Sie sind auf Seite 1von 647

i i

“master_livro” — 2007/3/8 — 15:26 — page i — #1


i i

Projeto Integrado de
Produtos:
planejamento, concepção e modelagem

Volume I

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page ii — #2


i i

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page iii — #3


i i

Projeto Integrado de
Produtos:
planejamento, concepção e modelagem

Volume I

Nelson Back
André Ogliari
Acires Dias
Jonny Carlos da Silva

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page iv — #4


i i

Copyrigth  c 2007 Editora Manole Ltda., por meio de co-edição com o autor.
Projeto gráfico e editoração eletrônica: Anibal Alexandre Campos Bonilla
Capa: Departamento Editorial da Editora Manole.

Dados Internacionais de Catalogação na Publicação (CIP)


(Câmara Brasileira do Livro, SP, Brasil)

Projeto integrado de produtos : planejamento, concepção e modelagem :


Nelson Back...[et al.]. – Barueri, SP : Manole, 2007.

Outros autores: André Ogliari, Acires Dias, Jonny Carlos da Silva


Bibliografia.
ISBN: 978-85-204-2208-3

1. Administração de produto 2. Administração de projetos 3. Engenharia de


produção 4. Produtos novos I. Back, Nelson. II. Ogliari, André. III. Dias, Acires.
IV. Silva, Jonny Carlos da.

07-1217 CDC - 670

Índices para catálogo sistemático:

1. Produtos industriais : Projeto : Engenharia de produção 670


2. Projeto integrado de produtos : Engenharia de produção 670

Todos os direitos reservados.


É proibida a reprodução total ou parcial desta publicação por quaisquer meios sem
autorização escrita da Editora Manole.
A violação dos direitos autorais é crime estabelecido na Lei n. 9.610/98 e punido pelo
artigo 184 do Código Penal.

1a Edição – 2007

Editora Manole Ltda.


Avenida Ceci, 672 – Tamboré
06460 – 120 – Barueri – SP – Brasil
Tel.: (11) 4196-6000
Fax: (11) 4196-6021
www.manole.com.br
info@manole.com.br

Impresso no Brasil
Printed in Brazil

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page v — #5


i i

Biografia dos autores

Nelson Back

Nelson Back nasceu em 1939 em Forquilhinha, no Estado de Santa


Catarina. É engenheiro mecânico, formado em 1964 pela Escola de En-
genharia da Universidade Federal do Rio Grande do Sul – EE/UFRGS.
Realizou seu mestrado em engenharia mecânica em 1968, na Coordena-
ção dos Programas Pós-Graduados em Engenharia da Universidade Fe-
deral do Rio de Janeiro – COPPE/UFRJ. Doutorou-se pelo Departamento
de Engenharia Mecânica do Instituto de Ciência e Tecnologia da Univer-
sidade de Manchester – UMIST, Inglaterra, em engenharia mecânica, em
1972. Tornou-se Livre Docente pela Universidade Federal de Santa Cata-
rina (UFSC) em 1974. É professor de graduação e pós-graduação no De-
partamento de Engenharia Mecânica da UFSC desde 1965. Lecionou as
disciplinas de Elementos de Máquinas, Projeto de Máquinas-ferramenta,
Análise Experimental de Tensões, Componentes de Mecânica de Precisão,
Metodologia de Projeto, Projeto Conceitual, Projeto para Manufatura e Ge-
renciamento de Desenvolvimento de Produtos. É autor do livro Metodolo-
gia de Projeto de Produtos Industriais, de 1983. É membro da Associação
Brasileira de Engenharia e Ciências Mecânicas e da Academia Nacional de
Engenharia. É Professor Emérito da UFSC. Atualmente é Professor Titular
aposentado e professor voluntário da UFSC.

André Ogliari

André Ogliari nasceu em 1962 em Lagoa Vermelha, no Estado do Rio


Grande do Sul. É engenheiro mecânico, formado em 1985 pela Universi-
dade de Caxias do Sul (UCS/RS). Em 1990 concluiu seu mestrado em en-
genharia mecânica, no Programa de Pós Graduação em Engenharia Mecâ-
nica (PPGEM) da UFSC, onde também doutorou-se em 1999. É professor

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page vi — #6


i i

vi Biografia dos autores

do Departamento de Engenharia Mecânica da UFSC desde 1995, onde le-


ciona as disciplinas de Metodologia de Projeto e Elementos de Máquinas,
na graduação, e Projeto Conceitual e Gerenciamento de Desenvolvimento
de Produtos, na pós-graduação.

Acires Dias

Acires Dias nasceu em 1952 em Rio do Sul, no Estado de Santa Cata-


rina. Graduou-se em 1978 e obteve o grau de mestre em 1983 em Engenha-
ria Mecânica, na UFSC. Doutorou-se em 1996 na Universidade Estadual
de Campinas (UNICAMP) em engenharia mecânica, na área de Projeto e
Mecânica dos Sólidos. Realizou estágio de pós-doutorado em Confiabili-
dade e Análise de Risco na University of Maryland, nos Estados Unidos
em 2003. É professor do Departamento de Engenharia Mecânica da UFSC
desde 1984. Leciona na graduação e na pós-graduação, na área de Projeto
de Sistemas Mecânicos, ministrando conteúdos de Elementos de Máqui-
nas, Manutenção, Mantenabilidade, Confiabilidade e Análise de Risco.

Jonny Carlos da Silva

Jonny Carlos da Silva nasceu em 1965 em João Pessoa, Paraíba. Em


1986, graduou-se em engenharia mecânica pela UFPB, tendo recebido
o prêmio Metal Leve de sua turma. Em 1990, obteve grau de mestre
em engenharia mecânica pelo PPGEM/UFSC. Atuou como pesquisador
no LASHIP-UFSC entre 1990-92, especializou-se em hidráulica industrial
pelo KIC (Kyushu International Center) no Japão. Em 1993, iniciou seu dou-
torado pelo PPGEM/UFSC, obtendo grau em 1998. Entre 1996 e 1998,
atuou como pesquisador visitante no Departamento de Engenharia da
Universidade de Lancaster na Inglaterra. É professor do Departamento de
Engenharia Mecânica desde 1993, tendo lecionado na graduação as disci-
plinas de Metodologia de Projeto, Elementos de Máquinas, Sistemas Hi-
dráulicos, e na pós-graduação as disciplinas Modelagem e Simulação e
Sistemas Especialistas Aplicados à Engenharia. Na EXPO 2000, seu pro-
jeto de doutorado recebeu o prêmio Shaping the future pela Universidade
de Hannover, Alemanha.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page vii — #7


i i

Dedicatória

A Maria Helena, minha esposa, meus filhos Alexandre, Isabela e Leonardo, ao


genro e noras Luiz Carlos, Jacqueline e Lia e aos netos Henrique, Victor, Isadora
e Victória.

Prof. Nelson Back

A Edilse, minha esposa, e ao vô Longo (in memoriam).

Prof. André Ogliari

A Fátima, Tiago e Lucas.

Prof. Acires Dias

A Alexandra, minha esposa, ao meu pai, José Cândido, e à minha mãe, Terezinha.

Prof. Jonny Carlos da Silva

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page viii — #8


i i

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page ix — #9


i i

Sumário

Biografia dos autores v

Dedicatória vii

Sumário ix

Prefácio xix

Lista de siglas xxv

Parte I Introdução ao projeto integrado de produtos 1

Capítulo 1 Desenvolvimento integrado do produto – importância


para a competitividade 3
1.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Conceitos básicos para o desenvolvimento integrado de
produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Breve histórico da área de conhecimento . . . . . . . . . . . . 8
1.4 Desenvolvimento de produtos e sua importância para a
competitividade . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 O ensino para o desenvolvimento de produtos e seu valor
estratégico no Brasil . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6 Perspectivas futuras no ensino e pesquisa em
desenvolvimento de produtos . . . . . . . . . . . . . . . . . . . 22
1.7 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.8 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 26
1.9 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 28

Capítulo 2 Desenvolvimeto integrado do projeto de produtos 31


2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page x — #10


i i

x Projeto Integrado de Produtos: planejamento, concepção e modelagem

2.2 Análise de modelos prescritivos de desenvolvimento de


produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 Desenvolvimento de produtos no ambiente de
engenharia simultânea . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.1 Engenharia simultânea: definições e princípios . . . . . 45
2.3.2 Engenharia simultânea: modelos . . . . . . . . . . . . . 47
2.3.3 Engenharia simultânea: implantação . . . . . . . . . . 53
2.3.4 Engenharia simultânea: modos de falha na fase
inicial da implementação . . . . . . . . . . . . . . . . . 54
2.3.5 Engenharia simultânea: falhas na preparação e no
planejamento de implantação . . . . . . . . . . . . . . 56
2.3.6 Engenharia simultânea: falhas na fase de execução
do plano de implantação . . . . . . . . . . . . . . . . . 61
2.3.7 Engenharia simultânea: barreiras da implantação . . . 62
2.3.8 Engenharia simultânea: etapas para a implantação . . 64
2.3.9 Engenharia simultânea: formação de equipes
multidisciplinares . . . . . . . . . . . . . . . . . . . . . . . 66
2.3.10 Engenharia simultânea: benefícios de sua aplicação . 67
2.4 Modelo de desenvolvimento integrado de produtos . . . . . . 68
2.4.1 Fase 1 – Planejamento do projeto . . . . . . . . . . . . . 74
2.4.2 Fase 2 – Projeto informacional . . . . . . . . . . . . . . . 75
2.4.3 Fase 3 – Projeto conceitual . . . . . . . . . . . . . . . . . 78
2.4.4 Fase 4 – Projeto preliminar . . . . . . . . . . . . . . . . . 80
2.4.5 Fase 5 – Projeto detalhado . . . . . . . . . . . . . . . . . 82
2.4.6 Fase 6 – Preparação da produção . . . . . . . . . . . . 82
2.4.7 Fase 7 – Lançamento do produto . . . . . . . . . . . . . 84
2.4.8 Fase 8 – Validação do produto . . . . . . . . . . . . . . 87
2.5 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.6 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 92
2.7 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 94

Capítulo 3 Gerenciamento do desenvolvimento integrado de


produtos 97
3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.2 Considerações gerais sobre gerenciamento de projetos . . . . 100
3.3 Gerenciamento do desenvolvimento integrado de produtos . 106

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xi — #11


i i

SUMÁRIO xi

3.4 Estrutura organizacional para o projeto de desenvolvimento


de produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.5 Equipes de desenvolvimento de produtos . . . . . . . . . . . . 115
3.6 Planejamento de projetos de desenvolvimento de produtos . . 118
3.7 Escopo do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 122
3.7.1 Processos de gerenciamento do escopo do projeto . . 126
3.7.2 Estrutura de Desdobramento do Trabalho – EDT . . . . . 128
3.7.3 Considerações gerais sobre o gerenciamento do
escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
3.8 Tempo e custo do projeto . . . . . . . . . . . . . . . . . . . . . . 133
3.8.1 Gerenciamento do tempo do projeto . . . . . . . . . . 133
3.8.2 Gerenciamento de custos do projeto . . . . . . . . . . 146
3.9 Execução, controle e encerramento do processo de
desenvolvimento de produtos . . . . . . . . . . . . . . . . . . . 152
3.10 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
3.11 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 154
3.12 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 156

Parte II Projeto informacional do produto 159

Capítulo 4 Planejamento de produtos 161


4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
4.2 Idéia do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.3 Processo de planejamento de produtos . . . . . . . . . . . . . 168
4.4 Metodologias gerais de apoio ao planejamento de produtos . 175
4.4.1 Gestão do conhecimento . . . . . . . . . . . . . . . . . 176
4.4.2 Inteligência competitiva . . . . . . . . . . . . . . . . . . 177
4.4.3 Gestão da inovação de produtos . . . . . . . . . . . . 179
4.5 Métodos e ferramentas de apoio ao planejamento de
produtos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
4.5.1 Métodos e ferramentas para a geração de idéias
de produtos . . . . . . . . . . . . . . . . . . . . . . . . . 181
4.5.2 Métodos e ferramentas de apoio à gestão da
tecnologia de produtos . . . . . . . . . . . . . . . . . . 185
4.6 Organização e infra-estrutura para a inovação . . . . . . . . . 192
4.7 Avaliação do impacto da tecnologia . . . . . . . . . . . . . . . 196
4.8 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xii — #12


i i

xii Projeto Integrado de Produtos: planejamento, concepção e modelagem

4.9 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 199


4.10 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 200

Capítulo 5 Especificações de projeto do produto 203


5.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5.2 Conceitos fundamentais relacionados à elaboração das
especificações de projeto . . . . . . . . . . . . . . . . . . . . . 205
5.3 Metodologia de desenvolvimento das especificações de
projeto do produto . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.3.1 Apresentação do problema de projeto . . . . . . . . . 207
5.3.2 Definição do ciclo de vida do produto . . . . . . . . . . 209
5.3.3 Identificação dos usuários do projeto e do produto . . 211
5.3.4 Elicitação das necessidades dos usuários . . . . . . . . 212
5.3.5 Transformação das necessidades em requisitos de
usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
5.3.6 Planejamento da qualidade desejada . . . . . . . . . . 217
5.3.7 Conversão dos requisitos de usuários em requisitos
de projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.3.8 Priorização dos requisitos de projeto . . . . . . . . . . . 226
5.3.9 Análise do relacionamento entre requisitos de
projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
5.3.10 Conversão dos requisitos de projeto em
especificações de projeto . . . . . . . . . . . . . . . . . 234
5.3.11 Redação das especificações de projeto . . . . . . . . 235
5.4 Qualidades das especificações de projeto . . . . . . . . . . . . 237
5.5 Considerações gerais sobre o processo de obtenção das
especificações de projeto . . . . . . . . . . . . . . . . . . . . . 240
5.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
5.7 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 245
5.8 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 246

Parte III Projeto conceitual – geração de soluções 249

Capítulo 6 Síntese de soluções alternativas – inovação do produto 251


6.1 Introdução ao processo de inovação do produto . . . . . . . . 251
6.2 Métodos intuitivos de geração de concepções do produto . . 256
6.2.1 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . 256

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xiii — #13


i i

SUMÁRIO xiii

6.2.2 Método de Delphi . . . . . . . . . . . . . . . . . . . . . . 260


6.2.3 Analogias direta, simbólica e pessoal . .
. . . . . . . . 262
6.2.4 Método sinético . . . . . . . . . . . . . . .
. . . . . . . . 263
6.2.5 Método da listagem de atributos . . . . .
. . . . . . . . 266
6.2.6 Método da instigação de questões . . .
. . . . . . . . 267
6.3 Métodos sistemáticos de geração de concepções . . . . . . . 268
6.3.1 Método da matriz morfológica . . . . . . . . . . . . . . 269
6.3.2 Análise do valor . . . . . . . . . . . . . . . . . . . . . . . 275
6.3.3 Teoria de solução inventiva de problemas – TRIZ . . . . 287
6.4 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
6.5 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 299
6.6 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 301

Capítulo 7 Método da síntese funcional e engenharia reversa 303


7.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
7.2 Fundamentos de sistemas técnicos . . . . . . . . . . . . . . . . 304
7.3 Método da síntese funcional . . . . . . . . . . . . . . . . . . . . 305
7.3.1 Formulação da função global do sistema técnico . . . 305
7.3.2 Desenvolvimento da estrutura funcional do sistema
técnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
7.3.3 Padronização e representação da estrutura
funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
7.3.4 Análise e seleção de estruturas funcionais
alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . 328
7.3.5 Estruturas de princípios de solução do sistema
técnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
7.4 Engenharia reversa . . . . . . . . . . . . . . . . . . . . . . . . . . 330
7.5 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
7.6 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 334
7.7 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 335

Parte IV Projeto conceitual – seleção da concepção 339

Capítulo 8 Projeto para viabilidade econômica do produto 341


8.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
8.2 Conceitos fundamentais de custos do produto . . . . . . . . . 344
8.3 Análise de custo do ciclo de vida de produtos . . . . . . . . . . 346

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xiv — #14


i i

xiv Projeto Integrado de Produtos: planejamento, concepção e modelagem

8.3.1 Definição do problema de análise . . . . . . . . . . . . 346


8.3.2 Identificação das alternativas viáveis . . . . . . . . . . . 349
8.3.3 Estrutura de desdobramento do custo do produto . . . 350
8.3.4 Seleção de modelos de custo para análise . . . . . . . 351
8.3.5 Elaboração de estimativas de custo . . . . . . . . . . . 352
8.3.6 Desenvolvimento de perfis de custo . . . . . . . . . . . 356
8.3.7 Elaboração da análise do ponto de equilíbrio . . . . . 358
8.3.8 Identificação de elementos ou funções de alto
custo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
8.3.9 Realização da análise de sensibilidade . . . . . . . . . 360
8.3.10 Realização da análise de riscos . . . . . . . . . . . . . . 362
8.3.11 Recomendação da solução preferida . . . . . . . . . . 363
8.4 Aplicações da análise de custo nas tomadas de decisão
no processo de projeto . . . . . . . . . . . . . . . . . . . . . . . 363
8.5 Controle de custos de desenvolvimento do produto . . . . . . 365
8.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
8.7 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 370
8.8 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 371

Capítulo 9 Processo de avaliação e seleção de concepções do


produto 373
9.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
9.2 Metodologia de avaliação e seleção da concepção . . . . . 375
9.2.1 Descrição e apresentação das concepções
alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . 376
9.2.2 Apresentação e seleção dos critérios generalizados . . 377
9.2.3 Escolha do método de triagem . . . . . . . . . . . . . . 378
9.2.4 Elaboração da triagem das concepções . . . . . . . . 380
9.2.5 Detalhar e reapresentar as concepções viáveis . . . . 380
9.2.6 Definição dos critérios específicos . . . . . . . . . . . . 381
9.2.7 Escolha do método de valoração das concepções . . 383
9.2.8 Determinação dos pesos dos critérios . . . . . . . . . . 384
9.2.9 Valoração dos critérios . . . . . . . . . . . . . . . . . . . 385
9.2.10 Determinação do valor da função utilidade e
ordenação das concepções . . . . . . . . . . . . . . . 388
9.2.11 Análise das melhores concepções . . . . . . . . . . . . 389

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xv — #15


i i

SUMÁRIO xv

9.3 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390


9.4 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 392
9.5 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 394

Capítulo 10 Aspectos legais e éticos na inovação de produtos 397


10.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
10.2 Busca de informações em bancos de patentes . . . . . . . . . 398
10.3 Avaliação da inovação e da patenteabilidade . . . . . . . . . 402
10.4 Processo de patenteamento ou registro de inovações . . . . . 405
10.4.1 Elaboração dos pedidos de patente . . . . . . . . . . . 409
10.4.2 Elaboração do pedido de registro de desenho
industrial . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
10.4.3 Pedido de patente internacional . . . . . . . . . . . . . 416
10.5 Registro de marcas . . . . . . . . . . . . . . . . . . . . . . . . . . 418
10.6 Responsabilidade civil sobre os produtos e serviços . . . . . . . 422
10.7 Perícias em litígios de proteção da inovação e de
responsabilidade civil . . . . . . . . . . . . . . . . . . . . . . . . 427
10.8 Ética profissional . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
10.9 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
10.10 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 440
10.11 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 442

Parte V Projeto conceitual – modelagem e análise da


concepção 445

Capítulo 11 Modelagem e simulação de soluções de projeto 447


11.1 A modelagem e a importância de modelos – contexto
histórico da modelagem . . . . . . . . . . . . . . . . . . . . . . 447
11.2 Modelos: definições, propósitos, classificações e riscos . . . . . 448
11.2.1 Classificação dos modelos . . . . . . . . . . . . . . . . . 450
11.2.2 Vantagens e riscos da modelagem . . . . . . . . . . . . 452
11.2.3 Processo de modelagem . . . . . . . . . . . . . . . . . 454
11.3 Exemplos de aplicações de modelos . . . . . . . . . . . . . . . 455
11.3.1 Modelos e simuladores veiculares . . . . . . . . . . . . . 455
11.3.2 Análise dimensional e modelos analógicos . . . . . . . 458
11.3.3 Simulação de escoamento . . . . . . . . . . . . . . . . 467
11.3.4 Simuladores integrados a sistemas especialistas . . . . . 469

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xvi — #16


i i

xvi Projeto Integrado de Produtos: planejamento, concepção e modelagem

11.4 Modelagem no projeto de produtos . . . . . . . . . . . . . . . . 473


11.5 A simulação dinâmica no contexto do projeto e
introdução ao sistema AMESim . . . . . . . . . . . . . . . . . . . 481
11.6 Análise de sensibilidade . . . . . . . . . . . . . . . . . . . . . . . 490
11.7 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
11.8 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 495
11.9 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 498

Capítulo 12 Análise de parâmetros no processo de projeto 501


12.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
12.2 Contextualização da análise de parâmetros no processo de
projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
12.3 Definições e medidas para análise de parâmetro . . . . . . . . 505
12.3.1 Relação entre sinal e ruído . . . . . . . . . . . . . . . . . 506
12.3.2 Função perda . . . . . . . . . . . . . . . . . . . . . . . . 507
12.3.3 Projeto de parâmetros . . . . . . . . . . . . . . . . . . . 509
12.3.4 Projeto de tolerâncias . . . . . . . . . . . . . . . . . . . 511
12.3.5 Análises de sensibilidade, compatibilidade e
estabilidade . . . . . . . . . . . . . . . . . . . . . . . . . 512
12.4 O método de Taguchi para o projeto robusto . . . . . . . . . . 518
12.5 Metodologia para projeto de experimento . . . . . . . . . . . . 521
12.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
12.7 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 533
12.8 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 534

Capítulo 13 Otimização integrada no processo de projeto do


produto 537
13.1 Introdução ao conceito de otimização integrada . . . . . . . . 537
13.2 Sistemática de dimensionamento da concepção de
projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
13.3 Otimização matemática do projeto . . . . . . . . . . . . . . . . 540
13.4 Otimização integrada do produto . . . . . . . . . . . . . . . . . 547
13.4.1 Projeto para configuração . . . . . . . . . . . . . . . . . 549
13.4.2 Projeto para precisão . . . . . . . . . . . . . . . . . . . . 551
13.4.3 Projeto para estética . . . . . . . . . . . . . . . . . . . . 552
13.4.4 Projeto para modularidade . . . . . . . . . . . . . . . . 554
13.4.5 Projeto para segurança e responsabilidade civil . . . . 558

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xvii — #17


i i

SUMÁRIO xvii

13.4.6 Projeto para a normalização . . . . . . . . . . . . . . . 560


13.4.7 Projeto para teste . . . . . . . . . . . . . . . . . . . . . . 561
13.4.8 Projeto para manufatura . . . . . . . . . . . . . . . . . . 563
13.4.9 Projeto para montagem . . . . . . . . . . . . . . . . . . 565
13.4.10 Projeto para embalagem . . . . . . . . . . . . . . . . . 568
13.4.11 Projeto para uso amigável . . . . . . . . . . . . . . . . . 570
13.4.12 Projeto para confiabilidade . . . . . . . . . . . . . . . . 573
13.4.13 Projeto para inspeção . . . . . . . . . . . . . . . . . . . 575
13.4.14 Projeto para mantenabilidade . . . . . . . . . . . . . . 577
13.4.15 Projeto para apoio logístico . . . . . . . . . . . . . . . . 579
13.4.16 Projeto para meio ambiente, reciclagem e descarte . 580
13.5 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
13.6 Problemas e temas de discussão . . . . . . . . . . . . . . . . . . 583
13.7 Referências bibliográficas . . . . . . . . . . . . . . . . . . . . . . 584

Apêndice Modelo PRODIP – processo de projeto 587

Índice remissivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xviii — #18


i i

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xix — #19


i i

Prefácio

“Projeto Integrado de Produtos: planejamento, concepção e modela-


gem” apresenta, de forma estruturada, os processos e métodos adotados
no projeto de produtos industriais, baseado na experiência de pesquisa,
estudo e ensino neste domínio de conhecimento, desde a década de 70, no
Núcleo de Desenvolvimento Integrado de Produtos – NeDIP, do Departa-
mento de Engenharia Mecânica da UFSC. Em 1983 foi publicada uma obra
sob o título “Metodologia de Projeto de Produtos Industriais”, de autoria
do Prof. Nelson Back, que repercutiu muito bem no meio acadêmico e no
setor industrial. Desde a década de 80 começou-se a reconhecer em diver-
sas universidades brasileiras a importância de um processo sistematizado
e estruturado de desenvolvimento de produtos. Ocorreram então inicia-
tivas de introdução de disciplinas de metodologia de projeto de produto
nos currículos de graduação e pós-graduação. Os egressos dessas univer-
sidades, ao aplicar essa metodologia na indústria, mostraram os benefícios
resultantes de uma metodologia estruturada, provocando uma demanda
por literatura nesse campo de conhecimento. Procura-se, nesta obra, por
meio de conceitos modernos e linguagem apropriada, cobrir os aspectos
de todo o processo de desenvolvimento de produtos, desde a identificação
de necessidades de consumidores até o descarte do produto. Por ser um
campo de conhecimento muito amplo, neste volume intitulado “Projeto
Integrado de Produtos: planejamento, concepção e modelagem” são apre-
sentados, de forma estruturada, o processo e métodos de desenvolvimento
de produtos desde a fase inicial de planejamento até a fase de projeto con-
ceitual, contendo cinco partes, desdobradas em treze capítulos. O volume
foi dimensionado dessa forma, por apresentar um conteúdo apropriado
para estudos iniciais no domínio do processo de desenvolvimento de pro-
duto e que estas fases promovem maior impacto na inovação e qualidade
do produto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xx — #20


i i

xx Projeto Integrado de Produtos: planejamento, concepção e modelagem

Na primeira parte, com três capítulos, encontram-se os conceitos ge-


rais do campo de conhecimento, assim como a estrutura e os aspectos de
gestão do processo de projeto. No Capítulo 1, são apresentados concei-
tos fundamentais de desenvolvimento integrado de produtos, a evolução
da área de conhecimento e a importância do projeto para a qualidade e
competitividade do produto. São discutidos os principais aspectos da ca-
pacitação de profissionais e das perspectivas de evolução na pesquisa. No
Capítulo 2, dá-se uma visão geral de diversos modelos prescritivos de de-
senvolvimento do projeto encontrados na literatura, os fundamentos da
engenharia simultânea e a estrutura do modelo de desenvolvimento in-
tegrado de produtos PRODIP, desenvolvido no NeDIP. Neste modelo o
processo é desdobrado em oito fases: planejamento do projeto; projeto in-
formacional; projeto conceitual; projeto preliminar; projeto detalhado; pre-
paração da produção; lançamento do produto; e validação do produto. No
Capítulo 3, apresentam-se argumentos e fundamentos demonstrando que
o desenvolvimento de um produto é mais eficiente quando o mesmo é
elaborado sob os conceitos e princípios da gestão de projetos.
A segunda parte deste volume trata da fase de projeto informacional,
que se constitui de dois capítulos. O Capítulo 4 discute o planejamento
do produto, que compreende a identificação das oportunidades do mer-
cado, ou a definição do produto a ser desenvolvido, e da gestão da tecno-
logia necessária na sua produção. Definido o produto, o passo seguinte é
a transformação das necessidades dos usuários em especificações de pro-
jeto, adotando como principal ferramenta o método do desdobramento da
função qualidade, tratado no Capítulo 5.
Na terceira parte, tendo definidas as especificações de projeto, inicia-se
a geração de soluções alternativas da concepção do produto, adotando-se,
para isso, métodos de criatividade muito encontrados na literatura, dos
quais o Capítulo 6, descreve os mais representativos, entre intuitivos e sis-
temáticos. No Capítulo 7, é apresentado o método da síntese funcional,
considerado o mais apropriado para a geração de concepções alternativas
de novos sistemas técnicos. No mesmo capítulo é descrita uma sistemá-
tica recomendada para, a partir de um produto existente, desenvolver a
formalização do projeto, procedimento normalmente denominado de en-
genharia reversa.
Obtidas as soluções alternativas, a próxima etapa do processo é a sele-
ção e a modelagem da melhor ou das melhores soluções, pois, neste está-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xxi — #21


i i

Prefácio xxi

gio do desenvolvimento, há muitas incertezas na avaliação da concepção


mais promissora. Na quarta parte deste volume, no Capítulo 8, inicia-se
a seleção da concepção pela avaliação da viabilidade econômica das con-
cepções alternativas. São apresentados os conceitos de custo do ciclo de
vida do produto, desdobramento da estrutura de custos, métodos de esti-
mativa de custo e métodos de análise comparativa da viabilidade econô-
mica das concepções. Definidas as concepções economicamente viáveis,
elas são submetidas a um procedimento mais abrangente de seleção, des-
crito no Capítulo 9. Neste capítulo, descreve-se uma metodologia de se-
leção em dois estágios. No primeiro estágio, considera-se um processo de
triagem das melhores soluções levando em conta múltiplos critérios gene-
ralizados. No segundo, adota-se um método de valoração das concepções
pela avaliação de múltiplos critérios específicos. A solução escolhida deve
atender a diversos aspectos legais e éticos, os quais poderiam ser incor-
porados como critérios de seleção do Capítulo 9, mas preferiu-se tratá-los
em capítulo à parte. Uma concepção pode ser desenvolvida adotando in-
formações de produtos existentes, se não houver patentes vigentes dessas
soluções, mas, por outro lado, uma solução inovadora e patenteável sem-
pre deve ser almejada. Os fundamentos para essa avaliação são tratados
no Capítulo 10, que aborda a busca de informações em bancos de paten-
tes, a patenteabilidade ou registro da invenção, a defesa da propriedade
industrial, o registro de marcas, os aspectos relacionados à responsabili-
dade civil e os relativos à ética dos profissionais envolvidos no processo
de desenvolvimento do produto. Realizada a análise de viabilidade econô-
mica, efetuada uma ordenação das soluções viáveis e, ainda, verificada
a patenteabilidade e a conformidade com as normas e a legislação perti-
nentes, é bem provável que se tenha identificado a melhor solução, que
deve então ser submetida à modelagem para, posteriormente, efetuar-se
seu dimensionamento e otimização. No Capítulo 11, são introduzidos co-
nhecimentos necessários para identificar e formular o modelo ou os mo-
delos mais apropriados para efetuar a análise e simulação do desempenho
da concepção desenvolvida para o produto. Identificados os modelos e as
correspondentes variáveis para efetuar os dimensionamentos, as diferen-
tes análises e simulações, no Capítulo 12, são apresentados os aspectos
e conceitos para a definição do espaço viável de projeto, a determinação
da sensibilidade do desempenho às variações dos parâmetros de projeto
e aos fatores de meio ambiente, bem como as tolerâncias admissíveis das

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xxii — #22


i i

xxii Projeto Integrado de Produtos: planejamento, concepção e modelagem

variáveis de projeto. Com os conceitos apresentados até o Capítulo 12 se


conclui a fase do projeto conceitual do produto.
O Capítulo 13 tem dois objetivos principais: o primeiro pretende dar
ao leitor uma idéia mais ampla sobre as preocupações que o projetista
deve ter durante o processo de planejamento, definição, geração e seleção
da solução para o produto, ou seja, nas três fases tratadas neste volume;
o segundo objetivo é estabelecer uma interface e dar uma visão do que se
entende por otimização integrada do produto, assunto a ser tratado em
maior profundidade em obra futura.

Por esta obra ter sido elaborada no Núcleo de Desenvolvimento Inte-


grado de Produtos – NeDIP, do Departamento de Engenharia Mecânica do
Centro Tecnológico da UFSC, foram inúmeros os que colaboraram com o
conteúdo e a preparação deste texto, a quem os autores agradecem. Muito
do que é apresentado são experiências de ensino e de pesquisa na gradua-
ção e pós-graduação. Assim, questões, partes do texto e exemplos apre-
sentados foram contribuições dos oitenta alunos de mestrado e quinze de
doutorado formados no NeDIP desde 1973. Os autores também receberam
contribuições de diversos professores do departamento.

Nominalmente, queremos agradecer a participação dos acadêmicos


Heitor Kagueiama e Eduardo Natal Meller pela preparação dos desenhos,
ao Dr. Anibal Alexandre Campos Bonilla pela diagramação do texto, a
Roberto Dias de Andrade, pela construção e pelos testes de protótipos e,
especialmente, a Maria Helena de Carlos Back, pela leitura e pelas suges-
tões de correções de português de todo o texto.

Quanto às instituições, queremos, em primeiro lugar, agradecer ao


Conselho Nacional de Desenvolvimento Científico e Tecnológico – CNPq,
que, desde 1992, vem apoiando o NeDIP nos projetos de pesquisa em sis-
tematização do processo de desenvolvimento de produtos, concedendo
bolsas de Iniciação Científica, Mestrado, Doutorado e de Produtividade,
bem como recursos financeiros para custear as pesquisas. Agradecemos
também ao Departamento de Engenharia Mecânica e ao Centro Tecnoló-
gico da UFSC, pelo contínuo incentivo.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xxiii — #23


i i

Prefácio xxiii

Os autores são gratos à Fundação do Ensino da Engenharia em Santa


Catarina – FEESC, com sede no Centro Tecnológico da UFSC, pelo apoio
financeiro recebido para a preparação final do texto desta obra.

Nelson Back
André Ogliari
Acires Dias
Jonny Carlos da Silva

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xxiv — #24


i i

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xxv — #25


i i

Lista de siglas

ABNT Associação Brasileira de Normas Técnicas


ACWP Custo atual do trabalho executado na data de
controle (Actual Costs of Work Performed)
AMESim Advanced Modeling Environment for Simulations
ANOVA Análise da variância (Analysis of Variance)
ASME Sociedade norte-americana de engenheiros
mecânicos (American Society of Mechanical Engineers)
BCC Custo meta ou planejado do projeto na conclusão
(Budgeted Cost at Completion)
BCWP Valor do trabalho executado
(Budgeted Cost for Work Performed)
BCWS Custo planejado do trabalho programado
(Budgeted Cost for Work Scheduled)
CAD Projeto assistido por computador
(Computer Aided Design)
CAM Manufatura assistida por computador
(Computer Aided Manufacturing)
CDC Código de Defesa do Consumidor
CEDIN Centro de Documentação e Informação Tecnológica
COPPE/UFRJ Coordenação dos Programas Pós-Graduados de
Engenharia da Universidade Federal do
Rio de Janeiro
CPM Método do caminho crítico (Critical Path Method)
CV Variação de custo (Cost Variance)
DFA Projeto para montagem (Design for Assembly)
DFC Projeto para custo (Design for Cost)
DFE Projeto para meio ambiente (Design for Enviroment)

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xxvi — #26


i i

xxvi Projeto Integrado de Produtos: planejamento, concepção e modelagem

DFM Projeto para manufatura (Design for Manufacturing)


DFS Projeto para segurança (Design for Safety)
DI Desenho Industrial
DoE Projeto do experimento (Design of Experiments)
EAP Estrutura Analítica do Projeto
ECC Projeção do custo na conclusão do projeto
(Estimated Cost at Completion)
ECOMP Estações de Compressão de Gás Natural
EDP Estrutura de Desdobramento do Produto
EDT Estrutura de Desdobramento do Trabalho
EE Estação de Entrega
EFt Tempo mais cedo de término (Earliest Finish time)
EPO Escritório Europeu de Patentes
(European Patent Office)
ES Engenharia Simultânea
ESt Tempo mais cedo de início (Earliest Start time)
EV Valor agregado (Earned Value)
FAST Técnica de análise funcional de sistemas
(Functional Analysis System Technique)
FE Função Elementar
FG Função Global
IDEF0 Definição de integração para a modelagem de função
(Integration Definition for Function Modeling)
INPI Instituto Nacional de Propriedade Industrial
FINEP Financiadora de Estudos e Projetos
FMEA Análise do modo de falha e efeito
(Failure Mode and Effect Analysis)
FMECA Análise do modo de falha, efeito e criticidade
(Failure Mode, Effect and Criticality Analysis)
FP Função Parcial
IPT Instituto de Pesquisas Tecnológicas
ISO Organização Internacional para Padronização
(International Organization for Standardization)
LFt Tempo mais tarde de término (Latest Finish time)
LIT Limite Inferior de Tolerância
LPI Lei de Propriedade Industrial

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xxvii — #27


i i

Lista de siglas xxvii

LSt Tempo mais tarde de início (Latest Start time)


LST Limite Superior de Tolerância
MEP Matriz de Estruturação do Projeto
(DSM – Design Structure Matrix)
NASA Agência Espacial Norte-americana
(National Aeronautics and Space Administration)
MU Modelo de Utilidade
NBR Norma Brasileira
NeDIP Núcleo de Desenvolvimento Integrado do Produto
OMPI Organização Mundial da Propriedade Intelectual
(WIPO – World Intellectual Property Organization)
PCA Aeronave de propulsão controlada
(Propulsion Controlled Aircraft)
PCEE Problema Como É Entendido
PCED Problema Como É Definido
PCT Tratado de Cooperação em Matéria de Patentes
PDM Método do Diagrama de Precedência
PERT Técnica de revisão e avaliação de programas
(Program Evaluation and Review Technique)
PI Patente de Invenção
P&D Pesquisa e Desenvolvimento
PMI Instituto de gerenciamento de projeto
(Project Management Institute)
PO Projeção do acréscimo de custo na conclusão do
projeto (Projected Overrun)
PRODIP Processo de Desenvolvimento Integrado de Produtos
PROFINT Programa de Fornecimento Automático de
Informação Tecnológica
QE Questão Evocativa
QFD Desdobramento da função qualidade
(Quality Function Deployment)
QLF Função perda de qualidade (Quality Loss Function)
RPI Revista da Propriedade Industrial
S/CS Sensor de Condicionamento de Sinal
SEGRED Sistemas Especialistas para Gerenciamento de Redes
de Gás Natural

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page xxviii — #28


i i

xxviii Projeto Integrado de Produtos: planejamento, concepção e modelagem

ST Sistema Técnico
SWOT Forças, fraquezas, oportunidades e ameaças
(Strengths, Weaknesses, Opportunities and Threats)
SV Variação do cronograma (Schedule Variance)
TRIZ Teoria de solução inventiva de problemas
(Teorija Rezhenija Izobretatel’skisch Zadach)
TV Variação entre tempo programado e de execução
(Time Variance)
USPTO Escritório de patentes e marcas registradas dos EUA
(United States Patent and Trademark Office)
VDI Associação alemã de engenheiros
(Verein Deutscher Ingenieure)
VF Valor Futuro
VP Valor Presente

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 1 — #29


i i

Parte I

Introdução ao projeto integrado


de produtos

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 2 — #30


i i

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 3 — #31


i i

Capítulo 1

Desenvolvimento integrado do produto –


importância para a competitividade

1.1 Introdução

Este capítulo apresenta uma introdução à área de desenvolvimento de


produtos industriais. Em primeiro lugar, devido à amplitude e à multidis-
ciplinaridade da área de conhecimento, serão relacionados alguns concei-
tos básicos e discutidas as principais terminologias adotadas nesta obra,
visando uma uniformidade de entendimento.
Utensílios ou produtos já são produzidos desde os primórdios da civi-
lização humana, mas o estudo do processo de projeto de produtos, como
uma disciplina ou de uma forma mais sistemática, só ocorreu a partir da
década de 1960, como será descrito em um breve histórico no item 1.3. A
partir de 1980, com a globalização, a atividade de desenvolvimento de pro-
dutos foi considerada de importância extraordinária; os métodos e ferra-
mentas desenvolvidos foram resultados de grandes esforços de pesquisa.
Atualmente a competitividade dos produtos depende de fatores tais como
escopo, custo, tempo de lançamento e qualidade do produto, conforme as
considerações apresentadas no item 1.4 deste capítulo.
Na seqüência, o capítulo traz aspectos e perspectivas sobre ensino, ca-
pacitação e pesquisa no campo de conhecimento de desenvolvimento de
produtos. Ao final do capítulo, com o objetivo de fixar e ampliar o conhe-
cimento sobre os assuntos abordados, são apresentados problemas, temas
de discussão e as referências bibliográficas.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 4 — #32


i i

4 Projeto Integrado de Produtos: planejamento, concepção e modelagem

1.2 Conceitos básicos para o desenvolvimento


integrado de produtos

Desenvolvimento de produto é um conceito amplo e, nesta obra, com-


preenderá os aspectos de planejamento e projeto, ao longo de todas as ati-
vidades da seqüência do processo, desde a pesquisa de mercado, o projeto
do produto, projeto do processo de fabricação, plano de distribuição e de
manutenção até o descarte ou desativação do mesmo. Por esse conceito,
entende-se desenvolvimento de produto como todo o processo de trans-
formação de informações necessárias para a identificação da demanda, a
produção e o uso do produto. O desenvolvimento integrado de produto
considera que esse processo de transformação e geração de informações
deva ser efetuado por uma equipe multidisciplinar, ou melhor, que os re-
quisitos, restrições do produto e soluções, ao longo de todas as fases do
processo, devam ser considerados ou pensados simultaneamente. O termo
engenharia simultânea também será usado para expressar o desenvolvi-
mento integrado do produto. Engenharia simultânea é a tradução adotada
para concurrent engineering, do inglês.
O termo produto refere-se a um objeto concebido, produzido indus-
trialmente com características e funções, comercializado e usado pelas pes-
soas ou organizações, de modo a atender a seus desejos ou necessidades.
Os produtos são constituídos de elementos que formam um conjunto de
atributos básicos, tais como: aparência, forma, cor, função, imagem, ma-
terial, embalagem, marca, serviços pós-venda e garantias. Novos produ-
tos não significam, necessariamente, produtos originais; novos produtos
podem ser obtidos com melhorias e modificações de produtos existentes.
Novos tamanho e forma de um produto já existente podem representar
um novo produto. Da mesma forma, um produto já existente introduzido
em um novo nicho de mercado ou em um novo mercado geográfico pode
ser considerado um novo produto. Os novos produtos podem ser classifi-
cados em:

• variantes de produtos existentes: incluem extensões de linha, repo-


sicionamento de produtos em termos de seu uso e mercado, formas
novas, versões modificadas e, em alguns casos, a nova embalagem
de produtos existentes;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 5 — #33


i i

Desenvolvimento integrado do produto – importância para a competitividade 5

• inovativos: são o resultado de modificações feitas em produtos exis-


tentes, gerando produtos de elevado valor agregado. Geralmente
um maior grau de inovação requer um tempo mais longo ou esforço
de desenvolvimento e maior custo de pesquisa;
• criativos: são produtos normalmente com existência nova. Seu tem-
po de desenvolvimento é longo e os custos de pesquisa e desenvolvi-
mento são elevados. A introdução de produtos criativos no mercado
pode ser de risco elevado, mas também pode gerar novos paradig-
mas e potencializar novos campos industriais.

Outro termo freqüentemente usado nesta obra é o de ciclo de vida do


produto, que é empregado na literatura em geral para dois significados.
No primeiro caso, é usado para expressar o período entre o lançamento
e a retirada do produto do mercado, ou o tempo de comercialização do
mesmo. No segundo caso, e quando usado no presente livro, ciclo de vida
do produto significa a seqüência de fases pelas quais se desenvolve o pro-
duto, desde a busca de oportunidades no mercado, o projeto, a fabricação
até o uso e o descarte. Dentro desse ciclo, tratar-se-á, em profundidade, o
processo de desenvolvimento do produto, que compreende as seguintes
fases: planejamento do produto; definição das especificações de projeto;
projeto do produto; projeto do processo de fabricação e de montagem;
construção e teste do protótipo; e planejamento do processo de transporte,
manutenção e descarte ou desativação do produto. A fase de projeto do
produto terá destaque especial nesta publicação e será abordada na maior
parte dos próximos capítulos.
Projeto, neste contexto, corresponde ao termo design, em inglês, e Kons-
truktion, em alemão. No Brasil vem-se adotando o termo design para ex-
pressar a área de conhecimento do domínio do desenho industrial ou, em
inglês, o termo industrial design. Os desenhistas industriais brasileiros cos-
tumam chamar-se de designers, para expressar os profissionais que atuam
no domínio de ergonomia, expressão e estética do produto. No Brasil, de
forma geral e neste livro, adotam-se os termos projetar e projetista para ex-
pressar a atividade e o profissional que desenvolve produtos industriais.
Projeto é o resultado da atividade de projetar, e para a ação de projetar
vem-se usando o termo projetação (Ferreira, 1986).
Conforme Ferreira (1986), a palavra projeto é a “idéia que se forma
de executar ou realizar algo no futuro, é um plano, um intento ou desíg-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 6 — #34


i i

6 Projeto Integrado de Produtos: planejamento, concepção e modelagem

nio”. Assim, projeto do produto é um plano de um empreendimento a ser


realizado – um produto, com o fim de atender a uma necessidade. Tradu-
zido do dicionário Oxford (Fowler e Fowler, 1964), projeto ainda pode ser
definido como “um plano mental, um esquema de ataque, visão de um
fim, adaptação de meios para fins (...), esquemas preliminares de um ob-
jeto (...), invenção”. Alguns elementos importantes dessas definições são
os seguintes:

• meios para fins: implica que se projete não para um exercício mental
abstrato, mas para uma meta definida em vista;

• mental: sugere que o projeto é um processo de pensamento. Quando


se projeta, trata-se primeiramente com idéias, com abstrações, em
vez de números. É vital que se desenvolva e aplique a imaginação
para visualizar, realisticamente, a futura concepção do produto;

• plano, esquema: sugere que o projeto é distinto do ponto de vista da


implementação. Diferentes planos podem ser preparados;

• invenção: significa que se está procurando alguma coisa nova, ao


menos parcialmente. A criatividade é crucial para esse propósito.

As definições anteriores são gerais e se aplicam para diferentes tipos de


projetos, desde aqueles pessoais, bem como os governamentais, até aque-
les desenvolvidos pelas empresas de um modo geral. Do ponto de vista
do projeto de produtos de engenharia, outras definições são encontradas
na literatura técnica, conforme exemplos mostrados a seguir.
Projeto de engenharia é o “uso de princípios científicos, informações
técnicas e imaginação na definição de estruturas, máquinas ou sistemas
para desempenhar funções pré-especificadas com máxima economia e
eficiência”. A responsabilidade do projetista ou da equipe de projeto se
estende por todo o processo, desde o estabelecimento das especificações
do mesmo até as instruções detalhadas para a fabricação, uso e descarte
ou desativação, além de atenção especial com segurança e meio ambiente.
Projeto é uma atividade predominantemente cognitiva, fundamentada
em conhecimento e experiência, dirigida à busca de soluções ótimas para
produtos técnicos, a fim de determinar a construção funcional e estrutu-
ral e criar documentos com informações precisas e claras para a fabricação.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 7 — #35


i i

Desenvolvimento integrado do produto – importância para a competitividade 7

Como parte do processo de desenvolvimento do projeto, incluem-se a con-


figuração intelectual e representacional de determinada forma, a escolha
da matéria-prima e o processo de fabricação, assim como tornar possível
e justificável, técnica e economicamente, a realização material ou física do
produto.
O projeto do produto pode ser formulado como o ato, sujeito às res-
trições de resolução, de planejar uma peça ou um sistema para atender
de forma ótima às necessidades estabelecidas, sujeito, ainda, às restrições
de solução. Por restrições de resolução, entende-se aquelas que se relacio-
nam com o conhecimento disponível, o tempo e as facilidades de labora-
tório e de computação para resolver o problema; por restrições de solução,
entende-se aquelas que englobam aspectos de custos, disponibilidade de
materiais, equipamentos de fabricação e de uso, manutenção e descarte.
Como se pode observar, projeto do produto é um plano amplo para
realizar algo, compreendendo aspectos desde a identificação de uma ne-
cessidade até o descarte ou o seu efeito sobre o meio ambiente. O objetivo,
neste livro, é orientar o leitor para a necessidade de uma visão abrangente
do termo projeto do produto, mostrando as preocupações que os projetis-
tas ou equipes de projeto devem ter e quais são os métodos e ferramentas
apropriadas para o desenvolvimento de um produto de alta qualidade.
Quando se fala em qualidade do produto, esse termo tem um significado
bem amplo, isto é, um produto de escopo apropriado, fornecido em tempo
e custo adequados, com especificações de função, de fabricação, uso e ma-
nutenção fáceis e econômicos, seguro, confiável, inofensivo ao meio am-
biente etc. Para conceitos tais como fabricação, montagem e manutenção
fáceis e econômicas, e tantos outros, serão usados os termos fabricabili-
dade, montabilidade e mantenabilidade. Estas são qualidades que o pro-
duto deverá apresentar.
Para desenvolver um produto com eficiência e eficácia, é necessário
saber o que fazer, para quem fazer, quando fazer, com que fazer e como fazer. A
esta organização (conhecimentos, métodos e ferramentas utilizados para
o desenvolvimento) chamar-se-á metodologia de projeto, ou metodologia
de desenvolvimento de produtos. Outros termos encontrados na literatura
são engenharia do produto, projeto de engenharia e teoria de projeto. Na
literatura de língua inglesa encontram-se termos tais como engineering de-
sign, product design e theory of design, e na língua alemã, encontram-se os
termos de Methodisches Konstruieren e Theorie der Konstruktionsprozesse.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 8 — #36


i i

8 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Com a globalização da economia, os produtos devem apresentar alta


qualidade, no mais amplo sentido do termo, ou seja, o produto deve ser
competitivo. Para alcançar essa competitividade o produto deverá ser de-
senvolvido de uma forma integrada, com competências em múltiplas dis-
ciplinas. Assim, não se pode mais falar em projetista, no singular, mas em
equipe integrada de profissionais de diversas funções dentro de um am-
biente de desenvolvimento de produto de uma empresa, universidade ou
instituto de pesquisa, e que atue, simultaneamente, ao longo do processo
de desenvolvimento do produto.
A gerência é importante para que uma equipe de profissionais das
mais diversas competências – desenhistas industriais ou designers; de mar-
keting; de custos; engenheiros mecânicos, eletricistas, eletrônicos, de in-
formática, de materiais, de confiabilidade, de embalagens; assistência téc-
nica; consumidores; fornecedores etc. – alcance bons resultados. Essa ação
de gerência é, genericamente, denominada e encontrada na literatura téc-
nica sob os termos de gestão ou gerenciamento de projetos. Nesta obra
prefere-se usar o termo gerenciamento, ou então, mais especificamente,
gerenciamento do desenvolvimento do produto.

1.3 Breve histórico da área de conhecimento


A atividade de produção é inerente à atividade humana e tem papel
fundamental nas diversas fases de desenvolvimento econômico. Até a Re-
volução Industrial, no século XVIII, os produtos eram elaborados direta-
mente por artesãos. Com o surgimento das fábricas e com o aumento do
volume de produção houve uma divisão do processo de produção em ati-
vidades de projeto, fabricação e comercialização. No século XX, após a
Segunda Guerra Mundial, iniciaram-se estudos da atividade de projeto
como uma disciplina independente. A partir de 1960 encontram-se obras
de autores que tratam da atividade de desenvolvimento de produtos de
uma forma mais sistemática: Asimov (1962), Cain (1969), Krick (1965), Vi-
dosic (1969) e Woodson (1966).
Mais recentemente, na década de 1980, países como os Estados Uni-
dos e a Inglaterra realizaram estudos para identificar razões da perda de
competitividade de seus produtos. Nos estudos da ASME (1985, 1986) e
de Wallace (1987), ficou evidenciado que essas perdas estavam associa-
das a deficiências na qualidade de projeto de seus produtos. Apontou-se

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 9 — #37


i i

Desenvolvimento integrado do produto – importância para a competitividade 9

o planejamento inadequado em ensino e pesquisa de princípios, teorias,


metodologias e ferramentas de apoio ao projeto como um dos principais
fatores. Na Alemanha, contudo, desde a década de 1970, desenvolveu-se
um grande esforço de pesquisa nesta área do conhecimento, como mos-
tram várias obras: Koller (1976), Pahl e Beitz (1977), Rodenacker (1976) e
Roth (1982). Estas são obras publicadas e traduzidas em várias edições, até
os dias atuais.
Após o estudo da ASME (1985), financiado pela National Science Foun-
dation dos Estados Unidos, houve um grande impulso em pesquisas e pu-
blicações de resultados, introduzindo novos conceitos, dentre os quais se
podem citar os seguintes: projeto para o ciclo de vida do produto; projeto
para manufatura; projeto para montagem; projeto para qualidade total;
projeto para competitividade; desdobramento da função qualidade, QFD;
engenharia simultânea; desenvolvimento integrado do produto; sistemas
especialistas em projeto etc. Algumas obras abordando esses aspectos es-
tão listadas a seguir: Andreasen (1983), Blanchard e Fabrycky (1981), Bo-
othroyd (1980), Clausing (1994), Nevins e Whitney (1989), Pugh (1991) e
Ullman (1992).
No Brasil foram poucas as iniciativas de ensino e pesquisa nesta área
de conhecimento. No Departamento de Engenharia Mecânica da UFSC,
foram dados os primeiros passos, em 1976, introduzindo disciplinas de
metodologia de projeto de produtos industriais, na graduação e na pós-
graduação. No início da década de 1980, Back (1983) publicou a primeira
obra em português sobre metodologia de projeto de produtos industriais.
A partir dessa data vários centros brasileiros introduziram esta área de
conhecimento em cursos de graduação e pós-graduação, geralmente nos
cursos de engenharia mecânica, engenharia de produção e desenho indus-
trial. Somente na década de 1990, com a abertura da economia brasileira,
é que houve, por parte da indústria brasileira, uma grande procura de
profissionais com competência em desenvolvimento de produto. Antes, a
indústria brasileira pouco inovava em seus produtos, e o que mais funci-
onava era a adaptação de produtos do exterior, tanto por empresas naci-
onais quanto por internacionais, usando para essa prática um nome mais
sofisticado, o de engenharia reversa.
A Tabela 1.1 dá uma breve idéia da evolução do conhecimento no do-
mínio de desenvolvimento de produtos, sob a ótica da equipe de pesqui-
sadores do NeDIP, do Departamento de Engenharia Mecânica da UFSC.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 10 — #38


i i

10 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Como se pode observar, foram dados novos enfoque e importância à


área de conhecimento, entendendo que a qualidade, a competitividade, o
custo e a redução do tempo de lançamento são, principalmente, alcança-
dos no projeto do produto.

Tabela 1.1 Evolução no campo de conhecimento em projeto de produtos

Cronologia das
Item principais referências Comentários sobre a obra
bibliográficas
Este foi o primeiro livro que apresentou, de forma
1 Asimov (1962) mais orientada, as atividades desenvolvidas ao
longo do processo de projeto de engenharia.
A obra, até esta data, apresentou a melhor visão
sobre o abrangente processo de projeto de
engenharia. Praticamente não usou o termo de
2 Woodson (1966)
projeto ou desenvolvimento de produto, mas é
uma boa obra e descreve de forma sistemática o
desenvolvimento de projetos de engenharia.
Esta talvez seja a primeira obra que adota o termo
de projeto de produtos e, pioneiramente,
apresenta capítulos tais como: projeto para
3 Cain (1969)
função; projeto para uso; projeto para aparência
e projeto para manufatura. Foi muito oportuna na
época.
Foram publicados, neste período, 36 artigos na
revista Konstruktion, descrevendo a prática de
projeto como resultados de pesquisas de diversos
Pahl e Beitz
4 centros na Alemanha. Este pode ser considerado
(1972 a 1974)
um marco inicial e importante para a
sistematização do processo de desenvolvimento
de produtos.
O autor apresentou uma metodologia de projeto
de sistemas técnicos. Está baseada em resultados
5 Koller (1976)
de pesquisas desenvolvidas na Alemanha
semelhantes ao material citado no item 4.
Esta obra é semelhante ao livro de Koller. Também
apresenta uma metodologia de desenvolvimento
6 Rodenacker (1976)
de sistemas técnicos. Os livros dos itens 5 e 6, para
o seu tempo, eram de muito bom conteúdo.
Continua na próxima página

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 11 — #39


i i

Desenvolvimento integrado do produto – importância para a competitividade 11

Tabela 1.1 Evolução no campo de conhecimento em projeto de produtos

Cronologia das
Item principais referências Comentários sobre a obra
bibliográficas
Os autores, no item 4, eram os editores dos artigos
e esta obra é a transformação daqueles artigos
em livro. A obra foi republicada, até o presente
Pahl e Beitz
7 momento, em várias edições, inclusive em inglês.
(1977)
Provavelmente estes dois autores sejam,
mundialmente, os mais referenciados nessa área.
Foi, e ainda é uma excelente obra.
As pesquisas realizadas na Alemanha e descritas
nas obras dos itens 4 a 7 resultaram nesta norma
8 VDI 2222 (1977) que apresenta uma sistemática de projeto de
sistemas técnicos. Em 1985 foi publicada a VDI
2221.
Esta obra é típica de engenharia de sistemas e foi
o livro que, até aquela data, melhor apresentou
uma visão global do processo de
Blanchard e Fabrycky
9 desenvolvimento de produtos. Tinha a visão de
(1981)
projeto do produto para o consumidor e para o
ciclo de vida do produto, próxima da atual visão
da engenharia simultânea.
Esta foi a primeira obra sobre metodologia de
projeto de produtos industriais publicada em
português. O conteúdo fez parte de duas
disciplinas ministradas na pós-graduação em
10 Back (1983) engenharia mecânica da UFSC e cobria aspectos
de projeto do produto. Fundamentou as bases
para pesquisa e ensino em metodologia de
projeto e para o reconhecimento dessa área no
Brasil.
A pesquisa foi realizada pela ASME, procurando
identificar as razões pelas quais os produtos dos
Estados Unidos estavam perdendo
competitividade perante os produtos do Japão e
11 ASME (1985)
da Alemanha. Constatou-se a baixa qualidade do
projeto de seus produtos e, como principal causa,
os descuidos no ensino e pesquisa na área de
desenvolvimento de produtos.
Continua na próxima página

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 12 — #40


i i

12 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 1.1 Evolução no campo de conhecimento em projeto de produtos

Cronologia das
Item principais referências Comentários sobre a obra
bibliográficas
Este artigo apresenta recomendações e diretrizes
para o ensino e pesquisa na área. Os trabalhos
12 ASME (1986) dos itens 11 e 12 podem ser considerados como
um marco para o desenvolvimento dessa área,
especialmente nos Estados Unidos e na Inglaterra.
Wallace e Hales De forma análoga ao item 11, este artigo aborda
13
(1987) o correspondente estudo efetuado na Inglaterra.
Estas três obras representam muito bem um
número elevado de publicações, que surgiram a
Clausing (1994), partir do fim da década de 1980, nas quais são
14 Kusiak (1993) e descritas metodologias de desenvolvimento de
Ullman (1992) produtos com as visões de engenharia simultânea,
qualidade total, desenvolvimento integrado ou
projeto para competitividade.

Como se pode verificar através das obras mostradas na Tabela 1.1, a


partir dos meados da década de 1980, a área de desenvolvimento de pro-
dutos recebeu grande atenção, resultando numa avalanche de publicações,
novos termos, conceitos e siglas. Para citar exemplos, tem-se a seguir, tra-
duzidos para o português, vários termos encontrados na literatura inglesa:
• projeto para o ciclo de vida do produto (Design for Life Cycle – DFLC);
• projeto para o consumidor (Design for Consumer);
• projeto para custo (Design for Cost – DFC);
• projeto para manufatura (Design for Manufacturing – DFM);
• projeto para montagem (Design for Assembly – DFA);
• projeto para meio ambiente (Design for Environment – DFE);
• projeto para confiabilidade (Design for Reliability);
• projeto para mantenabilidade (Design for Maintainability);
• engenharia simultânea (Concurrent Engineering – CE);
• projeto para qualidade (Design for Quality – DFQ);
• projeto para competitividade (Design for Competitiveness); e
• desenvolvimento integrado do produto (Integrated Product Develop-
ment – IPD).

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 13 — #41


i i

Desenvolvimento integrado do produto – importância para a competitividade 13

Assim se poderia estender por muitos outros conceitos, termos e siglas.


Dentro desses conceitos, o importante é destacar que surgiram duas li-
nhas principais de pensamento. A primeira é que o projeto deve ser elabo-
rado tendo em vista certas características ou qualidades do produto. Como
exemplos nesta linha tem-se projetos para: custo; manufatura; montagem;
confiabilidade; mantenabilidade; meio ambiente; entre outros. A segunda
linha refere-se ao processo de desenvolvimento do produto, quanto à mul-
tidisciplinaridade, ao ciclo de vida do produto, à integração de equipes e
à simultaneidade de atividades de desenvolvimento. Nesta linha podem
ser enquadrados: projeto para o ciclo de vida do produto; engenharia si-
multânea; projeto para a qualidade; projeto para competitividade e desen-
volvimento integrado do produto.
Esses princípios, procedimentos, técnicas ou ferramentas serão objeto
de estudo em capítulos posteriores.

1.4 Desenvolvimento de produtos e sua


importância para a competitividade

De acordo com Coutinho (1994), o desempenho competitivo é condi-


cionado por um vasto conjunto de fatores, que podem ser subdivididos
em: internos à empresa, de natureza estrutural, pertinentes aos setores e
complexos industriais; e de natureza sistêmica, como mostra a Figura 1.1.
Os fatores internos à empresa são os que estão sob a sua esfera de de-
cisão e por meio dos quais ela procura se distinguir de seus competidores.
Incluem os estoques de recursos acumulados pela empresa, as vantagens
competitivas que possui e sua capacidade de ampliá-las. Podem-se citar,
entre outros: a capacidade tecnológica e produtiva; a qualidade e a pro-
dutividade de seus recursos humanos; o conhecimento do mercado e a
capacidade de se adequar às suas especificidades; a qualidade e a ampli-
tude de serviços pós-vendas; e as relações privilegiadas com usuários e
fornecedores.
Os fatores estruturais são aqueles que, mesmo não sendo inteiramente
controlados pela organização, estão parcialmente sob sua área de influên-
cia e caracterizam o ambiente competitivo que ela enfrenta diretamente.
Esses fatores se relacionam às características dos mercados consumidores,
à configuração da indústria em que a empresa atua e à concorrência.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 14 — #42


i i

14 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 1.1 Fatores determinantes da competitividade da indústria (adaptado


de Coutinho, 1994)

Os fatores sistêmicos podem ser macroeconômicos, político-institucio-


nais, regulatórios, infra-estruturais e sociais.
Quanto aos fatores internos, em uma empresa produtora de bens ou
produtos, o fundamental é a qualidade dos mesmos, que tem atualmente
um conceito bem amplo, isto é, a qualidade deve estar integrada ao pro-
duto em todo o ciclo de vida. O ponto de partida é o projeto do produto, no
qual devem ser considerados os aspectos de qualidade, desde a atividade
de identificação das necessidades até o descarte.
Hoje em dia estão superadas as visões econômicas tradicionais que
definiam a competitividade como uma questão de preços, custos e taxas
de câmbio. A Figura 1.2 destaca as primeiras fases do projeto do produto e
ainda pode ser útil para uma análise do processo de projeto sob um ponto
de vista atual. Pode-se constatar que o custo do produto fica praticamente
comprometido com as tomadas de decisão nas primeiras fases do ciclo de
vida, isto é, até concluir o projeto detalhado. Como já foi apresentado por
Downey (1969) e, mais tarde, por Barton et al. (2001), isso representa cerca
de 70% ou mais do custo do produto.
Ainda sob a ótica do custo, é interessante observar, na Figura 1.3, que
o custo do projeto é da ordem de 5%, mas o efeito de decisões tomadas
nesta fase afeta 70% do custo total do produto.
Já a Figura 1.4 destaca a importância da atividade de desenvolvimento
do produto. Indica que mudanças a serem feitas, se necessárias, custam

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 15 — #43


i i

Desenvolvimento integrado do produto – importância para a competitividade 15

Figura 1.2 Efeitos das diferentes fases do ciclo de vida sobre o custo do produto
(Downey, 1969)

Figura 1.3 Influências sobre o custo do produto, devido às decisões tomadas,


referentes ao projeto, material, mão-de-obra e instalações (Smith, 1991)

muito pouco no início do desenvolvimento, mas, à medida que o processo


vai avançando nas diferentes fases, esse custo poderá alcançar um fator
dez vezes superior em relação à fase anterior.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 16 — #44


i i

16 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 1.4 Efeito de escala de custos de mudanças do produto nas diversas


fases de desenvolvimento (Huthwaite e Schneberger, 1992)

Como se pode observar, as figuras 1.2 a 1.4 mostram a influência da ati-


vidade de projeto sobre o custo do produto, em sua produção ou ao longo
de todo o ciclo de vida. De forma semelhante, pode-se analisar os efeitos
do projeto de produto sob uma ótica mais atual, considerando conceitos
de valor agregado, qualidade ou competitividade do produto.
Baseado nas observações anteriores, verifica-se que, na atualidade, a
competitividade dos produtos depende fundamentalmente da atividade
de projeto tendo em vista os seguintes fatos:

• de 70% a 90% do custo do ciclo de vida do produto já está compro-


metido com as decisões tomadas até o final do projeto do produto
(Barton, 2001);
• o projeto conceitual de um produto deve ser bem elaborado de iní-
cio, para evitar os elevados custos de modificações em estágios avan-
çados do desenvolvimento (Huthwaite e Schneberger, 1992);
• a aplicação de metodologias ou procedimentos de desenvolvimento
integrado do produto ou de engenharia simultânea têm apresentado
consideráveis vantagens nos seguintes aspectos: redução de tempo
de desenvolvimento do produto, redução de modificações do projeto
e aumento da qualidade sob diversos aspectos.

De acordo com Dixon (1991), as melhores práticas de desenvolvimento


de produtos, retiradas de um levantamento efetuado junto a empresas
mundialmente reconhecidas como competitivas, incluindo Xerox, Pola-
roid, Ford, Hewlett-Packard, Carrier e GE, são as relacionadas a seguir:

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 17 — #45


i i

Desenvolvimento integrado do produto – importância para a competitividade 17

• mecanismos para obtenção e consideração de novas e melhoradas


idéias de produtos e processos, de consumidores, de colaboradores
e de mercado. Esse processo é facilitado e apoiado por um contínuo
fluxo de informações de novas metodologias, materiais e tecnolo-
gias;
• mecanismos para seleção de novas idéias para estudos preliminares
relativos ao projeto, potencial de mercado, fabricação, custos e estra-
tégias empresariais;
• emprego da engenharia simultânea usando equipes multifuncionais
para obtenção da integração da função do produto, dos processos de
manufatura, aspectos de mercado e outras considerações do ciclo de
vida durante o processo de realização do produto;
• estabelecimento de pontos e critérios de decisão bem definidos e de
participantes de decisão, durante o processo de realização do pro-
duto;
• uso máximo da computação no desenvolvimento de protótipos, mé-
todos e tecnologias de simulação;
• especial atenção ao papel de protótipos, seus propósitos, números,
tempos e tecnologias;
• constante pesquisa visando à substituição de materiais;
• comprometimento total da empresa com qualidade, custo e prazos
de lançamento do produto no mercado;
• especial atenção ao controle de processos visando à alta qualidade
ao produto;
• especial atenção a tolerâncias;
• estabelecimento e contínuo refino das medidas de qualidade do pro-
duto, do desempenho do projeto e dos processos de manufatura;
• crescente ênfase na integração de sistemas de tecnologias mecânicas,
eletrônicas, ópticas e de computação;
• uso máximo de concepções baseadas em custos;
• uso máximo de tecnologias computacionais, CAD, modelagem só-
lida, de montagem;
• outras metodologias e tecnologias específicas, tais como projeto para
manufatura, montagem, confiabilidade, segurança, mantenabilida-
de, apoio logístico etc.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 18 — #46


i i

18 Projeto Integrado de Produtos: planejamento, concepção e modelagem

1.5 O ensino para o desenvolvimento de produtos


e seu valor estratégico no Brasil

Durante muito tempo se pensou que a capacitação no domínio de de-


senvolvimento de produtos apenas poderia ser plenamente adquirida com
muitos anos de experiência e, também, por profissionais que tinham cer-
tas aptidões especiais. Dessa forma, pouco se pesquisava por princípios,
métodos, ferramentas ou metodologias de projeto de produtos industriais.
Até o fim da década de 1970, havia uma ampla literatura de projeto, mas
de projetos específicos e mais voltados ao dimensionamento, como projeto
de elementos de máquinas, de máquinas operatrizes, de veículos automo-
tores, de vasos e tubulações sob pressão, sistemas hidráulicos, instalações
hidráulicas e elétricas etc. Dentro do mesmo estilo estavam as disciplinas
ministradas nos cursos tradicionais de engenharia e arquitetura.
Em meados da década de 1970, como já foi mencionado no item 1.3,
iniciou-se na Alemanha um grande esforço de pesquisa por princípios,
métodos e metodologias genéricas de projeto de produtos industriais, que
resultou em obras de ensino de projeto (Konstruktionslehre) e de metodo-
logia de projeto (Methodisches Konstruieren), como mostram as publicações
de Koller (1976), Pahl e Beitz (1977), Rodenacker (1976) e Roth (1982). Essas
obras são, em várias edições, bons textos para o ensino, dando uma visão
ampla do processo de projeto de produtos, mas não sob o ponto de vista
da engenharia simultânea ou de um processo integrado. Na Alemanha,
surgiram vários centros de excelência no ensino e pesquisa nessa área, tais
como Aachen, Berlin, Braunschweig e Ilmenau.
Nos Estados Unidos, o ensino e a pesquisa surgiram com maior inten-
sidade a partir dos resultados publicados pela ASME (1985; 1986). Publica-
ções de Blanchard e Fabricky (1981), Clausing (1994), Pugh (1991), Otto e
Wood (2001) e Ullman (1992) são alguns dos exemplos de bons textos para
o ensino de desenvolvimento de produtos, com uma visão de desenvol-
vimento integrado de produtos ou de engenharia simultânea. O ensino,
nessa área, foi desenvolvido majoritariamente em cursos de engenharia
de produção de instituições como Virginia Polytechnic Institute, Massa-
chusetts Institute of Technology, University of Texas, University of Iowa
etc.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 19 — #47


i i

Desenvolvimento integrado do produto – importância para a competitividade 19

A Tabela 1.2 mostra uma proposta de conteúdo de conhecimento para


capacitação de projetistas, que é uma adaptação da proposta de Dixon
(1991). Essas recomendações, de capacidades de projetistas de produtos
industriais, estão baseadas em levantamentos das melhores práticas de
empresas competitivas, efetuados no trabalho da ASME (1985).

Tabela 1.2 Recomendações para capacitação de projetistas de produtos


industriais (Dixon, 1991)

Capacidades dos Desdobramento das capacidades típicas


Item
projetistas necessárias ao projetista
Conhecer os passos essenciais do processo de
realização de produtos e os processos de
benchmarking competitivo. Compreender o
Projeto de impacto do projeto sobre marketing, finanças,
1 engenharia no manufatura e estratégia da empresa na
contexto do negócio realização de produtos; dos tipos e propósitos dos
protótipos; da qualidade, custo e tempo de
lançamento no processo de desenvolvimento de
produtos.
Conhecer os conceitos e práticas dos processos
Engenharia
de projeto num ambiente de engenharia
simultânea
simultânea, bem como a prática de trabalho e de
2 e princípios de
tomada de decisão em equipes multidisciplinares
trabalho
e multiculturais. Saber elaborar e apresentar
em equipe
relatórios efetivos.
Conhecer os processos de manufatura, suas
características físicas, economias, práticas e
tolerâncias; conhecer e praticar os métodos de
3 Manufatura projeto para manufatura, montagem e ciclo de
vida e os métodos estatísticos de controle de
processos.
Conhecer e praticar selecionados métodos de
modelagem computacional e de processos
Análise e analíticos; desenvolver modelos para análise e
4
prototipagem
simulação de projetos; conhecer métodos de
prototipagem rápida.
Conhecer e saber usar estatística, probabilidade,
5 Estatísticas teoria da decisão e princípios de projeto de
experimentos.
Continua na próxima página

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 20 — #48


i i

20 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 1.2 Recomendações para capacitação de projetistas de produtos


industriais (DIXON, 1991)

Capacidades dos Desdobramento das capacidades típicas


Item
projetistas necessárias ao projetista
Conhecer e saber usar princípios de projeto e
integração de sistemas que deverão conter
6 Projeto de sistemas elementos mecânicos, eletrônicos, ópticos e de
computação.

Projeto assistido por Conhecer e saber aplicar sistemas CAD, CAE, CIM
7
computador – CAD e equivalentes.
Conhecer os principais modelos descritivos,
Teoria e metodologia prescritivos e computacionais de processos de
8
de projeto projeto de produtos industriais. Por exemplo, a
metodologia de Pahl e Beitz.
Saber projetar, reprojetar, avaliar, dimensionar e
otimizar componentes e sistemas, considerando o
Projeto e otimização seu desempenho técnico, de manufatura, custo e
9 de componentes outros aspectos do ciclo de vida do produto.
e sistemas Saber formular problemas para otimização e
desempenhar selecionados métodos de
otimização.
Saber projetar, reprojetar e avaliar montagens
Projeto de
mecânicas considerando o desempenho técnico,
10 montagens e de manufatura, custo, tolerância e outros
de tolerâncias aspectos do ciclo de vida.
Manter-se informado e aprender sobre novos
Novas informações materiais, tecnologias e processos, quando
11
e aprendizagem necessários, através de leituras, discussões,
conferências técnicas e de negócios.

No Departamento de Engenharia Mecânica da UFSC, o ensino nessa


área teve início em 1976, introduzindo no curso de pós-graduação em en-
genharia mecânica duas disciplinas de projeto de produtos industriais,
adotando como material didático textos típicos dos autores Back (1983),
Blanchard e Fabricky (1981), Koller (1976), Pahl e Beitz (1974) e Rode-
nacker (1976). Para ampliar o conhecimento e a prática nessa área, eram
propostas e desenvolvidas dissertações de mestrado e teses de doutorado
tendo como temas o desenvolvimento de protótipos de máquinas e equi-
pamentos. Esses trabalhos tinham como conteúdos os seguintes aspectos:

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 21 — #49


i i

Desenvolvimento integrado do produto – importância para a competitividade 21

levantamento e estabelecimento das especificações de projeto; desenvol-


vimento de concepções alternativas; seleção da melhor concepção; projeto
preliminar e detalhado; construção e testes do protótipo; e, se necessárias,
sugestões para melhoramentos do protótipo. Essa prática tem motivado
muitos alunos que desenvolveram um número considerável de protótipos,
principalmente de máquinas e implementos agrícolas para agricultura de
pequeno porte ou agricultura familiar.
Em 1997, o Laboratório de Projeto foi convertido no atual Núcleo de
Desenvolvimento Integrado de Produtos – NeDIP – e foram introduzi-
das novas disciplinas na pós-graduação: projeto conceitual; modelagem e
simulação de sistemas mecânicos; projeto para manufatura; projeto para
confiabilidade e mantenabilidade; gerenciamento de desenvolvimento de
produtos; sistemas CAE/CAD/CAM; e técnicas de sistemas especialistas
aplicados ao projeto. Na graduação do curso de engenharia mecânica da
UFSC, onde se teve menos flexibilidade para inovações, foram introduzi-
das poucas disciplinas optativas, entre as quais: metodologia de projeto
e mantenabilidade de sistemas mecânicos. Na reforma curricular imple-
mentada, maior ênfase está sendo dada a essa área pela definição desses
conteúdos como obrigatórios.
Desde as atividades de ensino iniciadas em 1974 até os anos 1990, a
demanda na indústria brasileira por profissionais dessa área era pequena.
Foi a época das restrições às importações em que muito se copiava. So-
breviviam produtos de baixa qualidade, devido à falta de interesse e de
investimento em projeto.
A partir do início dos anos 1990, com a abertura da economia brasi-
leira, houve, por parte de instituições de ensino superior e da indústria,
uma procura muito grande por profissionais nessa área.
Atualmente, a indústria nacional precisa inovar concepções e desen-
volver produtos, de alta e integrada qualidade, para alcançar a necessária
competitividade. Para conseguir essa competitividade, um dos fatores im-
portantes é a capacitação de profissionais com conhecimento e formação
para trabalho em equipes, dentro de ambientes de engenharia simultânea,
como descrito anteriormente. Essa consciência, tanto na formação de pro-
fissionais em diversas instituições brasileiras de ensino superior e na orga-
nização de congressos como nas indústrias pela adoção de metodologias
avançadas de desenvolvimento de produtos, tem evoluído muito a partir
de 1990. No Brasil, várias empresas já adotam processos de desenvolvi-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 22 — #50


i i

22 Projeto Integrado de Produtos: planejamento, concepção e modelagem

mento integrado de produtos ou de engenharia simultânea, conceitos que


há dez anos eram somente temas acadêmicos. Cabe aqui mencionar al-
guns exemplos de empresas pioneiras no Brasil, como Embraco, Embraer,
Multibrás, AGCO do Brasil e John Deere do Brasil, que vêm igualmente
cooperando com a academia para o desenvolvimento de pesquisas e capa-
citação de profissionais nessa área.
Cabe advertir às instituições e empresas nacionais, mesmo que sejam
de médio a pequeno porte, que, para o Brasil se tornar uma nação avan-
çada, competitiva, com poder e real equilíbrio nos diversos acordos de
comércio exterior, é necessário conscientizar-se do caráter estratégico da
capacitação de profissionais para o desenvolvimento de produtos de alta
tecnologia e de valor agregado, dentro de conceitos modernos abordados
nesta obra.
O Brasil é competitivo em uma série de produtos, mas, em sua maioria,
possuem pouco valor agregado, como café, soja, suco de laranja, celulose
e minério de ferro. O preço desses produtos, quando comparado ao de
produtos de alta tecnologia, é muito baixo. Consideram-se alguns exem-
plos do comércio mundial de mercadorias: 1 kg de soja custa US$ 0,10, 1
kg de automóvel custa US$ 10, isto é, 100 vezes mais; 1 kg de aparelho
eletrônico custa US$ 100; 1 kg de avião custa US$ 1.000 (10 mil quilos de
soja); e 1 kg de satélite custa US$ 50.000. Uma placa de computador que
pesa 100 g é comprada por US$ 250. Para pagá-la, o Brasil precisa exportar
20 toneladas de minério de ferro. Quanto mais tecnologia agregada tem
um produto, maior é o seu preço e mais empregos foram gerados na sua
fabricação. Os países desenvolvidos sabem muito bem disso. Eles inves-
tem na pesquisa científica e tecnológica e na capacitação de profissionais
capazes de desenvolver esses produtos, o que cria muitos empregos, en-
quanto a extração de minério de ferro possibilita a geração de poucos e
mal remunerados empregos no Brasil.

1.6 Perspectivas futuras no ensino e pesquisa em


desenvolvimento de produtos

Nos últimos anos tem-se publicado muitas pesquisas sobre metodo-


logias mais eficazes de desenvolvimento de produtos industriais e sobre
experiências e métodos de ensino, visando à capacitação em cursos con-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 23 — #51


i i

Desenvolvimento integrado do produto – importância para a competitividade 23

vencionais de graduação e de pós-graduação, bem como à capacitação


continuada de profissionais, procurando encurtar o tempo de formação
e aumentar a produtividade e a eficácia de equipes que atuam em proble-
mas de desenvolvimento de produto.
Segundo experiências do NeDIP e de vários outros relatos, como de
Dixon (1991) e de Lovejoy e Srinivasan (2002), o curso de desenvolvimento
de produto deve apresentar um conjunto de disciplinas genéricas básicas,
conforme já discutido no item anterior, e uma atividade prática de desen-
volvimento de produto na forma mais próxima possível do que ocorre em
um ambiente industrial.
Na graduação, além das disciplinas dos cursos de formação, recomen-
da-se a introdução de, pelo menos, quatro disciplinas: metodologia de pro-
jeto; gerenciamento de projetos, noções de desenvolvimento integrado ou
de engenharia simultânea e princípios básicos de custos e organização de
negócios.
Na pós-graduação, como mestrado profissionalizante ou curso de es-
pecialização, recomenda-se um elenco de disciplinas básicas cobrindo os
seguintes aspectos: processo de desenvolvimento de produtos; engenharia
simultânea; gerenciamento do desenvolvimento de produtos; modelagem
e análise computacional de soluções; metodologia de seleção de materiais
e de processos de fabricação; métodos de estimativas e avaliação de custos;
otimização integrada de produtos; dependabilidade de produtos, também
denominada de garantia de funcionamento; prototipagem rápida; e méto-
dos de ensaios e validação de produtos.
Para tornar mais eficaz a capacitação de profissionais nessa área, é fun-
damental a realização de uma atividade prática de desenvolvimento de
um produto industrial, de complexidade e intensidade de trabalho, com-
patíveis com o tempo e os recursos disponíveis, com as seguintes reco-
mendações:

• as informações a serem apresentadas devem ser na forma de neces-


sidades detectadas ou especificações de um produto que deve ser
projetado e não uma descrição de algo já projetado ou existente que
precisa ser analisado;
• permitir a formação de equipes de três a cinco membros com as
capacidades principais necessárias, por exemplo, para desenvolver
um protótipo de máquina agrícola: engenharia mecânica, engenha-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 24 — #52


i i

24 Projeto Integrado de Produtos: planejamento, concepção e modelagem

ria agrícola, desenho industrial, previsão e análise de custos e instru-


mentação;
• os problemas de projeto devem ser tais que possibilitem à equipe
tomar decisões com o objetivo de gerar alternativas de soluções,
que atendam a um determinado segmento de mercado, um preço
de venda e que se possa fabricar um protótipo com os recursos dis-
poníveis;
• a equipe de desenvolvimento deve tomar decisões quanto à escolha
da melhor solução, não somente em termos de desempenho técnico,
mas de custos, manufaturabilidade e otimização dos vários aspectos
do ciclo de vida do produto;
• o projeto deve ser viável quanto à fabricação de um protótipo, que
seja testado e submetido à avaliação de possíveis usuários, para que
a equipe tenha retorno de avaliações do projeto realizado.

Para facilitar e tornar mais eficiente a capacitação de profissionais e


o processo de desenvolvimento de produtos vem-se, ainda atualmente,
investindo consideráveis recursos em pesquisas, tendo como principais
enfoques:

• organização e gerenciamento de equipe de desenvolvimento de pro-


dutos, visando a melhorar desempenho, eficiência e eficácia;
• desenvolvimento de sistemas de avaliação do desempenho de equi-
pes de projeto e da qualidade do projeto;
• sistematização do conhecimento para o projeto de produtos indus-
triais. Essa sistematização tem como objetivos principais o ensino e o
desenvolvimento de sistemas computacionais de suporte ao projeto.
Dentro dessa linha de pesquisa, tem-se os seguintes exemplos de tra-
balhos: Ogliari (1999), com a sistematização da concepção, auxiliada
por computador, de componentes de plástico injetado; e Maribondo
(2000), com a sistematização do processo de projeto de sistemas mo-
dulares;
• desenvolvimento de sistemas especialistas de projeto de determi-
nados domínios de produtos. Como exemplo é possível citar Silva
(1998), que desenvolveu um sistema especialista para projeto de sis-
temas hidráulicos focando em aspectos de engenharia simultânea;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 25 — #53


i i

Desenvolvimento integrado do produto – importância para a competitividade 25

• sistemas computacionais para o desenvolvimento virtual de produ-


tos ou prototipagem virtual que consiste na aplicação de avançados
sistemas de tecnologia de informações nas atividades do ciclo de
vida do produto (marketing, concepção, modelagem, análise, manu-
fatura, testes, apoio logístico e descarte) em ambientes eletrônicos.

1.7 Resumo

A sistemática adotada neste livro levou os autores a apresentar no final


de cada capítulo um resumo recuperando os pontos-chave para os leitores.
Neste sentido, apresentam-se os principais aspectos deste capítulo:

1. O desenvolvimento do produto compreende aspectos de planejamento e pro-


jeto, ao longo das fases pelas quais passa o produto, desde planejamento,
pesquisa de mercado, projeto do produto, projeto do processo de fabricação,
distribuição, uso, manutenção e descarte.
2. Produto refere-se a um objeto concebido, produzido industrialmente com
determinadas características e funções, comercializado e usado de modo a
satisfazer as necessidades ou desejos de pessoas ou organizações.
3. Para desenvolver um projeto de produto com eficiência e eficácia é necessá-
rio saber o que fazer, para quem fazer, quando fazer, com que fazer e como
fazer. Esta sistemática de desenvolver o projeto de produtos denomina-se
metodologia de projeto de produtos.
4. Desenvolvimento integrado do projeto do produto é uma metodologia por
meio da qual uma equipe multidisciplinar desenvolve um projeto, conside-
rando simultaneamente, ao longo do seu desenvolvimento, as necessidades
e restrições do ciclo de vida do produto.
5. O desenvolvimento de metodologias de projeto de produtos apresenta três
marcos importantes na sua evolução: na Alemanha, com a publicação dos
trabalhos de Pahl e Beitz (1972-1974); nos Estados Unidos, com os traba-
lhos da ASME (1985, 1986); e no Brasil, com a primeira obra em português
por Back (1983).
6. A partir do início dos anos 1990 surgiram duas novas linhas de metodolo-
gias de desenvolvimento do projeto de produtos. Dentro da primeira, a de
qualidades específicas, tem-se os conceitos de projeto para manufatura, para
montagem, para custo e tantos outros que podem ser englobados dentro do

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 26 — #54


i i

26 Projeto Integrado de Produtos: planejamento, concepção e modelagem

termo geral de projeto para x (Design for X). Na segunda linha do pro-
cesso de desenvolvimento do projeto, tem-se projeto para o ciclo de vida do
produto, engenharia simultânea, projeto para competitividade e projeto da
qualidade total, que representam a linha de desenvolvimento integrado do
projeto do produto.
7. Com a globalização da economia, as empresas tiveram de tornar seus produ-
tos competitivos para fazer frente à concorrência internacional. Isso levou
à necessidade de produtos diferenciados, de alto valor agregado e de elevada
qualidade, que são conseguidos, fundamentalmente, com a alta qualidade do
projeto do produto.
8. Alta qualidade de projeto só se consegue com equipes altamente competentes
e capacitadas para o trabalho integrado no desenvolvimento do projeto.
9. O Brasil, para transformar-se numa economia avançada e competitiva, pre-
cisa investir pesadamente na pesquisa e na capacitação de profissionais no
domínio de conhecimento de desenvolvimento de produtos de alta tecnolo-
gia, pois dificilmente se consegue um saldo positivo estável com a predomi-
nância de produtos primários, como é o caso atual.
10. Além da formação básica dos diversos profissionais que atuam em equipes
de desenvolvimento, é recomendável uma capacitação através de discipli-
nas básicas genéricas (planejamento estratégico, gerenciamento de projetos,
processo de desenvolvimento de produtos, engenharia simultânea, modela-
gem e análise computacional de soluções, seleção de materiais e de proces-
sos de fabricação, métodos de estimativas e avaliação de custos, otimização
integrada de produtos, prototipagem rápida, dependabilidade de produtos,
ensaios e validação de protótipos) e trabalho prático (em equipe multidis-
ciplinar) de desenvolvimento de produto, desde a atividade de identificação
das especificações de projeto até a construção e avaliação do protótipo.

1.8 Problemas e temas de discussão

1. Quais são as principais razões que levaram à necessidade atual de


desenvolvimento de um produto através de uma equipe multidisci-
plinar?
2. Quais são as capacidades típicas dos profissionais que integram uma
equipe de desenvolvimento integrado de produtos?

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 27 — #55


i i

Desenvolvimento integrado do produto – importância para a competitividade 27

3. Apresente um exemplo de problema de desenvolvimento de pro-


duto que requer uma equipe multidisciplinar e identifique as disci-
plinas necessárias.
4. Discuta as possíveis razões que levaram a considerar, somente em
anos recentes, a área de projeto de produtos como uma ciência que
pode ser pesquisada por princípios, ferramentas, metodologias, sis-
tematizando o processo de desenvolvimento e, assim, capacitando
os profissionais com cursos formais, não somente por uma longa ex-
periência prática.
5. Quais são as razões que levaram, com a globalização, a considerar
estratégico o domínio de conhecimento de desenvolvimento de pro-
jeto de produtos?
6. Na literatura tem-se o termo ciclo de vida para expressar dois con-
ceitos do produto. Quais são esses dois conceitos e quais são suas
principais diferenças?
7. Quais são as fases típicas pelas quais passa um produto em seu ciclo
de vida? Escolha um produto e defina as fases de seu ciclo de vida.
8. Na literatura tem-se relatado e discutido várias experiências e for-
mas de capacitação de profissionais para integrar equipes de desen-
volvimento de produtos. Discuta essas experiências e formas e apre-
sente, com justificativas, o modo mais eficaz, segundo sua opinião.
9. Discuta as formas e os conteúdos de cursos para capacitação de pro-
fissionais aptos a trabalhar em equipe de desenvolvimento de proje-
tos de produtos.
10. Quais argumentos usaria para justificar a afirmação “o principal fa-
tor para a competitividade de produtos industriais é a qualidade de
seus projetos”?
11. Faça comentários sobre a validade da seguinte afirmação: “o custo
de modificações, se necessárias de uma fase para outra do desenvol-
vimento, é acrescido de um fator de dez”.
12. Por que é importante para as empresas dominarem o processo de
desenvolvimento de produtos?
13. Pesquise na internet, usando as palavras significativas deste texto e
das referências, e identifique congressos, revistas e países onde os
mesmos são publicados.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 28 — #56


i i

28 Projeto Integrado de Produtos: planejamento, concepção e modelagem

14. Discuta o uso de metodologias de desenvolvimento integrado de


produtos nas empresas brasileiras, quem usa, como usam e o que
fazer para que todos usem.

1.9 Referências bibliográficas

ANDREASEN, M. Design for assembly. United Kingdom: Springer


Verlag, 1983.
ASIMOV, M. Introduction to design: fundamentals of engineering de-
sign. Prentice Hall, 1962. Traduzido para o português. Introdução
ao projeto de engenharia. São Paulo: Mestre Jou, 1968.
ASME – National Science Foundation. Goals and priorities for research
on design theory and methodology. Technical report, 1985.
ASME RESEARCH. Design theory and methodology: a new discipline.
Mechanical Engineering. p.23-27. Aug. 1986.
BACK, N. Metodologia de projeto de produtos industriais. Rio de Ja-
neiro: Guanabara Dois, 1983.
BARTON, J. A.; LOVE, D. M.; TAYLOR, G. D. Design determines 70%
of cost? A review of implications for design evaluation. Journal of
Engineering Design. v.12, n.1, p.47-58, 2001.
BLANCHARD, B. S.; FABRYCKY, W. J. Systems engineering and analy-
sis. New Jersey: Prentice Hall, 1981.
BOOTHROYD, G. Design for assembly: a designer’s handbook. Am-
herst, MA: University of Massachusetts, 1980.
CAIN, W. D. Engineering product design. London: Business Books
Ltd., 1969.
CLAUSING, D. Total quality development – a step-by-step guide to
world-class concurrent engineering. New York: ASME Press, 1994.
COUTINHO, L.; FERRAZ, J. C. Estudo da competitividade da indústria
brasileira. Campinas: Papirus, 1994.
DIXON, J. R. Engineering Design Science: new goals for engineering
education. Mechanical Engineering. v.113, n.3, p.56-62, Mar 1991.
DOWNEY, W. G. Development of cost estimating. Report of the Stee-
ring Group for de Ministry of Aviation. England, 1969.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 29 — #57


i i

Desenvolvimento integrado do produto – importância para a competitividade 29

FERREIRA, A. B. H. Novo Dicionário (Aurélio) da Língua Portuguesa.


2.ed. revisada e ampliada, Rio de Janeiro: Nova Fronteira, 1986.
FOWLER, H. W.; FOWLER, F. G. The Concise Oxford Dictionary of
Current English. 5.ed. Great Britain: Oxford University Press, 1964.
HUTHWAITE, B.; SCHNEBERGER, D. Design for competitiveness: the
teamwork approach to product development. EUA: Institute for
Competitive Design, 1992.
KOLLER, R. Konstruktionslehre für den Maschinen, Geräte und Ap-
paratebau. Berlim: Springer Verlag, 1976.
KRICK, E. V. An introduction to engineering and engineering design.
New York: John Wiley & Sons, 1965.
KUSIAK, A. Concurrent engineering: automation, tools and techni-
ques. EUA: John Wiley & Sons, 1993.
LOVEJOY, W. S.; SRINIVASAN, V. Perspective: ten years of experi-
ence teaching a multi-disciplinary product development course. The
Journal of Product Innovation Management. v.19, n.1, p.32-45, 2002.
MARIBONDO, J. de F. Desenvolvimento de uma metodologia de pro-
jeto de sistemas modulares, aplicada a unidades de processamento
de resíduos sólidos domiciliares. Florianópolis, 2000. 277f. Tese de
doutorado – PPGEM – UFSC.
NEVINS, J. L.; WHITNEY, D. L. Concurrent design of products and
processes. McGraw-Hill, 1989.
OGLIARI, A. Sistematização da concepção de produtos auxiliada por
computador com aplicações no domínio de componentes de plás-
tico injetado. Florianópolis, 1999. 349f. Tese de doutorado – PPGEM
– UFSC.
OTTO, K.; WOOD, K. Product design: techniques in reverse enginee-
ring and new product development. New York: Prentice Hall, 2001.
PAHL, G.; BEITZ, W. Für der Konstruktions Praxis. Série de 36 artigos
publicados na revista Konstruktion de 1972 a 1974.
PAHL, G.; BEITZ, W. Konstruktionslehre. 3.ed. Berlim: Springer Verlag,
1977.
PUGH, S. Total design. Wokingham: Addison Wesley, 1991.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 30 — #58


i i

30 Projeto Integrado de Produtos: planejamento, concepção e modelagem

RODENACKER, W. G. Methodisches Konstruieren. 4.ed. Berlim:Sprin-


ger Verlag, 1976.
ROOZENBURG, N. F. M; EEKELS, J. Product design: fundamentals
and methods. England: John Wiley & Sons Ltd., 1995.
ROTH, K. Konstruieren mit Konstruktions Katalogen. Berlim: Sprin-
ger Verlag, 1982.
SILVA, J. C. Expert system prototype for hydraulic system design fo-
cusing on concurrent engineering aspects. Florianópolis, 1998. 185f.
Tese de doutorado – PPGEM – UFSC.
SMITH, P. G.; REINERTSEN, D. G. Developing products in half the
time. New York: Van Nostrand Reinhold, 1991.
ULLMAN, D. G. The mechanical design process. New York: McGraw-
Hill, 1992.
VIDOSIC, J. P. Elements of design engineering. EUA: John Wiley &
Sons, 1969.
VDI 2222. Konstruktionsmethodik, konzipieren technischer Produk-
te. Düsseldorf: VDI – Verlag, 1977.
VDI 2221. Methodik zum entwickeln und konstruieren technischer
Systeme und Produkte. Düsseldorf: VDI – Verlag, 1986.
WALLACE, K. M.; HALES, C. Some applications of a systematic design
approach in Britain. Konstruktion. n.7, p.275-279, 1987.
WOODSON, T. T. Introduction to engineering design. New York: Mc-
Graw-Hill, 1966.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 31 — #59


i i

Capítulo 2

Desenvolvimento integrado do projeto


de produtos

2.1 Introdução

No Capítulo 1 foi mostrado que a qualidade e a competitividade são


conseguidas, principalmente, na fase de projeto do produto. Foi visto tam-
bém que para alcançar competitividade é necessário o desenvolvimento
do produto por uma equipe multidisciplinar em um ambiente coopera-
tivo. Para que essa equipe tenha alta produtividade e um bom desempe-
nho é fundamental que o projeto seja desenvolvido e gerenciado dentro
de um procedimento predeterminado, ou seja, de uma maneira sistemati-
zada e, para tal, a equipe deve ser capacitada e suportada por modelos de
desenvolvimento integrado de produtos.
Neste capítulo serão apresentados aspectos da estrutura do processo e
de sua sistematização no desenvolvimento do projeto do produto. Existem
correntes que afirmam que a sistematização desse processo coloca o pro-
jetista ou a equipe de projeto dentro de uma “camisa-de-força”, tolhendo
sua criatividade. Para problemas de pequeno porte, pode até ser que não
haja necessidade de seguir um longo caminho por meio de procedimen-
tos propostos, mas para projetos de grande porte, como um televisor, um
computador, uma máquina-ferramenta, um automóvel ou um avião, nos
quais trabalham profissionais de várias formações e culturas, é indispen-
sável seguir um procedimento ou uma metodologia predeterminada. Um
projeto desse porte precisa ser planejado, implementado, monitorado e

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 32 — #60


i i

32 Projeto Integrado de Produtos: planejamento, concepção e modelagem

controlado. Planejar um projeto requer a identificação das atividades a se-


rem desenvolvidas, seqüência ou simultaneidade dessas atividades, tem-
pos e recursos necessários, responsabilidade pelas atividades, início e con-
clusão do projeto. Na implementação, várias equipes de trabalho devem
ser gerenciadas e fornecedores compatibilizados em termos de especifica-
ções e prazos dos diversos subsistemas. A qualidade desses subsistemas e
de todo o sistema fica garantida se forem planejadas, monitoradas e con-
troladas as mudanças ao longo do processo. Desenvolver projetos com-
plexos como os anteriormente referidos, sem adotar um determinado pro-
cedimento ou metodologia é inconcebível atualmente. Da mesma forma,
a capacitação dos integrantes das equipes de desenvolvimento fica facili-
tada tendo procedimentos ou metodologias sistematizadas. Essas metodo-
logias devem focalizar: o que fazer, para quem fazer, quando fazer, como fazer
e com que fazer.
É grande o número de proposições de estruturas de procedimentos
ou metodologias de desenvolvimento de projeto de produtos. Essas meto-
dologias são classificadas como descritivas e prescritivas. No item 2.2 são
apresentados aspectos dos principais procedimentos prescritivos. No item
2.3 discutem-se os aspectos das metodologias de desenvolvimento em am-
bientes de engenharia simultânea: sua estrutura, organização, equipes de
projeto, infra-estrutura, dificuldades e fatores de sucesso na implantação,
vantagens e desvantagens de seu uso.
No item 2.4 são mostrados a sistematização do processo de desenvolvi-
mento integrado do projeto de produtos, o resultado de pesquisas desen-
volvidas e as experiências acumuladas nos últimos 20 anos pelo NEDIP.
Como se pode ver adiante, todas essas metodologias são válidas. Os
procedimentos prescritivos tradicionais foram usados por muito tempo
e ainda hoje são empregados por terem dado bons resultados, gerando
produtos existentes na atualidade. A partir de meados de 1980, devido ao
aumento da complexidade dos produtos, exigindo capacitações mais mul-
tidisciplinares, necessidade de redução de tempo de lançamento, redução
de custos e melhore qualidade, para fazer frente à concorrência internacio-
nal, surgiram metodologias de desenvolvimento em ambientes de enge-
nharia simultânea ou de equipes integradas.
A maioria dos procedimentos pesquisados, sistematizados e descritos
na literatura tem seu enfoque no processo de projeto, que é intrínseco a
um processo mais amplo, que é o processo de desenvolvimento do pro-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 33 — #61


i i

Desenvolvimeto integrado do projeto de produtos 33

duto, como mostra de forma bem resumida a Figura 2.1. Esse processo
de desenvolvimento engloba, também, o projeto do processo de manufa-
tura e o planejamento das fases pós-venda: distribuição, transporte, utili-
zação, manutenção e descarte. As metodologias prescritivas apresentadas
no item 2.2 têm seu enfoque no processo de projeto do produto e as me-
todologias do item 2.3 apresentam uma visão mais ampla do ciclo de vida
do produto.

Figura 2.1 Fases do desenvolvimento de produtos

2.2 Análise de modelos prescritivos de


desenvolvimento de produtos

No Capítulo 1, como mostrado na Tabela 1.1, no período do início da


década de 1960 até o fim da década de 1980, surgiram diversas sugestões
de metodologias prescritivas ou estruturas de projeto de produtos. Entre
essas estruturas cabe salientar as contribuições de autores como Asimov
(1968), Back (1983), Coryell (1967), Pahl e Beitz (1996), e Woodson (1966),
que tiveram considerável influência em várias outras propostas de meto-
dologias de projeto que surgiram na literatura.
A Figura 2.2 mostra a estrutura proposta por Asimov (1968, p.23). O ci-
clo de produção-consumo, como era chamado, se decompõe em sete fases.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 34 — #62


i i

34 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Destas, três referem-se ao projeto de engenharia, à exeqüibilidade, ao pro-


jeto preliminar e ao projeto detalhado. As demais fases, tradicionalmente
não consideradas como atividades de projeto, referem-se ao planejamento
da manufatura, da distribuição, do consumo e da retirada.

Figura 2.2 Fases do ciclo produção-consumo do produto (Asimov, 1968)

Na fase I, no estudo da exeqüibilidade, a partir das necessidades iden-


tificadas desenvolviam-se soluções alternativas. Dentre estas, as melho-
res eram selecionadas, adotando como critérios as análises de viabilidade
técnica, econômica e financeira. Na fase II, durante o projeto preliminar,
buscava-se a melhor solução através da modelagem da solução, da aná-
lise de sensibilidade, compatibilidade e estabilidade, da otimização for-
mal, de projeções futuras, da revisão do comportamento do sistema e da
verificação final da concepção do projeto. Na fase III, no projeto detalhado,

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 35 — #63


i i

Desenvolvimeto integrado do projeto de produtos 35

elaboravam-se descrições de engenharia de um projeto viável e conferido,


e desenvolviam-se o leiaute e o relatório final do projeto. Como passos
dessa fase, tinham-se: preparação e projeto geral dos subsistemas; projeto
geral dos componentes; preparação dos desenhos de montagem; constru-
ção experimental e testes do protótipo; análise; e revisão.
A Tabela 2.1 mostra uma adaptação da proposta de estrutura de Wood-
son (1966, p.26-27), com quatro fases: estudo de viabilidade; projeto pre-
liminar; projeto detalhado e revisão do projeto. O autor apresentou es-
sas fases numa forma de fluxograma, desdobradas em atividades, e, para
cada uma das atividades, indicou entradas, saídas, informações ou recur-
sos necessários; e cada saída submetida à verificação quanto à conformi-
dade com os requisitos de projeto. Não havendo conformidade, indicava o
retorno a atividades anteriores para as modificações e melhoramentos ne-
cessários. Na adaptação para a Tabela 2.1, além das entradas indicadas na
segunda coluna, para cada atividade são mostradas as respectivas saídas
na última coluna.
A estrutura de projeto de Woodson (1966) é uma pequena evolução
em relação à estrutura proposta por Asimov (1962) nos seguintes aspec-
tos: apresenta um maior desdobramento das fases em atividades, como
mostrado na Tabela 2.1; para cada uma das atividades são indicadas in-
formações ou conhecimentos de entrada; as saídas de cada atividade são
avaliadas e comparadas com os requisitos; e, não havendo conformidade,
são indicados retornos a atividades anteriores para modificações ou me-
lhoramentos necessários.
Outra sugestão interessante de estrutura do processo de projeto foi
apresentada por Coryell (1967), que desdobra a sistemática em doze pas-
sos, como mostra a Figura 2.3. Essa estrutura traz como inovação cinco
símbolos de válvula colocados no fluxo do processo. Nesse caso a válvula
tem o significado de uma revisão e avaliação do projeto em desenvolvi-
mento, que só seguirá adiante se a solução atender às especificações do
projeto. Essa válvula, já sugerida em 1967, é uma precursora do atual con-
ceito de gate usado em certas metodologias e difundido na indústria.
No início dos anos 1970, na Alemanha, houve um grande esforço de
pesquisa sobre princípios e metodologias de projeto de produtos. Dessas
pesquisas resultaram várias obras, como já se viu no Capítulo 1, e a mais
conceituada é a de Pahl e Beitz (1996), publicada primeiramente em 1977
e, posteriormente, em várias edições em alemão e inglês. Nessa obra está

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 36 — #64


i i

36 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 2.1 Estrutura do processo de projeto de produtos (adaptado de


Woodson, 1966)

Fases Entradas Atividades Saídas


Informações gerais e Analisar Resultados
de mercado necessidades desejados
Informações Explorar sistemas Proposições
Viabilidade do projeto

tecnológicas envolvidos técnicas


Métodos de Sintetizar soluções Soluções
criatividade alternativas propostas
Experiência Avaliar viabilidade Viabilidade
tecnológica física física
Informações de Avaliar viabilidade Viabilidade
custos e preços econômica econômica
Informações sobre
Avaliar viabilidade Conjunto de
riscos de
financeira soluções possíveis
investimentos
Estudo de
Selecionar a melhor Solução
viabilidade e
solução selecionada
experiência geral
Modelo de estrutura
Habilidade Formular
e/ou de
matemática modelos
Projeto preliminar

desempenho
Analisar sensibilidade Grau de
Habilidade
e compatibilidade sensibilidade
matemática
das variáveis das variáveis
Habilidade Otimizar parâmetros Dados sobre os
matemática de projeto parâmetros
Tecnologias de Testar processo e
Previsões
laboratório prever desempenho
Experiências de Projeto
Simplificar
engenharia melhorado
Projeto preliminar
Especificar
Projeto detalhado

e conhecimentos Subsistemas
subsistemas
tecnológicos
Conhecimentos Especificar
Componentes
tecnológicos componentes
Conjunto de
Conhecimentos Especificar
desenhos
tecnológicos partes
detalhados
Continua na próxima página

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 37 — #65


i i

Desenvolvimeto integrado do projeto de produtos 37

Tabela 2.1 Estrutura do processo de projeto de produtos (adaptado de


Woodson, 1966)

Fases Entradas Atividades Saidas


Experiência Desenhar conjuntos Desenhos de
Projeto detalhado

tecnológica de montagem montagem


Conjunto completo
Experiência de Verificar dimensões
de desenhos e
desenho e normas e normas
especificações
Informações de Liberar para Projeto para
gerência manufatura manufatura
Projeto detalhado,
habilidades de Fabricar Sistema
fabricação e componentes operacional
materiais
Técnicas de Testar desempenho Dados de teste
Revisão do projeto

teste na fábrica do sistema


Técnicas de Testar em campo Dados de
teste e para durabilidade teste
Técnicas de Auditar qualidade Dados sobre
auditoria de manufatura variações
Informações Mudar para
Projeto
de manufatura eliminar problemas
melhorado
e de vendas de qualidade
Custo reduzido e
Experiência de Simplificar para
sistema ou produto
engenharia reduzir custos
em produção

descrita a sistemática mais referenciada dentro da linha de metodologias


prescritivas.
Esses autores estabelecem o processo de projeto em quatro fases prin-
cipais: a definição da tarefa; o projeto conceitual; o projeto preliminar (de
configuração); e o projeto detalhado. A Figura 2.4 mostra esse processo,
indicando as ações e os resultados de cada fase.
Na fase de definição da tarefa, o estudo do problema resulta na elabo-
ração da lista de requisitos. A idéia básica desse estudo é fixar as funções
requeridas, as grandezas de entrada e saída e as perturbações externas ao
problema. Na elaboração da lista se distinguem os requisitos obrigatórios
dos desejáveis. Os obrigatórios devem ser atendidos sob quaisquer cir-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 38 — #66


i i

38 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 2.3 Estrutura do processo de projeto de produtos (Coryell, 1967)

cunstâncias e os desejáveis são considerados, principalmente, em função


de critérios econômicos.
A lista de requisitos constitui o ponto de partida na resolução da tarefa
de projeto. Deve ser atualizada permanentemente com as alterações sur-
gidas no decorrer do projeto. Para o estabelecimento da lista de requisitos,
os autores apresentam algumas recomendações:

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 39 — #67


i i

Desenvolvimeto integrado do projeto de produtos 39

Figura 2.4 Fases do processo de projeto de Pahl e Beitz (1996)

• coletar os requisitos: fazer uso de uma lista inicial básica; questio-


nar quais objetivos a solução deve satisfazer; que propriedades ela
deve ter ou não; coletar informações adicionais e distinguir entre re-
quisitos obrigatórios e desejáveis, classificando estes últimos por sua
importância;
• arranjar os requisitos em uma ordem clara, relacionando-os com a
parte do sistema a que se referem (subsistemas, funções, montagens
etc.);
• registrar os requisitos e colocá-los à prova;
• examinar sugestões incluindo complementações necessárias.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 40 — #68


i i

40 Projeto Integrado de Produtos: planejamento, concepção e modelagem

A conclusão dessa etapa se dá com o acordo entre as partes envolvidas


no projeto (pessoal técnico, fornecedores, consumidores, gerentes etc.) a
respeito da lista de requisitos estabelecida. Esta servirá de base para as
etapas seguintes do processo de projeto, iniciando com a concepção.
O desenvolvimento da concepção, ou do projeto conceitual, segundo
Pahl e Beitz (1996) será descrito em mais profundidade no Capítulo 7. En-
tre esses passos que serão mostrados tem-se: abstração para identificar os
problemas essenciais; estabelecimento da estrutura de funções; busca de
princípios de soluções e suas combinações; obtenção de variantes de con-
cepções; sua concretização; e, finalmente, avaliação segundo critérios téc-
nicos e econômicos.
Uma vez que o problema central tenha sido formulado é possível indi-
car uma função global que, baseada no fluxo de energia, material e sinal,
expresse o relacionamento entre entradas e saídas independentemente da
solução. O desdobramento feito a partir da função global, em subfunções
de níveis menores de complexidade, corresponde ao passo do estabeleci-
mento da estrutura de funções. Em projetos originais, as subfunções e o
relacionamento entre elas não são bem conhecidos. Nesse caso, o estabele-
cimento da estrutura de funções constitui um dos passos mais importantes
do projeto conceitual. No caso de projetos variantes ou adaptativos, esse
passo é realizado através da análise dos sistemas existentes. O objetivo da
estrutura de funções é facilitar a descoberta de soluções uma vez que se
trabalha em um nível menor de complexidade (subfunções).
O passo seguinte, a pesquisa de princípios de soluções, é realizado
para satisfazer as subfunções identificadas no passo anterior. Para concre-
tizar esse passo, faz-se uso de pesquisa bibliográfica, análise de sistemas
naturais, análise de sistemas existentes e métodos de criatividade diver-
sos, como será descrito no Capítulo 6.
A combinação de princípios de solução, o quarto passo, tem por ob-
jetivo satisfazer a função global associando os princípios de solução. A
base de tais associações é a estrutura de funções. Devem-se assegurar a
compatibilidade geométrica e física entre os princípios, o fluxo regular de
energia, material e sinal e a viabilidade técnica e econômica. O método
da matriz morfológica, a ser estudado no Capítulo 6, pode ser usado para
a associação ou combinação dos princípios de solução das subfunções e,
assim, construir concepções alternativas do problema.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 41 — #69


i i

Desenvolvimeto integrado do projeto de produtos 41

O passo seguinte corresponde à seleção das combinações identifi-


cadas no passo anterior. Isso pode ser feito, inicialmente, eliminando
as combinações inadequadas (fisicamente impraticáveis), selecionando e
ordenando as demais, usando critérios como os seguintes: compatibili-
dade com a tarefa global; satisfação dos requisitos obrigatórios; desem-
penho; custos; ergonomia; segurança e preferências pessoais. Conclui-se
esse passo com um conjunto de soluções viáveis.
A concretização em variantes de concepção tem por objetivo ob-
ter maiores informações sobre as combinações viáveis considerando um
maior número de critérios que a solução deve satisfazer.
Finalmente, na avaliação das variantes de concepção as soluções são
comparadas para estabelecer as melhores variantes.
A fase do projeto preliminar (ou de configuração, como chamam os
autores) se inicia com uma concepção técnica e economicamente avaliada.
A idéia básica é satisfazer uma dada função com a forma dos componen-
tes, leiaute e materiais apropriados. O processo começa com um leiaute
preliminar, em escala, baseado nos requisitos espaciais e prossegue consi-
derando critérios de segurança, ergonomia, manufatura, montagem, ope-
ração, manutenção e custos.
O projeto detalhado finaliza o projeto preliminar, estabelecendo as des-
crições definitivas para a disposição dos elementos, forma, medidas, aca-
bamentos superficiais, materiais, a verificação do projeto e dos custos de
fabricação. São elaborados os documentos finais do projeto na forma de
desenhos que possibilitam a realização física das soluções. De acordo com
a empresa onde o projeto será executado, faz-se uso de uma série de nor-
mas e procedimentos padrão.
As pesquisas da escola alemã resultaram, primeiramente, na VDI 2222
(1977) e, mais tarde, na VDI 2221 (1985), que apresentam uma estrutura
para o processo de projeto como a ilustrada na Figura 2.5. Essa estrutura
contém quatro fases e é desdobrada em sete passos. Os diversos passos
dessa metodologia, as atividades e os resultados obtidos são semelhantes
aos descritos na metodologia de Pahl e Beitz.
Para o desenvolvimento do projeto, a metodologia de Pahl e Beitz é
a mais adotada das metodologias prescritivas descritas nesse item. Atual-
mente, várias são as tentativas de desenvolvimento de sistemas computa-
cionais ou de sistemas especialistas de apoio ao projeto de sistemas técni-
cos e, em geral, são baseadas na metodologia de Pahl e Beitz, como, por

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 42 — #70


i i

42 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 2.5 Procedimento geral para o projeto de sistemas segundo a VDI 2221
(1985)

exemplo, os trabalhos de Hundal (1997). O NeDIP também tem desenvol-


vido suas pesquisas e dirigido seus trabalhos baseado nesta metodologia,
combinada aos conceitos de engenharia simultânea.
As metodologias prescritivas descritas anteriormente são considera-
das do tipo seqüencial, ou seja, as atividades do processo de desenvolvi-
mento de projeto são efetuadas em série, tanto pelo cronograma de exe-
cução quanto pelas disciplinas envolvidas em cada atividade: primeiro
os especialistas em marketing preparam uma lista de necessidades para
o produto, os projetistas elaboram o projeto do produto, passam a docu-
mentação para os especialistas em manufatura para planejar os processos
de fabricação, e assim por diante. Esses procedimentos têm apresentado
muitos problemas de conformidade com as especificações nas interfaces
das disciplinas ou dos departamentos funcionais. As principais críticas a
essas metodologias podem ser assim resumidas:

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 43 — #71


i i

Desenvolvimeto integrado do projeto de produtos 43

• as atividades propostas nessas metodologias de projeto são seqüen-


ciais;
• o processo é controlado por revisões formais ao final de cada fase;
• não contemplam as características do contexto industrial (pressões,
ambiente, linguagem, cultura organizacional, formação dos projetis-
tas, entre outras);
• não prescrevem claramente a integração entre os conhecimentos ne-
cessários para o desenvolvimento do produto;
• são baseadas nas habilidades individuais dos projetistas;
• freqüentemente não prescrevem meios formais de transferência de
informações entre as fases do desenvolvimento;
• as alterações necessárias são identificadas e realizadas muito tarde
no processo de desenvolvimento do produto.

Esses problemas são atenuados com a adoção de metodologias de de-


senvolvimento integrado e equipes multidisciplinares ou multifuncionais
de trabalho. Um primeiro passo nesse sentido foi dado com a metodologia,
denominada de projeto para o ciclo de vida do produto, descrita por Ben-
jamin S. Blanchard e Wolter J. Fabrycky em 1981 (Blanchard e Fabrycky,
1990). Essa metodologia define que o desenvolvimento do produto, ao
longo do seu processo, deve considerar, concomitantemente, os requisi-
tos e as restrições de todas as fases do ciclo de vida do produto. Ela tem
sido adotada, também, sob a denominação de C2C, que tem origem no
termo “Consumer to Consumer” (consumidor a consumidor). A metodolo-
gia pode ser considerada uma precursora da engenharia simultânea ou de
desenvolvimento integrado do produto como descrito a seguir.

2.3 Desenvolvimento de produtos no ambiente


de engenharia simultânea

Em termos gerais, reconhece-se, hoje, que as decisões tomadas nas fa-


ses iniciais do projeto do produto têm um efeito significativo na manufa-
turabilidade do produto, em sua qualidade, nos custos de produção, além
de outros fatores. Essas decisões diferem em suas naturezas e nas condi-
ções sob as quais são tomadas. Nos procedimentos tradicionais de projeto

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 44 — #72


i i

44 Projeto Integrado de Produtos: planejamento, concepção e modelagem

há mais riscos de não considerar a completeza necessária de informações


sobre o produto, do que há no desenvolvimento em um ambiente de enge-
nharia simultânea. Alguns exemplos típicos de decisões e condições que
podem afetar as diferentes fases do projeto do produto são:

• na definição das especificações de projeto, quando se está trabalhan-


do com informações qualitativas e muitas vezes insuficientes, por
não considerar a amplitude de conhecimentos necessários;
• na definição da concepção do produto, quando as informações são
abstratas e pela possibilidade de os dados para julgamento serem
insuficientes;
• na configuração mais apropriada para um princípio de solução,
quando o tempo disponível é insuficiente e já existem soluções pre-
concebidas;
• na definição dos parâmetros de componente, quando os riscos são
elevados e se dispõe de poucos recursos para análise e simulação.

Dos exemplos anteriores pode-se inferir que as decisões não acertadas


durante o projeto podem comprometer, em maior ou menor grau, o de-
sempenho do produto nas demais fases do processo de desenvolvimento.
Por exemplo, uma lista de especificações mal definida pode desencadear
processos de solução e decisões de projeto cujos resultados não representa-
rão as reais necessidades dos clientes. De maneira similar, uma definição
inadequada da concepção do produto pode resultar em comportamento
fora do especificado durante o uso. Configurações mal definidas podem
representar acréscimo nos custos do produto e dificuldades de forneci-
mento de componentes e, por último, dimensões inadequadas podem oca-
sionar, além de dificuldades de fabricação, refugos de peças produzidas.
Esses exemplos reforçam a importância em adotar práticas adequa-
das ao desenvolvimento de produtos, procurando-se minimizar decisões
empíricas ou por tentativa e erro; sugerem ainda que as abordagens tra-
dicionais de projeto devem ser revistas, principalmente com relação ao
envolvimento dos vários interessados no desenvolvimento do produto
(stakeholders), já que as decisões do processo de projeto podem afetá-los
diretamente. Nessa direção, têm surgido diferentes propostas para o de-
senvolvimento de produtos baseados na engenharia simultânea, as quais
serão apresentadas nos itens que seguem.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 45 — #73


i i

Desenvolvimeto integrado do projeto de produtos 45

2.3.1 Engenharia simultânea: definições e princípios

A Engenharia Simultânea (ES) de modo geral, tem sido apontada como


filosofia, metodologia ou prática de desenvolvimento de produto. Apesar
das diferentes conotações, seus princípios gerais são comuns e devem ser
investigados para a compreensão dessa abordagem de desenvolvimento
de produtos e identificação dos meios pelos quais ela pode ser inserida
nas atividades das empresas. Nesse sentido, esse tópico procura apresen-
tar as principais definições e princípios da engenharia simultânea, visando
indicar, ao final, os caminhos para a adoção dessa metodologia. Em outras
palavras, procura-se identificar os elementos que caracterizam a engenha-
ria simultânea, sejam eles os identificados nas definições propostas ou os
caracterizados pelos diferentes autores.
A seguir, algumas das definições para a engenharia simultânea e suas
respectivas fontes:
Prasad et al. (1998) – “A engenharia simultânea é uma abordagem sis-
temática que considera todos os aspectos do gerenciamento do ciclo de
vida do produto, incluindo integração do planejamento, projeto, produ-
ção e fases relacionadas”.
Smith (1997) – “A engenharia simultânea é um termo aplicado para
uma filosofia de cooperação multifuncional no projeto de engenharia, a
fim de criar produtos que sejam melhores, mais baratos e introduzidos no
mercado mais rapidamente”.
Sprague et al. (1991) – “A engenharia simultânea é uma abordagem sis-
temática para o projeto simultâneo e integrado de produtos e de processos
relacionados, incluindo manufatura e suporte. Procura considerar todos
os elementos do ciclo de vida do produto, desde a concepção até o des-
carte, incluindo qualidade, custo, programação e requisitos dos usuários”.
Outras definições consideram, ainda, a engenharia simultânea como
modelos de gestão do desenvolvimento do produto (Chiusoli e Toledo,
2000, Hyeon et al., 1993 e Ishii et al., 1989), na forma de gerenciamento da
compressão do tempo, gerenciamento do tempo para o mercado, gerencia-
mento do ciclo temporal etc. Na presente obra considera-se a engenharia
simultânea como uma metodologia de desenvolvimento integrado do pro-
duto, pois suas diretrizes e formulação são similares ao que é entendido
por metodologia.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 46 — #74


i i

46 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Por meio de diferentes definições para a engenharia simultânea, po-


dem-se sintetizar alguns elementos que auxiliam na compreensão inicial
desse tema e sugerem algumas questões importantes para reflexão. Esses
elementos, conforme destacados nas definições e outras variáveis da enge-
nharia simultânea, segundo Chiusoli e Toledo (2000), estão representados
na Figura 2.6. De acordo com ela, existem diferentes categorias de elemen-
tos associados à engenharia simultânea. Essas categorias podem ser esta-
belecidas na forma de princípios e variáveis da engenharia simultânea. Os
princípios estabelecem os elementos predominantes, as causas, as propo-
sições diretoras, admitidas provisoriamente válidas, de filosofia e prática
da engenharia simultânea. As variáveis, por sua vez, são elementos que
podem assumir diferentes aspectos, segundo os casos particulares ou as
circunstâncias do estado de implantação e prática da engenharia simul-
tânea em dada organização. Nesse sentido, os princípios da engenharia
simultânea pressupõem os seguintes aspectos:

• tratamento simultâneo de restrições de projeto e manufatura;


• compartilhamento de conhecimentos associados ao desenvolvimen-
to do produto;
• consideração do ciclo de vida do produto;
• ênfase às preferências dos consumidores no desenvolvimento do
produto;
• desenvolvimento do produto considerando qualidade, custo e tem-
po para o mercado.

Em outra forma, as variáveis associadas à engenharia simultânea po-


dem ser estabelecidas da seguinte maneira:
• configuração de equipes de projeto;
• paralelismo das atividades de projeto;
• integração dos clientes do projeto;
• utilização de ferramentas de apoio.
Diante desses elementos, algumas questões podem ser formuladas
para refletir sobre a metodologia da engenharia simultânea:

• É possível um indivíduo, na realização de suas tarefas individuais,


aplicar princípios da engenharia simultânea?

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 47 — #75


i i

Desenvolvimeto integrado do projeto de produtos 47

Figura 2.6 Síntese dos principais elementos associados à engenharia simultânea

• Como os modelos da engenharia simultânea devem ser configura-


dos para inserir aqueles elementos?
• Como a prática da engenharia simultânea pode ser implantada?

O item que segue, sobre modelos de engenharia simultânea, procura


responder parte dessas questões, estabelecendo estruturas que associam
logicamente os elementos considerados.

2.3.2 Engenharia simultânea: modelos

Em geral, os modelos de engenharia simultânea têm sido propostos


comparando-se o processo de desenvolvimento de produto, na forma se-
qüencial com aquele na forma paralela, como pode ser observado na Fi-
gura 2.7, conforme apresentada por Yazdani e Holmes (1999).
Fica clara, na figura, a redução do tempo na abordagem de engenha-
ria simultânea, pela adoção do paralelismo entre as fases do desenvolvi-
mento, quando comparada à engenharia seqüencial. Entretanto, esse mo-
delo pouco destaca os elementos envolvidos nessa metodologia. Na ver-
dade, o modelo apenas captura um dos elementos da engenharia simultâ-
nea, ou seja, o tempo de desenvolvimento do produto. Os demais elemen-
tos, como a qualidade, a redução do custo, o desenvolvimento integrado
do produto, o gerenciamento do desenvolvimento do produto, entre ou-
tros, embora possam estar implícitos, não são devidamente representados.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 48 — #76


i i

48 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 2.7 Engenharia seqüencial e simultânea (adaptado de Yazdani e


Holmes, 1999)

Outro modelo que expressa os demais elementos da metodologia


da engenharia simultânea, apresentado também por Yazdani e Holmes
(1999), está mostrado na Figura 2.8. Neste, além do paralelismo entre as
fases do desenvolvimento, verifica-se a existência de elementos de revi-
são entre cada fase e elementos de informação, sendo transferidas durante
o paralelismo das fases. A transferência das informações é facilitada por
intermédio de equipes multifuncionais e ocorre, em grande parte, de ma-
neira informal.
Outro aspecto importante da modelagem é a visualização da integra-
ção através dos recursos computacionais para configurar o ambiente da
prática da engenharia simultânea. Nessa linha, são encontrados vários
modelos, geralmente dedicados a domínios específicos, como é o caso de
produtos de plástico injetado, mostrados na Figura 2.9. A prática da en-
genharia simultânea se dará, por exemplo, durante um determinado pro-
cesso de decisão, quando o projetista conta com as recomendações especia-
lizadas, considerando as regras de cada especialidade envolvida no pro-
cesso de desenvolvimento do produto.
Conforme é possível detectar nos modelos anteriores, procura-se de-
senvolver as habilidades necessárias para satisfazer simultaneamente os
consumidores e os interesses da empresa com relação a tempo, custo e

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 49 — #77


i i

Desenvolvimeto integrado do projeto de produtos 49

Figura 2.8 Modelo de definição da engenharia simultânea (adaptado de


Yazdani e Holmes ,1999)

Figura 2.9 Ambiente computacional para o projeto conceitual do produto sob


o enfoque da engenharia simultânea

qualidade do produto. Sob esse ponto de vista, a cooperação é o elemento-


chave pelo qual as equipes podem melhorar suas habilidades para resol-
ver os problemas e atender às necessidades dos consumidores e da orga-
nização.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 50 — #78


i i

50 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Assim, a modelagem do processo de trabalho, quando desenvolvida


no contexto da engenharia simultânea, deve apresentar as seguintes qua-
lidades:

• ser representada na forma de uma estrutura de relacionamentos en-


tre os elementos envolvidos: isso se deve porque um processo de tra-
balho não é apenas um grupo de atividades, mas envolve elementos
tais como o produto, a organização, os recursos e o fluxo de traba-
lho. O elemento produto é o resultado de um processo de trabalho,
e os elementos da organização e os recursos suportam o processo de
trabalho para obter o produto;
• apresentar uma decomposição hierárquica: um processo de trabalho
pode variar desde uma pequena atividade (como editar um arquivo)
até grandes atividades de engenharia (como desenvolver um novo
tipo de avião). Essa decomposição possibilita identificar interfaces
entre as equipes de trabalho;
• distribuir as tarefas paralelamente: viabiliza o trabalho simultâneo
entre as equipes de trabalho durante a realização das respectivas ta-
refas;
• estabelecer um diagrama de fluxo de informações: nesse modelo
procura-se representar quem faz (pessoa ou equipe) determinada
atividade e a seqüência dos tempos nos quais as atividades são rea-
lizadas (Figura 2.10);
• refinamento progressivo: o modelo de processo deve ser criado de tal
modo que possa evoluir progressivamente à medida que o produto
se desenvolve ao longo dos vários estágios de desenvolvimento.

Conforme se observa, os modelos anteriores procuram expressar os


diferentes elementos envolvidos na engenharia simultânea para o desen-
volvimento de produtos. Desde o paralelismo das atividades, fluxo de in-
formações entre as atividades, desenvolvimento integrado, uso de ferra-
mentas de apoio, equipes multidisciplinares, ciclo de vida do produto e
gerenciamento do desenvolvimento do produto. Procura-se mostrar que a
abordagem da engenharia simultânea promove meios adequados para de-
senvolver o produto, buscando satisfazer às necessidades dos envolvidos,
seja pelo baixo custo de desenvolvimento, pelo menor tempo de desenvol-
vimento ou pela melhor qualidade dos produtos resultantes.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 51 — #79


i i

Desenvolvimeto integrado do projeto de produtos 51

Figura 2.10 Diagrama de fluxo de informações

Verifica-se, também, que essas abordagens tratam do desenvolvimento


do produto, desde o mercado até a fabricação e a distribuição, não de-
senvolvendo em detalhes a engenharia simultânea do ponto de vista do
processo de projeto. Nesse sentido, conforme mostrado na Figura 2.11,
procura-se expressar o procedimento da engenharia simultânea em con-
junto com o gerenciamento do projeto e conceito de ciclo de vida do pro-
duto, num modelo para o processo de projeto do produto, que é estabele-
cido através de quatro fases principais: informacional, conceitual, prelimi-
nar e detalhado.
Encontram-se, no núcleo, os processos da organização e, neste caso
particular, o processo de projeto. Esses processos são representados sob
certos princípios da engenharia simultânea; no caso, o paralelismo entre
fases, a realização de fases por equipe multidisciplinar e a troca de infor-
mações entre as fases.
Suportando os processos encontram-se quatro campos de conhecimen-
tos principais: metodologia, gerenciamento, ciclo de vida e tecnologia de
informação. O campo da metodologia fornece subsídios metodológicos na
forma de métodos e ferramentas para conduzir as atividades de projeto,
visando à transformação das informações. O campo do gerenciamento ofe-
rece subsídios gerenciais aos processos, visando sua execução dentro do
escopo, tempo, custo e qualidade desejados. O campo do ciclo de vida for-
nece subsídios de informações para as decisões e soluções de projeto, com
o objetivo de antecipar potenciais problemas. O campo da tecnologia da

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 52 — #80


i i

52 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 2.11 Modelo integrado para o projeto do produto

informação proporciona subsídios computacionais em termos de base de


dados e ferramentas para conduzir as atividades de projeto, aplicações de
metodologia e gerenciamento do projeto.
A partir do modelo da Figura 2.11 é possível visualizar e inferir uma
série de estudos e desenvolvimentos necessários para suportar as ativida-
des de projeto. Dentre estes, destacam-se:

• o estudo de modelos genéricos do ciclo de vida do produto, ou de-


dicados a domínios específicos de aplicação;
• desenvolvimento e implementação de métodos de projeto;
• desenvolvimento e implementação de métodos de gerenciamento de
projeto;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 53 — #81


i i

Desenvolvimeto integrado do projeto de produtos 53

• desenvolvimento de ferramentas computacionais de apoio ao pro-


jeto.

De acordo com o que foi apresentado nesse item, como já afirmado an-
teriormente, considera-se a engenharia simultânea uma metodologia inte-
grada de trabalho que, por seus princípios, procura dar suporte ao desen-
volvimento de ferramentas para melhorar a prática de desenvolvimento
do produto, incluindo, como elementos operacionais, a metodologia de
projeto e a disciplina de gerenciamento de projeto.

2.3.3 Engenharia simultânea: implantação

A implantação da engenharia simultânea (ES) tem sido bastante dis-


cutida na literatura especializada, o que é justificável considerando que
as profundas mudanças organizacionais e culturais requeridas não são,
via de regra, facilmente aceitas. Assim como existe uma série de relatos
sobre o sucesso da implantação, há também uma série de exemplos mal-
sucedidos devido, principalmente, ao pouco cuidado com questões como
conscientização, apoio, treinamento e comprometimento. A espera de re-
sultados imediatos também tem sido uma grande causa para o descrédito
da metodologia.
Assim como ocorre com os modelos de engenharia simultânea, o modo
de implantação também tem variado entre as empresas. Algumas come-
çam por adotar avançados sistemas CAD integrados, outras iniciam pela
formação de equipes multidisciplinares de desenvolvimento. Entretanto,
poucas são as companhias que têm uma compreensão abrangente da ES
para uma eficiente implantação (Evans, 1993).
Esta seção tem por objetivo discutir os principais fatores do sucesso
para a implantação da ES, as barreiras e as falhas mais comuns, além das
ações e recomendações feitas pelos especialistas.
Segundo Evans (1993), os fatores de sucesso e as falhas na implanta-
ção da ES são muito similares na maioria dos casos relatados. Ele defende
que, mais importante que as ferramentas empregadas e o modelo de ES
adotado, é a forma como são implantados.
Um bom plano de implantação aumenta os benefícios de qualquer fer-
ramenta ou modelo adotado, sendo que a escolha das ferramentas, com
exceção das equipes multifuncionais de desenvolvimento, tem pouca re-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 54 — #82


i i

54 Projeto Integrado de Produtos: planejamento, concepção e modelagem

lação com os benefícios alcançados. Esta afirmação de Evans (1993) é mais


bem entendida quando ele considera que a melhor forma de avaliar o
desempenho da implantação da metodologia é pelo número de conside-
rações ou restrições de projeto que são observadas em cada tomada de
decisão. Dessa forma, fica evidente que só um ambiente de ES bem im-
plantado, com equipes multidisciplinares de desenvolvimento, é capaz de
fornecer as condições necessárias de integração e comunicação para que
as restrições das diversas áreas sejam consideradas o mais breve possível,
não importando tanto as ferramentas que são adotadas.
Como forma de aumentar os benefícios alcançados com a implanta-
ção da ES, Evans sugere que sejam observadas as principais razões para
o insucesso de sua implantação e que sejam desenvolvidas técnicas para
neutralizá-las, conforme as características de cada organização.
Os principais modos de falha observados por Evans são brevemente
comentados a seguir, tendo como base as três principais fases do processo
de implantação, conforme a Figura 2.12. Essa figura expressa os pontos
onde os principais modos de falha acontecem, desde a iniciação, passando
pelo planejamento, até a implementação propriamente dita.
A primeira fase – Iniciação – começa com o reconhecimento de querer
melhorar o processo de desenvolvimento do produto e termina quando
a empresa decide planejar e implementar a engenharia simultânea. A se-
gunda fase – Preparação e planejamento – consiste na sistematização e aná-
lise das informações para a prática da engenharia simultânea e termina
quando o plano de implementação da engenharia simultânea é apresen-
tado e aprovado. Por último, a terceira fase do processo – Implementação
– inicia-se com a execução do planejamento, promovendo inicialmente o
treinamento de pessoal e, em seguida, avaliando-se os benefícios.

2.3.4 Engenharia simultânea: modos de falha na fase inicial


da implementação

Conforme se observa na Figura 2.12, em cada uma das fases do pro-


cesso de implementação da engenharia simultânea, existem modos de fa-
lha potenciais, os quais devem ser estudados e analisados em maiores de-
talhes, a fim de serem evitados durante a implementação da engenharia
simultânea. Uma discussão sobre esses modos de falha é conduzida a se-
guir.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 55 — #83


i i

Desenvolvimeto integrado do projeto de produtos 55

Figura 2.12 Problemas mais freqüentes na implementação da engenharia


simultânea (adaptado de Evans, 1993)

Problemática do custo/benefício:
O cálculo da relação custo/benefício para a implantação de um am-
biente de ES não é simples, considerando que os resultados são alcança-
dos a longo prazo, e que é difícil estabelecer um sistema preciso para a
avaliação do progresso e do próprio resultado da adoção da metodologia.
O custo também não é fácil de ser estimado, devido ao caráter contínuo do
programa de implantação. Além disso, a tendência para a busca de retor-
nos imediatos e palpáveis é um grande erro que tem desmotivado, já no
início, o esforço para a implantação da ES. Para Evans, se a ES for vista ex-
clusivamente como uma atividade com retorno de baixo risco, pode até ser

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 56 — #84


i i

56 Projeto Integrado de Produtos: planejamento, concepção e modelagem

aceita inicialmente, mas as melhorias no processo serão improváveis. Mas,


por outro lado, se for vista como um projeto sem perspectiva de retorno,
provavelmente nunca será aprovada. Como solução, Evans propõe uma
combinação de investimento e retorno de baixo risco como argumentação,
já que ambos os objetivos devem ser alcançados.

Problemática do responsável:
Para não se tornar apenas mais um projeto de engenharia, a implanta-
ção da ES deve ser liderada por um membro da alta gerência. Gerentes mé-
dios não possuem poder para a completa implantação da ES. Além disso, o
representante da alta gerência deve estar suficientemente comprometido,
com disponibilidade de tempo para o aprendizado e para trabalhar junto
à equipe.

Problemática da falta de objetivos ou falta de visão:


Os objetivos devem ser claros e bem definidos. Índices de desempenho
também devem ser definidos, como, por exemplo, o tempo de desenvolvi-
mento. A definição dos objetivos almejados também é importante para a
escolha do modelo de ES a ser adotado. Uma boa estratégia é definir inici-
almente, no curto prazo, objetivos para o planejamento da implementação
da engenharia simultânea.

Problemática da falta de experiência:


A experiência com ES só é alcançada com a sua implantação. A busca
da experiência de especialistas externos pode ajudar, mas a falta de co-
nhecimento desses profissionais quanto às características da organização
é uma barreira. A solução, segundo Evans, é primeiramente reconhecer a
falta de experiência; em seguida, perceber o quanto os conhecimentos da
organização e as atividades podem ser valiosos para a execução do plane-
jamento; e, por fim, estabelecer mecanismos para o aprendizado, incluindo
formas de revisão, análise e avaliação das atividades. Recomenda, ainda,
o treinamento em ferramentas de revisão e análise.

2.3.5 Engenharia simultânea: falhas na preparação e


no planejamento de implantação

Evans relaciona os quatro modos de falha anteriormente descritos co-


mo relativos à fase de iniciação para a adoção da ES. Após a resolução

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 57 — #85


i i

Desenvolvimeto integrado do projeto de produtos 57

daqueles problemas e o envolvimento da alta gerência, deve-se ter início a


próxima fase do programa de implantação da ES, ou seja, a preparação e
o planejamento. Os modos de falhas que seguem são relativos a essa fase.

Problemática da alta gerência:


Os benefícios da ES só serão integralmente alcançados com o empenho
prioritário da alta gerência. Delegar a tarefa de planejamento da ES acaba
por causar pouco entendimento e falta de comprometimento por parte da
equipe. Evans menciona que um programa para conscientização da alta
gerência é vital. Os riscos de um programa para criar um ambiente de ES
devem estar claros para a alta gerência, e esta deve reconhecê-los e fazer
um planejamento de modo a evitá-los. A alta gerência deve saber o que é
ES, como ela beneficiará a empresa e quais são os objetivos pretendidos.
Esclarecidos estes itens, ela deve então patrocinar a criação de uma equipe
para o planejamento da implantação da ES.

Problemática da cooperação funcional:


A equipe de planejamento deve ter representantes de todas as áreas da
empresa. A reunião inicial deve ser liderada por alguém da alta gerência,
que deixará claro para o grupo os seguintes aspectos:

• Por que a ES é necessária para a empresa?


• O que a ES significa para a alta gerência?
• Quais são os limites para a equipe de planejamento?
• Como serão relatados os resultados e atividades?
• O que poderá ou não ser dito para os demais funcionários?
• Como o sucesso do grupo será avaliado?

Nesse ponto, Evans expressa que o elemento mais crítico é a escolha


dos objetivos que servirão como critério de avaliação. Para que o espírito
de cooperação seja mantido, é necessário que objetivos comuns sejam esta-
belecidos como referência. Somente haverá cooperação efetiva se todos os
integrantes da equipe forem avaliados pelo alcance dos mesmos objetivos.

Problemática do grupo ou equipe:


Muitas empresas formam grupos multidisciplinares em que o ponto
básico em comum é apenas o fato de os integrantes estarem trabalhando
no mesmo projeto, o que não constitui equipes multidisciplinares real-
mente. Uma verdadeira equipe tem como fundamento não só a respon-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 58 — #86


i i

58 Projeto Integrado de Produtos: planejamento, concepção e modelagem

sabilidade por um mesmo projeto, mas também o compartilhamento dos


mesmos objetivos e o reconhecimento de que somente com o esforço de
todos os membros eles serão alcançados. O resultado obtido é responsabi-
lidade de todos, não de um único representante de uma determinada área.
Em resumo, utilizando as palavras de Evans, um grupo divide apenas um
mesmo nome, enquanto uma equipe divide os mesmos propósitos. Além
disso, ao contrário de um grupo, os membros de uma equipe não se reú-
nem ocasionalmente, mas sim em tempo integral. Outro ponto importante
ressaltado por Evans é que o plano de ação da equipe não deve ser imposto
por elementos externos, mas deve ser o primeiro trabalho a ser feito pela
própria equipe, o que constitui um fator motivador bastante forte. Entre
todos os modos comuns de falha, este é o mais importante, tanto em ter-
mos de ocorrência quanto de impacto na implantação da ES.

Problemática da paralisia cultural:


Evans sugere duas fontes para a paralisia do programa de ES. A pri-
meira é a dificuldade de assimilação de novas idéias, termos e métodos.
Por inércia, as pessoas tendem a rejeitar novas idéias por pensar não ser
possível ou muito difícil aprender o que não é trivial. A segunda noção
responsável pelo atraso na implantação da ES é a falsa idéia de que um
líder responsável por essa tarefa precisa ser alguém fora do comum, com
profundas habilidades técnicas, gerenciais e de relacionamento humano.
Partindo do princípio de que uma verdadeira equipe tem como caracte-
rística objetivos comuns, mesma referência de desempenho para todos os
membros e inexistência de gerenciamento externo, ou seja, a necessidade
de um líder controlador, fica claro que é mais importante mudar a cultura
de cada indivíduo e não buscar por um líder que reúna todas as qualida-
des. A soma da mudança cultural de cada indivíduo é que resultará na
mudança cultural da empresa. A idéia de que é necessário um superlíder
para compensar, por meio de um controle gerencial externo, os defeitos da
organização, deve ser desfeita dentro de um ambiente de ES. É preciso res-
saltar, entretanto, que a escolha de um bom líder é importante e, colocado
desse modo, a tarefa de encontrá-lo torna-se bem mais fácil.

Problemática da variedade de ferramentas:


Existe uma grande variedade de ferramentas proposta para o projeto
de produtos e sistemas. É impraticável procurar entender e avaliar todas,
considerando o tempo que isso levaria e os custos envolvidos. Para con-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 59 — #87


i i

Desenvolvimeto integrado do projeto de produtos 59

tornar esse modo de falha muito corrente, Evans enumerou três fatores
para evitar essa tendência:
• a demora na implantação é onerosa;
• as melhores pessoas para selecionar as ferramentas são os usuários;
• as ferramentas mais apropriadas são óbvias.
Segundo Evans, não é preciso muita pesquisa para aprender as poten-
cialidades das principais ferramentas. As ferramentas menos conhecidas
são normalmente indicadas para casos específicos. A tarefa de escolha das
melhores ferramentas específicas deve ser delegada para as equipes mul-
tidisciplinares de desenvolvimento.

Problemática da tecnologia:
Apesar de as ferramentas de alta tecnologia, como avançados sistemas
CAD, trazerem inquestionáveis benefícios, o conhecimento de trabalho em
equipes e as ferramentas mais simples e baratas, possibilitam um índice
de retorno de investimento bem mais elevado. Para Evans, a adoção de
ferramentas de alta tecnologia não deve ser vista como um ponto crítico
para o sucesso da implantação da ES, mas como um complemento para
outros elementos.

Problemática da fase final ou início tardio:


A execução do projeto dentro de uma metodologia de ES não deve co-
meçar somente quando ocorre a aprovação para o início do projeto por ter-
se percebido uma oportunidade de mercado, por exemplo. Dessa forma,
toda uma fase, desde a idéia inicial até a consulta do mercado (clientes), é
feita sem o auxílio da ES. Muitas restrições de projeto deixam de ser regis-
tradas, além de dificultar o entendimento da tarefa por parte da equipe.

Problemática do medo do insucesso:


Devido às muitas mudanças causadas pela adoção da ES, a implanta-
ção da mesma é vista com bastante cautela, suscitando estudos profundos
e minuciosos, deixando os responsáveis receosos quanto à implantação
por medo de errar. Esse temor pode ser superado com a conscientização de
que erros podem ocorrer muito provavelmente. Essa consciência deve es-
tar clara para a alta gerência e os demais. A idéia deve ser complementada
com a aceitação de que os erros são fontes de aprendizado e que devem ser
abertamente discutidos. O aprendizado deve então ser incorporado pelo
processo. Só a repetição de um erro deve ser vista como falha do processo.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 60 — #88


i i

60 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Problemática das especificações de projeto:


É importante que as especificações de projeto sejam estabelecidas pela
equipe de desenvolvimento e não antes do início do projeto e impostas
à equipe. Especificações de projeto estabelecidas fora de um ambiente de
ES e sem o envolvimento da equipe multidisciplinar tendem a ser falhas
e incompletas. Por este motivo, especificações de projeto não devem ser
fixadas na etapa de planejamento do ambiente de projeto.
Problemática do lançamento:
O lançamento do projeto de implantação da ES deve ser um evento.
Um lançamento bem planejado e executado é fundamental para o enten-
dimento de todos. Deve ocorrer juntamente com o lançamento do projeto
do produto que servirá de objeto para a implantação da metodologia. É
importante a participação do presidente da empresa e de toda a diretoria
apoiando os princípios definidos para a ES. O presidente deve evidenciar
a importância do projeto e do modo pelo qual será executado. Nesse mo-
mento é importante deixar claras as atribuições da equipe, o que ela pode
ou não fazer. A idéia de que a equipe é um fator crucial, que terá suficiente
autonomia e responsabilidades e que a gerência dará apoio aos métodos
estabelecidos pela equipe deve ser expressa com transparência.
Numa segunda etapa do lançamento, devem ser definidas as respon-
sabilidades dos membros e do líder da equipe. Vale ressaltar novamente
a necessidade de que os membros tenham as mesmas responsabilidades.
Devem-se evitar divisões do tipo “a manufatura é responsabilidade do en-
genheiro de processos”, a fim de garantir que toda a equipe compartilhe
as mesmas responsabilidades. O papel do líder de uma equipe multidisci-
plinar não é tomar decisões, e sim atuar como um facilitador responsável
pela comunicação e pelas informações, como a política da empresa e as
linhas gerais do projeto, além de manter o plano de execução atualizado.
Nas palavras de Evans, o objetivo do líder é criar o mais eficiente ambiente
de ES e, assim, atuar mais como um condutor do que como um executor.
Por fim, objetivos devem ser dados à equipe, por meio de metas quan-
tificáveis para desempenho, custos, redução de tempo de desenvolvimen-
to, entre outras. É necessário que essas metas sejam preparadas com ante-
cedência e submetidas à equipe para apreciação. As metas devem sempre
estar associadas ao produto e nunca à função de reduzir custo de manufa-
tura, por exemplo, para impedir desagregação da equipe quanto aos obje-
tivos comuns.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 61 — #89


i i

Desenvolvimeto integrado do projeto de produtos 61

2.3.6 Engenharia simultânea: falhas na fase de execução


do plano de implantação

Os próximos modos de falha são relativos à fase de execução do plano,


conforme a definição de Evans e a Figura 2.12.

Problemática do grau de envolvimento da média gerência:


Gerentes responsáveis por funções bem definidas, como produção,
pesquisa e desenvolvimento, análise estrutural, são normalmente requi-
sitados por colaboradores de sua área para resolver problemas. Quando
participam das equipes multidisciplinares, muitas vezes deixam a equipe
para resolver problemas em suas respectivas áreas, o que é definido como
seqüestro. Essa situação atrasa o andamento dos trabalhos e contribui para
reforçar a rígida estrutura funcional. Só o treinamento e o comprometi-
mento quanto à metodologia da ES e ao papel do gerente podem evitar
esse modo comum de falha.

Problemática do grupo ou equipe:


Alguns membros da equipe podem ter a tendência a retornar ao modo
de trabalho tradicional, ou seja, individual, especializado e seqüencial. As
causas para esse modo de falha são a falta de clareza quanto às atribuições
e às suas responsabilidades. A solução, segundo Evans, é a capacitação
continuada sobre o contexto da metodologia e a consciência de que os cri-
térios de avaliação de desempenho são os mesmos para a equipe como um
todo.

Problemática da expansão do programa:


Em vez de procurar planejar um programa abrangente e minuciosa-
mente planejado, as empresas devem buscar o incremento do ambiente de
ES através das lições aprendidas, registradas e incorporadas ao plano. A
equipe deve discutir a implantação do programa buscando identificar o
que está funcionando, o que não é eficiente e o que pode ser melhorado
ou introduzido. Basicamente, é importante que os objetivos e a política da
empresa sejam esclarecidos e bem entendidos por todos. Uma boa forma
de convencimento sobre os benefícios da ES é esclarecer quanto ela pode
contribuir para que os objetivos da empresa sejam atingidos. A falta de
políticas e objetivos claros é uma grande barreira para a implantação da
ES. Como no desenvolvimento de produtos, os modos de falha devem ser

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 62 — #90


i i

62 Projeto Integrado de Produtos: planejamento, concepção e modelagem

considerados no início, quando a ES está sendo avaliada e planejada (nas


fases informacional e conceitual da engenharia simultânea, para estabele-
cer um paralelo com o projeto de produtos), quando as alterações são mais
fáceis e não implicam em custos elevados, além de aumentar as chances
de sucesso do programa.

2.3.7 Engenharia simultânea: barreiras da implantação

Maddux e Souder (1993) consideram que as barreiras para a implanta-


ção da ES podem ser divididas em dois grupos: organizacional e técnica.
As barreiras organizacionais são aquelas relacionadas a gerenciamento,
política e cultura da empresa, comportamento humano e resistência a mu-
danças. As barreiras técnicas são aquelas relativas à falta de infra-estrutura
básica, como sistemas de comunicação e sistemas CAD/CAM, ou à falta
de conhecimento e experiência para a implantação da ES.
Como barreiras organizacionais, Maddux e Souder (1993) identifica-
ram sete, algumas também apontadas por Evans (1993) e relacionadas a
seguir:

• falta de apoio da alta gerência: qualquer tentativa de implantação da ES


sem o apoio e o forte envolvimento da alta gerência está fadada ao
fracasso. A conscientização deve ser feita a cada nível organizacio-
nal, partindo do mais alto e, sucessivamente, sendo transmitido para
os níveis inferiores;
• ambiente organizacional inadequado: devido à política da empresa, ati-
tudes e diretrizes da alta gerência têm o poder de influenciar quanto
à intensidade da cooperação multidisciplinar;
• protecionismo: gerentes que tendem a proteger sua área são barreiras
para a implantação da ES, dificultando a troca de informações e a
colaboração multidisciplinar;
• sistema de recompensa inadequado: a premiação por objetivos alcança-
dos deve ser feita com base em metas gerais, evitando a análise de
desempenho por departamento, o que diminui a aptidão para a co-
laboração entre as diversas áreas;
• falta de envolvimento com o cliente;
• falta de envolvimento com os fornecedores: as empresas que têm tido su-
cesso na aplicação dessa metodologia tendem a diminuir o número

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 63 — #91


i i

Desenvolvimeto integrado do projeto de produtos 63

de fornecedores e promover freqüente troca de informação e coope-


ração;
• temor de inibir a criatividade: muitos acreditam que as regras estabele-
cidas para a implantação da ES e a normalização do processo de pro-
jeto coíbem a criatividade. Sobre esse fato, Maddux e Souder (1993)
afirmam que os benefícios obtidos com a ES em muito suplantam
qualquer inibição quanto à criatividade que porventura possa ocor-
rer devido ao uso de técnicas bem definidas e à aceitação de suges-
tões de outros membros da equipe. Vista de outra forma, a ES pode
até aumentar a criatividade por suscitar discussões entre os mem-
bros da equipe com uma vasta gama de conhecimentos somados.
Quanto às barreiras técnicas, Maddux e Souder (1993) consideram que
um sistema CAD/CAM é imprescindível para o máximo aproveitamento
da ES. As facilidades de comunicação, através da simultaneidade de en-
vio de dados, troca de informações e correções, melhoram em muito o
ambiente integrado de desenvolvimento. Entretanto, um verdadeiro am-
biente dessa natureza não pode ser comprado com a aquisição de software.
Só a conscientização e a mudança da cultura profissional das pessoas vi-
sando ao aumento na cooperação entre as diversas áreas garantem o su-
cesso da engenharia simultânea. A necessidade de software e outras ferra-
mentas deve ser cuidadosamente avaliada de acordo com as necessidades
da equipe e as características do processo de projeto.
Outra dificuldade encontrada foi a falta de integração entre os vários
tipos de software e ferramentas adotados. A infra-estrutura informatizada
deve complementar as técnicas e os métodos de projeto.
Para que as barreiras organizacionais e técnicas sejam eliminadas,
Maddux e Souder (1993) sugerem cinco ações que devem ser observadas
pelo condutor do processo de implantação da ES:
• conscientização da necessidade de assimilar conhecimento advindo
de diferentes culturas;
• transformações organizacionais, eliminando as barreiras entre os de-
partamentos por intermédio de equipes multidisciplinares fortes. O
desenvolvimento do produto e do processo deve estar integrado,
sendo responsabilidade de um único vice-presidente;
• formação de uma equipe multidisciplinar fortemente integrada e
com membros que sejam realmente representantes de suas respec-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 64 — #92


i i

64 Projeto Integrado de Produtos: planejamento, concepção e modelagem

tivas áreas, inclusive com poder de decisão. É importante também a


participação de clientes e fornecedores na equipe;
• provisão de suporte tecnológico através da infra-estrutura informa-
tizada e da adoção de metodologias e ferramentas de projeto;
• definição de responsabilidades e promoção da integração.

Grande parte do sucesso da implantação da ES está em reconhecer


essas barreiras e observar as recomendações que, segundo os autores, ser-
vem para a maioria dos casos. A forma como as recomendações devem ser
executadas, entretanto, é bastante particular para cada empresa, conside-
rando suas características, tipo de produto que desenvolvem e o mercado
em que atuam.

2.3.8 Engenharia simultânea: etapas para a implantação

A etapa de implantação da ES é decisiva para que a metodologia pro-


posta não caia em descrédito. Algumas falhas e a falta de comprometi-
mento são suficientes para que a tentativa de implantação de um ambiente
de ES seja definitivamente abandonada. Durante essa etapa, é ainda maior
a importância da liderança da alta gerência, já que a incerteza existente,
devido à falta de resultados concretos obtidos, torna o processo frágil sob
o aspecto do comprometimento da organização.
A fim de evitar falhas como iniciativas isoladas, falta de iniciativa e
falta de foco, Clausing (1994) sugere que a ES seja implantada em quatro
etapas: conscientização, treinamento, projeto piloto e integração e instituciona-
lização. Para o autor é importante, ainda, a forma como ocorre o envolvi-
mento das pessoas em cada uma dessas etapas. A Figura 2.13 representa
essas etapas por meio do estabelecimento de dois aspectos: o estilo de im-
plantação, top down ou bottom up, e o foco, dirigido ao conteúdo da ES ou
à organização da ES. Assim são determinados quadrantes de atuação.
Para Clausing (1994), a forma de implantação que evita os problemas
anteriormente citados começa com a composição de uma equipe multi-
disciplinar que estaria caracterizada pelo quadrante número 1 na Figura
2.13, ou seja, seria conduzida pela gerência média, ainda que tenha o forte
apoio da alta gerência, e teria foco no conteúdo necessário para adoção
da ES. Inicialmente, a equipe é conscientizada quanto à importância da
nova abordagem e é iniciado um trabalho de treinamento. A equipe teria

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 65 — #93


i i

Desenvolvimeto integrado do projeto de produtos 65

Figura 2.13 Passos para implantação da ES (Clausing, 1994)

como atribuição aprender novas técnicas e ferramentas, aplicar e adaptar


os conceitos de gerenciamento da qualidade total à organização pelo de-
senvolvimento de um projeto piloto. Dessa forma, as três primeiras etapas
– conscientização, treinamento e projeto piloto – estariam cumpridas.
O próximo passo, após a sedimentação dos conceitos e a obtenção da
confiança quanto aos resultados obtidos, é migrar para o quadrante nú-
mero 2, por meio da transferência de experiência à alta gerência. A equipe
auxilia a alta gerência a entender e desenvolver um plano de implementa-
ção dos novos conceitos no âmbito da organização como um todo.
A alta gerência move-se então em direção ao quadrante número 3 com
um claro entendimento quanto aos conceitos e às recomendações geradas
pela aplicação durante a execução do projeto piloto. O plano de implanta-
ção é posto em prática através de uma forte liderança. A constituição de
um plano de implantação bem preparado durante a atuação no quadrante
3 é de fundamental importância. Para Clausing (1994), este deve cumprir
as seguintes funções:

• disseminar a conscientização e o treinamento em toda a organização;


• descrever detalhadamente os princípios de gerenciamento da qua-
lidade total de forma adaptada às necessidades e características da
organização;
• promover o desenvolvimento dentro dos princípios da qualidade to-
tal;
• criar condições para que a transição entre a antiga e a nova aborda-
gem seja bem-sucedida;
• prever treinamento operacional e acordos com consultores externos.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 66 — #94


i i

66 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Os princípios da ES, devidamente incorporados ao plano de implanta-


ção, são então aplicados a todos os programas de desenvolvimento.
Por fim, busca-se o envolvimento de todos os funcionários através da
adoção e adaptação do plano a cada um dos programas em execução. A
ES é, dessa forma, institucionalizada na condição caracterizada pelo qua-
drante número 4.

2.3.9 Engenharia simultânea: formação de equipes


multidisciplinares

A formação da equipe multidisciplinar é considerada como o ponto


crucial para o sucesso da ES. Clausing (1994) relaciona dez princípios bá-
sicos para o sucesso na formação de equipes multidisciplinares:
• as equipes devem ser formadas com base em objetivos comuns e
respeito a todas as áreas representadas;
• a participação de representantes de todas as grandes áreas da orga-
nização deve ser garantida;
• um entendimento comum sobre a ES deve ser certificado;
• a forma como o consenso para a convergência de soluções é obtido
deve ser bem entendida por todos;
• o consenso prematuro e fácil nas tomadas de decisão deve ser evi-
tado;
• definir de forma criteriosa os trabalhos que devem ser feitos indivi-
dualmente e aqueles que devem ser feitos pela equipe;
• adotar métodos sistemáticos;
• estimular a comunicação formal e informal;
• é importante selecionar pelo menos alguns dos membros da equipe
segundo aptidões e especialidades;
• deve-se desenvolver uma liderança.
Segundo Clausing (1994), a observação desses dez princípios em con-
junto com o cuidado em relação às barreiras discutidas anteriormente
torna a implantação da ES bastante robusta e aplicável a diferentes abor-
dagens.
É importante, ainda, promover o envolvimento e o treinamento de to-
dos os integrantes através de uma gestão participativa e procurar envolver
de alguma forma clientes e fornecedores.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 67 — #95


i i

Desenvolvimeto integrado do projeto de produtos 67

Outro ponto é o estabelecimento do número de integrantes para a


equipe. Os autores são unânimes ao recomendar que as equipes de projeto
multidisciplinares não devem ser demasiadamente grandes, para evitar
problemas como dificuldade de comunicação, dispersão e baixa produti-
vidade.
Miller (1993) observou que equipes com elevado número de integran-
tes tendem a tornar o ambiente menos favorável à criatividade. Ele sugere
que, para o caso de um projeto de conceito inovador, o projeto conceitual
deve ser iniciado por uma equipe de dois ou três projetistas. Na medida
em que o projeto avança, outros indivíduos são agregados à equipe, até
alcançar as etapas de projeto detalhado e fabricação, quando há um de-
créscimo no número de integrantes. Já em se tratando de um produto de-
rivado de outro já existente, Miller (1993) propõe que pequenos grupos
de especialistas executem o projeto preliminar e detalhado. Nesse caso,
as maiores inovações ocorrem nessas fases, já que o conceito é o mesmo
daquele produto previamente existente.
Para Clausing (1994), como já mencionado anteriormente, não deve
haver alterações bruscas com relação aos participantes da equipe, a fim de
que haja continuidade. A equipe multidisciplinar deve se manter razoa-
velmente constante. Todos aqueles que estiverem diretamente envolvidos
no projeto devem fazer parte da equipe.
Miller (1993) recomenda ainda que na composição da equipe seja ob-
servada a diversidade quanto às características pessoais, quanto à espe-
cialidade técnica e às áreas representadas. Clausing (1994) sustenta que
o representante de cada área na equipe multidisciplinar deve preencher
dois pré-requisitos: ter um bom conhecimento da área representada e o
comprometimento, por parte dos integrantes da respectiva área, quanto
ao acato das decisões por ele tomadas ao longo do processo. Dessa forma,
evitam-se problemas causados por falta de conhecimento e informação ou
por mudanças ocasionadas por decisões reconsideradas, o que aumenta o
tempo de desenvolvimento.

2.3.10 Engenharia simultânea: benefícios de sua aplicação

Diante dos princípios, modelos e aspectos da implantação da enge-


nharia simultânea, destacam-se, conforme Clausing (1994), os principais
benefícios dessa metodologia:

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 68 — #96


i i

68 Projeto Integrado de Produtos: planejamento, concepção e modelagem

• o desenvolvimento dos sistemas de produção e das áreas de apoio


começa cedo;
• a análise dos aspectos relacionados ao produto ocorre simultanea-
mente entre projeto, produção e logística, como um sistema único;
• a facilidade de obter um bom projeto para manufaturabilidade e
apoio logístico;
• a produção e as pessoas das áreas de apoio ganham um claro enten-
dimento do projeto e comprometem-se para seu sucesso;
• as modificações no protótipo são reduzidas porque o projeto se torna
mais maduro desde as fases iniciais.

Esses benefícios implicam diretamente numa melhoria no processo de


desenvolvimento do produto, a saber:
• foco na qualidade, custo e cronograma de desenvolvimento;
• ênfase na satisfação do consumidor;
• ênfase nas melhores práticas de desenvolvimento;
• equipe multidisciplinar de desenvolvimento;
• funcionários envolvidos e participantes no gerenciamento;
• relacionamento estratégico com os fornecedores.

2.4 Modelo de desenvolvimento integrado


de produtos

Neste item será descrito o Processo de Desenvolvimento Integrado de


Produtos – PRODIP –, proposto com base em pesquisas e experiências de-
senvolvidas pelo NeDIP. Esse modelo, também chamado de modelo de
referência, procura explicitar o conhecimento sobre o processo de desen-
volvimento de produtos, de modo a auxiliar no entendimento e na prática
do processo. Assim, é recomendado tanto na formação de estudantes e na
atualização de profissionais que trabalham na área, como para a imple-
mentação de melhorias no processo de desenvolvimento de produtos nas
empresas.
O modelo de referência contribui para que as empresas passem a exe-
cutar um processo de desenvolvimento de produtos mais formal e siste-
mático, integrado aos demais processos empresariais, com os participan-
tes da cadeia de fornecimento e com os clientes finais. Fornece, ainda, os

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 69 — #97


i i

Desenvolvimeto integrado do projeto de produtos 69

meios para que as empresas inovem e desenvolvam, dentro de suas fábri-


cas, novos produtos.
O modelo desenvolvido e descrito em mais detalhes por Romano
(2003) está representado graficamente na Figura 2.14 e apresenta, em li-
nhas gerais, as seguintes características:

• é baseado na visão de processo e em consonância com o plano estra-


tégico de negócios e de produtos da organização;
• traz a visão de todo o processo de desenvolvimento do produto, atra-
vés da unidade visual de representação gráfica e da descrição;
• o processo é decomposto em macrofases, fases, atividades e tarefas;
• indica a seqüência lógica das fases e atividades;
• explica o que deve ser feito para desenvolver um produto industrial,
ou seja, as atividades e tarefas apoiadas nos princípios da engenharia
simultânea e nas diretrizes do processo de gerenciamento de proje-
tos;
• define as áreas envolvidas em cada atividade do modelo;
• suporta estrutura organizacional matricial;
• define as informações necessárias para a realização das atividades,
apresentadas sob a forma de entradas, mecanismos e controles;
• expõe como realizar as atividades através da definição dos principais
métodos, ferramentas e documentos (mecanismos);
• exibe os eventos que marcam o término das fases e definem os resul-
tados desejados (saídas);
• avalia passagem de fase;
• registra lições aprendidas.

O modelo esquematizado na Figura 2.14 é decomposto em três macro-


fases:

• Planejamento do projeto: a primeira macrofase corresponde à fase de


planejamento do projeto. Envolve a elaboração do plano do projeto
do produto, principal resultado da fase.
• Elaboração do projeto do produto: envolve a elaboração do projeto do
produto e do plano de manufatura. Decompõe-se em quatro fases

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 70 — #98


i i

70 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 2.14 Representação gráfica do modelo do processo de desenvolvimento integrado de produtos – PRODIP
(Romano, 2003)

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 71 — #99


i i

Desenvolvimeto integrado do projeto de produtos 71

denominadas de projeto informacional, projeto conceitual, projeto


preliminar e projeto detalhado. Os resultados principais de cada fase
são, respectivamente, as especificações de projeto, a concepção do
produto, a viabilidade técnica e econômica e a documentação do pro-
duto.
• Implementação do lote piloto: envolve a execução do plano de manu-
fatura na produção da empresa e o encerramento do projeto. De-
compõe-se em três fases denominadas de preparação da produção,
lançamento e validação do produto. Os resultados principais de cada
fase incluem, respectivamente, a liberação do produto, a liberação do
lote piloto e a validação do produto.
Assim tem-se, no total do processo de desenvolvimento do produto,
três macrofases, decompostas em oito fases. Ao final de cada fase há uma
avaliação do resultado obtido, autorizando a passagem para a fase se-
guinte. Como descrito adiante, estas são decompostas em atividades que
são, por sua vez, desdobradas em tarefas.
Outro aspecto importante a ser observado (no modelo da Figura 2.14)
é a indicação dos principais domínios de conhecimento envolvidos na re-
alização das tarefas, cujo propósito é auxiliar na identificação das pessoas
e das habilidades necessárias para a realização dessas tarefas. O modelo
de referência apresenta-se estruturado a partir dos seguintes domínios de
conhecimento:
• Gestão Empresarial – GE: envolve a tomada de decisão da diretoria
da empresa.
• Gerenciamento de Projeto – GP: engloba a iniciação, o planeja-
mento, a execução, o controle e o encerramento do projeto.
• Marketing – MK: trata-se da pesquisa de mercado, planejamento de
marketing, propaganda e venda do produto.
• Projeto do Produto – PP: compreende o desenvolvimento e a vali-
dação do projeto do produto.
• Projeto da Manufatura – PM: trata do desenvolvimento e da imple-
mentação do plano de manufatura.
• Suprimento – SU: refere-se ao planejamento e controle de suprimen-
tos, bem como o envolvimento de fornecedores no desenvolvimento
do projeto do produto e do plano de manufatura.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 72 — #100


i i

72 Projeto Integrado de Produtos: planejamento, concepção e modelagem

• Qualidade – QU: considera desde o atendimento do produto até as


metas de qualidade.
• Segurança – SE: abrange a avaliação da segurança do produto.
• Dependabilidade – DP: corresponde ao atendimento do produto às
metas de confiabilidade e mantenabilidade. Inclui a realização de
testes e a preparação da logística de assistência técnica.
• Administrativo-financeiro – AF: compreende questões administra-
tivas, jurídicas e financeiras da empresa.
• Produção – PR: refere-se à implementação do plano de manufatura
e da produção dos produtos.
• Pós-venda – PV: compreende as ações corretivas e de apoio nos casos
de falha ou defeito do produto.

Sendo objeto principal desta obra o desenvolvimento do projeto do


produto, a seguir serão descritas em maiores detalhes, desdobradas ao
nível de atividades e tarefas, quatro fases: projeto informacional; projeto
conceitual; projeto preliminar; e projeto detalhado. Entende-se atividade,
aqui, como um conjunto de tarefas. A tarefa é caracterizada por escopo,
tempo de execução, recursos necessários e risco. Constitui-se no último
nível de desdobramento de uma atividade. Esses conceitos serão aprofun-
dados no Capítulo 3.
Nessas fases cada uma das atividades e tarefas será descrita na forma
da Tabela 2.2, com os seguintes elementos:

• Entradas: informações ou objetos físicos a serem processados ou


transformados pela tarefa.
• Mecanismos: recursos físicos e/ou informações necessárias para a
execução da tarefa (por exemplo: metodologias, técnicas, ferramen-
tas).
• Controles: informações usadas para monitorar ou controlar a tarefa.
• Saídas: informações ou objetos físicos processados ou transformados
pela tarefa (entregas produzidas).

As saídas são usadas como entradas de outras atividades ou tarefas.


Quando, na forma de informação – as especificações de projeto de uma
máquina, por exemplo –, são usadas como entradas de tarefa, ou na forma

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 73 — #101


i i

Desenvolvimeto integrado do projeto de produtos 73

de controle ou de mecanismo de outras tarefas. Quando a saída é um objeto


físico – um protótipo da máquina, por exemplo –, é usada somente como
entrada de tarefa ou mecanismo de outras tarefas.

Tabela 2.2 Modelo de tabela de desdobramento das fases de projeto do


produto (Romano, 2003)

Fase do processo de desenvolvimento do produto

Número da Domínios de
Entradas Atividades Tarefas Mecanismos Controles Saídas
atividade conhecimento

Xn1 .... .... ....

Xn2 .... .... ....


Entradas para Atividade Saídas da
n Xn3 .... .... ....
atividade Xn Xn atividade Xn
Xn4 .... .... ....

.... .... .... ....

.... .... .... ....


n+1 .... ....
.... .... .... ....

Indica- Descrição dos Declaração Declaração Relação dos Descrição dos Formas de Descrição
ção do dados ou da atividade da tarefa domínios de mecanismos, monitora- dos resultados
número de informações a ser resultante do conhecimento métodos ou mento e obtidos pela
ordem da necessárias executada desdobra- necessários ferramentas controle de execução da
atividade para executar mento da para executar utilizados na execução atividade
da fase a atividade atividade a tarefa elaboração da tarefa
da tarefa

Conforme se verifica na Tabela 2.2, as atividades estão dispostas numa


seqüência lógica de acontecimentos, de modo a facilitar o armazenamento
das informações, não significando, portanto, que as mesmas não possam
ser desenvolvidas simultaneamente.
O conteúdo detalhado do modelo de referência PRODIP é descrito em
tabelas cuja estrutura apresenta a mesma unidade visual da representação
gráfica adotada para o modelo, apresentada na Figura 2.14. As fases do
projeto informacional, conceitual, preliminar e detalhado serão descritas
em tabelas individuais, compostas pelos elementos mostrados na Figura
2.15: entradas, atividades, tarefas, domínios, mecanismos, controles e saí-
das.
O detalhamento dessas tabelas encontra-se disponível no Apêndice
(Tabelas A1 a A4). As demais fases do processo de desenvolvimento do
produto, o planejamento do projeto, a preparação da produção, o lança-
mento e validação do produto, serão desdobradas somente por fluxogra-
mas de atividades.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 74 — #102


i i

74 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 2.15 Elementos na descrição de atividades ou tarefas

2.4.1 Fase 1 – Planejamento do projeto

Essa fase destina-se ao planejamento de um novo projeto em face das


estratégias de negócio da empresa e da organização do trabalho a ser de-
senvolvido ao longo do processo. Como mostra a Figura 2.16, a partir do
plano estratégico de produtos, o planejamento de marketing é iniciado e
aprovado, liberando a criação do termo de abertura do projeto ou a carta
de projeto, que formaliza a existência do projeto dentro da organização.
Segue com a identificação das partes envolvidas no projeto (os clientes di-
retos e indiretos, parceiros, participantes da organização do projeto etc.) e
com a elaboração do plano de gerenciamento das comunicações (diretri-
zes para o sistema de informações do projeto). É elaborada a declaração do
escopo do projeto do produto, que descreve a justificativa do projeto, suas
restrições, o que será desenvolvido (características do produto), as saídas
desejadas de cada fase do projeto, bem como os objetivos do projeto. Após
aprovação, a declaração do escopo do projeto é detalhada através da ela-
boração da estrutura de decomposição do projeto, ou estrutura de desdo-
bramento do trabalho (EDT), que define o que é objeto do projeto. Com a
declaração do escopo do projeto e a estrutura de decomposição do projeto
parte-se para a avaliação do risco do projeto para as áreas envolvidas da
organização, resultando numa classificação do risco do projeto. A partir
desta classificação são definidas a equipe de gerenciamento do projeto e
todas as demais atividades necessárias à elaboração do plano do projeto
do produto, que orientará a execução das macrofases de projeto do pro-
duto e de implementação.
Paralelamente ao plano do projeto, são desenvolvidos os planos de
gerenciamento de suprimentos e da qualidade, bem como estabelecidas
metas de segurança a serem atendidas com o novo projeto. As melhores

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 75 — #103


i i

Desenvolvimeto integrado do projeto de produtos 75

Figura 2.16 Fluxograma da fase de planejamento do projeto

práticas relacionadas à realização das tarefas da fase são registradas para


incorporação a novos projetos como lições aprendidas. Ao encerrar as ati-
vidades da fase, submete-se o plano do projeto à aprovação, que é o cri-
tério que autoriza o progresso para a fase seguinte. O comprometimento
das áreas envolvidas no desenvolvimento é obtido através da avaliação e
da aprovação do plano de projeto.
Os Capítulos 3 e 4 descrevem com mais profundidade o conhecimento
necessário para o planejamento do produto, a elaboração do plano e o
gerenciamento do desenvolvimento do produto.

2.4.2 Fase 2 – Projeto informacional

A fase de projeto informacional, conforme apresentado pela Figura


2.17 e detalhado na Tabela A1 do Apêndice, destina-se à definição das

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 76 — #104


i i

76 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 2.17 Fluxograma da fase de projeto informacional

especificações de projeto do produto. Sendo a primeira fase do projeto do


produto, nela acontece a primeira reunião da equipe de desenvolvimento,
para apresentação do plano do projeto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 77 — #105


i i

Desenvolvimeto integrado do projeto de produtos 77

Uma vez iniciada a execução do plano do projeto, são realizadas di-


versas tarefas que buscam a definição dos fatores de influência no projeto
do produto. Paralelamente, o planejamento de marketing é continuado,
sendo o mercado monitorado para identificar variações que possam influ-
enciar na determinação das especificações de projeto. Para estabelecer as
especificações de projeto, são identificadas, primeiramente, as necessida-
des dos clientes ou usuários, sendo estas desdobradas em requisitos dos
usuários. A partir dos requisitos dos usuários são definidos os requisitos
de projeto do produto, considerando diferentes atributos: funcionais, er-
gonômicos, de segurança, de confiabilidade, de modularidade, estéticos
e legais, entre outros. Conhecidos os requisitos de projeto, uma avalia-
ção comparativa dos produtos disponíveis no mercado permite verificar o
atendimento dos mesmos aos requisitos dos usuários e aos do projeto.
Dos requisitos de projeto derivam as especificações de projeto, ou seja,
os objetivos a que o produto, a ser projetado, deve atender. De posse das
especificações de projeto, são definidos: os fatores de influência no plano
de manufatura; a estratégia para o envolvimento de fornecedores de com-
ponentes; as informações sobre segurança no ciclo de vida; as metas de
dependabilidade; e o custo meta do produto. Antes da aprovação das es-
pecificações de projeto, as mesmas são avaliadas quanto ao atendimento
do escopo do projeto.
Da mesma forma que na fase anterior, as melhores práticas relaciona-
das à realização das tarefas da fase são registradas para incorporação a no-
vos projetos como lições aprendidas. Esta mesma atividade é válida para
as demais fases do desenvolvimento do projeto do produto e, portanto,
não será mais repetida no texto a seguir.
Para concluir a fase de projeto informacional, as especificações de pro-
jeto do produto são submetidas à aprovação, considerada como o critério
que autoriza o progresso para a fase seguinte, e são realizadas as análises
econômica e financeira e a atualização do plano do projeto. O monitora-
mento do progresso do projeto é realizado simultaneamente às tarefas da
fase. Finalmente, o comprometimento das áreas envolvidas no desenvol-
vimento é obtido através da avaliação e tomada de decisão de aprovação
de passagem de fase. Um maior detalhamento desta fase está apresentado
no Capítulo 5, que trata do processo de obtenção das especificações de
projeto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 78 — #106


i i

78 Projeto Integrado de Produtos: planejamento, concepção e modelagem

2.4.3 Fase 3 – Projeto conceitual

Esta fase destina-se ao desenvolvimento da concepção do produto,


conforme Figura 2.18 e detalhamento na Tabela A2 do Apêndice. Esta fase
do projeto do produto é iniciada com a orientação da equipe de desenvol-
vimento a respeito das atualizações do plano do projeto.
Para atingir o propósito da fase são realizadas diversas tarefas que bus-
cam, primeiramente, estabelecer a estrutura funcional do produto. Essa
atividade envolve a definição da função global a ser executada, bem como
de suas subfunções. Determinadas as funções a serem realizadas pelo pro-
duto, parte-se para o estudo de estruturas funcionais alternativas, com o
objetivo de selecionar a mais adequada. Sobre a estrutura funcional sele-
cionada são desenvolvidas concepções alternativas. Paralelamente às ati-
vidades da fase, o planejamento de marketing é continuado, sendo o mer-
cado monitorado para a identificação de variações que possam influen-
ciar no desenvolvimento da concepção. Para a seleção da concepção faz-se
uma análise comparativa entre as alternativas considerando: as especifica-
ções de projeto; o custo meta; os riscos de desenvolvimento (do projeto do
produto e do plano de manufatura – complexidade, prazo, custo, envolvi-
mento de fornecedores etc.); e as metas de qualidade, de segurança e de
dependabilidade.
Uma vez selecionada a concepção do produto, iniciam-se os estudos
para identificação dos processos de fabricação (novos ou conhecidos, in-
ternos ou externos) possíveis de serem utilizados. Simultaneamente, são
definidos os prazos junto aos fornecedores para o desenvolvimento do
projeto preliminar e detalhado das subfunções especificadas na estrutura
funcional, e é realizado estudo inicial de segurança na concepção seleci-
onada. Antes da aprovação da concepção, a mesma é avaliada quanto ao
atendimento ao escopo do projeto.
Na conclusão das atividades da fase de projeto conceitual, a concepção
é submetida à aprovação. A concepção aprovada é o critério que autoriza
o progresso para a fase seguinte. São realizadas ainda a análise e atua-
lização econômica e financeira do plano do projeto. O monitoramento do
progresso do projeto é feito simultaneamente às tarefas da fase. O compro-
metimento das áreas envolvidas no desenvolvimento é obtido por meio da
assinatura da ficha de aprovação de passagem de fase.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 79 — #107


i i

Desenvolvimeto integrado do projeto de produtos 79

Figura 2.18 Fluxograma da fase de projeto conceitual

Esta fase tem sua base de conhecimento desenvolvida nos Capítulos 6


a 10. Os Capítulos 6 e 7 tratam de métodos de geração de concepções. Os
Capítulos 8 e 9 consideram os aspectos de seleção da melhor concepção e o
Capítulo 10 trata da proteção da inovação e dos aspectos éticos envolvidos
no desenvolvimento do produto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 80 — #108


i i

80 Projeto Integrado de Produtos: planejamento, concepção e modelagem

2.4.4 Fase 4 – Projeto preliminar

Esta fase destina-se ao estabelecimento do leiaute final do produto e à


determinação da viabilidade técnica e econômica, conforme a Figura 2.19,
detalhada no Apêndice, Tabela A3. Nesta fase da elaboração do projeto do
produto, o trabalho é iniciado com a orientação da equipe de desenvolvi-
mento a respeito das atualizações do plano do projeto.
Para estabelecer o leiaute final, as tarefas realizadas são: identifica-
ção das especificações de projeto que relacionam os requisitos de forma
(dimensões), leiaute (posição), material, segurança, ergonomia e manufa-
tura; definição dos componentes e/ou unidades de grupos existentes a se-
rem utilizados (comprados e/ou desenvolvidos por fornecedores); revisão
das patentes e considerações sobre aspectos legais e de segurança; seleção
de leiautes alternativos para atender ao número de modelos do produto
definidos no planejamento de marketing; estabelecimento das principais
dimensões dos componentes, tipo de material, processo de fabricação, to-
lerâncias; realização de testes com mock-up para confirmar o atendimento
dos leiautes alternativos às necessidades do mercado; avaliação dos leiau-
tes dimensionais sob o ponto de vista da viabilidade técnica do projeto,
dos processos de manufatura, visando à otimização da concepção. Parale-
lamente às atividades da fase, o planejamento de marketing é continuado,
sendo o mercado monitorado para a identificação de variações que pos-
sam influenciar no estabelecimento do leiaute final do produto.
Para atender às suas funções, o projeto preliminar faz uso de diferentes
tipos de modelos: icônicos, analógicos, numéricos e computacionais, tam-
bém conhecidos como protótipos virtuais, os quais são objetos de estudo
nos Capítulos 11 e 12. Uma visão mais ampla desta fase será apresentada
no Capítulo 13.
Estabelecido o leiaute final, iniciam-se o desenvolvimento do plano de
fabricação e de teste do protótipo e a elaboração da estrutura preliminar
do protótipo, que serve de parâmetro para o cálculo inicial de custo. A
partir desse ponto, definem-se os requisitos de manufatura do protótipo,
avalia-se a capabilidade de manufatura interna e externa dos componen-
tes e realiza-se a análise de segurança sobre o leiaute final. Na seqüência,
determina-se a viabilidade econômica. Antes da aprovação da viabilidade
econômica, a mesma é avaliada quanto ao atendimento ao plano estraté-
gico de negócio da empresa.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 81 — #109


i i

Desenvolvimeto integrado do projeto de produtos 81

Figura 2.19 Fluxograma da fase de projeto preliminar

Para finalizar a fase de projeto preliminar, a viabilidade econômica é


submetida à aprovação, sendo este o critério que autoriza o progresso para
a fase seguinte. São realizadas a análise econômica e financeira e a atua-
lização do plano do projeto. O monitoramento do progresso do projeto
é feito simultaneamente às tarefas da fase. Com a assinatura da ficha de
aprovação de passagem de fase tem-se o comprometimento dos membros
da equipe de desenvolvimento nesta fase.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 82 — #110


i i

82 Projeto Integrado de Produtos: planejamento, concepção e modelagem

2.4.5 Fase 5 – Projeto detalhado

A fase da elaboração do projeto detalhado do produto destina-se a vá-


rios propósitos: aprovação do protótipo; finalização das especificações dos
componentes; detalhamento do plano de manufatura; e preparação da so-
licitação de investimento, como está indicado na Figura 2.20 e na Tabela
A4 do Apêndice. Após a orientação da equipe a respeito das atualizações
do plano do projeto, o protótipo é construído e são concluídos os testes e
ensaios de laboratório e de campo, de acordo com os planos de fabrica-
ção e de teste emitidos na fase anterior. Durante a realização dos testes,
são aplicadas diversas análises, como a de segurança do protótipo e/ou
de componentes do produto.
Paralelamente à construção, ao teste e à aprovação do protótipo, é con-
cluída a otimização das especificações dos componentes. Na seqüência, a
estrutura do produto é completada, os componentes certificados, o plano
de manufatura detalhado e as especificações técnicas fixadas. Nesta fase é
iniciada a elaboração do manual de instruções, do manual de assistência
técnica e do catálogo de peças.
Concluídos o projeto do produto e o plano de manufatura, iniciam-
se a revisão da documentação gerada e a implementação do controle das
mudanças do projeto. A partir do projeto do produto e do plano de manu-
fatura é preparada a solicitação de investimento. Antes da aprovação da
solicitação de investimento, a mesma é avaliada quanto ao atendimento
ao plano estratégico de negócio da empresa.
No encerramento da fase de projeto detalhado, a solicitação de in-
vestimento é submetida à aprovação, sendo este o critério que autoriza
o progresso para a fase seguinte. São finalizadas as análises econômica e
financeira do projeto do produto e a atualização do plano do projeto. O
monitoramento do progresso do projeto é realizado simultaneamente às
tarefas da fase. A decisão de passagem para fase de produção é submetida
à aprovação da equipe de desenvolvimento.

2.4.6 Fase 6 – Preparação da produção

Esta fase trata da preparação da produção do produto e da implemen-


tação do planejamento de marketing, conforme mostrado na Figura 2.21.
Esta é a fase em que se tem início a macrofase da implementação do lote

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 83 — #111


i i

Desenvolvimeto integrado do projeto de produtos 83

Figura 2.20 Fluxograma da fase de projeto detalhado

inicial. Após a orientação da equipe a respeito das atualizações do plano


do projeto, diversas atividades são realizadas simultaneamente com o ob-
jetivo de preparar a produção para a realização do teste de montagem. Es-
sas atividades incluem tipicamente: elaboração da documentação de mon-
tagem; liberação para construção de ferramental; compra, recebimento,

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 84 — #112


i i

84 Projeto Integrado de Produtos: planejamento, concepção e modelagem

instalação, teste, preparação das máquinas operatrizes, dos dispositivos e


ferramentas para a implementação da linha de produção e montagem do
lote piloto; e desenvolvimento do plano de produção e da programação
do lote piloto.
Durante a produção do lote piloto, os procedimentos de montagem
são testados para verificação de não conformidades no processo e, tam-
bém, para treinar o pessoal responsável pela montagem. Os produtos pro-
duzidos no lote piloto são analisados e comparados com a estrutura do
produto. Caso necessário, novos testes de laboratório e de campo são re-
alizados com produtos do lote piloto, assim como testes de homologação
e/ou ensaios de certificação de conformidade. Outras atividades ocorrem
em paralelo, tais como: revisão do plano de manufatura; implementação
do plano de qualidade; conclusão da elaboração dos procedimentos de
assistência técnica; treinamento das áreas de vendas e pós-vendas, bem
como das concessionárias.
A revisão da documentação do projeto do produto e do plano de ma-
nufatura é encerrada nesta fase, e os custos e investimentos envolvidos
no desenvolvimento do produto são rastreados. A partir desse ponto é
elaborada a liberação para lançamento do produto, que descreve suas ca-
racterísticas.
Para encerrar as atividades da fase de preparação da produção, a libe-
ração do produto é submetida à aprovação, sendo este o critério que auto-
riza o progresso para a fase seguinte. São realizadas a análise econômica
e financeira do projeto e a atualização do plano do projeto. O monitora-
mento do progresso do projeto é feito simultaneamente às tarefas da fase.
O comprometimento das áreas envolvidas no desenvolvimento é obtido
com a promoção do consenso sobre a ficha de aprovação de passagem de
fase.

2.4.7 Fase 7 – Lançamento do produto

Nesta fase é efetuado o lançamento do produto no mercado (Figura


2.22). Sendo esta a segunda fase da implementação do lote piloto, é nela
que é realizada a produção do lote inicial. Após a orientação da equipe a
respeito das atualizações do plano do projeto, segue a implementação do
planejamento de marketing, com a emissão do material promocional do
produto e da literatura técnica para divulgação comercial do produto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 85 — #113


i i

Desenvolvimeto integrado do projeto de produtos 85

Figura 2.21 Fluxograma da fase de preparação da produção

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 86 — #114


i i

86 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 2.22 Fluxograma da fase de lançamento

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 87 — #115


i i

Desenvolvimeto integrado do projeto de produtos 87

A definição da data de início da produção e a revisão do volume de


vendas, para a definição do volume de produção, marcam o começo da
preparação da produção. Segue com revisão da aprovação final (certifica-
ção) dos componentes para produção seriada, elaboração do cronograma
de implantação da fabricação dos itens, programação da produção do lote
inicial e revisão do ferramental de auxílio à produção.
Uma vez iniciada a produção na fábrica e nos fornecedores, é dado
acompanhamento à produção do lote inicial para verificação de não con-
formidades. Estando dentro dos padrões de qualidade, é elaborada a libe-
ração do lote inicial do produto, o qual é avaliado quanto ao atendimento
ao escopo do projeto. Para encerrar as atividades da fase de lançamento, a
liberação do lote inicial é submetida à aprovação, sendo este o critério que
autoriza o progresso para a fase seguinte.
O lançamento no mercado é realizado através da apresentação do
produto aos consumidores ou usuários, concessionários, vendedores, im-
prensa, entre outros. Há então a comercialização do lote inicial, que passa
a ser acompanhada pela área de pós-venda. As análises econômica e finan-
ceira do projeto são encerradas nesta fase, e o plano do projeto é atualizado
para dirigir as atividades da última fase do processo de desenvolvimento.
O monitoramento do progresso do projeto é realizado simultaneamente às
tarefas da fase. O comprometimento das áreas envolvidas no desenvolvi-
mento é obtido através da assinatura da ficha de aprovação de passagem
de fase.

2.4.8 Fase 8 – Validação do produto

A última fase do desenvolvimento do produto trata da validação do


produto junto aos usuários e à auditoria e da validação do projeto junto
ao cliente direto (Figura 2.23). É nesta fase que o projeto é encerrado. Após
a orientação da equipe a respeito das atualizações do plano do projeto, são
realizadas atividades relacionadas à comercialização. Elas envolvem tipi-
camente a implementação do plano para avaliação da satisfação dos con-
sumidores e/ou usuários, o monitoramento da performance do produto,
das informações sobre segurança na utilização e operação e da ocorrência
de acidentes, entre outros.
Para a validação do produto são definidos os itens a examinar e os cri-
térios de avaliação. A validação é feita sobre os produtos do lote inicial

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 88 — #116


i i

88 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 2.23 Fluxograma da fase de validação

comercializado junto aos usuários. Posteriormente é realizada a avaliação


final da validação do produto, que consiste na análise do relatório de va-
lidação. Da análise resultam a definição de ações corretivas para os pro-
blemas identificados, a definição dos prazos para a sua implementação
e a implementação propriamente dita. Na seqüência, inicia-se o planeja-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 89 — #117


i i

Desenvolvimeto integrado do projeto de produtos 89

mento para o alcance das metas de melhoria contínua, tais como redução
do custo, melhoria das características do produto e aumento da perfor-
mance.
Para encerrar as atividades da fase de validação, o monitoramento do
progresso do projeto é concluído e o resultado do projeto – relatórios de
validação do produto e de progresso do projeto – é submetido à auditoria e
à validação junto ao usuário direto ou patrocinador. Realizada a auditoria
do projeto, é assinado o documento de aceitação formal do resultado do
projeto e é emitida a validação do projeto do produto. Neste momento,
os contratos pendentes são liquidados, é realizada a prestação de contas
do projeto, a equipe de desenvolvimento é desmobilizada, bem como sua
estrutura e projeto são encerrados.

2.5 Resumo

No presente capítulo foram apresentados aspectos referentes às prin-


cipais estruturas, de metodologias ou procedimentos de desenvolvimento
do projeto de produtos, propostas por diferentes autores nos últimos qua-
renta anos. Os principais resultados, aqui descritos, podem ser resumidos
como segue:

1. As metodologias de projeto de produtos industriais evoluíram, de um pri-


meiro estágio a partir de metodologias prescritivas, para um estágio inter-
mediário de metodologias de projeto para o ciclo de vida do produto, até o
estágio atual de engenharia simultânea ou de desenvolvimento integrado do
projeto de produtos.
2. Entre as metodologias prescritivas do primeiro estágio de evolução, desta-
cam-se as seguintes estruturas do processo de desenvolvimento do projeto:
de Asimov, que primeiro publicou seu modelo em 1962, com três fases de
projeto e quatro fases de planejamento do pós-venda; de Woodson, que di-
vulgou em 1966 seu modelo com quatro fases, viabilidade de projeto, projeto
preliminar, projeto detalhado e revisão do projeto; de Coryell, que apresen-
tou em 1967 um modelo com doze passos para o processo de projeto e desta-
cou cinco pontos de revisão, em que as soluções são analisadas, avaliadas e
comparadas com os requisitos de projeto, seguindo em frente, por meio das
válvulas, somente as soluções que atendem a todos os requisitos e restrições
de projeto; e, finalmente, em 1977, de Pahl e Beitz, que apresentaram sua

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 90 — #118


i i

90 Projeto Integrado de Produtos: planejamento, concepção e modelagem

estrutura com quatro fases, definição da tarefa, desenvolvimento da concep-


ção, projeto preliminar e projeto detalhado.
3. Das metodologias prescritivas, a que obteve maior reconhecimento foi a de
Pahl e Beitz, considerada, até recentemente, a mais apropriada para o de-
senvolvimento de sistemas técnicos, tais como máquinas e equipamentos.
4. As metodologias prescritivas apresentam, adequadamente, o desdobramento
do processo de projeto, ou seja, apresentam o que fazer, mas, no que se refere
a quando fazer, são do tipo seqüencial, o que demanda um maior tempo de
desenvolvimento e mais modificações de projeto para atender à conformi-
dade do produto.
5. A metodologia de projeto proposta por Blanchard e Fabrycky (1990), publi-
cada em 1980 em sua primeira edição, é uma evolução em relação às demais
metodologias prescritivas, porque considera, concomitantemente em todas
as tomadas de decisão ao longo do processo de projeto, os requisitos e as
restrições de todas as fases do ciclo de vida do produto e já considera uma
equipe de projeto.
6. A engenharia simultânea é, segundo Sprague (1991), uma abordagem sis-
temática para o projeto simultâneo e integrado de produtos e de processos
relacionados, incluindo manufatura e suporte. Procura considerar todos os
elementos do ciclo de vida do produto, desde a concepção até a disposição,
incluindo qualidade, custo, programação e requisitos dos usuários.
7. A modelagem do processo de trabalho, no contexto da engenharia simultâ-
nea, deve apresentar as seguintes características: uma estrutura de relacio-
namentos entre a organização, o produto que está sendo desenvolvido, os
recursos disponíveis e o fluxo de trabalho; uma decomposição hierárquica
do processo, possibilitando a identificação das interfaces entre as equipes de
trabalho; permitir a distribuição paralela das tarefas para o trabalho simul-
tâneo das equipes durante a realização das respectivas tarefas; possibilitar
o estabelecimento de diagramas de fluxo de informação para destacar quem
faz (pessoa ou equipe) determinada atividade e a seqüência dos tempos nos
quais as atividades são realizadas; o modelo do processo deve permitir a evo-
lução progressiva à medida que o produto evolui através dos vários estágios
de desenvolvimento.
8. A engenharia simultânea (ES) tem como objetivo primeiro desenvolver o
projeto de um produto, reduzindo tempo e custo, e aumentar sua qualidade,
utilizando equipe de projeto multidisciplinar ou multifuncional.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 91 — #119


i i

Desenvolvimeto integrado do projeto de produtos 91

9. A implantação da ES na empresa traz muitas dificuldades, advindas princi-


palmente das necessidades de mudanças no modo de trabalho de uma equipe
com diferentes funções e formações dentro da empresa e até de diferentes cul-
turas dos colaboradores. Por essa razão, as possíveis falhas e barreiras dessa
implantação devem ser estudadas com todo o cuidado para minimizar seus
efeitos negativos.
10. As falhas na implantação da ES na empresa podem ser classificadas como:
de iniciação; de preparação e planejamento do processo de implantação; e de
implantação propriamente dita.
11. As falhas na iniciação do processo de introdução da engenharia simultânea
estão relacionadas a: forma de avaliação dos possíveis custos e benefícios;
escolha do adequado promotor da introdução da ES na empresa; falta de
objetivos claros e bem definidos ou uma visão adequada do processo; falta e
busca de experiência.
12. Na preparação e no planejamento da implantação da ES, as principais fa-
lhas advêm das seguintes origens: prioridade dada pela alta gerência; coo-
peração entre as diferentes áreas funcionais da empresa; formação do grupo
ou equipe de trabalho multidisciplinar; paralisia cultural ou dificuldade de
assimilar novas idéias ou modos de trabalho; grande variedade de ferramen-
tas e escolha das mais apropriadas; visão e adoção da tecnologia apropriada
na solução do problema; data ou oportunidade de início de implantação da
ES; medo do insucesso; quem estabelece as especificações de projeto, a equipe
de desenvolvimento ou outro grupo; e importância dada ao lançamento do
projeto de implantação da ES.
13. Na execução do plano de implantação da ES as principais falhas têm ori-
gem nos seguintes aspectos: grau de envolvimento e comprometimento da
média gerência das áreas funcionais da empresa; definição correta das atri-
buições e responsabilidades dos membros da equipe; expansão e aprendizado
na execução do plano.
14. Princípios básicos para o sucesso na formação de equipes multidisciplinares
são: formar as equipes com base em objetivos comuns e respeito por todas
as áreas representadas; garantir a participação de representantes de todas as
grandes áreas da organização; entendimento comum e uniforme sobre ES;
a forma como o consenso para a convergência de soluções é obtido deve ser
bem entendida por todos; o consenso prematuro e fácil deve ser evitado; de-
finir de modo criterioso os trabalhos que devem ser feitos individualmente e

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 92 — #120


i i

92 Projeto Integrado de Produtos: planejamento, concepção e modelagem

aqueles que devem ser feitos pela equipe; adotar métodos sistemáticos; esti-
mular a comunicação formal e informal; selecionar pelo menos alguns dos
membros da equipe segundo aptidões e especialidades; desenvolver uma li-
derança desde o início.
15. Os principais benefícios da ES são: o desenvolvimento dos sistemas de pro-
dução e das áreas de apoio logístico tem um início mais cedo; a análise dos
aspectos relacionados ao produto ocorre simultaneamente entre projeto, pro-
dução e logística, como um sistema único; facilidade de obter um bom pro-
jeto para manufatura e apoio logístico; a produção e as pessoas das áreas
de apoio ganham um claro entendimento do projeto e comprometem-se com
seu sucesso; as modificações no protótipo são reduzidas porque o projeto se
torna mais maduro desde as fases iniciais.
16. O processo de desenvolvimento integrado de produtos (PRODIP) apresenta
três macrofases: planejamento do projeto; elaboração do projeto do produto;
e planejamento da implementação. A macrofase de elaboração do projeto
do produto é decomposta nas seguintes fases: projeto informacional; projeto
conceitual; projeto preliminar; projeto detalhado. A macrofase de implemen-
tação é decomposta nas fases de preparação da produção, do lançamento e
da validação do produto.
17. O modelo de referência PRODIP apresenta o processo de desenvolvimento
do produto sob as seguintes dimensões: o processo é desdobrado em tare-
fas; definem-se as entradas para a execução das tarefas; são identificados os
domínios de conhecimento para a realização das tarefas; apresentam-se me-
canismos (métodos e ferramentas) para a execução das tarefas; identifica-se
o monitoramento da qualidade de execução das tarefas por meio de controles;
e, finalmente, apresentam-se os resultados das tarefas com saídas.

2.6 Problemas e temas de discussão

1. Este capítulo descreve metodologias de desenvolvimento de projeto


de produtos industriais. Quais são os elementos principais que uma
metodologia deve conter e, segundo sua opinião, qual deve ser o
nível de desdobramento ou detalhamento para que a mesma seja
compreensível e eficaz?
2. Quais são os principais motivos que levaram, na atualidade, as em-
presas mais competitivas a adotarem procedimentos sistematizados

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 93 — #121


i i

Desenvolvimeto integrado do projeto de produtos 93

e integrados de desenvolvimento do projeto de produtos, especial-


mente aqueles do tipo de sistemas técnicos?
3. As empresas têm relatado resultados favoráveis consideráveis no de-
senvolvimento de produtos com a adoção de metodologias sistema-
tizadas. Descreva pelo menos cinco resultados de destaque obtidos
com o uso dessas metodologias.
4. Certos profissionais, principalmente da área de desenho industrial,
têm criticado o uso de metodologias de projeto. Afirmam que, ao
adotar um procedimento sistematizado do tipo prescritivo, isso pre-
judica a criatividade e que as maiores criações surgiram de forma
caótica. De acordo com sua opinião, quais seriam as principais ra-
zões dessas críticas? Essas razões têm justificativas?
5. Faça uma breve descrição da evolução, nos últimos trinta anos, das
características das propostas de metodologias de desenvolvimento
do projeto de produtos industriais.
6. O que você entende por ciclo de vida do produto e projeto para o
ciclo de vida?
7. O que são metodologias prescritivas de projeto de produtos indus-
triais? Quais são as principais características dessas metodologias?
8. Quais são as principais razões que levaram a metodologia de Pahl e
Beitz a ser a mais referenciada metodologia prescritiva de desenvol-
vimento do projeto de produtos?
9. Uma metodologia de projeto deve conter diretrizes sobre o que fazer,
para quem fazer, quando fazer, com que fazer e como fazer. Analise
as metodologias prescritivas apresentadas no item 2.2 e faça comen-
tários sobre o atendimento às diretrizes dessas metodologias.
10. Apresente no mínimo três definições de engenharia simultânea en-
contradas na literatura. Comente os principais aspectos de cada
uma.
11. Quais são as principais características que diferenciam as metodolo-
gias prescritivas de desenvolvimento do projeto de produtos indus-
triais, descritas no item 2.2, da engenharia simultânea, descrita no
item 2.3.
12. Cite benefícios advindos da aplicação da engenharia simultânea no
desenvolvimento de produtos industriais.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 94 — #122


i i

94 Projeto Integrado de Produtos: planejamento, concepção e modelagem

13. Na engenharia simultânea, o elemento principal é a adoção da equi-


pe multidisciplinar ou multifuncional. Quais são as principais carac-
terísticas dessa equipe?
14. O que significa engenharia simultânea baseada na equipe e engenha-
ria simultânea baseada em recursos?
15. Segundo relatos de pesquisadores e de empresas, a implantação da
engenharia simultânea tem mostrado muitas dificuldades. Quais são
as cinco principais dificuldades e apresente as razões que o levaram
a essas escolhas.
16. Alguns autores consideram a engenharia simultânea uma filosofia
de trabalho e não uma metodologia de desenvolvimento do projeto
de produtos. Segundo sua opinião, é uma filosofia ou uma metodo-
logia? Justifique suas afirmações.
17. Faça uma análise crítica do modelo integrado para o projeto de pro-
duto apresentado esquematicamente na Figura 2.11.
18. No modelo genérico de desenvolvimento integrado de produtos da
Figura 2.14, têm-se indicadas áreas de conhecimento nas quais a
equipe de desenvolvimento deve ter capacitações. Quais deveriam
ser as especialidades dos membros da equipe de desenvolvimento
para desenvolver o projeto de uma máquina agrícola, uma semea-
dora de plantio direto?
19. Faça uma análise crítica sobre o desdobramento das atividades, os
mecanismos e os instrumentos usados para a realização e o controle
das atividades de desenvolvimento da fase de projeto informacional
do modelo PRODIP.
20. Faça uma descrição do processo de otimização desenvolvido na fase
de projeto preliminar do modelo de referência PRODIP.

2.7 Referências bibliográficas

ASIMOV, M. Introduction to design: fundamentals of engineering de-


sign. Prentice Hall, 1962. Traduzido para o português. Introdução
ao projeto de engenharia. São Paulo: Mestre Jou, 1968.
BACK, N. Metodologia de projeto de produtos industriais. Rio de Ja-
neiro: Guanabara Dois, 1983

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 95 — #123


i i

Desenvolvimeto integrado do projeto de produtos 95

BLANCHARD, B. J; FABRYCKY, W. J. Systems engineering and analy-


sis. 2.ed. New Jersey: Prentice Hall, 1990.
CHIUSOLI, R. F. Z. e TOLEDO, J. C. Engenharia simultânea: estudo de
casos na indústria brasileira de autopeças. In: Anais do II Congresso
Brasileiro de Gestão de Desenvolvimento de Produtos. São Carlos,
2000.
CLAUSING, D. Total quality development – a step-by-step guide to
world-class concurrent engineering. New York: ASME Press, 1994.
CORYELL, A. E. The design process: 12 steps that turn ideas into hard-
ware. Machine Design. p.154-161, November 9, 1967.
EVANS, S. Implementation: common failure modes and success fac-
tors. In: PARSEI, H. R.; SULLIVAN, W. G. (Eds.). Concurrent En-
gineering: contemporary issues and modern design tools. London:
Chapman and Hall, p.42-60, 1993.
HUNDAL, M. S. Systematic mechanical designing: a cost and mana-
gement perspective. New York: ASME Press, 1997.
HYEON, H. JO; PARSAEI, H. R.; SULLIVAN, W. G., Principles of con-
current engineering. In: PARSEI, H. R.; SULLIVAN, W. G. (Eds.).
Concurrent engineering: contemporary issues and modern design
tools. London: Chapman and Hall, p.3-23, 1993.
ISHII, K.; HORNBERGER, L.; LIOU, M. Compatibility-based design for
injection molding. Proceedings of the 1989 ASME Winter Annual
Meeting: Concurrent Product and Process Design. San Francisco,
p.153-180, 1989.
MADDUX, G. A.; SOUDER, W. E. Overcoming Barriers to the Imple-
mentation of Concurrent Engineering. In: PARSEI, H. R.; SULLI-
VAN, W. G. (Eds.). Concurrent Engineering: contemporary issues
and modern design tools. London: Chapman and Hall, p.61-74,
1993.
MILLER, L. C. G. Concurrent engineering design: integrating the best
practices for process improvement. Dearborn, Michigan: Society of
Manufacturing Engineers, 1993.
PAHL, G.; BEITZ, W. Engineering design: a systematic approach. 2.ed.
London: Springer Verlag, 1996.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 96 — #124


i i

96 Projeto Integrado de Produtos: planejamento, concepção e modelagem

PRASAD, B.; WANG, F.; DENG, J. A concurrent workflow management


process for integrated product development. Journal of Enginee-
ring Design. v.9, n.2, p.121-135, 1998.
ROMANO, L. N. Modelo de referência para o processo de desenvol-
vimento de máquinas agrícolas. Florianópolis, 2003. 266f. Tese de
doutorado – PPGEM – UFSC.
SMITH, R. P. The historical roots of concurrent engineering funda-
mentals. IEEE Transactions on Engineering Management, v.44, n.1,
p.67-78, 1997.
SPRAGUE, R. A.; SINGH, K. J.; WOOD, R. T. Concurrent engineering in
product development. IEEE Design and Test of Computers, v.8, n.1,
p.6-13, 1991.
VDI 2221. Methodik zum Entwickeln und Konstruieren Technischer
Systeme und Produkte. Düsseldorf: VDI – Verlag, 1985. 35p.
WOODSON, T. T. Introduction to engineering design. EUA: McGraw
– Hill, 1966.
YAZDANI, B.; HOLMES, C. Four models of design definition: sequen-
tial, design centered, concurrent and dynamic. Journal of Enginee-
ring Design, v.10, n.1, p.25-37, 1999.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 97 — #125


i i

Capítulo 3

Gerenciamento do desenvolvimento
integrado de produtos

3.1 Introdução

Várias condições têm contribuído para a aplicação de conhecimentos


de gerenciamento de projetos nos processos das organizações. Dentre elas,
citam-se a estruturação de organizações com número cada vez menor de
pessoas e, em geral, mais trabalho para executar; projetos cada vez mais
complexos, com o crescimento constante da necessidade de atender mais
rapidamente ao mercado; e os mercados globais, com clientes mais exigen-
tes e tecnologias disponíveis mais avançadas. Essas condições impõem vá-
rios desafios às equipes que trabalham em desenvolvimento de produtos,
sejam próprios da organização para o trabalho, das soluções e das tecnolo-
gias necessárias ao produto, ou como desafios para satisfazer os diferentes
interesses no processo de desenvolvimento.
A literatura atual é bastante rica em referências que tratam de conheci-
mentos sobre o gerenciamento de projetos e muitas empresas já fazem uso
desses conhecimentos, métodos e ferramentas para conduzir de forma or-
ganizada e controlada seus projetos, entre os quais os de desenvolvimento
de produtos.
Por outro lado, sabe-se também que boa parte das empresas não em-
prega práticas de gerenciamento de projetos, seja por desconhecimento,
pela falta de formação de seus profissionais, ou pela inexistência de pro-
cessos sistematizados de desenvolvimento de produtos nas organizações.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 98 — #126


i i

98 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Nesses casos, essas empresas perdem a oportunidade de planejar melhor


os trabalhos e os recursos necessários e obter eficiência e eficácia em seus
processos, o que as tornaria mais competitivas e aumentaria a chance de
sucesso em seus empreendimentos.
Os conceitos de gerenciamento de projetos originaram-se nos EUA, se-
gundo Codas (1987), no fim dos anos 1950, sendo aplicados em projetos de
sistemas de informação e de construção. Porém, alguns autores comentam
que a aplicação dos princípios de gerenciamento de projetos remonta à an-
tiguidade, época em que houve grandes construções, como as pirâmides
do Egito. Nesses casos, já naquela época, segundo Verzuh (2000), se faziam
necessários o planejamento e a coordenação de uma série de recursos para
concretizar uma obra.
Alguns marcos importantes nesse campo de conhecimento, cujos re-
sultados são aplicados até hoje, correspondem à proposição de métodos e
ferramentas para o gerenciamento de projetos. Cita-se, por exemplo, a pro-
posição do gráfico de Gantt, no início do século XIX, por Henry L. Gantt
(Verzuh, 2000), aplicado ao gerenciamento do tempo e que se encontra im-
plementado em vários tipos de software atuais de gerenciamento de proje-
tos. Foram desenvolvidos na década de 1950 os métodos conhecidos como
CPM (Critical Path Method) e PERT (Program Evaluation Review Technique).
O CPM foi desenvolvido pela DuPont Company em 1956, para aplicação
em projetos industriais, e o PERT, pela Marinha americana em 1958, para
aplicações em projetos militares.
Na década de 1970, segundo Codas (1987), o gerenciamento de proje-
tos de construção foi predominante e surgiram técnicas específicas para
o gerenciamento de interfaces entre engenharia, compras e construção.
Ainda nessa época ocorreram grandes mudanças econômicas causadas
pelo aumento da inflação, crise do petróleo, falta de matéria-prima, inter-
nacionalização de projetos, aumento da sofisticação e complexidade dos
produtos, entre outros, promovendo o aparecimento de novas variáveis
no processo de gerenciamento associadas, principalmente, às incertezas
dos empreendimentos. Enfatizaram-se, então, proposições relacionadas ao
gerenciamento dos riscos em projetos. Especula-se aqui que o escopo do
projeto começa a ter um status de importância equivalente às variáveis de
tempo e custo, inicialmente consideradas, tendo em vista que, com maio-
res incertezas e riscos, se fez necessário definir melhor e focalizar os obje-
tivos do projeto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 99 — #127


i i

Gerenciamento do desenvolvimento integrado de produtos 99

Na década de 1980, as organizações se tornaram mais complexas, são


departamentalizadas, obrigando a definição de responsabilidades em um
ambiente de grande número de atividades e subdivisões, promovendo
questões relacionadas à comunicação e ao desdobramento do trabalho.
Assim, o fluxo e o acesso às informações tornaram-se importantes para a
tomada de decisões, surgindo então sistemas computacionais para facilitar
o armazenamento e a recuperação de informações para o gerenciamento
de projetos.
Na década de 1990 o consumidor assume papel preponderante nos
negócios e nos resultados das organizações, bem como em seu sucesso. A
concorrência pela abertura da maioria dos mercados é acirrada, e a variá-
vel qualidade passa a ter grande importância no gerenciamento de proje-
tos de desenvolvimento de produtos.
Atualmente, o gerenciamento de projetos tem sido aplicado a pra-
ticamente quase todas as áreas das atividades humanas, suportando o
planejamento e a tomada de decisões sob as mais variadas condições.
Encontram-se associadas, também, abordagens que tratam do gerencia-
mento do conhecimento, da tecnologia, da criatividade, além das áreas
tradicionais relacionadas a gerenciamento de projetos: comunicações, ris-
cos, aquisições etc. Alguns aspectos atuais bastante importantes se referem
aos problemas humanos e comportamentais no projeto, como competên-
cias, habilidades, motivação e conflitos, tratados, em parte, por áreas como
gerenciamento de equipes, de competências e de conflitos, visando a flexi-
bilidade, satisfação pessoal, motivação, eficiência e eficácia nos trabalhos
de projeto.
O gerenciamento de projeto tornou-se uma disciplina que é ensinada
e pesquisada em várias instituições, promovendo a formação e a certifica-
ção de profissionais especializados em planejar, conduzir e controlar pro-
jetos em toda a sua extensão. Várias associações foram criadas ao longo
do tempo, como o PMI (Project Management Institute – Instituto de gerencia-
mento de projeto), nos anos 1960, nos Estados Unidos, com o objetivo de
promover a área e difundir os conhecimentos e a tecnologia de gerencia-
mento de projetos.
O gerenciamento de projetos no Brasil, segundo Codas (1987), seguiu
a mesma direção que em outros países. Inicialmente foi aplicado no pla-
nejamento e na execução de instalações industriais e no gerenciamento de

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 100 — #128


i i

100 Projeto Integrado de Produtos: planejamento, concepção e modelagem

projeto de hidroelétricas. Um exemplo desta aplicação ocorreu com o pro-


jeto de Itaipu.
Neste capítulo serão apresentados os principais conceitos do geren-
ciamento de projetos e seu enfoque no desenvolvimento de produtos. A
ênfase será dada aos assuntos que tratam do escopo do projeto, da estru-
tura organizacional, das equipes de desenvolvimento de produtos, infra-
estrutura e do planejamento do processo de desenvolvimento de produ-
tos. As demais áreas do gerenciamento de projetos, como riscos, aquisi-
ções, qualidade, comunicações, entre outras, serão brevemente comenta-
das com indicações de referências mais completas sobre cada um dos as-
suntos. Finalmente, serão apresentados temas e problemas sobre o geren-
ciamento do desenvolvimento de produtos para discussão.

3.2 Considerações gerais sobre gerenciamento


de projetos

Os conhecimentos e práticas de gerenciamento, de modo geral, foram


estabelecidos ao longo do tempo, sob diferentes visões. De acordo com
Kerzner (2001), as principais visões ou escolas de gerenciamento são:

• clássica: o gerenciamento é o processo que “faz as coisas acontece-


rem” com o trabalho de pessoas, operando em grupos organizados.
A ênfase está no objetivo final, pouco considerando as pessoas en-
volvidas;
• empírica: as capacidades gerenciais podem ser desenvolvidas estu-
dando-se as experiências de outros gerentes, considerando situações
similares;
• comportamental: primeiramente, são enfatizados os relacionamen-
tos interpessoais entre os indivíduos e seus trabalhos. Em seguida,
considera-se o sistema social do indivíduo, em que o gerenciamento
se insere em um sistema de relacionamentos culturais, envolvendo
mudanças sociais;
• de decisão: o gerenciamento é uma abordagem racional para a to-
mada de decisão, usando um sistema de modelos e processos mate-
máticos;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 101 — #129


i i

Gerenciamento do desenvolvimento integrado de produtos 101

• sistêmica: o gerenciamento é o desenvolvimento de um modelo ca-


racterizado por entradas, processos e saídas, identificando direta-
mente o fluxo de recursos necessários para atender aos objetivos,
maximizando ou minimizando alguma função objetivo. Também in-
clui considerações de contingências sob as quais cada situação é
única e deve ser otimizada separadamente dentro das restrições do
sistema.

Sob tais visões, o gerenciamento de projetos é implementado de várias


formas, seja como conhecimento de pessoal qualificado à condução eficaz
de projetos, como habilidades e infra-estrutura necessárias para gerenciar
projetos, seja na forma de ferramentas e técnicas de apoio ao gerencia-
mento de projetos. Essas formas podem ser claramente identificadas nas
definições propostas para gerenciamento de projetos.
Segundo o PMI (2000), o gerenciamento de projetos consiste na aplica-
ção de conhecimentos, habilidades, ferramentas e técnicas nas atividades
de projeto e visa a satisfazer os requisitos de projeto, sendo conduzido sob
os processos gerais de iniciação, planejamento, execução, controle e encer-
ramento.
De acordo com Kerzner (2001), o gerenciamento de projetos consiste
em planejar, organizar, direcionar e controlar os recursos da organização
para satisfazer um objetivo, num tempo relativamente curto, estabelecido
para atender a objetivos e metas específicas.
A norma NBR ISO 10006 da ABNT (2000) estabelece que o gerencia-
mento de projetos inclui planejamento, organização, supervisão e controle
de todos os aspectos do projeto, em um processo contínuo, para alcançar
seus objetivos.
Por meio das visões e definições anteriores, pode-se inferir e repre-
sentar alguns elementos básicos associados ao gerenciamento de projetos,
conforme mostrado na Figura 3.1.
De acordo com a figura, o projeto pode ser formulado como um pro-
cesso cujo propósito consiste em estabelecer soluções, devidamente carac-
terizadas, que representam os objetivos e as metas dos usuários (stakehol-
ders), partindo de problemas que estão sujeitos a restrições e são condici-
onados por requisitos, que são derivados dos interesses de todos os usuá-
rios (como será tratado no Capítulo 5, entende-se por usuários todos que
tenham algum interesse ou envolvimento ao longo do ciclo de vida de um

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 102 — #130


i i

102 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 3.1 Síntese de elementos envolvidos no gerenciamento de projetos

produto). O gerenciamento de projetos sob essa visão consiste em ações


coordenadas, desde o estabelecimento do problema até a formalização e
a aprovação final da solução, baseadas em características próprias do ge-
rente e da equipe de projeto, na forma de conhecimentos, habilidades e
princípios de gerenciamento para a prática dessas ações, ocorrendo atra-
vés de métodos e ferramentas de gerenciamento, sendo estes elementos
conduzidos sob diferentes visões.
O projeto, assim, consiste no objeto principal do gerenciamento, de-
finido de várias maneiras, mas com elementos em comum. Por exemplo,
segundo Kerzner (2001), um projeto é uma série de atividades e tarefas que
tem um objetivo específico que deve ser alcançado dentro de certas espe-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 103 — #131


i i

Gerenciamento do desenvolvimento integrado de produtos 103

cificações; tem datas de início e fim definidas; tem limite de orçamento e


consome recursos financeiros e de pessoal, equipamentos etc. Os projetos
diferenciam-se das atividades rotineiras da organização porque são únicos
e temporários. Típicos exemplos de projeto são: desenvolvimento de um
software; implantação de um novo sistema de informações na organização;
construção de edifícios, estradas, pontes, barragens; desenvolvimento de
um novo medicamento; melhoramento do serviço de atendimento ao cli-
ente; desenvolvimento de componentes, equipamentos, máquinas etc.
As ações coordenadas do gerenciamento são baseadas em vários pro-
cessos, os quais são estabelecidos por diferentes modelos, conforme será
discutido mais adiante. Esses processos, por sua vez, devem ser condu-
zidos sob certos princípios para orientar as ações de gerenciamento. De
acordo com Wideman (2000), tais princípios não têm sido muito explora-
dos e algumas proposições nesse sentido estão comentadas na Tabela 3.1.
A aplicação de princípios, conhecimentos, habilidades, métodos e fer-
ramentas de gerenciamento se dá pelas ações sistematizadas na forma de
processos ou funções de gerenciamento, que têm sido propostas de dife-
rentes formas. De acordo com o PMI (2000), os processos principais são:
iniciação, planejamento, execução, controle e encerramento do projeto.
O processo de iniciação considera as ações necessárias para reconhecer
que um projeto ou fase de desenvolvimento deve começar e para desen-
volver o comprometimento em sua execução. O processo de planejamento
consiste em planejar e manter o plano de trabalho necessário para alcan-
çar os objetivos do empreendimento, os quais determinaram o negócio. O
processo de execução consiste em ações para coordenar as pessoas e outros
recursos para a realização do plano. O processo de controle visa assegu-
rar que os objetivos traçados no plano do projeto estejam sendo satisfei-
tos, conduzidos na forma do monitoramento, avaliação e ações corretivas,
quando necessário. Finalmente, o processo de encerramento formaliza a
aceitação dos resultados do projeto ou de cada fase, de forma organizada.
No modelo apresentado por Verzuh (2000), as ações de gerenciamento
de projetos são propostas na forma das funções de definição do projeto, de
planejamento e de controle. Na definição do projeto busca-se estabelecer
os trabalhos necessários, as responsabilidades, as formas de comunicação
entre os envolvidos e as regras do projeto. Esses resultados formam base
para a função de planejamento, cujo propósito é estabelecer como as metas
do projeto deverão ser atendidas diante das limitações impostas. O plano

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 104 — #132


i i

104 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 3.1 Princípios de gerenciamento de projetos (adaptado de


Wideman, 2000)

Princípios Comentários
Comprometimento: O provedor de recursos é tipicamente
“Deve existir um chamado de patrocinador ou proprietário
comprometimento do projeto. A equipe de projeto é
eqüitativo entre o responsável pelo desenvolvimento de
provedor de recursos e a estratégias, planos e controles, pela
equipe de aplicação de habilidades necessárias e pelo
desenvolvimento do trabalho para converter os recursos nas
projeto antes de o entregas requeridas. Um compromisso
mesmo existir.” eqüitativo entre ambas as partes significa
que são suficientemente conhecedoras do
empreendimento, do processo envolvido e
dos riscos associados e que ambos estão
dispostos ao desafio.
Sucesso: O sucesso do projeto deve ser definido em
“As medidas do sucesso termos da aceitabilidade dos resultados do
do projeto, ambos do projeto, envolvendo escopo, qualidade,
processo e do produto, relevância, eficácia etc. Também deve ser
devem ser definidas no definido em termos dos processos internos,
início do projeto como envolvendo tempo, custo, eficiência etc.
base para as decisões de Sem concordância quanto aos critérios de
gerenciamento do sucesso do projeto, não será possível medir
projeto e avaliação seu sucesso final.
pós-projeto.”
Compromisso da tétrade: Essas variáveis são medidas da eficiência
“As variáveis do núcleo interna do gerenciamento do projeto. Se
do gerenciamento de essas variáveis não forem mutuamente
projeto, denominadas de consistentes e atendíveis, o
escopo, qualidade, comprometimento não será alcançado e os
tempo e custo, devem critérios de sucesso do projeto não serão
ser mutuamente satisfeitos.
consistentes e atendíveis.”
Estratégia: Todo o trabalho de projeto deve primeiro ser
“Deve ser considerada planejado e depois executado. Esse
uma estratégia aplicada processo seqüencial de planejamento -
de forma progressiva de execução deve ser base em todo o ciclo de
primeiramente planejar e vida do projeto e não deve limitar-se ao nível
depois executar.” de projeto, mas igualmente aplicável em
qualquer nível da estrutura hierárquica do
projeto.
Continua na próxima página

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 105 — #133


i i

Gerenciamento do desenvolvimento integrado de produtos 105

Tabela 3.1 Princípios de gerenciamento de projetos (adaptado de


Wideman, 2000)

Princípios Comentários
Controle: Os atributos do controle incorporam as
“Devem ser definidos considerações de projeto, suas justificativas e
políticas e procedimentos uma linha de referência para cada variável
que sejam efetivos e núcleo do projeto, como base para
eficientes para conduzir e medição do progresso, comparação e
controlar o ajuste do curso. Os atributos de boas
comprometimento do políticas e procedimentos de controle
projeto.” incorporam responsabilidades e papéis
claros, delegação de autoridade e
processos para gerenciar mudanças no
escopo do produto e/ou do trabalho.
Comunicação: Manter a comunicação livre e transparente
“Deve existir um único é indispensável para a coordenação de um
canal de comunicação conjunto complexo de atividades de projeto,
entre o patrocinador do sendo necessária para uma administração
projeto e o líder da efetiva e eficiente do comprometimento do
equipe de projeto para projeto. A equipe de projeto deve ter sempre
todas as decisões que um representante principal para as
afetam o escopo do comunicações.
produto.”
Ambiente cultural: A habilidade da equipe de projeto para
“O gerenciamento deve produzir resultados efetivos e eficientes é
promover um ambiente fortemente dependente do ambiente da
cultural informado e com organização. Esse ambiente incorpora
suporte para assegurar valores e relações internas e externas do
que a equipe de projeto projeto. Internamente, o estilo de
esteja hábil para gerenciamento da equipe deve se adequar
trabalhar nos limites de ao tipo de projeto e suas fases.
sua capacidade.” Externamente, o gerenciamento da
organização, do qual o projeto é parte, deve
apresentar suporte e estar livre de
obstáculos.

de projeto deverá incluir a quantidade de trabalho, a alocação de recursos,


os tempos necessários, o cronograma e o orçamento, bem como as ações
diante dos riscos identificados. A função de controle, por sua vez, inclui as
atividades para manter o projeto em andamento, visando atender às metas
estabelecidas, incluindo medição de progresso, comunicações e interven-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 106 — #134


i i

106 Projeto Integrado de Produtos: planejamento, concepção e modelagem

ções corretivas. Essas funções são seqüenciais, porém repetidas à medida


que o projeto avança.
Os processos anteriores sistematizam as ações básicas de gerencia-
mento. No entanto, considerando as relações internas e externas do pro-
jeto, existe uma série de outras ações que, segundo o PMI (2000), são incor-
poradas nas chamadas áreas relacionadas ao gerenciamento de projetos:
gerenciamento da integração, do escopo, do tempo, dos custos, da quali-
dade, dos recursos, das comunicações, dos riscos e das aquisições. A inte-
gração dessas áreas e de suas ações visa promover condições para atender
de maneira balanceada às principais variáveis de sucesso de dado projeto:
escopo, tempo, custo e qualidade.

3.3 Gerenciamento do desenvolvimento


integrado de produtos

Os itens anteriores trataram de um breve histórico sobre gerencia-


mento de projetos e de seus conceitos. Foram abordagens gerais, consi-
derando os projetos nas mais variadas áreas de aplicação. Nesse item, o
propósito é focalizar os principais conceitos de gerenciamento de proje-
tos no processo de desenvolvimento integrado de produtos como um dos
projetos da organização.
Como visto anteriormente, em Romano (2003), o modelo do processo
de desenvolvimento de produto foi proposto para máquinas agrícolas e
sua generalização e descrição foram estabelecidas no Capítulo 2, conforme
a Figura 2.14.
Como descrito no item 2.4, na fase de planejamento são conduzidas
atividades para planejar o desenvolvimento do produto, visando sua exe-
cução e controle. Nessa fase, devem ser considerados aspectos relativos
ao planejamento estratégico da organização e ao planejamento de porta-
fólio de produtos. O resultado dessa fase é o plano de projeto constituído
na forma de formalização do projeto, definição do gerente e da equipe de
projeto, escopo do projeto, orçamento geral e cronograma de execução, e
demais planos associados, como os de marketing, comunicações, riscos,
aquisições e qualidade.
Na fase de elaboração do projeto do produto, incluem-se as fases pró-
prias da execução do projeto para tornar concretas as demandas dos usuá-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 107 — #135


i i

Gerenciamento do desenvolvimento integrado de produtos 107

rios, na forma do produto avaliado técnica e economicamente. São con-


sideradas as fases próprias do processo de projeto do produto, dividido
em projeto informacional, conceitual, preliminar e detalhado, conforme
o modelo apresentado na Figura 2.14. Nessas fases, as necessidades e os
requisitos de projeto do produto são transformados e formalizados em do-
cumentos técnicos que representam as soluções geradas para o produto e
possibilitam sua realização física.
À elaboração do projeto, seguem as fases de produção do lote piloto,
lançamento do produto e validação do projeto como um todo. Dessas, a
primeira é responsável pelo planejamento e pela implementação do pro-
cesso de produção, e a segunda, responsável pelo desenvolvimento do
lote inicial de produtos e sua introdução no mercado. Por fim, quando
o produto se encontra em processo de comercialização e utilização, essa é
considerada uma fase de validação do projeto, na qual o produto é moni-
torado e avaliado junto aos consumidores. Também são levados em consi-
deração, nessa fase de validação, o término e a validação do próprio pro-
jeto, enquanto negócio da organização, onde os contratos são encerrados, a
equipe é desmobilizada e avaliam-se os trabalhos executados, verificando-
se o grau de sucesso do empreendimento.
Nota-se, na descrição anterior do processo de desenvolvimento de pro-
dutos, que serão muitas as atividades e tarefas envolvidas em cada fase do
desenvolvimento, e sua execução e controle envolvem a consideração e a
integração de uma série de elementos, que são próprios do ambiente de
projeto. Esses elementos, numa categorização preliminar, são:

• usuários (stakeholders): como já mencionado, são todos aqueles en-


volvidos com o projeto e com o produto que está sendo desenvol-
vido, cuja influência pode ser positiva ou negativa; seus interesses,
do ponto de vista do gerenciamento de projetos, estão associados às
variáveis de escopo, tempo, custo e qualidade;
• condições internas: estratégias, metas, conhecimentos, tecnologias,
infra-estrutura e recursos;
• condições externas: comportamento do mercado e dos concorrentes.

Analisando os elementos listados, verifica-se a abrangência do pro-


cesso de desenvolvimento de produtos e a necessidade de integração en-
tre os vários componentes envolvidos. Sendo assim, para que qualquer

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 108 — #136


i i

108 Projeto Integrado de Produtos: planejamento, concepção e modelagem

empreendimento nesse ambiente tenha sucesso, faz-se necessária alguma


forma de disciplina para planejar atividades, reunir as condições necessá-
rias para iniciar e finalizar essas atividades e avaliar seu progresso. Essas
funções são, em grande parte, próprias do gerenciamento de projetos e,
várias outras, próprias do modelo adotado para o processo de projeto e de
metodologias empregadas.
Assim, o gerenciamento do desenvolvimento de produtos consiste na
aplicação, num ambiente de projetos, de todos os elementos do gerencia-
mento de projetos (princípios, conhecimentos, processos, métodos e ferra-
mentas), para desenvolver ações visando obter o sucesso do produto e de
seu desenvolvimento desde o planejamento até a validação. O gerencia-
mento do desenvolvimento de produtos diferencia-se do gerenciamento
de outros tipos de projetos principalmente pela natureza das atividades
– sendo muitas delas próprias do processo de projeto de produtos e da
metodologia de projeto empregada – e pelos conhecimentos e tecnologias
envolvidas com o produto e com os processos de produção. Entretanto, as
variáveis, como o escopo, tempo, custo e qualidade, devem ser atendidas,
assim como em qualquer outro tipo de projeto.

3.4 Estrutura organizacional para o projeto de


desenvolvimento de produtos

A execução de dado plano de projeto de desenvolvimento de produto,


desenvolvido sob os princípios do gerenciamento de projetos, necessita
de uma forma de organização. A organização estabelece, em linhas gerais,
segundo Merwe (2002), as relações de autoridade na cadeia de comando
da organização, os canais formais de comunicação, os grupos formais de
trabalho e as linhas formais de responsabilidades. Esses elementos são es-
senciais para o sucesso do projeto porque, por meio de sua configuração,
ter-se-á maior ou menor facilidade de execução das atividades planejadas
para o desenvolvimento do produto.
Qualquer tipo de organização formal possui certas características ge-
rais, umas mais ou menos pronunciadas em relação às demais, depen-
dendo da configuração adotada. Em linhas gerais, segundo Chiavenato
(1983), as características das organizações formais são: divisão do trabalho,
especialização, hierarquia, autoridade, responsabilidade e racionalismo.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 109 — #137


i i

Gerenciamento do desenvolvimento integrado de produtos 109

Sob tais características, os principais tipos de organização são: linear, fun-


cional, linha-staff e comissões.
A organização linear é aquela na qual existem linhas diretas e únicas
de autoridade e de responsabilidade e em que as linhas de comunicação
são rigidamente estabelecidas. Nessa organização, cada indivíduo se re-
porta única e exclusivamente ao seu superior e tem apenas um chefe.
A organização funcional aplica o princípio da especialização das fun-
ções para cada tarefa. Surgiu da necessidade de contar com órgãos alta-
mente especializados em seu campo de atuação, capazes de proporcionar
inovações rápidas e substanciais. As decisões são delegadas aos órgãos ou
cargos especializados, ou seja, a especialidade move as decisões. As res-
ponsabilidades são limitadas de acordo com as especializações.
Na organização linha-staff tem-se uma combinação das organizações
linear e funcional, procurando-se incrementar as vantagens e reduzir as
desvantagens de cada uma delas. Segundo Chiavenato (1983), é o tipo de
organização que tem sido mais empregado nas organizações. O staff, ou
assessoria, tem a função de auxiliar os trabalhos administrativos, visando
fornecer informações necessárias às decisões, bem como prestar assessoria
no planejamento. A distinção entre órgãos de linha e de staff depende dos
objetivos principais da organização. Por exemplo, se estes forem de pro-
dução, então somente a produção será considerada de linha e os demais
órgãos serão de staff. Em outras palavras, os órgãos de staff representam
atividades-meio e podem ser configurados em qualquer nível da organi-
zação.
A organização na forma de comissões, como define Chiavenato (1983),
apresenta uma série de controvérsias quanto a sua definição. Alguns as
consideram como grupos com funções específicas (administrativas, técni-
cas etc.), outros, como um tipo distinto de assessoria. O papel da equipe de
trabalho depende muito de sua autoridade, a qual, em geral, não é de li-
nha, mas de conhecimento. Suas principais características são: não se cons-
tituem num órgão da estrutura organizacional e seus objetivos consideram
vários órgãos da estrutura; é geralmente criada para estudar problemas
que ultrapassam os limites ou competências de um dado órgão; as equi-
pes têm participantes que pertencem aos vários órgãos da organização,
os quais são cedidos provisoriamente; a equipe funciona por um determi-
nado tempo e sua constituição é provisória e instável. As equipes podem
ser formais (autoridade delegada), informais (sem delegação de autori-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 110 — #138


i i

110 Projeto Integrado de Produtos: planejamento, concepção e modelagem

dade), temporárias (duração relativamente curta) e relativamente perma-


nentes (duração prolongada no tempo para estudar certos problemas).
As estruturas caracterizadas por Chiavenato (1983) são similares, em
parte, àquelas que têm sido apresentadas e definidas na literatura de ge-
renciamento de projetos. Nesse caso em particular, têm-se as estruturas do
tipo funcional, matricial ou por projetos. Observa-se, conforme será visto
mais adiante, que as estruturas matriciais reúnem características das estru-
turas em linha, funcionais e linha-staff, tendendo mais para esta última. Já
as estruturas por projetos derivam dos conceitos de estrutura por equipes
ou comissões. No caso das estruturas matriciais, dependendo de seu tipo,
tem-se influência simultânea dos conceitos de linha-staff e de comissões.
De acordo com o PMI (2000), tomando-se como base a autoridade do
gerente de projeto, têm-se as seguintes estruturas organizacionais de pro-
jeto (Figura 3.2): funcional, matricial e por projeto. A estrutura matricial,
por sua vez, divide-se em matricial fraca, equilibrada e forte.
De acordo com a Figura 3.2, na organização funcional configura-se uma
hierarquia bem definida e as funções (departamentos) são organizadas
por especialidades, tais como marketing, engenharia, produção etc. Nesse
caso, as atividades são executadas por funções, ou seja, cada departamento
executa sua parte independentemente dos demais. Quando os problemas
são multidisciplinares, deve-se seguir, em cada fase da execução do pro-
jeto, os canais formais da organização para resolvê-los. Isso torna o pro-
cesso seqüencial, promovendo comprometimento do cronograma, tendo
em vista a burocracia estabelecida nas comunicações e decisões. Nessa es-
trutura não existe um “dono” do projeto, o qual é fragmentado em tarefas
pelos vários departamentos, dificultando a avaliação de desempenho. As
vantagens e desvantagens dessa estrutura, quando comparada às demais,
estão expressas na Tabela 3.2.
A organização por projeto como um todo, ou um segmento seu, é defi-
nida de acordo com um programa de projetos que será desenvolvido num
dado período, alocando para isso todo seu recurso humano e sua infra-
estrutura disponível. Nesse tipo de estrutura organizacional, existe uma
pessoa nomeada pela alta gerência da empresa que é a responsável direta
por conduzir o trabalho da equipe e gerenciar os recursos, possuindo inde-
pendência e autoridade. Suas vantagens e desvantagens estão mostradas
na Tabela 3.3.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 111 — #139


i i

Gerenciamento do desenvolvimento integrado de produtos 111

Figura 3.2 Estruturas organizacionais segundo PMI (2000)

Na organização matricial, existem configurações alternativas em decor-


rência da autoridade do gerente de projeto em relação aos gerentes funcio-
nais. Os tipos principais são: matricial fraca, equilibrada e forte. Na organiza-
ção matricial fraca, o papel do gerente é de coordenar ou facilitar o projeto;
esta organização está mais próxima da funcional.
Na organização matricial forte, o gerente de projeto, em tempo integral,
tem autoridade suficiente para a alocação de recursos e possui pessoal ad-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 112 — #140


i i

112 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 3.2 Vantagens e desvantagens da organização funcional (adaptado de


Pinto, 1998 e Kerzner, 2001)

Vantagens Desvantagens

• Facilita o controle do custo de • Nenhum indivíduo é diretamente


cada atividade e a elaboração de responsável pelo projeto,
orçamentos, uma vez que se sabe comprometendo a coordenação
especificamente quem irá fazer o do projeto e a manutenção de
quê; prazos; tampouco existe um
• melhora o controle técnico do comprometimento em particular
projeto, devido ao fato de os com algum projeto em especial;
especialistas da empresa • a motivação e a inovação no
compartilharem conhecimentos e projeto são bem menores;
responsabilidades; • as decisões geralmente favorecem
• aumenta a flexibilidade no uso da o grupo funcional mais forte;
mão-de-obra, pois os mesmos • o foco do trabalho não é voltado
especialistas são designados para ao consumidor, comprometendo
diferentes projetos, promovendo dessa maneira as respostas às suas
uma larga base de mão-de-obra; necessidades e expectativas;
• permite maior controle sobre os • as idéias e soluções são orientadas
recursos humanos; estabelece funcionalmente, havendo pouca
canais de comunicação verticais preocupação global com o
bem definidos; produto que está sendo
• aumenta a capacidade de desenvolvido.
resposta da empresa; depende da
priorização das atividades.

ministrativo trabalhando também em tempo integral no projeto. Essa es-


trutura está bastante próxima da organização por projeto. Na matricial equi-
librada, como o próprio nome sugere, há eqüidade na discussão sobre o
projeto e na alocação de recursos, considerando o gerente do projeto e os
gerentes funcionais. Levando-se em conta as variações da estrutura matri-
cial, suas vantagens e desvantagens estão definidas na Tabela 3.4.
A maioria das pesquisas tem apontado a organização matricial balan-
ceada ou equilibrada como a forma mais efetiva para se obter os resultados
esperados em uma organização que trabalha com ambientes de projetos.
Entretanto, a escolha de um ou outro tipo de estrutura depende muito da
natureza dos problemas de projeto. Por exemplo, projetos em que a natu-
reza tecnológica do produto é simples e não muda com muita freqüência
e em que a natureza do problema não difere muito de projetos anterio-
res, esses projetos podem, em linhas gerais, ser melhor executados em

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 113 — #141


i i

Gerenciamento do desenvolvimento integrado de produtos 113

Tabela 3.3 Vantagens e desvantagens da organização por projeto (adaptado


de Pinto, 1998 e Kerzner, 2001)

Vantagens Desvantagens

• Promove uma completa • Aumenta os custos devido à


autoridade sobre o projeto e duplicação de esforços, estrutura e
conseqüentemente uma maior pessoal;
fidelidade e elevação moral da • apresenta tendência em se manter
equipe que o desenvolve; a equipe no projeto além do
• possibilita que produtos não tempo necessário, o que pode
lucrativos sejam facilmente acarretar falta de continuidade nas
identificados e eliminados do carreiras e perda de oportunidades
programa da empresa, devido ao de aperfeiçoamento para o
fato de a autoridade do projeto se pessoal do projeto;
concentrar na equipe que o • compromete a tecnologia devido
desenvolve; à falta de grupos funcionais fortes e
• apresenta fortes canais de intercâmbio técnico entre os
comunicação, desenvolvendo um projetos.
foco para as relações com os
consumidores;
• possibilita a manutenção da
especialidade técnica em um
determinado projeto sem
compartilhar pessoal-chave;
• permite reações rápidas às
mudanças de mercado;
• promove uma maior flexibilidade
na determinação de tempos,
cronogramas, custos e no
balanceamento dos objetivos de
desempenho do produto;
• facilita o gerenciamento de
interfaces devido à redução de
unidades envolvidas.

uma estrutura em que se tem claramente definidas as responsabilidades


e especialidades de cada indivíduo ou departamento da organização, ou
seja, em uma estrutura funcional. Por outro lado, para projetos nos quais
a natureza do produto ou do problema é complexa e apresenta muitas
novidades, em que a tecnologia avança ou muda com muita freqüência e
exige flexibilidade na execução, é mais indicada uma organização em que
as equipes tenham autoridade, autonomia e poder de decisão, tornando o
processo mais ágil, ou seja, uma estrutura matricial ou por projeto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 114 — #142


i i

114 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 3.4 Vantagens e desvantagens da organização matricial (adaptado de


Pinto, 1998 e Kerzner, 2001)

Vantagens Desvantagens

• Estabelece canais laterais de • Quebra o paradigma existente


comunicação que aumentam sua quanto ao fluxo tradicional de
freqüência entre as diferentes autoridade, gerando nos gerentes
áreas funcionais, bem como funcionais um sentimento de perda
mantêm a quantidade e de controle, insegurança e erosão
qualidade das informações que de autoridade;
fluem verticalmente; • conduz a ambigüidades no
• aumenta a flexibilidade no uso de controle de recursos,
especialistas e recursos capitais, responsabilidades para assuntos
minimizando o custo; técnicos e gerenciamento dos
• permite o compartilhamento de recursos humanos, aumentando os
autoridade e responsabilidade custos indiretos e com pessoal na
para com o projeto, fortalecendo a empresa;
motivação individual, a satisfação • cria conflitos organizacionais entre
com o trabalho, o compromisso e o gerentes funcionais e de projetos e
desenvolvimento pessoal; conflitos pessoais entre indivíduos
• facilita o alcance da excelência que devem trabalhar juntos, mas
técnica; possuem diferentes perspectivas,
• possibilita a definição de políticas e horizontes e objetivos, quanto ao
de procedimentos independentes trabalho.
para cada projeto;
• maximiza a capacidade de
atender a conflitos e necessidades
de projeto;
• utiliza a estrutura funcional como
um suporte ao projeto;
• permite que cada pessoa continue
se desenvolvendo individualmente
após o encerramento do projeto.

Uma pesquisa realizada por Larson e Gobeli (1988) avaliou a eficácia


de cinco diferentes estruturas de gerenciamento de projetos, comparando
o desempenho de 540 projetos em termos de custo, cronograma e desem-
penho técnico, bem como desempenho geral dos projetos. Os dados foram
coletados por meio de questionários, respondidos por profissionais de vá-
rios níveis hierárquicos (gerentes de projeto, gerentes funcionais, presi-
dentes, vice-presidente e gerentes de divisões) de empresas de diversos
setores, incluindo farmacêutico, aeroespacial, de informática, de telecomu-
nicações, de instrumentação, petroquímico, entre outros. As estruturas de

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 115 — #143


i i

Gerenciamento do desenvolvimento integrado de produtos 115

gerenciamento de projetos foram classificadas e caracterizadas pelos auto-


res, conforme a Tabela 3.5, mostrando também os principais resultados da
pesquisa.
De acordo com a Tabela 3.5, as estruturas que apresentaram os melho-
res resultados, com pequenas diferenças entre si, foram as matrizes balan-
ceada, de projeto e de equipe de projeto, quando comparadas à estrutura
funcional, e a matriz funcional. Os autores salientam, entretanto, que deve
haver um estudo rigoroso para determinar a melhor estrutura diante da
natureza do projeto e das condições que se apresentam para a organização
em um dado momento.

3.5 Equipes de desenvolvimento de produtos

Em relação à forma de organização para o desenvolvimento do projeto,


principalmente quando se considera a estrutura matricial, faz-se necessá-
rio identificar os participantes do projeto e estruturar a equipe de projeto.
Os participantes primários do projeto estão apontados conforme a Tabela
3.6, segundo Verzuh (2000).
A identificação adequada dos elementos participantes de um projeto
ou de seus representantes, como uma das primeiras tarefas do gerente de
projeto, é bastante importante, uma vez que serão necessárias várias de-
cisões ao longo do planejamento e da execução do projeto, que poderão
afetar, positiva ou negativamente, os envolvidos com o processo e/ou re-
sultados do projeto.
Na definição do PMI (2000), os usuários ou interessados no projeto são
os indivíduos e as organizações ativamente envolvidas no projeto ou cujos
interesses possam ser positiva ou negativamente afetados pela execução
do projeto ou pela sua conclusão; eles também podem exercer influência
sobre o projeto e seus resultados.
A configuração da equipe de projeto deverá representar os usuários,
mesmo que nem todos os envolvidos estejam presentes. Essa representa-
ção não é necessariamente física ou presencial a todo o instante durante
o planejamento e a execução do projeto, mas está na forma de expressão
de seus desejos e necessidades, de conhecimentos especializados neces-
sários ao projeto, nos momentos de decisão (aprovações de passagem de
fase, por exemplo), entre outros. A definição dos membros da equipe tam-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 116 — #144


i i

116 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 3.5 Estruturas de projeto e principais resultados de pesquisa (adaptado


de Larson e Gobeli, 1988)
Resultados
(% de sucesso)*

Desempenho
Desempenho
Cronograma
Número de

Orçamento
Estrutura Características

estruturas

técnico

geral
O projeto é dividido em segmentos e
designado para uma área funcional ou
Funcional grupo dentro de uma área funcional; o 72 25 25 50 30
projeto é coordenado por um gerente
funcional.
Um gerente de projeto com autoridade
limitada é designado para coordenar o
projeto através das diferentes áreas fun-
Matriz
cionais e/ou grupos; os gerentes funcio- 140 36 25 50 40
funcional
nais retêm a responsabilidade e autori-
dade de seus segmentos com relação
ao projeto.
Um gerente de projeto é designado
para coordenar o projeto e comparti-
lhar a responsabilidade e a autoridade
Matriz ba-
para sua conclusão com os gerentes
lanceada 87 42 50 70 60
funcionais; os gerentes do projeto e os
funcionais em conjunto dirigem grande
parte do fluxo de trabalho e, em con-
junto, aprovam muitas decisões.
Um gerente de projeto é designado
para coordenar o projeto e tem respon-
Matriz de sabilidade primária por sua conclusão;
154 50 46 70 60
projeto os gerentes funcionais designam pes-
soal quando necessário e promovem
experiência técnica para o projeto.
Um gerente de projeto é designado
para a coordenação de uma equipe
de projeto, composta por um núcleo de
Equipe de
várias áreas funcionais, que são desig- 87 50 47 70 60
projeto
nados em tempo integral; os gerentes
funcionais não têm envolvimento formal
no projeto.
* valores aproximados (somas de porcentuais maiores que 100% significam mais
de uma resposta)

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 117 — #145


i i

Gerenciamento do desenvolvimento integrado de produtos 117

Tabela 3.6 Participantes típicos de um projeto (adaptado de Verzuh, 2000)

Participantes Participação
Define, planeja, controla e lidera o projeto; deve reunir condi-
Gerente de
ções para a satisfação das necessidades de todos os partici-
projeto
pantes, inclusive as suas.
São os indivíduos que contribuem com seu tempo, habilida-
Equipe de
des e empenho para executar as tarefas do projeto, incluindo
projeto
os próprios clientes do projeto.
Possui autoridade formal e provê apoio à gerência do projeto
para vencer as barreiras organizacionais e ajudar a equipe
Facilitador
de projeto a ter êxito. Possui a responsabilidade final sobre o
sucesso do projeto.
Estabelecem as exigências do produto e provêm os fundos
Usuários
para a execução do projeto.
É responsável pela unidade da organização e controla, em
Gerente de
seu respectivo departamento, os empregados e recursos e
função
está envolvido na definição das políticas da organização.

bém está diretamente associada à natureza do projeto e de suas tarefas e


deve ser estabelecida na fase de planejamento do projeto com o apoio, por
exemplo, de ferramentas como a Estrutura de Desdobramento do Traba-
lho (EDT) e a matriz de responsabilidades.
Em projetos de desenvolvimento de produtos, considerando o mo-
delo apresentado na Figura 2.14 do Capítulo 2, a equipe de projeto po-
derá ser configurada tendo em vista os domínios de conhecimento envol-
vidos no desenvolvimento estabelecidos como: gestão empresarial, geren-
ciamento de projeto, marketing, projeto do produto, projeto da manufa-
tura, suprimento, qualidade, segurança, dependabilidade, administrativo-
financeiro, produção e pós-venda.
As equipes de projeto mudam ao longo do projeto, conforme a natu-
reza dos trabalhos em cada uma de suas fases, mas recomenda-se que um
núcleo de indivíduos deve ser mantido até o final. Em geral, esse núcleo é
formado pela gerência, pelo pessoal administrativo do gerenciamento (de-
pendendo do porte do projeto) e pelo pessoal especializado em áreas es-
tratégicas do domínio do projeto (marketing, engenharia, produção etc.).
Em particular, o gerente de projeto deve apresentar uma série de co-
nhecimentos e habilidades para conduzir adequadamente seu trabalho
durante planejamento, execução e controle do projeto. São várias as lis-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 118 — #146


i i

118 Projeto Integrado de Produtos: planejamento, concepção e modelagem

tas de atribuições, conhecimentos, habilidades e outras características que


o gerente de projetos deve possuir, como aquelas encontradas em Kerzner
(2001), Meredith (2000), Pinto (1998) e Valeriano (1998). Na Tabela 3.7 são
apresentadas algumas das principais atuações do gerente de projeto, tendo
em vista os processos de gerenciamento de projeto mais importantes.
A equipe de projeto constituída por elementos, seja em tempo integral
ou parcial, é responsável pela execução do projeto, devendo estar devida-
mente organizada e posicionada com relação aos trabalhos do projeto. Em
outras palavras, devem estar devidamente estabelecidos os papéis de cada
integrante da equipe, em uma matriz de responsabilidades, por exemplo.
Na formação da equipe, além das questões de conhecimentos e habilida-
des para a execução dos trabalhos, deve-se levar em conta questões de
relacionamento e conflitos potenciais, sabendo que muitos membros da
equipe podem estar trabalhando juntos pela primeira vez.

3.6 Planejamento de projetos de


desenvolvimento de produtos

O planejamento de projetos de desenvolvimento de produtos já co-


meça, em essência, no planejamento estratégico e do porta-fólio de produ-
tos da organização e segue com o planejamento de escopo, tempo, custos,
qualidade, comunicações, entre outros elementos importantes para o ge-
renciamento adequado do projeto. Nesse item serão mostradas, em maio-
res detalhes, as atividades de planejamento de projetos, considerando as
variáveis de escopo, tempo e custo. Ao final, serão feitas considerações
gerais sobre os demais aspectos do processo.
O processo de planejamento de projetos é considerado o núcleo dos
processos de gerenciamento. Pode-se observar uma relação entre os pro-
cessos de gerenciamento e as áreas envolvidas, na Figura 3.3 (PMI, 2000),
indicando a importância e a abrangência do planejamento de projetos.
Por meio das atividades de planejamento, são estabelecidos os traba-
lhos necessários, suas relações, custos, restrições, entre outras informa-
ções, que irão orientar e conduzir as ações e decisões gerenciais ao longo
da execução do projeto e formarão base para as medições e ações correti-
vas que se fizerem necessárias aos rumos do projeto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 119 — #147


i i

Gerenciamento do desenvolvimento integrado de produtos 119

Tabela 3.7 Atuações do gerente de projeto em função dos processos de


gerenciamento
Processo Atuação
• Demonstrar a viabilidade e necessidade do projeto
Inicializa-
• Obter a autorização para o projeto
ção
• Obter a autorização para a fase do projeto (primeiras ações)
• Descrever o escopo do projeto. Declaração de escopo, plano de
gerenciamento de escopo e estrutura de desdobramento do
trabalho (EDT)
• Definir e seqüenciar as atividades de projeto
• Estimar a duração das atividades e os recursos necessários
• Desenvolver o cronograma de atividades (Gantt)
• Estimar custos
• Desenvolver o orçamento e a programação de desembolso
• Criar um plano formal de qualidade
• Criar um plano formal de comunicações
Planeja-
• Criar e organizar a coordenação do projeto (staff ) com a
mento
respectiva atribuição de responsabilidades (matriz de
responsabilidades)
• Identificar riscos e planejar como responder-lhes
• Planejar a aquisição de recursos
• Organizar o plano de projeto evidenciando todos os produtos
(deliverables) com as tarefas em nível macro que precedem
cada um
• Obter uma aprovação formal do patrocinador para o plano de
projeto
• Retornar ao plano de projeto e replanejar sempre que necessário
• Identificar eventuais requisições de mudanças
• Criar relatório periódico de progresso (PPP – Progresso, Próximos
Execu- passos e Pontos de atenção)
ção • Acompanhar o desempenho da equipe, assessorando, dirigindo
e aprimorando, se necessário
• Gerenciar contratos com o fim de obter os resultados desejados
• Providenciar a aceitação formal dos produtos (deliverables)
• Tomar ações corretivas de retrabalho de produtos e de processos
de trabalho
• Manter plano de projeto e escopo atualizados
Controle
• Coletar as lições aprendidas
• Aprimorar a qualidade
• Conferir e avaliar periodicamente os itens de conferência (lista de
verificação)
• Providenciar o aceite formal por escrito da conclusão do projeto
tanto do patrocinador quanto do contratante
Encerra-
• Preparar os registros de projeto para arquivo
mento
• Montar um plano de acompanhamento e/ou entrega do
resultado do trabalho

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 120 — #148


i i

120 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 3.3 Relações entre processos e áreas do gerenciamento de projetos

Alguns autores procuram sistematizar o processo de planejamento,


tais como Lewis (2000), Vargas (2000) e PMI (2000), entre outros, mos-
trando o que deve ser feito para um gerenciamento adequado e quais fer-
ramentas podem ser empregadas nesse processo. A Figura 3.4, por exem-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 121 — #149


i i

Gerenciamento do desenvolvimento integrado de produtos 121

plo, mostra o modelo de gerenciamento apresentado por Lewis (2000), no


qual o processo de planejamento se encontra estabelecido após a fase de
planejamento estratégico da organização.

Figura 3.4 Modelo de gerenciamento de projetos (Lewis, 2000)

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 122 — #150


i i

122 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Na proposição do PMI (2000), o desenvolvimento do processo de pla-


nejamento de projetos é recomendado segundo um fluxograma (Figura
3.5) que recebe informações desenvolvidas na fase de iniciação e controle
(quando o projeto se encontra em execução e seu plano é realimentado), e
se inicia pelo planejamento e pela definição do escopo do projeto, ou seja,
pelo estabelecimento do conjunto de trabalhos que precisará ser desenvol-
vido para atender aos objetivos do projeto. Dá-se seqüência com a elabora-
ção do cronograma e do orçamento do projeto para os quais se faz neces-
sário definir e estimar os tempos das atividades de projeto e dos recursos
necessários para sua execução. O plano de projeto é concluído reunindo-
se a documentação elaborada nas atividades executadas, incluindo-se aí,
como será abordado, o planejamento dos riscos do projeto.

Figura 3.5 Processos essenciais de planejamento de projetos (adaptado de


PMI, 2000)

3.7 Escopo do projeto

Os projetos acontecem nas organizações sob várias condições. Nor-


malmente existem múltiplos projetos acontecendo em um dado momento,
oriundos de diversas áreas (marketing, engenharia, manufatura etc.).
Além de estar desenvolvendo o produto A, B ou C, a organização pode

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 123 — #151


i i

Gerenciamento do desenvolvimento integrado de produtos 123

estar implementando um novo sistema de informação, alterando o leiaute


da fábrica, desenvolvendo uma campanha publicitária para o lançamento
de novos produtos ou promovendo o treinamento de seus colaboradores.
Os projetos são definidos, em linhas gerais, tendo em vista o planeja-
mento estratégico da organização, que inclui as metas para determinados
períodos de tempo. Quando existem projetos alternativos para atender a
determinada meta, procede-se na seleção das propostas mais promissoras
para o crescimento da organização. Surgem então os projetos aprovados
para determinado período e sob determinado orçamento, os quais preci-
sam ser formalizados, designando-se uma gerência e, a partir daí, iniciado
o processo de desenvolvimento. A Figura 3.6 mostra conceitualmente as
relações entre os projetos e os principais elementos do planejamento estra-
tégico de uma organização.

Figura 3.6 Relações entre os projetos e principais elementos do planejamento


estratégico

De acordo com a Figura 3.6, tendo sido estabelecidos os projetos al-


ternativos associados a determinada estratégia e meta da organização,
deve-se selecionar aquele mais promissor, com base em critérios adequa-
dos, estabelecendo o produto principal para o projeto escolhido, ou seja, a
principal entrega do projeto, quem será o responsável (o gerente do pro-
jeto), quanto será disponibilizado do orçamento geral da empresa para
aquele projeto, quando e como o mesmo deverá ser executado e quem irá
executá-lo (equipe de projeto). Essas definições são gerais e estabelecem
inicialmente as principais diretrizes para o gerenciamento do projeto e,
em particular, para seu planejamento. Deve-se, a partir daí, formalizar o
projeto na organização e iniciar seu planejamento. Um dos processos ini-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 124 — #152


i i

124 Projeto Integrado de Produtos: planejamento, concepção e modelagem

ciais, nesse sentido, consiste no planejamento do escopo do projeto, onde


se busca definir quais serão os trabalhos e suas dimensões dentro das res-
trições de tempo, orçamento e exigências do produto e dos clientes.
O termo escopo, no contexto do projeto, segundo PMI (2000), pode
referir-se ao:

• escopo do produto: as características e funções que especificam o


produto ou serviço;
• escopo do projeto: o trabalho que deve ser realizado para gerar o
produto com as características e funções especificadas.

De acordo com Valeriano (1998), o escopo do projeto constitui uma


“descrição documentada de um projeto quanto aos seus potenciais resul-
tados, sua abordagem e conteúdo”, ou seja, ele é um resumo das partes
capitais do projeto e de suas esperadas conseqüências, de forma a permi-
tir uma compreensão do que se pretende fazer e com que finalidade. O
escopo deve conter as seguintes partes:

• os resultados do projeto: o que será criado, em termos de forma e


tamanho, geografia, quantidade, especificações de desempenho téc-
nico e operacional, características de custos, utilidade, e assim por
diante;
• a metodologia a ser empregada: as tecnologias (novas ou existentes),
os insumos internos e externos, a descrição das interfaces ou limites
entre o projeto e seu ambiente;
• o conteúdo do projeto: o que será incluído e excluído do trabalho a
ser executado e a descrição das interfaces ou limites entre as tarefas
do projeto e destas com outras relacionadas aos resultados do projeto
ou com seu ambiente.

De acordo com Vargas (2000), o escopo é dividido em três partes: o es-


copo funcional, consiste no conjunto de características funcionais do pro-
duto a ser desenvolvido no projeto; o escopo técnico são as características
técnicas do produto, destacando os padrões e as especificações a serem
utilizados; e o escopo de atividades, que é o trabalho a ser realizado para
prover os escopos técnico e funcional do produto. Nota-se que os escopos
funcional e técnico correspondem ao escopo do produto; e o escopo de
atividades, ao escopo do projeto, conforme definidos anteriormente.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 125 — #153


i i

Gerenciamento do desenvolvimento integrado de produtos 125

Com base no exposto verifica-se que os escopos, do projeto e do


produto, são inter-relacionados e estabelecem as dimensões do projeto
(ou suas limitações) para efeito de negociação, desdobramento dos de-
mais elementos do plano de projeto (cronograma, orçamento, riscos etc.)
e decisões futuras sobre potenciais mudanças no próprio escopo. A Fi-
gura 3.7 procura representar conceitualmente as características e o inter-
relacionamento entre o escopo do projeto e do produto, tomando-se por
base resultados e processos típicos da fase de elaboração do projeto do
produto.

Figura 3.7 Relações entre escopo do projeto e escopo do produto

De acordo com a Figura 3.7, determinado escopo do produto exige um


certo escopo do projeto, que, em conjunto, estabelecem as bases para o
contrato a ser estabelecido e para futuras decisões na execução do mesmo.
Se o escopo do produto for ampliado, novos trabalhos serão necessários e,
conseqüentemente, considerar-se-á um novo escopo do projeto e do pro-
duto, o que pode resultar em um novo contrato para o projeto, e assim por
diante.
A avaliação do escopo do produto é realizada com base nos resultados
alcançados e a avaliação do escopo do projeto, com base no acompanha-
mento do plano de projeto. A importância em suas definições e planeja-
mento encontra-se no estabelecimento de compromissos das partes envol-
vidas (ver princípio do comprometimento, Tabela 3.1) e na constituição de
uma base para futuras decisões de projeto.
Quando se inicia um projeto, muitas vezes não se encontram esclare-
cidos em detalhes os resultados em termos de produto ou entrega final,
tampouco em termos de trabalho necessário para obtê-lo. Os clientes po-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 126 — #154


i i

126 Projeto Integrado de Produtos: planejamento, concepção e modelagem

dem estar esperando determinado resultado, diferente daquele que está


sendo pensado pela organização que irá executar o trabalho. Essas expec-
tativas, se não forem bem exploradas e discutidas nas fases iniciais de pla-
nejamento e definição do escopo, resultarão em prováveis mudanças de
escopo ao longo do projeto ou dificuldades para aceitação dos resultados
no final do projeto. Como conseqüência, haverá clientes insatisfeitos e pos-
sibilidade de conflitos internos na organização traduzindo-se em fracasso
do projeto.

3.7.1 Processos de gerenciamento do escopo do projeto

O gerenciamento do escopo do projeto é constituído por cinco pro-


cessos, de acordo com o PMI (2000): iniciação, planejamento, definição,
verificação e controle de alterações do escopo.
A iniciação consiste na autorização formal de um novo projeto ou de
uma nova fase. No caso de um novo projeto, a iniciação é conduzida com
base em informações do planejamento estratégico da organização, infor-
mações históricas sobre produtos similares, entre outras, resultando em
um plano resumido do projeto (necessidade comercial do projeto e descri-
ção do produto), gerente designado, restrições e premissas. Nota-se que
parte das atividades e resultados do processo de iniciação integra os tra-
balhos que ocorrem no planejamento estratégico da organização. No caso
de autorização de uma nova fase do projeto, o processo de iniciação segue
as mesmas diretrizes, considerando em detalhes os resultados das fases
anteriores.
O planejamento do escopo consiste no processo em que se elabora e
documenta o trabalho do projeto (escopo do projeto) necessário para gerar
o produto do projeto (escopo do produto). Esse processo começa com as
informações resultantes do processo de iniciação e por meio de ferramen-
tas de análise do produto e da relação custo-benefício, e de identificação
de alternativas e opinião de especialistas. Nesse processo buscam-se os
seguintes resultados: declaração do escopo do projeto, detalhes auxiliares
e plano de gerenciamento do escopo. Na análise do produto são empre-
gadas técnicas como engenharia de sistemas, decomposição do produto,
engenharia de valor, análise da função e desdobramento da função quali-
dade, com o propósito de obter uma melhor compreensão do produto a ser
desenvolvido. Na análise da relação custo-benefício, busca-se uma estima-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 127 — #155


i i

Gerenciamento do desenvolvimento integrado de produtos 127

tiva dos custos tangíveis e não tangíveis (gastos), bem como dos benefícios
(retorno) das alternativas de produto e projeto, empregando-se indicativos
financeiros como retorno do investimento (payback). A identificação de al-
ternativas consiste no uso de técnicas de criatividade, como brainstorming,
analogias, entre outras discutidas no Capítulo 6, visando desenvolver al-
ternativas viáveis de idéias para o projeto. Nota-se que, nesse momento, as
alternativas para o projeto são desenvolvidas a partir de uma visão abran-
gente, estabelecendo um conceito geral para o produto, diferentemente
das soluções desenvolvidas na fase de projeto conceitual, em que são pes-
quisados e propostos princípios de solução, em detalhes, para cada uma
das funções técnicas do produto.
Dentre os resultados esperados desse planejamento, a declaração do
escopo consiste na documentação formal do projeto com itens como a jus-
tificativa do projeto, o produto do projeto, os principais resultados espe-
rados (subprodutos) e os objetivos do projeto, servindo de base para fu-
turas decisões durante sua execução. Associados a essa declaração podem
acompanhar dados auxiliares contendo restrições e premissas a respeito
do projeto, orientando a gerência no processo de planejamento, execução
e controle do projeto. Por último, o plano de gerenciamento do escopo es-
tabelece como este será gerenciado e como as possíveis alterações serão
tratadas e integradas ao longo do projeto.
A definição do escopo consiste em desdobrar o trabalho em compo-
nentes menores e mais facilmente gerenciáveis visando melhorar as esti-
mativas de custo, tempo e recursos para o projeto, definir uma base para
medição e controle do desempenho do projeto e facilitar a definição de
responsabilidades. A principal ferramenta empregada para auxiliar esse
processo é a EDT (Estrutura de Desdobramento do Trabalho), tratada em
maiores detalhes no item 3.7.2.
A verificação do escopo consiste em estabelecer a aceitação formal do
escopo do projeto pelos interessados. Deve ser verificado o atendimento
de todos os interesses no projeto. Com base em atividades de análise para
verificar o atendimento aos requisitos do projeto por meio do escopo esta-
belecido, busca-se, ao final da verificação, a aceitação formal do escopo.
Finalmente, o processo de controle de alterações do escopo visa,
quando necessário durante a execução do projeto, promover a concordân-
cia das partes sobre as mudanças no escopo, determinar que houve altera-
ções no escopo e gerenciar essas alterações. Esse processo deve estar inte-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 128 — #156


i i

128 Projeto Integrado de Produtos: planejamento, concepção e modelagem

grado aos demais processos de controle do projeto. Dele resultam modifi-


cações no escopo efetuadas mediante concordância de todos, o que requer
ajustes no cronograma, custos e qualidade do projeto. Também se inse-
rem nesses resultados as ações corretivas que se façam necessárias para
que o desempenho do projeto esteja de acordo com o planejado (ou re-
planejado). Deve-se, ainda, procurar estabelecer as causas das mudanças,
registrando-as como lições aprendidas para futuros projetos.

3.7.2 Estrutura de Desdobramento do Trabalho – EDT

A Estrutura de Desdobramento do Trabalho – EDT (WBS – Work Break-


down Structure) – constitui uma importante ferramenta para o processo de
definição do escopo do projeto. Por meio de seu uso, procura-se desdobrar
apropriadamente o projeto em pacotes de trabalho mais facilmente geren-
ciáveis e, assim, definir melhor o tempo das atividades, os recursos, as
responsabilidades, os riscos, entre outros elementos do plano de projeto.
Os pacotes de trabalho são conjuntos de atividades no mais baixo nível da
EDT; o resultado de sua realização será o produto ou determinada entrega
parcial do projeto. Em alguns tipos de software os pacotes de trabalho são
conhecidos como atividades-resumo. A elaboração de um relatório de en-
saio, a construção de um protótipo e a simulação de um componente são
típicos resultados parciais do processo de desenvolvimento de produtos,
para os quais podem ser definidos pacotes de trabalho.
A EDT também é conhecida como Estrutura Analítica do Projeto (EAP)
ou Plano Estruturado do Projeto (PEP). Sua definição, ou grau de desdo-
bramento, depende do porte do projeto. Projetos de maior porte exigirão
o desdobramento em mais níveis de estruturação, podendo-se empregar
as categorias, conforme Kerzner (2001), representadas na Tabela 3.8.
Em geral, os elementos da categoria gerencial, conforme a Tabela 3.8,
são aqueles definidos na ocasião da contratação do projeto (ou de sua
proposta). Os demais elementos, no nível técnico, são os estabelecidos in-
ternamente como base para o desenvolvimento do plano do projeto, in-
cluindo informações sobre o tempo, recursos, riscos, responsabilidades,
entre outros, após a aprovação da proposta do projeto.
O desdobramento do projeto pode dar-se sob diferentes abordagens e
representações. Quanto à representação, em geral, ela ocorre na forma de

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 129 — #157


i i

Gerenciamento do desenvolvimento integrado de produtos 129

Tabela 3.8 Níveis típicos do desdobramento do trabalho (Kerzner, 2001)

Categoria Nível Descrição


1 Programa
Gerencial 2 Projeto
3 Tarefa
4 Subtarefa
Técnico 5 Pacote de trabalho
6 Nível de esforço ou atividades

Figura 3.8 Exemplo parcial de estrutura de desdobramento do produto

árvores ou diagramas de blocos hierárquicos, conforme a Figura 3.8, mas


também podem ser empregadas tabelas.
O tipo de abordagem no desenvolvimento da EDT depende, em parte,
do tipo de projeto e pode ser funcional ou por produto. A abordagem
funcional é aquela em que o desdobramento do trabalho é realizado com
base nas atividades. Na abordagem por produto, também conhecida como
EDP (Estrutura de Desdobramento do Produto), o desdobramento se dá
identificando-se, em cada nível, os resultados físicos do projeto, como sis-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 130 — #158


i i

130 Projeto Integrado de Produtos: planejamento, concepção e modelagem

tema, subsistema, conjuntos e componentes a serem desenvolvidos. Nesse


caso, no último nível serão estabelecidas as atividades necessárias para a
realização do projeto, conforme é exemplificada na Figura 3.8.
De acordo com Verzuh (2000), a elaboração da EDT deve começar
listando-se os principais resultados ou tarefas de mais alto nível do pro-
jeto, que se encontram estabelecidos na declaração do escopo. Por exem-
plo, no caso do desenvolvimento de um produto, em sua fase de projeto,
poder-se-ia iniciar a elaboração da EDT, para um problema em particular,
conforme as abordagens mostradas na Figura 3.9.

Figura 3.9 Exemplos de abordagens na elaboração inicial da EDT

A próxima etapa na elaboração da EDT é desdobrar as tarefas ou ati-


vidades necessárias para alcançar os elementos de seus níveis superiores.
Nessa etapa, principalmente para projetos de grande porte e multidiscipli-
nares, recomenda-se consultar especialistas ou os responsáveis pela execu-
ção das tarefas para proceder no desdobramento. Isso propicia a obtenção
de estruturas de trabalho mais precisas, bem como estimula o comprome-
timento com os resultados do projeto. Com relação ao desdobramento das
tarefas, nos níveis inferiores da EDT, para o exemplo da Figura 3.9, poder-
se-ia ter o desdobramento, conforme mostrado na Figura 3.10.
No desenvolvimento de uma EDT deve-se procurar por conhecimen-
tos ou estruturas já realizadas em outros projetos da organização que pos-
sam ajudar neste processo. A metodologia empregada pela organização
para resolver determinado tipo de problema também deve ser uma fonte
inicial para definir os elementos da EDT. Esta última foi o caso empregado

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 131 — #159


i i

Gerenciamento do desenvolvimento integrado de produtos 131

Figura 3.10 Exemplos de desdobramentos adicionais na elaboração de uma


EDT

para os exemplos das Figuras 3.9 e 3.10, considerando-se as fases e ativi-


dades do processo de projeto, conforme modelo da Figura 2.14.
Uma das questões típicas no desenvolvimento de uma EDT é até onde
deve ser realizado o desdobramento do trabalho, ou seja, quantos ní-
veis devem ser desenvolvidos. Recomendações práticas nesse sentido, se-
gundo Verzuh (2000), são:

• regra 8/80: as tarefas não devem ter menos do que 8 horas de traba-
lho e mais do que 80, ou seja, a duração das tarefas deve ficar entre
1 e 10 dias;
• definir as tarefas levando em conta o período de avaliação: se este for
semanal, evitar que as tarefas tenham tempos maiores do que uma
semana para sua execução. Isso evita relatos de trabalho executado
como 25%, 40% ou 68%, por exemplo;
• a necessidade de desdobrar ou não uma dada tarefa também deve
ser pensada em função da maior ou menor facilidade nas estimativas
de tempo, custo e recursos, da clara definição do(s) responsável(is)
pela tarefa e pela maior ou menor facilidade de controle da tarefa
(resultados tangíveis).

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 132 — #160


i i

132 Projeto Integrado de Produtos: planejamento, concepção e modelagem

3.7.3 Considerações gerais sobre o gerenciamento


do escopo

Segundo Raz e Globerson (1998), entre os elementos essenciais na de-


finição do escopo do projeto encontram-se os pacotes de trabalho, que
consistem no trabalho requerido para completar um processo ou negó-
cio específico, tal como um relatório, uma concepção, um desenho, um
protótipo, entre outros. A determinação do tamanho e do conteúdo dos
pacotes de trabalho é de grande importância para um apropriado geren-
ciamento do projeto e, assim, os autores propõem uma lista de verificação
para avaliar se há necessidade de desdobramento adicional dos pacotes
de trabalho, conforme mostrado a seguir:

a. A precisão da estimativa dos custos e da duração das atividades


deve ser melhorada?
b. Existe mais do que um colaborador responsável por dado conteúdo
de trabalho?
c. O conteúdo de trabalho inclui mais do que uma atividade?
d. É necessário conhecer precisamente a duração das atividades inter-
nas de dado pacote de trabalho?
e. É necessário definir os custos das atividades internas dos pacotes de
trabalho?
f. Existem dependências entre atividades internas de um pacote de tra-
balho com outros pacotes de trabalho?
g. Os recursos alocados aos pacotes de trabalho mudam com o tempo?
h. Existem critérios de aceitação aplicáveis antes da finalização de um
pacote de trabalho?
i. Existem entregas intermediárias que podem ser usadas para gerar
fluxo de caixa positivo?
j. Existem riscos específicos que necessitam atenção específica?

Caso o número de respostas positivas para as questões anteriores seja


grande, configura-se a necessidade de desdobramento adicional dos paco-
tes de trabalho. Além da lista de verificação do desdobramento dos paco-
tes de trabalho em uma EDT, os autores sugerem uma estrutura genérica
para registrar as informações mais relevantes de cada pacote de trabalho
(Figura 3.11).

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 133 — #161


i i

Gerenciamento do desenvolvimento integrado de produtos 133

Figura 3.11 Estrutura genérica de registro de informações de pacotes de


trabalho (Raz e Globerson, 1998)

3.8 Tempo e custo do projeto

O tempo e o custo do projeto estão entre as variáveis mais importantes


para o seu sucesso. Para tratá-las existem processos e ferramentas sob o
contexto do gerenciamento do tempo e do custo, cujos principais aspectos
serão vistos a seguir.

3.8.1 Gerenciamento do tempo do projeto

Segundo o PMI (2000), o gerenciamento do tempo do projeto envolve


os seguintes processos: definição, seqüenciamento e estimativa de duração

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 134 — #162


i i

134 Projeto Integrado de Produtos: planejamento, concepção e modelagem

das atividades e elaboração e controle do cronograma. Os quatro primei-


ros são aqueles processos básicos do planejamento do projeto (Figura 3.5)
e serão descritos a seguir, com as respectivas orientações e ferramentas de
suporte.
A definição das atividades do projeto consiste no desdobramento dos
trabalhos necessários para alcançar os resultados especificados para o pro-
jeto. Nessa definição, as atividades devem ser identificadas e documenta-
das, estando de acordo com os objetivos e o escopo do projeto e os elemen-
tos da EDT.
A definição das atividades do projeto ocorre em geral sob duas situa-
ções principais. A primeira, em que o projeto sendo planejado é similar a
outros projetos já executados pela organização. Por exemplo, o projeto de
construção de um edifício, uma vez que a empresa já construiu vários ou-
tros edifícios similares. No segundo caso, a definição das atividades deve
ser realizada para novos projetos, sem similares na organização. Por exem-
plo, o projeto de desenvolvimento de um novo produto que não faz parte
da linha de produção atual da empresa.
No primeiro caso, a definição das atividades é fortemente influenciada
pelo histórico dos projetos anteriores, como fonte primária de informações
para o planejamento. O uso dessas informações se torna apropriado para
a definição das atividades, mas também para decidir se certas atividades
são realmente necessárias e importantes nesse novo projeto, com base nos
resultados dos projetos anteriores.
No segundo caso, de novos projetos para a organização, ou mesmo
quando se está implantando sistemáticas de gerenciamento de projetos, a
experiência do pessoal de planejamento, bem como um modelo de desen-
volvimento de produtos, são elementos essenciais para orientar a defini-
ção das atividades do projeto. O modelo de desenvolvimento de produtos
fornece grande parte dos elementos da EDT na forma de fases, atividades
e tarefas a serem executadas para o desenvolvimento do produto, que são
logicamente definidas e estruturadas. A experiência dos planejadores, por
sua vez, orienta a definição e decisão sobre certas atividades do projeto,
baseado principalmente em analogias com projetos já executados. As ta-
belas A.1 a A.4 dão uma boa orientação para a definição das atividades e
tarefas, considerando as funções no processo de projeto de máquinas.
Verzuh (2000) recomenda os seguintes procedimentos para auxiliar na
definição das atividades do projeto:

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 135 — #163


i i

Gerenciamento do desenvolvimento integrado de produtos 135

• a partir do escopo do projeto, listar todos os resultados esperados da


sua execução;
• listar todas as atividades necessárias para produzir os resultados es-
perados. Em seguida, deve-se desdobrar cada atividade em tarefas
até se chegar a uma tarefa que não possa ou não necessite mais ser
desdobrada;
• seqüenciar a estrutura de desdobramento do trabalho segundo as
suas relações de dependência e a partir do nivelamento dos recursos
disponíveis para o projeto (esse procedimento, em particular, será
tratado mais adiante).
Segundo Hoffmeister (2003), a definição das atividades do projeto
deve ser baseada em um modelo de desenvolvimento de produtos, princi-
palmente na orientação de profissionais de planejamento pouco experien-
tes. O autor recomenda as seguintes etapas para auxiliar nessa definição:

• pesquisa bibliográfica: coletar as informações necessárias sobre as


ferramentas empregadas no processo de desenvolvimento de produ-
tos e seus típicos resultados; listar os marcos de tomada de decisão
com base nas fases do modelo de desenvolvimento de produtos e
listar os principais resultados de cada marco;
• entrevista com especialistas: consultar os potenciais executores dos
resultados identificados na etapa anterior para identificar em deta-
lhes as atividades necessárias para sua execução;
• análise das informações: analisar criticamente as atividades listadas
procurando definir os demais elementos necessários, como entradas
e saídas, entre outros, de cada atividade para a completa definição
dos trabalhos necessários, utilizando como base o padrão de mode-
lagem IDEF0 (NIST, 1993);
• esboço inicial das atividades: revisar e listar as atividades resultantes
das etapas anteriores como base para os demais processos de plane-
jamento.

O seqüenciamento das atividades do projeto consiste na identificação


e documentação das relações lógicas entre as atividades e forma a base
para posterior elaboração do cronograma do projeto. Alguns métodos re-
comendados para a execução desse processo são: método do diagrama de

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 136 — #164


i i

136 Projeto Integrado de Produtos: planejamento, concepção e modelagem

precedência (PDM – Precedence Diagram Method) e Matriz de Estruturação


do Projeto (MEP), esta última mais conhecida como DSM (Design Structure
Matrix).
O PDM consiste em uma forma de rede para representar as relações de
dependência entre as atividades, sendo que os nós da rede (caixas ou re-
tângulos) representam as atividades, e as flechas, as dependências (Figura
3.12).
Observam-se, na Figura 3.12, além das dependências entre as ativida-
des, o caminho crítico do projeto, definido pela seqüência de atividades
onde o tempo de execução é maior, e as informações, como datas de início
e fim e duração da atividade. Incluem-se aí também as atividades que po-
dem ser executadas em paralelo. Nesse tipo de representação, entretanto,
não se consegue visualizar as interações e realimentações entre as ativida-
des de um projeto, as quais são típicas em projetos de desenvolvimento de
produtos. Esse tipo de informação é mais bem apresentado em métodos
como a MEP.

Figura 3.12 Exemplo de um diagrama PDM

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 137 — #165


i i

Gerenciamento do desenvolvimento integrado de produtos 137

A MEP auxilia no seqüenciamento das atividades de projeto de forma


compacta, sendo as dependências entre as atividades estabelecidas de
acordo com a escala de relacionamento adotada. Nesse método as ativi-
dades de projeto são dispostas em uma matriz, em suas linhas e colunas
(Figura 3.13).
Os relacionamentos na diagonal da matriz, ou seja, entre as próprias
atividades, são nulos. Os demais relacionamentos podem ser estabelecidos
de duas formas principais:

1. Se a atividade Aj fornece informações para a atividade Ai , então


o relacionamento é aij = 1 e representa uma dependência do tipo
seqüencial término para início.
2. Se a atividade Aj não fornece informações para a atividade Ai , então
o relacionamento é aij = 0 (para i = j) e representa uma dependência
do tipo paralela.

Figura 3.13 Representação genérica de uma MEP

Empregando-se essas definições para o exemplo mostrado na Figura


3.12, obtém-se uma representação das dependências entre as atividades de
projeto conforme mostrado na Figura 3.14.
Há três tipos principais de relacionamentos entre as atividades de pro-
jeto, que podem ser representados nos métodos PDM e MEP. A defini-
ção desses relacionamentos e suas típicas representações são comparati-
vamente mostradas na Figura 3.15. No relacionamento em paralelo as ati-
vidades estão desacopladas, isto é, a atividade A é independente da ati-
vidade B, e vice-versa, o que é representado por zero, na matriz. Nesse
caso, as duas atividades podem ser desenvolvidas em paralelo. O relacio-
namento seqüencial, com representação em série para as atividades, indica
que A está desacoplada de B, mas B é dependente de A, indicado por 1 na

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 138 — #166


i i

138 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 3.14 Exemplo de aplicação de uma MEP

Figura 3.15 Tipos de relacionamentos entre as atividades e suas representações

matriz. O relacionamento acoplado A e B é interdependente, requerendo,


nesse caso, um desenvolvimento simultâneo.
A decisão sobre o tipo de dependência entre atividades de projeto de-
pende de certos fatores, dentre os quais a natureza das entradas e saídas

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 139 — #167


i i

Gerenciamento do desenvolvimento integrado de produtos 139

das atividades é um dos mais importantes. O PMI (2000) aponta algumas


categorias de dependências que podem ajudar na definição desses relacio-
namentos:

• dependências obrigatórias: inerentes ao trabalho que está sendo efe-


tuado, não podem ser desconsideradas. Geralmente envolvem limi-
tações físicas. Por exemplo, a construção de um protótipo precede
seu teste;
• dependências arbitrárias: estabelecidas pela equipe de desenvolvi-
mento do produto, geralmente de acordo com a experiência e melho-
res práticas numa dada área de aplicação. Por exemplo, uma equipe
de desenvolvimento de produtos provavelmente não solicitará a
produção de um lote piloto do produto sem antes ter construído e
testado o protótipo do produto. Entretanto, dependendo da solução
obtida, da complexidade do produto e da experiência da equipe, o
lote piloto pode ser arbitrariamente solicitado sem os testes com o
protótipo;
• dependências externas: relacionadas a fatores externos ao projeto.
Um exemplo típico consiste no teste de um protótipo que depende
de um equipamento que será fornecido por outra empresa.

Outro aspecto relacionado ao seqüenciamento das atividades de pro-


jeto refere-se ao nível em que esses relacionamentos devem ser construí-
dos: atividades ou pacote de trabalho. Os pacotes de trabalho, por defini-
ção, segundo Raz e Globerson (1998), são as menores partes gerenciáveis
de um projeto. Entretanto, cada pacote de trabalho consiste em um nú-
mero de atividades e, se as dependências entre as atividades cruzam as
fronteiras dos pacotes de trabalho, pode-se perder precisão nos relaciona-
mentos, conforme o exemplo a seguir.
Na Figura 3.16a observam-se dois pacotes de trabalho, cada um cons-
tituído de três atividades. Os relacionamentos entre as atividades são
seqüenciais, do tipo término para início. Na construção da rede de relacio-
namentos do projeto, deve-se definir os relacionamentos entre os pacotes
de trabalho 1 e 2, fazendo o pacote de trabalho 1 preceder o 2. Quando
isso é feito, tendo em vista os relacionamentos entre as atividades, perde-
se a informação de que a atividade D pode ser executada paralelamente
à atividade C. Uma solução que pode ser adotada, nesse caso, consiste

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 140 — #168


i i

140 Projeto Integrado de Produtos: planejamento, concepção e modelagem

em reorganizar as atividades dos pacotes de trabalho, conforme a Figura


3.16b, possibilitando construir uma rede mais precisa somente com rela-
cionamentos do tipo término para início entre os pacotes de trabalho.

Figura 3.16 Efeito do conteúdo dos pacotes de trabalho na construção de uma


rede de projeto

Como orientação geral, as atividades que são altamente interdepen-


dentes devem ser reunidas em um mesmo pacote de trabalho, a fim de
reduzir o acoplamento entre os pacotes de trabalho e tornar mais fácil a
construção da rede de relacionamentos do projeto.
A estimativa de duração das atividades do projeto, segundo PMI
(2000), consiste na coleta de informações sobre o escopo e os recursos do
projeto para calcular os tempos necessários das atividades como base para
a elaboração do cronograma do projeto. Nesse processo, normalmente se
recorre à pessoa ou ao grupo que executará determinada atividade para
definir sua duração. Em grandes projetos, entretanto, esse procedimento
pode ser inadequado. Nesses casos deve-se recorrer aos responsáveis pe-
las equipes executoras do projeto e de suas partes (gerências funcionais,
líderes de equipes, entre outros).
A estimativa de duração das atividades é um processo progressivo e
depende da qualidade e disponibilidade dos dados. Pela própria defini-
ção, a estimativa de tempo possui incertezas inerentes, as quais devem ser
minimizadas através de uma adequada coleta e análise das informações

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 141 — #169


i i

Gerenciamento do desenvolvimento integrado de produtos 141

sobre cada atividade. São muito importantes, nesse processo, os dados his-
tóricos e a experiência dos estimadores.
Segundo Kerzner (2001), existem três tipos de estimativas, com suas
correspondentes precisões, aplicados à estimativa de custos. A primeira
delas é uma análise de ordem de grandeza, realizada sem o uso de dados
detalhados. A precisão desse tipo de estimativa encontra-se na faixa de ±
35%. Um segundo tipo, de estimativa aproximada (ou top-down), também
conduzida sem dados muito detalhados, apresenta uma precisão na faixa
de ± 15%. Esse tipo de estimativa é baseado em analogias com projetos
similares. Na estimativa definitiva ou detalhada, os valores são baseados
em dados detalhados sobre o problema em questão, sejam estes históricos,
de simulações, experimentos, entre outros, e sua precisão encontra-se na
faixa de ± 5%.
A estimativa de duração de uma atividade depende dos recursos que
serão alocados para sua execução. Entretanto, essa relação não é linear,
pois depende, em muitos casos, de limitações físicas para a execução da
atividade. Por exemplo, um projetista leva duas horas para modelar um
componente num ambiente CAD. Se outro projetista for alocado para essa
mesma atividade, não há garantia na redução do tempo pela metade, uma
vez que podem existir restrições operacionais no uso simultâneo do soft-
ware e do hardware.
O tempo de execução de uma atividade também é influenciado pela
qualidade dos recursos alocados (pessoas, equipamentos, materiais etc.).
Pessoas mais experientes tendem a desempenhar mais rapidamente de-
terminada atividade em comparação aos menos experientes, assim como
software e hardware mais modernos, após um treinamento adequado, con-
tribuem para reduzir o tempo na modelagem e na simulação de compo-
nentes ou sistemas.
A natureza das atividades também tem influência em suas estimativas.
Atividades mais rotineiras são mais facilmente previsíveis em comparação
a atividades mais criativas. Pode-se, através de métodos de criatividade,
suportar as atividades criativas, mas é pouco provável que se possa deter-
minar um tempo preciso para ser criativo.
A importância em se determinar adequadamente a duração das ati-
vidades do projeto e, como conseqüência, a própria duração do projeto,
está relacionada diretamente ao sucesso do produto no mercado. Várias
pesquisas têm demonstrado que o atraso no lançamento de produtos no

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 142 — #170


i i

142 Projeto Integrado de Produtos: planejamento, concepção e modelagem

mercado em relação aos concorrentes provocam perdas nos lucros e au-


mento dos custos de produção.
Em geral, as melhores práticas para a estimativa da duração das ativi-
dades são:

• execução, pela pessoa ou equipe de projeto responsável pela reali-


zação da atividade, resulta em estimativa com menos influências e
maior precisão do que uma pessoa avaliando todas as atividades, e
compromisso em atender aos prazos. Em projetos grandes, esta prá-
tica torna-se difícil;
• usar, sempre que possível, o julgamento de especialistas apoiado em
dados históricos;
• obter a participação de subcontratantes ou de fornecedores no que se
relaciona à avaliação dos tempos de fornecimento de serviços, mate-
riais, componentes, montagens ou equipamentos;
• executar estimativas por analogia a projetos semelhantes;
• executar estimativa por simulação, que envolve o cálculo de múlti-
plas durações com diferentes conjuntos de suposições.
Algumas orientações para a estimativa de tempo das atividades de
projeto são sugeridas por Verzuh (2000):
• ao estabelecer a duração estimada de uma atividade é importante in-
serir todo o tempo necessário para executá-la, incluindo, por exem-
plo, tempos de espera, preparação, potenciais atrasos, entre outros;
• nas atividades em que são necessários conhecimentos específicos
para executá-las, aumentar o número de pessoas nem sempre resulta
em menor duração;
• evitar estimativas otimistas e prontamente apresentadas sem anali-
sar os fatores de influência na execução da atividade;
• levar em conta as limitações pessoais e as restrições de recursos na
estimativa de duração das atividades;
• deve-se defender apropriadamente as estimativas realizadas du-
rante um processo de negociação, evitando distorções acentuadas no
cronograma; em vista de pressões por menores prazos e custos, as re-
duções realizadas devem ser baseadas nos resultados do projeto e na
produtividade dos recursos;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 143 — #171


i i

Gerenciamento do desenvolvimento integrado de produtos 143

• realizar estimativas detalhadas por fase do desenvolvimento do pro-


duto, e de ordem de grandeza do processo restante, em vez de procu-
rar uma estimativa precisa de todo o processo. Nesse caso, cada fase
do desenvolvimento do produto é tratada como se fosse um projeto;

• todos os participantes do projeto devem ser responsáveis pelas esti-


mativas do projeto, sejam de tempo ou de custo.

Outro aspecto interessante na estimativa de tempo das atividades de


projeto, igualmente válido para a estimativa de seus custos, refere-se à
seguinte questão: qual o nível de divisão do trabalho mais apropriado para
as estimativas de tempo e de custos?
Segundo Raz e Globerson (1998), estimativas baseadas em pacotes de
trabalho menores são, em geral, mais precisas. Entre os fatores de influên-
cia incluem-se: melhor base de informações para as estimativas e a natu-
reza estatística dos erros envolvidos.
Com relação ao segundo fator, devido às incertezas inerentes no pro-
cesso, cada estimativa possui um erro aleatório, podendo ser igualmente
positivo ou negativo. Quando as estimativas são somadas, alguns dos er-
ros são cancelados, resultando que o erro da soma das estimativas tem um
valor menor se comparado à soma dos erros das estimativas originais.
Em geral, aumentando-se o número de pacotes de trabalho e fazendo-
os de tamanhos iguais, tanto quanto possível, contribui-se para aumentar
a precisão nas estimativas totais de tempos e custos do projeto, desde que
as estimativas sejam mutuamente independentes ou fracamente correlaci-
onadas.
A elaboração do cronograma do projeto consiste, em essência, numa
síntese dos resultados dos processos anteriores e de suas apresentações
em forma gráfica, empregando-se, em geral, um diagrama de barras, o
Gantt. Também são incluídas, nesse processo, as atividades relacionadas à
determinação das datas de início e fim do projeto, cálculo do cronograma
e nivelamento de recursos.
Entre os resultados desse processo está o próprio cronograma do pro-
jeto, mostrando as datas planejadas de início e fim de cada atividade. Esse
cronograma pode ser apresentado em forma de resumo ou em detalhes.
Os formatos mais usuais são: diagrama de rede (Figura 3.12), em que, além
do relacionamento lógico entre as atividades do projeto, se observam da-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 144 — #172


i i

144 Projeto Integrado de Produtos: planejamento, concepção e modelagem

tas de início e fim de cada atividade e o caminho crítico e gráfico de barras,


conhecidos como gráfico de Gantt (Figura 3.17).
Também são resultados da elaboração do cronograma do projeto os
documentos auxiliares que descrevem todas as premissas e restrições
identificadas na programação, bem como a forma de gerenciamento do
cronograma, principalmente de suas alterações.

Figura 3.17 Exemplo de gráfico de Gantt

O cálculo do cronograma consiste na aplicação de técnicas de progra-


mação visando otimizar a execução do projeto entre os limites estabele-
cidos para seu início e/ou término. As datas de início e fim do projeto
estabelecem o “envelope” de tempo no qual o projeto deve ser executado.
O tempo de conclusão é, normalmente, parte dos objetivos do projeto, faz
parte do contrato de fornecimento de uma construção ou de um equipa-
mento, por exemplo. Às vezes, o início e o final do projeto são estabele-
cidos em contrato, mas é mais freqüente que o cliente ou consumidor só
especifique a conclusão do projeto ou a data de entrega do produto.
O método de cálculo do cronograma baseia-se na definição dos tempos
para cada atividade, conforme descrito anteriormente, indicando:

• o tempo mais cedo de início (Earliest Start time) – ESt: o tempo mais
cedo no qual uma dada atividade pode começar é calculado com
base no tempo definido de início do projeto e de duração estimada
das tarefas precedentes;

• o tempo mais cedo de término (Earliest Finish time) – EFt: o tempo


mais cedo no qual uma determinada atividade pode ser completada

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 145 — #173


i i

Gerenciamento do desenvolvimento integrado de produtos 145

é calculado pela adição da estimada duração da tarefa ao tempo de


início da tarefa: EFt = ESt + tempo de duração;
• o tempo mais tarde de término (Latest Finish time) – LFt: o tempo
mais tarde no qual uma determinada atividade deve terminar, de
modo que o projeto como um todo seja concluído no tempo reque-
rido, é calculado com base no tempo de conclusão do projeto e nas
estimadas durações das atividades seguintes;
• o tempo mais tarde de início (Latest Start time) – LSt: o tempo mais
tarde no qual uma dada atividade deve começar, de modo que o
projeto como um todo é concluído no tempo requerido, é calculado
subtraindo a estimada duração da atividade do tempo mais tardio
de término da atividade: LSt = LFt – tempo de duração.
Com base na definição desses tempos, aplicam-se as seguintes regras
durante o processo de programação:
• regra 1: o tempo mais cedo de início (ESt) de uma atividade parti-
cular deve ser o mesmo, ou o valor do maior tempo mais cedo de
término (EFt) de todas as atividades precedentes da (ou que termi-
nam na) atividade particular. Ou seja, ESt (atividade X) = maior va-
lor [EFt (das atividades que terminam em A)]. A Figura 3.18 mostra
um exemplo parcial de aplicação dessa regra onde o tempo (ESt) da
atividade L originou-se do maior tempo (EFt) das atividades I e J;

Figura 3.18 Exemplo parcial de aplicação da regra 1 na programação de um


projeto

• regra 2: o tempo mais tarde de término (LFt) de uma atividade parti-


cular deve ser o mesmo, ou o menor valor dos tempos de mais tarde

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 146 — #174


i i

146 Projeto Integrado de Produtos: planejamento, concepção e modelagem

início (LSt) das atividades que iniciam nesta atividade particular. Ou


seja, LFt (atividade X) = menor valor [LSt (das atividades que ini-
ciam em A)]. A Figura 3.19 mostra um exemplo parcial de aplicação
dessa regra onde o tempo (LFt) da atividade L originou-se do menor
tempo (LSt) das atividades I e J.

Figura 3.19 Exemplo parcial de aplicação da regra 2 na programação de um


projeto

Com base nessas definições e regras, procede-se a elaboração do crono-


grama do projeto verificando a viabilidade em cumprir os prazos especifi-
cados, determinando as folgas do projeto e definindo o caminho crítico. As
folgas do projeto devem ser, se possíveis, positivas para evitar atrasos na
execução do cronograma e são calculadas pelas diferenças entre o tempo
de término mais tarde e o tempo mais cedo de término e o tempo mais
tardio de início e o tempo mais cedo de início, ou seja: F = LFt - EFt = LSt -
ESt.
Os tipos de software disponíveis para auxiliar no gerenciamento de pro-
jetos, em sua grande maioria, automatizam esses procedimentos tornan-
do-se fácil e rápido promover simulações, considerando variações nos da-
dos de cada atividade do projeto, como redução de seus tempos, alocação
de mais recursos, entre outros. Em Verzuh (2000), tem-se uma boa descri-
ção de várias recomendações para equilibrar um projeto e seu cronograma.

3.8.2 Gerenciamento de custos do projeto

Grande parte dos conceitos e orientações sobre estimativas de tempo e


elaboração do cronograma do projeto se aplica, também, à estimativa dos
custos das atividades de projeto e à elaboração de seu orçamento.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 147 — #175


i i

Gerenciamento do desenvolvimento integrado de produtos 147

O gerenciamento de custos do projeto, segundo o PMI (2000), consiste


em assegurar que ele será concluído dentro do orçamento aprovado. Os
seguintes processos estão envolvidos: planejamento dos recursos e esti-
mativa, orçamento e controle de custos. Na fase de planejamento, os três
primeiros processos encontram-se em evidência e serão aqui descritos em
maiores detalhes.
O gerenciamento de custos do projeto ocorre em diferentes momentos
do desenvolvimento do projeto, desde o planejamento estratégico, pas-
sando pelo desenvolvimento do projeto, até o gerenciamento de custos
do ciclo de vida do produto. No planejamento estratégico, por exemplo,
podem ser aplicados métodos para a análise de retorno de investimento
de projetos candidatos a determinadas metas da empresa. No desenvol-
vimento do projeto, principal foco neste capítulo, busca-se definir e pro-
gramar os recursos e seus custos para a execução do projeto, na forma de
detalhamento do orçamento aprovado. Com relação ao gerenciamento de
custos do ciclo de vida do produto, interessa verificar o efeito de decisões
de projeto sobre os custos do uso do produto. Grande parte das ativida-
des, sob esse enfoque, é própria do processo de projeto, seja na proposição
e estimativa de custos de soluções conceituais para o produto, seja no deta-
lhamento dos custos do ciclo de vida da solução desenvolvida para o pro-
duto. Essas atividades têm sido estudadas e aplicadas, por exemplo, sob
a perspectiva de aspectos econômicos no processo de projeto do produto
e projeto para a viabilidade econômica (Back, 1983, Blanchard e Fabrycky,
1990).
O processo de planejamento de recursos consiste na determinação de
quais recursos e que quantidades devem ser usados para executar as ati-
vidades do projeto. Esses recursos são: financeiros; de mão-de-obra, o res-
pectivo tipo individual ou especialidades; de equipamentos; de materiais;
de facilidades; e outros insumos necessários, mas geralmente considera-
dos de disponibilidade limitada.
O planejamento de recursos deve começar com base no escopo do pro-
jeto e nas atividades definidas na EDT. Segue-se com o uso de informações
históricas sobre os típicos recursos utilizados em projeto similares e com
a determinação da disponibilidade dos recursos. Este último aspecto deve
ser confrontado com a definição das atividades e o cronograma do projeto.
O principal resultado desse processo consiste numa descrição detalhada
dos tipos e quantidades de recursos para cada atividade do projeto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 148 — #176


i i

148 Projeto Integrado de Produtos: planejamento, concepção e modelagem

No planejamento de recursos para o projeto encontram-se várias re-


comendações para orientar os gerentes de projeto. Dentre elas, conforme
Kerzner (2001) deve-se: constituir um núcleo de colaboradores, que atue
no projeto desde seu início até o final; não subestimar os recursos quanto
ao trabalho que eles podem executar; prever contingências; e empregar,
sempre que possível, pessoal da própria organização, quando se requer
conhecimento da empresa.
Um aspecto importante no planejamento de recursos consiste no que
se denomina “nivelamento de recursos”. Em estruturas do tipo matricial,
os gerentes de projeto negociarão recursos com os gerentes funcionais da
organização. Deve-se tomar cuidado para que, no processo de requisição
e alocação de recursos ao projeto, as necessidades sejam o mais uniforme
possível ao longo do tempo de projeto, evitando-se alocações excessivas
em certos períodos de tempo comparado com alocações mínimas em ou-
tros. Essa desatenção provoca dificuldades de programação de recursos
aos gerentes funcionais, o que ocasiona conflitos na organização. Algumas
orientações para o nivelamento de recursos, segundo Verzuh (2000):

• identificar os períodos de pico do projeto, geralmente próximos às


entregas parciais do projeto, para verificar se os recursos planejados
são realistas;
• nos períodos de pico, procurar atrasar as atividades não críticas do
projeto, ou seja, aquelas fora do caminho crítico com folga positiva;
• reavaliar as estimativas das atividades de projeto, verificando se é
possível reduzir o número de pessoal em determinada tarefa, execu-
tando-as em um tempo maior. Nesse caso, os recursos disponíveis
poderão ser alocados em outras tarefas.

Outro compromisso que deve ser analisado no planejamento de re-


cursos ocorre entre a programação de atividades em paralelo e os recursos
disponíveis. Atividades programadas em paralelo, de fato, ajudam a redu-
zir o tempo de execução do projeto. Nesse caso, parte-se do pressuposto
de que todos os recursos estarão disponíveis para a execução das ativida-
des. Deve-se verificar se nesse caso não haverá picos de recursos alocados
no projeto e se os mesmos estarão disponíveis de fato, caso contrário, solu-
ções conforme apresentadas na Figura 3.20 podem ajudar no nivelamento
dos recursos.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 149 — #177


i i

Gerenciamento do desenvolvimento integrado de produtos 149

Figura 3.20 Exemplo de solução adotada para o nivelamento de recursos

O processo de estimativa de custos do projeto consiste em estimar


os custos dos recursos necessários e alocados para completar as tarefas
individuais do projeto. Enquanto processo de estimativa, segue as mesmas
orientações estabelecidas anteriormente para a estimativa de duração das
atividades do projeto. A execução desse processo contribuirá para definir
quanto custará o projeto.
A estimativa de custo das atividades do projeto, tendo em vista seus
objetivos, tempos, recursos alocados e os custos unitários dos recursos,
também depende dos preços estabelecidos pela organização, que, por sua
vez, podem estar de acordo com diferentes estratégias.
Segundo Kerzner (2001), dois tipos de projeto podem ser considera-
dos: no tipo I, trata-se de projeto único, sem potencial de repetir-se ou de
ocorrer outro projeto semelhante e com o mesmo cliente; no tipo II, trata-
se de um projeto de penetração no mercado, ou seja, pode ser um caso
de entrada para outros negócios, pode repetir-se em um maior número
de projetos ou produtos semelhantes, ou obter um ponto de apoio em um
mercado novo.
Nos projetos do tipo I, tem-se o objetivo de elaborar uma proposta ven-
cedora e executar o projeto satisfatoriamente, com lucro, de acordo com os

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 150 — #178


i i

150 Projeto Integrado de Produtos: planejamento, concepção e modelagem

termos do contrato assinado. As estratégias de fixação de preço para esse


projeto, e que influenciarão as estimativas de custos do projeto, são:

• desenvolver modelos e orientações de estimativa de custo e elaborar


o projeto conceitual do produto para mínimo custo e atendimento
mínimo dos requisitos de projeto;
• estimar realisticamente os custos para atendimento mínimo dos re-
quisitos de projeto;
• revisar o projeto conceitual do produto e reduzir os custos desneces-
sários;
• obter o comprometimento dos participantes do projeto quanto aos
custos estabelecidos;
• ajustar as estimativas de custos para os riscos do projeto;
• adicionar margens de lucro e determinar o preço do projeto;
• buscar informações da concorrência para comparações;
• apresentar a proposta somente se o preço for competitivo.

No tipo II, o objetivo é vencer o projeto e ter um bom desempenho


para conquistar um ponto de apoio no mercado ou novos consumidores,
em vez de obter lucros no primeiro projeto. Nesse caso, as estratégias re-
comendadas são:

• desenvolver o projeto básico do produto, apropriado para avaliar


os custos, em conformidade com os requisitos do projeto mas com
riscos mínimos;
• estimar os custos realisticamente;
• revisar o projeto básico e reduzir os custos desnecessários;
• determinar custos mínimos realistas e obter comprometimento dos
participantes;
• determinar custos incluindo os riscos;
• comparar as estimativas com o orçamento do cliente ou de concor-
rentes;
• definir a margem de lucro para estabelecer uma proposta vencedora,
podendo esta ser negativa;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 151 — #179


i i

Gerenciamento do desenvolvimento integrado de produtos 151

• decidir se a margem de lucro é compatível com o desejo de vencer a


proposta e cotar o preço de maior probabilidade para vencer a pro-
posta;
• descrever, no caso em que o preço é menor do que os custos, quais as
fontes de recursos disponíveis para cobrir eventuais prejuízos. Isso
demonstra transparência e credibilidade no orçamento.

Nota-se que, para a aplicação dessas estratégias, faz-se importante o


processo de estimativa de custos do produto, principalmente em suas fa-
ses iniciais de desenvolvimento. Conforme mencionado no início, trata-se
do enfoque sobre análise econômica no projeto de produto, assunto que
será tratado no Capítulo 8.
O processo de orçamento de custos trata da alocação dos recursos fi-
nanceiros estimados aos itens individuais de trabalho, com a finalidade
de estabelecer uma base de custo para medir o desempenho financeiro do
projeto. Em geral, é apresentado na forma de planilhas, indicando as ati-
vidades e seus custos, numa linha de tempo, proporcionando a definição
do fluxo de caixa do projeto.
Empregando-se software de auxílio ao gerenciamento de projetos, ten-
do definidos o cronograma, os recursos e os custos dos recursos, obtém-se
automaticamente o fluxo de caixa do projeto, conforme exemplo da Figura
3.21.

Figura 3.21 Exemplo de fluxo de caixa de projeto obtido com auxílio de software

Até aqui, apresentou-se a base conceitual de procedimentos e de mé-


todos e ferramentas para o planejamento de projetos, considerando as va-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 152 — #180


i i

152 Projeto Integrado de Produtos: planejamento, concepção e modelagem

riáveis de escopo, tempo e custo. Essas variáveis não são as únicas envol-
vidas no gerenciamento de projetos, mas são essenciais para a medida de
seu sucesso.
Existe uma série de outras variáveis que também podem comprometer
o sucesso de um projeto e para as quais são dedicados, em geral, estudos
específicos ou áreas específicas do gerenciamento de projetos: qualidade,
riscos, aquisições, comunicações, recursos humanos e integração.
Foge ao escopo deste capítulo o estudo em detalhes dos processos
de gerenciamento associados a cada uma dessas variáveis. Esse conheci-
mento pode ser obtido em literatura especializada, conforme as referências
bibliográficas apresentadas ao fim deste capítulo.

3.9 Execução, controle e encerramento do


processo de desenvolvimento de produtos

Após o planejamento do projeto, iniciam-se os processos de execução


e controle que, em conjunto com o próprio processo de planejamento, for-
mam um ciclo contínuo de atividade até o encerramento do projeto ou de
uma de suas fases.
A execução do projeto consiste, em essência, em pôr em prática o que
foi planejado, assegurando que os recursos estarão disponíveis e coorde-
nando-os conforme foram programados. O controle do projeto procura as-
segurar que os objetivos estão sendo atingidos, monitorando e avaliando
seu progresso e tomando as ações corretivas, quando necessário. O pro-
cesso de encerramento do projeto, ou de uma de suas fases, consiste em
atividades para formalizar a aceitação dos resultados do projeto e para
encerrá-lo de forma organizada, incluindo as lições aprendidas.
Esses processos são amplamente descritos na literatura e não serão
aqui tratados em detalhes. Seus princípios, atividades, métodos e ferra-
mentas podem ser obtidos na literatura recomendada.

3.10 Resumo

1. As condições atuais impõem vários desafios para as equipes que trabalham


em processos de desenvolvimento de produtos, destacando-se, assim, a ne-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 153 — #181


i i

Gerenciamento do desenvolvimento integrado de produtos 153

cessidade de conhecimentos em gerenciamento de projetos para facilitar a


execução dos processos de desenvolvimento de produto da organização.
2. Os conhecimentos e práticas de gerenciamento, de modo geral, foram esta-
belecidos ao longo do tempo, sob diferentes visões. As principais são: clás-
sica, empírica, comportamental, de decisão e sistêmica. No gerenciamento
de projetos as duas últimas são normalmente as mais empregadas.
3. O gerenciamento de projetos consiste na aplicação de conhecimentos, habili-
dades, ferramentas e técnicas nas atividades de projeto, visando satisfazer os
requisitos de projeto, sendo conduzido sob os processos gerais de iniciação,
planejamento, execução, controle e encerramento.
4. No desenvolvimento de produtos, o gerenciamento de projetos consiste na
aplicação, em um ambiente de projetos, de todos os elementos do gerencia-
mento de projetos (princípios, conhecimentos, processos, métodos e ferra-
mentas) para desenvolver ações, visando obter o sucesso do produto e de seu
desenvolvimento, desde o planejamento até a validação. O gerenciamento
do desenvolvimento de produtos diferencia-se do gerenciamento de outros
tipos de projetos principalmente pela natureza das atividades, muitas delas
próprias do processo de projeto de produtos e da metodologia de projeto em-
pregada, e pelos conhecimentos e tecnologias envolvidos com o produto e os
processos de produção,
5. A execução de projeto e seu gerenciamento dependem de uma forma apro-
priada de organização e a maioria das pesquisas tem apontado a estrutura
matricial balanceada ou equilibrada como a forma mais efetiva para se obter
os resultados esperados em uma organização que trabalha com ambientes
de projetos. Entretanto, a escolha de um ou outro tipo de estrutura depende
muito da natureza dos problemas de projeto.
6. A equipe de projeto deve estar devidamente organizada e posicionada com
relação aos trabalhos do projeto. Em outras palavras, o papel de cada in-
tegrante da equipe deve estar devidamente estabelecido, por exemplo, por
intermédio de uma matriz de responsabilidades.
7. O planejamento de projetos de desenvolvimento de produtos já começa, em
essência, no planejamento estratégico e do porta-fólio de produtos da orga-
nização e segue com o planejamento do escopo, do tempo, custos, qualidade,
comunicações, entre outros elementos importantes para o gerenciamento
adequado do projeto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 154 — #182


i i

154 Projeto Integrado de Produtos: planejamento, concepção e modelagem

8. Os projetos são definidos em linhas gerais tendo em vista o planejamento es-


tratégico da organização, que inclui as metas da empresa para determinados
períodos de tempo. Quando existem projetos alternativos para atender a de-
terminada meta, procede-se à seleção das propostas mais promissoras para o
crescimento da organização. Surgem então os projetos aprovados para deter-
minado período e sob determinado orçamento, os quais precisam ser forma-
lizados, designando-se uma gerência e, a partir daí, iniciando-se o processo
de desenvolvimento.
9. Os escopos do projeto e do produto são inter-relacionados e estabelecem as
dimensões do projeto (ou suas limitações) para efeito de negociação, des-
dobramento dos demais elementos do plano de projeto (cronograma, orça-
mento, riscos etc.) e decisões futuras sobre potenciais mudanças no escopo.
10. O gerenciamento do tempo do projeto envolve os processos de definição,
seqüenciamento, estimativa de duração das atividades, elaboração do crono-
grama e controle do cronograma.
11. O gerenciamento de custos do projeto, segundo o PMI (2000), consiste em
assegurar que o projeto será concluído dentro do orçamento aprovado. Es-
tão envolvidos os processos de planejamento dos recursos, a estimativa dos
custos, o orçamento de custos e o controle de custos.

3.11 Problemas e temas de discussão

1. Liste e descreva brevemente as forças ou fatores sociais e econômi-


cos que considera terem levado à necessidade do gerenciamento de
projetos.
2. Discuta as vantagens e desvantagens do gerenciamento do projeto.
3. Quais são algumas das fontes de conflitos que o gerente de projeto
deve considerar e se preocupar?
4. Discuta os deveres e responsabilidades do gerente de projeto e o
quanto sua presença é crítica ou importante para o sucesso do pro-
jeto.
5. Numa organização matricial pode haver conflitos de opinião sobre
quem contribui mais para os lucros, o gerente de projeto ou o gerente
funcional?

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 155 — #183


i i

Gerenciamento do desenvolvimento integrado de produtos 155

6. Quais são os atributos que um gerente de projeto deve possuir? Pode


um indivíduo ser treinando para tornar-se um gerente de projeto?
Se uma empresa mudar de uma estrutura funcional para uma es-
trutura matricial, alguém da própria empresa pode ser promovido e
treinado ou deve-se contratar um profissional externo?
7. Como você defende a declaração de que o gerente de projeto deve
ajudar a si próprio?
8. Apresente as principais diretrizes ou guias para a escolha adequada
da forma de organização de gerenciamento de um projeto.
9. Como você organizaria o gerenciamento de projetos dos seguintes ti-
pos: implantação de um laboratório de pesquisa e desenvolvimento
de uma empresa; sistema de transporte de uma cidade de 50.000 ha-
bitantes; campanha política do candidato a prefeito de Florianópolis;
colhedora automotriz de cereais; edifício residencial.
10. Qual é o propósito da estrutura de desdobramento do trabalho ou do
projeto? Como isso pode auxiliar o gerente de projeto na organização
do projeto?
11. Deveria uma empresa aceitar um projeto que requer uma ime-
diata reestruturação organizacional? Em caso de resposta afirmativa,
quais fatores deveriam ser considerados?
12. Diversos autores afirmam que a tecnologia sofre atrasos numa or-
ganização que atua por projeto, pois não há um grupo responsável
pelo desenvolvimento tecnológico de longo prazo como na organi-
zação funcional. Por outro lado, em uma organização funcional há
problemas de tempos e programações. Você concorda com essas afir-
mações? Justifique com exemplos.
13. Quais são os passos gerais de gerenciamento de um pacote de traba-
lho dentro de um determinado projeto?
14. Quais são as características que distinguem o escopo do projeto do
escopo do produto?
15. Como são estimados os tempos das atividades?
16. As atividades do caminho crítico devem ser gerenciadas diferente-
mente das atividades fora do caminho crítico?

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 156 — #184


i i

156 Projeto Integrado de Produtos: planejamento, concepção e modelagem

3.12 Referências bibliográficas

ABNT – Associação Brasileira de Normas Técnicas. NBR ISO 10006:


Gestão da qualidade – diretrizes para a qualidade no gerencia-
mento de projetos. Rio de Janeiro, dez. 2000, 18p.
BACK, N. Metodologia de projeto de produtos industriais. Rio de Ja-
neiro: Guanabara Dois, 1983.
BLANCHARD, B. S.; FABRICKY, W. J. Systems engineering and analy-
sis. 2.ed. Englewood Cliffs, New Jersey: Prentice-Hall, 1990.
CHIAVENATO, I. Introdução à teoria geral da administração. 3.ed. São
Paulo: McGraw-Hill do Brasil, 1983.
CODAS, M. M. B. Development of project management in Brazil – a
historical overview. International Journal of Project Management.
v.5, n.3, 1987, p.144-148.
HOFFMEISTER, A. D. Sistematização do processo de planejamento de
projetos: definição e seqüenciamento das atividades para o desen-
volvimento de produtos industriais. Florianópolis, 2003. 120f. Dis-
sertação de mestrado. Programa de Pós-Graduação em Engenharia
Mecânica, UFSC.
KERZNER, H. Project management: a systems approach in planning,
scheduling and controlling. 6.ed. New York: John Wiley & Sons Inc.,
2001.
LARSON, E. W; GOBELI, D. H. Organizing for product development
projects. Journal of Product Innovation Management. v.5, n.3, 1988,
p.180-190.
LEWIS, J. P. The project manager’s desk reference. 3.ed. EUA: McGraw-
Hill, 2000.
MEREDITH, J. R.; MANTEL, S. J. Jr. Project management: a managerial
approach. 4.ed. EUA: John Wiley & Sons, 2000.
MERWE, A. P. Van Der. Project management and business development:
integrating strategy, structure, processes and projects. International
Journal of Project Management. v.20, n.5, 2002, p.401-411.
NIST – National Institute of Standards and Technology. Federal Infor-
mation Processing Standards Publication 183, Integration Definition

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 157 — #185


i i

Gerenciamento do desenvolvimento integrado de produtos 157

for Function Modeling (IDEF0). FIPS PUB 183, December 1993. Dis-
ponível em: <http://www.idef.com/pdf/idef0.pdf>. Acesso em:
24/1/2007.
PINTO, J. K. Project management handbook. San Francisco, CA: Jossey-
Bass Inc. Publishers, 1998
PMI – Project Management Institute. A guide to the project manage-
ment body of knowledge: PMBOK guide. EUA: PMI, 2000.
RAZ, T; GLOBERSON, S. Effective sizing and content definition of work
packages. Project Management Journal. v.29, n.4, December, 1998,
p.17-23.
ROMANO, L. N, Modelo de referência para o processo de desenvol-
vimento de máquinas agrícolas. Florianópolis, 2003. 266f. Tese de
doutorado. Programa de Pós-Graduação em Engenharia Mecânica,
UFSC.
VALERIANO, D. L. Gerência em projetos: pesquisa, desenvolvimento
e engenharia. São Paulo: Makron Books do Brasil, 1998.
VARGAS, R. V. Gerenciamento de Projetos. Rio de Janeiro: Brasport,
1998.
VERZUH, E. MBA Compacto: gestão de projetos. Rio de Janeiro: Cam-
pus, 2000.
WIDEMAN, R. M. First principles of project management. Vancouver,
Canadá: 2000. Disponível em: <http://www.pmforum.org/library
/papers/1999/0708papers.htm>. Acesso em: 25/1/2007.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 158 — #186


i i

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 159 — #187


i i

Parte II

Projeto informacional do produto

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 160 — #188


i i

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 161 — #189


i i

Capítulo 4

Planejamento de produtos

4.1 Introdução

A importância do planejamento de produtos reside na necessidade


de as organizações atuarem em mercados cada vez mais competitivos. A
competitividade tem sido promovida, em grande parte, pela inovação em
produtos, que precisa ser contínua e rápida. Inclui-se aí a capacidade de
prever futuros desenvolvimentos, tanto próprios como dos concorrentes.
O planejamento de produtos busca, em essência, responder à seguinte
questão: o que será desenvolvido em função das estratégias da organi-
zação? Decorrentes dessa questão existem várias outras, envolvendo as-
pectos tecnológicos, de produção e financeiros. Com relação à tecnologia,
por exemplo, deve-se investigar quais são as existentes e, dentre elas, as
mais promissoras para determinado período; deve-se, igualmente, moni-
torar e avaliar seu impacto. Sobre a produção devem-se avaliar qual será
o volume a ser produzido, quais as capacidades da organização para no-
vos desenvolvimentos e, com relação aos aspectos financeiros, qual será o
retorno do investimento, em quanto tempo ocorrerá, quais os riscos envol-
vidos etc.
De modo geral, essas questões têm sido investigadas, de forma mais
ou menos abrangente, em diferentes abordagens, como as de planeja-
mento estratégico, planejamento de porta-fólio de produtos, planejamento
da tecnologia, planejamento de projetos (projects) e do próprio processo de
projeto do produto (design) em suas fases iniciais. Essas abordagens algu-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 162 — #190


i i

162 Projeto Integrado de Produtos: planejamento, concepção e modelagem

mas vezes se superpõem e em outras se complementam, em seus princí-


pios, processos, métodos e ferramentas.
Neste capítulo será dada ênfase ao planejamento de produtos, conside-
rando processos, atividades, métodos e ferramentas para orientar e apoiar
a identificação e a seleção de idéias de produtos inovadores, como base
para os futuros projetos da organização.
No Capítulo 3, são apresentadas algumas relações entre os típicos
resultados do planejamento estratégico e do planejamento de projetos.
Nessa discussão, as estratégias são relacionadas aos potenciais projetos da
organização para dado período, os quais precisam ser planejados, execu-
tados e controlados. Nesse contexto, o planejamento de produtos se insere
como um processo para apoiar a definição de projetos que serão desen-
volvidos em termos de idéias de produtos, tecnologias, volumes de pro-
dução, retorno de investimento, entre outros elementos necessários para
efetivamente obter informações para a aprovação, ou não, do projeto. Essa
relação pode ser visualizada na Figura 4.1, como uma extensão da Figura
3.6.

Figura 4.1 Contextualização do planejamento de produtos

De acordo com a Figura 4.1, determinadas estratégias da organização


direcionam os esforços para a busca de idéias de produtos, que deverão
ser desenvolvidas e selecionadas. As idéias selecionadas poderão ser im-
plementadas sob diferentes tecnologias. Quando essa definição for obtida
em seus detalhes, considerando ainda informações do mercado e de pro-
dução, configura-se um projeto de desenvolvimento de produto, que de-
verá ser planejado, executado e controlado conforme os conhecimentos de
gerenciamento de projetos.
Existem vários desafios no planejamento de produtos, alguns dos
quais também se aplicam ao planejamento de projetos e a outras disci-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 163 — #191


i i

Planejamento de produtos 163

plinas de gerenciamento, bem como ao próprio processo de projeto. Entre


os principais, encontra-se a definição da idéia do produto, o que envolve
a identificação e a seleção dentre várias alternativas, trabalhando-se com
informações insuficientes e, em geral, qualitativas. Além disso, deve-se
avaliar as características e as incertezas associadas às novas propostas, ser-
vindo de base para a tomada de decisão da organização pela realização do
projeto.
A Tabela 4.1 apresenta alguns desafios apontados para o planejamento
de produtos, segundo Accept Software Corporation (2004).

Tabela 4.1 Desafios do planejamento de produtos (Accept Software


Corporation, 2004)

Categoria Desafios
Assegurar o alinhamento estratégico: o alinhamento estratégico
é um aspecto crítico para um gerenciamento balanceado e
otimizado do porta-fólio de produtos, visando investimentos
corretos de acordo com as estratégias, valores e riscos. Com os
investimentos corretamente alocados, as empresas podem focar
seus esforços na monitoração do porta-fólio e promover os
ajustes necessários quando as mudanças ocorrem.
Negócio Assegurar decisões consistentes: o sucesso do planejamento de
produtos é assegurado aplicando-se processos repetíveis e
consistentes. Isso viabiliza o gerenciamento preciso das
informações para apoiar a tomada de decisões, sob critérios
bem definidos.
Alcançar metas de rendimento e lucratividade: aumentar a
eficiência na maneira como os produtos são planejados,
desenvolvidos e lançados no mercado.
Balanceamento das necessidades: desenvolver habilidades para
entender as preferências do mercado e de consumidores para
planejar produtos apropriados.
Respostas às mudanças: agilidade e responsabilidade diante de
mudanças. Entender as mudanças e seus impactos no plano de
Mercado produtos e promover os ajustes, quando necessários, são
capacidades importantes para o sucesso.
Estabelecer expectativas do mercado realísticas: considerando
todos os envolvidos (stakeholders), estabelecer expectativas
claras e obteníveis, pois as mesmas influenciarão nas
características dos produtos e em seu tempo de lançamento.
Continua na próxima página

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 164 — #192


i i

164 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 4.1 Desafios do planejamento de produtos (Accept Software


Corporation, 2004)

Categoria Desafios
Gerenciamento da complexidade do produto: considerar a
mudança rápida nas tecnologias e as relações de dependência
entre os produtos.
Melhorar a qualidade do produto: assegurar que os produtos
sejam feitos para as demandas do mercado. Quanto melhor for
Produto a preparação dos requisitos de projeto, tanto melhor será a
chance de sucesso do produto.
Gerenciar a compatibilidade e a obsolescência: buscar a
compatibilidade de novos produtos com os produtos anteriores e
os futuros lançamentos. Estar atento à obsolescência para evitar
interrupção no mercado.
Colaboração entre as equipes: desenvolver habilidades e
infra-estrutura necessária para que haja colaboração entre as
equipes, em um ambiente de projetos.
Alocação de recursos para máximo retorno: buscar o correto
Organização
entendimento das necessidades de recursos para futuros
desenvolvimentos.
Interfaces com os parceiros: promover participação ativa dos
fornecedores-chave no desenvolvimento.

Observa-se que, conforme os desafios apontados na Tabela 4.1, no pla-


nejamento de produtos deverão ser avaliadas muitas alternativas e toma-
das decisões importantes com relação ao negócio da empresa, ao mercado,
ao produto e à organização para o desenvolvimento. Essas decisões pode-
rão determinar o sucesso ou o fracasso do empreendimento, sendo apro-
priado, portanto, o uso de metodologias e métodos de apoio à decisão.
Sob os aspectos anteriores, o presente capítulo discute o processo de
planejamento do produto, seus conceitos e metodologias, visando auxiliar
na obtenção de respostas sobre o que será desenvolvido e apresentando
subsídios para vencer os desafios envolvidos nessa fase do desenvolvi-
mento. Serão apresentadas definições sobre a idéia de produto, estrutura
do processo de planejamento, metodologias e métodos de apoio ao plane-
jamento, organização para a inovação e avaliação do impacto de tecnolo-
gias.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 165 — #193


i i

Planejamento de produtos 165

4.2 Idéia do produto

Entre os principais resultados do planejamento de produtos encontra-


se a idéia do produto. A idéia de um produto pode apresentar-se de várias
formas: descrição de características necessárias ao produto, descrição fun-
cional do produto, descrição de seus princípios de funcionamento ou uma
combinação das anteriores, na forma textual, gráfica ou em ambas. Em ge-
ral, nessa fase do processo de desenvolvimento, a descrição do produto
não é completa e deve haver um esforço no sentido de torná-la mais clara
possível para apoiar o processo de decisão.
A idéia, também conhecida como o conceito do produto, representa
uma síntese das características do produto estabelecidas sob diferentes
perspectivas, dependendo da visão e da linguagem. Na indústria auto-
mobilística, por exemplo, a idéia do produto pode se dar na forma da
mensagem que o produto passa ao consumidor e pode ser estabelecida
sob categorias de características conforme exemplos mostrados na Tabela
4.2.
Também são encontradas idéias de produtos na forma de visões de
características futuras do produto, como pode ser observado na Figura 4.2,
que representa uma parcela de um mapeamento tecnológico para futuros
sistemas de transporte.
Certamente, as idéias de produtos expressadas nos exemplos anterio-
res não são informações suficientes para decidir ou orientar o processo
de desenvolvimento do produto. São informações iniciais e importantes,
mas outras serão necessárias para apoiar o processo de decisão na fase de
planejamento do produto.
A idéia do produto é constituída de informações técnicas e de mer-
cado. Essas informações também são chamadas de perspectiva tecnoló-
gica e comercial, conforme a Figura 4.3. A perspectiva comercial estimula
prospectivamente o processo de inovação, geralmente na forma de neces-
sidades e requisitos identificados. Já a perspectiva tecnológica impulsiona
o processo de inovação pelas tecnologias disponíveis, obsolescência tec-
nológica dos produtos atuais da empresa ou produtos concorrentes inova-
dores. Deve haver um balanceamento apropriado entre essas perspectivas
para que se obtenha idéias de acordo com estratégias, metas e contexto da
organização.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 166 — #194


i i

166 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 4.2 Conceitos de veículos em mercados norte-americano, europeu e


japonês (adaptado de Clark e Fujimoto, 1991)

Categoria EUA Europa Japão


Interior e exterior Compacto, uso Compacto, uso
Unidade/conjunto
grandes eficiente do espaço eficiente do espaço
Formas arredondadas,
Frente e traseira frente e traseira curtas, Influenciado pelos
Estilo alongados , ênfase ênfase na estilos europeu e
no tamanho aerodinâmica e na americano
eficiência do espaço
Grandes carrocerias, Pequenos motores, Pequenos motores,
motores de elevadas estrutura leve, ênfase estrutura leve, ênfase
Motor/carroceria potências, estrutura na economia de na economia de
pesada, resposta combustível, combustível,
lenta resposta rápida resposta rápida
Firme e controle
Dependente do
Dirigibilidade Suave, confortável preciso, ênfase no
segmento
prazer do passeio
Opcionais e
Fontes de valor
Opcionais Equilíbrio total equipamentos
agregado
padronizados
Para todos os
Eclético e
propósitos, grande, Uma máquina de dirigir
Imagem geral dependente do
confortável e precisa e sofisticada
segmento
potente

Figura 4.2 Visões futuras de subsistemas de veículos representando a idéia de


produtos (adaptado de Phaal, 2002)

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 167 — #195


i i

Planejamento de produtos 167

Figura 4.3 Perspectivas comercial e tecnológica no processo de inovação


(adaptado de Phaal, Farrukh e Probert, 2004)

A idéia do produto também pode ser entendida como uma especifi-


cação de oportunidade, a qual deve conter uma idéia central chamada de
benefício básico, ou seja, a vantagem que o consumidor perceberá ao ad-
quirir o produto em relação aos concorrentes. A especificação da oportuni-
dade também deve conter todos os fatores que determinarão o sucesso co-
mercial do produto e deve ser devidamente justificada. A Figura 4.4 apre-
senta outros elementos para caracterizar a oportunidade.

Figura 4.4 Elementos para a especificação de oportunidade (Baxter, 1998)

Para desenvolver a idéia do produto, como base inicial para os pro-


cessos de planejamento do projeto (project) e processo de projeto, deve-se
focalizar meios apropriados para entender o mercado e suas necessidades
potenciais, bem como estudar as tecnologias potenciais para o desenvolvi-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 168 — #196


i i

168 Projeto Integrado de Produtos: planejamento, concepção e modelagem

mento. O estudo do mercado envolve determinar, por exemplo, qual será


o preço meta, o volume de produção, a posição e o segmento ocupados
no mercado, entre outros. Essas informações caracterizam a perspectiva
comercial da idéia do produto. Já o estudo da tecnologia envolve o co-
nhecimento necessário para o desenvolvimento do produto, em termos de
seus princípios de operação, domínio da tecnologia, capacidade de pro-
dução, vida da tecnologia e grau de inovação. Assim, pode-se dizer que
a fase do planejamento do produto, em termos operacionais, consiste em
atividades, métodos e ferramentas, devidamente sistematizados, destina-
dos a auxiliar a equipe de desenvolvimento na busca de informações sobre
os valores dos atributos tecnológicos e de mercado para caracterizar idéias
de produtos.
A busca por novas idéias e tecnologias de produtos não é um processo
simples. Depende, em parte, da capacidade criativa da organização, mas
também de processos e métodos sistemáticos de trabalho. Vários mode-
los têm sido propostos especificando atividades, métodos e ferramentas
para auxiliar nesse processo e são apresentados como abordagens, desde
as mais gerais, como gestão de conhecimentos, inteligência competitiva,
gerenciamento do porta-fólio de produtos e gestão da tecnologia, até aque-
las mais específicas, como métodos de apoio à criatividade. Nas próximas
seções, algumas dessas abordagens serão descritas em seus principais con-
ceitos e estruturas.

4.3 Processo de planejamento de produtos

O objetivo desta seção é discutir os processos e atividades do planeja-


mento de produtos, visando um melhor entendimento dessa fase do de-
senvolvimento e obter subsídios para entender o uso de métodos e ferra-
mentas de apoio ao planejamento, os quais serão apresentados nas próxi-
mas seções.
Segundo Roozenburg e Eekels (1995), o planejamento do produto se dá
na fase inicial do processo de inovação, que é, de forma abrangente, o de-
senvolvimento e a introdução do produto no mercado. No planejamento
do produto decide-se quando e quais produtos serão desenvolvidos. Em
algumas empresas, emprega-se o termo “mix de produtos” para represen-
tar o conjunto de produtos potenciais para determinado período.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 169 — #197


i i

Planejamento de produtos 169

Sidén, Lindström e Pauli (2000) estabelecem um modelo genérico do


planejamento de produtos, constituído de três componentes principais:
processos, métodos/ferramentas e gerenciamento (Figura 4.5).

Figura 4.5 Modelo genérico de planejamento de produto (adaptado de Sidén,


Lindström e Pauli, 2000)

O processo é o elemento central do modelo, estabelecendo as fases e


atividades que devem ser executadas. É essencial que se promova, no pro-
cesso, um grande fluxo de idéias, as quais deverão ser analisadas com base
em fatos. Outra característica importante do processo é que ele prescreva
maneiras de priorizar as idéias, de forma clara e objetiva. O processo tam-
bém deve conter elementos, visando à alocação de tempo e recursos para o
planejamento da implementação das idéias. Nesse caso, conforme descrito
na introdução, esses elementos referem-se ao planejamento de projetos.
Os métodos e ferramentas são componentes operacionais de suporte
às atividades do processo de planejamento. Cada atividade do processo
de planejamento necessita de entradas, as quais serão transformadas em
saídas adequadas ao desenvolvimento com o apoio de métodos e ferra-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 170 — #198


i i

170 Projeto Integrado de Produtos: planejamento, concepção e modelagem

mentas apropriados. Algumas categorias de métodos para o planejamento


de produtos são: os de geração de idéias, de monitoramento e de extrapo-
lação de tendências.
O terceiro elemento no modelo é o gerenciamento, em que se inserem
as estratégias da organização, a visão do mercado, as competências e a
infra-estrutura necessária. As estratégias, por exemplo, são consideradas
um guia para a geração de idéias e fornecem critérios para a seleção das
mais adequadas. Também incluem-se aqui métodos e ferramentas para
auxiliar na elaboração do plano de produto, em termos de tempo, recursos,
riscos etc.
Planejar o produto consiste essencialmente em pesquisar idéias siste-
maticamente e selecionar aquelas mais promissoras. Inclui atividades para
esclarecer o potencial da empresa, seu mercado e objetivos. Devem ser
investigadas questões como: requisitos sócio-políticos, ambientais, limi-
tes de crescimento, condições econômicas, tecnologias, flutuações do mer-
cado, redução no ciclo de vida dos produtos, previsão de incertezas etc.
(Pahl e Beitz, 1996). Outra atividade é a descoberta de idéias de produ-
tos como o foco do planejamento do produto. São recomendados, nesse
caso, os métodos de criatividade descritos no Capítulo 6, bem como aque-
les apresentados nas seções seguintes. A próxima atividade consiste na
seleção do produto ou de idéias promissoras, visando filtrar o conjunto de
idéias propostas. Na atividade de seleção deve-se efetuar, embora ainda
em nível macro, um estudo da viabilidade técnica e econômica do pro-
duto. Por fim, a atividade de definição do produto envolve a especificação
das características e dos requisitos mais importantes para o produto. Es-
sas definições ou propostas serão submetidas à apreciação da gerência ou
diretoria da empresa para análise e aprovação.
A Figura 4.6 apresenta uma visão do fluxo e das principais informa-
ções do planejamento do produto. De um lado encontra-se a necessidade
de informações do mercado e de outro, a necessidade de conhecer o po-
tencial da empresa. A reunião dessas informações leva à definição de um
campo potencial de busca, a partir do qual devem ser geradas, seleciona-
das e definidas idéias de novos produtos.
O processo de planejamento do produto pode ser estabelecido, em li-
nhas gerais, conforme as atividades e os elementos da Figura 4.7. Ele se
inicia a partir de idéias, algumas das quais já existem e outras que de-
verão ser geradas. As idéias são coletadas e avaliadas, considerando os

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 171 — #199


i i

Planejamento de produtos 171

Figura 4.6 Informações e atividades do planejamento de produtos (adaptado


de Pahl e Beitz, 1996)

Figura 4.7 Principais atividades do processo de planejamento do produto


(adaptado de Schachtner, 1999)

pontos de vista estratégico, econômico e técnico. As melhores idéias serão


selecionadas e agrupadas em projetos de desenvolvimento de produtos,
e a realização do produto começa com a decisão de aprovação de deter-
minado projeto estabelecido. Esses processos devem estar continuamente
associados às estratégias e ao sistema de comunicação da organização.
As fontes de idéias (Figura 4.7) são as mais variadas, como consumido-
res, fornecedores, pessoal da gerência, pessoal de vendas, serviço ao con-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 172 — #200


i i

172 Projeto Integrado de Produtos: planejamento, concepção e modelagem

sumidor, pessoal de marketing, setores de pesquisa e desenvolvimento da


organização. Há a necessidade de estabelecer canais de comunicação bem
definidos entre potenciais fontes de idéias e a equipe de desenvolvimento,
para incentivar e motivar a transmissção de idéias. Recomenda-se o esta-
belecimento de uma central de contato para a coleção de idéias, servindo
de referência para as fontes potenciais.
Para a seleção de idéias, deve-se empregar um processo estruturado
de avaliação, etapa por etapa, por meio do qual pode ser testado o poten-
cial de cada idéia. Nessa fase, podem ser empregados os métodos descri-
tos no Capítulo 9 para a avaliação de soluções alternativas geradas para o
produto. É particularmente importante estabelecer a importância e o sig-
nificado de mercado para determinada idéia, envolvendo, por exemplo,
as vantagens para os consumidores potenciais e as relações com produ-
tos concorrentes. Exemplos de estágios de avaliação e os correspondentes
critérios são mostrados na Tabela 4.3.
Com as idéias selecionadas, na fase final do processo de planejamento
do produto, devem ser definidos os produtos correspondentes e os proje-
tos a serem realizados em dado período. Aqui, as idéias podem ser agru-
padas por segmento de mercado ou categorias de necessidades. Os pro-
jetos sugeridos com base nas idéias selecionadas deverão ser avaliados
considerando-se, por exemplo, os métodos apresentados no Capítulo 3,
tanto do ponto de vista técnico quanto financeiro.

Tabela 4.3 Exemplos de estágios e critérios de avaliação de idéias (Schachtner,


1999)

Estágio Típicos critérios


1˚ estágio Conformidade com as metas estratégicas
• Benefícios ao consumidor
2˚ estágio • Lucratividade potencial
• Potencial de realização eficiente
Priorização em função da situação concreta da organização
3˚ estágio
(recursos disponíveis, por exemplo)
... ...

Conforme a Figura 4.7, tanto na fase de avaliação quanto na de defini-


ção de produto e projeto, deve-se considerar a formação de uma equipe
multidisciplinar, bem como o envolvimento de especialistas de várias
áreas, internos ou externos à organização. Por experiência, recomenda-se

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 173 — #201


i i

Planejamento de produtos 173

que a equipe seja configurada de forma matricial e sob princípios de en-


genharia simultânea, conforme discutido nos Capítulos 2 e 3, procurando
autonomia e agilidade no processo de decisão. Algumas empresas têm
denominado essas equipes “comitê técnico do produto” (Vilarouca, 2004 e
Alves, 2004), sendo este responsável pela avaliação e decisão dos projetos
que serão desenvolvidos em dado período.
Leif (1997) apresenta em maiores detalhes as atividades do processo de
planejamento de produtos (Tabela 4.4). O planejamento de produtos con-
siste em identificar quais tecnologias necessitam ser desenvolvidas e quais
as informações de mercado necessárias para os produtos apresentarem as
características desejadas. No Capítulo 2 isso foi tratado sob a macrofase de
planejamento, inserida nos objetivos do plano de marketing da organiza-
ção.

Tabela 4.4 Atividades do processo de planejamento de produtos (adaptado de


Leif, 1997)

Atividades Objetivos
Levantar a situação atual de produtos da empresa e
concorrentes. Identificar aplicações alternativas ou
segmentos de mercado, bem como seu tamanho.
Análise do
Investigar e descrever os problemas e as deficiências
mercado
relacionados aos produtos da empresa. Avaliar o
potencial e o nível de preço do mercado para produtos e
peças de reposição.
Levantar a situação atual das tecnologias dos produtos e
de produção da empresa e dos concorrentes. Descrever
Análise das
problemas e deficiências relacionados às próprias
tecnologias
tecnologias. Avaliar os potenciais e níveis de preço para
novas tecnologias.
Identificar as necessidades (declaradas e implícitas) e os
desejos dos consumidores. Levantamento das categorias
Análise do
de usuários. Métodos de apoio: benchmarking, QFD (ver
consumidor
Capítulo 5), DoE (ver Capítulo 12), análise conjunta,
questionários, entrevistas.
Analisar os produtos concorrentes e a proteção dos
produtos com relação aos aspectos de projeto,
Análise dos produção, mercado e finanças. Comparar com os
concorrentes produtos da empresa. Investigar e compilar a situação de
patentes na área de produtos. Métodos de apoio:
benchmarking, QFD.
Continua na próxima página

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 174 — #202


i i

174 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 4.4 Atividades do processo de planejamento de produtos (adaptado de


Leif, 1997)

Atividades Objetivos
Identificar os requisitos do mercado e o potencial da
empresa. Utilizar informações sobre os consumidores,
Descrição dos mercado, os próprios produtos da empresa (novos e
requisitos velhos), produtos concorrentes, patentes, requisitos
específicos em diferentes mercados, legislação e
normas.
Integração dos Avaliar a possibilidade de integrar novos conhecimentos
conhecimentos àqueles existentes (na forma de sistemas e componentes).
Avaliar as idéias de mudanças que tenham sido propostas
quanto às metas especificadas para o projeto e às metas
Avaliação das
e estratégias gerais da empresa. É importante avaliar a
idéias de produtos
influência das idéias na lucratividade de todo o ciclo de
vida.
Estimar o valor Fazer uma avaliação inicial do valor do produto para o
para o consumidor consumidor.
Calcular a lucratividade para a empresa. Calcular os
custos variáveis e fixos associados ao produto, preço e
Avaliação da
volume esperados de venda. Avaliar o potencial para a
viabilidade
realização comercial e financeira. Fazer uma análise de
sensibilidade para o cálculo da lucratividade.
Atualização Analisar como o produto se enquadra no porta-fólio da
do plano empresa. É um produto certo no tempo certo? Sugerir
do produto alternativas e estimar o número de itens necessários.
Levantar e avaliar os efeitos das idéias sugeridas com
Avaliação da relação ao suporte pós-venda, na forma de informações,
pós-venda treinamento, equipamentos, serviços, peças de
reposição, acessórios etc.
Mensagem
Planejar o lançamento e a embalagem de marketing.
do produto
Investigar as conseqüências e mercados potenciais das
Vendas do produto
propostas lançadas.
Necessidade de Investigar a necessidade de variantes e grupos de
variantes módulos adequados.
Análise de Fazer uma descrição (incluindo avaliação de preço) do
mercado serviço requerido e de níveis de montagem que as peças
pós-venda de reposição deverão ter.
Continua na próxima página

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 175 — #203


i i

Planejamento de produtos 175

Tabela 4.4 Atividades do processo de planejamento de produtos (adaptado de


Leif, 1997)

Atividades Objetivos
Estimar o valor do consumidor, isto é, quanto o consumidor
pode economizar com a utilização do produto. Deve-se
Cálculo do valor dar atenção aos custos totais do produto, incluindo custos
para o consumidor de instalação, de operação e de serviços. O custo total
do ciclo de vida do produto também deve ser
considerado.
Recomendação
Compilar as recomendações e decisões para resumir as
de
propostas de produtos e suas possibilidades de realização.
viabilidade
Avaliação do
Investigar alternativas de preço e de vendas.
preço
Avaliação da
Avaliar a lucratividade, o lucro e os efeitos no emprego.
lucratividade
Encerramento do Compilar os custos de planejamento. Verificar metas e
planejamento requisitos.
Apresentação do
Informar os resultados do planejamento e obter a
plano para
aprovação do plano.
aprovação

Com base nas atividades da Tabela 4.4, os resultados típicos do plane-


jamento do produto são: descrição dos desejos da empresa em um período
previsível para satisfazer seus negócios, estratégias e metas; avaliação das
necessidades dos consumidores; quais tecnologias devem ser desenvolvi-
das; o que os concorrentes farão; quais mercados poderão ser abertos; e
os requisitos para o desenvolvimento de novos produtos, tanto técnicos
como econômicos.

4.4 Metodologias gerais de apoio ao


planejamento de produtos

O planejamento de produtos é um processo multidisciplinar e abran-


gente que requer informações e conhecimentos de várias áreas, sejam in-
ternos ou externos à organização. É um processo criativo e ao mesmo
tempo sistemático para a geração e seleção de idéias, respectivamente.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 176 — #204


i i

176 Projeto Integrado de Produtos: planejamento, concepção e modelagem

O planejamento do produto é fortemente relacionado ao conhecimento


e à capacidadeda da organização de transformar esse conhecimento. O
planejamento também depende, na mesma intensidade, dos canais de co-
municação entre fontes potenciais de idéias e tecnologias e a equipe de
desenvolvimento. Nesse sentido, algumas abordagens gerais tratam do
modo como esses elementos podem ser empregados para apoiar o pla-
nejamento de produtos através de seus princípios e melhores práticas.

4.4.1 Gestão do conhecimento

A gestão do conhecimento (GC) pode ser vista sob diferentes enfoques.


De maneira abrangente, compreende a gestão de todos os processos e re-
cursos da organização para o desenvolvimento de seu negócio. De forma
mais específica, ela consiste em princípios, processos, métodos para auxi-
liar na identificação, geração e seleção de idéias de produtos promissores.
A gestão do conhecimento é uma disciplina que vem sendo largamente
estudada e estruturada de forma a suportar amplamente os processos da
organização. Aqui se observará essa disciplina no aspecto dos processos e
atividades do planejamento de produtos.
Nas atuais organizações do conhecimento, o principal fator de produ-
ção é o conhecimento das pessoas, e não apenas os recursos físicos. Nes-
sas organizações, o diferencial competitivo está na maneira de executar as
atividades e, portanto, na experiência dos colaboradores internos. No pla-
nejamento de produtos, tendo em vista a natureza qualitativa das infor-
mações e sua incipiência nas fases iniciais do desenvolvimento, bem como
a necessidade de tomar decisões importantes sobre o desenvolvimento de
um produto, o fator conhecimento se torna preponderante para o sucesso
da empresa.
Com o objetivo de otimizar o uso dos recursos, é importante que todo
aprendizado gerado seja documentado na forma de melhores práticas e
experiências, para que a equipe de desenvolvimento possa aprender com
as experiências passadas, evitando, assim, cometer erros em decisões fu-
turas similares às documentadas.
O conhecimento é dividido na dimensão tácita (informal) e explícita
(formal, documentada). Nonaka e Takeuchi (1997) afirmam que o conhe-
cimento expresso em palavras e números (formalizados) é uma represen-
tação empobrecida do conhecimento tácito existente na mente humana.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 177 — #205


i i

Planejamento de produtos 177

Quanto à conversão do conhecimento entre as duas dimensões anterior-


mente citadas, a mesma referência apresenta quatro processos: socializa-
ção (tácito para tácito – conversas); externalização (tácito para explícito –
escrita); combinação (explícito para explícito – reuniões); e internalização
(explícito para tácito – leitura). Na prática, Santos (2003) considera que a
GC engloba as seguintes etapas:
• identificar e mapear os ativos intelectuais ligados à organização (es-
trutura externa – clientes e fornecedores; estrutura interna – concei-
tos, patentes, modelos, normas e equipamentos da empresa; e a com-
petência dos funcionários);
• gerar novos conhecimentos para oferecer vantagens competitivas no
mercado;
• tornar acessíveis grandes quantidades de informações corporativas,
compartilhando as melhores práticas e as tecnologias envolvidas, in-
cluindo groupware (equipes) e intranet (redes internas), prática que
deveria se tornar parte da maioria dos negócios.
Observa-se, portanto, que os objetivos dessas etapas estão bastante ali-
nhados com os objetivos e atividades do planejamento de produtos. Trata-
se da busca do conhecimento da empresa e do mercado e sua capacidade
para o desenvolvimento de novos produtos. Também envolve maneiras de
obter informações sobre tecnologias de produtos como fator-chave para o
desenvolvimento de novas idéias. A Figura 4.8 relaciona alguns elemen-
tos da GC com o planejamento de produtos, dando ênfase às competências
necessárias e ao registro dos conhecimentos gerados para reutilização fu-
tura.

4.4.2 Inteligência competitiva

A inteligência competitiva pode ser entendida como processos essen-


ciais de uma organização, os quais devem ser continuamente executados
para alimentar novos negócios. De certa forma são processos também re-
lacionados ao gerenciamento estratégico da organização, como a própria
gestão do conhecimento.
O processo de inteligência competitiva, proposto por Kahaner (1996),
consiste em quatro etapas (Figura 4.9): planejamento e decisão, coleta de
informações, análise e disseminação de informações.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 178 — #206


i i

178 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 4.8 Elementos da GC relacionados ao planejamento de produtos


(adaptado de Montanha, 2004)

Figura 4.9 Processo de inteligência competitiva (Kahaner, 1996)

Na etapa de planejamento e decisão é necessária a compreensão clara


das necessidades dos usuários. Essa compreensão pode ser conseguida
através da proximidade com as pessoas que necessitam dos resultados do
processo de inteligência competitiva. É nesse momento que se elabora o
plano de coleta e análise de informações sobre os concorrentes.
A coleta consiste na obtenção de informações relevantes, considerando
características das fontes de informação como o tipo (de domínio público
ou não, principais ou secundárias), o prazo de obtenção (imediato, médio
ou longo), a dificuldade de obtenção (fácil ou difícil), a confiabilidade e
outros fatores. As fontes são as mais diversas: exposições, patentes, expec-
tativas, imprensa, internet, relatórios governamentais e de associações.
A etapa de análise é considerada a mais difícil e criativa porque con-
siste na transformação da informação coletada em inteligência competi-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 179 — #207


i i

Planejamento de produtos 179

tiva para a organização. Espera-se da análise a determinação do que acon-


tecerá, quando acontecerá e o que isso significa para a empresa. Alguns
possíveis caminhos para essa análise são:

• análise SWOT (Strengths, Weaknesses, Opportunities and Threats), pon-


tos fortes, pontos fracos, oportunidades e ameaças do concorrente,
ou seja, colocar-se na posição do concorrente;
• análise da missão, visão, objetivos do concorrente e sua evolução ao
longo do tempo;
• obtenção de análises e opiniões de analistas independentes;
• estudo da posição acionária do concorrente;
• análise da personalidade dos dirigentes da concorrência; e
• elaboração de cenários e simulações.

A disseminação dos resultados do processo deve ser contínua e di-


recionada a todos os possíveis interessados. Nota-se que esses caminhos
aplicam-se igualmente ao planejamento de produtos, pois envolvem en-
tendimento do mercado, coleta de idéias de produtos promissores, análise
das idéias e disseminação destas pela organização na forma de potenciais
projetos de desenvolvimento de produtos.

4.4.3 Gestão da inovação de produtos

O modelo conceitual de inovação, segundo o COTEC (1998), possui os


elementos mostrados na Figura 4.10, sendo que o processo de inovação
pode começar em qualquer elemento relacionado.
Em linhas gerais, o monitoramento consiste em entender a natureza
das ameaças e oportunidades que operam no ambiente onde a empresa
atua com seus produtos por meio do monitoramento e da interpretação de
sinais que sugiram mudanças potenciais no processo inovativo. As melho-
res oportunidades devem ser, então, selecionadas a partir daquelas iden-
tificadas, segundo as estratégias da empresa.
A focalização visa selecionar de forma estratégica os recursos que a
organização poderá alocar no processo inovativo a partir de alguns “gati-
lhos” potenciais de inovação que, em muitos casos, são as próprias idéias
e/ou tecnologias identificadas pelo monitoramento. Por isso, é uma ativi-
dade essencial para as tomadas de decisão estratégicas da empresa.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 180 — #208


i i

180 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 4.10 Elementos-chave do processo de inovação tecnológica (adaptado


de COTEC, 1998)

Na fase de alocação, os recursos previstos na focalização são efetiva-


mente comprometidos no processo de inovação, em que a combinação do
conhecimento externo com o existente na empresa é utilizada para solu-
cionar problemas relativos à inovação. Isso pode ocorrer por meio do de-
senvolvimento interno ou da aquisição de conhecimento e/ou tecnologias
necessários ao referido processo.
A implementação é o núcleo do processo de inovação. As entradas
desse processo são o claro conceito de estratégia, juntamente com algumas
idéias iniciais para realizar seu plano. Suas saídas são a inovação desen-
volvida (implementada) e a escolha definitiva do mercado, pronto para o
lançamento do produto ou processo.
A fase de aprendizado tem como objetivo realizar uma revisão com
posterior reflexão a partir das experiências de sucesso e fracasso vivenci-
adas ao longo de todo o processo. Com isso, as entidades envolvidas com
o processo inovativo podem aprender sobre a melhor maneira de geren-
ciar tal processo. Em linhas gerais, o aprendizado consiste no desenvol-
vimento de conhecimento e capacidade aperfeiçoados, para realizar ati-
vidades, e pode acontecer das seguintes formas: (I) desenvolvimento de
capacidade técnica aperfeiçoada; e (II) desenvolvimento de um processo
de gestão mais eficaz do processo de mudança tecnológica.
Observa-se que os elementos do modelo de inovação da Figura 4.10
estão diretamente relacionados a objetivos, processos e atividades do pla-
nejamento de produtos, principalmente com relação à definição das tec-
nologias associadas às idéias de novos produtos. Esses elementos são, em
grande parte, desdobrados na forma de atividades, conforme descrito no
item 4.3.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 181 — #209


i i

Planejamento de produtos 181

4.5 Métodos e ferramentas de apoio ao


planejamento de produtos

Considerando-se tanto as atividades do processo de planejamento de


produtos (Tabela 4.4) como as metodologias gerais de apoio ao planeja-
mento, vários métodos e ferramentas podem ser prescritos. Muitos desses
métodos e ferramentas também são empregados em outras fases do de-
senvolvimento de produtos, tais como planejamento do projeto, projeto
informacional e conceitual. Nessa seção será dada ênfase aos métodos e
ferramentas orientados para a geração de idéias e gerenciamento da tec-
nologia.

4.5.1 Métodos e ferramentas para a geração de idéias


de produtos

Na geração de idéias para o produto, as oportunidades serão descri-


tas em termos técnicos e de marketing. É um processo criativo, em grande
parte, mas também de coleta e classificação de idéias existentes. As em-
presas japonesas, segundo Burr (1989), por exemplo, dedicam boa parte
de seus estudos à fase de planejamento, visando entendimento preciso
das demandas do mercado e geração de idéias para satisfazer essas de-
mandas. As empresas empregam métodos simples e práticos de apoio à
geração de idéias, entre os quais se inclui a matriz de tecnologias versus
necessidades, por exemplo (Figura 4.11).
As tecnologias, segundo Burr (1989), devem ser constantemente pes-
quisadas e disseminadas na empresa. Algumas empresas, por exemplo,
possuem departamentos com o propósito de controlar o fluxo de infor-
mações sobre tecnologias na organização entre seus laboratórios de pes-
quisa e os setores de desenvolvimento de produtos. As principais ativi-
dades desses departamentos são: levar adiante temas de projeto para os
laboratórios de pesquisa, promover conferências técnicas na organização,
sugerir políticas gerais de pesquisa, formular estratégias e organizar as
tecnologias disponíveis.
Outro método de apoio à geração de idéias é o método de análise do
estilo de vida (Burr, 1989), também conhecido como clipagem (Montanha,
2004). Trata-se de um método de coleta e organização de informações so-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 182 — #210


i i

182 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 4.11 Matriz de necessidades versus tecnologias (adaptado de Burr, 1989)

bre o estilo de vida das pessoas com base num sistema de referência (Fi-
gura 4.12). O sistema de referência é constituído por palavras-chave que
expressam situações possíveis do dia-a-dia das pessoas. Os principais pas-
sos para o uso desse método são:
1. Descrever as características do estilo de vida das pessoas, empregan-
do-se palavras-chave (e suas inversas) como referência. Por exemplo,
quente (frio) e ativo (passivo);
2. Coletar reportagens, fotografias, ilustrações, entre outras informa-
ções, e arranjá-las de acordo com as palavras-chave;
3. Organizar o estilo de vida, expressando-o em palavras e por catego-
rias: homem/mulher/crianças/jovens/idosos, por exemplo;
4. Descrever, em cada mapa, cenas de situações características do estilo
de vida das pessoas;
5. Esquematizar idéias de produtos para cada cena, selecionando os
melhores exemplos uma por uma;
6. Apresentar as idéias desenvolvidas na forma de mapas, com o obje-
tivo de escolher as situações potenciais de novos produtos.
Outro método bastante simples e prático empregado por empresas ja-
ponesas, segundo Burr (1989), é chamado de Key-Needs (Figura 4.13). Con-
siste em sete etapas com os seguintes propósitos:

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 183 — #211


i i

Planejamento de produtos 183

Figura 4.12 Resultados típicos do método de análise do estilo de vida


(adaptado de Burr, 1989)

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 184 — #212


i i

184 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 4.13 Resultados típicos do método Key-needs (adaptado de Burr, 1989)

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 185 — #213


i i

Planejamento de produtos 185

• Etapa 1 – Palavras-chave: descrever os campos de pesquisa (basea-


dos na política da empresa) em sentenças do tipo: “coisas que se
deseja, mas não se pode fazer”;
• Etapa 2 – Geração de problemas: sugerir problemas que se relacio-
nem às palavras-chave. Procurar descrever vários problemas para
cada palavra-chave;
• Etapa 3 – Sugestão de razões: sugerir, para cada problema, as razões
que dificultam sua solução;
• Etapa 4 – Transformar razões em soluções: descrever pelo menos
duas soluções para cada razão em cartões separados;
• Etapa 5 – Geração de idéias: em uma planilha no centro, descrever
o tema e as necessidades básicas. Tomar de forma aleatória os car-
tões com as soluções descritas na etapa anterior e discutir possíveis
relações com o tema. Escrever novos cartões de idéias concretas de
produtos comerciais e descrevê-los em forma de etiquetas;
• Etapa 6 – Combinação de idéias: combinar duas a três idéias (de be-
nefícios similares ou combinações forçadas) em idéias mais atrativas.
Descrever desejos ou imagens associadas às novas idéias;
• Etapa 7 – Definir conceito: selecionar conceitos atrativos e descrevê-
los em formulário apropriado.

4.5.2 Métodos e ferramentas de apoio à gestão da


tecnologia de produtos

Segundo Porter et al. (1991), os métodos de apoio à gestão da tecno-


logia podem ser classificados em cinco famílias: métodos para monitora-
mento; métodos baseados na opinião de especialistas; método de extra-
polação de tendências; método de modelagem e métodos baseados em
cenários.
Entre os métodos de monitoramento, incluem-se a vigilância tecnoló-
gica e a bibliometria, por exemplo. A vigilância tecnológica consiste na
observação de um espectro amplo de informações para identificar eventos
no ambiente da empresa que possam ser relevantes para a mesma (esqua-
driamento ambiental). As atividades de esquadrinhamento ambiental são
particularmente úteis para identificar produtos e processos emergentes, os
quais podem oferecer ameaças ou vantagens mercadológicas, e para iden-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 186 — #214


i i

186 Projeto Integrado de Produtos: planejamento, concepção e modelagem

tificar novos usos para tecnologias atuais ou em desenvolvimento. Exis-


tem outras formas de vigilância; a mais focalizada entre elas é o monitora-
mento tecnológico, proposto para desenvolvimentos técnicos específicos
que foram identificados através do esquadrinhamento e do rastreamento,
que envolve um esforço concentrado no sentido de acompanhar os de-
senvolvimentos de maior importância para a empresa, como a potencial
resposta competitiva ao lançamento de um novo produto ou a introdução
de um novo produto por um concorrente.
A bibliometria baseia-se na análise de patentes e na análise de publi-
cações científicas. O objetivo é medir e interpretar avanços tecnológicos
utilizando como base a quantidade de patentes, publicações científicas ou
citações disponíveis. A análise de patentes provê informações referentes
às tendências tecnológicas e aos produtores de inovações. Os resultados
desse tipo de análise podem levar a previsões mercadológicas antecipa-
das de 6 a 18 meses. O processo de análise de patentes tem as seguintes
etapas: I) definição dos objetivos da análise; II) definição do domínio do
problema; III) obtenção das patentes relevantes; e IV) análise e interpreta-
ção dos resultados.
Os métodos baseados na opinião de especialistas servem para coletar
e organizar informações e conhecimentos especializados de determinado
domínio. São métodos especialmente importantes quando não há dados
históricos disponíveis, mas há forte influência de fatores éticos, morais ou
políticos e necessidade de analisar temas complexos e com grande incer-
teza envolvida. Tais métodos compreendem desde procedimentos simples
e corriqueiros, como entrevistas e aplicações de questionários, a métodos
mais sofisticados, como o Delphi (ver item 6.2.2), métodos para a geração
de idéias e o método dos grupos nominais.
Nas entrevistas, obtêm-se opiniões aprofundadas de especialistas com
relação aos tópicos de interesse do planejamento. Nesse sentido, é impor-
tante que sejam adequadamente planejadas, de forma a abordar os assun-
tos de real interesse. São preferíveis as entrevistas pessoais às por telefone.
A aplicação de questionários é um método similar à entrevista, com a di-
ferença de que é mais estruturado. Tal estruturação pode ser boa para a
padronização e tabulação dos resultados, mas pode prejudicar e direcio-
nar os resultados.
Os métodos de análise de tendências consistem em coletar dados his-
tóricos referentes a determinados parâmetros e, com base nestes dados,

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 187 — #215


i i

Planejamento de produtos 187

projetar tendências. Na extrapolação de tendências, uma curva de melhor


ajuste é obtida com base em dados históricos referentes a certo parâmetro.
A partir dessa curva, é previsto o desempenho futuro do parâmetro.
As curvas S podem ser utilizadas para prever quando uma dada tecno-
logia atingirá seu limite, sob determinados parâmetros. O desempenho de
dado parâmetro descreve, em função do tempo, uma trajetória em forma
de S (Figura 4.14). Os parâmetros técnicos têm limites, em função de leis
físicas, por exemplo. Inicialmente, seu desempenho é lento, aumentando
progressivamente com o desenvolvimento da tecnologia, até atingir certos
limites. O limite X (tempo t3 ) é aquele que pode ser alcançado, em relação
à nova tecnologia, com maiores investimentos no desenvolvimento. Já o
limite Y (tempo t2 ) é aquele alcançado com a mesma taxa de investimento.
Por fim, o limite Z (tempo t3 ) é aquele obtido com investimento reduzido.
A mudança para uma nova tecnologia significa a mudança para uma nova
curva S (Tecnologia 2), a qual poderá apresentar maiores limites de desem-
penho dos parâmetros ao longo do tempo.

Figura 4.14 Curva S (adaptado de Burgelman e Maidique, 1988)

A analogia histórica consiste no estudo de dados históricos de outras


empresas, concorrentes ou não, com a finalidade de prever resultados fu-
turos a partir dos resultados passados. Uma forma utilizada para a obten-
ção dos dados se dá por meio de organizações que administram bancos de

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 188 — #216


i i

188 Projeto Integrado de Produtos: planejamento, concepção e modelagem

dados de informações históricas de empresas associadas, fornecidas pelas


próprias empresas. A analogia histórica, da qual a análise da curva S pode
ser considerada um caso particular, pode permitir previsões qualitativas.
Em geral, os métodos propostos consideram os eventos ou tendên-
cias de forma independente, ou seja, não levam em conta as relações entre
eles ou os impactos mútuos. Um dos métodos que podem ser empregados
nesse caso é o de análise de impacto cruzado. Esse método se inicia com
a reunião da equipe de planejamento para gerar uma lista de temas (ten-
dências e possíveis eventos futuros). Em uma matriz (Figura 4.15), cada
tema é listado nas linhas e colunas, buscando-se nos cruzamentos os pos-
síveis impactos entre os fatores envolvidos. A escala de impacto pode ser
A para alto, M para médio, B para baixo e 0 para nenhum, com qualifica-
dores + para positivo e - para negativo. Na Figura 4.15, pode-se ilustrar a
primeira linha com as questões: “Qual é o impacto da redução da mão-de-
obra no custo do trabalho? E no investimento de capital? E na tecnologia
robótica?”. No exemplo da figura, é possível interpretar que a redução
da mão-de-obra, influenciando a elevação do custo do trabalho e maior
investimento de capital, conduziria a maiores investimentos no desenvol-
vimento da tecnologia robótica.

Figura 4.15 Exemplo de uma matriz de impacto cruzado (Twiss, 1992)

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 189 — #217


i i

Planejamento de produtos 189

Os métodos baseados em cenários têm o propósito de buscar a previ-


são de múltiplas possibilidades que podem vir a realizar-se. A pergunta
“como será o futuro?” é substituída por: “quais são os possíveis futuros?”,
“qual dos possíveis futuros é preferível?” e “sob que condições ocorrerá o
futuro preferido?”. Das alternativas vêm as previsões, e destas, as estraté-
gias (Millet e Honton, 1991).
Os cenários permitem a integração de informações de diversas fontes e
tipos numa única previsão. Os resultados de uma extrapolação de tendên-
cias e opiniões de especialistas, por exemplo, podem fornecer subsídios
para a criação de cenários, e estes podem ser uma forma interessante de
integrar resultados de previsões obtidas por outros meios.
O mapeamento tecnológico, como método baseado em cenários, desti-
na-se a suportar o planejamento e gerenciamento da tecnologia, especial-
mente pela exploração e comunicação das relações entre os recursos tec-
nológicos, objetivos organizacionais e mudanças no ambiente.
A abordagem mais comum, segundo Phaal, Farrukh e Probert (2004), é
ilustrada na Figura 4.16. Ela consiste em um mapa referenciado no tempo
com camadas ou categorias de informações de diferentes perspectivas. No
exemplo, as categorias de informações tratam do mercado, produto e tec-
nologia.

Figura 4.16 Esquema típico de um mapa tecnológico (Phaal, Farrukh e Probert,


2004)

Uma característica particular do conceito de mapeamento tecnológico


é o uso de uma estrutura de trabalho baseada no tempo, de forma gráfica,
para desenvolver, representar e comunicar planos estratégicos, em termos
da evolução e desenvolvimento da tecnologia, produtos e mercados.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 190 — #218


i i

190 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Existem vários tipos de mapas tecnológicos, dependendo da necessi-


dade (Figura 4.17). Particularmente para o planejamento de produtos (Fi-
gura 4.17a), tem-se uma maneira de avaliar a inserção de tecnologias nos
produtos da organização. Trata-se da representação do relacionamento en-
tre as tecnologias planejadas, ao longo do tempo, com os produtos sendo
desenvolvidos ou planejados para o futuro. No caso da Figura 4.17b, tem-
se um mapa do planejamento do processo, que suporta o gerenciamento
do conhecimento focalizando em um processo particular (por exemplo,
o desenvolvimento de um novo produto). Procura-se mostrar o fluxo de
conhecimento necessário para facilitar o desenvolvimento do produto, in-
corporando as perspectivas técnica e comercial. Na Figura 4.17c, tem-se
um mapa de planejamento de longo prazo, como forma de representar
mercados e novas tecnologias ao longo de uma ampla faixa de tempo.
Busca-se, com esse mapeamento, mostrar como o desenvolvimento tec-
nológico poderá convergir no futuro. Na Figura 4.17d, tem-se um mapa
do planejamento da integração, em que o objetivo é mostrar a evolução da
tecnologia do produto e sua combinação com os demais sistemas.

Figura 4.17 Exemplos típicos de mapas tecnológicos (adaptado de Phaal,


Farrukh e Probert, 2004)

A execução de um mapeamento tecnológico se dá em etapas, na forma


de workshops ou reuniões de trabalho, nas quais as camadas ou catego-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 191 — #219


i i

Planejamento de produtos 191

rias de informações do mapa são sucessivamente preenchidas. Na Figura


4.18a, tem-se um exemplo das reuniões típicas que devem ser conduzidas
na elaboração de um mapeamento tecnológico e, na Figura 4.18b, mostra-
se como ocorre o fluxo de informações para a criação de mapas tecnoló-
gicos. Ao final, desenvolvem-se as relações entre as informações, procu-
rando estabelecer base para a tomada de decisão sobre o desenvolvimento
de produtos. Típicos resultados e um mapeamento tecnológico são mos-
trados na Figura 4.2.

Figura 4.18 Esquema geral de execução de um mapa tecnológico (adaptado


de Phaal, Farrukh e Probert, 2004)

A análise de porta-fólio também pode ser entendida como um mé-


todo baseado em cenários, servindo para visualização e comunicação. Um

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 192 — #220


i i

192 Projeto Integrado de Produtos: planejamento, concepção e modelagem

exemplo é a matriz mostrada na Figura 4.19, na qual as categorias de “risco


financeiro” e “desenvolvimento do mercado” são utilizadas para classifi-
car os produtos de uma empresa em:

• “aposta segura”: produtos de baixo investimento, em mercados


emergentes;
• “carro-chefe do futuro”: produtos com alto investimento, em merca-
dos emergentes;
• “linha principal”: produtos com alto investimento em mercados ma-
duros;
• “em declínio”: produtos com pequeno investimento em mercados
maduros.

Tanto a escolha das características a serem utilizadas nas matrizes


como a ordenação das mesmas são definições arbitrárias. O porta-fólio
pode ser utilizado para antecipar aspectos financeiros de produtos e tec-
nologias, mas não para prever o desempenho tecnológico dos mesmos.

Figura 4.19 Matriz de análise de porta-fólio tecnológico (adaptado de Millet e


Honton, 1991)

4.6 Organização e infra-estrutura para a


inovação

Além do uso de métodos apropriados para o planejamento de pro-


dutos, a empresa precisa estar preparada para conduzir o processo. Uma
empresa inovadora em tecnologias de produtos e processos produtivos,
segundo a OECD (1998), é aquela que implementa produtos, processos

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 193 — #221


i i

Planejamento de produtos 193

(ou a combinação destes) com características tecnologicamente novas ou


significativamente aperfeiçoadas. Tais empresas apresentam duas caracte-
rísticas principais:

• habilidades estratégicas: identificação e antecipação das tendências


de mercado de forma adequada e utilização das informações tecno-
lógicas obtidas;
• habilidades organizacionais: cooperação interna entre os departa-
mentos e cooperação externa com parceiros, que podem ser clientes,
fornecedores, distribuidores comerciais, consultores, entre outros.

Diante das habilidades citadas, tais empresas devem utilizar formas


de geração de novos conhecimentos relevantes para o processo inovativo:

• atividades de pesquisa e desenvolvimento interno, através de expe-


rimentos;
• aquisição de tecnologias e conhecimentos externos;
• aquisição de tecnologias embutidas em equipamentos, métodos, fer-
ramentas computacionais, entre outras formas.

Para facilitar a implementação do processo inovativo devem ser consi-


derados alguns elementos relacionados à inovação, os quais são sugeridos
pelo Manual de Oslo (OECD, 1998) (Figura 4.20). Tais elementos são: con-
dições estruturais da organização; estrutura de pesquisa; fatores de trans-
ferência; e dinâmica da inovação.
Como condições estruturais, são citadas as seguintes:

• um sistema educacional que garanta um padrão mínimo de capaci-


tação da equipe de trabalho em relação às tarefas a serem realizadas;
• existência de uma infra-estrutura de comunicação adequada ao pro-
cesso inovativo, em termos de estradas, telefone, comunicação vi-
sual, eletrônica, entre outras;
• existência de instituições financeiras que permitam o acesso ao capi-
tal necessário ao processo;
• infra-estrutura jurídica que forneça apoio em termos de informações
sobre patentes, leis, taxas, políticas governamentais, normas, entre
outras;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 194 — #222


i i

194 Projeto Integrado de Produtos: planejamento, concepção e modelagem

• vias de acesso direto ao mercado consumidor (diálogo com os clien-


tes);
• existência de estrutura industrial e parcerias que favoreçam a intro-
dução de inovações.

Figura 4.20 Elementos relacionados à inovação (adaptado de OECD, 1998)

A estrutura de pesquisa é apoiada pelas fontes de geração de novos co-


nhecimentos para a inovação, citadas anteriormente. Tal estrutura é com-
posta pelos seguintes elementos:

• sistema especializado de capacitação técnica;


• universidades;
• sistema de apoio à pesquisa básica;
• atividades de P&D direcionadas às atividades da sociedade;
• atividades estratégicas de P&D;
• apoio de parceiros tecnológicos em áreas de pouco domínio tecnoló-
gico e grande risco para a empresa.

Os elementos de transferência são aqueles que influenciam a trans-


missão de informações e aprendizado da empresa e são cruciais para a
implementação da inovação na prática industrial:

• parcerias formais e informais entre parceiros, considerando grupos


de empresas, clientes, fornecedores e instituições de pesquisa;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 195 — #223


i i

Planejamento de produtos 195

• presença de especialistas experientes nas tecnologias pretendidas,


diminuindo o risco de insucesso da implementação das tecnologias;
• parcerias internacionais com especialistas/consultores externos da
área tecnológica pretendida;
• aumento do grau de autonomia dos especialistas envolvidos com o
processo de inovação, para acelerar o processo;
• facilitação do acesso da indústria às informações tecnológicas de do-
mínio público, tais como patentes, normas, legislações etc.;
• documentação das experiências dos profissionais envolvidos no pro-
cesso inovativo, para facilitar a difusão do conhecimento tecnoló-
gico;
• consideração dos aspectos relativos a ética, valores e filosofia de tra-
balho da comunidade, rede de colaboradores, para não prejudicar a
comunicação entre as pessoas.

Quanto aos elementos da dinâmica da inovação, tem-se:

• estratégia, em termos de definição de objetivos para o processo ino-


vativo;
• forma de atuação dos setores encarregados de realizar atividades de
P&D;
• fatores não relacionados diretamente a P&D, como informações de
vendas.

Considerando que os processos de inovação geralmente exigem signi-


ficativos investimentos em termos de recursos financeiros, além dos de-
mais recursos, a OECD (1998) sugere algumas fontes de financiamento:

• fundos próprios da empresa;


• fundos de empresas pertencentes ao mesmo grupo ou corporação;
• fundos de empresas de outros ramos de negócio, mas que estão en-
volvidas com o processo de inovação (parceiras);
• fundos derivados de incentivos das entidades governamentais;
• fundos oriundos de organizações internacionais ou nacionais, tais
como União Européia, Mercosul etc.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 196 — #224


i i

196 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Segundo Kelley e Littman (2001), as seguintes recomendações devem


ser seguidas para o processo de inovação:

• ser visionário (os clientes podem ter boa vontade ao responder aos
questionários, mas não têm a obrigação de ser visionários);
• criar listas de bugs e listas de “porque sim” e “porque não”, para
identificar problemas e avaliar possibilidades de melhorias em pro-
dutos existentes;
• imergir no ambiente dos clientes (colocar-se na situação dos clientes,
para criar empatia);
• localizar necessidades não satisfeitas e tendências;
• prestar atenção a grupos com necessidades específicas (crianças, ido-
sos, deficientes etc.);
• envolver pessoal de diversas áreas e com diversas formações e expe-
riências no processo de observação;
• identificar e observar pessoas que usam o produto de formas dife-
rentes e para finalidades diferentes;
• considerar o lado humano do produto (aquilo que ele irá proporcio-
nar ao cliente em termos emocionais);
• observar o todo da experiência de uso do produto (ver os produtos
como verbos, em movimento);
• perceber as inovações que serão aceitas pelos usuários e as que terão
de esperar ou ser introduzidas de forma gradativa;
• Fazer polinização cruzada, reaproveitando boas soluções de outros
produtos, com tecnologias similares ou não.

4.7 Avaliação do impacto da tecnologia

A avaliação do impacto da tecnologia, como parte do processo de pla-


nejamento de produtos, consiste no estudo sistemático dos efeitos da in-
trodução, extensão ou modificação de uma tecnologia em outras tecno-
logias e na sociedade. Em uma análise de impacto da tecnologia, deve ser
dada ênfase aos efeitos não-intencionais, indiretos e retardados (Carvalho,
2002).

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 197 — #225


i i

Planejamento de produtos 197

Tecnologias não existem isoladamente. Nenhuma tecnologia é inde-


pendente de influências externas, e cada uma delas pode afetar uma tec-
nologia de diferentes formas. De acordo com Twiss (1992), tais influên-
cias podem ser genericamente classificadas como forças políticas e legais,
econômicas, sociais e tecnológicas (Figura 4.21). Essas forças atuam entre
si e sobre a empresa.

Figura 4.21 Ambiente da empresa e suas relações (Twiss, 1992)

Por exemplo, a tendência social de urbanização tem influências signi-


ficativas na indústria de transportes, exigindo sistemas de transporte co-
letivo mais eficientes. Os índices de criminalidade crescentes influenciam
decisivamente a indústria de segurança.
A tecnologia também afeta a própria tecnologia. Um exemplo disso
vem da informática: as empresas fabricantes de hardware desenvolvem má-
quinas cada vez mais rápidas e de maior capacidade, que permitem a cri-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 198 — #226


i i

198 Projeto Integrado de Produtos: planejamento, concepção e modelagem

ação de novas características no software, as quais, por sua vez, exigirão


novas melhorias de desempenho do hardware.
A análise do impacto da tecnologia serve para subsidiar tomadas de
decisão em P&D. Com base na análise, pode-se decidir, por exemplo, alon-
gar o cronograma de desenvolvimento ou até interrompê-lo, estimular o
desenvolvimento de medidas de contingência referentes aos efeitos adver-
sos da tecnologia etc.
O processo de avaliação do impacto da tecnologia consiste nas seguin-
tes etapas (Carvalho, 2002):

• identificação dos impactos: nesta etapa, devem-se identificar os impac-


tos mais ou menos importantes. Para esta etapa, podem ser usados
métodos como brainstorming, checklists ou árvores. Um checklist útil
considera impactos em tecnologia, saúde, instituição, sociedade, po-
lítica, economia, cultura, indivíduo, ambiente e segurança;
• avaliação dos impactos: definição de quais impactos são prováveis e
qual a magnitude potencial dos mesmos. Definição dos impactos
mais importantes. Esta etapa e a próxima podem ser realizadas de
forma menos estruturada por meio de procedimento similar à ava-
liação de ocorrência, gravidade e detecção utilizada na FMEA;
• análise dos impactos: quantificação dos impactos considerados mais
importantes. Estimativa das implicações em termos de custos, riscos,
benefícios, entre outros, e faixas esperadas para cada valor.

4.8 Resumo

1. A importância de um bom planejamento de produtos tem sido destacada


na atualidade em decorrência de mercados cada vez mais competitivos. A
empresa precisa conhecer melhor e decidir, com riscos calculados, o que deve
ser desenvolvido em dado período;
2. Entre os principais desafios do planejamento de produtos encontra-se a defi-
nição de idéias de produtos, tendo em vista as várias alternativas possíveis.
Essa definição deve ser conduzida sob informações incipientes nessa fase do
desenvolvimento. Isso sugere o uso de metodologias e métodos de apoio para
reduzir as incertezas no processo de planejamento.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 199 — #227


i i

Planejamento de produtos 199

3. A idéia do produto consiste numa síntese das características técnicas e de


mercado, que mostram sua viabilidade e servem de base às tomadas de de-
cisão. A busca por idéias de produtos depende da capacidade criativa da
organização e de processos e métodos sistemáticos de trabalho;
4. Existem vários modelos de planejamento de produtos, desde os mais gerais
até os mais específicos. Em geral, as principais atividades são: definição de
idéias, seleção e classificação das idéias promissoras, especificação das idéias
e decisão sobre quais idéias serão desenvolvidas;
5. Para apoiar essas atividades existem também várias metodologias e métodos
de trabalho. Entre as metodologias gerais consideram-se: gestão do conheci-
mento, inteligência competitiva e gestão da tecnologia. Os métodos de apoio
podem ser classificados como destinados à geração de idéias e aqueles de
apoio à gestão da tecnologia;
6. Além de possuir metodologias e métodos, a empresa precisa estar preparada
e organizada para a inovação diante do planejamento de produtos. É neces-
sário desenvolver habilidades, competências e infra-estrutura. Também se
faz necessário, diante do planejamento de produtos, avaliar o impacto das
tecnologias propostas, seja interno ou externo;
7. Em linhas gerais, o planejamento de produtos é a fase do desenvolvimento
que subsidia a tomada de decisão da empresa sobre seus futuros desenvolvi-
mentos.

4.9 Problemas e temas de discussão

1. Discuta sobre os principais desafios do planejamento de produtos e


descreva meios para superá-los.
2. Estabeleça as principais relações entre o planejamento de produtos,
o planejamento estratégico e o planejamento de projetos da organi-
zação.
3. Liste e descreva brevemente os principais resultados de um planeja-
mento de produtos.
4. Como a idéia de um produto pode ser representada e comunicada?
Proponha formas alternativas dessa representação.
5. Quais são as principais fases do processo de planejamento de produ-
tos e suas típicas entradas e saídas?

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 200 — #228


i i

200 Projeto Integrado de Produtos: planejamento, concepção e modelagem

6. O que deve ser considerado para o desenvolvimento de um modelo


de planejamento de produtos tendo em vista as características da
organização?
7. Como a gestão do conhecimento se relaciona com os processos e ati-
vidades de planejamento de produtos?
8. Quais são as relações entre a gestão da tecnologia e o planejamento
de produtos?
9. Além dos métodos de apoio à geração de idéias de produtos, que
outros métodos você conhece e como eles podem ser empregados?
Cite exemplos de aplicações.
10. Discuta sobre os requisitos necessários de infra-estrutura e da equipe
de planejamento de produtos. Quais são os fatores determinantes
para o sucesso do planejamento de produtos?

4.10 Referências bibliográficas

Accept Software Corporation. 2004. Disponível em: <http://www.acce


ptsoft.com>. Acesso em: 13/01/2005.
ALVES, G. P. Um sistema de informação na gestão de projetos num
ambiente de engenharia simultânea em uma indústria de equi-
pamentos de telecomunicações. Florianópolis, 2004. Dissertação de
mestrado – PPGEPS – UFSC.
BAXTER, M. Projeto de produto: guia prático para o desenvolvimento
de novos produtos. São Paulo: Edgard Blücher, 1998.
BURGELMAN, R. A.; MAIDIQUE, M. A. Strategic management of te-
chnology and innovation. Boston: Irwin, 1988.
BURR, J. Mechatronics design in Japan: a study of japanese design
methods and working practice in japanese companies. Institute for
Engineering Design. Technical University of Denmark, Lyngby. 1989.
100p.
CARVALHO, M. A. de. Previsão tecnológica. Trabalho de disciplina de
estudo dirigido do PPGEPS – UFSC. Florianópolis, Publicação in-
terna. 2002. 74p.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 201 — #229


i i

Planejamento de produtos 201

CLARK, K. B.; FUJIMOTO, T. Product development performance: stra-


tegy, organization and management in the world auto industry.
Boston: Harvard Business School Press, 1991.
COTEC – Fundación COTEC para la Innovación Tecnológica. Tema-
guide: a guide to technology management and innovation for com-
panies. 1998. Barcelona: Cotec. Disponível em: <http://www.cotec.
es>. Acesso em: 23/1/2007.
KAHANER, L. Competitive intelligence: how to gather, analyse and
use information to move your business to the top. New York: Kane
and Associates, 1996.
KELLEY, T.; LITTMAN, J. A arte da inovação: lições de criatividade
da IDEO, a maior empresa norte-americana de design. São Paulo:
Futura, 2001.
LEIF, J. Implementing DFM in nordic industry. 1997. Capítulo 4: The
Product Planning Process. The Swedish Institute of Production Engi-
neering Research (IVF). Disponível em: <http://www.sintef.no/un
its/matek/projects/dfm/4kap.htm>. Acesso em: 28/10/2004.
MILLET, S. M.; HONTON, E. J. A manager’s guide to technology fo-
recasting and strategy analysis methods. Columbus: Battelle Press,
1991.
MONTANHA JR., I. R. Sistemática de gestão de tecnologia no processo
de projeto de produtos: um estudo dedicado às micro e peque-
nas indústrias metal-mecânicas. Florianópolis, 2004. Dissertação de
mestrado – PPGEM – UFSC.
NONAKA, I.; TAKEUCHI, H. Criação de conhecimento na empresa.
Tradução Ana Beatriz Rodrigues e Priscilla Martins Celeste. Rio de
Janeiro: Campus, 1997
OECD – Organisation for Economic Co-operation and Development.
Oslo manual: the measurement of scientific and technological ac-
tivities – proposed guidelines for collecting and interpreting tech-
nological innovation data. European Comission. Eurostat: OECD.
2.ed. 1998. 1.ed.: 1992. Disponível em: <http://www.oecd.org>.
Aces-so em: 17/02/2006.
PAHL, G.; BEITZ, W. Engineering design: a systematic approach. Glas-
gow: Springer Verlag, 1996

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 202 — #230


i i

202 Projeto Integrado de Produtos: planejamento, concepção e modelagem

PHAAL, R. Foresight vehicle technology roadmap: technology and


research directions for future road vehicles. Centre for Techno-
logy Management, Institute for Manufacturing, University of Cam-
bridge. 2002. Disponível em: <http://www.ifm.eng.cam.ac.uk>.
Acesso em: 3/8/2004.
PHAAL, R.; FARRUKH, C. J. P.; PROBERT, D. R. Technology roadmap-
ping: a planning framework for evolution and revolution. Procee-
dings of Technological Forecasting and Social Change. v.71, p.5-26.
North Holland. 2004.
PORTER, A. L.; ROPER, A. L.; MANSON, T. W.; ROSSINI, F. A.; BANKS,
J.; WIEDERHOLT, B. J. Forecasting and management of technology.
New York: John Wiley & Sons, 1991.
ROOZENBURG, N. F. M.; EEKELS, J. Product design: fundamentals
and methods. Chichester, England: John Wiley & Sons, 1995
SANTOS, N. Inteligência competitiva. Notas de aula da disciplina de
Inteligência Competitiva, do Programa de Pós-Graduação em Enge-
nharia de Produção e Sistemas. UFSC. Florianópolis, 2003.
SCHACHTNER, K. Information and communication structures in the
planning of market-oriented product innovations. Information Ma-
nagement Magazine. v.3. Ludwig-Maximilians, Universität Munich.
1999.
SIDÉN, J.; LINDSTRÖM, P.; PAULI, M. Strategic product planning: a
case study exploring the process and its development. Proceedings
of International Design Conference – DESIGN 2000: Dubrovnik.
2000. 6p.
TWISS, B. C. Forecasting for technologists and engineers: a practical
guide for better decisions. Stevenage: Peter Peregrinus. 1992.
VILAROUCA, M. G. Sistematização do conhecimento da manufatura
para uso na revisão formal de projeto: uma aplicação no domí-
nio de componentes plásticos. Dissertação de mestrado – PPGEM
– UFSC. Florianópolis, 2004.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 203 — #231


i i

Capítulo 5

Especificações de projeto do produto

5.1 Introdução

Após a realização das tarefas de pesquisa de informações e a definição


do produto a ser desenvolvido, conforme descrito no Capítulo 4, no âm-
bito da etapa de projeto informacional do PRODIP, o passo seguinte é o
estabelecimento das especificações de projeto.
Essa atividade é extremamente importante pois, além de propiciar o
entendimento e a descrição do problema na forma funcional, quantitativa
e qualitativa, formalizando a tarefa de projeto, fornece a base sobre a qual
serão montados os critérios de avaliação e de todas as tomadas de decisão
realizadas nas etapas posteriores do processo de projeto.
A atividade de elaboração das especificações de projeto, principal re-
sultado da fase de projeto informacional, tem recebido uma grande aten-
ção de pesquisadores e de profissionais de projeto e vem sendo, às vezes,
denominada de engenharia de requisitos (requirements engineering), princi-
palmente no desenvolvimento de produtos do domínio de sistemas com-
putacionais (Harwell et al., 1993, Karlsson, Nellore e Söderquist, 1998, Mc-
kay, Pennington e Baxter, 2001). Foram propostas metodologias que trans-
formam, sistemática e progressivamente a partir do planejamento do pro-
duto, as necessidades dos consumidores em requisitos dos consumidores
e estes em requisitos e especificações de projeto do produto, como mos-
tra esquematicamente a Figura 5.1, cujas definições serão apresentadas no
item 5.2.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 204 — #232


i i

204 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 5.1 Processo de transformação das necessidades dos usuários em


especificações de projeto

Essa sistematização trouxe vários benefícios ao processo de desenvol-


vimento de produtos, dentre eles:

• principalmente, a obtenção de especificações de melhor qualidade


em termos de precisão e completeza;
• vários métodos e ferramentas foram desenvolvidos e podem ser ado-
tados nas diversas atividades de coleta e transformação das informa-
ções pertinentes;
• a sistematização leva a equipe de projeto a um estudo mais apro-
fundado e a um maior entendimento das necessidades de todos os
envolvidos no ciclo de vida do produto;
• as especificações assim obtidas reduzem custos e tempos de desen-
volvimento, constituem a base de todas as decisões a serem tomadas
e facilitam o desdobramento funcional e o planejamento das ativida-
des de projeto e dos testes do produto.

Uma inadequada definição dessas especificações de projeto ou uma


determinação imprópria de certos aspectos do problema poderá causar
uma seqüência de decisões que fará emergir uma solução para um pro-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 205 — #233


i i

Especificações de projeto do produto 205

blema diferente do requerido. Ou seja, obter-se-á a solução de um pro-


blema definido erroneamente e que não satisfaz as necessidades dos usuá-
rios ao longo do ciclo de vida do produto.
Dessa forma, no item 5.2, serão apresentados os conceitos fundamen-
tais relacionados ao processo de desenvolvimento das especificações de
projeto; no 5.3, será descrita a metodologia e os correspondentes métodos
e ferramentas adotados no processo de elaboração das especificações, e
no 5.4, serão apresentadas especificações típicas de produtos industriais e
será discutida a caracterização das mesmas.

5.2 Conceitos fundamentais relacionados à


elaboração das especificações de projeto

Na Figura 5.1 foi mostrada uma seqüência de transformações de neces-


sidades em requisitos de usuários e, estes, em requisitos e especificações
de projeto.
O termo usuário será usado para representar todas as pessoas e orga-
nizações que de alguma forma têm interesse ou que serão afetadas pelo
produto ao longo de seu ciclo de vida. Aqui devem ser considerados os
usuários envolvidos no uso do produto e no processo de produção do
mesmo. Assim, o conceito de usuário do produto é bem amplo, compreen-
dendo: consumidores; operadores; pessoal de assistência técnica; compra-
dores; revendedores; bancos; agências financiadoras; órgãos de governo;
comunidades; órgãos reguladores; possíveis vítimas; empresas de recicla-
gem etc. Como usuários do processo de produção tem-se: a equipe de
projeto; fabricantes; fornecedores de matérias-primas e de componentes;
colaboradores envolvidos na fabricação, embalagem e manipulação; sin-
dicatos; empresários e acionistas. Na literatura em português são usados
outros termos, entre estes consumidor e cliente. Em inglês, atualmente, o
termo stakeholders é muito freqüente para denominar esse conjunto amplo
de possíveis envolvidos ao longo do ciclo de vida de um produto.
A primeira atividade propriamente dita de projeto do produto é a
identificação e coleta das necessidades dos usuários do produto. É tam-
bém a atividade mais crítica de todo o processo, pois essas necessidades
são a voz do consumidor, a qual deve ser atendida como primeira priori-
dade. As demais atividades e decisões são decorrências. Assim, a necessi-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 206 — #234


i i

206 Projeto Integrado de Produtos: planejamento, concepção e modelagem

dade do usuário é a palavra ou a frase que expressa o que o consumidor


precisa, sua vontade, desejos e expectativas. Essas necessidades são, geral-
mente, expressas numa linguagem natural e livre dos consumidores, sem
nenhuma padronização de termos e classificações.
As necessidades dos usuários, para serem de fácil visualização e ado-
ção pelos planejadores e membros da equipe de projeto, devem ser trans-
formadas, resumidas, agrupadas e classificadas numa linguagem apro-
priada para expressar atributos de qualidade do produto que são deno-
minados de requisitos do usuário (Figura 5.1). Os requisitos dos usuários
são, geralmente, expressos na forma qualitativa. Como exemplos, tem-se:
o produto deve ser seguro; ter aspecto atraente; ser de fácil operação e
manutenção; ter baixo custo etc.
Quando os requisitos dos usuários são transformados e ou desdobra-
dos, e aos mesmos são atribuídas dimensões, os resultados dessa conver-
são serão denominados de requisitos de projeto. Requisito de projeto é
uma qualidade, um atributo com grandezas definidas do produto. Por
exemplo, o requisito de usuários fácil manutenção pode ser convertido
nos seguintes requisitos de projeto: tempo médio (horas) entre manuten-
ções preventivas ou corretivas; x (horas) de manutenção preventiva ou
corretiva por hora de operação do sistema e y (R$) de custo médio de ma-
nutenção corretiva.
Quando são atribuídas grandezas a um atributo ou qualidade de um
produto, estas deverão ser passíveis de mensuração. O conjunto de atri-
butos assim definidos, adicionados os modos e as grandezas para ava-
liação de conformidade estabelecidas, e com prioridades de atendimento,
denominar-se-á especificações de projeto do produto. Essas especifica-
ções de projeto são o ponto de partida para a concepção do produto e o
meio de verificar se o projeto atende ou não às necessidades do usuário. A
metodologia de elaboração desse conjunto de especificações será descrita
no próximo item.

5.3 Metodologia de desenvolvimento das


especificações de projeto do produto

Todo o desenvolvimento de produto ou de serviço se inicia com o es-


tabelecimento das especificações de projeto. É muito freqüente observar

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 207 — #235


i i

Especificações de projeto do produto 207

que idéias são transformadas, às pressas, em produtos que não atendem


os usuários. As especificações do produto são incompletas ou então su-
perdimensionadas. No primeiro caso tem-se um produto abaixo das ne-
cessidades do usuário e, no segundo, o produto apresenta certas caracte-
rísticas acima das exigências, tornando, então, o custo de produção muito
elevado. A elaboração das especificações de projeto, ao seguir uma me-
todologia predefinida e ao investir tempo nesse processo, traz benefícios,
como já foi apontado anteriormente. Cada projeto ou produto a ser de-
senvolvido tem suas próprias características. Assim, o tempo investido, a
profundidade e a extensão de aplicação da metodologia devem ser dosa-
dos para cada caso, mas recomenda-se seguir todos os procedimentos da
sistemática apresentada nos próximos itens.
Esse procedimento sistemático permite uma definição progressiva das
especificações de projeto que expressam o que o produto deverá fazer,
baseando-se na identificação, avaliação, quantificação, priorização e do-
cumentação das necessidades dos usuários e encorajando a inovação pelo
uso das melhores práticas.

5.3.1 Apresentação do problema de projeto

O processo de elaboração das especificações de projeto se inicia com


a apresentação do problema que vai ser resolvido e que foi formulado no
planejamento do produto conforme descrito no Capítulo 4. Como consta
na Figura 2.16, tem-se, como saída da fase de planejamento, um plano
de desenvolvimento do produto. Recomenda-se que a apresentação desse
plano seja efetuada formalmente, marcando o início do projeto com a pre-
sença, no mínimo, do gerente e da equipe de projeto. Esse plano deve con-
ter: a declaração do escopo; estrutura de decomposição do projeto; riscos
do projeto; lista de atividades do projeto; recursos físicos, planejamento or-
ganizacional; cronograma; plano de gerenciamento das comunicações de
suprimentos, da qualidade; a política de segurança; restrições de projeto;
a prioridade; e a periodicidade de reuniões.
Nessa apresentação, devem também ser esclarecidas dúvidas de diver-
sas naturezas, entre as quais:

• tipo de projeto: se é um projeto de um produto totalmente novo, de


evolução de um produto já produzido ou se é um produto novo para

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 208 — #236


i i

208 Projeto Integrado de Produtos: planejamento, concepção e modelagem

a empresa, já existente no mercado, e que deverá ser submetido a um


processo de engenharia reversa;
• volume de produção: se é um produto ou um sistema único a ser
fornecido sob encomenda ou será produzido em larga escala;
• quais informações históricas estão disponíveis na empresa e qual é a
extensão do levantamento já realizado de necessidades dos usuários.

Essas são informações importantes para orientar a equipe na busca


detalhada das necessidades dos usuários do projeto e do produto.
Quanto ao tipo de projeto, tem-se, na literatura, várias formas de clas-
sificação e denominação. Os critérios mais comuns adotados para a classi-
ficação de projetos de produtos levam em consideração a inovação ou ori-
ginalidade, a novidade para a empresa ou, no mercado, a complexidade,
o porte, os domínios de conhecimento do projeto e o uso do produto. Para
os objetivos de busca das necessidades e da elaboração das especificações
de projeto, serão considerados os seguintes tipos:

• Projeto de inovação: apresenta alto grau de originalidade concei-


tual. É uma invenção resultante de uma pesquisa com potenciais
aplicações em novos produtos ou então que se requer um produto
para atender a uma nova necessidade ou operação ainda não aten-
dida por produtos existentes. Esse é o caso mais complexo e, para a
apresentação do projeto, provavelmente haverá menos informações
pois não há um produto de referência e não se tem conhecimentos
históricos sobre os potenciais usuários e mercados.
• Projeto de evolução: enquadram-se aqui vários casos de reprojetos
de produtos existentes. Em primeiro lugar tem-se a atividade de in-
troduzir melhoramentos no projeto de um produto existente e que
já vem sendo produzido pela empresa. As razões para realizar um
reprojeto são falhas no projeto anterior, necessidade de introduzir
novas tecnologias ou reduzir custos de produção para fazer frente à
concorrência. Para a apresentação, tem-se considerável quantidade
de informações do projeto anterior, assim como dados históricos de
problemas de fabricação, da assistência técnica e do mercado.
• Projeto de variação: semelhante ao anterior, este é um caso em que
em um projeto de produto existente, são introduzidas, variações di-
mensionais, de arranjos, ampliações ou adaptações para atender a

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 209 — #237


i i

Especificações de projeto do produto 209

novas operações ou ampliar capacidades solicitadas pelos usuários.


Geralmente não há alterações na função nem nos princípios de solu-
ção. Para o lançamento e apresentação do projeto à equipe de de-
senvolvimento, tem-se à disposição consideráveis informações do
produto que será adotado para a avaliação ou adaptação às novas
necessidades.
• Projeto reverso: são os casos em que a empresa pretende produzir
um produto já existente no mercado. Para a empresa é um projeto
novo, um processo de cópia ou, de forma mais elegante, um pro-
cesso de engenharia reversa; é desenvolvido o projeto de um pro-
duto já produzido por outros fabricantes. Sendo um produto sem
proteção de patentes, esta é uma prática legal, como será discutido
no Capítulo 10. Neste caso, para a apresentação na reunião de lança-
mento do projeto, pode-se dispor de modelos de produtos de outros
fabricantes.

Com o conhecimento do tipo de projeto e produto a ser desenvol-


vido, do volume de produção e das informações já disponíveis, a equipe
pode programar a análise desses dados, definir o ciclo de vida, identificar
os usuários e levantar dados adicionais, conforme descrito nos próximos
itens.

5.3.2 Definição do ciclo de vida do produto

Cada tipo de produto tem o seu ciclo de desenvolvimento. A Figura


5.2 dá uma visão geral do mesmo. A espiral interna indica o contato que
o setor de marketing da empresa deve manter continuamente com o mer-
cado ou os usuários. Na espiral externa está representado o contato que a
equipe de desenvolvimento manterá com os diferentes usuários que atua-
rão nas fases do ciclo de vida do produto, para elicitar informações neces-
sárias ao processo de transformação do problema de projeto em especifi-
cações de projeto.
No caso do desenvolvimento do projeto de inovação de um sistema
técnico de domínio multidisciplinar, tem-se um exemplo mais geral (Fi-
gura 5.2). Tem-se aqui, no processo de desenvolvimento, todas as 8 fases
do modelo de desenvolvimento integrado de produtos, descritas no item
2.4 do Capítulo 2. Considerando-se automóveis, máquinas-ferramenta ou

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 210 — #238


i i

210 Projeto Integrado de Produtos: planejamento, concepção e modelagem

eletrodomésticos, por exemplo, além das fases de projeto, o produto passa


pela fabricação, montagem, embalagem, transporte, uso, manutenção, de-
sativação e reciclagem. Na manutenção, devem-se prever a manutenção
preventiva e corretiva, peças de reposição e de reparo. No outro extremo,
tem-se o desenvolvimento de produtos simples, tais como componentes
mecânicos ou eletrônicos, nos quais, caso haja uma falha, são descartados
e substituídos. Assim não é necessário prever facilidades para manutenção
e reparos. Em projetos de inovação como esse devem ser elicitadas infor-
mações dos usuários que atuam em todas as fases de desenvolvimento.

Figura 5.2 Espiral do desenvolvimento (adaptado de Fonseca, 2000)

No que diz respeiro a projetos de evolução e de variação, o ciclo de


vida em geral, é, reduzido nas fases de projeto. Às vezes, são introduzi-
das modificações somente de partes, de componentes ou subsistemas que
venham apresentando muitas falhas ou sejam de tecnologias obsoletas.
Nesses tipos de projetos já existem informações da maioria dos usuários
que desenvolvem atividades ao longo do ciclo de vida do produto.
Havendo uma grande variedade de tipos, portes e complexidades de
produtos no mercado e, ainda, considerando projetos novos ou reprojetos,

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 211 — #239


i i

Especificações de projeto do produto 211

cada caso deve ser analisado e as atividades e os correspondentes usuários


durante o ciclo de vida, determinados.

5.3.3 Identificação dos usuários do projeto e do produto

O termo usuário já foi definido no item 5.2. Ele engloba todas as pes-
soas, órgãos ou instituições que têm interesse, direito de opinar, impor exi-
gências ou expressar necessidades que venham a afetar de alguma forma
as características ou os atributos do produto a ser desenvolvido. Esses
usuários podem ser classificados como externos, intermediários ou inter-
nos.
Os usuários externos são as pessoas ou organizações que irão usar
ou consumir o produto e devem ser considerados prioritariamente. Nessa
classe são incluídos todos os que exercem atividades nos setores de con-
sumo ou que são influenciados, direta ou indiretamente, pelo produto. No
caso do projeto de um sistema técnico, os usuários diretos seriam os ope-
radores do equipamento, o pessoal de manutenção e assistência técnica,
os envolvidos na desativação, no descarte e na reciclagem. No que diz
respeito a um veículo de transporte coletivo, ter-se-ia, ainda, os usuários
indiretos, que são os órgãos reguladores, os passageiros, os pedestres e
os moradores da comunidade, que seriam afetados pelos serviços e pela
poluição sonora e do ar.
No setor de mercado há os usuários intermediários que correspondem
àqueles responsáveis pela distribuição, promoção, marketing e vendas do
produto. Nessa classe são enquadrados os bancos ou agências de financia-
mento, órgãos coletores de impostos, representantes, revendedores e lojas
de departamentos.
Como mostra a Figura 5.2, os usuários internos são aqueles envol-
vidos nos setores produtivos, compreendendo as atividades de planeja-
mento, gerência, projeto, fornecimento, fabricação, embalagem, manipu-
lação e transporte do produto. Da mesma forma, são incluídos, na classe
de usuários internos, empresários, acionistas, sindicatos de trabalhadores,
a comunidade onde está instalada a unidade fabril etc.
É interessante destacar que a discussão apresentada sobre os usuários
leva a classificá-los em usuários do processo e usuários do produto resul-
tante do processo. As pessoas e organizações envolvidas nos setores pro-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 212 — #240


i i

212 Projeto Integrado de Produtos: planejamento, concepção e modelagem

dutivos são usuários do processo de produção e as envolvidas nos setores


de mercado e consumo são usuários do produto.

5.3.4 Elicitação das necessidades dos usuários

É muito freqüente dizer ou escutar que a voz do usuário se constitui no


principal e mais crítico passo para alcançar a qualidade ou a competitivi-
dade de produtos. E mais: a qualidade só pode ser definida pelos usuários,
e estes só ficarão satisfeitos com produtos e serviços que atendam ou ex-
cedam as suas necessidades e desejos, por um preço que represente valor
de uso. Isso significa que as empresas devem entender o que os usuários
realmente querem. Chega-se a afirmar que o papel de definir a excelência
do produto é dos usuários e não mais da gerência e da equipe de desen-
volvimento do produto.
Como já foi mencionado no item anterior, existem muitos usuários ou
clientelas a ser satisfeitos e que os mesmos têm linguagens e entendimen-
tos diferentes entre si especialmente em relação à linguagem da empresa.
A busca da voz do usuário tem sido objeto de muitos estudos e diversas
práticas e métodos para alcançar as reais necessidades do ambiente de de-
senvolvimento e uso dos produtos foram aprimoradas.
Dentre as melhores práticas que apóiam a elicitação das necessidades
dos usuários, podem ser citadas as seguintes:

• análise das necessidades em que se utilizam métodos para garantir


a identificação dos corretos ou reais desejos, vontades e expectativas
dos usuários;
• no uso do produto e na análise dos perfis dos usuários podem-se
documentar, em escala de tempo, todas as funções que o produto e o
usuário devem desempenhar, considerando os diferentes ambientes
ou missões. Esses perfis são chamados de cenários, casos de usos,
análise de tarefas, seqüências de funções, fluxos de trabalho, perfis
de ambientes ou de missões;
• previsão da capacidade tecnológica, de curto e longo prazo, para ga-
rantir que o projeto seja atualizado quando se iniciar a fabricação
do produto. A previsão tecnológica é uma forma de verificar a dis-
ponibilidade de tecnologias no tempo certo para serem aplicadas no

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 213 — #241


i i

Especificações de projeto do produto 213

projeto, os níveis esperados de desempenho e as capacidades de ma-


nufatura necessárias quando o projeto estiver pronto para ser fabri-
cado;
• a realização de estudos das capacidades da empresa e de benchmar-
king que avaliam as competências da empresa e da concorrência,
identificam as melhores práticas e auxiliam na definição das espe-
cificações de projeto e de fabricação;
• o uso da prototipagem virtual e do método de desdobramento da
qualidade que sistematizam a identificação das necessidades dos
usuários e o desenvolvimento das especificações de projeto do pro-
duto.

Os métodos desenvolvidos para a busca das necessidades dos usuá-


rios existem em número elevado e os mais recomendados para a captura
e documentação das mesmas são os seguintes:
Entrevistas estruturadas com usuários: a gravação e a transcrição des-
sas entrevistas com os reais usuários fornecem uma informação textual
e mantêm a essência da voz do consumidor enquanto necessária. Geral-
mente essas entrevistas são estruturadas, preparadas e baseadas em atri-
butos típicos do produto objeto da pesquisa.
Na preparação das entrevistas, Swanson e Hauser (1995) recomendam
que seja efetuada uma série de questionamentos, entre os quais:
Qual o tipo indicado de entrevista? As entrevistas individuais são mais
eficientes do que as em grupos. Há tendências potenciais e aspectos de
dinâmica de grupo que prejudicam a obtenção de dados, em maior pro-
fundidade e detalhes, quando focada em grupos de usuários.
Quantas entrevistas devem ser feitas? Um número de 20 ou 30 entrevistas
num grupo homogêneo de usuários pode garantir que 90% ou mais das
necessidades sejam identificadas. No entanto, o tópico e o entrevistado
também devem ser considerados; caso sejam mais complexos, pode-se ne-
cessitar de mais entrevistas.
Quem deve conduzir a entrevista? Membros da equipe de desenvolvi-
mento do projeto podem obter maior visão dos usuários ao ouvi-los dis-
cutirem seus problemas e preocupações. Ao menos a equipe de projeto
deve assistir ou ver os vídeos das entrevistas. Isso não significa que os
membros da equipe de desenvolvimento devam realizar as entrevistas. Às
vezes, membros da equipe de desenvolvimento podem adotar linguagem

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 214 — #242


i i

214 Projeto Integrado de Produtos: planejamento, concepção e modelagem

e posições de tendências típicas da empresa, prejudicando a busca pelas


reais necessidades dos usuários. O mais conveniente é capacitar, especial-
mente para essa função, pessoas da empresa para realizar as entrevistas,
pois elas têm um conhecimento privilegiado da empresa em questão.
O que o entrevistador deve falar? Deve ser organizado um plano para os
entrevistadores para garantir um bom fluxo e um entendimento dos tópi-
cos de interesse. Os usuários frequentemente apresentam soluções quando
o objetivo da entrevista deve ser o levantamento de necessidades que os
levaram a pensar nessas soluções. Por exemplo, usando “por que” como
a palavra-chave da entrevista, pode ser perguntado: Por que baixo custo
é um referencial importante neste projeto? Por que deve ser priorizada a
segurança independente do custo?
O que deve ser feito ao concluir a entrevista? Os analistas devem ler e des-
tacar as transcrições das entrevistas para extrair as necessidades dos usuá-
rios que serão submetidas ao processamento, como descrito mais adiante.
Parcerias ou alianças no projeto: a participação de usuários na rea-
lização do projeto também é uma forma de conhecer suas necessidades.
Atualmente é muito freqüente o envolvimento de fornecedores no desen-
volvimento do produto, especialmente no que concerne aos componentes,
subsistemas ou materiais dos quais serão fornecedores. No caso de equi-
pes, num ambiente de engenharia simultânea, normalmente já participam
representantes da fabricação, uso e manutenção ou assistência técnica.
Consultores e especialistas: profissionais em mercadologia são capa-
citados na identificação das necessidades dos usuários e podem ser con-
tratados ou consultados. O método de Delphi é uma forma sistemática de
buscar informações dessa natureza junto a especialistas sobre um produto
ou tecnologia objeto do desenvolvimento.
Sessões de brainstorming: este método solicita entradas que encora-
jam a geração de idéias inovadoras que fujam do ordinário e mudem os
conceitos do tipo de produto em estudo.
Experiências pessoais e da empresa: trazem necessidades de sucessos
e de falhas de produtos passados, ou planilhas e modelos de referência de-
senvolvidos para identificar necessidades ou atributos típicos do produto.
Pesquisa em material publicado: revistas, jornais, leis, projetos de lei,
normas e patentes, incluindo o uso da internet, fornecem dados e diretri-
zes de necessidades dos usuários do produto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 215 — #243


i i

Especificações de projeto do produto 215

Previsão da capacidade tecnológica: ao prever o futuro baseando-se


em dados históricos de produtos e tecnologias, identificam-se necessida-
des dos usuários.
Análise de mercado e benchmarking da concorrência: essa análise
identifica os melhores na classe e idéias inovadoras.
Prototipagem e realidade virtual: essas técnicas podem ser empre-
gadas para estudar respostas de usuários e promover recomendações à
equipe de projeto.
Método do desdobramento da função qualidade: esse método foi ini-
cialmente apresentado por Akao (1990), no fim dos anos 1960. É conhe-
cido como o método QFD (Quality Function Deployment). O QFD é funda-
mentado na preocupação de que os produtos devem ser projetados para
refletir os desejos, gostos e expectativas dos usuários (ou a voz do consu-
midor) que devem ser considerados de alguma maneira no processo de
desenvolvimento do produto. Adicionalmente, profissionais de mercado,
engenharia e fabricação devem trabalhar integrados desde as fases iniciais
do desenvolvimento. Os propósitos gerais do método QFD são: tornar efe-
tivo o uso de métodos sistemáticos para o desenvolvimento de produtos;
propiciar a solução de problemas pela atividade em grupo; tornar a ativi-
dade em grupo eficiente; e capacitar o grupo com ferramentas simples e
práticas.
É também conhecido como método das matrizes; no método completo
tem-se um desdobramento de quatro matrizes, mas, para o objeto do pre-
sente capítulo, adotar-se-á somente a primeira matriz, conhecida como a
casa da qualidade (Figura 5.3).
Esse método tem recebido especial atenção entre pesquisadores e pro-
fissionais da indústria e o desdobramento da primeira matriz, a casa da
qualidade, é adotado como uma sistemática que abrange a maioria do pro-
cesso de elaboração das especificações de projeto. O método do QFD não é
um método de elicitação das necessidades propriamente dito, mas é usado
para a documentação e visualização das necessidades levantadas pelos
métodos anteriormente descritos e como auxiliar no processamento das
mesmas e suas transformações sucessivas em requisitos de usuários e de
projeto, priorização dos requisitos de projeto e sua transformação final em
especificações de projeto, como proposto na metodologia deste capítulo,
ao preencher os sete campos da casa da qualidade.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 216 — #244


i i

216 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Como já foi dito anteriormente, as informações levantadas com usuá-


rios encontram-se em uma linguagem natural e bastante diversa, tendo
em vista os inúmeros usuários com diversos perfis, formações, culturas
e interesses. Assim, essas informações devem ser triadas, classificadas e
agrupadas de modo a formar as necessidades que sejam representativas
e que expressem vontades, desejos ou qualidades que o usuário quer no
produto. Essas declarações de necessidades são, então, usadas para preen-
cher o Campo I da casa da qualidade (Figura 5.3). Elas serão transformadas
nos chamados requisitos de usuários, como descrito no próximo item.

Figura 5.3 Forma e principais elementos da casa da qualidade

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 217 — #245


i i

Especificações de projeto do produto 217

5.3.5 Transformação das necessidades em requisitos de


usuários

Para o desenvolvimento do processo é conveniente que as necessida-


des sejam desdobradas ou agrupadas nos requisitos dos usuários. As ne-
cessidades dos usuários são transformadas ou traduzidas para os requisi-
tos de usuários usando-se uma linguagem mais compacta e apropriada ao
entendimento geral da equipe de desenvolvimento. Essa conversão pode
ser feita com base em atributos de qualidade do produto.
Considerando-se a variedade de produtos de forma geral, os atributos
de qualidade podem ser classificados de diversas formas: qualitativos ou
quantitativos; obrigatórios ou preferenciais; do ciclo de vida ou específi-
cos.
Aqui será adotada a última classificação (Tabela 5.1), em que os atribu-
tos de qualidade podem ser obrigatórios ou preferenciais e quantitativos
ou qualitativos. Na tabela tem-se uma amostra de atributos típicos de sis-
temas técnicos que podem ser utilizados como um dicionário de tradução
das necessidades de usuários do Campo I para os requisitos de usuários a
serem registrados no Campo II

5.3.6 Planejamento da qualidade desejada

No desenvolvimento de um produto, envolvem-se várias pessoas que


se constituem em usuários com diferentes interesses. Em tese, todos os
usuários expressarão seus interesses como sendo os mais importantes.
Ocorre, entretanto, que essa importância poderá ter seu valor alterado
(diminuído ou aumentado) se forem considerados outros parâmetros de
avaliação. A análise comparativa das necessidades ou dos requisitos dos
usuários em conjunto com o estudo de produtos concorrentes é denomi-
nada de planejamento da qualidade desejada. O objetivo dessa análise é
a determinação dos fatores de importância e as metas dos requisitos dos
usuários registrados no Campo II da casa da qualidade. Os resultados serão
registrados no Campo V da casa da qualidade.
À importância de cada requisito de usuário pode ser atribuído um va-
lor numérico, o qual indica, com base em uma dada escala, como aquele
requisito deverá ser analisado pela equipe de desenvolvimento durante a

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 218 — #246


i i

218 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 5.1 Atributos típicos de produtos industriais (adaptado de Fonseca, 2000)

Classes de
Atributos Comentários
atributos
Funcionalidade Funções, operações, desempenho, eficiência
Ergonomicidade Ergonomia de uso
Esteticidade Aparência, estilo, cores
Princípios de segurança, proteção, atos
Segurança
inseguros
Atributos Confiabilidade Taxas de falhas, redundâncias
básicos Legalidade Atendimento às leis de segurança, comércio
Patenteabilidade Inovação passível de privilégio
Atendimento às normas internas, de transporte
Normalização
e de comércio
Robustez Pouco sensível aos fatores do meio ambiente
Impacto Atende a normas ambientais, poluição,
ambiental conservação
Fabricabilidade Fácil, precisa e de baixo custo
Montabilidade Manutenção fácil e econômica
Embalagem fácil, compacta, econômica e
Embalabilidade
segura
Adequado aos meios de transporte e
Transportabilidade
Atributos manipulação
do ciclo Armazenabilidade Conservação, ambientes, manipulação
de vida
Vendabilidade De fácil venda e exposição
Usabilidade Fácil operação, aprendizado
Mantenabilidade Manutenção fácil, rápida e segura
Reciclabilidade Produto, componente, resíduos recicláveis
Descarte sem contaminação ou dano ao
Descartabilidade
ambiente
Geometria Forma, arranjo, dimensão, espaço
Cinemática Movimentos, direção, velocidade, aceleração
Forças Direção, magnitude, freqüência, rigidez, peso
Fontes, potência, rendimento,
Atributos Energia armazenamento
específicos Propriedades físicas e químicas,
Materiais
contaminações
Sinais Entrada, saída, forma, apresentação, controle
Automação Manual, índice de automação
Tempo Tempo de desenvolvimento, data de entrega

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 219 — #247


i i

Especificações de projeto do produto 219

solução do problema. Hauser e Clausing (1988) recomendam que sejam


estabelecidos valores relativos para cada requisito através do julgamento
da própria equipe de desenvolvimento. Também citam o emprego de téc-
nicas para expressar as preferências dos usuários com relação a produtos
existentes ou hipotéticos. Akao (1990), por sua vez, apresenta um método
para calcular o valor dos requisitos dos usuários, chamados pelo autor de
peso da qualidade demandada, considerando-se a análise de produtos con-
correntes, o potencial para vendas e a taxa de melhoramento da demanda.
Segundo o autor, o método proposto, conforme a Figura 5.4, leva em conta
as políticas da empresa com relação a determinadas demandas.
O método de Akao (1990) tem início pela determinação do grau de im-
portância de cada requisito de usuário. Esse valor pode ser atribuído pelos
próprios membros da equipe, respondendo a questões do tipo: “qual será
a importância deste requisito para o usuário?” Outra forma é perguntar
diretamente ao usuário como ele considera determinado requisito. Para
cada item de julgamento é elaborada uma questão e indicada uma escala
para o usuário escolher o valor mais apropriado. Esse método parece ser o
mais adequado. Entretanto, os itens de julgamento são estabelecidos pela
equipe e não pelos próprios usuários. Há, de certa forma, nesse caso, uma
espécie de indução de desejos pelos questionários formulados. A escala do
grau de importância a ser atribuído aos requisitos de projeto é de gi = 1 a
5, que é registrado na primeira coluna do Campo V, como mostra a Figura
5.4.
Na seqüência do método são valorados o produto da empresa e os
possíveis produtos concorrentes. Essa valoração também pode ser reali-
zada por questionários aplicados diretamente ao usuário. Com questões e
escalas de valores apropriadas, pede-se que ele atribua o valor correspon-
dente ao que pensa do produto da empresa e dos produtos concorrentes.
Esse tipo de questionamento pode se tornar ineficiente se os usuários sele-
cionados tiverem pouco conhecimento do mercado e dos produtos de es-
tudo. É recomendado, também, que a valoração de produtos da empresa e
de concorrentes seja feita pela própria equipe. Perguntas do tipo “quanto a
empresa está fazendo para atender a esse desejo?” e “como o concorrente
está atendendo esse desejo?” podem auxiliar nessa tarefa. Para cada um
dos requisitos de usuários e para o produto da empresa e dos concorren-
tes são realizadas valorações vi,j para as quais foi adotada também a escala
de 1 a 5. No exemplo da Figura 5.4, foram atribuídos os valores 3 para o

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 220 — #248


i i

220 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 5.4 Método para o cálculo da importância dos requisitos dos usuários
(adaptado de Akao, 1990)

produto da empresa e 4 para os dois produtos concorrentes. Esses valores


serão determinados para todos os requisitos de usuários e registrados nas
três colunas seguintes do Campo V.
O plano de qualidade, ou o valor meta atribuído vi,m , para dado re-
quisito do usuário, determina até onde a empresa pretende chegar para
satisfazê-lo. Isso depende de uma série de fatores, incluindo as próprias
políticas da empresa. Esse valor é atribuído pela equipe de trabalho e é ne-
cessário para que seus integrantes, ou pelo menos parte deles, conheçam
as diretrizes ou o planejamento estratégico da empresa. Esse valor também
expressa uma certa realidade do que é ou não possível de ser atendido com
os recursos disponíveis. Os valores serão registrados na quarta coluna do
Campo V.
A taxa de melhoramento tmi é um resultado direto dos valores an-
teriormente atribuídos, ou seja, da divisão do valor meta pelo valor atri-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 221 — #249


i i

Especificações de projeto do produto 221

buído ao produto da empresa, tmi = vi,m /vi,A . Esta taxa dá uma idéia de
quanto o produto da empresa poderá ser melhorado com relação a deter-
minado requisito. Trata-se de um valor intermediário para o cálculo final
da importância relativa do desejo do usuário e de um indicativo do con-
junto de requisitos que podem ser melhorados.
Os fatores de venda f vi de um dado requisito determinam, com base
em uma dada escala (Akao (1990) recomenda os valores de f vi = 1,5; 1,2
e 1,0) e na comparação entre o produto da empresa e os dos concorrentes,
qual será a estratégia de vendas da empresa com relação àquele requisito
de usuário. Ou seja, valores altos, decorrentes, por exemplo, de produtos
concorrentes com importâncias maiores, indicam que aquele requisito de-
verá apresentar um bom potencial para a venda do produto. Entretanto,
essa análise também deve ser feita com base nas facilidades da empresa
para esse fim. Não adianta atribuir um alto valor para fatores de venda se
a empresa não tiver condições de atender a eles (caso dos recursos para
propaganda, por exemplo).
Finalmente, com base nos resultados anteriores, calcula-se um peso
absoluto pai e um peso relativo prui para cada requisito de usuário. Esses
valores são calculados pelas seguintes equações:

pai = gii × tmi × f vi (5.1)

pai
prui = (5.2)

n
paj
j

Nota-se que as atribuições de valores, seja para cada requisito, para


os produtos concorrentes, para o produto da empresa ou para os fatores
de venda, dependem muito dos conhecimentos, experiências, intuição e
debates entre os membros do grupo de trabalho. Trata-se de valorações
com pouco ou nenhum embasamento teórico. Entretanto, segundo Akao
(1990), as aplicações práticas daquele método têm apresentado bons resul-
tados e sua validade vem sendo aceita gradualmente.
A valoração dos requisitos dos consumidores é uma atividade básica
para os demais processamentos efetuados na casa da qualidade. Com os va-
lores estabelecidos, é calculada, por exemplo, a ordem de importância dos

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 222 — #250


i i

222 Projeto Integrado de Produtos: planejamento, concepção e modelagem

requisitos de projeto registrados no Campo III, os quais, por sua vez, for-
marão base para a escolha de alternativas de solução para o produto ou
suas partes. Assim, se essa tarefa for subestimada e seus resultados forem
duvidosos, estes serão “transferidos” para as demais informações de de-
senvolvimento do produto e poderão conduzir a soluções inadequadas.
Portanto, todo o esforço possível para o entendimento, análise e valora-
ção dos requisitos dos usuários deve ser considerado como meta e podem
ser adotados ou desenvolvidos métodos alternativos para auxiliar nessa
tarefa.

5.3.7 Conversão dos requisitos de usuários em requisitos de


projeto

Após a sistematização e valoração dos requisitos dos usuários, a equi-


pe de desenvolvimento inicia a tarefa que trata do estabelecimento das
características de engenharia do produto. Essas características expres-
sam, conforme Reich (1996), a “voz da engenharia”. São, em essência, os
atributos do produto que podem ser manipulados (modificados, retira-
dos, incluídos, ampliados, diminuídos etc.) para satisfazer os requisitos
dos usuários. Essa atividade é denominada, conforme Hauser e Clausing
(1988), de tradução dos requisitos do usuário em características de enge-
nharia. Para o termo características da engenharia também são encontradas
diversas outras denominações, tais como elementos da qualidade (Akao,
1990), requisitos de engenharia (Ullman, 1992), ou atributos mensuráveis
do produto (Reich, 1996). No presente texto adotar-se-á o termo de requi-
sitos de projeto, como já definido no item 5.2, que serão registrados no
Campo III da casa da qualidade.
A palavra tradução é empregada para designar uma forma de inter-
pretação de cada requisito de usuário e expressar o resultado numa lin-
guagem técnica orientada ao objeto de estudo, os chamados requisitos de
projeto, que devem ser, na medida do possível, parâmetros mensuráveis.
Na forma como a casa da qualidade se apresenta, ou vem sendo utilizada,
o objeto de estudo é, em geral, o reprojeto ou o melhoramento de produ-
tos existentes (ou de suas partes), visando adequá-los às necessidades ou
aos desejos dos usuários e torná-los competitivos diante dos concorrentes.
Nesse caso, as características de engenharia ou os requisitos de projeto são
declarações a respeito de parâmetros, grandezas físicas, funções e restri-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 223 — #251


i i

Especificações de projeto do produto 223

ções, entre outros, de um produto conhecido que pode ser melhorado. A


tradução dos requisitos de usuários em requisitos de projeto não é feita um
a um, pois um requisito de usuário pode ser expresso por vários parâme-
tros, dimensões ou requisitos de projeto. Da mesma forma, um requisito
de projeto do Campo III pode englobar mais de um requisito de usuário
do Campo II.
Na tradução dos requisitos dos usuários em requisitos de projeto, cujas
declarações apresentam algumas das propriedades anteriormente mencio-
nadas, devem ser consideradas as seguintes questões:

• sobre a interpretação de um dado requisito do usuário: o que signi-


fica e que princípios ou métodos podem ser empregados para esse
fim?;
• sobre o propósito de declarações técnicas: por que estabelecer uma
lista de declarações técnicas do produto em estudo?

A interpretação de qualquer informação depende do sistema de valo-


res, conhecimentos e experiências de quem o faz. Isso quer dizer que dife-
rentes equipes de projeto proverão diferentes características de engenha-
ria para um mesmo conjunto de desejos dos usuários. Por outro lado, um
determinado desejo do usuário, e conseqüente requisito, poderá ter sido
declarado com diferentes conotações, o que conduzirá, provavelmente, a
interpretações equivocadas de seu significado. Buscar o entendimento das
reais necessidades dos usuários e traduzi-las em atributos do produto é
imprescindível para a obtenção de resultados adequados com a casa da
qualidade.
As características de engenharia ou requisitos de projeto, quando ade-
quadamente formulados, terão papel relevante para a solução dos proble-
mas e satisfação dos usuários. Na realidade, essas características da en-
genharia podem ser entendidas como os próprios problemas de projeto a
serem resolvidos. São elas que vão orientar a equipe de projeto na busca
de soluções alternativas e na avaliação das mesmas. Elas têm o propósito
de estabelecer os parâmetros, grandezas, funções, restrições, entre outros
atributos do produto, os quais “mapeiam” os problemas técnicos de um
dado contexto.
Em geral, cada requisito de projeto também possui uma unidade de
medição e um sinal qualificador da modificação desejada. Por exemplo, “+

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 224 — #252


i i

224 Projeto Integrado de Produtos: planejamento, concepção e modelagem

peso do produto (kg)” estabelece que a característica peso do produto (ou


da parte) é medida em quilogramas e que sua magnitude deve ser aumen-
tada (+) pela solução adotada. Para unidades de medição, deve ser empre-
gado o Sistema Internacional de Unidades (SI). Entretanto, nem sempre
se consegue definir uma característica de engenharia por meio de grande-
zas de base do SI ou suas derivadas e, nesses casos, nenhuma unidade é
adotada ou uma unidade percentual (qualitativa) é considerada. Já com re-
lação ao qualificador (+ ou -), ou seja, o que se deseja sobre dado requisito
de projeto, pode-se ter diferentes implicações.
Aumentar o peso de um produto, por exemplo, implica maior quanti-
dade de material e maiores custos, os quais podem ser características con-
flitantes entre si do ponto de vista do desenvolvimento global do produto.
Além disso, dependendo do tipo de produto, ou da parte estudada, peque-
nas variações de massa (peso) poderão comprometer o desempenho da
sua função (balanceamento/desbalanceamento de rotores, por exemplo).
Portanto, deve-se tomar cuidado e avaliar adequadamente o significado
e as implicações dos qualificadores das características de engenharia e o
compromisso decorrente deles. Essa análise será mostrada mais adiante,
no item que trata dos compromissos estabelecidos no “telhado” da casa da
qualidade (Campo VI).
O resultado da tradução dos requisitos dos usuários constitui-se, em
geral, numa lista de características de engenharia, ou seja, os requisitos de
projeto, que serão dispostos verticalmente nas colunas da matriz, em sua
parte superior no Campo III. Esses requisitos também podem ser agrupa-
dos e sistematizados para facilitar o entendimento e sua manipulação.
Vários autores têm tratado a tradução dos desejos dos consumidores
em características de engenharia, porém são poucos os métodos práticos
diretamente aplicáveis a esse fim. Encontra-se mais literatura sobre “o
quê” fazer do que “como” fazer. Entre as várias alternativas de práticas
para obter essa tradução, apresentam-se as seguintes:

• uso de glossário: lista de termos, atributos de produtos (Tabela 5.1),


cujas definições são baseadas no consenso da organização a respeito
de cada um dos requisitos de projeto;
• amostras: partes de produtos, filmes de vídeo, fitas de áudio, entre
outros, para que os membros da equipe tenham o “sentimento das
coisas” e para facilitar a declaração de suas características;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 225 — #253


i i

Especificações de projeto do produto 225

• organizações especiais: constituição de grupos de trabalho específi-


cos (internos ou externos), para tarefas dedicadas às traduções den-
tro da empresa;
• padronização: forma de caracterização comum de objetos de estudo,
utilizando códigos, siglas, palavras e frases, entre outros;
• medição: exprimir as coisas através de números de valores de medi-
das, para o que a modelagem e/ou experimentação são necessárias;
• análise do caráter crítico: tem por finalidade identificar poucas ca-
racterísticas, porém vitais (um conjunto mínimo) para prosseguir
com o desenvolvimento do produto. Os critérios empregados para
esse fim são: características essenciais à segurança; restrições legais;
características essenciais à vendabilidade; características que exigem
altos investimentos; características que exigem continuidade; carac-
terísticas que prolongam o lead time; características de áreas etica-
mente sensíveis; e características relacionadas à instabilidade do pro-
duto;
• Questionamentos: de acordo com o proposto por Blanchard e Fa-
brycky (1990), perguntas típicas que auxiliam na tradução dos re-
quisitos de usuários em requisitos de projeto são: o que o produto
deve realizar em termos de características de desempenho funcional
e operacional (faixa de operação, capacidade, fluxo, potência, con-
sumo etc.)?; qual é a vida útil esperada para o produto?; como o pro-
duto será usado em termos de horas de operação por dia, número de
ciclos por mês etc.?; como o produto será distribuído?; quais as ca-
racterísticas relativas à eficiência que o produto deverá exibir?; custo,
disponibilidade, confiabilidade, mantenabilidade etc.?; quais as ca-
racterísticas relacionadas ao meio ambiente que o produto deverá
possuir (temperatura, umidade, vibrações etc.)?; em que ambiente o
produto deverá operar?; como o produto será transportado, armaze-
nado e manipulado?; como será o descarte do produto?; o produto,
ou partes dele, pode ser reciclado?; quais os efeitos sobre o meio am-
biente?.

Observa-se que a conversão dos requisitos de usuários em requisitos


de projeto se constitui na primeira decisão sobre as características físicas
do produto sendo projetado. Essa ação definirá parâmetros mensuráveis,
associados às características finais que terá o produto sob análise, razão

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 226 — #254


i i

226 Projeto Integrado de Produtos: planejamento, concepção e modelagem

pela qual essa etapa constitui-se em um momento importante para o pro-


cesso de projeto em geral. É conveniente investir tempo e esforços nesta
tradução, usando as alternativas de práticas descritas acima.

5.3.8 Priorização dos requisitos de projeto

Uma vez definidos os requisitos de projeto, a atividade seguinte den-


tro do processo de desenvolvimento das especificações de projeto, é a clas-
sificação dos mesmos, ou seja, procura-se identificar a prioridade que se
deve dar, no desenvolvimento do projeto, à busca de soluções que aten-
dam a um requisito em detrimento de outros, se as ações forem de efeitos
contrários.
A primeira tarefa que a equipe de desenvolvimento deve realizar é a
análise dos requisitos de projeto e dos requisitos de usuários. Essa tarefa é
realizada na parte central da casa da qualidade (matriz de relacionamentos,
conforme Hauser e Clausing 1988), onde ocorre a interseção entre linhas e
colunas da matriz (Figura 5.3). Cada interseção corresponde a um relacio-
namento entre um requisito de projeto e um requisito de usuário.
O relacionamento entre entidades pode ser de vários tipos. Isso nor-
malmente é realizado pela comparação entre os atributos das entidades
consideradas. Os valores designados para o relacionamento podem ser
quantitativos ou qualitativos. Valores qualitativos são expressos por ad-
jetivos ou qualidades, que indicam quanto um dado atributo é ou não
melhor do que o outro. Isso é feito com base no conhecimento, na expe-
riência e intuição de quem estabeleçe as relações. Assim, quando se rela-
ciona qualitativamente um objeto A com um objeto B, relativo ao atributo
cor do produto, por exemplo, obter-se-á um resultado do tipo: a cor de
A é melhor do que a cor de B. Relacionamentos quantitativos, por outro
lado, dependem de dados mensuráveis, meios de medição e métodos de
modelagem e análise. Isso nem sempre é possível devido à natureza das
informações disponíveis, principalmente quando o produto ou suas partes
ainda não existem ou são pouco conhecidos.
No caso do relacionamento entre as necessidades dos usuários com as
características de engenharia, trata-se de informações de projeto ou decla-
rações que estabelecem as expectativas dos usuários e as descrições técni-
cas a respeito de um dado produto, respectivamente. Para que um relacio-
namento seja possível entre essas informações é necessário, em primeiro

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 227 — #255


i i

Especificações de projeto do produto 227

lugar, identificar quais são os atributos do objeto formulados nas declara-


ções.
Para tornar mais fácil o entendimento, considera-se o exemplo em que
um requisito do usuário, registrado no Campo II, seja de fácil e econô-
mica manutenção ou de alto grau de mantenabilidade. Supondo-se que
no Campo III houvesse os registros de requisitos de projeto seguintes: (-)
tempo médio entre falhas x (h); (-) tempo médio de manutenções correti-
vas y (h); (+) peças normalizadas z (%); (+) precisão de posicionamento i
(μm); (-) peso do equipamento de j (kg); e (-) mínimo número de peças k
(un.). Neste caso esses dados poderiam ser colocados na casa da qualidade,
como mostrado na Figura 5.5. Para analisar o relacionamento entre os dois
tipos de requisitos, verifica-se se os requisitos de projeto representam ou
expressam algum parâmetro ou se são uma forma de medir e avaliar o re-
quisito de usuário. Se o requisito de projeto tem um relacionamento forte,
médio, fraco ou nulo com um requisito de usuário.

Figura 5.5 Casa da qualidade com requisitos de usuários e de projeto parcial

Considerando-se os requisitos de projeto, a precisão de posiciona-


mento e o peso do equipamento, o mais provável é que não haja rela-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 228 — #256


i i

228 Projeto Integrado de Produtos: planejamento, concepção e modelagem

ção ou que a mantenabilidade não seja afetada, quando se pode valorar


esse relacionamento com o valor zero. O número de peças já pode afetar
ou melhorar a mantenabilidade. Com menos peças, geralmente, ocorrem
menos falhas, o estoque de peças de reposição é menor e menos peças
serão desmontadas e remontadas nos casos de falha. O valor de relacio-
namento poderia ser 1, designando um grau fraco. Uma solução onde se
procura adotar o maior número de peças normalizadas, em geral, melhora
a mantenabilidade. Componentes normalizados apresentam melhor pre-
cisão, maior confiabilidade, fornecimento mais rápido ou maior disponibi-
lidade no mercado e redução de ferramentas especiais. Nesse caso, o valor
do relacionamento pode ser avaliado em 3. Da mesma forma poderia ser
avaliado o relacionamento do tempo médio entre falhas e mantenabili-
dade. Mesmo que o tempo médio entre falhas seja pequeno, se o diagnós-
tico de falhas for fácil e rápido, ensejando uma simples reposição, ainda
se obtém uma razoável facilidade de manutenção. O valor do relaciona-
mento, também, poderia ser 3, como exemplifica a Figura 5.5. Por último,
o requisito de projeto de tempo médio de manutenção corretiva afeta con-
sideravelmente a mantenabilidade. O tempo médio de correção elevado
necessita de muita mão-de-obra e torna alto o custo da manutenção corre-
tiva, sendo 5 o valor deste relacionamento. Essa análise de relacionamento
é completada quando todas as células do Campo IV estiverem preenchi-
das.
Em geral, a atribuição de relacionamentos depende do consenso dos
integrantes da equipe de desenvolvimento do produto. Esse consenso é
obtido pela análise e por debates sobre cada uma das atribuições indivi-
duais. Estas últimas dependem, entretanto, do “sentimento” de cada pes-
soa a respeito dos parâmetros considerados.
As respostas dos consumidores, ou dados experimentais, também po-
dem ser utilizadas para atribuir valor a esses relacionamentos. Akao (1990)
salienta que, se possível, devem ser buscadas formas para efetuar os rela-
cionamentos com base em fatos ou análise estatística. Entretanto, caso isso
não seja possível, dependendo da natureza das informações e dos meios
disponíveis, o autor recomenda que sejam diferenciados, na matriz, aque-
les relacionamentos obtidos pela experiência, intuição, julgamento pró-
prio, entre outros, daqueles realizados pela análise de fatos ou experimen-
tação. Isso pode ser feito, por exemplo, com símbolos de diferentes tipos.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 229 — #257


i i

Especificações de projeto do produto 229

Além das dificuldades para estabelecer as relações entre as declarações


dos requisitos de usuários e as características de engenharia (os requisitos
de projeto), existe também perda de informações que ocorre após efetuado
o relacionamento. Seja pelo debate do grupo, pela experiência de seus in-
tegrantes, pelos resultados de sessões de brainstorming ou pela análise de
fatos ou dados experimentais, a relação obtida é representada através de
um valor numérico (ou por um símbolo), o qual atribui um grau de rela-
cionamento. Esse número (ou símbolo) parece insuficiente para expressar
todo o processo de raciocínio ou discussão que houve para chegar ao re-
sultado. Na mente de quem atribuiu um dado valor, provavelmente tenha
passado uma grande variedade de relações, analogias, processos e alter-
nativas, as quais não estão expressas naquele valor. Isso, de certa maneira,
é uma perda de informações sob dois aspectos: primeiro, aquelas infor-
mações pensadas poderiam levar a diferentes alternativas ou encaminha-
mentos para o problema e, segundo, elas dificilmente serão capturadas
por outra pessoa que examine os relacionamentos da casa da qualidade,
mas não tenha participado de seu processo de elaboração. Portanto, méto-
dos e meios para registrar e recuperar informações derivadas do processo
de raciocínio realizado para avaliar uma dada relação parecem ser um im-
portante problema potencial para futuros estudos ou tomadas de decisão
ao longo do processo de projeto do produto.
Não há regras genéricas que determinem o valor de um tipo de rela-
cionamento ou digam como se evitar as perdas de informações. Respostas
a esses problemas não são triviais pelo simples fato de que existem muitos
tipos de objetos, atributos e parâmetros que são tratados na engenharia e
de maneiras pelas quais as pessoas expressam suas necessidades ou dese-
jos.
O propósito para o relacionamento entre os desejos dos usuários e
as características de engenharia é a obtenção de indicativos (valores) de
quanto cada necessidade ou desejo do usuário afeta ou é afetado por um
dado parâmetro de engenharia. Esse valor é usado para quantificar outras
informações na casa da qualidade, como a importância dos requisitos de pro-
jeto. Os resultados dos relacionamentos assim obtidos e realizados na ma-
triz da casa da qualidade poderão auxiliar, também, em outras conclusões a
respeito do problema que está sendo estudado. Hauser e Clausing (1988),
por exemplo, estabelecem alguns princípios ou regras pelas quais podem
ser obtidas conclusões sobre os resultados dos relacionamentos efetuados:

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 230 — #258


i i

230 Projeto Integrado de Produtos: planejamento, concepção e modelagem

• se um requisito de projeto (característica de engenharia) não afeta


nenhum requisito de usuário, ou seja, todas as células da coluna têm
valor nulo, então esse requisito de projeto pode não ter significado
ou ser um parâmetro desnecessário;
• no caso de um produto sendo reprojetado ou no caso de engenha-
ria reversa, e se todas as células de uma coluna estiverem vazias, a
equipe de elicitação das necessidades pode ter esquecido de questio-
nar certo tipo de usuário;
• a simples soma dos valores dos relacionamentos em uma coluna do
Campo IV dá uma ordenação da importância dos requisitos de pro-
jeto para atender às necessidades dos usuários;
• efetuado o somatório, em cada coluna, do produto entre o valor do
relacionamento e o peso de importância porcentual do requisito do
usuário (determinado conforme exposto na Figura 5.4) tem-se uma
ordenação de prioridade dos requisitos de projeto de acordo com a
importância atribuída pelo usuário às suas necessidades e com a taxa
de melhoramento pretendida pela empresa. Esses resultados serão
registrados nas células da primeira linha do Campo VII da casa da
qualidade.

Com base nas discussões desse tópico, nota-se que relacionar desejos
dos usuários com as características de engenharia é uma tarefa com diver-
sas implicações e é fortemente dependente da experiência e dos conheci-
mentos dos integrantes da equipe de desenvolvimento. Não são muitos,
considerando-se a importância dos resultados dessa atividade, os méto-
dos, orientações ou regras que podem ser empregados para esse fim. Se
não houver consistência nos relacionamentos efetuados, as decisões toma-
das poderão comprometer as demais tarefas da casa da qualidade e a própria
qualidade das soluções obtidas para o problema.

5.3.9 Análise do relacionamento entre requisitos de projeto

No item anterior foi mencionada a importância da análise do relacio-


namento entre os requisitos dos usuários e os requisitos de projeto. Igual-
mente importante, é analisar as possíveis relações dos requisitos de pro-
jeto, o que é efetuado pela análise do Campo VI, ou o chamado “telhado”
da casa da qualidade (Figura 5.3).

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 231 — #259


i i

Especificações de projeto do produto 231

O processo de relacionamento efetuado no “telhado” da casa da qua-


lidade é semelhante àquele realizado entre os requisitos dos usuários e os
requisitos de projeto. Neste caso, entretanto, os objetos do relacionamento
são as próprias características de engenharia e os parâmetros nelas estabe-
lecidos. O propósito, aqui, é estabelecer o compromisso que existe entre as
características de engenharia. Esse compromisso, determinado pelo grau
de relacionamento, define quanto a alteração de um dado requisito de pro-
jeto influenciará em outro.
A Figura 5.6 reproduz o Campo VI (“telhado” da casa da qualidade) para
que se analise os principais conceitos e problemas a ele relacionados.

Figura 5.6 Representação dos relacionamentos entre requisitos de projeto no


“telhado” da casa da qualidade

De acordo com a Figura 5.6, será adotada uma escala de relaciona-


mento conforme os seguintes casos:
 - fortemente positivo: indica que, quando se efetua uma variação
para melhorar um requisito de projeto j, também melhorará fortemente o
requisito de projeto k. Por exemplo, se a qualidade de fabricação das peças
for melhorada, deverá haver, também, uma boa melhora na montagem
das mesmas.
f- medianamente positivo: similar ao anterior, entretanto, uma me-
lhora em um requisito m melhora o requisito de projeto o com menos in-
tensidade. Trata-se de um valor intermediário de relacionamento, ou que
define uma intensidade menor do relacionamento entre os parâmetros. A

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 232 — #260


i i

232 Projeto Integrado de Produtos: planejamento, concepção e modelagem

maior ou menor a intensidade do relacionamento atribuído dependerá da


experiência da equipe e de análises que possam ser efetuadas entre os pa-
râmetros considerados.
⊗ - fortemente negativo: este é um caso em que, se forem adotadas
medidas que melhoram o requisito de projeto i, deverá ocorrer uma consi-
derável piora no requisito de projeto l, ou seja, ocorrerão efeitos contrários
consideráveis entre os dois requisitos. Por exemplo, se forem adotadas me-
didas que melhorem a confiabilidade de um produto, é bem provável que
o custo de produção seja elevado com intensidade, pois nesse caso deve-
rão ser usados melhores materiais, processos de fabricação mais precisos,
redundâncias de componentes etc.
× - medianamente negativo: caso semelhante ao anterior, porém os
efeitos contrários entre os dois requisitos são de menor intensidade
- em branco: se uma célula foi deixada sem registro, isso significa
que não deve haver efeitos mútuos entre os requisitos de projeto.
Pelas observações anteriores, nota-se que a determinação de um dado
tipo de relacionamento entre as características de engenharia é dependente
de conhecimentos técnicos sobre o objeto de estudo. Trata-se de parâme-
tros ou variáveis de engenharia para as quais é necessário encontrar seus
conceitos e implicações.
Esse tipo de relacionamento pode ser considerado um pouco mais con-
creto do que aquele entre os requisitos de usuários e os requisitos de pro-
jeto, vistos no Campo V, pois é mais fácil verificar se existem implicações
diretas ou indiretas entre os parâmetros em relacionamento. As unidades
de medição também ajudam nesse propósito. Adicionalmente, essa tarefa
pode ser auxiliada por modelos matemáticos que relacionem as variáveis
de estudo. Com tais modelos, podem ser efetuadas análises de sensibili-
dade, por exemplo, para verificar influências nas variações dos parâme-
tros. Isso, entretanto, pode levar a estudos especializados do problema,
exigindo conhecimentos e facilidades adicionais. Dependendo do tipo de
problema, essa opção deve ou não ser considerada.
Da mesma forma que não se encontram métodos práticos ou regras
para auxiliar nos relacionamentos do Campo V, o mesmo ocorre para o
caso de relacionamentos entre as próprias características de engenharia.
Em geral, encontram-se recomendações sobre o que deve ser feito e o tipo

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 233 — #261


i i

Especificações de projeto do produto 233

de escala a ser empregada. Pelo fato de essa tarefa envolver uma quanti-
dade maior de conhecimentos técnicos, a perda de informações será pro-
vavelmente maior, principalmente se a leitura dos resultados for feita por
pessoal não especializado ou menos experiente.
Outro aspecto pouco tratado com relação ao “telhado” da casa da qua-
lidade é o que se refer à sua efetiva utilização no desenvolvimento do pro-
duto. Em princípio, os relacionamentos obtidos têm o propósito de auxi-
liar na análise de compromissos entre as características de engenharia e,
com isso, verificar quais serão as implicações quando algum atributo do
produto for alterado. Para que isso seja efetivo, o engenheiro deverá com-
parar constantemente suas propostas de soluções com os relacionamentos
constituídos no “telhado” ou memorizá-las o suficiente para que as solu-
ções contemplem aqueles relacionamentos. Se o número de características
for reduzido, isso parece não constituir grandes dificuldades; entretanto,
para problemas maiores, o gerenciamento e a efetiva utilização das infor-
mações do “telhado” poderão ser comprometidos ou subestimados.
Para evitar ou minimizar essas dificuldades devem ser estudados
meios pelos quais as informações dos relacionamentos no “telhado” da
casa da qualidade possam ser transformadas em parâmetros quantitativos
que orientem a solução do problema de projeto. Trata-se, por exemplo, do
emprego daquelas informações similarmente àquele realizado com os re-
lacionamentos entre os desejos e características da engenharia, os quais
são utilizados para estabelecer a ordem de importância de cada caracterís-
tica da engenharia.
Para a ordenação da importância dos requisitos de projeto, Ogliari
(1999) propõe que sejam adotadas as seguintes alternativas de métodos:

1. Ordenação simplificada, em que a ordem de importância dos requi-


sitos de projeto seja estabelecida adotando-se a soma dos valores de
relacionamentos contidos nas colunas da matriz do Campo V utili-
zando a equação:
n
RPi = vj,i (5.3)
j=1

onde RPi é o somatório dos valores numéricos vj,i , registrados na


coluna i, e n, o número total de linhas da matriz ou o número de
requisitos do usuário.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 234 — #262


i i

234 Projeto Integrado de Produtos: planejamento, concepção e modelagem

2. A classificação dos requisitos leva em consideração os pesos dos re-


quisitos dos usuários pru, registrados no Campo V, conforme mos-
trado na Fig. 5.2, e os valores dos relacionamentos vi,j entre os requi-
sitos de usuários e os requisitos de projeto. A equação, adotada para
determinar o valor de importância de cada requisito de projeto, é:
n

RPj = prui × vi,j (i = 1 a n e j = 1 a m) (5.4)
i

onde RPj é o valor de importância do requisito de projeto j; prui é


o peso de importância porcentual do requisito do usuário i; vi,j é o
valor do relacionamento entre o requisito de projeto j e o requisito
de usuário i, sendo m o número total de requisitos de projeto.

Os valores calculados pelas equações 5.3 e 5.4 podem ser registrados


diretamente em linhas no Campo VII. Uma alternativa é o registro de va-
lores normalizados e então ordenados. Experiências realizadas por Ogliari
(1999) demonstraram que a classificação obtida pelas duas relações ante-
riores apresenta semelhança.

5.3.10 Conversão dos requisitos de projeto em


especificações de projeto

Como já foi mostrado no item 5.3.7, os requisitos de projeto foram des-


critos de forma resumida para um preenchimento mais fácil no Campo
V da casa da qualidade. Esses requisitos de projeto devem ser redigidos
de forma mais detalhada para que sejam compreensíveis aos diferentes
usuários. Além disso, para cada requisito de projeto devem ser previstas
grandezas mensuráveis e meios ou métodos de verificar se a solução a
ser desenvolvida atenderá a esse requisito de projeto. Outros dados ne-
cessários para completar a redação de cada especificação de projeto são
os possíveis efeitos negativos ou riscos decorrentes da busca de soluções
para implementar a respectiva especificação.
As especificações de projeto com a classificação, em ordem decres-
cente, obtida conforme descrito no item anterior, juntamente com o modo
de verificação e os possíveis riscos, são apresentadas na forma da Tabela
5.2.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 235 — #263


i i

Especificações de projeto do produto 235

Tabela 5.2 Apresentação das especificações de projeto do produto

Descrição das Modo de


Classificação Possíveis riscos
especificações verificação
a
1
2a
3a
...
...
enésima

As especificações de projeto são o resultado final do processo de trans-


formação das necessidades dos usuários e são freqüentemente citadas
como a parte mais importante do desenvolvimento do produto. Sendo as-
sim, para que sejam válidas e úteis deve-se tomar todo o cuidado na re-
dação das mesmas. No próximo item serão apresentadas orientações para
essa redação.

5.3.11 Redação das especificações de projeto

Requisitos ou especificações de projeto estabelecem algo que é neces-


sário, verificável e atingível. Para ser verificável, a especificação deve de-
clarar algo que pode ser aferido por exame, análise, teste ou demonstração.
Se uma especificação não é atingível, não há razão para redigi-la. Uma boa
especificação deve ser claramente declarada.
Na redação da especificação é preciso verificar se existe uma necessi-
dade para a mesma e questioná-la. O que poderia acontecer se a especi-
ficação não fosse incluída e atendida. Se a resposta não trouxer nenhuma
conseqüência, provavelmente a especificação não é necessária.
Uma declaração da especificação deve incluir uma forma de verifica-
ção e um critério de aceitação da mesma. A especificação deve ser alcançá-
vel tecnicamente e compatível com o orçamento, a programação e outras
restrições. Se houver dúvidas sobre a viabilidade técnica da especificação,
pesquisas ou estudos devem ser conduzidos para verificar a sua viabili-
dade. E mesmo se houver viabilidade técnica é possível, ainda, que ela
não seja atingível devido a restrições de custo, orçamento, cronograma,
peso, materiais adequados etc. Neste caso, não há razão para redigir a cor-
respondente especificação.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 236 — #264


i i

236 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Se a especificação for necessária, verificável e viável, então a redação


deve expressar um único pensamento, ser concisa e simples. Uma especi-
ficação não deve apresentar dúvidas de interpretação e ser ambígua. Em
geral, frases simples e curtas são suficientes para a apresentação de boas
especificações.
Na redação das especificações, além da declaração da especificação e
da descrição do modo de avaliação, devem ser apresentados os possíveis
resultados negativos, como já mencionados no item anterior.
Hooks (1993) sugere, para a redação dos requisitos e especificações de
projeto, tomar certos cuidados e adotar as seguintes orientações:

• evitar suposições ruins ou erradas;


• redigir requisitos ou especificações (o que fazer) e não formas de im-
plementação (como fazer);
• descrever especificações e não operações do produto a ser desenvol-
vido;
• adotar termos precisos e com sentidos positivos;
• adotar, nas sentenças, boa gramática e estrutura correta;
• evitar esquecer especificações;
• evitar o superdimensionamento ou a redundância das especificações
de projeto.

Suposições errôneas ocorrem porque o redator não teve acesso a sufi-


cientes informações ou a informação não existe. Para eliminar o primeiro
problema, desde o início do levantamento das informações, devem ser re-
gistrados dados relativos ao produto, tais como: necessidades, metas, ob-
jetivos, restrições, missões ou perfis de operação, orçamento, cronograma
e aspectos de gerenciamento e de organização.
Na redação de uma especificação de projeto deve-se declarar “o que” é
necessário e não “como” algo deve ser realizado ou provido. No momento
de redigir a especificação, e para evitar o erro, o redator deve perguntar-se
“por que” necessita dessa especificação. Ao fazer essa pergunta, o autor
pode definir todas as necessidades a que o sistema deve atender e, assim,
declarar a real especificação.
A linguagem a ser usada na redação das especificações é de extrema
importância. Recomendam-se frases curtas com os verbos ser, estar ou ter,

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 237 — #265


i i

Especificações de projeto do produto 237

seguidos de substantivos, ou com verbos formadores de funções do pro-


duto. Uma boa prática é definir os termos utilizados em um glossário.
A granulação das especificações é outro aspecto importante na reda-
ção. Frases longas e narrativas devem ser evitadas, pois estas podem con-
ter vários requisitos ou especificações. Isso se consegue quando se evita as
conjunções “e” e “ou” nas frases. Outra forma de evitar frases com múlti-
plas especificações é obtida com o exercício de estabelecer testes de verifi-
cação do conteúdo da frase. Se forem necessários vários tipos de testes de
avaliação, é provável que se tenham várias especificações na declaração.
A citação repetida de uma especificação em diferentes declarações
também deve ser evitada. A citação repetida torna mais fácil a leitura, mas
dificulta a manutenção do documento de especificações se houver mudan-
ças ao longo do processo.
Ao seguir essas orientações na redação e efetuando revisões formais
ou informais, obtém-se um conjunto de especificações mais apropriado ao
projeto e ao teste do produto, bem como maior satisfação dos usuários.

5.4 Qualidades das especificações de projeto


Neste item serão analisadas as qualidades que distinguem boas espe-
cificações daquelas que apresentam problemas. Conforme Bahill e Dean
(1997) e Wiegers (1999), as características da boa qualidade das especifica-
ções podem ser avaliadas pelos seguintes aspectos:
Descrição de “o que” e não “como”: a primeira e importante carac-
terística de uma especificação de projeto é a de que ela deve descrever o
que o sistema deve fazer, mas não especificar como o sistema deve fazer. A
especificação não deve apresentar soluções preconcebidas para o produto
a ser desenvolvido. Para chegar a esse resultado, é precio questionar por
que a especificação é necessária e então derivar os reais requisitos.
Atomicidade: a especificação deve ser suficientemente fracionada ou
detalhada, isto é, deve haver um único propósito, uma idéia por especifi-
cação. Cada especificação deve ser alocada em uma única entidade física.
É aceitável designar duas ou mais especificações a uma única entidade ou
componente físico.
Identidade única: uma especificação deve ter uma única denominação
em um único conteúdo. Deve-se evitar repetir as especificações em seu
conjunto e não usar sinônimos.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 238 — #266


i i

238 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Detalhamento: o maior ou menor detalhamento de uma especifica-


ção depende da audiência ou dos fornecedores. Para comunicações inter-
nas ou com fornecedores com procedimentos bem definidos, a linguagem
pode ser de alto nível, mas, quando se trata de fornecedores sem essas
capacidades, as especificações devem ser desdobradas em um fino deta-
lhamento.
Correção: cada especificação deve descrever a funcionalidade do pro-
duto de forma correta. A referência para a correta definição da especifi-
cação é sua origem nos usuários do produto. Somente os representantes
dos usuários podem determinar a correção das especificações; por isso, é
importante incluí-los na revisão das mesmas.
Documentada e acessível: a especificação deve ser documentada (es-
crita, figura, filme, dado) e estar disponível. Se houver confidencialidade,
cada especificação deve indicar o seu status e quem pode ter acesso à
mesma.
Viabilidade: é necessário que cada especificação seja passível de im-
plementação dentro das capacidades e limitações do sistema em desenvol-
vimento e de seu meio ambiente. Para garantir a viabilidade das especifi-
cações, os profissionais da equipe de desenvolvimento devem participar
da elicitação das necessidades e realizar uma análise do que é ou não viá-
vel tecnicamente e o que só pode ser efetuado com altos custos ou outros
resultados negativos.
Rastreabilidade: cada especificação deve documentar algo que os
usuários realmente necessitem ou algo que seja requerido para o produto
se conformar a uma especificação externa, uma interface ou uma norma.
Outra forma de constatar essa qualidade da especificação é verificar se a
mesma teve origem em uma fonte legítima. A origem de cada especifica-
ção deve ser rastreada, seja uma norma, seja a entrada de um dos possíveis
usuários diretos ou indiretos.
Priorizável: a cada especificação deve haver a possibilidade de atribuir
prioridade de implementação no produto, baseada principalmente nos va-
lores de importância atribuídos pelos usuários do projeto ou do produto,
no custo relativo de sua implementação e nos riscos técnicos associados. Se
todas as especificações são consideradas igualmente importantes, torna-se
mais difícil ao gerente do projeto tomar decisões quando houver cortes no
orçamento, novas necessidades forem adicionadas, o cronograma for ul-
trapassado ou ocorrerem mudanças na equipe de projeto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 239 — #267


i i

Especificações de projeto do produto 239

Unicidade: o leitor da declaração de uma especificação deve extrair


uma única interpretação, ou diferentes leitores devem chegar à mesma
conclusão. Uma linguagem natural é muito propensa à ambigüidade. Ter-
mos são ambíguos porque são subjetivos e podem significar coisas di-
ferentes para cada um que lê a especificação. Devem ser evitadas pala-
vras como: amigável, fácil, simples, rápido, suficiente, adequado, eficiente,
estado-da-arte, melhorado, máximo ou mínimo. Diferentes leitores terão
avaliações diversas desses termos.
Consistência: o conjunto de especificações ou a especificação, indivi-
dualmente, não deve apresentar contradições e sim coerência lógica em
um pensamento, com fundamentação, estabilidade e veracidade.
Quantificável: deve-se, na medida do possível, atribuir valores quan-
titativos às especificações de projeto. Deve-se especificar um atributo de
um sistema a ser projetado. Sem uma quantificação, pode ocorrer eleva-
ção de custo devido a um superdimensionamento ou o valor necessário
não é atingido.
Verificabilidade: sendo quantificável, devem ser previstos testes, usos,
aplicações, inspeções ou demonstrações para verificar se cada especifica-
ção foi devidamente implementada no produto. No caso de a especificação
não ser verificável ou mensurável, a constatação de sua implementação
torna-se uma questão de opinião.
Completeza: no conjunto das especificações ou informações não de-
vem ocorrer omissões. Completeza também deve ser uma qualidade na
declaração individual de uma especificação. É difícil dizer se o conjunto
de especificações ou uma especificação individual está completo ou não.
Algumas recomendações para melhorar essa qualidade são:

• evitar que a equipe de levantamento das necessidades e de redação


dos requisitos ou especificações concentre o foco em uma parte do
produto em desenvolvimento;
• focalizar as atividades dos usuários do produto;
• sistematizar, classificar ou agrupar as especificações por áreas de co-
nhecimento ou por atributos do produto.

Flexibilidade: um conjunto de especificações não deve ser conside-


rado imutável ou definitivo. Deve ser revisado quando necessário e a his-
tória das modificações, mantida. Para que as especificações sejam mais

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 240 — #268


i i

240 Projeto Integrado de Produtos: planejamento, concepção e modelagem

flexíveis, estas devem ser classificadas univocamente e expressas separa-


damente umas das outras, de modo a serem referenciadas sem ambigüi-
dades.
Aprovação: toda especificação de projeto deve ser formalmente apro-
vada, constando por quem e quando foi aprovada.

5.5 Considerações gerais sobre o processo de


obtenção das especificações de projeto

A primeira consideração de caráter geral é que, na transformação das


necessidades dos consumidores ou usuários em especificações de projeto,
é preciso tomar certos cuidados especiais para evitar que determinados
fatores prejudiquem esse processo:

• adotar uma solução ou tecnologia específica muito cedo, sem antes


buscar concepções alternativas ou efetuar análises de compromisso.
Isso leva a uma solução sem um bom entendimento do problema de
projeto;
• entender que o produto deve ser extremamente inovador. Muitos
produtos de sucesso não são mais que pequenos incrementos de mo-
delos anteriores. Objetivos muito elevados levam a grandes riscos e
tornam-se inacessíveis à equipe e à empresa;
• declarar uma especificação de projeto em termos muito genéricos.
Se uma especificação não pode ser medida e testada, não há como a
equipe avaliar progressos alcançados;
• aceitar as sugestões de consumidores ou do pessoal de marketing
como as únicas e finais entradas para projeto do produto. Podem ha-
ver requisitos superdimensionados ou soluções preconcebidas, de-
vendo a equipe tomar certas precauções;
• haver contínuas modificações nas declarações do problema a ser de-
senvolvido. Requisitos que mudam ao longo do tempo levam a mu-
danças no projeto e induzem a gerência a freqüentes redireciona-
mentos dos esforços;
• tornar as especificações de projeto muito complexas e detalhadas.
Dessa forma ocorrem mais conflitos, generalizações, informações in-
completas e mais especializações serão necessárias;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 241 — #269


i i

Especificações de projeto do produto 241

• desenvolver somente um conjunto de especificações para todos os


usuários. Atualmente, os usuários buscam estabelecer suas próprias
especificações de produtos.

Outro aspecto importante a considerar pela equipe de desenvolvimen-


to do produto é a verificação do grau de completeza do conjunto de es-
pecificações. Para tal, recomenda-se confrontá-lo com possíveis fontes de
especificações. A Tabela 5.3, conforme Bahil e Dean (1997), indica possí-
veis fontes que podem ser adotadas como referências para verificar se não
houve omissões.

Tabela 5.3 Fontes típicas de requisitos de produtos industriais

Categorias de
Item Comentários gerais
especificações
As especificações de projeto mais comuns são
1 Entradas e saídas aquelas que relacionam as entradas e as saídas de
um sistema
As especificações de tecnologias geralmente
2 Tecnologia indicam componentes que devem ou não ser
usados
São as especificações que definem quantidades,
3 Desempenho
qualidades, tempos e habilidades de desempenho
Custos de mão-de-obra, materiais e financeiros ao
4 Custo
longo do ciclo de vida
Os testes de verificação requerem condições do
5 Teste do sistema ambiente e de aplicação de sensores e
instrumentos de medidas
Política da A política da empresa leva a declarações de
6
empresa necessidades específicas
O retorno sobre investimento e participação no
Prática de
7 mercado leva a diversas necessidades de custos e
negócio
tecnologias
Projetos de grande porte e complexidade têm
Gerenciamento
8 necessidades gerenciais diversas para o seu
de projeto
sucesso
Explicita características que agradem aos usuários,
9 Marketing incluindo demandas ainda não declaradas pelos
mesmos
Continua na próxima página

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 242 — #270


i i

242 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 5.3 Fontes típicas de requisitos de produtos industriais

Categorias de
Item Comentários gerais
especificações
Processos de Necessidades de diferentes processos de
10
manufatura fabricação, níveis de precisão e menos poluentes
A equipe de projeto deve ter competências e
11 Equipe de projeto
motivações para o seu desenvolvimento
Requer necessidades de arranjos e materiais
12 Confiabilidade especiais e afeta as exigências de manutenção e
de segurança
Várias necessidades podem resultar de exigências
13 Segurança de normas e políticas do processo de
desenvolvimento e uso do produto
Há necessidades de origem em leis e normas,
14 Meio ambiente preocupações de comunidades, nome da
empresa e possíveis prejuízos financeiros
Experiências com produtos anteriores podem
15 Herança
resultar em necessidades a serem atendidas
Muitos desejos dos usuários, em termos de estética
16 Intangíveis e de prestígio, são difíceis de quantificar, mas
devem ser analisados
Muitas necessidades não são mencionadas por se
17 Senso comum
entender que sejam óbvias e de senso comum
Além de leis e normas aprovadas, os projeto de leis
Leis, normas ou
18 e de normas devem ser objeto de busca de
projetos de lei
necessidades de usuários
Estudos dos perfis de uso, fluxos de trabalho e dos
19 Consumidor próprios usuários são as principais fontes de
necessidades

Outro aspecto de ordem geral para o qual convém alertar é a diversi-


dade de usos das especificações de projeto desenvolvidas neste capítulo.
Algumas já foram citadas e outras são as seguintes:

• base para definir as funções e os atributos de desempenho do pro-


duto;
• base para o estabelecimento de critérios de seleção de princípios, ma-
teriais, processos, procedimentos e soluções de partes ou da concep-
ção como um todo;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 243 — #271


i i

Especificações de projeto do produto 243

• referências para avaliação e aprovação, no final de cada fase, do de-


senvolvimento do produto;

• principais pontos de partida no planejamento e execução de testes


de validação do produto;

• especificações de projeto do produto, como um todo, serão usadas


como referências para o desdobramento nas especificações de pro-
jeto dos subsistemas até o nível de peças. As especificações assim
desdobradas devem ser alocadas nos subsistemas de modo a com-
por a especificação global do produto. Como exemplo, o custo total
do produto deve ser composto pelos custos desdobrados ao nível de
subsistemas ou componentes.

5.6 Resumo

No presente capítulo foi apresentada a metodologia de transformação


das necessidades dos usuários em especificações de projeto do produto a
ser desenvolvido. Os principais aspectos tratados são os seguintes:

1. A atividade de elaboração das especificações de projeto é o principal resul-


tado da fase de projeto informacional e tem recebido uma grande atenção
de pesquisadores e de profissionais de projeto, o que tem resultado em di-
versas propostas de metodologias para transformar, sistemática e progressi-
vamente, a partir do planejamento do produto, as necessidades dos consu-
midores em requisitos dos usuários e estes em requisitos e especificações de
projeto do produto.
2. Os principais benefícios obtidos com a elaboração sistemática das especifi-
cações de projeto são os seguintes: especificações de melhor qualidade, em
termos de precisão e completeza; desenvolvimento de vários métodos e fer-
ramentas que podem ser adotados nas diversas atividades de coleta e trans-
formação das informações pertinentes; aprofundamento do estudo da equipe
de projeto e maior entendimento das necessidades de todos os envolvidos
no ciclo de vida do produto; especificações reduzem custos e tempos de de-
senvolvimento; constituição da base de todas as decisões a serem tomadas;
desdobramento funcional, planejamento das atividades de projeto e dos tes-
tes do produto facilitados.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 244 — #272


i i

244 Projeto Integrado de Produtos: planejamento, concepção e modelagem

3. Para as denominações de consumidores e de clientes, é adotado o termo


usuário, que representa todas as pessoas e organizações que, de alguma
forma, têm interesse ou serão afetados pelo produto ao longo de seu ciclo
de vida. Assim, serão considerados usuários os consumidores, operadores,
pessoal de assistência técnica, compradores, revendedores, bancos, agências
financiadoras, órgãos de governo, comunidades, órgãos reguladores, possí-
veis vítimas, empresas de reciclagem, equipe de projeto, fabricantes, forne-
cedores de matéria-prima e de componentes, colaboradores envolvidos na
fabricação, na embalagem e manipulação, sindicatos, empresários e acionis-
tas.
4. A necessidade do usuário é a palavra ou a frase que expressa o que o usuário
precisa, sua vontade, desejos e expectativas. É geralmente expressa em uma
linguagem natural e livre dos consumidores, sem nenhuma padronização
de termos e classificações. A identificação e a coleta das necessidades dos
usuários é a primeira atividade de projeto do produto e, também, a atividade
mais crítica de todo o processo, pois essas necessidades são a voz do consu-
midor, a qual deve ser atendida em primeira prioridade; as demais atividades
e decisões são decorrências.
5. Requisitos dos usuários são o resultado da transformação, do agrupamento,
compactação e classificação das necessidades dos usuários para serem de fá-
cil visualização e adoção pelos planejadores e membros da equipe de projeto
e expressam atributos de qualidade do produto, geralmente de forma quali-
tativa.
6. Requisitos de projeto são resultados de transformações, desdobramentos
ou agrupamentos de requisitos dos usuários e são declarações compactas
dos atributos do produto, aos quais são, geralmente, atribuídos parâmetros
quantitativos.
7. Especificações de projeto são transformações dos requisitos de projeto aos
quais são atribuídas prioridades, definidos meios de avaliação e os riscos de
implementação.
8. As necessidades relacionadas ao desenvolvimento do produto têm origem
em diversos usuários, os quais desenvolvem atividades ou demonstram in-
teresses ao longo das fases do ciclo de vida do produto e são classificados em
usuários externos, intermediários e internos. Os usuários externos e inter-
mediários são as pessoas ou organizações que estão envolvidas na comercia-
lização, uso ou consumo, manutenção e reciclagem, portanto, interessados

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 245 — #273


i i

Especificações de projeto do produto 245

nos atributos do produto. Os usuários internos são os que desenvolvem e


implementam o projeto, logo, mais interessados nos atributos ou nas quali-
dades do projeto.
9. Os principais métodos utilizados para elicitação das necessidades dos usuá-
rios são: entrevistas estruturadas com usuários; parcerias ou alianças no
projeto; informações de consultores e especialistas; método de Delphi; ses-
sões de brainstorming; experiências pessoais e da empresa; análise de per-
fis de uso; pesquisa em material publicado e método do desdobramento da
função qualidade – QFD.
10. O método QFQ, além de apoiar a elicitação, documentação e visualização
das necessidades dos usuários, é usado no processamento e transformações
das mesmas, sucessivamente em requisitos de usuários, requisitos de pro-
jeto, priorização dos requisitos de projeto e sua transformação final em es-
pecificações de projeto, como proposto na metodologia deste capítulo.
11. As especificações de projeto de um produto devem apresentar declarações
que necessitam: descrever “o que” o produto deve fazer e não “como” fa-
zer; ser atômicas e não compostas; ter identidade única e detalhamento
apropriado ao entendimento do destinatário; ser corretas na expressão da
realidade; estar documentadas e acessíveis durante o desenvolvimento do
produto; apresentar viabilidade técnica e econômica na sua implementação;
apresentar rastreabilidade de sua origem; ser priorizável; permitir interpre-
tação única; ter consistência; ser quantificáveis; ser verificáveis; apresentar
um conjunto completo de especificações, sem omissões; oferecer flexibilidade
quando as modificações são necessárias; e ser aprovadas formalmente.

5.7 Problemas e temas de discussão

1. Descreva, resumidamente, as razões que tornam tão importante a


atividade de definição das especificações de projeto do produto.
2. Quais são as atividades do processo de desenvolvimento das espe-
cificações de projeto do produto? Descreva as entradas, as saídas e a
atividade para realizar a respectiva transformação.
3. Apresente uma breve definição dos seguintes termos: necessidades
dos usuários; requisitos dos usuários; requisitos de projeto; e especi-
ficações de projeto do produto.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 246 — #274


i i

246 Projeto Integrado de Produtos: planejamento, concepção e modelagem

4. Por que é imprescindível definir o ciclo de vida do produto, como


referência, na atividade de elicitação das necessidades dos usuários?
5. Quais são os principais aspectos que diferenciam o processo de defi-
nição das especificações, nos casos de projeto de inovação e projeto
reverso?
6. Faça uma breve descrição dos principais métodos usados para a eli-
citação das necessidades dos usuários.
7. Descreva brevemente as etapas de registro e de processamento dos
dados na casa da qualidade, ou da primeira matriz do método da fun-
ção de desdobramento da qualidade – QFD.
8. Descreva o processo de tradução dos requisitos de usuários em re-
quisitos de projeto. Quais são as diferenças de características desses
dois tipos de requisitos?
9. Qual é o objetivo da análise de relacionamento entre os requisitos de
projeto e os requisitos de usuários?
10. Quais são os objetivos da análise do relacionamento entre os requi-
sitos de projeto no “telhado” da casa da qualidade?
11. Quais são as principais recomendações que devem ser seguidas na
redação das especificações de projeto?
12. Cite, em ordem de prioridade, as cinco principais qualidades neces-
sárias às especificações de projeto. Justifique a lista de especificações
e a ordenação apresentada.
13. Desenvolva o processo de definição das especificações de projeto de
um produto. Exemplos: bicicleta; prancha de surfe; bote de recreio;
ou outro equipamento de livre escolha.
14. Quais são as principais armadilhas que podem prejudicar a quali-
dade das especificações de projeto de produtos?
15. Quais são os principais e possíveis usos das especificações de projeto
ao longo do processo de desenvolvimento do produto?

5.8 Referências bibliográficas

AKAO, Y. Quality function deployment: integrating customer requi-


rements into products design. Cambridge: Productivity Press, 1990.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 247 — #275


i i

Especificações de projeto do produto 247

BAHILL, A. T.; DEAN, F. F. Discovering system requirements. Dispo-


nível em: <http://www.sie.arizona.edu/sysengr/requirements/in
dex.html>. Acesso em: 25/1/2007.
BLANCHARD, B. S.; FABRYCKY, W. J. Systems engineering and analy-
sis. New Jersey: Prentice Hall, 1990.
FONSECA, A. J. H. Sistematização do processo de obtenção das es-
pecificações de projeto de produtos industriais e sua implemen-
tação computacional. Florianópolis, 2000. 180f. Tese de Doutorado,
PPGEM – UFSC.
HARWELL, R.; ASLAKSEN, E.; HOOKS, I.; MENGOT, R.; PTACK, K.
What is a requirement? 1993. Disponível em: <http://www.afis.fr
/nav/gt/ie/doc/Articles/WHAT_IS_. HTM>. Acesso em: 25/1/
2007.
HAUSER, J.R.; CLAUSING, D. The house of quality. Harvard Business
Review, p.63-73, May-June, 1988.
HOOKS, I. Writing good requirements. Proceedings of the Third Inter-
national Symposium of the NCOSE. v.2, 1993, 8p. Disponível em:
< http://www.complianceautomation.com/papers/writingreqs.
htm>. Acesso em: 25/1/2007.
KARLSSON, C.; NELLORE, R.; SÖDERQUIST, K. Black box enginee-
ring: redefining the role of product specifications. Journal of Product
Innovation Management. v.15, n.6, p.534-549, 1998.
MCKAY, A.; PENNINGTON, A.; BAXTER, J. Requirements manage-
ment: a representation scheme for product specifications. Computer-
Aided Design. v.33, n.7, p.511-520, 2001.
OGLIARI, A. Sistematização da concepção de produtos auxiliada por
computador com aplicações no domínio de componentes de plás-
tico injetado. Florianópolis, 1999. 349f. Tese de doutorado – PPGEM
– UFSC.
REICH, Y. AI-supported quality function deployment. Proceedings the
of Fourth International Workshop on Artificial Intelligence in Eco-
nomics and Management, IFAC, 1996.
SWANSON, D. A.; HAUSER, J. R. The voice of the customer: how can
you be sure you know what customers really want?. I Pacific Rim

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 248 — #276


i i

248 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Symposium of Quality Function Deployment. 1995. MacQuarie


University, NSW Australia. Proceedings.
ULLMAN, D. G. The mechanical design process. Singapore: McGraw-
Hill, 1992
WIEGERS, K. E. Writing quality requirements. Disponível em: <http:
//www.processimpact.com/articles/qualreqs.html>. Acesso em:
25/1/2007.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 249 — #277


i i

Parte III

Projeto conceitual –
geração de soluções

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 250 — #278


i i

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 251 — #279


i i

Capítulo 6

Síntese de soluções alternativas –


inovação do produto

6.1 Introdução ao processo de inovação


do produto

No Capítulo 5 foram descritas formas e métodos de elaboração das


especificações do projeto e, como foi visto, o conjunto das especificações é
uma descrição das características que o produto deve ter. A etapa seguinte
é a geração de soluções alternativas que atendam às especificações defini-
das. A equipe de projeto deve, no início desse trabalho, ter por objetivo
a criação de várias soluções alternativas para o mesmo problema. Assim,
pode comparar e combinar soluções e, ao longo do processo de projeto,
selecionar a melhor e mais inovadora concepção para o produto.
Para alcançar esse objetivo, a equipe de projeto precisa ser criativa e,
para tal, recomenda-se usar métodos ou procedimentos que permitam ob-
ter, de forma rápida, um conjunto de soluções inovadoras. Com o objetivo
de identificar indivíduos criativos, suas capacidades ou características e
o modo como procedem quando chegam a soluções criativas, muito se
tem pesquisado e publicado sob o rótulo de criatividade. O presente ca-
pítulo não tem por finalidade aprofundar-se sobre o tema da criatividade,
mas orientar o leitor sobre aspectos do chamado processo criativo, des-
crevendo alguns métodos ou procedimentos que se mostraram úteis na
obtenção de um conjunto de soluções, de forma mais rápida e resultados
mais inovadores.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 252 — #280


i i

252 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Entende-se por criatividade a habilidade dos membros da equipe de


ter idéias novas e úteis para resolver o problema proposto ou de sugerir
soluções para a concepção de um produto. Produtos, processos, soluções
de problemas e idéias criativas devem possuir as seguintes qualidades:
apresentar novidade, ser única; ser útil ou apreciada e simples.
Quanto ao processo de criação ou de geração de concepções, este pode
ser descrito pelos seguintes passos (Back, 1983):

• preparação: o ponto de partida é a formulação do problema e a busca


de informações ou de habilidades. A formulação do problema con-
siste na elaboração das especificações de projeto, já descrita no Capí-
tulo 5. A busca de informações pode ser bastante ampla, abrangendo
fontes diversas: natureza; revistas técnicas; livros; textos; bancos de
patentes; benchmarking; produtos existentes no mercado; folhetos e
manuais de produtos; consumidores; especialistas; associações de
profissionais; relatórios governamentais; feiras de amostras; inter-
net; serviços de pesquisas e outras fontes;
• esforço concentrado: encontrar soluções requer um trabalho árduo.
Freqüentemente se ouve que a solução é encontrada com muito mais
transpiração do que inspiração. Para que essa etapa do processo cria-
tivo seja mais eficiente, sugere-se o uso dos chamados métodos de
criatividade que, em sua maioria, recomendam a geração de idéias
em quantidade sem se preocupar com restrições de viabilidade de
qualquer natureza e de domínios de conhecimento;
• afastamento: como foi dito no passo anterior, é necessário um es-
forço concentrado. Às vezes, tem-se dificuldade em obter uma solu-
ção porque o problema talvez esteja sendo sempre enfocado sob a
mesma ótica ou método. Nesse caso, é conveniente um afastamento
temporário;
• visão: após um período de afastamento, mesmo curto, e que pode
ser ocupado com outra atividade, quando se volta ao problema é
provável que o mesmo seja visto sob outro ângulo ou enfoque. Esse
procedimento de afastamento e visão pode não ser tão linear, mas
repetido até que seja encontrada uma solução. Antes de cada passo
de visão é necessária uma análise e organização dos resultados já
alcançados;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 253 — #281


i i

Síntese de soluções alternativas – inovação do produto 253

• seleção das idéias: os pontos fortes e fracos das idéias geradas de-
vem ser considerados, combinando as boas partes de idéias, estabe-
lecendo-se um processo de triagem para selecionar as idéias úteis;
• revisão: uma vez encontradas as soluções, ou um conjunto delas,
deve-se generalizá-las e, finalmente, submetê-las a avaliações diante
de restrições do problema.
Além do processo de criação e de métodos ou procedimentos de criati-
vidade, foram também pesquisados aspectos dos indivíduos, ou da equipe
de trabalho, tais como: motivações; mente aberta; características indivi-
duais e de comportamento de trabalho em grupo. Segundo Comella (1975)
e Sandor (1974), para melhorar a criatividade, os aspectos citados acima e
as barreiras para a criatividade devem ser considerados. Especificamente
com relação às barreiras tem-se:

• definição incorreta do problema: o primeiro fator para a obtenção


de uma solução inovadora e útil é ter um problema definido de
forma clara e precisa, sem indicar ou induzir uma solução e excluir
possíveis alternativas. É interessante lembrar que um problema bem
formulado é um problema parcialmente resolvido;
• hábitos: sob este termo consideram-se os conhecimentos, métodos
e técnicas que os indivíduos utilizam para resolver o problema. Os
problemas, as condições e os tempos mudam muito, portanto os há-
bitos devem ser avaliados para verificar se são os mais apropriados,
se novos devem ser procurados e se não é conveniente adotar dife-
rentes hábitos para resolver um mesmo problema;
• fixação funcional: é muito comum a idéia de que um produto, solu-
ção ou método, uma vez concebido para uma determinada função,
não pode ter outros usos ou funções. Às vezes, pequenas modifica-
ções de um produto podem atender a funções bastante diversas das
originais para as quais ele – o produto – foi concebido. Uma concep-
ção desenvolvida em uma área de conhecimento, com algumas vari-
ações, pode ser aplicável em outras áreas. A procura por aplicações
de uma solução ou método em diferentes campos de conhecimento
é tratada dentro dos conceitos de interdisciplinaridade;
• superespecialização: um profissional altamente especializado geral-
mente chega de forma rápida a uma solução, mas somente em seu

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 254 — #282


i i

254 Projeto Integrado de Produtos: planejamento, concepção e modelagem

campo de especialização, sem considerar as possíveis contribuições


de outros domínios de conhecimento. Para conceber alternativas de
soluções, é necessária uma visão ampla dos potenciais dos diferen-
tes campos do conhecimento. Por exemplo, um engenheiro mecânico
poderia adotar um mecanismo de atrito para um redutor com varia-
ção contínua de velocidade sem considerar potenciais de sistemas
hidráulicos ou eletroeletrônicos;

• tendência em favor de tecnologias avançadas: apesar da relevância


das tecnologias avançadas, é muito freqüente observar que profissio-
nais das áreas técnicas procuram adotar soluções que requerem for-
mulações matemáticas e tecnologias muito avançadas e complexas.
Isso decorre da noção falsa de que o uso dessas ferramentas certifica
a competência do indivíduo e sua atualização. Esse comportamento
pode eliminar muitas boas idéias, simples, intuitivas ou experimen-
tais;

• mentalidade prática: as pessoas têm freqüêntemente a tendência de


descer aos fatos tão logo um problema seja exposto, mesmo antes de
entendê-lo perfeitamente, querendo assim mostrar resultados práti-
cos com cálculos e desenhos. Não se trata de perda de tempo, mas
investir tempo, ao vaguear imaginativamente no entorno do pro-
blema. Isso poderá, às vezes, ser altamente frutífero. Uma solução
não deve ser escolhida e particularizada muito cedo, porque esta
definição antecipada poderá impedir que uma visão ampla do pro-
blema e alternativas de solução sejam liberadas;

• dependência excessiva de outros: indivíduos podem tornar-se de-


masiadamente impressionados pelo conhecimento e julgamento de
outros, ou estarem submetidos a excessos de autoridade, e, por conta
disto, falhar em exercer sua própria criatividade;

• medo da crítica: semelhantemente ao caso anterior, o receio de desa-


provação e possíveis críticas podem fazer com que pessoas não pro-
ponham idéias, por não serem ordinárias. Idéias originais e inova-
doras são, com freqüência, mais sujeitas a críticas, mesmo que mais
tarde se provem altamente valiosas. É necessário que a gerência ou
a equipe de trabalho deixe todos à vontade para sugerir suas idéias,
mesmo que de início possam parecer estranhas ao problema;

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 255 — #283


i i

Síntese de soluções alternativas – inovação do produto 255

• recusa de sugestão não especialista: idéias originais e úteis não vêm,


necessariamente, de pessoas da alta gerência e formalmente qualifi-
cadas. Com freqüência, sugestões valiosas partem das pessoas mais
simples dentro de uma organização;
• julgamento prematuro: idéias devem fluir livremente. Julgar cada
idéia tão logo ela é concebida interrompe seu fluxo. A avaliação deve
ser efetuada no final do trabalho de concepção e, geralmente, é reali-
zada com melhores resultados por especialistas que podem não fazer
parte do trabalho inicial;
• motivação em excesso: motivação sempre deve existir, mas não em
excesso. Quando um problema é proposto, uma solução tem de ser
encontrada, mesmo que não seja perfeita ou ideal. Fixar objetivos
difíceis de serem alcançados pode ofuscar a visão, estreitar o campo
de observação e reduzir a eficácia na solução do problema.

Desde a década de 1960, muito se tem pesquisado e publicado sobre a


criatividade e formas de tornar as equipes de trabalho, no processo de ge-
ração de soluções, mais produtivas e criativas (Comella, 1975, Dick, 1985,
Dixon, 1966 e Raudsepp, 1969). As barreiras acima descritas são geral-
mente consideradas e servem de alerta aos membros de equipes, para des-
bloqueio de sua mente e preparo no uso de inúmeros métodos de criativi-
dade encontrados na literatura. A. Van Gundy, apud Baxter (1998, p.58), en-
controu, em um levantamento, 105 diferentes técnicas, procedimentos ou
métodos de geração de idéias ou soluções de problemas. Há muitas simi-
laridades entre vários desses métodos, sendo alguns bem simples, desde a
descrição das circunstâncias em que um determinado inventor encontrou
sua solução, até outros mais elaborados, resultantes de pesquisas das for-
mas de trabalho de pessoas ou equipes altamente criativas. Esses métodos
são classificados de diferentes formas na literatura. Nesse contexto, serão
classificados em dois grupos, chamados de métodos intuitivos e métodos
sistemáticos. Entre os métodos sistemáticos tem-se o método da síntese
funcional, que será descrito em profundidade no Capítulo 7. O método
citado merece este destaque por ser considerado mais adequado ao desen-
volvimento de sistemas técnicos e possuir maior potencial para o desen-
volvimento de sistemas informatizados de geração de soluções.
No item 6.2 são descritos os métodos classificados como intuitivos e
no item 6.3, os métodos sistemáticos.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 256 — #284


i i

256 Projeto Integrado de Produtos: planejamento, concepção e modelagem

É muito útil aos membros de uma equipe de projeto conhecer os as-


pectos da criatividade acima apontados, ou seja: o processo criativo; as
características de indivíduos criativos; as barreiras da criatividade; o tra-
balho e o desempenho de equipes no processo de geração de idéias e os
métodos de geração de soluções. Esse conhecimento é útil especialmente
para o líder da equipe, tendo em vista que: na formação e preparação da
equipe devem-se levar em conta as características de pessoas mais criati-
vas; o trabalho em grupo, seu desempenho, motivações e compensações
devem ser gerenciados com especial atenção; na escolha do(s) método(s)
de geração de soluções, é necessário conhecer os potenciais próprios de
cada um deles.

6.2 Métodos intuitivos de geração de


concepções do produto

Como já foi mencionado, o número de métodos intuitivos propostos


é muito grande, mas os mais recomendados e usados são: brainstorming
e suas variações, como o método 635 e o eletrônico; método de Delphi;
analogias direta, simbólica e pessoal; método sinético; método da listagem
de atributos; e método da instigação de questões.

6.2.1 Brainstorming

O termo brainstorming é de origem inglesa (brain = cérebro e storm =


tempestade). Possui grande aceitação e, como citado por Rausepp (1983),
foi desenvolvido por Alex F. Osborn em 1939. Esse método adota as se-
guintes orientações:
• um coordenador convida um grupo de pessoas a participarem de
uma reunião de trabalho a fim de sugerirem soluções para um pro-
blema formulado. O número de pessoas convidadas pode variar,
mas o recomendado é de 5 a 10 participantes;
• a formação das pessoas deve ser diversa: escolher representantes dos
diferentes departamentos da empresa pode ser uma boa alternativa;
• o tempo de reunião de trabalho não deve ultrapassar 50 minutos;
• a reunião deve ter um coordenador e ser organizada para que se
registrem as sugestões.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 257 — #285


i i

Síntese de soluções alternativas – inovação do produto 257

Como normas a serem seguidas durante a reunião, é recomendável:


evitar qualquer crítica ou avaliação prematura sobre soluções apresenta-
das, mesmo que de início possam parecer as mais absurdas; procurar o
número máximo possível de soluções, priorizando quantidade acima de
qualidade; soluções podem ser combinadas, uma pode gerar outra, e, em
outro estágio, pode-se compará-las e selecionar a melhor ou as melhores;
pensar de forma extravagante para propiciar o surgimento das mais di-
versas idéias; uma idéia não deve ser de autoria única, e sim resultado do
grupo de trabalho.
Esse método pode ser usado em qualquer fase de desenvolvimento do
produto. Não é recomendado para problemas muito especializados, mas
para encontrar novas soluções de problemas mais gerais, como um novo
produto que a empresa poderia lançar, um novo princípio de solução para
um subsistema do produto, como fabricar, montar, embalar, ou transportar
etc. Como já foi citado, o método propõe que as diversas áreas da empresa
tenham participantes no grupo de trabalho, porque é importante que cada
um observe o produto e sugira soluções sob a sua ótica. Dessa forma todos
ficam sabendo o que está sendo resolvido e o que ainda está por vir.
Outro aspecto importante é que as idéias devem fluir livremente, em
quantidade, sem restrições de tipos ou formas de solução e sem avaliações.
As avaliações ou triagem das soluções mais promissoras podem ser feitas
na fase final da reunião ou, então, por especialistas de dentro ou de fora da
organização. Para mostrar como as idéias podem e devem fluir livremente
será apresentado um exemplo de brainstorming dado por Dixon (1966) com
algumas adaptações de nomes e soluções.
O problema proposto é encontrar princípios de solução para separar
tomates maduros de verdes. Certos produtores de tomate entendem que é
mais econômico colher todos os tomates de uma só vez e, como é sabido,
nesta cultura não se tem uma maturação uniforme de todos os frutos. Por-
tanto, na mecanização da colheita, são colhidos tomates verdes e maduros
que devem ser separados para posterior processamento e comercialização.
O objetivo, então, é encontrar princípios de solução para a função de sepa-
rar tomates verdes de maduros, que podem ser parte da máquina colhe-
dora ou de uma máquina com esta função somente. Na Tabela 6.1 tem-se
um modo de registro de uma sessão de brainstorming do grupo.
Para se chegar a esses resultados houve liberdade total para as suges-
tões, não se levou mais do que 30 minutos e, se as idéias forem analisadas,

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 258 — #286


i i

258 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Tabela 6.1 Registro de uma sessão de brainstorming

Brainstorming: grupo A
Problema: separar tomates verdes de tomates maduros
Data:
Antônio separar pela cor, um medidor de cor deverá ser prático
Pedro reflexão, verdes refletem mais luz 1a solução
Davi dureza, apertamos os tomates ou batemos
Jorge condutibilidade elétrica
Antônio resistência elétrica 4a solução
Davi magnetismo
Jorge tamanho, os verdes não são menores?
Pedro peso, os maduros são mais pesados
Antônio tamanho e peso devem se correlacionar
Davi tamanho e peso é densidade
Pedro volume específico
Antônio os tomates são mais água e têm o volume específico da
água
Davi os tomates flutuam ou afundam?
Jorge talvez seja isto, separá-los por densidade, se flutuam ou
afundam em água
Paulo não somente em água, poderia ser qualquer coisa 2a solução
Antônio não tóxico
Davi água salgada
Jorge raios X, o tamanho das sementes ou qualquer coisa assim
Antônio cheiro, odor
Pedro som, você pode ouvir o tomate?
Jorge pode o tomate ouvir?
Davi calor, radiação infravermelha
Pedro condutibilidade térmica
Antônio calor específico
Jorge habilidade de hipnotizar os tomates
Pedro deixa uma moça olhar para os tomates e apertar um
botão
Davi estatisticamente – verifique somente um ou outro
Jorge sacudir um balaio, os maduros devem subir ou descer 3a solução
Pedro soprar ar através, ao sacudir o balaio
Antônio use números aleatórios

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 259 — #287


i i

Síntese de soluções alternativas – inovação do produto 259

verificar-se-á que várias têm potencial ou poderão ser combinadas para


a solução prática do problema. Na terceira coluna podem ser registradas
avaliações a serem feitas pela equipe ao final da sessão.
O método de brainstorming recebeu, ao longo dos anos, várias suges-
tões de modificações. Segundo Holt (1995), a forma descrita é chamada de
brainstorming clássico, vindo em seguida o brainstorming escrito e o brains-
torming assistido por computador.
O brainstorming escrito, ou também chamado de método 635, consiste
no seguinte:

• uma equipe de seis membros reunidos se familiariza com o pro-


blema a resolver;
• cada um dos membros da equipe registra, numa folha, três sugestões
de solução;
• em seguida cada um passa sua folha para o membro seguinte, que,
após a leitura, deverá acrescentar três sugestões novas ou melhora-
mentos e desenvolvimentos das anteriores;
• o último passo é executado até que cada folha com as três sugestões
iniciais tenha passado pelos outros cinco membros da equipe.

Na Figura 6.1, Bonsiepe, Kellner e Poessnecker (1984) mostram o re-


sultado que poderia constar numa das seis folhas de uma reunião de tra-
balho, para obter sugestões para o aproveitamento de uma sobra de couro,
de tamanho 40x40 cm. Se todos os seis membros fossem muito criativos,
ter-se-ia, ao final da reunião, 108 alternativas de aproveitamento do reta-
lho de couro.
Nesse exemplo, as soluções foram mostradas de forma gráfica, mas
pode-se adotar também um modo descritivo ou misto. Observa-se, ainda,
a possibilidade de uma diversidade muito grande de idéias, o que leva a
recomendar que os seis membros da equipe sejam de múltiplas áreas de
conhecimento ou de experiência.
Como última versão do brainstorming tem-se o eletrônico. Nesse caso
sugere-se que o trabalho seja efetuado via internet. A grande vantagem é
que as idéias, para o problema, podem ser obtidas de participantes que
dificilmente poderiam estar juntos em uma reunião, por meio da comuni-
cação a distância.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 260 — #288


i i

260 Projeto Integrado de Produtos: planejamento, concepção e modelagem

Figura 6.1 Exemplo de uma folha de resultados do método 635, aplicado ao


problema de aproveitamento de sobras de couro por Bonsiepe, Kellner e
Poessnecker (1984)

6.2.2 Método de Delphi

O método de Delphi foi desenvolvido pela empresa Rand Corpora-


tion, em 1950, para coletar opiniões de um grupo de especialistas através
de um questionário estruturado. No método, originariamente, a coleta de
opiniões foi efetuada em rodadas sucessivas, por correspondência, de es-
pecialistas que não se conheciam, eram mantidos no anonimato e que di-
ficilmente poderiam ser reunidos em uma sessão conjunta.
Assim, após identificar o problema, os especialistas são consultados
por correspondência em três rodadas sucessivas. Na primeira constam no

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 261 — #289


i i

Síntese de soluções alternativas – inovação do produto 261

questionário elaborado por uma equipe de coordenação, questões mais


genéricas, para que os profissionais apresentem uma visão inicial sobre o
problema. As respostas são processadas e as questões do segundo questio-
nário são preparadas. Neste, procura-se esclarecer alguns aspectos, identi-
ficar áreas de concordância e discordância, estabelecer prioridades, iden-
tificar e selecionar as soluções alternativas sugeridas na resposta ao pri-
meiro questionário. As respostas ao segundo questionário são novamente
processadas pela equipe e, então, é preparado o terceiro questionário, por
meio do qual os especialistas são novamente contactados, com o propósito
de se obter um consenso sobre os aspectos do problema e a escolha da me-
lhor solução. Este ciclo, mostrado na Figura 6.2, é repetido até se chegar à
solução do problema formulado.

Figura 6.2 Processo de desenvolvimento do método de Delphi

O método apresenta variações, sendo realizado por correio eletrônico


ou, também, usado em reuniões com respostas verbais dos participantes,
com o objetivo de chegar a um consenso sobre um determinado assunto.
Um exemplo de aplicação do método seria obter o consenso sobre o poten-
cial de mercado de um determinado produto ou sobre os custos relativos
dos vários subconjuntos de um determinado sistema técnico. Para obter
bons resultados nesses casos, recomenda-se a participação de especialis-
tas ou gerentes dos diversos departamentos funcionais da empresa: co-
mercial, industrial, administrativo, financeiro, de engenharia do produto,
de marketing, de assistência técnica e incluisve de clientes e consultores
externos.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 262 — #290


i i

262 Projeto Integrado de Produtos: planejamento, concepção e modelagem

6.2.3 Analogias direta, simbólica e pessoal

Observando produtos ou soluções de partes ou funções, verifica-se,


em inúmeros casos, que determinado princípio possui semelhança ou é
análogo a outro campo de conhecimento, na natureza ou na literatura. Por
meio de pesquisas realizadas com o objetivo de identificar pessoas criati-
vas, constatou-se que os mais criativos usavam, com freqüência, a analo-
gia direta com a natureza, a ficção, a história ou outros campos de conheci-
mento para encontrar soluções de concepção e construção de instrumentos
ou equipamentos de engenharia. A biologia e a fisiologia são riquíssimas
em idéias, princípios e soluções que podem ser simplesmente transferi-
dos para solucionar problemas de projeto de produtos. O termo biônica,
encontrado atualmente, consiste em analisar sistemas naturais com o obje-
tivo de identificar princípios de solução que, devidamente adaptados, pos-
sam contribuir para solucionar problemas técnicos. Essas adaptações per-
mitem criar formas análogas, funções análogas ou, ainda, comportamen-
tos análogos. Para um projetista é muito útil ter um bom conhecimento de
biologia.
Para entender e justificar essa importância, existem inúmeras publica-
ções sobre o assunto, como as de Ramos (1993) e Di Bartolo (1981) e exem-
plos encontrados no dia-a-dia. Para citar alguns, tem-se: o velcro ideali-
zado da semente do carrapicho; o sonar do golfinho e do morcego; aviões
(forma, asas, estrutura) e pássaros; robôs manipuladores (formas, graus
de liberdade, acionamentos); e os membros do corpo humano (normal-
mente, com muitos mais graus de liberdade); propulsão e direção de veí-
culos aquáticos e a medusa que se desloca por meio da propulsão a jatos
de água; estruturas diversas otimizadas semelhantes às de ossos, plantas,
favos de mel e teias de aranha; e sensores diversos análogos aos encontra-
dos em animais.
O conhecimento da literatura é imprescindível, mas é importante sa-
lientar que não se pode esquecer do passado para melhorar o futuro, pois
às vezes surgem idéias tidas como novas que já foram pensadas e esque-
matizadas por Leonardo da Vinci, por exemplo. Da ficção científica muitas
soluções hoje são realidade, criadas ou imaginadas a partir de Júlio Verner
ou Isaac Asimov.
Outra forma de analogia é a simbólica, também conhecida sob o nome
de palavra-chave. Nesse tipo de analogia, procura-se por um verbo, decla-

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 263 — #291


i i

Síntese de soluções alternativas – inovação do produto 263

ração ou definição condensada do problema. Em seguida deve-se substi-


tuir a palavra ou declaração por sinônimos ou alternativas de declarações
que tenham alguma relação com a original. Esse procedimento permite
analisar o problema sob outros pontos de vista e dispara novas soluções
ou aplicações. Para ilustrar, considera-se um exemplo em que a palavra ou
declaração condensada, para resolver o problema ou uma parte do pro-
blema, é cortar. Como se mostra na Tabela 6.2, procura-se por palavras
com alguma relação com a anterior, sinônimos, alternativas ou similares.

Tabela 6.2 Palavras relacionadas a cortar obtidas pela analogia simbólica

Cortar (palavra-chave)
rasgar dobrar cisalhar entalhar
dobrar trincar dividir fatiar
riscar fundir tracionar corroer
fundir furar romper desgastar
esmerilar jatear serrar separar

Se essas palavras forem examinadas, diferentes formas ou princípios


de solução para cortar um determinado material e perfil serão encontrados
ou, então, surgirão idéias para cortar diferentes materiais ou perfis.
Finalmente, a analogia pessoal, ou empatia, termo normalmente usado
na psicologia, o qual expressa o comportamento de deslocar-se para a si-
tuação e as circunstâncias experimentadas por outra pessoa. Da mesma
forma, pode-se usar as próprias emoções, sentimentos e características
para obter uma compreensão de problemas tecnológicos. Em outros ter-
mos: colocar-se no lugar de uma peça, mecanismo ou operação e ver como
se comportaria. Essa identificação pessoal com os elementos libera o in-
divíduo de ver o problema em termos de análises anteriores e assim ele
pode encontrar soluções novas ou alternativas.

6.2.4 Método sinético

O termo sinético foi adotado para traduzir a palavra synectics do in-


glês, que é usada para expressar a resolução de problemas com base no
pensamento criativo. Sinergia, do grego synergía, é entendida como um
ato ou esforço coordenado de vários órgãos na realização de uma função,

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 264 — #292


i i

264 Projeto Integrado de Produtos: planejamento, concepção e modelagem

uma associação de vários fatores que contribuem para uma ação coorde-
nada ou simultânea (Houaiss e Villar, 2001).
De acordo com Raudsepp (1969), o método proposto baseou-se em re-
gistro e estudo de procedimentos e mecanismos adotados por grupos de
trabalho que se mostraram altamente criativos. Constatou-se que as pes-
soas mais criativas costumavam usar as analogias descritas no item ante-
rior. Enfim, o método proposto nada mais é do que o uso coordenado das
analogias para a solução dos problemas (Figura 6.3), e descrito a seguir:

• 1o Passo: Formular o problema. Como em qualquer caso, também no


método sinético há o reconhecimento de que a formulação do pro-
blema influencia, significativamente, a forma pela qual ele é abor-
dado. Com a formulação concluída, tem-se declarações do Problema
Como É Definido (PCED).
• 2o Passo: Analisar o problema. Na seqüência, o problema deve ser
entendido. Para isso, há uma fase de análise, na qual o grupo de
trabalho deve decidir qual aspecto ou declaração enfrentará e de-
compor o problema. Ao transformar um problema desconhecido
ou estranho em um problema conhecido ou familiar, tem-se, então,
um Problema Como É Entendido (PCEE). Esse estágio analítico, do
PCED ao PCEE, tem como propósito principal tornar um problema
estranho em um familiar àqueles participantes do grupo que não es-
tão familiarizados com ele e seus fundamentos. Essa análise é usada
para levantar e eliminar aquelas soluções imediatas que inevitavel-
mente ocorrem aos membros do grupo mas que raramente provam
ser adequadas e serve para identificar o ponto de partida no qual o
grupo irá se concentrar. O PCED é freqüentemente redeclarado por
ser comum o grupo descobrir que o centro do problema é outro e
não aquele inicialmente definido.
• 3o Passo: Aplicar as analogias. No método sinético, o pensamento
oscila de um modo ordenado entre análise e analogia e entre a trans-
formação do estranho em familiar e do familiar em estranho. Trans-
formar o familiar em estranho se consegue com as analogias, por
meio das quais o grupo distorce deliberadamente a imagem do pro-
blema para assumir um novo enfoque ou ponto de vista. O caminho
analógico, ou a analogia a ser adotada, deve ser decisão do coorde-
nador da equipe, que lança uma Questão Evocativa (QE). Como já

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 265 — #293


i i

Síntese de soluções alternativas – inovação do produto 265

Figura 6.3 Processo de desenvolvimento do método sinético

foi dito, a QE deve ser tal que distorça o problema ou que permita
um novo ponto de vista. Para obter um princípio de solução da me-
cânica, deve-se escolher um princípio ou método biológico. Exem-
plificando questões evocativas: se no problema técnico uma peça ou
parte dela deve mudar de cor quando exposta a determinadas condi-
ções, pergunta-se o que na natureza muda de cor; se é um problema
de orientação, como os seres vivos se orientam; e se for um caso de
propulsão, como os peixes e outros animais se propulsionam. Já foi
visto que a analogia direta não é somente com a natureza, mas com
outras tecnologias, áreas de conhecimento, literatura e ficção. Sendo
novamente um problema de engenharia mecânica, a questão evoca-
tiva poderia ser como ele seria resolvido nas engenharias civil, elé-
trica, química ou na medicina. Da mesma forma, as questões evo-
cativas podem estar dentro das analogias simbólica ou pessoal. Um
bom coordenador logo descobre com qual analogia um membro, ou
a equipe, tem maior facilidade.

i i

i i
i i

“master_livro” — 2007/3/8 — 15:26 — page 266 — #294


i i

266 Projeto Integrado de Produtos: planejamento, concepção e modelagem

• 4o Passo: Desenvolver a analogia. Uma vez identificada uma solução


análoga promissora, esta deve ser desenvolvida para entender suas
implicações.
• 5o Passo: Aplicar a solução analógica. Neste passo ela deve ser apli-
cada ou confrontada ao PCEE e em seguida ao PCED, para verificar
se uma nova solução foi encontrada e se atende ao problema como
é entendido e ao problema como é dado. Este passo também pode
revelar um novo entendimento do problema ou um novo PCEE.
• 6o Passo: Avaliar a solução analógica. Se a solução atende ao PCEE e
ao PCED, deverá ser desenvolvida tão detalhadamente quanto pos-
sível e necessário e, então, avaliada.
• 7o Passo: Buscar soluções alternativas. Para isso tem-se como possi-
bilidades: encontrar outras soluções para a mesma questão evocativa
e repetir os passos 4o ao 6o ; lançar nova questão evocativa dentro do
mesmo tipo de analogia ou variar o tipo de analogia, repetindo os
passos do 3o ao 6o e, se no passo 5o revelar-se um novo PCEE, os
passos 3o ao 6o também devem ser repetidos.

6.2.5 Método da listagem de atributos

Conforme citado por Raudsepp (1983), o método foi desenvolvido por


Robert Crawford, da Universidade de Nebraska, e consiste em isolar e
listar os principais atributos ou características de um produto. Em seguida
cada uma dessas características é avaliada com o objetivo de melhorar o
produto.
Para um fácil entendimento desse método, considerou-se o caso de
uma chave de fenda de algumas décadas atrás. Essa chave apresentava
uma haste de secção circular, um cabo de madeira rebitada e uma ponta
chata. Era acionada manualmente e o torque aplicado por torção. Todas
essas características foram consideradas e modificadas para fazer um pro-
duto mais eficiente.
Uma haste com secção hexagonal tem substituído a secção circular