Cómo planificar un desarrollo de software a medida: alcance y costo

Un buen briefing de desarrollo de software a medida describe el trabajo que el software debe hacer posible. No necesita imponer un framework ni enumerar todas las pantallas. Necesita el detalle suficiente para que un equipo de desarrollo identifique las incógnitas y proponga una primera versión acotada.

Use esta lista de verificación antes de pedir una propuesta. Le ayuda a comparar lo que entregará cada proveedor, en lugar de comparar precios de interpretaciones distintas de la misma idea.

1. Nombre al usuario y la tarea

Escriba una frase: «Un [usuario] necesita [completar una tarea] para que [resultado útil]». Por ejemplo, un responsable de operaciones necesita aprobar una reserva sin copiar datos entre tres sistemas. Es un flujo de trabajo ilustrativo, no un resultado de un cliente.

Enumere a las demás personas implicadas. Un cliente, un administrador y un responsable de finanzas pueden necesitar permisos distintos aunque usen el mismo registro.

2. Describa lo que ocurre hoy

Explique el proceso actual, incluidas las hojas de cálculo, los correos y las comprobaciones manuales. Indique el paso que consume tiempo o provoca errores. Incluya un ejemplo anonimizado de los datos de entrada y del resultado esperado.

No envíe contraseñas, registros de clientes ni credenciales de producción en el primer correo. Describa los sistemas implicados; el acceso adecuado se organiza una vez acordado el proyecto.

3. Defina una primera versión completa

Elija un flujo de trabajo que un usuario real pueda terminar. Especifique qué lo inicia, qué hace el software y cómo sabe el usuario que ha funcionado. Incluya el caso de fallo: ¿qué ocurre cuando los datos son incorrectos, se rechaza una aprobación o una integración no está disponible?

Ponga todo lo demás en una lista aparte para más adelante. Una primera versión pequeña puede tener menos funciones y aun así necesitar un tratamiento fiable de los datos, control de acceso y una forma de recuperarse de un fallo.

4. Enumere las integraciones y los datos

Nombre cada servicio externo, la información que se intercambia y quién controla el acceso. Indique si el proveedor tiene una API documentada y si existe acceso de pruebas. Son preguntas por resolver, no capacidades que dar por supuestas.

Si hay que trasladar datos de un sistema antiguo, describa su formato, su tamaño aproximado, sus problemas de calidad y el período en que ambos sistemas tendrán que funcionar a la vez. La migración es trabajo adicional a la construcción de las pantallas nuevas.

5. Indique las restricciones que cambian la propuesta

Incluya los límites de presupuesto, cualquier fecha fija y su motivo, la accesibilidad exigida, las restricciones sobre la ubicación de los datos y quién usará el sistema. Si los requisitos exigen asesoramiento legal o de seguridad especializado, identifique quién lo aportará.

En el trabajo remoto, acuerde cómo se registrarán las decisiones, quién puede aprobar el alcance y qué coincidencia de horarios es necesaria. Una decisión estancada puede retrasar la entrega aunque la implementación sea sencilla.

6. Compare los factores de costo, no solo los totales

El costo del desarrollo de software depende de los flujos de trabajo, las reglas de permisos, las integraciones, el trabajo con datos y los requisitos de operación. El mismo número de pantallas puede esconder cantidades de trabajo muy distintas.

Pida a cada proveedor que separe el alcance conocido de las suposiciones. Compare estos cinco puntos:

• El comportamiento operativo incluido en la primera versión.
• Las incógnitas que deben comprobarse para que una estimación sea fiable.
• El trabajo excluido de la propuesta.
• Cómo afecta al precio y al calendario un cambio de alcance.
• Qué ocurre después del lanzamiento, incluidos los costos de alojamiento y el mantenimiento.

Un precio sin esos límites es difícil de comparar. Esta lista no ofrece un precio universal para un proyecto; una estimación creíble necesita los requisitos reales.

7. Decida cómo aceptará el trabajo

Redacte las comprobaciones en términos del usuario: «Un operador puede aprobar una solicitud, el cliente recibe la actualización correcta y la decisión queda registrada». Defina ejemplos representativos y los errores que el sistema debe gestionar.

Acuerde cómo verá el avance y probará las versiones. Acuerde también quién es titular del repositorio, de las cuentas de infraestructura, de la documentación, del proceso de despliegue y de las copias de seguridad. La lista de verificación del traspaso de software (en inglés) describe los elementos que debería poder recibir.

Envíe un briefing que inicie una conversación útil

Su primer correo puede ser breve: el usuario, el flujo de trabajo, lo que existe hoy, la integración importante y sus limitaciones de presupuesto o de plazo. No hace falta una especificación terminada.

AL+ ofrece servicios de desarrollo de software a medida y el código es de su empresa. Escriba a paul@alplustech.com con esos datos para hablar de su proyecto con las personas que lo construirían.