• Nenhum resultado encontrado

ANEXO   V.  R ESPOSTAS DAS A VALIAÇÕES DO M ODELO 234 

PRINCIPAIS ETAPAS DESCRIÇÃO

Briefing  Coleta de dados e definição da programação

Análises  Quebradesempenho,  do  problema  em  partes,  formulação  das  especificações  de  identificação de restrições.  Sínteses  Geração  de  ideias,  união  das  partes  de  um  novo  modo,  desenvolvimento  do 

projeto. 

Avaliação  Verificação  do  desempenho  das  especificações  e  restrições,  teste  para  descoberta das consequências de colocar o novo arranjo em prática 

      

24Broadbent, G. Design method in architecture. The Architects’ Journal, 144(11), 1966, p. 679–685.  25Jones, J. C. Design methods: Seeds of human futures. London: John Wiley, 1970. 

Evbuonwan,  Sivaloganathan  e  Jebb  (1996)  apresentam  diversos  modelos  prescritivos  e  concluem que a maioria deles baseiam seus procedimentos em atividades de projeto, que se  resumem em análise, síntese, avaliação, decisão, etc., enquanto outros se baseiam em fases  de  projeto  –  projeto  conceitual,  desenvolvimento  e  projeto  detalhado.  Mallory‐Hill  (2004)  descreve  a  passagem  do  projetista  por  uma  “cascata”  de  estágios  sequenciais,  iniciando  o  processo pelo briefing, até o detalhamento do projeto, construção e, por fim, ocupação (Figura  6). 

 

Figura 6. Modelo de Processo de Projeto Tradicional. Fonte: Mallory‐Hill (2004). 

Nelson  (199626  apud  MALLORY‐HILL,  2004)  apresenta  um  modelo  em  ‘roda  de 

retroalimentação’  (figura  7),  por  acreditar  que,  com  melhores  mecanismos  de  retroalimentação do que o modelo tradicional linear, as condições de riscos entre as etapas ou  a  equipe  de  projeto,  como  escolha  inapropriada  de  materiais  ou  um  briefing  inadequado,  podem ser controladas com maior rigor.         26Nelson, C. E. TQM and ISO 9000 for Architects and Designers. New York: McGraw‐Hill, 1996.  BRI EFI NG   FUNC IO NAL BRI EFI NG  DE   PROJETO PLANEJAMENTO   DO  PROJETO PROJETO DOC U MENTAÇ ÃO LICITA ÇÃ O CON STRUÇÃ O OC UPAÇ ÃO

  Figura 7. Modelo de Processo de Projeto Tradicional, com Ciclos de Retroalimentação.  Fonte: Nelson, (1996 apud MALLORY‐HILL, 2004).  Roozenburg e Cross (1991) acreditam que, no início da década de 1970 na área de arquitetura,  as críticas e reformulações dos esquemas lineares, sequenciais ou de análise‐síntese‐avaliação  se basearam na rejeição geral destes tipos de modelo. 

Hillier,  Musgrove  e  O’Sullivan  (1984)  propõem  um  novo  modelo,  chamado  conjectura‐análise  (C/A),  que  se  baseia  em  pré‐estruturas  que  originam  os  conceitos  de  solução, buscando o refinamento do entendimento do problema e da solução por um ciclo de  conjectura‐análise. Na área de metodologia em arquitetura, Bamford (2002) acredita que os  modelos  de  processo  de  projeto  mais  importante  sejam  A/S  e  C/A,  mas  que  o  C/A  é  o  que  melhor se encaixa no contexto. No entanto, apesar de diversos estudos existentes na literatura  apresentarem vários modelos de processo de projeto, nenhum deles foi aceito universalmente  (ROOZENBURG; CROSS, 1991; KORKMAZ et al., 2010). 

Alguns modelos mais detalhados do processo de projeto são apresentados a seguir,  para  servirem  de  base  para  o  presente  trabalho.  O  primeiro  deles  é  o  desenvolvido  por  Romano  (2006),  denominado  Modelo  de  Referência  para  o  Gerenciamento  do  Processo  de 

Projeto  Integrado  de  Edificações.  Além  da  representação  gráfica  das  fases  do  processo  de  projeto  de  edificações,  apresentada  na  Figura  8,  o  modelo  conta  com  uma  representação  descritiva,  composta  por  de  oito  planilhas.  Cada  planilha  representa  uma  fase  do  processo,  detalhado por meio de sete elementos: entradas, atividades, tarefas, domínios, mecanismos,  controles e saídas. 

Figura 8. Modelo de Referência para o Gerenciamento do Processo de Projeto Integrado de  Edificações. Fonte: Romano (2006). 

Outro modelo, denominado Protocolo Genérico do Processo de Projeto e Construção – GDCPP,  em  inglês  –  foi  desenvolvido  considerando  alguns  princípios‐chave,  baseados  na  literatura  e  em estudos sobre os requisitos da indústria da construção civil (KAGIOGLOU et al., 2000). Estes  princípios foram:   Visão holística do projeto, para considerar o processo durante todo o ciclo de vida  da edificação;   Consistência no processo, para reduzir ambiguidades e facilitar a melhoria contínua  do projeto e da construção;   Coordenação efetiva, ao longo das atividades de cada fase do processo; 

 Correção  progressiva  do  projeto,  por  revisões  de  fases  que  permitem  avaliar  o  trabalho realizado, aprovar resultados e planejar as fases seguintes; 

 Envolvimento  dos  stakeholders  e  da  equipe  de  projeto,  que  deverá  ser  multidisciplinar, para provimento das informações certas no momento adequado;   Retroalimentação, através das revisões de fases, para viabilizar o aprendizado e o 

Baseado  nestes  princípios,  o  GDCPP  subdivide‐se  em  fases  conforme  a  Figura  9.  O  modelo  completo,  com  a  proposição  das  revisões  de  fases  e  das  atividades  de  cada  fase  consta  no  trabalho de Kagioglou et al. (2000).    Figura 9. Fases do Protocolo Genérico do Processo de Projeto e Construção – GDCPP. Fonte:  Kagioglou et al. (2000).  Em relação aos edifícios de assistência à saúde, especificamente, Dickerman e Barach (2008)  descrevem o modelo tradicional do processo de projeto destes edifícios da seguinte forma:  1. O arquiteto recebe os objetivos da edificação, em termos de função e programa;  2. Traduz estes objetivos em requisitos de ambientes (programa espacial)  3. Determina as adjacências de setores;  4. Determina as adjacências de ambientes;  5. Desenvolve o projeto detalhado de cada ambiente;  6. Converte estes projetos em projetos para construção, representando o funcionamento da  edificação em conjunto com os equipamentos, tecnologia e equipe. 

Estes  autores  ressaltam  que,  geralmente,  o  planejamento  de  equipamentos,  tecnologias,  instalações, suas interfaces e impactos em relação ao fator humano ocorre nas últimas etapas  do processo de projeto, e não em conjunto com a concepção da edificação. 

Os  diversos  modelos  de  processo  de  projeto  apresentados  na  literatura  possuem  pouca  aplicação  na  prática,  e  muitas  justificativas  são  encontradas  na  literatura  para  tanto.  Acredita‐se, por exemplo, que uma das razões é que se subestima o potencial de um processo  de  projeto  profissional  (VAN  AKEN,  2005).  A  revisão  bibliográfica  apresentada  por  Tzortzopoulos  e  Sexton  (2007)  destaca  também  a  atenção  insuficiente  aos  fatores  humanos  relacionados à gestão do processo e a falta de motivação para colocar modelos de processos 

em  prática,  sem  valorizar  o  conhecimento,  os  esforços  e  o  tempo  dispensados  em  sua  elaboração. 

Em pesquisa prévia – dissertação de mestrado de Caixeta (2011) – foi desenvolvido  um modelo genérico para o processo de projeto de intervenções em edifícios de assistência à  saúde.  A  Figura  10  apresenta  macrofases  deste  modelo  em  relação  às  macrofases  do  PDP  propostas por Rozenfeld et al. (2006).    Figura 10. Processo de Projeto edifícios de assistência à saúde, dentro do contexto do PDP.  Fonte: Caixeta (2011).  Na sequência, são exploradas as características específicas do processo de projeto de  acordo com as macrofases de pré‐desenvolvimento, desenvolvimento e pós‐desenvolvimento,  mostradas na Figura 10.  3.3.1 Pré‐Desenvolvimento 

O  pré‐desenvolvimento  engloba  as  ‘fases  pré‐projeto’  que  são  relativas  “às  considerações  estratégicas  do  empreendimento  de  qualquer  projeto  potencial  que  objetive  atender  às  necessidades  dos  clientes”  (KAGIOGLOU  et  al.,  2000,  p.148).  Em  alguns  textos,  são  denominadas como front‐end estas fases preliminares, que antecedem o projeto e construção  dos edifícios, quando se tem o gerenciamento dos requisitos do projeto (TZORTZOPOULOS et  al., 2006). 

Frequentemente,  a  natureza  caótica  e  ambígua  do  front‐end  leva  os  autores  a  chamá‐lo de fuzzy front‐end, como ilustrado na figura 11. Atualmente, o fuzzy front end tem  recebido ênfase crescente no processo de projeto (SANDERS; STAPPERS, 2008). 

Figura 11. Crescimento do front‐end com a aproximação entre projetistas e usuários. Fonte:  Sanders e Stappers (2008). 

Para  Campobasso  e  Hosking  (2004),  os  líderes  de  edifícios  de  assistência  à  saúde  tendem  a  iniciar o processo de projeto diretamente focados na concepção e construção do espaço físico  em  si,  geralmente  com  contatos  de  arquitetos  com  quem  já  se  relacionam.  Estes  autores  acreditam que o motivo para esta postura seja que o espaço físico “é o aspecto mais visível do  futuro hospital” (CAMPOBASSO; HOSKING, 2004, p.222). Este procedimento não permite que o  projeto seja orientado pelo serviço, e sim pela arquitetura. No entanto, os autores defendem  que  é  necessário  articular  a  visão  geral  do  edifício  de  saúde,  estabelecer  os  objetivos  estratégicos, planejar os fundamentos da organização e alcançar um consenso antes de iniciar  a concepção do espaço físico em si. Para Caixeta e Fabricio (2013), no processo de projeto de  edifícios  complexos  como  os  de  saúde,  o  projeto  do  espaço  físico  deve  ser  precedido  pelo  projeto e planejamento das atividades e serviços que serão realizados na edificação. 

Na  construção  civil,  utiliza‐se  o  termo  briefing  para  designar  os  requisitos  para  o  projeto  dos  edifícios.  O  briefing,  que  tem  como  objetivo  garantir  o  alinhamento  entre  a  estratégia  de  negócio  e  processo  de  trabalho  (JENSEN,  2011),  é  considerado  um  dos  mais  importantes processos num projeto para construção, uma vez que, nesta etapa, as melhorias  podem  ampliar  a  satisfação  dos  clientes  (JENSEN,  2006;  AL  ZAROONI;  ABDOU;  LEWIS,  2011;  JENSEN, 2011).  

A princípio, o briefing era considerado um documento estático, no entanto, acredita‐ se atualmente que a captura de requisitos é um processo contínuo ao longo do processo de  desenvolvimento  do  produto  (TZORTZOPOULOS  et  al.,  2006;  JENSEN,  2011).  Assim,  tem‐se  como definições: 

 Visão  tradicional  de  briefing  (estático,  documento):  antecede  o  projeto  e  os  documentos  resultantes  contêm  os  requisitos  dos  clientes  para  o  projeto, 

usualmente  escrito  por  especialistas.  A  grande  crítica  é  que  as  necessidades  que  surgem  ao  longo  do  processo  de  projeto  não  podem  ser  preditas  em  conferência  (JENSEN, 2011). 

 Briefing dinâmico, inclusivo (processo e não documento): engloba “as necessidades  de  todos  os  clientes  e  usuários  no  desenvolvimento  de  um  componente  e  é  um  processo contínuo com mudança de foco em diferentes fases” (JENSEN, 2011, p.32). 

O quadro 8 compara o briefing tradicional com o briefing inclusivo. 

Quadro 8. Briefing tradicional e inclusivo. Fonte: Jensen (2011).