lunes, abril 25, 2016

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, especializaciones y maestrías para responder esto?)
y acá veo varios  problemas en esta óptica que quiero compartirles:
  1. En primer lugar no son recursos, son personas, esta eterna lucha por que comprendan que el trabajo lo hacen personas tan valiosas como quienes dirigen y que al pensar en una forma reduccionista sobre las personas lo que logran es ignorar o desperdiciar la capacidad creativa e innovadora del ser humano, y del equipo que los acompaña.
  2. ¿Quién en sus cinco sentidos quiere hacer mal su trabajo? La verdad no dudo que los hayan (serán muy pocos), pero no es lo común, todos queremos hacer cosas que ayuden a otros, que sirvan, que sean útiles y que estén alineadas con el propósito para el cual sentimos que estamos acá en esta tierra, por lo tanto culpar al equipo de trabajo es una costumbre simplista que indica que no se quiere abordar con el debido interés la causa y la solución del problema.
Pero cuando lo opinión mágica no está orientada a los "recursos" se centra en otro tema (9), 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. Mencken
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 cambió 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, ¿cómo 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 solución 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 qué el país está mal, por el presidente?
    • como si todos no hiciéramos parte de un país y fuéramos 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 qué fracasó su relación de pareja?, por una infidelidad de él/ella
    • es muy probable que la infidelidad sea el síntoma 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 qué tipo de problema estamos enfrentando y proporciona herramientas de cómo 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 término 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 chuzó 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 óptimo.
    • Se resuelve con las mejores prácticas, juicio de expertos, todo es perfectamente planeado (cronogramas, tiempos, planeación predictiva, PMP) y los expertos resolverán 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 economía es excelente prediciendo el pasado y explicándolo pero no es precisa hacia el futuro
    • Se resuelve con la multiexperimentación
    • Pasos de solución: inspección - adaptación
  • El caos
    • El problema es incoherente
    • las relaciones causa efecto no son perceptibles
    • Ejemplo: Escenarios de I+D
    • La solución 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 está 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 estás 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 más importantes)
    3. Propongan soluciones
    4. Las prioricen (cuales consideran claves, 3 o 4) (6)
    5. las ejecuten y observen en un ciclo de no más de un mes (ojalá menos) los resultados de ese experimento y decidan qué pasos seguir, tal vez sea necesario otro experimento.
Para este último escenario existen diversas herramientas de 
  • análisis de causa raíz
  • retrospectivas (que incluyen lo anterior)(8)
  • Toyota Kata (7)
que son bastante fuertes y útiles.

Por tanto, quisiera invitarlos a que abracemos la complejidad de nuestros proyectos y organizaciones y abandonemos la sobresimplificación.




Cerrando

Y bueno, propongo que los líderes de proyecto, gerentes, etc, seamos más creativos y demostremos nuestros años de estudio, experiencia y certificaciones identificando las verdaderas causas y dejemos la sobresimplificación de los problemas que enfrentamos, entendiendo que nos movemos en un espacio complejo sobre el cual no tenemos control, esta actitud, será mucho más útil, que ignorarlo.



"No estamos en las organizaciones para ofrecer soluciones rápidas sino para ofrecer las soluciones correctas"



Saludos ágiles
Jorge Abad


Notas, Referencias y Aclaraciones


  1. También puede ser una empresa, un área organizacional.
  2. Es un trabajo arduo remover este 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 o 4 para saber cual fue la mejora, solución o experimento que más influyó 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á)
  9. He también visto como se centran estos comités en culpar a las pruebas y acusan de la calidad del software solo a esta actividad del proceso, o cualquier otro chivo expiatorio ¡OMG!



No hay comentarios.:

Publicar un comentario