Tres desarrolladores que cotizan el mismo encargo en 40,000, 90,000 y 250,000 normalmente no están discrepando sobre sus tarifas. Están cotizando tres productos diferentes, porque el encargo permitía tres interpretaciones.
Por qué se produce la diferencia
Un encargo que dice "los usuarios pueden cargar documentos" deja abiertas todas las decisiones costosas. ¿Qué tamaño? ¿Qué formatos? ¿Hay análisis antivirus? ¿Vista previa en el navegador o solo descarga? ¿Control de versiones? ¿Quién puede ver los archivos de quién? ¿Conservación y eliminación?
Un desarrollador que cotiza con cautela asume la interpretación sencilla. Otro que cotiza de forma defensiva asume la compleja y calcula el precio en consecuencia. Ambos actúan razonablemente. El comprador concluye que el más caro está cobrando de más, elige el barato y descubre la diferencia durante el desarrollo, momento en el que se convierte en una solicitud de cambio.
Las cinco cosas que deben quedar definidas
- Los roles de usuario y lo que cada uno puede hacer. No "administrador y usuario", sino una lista de acciones por rol. La lógica de permisos representa una parte importante del trabajo en la mayoría de las aplicaciones empresariales y es invisible en una lista de funcionalidades.
- Los flujos de trabajo principales, paso a paso. Escriba la secuencia que realmente sigue un usuario, incluido lo que ocurre cuando algo sale mal: un pago rechazado, una sesión caducada o un envío duplicado.
- Los datos. Qué se almacena, qué es obligatorio, qué validación se aplica y durante cuánto tiempo se conserva. Una lista de campos es más útil que una descripción de pantallas, porque las pantallas cambian y los datos no.
- Las dependencias externas. Pagos, mensajería, mapas y sistemas existentes con los que haya que conectarse. Cada una implica tiempo de aprobación y gestión de fallos que deben contemplarse en el presupuesto.
- Los criterios de aceptación. Cómo decidirá que el producto está terminado. Esta es la sección que más suele omitirse y la que evita más discusiones.
Volumen y rendimiento, expresados con números
"Debería ser rápido" y "debería admitir muchos usuarios" no se pueden cotizar ni probar. Los números sí:
- Usuarios previstos en el primer año y usuarios simultáneos en el pico de actividad.
- Registros previstos en la tabla más grande después de un año.
- Tiempo de respuesta aceptable para la operación común más lenta.
- Tamaños de archivo y almacenamiento total.
Estos factores cambian la arquitectura. Una aplicación diseñada para 200 usuarios y otra diseñada para 200,000 difieren en el diseño de la base de datos, la caché y el coste del alojamiento; construir la segunda cuando necesita la primera desperdicia dinero que podría haberse destinado a funcionalidades.
Lo que una especificación no debe contener
Dos cosas que empeoran las especificaciones:
Decisiones tecnológicas, salvo que exista una limitación real. Especificar un framework porque alguien lo recomendó elimina la capacidad del desarrollador de proponer algo más adecuado. Si existe una limitación genuina, como un sistema existente o un equipo interno que deba mantenerlo, indique la limitación en lugar de la conclusión.
Diseño a nivel de píxel en una especificación funcional. Es mejor separar el diseño de la funcionalidad. Una especificación que los mezcla dificulta la revisión de ambos y convierte cada preferencia visual en un cambio funcional.
Las secciones que causan disputas más adelante
De forma sistemática, en este orden:
- Informes. "Informes" en un encargo se convierte en una semana de trabajo por informe una vez que se conocen los campos, filtros, agrupaciones y formato de exportación.
- Notificaciones. El correo electrónico, los SMS, las notificaciones push y las notificaciones dentro de la aplicación son cuatro implementaciones diferentes con cuatro costes diferentes. "El sistema notifica al usuario" no especifica ninguna de ellas.
- Búsqueda. Buscar en un campo es trivial; buscar entre registros relacionados con clasificación es un proyecto independiente.
- Migración. Incorporar los datos existentes casi siempre es más difícil de lo esperado, porque los datos antiguos son incoherentes de formas que nadie documentó.
Nombrar explícitamente estos cuatro aspectos en la especificación, aunque sea brevemente, los convierte de suposiciones en alcance.
Un enfoque práctico
Una especificación útil para un proyecto pequeño suele tener entre cinco y quince páginas: lista de roles, descripciones de flujos de trabajo, campos de datos, lista de integraciones, cifras no funcionales, criterios de aceptación y una sección explícita de elementos fuera del alcance.
Esta última sección hace más de lo que su extensión sugiere. Escribir "los informes más allá de las tres pantallas enumeradas quedan fuera del alcance de esta fase" cuesta una línea y elimina toda una categoría de desacuerdos posteriores.
Servicios relacionados de Manboo
- Desarrollo de aplicaciones Flutter para MVP de iOS y Android.
- Desarrollo de software empresarial para sistemas de CRM, reservas, inventario y flujos de trabajo.
- Desarrollo de paneles de administración para paneles operativos y gestión del backend.
- Integración de API de IA cuando su producto esté listo para búsquedas inteligentes, chat o automatización.
- Solicite una revisión del alcance y un presupuesto del proyecto cuando esté listo para planificar la primera versión.