Uma Stand-up meeting padrão serve para reportar acontecimentos. E reportar acontecimentos na verdade não nos obriga a pensar.
Apenas ouvir relatórios que não são necessariamente da nossa conta também é bastante entediante. Mesmo que seja por apenas 15 minutos. Quem vem participando regularmente de Stand-up meetings entende bem esse sentimento (veja It's Not Just Standing Up: Patterns for Daily Standup Meetings).
As três perguntas padrão para uma stand-up meeting ("O que eu fiz ontem? O que eu vou fazer hoje? Quais são meus obstáculos?") não nos obriga a proagir. Sugiro alterá-las para apenas uma pergunta:
"O que eu vou melhorar a seguir?"
A idéia é fazer com que cada um reflita sobre: "O que eu vou fazer para solucionar o problema que eu estou enfrentando no momento?". É muito mais interessante discutir propostas de soluções do que relatórios de problemas.
É comum as equipes de desenvolvimento terem um monte de opiniões sobre como solucionar os problemas do dia-a-dia das empresas. Mas, infelizmente, na maioria das vezes o que acontece é que os desenvolvedores simplesmente não falam sobre isso.
O ambiente de uma empresa precisa estar acessível as soluções propostas por seus funcionários. Se a equipe de desenvolvimento não é encorajada a oferecer soluções e nem tem a autoridade para implementá-las, o interesse em propô-las é rapidamente perdido.
Quadro de Melhorias x Quadro de Tarefas
O conceito de melhoria aqui neste contexto tem dois aspectos:
Primeiro, a equipe de desenvolvimento geralmente é quem tem a consciência das melhores soluções para os problemas de um software, porque os desenvolvedores são as pessoas que possuem o contato mais profundo com o código fonte. Por isso, é muito importante para um ambiente de desenvolvimento Lean promover a mentalidade proativa nos desenvolvedores, ao invés de "Aqui temos o quadro de tarefas que os desenvolvedores estão executando como se fossem robôs".
E o segundo aspecto é que, por outro lado, além de garantir que os desenvolvedores estejam sendo ouvidos nas soluções propostas para o software, no desenvolvimento Lean também é muito importante que o usuário final seja diretamente envolvido nessas discussões. Porque se uma tarefa simplesmente não agrega valor nenhum para o usuário final, mesmo que seja uma excelente solução, ainda sim normalmente não passa de um desperdício de tempo e dinheiro.
No comments:
Post a Comment