Em um mundo ideal, todos os times da empresa seriam de ponta a ponta. Indo desde a concepção do produto / serviço através de formulação de hipóteses, passando pela construção, entrega para o cliente até a aferição de resultados. Porém, na vida real nem sempre conseguimos isso e é aí que aparecem as dependências externas.
O que é a dependência externa
A dependência externa acontece quando uma etapa do seu fluxo de trabalho não pode ser executada pelas pessoas que estão no seu time. Você terá que acionar uma pessoa, time, unidade ou até mesmo uma outra empresa.
Por exemplo:
- Um time de desenvolvimento precisa que outro time valide o código antes da entrega.
- Uma equipe de marketing aguarda a aprovação jurídica de uma campanha.
Por que dependências externas são um problema?
Quanto mais dependências externas o seu fluxo de trabalho possui, mais lento ele tende a ser. Isso acontece por algum desses motivos:
- Prioridades conflitantes: Um item que pode ser muito prioritário para o seu time, pode não ter a mesma prioridade para o time externo.
- Especialistas sobrecarregados: Normalmente as dependências apontam para times de especialistas. Esses especialistas estão recebendo demandas de diversos times da empresa e o seu é só mais um no meio da multidão.
- Dependências em cascata: A dependência externa também pode ter uma dependência externa
- Custos de coordenação: Quanto mais pessoas envolvidas, maior será o custo de coordenação e a comunicação poderá sofrer bastante com isso.
Se for possível, a minha recomendação é que você sempre tente trazer para dentro do time todas essas dependências. Simplifica o fluxo e agiliza o trabalho
Como o Kanban pode te ajudar a visualizar essas dependências externas
Porém nem sempre é possível e aí será necessário gerir essas dependências. Há diversas formas e vou colocar algumas que já utilizei aqui. Fique à vontade para entrar no meu Linkedin e compartilhar a sua experiência.
Dependência Sistêmica em ambiente com baixa colaboração
Esse é um contexto bem comum. A dependência é sistêmica porque a maioria ou até mesmo todos os itens de trabalho que o time desenvolve precisam passar por um time externo. Por exemplo, em times de TI, é comum que times sejam responsáveis por desenvolver as funcionalidades do produto (Times de Desenvolvimento) e quando chegam na etapa de entrega passam para outro time que disponibiliza os itens para o cliente (Time de Infraestrutura).
Se o ambiente não for de colaboração entre os times, dificilmente eles se sentarão à mesa para discutir e planejar a forma mais eficiente de fazer as entregas e no geral tentam se resolver através de sistemas de tickets, Documento de Gestão de Mudanças (GMUD), e-mail etc.
Por ser uma dependência sistêmica e que o time não tem controle, uma boa solução para visualizar o problema é oficializar a etapa de dependência externa. Acrescentá-la ao fluxo de trabalho e tomar uma decisão quanto a limitar ou não a quantidade de itens de trabalho que ela poderá receber. Escrevi sobre isso no artigo: Briga – Resolvendo as dependências externas ao time.
A imagem acima representa uma forma de tratamento dessa dependência. As etapas de Avaliação e Entrega são externas ao time de construção. Logo elas são explicitadas e marcadas em outra cor para simbolizar a dependência.
Dependência Sistêmica em ambiente colaborativo
Aqui vale a mesma dica para o time. Oficialize a etapa de dependência externa e acrescente uma coluna no seu fluxo de trabalho. A diferença aqui é que há colaboração e as pessoas podem sentar juntas para discutir e planejar como os próximos itens serão desenvolvidos e entregues para o cliente. É aqui que o Modelo de Maturidade do Kanban (KMM de Kanban Maturity Model) pode fazer a diferença. Especialmente com as cadências (reuniões) de Nível 2.
Workflow Replenishment Meeting (Reunião de Reabastecimento do fluxo de trabalho)
É uma cadência em que todas as pessoas envolvidas no fluxo, internas e externas, combinam quais serão os próximos itens que entrarão no fluxo. Seus principais pontos são:
- Abastecer o backlog com novos itens;
- Priorizar as demandas
- Definir critérios de entrada
- Ajustar o ritmo do trabalho
- Apoiar decisões estratégicas
Workflow Kanban Meeting (Reunião Kanban de Fluxo de Trabalho)
Particularmente acredito que essa seja a cadência mais importante quando o fluxo de trabalho é compartilhado entre dois ou mais times. Ela funciona como se fosse a Team Kanban Meeting (“Daily Meeting”) para todos. Obviamente, por juntar pessoas de diversos times, não deve ser realizada diariamente. Ela garante que os itens avancem de forma eficiente e que bloqueios sejam identificados e resolvidos rapidamente.
Flow Review (Revisão do Fluxo)
Funciona como se fosse uma retrospectiva de todo o fluxo de trabalho. Os principais objetivos são:
- Avaliar o desempenho do fluxo de trabalho – Revisar métricas como Customer Lead Time e Vazão.
- Examinar a saúde do sistema Kanban – Verificar se os limites de WIP estão sendo respeitados.
- Identificar gargalos e atrasos – Diagnosticar etapas que acumulam itens ou apresentam maior tempo de espera.
- Revisar práticas de trabalho – Refletir sobre a eficácia das práticas atuais e identificar melhorias.
- Alinhar o fluxo com os objetivos do negócio – Garantir que o trabalho priorizado entregue valor esperado.
- Planejar melhorias contínuas – Definir ações para otimizar o fluxo e aumentar a previsibilidade.
Se quiser saber mais sobre essas cadências (reuniões) veja o artigo: Conhecendo as 18 Cadências do Kanban! Ou veja o nosso treinamento de KSD – Kanban System Design
Dependência Sistêmica com Gestor de Fluxo
Acontece quando há a presença de uma pessoa ou grupo de pessoas responsável pela gestão do fluxo de trabalho compartilhado entre dois ou mais times. Ele é o responsável por alinhar as entradas e saídas. Enquanto os times manipulam seus quadros de forma individual, o gestor fica com um quadro de segundo nível orquestrando para que as dependências externas estejam alinhadas.
Funciona mais ou menos assim. Imagine que o Time Construção e o Time Avaliação e Entrega sejam necessários para que um determinado serviço seja entregue. O Time Construção produz o insumo que será consumido pelo Time Avaliação e Entrega. Digamos também que nesse momento ambos estão envolvidos na construção dos Itens X, Y e Z que compõem a Entrega 12.
Conforme os itens que compõem a Entrega 12 estejam chegando nas etapas finais do Time de Construção, o Gestor do Fluxo deve trabalhar para garantir que ele seja recebido pelo Time de Avaliação e Entrega e que eles comecem a trabalhar nele o mais rápido possível.
Esse gestor normalmente tem seu quadro próprio, pois ele está olhando para diversos times. Nesse caso, uma ferramenta de gestão de trabalho se faz bastante necessária. Enquanto os times trabalham em uma granularidade bem fina, o gestor do fluxo acompanha a entrega em maior granularidade. Por exemplo: enquanto os quadros dos times apresentam todas as funcionalidades que comporão cada entrega, o quadro do gestor acompanha apenas as entregas.
Se quiser saber mais sobre os diferentes níveis de acompanhamento de um fluxo, veja o artigo O que é Flight Levels e suas 5 atividades ou vá direto no nosso treinamento de Flight Levels System Architecture (FLSA).
Dependência Pontual Planejada
Aqui não acontece o tempo todo e por isso não vale a pena explicitar no fluxo de trabalho como uma nova etapa (coluna). É interessante marcar o item com algo (cor diferente, fita, cabeçalho, indicando que há uma dependência externa ali.
Além disso, é importante que em algum lugar esteja escrito qual dependência é essa e qual o limite para que ela inicie e conclua o trabalho que ela tem que realizar. Algumas ferramentas de gestão de fluxo permitem que sejam criados alertas para facilitar esse controle de prazos.
Caso o limite seja ultrapassado e o item não possa prosseguir no fluxo de trabalho, ele deve ser marcado como bloqueado.
Dependência Imprevista
Esse é o pior caso. Nos comprometemos com a construção de um item, começamos a construção e no meio do caminho descobrimos que não podemos prosseguir porque precisamos acessar a dependência externa. Não tem muito o que fazer. Apenas adicionar o indicativo de bloqueio e resolver o problema.
Quando isso acontece, o mais importante é levar essa ocorrência para a retrospectiva. Temos que nos perguntar: Por que estamos nos comprometendo com itens que ficam impedidos por não termos visto a dependência externa previamente? Pode ter sido um problema pontual que não requer grandes cuidados ou, caso fique ocorrendo toda hora, temos um problemão para resolver.
Agrupamento de Bloqueadores
Caso as dependências externas estejam causando diferentes bloqueios no fluxo, uma ideia interessante é agrupar as causas por tipos. Tratamos esse assunto no artigo: Agrupe Bloqueadores e acelere seu time. Sendo muito resumido, você deve categorizar as causas dos bloqueios e tratar os que ocorrem com maior frequência o mais rápido possível.
Conclusão
Espero que este artigo tenha ajudado a visualizar e tratar as dependências externas que aparecem no seu fluxo de trabalho. Se você tiver outra ideia, manda uma mensagem lá no Linkedin para podermos continuar essa conversa.
Dá uma olhada nos nossos treinamentos
Flight Levels System Architecture (FLSA)
Até a próxima
Mikit tamu keng tutuki
