1

O que você vai

ler nesse ebook
03 | Dependências de fluxo
Dependência entre ítens
Dependência de revisão
Dependência de especificação

06 | Dependências de conhecimento

07 | Dependências burocráticas

08 | Dependências de produto

09 | Dependências externas

10 | Dependências de Infra

11 | Dependências de Arquitetura
Arquitetura de Código
Arquitetura da Aplicação
Gestão de Dependências: uma visão geral 2

Introdução
O crescimento exponencial e o
acúmulo das dependências é um
dos maiores desafios em
organizações que empregam as
técnicas de gestão enxuta e
otimização de fluxo, dentre outros
motivos, pela grande dificuldade de
enxergá-las e, consequentemente,
de agir para solução ou mitigação.
As dependências são atritos que
geram filas. Quanto mais autônoma
for a nossa unidade de execução -
item de trabalho + pessoas - mais
eficiente será o fluxo das
atividades.
Pensando na qualidade das
informações e com o foco na
agilidade no processo decisório,
usamos a nossa experiência para
classificar as dependências em
grupos distintos. Os grupos
possuem sua característica, sua
forma de análise e ações, mas pode
acontecer sobreposição de ações e
por isso um fluxo de informações
eficiente deverá ser mantido. As
ações são basicamente kaizens que
deverão ser planejados e
executados dentro de um período
de tempo.

O perigo da falta de visibilidade é

tão grande que é comum o uso de
ações pela gestão que claramente
resultarão na criação de uma ou
mais dependências. Portanto, o
primeiro passo para que a gestão
comece a erradicar essa erva
daninha é a visualização de
informações úteis, desde os fluxos
operacionais até os fluxos
estratégicos, passando pelos fluxos
de portfólio.
Gestão de Dependências: uma visão geral 3

Dependências de fluxo
As dependências de fluxo ocorrem
quando alguma atividade, que será
importante para que o item de
trabalho evolua, não pode ser
executada porque alguma coisa está
impedindo.
Este tipo de bloqueio está
diretamente ligado ao fluxo. São os
mais estudados e mapeados pelas
empresas que fazem a gestão para a
otimização de fluxo.

Dependência entre ítens

Esta dependência ocorre quando, para avançar o item de trabalho, você
depende do trabalho que precisa ser feito em outro item. Uma das
dependências mais destrutivas na operação mas que, em um fluxo organizado e
otimizado, não é difícil de enxergar e agir sobre. A melhoria mais comum neste
tipo de dependência é sobre a quebra dos itens de trabalho em fases
preliminares à construção que, com a análise do mapa dos itens (story map),
seja possível identificar dependências geradas por análise e quebras
excessivas.

Buscando mais a fundo na causa raiz, identificamos que, quando este tipo de
dependência é muito comum, o processo de análise dá muita ênfase em criar
itens bem pequenos, achando que assim estará otimizando o tamanho do lote.
Não, neste caso estão só reduzindo o tamanho do lote o máximo possível, e
não otimizando, o que na verdade apenas esconde o lote verdadeiro, que é o
conjunto de demandas dependentes.

Não estamos dizendo aqui que é possível eliminar completamente as

dependências entre item de trabalhos, pois em alguns casos isso realmente
não só não é possível, como a eliminação desta dependência poderá trazer
consequências ainda piores para a saúde do fluxo, como lotes maiores do que
o tamanho ideal, prejudicando os mecanismos de feedback.
Gestão de Dependências: uma visão geral 4

Apenas mantenha sob controle e tenha certeza de que cada dependência

criada realmente precisa estar ali.

Dependência de revisão
Também muito comum nos fluxos que temos trabalhado, esta porém é mais
perigosa, porque está quase sempre escondida em atividades que não estão
mapeadas no sistema de trabalho. Isso não quer dizer que temos que criar uma
etapa para cada fase de revisão, já que existem outras maneiras para manter os
olhos nelas, como o uso de bloqueios bem organizados e classificados, por
exemplo.

Aqui estão os tipos mais comuns: homologação, testes e code review.

Dos três tipos, nos lugares em que atuamos, é comum criarmos uma etapa
explícita apenas para a homologação, que normalmente tem alguma interação
externa. Os testes são resolvidos por quem constrói e o code review, quando
empregado, é feito na própria etapa de construção, usando bloqueios quando
não há capacidade imediata.

Entretanto, nenhum dos negócios que atuamos representa algum risco de vida
para os usuários. Caso o risco seja alto, aconselhamos criar quantas etapas de
verificação forem necessárias para garantir o funcionamento correto do que
está sendo construído. Perceba, porém, que cada criação de etapa extra gera
dependência e mais atrito, resultando em uma queda no time to market, que
será leve ou acentuada, dependendo da rigidez e burocracia de cada etapa.

Sempre dependendo dos riscos envolvidos, você também pode trocar

completamente o code review pelo pareamento. Com o pareamento cumprimos
com a política de tentarmos sempre a "unidade autônoma de execução" e com
o code review, a unidade dependerá de alguém de fora dela para executar uma
atividade essencial que só então liberará o fluxo.
Gestão de Dependências: uma visão geral 5

Dependência de especificação
Em fluxos disciplinados, não enfrentamos muitos problemas com a visualização
deste tipo de dependência também, que pode ocorrer tanto durante a análise
quanto durante a construção.

Na análise a dependência mais comum é a externa, quando quem tem a

informação necessária está em outro lugar, provavelmente trabalhando em
outras coisas. As ações aqui dependerão da gravidade do problema e do nível
de autonomia que o profissional que está atuando diretamente no produto
tenha. Para melhorar a saúde do fluxo, dependendo dos riscos envolvidos,
algumas decisões podem ser transferidas para quem está fazendo a análise.
Outra solução, que pode ser usada em ambientes de alto risco, é a criação de
uma cadência periódica com as pessoas responsáveis presentes, pois se o risco
é alto, a dedicação também deverá ser.

Durante a construção, as dúvidas do que deve ser feito, às vezes até como deve
ser feito (dependendo do nível de autonomia que as pessoas tenham), são as
principais causas deste tipo de dependência. Aqui a ação que normalmente
adotamos é uma melhoria no processo de análise, com o feedback de quem
está puxando o trabalho. Lembrando que o objetivo final deste kaizen não é
"escrever mais no item", mas escrever o suficiente para que ele seja a unidade
mais autônoma possível.
Gestão de Dependências: uma visão geral 6

Dependências de conhecimento
Neste tipo de dependência, o conhecimento para dar andamento no item
encontra-se em outro lugar. Pode ser alguma solução técnica que está em outro
time, ou alguma métrica gerada em outro produto que será importante para a
construção daquele item.

Nestes casos, o foco deverá estar no espalhamento da informação, da solução

técnica, o mais rápido possível e, possivelmente, a criação de cadências para
que os times se conversem e falem das coisas mais interessantes que
aconteceram na última semana, por exemplo.

Para as métricas de outro produto, uma solução possível está diretamente

ligada ao fluxo e uma boa disciplina e boas políticas no upstream.

Outra variação interessante deste tipo de dependência é quando uma pessoa

troca de times e com isso leva boa parte do conhecimento do produto e do
contexto em que o produto está inserido. Empresas com "gestão de cobertor
curto" vivem sofrendo com este tipo de problema e a cada mudança aumentam
cada vez mais a bola de neve. Outro ponto interessante aqui é que a troca de
time gera impacto direto nos dois times, do mesmo tipo de dependência: a
pessoa que entrou no time novo depende de informações de pessoas que já
estão no time, ao mesmo tempo que ela levou conhecimentos importantes do
outro time. É a gestão orientada por times, e não por serviços, cobrando o seu
preço.

Aqui temos a primeira dependência que o Fluxo Unificado pretende resolver

que, com o foco no produto e não na formação dos times, impede que a gestão,
normalmente distante da operação, tome decisões equivocadas que
aumentarão a dependência entre times.
Gestão de Dependências: uma visão geral
Dependências
burocráticas
Mais comuns nas empresas
tradicionais e por isso mesmo mais
perigosas, também pela falta de
visibilidade, as dependências
burocráticas consistem
basicamente em aprovações
necessárias, normalmente de
outros setores, outras camadas da
gestão, para atividades como
deploy em ambientes (não só
produção), para aprovação de
planilhas de testes, aprovações de
artefatos de homologação,
aprovações de análise.
Esta enxurrada de aprovações
normalmente está presente em
ambientes de baixíssima confiança
e de supervalorização de riscos
que, na maioria das vezes, as
pessoas não sabem nem quais são.
Como o fluxo nessas empresas é
desorganizado, as pessoas não
sabem exatamente quais são os
7
impactos destas políticas e acabam
reagindo aos problemas com cada
vez mais burocracia e tempo de
planejamento.
As soluções para este tipo de
dependência são muito mais
complexas que qualquer outra
apresentada aqui, pois serão
necessários mais passos para que a
solução se apresente. Será
necessária a organização do fluxo e
das políticas, ao mesmo tempo em
que todos os níveis da gestão
trabalhem juntos para a criação e
manutenção de um ambiente
seguro e de confiança. Uma
melhoria mais imediata é o
aprimoramento no processo de
identificação de causas raízes, que
resultará, consequentemente, em
melhores decisões e menos
burocracia desnecessária.
Gestão de Dependências: uma visão geral 8

Dependências de produto
Aqui temos as dependências que ocorrem dentro do escopo do produto,
normalmente entre seus temas e épicos. Ela pode ser de origem técnica, de
negócio ou de gestão. Quando a origem é técnica ou de negócios, a
dependência costuma estar no nível do item de trabalho que, para fluir,
depende de informações ou da construção de itens que se encontram em
outros módulos ou épicos. Normalmente não representa um perigo maior do
que a dependência de item de trabalho.

O perigo aqui está quando a gestão deliberadamente quebra o produto por

times, gerando problemas tribais e, claro, dependências. Este exemplo é uma
clara demonstração, de novo, do foco nos times em vez do foco no serviço que,
por falta de visibilidade e de dados confiáveis, passa despercebido como a
causa raiz de um grupo de problemas.

O ponto positivo aqui é que a decisão sobre esta mudança de mindset, do foco
em times para o foco no serviço, está completamente nas mãos da gestão. As
técnicas do Fluxo Unificado são ferramentas eficientes no auxílio da correção
desses problemas. De todas as dependências apresentadas aqui, esta é a que
mais poderá se beneficiar de tais técnicas.
Gestão de Dependências: uma visão geral 9

Dependências externas
Muito mais complicadas de resolver, as dependências externas são aquelas que
mapeiam necessidades para vazão que estão completamente fora do sistema
de trabalho, estando em clientes, outros fornecedores ou na nuvem.

Ao entender este tipo de dependência, compreendemos quanto é nociva a

quebra excessiva de frentes de atuação. Empresas grandes possuem o hábito
de quebrar um produto em várias frentes de atuação, muitas vezes com
fornecedores diferentes, com isso gerando dependências de produto,
dependências externas, dependências de conhecimento e dependências
burocráticas, isto é, quase todas as dependências de gestão.

Cada fornecedor, assim como cada time, é um sistema diferente que funciona
em acordo com as próprias regras que foram evoluídas no processo de
amadurecimento daquele time. Se existe alguma organização do fluxo de
trabalho, seja tradicional ou moderna, você encontrará um certo nível de
burocracia para entrada de itens no fluxo e cada entrada precisará ser
negociada. Para lidar com este tipo de situação, as empresas empilham
camadas de gestão que serão responsáveis pela coordenação entre os diversos
fornecedores ou entre os diversos times.

Não estamos dizendo aqui que você deverá, a partir da próxima segunda-feira,
unificar a empresa toda em um grande e caótico time, mas sim para considerar
não só se cada quebra é realmente necessária, mas também em como fazer
cada uma delas.

Aqui também as técnicas do Fluxo Unificado podem auxiliar nas tomadas de

decisão. Na verdade, resolver este tipo específico de dependência foi uma das
motivações da estruturação de tais técnicas.
Gestão de Dependências: uma visão geral
Dependências
de Infra
Neste tipo temos mapeadas as
dependências de servidores, locais
ou na nuvem, máquinas locais ou
qualquer dispositivo, físico ou
virtual, que esteja impedindo o
andamento do item de trabalho.
Muito natural na construção de
produtos digitais corporativos, e
por isso possui uma alta
maturidade nas soluções, o
impacto deste tipo de dependência,
entretanto, costuma ser alto,
inviabilizando por completo
qualquer trabalho no fluxo. A
compra de servidores virtualizados
costuma reduzir muito a ocorrência
e a gravidade deste tipo de
bloqueio. Alguns serviços oferecem
10
soluções mais completas e por isso
cobram mais por capacidade de
processamento e memória,
enquanto outros oferecem mais
capacidade por um valor menor,
mas exigem algum conhecimento
técnico para a operação.
As dependências de infra podem
ser bem inconvenientes e podem
representar um risco grande para a
organização, mas tanto as opções,
quanto os pontos positivos e
negativos de cada uma, são de
conhecimento geral e a gestão
atenta não deve ter muitos
problemas para mapear e lidar com
isso.
Gestão de Dependências: uma visão geral 11

Dependências de Arquitetura
Aqui temos dois subtipos mapeados: dependências de arquitetura de código e
dependências de arquitetura da aplicação.

Arquitetura de Código
Aqui temos as dependências que estão diretamente ligadas à má qualidade,
quando não observamos as boas práticas de código. Quando negligenciamos a
coesão de cada unidade de código e aumentamos o acoplamento com outras
unidades, corremos o risco de que a necessidade de mexer em outros lugares
acabe por gerar uma dependência. Em times muito reduzidos, o risco é baixo,
porque a probabilidade de outras pessoas estarem mexendo na mesma porção
de código que precisará ser alterada é baixa.

Entretanto, em times maiores, o problema pode aparecer com mais frequência,

mas mesmo assim o impacto é baixo, frequentemente sendo a questão de um
merge, que pode ser chato, mas com as ferramentas atuais, não costuma ser
um problema realmente grave em empresas organizadas.

Queremos aqui chamar a atenção apenas para o excesso de quebras, no

exemplo pendente, que pode potencializar este tipo de problema, aí sim,
tornando os resultados mais graves e arriscados.

Arquitetura da Aplicação
Neste tipo de dependência, os problemas estão nas definições da arquitetura
da aplicação, que podem deliberadamente gerar dependências entre domínios
mal desenhados. Um outro exemplo seria a decisão de comunicar duas
aplicações através de um Enterprise Service Bus (ESB), e também decidir por
colocar este ESB nas mãos de outro time.
Gestão de Dependências: uma visão geral 12

Neste caso, é provável que tenhamos um time para cada uma das pontas e um
time para o ESB, gerando vários tipos de dependências apresentadas neste
texto.

Um bom entendimento do Domain Driven Design também pode ajudar em

melhores decisões.
Gestão de Dependências: uma visão geral 13

Conclusão
Não estamos aqui estabelecendo
que é possível eliminar todos os
tipos de dependência do sistema
de trabalho. O título deste texto é
"Gestão de Dependências" e não
"Eliminando Dependências" e a
palavra chave é gestão. Se você não
conhece as dependências que
podem ser geradas a partir de uma
decisão e, principalmente, quais as
suas consequências, não
conseguirá realizar uma boa gestão
destas dependências, às vezes,
atirando no escuro para tentar
resolver fantasmas que aparecem
no sistema.
Saber com o que está lidando,
saber os fatores geradores, saber as
consequências e como lidar com
elas é obrigação fundamental de
qualquer gestor, principalmente
dos gestores do trabalho do
conhecimento.

Saiba mais
1. The impact of DEPENDENCIES - and how to MANAGE them
2. A Taxonomy of Dependencies in Agile Software Development
Site

Instagram

LinkedIn

Facebook

YouTube

Tallercast