Diatriba: Una salida a la sobresimplificación de nuestros problemas en proyectos

Hola a todos

Hoy quiero compartir una situación común en los proyectos y organizaciones, que se repite una y otra vez, adicionalmente creo que tanto ustedes como yo lo hemos vivido

El escenario es sencillo:
Se reúnen varios líderes asociados a la construcción de un proyecto (1) a deliberar ¿por qué este se encuentra mal o en riesgo?, y la primera respuesta que sale es:

• ¡El problema son los RECURSOS! ( - refiriéndose al equipo de trabajo - ,wow ¿estudiamos 5 años, más las experiencias, diplomados, certificaciones, especilizaciones y maestrías para responder esto?)

Pero, cuando lo opinión mágica no esta orientada a los "recursos", se centra en otro tema, todos concuerdan, se abrazan y sonríen, deciden que hacer, y salen de la reunión hasta que después sean convocados a otro comité para hablar sobre lo mismo y notar que los problemas no fueron resueltos o todos lo olvidan pues surgió otro proyecto en problemas para analizar.

¡Rayos! y recuerdo siempre a la cita del periodista del siglo pasado H.L. Macken

Image may be NSFW. Clik here to view.

Para cada problema complejo hay una solución clara, simple y equivocada,( H.L. Mencken)

No lo niego, al principio yo era así, además cuando asumes posiciones de liderazgo tiendes a adoptar los mismos lenguajes y análisis de tus pares, pero luego cuando en el 2012 conocí las metodologías ágiles y el poder de las retrospectivas para mejorar un equipo y su forma de trabajo, realmente cambio mi forma de ver las cosas.

Con esta nueva óptica, encontrarme en reuniones como esta no niego que me daba enojo, pues tendemos a la simplificación o sobresimplificación por herida newtoniana, ¿como así?, todos hemos sido heridos en nuestra lógica por Newton y su causa y efecto, y tendemos a creer que todo se resuelve así, por lo tanto, buscamos desesperada y angustiosamente una causa que explique nuestro problema (o efecto) y dado esto encontrar la solucion y continuar con el siguiente problema pues hay muchos líos en la fila esperando a ser resueltos.

algunos ejemplos de nuestra común sobresimplificación:

• por que el país esta mal, por el presidente 
• como si todos no hicieramos parte de un país y fueramos parte de la maquinaria que lo mueve)
• los proyectos de software fallan principalmente por los requisitos
• es una de las causas pero no es la única causa
• ¿Y por que fracasó su relación de pareja?, por una infidelidad de el/ella
• es muy probable que la infidelidad sea el sintoma y no la enfermedad, y la enfermedad era una serie de disfunciones en la pareja que hicieron que hubiese esa infidelidad,
• etc.

Y me topé con Cynefin

Cynefin es un framework para entender que tipo de problema estamos enfrentando y proporciona herramientas de como resolverlo, este framework me fue presentado por mi estimado Ricardo Colusso (@rcolusso) y desde ahí comencé a aficionarme a el, y recientemente leí un minilibro sobre el tema en Infoq.com (4) y muchas ideas se aclararon - recomendada su lectura -. Explicaré brevemente en qué consiste.

El framework de Cynefin fue elaborado por el Investigador Dave Snowden, y el termino significa "hábitat", divide los tipos de problema en 5 áreas y propone herramientas para solucionarlo

• El obvio:
• Problema conocido
• tiene relación directa causa efecto
• Ejemplo: Se chuzo la llanta, solución cambiar la llanta o parcharla
• Se resuelve con una mejor práctica
• Pasos de solución: inspeccione - categorice - responda
• El complicado
• Problema que se puede llegar a conocer
• Tiene relaciones causas y efectos conocidas
• Ejemplo: Se daño un vehículo y el mecánico luego de inspeccionarlo sabe los diferentes arreglos que hay que hacer para poner nuevamente el vehículo en marcha y estado optimo.
• Se resuelve con las mejores prácticas, juicio de expertos, todo es perfectamente planeado (cronogramas, tiempos, planeación predictiva, PMP) y los expertos resolveran este tipo de problemas de la misma manera teniendo el mismo éxito.
• Pasos de solución: inspeccione -analice - responda
• El complejo
• Problema es entendido en retrospectiva
• las relaciones causa y efecto no son repetibles
• Ejemplo: La economia es excelente prediciendo el pasado y explicándolo pero no es precisa hacia el futuro
• Se resuelve con la multiexperimentacion
• Pasos de solución: inspeccione - adaptación
• El caos
• El problema es incoherente
• las relaciones causa efecto no son percibibles
• Ejemplo: Escenarios de I+D
• La solucion es novedosa
• Pasos de solución: ensayo y error
• El desorden
• Corresponde al punto cuando llegamos a un problema y aún no lo hemos categorizado en los cuatro anteriores

Bajo todo lo expuesto quisiera invitarlos a varias cosas:

1. No caer en la sobresimplificación de los problemas que enfrentan, identificar si hay causa y efecto directamente relacionada o explicable, ya sea en el espacio de lo obvio o de lo complicado o realmente no.
2. Si lo anterior no se cumple trate de identificar si esta en el espacio de lo complejo, desde mi punto de vista y de otros muchos en la industria del software (5) la gestión y ejecución de proyectos de software cae allí, o sino díganme ¿qué gerente de proyecto de software es capaz de predecir todos los percances que le van a presentar en la ejecución del mismo, por más buena gestión del riesgo que haga? la verdad no conozco el primero, son capaces de explicar que les pasó y porqué les paso pero no de predecirlo por más que llenen el cronograma de colchones para la gestión del riesgo..
3. Si estas en una reunión de estas de análisis de problemas, propón lo siguiente:
1. Identifiquen las causas
2. las prioricen (cuales son las que consideran mas importantes)
3. Propongan soluciones
4. Las prioricen (cuales consideran claves, 3 ó 4) (6)
5. las ejecuten y observen en un ciclo de no más de un mes (ojala menos) los resultados de ese experimento y decidan que pasos seguir, tal vez sea necesario otro experimiento.

Cerrando

Notas, Referencias y Aclaraciones

1. También puede ser una empresa, un área organizacional.
2. Es un trabajo ardúo remover esta vicio de la gerencia tradicional de proyectos
3. Expicación de Cynefin segun wikipedia -https://en.wikipedia.org/wiki/Cynefin_Framework
4. Excelente libro sobre Cynefinby por Greg Brougham, corresponde a la colección de minilibros gratuitos de infoq.com - (clic aquí)
5. Debo esta referencia, pero no dudo que los firmantes del manifiesto ágil hacen parte de este grupo,
6. No se deben hacer todas las mejoras, al menos 3 ó 4 para saber cual fue la mejora o solución que más influyo en la solución del problema.
7. Excelente presentación sobre el tema de Hiroshi Hiromoto (@hhiroshi) (clic aquí)
8. Retrospectivas (ver más acá)