Fluxo Unificado: Perspectiva de um Desenvolvedor – Motivações
Fluxo uni o quê?
Fluxo Unificado é o modelo de gestão de fluxo adotado pela Taller. Nele, vários projetos são atendidos dentro de um mesmo fluxo e pela mesma equipe. Vou explicar aqui alguns pontos interessantes da experiência de um desenvolvedor que trabalha neste modelo.
Nesta série, demonstrarei este processo do ponto de vista de alguém que esteve na equipe de operações desde a adoção do modelo em meados de 2015 até agora. Com isso, espero conseguir expor como isso muda a vida da equipe e quais as vantagens que enxergamos. Nesta primeira parte, vou abordar as principais motivações que nos levaram às ações desta mudança.
Falta de Resiliência na Operação
Quando dividíamos os times por projeto, não havia impactos pequenos. As equipes eram enxutas e normalmente contavam com especialistas em áreas distintas (frontend, backend, infraestrutura, testes, etc.), então cada pessoa que faltava gerava um impacto considerável. Uma pessoa doente, em férias ou representando a Taller num evento, por exemplo, poderia significar um enorme risco num projeto. O impacto causado nas pessoas e nos projetos gerava frustração no time.
Ociosidade
Entre as fases de um projeto é comum que haja intervalos. Uma equipe parada, mesmo que por um dia, é bastante caro. Já tentamos alocar pessoas ociosas de uma equipe em outra para ajudar no andamento das demandas, mas a mudança de contexto era muito grande (lei de Brooks). Isso porque, ao invés de trabalhar em alguns projetos com uma frequência moderada, o desenvolvedor atuava em um projeto com altíssima frequência e nos outros com frequência nenhuma. Dessa maneira, o tempo de adaptação para ajudar num projeto diferente geralmente não compensava, e acabávamos absorvendo o custo do projeto parado.
Ilhas de Conhecimento
Este fenômeno se manifestou de várias formas, sendo algumas das mais comuns:
- Esforços que se repetiam em diferentes projetos pela falta de conhecimento de soluções já adotadas. Sempre trabalhamos com uma stack semelhante para vários projetos, mas com equipes pequenas e isoladas acabávamos por fazer a mesma coisa duas vezes, ou mesmo adotando soluções diferentes para um mesmo problema.
- Bloqueios antes mesmo de uma tarefa entrar no fluxo por depender de uma pessoa específica para executá-la – especialização. Quando uma tarefa é priorizada pelo cliente, o ideal é que o time tenha condições de puxar ela assim que alguém ficar disponível. Quando muitas tarefas dependem da atuação de uma mesma pessoa, ela se torna um gargalo na equipe. Isso inclusive deixava a pessoa muito ocupada e com poucas oportunidades para interagir com as outras pessoas da mesma equipe ou outras equipes para compartilhar tomadas de decisão.
- Decisões sempre tomadas pelas mesmas pessoas, que também acabavam sobrecarregadas. No fim das contas um problema desencadeava outro: o fato de haver grande dependência em uma pessoa do time deixava essa pessoa sobrecarregada, sem conseguir alinhar todas as decisões com o time e, portanto, sem conseguir compartilhar o conhecimento. Sem isso, a dependência nessa pessoa só aumentava.
Essas foram algumas das principais motivações do ponto de vista do desenvolvimento que nos levaram a unificar o fluxo. No próximo artigo, falarei das ações que foram desencadeadas por essas motivações. É possível ler sobre o Fluxo Unificado aqui.
Confira os outros posts da série aqui:
2º Post: Fluxo Unificado: perspectiva de um desenvolvedor – Ações
3º Post: Fluxo Unificado: perspectiva de um desenvolvedor – Resultados
4º Post: Fluxo Unificado: perspectiva de um desenvolvedor – Responsabilidades
