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 8ª parte del mismo: Ir a 8ª Parte
Torpedo 10. Las entregas de proyecto
“Coste, calidad y plazo… Ahora elija solo dos” Anónimo
La enajenación mental propia del Project manager muchas veces no nos deja ver la gestión de un proyecto como una acción preventiva a medio y largo plazo, sino más bien como un conjunto de acciones a corto plazo destinadas a evitar que el proyecto se nos hunda. Esta actitud sería una buena manera de actuar (es decir, actuar siempre sobre el corto plazo) para hundir nuestro proyecto, pero, dado que el objetivo es comportarnos como profesionales del sabotaje y no como aficionados, es mucho mejor hacerlo a conciencia y controlando cada paso que damos.
Por eso es importantísimo dedicar atención, desde un principio, a las entregas de proyecto (ya sean totales o parciales) porque es ahí cuando los frutos de nuestro trabajo llegan al usuario / cliente final (o al menos a la parte aprobadora) y es en ese momento cuando podemos cubrirnos de gloria entregando material con un bajo nivel de confiabilidad y testeo.
Para poder convertir estos momentos en algo glorioso es necesario ir dando pequeños pasos, recogidos sabiamente en la lista ‘NO’ dedicada a las entregas del proyecto:
- 1. NO prestes atención a las partes interesadas. Esto ya lo hemos visto con anterioridad pero es necesario hacer hincapié en este momento para acentuar su utilidad: No informarse sobre quién es la persona/s que va a realizar los procesos de aceptación de nuestras entregas es vital. De esa manera no conoceremos de antemano sus requisitos, ni las estrategias de validación, ni los procesos de aceptación, ni tan siquiera si existe alguna exigencia de calidad al respecto. Es mejor presentarse en la fecha de entrega sin saber nada de esto… Así se da emoción a la cosa y se crea una impresionante opinión con respecto a nuestra profesionalidad.
2. NO hagas demasiado caso a alguien denominado ‘test manager’. En el caso de que te topes con algún espécimen en tu proyecto y que quiera hacer bien su trabajo de testeo sobre nuestros entregables recuerda siempre una cosa: Es necesario un buen trabajo acerca de la captura y análisis de los requisitos para que los planes de prueba estén bien dirigidos y sean eficaces. Como nosotros habremos hecho sin duda un análisis pobre sobre los requisitos, es bastante probable que las pruebas no sean completas o pasen funcionalidades por alto y ¿qué mejor que llegar a una entrega sin haber ejecutado un buen plan de pruebas?
3. NO elabores documentación de aceptación y entrega. En el hipotético caso de que una aceptación tenga lugar y todo vaya bien (si eso pasa… ejem… ¿A qué estás jugando, amigo?), no tengas preparada ninguna vía formal de aceptación de la entrega. Normalmente con un “vale” oral es suficiente, aunque puedes añadir un apretón de manos o un cafelito de máquina. Si alguien te habla de “Gateways” y de que suele existir documentación asociada para formalizar su realización, aplica siempre la máxima del saboteador profesional de proyectos, ya sabes: conocer e ignorar.
4. NO te dejes sorprender y prepara excusas. Otra de las habilidades del PNP (Project Ninja Professional) es la de saber crear cortinas de humo que desvíen la atención de lo que en realidad está pasando. En lugar de buscar soluciones hay que justificar la mala calidad de tus entregas como sea. En este punto tenemos distintas estrategias a seguir: Transferir o salpicar (“que si el test manager no conoce bien los requerimientos del proyecto”, “que si la gente de TI no aprovisionan como deberían”, “que si es que no tenemos test manager”), Asumir (“que si el equipo ha tenido problemas tecnológicos”, “que si los tiempos están muy apretados”), o Mitigar (“que si en las retrospectivas se solucionarán estos ‘pequeños flecos’”), etc.
5. NO te precipites y caigas en el error de fracasar demasiado pronto. A veces es necesario hacer las cosas mal de poquito a poquito para evitar engrosar la cola del paro demasiado pronto. Planifica tus entregas y calcula de antemano las cosas que se pueden hacer mal pero sin caer en el caos total. Recuerda que un desastre prematuro podría causar tu sustitución y la posibilidad de que alguien recupere el rumbo del proyecto.
6. NO permitas que la culpa caiga en ti. NO asumas responsabilidades por otros y vende a tu equipo. Un truco vil y despreciable pero que funciona a las mil maravillas consiste en culpar a todo el mundo que te rodea de los males existentes y erigirte tú como el salvador de la situación, gracias a tus habilidades de gestión, por supuesto (aunque para esto habrá que hacer algunas cosas bien, y colgarse la medalla pero tranquilo, no importa, el retraso en el proyecto ya estará asegurado). Te recomiendo esto si eres un poco inútil como gestor y no sabes bien por donde tirar.
7. NO dependas de una única vía de escape. Tarde o temprano la situación se volverá insostenible. Si todo tus recursos fallan, es hora de sacar el mejor truco de un PNP:
http://es.wikihow.com/hacer-bombas-de-humo-ninja
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…