Compartilhe

Cómo sobrevivir al fuego cruzado

10/09/20 - 6 minutos de leitura

Muchos equipos se encuentran en medio de un fuego cruzado en algún momento. Especialmente cuando uno forma parte de un equipo de referencia, con muchos miembros experimentados, otros equipos acudirán a nosotros con demandas de ayuda o asistencia y se sentirá como si estuviéramos en el infierno. Corrección de errores, consejos técnicos, una guía sobre dónde comenzar en el desorden que llamamos arquitectura o incluso un hombro para llorar.

Incluso cuando estemos dispuestos a hacerlo, este tipo de situación puede desafiar la capacidad del equipo para mantenerse enfocado en las cosas más importantes, respetando la prioridad de su cartera de pedidos y no dejar de ser productivo. Veamos los riesgos de este tipo de situación y cómo lidiar con ella.

El daño a evitar

Cada vez que necesitamos dejar de hacer aquello en lo que estamos trabajando en ese momento, y cambiamos a un proyecto diferente, nuestra productividad disminuye. Si trabajamos en más de un proyecto a la vez, las tasas de productividad caen en picado, como podemos ver en la siguiente imagen:

Proyectos

Fuente: Gerard Weinberg, Quality Software Management, 2011.

Las pérdidas de tiempo derivan de ese cambio de contexto, ya que necesitamos pasar de una idea a otra.

Además, cuando estamos en un proceso de cambio de contexto, tendemos a perder el rastro de las prioridades, ya que estamos más enfocados en resolver cosas que en evaluar la urgencia e importancia de cada tema.

Demandas intangibles: cómo medir el impacto

Una idea es crear un tablero o documento simple donde “marquemos” cada vez que alguien del equipo sea interrumpido. En una semana o dos, veremos cuantas veces sucede esto a diario. También se pueden asignar diferentes colores en función del tiempo que duró la interrupción esa interrupción. Es decir:
1 hora: marca verde
medio día: marca amarilla
todo el día: marca roja

demandas

A partir de ahí, podemos comprender cuánto tiempo el equipo está dedicando a ese tipo de demandas y cuáles son las principales razones para ello. Esto nos dará una noción de cuánto cuesta y si realmente va en la dirección correcta. ¿Estamos poniendo todo este esfuerzo en las opciones más importantes?

También podríamos intentar hacer algunos experimentos dentro del equipo para comprender este comportamiento, algo así como una prueba A/B en la que se asignan dos tareas de complejidad y tamaño similares a dos miembros diferentes del equipo, pero uno de ellos estará protegido del mundo exterior. durante un período de tiempo y el otro no. Verifiquemos, después de ese tiempo, qué sucedió con el tiempo de ciclo de esa tarea en ambos casos.

Qué podemos hacer al respecto

Compartimos aquí algunas ideas sobre cómo lidiar con este tipo de situación y tratar de disminuir el impacto en nuestro equipo y sus resultados, comenzando desde una perspectiva más personal y adoptando un enfoque más sistemático del problema. Recordemos ese enfoque, no importa cuál sea la solución.

Pomodoro

Pomodoro
Desde un punto de partida muy personal, la técnica pomodoro es una herramienta de gestión del tiempo creada por Francesco Cirillo en los años 80, y la idea es bastante simple. Utiliza un temporizador para dividir el trabajo en varios intervalos, generalmente “cajas de tiempo” de 25 minutos, separadas por breves descansos. Cada uno de esos intervalos se conoce como "un pomodoro" (tomate en italiano, recordando los temporizadores de cocina que se asemejan a un tomate). Aquí la invitación es respetar ese tiempo para concentrarse en una tarea específica y tratar de evitar interrupciones, para que fluya el trabajo y aumente nuestra productividad.

Ley de Pareto

Ley de Pareto
Hagamos acuerdos explícitos dentro del equipo sobre cuánto tiempo queremos dedicar semanal o mensualmente a estas distracciones externas y permitamos que cada persona administre su propio tiempo en consecuencia. La sugerencia aquí es comenzar desde la proporción de Pareto (80% del tiempo en nuestra propia cartera de pedidos y 20% del tiempo en demandas externas) y evolucionar gradualmente. Asegurémonos de verificar este acuerdo al final de los ciclos del equipo, para comprobar si lo respetamos. Este tipo de acuerdo puede ser difícil de mantener y medir, ya que requerirá mucha disciplina por parte de cada miembro del equipo para manejar su propio tiempo y puede acontecer que no todas las personas se involucren demasiado con los problemas.

Automatización

Automatización
Aquí presentamos una idea bastante simple: automatizar todo lo que podamos para que otros puedan tomar decisiones sin que tengamos que involucrarnos directamente. Tal vez la razón por la que estamos siendo interrumpidos es porque nos necesitan para ejecutar algunas rutinas o procesos, tal vez es una cuestión de permisos que solo nuestro equipo tiene, tal vez hay un error que solo nuestro equipo conoce, o tal vez es sólo falta de información sobre algunos aspectos del código o productos que podemos facilitar en alguna parte. Todo esto puede ser automatizado. El costo de esta decisión es claro: tomará más tiempo y costará más resolver los problemas, pero valdrá la pena a escala.

El Rol de “Apaga incendios”

El Rol de “Apaga incendios”
Esta idea comienza con una iniciativa simple: designar un "apaga incendios" en el equipo para tratar los problemas más urgentes que nos están alejando de nuestro foco para ayudar a otros equipos. Para hacerlo, la sugerencia es verificar qué persona de nuestro equipo está menos ocupada en ese momento o iteración en particular, y elegirla para ese rol, para que podamos proteger los cuellos de botella de nuestras operaciones, mientras reaccionamos lo suficientemente ágil frente al sistema.

Otro hecho importante para recordar es que el rol de "apaga incendios" es rotativo y, dependiendo de la capacidad real de cada miembro, el rol debe asignarse por consenso a uno de los miembros del equipo. Durante el tiempo en que esa persona asuma el rol de apaga incendios, recordemos que será una experiencia difícil para ese miembro del equipo y que no se sentirá tan conectado con el resto del equipo o con el trabajo y los resultados que están logrando, por lo que debe haber mucha comprensión y comunicación dentro del equipo para abordar esos problemas.

“Guardián de las Puertas”

“Guardián de las Puertas”
De manera similar a la última sugerencia que presentamos, en esta ocasión crearemos un rol explícito para que alguien tome decisiones sobre si el equipo tomará o no esa demanda para trabajar. Esta persona recibirá todas las demandas y las analizará en función de la prioridad del negocio, el nivel de complejidad, el potencial de riesgo y cuánto afectará a nuestra cartera actual de pedidos. Esta persona debe ser alguien con una clara comprensión de la prioridad para la organización y alguien que conozca el trabajo atrasado del equipo, y también alguien con buenas habilidades de comunicación, ya que habrá muchos "no" que decir en este proceso. Lo que es especialmente bueno en esta solución es que estamos tratando de aumentar el enfoque sistémico del problema y tomar mejores decisiones para la organización, no solo para el equipo.

Intercambio de Conocimientos

Intercambio de Conocimientos
Al final, todo esto probablemente esté sucediendo porque su equipo tiene algo que le falta a la organización. O bien se trata de habilidades, comportamientos o algún tipo de conocimiento del que otros podrían beneficiarse. Entonces, ¿qué puede hacer nuestro equipo para compartirlo con otros y disminuir la dependencia, permitiendo que otros entreguen tanto valor como nosotros?

Una idea es organizar talleres, formaciones o Dojos (práctica de XP o "Programación extrema") para compartir de una manera muy práctica lo que sabemos sobre un tema en particular.

Hay muchos beneficios en enseñar mientras lo hacemos, de manera que no se convierta en un correo electrónico frío, mucho mejor si podemos hacerlo juntos, en función de situaciones de la vida real.

En una escala más pequeña, también podemos tomarnos un tiempo para trabajar en parejas con las personas que necesitan ayuda (también una práctica de XP llamada Programación de pares). Si deseamos ir aún más lejos en esa línea, podríamos crear algo para ayudar a decidir y priorizar qué temas enseñarán y aprenderán juntos, utilizando esta herramienta llamada Matriz de competencias de Management 3.0.

En el siguiente enlace os compartimos más detalles sobre cómo ejecutarlo (en Inglés): Using Team Competency Matrix to improve manager’s skills.

Contadnos si alguno de ellos fue útil para vuestro equipo y recordad seguir midiendo el impacto de vuestro trabajo constantemente. 🙂

Compartilhe

Escrito por

Ximena Valente

Agile Expert en K21


Ximena es Agile Expert en K21. Ha viajado y trabajado en más de 40 países, ayudando a organizaciones de diferentes sectores en procesos de innovación y transformación. Por encima de todo, Ximena es una entusiasta de cómo la cultura ágil puede impulsar la innovación y la creatividad.
Escrito por

Raphael Montenegro

Agile Expert e Trainer na K21


Raphael é Agile Expert e trainer na K21 com foco na visão de negócios, gestão de produtos, desenvolvimento de clientes e mindset lean startup. Tem a missão de usar a agilidade para educar e desenvolver pessoas desde 2007.
Esta postagem se encontra sob a licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Artigos relacionados

Product Backlog: Épico, Historia de Usuario y Tareas
26/05/20
4 minutos de leitura
¿Planificación con backlog prematuro? ¿Qué tal un refinamiento?
08/06/17
2 minutos de leitura

    ¿Quieres recibir nuestro contenido?

    Escribe tu nombre y correo electrónico para que te informemos todo lo que sucede por aquí.