¿Las especificaciones mandan?
En los modelos de desarrollo más difundidos se hace énfasis en las revisiones del sistema de forma que se garantice el cumplimiento de las especificaciones del proyecto, pero…¿Quién revisa si las especificaciones cumplen los objetivos del proyecto?.
por Javier Gómez, 3 octubre 05
Recientemente el director de la NASA, Michael Griffin, ha realizado comentarios en los cuales según su opinión el programa de transbordadores está totalmente equivocado y expresa su creencia de que los planes estratégicos de la NASA perdieron “el norte” en los 70 cuando decidieron terminar con los programas Apollo. Según él, el programa de lanzaderas no tiene sentido alguno pues se basa en naves que sólo pueden orbitar alrededor de la Tierra y no están en línea con los objetivos de colonización de la Luna y de Marte, anunciados por G.W.Bush como parte de su programa electoral.
Esto es llamativo viniendo de un organismo como la NASA, paradigma de la metodología y la tecnología (por no hablar de la ciencia), pero, ¿cuántas veces no se ha vivido esto mismo en el mundo de las Tecnologías de la Información?. ¿Cuántas veces no hemos visto decisiones “estratégicas” que se mantienen contra viento y marea y que acaban conduciendo a sistemas sin relación alguna con los objetivos de negocio que se pretendían cumplir con ellos?.
En algunas de las metodologías de desarrollo se proponen modelos evolutivos de desarrollo (Microsfot y su MSF, o el Modelo CMMI del Software Engineering Insitute, entre otros) en los cuales periódicamente se revisan y evolucionan los sistemas de forma que se garantice el cumplimiento de los requerimientos (objetivos). Pero, esto garantiza el éxito al cumplir las especificaciones, no garantiza que las especificaciones sean las adecuadas para las necesidades reales de los usuarios finales del sistema.
Existen técnicas y herramientas, como JAD entre otras, que permiten automatizar y analizar los requerimientos de los usuarios, y en base a ellas lanzar proyectos de desarrollos más o menos voluminosos y costosos. Dichas técnicas y herramientas, en la mayoría de los casos que yo conozco, o no se usan, o se usan “para la galería” de forma que el posible beneficio que pudiesen aportar para el cumplimiento del proyecto se pierde.
Se han desarrollado innumerables metodologías, técnicas y herramientas para el desarrollo de proyectos que parten del axioma de que La especificación manda. Evidentemente, como en el caso de la NASA comentado, esto puede conducir a situaciones como la del chiste del cirujano que saliendo del quirófano le comenta a la familia del enfermo: “Todo ha ido estupendamente, la operación ha sido un éxito pero el paciente a muerto”.
En mi opinión, convendría seguir ciertas reglas antes de activar los proyectos de desarrollo:
- Someter a un periodo de “enfriamiento” a los promotores del proyecto: A veces, por el entusiasmo de una decisión “afortunada”, se proponen lanzamientos de proyectos que empiezan a tomar velocidad y finalizan en desarrollos inadecuados, cuando hubiese sido más sencillo “mirar alrededor antes de hacer nada nuevo”. Incluso creo que esto es una máxima Zen (muy de moda en el desarrollo actual por otro lado).
- No aceptar nunca aportaciones únicas a la hora de realizar la toma de requerimientos: Si nos basamos en un único punto de conocimiento, podemos estar _“bebiendo de la fuente inadecuada”_. Todos hemos vivido situaciones en las cuales el “experto” asignando al proyecto toma más protagonismo del que debiera y en un afán de mostrar al mundo su sapiencia acaba conduciendo al fracaso más absoluto el proyecto. A veces el modelo de las películas americanas en el que el becario es el que tiene la “idea feliz” ocurre en el mundo real.
- Someter, en la medida de lo posible, todos los requerimientos a un “brainstorming” crítico con los propios usuarios y promotores del proyecto: Estas técnicas a veces funcionan mejor como “filtro de ideas” que como “fuente de ideas”.
- Ofrecer a los usuarios una revisión escrita en lenguaje natural (o semi-natural) de lo que ellos han definido como requisitos del sistema: Esto conduce a que ambas partes (equipo de proyecto y usuarios) empiecen a hablar “de lo mismo” y en “el mismo lenguaje” (lo cual innegablemente reduce la posibilidad de que se desarrolle algo que acabe recibiendo el comentario de “esto no es lo que yo pedí”).
No es que sean la panacea, pero como dicen que decía Napoleón: “Vísteme despacio que tengo prisa.”.
3 octubre 2005, 15:41
Yo he conocido varios problemas con la captura de requerimientos: – Los usuario son incapaces de comprender los documentos generados que expresan lo que ellos han dicho que quieren que hagan las aplicaciones. – Los usuarios no tienen fuerza sobre la gestión del proyecto para “obligar” a que esos requisitos depués se cumplan. – Los requisotos a veces son tomados como ley, y otras veces como sugerencias, según interesen a distintos grupos de presión sobre el proyecto.
Las propuestas del artículo me parecen muy válidas para mejorar el tema, pero a veces hay demasiados intereses en funcionalidades opuestas por personas o grupos diferentes.