Señales de alerta en una propuesta comercial de desarrollo

Recibir una propuesta comercial bien presentada genera una sensación de avance. Finalmente hay algo concreto sobre la mesa: un documento con un alcance, un plazo y una cifra. La tentación de aprobarla rápido —sobre todo si hubo varias reuniones previas y el proyecto ya viene demorado— es comprensible.

Pero una propuesta comercial no es una cotización de un producto estándar. Es un documento que define los términos de una relación que va a durar semanas o meses, durante la cual van a aparecer imprevistos, malentendidos y decisiones difíciles. Si la propuesta no está preparada para eso, el proyecto empieza mal antes de empezar.

Estas son ocho señales de alerta que conviene revisar antes de firmar. Ninguna es definitiva por sí sola, pero si aparecen dos o tres juntas, conviene pedir aclaraciones —o seguir buscando.

1. El alcance es ambiguo

La señal más frecuente y la más costosa de ignorar. Frases como "desarrollo de un sistema de gestión integral", "plataforma web con funcionalidades de administración" o "módulo de reportes avanzados" no dicen nada concreto. Son títulos, no definiciones.

Una propuesta profesional describe el alcance con suficiente detalle como para que alguien que no participó de las reuniones previas entienda qué se va a construir. Eso implica:

• Funcionalidades específicas, no categorías genéricas.
• Roles de usuario si los hay (qué puede hacer cada tipo de usuario).
• Reglas de negocio relevantes (validaciones, condiciones, flujos alternativos).
• Lo que no está incluido, tan importante como lo que sí.

Si el alcance ocupa media página en un documento de diez, lo que sigue es probablemente relleno. Un alcance bien definido ocupa la mayor parte de la propuesta, porque es lo único que después permite discutir si lo entregado cumple o no con lo acordado.

2. Los plazos son irreales o no tienen justificación

Un plazo de entrega que parece demasiado optimista para lo que se describe en el alcance no es una buena noticia —es un riesgo. O el proveedor está subestimando la complejidad, o está dispuesto a entregar algo incompleto para cumplir con la fecha, o simplemente está diciendo lo que cree que el cliente quiere escuchar.

Señales concretas:

• El plazo es un número redondo sin desglose ("tres meses") en vez de un cronograma con hitos.
• No se mencionan dependencias: ¿el plazo asume que el cliente entrega ciertos insumos en determinadas fechas? ¿Qué pasa si no lo hace?
• No hay margen para imprevistos. Cualquier proyecto tiene un porcentaje de incertidumbre; si el plazo no lo contempla, el plan ya está desactualizado antes de empezar.

Pedí que te expliquen cómo llegaron a ese plazo. Si la respuesta es "por nuestra experiencia en proyectos similares", preguntá cuántos proyectos similares hicieron y cuánto tiempo les llevaron realmente, no lo que habían estimado al principio.

3. No hay hitos ni entregables intermedios

Un proyecto de varios meses sin puntos de control intermedios es una caja negra: el cliente paga y espera, sin visibilidad de si el desarrollo va por buen camino hasta que supuestamente está terminado.

Una propuesta seria divide el proyecto en etapas, cada una con un entregable concreto y verificable: una versión funcional con un subconjunto de las funcionalidades, una demo de un flujo completo, un prototipo navegable. El objetivo no es burocrático: es que el cliente pueda detectar desvíos temprano, cuando corregirlos cuesta poco, en vez de descubrirlos al final, cuando ya se invirtió la mayor parte del presupuesto.

Si la propuesta solo menciona "entrega final", preguntá cómo vas a saber si el proyecto está avanzando al ritmo esperado durante los meses previos. Si la respuesta es "confiá en nosotros", ya sabés lo que necesitás saber.

4. No se menciona el mantenimiento posterior

Un sistema de software necesita mantenimiento desde el día uno: corrección de errores que aparecen en producción, actualizaciones de seguridad, ajustes por cambios en sistemas externos con los que se integra. Si la propuesta no dice nada sobre quién se ocupa de esto después de la entrega, el cliente está asumiendo ese riesgo sin saberlo.

Lo mínimo que debería aparecer:

• Período de garantía: ¿durante cuánto tiempo se corrigen errores sin costo adicional?
• Modelo de soporte posterior: ¿hay un plan de mantenimiento mensual? ¿Se cotiza por incidente? ¿No se ofrece y el cliente debe buscar otro proveedor?
• Condiciones de traspaso: ¿qué necesita el cliente para que otro equipo pueda hacerse cargo del mantenimiento si decide no continuar con el proveedor original?

Una propuesta que omite este punto está implícitamente diciendo que el proyecto termina con la entrega. Pero ningún proyecto de software termina realmente con la entrega: la entrega es el punto donde empieza la operación real.

5. La propuesta habla más de la empresa que del proyecto

No hay nada malo en que el proveedor incluya información sobre su trayectoria, equipo y casos de éxito. Pero cuando esas secciones ocupan más espacio que la descripción del alcance, la propuesta está diseñada para vender, no para definir un proyecto.

Una propuesta equilibrada dedica la mayor parte del contenido a lo que se va a hacer, cómo, en cuánto tiempo y bajo qué condiciones. Los antecedentes del proveedor son información de contexto, útil para evaluar si tienen experiencia relevante, pero no reemplazan una definición clara del trabajo.

Si después de leer la propuesta no podrías explicarle a un tercero qué funcionalidades incluye el proyecto, el documento no está cumpliendo su función principal. Volvé a pedirlo con más detalle.

6. No hay referencias a riesgos ni supuestos

Toda estimación de software se basa en supuestos: que cierta integración funciona de determinada manera, que los datos a migrar están en cierto formato, que el cliente va a estar disponible para validar entregables en ciertos plazos. Un proveedor experimentado explicita esos supuestos en la propuesta, porque sabe que si alguno no se cumple, el plan original deja de ser válido.

Si la propuesta no menciona ningún riesgo ni supuesto, está presentando un escenario ideal que rara vez se da en la práctica. Eso no significa que el proveedor sea deshonesto; puede ser simplemente que nunca aprendió —porque nunca se lo exigieron— a documentar las condiciones bajo las cuales su estimación es válida.

Pedí que agreguen una sección de "supuestos y riesgos". Si no saben qué poner, es porque no hicieron el análisis necesario para estimar con responsabilidad.

7. El precio es el único diferenciador

Si la propuesta compite exclusivamente por precio —"somos más baratos que cualquier otra opción", "precio imbatible", "descuento por tiempo limitado"—, hay una alta probabilidad de que ese ahorro inicial se pague después en calidad, soporte o funcionalidades que quedaron afuera sin que se explicitaran.

El precio es una variable importante, pero no puede ser la única. Una propuesta barata que no especifica qué incluye y qué no, es más cara a mediano plazo que una propuesta más costosa pero transparente, porque los costos que no se ven en la cotización inicial aparecen después, cuando ya no hay margen para comparar alternativas.

8. No se establecen condiciones de propiedad del código y los datos

Parece un detalle legal, pero es de las cosas que más problemas generan cuando el cliente quiere cambiar de proveedor o escalar el producto con otro equipo. La propuesta debe dejar claro, sin ambigüedad:

• Que el código fuente es propiedad del cliente una vez pagado el desarrollo.
• Que el cliente tiene acceso completo al repositorio desde el inicio del proyecto, no solo al final.
• Que las credenciales de todos los servicios contratados para el proyecto (hosting, bases de datos, dominios) quedan bajo control del cliente.

Si estos puntos no están en la propuesta, pedí que los incluyan por escrito. Una negativa o una respuesta evasiva en este punto es una señal de alerta más fuerte que cualquiera de las anteriores.

Qué hacer si detectás estas señales

Encontrar una o dos de estas señales no implica necesariamente descartar al proveedor. A veces son consecuencia de una propuesta preparada con poco tiempo, no de una mala práctica sistemática. Lo que corresponde es pedir las aclaraciones necesarias y ver cómo responde el proveedor.

Un proveedor serio:

• Acepta el pedido de más detalle sin ponerse a la defensiva.
• Explica por qué estimó lo que estimó.
• Está dispuesto a ajustar la propuesta para incluir lo que falta.

Un proveedor que se resiste a aclarar, que responde con generalidades o que trata el pedido de detalle como una falta de confianza, está confirmando que las señales de alerta eran acertadas.

Relacionado: si ya estás en etapa de evaluar proveedores, complementá esta lectura con las preguntas que debes hacer antes de contratar un proveedor tecnológico. Y si todavía no definiste el alcance del proyecto, revisá qué validar antes de desarrollar una aplicación para asegurarte de que la propuesta que recibas parta de una base sólida.

Más herramientas de evaluación en la categoría de proveedores tecnológicos.