Veamos algunas de las solicitudes – delirantes y desesperadas – que garantizan el desastre en el Project Management de cualquier proyecto y gestión de TI.
Para los sistemas de negocios, la fecha en los proyectos que “corren en vivo” realmente importa y los jefes de proyecto parecen dispuestos a sacrificar los límites presupuestarios con más frecuencia de lo que están dispuestos a ir más allá de un plazo programado.
Hay razones comerciales sólidas para hacer esto como lo son bonificaciones, comisiones y valoraciones de las acciones que dependen de los ingresos y ganancias en el trimestre.
Así que usted no desea hacer cambios que pudiera estropear los resultados trimestrales, pero desea implementar cambios lo antes posible del trimestre siguiente. Ahora el problema: tienes un par de días adelante, y la presión de tiempo para cortar y hacer el cambio sólo va en aumento.
Por ello, el índice de inteligencia colectiva del equipo de proyecto sólo disminuirá. Para la semana de finales de julio, todo el mundo estará presionando para un corte y cambios al nuevo sistema para que todos puedan tener sus bonos en el Q2.
Síndrome Caperucita
En el empujón final para el release, en el departamento de Project Management se escuchan todo tipo de sugerencias que están bien intencionadas para tomar un camino que, se supone, es más directo y menos tortuoso como:
- Escatimar alguna prueba de TI y enfocarse en las de integración.
- Realizar pruebas de integración y de aceptación del usuario en paralelo.
- Saltar la configuración del control de sobrecarga.
- Que haga la depuración y las correcciones directamente en producción.
- Saltar algunos de los casos de pruebas más difíciles, sobre todo los de integración.
- Realizar pruebas funcionales sólo para los primeros tres casos de uso.
- Cambiar la prueba (por una más fácil) de aceptación de usuario para los equipos remotos.
- Preocuparse acerca de la calidad de datos después de entrada en funcionamiento.
- Traer un equipo de tigres adicional a su personal.
- Conseguir consultores que trabajen doble turno.
- Olvidarse lo que se está haciendo sobre procesos de negocio en validación y código de comprobación.
- No encender todas las integraciones hasta más tarde y hacer actualizaciones de datos en la noche para mantener las cosas un poco sincronizados.
- Darle vuelta a la instantánea del nuevo sistema que tiene bajo impacto sobre pocos usuarios, por lo que puede demandar la entrada en funcionamiento a pesar de que los usuarios de levantamiento pesados están todavía en el antiguo sistema.
- También necesita algunos recursos ultramarinos de bajo costo para hacer la entrada de triple de los datos que serán necesarios.
- Mientras tanto, los desarrolladores podrán trabajar sólo en la versión real del nuevo sistema en la que no hay ningún usuario.
En (pésima) conclusión
Este es el tipo de cosas por las que se rechaza de inmediato en un solicitante de empleo que los sugiere, pero cuando las ideas vienen de los jefes del comité de revisión completa, bueno… a veces hay que morderse la lengua (y, a veces casi que apagarla).
Todos hemos estado allí. Toda la industria ha estado allí desde los años 60 (“The Mythical Man Month“) y vienen a nuestra mente las historias de horror de versiones ControlData del sistema operativo.
Es particularmente irritante ese pariente del pensamiento mágico que sólo logra descarrilamientos de trenes al decir: “Bueno, ya que estamos en ello, vamos a añadir esta complejidad artificial, aun con el riesgo de que el proyecto salga de control …”
Sólo el equipo Agile más celoso resistirá la tentación de tomar atajos.
Usted puede llamar a esto la estrategia “Potemkin Village”, recordando al famoso acorazado… hundido.
“The dirty secrets of project management revealed” fueron publicados inicialmente en Cio.com
