Manual: diseño de producto en mythical man month

Hay un capítulo en el libro “The Mythical Man Month: Essays on Software Engineering” en el que dice que la especificación del sistema debe reflejarse en “el manual”.

Leí eso hace muchos años, y de lo obvio que era no entendí a que se refería. ¿El manual? No se podía estar refiriendo al manual de usuario, ¿no? Es decir, yo esperaba encontrar alguna forma arcana pre-UML con auténticos blueprints sesenteros. Estaba hablando sobre cómo especificar un sistema software complejo, la solución no podía ser tan sencilla. Diagramas de clases, de secuencia, de componentes, diferentes vistas de la estructura, de la interacción. O un método Jackson de aquellos de programación estructurada. Eso sí. Algo que un simple usuario no pudiera entender jamás. Pero, ¿un manual?

Así que mi conclusión fue que en los 70 llamaban “manual” a una especificación completa y sesuda de los requisitos del software.

Storytelling

Muchos años más tarde leía “Storytelling in Design” de Anna Dahlstrom. Leía una versión preliminar porque la versión final todavía no ha salido (se ve que se está tomando su tiempo en escribir la historia). Y ahí la autora describía muy bien todo eso de contar cómo debe funcionar el producto y explicar el camino a los usuarios con comparaciones y buenas historias.

Algunas cosas empezaban a hacer “clic” en mi cabeza.

Product Roadmaps

Según “Product Roadmaps Relaunched”, también de O’Reilly, la función principal de un roadmap debe ser entusiasmar primero a la propia empresa y luego a sus usuarios presentes y futuros con la evolución del producto. Y para ello, de nuevo, mucho storytelling y empatía y ponerse en la piel del usuario y escuchar y todo eso que cuenta todavía mucho mejor el libro de Marty Cagan sobre diseño de producto y product management.

Contando historias

Así que, a finales de año pasado me veía escribiendo sobre cómo iba a evolucionar Plastic SCM en los siguientes meses. Imaginando cómo podría ser y contando cómo debería funcionar. Sin diagramas avanzados ni flechas ni cajitas. Contando cómo sería usarlo. Qué experimentaríamos como usuarios. Qué sensaciones crearía.

Y entonces llegó el “clic” de verdad: para diseñar producto software lo mejor es “escribir el manual” antes de que el producto exista. Contar cómo va a funcionar, imaginar qué va a hacer, en detalle, de modo que un futuro usuario, o el equipo que lo va a desarrollar, pueda visualizar el resultado antes de que empiece el código.

Lo había tenido delante durante casi 20 años.