En ocasiones se remite al Analista Funcional a Guías de Usuarios de distintos sistemas, y otros documentos de muy diversa índole, como fuente única de necesidades y/o expectativas en el Proceso de Definición de Requisitos. Esta circunstancia suele presentarse cuando …

• los usuarios finales son muy dependientes de dichos sistemas,
• los usuarios finales no tienen claro lo que desean,
• los usuarios finales son poco indulgentes asumiendo la programación de horas asignadas para el análisis,
• la comunicación con los usuarios finales es muy lenta,
• la cultura de empresa permite vislumbrar que los usuarios finales no se involucrarán en la elaboración de requisitos,
• la cultura de empresa permite vislumbrar que los usuarios finales no participarán en revisiones o serán incapaces de hacerlo,
• se “invita” al equipo a obtener los requisitos de todas las maneras posibles antes que entrevistar a usuarios y grupos focales.

Reunir requisitos a partir de Manuales de Usuario no es la forma ideal de trabajar. La lectura de la documentación es realmente útil, pero no será suficiente. Si no es posible acceder a los usuarios finales, existen ciertos aspectos a tener en cuenta durante las actividades de análisis.

1. Deshacerse de la sombra del pesimismo: si los usuarios y las distintas las unidades de negocio por parte del cliente están contentos con las características que ofrecen los sistemas actuales, y el nuevo sistema debe ser creado manteniendo dichas características, entonces reunir los requisitos a partir del manual de usuario no es un mal comienzo.
2. Tratar de conseguir una lista de características y beneficios, acudiendo a personas de Organizaciones o sistemas de respaldo, o a la propia Dirección, para conseguir una visión global del problema.
3. Será necesario acudir a otras personas para disponer de una visión más detallada, como programadores encargados del mantenimiento o administradores de los sistemas en cuestión, y hablar de las principales funciones del sistema. No se obtendrán hallazgos acerca de qué funcionalidades son las que realmente aportan valor, pero posiblemente la visión adquirida y el propio juicio permitan obtener una primera aproximación válida.
4. Documentar las características encontradas en la documentación y, a continuación, refinar los hallazgos con diagramas de contexto para determinar el alcance del actual sistema y para identificar las principales funciones y sistemas externos.
5. Los manuales de usuario, en general, no especifican qué reglas de negocio o qué lógica utiliza el sistema para llevar a cabo sus tareas. Por ejemplo: el manual del usuario podría decir: “Para saber la TAE para el préstamo, pulsar [Calcular TAE] en la pantalla Detalles de Préstamo”. Este nivel de detalle es lo suficientemente bueno para el usuario final, pero no lo es para el Analista Funcional dado que será necesario construir un nuevo sistema que calcule la TAE (con su correspondiente lógica y fórmulas para ello).
6. Si en algún momento se percibe algún tipo carencia, defecto o elementos que no están presentes en el sistema actual, serán documentadas y volcadas en un modelo to-be. Priorizar la lista resultante y utilizarla para estudiar otras alternativas existentes sobre soluciones similares al sistema considerado, con las que anticiparse al fenómeno de la Ignorancia, del que ya se ha hablado en posts anteriores.
7. No perder de vista otras fuentes de información; las más útiles: checklist de características pendientes, peticiones de cambio o de mejora en el sistema y especificaciones originales de Requisitos del momento en el que el sistema se introdujo por primera vez, para cotejar con él que todas las características están cubiertas en la forma convenida.
8. Ser capaz de “robar con disimulo” el tiempo de personas que conozcan el sistema. Ir a almorzar con ellos y conversar sobre el sistema en torno al menú del día. En el arsenal de herramientas del Analista Funcional no todo debe girar alrededor de los canales oficiales.

Estas conclusiones apuntan a que los procesos de definición y gestión de requisitos pueden mejorarse enormemente aplicando ciertas buenas prácticas (inspiradas por valores). En el lugar donde trabajo intentamos día a día refinar y mejorar nuestros procesos, y creo que empezar por adoptar ciertas ideas de Scrum y del Product Backlog puede ser un buen punto de partida.

Sin ser un experto en metodologías ágiles, y con mucho camino aún por recorrer, sí vislumbro ciertos valores y prácticas que mejoran los procesos, y que deben acompañarlos en cada fase del ciclo de vida. Concretamente, y en las fases en las que interviene el Analista Funcional, considero interesantes los siguientes valores y prácticas:

• Los artefactos de Análisis deben contener información viva, en continuo crecimiento y evolución, que durante el ciclo de vida se va desarrollando en paralelo con el resto de actividades; de esta forma siempre se proporcionará al cliente el mayor valor posible. Este valor es fundamental, aunque se ha de asumir que los alcances (medidos en necesidades a su vez expresadas en requisitos) son negociables.
• La concepción del negocio por parte del cliente (su visión) ha de ser conocida por todo el equipo. Cuando esta visión sea comprendida por el equipo, sus aportaciones introducirán (o descartarán) funcionalidades, mejoras y tecnologías, permitiendo la detección y corrección de errores de forma prematura, que se incorporarán a los productos de Análisis a través de sucesivas iteraciones del proceso.
• Como resultado de estas iteraciones, el equipo generará una visión real, aún más comprendida y compartida por todo el equipo. Este valor, a su vez, refuerza a las anteriores prácticas.

Esta es mi visión (mía, propia, particular), que espero seguir refinando y mejorando poco a poco (porque será un síntoma claro de madurez) en futuros post sobre cómo materializar estos propósitos y buenas intenciones en el día a día.