A maioria dos gerentes de desenvolvimento de produtos vive em eterna luta para concluir projetos sem estourar prazos e orçamentos. Nunca há recursos suficientes para dar cabo do trabalho e seus chefes exigem cronogramas e resultados previsíveis. Daí o gerente instar a equipe a ser mais parcimoniosa, a traçar planos mais detalhados e a minimizar o desperdício e variações no cronograma. Mas essa abordagem, que pode até funcionar para reerguer uma fábrica de fraco desempenho, pode acabar prejudicando iniciativas de desenvolvimento de produtos.

Embora muitas empresas tratem o desenvolvimento de produtos como se fosse similar à produção, as duas coisas são profundamente distintas.
No mundo da produção de objetos físicos, tarefas são repetitivas, atividades são relativamente previsíveis e itens sendo criados não podem estar em mais de um lugar ao mesmo tempo. Já no desenvolvimento de produtos muitas tarefas são singulares, requisitos do projeto mudam constantemente e o produto final — graças, em parte, ao uso generalizado de ferramentas avançadas de CAD (computer-aided design) e simulação e à incorporação de software em produtos físicos — é a informação, algo que pode estar em vários lugares ao mesmo tempo.

A ignorância sobre essas diferenças críticas deu origem a várias falácias que solapam o planejamento, a execução e a avaliação de projetos de desenvolvimento de produtos. Juntos, passamos mais de 50 anos estudando e assessorando empresas sobre iniciativas de desenvolvimento de produtos, e encontramos essas noções equivocadas — bem como outras, decorrentes de motivos distintos — em uma ampla gama de setores, incluindo semicondutores, automóveis, aparelhos eletrônicos, dispositivos médicos, software e serviços financeiros. Neste artigo, vamos expô-las e sugerir saídas para a superação dos problemas que criam.

 

 

PRIMEIRA FALÁCIA

Alta utilização de recursosmelhorará o desempenho.

Tanto em nossa atividade de pesquisa como no trabalho de consultoria, vimos que a grande maioria das empresas se esforça para empregar plenamente seus recursos de desenvolvimento de produtos (um de nós, Donald, por meio de sondagens feitas em cursos para executivos no California Institute of
Technology, descobriu que o típico gerente de desenvolvimento de produtos mantém a utilização da capacidade acima de 98%). A lógica parece óbvia: um projeto demora mais quando o pessoal não se dedica a ele 100% do tempo — e, portanto, uma organização de desenvolvimento que não para será mais rápida e eficiente do que uma que não for tão boa na utilização da equipe.

 

clique na imagem para ampliar

 

Na prática, porém, essa lógica não se sustenta. Vimos que a velocidade, a eficiência e a qualidade do produto final de um projeto inevitavelmente caem quando gerentes não deixam nenhuma folga para a equipe de desenvolvimento de produtos — não importa o quão tarimbados sejam esses gerentes. A alta utilização produz sérios efeitos negativos, que gestores subestimam por três razões:

Não computam plenamente a variabilidade intrínseca do trabalho de desenvolvimento. Muitos aspectos do desenvolvimento de produtos são imprevisíveis: quando um projeto vai chegar, que tarefas específicas vai exigir, quanto tempo levará para que trabalhadores que nunca fizeram isso antes concluam o trabalho. Empresas, no entanto, em geral estão mais familiarizadas com processos repetitivos como manufatura e processamento de transações, nos quais o trabalho não muda muito e surpresas são poucas e infrequentes. Tais processos se comportam de forma ordenada à medida que a utilização de recursos aumenta. Se houver 5% a mais de trabalho, o prazo para a conclusão será 5% maior.

Processos com alta variabilidade se comportam de modo muito distinto. À medida que a utilização sobe, prazos se alargam drasticamente (veja o quadro “Alta utilização provoca lentidão”). Se houver 5% a mais de trabalho, o tempo exigido para a conclusão pode ser 100% maior. Mas pouca gente entende esse efeito. Em nossa experiência com centenas de equipes de desenvolvimento de produtos, descobrimos que a maioria estava consideravelmente sobrecarregada. Para concluir todo projeto dentro de prazos e orçamentos, certas organizações com as quais trabalhamos teriam de ter pelo menos 50% mais recursos do que tinham.

É verdade que parte da variabilidade é resultado de falta de disciplina e que certas tarefas de desenvolvimento de produtos (como criar componentes para o protótipo de um avião ou conduzir ensaios clínicos) incluem um trabalho mais repetitivo. Mas, ainda que parte do trabalho seja previsível, quando combinado com outro trabalho, imprevisível, vai haver gargalos.

Não entendem como gargalos afetam o desempenho econômico. A alta utilização de recursos inevitavelmente cria filas de projetos. Quando um trabalho parcialmente concluído fica parado, esperando que a capacidade esteja disponível, a duração total do projeto vai aumentar. Filas também retardam o feedback, levando desenvolvedores a seguir mais tempo por caminhos improdutivos. Tornam difícil para a empresa se ajustar a necessidades mutantes do mercado e detectar falhas no produto antes que seja tarde. Ironicamente, são justamente os problemas que, na opinião de gestores, a alta utilização ajudaria a equipe a evitar.

Mesmo quando sabe que está criando filas de projetos, um gerente raramente percebe o custo econômico. Embora tal custo possa ser quantificado, descobrimos que a grande maioria das empresas não o calcula. Gerentes precisam pesar custos de gargalos à luz de custos da capacidade subutilizada para poder achar o equilíbrio certo.

No desenvolvimento de produtos, o estoque intermediário (“work-in-process inventory”) em geral é invisível. Na manufatura, filas consistem de objetos físicos; quando o estoque em uma fábrica dobra, é patente. Não é o caso no desenvolvimento de produtos, onde o estoque consiste basicamente de informação, como documentação de desenho, procedimentos e resultados de testes e instruções para construção de protótipos. Quando o estoque dobra em um processo de engenharia, não há sinais físicos. Além disso, já que normas contábeis exigem que a maioria do estoque de P&D seja registrado a valor zero, demonstrações financeiras não dão nenhuma indicação de sérios excessos de estoque no desenvolvimento de produtos.

É muito difícil combater
u
m problema que não dá para ver ou medir. Vejamos o caso de um grande laboratório farmacêutico. Anos atrás, o novo diretor de descoberta de fármacos enfrentava um dilema de gestão. Assim como outros executivos que dirigem grandes organizações de P&D, estava tentando achar maneiras de tornar seus cientistas mais inovadores. Queria que fizessem mais testes com novos compostos químicos que pudessem gerar medicamentos promissores e, ao mesmo tempo, que eliminassem candidatos pouco promissores o mais cedo possível. Experimentos com organismos vivos, no entanto, eram de responsabilidade do departamento de testes com animais, que não estava sob seu controle e era tocado como um centro de custos. Era avaliado pela eficiência com que usava os recursos de teste, o que naturalmente levava à alta utilização. Logo, cientistas no setor de descoberta de fármacos tinham de esperar de três a quatro meses por resultados de testes que levavam pouco mais de uma semana para realizar. A organização de testes “bem administrada” impedia o progresso da unidade de descoberta.

A solução óbvia para um problema desses é criar um “buffer” de capacidade em processos altamente variáveis. Certas empresas há muito sabem disso. Durante décadas, a 3M vem programando o pessoal de desenvolvimento de produtos para trabalhar a 85% da capacidade. Já o Google é famoso por deixar que 20% do tempo (um dia por semana) de seus engenheiros seja dedicado a qualquer coisa que queiram — prática que significa que haverá capacidade a mais disponível caso um projeto se atrase. Pelo que vimos, no entanto, esse tipo de solução é muito difícil de implementar. Como iremos mostrar, poucas organizações resistem à tentação de usar cada tiquinho da capacidade disponível. Sempre que veem um tempo livre, gerentes automaticamente criam mais trabalho.

Mas há outras soluções viáveis:

Mudar sistemas de controle da gestão. No caso da farmacêutica, talvez fosse preciso tomar medidas para alinhar os objetivos da unidade de testes com animais com os da unidade de descoberta. O laboratório poderia, por exemplo, premiar a área de testes com animais por respostas rápidas (medindo o tempo da solicitação à conclusão do teste), e não pela utilização de recursos.

Aumentar seletivamente a capacidade. Adicionar recursos em áreas nas quais a taxa de utilização é de 70% ou mais pode reduzir consideravelmente o tempo de espera. Se fizesse isso na unidade de testes com animais, a farmacêutica teria uma resposta sobre novos compostos químicos muito mais depressa. Em ambientes nos quais testes são feitos com modelagem e simulação por computador, aumentar a capacidade em geral custa relativamente pouco, pois envolve apenas a compra de equipamentos de informática e licenças de software.

Limitar número de projetos ativos. Ainda que não pudesse aumentar a capacidade da área de testes com animais, a farmacêutica poderia reduzir a taxa de utilização se derrubasse o número de projetos ativos de exploração de novos compostos químicos. A disciplina de impor estritos limites àquilo que entra no pipeline de desenvolvimento de produtos costuma resultar em um foco maior e em prioridades mais claras.

Tornar estoque intermediário mais fácil de enxergar. Um método consiste em utilizar painéis de controle visuais. Há várias formas, mas o segredo é usar algo físico, como um Post-it, para representar o trabalho de desenvolvimento (veja o quadro “Típico painel de controle do trabalho em curso”). Um painel de controle deveria exibir todo trabalho ativo e mostrar em que estado cada parte do projeto está. Deve estar no centro do processo de gestão da equipe. Uma equipe pode se reunir durante 15 minutos por dia na frente de um painel desses para coordenar iniciativas e manter o trabalho avançando.

 

 

SEGUNDA FALÁCIA

Processar trabalho em grandes lotes melhora a matemática do processo de desenvolvimento.

Um segundo motivo de gargalos no desenvolvimento de produtos é o tamanho de lotes. Digamos que um novo produto seja composto de 200 componentes. Se quisesse, a pessoa poderia projetar e fabricar todas as 200 peças antes de testar qualquer uma delas. Já se projetasse e fabricasse apenas 20 componentes antes de iniciar os testes, o lote seria 90% menor. Isso teria um efeito profundo no tempo em fila, pois a fila média em um processo é diretamente proporcional ao tamanho do lote.

A redução do tamanho de lotes é um princípio fundamental da produção enxuta. Lotes pequenos permitem ao fabricante ter menos material em processo e acelerar o feedback — o que, por sua vez, melhora a duração de ciclos, a qualidade e a eficiência. Pequenos lotes têm utilidade ainda maior no desenvolvimento de produtos, mas poucos desenvolvedores entendem o poder desse método.

Uma razão é a natureza do fluxo de trabalho. De novo, já que a informação que estão produzindo é basicamente invisível para eles, o tamanho do lote também o é. Além disso, desenvolvedores parecem ter um pendor inerente para usar grandes lotes — possivelmente porque acreditam, erroneamente, que grandes lotes produzem economias de escala.

Em um processo bem gerido, o tamanho do lote irá equilibrar custos de transação e de manter estoque (veja o quadro “Como determinar o tamanho ideal de um lote”). É como ao comprar ovos no supermercado. Se comprar um estoque para 12 meses de uma só vez, o custo da transação será baixo, mas a maioria dos ovos vai estragar, aumentando o custo de manter o estoque. Já se for comprando apenas para um dia, a perda por estrago será baixa, mas os custos de transação serão altos. Intuitivamente, a pessoa tenta achar um equilíbrio entre os dois.

Empresas que entendem como isso funciona estão explorando avanços em TI para reduzir o tamanho de lotes, não raro com resultados espetaculares. Certas fabricantes de software que costumavam testar grandes lotes de código a cada 90 dias agora estão testando lotes bem menores várias vezes ao dia. Uma fabricante de periféricos que aplicava abordagem similar na unidade de software derrubou a duração do ciclo de teste de software em 95% (de 48 meses para 2,5 meses), melhorou a eficiência em 220% e reduziu falhas em 33%. A queda em custos foi duas vezes maior do que esperava. Tais resultados foram excepcionais, mas descobrimos que reduzir o tamanho de lotes contribui consideravelmente para a maioria dos projetos de desenvolvimento. Na mesma veia, ferramentas informatizadas de modelagem e simulação reduziram drasticamente o tamanho ideal de lotes para experimentos e teste em empresas que criam produtos físicos.

TERCEIRA FALÁCIA

Nosso plano de desenvolvimento é ótimo, é só seguir fiel a ele.

Em todo nosso trabalho de consultoria e pesquis

a, jamais encontramos um projeto de desenvolvimento de produtos cujos requisitos tivessem permanecido estáveis ao longo do processo. Não obstante, muitas organizações depositam uma fé exagerada nos próprios planos. Atribuem desvios à má gestão e execução e, para minimizá-los, cotejam estritamente cada passo com metas e marcos intermediários. Tal mentalidade até serve para atividades altamente repetitivas em processos de produção estabelecidos. Mas pode levar a resultados ruins na inovação em produtos, na qual novos insights são gerados diariamente e condições estão sempre mudando.

Um estudo clássico de resolução de problemas técnicos feito por Thomas Allen, do MIT, destaca a natureza fluida do trabalho de desenvolvimento. Allen descobriu que engenheiros que vinham desenvolvendo um subsistema aeroespacial criaram e avaliaram uma série de alternativas de projeto antes de optar por aquela que julgavam ser a melhor. Ao longo do caminho, suas preferências foram mudando com frequência devido ao teste e aperfeiçoamento de soluções técnicas alternativas. Isso é típico de projetos de inovação: testes e experimentos revelam o que funciona ou não — e premissas iniciais sobre custos e valor podem acabar sendo refutadas.

Definir necessidades de clientes também pode ser difícil no início de um projeto de desenvolvimento de produtos. Se formos pensar, não surpreende: para um cliente, não é fácil especificar com precisão a necessidade de soluções que ainda nem existem. Aliás, a familiaridade com recursos de produtos atuais pode interferir na capacidade do indivíduo de expressar a necessidade de um novo produto. Preferências de clientes também podem mudar abruptamente ao longo de um projeto de desenvolvimento, com concorrentes lançando novidades e novas tendências surgindo.

Por isso tudo, seguir fiel ao plano original — por mais excelente que seja sua concepção e hábil sua execução — pode ser um tiro no próprio pé. Isso não quer dizer que não acreditemos em planejamento. O desenvolvimento de produtos é um conjunto de atividades complexas que requerem cuidadosa coordenação e atenção ao menor dos detalhes. No entanto, o plano deve ser tratado como uma hipótese inicial — hipótese constantemente revista à medida que surgirem evidências, premissas econômicas mudarem e a oportunidade for reavaliada (veja “O processo do captor de valor”, de Rita Gunther McGrath e Thomas Keil, HBR Maio 2007).

QUARTA FALÁCIA

Quanto antes o projeto começar, mais cedo será concluído.

Como dissemos lá atrás, tempo ocioso é anátema para gerentes, que tendem a explorar qualquer intervalo de inatividade com o lançamento de um novo projeto. Ainda que a tarefa não possa ser concluída porque o pessoal precisa retomar outro projeto, o gestor raciocina que qualquer coisa feita no novo projeto é trabalho que não precisará ser feito mais tarde. Esse raciocínio leva muita empresa a lançar mais projetos do que poderia tocar com determinação, diluindo recursos.

Essa diluição é perigosa. Se embarcar em um projeto antes de contar com recursos para seguir em frente, a empresa vai avançar com vacilação pelo processo de desenvolvimento. É um problema, pois o trabalho de desenvolvimento de produtos é altamente perecível: hipóteses sobre tecnologias e o mercado podem rapidamente ficar obsoletas. Quanto mais lentamente um projeto avança, maior a probabilidade de que seja redirecionado. Aliás, um braço das forças armadas americanas descobriu que estouros de custo e cronograma eram exponencialmente proporcionais (à quarta potência) à duração de um projeto. Ou seja, quando a duração original de um projeto dobrava, custos e prazos aumentavam por um fator de 16.

A importância de reduzir a quantidade de material em processo é evidente quando olhamos para uma das fórmulas clássicas da teoria das filas: a lei de
Little, que simplesmente sustenta que, em média, a duração do ciclo é proporcional ao tamanho da fila dividido pela velocidade de processamento. Logo, se 20 pessoas estão à sua frente na fila do Starbucks e o barista está servindo cinco pessoas por minuto, você será atendido em quatro minutos. É possível encurtar o ciclo aumentando o ritmo de processamento ou reduzindo o número de trabalhos em curso. Na maioria dos cenários, esta última opção é a única viável.

Para certos desenvolvedores de produtos, a solução é controlar rigorosamente o ritmo ao qual iniciam trabalhos, casando-o com o ritmo ao qual o trabalho é realizado; administrar cuidadosamente o número de projetos em curso; certificar-se de que, quando iniciado, um projeto conte com gente suficiente até ser concluído; e resistir à tentação de subtrair recursos de um projeto em curso para abrir espaço para outros.

 

clique na imagem para ampliar

 

QUINTA FALÁCIA

Quanto mais recursos incluirmos em um produto, mais satisfeito ficará o cliente.

Equipes de desenvolvimento de produtos parecem acreditar que acrescentar recursos cria valor para o usuário e subtraí-los destrói valor. Essa postura explica por que certos produtos são tão complicados: controles remotos parecem impossíveis de usar, computadores levam horas para configurar, carros têm tantos comandos e botões que lembram o cockpit de um avião e até a modesta torradeira agora vem com manual e telas de LCD.

Empresas que questionam a tese de que mais é melhor criam produtos elegantes em sua simplicidade. A fabricante dinamarquesa de produtos de áudio, vídeo e telefonia Bang & Olufsen sabe que o público não quer necessariamente estar ajustando equalizador, balanço e outros controles para achar a configuração ideal para ouvir música. Suas sofisticadas caixas de som automaticamente fazem ajustes necessários para reproduzir uma música com a maior fidelidade possível em relação ao original. Ao usuário, resta apenas ajustar o volume.

Convencer empresas a aceitar e a aplicar o princípio de que menos pode ser mais é difícil porque requer esforço adicional em duas áreas do desenvolvimento de produtos:

Definir problema. Formular o problema que desenvolvedores tentarão solucionar é a parte mais subestimada do processo de inovação. Muitas empresas dedicam pouquíssimo tempo a essa tarefa. É, contudo, uma fase importante, pois é nela que a equipe adquire uma compreensão clara de suas metas e traça hipóteses que podem ser testadas e buriladas por meio de experimentos. A qualidade do enunciado de um problema faz toda a diferença na capacidade da equipe de se concentrar nos poucos recursos que realmente importam.

Quando estava planejando a Disneylândia, Walt Disney não tratou de incluir mais recursos (brinquedos, variedade de comida, quantidade de estacionamento) do que outros parques de diversões já tinham. Em vez disso, começou com uma pergunta muito maior: de que maneira a Disneylândia poderia garantir uma experiência mágica ao público? A resposta obviamente não veio da noite para o dia; exigiu estudos de mercado minuciosos, experimentação constante e profundos insights sobre o que significava “mágica” para a Disney e seu público. A IDEO e outras empresas possuem etapas exclusivas para mergulharem completamente no contexto no qual o produto ou serviço imaginado será utilizado. Seus desenvolvedores leem tudo de interesse sobre o mercado, observam e entrevistam futuros usuários, analisam coisas que irão competir com o novo produto e sintetizam tudo o que descobriram em imagens, modelos e diagramas. O resultado são insights profundos sobre clientes — insights que são testados, aprimorados ou abandonados ao longo do processo iterativo de desenvolvimento.

Decidir o que ocultar ou omitir. Equipes volta e meia sucumbem à tentação de se exibir com a produção de soluções técnicas brilhantes que maravilham colegas e chefes. Em geral, no entanto, o usuário prefere um produto que simplesmente funcione sem atropelos. Do ponto de vista do cliente, as melhores soluções resolvem um problema do modo mais simples e ocultam o trabalho do qual desenvolvedores tanto se orgulham.

Uma empresa que entendeu isso é a Apple. Embora famosa por muitas coisas — produtos inovadores, desenho moderno e marketing astuto —, seu maior forte talvez seja a capacidade de chegar ao cerne de um problema (veja “As verdadeiras lições de liderança de Steve Jobs”, de Walter Isaacson, na edição de abril). É como explicou certa vez o falecido ​​Jobs: “Quando começa a analisar um problema e a impressão é que é muito simples, você na verdade não entende a complexidade do problema. E suas soluções são simplistas demais. Aí você mergulha no problema, e vê que é realmente complicado. E cria todas essas soluções elaboradas (…). É onde a maioria das pessoas para”. Não a Apple, que segue inquirindo. “A pessoa realmente espetacular vai continuar insistindo”, disse Jobs, “e achar (…) o princípio fundamental na base do problema e chegar a uma solução bonita, elegante e que funcione”.

Definir que recursos omitir é tão importante quanto — e talvez até mais do que — descobrir quais incluir. Infelizmente, muitas empresas, no afã de ser inovadoras, incluem tudo quanto é recurso possível e imaginável sem considerar plenamente fatores importantes como o valor para o usuário e a facilidade de uso. Quando essas empresas omitem alguma funcionalidade planejada, em geral é porque precisam cortar custos ou estouraram prazos, ou porque a equipe falhou de alguma outra forma.

Em vez disso, gestores deviam buscar descobrir se a exclusão de algum recurso proposto poderia melhorar um determinado produto e permitir que a equipe se concentrasse em coisas que realmente melhorariam a experiência geral do usuário. É algo que pode ser determinado se a empresa tratar cada suposto requisito como hipótese e testá-la em pequenos e rápidos experimentos com potenciais clientes.

Equipes de desenvolvimento costumam imaginar que um produto está concluído quando nenhum outro recurso pode ser adicionado. Talvez a lógica devesse ser o inverso: um produto se aproxima da perfeição quando nenhum outro recurso pode ser eliminado. É como disse certa vez Leonardo da Vinci: “A simplicidade é a suprema sofisticação”.

 

 

SEXTA FALÁCIA

Teremos mais sucesso se acertarmos já na primeira vez.

Muitos projetos de desenvolvimento de produtos não cumprem metas de orçamento, cronograma e desempenho técnico. Mau planejamento, processos rígidos e liderança fraca sem dúvida desempenham um papel. Mas outra causa, frequentemente ignorada, é a exigência de superiores de que a equipe “acerte já na primeira vez”. Exigir sucesso na primeira tentativa faz a equipe pender para soluções menos arriscadas, ainda que o cliente não as considere um grande avanço em relação ao que já está disponível. Pior ainda, a equipe tem pouco incentivo para buscar soluções inovadoras para problemas de clientes.

Para evitar cometer erros, uma equipe segue um processo linear no qual cada etapa (especificar, projetar, fabricar, testar, expandir, lançar) é cuidadosamente monitorada em pontos de controle. O trabalho na fase seguinte não pode começar enquanto o projeto não passar por aquele controle. À medida que o projeto avança, compromissos consideráveis são assumidos e o custo de responder a novas informações sobe por ordens inteiras de grandeza. O sucesso de testes em fases posteriores é festejado, e surpresas, por maior valor que tenham, são consideradas reveses. Infelizmente, um fluxo linear desses pode causar atrasos no projeto, já que o feedback de testes demora a chegar, equipes se aferram a más ideias por mais tempo do que deveriam e problemas não são descobertos até que saia caro resolvê-los.

Ser tolerante com o “erro na primeira vez” pode ser a melhor estratégia — desde que o pessoal itere rápida e frequentemente e aprenda rapidamente com os erros. Graças a avanços em tecnologias de simulação e rápida prototipagem, agir desse modo é muito mais fácil e menos oneroso.

Vejamos o que descobrimos em um estudo de 391 equipes que projetavam circuitos integrados sob medida. Equipes que seguiam uma abordagem iterativa e faziam testes frequentes desde cedo cometiam mais erros ao longo do caminho. Mas, já que usavam tecnologias de prototipagem de baixo custo, superavam (em termos de tempo e esforço exigidos) equipes que tentavam acertar no projeto logo na primeira tentativa. Equipes que tinham custos elevados de prototipagem investiam mais energia na especificação, no desenvolvimento e na verificação. E, já que faziam iterações mais adiante no processo — e bem menos iterações —, só iam descobrir problemas críticos mais tarde.

Provar muitas ideias distintas é crucial para projetos de inovação. Quando as pessoas experimentam com rapidez e frequência, muitos conceitos novos irão malograr, é claro. Mas esse insucesso inicial pode ser desejável, pois ​​permite que a equipe elimine opções ruins rapidamente e se concentre em alternativas mais promissoras.

Um teste de colisão que mostre que um modelo de carro é perigoso, um possível fármaco que se prova tóxico ou a interface de usuário de um soft-
ware que confunde o cliente podem ser resultados desejáveis — desde que ocorram logo cedo no processo, quando poucos recursos foram comprometidos, o projeto ainda é bem flexível e outras soluções podem ser testadas.

Um exemplo clássico das vantagens de “errar cedo e com frequência” é a surpreendente vitória da equipe New Zealand na

regata America’s Cup em 1995. Para testar ideias para melhorar o projeto da quilha, a equipe usou dois barcos quase idênticos: um deles foi modificado no decorrer do projeto e o outro, de “controle”, não. Todo dia, a equipe simulava hipóteses em uma estação de trabalho gráfica local, aplicava o que parecia promissor ao primeiro barco, competia com o outro, de controle, e analisava ​​os resultados. Em comparação, uma equipe adversária, a Dennis Conner — que tinha acesso a computadores mais possantes (supercomputadores da Boeing) —, fez grandes lotes de simulação no intervalo de semanas e, em seguida, testou possíveis soluções em um barco. O resultado: a equipe New Zealand concluiu muito mais ciclos de aprendizagem, eliminou ideias pouco promissoras mais depressa e acabou batendo o Young America, o barco da Dennis Conner.

O que esperamos que esteja ficando claro a essa altura é que experimentos cujo resultado é ruim não são necessariamente experimentos malogrados. Geram informações novas, que um inovador fora incapaz de prever. Quanto mais rápido o ciclo de experimentação, mais feedback pode ser colhido e incorporado a novas rodadas de experimentos com ideias novas, potencialmente arriscadas. Nesse cenário, funcionários tendem a perseverar quando a situação aperta, se envolver em trabalhos mais desafiadores e superar colegas avessos ao risco.

Mas criar esse tipo de ambiente não é fácil — tema que Amy C. Edmondson, da Harvard Business School, explorou em “Estratégias para aprender com o erro” (HBR Abril 2011). O insucesso pode levar a constrangimentos e expor lacunas no conhecimento, o que pode abalar a autoestima de indivíduos e sua posição na organização. Afinal, com que frequência um gerente é promovido e equipes recompensadas pela exposição precoce de falhas que levam um projeto a ser abortado (ainda que a rápida realocação de preciosos recursos beneficie a empresa)? Isso vale especialmente para organizações que cultivaram um ambiente de “tolerância zero a erros” ou “livre de erros” (Six Sigma).

Thomas Alva Edison entendeu isso tudo. Edison organizou seus célebres laboratórios em torno do conceito da rápida experimentação, instalando
o maquinário para a construção de modelos perto de locais onde experimentos eram feitos, a fim de que maquinistas pudessem cooperar estreitamente com pesquisadores. Os laboratórios tinham bibliotecas com um vasto número de obras para que a informação pudesse ser encontrada depressa; armazéns próximos com um vasto volume de suprimentos; e uma diversificada força de trabalho de artesãos, cientistas e engenheiros. Edison queria ter certeza de que, quando ele ou alguém da equipe tivessem uma ideia, esta poderia imediatamente ser convertida em um modelo de trabalho ou protótipo. “A verdadeira medida do sucesso é o número de experimentos que podem ser feitos em 24 horas”, declarou.

AVANÇOS NA TECNOLOGIA DA INFORMAÇÃO, como o desenho, a modelagem e a simulação por computador, já permitiram que empresas fizessem grandes progressos no desenvolvimento de produtos melhores em menos tempo e a um custo menor. Muitas, no entanto, ainda não exploraram o pleno potencial dessas ferramentas, pois suas ideias sobre a gestão não evoluíram tão depressa quanto a tecnologia: ainda abordam o trabalho de desenvolvimento de produtos — altamente variável, gerador de informações — como se fosse a manufatura. Com o avanço na área de TI continuando, a oportunidade de melhorar o processo de desenvolvimento de produtos ficará ainda maior. Mas o mesmo se pode dizer do risco para empresas que não reconhecem que o desenvolvimento de produtos é profundamente distinto da manufatura. 

 

Stefan Thomke é titular da cátedra William Barclay Harding Professor of Business Administration na Harvard Business School, nos EUA.

Donald Reinertsen é presidente da Reinertsen & Associates, consultoria com sede na Califórnia. Seu último livro é The Principles of Product Development Flow (Celeritas Publishing, 2009).

Share with your friends









Submit