Requisitos de software cuando el experto no tiene tiempo

Los requisitos de software no tiene que escribirlos el experto que conoce el proceso. Los redacta otra persona a partir de una conversación corta con él, el experto lee el borrador y dice sí o no. Para la primera versión basta una página, y la frase más importante es la que dice cómo sabrá que está terminado.

A continuación: por qué los requisitos a menudo no llegan a escribirse, qué deben incluir, un método en cinco pasos y cuándo congelarlos. El artículo es para propietarios y responsables de departamento cuya mejor persona en el proceso no tiene tiempo para escribir.

¿Por qué los requisitos nunca llegan a escribirse?

Casi todas las empresas tienen a alguien que sabe exactamente cómo debe funcionar un proceso. Sabe qué cliente quiere la factura de otra manera y qué no se puede sobrescribir nunca en la hoja de cálculo. Se pasa el día haciendo ese proceso.

Y precisamente por eso no tiene tiempo para describirlo. El proveedor espera los requisitos. El experto espera tener una tarde libre. Esa tarde no llega, y el proceso sigue haciéndose a mano.

Con la IA, el desarrollo se ha acelerado. Esta espera, no. Hoy el cuello de botella a menudo no es programar, sino que nadie sabe decir con precisión qué hay que construir. Fred Brooks ya lo escribió en 1987:

La solución no es enviar al experto una plantilla de requisitos. No la rellenará, por la misma razón por la que nunca escribió el documento. La solución es quitarle la tarea de escribir.

Una conversación en lugar de un documento

Un experto puede hablar de su trabajo sin preparación. Basta con dejar que enseñe cómo lo hace y hacerle preguntas. Otra persona convierte la conversación en un borrador, y el experto solo lo lee. Para eso sí encuentra tiempo.

Funciona mejor una conversación sobre el trabajo real. El experto abre el correo, la hoja de cálculo o el programa y enseña el último caso. Mientras lo hace, cuenta cosas que nunca pondría en un documento, porque para él son evidentes.

Mejor todavía que un documento es un prototipo. Cuando el experto prueba la primera versión, en pocos minutos dice qué no encaja. Sobre el papel, eso serían semanas de comentarios.

¿Qué deben incluir los requisitos?

Los requisitos de una primera versión caben en una página. Cada parte responde a una pregunta que le hace al experto en la conversación:

La fila «qué queda fuera de la primera versión» importa tanto como las demás. Sin ella, la primera versión crece hasta convertirse en un sistema entero. Y la última fila decide si los requisitos se pueden cumplir.

¿Cómo escribir los requisitos paso a paso?

Todo el método le lleva al experto unas pocas horas repartidas en una semana, no una semana de escribir:

El segundo paso marca la diferencia. Quien redacta tiene que saber preguntar y no puede inventarse lo que falta. Donde falta una respuesta, anota una pregunta, no una suposición.

¿Cuándo congelar los requisitos?

Unos requisitos que cambian cada día no son flexibilidad. Son requisitos que se escriben mientras se construye. Con personas se podía sobrellevar, porque el desarrollador notaba el cambio y preguntaba. Un agente de IA no pregunta. Construye lo que tiene delante, aunque ayer valiera otra cosa.

A partir de ahí se puede cambiar todo lo que haga falta. Solo que se ve, y todos los que trabajan en ello saben qué vale.

¿Cómo se ve en la práctica?

Unos buenos requisitos suelen ser más cortos de lo que se espera. En el procesamiento de facturas en contabilidad se trataba de un solo paso: llega una factura en PDF por correo y alguien la copia a mano. El objetivo se podía decir de forma sencilla: la factura queda registrada sin copiarla a mano.

Unos requisitos así de acotados se construyen rápido y se comprueban con datos reales. Qué paso elegir primero lo contamos en ¿Qué procesos de la empresa automatizar primero?. Si el proceso vive hoy en una hoja de cálculo, también ayuda ¿Cuándo Excel ya no es suficiente para una empresa?

¿Están listos sus requisitos?

Marque lo que ya sabe del proceso que quiere pasar a un sistema:

Cuándo no basta

• Nadie hace el proceso dos veces igual. Si cada uno resuelve cada caso a su manera, primero hay que ponerse de acuerdo en el método. El software no unifica lo que las personas no han unificado.
• Se trata de un sistema entero de golpe. Una página basta para la primera versión de un proceso, no para sustituir todo el sistema de gestión. Divida un proyecto grande en pasos más pequeños.
• Decide alguien que no estuvo en la conversación. Si los requisitos los aprueba la dirección, que no hace el proceso, invítela al menos a probar el prototipo.

¿Quiere requisitos sin tener que escribirlos?

En la demo de su proceso repasamos el trabajo con la persona que lo hace. Por su parte: una hora de su tiempo y una reunión en la que probamos juntos el prototipo. En 10 días hábiles ve cómo haría un sistema su trabajo manual.

Si está creando un producto nuevo y no un proceso interno, empiece con la especificación de la primera versión en 1 página. Si prefiere hablar primero, reserve una llamada introductoria de 15 minutos.

¿Quién es en su empresa esa persona cuyos requisitos todos llevan medio año esperando?

Preguntas frecuentes

¿Quién debe escribir los requisitos de software?

No necesariamente quien conoce el proceso. Su papel es explicar el trabajo y confirmar el borrador. Puede redactarlo otra persona a partir de una conversación corta: un analista, el proveedor o un compañero que sepa preguntar.

¿Qué extensión deben tener los requisitos?

Para la primera versión basta una página: qué hace hoy una persona, qué debe hacer el sistema, de dónde salen los datos, quién lo usa, qué queda fuera de la primera versión y cómo sabrá que está terminada. Nadie termina de leer un documento largo.

¿Qué es lo más importante en los requisitos?

La frase que dice cómo sabrá que está terminado. Por ejemplo: un pedido que llega por correo entra en el sistema sin copiarlo a mano y una persona solo lo revisa. Sin esa frase, los requisitos no se acaban nunca.

¿Y si los requisitos cambian durante el desarrollo?

Los cambios son normales. Lo importante es un único sitio donde viven los requisitos, una persona que diga «esto es lo que vale» y una fecha a partir de la cual cada cambio es una tarea nueva y no un retoque de la anterior.

¿Se puede empezar sin requisitos?

Se puede empezar con un prototipo. La persona que hace el trabajo lo prueba y dice enseguida qué no encaja. Un prototipo en el que se puede hacer clic suele ser mejor punto de partida que un documento, porque en él se ve lo que falta.