ERP

El jefe de proyecto hizo algo totalmente inesperado. ¡No creerá lo que pasó después!

Peter Burghardt06/08/2019

Imagine el siguiente escenario: Una sala con una gran mesa de conferencias, varias personas están sentadas alrededor de ella y comparten sus experiencias negativas de los últimos 1 o 2 años. El líder presenta hechos y cifras. Al final, todo el mundo se siente aliviado de haber pasado la reunión sin que se le culpe de nada.

 

Lo que suena como un grupo de autoayuda es en realidad un taller de lecciones aprendidas después de un proyecto. Puede que haya exagerado un poco en la descripción, pero creo que todos hemos pasado por uno o más talleres similares a éste. Entonces, ¿por qué los talleres de lecciones aprendidas tienden a salir así? ¿Por qué a menudo no logramos alcanzar los objetivos previstos en el taller?

Mala programación

¿Cuándo se realiza típicamente el taller de lecciones aprendidas? Al final del proyecto. Trabajas en algo durante uno o dos años, y al final, hablas de las cosas que no salieron muy bien. No importa que sea difícil para los participantes recapitular toda la historia del proyecto e identificar las áreas problemáticas - estos problemas ni siquiera se discuten en el momento en que surgen. Esto tiene varias desventajas:

  1. No hay garantía de que no se vuelva a cometer el mismo error en el proyecto.
  2. No hay garantía de que el mismo error no se cometa mientras tanto en un proyecto diferente.

Aunque las desventajas son bastante obvias, la gente insiste en guardar el taller de lecciones aprendidas para el final del proyecto. Francamente, no tengo ni idea de por qué.

¿Qué hemos aprendido?

A menudo, te sientas y recopilas todo lo que salió mal. Y ahí es donde normalmente termina. La gente se olvida de averiguar por qué fue mal y, lo que es peor, se olvida de averiguar lo que puede hacer en el futuro para evitar cometer el mismo error.

El solo hecho de saber que algo no era lo ideal no significa que haya aprendido algo de ello. Para aprender, debe entender las causas detrás del problema y luego derivar pasos o comportamientos que ayuden a prevenir que el problema vuelva a ocurrir.

Haga clic aquí para obtener más información sobre la gestión de proyectos!

Descubra más

Transferencia de lecciones a la organización

A menudo, algo se anota en documentos que luego se archivan en el portal del proyecto y se dejan allí, esperando ansiosamente ser redescubiertos. El intento de llevar a cabo acciones desde el proyecto a la organización es difícil y tiende a fracasar en la mayoría de los casos. Por lo general, el problema se repite antes de que se redescubra la documentación del taller de lecciones aprendidas.

Desde mi punto de vista, esto se debe a que el taller de lecciones aprendidas se lleva a cabo en una etapa tan tardía, mucho después del momento en que se produjeron los problemas. En este momento, ya no son tan críticos como cuando sucedieron - fuera de la vista, fuera de la mente. Por lo tanto, nadie se está concentrando en ellos, y es poco probable que la gente se dé cuenta cuando se entere de un problema que ya se ha discutido en el pasado.

¿Cómo podemos hacerlo mejor?

Retrospectiva. De lo que los cerebros detrás del Manifiesto Ágil se dieron cuenta es que no tiene sentido esperar hasta el final para hablar de lo que debieron haber hecho de otra manera. Por eso definieron el siguiente principio de agilidad:

A intervalos regulares, el equipo reflexiona sobre cómo pueden ser más eficaces y ajusta su comportamiento en consecuencia.

No se trata de aumentar el rendimiento laboral, sino de mejorar uno mismo. Scrum utiliza Retrospectivas al final de cada Sprint para hacer esto. Este enfoque es mucho más amplio que el taller de lecciones aprendidas "normales". La idea no es quejarse de todo lo que salió mal. Se trata de hacer mejoras específicas. Por supuesto, esto implica repasar los problemas que ocurrieron o los errores que se cometieron. Pero también implica la optimización de procesos y procedimientos que pueden haber funcionado bien hasta ahora.

La ventaja de una perspectiva externa

Las retrospectivas también demuestran la ventaja que ofrece el papel del Scrum Master o del Agile Coach, que modera la reunión y proporciona una perspectiva imparcial y externa. Este factor también está ausente en la mayoría de los talleres de lecciones aprendidas convencionales, porque normalmente es el gerente de proyecto quien modera, a pesar de que se supone que él/ella está involucrado/a en el trabajo en sí.

Llevamos varios meses utilizando métodos ágiles en nuestros equipos de productos, y hemos tenido muy buenas experiencias con las Retrospectivas y el uso de un Coach. Los equipos han hecho progresos notables. Hemos sido capaces de abordar errores y problemas y encontrar maneras de resolverlos o prevenirlos en el futuro.

Las retrospectivas también afectan positivamente y promueven los procesos de formación de equipos. Incluso después de una retrospectiva particularmente "pesada", el equipo suele salir más fuerte y más cohesionado.

Establecer las condiciones adecuadas

Para que las Retrospectivas sean eficaces, es necesario crear las condiciones marco adecuadas. Se debe evitar cualquier elemento perturbador. Esto incluye tener miembros de la gerencia en la reunión, porque esto podría hacer que el personal sea menos sincero con su retroalimentación. Asegúrese de dejar suficiente tiempo, para que las discusiones no tengan que ser interrumpidas. El moderador debe preparar y estructurar las Retrospectivas, dejando suficiente margen para lo inesperado. Las retrospectivas no son simples reuniones para hablar de problemas. Estas son reuniones creativas activamente diseñadas. En la página web "planes para la retrospectiva", puede encontrar excelentes herramientas que le ayudarán a hacer que su Retrospectiva sea interesante.

Las primeras Retrospectivas que realice en su empresa probablemente no serán muy efectivas y eficientes. Los equipos tienen que aprender cómo funcionan las Retrospectivas y comprometerse realmente con ellas. Después de dos o tres reuniones, usted comenzará a notar que los resultados del Retro están mejorando y que todo el proceso está yendo mejor.

Independientemente de cómo elija diseñar sus Retrospectivas, hay dos reglas básicas que siempre debe seguir:

  • Lo que pasa en la Retro se queda en la Retro. Sólo si todo el equipo está de acuerdo en que algo debe ser subcontratado es posible hacer una excepción. Esto generalmente se refiere a cuestiones que el equipo no puede resolver por sí solo.
  • No juegue al juego de la culpa. Los problemas existen y se cometen errores. No se trata de encontrar al culpable y ponerlo en el cepo. Las retrospectivas tienen que ver con encontrar soluciones y centrarse en el futuro.

El efecto de estas dos reglas básicas es hacer que los participantes sean más abiertos y crear (en conjunción con las condiciones mencionadas anteriormente) un ambiente libre de estrés que permita mejorar al equipo del proyecto e incluso a la empresa.

Compartir Post

Etiquetas

No hay etiquetas disponibles

Contáctenos:
Autor:
Peter Burghardt
Project Manager