Cómo comparar dos propuestas tecnológicas

Recibir dos o tres propuestas de desarrollo de software y tener que elegir una es una situación frecuente y, para quien no tiene experiencia comparando este tipo de documentos, incómoda. Las propuestas usan formatos distintos, describen el alcance con distintos niveles de detalle, incluyen —o excluyen— cosas diferentes y, sobre todo, llegan con números finales que rara vez son comparables de manera directa.

La respuesta instintiva —elegir la más barata o la que viene de la empresa más conocida— es comprensible pero riesgosa. El precio final de una propuesta es la consecuencia de un conjunto de decisiones sobre qué incluye, qué excluye, quién lo construye y cómo se gestiona el proyecto. Comparar solo el número final es como comparar dos autos por el color: es un dato, pero no es el que determina si el auto te va a llevar a donde necesitás ir.

Este artículo propone un método para comparar propuestas de desarrollo evaluando cinco dimensiones que impactan más que el precio en el resultado del proyecto.

Dimensión 1: El alcance real de cada propuesta

Dos propuestas por el mismo proyecto pueden tener precios completamente distintos simplemente porque están cotizando cosas distintas. Antes de comparar números, hay que comparar alcances.

Para cada propuesta, identificá:

• Qué funcionalidades incluye explícitamente. Hacé una lista de lo que cada propuesta dice que va a construir. Si una menciona "panel de reportes con cinco tipos de gráficos descargables en PDF" y la otra dice "módulo de reportes", no están cotizando lo mismo aunque las dos digan "reportes".
• Qué excluye explícitamente. Algunas propuestas listan lo que no está incluido: "no incluye migración de datos históricos", "no incluye diseño de marca ni identidad visual". Si una propuesta lo menciona y la otra no, asumí que la que no lo menciona tampoco lo incluye —hasta que lo confirmes por escrito—.
• Qué queda en zona gris. Hay funcionalidades que ninguna de las dos propuestas menciona pero que son necesarias para que el producto funcione: autenticación de usuarios, manejo de errores, panel de administración. Si no están mencionadas en ninguna propuesta, preguntá a ambas si están incluidas y bajo qué alcance.

Dimensión 2: El equipo asignado

Dos propuestas pueden tener el mismo precio y la misma descripción de alcance, pero si una asigna un equipo de dos personas y la otra un equipo de cinco, la calidad, la velocidad y la profundidad del trabajo van a ser distintas. También si una asigna desarrolladores con experiencia en el tipo de producto que necesitás y la otra asigna desarrolladores genéricos.

Para cada propuesta, preguntá y compará:

• Composición del equipo: cuántas personas, con qué roles, con qué dedicación —tiempo completo, parcial—.
• Experiencia relevante de las personas clave —no de la empresa, de las personas— en proyectos similares en tipo de producto, industria o tecnología.
• Estabilidad del equipo: ¿el equipo que va a arrancar es el mismo que va a terminar? Si hay rotación prevista, ¿cómo se gestiona?

Una propuesta que no especifica el equipo no necesariamente es mala, pero es una propuesta que deja una variable crítica sin definir. Pedí esa información antes de comparar.

Dimensión 3: El proceso de trabajo y la comunicación

El proceso determina cómo se va a desarrollar el proyecto día a día, y la comunicación determina cómo te vas a enterar de si va bien o mal. Dos propuestas pueden prometer el mismo resultado final, pero si una ofrece visibilidad semanal con demos funcionando y la otra propone "entregas parciales a definir", la experiencia durante el proyecto va a ser radicalmente distinta.

Compará:

• Frecuencia y formato de los avances. ¿Cada cuánto vas a ver algo funcionando? ¿Vas a recibir una demo, un informe de horas, acceso a un entorno de prueba?
• Gestión de cambios de alcance. ¿Cómo se definen, cotizan y aprueban los cambios? ¿Hay un proceso documentado o se resuelve "sobre la marcha"?
• Responsable asignado. ¿Hay una persona identificada como tu contraparte durante el proyecto? ¿Cuál es su rol y su experiencia?
• Herramientas de seguimiento. ¿Vas a tener acceso a la herramienta donde gestionan las tareas? ¿Vas a poder ver el avance en tiempo real o dependés de lo que te cuenten en la reunión semanal?

Dimensión 4: Lo que pasa después de la entrega

El desarrollo es un momento en la vida del producto. Lo que viene después —mantenimiento, soporte, actualizaciones— es un proceso continuo. Comparar propuestas solo por lo que incluyen hasta la entrega es ignorar la mayor parte del costo y del riesgo.

Para cada propuesta, verificá y compará:

• Período de garantía. ¿Cuánto dura? ¿Qué cubre exactamente —solo corrección de errores o también ajustes menores—? ¿Qué pasa con los errores que aparecen después de ese período?
• Documentación incluida. ¿Qué documentación entregan al finalizar? ¿Incluye manual de instalación, documentación de arquitectura, documentación de APIs?
• Transferencia de conocimiento. ¿Cómo se aseguran de que tu equipo —o un tercero— pueda operar y modificar el producto sin depender de ellos? ¿Hay sesiones de transferencia incluidas?
• Propiedad del código y accesos. ¿El código queda en un repositorio de tu propiedad? ¿Recibís todas las credenciales de servicios externos? ¿Hay algún componente que uses bajo licencia y no sea de tu propiedad?
• Costo del mantenimiento post-entrega. Si no está incluido en la propuesta, ¿cuál es el costo estimado mensual o por hora para soporte y mantenimiento una vez vencida la garantía?

Una propuesta más barata en desarrollo pero que no incluye documentación ni transferencia de conocimiento puede terminar costando más en el total, porque cada modificación futura va a requerir contratar al mismo proveedor —que ya sabe cómo funciona el sistema— o pagarle a otro para que haga arqueología del código.

Dimensión 5: Los riesgos que cada propuesta revela —u oculta—

Toda propuesta contiene información sobre riesgos, aunque no los mencione explícitamente. La forma en que está escrita, lo que incluye y lo que omite, dice cosas sobre los riesgos del proyecto con ese proveedor.

Algunas preguntas para detectar riesgos al comparar:

• ¿La propuesta menciona supuestos —cosas que el proveedor da por ciertas sin verificar—? Si una propuesta tiene supuestos explícitos —"asumimos que los datos históricos están en formato X"— y la otra no menciona ninguno, la primera está siendo más transparente sobre lo que no sabe. La segunda puede estar subestimando riesgos o, peor, planeando facturarlos como cambios cuando aparezcan.
• ¿La propuesta identifica los puntos de mayor complejidad técnica? Si una propuesta dedica un párrafo a explicar por qué cierta integración es compleja y cómo planean abordarla, y la otra la trata como una funcionalidad más, la primera entendió el proyecto mejor.
• ¿Hay algo en la propuesta que contradice lo que se habló en la reunión? Si en la reunión se acordó que el diseño de interfaz lo haría el cliente y la propuesta incluye una partida de diseño, hay una discrepancia que conviene resolver antes de firmar.
• ¿La propuesta incluye un cronograma con hitos medibles o solo una fecha de entrega? Un cronograma sin hitos intermedios es un riesgo: no hay manera de detectar desvíos durante el proyecto.

Integrar las cinco dimensiones en una decisión

Comparar propuestas no es encontrar cuál es mejor en todo —esa propuesta probablemente no existe— sino identificar en qué es fuerte y en qué es débil cada una, y decidir cuál se ajusta mejor a las prioridades del proyecto.

Un proyecto donde la velocidad de entrega es crítica puede tolerar un proveedor con proceso menos documentado pero con un equipo disponible para arrancar de inmediato. Un proyecto donde la independencia post-entrega es prioritaria puede justificar pagar más por un proveedor que documenta exhaustivamente y transfiere conocimiento de forma estructurada.

El precio importa, pero como una variable más dentro de una comparación multidimensional. Elegir solo por precio es delegar la decisión en un solo número que no captura ni el alcance real, ni la calidad del equipo, ni el costo post-entrega, ni los riesgos del proyecto.

Para complementar este método de comparación con un análisis de por qué dos propuestas por el mismo proyecto pueden diferir tanto en precio, revisá el artículo sobre por qué dos presupuestos de software pueden tener precios tan diferentes. Y si detectaste señales de alerta en alguna de las propuestas, el artículo sobre señales de alerta en una propuesta comercial detalla los patrones que conviene identificar antes de avanzar.

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