Você está na página 1de 10

D997i Dym, Clive L.

Introdução à engenharia [recurso eletrônico] : uma


abordagem baseada em projeto / Clive L. Dym, Patrick Little,
com Elizabeth J. Orwin e R. Erik Spujt ; tradução João Tortello.
– 3. ed. – Dados eletrônicos. – Porto Alegre : Bookman, 2010.

Editado também como livro impresso em 2010.


ISBN 978-85-7780-686-7

1. Engenharia. 2. Engenharia – Design. I. Little, Patrick.


II. Orwin, Elizabeth J. III. Spujt, R. Erik. IV. Título.

CDU 62:658.512.2

Catalogação na publicação: Renata de Souza Borges CRB-10/1922


3
Definindo o Problema de
Projeto do Cliente
O que esse cliente realmente quer? Existem limites?

N os capítulos anteriores, definimos projeto de engenharia, exploramos e descrevemos o pro-


cesso de projeto e falamos brevemente sobre o gerenciamento de um projeto estrutural. Agora,
passaremos para a definição do problema, a fase de pré-processamento do projeto, durante a
qual enquadramos o problema para moldá-lo em termos de engenharia. Assim, focaremos aqui
as quatro primeiras tarefas de projeto identificadas na Figura 2.3.

3.1 Identificando e representando os objetivos do cliente


O ponto de partida da maioria dos projetos de estrutura é a identificação, por parte de um
cliente, de um problema a ser resolvido ou de uma necessidade a ser atendida (lembre-se das
Figuras 2.1 a 2.4). A equipe de projeto trabalha então para resolver o problema do cliente.
Normalmente, a necessidade do cliente é apresentada como uma declaração verbal na qual
ele identifica um dispositivo que será atraente a certos mercados (por exemplo, um recipiente
para uma nova bebida), um dispositivo que executará determinadas funções (por exemplo, um
galinheiro) ou um problema a ser resolvido por meio de um novo projeto (como uma nova
malha viária ou terminal de transportes).

3.1.1 A declaração de problema original do cliente


Às vezes, as declarações de projeto dos clientes são bastante sucintas. Por exemplo, imagi-
ne que você esteja em uma equipe de projeto na American Beverage Company (ABC) ou
na National Beverage Company (NBC), os clientes identificados no problema de recipiente
para bebidas dado na Seção 2.5. Você poderia simplesmente receber um pedido da direção
dizendo: “Projete um vasilhame para nosso novo suco para crianças”. Sua equipe de projeto
poderia responder a esse pedido escolhendo um vasilhame já existente, projetando um rótulo
engenhoso e dizendo que seu trabalho estava feito. Contudo, esse é um bom projeto? É o
projeto correto? Não há uma maneira de responder a essas perguntas, pois a declaração do
problema era tão sucinta que não deu pistas sobre outras considerações que poderiam entrar
nas considerações ou na avaliação do projeto; por exemplo, o mercado pretendido, o formato
ou os materiais escolhidos para o recipiente, etc.
Outra declaração de projeto poderia assumir esta forma: “O Claremont Colleges precisa
reestruturar o cruzamento da Avenida Foothill com a Avenida Dartmouth para que os alunos
70 Introdução à Engenharia

possam atravessar a rua”. Embora comuniquem a ideia de alguém sobre qual é o problema,
declarações como essa têm limitações, pois frequentemente contêm erros, mostram tendências
ou insinuam soluções. Os erros podem ser informações incorretas, dados defeituosos ou in-
completos ou simples enganos relacionados à natureza do problema. Assim, a declaração do
problema que acabou de ser dada deve se referir ao Boulevar Foothill e não à Avenida Foothill.
Tendências são pressuposições sobre a situação, que também podem se mostrar imprecisas,
porque o cliente ou os usuários podem não compreender inteiramente a situação. No caso do
tráfego, por exemplo, o problema real pode não estar relacionado ao projeto do cruzamento,
mas à cronometragem dos semáforos ou à tendência dos alunos de atravessar a rua descuida-
damente. As soluções implícitas, isto é, as melhores conjecturas do cliente a respeito das solu-
ções, frequentemente aparecem nas declarações de problema. Embora as soluções implícitas
forneçam algumas ideias úteis sobre o que o cliente está pensando, elas podem acabar restrin-
gindo o espaço de projeto no qual o engenheiro procura uma solução. Além disso, às vezes
uma solução implícita não resolve o problema em questão. Por exemplo, não é óbvio que rees-
truturar o cruzamento resolverá o problema do tráfego para os estudantes. Se os alunos atra-
vessam a rua descuidadamente, reestruturar o cruzamento fará pouco ou nada para atenuar
isso. Se o problema é que os alunos estão atravessando uma rua perigosa, talvez queiramos
mudar o destino deles para outro lugar. A questão é que devemos examinar as declarações de
projeto cuidadosamente para identificar e lidar com os erros, tendências e so-
Um melhor luções implícitas. Somente então chegaremos ao problema real.
entendimento do Queremos enfocar o desenvolvimento de um entendimento mais claro
problema que é do que o cliente deseja, pois isso nos ajudará a ver os termos nos quais um
compartilhado
projeto poderia surgir. Isto é, queremos esclarecer o que o cliente deseja, levar
pelo cliente e pelo
projetista resulta em conta o que os usuários em potencial precisam e entender os contextos
do esclarecimento tecnológicos, de comercialização e outros, dentro dos quais nosso equipa-
da declaração de mento funcionará. Ao fazermos isso, estaremos definindo ou enquadrando o
problema original.
problema de projeto clara e realisticamente.

3.1.2 Fazendo perguntas e brain storming sobre o problema do cliente


Na Seção 2.1, falamos sobre o papel do questionamento no processo de projeto. Na verdade,
existem dois tipos de atividades que as equipes de projeto podem iniciar, às vezes em parale-
lo, após receberem a declaração de problema de projeto original. A primeira é fazer perguntas
para o cliente (ou clientes) e para os stakeholders que podem ter variados graus de interesse
no projeto, por exemplo, usuários em potencial e especialistas no setor. Os especialistas po-
dem ser pessoas versadas em qualquer tecnologia ou em outros aspectos técnicos relevantes,
ou especialistas em marketing que estejam familiarizados com o mercado dos usuários ao
qual o projeto se destina.
É interessante estar bem preparado ao fazer perguntas. Se soubermos o que estamos
procurando, poderemos conduzir a conversa e obter mais informações. Também é útil garantir
que as pessoas que estão respondendo as perguntas considerem que seu tempo não está sendo
desperdiçado. Isso é muito importante, se for previsto um programa de entrevistas estrutu-
radas com especialistas e/ou usuários, pois essas entrevistas ou formulários de levantamento
detalhado semelhantes não produzirão respostas úteis ou sérias a não ser que os entrevistados
achem que vale a pena perder tempo para responder muitas perguntas.
O brain storming é a segunda atividade que as equipes de projeto podem iniciar no
enquadramento do problema. O brain storming é um trabalho em grupo no qual novas
ideias são produzidas, mantidas e talvez organizadas em alguma estrutura relevante para o
problema. É importante que as sessões de brain storming permaneçam focadas, para que,
ao tentar identificar objetivos e restrições, o enfoque da equipe não mude para outra coisa;
Definindo o Problema de Projeto do Cliente 71

por exemplo, funções. Embora inevitavelmente surjam sugestões “sem interesse”, a equipe
deve tentar ater-se ao assunto em questão; quer dizer, identificar metas, objetivos e, talvez,
restrições. A equipe pode fazer isso se o líder apresentar declarações de ideias com frases
como, “uma característica desejável do equipamento seria...”, o que lembra aos outros que
o foco da equipe está nos objetivos. O melhor resultado do brain storming é uma lista de
características que podem ser cortadas e refinadas em uma lista endentada de objetivos para
o projeto.

3.1.3 De listas de atributos de objeto desejados a listas de objetivos


Agora, imagine que estamos em uma equipe de projeto que dá consultoria para uma empresa
que produz ferramentas de alta e de baixa qualidade (com uma gama de preços corresponden-
te!). A administração da empresa, buscando entrar em um novo mercado, forneceu à equipe
um contrato mais específico do que “projete uma escada segura”, a saber, “projete uma nova
escada para eletricistas ou outros profissionais de manutenção e construção que trabalham em
instalações de serviço convencionais”. Essa é uma tarefa de projeto “de rotina”, mas para en-
tender completamente os objetivos desse projeto, precisamos falar com a administração, com
alguns usuários em potencial, com algumas das pessoas de marketing da empresa e alguns
especialistas. Também precisamos realizar nossas próprias sessões de brain storming. Obte-
remos um entendimento melhor sobre o que nosso projeto de estrutura é realmente fazendo
perguntas como:
• Quais características ou atributos você gostaria que a escada tivesse?
• O que você quer que essa escada faça?
• Já existem escadas no mercado que tenham características semelhantes?
Além disso, ao fazermos essas três perguntas, também podemos perguntar:
• O que isso significa?
• Como você vai fazer isso?
• Por que você quer isso?
Como resultado de nossas discussões e brain stormings, podemos gerar a lista de atributos
e características de um projeto de escada segura mostrada na Lista 3.1.

Lista 3.1 Lista de atributos da ESCADA SEGURA


A escada deve ser útil
Usada para pendurar conduíte e fios em tetos
Usada para manter e consertar tomadas em lugares altos
Usada para substituir lâmpadas e luminárias
Usada ao ar livre no nível do chão
Usada suspensa a partir de algo, em alguns casos
Usada em recintos fechados, em assoalhos ou outras superfícies suaves
Pode ser uma escada de abrir e fechar ou de extensão curta
Uma escada dobrável poderia servir
Uma escada de cordas serviria, mas não em todos os casos
Deve ser razoavelmente rígida e confortável para os usuários
As deflexões dos degraus devem ser menores do que 1 mm
Deve permitir que uma pessoa de estatura mediana alcance e trabalhe em altu-
ras de até 3 m, aproximadamente
Deve suportar o peso de um trabalhador normal
Deve ser segura
72 Introdução à Engenharia

Deve satisfazer os requisitos da OSHA


Não deve conduzir eletricidade
Pode ser feita de madeira ou fibra de vidro, mas não de alumínio
Deve ser relativamente barata
Deve ser fácil de transportar entre os locais de trabalho
Deve ser leve
Deve ser durável
Não precisa ser atraente nem elegante
Observe que as entradas da Lista 3.1 refletem diferenças entre conceitos fundamen-
talmente diferentes; na verdade, muitos dos conceitos que definimos no Capítulo 1. Assim,
vamos examinar, ilustrar e comentar as definições conceituais relevantes:
• objetivo s: algo para o que o esforço é dirigido; um propósito ou fim da ação
“Deve ser relativamente barata”
“Deve ser leve”
Objetivos ou metas são expressões dos atributos e do comportamento que
o cliente ou os usuários em potencial gostariam de ver em um sistema ou
Objetivos são
equipamento projetado. Normalmente, eles são expressos como declarações
os atributos e
comportamentos “ser”, que dizem como o projeto será, ao contrário do que o projeto deve
desejados de um fazer. Por exemplo, dizer que uma escada deve ser fácil de transportar é um
projeto. termo “ser”. Os termos “ser” identificam atributos que fazem o objeto “ter
boa aparência” aos olhos do cliente ou usuário, expressos nas línguas naturais
do cliente e dos usuários em potencial.
Muitas vezes os objetivos também são escritos como declarações de que “mais
(ou menos) de [o objetivo]” é melhor do que “menos (ou mais) de [o objetivo]”. Por
exemplo, mais leve normalmente é melhor do que mais pesado, se nossa meta é a por-
tabilidade. Na verdade, conforme explicaremos na Seção 3.4, apresentaremos métricas
para objetivos que nos permitem medir ou quantificar se (ou não) os objetivos são satis-
feitos, o que nos ajudará então na escolha entre projetos alternativos. Outro indício de
como medimos a obtenção de objetivos fica claro a partir do primeiro objetivo anterior:
escadas custando US$15 ou US$20, respectivamente, são “relativamente baratas”, mas
qual seria mais desejável?
• restrição s: o estado de ser verificado, limitado ou forçado a evitar ou executar alguma
ação
“Não deve conduzir eletricidade”
“Deve ser durável”
As restrições são ressalvas ou limitações sobre um comportamento, um valor ou algum
outro aspecto do desempenho de um objeto projetado. Normalmente, as restrições são
expressas como limites claramente definidos, cuja realização pode ser enquadrada em
uma escolha binária; por exemplo, o material da escada é condutor ou não é, ou a defle-
xão dos degraus é menor do que 1 mm ou não é. As restrições são importantes para o
projetista, pois limitam o tamanho de um espaço de projeto, impondo a exclusão de al-
ternativas inaceitáveis. Por exemplo, o projeto de uma escada que não atende
Restrições são limites os padrões da OSHA será rejeitado.
rigorosos que um Os objetivos e as restrições estão intimamente ligados e às vezes pare-
projeto deve satisfazer
cem ser intercambiáveis, mas não são. (Conforme observaremos na página
para ser aceitável.
94, existem circunstâncias em que um objetivo pode ser convertido em uma
restrição, mas isso não os torna intercambiáveis.) As restrições limitam o
tamanho do espaço de projeto, enquanto os objetivos permitem a exploração do res-
Definindo o Problema de Projeto do Cliente 73

tante do espaço de projeto. Isto é, as restrições são formuladas para permitir a rejeição
de alternativas que são inaceitáveis, enquanto os objetivos permitem uma seleção en-
tre alternativas de projeto que são no mínimo aceitáveis ou, em outras palavras, que
apresentam soluções satisfatórias. Os projetos que apresentam soluções satisfatórias
podem não ser excelentes ou os melhores, mas pelo menos satisfazem todas as res-
trições. Por exemplo, poderíamos satisfazer os padrões da OSHA de forma mínima
ou superá-los significativamente fazendo uma escada “super segura” para obter uma
vantagem mercadológica. Ou então, no quesito preço, uma meta dizendo que a escada
deve ser “relativamente barata” também poderia ter a restrição de que o custo não po-
deria ultrapassar US$25. Se tivermos tanto o objetivo de baixo custo como a restrição
de US$25, poderemos excluir alguns projetos iniciais com base na restrição, ao passo
que fazemos uma escolha dentre os projetos restantes com base no custo e em outros
objetivos não econômicos.
É importante lembrar que os objetivos e as restrições se referem ao equipamento
ou sistema que está sendo projetado e não ao processo de projeto. Uma “escada de bai-
xo custo”, por exemplo, tem um custo de fabricação ou produção baixo. Os custos
acarretados durante o processo de projeto (salários de engenheiros, levantamentos de
mercado, desenvolvimento de protótipos, etc.) podem ser altos, mas essa é uma questão
totalmente separada.
• função s: a ação para a qual uma pessoa ou coisa é especialmente adequa-
Funções são ações da ou usada, ou para a qual uma coisa existe; uma de um grupo de ações
que um projeto
relacionadas, colaborando para uma ação maior
bem-sucedido deve
executar. “Deve suportar o peso de um trabalhador normal”
“Deve isolar o usuário”
Falando de forma simples, as funções são as coisas que o equipamento, sistema
ou processo projetado deve fazer, as ações que deve executar. Em uma lista de atributos
inicial, as funções normalmente são expressas como termos “fazer”, como a primeira fun-
ção anterior. Frequentemente, elas se referem a funções de engenharia, como a segunda
função destacada anteriormente (que também é uma restrição), que diz que o fluxo de
corrente elétrica deve ser evitado.
• meio s: uma entidade, instrumento ou método usado para atingir um fim
“Pode ser feita de madeira ou fibra de vidro, mas não de alumínio”
Os meios ou implementações são maneiras de executar as funções que o projeto deve
realizar. Na lista de atributos, essas entradas fornecem sugestões específicas sobre como
será o projeto final ou do que será feito (por exemplo, a escada será feita de madeira ou
de fibra de vidro); portanto, frequentemente elas aparecem como termos “ser”. Con-
tudo, geralmente é óbvio quais termos “ser” são objetivos a serem alcançados e quais
apontam para propriedades específicas. Os meios e as implementações são
Implementações são muito dependentes da solução, no sentido de que são frequentemente selecio-
escolhas específicas
de opções de projeto. nados para implementar as funções que devem ser executadas por um projeto
já escolhido.
Podemos agora reduzir a lista de atributos (Lista 3.1), removendo ou cortando as restri-
ções, funções e implementações, deixando apenas os objetivos. Assim, nossa lista de objeti-
vos para a escada é dada na Lista 3.2.
Embora a Lista 3.2 seja útil como lista de objetivos a serem alcançados, podemos
fazer muito mais com ela. Em particular, se nossa lista fosse muito grande, poderíamos
achar difícil utilizá-la sem organizá-la de alguma maneira. Considere os vários usos que
identificamos para a escada. Embora essa não seja uma lista exaustiva de modos de usar
uma escada, talvez queiramos reunir ou agrupar esses usos de alguma maneira coerente.
74 Introdução à Engenharia

Uma maneira de começar a agrupar as entradas da lista é nos perguntarmos por que nos
preocupamos com elas. Por exemplo, por que queremos que nossa escada seja usada ao
ar livre? A resposta provavelmente é porque isso faz parte do que torna a escada útil, que
é outra entrada de nossa lista. Analogamente, poderíamos perguntar por que nos preocu-
pamos se a escada é útil. Nesse caso, a resposta não está na lista: queremos que ela seja
útil para que as pessoas a comprem. Falando de outra forma, a utilidade torna a escada
comercializável.

Lista 3.2 Lista de objetivos da ESCADA SEGURA


A escada deve ser útil
Usada para pendurar conduíte e fios em tetos
Usada para manter e consertar tomadas em lugares altos
Usada para substituir lâmpadas e luminárias
Usada ao ar livre no nível do chão
Usada suspensa a partir de algo, em alguns casos
Usada em recintos fechados, em assoalhos ou outras superfícies suaves
Deve ser razoavelmente rígida e confortável para os usuários
Deve permitir que uma pessoa de estatura mediana alcance e trabalhe em altu-
ras de até 3 m, aproximadamente
Deve ser segura
Deve ser relativamente barata
Deve ser fácil de transportar entre os locais de trabalho
Deve ser leve
Deve ser durável
Isso sugere que precisamos de um item sobre comercialização em nossa lista; por
exemplo, “a escada deve ser comercializável”. Esse é um objetivo útil, pois nos informa por
que queremos que a escada seja barata, fácil de transportar, etc. (Por outro lado, também
devemos identificar cuidadosamente “super objetivos”, como a capacidade de comerciali-
zação, pois praticamente qualquer característica de produto nova ou interessante poderia se
encaixar sob essa rubrica.) Se utilizarmos um questionamento de agrupamento ponderado
desse tipo, encontraremos uma nova lista que poderemos representar em um esboço en-
dentado, com hierarquias de cabeçalhos importantes e vários níveis de subcabeçalhos (por
exemplo, a Lista 3.3).
O esboço endentado revisado da Lista 3.3 nos permite explorar melhor cada um dos
objetivos de nível superior, em termos dos subobjetivos que nos informam como realizá-los.
No nível mais alto, nossos objetivos nos levam de volta à declaração de projeto original que
recebemos, a saber, projetar uma escada segura que possa ser comercializada para um grupo
em particular.
Agora, certamente não esgotamos todas as perguntas que poderíamos fazer sobre a
escada, mas nesse esboço podemos identificar algumas das respostas para três perguntas
mencionadas anteriormente. Por exemplo, a pergunta “o que você quer dizer com segura?” é
respondida por dois subobjetivos do agrupamento de perguntas sobre segurança; isto é, que
a escada projetada deve ser estável e relativamente rígida. Respondemos à pergunta “como
você vai fazer isso?” identificando, dentro do agrupamento “a escada deve ser útil”, vários
subobjetivos ou maneiras pelas quais a escada poderia ser útil e especificando mais dois “sub-
subobjetivos” sobre como a escada seria útil ao ar livre. Além disso, respondemos à pergunta
“por que você quer isso?” indicando que a escada precisa ser barata e fácil de transportar para
atingir seu mercado-alvo de eletricistas e especialistas em construção e manutenção.
Definindo o Problema de Projeto do Cliente 75

Lista 3.3 Lista endentada de objetivos da ESCADA SEGURA


0. Uma escada segura para eletricistas
1. A escada deve ser segura
1.1 A escada deve ser estável
1.1.1 Estável em assoalhos e superfícies suaves
1.1.2 Estável relativamente no nível do chão
1.2 A escada deve ser razoavelmente rígida
2. A escada deve ser comercializável
2.1 A escada deve ser útil
2.2.1 A escada deve ser útil ao ar livre
2.2.1.1 Útil para fazer trabalhos elétricos
2.2.1.2 Útil para fazer trabalhos de manutenção
2.2.2 A escada deve ser útil em recintos fechados
2.2.3 A escada deve ter a altura correta
2.2 A escada deve ser relativamente barata
2.3 A escada deve ser fácil de transportar
2.3.1 A escada deve ser leve
2.3.2 A escada deve ser pequena quando estiver pronta para transporte
2.4 A escada deve ser durável
Encerra aqui o trecho do livro disponibilizado para
esta Unidade de Aprendizagem. Na Biblioteca Virtual
da Instituição, você encontra a obra na íntegra.

Você também pode gostar