Escolar Documentos
Profissional Documentos
Cultura Documentos
CDU 62:658.512.2
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.
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.
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.