El cliente y el desarrollador imaginan productos distintos sin saberlo, y lo descubren cuando el proyecto ya está a la mitad.
Solo el 29% de los proyectos de software termina en tiempo y presupuesto — Standish Group, que lleva documentando este patrón desde 1994. El 52% entrega algo, pero fuera de plazo o con más costo del acordado. El 19% se cancela. La causa principal: requisitos mal definidos desde el inicio.
La información correcta en la primera reunión no garantiza que el proyecto salga bien. Pero sin ella, casi siempre sale mal.
Define el problema, no la solución
El error más común al pedir una app es describir cómo quieres que funcione antes de explicar qué problema resuelve.
"Quiero una app con login, dashboard, notificaciones push y un mapa en tiempo real" no le dice al desarrollador nada útil. "Tengo 40 técnicos en campo y no sé en tiempo real dónde están ni qué trabajo completaron hoy" sí le dice todo lo que necesita.
El desarrollador necesita entender el problema para proponer la solución correcta. Si le describes la solución directamente, te cotiza esa solución aunque no sea la que realmente necesitas.
Los 5 datos que un desarrollador necesita antes de cotizar
- El usuario final. No el nombre de tu empresa, sino quién opera la herramienta en el día a día. ¿Personal interno? ¿Clientes finales? ¿Técnicos en campo? ¿Cuántas personas? Esto define si necesitas una herramienta interna o un producto de cara al público, y cambia completamente el diseño y la seguridad.
- El proceso actual. Cómo funciona hoy sin la app, aunque sea en Excel o en papel. Si ya hay un proceso, el sistema nuevo tiene que reemplazarlo sin romper lo que ya funciona. Si no hay proceso, el desarrollo incluye diseñar uno desde cero, lo que añade tiempo y costo.
- Los sistemas existentes. ERP, CRM, base de datos propia, APIs de terceros como pagos o mensajería. Si la app necesita hablar con algo que ya tienes, eso cambia el alcance y el costo de integración.
- La función principal. Una sola, la más crítica. Las demás vendrán después, pero el núcleo del sistema define la arquitectura. Los proyectos que intentan construir todo desde el día uno rara vez terminan.
- Fecha y presupuesto. Una fecha real en que necesitas algo funcionando (no "lo antes posible") y un presupuesto aproximado. Un desarrollador que no conoce tu presupuesto te cotiza su solución ideal. Uno que sí lo conoce puede decirte qué cabe en esta etapa y qué queda para después.
Qué no necesitas saber antes de cotizar
No necesitas saber programar, diseñar pantallas ni elegir tecnología. Esas decisiones las toma el desarrollador con base en lo que le cuentes.
Si el proveedor te pide elegir tecnología antes de escuchar el problema, cámbiate de proveedor.
Señales de alerta en un proveedor
- Te cotiza sin hacerte preguntas. Una cotización sin preguntas es una estimación a ciegas. Si el primer mensaje es un precio, el precio no tiene sustento.
- No puede mostrarte proyectos similares entregados. Los desarrolladores con experiencia real tienen ejemplos concretos. Pídelos.
- Promete funcionalidades sin firmar un alcance por escrito. Lo que no está en el documento no existe. Las promesas verbales no protegen a nadie.
- El precio es mucho más bajo que el resto de las propuestas. El desarrollo de software tiene costos reales de tiempo y experiencia. Si alguien cobra la mitad de los demás, algo no está en el precio.
- No menciona el mantenimiento. Todo sistema necesita mantenimiento: actualizaciones de seguridad, corrección de bugs, cambios de funcionalidad. Si nadie lo menciona, pregunta quién lo hace y cuánto cuesta.
Cómo pedir una cotización que sirva
Responde los cinco puntos de arriba en un párrafo cada uno. Con eso, un desarrollador puede darte una propuesta real.
Si no puedes escribir ese documento, el proyecto aún no está listo para cotizarse.
En Zopy desarrollamos sitios web y aplicaciones para negocios. Si tienes un proyecto de software y quieres una opinión honesta sobre el alcance y el camino a seguir, escríbenos.