Cómo contratar software a medida sin caer en el alcance infinito

El alcance infinito no es algo que los proveedores te hacen. Es lo que pasa cuando nadie en la sala define lo que el software no debe hacer. Un proyecto sin límites explícitos se expande para absorber cada buena idea que aparece por el camino, y cada una de esas ideas es, por separado, razonable. El resultado es una construcción que está permanentemente a tres meses de terminarse.

La solución no es un negociador más duro ni un contrato más grueso. Es otra forma de delimitar: definir el proyecto por los resultados operativos que debe producir, no por la lista de funcionalidades que debería contener. Lo decimos como un equipo que construye software y además opera sus propios productos en producción. Operar software después de entregarlo enseña rápido que un alcance pequeño funcionando en un día real vale más que un alcance grande que solo existe en un documento.

Por qué las listas de funcionalidades crean alcance infinito

Una lista de funcionalidades parece rigor, pero trae incorporada una válvula de un solo sentido. Cada reunión agrega una funcionalidad, porque agregar se siente como progreso y no cuesta nada en la etapa de planificación. Nadie quita ninguna, porque quitar se siente como renunciar a algo ya pagado. Así que la lista solo crece, y cada adición hace más fácil justificar la siguiente.

Después la lista se convierte en la especificación, y la especificación se convierte en la pelea. Cada ambigüedad, como si 'reportes' incluía exportar a Excel, se vuelve una negociación sobre quién debe qué. El documento que debía proteger a ambas partes se convierte en el terreno donde pelean. Y mientras esa pelea sigue, nadie hace la única pregunta que importa: ¿el punto 23 cambia algo en cómo opera realmente el negocio?

Delimita por resultado

Un resultado operativo es un momento específico del negocio que debe ser distinto cuando el software exista. Por ejemplo: un trabajador de campo fotografía un recibo, y el gasto existe en el sistema, categorizado, antes de que vuelva a la camioneta. Esa sola frase vale más que tres páginas de funcionalidades de un módulo de gastos, porque nombra quién, haciendo qué, con qué resultado, y puede verificarse observando a una persona real en un día real, en lugar de leyendo un checklist.

Así delimita Cazullo sus proyectos: como un conjunto corto de momentos con nombre, cada uno comprobable en la operación real. Las funcionalidades pasan a ser detalles de implementación, elegidos por quien construye y juzgados contra el momento al que sirven. Lo que no sirve a un momento con nombre queda, por definición, fuera del alcance. No fue rechazado, solo no está en este proyecto.

La disciplina de la v1

Con los momentos nombrados, la primera versión exige un acto más de disciplina: rechazar la amplitud. Sostenemos esta línea en nuestros propios productos por una razón egoísta, porque somos nosotros quienes tenemos que operar lo que sea que se entregue.

• Un flujo completo de punta a punta vale más que cinco flujos a medias. Un recibo que se convierte en gasto categorizado, siempre, es un producto. Cinco módulos al 60 por ciento es una demo.
• El software que sostiene un día real se gana el derecho a crecer. Cuando un flujo carga la operación de verdad, la siguiente conversación de alcance se apoya en uso, no en imaginación.
• Todo lo demás es un backlog etiquetado, no una promesa. Anota las ideas recortadas con nombre y motivo, para que sacarlas de la v1 se sienta como archivar, no como perder.

Formas de contrato que ayudan

Ninguna forma de contrato elimina la deriva de alcance, así que desconfía de quien afirme que la suya sí. Algunas formas, eso sí, facilitan la honestidad. La principal son fases en las que cada fase termina en algo que opera: un entregable que una persona real usa en el trabajo real. 'Requisitos completos' y 'arquitectura aprobada' son hitos de documentación, no entregables. Un trabajador registrando un gasto real a través del sistema es un entregable.

La otra forma útil es poder parar después de cada fase sin dejar escombros. Si el cliente puede irse después de la fase uno con software funcionando y que es suyo, el constructor tiene que hacer que la fase uno sea genuinamente útil, y el cliente tiene que poner en ella lo que de verdad importa. Esa opción de salida mantiene honestos a todos, incluidos nosotros.

Preguntas que encogen el alcance

Cuando la conversación de alcance empieza a inflarse, estas preguntas la desinflan:

• ¿Qué hoja de cálculo muere en la v1? Si ninguna hoja de cálculo, grupo de mensajes o proceso en papel desaparece, el software es un agregado en lugar de un reemplazo, y la adopción lo va a mostrar.
• ¿Quién usa esto el primer día? Nombra personas reales. Una funcionalidad que ninguna persona con nombre va a tocar en el primer mes pertenece al backlog.
• ¿Qué se rompe si recortamos esto? Si la respuesta honesta es 'nada, por ahora', recórtalo.
• ¿Cómo se las arregla la operación mientras esto se construye? El apaño manual suele revelar qué parte es urgente de verdad.
• ¿Cuáles de estas funcionalidades pidió alguien, y cuáles imaginamos que alguien querría?
• ¿Qué debe ser cierto en noventa días para llamar éxito a esta fase, sin que nadie corra una demo?
• Si el presupuesto se cortara a la mitad, ¿qué mantendríamos? Lo que sobrevive a esa pregunta es el alcance real.

Empieza más pequeño de lo que parece cómodo

Nuestra recomendación es directa: contrata el software más pequeño que cambie un momento operativo real, ponlo en manos reales y deja que lo que pase escriba el siguiente alcance. Una v1 pequeña, en vivo y usada te enseñará más sobre qué construir después que cualquier ciclo de planificación. Viniendo de un equipo que tiene que operar lo que construye, eso no es una concesión. Es el camino más rápido que conocemos hacia software que importa.