Juntas de Requerimientos

Uno de los peores escenarios que puede ocurrir en un proyecto de software, es cuando el cliente descubre que el producto desarrollado y próximo a entregarse, resulta no cubrir satisfactoriamente los requerimientos del negocio. Esto típicamente se debe a fallas de comunicación al levantar y administrar requerimientos, y es un problema común que no suele atenderse de fondo.

 Las juntas o reuniones donde se analizan los requerimientos, suelen ser donde más ocurren estas “fallas de comunicación”. El principal indicador de que una reunión fue poco fructífera, suele ser una posterior avalancha de correos en donde se trata caóticamente de cerrar todos los temas que quedaron pendientes en dicha reunión. Esto además de consumir tiempo valioso, provoca riesgos como cuando dichos correos no son recibidos o incluso ignorados por algunos responsables. Además con el paso del tiempo, los acuerdos en esa avalancha de mensajes se volverán contradictorios y surgirán controversias que tendrán que ser resueltas hurgando entre los correos para ver cual es “el bueno” y ver dónde quedaron los acuerdos definitivos.

 ¿Suena familiar? ¿Son prevenibles este tipo de situaciones? A continuación propongo algunas prácticas, que en la experiencia propia han ayudado a que los requerimientos sean lo más acorde posible con la necesidades del cliente.

Identificar stakeholders

El término “stakeholder” se utiliza para referirse a los actores involucrados o interesados directamente en resolver una necesidad. En un proyecto de TI, se tienen stakeholders tanto del lado del cliente como del proveedor. Por lo general, al contratar un proyecto el cliente ya tiene definido quienes serán los responsables de su lado; sin embargo es importante que nosotros como proveedor identifiquemos claramente los roles que tendrá cada stakeholder. Se puede dar el caso en que el perfil del stakeholder del cliente sea insuficiente para obtener requerimientos claros, y en tal caso necesitamos el apoyo de otros stakeholders que no se tuvieran previstos.

 A continuación listo algunos stakeholders clave para cualquier proyecto de software. Típicamente los primeros dos son del lado del cliente y los otros del lado del proveedor, pero esto puede variar dependiendo de la estructura del proyecto y el equipo de trabajo.

• Dueño del requerimiento. También es conocido como “usuario de negocio”, y es quien tiene el panorama de alto nivel del proyecto y conoce su importancia para la empresa. Es la autoridad final que solicita y aprueba el requerimiento.
• Experto de operaciones. Es la persona que conoce y trabaja con la necesidad operativa que se pretende resolver, por lo que es el más beneficiado con la resolución del requerimiento. Puede ser el usuario final, o el encargado de trabajar directamente con éstos.
• Analista. Es responsable de capturar y administrar los requerimientos. Debe conocer la perspectiva de todos los stakeholders sobre las necesidades que plantean, para así definir los requerimientos que resuelvan dichas necesidades.
• Experto técnico. Es el líder técnico del proyecto. Valida la viabilidad técnica de los requerimientos, arquitectura y plataformas tecnológicas que se utilizarán. También es vital para definir las estimaciones de esfuerzo junto con el analista.

 Hay ocasiones en que el número de stakeholders puede aumentar. Por ejemplo, cuando la operación involucra a varios responsables que actúan de forma aislada, o el proyecto es colaborativo entre varias empresas y proveedores. Es importante ser lo más incluyente posible a la hora de escuchar, a veces la opinión de un usuario o un programador puede ahorrarnos meses de problemas. Una señal de que una reunión de requerimientos ha sido fructífera, es que el analista hace preguntas a todos los stakeholders.

Asegurar capacidad y compromiso

Los stakeholders se suelen asignar de acuerdo a criterios de confianza de cada una de las partes. Esto es un factor humano y debe tratarse como tal, por lo que debemos considerar escenarios en el que uno o varios de los stakeholders no logren cubrir su rol plenamente. En el caso del cliente suele pasar que la persona asignada no conozca de fondo la necesidad que está solicitando o simplemente muestre una actitud poco cooperativa. En el caso del proveedor puede ocurrir que el analista o el experto técnico no estén suficientemente capacitados para ejercer su rol. En cada caso, se debe considerar dentro de las acciones permisibles el reemplazo del stakeholder y de no ser posible esto, tratar que otro de los stakeholders asuma nuevas responsabilidades o apoye al stakeholder que tenga dificultades para ejercer su rol.

Reunir a todos

Otra causa común de requerimientos fallidos y consecuentes avalanchas de correos, es que alguno de los stakeholders no haya podido estar presente en la reunión de requerimientos. Entre más se fragmente la reunión, más volátiles serán los requerimientos que surjan de estas.

 Cualquiera que haya estado en juntas de requerimientos sabe lo difícil que es lograr reunir a todos los stakeholders en una sola sesión. Incluso con la ayuda de interfaces de teleconferencia, quizá no todos puedan estar disponibles en una hora específica. Sin embargo es preferible priorizar el éxito de esta reunión a tener que realizar posteriormente penosas juntas de renegociación en las etapas tardías del proyecto.

Análisis de causa raíz

El cliente suele conocer sus necesidades, pero su idea de cómo resolverlas no siempre es la más adecuada; es aquí donde requiere ayuda del analista. A veces el cliente nos proporciona un requerimiento muy específico y parece que solo hay que seguirlo al pie de la letra. Sin embargo, al igual que un mal médico, un mal analista hace solo lo que el cliente le pide.

 El objetivo del análisis de causa raíz es definir los requerimientos que realmente resolverán las necesidades del cliente.

 Una técnica efectiva que recomiendo aplicar en el análisis de causa raíz es la de “los 5 por qués”. Básicamente consiste en cuestionar el por qué de algo, de manera iterativa, hasta encontrar una causa raíz. El “5” del nombre se refiere al número de iteraciones que típicamente se requieren para llegar a una causa raíz. Sin embargo, en proyectos de software suelen bastar 2 o 3 “por qués” para dar con el problema.

 Veamos un ejemplo de esta técnica aplicada a un caso real que me tocó vivir:

Cliente: “Necesitamos que el usuario del sistema A pueda generar únicamente cada viernes un informe de la base de datos y dicho informe se guarde en un archivo accesible por FTP.”
Analista: “¿Por qué necesitan subir el informe cada viernes?”
Cliente: “Porque cada lunes la gente del área X descarga el archivo.”
Analista: “¿Y por qué el área X tiene que descargar el archivo.”
Cliente: “Para imprimirlo”
Analista: “¿Y por qué imprimen el informe?”
Cliente: “Porque el área X necesita capturar los datos de ese informe en el sistema B.”

 Como se puede ver, bastaron 3 “por qués” para darse cuenta de que lo que realmente necesitaba el cliente no era el barroco procedimiento que solicitaba al principio, sino más bien desarrollar una transacción de datos automatizada entre el sistema A y el B. En la misma conversación, el cliente se puede dar cuenta de qué es lo que realmente necesita y los ahorros potenciales de tiempo y dinero para ambas partes se vuelven evidentes.

Mockups

Otra técnica que tiene mucho éxito en las juntas de requerimientos es la de presentar Mockups, es decir maquetas de cómo será la interfaz gráfica del usuario basándonos en los casos de uso. La ventaja inmediata es que se cierra la brecha de tecnicismos y se logra establecer un lenguaje común entre todos los stakeholders.

 En casos en los que la GUI resulte muy compleja, o se pretenda desarrollar un sistema para dispositivos móviles, es recomendable que el equipo cuente con alguien que tenga habilidad en UXD (User Experience Design).

 Asegurar el entendimiento

Conclusión

Finalmente, es bueno reflexionar sobre la cantidad de tiempo que tanto el cliente como el proveedor de TI están dispuestos a invertir en el análisis de requerimientos. Es frecuente encontrarse con stakeholders que tienen la sensación de que el análisis es improductivo y quita tiempo valioso al desarrollo. A veces nos lleva tiempo aprender por las malas las consecuencias de un análisis escueto y apresurado. Aquel tiempo que inicialmente creíamos haber ganado apresurando el análisis, se revierte por triplicado en demoras por requerimientos indefinidos o mal comunicados. Incluso, en organizaciones de baja madurez se asume que este tipo de situaciones son normales.

 Dedicar el tiempo necesario al análisis de requerimientos siempre nos ahorrara muchas horas de codificación y permitirá ofrecer soluciones más satisfactorias al cliente.