Muitos times estão no meio de um fogo cruzado em algum momento. Especialmente quando você faz parte de uma equipe de referência, com muitos membros experientes, outros times os procuram com pedidos de ajuda ou assistência, e você se sente como se estivesse no inferno.
Correções de bugs, dicas técnicas, um guia de onde começar na bagunça que chamamos de arquitetura ou até um ombro para chorar.
Mesmo quando estamos dispostos a fazê-lo, esse tipo de situação pode desafiar a capacidade da equipe de manter o foco nas coisas mais importantes, respeitando a prioridade do nosso backlog de pedidos e ainda sendo produtivo.
Vejamos os riscos desse tipo de situação e como lidar com isso.
O dano a evitar
Toda vez que precisamos parar de fazer o que estamos trabalhando no momento e mudar para um projeto diferente, nossa produtividade diminui.
Se trabalharmos em mais de um projeto por vez, as taxas de produtividade cairão, como podemos ver na imagem a seguir:
Fonte: Gerard Weinberg, Quality Software Management, 2011
O desperdício de tempo deriva dessa mudança de contexto, já que precisamos passar de uma ideia para outra.
Além disso, quando estamos em um processo de mudança de contexto, tendemos a perder a noção das prioridades, pois estamos mais focados em resolver as coisas do que em avaliar a urgência e a importância de cada tópico.
Como medir o impacto de pedidos intangíveis
Uma ideia é criar um quadro ou documento simples onde “anotaremos” toda vez que alguém da equipe é interrompido. Veremos em uma semana, ou duas, o quanto isso acontece diariamente.
Você também pode atribuir cores diferentes pela quantidade de tempo que a interrupção levou, por exemplo:
- 1 hora: marca verde
- meio-dia: marca amarela
- o dia todo: marca vermelha
A partir daí, podemos entender quanto tempo a equipe está gastando com esses tipos de demandas e quais são os principais motivos para isso.
Isso nos dará uma ideia de quanto custa e se realmente estamos indo na direção certa. Estamos colocando todo esse esforço nas opções mais importantes?
Também poderíamos tentar fazer alguns experimentos dentro da equipe para entender esse comportamento, algo como um teste A/B no qual duas tarefas de complexidade e tamanho semelhantes são atribuídas a dois membros diferentes da equipe, mas um deles será protegido do mundo exterior por um período de tempo e o outro não.
Vamos verificar, após esse período, o que aconteceu com o tempo de ciclo dessa tarefa nos dois casos.
O que podemos fazer
Compartilhamos aqui algumas ideias sobre como lidar com esse tipo de situação e tentamos diminuir o impacto sobre nossa equipe e seus resultados, partindo de uma perspectiva mais pessoal até chegar numa abordagem mais sistêmica do problema.
Vamos lembrar dessa abordagem, não importa qual seja a solução.
Pomodoro
De um ponto de partida muito pessoal, a técnica pomodoro é uma ferramenta de gerenciamento de tempo criada por Francesco Cirillo na década de 1980.
A ideia é bastante simples. Use um cronômetro para dividir o trabalho em vários intervalos, geralmente “caixas de tempo” de 25 minutos, separadas por intervalos curtos.
Cada um desses intervalos é conhecido como “um pomodoro” (tomate em italiano, lembrando temporizadores de cozinha que se assemelham a um tomate).
Aqui o convite é respeitar esse tempo para se concentrar em uma tarefa específica e tentar evitar interrupções, para que o trabalho flua e aumente nossa produtividade.
Relação de Pareto
Vamos fazer acordos explícitos dentro da equipe sobre quanto tempo queremos gastar semanalmente ou mensalmente nessas distrações externas e permitir que cada pessoa gerencie seu próprio tempo de acordo.
A sugestão aqui é começar a partir da razão Pareto (80% do tempo em nosso próprio backlog de pedidos e 20% do tempo em demandas externas) e evoluir gradualmente.
Certifique-se de revisar este acordo no final dos ciclos da equipe, para verificar se o cumprimos. Esse tipo de acordo pode ser difícil de manter e medir, pois será preciso muita disciplina de cada membro da equipe para gerenciar seu próprio tempo. E pode acontecer que nem todos se envolvam com os problemas.
Automação
Aqui apresentamos uma ideia bastante simples: automatize o máximo que puder para que outros possam tomar decisões sem que tenhamos que estar diretamente envolvidos.
Talvez a razão pela qual estamos sendo interrompidos seja porque eles precisam executar algumas rotinas ou processos, talvez seja uma questão de permissões que apenas nossa equipe tenha, talvez haja um erro que apenas nossa equipe conheça, ou talvez seja apenas falta de informações sobre alguns aspectos do código ou produtos que podemos disponibilizar em algum lugar.
Tudo isso pode ser automatizado. O custo dessa decisão é claro: levará mais tempo e custará mais para resolver os problemas, mas valerá a pena em escala.
O papel de “Bombeiro(a)”
Essa ideia começa com uma iniciativa simples: designar um “bombeiro(a)” na equipe para lidar com os problemas mais urgentes que estão nos afastando do foco e ajudando outras equipes.
Para fazer isso, a sugestão é verificar qual pessoa da nossa equipe está menos ocupada naquele momento e selecioná-la para essa função, para que possamos proteger os gargalos de nossas operações e reagir com agilidade suficiente ao sistema.
Outro fato importante a ser lembrado é que o papel do “bombeiro(a)” é rotativo. Dependendo da capacidade real de cada membro, o papel deve ser atribuído por consenso a um dos membros da equipe.
Durante o tempo em que essa pessoa assumir o papel de apagar incêndios, lembre-se de que será uma experiência difícil para esse membro da equipe e que ele não se sentirá tão conectado com o resto da equipe ou com o trabalho e os resultados que está alcançando.
Portanto, deve haver muita compreensão e comunicação dentro da equipe para resolver esses problemas.
“Guardião dos Portões”
Semelhante à última sugestão apresentada, desta vez criaremos um papel explícito para alguém tomar decisões sobre se a equipe fará ou não a demanda solicitada.
Essa pessoa receberá todos os pedidos e os analisará com base na prioridade do negócio, nível de complexidade, potencial de risco e o quanto isso afetará nosso backlog atual.
Essa pessoa deve ser alguém com um entendimento claro das prioridades da organização e que conheça o backlog da equipe. Também deve ser alguém com boas habilidades de comunicação, pois haverá muitos “não” para dizer neste processo.
O que é especialmente bom nesta solução é que estamos tentando aumentar a abordagem sistêmica do problema e tomar melhores decisões para a organização, não apenas para a equipe.
Troca de conhecimento
No final, tudo isso provavelmente está acontecendo porque sua equipe tem algo que está faltando na organização. Ou é sobre habilidades, comportamentos ou algum tipo de conhecimento que os outros possam se beneficiar.
Então, o que nossa equipe pode fazer para compartilhá-lo com outras pessoas e diminuir a dependência, permitindo que outras pessoas ofereçam tanto valor quanto nós?
Uma ideia é organizar workshops, treinamentos ou Dojos (prática do XP ou “Extreming Programming”) para compartilhar de uma maneira muito prática o que sabemos sobre um tópico específico.
Há muitos benefícios em ensinar enquanto o fazemos. Não deixe que isso se torne um e-mail frio! Muito melhor se pudermos fazê-lo juntos, olhando para as situações da vida real.
Em uma escala menor, também podemos dedicar tempo para trabalhar em pares com pessoas que precisam de ajuda (também uma prática do XP, chamada Programação em Pares).
Se quiséssemos ir ainda mais longe nessa linha, poderíamos criar uma ferramenta que ajudasse a decidir e priorizar em quais tópicos os times precisam de ajuda e gostariam de ensinar e aprender juntos, usando o que chamamos de Matriz de Competências do Management 3.0. Aqui compartilhamos mais detalhes sobre como executá-lo!
Diga-nos se algum deles foi útil para sua equipe e lembre-se de continuar medindo o impacto do seu trabalho constantemente. 
