Reglas básicas para hacer fracasar tu proyecto

Leído esta mañna en XING.com (dirigido a los jefes de proyecto)...

Haciendo limpieza he encontrado un abstract que no llegué a presentar en ninguna conferencia. No está pulido, pero tiene su gracia.

Por Juan Carlos Sánchez Mirabal

Este resumen detalla las malas prácticas que se pueden aplicar a un proyecto de manera que ni el coste ni la calidad sean aceptables. Obviamente la lectura debe hacerse con tono sarcástico.

La garantía es completa. Siguiendo minuciosamente mi plan será imposible que vuestro proyecto se ajuste a las necesidades de presupuesto, calidad o plazos. Este manual de malas prácticas consta de los siguientes apartados:

Relación con el cliente. Tenemos dos alternativas de trato para fracasar estrepitosamente. La primera es tratar al cliente de ESTÚPIDO y la segunda creer que es DIOS y poseedor de la verdad absoluta. Ambas nos harán profundamente desgraciados y nuestros proyectos subirán en coste.

Especificaciones funcionales. Tenemos tres alternativas: No escribirlas nunca, escribirlas al final o en el otro extremo detallar hasta el último detalle más insignificante.

Planificación del proyecto. Para cumplir nuestros objetivos es mejor no planificar. Es más, cuando alguien pregunte sobre el tema disimulemos y hablemos de otra cosa. Como si no hubiera dicho nada. Cuando alguien tenga prisa ya correremos.

Arquitectura y diseño. ¡Que nadie pierda su tiempo con esto por dios! Esta actividad puede generar grandes beneficios que revertirán en el coste, no solo del proyecto en curso si también de otros. Una actividad a evitar siempre que sea posible.

Revisiones. Cuantas menos mejor. Todo el mundo debe ser capaz de hacer las cosas mal a la primera. No necesitamos que nadie empeore nuestro trabajo.

Análisis Estático y Estándares de codificación. Esta actividad la podemos realizar completamente automatizada, siempre que no asignemos ningún responsable de supervisarlos ni ninguna actividad asociada. Así gastaremos dinero en una herramienta que no aportará beneficios.

Pruebas unitarias. Aquí surgen otra vez dos opciones. Una es no hacerlas, claro, pero otra mejor es hacer development driven testing, es decir, escribir el código y luego los test unitarios que NO fallen.

Integración continua. No hacerlo bajo ningún concepto. Es una actividad muy rentable. Mejor esperar al final del proyecto, juntarlo todo y disfrutar de los fuegos artificiales (pum, pom, plas, runtime,...)

Test funcional. Solo hay una cosa mejor que no hacerlo. Hacerlo después de entregar la versión y luego ignorar los defectos que se encuentren ya que el cliente no los ha visto (aún). A ser posible no decirle nunca al equipo del test las nuevas funcionalidades y en caso de que nos fuercen a ello hacerlo en las release notes (o lo más tarde posible).

Mantenimiento. Poner a un becario a mantener todo el código si es que después de todo conseguimos llegar hasta aquí.

Esta presentación tiene como objetivo defender las buenas practicas desde la perspectiva del absurdo. Algunas de las exageraciones comentadas nos parecerán un disparate, pero nos harán reflexionar sobre nuestras actuaciones, decisiones o planificación de los proyectos y sobre todo incidir en los costes que resultan de aplicar las malas prácticas y como la calidad ayuda a reducirlos.