Construindo equipes produtivas

Os engenheiros prosperam em ambientes onde podem se concentrar e entrar no fluxo de produtividade. As equipes geralmente enfrentam distrações e prioridades concorrentes que forçam os engenheiros a mudar o contexto e dividir sua atenção. Eles lutam para equilibrar o tempo de foco com o tempo de alerta. A adição de novos recursos exige que os membros da equipe estejam focados. Responder aos problemas dos clientes e resolver problemas do local em tempo real requer que a equipe esteja alerta e ciente do que está acontecendo.

Para mitigar as distrações, uma equipe pode se dividir em duas equipes: uma para recursos e outra para a integridade do local ao vivo.

Illustration of feature crew and customer crew working together.

A abordagem de duas equipes traz maior produtividade e previsibilidade. A implementação bem-sucedida depende destes elementos-chave:

  • Funções da equipe claramente definidas
  • Um processo de rotação de equipe bem definido
  • Ajustes frequentes no tamanho da equipe

Equipe de recursos

A equipe de recursos, ou equipe F, concentra-se no futuro. Ela funciona como uma unidade eficaz que tem uma missão e objetivo claros: criar e lançar recursos de alta qualidade.

A equipe F é protegida do caos diário do serviço ao vivo para garantir que eles tenham tempo para projetar, criar e testar seu trabalho. Ela pode contar com o mínimo de distrações e não precisa corrigir problemas que surgem aleatoriamente. Ela é incentivada a verificar seus emails raramente e evitar ser arrastada para outros problemas, a menos que sejam críticos.

Quando um membro da equipe F se junta a uma conversa ou ocasionalmente é sugado para uma conversa de email, outros membros da equipe devem repreendê-lo: "Você está na equipe F, o que você está fazendo?" Se um membro da equipe F precisar resolver um problema crítico, ele é incentivado a delegá-lo à equipe do cliente e retornar ao trabalho de recurso.

A equipe F opera como uma equipe unida que se concentra em um pequeno conjunto de recursos. Um bom limite de trabalho em andamento (WIP) é dois recursos em andamento para 4-6 pessoas. Trabalhando em estreita colaboração, elas criam um contexto compartilhado profundo e encontram bugs críticos ou problemas de design que uma revisão superficial de código perderia. Uma equipe dedicada permite uma taxa de transferência e um prazo de entrega mais previsíveis. Os membros da equipe costumam se referir à equipe F como serena e focada. Eles acham pacífico e rejuvenescedor se concentrar profundamente em um recurso e dedicar total atenção a ele. As pessoas encerram o expediente na equipe F se sentindo renovadas e realizadas.

Equipe do cliente

A equipe do cliente, ou equipe C, concentra-se no agora e fornece suporte de linha de frente para problemas do cliente e do local ao vivo, bugs, telemetria e monitoramento. A equipe C muitas vezes se amontoa em torno de um computador, depurando um problema crítico do local ao vivo. Sua prioridade número um é a integridade do local ao vivo. Totalmente focados nesse ambiente, eles desenvolvem habilidades especializadas de depuração e análise. A equipe do cliente é muitas vezes chamada de equipe de escudo, porque ela protege o resto da equipe de distrações. Em vez de trabalhar em recursos futuros, a equipe C é a ponte entre os clientes e o produto atual. Os membros da equipe são ativos no email, Twitter e outros canais de feedback. Os clientes querem saber que são ouvidos, e o trabalho da equipe C é ouvi-los. A equipe C organiza os problemas relatados pelo cliente imediatamente e rapidamente engaja e auxilia os clientes bloqueados.

Com uma enxurrada de tarefas recebidas, trabalhar em uma equipe C de ritmo acelerado pode, às vezes, ser emocionante. Em uma semana movimentada, eles abordam vários emails, investigações ao vivo e bugs. À medida que as operações se acalmam, eles trabalham para melhorar a telemetria e os relatórios, investindo seu tempo para facilitar a manutenção do serviço.

As equipes C permitem que a equipe resolva problemas sem tirar os membros da equipe de outras prioridades e garantir que os clientes e parceiros sejam ouvidos. A capacidade de resposta a perguntas e questões torna-se um ponto de orgulho para as equipes C. No entanto, esse ritmo pode ser desgastante, exigindo um rodízio frequente entre as equipes.

Rotação da equipe

Um processo de rotação bem definido faz o sistema de duas equipes funcionar. Você poderia simplesmente trocar as equipes (a equipe F torna-se a equipe C e vice-versa), mas isso limita o compartilhamento de conhecimento entre e dentro das equipes. Em vez disso, opte por um rodízio semanal.

No final de cada semana, realize uma pequena reunião de troca onde a equipe decide quem troca de equipe. Você pode usar um gráfico de quadro de comunicações para acompanhar quem está atualmente em cada equipe e quando a pessoa foi trocada. As pessoas com mais tempo de permanência em cada equipe normalmente devem trocar umas com as outras. No entanto, em uma determinada semana, alguém pode querer permanecer para concluir o trabalho em uma investigação ou recurso ao vivo. Embora haja flexibilidade, quanto mais tempo alguém estiver em uma equipe, maior a probabilidade de ser trocado.

Rotações semanais ajudam a evitar silos de conhecimento na equipe e garantem um fluxo constante de informações e perspectivas entre as equipes. O movimento frequente dos engenheiros cria conhecimento compartilhado do trabalho da equipe, o que ajuda a equipe C a resolver problemas sem a ajuda de outras pessoas. Muitas vezes, os novos membros da equipe F encontrarão rapidamente uma falha de design ou código que foi negligenciada anteriormente.

Tamanho da equipe

O tamanho da equipe varia para manter a saúde da equipe. Se uma equipe tem uma alta taxa de entrada de problemas no local ao vivo ou tem muita dívida técnica, a equipe C fica maior e vice-versa. Ajustar tamanhos semanalmente aumenta a previsibilidade nas entregas e dependências da equipe. Em algumas semanas, uma equipe pode mover todos para a equipe C para abordar o feedback de um grande lançamento.

Essa estratégia simplifica a comunicação com a gerência. Sem um sistema de duas equipes, os engenheiros geralmente trabalham em várias coisas simultaneamente. Quando várias distrações ocorrem em uma única semana, os recursos em andamento geralmente são atrasados. Como resultado, uma equipe pode não conseguir dar cronogramas com confiança para o trabalho futuro de recursos.

Uma equipe F dedicada leva a um rendimento e tempo de execução previsíveis. A divisão de recursos entre as equipes aumenta a responsabilidade dentro da equipe e com a gerência sobre o que a equipe pode realizar a cada semana e a cada sprint.

Próximas etapas

O sistema de duas equipes pode ajudar as equipes a entender onde os engenheiros devem gastar seu tempo e a progredir em muitas prioridades concorrentes.

Além de melhorar a produtividade e a previsibilidade, o sistema de duas equipes pode aumentar o moral da equipe. Os engenheiros de cada equipe entendem claramente seus papéis e responsabilidades e funcionam de forma mais independente e com muito mais responsabilidade. Essa abordagem é ideal para equipes de DevOps, aquelas responsáveis tanto pelo desenvolvimento quanto pelas operações. No entanto, essa abordagem pode ser aplicada a praticamente qualquer equipe Agile que lida com prioridades concorrentes.

A Microsoft é uma das maiores empresas Agile do mundo. Saiba como a Microsoft organiza equipes no planejamento de DevOps.