Causas del "MANEJO" o dícese de "LA FALTA DE TRANSPARENCIA"

Siempre que tengo la oportunidad de dar clase, facilitar una charla o compartir con un grupo de desarrolladores de software pregunto:

¿Quiénes de ustedes han visto decir mentiras a su gerente/líder de proyectos?

o les pregunto a los gerentes de proyectos presentes:

¿ustedes dicen mentiras en sus proyectos?

La respuesta lamentablemente en ambos casos es abrumadora, es un rotundo 

SI   :(

Hemos visto decir en la gerencia tradicional frases como:

• a esto hay que "darle manejo"
• el avance es del "tanto" por ciento pero digamos mejor que es este otro número
• o la típica sensación de que decimos que vamos en el 90% y nos demoramos otro 90% para terminar el 10% que supuestamente nos faltaba

Pueden haber varias causas dignas de investigación, sin tener datos fiables pero de acuerdo a mi experiencia y a la de mis colegas diría, que la causa principal es que 

"el proyecto se salió de control"

y es probable que sea considerado usted un mal gerente de proyecto o la culpa la tenga el equipo.

Pero viene una pregunta más fuerte, 

¿se puede controlar lo que no se no es posible controlar?

¿se puede controlar lo que esta en el campo de lo complejo?

Yo pienso que NO, y esa es la causa de la falta de transparencia.

El modelo de Cynefin nos da luces al respecto (ver referencias 1 y 2 entre muchas otras)

En software todo hace que el proyecto se atrase y se vuelva impredecible:

• el cliente
• los desarrolladores (la falta o exceso de los mismos)
• los egos 
• la inexperiencia
• los requisitos
• los servidores
• el software base
• la relaciones entre los componentes
• los componentes 
• las buenas relaciones
• las malas relaciones
• los insumos en el momento inapropiado
• la retroalimentación tardía
• la retroalimentación de las personas inadecuadas
• lo nuevo o viejo de cierto tipo de una u otra tecnología
• objetivos poco claros
• y muchos más, (ver referencias 3,4 y 5)

Si de una vez por todas decimos con sinceridad:

• estamos resolviendo el problema del software con las herramientas incorrectas
• fallamos aplicando métodos predictivos que aplican perfectamente en escenarios donde podemos imaginar con tranquilidad los acontecimientos (escenarios complicados, según el modelo de Cynefin)  

• cuando debemos ser adaptativos (o empleando el empirismo que propone Scrum), realizando inspección y adaptación (escenarios complejos, según el modelo de Cynefin)  .

Espero que algún día mis compañeros Gerentes de Proyectos de Software obsesionados:

• en ser secretarios de MS PROJECT (como le dice un gran Scrum Master y Coach - Jorge Johnson)
• en darle "manejo" a las situaciones ocultando información y cayendo en la FALTA DE TRANSPARENCIA
• en controlar lo que no se puede controlar

Acojan el agilismo y abracen sus principios y valores.

Saludos ágiles

Jorge Abad

___________

Referencias:

1. Sistemas Complejos Adaptativos: Modelo Cynefin (clic aquí)
2. Cynefin: la complejidad que nos rodea (clic aquí)
3. ¿Por qué fallan los proyectos? En: Navegapolis.net. Disponible en: <http://www.navegapolis.net/content/view/701/49/ >  [citado 24 de Junio de 2014]
4. STANDISH GROUP. Chaos Manifesto2013 - Think Big, Act Small. En: Version One [en línea]. Disponible en: <http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf> [citado 24 de Junio de 2014]
5. STANDISH GROUP. The Standish Group Report. [en línea]. Disponible en: <http://www.projectsmart.co.uk/docs/chaos-report.pdf> [citado 24 de Junio de 2014]