Jose María González López
Project manager y Fundador de Habilis Software http://www.habilissoftware.com/
Continúa la serie de artículos que forman el decálogo para hundir proyectos no sin antes referenciar la 1ª parte del mismo:
Torpedo 3. Análisis de requisitos
Durante el hundimiento profesional de un proyecto, los procesos de análisis de requisitos y de las reglas de negocio, son una inversión a futuro. El autentico maestro sabe que, en el océano del conocimiento, unas pocas ondas causadas hábilmente, se convertirán el maremotos si los dejas crecer.
Con esta 'peaso' de frase en mente, ahí va el primer consejo: No hay nada como descuidar un requisito importante o no tener tiempo para su seguimiento (incluso de esos que nos dan al principio...si....los estratégicos...), para llevar los problemas al punto más crítico de cualquier proyecto: la validación.
Si queremos empezar con buen pie en la elaboración de esta delicada "bola de nieve" tendremos que tener en cuenta que, en estas tareas de análisis y documentación, normalmente habrá involucradas más personas que querrán hacer bien su trabajo y dificultar (incluso anular) nuestra sutil labor, así que no te desilusiones si no consigues a la primera los objetivos. Un arma poderosísima contra éste tipo de enemigo que puedes utilizar son las suposiciones. Sobre todo en las cosas más simples.
Durante los análisis las suposiciones vienen y van, se crean y se destruyen, se transforman... Una labor de primer orden es tratar de que sean numerosas y que se mantengan indefinidas y que, nadie, repito, nadie, se interese por definir en cómo afectan dichas suposiciones al proyecto y a sus requerimientos. Mantener indocumentadas y en el olvido un buen número de suposiciones sin definirlas totalmente es abrir la puerta de la ambigüedad y disponer de más lastre para hundir el proyecto.
Una técnica estupenda para qué empiecen a aparecer suposiciones, y de paso, que los análisis sean prácticamente incomprensibles, es abordar el análisis de requisitos y reglas de negocio desde el detalle y la diversidad pero sin dotarlo de un sentido global que pueda ayudar en su posterior comprensión. Orienta los talleres facilitadores y las reuniones a tratar muy en detalle solo unos pocos temas dejando todo lo que puedas para las últimas sesiones (cuando no quede más tiempo ni para tratarlas ni para ordenar todo debidamente). Tampoco tengas en cuenta el nivel organizativo de los participantes en las reuniones que mantengas, se desordenado y trata temas técnicos cuando tengas oyentes ejecutivos. Haz que la gente de negocio piense que pierde el tiempo reuniéndose contigo y tendrás la clave para que empiece a faltar información en el proyecto. También huye de la idea racional de estructurar la información y tratar de capturarla de un modo ordenado, esto solo hará que las cosas se entiendan bien. Por último, nunca elabores actas de reunión para recordar puntos abiertos o conclusiones.
PREDICA CON EL EJEMPLO: Haz tus propias suposiciones en las cosa más simples. ¿El cliente es exigente?: Entonces da por supuesto que no dispone de plantillas para la elaboración de la documentación de proyecto y que aceptarán sin dudarlo la tuya, con su formato, su estructura desordenada y su presentación pobre. Asume que siempre estará dispuesto a reunirse contigo, las veces que hagan falta, cuando se lo pidas y que rápidamente validará y aceptará toda tu documentación en solo tres días.
Por supuesto, tarda lo máximo posible en elaborar la documentación que refleje tu análisis y no trates de darle una presentación adecuada y profesional y mucho menos de hacerla fácilmente entendible. Con un poco de suerte te rechazarán todo en el último momento y te verás obligado a rehacer la gran mayoría de los documentos antes de empezar si quiera a hablar de aceptación y validación.
Un importante detalle es que, todas las partes interesadas que hayas ignorado durante la preparación del torpedo número 2 tienen que permanecer aún en el anonimato. Si consigues que no participen en esta fase de análisis y que solo den su opinión cuando el proyecto (o el producto) esté ya terminado, habrás puesto un estupendo iceberg en el rumbo de tu proyecto. (Vamos, que vayan preparando salvavidas...). ¿Cómo conseguirlo?, repite conmigo: No involucrar... no involucrar... no involucrar... ¿Qué alguien tendría que validar y aprobar la documentación (extensible a los entregables)?... Sí. Claro. Pero no te preocupes por quién ha de hacerlo, ya aparecerá de manera espontánea (y con todo el tiempo del mundo para darte).
Todas las técnicas y metodologías que traten de ir asegurando gradualmente el cumplimiento de los requisitos tienen que manejarse con cuidado. No olvidemos que a la mínima que seamos eficaces podríamos hacer que el proyecto tenga éxito y eso sería nuestro fracaso... Empápate cuanto puedas de las metodologías tipo Scrum, Agile,... todo lo que suponga ciclos controlados de validación y flexibilidad en los cambios te puede perjudicar. Para nuestro oscuro propósito sólo hay un arma mejor que el conocimiento como tal: conocer e ignorar (y por ése orden).
Por último, las herramientas de ayuda en la gestión de los requisitos y el conocimiento hacen un daño tremendo. Mantén cerca de ti estas tecnologías para conocerlas y saber cómo reducir su efectividad pero nunca permitas que la flexibilidad de herramientas de productividad como PMP Mobile Suite-Requirements Management para Android (https://play.google.com/store/apps/details?id=com.PMPMS.RM&hl=es) se contagie a tu proyecto y ayude a su éxito.
En resumen:
- Intenta descuidar algún requisito importante o, al menos, no te intereses por su ciclo de vida. No documentes requisitos.
- Pon todo tu esfuerzo en que aparezcan suposiciones con efecto de bola de nieve (esto es, que causen problemas que crezcan como un tamagochi). No las documentes.
- Juega al despiste. No traces una estrategia clara para la captura y estructuración de la información y de las reglas del negocio de tu cliente. Usa el trabajo en detalle (excesivo a poder ser), desordenado y sin un hilo conductor común. Nada de top-down.
- Haz tus propias suposiciones y conviértelas en propias del proyecto (se recomienda trabajo conjunto con el punto 2)
- Tómate tu tiempo. Recuerda que el cliente valida muy rápido así que no importa si te retrasas un poco en entregar la documentación a validar (nótese el sarcasmo).
- No involucrar..., no involucrar..., no involucrar...
- Conocer e ignorar
Nota: El autor del presente artículo no se responsabiliza del mal uso de la información aquí recogida ni del hecho científico probado de que, en determinados cerebros, la psicología inversa no funciona...