Talvez você também passe por isso: sua equipe entrega de forma contínua, porém os solicitantes nunca conseguem tempo para as validações. Sempre há tempo para pedir coisas novas, mas para validar aquele item de 2 meses atrás parece que estão sempre “na correria” :-D. Acredite ou não, isso é um fato muito comum em muitas empresas.

Os sintomas

O sintoma mais comum da síndrome do cliente ausente pode ser visto no acúmulo de itens na coluna de trabalhos aguardando validação. Outros sintomas podem ser: frequente interrupção da equipe para ajustar trabalhos já entregues; dificuldade de organização das releases; dificuldade na comunicação e na coordenação do fluxo de trabalho.

Em casos mais graves, a síndrome do cliente ausente pode evoluir para uma esquizofrenia seletiva: O cliente reclama de não receber aquilo que não validou!

Além disso, é possível observar ainda baixa moral do time decorrente das não-entregas efetivas; sentimento de “pastelaria”; frustração por não verem valor no trabalho; e o aumento do uso da mesa de pebolim. Este ciclo vicioso tende a se repetir e a “doença” evoluir gerando baixa qualidade e aumento do Lead Time — prejudicando, inclusive, quem não está “infectado”.

Tratamentos caseiros

Times sem influência sobre a agenda do cliente acabam alterando a definição de done para não considerar a etapa de validação do cliente e, assim, partirem para o próximo trabalho. Apesar de criarem uma satisfação virtual imediata, ela logo pode se dissipar quando, de fato, precisam lidar com os ajustes do cliente, re-testes e a preparação para lançamento. Se o time usa Scrum, terá que coordenar esse trabalho parcialmente pronto nas sprints seguintes.

Outro tratamento caseiro é combinar um SLA de validação com o cliente. Caso o cliente não interaja dentro do SLA, o item é considerado finalizado e eventuais ajustes ou não-conformidades entram na fila concorrendo com os demais itens do backlog. Apesar de ser uma solução mais rebuscada, pois traz clareza sobre as políticas do sistema de trabalho, há o inconveniente de se selecionar o que vai para produção, mesmo sem a validação do cliente, e o que precisa ficar aguardando. Se o cliente é realmente ausente e não se importa em descumprir o SLA, quem mais sofre, no final das contas, continua sendo a equipe com seus custos de coordenação.

Tratamento definitivo

Um tratamento doloroso, porém mais efetivo, é aquele que cria skin in the game por parte do cliente. O cliente precisa sentir as consequências de não contribuir com sua parte no fluxo de trabalho num tempo aceitável. Para tanto, vamos mexer naquilo que ele mais gosta: sua capacidade de solicitar coisas novas. Huuuhahaha — <risada aterrorizante>

O conceito, na verdade, é bem simples: cria-se a política de que o time só vai puxar novos itens para serem trabalhados mediante tokens disponíveis e os tokens só ficam disponíveis na medida em que o cliente valida itens finalizados. Pronto. [note style=”” bg=”” border=”” bordercolor=”{{bordercolor}}” color=””] Pense no token como o elemento que informa que há capacidade para o sistema receber mais trabalho. Um bom exemplo desse mecanismo é dado pelo David Anderson em seu livro sobre o Método Kanban: num parque que tem controle de acesso, só entram mais pessoas na medida que saem pessoas. Quando uma pessoa sai do parque ela devolve seu token — sinalizando a possibilidade de outra pessoa entrar no parque. Desta forma o parque define um limite de pessoas que podem estar simultaneamente em seu interior, garantindo, desta forma, limpeza, segurança e uma boa experiência a todos. Esse token também é conhecido como kanban 😉 [/note]

Este mecanismo já é bem conhecido, estamos falando de limitar a quantidade de trabalho em progresso. Entretanto, estamos sugerindo sua utilização num âmbito maior no sentido de equalizar o fluxo de trabalho com o cliente, mostrando explicitamente sua importância no processo, evitando “re-fluxo” e ilusões sobre trabalhos parcialmente prontos, que não agregam valor e só aumentam o custo de coordenação.

O grande artifício, na minha opinião, é não iniciar novos itens sem que o cliente contribua fechando os itens correntes. Nas alternativas “caseiras” criamos controles paralelos para lidar com a ausência do cliente. Nesta última sugestão trazemos o cliente para o fluxo oficial e, apesar dele continuar solicitando novas demandas, elas só entrarão em execução com a interação ativa e diligente da parte dele.

Na prática, portanto, você precisará definir a quantidade de tokens (kanbans) que o seu sistema terá, e iniciar novos itens somente quando novos tokens estiverem disponíveis. Tokens ficam disponíveis mediante a validação do cliente no trabalho, liberando o token que está afixado neste trabalho para ser afixado em um novo que poderá, só assim, entrar para execução do time.

Reunimos nesta sugestão o conceito de fluxo puxado (neste caso incluindo o cliente) e o limite de trabalho em progresso, além de também tratar integridade, qualidade e a postura correta em focar na finalização dos itens abertos.

Essas ideias e insights você encontra no livro Essential Upstream Kanban by Patrick Steyaert , que recomendo a leitura. É gratuito.