Gostaria de abordar um tema que comentamos muito pouco na gestão de fluxo de trabalho, a dependência entre os itens de trabalho. Já escrevi sobre a dependência entre fluxo e times, porém creio que nunca tratei o caso de dependência interna que acontece quando para entregar o Item B, primeiro o time deverá entregar o Item A.
Eu sei, eu sei. No mundo ideal os itens de trabalho deveriam respeitar o I do INVEST.
I – Independente
N – Negociável
V – Valioso
E – Estimável
S – Small (Pequena)
T – Testável
Entretanto, no mundo real, infelizmente nem sempre conseguimos a total independência entre um item e outro. O que fazer nesses casos? Deixar as dependências entre os itens o mais claro possível.
Por que classificar as dependências?
Gostaria de passar o porquê acredito ser uma boa prática identificar as dependências antes de iniciarmos a construção de um item de trabalho. Os motivos são:
Priorização
Vamos dizer que seu time tem um backlog com três itens: A, B, C. Para o seu cliente, os itens A e B são muito valiosos. O seu time acredita que eles exigiram pouco esforço e por isso, eles foram para o topo da priorização. Eles também perceberam que o item C é fundamental para a entrega de A e B, porém o cliente não percebe tanto valor nele e ele exigirá um certo esforço de construção. Nesse caso, mesmo tendo menos valor e exigindo mais esforço, o item C deverá ser feito antes de A e B, pois ele é essencial para a construção de ambos.
Vou dar um caso concreto e relativamente comum. Imagine que alguém na sua empresa solicitou alguns relatórios e você precisará primeiro capturar os dados, normalizá-los, carregá-los em uma base de dados antes de entregar os relatórios. O seu cliente deseja os relatórios que ele te pediu, mas nenhum deles pode ser construído sem antes a captura, normalização e carga. Então, embora o cliente não perceba o valor real dessas atividades, elas serão prioritárias na construção de qualquer relatório.
Previsibilidade
Se você tem um item muito importante, mas para ele ser entregue há muitas dependências, você já sabe que a entrega dele deve considerar as entregas das dependências. Isso é fundamental para estabelecer prazos e gerir a expectativa com o seu cliente.
Fatiamento
No melhor caso, todos os itens devem ser independentes entre si. Se na hora que construímos o backlog, percebemos que há muita dependência entre eles, podemos concluir que o fatiamento (divisão dos itens de trabalho em itens menores que entregam valor para o cliente) que fizemos desses está com problemas. Será um bom indicativo de que devemos voltar, analisá-los e refatiá-los para que se tornem mais independentes e continuem entregando valor para o cliente.
Estabilidade
Uma das piores coisas que acontecem no trabalho é começar a fazer algo e no meio do caminho perceber que será necessário parar e fazer outra coisa que habilitará a entrega da primeira. Isso gera retrabalho, perda de foco e atrasos. Logo, identificar as dependências antes de começar é o ideal para que o fluxo de trabalho se mantenha estável e sem interrupções ao longo do tempo.
Qualidade
Está relacionado à estabilidade e a questão de manter a quantidade de trabalho em progresso em um nível aceitável. Se toda hora o time tem que parar para resolver uma dependência, ele perde o foco e a qualidade do produto ou serviço tende a baixar.
Como classificar as dependências
Nem toda dependência é igual e por isso é interessante saber quais classes normalmente eu gosto de trabalhar. Obviamente essa não é uma lista exaustiva, é apenas o que eu utilizo no meu dia a dia.
Independentemente
Mar de almirante e céu de brigadeiro. É isso que as pessoas gestoras de produto devem buscar incessantemente. Se o item é independente, obviamente ele pode ser construído em qualquer ordem que for necessária. Quanto mais independente for o seu backlog, melhor será a gestão do fluxo de trabalho.
Convivência
Infelizmente, nem todos os itens serão totalmente independentes, mas também nem todos são totalmente dependentes uns dos outros. Há um tipo de vínculo entre os itens que chamo de ligação leve. Eles podem ser construídos totalmente independentes entre si. Caso um fique pronto antes do outro, eles podem até ser entregues em momentos distintos, porém seria muito bom se fossem entregues juntos.
Um exemplo prático é quando você constrói filtros em uma consulta do seu sistema. Por exemplo, digamos que o Item 1 seja “Filtrar pelo nome” e o Item 2: “Filtrar pela categoria do produto”. Um não depende do outro, podem ser entregues em momentos diferentes, porém seria de bom tom que fossem entregues juntos. Outro exemplo são meios de pagamento, por exemplo cartão de crédito e PIX. Não precisam ser entregues juntos, mas seria interessante que fossem.
Ligação
Aqui os itens podem ser construídos de forma totalmente independentes, porém só podem ser entregues juntos. É comum em contextos que tratam de demandas de regulamentação. Vou dar um exemplo, na Justiça é comum que o lançamento de um serviço digital de atendimento ao cidadão seja sempre acompanhado de um serviço físico para a mesma finalidade. Isso acontece por causa do princípio jurídico de isonomia e acesso à justiça em que o direito de uma pessoa com acesso a meios digitais não se sobreponha ao de quem não consegue acessar um serviço digital.
Bloqueio
O nome deixa bem claro. Para que um item seja construído, primeiro o item que o bloqueia deve ser concluído. Aqui não há paralelismo, poiso item bloqueante deve ser concluído antes do item bloqueado. O exemplo que eu dei anteriormente sobre a necessidade de obter, normalizar e carregar dados antes de construir relatórios é um exemplo de dependência de bloqueio.
Espera
Esse aqui eu confesso que já usei, é uma tag aqui do fluxo, mas há alguns anos que ninguém o utiliza. Ele acontece quando um item pode ir até uma determinada etapa do fluxo de trabalho, porém para prosseguir, ele deve esperar que outro item chegue até o mesmo ponto ou outro ponto do fluxo de trabalho. Um exemplo é quando dividimos mal um determinado item de trabalho e acabamos com duas camadas em vez de duas fatias que entregavam valor. O primeiro item era a interface com o usuário (tela) e o segundo item eram os serviços web que integravam com os dados. Para que a tela (item mais rápido) fosse entregue, os serviços web deveriam estar totalmente concluídos.
No nosso dia a dia, essa classe perdeu um pouco de sentido, mas pode fazer sentido em outro contexto. Por exemplo, se você tem que fazer a instalação elétrica de uma casa, o eletricista pode trabalhar na conexão rua-casa enquanto o pedreiro prepara o encanamento nas paredes. Perceba que a entrega do serviço do eletricista só se conclui quando o encanamento elétrico estiver totalmente pronto.
Conclusão
Compreender e classificar as dependências entre itens de trabalho não é apenas uma prática de organização, mas uma estratégia essencial para a saúde do fluxo. Dependências mal identificadas se transformam em obstáculos que atrasam entregas, reduzem a qualidade e minam a previsibilidade.
O objetivo final não é eliminar todas as dependências, isso seria utópico, mas sim reduzir ao máximo os bloqueios e lidar com os demais de forma consciente e planejada. Quanto mais o backlog se aproxima da independência, maior a fluidez, a previsibilidade e a satisfação do cliente.
Em resumo, tratar dependências com seriedade é investir em foco, qualidade e valor entregue.
Se esqueci de algo, entre em contato comigo lá no LinkedIn.
