Estou lidando com os resultados de um experimento fracassado com engenharia simultânea baseada em conjunto (SBCE – do inglês, set-based concurrent engineering). Como especialista das operações de desenvolvimento de produtos, entendo que os experimentos do desenvolvimento lean de produtos e processos (LPPD) nem sempre resultam em sucesso – mas minha equipe de liderança não entende isso. Como posso ajudá-los a entender que o fracasso no LPPD não é perda total?
O primeiro passo de que sempre falamos é: “qual era o objetivo do experimento e fomos muito claros com a equipe de gestão quanto a o que estávamos tentando provar?”. Muitas vezes, no início do projeto, dizemos: “vamos fazer um experimento com projeto baseado em conjunto para vermos seus benefícios” e deixamos em aberto. E, como em qualquer coisa que é deixada em aberto, isso leva a muitas expectativas diferentes de pessoas diferentes na organização – aqueles que estão mais familiarizados com o LPPD obviamente terão uma expectativa mais realista quanto a o que resultará do projeto baseado em conjunto; os gerentes seniores certamente estarão mais interessados no resultado final, que pode acontecer no curto prazo ou, dependendo do desenvolvimento de produtos, pode acontecer após anos.
Então, pela perspectiva deles, se não estiverem vendo resultados instantâneos, eles podem enxergar o experimento como sendo um fracasso, enquanto os resultados ainda podem estar por vir. Ou esse pode ser um fracasso no qual havia um experimento conduzido com uma meta específica, que não foi alcançada.
No último caso, é importante lembrar que SEMPRE há algo a se aproveitar. Muito raramente temos uma completa e total falta de aprendizados em um experimento. Se tivermos, provavelmente não fizemos algo ou apenas nos prendemos ao status quo.
A primeira coisa que normalmente se deve fazer é uma boa reflexão com a equipe que conduziu o experimento para analisar o que deu certo e o que não deu.
Então, você pode conduzir uma reunião com a equipe de gestão para compartilhar suas descobertas. E acho que é nesse momento que começamos a entender que o copo ou está meio vazio ou meio cheio.
Lembro-me de uma época em que tivemos um experimento fracassado que foi visto como sendo um fracasso. Mas, quando o grupo fez uma reflexão, não era um fracasso tão grande quanto parecia. Uma equipe estava fazendo um experimento baseado em conjunto em certo projeto, e, na metade, os requerimentos regulatórios mudaram o projeto. E, quando os requerimentos mudaram, os parâmetros também mudaram, e a equipe foi forçada a mudar a direção do projeto naquele momento.
Agora, a percepção da organização – a “fala durante as conversas informais”, se você preferir – era que a equipe estava realmente tendo dificuldades com o projeto baseado em conjunto, já que obviamente tiveram de mudar a direção. Eles achavam que aquilo era um fracasso no projeto baseado em conjunto.
Interessantemente, quando sentamos com a equipe para discutir esse fracasso, a equipe não chamou de fracasso – ela chamou de soluço! Eles disseram: “Claro, é verdade que mudamos a direção do projeto, mas em apenas dois dos cinco conjuntos com os quais estávamos trabalhando”. Mas a verdadeira percepção da organização de que a equipe havia fracassado se dava ao fato de que os indicadores de custo do projeto aumentaram. As pessoas interpretavam os resultados não sendo alcançados como um reflexo de quão mal a equipe executou o projeto. Mas, assim que equipe explicou os resultados diretamente para a equipe de liderança, a resposta foi: “Ah. Isso faz sentido. Sem problemas – continuem trabalhando no projeto”. Um dos diretores até repetiu a explicação da equipe para o resto da organização.
Por minha experiência, você precise de pelo menos três ou quatro experimentos antes de a organização começar a entender profundamente as nuances da SBCE. E eles aprendem tanto com os sucessos quanto com os fracassos a fim de serem capazes de definir, em seus próprios termos, como a SBCE se parece em sua própria comunidade de desenvolvimento de produtos.
Agora, vamos falar sobre o que você pode fazer para gerenciar as expectativas da liderança enquanto o experimento é conduzido. Você não deve esperar até o final do experimento para informar a gestão sobre seu progresso. Se você fizer isso, poderá se desapontar, os resultados podem levar muitos meses ou anos – e, até onde sabemos, a gestão gosta de enxergar os resultados rapidamente.
Você deve ter muitos pontos de contato onde possa falar sobre o processo. Quando estamos fazendo um experimento no desenvolvimento de produtos – ou no lean em geral –, devemos estar tão interessados no processo quanto nos indicadores. Devemos ter contato com a gestão mais periodicamente quando passarmos pelo processo a fim de informá-la se o processo está em controle ou desviando. E é certamente aí que pode ser útil ter um comitê de direção ou um champion da liderança a quem possamos nos dirigir, porque, se a equipe tem um problema, precisa haver uma organização ou grupo específico a quem possam recorrer quando precisarem. É uma forma muito efetiva de evitar ter de contar à gestão sobre seu “fracasso” em retrospectiva.