Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

¿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.”.

Comentarios
1 Joserra
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.
2 Javier Gómez
3 octubre 2005, 17:11

Como dice Joserra (#1) en su primer punto, los usuarios no siempre comprenden la documentación generada en la fase de toma de requisitos y menos aún en etapas posteriores. De ahí la recomendación de utilizar un “lenguaje natural” al elaborar los documentos en esta fase inicial del proyecto.

Los otros dos puntos que menciona Joserra más que un problema metodológico o de gestión de proyecto, parecen una cuestión “política” o “diplomática”. A veces un buen gestor de proyectos tiene que lidiar con estas situaciones en las cuales no cuenta con todos los recursos necesarios para ganar. Ni que decir tiene que esto sería material para tratar no en un manual de gestión de proyectos sino en un manual de “técnicas de negociación” o a lo mejor en un capítulo comentado del libro de Suntzu.

Mi modesta experiencia me dice que cuando existen “grupos de presión” en el proyecto, es mejor que solucionen el entuerto los “padres de la criatura”. Bastante tiene el gestor de proyecto con los recursos, personas, “deadlines”, planificaciones y demás, para andar culebreando (perdón por el vocablo pero es el más gráfico que he encontrado) y tomando partido por unos u otros. Caso muy distinto es cuando el padre de la criatura es además el gestor del proyecto (pero creo que esto lo dejaré para un artículo posterior).
3 TrickyDicky
5 octubre 2005, 06:14

Una traducción al inglés de este artículo puede encontrarse en:
http://www.zenitservices.com/PlanetaCodigo/Oct2005/FundamentalRequirements.html
Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.