DESENVOLVIMENTO DE PRODUTOS E PROCESSOS

Antecipando atividades (uploading) no Desenvolvimento de Produtos

Todos que participam do processo de desenvolvimento de produtos estão familiarizados, de alguma forma, com a agonia da mudança nos últimos estágios, chamada de loopbacks (retrabalhos). Seja um fracasso inesperado no teste de protótipos ou um problema de manufatura que aparece durante o início da produção ou um problema com a garantia, fazer mudanças no projeto ou na engenharia tardiamente produz uma quantidade assombrosa de desperdício. As equipes de desenvolvimento se esforçam muito para evitá-los, mas, mesmo assim, quase todos os praticantes consideram os loopbacks inevitáveis, e, na verdade, até planejam contando com eles. Mas, de uma perspectiva lean, isso é lamentável porque um loopback não é nada mais do que retrabalho com um nome diferente. Os desenvolvedores projetam, analisam e testam seu produto ou processo apenas para ter que repetir essas mesmas atividades mais tarde.

Assim como no chão de fábrica, os retrabalhos podem ser extremamente caros. É vastamente reconhecido que o custo de fazer mudanças aumenta conforme se avança na linha do tempo do projeto de desenvolvimento do produto. Como mostrado na figura acima, para a maioria dos produtos fabricados, o custo de fazer uma mudança durante a fase do projeto é mais barato do que durante a fase do protótipo, que é mais barato do que quando o produto está na produção. E a maioria das pessoas concordaria que a curva do custo é geométrica. Na verdade, alguns disseram que o custo para fazer uma mudança em qualquer estágio é dez vezes mais caro do que no estágio imediatamente anterior! Então podemos enxergar que mudanças tardias podem, de fato, ser caras.

O conselho comum para eliminar o problema dos loopbacks é antecipar algumas atividades no processo de desenvolvimento do produto. Mas o que significa antecipar?

Alguns sugeriram que é inteligente começar um projeto de desenvolvimento de produtos acumulando o que já sabemos. Por exemplo, engenheiros de produção podem fornecer à equipe informações sobre a capacidade de seus equipamentos de fabricação atuais no início do projeto. Então os projetistas do produto podem (assim esperamos) projetar dentro dessas restrições para minimizar os problemas no chão de fábrica enquanto melhoram a qualidade e a eficiência. O desafio com essa sugestão é, obviamente, acumular conhecimento. Mas é também a tradução desse conhecimento de termos de processo para termos que os projetistas de produtos possam entender. Empresas lean devotam um grande esforço para catalogar sua capacidade processual em uma base contínua para que o conhecimento esteja pronto para ser implantado com qualquer nova projeção de desenvolvimento de produtos.

Outros recomendaram antecipar os projetos de desenvolvimento juntando equipes interfuncionais desde o começo do projeto. As equipes consistem em representantes capazes de todas as funções necessárias para trazer um produto ao mercado: vendas/marketing, engenharia de produto, projeto industrial, engenharia de produção, compras e finanças, por exemplo. A ideia é garantir que todos os pontos de vista sejam considerados desde os primeiros estágios para evitar “descobertas” inesperadas mais tarde. Mas uma pergunta frequentemente importuna essas equipes: o que eles devem fazer nessas primeiras fases?

Stefan Thomke recomenda a experimentação rápida a fim de aprender sobre as possibilidades do produto e do processo de produção. Podemos estender a ideia de Thomke com as noções de Allen Ward sobre projeto baseado em alternativas, o que chamamos agora de inovação baseada em alternativas.

Em uma abordagem baseada em alternativas no desenvolvimento, as equipes se envolvem de uma forma muito diferente com os desafios de desenvolvimento que enfrentam em comparação com as abordagens convencionais. As principais práticas da inovação baseada em alternativas são:

  1. Gerar soluções de alternativas múltiplas para todo subproblema de projeto identificado.
  2. Entender essas soluções aos requerimentos do projeto gerando dados através de análises, modelos e protótipos de baixo custo. Prestar atenção à granularidade dos dados necessários – usar modelos de baixa fidelidade quando respostas rápidas e brutas são necessárias, por exemplo.
  3. Eliminar uma alternativa quando os dados mostrarem que, ou não possa atender às exigências. ou seja claramente inferior à outra alternativa. Evitar escolher um vencedor antecipadamente – utilizar um processo de eliminação.
  4. Conforme você segue, tente gerar conhecimento reutilizável na forma de limites do projeto e curvas de trade-off. Se você entender os limites físicos de um conceito do projeto, e esses limites estiverem fora das exigências, você pode eliminar essa alternativa com segurança.
  5. Permita alguma flexibilidade nas exigências do projeto para que você possa utilizar o conhecimento adquirido para definir as exigências finais em um ponto onde você entenda mais profundamente os trade-offs que estão acontecendo.

O que você está fazendo para evitar os loopbacks? Quais são as outras formas que você utilizou para eliminar o retrabalho no desenvolvimento? Você tem exemplos de qualquer uma das abordagens acima? Compartilhe seus pensamentos e ideias para que todos possamos aprender mais.

Publicado em 28/10/2014

Planet Lean - The Lean Global Networdk Journal