El  ABC de un Taller de Requerimientos.  Parte1

                                  Por: Mónica Alegría Vázquez.

Cuando estamos planeando un proyecto de desarrollo ya sea nuevo o híbrido el sistema, las técnicas a emplear para concebir lógicamente la automatización de una solución de negocio son implícitamente pensadas, dentro de cualquier proceso definido y por las múltiples metodologías es difícil encontrar: ¿Cómo capto requerimientos de una manera eficiente y eficaz? Terminando este párrafo lo primero que se viene a la mente son los CASOS DE USO, pero nos falta un paso.

De ese mundo que hay, ¿cómo voy aterrizar de una manera concreta?:

·         Necesidades de negocio ó sistema

·         Reglas de negocio

·         Requerimientos(usuario,sistema,hardware,etc)

·         Casos de uso

·         Casos de prueba

·         Manuales                                 

·         PRODUCTO                                  

Una técnica recomendable de capturar ese “implícito” es el taller de requerimientos, el cual permite conocer las necesidades de los stakeholders y de los tomadores de decisiones; reduciendo en promedio un 50% el tiempo de levantamiento de información, involucrando y comprometiendo a los usuarios de principio a fin; logrando una colaboración por el dueño(s) de la solución.

Todo analista experimentado nunca debe olvidar la premisa “El negocio rige el sistema” nunca al revés.

El primer paso es identificar y/o verificar ¿quiénes son los sponsors, decision-makers, stakeholders, y los usuarios representativos?.

Una vez identificados, debemos asegurarnos que se encuentren dentro del plan de comunicación del proyecto, para asegurar el compromiso y comenzar con el flujo natural de retroalimentación. Claro respetando el marco metodológico que se esté aplicando, como breviario cultural el líder de requerimientos debe reflejar las actividades posteriormente expuestas en el plan inicial del proyecto.

Lo que prosigue es la planeación del taller, se escribe fácil pero implica lo siguiente:

Premisa1: Asegurar que en la primera sesión el sponsor del proyecto esté presente.

Premisa2: Conjuntar a los principales stakeholders en la primera sesión.

Premisa3: Asegurar la participación de los usuarios principales durante todas las sesiones.

Premisa4: El Project manager del proyecto NO asiste a los talleres.

Premisa5: El DevTeam tampoco participa dentro de los talleres.

Premisa6: El facilitador del taller debe ser un ingeniero de requerimientos experimentado (líder de requerimientos en el proyecto) puede contar con la ayuda de máximo dos analistas, dependiendo del número de participantes.

Premisa7: El número máximo de asistentes recomendado es de 15 personas.

Antes que nada, se debe planear cuidadosamente, una agenda donde en la primera sesión se cubran los siguientes puntos:

1)    Necesidades de negocio

2)    Requerimientos Generales

Ejemplo Agenda(planeación 4hrs primera sesión)

10 minutos Presentación, logística evento

5 minutos   Reglas de grupo

1.30 hrs     Detección de necesidades

15 minutos Receso

15 minutos Retroalimentación de lo encontrado

45 mintos   Reducción de ideas

15 minutos  Receso

30 minutos  Detección funcionalidad general

15 mintos    Cierre primera sesión

Partamos de la suposición de que es un desarrollo nuevo no mayor a 4 meses, debemos entender el contexto del negocio para ese nuevo desarrollo que se traduce NECESIDADES DE NEGOCIO.

También como suposición optaremos de utilizar como técnica de extracción la  LLUVIA DE IDEAS dentro del grupo, pero esta solo es recomendable cuando se tenga una amplia experiencia de manejo de audiencia como moderador.

Para emplear esta técnica utiliza un grupo en forma circular, nunca de auditorio, simula una mesa redonda donde los stakeholders con orden expondrán la necesidades que ellos consideran que debe satisfacer el sistema.

El moderador se abstendrá de intervenir en proposiciones de solución, simplemente mide tiempos y traduce la información que se está dando a lo que se tiene planeado durante las sesiones.

Para la utilización de la lluvia de ideas la principal regla es  “DEJAR QUE LA IMAGINACION FLUYA CON TODA LA LIBERTAD,

ya el mismo grupo determinará la viabilidad de sus peticiones y tomará las decisiones pertinente de las implicaciones.

Regresando a materia, para captar las necesidades de negocio tendremos que cumplir con este proceso básico:

                                           Fig1.

Es recomendable manejar diferentes elementos visuales como apoyo durante nuestras sesiones del taller o talleres. A continuación menciono algunos elementos que pueden utilizarse:

Para alguien que inicia con los talleres recomiendo dibujos, posters mezclados con diagramas de flujo sencillos para una primera sesión.

Los participantes también podrán aportar con sus propios elementos visuales.

Debemos tomar consciencia que nuestros participantes no deben por que tener como obligación entender y saber ¿qué es un diagrama de caso de uso?, ¿qué es un actor?, etc, por lo que durante la ejecución del taller todo lo expuesto será para que todo sea entendible para cualquiera y se determine de manera general ¿qué debe hacerse?, el ¿cómo? es la parte técnica que no forma parte de un taller de requerimientos.

Hay que estar conscientes que dentro de las necesidades se captaran reglas de negocio, las cuales deben manejarse de forma independiente, y se expondrán a su debido tiempo.

Extraordinariamente de las metodologías y los entregables a priori concebidos y planeados, el taller de requerimientos genera sus propios entregables de una forma iterativa que alimentarán a ese output metodológico. Ver fig2.

                                 Fig2.

Una vez aseguradas las necesidades de negocio las cuales no pueden resultar en un número exagerado, tendremos que parar y hacer una retroalimentación con nuestro grupo utilizando la Reducción de ideas, estas deben irse reflejando de manera visual para el auditorio e ir almacenando el contenido en un documento que bautizaremos como “Resultados del Taller”, por lo pronto tenemos un acercamiento general de las necesidades, reglas de negocio aisladas, palabras para el glosario, y una que otra funcionalidad.

Las necesidades de negocio debemos irlas captando de una manera jerárquica que de ella partan y se justifique toda la funcionalidad y no funcionalidad del nuevo sistema.

En el siguiente artículo se ejemplificará un documento de resultados de taller y con los siguientes pasos.

Hasta nuestra siguiente lección……..