A UTILIZAÇÃO DA METODOLOGIA ÁGIL SCRUM COMO ESTRATÉGIA PARA A OTIMIZAÇÃO DO DESENVOLVIMENTO DE PROJE by Ricardo Gonzalez Marinho de Mattos

RICARDO GONZÁLEZ MARINHO DE MATTOS

A UTILIZAÇÃO DA METODOLOGIA ÁGIL SCRUM COMO ESTRATÉGIA PARA A OTIMIZAÇÃO DO DESENVOLVIMENTO DE PROJETOS DE ARQUITETURA

Trabalho apresentado ao curso MBA em Gerência de Projetos, Pós-Graduação lato sensu, da Fundação Getulio Vargas como requisito

parcial

para

obtenção do Grau de Especialista em Gerência de Gerenciamento de Projetos.

ORIENTADOR: Prof. Dr. Arnaldo Lyrio Barreto COORIENTADOR: Profa. Sonia Lopes

Rio de Janeiro Novembro/2015

FUNDAÇÃO GETULIO VARGAS PROGRAMA FGV MANAGEMENT MBA EM GERENCIAMENTO DE PROJETOS

O Trabalho de Conclusão de curso: “A UTILIZAÇÃO DA METODOLOGIA ÁGIL SCRUM COMO ESTRATÉGIA PARA A OTIMIZAÇÃO DO DESENVOLVIMENTO DE PROJETOS DE ARQUITETURA”

Elaborado por: Ricardo González Marinho de Mattos e aprovado pela Coordenação Acadêmica do curso de MBA em Gerenciamento de Projetos foram aceitos como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível de especialização da FGV.

Rio de Janeiro, 13 de novembro de 2015.

___________________________________ André Baptista Barcaui Coordenador Acadêmico Executivo

___________________________________ Arnaldo Lyrio Barreto Professor Orientador

___________________________________ Sonia Lopes Professora Coorientadora

TERMO DE COMPROMISSO

O aluno Ricardo González Marinho de Mattos, abaixo assinado, do curso de MBA em Gerenciamento de Projetos, Turma GP-103 do Programa FGV Management, realizado nas dependências da Fundação Getulio Vargas, no período de 05/05/2014 a 15/11/2015, declara que o conteúdo do Trabalho de Conclusão de Curso intitulado ―A UTILIZAÇÃO DA METODOLOGIA ÁGIL SCRUM COMO ESTRATÉGIA PARA A OTIMIZAÇÃO DO DESENVOLVIMENTO DE PROJETOS DE ARQUITETURA‖ é autêntico, original e de sua autoria exclusiva.

Rio de Janeiro, 13 de novembro de 2015.

___________________________________ Ricardo González Marinho de Mattos

Dedico este trabalho ao meu pai, Joel Marinho de Mattos Filho, por ter me proporcionado um pensamento crĂtico e complexo, com uma visĂŁo holĂstica sobre o mundo, e por ter acreditado e me incentivado na busca de novos caminhos.

AGRADECIMENTOS

Agradeço à Fundação Getulio Vargas, em especial aos professores André Barcaui, coordenador acadêmico do curso de Gerenciamento de Projetos, Arnaldo Lyrio Barreto, orientador deste trabalho e à professora e arquiteta Sonia Lopes, coorientadora com quem pude conversar sobre a utilização no Scrum no processo do projeto de arquitetura e a todos os demais professores que contribuíram para a minha formação como especialista em gerenciamento de projetos. Agradeço também aos colegas da turma GP 103, pela troca de experiências e aprendizados durante o curso. Aos meus queridos pais e a toda a minha família pelo carinho e apoio sempre fundamentais para atingir meus objetivos. Aos meus amigos arquitetos, agradeço as boas conversas que me proporcionaram sobre o tema.

―Não são as espécies mais fortes que sobrevivem, nem as mais inteligentes, e sim as mais suscetíveis a mudanças.‖ Charles Darwin

RESUMO

O presente trabalho desenvolve uma análise sobre o processo do projeto arquitetônico e o papel do arquiteto como gestor, atuando na concepção e coordenação dos demais projetos, aplicados ao contexto da indústria da construção no Brasil. O estudo desenvolve um panorama sobre o impacto da implantação da utilização da tecnologia BIM e faz uma revisão no desenvolvimento dos conceitos de gerenciamento de projetos, até os novos conceitos do Manifesto Ágil, com ênfase na metodologia Scrum. A partir das análises bibliográficas, discutiu-se a implantação da nova tecnologia BIM e o quanto esta ferramenta sofre dificuldades de se estabelecer num primeiro momento; porém, tais impedimentos são recompensados após a mudança, com a aquisição de resultados satisfatórios. Isto posto, conclui-se que tal implantação é facilitada e potencializada através da utilização do Scrum.

Palavras-chave: Arquitetura, BIM, Metodologias Ágeis, Gestão 3.0, Scrum.

ABSTRACT

This paper develops an analysis of the process of architectural design and the architect's role as manager, acting in designing and coordinating other projects, applied to the context of the construction industry in Brazil. The study develops an overview of the impact of the implementation of the use of BIM technology and revises the development of project management concepts to the new concepts of the Agile Manifesto, emphasizing the Scrum methodology. From the bibliographic analysis, discussed the implementation of the new technology BIM and how this tool suffers difficulties settling at first; But these impediments are rewarded after the change, with the acquisition of satisfactory results. That said, it is concluded that such deployment is facilitated and enhanced through the use of Scrum.

Keywords: Architecture, BIM, Agile Methodologies, Management 3.0, Scrum.

RESUMEN

En este trabajo se desarrolla un análisis del proceso de diseño arquitectónico y el papel del arquitecto como gerente, que actúa en el diseño y coordinación de los demás proyectos, aplicado al contexto de la industria de la construcción en Brasil. El estudio desarrolla una visión general de los efectos de la aplicación de la utilización de la tecnología BIM y revisa el desarrollo de los conceptos de gestión de proyectos a los nuevos conceptos del Manifiesto Ágil, con énfasis en la metodología Scrum. A partir del análisis bibliográfico, discutió la implementación de la nueva tecnología BIM y cómo esta herramienta sufre dificultades de establecerse en primer lugar; Pero estos impedimentos son recompensados después del cambio, con la adquisición de resultados satisfactorios. Dicho esto, se concluye que dicho despliegue se facilita y mejora con el uso de Scrum.

Palabras clave: Arquitectura, BIM, Metodologías Ágiles, Gestión 3.0, Scrum.

LISTA DE FIGURAS

FIGURA 1: PERCENTUAL DE EMPRESAS QUE OBTIVERAM ROI POSITIVO (POR PAÍSES) ........ 24 FIGURA 2: TEMPO QUE AS EMPRESAS UTILIZAM O BIM .................................................... 24 FIGURA 3: NÍVEL ATUAL DE IMPLEMENTAÇÃO DO BIM ...................................................... 25 FIGURA 4: NÍVEL DE EXPERTISE EM BIM ........................................................................ 25 FIGURA 5: NÍVEL DE COMPROMISSO COM O BIM ............................................................. 26 FIGURA 6: ROI PERCEBIDO NO USO DO BIM................................................................... 26 FIGURA 7: FATORES CITADOS COMO DE ALTO IMPACTO NA MELHORIA DO ROI ................... 27 FIGURA 8: PREVISÃO

DE INVESTIMENTOS EM

PELO GRAU DE IMPORTÂNCIA

BIM

PARA OS PRÓXIMOS

ANOS AVALIADOS

................................................................................. 27

FIGURA 9: PRINCIPAIS BENEFÍCIOS CITADOS PELAS EMPRESAS QUE UTILIZAM O BIM ......... 28 FIGURA 10: MOTIVOS PARA ADOTAR O ÁGIL ................................................................... 29 FIGURA 11: EM QUE PONTOS O PROJETO APRESENTOU MELHORIAS COM A IMPLANTAÇÃO DO ÁGIL .................................................................................................................... 29 FIGURA 12: MODELO DE INTERAÇÃO EM EQUIPES SEM COORDENAÇÃO ............................. 40 FIGURA 13: MODELO

DE INTERAÇÃO EM EQUIPES COM O ARQUITETO, AUTOR DO PROJETO,

COMO COORDENADOR ........................................................................................... 41

FIGURA 14: MODELO DE INTERAÇÃO EM EQUIPES COM COORDENADOR INDEPENDENTE...... 42 FIGURA 15: IMPACTO DA VARIÁVEL COM BASE NO TEMPO DECORRIDO DO PROJETO ........... 46 FIGURA 16: ESQUEMA GENÉRICO DE UM PROCESSO SEQUENCIAL DE DESENVOLVIMENTO DO PROJETO DE EDIFÍCIOS – PARTICIPAÇÃO DOS AGENTES AO LONGO DO PROCESSO....... 49

FIGURA 17: ESTRUTURA ANALÍTICA

PROJETO (EAP),

PRIMEIRO NÍVEL, CONSIDERANDO

AS FASES DO PROJETO DE ARQUITETURA. ............................................................... 51

FIGURA 18: DISTRIBUIÇÃO DO TRABALHO NO TEMPO CONSIDERANDO AS FASES DO PROJETO DE ARQUITETURA .................................................................................................. 51

FIGURA 19: FLUXO GERAL DE ETAPAS DO DESENVOLVIMENTO DE PROJETO ....................... 53 FIGURA 20: AS

TRÊS ÁREAS OU

―ZONAS‖

DE APLICAÇÃO DA ENGENHARIA SIMULTÂNEA

DENTRO DO PROCESSO DE PRODUÇÃO DO EMPREENDIMENTO ................................... 55

FIGURA 21: PROPOSTA

PARA A SEQUÊNCIA DO PROJETO (FASES

III)

PRIVILEGIANDO O

PARALELISMO E A INTERATIVIDADE ENTRE AS ETAPAS DO PROJETO............................ 57

FIGURA 22: O PROCESSO DE PROJETO SEGUNDO A ÓTICA DA GESTÃO DE QUALIDADE. ....... 66 FIGURA 23: NÍVEIS DE MATURIDADE DO BIM, VISÃO INGLESA. .......................................... 72 FIGURA 24: NÍVEL DE DESENVOLVIMENTO – LOD – PARA O PROJETO DE UMA CADEIRA. .... 74

FIGURA 25: NÍVEL DE DETALHAMENTO – G – PARA O PROJETO DE UMA CADEIRA ............... 75 FIGURA 26: CURVA

MACLEAMY,

MOSTRANDO A COMPARAÇÃO ENTRE O PROCESSO

TRADICIONAL E O PROCESSO BIM/IPD.................................................................... 78

FIGURA 27: CICLO DE VIDA DOS GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETOS. ........................................................................................................................... 86 FIGURA 28: OS GRUPOS DE PROCESSOS INTERAGEM EM UMA FASE OU EM UM PROJETO. ... 87 FIGURA 29: AS DEZ ÁREAS DE CONHECIMENTO CONFORME O PMBOK. ............................ 89 FIGURA 30: GRUPO

DE PROCESSOS DE GERENCIAMENTO DE PROJETO E MAPEAMENTO DAS

ÁREAS DE CONHECIMENTO. .................................................................................... 91

FIGURA 31: IMPACTO DA VARIÁVEL COM BASE NO TEMPO DECORRIDO DO PROJETO. .......... 92 FIGURA 32: MODELO CYNEFIN ADAPTADO DE DAVE SWONDEN, 1999. ............................. 99 FIGURA 33: NÍVEIS

COMPLEXIDADE

INCERTEZA

VERSUS

POSSIBILIDADE

PLANEJAMENTO E O GERENCIAMENTO DE ELABORAÇÃO DO PRODUTO,

ANÁLISE

DE DE

COMPLEXIBILIDADE, ELABORADA SOBRE BASE DE GERÊNCIA DE RISCOS ADAPTADA DE

SALLES ET AL., (2006) (APUD LOPES, 2015, P. 24). .............................................. 101 FIGURA 34: MANIFESTO PARA O DESENVOLVIMENTO ÁGIL DE SOFTWARE. ....................... 104 FIGURA 35: MARTIE, A ILUSTRAÇÃO JURGEN APPELO MOSTRANDO AS 6 VISÕES DA GESTÃO 3.0. ................................................................................................................... 109 FIGURA 36: FORMAÇÃO SCRUM NO JOGO DE RÚGBI. ..................................................... 111 FIGURA 37: FORMAÇÃO SCRUM NO JOGO DE RÚGBI. ..................................................... 111 FIGURA 38: NÍVEIS

COMPLEXIDADE

INCERTEZA

VERSUS

POSSIBILIDADE

PLANEJAMENTO E O GERENCIAMENTO DE ELABORAÇÃO DO PRODUTO,

ANÁLISE

DE DE

COMPLEXIBILIDADE, ELABORADA SOBRE BASE DE GERÊNCIA DE RISCOS ADAPTADA DE

SALLES ET AL., (2006) (APUD LOPES, 2015, P. 24). .............................................. 113 FIGURA 39: VISÃO GERAL DOS PAPÉIS DO SCRUM ....................................................... 120 FIGURA 40: SEMANA DA SPRINT ................................................................................. 125 FIGURA 41: CICLO DO SCRUM ..................................................................................... 135 FIGURA 42: SCRUM VERSUS O MODELO TRADICIONAL CASCATA (WATERFALL) .............. 137 FIGURA 43: MODELO

PADRÃO DE QUADRO DE VISUALIZAÇÃO DO ANDAMENTO DAS TAREFAS

UTILIZADO COM FREQUÊNCIA NO

SCRUM. NA LATERAL, EM DETALHE, OS GRÁFICOS TIPO

BURNDOWN E BURNUP, ONDE SE PODE COMPARAR O TRABALHO PROGRAMADO COM O EFETIVAMENTE FEITO. ......................................................................................... 141

FIGURA 44: MODELO GENÉRICO DE KANBAN ................................................................ 143

LISTA DE QUADROS

QUADRO 1: ATIVIDADES PRESENTES NA COORDENAÇÃO DE PROJETO DE EDIFÍCIO ............. 38 QUADRO 2: ESPECIALIDADES DE PROJETO NA CONSTRUÇÃO DE EDIFÍCIO .......................... 39

LISTA DE TABELAS

TABELA 1: SCRUM X O MODELO TRADICIONAL DE GERENCIAMENTO DE PROJETOS SEGUNDO O SCRUMSTUDY. .............................................................................................. 144

SUMÁRIO

INTRODUÇÃO ................................................................................................... 18 1.1

Objetivos Gerais.......................................................................................... 21

1.2

Objetivos Específicos .................................................................................. 22

1.3

Relevância e Justificativa ............................................................................ 22

REFERENCIAL TEÓRICO ................................................................................. 31 2.1

Teoria relacionada à Arquitetura. ................................................................ 31

2.1.1

Contexto sobre Arquitetura .................................................................... 31

2.1.2

Definições de Arquitetura ...................................................................... 35

2.1.3

As Atribuições do Arquiteto Urbanista ................................................... 35

2.1.4

O Arquiteto Gestor ................................................................................. 37

2.1.5

Modelos de equipes multidisciplinares e fluxo de informações ............. 38

2.1.6

Mudanças .............................................................................................. 43

2.1.7

O Processo Criativo ............................................................................... 43

2.1.8

Métodos criativos ................................................................................... 45

2.1.9

O Ciclo de vida do Projeto de Arquitetura .............................................. 46

2.1.10

O Processo do Projeto arquitetônico .................................................. 48

2.1.11

As Fases do Projeto Arquitetônico ..................................................... 50

2.1.12

As Fases de coordenação de projetos arquitetônicos ........................ 51

2.2

Projeto Simultâneo ...................................................................................... 54

2.2.1

Possibilidades para o projeto simultâneo .............................................. 54

2.2.2

Proposta para o desenvolvimento simultâneo de projetos .................... 56

2.2.3

Dificuldades na implantação do projeto simultâneo ............................... 58

2.3

A qualidade nos Projetos ............................................................................ 59

2.3.1

Kaizen e PDCA ...................................................................................... 59

2.3.2

As origens do padrão internacional ISO 9000. ...................................... 60

2.3.3

Os princípios da Gestão da Qualidade. ................................................. 61

2.3.4

A qualidade nos Projetos Arquitetônicos ............................................... 64

2.3.5

Aumento da demanda por qualidade nos Projetos Arquitetônicos ........ 64

2.3.6

Tendência de resposta no aumento da qualidade ................................. 65

2.3.7

O Projeto visto pela Gestão da Qualidade ............................................. 65

2.3.8

O Plano da Qualidade: definição e importância ..................................... 67

2.4

A tecnologia BIM ......................................................................................... 68

2.4.1

A inovação da tecnologia da Informação nos Projetos Arquitetônicos .. 68

2.4.2

Níveis de maturidade do BIM ................................................................ 71

2.4.3

Nível de Desenvolvimento – LOD .......................................................... 72

2.4.4

Nível de Detalhe .................................................................................... 74

2.4.5

As novas dimensões estendidas do desenho: 3D, 4D, 5D, 6D e 7D ..... 75

2.4.6

O Desenvolvimento Integrado do Empreendimento .............................. 77

2.4.7

A integração do BIM com ferramentas de gestão. ................................. 79

2.4.8

As principais ―barreiras‖ para a mudança para a tecnologia BIM .......... 79

2.4.9

Impactos da implantação de sistemas BIM ........................................... 81

2.5

O Gerenciamento de Projetos ..................................................................... 82

2.5.1

Gestão 1.0 ............................................................................................. 82

2.5.2

Gestão 2.0 ............................................................................................. 83

2.5.2.1 2.5.3

O Surgimento do PMI ...................................................................... 84

Gestão 3.0 ............................................................................................. 95

2.5.3.1

Teoria da Complexidade ................................................................. 96

2.5.3.2

O modelo Cynefin ........................................................................... 98

2.5.3.3

Sistemas Adaptativos Complexos ................................................. 100

2.5.3.4

Desconhecido-Conhecido e Desconhecido-Desconhecido ........... 100

2.5.3.5

Movimento Ágil .............................................................................. 102

2.5.3.6

4 Valores do Manifesto Ágil........................................................... 102

2.5.3.7

12 Princípios por trás do Manifesto Ágil ........................................ 103

2.5.3.8

Manifesto para o desenvolvimento ágil de software ...................... 104

2.5.3.9

Método Toyota – Lean Thinking .................................................... 105

2.5.3.10 Lean Software Development ........................................................ 105 2.5.3.11 Design Thinking ............................................................................ 105 2.5.3.12 Lean Construction ........................................................................ 106

2.5.3.13 Conceitos de Gestão 3.0 .............................................................. 107 2.5.3.13.1 As 6 Visões da Gestão 3.0. ................................................... 108 2.6

Teoria relacionada ao Scrum .................................................................... 110

2.6.1

Introdução ao Scrum ........................................................................... 110

2.6.2

Definição do Scrum ............................................................................. 112

2.6.3

Teoria do Scrum .................................................................................. 113

2.6.4

Os Princípios do Scrum ....................................................................... 114

2.6.4.1

Controle de Processos Empíricos ................................................. 114

2.6.4.1.1 Os Pilares do Scrum ................................................................ 114 2.6.4.1.2 Os Valores do Scrum ............................................................... 115 2.6.5

O time Scrum ....................................................................................... 116

2.6.5.1

Product Owner (PO) – Dono do Produto ....................................... 117

2.6.5.2

O Time de Desenvolvimento ......................................................... 118

2.6.5.3

Scrum Master ................................................................................ 119

2.6.5.4

Auto-organização .......................................................................... 120

2.6.5.5

Colaboração .................................................................................. 121

2.6.5.5.1 Benefícios da Colaboração em Projetos Scrum ...................... 122 2.6.5.6

Priorização baseada em valor ....................................................... 122

2.6.5.7

Time-boxing .................................................................................. 123

2.6.6

Eventos Scrum .................................................................................... 124

2.6.6.1

Sprint ............................................................................................. 125

2.6.6.2

Reunião de Planejamento da Sprint .............................................. 126

2.6.6.3

Reunião Diária .............................................................................. 128

2.6.6.4

Revisão da Sprint .......................................................................... 129

2.6.6.5

Retrospectiva da Sprint ................................................................. 130

2.6.7

Artefatos Scrum ................................................................................... 131

2.6.7.1

Backlog de Produto ....................................................................... 132

2.6.7.2

Backlog da Sprint .......................................................................... 134

2.6.7.3

Incremento .................................................................................... 134

2.6.7.4

Desenvolvimento iterativo ............................................................. 136

2.6.8

Conceitos do Framework ..................................................................... 138

2.6.8.1

Pronto e Preparado ....................................................................... 139

2.6.8.2

Estimativa de Esforço ................................................................... 139

2.6.8.3

Monitoramento .............................................................................. 140

2.7

Kanban...................................................................................................... 141

2.8

Scrum versus PMI ..................................................................................... 143

CONCLUSÃO ................................................................................................... 148

REFERÊNCIAS BIBLIOGRÁFICAS ................................................................ 149

INTRODUÇÃO “A única constante é a mudança.” Heráclito de Éfeso

A Arquitetura, desde a sua origem, sempre esteve ligada ao desenvolvimento tecnológico,

construído

partir

experiências

empíricas,

através

desenvolvimento de técnicas construtivas, de observações de caraterísticas dos materiais e do meio ambiente. No primeiro momento, o projeto acontecia simultaneamente à obra, de maneira que as tomadas de decisão aconteciam dentro da obra sem sequer muita representação. A importância do projeto arquitetônico como conceituação e planejamento ganha força no século XV, com o projeto vencedor de Brunelleschi para a construção da cúpula da catedral de Santa Maria del Fiore, no qual se propõe um sistema estrutural inovador, capaz de vencer o vão de 42 metros com menos apoios. (Fabricio, 2008, p. 29). Após a Revolução Industrial, com o desenvolvimento da indústria e a produção de novos materiais e sistemas construtivos, surgem as especializações e regulamentações das profissões de arquiteto e engenheiro. Assim, o projeto arquitetônico se direciona para as questões de forma e função, ao passo que a engenharia tratava de promover as soluções técnicas para atender a concepção e a execução do projeto. Desta forma, podemos analisar o projeto arquitetônico como um projeto macro, agregado às especializações dos projetos complementares. Assim, Constata-se que na construção de edifícios existe uma relação hierárquica entre a arquitetura e todos os demais projetos que compõem o edifício. De acordo com Melhado (1997), as normas técnicas em vigor, bem como os textos institucionais que tratam do assunto, consideram o projeto de arquitetura como o responsável pelas indicações a serem seguidas pelos projetos de estruturas e instalações. (FABRÍCIO; BAÍA; MELHADO; 1998, p. 02)

No entanto, devido a esta visão focada das especializações, ocorrem ruídos na comunicação entre as equipes e falhas na compatibilização entre os projetos. No caso de a entrega do projeto arquitetônico ocorrer sem a existência de outra equipe de

arquitetos

contratados

para

gerenciamento

obra,

algumas

incompatibilidades podem ser descobertas somente na hora da execução da mesma, ocasionando resoluções baseadas em soluções de contingenciamento. No final do século XX, com o início da utilização do desenho assistido por computador (CAD) e a popularização do uso da internet, os projetos arquitetônicos, assim como outras áreas influenciadas pela Tecnologia da Informação (TI) passam a responder por exigências de desenvolvimento cada vez mais velozes e complexos. Apesar dessa evolução, os projetos continuam sendo concebidos da através do mesmo conceito de representação gráfica em 2D. Em uma matéria da revista Arquitetura e Urbanismo, arquiteta e engenheira Gilda Lúcia Bakker Batista de Menezes, menciona um estudo escrito em 1975, por Charles M. ―Chunk‖ Eastman, dando conta que desde o artigo do protótipo do ―Building Description System‖, já se desenvolvia um novo conceito para o desenvolvimento de projetos, que alterava o paradigma do projeto de arquitetura como até então conhecíamos de representação da forma para a simulação do objeto construído. Para a arquiteta, Esse trabalho incluiu noções de BIM, hoje em dia rotineiras, tais como derivar seções, planos, isométricos ou perspectivas com base em elementos anteriormente modelados; evitar o redesenho, uma vez que as alterações são atualizadas automaticamente em todos os desenhos derivados; possibilitar o acoplamento direto da análise quantitativa à descrição dos materiais durante a modelagem, com estimativas de custo ou quantitativos de materiais sendo facilmente gerados, enquanto alimenta um banco integrado de dados; gerar código automatizado para checagem da edificação na prefeitura ou no escritório de arquitetura; facilitar a tarefa dos empreiteiros de grandes obras, no tocante ao usufruto de vantagens como agendamento e encomenda de materiais. (MENEZES, 2011, p. 155-156)

Ainda de acordo com Gilda Menezes (2011), tal método ou abordagem continuou a ser desenvolvido especialmente nos Estados Unidos, como Building Product Models (modelos de produto da construção) e na Europa, especialmente na Finlândia, como Product Information Models (modelos de informação de produto), sendo descrito como BIM (Building Information Modeling) pela primeira vez, apenas em dezembro de 1992, no artigo escrito em inglês ―Automation in Construction‖ produzido pelos holandeses van Nederveen e Tolman. No entanto, o início do século XXI traz o avanço da capacidade de processamento dos novos computadores e o desenvolvimento de novos softwares, que criam as condições necessárias para a utilização desta nova abordagem para a produção de projetos dentro da indústria da construção.

Acerca da defasagem tecnológica presente no setor da construção, Luiz Antônio do Nascimento & Eduardo Toledo Santos (2003) afirmam que: a indústria da construção ainda está bastante atrasada em relação a outros setores industriais no uso das novas tecnologias de informação e comunicação. A globalização e o novo panorama mundial, bem como o atual cenário nacional, desestatizado e com escassez de financiamento, requer da construção civil urgente melhora de produtividade e competitividade. A inovação em seus produtos e processos, particularmente com a ajuda da Tecnologia da Informação (TI), pode conduzir o setor a trilhar novos rumos. (NASCIMENTO & SANTOS, 2003, p. 69)

Outras duas questões que são decisivas para o bom andamento de um projeto são a cooperação e a comunicação, haja vista que depende delas o bom andamento da obra e a satisfação dos envolvidos, com risco de acarretarem grandes prejuízos quando não são consideradas. A falta de cooperação e restrita comunicação entre as equipes de projeto, execução e fornecedores resultam em problemas já considerados normais. De acordo com Resende (2013), ―as principais causas dos atrasos em projetos a nível internacional estão relacionadas com alterações de ordens por parte do dono da obra e com mau planejamento e controle dos trabalhos por parte do empreiteiro‖, ou seja, as alterações realizadas no projeto causam uma reação em cadeia que gera retrabalho aos projetistas e aos construtores. (MASOTI, 2014, p.20-21)

Desta forma, é possível visualizar que uma alternativa é necessária, e que esta alternativa abrace todos as fases do empreendimento, desde a concepção, o projeto, a gestão, a comunicação, a execução e a operação. E esta alternativa é o BIM. Sobre a mudança da tecnologia CAD para BIM podemos citar Stephen A. Jones e Harvey M. Bernstein, no prefácio da McGraw Hill Construction, afirmam que A mudança está varrendo o globo. Equipes de projetos estão se beneficiando com comunicações mais rápidas, computadores móveis menores e mais poderosos, utilizando robustas ferramentas de modelagem digital e uma mudança transformadora em direção processo de entrega de projeto integrado, todos estes fatores voltados para a geração de resultados positivos, eficiências e benefícios inimagináveis há apenas alguns anos atrás. (MCGRAW HILL CONSTRUCTION, 2014, p.01)

Paralelamente ao avanço tecnológico no processo produtivo do projeto arquitetônico, no campo da gestão de projetos temos o surgimento de novos conceitos, como o Manifesto Ágil e o Management 3.0, sugerindo ambientes de

trabalho mais colaborativos, propondo trabalhos mais enxutos e com processos adaptativos, iterativos e incrementais. Este olhar do Manifesto Ágil, proposto para o desenvolvimento de softwares, pode ser facilmente transferido para outros projetos complexos, criativos, adaptativos, iterativos e incrementais como é o caso dos projetos de arquitetura, uma vez que atendem a uma multidisciplinaridade voltada para a inovação e a criatividade, geralmente iniciados com muitas incertezas, sendo propensos a mudanças. Atualmente, as organizações competitivas necessitam de características de velocidade e flexibilidade. Para a compreensão deste cenário complexo, faz-se necessária uma visão holística que integre as perspectivas dos especialistas. Ocorrem mudanças nas estruturas organizacionais das empresas, de um organograma vertical para estruturas horizontalizadas, que favorecem a inovação e a tomada de decisão. Ostroff (1999) ao ser citado por Severo et al (2012), observa que a organização horizontal promove a construção de uma cultura corporativa transparente, de cooperação e colaboração, com foco contínuo no desenvolvimento de performance e fortalecimento dos valores dos colaboradores, promovendo a responsabilidade na organização. (SEVERO et al, 2012, p.5)

O estudo de Severo et al (2012, p. 05) que cita Menguc e Auh (2009) ainda dá conta de que as estruturas organizações horizontais tem como objetivo promover uma maior participação de toda a equipe na obtenção dos objetivos organizacionais, aproveitando de forma mais efetiva a capacidade e as habilidades de todos os envolvidos nos processos, fomentando as inovações e gerando benefícios. E entre as metodologias Ágeis, o Scrum tem se destacado como a mais adotada. Segundo a pesquisa da VISION ONE (2015) realizada com organizações que se utilizam de metodologias ágeis, 56% das empresas pesquisadas afirmaram utilizar o Scrum.

1.1

Objetivos Gerais

O objetivo geral deste trabalho é demostrar os benefícios que podem ser alcançados através da utilização da metodologia ágil Scrum no processo de

implantação

plataforma

BIM

(Building

Information

Modeling)

para

desenvolvimento de projetos arquitetônicos.

1.2

Objetivos Específicos

Adicionalmente, busca-se atingir os seguintes objetivos secundários: 1. Demostrar o aumento do potencial da liderança e integração da equipe de projeto através da utilização da metodologia Scrum e o conceito de autoorganização; 2. Demostrar os benefícios para a melhoria continua na qualidade do projeto arquitetônico, através de Sprints iterativos e incrementais e adaptativos, priorizando-se o trabalho de mais valor percebido; 3. Reunir em um único documento algumas conclusões que vão ao encontro dos objetivos apresentados anteriormente.

1.3

Relevância e Justificativa

Entendemos que a metodologia Scrum seja um diferencial na implantação da plataforma BIM, pelo seu controle transparente e diário sobre o projeto em possíveis questões que estejam impedindo a equipe de atingir sua meta e pela integração e comprometimento da equipe com os objetivos do projeto. O foco do estudo são os escritórios de arquitetura do Brasil que utilizam ou pretendem utilizar a tecnologia BIM. Podemos entender a relevância do estudo ao analisarmos os dados sobre o crescimento do uso do BIM no Brasil e no mundo. Bem como o destaque para o desempenho da metodologia Scrum em projetos complexos. Desta forma, aliar a gestão do projeto à implantação da tecnologia BIM e o Scrum é interessante para a obtenção de melhores resultados. De acordo com a série de relatórios SmartMarket realizados pela McGraw Hill Construction desde 2007 sobre o impacto da plataforma BIM no processo do projeto arquitetônico, cujo foco principal reside nos países da Ásia, América do Norte e Oeste Europeu, durante este período o fator chave para impulsionar o uso da

plataforma foi possibilidade de melhores análises qualitativas e quantitativas do projeto. O relatório que foi desenvolvido exclusivamente através da análise de dados coletados a partir de empresas que utilizam a plataforma BIM, para a melhoria da produtividade, eficiência, qualidade, segurança e sua própria competitividade. De acordo com o estudo realizado pela McGraw Hill Construction, as principais conclusões da pesquisa relatadas por Stephen A. Jones e Harvey M. Bernstein são:  75% das empresas de construção relataram um retorno positivo sobre o (ROI – Return of Investment) e que a plataforma BIM proporcionou idéias claras sobre como melhorar ainda mais o ROI.  Redução de erros e omissões no projeto, menos retrabalho e construções com custos mais baixos estão entre os cinco maiores benefícios BIM citados pelos contratantes.  Ao longo dos próximos dois anos, empreiteiros esperam um aumento médio de 50% do seu trabalho que envolve BIM.  O ROI aumenta diretamente ao aumento do nível de detalhamento do BIM, e com o engajamento e sua experiência em BIM, o aumento do nível de habilidade e engajamento de fazer uma grande parte do trabalho em BIM  Organizações em todos os mercados estão a planejando, investimentos significativos para expandir seus programas BIM ao longo dos próximos dois anos, incluindo um foco crescente sobre os procedimentos de colaboração interna e externa, bem como hardware e software para atenderem a plataforma BIM. (JONES e BERNSTEIN, 2014, p.1)

Esta pesquisa tem como categorias-chave da investigação o retorno do investimento (ROI – Return of Investment) para a implantação da nova tecnologia e o compromisso de novos investimentos.

Assim, o percentual de empresas que

obtiveram ROI positivo em todos os países pesquisados pode ser visto na Figura 1.

Figura 1: Percentual de empresas que obtiveram ROI positivo (por países)

Empresas que relataram um ROI positivo sobre o para BIM Japão

97%

Alemanha

97%

França

97%

Canadá

87%

Brasil

85%

Austrália e Nova Zelândia

78%

Estados Unidos

74%

Reino Unido

59%

Korea do Sul

48%

Fonte: McGraw Hill Construction, 2013

Quanto à implantação no BIM do Brasil, a pesquisa (McGraw Hill Construction, 2013) nos mostra os dados apresentados nas figuras a seguir: Figura 2: Tempo que as empresas utilizam o BIM

Tempo que as empresas utilizam o BIM Brasil

Outros Países

70% 47% 28%

27%

18% 3%

De 1 à 2 anos

De 3 à 5 anos

De 6 à 10 anos

11 anos ou mais

Fonte: McGraw Hill Construction, 2013

Podemos observar que a utilização no Brasil é recente, sendo inferior a 10 anos e com forte crescimento nos anos de 2011 e 2012.

Figura 3: Nível atual de implementação do BIM

Nível Atual de implementação do BIM Brasil 35%

40% 29%

31%

Outros Países

22%

17% 2%

Leve (menos de 15% dos projetos)

Médio (de 15% à 30% dos projetos)

Forte (de 31% à 60% dos projetos)

Muito Forte (mais do que 60% dos projetos)

Fonte: McGraw Hill Construction, 2013

O processo de projeto através da plataforma BIM ainda ocorre de maneira moderada a média em 75% dos projetos. Sendo baixo o número de organizações que utilizam a plataforma em mais de 60% dos seus projetos em desenvolvimento.

Figura 4: Nível de expertise em BIM

Nível de Expertise em BIM Brasil

42% 15%

37%

21%

Iniciante

Outros Países

32%

29% 10%

Moderado

Avançado

13%

Expert

Fonte: McGraw Hill Construction, 2013

O nível de expertise em BIM, no Brasil, está próximo da média internacional, com números abaixo da média nos níveis iniciante e expert, e acima da média nos níveis moderado e avançado.

Figura 5: Nível de compromisso com o BIM

Nível de compromisso com o BIM Brasil

Outros Países

55% 36%

36%

33%

17%

13%

11% 0%

Baixo

Médio

Alto

Muito Alto

Fonte: McGraw Hill Construction, 2013

No entanto, ainda são poucos os escritórios que possuem a maior parte da sua produção em BIM.

Figura 6: ROI percebido no uso do BIM

ROI percebido no uso do BIM

15% 36%

ROI muito positivo (> 25%) ROI moderadamente positivo (< 25%)

49%

ROI negativo

Fonte: McGraw Hill Construction, 2013

Entre as empresas pesquisadas no Brasil, 85% afirmaram ter obtido um ROI positivo. Sendo que, dentre elas, 36% obtiveram um retorno do investimento acima de 25%.

Figura 7: Fatores citados como de alto impacto na melhoria do ROI

Fatores citados como de alto impacto na melhoria do ROI Melhor Comunicação entre os projetos envolvidos e entendimento do projeto através da visualização 3D

46%

54%

Melhoria da Produtividade da Equipe Melhoria do Projeto e dos Processos de Entrega

62%

Fonte: McGraw Hill Construction, 2013

Figura 8: Previsão de Investimentos em BIM para os próximos 2 anos avaliados pelo grau de importância

Previsão de Investimentos em BIM para os próximos 2 anos avaliados pelo grau de importância Brasil

Desenvolvimento de uma biblioteca padrão 3D

Outros Países 23% 34%

Novos e/ou Upgrades em Laptops ou Tablets

26%

Personalização do Software / Interoperabilidade de Soluções

26%

Desenvolvimento Externo Colaborativo na plataforma BIM Novos e/ou Upgrades em Desktops Treinamento BIM Software BIM Desenvolvimento Interno Colaborativo na plataforma BIM Fonte: McGraw Hill Construction, 2013

38% 32% 31% 43% 33% 34% 40% 45%

40% 41% 45% 49%

Figura 9: Principais Benefícios citados pelas empresas que utilizam o BIM

Principais Benefícios citados pelas empresas que utilizam o BIM Brasil

Outros Países

Benefícios Internos do BIM Reforça a Imagem da organização Marketing para novos negócios

32%

41%

21% 19%

Benefícios para o Projeto com o uso do BIM Redução dos Custos da Construção

46%

23% 26%

Redução de Erros e Omissões

41%

Benefícios do Processo em BIM Melhor Controle de Custos / Melhor Previsibilidade Colaboração entre Clientes e Escritórios de Projeto

21% 23%

31%

35%

Fonte: McGraw Hill Construction, 2013

De acordo com a pesquisa realizada pela Editora PINI em 2013, com 588 entrevistados, composta de 54,08% de Arquitetos e 45,92% de Engenheiros, constatou-se que a maioria (62,07%) ainda não trabalha com a plataforma BIM. Entretanto, quando perguntados se tinham a intenção de realizar a implementação do BIM e em quanto tempo, apenas 9,38% dos entrevistados disseram não ter intenção na implementação da plataforma BIM, 37,78% responderam que pretendiam implantá-la em um ano e 52,84% disseram pretender implantá-la no período de um a cinco anos. Portanto, podemos verificar a tendência de que mais de 90% dos entrevistados pretendem trabalhar com a plataforma até 2018. E sobre as metodologias ágeis, atualmente de acordo com a pesquisa da (VISION ONE, 2015) realizada 65% na América do Norte, 21% Europa e 14% pelo resto do mundo, com organizações que se utilizam de métodos ágeis, apesar de ser composta predominantemente por organizações de desenvolvimento de software, (53%), foram apresentados os seguintes dados:

Figura 10: Motivos para adotar o Ágil

Motivos para adotar o Ágil Acelerar a entrega do produto

59%

Melhorar a capacidade de gerir mudanças de…

56%

Aumentar a produtividade

53%

Melhorar a qualidade do software

46%

Aumentar a previsibilidade de entrega

44%

Melhorar os negócios / alinhamento de TI

40%

Melhorar a visibilidade do projeto

40%

Reduzir o risco do projeto

38%

Melhorar o moral da equipe

26%

Melhorar a disciplina de engenharia

25%

Reduzir o custo do projeto

23%

Aumentar a capacidade de manutenção de software

22%

Gerenciar melhor equipes distribuídas

20%

Fonte: (VISION ONE, 2015)

Figura 11: Em que pontos o projeto apresentou melhorias com a implantação do Ágil

Em que pontos o projeto apresentou melhorias com a implantação do Ágil Entregas no prazo

58%

Qualidade do produto

48%

Satisfação do Cliente / Usuário

44%

Valor do negócio

44%

Escopo do Produto

39%

Visibilidade do Projeto

30%

Produtividade

29%

Previsibilidade

25%

Melhoria dos processos Não soube responder

Fonte: (VISION ONE, 2015)

23% 11%

Através dos dados apresentados, podemos verificar os benefícios esperados e apresentados com a adoção dos métodos ágeis nas organizações de projetos. Com o aumento da qualidade proporcionado pela tecnologia BIM, aliado aos conceitos de gestão do Scrum, acreditamos na potencialização desta tecnologia com a aplicação deste tipo de gestão. O presente estudo pretende avaliar o potencial para a otimização do desenvolvimento dos projetos de arquitetura na plataforma BIM, aliados à gestão ágil da metodologia Scrum. Para isto, inicialmente apresenta uma introdução para a contextualização do assunto, a justificativa e relevância do mesmo e seus objetivos. A segunda parte aborda a fundamentação teórica necessária para embasar o estudo, como o papel do arquiteto como gestor e o processo de projeto na arquitetura, o projeto simultâneo, questões ligadas à qualidade dos projetos e, ainda, sobre a nova tecnologia BIM. Além de abordar um breve histórico do gerenciamento de projetos e do surgimento do Management 3.0, dos Métodos Ágeis e do Scrum, bem como os impactos destas ferramentas na competitividade e qualidade dos projetos. A última parte encerra o trabalho, tecendo algumas conclusões gerais a respeito dos tópicos específicos apresentados.

2 2.1

REFERENCIAL TEÓRICO Teoria relacionada à Arquitetura.

2.1.1 Contexto sobre Arquitetura Cross (1999) ao ser citado por Márcio M. Fabrício (2008, p. 26), afirma que ―A humanidade dispõe de uma habilidade cognitiva inata para representar e “projetar” a construção de artefatos, como pode ser observado desde as construções vernaculares e em desenhos rupestres‖. Desde o surgimento da agricultura e a fixação do homem no campo, a necessidade de abrigo promoveu o conhecimento empírico para as construções através do desenvolvimento de técnicas construtivas e o conhecimento das propriedades dos materiais. Porém, as soluções construtivas eram tomadas in loco, e o projeto estava fortemente atrelado ao ato de executar a obra. Os primeiros estudos conhecidos sobre as construções e sobre as áreas de conhecimento da profissão, são tratados no livro ―De architectura”, escrito no século I a.C. pelo arquiteto engenheiro e escritor, o romano, Marcus Vitruvius Pollio – Vitrúvio. Em seu tratado, Vitrúvio discorre sobre o que é arquitetura e o que é necessário para formação do ―arquiteto‖, a salubridade dos espaços, dos requisitos mecânicos e estruturais das construções, de questões sobre a habitabilidade, a estética nas edificações, das proporções, soluções de projeto e construtivas, geometria, propriedade dos materiais, e outros temas. No Renascimento, o texto vitruviano foi redescoberto, assim como outros valores da antiguidade Clássica, servindo de base para os tratados de Alberti e Palladio. No século XV, através do desenvolvimento de um projeto abstrato baseado em conceitos e técnicas construtivas Brunelleschi desenvolve o projeto vence o concurso para a construção da cúpula da catedral de Santa Maria del Fiore, em Florença. Através deste estudo, Brunelleschi mostra a importância do planejamento para a execução de uma obra de sucesso; uma vez que, anteriormente, as cúpulas eram desenvolvidas in loco, por tentativa e erro. Segundo Picon, 1993 (apud Fabricio 2008, p. 29):

A ruptura trazida pela Renascença não é só teórica; ao mesmo tempo em que se redescobre Vitrúvio, afirma-se, de fato, uma nova figura de arquiteto humanizada qual um Filippo Brunelleschi (1377-1446) constitui uma das primeiras encarnações. (PICON, 1993)

Segundo Carvalho Jr., 1994 (apud Fabricio 2008, p. 29): De fato, ao vencer o concurso para projetar a cobertura da catedral, propondo a construção de uma imensa cúpula de 42 m de vão, quase sem a utilização de cimbramentos, Brunelleschi lança mão de uma notável compreensão qualitativa do funcionamento estrutural de sua cúpula e, como sugerem inúmeras evidências, detém uma espantosa compreensão quantitativa do comportamento da estrutura da cúpula. (CARVALHO JR., 1994).

No século XVII, o desenvolvimento de estudos matemáticos e físicos, como a obra de Bonaventura Cavalieri, sobre geometria e trigonometria; a geometria analítica, por Descartes (1637); a lei de elasticidade dos corpos, de Robert Hooke (1653-1703); a descoberta do cálculo das probabilidades, por Pascal e Pierre de Fermat (1601- 1665) e o cálculo diferencial e integral, por Newton e Leibniz (BARSA, 2000) servem de base para o desenvolvimento de tecnologias. No entanto, a partir do século XVIII, com a Revolução Industrial e o desenvolvimento da tecnologia, o ato de projetar começa a incorporar o conhecimento cientifico, de modo que comecem a surgir as especializações para atender a demanda de complexidade dos projetos. Surgem as primeiras escolas de engenharia, tais como a: École Nacionale de Ponts et Chaussées (criada em 1747), a École des Mines (1783) e a École Polytechnique (1794), na França; além da Escola Politécnica em Coimbra, em Portugal (1837) e o Politecnico di Torino, na Itália (1859). As escolas de arquitetura começam a ser desenvolvidas primeiramente nas escolas de belas artes, até se tornarem independentes com a criação das escolas superiores de arquitetura, nos séculos XIX e XX, promovendo o reconhecimento das profissões de arquiteto e de engenheiro, como profissões formais e regulamentadas, que exigem formação para a sua habilitação profissional. Assim, com a regulamentação das profissões, o conhecimento sobre as construções dos espaços, que sempre esteve concentrado em uma única figura (a do Arquiteto Engenheiro) divide-se em duas profissões.

A origem do termo ―Arquiteto‖ já existe há muitos séculos, desde os antigos gregos, romanos e egípcios. No entanto, o reconhecimento da profissão é um conceito relativamente moderno. A etimologia da palavra arquiteto tem origem no francês antigo architecte, do latim architectus, do grego arkhitekton, ―mestre construtor, diretor de obras‖, de arkhi- ―chefe, primeiro, de alto nível‖, e tekton ―construtor, carpinteiro‖. Por sua vez, a palavra engenheiro decorre da palavra latina ingenium, derivada da raiz do verbo gignere, que significa gerar, produzir, isto é, o engenheiro é o encarregado da produção. Podemos fazer uma analogia, comparando o arquiteto com o maestro, por ser aquele que concebe e define a execução de todos os instrumentos e tem a visão geral do resultado da orquestra, e o engenheiro com o grande solista, especialista em seu tema e fundamental para que a música aconteça. No início do século XX, com o crescimento das cidades e a necessidade do aumento da produção de habitações e outras tipologias arquitetônicas surge a arquitetura moderna; que ao invés da arquitetura eclética, que valorizava os ornamentos, dá lugar a uma arquitetura industrializada, seguindo o conceito da ―máquina de morar‖, idealizado por Le Corbusier, em seu livro ―Por uma Arquitetura‖, em 1923. A partir daí o conceito de que ―a forma segue a função‖, se populariza, trazendo cada vez mais para o desenvolvimento do projeto e das construções de edificações, a tecnologia, o conhecimento científico e a multidisciplinaridade de conhecimentos. Em novembro de 1933, em Atenas, ocorre uma assembleia do CIAM Congresso Internacional de Arquitetura Moderna, na qual os principais arquitetos representantes da arquitetura moderna publicam a Carta de Atenas. Nesta carta, discute-se a complexidade que a arquitetura e o urbanismo representam para o desenvolvimento das cidades. O documento trata das contínuas modificações provocadas pela era da máquina e o desenvolvimento das grandes cidades, as quais devem levar em conta seus aspectos econômicos, sociais, políticos, psicológicos e fisiológicos, ante os reflexos de ordem individual e coletiva dos habitantes. Bem como a interação da cidade com o meio ambiente e sua região, a salubridade das habitações, o zoneamento urbano, a insolação das edificações, planejamento urbano, tecnologias

construtivas, diretrizes para áreas de lazer, de trabalho, de circulação e o Patrimônio Histórico. Segundo Castro, 1999 (apud Fabricio 2008, p. 31): De fato, o paradigma taylorista-fordista de produção, assimilado pela arquitetura moderna, traz consigo uma contínua e crescente separação entre o projeto e a execução, pautados em um ideal de industrialização das construções que se desenvolve em uma visão de sistema, subsistemas e componentes construtivos a demandarem soluções especializadas e, por conseguinte, projetos parcelados de especialidades. (CASTRO, 1999)

Em 1972, a publicação do primeiro relatório do Clube de Roma, ―Os Limites do Crescimento‖, serve de embrião para a criação do conceito de desenvolvimento sustentável. Conceito este que se torna uma necessidade em diversas indústrias seja para atender a restrições regulamentares e governamentais, ou para agregar qualidade e valor à marca. O mesmo ocorre na indústria da construção: o desenvolvimento dos projetos arquitetônicos que se torna cada vez mais complexo, a busca pela eficiência, através do conceito de sinergia, de Buckminister Füller (fazer mais com menos), a análise integrada de todo o ciclo de vida do produto (do berço ao túmulo) e o respeito aos princípios de responsabilidade social, ambiental e econômica. Atualmente os projetos arquitetônicos são desenvolvidos, por uma equipe multidisciplinar

colaborativa

diversos

arquitetos,

engenheiros,

outros

especialistas que se tornem necessários para atender as necessidades do projeto e da obra. Segundo (Fabricio 2008, p. 31), No modelo tradicional, a interação entre esses profissionais ocorre segundo uma abordagem cartesiana em que cada profissional se sucede no processo de projeto, acrescentando sua contribuição particular ao todo. Por outro lado, novos paradigmas de colaboração e informação colocam como referência uma abordagem mais multidisciplinar e participativa, na qual a concepção de artefatos surge de complexas interações entre equipes de especialidades que se entrelaçam em redes criativas. (FABRICIO, 2008).

2.1.2 Definições de Arquitetura

Definir Arquitetura no contexto de nosso mundo contemporâneo, complexo e dinâmico e de aceleradas mudanças é algo que necessita de uma análise constante e adaptativa. O arquiteto e urbanista Lúcio Costa (1940) a define como Antes de mais nada: construção; mas construção concebida com o propósito primordial de ordenar e organizar o espaço para determinada finalidade e visando a determinada intenção. E nesse processo fundamental de ordenar e expressar-se ela se revela igualmente arte plástica, porquanto nos inumeráveis problemas com que se defronta o arquiteto desde a germinação do projeto até a conclusão efetiva da obra, há sempre, para cada caso específico, certa margem final de opção entre os limites - máximo e mínimo - determinados pelo cálculo, preconizados pela técnica, condicionados pelo meio, reclamados pela função ou impostos pelo programa, - cabendo então ao sentimento individual do arquiteto, no que ele tem de artista, portanto, escolher na escala dos valores contidos entre dois valores extremos, a forma plástica apropriada a cada pormenor em função da unidade última da obra idealizada. [...] A intenção plástica que semelhante escolha subentende é precisamente o que distingue a arquitetura da simples construção. [...] Por outro lado, a arquitetura depende ainda, necessariamente, da época da sua ocorrência, do meio físico e social a que pertence, da técnica decorrente dos materiais empregados e, finalmente, dos objetivos e dos recursos financeiros disponíveis para a realização da obra, ou seja, do programa proposto. [...] Pode-se então definir arquitetura como construção concebida com a intenção de ordenar e organizar plasticamente o espaço, em função de uma determinada época, de um determinado meio, de uma determinada técnica e de um determinado programa. [...] É a arte ou técnica de projetar e edificar o ambiente habitado pelo ser humano. Uma definição mais precisa da área envolve todo o design do ambiente construído pelo homem, o que engloba desde o desenho de mobiliário (desenho industrial) até o desenho da paisagem (paisagismo) e da cidade (urbanismo), passando pelo desenho dos edifícios e construções (considerada a atividade mais comum dos arquitetos). O trabalho do arquiteto envolve, portanto, toda a escala da vida do homem, desde a manual até a urbana. (COSTA, 1940)

2.1.3 As Atribuições do Arquiteto Urbanista

Segundo a Lei n° 12.378, de 31 de dezembro de 2010, que regula as atribuições do arquiteto urbanista, as atribuições do profissional são: I - supervisão, coordenação, gestão e orientação técnica; II - coleta de dados, estudo, planejamento, projeto e especificação; III - estudo de viabilidade técnica e ambiental; IV - assistência técnica, assessoria e consultoria; V - direção de obras e de serviço técnico;

VI - vistoria, perícia, avaliação, monitoramento, laudo, parecer técnico, auditoria e arbitragem; VII - desempenho de cargo e função técnica; VIII - treinamento, ensino, pesquisa e extensão universitária; IX - desenvolvimento, análise, experimentação, ensaio, padronização, mensuração e controle de qualidade; X - elaboração de orçamento; XI - produção e divulgação técnica especializada; e XII - execução, fiscalização e condução de obra, instalação e serviço técnico. Parágrafo único. As atividades de que trata este artigo aplicam-se aos seguintes campos de atuação no setor: I - da Arquitetura e Urbanismo, concepção e execução de projetos; II - da Arquitetura de Interiores, concepção e execução de projetos de ambientes; III - da Arquitetura Paisagística, concepção e execução de projetos para espaços externos, livres e abertos, privados ou públicos, como parques e praças, considerados isoladamente ou em sistemas, dentro de várias escalas, inclusive a territorial; IV - do Patrimônio Histórico Cultural e Artístico, arquitetônico, urbanístico, paisagístico, monumentos, restauro, práticas de projeto e soluções tecnológicas para reutilização, reabilitação, reconstrução, preservação, conservação, restauro e valorização de edificações, conjuntos e cidades; V - do Planejamento Urbano e Regional, planejamento físico-territorial, planos de intervenção no espaço urbano, metropolitano e regional fundamentados nos sistemas de infraestrutura, saneamento básico e ambiental, sistema viário, sinalização, tráfego e trânsito urbano e rural, acessibilidade, gestão territorial e ambiental, parcelamento do solo, loteamento, desmembramento, remembramento, arruamento, planejamento urbano, plano diretor, traçado de cidades, desenho urbano, sistema viário, tráfego e trânsito urbano e rural, inventário urbano e regional, assentamentos humanos e requalificação em áreas urbanas e rurais; VI - da Topografia, elaboração e interpretação de levantamentos topográficos cadastrais para a realização de projetos de arquitetura, de urbanismo e de paisagismo, foto-interpretação, leitura, interpretação e análise de dados e informações topográficas e sensoriamento remoto; VII - da Tecnologia e resistência dos materiais, dos elementos e produtos de construção, patologias e recuperações; VIII - dos sistemas construtivos e estruturais, estruturas, desenvolvimento de estruturas e aplicação tecnológica de estruturas; IX - de instalações e equipamentos referentes à arquitetura e urbanismo; X - do Conforto Ambiental, técnicas referentes ao estabelecimento de condições climáticas, acústicas, lumínicas e ergonômicas, para a concepção, organização e construção dos espaços; XI - do Meio Ambiente, Estudo e Avaliação dos Impactos Ambientais, Licenciamento Ambiental, Utilização Racional dos Recursos Disponíveis e Desenvolvimento Sustentável. (BRASIL. Lei n° 12.378, 2010)

Desta forma, podemos constatar que as funções de planejamento, coordenação e gestão, bem como a visão de diversas áreas de conhecimento são inerentes ao arquiteto para o desenvolvimento dos projetos e tomada de decisões.

2.1.4 O Arquiteto Gestor

O Projeto de Arquitetura, assim como outros projetos, trata-se de um esforço temporário empreendido na criação de um produto, serviço ou resultado exclusivo, de natureza contingente que prevê um início e um término definidos. Considerando as suas atribuições profissionais, cabe ao Arquiteto o papel de conceber e coordenar um projeto multidisciplinar, desenvolvido em conjunto com colaboradores e diversos especialistas, buscando atender da melhor maneira os anseios e necessidades dos clientes, levando sempre em conta as premissas, restrições e toda a comunicação com as partes interessadas. O projeto de construção é, pois, composto por diversas especialidades de estudos (arquitetura, estrutural, sistemas prediais, etc.) que se desenvolvem em etapas de concepção com crescente nível de detalhamento. Fabrício (2008) tece comentários acerca das singularidades e do aumento da complexidade dos projetos arquitetônicos contemporâneos, lançando mão de estudos sobre os grandes empreendimentos, elaborados por Bobroff (1993) e acerca de como a indústria da construção civil se organiza, produzido por Jouini e Midler (1996), respectivamente. A crescente magnitude dos empreendimentos, o elevado valor, o longo ciclo de vida, a importância ambiental, social e econômica, a inserção urbana e cultural das edificações confere a esse produto um caráter único e particular dentro das estruturas produtivas e de consumo da sociedade. [...]A produção na indústria de construção se organiza segundo uma lógica de projetos particular, na qual coabitam problemas singulares e diferenciados a cada novo empreendimento, com soluções tecnológicas e construtivas padronizadas. (FABRÍCIO, 2008, p.32)

A partir desse pressuposto, o arquiteto deve gerir o processo de projetos, cabendo-lhe as funções de planejamento, organização, direção e controle; desde a definição do programa de necessidades, a montagem do planejamento estratégico e a condução da equipe de projetistas do empreendimento, até a integração do projeto com a obra. A gestão do processo de projeto tem dificuldades ampliadas, devido ao contínuo aumento da complexidade dos empreendimentos, a consequente subdivisão do projeto e a inserção de novas especialidades, que também serão geridas e compatibilizadas pela arquitetura, conforme podemos observa Fabrício:

Trata-se, essencialmente, de reconhecer que o projeto é um processo interativo e coletivo, exigindo uma coordenação do conjunto das atividades envolvidas, compreendendo momentos de análise crítica e de validação das soluções, sem, no entanto, impedir o trabalho especializado de cada um de seus participantes. Essa coordenação deve considerar aspectos do contexto legal e normativo que afetam cada empreendimento, estabelecer uma visão estratégica do desenvolvimento do projeto e levar, devidamente em conta, suas incertezas. (FABRICIO, 2008, p. 33)

Desta forma, podemos constatar que o arquiteto deve atuar nas frentes de gestão e coordenação técnica sobre o projeto. Conforme representado no Quadro 1, proposto por Fontenelle (2002).

Quadro 1: Atividades presentes na coordenação de projeto de edifício

Fonte: Fontenelle (2002) apud Fabrício (2008)

2.1.5 Modelos de equipes multidisciplinares e fluxo de informações

Deve-se reconhecer que o projeto arquitetônico é um estudo coletivo e interativo, exigindo a coordenação de todos os projetistas envolvidos, realizando constantemente uma análise crítica e uma validação de soluções e diretrizes, enquanto busca-se promover a comunicação entre todos os projetistas envolvidos acerca das interferências entre seus projetos, de modo que possam ser evitadas ou resolvidas.

Para o desenvolvimento de um projeto complexo e multidisciplinar, a utilização de uma estrutura organizacional projetada e colaborativa, bem como e a sinergia no trabalho e a troca de informações entre os participantes da equipe são fundamentais para a qualidade dos processos do projeto, uma vez que para Bobroff (1999) apud Fabrício (2008, p. 33) a excelência do projeto de um empreendimento passa pela excelência do processo de cooperação entre seus agentes, que na qualidade de parceiros submetem seus interesses individuais a uma confrontação organizada. (FABRÍCIO, 2008, p. 33).

Podemos considerar como especialidades inerentes a projetos de arquitetura de grande porte, as seguintes especialidades de delineamentos e suas subespecialidades e atividades projetuais, conforme representado no quadro 2.

Quadro 2: Especialidades de projeto na construção de edifício

Fonte: Melhado et al (2006) apud Fabrício (2008)

De acordo com Fabricio (2008), podemos considerar de forma genérica três modelos quanto a estrutura organizacional, o papel do coordenador e o fluxo de informações no processo do projeto: No primeiro modelo, representado na Figura 12, temos uma equipe a qual a coordenação não é formalmente assumida por nenhum agente, o que propicia trocas de informações aleatórias entre os envolvidos, sem que haja uma periodicidade

predeterminada, uma vez que tais interações são efetivadas de acordo com a necessidade. Neste modelo, como as comunicações ocorrem informalmente entre os envolvidos, existe o risco de que nenhum todos os envolvidos sejam comunicados sobre as modificações no projeto, o que pode resultar no resultado final de seus próprios projetos, o que geraria a repetição dos mesmos. Por outro lado, tal prática promove uma informação mais direta e ágil, na qual os projetistas são comunicados apenas do que é realmente inerente ao seu trabalho, evitando a sobrecarga da informação. Figura 12: Modelo de interação em equipes sem coordenação

Fonte: Adaptado de Fabrício (2008)

O segundo modelo apresentado é provavelmente o mais tradicional. Neste, o arquiteto, que tem a autoria do projeto, assume a coordenação dos demais planos envolvidos, tendo em vista que é tido como aquele que concebe o produto e institui as diretrizes a serem seguidas pelos outros colaboradores. Sendo assim, Para garantir e fomentar a coordenação surge a figura do coordenador, o qual deve ser responsável pela gestão do fluxo de informação e por fomentar a interatividade entre os diversos projetistas envolvidos. Nesse caso predominam, no setor, dois modelos organizacionais de equipes que

diferem segundo o papel e a posição do coordenador. (FABRÍCIO, 2008, p.40)

Este modelo tem como vantagem garantir que as decisões do projeto arquitetônico sejam as diretrizes de requisitos e restrições para o desenvolvimento das propostas complementares coerentes com o mesmo objetivo. Além de estabelecer uma hierarquia clara entre as equipes, fator importante para a mediação de conflitos, cujo respaldo, no Brasil, é constituído por associações (AsBEA), Normas Técnicas (NBR 13532 – ABNT, 1995) e pela grande maioria dos projetistas de arquitetura. Portanto, Em um processo sequencial, em que os projetos de especialidades se sucedem, esse é o modelo mais coerente; uma vez que a concepção do edifício foi realizada pelo arquiteto de forma independente dos demais projetistas, cabe a ele fazer respeitar e garantir as decisões iniciais, impedindo que as intenções projetuais e a fidelidade aos requisitos de programa se percam ao longo das contribuições dos projetos de especialidades. (FABRÍCIO, 2008, p.41)

Figura 13: Modelo de interação em equipes com o arquiteto, autor do projeto, como coordenador

Fonte: Adaptado de Fabrício (2008)

Em projetos desenvolvidos a partir de modelos colaborativos, o arquiteto participa das demais especialidades envolvidas, da concepção ao produto final, podendo assumir também o papel de coordenador. Ou outro modelo, no qual outro profissional assume o papel da coordenação, criando uma sistematização especializada a partir da troca de informações e da interação entre os profissionais, tendo como foco o gerenciamento do projeto. Comumente esta função é assumida por um segundo arquiteto. Este modelo costuma ser adotado para projetos de grande porte e que envolvem a coordenação de diversas especialidades. Uma das peculiaridades que envolvem este sistema decorre do fato de se proporcionar a imparcialidade das definições da gestão do produto em relação às decisões do projeto de arquitetura. Uma vez que as evidências empíricas sugerem que, quando as soluções tecnológicas se tornam mais complexas e mais profissionais especializados são envolvidos no projeto, é necessária uma coordenação mais efetiva e especializada. Nesses casos, ganha importância o emprego de técnicas de planejamento, maior atenção às atividades de gestão e uso de ferramentas auxiliares especializadas, tais como extranets de projeto, check list de verificação de interferências, etc., que podem demandar uma dedicação incompatível com o trabalho de projeto de arquitetura. Para tais situações, pode ser vantajosa uma coordenação independente, voltada às atividades de gestão e uma mediação mais equilibrada e isenta na resolução das interfaces dos projetos. De qualquer maneira, quanto ao fluxo de informações, cabe ao coordenador fomentar as interações, bem como planejar, registrar e gerenciar as trocas de projeto. (FABRÍCIO, 2008, p. 41) Figura 14: Modelo de interação em equipes com coordenador independente

Fonte: Adaptado de Fabrício (2008)

2.1.6 Mudanças

Quando pensamos em projetos de arquitetura estamos pensando em mudança, uma vez que ela é promovida nos espaços construídos e em sua área de influência, modificando não apenas a materialidade dos espaços, como também os aspectos econômicos, sociais, políticos, psicológicos e fisiológicos, que refletem individual ou coletivamente na vida dos envolvidos, conforme as premissas citadas na Carta de Atenas. Segundo Kurt Lewin (apud LOPES, 2015, p. 8-9) ―a mudança é um processo que necessita primeiramente de uma desconstrução da situação existente para uma posterior construção de algo novo‖. Nos projetos as modificações podem ocorrer genericamente de duas maneiras: Por modificações internas ao mesmo, cujas alterações são devidas a requisitos e restrições da integração dos demais delineamentos que compõem o projeto arquitetônico, ou por solicitações de mudanças no programa do empreendimento pleiteadas pelo cliente. Deste modo, As modificações, por sua vez, podem ser de dois tipos: modificações do projeto ou modificações do programa do empreendimento, essas últimas obrigatoriamente resultando de uma alteração dos dados de entrada anteriormente definidos, a qual deve ser devidamente aprovada pelo empreendedor. (MELHADO, 1999, p. 04)

2.1.7 O Processo Criativo

A capacidade de adaptação e flexibilidade através de soluções ágeis e velozes são características das organizações competitivas nos dias de hoje. Segundo Yoshimura e Kondo [1995, p.1740] (apud Silva, et al.,1998, p.1), “companhias de classe mundial esperam ter 40 a 70% de sua receita gerada por produtos que foram desenvolvidos e lançados dentro dos últimos três anos”, o que requer uma busca constante pelo melhoramento e desenvolvimento de novos produtos e formas de gerenciamento. Neste cenário, surge a Engenharia Simultânea definida Hartley (1998, p.42) como: ―a combinação do enfoque de equipe multidisciplinar para a gestão de projeto,

com um certo número de técnicas especializadas que asseguram a otimização do projeto – de um ponto de vista global, não somente funcional‖. Examinando o processo de desenvolvimento de produtos em algumas empresas japonesas e americanas notadamente reconhecidas como a Honda, a 3M, a Epson, a Cânon e a HP através de entrevistas com a alta administração e com a engenharia de desenvolvimento, Takeuchi e Nonaka (1986) apud Silva, et al. (1998), identificaram em todas, seis pontos comuns no modo de desenvolver e administrar novos produtos: 1. embutir instabilidade: a Alta Administração cria tensão dentro do grupo de desenvolvimento estabelecendo metas abrangentes e desafiadoras; 2. times de projeto autônomos: os times de projeto assumem suas iniciativas e seus riscos, delegam tarefas e não esperam, na maioria dos casos, autorização da Alta Administração. O time apresenta os atributos:  autonomia: a organização provê os recursos, capital e apoio para o projeto, mas o grupo tem seu próprio programa de trabalho. A organização torna-se mais ou menos capitalista e requer do grupo informações sobre o progresso e raramente intervém;  modelos Mentais Transcendentes: para atender as metas desafiadoras da Alta Administração, o time propõe idéias novas e inovadoras que vão contra os estados atuais e levam a grandes descobertas;  fertilização Cruzada: o time de projeto consiste em um grupo especialmente selecionado, com várias especialidades funcionais variando e personalidades. A fertilização cruzada acontece quando o grupo interage e torna-se uma unidade, ou seja, deixam de ser apenas um grupo de indivíduos com diferentes programas de trabalho. 3. sobreposição de fases do desenvolvimento: fases do desenvolvimento são realizadas simultaneamente; 4. aprendizado múltiplo: surge como resultado do ambiente multifuncional. Trata-se de um processo de evolução, onde a cada etapa busca-se o de consenso, antecipação de enganos e a solução de pontos problemáticos. Como resultado, temos a aprendizagem em grupo, que adquire habilidades e conhecimentos abrangentes. Ocorre também a aprendizagem individual de vários modos: desenvolvendo alternativas individuais, buscando alternativas em outros grupos ou até mesmo interagindo com especialistas; 5. controle sutil: embora os grupos de projeto são largamente autônomos, a Alta Administração estabelece controles sutis para prevenir a instabilidade e o caos. Alguns dos métodos usados são: selecionar pessoas para os times, monitorar as dinâmica de grupo, estabelecer um sistema de recompensa baseado no desempenho do grupo, tolerar e se antecipar aos enganos, encorajar o grupo para se auto organizar, encorajar o grupo para falar com os clientes e descobrir o que eles têm que dizer; 6. transferência de aprendizagem para a organização: as pessoas que participam dos times levam para seus grupos de origem o conhecimento desenvolvido. Porém este não é o único aspecto de aprendizagem. Existe a vontade dos elementos do time em transferir seu conhecimento para fora do seu grupo de origem, para novos projetos ou para outras divisões. Firmas japonesas utilizam bastante esta técnica. Uma vez um projeto é completado, a Honda despacha os elementos interinos do grupo de projeto para outros projetos-chave dentro da organização. Adicionalmente, também é transferido conhecimento dentro da organização institucionalizando

práticas prósperas aprendidas em um projeto particular. (SILVA et al, 1998, p. 02)

Essa nova empresa é descrita por Nolan e Croson (1996, p. 33) como aquela que se organiza ―em torno de seus processos e centrará seus esforços em seus clientes. Ela será ágil e enxuta, seus “jobs” exigirão conhecimento do negócio, autonomia, responsabilidade, habilidade na tomada de decisões e um forte caráter inovador alimentado pelo estímulo à criatividade‖. É, pois, a liberação de criatividade e capacidade de gestão intelectual dentro das grandes corporações que Morup (1992) considera como um dos grandes desafios das lideranças do século XXI.

2.1.8 Métodos criativos

O projeto arquitetônico é muitas vezes idealizado inicialmente pelos clientes como um projeto apenas de concepção plástica e artística. No entanto, assim como qualquer outro projeto, ele deve atender às necessidades e expectativas dos clientes e ser desenvolvido baseado em premissas, requisitos e restrições, buscando-se o melhor resultado. Porém como dizia frequentemente Thomas Edison, um dos grandes inventores de todos os tempos ―o projeto é feito com 1% de inspiração e 99% de transpiração‖; assim, podemos entender que a criatividade no processo do projeto de arquitetura é importante, mas é desenvolvida sobre o trabalho que orienta uma série de decisões tomadas em função das potencialidades do projeto e suas premissas, requisitos e restrições. Neste contexto, surgem os métodos criativos que orientam e instigam a produção desta criatividade. Segundo Salama (1995, p. 7) apud Lopes (2015): O mito do insight do gênio criador, que não permite amarras e que foi cultivado durante anos por diversos profissionais, transmite a idéia de que seu trabalho é algo que não tem origem lógica. A criatividade é considerada por muitos ―uma bênção‖ a que apenas alguns escolhidos têm direito, restrita apenas a artistas e inventores e incapaz de ser analisada e provocada. O entendimento sobre criatividade tem mudado ao longo dos anos e ―pode ser definida como uma qualidade interativa que representa a conversa entre as influências externas e sua percepção interna e um diálogo entre a pessoa e o ambiente‖. (LOPES, 2015, p. 47)

2.1.9 O Ciclo de vida do Projeto de Arquitetura

Quanto ao ciclo de vida dos projetos de arquitetura devemos entendê-los como iterativos e incrementais, e adaptativos. Não nos esquecendo do seu caráter complexo, multidisciplinar e criativo. O projeto, assim como qualquer outro, inicia-se para atender a uma necessidade, e inicia o seu desenvolvimento seguindo o conceito da elaboração progressiva, no qual a cada fase seguinte o projeto aumenta o seu nível de informações e conhecimentos sobre o produto e ou serviço planejado. Durante o desenvolvimento destas etapas a liberdade de decisões vai sendo substituída pelo amadurecimento e desenvolvimento das soluções adotadas (MELHADO, 1994).

Figura 15: Impacto da variável com base no tempo decorrido do projeto

Fonte: (PMI, 2013)

De acordo com Melhado (1997), as normas técnicas em vigor, bem como os textos institucionais que tratam do assunto, consideram o projeto de arquitetura como o responsável pelas indicações a serem seguidas pelos projetos de estruturas e instalações, uma vez que,

No processo de projeto convencionalmente utilizado no setor é comum que uma etapa de projeto de determinada especialidade dependa, para ser iniciada, do término de uma etapa de diferente especialidade, cujo grau de aprofundamento e maturação das decisões é equivalente ao da etapa (da outra especialidade) que se inicia. Por exemplo, a etapa de anteprojeto de estruturas e fundações tem como pré-requisito a etapa de anteprojeto de arquitetura. (FABRÍCIO et al, 1998, p.02)

Desta forma, os projetos arquitetônicos são desenvolvidos em fases sequenciais que se repetem intencionalmente (ciclo de vida iterativos e incrementais) onde, ao final de cada fase, são feitas considerações e análises sobre o produto ainda abstrato, sobre o qual a visão macro começa a se concretizar à medida que o desenvolvimento das etapas do projeto avança em suas definições e detalhamento. Servindo de marco para o início da próxima fase. A definição do Ciclo de vida de projetos interativos e incrementais, segundo o PMI (2013) é: Ciclos de vida interativos e incrementais são aqueles em que as fases do projeto (também chamadas de iterações) intencionalmente repetem uma ou mais atividades de projeto à medida que a compreensão do produto pela equipe do projeto aumenta. Iterações desenvolvem o produto através de uma série de ciclos repetidos, enquanto os incrementos sucessivamente acrescentam à funcionalidade do produto. Os ciclos de vida desenvolvem o produto de forma tanto iterativa como incremental. Os projetos iterativos e incrementais podem avançar em fases, e as iterações propriamente ditas são executadas de maneira sequencial ou sobreposicional. Durante uma iteração, as atividades de todos os grupos de processos de gerenciamento de projeto serão executadas. No final de cada iteração, uma entrega ou conjunto de entregas será concluído. As iterações futuras podem aprimorar tais entregas ou criar novas entregas. Cada iteração desenvolve de forma incremental as entregas até que os critérios de saída da fase sejam cumpridos, permitindo que a equipe do projeto incorpore o feedback. Na maioria dos ciclos de vida iterativos, uma visão de alto nível é desenvolvida para o empreendimento em geral, mas o escopo detalhado é elaborado uma iteração de cada vez. Frequentemente, o planejamento para a nova iteração é feito à medida que o trabalho no escopo e entregas da iteração atual avança. O trabalho exigido para um determinado conjunto de entregas pode variar em duração e esforço, e a equipe do projeto pode mudar entre ou durante as iterações. As entregas não abordadas no escopo da iteração atual são normalmente abrangidas em um nível mais alto somente e podem ser provisoriamente designadas para uma iteração futura específica. As mudanças no escopo da iteração são cuidadosamente gerenciadas assim que o trabalho se inicia. Os ciclos de vida iterativos e incrementais são geralmente preferidos quando uma organização necessita administrar as mudanças dos objetivos e escopo, reduzir a complexidade de um projeto ou quando a entrega parcial de um produto é benéfica e proporciona valor para um ou mais grupos de partes interessadas sem causar impacto na entrega ou conjunto de entregas final. Projetos grandes e complexos são muitas vezes executados de maneira iterativa para reduzir o risco ao permitir que a equipe incorpore o feedback e as lições aprendidas entre as iterações. (PMI, 2013, p. 45-46).

Além disso, os projetos de arquitetura devem estar também sempre suscetíveis a mudanças, tendo em vista que durante o desenvolvimento do projeto podem surgir modificações solicitadas pelo cliente; uma vez que este, por conta de uma melhor compreensão do projeto, favorecida pela representação do mesmo, pode requerer alterações que atendam às necessidades técnicas dos projetos complementares envolvidos, ou ainda para atender a fatores externos, ligados à legislação, regulamentações, ou outros entraves. Conforme o PMI (2013), a definição do ciclo de vida adaptativo (também conhecidos como direcionados à mudança ou utilizadores de métodos ágeis) são projetados para reagir a altos níveis de mudança e envolvimento contínuo das partes interessadas. Os métodos adaptativos são também iterativos e incrementais, a diferença é que as iterações são muito rápidas (geralmente com uma duração de 2 a 4 semanas), com tempo e recursos fixos. Os projetos adaptativos geralmente executam vários processos em cada iteração, embora as primeiras iterações possam se concentrar mais nas atividades de planejamento. O escopo geral do projeto pode ser desmembrado em um conjunto de requisitos e trabalhos a serem executados, comumente chamado de backlog do projeto. No início de uma iteração, a equipe trabalhará para determinar a quantidade de itens altamente prioritários da lista de backlog que podem ser entregues na próxima iteração. No final de cada iteração, o produto deve estar pronto para a análise pelo cliente. Isso não significa que o cliente deve aceitar a entrega, mas simplesmente que o produto não deve incluir características inacabadas, incompletas, ou que não podem ser usadas. Os representantes do patrocinador e do cliente devem estar continuamente envolvidos no projeto para fornecer o feedback sobre as entregas à medida que elas são criadas, a fim de garantir que o backlog do produto reflitam suas necessidades atuais. Os métodos adaptativos geralmente são preferidos quando se lida com um ambiente em rápida mutação, quando os requisitos e escopo são difíceis de definir antecipadamente, e quando é possível definir pequenas melhorias incrementais que entregarão valor às partes interessadas. (PMI, 2013, p. 46).

2.1.10 O Processo do Projeto arquitetônico

De acordo com Maciel (1997) apud Fabrício et al (1998, p.2), na indústria da construção, voltada para edifícios multifamiliares, corporativos e comerciais, “a atuação do projetista de arquitetura ocorre previamente e sem a interação com os demais projetistas”, deixando clara a separação entre a fase de concepção do

produto e o desenvolvimento do projeto. Acerca dos procedimentos que são estabelecidos para imóveis de grande porte, Fabrício et al (1998) descrevem que O projeto de arquitetura é desenvolvido a partir da pesquisa de mercado e aquisição do terreno e depois, é aprovado nos órgãos competentes, para obtenção de recursos financeiros e lançamento do empreendimento no mercado. Somente após a etapa de lançamento, é feita a contratação dos demais projetistas que irão participar do desenvolvimento do projeto. Desta forma, a atuação dos diversos projetistas envolvidos no processo não ocorre de maneira conjunta e o projeto é elaborado sem a efetiva contribuição de todos os participantes ao longo das diferentes etapas do processo de projeto. (FABRICIO et al, 1998, p.02)

Assim, podemos entender como acontece a relação entre a participação dos agentes

envolvidos

concepção,

durante

processo

sequencial

desenvolvimento do projeto de edifícios. Na figura 16, Fabrício (2001) representa nos eixos verticais, as especialidades envolvidas com o projeto de edifícios e no eixo horizontal, o seu nível de atuação durante as etapas de desenvolvimento do projeto. Para o autor, O processo sequencial em uso possibilita que apenas o projetista de arquitetura tenha contato direto com a programação do empreendimento. Os demais projetistas partem do projeto ou anteprojeto de arquitetura e das soluções adotadas nessa disciplina para desenvolver soluções técnicas que ―complementem‖ o projeto de arquitetura. (FABRÍCIO, 2008, p. 34) Figura 16: Esquema genérico de um processo sequencial de desenvolvimento do projeto de edifícios – participação dos agentes ao longo do processo.

Fonte: Fabrício (2001)

Fabrício (2008, p. 34), ao citar o estudo de Lyrio Filho e Nascimento (2004), comenta sobre os riscos que podem ser causados pela falta de comunicação ao longo dos processos de desenvolvimento dos projetos, podendo leva-los a “soluções desvinculadas dos requisitos do empreendimento, gerando retrabalho ou deslocando o empreendimento de seus objetivos iniciais ou do nicho de mercado almejado”.

2.1.11 As Fases do Projeto Arquitetônico Segundo a ABNT – Associação Brasileira de Normas Técnicas, na NBR 13531:1995 (Elaboração de projetos de edificações – Atividades técnicas), estão previstas as seguintes fases de projeto arquitetônico. Levantamento (LV) – Etapa destinada à coleta das informações de referencia que representem as condições preexistentes, de interesse para instruir a elaboração do projeto, podendo incluir dados físicos (planialtimétricos, cadastrais, geológicos, hídricos, ambientais, climáticos, ecológicos e outros), técnicos, legais e júdicos, sociais, econômicos, financeiros e outros. Programa de Necessidades (PN) – Etapa destinada à determinação das exigências de caráter prescritivo ou de desempenho (necessidades e expectativas dos usuários) a serem satisfeitas pela edificação a ser concebida. Estudo Preliminar (EP) - Etapa destinada à concepção e à representação do conjunto de informações técnicas iniciais e aproximadas, necessários à compreensão da edificação, podendo incluir soluções alternativas. Anteprojeto (AP) e/ou pré-execução (PR) - Etapa destinada à concepção e à representação das informações técnicas provisórias de detalhamento da edificação e seus elementos, instalações e componentes, necessárias ao inter-relacionamento das atividades técnicas de projeto e suficientes à elaboração de estimativas aproximadas de custos e de prazos dos serviços de obra implicados. Projeto Legal (PL) - Etapa destinada à representação das informações técnicas necessárias à análise e aprovação, pelas autoridades competentes, da concepção da edificação e seus elementos e instalações com base nas exigências legais (municipal, estadual, federal), e à obtenção do alvará e das licenças e demais documentos indispensáveis para as atividades de construção. Projeto Básico (PB) - Etapa opcional destinada à concepção e à representação das informações técnicas da edificação e seus elementos, instalações e componentes, ainda não completas ou definitivas, mas consideradas compatíveis com os projetos básicos das atividades técnicas necessárias e suficientes à licitação (contratação) dos serviços de obra correspondentes. Projeto para execução (PE) - Etapa destinada à concepção e à representação final das informações técnicas da edificação e seus elementos, instalações e componentes, completas, definitivas, necessárias

e suficientes à licitação (contratação) e à execução dos serviços de obra correspondentes. (ABNT, 1995)

Lopes (2015, p.14), considera a seguinte EAP - Estrutura Analítica do Projeto, representada na figura 6, bem como a distribuição do trabalho no tempo, considerando as fases do Projeto de Arquitetura, conforme consta na figura 17.

Figura 17: Estrutura Analítica do Projeto (EAP), primeiro nível, considerando as fases do projeto de arquitetura.

Fonte: Lopes (2015)

Figura 18: Distribuição do trabalho no tempo considerando as fases do Projeto de Arquitetura

Fonte: Lopes (2015)

2.1.12 As Fases de coordenação de projetos arquitetônicos

De acordo com a AGESC - Associação dos Gestores e Coordenadores de Projeto, em seu Manual de escopo de coordenação de projetos, considera-se que a coordenação de projetos arquitetônicos é desenvolvida em seis etapas, a saber:

Fase A – Concepção do produto – apoiar o empreendedor nas atividades relativas ao levantamento e definição do conjunto de dados e de informações que objetivam conceituar e caracterizar perfeitamente o partido do produto imobiliário e as restrições que o regem, e definir as características demandadas para os profissionais de projeto a contratar; Fase B – Definição do produto – coordenar as atividades necessárias à consolidação do partido do produto imobiliário e dos demais elementos do empreendimento, definindo todas as informações necessárias à verificação de sua viabilidade técnica, física e econômico-financeira, assim como à elaboração dos projetos legais; Fase C – Identificação e solução de interfaces – coordenar a conceituação e caracterização claras de todos os elementos do projeto do empreendimento, com as definições de projeto necessárias a todos os agentes nele envolvidos, resultando em um projeto com soluções para as interferências entre sistemas e todas as suas interfaces resolvidas, de modo a subsidiar a análise de métodos construtivos e a estimativa de custos e prazos de execução; Fase D – Detalhamento das especialidades – coordenar o desenvolvimento do detalhamento de todos os elementos de projeto do empreendimento, de modo a gerar um conjunto de documentos suficientes para perfeita caracterização das obras e serviços a serem executados, possibilitando a avaliação dos custos, métodos construtivos e prazos de execução; Fase E – Pós-entrega do projeto – garantir a plena compreensão e utilização das informações de projeto e a sua correta aplicação, e avaliar o desempenho do projeto em execução; Fase F – Pós-entrega da obra – coordenar o processo de avaliação e retroalimentação do processo de projeto, envolvendo os diversos agentes do empreendimento e gerando ações para melhoria em todos os níveis e atividades envolvidos. (AGESC, 2006, p. 9)

Segundo o Centro de Tecnologia de Edificações – CTE (1998) (apud Fabricio et al 1998) em sua análise sobre Programa de Gestão da Qualidade no Desenvolvimento de Projeto na Construção Civil, coordenado pelo Centro de Tecnologia de Edificações – CTE, no qual participaram 06 empresas de projeto de arquitetura, 04 empresas de projeto estrutural, 02 empresas de projeto de sistemas prediais e 10 empresas construtoras e incorporadoras, totalizando 22 empresas, foram identificados os principais aspectos que afetam a qualidade, no decorrer do fluxo de atividades ao longo do processo de projeto do edifício. Tais aspectos estão relacionados com as etapas de caracterização e concepção do produto a ser desenvolvido,

desenvolvimento

mesmo,

entrega

projeto

acompanhamento da execução e avaliação da satisfação dos clientes finais quanto ao projeto. Conforme ilustrado na figura 19, a escolha do projeto deve estar alinhada com o planejamento estratégico, assim como todas as etapas seguintes.

Figura 19: Fluxo geral de etapas do desenvolvimento de projeto

Fonte: Fabrício et al (1998) adaptado de (CTE, 1998)

De acordo com o modelo proposto, na etapa I o projeto trata do planejamento de empreendimentos, constando a viabilidade de um produto definido a partir das necessidades de mercado. A etapa II consiste na concepção do produto, e define o produto em relação a: ambientes, processos construtivos, formas e geometria. Já a etapa III contém as fases do projeto arquitetônico e o desenvolvimento do produto, que é subdividido em cinco estágios de desenvolvimento: anteprojeto, projeto legal, projeto pré-executivo, projeto executivo e projeto para produção. Sendo o projeto para produção geralmente desenvolvido pela empresa responsável pela obra ou pelo arquiteto autor do projeto, como uma fase de acompanhamento à obra. A etapa IV consiste na documentação do projeto conforme o mesmo foi executado, o projeto ―As built‖. Por fim, é na etapa VI que é feita uma análise do uso e desempenho do edifício e da satisfação do cliente final. Acerca de tais estágios Observa-se, ainda, que a atividade de entrega do projeto ocorre ao longo das etapas III e IV, e que a atividade de acompanhamento técnico da

execução da obra inicia-se a partir da conclusão do projeto executivo até a elaboração do projeto ―as built‖. Atualmente, esse fluxo de atividades de desenvolvimento técnico do projeto está em discussão, pois ainda há divergências entre as empresas de arquitetura, de projeto de engenharia e construtoras e incorporadoras quanto à nomenclatura das etapas e o escopo de cada uma delas, principalmente durante a etapa III de desenvolvimento do produto. Mesmo sendo este um modelo evoluído em relação ao processo de projeto tradicional no setor, ele ainda guarda características de desenvolvimento sequencial de produtos, que limita as possibilidades de interações entre os projetistas, uma vez que muito da liberdade para propor soluções alternativas em determinada especialidade de projeto fica restringida por soluções e um grau de detalhamento já atingido em outra especialidade. (FABRICIO, 1998, p. 5-6)

2.2

Projeto Simultâneo

2.2.1 Possibilidades para o projeto simultâneo

Atualmente, devido à demanda do desenvolvimento de projetos arquitetônicos com maior velocidade, muitos empreendimentos iniciam a sua construção a partir da fase de anteprojeto, aumentando os riscos de que decisões de projeto importantes, durante a execução da obra, podendo gerar modificações de escopo, influências quanto ao tempo de execução, aos custos e à qualidade, assim como nos recursos humanos e aquisições. Como em outros projetos, quanto mais rápidas e assertivas forem as decisões com relação ao produto, os custos relacionados a tais mudanças serão reduzidos. Portanto, promover um desenvolvimento de modo que se garanta uma maior integração e o entendimento de todos os envolvidos, visando o atendimento das necessidades projetuais, alcançarão, como fim a assertividade de propósitos. O conceito de projeto simultâneo, de acordo com as propostas de Melhado, a partir deste cenário diz que: Nesse contexto de mudanças, a colaboração entre os agentes principais que geram os empreendimentos mostra-se como alternativa válida, inspirando-se em modelos adotados pela indústria seriada, como o projeto simultâneo (concurrent engineering). (MELHADO, 1999, p.01)

Segundo este conceito, a integração das partes envolvidas com o projeto é fundamental para o desenvolvimento de um plano que considere todas as suas interferências, podendo assim garantir a qualidade.

No modelo tradicional, a interação entre os profissionais ocorre segundo uma abordagem cartesiana em que cada profissional se sucede no processo de projeto, acrescentando sua contribuição particular ao todo. Por outro lado, novos paradigmas de colaboração e informação colocam como referência uma abordagem mais multidisciplinar e participativa, na qual a concepção de artefatos surge de complexas interações entre equipes de especialidades que se entrelaçam em redes criativas. (FABRICIO, 2008, p. 31)

Jouini (1999), ao ser citado por Melhado (1999, p. 5), considera três focos importantes para a utilização do conceito de projeto simultâneo e o incentivo a colaboração entre as partes envolvidas: O primeiro foco trata da colaboração do arquiteto e dos engenheiros, bem como de outros especialistas envolvidos com o cliente ou incorporadora, desde o início da concepção do produto. O segundo foco trata da colaboração voltada para trocas de informações constantes entre todos os projetistas envolvidos no desenvolvimento do projeto arquitetônico. E o terceiro foco, trata da Colaboração Projeto-Produção, realizados no Brasil em projetos chamados projetos para produção, como o projeto das fôrmas de concreto ou da alvenaria, normalmente feitos em uma etapa de acompanhamento à obra. Conforme pode-se observar na representação da figura 20:

Figura 20: As três áreas ou “zonas” de aplicação da engenharia simultânea dentro do processo de produção do empreendimento

1 – ―foco‖ de colaboração simultânea entre o promotor e a equipe de projeto 2 – ―foco‖ de colaboração simultânea transversal à equipe de projeto (projeto simultâneo) 3 – ―foco‖ de colaboração entre a concepção do produto e a concepção tecnológica da produção Fonte: MELHADO (1999) adaptada de Jouini (1999)

Para Melhado (1999), podemos entender a atividade do projeto de edifícios como uma atividade fragmentada, na qual a integração dos projetos pode colaborar para a qualidade do processo. A partir de uma pesquisa realizada na França, por Alluin (1998), acerca das profissões ligadas ao projeto arquitetônico, fica evidente a ruptura entre as atividades de projeto e as de execução das obras. Neste trabalho, o pesquisador mostra os impactos deste distanciamento, ocasionando a falta de uma visão sistêmica e integrada da construção pelas equipes de projeto, o que causará conflitos que só serão identificados ao longo do andamento da obra. Uma vez que “Alluin ainda defende que o desenvolvimento da capacidade de qualquer participante do empreendimento de antecipar a cada etapa e os parâmetros que deverão ser integrados à etapa seguinte poderia ser extremamente auxiliado por uma maior experiência de execução da obra”. (MELHADO, 1999).

2.2.2 Proposta para o desenvolvimento simultâneo de projetos

Da necessidade de se promover a integração entre todas as especialidades envolvidas no projeto, obra, clientes ou incorporadoras, surge a necessidade de aplicação de um Projeto Simultâneo. (FABRÍCIO; BAÍA; MELHADO; 1998), sugerem o Projeto Simultâneo. Segundo os autores, O desenvolvimento do edifício de forma simultânea e integrada, estabelecendo uma sequência de atividades de projetos distintos e complementares, que possam ser resolvidos paralelamente, considerando possíveis interferências entre eles, é sugerido no conceito de Projeto Simultâneo. (FABRÍCIO; BAÍA; MELHADO, 1998)

Para isso, (FABRÍCIO; BAÍA; MELHADO; 1998), analisam o modelo tradicional de projetos, “(...) para viabilizar o início de determinada parte (ou atividade) de projeto é necessário que um bloco de informações pré-requisito estejam disponíveis, envolvendo conteúdos desenvolvidos anteriormente na mesma ou em diferente especialidade do projeto”. E para a utilização deste conceito, é conveniente a divisão do projeto em etapas, e que cada etapa seja subdividida em projetos referentes ao pacote de trabalho de cada especialidade que participa do projeto. O projeto deve incentivar o

aumento continuo e ordenado do nível de amadurecimento de todas as especialidades ao mesmo tempo, e o aumento do seu grau de detalhamento. Devido às constantes interferências que um projeto pode trazer aos outros, reduzindo o retrabalho, e aumentando a assertividade do projeto. Neste conceito, (FABRÍCIO; BAÍA; MELHADO; 1998), propõem as etapas representadas na figura abaixo, onde se pode ver o papel da coordenação da arquitetura atuando de forma paralela e interativa – dividindo o projeto em 4 etapas de amadurecimento: informações iniciais, ―briefing‖ – concepção, desenvolvimento e detalhamento. Conforme ilustrado na Figura 21.

Figura 21: Proposta para a sequência do projeto (fases II e III) privilegiando o paralelismo e a interatividade entre as etapas do projeto.

Fonte: Fabrício et al (1998) adaptado de (CTE, 1998)

De acordo com esta proposta, Com algumas atividades ou operações já terminadas em determinada especialidade de projeto é possível desencadear o desenvolvimento de atividades referentes a outra especialidade com estágio de detalhamento similar, ampliando sensivelmente a interatividade entre os projetistas que podem coordenar as soluções ao invés de não discutir a compatibilização entre projetos já desenvolvidos e praticamente fechados, quando a proposição de alterações substanciais significaria um grande retrabalho e uma volta a estágios de projetos já vencidos. Desta forma, as tentativas de compatibilizar especialidades de projetos em etapas acabadas dão lugar ao desenvolvimento coordenado entre as várias especialidades de projeto. (FABRÍCIO; BAÍA; MELHADO; 1998, p. 6)

Nesta matriz apresentada por podemos identificar no eixo horizontal, as especialidades de projeto envolvidas, e no eixo vertical, os estágios de maturação e desenvolvimento do projeto. Sobre os estágios e atividades, os autores descrevem: No primeiro estágio, está contida a etapa de levantamento e apresentação de informações básicas sobre as características do terreno e de sua ocupação que fica sob responsabilidade da incorporadora. No segundo estágio, estão agrupadas as atividades de geração do programa de necessidades a ser atendido no desenvolvimento do produto e o estudo preliminar de arquitetura que vão desenvolver o conceito do produto e já devem considerar informações e as experiências de outras especialidades de projeto e do pessoal da produção, de forma a coordenar conceitualmente as visões do incorporador e do arquiteto com a dos demais especialistas e analisar as repercussões das alternativas consideradas nos estudos preliminares em relação às possibilidades tecnológicas e construtivas. O terceiro estágio é composto pelo desenvolvimento interativo dos diversos anteprojetos de forma a coordenar as soluções de diferentes especialidades de projeto visando amarrar as decisões de especialidades e otimizar globalmente o projeto. Por fim, no quarto estágio, são detalhadas as soluções das especialidades de projeto do produto que subsidiam a definição final dos projetos para produção dos subsistemas críticos de obra. (FABRÍCIO; BAÍA; MELHADO; 1998, p. 6)

2.2.3 Dificuldades na implantação do projeto simultâneo

No entanto através de estudos realizados por BAÍA (1998) e citados por FABRÍCIO; BAÍA; MELHADO (1998), em algumas empresas, foi possível constatar algumas dificuldades a implantação do fluxo do processo de projeto proposto:

 baixo grau de compromisso dos profissionais e empresas de arquitetura com a estratégia e metas dos contratantes (custos, prazos, atendimento ao usuário final); situação agravada devido à falta de estratégia de produto por parte dos contratantes;  ausência de metodologias adequadas para levantamento das necessidades dos clientes, tanto o investidor como o usuário final;  excesso de retrabalho no processo de desenvolvimento do projeto, em função de alterações por parte do contratante e da falta de integração entre os diversos agentes participantes;  o controle de qualidade durante o processo de projeto é incipiente; sendo ainda necessário o desenvolvimento de procedimentos de controle eficazes, de fácil utilização que sirvam de base para tomadas de decisões nos projetos futuros e em andamento;  não existe uma troca sistemática de informações entre o escritório de projeto e a obra, não promovendo assim a aplicação dos princípios de racionalização e construtibilidade desde a etapa inicial do processo de projeto;  ausência de coordenação do processo de projeto do edifício, ou seja, não há um trabalho conjunto entre a construtora, os demais projetistas e o escritório de arquitetura durante o processo de projeto do edifício.‖ Todos os fatores acima citados, com relação ao processo de projeto do edifício, contribuem para uma falta da qualidade do projeto como um todo, pois esse é desenvolvido sem uma visão sistêmica, na qual todas as necessidades e exigências dos diversos clientes do processo deveriam ser consideradas. (FABRÍCIO; BAÍA; MELHADO, 1998, s.n)

Estes fatores podem ser corrigidos, se agregarmos ao conceito de projeto simultâneo a utilizações de novas ferramentas, como a tecnologia BIM, e a utilização de metodologias de gerenciamento ágil como o Scrum, buscando o desenvolvimento de equipes multidisciplinares e auto-organizáveis.

2.3

A qualidade nos Projetos

2.3.1 Kaizen e PDCA

Segundo IMAI (1994), podemos entender a essência da filosofia kaizen da seguinte forma: por ter um caráter de contínuo melhoramento, que envolve a todos, quaisquer que sejam os papéis ocupados, indo desde o operário ao gerente, tendo em mente que este indivíduo deve sempre prezar por viver em um contexto cuja situação seja a mais favorável possível. Assim, o sujeito deve buscar meios contínuos de otimizar a conjuntura na qual se insere. Para que tal conceito seja complementado, deve-se entendê-lo como um sistema que realiza pequenas mudanças que se refletem em outras etapas do processo, ou seja,

O melhoramento contínuo não se preocupa com a promoção dos pequenos melhoramentos. Ele vê os pequenos melhoramentos, todavia, como tendo uma vantagem significativa sobre os grandes: eles podem ser seguidos de forma relativamente indolor por outros pequenos melhoramentos. (SLACK et al, 2008, p. 602)

Para o desenvolvimento da filosofia kaizen, consideramos dois processos contínuos, a definição de padrões para o desenvolvimento de mudanças para a melhoria e a inovação. Tais mudanças refletem-se, conforme salienta IMAI (1994) no ―status quo‖, trazendo sensíveis melhorias a partir de esforços contínuos, bem como alterações drásticas via investimentos em tecnologia e/ou maquinário. O que reforça a diferença entre os empreendimentos no ocidente e oriente, conforme salientam Ferreira e Monteiro: Estes dois enfoques diferenciam as empresas ocidentais das orientais; as organizações ocidentais prezam mais pela inovação que os avanços tecnológicos ou novas técnicas e conceitos trazem; já as orientais, com o kaizen, preocupam-se com as pequenas e sutis mudanças trazidas por esta filosofia, com suas técnicas simples e convencionais, mas que geram grandes benefícios em longo prazo, se usarem desta ferramenta correta e continuamente. (FERREIRA e MONTEIRO, 2008, p. 30)

Segundo o PMI (2013), esta implementação da melhoria continua se dá através do ciclo PDCA (planejar-fazer-verificar-agir) sobre o qual se baseia o aumento da qualidade, segundo Shewhart e Deming. Algumas iniciativas visam a criação de uma cultura de excelência organizacional através da implementação de programas como o Gerenciamento da qualidade total (GQT), o Seis sigma e o Lean seis sigma, nos quais as transações são bem-sucedidas, com o máximo desempenho e eficiente relacionamento interpessoal, tornando o gerenciamento do projeto e do produto do projeto elementos de qualidade aperfeiçoada. Cujos modelos de melhoria de processos incorporam o Malcolm Baldrige, o Modelo de maturidade organizacional em gerenciamento de projetos (OPM3®) e o Modelo integrado de maturidade e de capacidade (CMMI®)

2.3.2 As origens do padrão internacional ISO 9000.

Segundo o site BSI Education, os primeiros padrões de controle de qualidade surgiram a partir da necessidade do governo Inglês de controlar os problemas que

havia enfrentando, relacionados à produção de munições, geração de energia e novas tecnologias. Dessa forma, o governo do Inglês desenvolve um padrão, o BSD British Standart 5750, que exigia que os fornecedores, especificassem como era o seu processo de trabalho por escrito e apresentassem tais informações para a aprovação de um inspetor. A aprovação estava focada no processo, ou seja, na gestão e não era uma norma do produto. Na década de 80, com o crescimento da globalização, percebe-se a necessidade da criação de um padrão internacional para o controle de qualidade. E por já possuir este embrião, o governo do Inglês apresenta à International Organization

for

Standardization

–

ISO

(Organização

Internacional

para

Padronização), o padrão BSD British Standart 5750, que se tornaria a primeira norma ISO 9000.

2.3.3 Os princípios da Gestão da Qualidade.

Segundo a ISO - International Organization for Standardization define em sua publicação ―ISO quality – Quality management principies‖, os sete princípios da gestão da qualidade são: QMP 1 - Foco no cliente Conceito - O foco principal da gestão da qualidade é atender as necessidades, e se esforçar para exceder as expectativas dos clientes Raciocínio - A Sustentabilidade do sucesso é atingida quando é possível atrair e reter a confiança sobre a sua organização, com clientes e outras partes interessadas. Principais Benefícios • Reconhecer como clientes diretos e indiretos aqueles que recebem os valor da organização; • Entender as necessidades e expectativas, atuais e futuras dos clientes. • Vincular os objetivos da organização com as necessidades e expectativas do cliente. • Comunicar às necessidades e expectativas dos clientes toda a organização. • Planejar, projetar, desenvolver, produzir, divulgar e produtos e serviços para atender ao cliente em suas necessidades e expectativas. • Medir e monitorar a satisfação do cliente, e promover as mudanças necessárias em cima deste retorno. • Determine e tomar ações sobre interessado necessidades e expectativas que podem afetar partes satisfação do cliente. • Gerenciar ativamente os relacionamentos com clientes para alcançar a sustentabilidade do sucesso. QMP 2 – Liderança

Conceito – Lideres em todos os níveis para estabelecer uma unidade de propósito e direção criando condições em que as pessoas estejam envolvidas em alcançar os objetivos do Plano de Qualidade da organização Raciocínio – Criação de unidade de propósito e direção e o engajamento das partes interessadas, permitindo o alinhamento das estratégias, politicas, processos, recursos e objetivos. Principais Benefícios • Aumento da eficácia e eficiência no cumprimento da qualidade da organização objetivos; • Melhor coordenação de processos da organização; • Melhor comunicação entre níveis e funções da organização; • Desenvolvimento e melhoria da capacidade da organização e seu povo para entregar resultados desejados; QMP 3 - Contratação de pessoas Conceito – Pessoas competentes, habilitadas e comprometidas, em todos os níveis em toda a organização são essenciais para melhorar é capacidade de criar e entregar valor. Raciocínio – Para gerenciar uma organização eficaz e eficiente, é importante envolver a todas as pessoas em todos os níveis e de respeitá-los como indivíduos. Reconhecer, capacitar e aperfeiçoar suas competências, facilitando a participação das pessoas para alcançar os objetivos de qualidade da organização. Principais Benefícios • Melhoria da compreensão dos objetivos de qualidade da organização por pessoas da organização e aumento da motivação para alcançá-los; • maior envolvimento de pessoas em atividades de melhoria; • Aprimorada desenvolvimento pessoal, iniciativas e criatividade; • Aumento da satisfação das pessoas; • Confiança reforçada e colaboração em toda a organização • Maior atenção aos valores partilhados toda a organização e cultura; QMP 4 - Abordagem de processo Conceito – Resultados consistentes e previsíveis são alcançados de maneira eficaz e eficiente, quando são compreendidas e gerenciadas como processos inter-relacionados que funcionam como um sistema coerente. Raciocínio – O sistema de gestão da qualidade consiste em um conjunto de processos interrelacionados. Compreender como os resultados são produzidos por um sistema complexo, permite propor uma nova organização para otimizar o sistema e seu desempenho. Principais Benefícios • Maior capacidade de concentrar esforços em processos-chave e oportunidades de melhoria; • Resultados consistentes e previsíveis Através de um sistema de processos alinhados; • Desempenho otimizado, e eficaz da gestão de processos, utilização eficiente dos recursos, e redução de barreiras interfuncionais • Habilitação por parte da organização para fornecer confiança às partes interessadas quanto à sua consistência, eficácia e eficiência. QMP 5 - Melhoria Contínua Conceito – As organizações bem sucedidas devem ter foco na melhoria contínua. Raciocínio – A melhoria contínua é essencial para uma organização manter os atuais níveis de desempenho, para reagir às mudanças nos cenários interno e externo, e possibilitar a criação de novas oportunidades. Principais Benefícios • Maior foco nos causa-raiz, investigação e determinação, seguido por prevenção e ações corretivas;

• Maior capacidade de antecipar e reagir à riscos e oportunidades internas e externas; • Melhoria contínua por incremento, seguindo o padrão PDCA - Plan (Planejamento) - Do - (Fazer) - Check - (Verificar) - Act - (Agir) • Utilização das lições aprendidas para a melhoria contínua. • Foco na inovação QMP 6 - Tomada de decisão baseada em evidências Conceito – Decisões com base na análise e avaliação de dados e informações, analisando as possibilidades de ocorrer resultados desejados. Raciocínio – A tomada de decisão trata-se de um processo complexo, que envolve incertezas. Freqüentemente envolve múltiplos fatores, sobre diferentes estratégiase pode ser muito subjetiva. É importante entender as relações de causa e efeito e o potencial impacto. Fatos e análise de dados podem levar a uma maior objetividade e confiança na tomada de decisões. Principais Benefícios • Melhoria dos processos de tomada de decisão; • Melhoria da avaliação dos do desempenho do processo e capacidade de atingir os objetivos; • Melhoria da eficácia operacional e eficiência; • Aumento da capacidade de analisar e revisar decisões, e promover mudanças; • Aumento da capacidade de demonstrar a eficácia das decisões passadas; QMP 7 - Gestão de Relacionamento Conceito – Para a sustentabilidade do sucesso, a organização deve gerenciar as partes interessadas envolvidas no projeto. Raciocínio – Partes interessadas influenciam a performace da organização. Para alcançar a sustentabilidade do sucesso, é importante gerenciar as relações com todas as partes interessadas para otimizar o seu impacto sobre o desempenho. Ter boas relações com fornecedores e parceiros tem especial importância. Principais Benefícios • Atuar com boa comunicação na solução de conflitos. • Melhor comunicação dos objetivos e valores entre as partes interessadas; • Aumento da capacidade de criar valor para as partes interessadas por partilha de recursos e competências e gestão dos riscos relacionados com a qualidade; • Promover um boa cadeia de suprimentos criando um fluxo de bens e serviços estável; Estes princípios não são listadas em ordem de prioridade. A importância relativa de cada princípio irá variar de organização para organização e pode, se esperar que mudam com o tempo. (ISO, 2015)

2.3.4 A qualidade nos Projetos Arquitetônicos

Um projeto bem desenvolvido é fundamental para a garantia da qualidade dos produtos e a eficiência do processo produtivo. Na indústria da construção, o projeto arquitetônico deve ser concebido e desenvolvido em sinergia com os projetos completares, considerando seus impactos durante todo o seu ciclo de vida, planejando soluções e antevendo possíveis conflitos construtivos, detectados através da análise e compatibilização dos projetos complementares. E quanto mais detalhado e desenvolvido, maiores serão os reflexos na redução do risco de conflitos construtivos, detectados através da análise e compatibilização de todos os projetos envolvidos. Como todos os projetos complementares atuam sobre o mesmo produto, são fundamentais a coordenação e a troca de informações entre toda a equipe, a fim de que se possa compartilhar as lições aprendidas e a experiência de todos os envolvidos, obtendo um projeto com maior grau de maturidade. Cabe salientar que, de acordo com Fabrício, Baía e Melhado (1998), o estudo de Cole (1990) citado por Koskela et al (1997) indica que o briefing deficiente é uma das causas cruciais dos problemas dos projetos, bem como as inadequações do conhecimento técnico dos projetistas e a falta de planejamento de projeto. Partindo destes indicadores e levando em consideração as peculiaridades setoriais e da produção de edifícios, busca-se possibilidades que assegurem o processo de projeto, tornando-o mais eficaz no que tange às obras e a qualidade dos edifícios.

2.3.5 Aumento da demanda por qualidade nos Projetos Arquitetônicos

Podemos constatar que a demanda por qualidade também se reflete na indústria da construção e nos projetos arquitetônicos. De acordo com Melhado (1999), podemos constatar um aumento da demanda por qualidade nos projetos arquitetônicos. A cada dia, o movimento da qualidade dentro do setor da construção civil ganha novo folego, com o aumento da conscientização dos clientes e a conseqüente reação dos agentes da cadeia produtiva: um número cada vez maior de fabricantes de materiais e componentes, de empresas

construtoras e de empresas de projeto se interessa pela implementação de sistemas de gestão da qualidade e sua certificação segundo as normas da série ISO 9000. (MELHADO, 1999, p. 2)

2.3.6 Tendência de resposta no aumento da qualidade Esta demanda é atendida pela indústria da construção, propiciando o início de modificações no processo do projeto arquitetônico conforme podemos constatar com a tendência de resposta no aumento da qualidade. Em alguns casos, observa-se hoje uma tendência a ir mais além, ou seja, após a preocupação com a qualidade ―individual‖, voltada aos clientes mas ao mesmo tempo demandante de apoio dos fornecedores, passa-se a enfrentar as questões que cercam a qualidade no desenvolvimento de soluções para cada empreendimento. A construção de edifícios, particularmente, tem sofrido uma mudança acelerada de paradigmas. Começa-se a discutir mais profundamente como garantir a qualidade dos empreendimentos, entidades temporárias de produção que se formam a partir da interação de vários participantes com atuação bastante especializada. O Plano da Qualidade do Empreendimento - PQE, ainda não presente no universo da qualidade da maior parte das empresas, tem sido discutido enquanto tendência reveladora dos próximos desafios a vencer nesse setor. A elaboração de um PQE deve formalizar a colaboração entre todos os agentes do empreendimento para a obtenção dos objetivos formulados, estabelecendo responsabilidades, procedimentos e controles específicos e provendo meios para a sua gestão, de forma a maximizar a qualidade das soluções e seu resultado medido em termos da satisfação dos clientes. Sua introdução pode ainda abrir caminho para a evolução das práticas de projeto e execução, através da aplicação de conceitos como a engenharia simultânea. (MELHADO, 1999, p. 2-3)

2.3.7 O Projeto visto pela Gestão da Qualidade

Ao analisarmos o projeto arquitetônico pelo foco da gestão da qualidade, podemos entendê-lo como um processo que, a partir de um conjunto de dados de entrada, desenvolve as etapas do projeto, para produzir como dados de saída soluções para atenderem as necessidades as quais o edifício se destina. O conjunto de dados de entrada deve conter as diretrizes que atendem às necessidades do empreendimento e a verificação dos dados de saída devem ser feitas verificando se atenderam a estas necessidades, em uma análise crítica, para

depois

serem

encaminhadas

para

processo

validação

com

empreendedores. As saídas se validadas devem ser encaminhadas à produção; e se não validadas devem ser analisadas de modo que sirvam de base para solicitações de mudança no projeto e ajustes no mesmo. Entretanto, em projetos complexos como é o caso dos projetos arquitetônicos, este processo se aplica às etapas ou às partes do projeto, que normalmente passam por estágios de concepção, verificação e validação, cujos dados de saída deste processo se juntam a um novo conjunto de informações, servindo de dados de entrada para a etapa ou parte seguinte. Melhado (1999) também destaca a importância da análise crítica que deve ser feita antes do envio do produto ou serviço para uma validação, realizando uma triagem e uma otimização dos processos de validação. A validação é um elemento essencial e indispensável de todo processo de concepção inserido num sistema de gestão da qualidade. A validação, para ser eficiente, deve ser antecedida de uma análise crítica, a qual tem por objetivo geral avaliar se as soluções propostas pelo projeto correspondem verdadeiramente às necessidades do cliente e levam em conta as restrições que afetam ao projeto. Uma análise crítica pode desencadear um processo de modificação anterior à validação propriamente dita e, portanto, reduzir a possibilidade de que o cliente se decepcione com as soluções apresentadas ou que, mesmo ele as aprovando naquele momento, possa mais tarde identificar pontos de desacordo em relação à mesma. (MELHADO, 1999, p. 4)

Figura 22: O processo de projeto segundo a ótica da gestão de qualidade.

Fonte: Melhado (1999)

Conforme afirmado anteriormente, a análise crítica pode ser determinante na apresentação dos resultados, uma vez que interfere na concepção dos produtos, por

manifestar-se como um questionamento da qualidade, independente e fundamental para a verificação sobre a qualidade das soluções projetuais, obedecendo a critérios determinados de modo a verificar se o andamento do projeto coincide com o seu planejamento, tendo em vista a satisfação do cliente.

2.3.8 O Plano da Qualidade: definição e importância

O Plano de Qualidade do Empreendimento (PQE) é fundamental para a garantia da qualidade do projeto e da obra. O projeto é concebido e desenvolvido de forma integrada pelas equipes de projeto e obra, com o intuito de obter uma obra mais eficaz, eficiente. O PQE deve acompanhar as atividades desenvolvidas no canteiro de obra e, através do feedback da execução da obra, realizar mudanças, buscando uma melhoria contínua. Melhado (1999, p.05), ao citar a norma ISO 9001 afirma que ―as interfaces entre os diferentes grupos implicados no projeto (…) devem ser gerenciadas para assegurar-se uma comunicação eficaz e a clareza de responsabilidades‖. Desta forma, a ISO 9001 reforça a necessidade da integração dos projetos complementares ao projeto arquitetônico e de um sistema colaborativo de trabalho, com a definição de funções e responsabilidades de todos os envolvidos. Para o autor Um dos pontos de debate bastante acirrado entre as empresas de arquitetura que adotam sistemas de gestão da qualidade tem sido as relações com os demais projetistas – no qual a tendência de maior participação dos demais especialistas desde o início do projeto está ganhando bastante destaque. [...] Sobre o planejamento da qualidade, a norma ISO 9004 (ISO, 1999a), no item 5.5.2 da nova versão para o ano 2000, recomenda que a análise de riscos seja incluída entre as considerações necessárias a essa atividade de planejamento. De fato, nos empreendimentos de construção, dado o seu caráter não-repetitivo, os riscos alteram-se a cada novo caso e, portanto, não podem ser previamente tratados pelo sistema da qualidade. (MELHADO, 1999. p. 8)

É, pois, a partir da análise dos textos da série ISO 9000 que Melhado (1999) propõe as seguintes diretrizes para o Plano de Qualidade do Empreendimento PQE a análise de riscos para a qualidade e a adoção de ações para prevenir a ocorrência de falhas consequentes dos mesmos;

o estabelecimento do conjunto de procedimentos de execução e controle a serem utilizados, incluindo a elaboração dos específicos para a obra em questão; a definição dos pontos críticos para controle e validação; as formas de integração entre os diversos participantes da equipe do empreendimento, envolvendo o empreendedor, os projetistas, a coordenação da obra e subcontratados, e fornecedores de produtos ou serviços. . (MELHADO, 1999. p. 8-9)

A adoção do Plano de Qualidade do Empreendimento PQE, segundo Melhado (1999, p.10) tem o potencial de gerar melhorias na qualidade e na satisfação dos clientes, uma vez que através dele é possibilitada a eliminação de padrões genéricos, onde pese a flexibilidade e a adaptabilidade para a composição do sistema de qualidade de cada empreendimento, o respaldo para a concepção de métodos de trabalho que são produtos da incorporação de experiências e competências profissionais dos envolvidos no empreendimento, ao contrário da metodologia individual que se impõe aos demais; por fim, permite a introdução de focos de cooperação simultânea, que fomentam a integração com a execução da obra e a agregação ao processo e produto final.

2.4

A tecnologia BIM

2.4.1 A inovação da tecnologia da Informação nos Projetos Arquitetônicos

A arquitetura sempre esteve ligada ao desenvolvimento de novas tecnologias para a execução das obras e, mais recentemente, para a melhoria contínua da qualidade dos projetos e produtividade da equipe de concepção e desenvolvimento. Durante os anos 90 do século XX, a arquitetura conseguiu obter um grande salto de produtividade, saindo dos desenhos bidimensionais feitos na prancheta, desenvolvendo-os no computador, com os programas CAD – Computer Aided Design (Desenho assistido por computador). Isto gerou um grande salto de produtividade, agora os desenhos podiam ser modificados mais rapidamente, possuírem versões, serem comparados e sobrepostos digitalmente aos projetos complementares, digitalizados para a compatibilização, além de facilitar a troca de informações entre o escritório e a obra, pois um projeto que antes precisaria ser

copiado e depois ser enviado pelos correios, agora já podia ser enviado por e-mail em pouco tempo. No entanto, mesmo com o aumento da produtividade trazida pelo uso dos softwares CAD, a maneira como os projetos eram desenvolvidos seguiam a mesma linha

raciocínio

executando

elementos

arquitetônicos

através

representações bidimensionais, exatamente como os antigos desenhos em papel. Utilizava-se raramente da representação em modelos 3D e quando empregados eram apenas representativos sem informação digital agregada ao desenho. De acordo com o guia da Associação Brasileira de Escritórios de Arquitetura (AsBEA ) de boas práticas em BIM: O processo projetual tem passado nas últimas décadas por contínuas transformações. Saímos da representação dos projetos por meio de desenhos bidimensionais a lápis e através de canetas a nanquim, para desenhos também bidimensionais, porém gerados em meio eletrônico por intermédio de computadores, utilizando softwares para CAD – Computer Aided Design. Por sua vez, o desenvolvimento dos projetos em CAD também tem sofrido grandes e rápidas transformações, em função das evoluções dos softwares e hardwares. Ao longo desse processo evolutivo, surgiu nos últimos anos uma nova plataforma para desenvolver os projetos, com o lançamento de novos softwares, que utilizam processos e conceitos inovadores: a Modelagem da Informação da Construção, ou, como difundido pela sigla em inglês, BIM - Building Information Modeling. (AsBEA, 2013, p. 06)

Manzione (2013), ao citar Eastman (2006, p. 02) salienta que Ao longo da história da Arquitetura, a representação essencial dos edifícios tem sido feita através de desenhos. A leitura de muitos livros mostra como os desenhos e os croquis são parte integrante do pensamento e do trabalho criativo do Arquiteto. [...] A substituição de desenhos por uma nova base de representação para o projeto, comunicação e construção dos edifícios é uma mudança revolucionaria e que marca época, tanto na Arquitetura como na Indústria da Construção em Geral. Estas mudanças alteram ferramentas, os meios de comunicação e os processos de trabalho. (MANZIONE, 2013, p.54)

Em 2000 surgem as primeiras plataformas BIM – Building Information Modeling (Modelagem da Informação da Construção). Nesta nova plataforma onde através da criação de modelos virtuais da construção, que simulam o edifício com todas as suas características espaciais, mecânicas e relacionadas ao seu conforto ambiental, os elementos deixam de ser apenas uma representação e se transformam em uma simulação das informações. E através desse modelo virtual que contém diversas

informações, tem-se a possibilidade de da utilização da Realidade Virtual e da Realidade Aumentada, onde se pode ―ver antes de construído‖ e promover simulações e gerar diversos desenhos e visualizações, úteis para a melhor compreensão do edifício. Portanto, de acordo com a análise de (Manzione (2013, p.35) sobre Underwood e Isikdag (2010), através do advento e crescente uso do BIM, podemos concluir que estamos no início de um novo ciclo na Arquitetura e em toda a Indústria da Construção Civil, uma vez que tal ferramenta permite simular todo o edifício antes de sua construção, possibilitando otimizar o uso de materiais e energia e reduzindo os seus impactos ambientais. Existem alguns pontos importantes nesta mudança: na plataforma BIM, o projeto é desenvolvido em um arquivo compartilhado que atua gerindo todos os dados de projeto, inseridos por todas as diferentes entidades colaboradoras. A reunião de todas estas informações favorece a interoperabilidade e o sistema colaborativo, entre todos os projetistas envolvidos. Informações estas que serão desenvolvidas e incrementadas ao longo do ciclo de vida do projeto arquitetônico e fazendo com que todas as suas dependências e interferências, entre todos os projetos complementares, (mecânicos, térmicos, acústicos, iluminação, etc.) sejam simuladas, analisadas, e instantaneamente compartilhadas por todos os projetistas envolvidos em um único modelo BIM. Outro fator relevante é a possibilidade de que o projeto é desenvolvido como uma programação. Por exemplo, para se projetar uma janela é preciso existir antes a alvenaria que irá recebê-la. Esta simulação permite uma análise constante de todos os projetistas quanto aos requisitos e as restrições do projeto além de pontos de incompatibilidade entre os projetos, chamados de ―clash detection‖. Toda esta comunicação entre os projetos favorecem a utilização do conceito de projeto simultâneo. Este modelo tem grande vantagem: ao analisarmos a assertividade em processos de orçamento e planejamento, estudos de viabilidade e extração de quantitativos, uma vez que o modelo fornece automaticamente estas informações com precisão, já que todos os elementos estão registrados no modelo BIM. Sobre o Planejamento de Custos, o programa se utiliza da base de dados recebida pelo arquiteto e pelos outros projetistas, contribuindo para a assertividade

com os quantitativos de materiais em tabelas precisas e, caso tenham sido inseridos os valores, até o próprio orçamento dos materiais. Quanto ao Planejamento do Tempo do projeto é possível inserir as informações da construção em ―fases‖, separando-as em etapas distintas e criando uma linha do tempo do projeto, o que facilita o gerenciamento da informação do processo construtivo, servindo de base através de outros programas para o gerenciamento do projeto. Existe uma relação direta entre o maior nível e a qualidade das informações inseridos no modelo BIM e a maior assertividade do projeto. 2.4.2 Níveis de maturidade do BIM

Uma das mais conhecidas classificações de maturidade dos modelos BIM é baseada em Bew-Richards e é adotada pelo governo inglês. Como podemos ver na figura 23, no modelo desenvolvido para o governo do Reino Unido, o ―BIM Maturity Model‖, por Mark Bew - Mervyn Richards (2008), existe um aumento da informação presente no modelo, conforme o crescimento do seu nível. Portanto, os seguintes níveis são considerados: 

Nível 0 – Desenhos representativos (feitos à mão, assim como os feitos em computador, CAD) mas sem informação no modelo.



Nível 1 – Desenhos de CAD em 2D e/ou 3D voltados para a análise das interferências, mas sem a biblioteca de gerenciamento de informações dos modelos BIM, apresentando a compatibilização feita manualmente.



Nível 2 - O nível mais simples dos modelos de BIM; apresentam modelos 3D, voltados para a análise das interferências e com a biblioteca de gerenciamento de informações dos modelos BIM, proporcionando a compatibilização do ―clash detection‖ automaticamente.



Nível 3 - O nível mais avançado dos modelos de BIM; com modelos 3D voltados para a análise das interferências e além de oferecer as vantagens do nível anterior, possui informações de alto detalhamento, proporcionando o

desenvolvimento de soluções integradas e simulações sobre o ciclo de vida do edifício.

Figura 23: Níveis de maturidade do BIM, visão inglesa.

Fonte: http://constructioncode.blogspot.com.br/2014/09/bim-levels-of-maturity.html.

2.4.3 Nível de Desenvolvimento – LOD De acordo com a AIA – American Institute Architect, em seu documento Project Building Information Modeling Protocol Form (Protocolo Formal da Modelagem da Informação da Construção), alguns modelos podem ser classificados de acordo com o nível de informações que ele contenha. E sugere a classificação analisando dois aspectos: o conceito do Nível de Desenvolvimento – LOD, ligado ao nível de informações do projeto que constam no modelo BIM e não a representação

gráfica deles. Deste modo, o Nível de Desenvolvimento – LOD pode ser classificado em 5 níveis: 

LOD100 – Desenho Conceitual – O modelo é um desenho conceitual que contém todos os elementos do edifício, seus volumes e materiais. Permitindo analisar sua implantação e orientação. Pode ser relacionado com o nível de informações do estudo de viabilidade, estudo preliminar do projeto arquitetônico.



LOD200 – Desenho em desenvolvimento – O modelo contém o desenho desenvolvido com seus sistemas construtivos, instalações, sistemas, urbanização e entorno. Permitindo realizar uma primeira análise de quantidades e custos da obra, com ou sem variantes. Pode ser relacionado com nível de informações do anteprojeto do projeto arquitetônico.



LOD300 – Documentos para a construção – O modelo contém a informação precisa de elementos construtivos e seus sistemas, permitindo gerar os documentos tradicionais, todos os relatórios, planilhas, desenhos arquitetônicos compatibilizados, desenhos de todos os sistemas e o detalhamento construtivo. Pode ser relacionado com o nível de informações do projeto executivo do projeto arquitetônico.



LOD400 – Fabricação, montagem ou construção – O modelo contém as informações necessárias para a fabricação, montagem ou construção. O projeto deve ter o nível de informações que contenham todos os dados relativos aos fornecedores de equipamentos e sistemas do edifício. Pode ser relacionado com nível de informações do projeto de produto e do projeto arquitetônico.



LOD500 – Operação e Manutenção – O modelo contém as informações do edifício conforme construído, ―as built‖, permitindo iniciar as operações de manutenção das instalações e promovendo o monitoramento assistido do projeto arquitetônico.

Figura 24: Nível de Desenvolvimento – LOD – para o projeto de uma cadeira.

LOD-100 = existe uma cadeira. LOD-200 = existe uma cadeira, que ocupa o espaço de 50 x 50 cm. LOD-300 = existe uma cadeira, com braços e rodas. LOD-400 = existe uma cadeira, com modelo, fabricante e número de serie. LOD-500 = existe uma cadeira, com modelo, fabricante e número de serie, o vendedor, e a data de compra e instalação. Fonte: (KNIJNIK, 2015).

2.4.4 Nível de Detalhe

Deve-se considerar, também, o conceito do Nível de Detalhamento (G), que está ligado ao nível de representação do desenho do projeto e de suas informações. Podendo ser classificado, segundo a AIA (American Institute Architect) em quatro níveis: 

G0 – Esquemático – Apresenta informação mínima, somente para indicar a sua existência.



G1 – Concepção – Traz os detalhes mínimos para a identificação do componente em 3D: apenas com o volume geral demarcado e as informações em nível macro, sem definição de materiais.



G2 – Definição – Contém todas as informações técnicas relevantes e a modelagem 3D necessária para identificar-se o tipo e os materiais do elemento modelado. E é o nível adequado para a maioria dos projetos.



G3 – Renderizado – idêntico ao nível G2, com um grau maior de detalhamento, utilizado apenas quando a escala de apresentação justifique.

Figura 25: Nível de Detalhamento – G – para o projeto de uma cadeira

Fonte: (KNIJNIK, 2015.)

2.4.5 As novas dimensões estendidas do desenho: 3D, 4D, 5D, 6D e 7D

Segundo o site e grupo de estudos inglês BIMTalk, o modelo BIM cria possibilidades através do seu banco de informações da criação do que se chamou de dimensões estendidas; no qual, além das 3 dimensões espaciais, (largura, altura e profundidade) pode-se inserir informações sobre o tempo em que aquele elemento

será executado, o que através dos recursos BIM poderá gerar um cronograma, o que seria considerada a 4ª Dimensão. Podemos inserir no modelo BIM, informações sobre os custos dos materiais, o que pode gerar planilhas orçamentárias, consideradas a 5ª Dimensão. E ainda podemos ter mais uma dimensão do desenho, se ele for revisado com as informações de como a obra foi executada, o que chamamos de ―As-Built‖, ou ainda de simulações para o controle e manutenção do edifício, que podemos considerar como a 6ª Dimensão. Segundo o BIMTalk, o desenho BIM oferece dimensões estendidas, a saber: 3D - Terceira Dimensão - O Modelo Passeios Virtuais – Possibilita a visualização simulada de todo o projeto permitindo aos arquitetos e engenheiros, a trabalhar juntos para identificar e resolver problemas antes da sua construção. Detecção de Conflitos – Tradicionalmente desenhos de projetos devem ser coordenados para assegurar que não existam conflitos entre os diferentes sistemas prediais e que a sua execução é possível. Desta forma, a maioria dos conflitos são identificados apenas em fases avançadas do projeto (Projeto Básico (PB) e/ou Projeto para execução (PE)), o que aumenta o custo para a resolução de conflitos. No entanto com as ferramentas BIM, e a utilização de uma equipe de projeto simultâneo os conflitos são identificados automaticamente pela ferramenta que faz um alerta solicitando uma solução. Visualização do Projeto – Oferece assim como uma maquete física a possibilidade da geração de imagens diversas imagens para o melhor entendimento e auxiliando na tomada de decisão quanto aos aspectos estéticos e funcionais do projeto. Tendo cada modelo a sua estimativa de custos desenvolvida a partir das informações dos custos dos materiais. Pré-fabricação – Com o Nível de Detalhe (ND) dos projetos em BIM os modelos podem ser usados com segurança para a pré-fabricação de componentes para a obra. Como resultado, o trabalho da construção pode ter mais produtividade dentro e fora do canteiro de obras, custo mais eficiente, e maior controle dos componentes pré-fabricados e mais eficiência. 4D – Quarta Dimensão – O Tempo Planejamento e Gerenciamento da Construção – Os modelos em BIM permitem a verificação da logística do local e operações de canteiro de obras, incluindo ferramentas de visualização da utilização do espaço de trabalho durante a construção. O modelo pode incluir componentes temporários como guindastes, caminhões, rotas de acesso de materiais, andaimes, gruas elevadores e outros itens que podem ser incorporados no plano de logística. E outras ferramentas podem ser utilizadas para o monitoramento e controle de saúde e segurança necessárias ao canteiro de obras. Visualização de Cronograma – Ao acompanhar a visualização do cronograma, com monitoramento e controle da obra, no modelo BIM, os arquitetos gestores podem tomar decisões baseados em vários fatores analisados em tempo real. Com o modelo BIM podemos gerar um gráfico onde podemos visualizar o caminho crítico e as dependências entre as atividades. Com a modificação do modelo BIM, automaticamente o novo caminho crítico e as dependências entre as atividades são identificadas indicando o impacto gerado nas entregas do projeto.

5D – Quinta Dimensão – O Custo Planilhas de Orçamento - Para a determinação do custo da construção do projeto, seus recursos (mão-de-obra, equipamentos e materiais), tradicionalmente era um processo manual de quantificação com grande potencial de erros. Com o modelo BIM, caso tenhamos inserido todas as informações e tenhamos um bom Nível de Detalhe (ND), podemos gerar rapidamente tabelas precisas com as quantidades dos materiais e seus custos, tamanho e áreas estimadas, e uma projeção da produtividade. Caso ocorram mudanças, as informações são automaticamente ajustadas agregando muita produtividade. Estimativa de Custo em tempo real – Em um modelo BIM os dados de custo podem ser adicionados em cada objeto para que permita ao software calcular automaticamente uma estimativa aproximada dos custos por material. O que é uma ferramenta valiosa par o arquiteto permitindo estar sempre atento aos custos da execução do seu projeto. No entanto, para a definição do preço global, a análise de um orçamentista é importante para a validação da estimativa. 6D – Sexta Dimensão – Facilitadores de Gestão As-Built – Quando o projeto o projeto concebido pelo arquiteto sofre alterações na sua execução ou em futuras reformas, chamamos de ―AsBuilt‖, ou seja, como construído. Estas informações atualizadas mantém o modelo fiel ao projeto realizado com todas as especificações, informações sobre a operação e manutenção, manuais de utilização e garantia de informações, útil para a manutenção futura da edificação. Gerenciamento do Ciclo de Vida – Sensores instalados da edificação podem coletar dados da operação do edifício, permitindo ao modelo BIM, ser utilizado par modelar e avaliar a eficiência energética, monitorar os custos do ciclo de vida do edifício e otimizar a sua eficiência de custos. E também permite aos gestores através de simulações avaliarem a relação custo x benefício de quaisquer modificações propostas. (BIMTalk, 2013)

2.4.6 O Desenvolvimento Integrado do Empreendimento Em 2007, o American Institute of Architects California Council - AIA CC, propõe o conceito do desenvolvimento integrado do empreendimento, Integrated Project Delivery – IPD. De acordo com o órgão, este conceito tem como objetivo a integração das pessoas, sistemas, estruturas e práticas empresariais em um processo colaborativo que valoriza os talentos e as ideias de todos os participantes com o objetivo de otimizar os resultados do projeto, aumentar o valor do empreendimento para o proprietário, reduzir o desperdício e maximizar a eficiência durante todas as fases o projeto e de concepção, desenvolvimento e execução. Os Princípios do IPD podem ser aplicados a uma variedade de arranjos contratuais e as equipes, segundo o Integrated Project Delivery – IPD (Desenvolvimento

Integrado

Empreendimento),

além

tríade

básica

proprietário, arquiteto e construtor, podem incluir outros membros envolvidos no projeto e na execução. Em todos os casos, os projetos integrados são distinguidos

pela colaboração altamente eficaz entre o proprietário, o arquiteto, e o construtor, desde os primeiros estudos até a entrega do produto. Desse modo, O conceito Desenvolvimento Integrado do Empreendimento (―Integrated Project Delivery‖ – IPD) corresponde a uma metodologia de contratação e desenvolvimento do empreendimento à qual tem estado associada a concepção segundo o Building Information Modeling. Este método procura integrar a intervenção dos principais intervenientes no desenvolvimento do empreendimento nas fases mais iniciais possíveis, incluindo a Entidade Executante. A relação entre estes intervenientes deverá desenvolver-se num ambiente totalmente colaborativo, partilhando abertamente a informação e conhecimento, sendo baseada nos princípios de confiança, partilha de risco e partilha de resultados. Este conceito permite antecipar o esforço do desenvolvimento do empreendimento para as fases iniciais, permitindo uma maior sobreposição destas, traduzindo-se numa clara economia de tempo de duração total do mesmo. A Figura 4 apresenta a comparação do esforço de desenvolvimento do empreendimento ao longo do tempo, entre os processos tradicionais e o processo IPD (AIA et al., 2007). Igualmente apresenta as curvas referentes à capacidade de decisões que influenciam oportunamente a definição das funcionalidades e dos custos dos empreendimentos e o custo a suportar por efeito de alterações ao âmbito do projeto, ao longo do seu ciclo de vida. (PISSARA, 2010, p. 15).

Figura 26: Curva de MacLeamy, mostrando a comparação entre o processo tradicional e o processo BIM/IPD.

Fonte: (KNIJNIK, 2015.)

2.4.7 A integração do BIM com ferramentas de gestão.

Através da digitalização e organização de todas as informações do projeto em modelos BIM com mais nível de maturidade e com a utilização das dimensões estendidas, a integração do projeto arquitetônico com as ferramentas de gestão, podem funcionar de maneira integrada. Segundo Müller (2015): Esse planejamento da obra é parte imprescindível para o sucesso e o cumprimento das metas estabelecidas para o projeto. A integração do modelo BIM com o cronograma elaborado funciona como uma via de duas mãos: o modelo fornece informações para a elaboração do cronograma, e o planejamento fornece cenários e estudos para serem implementados graficamente no modelo. (MÜLLER, 2015, p. 37) A partir do modelo completo, a velocidade de extração de dados de quantitativos se limita a alguns cliques. Com o devido cuidado no desenvolver da modelagem aliado com alguns filtros na informação, os quantitativos precisam de pouco tratamento para que possam ser utilizados na elaboração dos cronogramas. (IDEM, p. 39) O processo de integração do modelo com o cronograma tem um certo caráter iterativo, já que uma vez que o modelo está pronto, é elaborado o cronograma, mas a partir do planejamento pronto, com o cronograma feito, pode se modificar métodos construtivos para evitar interferências, o próprio plano de ataque pode ser alterado de forma a permitir o facilitar a execução de tarefas concomitantes, e a própria natureza orgânica do planejamento faz com que ele possa se modificar durante a fase de execução. [...] O Navisworks Manage é a ferramenta que finalmente integra o modelo e o cronograma. Para isso, é necessário importar o modelo digital 3D de forma a criar um novo arquivo em formato proprietário utilizado pelo Navisworks. (...) Além disso, um cronograma deverá ser importado, sendo possível fazê-los a partir dos softwares Primavera e Project, no caso desse projeto, o último. É possível cria-lo no próprio Navisworks, mas comparado com as outras ferramentas é ainda bastante rudimentar. (IDEM, p. 40)

2.4.8 As principais “barreiras” para a mudança para a tecnologia BIM

Os projetos desenvolvidos em BIM tratam-se de modelos tridimensionais alimentados por diversos tipos de informações desde o início do processo, favorecendo o desenvolvimento iterativo e incremental. A partir do modelo criado com sua volumetria em 3D e as informações inseridas, podem ser gerados todo o

tipo de informação, plantas, cortes, fachadas, perspectivas, tabelas quantitativas, possibilitando análises e simulações do empreendimento. No entanto, tal modelo vem encontrando um pouco de resistência junto às empresas de projetos, uma vez que tal simulação de solução exige mais informação para a sua concepção do que os projetos desenvolvidos na metodologia tradicional, em que os desenhos são representações em 2D e vão sendo desenvolvidos de forma fragmentada e desconexa. Acerca disso, Bazjanac (2004), ao ser citado por Souza et al. (2009, p.06) afirma que “a grande maioria dos projetos de edifícios ainda é desenvolvida no método tradicional, com desenhos 2D e documentos de texto. O setor de projetos, em geral, está resistindo à mudança em direção a esse novo modelo de informação”. Fato que se explica a partir dos estudos de Sousa e Meiriño (2013), que dão conta de que A necessidade da configuração de parâmetros e definição de informações não geométricas nas fases iniciais de concepção do modelo, exige do usuário um certo nível de experiência e conhecimento projetual, dificultando o uso dos sistemas por estagiários e projetistas recém-formados, uma vez que a maioria dos cursos universitários de Arquitetura e Engenharia Civil ainda não incorporaram as novas ferramentas computacionais ao ensino de projeto. (SOUSA; MEIRIÑO, 2013, p. 9)

Outra questão importante tange o investimento financeiro na aquisição de novos ―softwares‖ e em ―hardware‖ de alto desempenho, na realização de treinamentos e no desenvolvimento de novas bases de trabalho, uma vez que a evolução tecnológica não alcança os profissionais em sua totalidade, produzindo deficiências que perpassam a mão de obra especializada e, consequentemente, o produto final. Assim, Por se tratar de uma prática relativamente recente, o número de projetistas capacitados fazendo uso efetivo das ferramentas BIM é insuficiente para promover total integração entre os escritórios, empresas e profissionais autônomos de AEC. De acordo com Campbell (2007), o isolamento daqueles que investiram nos sistemas BIM acarreta uso incipiente da totalidade de suas possibilidades. (SOUSA; MEIRIÑO, 2013, p. 11)

2.4.9 Impactos da implantação de sistemas BIM A mudança da plataforma CAD para a plataforma BIM promove um forte impacto no ciclo de vida do projeto e na metodologia da sua concepção. No primeiro momento, ocorre a redução da produtividade, tendo em vista que os novos templates estão sendo criados e a equipe passa por um momento de treinamento e adaptação. No entanto, após a implantação do novo sistema, o aumento da produtividade é exponencial. A revista AU (Arquitetura e Urbanismo) traz uma matéria que apresenta o cenário da implementação do BIM junto aos profissionais do escritório Aflalo & Gasperini, que confirmam que A redução do rendimento é temporária e a tendência é que após o período de transição haja um aumento considerável de produtividade. Um dos principais motivos é a facilidade de gerar a documentação do projeto a partir do modelo BIM. Ao modificar um elemento construtivo no modelo, automaticamente o software atualiza todas as plantas, cortes e elevações do projeto, já que toda a informação está concentrada em um único arquivo. No CAD, a cada modificação seria preciso atualizar planta por planta. 2 "Hoje conseguimos desenvolver projetos complexos de até 40 mil m com apenas três arquitetos, quando no CAD seria preciso ter no mínimo o dobro da equipe", comemora Pedro Lira. Em geral, o BIM requer uma equipe menor, mas com profissionais mais especializados. O Aflalo & Gasperini também experimentou a redução da equipe por conta do BIM. "Houve um caso em que, baseado nos modelos antigos de planejamento, teríamos que contratar uma pessoa a mais, mas os dois integrantes da equipe foram suficientes", conta Miguel Aflalo. (REIS, 2011)

Ainda de acordo com o periódico, outra questão que deve ser levada em consideração entre os usuários do BIM é a alteração dos prazos das etapas do projeto. Convencionalmente, um arquiteto teria menos trabalho diante dos estudos preliminares, fato que mudaria à medida que o projeto evoluísse e se aproximasse do executivo. Já quando o profissional lança mão do suporte do BIM, este cenário se desloca e a exigência recai sobre o profissional ainda na elaboração do anteprojeto. Assim, a necessidade de se trabalhar com determinadas informações técnicas em fases anteriores às usuais provocou uma demanda por profissionais de diferentes áreas, capazes de prestar consultoria, eliminando quaisquer falhas no conjunto das informações coletadas. De acordo com a experiência vivida por Miguel Aflalo, mais do que utilizar o software no escritório é preciso que a equipe, como um todo, esteja apta a maneja-lo com desenvoltura. Dessa forma, é imprescindível a criação de um núcleo dedicado a implementação do novo sistema e da realização da mudança de forma gradual, haja

vista o treinamento da mão de obra, do enquadramento ao contexto das demandas do escritório e dos processos de produção. “Percebemos que não era só trocar o programa, era preciso mudar o processo inteiro", comenta. Em 2008, foi criado um departamento específico, sob coordenação de Miguel Aflalo, para aprofundar o conhecimento do software, customizar o programa às necessidades do escritório, realizar treinamentos e dar suporte às outras equipes de projeto. Foram montados cursos de 20 horas, distribuídas ao longo de 15 dias. Ao final do treinamento, cada equipe desenvolvia um projeto em BIM com apoio do núcleo de implementação. "Trabalhamos em doses homeopáticas, uma equipe por vez. Cada projeto que era começado herdava aprendizado dos projetos anteriores", afirma Aflalo. (REIS, 2011)

Assim, deve-se levar em consideração a relação custo-benefício da aplicação do modelo BIM para a produção de projetos; uma vez que, a despeito da demanda inicial requerer uma maior atenção do profissional e consequente concentração de forças, os resultados são satisfatórios e agradam tanto o profissional quanto o seu cliente.

2.5

O Gerenciamento de Projetos

2.5.1 Gestão 1.0

Em seu artigo A história do gerenciamento de projetos, Mario Andreuza (s.d) observa que desde os primórdios da civilização, projetos sempre foram elaborados e executados, como as diversas construções da Antiguidade. Porém, tais obras monumentais parecem ter sido concebidas empiricamente ou, pelo menos, sem documentação. No entanto, após a Revolução Industrial, na segunda metade do século XIX, o ocidente passou por uma profunda mudança na estrutura econômica, tendo como uma de suas principais consequências o desenvolvimento do capitalismo industrial. As relações de produção são amplamente modificadas, o que tornou cada vez mais necessária a tarefa de gerir as organizações. A primeira fase da gestão de projetos, tal como a conhecemos hoje, se dá no início do século XX, com os primeiros estudos de Frederick Taylor (1856-1915), que

aplica o seu raciocínio cientifico para analisar e melhorar as sequências de trabalho, sistematizando-as em partes, a fim de buscar a melhoria da produtividade. Ainda nesta época, Taylor associa- se a Henry Gantt (1861-1919) que foca os seus estudos no ordenamento das operações no trabalho. Gantt representou estas ordenações em diagramas com barras de tarefas e marcos que esboçavam a sequência e a duração de todas as tarefas em um processo. Tais diagramas tornaram-se uma ferramenta analítica de fácil compreensão e seguem sendo utilizados até hoje com poucas modificações. Assim, Taylor, Gantt e outros estudiosos nos mostraram que o desenvolvimento do gerenciamento de projetos exigia estudo e disciplina. No entanto, vale ressaltar que o foco desta primeira fase foi voltado apenas para o aumento da produtividade. E tem como características a centralização do controle dos projetos, o planejamento de cima para baixo, um ambiente hierárquico e autoritário, o monitoramento constante do operacional para garantir a performance, o acesso limitado e restrito às informações de planejamento que, nesta época, só podiam ser acessadas fisicamente. A comunicação entre as equipes era limitada e os projetos eram gerenciados separadamente, através do uso de ferramentas rígidas e complexas. Em 1917, Fayol define as 5 funções de um gestor: Planejar; Coordenar; Organizar; Comandar e Controlar. Para ilustrar esta fase podemos citar dois exemplos clássicos de ilustram o pensamento de redução de custos e aumento na produtividade: a frase lapidar de Henry Ford “O cliente pode ter o carro da cor que quiser, contanto que seja preto”, uma vez que a tinta preta era a mais barata e o processo produtivo, sem a alteração de cores, exigia menos tempo. E a representação das linhas de produção do filme ―Tempos modernos‖, de Charles Chaplin.

2.5.2 Gestão 2.0

Na segunda metade do século XX, após a II Guerra Mundial, entramos na segunda fase da gestão de projetos. Novas áreas de conhecimento como a

psicologia industrial, as relações humanas e as estratégias de marketing começam a ser integradas com o gerenciamento dos negócios e a administração das empresas. Com o aumento da complexidade dos projetos surgem novas estruturas organizacionais e novas ferramentas, como os Diagramas de Rede, os Gráficos PERT (Program Evaluation and Review Technique) e o método de Caminho Crítico (Critical Path Method - CPM), dando mais assertividade aos profissionais na gestão de seus projetos. E novas iniciativas, buscando a melhoria da produtividade como Balanced Score Cards (BSC), Six Sigma, TQM, entre outras. Mantendo, no entanto, o mesmo conceito do planejamento de cima para baixo. Com a difusão destas novas técnicas e ferramentas pelas organizações industriais, os sistemas de gestão começam a ser vistos como uma parte integrada às empresas e ao seu planejamento, buscando atingir metas especificas, com prazos e custos determinados. Deste modo, o gerenciamento de projetos passa a ser reconhecido como uma ciência no início dos anos 60. O complexo mundo das organizações e dos negócios reconhecem o benefício do trabalho organizado em torno dos projetos e a compreender as necessidades fundamentais para a comunicação e a integração dentro dos projetos. Nesta segunda fase da gestão de projetos, vemos um gerenciamento focado em técnicas, buscando melhorias em relação ao conceito anterior, mas mantendo a mesma estrutura de análise de cima para baixo, mudando muito pouco o conceito anterior da hierarquia piramidal.

2.5.2.1 O Surgimento do PMI

Em 1969, Jim Snyder e outros cinco profissionais de gestão de projetos, fundam na Philadelphia, Pensilvânia - EUA, o PMI - Project Management Institute – Instituto de Gerenciamento de Projetos. Atualmente, o PMI é a maior instituição internacional dedicada à disseminação do conhecimento e ao aprimoramento das atividades de gestão profissional de projetos. O PMI estima que atualmente cerca de um quarto do PIB

mundial é aplicado em projetos e que aproximadamente 16,5 milhões e meio de profissionais estão ligados diretamente à alguma metodologia de gerenciamento de projetos. Assim, o instituto fica responsável pelas certificações ISO e as demais certificações relacionadas a projetos, tais como: 

Certificação CAPM – Técnico Certificado em Gerenciamento de Projetos;



Certificação PfMP® - Profissional de Gerenciamento de Portfolio fazer PMI;



Certificação PMI-PBA® - Profissional de Análise de Negócios do PMI;



Certificação PMP – Profissional de Gerenciamento de Projetos (PMP);



Certificação PMI-SP – Profissional de Gerenciamento de Cronograma do PMI;



Certificação PMI-RMP – Profissional de Gerenciamento de Riscos do PMI;



Certificação PgMP – Profissional de Gerenciamento de Programas PMI;



Certificação PMI-ACP – Profissional Certificado em Métodos Ágeis do PMI Além disto o PMI, é responsável pela publicação do Guia do Conhecimento

em Gerenciamento de Projetos (Guia PMBOK®), cujos objetivos são identificar o subconjunto de conhecimentos em gerenciamento de projetos que são ―amplamente reconhecidos‖ como ―boa prática‖, o que significa que conhecimentos e práticas são, comumente, aplicáveis à quase totalidade dos projetos, havendo um consenso relacionado ao seu valor e utilidade, o que aumenta as possibilidades de sucessos futuros, ficando à equipe responsável a decisão acerca de sua apropriação e aplicabilidade. Além disso, o guia também fornece e promove um vocabulário que é utilizado estritamente pelos profissionais de gerenciamento, tendo em vista o uso e a aplicação de conceitos. A possibilidade de adoção de um vocabulário comum é importante, uma vez que torna mais claros os objetivos de cada profissional, evitando equívocos de comunicação; além disso, pode ser utilizado por quaisquer segmentos envolvidos no empreendimento, aproximando gerentes e partes interessadas. O Guia PMBOK apresenta o Gerenciamento de Projetos como sendo a utilização de conhecimento, habilidades, ferramentas e técnicas ao projeto, de modo que este atenda às suas necessidades e requisitos. Tal procedimento torna-se concreto a partir da integração e aplicação dos 47 processos de gerenciamento de projetos, estes agrupados em cinco grupos, que são: 

Iniciação;



Planejamento;



Execução;



Monitoramento e controle; e



Encerramento. O Guia ainda apresenta os processos de gerenciamento de acordo com sua

natureza, uma vez que este se conforma a partir da integração entre os processos, suas interações e objetivos. Assim, cinco categorias conhecidas como Grupos de Processos são agrupadas e descritas a seguir: • Grupo de processos de iniciação. Os processos executados para definir um novo projeto ou uma nova fase de um projeto existente através da obtenção de autorização para iniciar o projeto ou fase. • Grupo de processos de planejamento. Os processos necessários para definir o escopo do projeto, refinar os objetivos e definir a linha de ação necessária para alcançar os objetivos para os quais o projeto foi criado. • Grupo de processos de execução. Os processos realizados para executar o trabalho definido no plano de gerenciamento do projeto para satisfazer as especificações do projeto. • Grupo de processos de monitoramento e controle. Os processos exigidos para acompanhar, analisar e controlar o progresso e desempenho do projeto, identificar quaisquer áreas nas quais serão necessárias mudanças no plano, e iniciar as mudanças correspondentes. • Grupo de processos de encerramento. Os processos executados para finalizar todas as atividades de todos os grupos de processos, visando encerrar formalmente o projeto ou fase.‖ (PMI, 2013, p. 48-49).

Figura 27: Ciclo de vida dos grupos de processos de gerenciamento de projetos.

Fonte: (PMI, 2013).

Figura 28: Os grupos de processos interagem em uma fase ou em um projeto.

Fonte: (PMI, 2013)

E distribuídas durante todos os processos estão as 10 áreas de conhecimento estudadas no PMI. As áreas de conhecimento, segundo o PMI (2013): O gerenciamento da integração do projeto inclui os processos e atividades para identificar, definir, combinar, unificar e coordenar os vários processos e atividades dentro dos grupos de processos de gerenciamento do projeto. (PMI, p. 63). O gerenciamento do escopo do projeto inclui os processos necessários para assegurar que o projeto inclui todo o trabalho necessário, e apenas o necessário, para terminar o projeto com sucesso. O gerenciamento do escopo do projeto está relacionado principalmente com a definição e controle do que está e do que não está incluso no projeto. (PMI, p. 105). O Gerenciamento do tempo do projeto inclui os processos necessários para gerenciar o término pontual do projeto. (PMI, p. 141). O gerenciamento dos custos do projeto inclui os processos envolvidos em planejamento, estimativas, orçamentos, financiamentos, gerenciamento e controle dos custos, de modo que o projeto possa ser terminado dentro do orçamento aprovado. (PMI, p. 193) O gerenciamento da qualidade do projeto inclui os processos e as atividades da organização executora que determinam as políticas de qualidade, os objetivos e as responsabilidades, de modo que o projeto satisfaça às necessidades para as quais foi empreendido. O gerenciamento da qualidade do projeto usa as políticas e procedimentos para a implementação, no contexto do projeto, do sistema de gerenciamento da qualidade da organização e, de maneira apropriada, dá suporte às atividades de melhoria do processo contínuo como empreendido no interesse da organização executora. O gerenciamento da qualidade do projeto trabalha para garantir que os requisitos do projeto, incluindo os requisitos do produto, sejam cumpridos e validados. (PMI, p. 227)

O gerenciamento dos recursos humanos do projeto inclui os processos que organizam, gerenciam e guiam a equipe do projeto. A equipe do projeto consiste das pessoas com papéis e responsabilidades designadas para completar o projeto. Os membros da equipe do projeto podem ter vários conjuntos de habilidades, atuar em regime de tempo integral ou parcial, e podem ser acrescentados ou removidos da equipe à medida que o projeto progride. Os membros da equipe do projeto também podem ser referidos como pessoal do projeto. Embora os papéis e responsabilidades específicos para os membros da equipe do projeto sejam designados, o envolvimento de todos os membros da equipe no planejamento do projeto e na tomada de decisões pode ser benéfico. A participação dos membros da equipe durante o planejamento agrega seus conhecimentos ao processo e fortalece o compromisso com o projeto. (PMI, p. 255) O gerenciamento das comunicações do projeto inclui os processos necessários para assegurar que as informações do projeto sejam planejadas, coletadas, criadas, distribuídas, armazenadas, recuperadas, gerenciadas, controladas, monitoradas e finalmente dispostas de maneira oportuna e apropriada. Os gerentes de projetos passam a maior parte do tempo se comunicando com os membros da equipe e outras partes interessadas do projeto, quer sejam internas (em todos os níveis da organização) ou externas à organização. A comunicação eficaz cria uma ponte entre as diversas partes interessadas do projeto, que podem ter diferenças culturais e organizacionais, diferentes níveis de conhecimento, e diversas perspectivas e interesses que podem impactar ou influenciar a execução ou resultado do projeto. (PMI, p. 287) O Gerenciamento dos riscos do projeto inclui os processos de planejamento, identificação, análise, planejamento de respostas e controle de riscos de um projeto. Os objetivos do gerenciamento dos riscos do projeto são aumentar a probabilidade e o impacto dos eventos positivos e reduzir a probabilidade e o impacto dos eventos negativos no projeto. (PMI, p. 309) O gerenciamento das aquisições do projeto inclui os processos necessários para comprar ou adquirir produtos, serviços ou resultados externos à equipe do projeto. A organização pode ser tanto o comprador quanto o vendedor dos produtos, serviços ou resultados de um projeto. (PMI, p. 355) O gerenciamento das partes interessadas do projeto inclui os processos exigidos para identificar todas as pessoas, grupos ou organizações que podem impactar ou serem impactados pelo projeto, analisar as expectativas das partes interessadas e seu impacto no projeto, e desenvolver estratégias de gerenciamento apropriadas para o engajamento eficaz das partes interessadas nas decisões e execução do projeto. O gerenciamento das partes interessadas também se concentra na comunicação contínua com as partes interessadas para entender suas necessidades e expectativas, abordando as questões conforme elas ocorrem, gerenciando os interesses conflitantes e incentivando o comprometimento das partes interessadas com as decisões e atividades do projeto. A satisfação das partes interessadas deve ser gerenciada como um objetivo essencial do projeto. (PMI, p. 391)

Figura 29: As dez áreas de conhecimento conforme o PMBOK.

Fonte: Google Imagens (https://www.emaze.com/@AOCTOQIC/GEOR)

Para promover a integração e a comunicação entre os projetos e as partes interessadas é importante que o Gerente de Projetos tenha bem desenvolvidas suas habilidades interpessoais. Segundo o PMI, (2013, p. 513), um trabalho eficaz de uma equipe é realizado a partir do equilíbrio de características inerentes a cada profissional, facilitando seu relacionamento com os pares, de modo que possam avaliar as situações e interagir de maneira adequada. De modo que os gerentes de projetos, via quadro de profissionais do projeto e de outras partes interessadas possam gerir seu trabalho a partir de um equilíbrio de competências técnicas, interpessoais e conceituais. São, pois, estes atributos: 

Liderança;



Desenvolvimento da equipe;



Motivação;



Comunicação;



Influência;



Processo decisório;



Conhecimento político e cultural;



Negociação;



Estabelecimento de confiança;



Gerenciamento de conflitos;



Coaching. Além destas, outras características são facilitadoras dos relacionamentos

interpessoais e que também são utilizadas pelos gerentes de projetos, favorecendo no seu gerenciamento efetivo. A figura 30 traz um mapeamento dos grupos de processos de gerenciamento de projetos e das áreas de conhecimento correlacionadas.

Figura 30: Grupo de processos de gerenciamento de projeto e mapeamento das รกreas de conhecimento.

Fonte: (PMI, 2013).

Mesmo levando em conta diversos fatores no planejamento do Projeto, devemos considerar que ele é elaborado de forma progressiva e com diversas variáveis e interesses, o que provoca um grande potencial de mudanças. O que significa que Devido ao potencial de mudanças, o desenvolvimento do plano de gerenciamento do projeto é uma atividade iterativa elaborada de forma progressiva ao longo do ciclo de vida do projeto. A elaboração progressiva envolve a melhoria contínua e o detalhamento de um plano conforme informações mais detalhadas e específicas e estimativas mais exatas tornam-se disponíveis. A elaboração progressiva permite que a equipe de gerenciamento do projeto defina e gerencie o trabalho com um nível maior de detalhes, à medida que o projeto evolui.‖ (PMI, 2013, p. 5).

Acerca da elaboração progressiva, verifica-se, a partir de PMI (2013, p. 40) que “A capacidade de influenciar as características finais do produto do projeto, sem impacto significativo sobre os custos, é mais alta no início do projeto e diminui à medida que o projeto progride para o seu término”. A Figura 31 representa a ideia de do que foi exposto anteriormente, os custos das mudanças e alterações do projeto aumentam à medida que este chega ao seu termo, enquanto que os riscos diminuem proporcionalmente.

Figura 31: Impacto da variável com base no tempo decorrido do projeto.

Fonte: (PMI, 2013).

Apesar de serem consideradas características inerentes aos ciclos de vida de quase todos os projetos, sua conformação se apresenta em graus similares. Devese salientar que os ciclos de vida adaptativos comumente são elaborados a partir da

ideia de que ao longo de todo ciclo de vida do projeto, mantenha-se o grau de influência das partes interessadas mais alto, opondo-se aos custos das mudanças, quando se leva como referência o ciclo de vida previsível. Assim, a partir da realidade de uma estrutura genérica do ciclo de vida de um projeto, o seu gerente pode precisar, por exemplo, a necessidade de um manejo eficaz sobre determinadas entregas, ou que estas podem ser concluídas antes da definição do escopo do projeto. Tal prática se aplica a grandes e complexos projetos, particularmente aqueles que pressupõem um nível incremental de controle. Nestes, os expedientes realizados para atingir os propósitos do projeto podem ser favorecidos a partir de uma divisão formal em fases. Para a gestão de projetos arquitetônicos devemos considerar seus ciclos de vida como complexos, predeterminados, adaptativos, iterativos e incrementais. Segundo o PMI (2013) Os ciclos de vida previstos (também conhecidos como ciclos de vida inteiramente planejados) são aqueles em que o escopo do projeto, bem como o tempo e custos exigidos para entregar tal escopo são determinados o mais cedo possível no ciclo de vida do projeto, que progride através de uma série de fases sequenciais ou sobrepostas, em que cada fase geralmente foca um subconjunto de atividades de projeto e processos de gerenciamento de projeto. O trabalho executado em cada fase é geralmente de caráter diferente do trabalho das fases anteriores e subsequentes e, assim sendo, a formação e habilidades exigidas da equipe do projeto podem variar de fase para fase. [...]Ciclos de vida iterativos e incrementais são aqueles em que as fases do projeto (também chamadas de iterações) intencionalmente repetem uma ou mais atividades de projeto à medida que a compreensão do produto pela equipe do projeto aumenta. Iterações desenvolvem o produto através de uma série de ciclos repetidos, enquanto os incrementos sucessivamente acrescentam à funcionalidade do produto. Os ciclos de vida desenvolvem o produto de forma tanto iterativa como incremental. [...] Os ciclos de vida adaptativos (também conhecidos como direcionados à mudança ou utilizadores de métodos ágeis) são projetados para reagir a altos níveis de mudança e envolvimento contínuo das partes interessadas. Os métodos adaptativos são também iterativos e incrementais, a diferença é que as iterações são muito rápidas (geralmente com uma duração de 2 a 4 semanas), com tempo e recursos fixos. Os projetos adaptativos geralmente executam vários processos em cada iteração, embora as primeiras iterações possam se concentrar mais nas atividades de planejamento. (PMI, 2013, p. 44-46).

Quando o projeto é iniciado, a equipe do projeto se concentra em definir o escopo geral de produto e projeto, desenvolve um plano de entrega do produto (e de quaisquer entregas associadas) e então dá prosseguimento às fases para a execução do plano dentro daquele escopo. As mudanças no escopo do projeto são

meticulosamente gerenciadas e exigem o replanejamento e a aceitação formal do novo escopo. Ainda de acordo com o PMI (2013), os ciclos de vida previsíveis são escolhidos quando há bastante entendimento sobre o produto a ser entregue, quando existe uma base relevante de prática na indústria, ou, ainda, quando há solicitações de que o produto seja entregue por inteiro, de modo a ter valor junto aos grupos de partes interessadas. Assim, os projetos uniformes que se utilizam deste ciclo de vida podem usar o conceito de planejamento em ondas sucessivas, dentro de um plano geral e de alto nível, no qual está disponível e um planejamento mais cuidadoso é executado para as janelas de tempo correspondentes, à medida que são associadas novas atividades de trabalho e recursos são designados. Os projetos interativos (ou incrementais) avançam em etapas e as interações são executadas de modo sequencial ou sobreposicional. Ao longo de uma interação, as atividades das equipes de processos de gerenciamento de projetos serão executadas. Ao final de cada interação, uma entrega (ou um conjunto de entregas) deverá ser concluída. Deste modo, as futuras interações podem refinar tais entregas ou criar novas. Assim, cada nova interação proporciona o aprimoramento, a partir da aplicação de novos incrementos, às entregas até que os critérios de saída de fase sejam satisfeitos, permitindo a incorporação do feedback pela equipe do projeto. Neste tipo de ciclo, de forma geral desenvolve-se uma visão de alto nível para o empreendimento, mas no escopo detalhado é elaborada uma interação de cada vez. Desta forma, o planejamento para uma nova interação é feito à medida que o trabalho no escopo e entregas da interação atual avançam. O trabalho exigido para um determinado conjunto de entregas pode variar em duração e esforço, de modo que a equipe do projeto pode mudar entre ou durante as iterações. As entregas não abordadas no escopo da iteração atual são normalmente abrangidas somente em um nível mais alto e podem ser provisoriamente designadas para uma iteração futura específica. As mudanças no escopo da iteração são cuidadosamente gerenciadas assim que o trabalho se inicia. Os ciclos de vida iterativos e incrementais são geralmente preferidos quando uma organização necessita administrar as mudanças dos objetivos e escopo, reduzir a complexidade de um projeto ou quando a entrega parcial de um produto é benéfica e proporciona valor para um ou mais grupos de partes interessadas, sem causar impacto na entrega ou conjunto de entregas final.

Projetos grandes e complexos são muitas vezes executados de maneira iterativa para reduzir o risco ao permitir que a equipe incorpore o feedback e as lições aprendidas entre as iterações. (PMI, 2013 p. 45-46).

O propósito geral de um projeto pode ser seccionado em um conjunto de requisitos e trabalhos a serem executados, o backlog do projeto. Ao início da interação, a equipe ficará incumbida de estipular a quantidade de itens que consideram prioritários dentro da lista de backlog, que podem ser entregues na interação seguinte. Ao final de cada interação, o produto deve ser entregue pronto para a avaliação do cliente. Mesmo que ainda não seja a versão final e que o cliente não aceite prontamente o produto, este não pode conter elementos inacabados, incompletos ou que não possam ser utilizados. Desta forma, pressupõe-se que tantos os representantes dos patrocinadores quanto os clientes devem estar envolvidos no projeto, uma vez que tal relação favorecerá o feedback acerca das entregas à medida que são realizadas, o que garante que o backlog do produto reflita suas necessidades atuais. Os métodos adaptativos geralmente são preferidos quando se lida com um ambiente em rápida mutação, quando os requisitos e escopo são difíceis de definir antecipadamente e quando é possível definir pequenas melhorias incrementais que entregarão valor às partes interessadas. (PMI, 2013, p. 45-46).

2.5.3 Gestão 3.0 ―O Século XXI é o Século da Complexidade.‖ Stephen Hawking

Na década de 80, o aumento da necessidade de algumas organizações por projetos mais rápidos serve como incubadora para o desenvolvimento dos métodos ágeis. E a partir da década de 90, com a Revolução da Informação, temos o surgimento de uma demanda cada vez maior por projetos com resultados cada vez mais rápidos, com maior qualidade e custos reduzidos. Neste contexto surge a teoria da complexidade, teoria dos sistemas adaptativos complexos.

2.5.3.1 Teoria da Complexidade

Durante séculos, a humanidade sempre teve uma visão newtoniana, acreditando em uma realidade linear, regulada por conceitos de causas e efeitos, e movimentos previsíveis como as leis da mecânica clássica. Assim, a administração Taylorista acredita que é uma questão de tempo até encontrarmos todas as fórmulas que regulam o trabalho e a produtividade. Segundo Ponchirolli (2007), Por três séculos, desde Isaac Newton, os cientistas descreveram o mundo como semelhante a uma máquina. Governando o mundo estavam os princípios de regularidade e ordem. Todas as coisas eram a soma das partes; as causas e efeitos estavam ligados linearmente; e os sistemas moviam-se de modo determinístico e previsível. É claro que os cientistas desde longo tempo estavam atentos para os fenômenos que contradiziam a lógica linear: as formas espirais das chamas de fogo, os redemoinhos em correntes e as formações de nuvens, por exemplo, não podiam ser representadas por simples equações lineares. O desenvolvimento da teoria do caos nos anos 70 e 80 sugeriu um modelo muito diferente para a maneira como as coisas ocorrem. O mais importante avanço das últimas décadas do século 20 foi a percepção de que o mundo é fundamentalmente não-linear. (PONCHIROLLI, 2007, p 83)

Acreditando nesta mesma visão linear da realidade, na década de 60, o meteorologista Edward Lorenz, do Instituto de Tecnologia do Massachusetts (MIT – Massachusetts Institute of Technology), desenvolveu um modelo computacional com os principais fatores que provocavam mudanças climáticas, tendo como objetivo a previsão de um longo período de tempo. No entanto, em sua pesquisa, Lorenz descobriu que pequenos erros ou pequenas variáveis produziam resultados desproporcionais no resultado final. Estas alterações quando ocorriam, por pequenos períodos, não apresentavam grandes mudanças, mas em períodos maiores causavam grandes alterações. E chamou sua descoberta, em um artigo publicado em 1979, de ―Efeito Borboleta‖. Este artigo e outros estudos sobre a equação não-linear, feitas pelo matemático James A. Yorke e pelo biólogo Robert May, além de questões nãolineares como a variação do preço de venda do algodão, estudada por Benoit Mandelbrot, serviram como base para a Teoria do Caos. Em meados da década de setenta, o físico Mitchell Feigenbaum começa a perceber que muitos sistemas não-lineares, aparentemente não relacionados,

comportam-se de modos claramente semelhantes. O que sugere que deveria existir uma teoria unificada para explicar o comportamento caótico dos sistemas e equações em uma faixa ampla de setores, de onde surge a Teoria do Caos. Com esta nova visão da realidade surge a Teoria da Complexidade, entendendo que a realidade é não linear, caótica, fractal, catastrófica, difusa e inacabada, um eterno e caótico fluir, reconhecendo a incompletude da nossa interpretação e a incerteza da realidade, bem como as múltiplas conexões entre os componentes dessa. Portanto, examinar isoladamente um componente do todo não faz sentido – é o reducionismo das partes. Devemos examinar, também, os relacionamentos deste componente com os demais e com o global constituído por todos eles. Examinar somente o global sem examinar os seus componentes e os relacionamentos, também não faz sentido – é o reducionismo do todo. Acerca da complexidade das relações sistêmicas, Capra (1996) afirma que: Quanto mais estudamos os principais problemas de nossa época, mais somos levados a perceber que eles não podem ser entendidos isoladamente. São problemas sistêmicos, o que significa que estão interligados e são interdependentes. (CAPRA, 1996, p.14).

E ainda,

Antes da década de 40, os termos ''sistema" e "pensamento sistêmico" tinham sido utilizados por vários cientistas, mas foram as concepções de Bertalanffy de um sistema aberto e de uma teoria geral dos sistemas que estabeleceram o pensamento sistêmico como um movimento científico de primeira grandeza. Com o forte apoio subseqüente vindo da cibernética, as concepções de pensamento sistêmico e de teoria sistêmica tornaram-se partes integrais da linguagem científica estabelecida, e levaram a numerosas metodologias e aplicações novas — engenharia dos sistemas, análise de sistemas, dinâmica dos sistemas, e assim por diante. Ludwig von Bertalanffy começou sua carreira como biólogo em Viena, na década de 20. Logo juntou-se a um grupo de cientistas e de filósofos, internacionalmente conhecidos como Círculo de Viena, e sua obra incluía temas filosóficos mais amplos desde o início. A semelhança de outros biólogos organísmicos, acreditava firmemente que os fenômenos biológicos exigiam novas maneiras de pensar, transcendendo os métodos tradicionais das ciências físicas. Bertalanffy dedicou-se a substituir os fundamentos mecanicistas da ciência pela visão holística. (CAPRA, 1996, p.43).

Sobre o mesmo tema, Morin (2005) salienta que: A complexidade tem como objetivo tentar compreender os fenômenos estudados pelos diferentes ramos do conhecimento não apenas através de um conhecimento especifico mas sim através de uma percepção obtida ao

integrar diferentes formas de se pensar ao estudar um mesmo assunto. (MORIN, 2005) Até então no estudo das ciências o conhecimento era dividido e abordado sob diferentes ângulos por cada partição. A fim de se estudar e chegar a proposições formais parâmetros eram ignorados ou simplificados. Do ponto de vista da complexidade essa simplificação faz com o universo observado não seja, de fato, o real. Ao mesmo tempo que observar mesmos fenômenos sem considerar o caráter multidisciplinar intrínseco ao fenômeno afasta ainda mais da realidade. (MORIN, 2005)

2.5.3.2 O modelo Cynefin

Em 1999, Dave Snowden, gestor ligado às áreas de conhecimento e estratégia organizacional do Instituto de Gestão do Conhecimento da IBM propõe o modelo Cynefin, um quadro para ajudar os líderes a determinar o contexto operacional predominante para poderem tomar decisões adequadas. Este modelo classifica os problemas em quatro contextos: simples, complicado, complexo e caótico, assim: Os contextos Simples e Complicado assumem um universo ordenado, onde as relações de causa e efeito são perceptíveis, e as respostas corretas podem ser determinadas com base nos fatos. O contexto Simples é o domínio das melhores práticas, no qual a relação entre causa e efeito é evidente para todos, sendo caracterizado pela estabilidade. Nesse contexto a abordagem utilizada para resolução de problemas é: Sentir (entender), categorizar (escolher a alternativa com base em protocolos e/ou procedimentos) e responder. O contexto Complicado é o domínio dos especialistas, no qual a relação entre causa e efeito exige uma análise mais aprofundada, o que às vezes necessita de conhecimentos específicos. Diferentemente do simples, o contexto complicado pode conter diversas respostas corretas, embora haja uma clara relação entre causa e efeito, porém nem todos conseguem enxergar. Nesse contexto, a abordagem utilizada é: Sentir, analisar (para escolher a melhor alternativa ou boa prática) e responder. Os contextos Complexo e Caótico não são ordenados, não há relação imediatamente aparente entre causa e efeito e o caminho a seguir é determinado com base em padrões emergentes e intuição. O contexto Complexo é o domínio da emergência, no qual as relações entre causa e efeito só podem ser percebidas em retrospecto, mas não antes. Nesse contexto, é impossível descobrir uma resposta certa. A abordagem adotada é: sondar (probe), sentir (entender) e responder. Aqui o desconhecido predomina sobre o conhecido, o que exige levantamento de fatos antes da tomada de decisão, visando minimizar a imprevisibilidade. O contexto Caótico é o domínio da resposta rápida, no qual não existe uma relação entre causa e efeito ao nível de sistema. Buscar uma resposta certa é inútil. É impossível determinar a relação entre causa e efeito, pois esta sofre mudança constante e não há padrões controláveis. Aqui a abordagem é: Agir, sentir e responder. Nesta situação não se sabe nada e nem se

consegue saber. O contexto, o sistema e as condições de contorno estão sem restrições, não existe nenhuma previsibilidade e também não existem maneiras de mensuração. É uma oportunidade de se realizar uma mudança radical. (GRANDO, 2013)

A figura 32 ilustra os quadros utilizados no modelo Cynefin, com seu contexto, domínio, modo de gestão, intervenções a serem aplicadas e a abordagem característica de cada contexto.

Figura 32: Modelo Cynefin adaptado de Dave Swonden, 1999.

Fonte: (GRANDO, 2013).

100

2.5.3.3 Sistemas Adaptativos Complexos ―As organizações são vistas como máquinas, mas deveriam ser vistas como organismos vivos‖ Gareth Morgan

De acordo com Garrido (2014, p.19), ―Mesmo quando desenhadas como hierarquias, as organizações são de fato redes, com complexa dinâmica social. Gestão é sobre pessoas e seus relacionamentos e não sobre departamentos e lucros.‖ Um time de desenvolvimento de projetos arquitetônicos é um sistema adaptativo complexo. E, para a sua auto-organização, devemos pensar o sistema organizacional como um sistema vivo, oscilando entre dois momentos: o momento aberto, em que o time de desenvolvimento interage com as solicitações e comentários dos clientes e usuários do produto; e um momento fechado, no qual a equipe trabalha focada para a entrega do próximo incremento. O desenvolvimento do projeto, levando em consideração estes dois momentos, é fundamental para que a equipe tenha a liberdade na tomada de decisões no seu momento fechada e tenha sempre um deliveryble de importância e valor reconhecidos pelo cliente para a sua análise no momento aberta.

2.5.3.4 Desconhecido-Conhecido e Desconhecido-Desconhecido

Devemos

considerar

conceitos

Conhecido-desconhecido

Desconhecido-desconhecido, a fim de organizar os eventuais riscos em função de sua identificação, assim: Conhecido-desconhecido — Riscos identificados, mas que pela própria definição de risco não sabemos se ocorrerão. Para proteger o projeto dos riscos conhecidos-desconhecidos, os gerentes de projetos devem planejar as respostas e incluir uma reserva de contingência para os riscos residuais. Desconhecido-desconhecido — Riscos que não foram, ou não podiam ser, identificados no projeto. Para proteger o projeto dos riscos desconhecidos-desconhecidos, o orçamento de projeto deve incluir uma reserva gerencial determinada com base na experiência de projetos passados. (MOURA, 2013, p. 224)

101

Podemos representar a relação entre os níveis de complexidade e incerteza versus a possibilidade de planejamento e o gerenciamento da elaboração do produto, através da figura abaixo adaptada de Salles et al., (2006) (apud Lopes, 2015, p. 24), que mostra que quanto maior o nível de incerteza maior a importância da adoção de um método ágil. Neste contexto começa a surgir uma nova onda no gerenciamento, a Gestão 3.0, com os Métodos Ágeis, que valorizam mais as pessoas do que os projetos. Mantendo o comprometimento com o projeto e, buscando através da sinergia de toda a equipe de projeto, atingir melhores resultados em projetos complexos, adaptativos, iterativos e incrementais.

Figura 33: Níveis de complexidade e incerteza versus possibilidade de planejamento e o gerenciamento de elaboração do produto, Análise de complexibilidade, elaborada sobre base de gerência de riscos adaptada de Salles et al., (2006) (apud Lopes, 2015, p. 24).

Fonte: Lopes (2015).

102

2.5.3.5 Movimento Ágil

Na indústria do software, a necessidade por entregas rápidas de novos produtos muitas vezes era inviabilizada, devido à utilização de um planejamento em cascata. O projeto era pensado de maneira linear, em que pese o planejamento como sendo realizado totalmente no início, depois viria a execução do projeto e, por fim, sua entrega. No entanto, este processo gerava inúmeros documentos e procedimentos muitas vezes burocráticos, que comprometiam a velocidade de desenvolvimento do software, tornando-o obsoleto antes do seu lançamento. Foi no ano de 2001 que 17 profissionais representantes de métodos de desenvolvimento de software se reuniram para comparar seus métodos e discutir suas diferenças e semelhanças e, com a complementação de suas práticas, identificaram um consenso de ideologia. Tais valores estavam voltados para um gerenciamento focado em eficiência e eficácia, que intitularam de ―Ágil‖. Como nos projetos de desenvolvimento de softwares (projetos adaptativos, iterativos e incrementais) ocorrem, com grande frequência, mudanças no projeto; haja vista que lidar com as mudanças seja um dos principais pontos debatidos. Além disso, foram percebidos quatro valores que serviram de base para os 12 princípios ágeis e para o Manifesto ágil.

2.5.3.6 4 Valores do Manifesto Ágil

Segundo Jeff Sutherland et al (2001), o Manifesto Ágil está pautado sobre estes quatro valores, uma vez que tais premissas colaboram para a geração de resultados a partir de uma abordagem construtivista que contempla pessoas, ambientes e produtos de maneira equilibrada. São eles: •

A busca mínima de documentação e pelo processo necessário e suficiente;

•

A alta importância dada às pessoas e as comunicações entre elas;

•

O maior foco no cliente e na sua participação direta no ambiente de projeto;

•

Uma entrega frequente e de valor conhecido e esperado pelo cliente.

103

O que se tem a partir destes pontos é a determinação de uma escala de valores em que os movimentos de colaboração e versatilidade importam mais do que o rigor de certos processos e do planejamento clássicos.

2.5.3.7 12 Princípios por trás do Manifesto Ágil

Foram também propostos por Jeff Sutherland et al (2001), 12 princípios que orientam o Manifesto Ágil. São eles:           

Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. Software funcionando é a medida primária de progresso. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Contínua atenção à excelência técnica e bom design aumenta a agilidade. Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é essencial. (SUTHERLAND et al, 2001)

Desta forma podemos notar um alinhamento por um processo mais enxuto, adaptado a mudanças, a valorização de prioridades, a auto-organização, a motivação intrínseca, e de forma clara e transparente.

104

2.5.3.8 Manifesto para o desenvolvimento ágil de software

Conforme o exposto acerca do movimento ágil, observa-se que seus signatários o formularam a partir de pontos comuns que perceberam ao longo de projetos exitosos, que tinham por premissa a aproximação do negócio às pessoas envolvidas, assim prega o Manifesto para o Desenvolvimento Ágil de Software: Estamos descobrindo maneiras melhores de desenvolver software fazendoo nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano. Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. (SUTHERLAND et al, 2001)

Este manifesto proporciona uma mudança de paradigma, no qual a comunicação e interação da equipe, a obtenção de resultados, a transparência do processo e a capacidade de adaptação às mudanças são valorizadas. Criando a possibilidade para as utilizações em projetos complexos, adaptativos, iterativos e incrementais. Figura 34: Manifesto para o desenvolvimento ágil de software.

Fonte: SBOK (2013) adaptado de (Jeff Sutherland et al, 2001).

105

2.5.3.9 Método Toyota – Lean Thinking

No final da década de 80, ao desenvolver um estudo sobre a indústria automobilística, o Massachusetts Institute os Technology – MIT identificou na Toyota um sistema de gestão que pode ser entendida como uma filosofia que deve estar presente em toda a organização e foi intitulado de Lean, ou seja, ―enxuto‖. Assim, A filosofia conhecida como Lean Thinking (mentalidade enxuta) busca de forma consciente:  Agregar valor ao produto com custos mais baixos.  Melhoria contínua de fluxos primários e secundários.  Envolvimento de pessoas qualificadas, modificadas e com iniciativa. (LOPES, 2015, p. 20)

2.5.3.10

Lean Software Development

De acordo com Lopes (2015, p. 20), em 2003, Mary e Tom Poppedieck organizaram sete princípios que podem ser aplicados ao desenvolvimento de software e em outros ambientes de projetos complexos, adaptativos, incrementais e iterativos. Estes princípios ficaram conhecidos como Lean Software Development e pregam que se 1. Elimine desperdícios; 2. Crie conhecimento; 3. Flexibilize decisões e planejamento; 4. Entregue o quanto antes; 5. Dê autonomia à equipe; 6. Seja transparente; 7. Veja o todo.

2.5.3.11

Design Thinking

Para a criação e gestão de projetos inovadores devemos considerar o conceito do Design Thinking, que propõe um desenvolvimento com foco em 5

106

principios, a criação deve estar focada no usuário, deve ser desenvolvida por uma equipe

multidisciplinar,

cocriação

com

usuários,

soluções

iterativas

desenvolvidas através de protótipos para a verificação da aceitação do produto por parte dos clientes. Acerca do Design Thinking, Pinheiro e Alt (2011) ao serem citados por Lopes (2015) afirmam que O método que ficou conhecido com Design Thinking propõe um processo centrado no usuário, com equipes multidisciplinares, prazo bem definido e prototipagem. A ideia é desenvolver a criatividade focada no problema e gerando soluções inovadoras, sejam estes problemas de gestão de empresas, estratégia, educação ou qualquer outro. (LOPES, 2015, p. 47-48)

2.5.3.12

Lean Construction

Segundo Koskela et al. (2002), citado por Pissara (2010, p. 79) o conceito de produção Lean baseia-se nos princípios do trabalho em equipe, comunicação, uso eficiente de recursos, eliminação dos desperdícios e melhoria continua. Sendo os onze princípios simplificadores que buscam a melhoria dos processos do projeto, denominados Lean Construction e que têm alicerçado os estudos da construção civil, são os seguintes: 1. Aumentar o valor do produto através da consideração dos requisitos dos clientes; 2. Reduzir o tempo do ciclo; 3. Reduzir a parcela de actividades que não agregam valor; 4. Simplificar através da redução de passos, partes e ligações; 5. Focar o controlo do processo global; 6. Manter o equilíbrio entre melhorias de fluxo e nas conversões; 7. Reduzir a variabilidade; 8. Aumentar a transparência do processo; 9. Aumentar a flexibilidade do trabalho final; 10. Introduzir melhoria contínua no processo; 11. Fazer benchmarking. (PISSARA, 2010, p. 79)

A partir destes onze princípios norteadores, os profissionais da construção civil são convocados a quebrar antigos paradigmas, adaptando o instrumental produzido com sucesso pelo método Toyota de produção, adequando conceitos de fluxo e geração de valor, presentes no pensamento enxuto. O resultado disto é a viabilização de sistemas de informação e métodos que propiciem a estabilização de

107

um cenário produtivo, tendo como característica a antecipação de problemas em um universo de ocorrência de alto grau de incertezas.

2.5.3.13

Conceitos de Gestão 3.0

Em 2011, Jurgen Appelo, lança seu livro ―Management 3.0: Leading Agile Developers, Developing Agile Leaders‖, criando o conceito de ―Management 3.0‖ ou Gestão 3.0. De acordo com Appelo (2011), o ―Management 3.0‖ ou Gestão 3.0, não é uma metodologia, mas um novo modo de pensar. Não existe uma sequência prédefinida e podem existir visões diferentes sobre um mesmo ponto, uma vez que se propõe a gerenciar pessoas para atingir resultados em projetos complexos, adaptativos, iterativos e incrementais. Um ponto em destaque das mudanças propostas pelo Management 3.0 é a forma de atuação do gestor ou líder, que é descrita pela metáfora de um jardineiro: O Conceito de gestor jardineiro é interessante, pois segundo o conceito, o jardineiro não atua diretamente na planta para promover o seu florescimento, mas no ambiente necessário para que isso aconteça. Portanto, partindo desta analogia, o gestor deve cuidar dos estímulos e entradas necessárias para que o time atue por auto-organização, buscando sempre estimular e fornecer as condições necessárias para maximizar seus pontos fortes e oportunidades e minimizar ou eliminar seus pontos fracos e ameaças. O Gestor jardineiro precisa inspirar o time a trabalhar dentro de algumas restrições para atingir determinados objetivos e resultados; porém, dando abertura para que os participantes dos times possam colaborar para o desenvolvimento de um ambiente de trabalho o mais próximo do ideal. Assim, a motivação da equipe é o grande diferencial. Apesar de muitas organizações acreditarem que um plano de bônus e benefícios motivam a equipe, o Management 3.0 entende que através deste estimulo, só conseguiria uma motivação extrínseca e não uma intrínseca, que é a que realmente faz com que as pessoas trabalhem ativas, criativas e motivadas. Deste modo, cria-se um ambiente transparente

colaborativo,

incentivando

pessoas

assumirem

108

responsabilidades sobre suas decisões, ao passo que se desenvolve um perfil multidisciplinar de atuação. Entende-se que os erros devem ser sempre evitados, mas fazem parte do processo do desenvolvimento de projetos complexos. No entanto, quando diagnosticados, mais importante do que punir o culpado, o gestor deve direcionar para que sejam solucionados por todo o time e serem revistos como lições aprendidas, nas quais se almeja o amadurecimento e capacitação de toda a equipe. Um ponto importante é o número de participantes da equipe, geralmente em equipes com um grande número de pessoas, a comunicação entre o time tende a não ocorrer com fluidez e pouco ruído, já que naturalmente e informalmente as pessoas tem uma tendência de formar grupos de aproximadamente 5 pessoas. Portanto, os métodos ágeis propõem equipes menores, de 5 a 8 pessoas. Valorizando também a diversidade do time por acreditar que tal peculiaridade proporciona

mais

aprendizados

ocorrência

diversificação

assuntos/propostas. Outro ponto a ser destacado é o fato de muitas organizações, atualmente, já adotam práticas de auto-organização, sendo que os métodos ágeis servem para elevar os níveis desta auto-organização.

2.5.3.13.1

As 6 Visões da Gestão 3.0.

Em 2011, Jurgen Appelo, em seu livro Management 3.0: Leading Agile Developers, Developing Agile Leaders propõe seis visões no management 3.0, são elas: •

Energise people - Energizar as Pessoas: Levando em conta que as pessoas são a parte mais importante das organizações, os gerentes devem estimulalas

para

mantê-las,

ativas,

criativas

motivadas.

Identificando

personalidades que compõem a sua equipe e quais seus fatores motivadores. •

Empower teams - Empoderar Times: Com grandes poderes vem grandes responsabilidades. Se nós queremos que nossos times tenham autoorganização,

pro-atividade

outros

comportamentos

time

109

extraordinário, então é preciso conceder poder a eles, delegando poder, dando autorização e confiança. •

Align Constrains - Alinhar Restrições: As restrições sempre são importantes para guiar e alinhar o interesse de todos os envolvidos. Visto que, por mais engajadas que as pessoas estejam, se o foco não for único, toda ação tomada pode ser em vão. A equipe deve ter sempre propósitos claros e metas definidas.

•

Develop competence - Desenvolver Competências: É muito importante conhecer as pessoas para ajudá-las a desenvolverem suas competências.

•

Grow structure - Crescer a Estrutura: Crescer é o objetivo de quase toda empresa, mas para manter o conceito de valorizar as pessoas e suas interrelações, antes de um crescimento devemos pensar: Por que queremos crescer? Precisamos realmente crescer? E depois disso respondido, precisamos ter muito cuidado para crescer sem perder a forma e os valores cultivados pela empresa.

•

Improve everything - Melhorar Tudo: Define que pessoas times e organizações precisam melhorar constantemente para evitar a ocorrência de falhas pelo maior tempo possível. Inspeção e adaptação constantes são necessárias para garantir uma evolução para o sucesso.

Figura 35: Martie, a ilustração Jurgen Appelo mostrando as 6 visões da Gestão 3.0.

Fonte: (APPELO, 2011).

110

2.6

Teoria relacionada ao Scrum

2.6.1 Introdução ao Scrum

Em 1991, Ken Schwaber e Jeff

Sutherland, que havia participado

anteriormente do Manifesto Ágil, desenvolveram as bases para uma estrutura de trabalho intitulada Scrum e lançam o Guia do Scrum, uma obra aberta que vem sendo revisada e atualizada regularmente. A escolha do nome Scrum para esta estrutura de trabalho surgiu a partir de uma analogia feita de um artigo de 1986, de autoria de Nona e Takeuchi, no qual eles comparam as equipes multifuncionais e de alto desempenho com a formação Scrum do rúgbi A analogia analisa a os critérios de auto-organização, de velocidade e do senso de urgência das equipes de rúgbi ao reiniciar a partida. Chamei de ―Scrum‖ essa estrutura de desempenho de equipe. O termo vem do jogo de rúgbi e se refere à maneira como um time trabalha junto para avançar com a bola no campo. Alinhamento cuidadoso, unidade de propósito, clareza de objetivo, tudo se unindo. Trata-se de uma metáfora perfeita para o que uma equipe deseja fazer. [...] O Scrum acolhe a incerteza e a criatividade. Coloca uma estrutura em volta do processo de aprendizagem, permitindo que as equipes avaliem o que já criaram e, o mais importante, de que forma o criaram. A estrutura do Scrum busca aproveitar a maneira como as equipes realmente trabalham, dando a elas as ferramentas para se auto-organizar e, o mais importante, aprimorar rapidamente a velocidade e a qualidade de seu trabalho. Em essência, o Scrum tem como base uma ideia simples: ao começar um projeto, por que não fazer paradas regulares para verificar se o que está sendo feito está seguindo na direção certa, e se, na verdade, os resultados são os que as pessoas desejam? E verificar se existem maneiras de aprimorar a forma como se está trabalhando para obter resultados melhores e executados mais rapidamente, e quais seriam os obstáculos que impedem as pessoas de obtê-los. Isso é chamado de ciclo de ―Inspeção e Adaptação‖. De tempos em tempos, pare de fazer o que está fazendo, revise o que já fez e verifique se ainda deveria estar fazendo aquilo e como você pode fazê-lo melhor. É uma ideia simples, mas executá-la exige reflexão, introspecção, honestidade e disciplina. (SCHWABER; SUTHERLAND, 2014, p. 12-13)

No rúgbi, o Scrum ou ―formação ordenada‖ é uma situação que geralmente ocorre após uma penalização ou jogada irregular, para a reposição da bola em jogo. Então é feita uma formação, o Scrum (como pode ser visto na figura 36), na qual os oito jogadores avançados das duas equipes, colocam-se em uma posição em três linhas formando um túnel, onde no meio dele será reposta a bola em jogo pelo jogador do time que sofreu a falta. O objetivo é recuperar a bola que voltará a jogo.

111

E para o sucesso desta jogada ficam evidentes fatores fundamentais tais como, a união dos integrantes e o foco do time com um objetivo único, além da autoorganização do time. Desta forma, destaca-se a importância do comprometimento de todos os envolvidos da equipe e que qualquer deslize ou fraqueza de qualquer envolvido fará com que os objetivos não sejam alcançados, prejudicando todo o grupo.

Figura 36: Formação scrum no jogo de rúgbi.

Fonte: Lopes (2015).

Figura 37: Formação Scrum no jogo de rúgbi.

Fonte: Google imagens (http://blogs.independent.co.uk/wp-content/uploads/2011/09/scrum1.jpg)

Podemos fazer a mesma analogia com relação à equipe de projeto, já que quando um integrante está fora de sintonia com os demais, prejudica toda a equipe, refletindo nos resultados de todos e não apenas no seu, especificamente.

112

De acordo com o Guia do Scrum, de Ken Schwaber (2013), desde a década de 90 o Scrum vem sendo utilizado no desenvolvimento de produtos complexos. Atualmente o Scrum é utilizado por grandes empresas como a Microsoft, Yahoo, Google, Eletronic Arts, Philips, Siemens, Nokia, BBC, Time Warner, entre outras grandes empresas.

2.6.2 Definição do Scrum Segundo Sabbagh (2013, p. 17), “Scrum é um framework ágil, simples e leve, utilizada para a gestão do desenvolvimento de produtos complexos imersos em ambientes complexos”. Ou seja, é uma caixa de ferramentas que tem como função a organização e o gerenciamento de trabalhos complexos, na qual pode-se tratar e resolver problemas de demandas complexas e adaptativas, ao passo que se pode entregar de forma criativa o produto, com alto valor. Para Cruz (2015, p. 43), “A principal ideia do Scrum é controlar processos empíricos, mantendo o foco na entrega de valor de um negócio no menor tempo possível”. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013), [O] Scrum não é um processo ou uma técnica para construir produtos; em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las. O framework Scrum consiste nos times do Scrum associadas a papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum. As regras do Scrum integram os eventos, papéis e artefatos, administrando as relações e interações entre eles. [...] As estratégias específicas para o uso do framework Scrum variam e são descritas em outros documentos. (SCHWABER; SUTHERLAND, 2013 p. 3)

A partir dos valores e atitudes adotadas, tem-se uma organização cujas práticas de engenharia e gestão são condizentes com as necessidades do empreendimento; ou seja, o Scrum possibilita a aplicação de métodos relevantes à empresa e que garantem a exclusividade do projeto.

113

2.6.3 Teoria do Scrum

Para projetos muito complicados, complexos ou caóticos, o Scrum apresenta uma metodologia mais eficiente para lidar com incertezas e possíveis mudanças, uma vez que desenvolve o projeto de maneira incremental priorizando os objetivos de maior valor. Para Lopes (2015, p. 25), ―Quanto mais simples o contexto, mais confortáveis ficamos com os métodos preditivos, aqueles que se propõem o planejamento detalhado logo no início do projeto. Quanto maior o nível de incerteza e a complexidade do ambiente, mais valor pode ser observado ao uso do Scrum‖.

Figura 38: Níveis de complexidade e incerteza versus possibilidade de planejamento e o gerenciamento de elaboração do produto, Análise de complexibilidade, elaborada sobre base de gerência de riscos adaptada de Salles et al., (2006) (apud Lopes, 2015, p. 24).

Fonte: Lopes (2015).

114

2.6.4 Os Princípios do Scrum

De acordo com o SCRUMStudy, (2013, p. 9) podemos considerar 6 princípios do Scrum, que devemos considerar como as diretrizes fundamentais para a aplicação da metodologia e que devem ser utilizados em todos os projetos com esta abordagem. São eles: 1. Controle de Processos Empíricos 2. Auto-organização 3. Colaboração 4. Priorização Baseada em Valor 5. Time-boxing 6. Desenvolvimento Iterativo

2.6.4.1 Controle de Processos Empíricos Segundo Cruz (2015, p. 46), ―O Scrum controla processos empíricos empregando uma abordagem iterativa e incremental para otimizar a previsibilidade e o controle de riscos‖. Tal conceito corrobora com o fato de que o Scrum se fundamenta a partir do empirismo, ou seja, do conhecimento que é proveniente da experiência que se adquire através de tentativas, levando-se em conta os acertos e os erros, além das escolhas feitas a partir daquilo que se conhece, assumindo uma abordagem interativa e progressiva para dar conta de fatores como a previsibilidade e o manejo de ameaças. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013, p. 4), os três pilares que sustentam a implementação de controle do processo empírico são “a transparência, a inspeção e a adaptação”.

2.6.4.1.1 Os Pilares do Scrum

115

Os três pilares que apoiam o Scrum são: A transparência, no qual o pressuposto é o claro entendimento ao longo do processo e seu andamento. A inspeção, que dá conta do acompanhamento dos processos, que deve ser frequente, a fim de se evitar imprevistos. E a adaptação, que corresponde às correções pelas quais os eventuais ―desvios‖ devem ser submetidos. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013): Transparência: Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer aspectos definidos por um padrão comum para que os observadores compartilharem um mesmo entendimento do que está sendo visto. Inspeção: Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar. Adaptação: Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizar mais desvios. O Scrum prescreve quatro eventos formais, contidos dentro dos limites da Sprint, para inspeção e adaptação.  Reunião de planejamento da Sprint  Reunião diária  Reunião de revisão da Sprint  Retrospectiva da Sprint. (SCHWABER; SUTHERLAND, 2013, p.04)

Desse modo, a aplicação destes três elementos proporcionará a todos os sujeitos envolvidos, via papéis do Scrum, um olhar mais atento e claro sobre o processo, de modo que tal visibilidade evita insatisfações com o projeto que se conforma, além de atrasos devido a retrabalhos, a identificação de quaisquer desvios de meta e os retornos acerca dos processos, agregando valor e consistência gerencial ao projeto desenvolvido.

2.6.4.1.2 Os Valores do Scrum

De acordo com a Scrum Alliance (2015), além dos três pilares, devemos observar nos projetos gerenciados pelo método Scrum a existência de cinco valores que são propostos para orientar os processos, interações, boas práticas e o sucesso do projeto. São eles:

116

1. Foco – evitar multitarefa 2. Coragem – mudança é parte do processo 3. Franqueza – transparência par inspeção e adaptação 4. Compromisso – o time é responsável 5. Respeito – a opinião do outro, trabalhar junto exige compartilhar e ajudar. A partir do foco/concentração que se irá trabalhar com poucos itens, realizando uma coisa de cada vez e conjuntamente, de modo que se realize pequenas transferências de itens de valor, em menor prazo de tempo. A coragem pressupõe a demanda por tomadas de decisões, que são conferidas a todos os integrantes do time, tornando-os mais estimulados e desenvoltos nos momentos cruciais de deliberação. A abertura denota o processo de naturalização e da liberdade de comunicar-se, uma vez que a proximidade e a convergência de interesses e metas favorecem tal integração entre os participantes do time. O compromisso/responsabilidade é resultado da integração entre os participantes, que ao se considerarem engrenagens deste mecanismo, reconhecem e assumem suas atribuições, que resultarão em sucesso ou fracasso. Por fim, o respeito é a relação que se estabelece quando os integrantes do time trabalham juntos, em prol de uma causa comum e com espírito colaborativo, uma vez que o sucesso (ou fracasso) de um é o de todos. Assim, o resultado prático destes valores do Scrum nas equipes de desenvolvimento converte-se em grandes e favoráveis mudanças.

2.6.5 O time Scrum O Time Scrum é composto pelo Product Owner, o Time de Desenvolvimento e o Scrum Master. Times Scrum são auto-organizáveis e multifuncionais. Times auto organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora do time. Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. Times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades de realimentação. Entregas incrementais de produto ―pronto‖ garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível. (SCHWABER; SUTHERLAND, 2013, p. 4)

117

Um time Scrum tem a característica de ser auto-organizável e multidisciplinar, favorecendo a flexibilidade e a produtividade. O Scrum Master é o ―guardião‖ do processo Scrum e é quem orienta e treina a equipe, protegendo-a de interferências externas que possam afetar os trabalhos. Além de incentivar e promover as tomadas de decisões da equipe, de forma a zelar pelo progresso desta e do projeto. O Product Owner é o ―dono‖ do produto, aquele que favorece a interface entre o Time de Desenvolvimento e o cliente. É o profissional que define os requisitos dos produtos de acordo com as necessidades do cliente e a execução dos mesmos de acordo com o seu valor. O Time de Desenvolvimento é a equipe multidisciplinar que desenvolve e testa os produtos, geralmente em um número entre 3 a 9 pessoas, o time deve apresentar a característica da auto-organização, estando apto a determinar como será a divisão e a execução do trabalho por cada membro da equipe.

2.6.5.1 Product Owner (PO) – Dono do Produto De acordo com Lopes (2015, p. 26), ―Product Owner (PO) é o dono do produto. Faz a interface entre o cliente e o restante do Time e é o responsável por maximizar o valor do produto‖. Cabe a este profissional a maximização do valor do produto e do trabalho do Time de Desenvolvimento,

além de ser o profissional responsável pelo

gerenciamento do Backlog do produto, que inclui, entre outras demandas:  Expressar claramente os itens do Backlog do Produto;  Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;  Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;  Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,  Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário. (SCHWABER; SUTHERLAND, 2013, p. 5)

De acordo com Ken Schwaber e Jeff Sutherland (2013), o Product Owner pode executar as tarefas do Backlog ou delegá-las para que sejam executadas pelo Time de Desenvolvimento, ainda que permaneça sendo o responsável por este trabalho.

118

O poder de decisão deste profissional é soberano e toda a organização deve respeitá-lo. As resoluções referentes às escolhas e necessidades projetuais compreendidas pelo Product Owner são visíveis tanto no conteúdo quanto na priorização do Backlog do produto. Assim, conforme Ken Schwaber e Jeff Sutherland (2013, p. 6), “Ninguém tem permissão para falar com o Time de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem”.

2.6.5.2 O Time de Desenvolvimento Para Lopes (2015, p. 26), ―Equipe de desenvolvimento é composta por profissionais que elaboram o produto, que são auto-organizados. A responsabilidade pela produção é da equipe como um todo‖. São os profissionais do time de desenvolvimento que tem o papel de entregar ao cliente uma versão ―usável‖ do produto que, após cada reunião de avaliação, sofre alterações e incrementos. Tais equipes estão compostas e autorizadas para organizar e gerir seu próprio trabalho, cujo resultado eficaz se concretiza a partir da sinergia do grupo. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013), as características do time de desenvolvimento são:  Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;  Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.  O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra.  Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo;

119

 Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios. (SCHWABER; SUTHERLAND, 2013 p. 6)

Por se tratar de uma equipe que deve manter a agilidade de trabalho dentro dos limites da Sprint, espera-se que a quantidade de componentes não seja inferior a três ou superior a nove profissionais, uma vez que o número muito reduzido de integrantes diminui a interação, podendo ocasionar, eventualmente, restrições de habilidades, o que resulta na impossibilidade de entregar os incrementos esperados e, consequentemente, menores ganhos de produtividade. Já grupos com elevado número de integrantes requerem uma coordenação mais cuidadosa, haja vista que pode ocorrer prejuízos devidos a dispersões e comunicação ineficientes.

2.6.5.3 Scrum Master Segundo Lopes (2015, p. 26), o ―Scrum Master é o guardião do método, responsável por garantir que o Scrum seja entendido e aplicado. Ele é também um facilitador dentro do Time. Um indivíduo pode ser Scrum Master de mais de uma equipe. Este papel não deve se sobrepor, na mesma pessoa, ao do Product Owner‖. Este profissional tem como atribuição colaborar para aqueles que estão fora do Time Scrum compreendam qual seu papel nas interações com o time e quais são ou não úteis para que os propósitos do projeto sejam atingidos. Ken Schwaber e Jeff Sutherland (2013, p. 07) consideram que o Scrum Master atua como um ―servo-líder‖ para o Time Scrum, promovendo a mudança nas interações dos membros, de forma a maximizar o valor criado pelo Time Scrum. Outros encargos são atribuídos ao Scrum Master, a saber: O Scrum Master serve o Product Owner de várias maneiras, incluindo:  Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;  Claramente comunicar a visão, objetivo e itens do Backlog do Produto para o Time de Desenvolvimento;  Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;  Compreender a longo-prazo o planejamento do Produto no ambiente empírico;  Compreender e praticar a agilidade; e,  Facilitar os eventos Scrum conforme exigidos ou necessários.

120

O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo:  Treinar o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;  Ensinar e liderar o Time de Desenvolvimento na criação de produtos de alto valor;  Remover impedimentos para o progresso do Time de Desenvolvimento;  Facilitar os eventos Scrum conforme exigidos ou necessários; e,  Treinar o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido. O Scrum Master serve a Organização de várias maneiras, incluindo:  Liderando e treinando a organização na adoção do Scrum;  Planejando implementações Scrum dentro da organização;  Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico;  Causando mudanças que aumentam a produtividade do Time Scrum;  Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum nas organizações. (SCHWABER; SUTHERLAND, 2013, p. 07)

Na figura 39, a seguir, temos uma esquematização dos papéis e atribuições ocupados por cada profissional do Scrum.

Figura 39: Visão Geral dos Papéis do Scrum

Fonte: Adaptado de (SCRUMStudy, 2013).

2.6.5.4 Auto-organização

De acordo com o SCRUMStudy (2013, p. 27), os profissionais envolvidos no Scrum são auto-motivados e buscam assumir responsabilidades cada vez maiores, oferecendo um valor maior quando isso ocorre. De modo que a ―liderança servidora‖

121

é o estilo preferido em Scrum, uma vez que tem ênfase na obtenção de resultados e foco nas necessidades do Time Scrum. O fato que faz com que o Scrum seja autoorganizado não autoriza que seus membros ajam deliberadamente, de acordo com suas crenças e desejos. Significa, tão somente que, definida a Visão do Produto a partir da criação da Visão do Projeto, o Dono do Produto, o Scrum Master e o Time Scrum são identificados. Assim, enquanto princípio essencial em Scrum, a autoorganização conduz o profissional ao

Time buy-in e à responsabilidade

compartilhada, à motivação, que produz níveis de melhor desempenho do time e a um ambiente inovador e criativo, propenso ao crescimento. Os principais objetivos de times auto-organizados são: Compreender a Visão do Projeto, e por que o projeto agrega valor à organização; Estimar Estórias de Usuário durante o processo de Aprovar, Estimar e Comprometer as Estórias de Usuário, e atribuir tarefas a si mesmos durante o processo de Criar o Backlog do Sprint; Criar tarefas de forma independente durante o processo de Criar as Tarefas Aplicar e aprimorar os seus conhecimentos por ser um time multifuncional, para trabalhar nas tarefas durante o processo de Criar Entregáveis; Entregar resultados tangíveis que são aceitos pelo cliente e pelos stakeholders durante o processo de Demonstrar e Validar o Sprint; Resolver em conjunto problemas individuais abordados durante as Reuniões Diárias; Esclarecer quaisquer discrepâncias ou dúvidas e estar aberto para aprender coisas novas; Atualizar o conhecimento e a habilidade de forma contínua por meio de interações regulares do time; Manter a estabilidade dos membros do time durante toda a duração do projeto, não alterando os membros, a menos que seja inevitável. (SCRUMStudy, 2013, p. 28)

2.6.5.5 Colaboração

A colaboração em Scrum diz respeito à interação e trabalho em conjunto entre o Time Central do Scrum e os Stakeholders, de modo que possam criar e validar as entregas dos projetos, a fim de que se atinja os objetivos esboçados na Visão do Projeto. SCRUMStudy (2013) chama a atenção para a diferenciação entre colaboração e cooperação, uma vez que esta ocorre quando o resultado do trabalho é fruto da soma dos esforços de várias pessoas em um time, ao passo que aquela

122

refere-se a um time que trabalha conjuntamente, em sua totalidade, contribuindo para produzir algo maior. São, pois, as dimensões principais do trabalho colaborativo: Consciência—Os indivíduos que trabalham juntos precisam estar cientes do trabalho um do outro. Articulação—Os colaboradores devem dividir o trabalho em unidades, dividir as unidades entre os membros do time, e em seguida, assim que o trabalho for concluído, devem reintegrá-lo. Apropriação—Adaptação de tecnologia para a própria situação; a tecnologia pode ser usada de uma maneira completamente diferente do que esperado pelos designers. (SCRUMStudy, 2013, p. 29)

2.6.5.5.1 Benefícios da Colaboração em Projetos Scrum De acordo com o SCRUMStudy (2013): O Manifesto Ágil (Fowler e Highsmith, 2001) enfatiza a "colaboração do cliente acima da negociação de contrato." Assim, o framework Scrum adota uma abordagem em que os membros do Time Central do Scrum (Dono do Produto, Scrum Master e Time Scrum), colaboraram uns com os outros e com os Stakeholders para criar os entregáveis que proporcionem o maior valor possível para o cliente. Essa colaboração ocorre durante todo o projeto. A colaboração garante que os seguintes benefícios do projeto sejam realizados: 1. A necessidade de mudanças devido a requisitos mal esclarecidos são minimizadas.(...) 2. Os riscos são identificados e tratados de forma eficiente.(...) 3. O verdadeiro potencial do time é realizado.(...) 4. A melhoria contínua é assegurada através de lições aprendidas.(...) . (SCRUMStudy, 2013, p. 31)

2.6.5.6 Priorização baseada em valor

Um dos principais objetivos do Scrum é oferecer o maior valor de negócio e no menor tempo possível, para isto está focado na priorização. Desta forma, a definição sobre quais atividades devem ser feitas agora ou mais tarde são realizadas a partir do valor de negócio reconhecido pela atividade. De acordo com o SCRUMStudy (2013)

123

O framework Scrum é impulsionado pelo objetivo de oferecer o máximo valor de negócio em um período de tempo mínimo. Uma das ferramentas mais eficazes para realizar esse objetivo é a priorização. A Priorização pode ser definida como a determinação da ordem e da separação do que deve ser feito agora, a partir do que precisa ser feito mais tarde. O conceito de priorização não é novidade em gerenciamento de projetos. O modelo tradicional de gerenciamento de projetos (Waterfall), propõe a utilização de várias ferramentas de priorização de tarefas. Do ponto de vista do Gerente do Projeto, a priorização é fundamental, já que certas tarefas devem ser realizadas primeiro para agilizar o processo de desenvolvimento e alcançar os objetivos do projeto. Algumas das técnicas tradicionais de priorização de tarefas, incluem os prazos de definição para tarefas delegadas e a utilização de matrizes de priorização. O Scrum, no entanto, usa a Priorização Baseada em Valor como um dos princípios fundamentais que impulsiona a estrutura e funcionalidade de todo o framework Scrum, ajudando os projetos a se beneficiarem através da adaptabilidade e desenvolvimento iterativo do produto ou serviço. Mais significativamente, o Scrum tem como objetivo, entregar um produto ou serviço de valor para o cliente durante todas as fases do projeto.(...) O Dono do Produto deve trabalhar simultaneamente, com o Time Scrum para entender os riscos e as incertezas do projeto, pois podem haver consequências negativas associadas a eles. Isso deve ser levado em conta ao priorizar-se (...). O Time Scrum também alerta o Dono do Produto sobre quaisquer dependências que surjam na implementação. Estas dependências devem serem levadas em conta durante a priorização. A priorização pode ser baseada em uma estimativa subjetiva do valor de negócio projetado, ou de sua rentabilidade, ou pode ainda basear-se em resultados e análises de mercado, utilizando ferramentas, incluindo mas não limitado-se a, entrevistas com clientes, pesquisas, modelos financeiros e técnicas de análise. O Dono do Produto tem que traduzir as entradas e as necessidades dos stakeholders, com relação ao projeto, para criar o Backlog Priorizado do Produto. Assim, ao priorizar as Estórias de Usuário no Backlog Priorizado do Produto, três fatores são considerados (...): 1. Valor 2. Risco ou incerteza 3. Dependências Neste caso, a priorização resulta em entregas que satisfazem os requisitos do cliente com o objetivo de fornecer o maior valor de negócio no menor tempo possível. (SCRUMStudy, 2013, p. 31)

2.6.5.7 Time-boxing

Para a gestão do tempo em projetos, podemos utilizar o conceito de Timeboxing, a caixa do tempo, onde ao invés de uma atividade se encerrar ao ter os seus objetivos atingidos, a atividade deve se encerrar ao final de um pacote de tempo definido para tal atividade. De acordo com SCRUMStudy (2013),

124

O Scrum trata o tempo como uma das restrições mais importantes no gerenciamento de um projeto. Para solucionar as restrições de tempo, o Scrum introduz um conceito chamado Time-boxing, que propõe a fixação de um certo período de tempo para cada processo e atividade de um projeto Scrum. Isso garante com que os membros do Scrum não usem muito tempo (ou pouco) em um trabalho específico, e não gastem o seu tempo e energia em um trabalho no qual eles tenham pouco conhecimento. Algumas das vantagens de Time-boxing: Processo de desenvolvimento eficiente Redução de despesas gerais Alta velocidade para os times O Time-boxing pode ser utilizado em muitos processos Scrum, por exemplo, no processo de Conduzir a Reunião Diária, a duração da Reunião Diária é Time-boxed. Às vezes, o Time-boxing pode ser usado para evitar a melhoria excessiva de um item (ou seja, gold-plating). O Time-boxing é uma prática fundamental em Scrum e deve ser aplicado com cuidado. Sendo que se for utilizado de forma arbitrária pode levar a desmotivação do time, tendo como consequência a criação de um ambiente apreensivo, por isso deve ser usado de forma adequada. (SCRUMStudy, 2013, p. 33)

2.6.6 Eventos Scrum

A realização do Scrum desenvolve-se em um ciclo de eventos que acontecem dentro de uma Sprint. Os eventos têm como objetivo o planejamento, o acompanhamento e o controle diários, de modo que ao final do ciclo inicia-se uma reunião para a revisão e análise do projeto desenvolvido durante a Sprint e se encerra com uma reunião de retrospectiva, que tem como objetivo aprender com os erros ocorridos e potencializar as lições aprendidas. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013): Eventos prescritos são usados no Scrum para criar uma rotina e minimizar a necessidade de reuniões não definidas no Scrum. Todos os eventos são eventos time-boxed, de tal modo que todo evento tem uma duração máxima. Uma vez que a Sprint começa, sua duração é fixada e não pode ser reduzida ou aumentada. Os eventos restantes podem terminar sempre que o propósito do evento é alcançado, garantindo que uma quantidade adequada de tempo seja gasta sem permitir perdas no processo. Além da Sprint, que é um container para outros eventos, cada evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa. Estes eventos são especificamente projetados para permitir uma transparência e inspeção criteriosa. A não inclusão de qualquer um dos eventos resultará na redução da transparência e da perda de oportunidade para inspecionar e adaptar. (SCHWABER; SUTHERLAND, 2013 p. 8)

Para Lopes (2015, p. 27), ―Os eventos têm o objetivo de criar uma rotina para o andamento do projeto e suas atividades. Cada evento tem o objetivo de inspecionar e adaptar, isto é buscar a melhoria continua‖.

125

Figura 40: Semana da Sprint

Fonte: Lopes (2015)

2.6.6.1 Sprint

A Sprint é o conceito chave do Scrum, trata-se do desenvolvimento do projeto em time-boxed curtos de no máximo um mês, voltado para atingir a entrega de um pacote de trabalho pronto. O projeto desenvolvido pelo Scrum ocorre através de uma sequência continua de Sprints até a obtenção dos objetivos do projeto. Durante este ciclo de trabalho, não são realizadas mudanças que possam comprometer o cumprimento da meta do ciclo como, também, as metas de qualidade não diminuem, tal ciclo só poderá ser interrompido pelo Product Owner (Dono do Produto) caso seja considerada inútil ou obsoleta. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013): O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um ―Pronto‖, versão incremental potencialmente utilizável do produto, é criado. Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior. As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint. Durante a Sprint:  Não são feitas mudanças que possam por em perigo o objetivo da Sprint;  As metas de qualidade não diminuem; e,  O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido. Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos, as Sprints são utilizadas para realizar algo.

126

Cada Sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto. Sprints são limitadas a um mês corrido. Quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer. Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido. Cancelamento da Sprint Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master. A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem. Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido. Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e ―Pronto‖ é revisado. Se uma parte do trabalho estiver potencialmente utilizável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente reestimado. O cancelamento de Sprints consome recursos, já que todos tem que se reagrupar em outra reunião de planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns. (SCHWABER; SUTHERLAND, 2013 p. 8-9)

Para Lopes (2015, p. 27), ―Sprint – ciclo de trabalho de uma a quatro semanas com um objetivo bem definido. Uma Sprint inicia imediatamente após a outra‖.

2.6.6.2 Reunião de Planejamento da Sprint

Nesta reunião acontece o planejamento dos objetivos a serem entregues como incremento no final da Sprint. A decisão sobre o que deverá ser entregue e como acontecerá o trabalho da Sprint, e a qualidade necessária para a entrega ser considerada ―Pronto‖ ocorre de forma colaborativa entre todos os envolvidos (Product Owner (Dono do Produto), Scrum Master e o Time de Desenvolvimento), podendo desta forma analisar melhor os riscos e possíveis problemas para obtenção dos resultados. E ela ocorre como uma reunião de abertura da Sprint. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013):

127

O trabalho a ser realizado na Sprint é planejado na reunião de planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum. Reunião de planejamento da Sprint possui um time-box com no máximo oito horas para uma Sprint de um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito. O Scrum Master ensina o Time Scrum a manter-se dentro dos limites do time-box. A reunião de planejamento da Sprint responde as seguintes questões:  O que pode ser entregue como resultado do incremento da próxima Sprint?  Como o trabalho necessário para entregar o incremento será realizado? Tópico Um: O que pode ser Pronto nesta Sprint? O Time de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidas durante a Sprint. O Product Owner debate o objetivo que a Sprint deve realizar e os itens de Backlog do Produto que, se completados na Sprint, atingirão o objetivo da Sprint.Todo o Time Scrum colabora com o entendimento do trabalho da Sprint. A entrada da reunião de planejamento da Sprint é o Backlog do Produto, o mais recente incremento do produto, a capacidade projetada do Time de Desenvolvimento durante a Sprint e o desempenho passado do Time de Desenvolvimento. O número de itens selecionados do Backlog do Produto para a Sprint é o único trabalho do Time de Desenvolvimento. Somente o Time de Desenvolvimento pode avaliar o que pode ser completado ao longo da próxima Sprint. Após o Time de Desenvolvimento prever os itens de Backlog do Produto que irá entregar na Sprint, o Time Scrum determina a meta da Sprint. A meta da Sprint é o objetivo que será conhecido dentro da Sprint através da implementação do Backlog do Produto, e esta fornece orientação para o Time de Desenvolvimento sobre o porque dele estar construindo o incremento. Tópico Dois: Como o trabalho escolhido será Pronto? Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o Time de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto ―Pronto‖. Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de Backlog da Sprint. O Time de Desenvolvimento frequentemente inicia o desenho do sistema e do trabalho necessário para converter o Backlog do Produto em um incremento utilizável do produto. O trabalho pode ser de vários tamanhos ou esforços. Contudo, o trabalho suficiente é planejado durante o planejamento da Sprint pelo Time de Desenvolvimento para prever o que esta acredita que poderá fazer durante a próxima Sprint. Com o trabalho planejado pelo Time de Desenvolvimento para os primeiros dias da Sprint, este é decomposto até o final desta reunião, frequentemente em unidades de um dia de duração ou menos. O Time de Desenvolvimento se auto-organiza para realizar todo o trabalho do Backlog da Sprint, tanto durante o planejamento da Sprint quanto no que for necessário durante a Sprint. O Product Owner pode ajudar a clarificar os itens de Backlog do Produto selecionados e nas decisões conflituosas de troca. Se o Time de Desenvolvimento determina que tem excesso ou falta de trabalho, os itens do Backlog da Sprint pode ser renegociados com o Product Owner. O Time de Desenvolvimento também pode convidar outras pessoas para participar desta reunião de forma a fornecer opinião técnica ou de domínios específicos. No final do planejamento da Sprint, o Time de Desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe auto-organizada para completar o objetivo da Sprint e criar o incremento previsto.

128

Objetivo ou meta da Sprint A meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da implementação do Backlog do Produto. Este fornece uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento. Este é criado durante a reunião de planejamento da Sprint. O objetivo da Sprint dá ao Time de Desenvolvimento alguma flexibilidade a respeito da funcionalidade que será completada dentro dos limites da Sprint. Os itens do Backlog do Produto selecionados entregam uma função coerente, que pode ser o objetivo da Sprint. O objetivo da Sprint pode ser qualquer outro coerente que faça o Time de Desenvolvimento trabalhar em conjunto em vez de em iniciativas separadas. Conforme o Time de Desenvolvimento trabalha, ele mantém o objetivo da Sprint em mente. A fim de satisfazer o objetivo da Sprint, implementam a funcionalidade e a tecnologia. Caso o trabalho acabe por ser diferente do esperado pelo Time de Desenvolvimento, então eles colaboram com o Product Owner para negociar o escopo do Backlog da Sprint dentro da Sprint. (SCHWABER; SUTHERLAND, 2013 p. 9 -11)

Para Lopes (2015, p. 27), ―Reunião de planejamento da Sprint – Com a participação de todo o Time, o trabalho a ser realizado na Sprint é planejado. Sugere-se que para organizar o trabalho de uma semana seja feita uma reunião de não mais que duas horas. Na primeira parte será definido o que será entregue e a segunda parte, como o trabalho será realizado. Também deverá ser confirmada a definição de “pronto”.‖

2.6.6.3 Reunião Diária

A Reunião Diária, também conhecida como Daily meeting ou Stand-up meeting (por muitas vezes ser realizas em pé) trata-se de uma reunião curta e dinâmica e que tem por objetivo promover a transparência do estágio de desenvolvimento da Sprint. A Reunião Diária conta com a duração de, em média, 15 minutos. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013): A Reunião Diária do Scrum é um evento time-boxed de 15 minutos, para que o Time de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas. Esta reunião é feita para inspecionar o trabalho desde a última Reunião Diária, e prever o trabalho que deverá ser feito antes da próxima Reunião Diária. A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade. Durante a reunião os membros do Time de Desenvolvimento esclarecem:  O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint?

129

 O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint?  Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da Sprint? O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao objetivo da Sprint e para inspecionar se o progresso tende para completar o trabalho do Backlog da Sprint. A Reunião Diária aumenta a probabilidade do Time de Desenvolvimento atingir o objetivo da Sprint. Todos os dias, o Time de Desenvolvimento deve entender como o mesmo pretende trabalhar em conjunto, como um time auto-organizado, para completar o objetivo da Sprint e criar um incremento esperado até o final da Sprint. O Time de Desenvolvimento ou membros da equipe frequentemente se encontram imediatamente após a Reunião Diária para discussões detalhadas, ou para adaptar, ou replanejar, o restante do trabalho da Sprint. O Scrum Master assegura que o Time de Desenvolvimento tenha a reunião, mas o Time de Desenvolvimento é responsável por conduzir a Reunião Diária. O Scrum Master ensina o Time de Desenvolvimento a manter a Reunião Diária dentro do time-box de 15 minutos. O Scrum Master reforça a regra de que somente os integrantes do Time de Desenvolvimento participem da Reunião Diária. Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento do Time de Desenvolvimento. Esta é uma reunião chave para inspeção e adaptação. (SCHWABER; SUTHERLAND, 2013 p. 11)

Para Lopes (2015, p. 27), Reunião diária – Evento de 15 minutos em que se planejam as próximas 24 horas de trabalho e inspeciona o trabalho realizado nas ultimas 24 horas. É ideal que essa reunião seja com o Time em pé. Três questões devem ser respondidas:  O que foi completado desde a ultima reunião?  O que será feito até a próxima reunião?  Quais os obstáculos estão no caminho?

2.6.6.4 Revisão da Sprint

A reunião de Revisão da Sprint é o primeiro evento para o encerramento da Sprint, seu objetivo é inspecionar e propor adaptações no incremento da Backlog do Produto se necessário. Esta é uma reunião informal, realizada com o todo o Time do Scrum (Product Owner (Dono do Produto), Scrum Master e o Time de Desenvolvimento), podendo ser realizada com a participação de stakeholders chaves para o acompanhamento do projeto.

E tem uma duração de

aproximadamente 1 hora por semana trabalhada na Sprint. De acordo com o Guia do Scrum, Ken Schwaber e Jeff Sutherland (2013):

130

A Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a reunião de Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que podem ser feitas para otimizar valor. Esta é uma reunião informal, não uma reunião de status, e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração. Esta é uma reunião time-boxed de 4 horas de duração para uma Sprint de um mês. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam o seu objetivo. O Scrum Master ensina a todos a manter a reunião dentro dos limites do Time-box. A Reunião de Revisão inclui os seguintes elementos:  Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner;  O Product Owner esclarece quais itens do Backlog do Produto foram ―Prontos‖ e quais não foram ―Prontos‖;  O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos;  O Time de Desenvolvimento demonstra o trabalho que está ―Pronto‖ e responde as questões sobre o incremento;  O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta as prováveis datas de conclusão baseado no progresso até a data (se necessário);  O grupo todo colabora sobre o que fazer a seguir, e é assim que a Reunião de Revisão da Sprint fornece valiosas entradas para a Reunião de Planejamento da próxima Sprint;  Análise de como o mercado ou o uso potencial do produto pode ter mudado e o que é a coisa mais importante a se fazer a seguir; e,  Análise da linha do tempo, orçamento, potenciais capacidades, e mercado para a próxima versão esperada do produto. O resultado da Reunião de Revisão da Sprint é um Backlog do Produto revisado que define o provável Backlog do Produto para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades. (SCHWABER; SUTHERLAND, 2013 p. 12)

Para Lopes (2015, p. 27), ―Revisão da Sprint – Inspeção do que foi produzido, avaliação se está realmente “pronto”. Pode ou não ter a participação do cliente. O Product Owner avalia o progresso do produto‖.

2.6.6.5 Retrospectiva da Sprint

A reunião de Retrospectiva da Sprint é a reunião do fechamento da Sprint, revendo as deliberações com toda a equipe (Product Owner (Dono do Produto), Scrum Master e o Time de Desenvolvimento), com o objetivo de avaliar o desenvolvimento do trabalho da Scrum em relação às pessoas, às relações, aos

131

processos e às ferramentas, buscando potencializar os pontos fortes para a próxima Sprint e reduzir as falhas e problemas ocorridos nesta. Tal reunião tem uma duração de aproximadamente 45 minutos por semana trabalhada na Sprint. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013): A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint. A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes da reunião de planejamento da próxima Sprint. Esta é uma reunião time-boxed de três horas para uma Sprint de um mês. Para Sprint menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito. O Scrum Master ensina todos a mantê-lo dentro do time-box. O Scrum Master participa da reunião como um membro auxiliar do time devido a sua responsabilidade pelo processo Scrum. O propósito da Retrospectiva da Sprint é:  Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos processos e às ferramentas;  Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,  Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho; O Scrum Master encoraja o Time Scrum a melhorar, dentro do processo do framework do Scrum, o processo de desenvolvimento e as práticas para fazê-lo mais efetivo e agradável para a próxima Sprint. Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar a qualidade do produto, adaptando a definição de ―Pronto‖ quando apropriado. Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si próprio. A Retrospectiva da Sprint fornece um evento dedicado e focado na inspeção e adaptação, no entanto, as melhorias podem ser adotadas a qualquer momento. (SCHWABER; SUTHERLAND, 2013 p. 12-13)

Para Lopes (2015, p. 28), ―Retrospectiva da Sprint – Avaliar a última Sprint em relação às pessoas, aos processos, às ferramentas e às relações, identificando o que for positivo e quais possíveis melhorias e criar um plano para implementá-las na próxima Sprint.‖

2.6.7 Artefatos Scrum

Os artefatos Scrum são os entregáveis do Scrum. E podemos dividi-los em três grupos. São eles:

132



Backlog do Produto



Backlog da Sprint



Incremento

De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013): Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos. (SCHWABER; SUTHERLAND, 2013 p. 13)

2.6.7.1 Backlog de Produto

O Backlog do Produto é o objetivo de todo o Scrum, trata-se do maior pacote do Scrum, que deve ter o escopo bem delimitado, com a definição de critérios para a avaliação da qualidade e a informação das características necessárias para ser considerado ―Pronto‖. O Product Owner (Dono do Produto) é o responsável por inspecionar e garantir que os objetivos do Backlog do Produto sejam atendidos. Como o Scrum ocorre em projetos complexos e caóticos é natural que aconteça um desenvolvimento do Backlog do Produto, acompanhando o desenvolvimento e melhor entendimento do projeto. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013): O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação. Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. O Backlog do Produto existirá enquanto o produto também existir. O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor. Enquanto um produto é usado, ganha valor, e o mercado oferece retorno, o Backlog do Produto torna-se uma lista maior e mais completa. Requisitos

133

nunca param de mudar, então o Backlog do Produto é um artefato vivo. Mudanças nos requisitos de negócio, condições de mercado ou tecnologia podem causar mudanças no Backlog do Produto. Múltiplos Times Scrum frequentemente trabalham juntos no mesmo produto. Um Backlog do Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog do Produto que agrupe itens pode ser então aplicado. O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto. Este é um processo contínuo em que o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos itens do Backlog do Produto. Durante o refinamento do Backlog do Produto, os itens são analisados e revisados. O Time de Desenvolvimento decide como e quando o refinamento está ―Pronto‖. Este refinamento usualmente não consome mais de 10% da capacidade do Time de Desenvolvimento. Contudo, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do Product Owner. Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em maior clareza e maior detalhamento; Quanto menor a ordem na lista, menos detalhes. Os itens do Backlog do Produto que irão ocupar o desenvolvimento na próxima Sprint são mais refinados, de modo que todos os itens possam ser ―Prontos‖ dentro do time-boxed da Sprint. Os itens do Backlog do Produto que podem ser ―Prontos‖ pelo Time de Desenvolvimento dentro da Sprint são considerados como ―Preparados‖ para seleção no Planejamento da Sprint. Itens do Backlog do Produto geralmente adquirem este grau de transparência através das atividades de refinamento descritas acima. O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalham fazem a estimativa final. Monitorando o Progresso a Caminho do Objetivo Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser somado. O Product Owner acompanha o total do trabalho restante pelo menos a cada Reunião de Revisão da Sprint. O Product Owner compara este valor com o trabalho restante na Reunião de Revisão da Sprint anterior, para avaliar o progresso na direção de completar o trabalho previsto, pelo tempo estimado para alcançar o objetivo. Esta informação deve ser transparente para todas as partes interessadas. (SCHWABER; SUTHERLAND, 2013 p. 13)

Para Lopes (2015, p. 29), ―Backlog do produto – Listagem ordenada de tudo que deve ser necessário no produto. É o estoque de itens que precisa ser executado pelo Time. O Product Owner é o responsável por manter todas as características, funções, melhorias, correções e requisitos gerados por mudanças. Os itens priorizados no topo da lista devem conter informações que permitam que a equipe os desenvolva, isto é, eles devem estar “preparados”.”

134

2.6.7.2 Backlog da Sprint

O Backlog da Sprint consiste em entregas que podem ser em uma Sprint e que compõem partes do Backlog do Produto. Assim como o Backlog do Produto deve ter características pré-estabelecidas para a verificação da qualidade e critérios para sua aceitação como ―Pronto‖, a transparência do andamento do projeto será favorecida. De acordo com o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013): O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint. O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento ―Pronto‖. O Backlog da Sprint torna visível todo o trabalho que o Time de Desenvolvimento identifica como necessário para atingir o objetivo da Sprint. O Backlog da Sprint é um plano com detalhes suficientes que as mudanças no progresso sejam entendidas durante a Reunião Diária. O Time de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Este surgimento ocorre quando o Time de Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para alcançar o objetivo da Sprint. Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do trabalho restante é atualizada. Quando elementos do plano são considerados desnecessários, eles são removidos. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o Time de Desenvolvimento planeja completar durante a Sprint, e pertence exclusivamente ao Time de Desenvolvimento. Monitorando o Progresso da Sprint Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos itens do Backlog da Sprint pode ser somado. O Time de Desenvolvimento monitora o total do trabalho restante pelo menos a cada Reunião Diária. O Time de Desenvolvimento acompanha estes resumos diários e projeta a probabilidade de alcançar o objetivo da Sprint. Com o rastreamento do trabalho restante em toda a Sprint, o Time de Desenvolvimento pode gerenciar o seu progresso. (SCHWABER; SUTHERLAND, 2013 p. 15)

Para Lopes (2015, p. 29), ―Backlog da Sprint – Listagem com os itens selecionados para serem desenvolvidos naquela Sprint. O Backlog do Sprint deve ser “preparado” pelo Product Owner.‖

2.6.7.3 Incremento

135

O Incremento é o desenvolvimento de um novo pacote ―Pronto‖ que ocorre a cada Sprint, acrescentando mais informação e valor do produto para complementar a Sprint anterior até atingir todo o pacote do Backlog do Produto. Segundo o Guia do Scrum, de Ken Schwaber e Jeff Sutherland (2013): é a soma de todos os ítens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar ―Pronto‖, o que significa que deve estar na condição utilizável e atender a definição de ―Pronto‖ do Time Scrum. Este deve estar na condição utilizável independentemente do Product Owner decidir por liberá-lo realmente ou não. (SCHWABER; SUTHERLAND, 2013 p. 15)

Para Lopes (2015, p. 29), ―Incremento é a soma de todos os itens do Backlog do produto completados (prontos). Esse conjunto pode ou não ser liberado para o cliente‖.

Figura 41: Ciclo do Scrum

Fonte: Adaptada de Ken Schwaber e Jeff Sutherland (2013)

136

2.6.7.4 Desenvolvimento iterativo De acordo com SCRUMStudy (2013, p. 35), “o framework Scrum é impulsionado pelo objetivo de oferecer o maior valor de negócio em um curto período de tempo. Para alcançar este objetivo, na prática, o Scrum acredita em desenvolvimento iterativo de resultados”. Isso significa que ao cliente cabe a definição de alterações, que devem atender às suas necessidades, mesmo que o mesmo não tenha conhecimentos técnicos para requisita-las ou, ainda, não ter certeza de como deverá ficar o produto final que lhe será entregue. O que ocorre frequentemente nos projetos complexos. Este problema suscitou a aplicação de um modelo iterativo, que é aquele que sofre constantemente alterações incrementais, mostrando-se mais flexível uma vez que possibilita ao cliente que quaisquer mudanças solicitadas sejam inclusas como parte do projeto. Portanto, cada característica do projeto complexo é dividida via produção progressiva ao longo do processo de Refinamento do Backlog Priorizado do Produto, de modo que “Os processos de Criar as Estórias de Usuário e Aprovar, Estimar e Comprometer as Estórias de Usuário são usados para adicionar novos requisitos ao Backlog Priorizado do Produto”. (SCRUMStudy, 2013, p. 35) Cabe ao Dono do Produto a garantia do aumento do ROI (retorno sobre o Investimento), concentrando-se tanto no valor quanto na sua entrega durante a Sprint. Assim, quando este profissional produz o Backlog Priorizado do Produto deve dominar a justificativa do negócio do projeto e ter clareza sobre o valor de projeto a ser entregue, de modo a decidir resultados e montantes que devem ser entregues a cada Sprint. Ainda sobre os estágios do Backlog do Sprint, Os processos de Criar as Tarefas, Estimar as Tarefas e Criar o Backlog do Sprint produzem o Backlog do Sprint, o qual é utilizado pelo time para criar os entregáveis. Em cada Sprint, o processo de Criar os Entregáveis é usado para desenvolver as saídas do Sprint. (SCRUMStudy, 2013, p. 35)

137

Cabe ao Scrum Master a garantia de que as etapas do Scrum sejam seguidas, bem como prestar auxílio ao Time, visando a garantia de um trabalho produtivo e proveitoso para os envolvidos. Sobre o Time Scrum, sua característica de auto-organização favorece a criação dos Entregáveis do Sprint a partir das Estórias de Usuário no Backlog do Sprint. Dependendo da complexidade do projeto, vários times multifuncionais colaboram entre si paralelamente aos Sprints, apresentando soluções potencialmente utilizáveis ao cabo de cada Sprint. Ao ser finalizado o Sprint, os entregáveis são rejeitados ou acatados pelo Dono do Produto, que toma sua decisão de acordo com os Critérios de Aceitação do processo de Demonstrar e Validar o Sprint.

Figura 42: Scrum versus O Modelo Tradicional Cascata (Waterfall)

Fonte: (SCRUMStudy, 2013)

138

De acordo com SCRUMStudy (2013), O benefício do desenvolvimento iterativo é que ele permite a correção de curso, na medida em que todas as pessoas envolvidas adquirem um melhor entendimento sobre o que precisa ser entregue como parte do projeto, e incorporando esse conhecimento de maneira iterativa. Assim, o tempo e o esforço necessário para chegar ao ponto final é consideravelmente reduzido e o time produz resultados que são mais adequados ao ambiente de negócios. (SCRUMStudy, 2013, p. 36)

2.6.8 Conceitos do Framework

De acordo com o Guia do Scrum, de Ken Schwaber (2013 p. 16), o Scrum solicita um comportamento de transparência e as decisões que são determinadas para potencializar o valor e o controle de riscos são feitas com base na percepção existente da condição dos artefatos. Quando a transparência é irrestrita, tais decisões tornam-se ainda mais solidas. Por outro lado, quando os artefatos não são transparentes, as decisões podem assumir um caráter falho, o que decorre em diminuição de valores e aumento de riscos. Assim, o Scrum Master deve trabalhar com o Product Owner, Time de Desenvolvimento e demais partes envolvidas de modo que perceba se os artefatos estão absolutamente transparentes. Na supressão de uma transparência plena é atribuição do Scrum Master aplicar a prática mais apropriada para sanar transparências incompletas, uma vez que O Scrum Master pode detectar transparência incompleta pela inspeção dos artefatos, percebendo padrões, ouvindo atentamente o que está sendo dito, e detectando diferenças entre o esperado e o resultado real. (SCHWABER, 2013 p. 16)

Outra competência do Scrum Master é a de trabalhar junto do Time Scrum para organizar o aumento da transparência dos artefatos. Atividade que pressupõe aprendizagem, convencimento e mudança. Haja vista que “Transparência não ocorre de um dia para o outro, mas é um caminho.” (SCHWABER, 2013 p. 16)

139

2.6.8.1 Pronto e Preparado As definições de ―Pronto‖ e ―Preparado‖ são de extrema importância para o andamento do projeto. De acordo com o Guia do Scrum, de Ken Schwaber (2013 p. 16), quando um item do Backlog do produto, ou uma alteração deste, é considerado pronto, os envolvidos (Time Scrum) devem ter em mente que o trabalho está concluído, completo, garantindo sua transparência. A mesma concepção de pronto deve permear os trabalhos do Time de Desenvolvimento, uma vez que estes devem reconhecer a quantidade de itens do Backlog do produto podem ser escolhidos durante a reunião de planejamento da Sprint. Ao Time de Desenvolvimento cabe a entrega da mudança da funcionalidade do produto. Se o incremento é utilizável, o Product Owner pode liberá-lo. Do mesmo modo, a finalidade de cada Sprint é a de transferir as alterações das funcionalidades utilizáveis (―prontas‖) do Time Scrum e este deverá seguir tal convenção como premissa mínima. Se tal convenção não se justifica para um incremento,

Time

Desenvolvimento

Time

Scrum

deve

defini-la

apropriadamente de acordo com o produto. Assim, cada incremento deve ser somado aos demais, preliminares e já ensaiados, certificando-se de que todos os incrementos funcionam juntos. A partir de um Time Scrum maduro, os profissionais envolvidos poderão expandir seu conceito de ―pronto‖ e determinar novos e mais rigorosos parâmetros de qualidade. Para Lopes (2015), os conceitos de Pronto e Preparado são definições importantes que devem ser compreendidas da mesma forma por todo o Time. De modo que: Preparado – Cabe ao Project Owner ―preparar‖ o Backlog para que a equipe tenha todas as informações para que possa desenvolver o produto. Pronto – Deve ser estabelecido a cada caso, ou genericamente, o significado de ―pronto‖, para que ao final da Sprint não haja surpresa. (LOPES, 2015, p. 30)

2.6.8.2 Estimativa de Esforço

140

Para definirmos o Sprint backlog, ou seja, o que será produzido na Sprint, devemos quantificar o trabalho. Todos os itens que farão parte da backlog deverão ser analisados e estimados pela equipe até que se chegue a um consenso. De acordo com Sutherland (2014), o ser humano não é bom em estimativas de tempo, mas sua capacidade comparativa em relação ao tamanho é muito boa; de modo que é aconselhável que a estimativa de esforço das tarefas seja feita em alguma escala de tamanho ao invés de um número de horas. O esforço deve ser determinado comparando-se as tarefas e utilizando escalas de tamanho com P (pequeno), M (médio), G (grande), GG (muito grande). Para chegarmos a um consenso com a equipe podemos utilizar um jogo de cartas, o Planning Poker. De acordo com Lopes (2015), A estimativa do esforço é feita com o auxílio de um baralho que possui os números 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 (esses números são conhecidos como escala de Fibonacci). Todos os integrantes da equipe devem participar e indicar o nível de complexidade. O baralho tem ainda uma carta com um ponto de interrogação, que deve ser usada quando o participante não souber estimar o esforço da tarefa e uma carta com uma xícara de café, que deve ser usada para sugerir uma pausa. [...] A cada tarefa devem ser feitas rodadas de ―jogo‖, coordenadas pelo Scrum Master, para que os integrantes discutam o esforço necessário à conclusão da tarefa em quantas rodadas forem necessárias, até chegarem ao consenso. (LOPES, 2015, p. 32)

2.6.8.3 Monitoramento

Tão importante quanto o planejamento é o monitoramento que se deve realizar para que o projeto não se distancie do que foi inicialmente planejado. Para este acompanhamento, a ferramenta comumente utilizada é um quadro em que se pode visualizar facilmente o andamento das atividades. O quadro contém três colunas: ―a fazer‖ (to do), ―fazendo‖ (doing) e ―feito‖ (done), que indicam o andamento das tarefas. Além destas colunas pode-se ter um espaço para se registrar os problemas identificados e as observações importantes sobre o trabalho. Para acompanhar a produtividade planejada versus a executada coloca-se, também no quadro, um gráfico que pode ser ascendente (burnup) ou descendente (burndown). Neste gráfico são marcados os números de pontos a serem cumpridos

141

em relação ao tempo da Sprint de uma cor e em outra faz-se o controle do desempenho verificando-se os ajustes necessários para se alcançar o resultado final. Figura 43: Modelo padrão de quadro de visualização do andamento das tarefas utilizado com frequência no Scrum. Na lateral, em detalhe, os gráficos tipo burndown e burnup, onde se pode comparar o trabalho programado com o efetivamente feito.

Fonte: Lopes (2015).

2.7

Kanban

O Kanban, foi desenvolvido por Eiji Toyoda e Taiichi Ohno no Sistema Toyota de Produção para agilizar e garantir a comunicação através de um quadro visual baseado em conceitos como fluxo continuo, foco, visibilidade e melhoria contínua. Em 2007 é utilizado como ferramenta para o desenvolvimento de software, por David J. Anderson. Em seu sentido literal, Kanban significa "placa" ou "outdoor", o que justifica a utilização de recursos visuais visando o acompanhamento dos processos de produção. O emprego de tais ferramentas visuais mostrou-se eficaz e transformou-

142

se uma aplicação bastante comum, exemplos disso são as cartas de tarefas, os Scrumboards e os gráficos Burndown, recursos bastante praticados na Toyota, referência no gerenciamento de projetos. Além das colunas ―a fazer‖ (to do), ―fazendo‖ (doing) e ―feito‖ (done), o Kanban determina um limite para cada estágio de desenvolvimento, este limite é chamado de WIP – Work in process e serve para orientar o gestor acerca da capacidade e o tempo de trabalho a ser realizado em cada etapa. O objetivo do WIP é garantir que o trabalho a ser realizado em cada etapa não seja nem maior, nem menor do que a capacidade da equipe e o tempo disponível. De acordo com Lopes (2015), o WIP deve ser estabelecido por coluna, facilitando o controle do fluxo, e evidenciando possíveis filas ou gargalos de trabalho, para que a equipe possa definir como atuar imediatamente. O Lean Kanban alia a utilização dos métodos de visualização estabelecido pelo Kanban aos preceitos do Lean, produzindo uma evolução no sistema de gerenciamento visual. O conceito de Lean otimiza sistemas de uma organização para produzir resultados valiosos com base nos seus recursos, necessidades e alternativas, enquanto reduz o desperdício. O desperdício pode ser resultado da construção da coisa errada, a incapacidade de aprender, ou práticas que impedem o processo. Como esses fatores são de natureza dinâmica, uma organização Lean avalia todo o seu sistema e continuamente afina seus processos. (SCRUMStudy, 2013, p. 277)

Deste modo, pode-se considerar que o Lean Kanban proporciona um elevado índice de produtividade, uma vez que minimiza atrasos e auxilia na detecção de erros numa fase inicial do projeto, o que significa reduzir a total de esforço dispendido para a conclusão de uma tarefa.

143

Figura 44: Modelo genérico de Kanban

Fonte: Lopes (2015).

2.8

Scrum versus PMI

O SCRUMStudy (2013) propõe algumas comparações entre a metodologia de projeto tradicional com a metodologia Scrum. A partir do quadro comparativo que levam em conta os princípios de um e outro método, podemos observar, a partir do que foi elaborado pelo PMI (2013) que o destaque no modelo tradicional de gerenciamento de projetos reside na realização do planejamento inicial do projeto, uma vez que se busca fixar um escopo, um custo, um cronograma e um modo de gerenciar tais processos. O que neste modelo pode acarretar a insatisfação do cliente, mesmo que o plano esteja em bom andamento. Já no método Scrum, a pessoa é levada em consideração, assim, todos os processos serão conduzidos para a satisfação dos envolvidos, sejam eles os profissionais ou os clientes. Por esse motivo, o framework Scrum está baseado na ideia de que os colaboradores podem acrescentar com conhecimentos que excedem ao cartesianismo do saber técnico. Além disso, defendem que o mapeamento e o planejamento não são eficazes dentro de ambientes inconstantes.

144

Tabela 1: Scrum x O Modelo Tradicional de Gerenciamento de Projetos segundo o SCRUMStudy.

Fonte: SCRUMStudy (2013)

Por essas razões, o modelo Scrum defende a tomada de decisões que são baseadas em dados, haja vista que o foco é a entrega de produtos que satisfaçam os desejos e as necessidades dos clientes, em pequenos acréscimos realizados repetidamente, até que o produto seja utilizável. Assim, para que se entregue a maior quantidade de valor no menor tempo, o Scrum promove, de forma autoorganizada a priorização e o Time-boxing sobre a fixação do escopo, custo e cronograma do projeto.

145

Acerca da organização, os métodos analisados diferem de forma bastante sensível. No modelo tradicional, a estrutura é hierárquica e a autoridade se estabelece do nível superior ao inferior, quaisquer desvios na escala hierárquica causa incômodos; este modelo enfatiza o indivíduo, que é o único responsável pela prestação de contas. E o gerente do projeto é o responsável pelas decisões sobre o mesmo, seja qual for o estágio, até a conclusão e entrega do produto final. Ao contrário do método tradicional, concentrado e hierárquico, observamos que A ênfase do Scrum está na auto-organização e auto-motivação, onde o time assume uma responsabilidade maior pelo projeto, comprometendo-se com o seu sucesso. Isso também garante que o time ―buy-in‖ e compartilhe responsabilidades. O que por sua vez, resulta em motivação conduzindo a otimização da eficiência do time. O Dono do Produto, o Scrum Master, e o Time Scrum trabalham em conjunto com o(s) Stakeholder(s) relevantes, para refinar os requisitos enquanto passam pelo processos de Desenvolver o(s) Épico(s), Criar o Backlog Priorizado do Produto, e Criar as Estórias de Usuário. Isso garante que não haja espaço para o planejamento isolado em Scrum. A experiência do time e sua expertise no desenvolvimento de produtos, são utilizadas para avaliar as entradas necessárias para planejar, avaliar e executar os trabalhos do projeto. A colaboração entre os membros do Time Central do Scrum, garante que o projeto seja realizado em um ambiente inovador e criativo, favorável à harmonia e ao crescimento do time. (SCRUMStudy, 2013, p. 57)

Sobre a Justificativa de Negócios nos métodos analisados, a valoração do projeto tradicional é comumente lenta, centralizada na figura do gerente de projeto e só é entregue ao cliente ao fim do projeto. Nos projetos que usam o Scrum, o planejamento é iterativo, anterior às Sprints. Procedimento que favorece as respostas, de modo que estas se adequem às mudanças necessárias e implementadas, resultando em um baixo custo, elevada margem lucrativa e significativo retorno sobre o investimento (ROI). A entrega orientada a valor é uma importante vantagem do framework Scrum, uma vez que promove a priorização e a realização do valor de forma mais rápida e eficiente. Além disso, Devido à natureza interativa do desenvolvimento do Scrum, há pelo menos sempre uma versão disponível do produto de acordo com o Minimal Marketable Feature – MMF (Características Mínimas Comerciáveis). Mesmo se um projeto for finalizado, geralmente existem alguns benefícios ou valor criado antes de sua rescisão. (SCRUMStudy, 2013, P. 82)

Sobre a Qualidade do produto nos dois métodos empregados, percebe-se que diferenças de abordagem são determinantes para a entrega do produto, uma

146

vez que influem no cumprimento dos diferentes níveis de exigência. Assim, no modelo tradicional, os clientes expõem suas expectativas e os gerentes respondem favoravelmente a elas ou não. Caso haja alguma alteração a ser feita, estas só se realizam a partir de um sistema de gerenciamento de mudança, o qual mede os impactos casados pelas alterações e o gerente de projeto recebe a aprovação dos stakeholders. em Scrum, o Dono do Produto colabora com o Time Scrum e define os Critérios de Aceitação para as Estórias de Usuário relacionadas com o produto a ser entregue. O Time Scrum em seguida, desenvolve o produto de uma série de iterações curtas chamadas Sprints. O Dono do Produto pode modificar os requisitos para manter o ritmo com as necessidades do usuário e essas mudanças podem ser abordadas pelo Time Scrum, seja encerrando o atual Sprint ou incluindo os requisitos ajustados no próximo Sprint já que possuem curta duração (de uma a seis semanas). Uma das principais vantagens do Scrum é a ênfase na criação de entregáveis potencialmente utilizáveis no final de cada ciclo do Sprint, ao invés de ser realizada apenas no final de todo o projeto. Sendo assim, o Dono do Produto e os clientes constantemente inspecionam, aprovam e aceitam as entregas após cada Sprint. Além disso, mesmo que um projeto Scrum seja encerrado, sempre existe algum valor criado antes de sua rescisão, através das entregas criadas em Sprints individuais. (SCRUMStudy, 2013, P. 95)

O comparativo o gerenciamento de mudanças produzido nos dois modelos, o Scrum e o tradicional é bastante visível. Neste as alterações estão condicionadas a um Gerenciamento de Configuração, no qual as mudanças são baseadas na sua magnitude de variação, permanecendo nas mãos do gerente de projeto todas as decisões e gestão das tolerâncias diárias.

Deste modo, o gerente solicita a

mudança e outorga sua realização para um profissional de elevada posição hierárquica, que deliberará de acordo com o impacto causado pela mudança em questão, ficando para o gerente decidir sobre a mesma. Este profissional também pode sugerir recursos para contornar os impactos das alterações que, dependendo da decisão das autoridades acerca de sua realização ou não, deve ser implementada corretamente. Já a mudança em Scrum funciona de uma forma muito diferente se comparada ao Modelo Tradicional de Gerenciamento de Projeto. O framework Scrum é altamente sintonizado para gerenciar mudanças com eficácia e eficiência. Sempre que o Dono do Produto ou o Time Scrum encontram um problema ou defeito, ou identificam um Item do Backlog Priorizado do Produto que precisa ser alterado, substituído ou adicionado, a modificação é feita no Backlog Priorizado do Produto. Da mesma forma, a alta administração, o Dono do Produto, ou o(s)

147

stakeholder(s) podem adicionar Solicitações de Mudança para o Backlog Priorizado do Produto. O Dono do Produto e o(s) Stakeholder(s) aprovam as Solicitações de Mudança, e o Backlog é priorizado de acordo. Sempre que há um problema ou um novo requisito que precisa ser tratado imediatamente e exige uma mudança que afeta o Sprint atual, o Dono do Produto encerra o Sprint com a aprovação dos stakeholders relevantes. Uma vez encerrado, o Sprint vai ser replanejado e reiniciado para incorporar os novos requisitos. No entanto, se o problema ou a mudança não é grande e não garante uma mudança no atual Sprint, a modificação será adicionada ao Backlog Priorizado do Produto e incorporada no planejamento de um Sprint subsequente. Isto dá aos stakeholders a habilidade de responder a mudanças no ambiente externo, enquanto ainda é mantido um certo grau de controle sobre as atividades do projeto em andamento. Além disso, no final de cada Sprint, os Entregáveis Prontos são demonstrados pelo time Scrum. Estes entregáveis são potencialmente utilizáveis e podem ser revisados pelo Dono do Produto e por outros stakeholders. (SBOK, 2013, P. 116)

Tanto o método tradicional de gerenciamento de projeto quanto o Scrum definem o risco como crucial para a execução dos objetivos do projeto, configurando-se como consta em SCRUMStudy (2013, p. 132) como “evento(s) incerto(s) que podem afetar positivamente ou negativamente a consecução dos objetivos do projeto”, passando a realizar um acompanhamento sobre os mesmos, que são continuamente identificados, avaliados, planejados e comunicados. No padrão tradicional, existe a ênfase no planejamento inicial, e é a partir deste que se identifica, avalia e determina os riscos do projeto. Ao longo da execução, os riscos são comunicados ao gerente, ao escritório ou ao time de apoio que os atualizam no registro de risco. Cabe ao gerente o monitoramento e controle dos riscos e a eleição do elemento do time de apoio que responderá por determinados riscos. Em Scrum, qualquer membro do Time Scrum pode identificar riscos e o Dono do Produto pode atualizar os riscos identificados, no Backlog Priorizado do Produto de Risco Ajustado. Os princípios do Scrum de Controle de Processo Empírico e de Desenvolvimento Iterativo permitem que o Time Scrum possa manter constantemente a identificação de riscos, e de adicioná-los ao Backlog Priorizado do Produto, onde esses riscos serão priorizados juntamente com outras Estórias de Usuários existentes no backlog, para serem mitigados em Sprints seguintes. O Time Scrum tem responsabilidades coletivas no gerenciamento de todos os riscos no Sprint. (SCRUMStudy, 2013, p. 132)

148

CONCLUSÃO

Conforme o exposto neste estudo fica evidente que, no ambiente das organizações de negócios, a complexidade, a velocidade de mudanças e a adaptação ao grande fluxo de informações são os componentes que vão fomentar o desenvolvimento constante de novas tecnologias. Este cenário provoca uma seleção natural em que somente as empresas inovadoras e criativas, que são capazes de se adaptar às novas demandas, sobrevivem. A mudança da tecnologia de projetos, cuja representação evoluiu dos projetos em desenhos 2D, para modelos BIM, utilizando-se de cada vez mais informações, facilitando todo o processo do projeto. Tal avanço tecnológico abriu a possibilidade da implementação do projeto integrado, no qual todos os projetistas acrescentam as suas informações no mesmo modelo, fazendo com que se consiga uma notável redução de erros, o que facilita a comunicação entre todos os projetistas e promove a possibilidade de se simular toda a construção, gerando dados quantitativos e qualitativos precisos. No entanto, a mudança do processo de desenvolvimento dos projetos arquitetônicos, apesar ser desejada em sua grande maioria pelos escritórios, ainda enfrenta dificuldades, devido ao treinamento e acompanhamento de novas equipes. Neste contexto, a aplicação de um método ágil como o Scrum passa a ser um diferencial, uma vez que apresenta um monitoramento constante e ágil para responder às mudanças, melhorar a qualidade do produto, as entregas dentro dos prazos, a satisfação do cliente e/ou usuário e, consequentemente, o valor do negócio, a produtividade e a previsibilidade do projeto. Entendemos que este momento de mudança do processo de projetar proporcionado pelas plataformas BIM, com suas possibilidades do trabalho colaborativo e just-in-time, produz um embasamento técnico necessário para a proposição de outra grande mudança no processo de gestão dos projetos, utilizando os princípios ágeis do Scrum e que esta mudança conjunta, feita gradualmente, tem muito a contribuir para a sustentabilidade das empresas competitivas. Conforme visto neste trabalho de pesquisa, de acordo com os textos, figuras, tabelas e quadros apresentados, julgamos que este objetivo tenha sido alcançado.

149

REFERÊNCIAS BIBLIOGRÁFICAS

ABNT NBR ISO 9001:1994

ABNT NBR ISO 14001:2004

AGILE MANIFESTO. Manifesto para Desenvolvimento Ágil de software. Disponível em: http://www.agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em: 08.ago.2015

AGILE MANIFESTO. Os doze princípios por trás do Manifesto Ágil. Disponível em: http://www.agilemanifesto.org/iso/ptbr/principles.html. Acesso em: 08.ago.2015

ANDREUZA, M. A história do gerenciamento de projetos. Disponível em: http://www.sagres.org.br/artigos/historiagerenciamento.pdf.

Acesso

em:

out.2015.

APPELO, J. Management 3.0: Leading Agile Developers, Developing Agile Leaders, Pearson Education, Boston, MA, USA, 2011.

______. Management 3.0 #Workout: Games, Tools & Practices to Engage People, Improve Work, Pearson Education, Boston, MA, USA, 2014.

ARAYICI,

Y.; COATES,

S.P.; KOSKELA,

L.J.; KAGIOGLOU,

M.; USHER,

C.; O’REILLY, K. BIM implementation for an architectural practice, in: 26th International Conference on IT in construction, 1/10/09 - 3/10/09, Istanbul Technical University, Turkey. 2009,

AsBEA. Associação Brasileira dos Escritórios de Arquitetura Site oficial, Brasil - Guia AsBEA

boas

práticas

BIM,

Fascículo

Disponível

em:

http://www.asbea.org.br/asbea/assuntos/manuais.asp. Acesso em: 11 ago.2015.

BAÍA, J.L. Sistema de gestão da qualidade em empresas de projeto: aplicação ao caso dos escritórios de arquitetura. São Paulo, 1998. Exame de Qualificação (Mestrado) - Escola Politécnica, Universidade de São Paulo. /não publicado/

150

CAPRA, F. A Teia da Vida. São Paulo: Cultrix, 1996

CASTELLS, E.J.F.; HEINECK, L.F.M. A aplicação dos conceitos de qualidade de projeto no processo de concepção arquitetônica – uma revisão crítica. In: WORKSHOP NACIONAL: gestão do processo de projeto na construção de edifícios, 2001, São Carlos. Anais... São Carlos: EESC/USP, 2001. CD-ROM

COSTA, L. Considerações sobre arte contemporânea. In: Lúcio Costa, Registro de uma vivência. São Paulo: Empresa das Artes, 1995.

CRUZ, F. Scrum e Agile em projetos: guia completo. Rio de Janeiro, Editora Brasport, 2015.

FABRÍCIO, M. M., BAÍA J. L., MELHADO, S. B., Estudo da sequência de etapas do projeto na construção de edifícios: cenário e perspectivas. In. ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO, Rio de Janeiro, 1998.

FABRICIO, M. M; MESQUITA, M. J.; MELHADO, S. B. Colaboração simultânea em diferentes tipos de empreendimentos de construção de edifícios. In: ENCONTRO NACIONAL DE TECNOLOGIA DO AMBIENTE CONSTRUÍDO: cooperação & responsabilidade social 9, 2002, Foz do Iguaçu. Anais... Foz do Iguaçu, 2002. CDROM

FABRICIO, M. M.; MELHADO, S.B. Desafios para integração do processo de projeto na construção de edifícios. In: WORKSHOP NACIONAL: gestão do processo de projeto na construção de edifícios, 2001, São Carlos. Anais.... São Carlos: EESC/USP, 2001. CD-ROM

FABRÍCIO, M. M., Projeto simultâneo na construção de edifícios. Tese apresentada à Escola Politécnica da Universidade de São Paulo para obtenção do Título de Doutor em Engenharia São Paulo, 2002.

151

______. O Arquiteto e o coordenador de projetos. Artigo Revista Pós n°22 Escola Politécnica da Universidade de São Paulo, São Paulo, 2008. (p. 26-50)

FERREIRA, R. C. Os diferentes conceitos entre gerência, coordenação e compatibilização de projetos na construção de edifícios. In: WORKSHOP NACIONAL: GESTÃO DO PROCESSO DE PROJETO NA CONSTRUÇÃO DE EDIFÍCIOS, 2001, São Carlos-SP. Anais... São Carlos: EESC/USP, 2001. CD-ROM.

FERREIRA, R. de R.; MONTEIRO, S. A. P. O kaizen como sistema de melhoria contínua dos processos: um estudo de caso na Mercedes-Benz do Brasil LTDA planta Juiz de Fora. 2008. 70p. Monografia (Bacharelado em Secretariado Executivo Trilíngüe) – Universidade Federal de Viçosa, Viçosa, MG, 2008.

GARRIDO, M. Management 3.0 Agile Leadership Pratices. Disponível em: http://pt.slideshare.net/marcosgarrdio/management-30-33178336.

Acesso

em:

24.out.2015.

GRANDO, N. Simples, complicado, complexo ou caótico.

Disponível em:

https://neigrando.wordpress.com/2013/12/06/simples-complicado-complexo-oucaotico/. Acesso em: 15.out.2015

HARTLEY, Jonh R. Engenharia Simultânea. Bookman, Porto Alegre, 1998.

IMAI, M. Kaizen: a estratégia para o sucesso competitivo. 51ªed. São Paulo: Instituto IMAM, 1994.

ISO, International Organization for Standardization.

ISO quality – Quality

management principies. Disponível em: http://www.iso.org/iso/pub100080.pdf. Acesso em: 20.out.2015 JOUINI, S (1999). Programmer et concevoir – pratiques de projet et ingénieries: interaction des approches produit et process à travers les ingénieries. Paris, não publicado.

152

KUHN, T. Estrutura das revoluções científicas. Chicago: University Chicago, 1970. KNIJNIK Engenharia Integrada, BIM – Conceitos e Aplicações – Disponível em: http://www.engenhariaintegrada.com.br/wp-content/uploads/2014/10/APRESENTA %C3%87%C3%83O_BIM-SITE.pdf. Acesso em: 24.out.2015.

Lei n° 12.378, de 31 de dezembro de 2010, que regula as atribuições do arquiteto urbanista.

Disponível

em:

https://www.planalto.gov.br/ccivil_03/_ato2007-

2010/2010/lei/l12378.htm. Acesso em: 18 set.2015

LOPES, S., Métodos Ágeis para arquitetos e profissionais criativos, Editora Brasport, Rio de Janeiro, 2015.

MANZIONE, L., Proposição de uma Estrutura Conceitual de Gestão do Processo de Projeto Colaborativo com o uso do BIM. 2013. (Tese de doutorado) - Escola Politécnica da Universidade de São Paulo, Universidade de São Paulo, São Paulo.

MASOTTI, L. F. C. Análise da implementação e do impacto do BIM no Brasil. 2014. (Monografia) Graduação em Engenharia Civil. Universidade Federal de Santa Catarina. Florianópolis.

MELHADO, S. B., O Plano da Qualidade dos Empreendimentos e a Engenharia Simultânea na Construção de Edifícios. In. ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO, Rio de Janeiro, 1999. Anais em CD-ROM: UFRJ/ABREPO, Rio de Janeiro, 1999.

MENEZES, G. L. B. B. de. Breve Histórico de Implantação da Plataforma BIM, Cadernos de Arquitetura e Urbanismo, v.18, n.22, 21º sem. 2011, PUC MINAS.

MOURA,

PMP

Sem

segredos

Rio

Janeiro.

Elvesier,

2013.

153

MORIN, E. Introdução ao Pensamento Complexo. Trad: Eliane Lisboa - Porto Alegre: Ed. Sulina, 2005.

MÜLLER, L. S., Utilização da Tecnologia Bim (Building Information Modeling) Integrado a Planejamento 4D na Construção Civil. 2015. 84f. Projeto de Graduação (Graduação em Engenharia Civil) - Escola Politécnica / Curso de Engenharia Civil, Universidade Federal do Rio de Janeiro, Rio de Janeiro.

NOLAN, Richard e CROSON, David. Creative Destruction. Harvard Business Scholl Press, 1996.

PETERS,

Agile

Project

Manager.

Disponível

em:

https://pmi.adobeconnect.com/_a821822776/p7v9mnhcsbb/?launcher=false&fcsCont ent=true&pbMode=normal. Acesso em: 08.ago.2015

PISSARA. N. M. de M. Utilização de plataformas Colaborativas para o Desenvolvimento de Empreendimento de Engenharia Civil. 2010. Dissertação (Mestrado em Engenharia Civil) Instituto Superior Técnico da Universidade Técnica de Lisboa, Universidade Técnica de Lisboa, Lisboa.

PMI, Project Management Institute. A guide to the project management body of knowledge (PMBOK® guide). 5 ed. Pennsylvania, Project Management Institute, Inc, 2013.

PONCHIROLLI, O. A Teoria da Complexidade e as Organizações. Diálogo Educ., Curitiba, v. 7, n. 22, p. 81-100, set/dez. 2007.

REIS, P. Saiba como foi o processo de implementação do BIM em escritórios de arquitetura como Aflalo & Gasperini, Gui Mattos, Orbi Arquitetura e Clarissa Strauss.

Revista

AU,

São

Paulo,

Edição

208, jul.2011.

Disponível

em:

http://au.pini.com.br/arquitetura-urbanismo/208/desafios-da-implementacao-2243731.aspx. Acesso em: 02.nov.2013

154

RITTER, R. Scrum e planning poker: análise de estimativa de software. Devmedia, 2014. Disponível em: http://www.devmedia.com.br/scrum-e-planningpoker-analise-de-estimativa-de-software/31019. Acesso em: 07.out.2015.

SABBAGH, R. Scrum gestão ágil para projetos de sucesso. São Paulo: Casa do Código, s/d.

SCHWABER, K; SUTHERLAND, J. Guia Scrum. Scrum.org (2013). Disponível em http://www.scrumguides.org/scrum-guide.html. Acesso em: 08.ago.2015

SCRUM

ALLIANCE.

Core

Scrum.

Disponível

https://www.scrumalliance.org/why-scrum/core-scrum-values-roles.

em: Acesso

em:

07.out.2015. SCRUMstudy. A Guide to the Scrum body of knowledge (SBOK™guide) 2013 Edition. Phoenix, Arizona, 2013.

SEVERO, E. A., et al. Estrutura organizacional das empresas inovadoras no Brasil,

Revista

Espacios.

Vol.

(11)

2012.

Disponível

em:

http://www.revistaespacios.com/a12v33n11/12331105.html. Acesso em: 24 set. 2015.

SILVA; C. E. S. da; ULBRICHT V. R.; NETO M. F. A importância da criatividade no contexto emergente do desenvolvimento de produtos. In: XVIII Encontro Nacional de Engenharia de Produção, v. 1, p. 01-07, Niterói – Rio de Janeiro, 1998.

SLACK, Nigel; CHAMBERS, Stuart; JOHNSTON, Robert. Administração da produção. 2ªed. São Paulo: Atlas, 2008.

SOUSA, O. K. de; MEIRIÑO, M. J. Aspectos da implantação de ferramentas BIM em empresas de projetos relacionados à construção civil. In: IX Congresso Nacional de Excelência em Gestão, 2013, Laboratório de Tecnologia, Gestão de Negócios & Meio Ambiente, LATEC-UFF, Universidade Federal Fluminense, Niterói.

155

SOUZA, L. L. A. de. Diagnóstico do uso do BIM em empresas de projeto de Arquitetura. 2009. 107f. Dissertação (Mestrado em Engenharia Civil) - Programa de Pós-Graduação em Engenharia Civil, Universidade Federal Fluminense, Niterói.

SOUZA, L. L. A.; AMORIM, S. R. L.; LYRIO, A. M. Impactos do uso do BIM em escritórios de arquitetura: oportunidades no mercado imobiliário. Gestão & Tecnologia de Projetos. 2009, Vol. 4, n° 2.

SUTHERLAND, J. Scrum: a arte de fazer o dobro de trabalho em metade do tempo. São Paulo: LeYa, 2014.

VERSION

ONE.

9th

Anual

State

Agile

Survey.

Disponível

em:

https://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf. Acesso em: 09.out.2015.