ESTUDO DE MODELOS DE GESTÃO DE PROJETOS APLICADO À

CONSTRUÇÃO CIVIL: caso comparativo entre modelo tradicional e modelo ágil

Luiz Fernando Melo Pinheiro

INSTITUTO DE ENSINO SUPERIOR FRANCISCANO – IESF

Resumo
Toda empresa de precisa seguir uma metodologia bem definida para o desenvolvimento adequado de
seus projetos. Modelos de desenvolvimento de software tem ajudado muitas empresas de construção civil a
concluir projetos de boa qualidade dentro do limite de tempo e custo. Duas metodologias amplamente utilizados
em outras áreas são discutidos neste artigo. Este artigo também discute seu uso junto com seus prós e contras. O
desenvolvimento de projetos na Konzept Engenharia LTDAtambém é discutido.

Palavras-chave: Ciclo de Vida de Projetos. modelo Tradicional. modelos Ágil. SCRUM

1 – INTRODUÇÃO

Diante da dinâmica dos mercados, juntamente ao crescimento da concorrência e

exigências dos clientes, as empresas do setor de construção civil buscam constantemente
soluções que gerem vantagens competitivas.
Nesse contexto, este artigo tem como objetivo analisar e comparar a aplicação da
metodologia de Gestão Projetos Ágeis, frente a metodologia de Gestão de Projetos
Tradicionais, modelos clássicos no ramo de softwares, agora aplicados no Setor de
Construção Civil, tendo como unidades de análise duas obras de médio porte (projetos de
reformas de duas clínicas em São Luís – MA) ambas geridas pela mesma construtora,
Konzept Engenharia LTDA. Para tal, utiliza-se de pesquisa descritiva de natureza qualitativa,
mediante pesquisa-ação e estudo de caso comparativo. Os mecanismos de coleta de dados
consta de roteiro de entrevista e relatórios aplicados junto aos colaboradores da organização.
Os primeiros resultados indicam que existem diferenças nos resultados entre a
construtora que tem atividades orientadas pelo ciclo de trabalho processo padrão-produtivo –
Modelo Cascata e a que é pautada pelo ciclo de trabalho orientado por processos ágeis –
Modelo SCRUM, em especial no que se refere a integração de pessoas aos projetos, a
prevenção e controle de irregularidades nos orçamentos e prazos, as revisões e adaptações nos
cronogramas, propiciando encurtamento de ciclos e permitindo agilidade nos processos e
melhoria da gestão das atividades. Por fim, pode-se sugerir que existem significativos
benefícios para a empresa que utiliza o Método Ágil.
 Assim, o questionamento que surge como consequência do estudo, é como utilizar
esses fundamentos da Gestão Ágil na conjuntura da construção civil frente as metodologias de
Gestão Tradicional? E, neste aspecto, Highsmith (2004) destaca que para o emprego efetivo
dos fundamentos do gerenciamento ágil, é preciso que a organização determine cinco
objetivos comuns para seu empreendimento, que devem encontrar-se ajustados com os
fundamentos desse tipo de gestão, são eles: busca incessante por inovações, flexibilidade do
projeto, entregas com minimização dos prazos, capacidade de adequação as mudanças dos
indivíduos e dos processos, e resultados confiáveis.
Diante desta reflexão, o que se pretende é comparar a aplicação da metodologia Ágil e
Tradicionais, do ramo de softwares, aplicados em projetos da Indústria da Construção Civil, a
partir desse desafio, este estudo se propõe a fazer uma reflexão de quais indicativos podemos
usar para melhor comparar os dois modelos de gestão haja vista que, a crescente
competitividade do setor exige a aplicação dessas novas tecnologias de gestão como
competência essencial nas obras contemporâneas.
De acordo com a taxionomia de Vergara (2014), esta pesquisa classifica-se da seguinte
forma: quanto aos fins é descritiva, explicativa e aplicada. Descritiva porque visa descrever o
ambiente físico e de convivência dos sujeitos envolvidos nos projetos. Explicativa porque
busca uma relação de causa-efeito para cada uma das metodologias e aplicada por se tratar de
comparação metodológica aplicada a projetos concretos. Quanto aos meios, é bibliográfica e
de campo. Bibliográfica pela necessidade de recorrer à literatura, livros e artigos científicos,
confrontando teoria com a realidade; de campo ao considerar-se que o objeto investigado é
algo concreto que se manifesta nos ambientes de projeto (obras) necessitando de pesquisa,
emissão de relatórios e entrevistas in locco. Quanto a abordagem, ainda segundo a autora, é
qualitativa e quantitativa. Qualitativa, pois através das entrevistas ganhará um caráter
subjetivo a ser analisado, estudando as particularidades e experiências individuais dos
entrevistados, que estarão livres para apontar os seus pontos de vista sobre os métodos em
estudo; e quantitativa porque utilizará diferentes técnicas estatísticas, através dos
questionários das entrevistas e dos relatórios de processos, para quantificar as opiniões e
informações a fim de compreender e extrair as informações que possam mensurar sobre as
experiências de cada um dos indivíduos em cada um dos métodos.
Assim, as empresas do setor de construção civil na constante busca de soluções que
gerem vantagens competitivas frente ao mercado, o conceito de gestão de projetos tornou-se
indispensável neste setor, podendo ser aplicada nos perfis mais diversificados de
organizações, desde pequenas empresas de caráter individual, englobando também
organizações sem fins lucrativos e alcançando até grandes companhias de relevância mundial.
Nesse contexto, este artigo busca analisar e comparar a aplicação da metodologia de
Gestão Projetos de Softwares, Ágeis frente a Tradicionais em Cascata. Os primeiros
resultados indicam que existem diferenças nos resultados entre projetos que tem atividades
orientadas por uma ou outra metodologia, assim, se faz de extrema relevância discutir
problemas e vantagens nas metodologias tradicionais na gestão de projetos na indústria da
construção civil frente as novas metodologias de projetos Ágeis. Desta forma, esta pesquisa
sinalizará a imperativa adaptação das empresas do setor na busca por maior competitividade.
Diante do explicitado, para concretizar este estudo, primeiramente analisam-se as
literaturas pertinentes aos Métodos em Cascata e SCRUM. Logo após, diagnosticam-se a
atual metodologia de gestão e convivência em obra. Seguem-se comparando a Metodologia
Tradicional à Ágil e, por último, demonstram-se as vantagens e desvantagens entre os dois
modelos;

2 – METODOLOGIAS TRADICIONAIS (MODELO CASCATA)

Figura 1

É considerado como o modelo mais básico de ciclo de desenvolvimento e é uma

abordagem linear e sequencial para o desenvolvimento de um produto ou serviço. Neste
modelo, cada processo necessita ser completado antes de passar ao próximo. O progresso é
comparado a uma “cascata” e justamente é o nome deste modelo. Como nas cascatas naturais,
onde uma vez que a água fluir morro abaixo, não retorna nunca mais ao topo, da mesma
forma o progresso no modelo em cascata nunca pode ser revertido, ou seja, não podemos
nunca retornar a uma fase anterior, temos apenas uma opção que é seguir em frente. Este
modelo também é chamado de metodologia de ciclo de vida clássico, ou simplesmente,
Metodologia Tradicional, uma vez que sugere uma abordagem sistemática sequencial e
clássica para o desenvolvimento de um projeto. Em um processo em cascata, normalmente um
relatório é a saída de cada fase que serve como entrada para a próxima fase. Os membros da
equipe não podem alterar as saídas que o projeto certificou. No entanto, os requisitos estão
sujeitos a alterações. Existe, portanto, a necessidade de um mecanismo que garanta que as
modificações sejam feitas de maneira controlada, sem afetar o produto e seu progresso.
Empresas como a Toyota usam esse modelo para desenvolvimento. As fases de um modelo
em cascata podem ser generalizadas nos pontos a seguir.

2.1. FASE DE ESPECIFICAÇÃO E ANÁLISE DE REQUISITOS

É provavelmente a fase mais propensa a erros, demorada e cara. Esta fase visa
entender, reunir e documentar os requisitos do usuário/proprietário. Requisitos do usuário são
a principal razão para o desenvolvimento de softwares e, portanto, são necessários ser
observados com precisão, para nossa realidade, da construção civil, os usuários são desde
proprietário, funcionários, arquitetos até futuros usuários de um determinado
empreendimento. O levantamento é um esforço conjunto dos clientes e desenvolvedores, pois
o objetivo é documentar todas as funções, desempenho e requisitos do projeto. Esta fase leva
ao desenvolvimento de um grande documento escrito em linguagem natural e que contém o
“quê” do sistema sem descrever o “como”. Esse documento resultante é chamado de
documento de especificação de projeto (DEP). O DEP pode atuar como um contrato entre o
construtor e o cliente. Em caso de falha no cumprimento dos requisitos do DEP, o resultado
final pode ser considerado uma falha.

2.2. FASE DE PROJETO

O documento DEP produzido no estágio anterior serve como entrada desta fase. Os
requisitos devem ser transformados em uma estrutura adequada para projeto e implementação
em alguma linguagem de projeto adequada. A arquitetura geral é definida e o trabalho
detalhado e de alto nível é executado. O trabalho / processo é documentado e é conhecido
como o documento de descrição de projeto (DDP). O DDP pode conter jargões técnicos e
também informa sobre o “como” do Projeto. As informações fornecidas no DDP devem ser
suficientes para iniciar o projeto.

2.3. FASE DE IMPLEMENTAÇÃO E TESTE

Com base nas informações fornecidas pelo DDP, os projetistas precisam começar a
construir / desenvolver. Se o DDP contiver todas as informações necessárias e for completo,
consistente e preciso, essa fase deve ocorrer sem problemas. O teste se concentra no exame,
correção e modificação do projeto se necessário. Em testes de unidades, testamos parte a parte
uma por vez, independentemente da outra. Normalmente, esse processo de integração e teste
do sistema exige a reformulação dos módulos para corrigir problemas na operação ou
interações das peças, devido a problemas imprevistos, erros, falhas de comunicação ou
alterações que ocorreram no design durante o projeto. Se esse trabalho de integração for bem,
a equipe enviará o produto quando não houver problemas sérios (erros ou defeitos).

2.4. FASE DE IMPLANTAÇÃO

O testes apresentam os seguintes problemas a) Como testamos módulos individuais
sem uma função? b) Não nos diz nada sobre como diferentes módulos interagem uns com os
outros. O teste do sistema/ implantação supera esse problema testando como um todo. Testes
efetivos garantirão maior qualidade, usuários mais satisfeitos, menor custo de manutenção e
resultados mais precisos e confiáveis. Essa fase é uma atividade muito cara e consome até
metade do custo do orçamento total.

2.5. FASE DE OPERAÇÃO E MANUTENÇÃO

É a fase que vem depois que o projeto foi lançado, instalado e está operacional. A fase
de manutenção começa com o próprio lançamento e continua durante todo o ciclo de vida do
projeto. A manutenção de inclui correção de erros, aprimoramento de funções e capacidades,
introdução de novas funções, remoção de funções obsoletas e otimização.

2.6. DESVANTAGENS DO MÉTODO

1. Exige que todos os requisitos sejam especificados logo no início, o que não é possível para
projetos da vida real, principalmente porque os clientes são notórios por alterar seus requisitos
declarados. Além disso, a menos que os desenvolvedores e os especificadores de requisitos
sejam altamente qualificados, é difícil saber exatamente o que é necessário para uma fase até
que se esteja algum tempo nessa fase. Assim, deve-se ser altamente flexível e adaptável
levando em consideração que os requisitos estão sujeitos a alterações.
2. Como o modelo é linear, ele não permite que as alterações sejam acomodadas.
3. Um produto em funcionamento não está disponível até passar por todas as etapas.
4. Projetos reais raramente são seqüenciais e, portanto, o modelo em cascata não é bem
dimensionado para grandes projetos.
5. Não acomoda riscos e incertezas. A menos que haja iteração e feedback, pode não haver
maneira de melhorar as imperfeições iniciais em uma das fases posteriores.
6. É um modelo pobre para projetos grandes e em andamento.
7. É difícil medir o progresso em todas as etapas do modelo, pois o tempo e o custo incorridos
por cada fase não são determináveis.
8. A integração é feita no final, o que não ajuda na identificação de desafios e gargalos nos
negócios no início do ciclo de vida.
9. Muito tempo é desperdiçado enquanto se espera que uma fase seja concluída. Por exemplo,
quando os designers estão ocupados projetando, o tempo do construtor é desperdiçado. Testes
constantes do projeto, sua implementação e verificação de cada fase são necessários para
validar as fases que os precedem. Alguns podem argumentar que, se seguirmos um processo
projetado e não permitirmos qualquer espaço para erros, não será necessário validar
constantemente as fases anteriores.
10. Coordenação do trabalho de um grande grupo de pessoas construindo diferentes
componentes, requer um alto nível de gerenciamento que o simples sequência de atividades
no modelo em cascata não pode garantir. Implementar essa sincronização e, simultaneamente,
fornecer a quantidade necessária de liberdade talvez seja um problema enfrentado pelos
gerentes.

2.7. VANTAGENS DO MÉTODO

1. A principal vantagem do modelo em cascata ou ciclo de vida é que ele fornece uma
estrutura para organizar e controlar um projeto de desenvolvimento.
2. Os detalhes do projeto e os erros são capturados pelo modelo antes de qualquer projeto ser
entregue e, portanto, economizar tempo durante o desenvolvimento.
3. É feito um documento técnico adequado que facilita ou que os clientes saibam o que devem
esperar. A documentação também ajuda no processo de manutenção.
4. Se o procedimento for seguido corretamente, a estimativa de custo e tempo pode ser feita
com precisão.
5. Devido à sua natureza seqüencial e linear, falhas em uma fase podem ser detectadas antes
de passar para a outra.
6. Muita ênfase é feita na papelada. Qualquer novo funcionário que ingressar na equipe de
desenvolvimento pode achar fácil acompanhar com a ajuda desses documentos.
7. Para projetos menores, é o melhor modelo a ser usado. Também requer menos recursos em
comparação com os outros.
8. Permite a departamentalização e controle gerencial. Isso permite que o produto seja
concluído no prazo, definindo um cronograma para cada fase.
9. Um plano de projeto pode ser utilizado para projetos indistinguíveis ou comparáveis no
futuro. É melhor para projetos que lidam com entregas orientadas a serviços e não físicos,
como projetos de código, copywriting e design.

2.8. QUANDO USAR O CASCATA?

1. Quando uma imagem clara do produto final estiver disponível.
2. Quando os requisitos são bem definidos e compreendidos e não estão sujeitos a alterações.
3. Quando o interesse é sobre o produto final a ser desenvolvido em vez de ser a preocupação.

3 - METODOLOGIA ÁGIL (MODELO SCRUM)

Figura 2

O desenvolvimento ágil é, em si, um enorme termo abrangente que inclui outras

metodologias ágeis também. Estes incluem inicialmente o Scrum, XP, Crystal, FDD e
DSDM. No entanto, metodologias ágeis enxutas também foram incluídas, pois surgiram como
valiosas metodologias ágeis no passado. Os modelos ágeis foram projetados especificamente
para manter a adaptabilidade das necessidades de mudança em mente. Um método ágil é uma
combinação de modelos de processo iterativo e incremental, tendo em mente a flexibilidade e
a entrega no prazo do software. Os modelos ágeis consideram cada processo de
desenvolvimento diferente e acreditam que os métodos existentes precisam ser personalizados
para atender melhor aos requisitos do projeto. O SCRUM fornece métodos para avaliar o
desenvolvimento e os riscos e também a direção durante todo o ciclo de vida do
desenvolvimento.
Assim, ao longo da efetivação de cada iteração (Sprint), segundo Schwaber e
Sutherland (2009), os envolvidos executam reuniões diárias de mais ou menos quinze minutos
de extensão intituladas reunião diária (Daily Scrum Meeting), com o propósito de conduzir o
desenvolvimento do projeto. Na conclusão de cada iteração é efetuada uma reunião,
denominada de reunião de revisão (Sprint Review Meeting), com o intuito da equipe explicitar
um aperfeiçoamento “entregável” do projeto ao cliente/proprietário (Product Owner).
Posteriormente, o Gerente (Scrum Master) realiza uma reunião com os envolvidos
denominada de reunião de retrospectiva (Sprint Retrospective Meeting). O Sprint
Retrospective Meeting possui como objetivo examinar a realização do desenvolvimento do
projeto e a versão do produto concebida, tendo em vista aprimorar a equipe, o processo ou o
produto para o próximo Sprint.

O produto é desenvolvido em uma série de rodadas e envolve várias equipes

trabalhando simultaneamente em várias áreas, como coleta de requisitos, análise de requisitos,
planejamento, projeto, codificação e teste. Cada iteração garante um aprimoramento nos
recursos do produto da iteração anterior e o produto de iteração final envolve todos os
recursos exigidos pelo cliente. O Google Agile trabalha com as seguintes abordagens:
1. Indivíduos e Interações - Em agilidade, auto-organização e encorajamento são tão
importantes quanto as interações como programação em pares e co-localização.
2. Trabalhar com o modelo Ágil requer a necessidade de desenvolver um protótipo funcional
no início da vida de um software e esse protótipo é geralmente a melhor maneira de se
comunicar com os interessados que não podem apreciar o "como" dos jargões técnicos e de
software.
3. Envolvimento do Cliente - Como não requer todos os requisitos no início do software, ele
depende da interação com o cliente durante todo o desenvolvimento.
4. Adaptabilidade Rápida - Deve ser capaz de se adaptar rapidamente às mudanças de
requisitos e de acordo com a necessidade do desenvolvimento adequado e oportuno do
software. Essa técnica de “inspecionar e adaptar” diminui significativamente os custos de
desenvolvimento e o tempo de envio. As equipes podem começar a desenvolver seu software
em coro com o processo de coleta de requisitos, o que reduz o impacto da "paralisia de
análise" no progresso. O ciclo de trabalho de uma equipe é limitado a duas semanas, pois as
partes interessadas têm oportunidades freqüentes de regular as liberações para o sucesso.
Permite que as empresas aprimorem constantemente seus produtos e planejem seus
lançamentos para uma melhor aceitação e maior sucesso. Por isso, o modelo garante que o
esforço colocado não seja desperdiçado e que a relevância do mercado de produtos não caia e
que o trabalho das equipes não acabe em uma prateleira, inédita. Uma equipe ágil adaptativa
terá dificuldades em descrever quanto progresso será observado na próxima iteração ou,
provavelmente, quais riscos podem ser encontrados, mas pode ser capaz de identificar quais
são as funcionalidades que serão adicionadas ao produto. Quanto mais longe o prazo, mais
vaga é a ideia. Cada equipe ágil contém um representante do cliente que é escolhido pelas
partes interessadas para operar em seu nome e estar disponível para responder às perguntas
dos desenvolvedores. No final de cada iteração, as partes interessadas e o representante do
cliente avaliam o progresso e reavaliam as prioridades para otimizar o retorno sobre o
investimento e para um melhor alinhamento com as necessidades do cliente e os objetivos da
empresa. Empresas como a Pivotal Labs, Microsoft, RailsCarma, etc. usam o modelo de
desenvolvimento Ágil.

3.1. DESVANTAGENS
1. Não é adequado para lidar com dependências complexas e tem mais risco de
extensibilidade, sustentabilidade e facilidade de manutenção. No caso de algumas entregas de
software, é difícil avaliar o esforço no início do processo.
2. Embora não exija uma fase inicial de planejamento, ainda é necessário um plano geral de
desenvolvimento. Um bom sistema de gerenciamento, um líder ágil e prática de
gerenciamento de projetos é necessário. Sem eles, o projeto pode não funcionar.
3. A conclusão do trabalho dentro de um período estrito de tempo com boa qualidade e
requisitos especificados dificulta o gerenciamento.
4. O envolvimento do cliente é uma obrigação. Sem a cooperação dos usuários, o processo de
desenvolvimento seria dificultado e poderia levar ao fracasso.
5. Não há importância na documentação e, portanto, qualquer novo membro que se junte à
equipe pode achar difícil de se encaixar. Também os membros da equipe existentes podem
precisar fazer referência ao documento de especificação de projeto (DEP) e sua ausência pode
levar o desenvolvimento a uma direção errada.
6. Algumas decisões exigem a experiência dos desenvolvedores de software sênior; portanto,
os desenvolvedores iniciantes não são realmente bem-vindos, a menos que sejam combinados
com recursos experientes.
7. Devido ao desenvolvimento em iterações, erros e riscos são identificados no início.
8. Não adequado para projetos com requisitos e escopo estritamente definidos.

3.2. VANTAGENS
1. Ele leva em consideração os requisitos e a natureza mutável do desenvolvimento e,
portanto, se adapta bem a projetos da vida real, independentemente de seus tamanhos.
2. Promove o trabalho em equipe. Todos os envolvidos no processo de desenvolvimento
trabalham juntos simultaneamente em diferentes áreas.
3. Um produto funcional está disponível nas fases iniciais.
4. Ágil não dita a necessidade de documentar o trabalho e regras mínimas são empregadas.
Também requer a quantidade mínima de recursos em comparação com outros modelos.
5. Torna o planejamento apenas uma fase voluntária e torna o processo fácil de gerenciar e
flexível.
6. Desenvolvedores e clientes se comunicam constantemente uns com os outros e a interação
com os clientes é mais importante do que o processo e as ferramentas. Isso também ajuda na
compreensão do que os usuários esperam do produto final.
7. Melhor para projetos que lidam com entregas orientadas a serviços e não físicas, como
projetos de código, copywriting e design.

3.3. QUANDO USAR ÁGIL

1. Quando os requisitos não são bem especificados ou quando se espera que os requisitos
mudem durante as fases posteriores do processo de desenvolvimento. No ágil, novas
mudanças podem ser implementadas a um custo muito baixo, devido à frequência de novos
incrementos que são produzidos.
2. Se a liberdade de opções e tempo é exigida pelos desenvolvedores e pelas partes
interessadas. Ter opções proporciona a elas a possibilidade de deixar decisões importantes até
que mais ou melhores dados estejam disponíveis e também que o projeto possa ser continuado
sem o medo de ser um fracasso.
4 - METODOLOGIA AGIL VS TRADICIONAL
Os métodos ágeis são considerados no extremo oposto do arco-íris dos métodos
"orientados pelo plano" ou "disciplinados". Projetos geralmente são considerados entre a faixa
“adaptativa” a “disciplinada”. Métodos ágeis ocupam a banda “adaptativa”. Uma equipe ágil
adaptativa terá dificuldades em descrever quanto progresso será observado na próxima
iteração ou, provavelmente, quais riscos podem ser encontrados, mas pode ser capaz de
identificar quais são as funcionalidades que serão adicionadas ao produto. Quanto mais longe
o prazo, mais vaga é a ideia. Já o modelo em cascata é preditivo e, em contraste com o
modelo ágil, concentra-se no planejamento para o futuro bem antes do tempo. Uma previsão
pode dizer exatamente como e por quanto o software vai se desenvolver e quais mudanças
podem ser observadas. No entanto, as equipes preditivas não estão prontas para alterações não
identificadas ou não aceitas e têm dificuldade em se ajustar a elas. O plano está definido e
acomodar novas alterações pode significar que o processo tenha que ser iniciado novamente.
Por causa de tal problema, apenas as mudanças mais importantes receberão uma chance de
serem implementadas.

4.1 - QUAL A SUA METODOLOGIA?

Use o Agil se ...
1- Os requisitos e funções estão sujeitos a alterações.
2- O produto precisa ser desenvolvido em um tempo limitado.
3- Um protótipo rápido com apenas certas funcionalidades é necessário antes que o
produto final esteja disponível.
4- Ágil requer a participação ativa das partes interessadas.
5- Se a equipe estiver trabalhando de maneira altamente colaborativa e auto-
organizada. A auto-organização garante que os membros da equipe estejam
planejando e estimando ativamente seu próprio trabalho.
6- Se a equipe estiver disposta a desenvolver o software em parcelas.

Use o Cascata se ...

1- Os requisitos são bem definidos e fixados.
2- Não há limite de tempo ou uma quantidade razoável de tempo está disponível para
desenvolver o software.
3- Existe a necessidade de documentar tudo.
 4- Você precisa de um software seguro com um alto nível de confiabilidade.
5- Você deseja usar o software finalizado.
6- Você não tem recursos para o trabalho cotidiano face-a-face.

4.2 - SEMELHANÇAS
1. Ambos fornecem métodos, ferramentas, técnicas e processos bem definidos.
2. Ambos exigem uma abordagem disciplinada e têm um tempo de conclusão pré-
decidido.
3. Ambos querem a satisfação do cliente e querem aderir ao tempo e ao cronograma
decididos.

5 - ESTUDO DE CASO DAS CLINICAS

Muitas empresas começaram a se desviar do estilo cascata e a fazer mudanças para
melhorar sua capacidade de controlar as alterações nos projetos. Uma dessas empresas é a
Konzept Engenharia LTDA. À medida que o apoio ao cliente se expandia, havia a
necessidade de desenvolver produtos de qualidade e os problemas de entrega tornavam-se
inaceitáveis. O desafio que a Konzept estava enfrentando era introduzir mais estrutura e
previsibilidade em suas práticas de desenvolvimento vagamente organizadas e ainda ter
flexibilidade e criatividade. A empresa queria um processo diferente que permitisse uma
abordagem incremental para projetar, responder a entradas do cliente, construir protótipos e
permitir alterações. A Konzept inclui as seguintes fases no desenvolvimento de seus projetos.
1. Revisão e Planejamento - O número de liberações necessárias é planejado com uma
explicação sobre por que a liberação específica é necessária e suas interdependências com
outras partes do projeto. A equipe de marketing cria previsões de vendas com base nos planos
de projeto. O orçamento é então planejado e o lucro esperado é calculado. Com base nessa
análise, uma contagem de cabeças é determinada.
2. Desenvolvimento - Divide o desenvolvimento em três ou quatro marcos, onde cada
marco tem sua própria fase de desenvolvimento e teste. Agrupamentos de recursos
determinam os marcos. As características mais difíceis e importantes são construídas primeiro
em contraste com os tradicionais, onde o foco está na implementação completa das
especificações. Como um resultado, as peças são colocadas três ou quatro vezes durante o
desenvolvimento, com atividades de teste, depuração e integração, todas feitas em paralelo em
cada etapa. Também é assumido que as especificações podem mudar, portanto, nenhum
documento de especificação é feito no início de um projeto. Cria um "asbuild" do projeto
todos os dias.
3.Fase Teste - baseia-se fortemente em testes manuais diárias. O teste inclui
documentação, tutoriais, e utilitários de suporte. Além disso, três tipos de testes são usados
para garantir uma melhor aceitação.
3.1. Divide os produtos grandes em peças controláveis menores (que podem
ser criadas em poucos meses).
3.2. Permite que os projetos sigam metodicamente, mesmo quando um produto
complexo e instável
3.3. Permite que equipes grandes trabalhem como pequenas equipes, dividindo
o trabalho em partes, organizadas em paralelo, mas sincronizadas e incrementais.

5.1 PROJETO A
O Projeto A consistiu na construção de uma clínica de 4 pavimentos no centro de São
Luís - MA, este projeto foi realizado no biênio 2015/2016 tendo uma duração total de 14
meses. Neste período, a empresa utilizava ainda o modelo de gestão tradicional de projetos
(método em cascata). Já havia um forte controle no planejamento e administração de
atividades para a prevenção de perturbações nos custos previstos e nos prazos pré-
determinados, tendo em vista que são dois dos aspectos mais exigidos pelos clientes.
O projeto foi executado exatamente conforme o documento de especificação de
projeto (DEP), cumprindo rigorosamente o prazo inicial, houve um acréscimo nos custos
devido a acréscimos e modificações propostas pelos proprietários, mas foram absorvidas nos
prazos preestabelecidos em projeto sendo.

5.2 PROJETO B
O Projeto B consisti na reforma de ima clínica de 2 pavimentos no bairro do
cohatrac em São Liís - MA, este projeto foi realizado no biênio 2017/2018 tendo ima
diração total de 7 meses. Como reqiisito essencial para o projeto foi estabelecido qie a
clínica não fecharia para realização da reforma, manteria fincionamento normal em im dos
pavimentos, sendo feito im por vez.

Neste período, a empresa migroi para im modelo de gestão ágil de projetos

(método SCRUM). Havia um forte interesse na diminuição de custos e prazos, tendo em vista o
período de crise em que o setor passava. Ainda era um período de adaptação e busca por
conhecimento nesta nova metodologia e o projeto pela sua própria estrutura demonstrava-se
ideal para esta migração.

O projeto foi executado cumprindo rigorosamente o prazo inicial, houve também um

acréscimo nos custos devido a acréscimos e modificações propostas pela proprietária, mas
foram absorvidas nos prazos preestabelecidos em projeto.

5.3 COMPARATIVO PROJETOS A E B

É possível inferir que o projeto B, em decorrência do emprego do métodos ágil,
reduziu os períodos dos ciclos, melhorou a administração do empreendimento, propiciando
que os gestores participem das revisões e do desenvolvimento do cronograma, aumentou a
frequência dessas reuniões e também possibilitou mudanças dentro do projeto.
E mesmo com uma maior quantidade de restrições quanto, barulho, poeira e
funcionamento do estabelecimento, houve uma expressiva redução no prazo e custos gerais da
obra. Porém, mesmo fazendo uso do Scrum ainda existem deficiências na prevenção do
desperdício, tanto no número de atividades irrelevantes quanto na restrição dos desperdícios
provenientes de suas atividades. E um dos objetivos desses estudo é a construção de materiais
de treinamento dentro da própria organização

6 - CONSIDERAÇÕES FINAIS
Cada projeto é diferente e requer um tratamento diferente. Portanto, é melhor não se
apegar a uma metodologia específica, os desejos da empresa e o projeto estão sujeitos a
mudanças regulares, e é preciso ser flexível em como abordar esses projetos para que eles
sejam bem-sucedidos. Nenhuma metodologia é infalível, então o segredo é determinar qual
método funciona e adequá-lo às necessidades individuais.
Abstract

STUDY OF PROJECT MANAGEMENT MODELS APPLIED TO CONSTRUCTION:

comparative case between traditional and agile model

Every business needs to follow a well-defined methodology for proper

development of their projects. Software development models have helped many construction
companies too complete projects of good quality, in time and cost. Two methodologies widely
used in other areas are discussed in this article. This article also discusses its use along with
its pros and cons. The projects development at Konzept Engineering LTDA is also discussed.

Keywords: Life Cycle of Projects. Traditional models. Waterfall model. Agile

models. SCRUM
 REFERÊNCIAS

DR. VERMA, Seema, KANNAN, V., JHAJHARIA, S. (2014). Agile vs Waterfall: A

Comparative Analysis. International Journal of Science, Engineering and Technology
Research (IJSETR), Volume 3, Issue 10, October 2014

Ferreira, D., Costa, F., Alonso, F., Alves, P., & Nunes, T. (2005). SCRUM – Um modelo ágil
para gestão de projetos de software. Recuperado em 17 dezembro, 2018, de
http://paginas.fe.up.pt/~aaguiar/es/artigos%20finais/es_final_19.pdf.

FROTA, Filipe R., WEERSMA, Laodicéia, WEERSMA, Menno, Método de Projetos Ágeis
Aplicado ao Setor de Construção Civil: Caso Comparativo entre Construtoras de Médio Porte.
V Simpósio Internacional de Gestão de Projetos, Inovação e Sustentabilidade ( V SINGEP),
São Paulo – SP – Brasil

Leal, L. (2008). Uma abordagem ágil ao gerenciamento de projetos de software baseada no

PMBOK Guide. Tese de mestrado, Universidade Federal de Pernambuco, Pernambuco, PE,
Brasil.

Malik Hneif and Siew Hock Ow “Review Of Agile Methodologies In Software

Development”, International Journal of Research and Reviews in Applied Sciences ISSN:
2076-734X, October 2009

Michael A. Cusumano and Stanley Smith “Beyond the Waterfall:Software Development at

Microsoft”, August 16, 1995

Neves, A. (2010). Agilidade e lean construction – metodologia de planeamento e controlo da

produção baseada na integração de práticas ágeis com a filosofia Lean. Tese de Mestrado,
Instituto Superior Técnico, Lisboa, Portugal.

Schwaber, K. (2004). Agile project management with Scrum. Microsoft Press, USA.

Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum. Prentice-Hall,

New Jersey.

Schwaber, K., & Sutherland, J. (2009). Scrum guide: developed and sustained. Recuperado
em 17 março, 2016, de http://www.scrumguides.org/.

Youssef Bassil ” A Simulation Model for the Waterfall Software Development Life Cycle”
International Journal of Engineering & Technology (IJET), ISSN: 2049-3444 May 2012
http://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Process/Agile_Model