Você está na página 1de 577

VI

Gestão de
Desenvolvimento
de Produtos
Uma Referência para a
Melhoria do Processo

Henrique Rozenfeld
Fernando Antônio Forcellini
Daniel Capaldo Amaral
José Carlos de Toledo
Sergio Luis da Silva
Dário Henrique Alliprandini
Régis Kovacs Scalice
ISBn 978-85-02-05446-2
85-02-05446-5
Rua Henrique Schaumann, 270 – CEP: 05413-010
Pinheiros – TEL.: PABX (0XX11) 3613-3000
Fax: (11) 3611-3308 – Televendas: (0XX11) 3613-3344
Fax Vendas: (0XX11) 3268-3268 – São Paulo – SP CIP-BRASIL. CAtALogAção nA Fonte
Endereço Internet: http://www.saraivauni.com.br SIndICAto nACIonAL doS edItoReS de LIvRoS, RJ.

05-2250. CDD 658.575


Filiais CDU 658.512 Gestão de desenvolvimento de produtos / Daniel
Capaldo Amaral... [et al.]. - São Paulo : Saraiva, 2006
AMAZONAS/RONDÔNIA/RORAIMA/ACRE
Rua Costa Azevedo, 56 – Centro
Fone/Fax: (0XX92) 3633-4227 / 3633-4782 – Manaus ISBN 978-85-02-05446-2
85-02-05446-5
BAHIA/SERGIPE
Rua Agripino Dórea, 23 – Brotas
Fone: (0XX71) 3381-5854 / 3381-5895 / 3381-0959 – Salvador 1. Produtos novos - Administração. 2. Administração de produ-
tos. 3.Administração de projetos. I. Amaral, Daniel Capaldo.
BAURU/SÃO PAULO (sala dos professores)
05-2250 CDD-658.575
Rua Monsenhor Claro, 2-55/2-57 – Centro
CDU-658.512
Fone: (0XX14) 3234-5643 – 3234-7401 – Bauru

CAMPINAS/SÃO PAULO (sala dos professores)


Rua Camargo Pimentel, 660 – Jd. Guanabara
Fone: (0XX19) 3243-8004 / 3243-8259 – Campinas

CEARÁ/PIAUÍ/MARANHÃO Copyright©Henrique Rozenfeld, Fernando Antônio Forcellini,


Av. Filomeno Gomes, 670 – Jacarecanga Daniel Capaldo Amaral, José Carlos de Toledo, Sergio Luis da
Fone: (0XX85) 3238-2323 / 3238-1331 – Fortaleza
Silva, Dário Henrique Alliprandini, Régis Kovacs Scalice
2006 Editora Saraiva
DISTRITO FEDERAL Todos os direitos reservados.
SIA/SUL Trecho 2, Lote 850 – Setor de Indústria e Abastecimento
Fone: (0XX61) 3344-2920 / 3344-2951 / 3344-1709 – Brasília

GOIÁS/TOCANTINS
Av. Independência, 5330 – Setor Aeroporto
Fone: (0XX62) 3225-2882 / 3212-2806 / 3224-3016 – Goiânia
direção editorial Flávia Alves Bravin
MATO GROSSO DO SUL/MATO GROSSO
Coordenação editorial Ana Paula Matos
Rua 14 de Julho, 3148 – Centro
Gisele Folha Mós
Fone: (0XX67) 3382-3682 / 3382-0112 – Campo Grande
Juliana Rodrigues de Queiroz
MINAS GERAIS Rita de Cássia da Silva
Rua Além Paraíba, 449 – Lagoinha Produção editorial Daniela Nogueira Secondo
Fone: (0XX31) 3429-8300 – Belo Horizonte Rosana Peroni Fazolari
Marketing editorial Nathalia Setrini
PARÁ/AMAPÁ
Travessa Apinagés, 186 – Batista Campos Suporte editorial Renata Moraes
Fone: (0XX91) 3222-9034 / 3224-9038 / 3241-0499 – Belém Arte e produção ERJ Composição Editorial

PARANÁ/SANTA CATARINA Capa ERJ Composição Editorial


Rua Conselheiro Laurindo, 2895 – Prado Velho Produção gráfica Liliane Cristina Gomes
Fone: (0XX41) 3332-4894 – Curitiba Impressão Nononno
PERNAMBUCO/ ALAGOAS/ PARAÍBA/ R. G. DO NORTE Acabamento Nonono
Rua Corredor do Bispo, 185 – Boa Vista Atualização da 5a tiragem ERJ Composição Editorial
Fone: (0XX81) 3421-4246 / 3421-4510 – Recife

RIBEIRÃO PRETO/SÃO PAULO


Av. Francisco Junqueira, 1255 – Centro
Fone: (0XX16) 3610-5843 / 3610-8284 – Ribeirão Preto

RIO DE JANEIRO/ESPÍRITO SANTO


Rua Visconde de Santa Isabel, 113 a 119 – Vila Isabel
Fone: (0XX21) 2577-9494 / 2577-8867 / 2577-9565 – Rio de Janeiro Contato com o editorial
editorialuniversitario@editorasaraiva.com.br
RIO GRANDE DO SUL
Av. A. J. Renner, 231 – Farrapos
Fone: (0XX51) 3371- 4001 / 3371-1467 / 3371-1567 – Porto Alegre

SÃO JOSÉ DO RIO PRETO/SÃO PAULO (sala dos professores)


Av. Brig. Faria Lima, 6363 – Rio Preto Shopping Center – V. São José
1ª Edição
Fone: (0XX17) 3227-3819 / 3227-0982 / 3227-5249 – São José do Rio Preto
1ª tiragem: 2006
SÃO JOSÉ DOS CAMPOS/SÃO PAULO (sala dos professores) 2ª tiragem: 2006
Rua Santa Luzia, 106 – Jd. Santa Madalena 3ª tiragem: 2008
Fone: (0XX12) 3921-0732 – São José dos Campos 4ª tiragem: 2009
5ª tiragem: 2010
SÃO PAULO
Av. Antártica, 92 – Barra Funda
Fone: PABX (0XX11) 3613-3666 – São Paulo
Nenhuma parte desta publicação poderá ser
reproduzida por qualquer meio ou forma
sem a prévia autorização da Editora Saraiva.
A violação dos direitos autorais é crime
353.617.001.005
estabelecido na lei nº 9.610/98 e punido
pelo artigo 184 do Código Penal.
GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Na Introdução, narramos como este livro foi produzido, demonstrando quanto este trabalho é fruto da
união de esforços e experiências de vários pesquisadores, profissionais de empresa e estudantes, que dedicaram
parte preciosa de suas vidas para compartilhar conosco suas experiências e conhecimentos em desenvolvimento
de produtos. Se contássemos todas as pessoas que, durante quase uma década, nos ajudaram a entender um
pouco mais de desenvolvimento de produtos, certamente chegaríamos a centenas. Sem elas, não teríamos expe-
riência suficiente para realizar esta empreitada, de certa maneira pretensiosa, de condensar as melhores práticas
em desenvolvimento de produtos e colocá-las de forma organizada em um único livro.
Gostaríamos de registrar os nossos sinceros agradecimentos a todos, sabendo que seria impossível nomeá-los
neste espaço, tanto pela quantidade como pela certeza de que erros graves de esquecimento seriam cometidos.
Ficam os nossos agradecimentos aos profissionais que abriram a porta de suas organizações, tiveram a pa-
ciência e a compreensão de compartilhar os problemas, experiências e os modelos de suas empresas, e, final-
mente, criticaram as primeiras versões do modelo de referência: Marco Diniz, da Eaton; Eduardo Vaz, da
Xerox; Wilson Moura e João Nascimento, da Multibras; e Renato Mastrobuono, da VW Caminhões e Ônibus.
A contribuição e o incentivo do professor Majdi Najm, do E-business center, da Universidade de Missouri,
também foram decisivos para a conclusão deste livro.
Outra contribuição decisiva foi obtida dos pesquisadores e profissionais que participaram conosco do pro-
jeto Programa de Cooperação Acadêmica (PROCAD) — financiado pela Coordenação de Aperfeiçoamento de
Pessoal de Nível Superior (Capes) — e da PDPNet, nossa Comunidade de Prática na Internet sobre o tema
deste livro. Esse projeto e a criação da comunidade foram fundamentais tanto para aproximar os autores como
para o compartilhamento de valiosas informações e experiências. Agradecemos aos professores que partici-
param da fase inicial do projeto PROCAD: Nelson Back, Acires Dias, André Ogliari e Roberto Martins. Gosta-
ríamos de destacar os nomes dos pesquisadores e profissionais que participaram com intensidade na criação de
nossa comunidade virtual e nos debates e compartilhamento de conhecimentos: Elaine Mosconi, Sanderson
Barbalho, Cristiano Vasconcellos Ferreira, Antonio Francisco Savi, Vinicius Kaster Marini, Edenilza Valéria da
Silva, Sandro Giovanni Valeri, Leonardo Nabaes Romano, Andréa Cristina dos Santos, Antonio Carlos Peixoto
Bitencourt, Diego Jorge Balthazar Neves, Luis Fernando Soares Zuin, Franco Antonio Menegatti, Karina Kühl
de Lima e Leonardo Santiago.
Gostaríamos, também, de agradecer a todos os nossos alunos de disciplinas de pós-graduação, graduação e,
principalmente, nossos orientados que nos ajudaram a construir este conhecimento com suas dúvidas, suges-
tões, dissertações de mestrado e de doutorado, cujos resultados principais foram incorporados neste livro: Cris-
tiano Bevitori M. Oliveira, Lucas Cley da Horta, Marcelo Gitirana Gomes Ferreira, Vander Guerrero,
Fernanda Menezes Ferrari, Rogerio Omokawa, Glauco Henrique Souza Mendes, José Luiz Moreira de Car-
valho, Marcelo Ruy e Mariana Maciel da Silva.
Neste contexto, não poderíamos deixar de agradecer às instituições que fomentaram essas pesquisas: Fun-
dação de Amparo à Pesquisa do Estado de São Paulo (Fapesp), Conselho Nacional de Desenvolvimento Cientí-
fico e Tecnológico (CNPq), Ministério de Ciências e Tecnologia (MCT) e Capes.
Não podemos nos esquecer, ainda, de todo o pessoal de apoio, que sempre esteve presente no gerencia-
mento de nossa infra-estrutura para a realização desta obra: Fernando Walker Lima da Silva, Cristiane de Cássia
Cornetta Bernardes e Francis Ribeiro da Silva.
vi GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

O apoio do Instituto Fábrica do Milênio (IFM) também foi essencial para manter a nossa rede de coope-
ração e realização de projetos conjuntos, assim como de fornecer infra-estrutura para a realização de reuniões
virtuais e de apoio financeiro para os diversos encontros.
Finalmente, temos que agradecer aos nossos familiares, que foram privados de muitos momentos de nossa
companhia, pois dedicamos grande parte de nosso tempo livre à confecção deste livro.

Os autores
GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Henrique Rozenfeld
Formou-se engenheiro mecânico, em 1980, e mestre, em 1983, pela USP. Doutorado em Sistematização da
Produção no WZL da Universidade Técnica de Aachen, Alemanha, em 1988. Livre-docente, em 1992, na área
de Planejamento do Processo e professor titular na área de Integração da Manufatura, em 1995. É docente do
Departamento de Engenharia da Escola de Engenharia de São Carlos (EESC-USP), desde 1982, coordenador
do Núcleo de Manufatura Avançada (NUMA) e do Grupo de Engenharia Integrada do NUMA. Além de vice-co-
ordenador do Instituto Fábrica do Milênio. Possui mais de 300 artigos publicados nacionais e internacionais. De-
senvolveu sistemas de planejamento de processo, realizou várias consultorias na área de desenvolvimento de
produtos e de sistemas integrados de gestão. Já formou mais de 40 mestres e doutores. Foi professor convidado no
ano de 2003 na Universidade de Missouri na área de Gestão do Ciclo de Vida de Produtos. Coordena projetos nacio-
nais e cooperados com instituições européias na área de Engenharia Colaborativa, e outros de modelagem de
processos de negócio.

Fernando Antônio Forcellini


Formou-se engenheiro mecânico, em 1985, mestre, em 1989 e doutor, em 1994 pela Universidade Federal
de Santa Catarina. Docente do Departamento de Engenharia Mecânica da UFSC desde 1994. Já formou mais de
30 mestres e doutores, possui mais de 150 artigos publicados em eventos nacionais e internacionais e periódicos.
Participou e coordenou projetos cooperativos com diversas instituições nacionais e internacionais. Coordenador
do NeDIP – Núcleo de Desenvolvimento Integrado de Produtos – até 2004. Atualmente, atua como pesquisador
do Gepp – Grupo de Engenharia do Produto e Processo – e como professor dos Programas de Pós-Graduação em
Engenharia Mecânica e de Engenharia de Produção da Universidade Federal de Santa Catarina.

Daniel Capaldo Amaral


Doutor em Engenharia Mecânica pela Escola de Engenharia de São Carlos (EESC-USP) e mestre e engenheiro
de produção formado pela Universidade Federal de São Carlos (UFSCar). Atualmente, é professor do Departa-
mento de Engenharia de Produção da EESC-USP, sendo responsável pelas disciplinas de Projeto do Produto e
Gerenciamento de Projetos. Realiza pesquisas na área de desenvolvimento e aplicação de sistemas para gestão
do processo de desenvolvimento de produto. Desenvolveu protótipos de sistemas computacionais para enge-
nharia colaborativa, estudos de implantações de sistemas para gestão do PDP e propostas para o ensino de de-
senvolvimento de produto.
viii GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

José Carlos de Toledo


Engenheiro de produção, mestre em Engenharia de Produção formado pela Coppe/UFRJ, doutor em Enge-
nharia de Produção pela Escola Politécnica da Universidade de São Paulo. É coordenador e pesquisador do
Gepeq – Grupo de Estudos e Pesquisa em Qualidade – e professor do Programa de Pós-Graduação em Enge-
nharia de Produção da Universidade Federal de São Carlos. Cursou especialização em TQM – Total Quality
Management – na AOTS – Association of Overseas Technical Scholarhip –, no Japão. Desenvolve atividades de
ensino, pesquisa e de consultoria nas áreas de sistemas e ferramentas para gestão do desenvolvimento de pro-
duto, sistemas e ferramentas para gestão e melhoria da qualidade, métodos para coordenação da qualidade em
cadeias de produção e sistemas da qualidade em unidades de produção agropecuária.

Sergio Luis da Silva


Formou-se engenheiro de materiais e mestre em Engenharia de Produção pela UFSCar (Universidade Federal
de São Carlos). Doutor em Engenharia Mecânica pela Escola de Engenharia de São Carlos – EESC/USP. Na
UFSCar, atua desde 1995 como professor efetivo na área de Informação Tecnológica e Empresarial do Depar-
tamento de Ciências da Informação, e, a partir de 2004, como docente credenciado no Programa de Pós-Gradu-
ação em Engenharia de Produção. Colaborou na implantação do NIT/Materiais (Núcleo de Informação
Tecnológica) do Departamento de Engenharia de Materiais dessa Universidade. Atua como pesquisador e con-
sultor em temas relacionados ao Desenvolvimento de Produtos e à Gestão do Conhecimento, no Gepeq –
Grupo de Estudos e Pesquisa em Qualidade –, do Departamento de Engenharia de Produção da UFSCar, e em
colaboração com o Grupo de Engenharia Integrada – EI – no NUMA – Núcleo de Manufatura Avançada na
EESC/USP. Nesses mesmos temas, publicou mais de 50 artigos em congressos nacionais, internacionais e pe-
riódicos científicos.

Dário Henrique Alliprandini


Professor do Departamento de Engenharia de Produção da Universidade Federal de São Carlos (UFSCar)
desde 1992. Formou-se engenheiro mecânico, em 1982, mestre, em 1990, e doutor, em 1996, pela Escola de
Engenharia de São Carlos da USP. Atuou como engenheiro de fabricação, engenheiro de produto e supervisor
de produção em empresas manufatureiras entre 1983 e 1991. Realizou estágio de pesquisa no Georgia Institute
of Technology – School of Industrial Engineering (2000/2001). Atua em ensino e pesquisa sobre melhoria con-
tínua, aprendizagem organizacional e sistemas de gestão em ambientes de manufatura e processo de desenvolvi-
mento de produto.

Régis Kovacs Scalice


Engenheiro mecânico formado em 1997 pela Universidade Estadual Paulista (FEG-Unesp) e doutor em Enge-
nharia Mecânica, em 2003, pela Universidade Federal de Santa Catarina (UFSC), tendo trabalhado com Meto-
dologia de Projeto e com o Desenvolvimento de Produtos Modulares. Coordena o Curso de Graduação em
Engenharia Mecânica da Sociedade Educacional de Santa Catarina (Sociesc), desde 2005, e atua no grupo de
pesquisa da instituição. Realizou consultorias na área de Desenvolvimento de Produtos e participou de projetos
nacionais cooperados na área de Desenvolvimento de Produtos e com instituições européias na área de Enge-
nharia Colaborativa.
Prefácio
GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

O maior legado da onda de Reengenharia de Processos, iniciada pelo trabalho de Michael Hammer e James
Champy no início dos anos 1990, talvez seja a disseminação do conceito de Processos de Negócio e da necessi-
dade de seu adequado gerenciamento. Atualmente, a maioria das empresas líderes em seus mercados conhece,
gerencia e aprimora continuamente seus processos-chave de negócio. Apesar de isoladamente isso não garantir
o sucesso, esses fatores são fundamentais para a competitividade.
O Processo de Desenvolvimento de Produtos se constitui num dos processos-chave de qualquer empresa
que se proponha a competir por meio da criação de produtos próprios e da busca de liderança tecnológica. A an-
tiga fórmula de sucesso — baseada em fazer um produto, produzi-lo a preços baixos e vendê-lo em grande quan-
tidade — não se aplica mais ao ambiente atual dos negócios. É preciso identificar a premissa de criação de valor
que garantirá, no mercado, o êxito com os clientes e realizá-la em tempo adequado para aproveitar ao máximo a
oportunidade que se apresenta. O sucesso será conquistado pelas empresas que sabem produzir valor de mer-
cado — aquelas que podem entregar o que as pessoas querem comprar. Assim sendo, o Processo de Desenvolvi-
mento de Produtos deve ser abrangente, iniciando-se no entendimento das necessidades de mercado e
terminando no final do ciclo de vida do produto.
O modelo geral, proposto neste livro, atende a essa necessidade, constituindo-se numa excelente referência
para aqueles que desejam aprimorar seu processo atual, necessitam implementar tal processo em sua empresa ou
apenas precisam se iniciar no assunto. Os autores, professores em renomadas universidades brasileiras, com-
binam uma grande experiência em ensino, pesquisa e consultoria em áreas como: sistemas e ferramentas para
gestão do desenvolvimento de produto e melhoria da qualidade, engenharia colaborativa, modelagem de pro-
cessos de negócio, gestão do conhecimento e sistemas integrados de gestão. Desde o início da década de 1990,
eles têm realizado pesquisa e análise profundas dos conceitos mais avançados na implementação e gerenciamen-
to do Processo de Desenvolvimento de Produtos.
Ao mesmo tempo, por meio da interação com instituições de ensino e pesquisa no exterior e trabalhos de
consultoria em empresas de porte no Brasil, esses conceitos foram aplicados em casos reais, e com isso puderam
ser refinados e tornaram-se melhores práticas, documentadas nesse livro.
O resultado dessa dedicação e disposição em combinar a pesquisa acadêmica com experiência prática pode
ser visto no livro. O modelo de referência foi desenvolvido com uma visão holística, incluindo fases anteriores e
posteriores à parte mais visível do desenvolvimento de produto e processo, que são as atividades de engenharia
própriamente ditas, além de abordar os processos de apoio relevantes. A importância dessa ligação entre o Pro-
cesso de Desenvolvimento de Produtos com os processos de Pré-Desenvolvimento, Pós-Desenvolvimento e
Processos de Apoio não é óbvia, o que leva muitas empresas a tratá-los separadamente, resultando desse proce-
dimento projetos mal-sucedidos de desenvolvimento de produto.
As melhores práticas no gerenciamento do Processo de Desenvolvimento de Produtos, encontradas na lite-
ratura e nas empresas de ponta, também estão presentes no modelo. A avaliação dos resultados ao término de
cada fase inclui não somente a análise dos resultados esperados (deliverables), como ainda o registro de lições
aprendidas, gestão do conhecimento gerado e análise dos indicadores de desempenho selecionados. O ciclo de
aperfeiçoamento do Processo de Desenvolvimento de Produtos também está incluído no modelo, seguindo cri-
térios reconhecidos de excelência em negócios.
Diferentes ferramentas de gerenciamento de portfólio de projetos são levantadas, e a sua relação com o Pla-
nejamento Estratégico da empresa é abordada, sendo discutidas inclusive alternativas de estrutura organizacional
para o desenvolvimento de produtos e ferramentas de Tecnologia de Informação, como sistemas ERP.
x GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Outra contribuição digna de nota é a apresentação e a análise de métodos e ferramentas aplicáveis a cada
uma das fases do projeto, que estão nos quadros de cada capítulo. Essa é uma das áreas que as empresas mais tem
dificuldade em desenvolver, pois requer disponibilidade de pessoal para buscar as ferramentas, estudá-las e de-
finir a aplicabilidade em cada caso. Para orientar a aplicação dos conceitos em uma empresa, diferentes níveis de
maturidade do Processo de Desenvolvimento de Produtos são definidos e analisados.
O ritmo alucinante de trabalho nos dias atuais faz com que as empresas tenham dificuldades em man-
terem-se atualizadas; nesse contexto, as contribuições aqui apresentadas constituem patrimônio valioso. Du-
rante o tempo em que trabalhei com alguns dos autores, desenvolvendo e implementando o primeiro processo
estruturado para o desenvolvimento de produtos de minha empresa na metade da década de 1990, encontramos
muita dificuldade em identificar o processo em si, compreender, selecionar e aplicar os inúmeros métodos exis-
tentes sem a ajuda de um guia como este livro. Fica claro para mim a utilidade que este livro pode ter, pois onde
mais poderíamos encontrar, numa única referência, a maioria dos elementos importantes na área, acompa-
nhados de análises detalhadas e com abordagem completa e rigorosa dos diversos temas? Ou a discussão dos di-
ferentes conceitos de modelagem de processos no Capítulo 2 ou, ainda, a análise detalhada de outras abordagens
para a gestão do Processo de Desenvolvimento de Produtos encontrados no Capítulo 16?
Isto deve servir de motivação para que os profissionais com interesse no assunto leiam e utilizem os concei-
tos aqui apresentados. Posso afirmar que o conteúdo do livro lhes será muito útil e sua aplicação ajudará no
avanço das atividades de desenvolvimento de produtos, com conseqüente aumento de produtividade, diminuição
do tempo de desenvolvimento e melhoria na qualidade dos resultados.

Marco Antonio N. Diniz


Diretor de Engenharia
Divisão de Transmissões Leves e Médias
Truck Components Group – Eaton Corporation
Kalamazoo, Michigan, USA
Apresentação xi

Apresentação
GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

A.1 Objetivos do livro


O objetivo deste livro é apresentar de forma didática e completa um modelo estruturado, como se fosse um
guia de orientação, para a estruturação e gestão do processo de desenvolvimento de produtos. O modelo possui
algumas particularidades relacionadas com o desenvolvimento de bens duráveis e de equipamentos. Porém, o
modelo geral, com algumas adaptações, pode ser adequado ao desenvolvimento de qualquer tipo de produto.
Enfatiza-se a visão do desenvolvimento como um processo de negócio amplo, que abrange todo o ciclo de
vida do produto. Esse processo compreende a integração com o planejamento estratégico da empresa, quando a
carteira de produtos e projetos de desenvolvimento é definida; as fases de engenharia, lançamento e acompanha-
mento do produto durante a sua comercialização e operação; até a sua retirada do mercado e as atividades de re-
ciclagem, reutilização ou descarte.
A apresentação do modelo é desdobrada em macrofases, fases e atividades necessárias para o desenvolvi-
mento de um produto. Para a compreensão do modelo, discutem-se os condicionantes do processo de desenvol-
vimento de produtos, em termos do ambiente competitivo e das estratégias e capacitações da empresa. São
apresentados, também, os conceitos, ferramentas e fluxos de informações que podem ser aplicados nas diversas
atividades para compreensão e tradução dos requisitos dos clientes e para o projeto e melhoria das especificações
do produto e de seu processo de produção. Assim, as atividades são detalhadas em termos das informações de en-
trada necessárias, do conteúdo das tarefas a serem executadas, das informações de saída, das ferramentas de su-
porte e dos mecanismos de controle.

A.2 Público-alvo
O livro se destina a um público constituído por alunos, professores e profissionais de empresas que estejam
em busca da compreensão de uma visão ampla e, ao mesmo tempo, detalhada das atividades do processo de de-
senvolvimento de produtos e de sua gestão estratégica e operacional.
Os alunos de graduação em Engenharia encontrarão no livro um texto didático e estruturado que os guiará na
compreensão das atividades e ferramentas que são pertinentes a esse processo. Os graduandos de Administração en-
contrarão uma visão geral do processo e dos principais elementos e condicionantes para gerenciamento dele.
Os alunos de pós-graduação encontrarão, além da visão geral do processo, uma abordagem devidamente
fundamentada e com indicações bibliográficas para a busca de uma compreensão mais detalhada de elementos,
conceitos e ferramentas pertinentes ao processo.
Os professores, de graduação e de pós-graduação, de diversas áreas de conhecimento, terão a sua disposição
um livro que poderá ser utilizado como texto básico a ser seguido ao longo de toda uma disciplina sobre Desen-
volvimento de Produtos, ou como relevante leitura complementar para disciplinas que abordam temas especí-
ficos aplicados no contexto ou no escopo do desenvolvimento de produtos, tais como Marketing, Design,
Manufatura e Projeto de Processos.
Os profissionais de empresas encontrarão no livro conhecimentos que lhes permitirão:

n obter uma visão ampla do Processo de Desenvolvimento de Produtos (PDP);


n compreender, em função do tipo de produto, de mercado e de tecnologia da empresa em que atua, qual
o escopo mais adequado para o desenvolvimento de produtos;
xii GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

n obter elementos que os auxiliarão na identificação e análise de como se encontram a estrutura e o geren-
ciamento do PDP da empresa; e
n conhecer um modelo de referência como base de apoio para planejar ou melhorar a estrutura do PDP da
empresa; além de elementos para planejar a transição da situação atual para uma situação desejada com
base no modelo aqui apresentado.

A leitura do livro pode ser útil a profissionais que atuam no desenvolvimento de produtos, bem como nos
processos a ele relacionados, sejam em empresas de manufatura ou como consultores na área ou como desenvol-
vedores de sistemas de informação ou de integração do todo ou de partes deste processo.

A.3 Histórico do livro


O modelo que será apresentado contém os conceitos e as melhores práticas em Desenvolvimento de Pro-
dutos (DP), uma vez que incorpora experiências e conhecimentos em desenvolvimento de produtos acumulados
pelos autores deste livro desde o início da década de 1990 — sejam em atividades acadêmicas e de ensino como,
também, em atividades práticas em empresas. O modelo sistematiza conhecimentos adquiridos por meio da atu-
ação em atividades de consultoria, orientações de dissertações e teses, coordenação de projetos de desenvolvi-
mento de produtos, realização de pesquisas de campo (entre elas, estudos de casos profundos em empresas),
execução de diagnósticos, realização de pesquisas-ação, estudo e comparação de modelos de referência de várias
empresas, e análises mais amplas e abrangentes do PDP em empresas dos setores tratados no livro.
Este modelo é também resultado de uma ação conjunta de grupos de pesquisa de três universidades brasileiras,
com forte atuação na área de Desenvolvimento de Produtos. Essa ação, financiada pela Coordenação de Aperfe-
içoamento de Pessoal de Nível Superior (Capes), foi iniciada em 2001 como parte do Programa Nacional de
Cooperação Acadêmica (PROCAD), que objetivou promover a integração e o intercâmbio de conhecimentos
entre grupos de pesquisa nacionais, no âmbito da pós-graduação. No projeto de pesquisa em questão, coorde-
nado pelo professor Henrique Rozenfeld, participaram os seguintes centros de pesquisa:

n Grupo de Engenharia Integrada do Núcleo de Manufatura Integrada (NUMA) do departamento de


Engenharia da Escola de Engenharia de São Carlos, Universidade de São Paulo;
n Grupo de Estudos e Pesquisa em Qualidade (Gepeq), do Departamento de Engenharia de Produção da
Universidade Federal de São Carlos (UFSCar).
n Inicialmente, pelo Departamento de Engenharia Mecânica da Universidade Federal de Santa Catarina,
o Núcleo de Desenvolvimento Integrado de Produtos (NeDIP) e, posteriormente, o Grupo de Enge-
nharia do Produto e Processo (Gepp).

Nesse projeto foram feitas várias ações de integração entre esses grupos, incluindo encontros entre os pes-
quisadores para troca de experiências e a criação de uma comunidade de prática em Desenvolvimento de Pro-
dutos, denominada PDPNet (http://www.pdp.org.br). Essa comunidade contou ainda com a participação de
profissionais de empresas brasileiras com vasta experiência na Gestão do Desenvolvimento de Produtos.
Um dos principais resultados dessa verdadeira coalizão que se formou em torno do assunto foi a elaboração
de um modelo de referência com o objetivo de ser utilizado nas atividades didáticas e acadêmicas dos envolvidos
na comunidade. A missão desse grande modelo de referência, de caráter mais geral, foi se tornar “referência”
para a derivação de outros modelos, adequados a um setor ou tipo específico de produto.
Paralelo a esse exaustivo trabalho de desenvolvimento do modelo de referência principal, os grupos de pes-
quisa desenvolveram modelos de referência para aplicações específicas. Foram criados e testados modelos para a
indústria de máquinas agrícolas e alimentos, e outros estão em andamento — como é o caso de um modelo vol-
tado para empresas de produtos mecatrônicos. Parte desses projetos desenvolvidos com o uso do modelo foi rea-
lizada com o apoio da rede de pesquisa do Instituto Fábrica do Milênio, um dos Institutos do Milênio criados
pelo Ministério da Ciência e Tecnologia (http://www.ifm.org.br).
Apresentação xiii

O modelo apresentado neste livro é uma evolução do modelo genérico desenvolvido pela comunidade
PDPNet, o qual foi aprimorado e adaptado pelos autores com o objetivo de ser disseminado para o grande pú-
blico: pesquisadores, profissionais e estudantes interessados nessa instigante e desafiadora atividade de criar so-
luções para melhorar a vida das pessoas e a competitividade da indústria nacional. A escrita do livro foi iniciada
após a conclusão da primeira versão validada do modelo, no primeiro semestre de 2004.
Portanto, caro leitor, o livro é resultado da união entre a experiência dos autores e a experiência de dezenas
de pesquisadores e especialistas da área de Desenvolvimento de Produto, acumulada em encontros e discussões
realizadas durante quase três anos de trabalho. Todo esse esforço, então, é para disseminar as técnicas de Desen-
volvimento de Produto nas empresas nacionais e auxiliá-las a melhorar a eficiência nessa atividade.

A.4 Estrutura do livro


O livro está estruturado em três partes e 16 capítulos. A Figura A.1 ilustra a estrutura das partes do livro.

Figura A.1 Estrutura do livro.

Parte 1:
A primeira parte é dividida em dois capítulos. O Capítulo 1 apresenta os conceitos sobre Gestão do Pro-
cesso de Desenvolvimento de Produtos, discutindo a importância do PDP e suas características; a realidade do
Brasil nessa área; as principais abordagens e arranjos organizacionais para o PDP; e quais os fatores que afetam o
desempenho desse processo. O Capítulo 2 mostra uma visão geral do modelo, apresentando as suas macrofases e
os principais conceitos que o modelo contém. Assim, obtém-se a base conceitual para o seu entendimento.
n Capítulo 1: Gestão do Processo de Desenvolvimento de Produtos

n Capítulo 2: O Modelo Unificado do PDP.

Parte 2:
Na segunda parte, o Modelo de Referência para o PDP é apresentado em 11 capítulos. O Capítulo 3 des-
creve as atividades gerais que se repetem em cada uma das fases. Cada uma das nove fases do modelo é descrita
em detalhes nos capítulos subseqüentes, quando suas atividades e tarefas são mostradas, assim como os concei-
tos, métodos e ferramentas principais que podem ser utilizadas para o seu desenvolvimento.
n Capítulo 3: Atividades Genéricas do Modelo

n Capítulo 4: Planejamento Estratégico de Produtos

n Capítulo 5: Planejamento do Projeto

n Capítulo 6: Projeto Informacional

n Capítulo 7: Projeto Conceitual


xiv GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Capítulo 8: Projeto Detalhado


n

n Capítulo 9: Preparação da Produção do Produto

n Capítulo 10: Lançamento do Produto

n Capítulo 11: Acompanhar Produto e Processo

n Capítulo 12: Descontinuar o Produto

n Capítulo 13: Processos de Apoio

Este último capítulo dessa parte, descreve os processos de apoio ao PDP: o processo de gerenciamento de
mudanças de engenharia e o processo de melhoria incremental do PDP.

Parte 3:
A terceira parte discute a Aplicação do Modelo, mostrando quais os níveis de maturidade que o PDP de
uma empresa pode possuir (Capítulo 14) e como utilizar o modelo proposto para aumentar a eficácia do PDP
(Capítulo 15). No Capítulo 16, discute-se como adaptar esse modelo para outros tipos de empresa, diferentes
das empresas de bens de consumo duráveis e de equipamentos, e finalmente qual a relação entre o modelo apre-
sentado e as abordagens de gestão do PDP, mostradas no Capítulo 1.
n Capítulo 14: Níveis de Maturidade do PDP

n Capítulo 15: Método de Transformação do PDP

n Capítulo 16: O Modelo, Suas Alternativas de Aplicação e Sua Relação com Outras Abordagens para
Gestão do PDP
Ao longo dos capítulos, há quadros, que detalham conceitos e ferramentas citados no texto. No final de
cada um deles, são apresentadas questões para reflexão, atividades para reforço dos conhecimentos apresentados
e são listadas referências bibliográficas complementares. No final do livro, há um glossário com a definição dos
principais conceitos e termos usuais na área, além daqueles citados no modelo. Outros apêndices existentes
servem para facilitar a aplicação prática do modelo de referência.

A.5 Como ler e empregar este livro


De modo geral, recomenda-se que o livro seja lido de forma completa e na seqüência em que os capítulos
são apresentados.
Entretanto, dependendo do curso e da disciplina que você esteja fazendo, ou do seu interesse individual e
em função da sua área de atuação e experiência profissional que já possui, você poderá ler apenas alguns capítulos
mais apropriados, conforme será sugerido a seguir.
Se o interesse é ter apenas uma visão geral do que é PDP e do modelo de referência, você poderá ler apenas
os capítulos 1 e 2, que trazem uma visão geral e um resumo do modelo completo.
Na Figura A.2 são apresentadas as formas alternativas de ler e empregar este livro, de acordo com cada tipo
de leitor.
Este livro é voltado ao aluno interessado em GDP que esteja cursando disci-
Aluno interessado plinas com esse conteúdo ou realizando projetos durante o seu curso e que precisa
em Gestão do ter uma boa noção de como desenvolver um produto, ou, então, ao aluno que pre-
Desenvolvimento de
Produtos (GDP)
tende trabalhar, futuramente, nessa área. O aluno pode ser de várias áreas: Adminis-
tração de Empresas, Engenharia e Economia.
Sendo um livro com finalidade didática, o ideal é que você o estude de forma completa e na seqüência apre-
sentada, uma vez que há um encadeamento de conceitos e de idéias, além, obviamente, de notações e terminolo-
gias adotadas, para uma melhor compreensão do modelo apresentado. Ou seja, existe uma relação de
dependência entre os capítulos do livro.
Apresentação xv

Figura A.2 Alternativas de leitura do livro conforme o tipo de leitor.

Leia sempre e atentamente os capítulos 1 e 2, antes dos demais, pois eles apresentam o referencial teórico
básico do livro, bem como uma visão geral do modelo para PDP, que será detalhado nos capítulos seguintes.
Em uma primeira leitura, você não precisa se preocupar em ler os quadros, uma vez que o texto descreve a
seqüência do processo de desenvolvimento de produtos. Os quadros trazem explicações adicionais sobre os
principais conceitos, ou uma introdução sobre determinados temas, ferramentas e métodos. Nesses casos, você
precisará consultar as informações adicionais citadas ao final de cada quadro para poder se aprofundar nos as-
suntos tratados. Repare que os assuntos de alguns quadros são bem abrangentes e fazem parte de outras disci-
plinas do seu curso.
Este livro é um guia que indicará leituras adicionais necessárias para você dominar a Gestão do Desenvolvi-
mento de Produtos (GDP). Entretanto, aqui, você não vai encontrar especificidades relacionadas com as áreas
tecnológicas. Este livro trata de gestão e não de conhecimentos tecnológicos especiais. Ele complementa o
aprendizado dessas áreas tecnológicas, pois, normalmente, essa visão geral e ampla não é fornecida nos cursos
regulares de Engenharia.
As questões para reflexão e as atividades sugeridas no final de cada capítulo devem ser priorizadas após a sua
leitura, já que reforçam a compreensão dos conceitos, a aprendizagem e a transposição para a sua realidade de in-
teresse. Se não conseguir respondê-las, retorne à leitura do capítulo, reflita mais um pouco e dedique-se às ativi-
dades sugeridas. Se necessário, busque leituras complementares sugeridas.
Um aluno de outra disciplina deve, primeiro, ler o Capítulo 2 para obter uma
visão geral do escopo e dos conceitos principais do PDP. Assim, ele consegue loca- Aluno cursando outras
lizar a sua disciplina no contexto geral do desenvolvimento de produtos. disciplinas

Em seguida, você precisa analisar quais fases e/ou atividades estão relacionadas
com a sua disciplina em particular. Dedique-se a estudar em profundidade os capítulos correspondentes a essas
fases e atividades. Identifique os quadros relacionados e estude-os também, em um segundo momento. Estude
as bibliografias adicionais relativas aos quadros identificados.
xvi GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Planeje realizar uma disciplina de GDP para aumentar a sua visão sobre o PDP, adquirindo, assim, um es-
copo maior de oportunidades futuras na sua vida profissional. Para isso, você vai ter de seguir os passos pro-
postos para os estudantes interessados em GDP.
Se você coordenar um curso não diretamente relacionado com a área de Enge-
Professor coordenador nharia, você deve ler as Partes 1 e 3 do livro para identificar o escopo do PDP e ava-
de curso liar o conteúdo que você precisaria ter no curso que coordena.
Se você for um coordenador de curso de Engenharia, deve, ainda, levantar os
temas dos quadros, lendo-os com cuidado. Verifique com os outros professores da sua equipe quem estudaria
qual capítulo e quadro para mapear as competências necessárias para definição ou atualização das disciplinas do
curso. Em grupo, vocês poderiam consultar as informações adicionais para buscar um conhecimento mais deta-
lhado sobre esses temas. E, ainda, identificariam os conteúdos necessários ao ensino de GDP, ou mesmo à in-
serção dos conceitos de PDP nas disciplinas atuais, ou em novas disciplinas a serem oferecidas.
Você, professor de GDP, deve adotar este livro como livro-texto de sua disci-
Professor de GDP plina. Baixe do site da editora as apresentações das aulas e o modelo de referência no
formato de guia. Você pode completar o conteúdo das apresentações sobre os as-
suntos dos quadros que considerar mais relevantes. Tente mapear, com base nos quadros, as outras disciplinas
existentes na sua universidade relacionadas com PDP. Assim, é possível identificar algumas lacunas e levar essas
informações à coordenação do seu curso.
Você pode passar aos alunos o modelo de referência (como um guia) para eles o utilizarem como base para
os passos dos projetos que poderão realizar durante o curso.
Um professor de outras disciplinas deve ler o Capítulo 2 para obter uma visão
Professor de outras integrada do PDP. Identifique, no restante do livro, qual fase e/ou atividade está re-
disciplinas lacionada com a sua disciplina. Leia, então, os capítulos e quadros correspondentes.
Localize a sua disciplina no contexto do modelo para motivar os alunos.
Um executivo de alto nível da empresa, cuja área de responsabilidade relacio-
Executivo de alto nível da na-se com o desenvolvimento de produtos, deve ler o Capítulo 2 para obter uma
empresa relacionado com visão ampla do processo e do seu potencial. Em seguida, leia a Parte 3 do livro para
o PDP
conhecer os níveis de maturidade do PDP, as etapas necessárias para adaptação do
modelo à realidade de sua empresa, assim como o método de transformação do
PDP de sua empresa, com base no modelo proposto.
Caso fique interessado em adotar as melhores práticas apresentadas no livro, você pode indicar a leitura
para o seu gerente do PDP ou para os seus gerentes de projetos de desenvolvimento.
Um gerente ou mesmo consultor pode estar participando de um projeto de
Gerente de implantação implantação ou mudança do PDP. Este projeto pode envolver um grande número
do PDP (ou consultor de de temas — da introdução de um novo arranjo organizacional até a implantação de
implantação)
um sistema de gestão de projetos. Não importa o projeto. Nesses casos, a premissa
básica é que todos os participantes e a empresa possuam um “mapa” único de como
desenvolver produtos. Isso pode ser obtido a partir do modelo proposto neste livro.
Você deve ler o Capítulo 2 e a Parte 3 do livro. Em seguida, baixe do site da editora o modelo de referência
em formato de guia. Você deve possuir conhecimentos sobre todos os temas relevantes em desenvolvimento de
produtos. Identifique e analise o foco necessário ao seu projeto de mudança, utilizando o guia como uma check-
list. Se surgir alguma dúvida, leia o capítulo correspondente ao item do guia. Consulte as bibliografias adicio-
nais, se necessário, ou contate empresas ou parceiros que entendam do assunto.
Você pode, ainda, usar o guia como referência para desenhar o processo específico do PDP da sua empresa.
Se você for um gerente de projeto de desenvolvimento de produtos, leia o Ca-
Gerente de projeto de
pítulo 2 e verifique a aderência do modelo à sua empresa. Se a empresa já possuir um
desenvolvimento de
produtos modelo do PDP, use o livro como um benchmarking das melhores práticas. Se não
Apresentação xvii

possuir, você pode adotar o livro como referência, e adaptar o modelo à realidade de sua empresa. Nesses casos,
a empresa pode definir um gerente de implantação do PDP (veja o tipo de usuário anterior).
Qualquer que seja a direção tomada, o livro pode ser lido e discutido em grupo, com cada membro se res-
ponsabilizando pela leitura e apresentação detalhada de capítulos específicos. A aprendizagem, bem como a ade-
quação do modelo às necessidades da empresa, podem ser maiores, em função da sinergia no grupo de estudo.
No final, podem ser definidos especialistas por quadros relevantes, e eles devem dar continuidade ao estudo
e à implantação dos conceitos e ferramentas estudadas.
No caso de você ser um membro de um time de desenvolvimento, leia primeiro
o Capítulo 2, para obter uma visão ampla do processo. Em seguida, utilize o Apên- Membro de um time de
dice I “Áreas de conhecimento versus atividades” para identificar quais são as ativi- desenvolvimento
dades relacionadas com a sua capacitação. Leia os capítulos relacionados com as
atividades, assim como os quadros correspondentes. Se achar que são relevantes
para o seu trabalho, consulte as informações adicionais e estude o material que obtiver.
Utilize os quadros para realizar um autodiagnóstico dos seus conhecimentos e, assim, adquirir motivação
para aprender novidades.
Procure identificar com colegas do time, que possuem uma outra capacitação, quais as áreas de interesse
deles. Tente entender como todos os membros são importantes para o projeto de desenvolvimento.
Se você já estiver trabalhando com base em um modelo semelhante, identifique e analise os exemplos de
critérios de revisão de fases e os exemplos de indicadores que podem ser aplicados na sua empresa.
Sumário
GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

PARTE 1 O Processo 1

1. Gestão do Processo de Desenvolvimento de Produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3


1.1 O que é o Processo de Desenvolvimento de Produtos e sua importância . . . . . . . . . . . . . . . . . . . . 3
1.2 O papel do PDP no Brasil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Características do PDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Tipos de projetos de desenvolvimento de produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Definição e escopo do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 A importância da gestão do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Abordagens para gestão do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.8 Arranjos organizacionais para o PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.9 Fatores gerenciais que afetam o desempenho do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.10 Modelo de referência é essencial para o PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.11 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.12 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.13 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2. O Modelo Unificado do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37


2.1 Conceitos de modelagem de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2 Visão geral do modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3 Os papéis principais das pessoas envolvidas no PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.4 Visão geral da macrofase de pré-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.4.1 Por que pré-desenvolvimento? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.4.2 Conceitos básicos do processo de planejamento estratégico . . . . . . . . . . . . . . . . . . . . . . . . 52
2.4.3 O início e o fim do pré-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.4.4 A importância do pré-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.4.5 Pré-desenvolvimento é para todos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.5 Visão geral da macrofase de desenvolvimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.5.1 Características das fases do desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.5.2 O início e o fim do desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.6 Visão geral da macrofase de pós-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.6.1 Por que pós-desenvolvimento? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.6.2 O início e o fim do pós-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.6.3 Pós-desenvolvimento é para todos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.7 Revisão de fases (gates) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.8 Métodos e ferramentas de desenvolvimento de produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.9 Indicadores de desempenho do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.10 Parceiros do desenvolvimento colaborativo de produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.11 Áreas de conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.12 Gestão do conhecimento do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.13 Caracterizando o modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.14 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
2.15 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
2.16 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
xx GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

PARTE 2 O Modelo 103

3. Atividades Genéricas do Modelo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105


3.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.2 Atualizar plano da fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.3 Monitorar viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.4 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.5 Aprovar fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.6 Documentar as decisões tomadas e registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.7 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.8 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4. Planejamento Estratégico de Produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115


4.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.2 Definir escopo da revisão do PEN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.3 Planejar atividades para a revisão do PEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.4 Consolidar informações sobre tecnologia e mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.5 Revisar o PEN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.6 Analisar o portfólio de produtos da empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.7 Propor mudanças no portfólio de produtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.8 Verificar a viabilidade do portfólio de produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.9 Decidir o início do planejamento de um dos produtos do portfólio . . . . . . . . . . . . . . . . . . . . . . 145
4.10 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
4.11 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

5. Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149


5.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.2 Definir interessados do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.3 Definir escopo do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
5.4 Definir escopo do projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
5.5 Detalhar o escopo do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
5.6 Adaptar o modelo de referência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
5.7 Definir atividades e seqüência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.8 Preparar cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
5.9 Avaliar riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.10 Preparar orçamento do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
5.11 Analisar a viabilidade econômica do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.12 Definir indicadores de desempenho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
5.13 Definir plano de comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
5.14 Planejar e preparar aquisições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
5.15 Preparar plano de projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5.16 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
5.17 Aprovar fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.18 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.19 Questões e atividades didáticas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
5.20 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

6. Projeto Informacional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211


6.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.2 Atualizar o Plano do Projeto Informacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.3 Revisar e atualizar o escopo do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.4 Detalhar ciclo de vida do produto e definir seus clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
6.5 Identificar os requisitos dos clientes do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
6.6 Definir os requisitos do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Sumário xxi

6.7 Definir especificações-meta do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225


6.8 Monitorar a viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
6.9 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
6.10 Aprovar fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
6.11 Documentar as decisões tomadas e registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6.12 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6.13 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

7. Projeto Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235


7.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
7.2 Atualizar o Plano do Projeto Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
7.3 Modelar funcionalmente o produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
7.4 Desenvolver princípios de solução para as funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
7.5 Desenvolver as alternativas de solução para o produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
7.6 Definir arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
7.7 Analisar Sistemas, Subsistemas e Componentes (SSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
7.7 Definir ergonomia e estética do produto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
7.8 Definir fornecedores e parcerias de co-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
7.9 Selecionar a concepção do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
7.10 Definir plano macro de processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
7.11 Atualizar estudo de viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
7.12 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
7.13 Aprovar fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
7.14 Documentar as decisões tomadas e registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 291
7.15 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
7.16 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

8. Projeto Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293


8.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
8.2 Atualizar o plano do projeto detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
8.3 Criar e detalhar SSCs, documentação e configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
8.3.1 Criar, reutilizar, procurar e codificar SSCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
8.3.2 Calcular e desenhar os SSCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
8.3.3 Especificar tolerâncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
8.3.4 Integrar os SSCs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
8.3.5 Finalizar desenhos e documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
8.3.6 Configurar produto e completar a estrutura do produto . . . . . . . . . . . . . . . . . . . . . . . . . . 335
8.4 Decidir fazer ou comprar SSCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
8.5 Desenvolver fornecedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
8.6 Planejar processo de fabricação e montagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
8.7 Projetar recursos de fabricação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
8.8 Avaliar SSCs, configuração e documentação do produto e processo . . . . . . . . . . . . . . . . . . . . . . 363
8.9 Otimizar produto e processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
8.10 Criar material de suporte do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
8.11 Projetar embalagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
8.12 Planejar fim de vida de produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
8.13 Testar e homologar produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
8.14 Enviar documentação do produto a parceiros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
8.15 Monitorar a viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
8.16 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
8.17 Aprovar fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
8.18 Documentar as decisões tomadas e registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 386
8.19 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
8.20 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
xxii GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

9. Preparação da Produção do Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393


9.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
9.2 Obter recursos de fabricação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
9.3 Planejar produção piloto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
9.4 Receber e instalar recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
9.5 Produzir lote piloto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
9.6 Homologar o processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
9.7 Otimizar a produção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
9.8 Certificar produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
9.9 Desenvolver processo de produção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
9.10 Desenvolver processo de manutenção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
9.11 Ensinar pessoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
9.12 Monitorar viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
9.13 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
9.14 Aprovar fase — liberação da produção. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
9.15 Documentar as decisões tomadas e registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 412
9.16 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
9.17 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

10. Lançamento do Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415


10.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
10.2 Planejar lançamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
10.3 Desenvolver processo de vendas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
10.4 Desenvolver processo de distribuição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
10.5 Desenvolver processo de atendimento ao cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
10.6 Desenvolver processo de assistência técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
10.7 Promover marketing de lançamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
10.8 Lançar produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
10.9 Gerenciar lançamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
10.10 Atualizar plano de fim de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
10.11 Monitorar viabilidade econômico-financeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
10.12 Avaliar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
10.13 Aprovar fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
10.14 Documentar as decisões tomadas, registrar lições aprendidas e encerrar a macrofase de
desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
10.15 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
10.16 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

11. Acompanhar Produto e Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435


11.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
11.2 Avaliar satisfação do cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
11.3 Monitorar desempenho do produto (técnico, econômico, ambiental,
de produção e de serviços) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
11.4 Realizar auditoria pós-projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
11.5 Registrar lições aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
11.6 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Questões para reflexão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
11.7 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

12. Descontinuar o Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445


12.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
12.2 Analisar e aprovar descontinuidade do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
12.3 Planejar a descontinuidade do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
12.4 Preparar o recebimento do produto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
12.5 Acompanhar o recebimento do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Sumário xxiii

12.6 Descontinuar a produção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451


12.7 Finalizar suporte ao produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
12.8 Avaliação geral e encerramento do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
12.9 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
12.10 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

13. Processos de Apoio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453


13.1 Gerenciamento de Mudanças de Engenharia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
13.1.1 Informações e papéis do ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
13.1.2 Sumário do processo de Gerenciamento de Mudanças de Engenharia. . . . . . . . . . . . . . . 460
13.1.3 Identificar mudança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
13.1.4 Propor mudança. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
13.1.5 Alterar informações do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
13.1.6 Implementar mudança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
13.1.7 Comentários sobre a implantação do processo de ECM . . . . . . . . . . . . . . . . . . . . . . . . . . 466
13.2 Melhoria Incremental do PDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
13.2.1 Método amplo de transformação de negócios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
13.2.2 Sumário do processo de melhoria incremental do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . 471
13.2.3 Informações e papéis na melhoria incremental do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . 472
13.2.4 Entender motivação das melhorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
13.2.5 Analisar situação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
13.2.6 Definir Ações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
13.2.7 Implantar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
13.3 Prover a infra-estrutura, educar e treinar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
13.4 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
13.5 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

PARTE 3 A Aplicação 479

14. Níveis de maturidade do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481


14.1 Conceitos sobre maturidade de processo de negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
14.2 Níveis de maturidade para o PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
14.3 Nível 1: Básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
14.4 Nível 2: Intermediário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
14.5 Níveis avançados de maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
14.6 Comentários sobre os níveis de maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
14.7 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
14.8 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
14.9 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

15. Método de transformação do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491


15.1 Entender motivação das melhorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
15.2 Analisar a situação atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
15.3 Definir ações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
15.4 Implantar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
15.5 Prover infra-estrutura, educar e treinar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
15.6 Integração entre transformação e melhoria incremental do PDP . . . . . . . . . . . . . . . . . . . . . . . . 503
15.7 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
15.8 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
15.9 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
xxiv GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

16. O modelo, suas alternativas de aplicação e sua relação com outras abordagens
para gestão do PDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
16.1 Modelo para projetos radicais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
16.2 Modelo para produção sob encomenda ETO (Engineering To Order) . . . . . . . . . . . . . . . . . . . 508
16.3 Modelo para fornecedor de commodities e para fornecedor de outros tipos
de tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
16.4 Relação entre o modelo e outras abordagens para gestão do PDP. . . . . . . . . . . . . . . . . . . . . . . . 510
16.5 Questões e atividades didáticas propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
16.6 Informações adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Apêndice I Modelo de Referência para o PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

Apêndice II Glossário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

Apêndice III Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541


Lista de Quadros xxv

Lista de Quadros
GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Quadro 1.1 Times/Equipes de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


Quadro 2.1 Estratégia Tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Quadro 2.2 Planejamento Estratégico, Marketing ou Desenvolvimento de Produtos?. . . . . . . . . . . . . . . . . . . . . . . . 58
Quadro 2.3 O que é Engenharia Simultânea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Quadro 2.4 Diretrizes para a Realização de Reuniões Produtivas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Quadro 2.5 Sistemas ERP e Soluções Relacionadas: CRM, SCM e PLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Quadro 2.6 O Surgimento da Parceira com Fornecedores e das Empresas Especializadas
em Serviços de Engenharia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Quadro 2.7 Outros Modelos de Referência Organizam as Atividades por Áreas de Conhecimento . . . . . . . . . . . . . 87
Quadro 2.8 Diferenças entre o PDP e Outros Processos Estruturados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Quadro 4.1 Fontes de Dados para Pesquisa de Mercado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Quadro 4.2 Fontes de Erro em Pesquisas de Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Quadro 4.3 Vigilância Tecnológica na Era da Gestão do Conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Quadro 4.4 Formas de Capacitação Tecnológica (learning) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Quadro 4.5 Tipos de Inovação Tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Quadro 4.6 Comunidades de Prática no PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Quadro 4.7 Gestão de Portfólio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Quadro 4.8 Técnicas para Avaliação do Portfólio de Produtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Quadro 4.9 Comparando as Técnicas para a Avaliação de Portfólio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Quadro 4.10 Diferenciação e Posicionamento de Produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Quadro 4.11 Estratégias para Planejamento do Portfólio de Produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Quadro 4.12 Minuta do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Quadro 5.1 Gestão de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Quadro 5.2 Escritório de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Quadro 5.3 Participação de Fornecedores no PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Quadro 5.4 Escopo do Produto versus Escopo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Quadro 5.5 Checklist do Escopo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Quadro 5.6 Definição de EDT (WBS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Quadro 5.7 Cuidados para a Elaboração da EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Quadro 5.8 Importância da Definição do Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Quadro 5.9 Erros Comuns na Preparação da Declaração do Escopo do Projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Quadro 5.10 Tipos de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Quadro 5.11 Identificando as Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Quadro 5.12 Softwares de Gestão de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Quadro 5.13 Tipos de Relacionamentos entre Atividades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Quadro 5.14 Análise Econômica do Desenvolvimento de Produtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Quadro 5.15 A Análise Financeira Acompanhará Todo o Ciclo de Vida do Produto . . . . . . . . . . . . . . . . . . . . . . . . . 196
Quadro 6.1 Termos Utilizados no Projeto Informacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Quadro 6.2 Clientes e Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
xxvi GESTÃO DE DESENVOLVIMENTO DE PRODUTOS

Quadro 6.3 Visão dos Custos do Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222


Quadro 6.4 Checklist para Obtenção de Requisitos de Produto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Quadro 6.5 Quality Function Deployment (QFD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Quadro 7.1 Termos Utilizados no Projeto Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Quadro 7.2 Método FAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Quadro 7.3 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Quadro 7.4 Matriz Morfológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Quadro 7.5 TIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Quadro 7.6 Projeto Modular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Quadro 7.7 Seleção de Materiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Quadro 7.8 Relação de DFX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Quadro 7.9 Princípios e Recomendações do Projeto para a Manufatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Quadro 7.10 Princípios e Recomendações do Projeto para a Montagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Quadro 7.11 Ergonomia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Quadro 7.12 Definição de Design ou Desenho Industrial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Quadro 8.1 Integração do Projeto Detalhado com o Projeto Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Quadro 8.2 Tipos de Ciclos da Fase de Detalhamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Quadro 8.3 Projeto Preliminar entre o Projeto Conceitual e Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Quadro 8.4 Recomendações para o Planejamento das Tarefas de Detalhamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Quadro 8.5 Termos Utilizados no Projeto Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Quadro 8.6 Classificação de Itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Quadro 8.7 Sistemas CSM, Catálogos na Internet e o e-procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Quadro 8.8 Padronização no Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Quadro 8.9 Identificação de Itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Quadro 8.10 Gerenciamento dos Parâmetros Críticos (CPM) de um Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Quadro 8.11 Sistemas CAD/CAE/CAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Quadro 8.12 Geometric Dimensioning and Tolerancing (GD&T) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Quadro 8.13 Processo de Desenvolvimento de Software (PDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Quadro 8.14 Tipos de BOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Quadro 8.15 Custo-alvo e Gestão de Custos do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Quadro 8.16 Diminuindo os Custos, Desenvolvendo Fornecedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Quadro 8.17 Paralelismo entre Desenhar e Planejar Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Quadro 8.18 Sistemas Product Data Management (PDM — Gestão de Dados de Produto) . . . . . . . . . . . . . . . . . . . 347
Quadro 8.19 Métodos Amplos de Planejamento do Processo Tradicional (Manual) . . . . . . . . . . . . . . . . . . . . . . . . . 350
Quadro 8.20 Manufatura Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Quadro 8.21 Sistemas Computer Aided Process Planning (CAPP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Quadro 8.22 Projeto de Fábrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Quadro 8.23 Métodos de Avaliação dos Sistemas, Subsistemas e Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Quadro 8.24 Failure Mode and Effect Analysis (FMEA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Quadro 8.25 Planejamento de Experimentos (DOE —Design Of Experiments) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Quadro 8.26 Projeto Robusto (RD —Robust Design) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Quadro 8.27 O Uso de Protótipos e Modelos de Produtos (Componentes e Ferramentas) . . . . . . . . . . . . . . . . . . . . 373
Quadro 8.28 Disponibilidade, Confiabilidade e Manutenabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Quadro 8.29 Requisitos da ISO 9001 e as Atividades Deste Modelo de Referência . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Quadro 8.30 Product Life-cycle Management (PLM ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Lista de Quadros xxvii

Quadro 9.1 Análise dos Sistemas de Medição (MSA — Measurement System Analysis) . . . . . . . . . . . . . . . . . . . . . 402
Quadro 9.2 Indicadores de Capabilidade de Processo e Controle Estatístico do Processo (CEP) . . . . . . . . . . . . . . 404
Quadro 9.3 Lean Production (Produção Enxuta) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Quadro 10.1 Logística e Distribuição na Gestão da Cadeia de Suprimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Quadro 10.2 Sistemas de Gestão Eletrônica de Documentos (GED) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Quadro 10.3 Riscos se os Processos de Apoio não Estiverem Operacionais no Lançamento . . . . . . . . . . . . . . . . . . . 428
Quadro 10.4 Tarefas de Marketing no Desenvolvimento de Produtos?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Quadro 11.1 Considerações sobre a Macrofase de Pós-desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Quadro 11.2 As Atividades de Acompanhamento Propiciam Benefícios para o Produto e para
PDP como um Todo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Quadro 12.1 O Impacto Ambiental, Relacionado à Retirada do Produto, Deve Ser Analisado, e
Qualquer Aspecto Negativo, Tratado de Forma a Gerar uma Ação Efetiva . . . . . . . . . . . . . . . . . . . . . 448
Quadro 12.2 Ecodesign e Design For Environment (DFE ). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Quadro 13.1 ECM versus Gestão da Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Quadro 13.2 Sistemas Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Quadro 13.3 Considerações sobre Melhoria do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Quadro 13.4 PDCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Quadro 13.5 Técnicas de Diagnóstico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Quadro 15.1 Melhoria Incremental ou Inovadora (Transformação)?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Quadro 15.2 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Quadro 15.3 Sistematização do PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Como foi mencionado na Apresentação deste livro, esta primeira parte for-
nece a base conceitual para o entendimento do modelo (veja a Figura P1).
Esta primeira parte é dividida em dois capítulos. O Capítulo 1 traz os concei-
tos da área de Gestão do Desenvolvimento de Produtos (GDP), que é a área que
usa modelos de referência para a melhoria do processo. Destaca, ainda, a impor-
tância do Processo de Desenvolvimento de Produtos (PDP) para as empresas em
geral. Em seguida, discute as particularidades desse processo de negócio e,
também, a realidade do Brasil nessa área, as principais abordagens e arranjos or-
ganizacionais para o PDP, e quais os fatores que afetam o desempenho desse
processo. As principais abordagens de GDP, então, são apresentadas, as quais
serão novamente mencionadas no capítulo final, quando elas forem comparadas
com o Modelo Unificado deste livro.
Se você observar o tópico “Como ler e empregar este livro”, mostrado na
Apresentação, verá a importância do Capítulo 2, que traz uma visão geral do mo-
delo. Nele são apresentadas as macrofases e os principais conceitos gerais, que
estão detalhados na Parte 2 deste livro. Esse capítulo é ideal para leitores que de-
sejam ter uma visão ampla, mas superficial, do modelo. Para os demais leitores, é
importante obter uma visão do todo, para, depois, aprofundar-se nas fases e ati-
vidades do modelo.

Visão geral dos capítulos da Parte 1.

Parte 1 O Processo
Gestão do Processo de Desenvolvimento de Produtos 3

1.1 O que é o Processo de Desenvolvimento de Produtos e sua importância


1.2 O papel do PDP no Brasil
1.3 Características do PDP
1.4 Tipos de projetos de desenvolvimento de produtos
1.5 Definição e escopo do PDP
1.6 A importância da gestão do PDP
1.7 Abordagens para gestão do PDP
1.8 Arranjos organizacionais para o PDP
1.9 Fatores gerenciais que afetam o desempenho do PDP
1.10 Modelo de referência é essencial para o PDP
1.11 Resumo do capítulo
1.12 Questões e atividades didáticas propostas
1.13 Informações adicionais
1. Gestão do Processo de Desenvolvimento de Produtos
Gestão do Processo de Desenvolvimento de Produtos
PARTE 1 O Processo

Depois da leitura deste capítulo, você será capaz de:


l Entender o que é desenvolver um produto e qual é o processo pelo qual são gerados novos produtos.
l Entender a importância estratégica do processo de desenvolvimento de produto e em que ele contribui para a
competitividade da empresa.
l Conhecer as principais características específicas das atividades típicas de desenvolvimento de produto, tais como o
elevado grau de incerteza e de requisitos a serem atendidos.
l Compreender como o desempenho desse processo depende da sua gestão.
l Conhecer as principais abordagens e arranjos organizacionais para gestão do desenvolvimento de produto.
l Conhecer os principais fatores gerenciais que contribuem para o desempenho desse processo
l Compreender que a adoção de um modelo de referência é importante para guiar a estruturação e a gestão desse
processo.

1.1 O que é o Processo de Desenvolvimento de Produtos e sua importância


De modo geral, desenvolver produtos consiste em um conjunto de atividades por meio das quais busca-se, a
partir das necessidades do mercado e das possibilidades e restrições tecnológicas, e considerando as estratégias
competitivas e de produto da empresa, chegar às especificações de projeto de um produto e de seu processo de
produção, para que a manufatura seja capaz de produzi-lo. O desenvolvimento de produto também envolve as
atividades de acompanhamento do produto após o lançamento para, assim, serem realizadas as eventuais mu-
4 PARTE 1 O Processo

danças necessárias nessas especificações, planejada a descontinuidade do produto no mercado e incorporadas,


no processo de desenvolvimento, as lições aprendidas ao longo do ciclo de vida do produto.
O desenvolvimento de produtos é considerado um processo de negócio cada vez mais crítico para a compe-
titividade das empresas, principalmente com a crescente internacionalização dos mercados, aumento da diversi-
dade e variedade de produtos e redução do ciclo de vida dos produtos no mercado. Novos produtos são
demandados e desenvolvidos para atender a segmentos específicos de mercado, incorporar tecnologias diversas,
se integrar a outros produtos e usos e se adequar a novos padrões e restrições legais.
Ou seja, é por meio desse processo que a empresa pode criar novos produtos mais competitivos e em menos
tempo para atender à constante evolução do mercado, da tecnologia e dos requisitos do ambiente institucional
(principalmente quanto à sua saúde, meio ambiente e segurança).
Os clientes estão cada vez mais exigentes, informados e com maiores possibilidades de escolhas, e as em-
presas competidoras globais, com freqüência, lançam novos produtos, os quais buscam atender continuada-
mente às mudanças nas necessidades dos clientes, de forma melhor e com maior número de funcionalidades,
tornando-os mais atrativos e criando no cliente o desejo de substituir o produto (modelo) anterior.
Esse ambiente competitivo impõe ao processo de desenvolvimento de produtos a necessidade de estar apto,
em habilidades e competências, para atuar com dinamismo e flexibilidade em um grau até então não experimen-
tado pelas empresas.
O Processo de Desenvolvimento de Produtos (PDP) situa-se na interface
Desenvolvimento de entre a empresa e o mercado, cabendo a ele identificar — e até mesmo se antecipar
produtos: interface entre a — as necessidades do mercado e propor soluções (por meio de projetos de produtos
empresa e o mercado
e serviços relacionados) que atendam a tais necessidades. Daí sua importância estra-
tégica, buscando: identificar as necessidades do mercado e dos clientes em todas as
fases do ciclo de vida do produto; identificar as possibilidades tecnológicas; desenvolver um produto que atenda
às expectativas do mercado, em termos da qualidade total do produto; desenvolver o produto no tempo ade-
quado — ou seja, mais rápido que os concorrentes — e a um custo competitivo. Além disso, também deve ser as-
segurada a manufaturabilidade do produto desenvolvido, isto é, a facilidade de produzi-lo, atendendo às
restrições de custos e de qualidade na produção.
Diversas publicações apontam o papel central que o PDP tem representado no
Desenvolvimento de ambiente competitivo das últimas décadas. Além disso, significativos estudos anali-
produtos: importante sando o desempenho de empresas em âmbito mundial, principalmente comparando
para aumento da
as indústrias japonesas e norte-americanas, demonstraram que uma importante par-
competitividade
cela da vantagem competitiva conseguida pela manufatura japonesa nas últimas dé-
cadas advém do modo como os produtos são desenvolvidos e aperfeiçoados. As
indústrias norte-americanas e européias dos setores automobilísticos e de produtos eletrônicos de consumo, por
exemplo, incorporaram muitos novos conhecimentos sobre gestão do PDP a partir dos casos bem-sucedidos de
desenvolvimento de produtos por empresas japonesas.
O lançamento eficaz de novos produtos e a melhoria da qualidade daqueles já existentes fazem parte do es-
copo do PDP e são duas questões de grande relevância para a capacidade competitiva das empresas.
Historicamente, por influência da cultura dominante nos tradicionais laboratórios de Pesquisa & Desen-
volvimento (P&D), considerava-se que o êxito das empresas no desenvolvimento de produtos dependeria em
grande parte da genialidade dos profissionais que atuavam nesse processo e de maiores montantes financeiros
alocados a ele. Considerava-se que as incertezas, a baixa previsibilidade e criatividade inerentes a esse processo
inviabilizariam qualquer tentativa de disciplinar as atividades e estruturar e gerenciar o processo, com conse-
qüências negativas nos resultados obtidos.
Ao longo das últimas décadas, diversos casos bem-sucedidos de empresas e países em termos de desenvolvi-
mento de produtos evidenciaram que o desempenho desse processo depende também e muito do modelo e das
práticas de gestão adotadas. Ou seja, mesmo com tais especificidades (incerteza, baixa previsibilidade e criativi-
dade), é possível e necessário gerenciar o PDP, planejando, executando, controlando e melhorando as atividades,
em busca de melhores resultados de desempenho e de aprendizagem — algo que será apresentado ao longo
deste livro.
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 5

1.2 O papel do PDP no Brasil


Em países em desenvolvimento, como é o caso do Brasil, as atividades de desenvolvimento de produtos tra-
dicionalmente se concentram em grande parte nas adaptações e melhorias de produtos existentes. Em alguns
segmentos de mercado (como automóveis, equipamentos eletrônicos, produtos farmacêuticos), os novos pro-
dutos tendem a ser concebidos e projetados quase exclusivamente nos países desenvolvidos (onde normalmente
estão localizados os centros de desenvolvimento das corporações multinacionais e onde os mercados têm maior
poder aquisitivo) e são difundidos nos demais países via transferência internacional de tecnologia. Assim, para
produtos desses segmentos, as atividades de desenvolvimento de produtos no Brasil são voltadas principalmente
para adequação do produto e do projeto às condições do mercado local, à estrutura de fornecedores existentes e
aos processos de produção disponíveis.
A importância estratégica e a divisão internacional de atividades do PDP, entre países desenvolvidos e em
desenvolvimento, evidentemente, manifestam-se de forma diferenciada, conforme o setor e, também, o papel
do país na produção mundial do produto em questão.
No Brasil, em muitos setores industriais, a tendência em termos de desenvolvimento de produto é no sen-
tido de consolidar uma competência local para adaptar projetos mundialmente atuais para o mercado local ou
regional (por exemplo, Mercosul), ou mesmo para participar de projetos de desenvolvimento mundiais — res-
ponsabilizando-se por atividades e/ou etapas específicas desses projetos em função das capacitações existentes
no país. Nesse segundo caso, a unidade local da corporação multinacional pode se responsabilizar por etapas do
desenvolvimento e, eventualmente, ser a responsável pelo fornecimento global do produto, em função da capa-
cidade de manufatura local. Também podem existir casos específicos em que a unidade local é a responsável pelo
desenvolvimento total de um produto, em função do domínio tecnológico e de vantagens competitivas no de-
senvolvimento de determinadas linhas de produto. Essa possibilidade surge como reflexo de uma alternativa de
organização do desenvolvimento de produto, de corporações multinacionais, de forma distribuída, a partir de
competências locais específicas que cada unidade procura adquirir e que estão distribuídas pelo mundo, em con-
traposição às alternativas de desenvolvimento totalmente centralizado (na matriz) ou descentralizado (por país,
sendo que, em cada um, pode haver repetição de competências). É o caso, por exemplo, do desenvolvimento de
projetos de ônibus, de caminhões e de compressores herméticos por algumas unidades de multinacionais insta-
ladas no Brasil.
Pode-se destacar, ainda, o papel e a capacitação crescente do país no desenvolvimento de carros populares
(com motorização de baixa cilindrada) e o reconhecimento internacional da capacitação da Embraer na coorde-
nação dos projetos de desenvolvimento de suas aeronaves.
Em relação ao desenvolvimento de produto em unidades de multinacionais instaladas no Brasil, observa-se,
em algumas empresas, movimentações no sentido de reduzir as atividades de desenvolvimento locais, e, em ou-
tras, observa-se o aumento do espectro de atividades realizadas aqui no país. Não fica claro qual será o sentido
dominante da tendência geral dessas movimentações (se de aumento ou redução) em relação às atividades do
PDP realizadas no Brasil.
Para equilíbrio e geração de superávits nas contas externas do Brasil, o país necessita exportar produtos de
maior valor agregado, em vez de matérias-primas e produtos semiprocessados. Isso exige uma maior capacitação
e esforço de desenvolvimento de produto, para dispor, ao mercado local, produtos brasileiros com padrões equi-
valentes aos importados, e para capacitar o país a exportar produtos de padrão internacional.
E isso passa, necessariamente, pela melhoria na qualificação do corpo técnico e gerencial das empresas em
gestão do Processo de Desenvolvimento de Produtos, o que é um dos focos deste livro. Ou seja, considera-se
fundamental para o país a elevação do nível de conhecimento sobre as boas práticas de estruturação e gerencia-
mento desse processo de negócio.
É importante ressaltar que mesmo que a tecnologia e a concepção de um novo produto venha do exterior,
existem ainda muitas atividades de desenvolvimento (do projeto detalhado, passando pelo projeto ou planeja-
mento do processo, testes, projeto de fábrica, lançamento etc.), que estão inseridas no escopo do desenvolvi-
mento de produtos, e que fazem parte das responsabilidades de empresas locais.
6 PARTE 1 O Processo

1.3 Características do PDP


O PDP, comparado a outros processos de negócio, tem diversas especificidades. As principais caracterís-
ticas que diferenciam esse processo são:

n elevado grau de incertezas e riscos das atividades e resultados;


n decisões importantes devem ser tomadas no início do processo, quando as incertezas são ainda maiores;
n dificuldade de mudar as decisões iniciais;
n as atividades básicas seguem um ciclo iterativo do tipo: Projetar (gerar alternativas)-Construir-
Testar-Otimizar,
n manipulação e geração de alto volume de informações;
n as informações e atividades provêm de diversas fontes e áreas da empresa e da cadeia de suprimentos; e
n multiplicidade de requisitos a serem atendidos pelo processo, considerando todas as fases do ciclo de
vida do produto e seus clientes.

Essas características fazem com que a natureza desse processo seja relativamente diferente dos demais pro-
cessos da empresa, o que condicionará os modelos e práticas de gestão adequadas ao processo, além do perfil e
das capacitações requeridas dos profissionais que atuam no PDP.
O lançamento de um produto novo no mercado, para a maioria das empresas, não é uma atividade rotineira
e, sim, o resultado de um esforço que pode durar um tempo significativo e envolver quase todos os setores fun-
cionais da empresa, com implicações nas vendas futuras e conseqüentemente na sobrevivência da empresa.
Uma característica organizacional muito específica da atividade de desenvolvimento é que cada projeto
pode apresentar problemas, dificuldades e históricos muito particulares. Ou seja, a atividade de desenvolvi-
mento não é uma atividade rotineira, como acontece nos processos financeiros ou de produção.
O volume de informações de entrada no processo, de informações processadas e repassadas é relativamente
alto, variado e complexo. As informações de entrada, tais como requisitos de mercado, requisitos legais, requi-
sitos de homologação, as capacidades e competências da empresa e de sua rede de fornecedores etc., são bastante
variadas e provêm de diversas fontes internas e externas à empresa. Não se deve esquecer que os requisitos a
serem considerados dizem respeito a todos os clientes de todas as fases do ciclo de vida do produto (projeto, ma-
nufatura, distribuidores, usuários, pessoal de assistência técnica, reciclagem do produto etc.).
Além disso, as atividades do PDP influenciam e são influenciadas pelo trabalho de praticamente todas as
pessoas da empresa, já que o novo produto será desenvolvido, produzido, vendido e controlado envolvendo e
sendo envolvido por todos os setores. Assim, uma especificidade na gestão do PDP é a necessidade de integração
de informações e decisões com muitas áreas da empresa. Isso aumenta a importância da coordenação e da comu-
nicação entre as etapas e atividades relativas ao processo e a necessidade de integração interfuncional.
Nas fases iniciais do PDP é que são definidas as principais soluções construtivas e as especificações do pro-
duto. É nesse momento que são determinados os materiais e as tecnologias a serem utilizados, os processos de
fabricação, a forma construtiva etc. Apesar de existir a possibilidade de caminhar ao longo do processo com solu-
ções alternativas, as definições essenciais e centrais são determinadas nesse período.
Normalmente, argumenta-se que as escolhas de alternativas ocorridas no
As decisões técnicas início do ciclo de desenvolvimento são responsáveis por cerca de 85% do custo do
iniciais determinam produto final. Ou seja, todas as outras definições e decisões a serem tomadas ao
85% do custo final
do produto...
longo do ciclo de desenvolvimento, após as fases iniciais, determinam 15% do
custo. Em outras palavras, depois da definição dos materiais, tecnologia, processos
de fabricação e principais soluções construtivas, resta ao time de desenvolvimento:
determinar as tolerâncias das peças; construir e testar o protótipo; definir os fornecedores; o arranjo de parceiros
da cadeia de suprimentos e o arranjo físico da produção; a campanha de marketing; assistência técnica etc. E
essas definições, quando comparadas com as anteriores, exercem menor influência no custo final do produto.
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 7

Além disso, parte dessas definições também ocorre nas fases iniciais e apenas são detalhadas e consolidadas nas
fases subseqüentes.
Conforme mostra a Figura 1.1, para muitos tipos de produto, durante as fases de desenvolvimento, os
custos de fato incorridos (ou seja, aqueles que já aconteceram) são relativamente baixos em relação ao custo final.
Porém, por outro lado, essas fases são bastante críticas quanto ao comprometimento do custo final do produto.
Nas fases de produção, são poucas as possibilidades de redução desse custo, já que elas estão atreladas às especifi-
cações técnicas já definidas.

Figura 1.1 Curva de comprometimento do custo do produto.

No entanto, exatamente quando se toma a maior parte das decisões, que são
significativas para a determinação do custo final do produto, é o momento no qual ...mas, justo no início,
se tem o maior grau de incerteza sobre o produto e suas especificações, sobre o seu quando temos de tomar
as decisões, as incertezas
processo de fabricação e mesmo se ele será um sucesso no mercado. Somente no de- são grandes
senrolar do desenvolvimento, quando muitos conceitos, alternativas construtivas e
soluções estiverem definidos, é que esse grau de incerteza vai diminuindo.
Com o tempo, as incertezas vão diminuindo, de acordo com as definições que vão sendo tomadas. Mas o
fato concreto é que é preciso tomar decisões importantes quando ainda se têm muitas incertezas.
Por mais que se procure tomar as melhores decisões e acertar as definições no início do desenvolvimento,
sempre ocorrem mudanças no projeto ao longo do desenvolvimento, uma vez que as decisões tomadas envolvem
muitas incertezas. O custo de modificação de uma decisão anterior de projeto aumenta ao longo do ciclo de de-
senvolvimento, pois, para se efetivar uma mudança, as decisões já tomadas e as ações conseqüentes já realizadas
podem ser invalidadas.
O segredo de um bom desenvolvimento de produtos é, assim, garantir que as
O segredo, então, é
incertezas sejam minimizadas por meio da qualidade das informações, e que, a cada
gerenciar as incertezas
momento de decisão, exista um controle constante dos requisitos a serem atendidos
e uma vigilância das possíveis mudanças de mercado.
8 PARTE 1 O Processo

As incertezas típicas dizem respeito não apenas à falta de informações relevantes sobre eventos previstos,
mas, também, à existência de problemas tecno-econômicos, cujos procedimentos de solução são desconhecidos,
e à impossibilidade de traçar precisamente as conseqüências das decisões e ações tomadas.
As atividades típicas do PDP seguem a seqüência Projetar-Construir-Testar-Otimizar, sendo que o que se
“projeta-constrói-testa-otimiza” pode ser um conceito, uma especificação ou uma tolerância, tanto do produto
ou do processo de produção. E isso é diferente das atividades típicas da manufatura em que, por exemplo, se tem
uma especificação do produto e se produz e controla o processo de fabricação para atingir essa especificação.
Tal especificidade faz com que o retrabalho, que é mais visível, definido e quantificável na atividade de ma-
nufatura, seja menos visível e definido, embora não menos custoso, no PDP, à medida que ele aparece diluído na
própria natureza iterativa das atividades do processo.

1.4 Tipos de projetos de desenvolvimento de produtos


Os projetos de desenvolvimento de produtos podem ser classificados por diversos critérios, sendo que a
classificação mais comum e útil é baseada no grau de mudanças que o projeto representa em relação a projetos
anteriores. Essa classificação depende das especificidades do setor. Por exemplo, existem significativas dife-
renças na classificação adotada no setor automobilístico em relação ao setor alimentício.
A Figura 1.2 traz a classificação de projetos de desenvolvimento usual nos setores de bens de capital e de
bens de consumo duráveis.

Figura 1.2 Tipos de projeto de desenvolvimento de produtos baseados na inovação.

n Projetos radicais (breakthrough): são os que envolvem significativas modificações no projeto do produto
ou do processo existente, podendo criar uma nova categoria ou família de produtos para a empresa.
Como, nesse tipo de projeto, são incorporados novas tecnologias e materiais, eles normalmente re-
querem um processo de manufatura também inovador.
n Projetos plataforma ou próxima geração: normalmente representam alterações significativas no projeto do
produto e/ou do processo, sem a introdução de novas tecnologias ou materiais, mas representando um
novo sistema de soluções para o cliente. Esse novo sistema de soluções pode representar uma próxima ge-
ração de um produto ou de uma família de produtos anteriormente existentes. Também pode representar
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 9

o projeto de uma estrutura básica do produto que seria comum entre os diversos modelos que compõem
uma família de produtos. Para funcionar como plataforma, um projeto deve suportar toda uma geração de
produto (ou de processo) e ter ligação com as gerações anteriores e posteriores do produto.
n Projetos incrementais ou derivados: envolvem projetos que criam produtos e processos que são derivados,
híbridos ou com pequenas modificações em relação aos projetos já existentes. Esses projetos incluem
versões de redução de custo de um produto e projetos com inovações incrementais nos produtos e pro-
cessos. Requerem menos recursos, pois partem dos produtos ou processos existentes, estendendo a sua
aplicabilidade e ciclo de vida.

Além desses tipos de projetos, em países como o Brasil, temos os chamados projetos follow-source (seguir a
fonte), que são projetos que chegam da matriz ou de outras unidades do grupo ou de clientes, e que não re-
querem alterações significativas da unidade brasileira que irá adequar o projeto e produzir o produto. Geral-
mente, nessas unidades, são realizadas atividades de desenvolvimento, como adaptações à realidade local,
validação do processo e de equipamentos e ferramentas, a produção do lote piloto e o início da produção.
Um outro tipo de projeto que pode existir nas empresas, mas menos comum, são os chamados Projetos de
Pesquisa Avançada, que têm por objetivo criar conhecimento para projetos futuros. Esses projetos normalmente
são precursores do desenvolvimento comercial, mas não possuem objetivos comerciais de curto prazo. Ou seja,
não se trata de um projeto de desenvolvimento de produto propriamente dito, mas, sim, de pesquisa avançada.
Todos esse tipos de projeto podem ser conduzidos internamente à empresa ou por meio de alianças ou par-
cerias com outras empresas ou instituições. A diferenciação em relação aos demais projetos não está no grau de
mudança incorporado, e, sim, no fato de ser conduzido fora do âmbito da empresa ou em parcerias com outras
empresas.
Nos casos em que a empresa dispõe de um portfólio de produtos e de projetos, adotando uma abordagem
de gerenciamento de multiprojetos e de projetos plataforma, é possível uma outra classificação de projetos de
desenvolvimento, caracterizando-os em quatro tipos, dependendo do escopo da nova tecnologia ou de mu-
danças na plataforma e de quão rápido a empresa transfere a plataforma de um projeto para outro. Os quatro
tipos de projeto são:

n Novo projeto: é aquele em que é desenvolvida uma nova plataforma tecnológica.


n Transferência de tecnologia simultânea: quando um novo projeto utiliza a plataforma de um projeto-
base, antes que o desenvolvimento deste tenha sido concluído.
n Transferência de tecnologia seqüencial: quando um novo projeto utiliza a plataforma de um projeto-
base, cujo desenvolvimento já foi concluído e encontra-se em fase de produção.
n Modificação de projeto: neste tipo, não há transferência de tecnologia ou de plataforma de um projeto
para outro. Um projeto é modificado, mas sem que haja mudança na plataforma. Há apenas modifica-
ções em um projeto existente.

Os projetos de novos produtos podem ser classificados também em termos de projetos de produtos que são
novos para a empresa e de projetos que são novos para o mercado. Projeto novo para a empresa é aquele cujo
produto já existe no mercado, mas que, para a empresa, é totalmente novo. Projeto novo para o mercado é
aquele cujo produto ainda não existe no mercado. O primeiro projeto de videocassete doméstico, que foi desen-
volvido pela JVC, era um produto novo para o mercado, ainda que tenha sido desenvolvido tendo como ponto
de partida equipamentos já existentes para exibição em cinemas. Já quando, por exemplo, anos após, a LG de-
senvolveu o seu primeiro projeto de videocassete, o projeto era novo apenas para a empresa. Obviamente,
quanto maior o grau de inovação do projeto, maior é o esforço de desenvolvimento requerido da empresa.
A importância de classificar os projetos de uma empresa está na necessidade de planejar estrategicamente e
de forma conjunta todos os projetos de desenvolvimento, os quais possuem relevância e necessidades de recursos
que são específicas a cada caso. Com isso, assegura-se que se tenha a quantidade adequada de recursos para coor-
10 PARTE 1 O Processo

denar e executar os vários projetos, conseguir eficiência nas atividades realizadas e obter um padrão adequado de
inovação dos produtos da empresa, que não seja nem tão conceitualmente estático nem caoticamente dinâmico.

1.5 Definição e escopo do PDP


Uma organização é um sistema complexo formado por pessoas e recursos,
Desenvolvimento de como equipamentos e instalações, com intensas, variadas e complexas relações entre
produtos como um si, tornando árdua a tarefa de compreendê-la. Essa complexidade, aliada às especifi-
processo
cidades do processo já citadas, dificulta a determinação do contorno que delimita a
composição do PDP, tendo em vista que esse processo abrange atividades de praticamente todas as áreas da em-
presa e de suas cadeias de suprimentos e de distribuição.
É importante considerar dois aspectos relevantes para o enfoque da estruturação e gestão do desenvolvi-
mento de produtos: o conceito de processo e o fluxo de informações. O PDP envolve um fluxo de atividades e de
informações.
Processo é, em linhas gerais, um conjunto de atividades realizadas em uma seqüência lógica com o objetivo
de produzir um bem ou serviço que tem valor para um grupo específico de clientes.
O conceito de processo auxilia na visualização das organizações em termos das atividades ou conjuntos de
atividades realizadas, de suas inter-relações e da integração e eficiência de suas operações.
A compreensão e o gerenciamento do fluxo de informações são importantes à medida que o PDP gera e faz
uso de entradas e saídas de conhecimentos e informações, nas atividades e no processo como um todo, intera-
gindo com as mais diversas fontes de informação, principalmente as áreas funcionais da empresa, fornecedores e
clientes. Quando o PDP é visualizado como um fluxo de informações, estão subentendidos o fluxo de criação, de
comunicação e de utilização das informações desenvolvidas, englobando a engenharia, a produção, o marketing
e o mercado consumidor.
A visão do PDP baseada em fluxo de atividades e de informações permite compreender as ligações críticas
entre as áreas da empresa e entre essa, o mercado, os fornecedores, as fontes de informação tecnológica e as ins-
tituições de regulamentação do produto. Desse modo, pode-se posicionar o PDP dentro do ambiente da empre-
sa, sua relação com os outros processos internos e com o ambiente externo à empresa.
O processo de desenvolvimento de produto foi, tradicionalmente, visto como a
O escopo do processo de elaboração de um conjunto de informações sobre as especificações de um produto e
desenvolvimento de sobre como produzi-lo e sua disponibilização para a manufatura. Mas essa visão
produto vem sendo
ampliado, envolvendo
convencional, ainda muito empregada, é posta em xeque quando se consideram as
muitas áreas funcionais da novas abordagens com as quais as empresas de ponta têm direcionado suas ativi-
empresa e a cadeia de dades de desenvolvimento de produto. Essas empresas abordam o PDP como um
suprimentos processo que integra suas áreas e sua cadeia de suprimentos.
Assim, o desenvolvimento de produto pode ser compreendido e visualizado
por meio da consideração de todas as atividades, internas à empresa e nas cadeias de suprimentos e de distribui-
ção. Essas participam da função de traduzir o conhecimento sobre as necessidades do mercado, as oportunidades
tecnológicas e as estratégias da empresa em informações para a produção, distribuição, uso, manutenção e descarte
do produto, considerando todo o seu ciclo de vida. Nessa nova visão, o PDP deve integrar desde atividades do pla-
nejamento estratégico e competitivo da empresa até a descontinuidade ou retirada do produto do mercado.
O desenvolvimento de produto envolve muitas atividades a serem executadas por diversos profissionais de
diferentes áreas da empresa, tais como: Marketing, Pesquisa & Desenvolvimento, Engenharia do Produto, Su-
primentos, Manufatura e Distribuição — cada uma vendo o produto por uma perspectiva diferente, mas com-
plementares. Tal particularidade exige que essas atividades, e suas decisões relacionadas, sejam realizadas em
conjunto e de forma integrada, evidenciando a necessidade de estruturar um processo específico que reúna esse
conjunto de atividades a serem planejadas e gerenciadas de forma dedicada.
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 11

A tomada de decisões sobre o projeto envolvendo pessoas com diferentes visões do produto, ainda na fase
de desenvolvimento, pode antecipar problemas e soluções, além de reduzir o tempo de lançamento do produto.
Decisões inadequadas tomadas no início do desenvolvimento podem ser difíceis e caras de serem revertidas nas
fases em que o produto já se encontra em produção e uso no mercado.
Assim, quanto ao escopo do PDP, há uma ampliação em ambos os sentidos do processo de negócio, ou seja,
a montante e a jusante de seu tradicional núcleo central, conforme pode ser acompanhado na Figura 1.3. Cada
vez mais são incorporadas nesse processo as estratégias de produto, de mercado e tecnológicas da empresa, além
das atividades necessárias para suportar a produção, o lançamento e o acompanhamento do produto no mercado
e a decisão de sua descontinuidade. Com essas ampliações, obtém-se um processo mais coeso em que o planeja-
mento e a execução do projeto e o acompanhamento do produto pós-venda estão integrados em um mesmo pro-
cesso de negócio, que, como em um ciclo, permite que seja gerenciada e garantida a retroalimentação rápida e
contínua dos dados e informações sobre o desempenho do produto e os requisitos dos consumidores e da socie-
dade. Os requisitos dos clientes e de instituições de regulamentação e os problemas manifestados nos produtos
em campo são, dessa forma, continuamente compilados e alimentam o planejamento e as decisões tomadas du-
rante o desenvolvimento de novos produtos e a melhoria dos produtos existentes.

Figura 1.3 O processo de desenvolvimento de produtos envolve o processo de planejamento estratégico e acompanha o processo de
produção.

O desenvolvimento de produtos deve abranger todo o planejamento e gerenciamento do portfólio de pro-


dutos (produtos que já estão no mercado, produtos que estão sendo lançados, produtos em fase de descontinui-
dade) e do portfólio de projetos (projetos em fase de planejamento, projetos em andamento, projetos
concluídos), garantindo compatibilidade com as estratégias da empresa. Deve abranger, também, a especifi-
cação de todos os recursos e procedimentos de manufatura, envolvendo compra de máquinas, equipamentos,
ferramentas e, quando necessário, a construção de novas unidades de produção. Ou seja, envolve tanto a gestão
estratégica quanto a gestão operacional desse processo de negócio, considerando aspectos de mercado e da ma-
nufatura. E, ainda, não se pode esquecer que o produto desenvolvido envolve não só o bem físico como também
todo o tipo de informação e serviços associados ao seu uso e manutençãoo. Assim, o seu desenvolvimento deve
abranger a obtenção e garantia da qualidade de todos esses itens, ou seja, do produto físico e dos serviços (por
exemplo, assistência técnica) e informações (por exemplo, manuais de instruções de operação e uso).
Uma das principais explicações para a ampliação da visão do desenvolvimento de produto é a preocupação
com o gerenciamento do ciclo de vida completo do produto (da identificação das necessidades à retirada física e
disposição do produto). Nesses casos, não existe a dissolução das equipes responsáveis pelo desenvolvimento (ou
12 PARTE 1 O Processo

pelo menos de parte dela) após a sua “entrega” para a manufatura. Ou seja, durante a fase de produção e con-
sumo, há momentos de registrar, para o PDP, as experiências obtidas a fim de melhorar e atualizar o produto de-
senvolvido e de aprender para não cometer os mesmos erros em futuros desenvolvimentos. Finalmente, deve-se
preparar e implantar o plano de descontinuidade do produto no mercado. Todas essas atividades, e também a lo-
gística de captação do produto no momento do seu descarte pelo cliente e o planejamento de sua reciclagem,
fazem parte do escopo do desenvolvimento.
Para um desenvolvimento de produto bem-sucedido, é essencial a integração
O PDP e outros processos desse processo com as funções e outros processos empresariais envolvidos na reali-
de negócio ou áreas zação de atividades ou suprimento de informações para o PDP. Isso requer que o
funcionais
tempo, a comunicação, a disponibilização de informações e o conteúdo das ativi-
dades nas várias funções estejam coordenados e que as ações tomadas nas funções apóiem-se mutuamente, tendo
em vista as metas do projeto.
Os principais processos e funções que realizam atividades pertinentes ao PDP podem ser visualizados na
Figura 1.4.

Figura 1.4 Processos relacionados com o desenvolvimento de produtos.

Os processos que, na Figura 1.4, aparecem acima do PDP envolvem basicamente atividades de manipu-
lação de informações referentes ao conhecimento sobre o mercado e às estratégias e práticas da empresa para
atender esse mercado. Já os processos que aparecem abaixo referem-se à realização de atividades mais técnicas
que suportam o desenvolvimento do projeto ou que permitem implantar o novo produto.
O modelo de PDP apresentado nos capítulos seguintes do livro considera a integração com todos esses pro-
cessos e funções, recebendo e fornecendo informações e compartilhando conhecimentos e atividades.
O Planejamento Estratégico é um processo gerencial que não está vinculado a uma função específica
dentro da empresa, caracterizando-se como um processo cross funcional. Uma das finalidades do Planejamento
Estratégico é gerar informações que orientem o PDP principalmente nas suas fases iniciais, quando ocorre a de-
finição do produto, mas também durante todo o processo de desenvolvimento. O Planejamento Estratégico,
desdobrado no Planejamento Estratégico do Produto, orienta o PDP em relação às estratégias tecnológicas
(foco da tecnologia central do produto, fontes para aquisição da tecnologia e timing para introdução das inova-
ções tecnológicas) e às estratégias de produto da empresa (linhas de produto, segmentos de mercado a serem
atendidos pela empresa, como levar o produto até o mercado — canais de distribuição —, características dos
produtos a serem priorizadas para enfrentar a concorrência e atrair os clientes etc.).
Monitorar o mercado é um processo geralmente vinculado à área funcional de Marketing. Tem por finali-
dade abastecer o PDP de informações sobre o mercado antes, durante e após o desenvolvimento propriamente
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 13

dito, acompanhando as tendências, comparando o desempenho e posicionamento dos produtos, captando re-
quisitos e sugestões dos clientes e das instituições que regulamentam o produto e o setor no qual a empresa atua.
O novo produto normalmente requer a preparação da equipe de Vendas, elaborando as argumentações
para a venda, as orientações a serem passadas aos clientes, as vantagens do novo produto, além da preparação dos
documentos pertinentes, tais como: rotinas, manuais e catálogos. Essas atividades devem se realizadas sob a
orientação e em conjunto com as equipes do desenvolvimento do produto.
Dependendo do tipo de produto, por exemplo, se é um novo equipamento com novas funcionalidades, ca-
berá à equipe de desenvolvimento preparar o pessoal interno que atuará nas funções de Atendimento ao Cliente,
para que os clientes sejam devidamente orientados (de forma remota ou com a presença física de equipes téc-
nicas no próprio cliente) nas dúvidas que poderão surgir no uso do produto e para que o cliente consiga utilizar o
novo produto em toda sua potencialidade. O PDP deverá capacitar o pessoal de atendimento para orientações
quanto a problemas no uso e manutenção do produto e preparar os manuais e roteiros pertinentes.
Em muitos modelos de referência sobre desenvolvimento de produto, em publicações e também em em-
presas, não há uma divisão clara entre o que é P&D e o que é PDP — sendo esses dois processos muitas vezes
considerados em conjunto como algo único. No contexto deste livro, entende-se que existem os dois processos,
cada um com uma finalidade específica. Ambos fazem parte de um processo mais amplo, que é o processo de ino-
vação na empresa.
O processo de P&D normalmente realiza atividades de pesquisa voltadas para o desenvolvimento ou do-
mínio das tecnologias, isto é, soluções baseadas em fenômenos físicos e químicos voltadas para a solução de pro-
blemas bastante específicos. O resultado desse processo é o domínio da tecnologia, isto é, conhecimentos e
soluções tecnológicas que serão utilizadas no processo de desenvolvimento de produtos, PDP. Somente as solu-
ções tecnológicas que forem consideradas estáveis e maduras deverão ser incorporadas nos projetos de novos
produtos. As soluções tecnológicas fornecidas ao PDP tanto podem ser desenvolvidas a partir de objetivos e
planos internos da P&D, como podem ser desenvolvidas a partir de demandas/solicitações do próprio PDP.
Essas atividades podem ser realizadas internamente à empresa e ou em parcerias, por exemplo, com instituições
de pesquisa e até mesmo de ensino. No caso deste livro, o enfoque é unicamente no Processo de Desenvolvi-
mento de Produtos.
O processo de Suprimentos, no sentido do fornecimento de matérias-primas e componentes para a empre-
sa, além de desempenhar o papel de abastecer com bens físicos, também proporciona informações técnicas e coopera
nas atividades de desenvolvimento. Os fornecedores podem se responsabilizar pelo desenvolvimento, total ou
em conjunto com a empresa cliente, dos projetos necessários para os itens a serem fornecidos. É o caso, por
exemplo, do chamado desenvolvimento conjunto (normalmente citado em inglês como co-design), uma forma de
desenvolvimento colaborativo que considera as vantagens do envolvimento o mais cedo possível dos fornece-
dores no projeto do item e até mesmo participando de equipes de projeto da empresa cliente.
Quando o processo de desenvolvimento de produto da empresa tem uma proximidade maior com os forne-
cedores, o fluxo de informações entre os dois processos torna-se mais complexo. Essa relação pode assumir dife-
rentes graus de interação em função do grau em que os fornecedores se responsabilizarem por atividades e partes
do desenvolvimento do projeto.
As informações de saída do PDP são entradas para o processo de Produção, que, ao final, produzirá os pro-
dutos em escala comercial. Porém, o PDP também deve receber informações da Produção, para realizar suas ati-
vidades, antecipando-se a problemas na fase de manufatura do produto. O PDP deverá ser informado e levar em
consideração as restrições e capacidades de produção existentes na empresa e as disponíveis no mercado de for-
necedores. Ou seja, deve incorporar, durante o desenvolvimento, a chamada “voz da fábrica” para assegurar a
manufaturabilidade do produto desenvolvido. A Produção também participa do PDP, realizando atividades
como elaboração de protótipos de produção, produção piloto, resolução de problemas para passagem da pro-
dução piloto para a produção em escala comercial (scale up), ações para melhoria da capabilidade do processo e
reduções de custo de processamento do produto.
A estrutura da logística de Distribuição da empresa, bem como os canais de distribuição do novo produto
no mercado, também deve ter seus requisitos incorporados durante o desenvolvimento — uma vez que são
14 PARTE 1 O Processo

clientes do PDP no que diz respeito, por exemplo, a armazenar, manusear e transportar o produto. No outro
sentido do fluxo de informações entre esses dois processos, caberá às equipes do PDP orientar a elaboração de
informações, instruções e manuais para a preservação da qualidade na distribuição do novo produto.
Em relação ao processo de Assistência Técnica, o PDP deverá orientá-lo sobre as falhas potenciais e pre-
pará-lo para os serviços a serem prestados ao novo produto. No sentido do fluxo de informações da Assistência
Técnica para o PDP, esse deverá ser informado sobre os requisitos desse cliente na fase de uso e manutenção do
produto, bem como dos problemas que o produto apresenta em campo, para as correções necessárias no projeto.
Os dados da Assistência Técnica também são uma importante fonte de informações para futuros projetos de de-
senvolvimento.

1.6 A importância da gestão do PDP


A demanda por mudanças nos produtos, e nas suas aplicações e usos, tem au-
São muitas as vantagens mentado muito intensamente, justificando uma preocupação maior com a eficiência
competitivas que se e a eficácia do desenvolvimento de produtos. E esse desempenho depende do geren-
obtém de um processo de
desenvolvimento bem
ciamento do PDP.
estruturado e gerenciado Já no início da década de 1990, gerentes seniores de grandes corporações japo-
nesas, européias e norte-americanas identificaram o desenvolvimento de produtos
como uma área de grandes oportunidades para elevar a competitividade das empresas e cujas capacidades neces-
sitavam ser incentivadas e fortalecidas.
Apesar da unanimidade sobre a importância do PDP, não são raros os casos de fracassos de desenvolvi-
mento de novos produtos. No início da década de 1990, já podiam ser identificadas grandes empresas multinacio-
nais com efetiva capacidade para desenvolver produtos, enquanto outras se debatiam com os elevados custos al-
cançados, com a demora no lançamento, com problemas de qualidade ou mesmo com a falta de mercado para o
produto desenvolvido.
O desenvolvimento deve buscar algo mais do que custo e desempenho técnico do produto. Também são
condições desejáveis para a competitividade: a qualidade do produto no atendimento aos diferentes requisitos
dos clientes; colocação do produto no mercado o mais rápido possível, para aproveitamento adequado da janela
de oportunidades, antecipando-se em relação à concorrência; e, ainda, a manufaturabilidade (facilidade de pro-
duzir e montar) do produto e a criação e o fortalecimento, a cada projeto, das capacitações requeridas para o de-
senvolvimento de produto no futuro.
A contribuição do PDP como fonte de vantagens competitivas para as empresas está sendo cada vez mais
enfatizada. Estima-se que uma parcela significativa, algo em torno de 85% dos custos do ciclo de vida de um
produto, é reflexo da fase de projeto, ou seja, fica determinada em função do que é definido no projeto (tecnolo-
gias básicas do produto e do processo, materiais, especificações etc.).
Estima-se que são possíveis reduções de mais de 50% no tempo de lançamento de um produto, quando os
problemas de projeto são identificados e resolvidos com antecedência, reduzindo o número de alterações poste-
riores e os tempos de manufatura e de resposta às necessidades do consumidor e, portanto, gerando competitivi-
dade. Além disso, é importante considerar e evitar o “efeito escala” do aumento do custo de alteração
(mudanças) no produto ao longo dos seus estágios de desenvolvimento (idéia, projeto, protótipo, produção e
lançamento): estima-se que o atraso na detecção e correção de problemas, à medida que se avança do projeto
para a produção e para o consumo, representa um aumento do custo de alteração (resolução dos problemas), que
cresce em progressão geométrica de razão 10 a cada fase.
Além da obtenção da qualidade de produto e de processo, o PDP tem forte influência sobre outros fatores
de vantagem competitiva, como custo, velocidade e confiabilidade de entrega e flexibilidade. A velocidade de
entrega pode ser beneficiada pelo projeto de produtos mais fáceis de produzir e de montar. A confiabilidade
de entrega é beneficiada pelo projeto de processos de fabricação dos produtos estáveis, mais fáceis de executar e
de controlar. A vantagem em flexibilidade pode ser favorecida pelo PDP que compartilha grande quantidade de
componentes e pelo projeto de processos, os quais buscam favorecer o compartilhamento dos equipamentos
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 15

de produção. O PDP também tem forte influência sobre a vantagem em custo, uma vez que o custo final do pro-
duto tem estreita ligação com o consumo e com o tipo de materiais utilizados na fabricação, que, por sua vez, são
dependentes do projeto do produto e do processo. Ao se introduzirem novos produtos antes da concorrência, po-
de-se tornar o produto um padrão no mercado, pioneiro na inovação e apto para responder rapidamente aos feed-
backs dos clientes, assegurando maiores margens de lucratividade.
O processo de desenvolvimento de produto basicamente tem seu desempenho avaliado por meio de indica-
dores associados à qualidade total do produto desenvolvido, aos custos e à produtividade desse processo e ao
tempo total de desenvolvimento, e de sua contribuição para a competitividade da empresa em termos de rentabi-
lidade, crescimento, fortalecimento da imagem e participação no mercado.
O modo como a empresa desenvolve produtos — ou seja, sua estratégia de produto e como ela organiza e
gerencia o desenvolvimento — é que determinará o desempenho do produto no mercado e a velocidade, efi-
ciência e qualidade do processo de desenvolvimento. Isto é, o desempenho do PDP depende de sua gestão (es-
tratégias, organização e gerenciamento).
Mas a gestão do PDP é bastante complexa em razão da natureza dinâmica des-
se processo, descrita no Tópico 1.1, à grande interação com as demais atividades e A gestão do processo de
funções da empresa e da cadeia de suprimentos, e à quantidade e diversidade das in- desenvolvimento de
produtos é bastante
formações de natureza econômica e tecnológica manipuladas durante o processo. complexa
As freqüentes mudanças nos requisitos dos clientes, nas tecnologias disponíveis e
nas regulamentações que se aplicam aos produtos também contribuem para elevar a
complexidade desse processo.
A natureza dinâmica do processo diz respeito ao próprio ciclo iterativo de Projetar-Construir-Testar-Oti-
mizar, presente nas atividades típicas de desenvolvimento, envolvendo constantes alterações e, também, intera-
ções entre as etapas.
Assim, do ponto de vista gerencial, representa um grande desafio lidar com as incertezas, mudanças e com-
plexidades, as quais dificultam, inclusive, a visualização do processo de forma sistêmica.
Um processo eficaz e eficiente de desenvolvimento de produtos não é algo fácil de conseguir. Muitas em-
presas podem ter sucessos eventuais com um ou outro produto, mas são poucas as que alcançam êxito por meio
de um processo de desenvolvimento eficiente de forma sustentada e conduzido de modo planejado e articulado
com as estratégias competitivas da empresa.
O que distingue as empresas com excelência em desenvolvimento de produtos
é o padrão de coerência e consistência em todo o processo de desenvolvimento, in- Qual o diferencial das
cluindo a estratégia, a estrutura organizacional, a sistematização das atividades, as empresas com excelência
em desenvolvimento de
habilidades técnicas, as abordagens para resolução de problemas, os mecanismos de produtos?
aprendizagem e o tipo de cultura dominante.
De modo geral, pode-se argumentar que a consistência nas diversas dimensões de desempenho do produto
desenvolvido (desempenho técnico, qualidade, custo, prazo de lançamento etc.) seria conseqüência da consis-
tência na organização e no gerenciamento do desenvolvimento do produto.
Acima de tudo, é necessário que se tenha uma adequada estratégia de desenvol-
vimento. Essa estratégia representa um caminho para se criar uma estrutura capaz Uma adequada estratégia
de reduzir problemas típicos, como a falta de envolvimento da alta administração de desenvolvimento...
nas decisões do desenvolvimento de produtos, especialmente nas suas primeiras
etapas, e a falta de sintonia entre o plano de negócios da empresa e os projetos em curso ou a serem iniciados. Por
causa desse descompasso, importantes aspectos de marketing e de estratégia tecnológica, por exemplo, tendem a
surgir apenas após os projetos estarem em andamento, o que torna seu gerenciamento uma tarefa mais complexa.
A estratégia de desenvolvimento também trata de traduzir os objetivos do negócio, geralmente mais am-
plos, em requisitos de caráter detalhados, tais como: tempos para introdução de novos produtos, custos de de-
senvolvimento, definição de capacidades e de mix produtivo. Essa estratégia compreenderia não apenas uma
visão de curto e médio prazos, relacionados à criação de novas gerações de produtos, mas, principalmente, a
16 PARTE 1 O Processo

identificação e o desenvolvimento das capacidades críticas para que a empresa possa continuar tendo um desen-
volvimento eficaz no futuro. Assim, a gestão estratégica do PDP segue a orientação estratégica da empresa e, ao
mesmo tempo, direciona as decisões em nível operacional do PDP. Já a gestão operacional do PDP ocupa-se do
planejamento e controle das atividades rotineiras de desenvolvimento, tais como: o mapeamento dos requisitos
dos clientes, dos requisitos do projeto, a definição das especificações do produto e dos materiais, a realização de
avaliações, construção dos protótipos, análises de custos e prazos etc.
Mas a estratégia de desenvolvimento não é suficiente para o desempenho do
...complementada por um processo, ela deve orientar e ser complementada e operacionalizada por um amplo
adequado conjunto de conjunto de abordagens e fatores gerenciais, a serem comentados nos tópicos se-
abordagens e fatores
gerenciais
guintes deste capítulo.
Resumidamente, as empresas com excelência em desenvolvimento de pro-
dutos possuem um modelo para o PDP, o qual apresenta forte consistência em seus elementos e possuem uma
gestão estratégica e operacional do desenvolvimento de projetos devidamente articuladas.

1.7 Abordagens para gestão do PDP


A evolução da visão sobre o modo de gerenciamento do processo de desenvolvimento de produto está rela-
cionada à evolução do modo de gestão geral adotado pelas empresas.
Após a Primeira Guerra Mundial, os sistemas de produção industrial evoluíram da produção artesanal, ca-
racterizada por elevados custos de produção e ausência de consistência e confiabilidade nos produtos e pro-
cessos, para um novo sistema de produção em massa, baseado nas técnicas de Henry Ford.
Os princípios da administração científica, de divisão de tarefas, busca pela ma-
Como o PDP era visto neira ótima e das pessoas certas, bem como a estruturação funcional das organiza-
antes: Desenvolvimento ções, “moldaram” o surgimento da função de desenvolvimento de produtos nas
de Produtos Seqüencial
organizações. Como resultado, viu-se a criação do que hoje se chama Engenharia
Tradicional ou Desenvolvimento de Produtos Seqüencial, no qual as tarefas re-
1
lacionadas ao projeto eram atribuídas a um número exagerado de áreas funcionais excessivamente especializadas e
constituídas por técnicos com domínio específico na área funcional.
Esse modelo de desenvolvimento é chamado de seqüencial porque as informações sobre o produto eram
definidas em uma ordem lógica de uma área funcional para outra — primeiro Marketing, depois Design, Enge-
nharia, Produção etc. O projeto “caminhava” entre elas, e cada uma se limitava a receber uma determinada in-
formação, realizar o trabalho e produzir o resultado que dela se esperava. Não havia, portanto, uma interação
forte entre elas durante e depois da realização das atividades. As atividades e procedimentos para o gerenciamen-
to eram informais, baseados na experiência das pessoas e diferiam entre as áreas funcionais, que criavam culturas
e padrões de trabalho próprios.
No fundo, era como se houvesse uma premissa de que a excelência em desen-
Características do volvimento de produto dependesse única e exclusivamente da excelência em cada
Desenvolvimento de uma das áreas de especialização.
Produtos Seqüencial Essa visão tradicional de desenvolvimento de produto apresenta as seguintes
características:

n As áreas de P&D e de Desenvolvimento de Produtos (DP) tendem a ser mais isoladas do restante da em-
presa e não integradas à estratégia geral do negócio. Apresentam uma cultura, linguagem e compreen-
são dos problemas próprios.
n Existem barreiras organizacionais e de comunicação significativas entre essas áreas e o restante da empresa.

1
Por exemplo, na indústria automobilística, era comum encontrar: marketing, gerência, design, engenharia avançada, engenharia deta-
lhada, engenharia de processo de fabricação, prototipagem e assim por diante, sendo que, ainda, havia segmentações dentro delas. Nas
áreas de engenharia, havia, por exemplo: Engenharia de Chassis, Motor, entre outras. (Fonte: WOMACK, JONES e ROSS, 1992.)
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 17

n A alta administração participa pouco das principais definições das metas de P&D e do DP.
n Predomina a hierarquia e a linearidade no fluxo de informações e das atividades entre P&D, Engenharia
de Produto e de Processo, Produção, Vendas, Assistência Técnica etc., que são vistas como seqüenciais e
sem que uma interaja com as demais.
n Os fornecedores somente são envolvidos nas fases finais do desenvolvimento, com a empresa procu-
rando ser excessivamente auto-suficiente.
n As atividades de P&D e de DP são consideradas como um conjunto de atividades de risco e, portanto, de
difícil mensuração e controle. Assim na área havia uma forte resistência a controles e à contabilidade de
custos e análise do retorno de investimentos.
n Os profissionais da área eram especializados, com a promoção na carreira sendo essencialmente vertical
e sem mobilidade horizontal para outras áreas, valorizando o aprofundamento e isolamento do conheci-
mento.

Como resultado, havia uma grande dificuldade de compreensão mútua entre as


áreas, e a coordenação do projeto era prejudicada. Quando surgiam problemas, Deficiências do
eram comuns os embates entre áreas funcionais, os quais aumentavam a turbulência Desenvolvimento de
Produtos Seqüencial
e não contribuíam para a solução. Nessa época, começou a surgir o papel do gerente
de projeto, que deveria se preocupar com o projeto como um todo e servir como fa-
cilitador na transição do projeto pelas áreas. Mas, na maioria dos casos, seu poder e influência eram limitados e
bem menores que os gerentes funcionais, os quais podiam tomar a decisão final, muitas vezes priorizando a oti-
mização dos esforços e aspectos relacionados à sua função.
As barreiras culturais aprofundavam esse problema. Os valores, procedimentos e padrões de cada área difi-
cultavam a integração, criando diferentes ambientes na empresa. Assim, os colaboradores não tinham conheci-
mento de como o processo de desenvolvimento ocorria e possuíam pouca informação do andamento do projeto.
Eles tinham acesso somente à atividade sob sua responsabilidade, em alguns casos sem saber o porquê dos
prazos, com poucas informações sobre o projeto e sem nem mesmo conhecimento de como aqueles resultados
seriam utilizados.
A superespecialização das áreas contribuía para que as decisões de projeto fossem tomadas de um ponto de
vista restrito a um domínio de conhecimento da área. Por exemplo, um pesquisador norte-americano relata ter
encontrado, no início da década de 1990, um projetista de uma montadora que, apesar de possuir vários anos de
experiência no projeto de travas de automóveis, não tinha contato com o engenheiro responsável pelo desenvol-
2
vimento do processo de fabricação das mesmas travas. Trata-se de uma situação claramente inadequada, pois a
troca de experiências seria fundamental para que o projetista tivesse um conhecimento melhor do projeto e pu-
desse projetar peças mais fáceis de serem fabricadas.
Outra característica desse modelo é o fato de os departamentos de engenharia serem totalmente auto-sufi-
cientes. O projeto era realizado quase inteiramente por profissionais da mesma empresa, incluindo as peças que
seriam produzidas por fornecedores externos. Isso prejudicava a manufaturabilidade do produto, o tempo de de-
senvolvimento e a atualização tecnológica. Por exemplo, enquanto empresas japonesas utilizando abordagens
mais recentes de desenvolvimento empregavam em média 485 pessoas em uma equipe de projeto (as mais evoluídas,
333), as montadoras norte-americanas com desenvolvimento de produtos clássico empregavam 900, e havia
montadoras alemãs que alocavam em média 1.500 engenheiros. Não que o trabalho fosse menor; a questão é
que, no primeiro caso, há uma participação efetiva no projeto por parte das empresas fornecedoras e parceiras.
No início da produção em massa, essas deficiências não eram tão prejudiciais como agora, pois o ciclo de
vida dos produtos era maior, o produto ficava mais tempo no mercado e a concorrência era menor. À medida que
o padrão competitivo avançou no sentido de exigir vários projetos concorrentes, com qualidade, tempo e custo,
essas deficiências foram logo notadas. Assim, ao longo dos anos, diversos aperfeiçoamentos foram incorporados

2
WOMACK, JONES e ROSS, 1992.
18 PARTE 1 O Processo

nessa abordagem, buscando melhorar sua eficiência, mas sempre mantendo a mesma visão de um Desenvolvi-
mento de Produtos Seqüencial.
O primeiro passo nessa solução foi a busca de uma excelência funcional, ou
A abordagem das seja, da excelência dentro de cada departamento, porém ainda sem uma excelência
Metodologias de Projeto entre as funções. Um marco importante para o desenvolvimento de produtos, den-
tro dessa visão, foi a proposição e a difusão das chamadas Metodologias de Projeto.
A proposta era encontrar a seqüência de etapas e atividades considerada mais racional para se desenvolver um
produto.
Nessa abordagem, o modo de gerenciamento é o funcional, em que cada departamento ou setor da empresa
tem sua especialidade e realiza as atividades de desenvolvimento que lhe são pertinentes e as transferem a outro
departamento.
Não há a visão de um processo que integre as diversas atividades, do conjunto de áreas funcionais, que são ne-
cessárias para o desenvolvimento de um produto. Não há uma visão compartilhada do ciclo de vida do produto.
Mas a complexidade e o dinamismo dos ambientes econômico, tecnológico,
A abordagem da social e de regulamentação foram aumentando ao longo dos anos, com destaque
Engenharia Simultânea para o aumento da diversidade de produtos, maior valorização do atendimento a
prazos, maior pressão de custos, maior regulamentação socioambiental, aceleração
da taxa de inovação tecnológica, clientes mais exigentes etc.
A intensificação dessas exigências, no final dos anos 1980, levou ao surgimento de diversas propostas de
mudanças maiores na visão de como desenvolver produtos, as quais resultaram em uma transformação significa-
tiva na gestão do PDP em um período curto de espaço de tempo. Essa abordagem tornou-se amplamente co-
3
nhecida como o movimento da Engenharia Simultânea .
Foram muitas as inovações advindas desse movimento. Uma das mais significativas diz respeito à estrutura
organizacional. Ele deu início à utilização de times multifuncionais de projeto, encabeçados por um gerente de
projeto peso pesado, isto é, um gerente com poderes superiores ao dos gerentes funcionais. Era a descoberta das
vantagens da Estrutura Matricial Forte. Essa abordagem ampliou a integração, propondo a participação de
clientes e fornecedores no processo de desenvolvimento e, principalmente, mostrando as vantagens da reali-
zação de atividades simultâneas. As empresas e teóricos da época demonstraram que esse tipo de estratégia, só
possível com uma integração maior entre as áreas funcionais, promovia a diminuição do tempo de desenvolvi-
mento, de custo e, ainda, aumentava a qualidade.
Esse movimento ajudou também a difundir a importância de utilizar técnicas sistemáticas de projeto para
aumentar a produtividade do trabalho da engenharia e diminuir erros. Foram os primeiros autores a colecionar
essas técnicas, classificá-las, geralmente em filosofias, técnicas e métodos, e a tentar entender a relação entre
elas. Foi nesse momento que muitas das técnicas que serão apresentadas no decorrer deste livro (tais como: o
Quality Function Deployment — QFD, Desdobramento da Função Qualidade —; a matriz de seleção de Pugh;
a Failure Modes and Effects Analysis — FMEA, Análise dos Modos de Falha e Seus Efeitos —; e a Análise do
Valor) foram sistematizadas e propostas para trabalhar conjuntamente.
A abordagem da Engenharia Simultânea foi muito difundida, e saltos significa-
A abordagem do Funil de tivos de desempenho foram obtidos, mas outras melhorias importantes viriam logo
Desenvolvimento em seguida, na metade dos anos 1990. Sem dúvida, uma das mais importantes foi a
adoção da abordagem de processo de negócio. Até então, mesmo os teóricos da
Engenharia Simultânea consideravam apenas as áreas funcionais, cujas atividades eram integradas e coorde-
nadas por meio dos trabalhos dos times, gerentes de projeto e as técnicas.
Com a adoção da visão por processos, a integração entre as atividades ficou ainda mais evidente, pois os
profissionais de DP começaram a entender a relação entre atividades antes consideradas muito distantes, tais

3
Outra abordagem famosa nessa época foi chamada de Total Design, originada para se contrapor à abordagem tradicional por esses au-
tores, que foi denominada Partial Design, ou projeto quebrado em pedaços, das estruturas funcionais. Aqui, esses foram considerados
dentro do rótulo da Engenharia Simultânea por motivo de simplificação.
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 19

como: a criação da tecnologia e seu uso, a relação entre a retirada do produto do mercado e a obtenção de idéias
para os novos produtos e assim por diante.
Outra grande contribuição foi a descoberta da importância do alinhamento entre as atividades do PDP e o
Planejamento Estratégico da Empresa, considerando a estratégia mercadológica, a estratégia de produtos e a es-
tratégia tecnológica.
Ambas as inovações foram consolidadas na proposta da Estrutura Estratégica para Desenvolvimento de
Produtos, conhecida como Funil de Desenvolvimento, de Clark & Whelwright. Os teóricos dessa abordagem
passaram a estudar o desenvolvimento de produtos como um processo, e propuseram um modelo de processo
que integrava o planejamento estratégico de mercado e negócio com as atividades de desenvolvimento de pro-
duto. O PDP começava pelo planejamento de um conjunto de projetos (o portfólio de produtos) e, por meio de um
processo de negócio disciplinado, com fases e avaliações, somente os produtos com maior probabilidade de su-
cesso chegavam ao mercado, garantindo eficácia e atendimento às metas da estratégia competitiva da empresa.
Outro aspecto dessa ligação com a estratégia é que ela permitiu uma forma sistemática de criar novos pro-
dutos que compartilhem componentes-chave, mas cujas características e funções assegurem o atendimento dife-
renciado de um segmento bem específico de clientes. Isso permite atender melhor os clientes, criando soluções
diferenciadas, dentro de um custo de manufatura e desenvolvimento viável.
Portanto, a necessidade de integração e de coordenação das atividades de desenvolvimento levou à visão de
um processo de negócio, o Processo de Desenvolvimento de Produtos, com ênfase para a sua estruturação e
gestão. Consolidou-se, assim, o conceito de gestão do PDP da forma como pensamos atualmente — como um
dos processos essenciais para o desempenho empresarial.
Embora as primeiras definições de desenvolvimento de produtos como um
processo tenham surgido entre o começo e a metade dos anos 1990, somente no fi- A abordagem
nal dessa década é que elas passaram a ser bem difundidos nas empresas de exce- Stage-Gates
lência em desenvolvimento de produtos. O legado do desenvolvimento de produtos
seqüencial ainda era muito forte. Durante esse tempo, porém, a teoria de desenvolvimento de produtos passou a
adotar rapidamente a visão por processos, e, com isso, várias abordagens para desenvolvimento de produtos sur-
giram, descrevendo-o sistematicamente e mostrando a relação entre técnicas e métodos anteriormente conhe-
cidos. Com pequenas variações, pode-se considerar que elas adotavam os mesmos princípios citados até o
4
momento. A principal diferença era a quantidade de técnicas e áreas do conhecimento consideradas no processo.
Uma delas, porém, merece ser citada, porque contribuiu para identificar a importância e mostrar como im-
plementar uma disciplina sistemática de avaliação e transição de fases, integrada com o processo decisório de
planejamento estratégico — a abordagem proposta por Cooper e denominada, em inglês, de Stage-Gates. O foco
principal do seu modelo era um processo sistemático de decisão, que garantia não apenas o desempenho e a qua-
lidade do desenvolvimento, mas permitia que essa escolha levasse em consideração o andamento de todos os
projetos e as mudanças no ambiente. Essa integração fortalece ainda mais o impacto do desenvolvimento na es-
tratégia de produtos.
As abordagens da Engenharia Simultânea, Funil e Stage-Gates se desenvol-
veram quase simultaneamente, no período de tempo entre o final dos anos 1980 e fi- A era do Desenvolvimento
nal dos anos 1990, comungam várias características e influenciaram uma às outras. Integrado do Produto
Juntas, podem ser rotuladas como a era do Desenvolvimento Integrado do Pro-
duto, como uma evolução da era inicial que poderia ser denominada como era do Desenvolvimento Seqüencial.
As abordagens do Desenvolvimento Integrado do Produto apresentam as seguintes características:

n O desenvolvimento de produtos é visto como um processo.


n A P&D e o DP são inseridos na estratégia geral da empresa e de sua cultura.
n O uso de projetos plataforma e modularizados para criar grande variedade de produtos, atendendo aos
diferentes segmentos, com baixo investimento

4
Basta ver as abordagens de EPPINGER, BAXTER e vários outros autores.
20 PARTE 1 O Processo

n O desenvolvimento de tecnologias e de produtos é visto como fundamental para a estratégia e a capaci-


dade competitiva da empresa, e faz parte das preocupações maiores da alta administração.
n Há simultaneidade e superposição de informações e de atividades.
n Há maior capacidade e intensidade de comunicação entre os setores e departamentos, possibilitando
formas de trabalho em grupo.
n Os projetos são conduzidos por meio de times de desenvolvimento multifuncionais.
n Os fornecedores são envolvidos desde o início do desenvolvimento e há mais facilidade de fazer alianças
estratégicas para o projeto.
n Os projetos são constantemente submetidos à revisão e avaliação técnica e de custos, bem como de seu
alinhamento com as estratégias de marketing e de produto.
n Os recursos aplicados no DP devem ser justificados pelas necessidades e são controlados e avaliados
constantemente.
n Os profissionais tendem a ser mais generalistas; na carreira, há promoção tanto vertical quanto hori-
zontal e há muita mobilidade de pessoal internamente para áreas externas, para outras áreas da organi-
zação.
n O treinamento e a seleção de pessoal reforçam os atributos mais gerais, como a capacidade de trabalhar
em grupo. A visão ampla é tão importante quanto a especialidade ou a competência técnica.
n O estímulo à participação das áreas envolvidas ocorre em todas as fases dos projetos de desenvolvi-
mento, mas, particularmente no início, ela é fundamental para que haja consenso sobre os parâmetros
básicos dos projetos, evitando divergências posteriores. Desse modo, tomadas as decisões básicas de
modo consensual, o projeto pode transcorrer de forma mais fluida e sem divergências

A ênfase em equipes de desenvolvimento multifuncionais com forte liderança e


Vantagens das abordagens com participação ativa de especialistas de diversas áreas funcionais resultou em um
de Desenvolvimento salto significativo na produtividade do desenvolvimento, na qualidade dos produtos
Integrado de Produtos
e na rapidez das respostas às exigências dos consumidores (diminuição do lead time).
Algumas vantagens competitivas obtidas são a maior capacidade de projetar e
produzir uma maior variedade de produtos, atingindo diferentes segmentos do mercado, e a obtenção de uma
maior taxa de renovação de produtos, mantendo-os mais atualizados do que a concorrência.
Um dos desafios para a excelência em desenvolvimento de produtos é a efetiva
Entre os atuais desafios: a utilização das melhores práticas consolidadas na era do Desenvolvimento Integrado
efetiva implementação da de Produtos. Embora esses conceitos tenham quase uma década, ainda é raro encon-
abordagem de
Desenvolvimento
trar empresas com altos níveis de evolução de disciplina de processo em todos os as-
Integrado de Produtos... pectos citados, isto é, capazes de colocarem as melhores práticas em funcionamento.
O que se vê é uma pequena parte implantada completamente, enquanto outras
estão parcialmente presentes, além da existência de práticas e características importantes ainda não utilizadas.
Um dos desafios é a complexidade em gerenciar tais mudanças, algo que as abordagens da era do Desenvolvi-
mento Integrado de Produtos não exploram de maneira efetiva. Trata-se de uma fronteira que está sendo des-
bravada pelos modelos de desenvolvimento de produtos mais recentes.
Atualmente, é cada vez mais comum as empresas atuarem na forma de con-
...e a complexidade do sórcio e de desenvolvimento de um conjunto de projetos ao mesmo tempo (multi-
ambiente do projetos), os quais são muitas vezes desenvolvidos e manufaturados em unidades de
desenvolvimento continua
aumentando: o
produção diferentes (multiplantas) espalhadas pelo mundo, conforme é usual en-
desenvolvimento de contrar nas empresas transnacionais.
multiprojetos em Os desafios dessa “globalização” dos projetos, aliados às estratégias das em-
multiplantas presas transnacionais e aos novos recursos de comunicação, fazem com que o desen-
volvimento aconteça em uma rede complexa de empresas e cadeias de produção.
Nesse caso, a eficácia e a eficiência do desenvolvimento devem ser buscadas de forma sistêmica, em todo o con-
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 21

junto de projetos e na rede de empresas. Não basta ser eficiente em um projeto de desenvolvimento isolado; o
que importa é o desempenho do conjunto de projetos.
Portanto, os desafios de integração, comunicação e compatibilidade das decisões será ainda maior nas pró-
ximas décadas. Os projetos de desenvolvimento de produtos tenderam a ser maiores e mais complexos, uma vez
que o desenvolvimento envolve um número maior, mais diversificado e disperso de atores participantes.
Nesse contexto, é possível identificar abordagens recentes que têm proposto
mudanças significativas em comparação com as da era do Desenvolvimento Inte- Novas abordagens
grado de Produtos. Elas são mais recentes e, portanto, ainda faltam pesquisas siste- para o PDP
máticas que permitam diferenciá-las claramente das anteriores. Arriscaremos tecer
algumas considerações sobre elas, as quais, no momento, são as novas fronteiras de estudo do PDP e, por isso,
não estão tão consolidadas quanto as práticas das abordagens das eras anteriores. Para efeito de classificação, elas
serão agrupadas sob o rótulo de Abordagens Recentes ou, simplesmente, Novas Abordagens para o PDP.
Uma das abordagens muito citadas pela literatura é a do Desenvolvimento
Lean. À primeira vista, não parece se diferenciar muito do Desenvolvimento Inte- O desenvolvimento Lean
grado de Produtos. Inclui as mesmas práticas. Uma das contribuições de destaque
está na proposta de uma visão mais orgânica do processo, que deve ser atingida por meio da máxima simplifi-
cação e diminuição da formalização do processo (pois são atividades que não agregam valor) e de uma valori-
zação dos trabalhos dos times, com um foco nas atividades de prototipagem e testes. A idéia é valorizar ao
máximo a experimentação e a aprendizagem. O gerente de projeto não é visto apenas como um coordenador e
motivador, ele é também um dos orientados, no sentido acadêmico do termo, que orienta (tutoria) o processo de
aprendizagem dos engenheiros e técnicos sob sua supervisão, em busca de uma inovação constante. Nesse
ponto, tal teoria “se toca” com a valorização da aprendizagem organizacional e gestão do conhecimento. Nas
abordagens de Desenvolvimento Integrado, esse aspecto do trabalho em times não era valorizado.
A segunda contribuição é a idéia de retardar ao máximo as decisões de detalhes muito específicos, como to-
lerâncias, os quais serão otimizados nas etapas finais do projeto. Prega-se que o tempo despendido antecipada-
mente nesses detalhamentos seja investido em busca de alternativas de soluções e entendimento do problema de
projeto.
Essa é outra abordagem fruto da aplicação de conceitos criados para a manufa-
tura e que também prega as mesmas características que as abordagens da era do De- A abordagem do Design
senvolvimento Integrado de Produtos. A diferença fundamental é o foco na For Six Sigma (DFSS)
integração de necessidades dos clientes, requisitos de produto, especificações e tole-
râncias por meio do uso de otimização, por meio de ferramentas estatísticas e de simulação.
No processo de desenvolvimento de produtos, os teóricos dessa abordagem descrevem em detalhes as ativi-
dades de desdobramento dos requisitos em especificações e tolerância. Trata-se de uma abordagem que prega a
aplicação intensa de técnicas estatísticas, instrumentação digital de ensaios e simulação computacional de pro-
dutos. A grande incógnita é que esse tipo de atividade não é simples e nem mesmo barata.
Nas abordagens de Desenvolvimento Integrado de Produtos não havia uma
ênfase na implantação dos processos e menos ainda na melhoria contínua do Pro- A abordagem dos modelos
cesso de Desenvolvimento de Produtos. Trata-se de modelos estáticos que demons- de maturidade
tram o nível mais avançado de prática. O problema é: O que fazer para chegar até
aquele nível?
Existem novas abordagens para desenvolvimento de produtos que enfatizam esse aspecto. A mais conhe-
cida é o Capability Maturity Model Integration ou CMMI, proposto pela Software Engineering Institute (SEI).
Trata-se de um modelo para sistematização do desenvolvimento que, além das atividades e fases, divididas em
áreas de conhecimento, fornece níveis de maturidade em termos de práticas e indicadores capazes de medir esses
níveis. É uma ótima inovação em abordagens para melhorar o Desenvolvimento de Produto, pois parte-se do
princípio que nem todas as empresas precisam estar no nível mais alto de excelência, inclusive porque perma-
necer em um nível maior significa onerar os produtos com custos para melhoria e sistematização do processo, os
quais podem não se reverter em benefícios.
22 PARTE 1 O Processo

Com os indicadores e níveis, os responsáveis pelo desenvolvimento podem facilmente identificar o nível de
prática da empresa e planejar um nível adequado a ser atingido. Aí, pode-se focar os esforços nas práticas que
contribuam para atingir aquele nível.
Correremos o risco de citar aqui uma abordagem que, embora possa ser consi-
A abordagem do derada gerencial, tem suas origens no domínio da tecnologia de informação: Gestão
Gerenciamento do Ciclo do Ciclo de Vida de Produtos. Como decorrência da evolução dos Sistemas Inte-
de Vida de Produtos
grados de Gestão Empresarial (ERP – Enterprise Resource Planing), vêm sendo
criadas soluções corporativas complexas e sofisticadas que permitem transformar
em realidade o sonho de qualquer gerente de projeto: navegar no conjunto complexo de dados e documentos e
se comunicar com todos os envolvidos no projeto.
Essas ferramentas, denominadas Sistemas para Gestão do Ciclo de Vida de Produtos, poderão também ser
integradas com as ferramentas de trabalho (por exemplo, as ferramentas CAD 3D, os gerenciadores de docu-
mentos e os sistemas de gestão de projetos).
A contribuição dessa abordagem é uma integração de dados e atividades muito mais elevada do que se podia
pensar na era do Desenvolvimento Integrado de Produtos. Afinal, a integração que se buscava entre as áreas fun-
cionais mais ligadas à engenharia e dentro de um mesmo projeto poderá evoluir para uma integração entre pro-
jetos distintos e com interações em tempo real com áreas da manufatura e de finanças. Estamos falando de
funcionalidades, tais como: gerenciamento integrado de multiprojetos; desenvolvimento e gerenciamento si-
multâneo de dois produtos que compartilham uma mesma arquitetura com os sistemas, apoiando coordenação
dessas atividades; cálculos em tempo real dos investimentos realizados no portfólio, medições em tempo real dos
indicadores de desempenho do projeto e muitas outras inovações.
O gerenciamento integrado de multiprojetos, por exemplo, permite maximizar as chances de a empresa
obter um fluxo de novos produtos que cubra diversos segmentos de mercado e faça o melhor uso possível dos in-
vestimentos em tecnologia. Essa visão se aplica a muitas empresas que têm mais de um produto e desejam ex-
pandir o número de novos produtos de forma rápida e eficiente.
Outra grande vantagem dessa abordagem será facilitar o equilíbrio entre o que é ótimo para um projeto in-
dividual e o que é ótimo para a empresa como um todo, em termos de especificações, custos e prazos. Essa visão
sistêmica de multiprojetos se ajusta mais à realidade atual do que o foco na eficiência de projetos individuais.
Assim, o conjunto dos projetos poderá ser coordenado de forma mais sistemática e disciplinada, com uma velo-
cidade maior na tomada de decisões. A Toyota, por exemplo, é reconhecida por criar famílias de produtos bem
integrados que compartilham conceitos de projetos, componentes-chave e tecnologias básicas.
Resumindo, as características que têm sido propostas pelas abordagens mais
Características das novas recentes para o desenvolvimento de produtos são:
abordagens para o
desenvolvimento
n Simplificar a formalização por meio de uma disciplina mais avançada de tra-
de produtos
balho em equipe e utilização de ferramentas computacionais sofisticadas.
n Ênfase na aprendizagem e busca de soluções inovadoras, com ações como:
• aumento do investimento de tempo em atividades de avaliação e proposição de novas soluções;
• uso intenso de técnicas estatísticas, instrumentação e modelos computacionais, de maneira sistemá-
tica no processo de desenvolvimento de produtos — tanto para entender os parâmetros físicos envol-
vidos na função executada como para otimizar o desempenho do produto; e
• foco na gestão do conhecimento.
n Adoção do conceito de níveis de maturidade para garantir êxito na implantação das abordagens como
para garantir sua melhoria contínua.
n Introdução do conceito de gerenciamento do ciclo de vida de produtos, ampliando o escopo do pro-
cesso, e fortalecendo a integração interprojetos.

A Tabela 1.1 apresenta uma síntese dessas eras, abordagens e suas características.
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 23

Tabela 1.1 Eras, Abordagens e Suas Características

(continua)
24 PARTE 1 O Processo

Tabela 1.1 Eras, Abordagens e Suas Características (continuação)


CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 25

A análise de como se encontra e como deveria ser a gestão do PDP de uma em-
presa deve considerar um contexto amplo, o qual inclui o ambiente competitivo em Qual a abordagem mais
que ela está inserida e suas demandas, a capacitação e a organização interna da em- adequada para a empresa?
presa e o desempenho do processo. Ou seja, o desempenho no desenvolvimento,
um importante contribuinte para a competitividade da empresa, é determinado pela estratégia de produto da
empresa e por suas capacidades técnica e gerencial e, ainda, pela organização no processo como um todo. E esses
fatores influenciam uns aos outros.
A abordagem para organização do PDP (por exemplo, funcional, integrado, desenvolvimento integrado de
multiprojetos etc.) mais adequada à empresa dependerá dessa análise.
O relacionamento entre as capacidades da empresa e seu ambiente competitivo é dinâmico. A incerteza e a
diversidade do ambiente de mercado, por exemplo, podem mudar o papel do desenvolvimento de produtos na
empresa. Para manterem e melhorarem seu desempenho e competitividade, as empresas devem, de forma dinâ-
mica, adaptar suas formas de organização e de gerenciamento do desenvolvimento para modelos mais ade-
quados ao ambiente competitivo e de mercado.
A empresa, e as atividades do PDP, devem se adequar ao status estático/dinâmico das inovações no setor in-
dustrial em que está inserida, ou seja, caso, no setor, as inovações sejam raras (estático) ou bastante freqüentes
(dinâmico). Culturas e práticas adequadas para empresas de um setor estático não funcionarão bem em um setor
dinâmico e vice-versa.
Os produtos também diferem quanto à complexidade de sua estrutura interna e quanto à complexidade da
interface usuário-produto. Para cada tipo de produto, as questões críticas para a gestão do desenvolvimento de-
penderiam do grau dessas complexidades.
Apesar de uma aparente vantagem superior, por exemplo, do desenvolvimento integrado em relação ao de-
senvolvimento funcional, pode-se dizer que não existe uma única melhor abordagem para todas as empresas e
ela depende do contexto. O que funciona bem para determinada empresa e produto não necessariamente funcio-
nará bem para outra.
Assim, a abordagem mais adequada à empresa dependerá da análise do ambiente competitivo, das capacita-
ções existentes, do desempenho do PDP, da complexidade do produto e do status estático/dinâmico das inovações
no setor.
A Associação Americana de Gestão do Desenvolvimento de Produto (PDMA, Product Development Mana-
gement Association) procura identificar, nos Estados Unidos, os modelos e as práticas de gestão mais comumente
presentes nas empresas com sucesso no desenvolvimento de produtos. E isso é feito por meio de pesquisas de
5
campo com levantamento de dados nas empresas, que são atualizadas a cada 5 anos. Investigando a evolução das
práticas e do desempenho ao longo dos anos, e quais as suas particularidades nos diferentes setores industriais, a
Associação afirma que, sem a manutenção de processos de desenvolvimento freqüentemente atualizados, diante das
necessidades do ambiente econômico e tecnológico, as empresas sofrem uma crescente desvantagem competitiva.
Tem sido crescente a preocupação das empresas com seus modelos de desenvolvimento e de gestão de pro-
jetos, além da própria avaliação do nível de maturidade em que esses modelos de gestão se encontram (veja a
Parte 3 deste livro).
A estratégia competitiva da empresa direciona a estratégia de desenvolvimento de novos produtos (veja o
Capítulo 4) que, por sua vez, influencia os modelos de gestão e as práticas aplicadas
no PDP. O modelo de
Não é possível pensar o PDP e sua gestão como um processo isolado da empre- sistematização do PDP
sa. As atividades nele realizadas dependem de diversas áreas e processos da empresa apresentado neste livro
pode ser utilizado em
e são influenciadas por suas escolhas estratégicas e pelo seu ambiente competitivo.
qualquer das abordagens
No Capítulo 16, discute-se especificamente essa questão. aqui mencionadas.

5
Veja, por exemplo: GRIFFIN, A. “PDMA research on new product development practices: updating trends and benchmarking best
practices.” Journal of Product Innovation Management, Manchester, v. 14, p. 429-458, 1997.
26 PARTE 1 O Processo

1.8 Arranjos organizacionais para o PDP


Para realizarem o desenvolvimento de produtos de forma efetiva, as empresas precisam organizar esse pro-
cesso e suas equipes eficientemente. Quando, no início do século XX, os primeiros automóveis foram proje-
tados, como na Ford, por exemplo, a organização do desenvolvimento não era uma questão crucial. Mas o alto
nível de integração funcional existente naquela época foi se reduzindo com o aumento da diferenciação6 e da es-
pecialização departamental nas empresas, e os desafios organizacionais tornaram-se vitais.
A organização das atividades de desenvolvimento de produto se refere à forma como os indivíduos que
estão trabalhando estão ligados, individualmente ou em grupos, seja formal ou informalmente. As maneiras mais
tradicionais de realizar essa ligação organizacional ocorrem por meio do alinhamento de funções ou de projetos,
ou ambos.
Uma função, no contexto organizacional, é uma área de responsabilidade que usualmente envolve alto grau
de especialização de conhecimentos, em termos de formação e experiência. As funções clássicas envolvidas em
um PDP são: Marketing, Engenharia e Manufatura. É comum existirem subdivisões dessas funções clássicas,
tais como: Estratégia de Produto, Engenharia de Produto, Engenharia Industrial, entre outras.
Mesmo estando ligados a uma função pela sua especialização, os indivíduos também podem estar vincu-
lados a um projeto específico, aplicando, nesse contexto, o seu conhecimento.
Assim, pode-se identificar duas formas clássicas de organização do PDP: a estrutura funcional e a estrutura
autônoma ou por projeto. Na estrutura funcional, a ligação entre os indivíduos acontece primeiro entre aqueles
que realizam funções similares. Na estrutura por projeto, essa ligação acontece preferencialmente entre aqueles que
estão trabalhando em um mesmo projeto. As figuras 1.5 e 1.6 ilustram esses dois tipos de estruturas no PDP.

Figura 1.5 Estrutura funcional.

Figura 1.6 Estrutura por projeto.

6
Diferenciação pode ser entendida como o fenômeno oposto ao da integração. Uma organização cresce e necessita se diferenciar por
meio de departamentos, funções, filiais, passar responsabilidades para fornecedores etc. Assim, à medida que ela se diferencia, a inte-
gração tende a ser mais fraca, e a empresa cria mecanismos organizacionais para compensar ou recompor a integração. Esse paradoxo
da integração e diferenciação é uma questão clássica da teoria das organizações e brilhantemente tratada por Lawrence & Lorsch
(1967). LAWRENCE, P. R.; LORSCH, J. W. “Differentiation and integration in complex organizations.” Administrative Science Quar-
tely, v. 12, n. 1, p. 1-47, 1967.
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 27

Essas duas formas não são efetivamente distintas quando observadas na prática, principalmente porque in-
divíduos de diferentes funções podem estar simultaneamente ligados a sua função especializada e contribuindo
em um ou mais projetos. Uma estrutura funcional pode conter indivíduos que participam de projetos especí-
ficos. Entretanto, a ligação organizacional forte é baseada na função, tanto pela relação hierárquica quanto pela
alocação física. Cada área funcional tem seu próprio espaço físico, seu próprio orçamento, e um gerente cuja
origem normalmente é da própria unidade. Por outro lado, os indivíduos de uma estruturação por projeto re-
portam ao gerente do projeto e não ao responsável pela área funcional de sua origem, e, normalmente, eles com-
partilham espaço físico relacionado ao projeto, mesmo que também façam parte de um departamento funcional
específico. Uma organização tipicamente por projeto pode ser encontrada nos casos de empresas nascentes que
estão desenvolvendo seus primeiros produtos, quando o próprio presidente assume o papel de líder. Nos casos
de empresas já constituídas, o exemplo mais comum é quando se forma um Tiger Team com recursos dedicados
exclusivamente a um projeto específico de vital importância para a empresa. Como esses times ficam dedicados a um
projeto, os membros, com freqüência, mudam a cada projeto e ficam praticamente isolados das outras atividades do
PDP da empresa, surgindo, então, a questão de como compartilhar o aprendizado de um projeto para outro.
Por muito tempo, os projetos de desenvolvimento foram realizados por meio de um desses dois tipos de es-
trutura. Entretanto, principalmente por causa do aumento da complexidade e dos desafios da integração de tec-
nologias, surgiu um tipo de organização híbrida que apresenta características da estrutura funcional e da
estrutura por projeto. Esse tipo de organização é conhecido por estrutura matricial (Figura 1.7).

Figura 1.7 Estrutura matricial.

Na estrutura matricial, os indivíduos estão ligados a outros tanto por meio de suas áreas funcionais quanto
por meio de um ou mais projetos. Nesse contexto, o indivíduo normalmente tem dois superiores hierárquicos:
um da organização funcional e outro referente ao projeto. Na prática, como fica difícil esse compartilhamento
hierárquico, em razão de questões de orçamento, avaliação de desempenho, entre outras, a ligação organizacional
tende a ficar mais forte em um dos tipos (projeto ou função). Como conseqüência, surgiram duas variações da es-
trutura matricial, conhecidas por “Estrutura de Projeto Peso Pesado” e “Estrutura de Projeto Peso Leve”.
Em uma estrutura de Projeto Peso Pesado predomina a ligação baseada no projeto. Ela tem a natureza
cross-funcional. O gerente do projeto, conhecido por “gerente peso pesado”, tem completa autonomia e autori-
dade no orçamento e na avaliação do desempenho dos membros de seu time, e, normalmente, toma a maioria
das decisões sobre a alocação de recursos para o projeto. Embora cada participante pertença a uma unidade fun-
cional, o gerente funcional tem pouca autoridade e controle sobre ele em comparação com o gerente peso pe-
sado. Em muitas empresas, um Time de Projeto Peso Pesado é conhecido por Time de Desenvolvimento
Integrado de Produtos ou simplesmente de Time de Desenvolvimento.
28 PARTE 1 O Processo

A estrutura de Projeto Peso Leve apresenta ligações organizacionais baseadas na função mais forte do que
no contexto do projeto. Nesse caso, o gerente do projeto é mais um coordenador ou administrador, não tendo
autoridade nem controle sobre os indivíduos, sobre o orçamento do projeto, que normalmente é compartilhado
e controlado pelos gerentes funcionais, e sobre a avaliação de pessoal. Suas atribuições básicas estão mais direta-
mente relacionadas às tarefas operacionais de gestão de projetos.
A concepção de times de desenvolvimento — ou seja, do time de trabalho — parece fazer muito mais sen-
tido nas estruturas por projeto ou matricial. A estrutura funcional possui mais as características do trabalho em
grupo, isto é, uma ligação mais forte com a empresa como um todo e não com uma tarefa ou projeto específico.
Uma variedade de fatores determina como se deve organizar o PDP de uma empresa. A empresa deve ava-
liar qual o tipo de organização mais adequado para o desenvolvimento de seus projetos. Ela pode, por exemplo,
organizar seu PDP baseado em uma organização matricial do tipo peso leve, mas, para os projetos considerados
mais estratégicos, é recomendado estruturar uma organização matricial peso pesado. Para os casos de projetos
que envolvem alto grau de inovação, ou uma forte natureza de pesquisa e desenvolvimento, a organização de
projeto pura pode ser mais adequada. Já para um projeto de atualização ou ajuste do produto, uma organização
funcional pode ser suficiente. Obviamente, existem características e limitações que influenciam a decisão por
um tipo de organização ou outro — por exemplo, o porte da empresa, a capacidade de integração com deten-
tores de tecnologia externos, entre outros. Mas a importância do projeto, a dinâmica da inovação no ambiente
em que ela compete e o tipo de liderança necessária são fatores-chave para a definição.
Uma questão importante está relacionada à própria natureza dinâmica do PDP, devendo a empresa conti-
nuamente avaliar a necessidade de mudanças organizacionais nesse processo, procurando buscar pontos que for-
talecem o desenvolvimento de produtos. Por exemplo, a necessidade crescente de operar com vários projetos
simultaneamente. Esse foi o caso da Toyota, que promoveu uma mudança na organização do processo de desen-
volvimento de produtos para aumentar sua capacidade de coordenação e integração interprojetos. A empresa re-
alizou um projeto de reestruturação organizacional que culminou em uma organização que manteve a força da
coordenação e integração cross-funcional da organização peso pesado, e promoveu o aumento de sua capacidade
para coordenar vários projetos simultaneamente, como os projetos dos sistemas que compõem os veículos e os
projetos dos próprios veículos. Isso se deu por meio da organização de equipes de coordenadores de projetos.
As opções quanto ao tipo de organização do PDP não são muitas, mas suas variantes para cada aplicação são
inúmeras. As tabelas 1.2 e 1.3 apresentam uma síntese das características de cada tipo de organização para o
PDP, podendo ser útil para a tarefa de escolher as combinações mais adequadas para cada caso.

Tabela 1.2 Exemplos dos Tipos de Arranjos Organizacionais

Organização funcional Organização matricial Organização por projeto


Organização de projeto Organização de projeto
peso leve peso pesado
Exemplos Projetos de customização; Automóveis tradicionais; Projetos de sucesso mais Projetos de empresas que
típicos projetos do tipo inovação projetos de aparelhos recentes da indústria competem por inovação.
incremental. Projetos de eletrônicos. Projetos automobilística. Projetos Projetos de mudança
empresas de pequeno incrementais com alto com alto grau de inovação tecnológica radical.
porte. grau de complexidade. da indústria eletrônica. Projetos da indústria
Projetos derivativos de Projetos do tipo aeroespacial
plataformas existentes. plataforma.
Questões Como garantir a Como determinar e gerenciar o equilíbrio adequado, da Como compartilhar o
principais integração entre as equipe, entre a ligação funcional e a do projeto? aprendizado de um
diferentes funções para projeto para outro?
atingir os objetivos do
projeto?
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 29

Tabela 1.3 Características dos Tipos de Arranjos Organizacionais

Tipos de organização Funcional Matricial Por projeto


Características Peso leve Peso pesado
PERSPECTIVA DE LIDERANÇA
Autoridade do gerente de Pouca ou Nenhuma Baixa Forte Forte
projeto
Alocação do gerente de projeto Tempo Parcial Tempo Parcial Tempo Integral Tempo Integral
Principais funções Técnicas Técnicas Técnicas Técnicas
desempenhadas pelo gerente Comunicação Gerenciais Gerenciais
de projeto
Negociação Negociação
Comunicação Comunicação
Responsabilidade pela Gerentes funcionais Gerente peso leve Gerente peso pesado Gerente de projeto
integração entre as áreas
funcionais
Controle sobre o projeto de Compartilhada entre Compartilhada Total pelo gerente do Total pelo gerente
desenvolvimento o líder e os gerentes entre o líder e os projeto do projeto
funcionais gerentes funcionais
PERSPECTIVA DO GRUPO
Participação de pessoal de Limitada Limitada Extensa Extensa
outros departamentos funcionais
alocados ao projeto
Comunicação entre o gerente de Indireta Direta e Indireta Direta Direta
projeto e os membros da equipe
PERSPECTIVA DE APRENDIZAGEM
Aprendizagem sistêmica Baixa Moderada Grande Grande
(sobre o projeto como um todo)
Criatividade Focada na área Focada na área Mais sistêmica Mais sistêmica

1.9 Fatores gerenciais que afetam o desempenho do PDP


Os principais fatores gerenciais que afetam o desempenho do PDP são:
Integração do PDP com as estratégias de mercado, de produto e de desenvolvimento tecnológico:
As estratégias de mercado, de produto e de desenvolvimento tecnológico da empresa devem ser o ponto de par-
tida do PDP, e as atividades realizadas ao longo do PDP devem estar alinhadas a essas estratégias. Isso assegura a
realização de um fluxo de projetos adequados do ponto de vista das estratégias competitivas da empresa, a visibili-
dade da contribuição do PDP para a competitividade da empresa e a articulação e o apoio da alta administração.
Planejamento integrado do conjunto de projetos: O conjunto de produtos da empresa não representa
unidades isoladas; eles são relacionados e interdependentes, pertencendo a uma mesma família — ou como deri-
vados ou como extensões de linhas de produtos. Conseqüentemente, o mesmo ocorre com o conjunto dos pro-
jetos, os quais são interdependentes e relacionados em maior ou menor grau, compartilhando tecnologias
básicas, componentes, conceitos, projetos básicos etc. E é preciso gerenciar essa articulação com uma visão sistê-
mica do conjunto de projetos, buscando-se a otimização do desempenho desse conjunto.
Desenvolvimento: Os times, no sentido de uma equipe coesa, integrada e que compartilha uma mesma visão
e os objetivos do projeto, são os responsáveis diretos pelo desenvolvimento, ou seja, eles transformam as informa-
ções sobre o mercado e sobre as tecnologias em informações para a realização de todas as fases do ciclo de vida do
produto. Quanto à composição, há fortes evidências de que a interdisciplinaridade, a existência de um facilitador, e
a afinidade entre os seus membros afetam positivamente o desempenho do time. Em muitos casos, o uso de times
de projeto relativamente autônomos liderados por gerentes de projeto relativamente fortes (gerentes peso pesado)
30 PARTE 1 O Processo

no relacionamento com os gerentes funcionais e com os clientes e fornecedores possibilita melhores resultados.
Para mais informações sobre Times de Projeto, veja o Quadro 1.1 a seguir.

Quadro 1.1 Times/Equipes de Desenvolvimento

É comum uma equipe de desenvolvimento ser chamada de “time de projeto” ou “time de desenvolvimento”. O termo
“time” provavelmente foi empregado em conseqüência do reconhecimento da necessidade de se ter um grupo mais coeso
e engajado nos objetivos do projeto e do processo de desenvolvimento. Experiências mostram que trabalho em times e
bom desempenho são inseparáveis. E o processo de desenvolvimento de produtos é um ambiente que requer tanto o tra-
balho em grupo no contexto de todo o processo como o trabalho em times no desenvolvimento de projetos.

Critérios para se construir um time


Pode-se elaborar uma lista de critérios para se constituir um bom time de desenvolvimento, mas, certamente, ela não
será completa ao longo do tempo, nem mesmo válida para todos os contextos de desenvolvimento de produtos. Smith e
7
Reinertsen apresentam uma lista de critérios que pode ser útil como guia na constituição de um time de desenvolvimento.
Considera-se que, quanto maior o número de critérios da lista um time satisfizer, mais rapidamente ele deve desenvolver os
produtos. Os critérios são os seguintes.
Time formado por 10 ou menos membros:
• os membros são voluntários para compor o time;
• os membros trabalham no time desde a concepção até a produção;
• os membros dedicam-se em tempo integral ao time;
• os membros reportam-se diretamente ao líder do time;
• as funções-chave, que incluem Marketing, Engenharia e Produção, estão contidas no time; e
• os membros estão fisicamente próximos, facilitando a comunicação e o diálogo.
É difícil compor um time que atenda a todos esses critérios. E muitas questões são derivadas da análise dessa lista, tal
como qual o tamanho ideal de um time, considerando-se o tamanho da empresa, a complexidade do produto, o prazo de
desenvolvimento. Pode-se estimar a necessidade de horas de trabalho em termos de horas-homem, e comparar esse valor
com o prazo para concluir o projeto. É importante salientar que times menores mostram-se mais eficientes, e que a dedi-
cação integral agiliza o desenvolvimento, pois os membros gastarão menos tempo em reuniões e mais em tarefas de desen-
volvimento em razão da maior facilidade do processo de comunicação.

Tamanho do time e competências necessárias


A determinação do tamanho do time por essa maneira é relativamente fácil. Entretanto, vários fatores dificultam a com-
8
posição de um time. Ulrich e Eppinger destacam três fatores: (1) a necessidade de competências específicas para completar
o projeto, sendo que o time não pode ter um profissional tão especializado durante todo o tempo de desenvolvimento; (2)
um ou mais membros não podem se desligar de algumas responsabilidades que já possuem, limitando a participação em
tempo integral; (3) a quantidade de trabalho não é constante ao longo do desenvolvimento (normalmente ela aumenta),
acarretando a necessidade de inclusão de outros profissionais na tentativa de cumprir os prazos. Em relação às competên-
cias necessárias para os membros de um time, pode-se destacar três categorias de habilidades que auxiliam na composição
do time: competências técnicas e funcionais, habilidades para solução de problemas e tomada de decisões, e habilidades in-
terpessoais.
Como um projeto de desenvolvimento de um novo produto envolve muitas incertezas, utilizam-se estimativas, princi-
palmente para tratar as variáveis tempo e custo de desenvolvimento. Também existe a variável qualidade, que, junto com
tempo e custo, pode ser utilizada para a realização de uma análise sobre a composição de um time de desenvolvimento. Por
exemplo, quando um projeto envolve o uso de novos materiais (como o caso de termoplásticos de engenharia) e ainda não
se tem domínio do comportamento da peça tanto na operação do sistema como um todo quanto no próprio processo de fa-
bricação, a qualidade passa a ser uma variável importante para se definir a composição do time. Ou seja, o estudo da funcio-
nalidade para a definição das especificações dimensionais vai requerer estudos especiais sobre durabilidade, confiabilidade

(continua)
7
SMITH, P. G.; REINERTSEN, D. G. Developing products in half time. 2. ed. New York: Van Nostrand Reinhold,1998.
8
ULRICH, K. T.; EPPINGER, S. D. Product design and development. 2. ed. Boston: McGraw-Hill, 2000.
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 31

Quadro 1.1 Times/Equipes de Desenvolvimento (continuação)

e capacidade de processo, o que leva à inclusão de membros que dominam técnicas e métodos de confiabilidade, projeto
de experimentos, capacidade de processo, e o próprio processo de transformação do termoplástico.

Liderança do time
O aspecto liderança é um dos principais fatores para que um time tenha êxito. Apesar de o trabalho em time prever a pos-
sibilidade de compartilhamento dos papéis da liderança, no caso de projetos de desenvolvimento, a liderança interna pode
ser compartilhada, dependendo das fases de desenvolvimento. Porém, a liderança do projeto como um todo deve ser man-
tida sob um único líder, pois os papéis relacionados à interface com outros setores internos ou externos, e, principalmente,
com a alta administração, exigem uma convergência de habilidades em uma única pessoa.
A primeira das habilidades de um líder de time de desenvolvimento é a Habilidade de Liderança. O líder deve estar prepa-
rado para aproveitar o máximo dos membros do time, e facilitar para que as atividades sejam de fato desenvolvidas como
um trabalho em time. Ou seja, mostra que as responsabilidades não são somente individuais, mas também mútuas. A se-
gunda habilidade é a Visão, que está relacionada à capacidade do líder em ter e saber construir uma visão clara do produto e
o que determina o seu sucesso. Para isso, sua capacidade de argumentação para testar por meio de questionamento as deci-
sões ao longo do desenvolvimento, e de saber manter o foco nos objetivos do projeto, deve ser superior. Existem outras
duas habilidades que também são importantes, porém podem ser consideradas secundárias em relação às duas primeiras.
Uma delas é a habilidade técnica, o que leva à necessidade de o líder conhecer as tecnologias que entram na composição do
produto para poder entender aspectos técnicos envolvidos no projeto e argumentar com os membros sobre alternativas e
interfaces tecnológicas com a fabricação, assistência técnica, entre outras. Os produtos atualmente envolvem vários tipos
de tecnologia, e fica difícil, e às vezes arriscado, decidir por um líder pela competência técnica em uma dessas tecnologias.
Isso é o que faz essa habilidade ser secundária em relação às habilidades de liderança e de visão. A última habilidade é a de
Gerenciamento de Projeto, que está relacionada às atividades típicas de gestão de projetos, como cronograma, recursos, re-
latórios etc. Essa habilidade é considerada secundária em relação às duas primeiras porque o líder deve ter domínio sobre as
atividades e métodos de gestão de projetos para fins de sínteses, análises e tomada de decisões, mas as tarefas mais opera-
cionais podem ser realizadas por outra pessoa.

Recompensa
Uma outra questão importante do trabalho em times é a recompensa. Considera-se que recompensar os membros de um
time de desenvolvimento é uma boa prática relacionada aos produtos de sucesso. O objetivo de uma sistemática de recom-
pensa não deve ser somente reconhecer o que o time realiza, mas também encorajar outros a fazer o mesmo.

Papel dos líderes e gerentes do projeto: A definição — ou seja, a indicação e o papel desempenhado
pelos líderes e gerentes do projeto — é fundamental para o desempenho do time. Os líderes, por exemplo, fazem
a ligação do time com a alta administração da empresa e com os administradores das áreas funcionais, gerenciam
as atividades do projeto e mantêm a motivação do time. Assim, sua atuação afeta sobremaneira o desempenho do
time, por sua capacidade de resolver conflitos, isolar o time de problemas exteriores, e prover os recursos, um
bom ambiente de trabalho e uma visão ampla sobre o caminho a ser trilhado pelo time.
Envolvimento da cadeia de fornecedores e de clientes: Quanto aos fornecedores, os casos bem-suce-
didos evidenciam que o seu envolvimento, o mais cedo possível, diminui o tempo de conclusão do projeto (time
to market) e aumenta a produtividade do desenvolvimento, por meio da diminuição da complexidade do projeto
e da antecipação da solução de problemas no projeto por parte da equipe de desenvolvimento dos fornecedores.
Já com relação aos clientes, considera-se que o seu envolvimento melhora principalmente a adequação do con-
ceito do produto às necessidades dos usuários, ou seja, a qualidade do produto desenvolvido.
Integração das áreas funcionais da empresa: Essa integração permite a prevenção e a resolução anteci-
pada de problemas por meio da colaboração e da troca de informações em todas as fases do desenvolvimento, e
ainda facilita a abordagem das questões do projeto relativas a interfaces entre os departamentos da empresa. É
vastamente reconhecido que a orientação para o mercado, de todos os envolvidos no desenvolvimento, e a inte-
gração entre os diversos departamentos envolvidos podem afetar positivamente o desempenho do PDP.
32 PARTE 1 O Processo

Ainda em relação à integração entre as áreas funcionais da empresa e o PDP, uma maior aproximação entre
a Pesquisa & Desenvolvimento e as Engenharias de Produto e de Processo tem como conseqüência uma mais
rápida introdução de inovações tecnológicas nos novos produtos, resultando em maior confiabilidade do pro-
duto final e melhor manufaturabilidade. A integração do PDP com as áreas de Marketing e Produção contribui
para reduzir o tempo de desenvolvimento pela proximidade maior com a manufatura e pela orientação decisiva e
maior sensibilidade das atividades de desenvolvimento às necessidades do mercado. A integração entre o PDP e
outros processos também foi discutida no Tópico 1.5 deste capítulo.
Estruturação das etapas e atividades do processo: O PDP, assim como qualquer tipo de processo de ne-
gócio, pode ser representado simbólica e formalmente por meio de um modelo de referência, que descreve as
atividades, os resultados esperados, os responsáveis, os recursos disponíveis, as ferramentas de suporte e as infor-
mações necessárias e ou geradas no processo. Tal modelo serve como um referencial comum na empresa, um
guia que auxilia no gerenciamento do processo, por facilitar o entendimento e a comunicação entre os inte-
grantes do desenvolvimento (internos e externos à empresa), e por facilitar a implantação e a integração de mé-
todos, técnicas e sistemas de apoio ao PDP.
Em relação a esse fator, a superposição das diferentes atividades funcionais e das fases do desenvolvimento
é especialmente importante por facilitar a comunicação e a troca de informações, o mais cedo possível, entre as
áreas envolvidas no PDP ao longo do ciclo de vida do produto. Isso permite, por exemplo, a resolução anteci-
pada de problemas e a redução do tempo de desenvolvimento.
Esse fator da gestão do PDP é o foco principal deste livro.

1.10 Modelo de referência é essencial para o PDP


O desenvolvimento de produto precisa ser um processo eficaz e eficiente para realmente cumprir sua
missão de favorecer a competitividade da empresa. O desempenho desse processo depende, fundamentalmente,
do modelo geral para sua gestão, o qual, por sua vez, determina a capacidade de as empresas controlarem o pro-
cesso de desenvolvimento e de aperfeiçoamento dos produtos e de interagirem com o mercado e com as fontes
de inovação tecnológica. Por geral, entende-se o modelo que engloba a gestão estratégica, a gestão operacional
do desenvolvimento e os ciclos de resolução de problemas, de melhoria e de aprendizagem, considerando-se
todo o ciclo de vida do produto. Deve considerar, ainda, as melhores e mais adequadas práticas dos fatores de
gestão anteriormente mencionados O núcleo central desse modelo geral, representado pela estruturação das
etapas e atividades operacionais do desenvolvimento do projeto, é o foco do modelo de referência apresentado
nos capítulos seguintes deste livro.
Por eficácia do PDP, entende-se que ele deve apresentar resultados em projetos e produtos, que sejam ade-
quados e competitivos, ou seja que atendam às expectativas do mercado e que estejam devidamente integrados às
estratégias da empresa. Por eficiência, entende-se que o processo é capaz de atingir esses resultados utilizando o
mínimo possível de recursos, os quais incluem o tempo e os custos para se desenvolver.
A formalização do modelo de gestão e de estruturação do desenvolvimento de produto possibilita que todos
os envolvidos (alta administração, pessoal das áreas funcionais da empresa e os parceiros) tenham uma visão
comum desse processo: o que se espera de resultados do PDP, quais e como as atividades devem ser realizadas, as
condições a serem atendidas, as fontes de informação válidas e os critérios de decisão a serem adotados.
Assim, tendo em vista a importância do processo de desenvolvimento de produtos, e de se obter bons resul-
tados dele a partir de sua gestão, é fundamental que se adote um modelo de referência, mais adequado às necessi-
dades da empresa, que oriente a estruturação e gestão desse processo.

1.11 Resumo do capítulo


O desenvolvimento de produtos é considerado um processo de negócio cada vez mais crítico para a compe-
titividade das empresas, principalmente com a crescente internacionalização dos mercados, aumento da diversi-
dade e variedade de produtos e redução do ciclo de vida dos produtos no mercado. Novos produtos são
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 33

demandados e desenvolvidos para atender a segmentos específicos de mercado, incorporar novas tecnologias, se
integrar a outros produtos e usos e se adequar a restrições legais.
Desenvolver produtos consiste no conjunto de atividades por meio das quais busca-se, a partir das necessi-
dades do mercado e das possibilidades e restrições tecnológicas, e considerando as estratégias competitivas e de
produto da empresa, se chegar às especificações de projeto de um produto e de seu processo de produção, para
que a manufatura seja capaz de produzi-lo e de acompanhá-lo após seu lançamento. Assim, irão se realizar as
eventuais mudanças necessárias nessas especificações, planejar a descontinuidade do produto no mercado e in-
corporar, no processo de desenvolvimento, as lições aprendidas ao longo do ciclo de vida do produto.
Ao longo das últimas décadas, diversos casos bem-sucedidos de empresas e países em termos de desenvolvi-
mento de produtos evidenciaram que o desempenho desse processo depende do modelo e das práticas de gestão
adotadas. Ou seja, mesmo sendo um processo com elevado grau de incerteza e baixa previsibilidade de resul-
tados, é possível e necessário gerenciar o PDP, planejando, executando, controlando e melhorando as ativi-
dades, em busca de melhores resultados de desempenho e de aprendizagem.
O Brasil necessita exportar produtos de maior valor agregado, o que exige uma maior capacitação e esforço
no desenvolvimento de produtos, para dispor, para o mercado local, produtos com padrões equivalentes aos im-
portados, e para capacitar o país a exportar produtos de padrão internacional. E isso passa, necessariamente, pela
melhoria na qualificação do corpo técnico e gerencial das empresas em gestão do processo de desenvolvimento
de produtos.
As características desse processo fazem com que sua natureza seja relativamente diferente dos demais pro-
cessos empresariais, o que condiciona os modelos e as práticas de gestão adequadas ao processo, além do perfil e
das capacitações requeridas dos profissionais envolvidos no PDP.
Os projetos realizados por uma empresa podem ser classificados em categorias, o que facilita planejar estra-
tegicamente e de forma conjunta todos os projetos de desenvolvimento, os quais possuem relevância e necessi-
dades de recursos que são específicas a cada caso. Com isso, busca-se assegurar a quantidade adequada de
recursos para coordenar e executar os vários projetos, conseguir eficiência nas atividades realizadas e obter um
padrão adequado de inovação dos produtos da empresa.
O desenvolvimento de produto envolve muitas atividades que devem ser executadas por diversos profissio-
nais de diferentes áreas da empresa, tais como: Marketing, Pesquisa & Desenvolvimento, Engenharia do Pro-
duto, Suprimentos, Manufatura e Distribuição — cada uma vendo o produto por uma perspectiva diferente, mas
de forma complementar. Essa particularidade exige que essas atividades e decisões sejam realizadas em conjunto
e de forma integrada, evidenciando a necessidade de se estruturar um processo específico que reúna esse con-
junto de atividades a serem planejadas e gerenciadas de forma dedicada.
A tomada de decisões sobre o projeto envolvendo pessoas com diferentes visões do produto, ainda na fase
de desenvolvimento, pode antecipar problemas e soluções, além de reduzir o tempo de lançamento do produto.
Decisões inadequadas tomadas no início do desenvolvimento podem ser difíceis e caras de serem revertidas nas
fases em que o produto já se encontra em produção e uso no mercado.
Assim, cada vez mais se incorporam a esse processo as estratégias de produto, de mercado e tecnológicas da
empresa e as atividades necessárias para suportar a produção, o lançamento e o acompanhamento do produto no
mercado e a decisão de sua descontinuidade. Com essas ampliações, obtém-se um processo mais coeso, em que o
planejamento e a execução do projeto e o acompanhamento do produto pós-venda estão integrados em uma
mesmo processo de negócio.
Além de influenciar a qualidade do produto e do processo, o PDP tem forte influência sobre outros fatores
de vantagem competitiva como custo, velocidade e confiabilidade de entrega e flexibilidade. Estima-se que são
possíveis reduções de mais de 50% no tempo de lançamento de um produto, quando os problemas de projeto são
identificados e resolvidos com antecedência. Estima-se, também, que o atraso na detecção e correção de pro-
blemas, à medida que se avança do projeto para a produção e para o consumo, representa um aumento do custo
de alteração (resolução dos problemas), que cresce em progressão geométrica de razão 10 a cada fase.
34 PARTE 1 O Processo

O processo de desenvolvimento de produtos pode ter seu desempenho avaliado por meio de indicadores as-
sociados à qualidade total do produto desenvolvido, aos custos e à produtividade deste processo e ao tempo total
de desenvolvimento, e de sua contribuição para a competitividade da empresa em termos de conhecimento tec-
nológico, rentabilidade, crescimento e participação no mercado.
O modo como a empresa desenvolve produtos — ou seja, sua estratégia de produto — e como ela organiza
e gerencia o desenvolvimento é que determinará o desempenho do produto no mercado e a velocidade, efi-
ciência e qualidade do processo de desenvolvimento.
A análise de como se encontra e como deveria ser a gestão do PDP de uma empresa deve considerar um
contexto amplo que inclui o ambiente competitivo em que a empresa está inserida e suas demandas, a capaci-
tação e organização interna da empresa e o desempenho do processo. Ou seja, o desempenho no desenvolvi-
mento, que é um importante contribuinte para a competitividade da empresa, é determinado pela estratégia de
produto da empresa e por suas capacidades, técnica e gerencial, e pela organização no processo como um todo.
A abordagem para organização do PDP, que pode ser considerada mais adequada à empresa, dependerá
dessa análise. Ou seja, para manterem e melhorarem seu desempenho e competitividade, as empresas devem, de
forma dinâmica, adaptar suas formas de organização e de gerenciamento do desenvolvimento para modelos mais
adequados ao ambiente competitivo e de mercado.
As empresas, e as atividades do PDP, devem se adequar ao status (estático ou dinâmico) das inovações no
setor industrial em que estão inseridas, ou seja, caso, no setor, as inovações sejam raras (estático) ou bastante fre-
qüentes (dinâmico). Culturas e práticas adequadas para empresas de um setor estático não funcionarão bem em
um setor dinâmico e vice-versa.
Os produtos também diferem quanto à complexidade de sua estrutura interna e quanto à complexidade da
interface usuário-produto. Para cada tipo de produto, as questões críticas para a gestão do desenvolvimento de-
penderiam do grau dessas complexidades.
A organização das equipes de desenvolvimento de produto se refere à forma como os indivíduos que estão
trabalhando estão interligados, individualmente ou em grupos, seja formal ou informalmente. As maneiras mais
tradicionais de realizar essa ligação organizacional ocorrem por meio do alinhamento de funções ou de projetos,
ou ambos. A concepção de times de desenvolvimento, ou seja, do time de trabalho, parece fazer mais sentido nas
estruturas por projeto ou matricial. A estrutura funcional possui mais as características do trabalho em grupo, isto
é, ela representa uma ligação mais forte com a empresa como um todo e não com uma tarefa ou projeto específico.
Os principais fatores gerenciais que afetam o desempenho do PDP são:

n Integração do PDP com as estratégias de mercado, de produto e de desenvolvimento tecnológico.


n Planejamento integrado do conjunto de projetos.
n Desenvolvimento de Times de Projeto.
n Papel dos líderes e gerentes de projeto.
n Envolvimento da cadeia de fornecedores e de clientes.
n Integração das áreas funcionais da empresa.
n Estruturação das etapas e atividades do processo.

O desenvolvimento de produtos deve ser um processo eficaz e eficiente para realmente cumprir sua missão
de favorecer a competitividade da empresa. O desempenho desse processo depende, fundamentalmente, do mo-
delo geral para sua gestão — o qual, por sua vez, determina a capacidade de as empresas controlarem o processo
de desenvolvimento e de aperfeiçoamento dos produtos e de interagirem com o mercado e com as fontes de ino-
vação tecnológica.
A formalização do modelo de gestão e de estruturação do desenvolvimento de produto possibilita que todos
os envolvidos (alta administração, pessoal das áreas funcionais da empresa e os parceiros) tenham uma visão
comum desse processo: o que se espera de resultados do PDP, quais e como as atividades devem ser realizadas, as
condições a serem atendidas, as fontes de informação válidas e os critérios de decisão a serem adotados.
CAPÍTULO 1

Gestão do Processo de Desenvolvimento de Produtos 35

1.12 Questões e atividades didáticas propostas


Questões para reflexão
1. O que significa desenvolver produtos?
2. Qual a finalidade e o escopo (abrangência) do PDP?
3. Como o PDP pode contribuir para a capacidade competitiva de uma empresa?
4. Quais as principais características específicas do PDP?
5. Qual a importância de classificar, em categorias, os tipos de projetos de desenvolvimento de uma em-
presa?
6. Qual a contribuição ou papel, para o PDP, das principais funções ou processos empresariais?
7. Qual a importância, para a empresa, de uma boa gestão estratégica e operacional do PDP?
8. Faça uma síntese e discuta as principais características e diferenças entre as abordagens gerais para
gestão do PDP?
9. Quais as principais características, bem como os pontos fortes e fracos, dos arranjos organizacionais
para equipes de desenvolvimento?
10. Identifique e explique os principais fatores gerenciais, que afetam o desempenho do PDP, separando os
mais estratégicos dos mais operacionais?
11. Por que é importante para uma empresa adotar um modelo de referência para o seu PDP? Quais as con-
seqüências previsíveis, caso a empresa vá estruturando seu PDP sem seguir um modelo?

Atividades didáticas
1. Vá a uma empresa, identifique e analise o escopo de seu PDP. Ele está adequado? O que estaria faltando
ser incluído no PDP da empresa?
2. Discuta com profissionais de empresas, ou com estudantes, das áreas de Marketing e de Manufatura, o
que eles entendem por desenvolvimento de produto? Qual a visão que eles têm confrontada com o es-
copo do PDP apresentado no livro?
3. Quais as categorias de tipos de projeto da empresa visitada?
4. Como se dá, na prática, o relacionamento e a integração do PDP com as áreas de Marketing, Manufa-
tura e de Assistência Técnica da empresa?
5. Qual a estrutura organizacional que a empresa segue para as equipes de projeto? Quais os problemas
existentes em relação a ela? Essa estrutura é a mais adequada à empresa?
6. Avalie como se encontra a gestão do PDP em uma empresa, ou seja, faça um diagnóstico dos principais
fatores gerenciais que influenciam o desempenho do PDP dessa empresa.

1.13 Informações adicionais


BROWN, S. L. & EISENHARDT, K. M. “Product development: past research, present findings, and future
directions.” Academy of Management Review, v. 20, n. 2, p. 343-378, abr. 1995.
CHRISSIS, M. B.; KONRAD, M.; SHRUM, S. CMMI: Guidelines for process integration and product
improvement. SEI, New York: Addsion Wesley, 2003
CLARK, K. B.; FUJIMOTO, T. Product development performance: strategy, organization and
management in the world auto industry. Boston-Mass.: HBS Press, 1991. p. 405.
CLARK, K. B.; HENDERSON, R. M. “Architectural innovation: the reconfiguration of existing product
technologies and the failure of established firms. Administrative Science Quarterly, Cornell, v. 35, p. 9-30, mar.
1990.
36 PARTE 1 O Processo

CLARK, K. B.; WHEELRIGHT, S. C. Managing new product and process development: text and
cases. New York: The Free Press, 1993.
CLAUSING, D. Total quality development. New York: ASME Press, 1994.
COOPER, R. G.; EDGETT S. J.; KLEINSCHMIDT, E. J. Portfolio management for new products.
New York: Perseus Books, 1998.
CUSUMANO, M.; NOBEOKA, K. Thinking Beyond Lean. New York: Free Press, 1998.
GRIFFIN, A. “PDMA research on new product development practices: updating trends and benchmarking
best practices.” Journal of Product Innovation Management, Manchester, v. 14, p. 429-458, 1997.
ROZENFELD, H.; AMARAL, D. C.; TOLEDO, J. C.; CARVALHO, J. “O processo de desenvolvimento
de produtos”, cap. 8, p. 55-64. In: Fábrica do futuro: entenda hoje como sua indústria vai ser amanhã, São
Paulo: Editora Banas, 2000.
SAREN, M. A. “A classification and review of models of the intra-firm innovation process.” R&D
Management, v. 14, n. 1, p. 11-24, 1984.
ULRICH, K. T.; EPPINGER, S. D. Product design and development. New York: McGraw-Hill, 1995.
p. 284.
WARD, A. et al. “Toyota’s principles of set-based concurrent engineering.” Sloan Management Review, v. 40,
p. 67-83, 1999.
WHEELWRIGHT, S. C.; CLARK, K. B. Leading product development: the senior manager’s guide to
creating and shaping the enterprise. New York: Hardcover, 1995.
2.1 Conceitos de modelagem de processos
2.2 Visão geral do modelo
2.3 Os papéis principais das pessoas envolvidas no PDP
2.4 Visão geral da macrofase de pré-desenvolvimento
2.4.1 Por que pré-desenvolvimento?
2.4.2 Conceitos básicos do processo de planejamento estratégico
2.4.3 O início e o fim do pré-desenvolvimento
2.4.4 A importância do pré-desenvolvimento
2.4.5 Pré-desenvolvimento é para todos?
2.5 Visão geral da macrofase de desenvolvimento
2.5.1 Características das fases do desenvolvimento
2.5.2 O início e o fim do desenvolvimento
2.6 Visão geral da macrofase de pós-desenvolvimento
2.6.1 Por que pós-desenvolvimento?
2.6.2 O início e o fim do pós-desenvolvimento
2.6.3 Pós-desenvolvimento é para todos?
2.7 Revisão de fases (gates)
2.8 Métodos e ferramentas de desenvolvimento de produtos
2.9 Indicadores de desempenho do PDP
2.10 Parceiros do desenvolvimento colaborativo de produtos
2.11 Áreas de conhecimento
2.12 Gestão do conhecimento do PDP
2.13 Caracterizando o modelo
2.14 Resumo do capítulo
2.15 Questões e atividades didáticas propostas
2.16 Informações adicionais

2. O Modelo Unificado do PDP


O Modelo Unificado do PDP
PARTE 1 O Processo

Depois da leitura deste capítulo, você será capaz de:


G Definir processo de desenvolvimento de produtos.
G Compreender a importância de utilizar o conceito de processo e modelos de referência para a gestão do
desenvolvimento de produtos.
G Compreender a estrutura de macrofases e fases em que o modelo unificado foi estruturado.
G Compreender os principais conceitos, importância e resultados principais de cada uma das três macrofases do
processo de desenvolvimento do modelo unificado.
38 PARTE 1 O Processo

G Compreender alguns conceitos e tendências em desenvolvimento de produto que serviram de base para o modelo
unificado. São eles: revisões de fase, métodos e ferramentas de desenvolvimento de produtos, indicadores de
desempenho, parceria no desenvolvimento de produto e gestão do conhecimento.
G Compreender a relação entre as áreas do conhecimento empregadas na gestão do desenvolvimento de produtos e o
modelo unificado.
G Entender algumas características específicas do modelo unificado que devem ser consideradas durante sua adaptação
e utilização em casos reais.

Este capítulo apresenta uma visão geral do modelo unificado do Processo de


Objetivo deste capítulo Desenvolvimento de Produtos (PDP) com o objetivo de facilitar a compreensão da
segunda parte do livro, que descreve uma visão completa do conteúdo do modelo.
Outro objetivo é apresentar os conceitos necessários ao entendimento das fases descritas na segunda parte
deste livro. Começaremos pela definição do que é o modelo de referência unificado.
O Capítulo 1 demonstrou a importância de conseguir a integração entre as ativi-
O que é o modelo dades do PDP, e da sinergia desse processo com os demais processos empresariais,
unificado do PDP?
incluindo as empresas fornecedoras e clientes. Mas por que isso é tão difícil de conse-
guir na prática? Por causa da natureza não estruturada do processo de desenvolvi-
mento de produtos. Um exemplo: imagine que alguém precise saber como é fabricado um automóvel. Embora seja
um processo altamente complexo, é bem provável que a pessoa interessada iniciasse sua jornada visitando a linha
de montagem. Durante a visita, então, seria possível observar todas as atividades principais para a montagem do
veículo — desde a chegada das peças —, entendendo a seqüência em que elas ocorrem. Qualquer pessoa sairia de lá
com uma boa noção de quem faz o quê. Isto é, os resultados e o papel de cada departamento, tais como: engenharia
de processos, qualidade, logística, contabilidade etc. Imagine, porém, se a mesma solicitação fosse feita para de-
monstrar o desenvolvimento de um produto. Provavelmente, a pessoa iria para o departamento de engenharia. Ela
encontraria um conjunto de funcionários atrás de vários computadores, realizando tarefas diferentes, conversando
e, certamente, muitos deles realizando tarefas comuns, como passar um fax ou tomar café. Mas qual o processo de
desenvolvimento? Para saber, seria preciso percorrer as estações, observando e tentando montar um quebra-ca-
beça imaginário, pois não daria para observar as atividades na seqüência correta. O próprio nascimento do produto
não seria observável, afinal, provavelmente, os projetos atuais iniciaram meses atrás, a partir de alguma decisão em
uma sala da diretoria. Além disso, muitas das atividades são realizadas no chão de fábrica — como o teste de uma
máquina —, em outras partes da empresa — como a análise de viabilidade e orçamentos preparados no departa-
mento de compras — ou, ainda, dentro de empresas fornecedoras e clientes. Imagine, também, a diversidade de
áreas funcionais e pessoal envolvido. Em projetos de automóveis, por exemplo, caso alguém contabilize todos os
profissionais que realizaram alguma tarefa do projeto, esse número pode chegar a milhares de pessoas e apenas
poucas centenas farão parte efetiva da empresa responsável pelo projeto.
A dificuldade de descrever como é o processo de desenvolvimento tem reflexos importantes na forma como
ele pode ser gerenciado. Como prever, planejar e controlar o trabalho das pessoas uma vez que nem todos têm
uma linguagem comum e uma visão mínima do andamento do projeto geral e da contribuição que é esperada
para a empresa? Lembre-se de que, quando uma linha de produção pára, todos ficam sabendo, pois a paralisação
afeta-os de maneira imediata. Ao contrário, um problema em um processo de desenvolvimento pode aparecer
meses ou até mesmo anos após sua ocorrência. O primeiro passo para o gerenciamento eficiente do processo de
desenvolvimento de produtos, portanto, é torná-lo “visível” a todos os atores envolvidos.
É nesse momento que entra a importância da modelagem de processos de negócio, da qual trataremos deta-
lhadamente neste capítulo. A modelagem de processos é uma área do conhecimento que estuda os métodos e as
CAPÍTULO 2

O Modelo Unificado do PDP 39

ferramentas necessárias para descrever os processos de negócio das empresas. O resultado final é um modelo,
isto é, um mapa ou representação, que descreve como é o processo de negócio. No caso deste livro, estaremos
abordando exclusivamente o processo (de negócio) de desenvolvimento de produtos (PDP). Portanto, obter um
modelo do PDP significa descrever as atividades, recursos, informações, fases, responsabilidades e outras possí-
veis dimensões do processo. Em uma empresa, estaríamos falando de desenvolver o modelo de referência para
essa empresa — aquele modelo que serve de guia para todos os projetos de desenvolvimento de produtos. Aqui,
estaremos apresentando um modelo cujo objetivo é apresentar as melhores práticas em desenvolvimento de
produtos. O propósito é claramente didático, mas nada impede que uma empresa utilize-o como referência para
identificar pontos que poderiam ser melhorados: o modelo unificado.
O modelo unificado de desenvolvimento de produtos originou-se da união das
metodologias, estudos de caso, modelos, experiências e melhores práticas desenvol- Origem do modelo
vidas e coletadas nos últimos anos pelas equipes de pesquisadores coordenadas pelos
autores, como descrito em detalhes na apresentação do livro. Ele também considera comparações e avaliações
realizadas com modelos de referência para PDP de empresas líderes em desenvolvimento de produtos de di-
versos ramos, em especial metal-mecânico. Versões simplificadas e específicas do modelo já foram validadas em
casos práticos, tanto no desenvolvimento de produtos realizado pelos autores deste livro, como, também, na criação
de modelos de referência específicos em algumas empresas. O modelo reflete, portanto, o conhecimento e a ex-
periência acumulados pelos autores.
O capítulo contém três conjuntos de tópicos apresentados na Figura 2.1. O
primeiro contém tópicos com conceitos básicos de modelagem e de desenvolvi- Conteúdo deste capítulo
mento de produtos, fundamentais para que o modelo possa ser compreendido
(parte inferior esquerda da figura). Profissionais de empresa ou estudantes já familiarizados com o desenvolvi-
mento de produtos podem “saltar” os dois tópicos que fazem parte desse conjunto. O segundo conjunto é
composto por tópicos contendo a descrição completa do modelo, em um nível mais alto de abstração (parte
superior da figura), e está dividido em dois subconjuntos. O primeiro apresenta uma síntese de cada macrofase
com as atividades, principais documentos e responsabilidades. Serve de leitura introdutória para a descrição
detalhada do modelo na Parte 2 deste livro. Complementarmente, há um outro subconjunto de tópicos que
trata das características especiais do modelo e que merece a atenção do leitor. Aí estão descritos detalhes con-
siderados importantes e são apresentadas as melhores práticas adotadas na construção do modelo, que trans-
cendem o escopo de apenas uma fase — isto é, são assuntos que dizem respeito a todas as fases. O terceiro
subconjunto, composto por apenas um tópico, trata das limitações do modelo e é a discussão sobre suas carac-
terísticas visando orientar a aplicação (parte inferior direita da Figura 2.1). Ele é fundamental para que os pro-
fissionais e estudantes de pós-graduação interessados em utilizar o modelo possam entender os limites para
sua aplicação. Alunos de graduação ou profissionais de empresa interessados em uma visão geral do modelo
podem ignorar esse tópico.
A disposição dos tópicos foi elaborada conforme uma leitura seqüencial. Uma vez conhecida a organização
apresentada na Figura 2.1, você poderá pular ou antecipar itens conforme sua experiência prévia no assunto.
O capítulo inicia com a descrição dos conceitos básicos sobre modelagem de empresas. Depois é apresen-
tado um primeiro nível de detalhamento do modelo, sua visão geral. Em seguida, são expostos os papéis citados
nas atividades do modelo. As três macrofases são descritas em detalhes, fornecendo um segundo nível de deta-
lhamento do modelo (o terceiro nível de detalhamento está na Parte 2 do livro). Os subitens subseqüentes des-
crevem conceitos complementares, que ajudarão no entendimento da Parte 2 do livro: o tópico “revisão de
fases” descreve a origem e os princípios da avaliação de projetos de desenvolvimento; “parceiros” discute a for-
ma de relacionamento entre empresas de uma mesma cadeia de suprimentos e como elas podem fazer proveito
deste livro; “ferramentas e métodos” mostra de que maneira é possível relacioná-las com as atividades e tarefas
propostas neste livro; “indicadores de desempenho” discute a necessidade de medir o progresso e os resultados
de um projeto de desenvolvimento. O tópico “áreas de conhecimento” mostra que as atividades de cada fase
40 PARTE 1 O Processo

Figura 2.1 Esquema de apresentação do capítulo.

também podem ser agrupadas de uma outra forma, facilitando a sua visualização por pessoas que trabalham em
departamentos funcionais e que participaram em times de desenvolvimento de produtos. A gestão de conheci-
mento é um tema que abrange todos os tópicos anteriores. Nesse tópico, o PDP é comparado a outros tipos de
processos, e analisa-se como o modelo deste livro pode contribuir para a criação de uma organização que
aprende. Finalmente, o modelo de referência a ser detalhado na Parte 2 do livro é caracterizado, para que o le-
itor entenda onde e como ele pode ser aplicado. Assim, você poderá estudar a Parte 2 do livro conhecendo o seu
potencial e suas limitações, e já se preparando para entender a Parte 3, que trata exclusivamente da aplicação do
modelo em casos práticos.

2.1 Conceitos de modelagem de processos


Vamos conhecer alguns aspectos básicos da modelagem de
processos para definir o tipo de modelo apresentado neste livro.
Até agora, utilizamos os termos processo e projeto de desenvolvi-
mento de produtos sem nos preocuparmos em distingui-los.
Convém, então, delimitar esses termos para um melhor entendi-
mento do conteúdo deste livro.
Processos de negócio compreendem um conjunto de ativi-
dades organizadas entre si visando produzir um bem ou um ser-
viço para um tipo específico de cliente (interno ou externo à
empresa). Eles podem representar operações repetitivas da em-
presa, que normalmente são estruturadas, como no caso dos pro-
cessos de gestão financeira ou de produção. No entanto, o
1
processo de desenvolvimento de produtos não é tão estruturado ,
Diferença entre processo porque cada desenvolvimento de um produto específico pode ser
e projeto diferente.

1
Veja uma discussão completa no Tópico 2.12, mais adiante, neste capítulo e um exemplo de comparação entre o PDP e um processo
estruturado no Quadro 2.8, também neste capítulo.
CAPÍTULO 2

O Modelo Unificado do PDP 41

Projetos também representam um conjunto de atividades, porém, eles são únicos e temporários, ou seja,
possuem início, meio e fim. A Figura 2.2 salienta a diferença entre processo e projeto.
Processos possuem objetivos estabelecidos periodicamente. Por exemplo, no processo de produção, po-
de-se definir que, em um ano, a porcentagem de peças refugadas na fábrica deve diminuir de 3% para 1%. Outro
exemplo seria o aumento do retorno financeiro a ser estabelecido como meta do processo de gestão financeira da
empresa.
Projetos possuem objetivos únicos e específicos a serem atingidos no final de sua realização. No caso de um
projeto de desenvolvimento de um produto, as metas normalmente estabelecidas indicam a data de lançamento
do produto e o seu custo, entre outras.

Figura 2.2 Diferença entre processos e projetos.

Ao documentar e disseminar o PDP de uma empresa, a gerência está definindo


um padrão de como desenvolver os seus produtos. Esse padrão pode ser aplicado Projetos definidos a partir
pelas equipes e pelo gerente de cada projeto. Eles adaptarão as práticas descritas no de processos de negócios
modelo do processo conforme as necessidades do projeto. Com isso, cada projeto de
desenvolvimento “beberá na mesma fonte”, havendo, assim, uma linguagem comum e a garantia de que certas
práticas e ferramentas serão aplicadas em todos os projetos de desenvolvimento (veja a Figura 2.3).
Isso é muito importante porque cada projeto possui tarefas específicas, dependendo de inúmeras variáveis,
como a complexidade do produto, grau de inovação, tecnologia etc. O processo de desenvolvimento de pro-
dutos sistematizado e documentado permite que as particularidades de cada projeto e equipe de desenvolvi-
mento sejam atendidas e, ao mesmo tempo, garante-se a utilização das melhores práticas de projeto e um
linguajar padronizado e único para toda a corporação. Por exemplo, imagine que uma empresa possua na docu-
mentação de seu processo 50 atividades freqüentemente utilizadas na realização de um projeto. No início de um
novo projeto, pode-se adotar essas 50 atividades e, depois, eliminar algumas que não estão diretamente relacio-
nadas com o produto em questão e, ao mesmo tempo, adicionar outras atividades. Isso aumenta a qualidade e re-
petibilidade dos projetos de desenvolvimento de produtos. A partir desse momento, o desenvolvimento de um
produto particular é gerenciado como um projeto.
Para que o processo-padrão de desenvolvimento de produtos possa ser reutili-
zado por várias pessoas, ele é documentado na forma de um modelo.Um modelo Como representar o
serve para representar a realidade. No caso deste livro, ele representa um processo processo?
de desenvolvimento de produtos. Vários autores mostram o desenvolvimento de
produtos como uma seqüência de passos, fases, etapas, ou seja, na realidade, eles trazem modelos estruturados de
diversas formas. Como os projetos de desenvolvimento são definidos a partir desse modelo, ele é conhecido
como modelo de referência.
42 PARTE 1 O Processo

Figura 2.3 Projetos distintos resultantes de um mesmo processo.

Hoje, muitas empresas adotam modelos para definir qual o padrão de trabalho que elas desejam adotar para
o desenvolvimento de produtos. Existem modelos de diversos tipos; alguns representam somente quais ativi-
dades devem ser realizadas. Outros são mais detalhados e especificam procedimentos, métodos que devem ser
adotados, critérios de avaliação, e até conceitos e referências bibliográficas que precisam ser estudadas para que
uma pessoa realize uma determinada atividade.
Ou seja, o modelo é um documento que pode estar na forma de uma publicação, manual, ou mesmo na in-
2
tranet de uma empresa. O modelo que estamos apresentando neste livro está formatado como um manual e
também está na Internet para facilitar a navegação entre as diversas fases e visões.
Cada ator, que participa do desenvolvimento de produtos, enxerga o desenvol-
Modelo apresenta uma vimento de produtos segundo a sua percepção. O pessoal de marketing olha para o
visão unificada do processo de desenvolvimento de produtos como um todo, enfatizando as etapas ini-
desenvolvimento
ciais e finais do processo de negócio. Eles enfatizam as avaliações sobre o mercado
de produtos
e, dentro de um prazo, aguardam os produtos a serem oferecidos, assumindo o pro-
cesso de desenvolvimento de produtos como parte do processo de marketing. Os
engenheiros enxergam o desenvolvimento como um desafio tecnológico a ser vencido, e estão mais preocupados
em realizar as atividades técnicas, não possuindo, às vezes, um profundo conhecimento sobre as outras ativi-
dades, além de não terem uma maior preocupação com questões de gerenciamento do projeto. Pessoas envol-
vidas com a produção estão preocupadas com o impacto que vão sofrer com os novos produtos, e procuram
garantir a capacidade de entrega, deixando para um segundo plano as avaliações de como produzir. A área finan-
ceira não se importa com os aspectos técnicos, mas e somente com a avaliação do retorno monetário que o pro-
jeto trará para a empresa.
Poucos possuem uma visão do todo, e os gerentes de desenvolvimento, que teoricamente possuem essa
visão, não conseguem administrar os conflitos e, às vezes, se perdem na abrangência do projeto. De maneira
geral, as empresas não possuem uma visão unificada do processo. Além disso, o desempenho de cada unidade da
empresa e a diferença do escopo dos produtos não permitem que se tenha uma visão única do processo de desen-

2
Existem vários formalismos para a representação de processos de negócios, cuja apresentação fugiria do escopo deste livro. Para visão
geral desses formalismos, consultar: VERNADAT, F. B. Enterprise modeling and integration: principles and applications. Lon-
don: Chapman & Hall, 1996.
CAPÍTULO 2

O Modelo Unificado do PDP 43

volvimento de produtos. Muitas vezes, cada pessoa possui um entendimento próprio do processo e utiliza um
vocabulário e formalismo particular para descrevê-lo, advindos da sua área específica.
No dia-a-dia, essas limitações acarretam problemas e ineficiências no processo de desenvolvimento de pro-
dutos, dificultando a comunicação e integração entre os profissionais e as áreas envolvidas.
Modelos de referência surgiram para minimizar essas limitações. Eles descrevem
o processo de desenvolvimento de produto e servem de referência para que empresas e O que são modelos de
seus profissionais possam desenvolver produtos segundo um ponto de vista comum. referência?
Com um modelo de referência, pode-se obter uma visão única do processo de desen-
volvimento de produtos, nivelando-se os conhecimentos entre os atores que participam de um desenvolvimento es-
pecífico. Ele passa a ser um linguajar único na empresa, é um mapa que serve de base para todos (Figura 2.4).

Figura 2.4 Modelo de referência como mapa comum na empresa.

Este livro apresenta um modelo de referência genérico, com o objetivo de ser didático, mas ele também
pode ser utilizado para a criação de modelos de referência específicos para empresas.
Após essa discussão dos conceitos básicos sobre modelagem de processos, vamos apresentar uma visão geral
do seu conteúdo e estrutura.

2.2 Visão geral do modelo


O modelo deste livro é voltado principalmente para empresas de
manufatura de bens de consumo duráveis e de capital. Esse aspecto
será analisado em detalhes no Tópico 2.13. O importante agora é
notar que ele é dividido em macrofases, subdivididas em fases e ativi-
dades. Conforme apresentado na Figura 2.5, as três macrofases são:
Pré-Desenvolvimento, Desenvolvimento e Pós-Desenvolvimento.
As macrofases de pré- e pós-desenvolvimento são mais gené-
ricas e podem ser utilizadas em outros tipos de empresa com pe-
quenas alterações. A macrofase de desenvolvimento enfatiza os
aspectos tecnológicos correspondentes à definição do produto em
si, suas características e forma de produção. Portanto, tais ativi-
dades são dependentes da tecnologia envolvida no produto.
44 PARTE 1 O Processo

Figura 2.5 Visão geral do modelo de referência adotado neste livro.

O que determina uma fase é a entrega de um conjunto de resultados (delivera-


Caracterização de uma bles), que, juntos, determinam um novo patamar de evolução do projeto de desen-
fase do processo de
desenvolvimento de
volvimento. Os resultados criados em cada fase permanecerão “congelados”, a
produtos partir do momento em que a fase é finalizada. Por exemplo, ao término da fase de
projeto conceitual, um novo nível de evolução é atingido. Será o momento em que
uma ou mais possíveis soluções são escolhidas para ser detalhadas. Uma vez avaliadas como satisfatórias e apro-
vadas, o processo de desenvolvimento muda para um novo patamar: a fase do projeto detalhado. As informações
sobre a solução serão “congeladas”, ou seja, todas as pessoas podem acessá-la, mas não modificá-la. Qualquer
mudança acontecerá única e exclusivamente por meio de um processo de mudança controlado (como apresen-
tado no Capítulo 13, Tópico 13.1, “Gerenciamento de Mudanças de Engenharia”), o qual garantirá que o im-
pacto da mudança seja verificado e todos os atores que se utilizam daquele resultado sejam comunicados.
A avaliação dos resultados da fase serve também como um marco importante de reflexão sobre o anda-
mento do projeto, antecipando problemas e gerando aprendizado para a empresa. Ela deve ser realizada por
meio de um processo formalizado conhecido como transição de fase ou gate. Trata-se de uma revisão ampla e
minuciosa, considerando a qualidade dos resultados concretos obtidos, a situação do projeto diante do plane-
jado, o impacto dos problemas encontrados e a importância do projeto perante o portfólio completo (veja o con-
ceito ainda neste capítulo, posteriormente, no Tópico 2.7).
Para facilitar a apresentação, as fases são representadas de forma seqüencial,
Sobreposição entre porém, em projetos distintos, certas atividades de uma fase podem ser realizadas
atividades de diferentes
fases do modelo
dentro de outra fase. Por exemplo, a sobreposição esquematizada na Figura 2.6,
entre as fases do projeto conceitual e detalhado, é muito comum nos projetos deno-
minados “derivados”, isto é, em que são desenvolvidos produtos similares a pro-
dutos existentes — como acontece, por exemplo, nas reestilizações de modelos de
automóveis.
CAPÍTULO 2

O Modelo Unificado do PDP 45

Figura 2.6 Exemplo de sobreposição de atividades nas fases do processo de desenvolvimento de produtos.

Note que a atividade “Desenvolver Plano de Processo para os Componentes”, que no nosso modelo faz
parte do projeto detalhado, é iniciada ainda durante a fase de projeto conceitual. Isso é possível pelo fato de o
novo produto reutilizar um conjunto grande de peças do produto anterior; dessa forma, o processista já possui
conhecimento suficiente do produto para antecipar parte de suas atividades. Ele poderá iniciar seu trabalho
antes que a definição completa de todas as características e partes do produto seja concluída. Essa é a caracterís-
tica de paralelismo/simultaneidade, que é capaz de encurtar sobremaneira o tempo de desenvolvimento. Outro
exemplo de um produto derivado seria o de uma máquina de lavar, que é desenvolvida utilizando a mesma car-
caça, motorização e tambor de máquinas já desenvolvidas. Um novo projeto de desenvolvimento pode envolver
a criação de um sistema de controle do ciclo de lavagem, com componentes eletrônicos, software de controle e
componentes para admissão e expulsão de água, com o objetivo de diminuir o ciclo de lavagem e aumentar a eco-
nomia de água. Nesses casos, pode-se efetuar cálculos de simulação da aplicação do produto na fase de projeto
conceitual, embora essas sejam atividades típicas da fase de projeto detalhado. Poderia existir, também, um pro-
grama de simulação do processo de lavagem, ferramenta típica da fase de projeto detalhado. Se a empresa esti-
vesse desenvolvendo uma nova máquina, sem mexer na tecnologia da lavagem, poderíamos utilizar esse
programa na fase de projeto conceitual. Assim, testaríamos as diversas alternativas, verificando se os tempos de
lavagem diminuiriam, mantendo-se a sua qualidade. Nesses casos, diminuiríamos o escopo e o tempo de desen-
volvimento do projeto detalhado, pois muitas atividades poderiam ser adiantadas e realizadas durante o projeto
conceitual.
Deve-se ressaltar também uma diferença fundamental entre o pré-desenvolvi-
mento, particularmente a fase de Planejamento Estratégico de Produtos, e as de- A fase de Planejamento
mais macrofases e fases. Como já visto, cada desenvolvimento de um produto Estratégico de Produtos
envolve vários produtos
específico torna-se um projeto único. Na Figura 2.7 é mostrado o aspecto da quan-
tidade de produtos relacionada com cada macrofase, explicado nos parágrafos se-
guintes.
Na fase de planejamento estratégico, são consideradas as estratégias de mercado da empresa e também as
tecnológicas (veja o Tópico 2.4.2, posteriormente, neste capítulo). O planejamento dos produtos envolve todo o
conjunto de produtos da empresa e sua relação com os mercados que se deseja atingir (na Figura 2.7, mercados
A, B, C e D). Para cada mercado, define-se um conjunto de produtos (na Figura 2.7, os pontos dentro do qua-
drado). Esse conjunto é conhecido como portfólio de produtos da empresa, e está intimamente ligado com o
planejamento estratégico da empresa, como mostra o Tópico 2.4.2. O portfólio contém os produtos em planeja-
mento, os em desenvolvimento e aqueles que já estão sendo comercializados.
O objetivo é manter um conjunto de produtos capaz de atender a todas as necessidades dos clientes.
46 PARTE 1 O Processo

Figura 2.7 Relação das macrofases do modelo e a quantidade de produtos.

Os produtos definidos no portfólio são desenvolvidos por meio de projetos (na


As demais fases Figura 2.7, projetos C1 a C6 para os respectivos produtos C1 a C6 do portfólio vol-
relacionam-se com um tado ao mercado C). Esses projetos estão em diferentes estágios de desenvolvi-
produto em particular
mento (na Figura 2.7, o projeto C1 está sendo finalizado; o C2 está congelado; o C3
está no meio do desenvolvimento; o C4 está sendo lançado e entrando no mercado;
o C5 foi cancelado e o C6 está no início do desenvolvimento).
Ou seja, as demais fases do desenvolvimento relacionam-se com um produto em particular por projeto de
desenvolvimento: aquele (ou aqueles) que o planejamento estratégico mostrou ser atrativo (ou serem atrativos) o
suficiente para a empresa gastar dinheiro no seu desenvolvimento. A quantidade de projetos paralelos depende
da capacidade da empresa. Esse é o portfólio de projetos, o qual representa um subconjunto do portfólio de pro-
dutos, que também contém os produtos existentes no mercado.
Tal conceito é conhecido como “funil” por vários autores. O princípio é que, no início, um número grande
de idéias se transforme em um número menor de projetos especificados no portfólio, o qual, por sua vez, gerará
um número menor ainda durante o desenvolvimento — pois a capacidade da empresa limita o desenvolvimento
paralelo de muitos produtos — e, finalmente, apenas alguns produtos serão lançados; todos eles viáveis e com
3
grande probabilidade de sucesso no mercado.
A fase de planejamento do projeto trata do desenvolvimento de um produto em particular do portfólio —
em que o escopo do produto e do projeto, os recursos necessários, o tempo e o custo são definidos em detalhes.4
Se esse planejamento for aprovado, o projeto tem início na macrofase subseqüente. As fases de desenvolvimento
são equivalentes às fases de um projeto, cujo término (fechamento do projeto) culmina com o lançamento do
produto no mercado.
Após o lançamento do produto, inicia-se sua produção e comercialização sob a responsabilidade de outros
processos de negócio da empresa, assim como de outras áreas e pessoas. Normalmente, o time de projeto é dis-
solvido, e seus membros são alocados para outros projetos ou retornam para as suas áreas funcionais. Porém, o
processo de desenvolvimento de produtos ainda não terminou, pois é necessário um esforço de acompanha-
mento do produto durante todo seu ciclo de vida. Durante a fabricação, esse esforço será o de garantir a reali-

3
Leia sobre o conceito de funil no Tópico 2.4.2, e observe a Figura 2.12, ambos posteriormente, neste capítulo.
4
Essa é uma visão simplificada do conteúdo do planejamento do projeto. Leia o Capítulo 5 para ter conhecimento sobre o conteúdo
completo dessa fase.
CAPÍTULO 2

O Modelo Unificado do PDP 47

zação de mudanças para aprimorá-lo ou reparar defeitos identificados. Esse é o momento de se preocupar com a
assistência técnica e o atendimento ao cliente. É aí que surgem oportunidades de melhoria no produto, as quais,
por sua vez, devem ser gerenciadas de forma organizada para garantir a integridade das informações durante
todo o ciclo de vida do produto. Em seguida, será preciso apoiar a descontinuação do produto, isto é, sua retirada
do mercado. Em alguns casos, como bens de consumo duráveis e bens de capital, esse acompanhamento irá se
estender enquanto houver clientes utilizando o produto. Veja o exemplo das aeronaves, que necessitam de uma
equipe de manutenção e melhorias muitos anos após o término da sua produção, isto é, enquanto existirem pro-
dutos sendo utilizados pelas companhias aéreas.
Em alguns casos, também, a macrofase de pós-desenvolvimento ficará a cargo de outros responsáveis, mas,
no modelo que desenvolvemos, essa macrofase está relacionada com as anteriores, pois acessa e dá manutenção
às mesmas informações anteriormente criadas. Além disso, nesse momento, aprende-se muito com o mercado, e
essas lições devem ser consideradas pela empresa para não repetir os mesmos erros no futuro.
Um outro aspecto a ser destacado é a temporalidade usual dessas fases em um
ciclo de vida de um produto, como mostra a Figura 2.8. O pré-desenvolvimento leva Duração das macrofases
dias e pode estar associado ao ciclo do planejamento estratégico das empresas, que do modelo
normalmente é realizado uma vez por ano. O desenvolvimento em si varia muito de
acordo com a complexidade do produto e a novidade que ele representa para a empresa, mas, tipicamente para
empresas de manufatura discreta e para os tipos de produtos tratados neste livro, ele leva meses.

Figura 2.8 Exemplo da duração típica das macrofases do modelo.

A macrofase de desenvolvimento de uma máquina com novos conceitos, como uma máquina-ferramenta
ou mesmo uma nova copiadora, leva de 15 a 30 meses. Já uma máquina desenvolvida com base em uma existente,
situa-se entre 6 a 10 meses. Um automóvel tipicamente levava de 36 a 48 meses e hoje leva de 15 a 25 meses.
Uma copiadora que seja continuação de uma existente demora de 3 a 6 meses. Finalmente, a fase de pós-desen-
volvimento dura até o final da vida do produto. Esse período tem diminuído ultimamente, mas, no setor de má-
quinas-ferramentas, o período de produção/comercialização dura em média 5 anos. E, depois, as máquinas
ainda são utilizadas por anos. No caso do setor automobilístico, um mesmo produto pode ficar no mercado 10
anos, sofrendo pequenas mudanças estéticas e tecnológicas. Mesmo assim, a empresa precisa garantir a assis-
tência técnica por vários anos após o encerramento de sua produção.
Na Figura 2.9 estão mencionados os principais resultados produzidos ao final
de cada uma das fases do modelo. A fase de planejamento estratégico de produtos, Principais resultados
que não consta na figura, resulta em dois documentos principais. Um deles é o port- das fases
fólio de produtos com a descrição de cada um dos produtos e datas de início de de-
senvolvimento e lançamento, segundo as perspectivas de mercado e tecnológicas. O segundo é o primeiro
documento que diz respeito a um projeto específico e é o primeiro apresentado na Figura 2.9: a Minuta do Pro-
jeto. Ela contém a primeira descrição do produto — algo bastante sucinto e que delimita o projeto. Esse docu-
mento serve de entrada para a fase de planejamento do projeto, que produzirá um plano detalhado com
atividades, prazos, recursos necessários, riscos e uma primeira análise econômico-financeira do projeto, con-
forme apresentado na Figura 2.9.
48 PARTE 1 O Processo

Figura 2.9 Principais resultados das fases.

A primeira fase de desenvolvimento, o projeto informacional, cria, a partir do Plano do Projeto, as Especifica-
ções-Meta do futuro produto, que são aquelas que se deseja obter no final das atividades de engenharia, com-
postas pelos requisitos e pelas informações qualitativas sobre o futuro produto. Em seguida, na fase de
concepção do produto, soluções de projeto são geradas e estudadas detalhadamente até se encontrar a melhor
solução possível que seja capaz de atender às Especificações-Meta concebidas na fase anterior. As soluções de pro-
jeto são resumidas em um conjunto de documentos, listados na Figura 2.9, e que receberá o nome de Concepção do
Produto. Nessa fase, o time de desenvolvimento pode estar lidando com uma concepção única, selecionada entre
as alternativas definidas, ou mais de uma em paralelo, até que, após a realização do primeiro ciclo de detalha-
mento, também conhecido como projeto preliminar5, seja adotada somente uma das concepções.
Na fase de Projeto Detalhado, a Concepção do Produto será detalhada e transformada nas Especificações Finais,
que podem abranger uma ampla gama de documentos, detalhando cada item que o compõe e os respectivos pro-
cessos de fabricação, conforme apresentado no detalhe da Figura 2.9. Outros documentos serão gerados
também como Protótipo funcional, Projeto dos recursos, como dispositivos e ferramentas, e o Plano de fim de vida, o
qual estabelece condições para a descontinuidade e a reciclagem dos produtos. O protótipo é aprovado, o pro-
duto pode ser homologado e as especificações finais são congeladas.
Durante a preparação da produção, o produto é certificado com base nos resultados dos lotes piloto. Isso
significa que os testes são feitos com produtos fabricados com peças oriundas da linha de produção. Acontece,
também, a homologação da produção, culminando com a sua liberação. Esse é um documento oficial, no qual a
empresa comunica que o produto começa a ser produzido em série (quando for o caso). A lista de documentos
principais dessa fase é descrita na Figura 2.9. Em seguida, ocorre a fase de lançamento do produto, que termina
com a emissão do documento oficial de lançamento, cujos documentos principais também estão presentes na Fi-
gura 2.9.

5
Veja a discussão no início do Capítulo 8, no Quadro 8.3, “Projeto Preliminar entre o Projeto Conceitual e o Projeto Detalhado”.
CAPÍTULO 2

O Modelo Unificado do PDP 49

Agora que acabamos de ter uma visão geral das macrofases e de seus principais resultados, vamos definir
qual a organização responsável pelo desenvolvimento de produtos, pois ela será utilizada ao longo de todo este
livro. Para que o processo de desenvolvimento de produtos possa ser realizado, é necessário que exista uma di-
visão de responsabilidades entre os participantes do desenvolvimento, apresentada no próximo tópico.

2.3 Os papéis principais das pessoas envolvidas no PDP


As macrofases, fases e atividades descrevem o que deve ser
feito para o desenvolvimento do produto, mas quem deve ser o
responsável pelas etapas de desenvolvimento de produtos? A res-
posta a essa pergunta está na identificação dos papéis. No Capí-
tulo 1, foi possível conhecer os conceitos básicos sobre organização
para o desenvolvimento de produtos. Foram apresentadas dife-
rentes estruturas organizacionais possíveis, as quais podem ser
mais ou menos adequadas, dependendo das características da em-
presa e de seus produtos. Em cada arranjo, as responsabilidades
pelas atividades do PDP são divididas de maneira diferente dentro
da organização. O que significa que teríamos que tecer a relação
entre as atividades do PDP e cada um dos diferentes tipos de es-
trutura organizacional. Para facilitar a compreensão e simplificar
a apresentação do modelo, faremos esse relacionamento por meio do conceito de papel. Cada papel representa
uma determinada responsabilidade e tipo de atuação dentro do PDP. Portanto, durante a apresentação do mo-
delo, iremos sempre nos referir aos papéis, os quais poderão ser atribuídos de maneira diferente, conforme a es-
trutura organizacional específica da empresa.
O objetivo deste tópico é apresentar o conjunto-padrão de papéis organizacionais que serão utilizados
como referência na descrição das atividades do modelo de referência unificado. Partimos também das premissas
de que a empresa adota o conceito de time de desenvolvimento (independentemente de a organização ser matri-
cial ou por projetos) e pratica a gestão por processos, sem a qual não haveria sentido em dizer PDP.
O modelo de referência do PDP de uma determinada empresa descreverá os
elementos específicos do processo, isto é, as atividades, documentos utilizados, sis- Os papéis são a ligação
temas, pessoas envolvidas, entre outros fatores, para que o resultado do processo entre a estrutura
organizacional e as
possa ser alcançado. Em relação ao aspecto da estrutura organizacional, isso signifi- atividades do modelo de
ca que o modelo pode conter os nomes específicos dos departamentos, áreas, cola- referência unificado
boradores e até das pessoas responsáveis pelas atividades. Já em um modelo
genérico, como o deste livro, isso é impossível, pois os nomes das pessoas, cargos ou mesmo a definição da estru-
tura organizacional não existem. A solução encontrada foi a de identificar papéis. Cada papel é um conjunto de
atribuições e responsabilidades que podem ser assumidas por um determinado ator. Por exemplo, utilizaremos o
título gerente de projetos para identificar a pessoa cujas responsabilidades incorporem a de coordenar e controlar o
desenvolvimento. Especialistas são aqueles responsáveis pela execução de atividades técnicas específicas de apoio
ao time de projeto. Em uma empresa grande, por exemplo, esses papéis podem ser delegados para cargos dis-
tintos; conseqüentemente, pessoas distintas estariam assumindo cada um dos papéis. Já em uma pequena organi-
zação, uma única pessoa pode assumir ambos os papéis durante o desenvolvimento.
Os papéis definidos e referenciados no modelo unificado de PDP são:
Papéis e suas
I Membros da diretoria: eles reúnem o conjunto de responsabilidades refe- responsabilidades no PDP
rentes ao planejamento, aconselhamento e auditoria das atividades e deci-
sões tomadas pelo agente executivo da organização ou unidade de negócio, quando existirem. Esse papel
é comumente delegado para os cargos nomeados, tais como: diretor de marketing, fabricação, desenvol-
vimento etc. Eles são os patrocinadores do PDP e definem as estratégias que norteiam o planejamento
estratégico de produto. Podem participar das revisões de fase de algum projeto de desenvolvimento im-
50 PARTE 1 O Processo

portante, trazendo a visão estratégica para comparar o projeto em avaliação, perante todo o portfólio e
oportunidades existentes.
I Gerente funcional: responsável por uma função específica da empresa, tais como: financeira, vendas,
marketing, engenharia, laboratórios de protótipos, oficinas, assistência técnica, suprimentos e pro-
dução. Varia muito de empresa para empresa.
I Responsável pela engenharia: pessoa que responde pelos recursos específicos da área de engenharia. Em
algumas empresas, esse papel é assumido pelos cargos de diretor de desenvolvimento ou de engenharia.
Em empresas maiores, pode existir um gerente de engenharia responsável pela linha de produtos com
recursos próprios. Em empresas pequenas, pode ser um diretor ou mesmo o presidente ou dono da em-
presa. Seu papel é ser responsável pelos recursos de engenharia a serem utilizados pelos projetos de de-
senvolvimento.
I Gerente de projetos: responsável por um projeto específico de desenvolvimento e líder de um time de
desenvolvimento. Em geral, possui o conhecimento técnico para gerenciar o desenvolvimento, mas,
principalmente, deve ter as habilidades e os conhecimentos de gestão de projetos. Muitas vezes, um ge-
rente é auxiliado por pessoas que tratam da consolidação de dados de controle de projeto, uso de sis-
temas de gestão, ou administração de recursos. Essas pessoas podem fazer parte de um escritório de
projetos, que presta serviço para mais de um projeto, com o objetivo de compartilhar recursos entre
os projetos.
I Especialistas: pessoas de determinadas áreas funcionais da empresa ou mesmo de empresas de consul-
toria que possuem um domínio sobre tecnologias empregadas do produto e processo de fabricação, ou
sobre os métodos de trabalho (cálculo estrutural, injeção plástica, sistemas de controle, integração de
hardware etc.).
I Parceiros: são pessoas de empresas parceiras, que podem contribuir nas mais diversas áreas de conheci-
mento (veja os tipos de parceiros no Tópico 2.10).
I Time de planejamento estratégico de produto: responsável pelo desdobramento do planejamento estra-
tégico em portfólio de produtos da empresa (veja o Tópico 2.4.2). Pode ser constituído pelos membros
da diretoria ou os gerentes funcionais.
I Time de desenvolvimento: responsável por um projeto específico de desenvolvimento. Pode envolver
pessoas de diversas áreas da empresa, especialistas, assim como parceiros. A cada estágio do projeto, ele
pode ser composto por membros diferentes (mais pessoas de marketing no início, de engenharia nas
fases de projeto, de produção e marketing novamente no final).
I Time de avaliação: responsável por aprovar a continuidade do projeto após uma revisão da fase (veja
uma explicação mais detalhada no Tópico 2.7). Membros da diretoria, gerência, especialistas e convi-
dados podem fazer parte desse time.
I Time de acompanhamento do produto: é aquele que fica responsável pelo produto ao longo do seu ciclo
de vida, após o término da macrofase de desenvolvimento. Os integrantes desse time não se dedicam in-
tensamente ao produto. Participam de outros projetos ou tarefas operacionais, mas detêm o conheci-
mento sobre o produto desenvolvido e podem ser chamados a qualquer momento para analisar situações
de desvio e propor mudanças, a serem direcionadas ao processo de apoio de Gerenciamento de Mudanças
de Engenharia (veja o Capítulo 13, Tópico 13.1, “Gerenciamento de Mudanças de Engenharia”).

O leitor não deve confundir a existência desses papéis com a necessidade da criação
Adaptação dos papéis de cargos ou funções na empresa. A estrutura organizacional precisa ser enxuta e
definidos a cada tipo adequada à situação específica de cada empresa, como vimos no Capítulo 1. O im-
de empresa
portante é verificar se cada um dos papéis citados está contemplado dentro da estru-
tura organizacional definida na empresa. Pois, assim, ao se criar um modelo de
referência específico a partir desse modelo genérico, será possível mapear o elemento da organização (departa-
mento, área, divisão), o qual deverá ser responsável por cada um dos papéis. Caso esse mapeamento identifique
que um determinado papel não foi atribuído a ninguém, isso pode significar que aquelas atividades do modelo
CAPÍTULO 2

O Modelo Unificado do PDP 51

estejam sem um responsável bem definido e não estejam formalizadas, sendo um indício de disfunção ou pro-
blema em uma determinada área do processo do PDP.
A Figura 2.10 demonstra esquematicamente essa idéia. O organograma de duas empresas fictícias é apre-
sentado. A primeira delas, a Empresa A, possui uma estrutura mais complexa com três níveis, diretorias, gerên-
cias funcionais e o terceiro com analistas e técnicos. Trata-se de uma estrutura matricial na qual representantes
das áreas funcionais se unem nos times. O segundo caso representa a estrutura típica projetada de empresas mé-
dias de desenvolvimento. Há uma gerência para a engenharia, e os técnicos e analistas reportam diretamente ao
gerente/diretor. O número de níveis organizacionais é de apenas dois. Enquanto os papéis de Membro da Dire-
toria e Responsável pela Engenharia são atribuídos à mesma pessoa na Empresa B, eles são delegados para pes-
soas diferentes no caso da Empresa A.

Figura 2.10 Relação da visão organizacional entre o modelo de referência e o específico.

2.4 Visão geral da macrofase de pré-desenvolvimento


2.4.1 Por que pré-desenvolvimento?
Tradicionalmente, quando se pensa em desenvolver pro-
dutos, a primeira coisa que vem à mente são os requisitos e dese-
nhos. Basta decidirmos quem é o cliente e definir com ele o que
temos que desenvolver, certo? É preciso começar muito antes de
tudo isso.
Imagine agora uma empresa
qualquer, por exemplo, uma pequena Primeiro reunir idéias e...
empresa que produza bebedouros.
Suponha que ela possua 15 pessoas na engenharia, 5 na área de
vendas e mais os seus diretores, 4 ao todo. Eles lêem revistas espe-
cializadas, conhecem o que seus competidores estão fazendo, vi-
sitam feiras e eventos científicos especializados e conversam com
vários clientes. Ao final, teremos 24 pessoas dando idéias de pro-
dutos que poderiam ser desenvolvidos, tanto novos bebedouros
52 PARTE 1 O Processo

como produtos similares, pequenas geladeiras etc. Imagine que essa empresa possui 8 grandes distribuidores
que trazem do campo reclamações e sugestões, os quais também podem conter excelentes idéias para novos pro-
dutos. Sem contar o novíssimo telefone 0800 e os relatórios da sua rede de assistência técnica. Tudo isso permi-
tindo mais idéias de novos projetos de desenvolvimento.
Esse mundo de oportunidades é claramente inesgotável. Porém, estamos no
...avaliar as restrições mundo real onde não existem apenas oportunidades — nele é preciso considerar as
existentes restrições. A primeira delas é o capital. Desenvolver um novo produto significa in-
vestir em um negócio e uma empresa real, com riscos envolvidos. Por maior que seja
a empresa, a capacidade de investimento é limitada. Mesmo se essa capacidade fosse infinita, há restrições físicas,
institucionais e de capacitação de pessoal. Alguns exemplos: nada adianta dinheiro se você não puder aumentar
rapidamente sua capacidade de produção, se não possuir fornecedores capazes de entregar peças ou maté-
rias-primas a preços competitivos, se você não possuir mão-de-obra com experiência nas tecnologias daquele
determinado produto, se não tiver acesso a uma rede de distribuição para o seu produto etc.
Portanto, unindo ambos os lados da moeda, temos uma equação que precisa
Priorizar os projetos de ser resolvida: quais projetos de desenvolvimento priorizar, considerando as restri-
acordo com a estratégia ções de capital, tecnologia e competências? Para iniciarmos a solução desse
da empresa
quebra-cabeça, você já deve ter notado que faltou algo: Estratégia Competitiva.
Isto é, decidir o que será desenvolvido passa por resolver essa questão, considerando
os objetivos que a empresa espera conseguir no futuro e como deseja atingi-los. Portanto, não é mais possível con-
ceber o processo de desenvolvimento de produtos sem que ele esteja ligado à Estratégia Competitiva da Empresa.
O pré-desenvolvimento deve garantir que o direcionamento estratégico, defi-
Então a missão do nido a priori pela empresa no Planejamento Estratégico da Corporação, as idéias de
pré-desenvolvimento é... todos os atores internos e externos envolvidos com os produtos, e as oportunidades
e restrições sejam sistematicamente mapeados e transformados em um conjunto de
projetos bem definidos, isto é, o portfólio dos projetos que deverão ser desenvolvidos.
E é no planejamento detalhado de cada um desses projetos que se deve definir com clareza o seu escopo, ga-
rantindo-se uma integração com os direcionamentos estratégicos. As principais análises sobre o projeto são rea-
lizadas para decidir se realmente o que foi definido no planejamento estratégico tem chance de acontecer. No
final do planejamento, é decidido se o desenvolvimento do produto deve continuar ou não.
Para entendermos melhor a diferença entre essas fases, precisamos entrar em consenso sobre alguns con-
ceitos básicos de planejamento estratégico.

2.4.2 Conceitos básicos do processo de planejamento estratégico


O processo de planejamento estratégico é um processo gerencial, isto é, seu re-
Processo de planejamento
sultado final não agrega valor diretamente ao cliente. Ele obtém informações que
estratégico e o orientam os demais processos de negócio da organização, incluindo o Processo de
desenvolvimento
de produto
Desenvolvimento de Produtos (PDP). Esse tema é vasto por si só e mereceria um
livro à parte, caso essa questão fosse aprofundada.6 De maneira simplificada, po-
demos considerar que desenvolver uma estratégia para uma organização é responder a um conjunto de questões:

1. Onde estamos?
2. Para onde vamos?
3. Como chegaremos lá?
4. Temos capacidade para realizar isso?
5. Como saberemos se estamos chegando lá?

6
Para uma definição mais apropriada, recomenda-se a leitura de MITZENBERG, AHLSTRAND e LAMPEL (2000).
CAPÍTULO 2

O Modelo Unificado do PDP 53

Transportando essas perguntas para o universo de uma empresa, é possível perceber que elas podem ser
aplicadas em diferentes níveis. De maneira didática, podemos identificar três deles, descritos na Figura 2.11.

Figura 2.11 Níveis de planejamento estratégico.

Como exemplo, imagine que uma empresa produza vários tipos de equipa-
mentos para impressão, atendendo, a partir de várias fábricas, diferentes tipos de Um exemplo para
clientes: o profissional que possui uma impressora no escritório de sua casa, escritó- entendermos o
desdobramento do
rios de empresas e gráficas. O conjunto dessas fábricas e unidades administrativas é planejamento estratégico
o que poderemos chamar de corporação. As características dos consumidores finais
citados são muito diferentes. Um comprador doméstico, na maioria das vezes leigo
em informática, precisa de um catálogo de informações simples e que consiga orientá-lo facilmente na aquisição
do produto, sem que ele precise se tornar um especialista. Ele mede a qualidade do produto de uma maneira di-
ferente também, considerando impressões, sentimentos transmitidos pelo produto e indicações do vendedor e
de pessoas conhecidas. São muitos clientes, e o volume de vendas será alto, portanto, as margens em cada pro-
duto tendem a ser pequenas, inviabilizando a personalização do atendimento. Por outro lado, o consumidor grá-
fico realizará uma compra altamente técnica, discutindo cada especificação e detalhe do equipamento e
avaliando o retorno financeiro que terá com o produto. Ele exigirá a presença de um profissional da assistência
técnica tanto antes quanto após a compra, em um atendimento altamente especializado. A quantidade de consu-
midores nesse mercado7 é menor, porém com equipamentos de maior valor agregado. Deve-se vender poucos
itens, mas a margem de lucro e faturamento em cada um deles será significativamente maior. Os canais de distri-
buição, isto é, a forma como o produto chega ao cliente é também muito diferente. Portanto, seria muito difícil,
ou mesmo impossível, atendê-los com a mesma estrutura organizacional. A melhor forma de lidar com essa si-
tuação seria criar estruturas organizacionais distintas, chamadas de unidades de negócio. Apesar de ser a mesma
tecnologia de produto e processo envolvida no produto, tais unidades funcionam como se fossem empresas dis-
tintas. Cada uma delas com número de funcionários, competências e procedimentos específicos, adequados às
especificidades do mercado que atendem.
É assim que a maioria das empresas, que atuam em diferentes ramos, opera de forma a manter seu tamanho
sem comprometer a eficiência. Um exemplo é a General Eletric, que fabrica desde lâmpadas, eletrodomésticos
até turbina de aviões e equipamentos médicos. Certamente, seria impossível gerenciar essa que é considerada a
maior empresa do planeta sem essa estrutura organizacional.

7
Neste livro, estaremos utilizando bastante a palavra mercado, que, no senso comum, pode ser interpretada de diferentes maneiras.
Deve-se entender mercado pelo conjunto de consumidores potenciais de um produto ou serviço. Para mais detalhes, veja KOTLER
(2001).
54 PARTE 1 O Processo

No caso da empresa de exemplo, poderiam existir no mínimo três unidades de negócio: impressoras para
uso doméstico; impressoras para escritório; e impressoras de alto desempenho para gráficas. Serviços especiali-
zados, comuns a todas elas e capazes de serem prestados como consultoria, tais como o RH e a infra-estrutura de
tecnologia de informação, seriam candidatos também a se transformar em unidades de negócio. A diferença é
que essas unidades seriam voltadas para o atendimento das outras três, isto é, seriam unidades da corporação vol-
tadas para apoio. Dessa forma, as organizações mantêm estruturas operacionais adequadas a cada mercado e di-
videm os custos dos serviços comuns entre elas. Para este livro, o que interessa saber é que cada unidade opera
com uma estrutura organizacional, objetivos e pessoal próprios. Além de facilitar e garantir a adequação do fun-
cionamento da empresa, conforme as necessidades de cada mercado, a aplicação desse conceito permite dimi-
nuir riscos, pois a verificação do desempenho da corporação em cada nicho do mercado torna-se transparente,
facilitando a ação dos executivos.
Voltando ao planejamento estratégico, o exemplo da empresa de impressoras ajuda a entender a diferença
entre os níveis de abstração na estratégia de uma empresa.
A estratégia no nível corporativo precisa responder sobre os rumos da corpo-
Planejamento Estratégico ração como um todo, incluindo todas as unidades de negócio. Onde a corporação
da Corporação (PEC) está em termos de capitalização, desempenho, presença física, acionistas etc.? Qual
a missão dessa corporação, isto é, aonde vamos? No “como chegaremos lá”, preci-
samos responder em quais unidades de negócio a empresa deve investir ou não. Isso significa decidir se a corpo-
ração deve reinvestir a receita de cada unidade de negócio ou transferi-la para uma delas — eventualmente mais
importante para a concretização da missão da corporação. Por exemplo, um novo nicho de impressoras para fo-
tografia digital caseira poderia se fortalecer, justificando o direcionamento de receitas da unidade de impressoras
para gráficas para a unidade de negócio de consumidores domésticos, ampliando o investimento da corporação
nesse novo negócio. Significa também rever a própria divisão entre as unidades mencionadas.
O perfil dos consumidores em termos de comportamento e hábitos pode mudar, consolidando novos
grupos com características diferentes. No processo de planejamento da estratégia corporativa, a eventual inade-
quação da estrutura de unidades de negócio precisa ser identificada, e propostas de novas segmentações devem
ser desenvolvidas. Por exemplo, o crescimento da capacidade, da confiabilidade e da facilidade de uso das im-
pressoras pode tornar as características de compra dos mercados domésticos e de escritórios muito parecidas.
Nesse caso, a corporação poderia optar por unificar as duas unidades. Mas a empresa tem capacidade para rea-
lizar isso? Para responder a essa pergunta, é preciso identificar as restrições e os riscos para a adoção das soluções
identificadas no passo anterior. Ao final, deve-se desenvolver metas para o desempenho da corporação. Em
suma, isso significa definir objetivos específicos que cada unidade de negócio precisa atingir, para que as metas
da corporação sejam atingidas. O Planejamento Estratégico da Corporação é o primeiro passo do planejamento
estratégico.
Uma vez definido o papel e as metas de cada unidade de negócio, deve-se deta-
Planejamento Estratégico lhar como será a estratégia de ação da unidade de negócio em si. As perguntas gené-
da Unidade de Negócios ricas são as mesmas, porém as decisões e os problemas enfrentados são distintos.
(PEUN)
Esse plano estratégico deve começar pela análise da situação da unidade de negócio
em questão, sua participação no mercado em que atua, faturamento, satisfação dos
clientes diante da concorrência etc. A preocupação é, portanto, de natureza mais tática. Quais os desafios da uni-
dade de negócio no nicho em que atua e como ela enfrentará a concorrência de maneira a atingir as metas pre-
vistas para essa unidade no Planejamento Estratégico da Corporação, considerando a previsão de investimentos
e restrições internas e externas. Os gestores da unidade de negócio precisam segmentar o mercado e identificar
inicialmente qual o desempenho, não apenas financeiro, como no planejamento corporativo, mas também em
termos de eficiência e eficácia dos produtos e processos (logística, entrega, compras etc.) e percepção dos clien-
tes, fornecedores e colaboradores — expressa no nível de satisfação.
Em seguida, é preciso identificar suas competências essenciais e realizar a melhor previsão possível sobre as
tendências tecnológicas e de mercado. A consideração desse conjunto grande de informações permite identificar
as forças e também as fraquezas da empresa. Feito isso, pode-se pensar no “como”. Na estratégia corporativa, o
CAPÍTULO 2

O Modelo Unificado do PDP 55

“como” estava relacionado a discutir em qual unidade (no fundo, mercado) a empresa deve ampliar ou reduzir
sua participação. Na unidade de negócio, é preciso identificar em quais segmentos de mercado a empresa deve
apostar e como superar a concorrência em cada um deles. Nesse nível de planejamento, portanto, deve-se ir
fundo nos detalhes, identificando a forma de superação, ou seja, que ganhos em termos de características de pro-
dutos e processos precisam ser obtidos para que haja superação suficiente para atingir as metas de desempenho.
Pode ser menor custo, condições de entrega, diferenciação em atributos, tais como: desempenho, design etc.
Além da estratégia em termos de concorrência, deve-se discutir estratégias em relação à cadeia de valor. Isto é, a
unidade de negócio pode crescer sua participação no segmento de mercado, agregando operações realizadas
pelos fornecedores ou em mercados de seus atuais clientes.
No caso da unidade de negócio doméstico do nosso exemplo, a estratégia poderia ser a de crescer no sen-
tido da diferenciação dos produtos em termos de aparência e sofisticação tecnológica. Essa decisão depende, lo-
gicamente, de toda a informação prospectada. Pode ser que a empresa tenha como força uma equipe com alta
competência técnica e uma marca premium, isto é, valorizada pelo consumidor. Como fraqueza, uma dificuldade
de penetração e presença em pontos-de-venda. Essa estratégia exploraria os aspectos positivos, as forças da em-
presa — como a marca e a competência —, transformando-os em um diferencial nos pontos-de-venda, em que,
com custo similar ao do concorrente, esses fatores decidiriam a compra em favor da empresa.
Uma vez definida a estratégia, deve-se avaliar a capacidade da unidade de negócio, em termos de riscos e
restrições, quanto à operacionalização da estratégia. Ao final, metas e indicadores de desempenho, específicos
para a unidade de negócio, precisam ser definidos. Indicadores são fundamentais para o acompanhamento da
implementação da estratégia e para avaliar, ao final do período, se os objetivos foram atingidos.
O último nível de planejamento estratégico é o de produto. Ele é realizado a
partir do Planejamento Estratégico da Unidade de Negócios e se relaciona forte- Planejamento Estratégico
mente com o anterior. Na maioria das vezes, acontece simultaneamente. É aquele de Produtos (PEP)
em que se determina a estratégia em relação às linhas de produto. Na prática, isso é
feito por meio do desdobramento do portfólio, ou carteira de projetos, a partir da estratégia da unidade de negó-
cio. As mesmas questões gerais anteriormente apresentadas são válidas para esse planejamento.

Quadro 2.1 Estratégia Tecnológica

Para autores clássicos em planejamento estratégico, como Porter (1980), a estratégia tecnológica é o enfoque que a em-
presa adota para o desenvolvimento e uso da tecnologia, constituindo um ingrediente essencial de sua estratégia competi-
tiva. Ou seja, objetiva orientar a empresa na aquisição, desenvolvimento e aplicação da capacidade tecnológica para
obtenção da vantagem competitiva. Wheelwright & Clark (1992) consideram que uma estratégia tecnológica deve contem-
plar o foco, as fontes de capacitação e o momento e freqüência de implantação das inovações.
Primeiro, deve ser definido o foco de mudança ou desenvolvimento técnico. A tecnologia deve incluir o know-how neces-
sário para a empresa criar/desenvolver, produzir, vender seus produtos e distribuí-los aos consumidores. Uma parcela desse
conhecimento pode estar apoiada na experiência acumulada da empresa ou pode ter origem no conhecimento científico ou
nas atividades de P & D na área. Embora o conhecimento técnico possa ter diferentes origens e assumir diferentes formas, o
mais relevante para a capacidade competitiva é a capacitação técnica da empresa — sua habilidade em utilizar esse
know-how para obter resultados interessantes em seus produtos e processos.
O segundo aspecto crítico da estratégia tecnológica diz respeito às fontes de capacitação. Essa pode ser desenvolvida in-
ternamente, por meio de investimentos em recursos humanos, equipamentos, laboratórios e metodologias, ou por meio de
projetos de desenvolvimento avançado. Entretanto, a tecnologia pode também ser adquirida externamente, por meio de
contratos de pesquisas com universidades, joint ventures, licenciamentos ou compras de pacotes tecnológicos.
Essas duas fontes não são mutuamente exclusivas, e a definição do mix de fontes internas e externas é um dos aspectos
críticos da estratégia tecnológica. Ainda que uma das fontes possa ser dominante, a outra geralmente também desempenha
papel importante. Mesmo nos casos em que a fonte principal é externa, a empresa necessita de capacitação interna para ava-
liar as tecnologias disponíveis no mercado e integrá-las à sua realidade. Assim, as questões básicas a que a estratégia tecno-
lógica deve responder sobre as fontes são:

(continua)
56 PARTE 1 O Processo

Quadro 2.1 Estratégia Tecnológica (continuação)

• Qual o papel das fontes externas e internas?


• Como elas são integradas?

Após determinar esses dois aspectos, a empresa precisa definir o momento (timing) e a freqüência de implementação das
inovações. O momento envolve tanto questões referentes ao desenvolvimento da capacidade tecnológica quanto a intro-
dução das inovações no mercado. A empresa pode optar em ser pioneira ou seguidora das demais empresas do mercado.
A freqüência de inovação e os riscos associados dependerão, em parte, da natureza da tecnologia e dos mercados envol-
vidos e em parte da escolha estratégica da empresa. Pensando em dois extremos, uma empresa pode adotar uma estratégia
de inovação baseada em saltos pequenos e freqüentes, representada por mudanças incrementais na tecnologia que asse-
guram melhoria contínua no desempenho. Em um outro extremo, estaria uma estratégia de grandes saltos, que permite de-
senvolver mudanças pouco freqüentes, mas de grande escala e que avançam substancialmente o estado da arte.

Onde estamos? Deve-se iniciar pelo levantamento da situação atual do portfólio de projetos. Ao final,
deve-se responder quais são os produtos que estão no mercado, quais projetos estão em desenvolvimento, quais
os resultados obtidos pelos produtos e a situação dos projetos em andamento. A meta é planejar o portfólio fu-
turo de forma a satisfazer a estratégia da unidade de negócio.
Voltemos ao exemplo das impressoras. A estratégia era obter uma diferenciação tecnológica e de qualidade.
Para que essa estratégia seja implementada, é preciso que a linha de produtos da empresa seja, aos olhos do con-
sumidor, mais sofisticada que a do concorrente. Análises do portfólio podem indicar que a empresa possui
poucos produtos em situação favorável aos concorrentes nesse quesito e que os projetos em andamento, embora
sofisticados e com design voltados para demonstrar isso, não apresentariam novidades. A empresa poderia, então,
alterar o portfólio, incluindo o desenvolvimento de uma nova família de impressoras voltada para a impressão de
fotografia digital com novos recursos — como scanner de negativo acoplado. Fundamental é que a linha de pro-
dutos da empresa seja capaz de responder à estratégia da empresa. Nesse caso, por exemplo, ter o produto de
preço mais baixo do mercado não seria necessário, mas o produto mais avançado sim.
Além dessa preocupação com o alinhamento estratégico, deve-se perseguir três outros objetivos durante a
definição do portfólio: a maximização do valor econômico, o balanceamento da carteira e a diminuição dos ris-
8
cos . Deve-se considerar também as tendências e estratégias específicas da empresa com relação a dois aspectos:
a estratégia tecnológica, garantindo que a empresa mantenha sua linha de produtos atualizada e uma equipe de
profissionais capacitada a projetar utilizando as novas tecnologias.
Uma analogia interessante para essa atividade é a de um funil ou tubo conectando a empresa ao mercado,
conforme apresentado na Figura 2.12. Cada círculo nessa figura representa um determinado projeto de desen-
volvimento de produto a ser realizado no tempo. Eles vão diminuindo porque, dado o risco dessa atividade,
parte deles será congelada ou cancelada antes de ser lançada por diferentes razões. Mantendo-se um bom plane-
9
jamento desses projetos, os melhores sobreviverão e atingirão o mercado trazendo benefícios para a empresa.
Ao final do planejamento do portfólio de produtos, obtém-se um “retrato” desse funil com a definição exata
das famílias, produtos e projetos de desenvolvimento que deverão ser realizados pela unidade de negócio no ho-
rizonte de planejamento, que pode variar de empresa para empresa conforme o ramo de atividade. Um exemplo
é um prazo de 5 anos. Falta definir agora o “como”, isto é, verificar se há capacidade para realizar esse plano. Isso
terá que ser feito separadamente, para cada projeto. Portanto, à medida que se aproxima a data de início do de-
senvolvimento de um determinado produto do portfólio, a unidade de negócio precisa destacar um profissional
para analisar e começar o planejamento específico daquele projeto, definindo detalhadamente seu escopo, cro-
nograma e viabilidade técnica e financeira.

8
Esse conceito será apresentado em detalhes no Capítulo 4. Caso o leitor queira se antecipar, consulte o Quadro 4.7.
9
O leitor deve reparar na semelhança da idéia de funil com a descrição geral do modelo. Não é por acaso, pois o modelo unificado é ba-
seado nesse princípio, e sua aplicação gerará esse funil com produtos saindo da empresa até o mercado.
CAPÍTULO 2

O Modelo Unificado do PDP 57

Figura 2.12 Funil ou tubo de produtos.

O desdobramento da estratégia conforme apresentado aqui é reconhecida-


mente a melhor prática em desenvolvimento de produto. Se o processo de desen- Personalizando o processo
volvimento não possui uma forte conexão com essa estratégia, todo o esforço de planejamento
estratégico
técnico e de monitoramento do mercado realizado nas fases seguintes corre grande
risco de se dispersar, comprometendo o futuro da empresa. Logicamente, não é ne-
cessário que uma empresa possua os três níveis estratégicos para aplicar esses conceitos. O caso apresentado aqui
é propositalmente complexo, o de uma empresa internacionalizada com unidades de negócio distintas e uma
grande operação. A idéia básica pode ser seguida independentemente do tamanho da empresa. Por exemplo,
empresas mais enxutas podem realizar um único plano estratégico contemplando desde a missão da organização
até a linha de produtos da empresa. Portanto, não é o tamanho do processo de planejamento ou a quantidade de
análises e de níveis que conta. Fundamental é contemplar um desdobramento de metas de longo prazo e finan-
ceiras da empresa como um todo (corporação) até a definição de uma linha de produtos e projetos de desenvolvi-
mento, capazes de contribuir para que os objetivos da corporação sejam alcançados. Importante é manter uma
estreita coerência entre o que se deseja em termos de resultados gerais, comerciais e financeiros, com a definição
e priorização dos projetos. É isso que garante que a empresa canalize seus esforços de desenvolvimento no essen-
cial, evitando desperdícios e garantindo uma coerência entre a comunicação com os colaboradores e clientes e o
resultado concreto: os produtos. Se há incoerências entre mensagem e características dos produtos, fica evidente
a fragilidade em atender os clientes.
O modelo apresentado neste livro parte desse compromisso e apresenta um
processo de desenvolvimento de produto com elevada integração com a estratégia O modelo deste livro
da empresa. Isso é fundamental para garantir que sejam atendidas e superadas as ex-
pectativas dos clientes, mas também que se atinja os clientes certos, de interesse da empresa. Algo assim permite,
ainda, que a proposta da empresa pareça clara para seu público-alvo, dentro de um estilo próprio capaz de dife-
renciá-la e atribuindo uma vantagem competitiva difícil de ser imitada: a vantagem competitiva por meio do de-
senvolvimento de produtos.

2.4.3 O início e o fim do pré-desenvolvimento


A macrofase de pré-desenvolvimento envolve as atividades de definição do projeto de desenvolvimento, reali-
zadas a partir da estratégia da empresa, delimitação das restrições de recursos e conhecimentos e informações
sobre os consumidores, e levantamento das tendências tecnológicas e mercadológicas. O primeiro passo é o des-
dobramento do resultado do planejamento estratégico em um portfólio, ou carteira de projetos. E finaliza com a
Declaração de Escopo e o Plano do Projeto inicial de um dos produtos previstos no portfólio de projetos, ou um
dos produtos da carteira, o qual será desenvolvido nas etapas posteriores.
58 PARTE 1 O Processo

Os dois objetivos principais dessa macrofase são: 1) garantir a melhor decisão


Objetivos principais dasobre o portfólio de produtos e projetos, respeitando a estratégia da empresa e as
macrofase de restrições e tendências mercadológicas e tecnológicas; 2) garantir que haja uma de-
pré-desenvolvimento
finição clara e um consenso mínimo sobre o objetivo final de cada projeto, partindo
de uma visão clara sobre as metas do projeto para a equipe e evitando um “desvio de
rota” em relação ao papel de cada produto dentro do portfólio da empresa.
A macrofase de pré-desenvolvimento se inicia com o Planejamento Estraté-
Partimos do plano gico da Corporação e o Planejamento Estratégico da Unidade de Negócios, previa-
estratégico da corporação mente preparados. Em nosso modelo, esse é o limite que separa o processo de
e da unidade de negócio
planejamento estratégico do processo de desenvolvimento de produto. Segundo
nossa concepção, todo o trabalho anterior está relacionado ao planejamento estra-
tégico da empresa, e o trabalho de desenvolvimento começa na definição do portfólio de produtos e projetos.

Quadro 2.2 Planejamento Estratégico, Marketing ou Desenvolvimento de Produtos?

Diferentes teóricos da área de marketing e de planejamento estratégico incluem o processo de desenvolvimento de pro-
duto como parte do processo de planejamento e marketing. Autores ligados ao desenvolvimento de produto, por sua vez,
afirmam que o planejamento estratégico está dentro do desenvolvimento ou que o desenvolvimento começa com a idéia
dos novos produtos. Na verdade, do ponto de vista prático, o importante mesmo é que exista a integração entre essas ativi-
dades, independentemente do nome do processo macro, qual seja estratégia ou desenvolvimento de produto.
No caso do modelo apresentado neste livro, adotou-se um ponto objetivo e bastante específico para demarcar a divisão
entre os dois processos: a elaboração da estratégia de produtos, cujo grande resultado é o portfólio de produtos. Ao realizar
as decisões relativas ao portfólio de projetos, se está realizando uma primeira definição de cada um dos produtos e enten-
dendo o seu papel específico na estratégia da empresa. Nessa fase, parâmetros suficientes para estabelecer uma primeira
idéia do que é cada produto são definidos e daí parece ser um início conveniente para o Processo de Desenvolvimento do
Produto. No decorrer desse processo, a definição inicial do produto será continuamente revisada e ampliada até se obter
uma descrição exata e inequívoca de cada item e do processo de fabricação do produto, e tudo esteja pronto para que ele
seja comercializado.
Além disso, essa demarcação deixa subentendida a idéia fundamental de que um bom produto não nasce apenas “de
uma idéia”, como colocado por vários livros-texto em desenvolvimento de produto. Por exemplo, imagine que um enge-
nheiro da área de desenvolvimento da nossa empresa de impressoras apresentada no início do livro tenha uma idéia genial
para criar um produto mais simples e significativamente mais barato que o dos concorrentes. No caso desse produto ser de-
senvolvido, ele estaria indo de encontro à estratégia da empresa, que é distinguir-se pela inovação tecnológica e não em
custos. O produto não estaria contribuindo para as metas da empresa, correndo-se o risco de, por melhor que seja a solução
técnica adotada no projeto, não existir o retorno comercial e de imagem pretendidos. Esse exemplo é algo que acontece na
prática em muitas empresas. Gasta-se tempo e dinheiro criando interessantes planos estratégicos, que se tornam inúteis
porque, no dia-a-dia das operações, decisões são tomadas distanciando a empresa das metas pretendidas.

Uma observação importante é que, dado o caráter criativo e recorrente das atividades de planejamento, o
uso do Plano Estratégico de Negócios não significa a aceitação pura e simples das metas e estratégias nele con-
tidas. Deve-se entender o Planejamento Estratégico de Produtos como um trabalho de recriação, isto é, de apro-
priação crítica em que os planos estratégicos, fruto de uma síntese de várias análises e estudos, são reavaliados e
questionados até que o time de planejamento estratégico do produto esteja consciente da visão futura traçada
para a corporação e/ou unidade de negócio e compreenda perfeitamente o papel que a linha de produtos da em-
presa deverá desempenhar na estratégia. A Figura 2.13 esclarece o escopo do pré-desenvolvimento.
CAPÍTULO 2

O Modelo Unificado do PDP 59

Figura 2.13 Relação entre os documentos principais do processo de planejamento estratégico e desenvolvimento de produtos.

A macrofase pré-desenvolvimento do nosso modelo é dividida, portanto, em duas grandes fases: Planeja-
mento Estratégico de Produtos e Planejamento do Projeto. A primeira delas é composta pelo conjunto de ativi-
dades que transformam as informações contidas nas Estratégias Corporativas e da Unidade de Negócio no
Plano Estratégico de Produtos, o qual contém a descrição do portfólio de produtos. A segunda fase tem seu
início assim que se aproxima a data prevista da realização de um dos projetos do Plano Estratégico de Produtos.
Portanto, um início diferente para cada projeto específico. Ela é composta pelas atividades de determinação do
escopo e planejamento macro do projeto e finaliza no momento em que um projeto específico, depois de plane-
jado, é considerado viável e aprovado no gate.

2.4.4 A importância do pré-desenvolvimento


Agora deve estar mais fácil perceber a importância dessa macrofase. É nela que
se faz a ponte entre o objetivo que a empresa possui e os produtos desenvolvidos. É a ponte entre os
Embora essa discussão pareça extremamente simples e lógica, o leitor deve compreender objetivos da empresa e os
projetos de
que, ainda hoje, é bastante revolucionária diante das práticas adotadas nas indús- desenvolvimento
trias. Em muitas empresas, ainda predomina a visão de que desenvolver produtos é
perguntar ao cliente o que ele quer e ir direto para a “prancheta”. O problema é que
isso pode levar ao desenvolvimento de projetos que estejam desviando a empresa de uma meta. Ou fazendo com
que a empresa deixe escapar oportunidades fundamentais para sua sobrevivência no longo prazo. Evita-se a
perda dessas oportunidades quando, por exemplo, uma empresa decide desenvolver um produto deficitário do
ponto de vista comercial, mas que contribui, por exemplo, com o desenvolvimento de uma nova tecnologia, a
qual, no futuro, pode definir a sobrevivência da empresa. Dosar todas essas possibilidades, na definição do port-
fólio, é uma grande contribuição do pré-desenvolvimento.
Assim, a importância do pré-desenvolvimento está em contribuir com os seguintes aspectos:

I foco nos projetos prioritários definidos pelos critérios da empresa;


I uso eficiente dos recursos de desenvolvimento;
60 PARTE 1 O Processo

I início mais rápido e mais eficiente; e


I critérios claros para avaliação dos projetos em andamento.

Além disso, o planejamento sistemático dos projetos permite que o escopo seja bem definido e que os riscos
sejam avaliados, prevenindo problemas durante a sua realização.
Um aspecto interessante a ser notado é que deficiências nessa macrofase não
Quando existem são facilmente diagnosticadas como problemas de desenvolvimento. São comuns as
deficiências no eternas lutas entre as áreas funcionais de engenharia e o setor de vendas das em-
pré-desenvolvimento...
presas, em um “jogo de empurra-empurra” sem fim: os dois identificando a fonte de
seus problemas como sendo as atividades do outro. Vendas apontando deficiências
na linha de produtos e a engenharia sem capacidade para novos projetos em conseqüência do excesso de novas
idéias e mudanças nas metas de necessidades identificadas pela área de vendas. Ambos têm sua parcela de razão,
mas não percebem que a causa fundamental de todos os problemas está na deficiência da delimitação do plano
estratégico e do gerenciamento da carteira de produtos. Falta um pré-desenvolvimento mais sistematizado e in-
tegrado com as demais fases do PDP.

2.4.5 Pré-desenvolvimento é para todos?


Sim, independentemente do tipo de processo de desenvolvimento de produto, a empresa necessita de um
mínimo de entendimento da missão e objetivos estratégicos. E a escolha dos projetos de desenvolvimento pre-
cisa ser baseada nessa missão. Mesmo empresas que desenvolvem sob encomenda precisam analisar o mercado
para avaliar quais as oportunidades e priorizar clientes e projetos. Mas, certamente, a importância dessa fase
deve ser medida conforme certas características do processo de desenvolvimento de produto e do ambiente da
empresa. Alguns exemplos:

I Quanto à dimensão mercado-setor: alguns setores industriais específicos, como atualmente o eletroele-
trônico, em especial celulares, e o de biotecnologia atravessam fases de saltos abruptos no nível tecnoló-
gico. Nesses ambientes, escolher adequadamente os projetos de desenvolvimento é fundamental e pode
ser a diferença entre prosperar ou morrer. É condição essencial para que a empresa consiga manter uma
linha de produtos atualizada e competitiva no longo prazo. Em casos assim, as empresas precisam ter um
pré-desenvolvimento sofisticado, contendo todas as fases e atividades apresentadas no modelo.
I Quanto à dimensão mercado-concorrência: há setores industriais específicos em que, embora a tecno-
logia básica seja madura, a concorrência torna-se acirrada em termos de características subjetivas dos
clientes ditadas por modas ou valores culturais. É o caso específico de empresas de perfumes, alimentos
ou linha branca. O pré-desenvolvimento aqui é essencial para se definir uma quantidade de projetos
capaz de gerar uma linha de produtos que atenda às necessidades específicas de cada cliente sem com-
prometer a manufaturabilidade.
I Complexidade do produto: produtos que possuem uma complexidade muito grande exigem um pré-desen-
volvimento mais completo, pois é grande o risco de fracasso diante das dificuldades de desenvolvimento.

Em síntese, podemos dizer que, quanto mais turbulento o ambiente (no sentido de ser competitivo e com
mudanças mais bruscas), mais inovador o produto, menor o tempo de vida do produto no mercado e maior a
complexidade em quantidade de peças e processos de fabricação específicos, mais importante se torna o
pré-desenvolvimento.
Após o planejamento de um projeto específico de desenvolvimento de um produto, parte-se para a outra
macrofase do modelo, na qual esse planejamento é utilizado e atualizado durante a realização do projeto pro-
priamente dito, ou seja a macrofase de desenvolvimento.
CAPÍTULO 2

O Modelo Unificado do PDP 61

2.5 Visão geral da macrofase de desenvolvimento


Após a definição do portfólio de produtos e o planejamento
dos projetos, partiremos para o desenvolvimento propriamente
dito. Por tradição, essa macrofase é denominada desenvolvimento
de produtos ou projeto do produto. No nosso modelo, ela é integrada
às macrofases de pré e pós-desenvolvimento.

2.5.1 Características das fases do desenvolvimento


Na Figura 2.14 pode-se observar as fases do desenvolvi-
mento. Vimos que uma fase termina com a entrega de resultados
(deliverables), os quais, a partir desse momento, permanecem con-
gelados. Essa divisão varia de empresa para empresa e não existe
um padrão.10 Normalmente, a definição de uma fase está relacio-
nada com o conceito de gate (veja o Tópico 2.7). No final de uma fase, sempre temos uma avaliação do projeto,
isto é, a necessidade de avaliar os resultados de um projeto implica um gate, que, por sua vez, delimita uma fase.11
As características do processo de desenvolvimento de produtos foram apresentadas no início do Capítulo 1,
e mostra a importância das fases iniciais do desenvolvimento, ressaltadas na Figura 2.14: no início, o grau de in-
certeza é grande, porém, é neste momento que são realizadas as escolhas de soluções de projeto (materiais, con-
ceitos, processos de fabricação etc,), que determinam aproximadamente 85% do custo final do produto.

Figura 2.14 Características das fases iniciais do desenvolvimento.

Em razão do grau de incerteza inicial, ocorrem modificações de produto nas fases subseqüentes do desen-
volvimento, quando informações mais precisas estão disponíveis. O custo das modificações é cada vez mais ele-
vado, conforme avançam as fases do DP.
Vamos comparar qualitativamente o custo de uma modificação no desenvolvimento de uma máquina para
entendermos melhor o que estamos falando. Imagine a introdução de alguma mudança durante a fase de projeto
informacional, quando os requisitos do produto e suas especificações-meta foram definidos. O custo dessa mo-
dificação envolve definir os novos requisitos e as especificações e pode significar algumas horas de trabalho do

10
Veja quatro exemplos diferentes de fases do PDP: 1. estudo do mercado, especificação, projeto conceitual, projeto detalhado, proces-
so, vendas; 2. análise de necessidades, pesquisa de mercado, projeto de componentes, projeto de processo, teste, início da produção, al-
teração de engenharia; 3. estudo de viabilidade, projeto preliminar, projeto detalhado, revisão e testes, modificações; 4. conceber
produto, conceituar produto, projetar produto e processo, homologar produto e processo, ensinar empresa, produção, avaliação e
ações corretivas.
11
Existem empresas que definem avaliações intermediárias dos resultados do projeto no meio das fases. Nesses casos, os gates podem ser
direcionados aos aspectos técnicos do projeto.
62 PARTE 1 O Processo

time de desenvolvimento. Imagine agora que estamos na fase de lançamento, na qual todos os desenhos, pro-
cessos, ferramental, máquinas etc. já foram definidos, especificados, comprados, construídos etc. O custo de
modificação nesse momento, dependendo do grau de mudança, é da ordem de até mil vezes o custo da mudança
da fase do projeto informacional (Figura 2.15).

Figura 2.15 Custo de mudanças cresce exponencialmente nas fases finais do desenvolvimento.

Mudanças sempre ocorrem, dada a natureza do processo de desenvolvimento, e o importante é fazer com
que elas ocorram no início do desenvolvimento (Figura 2.16), quando o custo das alterações é menor. Esse é um
dos objetivos da Engenharia Simultânea.12

Figura 2.16 Um dos objetivos da Engenharia Simultânea é fazer com que mudanças no produto ocorram no início da macrofase de
desenvolvimento.

12
Veja o Quadro 2.3, a seguir, para saber o que é Engenharia Simultânea.
CAPÍTULO 2

O Modelo Unificado do PDP 63

Quadro 2.3 O que é Engenharia Simultânea

O termo Engenharia Simultânea vem sendo utilizado há anos com significados diferentes, porém complementares.
Alguns autores também empregam o termo Engenharia Concorrente, mas, em português, esse termo não tem o mesmo sig-
nificado que em inglês (Concurrent Engineering).
Uma das primeiras iniciativas foi aumentar o grau de paralelismo entre as atividades de desenvolvimento, com ênfase na
realização simultânea das tarefas de projeto e planejamento de processo. Apesar de um pouco teórica, essa iniciativa pre-
gava que atividades, que eram iniciadas somente após o término e a aprovação das atividades anteriores, deveriam ser an-
tecipadas de forma que seu início não dependesse dos demorados ciclos de aprovação (além disso, ciclos de aprovação
“não agregam valor ao produto”). Para isso, os projetistas e processistas deveriam trabalhar em um mesmo time. Desde
então, esse conceito vem evoluindo.
Algumas empresas consideram a Engenharia Simultânea como um método que pode ser aprendido e utilizado, assim
como o método de projeto robusto (por exemplo). Ela representa, no entanto, um conceito de trabalho mais amplo e en-
volve várias técnicas.
Os objetivos da Engenharia Simultânea são os mesmos de outras técnicas de melhoria de processo:
• aumento de qualidade do produto, com foco no cliente;
• diminuição do ciclo de desenvolvimento; e
• diminuição de custos.
Esses objetivos podem ser desdobrados em vários objetivos intermediários, como o apresentado no texto, de se diminuir
a quantidade de mudanças nas fases finais do desenvolvimento. Isso, em última análise, diminui o tempo e os custos de de-
senvolvimento.
Engenharia Simultânea é uma filosofia utilizada no processo de desenvolvimento de produtos. É uma abordagem siste-
mática, que possui os seguintes princípios:
• deve-se trabalhar em equipe, pregando-se a cooperação e confiança entre seus membros, assim como o compartilha-
mento de conhecimentos;
• devem fazer parte dessa equipe os clientes e fornecedores, enfim, todos os parceiros da cadeia de suprimentos;
• as pessoas envolvidas no desenvolvimento devem considerar, desde o início, todos os elementos do ciclo de vida do
produto, da concepção ao descarte, incluindo qualidade, custo, prazos e requisitos dos clientes; e
• enfatiza o atendimento das expectativas dos clientes.
Além disso, a prática de Engenharia Simultânea faz uso de métodos e sistemas integrados de engenharia, tais como QFD,
13
FMEA, DFx, CAD/CAE, CAPP, PLM .
Observa-se que o conceito de Engenharia Simultânea se confunde com o de desenvolvimento integrado de produtos,
que é o conteúdo apresentado neste livro. Não se consegue tratar hoje de Engenharia Simultânea sem que seja considerada
a visão de processo na sistematização do PDP.

2.5.2 O início e o fim do desenvolvimento


A macrofase anterior produz informações necessárias para a realização do desenvolvimento, tanto do ponto
de vista tecnológico, comercial e financeiro como do ponto de vista organizacional, ou seja, como se deve con-
duzir o projeto de desenvolvimento. Mas cada projeto é um caso específico. Dependendo de vários fatores,
como grau de maturidade tecnológica, nível de inovação do produto, mercado, estratégias etc., estão disponíveis
mais ou menos informações para o time de desenvolvimento.
O time de desenvolvimento varia em tamanho e tipo de membro, dependendo
da fase. No início trabalham mais os representantes das áreas comercial e de marke- O time de
ting, pois é o momento em que se definem os requisitos do produto a partir das neces- desenvolvimento
sidades do mercado, culminando com a concepção do produto. No final, a maior
parte do time é formada por pessoas das áreas de engenharia e produção. Porém sempre existe um time central
multidisciplinar permanente participando de todas as fases de desenvolvimento, com o intuito de garantir uma

13
O significado dessas siglas encontra-se no Apêndice III deste livro.
64 PARTE 1 O Processo

continuidade de conhecimento ao longo dessa macrofase. Esse time comumente é dissolvido ao final do desenvol-
vimento, ou melhor, após acompanhar o resultado dos primeiros lotes do produto no mercado. Se o produto for
inovador, o tempo de acompanhamento no começo da comercialização é maior do que nos produtos derivados.
Tipicamente, o desenvolvimento parte das informações geradas pela macro-
Informações iniciais fase de pré-desenvolvimento, e documentadas no plano do projeto. Como pôde ser
visto na Figura 2.9, o plano de projeto é constituído por: escopo do projeto, escopo
do produto (conceito do produto), atividades e sua duração, prazos, orçamento, pessoal responsável, recursos
necessários para realizar o projeto, especificação dos critérios e procedimentos para avaliação da qualidade
(assim como possíveis normas que precisam ser atendidas), análise de riscos, indicadores de desempenho sele-
cionados para o projeto e produto (com seus valores-alvo).
Ao final dessa macrofase são produzidas informações técnicas detalhadas, de
Resultados da macrofase produção e comerciais relacionadas com o produto; os protótipos já foram apro-
de desenvolvimento vados; os recursos a serem utilizados para a sua produção, comercialização e suporte
técnico foram comprados, recebidos, testados e instalados; alguns produtos foram
fabricados e aprovados; já ocorreu o lançamento no mercado e as pessoas da cadeia de suprimentos estão infor-
madas e treinadas — tanto aquelas de empresas parceiras no fornecimento quanto as que estão envolvidas na co-
mercialização e suporte. Em alguns casos, novos processos de negócio de produção, atendimento ao cliente e
assistência técnica foram desenhados e implementados. Esses resultados estão resumidamente representados na
Figura 2.9 por: especificações finais, liberação da produção e documento de lançamento.
O time de desenvolvimento será constituído no início da macrofase de desen-
Inicia-se com a volvimento por pessoas de diversas áreas da empresa, com ênfase nas áreas comer-
determinação de todas as cial e de marketing, mas sendo auxiliadas pelos engenheiros e pessoal da produção.
especificações-meta
O time de projeto tem em mãos a Minuta do Projeto e o Plano do Projeto, este úl-
do produto
timo um plano detalhado contendo atividades, recursos, riscos, análise econô-
mico-financeira e várias outras informações (veja a Figura 2.9). O primeiro passo
será obter um entendimento comum do que está no plano do projeto, chegando a uma definição final sobre o
problema do projeto, ou seja, o que se pretende atingir (“resolver”) com o produto. Eles identificam, então, as
pessoas envolvidas com o produto durante o seu ciclo de vida (clientes, pessoal da assistência técnica, manufa-
tura etc.) e levantam quais são as suas necessidades, complementando, assim, com o uso de diversas técnicas e
métodos (apresentados no Capítulo 6) as informações recebidas da macrofase anterior. Com base nessas neces-
sidades e requisitos, todas as especificações-meta do produto são determinadas e documentadas. O envolvi-
mento das pessoas da cadeia de suprimentos e o contato com clientes em potencial são primordiais para garantir
a qualidade das especificações.
A seguir, são listados alguns exemplos de especificações: relacionadas às necessidades dos clientes em
termos de parâmetros do produto, tais como: tamanho, peso, aparência e grandezas elétricas do produto;
normas técnicas, de qualidade e de meio ambiente a que o produto precisa atender; informações mais precisas
sobre parceiros no desenvolvimento e comercialização do produto com a determinação de parceiros-chave; ve-
rificação se a tecnologia a ser utilizada no produto está madura e pode ser usada; informações mais completas so-
bre as características de produtos concorrentes, se existirem; definição mais precisa do mercado e das vendas
futuras, como volume de vendas esperado durante um período, preço que o mercado pagaria; e análise financeira
do produto, mostrando se ele ainda seria rentável perante as novas informações disponíveis nas especificações.
Com base nas especificações, são estabelecidas as estruturas funcionais do pro-
Deve-se partir de uma duto, ou seja, quais as funções (físicas, de qualidade, estéticas etc.) ele deve possuir
concepção para para atender aos requisitos de todas as pessoas que entrarão em contato com o pro-
se projetar
duto no decorrer do seu ciclo de vida, consumidores, técnicos de assistência técnica,
vendedores etc., isto é, os clientes do produto. O time de desenvolvimento nesse
momento envolve-se mais estreitamente com os parceiros e fornecedores da cadeia de suprimentos. Em con-
junto são definidas as alternativas de solução, que correspondem às soluções construtivas e tecnológicas, as
quais, por sua vez, fornecem as funções esperadas do produto. A melhor solução (ou as melhores soluções alter-
nativas) é selecionada e verifica-se se ela garante um retorno financeiro, de acordo com o plano de negócio defi-
nido anteriormente.
CAPÍTULO 2

O Modelo Unificado do PDP 65

As soluções são detalhadas em informações técnicas, com a definição dos sistemas, subsistemas e compo-
nentes do produto. Fazem parte dessas informações, por exemplo, desenhos de conjunto do produto; cálculos
preliminares de engenharia; esquemas com a definição da arquitetura do produto.
Todas essas informações são reunidas em uma concepção do produto, que contém todos os elementos para
decidir se o produto pensado no momento do plano de negócio vai ser viável ou não. Isso quer dizer que, mais
uma vez, o estudo de viabilidade econômico-financeira é atualizado para avaliar o retorno financeiro que esse
produto trará para a empresa.
Nessa ocasião, o time de desenvolvimento tem o envolvimento cada vez maior
de pessoas das áreas técnicas relacionadas com as tecnologias do produto e sua pro- Informações são
dução. Paralelamente aos projetos conceituais, pode-se detalhar informações e es- detalhadas, protótipos
testados e produto
pecificações do produto (principalmente para projetos derivados), trabalhando-se homologado
no conceito de Engenharia Simultânea.
Inicia-se um processo de Projetar-Construir-Testar-Otimizar o produto em ciclos de detalhamento e oti-
mização até a homologação do produto. Além de realizar todos os cálculos e desenhos detalhados, o time planeja
como o produto vai ser produzido e lançado no mercado. Não se pode esquecer aqui dos manuais do cliente, téc-
nico e para o pessoal de assistência técnica, assim como possíveis sistemas de apoio a vendas. Um exemplo aqui
são os sistemas específicos de configuração de produtos, que os vendedores de elevadores possuem e levam junto
quando eles vão visitar uma obra de construção de um prédio. Com alguns poucos dados da obra, eles podem
fazer uma proposta comercial, graças às opções existentes nesses sistemas de configuração.
Os processos de manufatura são finalizados contendo a seqüência de fabricação; as especificações das má-
quinas e das ferramentas; os métodos de produção; enfim todos os documentos que são necessários para se pro-
duzir o produto com qualidade. Em alguns casos, esses planos de processo de fabricação objetivam a produção
em série. A obtenção da documentação de fabricação também pode ser obtida quase ao mesmo tempo em que
são criados os desenhos de detalhamento, quando a empresa aplicar os princípios da Engenharia Simultânea.
Nesse momento, existem ainda alguns itens do produto, que não são estratégicos, e deve-se definir o que
será produzido dentro da própria empresa e o que será comprado dentro da cadeia de suprimentos. Anterior-
mente, já haviam sido determinados os parceiros mais estratégicos, agora outros fornecedores serão definidos.
Em alguns casos, a cadeia de suprimentos é criada para o produto em questão; em outras palavras, é estabelecido
todo o conjunto de fornecedores que, juntos, produzirão os componentes, tecnologia e serviços que garantirão
que o produto chegue ao mercado com sucesso no tempo determinado.
Paralelamente, os protótipos são produzidos e testados, e assim o produto é homologado. Homologar sig-
nifica verificar se o protótipo atende todos os requisitos anteriormente definidos e/ou padrões específicos da in-
dústria. Por exemplo, para produtos da linha branca e elétricos, há uma série de normas, nacionais e
14
internacionais, que precisam ser atendidas. Algumas delas possuem instituições, como o Inmetro , que fazem
testes e emitem certificados, chamados selos de qualidade. Falta agora saber se a empresa (na verdade, a cadeia
de suprimentos total, ou seja, todos os parceiros de fornecimento) consegue produzir produtos em série (quando
for o caso) com as mesmas qualidades do protótipo e que também atendam aos requisitos dos seus clientes ao
longo do ciclo de vida do produto.
Todos os equipamentos necessários à produção do produto são especificados e adquiridos durante a con-
fecção do projeto, pois, caso contrário, os prazos de lançamento serão mais longos. Muitas vezes, a produção
exige equipamentos especiais, que não são encontrados no mercado de máquinas em geral. E, em alguns casos,
esses equipamentos trazem um diferencial em produtividade, o que torna o produto competitivo. Em alguns
casos, esses equipamentos são fabricados na própria empresa, pois são eles que garantem a vantagem competi-
tiva do produto, e deverão ser finalizados ainda na fase de desenvolvimento. Hoje em dia, no entanto, é mais
comum terceirizar as atividades de fabricação desses equipamentos.

14
Instituto Nacional de Metrologia, Normalização e Qualidade Industrial (http://www.inmetro.gov.br).
66 PARTE 1 O Processo

Começam a chegar os equipamentos comprados e os primeiros lotes de peças


Os equipamentos chegam, dos fornecedores. As máquinas precisam ser testadas com o uso das novas ferra-
a produção inicia e o mentas para produção que também começam a ficar prontas. Em alguns casos,
produto é lançado
novas instalações (fábricas) precisarão ser construídas para a manufatura do novo
produto. Quando o volume de produção é pequeno ou há capacidade ociosa na em-
presa, os equipamentos existentes podem dar conta do novo produto. Em qualquer um desses casos, realiza-se a
produção inicial de um lote piloto, que é avaliado para provar que a empresa consegue obter produtos com as
mesmas características do protótipo (ou melhores). Os atrasos costumam ser fatais, pois a falta de uma única
peça específica, mesmo que simplória e no valor de centavos, pode impedir a produção de um produto complexo
de milhares de reais.
No final dessa macrofase, termina-se, por assim dizer, o projeto de desenvolvimento. A maior parte das me-
todologias de projeto termina nesse ponto. O nosso modelo de referência abrange todo o ciclo de vida do pro-
duto. Normalmente, o time de desenvolvimento se desfaz ou parte dele acompanha o início do período de
comercialização, quando ocorrerem os primeiros problemas. Na fase de produção e comercialização do pro-
duto, são outros os processos de negócio que ficam no primeiro plano, e o processo de desenvolvimento de produtos
ocorre paralelamente, realizando as atividades mostradas na próxima macrofase.

2.6 Visão geral da macrofase de pós-desenvolvimento


2.6.1 Por que pós-desenvolvimento?
Nas publicações mais tradicionais e mesmo em muitas em-
presas, o final da macrofase de desenvolvimento apresentada no
tópico anterior representa o final do processo de desenvolvi-
mento de produtos. É o momento em que a “engenharia passa o
bastão para a produção”. Essa visão pode fazer com que as em-
presas desperdicem os conhecimentos adquiridos durante a fase
de produção e comercialização do produto, como ilustrado no
exemplo a seguir.
Uma empresa fabricante de tratores acabou de lançar um
novo produto no mercado e passou a responsabilidade pelo pro-
duto ao setor de manufatura. O time de desenvolvimento foi des-
feito, as pessoas voltaram para as suas áreas funcionais e outras
foram alocadas em novos projetos. Nenhuma dessas pessoas terá mais contato com
Exemplos de falta de o produto, que eles acabaram de desenvolver. Elas até podem reutilizar as informa-
gestão de conhecimento ções que foram criadas, mas sem o crivo da aplicação prática para verificar a quali-
dade dessas informações em casos reais.
No entanto, o desempenho do trator em campo não está sendo o esperado. A empresa possui um departa-
mento de assistência técnica com pessoas experientes, e a única pessoa desse departamento que participou do de-
senvolvimento do produto está alocada em um outro projeto. Eles conseguem resolver o problema de campo,
que surgiu por uma falta de dirigibilidade do trator, causada por um problema da bomba hidráulica do comando
de direção. A especificação da bomba foi modificada. No entanto, eles demoraram três meses para descobrir a
causa e, com isso, perderam muitos clientes. Constataram que três anos atrás, um outro trator da mesma família
apresentou o mesmo tipo de problema. Como foi que eles incorreram no mesmo erro? Foi falta de uma gestão de
conhecimentos adequada que pudesse garantir o registro das lições aprendidas no campo para reutilização em pro-
jetos futuros. Ou seja, não existiu um pós-desenvolvimento sistematizado e, assim, eles perderam a chance de
aprender com os problemas do passado, causando muitas perdas atuais, que poderiam ter sido evitadas.
Esse mesmo trator permaneceu no mercado por cinco anos e, durante esse período, ele apresentou outros
problemas. O volume de venda não foi o esperado, assim como o preço que foi cobrado. Após a sua substituição
CAPÍTULO 2

O Modelo Unificado do PDP 67

por um modelo novo da mesma família, a empresa ainda teve que dar manutenção aos tratores em campo e
nunca soube com uma certa precisão qual o retorno que eles tiveram com o trator, para comparar com os dados
iniciais dos estudos de viabilidade econômica do projeto de desenvolvimento e do trator.
Durante a macrofase de desenvolvimento, o protótipo do trator tinha apresentado um problema de fadiga
em sua estrutura, solucionado por especialistas em cálculo estrutural. No entanto, na aplicação prática, surgiram
novas condições de uso que não tinham sido previstas, e o trator passou a apresentar o mesmo problema. Porém,
aqueles especialistas estavam alocados em outros projetos, e o pessoal de assistência técnica levou as novas difi-
culdades para pessoas que não participaram do desenvolvimento. Demorou dois meses para se chegar a mesma
solução que o time de desenvolvimento tinha proposto durante a fase de teste do protótipo. Por que isso
ocorreu? Porque não foi designado um time de acompanhamento do produto nem existia na empresa um
pós-desenvolvimento sistematizado, que garantisse uma continuidade à gestão do ciclo de vida do produto. Os
conhecimentos gerados ficaram com as pessoas, e a empresa não os aproveitou. A empresa não aprendeu.
Esses são exemplos, entre vários possíveis, do que a falta da macrofase de pós-desenvolvimento pode causar
em uma empresa.
O acompanhamento sistemático e a documentação correspondente das melho-
rias de produto ocorridas durante o seu ciclo de vida são atividades centrais do Atividade central do
pós-desenvolvimento:
pós-desenvolvimento. acompanhar o produto
O acompanhamento recebe informações de todos os processos envolvidos com
o produto: do monitoramento dos resultados do produto no mercado; da produção e distribuição do produto;
do atendimento ao cliente; e da assistência técnica. Essas informações são processadas pelo acompanhamento
que, quando necessário, aciona os processos de apoio correspondentes de gerenciamento das mudanças de enge-
15
nharia; ou de melhoria do PDP .
A macrofase de pós-desenvolvimento compreende a retirada sistemática do produto do mercado e, final-
mente, uma avaliação de todo o ciclo de vida do produto, para que as experiências contrapostas ao que foi plane-
jado anteriormente sirvam de referência a desenvolvimentos futuros.
Graças ao pós-desenvolvimento, garante-se que parte das pessoas e o conheci-
mento acumulado durante o desenvolvimento estejam à disposição da empresa no Razão do
pós-desenvolvimento
acompanhamento da vida do produto. Garante-se, ainda, que os conhecimentos ad-
quiridos durante esse período sejam sistematizados e documentados, viabilizando a
sua reutilização em novos projetos de desenvolvimento. Além disso, o pós-desenvolvimento compreende a reti-
rada sistemática do produto do mercado, fazendo com que os requisitos de gestão do meio ambiente sejam con-
siderados, para que, novamente aqui, a experiência possa ser útil em um novo desenvolvimento. A retirada pode
envolver o reuso do produto (ou parte dele) em um outro, a desmontagem do produto e a utilização de suas
partes ou material; a reciclagem do material empregado no produto; ou o descarte completo. Finalmente, no
pós-desenvolvimento, acontece uma avaliação de todo o ciclo de vida a posteriori, para averiguar o grau de acerto
do planejamento econômico anteriormente realizado e suas atualizações durante o ciclo de vida, a fim de se criar
um padrão de previsões na empresa.

2.6.2 O início e o fim do pós-desenvolvimento


Primeiro devemos ressaltar a duração dessa macrofase. Observe novamente a Figura 2.8. Veja que o tempo
de duração dessa macrofase é bem superior ao tempo das demais fases. Um produto fica no mercado por muito
tempo, quando comparado com o tempo de planejamento e de desenvolvimento. Hoje em dia, aumentou a fre-
qüência de substituição dos produtos e, portanto, o seu ciclo de vida diminuiu, fazendo com que tenhamos de
lançar mais produtos em menos tempo. Mesmo assim, em alguns casos, essa macrofase dura vários anos.

15
Descritos no Capítulo 13, tópicos 13.1 e 13.2, respectivamente.
68 PARTE 1 O Processo

Após a entrega dos primeiros lotes de produtos no mercado, quando se finaliza


O time de o projeto de desenvolvimento, o time de desenvolvimento é dissolvido, e os seus
acompanhamento membros são deslocados para outros projetos ou retornam para as suas áreas funcio-
nais. Nessa ocasião é formado o time de acompanhamento do produto, que é com-
posto por membros do time de desenvolvimento acrescidos de pessoas responsáveis pela produção e assistência
técnica do produto. Apesar de receber o nome de time, os seus membros não trabalham com dedicação exclusiva
para o produto, mas estão disponíveis para atenderem chamados emergenciais. Normalmente, eles cumprem as
suas obrigações funcionais nos departamentos em que estão alocados ou mesmo nos projetos em que estão atuando.
No entanto, é bom que sejam designadas pessoas que participaram do desenvolvimento, pois elas preservam a
memória do desenvolvimento. Existem várias configurações possíveis para esse time. Em qualquer uma delas,
porém, deve-se alocar membros do time de desenvolvimento, para garantir uma continuidade e passagem de co-
nhecimentos.
Outras pessoas da organização também possuem funções operacionais relacionadas ao acompanhamento
do produto, como o pessoal de assistência técnica, mas elas não fazem parte do time de acompanhamento e, pro-
vavelmente, não participaram do time de desenvolvimento. Elas estão formalmente alocadas a esse outro processo
de negócio. E não necessariamente lidam apenas com um produto, dependendo de sua importância na empresa
e volume no mercado.
Esse time tem o conhecimento profundo de todos os aspectos do produto e
Inicia-se pelo realiza um planejamento do acompanhamento do produto no pós-desenvolvi-
planejamento mento. Esse planejamento deve estar em consonância com todos os planos defi-
nidos durante a macrofase de desenvolvimento. Ele define as principais atividades e
os responsáveis, ou seja, quem responderá pela interface com os dados do produto que podem ser atualizados
durante todo o ciclo de vida e pelas atividades operacionais (normalmente departamentos estabelecidos para
esse fim). Além disso, estabelece como será o procedimento em um momento de necessidade, quando, por
algum motivo, o produto falhar no mercado, e, também, quando e como acionar o processo de apoio de geren-
ciamento de mudanças de engenharia.
Na fase de acompanhamento, o time reúne as informações de todos os processos
Integração e consolidação envolvidos com o produto: do monitoramento dos resultados do produto no mer-
das informações recebidas cado; da produção e distribuição do produto; do atendimento ao cliente; e da assis-
de outros processos
tência técnica. Essas informações são processadas e consolidadas por membros do
time, que são consultados quando necessário para realizar análises mais elaboradas.
Essa fase possui duas atividades operacionais: a avaliação da satisfação do cliente e o monitoramento do de-
sempenho técnico do produto. E três que ocorrem esporadicamente: as auditorias, o acompanhamento das mo-
dificações do produto, quando acionadas por um dos processos listados anteriormente, e o registro das lições
aprendidas.
A avaliação da satisfação do cliente pode ser realizada pelas pessoas responsáveis pelo produto que traba-
lham na área de marketing e é uma forma proativa da empresa ir a campo e verificar a percepção do cliente com
relação ao produto.
Por sua vez, o monitoramento pode ocorrer por meio da análise das informações recebidas de diversos ca-
nais de comunicação com o mercado, existentes nos processos de atendimento ao cliente (que recolhe opiniões e
reclamações de clientes insatisfeitos) e de assistência técnica (traz as experiências de campo). O monitoramento
pode envolver questões técnicas, econômicas, de produção e de serviços. De tempos em tempos, deve-se realizar
auditorias para se avaliar em detalhes esses aspectos do produto. Essas auditorias podem estar associadas à ava-
liação da satisfação dos clientes, mas não devem ser limitadas a essas questões.
Cada vez que a solução de um problema, ou mesmo uma oportunidade de melhoria, implicar mudança de
alguma especificação do produto ou processo, deve-se gerenciar de forma sistemática a introdução dessa mu-
dança na empresa. Em razão de sua importância e abrangência, o gerenciamento de mudanças de engenharia
ocorre em um outro processo, considerado de apoio, pois, como mencionado anteriormente, o time de acompa-
nhamento não tem dedicação exclusiva para o produto corrente. Além disso, o gerenciamento de mudanças não
CAPÍTULO 2

O Modelo Unificado do PDP 69

ocorre somente durante a fase de produção, mas pode ocorrer, também, durante a macrofase de desenvolvi-
mento, quando certas informações do produto já estiverem “congeladas”. Isso evita que aconteçam inconsistên-
cias entre as informações armazenadas e que os impactos das mudanças sejam avaliados, evitando vários
desperdícios.
Em alguns casos, na fase de acompanhamento, são detectadas inconsistências nas informações do produto
ou processo, que surgiram por uma falha no próprio processo de desenvolvimento de produtos. Nesses casos,
eles encaminham ou propõem uma melhoria no PDP. Essa melhoria é gerenciada por meio de um outro pro-
cesso de apoio.
Por exemplo, imagine que uma empresa de espelhos retrovisores automotivos
resolva atender a uma reivindicação de uma melhoria estética no produto, conside- Exemplo de falta de
rada não urgente pelo cliente. E que ainda exista matéria-prima disponível para a gerenciamento de
mudanças de engenharia
produção de 10 mil peças. Se ela implantar a mudança, sem utilizar o material dis-
ponível, estará desperdiçando seus recursos. Ou seja, ela deveria realizar a mudança,
mas implantá-la somente após esgotar toda a matéria-prima anterior.
Imagine ainda que essa mudança envolva uma atualização da geometria da peça, realizada pelos projetistas
da empresa, resultando em um novo modelo geométrico dentro da base de dados do sistema CAD. Se não
houver um controle efetivo da integridade das informações, pode ser que a área de processos de fabricação não
receba a nova geometria e continue a produzir matrizes de injeção plástica com base na geometria antiga. Ou
seja, apesar de a alteração ter sido realizada pelos engenheiros, os processistas não foram informados, e a empre-
sa continuará a produzir espelhos com a geometria antiga.
O gerenciamento sistemático das mudanças de engenharia procura evitar esses problemas (veja o Capítulo 13).
Assim como nas fases de desenvolvimento, no pós-desenvolvimento deve-se
registrar de forma sistemática todas as lições aprendidas durante o acompanha- Registre todas as lições
mento do produto. Elas devem estar armazenadas de tal maneira, que pessoas não aprendidas
envolvidas com o presente projeto possam reutilizar essas experiências, evitando in-
correr nos mesmos erros no futuro.
Pode ser que o momento de finalização da produção coincida com a retirada do
produto do mercado. Mas como o modelo de referência deste livro lida com pro- Enfim o produto é retirado
dutos duráveis, mesmo que sejam de consumo, normalmente a empresa pára de do mercado
produzi-los, mas eles ainda permanecem no mercado durante um tempo. Por isso,
tratamos nesta macrofase de dois momentos distintos: o de encerramento da pro-
dução e o de retirada do produto do mercado.
O momento de encerramento da produção é acompanhado por uma definição de quem será o fornecedor
de produtos de reposição e serviços. No momento da retirada do produto de mercado, deve-se acionar os planos
previstos para reúso, reciclagem ou descarte do produto. Um bom desenvolvimento deve prever essas atividades
desde o levantamento dos requisitos do produto e a definição de soluções que atendam a esses requisitos, quando
o ciclo de vida do produto é analisado. O planejamento do pós-desenvolvimento trata dessas questões somente
do ponto de vista organizacional, pois as questões técnicas são consideradas durante o desenvolvimento.
No final do ciclo de vida, são reunidas todas as informações associadas àquele
produto para permitir que elas sejam reutilizadas no futuro. São anexadas ao projeto O ciclo de vida é encerrado
de desenvolvimento, que foi finalizado no término da macrofase de desenvolvi-
mento, todas as informações e conhecimentos relevantes, que surgiram durante a macrofase de pós-desenvolvimento.
A associação das informações relacionadas com o produto acontece na verdade de forma contínua durante todo
o ciclo de vida. No final, acrescenta-se um documento formal de fim de vida, no qual se avalia o retorno real que
o produto trouxe à empresa, comparando-se com o que foi planejado.
70 PARTE 1 O Processo

2.6.3 Pós-desenvolvimento é para todos?


Assim como a macrofase de pré-desenvolvimento, pode parecer que o pós-desenvolvimento só deve ser
aplicado em grandes empresas. Não!
Nas empresas grandes com produtos complexos, como é o caso da indústria aeronáutica, o pós-desenvolvi-
mento é vital e uma exigência dos clientes e instituições que regulam o setor. O acompanhamento da operação
das aeronaves pode durar até 40 anos, pois o fabricante é obrigado a realizar essas atividades enquanto existir um
número mínimo de produtos em uso. Nessas empresas, deve-se estabelecer todos os papéis citados, o time de
acompanhamento e as áreas envolvidas devem ser muito bem definidas.
Em uma empresa pequena, por exemplo, uma empresa de fabricação de máquinas de pequeno porte com
30 funcionários ao todo, as mesmas fases e atividades podem ser realizadas, pois os clientes podem voltar a rea-
lizar consultas ou solicitar melhorias nos produtos comprados. Nesse caso, um pequeno time pode atender essas
necessidades, por exemplo: uma pessoa da engenharia, que estaria à disposição quando algum problema ocor-
resse e necessitasse de atualização do produto; uma pessoa da assistência técnica, que, de qualquer maneira, es-
taria em contato com o produto em campo; e outra do controle da qualidade.
O gerenciamento de mudanças poderia utilizar um sistema de registro das modificações integrado a um siste-
ma de gerenciamento de documentos. Em casos mais simples, uma planilha poderia auxiliar a área de engenharia.
Mesmo no caso de produtos de bens de consumo muito simples, ao menos parte das atividades dessa ma-
crofase precisará ser realizada. É o caso do registro das lições aprendidas, problemas e falhas do produto no mer-
cado. Uma empresa pequena pode utilizar ferramentas simples. Um exemplo: pode-se criar um arquivo de
texto, no qual os problemas e suas causas seriam registrados. Logicamente, esse seria um primeiro nível de orga-
nização, que deveria evoluir com o tempo, fazendo uso de ferramentas modernas de recuperação dessas infor-
mações. No entanto, só para exemplificar, nos sistemas operacionais Windows, existe a função de busca de texto
dentro de arquivos. Essa seria uma forma inicial de recuperar as informações registradas nos arquivos de lições
aprendidas.
O importante é adotar os conceitos existentes no modelo de referência e adaptá-los à realidade da empresa.
Agora que já entendemos de maneira geral o processo de desenvolvimento de produtos descrito pelo modelo
deste livro e também conhecemos com um pouco mais de profundidade as macrofases desse processo, vamos es-
tudar quatro conceitos importantes desta nossa proposta. O primeiro é a sistemática de revisão de fases (gates).

2.7 Revisão de fases (gates)


No final de cada fase do processo de desenvolvimento, deve
acontecer uma revisão e aprovação formal dos produtos. Adota-se
o termo em inglês gate, que, traduzido literalmente, significa
portão. Ou seja, é a passagem de uma fase para outra. Se todos os
requisitos necessários forem cumpridos, pode-se iniciar a fase se-
guinte.
A introdução da sistemática formalizada de gates é uma prá-
tica que traz grandes benefícios para o desempenho da empresa.
Um entre os diferenciais do modelo proposto neste livro é o de
estabelecer formalmente a realização desse tipo de avaliação.
Em um primeiro momento, os requisitos que condicio-
navam a passagem de uma fase para outra estavam na verificação
Evolução da sistemática de
do cumprimento das atividades planejadas. Ou seja, se 10 tarefas tinham sido plane-
revisão de fases jadas para aquela fase e caso, ao final dela, verificava-se que elas tinham sido reali-
zadas, considerava-se, então, que o projeto estava cumprindo os objetivos. Em
seguida, passou-se a avaliar a qualidade dos resultados obtidos na fase. Essa verifi-
cação envolvia diversos aspectos tecnológicos, comerciais e financeiros. A geração
CAPÍTULO 2

O Modelo Unificado do PDP 71

mais recente da sistemática de gates considera ainda o valor do presente projeto perante os demais da empresa,
ou seja, responde às seguintes questões básicas e cruciais para a continuidade do projeto: As atividades foram
cumpridas, os resultados estão dentro dos previstos, mas será que ocorreram mudanças no mercado (necessi-
dade dos clientes, concorrência e condições econômicas) que inviabilizaram o sucesso do produto e, portanto, a
continuidade desse projeto? Se sim, deveríamos, então, investir os nossos recursos e esforços em outros pro-
jetos? Em outras palavras, coloca-se a perspectiva de negócio na avaliação do projeto para garantir que ele esteja
sempre alinhado às estratégias da empresa, pois, afinal de contas, foram com base nelas que se definiu o portfólio
de produtos/projetos (na fase de planejamento da estratégia).
Imagine que estamos criando uma nova impressora que imprime simultanea-
mente os dois lados de uma folha. Nós seremos os primeiros a lançá-la no mercado. Exemplo de gates
A tecnologia é cara, mas vale a pena, pois, ao sermos os primeiros, atingiremos um
grande volume de vendas, segundo os estudos de marketing que recebemos. Isso garantiria um fluxo de caixa
que pagaria todas as despesas com o desenvolvimento e a tecnologia, e o retorno seria ainda muito significativo,
segundo o estudo aprovado pelo setor financeiro.
Estamos no gate da fase de projeto informacional para ver se podemos passar para o projeto conceitual.
Cumprimos todos os prazos (na verdade, estamos dois meses adiantados) e as informações do projeto informacional
são alentadoras. No momento do gate, a inteligência de mercado traz a informação de que o nosso maior concor-
rente vai lançar em um mês uma impressora similar com a mesma tecnologia, ou seja, seis meses antes de conse-
guirmos colocar o primeiro lote piloto no mercado. O que fazemos?
Com o lançamento do produto do mesmo tipo pelo nosso maior concorrente, antes do nosso produto ino-
vador entrar no mercado, podermos ter o seguinte cenário:

I O volume previsto de vendas não será o mesmo, e, assim, as premissas do nosso estudo de viabilidade
econômica mudam.
I Provavelmente, não atingiremos mais os indicadores financeiros previstos na nossa análise de investi-
mento. Não teremos mais o retorno esperado. Vamos perder dinheiro com esse produto.
I Não seremos os primeiros a lançar o produto, e a nossa imagem de inovadores ficará cada vez mais desgastada.

Então, temos de tomar uma decisão dentro de certas alternativas: É melhor abortar o projeto agora do que
investir mais? Vamos passar o que desenvolvemos até agora para uma outra empresa? Devemos colocar os
nossos esforços em uma outra linha de impressoras de baixo custo, cujo desenvolvimento estava congelado, pois
não tínhamos recursos para desenvolver os dois produtos ao mesmo tempo?
Somente com uma revisão de fase que possibilite a visão geral do portfólio é que podemos tomar tais deci-
sões. É isso que significa um processo de gate segundo a melhor prática atual. É aquele no qual são considerados
conjuntamente os aspectos técnicos do produto, de gerenciamento do projeto e da situação do mercado, sem es-
quecer o projeto em relação aos demais produtos e projetos da empresa.
Pelo exemplo apresentado, pode-se observar que, no momento da revisão de fase, os
resultados do projeto são avaliados individualmente. Além disso, precisamos verificar se o Sistemática de gate
projeto ainda é o mais atrativo para empresa, considerando o portfólio de projetos.
A sistemática de gates está ilustrada na Figura 2.17 e possui as seguintes atividades:

I a definição dos critérios a serem utilizados ao final de uma fase;


I a avaliação constante pelo time de desenvolvimento se os critérios estiverem sendo cumpridos ou não; e
I a realização do gate propriamente dito, o qual é dividido em duas atividades:
• auto-avaliação realizada pelo próprio time de desenvolvimento; e
• aprovação; quando o relatório da auto-avaliação é analisado pelo time de avaliação, o presente projeto
é comparado com os demais do portfólio e com a análise do estudo de viabilidade econômica.
72 PARTE 1 O Processo

Na definição dos critérios, toma-se como base um “catálogo” de critérios, isto é, um conjunto de critérios
que serve como checklist.Esse catálogo deve fazer parte do modelo de referência da empresa. O time de desenvol-
vimento em conjunto com o time de avaliação define os critérios a serem utilizados em cada fase, assim como os
valores dos critérios quantitativos, escolhendo, desse catálogo, quais critérios são pertinentes para aquele pro-
jeto específico. Essa definição deve ocorrer bem antes do gate, porque, caso contrário, o time de desenvolvi-
mento tende a adotar somente critérios que eles sabem por antemão que serão aprovados (normalmente, esses
critérios são definidos nas atividades de planejamento do projeto e no gate anterior). É vantajoso também que os
responsáveis pela gestão do PDP identifiquem nesse catálogo quais critérios devem ser obrigatórios e quais são
uma opção do time de projeto, conforme a natureza do critério.

Figura 2.17 Sistemática de gates.

A premissa de que o time de desenvolvimento sabe com antecedência como o seu trabalho será avaliado,
tendo ele próprio participado da definição dos critérios, é fundamental para o sucesso da implantação dos gates,
pois possibilita a transparência do processo de avaliação. O gerente e o time conhecerão os critérios e, com isso,
estarão atentos a questões relevantes para a aprovação da fase do projeto.
A realização de gates é uma atividade coletiva e, como tal, acontece basicamente
Cuidados e planejamento por meio de reuniões. A eficiência com que as reuniões são planejadas e realizadas é
nas reuniões são fundamental para o sucesso da prática. É comum o surgimento de resistências quan-
fundamentais para o
sucesso dos gates
do as reuniões são vistas como improdutivas. O tempo consumido dos diversos téc-
nicos e gerentes envolvidos é um investimento que a empresa está realizando no
projeto e, como tal, precisa surtir resultados.
Valem os mesmos cuidados gerais para qualquer tipo de reunião de negócio, conforme o Quadro 2.4, a se-
guir. No caso específico de reuniões de gates, um problema muito comum é a dispersão. Nessas reuniões é
comum misturar gerentes e diretores, preocupados com o andamento do projeto em seu todo e os impactos no
negócio, com técnicos das diversas áreas: financeira, de engenharia e outras. Quando um problema eminente-
mente técnico emerge, por exemplo, os especialistas podem começar uma discussão técnica, fugindo do escopo
da decisão que, no caso, seria a solução em termos de ações que precisam ser realizadas. Nesses momentos, os
demais participantes sentirão a sensação de improdutividade. O mesmo acontece em questões gerenciais que
CAPÍTULO 2

O Modelo Unificado do PDP 73

dispersam para discussões conceituais ou o histórico do problema, desestimulando, dessa vez, as pessoas com
formação mais técnica. Deve-se redobrar, portanto, a atenção ao aspecto da dispersão ao se introduzir a sistemá-
tica de gates.

Quadro 2.4 Diretrizes para a Realização de Reuniões Produtivas

As atividades em grupo por meio de reuniões são uma das principais ferramentas durante todo o processo de desenvolvi-
mento de produto, em especial nos gates. Apesar das inúmeras vantagens, a produtividade desse tipo de trabalho pode ser
grandemente afetada pelo planejamento, transformando-o em um grande desperdício de tempo. Por isso, deve-se ter bas-
tante cuidado na realização de reuniões, observando-se as diretrizes a seguir.
1) Estabeleça o tipo de objetivo da reunião. Antes de planejar a reunião, identifique claramente o tipo de objetivo.
Existem reuniões cujo intuito é de decisão, isto é, espera-se obter consenso sobre determinadas questões. Outras são
reuniões de trabalho, em que uma determinada atividade deverá ser feita em comum. Ë conveniente sempre se-
pará-las, pois, enquanto reuniões de decisão são possíveis com uma quantidade maior de pessoas, as reuniões de tra-
balho tornam-se inviáveis quando o número é maior do que até dez pessoas. Além disso, geralmente as pessoas que
decidem fazem parte de um grupo maior do que daquele de quem executa. A estratégia e agenda dessas reuniões são
também distintas.
2) Defina uma pauta e comunique-a antecipadamente. Para que qualquer reunião possa funcionar adequadamente,
é preciso que as pessoas se preparem, consultando documentos ou mesmo lendo documentos que serão apreciados.
A pauta tem um papel fundamental e pode ser um documento bastante simples, na forma de uma mensagem eletrô-
nica — o importante é que ele discrimine claramente cada assunto, os participantes, data, local e, não se esqueça, o
tempo previsto para término.
3) Prepare o local e certifique-se antecipadamente de que os recursos necessários estejam preparados. O local
onde será realizada a reunião precisa ser preparado com todos os recursos multimeios e de apoio ao usuário. É funda-
mental que eles sejam testados e estejam ligados antes do horário da reunião — de preferência 15 minutos ou meia hora
antes. Os participantes devem encontrar o ambiente totalmente preparado para o início da reunião. No caso de apresen-
tações multimeios, é boa prática solicitá-las antecipadamente e deixá-las preparadas em um computador, pois é muito
comum atrasos para conexões de laptop, cópias de arquivos ou por falhas em disquetes ou equipamentos.
4) Exija e pratique a pontualidade. O início atrasado das reuniões causa um efeito “bola de neve”, incentivando novos
atrasos, e prejudicando a todos. Por isso, as reuniões devem começar pontualmente, evitando-se ao máximo a espera
por algum dos membros.
5) O papel de coordenador ou facilitador deve estar bem definido. É comum acontecerem reuniões nas quais várias
pessoas direcionam os assuntos. Corre-se o risco, assim, de promover a dispersão das pessoas. A solução ideal é que
haja um único e bem definido coordenador em cada reunião. Ele será o responsável por conduzir os assuntos e manter
o foco das pessoas na pauta e objetivos da reunião. Ele precisa saber como iniciar os trabalhos e conduzir democrática
e sistematicamente os assuntos.
6) Discuta rapidamente a pauta com os participantes, identificando metas de tempo para cada assunto. É boa prá-
tica dispensar um tempo curto, 15 minutos, no início da reunião para discutir a pauta, solicitando aos membros suges-
tões de mudança ou esclarecendo possíveis dúvidas. Ao final da discussão, o objetivo a ser atingido com o trabalho
precisa estar claramente identificado e ser um consenso entre os presentes. Uma boa prática é definir um intervalo de
tempo para cada assunto. Caso contrário, um assunto pode se estender demasiadamente, comprometendo parte dos
objetivos da reunião. No caso do grupo perceber o problema, deve-se tomar uma decisão que passará entre adiar o as-
sunto em questão ou mantê-lo e ocupar o tempo de outros assuntos da pauta. Outra boa prática é manter a lista com a
pauta ou agenda visível para todos os participantes. Os flip-charts são ótimos meios.
7) Defina o papel de monitoramento de tempo da reunião. Uma boa prática é delegar para um dos participantes da
reunião o papel de monitorar o relógio e avisar o grupo quando o tempo para um dos assuntos estiver em vias de ul-
trapassar o limite. O “calor” das discussões faz as pessoas se esquecerem do tempo e, delegando esse papel, au-
menta-se a chance de que esse aspecto seja continuamente avaliado.
8) Defina o papel de redator da ata da reunião. A ata é um instrumento fundamental para a comunicação dos resul-
tados da reunião e a garantia da realização das ações definidas. Deve-se, desde o início, delegar esse papel a um dos
participantes, que ficará responsável por publicar a ata após a reunião. Esse documento precisa apresentar de manei-

(continua)
74 PARTE 1 O Processo

Quadro 2.4 Diretrizes para a Realização de Reuniões Produtivas (continuação)

ra clara e sucinta os seguintes aspectos: data, local, lista de participantes, pauta, descrição dos assuntos principais e lis-
tagem das ações ou decisões realizadas. No caso das ações, a ata deve sempre descrever prazo e responsável para
cada ação. Uma prática muito útil é criar uma lista permanente, à vista de todos os participantes, na qual as ações e de-
cisões tomadas durante a reunião vão sendo anotadas, na frente de todos, para evitar erros de interpretação. Quando
essa lista não é compilada de forma transparente, um erro do redator poderá gerar uma grande confusão.
9) Mantenha um ambiente favorável à livre expressão. Quando um grupo é formado, é comum que alguns membros
se sobressaiam inibindo a expressão daquelas pessoas mais tímidas ou retraídas. O facilitador deve, a todo momento,
estar atento a esse aspecto. Ao verificar, pela expressão do rosto, que alguém não concorda com algo, deve lhe dirigir
a palavra, incentivando-o a expressar sua opinião. Além disso, nas reuniões de trabalho, ele deve adotar diferentes di-
nâmicas, tais como: jogos, trabalhos com cartões, divisão em grupos menores e outras técnicas que facilitem a inte-
ração e livre expressão de todos os participantes. As análises sistemáticas do tipo QFD e métodos criativos,
apresentados no Capítulo 6, são alguns exemplos de dinâmicas.

Uma medida fundamental nesse sentido é separar o trabalho de análise com o de decisão. Quando eles se
misturam, a probabilidade de dispersão aumenta. Análises devem ser delegadas para especialistas ou times de es-
pecialistas. Esses, por sua vez, produzem planos de ações e relatórios claros, com resumos executivos, que são
apresentados nas reuniões de caráter decisório. Elas, sim, com a participação dos diversos atores envolvidos —
gerentes, planejadores e técnicos com poder de decisão — e, portanto, com tempo e disponibilidade menores.
Todos devem receber os relatórios específicos com antecedência para que possam se preparar adequadamente
para a reunião. Aí, então, as reuniões de caráter decisório poderão transcorrer de maneira transparente e obje-
tiva, com o foco no que interessa: a decisão de ir adiante ou não com o projeto.
No caso de uma empresa muito pequena, na qual o time de projeto e o gerente
Tipos de gates assumem conjuntamente os papéis de especialistas, gerente do projeto e do time de
avaliação do produto (veja o Tópico 2.3), o gate pode ser feito por um conjunto pe-
queno de reuniões entre esse time — específicas para analisar todos os critérios e tomar a decisão final de apro-
vação ou não do projeto naquela fase. A auto-avaliação e a avaliação do gate, descritas anteriormente, são feitas
de uma única vez. Deve-se atentar para o fato de que, mesmo sendo as mesmas pessoas que realizaram o projeto,
o gate é para essas empresas uma forma sistemática do time avaliar o andamento dos trabalhos conjuntamente.
No caso de empresas maiores e com produtos mais complexos, os papéis do time de avaliação e de gerente
de projetos são comumente exercidos por diferentes pessoas. Uma solução em geral adotada nesses casos é criar
diferentes tipos de avaliações dentro do processo de gates.
A maneira mais simples é a criação de reuniões denominadas Revisões Técnicas (Design Reviews) e Revisões
de Planejamento (Project Reviews). As primeiras são feitas pelas pessoas que assumem os papéis de membros do
time de projeto, especialistas técnicos, parceiros do projeto e o gerente. Essa equipe revisará detalhadamente
todos os aspectos técnicos do projeto e emitirá parecer com a avaliação dos critérios do gate ligados a esse tipo de
questão. Essas reuniões dependem de uma grande preparação em que responsáveis por partes do produto anali-
sarão antecipadamente a qualidade e os problemas sob sua responsabilidade. Durante essa análise, novas ativi-
dades ou necessidades de retrabalho podem ser identificadas.
As revisões de planejamento são realizadas depois das revisões técnicas e têm como objetivo a verificação
dos demais aspectos do projeto, considerando o resultado da verificação técnica. Verifica-se o desempenho do
projeto em termos de tempo e comprometimento do orçamento, o impacto das dificuldades técnicas identifi-
cadas e novas atividades, o impacto de fatores externos e as mudanças no portfólio da empresa. Ao final, são ob-
tidos uma análise de todos os critérios do gate e o resultado final sobre a aprovação ou não da fase e condições e
direcionamentos para a próxima fase.
A revisão de projeto deve ser sempre realizada em duas etapas, conforme discutido no subtópico “Sistemá-
tica de gates”. A primeira, de maior duração, é realizada pelo time de projeto e o gerente. Eles avaliam todos os
critérios e criam o relatório de auto-avaliação que, então, é submetido para os atores que assumem o papel de
CAPÍTULO 2

O Modelo Unificado do PDP 75

time de avaliação. Eles se preparam estudando o relatório de auto-avaliação e realizam, assim, a reunião de re-
visão final em que participarão o time de avaliação e o gerente de projetos. Caso haja pontos controversos, ou-
tros participantes — como especialistas da própria empresa ou membros do time — poderão fazer parte da
reunião, para auxiliar durante a tomada de decisão nos gates em cada fase.
No final de cada fase do processo de desenvolvimento de produtos apresentado neste livro, repetem-se as
seguintes atividades genéricas de revisão (gate): avaliar fase e aprovar fase. Por serem genéricas, isto é, aplicáveis
a todas as fases, elas são descritas no Capítulo 3, a seguir, em tópicos separados, 3.4 e 3.5, respectivamente. Nos
tópicos correspondentes a essas atividades, dentro de cada fase, as atividades genéricas são citadas e adicionam-se
alguns critérios específicos relacionados àquela fase. Os critérios colocados são básicos e genéricos, compatíveis
com um modelo de referência genérico, pois, para cada tipo de produto, estratégia, tecnologia etc. devem ser de-
finidos critérios apropriados.
A sistemática de revisão de fase deve ser formalizada de forma clara e simples e
deve ser incorporada pela empresa e praticada pelos times envolvidos. Ela envolve A sistemática de revisão
as pessoas de nível superior da empresa na tomada de decisões, como membros do deve ser simples
time de avaliação.
Essa sistemática garante que as estratégias de produto e, por conseguinte, as da empresa estejam sendo
constantemente observadas em cada projeto. Assim, existem pontos de verificação quantificáveis, com os quais é
possível monitorar o progresso do projeto. Um dos elementos críticos para o sucesso da introdução da prática de
gates está nos critérios de avaliação utilizados.
Devemos ter critérios bem definidos e relevantes para realizarmos o gate. Esses
critérios não podem ser limitados somente a aspectos técnicos do produto, mas, Critérios de avaliação
também, a aspectos estratégicos, de marketing, manufatura, finanças e qualidade.
Eles devem ser abrangentes e devem fazer parte do modelo de referência de desenvolvimento de um determi-
nado tipo de produto. Além disso, precisam ser adaptados no início de cada projeto de desenvolvimento e no gate
da fase anterior, como mostrado na apresentação da sistemática de gate, e confirmados na atualização do planeja-
mento daquela fase específica.
Os critérios quantitativos estão associados a indicadores de medição de progresso do projeto (veja, mais à
frente, o Tópico 2.9). Um exemplo é o grau de maturidade de uma nova tecnologia a ser utilizada em produtos.
Deve-se garantir que, até o início da fase de projeto detalhado, esse indicador esteja com o valor de 100%, ou
seja, que a tecnologia a ser empregada já tenha sido avaliada e homologada. É comum algumas empresas empre-
garem tecnologia não maduras e, com isso, correrem riscos na introdução de um novo produto no mercado.
São os critérios qualitativos e quantitativos que vão nortear o desenvolvimento. O cumprimento de cada
critério significa que as atividades relacionadas com esse critério foram finalizadas e que seus resultados foram
entregues e possuem a qualidade exigida.
A boa prática do processo e a definição e aplicação dos critérios só acontece se a organização estiver estrutu-
rada para a realização dos gates.
O time responsável pelos gates é denominado no nosso modelo de time de ava-
liação. Em geral, ele é composto por pessoas da alta administração da empresa e por Time de avaliação
especialistas (convidados ou não) nas diversas tecnologias empregadas no produto.
Necessariamente, eles devem possuir uma visão ampla do portfólio de produtos e projetos da empresa. As pes-
soas do time de avaliação normalmente não são as mesmas do time de desenvolvimento para evitar que eles de-
fendam e escondam os possíveis erros ocorridos em uma fase. Em empresas pequenas, esse time pode ser
formado por pessoas da diretoria e um especialista, quando for o caso.
Um dos problemas das empresas que começam a adotar a sistemática de gates é
que elas avaliam todos os seus projetos da mesma forma. Cada projeto deve ser clas- Diferenciar os gates por
sificado e, para cada tipo de projeto, deve ser adotado um procedimento diferente. tipo de projeto
Projetos muito simples — por exemplo, que provavelmente envolvam o desenvolvi-
76 PARTE 1 O Processo

mento de um produto simples (derivado de um produto existente) — devem ser submetidos a somente alguns
critérios técnicos. É sempre importante avaliar o impacto no portfólio de produtos e projetos da empresa.
Depois de conhecer o primeiro conceito auxiliar do modelo de referência deste livro, vamos passar para o
segundo, que trata dos métodos e ferramentas de desenvolvimento de produtos constantes dessa proposta.

2.8 Métodos e ferramentas de desenvolvimento de produtos


Métodos e ferramentas são meios que existem para apoiar a realização das ativi-
Métodos e ferramentas
dades de PDP e, muitas vezes, são utilizados como sinônimos. Exemplos de mé-
são sinônimos
todos são: Quality Function Deployment (QFD), Design for Manufacturing and
Assembly (DFMA), Failure Modes and Effects Analysis (FMEA),
projeto robusto etc. Esses métodos também são conhecidos como
ferramentas de apoio ao PDP. Porém, o termo ferramentas é mais
utilizado para definir sistemas de informação, tais como: Com-
puter Aided Design (CAD), Computer Aided Process Planning
(CAPP), Computer Aided Engineering (CAE), Product Data Ma-
nagement (PDM) etc.16
Durante a descrição do modelo são apresentadas as várias
ferramentas de informática que podem melhorar a eficiência e a
eficácia do processo de desenvolvimento de produtos. Mas, além
do benefício específico que cada uma delas pode proporcionar,
existe uma forte tendência no sentido da integração. Os Sistemas
Integrados de Gestão Empresarial (ERP, Enterprise Resource
Planning), que, na última década, vêm se disseminando nas organizações, são a plataforma básica dessa inte-
gração. Eles começaram com foco na manufatura e finanças e, atualmente, estão cada vez mais suportando a in-
tegração com as ferramentas de planejamento e execução de projetos de engenharia. Essa mudança é
significativa, pois, no passado recente, os sistemas de informação das áreas de engenharia trabalhavam de manei-
ra isolada do dia-a-dia da empresa. Isto é, a direção tinha idéia apenas da quantidade de dinheiro e tempo gastos.
Os resultados eram vistos no final, com o produto pronto. Com essa integração de ERPs e as outras ferramentas,
a gestão integrada de todo o ciclo de vida dos produtos está se tornando uma realidade, (veja o Quadro 2.5).

Quadro 2.5 Sistemas ERP e Soluções Relacionadas: CRM, SCM e PLM

Com o avanço da tecnologia da informação (TI), as empresas passaram a utilizar sistemas computacionais para suportar
suas atividades. Geralmente, em cada empresa, vários sistemas foram desenvolvidos para atender aos requisitos específicos
das diversas unidades de negócio, plantas, departamentos e escritórios. Por exemplo, o departamento de planejamento da
produção utiliza um sistema próprio e o departamento de vendas utiliza outro. Dessa forma, a informação fica dividida entre
diferentes sistemas.
Os principais problemas dessa fragmentação da informação são a dificuldade de obtenção de informações consolidadas
e a inconsistência de dados redundantes armazenados em mais de um sistema. Os sistemas ERP solucionam esses pro-
blemas ao agregarem, em um só sistema integrado, funcionalidades que suportam as atividades dos diversos processos de
negócio das empresas.
Os sistemas ERP surgiram a partir da evolução dos sistemas Material Resource Planning, (MRP, Planejamento de Recursos
de Manufatura). Neles, foram agregadas várias funções, e ele passou a ser chamado de MRP II. Com o objetivo de ampliar a
abrangência dos produtos vendidos, os fornecedores de sistemas desenvolveram mais módulos, integrados aos módulos de
manufatura, porém com escopo que ultrapassa os limites da manufatura. Como exemplo, foram criados os módulos de Ge-

(continua)
16
Os significados dessas siglas podem ser consultados no Apêndice III deste livro, e uma explicação mais detalhada desses métodos e fer-
ramentas citados encontra-se em quadros posicionados dentro da descrição da atividade mais apropriada à sua aplicação.
CAPÍTULO 2

O Modelo Unificado do PDP 77

Quadro 2.5 Sistemas ERP e Soluções Relacionadas: CRM, SCM e PLM (continuação)

renciamento dos Recursos Humanos, Vendas e Distribuição, Finanças e Controladoria, entre outros. Esses novos sistemas,
capazes de suportar as necessidades de informação para todo o empreendimento, são denominados sistemas ERP.

Estrutura típica dos sistemas ERP


Os sistemas ERP são compostos por uma base de dados única e por módulos que suportam diversas atividades das em-
presas. A Figura 2.18 apresenta uma estrutura típica de funcionamento de um sistema ERP. Os dados utilizados por um mó-
dulo são armazenados na base de dados única, para serem manipulados por outros módulos.

Figura 2.18 Estrutura típica de um sistema ERP.

Com o advento da Internet e a especialização dos sistemas ERP em sistemas verticais voltados para certos tipos de seg-
mentos, a grande parte dos fornecedores o dividiu em três grandes suítes de módulos (alguns adotaram outro tipo de divisão):
CRM (Customer Relationship Management): CRM visa entender e antecipar as necessidades dos clientes potenciais e
dos atuais (base instalada). O objetivo é conhecer o cliente e atendê-lo melhor; com isso, procura-se reter os clientes atuais,
para que ele compre mais. Além disso, o conhecimento dos clientes potenciais permite que sejam tomadas medidas especí-
ficas e eficazes para conquistá-los. Isso envolve captar todas as possíveis informações sobre eles, consolidá-las em um banco
de dados, analisá-las para identificar padrões, distribuir resultados para todos os pontos de contato e usar essas informações
para interagir com os clientes. O CRM integra módulos de automação de vendas, gerência de vendas, telemarketing, tele-
vendas, atendimento ao cliente, soluções para informações gerenciais, Web e comércio eletrônico.
SCM (Supply Chain Management): SCM integra os processos de negócios dos parceiros da cadeia de suprimentos, en-
volvendo desde a produção até a distribuição. SCM não contempla apenas a área de suprimentos de produtos, mas também
a demanda de mercado, vendas, compras, recebimento, estoques dos parceiros, planejamento de produção, transporte etc.
Os módulos do SCM compreendem o núcleo do sistema ERP.
PLM (Product Life-Cycle Management): PLM contempla a criação e a gestão das informações de produto e os projetos
de desenvolvimento. PLM integra todas as soluções de tecnologia de informação relacionadas com o PDP. Em razão de sua
importância para este livro, existem quadros específicos sobre PLM e seus principais componentes. Veja, no decorrer dos ca-
pítulos, os seguintes quadros:

(continua)
78 PARTE 1 O Processo

Quadro 2.5 Sistemas ERP e Soluções Relacionadas: CRM, SCM e PLM (continuação)

• Sistemas PLM
• Sistemas de Gerenciamento de Projetos
• Sistemas CAD/CAE/CAM
• Sistemas CAPP
• Sistemas CSM integrados ao e-procurement
• Sistemas PDM/EDM
• Sistemas GED
• Manufatura virtual
Como base para a operação dessas três suítes, estão os demais módulos de gestão financeira e de recursos humanos do
ERP, já citados na Figura 2.18.
A Figura 2.19 apresenta, de forma conceitual, a integração entre essas três suítes de software, destacando-se a intensi-
dade de seu uso nas fases de desenvolvimento de produtos.

Figura 2.19 Integração das soluções de CRM, SCM e PLM ao longo do ciclo de vida do produto, relacionada com o modelo de
referência de desenvolvimento de produtos (adaptado da figura de SAP).

Durante as macrofases de pré-desenvolvimento e desenvolvimento, o principal sistema utilizado é o PLM. Mas a base de
dados do CRM é muito importante para ser utilizada na fase de planejamento estratégico de produto e na fase de projeto in-
formacional, quando se procura determinar padrões de clientes a serem contatados para pesquisas de mercado. CRM é
também aplicado para se definir requisitos a partir de dados levantados dos processos de apoio, tais como: atendimento a
clientes e assistência técnica. SCM é utilizado para o cálculo de necessidades de capacidade futuras com base nas programa-
ções existentes, para a compra e cotação de material, além da gerência dos fornecedores.
Na fase de produção, o SCM entra em primeiro plano e o CRM acompanha as reações dos clientes às campanhas de lança-
mento. O PLM é mais utilizado no início para gerenciar as possíveis mudanças de engenharia, mas, depois, entra em uma
época de manutenção da configuração.
Após o término da produção, o PLM tem um papel relativo mais importante novamente, pois é responsável pela manu-
tenção e atualização dos dados de produto.
Hoje já se fala em ERP II, que conota a distribuição dos sistemas ERP por todos os parceiros da cadeia de suprimentos via
Internet. A interface comum entre todos os usuários é um portal corporativo (ou da cadeia), que é personalizado para cada
usuário, contendo funcionalidades à disposição que podem apoiar as suas atividades específicas.
CAPÍTULO 2

O Modelo Unificado do PDP 79

Os métodos contêm normalmente uma lista de passos que devem ser seguidos
para se atingir os objetivos para os quais eles se propõem. Métodos apresentam uma
seqüência de passos
Toda publicação de desenvolvimento de produtos apresenta alguns desses mé-
todos inseridos nas fases e atividades do PDP. Como a origem desses métodos co-
mumente não estava relacionada com uma visão de processo, freqüentemente surge uma dúvida ao se relacionar
os passos propostos por esses métodos e as atividades do PDP. Ou seja, existe atividade que é completamente reali-
zada por um método; existe atividade que utiliza mais de um método (ou passos de diferentes métodos); e
existem métodos que abrangem várias atividades. Por exemplo, o método QFD é utilizado nas seguintes ativi-
dades da fase de projeto informacional (veja o Capítulo 6):

I identificar os requisitos dos clientes do produto;


I definir requisitos de projeto do produto; e
I definir especificações de projeto do produto.

Para manter o foco no modelo de PDP e evitar a repetição de conteúdos farta-


mente desenvolvidos em outras publicações, este livro traz resumos dos principais A descrição desses
métodos e ferramentas, que são registrados em quadros. Esses quadros são posicio- métodos e ferramentas
neste livro
nados no texto, de forma a se relacionar com as atividades mais afins. No final de
cada capítulo, são listadas as principais referências bibliográficas que trazem infor-
mações adicionais sobre esses métodos e ferramentas.
Dessa forma, o leitor obtém as informações essenciais sobre o método e sua aplicabilidade no PDP, e en-
contra fontes para se aprofundar no entendimento do método caso julgar interessante. O mesmo ocorre com a
descrição dos sistemas de informação apropriados.
Vamos conhecer agora o terceiro conceito importante relacionado com o modelo proposto por este livro:
os indicadores de desempenho do PDP.

2.9 Indicadores de desempenho do PDP


Como todo processo de negó-
cio, o desenvolvimento de produto Tipos de indicadores
deve ser monitorado por meio de in-
dicadores de desempenho.
A literatura de desenvolvimento de produtos propicia diversos
indicadores que podem ser utilizados para a avaliação desse processo.
Há indicadores ligados ao desempenho do produto no mercado, que
servem para uma avaliação indireta do processo de DP que o gerou,
bem como há outros indicadores que tratam diretamente da avalia-
ção dos projetos de desenvolvimento em si, quanto a sua realização
geral e das principais partes ou etapas que o compõem. Esses indica-
dores podem ser focados tanto na avaliação de todo o portfólio de
projetos/produtos como na avaliação particular de alguns deles.
Esse tipo de indicador monitora a produtividade do PDP avaliando o portfólio
de produtos de maneira unificada, sem diferenciar os projetos individuais de desen- Indicadores do PDP que
volvimento e preocupando-se com a contribuição desse processo aos objetivos es- agregam informações
de todos os projetos
tratégicos gerais da empresa. Esses indicadores, assim como os seus valores, são e produtos
normalmente determinados durante o planejamento estratégico e tipicamente são
atualizados ano a ano. Na Figura 2.20 são apresentados os indicadores desse tipo
mais utilizados pelas empresas, sem, no entanto, entrar em detalhes de como le-
vantá-los. Toda empresa deve definir os indicadores mais apropriados, segundo a
80 PARTE 1 O Processo

sua estratégia, as restrições em termos de obtenção dos dados e de forma integrada com os demais indicadores de
gestão do negócio da empresa.17

Figura 2.20 Porcentagem de uso de indicadores para medir a produtividade do processo de desenvolvimento de produtos por em-
18
presas em 2002.

O segundo grupo de indicadores de desempenho estão relacionados com quatro dimensões de avaliação:

Sucesso financeiro (lucros, metas e crescimento de vendas, percentual de


I
vendas dos novos produtos, participação de mercado — market-share, tem-
Indicadores relacionados po/retorno de investimento, metas de margem e lucratividade etc.).
com projetos individuais
I Sucesso operacional (custos e tempos de desenvolvimento, diretrizes de
qualidade atingidas, velocidade, produtividade do desenvolvimento).
I Sucesso em qualidade (grau de aceitação pelo consumidor, satisfação do cliente, tempo de permanência
no mercado).
I Sucesso perceptivo (avaliações realizadas pela equipe e pelo gerenciamento, aprendizagem para futuros
projetos).

Os indicadores de sucesso operacional e parte dos indicadores de sucesso em qualidade e perceptivo são
equivalentes aos indicadores da área de gestão de projetos, pois o desenvolvimento de um produto específico
ocorre por meio de projetos. Sendo assim, é possível avaliar diretamente os projetos de desenvolvimento em si,
inclusive desdobrando os indicadores dessa categoria para avaliar as fases que o compõem. Veja no Capítulo 5,
Tópico 5.12, o detalhamento proposto desses indicadores, que deve ocorrer durante o planejamento do projeto.
Pode-se considerar que o processo de desenvolvimento de um produto foi bem-sucedido (teve um bom de-
sempenho) se o produto resultante for aceito no mercado tal qual a previsão inicial ou, melhor, se trouxe a renta-
bilidade planejada para os investimentos, se contribuiu para fortalecer a imagem da marca conforme o esperado
e se permite futuros lançamentos de produtos derivados. Esses são resultados atrelados aos objetivos maiores da
empresa (faturamento, rentabilidade, aumento da participação no mercado etc.) e cada projeto/produto possui a
sua margem de contribuição para a avaliação do PDP.

17
Os indicadores do processo de desenvolvimento de produtos devem estar coerentes com o desdobramento de indicadores globais da
empresa. As empresas atualmente utilizam metodologias para gestão de indicadores, como os do Balacend Scorecard, para desdobrar
indicadores para toda a organização.
18
American Productivity and Quality Center (APQC), Measuring Research and Development (R&D) Productivity Webseminar, 3/6/2004.
CAPÍTULO 2

O Modelo Unificado do PDP 81

Como mencionado no tópico que discute as revisões das fases, alguns desses
indicadores podem ser utilizados na sistemática de gate, juntamente com os critérios Indicadores de
de aprovação. A definição dos indicadores apropriados depende da estratégia de desempenho neste livro
cada empresa e deve ocorrer quando se implanta o modelo proposto neste livro e se
institucionaliza o PDP.
Vamos agora conhecer o último conceito complementar ao modelo apresentado, que discute sobre os par-
ceiros de desenvolvimento dentro de uma cadeia de suprimentos.

2.10 Parceiros do desenvolvimento colaborativo de produtos


Cada vez mais o processo de desenvolvimento de produtos
de uma empresa é realizado em conjunto com os seus parceiros, o
que pode acontecer desde as primeiras fases do desenvolvi-
mento.19 O modelo deste livro considera as necessidades de um
desenvolvimento colaborativo. As práticas nesse sentido estão em
vários detalhes específicos das diversas partes do modelo. O obje-
tivo deste tópico é ressaltar essas características de colaboração
para que possam ser entendidas e utilizadas.
A primeira característica que au-
xilia a colaboração é considerar os Time de desenvolvimento
parceiros como possíveis membros estendido: o importante
papel dos parceiros
do time de desenvolvimento. Podem
ser representantes de clientes ou fornecedores muito importantes que fazem parte
do time e, portanto, atuam ativamente desde o início do projeto. Certamente, a quantidade não conta, pois par-
ticipar desse time significa ser responsável por atividades diretas de desenvolvimento e ter acesso às decisões so-
bre o projeto. Esse tipo acontecerá quando o projeto de desenvolvimento for estratégico para a empresa cliente
ou fornecedora e esse parceiro detiver uma competência essencial para contribuir com o projeto. No caso das
empresas clientes, essa competência pode ser o conhecimento sobre os requisitos do mercado, por exemplo,
quando a empresa pretende entrar em um novo ramo e se associa a uma outra empresa com larga experiência no
mercado. No caso das empresas fornecedoras, a competência essencial geralmente é a capacidade de projetar um
determinado subsistema que fará parte do produto. Nesse caso, o representante do fornecedor participará da
equipe de projeto e será responsável pela especificação, projeto e teste do subsistema. Em qualquer um dos
casos, a última condição essencial para que esse nível de cooperação seja interessante é a confiança entre as em-
presas parceiras. Participar do time do projeto significa também ter acesso à área de desenvolvimento da empre-
sa e de informação muitas vezes confidenciais. Uma boa estrutura jurídica pode aumentar a segurança da
empresa, mas experiência prévia de trabalho com o parceiro e confiança nas pessoas envolvidas são fundamentais
para que o trabalho conjunto seja produtivo.
A participação do parceiro no time de projeto demonstra um nível elevado de
cooperação. Convém destacar que existem diferentes níveis de parceria, com níveis Tipos de parceiros
menos significativos de envolvimento. Devemos conhecer os papéis que cada um existentes
dos tipos de parceiros assume dentro do processo de desenvolvimento de produtos e
saber utilizá-los de forma coerente para fortalecer o processo de desenvolvimento. Uma parceria mal definida
pode causar problemas que drenam tempo precioso da gerência na solução de conflitos.
No setor que estamos tratando neste livro, bens de consumo duráveis e de capital, existem os seguintes
tipos de elos na cadeia de suprimentos:

19
No Apêndice II, há um termo em inglês bem conhecido (Early Supplier Involvement, ESI) que é utilizado para representar esse envol-
vimento.
82 PARTE 1 O Processo

I Montador: Fornece seus produtos para o mercado de consumo final e possui contato com os consumi-
dores. Exemplo: fabricantes de eletrodomésticos, produtos da linha branca (máquinas de lavar, seca-
doras, geladeiras etc.), automóveis, eletroeletrônicos etc.
I Fornecedor de equipamentos e ferramental: É como o montador, mas o seu produto é o meio de produção
de um cliente final. Tanto ele quanto o montador podem comprar de um outro fornecedor de equipa-
mentos e ferramental. Esses equipamentos e ferramental podem ser universais, como uma máquina-fer-
ramenta de linha (exemplo, torno CNC), ou um equipamento ou ferramental específicos projetados
para produzir um produto em particular (exemplo, uma máquina para montagem de um motor elétrico).
Exemplo: fornecedor de moldes de injeção e forjamento, de equipamentos de medição etc.
I Fornecedor de primeiro nível: Fornece sistemas que fazem parte de um produto final de um montador ou
fornecedor de equipamentos. Exemplo: fornecedor de chassis e estrutura para indústria de caminhões,
motores de combustão etc.
I Fornecedor de segundo nível: Fornece subsistemas ou componentes que fazem parte dos produtos dos for-
necedores de primeiro nível. Exemplo: fornecedor de motor elétrico, controles etc.
20
I Fornecedor de commodities : Fornece subsistemas ou componentes padronizados no mercado, isto é, cujas
características básicas são definidas por normas seguidas por todas as empresas que atuam no setor e o
nível de qualidade é similar. Como resultado, os produtos de diferentes concorrentes podem ser inter-
cambiáveis e a definição de onde comprar é baseada essencialmente no preço, dado que a qualidade é equi-
parada pela obediência aos padrões. Normalmente, esses produtos são utilizados por empresas de várias
cadeias produtivas. Exemplos: fornecedor de rolamentos, peças-padrão, anéis de vedação, filtros etc.
I Fornecedor de matéria-prima: Freqüentemente um fornecedor de matéria-prima é tratado como um de
commodities. Porém, surgem hoje em dia materiais especiais (como plásticos condutores de eletricidade,
plásticos de engenharia etc.) e, nesses casos, essas empresas assumem papéis diferentes, podendo inclu-
sive participar do PDP no momento da especificação dos requisitos do produto.
I Fornecedor de tecnologia: Desenvolve tecnologia a ser incorporada nos produtos dos parceiros da cadeia de
suprimentos. Normalmente, eles possuem centros de pesquisa e desenvolvimento. No Brasil, não é
usual encontrar empresas desse tipo — como no exterior. Em geral, a tecnologia é desenvolvida em ins-
tituições de pesquisa (como universidades e institutos estatais) ou em áreas de P & D dentro das próprias
empresas. Mas, na maior parte das vezes, a tecnologia vem de outros países, normalmente sede de multi-
nacionais aqui instaladas.
I Fornecedor de serviços: Há fornecedores de serviços de desenvolvimento (a serem contratados para rea-
lizar alguma tarefa de um projeto de desenvolvimento de um produto) e de serviços envolvidos com a
manufatura do produto final. Exemplos da primeira categoria: fornecedor de serviços de desenhos, cál-
culos, prototipagem, marketing, grupo focal para levantamento de necessidades, entrevista de mercado
etc. Exemplos da segunda categoria: serviços de usinagem especial, tratamento térmico, medição di-
mensional, injeção plástica etc.

Algumas empresas podem ser classificadas em mais de um tipo ao mesmo tempo. Um caso típico é no for-
necimento de peças plásticas injetadas. Alguns fornecedores realizam somente a operação de injeção plástica, ou
seja, possuem um parque de injetores e vendem o serviço de injeção. O cliente é responsável por todas as outras
atividades, e ainda traz o molde de injeção. Outros fornecedores especializaram-se no setor de moldes de injeção
plástica, e realizam o projeto do molde (simulando por computador o processo de injeção) e podem participar
das fases de desenvolvimento de produtos, trazendo os seus conhecimentos na definição do estilo mais apro-
priado para o processo de injeção. Outros, ainda, abrangem todo o ciclo de peças injetadas.
A Figura 2.21 mostra o relacionamento comum encontrado entre esses tipos de fornecedores dentro de
uma mesma cadeia de suprimentos.

20
Usualmente, adota-se o termo em inglês, por não haver termo apropriado em português. O mais próximo é fornecedor de produtos-
padrão, mas não é usual.
CAPÍTULO 2

O Modelo Unificado do PDP 83

Figura 2.21 Tipos de parceiros dentro de uma mesma cadeia de suprimentos.

No modelo unificado, utilizaremos a classificação apresentada na Figura 2.22


para identificar os diferentes tipos de fornecedores.21 Tipos de relacionamento
com fornecedores no
modelo unificado
I Parceiro de risco: Ocorre quando uma empresa se associa à empresa que está
coordenando o desenvolvimento e irá colaborar e dividir os riscos. Os con-
tratos são de longo prazo, deverão durar toda a vida do produto, e a empresa participa de todas as deci-
sões fundamentais no desenvolvimento e na comercialização. Geralmente, o parceiro assume o
investimento no desenvolvimento e no custeio da produção de um subsistema do produto. Em troca, re-
ceberá uma parte das receitas de vendas. Ele é envolvido em todas as etapas do PDP. Ocorre normal-
mente com os fornecedores de primeiro nível;
I Parceiro de tecnologia: É essencial para existir inovação no produto. O objeto de fornecimento é a tecno-
logia, que pode fazer parte do produto do fornecedor. Muitas vezes, é uma empresa dentro do mesmo
grupo, ou laboratório de Pesquisa e Desenvolvimento da organização. Em geral, esse papel é assumido
pelo fornecedor de tecnologia, mas pode ocorrer com um fornecedor de máquinas e/ou de primeiro
nível, quando a sua tecnologia for um diferencial para o produto final. Atualmente, instituições como
universidades e centros de pesquisa têm assumido esse papel, fechando contratos de longo prazo com
empresas.

21
Essa nomenclatura é adequada para os tipos de produtos nos quais uma empresa principal, a empresa cliente, coordena todo o processo
de desenvolvimento de produtos. Há casos, como na construção civil, construção de navios e outros, que fogem ao escopo do modelo
unificado em que há um consórcio de empresas que realiza o projeto, liderado pela empresa que será a consumidora final do produto, a
contratadora. Nesse caso, essa tipologia não é de todo adequada.
84 PARTE 1 O Processo

Figura 2.22 Tipos de relacionamento com os fornecedores no PDP.

I Co-desenvolvedor: Este nome é dado ao fornecedor que participa da definição dos requisitos do subsis-
tema e do seu desenvolvimento. Geralmente, são responsáveis por sistemas ou módulos complexos e
possuem domínio completo da tecnologia, gerando as possíveis concepções do subsistema e, muitas
vezes, sugerindo alterações. Eles podem ou não produzir as peças mais tarde. Em caso afirmativo, esta-
belecem contratos de longo prazo com o fornecedor principal, garantindo a compra do subsistema por
um período de anos ou a vida toda do produto principal. O caso em que não irão produzir diz respeito a
empresas especializadas em engenharia (veja o Quadro 2.6, a seguir). São empresas formadas por téc-
nicos e engenheiros que dominam a tecnologia e auxiliam na especificação, mas não possuem recursos
para produzir os produtos. Na Figura 2.22, eles foram separados ainda em duas categorias, um deles de-
nominado de parceiro. Tais parceiros são co-desenvolvedores que participam da equipe de projeto e,
portanto, auxiliam também na especificação do produto final. Normalmente, o co-desenvolvimento
acontece com os fornecedores de primeiro nível.

Quadro 2.6 O Surgimento da Parceira com Fornecedores e das Empresas Especializadas em Serviços de Engenharia

Os setores de engenharia surgiram dentro das empresas com a produção em massa. Até aquela época, os produtos eram pro-
jetados e construídos artesanalmente, muitas vezes pelo mesmo grupo de pessoas. Portanto, era difícil separar o trabalho de pro-
dução com a especificação dos produtos. A produção em massa alterou profundamente essa lógica. O requisito básico para a
produção em série é a padronização dos componentes, que se inicia pela especificação detalhada. O sucesso da produção em
massa fez surgir os departamentos de engenharia nas grandes corporações, as quais, no seu apogeu, eram responsáveis pela es-
pecificação de cada um deles. Isso significa milhares de profissionais trabalhando para detalhar o produto completamente.
Essa situação perdurou até recentemente. Um estudo realizado no início da época de 1990 constatou, por exemplo, que
as montadoras de carros, com exceção das japonesas, realizavam a grande maioria do trabalho de engenharia. Os fornece-
dores recebiam os desenhos das peças e eram obrigados a segui-los à risca.

(continua)
CAPÍTULO 2

O Modelo Unificado do PDP 85

Quadro 2.6 O Surgimento da Parceira com Fornecedores e das Empresas Especializadas em Serviços de Engenharia (continuação)

Essa situação causava um conjunto grande de ineficiências. O número de funcionários era maior. Os engenheiros das em-
presas não conheciam detalhadamente as máquinas e equipamentos de todos os fornecedores, causando custos adicionais
ou mudanças e redesenho das peças. Os fornecedores tinham menos espaço para sugerir alterações que poderiam me-
lhorar a fabricação.
A situação começou a mudar quando as empresas japonesas demonstraram as vantagens de envolver cada vez mais os for-
necedores, delegando-lhes responsabilidades de detalhamento e desenvolvimento das especificações das peças e processos.
As empresas começaram a perceber também que certos subsistemas e componentes não representavam diferencial sig-
nificativo no desempenho de seus produtos. Na linguagem utilizada, eles não eram core, isto é, não eram essenciais para a
empresa, pois o cliente final não sentia os seus efeitos e, portanto, não impactavam na competitividade do produto. Havia
também certos testes que exigiam uma grande infra-estrutura física e técnicos especializados, e eram subutilizados. Isso sig-
nifica custos adicionais no desenvolvimento dos produtos da empresa como um todo. Passou-se, então, a subcontratar os
serviços de engenharia de empresas especializadas, muitas delas formadas por ex-funcionários, e até mesmo de concor-
rentes. Por exemplo, existem empresas especializadas em projetos de lentes e que vendem esse serviço para empresas inte-
ressadas em incorporar tal tecnologia em seus produtos. Subcontratar um serviço desse tipo certamente valeria a pena se
esse não fosse um item core da empresa. Imagine o custo de buscar um profissional no mercado, contratá-lo e montar labo-
ratórios específicos.
O resultado dessas mudanças é que parte significativa das atividades de desenvolvimentos são atualmente realizadas
fora da empresa responsável pelo desenvolvimento de produto, conforme ilustra esquematicamente a Figura 2.23. O pro-
blema que os profissionais e gerentes de projeto enfrentam é saber quando é melhor projetar e produzir in house e quando
subcontratar. Uma dica é a seguinte, os subsistemas e componentes essenciais (core) para o desempenho do produto de-
verão sempre ser desenvolvidos pela empresa principal, ou por parceiros de absoluta confiança e laços financeiros estáveis
e de longo prazo. Os subsistemas não essenciais, mas complexos e que demandam uma competência bem especializada,
poderão ser prioritariamente delegados para parceiros tecnológicos e de co-desenvolvimento. Em todos esses casos, os for-
necedores precisarão ser envolvidos nas fases iniciais do processo de desenvolvimento de produto. Os módulos e compo-
nentes padronizados serão procurados no mercado no momento em que forem necessários, provavelmente na fase de
preparação da produção, e serão adquiridos de fornecedores de peças-padrão, cujo relacionamento em termos de desen-
volvimento de produto será pequeno ou inexistente. Há a possibilidade de restarem certos componentes que não são pa-
dronizados e poderiam ser desenvolvidos tanto internamente como por um fornecedor. Eles merecem uma análise make or
buy que será feita na fase de detalhamento.
Figura 2.23 Tipos de fontes de origem dos componentes de um produto manufaturado.
86 PARTE 1 O Processo

I Fornecedores de serviços: São fornecedores que possuem um alto nível de capacitação técnica, mas, dadas as
características do produto e do processo de fabricação, têm uma interface menor com o processo de de-
senvolvimento em si. Eles recebem os requisitos do produto e peças prontos da empresa cliente e desen-
volvem a solução, podendo ou não oferecer sugestões de alterações. Nesse caso, visando principalmente
a melhoria na manufaturabilidade das peças. Na Figura 2.22 foram classificados em dois tipos. Os pri-
meiros são os fornecedores de serviços de engenharia, isto é, aqueles que recebem os requisitos do sub-
sistema, os desenvolvem e podem ou não ser responsáveis pela sua fabricação. Os fornecedores de
serviços de manufatura desenvolvem ferramentais, máquinas operatrizes, sistemas de automação, dispo-
sitivos de medição, teste e posicionamento, entre outros recursos necessários para a fabricação. Os for-
necedores de segundo nível e alguns de primeiro podem assumir esse papel.
I Fornecedor de peças-padrão: Trata apenas da produção de sistemas e componentes de menor valor agre-
gado e não possui acordos de parcerias. Nesses relacionamentos, o que importa são apenas o prazo e o
custo de seus produtos. Esse é o caso dos fornecedores de commodities e de segundo nível, quando os seus
produtos não forem estratégicos para o cliente. Nesse caso, o fornecedor desenvolve os produtos e os
comercializa por meio de catálogos.

Conforme os tipos de empresa mostrados e as suas formas de relacionamento,


Por que conhecer os tipos o conteúdo do modelo precisa ser adaptado.
de empresa e as suas
formas de relacionamento As descrições de algumas atividades existentes na Parte 2 serão diferenciadas,
dentro de uma cadeia dependendo do papel da empresa dentro da cadeia: se ela for uma empresa cliente
de suprimentos? final da cadeia (montadora) ou fornecedora intermediária (fornecedor de primeiro
nível ou de equipamentos). No decorrer da apresentação do modelo, poderá ser ob-
servado que, desde as primeiras fases, os parceiros de risco e estratégicos estão envolvidos, participando inclu-
sive do time de desenvolvimento. Em fases posteriores, os co-desenvolvedores atuarão, e, em outras, os
fornecedores de commodities serão convidados para enviar cotações de seus produtos.
Agora que já conhecemos os quatro elementos conceituais auxiliares do modelo, vamos conhecer uma
outra forma de agrupar as atividades descritas na Parte 2 deste livro.

2.11 Áreas de conhecimento


As macrofases desse modelo são
Modelo deste livro é
divididas em fases, que, por sua vez,
organizado por fases, pois
agrupam as atividades, as quais, em
é mais didático
alguns casos, ainda são detalhadas
em tarefas. Essa forma de apresen-
tação tem como foco principal a evolução do produto em si.
Dentro de uma visão integrada e multidisciplinar, é a forma mais
didática de apresentar o desenvolvimento de produtos, que é o ob-
jetivo principal deste livro, pois reflete a realidade (os passos) dos
processos de desenvolvimento das empresas.22 Como a quantidade
de atividades é grande, esse agrupamento por fases também facilita
o seu entendimento, organizando-as segundo o enfoque temporal.
Mas existem outras formas de visualizar o desenvolvimento.
As atividades podem ser Uma delas é classificando as atividades segundo as áreas clássicas relacionadas com
classificadas por área de o desenvolvimento de produto A vantagem de agrupar as atividades em áreas de co-
conhecimento
nhecimento é demonstrar a contribuição de cada uma delas para o processo de de-
senvolvimento. Um especialista interessado em conhecer qual sua potencial
contribuição ou interessado em verificar a consistência do modelo em relação àquela área do conhecimento po-

22
Como será discutido na Parte III deste livro, essa seqüência pode ser ajustada para a particularidade de cada processo de desenvolvimento.
CAPÍTULO 2

O Modelo Unificado do PDP 87

deria fazê-lo mais facilmente havendo essa classificação. Isso é importante porque a maior parte das empresas
possui estruturas funcionais voltadas para áreas de conhecimento específicas. Por exemplo, possíveis áreas de
uma empresa podem ser: escritório de projetos, engenharia de produto, marketing etc. As pessoas que atuam em
uma dessas áreas podem ter uma idéia geral de todo o processo com a visão por fases, mas podem atentar às ativi-
dades mais voltadas à sua área específica de atuação, respectivamente gerenciamento de projetos, especificação
do produto e marketing, no exemplo. Assim, ela pode gerenciar as atividades sob sua responsabilidade, sem
perder a visão do processo. Uma pessoa da área de marketing, por exemplo, pode ler este livro com o objetivo de
obter uma visão ampla do processo de desenvolvimento de produtos, mas, ao mesmo tempo, aprofundar-se mais
nas atividades relacionadas com marketing.

Quadro 2.7 Outros Modelos de Referência Organizam as Atividades por Áreas de Conhecimento

23
Outros modelos de referência existentes, tais como Project Management BOdy of Knowledge (PMBOK) e Capability Ma-
24
turity Model Integration (CMMI), das áreas de gestão de projetos e desenvolvimento de software integrado , respectiva-
mente, agrupam as atividades em áreas de conhecimento. Nesses modelos, essas áreas são chamadas de áreas de processo.
25
No PMBOK, as atividades de referência estão agrupadas por capítulo (cada um tratando de uma área de processo ), mas existe
também uma visão que agrupa as atividades por fase da gestão de projetos: iniciação, planejamento, controle e fechamento.
No CMMI, as atividades estão agrupadas pelas áreas de processo, dividas em níveis de maturidade. São 24 áreas de pro-
cesso e 5 níveis de maturidade.
Esses modelos não têm intuito didático e, sim, são guias para utilização e certificação. Em razão disso, a organização por
áreas de processo é mais apropriada para esses modelos, mas seu conteúdo é de difícil entendimento.

As áreas de conhecimento do modelo proposto neste livro são: gestão de projetos, meio ambiente, marke-
ting, engenharia de produto, engenharia de processo, produção, suprimentos, qualidade e custos. O conteúdo
dessas áreas — os temas tratados pelas atividades desse modelo — é apresentado na Tabela 2.1.

Tabela 2.1 Temas e Atividades por Área de Conhecimento

Área de Conhecimento Temas/Atividades típicas


Gestão de projetos Definição de escopo, tempos, recursos humanos, sua qualificação e controle das atividades.
Meio ambiente Sustentabilidade, reúso, remanufatura, reciclagem, reutilização de material, descarte.
Marketing Relacionamento com o mercado, como levantamento de necessidades, inserção e avaliação dos
produtos no mercado, e vigilância tecnológica.
Engenharia de produto Soluções de estilo, de material, funcionais, estruturais, de comportamento do produto, integração de
tecnologia etc.
Engenharia de processo Processos e operações de fabricação e montagem, especificação e projeto de recursos de manufatura.
Produção Atividades que consideram a manufatura dos produtos em desenvolvimento.
Suprimentos Envolve as atividades de relacionamento com os parceiros, fornecedores, clientes da cadeia de
suprimentos e o projeto da logística para viabilizar a produção.
Qualidade Gestão constante dos requisitos dos produtos, mas cobre também o acompanhamento da qualidade
dos processos de negócio resultantes do desenvolvimento de produtos e a qualidade dos produtos no
mercado após o seu lançamento.
Custos Definições de preços e custos-alvo, elaboração do orçamento, estudos de viabilidade e o
monitoramento constante dessas informações.

23
Embora não adotem o termo “modelo de referência”.
24
O CMMI considera o desenvolvimento integrado de produtos, que envolve várias tecnologias. Ele é uma evolução do CMM, que an-
tes só tratava de desenvolvimento de software.
25
As áreas de processo do PMBOK são: integração, escopo, tempo, custo, qualidade, análise de riscos, aquisição, comunicação e recursos
humanos.
88 PARTE 1 O Processo

Na Figura 2.24 pode ser observada uma distribuição típica das atividades por
Distribuição do esforço e aessas áreas de conhecimento nas fases de desenvolvimento de produtos. A figura
importância de cada área mostra qualitativamente que atividades de uma área de conhecimento são mais ne-
de conhecimento
cessárias em determinadas fases do desenvolvimento. Por exemplo, atividades de
suprimentos (compra de recursos, tais como equipamentos e ferramentas) são mais
intensas na fase de “preparação da produção” do que em outras.

Figura 2.24 Distribuição qualitativa típica das atividades (esforço e importância) por área de conhecimento nas fases do desenvolvimento.

No final deste livro encontra-se o Apêndice I com uma tabela que indica, para cada atividade, qual a área de
conhecimento correspondente. Assim, o leitor que trabalha em uma determinada área — ou que possui um co-
nhecimento específico — pode verificar quais as atividades relacionadas com os seus conhecimentos e/ou quais
poderão ficar sob sua responsabilidade.
Nesse ponto, já obtivemos uma visão geral do modelo, macrofases e conhecemos os conceitos que nos auxi-
liarão no entendimento do resto deste livro. Vamos discutir agora o conceito de gestão de conhecimento e como
ele se relaciona com o modelo proposto.

2.12 Gestão
do conhecimento do PDP
Gerenciar o desenvolvimento de produtos é um desafio sig-
nificativamente diferente do que gerenciar outras operações tra-
dicionais na área de manufatura, e discutir essas diferenças é
fundamental para entender por que a gestão do conhecimento é
tão importante para o processo de de-
Processo estruturado senvolvimento de produtos.
versus não estruturado
CAPÍTULO 2

O Modelo Unificado do PDP 89

O processo de manufatura é um processo estruturado e o de desenvolvimento de produtos é não estrutu-


rado, como discutido no Tópico 2.1 deste capítulo.
No Quadro 2.8, são apresentadas as características que distinguem o processo de desenvolvimento de pro-
dutos de outros processos industriais. Tais diferenças são marcantes e “dizem muito” sobre a importância e o pa-
pel da gestão do conhecimento para o processo de desenvolvimento de produtos. A Tabela 2.2 traz uma
comparação entre o processo de desenvolvimento de produtos e os processos estruturados.

Tabela 2.2 Comparação entre o Processo de Desenvolvimento de Produtos e Processos Estruturados como Operações de Compra e
Serviços Padronizados

Processos Estruturados (Manufatura Processo de Desenvolvimento de Produto


ou Serviços Padronizados)
Resultado Final (produto) Físico (tangível e bem determinado) Dados e Informações (conjunto de informações
para a produção industrial e retirada do produto)
Objetivos de melhoria no Executar eficientemente tarefas bem Resolver problemas de maneira rápida e eficaz
processo de gestão estabelecidas
Unidade Elementar para a Racionalizar o fluxo de materiais e Aumentar a competência dos indivíduos
melhoria do Processo recursos
Prazo de Duração Curto (dias) Longo (anos ou meses)
Grau de repetibilidade das Alta Baixa
atividades

Nas operações produtivas, o produto e as atividades necessárias para construí-lo são definidos antes do início da fabri-
cação. Os momentos de decisão são claros e, na maioria das vezes, podem ser padronizados por regras do tipo “Se... Então”. A
inspeção de qualidade é um exemplo: se houver arranhões na pintura ou encaixe inadequado de um conjunto, enviar para a
remanufatura; se houver problemas mais complexos, deve-se refugar o produto. O fluxo de materiais e atividades é bem de-
finido e o ciclo, ou lead time, é de dias, trazendo o benefício da previsibilidade. Com intervalos de tempo curtos, é mais fácil
estimar os prazos e as durações das atividades. As melhorias podem ser tratadas como ações paralelas, enquanto o processo
principal é executado e mantido em um determinado nível de controle. Os processos de negócio que possuem essas carac-
terísticas podem ser ditos estruturados, pois o resultado esperado é claro, as atividades para atingi-lo são previsíveis e perce-
bidas da mesma forma por todos. Outros exemplos de processos bem estruturados são: aprovação de contas em um banco;
processamento de um sinistro em uma companhia de seguros; compras; preparação de balanços financeiros e outros.
O processo de desenvolvimento de produtos é de outra natureza. Parte significativa das atividades que o compõem en-
volve criação. Muitas vezes, tem-se pouco conhecimento do resultado final a ser alcançado. Tem-se conhecimento de dire-
trizes gerais de desempenho esperado no produto ou serviço, por exemplo: precisa-se de um freio de automóvel que pare
um carro de 500kg, em 100m a uma velocidade de 80Km por hora. A configuração do mecanismo de freio será “criada” ao fi-
nal do processo. Com pouco conhecimento do resultado esperado, fica difícil prever todas as atividades, como: quantas
horas para detalhar as características do produto serão necessárias e quantas pessoas e como o resultado será consolidado?
O mesmo vale para os momentos de decisão. A criação do produto envolve milhares de pequenas decisões interdepen-
dentes: que material escolher, qual o melhor desenho de estrutura, como realizar as atividades de testes e assim por diante. É
difícil sistematizá-las previamente a partir de uma regra. A situação torna-se mais crítica se considerarmos que o conheci-
mento tecnológico avança rapidamente, trazendo novas possibilidades de soluções, novos caminhos, que precisam ser tes-
tados. Problemas idênticos, em dois projetos distintos no tempo, podem receber tratamentos diferentes, mesmo que
solucionados por um único profissional. Basta que uma nova teoria, técnica ou conhecimento seja absorvida durante o pe-
ríodo que distanciou os projetos.

Quadro 2.8 Diferenças entre o PDP e Outros Processos Estruturados


90 PARTE 1 O Processo

Note que em um processo estruturado, o fluxo a ser otimizado é o de materiais


O importante são pessoas e recursos tangíveis, que podem ser medidos precisamente e cujas decisões são em
capacitadas em resolver um grau de variação menor. Nesses casos, o foco da melhoria do processo está na
problemas
execução eficiente do fluxo e na melhoria contínua das práticas empregadas. No
caso do desenvolvimento de produto, cada projeto realizado é bastante particular.
Se é difícil entender quais são as atividades, como otimizar os métodos? Se o resultado é o conhecimento, como
medi-lo? É evidente que nos processos não estruturados, melhorar a capacidade de solução de problemas da
equipe é mais importante do que aprimorar os métodos. Pois mais importante do que dizer “como fazer” é pos-
suir profissionais capazes de reagir adequadamente a cada situação, encontrando a melhor forma de proceder
conforme o problema de projeto enfrentado. Conforme a capacitação do pessoal aumenta, maior a probabili-
dade de que soluções melhores sejam encontradas em cada momento do processo de desenvolvimento. A velocidade
também depende disso, pois a equipe mais capacitada deverá encontrar as soluções mais rapidamente, diminuin-
do também o tempo de desenvolvimento.
No final dos anos 1990, vários teóricos do mundo organizacional demonstraram, na prática, que, por trás
de uma maior eficiência na área de desenvolvimento de produto, está a maior capacitação da equipe e a habili-
dade da empresa em mantê-las atualizadas. Os termos “empresa que aprende” e “aprendizagem organizacional”
foram criados para designar as empresas que se distinguiam em termos de capacidade de aprendizado contínuo.
Uma organização que aprende é aquela que continuamente revê suas práticas.
Exemplo da Boeing Um exemplo citado é a Boeing. Após sofrer com vários problemas nos projetos dos
aviões 737 e 747, a empresa criou um projeto batizado de homework. Uma equipe de
gerentes seniores, com grande experiência, estudou e identificou as causas possíveis de cada um dos problemas
ocorridos nesses projetos e os erros cometidos, comparando o processo de desenvolvimento desses aviões com
26
os dos 707 e 727 (com alto nível de sucesso). Segundo consta, o resultado desse estudo foi empregado nos pro-
jetos dos modelos 757 e 767, os quais, mais tarde, se tornaram os mais lucrativos da empresa.
Uma empresa que aprende é também aquela cujo ambiente convida as pessoas
O ambiente deve ser a se aprimorarem. Na época do “milagre econômico” japonês, no final dos anos
convidativo ao 1980, identificou-se que a vantagem em desenvolvimento de produtos das empresas
aprendizado e à inovação
oriundas desse país estava relacionada com a postura dos engenheiros chefes que de-
safiavam as suas equipes a pesquisar e solucionar problemas, a aprender continua-
mente, em vez de dizer como o projeto deveria ser feito — tal qual ocorria nas empresas norte-americanas. Um
exemplo é o Honda City, um grande sucesso de mercado, cujo projeto teve início com a proposta desafiadora de
Hiro Watanabe de criar um carro com o seguinte slogan: “máximo de ser humano e mínimo de máquina”. O
trabalho com esse desafio levou ao conceito de carro curto e alto, que influenciou e modificou o rumo da indús-
27
tria automobilística. Exemplo semelhante foi a tecnologia de tambor descartável criada pela Cannon , que per-
mitiu a criação de toda uma geração de máquinas copiadoras de tamanho reduzido. Essa inovação teve origem
em um desafio aos paradigmas vigentes proposto pelos líderes de projeto.

A organização que aprende é a que dispõe de habilidades para criar, adquirir e transferir conhecimentos e é capaz de mo-
dificar seu comportamento, de modo a refletir os novos conhecimentos e idéias (Garvin, 1988).

Uma empresa que aprende é também aquela que consegue criar um ambiente que estimule e cobre das pes-
soas uma postura de aprendizagem contínua e a reflexão sobre os problemas passados e experimentação como
hábitos de trabalho. Um ambiente no qual as pessoas estejam continuamente introduzindo melhorias. Ela

26
Esse caso foi descrito primeiro por GARVIN, David A. Construindo a organização que aprende. Rio de Janeiro: Ed. Campus,
2000.
27
Esse caso é descrito nos livros: DECHAMPS J.P. & NAYAK. P.R. Produtos irresistíveis. São Paulo: Makron Books, 1996; e NONAKA,
Y. “A empresa criadora de conhecimento.” In: Harvard Business Review. Gestão do conhecimento. Rio de Janeiro: Campus, 2000.
CAPÍTULO 2

O Modelo Unificado do PDP 91

possui estrutura organizacional, procedimentos, práticas e cultura, isto é, valores, crenças, entre outros, com-
partilhados entre seus funcionários, voltados para o aprendizado contínuo.
Na base da empresa que aprende está o profissional e o conceito de compe-
tência. Na verdade, dizer que uma empresa aprende é uma figura de linguagem. São É a competência das
as pessoas que aprendem, que aprimoram suas competências e são responsáveis pela pessoas que torna a
empresa uma organização
renovação das práticas. Portanto, no âmago da empresa que aprende está o desen- que aprende
volvimento das competências individuais de seus colaboradores. Pode-se definir
competência como o conjunto de conhecimentos, habilidades e atitudes, formadas a
partir da experiência prática. Trata-se, portanto, da capacidade desenvolvida pelo profissional em solucionar
problemas em um determinado campo de atuação. A competência é difícil de ser medida. Ela se manifesta no de-
sempenho do indivíduo, mais precisamente no momento em que se observa a qualidade dos resultados produ-
zidos por ele. Se há excelência na solução, há um conjunto de conhecimentos, habilidades e atitudes.
Nesse conjunto, deve-se destacar o componente conhecimento. Trata-se de
algo difícil de ser medido, mas é fundamental para o aumento da competência dos Conhecimento é
funcionários. Ele é indissociável do indivíduo e se materializa no conjunto de cons- fundamental para
aumentar a competência
trutos que cada um se utiliza para interpretar o mundo. Não pode ser transmitido
diretamente. Seu acréscimo depende de um processo individual de cada pessoa, fa-
cilitado pelo contato com informações e pela interação com outros indivíduos.
Na prática, os gestores de áreas relacionadas ao processo de desenvolvimento de produtos não podem criar
o ambiente em si — isso depende da interação dos profissionais. Resta-lhes criar ações e condições que esti-
mulem o desenvolvimento desses ambientes. Tais incentivos compreendem desde formas mais tradicionais —
como leituras, cursos, interações com clientes e fornecedores e interações entre os membros da empresa — até
outras menos usuais — como promover e criar comunidades de pessoas interessadas em determinados assuntos,
criar sistemas de informação que aproximem pessoas de diferentes unidades ou setores da empresa. O termo
empregado para isso é o de Gestão do Conhecimento.
Em termos formais, a Gestão do Conhecimento (GC) pode ser definida como
o conjunto de práticas e atividades destinadas a incentivar e garantir a criação, com- Definição de Gestão do
partilhamento e disseminação de informações e a troca de experiências visando a Conhecimento
melhoria contínua das competências das pessoas e, conseqüentemente, o cresci-
mento do conhecimento organizacional.
Um problema com esse termo é que, em um primeiro momento, ele pode passar uma idéia errada, a de que
se está gerenciando, isto é, planejando, controlando e medindo o conhecimento em si. Na verdade, como vimos
anteriormente, o conhecimento não pode ser planejado, medido ou controlado. O que se planeja e se controla
são as ações e as práticas gerenciais que estimulam a manutenção e a aprendizagem contínua das pessoas, por
meio do compartilhamento de conhecimentos. Portanto, o objetivo da Gestão do Conhecimento é garantir que
a empresa desenvolva práticas e uma “cultura” de criação, compartilhamento e uso de conhecimentos.

Gestão do Conhecimento (GC): o conjunto de práticas e atividades destinadas a incentivar e garantir a criação, comparti-
lhamento e disseminação de informações e a troca de experiências, visando a melhoria contínua das competências das pes-
soas e, conseqüentemente, o crescimento do conhecimento organizacional.

Os projetos de gestão do conhecimento precisam trabalhar todos os aspectos das organizações para sur-
tirem efeito, avaliando-os perante as necessidades de aprendizagem contínua e propondo ações para que re-
forcem a aprendizagem. Deve-se observar desde a missão, estratégia, política de recursos humanos, os sistemas
de informações até os padrões e procedimentos organizacionais.
92 PARTE 1 O Processo

No modelo unificado de referência deste livro, a Gestão do Conhecimento


Gestão do Conhecimento (GC) permeia todas as atividades. A política de recursos humanos deve promover o
no modelo unificado de clima para que o compartilhamento de conhecimentos ocorra. A definição de estra-
referência do PDP
tégias da empresa e por conseqüência as estratégias de produto devem reutilizar ex-
periências do passado. Os sistemas de informação devem possibilitar a inserção de
conhecimentos explícitos dos mais diversos tipos, a sua recuperação e a formação de comunidades entre membros
da empresa, do time de desenvolvimento, dos parceiros externos e das pessoas que possuem interesses comuns.
No final de cada fase do modelo, existe uma atividade denominada “Documentar as decisões tomadas e re-
gistrar as lições aprendidas”. A existência formal dessa atividade reforça a necessidade de realização de uma das
facetas mais importantes da Gestão do Conhecimento: o armazenamento sistemático de informações e expe-
riências. Isso deve ocorrer constantemente, sempre que uma pessoa considerar que possui conteúdo para com-
partilhar com os seus colegas e com a empresa como um todo. O acúmulo desses conhecimentos explícitos (que
podem ser documentados) e de ferramentas de TI apropriadas permitem que esse conhecimento seja reutili-
zado, evitando, assim, que a empresa incorra nos mesmos erros do passado. Isso cria a empresa que aprende. As
descrições das atividades do modelo não vão apresentar de maneira explícita atividades dessa natureza, mas, após
este tópico, esperamos que o leitor considere que o compartilhamento de conhecimentos é uma postura cons-
tante de todos os membros do time de desenvolvimento.
O próprio modelo é um registro de conhecimentos explícitos (regras de negócio, padrões) e seu uso, na oti-
mização e sistematização do PDP, é considerado uma boa prática de Gestão do Conhecimento.
Vamos agora discutir as características do modelo unificado, preparando o leitor para interpretar a segunda
parte deste livro.

2.13 Caracterizando o modelo


No início deste capítulo, mostramos que o modelo de refe-
rência deste livro é voltado para empresas de manufatura de bens
de consumo duráveis e/ou capital com ênfase na tecnologia mecâ-
nica de fabricação. Mostramos, também, os conceitos básicos so-
bre modelagem de processos para você entender a importância da
existência de um modelo de referência.
Em seguida, apresentamos uma visão geral do modelo, das
suas macrofases, os papéis usuais das pessoas em um processo de
desenvolvimento de produtos e destacamos alguns conceitos im-
portantes do nosso modelo: a revisão de fases (gates); como relacionar
os métodos e ferramentas de desenvolvimento de produtos ao mo-
delo; os tipos de parceiros e as formas de relacionamento entre
eles dentro de uma cadeia de suprimentos; e quais os indicadores de desempenho utilizados para avaliar os pro-
cesso. Finalmente, mostramos as áreas de conhecimento tratadas no modelo e também como ele pode ajudar na
Gestão do Conhecimento do processo de desenvolvimento de produtos.
Agora que já temos a visão geral do modelo, podemos caracterizá-lo melhor para que você entenda para
que serve o modelo apresentado neste livro. Para isso, vamos discutir mais um conceito importante da mode-
lagem de processos: os modelos de referência e seus tipos. Deixamos esse assunto para este tópico e não para o
início deste capítulo, pois, agora, você possui conhecimentos que facilitam o entendimento dessa questão.
Existe uma discussão acadêmica sobre o significado do modelo de referência,
Definição de modelo de mas, neste livro, vamos adotar a seguinte definição “modelo de referência pode ser
referência e seus tipos utilizado como base para a criação de outros modelos ou para a definição de pro-
jetos”. Denominamos de modelo de referência genérico, quando definimos, a partir
dele, um modelo de referência específico para uma determinada empresa, que, por sua vez, serve de base à defi-
nição de projetos de desenvolvimento de produtos dessa empresa, como ilustrado na Figura 2.25.
CAPÍTULO 2

O Modelo Unificado do PDP 93

Figura 2.25 Modelos de referência genéricos dando origem a modelos de referência específicos, os quais, por sua vez são a base
para a definição de projetos.

Um modelo de referência genérico normalmente é voltado para um determinado setor, mas pode ser utili-
zado por mais de um setor. Por exemplo, um mesmo modelo genérico pode servir como referência para os se-
tores de máquinas agrícolas e máquinas-ferramentas.
Empresas de um mesmo setor poderiam definir os seus modelos específicos a partir do modelo genérico.
No entanto, a partir da nossa experiência, consideramos que existem vários fatores que diferenciam empresas de
um mesmo setor, dificultando a criação e a aplicação de um modelo genérico único para um determinado setor.
Isto é, duas empresas de um mesmo setor podem possuir modelos de processos bens distintos. Não basta ser do
mesmo setor. Portanto, um modelo genérico de um determinado setor deve ainda considerar outros fatores que o
individualizam, como tecnologia, tipo de projeto de desenvolvimento, posição e relacionamento da empresa com
os seus parceiros na cadeia de suprimentos, estratégia de produção, grau de responsabilidade da empresa, nível de
maturidade em desenvolvimento de produtos, forma de inserção da empresa dentro do grupo, tipo de mercado,
28
entre outros. Em outras palavras, pode existir mais de um modelo de referência genérico para um mesmo setor
(veja, na ilustração da Figura 2.25, o caso do Setor A que possui três modelos de referência genéricos).
Um exemplo fácil de ser entendido está no setor automotivo. Vamos listar três tipos de fornecedores, dife-
renciando para esse exemplo somente o fator tecnologia: os de componentes eletrônicos, como a injeção eletrô-
nica; os de pneus; e os fornecedores de chassi de carros. Alguns aspectos gerenciais do processo dessas empresas
são equivalentes, mas, quando se trata das fases tecnológicas, as atividades a serem realizadas são distintas. Isso
significa que os modelos de referência para esses fornecedores são diferentes. A maior diferença está nas ativi-
dades relacionadas com as tecnologias específicas: eletrônica, processamento de borracha e estrutura metálica e
processo de soldagem. Então, para cada um desses três grupos de fornecedores, há um modelo genérico, e cada
empresa dentro do grupo tem um modelo específico.
O modelo apresentado em detalhes na Parte 2 deste livro é um modelo de refe-
rência genérico. O foco é na tecnologia de fabricação mecânica e é voltado para o Qual o tipo do modelo
setor de bens de consumo duráveis, tais como produção de equipamentos, eletrodo- deste livro?
mésticos, linha branca (geladeira, fogão, lavadora etc.), automóveis etc. Vamos con-
siderar agora alguns dos fatores de diferenciação do PDP listados para melhor caracterizar o modelo deste livro:

28
Para estudar uma discussão mais completa dos fatores que influenciam e caracterizam o processo de desenvolvimento de produtos,
consulte ROZENFELD & AMARAL (1999).
94 PARTE 1 O Processo

I tipo de projeto de desenvolvimento;


I posição e relacionamento da empresa com os seus parceiros na cadeia de suprimentos; e
I estratégias de produção.

Os tipos de projeto já foram discutidos no Capítulo 1 — radical, plataforma, derivado e follow source —, e a po-
sição e o relacionamento da empresa com os seus parceiros na cadeia de suprimentos estão no Tópico 2.10, deste ca-
pítulo. Vamos agora conhecer as estratégias alternativas de produção, antes de analisar a aplicabilidade do modelo.
Normalmente, os produtos do setor de bens de consumo duráveis são desen-
Estratégias de produção volvidos a partir de análise de mercado, com a estratégia de produção conhecida
como Make To Stock (MTS). Ou seja, são produzidos para estoque e não para um
cliente específico. Um exemplo é a fabricação de geladeira, um bem de consumo durável. Seus fabricantes pos-
29
suem uma análise da demanda por um produto, e, com base nessa análise, eles o produzem para estoque.
Em certos casos, alguns desses produtos são produzidos conforme a especificação de um cliente em parti-
cular. As diferentes especificações definem uma combinação de acessórios, previamente definidos pela monta-
dora. O desenvolvimento, então, já prevê todas essas variações. As estratégias de produção nesse caso podem ser
Assembly To Order (ATO) ou Make To Order (MTO). Na estratégia ATO, os sistemas e os componentes prin-
cipais são produzidos para um estoque intermediário, e, a cada pedido, o produto final é montado utilizando
esses componentes — como é o caso de alguns fabricantes de computadores, em que o produto final é montado
no distribuidor. Se o tempo de produção desses sistemas e componentes for menor do que o tempo de espera
aceito pelo cliente, ou mesmo se a empresa trabalhar com Just In Time (JIT), estaremos falando da estratégia de
MTO, isto é, somente após a entrada do pedido é que as peças são produzidas e, em seguida, o produto é mon-
tado. Esse é o caso de alguns produtos da indústria automobilística. Somente após o pedido do cliente30 é que a
montadora inicia a produção do veículo.
Para empresas de bens de capital de alto valor agregado (como uma turbina de uma hidroelétrica), a estraté-
gia de produção é a Engineering To Order (ETO). Ou seja, a macrofase de desenvolvimento só é iniciada após a
venda e o pedido do cliente. E, normalmente, esse pedido vem com especificações técnicas detalhadas e particulares.
Agora temos todos os elementos para discutir onde se pode aplicar o modelo
O modelo deste livro é deste livro.
aplicável para qual tipo de
projeto e empresa? Na Tabela 2.3 estão listados os fatores de diferenciação citados e na coluna da
direita é mostrada a aplicabilidade do modelo deste livro.

Tabela 2.3 Análise da Aplicabilidade do Modelo para Alguns Fatores de Diferenciação das Empresas

Fator de diferenciação Aplicabilidade do Modelo


Tipo de Projeto Projeto radical Total, mas é preciso considerar uma maior integração com o processo de P & D.
Projeto plataforma Total
Projeto derivado As fases iniciais do desenvolvimento podem ser simplificadas.
Projeto follow source As fases de Projeto Conceitual e Preliminar devem ser bem simplificadas ou até
eliminadas.
Posição na cadeia Montador Total
de suprimentos Fornecedor de Total no caso de fornecimento para mercado. No caso de fornecimento sob
equipamentos e encomenda, deve seguir a recomendação do tipo de produção ETO.
ferramental

(continua)

29
Em alguns casos, as redes de lojas de revenda enviam uma previsão para os fabricantes e fecham a compra de grandes quantidades de
geladeiras. A produção, então, é feita para atender esses pedidos.
30
Nesse caso, o cliente pode ser um cidadão comum ou uma concessionária.
CAPÍTULO 2

O Modelo Unificado do PDP 95

Tabela 2.3 Análise da Aplicabilidade do Modelo para Alguns Fatores de Diferenciação das Empresas (continuação)

Fator de diferenciação Aplicabilidade do Modelo


Fornecedor de A fase de lançamento do produto é praticamente eliminada, pois todo o contato com
primeiro nível o mercado fica com o montador.
Fornecedor de Idem ao anterior. Além disso, o modelo deve ser simplificado, pois, normalmente, os
segundo nível produtos são mais simples.
Fornecedor de Total, mas, dependendo da complexidade da commodity (e normalmente ela não é
commodities complexa), deve ser simplificado.
Fornecedor de Parcial, pois a natureza (tecnologia) do material pode exigir outros tipos de atividades.
matéria-prima
Fornecedor de Não é diretamente aplicável, mas é bom que um fornecedor desse tipo conheça o
tecnologia modelo, quando for participar do PDP dos clientes.
Fornecedor de Idem ao fornecedor de tecnologia.
serviços
Relacionamento Parceria de risco Total
na cadeia de Parceiro de Deve se preocupar com as atividades relacionadas à prospecção tecnológica e de
suprimentos tecnologia desenvolvimento, avaliação e teste de novas tecnologias, presentes nas fases iniciais
do modelo.
Parceria estratégica Total
Co-desenvolvedor Total
Fornecedor de Poderá utilizar este modelo para estruturar um processo de venda e entrega do
serviços serviço. Deverá ser algo bem mais simplificado uma vez que as atividades de busca de
informações dos clientes e a geração de soluções serão mais simples. O
pré-desenvolvimento descrito em nosso modelo não se aplica neste caso, à medida
que os projetos dependerão mais de uma prospecção de demanda do que
planejamento de uma estratégia.
Fornecedor de Idem ao anterior, mas um modelo para desenvolvimento de produtos padronizados,
peças-padrão no qual as fases iniciais de planejamento estratégico, planejamento do projeto,
projeto informacional e conceitual serão tremendamente simplificados, dado que são
peças normalmente descritas cujas funções e características estão descritas em
normas técnicas de fácil acesso.
Estratégia de Produção MTS Total
Produção Produção ATO Total (a diferença está na forma como o produto é estruturado para facilitar essa
estratégia).
Produção MTO Total
Produção ETO O pré-desenvolvimento terá que ser modificado. A fase de planejamento estratégico
do produto é simplificada, pois a empresa tem menor poder de decisão diante da
demanda que deverá atender. Porém, a fase de planejamento do projeto será muito
mais sofisticada e deverá incluir parte das atividades das fases do projeto
informacional e de lançamento. As atividades do projeto detalhado poderão ocorrer
em mais de um ciclo, dada a complexidade do projeto; a fase de preparação da
produção deve ser simplificada; provavelmente a fase de lançamento será eliminada,
e, em seu lugar, haverá um esforço bem grande nas atividades de homologação de
31
forma a certificar que o produto atinge todas as metas previstas.

Vê-se que a aplicabilidade é para todo o tipo de projeto, ressaltando-se a necessidade de uma maior inte-
gração com o processo de P & D no caso de projetos radicais; além disso, algumas aplicações precisam de um
modelo mais simplificado que o proposto. Como é raro que projetos radicais sejam realizados no Brasil, a aplica-
bilidade é grande para as empresas do setor a que ele se destina.
Dentro da cadeia de suprimentos do setor de bens de consumo duráveis e de capital, o modelo proposto
neste livro pode ser adotado como referência por empresas de todos os tipos, exceto a de fornecedores de tecno-

31
Consulte as adaptações desse modelo para atender empresas que trabalham com a estratégia ETO no Capítulo 16.
96 PARTE 1 O Processo

logia e serviços. Porém, como citado na Tabela 2.3, recomenda-se que as empresas desse tipo estudem o modelo
para conhecer as possíveis fases e atividades do PDP dos seus clientes, uma vez que elas poderão atuar nesse pro-
cesso. O processo de desenvolvimento mais abrangente é o das montadoras, cujo produto sempre é voltado para
um mercado amplo de consumidores. Este livro, então, apresenta uma proposta para esse tipo de empresa. Para
os demais tipos de empresa, o modelo pode ser simplificado.
O modelo abrange, também, a maior parte das formas de relacionamento que agregam mais valor ao PDP.
Nesses casos, deve-se usar esse modelo unificado para mapear o processo “conjunto” de desenvolvimento entre
os membros da cadeia de suprimentos, mas o papel de cada um dos parceiros tem de ser bem definido. Isto é,
quem será responsável por qual atividade.
O modelo pode ser adaptado para empresas que fornecem sob encomenda para um cliente específico
dentro da cadeia de suprimentos (caso dos fornecedores de equipamentos especiais). A adaptação está descrita
na Tabela 2.3 de forma geral e em detalhes no Capítulo 16.
A macrofase de desenvolvimento para todos os casos é praticamente a mesma. A ênfase dessa macrofase está
na aplicação da tecnologia metal mecânica. Mas ela também pode ser adotada para produtos que utilizam outras
tecnologias, como eletrônica e mecatrônica. Nesses casos, porém, deve-se especificar atividades adicionais vol-
tadas a essas tecnologias (por exemplo, desenvolvimento de software, integração de hardware, projeto de circuitos
eletrônicos etc.).
As macrofases de pré-desenvolvimento e pós-desenvolvimento são mais genéricas e provavelmente podem
ser utilizadas como referência para qualquer tipo de produto.
Foram analisados somente esses critérios de diferenciação do modelo, mas existem outros, como já foi ci-
tado. Fique atento ao analisar a Tabela 2.3, pois uma empresa real não deve considerar somente um tipo de fator
de diferenciação para verificar a aplicabilidade do modelo. A análise deve considerar todos os tipos de fatores si-
multaneamente.
Como as diferenças de conteúdo do modelo dependentes do tipo de projeto in-
Esse modelo possui 4 32
cluem somente a simplificação do modelo, uma mesma empresa pode utilizar ver-
versões: uma completa e sões mais simplificadas do modelo porque projetos de tipos distintos podem ser
suas simplificações
realizados paralelamente. Por exemplo, a empresa pode estar desenvolvendo um
projeto plataforma para criar uma nova família de produtos “A”; e a mesma empresa
pode estar realizando um projeto derivado “B34”, a partir da plataforma “B”. Para o projeto “A”, ela estará
usando a totalidade do modelo proposto e, no caso do projeto “B34”, ela usará um subconjunto do modelo.
Na verdade, então, esse nosso modelo de referência tem quatro versões: a completa, que contém todas as
fases e atividades propostas na Parte 2 deste livro; e três versões mais simplificadas para cada tipo de projeto.
Esse assunto será discutido no Capítulo 5 deste livro, durante o planejamento do projeto, quando se extrai do
modelo de referência as atividades que comporão um projeto de desenvolvimento.
Na Parte 3 deste livro, mostramos um método para ser adaptado para o modelo
Como adaptar o modelo de uma empresa específica, e explicamos em maiores detalhes o que deve ser mu-
para uma aplicação dado para os casos citados anteriormente (empresas de bens de capital, eletrônica e
prática?
mecatrônica). Provavelmente, as mesmas atividades apresentadas na Parte 2 deste
livro podem ser utilizadas, porém ordenadas de uma outra forma e estruturadas
dentro de outras fases. Em outras palavras, estaremos discutindo como transformar o modelo de referência gené-
rico deste livro em um modelo de referência específico para uma determinada empresa (veja a Figura 2.25).
Vamos agora conhecer em detalhes as atividades e tarefas de cada uma das fases do modelo na Parte 2 deste
livro.

32
Exceto no caso de projetos radicais, que não estão sendo considerados neste momento — veja a Tabela 2.3, em que discutimos o
que deve ser feito para projetos radicais, que será detalhado na Parte III.
CAPÍTULO 2

O Modelo Unificado do PDP 97

2.14 Resumo do capítulo


Processos de negócio podem ser estruturados ou não estruturados; o PDP é não estruturado; e dele podem
ser derivados projetos de desenvolvimento de produtos.
Um processo de negócio pode ser representado por um modelo; o modelo deste livro representa um PDP pa-
drão voltado para empresas de bens de capital e de consumo duráveis; é um modelo de referência genérico para
esse setor; um modelo de referência proporciona à empresa e seus parceiros uma visão unificada do processo.
O modelo unificado é dividido em macrofases, fases, atividades e tarefas; as macrofases são: pré-desenvolvi-
mento, desenvolvimento e pós-desenvolvimento.
O que determina uma fase é a entrega de resultados (deliverables), que permanecem congelados a partir do
momento em que a fase é finalizada; o final de uma fase é delimitado pela avaliação de fase ou gate.
Embora as fases estejam representadas de forma seqüencial, elas podem estar sobrepostas em um projeto real.
A fase de Planejamento Estratégico de Produtos envolve vários produtos, e as demais fases relacionam-se
com um produto em particular.
Atores e times do PDP são: membros da diretoria, gerentes funcionais, responsável pela engenharia, ge-
rente de projeto, especialistas, parceiros, Time de Planejamento Estratégico de Produtos, Time de Desenvolvi-
mento, Time de Avaliação, Time de Acompanhamento do Produto; em empresas pequenas, uma mesma pessoa
pode assumir diversos desses papéis.
Planejamento Estratégico compreende: Planejamento Estratégico da Corporação (PEC), que responde
sobre os rumos da corporação como um todo, incluindo todas as unidades de negócio; Planejamento Estratégico
da Unidade de Negócios (PEUN), que detalha como será a estratégia de ação da unidade de negócio em si; Pla-
nejamento Estratégico de Produtos (PEP), que é a primeira fase do pré-desenvolvimento.
Planejamento Estratégico de Produtos garante que o direcionamento estratégico seja mapeado e transfor-
mado em um conjunto de projetos bem definidos, isto é, a carteira de projetos que deverão ser desenvolvidos
(portfólio de projetos); considera a estratégia tecnológica, que é o enfoque que a empresa adota para o desenvol-
vimento e uso da tecnologia.
Pré-desenvolvimento envolve também o planejamento detalhado de cada um desses projetos; deve-se de-
cidir se realmente o que foi definido no planejamento estratégico tem chance de acontecer; no final do planeja-
mento, verifica-se se o desenvolvimento do presente produto deve continuar ou não.
Pré-desenvolvimento é a ponte entre objetivos da empresa e os projetos de desenvolvimento.
Características do PDP: no início, o grau de incerteza é grande; porém é neste momento que são realizadas
as escolhas de soluções de projeto (materiais, conceitos, processos de fabricação etc.), as quais determinam apro-
ximadamente 85% do custo final do produto; portanto, as fases iniciais do desenvolvimento são importantes;
mudanças sempre ocorrem, e o importante é fazer com que elas ocorram no início do desenvolvimento, quando
o custo das alterações é menor.
Engenharia Simultânea é uma filosofia utilizada no desenvolvimento; possui as seguintes premissas: tra-
balho em equipe, que envolve clientes e fornecedores; considera todos os elementos do ciclo de vida do produto;
enfatiza o atendimento das expectativas dos clientes; paralelismo entre atividades; faz uso de métodos e sistemas
integrados de engenharia, tais como QFD, FMEA, DFx, CAD/CAE, CAPP, PLM.
O time de desenvolvimento varia em tamanho e tipo de membro, dependendo da fase.
No desenvolvimento, são produzidas com detalhes todas as informações técnicas, de produção e comerciais
relacionadas com o produto; os protótipos já foram aprovados; os recursos a serem utilizados para a sua pro-
dução, comercialização e suporte técnico foram comprados, recebidos, testados e instalados; alguns produtos
foram fabricados e aprovados; já ocorreu o lançamento no mercado e as pessoas da cadeia de suprimentos estão
informadas e treinadas — tanto aquelas de empresas parceiras no fornecimento quanto as que estão envolvidas
na comercialização e suporte. Em alguns casos, novos processos de negócio de produção, atendimento ao cliente
e assistência técnica foram desenhados e implementados.
98 PARTE 1 O Processo

Pós-desenvolvimento compreende: o acompanhamento sistemático e a documentação correspondente das


melhorias de produto ocorridas durante o seu ciclo de vida; recebe informações de todos os processos de negó-
cio envolvidos com o produto; quando necessário, aciona os processos de apoio correspondentes de gerencia-
mento das mudanças de engenharia; ou de melhoria do PDP; gerencia também a retirada sistemática do produto
do mercado e finalmente uma avaliação de todo o ciclo de vida do produto; garante que parte das pessoas e os co-
nhecimentos acumulados estejam à disposição da empresa, viabilizando a sua reutilização em novos projetos de
desenvolvimento.
Na revisão de fase (gate), avaliamos os resultados do projeto individualmente e também se ele ainda é o mais
atrativo para empresa, considerando o portfólio de projeto; possui as seguintes atividades: a definição dos crité-
rios, auto-avaliação (pelo time de desenvolvimento) e aprovação pelo time de avaliação.
Ferramentas e métodos são meios que existem para apoiar à realização das atividades do PDP, e, neste livro,
estão resumidamente colocados em quadros.
Existem dois grandes grupos de indicadores para o PDP: relacionados com o processo como um todo e relacio-
nados com os projetos e produtos individuais, que medem sucesso financeiro, operacional, qualidade e perceptivo.
O PDP pode ser realizado de forma colaborativa desde as primeiras fases do desenvolvimento com os seus
parceiros de cadeia de suprimentos; tipos de parceiros: montador, fornecedor de equipamentos e ferramental,
fornecedor de primeiro nível, fornecedor de segundo nível, fornecedor de commodities, fornecedor de material, for-
necedor de tecnologia e fornecedor de serviços; formas de relacionamento: parceria de risco, parceria tecnoló-
gica, parceria estratégica, co-desenvolvimento, parceria de produção, contratados de longo e curto prazos.
Agrupar as atividades em cada fase é mais didático; pode-se também agrupar as atividades em áreas de co-
nhecimento, garantir que os aspectos dessas áreas sejam considerados nas fases; as áreas de conhecimento são:
gestão de projetos, meio ambiente, marketing, engenharia de produto, engenharia de processo, produção, su-
primentos, qualidade e custos.
A organização que aprende é a que dispõe de habilidades para criar, adquirir e transferir conhecimentos e é
capaz de modificar seu comportamento, de modo a refletir os novos conhecimentos e idéias; os gestores de áreas
relacionadas ao PDP não podem criar o ambiente de uma empresa que aprende, isso depende da interação dos
profissionais; resta-lhes criar ações e condições que estimulem o desenvolvimento desses ambientes.
Gestão do Conhecimento é o conjunto de práticas e atividades destinadas a incentivar e garantir a criação,
compartilhamento e disseminação de informações e a troca de experiências visando a melhoria contínua das
competências das pessoas e, conseqüentemente, o crescimento do conhecimento organizacional; no modelo
unificado de referência deste livro a Gestão do Conhecimento permeia todas as atividades.
Este livro apresenta um modelo de referência genérico, com foco na tecnologia de fabricação mecânica,
voltado para o setor de bens de consumo duráveis, tais como produção de equipamentos, eletrodomésticos,
linha branca (geladeira, fogão, lavadora etc.), automóveis etc; avalia, ainda, a aplicabilidade do modelo para PDP
diferenciado por: tipo de projeto, posição e relacionamento na cadeia de suprimentos e estratégias de produção.

2.15 Questões e atividades didáticas propostas


1. Defina projeto, processo de negócio e cite as diferenças entre um projeto de desenvolvimento de pro-
dutos e um processo.
2. Visite o setor de desenvolvimento de produtos de uma empresa para conhecer o modelo de referência
para desenvolvimento de produtos utilizado. Faça um relatório com as seguintes atividades:
a) Compare com as fases do processo de desenvolvimento de produto.
b) Identifique, na estrutura organizacional das empresas, quem exerce cada um dos papéis propostos
no Tópico 2.3.
c) Descreva os principais documentos gerados durante o desenvolvimento de produtos da empresa e
compare-os com os resultados apresentados na Figura 2.9, principais resultados das fases, de forma
a identificar o conteúdo de cada documento.
CAPÍTULO 2

O Modelo Unificado do PDP 99

3. Qual a relação entre o processo gerencial de planejamento estratégico e o processo de desenvolvimento


de produtos?
4. O que é Engenharia Simultânea?
5. Cite o principal resultado e cinco atividades que acontecem em cada uma das macrofases do modelo:
a) Pré-desenvolvimento.
b) Desenvolvimento.
c) Pós-desenvolvimento.
6. Defina Modelo de Referência.
7. Cite três usos potenciais dos modelos de referência. Qual é a função que podemos definir como a que
engloba todas as demais (ou seja, à qual todos os objetivos são comuns)?
8. Quais das atividades a seguir não serão auxiliadas com o uso de modelos de referência?
a) Desenvolver o Manual de Qualidade da Empresa.
b) Análise de requisitos e implantação de sistemas de informação.
c) Desenvolver a estratégia de produtos da empresa.
d) Identificar skills e habilidades necessárias para as diversas funções da empresa.
e) Gerenciar e identificar melhorias nos processos de negócio.
9. Por que, em termos de desenvolvimento de produtos, é necessário que uma empresa tenha vários mo-
delos de referência ou um único modelo “customizável”?
10. Cite três características do processo de desenvolvimento de produto que influenciam na “customi-
zação” do modelo de referência.
11. Das características a seguir, qual não interfere na definição do processo de desenvolvimento de pro-
dutos?
a) Grau de inovação do projeto.
b) Inserção da empresa na estrutura mundial do desenvolvimento de produtos.
c) Informações iniciais recebidas para o desenvolvimento do projeto.
d) Setor industrial do qual a empresa faz parte.
e) Número de projetistas e processadores que a empresa possui trabalhando.

2.16 Informações adicionais


AMARAL, D. C. Arquitetura para gestão do conhecimento no processo de desenvolvimento de
produtos. Tese (Doutorado) — Escola de Engenharia de São Carlos, Universidade de São Paulo, São
Carlos, 2002. p.208.
AMARAL, D. C.; ROZENFELD, H.; MOSCONI, E. P.; TOLEDO, J. C.; ALLIPRANDINI, D. H.;
FORCELLINI, F. A. Development of reference model for integrating product development process-related
knowledge. In: 17º INTERNATIONAL CONGRESS OF MECHANICAL ENGINEERING, São Paulo,
2003. COBEM. São Paulo: ABCM, 2003. v.17.
O
ARAUJO, C. S. An analisys of the life-cycle of product development tools. In: 2 BRAZILIAN CONGRESS
OF PRODUCT DEVELOMENT MANAGEMENT, 2000, UFSCar, São Carlos, Brazil. ago. 2000, p.
30-31.
BENEDICTIS, C. C.; AMARAL, D. C.; ROZENFELD, H. Avaliação dos principais métodos e ferramentas
disponíveis para a modelagem do processo de desenvolvimento de produto. In: 4º CONGRESSO
BRASILEIRO DE GESTÃO DE DESENVOLVIMENTO DE PRODUTO, 2003, Gramado. CBGDP.
Porto Alegre: UFRGS, 2003. v. 4.
100 PARTE 1 O Processo

CLARK, K. B.; FUJIMOTO, T. Product development performance: strategy, organization and


management in the world auto industry. Boston, Mass.: Harvard Business School Press, 1991.
CLARK, K. B.; FUJIMOTO, T. Product development performance: strategy, organization and
management in the world auto industry. Boston, Mass: Harvard Business School Press, 1991.
CLAUSING, D. Total quality development: a step-by-step guide to world-class concurrent engineering.
New York: Asme Press, 1993.
COOPER, R. “From experience: the invisible success factors in product innovation.” The International
Journal of Product Innovation Management, v. 13, p. 115-133, 1999.
COOPER, R. G. Winning at new products: accelerating the process from idea to launch. Readin, MA:
Perseus Books, 1993.
CRUZ, T. Sistemas, métodos e processos: administrando organizações por meio de processos de
negócios. São Paulo: Atlas, 2003.
DECHAMPS, J. P.; NAYA, P. R. Produtos irresistíveis. São Paulo: Markron Books, 1997.
DECHAMPS, J. P.; NAYA, P. R. Produtos irresistíveis. São Paulo: Markron Books, 1997.
Harvard Business Review. Medindo o desempenho empresarial. Rio de Janeiro: Campus, 2000.
KAPLAN, N.; NORTON. A estratégia em ação: balanced scoredcard. Rio de Janeiro: Campus, 1997.
NONAKA, I.; TAKEUCHI, H. Criação de conhecimento na empresa. Rio de Janeiro: Campus, 1997.
PAHL, G.; BEITZ, W. Engineering Design a systematic approach. Springer: Verlag, 1993.
PEREZ, R. L., OGLIARI, A., BACK, N. Sistema de medição de desempenho aplicado no processo de
projeto (SiMDAP). In: IV CONGRESSO BRASILEIRO DE GESTÃO E DESENVOLVIMENTO DE
PRODUTOS, 2003, Gramado, RS, Brasil, 6 a 8 out. 2003.
PUGH, S. Creating innovative products using Total Design: the living legacy of Stuart Pugh. Reading,
MA: Addison Weslley, 1996.
PUGH, S. Total design: integrated methods for successful product engineering. Reading, HA: Addison
Wesley, 1991.
Romano, L. N. Modelo de referência para o processo de desenvolvimento de máquinas agrícolas.
2003. Tese (Doutorado em Engenharia Mecânica) — Programa de Pós-Graduação em Engenharia
Mecânica, Universidade Federal de Santa Catarina, Florianópolis, 2003.
ROZENFELD, H.; AMARAL, D. C. Proposta de uma tipologia de processo de desenvolvimento de produto
visando a construção de modelos de referência. In: I CONGRESSO BRASILEIRO DE GESTÃO DO
DESENVOLVIMENTO DE PRODUTO, 1999, Belo Horizonte, MG. Anais do 1º Congresso Brasileiro
de Desenvolvimento de Produto, 1999. p. 94-103.
ROZENFELD, H.; AMARAL, D. C.; TOLEDO, J. C.; CARVALHO, J. “O processo de desenvolvimento
de produtos e processos na fábrica do futuro.” In: ROZENFELD, H. R. (Org.). A fábrica do futuro. São
Paulo: Banas.
SHANE, S. A.; ULRICH, K. T. “Technological innovation, product development, and entrepreneurship.”
Management Science, vol. 50, n. 2, p. 133-144, fev. 2004.
SILVA, M. M.; ALLIPRANDINI, D. Aprendizagem organizacional no processo de desenvolvimento
de produtos: investigação do conhecimento declarativo no contexto da sistemática de stage-gates.
Dissertação (Mestrado) — Universidade Federal de São Carlos, Programa de Pós-Graduação em Engenharia
de Produção, São Carlos, SP. p. 151.
SILVA, S. L. DA. Proposição de um modelo para caracterização das conversões do conhecimento no
processo de desenvolvimento de produtos. Tese (Doutorado em Engenharia Mecânica) — Escola de
Engenharia de São Carlos, Universidade de São Paulo, São Carlos, 2002. 216 f.
CAPÍTULO 2

O Modelo Unificado do PDP 101

SILVA, S.; ROZENFELD, H. Gestão do conhecimento no processo de desenvolvimento de produto.


In: I CONGRESSO BRASILEIRO DE GESTÃO DO DESENVOLVIMENTO DE PRODUTO, Belo
Horizonte, out. 1999.
SIMONS, R. Performance measurement & control systems for implementing strategy: texts and cases.
New Jersey: Prentice Hall, 1999.
TERRA, J. C. C. Gestão do Conhecimento. São Paulo: Negócio, 2000.
TERRA, J. C. C. Portais corporativos: a revolução na Gestão do Conhecimento. São Paulo: Negócio,
2002.
ULRICH, K. T.; EPPINGER, S. D. Product design and development. New York: McGraw-Hill, 1995.
VALERI, S. G.; ROZENFELD, H.. “Improving the flexibility of new product development (NPD) through
a new quality gate approach.” Journal of Integrated Design And Process Science, USA, v. 8, n. 4, p.
17-36, 2004.
VALERI, Sandro Giovanni. Estudo do método de aprovação de fases no processo de desenvolvimento
de produtos em uma indústria automobilística. Dissertação (Mestrado em Engenharia Mecânica São
Carlos) — Universidade de São Paulo, 2001. Orientador: Henrique Rozenfeld. Of.
VERNADAT, F. B. Enterprise modeling and integration: principles and applications. London: Chapman
& Hall, 1996.
WHEELWRIGHT, S. C. CLARK, K. B. Revolutionizing product development process: quantum leaps
in speed, efficiency, and quality. New York: The Free Press, 1992.
WHEELWRIGHT, S. C.; CLARK, K. B. Revolutionizing product development process: quantum leaps
in speed, efficiency, and quality. New York: The Free Press, 1992.
Na Parte I, obtivemos uma visão abrangente do modelo de referência e dos
conceitos gerais utilizados na sua construção. Cada uma das macrofases do mo-
delo foi apresentada. Esta parte do livro descreve em detalhes as fases e ativi-
dades do modelo.
Em todos os capítulos a seguir, há quadros que apresentam explicações de-
talhadas de conceitos e textos introdutórios sobre métodos e ferramentas relaci-
onados com as atividades descritas no capítulo. Nesses casos, são citadas fontes
para consulta adicional.
A Figura PII representa o escopo de cada um dos 11 capítulos que compõem
esta parte do livro. O Capítulo 3 descreve as atividades genéricas que são recor-
rentes em todas as fases. Assim, evita-se repetir o mesmo conteúdo na descrição
de cada fase. As descrições das fases compreendem do Capítulo 4 ao Capítulo 12,
como pode ser visto na figura. O Capítulo 13, o último desta parte, descreve os
dois processos de apoio.

Figura PII Visão geral dos capítulos que descrevem o modelo.


3.1 Sumário
3.2 Atualizar plano da fase
3.3 Monitorar viabilidade econômico-financeira
3.4 Avaliar fase
3.5 Aprovar fase
3.6 Documentar as decisões tomadas e registrar lições aprendidas
3.7 Questões e atividades didáticas propostas
3.8 Informações adicionais

3. Atividades Genéricas do Modelo


Atividades Genéricas do Modelo
PARTE 2 O Modelo

Depois da leitura deste capítulo, você será capaz de:


l Conhecer as atividades genéricas que são recorrentes em todas as fases do modelo unificado.
l Compreender a importância e saber como atualizar o plano de projeto no início de cada fase.
l Compreender a importância e como implementar o monitoramento da viabilidade econômico-financeira no final de
cada fase.
l Definir as tarefas de revisão das fases (gates), cujos conceitos foram vistos no Capítulo 2. Essas atividades são realizadas
no final de cada fase do modelo, em que estão definidos critérios a serem utilizados.
l Documentar as decisões tomadas durante o desenvolvimento e registrar as lições aprendidas. Os conceitos básicos
dessas atividades encontram-se no Capítulo 2.

3.1 Sumário
Existem atividades que se repetem durante as fases que compreendem o desenvolvimento do produto,
chamadas de atividades genéricas (veja a Figura 3.1). Elas são descritas neste capítulo com o objetivo de evitar
sua repetição em cada uma das fases.
Primeiro, para cada uma das fases, ocorre a atualização do plano do projeto, e as tarefas relacionadas com a
fase que se inicia são atualizadas e detalhadas. Em seguida, ocorrem as atividades específicas de cada fase, des-
critas nos capítulos correspondentes. O monitoramento da viabilidade econômico-financeira é realizado du-
rante o desenvolvimento da fase, nos momentos em que novas decisões possam comprometer os resultados do
estudo de viabilidade, ou seja suas premissas e indicadores definidos e calculados no planejamento do projeto
(veja o Capítulo 4). Porém, a atualização do estudo de viabilidade é formalmente realizada e documentada ao fi-
nal de cada fase, antes da sua revisão (gate), pois a nova versão desse estudo fornece informações importantes
para as tomadas de decisão do gate. Em seguida, realiza-se a revisão de fase (o gate propriamente dito), composta
106 PARTE 2 O Modelo

1
de duas atividades principais, como descrito no Capítulo 2. A primeira é a auto-avaliação, quando o próprio
time de desenvolvimento aplica o método de revisão descrito no Capítulo 2, verificando se todos os critérios de
passagem foram atendidos e se eles podem se submeter ao processo de aprovação. Em caso positivo, na segunda
atividade da revisão, os responsáveis pelo projeto participam da avaliação e aprovam ou não a fase, permitindo
que o projeto continue. Por fim, todas as decisões tomadas durante a realização da fase e durante a revisão, assim
como as lições aprendidas, são formalmente documentadas.

Figura 3.1 Atividades genéricas das fases do modelo.

Vamos agora descrever cada uma dessas atividades genéricas citadas.

3.2 Atualizar plano da fase


Após a fase de planejamento estratégico de produtos (descrita em detalhes no Capítulo 4), quando se define
o portfólio de projetos a serem desenvolvidos, realiza-se individualmente o planejamento de cada um dos pro-
jetos de desenvolvimento específico (descrito no Capítulo 5).
Esse planejamento do projeto envolve a definição dos principais resultados esperados de cada fase, assim
como as atividades principais a serem realizadas para se atingir esses resultados. Além disso, o planejamento com-
2
preende a determinação do escopo do projeto , dos tempos de duração de cada atividade, da análise de risco etc.
Todos esses temas são discutidos no Capítulo 5. Essas informações resultantes são registradas em um docu-
mento denominado plano do projeto.
No início de cada fase de desenvolvimento, realiza-se essa atividade genérica
A atualização sempre de atualização do plano de projeto. Na verdade, ele é atualizado e pode ser também
ocorre no início de cada detalhado. Em projetos de grande porte e complexos, o plano inicial não contém
fase do desenvolvimento
detalhes sobre todas as atividades e prazos relacionados com uma fase específica.
Nessa atividade, parte-se dos prazos-limite de início e fim de fase e as atividades
mais específicas são detalhadas. As atividades apresentadas no Capítulo 5 são novamente realizadas. Nos casos
de projetos de menor porte ou de menor complexidade, essa atividade objetiva revisar o planejado. Destaca-se
que, em razão do menor escopo e das definições já existentes, o tempo de detalhamento do plano é bem menor
do que aquele necessário à realização do planejamento inicial. É importante que se faça esse detalhamento no
início da fase, pois, além de se estar mais próximo dos eventos daquela fase, é possível ajustar o plano com base
nos resultados do gate da fase anterior.
Durante o desenvolvimento podem existir novas condições que não foram consideradas durante o planeja-
mento inicial, como uma mudança no mercado, avanço tecnológico, limitações de recursos, novas políticas etc.

1
Para projetos mais complexos e abrangentes, podem acontecer revisões técnicas intermediárias antes do gate final, que, nesses casos,
compreende principalmente as questões gerenciais do projeto.
2
Escopo do projeto define as características do projeto para se obter o produto final. Ele é formalmente definido no Capítulo 4.
CAPÍTULO 3

Atividades Genéricas do Modelo 107

Essas novas condições são apreciadas e também contribuem para o detalhamento, mas principalmente podem
ser utilizadas para se atualizar o plano inicial, influenciando inclusive as fases subseqüentes de desenvolvimento.
Serão agora simplesmente listadas as tarefas genéricas pertencentes a essa fase. Elas não serão detalhadas,
pois equivalem às atividades discutidas no Capítulo 5, exceto a última tarefa de definição e atualização dos crité-
rios de passagem dos gates:

n analisar o plano de projeto atual;


n analisar e sintetizar as novas condições para a realização do projeto;
n atualizar o escopo do produto;
n atualizar e detalhar o escopo do projeto;
n atualizar e detalhar as atividades, os responsáveis, os prazos e o cronograma;
n atualizar e detalhar recursos necessários;
n atualizar estimativa de orçamento do projeto;
n atualizar, monitorar, valorar e definir novos indicadores de desempenho;
n analisar a viabilidade econômico-financeira do projeto;
n avaliar novos riscos;
n atualizar plano de comunicação;
n planejar, atualizar e preparar novas aquisições; e
n definir/atualizar os critérios de passagem dos gates.

Como pode ser visto no Tópico 3.5, a última tarefa da atividade de “Aprovar e Fase” é ajustar os critérios da
próxima fase. No planejamento da fase subseqüente esses critérios são confirmados na tarefa de “definir/atua-
lizar os critérios de passagem dos gates”.

3.3 Monitorar viabilidade econômico-financeira


Como visto na descrição da atividade genérica anterior, a atualização e o detalhamento do plano do projeto
para uma fase específica incluem a atualização do estudo de viabilidade econômico-financeira (realizado na fase
de planejamento do projeto), para garantir que as premissas e os indicadores iniciais estão sendo mantidos.
O estudo da viabilidade econômico-financeira do produto já nasce durante a
definição do portfólio, na fase de planejamento estratégico de produtos (Capítulo Primeira versão da
4). Durante o planejamento do projeto (Capítulo 5), é realizada uma atividade de viabilidade
econômico-financeira
análise da viabilidade econômico-financeira do projeto, na qual são definidos os
surge durante a definição
principais indicadores financeiros do projeto relacionados com o produto final, tais do portfólio
como: retorno do investimento, valor presente líquido e taxa interna de retorno
(veja o Quadro 5.14, no Capítulo 5, sobre a análise econômico-financeira). Existem
outros indicadores financeiros do projeto, que são operacionais e relacionam-se com o orçamento previsto
(budget) versus gastos, e que, em última análise, influenciam no fluxo de caixa do projeto — podendo aí, sim, mo-
dificar os indicadores anteriormente citados. No momento da análise inicial da viabilidade econômico-finan-
ceira, pode ter sido definido um custo-alvo do produto (veja o Quadro 5.12, no Capítulo 5, sobre custo-alvo e
gestão de custos), cujo monitoramento fornece subsídios para se atualizar a lucratividade esperada do produto
no mercado (veja o Quadro 5.14, no Capítulo 5, sobre a análise econômico-financeira).
A análise realizada durante o planejamento do projeto é a referência inicial
para as demais fases do projeto. É com base nela que se toma a decisão de se desen- As incertezas do início,
volver o produto (não é o único critério, mas um dos mais importantes). No en- refletidas no primeiro
estudo de viabilidade,
tanto, esse referencial é adotado em um momento no qual existem ainda várias
diminuem e precisamos
incertezas (veja o Tópico 2.5.1 sobre as características das fases de desenvolvimento atualizar esse estudo
de produtos). Durante o desenvolvimento, quando as especificações do produto são
detalhadas, pode-se ter uma certeza maior do custo, das características técnicas, e, portanto, do preço/volume.
108 PARTE 2 O Modelo

Além disso, o mercado previsto inicialmente pode mudar. Nesse período, deve-se monitorar os indicadores eco-
nômicos do projeto, pois uma mudança para pior pode inviabilizar o retorno financeiro do projeto e a empresa
deve avaliar se ele pode ter continuidade ou não. Lógico que uma mudança para melhor sempre é bem-vinda.
O ideal é realizar um monitoramento constante, sempre atento às condições
O ideal é monitorar 3
do mercado. Por essa razão é que sempre deve existir, no time de desenvolvimento,
constantemente a alguém da área financeira, ou, no mínimo, a área financeira deve fornecer ferra-
viabilidade
econômico-financeira do
mentas eficazes para que esse monitoramento seja realizado. Pode ser que alguma
projeto/produto... mudança significativa realmente necessite de um estudo de viabilidade mais formali-
zado antes de se atingir o final da fase, ou seja, qualquer grande decisão deve vir acom-
panhada de um estudo para ver se as premissas iniciais estão sendo mantidas ou não.
A Figura 3.2 apresenta uma visão geral das tarefas dessa atividade.

Figura 3.2 Tarefas da atividade genérica de monitorar a viabilidade econômico-financeira.

4
A atividade de monitoramento formal acontece ao final de cada fase de desen-
...mas o monitoramento volvimento. É um momento em que os resultados são consolidados e uma nova
formal ocorre no final versão do estudo de viabilidade econômico-financeira é documentada. Essa nova ver-
da fase
são compreende: premissas (juros, custo de atratividade etc.), custo-alvo, preço/vo-
lumes previstos no tempo, novo fluxo de caixa e os novos indicadores (veja o Quadro
5.14, no Capítulo 5, sobre análise econômico-financeira do projeto). Além disso, se necessário, deve-se justificar
os desvios do estudo atual com relação ao inicial e os possíveis impactos. Esse novo estudo é uma das informa-
ções analisadas durante a revisão de fase (gate), que também são atividades genéricas do modelo — as quais serão
apresentadas nos próximos tópicos.

3
As condições de mercado podem envolver mudanças nas políticas e nas condições macro e microeconômicas da região em que se pro-
duz e que consumiria o produto, como: novas políticas de juros e poder aquisitivo do mercado-alvo; entrada de novos concorrentes ou
mesmo o lançamento de novos produtos pelos concorrentes existentes; novos avanços tecnológicos que impactam o produto em de-
senvolvimento; e outros.
4
O monitoramento contínuo também é formal, mas, no final da fase, ele é documentado de uma maneira tal que pode ser utilizado na
revisão da fase.
CAPÍTULO 3

Atividades Genéricas do Modelo 109

3.4 Avaliar fase


Os conceitos principais sobre o processo de revisão de fases foram apresentados no Tópico 2.7, no qual
foram comentados os critérios a serem verificados no gate, o time de avaliação, o processo de gate e sua adap-
tação. Conforme discutido, o processo de gate é dividido em duas atividades: a deste tópico do livro, na qual o
próprio time de desenvolvimento realiza uma auto-avaliação, e uma outra na qual a decisão de continuidade do
projeto é tomada pelo time de avaliação (veja o Tópico 3.5, a seguir).
A Figura 3.3 apresenta uma visão geral das tarefas dessa atividade.

Figura 3.3 Tarefas da atividade genérica de avaliar fase.

Nessa atividade, o time de desenvolvimento realiza uma auto-avaliação, para ver se o projeto pode ser sub-
metido ao gate, coordenado pelo time de avaliação (atividade de aprovação da fase). São avaliados o cumpri-
mento das atividades e os seus resultados. A qualidade dos resultados é analisada, e os critérios qualitativos e
quantitativos são verificados, assim como a análise da viabilidade econômico-financeira.
Se surgir algum problema nessas avaliações, o próprio time de desenvolvimento pode decidir implementar
ações corretivas, antes de submeter a fase ao crivo do time de avaliação.
Caso eles considerem que os resultados foram satisfatórios e os critérios atendidos, eles marcam a reunião
de avaliação. É comum que se realize um relatório da auto-avaliação para facilitar o trabalho do time de avalia-
ção. No entanto, deve-se tomar o cuidado de não acreditar somente nesse relatório, pois o time pode estar “es-
condendo” os problemas. Por isso é que a existência de critérios bem definidos é essencial para o sucesso da
reunião de avaliação.
Algumas empresas definem ainda um time assessor para essa atividade, que
contém pessoas da empresa com conhecimentos tecnológicos do produto sendo de- Pode existir também um
senvolvido e ao mesmo tempo uma visão crítica do portfólio de produtos. Esse time time assessor para
colaborar no processo
não pode conter pessoas do time de desenvolvimento. É comum que sejam convi- de revisão
dados para esse time membros de fora da empresa. O papel desse time é auxiliar o
time de desenvolvimento na preparação para o gate com o time de avaliação e, ao
mesmo tempo, auxiliar esse time a tomar a decisão na atividade subseqüente, pois, muitas vezes, os membros do
time de avaliação não possuem conhecimentos técnicos nem tempo para entrar nos detalhes, que talvez sejam
necessários, para aprovar a fase. Pode parecer que a existência desse time acrescente burocracia ao processo e só
110 PARTE 2 O Modelo

pode existir em empresas muito grandes. No entanto, ele pode ser constituído de somente uma pessoa interna já
iniciada na gestão por gates, ou mesmo por um consultor externo cumprindo o papel mostrado.
As tarefas dessa atividade também são genéricas e devem considerar os crité-
Critérios para a revisão rios específicos de cada área, que devem ser definidos a priori e atualizados a cada
estão nos tópicos atividade de detalhamento do plano do projeto (veja o Tópico 2.7). Normalmente,
específicos relacionados
com cada fase
um modelo de referência, como o deste livro, apresenta alguns critérios que servem
de base para a definição dos critérios específicos para cada projeto. Dessa forma, ao
final de cada fase, quando essas atividades genéricas forem realizadas, são apresen-
tados neste livro os critérios pertinentes à fase em questão.
Vimos que, no final da fase, há as atividades de avaliação e aprovação da fase, os
Revisões técnicas antes do gates. No entanto, existem projetos grandes e complexos que necessitam de gates in-
final da fase termediários. Normalmente, esses gates intermediários tratam apenas de questões
técnicas, e lógico que o monitoramento do estudo de avaliação econômica pode ser
revisto, uma vez que a revisão é contínua. Esses gates podem ser definidos no modelo de referência específico da
empresa. No modelo apresentado, estaremos apresentando gates somente nos finais da fase. A fase de projeto de-
talhado, por exemplo, é uma fase que contém ciclos de detalhamento e otimização e, ao final de um ciclo, pode
ser realizado um gate técnico.
No final de um primeiro ciclo de detalhamento e otimização dentro da fase de projeto detalhado, existem
informações mais detalhadas do que na fase de projeto conceitual, mas não se tem certeza ainda se o projeto deve
continuar ou não. Nesse momento, é possível realizar um gate para aprovar a continuidade da fase de projeto de-
talhado. Esse gate é técnico e também envolve a atualização do estudo de viabilidade para que se decida se o pro-
jeto deve continuar ou não. Alguns autores chamam esse primeiro ciclo de detalhamento de projeto preliminar
(veja o Quadro 8.3 sobre projeto preliminar entre o projeto conceitual e detalhado).

3.5 Aprovar fase


Nesta atividade, diferentemente da anterior, o objetivo da avaliação é mais amplo, pois, aqui, o portfólio de
projetos também é analisado. Não é o time de desenvolvimento que coordena a realização desta fase, mas, sim, o
time de avaliação (veja o Tópico 2.3 sobre os papéis principais das pessoas envolvidas no PDP). Nesta atividade é
tomada a decisão de aprovação ou não da fase e, por conseqüência, do projeto — motivos do porquê definir esta
atividade separadamente da anterior.
A Figura 3.4 mostra as tarefas desta atividade.
O time de avaliação, com uma visão do portfólio de projetos, analisa o resultado da auto-avaliação da fase an-
terior realizada pelo time de desenvolvimento, verificando a situação do presente projeto perante o portfólio de
produtos e projetos existentes, ou seja, avaliando se ele ainda é prioritário perante as demais alternativas. Aprecia o
estudo de viabilidade econômico-financeira, e, finalmente, toma a decisão, que pode ser de quatro tipos:

n Cancelar o projeto: quando o projeto não cumpriu as atividades programadas, ou os resultados não são sa-
tisfatórios, ou, ainda, perante o portfólio, esse projeto não é mais atrativo, e não existe forma de recupe-
ração. Não é fácil cancelar um projeto, principalmente por problemas culturais, mas deve ser feito
quando necessário.
n Congelar o projeto: em razão das outras prioridades no portfólio, o projeto é congelado para ser conti-
nuado em um outro momento. A continuação pode estar condicionada a um plano de ação ou não.
n Redirecionar o projeto: alguns dos resultados não foram satisfatórios, mas uma recuperação é possível, e
um plano de ação é preparado para ser realizado em paralelo com o desenvolvimento da próxima fase.
Pode-se, então, realizar uma avaliação posterior dos resultados do plano de ação ou pode-se incorporar
essa avaliação no próximo gate.
CAPÍTULO 3

Atividades Genéricas do Modelo 111

Figura 3.4 Tarefas da atividade genérica de aprovar fase.

n Aprovar a fase: nesse caso, a próxima fase é iniciada e os resultados do gate são documentados, regis-
trando as lições aprendidas (Tópico 3.6), quando for o caso, para uma utilização posterior, a fim de
evitar que os mesmos problemas ocorram no futuro.

Após a tomada de decisão, é preparado um relatório sobre a avaliação e apro-


vação; os planos de correção são definidos; pode-se realizar uma análise de riscos, Tarefas para depois
caso exista a possibilidade desses planos não eliminarem as causas da reprovação; o da decisão
processo de revisão e os critérios utilizados são apreciados; e os critérios para a pró-
xima fase são ajustados. A definição desses critérios baseia-se nos padrões existentes no modelo de referência,
mas salienta-se que é na atividade de detalhamento do plano, no início de cada fase, que esses critérios são com-
pletamente definidos e aprovados.
O time assessor, descrito na atividade anterior, pode auxiliar o time de avalia-
ção, o qual normalmente possui pessoas do alto escalão da empresa e sem tempo Time assessor também
para se envolver com os detalhes do projeto, principalmente se a empresa estiver de- pode ajudar o time
de avaliação
senvolvendo muitos projetos ao mesmo tempo. Mas isso ocorre somente se ele
existir, pois ele não é imprescindível à realização do processo de gate.
Apesar de estarmos falando que uma fase precisa ser aprovada para darmos
continuidade ao projeto, podem existir casos em que algumas atividades da próxima Antes do gate pode-se
fase já sejam adiantadas antes do gate. Essa superposição de fases contribui para di- realizar atividades de outra
fase para acelerar o
minuir o tempo de desenvolvimento do produto. Caso a fase anterior seja reprovada desenvolvimento
e o projeto congelado ou cancelado, os recursos investidos no adiantamento da fase
seguinte serão perdidos. Na maior parte dos casos, todavia, essa prática diminui o
tempo de desenvolvimento.
A decisão de adiantar atividades de uma outra fase é tomada com base na expectativa compartilhada de
aprovação, com anuência dos tomadores de decisão. Mas, mesmo assim, não deixa de ser um risco calculado,
pois pode ocorrer que a fase seja reprovada e o projeto cancelado ou congelado.

Critérios
Assim como descrito na atividade genérica anterior, os tópicos deste livro relacionados com o processo de
revisão para cada uma das fases apresentam nos locais correspondentes os critérios específicos genéricos, que
devem ser tomados como referência na definição de critérios específicos. Tanto na atividade anterior de avalia-
112 PARTE 2 O Modelo

ção como nesta utilizam-se os mesmos critérios, pois a diferença está na análise do portfólio e na existência do
time de avaliação.

3.6 Documentar as decisões tomadas e registrar lições aprendidas


Ao longo de todo o processo de desenvolvimento de um projeto são realizadas atividades relacionadas à
melhoria do processo de desenvolvimento de produtos, e as lições aprendidas durante esse processo são fontes
importantes de informações para a realização das melhorias.
A captura das lições aprendidas não pode ser uma atividade informal e não estruturada, pois é preciso ga-
rantir que a análise crítica do que se realizou durante o desenvolvimento de um projeto seja sempre feita. Isso garante
mais transparência e facilita a gestão das ações de melhoria desdobradas a partir dessas lições. Quando não existe
a atividade de registro das lições aprendidas sistematizada, é comum que quase todos os novos conhecimentos
gerados ou aprimorados durante o desenvolvimento do projeto seja perdido ou esquecido, principalmente em
razão da dinâmica do fluxo de projetos de desenvolvimento que exige esforços contínuos das equipes de desen-
volvimento. Por outro lado, a realização de uma atividade dedicada à captura e registro de lições aprendidas,
apesar de requerer mais tempo dos profissionais, pode resultar em benefícios em termos de tempo e qualidade
muito significativos — principalmente em outros projetos.
A atividade “Registrar lições aprendidas” é uma atividade simples em termos de sistematização, porém
complexa em relação às análises necessárias. Para sua realização, uma equipe deve fazer uma análise normal-
mente estratificada por tópicos, tais como: aspectos técnicos do produto, aspectos técnicos do processo de pro-
dução, aspectos relacionados à gestão do processo de desenvolvimento e à gestão do projeto (estão incluídos
aqui aspectos relacionados a fornecedores, clientes, protótipos, capacitação de pessoal, liderança, estratégias
tanto de mercado quanto tecnológica).
Essa análise resulta em registros que devem ser recuperados a qualquer tempo pelas equipes de desenvolvi-
mento, visando a captura de conhecimentos úteis para a realização de atividades ao longo do projeto ou para a rea-
lização de melhorias no PDP. A atividade genérica de registro de melhorias e melhores práticas, que acontece no
final de cada fase, trata com detalhes a captura das lições aprendidas ao longo de todo o desenvolvimento.
A qualquer momento, durante o desenvolvimento, podem ser tomadas decisões e existem lições aprendidas
que podem ser registradas, para evitar que, no futuro, se incorram em erros semelhantes aos ocorridos no passado.
A empresa deve prover uma infra-estrutura que permita essa documentação. Além disso, os membros do time de
5
desenvolvimento devem estar capacitados para registrá-los e acessá-los durante a realização de suas tarefas.
Essa atividade genérica formaliza o momento da documentação. Em algumas
Deve-se registrar a todo o empresas, existe a prática de se exigir que os membros do time de desenvolvimento
momento experiências escrevam um relato de uma página sobre as lições aprendidas para que elas fiquem
adquiridas, mas existe um
momento formal para
registradas.
garantir a sua No caso do modelo, define-se a realização dessa atividade logo após o gate, mas
documentação pode-se exigir que um dos critérios para a aprovação da fase seja a evidência de exis-
tência da documentação das decisões tomadas e lições aprendidas. Ou seja, o re-
gistro desses conhecimentos ocorreria dentro do próprio processo de gate. As decisões e discussões que
acontecem no gate também contêm conhecimentos explícitos e também devem ser registradas, de forma a serem
recuperadas, quando necessário.
Não existe um conjunto de tarefas específicas para a realização dessa atividade. Conforme o grau de forma-
lismo da empresa, deve-se classificar essas informações e mesmo associá-las aos objetos do projeto/produto, a
fim de facilitar a sua recuperação e reutilização no futuro. Essa prática dificulta um pouco o processo de inserção
desses conhecimentos, pois exige que um membro do time insira essas informações adicionais às lições apren-

5
Existem hoje soluções computacionais baseadas em agentes, que analisam automaticamente os documentos armazenados, os relatos
que os projetistas criam, ou outras informações coletadas durante o desenvolvimento, ou mesmo nos gates. Dessa análise resulta uma
classificação de todo esse conteúdo, facilitando a sua recuperação posteriormente para reutilização daquele conhecimento registrado.
CAPÍTULO 3

Atividades Genéricas do Modelo 113

didas. Hoje existem alguns sistemas que analisam os textos e automaticamente o classificam, eliminando, assim,
a necessidade de inclusão dessas informações adicionais.
Porém, a existência de sistemas e procedimentos só ajuda, porque o mais importante é promover a cultura
dessa prática dentro da empresa. Isso pode ser obtido se houver a promoção consistente da Gestão do Conheci-
6
mento (veja o Tópico 2.12 sobre gestão do conhecimento). Ou seja, o mais importante é fazer com que os mem-
bros do time estejam conscientes da necessidade da documentação, e também treinados para realizá-la da forma
mais eficaz.

3.7 Questões e atividades didáticas propostas


Questões para reflexão
1. Qual o significado de uma atividade genérica?
2. Por que devemos atualizar o plano de projeto no início de cada fase do desenvolvimento?
3. Qual a razão de monitorar constantemente a viabilidade econômico-financeira do projeto e por que
existe essa atividade genérica formal?
4. Discuta os indicadores que são avaliados na atividade de monitoramento da viabilidade econômico-fi-
nanceira.
5. Qual a razão de separar a avaliação da fase em duas atividades? Qual o papel de cada uma dessas ativi-
dades? Como se deve proceder em uma empresa pequena?
6. Por que o time de desenvolvimento realiza uma auto-avaliação antes de se submeter à aprovação da
fase?
7. Qual seria o papel de um time assessor para colaborar no processo de revisão de fase?
8. Quando é que se divide o gate em revisão técnica antes da gerencial realizada durante a fase de desenvol-
vimento?
9. Liste e explique cada uma das possíveis tomadas de decisão em um gate.
10. O gate é um divisor entre fases. A partir dele uma outra fase se inicia. Quando é que são desenvolvidas ati-
vidades das fases subseqüentes mesmo antes da finalização e aprovação da fase anterior? Cite exemplos.
11. Qual a importância da atividade genérica de documentar as decisões tomadas e registrar lições apren-
didas?
12. Por que a atividade de registrar as lições aprendidas não pode ser uma atividade informal?
13. Qual a maior dificuldade em garantir a qualidade de registro das lições aprendidas?

Atividades didáticas
1. Simule com os colegas o início de uma fase. Selecione qualquer uma das fases de desenvolvimento. Re-
cupere um plano de projeto, monte um cenário de mudança e sinta como seria atualizar esse plano.
2. Entreviste gerentes de desenvolvimento de produtos visando levantar as características de alteração de
planos de projeto no meio de um projeto.
3. Recupere um estudo de viabilidade econômico-financeira de um projeto e simule a sua atualização no
caso de uma queda do volume de vendas previsto. Reutilize o modelo criado em uma planilha.
4. Modifique outras premissas do estudo de viabilidade econômico-financeira inicial e veja o resultado.
5. Selecione algumas das variações realizadas nas duas questões anteriores e escreva um relatório de aná-
lise do novo estudo para ser tomado como referência durante o gate da fase.

6
Gestão do conhecimento envolve a definição de políticas, disseminação de cultura, organização para a gestão do conhecimento, trei-
namento, motivação e também o oferecimento de sistemas de informação para apoiar essa prática. Esses sistemas são conhecidos como
portais corporativos para gestão do conhecimento (TERRA, 2000).
114 PARTE 2 O Modelo

6. Simule a auto-avaliação e a aprovação de fase com os seus colegas. Defina um conjunto de critérios de
passagem, com base nos critérios fornecidos no final da cada capítulo que descreve uma fase. Acrescente
novos critérios. Imagine um cenário e siga passo a passo as recomendações da atividade de avaliar a fase.
7. Realize novamente a atividade anterior, considerando, agora, o relatório recebido do monitoramento
da viabilidade econômico-financeira. Compare as duas auto-avaliações.
8. Discuta com os seus colegas como vocês fariam para monitorar os indicadores não-financeiros do pro-
jeto durante o gate.
9. Simule o final de uma fase e tente escrever e registrar uma lição aprendida. Reúna as lições escritas pelos
colegas e defina um padrão de formulário e uma forma padronizada de armazená-las. Após isso, critique
as decisões tomadas e veja como isso poderia ser melhorado.
10. Tente buscar exemplos de empresas que praticam o registro de lições aprendidas (use para isso a
Internet, publicações, informações adicionais ou contatos já existentes).

3.8 Informações adicionais


COOPER, R. G.; EDGETT, S. J.; KLEINSCHMIDT, E. J. Portfolio management for new products.
United States of America: Perseus Books, 1998. p. 230. Disponível em: <http://www.stage-gate.com>. Acesso
em: 21 fev. 2005.
PMI (Project Management Institute). “PMBOK — A Guide to the Project Management Body of
Knowledge.” USA, 2000.
TERRA, J. C. C. Gestão do conhecimento e e-learning na prática. São Paulo: Negócio Editora, 2003. p. 363.
TERRA, J. C. C. Gestão do conhecimento: o grande desafio empresarial — uma abordagem baseada no
aprendizado e na criatividade. São Paulo: Negócio Editora, 2000. p. 283.
TERRA, J. C. C.; GORDON, C. Portais corporativos: a revolução na gestão do conhecimento. São Paulo:
Negócio Editora, 2002. p. 453.
VALERI, S. G. “Estudo do método de aprovação de fases no processo de desenvolvimento de produtos em
uma indústria automobilística.” Dissertação (Mestrado) — Escola de Engenharia de São Carlos,
Universidade de São Paulo, 2001.
VALERI, S. G.; ROZENFELD, H. “Improving the flexibility of new product development (NPD) through a
new quality gate approach.” Journal of Integrated Design and Process Science, USA, v. 8, n. 3, p. 17-36, set. 2004.
4.1 Sumário
4.2 Definir escopo da revisão do PEN
4.3 Planejar atividades para a revisão do PEN
4.4 Consolidar informações sobre tecnologia e mercado
4.5 Revisar o PEN
4.6 Analisar o portfólio de produtos da empresa
4.7 Propor mudanças no portfólio de produtos
4.8 Verificar a viabilidade do portfólio de produtos
4.9 Decidir o início do planejamento de um dos produtos do portfólio
4.10 Questões e atividades didáticas
4.11 Informações adicionais
4. Planejamento Estratégico de Produtos
Planejamento Estratégico de Produtos
PARTE 2 O Modelo

Depois da leitura deste capítulo, você será capaz de:


l Entender a relação entre o Processo de Planejamento Estratégico da empresa e o Plano Estratégico de Produtos.
l Compreender o significado e a importância do Planejamento Estratégico de Produtos e o Portfólio de Produtos.
l Identificar a diferença entre produto e tecnologia.
l Conhecer as diferentes fontes de dados sobre o mercado e tendências tecnológicas.
l Entender os principais cuidados na coleta de informações sobre mercado e tendências tecnológicas.
l Descrever quais os objetivos e as metas da gestão de portfólio.
l Descrever quais as atividades e ferramentas disponíveis para realizar o planejamento estratégico de produtos; isto é, a
definição dos projetos de desenvolvimento.
l Entender a importância da segmentação e posicionamento dos produtos na definição do portfólio de produtos,
incluindo as diferentes estratégias possíveis.
l Listar todo o conteúdo de um Plano Estratégico de Produtos.
l Dar início ao desenvolvimento de seu primeiro Plano Estratégico de Produtos.
l Compreender como se dá a passagem entre as fases de Planejamento Estratégico de Produtos e o Planejamento do
Projeto por meio da Minuta do Projeto.

4.1 Sumário
O Planejamento Estratégico de Produtos (PEP) é a primeira fase do modelo e inicia a macrofase de pré-de-
senvolvimento. Conforme apresentado no Capítulo 2 (Tópico 2.4.1), a macrofase de pré-desenvolvimento en-
116 PARTE 2 O Modelo

volve as atividades de definição do projeto de desenvolvimento — realizada a partir da estratégia da empresa —,


restrições de recursos e conhecimentos, e informações sobre os consumidores, tendências tecnológicas e merca-
dológicas, conforme a área em destaque na Figura 4.1, a seguir.

Figura 4.1 Localização das fases do pré-desenvolvimento dentro do processo de desenvolvimento de produtos unificado.

A Figura 4.1 ilustra como a macrofase de pré-desenvolvimento do nosso modelo é, portanto, dividida em
duas fases: Planejamento Estratégico de Produtos e Planejamento do Projeto.
O objetivo do Planejamento Estratégico de Produtos é obter um plano contendo o portfólio de produtos
da empresa a partir do Planejamento Estratégico da Unidade de Negócios. Na prática, isso significa uma lista
descrevendo a linha de produtos da empresa e os projetos que serão desenvolvidos, de maneira a auxiliá-la a
atingir as metas estratégicas de negócio. Para os produtos em comercialização, esse portfólio de produtos deve
incluir uma previsão da retirada do mercado. Com relação aos produtos a serem desenvolvidos, é preciso conter
uma primeira descrição de suas características e metas para início de desenvolvimento, lançamento e retirada.
Esse plano parte da estratégia de negócios, corporativa e/ou da unidade de negócio, e sua adequação a ela é fun-
damental. Por exemplo, se a estratégia da empresa é competir por meio de diferenciação tecnológica, o portfólio
de produtos deve ser planejado de forma que a empresa possua uma linha de produtos mais sofisticada que a de
seus concorrentes, isto é, que tenha conteúdo tecnológico maior, funções inovadoras e características que trans-
mitam essa sensação aos consumidores, tais como o design arrojado. Por outro lado, se a estratégia da empresa é
atacar o mercado de consumidores de baixa renda, toda a linha de produtos e as tecnologias escolhidas devem,
além de atender às necessidades em termos de forma e função, apresentar custos aceitáveis a esses consumidores
e considerar as restrições de estilo de vida, como espaço e tipo de moradia.
Os principais atores nessa fase são os membros da diretoria e os gerentes fun-
Quem assume o papel mais cionais. Uma prática avançada é formar o que se denomina de Comitê de Aprovação
importante nessa fase? de Produtos ou Comitê Gestor do Portfólio de Produtos. Esse comitê torna-se res-
ponsável por gerenciar o portfólio de produtos, decidindo quais produtos serão re-
tirados do mercado e quais projetos de desenvolvimento serão realizados. No Modelo Unificado, esse papel é
denominado de Time de Planejamento Estratégico de Produtos.
CAPÍTULO 4

Planejamento Estratégico de Produtos 117

Em uma grande empresa multinacional, poderão existir vários desses comitês, espalhados por regiões do
mundo e famílias de produtos. Em uma empresa pequena, poderá inexistir um comitê formal, e essa função será
tratada dentro das próprias reuniões de diretoria. O que importa, na verdade, é que a responsabilidade por essa
decisão seja bem definida e de preferência delegada a uma equipe multifuncional com capacidade de decidir so-
bre a realização ou não de um produto. Por isso, certamente deverá envolver membros da alta gerência da em-
presa. Todas as áreas devem acompanhar e dar opiniões sobre a adequação da linha de produtos, melhorando a
qualidade das decisões e criando uma visão coerente sobre os objetivos específicos de cada projeto.
Esse é um avanço em relação ao passado no qual, muitas vezes, essa decisão
cabia unicamente ao marketing ou ao departamento de engenharia. Nesses casos, As vantagens dos comitês
muitas vezes informações importantes de outros setores como manufatura e distri-
buição não eram consideradas nessa decisão, além de dificultar o processo de desdobramento da estratégia por
falhas de comunicação e entendimento da visão da empresa pelas áreas funcionais responsáveis por tais escolhas.
Sabe-se atualmente que é fundamental analisar a linha de produtos sobre a ótica da estratégia da empresa como
um todo, considerando a realidade de todas as áreas da empresa. Ao mesmo tempo, o envolvimento de membros
da alta gerência é crucial porque são eles que conhecem profundamente a estratégia de negócios da empresa.
Um exemplo para a formação desse comitê seria: um diretor de cada área funcional (manufatura, marketing, lo-
gística, qualidade, finanças etc.) e os gerentes das áreas de desenvolvimento de produtos e marketing. No de-
correr deste capítulo, adotaremos o nome Time de Planejamento Estratégico de Produtos.
O fluxo das atividades da fase de Planejamento Estratégico de Produtos é apresentado na Figura 4.2. A
principal informação de entrada é o Planejamento Estratégico de Negócios. Conforme apresentado no Capí-
tulo 3, no caso de grandes corporações, ele pode ser formado por mais de um planejamento: o Planejamento
Estratégico da Corporação e o Planejamento Estratégico da Unidade de Negócios. Esse plano, ou conjunto de
planos, contém a estratégia da empresa dentro de um horizonte de planejamento, que, em suma, define como a
empresa pretende competir e quanto almeja crescer. A saída dessa fase é a definição de um portfólio de produtos
e projetos que permitam que a empresa atinja este objetivo.

Figura 4.2 Fluxo de atividades da fase de Planejamento Estratégico de Produtos.


118 PARTE 2 O Modelo

4.2 Definir escopo da revisão do PEN


A primeira atividade desta fase é definir o nível de avaliação do Planejamento Estratégico, em que o Time
de Planejamento Estratégico de Produtos deverá definir qual o nível de detalhamento e esforço necessários. A
Figura 4.3 resume o conteúdo dessa atividade, que parte do Plano Estratégico de Negócios já elaborado. O re-
sultado final será um documento simples, descrevendo o escopo da mudança e os assuntos a serem discutidos.

Figura 4.3 Resumo da atividade “Definir o escopo de revisão do PEN”.

Isso é importante em razão do horizonte de planejamento. Em geral, um plano estratégico é revisto de pe-
ríodo em período, anual ou semestralmente, mas aborda um horizonte de médio a longo prazos, entre 2 até 10
anos, dependendo do negócio. Pode ser que, de um ano para outro, não ocorram alterações significativas no ce-
nário previsto no período anterior. É o caso quando não surge nenhum concorrente novo, nenhuma tecnologia
inovadora e não existam sinais de mudança no comportamento e perfil dos consumidores. Nessa situação, certa-
mente o novo Plano Estratégico conterá pequenas alterações em relação ao plano anterior e, provavelmente,
poucas metas mudaram no Planejamento Estratégico da Unidade de Negócios. Conseqüentemente, não há ne-
cessidade de grandes estudos ou grandes decisões durante a revisão do novo Plano Estratégico de Produtos.
Assim, não faz sentido um grande esforço de revisão, e essa atividade pode ser realizada rapidamente sem en-
volver maiores recursos e estudos aprofundados.
Entretanto, há situações em que ocorrem grandes mudanças no cenário, tais como: fusões dos principais
concorrentes, novos concorrentes de peso que não haviam sido previstos, surgimento de uma inovação tecnoló-
gica radical não prevista pela empresa ou mesmo uma mudança na sociedade, ocasionando a alteração de um há-
bito de consumo relacionado com o produto. No extremo da situação inovadora, deve-se contar também com a
situação em que a empresa está criando pela primeira vez seu Planejamento Estratégico da Unidade de Negó-
cios: por exemplo, quando ela está entrando pela primeira vez naquele mercado. Nesse caso, a equipe que está rea-
lizando o Planejamento de Produtos precisa se familiarizar e estudar criticamente o Planejamento de Negócios
recém-elaborado. Ela necessitará de várias rodadas de reuniões, incluindo o apoio de especialistas em assuntos
específicos e o levantamento de informações como pesquisas e relatórios.
Resumindo, independentemente do grau de mudança, o objetivo dessa atividade inicial é avaliar o nível de
análise necessário para que as atividades de planejamento sejam, enfim, planejadas! É o primeiro passo a ser rea-
lizado pelo Comitê de Avaliação de Produtos. Geralmente, inicia com o coordenador. Ele distribui cópias do
CAPÍTULO 4

Planejamento Estratégico de Produtos 119

Plano Estratégico de Negócios previamente para que os membros possam se preparar. Em geral, em uma reu-
nião rápida, o time deve:

n analisar o Plano Estratégico de Negócios;


n definir os assuntos a serem discutidos;
n avaliar os elementos do Time de Planejamento Estratégico de Produtos, com o intuito de identificar
possíveis competências complementares;
n definir a metodologia de revisão (quais fases, atividades e técnicas a serem utilizadas);
n definir o prazo final para o término do trabalho; e
n compilar o documento de declaração de escopo de revisão do PEN.

O coordenador deve estar atento para evitar o início da discussão dos assuntos específicos. Isso é muito
comum, e acaba prolongando a reunião desnecessariamente, tornando-a improdutiva. O resultado final é um do-
cumento, denominado, em nosso modelo, de Escopo de Revisão do Plano Estratégico, contendo tais informações. Pode
ser um documento simples, uma folha de papel, o importante é que se discuta e formalize o que deverá ser feito.

4.3 Planejar atividades para a revisão do PEN


Uma vez definido o escopo de revisão do planejamento estratégico, o Time de Planejamento Estratégico
de Produtos poderá iniciar o planejamento das atividades de revisão do Plano Estratégico de Negócios e de pre-
paração do Plano Estratégico de Produtos. Isto é, definição das atividades, prazos e recursos necessários. Essa
atividade é sintetizada na Figura 4.4. As entradas são, além do Plano Estratégico de Negócios, a Declaração de
Escopo de Revisão, preparada na atividade anterior. Os resultados principais são o cronograma de atividades e
as agendas de discussões. Esta atividade pode acontecer na mesma reunião da atividade anterior.

Figura 4.4 Resumo da atividade “Planejar atividades para a revisão do PEN”.

Uma prática comum é a utilização de workshops, isto é, reuniões de trabalho na quais os membros do time
apresentam estudos específicos, realizam análises, discutem os resultados e tomam decisões. Pode-se fazer uma
120 PARTE 2 O Modelo

agenda com os principais temas que precisam ser discutidos e uma programação para atacá-los um a um. Uma pes-
soa ou subgrupo deve ser nomeado como redator e ficará com a responsabilidade de documentar os resultados.
É comum, também, que esses encontros ocorram fora do ambiente da empre-
Cuidados com o sa, como maneira de livrar os membros do comitê das interrupções rotineiras. A
Planejamento da Revisão idéia é manter o grupo concentrado para que os encontros sejam proveitosos. Se as
pessoas começam a se dispersar, as discussões se perdem e nenhuma decisão será to-
mada. Por exemplo, se um membro precisa se ausentar, mesmo que por minutos, quebra-se o ritmo da discussão
e todos perdem tempo. Atualmente, só a distância física não é suficiente. Deve-se oferecer orientações especí-
ficas quanto ao uso de celulares e laptops com conexão “sem fio”. É comum observar pessoas desrespeitando seus
colegas, consultando e-mails, enquanto os demais membros do grupo discutem.
Outro aspecto que precisa ser bastante cuidadoso nesse processo é a democratização. Sempre que se
formam pequenos grupos, alguns de seus membros acabam tomando naturalmente um papel de liderança, exer-
cendo uma influência mais significativa nas decisões dos grupos. Seja pela legitimidade do cargo, como o presi-
dente ou um grande diretor da empresa, pelo próprio carisma ou por algum domínio técnico especializado e
reconhecido por todos. Nesses casos, cabe às pessoas que estão planejando o processo encontrar métodos de tra-
balho em que todas as pessoas possam expressar livremente suas opiniões. Do contrário, as pessoas se calam e
concordam em um primeiro momento. Mas, depois de terminado o processo, questionarão as decisões obtidas
e, independentemente da qualidade do resultado final, o plano perderá legitimidade, não sendo seguido.
Um entrave à prática de realização de reuniões e workshops para planejamento é a grande mobilização da
alta gerência, privando-a de suas atividades normais durante horas ou dias. Na maioria das empresas, isso é mui-
to difícil, tanto por problemas de agenda quanto pelo investimento monetário que isso significa. Mais um mo-
tivo para que essa atividade de planejamento seja muito bem executada. Deve-se considerar todas as restrições
de tempo e recursos, planejando um processo de discussão proveitoso e útil para a empresa e, ao mesmo tempo,
que consuma o menor tempo possível.
Se realizada com êxito, ao final dessa atividade, o Time de Planejamento Estra-
Resultados do tégico de Produtos obterá as seguintes informações: lista dos especialistas e consul-
planejamento da revisão tores que deverão apoiar o time em assuntos específicos; cronograma de reuniões e
eventos (com data, local, participante, agenda e metas a serem cumpridas em cada
uma delas) e programação dos recursos necessários em cada uma das atividades. Se realizadas com êxito, as ativi-
dades planejadas levarão a uma visão consensual da estratégia de negócios da empresa e do papel da linha de pro-
dutos, com o mínimo investimento de tempo e recursos.
O planejamento da revisão pode ser realizado concomitantemente à atividade
Definição do escopo da anterior. Nesse caso, a primeira reunião do Time de Planejamento Estratégico de
revisão e do planejamento Produtos poderia servir para decidir o escopo e realizar o planejamento. Na outra
se sobrepõem
opção, no caso de ocorrerem separadamente, a definição do escopo é feita pelo time,
e o planejamento pode ficar sob a responsabilidade do coordenador, que enviaria
uma proposta de atividades e prazos para análise e aprovação pelos demais membros. Esse último caso é o mais
recomendado para grandes corporações e atividades de planejamento com escopo maior de revisão. O planeja-
mento deverá consumir muito tempo, e seria um desperdício de recursos manter os executivos desse comitê en-
volvidos com tal atividade.

4.4 Consolidar informações sobre tecnologia e mercado


Definido o escopo da revisão e, portanto, das alterações necessárias no portfólio de produtos da empresa, é
preciso que o Time de Planejamento Estratégico de Produtos se prepare para realizar as atividades posteriores
de revisão dos planos e proposição do portfólio de produtos. Todas as decisões referentes ao planejamento es-
tratégico dependem do conhecimento das pessoas em relação ao ambiente, isto é, mudanças nos competidores,
concorrentes e as tecnologias que vão sendo desenvolvidas. Portanto, é fundamental que a empresa man-
tenha-se continuamente atenta às mudanças. Não é possível traçar uma estratégia e definir uma linha de pro-
CAPÍTULO 4

Planejamento Estratégico de Produtos 121

dutos sem que se conheça profundamente o mercado, isto é, quais os competidores e os hábitos e preferências do
consumidor, e sem o domínio das características das tecnologias disponíveis e as tendências de inovação futuras.
Por isso, o modelo unificado contém a atividade de consolidar as informações sobre tecnologia e mercado,
sintetizada na Figura 4.5. As entradas são as informações já compiladas nos planos já traçados, e a saída é um con-
junto de dados e informações que as complementam e aprofundam. Na verdade, essa atividade pode ser reali-
zada paralelamente a todas as demais atividades realizadas nessa fase.

Figura 4.5 Resumo da atividade “Consolidar informações sobre tecnologia e mercado”.

No início da Revolução Industrial, as mudanças nos produtos eram significati-


vamente mais lentas. Produtos como o Ford T permaneceram em produção du- A importância da
rante dezenas de anos e demoravam vários deles para ser projetados. Além de lentas, informação: uma
vantagem competitiva no
as mudanças eram relativamente bem conhecidas por todos os profissionais da in-
desenvolvimento de
dústria. As principais informações vinham da rede de relacionamento dessas pes- novos produtos
soas, sendo a experiência e o contato dos profissionais de alto escalão a principal
fonte de informações sobre o mercado. Com relação à tecnologia, a principal fonte
vinha das bases de patentes, monitoradas pelas empresas. Portanto, no fundo, as empresas assumiam que as
ações de busca de informações sobre mercado e tecnologia eram como uma atividade informal e implícita nas
funções de marketing e desenvolvimento de produtos.
Essa situação mudou radicalmente. Não apenas em razão da velocidade, mas também no que se refere à
quantidade de informações, que vem se tornando assustadoramente grande. Tudo isso, aliado ao mercado alta-
mente competitivo, faz do “conhecer precisamente as características dos consumidores” uma importante van-
tagem competitiva. Na “batalha” com a concorrência, é fundamental distinguir precisamente os produtos em
grupos com comportamentos similares (os segmentos de mercado) e definir estratégias específicas para cada
segmento-alvo. Na analogia com a guerra de precisão, os “tiros”, no caso os projetos de novos produtos, pre-
cisam atingir alvos precisos para evitar o desperdício de munição e aumentar a eficácia, isto é, o sucesso empresa-
rial. Quanto maior o conhecimento sobre os consumidores, maior a probabilidade da empresa atendê-los
adequadamente ou melhor que seus concorrentes. Essas informações provêm de diversas fontes, e as empresas
com melhores práticas em desenvolvimento de produtos desenvolvem procedimentos sistemáticos para
122 PARTE 2 O Modelo

captá-las. Dividiremos a atividade em três tarefas principais: coletar informações de mercado, coletar informa-
ções tecnológicas e gerar cenários e análises.
Com relação ao mercado, as pessoas associam tradicionalmente esse processo
Tarefa 1: Coletar de busca ao termo pesquisa de mercado. Muitas também associam esse nome à reali-
informações sobre o zação de uma pesquisa em si, isto é, a atividade de aplicação de um questionário ou
mercado (clientes,
concorrentes e cadeia de
realização de uma enquete. A visão mais moderna de pesquisa de mercado, porém, a com-
suprimentos) preende como a função que integra o consumidor, o cliente e o público aos profissio-
1
nais por meio de informação. Essa definição deixa claro que pesquisar um mercado
é mais do que realizar um levantamento de dados específico. Trata-se de coletar e
organizar informações de diferentes fontes de dados, isto é, dados obtidos de periódicos especializados do setor,
relatórios de agências de serviço de marketing, dados dos sistemas de vendas da empresa, entre outros. Uma
classificação dos tipos de fontes de dados pode ser consultada no Quadro 4.1, a seguir.

Quadro 4.1 Fontes de Dados para Pesquisa de Mercado

As fontes de dados para pesquisas de mercado podem ser divididas em dois grupos principais: fontes primárias e fontes
secundárias. As fontes primárias são aquelas que obtêm dados sob medida para o usuário da informação, conforme as ne-
cessidades do projeto — seja ele o desenvolvimento de um produto ou a análise do desempenho da empresa. Um exemplo
é uma observação no campo ou uma pesquisa do tipo enquete, projetadas e conduzidas especialmente para responder a
certas dúvidas encontradas no decorrer de um processo de planejamento estratégico. As fontes secundárias são aquelas
que produziram informações para outros fins, mas que são úteis ao projeto. Exemplos são uma pesquisa publicada em um
jornal, dados do censo do Instituto Brasileiro de Geografia e Estatística (IBGE) ou estatísticas computadas a partir do sistema
de vendas da empresa. As fontes podem ainda ser classificadas em três grupos cada, conforme apresentado na Figura 4.6.

Figura 4.6 Tipos de fontes de dados.

As fontes secundárias de dados podem ser divididas em três tipos:


Registros Internos: é formada pelos dados que a empresa produz durante as operações rotineiras, tais como estatísticas
de defeitos da assistência técnica, quantidade de vendas, observações dos pontos-de-venda coletadas pelos vendedores,
chamadas para o serviço de atendimento ao consumidor (0800) etc. Se bem planejados, fornecem informações significativas
com custo pequeno para a organização, na medida em que são obtidos de atividades inevitavelmente realizadas pela em-
presa. Um exemplo interessante é o de uma pequena empresa de eletrodomésticos brasileira que criou um programa de ga-
rantia estendida, grátis para seus clientes, desde que eles preenchessem um cadastro. Com isso, a empresa conseguiu
coletar um conjunto significativo de informações valiosas sobre o perfil de seus consumidores.

(continua)
1
Esse é um resumo da definição adotada pela American Marketing Association, cuja íntegra pode ser consultada em AAKER, KUMAR
& DAY (2001).
CAPÍTULO 4

Planejamento Estratégico de Produtos 123

Quadro 4.1 Fontes de Dados para Pesquisa de Mercado (continuação)

Dados Publicados e de Uso Comum: trata-se de informações dirigidas ao grande público sobre o setor ou o mercado
consumidor. São os jornais e as revistas especializadas tradicionais, seja na mídia impressa, televisiva ou Internet. Pode-se
acessar tais informações de duas maneiras. Assinando as principais publicações do setor (as principais revistas etc.), acompa-
nhando e filtrando as notícias — o chamado clipping. Outra maneira é adquirindo os serviços de uma agência de informação.
São empresas especializadas, que vendem seus serviços inclusive para os jornais, e que, muitas vezes, possuem canais de in-
formação específicos para diferentes ramos de atividade. Cada canal é uma publicação em tempo real, por televisão ou cada
vez mais comumente via Internet, em que as notícias são atualizadas conforme vão sendo produzidas: on time. Outros dados
de uso comum são as informações coletadas pelas agências e órgãos governamentais e associações dos diferentes tipos, pa-
tronais, comerciais e de trabalhadores. Exemplos de dados de agências governamentais são os produzidos pelo IBGE na área
de informações sobre população e território brasileiro e a Fundação Getúlio Vargas e o Instituto Nacional de Pesquisas Eco-
nômicas (IPEA) para dados sobre desempenho econômico (inflação, PIB etc.). A Associação Nacional dos Fabricantes de Veí-
culos Automotores (Anfavea) e o Sindicato Nacional da Indústria de Componentes para Veículos Automotores (Sindipeças)
são exemplos de associações empresariais atuantes, que reúnem dados importantes sobre esses setores econômicos. Tais
dados podem ser obtidos pela compra de publicações ou filiação. Os publicados de uso comum são básicos e, se bem traba-
lhados, podem auxiliar imensamente no planejamento de produtos ou o planejamento estratégico.
Dados Padronizados de Marketing: nesta categoria incluem-se dados produzidos por empresas da área de informação
e de marketing, voltados exclusivamente para avaliação do mercado. São produzidos por empresas que visam o lucro com a
comercialização dessa informação, vendendo-a para as empresas que atuam no setor. Exemplos desse tipo de material são
os painéis setoriais comercializados pela Gazeta Mercantil. Cada um deles voltado para determinado setor e contendo dados
como dimensão do mercado brasileiro, divisão entre os principais concorrentes e tendências. Outro exemplo famoso está na
área de informática, são os relatórios do Gartner Group. Um exemplo bem conhecido no Brasil é a pesquisa de medição de
audiência televisiva do Ibope. Esse produto é resultado da introdução de aparelhos em uma amostra de lares de diversas ci-
dades. As empresas que compram esse serviço (agências de propaganda e emissoras) recebem um aparelho em que podem
acompanhar instantaneamente o índice de audiência dos programas da TV aberta. Há painéis similares para medição de
rádio e Internet. A empresa Nielsen de pesquisa de mercado comercializa nos Estados Unidos diversos serviços desse tipo,
tais como: painéis de auditoria de lojas, painel de consumo doméstico, entre outros. As informações obtidas por esses tipos
de pesquisa são bem mais detalhadas e profundas que os dados de uso geral, porém, o valor para a sua aquisição costuma
ser expressivo, muitas vezes mais caro que a assinatura de revistas e serviços de informação.
Os dados secundários são a principal fonte para se responder a questões como dimensionamento do mercado e partici-
pação da empresa e seus concorrentes. Eles podem também indicar problemas ou mudanças de comportamento, identifi-
cando a necessidade de busca por dados primários. Além disso, os dados secundários de registros internos podem oferecer
boas informações sobre necessidades dos clientes sem precisar de altos investimentos. Outra vantagem dos dados secundá-
rios é que eles oferecem informações ricas para o planejamento e coleta adequada e racional de dados primários, que
podem ser divididos em:
Pesquisas Qualitativas: são pesquisas que empregam métodos capazes de analisar informações abstratas como concei-
tos e percepções dos consumidores. Os tipos de pesquisa qualitativa são as seguintes:
1. Observação Direta: trata-se do tipo mais simples de pesquisa qualitativa. O pesquisador sai a campo e observa direta-
mente o consumidor, utilizando ou comprando o produto. No desenvolvimento de equipamentos e máquinas agrícolas
para se beneficiar mexilhão, por exemplo, a equipe de projeto pode acompanhar um grupo de maricultores em ação, obser-
vando-os limpar as cascas e classificar os animais. Em projetos de caminhões, tratores e equipamentos diversos, esse é um
meio bastante eficaz de entender as necessidades dos clientes, inclusive de identificar comportamentos como usos peculiares
de ferramentas e questões de manutenabilidade — alguns deles culturais e específicos da população. Outro uso importante
é no projeto de embalagens como forma de determinar quais preferências e parâmetros são utilizados pelo consumidor. Um
exemplo desse tipo de pesquisa é a escolha do tipo de embalagens de iogurte. Existem vários tipos: plástico, tetra pak, em di-
ferentes volumes. O pesquisador se posiciona no supermercado, próximo à estante desse produto, e observa os consumi-
dores durante a escolha. Ao final, como forma de melhorar essas impressões, ele pode inclusive abordar o consumidor e
pedir para que justifique sua escolha. Trata-se de um método limitado em termos de generalização dos resultados, pois não
é possível realizar muitos casos de observação dada a restrição de tempo.
2. Entrevistas Individuais em Profundidade (Entrevista): o segundo tipo de pesquisa qualitativa é a que utiliza o mé-
todo da entrevista. Nesse caso, um entrevistador aborda o consumidor e faz um conjunto de perguntas, anotando cuidado-
samente os resultados. São perguntas abertas ou que buscam percepções ou explicações para um conjunto de respostas
fechadas. É o caso, por exemplo, de pesquisas para verificar a aceitação de produtos como perfumes ou alimentos. O entre-
vistador pode mostrar o produto e colher dos consumidores não apenas a informação se ele compraria ou não, mas,
também, explicações do porquê ou impressões sobre o produto. Nesses casos, isso é fundamental para verificar se a essência

(continua)
124 PARTE 2 O Modelo

Quadro 4.1 Fontes de Dados para Pesquisa de Mercado (continuação)

ou o sabor despertam o interesse planejado no início do projeto. É um tipo de pesquisa que exige um entrevistador bem pre-
parado, capaz de abordar o cliente adequadamente, conduzir a conversa e realizar anotações precisas. A compilação dos
dados também é demorada. O instrumento de coleta é chamado de Roteiro de Entrevista.
3. Clínicas (Focus Groups): é o tipo de pesquisa na qual se seleciona um grupo de consumidores e realiza-se, em ambien-
te controlado, uma dinâmica de grupo em que os clientes são estimulados a reagir diante dos produtos e são avaliados seus
comportamentos, comentários e sugestões. Os grupos variam de 5 a 9 pessoas e podem conter diferentes dinâmicas. Por
exemplo, uma empresa que produz cadeiras pode verificar em uma pesquisa prévia que os clientes querem algo moderno.
Mas, o que é moderno para o seu mercado consumidor? Uma clínica pode ser projetada de forma a colocar os consumidores
em um ambiente contendo fotos ou modelos de cadeiras prévia e intencionalmente escolhidos, contendo combinações
propositais de diferentes tipos de materiais, cores e formas básicas. Esse grupo discutiria quais são as mais “modernas”, e os
projetistas poderiam avaliar quais características estão associadas à modernidade. Pode ser que as cadeiras em que predo-
minava o uso de aço inoxidável, plásticos transparentes e formas orgânicas (indefinidas, com esferas e fluidez) poderiam ser
as de preferência dos clientes durante a dinâmica, com comentários cheios de referências a essas características. As clínicas
são muito utilizadas na indústria automobilística para se validar e aprimorar o design. Pode ser utilizado também para avaliar
a mensagem do produto, a “usabilidade”, a dificuldade de montagem e outras questões desse tipo. Trata-se de um tipo de
pesquisa mais complexa, pois exige profissionais especializados para a definição da dinâmica, escolha de um grupo de con-
sumidores representativo, um ótimo facilitador para conduzir a dinâmica e profissionais experientes para analisar o resul-
tado e discuti-los com a equipe de planejadores ou projetistas.
Pesquisa Quantitativa (Enquetes): considera-se como pesquisa quantitativa de dados primários a pesquisa por meio de
enquetes. Como o nome diz, trata-se de desenvolver um questionário com perguntas objetivas (utilizando números ou múl-
tiplas escolhas) que podem ser respondidas pelo próprio consumidor ou com a ajuda de um entrevistador. O questionário
pode ser aplicado por correio (o formulário é enviado e recebido por carta), por telefone, fax ou mensagem eletrônica. Como
se trata de dados objetivos, a enquete é mais fácil de ser respondida, a entrevista dura um tempo menor que a entrevista em
profundidade e exige menor capacitação do entrevistador, nos casos em que é necessária sua presença — como nas en-
quetes por telefone. Assim, ela é viável de ser aplicada a amostras de tamanho grande e, portanto, é recomendada nos casos
em que se busca uma informação precisa e deseja-se uma precisão na generalização dos resultados para a população como
um todo. Em um projeto de produto poderia ser utilizado, por exemplo, para entender o grau de prioridade dos clientes
diante de um conjunto de atributos previamente listados em uma pesquisa de caráter qualitativo. Pode ser utilizada
também para descobrir co-relações entre diferentes aspectos de consumo. Por exemplo, um questionário contendo idade e
preferência de cor coletadas dos clientes poderia indicar uma co-relação entre as cores mais modernas (diferentes do tradicional)
e menor idade. Isso é uma indicação de que, para esse produto, os clientes mais idosos preferem cores mais tradicionais. Essa
informação pode ser valiosa no momento da escolha de opções de cores para produtos posicionados para as diferentes faixas
etárias. Existem métodos de análise estatística bastante eficientes, capazes de detectar padrões de correlação não espe-
rados, e esse tipo de informação é fundamental para atividades como a segmentação de mercado. Sua limitação é quanto
aos aspectos qualitativos, como impressões e explicações, que não podem ser obtidos por meio de perguntas objetivas.
Experimentos Controlados: os experimentos são um método de pesquisa no qual se constrói uma situação ou ambien-
te com variáveis controladas para testar uma ou mais hipóteses. Um exemplo é o teste de sabores, realizado amplamente nas
empresas do ramo alimentício. Uma informação de mercado importante é saber, por exemplo, se o cliente consegue dife-
renciar o sabor de uma marca de cerveja da outra. Para verificar essa informação, monta-se um experimento em que os con-
sumidores são desafiados a provar as diferentes bebidas, sem a identificação, e responder qual delas é a marca líder. Isso
pode acontecer em supermercados, feiras e outros locais freqüentados por consumidores representativos do mercado e
normalmente envolve algum tipo de brinde para incentivá-los a participar do teste. Aos olhos do cliente, isso pode ser feito
de maneira a parecer uma brincadeira ou promoção, aliando o teste a uma iniciativa promocional. É comum utilizar experi-
mentos para saber ainda: quais atributos de um produto alimentício (sal ou açúcar, por exemplo) estão correlacionados com
o sabor, qual a melhor cor de um pão ou massa e assim por diante. Experimentos podem ser conduzidos também para avaliar
atributos de embalagens e mesmo a aceitação de comerciais de TV. Existem várias técnicas estatísticas, na área chamada de
Planejamento de Experimentos, que visam obter o maior número possível de inferências com a menor quantidade de ro-
dadas de experimentos. Elas são intensamente utilizadas nesse tipo de pesquisa.
Uma boa pesquisa de mercado é a compilação rigorosa e adequada de dados provenientes das diversas fontes. Com re-
lação ao processo de desenvolvimento de produtos, ela pode ser utilizada para gerar informações sobre o mercado e dar
subsídios às decisões das fases de Planejamento Estratégico da Corporação ou de produtos. Mais tarde, veremos que esses
mesmos instrumentos podem ser utilizados na fase de projeto informacional para que a equipe de projetistas de uma oferta
de produto em si possa descrever as necessidades específicas dos clientes quanto àquele produto. O resultado final, repre-
sentado pela figura de base de dados no centro da Figura 4.1, é um conjunto de dados, observações e afirmações sobre o
mercado da empresa ou sobre as necessidades dos clientes relacionadas a um produto específico.
Fonte: AAKER, D.; KUMAR, V.; DAY, G. S. Pesquisa de marketing. São Paulo: Atlas, 2001.
CAPÍTULO 4

Planejamento Estratégico de Produtos 125

Uma observação importante sobre a pesquisa de mercado diz respeito à sua


utilidade. É comum encontrarmos duas afirmações: a de que pesquisa de mercado é Limitações da pesquisa
“cara” ou que, para produtos muito inovadores, ela não funciona. Ambas são incor- de mercado
retas se considerarmos o conceito apresentado anteriormente. De fato, realizar um
painel de consumidores, uma enquete ampla, comprar o relatório de painel de consumo direto (como a au-
diência de TVs do Ibope) ou realizar uma clínica envolve um investimento considerável à medida que são formas
de coletas de dados que exigem esforços de profissionais especializados e gastos elevados de ações no campo. O
Quadro 4.1 demonstra claramente que essas não são as únicas formas de coleta de dados. Pode-se obter boas in-
formações sobre os clientes e mercado utilizando fontes secundárias mais simples. Por exemplo, aprimorando os
procedimentos de trabalho da assistência técnica e da área de vendas, com um investimento irrisório na maioria
dos casos. Os sistemas CRM2 disponíveis vêm facilitando cada vez mais a reunião e síntese desses dados, de uma
forma muito prática e de fácil consulta.
Segundo a definição apresentada, isso é também pesquisa de mercado, na medida em que se estrutura um sis-
tema de informações para monitorá-lo. Aliás, as fontes de dados mais caras e sofisticadas precisam ser utilizadas
com cuidado e precisão. Somente quando a pesquisa é bem planejada e quando seus objetivos são realmente rele-
vantes para o planejamento de produtos é que as informações obtidas valerão cada centavo do investimento.
Com relação ao problema da inovação, a argumentação se baseia em uma afirmação correta: se o produto é
inovador, os clientes não possuem paradigmas ou experiências de consumo anterior. O problema é com a con-
clusão: portanto, não podemos “perguntar” a ele o que ele quer, Certo? Errado, porque, se a pesquisa é bem pla-
nejada, especialmente no que diz respeito ao método de coleta de dados e aos instrumentos da pesquisa, essa
dificuldade pode ser contornada. Nesses casos, o caminho não é desenhar pesquisas para perguntar o que o
cliente quer, e sim verificar os hábitos do cliente em relação à necessidade fundamental. Independentemente do
paradigma dos produtos atuais, os hábitos e as necessidades básicas são sempre possíveis de ser verificados.
Por exemplo, quando a Sony lançou o walkman, não existia produto similar.
Porém, a necessidade básica de ouvir música em diferentes lugares já existia. Com Um exemplo das reais
ou sem pesquisa de mercado, essa empresa foi hábil em identificar essa necessidade limitações da pesquisa
de mercado
e, utilizando uma inovação tecnológica, traduzi-la em um produto capaz de satis-
fazê-la. Técnicas como a coleta de dados por observação ou clínicas teriam servido
muito bem para solucionar esse fato. Logicamente, é preciso ter muito cuidado nesses casos. Naquela época, se
algum profissional que, vislumbrando a possibilidade tecnológica de projetar um produto pequeno, pergun-
tasse, utilizando uma enquete, qual o tamanho ideal de um aparelho de som, certamente ouviria algo na casa das
dezenas de centímetros. Não porque os consumidores quisessem algo desse tamanho, mas, sim, porque esse ta-
manho (grande para os padrões atuais) significaria pequeno, segundo a experiência do consumidor — muitos
deles acostumados inclusive à geração anterior de rádios com válvulas, monstruosos para os padrões atuais. Ana-
lisando de maneira simplista os dados produzidos, esse pesquisador poderia erroneamente chegar à conclusão de
que os consumidores não precisavam de um produto tão pequeno e que o walkman não “emplacaria”. O erro está
na escolha do método e no projeto do instrumento de coleta (a pergunta e formato, questionário, inadequados).
A pesquisa exigiu uma resposta que o cliente não poderia responder por desconhecer o avanço tecnológico pos-
sível ou ter experiência com a nova tecnologia. Por outro lado, caso fosse perguntado, em uma clínica, onde o
cliente gostaria de ouvir música, além da casa, certamente muitos diriam que gostariam de fazê-lo no metrô ou
durante a corrida matinal e talvez até sugerissem a existência de um aparelho de som portátil igual ao walkman.
Respondendo à pergunta inicial: é possível aplicar pesquisa de mercado mesmo
para produtos inovadores, desde que observados os devidos cuidados na escolha do Cuidados na realização das
método e preparação dos instrumentos de coleta. Os casos de insucesso geralmente pesquisas de mercado
são frutos de aplicações inadequadas das técnicas ou erros nos procedimentos de
condução da pesquisa. Consulte o Quadro 4.2 para uma visão geral de todos os problemas possíveis. Cabe,
então, aos profissionais avaliar o teor da informação a ser obtida com a pesquisa e avaliar se os métodos de coleta

2
Veja o Tópico 2.8, no Capítulo 2.
126 PARTE 2 O Modelo

disponíveis são capazes de gerar a informação com grau suficiente de confiança. Caso seja impossível ou mesmo
inviável pelo custo, é melhor não fazer a pesquisa do que utilizar procedimentos problemáticos, que, pior do que
ajudar, podem atrapalhar sugerindo direções erradas.

Quadro 4.2 Fontes de Erro em Pesquisas de Mercado

Toda pesquisa possui uma margem de erro que precisa ser controlada para que os resultados sejam efetivos. O total de
erros de uma pesquisa é formado pela influência de um conjunto de erros que precisam ser controlados. A lista a seguir
contém os erros mais freqüentes e serve como verificação.
Erros de Amostragem: são os erros cometidos durante a escolha da amostra e que a tornam não representativa. Pode
acontecer na escolha dos indivíduos, no dimensionamento ou em amostras estratificadas na definição dos estratos.
Erros de Não-Amostragem: são os demais erros que não estão ligados somente à amostragem, eles podem ser divi-
didos em:
• Erros de Projeto: são os erros de seleção, especificação da população-alvo, erros de substituição de informações (es-
colha da informação errada a ser obtida), erros de medidas (variáveis ou atributos escolhidos equivocadamente) e
erros de métodos experimentais.
• Erros de Gerenciamento: erros na aplicação dos questionários ou outros instrumentos de coleta, erros de gravação
(trocas de questionários, preenchimento errado por parte do pesquisador, troca de números etc.) e erros de interfe-
rência (alterações ou interpretações equivocadas por parte do entrevistador que o está aplicando).
• Erros de Resposta: erros intencionais ou não cometidos pelo respondente. Deve-se atentar para o fato de que ambos
podem ter como causa-raiz o projeto inadequado do instrumento de coleta de dados. No caso dos intencionais, a
causa pode ser o uso de um termo desconhecido ou que tenha outro significado para o respondente. Os intencionais
podem ser gerados por termos ou perguntas que causem constrangimento ou que contenham implicitamente algum
juízo de valor. O respondente altera a resposta para evitar o constrangimento ou garantir sua adequação a algum tipo
de crença. Pode ser causado também pela falta de confiança do respondente em relação ao uso dos dados ou cansaço
(se livrar do entrevistador).
• Erros de Não-Resposta: advêm da impossibilidade de contatar o número suficiente de consumidores segundo o pro-
jeto inicial da amostra ou por respostas incompletas ou dúbias que invalidem parte dos dados levantados.
Fonte: AAKER, D.; KUMAR, V.; DAY, G. S. Pesquisa de marketing. São Paulo: Atlas, 2001.

A pesquisa das tendências tecnológicas se assenta sobre uma base mais técnica.
Tarefa 2: Coletar Pode-se definir tecnologia como um modo peculiar de resolver um determinado
informações tecnológicas problema, utilizando um ou mais princípios físicos ou químicos. Trata-se, portanto,
de um corpo de conhecimentos para um fim prático. As tecnologias têm um ciclo de
vida, sendo criadas e substituídas tal qual os produtos. Um cuidado especial é que elas podem ser protegidas
pelas leis de propriedade intelectual. Para obterem informações tecnológicas, as empresas precisam estruturar
um procedimento de vigilância (veja o Quadro 4.3), isto é, de monitoramento da evolução das tecnologias atual-
mente utilizadas em seus produtos e das tecnologias que podem vir a substituí-las.
Um plano de vigilância deve mapear as tecnologias em uso na empresa, identi-
Obtendo informações ficar quais tecnologias estão sendo desenvolvidas em institutos de pesquisa, univer-
tecnológicas por meio da sidades e concorrentes e novas tecnologias substitutas oriundas de outros setores
vigilância tecnológica
industriais. Exemplos de tecnologias substitutas são: a tecnologia digital substituindo
a ótica nas câmeras fotográficas e o CD digital substituindo o videocassete. Moni-
torar significa não apenas saber da existência, mas também avaliar e prever o desempenho, vantagens e desvanta-
gens, e o período em que a tecnologia estará madura, pronta para ser introduzida em produtos comerciais.
CAPÍTULO 4

Planejamento Estratégico de Produtos 127

As empresas podem também utilizar o subterfúgio de criar projetos específicos


para obter análises e informações tecnológicas. A construção de carros-conceito é Obtendo informações
um exemplo clássico. Trata-se de uma estratégia utilizada na indústria automobilís- tecnológicas dos projetos
de desenvolvimento
tica para avaliar tecnologias futuras. As empresas montam carros que nunca serão
comercializados e os apresentam para o público. Esses projetos incorporam várias
tecnologias em componentes e materiais inovadoras e tendências de forma e cor. Com isso, pode-se avaliar o po-
tencial e maturidade de cada tecnologia e, ainda, com a apresentação, entender melhor a reação do público. Por
exemplo, sabe-se atualmente que os carros baseados em gasolina estão com os dias contados, e as empresas in-
vestem há décadas em pesquisas com combustíveis inovadores e é comum, em todo salão de automóvel, obser-
varmos carros-conceito com combustíveis alternativos: hidrogênio, eletricidade, mistos etc. Qualquer uma das
grandes montadoras precisa manter vigilância constante sobre as inovações nessas áreas para que possa: dominar
aspectos técnicos e já ir formando profissionais capacitados a utilizá-las, caso atinjam o ponto de maturação.

Quadro 4.3 Vigilância Tecnológica na Era da Gestão do Conhecimento

Um sistema de vigilância tecnológica é um passo fundamental para a empresa se manter atualizada e para alimentar os
sistemas de inteligência competitiva e de mercado. Ele é um sistema de informações, isto é, procedimentos e sistemas infor-
matizados, capazes de manter um monitoramento constante sobre as inovações tecnológicas e suas tendências. Ele deve
3
cumprir quatro etapas básicas:
• Estabelecimento do sistema: o primeiro passo é a definição de recursos humanos, procedimentos, equipamentos e
sistemas informatizados de forma a garantir a captação de informações tecnológicas. Montada a estrutura, é preciso
identificar as fontes de dados principais sobre a tecnologia específica: bases de dados de patentes, revistas científicas,
periódicos importantes sobre o setor, bases de dados de agências de informações, revistas e o mapeamento de com-
petências (pessoas e instituições) que trabalham com o tema.
• Coleta de dados: definido o sistema, passa-se para a coleta contínua dessas informações e a sua organização. Esses
dados precisam ser dispostos de forma a serem facilmente acessados pelos usuários da informação.
• Avaliação e análise dos dados: as informações coletadas precisam ser analisadas por especialistas das áreas de tec-
nologia e desenvolvimento de produtos. Uma prática comum é a criação de cenários a partir da contribuição de infor-
mações de diversos especialistas, empregando técnicas específicas de inteligência competitiva. Os sistemas web e o
surgimento da Gestão do Conhecimento permitem hoje que essa informação seja analisada e avaliada de maneira
compartilhada. A idéia é criar comunidades de prática, isto é, conjunto de pessoas interessadas em um determinado
assunto ou pontos específicos relacionados com a tecnologia. As informações coletadas poderiam ficar disponíveis
para esse grupo, o qual pode, então, discuti-las e trocar experiências naquele determinado tema. A empresa pode
também criar fóruns para discutir os assuntos.
• Disseminação de Informações: as discussões nas comunidades, realizadas com base nas informações continua-
mente coletadas, podem ser sumarizadas pelo moderador do grupo na forma de políticas, sugestões de ações ou
mesmo novos projetos de desenvolvimento ou de pesquisa para a organização.

Um exemplo menos radical de projetos especiais é comumente utilizado na indústria de informática. Ima-
gine uma empresa que tenha um software para gestão de escolas, contendo ensino baseado a distância. Essa em-
presa pode ser contatada para verificar a possibilidade de desenvolver uma tecnologia que permita avaliar os
alunos por meio de competências utilizando algoritmos de inteligência artificial para avaliar notas, trabalhos e
opiniões de professores e colegas. Ela poderia fazer um acordo com um determinado cliente interessado nessa
funcionalidade e desenvolver um produto sob medida, contendo-a. O cliente, nesse caso parceiro no desenvolvi-
mento, assume os riscos e por isso geralmente paga um preço inferior pelo produto. Em troca, a empresa pode
desenvolver e testar a tecnologia com um risco menor, pois parte do investimento virá da venda previamente
acertada com o cliente-parceiro. Trata-se de um tipo de projeto de produto cujo objetivo principal é o desenvol-
vimento da tecnologia e não o lucro. Se tudo der certo, a empresa possuirá ainda um caso de implantação que
poderá ser útil na promoção do produto.

3
Essas etapas foram baseadas em KOTLER (2001, p. 251).
128 PARTE 2 O Modelo

As informações devem ser utilizadas na criação de cenários futuros antevendo as


Compilando as tecnologias mais maduras e mais competitivas em termos de custo/benefício. É com
informações coletadas base nesses cenários que a empresa investirá na capacitação técnica da sua equipe téc-
nica, podendo optar por diferentes caminhos — conforme demonstra o Quadro 4.4.

Quadro 4.4 Formas de Capacitação Tecnológica (learning)

Existem vários meios de as empresas adquirirem tecnologia, comumente chamados de mecanismos de aprendizado. Os
principais são :
• Aprendizado por operação ou utilização: é o fluxo de informações tecnológicas obtidas por meio da experiência,
seja fazendo testes operando processos produtivos ou desenvolvendo produtos na área para aprender com eles. Por
exemplo, é comum que empresas de softwares aceitem desenvolver produtos novos a preço de custo, quando elas
pretendem desenvolver uma nova tecnologia que não dominam. É uma forma de a empresa custear o aprendizado
com o desenvolvimento.
• Aprendizado pela realização de mudanças organizacionais: criar mudanças específicas na estrutura organizacional
que reforcem a necessidade de desenvolvimento em alguma área. Com a introdução da eletrônica em produtos com
tecnologia puramente mecânica, como câmbios e injeção, muitas empresas criaram áreas funcionais unindo profissio-
nais que dominam o assunto como forma de incentivar os profissionais a se preocuparem com aquela determinada
tecnologia e criar um centro de competência no assunto dentro da empresa.
• Aprendizado por meio de contratos de aquisição: realização de treinamentos formais. Trata-se do oferecimento de
cursos para os profissionais. Isso é muito comum nas áreas de software e eletrônica, nas quais novas linguagens de pro-
gramação e tipos de equipamentos são constantemente atualizadas pelos fornecedores. Nesse caso, a empresa pode in-
vestir em cursos para seus profissionais de desenvolvimento como forma de acelerar a introdução dessas tecnologias.
• Aprendizado por meio de contratação: a empresa contrata pessoas com conhecimentos técnicos e experiência na
área. Deve-se tomar cuidado em relação ao uso desse tipo de instrumento de forma a evitar problemas judiciais por se-
gredos de negócio.
• Aprendizado por aquisição: a empresa busca profissionais, empresas de consultoria, institutos de pesquisa ou uni-
versidades que detenham a tecnologia e realizam contratos de aquisição — seja por meio da compra de direitos sobre
patentes ou mesmo a contratação de serviços especializados desses profissionais.
• Aprendizado por meio de Spin-Offs: uma forma de as multinacionais diminuírem os riscos de investimentos em
novas tecnologias tem sido incentivar os funcionários que tenham interesse em desenvolvê-las a montar sua própria
empresa, eventualmente, com investimento conjunto entre a empresa e o funcionário. São as chamadas empresas
Spin-offs. Nesses casos, a empresa, diminui o risco investindo menos e, caso dê certo, manterá uma parte do negócio,
facilitando uma possível reincorporação ou tornando-a um futuro fornecedor.

A empresa deve planejar a introdução paulatina das novas tecnologias nas suas linhas de produtos, minimi-
zando os riscos com o uso de tecnologias pouco conhecidas e no tempo certo, sem atrasos tecnológicos. A me-
lhor prática atualmente é evitar a introdução de um produto 100% novo, uma inovação radical. Existem outros
tipos de inovações possíveis (veja o Quadro 4.5), que podem ser utilizados para introduzir novas tecnologias
pouco a pouco. Assim, a empresa vai “aprendendo” com os produtos e, ao mesmo tempo, transmitindo uma
imagem de empresa inovadora, que atualiza constantemente seus produtos aos “olhos” dos clientes. Com esse
artifício, a empresa ainda diminui os riscos inerentes em qualquer inovação.
Um aspecto importante a ser enfatizado é que as empresas precisam saber dife-
Diferenciar produto de renciar bem produto e tecnologia. No passado, muitas empresas as confundiam e
tecnologia é fundamental um novo produto significava, no linguajar atual, produto com tecnologias novas,
para o desempenho
isto é, produtos com inovações radicais. Cada esforço de entrega de um novo pro-
eficiente do processo de
desenvolvimento de
duto gerava, então, um reprojeto inteiro do produto anterior. Essa situação pode
produtos levar a um tempo de desenvolvimento elevado, demora da empresa em responder ao
mercado, taxa menor de reúso de componentes e introdução de produtos que não
estejam em um grau de maturidade suficiente, causando vários problemas no campo. A melhor forma de atuar é
a empresa criar em seu processo de desenvolvimento uma distinção muito clara entre tecnologia e desenvolvi-
CAPÍTULO 4

Planejamento Estratégico de Produtos 129

mento de produtos. Ela deve possuir a capacidade de avaliar cuidadosamente cada tecnologia, medindo sua ro-
bustez e, portanto, sua prontidão. Cada tecnologia é aprovada por um processo formal (incluindo testes e
experimentos) antes de ser liberada para a incorporação em projetos de novos produtos. Em paralelo, a empresa
estaria continuamente lançando novos produtos no mercado, simplesmente alterando sua aparência ou mesmo
introduzindo outros tipos de inovação, tal como a incremental e arquitetural.

Quadro 4.5 Tipos de Inovação Tecnológica

A empresa pode ir acrescentando atualizações tecnológicas pouco a pouco na linha de produtos. Assim, cada produto
possuirá diferentes tipos de inovação, as quais podem ser classificadas em:
• Inovação radical: quando há inovações significativas na tecnologia dos componentes básicos (principais) ou na com-
binação dos componentes principais.
• Inovação modular: quando se faz uma inovação tecnológica grande, mas restrita, a um dos módulos específicos, sem
alterar a concepção geral do produto.
• Inovação incremental: quando não há mudanças significativas na tecnologia dos componentes e na sua combi-
nação, havendo melhorias e otimizações nas soluções de projeto já existentes.
• Inovação arquitetural: quando se faz uma inovação na forma de combinar os componentes, sem que haja evolução
na tecnologia básica deles.

Um exemplo é o caso de produtos em estágio avançado no ciclo de vida, como os de linha branca. A veloci-
dade das inovações tecnológicas radicais é pequena. As tecnologias empregadas no produto já existem há dé-
cadas e há poucos casos de inovações radicais. Apesar disso, anualmente, as empresas se esforçam para introduzir
no produto inovações incrementais, modulares e arquiteturais, processos de fabricação e componentes, visando
garantir a competitividade de seus produtos. Nos produtos em estágios iniciais de evolução, as inovações radi-
cais acontecem bem mais freqüentemente. É o caso dos celulares e computadores do tipo tablet PC ou da TV di-
gital. Nos últimos anos, vêm sendo lançados produtos com inovações radicais em termos de padrões. Cada novo
padrão traz um salto tecnológico, multiplicando o desempenho dos produtos.
A atividade de coleta de informações, conforme definido neste capítulo, pode ser
desempenhada por diferentes áreas funcionais da empresa, muitas vezes contando com Papéis e responsabilidades
o apoio ou serviços prestados por outras empresas e consultores. Por exemplo, a vigi- pela atividade de
consolidar informações
lância tecnológica pode ficar a cargo da área de engenharia. O monitoramento e o ar-
mazenamento das informações de mercado podem ficar a cargo de marketing. A
responsabilidade por organizar os dados muitas vezes é delegada ao papel de gerente funcional. Em grandes em-
presas, é comum a opção por construir e manter uma área funcional específica para esse fim, um setor de informações
ou vigilância competitiva, nos quais existam profissionais da área de ciência da informação dedicados a essa tarefa.
No extremo, a empresa poderia criar um processo multifuncional e estruturado denominado monitorar o
mercado, conforme discutido no Capítulo 1. Dessa forma seria criado um fluxo para que todas as informações
fossem coletadas e reunidas nas diversas áreas funcionais para que pudessem ser sintetizadas e colocadas à dispo-
sição das pessoas envolvidas nessa e em outras atividades da empresa.
No caso do nosso modelo, consideramos que o papel do Time de Planejamento é ir atrás dessas informações,
independentemente de como tenham sido coletadas. Eles podem ainda decidir complementá-las com fontes de
dados primárias e secundárias, conforme sentirem necessidades e as oportunidades sejam identificadas.
Com base nas informações coletadas, o Time de Planejamento Estratégico de
Produtos poderá criar os cenários atual e futuro de tendências tecnológicas e de mer- Tarefa 3: Criar cenários e
análises sintetizando as
cado. Esses cenários e análises são sínteses das diversas informações e balizarão as de-
informações
cisões sobre o portfólio de produtos. Precisam ser claros e terem sido fruto de um
consenso do grupo. São também confidenciais, pois deixam evidente a estratégia da
empresa, portanto, eles deverão ser restritos a esse time e à alta administração.
130 PARTE 2 O Modelo

A gestão do conhecimento
Um aspecto novo e importante em relação a esse tema é que o fluxo de informa-
deve ser cada vez mais ções não é de uma via apenas e não deve se restringir ao Time de Planejamento Estra-
presente nessa atividade tégico de Produtos e aos gerentes funcionais. Dentro do conceito de gestão do
conhecimento apresentado no Capítulo 2, a meta é disponibilizar os conhecimentos
dos diversos colaboradores para todos os profissionais da empresa. Assim, deve-se criar mecanismos para que os
diversos profissionais possam discutir e trocar informações complementares sobre esses assuntos; um exemplo é a
utilização de grupos de discussão e comunidades de prática (consulte o Quadro 4.6). Fazendo isso, o Time de Pla-
nejamento Estratégico de Produtos poderá obter contribuições de todos os profissionais, aumentando a qualidade
dos cenários, análises e decisões. Ao mesmo tempo, ao divulgarem parte das informações, estarão contribuindo
para a capacitação e aumento do nível de conhecimento de todos os envolvidos no processo de desenvolvimento.

Quadro 4.6 Comunidades de Prática no PDP

A constituição de comunidades de prática é um poderoso recurso para as empresas interessadas em captar informações
tecnológicas e mercadológicas. Conforme apresentado no Capítulo2, uma comunidade é um grupo de pessoas que realizam
uma mesma função ou têm um mesmo interesse. Elas se unem para discutir determinados assuntos. A empresa pode incen-
tivar a criação de comunidades para discutirem aspectos de diferentes tecnologias ou assuntos relacionados. Elas trocam expe-
riências e informações, sendo uma importante fonte para a atualização tecnológica e obtenção de novas idéias de produtos.
Por exemplo, comunidades de prática com todos os vendedores e pessoal de assistência técnica estão sendo constituídas
nas empresas, para que os profissionais possam compartilhar melhores práticas e informações prévias dos clientes. Com os
devidos cuidados, seria possível aproveitar essa comunidade para solicitar informações sobre o mercado ou discutir com
eles tendências para os novos produtos. O registro adequado das discussões da comunidade pode ser de alto valor para os
responsáveis pela análise do Plano Estratégico da Empresa. Outro exemplo, podem ser criadas comunidades de especia-
listas em determinadas tecnologias de forma que, em vez de contratar a peso de ouro um especialista externo para descobrir
as tendências na área de ótica, o Time de Planejamento Estratégico de Produtos poderia consultar a comunidade inteira. Se-
ria possível pedir para que eles discutissem o tema em um fórum e depois criassem um sumário da discussão para alimentar
os cenários de tendências tecnológicas e de produtos.
As comunidades podem auxiliar em outros aspectos do processo de desenvolvimento de produtos. Por exemplo, pre-
cisa-se de um especialista em lentes para compor um determinado time de desenvolvimento de produtos? Por que, então,
não procurar esse especialista em uma das comunidades de prática sobre ótica, a qual poderia conter, além das pessoas da
empresa, profissionais de empresas parceiras e de instituições como universidades e centros de pesquisa? Isso sem falar na
mais imediata das implicações. Em vez de a empresa investir milhões anualmente em cursos de reciclagem para todos os
funcionários, que tal a existência de uma comunidade em que eles se mantivessem em contínuo aprendizado, diminuindo a
necessidade desses cursos e garantindo uma alta preparação dos colaboradores em momentos de tomadas de decisão?
As possibilidades nesse sentido são grandes e tentadoras, mas será preciso enfrentar desafios novos. Diferentemente de ou-
tras áreas, nas quais o tão famoso “comprometimento da alta administração” é capaz de garantir um mínimo de resultados, não
se pode criar uma comunidade “unilateralmente”, de cima para baixo, empregando as estruturas funcionais clássicas.
Eis um conjunto de diretrizes visando esse objetivo:
• Estabeleça um grupo inicial que se conheça e respeite profissionalmente e, de preferência, tenha bons relaciona-
mentos pessoais anteriores.
• No caso de uma empresa ou grupo de trabalho, estabeleça um objetivo que possa unir o grupo e que tenha o potencial
de fazê-los realizar tarefas conjuntas.
• Encontre formas de fazer com que o grupo defina suas próprias regras de convivência e de valores, como criando um
código de ética.
• Mais que evitar problemas, esteja preparado para solucioná-los de maneira transparente e democrática.
• Faça dos problemas uma oportunidade para a discussão e aprimoramento do consenso sobre as formas de conduta
dentro da comunidade.
• Utilize as ferramentas computacionais de maneira consciente, aproveitando o seu potencial de apoio nas atividades e
de “marketing” na cooperação.
• Cultive a confiança dos membros a cada dia, todos os dias, com ações de esclarecimento e por meio de atividades coo-
perativas e programas de intercâmbio.
Fonte: AMARAL, D. C.; MOSCONI, E. P.; ROZENFELD, H. “Cultivando confiança: o dia-a-dia de uma comunidade de prática em desenvolvi-
mento de produtos.” In: TERRA, J. C. Gestão do conhecimento e e-Learning na prática: 39 casos. Rio de Janeiro: Elsevier, 2003.
CAPÍTULO 4

Planejamento Estratégico de Produtos 131

4.5 Revisar o PEN


A revisão do Plano Estratégico de Negócios é realizada pelo Time de Planejamento Estratégico de Pro-
dutos, por meio de reuniões de trabalho, seguindo o calendário e agendas previstos na etapa de planejamento,
Tópico 4.3, e os cenários e informações sistematizados na atividade do Tópico 4.4; conforme ilustra a Figura 4.6.
Serão uma ou mais reuniões nas quais a equipe discutirá o Plano Estratégico de Negócios até que exista um con-
senso sobre esse documento. As saídas dessa atividade são recomendações e observações sobre o Plano Estraté-
gico definido.

Figura 4.7 Resumo da atividade “Revisar o Plano Estratégico de Negócios –(PEN)”.

As tarefas principais que precisam ser realizadas pelo time são explicadas nos tópicos que se seguem. O nível
de profundidade e o tempo dedicado em cada um deles variam conforme escopo da revisão de fases, preparado
ao final da atividade do Tópico 4.2, e os resultados das atividades anteriores.

n Revisar missão: o Time de Planejamento Estratégico de Produtos precisa inicialmente ter ciência e cla-
reza sobre a missão da organização. Essa missão é definida no Planejamento Estratégico da Unidade de
Negócios e normalmente não precisará ser discutida, pois deverá ser bastante evidente e clara para todos
os profissionais da empresa. Deverá ser objeto de análise apenas em casos especiais, uma vez questionada
por algum membro da comissão ou recentemente adotada pela corporação.
n Revisar segmentação do mercado: deve-se analisar detalhadamente a divisão de segmentos de mercado pro-
posta no Plano Estratégico de Negócios, mas com o foco no segmento para o qual está sendo realizada.
A delimitação adequada dos segmentos de mercado é vital para a qualidade de qualquer planejamento
estratégico. Um segmento significa um conjunto de consumidores com características de consumo si-
milares. Quanto melhor essa delimitação, mais coeso será o público-alvo de cada projeto, e isso afetará
todo o desenvolvimento dos produtos. Um exemplo, quanto mais coeso, mais fácil será realizar a ativi-
dade de levantamento de requisitos na fase de projeto informacional.
132 PARTE 2 O Modelo

n Revisar posicionamento no mercado: isso significa analisar os cenários que foram desenvolvidos na atividade
anterior, para identificar a posição da empresa diante da concorrência. Essa posição deve ser vista tanto do
ponto de vista de mercado, participação, mas também em termos da linha de produtos. O Plano Estraté-
gico de Negócios deve identificar claramente qual a percepção dos clientes quanto à linha de produtos da
empresa, quais são os aspectos fortes e fracos e, principalmente, quais os diferenciais competitivos tanto
dos produtos da empresa quanto dos concorrentes. Ao final da revisão, mudanças podem ser propostas.
n Revisar tendências tecnológicas: da mesma forma que a anterior, essa tarefa compreende a análise dos cená-
rios ali consolidados. Aqui o importante é entender quais as tecnologias que devem predominar no de-
correr do horizonte de planejamento. Além das tecnologias, deve-se atentar para as metas de
desempenho dos produtos. Por exemplo, emissão de gases tóxicos, quantidade de rejeitos, velocidade e
certos parâmetros fundamentais de desempenho muitas vezes precisam ser monitorados, pois são metas
que deverão estar contidas na definição de novos projetos a ser realizada nas próximas atividades do mo-
delo — seja pela evolução da concorrência ou por exigências de instituições normalizadoras ou governa-
mentais. Mapas com a evolução desses parâmetros devem estar contidos no Plano Estratégico de
Negócios e, nessa tarefa, são analisados com cautela pelo Time de Planejamento Estratégico, que po-
derá identificar necessidades de análises complementares ou apontar erros nas análises realizadas.
n Revisar o direcionamento estratégico da Unidade de Negócio (UN): se as análises anteriores forem realizadas
com êxito, o time estará consciente das tendências tecnológicas e de mercado e poderá entender clara-
mente a motivação da estratégia estabelecida para a unidade de negócio, expressa no direcionamento es-
tratégico. Ele é a diretriz que resume a metas da UN e o meio que deverá ser utilizado para atingi-la.
Para um exemplo simples, imagine uma unidade de negócio de desenvolvimento de produtos para co-
lheitas agrícolas que poderia ter traçado a meta de aumentar em 10% sua participação no mercado de
equipamentos para soja por meio do desenvolvimento de novos produtos para o plantio. Essa infor-
mação guiará a proposição do novo portfólio de projetos, que deverá, então, conter novos projetos de
equipamentos para o plantio de soja. Portanto, compreender perfeitamente o que a alta direção deseja
para a UN é o passo central e vital para a definição da estratégia de produtos, a qual deverá acontecer nas
próximas atividades.
n Revisar competências: com os cenários de tendências de mercado e tecnológicos e a definição do direcio-
namento estratégico, deve-se começar a analisar a capacidade de a empresa em implementá-las. O pri-
meiro passo é verificar se a empresa possui pessoas com as competências necessárias para enfrentar os
desafios de mercado e trabalhar com as novas tecnologias que deverão ser utilizadas segundo as tendên-
cias observadas. Avaliando a situação da empresa nesse quesito, é possível antecipar ações de capaci-
tação, seja com projetos, treinamento ou aquisição de profissionais do mercado, visando suprir as
lacunas existentes.
n Revisar recursos necessários: idem à atividade anterior, mas a análise agora é quanto aos recursos físicos e
monetários. Um exemplo de recursos físicos é o caso de uma empresa do ramo de máquinas que decide
introduzir uma nova tecnologia baseada em eletrônica e precisará de um laboratório para desenvolver e
produzir placas de circuito impresso e softwares. Isso precisa ser previsto no plano. A situação dos re-
cursos financeiros previstos também é importante e precisa ser revista com cuidado.
n Revisar metas: ao final de todas as análises, o Time de Planejamento Estratégico de Produtos poderá re-
visar as metas para a UN estipuladas pela alta direção da empresa. Possíveis discordâncias teriam que ser
levadas para uma discussão superior.
n Preparar documento sobre resultados da revisão do PEN: o resultado das discussões realizadas nesta fase
serão dúvidas, sugestões e novas interpretações dos dados contidos no plano. Tais informações devem
ser planejadas e serão úteis nas próximas atividades. Inclusive, várias idéias para novos projetos já devem ter
surgido no decorrer dessas análises e, nesse caso, é fundamental que elas sejam cuidadosamente compi-
ladas para ser aproveitadas nas próximas atividades.
CAPÍTULO 4

Planejamento Estratégico de Produtos 133

4.6 Analisar o portfólio de produtos da empresa


Uma vez realizadas as atividades anteriores, o Time de Planejamento Estratégico de Produtos estará pronto pa-
ra iniciar o estudo do portfólio de produtos da empresa, atividade que é representada esquematicamente na Figura 4.8.
O portfólio de produtos é a “carteira” de projetos de desenvolvimento que a empresa oferece, isto é, o conjunto de
produtos que a empresa está desenvolvendo ou que comercializa. Nessa atividade, o Time de Planejamento Estraté-
gico de Produtos deverá avaliá-lo com vistas a obter sugestões (idéias) de mudanças e possíveis novos produtos.

Figura 4.8 Resumo da atividade “Analisar portfólio de produtos da empresa”.

Cada produto ou novo projeto pode ser visto como um negócio que visa obter
resultados para a empresa, que, em geral são: obter lucro, atender a quesitos especí- Cada projeto de novo
ficos da estratégia ou obter algum aprendizado. Um projeto pode buscar atender produto é um novo
negócio
todos esses objetivos ou ter um deles como prioritário. Outra característica que pre-
cisa ser notada é o fato de todo projeto possuir um risco associado. Como todo pla-
nejamento, o Plano Estratégico de Produtos é uma previsão, no popular “um chute”, que pode ou não a vir se
concretizar. Os riscos inerentes a cada projeto podem ser maiores ou menores, dependendo da natureza do pro-
jeto. O importante é que a empresa aprimore seu processo de forma a aprimorar seu embasamento no momento
da previsão, permitindo-lhe aprimorar cada vez mais esse “chute”.
Visto isso, é fácil perceber por que a análise desse conjunto é fundamental para
a sobrevivência da empresa. Ao definir o portfólio de produtos, o Time de Planeja- O que é o gerenciamento
mento Estratégico de Produtos estará assumindo um determinado nível de risco e de portfólio?
definindo o futuro da linha de produtos da empresa, algo fundamental para a sua so-
brevivência. Uma escolha bem-feita significa que a empresa terá um conjunto de projetos que resultem em uma
linha de produtos capaz de atender às necessidades dos clientes-alvo, conforme previsto na estratégia de negó-
cios, com o menor nível de risco possível e a maior lucratividade. O menor risco significa que, mesmo que alguns
dos projetos dêem errado, o resultado final não será comprometido.
Escolher projetos ruins afastará o conjunto de projetos de um desses objetivos básicos e, mesmo que eles
sejam bem-feitos e que tudo dê certo, a empresa não terá êxito no mercado. Exemplo: pode-se ter um conjunto
de projetos que leve a produtos de alta rentabilidade, mas que esteja atacando necessidades não previstas na es-
tratégia. Nesse caso, pode-se comprometer a sobrevivência futura da empresa. É possível, ainda, optar por um
portfólio de produtos de alta rentabilidade e voltado para a estratégia, mas com projetos predominantemente de
alto risco. Isso também pode comprometer o futuro da empresa, dado que existirá uma chance alta dos projetos
134 PARTE 2 O Modelo

falharem. Por fim, pode ser que o risco seja baixo e que os produtos sejam alinhados com a estratégia, mas, se a
rentabilidade dos projetos é baixa, a saúde financeira da empresa no curto prazo poderá ser comprometida, le-
vando-a à bancarrota antes dos lucros chegarem.
O Quadro 4.7 possui uma definição formal do que é a gestão de portfólio e seus objetivos. Similar a um acio-
nista que investe em uma carteira ou portfólio de ações, o objetivo principal do Time de Planejamento Estratégico
de Produtos deve ser escolher os projetos a serem desenvolvidos e produtos que devem permanecer no mercado.

Quadro 4.7 Gestão de Portfólio

A gestão do portfólio ou da carteira de projetos é um processo estruturado de decisão sobre quais projetos devem ou
não ser desenvolvidos dentro da organização. Esse processo deve ser bem formalizado dentro da empresa e envolve ativi-
dades de avaliação dos projetos e produtos existentes, identificação de novas idéias, priorização e escolha. Seu resultado é
uma decisão sobre cada projeto ou produto da empresa, envolvendo um dos cinco tipos básicos de escolha:
• Criar novo projeto.
• Aprovar o projeto em desenvolvimento, na forma como está atualmente.
• Redirecionar um projeto. É o caso no qual o projeto será mantido com a condição de que haja um conjunto específico
de modificações no escopo.
• Congelar um projeto. É a alternativa de suspender o projeto até que ele possa ser retomado no futuro, do ponto em
que se encontra.
• Cancelar um projeto. É a alternativa de abandonar ou matar um projeto. Normalmente, dada a cultura das empresas e
da sociedade, essa alternativa é evitada ao máximo dentro das organizações. Tanto o Time de Planejamento Estraté-
gico de Produtos como o Time de Desenvolvimento procuram evitar o sentimento de fracasso que acompanha tal de-
cisão. Com isso, muitos projetos sabidamente problemáticos acabam sendo mantidos. E, para evitar um prejuízo
menor, acaba-se criando um prejuízo muitas vezes maior no futuro. A verdade é que a atitude de cancelar um projeto
precisa ser considerada como algo normal, inerente às incertezas ligadas a esse processo de negócio, desde que ela
aconteça nas fases iniciais do processo de desenvolvimento de produtos e causada por motivos que não poderiam ter
sido previstos anteriormente.
Deve-se notar que as quatro últimas escolhas são idênticas aos tipos de decisão que acontecem na atividade genérica de
aprovar a fase. Isso não ocorre por acaso, pois, ao se revisar o portfólio de projetos da empresa, os tipos de decisão são idên-
ticos aos de aprovação de fase, com exceção da adicional de criar novo projeto.
Tais escolhas devem ser feitas de maneira que o conjunto final de projetos e produtos satisfaça os três objetivos básicos
da gestão de portfólio:
• Maximizar o retorno financeiro: o conjunto de projetos deve trazer a maior rentabilidade possível para a empresa. Os
investimentos realizados em todos os projetos deverão ser superados com grande vantagem pelos retornos a serem pro-
duzidos. Trata-se de um critério fundamental, mas, se tomado isoladamente, pode levar a empresa a prejuízos no longo
prazo. Isso é particularmente verdadeiro para o desenvolvimento de novos produtos, pois, para a maioria das empresas,
os projetos mais lucrativos são os que se baseiam em continuação de produtos vencedores no mercado e/ou que uti-
lizam tecnologias consagradas pela empresa. Portanto, se esse for o único critério utilizado pelo Time de Planejamento
Estratégico de Produtos, a empresa corre o risco de realizar somente projetos desse tipo, comprometendo seu futuro.
• Alinhar com a estratégia da empresa: este critério é o grau com que tais projetos se alinham com as metas estraté-
gicas da empresa. Por exemplo, se a meta da empresa é competir com diferenciação em custo, voltadas para a Classe C,
o conjunto de projetos do portfólio deve permitir que a empresa constitua uma linha de produtos com tal diferenciação.
Se há projetos de produtos sofisticados, com muitas funções e tecnologias inovadoras, é sinal de que essa carteira de
projetos não está alinhada com a estratégia da empresa.
• Balancear o portfólio de projetos: os dois critérios anteriores são capazes de atender à missão da organização: ter
lucro por meio de uma determinada estratégia. Mas avaliar os projetos utilizando apenas os dois critérios anteriores
pode levar ao erro de não se considerar o nível de risco da carteira de projetos. Esse nível de risco deve ser o menor pos-
sível, e eis aí algo que pode ser obtido combinando projetos altamente inovadores, capazes de manter a sobrevivência
da empresa no longo prazo, com projetos de menor risco e alta lucratividade, destinados a manter a posição da empre-
sa no mercado. Portanto, balancear o portfólio é manter uma proporção adequada de inovação, risco e lucratividade,
atendendo, além da estratégia da empresa, às realidades de curto e longo prazos do mercado.
Informações adicionais podem ser obtidas em: COOPER, R. G; EDGETT, S. J.; KLEINSCHMIDT, E. J. Portfolio management for new pro-
ducts. Massachussets: Perseus Book, 1998.
CAPÍTULO 4

Planejamento Estratégico de Produtos 135

Há um conjunto de técnicas para se analisar uma carteira de projetos. Elas são similares às utilizadas na aná-
lise de mercados, segmentação em unidades de negócio e até mesmo na análise de carteiras de ações. Elas podem
ser divididas em três tipos básicos, conforme apresentado no Quadro 4.8.

Quadro 4.8 Técnicas para Avaliação do Portfólio de Produtos

As técnicas para gestão de portfólio podem ser divididas em três grupos distintos:
Análise do Valor Comercial Esperado: é a avaliação por meio de modelos de matemática financeira, considerando in-
vestimento, retorno e riscos. Esses modelos utilizam os índices de avaliação financeira, tais como: Valor Presente Líquido,
Taxa Interna de Retorno e outros para medir qual a média (esperança) de retorno financeiro de cada projeto. O resultado é
comparado e pode-se priorizar os projetos com melhor retorno. Um exemplo simples é a obtenção do Valor Econômico
Esperado por meio de um modelo de árvore de decisão, unindo os índices financeiros com um pouco de probabilidade, con-
forme a Figura 4.9.

Figura 4.9 Valor econômico esperado.

Cada projeto foi dividido em duas grandes fases, denominadas, respectivamente, de Desenvolvimento e Lançamento.
Obtém-se o valor gasto em cada uma delas para cada projeto: Custo do Desenvolvimento ($D) e Custo do Lançamento ($L).
O time fará uma avaliação técnica para determinar a Probabilidade de Sucesso Técnico (Pts) e Comercial (Pcs). Deve-se cal-
cular também o Valor Presente das receitas previstas no projeto (VPR). Com essas informações, é possível, então, calcular o
Valor Esperado (ECV) de cada projeto, que, nesse caso, será dado pela seguinte fórmula:
ECV = (VPR x Pcs – L) x Pts – D
No linguajar estatístico, esse valor significa que, se esse projeto fosse executado repetidas vezes, tendendo ao infinito, e
se fossem calculados os resultados financeiros, a média dos valores econômicos obtidos seria igual ao ECV. Portanto, trata-se
de uma medida que combina Retorno Financeiro e Risco, de forma que quanto maior esse valor, melhor o projeto.
Modelos Baseados em Notas (Score): são os modelos que utilizam um conjunto de critérios predefinidos e baseados em
notas para avaliar os projetos. O primeiro passo é a definição dos critérios, tais como: facilidade de implementação, partici-
pação no mercado, dificuldade técnica, nível de risco etc. Cada um dos critérios é definido, incluindo uma escala qualitativa
ou um índice quantitativo que serão utilizados para medir cada projeto. Os critérios são priorizados e aplicados para avaliar
cada projeto. O próprio grupo responsável pela decisão pode avaliá-los. Em alguns casos, especialistas podem ser consul-
tados para avaliar um ou mais critérios. Os resultados podem ser utilizados para criar índices compostos, com pesos ade-
quados para cada um dos critérios, que fornecem a informação dos projetos que devem ser priorizados. A eficácia na
utilização desses modelos depende totalmente da escolha adequada dos critérios e pesos e da sistemática de condução das
reuniões e obtenção das avaliações. Caso alguns aspectos não sejam considerados ou os critérios sejam definidos inadequa-
damente, prejudica-se a qualidade da decisão. A condução das discussões é uma tarefa que precisa ser realizada de forma
transparente e com a contribuição de todos. Deve-se criar um procedimento que impeça que uma ou mais pessoas, de per-
sonalidade mais forte, dominem o debate e influenciem a resposta de todo o grupo.
Um exemplo de Modelo de Notas é apresentado nas figuras 4.10a e 4.10b. A primeira tabela é uma forma de dar pesos aos
critérios, partindo-se de uma análise sistemática. O exemplo mostra três critérios para projetos de famílias de redutores. No

(continua)
136 PARTE 2 O Modelo

Quadro 4.8 Técnicas para Avaliação do Portfólio de Produtos (continuação)

caso, a estratégia da empresa é a de obter uma linha de produtos voltada para um nicho específico do mercado específico,
que forneça para o cliente o menor custo de operação e que permita a criação de extensões futuras para outros segmentos
de mercado. Portanto, os três critérios apresentados estão relacionados com a estratégia e são qualitativos. Trata-se de um
exemplo didático, pois, na prática, deveriam ser considerados também critérios de risco e de retorno financeiros, podendo
ser quantitativos. Feita a lista de critérios, eles são dispostos em uma matriz relacionando-os entre si. O Time de Planeja-
mento Estratégico de Produtos se reúne e, por meio da Tabela da Figura 4.10a, compara cada critério contra todos os demais,
identificando qual é o mais importante e anotando os pontos conforme a legenda da figura. A soma dos pontos, se relativi-
zada, oferece um valor de peso para cada critério. Os critérios alimentam as matrizes para avaliação dos projetos, como
exemplificado na Figura 4.10b. No exemplo, pode-se ver a avaliação do projeto da Família LGB. Cada um dos membros do
time avaliou o projeto segundo os critérios. Por fim, o valor obtido para esse projeto é comparado com os demais projetos do
portfólio na Figura 4.10c.

Figura 4.10 Exemplo de modelo de notas.

Modelos de Gráficos de Bolhas: os Gráficos de Bolha são gráficos que possuem três dimensões (dois eixos e o diâmetro
dos pontos) e se caracterizam por separar o espaço em quadrantes. Avaliar portfólio utilizando Gráficos de Bolhas significa
desenhar o gráfico para o conjunto de projetos da empresa. O significado dos eixos e do raio da circunferência pode variar de
acordo com a necessidade dos avaliadores. Os eixos geralmente representam o retorno financeiro e a probabilidade de su-
cesso técnico, e o raio significa a quantidade de investimento necessária para o projeto, conforme exemplificado na Figura
4.11, para uma empresa hipotética que desenha e produz caminhões.

(continua)
CAPÍTULO 4

Planejamento Estratégico de Produtos 137

Quadro 4.8 Técnicas para Avaliação do Portfólio de Produtos (continuação)

Figura 4.11 Exemplo de modelo de avaliação de portfólio utilizando Gráfico de Bolhas.

A grande vantagem dessa técnica de avaliação de portfólio é que esses gráficos apresentam, de uma forma sintética e
simples, várias informações relevantes. Outro aspecto é que os quadrantes têm um significado bem claro para o Time de Pla-
nejamento Estratégico de Produtos, conforme os eixos escolhidos. Por isso, geralmente atribuem-se nomes a esses qua-
drantes como forma de classificar os tipos de projeto. No caso do exemplo, o quadrante superior da esquerda foi chamado
de Pérolas, porque une os melhores projetos, aqueles que possuem alto retorno financeiro e alta probabilidade de sucesso
técnico. Os da direita foram chamados de pão com manteiga porque contêm os projetos com baixo retorno financeiro,
porém, com pouco risco. Geralmente, enquadram-se nessa categoria os projetos de mudança incremental nos produtos
vencedores da empresa, isto é, produtos que são bem avaliados no mercado. As ostras são os projetos que, se bem cuidados,
isto é, se os riscos forem diminuídos, podem se transformar em pérolas. Faz parte desse grupo os projetos que possuem alto
retorno, mas a probabilidade de sucesso é baixa. Por fim, os elefantes brancos que são projetos com baixo retorno e alto
risco, mas que podem trazer benefícios para estratégia ou para o marketing da empresa, conforme está exemplificado no
projeto do caminhão ecológico. Um portfólio de produtos bem balanceado deve conter projetos nos vários quadrantes, ga-
rantindo-se a combinação de inovação e exploração máxima do potencial dos projetos já existentes. A vantagem desse mo-
delo de avaliação é que ele permite balancear facilmente o portfólio.
Fonte: COOPER, R. G.; EDGETT, S. J.; KLEINSCHMIDT, E. J. Portfolio management for new products. Massachussets: Perseus Books, 1998.

Do quadro contendo as técnicas para avaliação do portfólio é possível verificar que cada um desses três
tipos básicos possui vantagens e desvantagens quanto ao atendimento dos objetivos principais da gestão de port-
fólio. É fácil perceber que a Análise do Valor Econômico Esperado é uma ótima técnica para identificar os pro-
jetos que maximizam o retorno financeiro, mas é inadequada para apontar quais deles se alinham com a
estratégia da empresa. Já o Gráfico de Bolhas é ótimo para balancear os projetos e ruim para alinhar com a estra-
tégia. O Modelo de Notas é mais flexível e possui a desvantagem de ser mais suscetível a erros de interpretação.
O fato é que cada um dos modelos permite analisar com mais ou menos propriedade cada um dos objetivos
básicos da gestão de portfólio e, portanto, a situação ideal é combiná-los de forma a obter o máximo de cada um,
visando a melhor decisão. Uma comparação dos três tipos básicos de técnicas para gestão de portfólio é apresen-
tada no Quadro 4.9.
138 PARTE 2 O Modelo

Quadro 4.9 Comparando as Técnicas para a Avaliação de Portfólio

A Figura 4.12, a seguir, apresenta uma comparação didática entre os métodos para a avaliação do portfólio com os obje-
tivos básicos dessa análise. O Valor Comercial Esperado é mais eficaz na comparação da maximização do valor. Ele auxilia no
balanceamento porque considera o risco dos projetos, mas é totalmente ineficaz quando a meta é alinhar com a estratégia
da empresa. O Gráfico de Bolhas é o mais eficaz no balanceamento do portfólio, auxilia no alinhamento estratégico, mas não
contribui de maneira eficaz para priorização da maximização do valor. Já o Modelo de Notas pode ser utilizado para adequar
os projetos aos três objetivos, bastando, para isso, considerar critérios para cada um deles. O problema é que ele é menos efi-
ciente que os demais em objetivos específicos, pois sua implantação está sujeita a uma série de vieses conforme são esco-
lhidos os critérios e seus pesos.

Figura 4.12 Comparação dos métodos para análise e avaliação do portfólio de projetos.

O ideal é que a empresa adapte esses diferentes índices e técnicas criando uma metodologia própria de avaliação de port-
fólio, na qual as diferentes metodologias se complementem e se fundem. Por exemplo, pode-se adicionar um índice de um
Modelo de Notas em um Gráfico de Bolhas, o Valor Econômico Esperado como um critério do Modelo de Notas e assim por
diante.

Agora que pudemos conhecer melhor o que é a gestão de portfólio e as técnicas


Tarefa 1: Revisar/Definir que podem ser utilizadas, fica mais fácil entender as tarefas que compõem a ativi-
o método de avaliação dade de avaliar o portfólio de projetos. Nessa atividade, basicamente, o Time de
de portfólios
Planejamento Estratégico de Produtos deverá revisar a metodologia de avaliação do
portfólio, isto é, definir os modelos a serem utilizados, critérios específicos e escalas.
O grupo deve definir também a dinâmica a ser empregada nas reuniões em que houver trabalho coletivo, como
na escolha dos critérios e definição de pesos.
Definidos os critérios para a avaliação do portfólio de produtos, deve-se dar
Tarefa 2: Avaliar o início à avaliação dos projetos em andamento e produtos existentes quanto aos cri-
posicionamento dos térios propostos no modelo de avaliação. Essas informações podem ser compiladas
produtos
em uma única planilha ou qualquer outro software específico para essa função.
No caso dos produtos que já estão no mercado, as informações sobre o seu de-
Tarefa 3: Avaliar o sempenho diante da concorrência são essenciais e devem ser coletadas e sinteti-
desempenho dos zadas. Elas serão transmitidas ao Time de Planejamento Estratégico de Produtos e
produtos
servem de apoio ao processo de decisão. Portanto, essa é mais uma tarefa que deve
acontecer nessa etapa.
CAPÍTULO 4

Planejamento Estratégico de Produtos 139

Uma análise importante é com relação às tecnologias básicas adotadas pela em-
presa e os concorrentes, sem se esquecer de avaliar as plataformas de produto. É Tarefa 4: Avaliar
fundamental identificar quais são as plataformas existentes e as variações, pois isso tecnologias e plataformas
utilizadas
traz uma enorme economia de investimentos no desenvolvimento de produtos e
reutilização. Mais tarde, na macrofase de desenvolvimento, ficará clara a definição
4
de plataformas e a importância de seu planejamento.
Idéias para novos projetos de desenvolvimento são continuamente geradas
dentro da organização. Por exemplo, os colaboradores da força de venda costumam Tarefa 5: Compilar idéias
ter boas idéias ou as coletam de seus clientes. Engenheiros e especialistas das áreas de novos produtos
de desenvolvimento de produtos, além de novos produtos, podem identificar novas
tecnologias potenciais. Possuir uma sistemática para coletar essas idéias é fundamental. A empresa pode adicio-
nar um campo no formulário de visita ao cliente ou até mesmo oferecer certos tipos de recompensa por idéias
que se transformam em produtos. O resultado será uma lista de propostas de novos projetos que deverá também
ser fornecida ao Time de Planejamento Estratégico de Produtos. Se há uma planilha automatizada com os crité-
rios e gráficos para análise do portfólio, cada um dos projetos potenciais poderia já ser cadastrado para manter
um histórico das idéias. Afinal, pode ser que uma das idéias propostas não seja interessante no momento atual da
avaliação do portfólio e, no futuro, ser “ressuscitada” ou servir como estímulo para uma nova idéia.
São iniciadas as reuniões de trabalho do Time de Análise Estratégica dos Pro-
dutos. O primeiro item da agenda será analisar as informações coletadas sobre os pro- Tarefa 6: Analisar projetos
dutos atuais entregues no mercado, plataformas e tecnologias e complementar a lista de segundo critérios de
análise do portfólio
idéias de novos projetos. Caso existam muitas propostas, o time poderá realizar um pri-
meiro filtro, eliminando aquelas sabidamente inviáveis técnica ou economicamente.
Outro ponto importante é avaliar as plataformas e tecnologias utilizadas. Uma plataforma é um conjunto
de elementos e subsistemas comum a um conjunto de projetos. Esse compartilhamento reduz custos e riscos do
projeto. Ele ajuda também na assistência técnica e apoio ao cliente (o tópico a seguir contém uma breve des-
crição desse problema). Portanto, é preciso avaliar quais são as plataformas existentes.
Depois de definida a lista de projetos que devem ser considerados, cada um deles será avaliado segundo os
critérios propostos no modelo de avaliação do portfólio de projetos. Isso significa dar notas ou realizar previsões
como cálculo do Valor Econômico Esperado. Ao final dessa tarefa, o time estará finalizando a atividade de Aná-
lise do Portfólio de Produtos da Empresa, e o Time de Planejamento Estratégico de Produtos estará ponto para
tomar a decisão de quais projetos e produtos ficam, saem ou são adicionados.

4.7 Propor mudanças no portfólio de produtos


Com os resultados das avaliações de todos os projetos em mãos, o Time de Planejamento Estratégico de
Produtos poderá dar início à definição do portfólio de produtos futuro da empresa, isto é, realizar a decisão
de quais produtos serão desenvolvidos e mantidos no mercado. Essa atividade é representada esquematicamente
pela Figura 4.13, sendo as informações de entrada o Portfólio de Produtos e a lista de idéias. Logicamente, todas
as análises e cenários criados na atividade do Tópico 4.4 poderão ser extremamente úteis. O resultado final dessa
atividade é o novo portfólio de produtos da empresa. Do conjunto de idéias de novos produtos compilados,
parte será eliminada nessa fase. A palavra eliminada não significa necessariamente deixar de constar na planilha
ou no sistema utilizado para gerenciar o portfólio. Como o histórico das decisões é importante para o aprendi-
zado futuro, os projetos rejeitados devem ser armazenados para futuras consultas.
Um aspecto fundamental nessa escolha e que vai além dos critérios de avaliação
do portfólio de produtos, apresentado no tópico anterior, é o aspecto da diferenciação A importância do valor e
e do posicionamento. Explicaremos melhor essa questão. da diferenciação dos
produtos

4
Caso esteja interessado em obter mais informações neste momento, consulte o Apêndice II e os quadros de definições de termos-chave
nos capítulos 6 e 7.
140 PARTE 2 O Modelo

Figura 4.13 Resumo da atividade “Propor mudanças no portfólio de produtos”.

Uma máxima atualmente válida para produtos e serviços, e que precisa ser sempre lembrada, é que, no mer-
cado, não há espaço para produtos com desempenho mediano em todas as suas características. Produtos desse
tipo estão fadados ao fracasso, pois, mesmo não apresentando deficiências em relação aos concorrentes, eles difi-
cilmente irão se sobressair no momento da escolha realizada pelo cliente. As empresas que obtêm vantagens
competitivas por meio de produtos são aquelas que possuem linhas de produtos com características tais que
criam uma imagem única na mente dos consumidores e na qual cada produto possui vantagens em um conjunto
coeso de características que são fundamentais para o cliente, conforme o tipo especial de cliente para o qual foi
planejado. O usuário experimenta um diferencial em relação aos outros produtos porque as características que
ele mais valoriza são melhores naquele produto. É o fator de diferenciação. Cada produto de uma linha deve ter
esse fator bem definido de forma a atender um conjunto específico de clientes, sem haver também a sobrepo-
sição. (Veja o Quadro 4.10.)

Quadro 4.10 Diferenciação e Posicionamento de Produtos

Segundo Kotler (2000), diferenciação é o ato de desenvolver um conjunto de diferenças significativas para distinguir a
oferta da empresa (produto + serviço) da oferta da concorrência. Para diferenciar, é preciso entender os valores dos clientes,
isto é, identificar os perfis de clientes e a hierarquia de valores de cada perfil. Isso significa identificar quais aspectos do pro-
duto e serviço são mais importantes dentro do perfil: o pacote de valores.
Conhecendo os pacotes de valores, é possível planejar produtos de forma que ofereçam um conjunto de características
coerente com o conjunto de valores. É isso que fará com que ele ocupe uma posição de destaque diante dos demais pro-
dutos da empresa e dos concorrentes, para aquele perfil de cliente específico. Essa ação é chamada de posicionamento. De
uma maneira mais rigorosa, Kotler (2000) define posicionamento como o ato de desenvolver a oferta e a imagem da empre-
sa para ocupar um lugar destacado na mente dos clientes-alvo. O resultado final do posicionamento é a definição de uma
possível oferta de produto com definição clara de seu diferencial perante os produtos presentes no mercado.
Fonte: Kotler (2000).

A identificação clara da diferenciação de cada produto da linha é fundamental também para obter uma
maior racionalidade na produção e comercialização dos produtos, aumentando as chances de lucro da empresa.
Se uma empresa possui uma sobreposição, com dois produtos capazes de atender às necessidades de um mesmo
CAPÍTULO 4

Planejamento Estratégico de Produtos 141

perfil de cliente, surgem várias ineficiências. O volume de vendas de cada produto será menor do que se hou-
vesse apenas um produto, com o conseqüente aumento no custo das peças e a necessidade de estoque de uma
quantidade maior de material. O esforço para treinar a força de vendas e assistência técnica é maior, aumentando
o custo de manutenção e apoio ao cliente. E, por fim, pode-se dificultar a comunicação da melhor solução para o
cliente, que terá dúvidas no momento da compra, entre optar por um deles, aumentando desnecessariamente
seu desgaste. Tais dificuldades podem levá-lo a optar por um produto de empresa concorrente, que consiga in-
dicar a melhor solução de uma forma mais transparente e direta.
A Embraer é um caso de excelência mundial em desenvolvimento de produtos.
A empresa saiu de uma situação financeira complicada para, em poucos anos, se Um caso de sucesso em
tornar uma das maiores produtoras de aeronaves do mundo. Um dos projetos que termos de posicionamento:
o projeto Embraer 170
ajudou a empresa nesta transformação é denominado 170, e seu sucesso está vincu-
lado em grande medida a um trabalho excepcional de posicionamento de produto
no mercado. A Figura 4.14 demonstra a situação em termos de capacidade de assentos nas empresas aéreas, co-
lunas em cinza. A região em destaque está vazia por causa da inexistência de aeronaves capazes de voar economi-
camente com tais números de passageiros. Isto é, os produtos oferecidos pelas empresas aéreas eram muito
grandes ou muito pequenos, tornando-os ineficientes em mercados regionais mais aquecidos com o número de
passageiros na faixa em destaque.

Figura 4.14 A lacuna no número de assentos ocupados no mercado de aviação.

Fonte: Site: http://www.ruleof70to110.com/main/index.html — consultado no dia 18 de janeiro de 2005.

O projeto da família de aviões Embraer 170/190 teve como escopo o atendimento desse mercado regional
inexplorado, alcançando enorme sucesso. O fato de ser um projeto totalmente posicionado nesse segmento — e,
portanto, com características bem definidas para atender às necessidades desses clientes (diferenciação) — pos-
sibilitou uma vantagem enorme para os produtos da família. E, ainda, dificultou a concorrência de grandes em-
presas do setor, que costumavam comercializar aeronaves maiores ou adaptações desses produtos, geralmente
grandes aviões que eram “encurtados”.
Sem dúvida, a competência técnica da empresa foi fundamental, afinal, essa oportunidade vislumbrada
nunca poderia ter sido explorada sem a competência técnica. Mas o caso demonstra claramente a vantagem que
142 PARTE 2 O Modelo

pode ser obtida de um Plano Estratégico de Produtos bem elaborado, capaz de fornecer um posicionamento
preciso do produto no mercado. A definição adequada do Portfólio de Produtos deve garantir um posiciona-
mento ótimo para cada um dos produtos, sendo o elo entre Planejamento Estratégico e o esforço tecnológico
para a obtenção de um produto em si.
Portanto, além de considerar os critérios de alinhamento com a estratégia, de
Considerações a serem maximização de valor e balanceamento do portfólio, discutidos na atividade anterior,
tomadas durante a fase de o Time de Planejamento Estratégico de Produtos precisa escolher os produtos, preo-
proposição de mudanças
no portfólio de produtos
cupando-se, também, com a estratégia a ser seguida pela linha de produtos em si, isto
é, o posicionamento e, conseqüentemente, a diferenciação que será buscada entre
cada um deles. O Quadro 4.11, a seguir, apresenta uma lista de possíveis estratégias de
produtos que podem ser adotadas.

Quadro 4.11 Estratégias para Planejamento do Portfólio de Produtos

As mudanças no portfólio de produtos dependem das análises da estratégia, valor agregado e balanceamento, conforme
visto no tópico anterior. Especificamente com relação à estratégia, porém, é comum encontrarmos uma visão simplista com
5
dois tipos genéricos de estratégia: baixo custo e diferenciação. Os consultores Deschamps e Nayak , porém, compilaram um
conjunto de 8 estratégias para adição de valor aos produtos. Além do baixo custo e qualidade, são elas:
• Proliferação de produtos: segundo esses consultores, é a estratégia inaugurada pela Sony em equipamentos de
áudio e pela Honda em motocicletas no Japão. Trata-se de oferecer ao cliente uma vasta gama de opções, minando a
concorrência ao oferecer produtos com posicionamento melhor em todos os segmentos do mercado.
• Valor do dinheiro pago: é a estratégia de criar uma linha de produtos que maximiza o valor do dinheiro pago pelo
cliente, isto é, cujo posicionamento visa obter o máximo em termos de valor com o menor custo total de propriedade.
Um exemplo famoso é o da Toyota, no segmento de carros de luxo. A estratégia foi oferecer um conjunto de produtos
com características de design, acabamento e desempenho compatíveis com os melhores carros de luxo europeus,
porém, com custo total de compra e manutenção menores.
• Design: o conceito de design não é simples de definir, mas, para a compreensão desta estratégia, pode ser entendido
como as características de comunicação e interface do produto com o cliente, tais como: as mensagens visual, táctil e a
ergonomia do produto. Essa estratégia consiste em criar um conjunto de produtos com uma coerência de formas
capaz de criar uma imagem distinta no consumidor. Um exemplo é a Harley-Davidson. As formas dos guidões, bancos,
acessórios de couro, do escapamento e outros detalhes de comunicação visual e ergonomia, juntos, deram origem a
um estilo de produto característico, um novo paradigma de motocicleta, com personalidade própria e que, depois de
imitada, deu origem a uma nova categoria de produtos. Outro exemplo foi a Swatch, na área de relógios, que construiu
uma imagem clara de comunicação visual inovadora com o uso de cores e elementos gráficos inspirados na arte mo-
derna e formas não convencionais. Existem entusiasmados colecionadores que compram vários produtos da empresa
6
por ano, com formas totalmente distantes do padrão convencional. Para garantir esse alinhamento, a empresa
inovou, inclusive, ao ser uma das primeiras a encomendar os projetos gráficos de seus produtos para artistas plásticos
renomados. Logicamente que, no caso dessa empresa de relógios suíça, a mensagem não é transmitida unicamente
pelo produto, mas passa, ainda, por uma coerência entre o produto e o visual no ponto-de-venda, com projetos de
lojas que enfatizam o mesmo atributo da modernidade. Outro exemplo interessante é o da Apple. A empresa possuía
um produto com diferencial tecnológico em termos de recursos gráficos, mas vinha perdendo mercado e enfrentava
sérios problemas. Ela se recuperou ao lançar a linha de computadores iMAC, que enfatizava esse desempenho superior
7
e diferencial por meio de suas formas. Essa linha foi pioneira ao utilizar plásticos translúcidos, levar ao extremo o uso
das formas ovaladas e inovar com a integração entre monitor e CPU em micros portáteis: uma quebra de paradigma.
Tais elementos de design criaram uma personalidade própria e ajudaram a transmitir ao cliente a idéia de que se tra-
tava de um produto especial, posicionando-o em uma categoria única no mercado de computadores portáteis, padrão

(continua)

5
DESCHAMPS, J. P.; NAYAK, P. R. Produtos irresistíveis. São Paulo: Makron Books, 1996. cap. 2.
6
KOTLER (2000, p. 75).
7
KOTLER (2000, p.313).
CAPÍTULO 4

Planejamento Estratégico de Produtos 143

Quadro 4.11 Estratégias para Planejamento do Portfólio de Produtos (continuação)

PC. Nesta estratégia, a empresa precisa definir uma meta clara de identidade que deverá ser compartilhada pelos pro-
jetos e a diferenciação que está planejando.
• Inovação: uma outra estratégia possível de produtos é o foco na inovação como diferencial. Nesta estratégia, a empre-
sa define um portfólio capaz de garantir a linha de produtos mais inovadora do mercado, com os produtos mais avan-
çados e sendo pioneira na introdução de inovações tecnológicas. A empresa também planeja o portfólio de forma que
os produtos em operação sejam descontinuados mais rapidamente e haja uma proporção alta de projetos com
grandes inovações. O exemplo clássico aqui é a 3M, famosa por buscar um direcionamento desse tipo nos produtos
com tecnologia adesiva.
• Atendimento: em alguns mercados, o atendimento é o parâmetro mais importante na competição. Nesses casos, uma
estratégia de produtos possível é definir um portfólio com produtos posicionados para serem superiores nesse parâ-
metro. Isso significa a definição das famílias de produtos, adoção de novas tecnologias e modularização, tudo isso vi-
sando a manutenabilidade e confiabilidade. Os consultores Deschamps e Nayak citam, como exemplo, os casos da
OTIS e da Schindler/Westinghouse na área de elevadores.
• Velocidade: a estratégia de produtos baseada na velocidade é aquela em que o processo de desenvolvimento e o
portfólio são planejados de forma a obter desempenho de lead time de desenvolvimento muito superior que o das em-
presas concorrentes. Trata-se de uma estratégia ampla que pode ser utilizada para diferentes fins. A empresa pode uti-
lizá-la para criar uma diferenciação por quantidade de produtos, lançando maior número de opções (igual à estratégia
de proliferação de produtos). Pode-se utilizá-la para adotar uma estratégia seguidora dentro do setor, esperando a
concorrência correr os riscos pela inovação e entrando com uma solução mais madura e com ganhos de desempenho
no mercado. Pode-se utilizá-la para aumentar os lucros, diminuindo o investimento em marketing. A empresa apro-
veita o lançamento feito pelo concorrente, e o seu esforço em propaganda, colocando simultaneamente o seu produto
no mercado. Trata-se de uma estratégia importante em mercados com tecnologia ainda não madura, nos quais os pa-
drões mudam constantemente e inovações são criadas a todo instante — como o mercado de celular há 10 anos e o
mercado atual de desktops e palmtops.
Fonte: Essas estratégias de produto foram propostas por DESCHAMPS, J. P.; NAYAK, P. R. Produtos irresistíveis. São Paulo: Makron Books, 1996.

Uma vez entendida a importância do posicionamento e da diferenciação, fica


fácil compreender as tarefas que ocorrem na atividade proposição de mudanças no Tarefas da atividade de
portfólio de produtos. São elas: proposição de mudanças
no portfólio de produtos
n identificar produtos a serem descontinuados;
n identificar projetos a serem abandonados e congelados;
n identificar projetos a serem redirecionados;
n identificar os novos projetos que deverão ser iniciados;
n preparar a Minuta do Projeto (minutas de projeto) para cada um dos novos produtos a serem desenvol-
vidos; e
n consolidar proposta de novo portfólio de produtos.

A ordem em que essas tarefas foram listadas não corresponde à ordem cronológica de ocorrência. Cada
uma delas é uma decisão sobre a lista de produtos e projetos, as quais acontecem de maneira interativa. O Time
de Planejamento Estratégico de Produtos poderá realizar isso em uma reunião de trabalho com todos os pre-
sentes ou realizar várias reuniões. O ideal é que os participantes tenham tempo para estudar separadamente as
informações e se preparar para a reunião trazendo propostas.
Cada um dos novos projetos que passarão a integrar o portfólio exige um esforço adicional do time: a pre-
paração da Minuta do Projeto. Esse documento é a primeira definição do projeto, descrevendo as características
fundamentais do produto, definindo preço-alvo, líder do time e datas para o início do desenvolvimento e en-
trega final.
144 PARTE 2 O Modelo

A atividade é finalizada com a consolidação de todas as informações no documento que descreve o novo
portfólio de produtos.

4.8 Verificar a viabilidade do portfólio de produtos


Depois de definido o novo portfólio de produtos, o Time de Planejamento Estratégico de Produtos terá
uma lista de todos os produtos a serem mantidos no mercado e todos os projetos de desenvolvimento que de-
verão ser realizados em um determinado horizonte. O próximo passo a ser realizado é avaliar a viabilidade econô-
mica, de recursos e capacitação para a implantação do portfólio planejado, conforme sintetizado na Figura 4.15.

Figura 4.15 Resumo da atividade “Verificar a viabilidade do portfólio de produtos”.

As tarefas que precisam ser realizadas são:

n Avaliar a viabilidade econômica do portfólio de projetos: esta análise pode ser feita criando-se um
grande fluxo de caixa com as estimativas iniciais de investimento e retorno financeiro de cada um dos
projetos do portfólio. Detalhes maiores sobre como proceder a uma análise de viabilidade econômica
serão apresentados nos próximos capítulos. A única diferença em relação à análise econômica de um
projeto único é que essa análise é baseada em um fluxo de caixa de todos os projetos e produtos da em-
presa. É algo raro de ser visto nas organizações dado o grau de dificuldade inerente à quantidade de in-
formações que precisam ser sistematizadas. Espera-se que, no futuro, com o avanço e a integração das
ferramentas computacionais de gestão de portfólio, veja o Quadro 2.5, no Capítulo 2 deste livro, a exe-
cução desse tipo de análise seja factível para as empresas.
n Avaliar a viabilidade de obter os recursos para implantação do plano: outra análise importante é a
verificação se a empresa ou unidade de negócio possui os recursos financeiros e materiais para a implan-
tação do portfólio. Em caso negativo, essa análise deve resultar na identificação das ações para sua ob-
tenção, tais como: montagem de um determinado tipo de laboratório, bancada de ensaio ou busca de
novas verbas para investimentos.
n Avaliar se a empresa possui todas as competências necessárias: para o desenvolvimento dos pro-
dutos, serão necessárias competências que precisam ser dominadas — seja pela própria empresa ou um
de seus parceiros estratégicos. No caso do portfólio prever a incorporação de novas tecnologias nos pró-
ximos períodos, é fundamental que sejam elaboradas, nessa etapa, ações de aprendizagem que visem a
CAPÍTULO 4

Planejamento Estratégico de Produtos 145

incorporação dessas competências. Tais ações podem ser contratação de pessoal, compra de direitos
para o uso de determinadas patentes, parcerias estratégicas e outras conforme listado no Quadro 4.4, an-
teriormente.
n Obter consenso sobre a decisão final: enfim tem-se a versão final do novo portfólio de produtos da
empresa, montado a partir das discussões do Time de Planejamento Estratégico de Produtos, e que de-
verá ser implementado por ele. Se o planejamento das atividades dessa fase foi bem elaborado, todas as
atividades listadas anteriormente devem ter ocorrido de forma transparente e democrática. Nesse caso,
ao atingir-se esse momento há consenso no grupo de que o novo Portfólio de Produtos é o melhor a ser
seguido. O Time passa então para uma fase de implantação do Portfólio, na qual há um acompanha-
mento periódico dos projetos e produtos, promovendo-se atualizações pontuais nessa versão do port-
fólio. Acompanhar significa verificar o andamento dos projetos por meio dos gates e dar início ao
desenvolvimento de novos projetos, conforme previsto no plano. O início de um novo projeto é a pró-
xima e última atividade da fase de Planejamento Estratégico de Produtos.

4.9 Decidir o início do planejamento de um dos produtos do portfólio


Esta atividade extremamente simples é a primeira em nosso modelo específica para um determinado pro-
jeto de produto — como já discutimos anteriormente Até agora, todas as atividades foram direcionadas para o
conjunto de projetos e produtos existentes: o portfólio de produtos. Outra diferença importante é que as ativi-
dades anteriores ocorrem em um momento localizado no tempo, enquanto a ocorrência desta atividade depende
da programação expressa no portfólio de projeto.
A Figura 4.16 ilustra esta atividade que tem como principais informações de entrada o Portfólio de Pro-
dutos e o documento Minuta do Projeto. Este último é a proposta de um dos produtos do portfólio, que teve seu
início planejado para a data atual. A saída será a Minuta do Projeto aprovada, isto é, referendada pelo Time de
Planejamento Estratégico de Produtos, que deverá comunicar essa decisão para o Time de Desenvolvimento e
para o gerente de projeto.

Figura 4.16 Resumo da atividade “Decidir o início do planejamento do produto”.


146 PARTE 2 O Modelo

Em geral, as atividades anteriores ocorrem um ou dois meses no começo ou fi-


Tarefas da atividade de nal do ano, quando se mobiliza o Time de Planejamento Estratégico em um esforço
decisão do início do concentrado para realizar o Planejamento Estratégico de Produtos. Com o plano
planejamento do produto
aprovado, esse time passará a ter as seguintes atribuições: 1) monitorar os projetos e
produtos, respectivamente, em desenvolvimento e produção; 2) realizar pequenos
ajustes no plano; e 3) dar início formal aos projetos conforme as datas previstas de início do projeto são atingidas.
Se um projeto tem seu início marcado para 10 de julho, por exemplo, o time realizará o lançamento formal desse
projeto quando essa data chegar.
O lançamento formal de um projeto é feito pela assinatura e comunicação do
O documento principal: documento Minuta do Projeto e que, no linguajar da Gestão de Projetos (veja
Minuta do Projeto o Quadro 4.12). No caso do modelo unificado, são as pessoas que estão assumindo o
papel de Time de Planejamento Estratégico de Produtos as responsáveis pela
emissão da minuta. O leitor deve se lembrar que a primeira versão da minuta foi preparada durante a atividade
4.7, de proposição de mudanças no portfólio da empresa.

Quadro 4.12 Minuta do Projeto

Segundo a teoria de Gestão de Projetos, a Minuta do Projeto, também conhecida pelo termo em inglês Project Charter, é
um anúncio único que autoriza formalmente o início de um determinado projeto. Esse documento deve incluir uma des-
crição mínima do projeto, do produto que será desenvolvido e da pessoa responsável pelo trabalho de preparação da Decla-
ração de Escopo desse projeto. É importante que esse documento seja emitido por uma pessoa com um nível adequado de
decisão, isto é, que tenha o poder para autorizar o projeto. É um documento importante, mas, não significa que deva ser com-
plexo e ser enviado a todas as pessoas envolvidas em decisões importantes sobre os projetos desenvolvidos na empresa.

O Time de Planejamento Estratégico de Produtos revisará a Minuta do Projeto para incorporar possíveis
alterações no portfólio entre o tempo de sua primeira versão e o momento atual. Terá também a adição do nome
da pessoa que assumirá o papel de gerente de projeto. Esse ator é fundamental no processo de desenvolvimento
de produto. Desse momento em diante, coordenará as atividades da fase final do pré-desenvolvimento e todas as
fases do desenvolvimento de produtos.
Outro aspecto que deve ser notado é que a Minuta do Projeto contém a primei-
ra definição do que é o produto. Essa definição será ampliada com novos detalhes na A Minuta do Projeto
fase de Planejamento do Projeto, dando origem ao Escopo do Produto. Em seguida, contém a primeira
definição do produto, que
na fase de projeto informacional, esse escopo será esmiuçado e, novamente deta- será continuadamente
lhado, dará origem aos requisitos do produto e especificações-meta. Estas, por sua aprimorada até o final do
vez, serão transformadas em soluções técnicas e concepções na fase de projeto con- desenvolvimento
ceitual e, por fim, o produto e os processos de fabricação estarão completamente de-
finidos, em inúmeros documentos contendo descrições técnicas de cada peça e processo de fabricação. Essa é
uma característica de projetos de desenvolvimento, que são evolucionários. O produto vai sendo continuamente
definido e detalhado até que possa ser fabricado.

4.10 Questões e atividades didáticas propostas


1. Escolha uma empresa que desenvolva produtos e que você (ou seu grupo) tenha acesso às pessoas res-
ponsáveis pelo processo de desenvolvimento de produtos. Peça que elas descrevam todas as atividades
até o momento da escolha e realização da primeira definição de um determinado produto para ser pro-
jetado. Em seguida, compare com as atividades do modelo apresentadas no livro e responda: (a) os projetos
de novos produtos são escolhidos conforme a estratégia da empresa? (b) cite os prós e os contras da sis-
temática adotada pela empresa.
CAPÍTULO 4

Planejamento Estratégico de Produtos 147

2. Por que é tão importante que a definição do portfólio de produtos esteja relacionada com a estratégia de
negócios da empresa? Cite os problemas que podem acontecer caso essa ligação seja fraca.
3. Qual a relação entre Estratégia de Produto, Portfólio de Produtos e a Minuta do Projeto?
4. Quais são as vantagens de atribuir a um comitê a tarefa de escolha do portfólio de produtos da empresa?
5. Por que o esforço necessário para a revisão de um Plano Estratégico de Negócios pode variar de perío-
do a período?
6. Quais os cuidados básicos que devem ser tomados no planejamento de reuniões de trabalho?
7. Procure na Internet, em livros e artigos de seriados e periódicos exemplos de resultados de pesquisas de
mercado baseadas em cada um dos seguintes tipos de fonte:
a. Secundárias
i. Registros Internos
ii. Dados publicados de uso comum
iii. Dados padronizados de marketing
b. Primárias
i. Pesquisa qualitativa
ii. Pesquisa quantitativa
iii. Experimentos
8. Escolha um produto ou uma classe de produtos como exemplo, tais como: ferramentas elétricas, colas,
entre outros. Entre no site do Instituto Nacional de Propriedade Industrial (http://www.inpi.gov.br) e faça
uma busca nas bases de marcas, patentes e desenhos industriais, relacionados com o produto escolhido.
9. Defina Gerenciamento de Portfólio. Quais são as metas principais do gerenciamento de portfólio?
10. Quais os três tipos de técnicas para gestão de portfólio? Descreva-os.
11. A tabela a seguir apresenta uma lista de projetos contendo algumas informações. Identifique o melhor
projeto empregando a técnica do Valor Econômico Esperado. Quais as vantagens e desvantagens da
técnica do Valor Econômico Esperado?

Custo de Custo de Probabilidade Probabilidade


Valor Presente Total investido Desenvolvimento Comercialização de Sucesso de Sucesso
Líquido (R$) (R$) (R$) (R$) Técnico (%) Comercial (%)
Nome do Projeto VPL TI CD CC Pst Pst

Produto A 1.000.000,00 40.000,00 30.000,00 10.000,00 88 86


(Incremental)

Produto B (Inovação 3.000.000,00 300.000,00 150.000,00 150.000,00 76 64


no processo)

Produto C (Nova 30.000.000,00 800.000,00 600.000,00 600.000,00 40 74


plataforma)

Produto D 100.000,00 20.000,00 5.000,00 5.000,00 20 70


(Pequeno Projeto)

Produto C 5.000.000,00 600.000,00 400.000,00 400.000,00 52 100


(Redesenho para
inclusão de Nova
Funcionalidade)

12. Desenhe Gráficos de Bolha para os projetos apresentados na listagem da questão anterior e, obser-
vando a análise realizada, responda: Quais projetos você cancelaria? É importante ter projetos em todos
os quadrantes do diagrama? Explique.
148 PARTE 2 O Modelo

13. Faça uma lista com possíveis critérios para análises de portfólio baseada em modelos de notas. Liste no
mínimo sete critérios.
14. Visite uma empresa e entreviste o gerente de desenvolvimento de produtos para conhecer a lista de pro-
dutos da empresa. Em seguida, crie uma planilha Excel que auxilie na análise de portfólio de produtos,
combinando as técnicas apresentadas no texto.
15. Forme um grupo com três alunos. Escolha um tipo de produto e faça um levantamento das linhas de
produto, classificando-as em segmentos e posicionamentos distintos. Utilize catálogos disponíveis nos
sites de empresas que atuam na área.

Sugestões de tipos de Empresa Site


produtos
Linha Branca Brastemp http://www.brastemp.com.br/
no Brasil Electrolux http://www.electrolux.com.br/index.asp
Enxuta http://www.enxuta.com.br/
Máquinas Fotográficas Pentax http://www.pentax.com/products/cameras/
Sony http://www.sony.com
Nikon http://www.nikonusa.com/usa_home/home.jsp
Sigma http://www.sigmaphoto.com/
Copiadoras Xerox http://www.xerox.com.br/
HP http://www.hp.com/country/bz/por/welcome.htm
Minolta http://www.minolta.com.br/

16. O que é a Minuta do Projeto? Qual a sua importância para o processo de desenvolvimento de produtos?
17. Que cuidados devem ser tomados na preparação da Minuta do Projeto?

4.11 Informações adicionais


AAKER, D.; KUMAR, V.; DAY, G. S. Pesquisa de marketing. São Paulo: Atlas, 2001.
CLARK, K. B.; FUJIMOTO, T. Product development performance: strategy, organization and
management in the world auto industry. Boston, Mass.: Harvard Business School Press, 1991.
COOPER, R. G.; EDGETT, S. J.; KLEINSCHMIDT, E. J. Portfolio management for new products.
Massachussets: Perseus Books, 1998.
DECHAMPS, J. P.; NAYA, P. R. Produtos irresistíveis. São Paulo: Markron Books, 1997.
KIDDER, L. H.; JUDD, C. M. Research methods in social relations. 5. ed. New York: Holt, Rinehart
and Winston, CBS College Publishing, 1986.
KOTLER, P. Administração de marketing: a edição do novo milênio. São Paulo: Prentice Hall, 2000.
OPPENHEIM, A. N. Questionnaire design, interviewing and attitude measurement. New York:
Continuum, 2001.
PAHL, G.; BEITZ, W. Engineering Design a systematic approach. Springer: Verlag, 1993.
PMI Standards Committee. Project Management Body Of Knowledge. Pennsylvania: Project
Management Institute Publications, 2000. Disponível em: <http://www.pmi.org>. Acesso em: 20 mar. 2005.
PUGH, S. Total design: integrated methods for successful product engineering. Addison Wesley, 1991.
REA, L. M.; PARKER, R. Metodologia de pesquisa: do planejamento à execução. São Paulo: Pioneira, 2000.
ULRICH, K.T.; EPPINGER, S. D. Product design and development. USA: McGraw-Hill, 1995.
WHEELWRIGHT, S. C. CLARK, K. B. Revolutionizing product development process: quantum leaps
in speed, efficiency, and quality. New York: The Free Press, 1992.
5.1 Sumário
5.2 Definir interessados do projeto
5.3 Definir escopo do produto
5.4 Definir escopo do projeto
5.5 Detalhar o escopo do projeto
5.6 Adaptar o modelo de referência
5.7 Definir atividades e seqüência
5.8 Preparar cronograma
5.9 Avaliar riscos
5.10 Preparar orçamento do projeto
5.11 Analisar a viabilidade econômica do projeto
5.12 Definir indicadores de desempenho
5.13 Definir plano de comunicação
5.14 Planejar e preparar aquisições
5.15 Preparar plano de projeto
5.16 Avaliar fase
5.17 Aprovar fase
5.18 Resumo do capítulo
5.19 Questões e atividades didáticas
5.20 Informações adicionais

5. Planejamento do Projeto
PARTE 2 O Modelo
Planejamento do Projeto

Depois da leitura deste capítulo, você será capaz de:


l Identificar na empresa quem são os maiores interessados com o projeto de produto, relacionando suas necessidades,
limitações, e potencial de envolvimento com o projeto.
l Definir o escopo do produto e do projeto, buscando uma clara compreensão do que será fornecido ao cliente e como
será obtido.
l Adaptar o modelo de referência adotado pela empresa, para que seja utilizado em um projeto específico.
l Definir quais as atividades, o cronograma e os recursos necessários para realização do projeto.
l Elaborar um plano de gestão de riscos do projeto.
l Realizar a análise da viabilidade econômico-financeira, estimando as perspectivas de desempenho financeiro do
produto resultante do projeto.
l Planejar os indicadores de desempenho que serão empregados no acompanhamento e avaliação das cinco fases do
desenvolvimento do produto, durante a execução do projeto.
l Planejar o gerenciamento das comunicações no projeto e das aquisições do que será necessário adquirir para a
realização do projeto.
150 PARTE 2 O Modelo

5.1 Sumário
A fase de planejamento do projeto finaliza a macrofase de pré-desenvolvimento, o que pode ser visualizado
no destaque em cinza-escuro da Figura 5.1.

Figura 5.1 Localização das fases do pré-desenvolvimento dentro do Processo de Desenvolvimento de Produtos unificado.

A fase de Planejamento Estratégico de Produtos, veja o Capítulo 4, trans-


Objetivo do Planejamento formou informações advindas do Planejamento Estratégico da Corporação e do
do Projeto
Planejamento Estratégico da Unidade de Negócios em um portfólio de projetos e
produtos da empresa. Nessa fase, realiza-se o planejamento macro de um dos pro-
jetos de novo produto planejados no portfólio, aquele aprovado pelo Time de Planejamento Estratégico de Pro-
dutos na última atividade da fase anterior. O planejamento tem início assim que um projeto específico é
formalmente iniciado. Deve-se lembrar que esse momento foi previsto no portfólio de produtos e a comuni-
cação é feita pelo Time de Planejamento Estratégico de Produtos. A comunicação deve ser feita para todas as
áreas ligadas diretamente com o desenvolvimento de produtos, em especial, para o coordenador dessa atividade.
O resultado final é o Plano de Projeto do Produto que, demonstrando-se viável, será utilizado como guia
para a próxima macrofase de Desenvolvimento do Produto. Como já ressaltado no Capítulo 2, a importância do
pré-desenvolvimento reside no planejamento sistemático dos projetos, pois, ao permitir uma boa previsão e aná-
lise do seu escopo e riscos, previne problemas que poderiam ocorrer quando da realização efetiva do projeto no
desenvolvimento do produto.
As atividades do Planejamento do Projeto, de forma genérica, devem empreender esforços no sentido de
identificar todas as atividades, recursos e a melhor forma de integrá-los para que o projeto siga em frente com o
mínimo de erros. Compatível com as preocupações levantadas no Capítulo 1 a respeito dessas informações, o
planejamento deve prever as necessidades de integração de informações e decisões entre as áreas funcionais e
outros projetos da empresa, contribuindo para a melhor coordenação e comunicação no projeto.
CAPÍTULO 5

Planejamento do Projeto 151

A visão e a efetividade com que a empresa e seu Processo de Desenvolvimento de Produtos (PDP) tratam
da questão do gerenciamento multiprojetos, conforme destacado no Capítulo1, terá significativo impacto na
concepção e administração do portfólio de projetos/produtos da empresa, com conseqüente reflexo no Planeja-
mento do Projeto. Esses reflexos referem-se tanto ao planejamento de colaborações entre pessoas e tecnologias
nos diferentes tipos de projetos em andamento (plataformas, derivações etc) no PDP da empresa, como,
também, ao planejamento das combinações entre os diferentes arranjos organizacionais possíveis no PDP da
empresa, para conduzir a execução desses projetos.
O plano do projeto é um documento que agrupará informações relevantes para
a execução do projeto. Essas informações são, como já mencionado no Capítulo 2: O resultado da fase
escopo do projeto, escopo do produto (conceito do produto), previsões das ativi-
dades e sua duração, prazos, orçamento, definição do pessoal responsável, recursos necessários para realizar o
projeto, especificação dos critérios e procedimentos para avaliação da qualidade (assim como possíveis normas
que precisam ser atendidas), análise de riscos e indicadores de desempenho selecionados para o projeto e pro-
duto (com seus valores-alvo). Dada a ligação imediata com a macrofase seguinte, a elaboração desse plano pre-
cisa considerar o escopo e as características de cada uma das cinco fases do desenvolvimento do produto: projeto
informacional (gera especificações-meta), projeto conceitual (as concepções do produto), projeto detalhado (es-
pecificações finais), preparação da produção (liberação da produção) e lançamento do produto. Essas fases farão
uso do plano do projeto, atualizando-o no início de cada fase, na atividade genérica de “atualizar plano do pro-
jeto”, descrita no Capítulo 3, Tópico 3.1.
A Gestão de Projetos é uma área do conhecimento que estuda as ferramentas e
as melhores práticas para o gerenciamento de qualquer tipo de projeto, desde a im- Os conhecimentos da área
de Gestão de Projetos são
plantação de um novo serviço de manutenção elétrica, a organização de um evento, fundamentais
incluindo o projeto de novos produtos, conforme pode ser observado no Quadro
5.1. O planejamento é uma das etapas principais da gestão de um projeto e, por isso,
as atividades dessa fase estão fortemente relacionadas com essa área do conhecimento. Os conhecimentos, mé-
todos e técnicas propostos pelos pesquisadores e profissionais da área devem, portanto, ser utilizados. O modelo
unificado descreve a aplicação desses conceitos especificamente para o projeto de produtos físicos, o que signifi-
ca que a escolha e a combinação das técnicas foi elaborada para esse tipo específico de projetos.

Quadro 5.1 Gestão de Projetos

Um projeto pode ser entendido como um empreendimento com começo, meio e fim bem definidos, seguindo a orienta-
ção do plano estratégico da empresa, e com o objetivo claro de criar um produto ou serviço bem delimitado.
A Gestão de Projetos é, portanto, a forma com que esse empreendimento é conduzido dentro da empresa. Sua preocu-
pação é com a otimização da realização das atividades e com o emprego dos recursos, ambos devidamente integrados,
pelas pessoas que formam a equipe de projeto. Essa gestão deve estar preparada para mudanças que podem ocorrer no
contexto em que o projeto está inserido, para que ele atinja desempenho igual, ou melhor, ao originalmente previsto.
Em geral, a Gestão de Projetos deve ser realizada ao longo de todas as três etapas básicas de um projeto: desde seu plane-
jamento, passando pela execução propriamente dita, até chegar a seu encerramento, quando são registrados os resultados
atingidos pelo projeto e as lições aprendidas. O Project Management Institute (PMI) define cinco processos, conjuntos de
atividades da gestão de projetos, conforme apresenta a Figura 5.2.
Ao longo dessa gestão, é necessário o estabelecimento de controles e avaliações periódicas para o acompanhamento do
projeto, e a constante busca de equilíbrio entre requisitos muitas vezes conflitantes, como a duração do projeto, os seus pa-
râmetros de qualidade, e os recursos necessários, além dos diferentes interesses e necessidades dos vários atores envol-
vidos, tais como os clientes, os fornecedores, demais setores da empresa, dentre outros.

(continua)
152 PARTE 2 O Modelo

Quadro 5.1 Gestão de Projetos (continuação)

Figura 5.2 Processos da Gestão de Projetos.

Fonte: PROJECT MANAGEMENT INSTITUTE(2000)

Uma completa Gestão de Projetos deve gerenciar de forma integrada vários conhecimentos, em que se destacam, se-
gundo o Project Management Body Of Knowledge (PMBOK): o escopo, tempo, custo, qualidade, recursos humanos envol-
vidos, as comunicações do projeto, a gestão de riscos, as aquisições externas da empresa e a integração de todas essas áreas.
Dada essa diversidade de assuntos envolvidos, é recomendável que a Gestão de Projetos relacione-se com outras disci-
plinas e práticas da administração.

Fonte: PMI Standards Committee. Project Management Body Of Knowledge. Pennsylvania: Project Management Insti-
tute Publications, 2000. Disponível em: <http://www.pmi.org>. Acesso em: 20 de março de 2001.

Um projeto, no contexto do PDP, significa seguir e interpretar esse processo de forma única e temporária,
visando criar um novo produto. É única porque esse produto desenvolvido será de alguma forma diferenciado
em relação aos outros produtos do portfólio da empresa, e seguiu um caminho único em seu desenvolvimento,
embora orientado por um processo de desenvolvimento de produtos (DP) — que é o mesmo que orienta todos
os demais produtos do portfólio. É temporário, pois o projeto deve ter um começo, meio e fim definidos.
Essas características de unicidade e temporalidade do projeto trazem implicações em seu planejamento e
gestão. Um projeto de DP deve ser planejado para aproveitar adequadamente um intervalo de tempo propício
ao lançamento de um novo produto, pois, passado esse tempo, perde-se a oportunidade de mercado para isso.
Durante o tempo de realização do projeto, deve ser previsto o envolvimento parcial ou integral das pessoas na
equipe que o executará, e que, ao final, serão realocados em outros projetos ou trabalhos. As particularidades de
cada projeto de produto, mesmo que seguindo o PDP padrão da empresa e sendo similar a outros projetos de
DP, certamente exigirão habilidades particulares e que devem ser planejadas tanto quanto possível.
No Capítulo 2, foi feita uma discussão detalhada desse aspecto, mas é importante aqui demonstrar as impli-
cações em seu planejamento e gestão. Um projeto de DP deve ser planejado para aproveitar adequadamente um
intervalo de tempo propício ao lançamento de um novo produto, pois, passado esse tempo, a oportunidade de
mercado pode ser “perdida”, isto é, mudanças no ambiente podem torná-lo inviável. Durante o tempo de reali-
zação do projeto, deve ser previsto o envolvimento parcial ou integral das pessoas na equipe que o executará, e
que, ao final, serão realocados em outros projetos ou trabalhos. Diferenças nas características do projeto e do
processo certamente exigirão habilidades particulares e que devem ser planejadas tanto quanto possível.
CAPÍTULO 5

Planejamento do Projeto 153

A pessoa que coordenará todo o Planejamento do Projeto, e executará pratica-


mente todas as atividades dessa fase, deve ser a mesma que exercerá o papel de gerente Quem participa e quais são
de projeto, isto é, a pessoa que estará também na coordenação do time durante a ma- os responsáveis pelo
Planejamento do Projeto?
crofase de desenvolvimento. Essa característica do modelo é intencional e serve para
garantir um bom fluxo de informações e aumentar o comprometimento da equipe.
Por melhor que seja a qualidade dos documentos gerados nessa fase, se o gerente de projeto for uma pessoa
diferente da que elaborou o plano, uma quantidade significativa de informação não explícita e conhecimentos
tácitos serão perdidos. Além disso, uma pessoa distinta não teria o mesmo comprometimento. Isso vale para
qualquer atividade de planejamento. Quando planejador e responsável por execução são a mesma pessoa, o cui-
dado na elaboração é maior. A pessoa só recomendará a aprovação se tiver consciência de que o Plano de Desen-
volvimento de Produtos é viável, pois, caso contrário, é ele próprio quem sofrerá as conseqüências no futuro
como gerente do projeto.
Apesar de a nomeação do gerente de projeto acontecer nessa fase, não é necessária a nomeação do Time de
Desenvolvimento. O planejamento, para a maioria dos projetos de desenvolvimento de produtos, pode ser reali-
zada pelo gerente de projeto isoladamente, sem comprometer horas de trabalho de outras pessoas do time. Lo-
gicamente, o gerente de projeto poderá necessitar da ajuda de uma quantidade grande de especialistas para
realizar as atividades, especialistas em finanças, técnicos, em vendas etc. Eles deverão fornecer estimativas de na-
tureza diversa, fundamentais para o bom planejamento, como horas necessárias para realizar determinadas ta-
refas. Em casos especiais como produtos de grande porte, navios, aviões, projetos de novas plataformas de
automóveis mundiais com várias versões e outros, a complexidade do planejamento, seja em termos de quanti-
dade de recursos — como a logística para integração —, poderá exigir que o planejamento seja realizado por
uma equipe específica. Nesse caso, essa equipe poderá ou não ser a mesma que realizará o projeto posteriormen-
te. É comum também a existência de áreas funcionais especializadas em planejamento, cuja função é apoiar o ge-
rente de projeto, que são os chamados escritórios de projeto (veja o Quadro 5.2).

Quadro 5.2 Escritório de Projetos

É uma estrutura organizacional específica que realiza serviços de suporte para o gerenciamento dos projetos da empresa.
Conhecido também como: Comitê Diretor de Projetos, Coordenação de Projetos, Escritório de Apoio a Projetos, Grupo de
1
Apoio à Gerência de Projetos, entre outros nomes. Segundo Valeriano, um escritório de projetos pode receber diferentes atri-
buições, conforme o nível de evolução da empresa em termos de maturidade da Gestão de Projetos. Essas atribuições são:
1) Para um estágio inicial:
prestação de serviços de controle de prazos e custos;
elaboração de relatórios multiprojetos e interdepartamentais;
treinamento em aspectos específicos de gerenciamento de projeto;
ligações com gerentes departamentais;
melhoria contínua de processos de gerenciamento de projeto; e
registro de lições aprendidas.
2) Estágio Intermediário:
arquivo do histórico de projetos;
administração dos processos de gerenciamento de projeto;
consultoria interna sobre gerenciamento de projeto;
desenvolvimento e aperfeiçoamento de métodos e padrões; e
apoio a reuniões de avaliações e revisões de projetos.
3) Para um estágio avançado:
distribuição de recursos de acordo com prioridades estabelecidas;

(continua)
1
VALERIANO (2000).
154 PARTE 2 O Modelo

Quadro 5.2 Escritório de Projetos (continuação)

avaliação externa de projetos;


formação de gerentes de projeto; e
gerência direta de grandes projetos da organização.

Fonte: VALERIANO, D. L. Gerenciamento estratégico e administração por projetos. São Paulo: Makron Books, 2001.

As atividades realizadas nesta fase e a relação entre elas são representadas na Fi-
Resumo das atividades gura 5.3. O Planejamento do Projeto recebe informações do portfólio de produtos e
realizadas na fase de projetos e, em especial, aquelas provenientes da proposta do produto (Minuta do Pro-
Planejamento do Projeto
jeto). Como resultado, o Plano do Projeto apresenta informações relativas às declara-
ções de escopo de produto e de projeto, às atividades e suas previsões de duração, aos
orçamentos, recursos e pessoal necessários para a execução do projeto, às possibilidades de riscos e aos indicadores
de desempenho que devem ser empregados. Os nomes das atividades, técnicas e métodos foram escolhidos
tendo-se como referência principal o PMBOK (livro ou conjunto de conhecimentos em gerência de projetos)2 do
PMI, com pequenas alterações para adequá-los. Essa associação de profissionais de Gestão de Projetos vem orga-
nizando e sistematizando os conceitos e técnicas da área e, tornando-se um padrão largamente adotado pelos pro-
fissionais de Gestão de Projetos de diferentes domínios. Com isso, espera-se facilitar a compreensão do modelo.

Figura 5.3 Informações principais e dependências entre as atividades da fase de Planejamento do Projeto.

2
PMI Standards Committee. Project Management Book of Knowledge. Pennsylvania: Project Management Institute Publications,
2000. Disponível em: <http://www.pmi.org>. Acesso em: 20 de março de 2005.
CAPÍTULO 5

Planejamento do Projeto 155

5.2 Definir interessados do projeto


Essa atividade, cuja síntese é apresentada na Figura 5.4, trata da definição dos interessados no projeto, que
são os indivíduos e as organizações envolvidos diretamente e também aqueles que, de alguma forma, serão afe-
tados por sua existência. Esses agentes ou atores podem manifestar ou sofrer influências relativas ao projeto
tanto ao longo de seu planejamento, como em sua realização e mesmo após sua conclusão. Cabe a presente ativi-
dade identificar essas partes envolvidas, e entender suas necessidades, limitações e o tipo de envolvimento que
terão com o projeto, de forma que as demais atividades do planejamento e execução do projeto façam adequado
uso dessa informação.

Figura 5.4 Atividade de definição dos interessados do projeto.

Em um projeto de DP típico, existem algumas partes principais envolvidas: os membros da equipe; o ge-
rente ou líder do projeto; os múltiplos clientes do projeto (produto); a organização executora e financiadora; os
fornecedores diversos (de serviços para o projeto, e de serviços e componentes para a manufatura do produto e
sua posterior pós-venda).
Viabilizar o trabalho dessas partes ou interessados requer algumas ações de planejamento organizacional,
montagem e desenvolvimento da equipe, que são as principais tarefas da presente atividade. Essas ações orientam-se
por certas habilidades genéricas da administração, como a capacidade de liderança, comunicação, negociação,
delegação, motivação, desenvolvimento de equipe e tratamento de conflitos, dentre outros temas relacionados
ao tratamento de pessoas e gerenciamento de equipes de projeto na organização.
A gestão dos interessados do projeto deve também considerar certas características inerentes ao projeto e
que afetam significativamente as pessoas e equipes com ele envolvidas:

n projetos são temporários e, portanto, predominam as relações transitórias entre os envolvidos com sua
execução; e
n as partes envolvidas, e sua intensidade de envolvimento, alteram-se ao longo do projeto.
156 PARTE 2 O Modelo

A determinação das responsabilidades e nível de dedicação (esforço alocado no


Planejamento projeto) de cada participante é feita no planejamento organizacional, que deve
organizacional dos ocorrer logo no início do projeto. Esse planejamento já deve prever o envolvimento
interessados do projeto
ao longo do projeto tanto dos atores internos à organização, provenientes de áreas
funcionais — como engenharia, marketing etc. —, como também de colaboradores
externos, como a participação de fornecedores e de outros parceiros estratégicos ao longo do DP (na presente
atividade, uma das preocupações é o pré-estabelecimento de parcerias estratégicas).

Quadro 5.3 Participação de Fornecedores no PDP

No Capítulo 2, Tópico 2.10, foram apresentados os diferentes tipos de envolvimento dos fornecedores em projeto de desen-
volvimento. Nessa atividade, devem ser identificados os fornecedores de nível maior de envolvimento no Processo de Desenvol-
vimento de Produtos. Tal qual os demais interessados, será preciso definir claramente suas responsabilidades no projeto. Por
exemplo, pode-se identificar que o fornecedor de um determinado subsistema tem maior competência na tecnologia do que
a empresa, possui um bom histórico de relacionamento, garantindo níveis suficientes de confiança e sigilo, e comprometi-
mento de longo prazo. Nesse caso, ele poderá já ser escolhido para participar no projeto como co-desenvolvedor (veja a Figura
5.5), atribuindo desde já a responsabilidade pelo subsistema. Nesse caso, ele poderá dar início às negociações para obter uma
confirmação do interesse da empresa e obter uma primeira proposta de orçamento. Se ele for um co-desenvolvedor do tipo
parceiro, irá se comprometer com a nomeação de um engenheiro residente que fará parte do Time de Desenvolvimento, iniciando
sua atuação na próxima fase, Planejamento do Projeto. Outra possibilidade é o fornecedor que entrega um subsistema impor-
tante, mas com interface padronizada, isto é, trata-se de um fornecedor de serviços. Ele é um fornecedor importante e sua
competência será essencial para o sucesso do produto, mas, nesse caso, não precisará participar da equipe do projeto. O ge-
rente de projeto especificará no plano que o fornecedor será escolhido no projeto detalhado (veja a Figura 5.5), mas não pre-
cisará se preocupar com contratos e decisões legais nesse momento. Ele será também o co-desenvolvedor e será escolhido
durante a fase de projeto conceitual, quando a equipe de projeto irá lhe transmitir um conjunto de requisitos do produto defi-
nidos pelo time de projeto. O caso de menor interação é aquele no qual o fornecedor é responsável por produtos padroni-
zados. Esses fornecedores não precisam ser identificados nessa fase também. Eles só serão escolhidos no momento de
preparação da produção, pois a sua escolha dependerá principalmente dos critérios custo e entrega.

Figura 5.5 Possibilidade de envolvimento dos fornecedores no PDP.

(continua)
CAPÍTULO 5

Planejamento do Projeto 157

Quadro 5.3 Participação de Fornecedores no PDP (continuação)

O parceiro de tecnologia auxilia no desenvolvimento da tecnologia, processo paralelo ao PDP. Eventualmente, ele pode
ser consultado na definição do portfólio de produtos para que seja verificado se uma tecnologia está madura o suficiente
para ser utilizada. Pode também participar da concepção, apoiando o time na primeira aplicação da tecnologia. O parceiro
de risco geralmente precisa ser consultado desde a proposta do projeto e, neste caso, estaria acompanhando o trabalho
atual do Gerente de Projeto. Sem o seu aval, a Proposta de Projeto não poderá ser encaminhada. Além disso, ele deve parti-
cipar do planejamento de todo o projeto.
Enfim, a participação de cada diferente tipo de fornecedor será iniciada em fases distintas, conforme sua responsabili-
dade dentro do projeto. Os fornecedores de maior interação (Parceiros de Tecnologia, Risco e Co-Desenvolvedores de maior
envolvimento) terão que ser identificados nessa fase, e suas responsabilidades e nível de dedicação deverão ser claramente
estabelecidos no escopo do projeto como interessados.

As informações necessárias para a realização do planejamento organizacional são basicamente dos se-
guintes tipos: das interfaces do projeto com outras entidades (unidades, setores etc.) da empresa; do perfil do
pessoal envolvido quanto as suas habilidades; e das restrições das opções organizacionais do projeto, tais como: o
tipo de estrutura organizacional da empresa, que pode ser mais ou menos favorável à Gestão de Projetos; os
acordos trabalhistas, que podem dar maior ou menor possibilidade de alocação dos empregados da empresa em
estruturas flexíveis voltados ao DP etc.
Essas informações devem ser processadas a fim de constituir o planejamento organizacional do projeto, e,
para isso, alguns procedimentos podem ser empregados. Um dos principais é tomar como base outros projetos
bem-sucedidos da empresa, adaptando ao atual projeto a forma com que foram organizados as responsabilidades
e relacionamentos, com base nessas novas informações. Outros procedimentos envolvem inspirar-se nas me-
lhores práticas de gerenciamento de recursos humanos em diferentes setores da empresa e também na ampla li-
teratura sobre teoria organizacional, de onde se podem derivar propostas de responsabilidades e relacionamentos
para as atividades do projeto.
Como resultados desse planejamento organizacional têm-se:

n as atribuições dos papéis e responsáveis pelas atividades do projeto, nas cinco fases do desenvolvimento
do produto (do projeto informacional ao lançamento do produto) — portanto, essas responsabilidades
variam ao longo do tempo de execução do projeto e devem estar ligadas ao detalhamento do escopo
dessas atividades;
n um plano de gerenciamento do pessoal envolvido com o projeto, que descreve quando (ao longo da exe-
cução do projeto) e como (em que partes das atividades, com quais outras pessoas e recursos) os colabo-
radores serão alocados e retirados do time de projeto de DP;
n o organograma do projeto, um tipo de representação gráfica que ilustra os papéis e responsáveis pelas
atividades do projeto além de seus relacionamentos;
n e outros detalhes para dar apoio a esse planejamento organizacional dos interessados do projeto, que
normalmente incluem: avaliações de impacto nos recursos humanos da organização em razão do plane-
jamento adotado; descrições das responsabilidades especificadas pelo planejamento; descrição do nível
de dedicação de cada pessoa; e necessidades de treinamentos de pessoal.

Realizado o planejamento organizacional, a tarefa seguinte é a montagem da


equipe que será responsável pelo projeto de DP, a qual exercerá o papel de Time de Montagem da equipe
Desenvolvimento especificado no modelo. (time de desenvolvimento)

A seleção daqueles que farão parte dessa equipe baseia-se no plano de gerencia-
mento do pessoal envolvido com o projeto e nas características do quadro de pessoal disponível na empresa, par-
ticularmente nas áreas e departamentos envolvidos com o DP. Verificar essas características envolve: analisar a
experiência anterior de indivíduos e grupos em outros projetos, os interesses dessas pessoas e grupos em parti-
158 PARTE 2 O Modelo

cipar do atual projeto, suas afinidades para trabalhar em um mesmo time ou equipe, a disponibilidade dessas pes-
soas e grupos ao longo do projeto, e a compatibilidade entre as demandas do projeto com as competências e
habilidades dessas pessoas.
Essas informações quanto ao mapeamento dos recursos humanos, que se deseja façam parte do time de pro-
jeto de DP, servem de base para que se negocie com outras instâncias da empresa a necessária alocação do pes-
soal no projeto. Geralmente, o gerente de projeto negociará diretamente a equipe com as pessoas que assumem
o papel de Time de Planejamento Estratégico de Produtos. Esse time possui a visão da estratégia da empresa e
dos comprometimentos dos recursos nos diversos projetos em andamento, as quais são as bases para o projeto de
desenvolvimento. Em casos extremos, podem ser necessárias negociações com a alta cúpula da empresa, que
deve possuir a visão estratégica das prioridades da empresa em termos de produtos a serem lançados no mercado
e, portanto, podem melhor intermediar as diferentes e, por vezes, conflitantes necessidades de pessoal.
Deve ser buscado um equilíbrio nas disputas por recursos humanos entre os gerentes dos projetos de DP
em andamento na empresa, e desses com os gerentes funcionais que naturalmente olham primeiro as necessi-
dades de suas áreas ou departamentos. Uma negociação bem conduzida e transparente, ouvindo e discutindo
com todos os interessados, permitirá a constituição de um time ou equipe de projeto estável. Isso minimiza con-
flitos dentro do projeto e com outros projetos e áreas funcionais, reduzindo alocações inadequadas de pessoas no
projeto e os riscos de perdas de pessoal para outros projetos ou áreas funcionais, em trocas não previstas de pes-
soal ao longo do projeto.
A finalização da montagem da equipe ou time de projeto do DP ocorre com o encerramento das negocia-
ções, quando é esperada a definição de quais as pessoas e grupos efetivamente farão parte do projeto ao longo do
seu andamento, e, dentre essas, quais ficarão em alocação integral ou parcial.
Ao longo de toda a execução do projeto, é necessário que se busque um con-
Desenvolvimento da tínuo aprimoramento e desenvolvimento, no sentido do trabalho efetivo em time
equipe para a execução ou equipe, de forma que as partes envolvidas percebam e sintam que suas contribui-
do projeto
ções individuais se encaixam em um todo maior e integralmente constituído, dado
pelo esforço conjunto da equipe no projeto de DP.
A verificação de como o efetivo desenvolvimento do trabalho em equipe está ocorrendo pode ser feita me-
diante certas comparações. As características esperadas de competência individual e para o trabalho em equipe
— tendo-se como base os históricos a esse respeito em projetos anteriores dos membros alocados no projeto —
podem ser comparadas com o desempenho desses participantes na execução individual e em equipe das ativi-
dades do plano do projeto atual, em consonância com o plano de gerenciamento do pessoal. Além disso, a equipe
do projeto pode periodicamente se auto-avaliar em termos de trabalho individual e em equipe, comparando-se
com o que foi realizado nesses quesitos em outros projetos, além de receberem avaliações independentes a esse
respeito, de pessoas externas ao projeto.
Para fomentar o desenvolvimento do trabalho em equipe, algumas ações são recomendadas e podem ser
planejadas para ocorrer ao longo do projeto. Envolve essencialmente a criação de condições facilitadoras para
melhorar o relacionamento entre os membros da equipe, como a oportunidade de participação coletiva em mo-
mentos de decisões no projeto, uma cultura de gestão do projeto que busca reconhecimento e recompensa aos
participantes que consigam equilibrar contribuições individual e coletiva ao projeto, a alocação da maioria dos
participantes do projeto em um espaço físico próximo, a realização de reuniões presenciais regulares para esti-
mular a atualização coletiva, programas de treinamento formais e capacitação dos membros do projeto que prio-
rizem a execução do trabalho em equipe etc.

5.3 Definir escopo do produto


A primeira atividade de planejamento a ser executada pelo gerente de projeto será estudar e detalhar as de-
finições básicas do produto, definidas na Minuta do Projeto. O resultado final será um documento que sintetiza
as características e funções do produto, o Escopo do Produto. A Figura 5.6 resume a atividade.
CAPÍTULO 5

Planejamento do Projeto 159

Figura 5.6 Atividade de definição do escopo do produto.

O documento Escopo do Produto (a saída na Figura 5.6) é composto por uma lista das características e fun-
ções que o produto deverá apresentar, e que o respectivo projeto deverá criar. Elas se relacionam diretamente
com as características do projeto, mas o gerente de projeto não irá se preocupar com elas nesse momento (veja o
Quadro 4.4). A idéia implícita no modelo é a de trabalhar sistematicamente, entendendo, primeiro, qual o pro-
duto que se espera criar com o projeto; antes de investir tempo no “como”, isto é, na definição das estratégias
para o desenvolvimento do projeto, assunto esse que deverá ser tratado na próxima atividade.

Quadro 5.4 Escopo do Produto versus Escopo do Projeto

Em projetos de desenvolvimento de produtos, devemos tomar bastante cuidado para nunca confundir o Escopo do Pro-
duto com o Escopo do Projeto. Todo o projeto é algo que possui começo, meio e fim bem definidos. Para definir, então, o es-
copo do projeto, é fundamental descrever o método de realização, os interessados, prazos e várias informações relevantes.
Uma delas é o produto que será obtido com o projeto, em outras palavras, o escopo do produto.
No caso de um projeto de produto físico, isso significa definir metas que o produto deverá atender quando pronto.
Embora o escopo do produto seja fundamental para caracterizar um projeto, ele não diz como o resultado será obtido, isto
é, as atividades, responsáveis, recursos, tempo e várias outras informações que fazem parte do escopo do projeto.
Uma definição mais formal é a seguinte:
• Escopo do Produto: é composto pela especificação técnica que descreve o conjunto de funcionalidades e o desem-
penho desejado para o produto.
• Escopo do Projeto: define o conjunto de trabalhos que serão executados para construir e entregar o produto ou pro-
dutos do projeto. O escopo do projeto contém, em um de seus itens, uma descrição sucinta do escopo do produto.
Uma observação final é que escopo do produto e o escopo do projeto são interdependentes e devem ser integráveis, isto
é, se houver mudanças em qualquer um deles, então, é preciso avaliar o outro em busca de possíveis impactos e necessi-
dades de mudanças.

O procedimento para construir o escopo do produto é simples: reuniões entre o gerente de projeto e os es-
pecialistas em diversas áreas, que auxiliarão na complementação e validação das características e funcionalidades
do produto. O gerente de projeto terá como base as informações provenientes do portfólio e da Minuta do Pro-
jeto, e poderá utilizar como referência escopos de produtos similares.
160 PARTE 2 O Modelo

Como resultado da atividade, deverão ser definidos os parâmetros básicos que caracterizam o produto (o
que é o produto) e as funcionalidades que dele se espera (para que serve o produto), de forma a se ter uma clara
compreensão do que será fornecido ao cliente. Esses parâmetros devem ser preferencialmente quantitativos e
devem apresentar metas claras e inequívocas, mesmo quando qualitativos. Por exemplo, para um produto de
bem de consumo durável como um eletrodoméstico, o espaço que os clientes dispõem para armazená-los em
casa é crucial na decisão de compra. Portanto, um dos parâmetros básicos para se entender o produto do projeto
certamente será sua dimensão ou volume. Um erro que pode ser cometido é definir o projeto de maneira gené-
rica, tal como “volume pequeno”. Essa descrição não quer dizer nada porque o significado de pequeno é relativo
e varia de pessoa para a pessoa. O ideal é definir já um valor, tal como deve ocupar um volume máximo de 30cm
de altura, 20cm de largura e 20cm de profundidade.
Uma dúvida que pode surgir é a seguinte: como o gerente de projetos define esse valor sem consultar o
cliente? Na verdade, esse valor será estabelecido de acordo com as análises dos produtos concorrentes, tendên-
cias de mercado e o comportamento conhecido atualmente do consumidor. Segundo o modelo unificado, essas
informações foram levantadas na fase de planejamento estratégico, compiladas e já deverão estar disponíveis
para o gerente desse projeto. Aliás, não apenas para esse gerente de projeto, mas para todos os demais, o que per-
mitirá diluir entre os projetos os esforços de prospecção mercadológica e tecnológica realizados na etapa ante-
rior. Essas informações foram utilizadas para definir o portfólio e distinguir cada um dos produtos presentes.
Na próxima fase, projeto informacional, essa definição de tamanho, por exemplo, será validada e aprimo-
rada, agora, sim, com base em dados de campo sobre o público-alvo específico do produto em questão. O resul-
tado das pesquisas indicará se essa meta prevista inicialmente é realista, válida ou se deverá ser alterada. Além
disso, muitas outras características e funções serão acrescentadas, pois, nesse momento, no Planejamento do
Projeto, o gerente estará se preocupando com os parâmetros (características e funções) básicas do produto,
apenas àquelas suficientes para discriminar claramente dos demais do portfólio e permitir o Planejamento do
Projeto.
Portanto, a descrição presente no atual Escopo do Produto será profundamente avaliada, validada e deta-
lhada na próxima fase, quando haverá uma análise mais completa e intensa empregando-se várias técnicas, além
da pesquisa de mercado, tais como: a análise de decomposição do produto, a análise e engenharia do valor, a aná-
lise de funções e o desdobramento da função qualidade.
O gerente de projetos, de acordo com a necessidade, poderá se antecipar empregando princípios básicos
dessas técnicas já durante a definição dessa primeira versão do escopo do produto. Outra prática interessante é
utilizar uma mesma checklist para ambas as atividades: no planejamento e no projeto informacional. Um exemplo
é apresentado no Quadro 6.4, do Capítulo 6. O gerente de projeto poderá consultá-lo para verificar se não falta
algum parâmetro básico que ajude a descrever o produto.

5.4 Definir escopo do projeto


Uma vez entendido qual é o produto, ou produtos, do projeto, será preciso definir as características que de-
limitam o conteúdo do trabalho. São as características que descrevem “como” o produto será obtido, premissas
assumidas, pessoas envolvidas, entre muitas outras. Essa atividade é apresentada sinteticamente na Figura 5.7 e é
a base para todo o Planejamento do Projeto. A entrada principal é o Escopo do Produto e a saída é o documento
Declaração do Escopo do Projeto.
Para a construção da definição do escopo do projeto são utilizadas informações do escopo e da descrição do
produto, e uma definição inicial de restrições e premissas que o projeto precisa respeitar. Essas informações
provêm, basicamente, do escopo do produto, além da Proposta do Produto (Minuta do Projeto ou Project
Charter), produzida na fase anterior. Assim como o escopo do produto, essas características precisam ser des-
critas de uma forma clara e sem ambigüidades, preferencialmente com metas quantitativas.
Para a realização da definição e conseqüente planejamento do escopo, devem ser empregados alguns proce-
dimentos nessas informações de entrada da atividade.
CAPÍTULO 5

Planejamento do Projeto 161

Figura 5.7 Atividade de definição do escopo do projeto.

Um dos procedimentos mais empregados é a análise de custo/benefício, que envolve verificar custos tangí-
veis e intangíveis e benefícios das várias alternativas do projeto. Técnicas de estímulo de discussão em grupo
também podem ser empregadas para gerar diferentes alternativas e abordagens do projeto, tais como o brainstor-
ming (“tempestade” de idéias) e o lateral thinking (pensamento lateral).3 Por fim, em complemento a esses proce-
dimentos, uma outra opção é uma avaliação por especialistas dessas informações de entrada.
Com o andamento do projeto, na macrofase seguinte de desenvolvimento do produto, modificações
podem se fazer necessárias em seu escopo, de forma que a sua declaração provavelmente passará por revisões e
refinamentos que reflitam essas mudanças. Tais modificações fazem parte da gestão do escopo e a possibilidade
de ocorrerem, dadas as características do projeto, devem ser previstas na construção de sua definição. Essas mu-
danças podem se dirigir tanto no sentido de uma ampliação da definição do escopo do projeto como para uma
redução de sua abrangência.
Entre as definições do escopo do projeto, é fundamental a definição do processo de gestão do escopo, ou
seja, as atividades que garantam um controle de todas as alterações realizadas nesse documento. É preciso ga-
rantir que qualquer alteração tenha seus impactos avaliados e sejam aceitas de comum acordo por todos os en-
volvidos no projeto. O controle das mudanças do escopo deve estar integrado aos demais controles do
Planejamento do Projeto, que serão descritos nas próximas atividades, tais como: prazos, custos, qualidade etc,
dado que a modificação de uma dessas variáveis afeta as demais assim como os objetivos do projeto.
A definição de escopo do projeto também deve deixar claras as justificativas ou razões pelas quais o projeto
deve ser realizado. Posteriormente, na próxima atividade, essa definição será utilizada para a elaboração de uma
declaração escrita do escopo do projeto. Em síntese, ao final dessas duas atividades intrinsecamente relacio-
nadas, o Planejamento do Projeto terá sua declaração do escopo e o seu plano de gerenciamento.
Uma boa prática, semelhante à descrita no tópico anterior, é criar um modelo de documento que auxilie o
gerente de projeto, para evitar esquecimentos ao se preparar o escopo do projeto. Esse documento é apresen-
tado na Figura 5.8, no Quadro 5.5.
A definição do escopo do produto e a do projeto, preparadas durante as atividades anteriores, são utilizadas
para a elaboração de um documento formal denominado de Declaração do Escopo do Projeto (observe a Figura
5.9). Esse documento é conhecido no meio empresarial por outros nomes, entre eles Declaração do Trabalho
(Statement Of Work – SNOW).

3
Consulte os métodos de criatividade descritos no Capítulo 6.
162 PARTE 2 O Modelo

Quadro 5.5 Checklist do Escopo do Projeto

A lista a seguir apresenta um conjunto de itens que podem fazer parte da descrição do escopo do projeto.
Título do projeto.
Apelido do projeto. Definir o apelido do projeto é uma prática que facilita a comunicação.
Contexto. Informações sobre como o projeto surgiu, pessoas envolvidas e motivações principais. Descrever se esse pro-
jeto está inserido em um projeto mais amplo, discutindo qual o contexto. Sempre que possível, deve-se contextualizar esse
projeto dentro da estratégia de produtos da empresa.
Justificativa. Apresenta os requisitos do negócio aos quais o projeto deverá atender. Deve-se contemplar os requisitos
do ponto de vista de todos os interessados e da comunidade em geral.
Objetivos. Serve para dar uma visão ampla do que se deseja conseguir com esse projeto, pensando em um leitor “leigo”
no assunto.
Partes Envolvidas (interessados). Lista das pessoas/instituições que podem ser afetadas com a realização desse projeto.
Incluem os clientes, outras áreas, instituições governamentais, dentre outras.
Equipe Responsável/Organização. Definição dos times e especialistas responsáveis pela condução do projeto. É pre-
ciso definir seus papéis, contribuição (qual o conhecimento/experiência que cada um possui e que contribui para o sucesso
do projeto) de cada um e suas responsabilidades. Além do organograma do projeto, uma forma fácil de realizar essa defi-
nição é criando uma matriz de responsabilidades e dedicação, como no exemplo a seguir:

Figura 5.8 Matriz de responsabilidades e dedicação da equipe de projeto.

Lista de Produto(s) do Projeto/Metas. Descreve o resultado final do produto do projeto, na visão do cliente. Em caso de
projetos de desenvolvimento de produto, os produtos podem ser: as especificações do produto, o ferramental para pro-
dução, protótipos, documentação que acompanha o produto (manuais), até mesmo uma nova fábrica que irá produzi-lo.
Deliverables (subprodutos ou produtos intermediários). Descreve os resultados intermediários que se pretende atingir
com esse projeto. Um deliverable pode ser algo físico (protótipo, por exemplo) ou um determinado estado final de algo que
já existe (linha de produção pronta para ser produzida).
Embasamento Teórico/Referências. Contém a lista de referências do material bibliográfico utilizado. Normalmente,
esse item cita um anexo mais extenso ou um outro trabalho relacionado.
Premissas, Limitações e Restrições. Definição das “verdades” a serem adotadas para a realização do projeto. São as afir-
mações que deverão ser assumidas como verdadeiras durante o planejamento e execução. (Exemplo: o módulo de acaba-
mento do equipamento será o mesmo do projeto 178). Ou, então, das listas dos limites do presente projeto (aquilo que ele
não pretende atingir) e condições que restringem a sua realização.
Estratégias. Definição das estratégias genéricas para a realização do projeto, quando for o caso. Por exemplo, serão con-
tratados serviços de terceiros, serão realizadas reuniões semanais, o time ficará totalmente dedicado a esse projeto etc.
Metodologia. Descreve métodos ou padrões de processos de desenvolvimento que serão adotados como referência.
Prazos Máximos a Serem Atingidos. Prazos máximos para a entrega dos principais produtos e subprodutos (deliverables).
Custo e Preço-Meta. Valores-meta para custos do projeto que deverão ser respeitados.
Plano de Gerenciamento do Escopo. Definição de como o projeto será controlado e de como as mudanças serão solici-
tadas, avaliadas e implementadas, incluindo quem será o responsável e como as mudanças serão aprovadas.
CAPÍTULO 5

Planejamento do Projeto 163

Uma Declaração do Escopo completa deve conter:


Preparar o documento de
n a justificativa do projeto e os requisitos do negócio aos quais pretende Declaração do Escopo
atender;
n uma descrição sucinta do produto que será gerado no projeto;
n os objetivos do projeto colocados em termos quantificáveis, especialmente quanto a parâmetros de
custo, cronograma e medidas de qualidade;
n o conjunto de premissas e restrições identificadas; e
n um plano de gerenciamento do escopo, que descreve como esse escopo será gerenciado e como as mu-
danças que vier a sofrer serão incorporadas ao projeto.

Enfim, o gerente de projeto terá em mãos uma lista com as características do produto e do projeto, respecti-
vamente, o escopo do produto e a Declaração do Escopo. O problema é que ambas são informações textuais e
analógicas, dependentes de interpretação. Por isso, será necessária uma nova atividade, o detalhamento do es-
copo do projeto.

5.5 Detalhar o escopo do projeto


Embora ofereça precisão, o formato de texto utilizado na Declaração do Escopo é árido e dificulta a ob-
tenção de uma visão sintética e mais precisa de todo o trabalho necessário. Portanto, será preciso uma nova ativi-
dade, denominada Detalhar o Escopo do Projeto, que é apresentada esquematicamente na Figura 5.9. As
entradas principais são a Declaração do Escopo do Projeto e o Escopo do Produto.

Figura 5.9 Atividade de preparação da Declaração do Escopo.

A atividade Detalhar Escopo do Projeto tem os seguintes propósitos:

n uma melhor precisão de estimativas de custos, tempos e recursos;


n a definição de padrões mais objetivos para medir e controlar o desempenho; e
n por fim, uma atribuição mais clara e precisa de responsabilidades.
164 PARTE 2 O Modelo

O detalhamento do escopo deve ser realizado por meio de um recurso denominado Estrutura de Decom-
posição do Trabalho (EDT), que desmembra o projeto em suas partes componentes e elementos. Esse procedi-
mento é bastante conhecido também pela sigla em inglês: WBS, Working Breakingdown Structure. O modelo
unificado prescreve o uso dessa técnica e, por isso, a saída dessa atividade, na Figura 5.10, é a EDT.
Nessa técnica, todo o trabalho necessário no projeto, definido analiticamente
Preparar a Estrutura de na forma de texto, será decomposto em três tipos de elementos e suas relações: pro-
Decomposição do
Trabalho (EDT)
dutos do projeto, deliverables (entregas) e pacotes de trabalho (veja o Quadro 5.6).

Quadro 5.6 Definição de EDT (WBS)

A Estrutura de Decomposição do Trabalho (EDT) é uma forma de decompor e agrupar os componentes do projeto, de ma-
neira orientada aos resultados (deliverables e produtos) e que define o escopo completo do projeto (PMI, 2000, p. 59). A de-
composição é feita em três tipos de elementos, em uma abordagem de cima para baixo (top-down). Os elementos básicos da
EDT são:
• Produtos do projeto. É formado pelos resultados finais do projeto na linguagem dos clientes e, portanto, em um nível
alto de abstração. No caso de projetos de desenvolvimento de produtos, pode ser a especificação do produto, protó-
tipo, chão de fábrica preparado etc. A definição do produto se faz com metas abrangentes de especificação.
• Deliverables (entregas ou resultados importantes). Cada produto do projeto é desdobrado em resultados tangíveis,
isto é, que podem ser observados, denominados deliverables (entregas). Eles podem ser físicos (um relatório, parte do
protótipo etc.) ou uma mudança de estado verificável (pessoas treinadas etc.). A característica fundamental dos delive-
rables é a capacidade de serem medidos e avaliados. Este termo foi mantido no idioma original por se popularmente
empregado desta forma nas organizações.
• Pacotes de trabalho. Representam um conjunto de atividades que precisam ser feitas para a obtenção de um delive-
rable ou produto do projeto.
• Atividade. É uma ação com verbo e substantivo que será programada e gerenciada no decorrer do projeto. Elas fazem
parte de um pacote de trabalho. Esse é o menor nível de planejamento. Ações mais detalhadas só serão significativas
para a pessoa que realiza a tarefa e não para o gerente e membros da equipe de projeto.
A EDT não é apenas a identificação dos elementos do projeto, mas, também, a relação de pai e filho entre eles. Ela deve ser
descrita por meio de uma lista ou de um gráfico similar a um organograma, como mostra a Figura 5.10 a seguir.

Figura 5.10 Representação gráfica da EDT.


CAPÍTULO 5

Planejamento do Projeto 165

A elaboração da EDT deve ser iniciada pela identificação dos produtos do projeto. Eles formam o primeiro
nível, conforme demonstrado no Quadro 5.7. Em projetos de desenvolvimento de produtos, o principal pro-
duto é a especificação, mas podem existir outros como o projeto e construção de uma nova fábrica, a estrutu-
ração de um novo canal de vendas, entre outros, dependendo do projeto. Em seguida, são identificados os
deliverables e pacotes de trabalho de segundo nível, isto é, que juntos significarão a entrega do produto. É impor-
tante notar que o conjunto de elementos abaixo do produto precisa corresponder exatamente à entrega do pro-
duto. Note, no exemplo do Quadro 5.7, que o elemento Especificação do Produto, tomado isoladamente, é algo
abstrato, mas, analisando o segundo nível da EDT, é possível identificar o que ele representa exatamente — no
caso, o documento de requisitos, o produto homologado e o protótipo, só para citar parte do exemplo.
Percebe-se que esse trabalho de decomposição poderá ocorrer indefinidamente. Na prática, porém, des-
dobra-se, na atividade de detalhamento do escopo, somente os primeiros níveis da EDT, geralmente de 2 a 4 ní-
veis. Eles são suficientes para identificar os deliverables e pacotes de trabalho principais do projeto. A
identificação de todos os elementos, incluindo as atividades, se dará no momento de detalhar o planejamento,
isto é, de realizar a programação das atividades. Isso acontecerá na atividade Definir Atividades e Prazos e
também nas atividades genéricas recorrentes de “ajustar o plano do projeto”, no início de cada fase. O detalha-
mento no início de cada fase é mais comum, quando o projeto for grande e/ou complexo, conforme mencionado
no Tópico 3.2, no Capítulo 3. Pois seria improdutivo prever tudo o que acontecerá em detalhes, inclusive,
porque muitas ações dependem de resultados das primeiras fases. Assim, o esforço de planejamento investido,
no momento atual de definição de escopo, não seria produtivo em razão da imprecisão e dos riscos vindouros.
Assim, em projetos longos, planejam-se os primeiros níveis da EDT nessa atividade, detalham-se as fases iniciais
nas próximas atividades, e o planejamento detalhado das demais fases é delegado para antes do início de cada
uma delas.
A EDT é uma forma de apresentação adequada do projeto, pois é uma maneira didática e rigorosa de de-
monstrar todo o esforço que será necessário para a realização do projeto, a qual será a base do esforço de progra-
mação das atividades. Por isso, precisa ser realizada com atenção e cuidado. Não existe uma regra ou método
exato para a sua determinação. Depende de habilidade e prática. Mais que isso, da experiência da própria empre-
sa, que irá, com o tempo, identificar a melhor forma de dividir o trabalho, de acordo com as características de
seus projetos de desenvolvimento e a estrutura organizacional da empresa. Porém, algumas dicas podem auxiliar
no desenvolvimento e verificação da subdivisão.

Quadro 5.7 Cuidados para a Elaboração da EDT

As principais diretrizes para a elaboração de EDTs são:


1) Cada elemento da EDT deve ser claramente definido e estar relacionado a um resultado (produto ou deliverable) único
(propriedade de independência).
2) Cada elemento de um nível superior da WBS deve significar o resultado da agregação dos resultados de todos, e tão-so-
mente, dos níveis inferiores.
3) Cada elemento-filho deve se relacionar com um único elemento-pai.
4) Todos os deliverables do projeto devem estar incluídos na WBS.
5) O número de elementos de um mesmo resultado deve ser planejado de maneira tal que (veja a Figura 5.11):
• Situação A — O número de atividades destinadas a um resultado (produto) não seja tão grande que torne impossível
para uma pessoa gerenciar aquele resultado.
• Situação B — O número de atividades que compõem um deliverable não pode ser tão pequeno que gere mais delivera-
bles no projeto do que o gerente seja capaz de controlar.

(continua)
166 PARTE 2 O Modelo

Quadro 5.7 Cuidados para a Elaboração da EDT (continuação)

Figura 5.11 Exemplos gráficos de EDTs inadequadas.

Fonte: Project Management Institute. Practice standards for working-breaking-down structure. Newton square-Pennsylvania : PMI, 2001.

Uma vez preparada a EDT, a Declaração do Escopo do Projeto estará pronta.


Preparar versão final da E se transformará no documento que guiará todas as demais atividades de Planeja-
Declaração do Escopo mento do Projeto (veja o Quadro 5.8).

Quadro 5.8 Importância da Definição do Escopo

A Figura 5.12, proposta pelo PMI, demonstra a importância da definição do escopo do projeto. Ela representa esquemati-
camente o relacionamento entre os processos de definição do escopo e os demais processos da Gestão de Projetos, con-
forme definidos pelo PMI. Note que ela servirá de base para praticamente todo o Planejamento do Projeto.
Figura 5.12 Relacionamento entre a definição do escopo e a EDT com as atividades de planejamento do projeto.

Fonte: Baseado em PMI Standards committee. Project Management Body of Knowledgement. Pennsylvania: Project Management Institute Pu-
blication, 2000. Disponível em: <http://www.pmi.org>. Acesso em: 20 de março de 2001. Tradução própria.

Dada a importância da Declaração do Escopo, é fundamental revisá-la até que se garanta um bom nível de
maturidade, em que a probabilidade de erros seja pequena. Consulte o Quadro 5.9 para uma lista dos erros mais
CAPÍTULO 5

Planejamento do Projeto 167

comuns na preparação da Declaração do Escopo do Projeto. Uma boa prática é criar um modelo de documento
contendo os títulos de todos os possíveis tópicos.

Quadro 5.9 Erros Comuns na Preparação da Declaração do Escopo do Projeto

Um erro na confecção da Declaração do Escopo pode trazer conseqüências sérias para um projeto de desenvolvimento
de produtos. Devemos sempre ter em mente que a Declaração do Escopo é elaborada para “selar o pacto” entre a pessoa que
está assumindo o papel de gerente de projeto e os interessados. Um erro, mesmo que mínimo, pode levar a divergências de
interpretação com impactos significativos. Os erros mais comuns são:
• Documentos desorganizados. O primeiro passo para garantir uma boa Declaração do Escopo é a utilização de boas
práticas de organização do texto. Utilizar subitens numerados, separar os tópicos, dispô-los em uma seqüência lógica,
incluir sumário e, quando extenso, incluir índices remissivos e analíticos são exemplos disso. Um erro comum é mis-
turar os diversos elementos (especificações, aprovações e instruções especiais), tornando-o árido, inconsistente e im-
possibilitando análises críticas. Além de evitar os demais erros, faz com que o interessado deixe de notar aspectos
específicos do projeto ou incoerências que levem a interpretações dúbias.
• Imprecisão terminológica. Definições conceitualmente erradas, termos utilizados de maneira inadequada, termos
vagos (como “aproximadamente”, “etc.”, “vários” e outras) e frases com duplo sentido são exemplos de imprecisão ter-
minológica. Ela acontece quando a mensagem fica prejudicada pelo desconhecimento ou uso errado dos termos.
Avalie sempre se os termos utilizados no texto têm o mesmo significado para todos os interessados no projeto.
• Falta de padronização no tamanho das tarefas e resultados. É comum a definição e mistura de atividades e resul-
tados muito distintos. Isso significa que algumas delas podem estar com níveis muito diferentes de abstração. Na prá-
tica, isso leva a uma série de sobreposições que podem esconder erros. Deve-se esforçar para garantir o máximo de
padronização e coerência.
• Falha na solicitação de revisão por terceiros. A pessoa que está preparando o documento de Declaração do Escopo
geralmente tem uma limitação de nível de conhecimento, isto é, é especialista em parte do projeto. Um erro comum,
principalmente em projetos complexos, acontece quando ele julga sua própria experiência como suficiente. A proba-
bilidade de erros aumenta, principalmente nas áreas na qual ele tem um conhecimento técnico menor. Por isso é uma
boa prática submeter o documento para a revisão de especialistas nas diversas áreas para que verifiquem os termos
empregados e garantam a clareza.

5.6 Adaptar o modelo de referência


Definidas as atividades anteriores do planejamento, fica mais claro qual é o escopo do produto e principal-
mente do projeto. A partir desses resultados, e das características do modelo de referência específico adotado na
empresa para seu PDP, pode-se, na presente atividade (Figura 5.13), realizar as devidas adaptações nesse mo-
delo, de forma a que venha a ser utilizado para o projeto de novo produto em questão.
Conforme explicitado no Capítulo 2, um modelo de referência pode ser utilizado como base para a criação
de outros modelos ou para a definição de projetos. Alguns modelos são criados para adequar-se a necessidades
genéricas, tais como as de um setor, tecnologia etc. Quanto mais genérico, maior é o trabalho de adaptação do
modelo, pois as práticas, ordem das atividades, soluções e documentos propostos são elaborados para atender à
necessidade geral de todas as empresas dessa categoria. O ideal é que a empresa possua o seu próprio modelo de
referência. Esses modelos mais gerais são interessantes porque, a partir deles, chega-se ao modelo de referência
específico para uma determinada empresa, de acordo com a sua realidade particular, assunto que será tratado no
Capítulo 15. O Planejamento do Projeto parte desse modelo específico, adaptando-o conforme a necessidade de
cada projeto de desenvolvimento de produtos da empresa.
Note, porém, que, mesmo dentro de uma única organização, os projetos de novos produtos podem variar
bastante em termos de complexidade. Existem desde projetos mais simples, que envolvem pequenas variações de
produtos existentes, até projetos que geram uma nova categoria ou tipo de produto — alguns deles incluindo
projetos de novas fábricas. Por isso, mesmo o modelo de referência de uma empresa deve ser flexível o suficiente
para atender às necessidades desses diferentes projetos. O primeiro passo para realizar essa personalização é
168 PARTE 2 O Modelo

identificar as características do projeto. Isso deve ser feito por meio de uma tipologia de projetos cuidadosamen-
te elaborada e específica da empresa. Ao se classificar o projeto dentro dos diferentes tipos, ter-se-á uma boa
noção das mudanças em relação ao projeto.

Figura 5.13 Atividade de adaptação do modelo de referência.

Normalmente, os projetos podem ser classificados em quatro tipos básicos quanto à inovação tecnológica e
esforço:4

n Um projeto do tipo radical é aquele que resultará em um produto totalmente novo para a empresa e, al-
gumas vezes, totalmente novo para o mercado. A inovação pode estar também no processo de fabri-
cação, isto é, quando o processo de fabricação é totalmente novo para a empresa ou mesmo para o
mercado. Eles não ocorrem com muita freqüência no DP de uma empresa, e o Time de Projeto deverá
utilizar o modelo de referência unificado em sua completude, isto é, todas as fases e atividades. Além dis-
so, dadas as características desse tipo de projeto, deve-se considerar a necessidade de uma maior inte-
gração do modelo com o setor ou processo de P & D da empresa (os ajustes e adaptações no modelo
específico, necessários para seu uso nesse tipo de projeto radical, são comentados no Capítulo 16).
n Em um projeto do tipo plataforma, isto é, naquele em que o produto não é totalmente novo para a em-
presa, mas terá mudanças significativas na concepção. Significa a adoção de novas soluções na arquite-
tura do produto, originando uma nova plataforma, isto é, um novo conjunto básico de componentes que
será reutilizado nas próximas gerações de produtos derivados da plataforma. Nesse caso, o modelo do pro-
cesso de desenvolvimento será também utilizado na íntegra, incluindo todas as suas fases e atividades.
n Para um projeto derivado de uma plataforma, o objetivo é criar um produto adicional em uma linha,
que deverá ser baseado em uma plataforma ou produto previamente desenvolvido e em produção. Em
geral, as fases e atividades iniciais da macrofase de desenvolvimento podem ser simplificadas, pois a con-
cepção do produto não terá modificações profundas.

4
Esses tipos foram discutidos brevemente no Capítulo 1, e agora são descritos com maiores detalhes.
CAPÍTULO 5

Planejamento do Projeto 169

n Por fim, para um projeto do tipo follow source, além de simplificações de fases e atividades, pode mesmo
ocorrer a eliminação da fase de projeto conceitual, pouco relevante para as características desse tipo de
projeto.

Outros parâmetros podem ser utilizados nessa tipologia, além do grau de inovação. Deve-se escolhê-las
identificando as características do projeto que mais afetam a maneira de gerenciar os produtos. Por exemplo, em
produtos sob encomenda para a indústria metal-mecânica pesada, por exemplo, o volume ou tamanho de uma
peça pode ser um fator determinante, dado que, em peças grandes, haverá necessidade de um cuidado especial
nas atividades de planejamento da logística e instalação dos produtos, desnecessários em produtos menores.
Exemplos de parâmetros que podem ser utilizados são complexidade dos produtos e relacionamento com outros
projetos da empresa.
No modelo de referência de PDP apresentado neste livro, a primeira tarefa
dessa atividade é a classificação do projeto. O modelo prevê uma classificação com- Classificar o projeto
binando dois dos tipos mais utilizados: o grau de complexidade do produto/projeto
e o seu grau de inovação, tomando-se como base informações provenientes das declarações de escopo, resul-
tantes das atividades anteriores do planejamento.
A primeira variável, novidade, mede quanto há de peças novas no produto. A segunda variável, complexi-
dade, mede a quantidade de peças e/ou o seu agrupamento no produto.
Em termos mais objetivos, a determinação do grau de novidade em um produto pode ser avaliado pela por-
centagem de itens ou partes na BOM (Bill Of Material, Estrutura do Produto) desse produto que não foram uti-
lizados antes em outro produto da empresa (se esse produto for um software, refere-se às novidades introduzidas
no código fonte).
Já o grau de complexidade deve ser avaliado por uma composição de indicadores, como o tempo gasto para
projetar esses itens ou partes e combiná-los no produto, a necessidade de pessoas e conhecimentos para isso, os
tempos e recursos necessários para a manufatura e montagem desses itens ou partes etc. Comparando-se os re-
sultados desses indicadores com o obtido em outros produtos da empresa, é possível obter uma perspectiva do
grau de complexidade do produto em questão. Se o produto for um software, o mesmo raciocínio, com as devidas
adaptações, deve ser aplicado à realização de seu código-fonte.
Com isso, ficam evidentes as adaptações que serão necessárias no modelo de referência específico do PDP
da empresa, de forma a melhor utilizá-lo para o projeto em questão.
A adaptação desse modelo específico para o escopo e as características do presente projeto de DP em plane-
jamento devem considerar quais e como devem ser realizadas as atividades e tarefas de cada uma das seis fases do
desenvolvimento do produto: o projeto informacional (que gera as especificações-meta do produto); o projeto
conceitual (que chega às concepções do produto); o projeto detalhado (que apresenta as especificações finais do
produto); a preparação da produção (que prepara e libera o projeto para a produção); e, finalmente, o lança-
mento do produto. A próxima tarefa aborda essa realização das fases do desenvolvimento, para os tipos de pro-
jetos anteriormente descritos — exceto o radical, que, em razão de suas particularidades, será abordado no
Capítulo 16.
A Figura 5.14 ilustra, a partir da avaliação conjunta da complexidade e ino-
vação do produto/projeto em questão, quatro versões adaptadas do modelo de refe- Adotar versão adaptada
do modelo específico
rência específico, diferenciando-as conforme a ênfase com que serão tratadas as
fases do desenvolvimento do produto. O comprimento de cada fase na Figura 5.14
(nominalmente citadas e numeradas na primeira versão e apenas numeradas nas outras três) indica o nível de es-
forço gasto durante o projeto. Um grande esforço significa realizar todas as atividades da fase e aplicar todas as
técnicas.
170 PARTE 2 O Modelo

Figura 5.14 Versões do modelo de referência específico.

Em seguida, descreve-se cada uma das versões, da parte superior para a inferior da Figura 5.14, ou seja, da com-
plexidade/novidade maior para a menor do produto/projeto, o que, em conseqüência, significa ir da mais completa
versão para a mais simplificada, em termos de realização das atividades e fases do desenvolvimento do produto.
Uma primeira versão é o modelo específico praticamente completo ou plenamente utilizado pelo projeto
de DP, em termos do emprego na sua execução das cinco fases e suas respectivas atividades. Esse modelo com-
pleto é empregado no caso de projetos de produtos complexos e ao mesmo tempo inovadores, muitas vezes para
explorar um novo segmento de mercado em que a empresa ainda não atuava ou não tinha um produto adequada-
mente direcionado para isso. Esse caso é típico quando ocorre o desenvolvimento de uma plataforma de produto
totalmente nova, diferente de qualquer outra que a empresa já desenvolveu, inaugurando uma nova família de
produtos na empresa (embora não necessariamente no mercado, pois já podem existir produtos pioneiros con-
correntes), de onde é esperado o surgimento de muitas derivações futuras. Poderia ser citado, a título de
exemplo, a entrada de uma montadora de automóveis, com um veículo totalmente novo, o primeiro da plata-
forma, em um determinado segmento do mercado em que não atuava. Deve-se notar que, embora todas as ver-
sões estejam com o mesmo tamanho, para deixar clara a ênfase, esses tipos de projeto normalmente têm duração
muito maior que os demais tipos.
Em uma segunda versão, há uma relativa simplificação do modelo de referência específico. Se comparada à
versão anterior, possui como características diferenciais um planejamento de projeto menos detalhado e simpli-
ficações nas fases do desenvolvimento. Destaca-se como diferenças o projeto informacional e conceitual que
podem ser tratados como uma única fase, além do projeto detalhado e da preparação da produção, que são redu-
zidos com várias de suas atividades e tarefas simplificadas, agrupadas, ou mesmo sem necessidade de execução.
Essa versão do modelo de referência específico é especialmente aplicável em situações em que o produto/projeto
não apresenta ao mesmo tempo complexidade e inovação altas. Apenas uma dessas duas dimensões é alta, ou,
então, ambas estão em um patamar intermediário. Normalmente, esse contexto é encontrado no projeto de uma
nova plataforma, em substituição a uma plataforma que a empresa descontinuará. Ou seja, uma nova família de
produtos, mas em um segmento que a empresa já atua e, portanto, conhece bem. Também essa versão do mo-
delo pode ser a mais adequada quando há o desenvolvimento dos principais derivados, de uma plataforma de
produto totalmente nova (desenvolvida seguindo a primeira versão, como já explicado).
CAPÍTULO 5

Planejamento do Projeto 171

Como exemplo palpável, pode-se citar, na indústria automobilística, o desenvolvimento de uma nova plata-
forma de veículo, que ocorre regularmente após um conjunto de anos, no mesmo segmento e adotando o mesmo
nome comercial do produto que a empresa já produz. Pode-se nominalmente citar os casos mundiais do Toyota
Corolla e do VW Golf, que existem desde os anos 1970, porém, a cada período de alguns anos, são totalmente
remodelados com a criação de uma nova plataforma. Outro exemplo, nessa mesma indústria, é o desenvolvi-
mento das primeiras derivações, como uma nova station-wagon, ou uma nova van, a partir de uma plataforma de
produto totalmente nova para a empresa.
Sempre comparando com as anteriores, em uma terceira versão há uma grande simplificação do modelo de
referência específico. Como características dessa versão, além de um planejamento de projeto reduzido, há muitas
simplificações no desenvolvimento do produto. As fases de projeto informacional e conceitual permanecem
unidas e com menos atividades e tarefas do que na versão anterior. O projeto detalhado se mantém, mas a prepa-
ração da produção pode ser simplificada. O lançamento do produto, que nas versões anteriores mantinha-se in-
tegralmente idêntico ao do modelo de referência específico, passa a ser executado parcialmente. Como pode ser
observado na Figura 5.14, essa versão do modelo é aplicada em produtos/projetos em que as dimensões de com-
plexidade e novidade tendem para um patamar de intermediário a baixo. Esse é o caso de derivações usuais ou
convencionais a partir de plataformas de produtos já bem estabelecidas na empresa. Usando novamente a indús-
tria automobilística como exemplo, podem ser citados aqui alguns desenvolvimentos de produtos normalmente
encontrados nesse setor e que podem utilizar essa terceira versão: uma nova motorização de um veículo (porém,
se for um motor que exija grandes modificações no veículo, cabe a segunda versão do modelo); um face-lift ou
uma nova versão anual do veículo, que requer mínimas modificações do produto, mas com certo apelo mercado-
lógico; as séries ou edições especiais do veículo, que são derivações com certas mudanças de acabamento e espe-
cificações técnicas, que não requer grandes modificações do produto original para ser feita etc.
Por fim, há uma quarta versão do modelo de referência específico, em que são baixas tanto a complexidade
quanto a novidade do produto/projeto. Esse é o caso dos denominados follow source, por exemplo, um produto já
produzido pela matriz ou em outro mercado em que a montadora automotiva atua, e que é adaptado (“tropicali-
zado”, usando um termo mais comum nessa indústria), para lançamento no mercado brasileiro. Essa adaptação
envolve mínimas modificações e regulagens no produto, por exemplo, ajustes para receber os tipos de combus-
tível encontrados no Brasil e na suspensão para uso nas estradas brasileiras. Porém, pode existir muito a ser feito
no projeto do processo de fabricação e montagem, dada a necessidade de preparar uma planta nacional para a
produção local. Por essas características, a presente versão do modelo de referência específico normalmente dis-
pensa o projeto conceitual, que não faz sentido uma vez que o produto já está totalmente concebido. Possui um
projeto informacional reduzido, apenas para levantar certas especificidades do mercado local em relação ao pro-
duto já desenvolvido em outro país e que se pretende adaptar. O modelo concentra-se no projeto detalhado, e
principalmente na preparação da produção e lançamento do produto, retornando essas fases na presente versão
à mesma plenitude de realização das atividades e tarefas do modelo completo. Mesmo considerando-se que já há
uma planta em produção em outro país, que serve de referência para o projeto do processo de produção local do
produto, muitas diferenças existem e precisam ser consideradas. As fábricas, escalas de produção, processos pro-
dutivos, fornecedores, colaboradores, entre outras condições, são diferentes e requerem que muitos trabalhos
dessas fases do projeto sejam refeitos para as novas condições encontradas na planta.
Importante ressaltar que essa quarta versão é aplicável a situações em que um produto que se pretende
lançar no mercado nacional já foi desenvolvido plenamente, e mesmo está em produção, em um outro local. Há
situações em que a complexidade e/ou a inovação do produto/projeto são maiores, quando a unidade brasileira
de uma multinacional participa do desenvolvimento original do produto na matriz, pois foi planejado que esse
será lançado também no Brasil, podendo ser quase simultaneamente ao lançamento mundial. Nesses casos, faz
sentido aplicar a segunda ou a terceira versão do modelo, dependendo das particularidades do projeto do pro-
duto em questão.
As quatro versões anteriormente apresentadas não pretendem ser possibilidades absolutas de classificação do
modelo de referência específico da empresa em relação à complexidade/inovação dos produtos/projetos da empre-
sa. Antes disso, são os principais patamares de uma escala imaginária de mais para menos complexidade e inovação.
Diversas readaptações dessas versões são possíveis, conforme a realidade encontrada em cada empresa e indústria.
172 PARTE 2 O Modelo

O modelo de referência apresentado no presente livro, no Apêndice I, é o da versão mais completa, com
todas as fases/atividades/tarefas. Trata-se de uma indicação, cabendo a cada empresa julgar quanto essas esco-
lhas são pertinentes para suas situações de desenvolvimento de produtos.
Na realização de um Planejamento do Projeto de DP, após a realização da pre-
Identificar necessidades sente atividade, fica a empresa ciente de qual será a versão do modelo adotada para o
de mudanças produto/projeto em questão. Sendo assim, cabe à empresa e especialmente aos en-
volvidos com o planejamento do DP passar a realizar as próximas atividades desse
planejamento considerando a especificidade que ocorrerá nas fases seguintes do desenvolvimento, delimitadas
pelo modelo que foi escolhido. Em outras palavras, cabe aos planejadores da empresa, ao realizar as próximas
atividades do planejamento, se concentrar naquelas atividades do desenvolvimento de produto que fazem parte
do modelo escolhido.
Deve-se lembrar também que há casos especiais em que o projeto se enquadra em um dos tipos da empresa,
mas com algumas exceções em termos de atividades. Utilizando o exemplo de categorização do modelo unifi-
cado, pode-se ter um projeto que é follow source, mas que precisa ser testado no mercado. Nesse caso, além do
foco nas atividades de detalhamento, preparação da produção e lançamento, o projeto poderá incluir atividades
da fase do projeto informacional. Outro exemplo é o caso de um produto que utilizará um mesmo canal de
vendas de outro produto, substituindo sem muitas novidades para clientes e assistência técnica. Nesse caso, a
fase de lançamento pode ser suprimida ou unida com a de preparação da produção.

5.7 Definir atividades e seqüência


A presente atividade é o detalhamento das atividades para a execução do projeto (veja a Figura 5.15). O ob-
jetivo dessa atividade é planejar todas as ações que precisam ser executadas no projeto, isto é, identificar cada
uma delas e verificar o relacionamento. Se as atividades anteriores tiverem sido bem executadas, essa atividade
será bastante facilitada. O modelo de referência do PDP adaptado e a Declaração do Escopo do Projeto, juntos,
permitirão a programação das atividades, com probabilidade pequena de erros.

Figura 5.15 Definição de atividades e prazos.


CAPÍTULO 5

Planejamento do Projeto 173

A primeira tarefa é identificar as atividades. Na verdade, a partida para essa


ação já foi dada. Basta lembrar que, no final da atividade Preparar Declaração do Identificar atividades
Escopo do Projeto, Tópico 5.5, o gerente de projeto já especificou os primeiros ní-
veis da Estrutura de Decomposição do Trabalho (EDT). A identificação das atividades é realizada dando-se
prosseguimento a esse mesmo processo de decomposição da EDT, só que, agora, conta-se com o apoio do mo-
delo de referência na sua versão personalizada para o projeto.
O gerente de projetos decompõe a EDT transformando todos os deliverables e pacotes de trabalho em pa-
cotes de trabalho mais detalhados. Depois, com a ajuda do modelo de referência na versão personalizada, de-
comporá os pacotes de trabalho em atividades. Uma atividade pode ainda ser decomposta em um conjunto de
outras atividades. Quando isso acontece, denominamos a atividade-pai de atividade-resumo (veja o Quadro
5.10, para uma lista dos tipos de atividades), pois, para efeitos de controle e cálculos, seus parâmetros serão o re-
sultado do somatório das atividades-filho.

Quadro 5.10 Tipos de Atividades

Para fins de planejamento, as atividades geralmente são classificadas em três tipos:


• Atividade: é a definição de uma ação necessária para a execução do projeto, com o nível mais baixo de detalhe. Uma
atividade em um plano possui vários atributos, tais como: prazo, datas de início e fim, recursos humanos responsáveis,
duração etc.
• Atividade-resumo: é aquela composta por um conjunto de atividades. Seus parâmetros são dependentes das ativi-
dades-filho que a caracterizam. Sua duração, por exemplo, é determinada pela data mais cedo de início e data mais
tarde de término dentre todas as atividades-filho.
• Atividade-marco (milestone): é uma atividade inserida no planejamento e que recebe duração. Ela não afeta a progra-
mação e existe apenas como lembrete do fim ou início de um momento importante do projeto.

Atividade é o termo utilizado dentro da Gestão do Projeto para o último nível de detalhe da EDT. A identi-
ficação da atividade depende do nível de controle que se exercerá no projeto (veja o Quadro 5.11).

Quadro 5.11 Identificando as Atividades

A decomposição correta de todo o trabalho em atividades tem impacto em todo o planejamento e controle do projeto.
Não se engane, pois não é algo fácil de fazer. Depende de experiência, conhecimento profundo dos detalhes do projeto e
prática. O maior cuidado está em saber o momento adequado de parar o desdobramento, isto é, quando temos a atividade
(o menor nível do planejamento).
A dica a ter em mente é verificar o nível de controle que se espera realizar sobre o projeto na fase de execução, nem maior
nem menor. Se maior, o conteúdo da ação não ficará bem definido e o gerente de projeto terá dificuldade de especificar o es-
forço, como veremos adiante. Se menor, a lista ficará tão complexa e com detalhes tão irrelevantes que pode até mesmo
atrapalhar o controle do projeto. Um nível suficiente significa que a ação é definida inequivocamente e apresenta detalhes
suficientes para saber o que será feito na ação.
Por exemplo, se esperamos verificar o andamento das atividades semanalmente e a montagem do protótipo de uma má-
quina dura 4 horas, faz sentido parar nesse nível, sendo a atividade de menor nível chamada simplesmente de Montar protó-
tipo. O gerente de projeto, com essa informação, é capaz de controlar o andamento do projeto semanalmente e delegar essa
atividade. Caso estejamos falando de um grande equipamento que demora 60 dias para ser montado, utilizar essa mesma
atividade como último nível seria claramente inadequado do ponto de vista do gerenciamento. Pois, durante estes 60 dias, o
uso de muitos equipamentos, esforços e pessoas precisaria ser identificado e seqüenciado em detalhes — o que não será
possível com uma única atividade. Além disso, podem se passar até 12 semanas para identificar um problema. Nesse caso,
montar protótipo pode ser uma atividade-resumo, mas seria fundamental quebrá-la em subatividades para facilitar o plane-
jamento e controle, tais como: preparar galpão, montar estrutura etc.

(continua)
174 PARTE 2 O Modelo

Quadro 5.11 Identificando as Atividades (continuação)

Existem projetos em que há necessidade de controles muito finos; nesse caso, o nível de detalhes pode ser até maior, atin-
gindo horas. Por exemplo, existem produtos de bens de consumo, tais como: escovas de dentes, absorventes, hastes flexí-
veis e outros, que são produzidos em altíssimos volumes por equipamentos específicos, complexos e altamente informati-
zados. O custo da hora parada dessas máquinas é muito grande. Por outro lado, na introdução do produto na fábrica, ele terá
que ser parado e sofrer uma série de modificações para iniciar a produção piloto do novo produto. Nesse caso, um planeja-
mento detalhado de tudo que será feito, pelos diversos técnicos que participam do projeto, poderá fazer-se necessário. O di-
mensionamento dessas tarefas em dias seria inadequado. Teríamos que as programar detalhadamente, em horas, para
controlar a execução das várias atividades.
Outra dica é padronizar a escrita da EDT utilizando sempre verbo e substantivo para designar atividades e pacotes de tra-
balho. Utilize substantivos para designar deliverables e produtos. Pode parecer perfeccionismo, mas a facilidade de com-
preensão do plano aumenta significativamente com o uso de padrões simples de escrita.

Ações com nível de detalhe maior do que o adequado ao controle são comumente denominadas de tarefas,
com o intuito de distingui-las claramente das atividades. Atividade e tarefas são categorias de ações, mas é impor-
tante separá-las porque a tarefa traz informações irrelevantes do ponto de vista da Gestão do Projeto, pois NÃO se
destinam a auxiliar na atribuição e muito menos ao controle das atividades. As tarefas devem ser identificadas e
controladas pelo responsável pela atividade e, na grande maioria dos casos, não interessam ao gerente de projetos.
Agora fica fácil entender uma das grandes vantagens da empresa trabalhar com o conceito de processos de
negócio e utilizar modelos de referência dentro da empresa. O modelo de referência oferece ao gerente de pro-
5
jetos uma lista de todas as atividades possíveis, servindo como uma checklist e, ao mesmo tempo, facilitando a pa-
dronização das atividades. Aliás, a empresa pode ter um modelo de documento com essas listas em formato
digital, facilitando ainda mais a vida do gerente de projeto. Nesse caso, as atividades-padrão do modelo poderão
ser copiadas e modificadas. Uma ferramenta que faz a diferença são os softwares de Gestão de Projetos (consulte
o Quadro 5.12).
Normalmente, os primeiros níveis da EDT, identificados durante a prepa-
Os softwares de Gestão de ração da Declaração do Escopo, são registrados em um editor de textos padrão ou
Projetos apóiam o gerente em planilhas. Utilizar sistemas de Gestão de Projetos para completá-lo é vantajoso
de projetos nesta
atividade
porque as funcionalidades de edição de listas e geração de gráficos da EDT podem
ser úteis para lidar com a quantidade grande de atividades. Projetos simples chegam
a ter uma centena de atividades, mas há projetos complexos que podem atingir mi-
lhares delas. Outra razão, ainda mais forte, é que, conforme demonstrado no Quadro 5.12, esses sistemas auxi-
liam em uma série de análise. Uma das informações fundamentais para utilizar tais recursos é a lista de
atividades. Realizá-la direto no sistema irá, portanto, economizar um tempo precioso nos próximos passos, mo-
mento em que tais análises poderão ser realizadas.

Quadro 5.12 Softwares de Gestão de Projetos

O gerenciamento do projeto é uma atividade complexa formada por uma mistura de planejamento, tomada de decisões
e muita negociação. A qualidade e atualização das informações sobre o projeto são requisitos básicos para o gerente tomar
as melhores decisões. Um apoio fundamental é o das ferramentas computacionais conhecidas como softwares de Gestão de

(continua)

5
No modelo de referência unificado procurou-se utilizar a distinção entre atividade e tarefas apresentada neste texto. O nível descrito é
o que deve ser utilizado para controle, e o nível das tarefas descreve as atividades para os responsáveis pela sua execução. É lógico que
não se deve utilizar cegamente essa definição dessa referência, pois, dependendo das circunstâncias, tipo de produto, organograma da
empresa, entre outros, o nível descrito como de tarefa pode ser útil ao planejamento, devendo constar na EDT.
CAPÍTULO 5

Planejamento do Projeto 175

Quadro 5.12 Softwares de Gestão de Projetos (continuação)

Projetos. Esses sistemas automatizam os cálculos de tempo, utilização e nivelamento dos recursos e custos. Conseqüente-
mente, permitem criar cenários para avaliar diferentes alternativas e definir o melhor planejamento possível. Eles aumentam
a capacidade humana de monitorar as datas planejadas e compará-las com as datas reais. Em ambientes multiprojetos ou
projetos de altíssima complexidade, milhares de recursos humanos e prazos de anos, essas ferramentas são imprescindíveis.
Elas podem oferecer simulações que envolvem cálculos de diferentes durações de projeto ou análise de diferentes cenários
(análise what-if) — por exemplo: avaliar como o atraso ou o adiantamento de determinadas atividades em um projeto pode
afetar o cronograma de outros projetos que compartilham os mesmos recursos. Essas análises, entre outras, seriam bastante
dificultadas sem o uso desses softwares (PMBOK, 2000).
As funcionalidades típicas de um sistema de Gestão de Projetos são:
• Gestão de calendário e agenda: os sistemas permitem a organização e programação de calendários para o projeto,
recursos ou tarefas. A programação do calendário envolve definir o período de trabalho diário, dias de trabalho por se-
mana e eventuais feriados. As ferramentas mais sofisticadas permitem a criação de calendários-base com os dados da
empresa e a sua personalização para cada recurso específico, material ou humano. Um exemplo: se um determinado
fornecedor só pode trabalhar no período da tarde, o sistema permite criar um calendário específico para ele com essa
restrição.
• Gestão de atividades: os sistemas permitem registrar as atividades, visualizá-las e organizá-las em níveis. Permitem,
também, estabelecer diferentes tipos de precedência entre as atividades e representá-las na forma de rede de ativi-
dades, de Gráfico de Gantt e geração de EDT/WBS. Permitem buscas, filtros e outras facilidades para editar as tarefas e
definir dados básicos como esforço, duração, datas de início e fim e recursos alocados.
• Gestão de recursos: permitem o gerenciamento das pessoas e materiais necessários para o projeto. Permitem, ainda,
cálculos de disponibilidade, facilitam o acompanhamento do trabalho dos times e permitem diferentes padrões de
alocação nas atividades. Os sistemas mais avançados possuem algoritmos para realizar o nivelamento dos recursos e
são capazes de gerar diferentes tipos de gráficos para analisar a alocação. Alguns sistemas mais sofisticados integrados
a sistemas ERP (veja o Quadro 2.5, no Capítulo 2) utilizam a base única da empresa dos recursos humanos, facilitando a
seleção das pessoas por meio da análise de suas competências registradas na base de dados, e, também, o controle e
remuneração integrados. A base de dados única permite um gerenciamento das férias e compartilhamento da pessoa
em vários projetos e departamentos. A integração com o processamento da folha de pagamento permite que ela re-
ceba conforme o seu desempenho no projeto, desde que seja essa a regra para pagamento.
• Gestão de custos: com as informações dos recursos e atividades, esses sistemas possuem funções para calcular e ge-
renciar o orçamento do projeto. Trata-se de um recurso que auxilia bastante o gerente de projeto na preparação do or-
çamento e no controle dos gastos. Os sistemas de gerenciamento de projetos integrados a sistemas ERP permitem que
todos os gastos de um projeto sejam alocados a um centro de despesas, com regras flexíveis para sua alocação ao
plano de contas da empresa. Dessa forma, pode-se utilizar as regras de consolidação de contas da empresa, sem a ne-
cessidade de entrada de dados adicionais nos sistemas financeiros. Com isso, pode-se controlar os orçamentos de for-
ma integrada e reportar as despesas dos projetos nas alíneas permitidas pelo fisco, conforme a classificação
automática de suas despesas, que são transformadas em custos ou investimentos, dependendo da configuração esta-
belecida para cada um dos projetos. Essa integração permite um controle financeiro mais apurado do projeto.
• Ferramentas de monitoramento: os sistemas mais avançados possuem funcionalidades para auxiliar o acompanha-
mento do projeto. A funcionalidade mais simples é a geração de linhas de acompanhamento dentro de gráficos de
Gantt. Devem permitir, também, o armazenamento de linhas de base, isto é, cópias da situação do planejamento em
um dado instante. As ferramentas devem realizar comparações entre parâmetros do planejamento atual do projeto
com os mesmos parâmetros armazenados nas linhas de base completas. Devem permitir o acompanhamento do pro-
jeto por meio da ferramenta de análise do valor agregado.
• Gerenciamento de múltiplos projetos: essas ferramentas devem permitir a análise do portfólio da empresa, isto é,
gerenciar mais de um projeto ao mesmo tempo e compartilhar dados entre esses projetos. O principal deles é o do con-
junto (pool) de recursos da empresa ou unidade como um todo. Esse é um problema delicado, pois, na grande maioria
das empresas, vários projetos estão em andamento ao mesmo tempo, compartilhando um mesmo conjunto de re-
cursos. Conhecer a capacidade da empresa é fundamental e muito difícil, dados o número de restrições e a grande
quantidade de informações. As ferramentas com essa funcionalidade permitem análises do andamento dos vários pro-
jetos e a determinação do comprometimento atual dos recursos, considerando todos os projetos.

(continua)
176 PARTE 2 O Modelo

Quadro 5.12 Softwares de Gestão de Projetos (continuação)

Uma última observação é que, dentro da tendência em direção ao Product Lyfe-Cycle Management, PLM (veja o Quadro
8.30, no Capítulo 8), essas ferramentas vêm se ampliando para lidar também com a gestão de documentos do projeto e para
facilitar a integração dos times. Portanto, a tendência é que as ferramentas de Gestão de Projetos sejam capazes de se inte-
grar aos sistemas PDM e EDM e estão se desenvolvendo para incluir funcionalidades, tais como:
• Comunicação e integração: os sistemas mais modernos de Gestão de Projetos possuem funcionalidades para im-
portar e exportar dados em outros sistemas (bancos de dados, ERPs etc.), realizar notificações por e-mail e possuir fó-
runs de discussões interno e na Internet (para suporte de instalação e utilização).
• Gestão de documentos, relatórios e impressão: permitem a geração de relatórios predefinidos e sua personali-
zação. As funcionalidades de auxílio ao gerenciamento de documentos, como controle de versão e autoria, ou podem
importá-los ou exportá-los para outros formatos. Ainda avalia se o software gera visões em formato de impressão para
determinados dados ou gráficos.
• Colaboração entre equipes distribuídas: são sistemas de gerenciamento de projetos que rodam na Internet e per-
mitem um controle de projeto distribuído, com uma consolidação centralizada desses controles pelo gerente do pro-
jeto. Todos os membros do time acessam as informações mais atualizadas via Internet. Além disso, eles podem
compartilhar documentos pela Internet.
Por fim, o crescimento do emprego de técnicas para gerenciamento de projetos deve muito à disponibilidade de soft-
wares. Muitas delas exigem a manipulação de grande quantidade de dados, que, no passado, era realizada apenas pelas em-
presas que operavam com projetos de proporções e complexidade suficientes para tornar justificável a existência de uma
equipe de apoio, com engenheiros, estatísticos e matemáticos, dedicados exclusivamente ao trabalho de gerenciamento.
Com o auxílio dos sistemas, mesmo empresas de menor porte podem de maneira prática ter acesso a essas técnicas. No en-
tanto, não se deve esperar que o computador substitua o tradicional processo decisório. Na Gestão de Projetos, o compu-
tador ainda é utilizado principalmente como uma ferramenta de apoio, facilitando a manipulação dos dados para o
emprego de técnicas e métodos disponíveis na área. Sua principal vantagem é a velocidade de processamento de análises
quantitativas, necessárias a uma grande variedade de processos (BADIRU, 1995). O emprego de técnicas computacionais
mais sofisticadas, como a inteligência artificial, ainda está distante das práticas dos sistemas comerciais.

Ao final da identificação das atividades, tem-se uma primeira listagem com a


O resultado da descrição das atividades a serem realizadas no projeto, de preferência, já no sistema
identificação das de Gestão de Projetos adotado como padrão na empresa. Essas atividades devem
atividades
estar organizadas em agrupamentos conforme a EDT identificada do documento
Declaração do Escopo do Projeto. Também é um resultado o aprendizado decor-
rido das discussões e decisões para a definição e descrição das atividades, que deve ser registrado para uso futuro
em outros planejamentos de projetos. Como decorrência desse planejamento das atividades, pode ser percebido
algum ponto incompleto no detalhamento do escopo dado pela EDT, o que deve, então, ser corrigido e/ou
atualizado.
As informações de entrada dessa tarefa são: a lista das atividades; a Declaração
Definir relacionamentos do Escopo do produto, visto que suas características podem afetar as possibilidades
entre atividades de seqüências das atividades; e, principalmente, o conhecimento e a experiência ne-
cessários para determinar as dependências obrigatórias conforme apresentado.
Parte das atividades identificadas possui entre si uma seqüência natural, isto é, uma relação de precedência.
Do ponto de vista de planejamento, tais relações representam restrições de programação que precisam ser consi-
deradas. Por exemplo, se uma atividade é a de detalhar o plano de processo, é lógico que pelo menos um con-
junto de detalhes fundamentais de especificação da peça deve existir. Portanto, a programação do início dessa
atividade terá que ser feita após a conclusão das atividades que definiram a peça. Trata-se de uma precedência de
ordem física e natural. Existem também precedências de ordem lógica. Acontecem quando a motivação da de-
pendência é empírica, ou seja, não há restrições físicas, mas sabe-se, por experiência, que a seqüência torna o
projeto mais produtivo. Por exemplo, as atividades de capacitar a assistência técnica e realizar um determinado
teste do novo produto no mercado são totalmente independentes. Mas pode-se programá-las conjuntamente
para obter economia de translados e compartilhar recursos humanos.
CAPÍTULO 5

Planejamento do Projeto 177

Conforme a natureza da relação entre as atividades, diferentes relações de precedência podem existir, con-
forme o Quadro 5.13. A próxima tarefa do gerente de projeto é estabelecer corretamente esses relacionamentos
para garantir uma seqüência correta. Novamente, aqui é fundamental a utilização de sistemas computacionais de
gestão de projeto.

Quadro 5.13 Tipos de Relacionamentos entre Atividades

Existem quatros tipos básicos de relacionamentos entre atividades. Apresentamos, a seguir, definições de cada um deles
e um exemplo da representação gráfica tradicionalmente utilizada pela maioria dos softwares de Gestão de Projetos:
Final-Início. É o relacionamento mais simples e comum. Acontece quando a atividade su-
cessora só poderá ser iniciada quando a atividade predecessora for finalizada. É o caso da re-
lação entre a atividade Preparar Proposta de Projeto e a atividade predecessora Decidir Início
do Planejamento de um Produto do Portfólio, pertencentes à fase de Planejamento do Pro-
duto.
Início-Início. É aquele que acontece quando a sucessora só poderá ser iniciada se a prede-
cessora já estiver também iniciada, mas NÃO necessariamente finalizada. Um exemplo é o que
acontece entre as atividades de detalhamento de um conjunto de subsistemas com grande in-
terface, como o projeto de um motor de veículos. Sistemas de refrigeração, ignição eletrônica
e outros podem ser planejados para iniciarem necessariamente juntos, para facilitar a dis-
cussão das equipes responsáveis por tais subsistemas.
Final-Final. É a restrição em que as atividades podem começar independentemente, mas a
atividade sucessora deve terminar junto com a antecessora. É o caso típico de atividades de
documentação que requerem atualizações. Por exemplo, as atividades de aprovação final da
Estrutura do Produto (BOM) e sua sucessora homologação do produto. Embora o processo de
homologação comece depois da definição da estrutura, as atividades de documentação
devem terminar juntas para garantir que todas as alterações necessárias durante a homolo-
gação do produto sejam devidamente documentadas.
Duas observações importantes:
• Observação 1: Os livros e sistemas de Gestão de Projetos apresentam também a restrição Início-Final, mas ela tem um
caráter mais conceitual, pois pode ser estabelecida no projeto empregando-se outros relacionamentos.
• Observação 2: Nos sistemas de Gestão de Projetos, além da restrição de seqüência, é possível identificar um prazo de-
nominado de latência (nos sistemas em inglês, lag), isto é, um período de tempo que deve ser contabilizado entre o
fim da atividade predecessora e o início da atividade sucessora.

O diagrama de rede do projeto é uma representação gráfica das atividades e as


relações de seqüência entre elas. São gráficos que auxiliam na análise e otimização Montar a rede do projeto
do projeto. Existem basicamente três modelos de diagramas que podem ser se-
guidos, são eles:

n O método do diagrama de precedência, que basicamente utiliza retângulos para representar as ativi-
dades, que são conectados por setas que representam as dependências entre elas. Esse método, que é uti-
lizado na maioria dos sistemas computacionais de apoio à gerência de projetos, envolve quatro tipos
básicos de relacionamento de seqüência entre atividades: o início do trabalho da atividade sucessora de-
pende ou do início ou do término do trabalho da atividade predecessora; ou o término do trabalho da su-
cessora depende do início ou do término da predecessora (como acabamos de ver no Quadro 5.13).
n O método do diagrama de flecha, que faz uso de setas para representar as atividades, cujas dependências
são esboçadas por meio de nós que as relacionam. Esse método utiliza apenas o relacionamento lógico do
início do trabalho da atividade sucessora que depende do término do trabalho da atividade predecessora.
n O método do diagrama condicional faz uso de técnicas de diagramação e modelos de sistemas dinâ-
micos, o que permite representar atividades não seqüenciais, que é uma limitação dos métodos anterio-
178 PARTE 2 O Modelo

res. Essa não-seqüencialidade pode ser desde uma repetição de atividade, conforme existam necessidades
para isso (como um erro ou inadequação resultante da primeira execução da atividade), até escolhas
entre atividades sucessoras conforme o resultado da atividade predecessora.

Uma vez montada a rede, o gerente de projeto poderá analisá-la para identificar possíveis inconsistências
em termos de falha na identificação de atividades e restrições de seqüência. Feito isso, ele poderá passar à pró-
xima atividade: a obtenção do cronograma do projeto, que é a descrição das atividades com as estimativas dos
prazos e recursos.

5.8 Preparar cronograma


Na atividade Preparar Cronograma (veja a Figura 5.16), o gerente de projeto definirá uma programação de
datas de início e fim das atividades. Essa estimativa depende do esforço necessário para a realização da atividade
e da quantidade de recursos disponíveis, que também deverão ser definidas em detalhes nesse momento. A quali-
dade do resultado final dependerá da experiência do gerente e especialistas consultados na realização de tarefas
similares em projetos de desenvolvimento anteriores e na verificação dos acertos e erros dessas previsões.

Figura 5.16 Atividade de preparação de cronograma.

As informações de entrada para essas previsões de duração temporal são: a lista de atividades; as restrições e
premissas inerentes às atividades, que podem afetar as estimativas de seus tempos de execução; a maior ou menor
disponibilidade dos recursos para a realização das atividades, bem como a produtividade obtida com esses re-
cursos, o que influencia sua duração; a memória de projetos passados seja em registros formais ou informais pela
experiência dos membros das equipes de projeto, quanto às estimativas de tempos nas atividades e sua efetiva
ocorrência quando da realização da atividade; e, por fim, as possíveis ameaças e oportunidades decorrentes de
cada estimativa de duração das atividades. A saída é o cronograma, ou programação do projeto, que pode ser
apresentado de diversas maneiras e conterá datas de início e fim esperados para cada atividade.
CAPÍTULO 5

Planejamento do Projeto 179

A melhor maneira de prever prazo é considerar a quantidade de recursos dis-


poníveis. Intuitivamente, isso é fácil de ser entendido. Imagine que você é encarre- A definição de prazos
gado de determinar o prazo para o desenvolvimento de uma tarefa de montagem do depende da definição da
quantidade de recursos
protótipo de um barco. Se for preciso realizá-la sozinha, provavelmente você irá de- disponíveis
finir um prazo específico. Se você tiver à disposição um técnico altamente especiali-
zado e com experiência na função, as tarefas poderão ser divididas e provavelmente
esse prazo será menor, podendo chegar até a 50% do primeiro, isto é, com duas pessoas, o prazo seria a metade.
Mas a questão é ainda mais complexa porque, se houver uma única pessoa à disposição, outro técnico especiali-
zado, mas com pouca experiência, provavelmente o prazo será menor que a primeira situação, solitário, e maior
que a segunda, dado que o conjunto de tarefas a serem divididas provavelmente será menor.
A forma-padrão de solucionar esse problema, adotada na área da Gestão de Projetos, é utilizar três parâme-
tros fundamentais na programação das atividades, são eles: esforço, duração e unidade de recursos. A idéia é de-
finir a duração como função do esforço total, medido em quantidade de horas para realizar uma determinada
tarefa. Dividindo-o pelo número de recursos disponíveis para executar a tarefa, teremos então a duração. Por
trás dessa relação, encontra-se a premissa de que, ao se alocar o dobro de recursos para uma determinada tarefa,
a duração será a metade do previsto inicialmente. Essa proposição diminui a complexidade do problema e facilita
a programação, embora não seja válida sempre. No caso de atividades em que a divisão de tarefas não é possível
ou exige esforço adicional de coordenação e transmissão de informações, a adição de recursos não diminui a du-
ração na mesma proporção.
Aplicando os três parâmetros, a primeira tarefa do gerente do projeto na pre-
paração do cronograma é prever o esforço, quantidade de homens-horas, necessário Estimar o esforço
para cada tarefa. Para fazer isso, ele irá levar em consideração a natureza da ativi- necessário
dade e também a classificação de complexidade e novidade do projeto, realizada na
atividade anterior, a adaptação do modelo.
Note que, dada a relação apresentada, a estimativa do esforço é independente da quantidade de recursos
necessária. Assim, o gerente de projeto pode se concentrar nos dois problemas de maneira distinta, isto é, com
base na complexidade de definir o esforço necessário e, depois, alocar os recursos disponíveis com base na quan-
tidade de recurso disponível e metas de prazo. O resultado final será um prazo de realização da atividade bas-
tante realista. A relação apresentada facilita a comparação dos diferentes projetos anteriores, permitindo uma
estimativa com base em dados históricos bem mais precisa.
Uma vez definido o esforço necessário em cada atividade, o gerente de projeto
poderá alocar os recursos. Além das informações anteriores, ainda são necessárias a Alocar recursos