O que é Fluxo Unificado?
Fluxo Unificado é um modelo de fluxo onde projetos fluem pelo mesmo processo e são atendidos pelo mesmo time.
Existe um mito de que um produto deve ser quebrado em times cada vez menores para atender problemas específicos. Muito se fala em autoridade e ownership. Quando um time vira praticamente um apertador de parafusos de um produto, existe ownership?
Imagine uma organização tática que permita mudar o tamanho do seu time e capacidade de um produto do seu portfólio apenas mudando a priorização do seu backlog.
Agora imagine que isso é possível e ainda reduz custos de coordenação e melhora a gestão em ambientes com alta variabilidade. Bacana né?
Foi para resolver esse problema que nasceu o Fluxo Unificado. Vou explicar um pouco melhor como isso funciona.
Quando e porque um Fluxo Unificado é a solução
Sua empresa tem um grande portfólio de produtos para gerenciar ou talvez um grande produto com muitas frentes que são atendidas por muitos times? Qual a variabilidade de tamanho de times (ou squads) você tem?
Talvez você siga à risca os ensinamentos do scrum de 7 a 10 pessoas em um time, mas muitas vezes isso não é viável. Algumas iniciativas têm duas ou três pessoas e outras acabam tendo mais de vinte.
A quantidade de conhecimento necessária varia? Em alguns casos é preciso de pouco conhecimento, fazer cadastros e implementar telas, em outros um conhecimento enorme de performance e otimização ou implementação de algoritmos complexos e orquestração de sistemas.
E quando colocamos múltiplos fornecedores externos interagindo com o seu time, pioramos a situação.
A Variabilidade
É comum pensar que a variabilidade é algo que deve ser evitada ao máximo num projeto ou produto. Quando se olha para a manufatura isso é um fato. Se um item não é igual ao outro chamamos de defeito. Logo, evitar a variabilidade é bom.
O desenvolvimento do produto é diferente. Nele não criamos o produto em si, criamos uma receita para criar aquele produto, seja físico ou digital, através de uma série de experimentações.
Em uma receita de uma torta de limão de uma indústria de doces, a receita é criada por um cozinheiro e é replicada milhares de vezes. A criação da receita envolve muita experimentação, experiência e criatividade.
Se o produto é criado e as vendas não vão bem, algo precisa ser feito. Para tentar melhorar as vendas, o cozinheiro adiciona um pouco de açúcar na receita e um pouco menos de farinha. Essa variabilidade pode aumentar ou diminuir as vendas, então existe um risco, mas sem essas mudanças, o produto não evolui.
Não é possível gerar novo valor para seu produto sem adicionar variabilidade. No caso de produtos digitais, o que varia é o plano. Novas funcionalidades vão entrar, sair ou mudar. Alguns fornecedores vão atrasar a entrega forçando a uma mudança (que pode até ser para melhor) de escopo, bugs irão aparecer, e aquele plano lindão no Gantt Chart que foi aprovado por várias mãos vai pro beleléu.
A variabilidade sempre aparecerá, e com ela o risco embutido. Estar exposto ao risco é uma peça central na criação de valor. O que precisamos é de um processo para acomodá-la, pois, o que importa não é a variabilidade, é o impacto econômico dessa variabilidade.
Conhecendo e se preparando para os piores riscos e deixando os menores acontecer, medindo e analisando continuamente, nos tornamos criadores de valor com base no imprevisto.
Brooks
Quando projetos começam a dar errado, a primeira coisa que os gestores pensam é: “vamos alocar mais pessoas”. O projeto atrasou? Mais pessoas. Mudou o escopo? Mais pessoas. Colocar mais pessoas parece ser a resposta universal que todos estão procurando.
No clássico “O mito do homem-mês”, Fred Brooks cita a famosa frase que veio a ser chamada de “Lei de brooks”.
“Colocar mais pessoas em um projeto já atrasado contribui para atrasar ainda mais o projeto”
Fred Brooks
Ele estabelece que projetos não podem ser particionado perfeitamente em pequenos pedaços discretos que podem ser feitos independentemente.
Sempre que colocamos novas pessoas no projeto, temos uma queda de produtividade devido ao aumento de comunicação necessária para que as novas pessoas entrem no jogo. Resumindo: pessoas que estão produzindo precisam parar para explicar e ensinar o projeto para quem está entrando.
No caso de um projeto já atrasado, eu parar quem está trabalhando para ensinar pessoas novas que levarão alguns dias ou semanas para começar a produzir pode não ser uma boa ideia.
Isso será verdade no caso de alocações curtas, movendo um time para outro projeto por um curto período de tempo. O valor gasto na redução da produtividade pode não compensar a mudança de contexto.
Isso também é válido em outros casos. Cada projeto ou produto ou feature pode ter variações na dificuldade e tamanho, que resultará em variações no tamanho dos times, com projeto menores com poucas pessoas e projetos maiores com muitas e/ou vários times.
Geralmente um gerente médio usa essa abordagem para chegar em um prazo que prometeu para a diretoria. Se faz de tudo para que a entrega seja feita. O resultado é um produto mal feito que é um castelo de cartas. Meses e mais meses apenas resolvendo bugs e problemas de performance enquanto os usuários começam a fugir e sem falar do time, que logo depois de um projeto desses costuma sair correndo para o próximo emprego.
Experiência própria, a tendência é o caos. Até hoje ainda não vi nenhum caso de sucesso com essa abordagem, mas alguns gerentes continuam tentando.
Com toda essa variabilidade fica muito difícil conseguir previsibilidade, já que cada caso é um caso. Quando for passar uma estimativa ou previsão, faço baseada em que?
O problema das filas em projetos de software
Teoria das filas é um ramo da probabilidade que estuda a formação de filas através de análises matemáticas e provê modelos que tornam possível dimensionar sistemas onde a demanda cresce aleatoriamente.
A fila se forma quando a capacidade do sistema é menor que a demanda de itens. É o excesso do sistema. Estamos acostumados com filas no nosso dia a dia: no supermercado, no banco, no trânsito. Um estoque de produtos também pode ser considerado uma fila, pois se vendo tudo que produzo automaticamente, jamais criaria uma fila.
Em todos esses casos as filas são fáceis de serem identificadas. Eu vejo as pessoas na minha frente, eu vejo os carros parados e eu vejo o estoque no depósito da loja. Mas existe um tipo de fila que é um pouco mais difícil de se ver. A fila do trabalho do conhecimento.
O trabalho do conhecimento se dá no mundo das ideias. Quando tenho um estoque alto de ideias, geralmente elas estão em e-mails, notas, chats ou nas inúmeras ferramentas que usamos para gerenciar conhecimento. Elas só são óbvias para poucas pessoas. Toda vez que crio uma nova ideia para um produto, essa ideia não existe fisicamente e automaticamente ela entra em progresso, sendo executada ou não. As filas são o estoque de trabalho em progresso.
Mesmo com métodos de gestão visual, não é tão simples gerenciar a fila. É preciso entender e classificar os tipos de demandas e o risco associado a elas. Não são várias peças de uma mesma máquina. Posso ter um projeto inteiro escondido dentro de um cartão, enquanto o próximo é um pedido para trocar a cor do botão.
Quando um sistema atinge mais de 80% da sua capacidade suas filas são potencialmente infinitas. Pensem nos carros: se 100% da via está tomada por carros, sempre que um carro para, todos os carros param.
Geralmente um trabalho fica mais tempo em filas que em execução, aumentando desnecessariamente o tempo de entrega.
E isso aumenta e muito o risco, pois faz com que o feedback do cliente seja reduzido. Isso cria ainda mais variabilidade, pois um feedback lento nos deixa andar mais longe pelo caminho errado. Isso gera sobrecarga no sistema, pois continuamos tendo que entregar resultados, reduz a qualidade, já que com prazos tão apertados, qualidade para quê?
O pensamento intuitivo é que todos estejam sempre trabalhando e dando seu máximo. Trabalhe duro, trabalhe mais. Porém, se for nas coisas que não geram resultado, não só não adianta quanto prejudica em muito todo o sistema.
Essa dificuldade faz do gerenciamento de filas o principal trabalho do gestor de fluxos.
Gerenciar filas é a chave para melhoramento da economia no desenvolvimento de produtos. (don)
Como o Fluxo Unificado o ajudará a superá-las
O Fluxo Unificado é uma forma de diminuir os impactos econômicos de toda essa variabilidade. Ele é um modelo de fluxo de trabalho baseado nos sistemas puxados da Toyota e na teoria das filas, pensado com base no trabalho de conhecimento de fluxo de produtos do Don Reinertsen.
Ter múltiplos projetos para múltiplos times tem seu risco embutido. Caso cada time tenha sua própria fila, qualquer problema com esse time pode bloquear toda a fila. Se o fornecedor do ERP ou de um parceiro não conseguiu entregar a API de integração a tempo e não consigo puxar nada do projeto sem isso, o que faço com esse time? Ou se esse mesmo time precisa entregar no prazo mas mudanças inesperadas na tecnologia exigiram um esforço maior?
Existem muitos modelos de filas. Os que mais interessam no nosso contexto são:
Uma fila por servidor
Esse modelo é bem comum e pode ser visto nos caixas de supermercados. No nosso mundo é o modelo de um projeto por time. Cada projeto tem sua fila de itens a serem feitos e apenas um time atende a cada fila. Caso alguma fila fique com problemas teremos um servidor ocioso, e se um servidor tiver problemas, ficamos com uma fila parada.
Fila única com múltiplos servidores
Esse modelo também pode ser visto no supermercado no caixa rápido ou em bancos no modelo de senhas. A senha é uma fila única atendida por múltiplos servidores.
Com fila compartilhada, caso um servidor tenha algum problema, todos da fila sentem uma pequena demora. Matematicamente, isso significa que a variação no tempo de atendimento é menor.
“No modelo de uma fila por servidor, um único trabalho com problemas pode bloquear toda a fila.”
Filas compartilhadas levam a menor variância no tempo de processamento e o modelo de uma fila por servidor leva a filas maiores e desnecessárias.
A performance nas duas estruturas de fila são diferentes, mesmo que ambas tenham a mesma demanda e mesma capacidade.
Os novos princípios de fluxo aplicados a múltiplas fontes de demanda atendidas por um único processo de desenvolvimento
Don Reinertsen é um dos autores mais conhecidos e influentes da área de gestão de produtos. Ele influenciou diretamente pessoas como David Anderson no método Kanban e Eric Reis no Lean Startup. Não é pouca coisa né?
No seu último livro, “Principles of Product Development Flow” (sem tradução para o ptbr), ele trata especialmente dos impactos econômicos no desenvolvimento de software, como filas, variabilidade, tamanho de lote e descentralização.
“Podemos servir demandas aleatórias com menos filas se agregarmos essa demanda e servidor com um recurso compartilhado.” Don Reinertsen
Existe um mito que descentralização de recursos é sempre boa. Ter um time 100% alocado em um projeto é um mito que veio com a ascensão dos métodos ágeis, especialmente o Scrum, em que acredita que equipes focadas resultarão em melhores tempos de resposta. Mas isso nem sempre é verdade.
Com uma gestão correta, ambientes com alta variabilidade podem se beneficiar muito com centralização de recursos. Essa centralização é essencial na prevenção da formação de filas inesperadas.
Quando existem demandas variadas de vários projetos, quando a variabilidade dessas demandas é combinada a variabilidade relativa geral é menor que a variabilidade de cada um dos seus componentes.
Lidando com variabilidade no tamanho e nos tempos de chegada das demandas
Trazendo para o nosso mundo: Digamos que você tem 9 desenvolvedores seniores e 9 projetos no seu portfólio. Você poderia colocar um desenvolvedor em cada projeto, e isso é uma boa opção se você tem baixa variabilidade nas demandas. Mas se a variabilidade, como já vimos antes, for alta, a melhor opção é centralizar esses nove desenvolvedores seniores em um único time. Isso vai combinar a variabilidade de cada projeto e reduzir em termos gerais o impacto econômico da variabilidade no nosso sistema.
Pelas pesquisas do Don Reinertsen, isso reduziria a variabilidade mais ou menos em um fator de 3.
Na prática, se você tem 2 projetos, e ambos sofrem com variabilidade, unificar seu fluxo pode reduzir o impacto econômico geral.
Se tenho vários times atendendo a mesma fila, ou um único time maior atendendo a todas, consigo reduzir a variabilidade total mantendo a entrega, mesmo que em uma menor velocidade.
Caso uma grande variabilidade aconteça, como o Projeto Y ter que parar por questões legais ou porque espera a implementação de outro fornecedor, a fila é repriorizada e o time agrupado simplesmente continua trabalhando nas demandas do Projeto X.
Esse tipo de situação é comum no dia a dia das empresas. O mercado anda muito rápido e é preciso agilidade para mudar o plano e atender melhor os clientes.
Conclusão
Cada cliente tem uma pressão diferenciada em um dado momento. Projetos podem ganhar ou perder preferência a qualquer momento dependendo dos mais variados fatores.
Um time fixo para esse tipo de cenário com alta variabilidade é pouco eficiente. Em projetos novos, onde existe a possibilidade de um time estar focado em um determinado projeto por um bom tempo, esse problema não existe.
Mas em cenários onde uma mesma empresa ou departamento precisa criar e dar manutenção, e ainda fazer pequenas criações que surgem a qualquer momento, podemos ter uma vantagem enorme.
Fluxo unificado é uma solução tática que ajuda a reduzir o custo de coordenação global de uma empresa, aumentar a eficiência em alocações e sizing de times e dar vantagens significativas por não precisar gerenciar as pessoas diretamente dando uma grande abertura à autogestão.
Nos próximos artigos vou falar um pouco mais sobre como aplicamos na prática as idéias do fluxo unificado, ferramentas, métricas e problemas que encontramos no caminho.
Enquanto isso, confira nosso Guia Essencial do Fluxo Unificado e assista ao nosso TallerMeetup sobre a experiência da Sof.to com o Fluxo Unificado.