Señales de alerta al recibir una propuesta de desarrollo

Recibir una propuesta comercial de desarrollo de software genera una mezcla de entusiasmo y ansiedad. Entusiasmo porque el proyecto empieza a tomar forma concreta. Ansiedad porque, para quien no tiene experiencia técnica, evaluar si la propuesta es sólida o está llena de supuestos optimistas puede ser difícil.

La buena noticia es que muchas propuestas problemáticas comparten patrones reconocibles. No hace falta saber de tecnología para detectarlos: son inconsistencias de negocio, no de ingeniería. Este artículo lista las señales de alerta más frecuentes y explica por qué cada una debería disparar una conversación adicional antes de firmar.

Señal 1: El alcance es ambiguo

La señal más común y la más peligrosa. Una propuesta que describe el proyecto en términos genéricos —"desarrollo de plataforma web con panel de administración", "sistema de gestión de clientes con reportes"— sin especificar qué funcionalidades incluye cada módulo, qué queda fuera del alcance y cuáles son los criterios para considerar que algo está terminado.

Una propuesta sólida dedica varias páginas a describir, funcionalidad por funcionalidad, qué se va a construir. No necesita ser un documento de especificación técnica completo —eso puede ser parte del trabajo posterior al contrato—, pero sí debe ser lo suficientemente detallada como para que dos personas distintas que la lean entiendan lo mismo.

Si la propuesta describe el proyecto en tres párrafos y el resto son condiciones comerciales, la ambigüedad del alcance va a generar discusiones durante el desarrollo sobre qué está incluido y qué no. Y en esa discusión, el proveedor —que redactó la propuesta— tiene ventaja.

Señal 2: Los plazos no se corresponden con el alcance

Un proyecto que según la propuesta requiere seis meses de trabajo pero se ofrece en tres debería disparar una pregunta: ¿cómo se logra esa reducción? Si la respuesta es "nuestro equipo es más eficiente", sin explicar qué decisiones técnicas o de proceso permiten esa eficiencia, el plazo probablemente no sea realista.

Los plazos irreales no son un problema menor: afectan todas las decisiones posteriores. Un plazo imposible lleva a recortar calidad para llegar a la fecha —menos pruebas, menos documentación, funcionalidades entregadas a medias—, o a incumplir la fecha y generar frustración en el cliente.

Una propuesta con plazos realistas incluye un cronograma —aunque sea tentativo— con hitos intermedios. No solo la fecha de entrega final, sino momentos en los que el cliente va a ver algo funcionando: un prototipo, un módulo terminado, una versión de prueba. Si la propuesta solo menciona una fecha de entrega sin hitos intermedios, no hay manera de saber durante el desarrollo si el proyecto viene bien encaminado o ya se desvió.

Señal 3: La propuesta no menciona al equipo que va a trabajar en el proyecto

Una propuesta que describe la empresa —"somos un equipo de treinta profesionales con experiencia en más de cien proyectos"— pero no dice quiénes específicamente van a trabajar en este proyecto está vendiendo la marca, no el equipo.

Lo que importa no es cuánta experiencia tiene la empresa en general, sino cuánta experiencia tienen las personas concretas que van a escribir el código, diseñar la arquitectura y tomar decisiones técnicas en este proyecto. Una empresa puede tener cien proyectos en su historial y asignar a tu proyecto a un equipo sin experiencia en el tipo de producto que necesitás.

Pedí que la propuesta incluya, al menos, los roles del equipo —desarrollador frontend, desarrollador backend, líder técnico— y la experiencia relevante de las personas que ocuparían esos roles. Si el proveedor no puede o no quiere compartir esa información antes de firmar, es razonable preguntarse por qué.

Señal 4: No hay plan de mantenimiento ni de soporte post-entrega

Una propuesta que cubre solo el desarrollo y no dice nada sobre lo que pasa después está omitiendo la mitad del costo del proyecto. Mantener una aplicación funcionando —hosting, actualizaciones de seguridad, corrección de errores, soporte a usuarios— tiene un costo que empieza cuando el desarrollo termina y no se detiene mientras la aplicación esté en uso.

Si la propuesta no menciona:

• Qué cobertura de garantía incluye —treinta, sesenta, noventa días— y qué cubre exactamente.
• Cómo se gestionan los errores que aparecen después de la entrega.
• Quién se ocupa de las actualizaciones de seguridad de las dependencias.
• Qué costo tiene el soporte post-entrega si no está incluido.

...entonces esos puntos van a ser motivo de negociación —o de discusión— cuando ya no haya margen para cambiar de proveedor sin costo.

Señal 5: La propuesta llegó demasiado rápido

Preparar una propuesta seria de desarrollo de software lleva tiempo. Requiere entender el problema del cliente, dimensionar la complejidad, evaluar alternativas técnicas, estimar el esfuerzo. Si la propuesta llegó veinticuatro horas después de la primera reunión, probablemente es una propuesta genérica con el nombre del cliente cambiado.

Esto no significa que el proveedor no pueda ser bueno. Pero sí significa que la propuesta no fue pensada para este proyecto específico, y que el trabajo real de entender lo que hay que construir va a ocurrir después de firmado el contrato —cuando el cliente ya está comprometido—.

Una propuesta que incluye referencias a detalles de la conversación con el cliente, que plantea preguntas sobre aspectos que quedaron ambiguos y que propone una fase de descubrimiento para definir mejor el alcance es una propuesta que fue pensada para este proyecto. La diferencia se nota.

Señal 6: No se mencionan riesgos ni supuestos

Todo proyecto de software tiene riesgos: integraciones con sistemas externos cuyo comportamiento no se conoce del todo, funcionalidades cuya complejidad es difícil de estimar sin una prueba de concepto, dependencias de terceros que pueden cambiar. Una propuesta que no menciona ningún riesgo no es una propuesta optimista: es una propuesta que no fue analizada.

Los riesgos no tienen que ser un capítulo extenso, pero deberían aparecer. Y junto con cada riesgo, una mitigación: qué va a hacer el proveedor si ese riesgo se materializa, cómo afecta los plazos, quién asume el costo adicional.

Señal 7: La propuesta es marcadamente más barata que las otras

Si recibiste tres propuestas y una es significativamente más barata que las otras dos, no asumas que encontraste un proveedor más eficiente. Asumí que hay algo que ese proveedor no está incluyendo —mantenimiento, documentación, pruebas, soporte— y que los otros dos sí.

Pedile al proveedor más barato que detalle qué incluye su propuesta y, sobre todo, qué no incluye. Si no puede hacer ese detalle, probablemente tampoco dimensionó bien el proyecto y el precio bajo es el resultado de una estimación insuficiente, no de una eficiencia genuina.

El artículo sobre por qué dos presupuestos de software pueden tener precios tan diferentes explica qué variables explican esas diferencias y cómo comparar cotizaciones sin quedarse solo con el número final.

Cómo actuar frente a estas señales

Una señal de alerta no significa necesariamente que el proveedor sea malo. Significa que hay un punto que requiere una conversación adicional antes de firmar. La respuesta del proveedor a esa conversación es, en sí misma, información valiosa.

Si el proveedor reconoce la señal —"tenés razón, el alcance está poco detallado, preparemos un documento más específico antes de firmar"— y propone una solución, es una buena señal. Si minimiza la señal —"no te preocupes, eso lo resolvemos sobre la marcha"— o se pone a la defensiva, es una señal adicional.

El objetivo no es encontrar al proveedor perfecto —no existe—, sino identificar los riesgos de cada propuesta y decidir con cuáles se puede convivir y con cuáles no.

Para una guía más completa sobre cómo evaluar proveedores, el artículo sobre cómo elegir una empresa de desarrollo de software ofrece seis criterios estructurados. Y si ya identificaste estas señales y querés profundizar en cómo comparar dos propuestas, revisá cómo comparar dos propuestas tecnológicas.

Más contenido sobre selección de proveedores en la categoría de proveedores tecnológicos.