Requisitos de usar y tirar
Que nadie piense que voy a hablar de una aproximación hacia la captura de requisitos que tenga similitud alguna con los prototipos de usar y tirar. Ni siquiera es post va de cómo manejamos los requisitos en las metodologías ágiles y Scrum. De lo que voy a hablar hoy es de una situación que me estoy encontrando a menudo, sobre todo en equipos con cierto nivel de madurez, que escriben elaborados documentos de requisitos. No se porque algunos tienen la extraña idea de que madurez y documentos de requisitos infumables deben ir de la mano.
Cada vez más y más equipos que 'oficialmente' se encuentra en organizaciones CMMI, se interesan por la agilidad. En estos equipo, y según mi experiencia, que no es una muestra muy amplia de momento, todo hay que decirlo, encuentro un problema habitual en la gestión de los requisitos.
Las manifestación más claras de este problema es tener diferentes documentos, elaborados por diferentes grupos del equipo de proyecto, que dicen ser la fuente última de verdad sobre los requisitos.
La situación suele ser parecida a la siguiente:
Un grupo, bien ubicado en el departamento de Marketing o en el de Product Management escribe una especificación de requisitos. Esta especificación de requisitos es un documento con un buen puñado de páginas. Generalmente estos requisitos están expresados siguiendo una plantilla de documento, con una serie de campos. Luego este documento se pasa a los desarrolladores, para que lo asuman como fuente de verdad y validen su contenido desde diferentes puntos de vista.
Aquí están los desarrolladores, enfrentándose a un documento formado por cientos de páginas que deben leerse, que básicamente consisten en un motón de aburridísimos formularios. ¿Alguien cree a estas alturas que los desarrolladores se van a leer ese tocho? Ni por asomo. Yo he tenido que leerme ese tipo de documentos y sinceramente, tengo que reconocer que nunca lo hice con el más mínimo interés. Es que leer formularios es muy aburrido.
¿Qué hacemos los desarrolladores en lugar de leernos decenas de aburridos formularios? Defendernos para no tenerlo que hacer. La defensa suele ocurrir de dos maneras: o nos escudamos en las carencias que todo documento tiene para evitar tenerlo que leer y proponemos continuas mejoras o proponemos crear un nuevo documento. Tenemos un nuevo documento, que expresa los mismos requisitos desde el punto de vista de los desarrolladores.
Aquí están los Product Managers o analistas funcionales o lo que quiera que ponga en su tarjeta, enfrentándose a un documento formado por cientos de páginas de incomprensible jerga técnica alejada totalmente de las necesidades del negocio. Y que hacen… protegerse como lo hicieron los desarrolladores.
En cualquier de los casos, nos vemos en la situación que yo llamo requisitos de usar y tirar… de tirar contra otros implicados en el proyecto. Requisitos que se acaban convirtiendo en un arma arrojadiza entre dos grupos de implicados en el proyecto. He puesto aquí el ejemplo de desarrolladores y Product Managers, pero esta situación también se da entre organizaciones, entre proveedores y clientes.
Lo peor, es el tiempo de proyecto que se pierde en este baile de requisitos arrojadizos… y que se podría estar empleando en un motón de cosas útiles.
¿Cuál es el antídoto para esta situación? Usar un lenguaje común, el lenguaje natural para expresar los requisitos, lenguaje simple y llano que todos los implicados entiendan. Y hacer los requisitos divertidos… vale, vale, ya se que los requisitos nunca pueden ser divertidos… pero no tienen por que ser una colección de aburridísimos formularios que se rellenan solo por sistema. Otra aproximación fallida, es la visión de los requisitos como algo jerarquico. ¿Alguien es capaz de leerse una jerarquía de lo que sea? ¿Es posible conocer la historia de una familia viendo su árbol genealógico?.
Evidentemente, lo anteriormente dicho excluye a UML y los casos de uso como herramientas ágiles a la hora de especificar un sistema. Las metodologías ágiles proponen usar historias de usuario o escenarios como alternativa. No es que sea lo más divertido del mundo leer requisitos escritos como historias o escenarios, sigo prefiriendo una buena novela, pero sin duda es infinitamente más divertido que leer casos de uso o jerarquías de requisitos.
Solo si logramos que leer nuestros requisitos no sea una tarea titánica lograremos que los clientes, los desarrolladores y los Product Managers dejen de usarlos como un arma arrojadiza y lo empiecen a utilizar como un artefacto útil que facilite la construcción del sistema que se necesita.
¿Vamos a poner esfuerzo en hacer de los requisitos algo manejable o vamos a seguir a garrotazos?