Protótipos iniciais podem prejudicar a criatividade da equipe

No desenvolvimento de produtos, uma ferramenta popular é o protótipo rápido e sujo. Como os protótipos simples tornam concreto o abstrato, eles podem orientar as conversas dos inovadores e concentrar sua atenção, ajudando-os a avançar. Mas muitas empresas rapidamente os seguem com protótipos polidos - e o problema começa. Pesquisas que realizei no setor automobilístico mostram que, quando as pessoas veem um protótipo detalhado, algo estranho acontece: Elas se concentram na forma e na função do protótipo, esquecendo-se de prestar atenção a quaisquer ambiguidades remanescentes sobre o problema que o produto deve resolver ou os obstáculos no caminho. Em vez de esclarecer o caminho a seguir, o protótipo interrompe o brainstorming útil. Isso ocorre porque, quando um produto tecnológico complexo está sendo desenvolvido, os grupos envolvidos geralmente tentam prosseguir em uníssono, sem perceber que não concordam com o que levou ao projeto em primeiro lugar ou com o que está impedindo sua conclusão. Essa "cegueira da inovação" causa conflitos e atrasos e pode acabar com o projeto. Como as organizações podem evitar essa armadilha? Nas fases iniciais do desenvolvimento, elas devem manter a ambiguidade inerente a qualquer desafio tecnológico, avançando somente depois que todos tiverem clareza sobre quais problemas o produto deve resolver e como. Em uma montadora dos EUA que estudei, um produto que havia sido engavetado devido à cegueira da inovação foi ressuscitado pelo retorno à ambiguidade. Todas as pessoas com quem me reuni, desde gerentes até engenheiros, concordaram que a análise de simulação de colisões - bater representações computadorizadas de veículos em paredes virtuais - deveria desempenhar um papel mais importante no desenvolvimento de produtos, a fim de aumentar a segurança e reduzir custos. Muitos departamentos, trabalhando juntos, tiveram a ideia de criar uma ferramenta baseada em computador que aumentaria a precisão das análises e ajudaria os tomadores de decisão a avaliar os projetos. Mas, apesar da aparente concordância em relação ao objetivo geral, ainda havia discordâncias básicas. Por exemplo, um grupo de desenvolvedores achava que o que era necessário para atingir a meta era uma engenharia mais rápida. Outro achava que eram dados mais precisos. Quando um protótipo detalhado foi construído, a discussão rapidamente se transformou em argumentos. "Todos diziam: 'Por que ele não tem esse ou aquele recurso?", contou-me um participante. As discussões se estenderam por anos. "Foi uma época brutal", disse outro. Foi preciso a chegada de um novo gerente - alguém com uma nova perspectiva - para ressuscitar a ferramenta. Como o gerente viu um problema completamente diferente do que os outros haviam visto, ele inadvertidamente reinjetou ambiguidade no pensamento. Lidar com essa ambiguidade forçou as pessoas a pararem de simplesmente defender os recursos do protótipo. O protótipo foi abandonado, os grupos definiram claramente o que precisavam resolver e a ferramenta foi construída. A TI agora está ajudando os engenheiros a projetar carros e caminhões mais seguros. Embora os protótipos muitas vezes facilitem para os desenvolvedores traduzirem seus conhecimentos uns para os outros, eles podem impedir o progresso se forem muito detalhados cedo demais. As organizações precisam manter alguma ambiguidade até que os grupos tenham concordado não apenas com as metas, mas também com as dificuldades fundamentais em questão. No início, o mantra de um gerente deve ser: "Não quero ouvir soluções. Quero ouvir sobre os problemas que nosso produto precisa resolver".

Protótipos iniciais podem prejudicar a criatividade da equipe

Partner Center