Por Vanessa Amaya

Es un hecho que sin entendimiento compartido de los requerimientos no hay agilidad que valga, ni cascada, ni río, ni mar. 

No porque entreguemos frecuentemente quiere decir que estamos entregando valor, ese valor está alimentado por la satisfacción de los cliente finales, las necesidades del negocio y  la calidad técnica.

A lo largo del camino he encontrado muchos casos en los que dicen que son ágiles porque trabajan por iteraciones (ah y claro, porque hacen “Dailys” y retrospectivas con show): ¿y dónde queda la entrega de valor frecuente?

En la relación entre REQUERIMIENTOS y VALOR hay mucho trasfondo importante:

• Hay mucho que siempre se puede hacer pero no todo aporta en la misma medida a los clientes finales ni a los negocios.

• Centrarse en el cliente final es una misión no solo de perfiles de negocio sino también de quienes estamos del lado de la generación de soluciones de software.

• Los requerimientos no son obvios, son el resultado de procesos de descubrimiento y como vienen de varias fuentes y son vistos desde múltiples perspectivas lo que puede llegar a ser obvio para el negocio no va a ser obvio para TI (y viceversa).

• Los requerimientos son cada vez más dinámicos porque los negocios también lo son por lo que mantener la vigencia y la relevancia de cada uno es todo un desafío. 

En una estrategia de transformación hay una enorme variedad de puntos a tratar: prácticos, culturales, tecnológicos, sociales, procedimentales y de otras índoles. Pero por algún lugar hay que empezar y algún aspecto hay que elegir para dirigir el esfuerzo. 

Mi sugerencia es elegir lo que tiene que ver con requerimientos y la comunicación que hay alrededor de ellos, créeme que ahí hay muchos temas con que entretenernos, desde lo práctico, lo técnico y lo cultural, pero más allá de buscar la “entretención”, se logran resultados tangibles en las entregas de productos y se mejora la dinámica entre todos los que intervienen con los requerimientos.

Requerimientos & Agilidad

Uno de los 12 principios del manifiesto dice: Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo el proyecto. ¿Qué tanto procuramos que esto realmente se realice?

Escenario 1: “Lo intentamos pero creemos que fue un fracaso total”.

Primero recordar que el fracaso no es absoluto ni el éxito tampoco, en ambos hay matices y para entender los matices antes de pensar que es un fracaso total es vital rescatar las lecciones y descubrimientos detrás de esos intentos.

No es solo poner a personas de frente en la misma mesa, es intercambiar y transmitir información que les dé el contexto completo a todos los involucrados invirtiendo tiempo de calidad, sobre todo: atención de calidad.

Les contaré que supe de alguien que consideró que hacer esto fue un fracaso porque: “los desarrolladores se pusieron a opinar”. Sí, leíste bien, hay quien cree que opinar y colaborar está restringido para algunos roles.

Escenario 2: “No lo hemos intentado porque los responsables de negocio no quieren”.

Es común la confusión entre “pérdida de tiempo” con “inversión de tiempo”. Entendiendo que la agenda tan apretada que un responsable de negocio debe tener, se puede dificultar la convivencia cotidiana con los equipos de trabajo, aquí la cuestión importante es reflexionar sobre ¿Qué tanto afecta al mismo negocio esa falta de convivencia? 

El tiempo y pérdidas que cuestan los errores por falta de entendimiento son mucho más grandes que el tiempo que lleva hacerlo bien. Además, el tiempo reactivo (como gasto) no es estimable y es fuera de los tiempos acordados, en cambio, el tiempo planeado (como inversión) en actividades de análisis colaborativo y entendimientos no impacta a las entregas.

Escenario 3: “Lo intentamos a través de mediadores”.

Con frecuencia se ponen perfiles mediadores entre Negocio y TI, se les ha llamado Business Partners, Analistas, Business Analyst, Project Managers entre otros nombres. Si estos roles cumplen con el objetivo de mediar el cual es mejorar la cultura de diálogo y entendimiento entre personas, está bien, sin embargo, con frecuencia me he encontrado que estos roles se convierten en bloqueadores de la comunicación directa y filtros de información, seleccionando qué debería saber cada uno de los roles involucrados, y así, no funciona.

Los requerimientos no son obvios y vienen de muchas fuentes pero mientras no estén en contexto quien da origen (negocio) y quien hace realidad (desarrolladores) poco avance se podrá lograr.

Escenario 4: “Ya sucede y es genial”.

¿Qué hacemos para entendernos?

La naturaleza del software está alimentada por varias perspectivas, donde las dos principales son las de negocio y las técnicas así que para podernos entender es vital:

• Compartir contextos completos. No burocratizar la información alrededor de los requerimientos.

• Comprender que la especificación de requerimientos (en el formato que sea) representa un consenso entre ambas partes por lo que toda especificación debe de ser CONVERSADA.

• Aterrizar en algún lugar los requerimientos porque con el paso del tiempo el entendimiento puede cambiar.

• Tener presente que los perfiles de negocio pueden tender a identificar lo excepcional y lo crítico y olvidar lo rutinario y detallar al momento de especificar.

• Considerar que una de las mejores formas para especificar y entender es a través de ejemplos.

• Incluir prácticas de especificación más allá de generar prosas en documentos.

Conclusión:

Hay muchos indicadores de “Intención por la agilidad” y “realidades de agilidad”, he visto que la realidad de hacer verdadera sinergia entre responsables de negocio y desarrolladores es un indicador de madurez en agilidad importante.

Vanessa Amaya | Scrum México
Team Member