Desarrollar un sistema de gestión por fases: elegir qué entra en la primera versión

La pregunta «qué ponemos en la primera versión» recibe casi siempre la misma respuesta equivocada: un poco de todo. Un trozo de fichas, un trozo de pedidos, un trozo de almacén. Es la elección que parece más prudente y es la que no se puede usar: ningún proceso llega hasta el final, y el sistema se queda como algo más que rellenar además de lo que ya se hace.

El criterio es el opuesto: la primera versión cubre un proceso completo, de principio a fin, aunque sea reducido. Mejor poco y completo que mucho e interrumpido.

Un proceso completo, con un resultado que se ve

«Completo» tiene un significado preciso: quien lo usa debe poder dejar de usar el método anterior para ese trozo de trabajo. Si después de introducir los datos en el sistema se sigue rellenando también la hoja de siempre, la primera versión no está terminada: es un doble trabajo, y se abandonará en cuanto la empresa tenga una semana difícil.

El resultado debe ser visible para alguien: un documento que sale, un listado que antes no existía, una llamada de teléfono que ya no hace falta. Sirve para dos cosas a la vez: da una razón concreta para usar el sistema y da una prueba de que el proyecto va a alguna parte.

Separar lo indispensable de las mejoras

Las peticiones llegan todas juntas y todas urgentes. Hacen falta preguntas que separen, y son siempre las mismas cuatro.

• ¿Sin esta función, el proceso se para? Si alguien puede hacer lo mismo de otra manera, por ahora, no es indispensable.
• ¿Quién la usa, y con qué frecuencia? Las funciones que se necesitan dos veces al año pueden seguir siendo manuales durante mucho tiempo, y a menudo siguen siendo manuales para siempre sin que nadie se queje.
• Si falta, ¿qué pasa de verdad? «Perdemos tiempo» y «no podemos facturar» no son la misma respuesta.
• ¿Es una función o es una costumbre? A veces hay que reproducir un paso que existía solo porque la herramienta antigua no sabía hacer otra cosa.

Cuidado con las peticiones breves que arrastran un mundo detrás: un estado más en un documento puede requerir permisos, avisos, historial y una regla sobre quién lo puede cambiar. El coste no se mide por la longitud de la frase que lo describe.

Las dependencias que no se pueden aplazar

El lanzamiento por módulos funciona solo si algunas decisiones se toman enseguida, aunque afecten a partes que llegarán mucho después. Son pocas, y cambiarlas más tarde cuesta tanto como rehacerlas.

• Los datos compartidos: cómo se identifica un cliente, un artículo, un encargo. Si la primera versión inventa una numeración propia, la segunda tendrá que reconciliar dos archivos.
• Quién ve qué: los permisos se diseñan al principio aunque al principio el sistema lo usen tres personas. Añadirlos después significa revisar cada pantalla.
• De dónde vienen los datos que no nacen aquí: si las existencias están en otro sitio, se decide ahora quién manda sobre una cantidad, aunque la conexión llegue más tarde.
• Cómo se registra el historial: si hace falta saber quién ha cambiado qué, hay que preverlo desde el principio, porque a posteriori no se puede reconstruir.

Ejemplo: primera versión para los encargos

Una empresa que instala equipamientos quiere un sistema de gestión para los encargos. La lista de deseos contiene una veintena de funciones. La primera versión toma cuatro, pero llega hasta el final.

Las funciones dejadas fuera no están canceladas: quedan enumeradas, con el motivo al lado y con la condición que hará que vuelvan a entrar. Es la diferencia entre aplazar y olvidar, y es también lo que permite responder a quienes las habían pedido.

Criterios de aceptación: cómo se dice que está terminado

«Funciona» no es un criterio. Un criterio es una frase que cualquiera puede verificar, escrita antes de empezar a desarrollar.

1. Describir el caso real, no la función: «el jefe de obra abre el encargo desde un presupuesto aceptado, asigna el equipo y rellena el parte de trabajo desde el móvil, en obra».
2. Decir quién lo verifica: quien hará ese trabajo todos los días, no quien encargó el proyecto.
3. Incluir los casos anómalos: el encargo anulado, el parte de trabajo rellenado sin red, la intervención que cambia de fecha.
4. Establecer con qué datos se prueba: datos reales y recientes, porque los inventados siempre están más ordenados que la realidad.

Las peticiones que llegan durante el proceso

Llegarán, y es una buena señal: significa que alguien está usando el sistema. El problema no es recibirlas, es clasificarlas deprisa.

• Error: lo que hay no hace lo que se había acordado. Se corrige enseguida.
• Olvido: hace falta para el proceso y nadie lo había mencionado. Se evalúa si entra, y la fecha de entrega se mueve en consecuencia.
• Mejora: hace el trabajo más cómodo. Va a la lista, no en la versión en curso.
• Cambio de rumbo: la empresa ha cambiado su forma de trabajar. Se debate aparte, porque no es una petición sino otro proyecto.

Sin esta distinción cada petición se vuelve urgente y la primera versión nunca sale. Es la forma más habitual en que estos proyectos se detienen: no por un obstáculo técnico, sino por acumulación.

Lo que esta guía no cubre

Aquí se habla de alcance y secuencia: qué entra en la primera versión, qué se aplaza y en qué orden. Las pruebas que hay que hacer antes de confiar en un sistema todos los días son un capítulo aparte. Y si la función a evaluar tiene que ver con el uso de un asistente automático, los criterios de juicio son distintos, porque el resultado no es previsible del mismo modo.