De acuerdo al ensayo de Shelley Cudly “Improving Business Analysis Processes”, solo un 25% de las empresas a nivel mundial operan con un alto nivel de madurez en sus procesos de gestión de requerimientos[1]. Las estadísticas relativas a las razones de porqué los proyectos fallan, apuntan a una abrumadora necesidad de mejora en los procesos de requerimientos y análisis de negocios. Los pobres niveles de madurez indican que las organizaciones no han resuelto el problema de la mejora de los procesos de análisis de negocio[2].
[1] Heembrock, P. Hittin the Mark: The Impact of Requirements Maturity on Project Outcome. IAG Consulting (2009)
[2] 70% de las organizaciones reconocen que los requerimientos son importantes para el éxito del proyecto pero fallan al tomar acciones apropiadas. Ellis, K. Diagnosing Requirements Failure. IAG Consulting (2009)
_________________________
Un mejor resultado de los proyectos es la preocupación principal de todos los involucrados en el trabajo del proyecto. De hecho debería ser la preocupación de la organización entera. La mejora de los procesos es una actitud mental que, una vez adoptada, creará el ambiente que continuamente generará valor y éxito en los proyectos.
La mejora de los proyectos y requerimientos significativa y duradera, no es simplemente el resultado de procesos sólidos sino también del desarrollo de las personas y sus habilidades para soportar esos procesos.
¿Por qué Preocuparse?
¿Por qué invertir tiempo enfocándose a los requerimientos, las personas y los procesos que los soportan? Si has leído acerca del tema de requerimientos seguramente te has encontrado con docenas de artículos que explican la fatal situación de los proyectos de tecnología. Se encuentra en todas partes documentación acerca de las fallas de la tecnología y existen muchos intentos de cuantificar la naturaleza de las fallas. Mientras ha habido algunos cuestionamientos acerca de cómo definir las fallas de los proyectos, la evidencia sugiere que es «una incapacidad para producir confiablemente resultados exitosos en los proyectos»[3].
[3] Diversos estudios definen la falla de un proyecto como cualquier desviación de la línea base del proyecto, lo cual podría decirse que desvirtúa los resultados.
_________________________
Planeación y programas mejorados
Mejores requerimientos conducen a una mejor planeación del proyecto, estimación de costos y estructuras de descomposición del trabajo[4] (WBS – por sus siglas en Inglés). Utilizando métodos establecidos de elicitación y una buena relación con los stakeholders conducen a un mejor entendimiento de los requerimientos los cuales requerirán pocos cambios a lo largo del ciclo de vida.
[4] La escasa especificación de los requerimientos es una de las causas de la pobre estimación de los costos del proyecto. Davis, A.M. 201 Principles of Software Development, New York. McGraw Hill. El promedio de proyectos con una pobre especificación de los requerimientos rebasan la cantidad de tiempo esperada en un 200%. Ellis, K. Things You Need to Know About Requirements Planning. IAG (2010)
________________________
Menos gasto / menos costo / menos retrabajo
El retrabajo en los requerimientos atrasan el proyecto[5]. Los requerimientos descubiertos de forma tardía en el ciclo de vida conducen a excesos en el proyecto, el programa y costos del proyecto[6]. A la inversa, los proyectos con una alta calidad en los requerimientos tienen pocos cambios lo cual resulta en menos retrabajo y menos costos.
[5] Hay un 60% de prima adicional de tiempo y costo a pagar por proyectos con una pobre calidad en los requerimientos. Ellis, K. Assesing the Impact of Poor Requirements on Companies. IAG Consulting (2009).
[6] Los problemas de los requerimientos comprenden el 40% de todos los errores dentro de un proyecto y el costo de arreglar esos errores es muy alto contabilizando de un 70% a un 80% de costos de retrabajo. Leffingwell, D. Calculating your return of investment from more effective requirements management. 26 February 2011. Mientras más tarde se encuentre el error en el ciclo de vida mayor es el costo de reparar el error costando hasta 10 veces más si se corrige durante las pruebas y por encima de 100 veces más una vez que el sistema está en operación. Grady, R. An Economic Decision Model: Insights into Software Project Management. Tener correctos los requerimientos pronto en tu proyecto puede ahorrarte al menos un tercio del presupuesto total del proyecto. Hooks, I & Ferry, K. Customer Center Products: Creating Successful Products through Smart Requirements Management. New York (2001)
__________________________
Calidad en los requerimientos conduce a calidad en el software
Realizar cambios al código debido a requerimientos tardíos, resulta en el deterioro de la calidad del proyecto[7].
[7] Requerimientos faltantes y ambiguos contribuyen con un tercio del total de los defectos del proyecto. Lausen, S & Vinter, O. Preventing Requirements Defects: An Experiment in Process Improvement. Requirements Engineering Journal (2001). Los Procesos de los Requerimientos son la fuente de la mayoría (50% o más) de los problemas de calidad serios. Weinberg, G.M Quality Software Management: Anticipating >change. Dorset House Publishing Company (1997)
_________________________
Otras cosas que considerar
Mejorar el proceso de requerimientos es esencial y si la información anterior no le convence, he aquí algunos otros aspectos a considerar:
La documentación realizada no concuerda con la realidad
Cuando se tiene la documentación suficiente para soportar el esfuerzo de pruebas, esta frecuentemente no concuerda con la solución entregada por TI. ¿Porque? Porque nadie ha manejado los requerimientos después de que fueron inicialmente entregados o lo requerimientos fueron insuficientes o se incorporó información adicional al proyecto fuera del proceso de requerimientos. Con frecuencia los otros procesos del proyecto no están bien sintonizados y no existe una transferencia formal de los requerimientos o no existe una validación del entendimiento de su contenido. Sin una apropiada revisión y validación de los requerimientos y una administración subsecuente de los mismos, las actividades de los desarrolladores no siempre coinciden con lo que se está presentando en la documentación. Los ingenieros de pruebas no saben quién está en lo correcto o que es lo que hay que probar y no tienen tiempo para ordenar todo de forma que se concretan a hacer su mejor esfuerzo.
Muchos defectos en post-producción
Como puede imaginar, lo anterior no asegura que los módulos o las piezas de código serán probados a fondo y verá muchos defectos cuando ese código sea llevado a producción
La necesidad de negocio no se satisface
Algunos defectos no son considerados problema por el equipo de desarrollo (el código fue “diseñado” para hacer eso) pero sí son considerados como defectos por parte del usuario porque el producto no está entregando el valor de negocio que se requiere. El analista de negocio se dedica entonces a tratar de determinar porque algo fue diseñado y no está alineado con la necesidad de negocio y tiene que defender al área de TI, el proceso defectuoso y la entrega no adecuada. Enfrentar a clientes insatisfechos nunca es divertido. Hazlo suficientes veces y tu grupo de TI se ganara una mala reputación.
Conclusión
Cada organización tiene sus historias de proyectos dolorosos y entregas fallidas. Los procesos de proyectos bien sintonizados conducen a más proyectos exitosos, así que la pregunta de fondo es, ¿Por qué no preocuparse por la mejora de los procesos de gestión de los requerimientos?
Como siempre, te invito a dejar tus comentarios y observaciones.
Definitivamente una gestión adecuada de los requerimientos impacta profundamente y de manera positiva en el resultado del proyecto. Desafortunadamente esta no es la percepción de muchas organizaciones que consideran esto como un gasto innecesario. El contar con la medición de los resultados de un antes y un después de implantar una gestión de requerimientos adecuada, puede darles mucha luz y convencer a la organización de tomar este camino. Adicionalmente desde luego es indispensable no perder de vista la Gestión del cambio y la Mejora continua que son parte vital en para que los procesos den el mayor valor posible a la organización.
Gracias por esta interesante información!
Es correcto tu punto de vista Alejandra, independientemente de si tenemos o no en este momento los procesos para un adecuado control y seguimiento de los requerimientos, es importante empezar a medir los procesos actuales para poder comparar los beneficios cuando se tengan implementados los nuevos procesos ya con una mejor gestión de los requerimientos. Te agradezco tus comentarios y quedo a tus órdenes.
Es necesario que las juntas que se hagan se definan minutas, no dar por entendido sin un documento firmado por las partes involucradas, la gestión de requerimientos debe de tener el WBS y cualquier cambio que involucre un costo deben estar enterados las partes involucradas. Todo cambio imprevisto se debe de notificar.
Hola Pablo: En efecto, idealmente debemos de tener un mayor control sobre todas las actividades relacionadas a la gestión de los requerimientos, pero independientemente de documentar y controlar, me parece importante establecer puntos de verificación o checkpoints a lo largo del proceso con la finalidad de ir verificando paso a paso que las acciones de control se cumplan. Muchas gracias por tus comentarios! Saludos.
Hola Gabriel
Que técnica recomiendas para reconocer los requerimientos de negocios.
Cuando uno se entrevista con el experto de negocio(la persona que necesita el software).
Las historias de usuario es fundamental para comenzar a diseñar una solución de negocio, como sacarle provecho a esas entrevistas con el experto del dominio.
Tienes alguna técnica para sacarle el máximo provecho a esas historias de usuario.
Hola Pedro: En realidad es una mezcla de técnicas las que puedes utilizar para recolectar la información. Una de ellas es la Entrevista, otra más es el Modelo Funcional, el Modelo de Procesos, La lluvia de Ideas y el Modelado de la Organización. Otras más que ayudan mucho son la de Observación (job Shadowing) y el Modelado Entidad-relación. Espero que esto te sea de utilidad. Saludos.