Seis mitos do desenvolvimento de produtos

Escrito por:

Stefan Thomke Donald Reinertsen

segunda-feira, 7 maio, 2012 - 20:22 Comentrios (0)

A maioria dos gerentes de desenvolvimento de produtos vive em eterna luta para concluir projetos sem estourar prazos e oramentos. Nunca h recursos suficientes para dar cabo do trabalho e seus chefes exigem cronogramas e resultados previsveis. Da o gerente instar a equipe a ser mais parcimoniosa, a traar planos mais detalhados e a minimizar o desperdcio e variaes no cronograma. Mas essa abordagem, que pode at funcionar para reerguer uma fbrica de fraco desempenho, pode acabar prejudicando iniciativas de desenvolvimento de produtos. Embora muitas empresas tratem o desenvolvimento de produtos como se fosse similar produo, as duas coisas so profundamente distintas. No mundo da produo de objetos fsicos, tarefas so repetitivas, atividades so relativamente previsveis e itens sendo criados no podem estar em mais de um lugar ao mesmo tempo. J no desenvolvimento de produtos muitas tarefas so singulares, requisitos do projeto mudam constantemente e o produto final graas, em parte, ao uso generalizado de ferramentas avanadas de CAD (computer-aided design) e simulao e incorporao de software em produtos fsicos a informao, algo que pode estar em vrios lugares ao mesmo tempo. A ignorncia sobre essas diferenas crticas deu origem a vrias falcias que solapam o planejamento, a execuo e a avaliao 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 noes equivocadas bem como outras, decorrentes de motivos distintos em uma ampla gama de setores, incluindo semicondutores, automveis, aparelhos eletrnicos, dispositivos mdicos, software e

servios financeiros. Neste artigo, vamos exp-las e sugerir sadas para a superao dos problemas que criam.

PRIMEIRA FALCIA Alta utilizao de recursosmelhorar o desempenho. Tanto em nossa atividade de pesquisa como no trabalho de consultoria, vimos que a grande maioria das empresas se esfora para empregar plenamente seus recursos de desenvolvimento de produtos (um de ns, Donald, por meio de sondagens feitas em cursos para executivos no California Institute of Technology, descobriu que o tpico gerente de desenvolvimento de produtos mantm a utilizao da capacidade acima de 98%). A lgica parece bvia: um projeto demora mais quando o pessoal no se dedica a ele 100% do tempo e, portanto, uma organizao de desenvolvimento que no para ser mais rpida e eficiente do que uma que no for to boa na utilizao da equipe.

clique na imagem para ampliar

Na prtica, porm, essa lgica no se sustenta. Vimos que a velocidade, a eficincia e a qualidade do produto final de um projeto inevitavelmente caem quando gerentes no

deixam nenhuma folga para a equipe de desenvolvimento de produtos no importa o quo tarimbados sejam esses gerentes. A alta utilizao produz srios efeitos negativos, que gestores subestimam por trs razes: No computam plenamente a variabilidade intrnseca do trabalho de desenvolvimento. Muitos aspectos do desenvolvimento de produtos so imprevisveis: quando um projeto vai chegar, que tarefas especficas vai exigir, quanto tempo levar para que trabalhadores que nunca fizeram isso antes concluam o trabalho. Empresas, no entanto, em geral esto mais familiarizadas com processos repetitivos como manufatura e processamento de transaes, nos quais o trabalho no muda muito e surpresas so poucas e infrequentes. Tais processos se comportam de forma ordenada medida que a utilizao de recursos aumenta. Se houver 5% a mais de trabalho, o prazo para a concluso ser 5% maior. Processos com alta variabilidade se comportam de modo muito distinto. medida que a utilizao sobe, prazos se alargam drasticamente (veja o quadro Alta utilizao provoca lentido). Se houver 5% a mais de trabalho, o tempo exigido para a concluso pode ser 100% maior. Mas pouca gente entende esse efeito. Em nossa experincia com centenas de equipes de desenvolvimento de produtos, descobrimos que a maioria estava consideravelmente sobrecarregada. Para concluir todo projeto dentro de prazos e oramentos, certas organizaes 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 prottipo de um avio ou conduzir ensaios clnicos) incluem um trabalho mais repetitivo. Mas, ainda que parte do trabalho seja previsvel, quando combinado com outro trabalho, imprevisvel, vai haver gargalos. No entendem como gargalos afetam o desempenho econmico. A alta utilizao de recursos inevitavelmente cria filas de projetos. Quando um trabalho parcialmente concludo fica parado, esperando que a capacidade esteja disponvel, a durao total do projeto vai aumentar. Filas tambm retardam o feedback, levando desenvolvedores a seguir mais tempo por caminhos improdutivos. Tornam difcil para a empresa se ajustar a necessidades mutantes do mercado e detectar falhas no produto antes que seja tarde. Ironicamente, so justamente os problemas que, na opinio de gestores, a alta utilizao ajudaria a equipe a evitar. Mesmo quando sabe que est criando filas de projetos, um gerente raramente percebe o custo econmico. Embora tal custo possa ser quantificado, descobrimos que a grande maioria das empresas no o calcula. Gerentes precisam pesar custos de gargalos luz de custos da capacidade subutilizada para poder achar o equilbrio certo. No desenvolvimento de produtos, o estoque intermedirio (work-in-process inventory) em geral invisvel. Na manufatura, filas consistem de objetos fsicos; quando o estoque em uma fbrica dobra, patente. No o caso no desenvolvimento de produtos, onde o estoque consiste basicamente de informao, como documentao de desenho, procedimentos e resultados de testes e instrues para construo de prottipos. Quando o estoque dobra em um processo de engenharia, no h sinais fsicos. Alm disso, j que normas contbeis exigem que a maioria do estoque de P&D seja registrado a valor zero, demonstraes financeiras no do nenhuma indicao de srios excessos de estoque no desenvolvimento de produtos. muito difcil combater um problema que no d para ver ou medir. Vejamos o caso de um grande laboratrio farmacutico. Anos atrs, o novo diretor de descoberta de frmacos enfrentava um dilema de gesto. Assim como outros executivos que dirigem grandes organizaes de P&D, estava tentando achar maneiras de tornar seus cientistas mais

inovadores. Queria que fizessem mais testes com novos compostos qumicos que pudessem gerar medicamentos promissores e, ao mesmo tempo, que eliminassem candidatos pouco promissores o mais cedo possvel. Experimentos com organismos vivos, no entanto, eram de responsabilidade do departamento de testes com animais, que no estava sob seu controle e era tocado como um centro de custos. Era avaliado pela eficincia com que usava os recursos de teste, o que naturalmente levava alta utilizao. Logo, cientistas no setor de descoberta de frmacos tinham de esperar de trs a quatro meses por resultados de testes que levavam pouco mais de uma semana para realizar. A organizao de testes bem administrada impedia o progresso da unidade de descoberta. A soluo bvia para um problema desses criar um buffer de capacidade em processos altamente variveis. Certas empresas h muito sabem disso. Durante dcadas, 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 prtica que significa que haver capacidade a mais disponvel caso um projeto se atrase. Pelo que vimos, no entanto, esse tipo de soluo muito difcil de implementar. Como iremos mostrar, poucas organizaes resistem tentao de usar cada tiquinho da capacidade disponvel. Sempre que veem um tempo livre, gerentes automaticamente criam mais trabalho. Mas h outras solues viveis: Mudar sistemas de controle da gesto. No caso da farmacutica, talvez fosse preciso tomar medidas para alinhar os objetivos da unidade de testes com animais com os da unidade de descoberta. O laboratrio poderia, por exemplo, premiar a rea de testes com animais por respostas rpidas (medindo o tempo da solicitao concluso do teste), e no pela utilizao de recursos. Aumentar seletivamente a capacidade. Adicionar recursos em reas nas quais a taxa de utilizao de 70% ou mais pode reduzir consideravelmente o tempo de espera. Se fizesse isso na unidade de testes com animais, a farmacutica teria uma resposta sobre novos compostos qumicos muito mais depressa. Em ambientes nos quais testes so feitos com modelagem e simulao por computador, aumentar a capacidade em geral custa relativamente pouco, pois envolve apenas a compra de equipamentos de informtica e licenas de software. Limitar nmero de projetos ativos. Ainda que no pudesse aumentar a capacidade da rea de testes com animais, a farmacutica poderia reduzir a taxa de utilizao se derrubasse o nmero de projetos ativos de explorao de novos compostos qumicos. 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 intermedirio mais fcil de enxergar. Um mtodo consiste em utilizar painis de controle visuais. H vrias formas, mas o segredo usar algo fsico, como um Post-it, para representar o trabalho de desenvolvimento (veja o quadro Tpico 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 gesto 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 avanando.

SEGUNDA FALCIA Processar trabalho em grandes lotes melhora a matemtica 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 peas 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 mdia em um processo diretamente proporcional ao tamanho do lote. A reduo do tamanho de lotes um princpio fundamental da produo enxuta. Lotes pequenos permitem ao fabricante ter menos material em processo e acelerar o feedback o que, por sua vez, melhora a durao de ciclos, a qualidade e a eficincia. Pequenos

lotes tm utilidade ainda maior no desenvolvimento de produtos, mas poucos desenvolvedores entendem o poder desse mtodo. Uma razo a natureza do fluxo de trabalho. De novo, j que a informao que esto produzindo basicamente invisvel para eles, o tamanho do lote tambm o . Alm 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 transao 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 transao 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 transao sero altos. Intuitivamente, a pessoa tenta achar um equilbrio entre os dois. Empresas que entendem como isso funciona esto explorando avanos em TI para reduzir o tamanho de lotes, no raro com resultados espetaculares. Certas fabricantes de software que costumavam testar grandes lotes de cdigo a cada 90 dias agora esto testando lotes bem menores vrias vezes ao dia. Uma fabricante de perifricos que aplicava abordagem similar na unidade de software derrubou a durao do ciclo de teste de software em 95% (de 48 meses para 2,5 meses), melhorou a eficincia 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 simulao reduziram drasticamente o tamanho ideal de lotes para experimentos e teste em empresas que criam produtos fsicos. TERCEIRA FALCIA Nosso plano de desenvolvimento timo, s seguir fiel a ele. Em todo nosso trabalho de consultoria e pesquisa, jamais encontramos um projeto de desenvolvimento de produtos cujos requisitos tivessem permanecido estveis ao longo do processo. No obstante, muitas organizaes depositam uma f exagerada nos prprios planos. Atribuem desvios m gesto e execuo e, para minimiz-los, cotejam estritamente cada passo com metas e marcos intermedirios. Tal mentalidade at serve para atividades altamente repetitivas em processos de produo estabelecidos. Mas pode levar a resultados ruins na inovao em produtos, na qual novos insights so gerados diariamente e condies esto sempre mudando. Um estudo clssico de resoluo de problemas tcnicos 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 srie de alternativas de projeto antes de optar por aquela que julgavam ser a melhor. Ao longo do caminho, suas preferncias foram mudando com frequncia devido ao teste e aperfeioamento de solues tcnicas alternativas. Isso tpico de projetos de inovao: testes e experimentos revelam o que funciona ou no e premissas iniciais sobre custos e valor podem acabar sendo refutadas. Definir necessidades de clientes tambm pode ser difcil no incio de um projeto de desenvolvimento de produtos. Se formos pensar, no surpreende: para um cliente, no fcil especificar com preciso a necessidade de solues que ainda nem existem. Alis, a familiaridade com recursos de produtos atuais pode interferir na capacidade do indivduo de expressar a necessidade de um novo produto. Preferncias de clientes tambm podem

mudar abruptamente ao longo de um projeto de desenvolvimento, com concorrentes lanando novidades e novas tendncias surgindo. Por isso tudo, seguir fiel ao plano original por mais excelente que seja sua concepo e hbil sua execuo pode ser um tiro no prprio p. Isso no quer dizer que no acreditemos em planejamento. O desenvolvimento de produtos um conjunto de atividades complexas que requerem cuidadosa coordenao e ateno ao menor dos detalhes. No entanto, o plano deve ser tratado como uma hiptese inicial hiptese constantemente revista medida que surgirem evidncias, premissas econmicas mudarem e a oportunidade for reavaliada (veja O processo do captor de valor, de Rita Gunther McGrath e Thomas Keil, HBR Maio 2007). QUARTA FALCIA Quanto antes o projeto comear, mais cedo ser concludo. Como dissemos l atrs, tempo ocioso antema para gerentes, que tendem a explorar qualquer intervalo de inatividade com o lanamento de um novo projeto. Ainda que a tarefa no possa ser concluda porque o pessoal precisa retomar outro projeto, o gestor raciocina que qualquer coisa feita no novo projeto trabalho que no precisar ser feito mais tarde. Esse raciocnio leva muita empresa a lanar mais projetos do que poderia tocar com determinao, diluindo recursos. Essa diluio perigosa. Se embarcar em um projeto antes de contar com recursos para seguir em frente, a empresa vai avanar com vacilao pelo processo de desenvolvimento. um problema, pois o trabalho de desenvolvimento de produtos altamente perecvel: hipteses sobre tecnologias e o mercado podem rapidamente ficar obsoletas. Quanto mais lentamente um projeto avana, maior a probabilidade de que seja redirecionado. Alis, um brao das foras armadas americanas descobriu que estouros de custo e cronograma eram exponencialmente proporcionais ( quarta potncia) durao de um projeto. Ou seja, quando a durao original de um projeto dobrava, custos e prazos aumentavam por um fator de 16. A importncia de reduzir a quantidade de material em processo evidente quando olhamos para uma das frmulas clssicas da teoria das filas: a lei de Little, que simplesmente sustenta que, em mdia, a durao do ciclo proporcional ao tamanho da fila dividido pela velocidade de processamento. Logo, se 20 pessoas esto sua frente na fila do Starbucks e o barista est servindo cinco pessoas por minuto, voc ser atendido em quatro minutos. possvel encurtar o ciclo aumentando o ritmo de processamento ou reduzindo o nmero de trabalhos em curso. Na maioria dos cenrios, esta ltima opo a nica vivel. Para certos desenvolvedores de produtos, a soluo controlar rigorosamente o ritmo ao qual iniciam trabalhos, casando-o com o ritmo ao qual o trabalho realizado; administrar cuidadosamente o nmero de projetos em curso; certificar-se de que, quando iniciado, um projeto conte com gente suficiente at ser concludo; e resistir tentao de subtrair recursos de um projeto em curso para abrir espao para outros.

clique na imagem para ampliar

QUINTA FALCIA 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 usurio e subtra-los destri valor. Essa postura explica por que certos produtos so to complicados: controles remotos parecem impossveis de usar, computadores levam horas para configurar, carros tm tantos comandos e botes que lembram o cockpit de um avio 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, vdeo e telefonia Bang & Olufsen sabe que o pblico no quer necessariamente estar ajustando equalizador, balano e outros controles para achar a configurao ideal para ouvir msica. Suas sofisticadas caixas de som automaticamente fazem ajustes necessrios para reproduzir uma msica com a maior fidelidade possvel em relao ao original. Ao usurio, resta apenas ajustar o volume. Convencer empresas a aceitar e a aplicar o princpio de que menos pode ser mais difcil porque requer esforo adicional em duas reas do desenvolvimento de produtos: Definir problema. Formular o problema que desenvolvedores tentaro solucionar a parte mais subestimada do processo de inovao. Muitas empresas dedicam pouqussimo tempo a essa tarefa. , contudo, uma fase importante, pois nela que a equipe adquire uma compreenso clara de suas metas e traa hipteses que podem ser testadas e buriladas por meio de experimentos. A qualidade do enunciado de um problema faz toda a diferena na capacidade da equipe de se concentrar nos poucos recursos que realmente importam.

Quando estava planejando a Disneylndia, Walt Disney no tratou de incluir mais recursos (brinquedos, variedade de comida, quantidade de estacionamento) do que outros parques de diverses j tinham. Em vez disso, comeou com uma pergunta muito maior: de que maneira a Disneylndia poderia garantir uma experincia mgica ao pblico? A resposta obviamente no veio da noite para o dia; exigiu estudos de mercado minuciosos, experimentao constante e profundos insights sobre o que significava mgica para a Disney e seu pblico. A IDEO e outras empresas possuem etapas exclusivas para mergulharem completamente no contexto no qual o produto ou servio imaginado ser utilizado. Seus desenvolvedores leem tudo de interesse sobre o mercado, observam e entrevistam futuros usurios, analisam coisas que iro competir com o novo produto e sintetizam tudo o que descobriram em imagens, modelos e diagramas. O resultado so insights profundos sobre clientes insights que so testados, aprimorados ou abandonados ao longo do processo iterativo de desenvolvimento. Decidir o que ocultar ou omitir. Equipes volta e meia sucumbem tentao de se exibir com a produo de solues tcnicas brilhantes que maravilham colegas e chefes. Em geral, no entanto, o usurio prefere um produto que simplesmente funcione sem atropelos. Do ponto de vista do cliente, as melhores solues 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 lies de liderana de Steve Jobs, de Walter Isaacson, na edio de abril). como explicou certa vez o falecido Jobs: Quando comea a analisar um problema e a impresso que muito simples, voc na verdade no entende a complexidade do problema. E suas solues so simplistas demais. A voc mergulha no problema, e v que realmente complicado. E cria todas essas solues elaboradas (). onde a maioria das pessoas para. No a Apple, que segue inquirindo. A pessoa realmente espetacular vai continuar insistindo, disse Jobs, e achar () o princpio fundamental na base do problema e chegar a uma soluo bonita, elegante e que funcione. Definir que recursos omitir to importante quanto e talvez at mais do que descobrir quais incluir. Infelizmente, muitas empresas, no af de ser inovadoras, incluem tudo quanto recurso possvel e imaginvel sem considerar plenamente fatores importantes como o valor para o usurio 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 excluso de algum recurso proposto poderia melhorar um determinado produto e permitir que a equipe se concentrasse em coisas que realmente melhorariam a experincia geral do usurio. algo que pode ser determinado se a empresa tratar cada suposto requisito como hiptese e test-la em pequenos e rpidos experimentos com potenciais clientes. Equipes de desenvolvimento costumam imaginar que um produto est concludo quando nenhum outro recurso pode ser adicionado. Talvez a lgica devesse ser o inverso: um produto se aproxima da perfeio quando nenhum outro recurso pode ser eliminado. como disse certa vez Leonardo da Vinci: A simplicidade a suprema sofisticao.

SEXTA FALCIA Teremos mais sucesso se acertarmos j na primeira vez. Muitos projetos de desenvolvimento de produtos no cumprem metas de oramento, cronograma e desempenho tcnico. Mau planejamento, processos rgidos e liderana fraca sem dvida desempenham um papel. Mas outra causa, frequentemente ignorada, a exigncia de superiores de que a equipe acerte j na primeira vez. Exigir sucesso na primeira tentativa faz a equipe pender para solues menos arriscadas, ainda que o cliente no as considere um grande avano em relao ao que j est disponvel. Pior ainda, a equipe tem pouco incentivo para buscar solues inovadoras para problemas de clientes. Para evitar cometer erros, uma equipe segue um processo linear no qual cada etapa (especificar, projetar, fabricar, testar, expandir, lanar) cuidadosamente monitorada em pontos de controle. O trabalho na fase seguinte no pode comear enquanto o projeto no passar por aquele controle. medida que o projeto avana, compromissos considerveis

so assumidos e o custo de responder a novas informaes sobe por ordens inteiras de grandeza. O sucesso de testes em fases posteriores festejado, e surpresas, por maior valor que tenham, so 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 ms ideias por mais tempo do que deveriam e problemas no so descobertos at que saia caro resolv-los. Ser tolerante com o erro na primeira vez pode ser a melhor estratgia desde que o pessoal itere rpida e frequentemente e aprenda rapidamente com os erros. Graas a avanos em tecnologias de simulao e rpida prototipagem, agir desse modo muito mais fcil 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 esforo exigidos) equipes que tentavam acertar no projeto logo na primeira tentativa. Equipes que tinham custos elevados de prototipagem investiam mais energia na especificao, no desenvolvimento e na verificao. E, j que faziam iteraes mais adiante no processo e bem menos iteraes , s iam descobrir problemas crticos mais tarde. Provar muitas ideias distintas crucial para projetos de inovao. Quando as pessoas experimentam com rapidez e frequncia, muitos conceitos novos iro malograr, claro. Mas esse insucesso inicial pode ser desejvel, pois permite que a equipe elimine opes ruins rapidamente e se concentre em alternativas mais promissoras. Um teste de coliso que mostre que um modelo de carro perigoso, um possvel frmaco que se prova txico ou a interface de usurio de um software que confunde o cliente podem ser resultados desejveis desde que ocorram logo cedo no processo, quando poucos recursos foram comprometidos, o projeto ainda bem flexvel e outras solues podem ser testadas. Um exemplo clssico das vantagens de errar cedo e com frequncia a surpreendente vitria da equipe New Zealand na regata Americas Cup em 1995. Para testar ideias para melhorar o projeto da quilha, a equipe usou dois barcos quase idnticos: um deles foi modificado no decorrer do projeto e o outro, de controle, no. Todo dia, a equipe simulava hipteses em uma estao de trabalho grfica local, aplicava o que parecia promissor ao primeiro barco, competia com o outro, de controle, e analisava os resultados. Em comparao, uma equipe adversria, a Dennis Conner que tinha acesso a computadores mais possantes (supercomputadores da Boeing) , fez grandes lotes de simulao no intervalo de semanas e, em seguida, testou possveis solues 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 no so necessariamente experimentos malogrados. Geram informaes novas, que um inovador fora incapaz de prever. Quanto mais rpido o ciclo de experimentao, mais feedback pode ser colhido e incorporado a novas rodadas de experimentos com ideias novas, potencialmente arriscadas. Nesse cenrio, funcionrios tendem a perseverar quando a situao aperta, se envolver em trabalhos mais desafiadores e superar colegas avessos ao risco. Mas criar esse tipo de ambiente no fcil tema que Amy C. Edmondson, da Harvard Business School, explorou em Estratgias 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 indivduos e sua posio na organizao. Afinal, com que frequncia um gerente promovido e equipes recompensadas pela exposio precoce de falhas que levam um projeto a ser abortado (ainda que a rpida realocao de preciosos recursos beneficie a empresa)? Isso vale especialmente para organizaes que cultivaram um ambiente de tolerncia zero a erros ou livre de erros (Six Sigma). Thomas Alva Edison entendeu isso tudo. Edison organizou seus clebres laboratrios em torno do conceito da rpida experimentao, instalando o maquinrio para a construo de modelos perto de locais onde experimentos eram feitos, a fim de que maquinistas pudessem cooperar estreitamente com pesquisadores. Os laboratrios tinham bibliotecas com um vasto nmero de obras para que a informao pudesse ser encontrada depressa; armazns prximos com um vasto volume de suprimentos; e uma diversificada fora de trabalho de artesos, cientistas e engenheiros. Edison queria ter certeza de que, quando ele ou algum da equipe tivessem uma ideia, esta poderia imediatamente ser convertida em um modelo de trabalho ou prottipo. A verdadeira medida do sucesso o nmero de experimentos que podem ser feitos em 24 horas, declarou. AVANOS NA TECNOLOGIA DA INFORMAO , como o desenho, a modelagem e a simulao 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 no exploraram o pleno potencial dessas ferramentas, pois suas ideias sobre a gesto no evoluram to depressa quanto a tecnologia: ainda abordam o trabalho de desenvolvimento de produtos altamente varivel, gerador de informaes como se fosse a manufatura. Com o avano 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 no reconhecem que o desenvolvimento de produtos profundamente distinto da manufatura. Stefan Thomke titular da ctedra William Barclay Harding Professor of Business Administration na Harvard Business School, nos EUA. Donald Reinertsen presidente da Reinertsen & Associates, consultoria com sede na Califrnia. Seu ltimo livro The Principles of Product Development Flow (Celeritas Publishing, 2009).

HBR Reprint R1205DP