Ayer, hablando con una amiga sobre una situación que se había dado en su equipo, me hizo pensar en escribir algo sobre esto, y es el eterno tema de hacer los diseños técnicos, los funcionales, como mejorarlos, como usarlos para comunicar el trabajo, etc.

La situación, para ponernos en antecedentes, es una tarea que había hecho otra persona y que ella tenía que validar, la tarea, descrita en el funcional, era bien sencilla, hacer una validación de un campo y en caso de error mostrarle un mensaje al usuario, bien sencillo, sin embargo, la persona que lo hizo, en vez de mostrar un error, hacia otra cosa distinta.

¿Por qué había ocurrido esto?, el desarrollador, se había basado en lo que muchos desarrolladores se basan para hacer sus tareas, y que usamos habitualmente entre nosotros como nuestro modo de comunicación, el diseño técnico, pero ah, amigo, realmente donde está detallado ese funcionamiento es en el diseño funcional, que es el que solemos tomar para hacer las pruebas, la pregunta que surgía era, ¿cómo puedo hacer mejores diseños técnicos para que especifiquen este tipo de cosas?.

Mi opinión en esto, es ¿realmente debe un diseño técnico detallar este tipo de cosas funcionales?, vale, ya sabemos que muchas veces a nivel de desarrollo usamos el diseño técnico, pero este documento, gráfico, o cualquiera que sea nuestro diseño técnico, nos vale para detallar la arquitectura del sistema, los componentes,  como se van a comunicar, que tecnologías vamos a usar, y todos los detalles técnicos, pero, a pesar de que este documento es nuestra base de todo, lo que tenemos que tener realmente siempre presente a la hora de trabajar, es la funcionalidad (recordemos, aportar valor al cliente), y es este documento el que tenemos que usar para nuestro trabajo diario, para saber como tiene que funcionar la tarea que estamos haciendo.

¿Y cómo hacemos entonces correctamente un diseño funcional? porque lo cierto es que muchas veces son documentos que no es factible utilizarlos en el día a día del proyecto para el desarrollo, yo, por ejemplo, como muchos ya sabéis, me gusta especialmente SCRUM que lo que hace es que gestionamos ese trabajo del día a día en lo que se llama Sprint Backlog, que sin meterme mucho en detalles de como se genera, no es más que la lista de tareas, descritas a nivel funcional (o técnico cuando así se requiere), de lo que vamos a hacer en una iteración, así cuando un desarrollador coge una tarea a realizar, lo que ve es "En este campo se ha de mostrar un mensaje de error al usuario cuando el valor es incorrecto" y eso es lo que tiene que hacer, y no "página ASP.NET de introducción de datos mediante TextBox, y validación de los campos".

Por supuesto, SCRUM no es los únicos que tienen algo así, existen muchas más opciones, como las tarjetas de eXtremeProgramming, o los paneles de descomposición de tareas (Work Breakdown Structure) que tanto le gusta a mi amigo Enrique Blanco.

Y por supuesto esto es mi opinión, yo personalmente me siento más cómo trabajando sobre la descripción funcional, que sobre los diseños técnicos, que normalmente nos aportan más información sobre la arquitectura, o tienen más posibilidad de interpretación que las descripciones funcionales de las tareas, pero ya digo, es mi opinión.