Supero

Fluxo Unificado

Imagine você chegando na padaria da sua esquina para comprar dois pãezinhos. É uma padaria grande e há 6 atendentes. Cada um deles possui uma fila de espera. Você chega no local, escolhe uma das filas dos atendentes e fica aguardando. Enquanto aguarda você observa outras 8 pessoas chegarem e optarem por filas/atendentes diferentes. Mais um tempo e você presencia 4 dessas 8 pessoas serem atendidas. E já estão indo embora!

Não parece muito justo certo? Aliás, não parece nada eficiente.

Já perceberam quantos destes estabelecimentos já trabalham com fila única? Já notaram como a fila única dos caixas rápido dos supermercados realmente funciona bem? Muitos dos lugares onde vamos hoje (padarias, lojas, bancos), pegamos uma senha e aguardamos o atendimento.

Entretanto, pare e pense: porque não usamos nada parecido em software? Porque sempre queremos trabalhar com vários projetos, cada um no seu próprio silo? Talvez você ache que isso não se aplica ao desenvolvimento de software. Vamos conversar um pouco mais então.

 

O problema

Qual problema que as filas únicas resolvem? VARIABILIDADE. Essa é a palavra. E ela se multiplica e torna-se mais forte num ambiente de outsourcing e fábrica de software. Vamos pensar na seguinte situação. Você tem quatro projetos rodando. Com equipes diferentes.

 

De repente, um dos projetos é bloqueado porque o analista principal do cliente está de férias e ele precisa bater o martelo em algumas definições antes de prosseguir com o projeto. Ou simplesmente porque esse cliente efetuou mais o pagamento combinado no projeto.

 

O que normalmente acontece nesses casos? Temos duas opções:

  • Deixar o pessoal que estava neste projeto sem atividades. O que é péssimo, pois é prejuízo.
  • Realocar o pessoal para dar vazão em atividades de outro projeto. Justamente o que mais acontece.

 

A segunda alternativa parece plausível. Mas é nesse momento que ocorre a Lei de Brooks (Frederick Phillips Brooks, Jr):

“Acrescentar mais pessoas trabalhando num projeto que está atrasado só aumentará o atraso do projeto”

 

Algumas perguntas sobre essa equipe que foi deslocada:

  • O ambiente está montado e configurado?
  • Elas possuem conhecimento de negócio?
  • Elas possuem o conhecimento técnico do projeto?
  • Conhecem os padrões de desenvolvimento e processo deste projeto?

Agora você pode pensar que este cenário é exceção. Mas vamos pensar que da mesma maneira que um projeto é bloqueado, podemos ter pessoas bloqueadas.

E para atender a uma demanda tão urgente de um cliente importante, fazemos o que? O mesmo deslocamento.

 

Neste caso, o projeto que perdeu um recurso foi penalizado no seu throughput (sua saída). E o projeto que recebeu um recurso foi penalizado por um Lei de Brooks aplicada. No final das contas quem paga? O seu cliente!

Podemos citar ainda o alto esforço de coordenação deste fluxo, pois temos:

  • 4 projetos;
  • 4 fluxos;
  • 4 métricas;
  • 4 análises de fluxo;
  • 4 dailies;
  • 4 retrospectivas;
  • 1 melhoria no processo será sempre multiplicada por 4…
  • Etc, etc, etc…

 

A solução

Que tal tentarmos colocar esses projetos em uma fila única com uma equipe “servindo” a todos os projetos?

Neste caso, quando temos um projeto bloqueado o que acontece?

Isso mesmo! A fila tem sua prioridade atualizada e a equipe continua trabalhando normalmente.

E caso tenhamos um “servidor” bloqueado?

Perdemos um pouco no throughput. Mas não é preciso tomar nenhuma medida. O fluxo continua por si só.

 

Ganhos

E aí o que ganhamos? Vamos separar por áreas

Gestão

  • Redução nos custos de coordenação, pois trabalha-se na gestão do fluxo:
  • Definição, manutenção e guarda das restrições;
  • Priorização das demandas;
  • Priorização dos projetos;
  • Maior margem de manobra para lidar com a variabilidade;

Time

  • Elimina-se o impacto da Lei de Brooks:
  • Sem custo de transação;
  • Sem custo de sincronia;
  • Gestão do conhecimento simplificada, pois todos sabem tudo o que está acontecendo e todos podem opinar nas situações mais complexas;
  • Motivação do time em Projetos “LEGAIS” vs Projetos “CHATOS”, pois não haverá pessoas que só pegam “Projetos Legais” e pessoas que só pegam “Projetos Chatos”;
  • Diminui ociosidade caso haja horários de trabalhos diferentes entre pessoas, pois todos consomem a fila.

Processo

  • Inovação/melhorias (CI, DEVOPS, BOAS PRÁTICAS, PROCESSO) acontecem com mais facilidade em todos os projetos;

Cliente

  • Adaptabilidade da equipe em sua capacidade para o cliente:
  • É  possível executar um RUMP UP da produção para um projeto atrasado com a simples priorização da fila.

 

E aí o que acha?

 

Fontes:

https://crafters.cc/startup/por-que-colocar-sua-startup-no-fluxo-unificado/

https://pt.slideshare.net/Tallerws/kanban-no-fluxo-unificado-de-portfolio-de-projetos-agile-brazil-2016