Hola, tuve el siguiente caso: un problema de JIra con flujo interrumpido con respecto a Tareas pendientes/Seleccionado para desarrollo/En progreso/Terminado. El resultado fue que todas las herramientas alrededor de JIra: los informes de las placas estaban rotas e inutilizables. Los propietarios de productos y los líderes del equipo querían tener una visión general de un estado determinado, por lo que iniciaron una revisión de los estados. Aunque no soy un líder de equipo, soy el desarrollador de Jira más comprometido en mi equipo. La mayoría de los problemas de Jira los informo yo. El líder de mi equipo y el propietario de mi producto pidieron comentarios y vine preparado para abordar el flujo roto. Estaba preparado con 4 puntos.
En la última reunión, el líder del equipo y el propietario del producto se reunieron con los otros líderes del equipo y los PO y, después de un día, presentaron un flujo revisado y ninguno de mis 4 puntos se tuvo en cuenta. El flujo de desarrollo estaba tan roto como antes. Salieron a holgazanear presentando el nuevo flujo en busca de retroalimentación. Di comentarios bastante negativos y, como resultado, se aceptaron 3 de 4 puntos de mis comentarios.
Me siento muy descontento con mi TL y mi PO porque no entregaron mi mensaje y tuve que contactar a un TL diferente para hacerlo.
El lunes tengo una reunión retrospectiva y siento la necesidad de quejarme y mostrar mi descontento con la situación. ¿Cómo puedo hacerlo de tal manera que no aliene al resto del equipo? ¿Debo tomarlo como algo personal con el PO y el TL o puedo presentar una buena queja durante la retrospectiva?
Aquí está el flujo exacto de eventos:
No te quejes en una retrospectiva, y mucho menos de personas específicas. Puede ser catártico, pero no va a cambiar nada y no va a ganarte el cariño de nadie. Guarda eso para fuera del trabajo con tus amigos y/o cónyuge.
En su lugar, concéntrese en las cosas que le gustaría mejorar en el futuro.
Si cree que el nuevo flujo de trabajo no abordó los problemas inherentes al anterior, tal vez sugiera que en el futuro, al rediseñar los procesos, las personas más cercanas a los problemas deberían participar en la creación del nuevo.
O tal vez los problemas podrían haberse evitado si hubiera habido más oportunidades de retroalimentación durante el diseño del nuevo proceso en lugar de justo al final.
Estos son solo ejemplos, tendrá que averiguar por sí mismo lo que cree que podría mejorar las cosas en el futuro, pero mi punto es que una reunión retrospectiva solo puede ser útil si hay elementos de acción al final para las cosas que van a mejorar. ser diferente a partir de ahora. De lo contrario, es solo un festival de gemidos que no logra nada excepto bajar la moral de todos.
Decirle a la gente el mal trabajo que crees que hicieron no va a crear esas acciones, aunque pueda parecer satisfactorio.
No salió como supuse, realmente salió mal.
La acción principal será pedir retroalimentación:
Lo que se gana con esto en el futuro es
Siempre enmarque sobre la ganancia en el futuro.
Si puedes hacer eso, creo que vale la pena mencionarlo durante la retrospectiva. Porque habrás encontrado algo para mejorar la situación. Si crees que no es suficiente, tu equipo te ayudará.
Respuesta anterior basada en una idea incorrecta de cómo fueron las cosas:
no estoy seguro de que las cosas fueran tan mal, ¿quizás solo fue un malentendido?
Pero podrías enmarcarlo como "en este caso salió bien pero podría haber salido mal y hay cosas por mejorar":
Con respecto al problema con Jira, todo salió bien, pero... Pensé que mis puntos ya habían sido descartados cuando los TL/PO solicitaron comentarios.
Lo mencioné nuevamente porque me sentí frustrado, pero es posible que otra persona no haya hecho lo mismo.
Si no hubiera dado ningún comentario, el flujo de trabajo habría cambiado sin resolver realmente el problema.
Luego hay algunas acciones disponibles.
Acción 1:
hacer explícito que cuando los TL/PO solicitan retroalimentación, las personas deben mencionar cualquier punto, incluso si piensan que sus puntos ya se tomaron en cuenta, porque puede que no sea el caso.
Acción 2:
El TL/PO comparte los puntos del miembro en la discusión.
Debe haber un comentario del TL/PO sobre por qué se descartó/cambió.
Luego, regrese a la acción 1: es posible que TL/PO no haya podido "venderlo bien" (o malinterpretó algo o lo que sea que pueda suceder)
Acción 3:
En lugar de la acción 2, el miembro participa en la discusión.
Luego regrese a la acción 1: Alguien más puede tener algunos puntos que no llegaron a la discusión.
HorusKol
Pesho
Pesho