O que faz um Gerente de

projetos ou e um Scrum
Master?
Veja nesse artigo o que cada profissional faz e cada
tipo de organizao precisa deles. Veja tambm
quais suas tarefas e atribuies no dia a dia do
trabalho.
2

Gostei (0)
(0)

Fique por dentro

Tem sido uma prtica constante a publicao de vagas e
oportunidades de trabalho para Gerentes de Projeto requerendo
conhecimentos em metodologias geis e, da mesma forma, os
anncios solicitando profissionais ScrumMaster os quais possuam
conhecimentos sobre a metodologia PMI. Estamos abordando dois
papis fundamentais no processo de desenvolvimento de software,
porm, as organizaes que esto procura de um profissional
devem saber qual papel e quais so os requisitos de conhecimento
mais adequados s necessidades da organizao. Este artigo visa
esclarecer as diferenas entre estes papeis e auxiliar na escolha do
papel mais adequado para a organizao.
Definir escopo, estabelecer planos para o projeto, criar a lista de
atividades e subatividades, estabelecer cronograma, identificar riscos,
avaliar e orar o impacto dos riscos no projeto, calcular os custos
humanos e materiais, estabelecer os marcos do projeto, estabelecer
os indicadores de acompanhamento do projeto, compor o plano de
faturamento ao cliente ou ao patrocinador, administrar o oramento,
criar e manter um plano de comunicao, obter os aceites e interagir
com o departamento financeiro da empresa para gerar as faturas e
acompanhar a liberao dos pagamentos junto ao cliente, entre

outras responsabilidades. Estes so alguns exemplos das atribuies

de um Gerente de Projetos segundo o PMI (Project Management
Institute). Se ao ler estes pontos descritos anteriormente e no pode
reconhecer ou no entender o significado deles porque talvez no
esteja familiarizado com os processos de gerenciamento de projetos.
Este desconhecimento por parte dos executivos muito maior do que
se imagina.
Segundo o relatrio anual do Standish Group, o Chaos Manifesto do
ano de 2012, o papel do Patrocinador foi questionado, pois caso o
Executivo no possua determinadas caractersticas, ele no ter
condies de atuar em plenitude e poder colocar em risco ou at
condenar os projetos da empresa ao fracasso. No relatrio emitido
pelo Standish Group, foi dedicado um bom espao para abordar os
principais aspectos dos quais um Executivo deva possuir para poder
desempenhar plenamente suas funes e elevar o nvel de sucesso
dos projetos de sistemas como um todo. Em dois tpicos, o relatrio
do Standish Group abordou a personalidade e a conduta dos
patrocinadores e/ou executivos.
Dentre todos os tpicos, um dos que chamam ateno foi o
dedicado avaliao da conduta dos Executivos. Nesta avaliao
foram considerados itens como: a personalidade do executivo (uma
espcie de DNA de sua maneira de comandar), as experincias do
executivo (os diferentes tipos e condies de projetos em que o
executivo participou) e, o que necessrio saber para ser tornar um
bom executivo (conhecimentos e habilidades). O resultado deste
estudo demonstrou 50 pontos, chamados de segredos, que um
executivo deve possuir para ser considerado como timo.
Dentre estes 50 segredos, um dos que mais chama a ateno foi o
segredo de nmero 3 intitulado como Entendimento dos Processos
de Gerenciamento de Projetos. Neste tpico, a avaliao realizada
demonstrou o nvel de dificuldade de entendimento por parte dos
executivos quanto aos processos de gesto de projetos. Apenas 17%
dos executivos avaliados consideraram no ter dificuldades em
entender os processos de gerenciamento dos projetos (Figura 1), ou
seja, 83% dos executivos no entendem o que est sendo discutido
em termos dos processos e respectivas atividades envolvidas.
Diante deste cenrio, quase impossvel a interao em plenitude de
algum a qual possua a responsabilidade de decidir e ordenar sobre
um assunto do qual falta o devido conhecimento.

Figura 1. Percentual de Dificuldade de Entendimento sobre os

Processos de Gesto de Projetos.
Desta forma, se faz necessrio entender o propsito dos processos de
gesto de projetos, firmando o conhecimento da definio de projeto
e as abordagens das metodologias que surgiram com objetivo
principal de aumentar as chances de sucesso dos projetos. Em se
tratando de Engenharia de Software, de desenvolvimento de
sistemas, a adoo destas metodologias vem se tornando cada vez
mais indispensvel para que se alcancem melhores resultados.
Dentro de um projeto, existem papis e responsabilidades e estes,
so a base para a execuo do processo. Estamos falando das
pessoas, dos membros da equipe os quais sero responsveis por
diferentes partes e em diferentes momentos no decorrer do projeto.
Depois de entendermos as metodologias, os papis de cada um,
iremos contextualizar a aplicao do papel do Gerente de Projetos e
do ScrumMaster em um projeto de desenvolvimento de software.
Desta maneira, os executivos de sua organizao tero uma ideia
clara do perfil mais adequado a ser contratado de acordo com as suas
necessidades, sua realidade operacional.
O papel do gerente de projeto, qual o objetivo das metodologias
geis, o papel do ScrumMaster e, em uma abordagem prtica,
verificar onde os papis so corretamente aplicados para a execuo
de projetos de engenharia de software.

Definio de Projeto
Segundo oPMBOK (Project Management Body of Knowledge livro
reconhecido como o Corpo de Conhecimentos sobre Gesto de

Projetos), publicado e mantido pela instituio americana PMI

(Project Management Institute), em linhas gerais, projeto um
esforo temporrio empreendido para alcanar um objetivo
especfico. Projetos so executados por pessoas, geralmente tm
limitaes de recursos e so planejados, executados e controlados.
Um projeto cria um produto, servio ou resultado especfico.
Construir uma nova estrada, uma praa de pedgios, um novo
sistema de gesto de recursos, uma escola, um novo servio de
atendimento, so bons exemplos de projetos. Neste momento,
importante ressaltar a diferena entre Projeto e Operao. Operao
uma ao em si, o ato de fazer alguma coisa de forma padronizada
e repetitiva, so as aes que sustentam as atividades comerciais.
Outro exemplo de projeto, aquele que objetiva alcanar um resultado
especfico pode ser considerado como um projeto de melhoria. Um
projeto sobre algo que j existe e que pode ser modificado de forma
a gerar melhores resultados ou atender a mudanas de necessidades
(requisitos).
Agora que o termo projeto est definido, precisamos entender como
os projetos so executados / conduzidos. Para tanto, preciso
entender as metodologias voltadas para este tema. Metodologias so
conjuntos de processos (aes) e ferramentas que auxiliam na
execuo de uma determinada atividade.

Viso geral sobre Gerenciamento de

Projetos
De acordo com oPMBOK, Gerenciar Projetos a aplicao de um
conjunto de conhecimentos, habilidades, ferramentas e tcnicas de
forma que as atividades do projeto alcancem seus requisitos.
Significam os itens imprescindveis os quais aumentam as chances de
sucesso dos projetos de atingirem os objetivos estabelecidos.
O PMBOK estabelece que o Gerenciamento de Projetos deve ser
realizado atravs da correta aplicao e integrao de 47 processos
organizados e agrupados em cinco grupos de processos. Os cinco
grupos de processos so:

Iniciao;
Planejamento;
Execuo;
Monitoramento e Controle;
Encerramento.

Gerenciar projetos comumente inclui (mas no se limitam) a:

Identificar requisitos;
Enderear as diversas necessidades, preocupaes e
expectativas das Partes Interessadas (Stakeholders) durante o
planejamento e execuo do projeto;
Estabelecer, manter e distribuir a comunicao entre as partes
interessadas, de forma colaborativa e eficaz;
Gerenciar as Partes Interessadas (Stakeholders) no sentido de
cumprir os requisitos do projeto e criar os entregveis (as
entregas) do projeto;
Balancear as limitaes concorrentes do projeto, que incluem
(mas no se limitam) a:
o Escopo;
o Qualidade;
o Prazo;
o Oramento;
o Recursos;
o Riscos.

Nota
As limitaes do projeto (constraints) esto completamente
interligadas e devem estar totalmente balanceadas. Caso uma destas
limitaes seja afetada, automaticamente as demais tambm sero.
Por exemplo, se o Escopo for ampliado, consequentemente, ser
necessrio mais tempo (prazo), aumento nos processos de qualidade,
aumento no custo (oramento), aumento do uso dos recursos e,
aumentam-se os riscos.

Contexto do Gerenciamento de
Projetos
De acordo com oPMBOK, podemos ampliar a viso da Gesto de
projetos agrupando os projetos atravs de Programas, Portflios e o
Escritrio de Projetos, mais conhecido como PMO (Project
Management Office).
Programas uma forma de agrupar projetos relacionados
gerenciados de uma maneira coordenada, com objetivo de obter
benefcios e controles que no seriam possveis caso fossem
gerenciados individualmente. Para gerir os Programas, existe o
conceito de Gerenciamento de Programas. Um bom exemplo de
programa seria o desenvolvimento de um novo modelo de carro,
onde podem ser criados projetos independentes para seus
componentes como motor, cambio, freios, etc. Os programas ainda

podem ser decompostos em subprogramas. Os subprogramas geram

projetos mais especializados de forma que possam ser mais bem
gerenciados.
Portflios so conjuntos de projetos ou de programas os quais so
agrupados para facilitar o gerenciamento eficaz do trabalho para
alcanar os objetivos estratgicos da organizao. Voltando ao
exemplo do programa de um novo modelo de carro, o portflio pode
ser criado para novos modelos de carro do tipo utilitrios, ou novos
motores, etc. Os Portflios tambm podem ser organizados e
subdivididos em sub portflios, de maneira a facilitar a gesto e
aumentar a eficincia de seus resultados.
O escritrio de Projetos, o PMO, uma estrutura gerencial cuja
funo a de padronizar os processos de governana relacionados a
projetos. Esta estrutura facilita o compartilhamento de recursos,
metodologias, ferramentas e tcnicas. Dentre as responsabilidades do
PMO esto, desde o suporte aos gerentes de projeto, fornecer
treinamento e capacitao, gerir conflitos e at mesmo, responder
pela gesto de projetos, portflios ou programas.

Vantagens em se trabalhar com

Projetos
A presso comercial para que as empresas tenham mais
lucratividade, reduzindo custos e aumentando a eficincia,
potencializado pelos fatores da globalizao remetem a necessidade
das empresas serem mais geis. A estrutura tradicional altamente
burocrtica e a experincia tem mostrado que essa estrutura no
pode responder de modo suficientemente rpido a um ambiente em
constante mudana. Por isso, a estrutura tradicional deve ser
substituda pelo gerenciamento de projetos, ou outra estrutura
temporria de gesto que seja altamente orgnica e que possa
responder muito rapidamente conforme as situaes se apresentarem
internamente e externamente empresa. O gerenciamento de
projetos tem sido amplamente discutido por executivos e acadmicos
como uma das possibilidades exequveis para modelos
organizacionais futuros que poderiam integrar esforos complexos e
reduzir a burocracia.
Uma empresa tem como opo trabalhar de forma projetizada
(orientada a projetos). Originalmente, as empresas trabalhavam de
forma funcional. Uma vez que definimos o conceito de projetos e a
maneira com que eles devem ser tratados pelas organizaes, cabe o
entendimento de como as organizaes esto estruturadas e qual

deve ser a abordagem para a adoo de uma estrutura orientada a

projetos.

Saiba identificar o tipo da Organizao

onde voc trabalha
As organizaes estabelecem suas estruturas de forma a obterem
uma melhor maneira de administrar seus recursos humanos,
materiais e financeiros possibilitando atingir de forma mais eficiente
seus objetivos comerciais. Basicamente, existem trs estruturas
organizacionais: funcional, projetizada e a matricial.
A estrutura organizacional funcional prega que cada funcionrio
possui um superior e que as equipes esto organizadas por funo
exercida (por exemplo: finanas, produo, jurdico). Empresas de
menor porte esto mais suscetveis a adotarem esta estrutura
funcional como um posto de gasolina, borracharia ou um pequeno
comrcio.
Na estrutura organizacional projetizada, existem os departamentos e
cada um deles possui um gestor de projetos para conduzir seus
prprios projetos contando com o apoio de outros departamentos.
Esta abordagem traz tona a questo da concorrncia dos recursos
dos departamentos de apoio, sendo requisitados simultaneamente
pelos gerentes de projetos dos demais departamentos da empresa.
Por exemplo, a pessoa responsvel pelas aquisies de uma empresa,
inevitavelmente, receber solicitaes de compra de diversos
gerentes de projetos. Por vezes, receber solicitaes de compras de
um mesmo material porm com dias de diferena, fazendo com que o
comprador repita, desnecessariamente, todo o processo de compra.
J a estrutura organizacional matricial prope a mistura entre as
estruturas funcional e projetizada. Desta forma, o projeto ser
conduzido conforme seu grau de relevncia, alocando os recursos
funcionais necessrios.
A estrutura matricial pode ainda ter trs aspectos: matricial fraca,
matricial forte e a matricial balanceada. Para entender melhor cada
uma delas, vamos explicar como esto organizadas cada uma delas a
seguir.
A estrutura matricial fraca mantm o Gerente Funcional (responsvel
por um setor, unidade organizacional ou grupo de pessoas) com o
maior nvel de autoridade. O gerente de projetos est subordinado ao
gerente funcional e depende dele e dos demais gerentes funcionais

para disponibilizarem os recursos humanos e materiais para a

execuo dos projetos.
J na estrutura matricial forte, o Gerente de Projetos que tem
maior nvel de autoridade, alocando os recursos humanos e materiais
necessrios ou at contrat-los externamente a fim de garantir a
execuo e entrega dos resultados dos projetos.
A estrutura matricial balanceada busca, como o prprio nome diz,
balancear as necessidades funcionais e dos projetos dentro da
empresa, ou seja, o Gerente Funcional e o Gerente de Projetos
possuem o mesmo grau de autoridade. Esta estrutura pouco
utilizada dada a complexidade em sua gesto.

O contexto dos projetos

O PMBOK no considerado como uma metodologia. Apesar do
mercado j ter se habituado a chamar de Metodologia de Gesto de
Projetos PMI, o foco do PMBOK concentrar um conjunto de boas
prticas e processos, de forma genrica. Fica sob responsabilidade de
cada empresa construir sua prpria metodologia a qual pode ou no
seguir as recomendaes que constam no PMBOK. Para ser
considerada uma metodologia, a abordagem do PMBOK deveria
estabelecer princpios e regras, estabelecendo como exatamente os
processos deveriam ser executados quando na verdade, o PMBOK
sugere processos, ferramentas e tcnicas de forma que a empresa
estabelea as suas prprias regras para execut-los.
Considerando o exposto, passamos a estabelecer como premissa que
as empresas, aquelas que optaram em trabalhar por projetos, devam
manter uma estrutura Matricial Forte. Geralmente, a alta direo da
empresa determina uma necessidade interna ou de um cliente, algo
precisa ser criado objetivando um resultado especfico. Pode ser
construir uma nova loja, ampliar instalaes, criar uma nova rea,
implantar um sistema de gesto (ERP), construir um novo sistema,
elaborar um novo site ou uma grande mudana visando atender a
objetivos estratgicos da empresa. Ao solicitante ou cliente do
projeto d-se o nome de patrocinador. o patrocinador que ir
usufruir dos resultados alcanados no projeto e, aquele que paga pelo
projeto.
Mas, no basta saber o que se quer, ter em mente o objetivo
esperado apenas parte do projeto. A partir deste momento, existe
uma pessoa a qual dever transformar este objetivo em um projeto e
o profissional mais indicado o gerente de projetos.

Como nosso enfoque a rea de desenvolvimento de software,

iremos assumir que trataremos de um projeto de um novo sistema
(software). Desta forma, do ponto de vista prtico, a alta direo da
empresa precisar saber, basicamente, para entrega deste novo
sistema a ser desenvolvido, quanto tempo ir levar, quanto custar,
como saber se o novo sistema atender s expectativas, quantas
etapas ou fases, como e quando sero informados do avano do
projeto, quais e quantas pessoas sero envolvidas, como os
problemas sero encaminhados e resolvidos, enfim, sero necessrios
documentos que definiro todos estes pontos, um informe executivo
peridico entre outros documentos.
Digamos que este o modo formal, ou melhor, profissional de se
gerenciar projetos conforme consta no PMBOK. O patrocinador e
todas as partes interessadas (pessoas afetadas direta ou
indiretamente pelo projeto) sabero de todo o andamento, das suas
atividades e responsabilidades, a partir das informaes, documentos
e relatrios emitidos pelo Gerente de Projetos. Percebam que esta
forma de conduo de projetos generalista ao ponto de poder ser
adotada em projetos de qualquer natureza, desde a construo de
uma ponte, de criar uma nova linha de montagem em uma indstria
automotiva e, neste ponto que se destacam as boas prticas
sugeridas no PMBOK (PMI) e a necessidade de se criar uma
metodologia dentro da empresa a qual estabelea esta cultura de
projetos para que todos os envolvidos estejam integrados em todos
os momentos do projeto, entendendo o que est sendo, o que ser
feito e, principalmente, o que est sendo dito e informado sobre o
projeto. Este o contexto de um projeto.

Entendendo os conceitos de
Engenharia de Software
Bom, j sabemos o que um projeto e como ele ser conduzido, mas
em se tratando de desenvolvimento de software, existe ainda a
necessidade de se saber construir software e esta, uma rea
bastante abrangente, pois existem diversas maneiras de se fazer
software. Digamos que no incio da informtica, a construo de
software estava focada em resolver questes muito cientficas e
especficas tais como clculos balsticos, para fins militares. Os
computadores no estavam acessveis ao pblico em geral, apenas
em centros governamentais e cientficos como universidades.
Com a popularizao da informtica, o mundo percebeu a capacidade
em utiliz-la de forma a reduzir as atividades repetitivas e, nesta
ocasio, surgiram os chamados programadores, pessoas as quais
detinham o conhecimento para instruir (programar) um computador,

atravs de uma linguagem especfica para executar as tarefas

determinadas. Nesta ocasio, no existiam mtodos ou normas as
quais orientasse a construo destes programas.
Dada a falta de mtodos e de profissionais frente a crescente
demanda, no final da dcada de 1960, instaurou-se a chamada Crise
do Software. Para normalizar a prtica de desenvolvimento de
sistemas, surge a Engenharia de Software trazendo consigo os
princpios da engenharia tais como: criao, construo, anlise,
desenvolvimento e manuteno, com um tratamento mais
sistemtico e controlado. Com a engenharia de software torna-se
possvel especificar, projetar, planejar, construir, aferir e garantir a
qualidade dos resultados.
Com a evoluo da engenharia de software, foram criados os
chamados modelos de processo de software. Estes modelos visam a
melhor representao do gerenciamento do processo de software,
trazendo maior visibilidade. Os modelos basicamente determinam o
ciclo de vida. Ciclo de vida, como o prprio nome indica, significa a
representao de todas as fases desde a concepo at a finalizao
do software entregue, quando este passa a ser tratado como um
produto e ser mantido em um regime de operao de manuteno.
So exemplos de modelos de processo:

Sequencial ou cascata;
Desenvolvimento iterativo e incremental;
Evolucional ou prototipao;
Modelo em V;
Espiral;
Componentizado;
Formal;
gil;
RAD.

Podemos verificar que os modelos foram evoluindo na medida em que

o tempo e a maturidade foram passando. Conforme foi dito
anteriormente, estes modelos foram criados para melhorar a
visibilidade do gerenciamento do processo de software bem como do
gerenciamento do projeto. Esta trajetria de evoluo dos modelos
passa por diversos nveis de exigncia, como gerao de documentos,
processos de aprovao e validaes entre fases. O melhor exemplo
o modelo sequencial (ou cascata) onde uma fase do processo de
desenvolvimento de software, s pode ser iniciada aps a concluso e
aceite da fase anterior. Este modelo sequencial (cascata) est
representado na Figura 2.

Figura 2. Modelo Sequencial (Cascata).

J nos modelo iterativo e incremental a proposta a de que as fases
que no possuam dependncias diretas podem ser iniciadas em
paralelo desde que as aprovaes (aceites) ocorram formalmente. A
melhor representao deste modelo demonstrada atravs do
Processo Unificado (Unified Process). O Processo Unificado prope a
construo do software em partes menores que, ao final, sero
integrados para formar um grande sistema. Este padro de
desenvolvimento permite possuir mais equipes trabalhando em
diferentes partes do software e de forma integrada. A Figura
3 representa o processo unificado (PU).
O PU foi evoludo e popularizado atravs da empresa Rational (agora
pertencente empresa IBM) atravs da criao do chamado Rational
Unified Process (RUP). A Rational desenvolveu um conjunto de
ferramentas as quais representavam todas as fases de forma iterativa
com a equipe de desenvolvimento de software onde, alm de
visualizar os processos era possvel armazenar os artefatos gerados
como um repositrio e ainda navegar por todo seu contedo tal qual
um website. Este padro adota o processo de levantamento e gesto
de requisitos (as necessidades do solicitante), ou as funcionalidades
que sero promovidas pelo software na forma de casos de uso. Casos
de uso so documentos criados para descrever estes requisitos e
todas as suas validaes como regras de negcio, atores (pessoas
envolvidas na utilizao do software), cenrios (como a
funcionalidade dever ser tratada), fluxos, prototipao,
relacionamento com casos de uso, entre outros assuntos que
auxiliem no entendimento do que est sendo solicitado.
Sendo assim, o ponto central do modelo PU est justamente na
correta descrio das funcionalidades atravs dos requisitos e casos
de uso gerados. So documentos que precisam de levantamentos
realizados por um analista o qual ir traduzir as necessidades dos
solicitantes em um formato adequado para a equipe de
desenvolvimento do software.

Outro fator interessante foi que o Rational Unified Process (RUP)

inseriu a abordagem de gerenciamento de projetos conforme
estabelecida pelo Project Management Institute (PMI). neste
momento que a gesto de projetos e a rea de Engenharia de
Software se unem para oferecer, cada vez mais, visibilidade para as
partes interessadas e os patrocinadores do projeto. Em resumo,
tornou-se claro que o desenvolvimento do software fazia parte de um
projeto.
Os modelos de processos e os padres associados aos modelos de
desenvolvimento de software estavam concentrados em guiar as
atividades e normatizar o desenvolvimento em si. Por outro lado, um
projeto pode possuir mais de um software a desenvolver e ainda
cuidar de outras atividades relacionadas ao projeto como a aquisio
de um imvel, mobilirio e infraestrutura para receber a nova equipe
que ir operar o novo software que est sendo desenvolvido no
projeto.

Figura 3. Modelo Iterativo (Unified Process).

Ainda em se tratando de Modelos Iterativos, existem tambm os
modelos geis (Agile) nos quais so oferecidos um conjunto de
prticas que permitem a produo de software de maneira mais
rpida e eficaz. A base do desenvolvimento gil consiste em um
manifesto, chamado de Manifesto gil. A partir deste manifesto gil
surgiram vrias metodologias tais como Scrum, Extreme
Programming (XP), entre outras.
O contedo deste Manifesto diz:

Manifesto para Desenvolvimento gil de Software

Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o ns mesmos e ajudando outros a
fazerem o mesmo. Atravs deste trabalho, passamos a valorizar:
Indivduos e interaes mais que processos e ferramentas
Software em funcionamento mais que documentao abrangente
Colaborao com o cliente mais que negociao de contratos
Responder a mudanas mais que seguir um plano
Ou seja, mesmo havendo valor nos itens direita,
valorizamos mais os itens esquerda.
Tomando como base o que descrevemos anteriormente sobre o PU,
percebemos a ruptura na necessidade de tantos processos e
iteraes, documentos e aprovaes quando na realidade o objetivo
a entrega de um software funcionando. Construir um software o qual
atenda s expectativas deve ser feito atravs do contato direto entre
a equipe de desenvolvimento e o prprio solicitante (cliente).
importante lembrar que esta forma de construir software s
possvel graas evoluo e maturidade das tecnologias e da cultura
das pessoas envolvidas. Nas dcadas de 90 e incio dos anos 2000,
podemos dizer que a tecnologia at viabilizaria a adoo de uma
metodologia gil mas a cultura das pessoas, principalmente daquelas
pessoas que contratavam a construo de um software, estava muito
longe. Tomemos como exemplo a compra de um carro. Seria timo
poder chegar numa concessionria e dizer todos os requisitos
desejados em um novo carro e, numa linha de montagem, estes
requisitos iriam sendo adicionados como rdio, bancos de couro, ar
condicionado, entre outros mas, e quando chegasse ao ponto da
escolha do motor? Cmbio? Sistema de Freios? Trao? Suspenso?
Neste ponto seriam exigidos conhecimentos muito mais profundos e
tcnicos os quais, nem todas as pessoas possuem. Em se tratando de
software, seria a mesma situao onde o solicitante poderia ser
questionado sobre temas que ele no conhece e nem pretende
conhecer devido a sua prpria formao ou profisso.
Retornando ao ponto sobre os processos e modelos, quando
abordamos o tema dos processos geis, mais uma vez, temos a clara
viso de que a construo do software possui necessidades

especficas para garantir mais flexibilidade e qualidade na entrega do

software funcionando, que o software funcione conforme as
expectativas de quem o solicitou. E o projeto? Qual seria o papel do
projeto sendo que na verdade o item desejado o software entregue
e funcionando. O papel do projeto de disponibilizar controles e
envolvimento das partes interessadas a fim de garantir que todo o
processo de desenvolvimento de software, seja ele gil ou no,
funcione perfeitamente.

Um projeto formal pode ser gil?

A resposta sim, definitivamente. A base de um mtodo gil o de
abolir burocracias que dificultam atingir um determinado objetivo. Em
nosso caso, estamos falando de construir software e totalmente
possvel entregar software, de qualidade, funcionando conforme as
expectativas de forma gil e documentada de maneira mnima e
necessria.
A Engenharia de Software, com seus processos e modelos permitiu o
surgimento dos chamados modelos de maturidade. Maturidade se
resume na adoo das reconhecidas boas prticas da engenharia de
software (metodologias, processos, ferramentas e tcnicas) aplicadas
pelas empresas que produzem software. O modelo de maturidade
mais reconhecido mundialmente o CMMI (Capability Maturity Model
Integration) criado pelo Software Engineering Institute SEI.
Como referncia em termos da maturidade no desenvolvimento de
software, o modelo CMMI aceita plenamente a adoo de
metodologias geis desde que estas no interfiram ou deixem de lado
o cumprimento das boas prticas como registros e controles.
O modelo CMMI fornece um conjunto de boas prticas geralmente
aplicveis em grandes projetos que possuam altos nveis de risco e
ainda, oferece um conjunto de prticas de gesto e suporte para
implantao dos mtodos geis nas empresas, independentemente
do tamanho dos projetos. No cabe neste artigo o detalhamento
sobre o Modelo CMMI. Recomendamos o artigo CMMI: Uma viso
Geral publicado na edio nmero 44. O importante ter em mente
o fato de que a maturidade pode e deve andar em conjunto com a
agilidade.
Da mesma forma que o modelo CMMI prev e apoia a adoo das
metodologias geis, o PMI (Project Management Institute) tambm as
reconhece. Em 2011 o PMI lanou uma nova certificao voltada aos
praticantes dos mtodos geis chamada de PMI-ACP (Agile Certified
Practitioner ou Praticante de Agile Certificado). Esta certificao visa
demonstrar ao mercado (empregadores) o nvel de profissionalismo

em prticas geis na gesto de projetos pelo praticante

(profissional), aumentar a versatilidade do profissional em
ferramentas e tcnicas de gesto de projetos, aliada com a
capacidade de liderana de equipes geis e a disponibilizao de uma
estrutura voltada treinamentos e iniciativas de desenvolvimento
profissional.
Em resumo, as prticas geis podem e devem ser associadas a
processos formais de gesto de projetos. Isto no significa abrir mo
da rapidez que as prticas geis oferecem sem perder o controle,
qualidade e visibilidade oferecidas pela gesto de projetos formal.
Porm, tanto as prticas geis bem como o gerenciamento de
projetos formal, por si s, no garantem a eficincia e eficcia do
resultado. Precisamos separar as reas e demonstrar o
funcionamento destas prticas para elucidar o contexto de
desenvolvimento de software na vida real.

Gesto de Projetos e Mtodos geis

na prtica
Falamos anteriormente da existncia das empresas e como estas
esto normalmente estruturadas. Agora necessrio que o leitor
identifique se a empresa em que est trabalhando do tipo funcional,
projetizada ou matricial para enxergar os paralelos e comparaes a
seguir. Vamos estabelecer um cenrio onde apresentaremos a
aplicao dos conceitos de gesto de projetos e prticas geis.
Voc trabalha numa empresa voltada ao desenvolvimento de
software, do tipo matricial forte onde o gerente de projetos possui a
autoridade necessria para acionar os demais gerentes funcionais e
garantir que os projetos sejam executados seguindo a metodologia
definida pela empresa. Esta metodologia inclui a gesto de projetos
formal (seguindo as recomendaes do PMBOK do PMI) bem como as
boas prticas da rea de engenharia de software, entre elas o uso
das prticas geis do Scrum conforme sugeridas pelo modelo CMMI.
No entraremos no mrito da empresa estar ou no certificada em
um dos nveis de maturidade do CMMI.
Sua empresa venceu uma concorrncia para desenvolver um
software de gesto para um cliente do ramo de minerao. Este
projeto foi concebido a partir da apresentao de uma solicitao de
proposta (RFP Request For Proposal) onde foram recebidas as
informaes como escopo, prazo, qualidade. Esta solicitao foi
recebida pela rea comercial da sua empresa e, foi encaminhada ao
time de oramento. Este time de oramento composto por

membros da equipe comercial, do gerente de projetos e at da alta

direo da sua empresa.
O Gerente de Projetos em conjunto com as equipes funcionais
fizeram a anlise das solicitaes da empresa de minerao,
definiram um plano de projeto contendo: escopo, premissas,
restries, custos, riscos, controle e garantia da qualidade, controle
de solicitaes de mudanas, plano de comunicao, gesto das
partes interessadas, controle dos contratos de terceirizadas, gesto
dos recursos, enfim, todos os tpicos descritos na metodologia da
empresa que tomaram como base o PMBOK. E alm disso, iro adotar
a metodologia gil Scrum. Neste documento de plano de projeto, j
se sabe, em linhas gerais, o que precisa ser feito e como, quando
ser feito e por quem. De posse destas informaes, a equipe
comercial pode gerar uma proposta contendo valores e condies.
Chega a notcia de que a sua empresa foi escolhida pela empresa de
minerao para desenvolver o sistema de gesto solicitado por ela.
Neste momento, o Gerente de Projetos entra em cena para alocao
dos recursos e dar incio ao projeto. Faz-se uma reviso do plano do
projeto para garantir que tudo o que estava na proposta comercial
est contemplado no plano e ento feita a reunio de incio (Kickoff). As providencias administrativas so iniciadas, os recursos
alocados e, o time de desenvolvimento faz a reviso das estrias
liderados pelo ScrumMaster, organizam o backlog de estrias e
planejam as Sprints.
Para iniciar o desenvolvimento do sistema, a primeira coisa que o
time de desenvolvimento precisar do envolvimento do cliente (as
pessoas elencadas pela empresa de minerao) para refinar e
desenvolver as estrias. Neste meio tempo, o gerente do projeto est
providenciando contratos, contrataes de pessoas e materiais
necessrios para a execuo do projeto.
Durante o planejamento da Sprint, o ScrumMaster e a equipe de
desenvolvimento no conseguem total disponibilidade do cliente. Um
impedimento registrado na reunio e o ScrumMaster aciona o
Gerente do Projeto por telefone. O Gerente de Projeto, verifica no
plano do projeto e identifica no plano de comunicao e na matriz de
responsabilidades quem a pessoa responsvel do lado do cliente em
resolver este problema. O Gerente de Projeto entra em contato com
esta pessoa, explica a situao e solicita um encaminhamento.
Passado um breve perodo, o cliente assume que no havia entendido
corretamente e que os recursos estaro disponveis no prximo dia.
Conforme o entendimento telefnico, o gerente de projetos registra a
ocorrncia no formato previsto da metodologia da empresa e
acompanha a soluo do impedimento junto ao ScrumMaster. No dia

seguinte as pessoas definidas pelo cliente chegam empresa e

desempenham o papel necessrio para iniciar as atividades de
desenvolvimento junto ao ScrumMaster e a equipe. O impedimento
removido, registrado na reunio diria e o processo de
desenvolvimento segue, sem maiores problemas.
De acordo com a evoluo das sprints, o ScrumMaster envolve e
reporta o Gerente de Projetos quanto ao andamento e, o Gerente de
Projetos por sua vez emite os relatrios e os documentos de aceite
obrigatrios na liberao dos pagamentos e incio das prximas fases.
O ScrumMaster e a equipe de desenvolvimento tambm registram as
mudanas no backlog, as reunies de retrospectiva, planejamento
das sprints seguintes.
Ao final do prazo acordado, a equipe de desenvolvimento da sua
empresa entrega o sistema de gesto em funcionamento, conforme
as expectativas definidas pela empresa de minerao e o projeto
dado como finalizado com sucesso, entrando em produo e em
operao gerando os benefcios esperados. Enfim, temos um caso de
projeto bem sucedido utilizando o processo formal e o gil de
desenvolvimento de software em harmonia.

Entendendo os Papis do Gerente de

Projetos e do ScrumMaster
Com o sucesso comprovado de resultados ao se adotar as
metodologias geis, algumas empresas passaram a entender que o
papel do ScrumMaster seria suficiente para executar os projetos. Da
mesma forma que outras empresas tambm passaram a entender
que um Gerente de Projetos tambm poderia assumir a funo de
ScrumMaster. Diante da novidade e, por vezes, da falta de
informaes podemos considerar natural que esta confuso entre
papis ocorram.
Segundo o PMBOK (PMI), o papel do gerente de projetos a pessoa
definida por uma organizao responsvel por garantir que os
resultados (objetivos) do projeto sejam alcanados. Diferentemente
dos gerentes funcionais (responsveis por equipes funcionais ou
unidades de negcio especficas) ou dos gerentes operacionais
(responsveis por garantir a eficincia das operaes comerciais). Um
Gerente de Projetos possui responsabilidades e competncias
prprias. Destacamos entre as responsabilidades do Gerente de
Projetos a responsabilidade de atender s necessidades das tarefas,
das equipes e dos indivduos, funcionando como um elo entre a
equipe e a estratgia pois, atravs dos projetos que as empresas

podem crescer e se manterem atendendo as crescentes e variadas

demandas do mercado.
Um Gerente de Projeto precisa deter muito mais do que
conhecimentos sobre ferramentas e tcnicas, deve aliar a prtica e
ainda possuir habilidades gerenciais (soft skills) tais como: liderana,
motivao, possuir boa comunicao, influenciador, tomada de
deciso, confiabilidade, gesto de conflitos, orientao, entre outros.
O papel do ScrumMaster, diferentemente do Gerente de Projeto, o
de facilitar o caminho da equipe para que esta possa concluir os
objetivos da Sprint, removendo impedimentos, impedindo que
influencias externas atrapalhem o andamento das atividades,
mantendo o foco da equipe. Alm disso, o ScrumMaster o
responsvel pela aplicao correta das prticas do Scrum,
capacitando e motivando a equipe, promovendo as adaptaes
necessrias ao processo de desenvolvimento de software. No precisa
necessariamente ser um Lder da equipe de desenvolvimento, mas
por outro lado, assume para si o papel de ponto focal entre a equipe
e os demais envolvidos no projeto como o Gerente de Projetos e o
Cliente.
Percebemos que algumas empresas, ao publicarem vagas e
oportunidades de emprego vem exigindo, cada vez mais, que tanto o
Gerente de Projetos possua conhecimento e experincia com Scrum e
prticas geis bem como, exigindo do ScrumMaster que possua
conhecimentos e experincia sobre gesto de projetos.
Entretanto, importante deixar claro que os papeis do Gerente de
Projetos e do ScrumMaster so bem distintos e no deveriam ser
confundidos. Do ponto de vista prtico, conforme expusemos neste
artigo, um Gerente de Projetos possui muitas responsabilidades as
quais, vo muito alm de cuidar e garantir que o software seja
entregue conforme o combinado e, no pode ficar junto da equipe
aguardando que impedimentos ocorram para poder resolv-los.
Da mesma forma, no seria justo que um ScrumMaster deixasse de
resolver os impedimentos apresentados pela equipe enquanto produz
relatrios ou est em reunio junto ao cliente para aprovao de
pagamentos.

Leia mais em: O que faz um Gerente de projetos ou e um Scrum

Master? http://www.devmedia.com.br/o-que-faz-um-gerente-de-projetos-ou-eum-scrum-master/31376#ixzz3GPgBJtBY