GESTÃO DE PROJETOS ÁGEIS: UMA ANÁLISE DOS PRINCIPAIS PORTAIS DE CONTEÚDO NA INTERNET BRASILEIRA

FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA

CLAUDIO MONTEIRO DA SILVA

PAULO MOREIRA MARINHO

GESTÃO DE PROJETOS ÁGEIS: UMA ANÁLISE DOS PRINCIPAIS

PORTAIS DE CONTEÚDO NA INTERNET BRASILEIRA

São Paulo

2009





Trabalho de Conclusão de Curso apresentado à Faculdade de Informática e Administração Paulista,
como um dos requisitos para conclusão do Curso de Pós-Graduação em Gestão de Tecnologia da
Informação.

Orientador: Prof. Marco Antonio Bastoni

São Paulo

2009





Trabalho de Conclusão de Curso apresentado à Faculdade de Informática e Administração Paulista,
como um dos requisitos para conclusão do Curso de Pós-Graduação em Gestão de Tecnologia da
Informação.

Aprovada em ____________ de 2009

BANCA EXAMINADORA

Prof. Marco Antonio Bastoni.

Orientador

Prof.(ª) Ms. ou Dr.

Componente da Banca

Prof.(ª) Ms. ou Dr.

Componente da Banca

Dedicatória: Agradecemos a nossas famílias,

que sempre acreditaram que conseguiríamos

concluir mais este desafio, principalmente pelas

horas, finais de semana e feriados que foram

pacientes e nos apoiaram sempre.

AGRADECIMENTOS

Agradecimentos: Agradecemos aos colegas de

área que ajudaram a avaliar o cenário da

internet no Brasil, por entrevistas com

depoimentos dramáticos de bastiões do cenário

brasileiro. Também gostaríamos de agradecer

a instrução feita nos cursos de SprintIt, em

especial aos instrutores Boris Gogler,

Alexandre Magno e Juan Bernardó.

RESUMO

Por décadas, as melhores práticas de gerenciamento de projetos vêm sendo
discutidas e implementadas em empresas de todos os segmentos. Desde o fim dos
anos 90, as empresas de internet, ou frentes de empresas tradicionais, vem
tomando força. Em um segmento de mercado onde a inovação e o pioneirismo são
artefatos estratégicos fundamentais, as metodologias tradicionais de gestão de
projetos podem dificultar a competitividade por se preocupar mais nos processos e
menos nos resultados a curto prazo. As metodologias ágeis se aplicadas
corretamente e não deixando de lado a qualidade e o custo de seus produtos podem
ajudar as empresas de portais de conteúdo de internet no Brasil a obterem bons
resultados e um diferencial competitivo.

Palavras-chave: PMBoK. SCRUM. Internet. Gestão de Projetos.

ABSTRACT

For decades, the best practices of Project management have been discussed and
implemented in companies of all segments. Since the end of the ninety decade, the
Internet companies, or segments of traditional offline companies, have been
stronger. In a place where innovation and being the first to have an available service
before the competition is a strategic diferential, the traditional metodologies of Project
management can make the competitivity of a company harder, targeting more the
proccess tan the short time results. The agile metodologies, applied correctly, without
forgeting the quality and cost of their products, can help the internet portals
companies to gain good results and a competitive diferential.

Keywords: PMBoK. SCRUM. Internet. Project Management.

LISTA DE ILUSTRAÇÕES

FIGURAS

Figura 1 - Divisão das falências por setor. Fonte: Freitas (2001)............................................. 22
Figura 2 - Pesquisa Cetic 2007. Fonte: Balboni (2008) ........................................................... 24
Figura 3 - A cauda longa - Conceito. Fonte adaptada: Anderson (2006) ................................. 28
Figura 4 - A cauda longa - Prática. Fonte: Teixeira Junior (2005) ........................................... 29
Figura 5 - Gráfico diário de visitantes únicos. Fonte: Trends (2008) ....................................... 31
Figura 6 - Exemplo de gráfico de Gantt, Fonte: Kremer (2006) .............................................. 33
Figura 7 - Exemplo de resultado da utilização de Pert-CPM. Fonte: Brand (1998)................. 34
Figura 8 - Modelo espiral de processo de projeto. Fonte: Boehm (1988) ................................ 37
Figura 9 - Comparativo entre abordagens de metodologia de projeto. Fonte: Martins (2007) 38
Figura 10 - Avaliação de metodologias conforme seu alinhamento ágil, iterativo ou
prescritivo (tradicional). Fonte: Martins (2007) ....................................................................... 41
Figura 11 - Processo no ciclo de vida de um projeto. Fonte: PMBoK (2004) ......................... 43
Figura 12 - Processos de planejamento. Fonte: Martins (2007) ............................................... 47
Figura 13 - Exemplo de EAP. Fonte: Marquioni (2008) .......................................................... 48
Figura 14 - Exemplo de controle de projeto pelo Microsoft Project. Fonte: Microsoft (2007) 49
Figura 15 – Exemplo de curva de acompanhamento de evolução de projeto. Fonte: Martins
(2007)........................................................................................................................................ 51
Figura 16 - Modelo de processos PRINCE2. Fonte: Pharro (2005) ......................................... 53
Figura 17 - Modelo de disciplina RUP. Fonte: IBM (2008) .................................................... 54
Figura 18 - Apresentação do fluxo SCRUM. Fonte: Conchango (2008) ................................. 56
Figura 19 - Apresentação do dashboard. Fonte: Flavio (2008) ................................................ 61
Figura 20 – Painel Kanban. Fonte: Pedroso (2007).................................................................. 67
Figura 21 – Visualização de projetos ágeis utilizando quadros Kanban. Fonte: Hiranabe
(2007)........................................................................................................................................ 68

TABELAS

Tabela 1 - Evolução da Web 1.0 para Web 2.0. Fonte: O'Reilly (2008) .................................. 26
Tabela 2 - Comparativo entre abordagens de metodologia de projetos. Fonte: Martins (2007)40
Tabela 3 - Presença de processos em cada etapa de ciclo de vida de um projeto. Fonte:
PMBoK (2004) ......................................................................................................................... 44
Tabela 4 - Adequação a estrutura organizacional. Fonte: Martins (2007) ............................... 46

SUMÁRIO

1. INTRODUÇÃO ................................................................................................................ 12
1.1. Objetivos .................................................................................................................... 13
1.2. Pergunta-chave ........................................................................................................... 14
1.3. Hipótese ..................................................................................................................... 14
1.4. Justificativas para a pesquisa ..................................................................................... 14
1.5. Delimitação do Tema ................................................................................................. 16
1.6. Procedimentos metodológicos ................................................................................... 16
1.7. Limitações .................................................................................................................. 17
1.8. Referencial teórico ..................................................................................................... 17
2. PORTAIS DE INTERNET NO BRASIL ....................................................................... 20
2.1. A origem dos portais .................................................................................................. 20
2.2. O segmento internauta brasileiro ............................................................................... 23
2.2.1. O perfil do internauta brasileiro ............................................................................. 23
2.2.2. Web 2.0 .................................................................................................................. 25
2.3. A cauda longa e a fragmentação de mercado ............................................................. 28
2.4. Oportunidades do nicho ............................................................................................. 30
3. GESTÃO DE PROJETOS – MODELOS E CARACTERÍSTICAS .......................... 33
3.1. Histórico de gestão de projetos .................................................................................. 33
3.2. Metodologias tradicionais .......................................................................................... 41
3.2.1. PMBoK................................................................................................................... 41
3.2.1.1. Processos de Iniciação ........................................................................................ 45
3.2.1.2. Processos de Planejamento ................................................................................. 45
3.2.1.3. Processos de Execução e Controle ..................................................................... 50
3.2.1.4. Processo de Encerramento .................................................................................. 51
3.2.2. Outras Metodologias Tradicionais ......................................................................... 52
3.3. Metodologias Ágeis ................................................................................................... 54
3.3.1. Scrum ..................................................................................................................... 54

3.3.1.1. A metodologia scrum.......................................................................................... 56
3.3.1.2. Papéis e Responsabilidades ................................................................................ 56
3.3.1.3. Planejamento ...................................................................................................... 58
3.3.1.4. Processo diário.................................................................................................... 60
3.3.1.5. Finalização da Iteração ....................................................................................... 62
3.3.1.6. Escalando Scrum ................................................................................................ 64
3.3.2. Outras metodologias Ágeis .................................................................................... 66
4. Conclusão ........................................................................................................................ 69

1. INTRODUÇÃO

No Brasil, as principais empresas voltadas a Internet começaram a utilizar
gerenciamento de projetos por sentirem a necessidade de controlar melhor seus
processos internos, a fim de atender as demandas de seus clientes, sejam internos
ou externos, com maior eficiência e precisão. Porém, cada vez mais há uma
necessidade de mudança na visão inicial do projeto, dada as mudanças de
concorrentes ou evoluções tecnológicas que criam necessidades do mercado.

Pesquisas do The Standish Group demonstram uma melhora significativa no
sucesso dos projetos à medida que as organizações adotam os conceitos de
gerenciamento de projeto. Em 1995, observou-se que 16,2% dos projetos foram bem
sucedidos, enquanto 83,8% dos projetos falharam ou excederam o orçamento, o
prazo ou o escopo estimado (STANDISHGROUP, 1995 apud GUERRA FILHO,
2006). Em 2006, foi visto que 35% dos projetos foram bem sucedidos, 19% falharam
ou foram cancelados antes de sua finalização e 46% deles foram entregues com
menos funcionalidades, atraso e/ou acima do orçamento (STANDISHGROUP,
2008). Estes dados abrangem uma pesquisa em mais de 60.000 projetos.

Estes números apesar de significativos ainda deixam muito a desejar. Há diversas
razões para tais fatos. Guerra Filho (2006) cita alguns:

• Mudanças ou especificações incompletas de requisitos;
• Falta de recursos humanos ou financeiros;
• Expectativas irrealistas dos stakeholders;
• Falta de comunicação dos membros da equipe, que os leva a trabalhar de forma
não integrada;
• Ausência de processos bem definidos na organização.

Grande parte das razões destes fracassos tem relação direta ou indireta com a
abordagem ineficaz de gerenciamento de projeto ou mesmo sua total ausência.

Em geral, em gerenciamento de projetos de portais de Internet, há duas
características predominantes: muita incerteza em relação ao escopo e
especificação, mesmo a médio prazo do que se quer; e forte tendência ao empírico,
pois quase sempre a visão do projeto é inovadora. Em um mercado que sempre
busca a inovação e o pioneirismo, o fator de inovação de uma empresa concorrente
pode levar um projeto ao cancelamento ou a completa revisão de escopo, seja
quanto aos objetivos de negócio ou quanto à tecnologia a ser aplicada.

Usualmente diversos autores de livros, como Martins (2007), classificam as
abordagens de gerenciamento de projeto como clássicas ou ágeis. Ambos os
modelos promovem formas estruturadas e progressivas rumo ao sucesso de um
projeto. No entanto, destaca-se uma principal diferença: o modelo de abordagem de
gerenciamento de projeto clássica permite que aja pouca iteratividade aumentando a
possibilidade de desalinhamento das expectativas dos projetos; já algumas
abordagens ágeis, como Scrum, seu princípio base é a iteratividade.

A presente pesquisa se configura como Trabalho de Conclusão de Curso de pós-
graduação em Gestão de Tecnologia da Informação da Faculdade de Informática e
Administração Paulista e apresenta suas justificativas para a escolha do tema,
bem como a sua delimitação. Com a finalidade de contribuir para a produção
científica e atingir certo grau de aprofundamento acadêmico, a pesquisa foi realizada
pelos alunos Claudio Monteiro da Silva e Paulo Moreira Marinho do curso de Gestão
de Tecnologia da Informação. Alguma pesquisa prévia se fez para a sua elaboração
pelos estudantes empenhados na pesquisa. Grande parte do projeto inspira-se, no
entanto, numa tentativa de avaliar e propor melhorias para a área em que atuam os
pesquisadores.

1.1. OBJETIVOS

Para a apresentação mais clara dos objetivos dessa pesquisa a problemática
(questão central) norteadora da pesquisa, bem como a hipótese de trabalho

(resposta provisória) foram o “fio de Ariadne” deste TCC, em fase de apresentação
para a banca examinadora. A partir da questão central o objetivo deste TCC é:

“As metodologias de gerenciamento ágeis, especialmente Scrum, são as
melhores práticas a serem aplicadas em portais de conteúdo de Internet no
Brasil para obterem melhores resultados de forma mais rápida, mesmo que
num curto prazo e mesmo com pouco entendimento de ambas as partes do
que se deseja no final do projeto, com a finalidade de manter o pioneirismo
das empresas quanto a suas inovações, mesmo que parciais, e permitir com
que novos enfoques sejam dados sem ter sido feito grandes trabalhos que
sejam descartados.”

1.2. PERGUNTA-CHAVE

A pesquisa será realizada a partir do seguinte problema central (ou pergunta-chave,
ou ainda a questão principal a ser respondida com a sua pesquisa):

“O melhor modelo de gestão de projetos em portais de conteúdo de internet do
Brasil é o modelo ágil?”

1.3. HIPÓTESE

Com base na questão (problema) central, a pesquisa apresenta a seguinte hipótese
de trabalho:

“Os modelos ágeis são ideais para portais de conteúdo de internet do Brasil.”

1.4. JUSTIFICATIVAS PARA A PESQUISA

Afora o interesse pessoal dos pesquisadores, por atuarem em portais de Internet por
mais de uma década, o tema se impõe pela recorrência das discussões sobre
modelos de gerenciamento de projeto adequados ao perfil de empresas web. No
Brasil, este assunto tem estado altamente em voga, por haver uma grande força
neste setor de empresas a metodologias fora do tradicional, que reflete as inovações
trazidas por elas, tanto tecnológicas quanto culturais.

Há total relevância científica nesse projeto de pesquisa uma vez que poucos cursos
de Gestão no Brasil ainda não trazem o que há de ponta no cenário acadêmico
mundial. Há uma atualização constante do já estudado por aqui, mas não quanto a
novas linhas de pensamento sendo elaboradas e discutidas. A pesquisa pode,
então, contribuir, entre outras coisas, para trazer a discussão o tema, alertar quanto
ao risco que esta falta de atualização pode trazer ao crescimento acadêmico do país
e, também, de empresas nacionais.

Por outro lado, a relevância social da pesquisa se mostra pelo fato de que o estudo
permitirá ajudar na resposta a uma pergunta básica: A quebra de paradigma
tradicional não seria necessária, em prol do negócio? Ao mesmo tempo, a pesquisa
poderá ajudar a compreender como o conhecido "jeito brasileiro", embasado em
nossa criatividade, pode ser utilizada como uma ferramenta de inovação positiva, ao
invés de ser castrada para seguir preceitos antiquados ao mercado nascente.
Crendo na sua real importância, a pesquisa visa analisar a inovação de modelos de
gestão visando o negócio e a governança, sem se prender necessariamente a
conceitos existentes para, de alguma forma, ajudar às empresas nacionais a
encontrarem um modelo que se encaixe a seus mercados, à suas missões e que
faça com que seus recursos humanos produzam o máximo em prol do negócio, sem
sacrificarem sua própria qualidade de vida nem a nenhum ponto importante do
produto final da empresa; como a qualidade.

O interesse pessoal dos pesquisadores advém do fato de militarem na área de
portais de internet desde seus primórdios no Brasil. Os pesquisadores se interessam
altamente pela gestão de projetos e pela inovação constante deste nicho,
principalmente quanto à sua postura em prol de se envolverem mais efetivamente
com o objeto de sua investigação.

A despeito de a pesquisa roçar quase sempre o pioneirismo, pela quase inexistência
de estudos na área (especialmente no Brasil, quanto ao nível acadêmico), o tema se
mostra de execução viável, primeiro, pela pouca existência de fontes acadêmica a
serem consultadas; segundo, pelo apoio que os pesquisadores receberam da

instituição e pelos estudos teóricos já desenvolvidos nesta área.

1.5. DELIMITAÇÃO DO TEMA

Para analisar a gestão de projetos ágeis, circunscrito à área de portais de conteúdo
de internet no Brasil, a presente pesquisa se organizou em torno de cinco capítulos.
O primeiro capítulo é introduzido o contexto do tema pesquisado, seus objetivos, sua
pergunta-chave, suas justificativas, suas delimitações em que o estudo se propõe
atingir. Num segundo capítulo, é apresentada uma visão geral do nascimento dos
portais de internet no Brasil, fazendo uma avaliação de quais foram e estão sendo
os valores de negócio e de como foi ou está sendo aplicada a gestão dos projetos
neles. Em terceiro lugar, é feita uma análise dos modelos de gestão de projetos,
onde são apresentados os modelos tradicionais de gestão de projetos, com ênfase
ao PMI, e seqüencialmente, apresentamos os modelos ágeis, destacando o SCRUM
dentre eles. E finalmente no quarto capítulo, fecharemos este trabalho de pesquisa
com a síntese dos objetivos, conclusões e recomendações para pesquisas futuras a
áreas correlatas a este estudo.

1.6. PROCEDIMENTOS METODOLÓGICOS

Para a construção deste trabalho acadêmico, a pesquisa seguiu, inicialmente, com
leitura e revisão da literatura teórica referencial a fim de amadurecer a nossa
hipótese norteadora além de provocar uma compreensão conceitual e focada à
gestão de projetos ágeis. Para a coleta de dados foram utilizados instrumentos
adequados, bem como foram empregadas técnicas aprendidas durante o curso para
a efetiva análise dos dados coletados. Foram, portanto, adotados os seguintes
procedimentos nesta ordem:

a) Pesquisa exploratória;

b) Leitura de textos de orientação teórico-metodológica;

c) Métodos comparativos, indutivos, dedutivos e hipotético-dedutivos;

d) Análise geral dos resultados.

1.7. LIMITAÇÕES

Apesar do tema apresentar limitações fracas quanto ao delineamento de uma
conjuntura de gerenciamento de projetos no mercado de portais de conteúdo
nacional, ao invés da internacional, a pesquisa se focou, embasada e discutida em
fatos além de nossas fronteiras, no mercado brasileiro. Como temos um dos maiores
mercados de telefonia e de navegação em Internet, tendo orientado inclusive a
mudança da sede do site de relacionamento Orkut para o país (CARPANEZ, 2008),
o mercado brasileiro ainda tem muitos poucos trabalhos acadêmicos voltados a
nossa realidade, o que pode embasar uma argumentação de sua imaturidade e de
uma defesa acadêmica de novos rumos que estão sendo tomados por novas
empresas, como o núcleo Internet do jornal O Globo, em focar em metodologias
ágeis. Além disto, a pesquisa limitou-se a análise de portais de internet, onde o foco
do negócio deriva de retornos obtidos devido a seu conteúdo.

1.8. REFERENCIAL TEÓRICO

Foi de grande utilidade para a pesquisa o livro “TÉCNICAS PARA
GERENCIAMENTO DE PROJETOS DE SOFTWARE, de José Carlos Cordeiro
Martins”, que apresenta uma análise das principais metodologias de gestão
utilizadas atualmente em tecnologia da informação, e faz comparações entre elas
sempre pensando em estilos de empresas existentes. O tema do texto não traz uma
análise do mercado web, porém muitos de seus pontos são válidos neste mercado.

Os estudos “GERENCIANDO EQUIPES DE DESENVOLVIMENTO ÁGIL: ACERTAR

ALVOS MÓVEIS É DIFERENTE!”, de Ronald Cuellar e Sanjiv Augustine, e
“GERENCIAMENTO ÁGIL DE PROJETOS – UMA ABORDAGEM ADAPTATIVA”, de
Otávio A. Ritter, publicado na revista MundoPM foi de grande valia para entender os
dogmas das metodologias tradicionais em seu principal expoente.

Os livros “THE ENTERPRISE AND SCRUM” e “AGILE PROJECT MANAGEMENT
WITH SCRUM”, de Ken Schwaber, onde são relatados vários casos de estudo de
aplicação de metodologias ágeis e de transições de metodologia tradicional para
ágil, foi importante para o comparativo do cenário nacional, ao vermos as
similaridades de cenários.

O livro “GERENCIA DE PROJETOS”, de Kim Heldman, foi importante para uma
compreensão mais profunda do PMBoK, além do livro em si, publicado pelo Project
Management Institute.

Uma classificação das fontes pode ser proposta assim:

1. Fontes primárias:

Livros de metodologia do trabalho científico;

Livros de gerenciamento de projeto citados;

Teses e dissertações citadas;

Cursos feitos pelos pesquisadores, quanto a metodologia tradicional, focando
o PMBoK1, e ágeis, focando SCRUM2;

Seminários, como o FalandoAgile2008.

.

1
Curso de Gestão de Projetos ministrado por Roque Rabechini Jr, In Company.
2
Curso e certificação Scrum Master (CSM) sob orientação da http://www.scrumalliance.org/

2. Fontes secundárias:

Textos de gerenciamento de projetos usados durante o curso;

Experiência profissional vivida, trazida em alguns casos de uso.

2. PORTAIS DE INTERNET NO BRASIL

2.1. A ORIGEM DOS PORTAIS

O primeiro acesso a Internet no Brasil ocorreu em 1988, quando a Fundação de
Amparo à Pesquisa do Estado de São Paulo (Fapesp) realizou a primeira conexão à
rede mundial. Na mesma época, a Universidade Federal do Rio de Janeiro (UFRJ) e
o Laboratório Nacional de Computação Científica (LNCC), em Petrópolis (RJ),
também realizaram o feito se conectando à Internet através de links com
universidades americanas (VIEIRA, 2003).

Em 1992, o governo federal criou a Rede Nacional de Pesquisa (RNP), que cresceu
e passou a receber link internacional. Com isso, o governo federal passou a espalhar
pontos de conexão a Internet pelas principais capitais do país principalmente para
universidades, fundações de pesquisa e órgãos governamentais (VIEIRA, 2003).

Em paralelo ao inicio da RNP, em 1989, foi criada no Rio de Janeiro a primeira
instituição não-governamental e fora do ambiente acadêmico a usar a Internet
através da Alternex, chamada Instituto Brasileiro de Análises Sociais e Econômicas.
O grande desafio do Alternex ocorreu em 1992, com a conferência internacional
ECO-92, no qual foi montado um sistema de veiculação de informações eletrônicas
para acompanhar o andamento dos debates (VIEIRA, 2003).

Pode-se considerar o marco inicial do Internet comercial no Brasil e no mundo o ano
de 1995. Este foi o ano em que foram criados nos Estados Unidos alguns dos
grandes nomes da Internet, tais como o Yahoo! e a livraria (inicialmente) virtual
Amazon.com. Além disso, no Brasil, surgiam centenas de pequenos provedores de
acesso a Internet.

Neste contexto inicial, o Yahoo, por exemplo, faturou 19,7 milhões de dólares em
1996 e 67 milhões de dólares no ano seguinte, receita oriundas quase que

exclusivamente da publicidade veiculada no site (VIEIRA, 2003).

Foi nesta década de 90 que também surgiram os principais players da Web
brasileira. Nomes como Mandic Internet, Booknet, ZipMail, Cadê?, ZAZ, Universo
Online e IG (VIEIRA, 2003).

Diferente do que ocorreu nos Estados Unidos, onde o surgimento dos portais
originou da evolução dos sites de busca, que usaram o conteúdo como forma de
manter mais tempo o usuário, no Brasil os portais nasceram dentro das empresas
jornalísticas. No início, alguns deles nem tinham a concepção de Portal, evoluindo
apenas posteriormente para o modelo.

O primeiro site com características jornalísticas do Brasil foi o do Jornal do Brasil,
criado em 1995, seguido pela versão eletrônica do jornal O Globo e das publicações
das notícias da Agência Estado na Internet. Assim como O Globo, o UOL publica na
íntegra as matérias do jornal Folha de S. Paulo, para acesso irrestrito somente de
assinantes do provedor ou do jornal.

O caminho percorrido no Brasil foi inverso ao adotado nos Estados Unidos, pois
somente depois de conquistar o leitor pelo valor jornalístico de cada produto, foi que
os sites começaram a agregar serviços, produtos, agendas e afins até, finalmente,
denominarem-se portais (TEIXEIRA, 2002).

Passado o período inicial, houve um imenso descontentamento por parte dos
investidores, pois os resultados obtidos com os investimentos não foram os
esperados (FREITAS, 2001).

Divisão das falências por setor

Infra-estrutura
6%
Serviços
15%
Comércio
eletronico
52%
Conteúdo
27%

Figura 1 - Divisão das falências por setor. Fonte: Freitas (2001)

Pouco mais da metade dos novos empreendimentos de negócios que receberam
investimentos, geralmente internacionais, estavam com seu foco no comércio
eletrônico, ficando o percentual restante dividido entre as empresas fornecedoras de
conteúdo, como os portais e as redes de notícias, as empresas de infra-estrutura,
como os provedores de acesso a Internet e tecnologia, e as empresas fornecedoras
de serviços (FREITAS, 2001).

Os principais portais de conteúdo conseguiram sobreviver, porém tiveram que se
adaptar ao novo cenário, seja fazendo fusões e aquisições seja participando de
alianças estratégicas. A fusão do BOL com o UOL é um exemplo. ZAZ e Terra são
outros exemplos que devido a pressões de investidores, houve a aquisição do ZAZ
pelo Terra Networks. A pressão por retorno de investimento provocou e continua
provocando as constantes fusões e aquisições (IDGNOW, 2008).

Para Mallett (2008), diretor de operações do Yahoo! na época, a fusão com o
Geocities1 “possibilitou aos milhões de usuários do Yahoo! meios adicionais de
personalizar sua navegação na Web e, ao mesmo tempo, introduziu nossos serviços
de comunicação e personalização ao extenso público do Geocities”. De forma
similar, Teixeira (2002) diz que a compra do HpG pelo Portal iG tornou o mesmo

1
Geocities foi o primeiro site a oferecer hospedagem de páginas HTML gratuitamente seu domínio.

líder em páginas acessadas em 2001. No geral, todas as aquisições e fusões foram
com o intuito de sobrevivência e uma forma de agregar maior valor aos usuários
finais.

2.2. O SEGMENTO INTERNAUTA BRASILEIRO

2.2.1. O PERFIL DO INTERNAUTA BRASILEIRO

Segundo Balboni (2008), os dados da mais recente Pesquisa TIC Domicílios 2007 e
apresentados em Setembro de 2008, houve um significativo aumento do número de
usuários com acesso ao computador e à Internet no Brasil nos domicílios de renda
familiar entre dois e cinco salários mínimos. Constatou-se também um crescimento
do uso de banda larga, que ultrapassou a conexão discada. Houve uma explosão do
uso de Lan House1 que se tornaram o principal local de acesso à Internet no país,
representando 49% dos acessos. Esta explosão, segundo Balboni (2008), é a forma
de inclusão digital que as classes C, D e E encontraram de ter acesso ao mundo
cibernético.

1
Lan House é um estabelecimento comercial onde, à semelhança de um cyber café, as pessoas podem pagar para
utilizar um computador com acesso à Internet e a uma rede local, com o principal fim de acesso á informação
rápida pela rede e entretenimento através dos jogos em rede ou online.

Figura 2 - Pesquisa Cetic 2007. Fonte: Balboni (2008)

Conforme se pode observar, na figura 2, 90% dos internautas brasileiros realizam as
ações relacionadas a comunicação, lazer e busca de informações online. Onde:

Na atividade de comunicação, a Internet foi usada principalmente na troca de
e-mail (78%), na participação de sites de relacionamento como Orkut (64%), no
envio de mensagens instantâneas (55%), lista de discussão (11%), criar ou atualizar
blogs (13%).
A principal atividade de lazer realizada pelos internautas brasileiros é ler
jornais e revistas (47%).
E no que diz respeito às atividades de busca de informações online, a Internet
foi usada para procurar informações relacionadas à diversão e entretenimento
(55%), procurar informações sobre bens e serviços (49%) e procurar informações
relacionadas à saúde ou a serviços de saúde (32%).

Contudo, do ponto de vista de acesso à tecnologia, apesar dos avanços obtidos,

ainda há muito a ser feito para que os benefícios trazidos pelo uso da rede possam
estar ao alcance da maioria da população (BALBONI, 2008). O que torna ainda mais
promissor este mercado.

O expressivo crescimento do número de usuários da Internet citados e, em
particular, do e-commerce aliado a conteúdo, vem despertando o interesse dos
pesquisadores de marketing. Isso porque o aumento da concorrência e a crescente
fragmentação dos mercados exigem que se encontrem novas formas de chegar ao
consumidor. É neste ponto que entram os conceitos da Web 2.0 e da “Cauda longa”
com o propósito de atender a esta necessidade.

2.2.2. WEB 2.0

Os conceitos de Web 2.0 têm sido utilizados como ponto de evolução do chamado
“fazer web”. A Web 2.0 não é uma nova tecnologia ou uma evolução de uma
linguagem de desenvolvimento web. Trata-se de um termo usado para servir de
nome um conjunto de características que podem ser observadas nas aplicações
online mais avançadas e atualmente amplamente utilizadas pelos internautas
(KREIGNE, 2006).

Segundo O'Reilly (2008), destacam-se sete grandes princípios na Web 2.0:
Utilização da web como plataforma; Aproveitamento da inteligência coletiva; A
importância do armazenamento de dados; Fim do ciclo de lançamento de software;
Adoção de modelo de programação leve e simples; Softwares projetados para serem
acessados por múltiplos dispositivos; Experiências do usuário melhores e mais ricas.

O'Reilly (2008) conclui que as organizações da era web 2.0 devem ter as seguintes
competências:

Prestar serviço e não ter aplicações empacotadas;

Criar aplicações que fiquem mais eficientes na proporção que mais pessoas
as utilizem;
Acreditar no usuário como um co-autor;
Utilizar a inteligência coletiva, aprender com o usuário;
Alavancar o alcance do serviço através da participação do usuário
Potencializar o conceito da “Cauda Longa” através da participação do usuário;
Desenhar aplicações visando múltiplos dispositivos;
Desenvolvimento de interfaces simples e leve do ponto de vista de
implementação e de modelo de negócio;

Web 1.0 Web 2.0

DoubleClick Google AdSense

Ofoto Flickr

Akamai BitTorrent

mp3.com Napster

Britannica Online Wikipedia

personal websites blogging

evite upcoming.org and EVDB

domain name speculation search engine optimization
page views cost per click

screen scraping web services

publishing participation

content management systems wikis

directories (taxonomy) tagging ("folksonomy")

stickiness syndication

Tabela 1 - Evolução da Web 1.0 para Web 2.0. Fonte: O'Reilly (2008)

O Google AdSense talvez seja um dos que mais se destaca como aplicação Web

2.0 (veja tabela 1), e que usa o conceito da “Cauda Longa”, se aproveitando da
grande fragmentação do mercado.

O Google AdSense permite que o usuário controle o serviço que deseja, de forma
que ele tenha o controle de quanto gastar com seus anúncios, por quanto tempo
ficarão disponíveis, em qual posição de destaque e afins. Do ponto de vista de
negócio, procura atingir um grande número de pequenos usuários e não somente os
grandes. Trata-se da aplicação na integra do conceito de “Long Tail” ou “Cauda
Longa” de Anderson (2006) que abordaremos no subcapítulo seguinte (KREIGNE,
2006).

A potencialização do anúncio acontece quando o mesmo é apresentado sob o
mesmo contexto da página web em que está sendo exibido. Estes são chamados de
anúncios contextuais, pois refinam o público-alvo a ser atingido à medida que se
relaciona com o conteúdo da página ao anunciante. Este serviço está voltado para
os editores de site, seja um jornal e revista com conteúdo digital seja um blog,
fornecendo automaticamente anúncios gráficos e de texto. O intuito com a precisão
do relacionamento do anuncio com o conteúdo da página é torná-lo adaptável de
forma a causar nos leitores a sensação de ser realmente um link útil. Dessa forma, o
serviço permite que, de uma forma rápida e fácil, sites de quaisquer dimensões
exibam anúncios Google relevantes ao conteúdo de cada página, capitalizando-os
(BRUNO et al., 2006).

Desta forma, ao entrar num blog sobre programas de televisão o Google Adsense
deverá exibir algo como anúncios de assinatura de TV a cabo ou venda de Box de
DVD de series ou filmes. Outro diferencial dos anúncios contextuais é que eles
podem produzir resultados por demanda, ou seja, apenas quando um leitor clicar no
anúncio exibido é que o blogueiro receberá por ele, o que se torna vantajoso para
quem anuncia.

Essa nova abordagem ajuda a formar novas formas de exploração comercial da
Internet por meio da teoria de especificação de nichos online, ou fragmentação do
mercado, chamada de “Long Tail” ou “Cauda Longa” (ANDERSON, 2006).

2.3. A CAUDA LONGA E A FRAGMENTAÇÃO DE MERCADO

A Cauda Longa é um fenômeno observado, principalmente, em empresas de
internet que conseguem faturar com produtos de nicho tanto quanto, ou até mais,
que os Best-Sellers. A inexistência de limitação do espaço físico para exibição de
produtos faz com que os mercados de nicho sejam explorados da mesma forma que
o mercado de massas (IKEDA; NEWS, 2008).

Figura 3 - A cauda longa - Conceito. Fonte adaptada: Anderson (2006)

Esse contexto virtual de recursos ilimitados não deve fazer desaparecer a venda
tradicional de produtos e serviços, mas certamente irá modificar o peso dessa forma
de fazer negócios. Anderson (2006) alerta que não apenas os mercados ligados às
tecnologias digitais serão impactados, conforme exibido na figura 3, mas todas as
empresas que quiserem sobreviver precisarão entender a nova lógica econômica

moldada pela internet. De um universo de produção em massa e busca de
maximização do alcance dos produtos, passamos a viver a era dos nichos, da
fragmentação do consumo e da produção.

Figura 4 - A cauda longa - Prática. Fonte: Teixeira Junior (2005)

A figura 4 demonstra que duas empresas virtuais que enxergaram nos produtos de
nicho a sua principal receita.

Há uma ligação dos produtos de nicho com os segmentos de conteúdo, em especial,
o segmento de Portal. À medida que o conteúdo torna-se vasto, seja via área
jornalística digital seja via blogs no portal ou notícias provindas dos próprios
usuários, pode-se ter uma excelente fonte de renda com seus anúncios contextuais,
seja para alavancar Vendas do Portal seja para servir de vitrine para outros e-
commerce.

A concorrência no segmento Portal e e-commerce vêm transformando a forma de
fazer negócio e os focos de receita de cada portal brasileiro (IDGNOW!, 2008). As

atenções que estavam sendo transferidas de interconexão 1 para Serviço de valor
Agregado (SVA) nem foi completa e o foco de transição já mudou para o conteúdo,
interatividade e uso dos conceitos de web 2.0 como forma de obter maior rendimento
de forma mais eficaz (IDGNOW!, 2008).

2.4. OPORTUNIDADES DO NICHO

O impacto da Internet e dos meios eletrônicos de informação nos negócios é um
consenso entre os especialistas de mercado (IKEDA; NEWS, 2008).

A maior variedade e volume de conteúdo na Web em relação a qualquer outra mídia
é resultado da democratização das ferramentas de produção e do acesso cada vez
mais universalizado. Junto com a facilidade de publicar qualquer coisa na Internet,
estes aspectos mudaram a história da mídia que vinha sendo de um consumo
passivo. Atualmente, o leitor pode ser um consumidor passivo e, ao mesmo tempo,
um criador de conteúdo (THE FUTURE, 2006 apud SCHMITT, 2007).

Quando o efeito da Bolha2 começou a ser desfeito, cerca 2002/2003, e os dados
sobre as vendas online de carros, livros, CDs de música e turismo começaram a
crescer, constatou-se a consolidação do e-commerce. De modo oportuno, a
prestigiada revista “The Economist” abordou o tema em uma reportagem de 14
páginas, em maio de 2004 – E-Commerce takes off – e alertou para diversos
números já surpreendentes para a época (IKEDA; NEWS, 2008).

Se aliarmos o exponencial crescimento e disponibilidade de conteúdo colaborativo,
participativo e jornalístico que os portais vêm produzindo com as diversas
oportunidades de negócio contextualizadas poderemos potencializar e-commerce
incrivelmente.

1
Valor pago de uma empresa de telecomunicações à outra pelo uso de sua infra-estrutura de rede.
2
Conhecido pelo momento de euforia de investimento e pelas seguidas falências de empresas pontocom.

Conforme De Paula afirma que:

[...] começa a mudar a cultura do brasileiro de tocar no produto, pechinchar
e conversar com o vendedor, antes de se decidir. A própria praticidade da
compra eletrônica e sua capacidade de acontecer mesmo longe dos
grandes centros (e das grandes lojas de departamentos) é um ponto a favor.
"De qualquer forma, ainda temos um longo caminho a percorrer. Para se ter
uma idéia, enquanto o EBTDA do Brasil em e-commerce foi de 7 bilhões de
reais, em 2004, o dos Estados Unidos, no mesmo ano, atingiu US$ 250
bilhões. Só a Amazon, com sua receita global de US$ 10 milhões bate a
receita total do Brasil", salienta Gil, diretor de marketing da Ikeda. (2008).

O portal Globo.com é um dos exemplos de portais que vem explorando os conceitos
de Web 2.0 e da cauda longa com intuito de alavancar sua audiência e seu e-
commerce.

Figura 5 - Gráfico diário de visitantes únicos. Fonte: Trends (2008)

A figura 5 demonstra os primeiros resultados do portal perante os seus principais
concorrentes no Brasil. A Globo.com saiu de quatro, e última colocação dos grandes,
para a segunda colocação.

Essa arrancada da Globo.com se explica devido ao investimento em serviços de
relacionamento, tais como o 8p.com.br que é uma mistura de fotolog com rede
social, unidos com o conteúdo do canal televisivo da Globo, que mostra a força do
conteúdo tradicional ainda presente (o UOL tem o conteúdo da editora Abril como
um de seus pontos fortes). Janeiro e Fevereiro de 2008 além de iniciar a
alavancagem, foi justamente o período que a Globo.com começou a adotar
gerenciamento ágil de projetos. Inicialmente com muito treinamento, inclusive
oficiais, e projetos pilotos até se tornar um modelo padrão de gerenciamento de
projetos na empresa.

Outro portal que acordou para a nova realidade foi o iG, com a criação de serviços
como “Minhas Noticias”, “iG Album”, “BliG”, voltado a usuários e “Blog do iG”,
voltados a colunistas, além de poder comentar todas as notícias assim como é feito
nos blogs. O carro chefe da empresa, inclusive, é “O mundo é de quem faz”, onde se
ressalta esta visão de interação do usuário com o portal.

As empresas de comunicação não virtuais, também começam a enxergar essa
oportunidade. Jornais e revistas cada vez mais disputam a atenção dos leitores com
os blogs. Emissoras de rádio têm a nova concorrência dos podcasts. As milhões de
pessoas que produzem conteúdo na internet são um novo e importante desafio para
a mídia. Mas, de acordo com Anderson (2006), será nos mercados de livro, cinema e
música que a cauda longa terá o maior efeito transformador. A idéia de que o mundo
inteiro assista a O Senhor dos Anéis, leia Harry Potter e ouça Madonna, embora
pareça natural, é recente. Antes do rádio e da televisão, não existiam tais
fenômenos globais. Eles são produto da ineficiência de distribuição dos bens físicos
e da escassez. Sobram livros, filmes e discos, faltam prateleiras, telas de cinema e
estações de rádio. Com a internet, há espaço de sobra. Os hits não vão deixar de
existir, argumenta Anderson (2006), mas talvez tenham menos importância cultural e
econômica. As empresas terão de fugir do gosto médio e aprender a identificar e
cultivar nichos (TEIXEIRA JUNIOR, 2005).

3. GESTÃO DE PROJETOS – MODELOS E
CARACTERÍSTICAS
3.1. HISTÓRICO DE GESTÃO DE PROJETOS

A gestão de projetos é uma pratica antiga, utilizada em Engenharia (seja mecânica,
civil, ou militar) há séculos, porém somente voltada para sua finalidade principal, não
como um conceito que se aplicaria a quaisquer áreas. Podemos exemplificar com
casos como as construções das pirâmides ou o planejamento de hebreus de suas
colheitas conforme o calendário lunar, sempre antecipando os riscos e problemas e
os mitigando, garantindo o alimento a seu povo.

Um dos grandes avanços considerados na história da gestão de projetos foi feita por
Henry Gantt, em 1917, com a criação de uma visualização dos tempos de duração
de tarefas e suas interdependências, no que hoje ainda é utilizado e chamado de
gráfico de Gantt (CODAS, 1987). Durante aproximadamente quatro décadas, esta
continuou a ser a principal ferramenta utilizada para o controle de projetos, o que
permitia verificar os caminhos críticos do projeto bem como seus gastos, porém, não
evitava problemas encontrados até hoje, como atrasos, custos maiores que os
planejados e complexidade de medir o avanço de tarefas no dia a dia. Um exemplo
de gráfico de Gantt encontra-se na figura 6.

Figura 6 - Exemplo de gráfico de Gantt, Fonte: Kremer (2006)

A década de 50 é considerada o nascimento da gestão moderna de projetos. Duas
criações foram importantes para isto: a utilização de PERT para a detecção do
menor tempo possível para a realização das tarefas necessárias e do Criticas Path
Method, traduzido como Caminho Crítico, onde detectamos a seqüência de tarefas
de maior duração no projeto que, havendo algum atraso, provavelmente impactam a
duração do projeto como um todo. A união das técnicas de PERT e CMP (Critical
Path Method) gerou a técnica chamada de Pert-CPM (MILLER, 1970), onde o
resultado final, gerado após a aplicação das técnicas de verificação de maior e
menor tempo de cada tarefa e suas interdependências, é exemplificado na figura 7.

Figura 7 - Exemplo de resultado da utilização de Pert-CPM. Fonte: Brand (1998)

Em paralelo, a American Association of Cost Engineering foi criada por gestores de
projetos e gestores de outras especialidades, como estimativa de custo, controle de
custo e cronograma, continuando este trabalho até os dias de hoje, onde lançaram
em 2006 seu processo integrado para controle de projeto, programa e portfólio, este

chamado de Total Cost Management Framework.

Com a evolução da gestão de projetos e com a necessidade encontrada pelos
gestores de técnicas apuradas e processos bem definidos, no final dos anos 60,
duas instituições nasceram, o Project Management Institute, comumente chamada
de PMI, e o International Project Management Association (IPMA), respectivamente
nos Estados Unidos e Europa. Ambas as instituições existem até hoje e trabalham
em conjunto com outras criadas posteriormente a fim de criar um padrão ISO para a
gestão de projetos.

Alguns conceitos criados para a gestão de projetos são importantes e existentes em
todas as linhas de pensamento, que são descritos abaixo:

Projeto: “É um empreendimento temporário com o objetivo de criar um
produto ou serviço único” (PMBoK, 2000 apud POSSI 2004).

Escopo: Onde se define o projeto em si e todas as características do projeto.

Requisitos: São as necessidades que o negócio vê que o produto final deverá
atender. Existem várias maneiras de gerar a especificação dos requisitos,
como documentação textual ou diagramas em linguagens especifica, sendo
muito utilizada a UML.

Análise de Risco: é a verificação de todos os pontos que podem prejudicar o
projeto, seja em prazo, custo ou qualidade. A partir desta análise, riscos são
pesados e ou aceitos ou criado um plano para sua mitigação e contingência.

Na área de tecnologia de informação, os projetos não eram predominantemente
tratados segundo uma gestão de processos, o sendo somente em empresas
militares e industriais (tais como: construção civil, aeronáuticas, e afins).

Segundo Neto (2004):

Na década de 70, a atividade “desenvolvimento de software” era executada

de forma desestruturada e sem planejamento, gerando um produto final de
má qualidade, pois não existia documentação ou era entregue fora do prazo
ou o levantamento de tempo e esforço não correspondia com a real
necessidade.

Ao haver uma crise no mercado de software nos anos 70, na chamada Crise do
Software (PRESSMAN, 2002), as empresas começaram a adotar as melhores
práticas existentes no mercado, a fim de evitar que houvesse um contínuo
desperdício de recursos desenvolvendo produtos que não gerariam o desejado ao
negócio.

Foi durante a década de 70 e 80 que começaram a aparecer alguns artigos
questionando quanto à verificação da eficácia dos modelos existentes. Um dos
principais artigos foi “A Spiral Model of Software Development and Maintenance”, de
Barry Boehm, de 1988, que defendia uma abordagem iterativa ao desenvolvimento
de projetos, pois não havia como precisar todos os pontos de um projeto em seu
planejamento inicial que garantisse o custo e a qualidade, sendo necessárias
iterações de maior análise ao seu decorrer, quando todos teriam mais conhecimento
do projeto e conseguiriam precisar melhor todos os parâmetros envolvidos.

Na figura 8, temos uma visão holística do processo defendido por Boehm, dividido
nas etapas de determinação de objetivos, identificação de riscos, desenvolvimento e
verificação de qualidade, e planejamento na nova iteração, que revalida todos os
pontos vistos anteriormente, além de evoluir quanto a mais áreas envolvidas
(requisitos, protótipo e geração de produto).

Figura 8 - Modelo espiral de processo de projeto. Fonte: Boehm (1988)

Assim, na década de 80, começam a nascer as chamadas metodologias ágeis, que
seguiam o mesmo conceito inicial de Boehm. Com o crescimento da indústria de
tecnologia, tendo a utilização cada vez maior de sistemas e novas tecnologias, onde
o conhecimento ainda não é pleno nas equipes, a abordagem iterativa criou novas
linhas de pensamento, onde a definição deveria ser feita num nível alto, e sendo
refinada a cada iteração. A figura 9 visualiza a diferença entre as duas linhas de
pensamento.

Figura 9 - Comparativo entre abordagens de metodologia de projeto. Fonte: Martins (2007)

Na tabela 2, apresentamos um comparativo do que caracteriza, segundo Martins
2006, o processo definido, que chamaremos de modelo tradicional, e o processo
empírico, que chamaremos de modelo ágil.

Processo definido (clássico) Processo empirico (agil)

Permite primeiro fazer uma Raramente é possível fazer uma
especificação completa para depois especificação inicial que seja detalhada
construir o produto ou executar o e permaneça imutável.
serviço.

No inicio do projeto é possível fazer No início é praticamente impossível
estimativas com precisão razoável. estimar o projeto. A medida que os
dados empíricos emergirem vai ficando
mais fácil planejar e estimar.

Fornece informação sobre o estado Fornece informação apenas sobre uma
interno do processo. parte do processo, que pode ser
influenciada por ações de controle.

Promove um entendimento fundamental Trata o processo como uma "caixa
dos trabalhos internos do processo. preta".

Requer um conhecimento abrangente e Não requer conhecimento detalhado;
acurado sobre o processo. mas um certo resultado pode ser obtido
em resposta a certas mudanças.

É possível identificar, definir, agendar e No inicio do projeto não é possível
seqüenciar todas as atividades de forma identificar as atividades. São
detalhada. necessárias tarefas de adaptação
dirigidas pelos ciclos de constrói-avalia-

adapta.

Adaptações devido a mudanças não A regra são as adaptações criativas que
previstas são raras, e a taxa de ocorrem devido as mudanças não
mudanças e relativamente baixa. previstas. A taxa de mudanças é
bastante alta.

É mais adequado para processos de Normalmente é a única alternativa para
baixa complexidade e bem processos complexos ou pouco
compreendido. compreendidos.

Tabela 2 - Comparativo entre abordagens de metodologia de projetos. Fonte: Martins (2007)

As metodologias ágeis variam em suas abordagens, mas seguindo os princípios
acima citados. Algumas metodologias tradicionais, com o passar do tempo, incluíram
em suas melhores práticas e/ou definição de processos algumas características
ágeis, o que nos leva a apresentar o diagrama da figura 10, onde Martins faz uma
avaliação de onde cada metodologia se encontra quanto a uma abordagem
tradicional ou ágil. Nos sub-capítulos a seguir, abordaremos com ênfase nas duas
principais de cada expoente, o PMBoK e Scrum, mas apresentando também a
diferença das outras metodologias da figura 10.

Figura 10 - Avaliação de metodologias conforme seu alinhamento ágil, iterativo ou prescritivo
(tradicional). Fonte: Martins (2007)

3.2. METODOLOGIAS TRADICIONAIS

3.2.1. PMBOK

Conforme citado acima, no final dos anos 60, foi criada a entidade PMI, que visava
estudar a gestão de projetos a fim de aprimorá-la e criar padrões que sirvam de
direcionamento aos gestores. O documento com estas melhores práticas é o
chamado Project management Book of Knowledge, ou PMBoK. Atualmente o PMBok
está em sua terceira versão, lançada em 2004 (PMBOK, 2004).

Em sua definição, três áreas de atuação são envolvidas no projeto (ou
empreendimento): engenharia, responsável pelo planejamento da especificação do
produto, suprimentos, que é responsável pela contratação de recursos necessários
para o desenvolvimento do projeto, e obras, que é responsável pela execução do

trabalho em si. Todas as áreas têm atuações isoladas, porém sendo necessário o
respeito em suas interações como, por exemplo, as compras serem feitas conforme
especificações de engenharia, e sendo acompanhadas em conjunto, onde se
encontra um dos principais papéis da gestão do projeto, de manter o projeto como
um todo em dia com os custos, cronograma e qualidade.

Segundo PMBoK (2004), são 5 os processos no ciclo de vida de um projeto,
simbolizados na figura 11 quanto a sua magnitude durante o ciclo:

Inicialização: quando o projeto tem suas metas e objetivos definidos, o
público-alvo e retorno de investimento são traçados e consegue-se o
patrocínio para sua viabilização;

Controle: quando há uma atuação centralizada de todas as frentes sendo
executadas no projeto, verificando o andar do projeto e tomando as ações
necessárias para mantê-la conforme o planejado;

Planejamento: quando é feita a especificação do projeto, definidos prazos e
recursos a serem utilizados, e todos os planos do projeto são definidos
(cronograma, papéis e responsabilidades, plano de comunicação, entre outros
que serão abordados a seguir);

Execução: quando o projeto é desenvolvido, seguindo os parâmetros de
tempo, custo e qualidade, havendo ações de contorno para haver a menor
fuga do planejamento possível;

Encerramento: quando o projeto é entregue, assim como a formalização de
fechamento necessária (documentos, pagamentos finais, e afins).

Figura 11 - Processo no ciclo de vida de um projeto. Fonte: PMBoK (2004)

PMBoK (2004) também separa os processos a serem utilizados em 9 áreas:

Gestão de integração

Gestão de Escopo

Gestão de Tempo

Gestão de Custo

Gestão de Qualidade

Gestão de Recursos Humanos

Gestão de Comunicação

Gestão de Risco

Gestão de Aquisição

Na tabela 3 exibimos onde cada gestão terá uma participação ativa para cada
etapa do ciclo de vida do projeto.

Iniciação Planejamento Execução Controle Finalização

Integração X X X

Escopo X X X

Tempo X X

Custo X X

Qualidade X X

Recursos X X
Humanos

Comunicação X X X X

Risco X X

Aquisição X X X

Tabela 3 - Presença de processos em cada etapa de ciclo de vida de um projeto. Fonte: PMBoK (2004)

3.2.1.1. PROCESSOS DE INICIAÇÃO

Com base no PMBoK, os processos envolvidos nesta etapa são representados pelo
desenvolvimento do termo de abertura do projeto (ou Project Charter) e o pelo
desenvolvimento da declaração de escopo preliminar do projeto.

Segundo Martins (2007):

O termo de abertura do projeto documenta as necessidades do negócio, a
justificativa para o projeto, o entendimento das necessidades do cliente,
também descreve o produto ou serviço que vai ser abordado e seus
requisitos..

Na declaração do escopo preliminar do projeto, começamos as definições a serem
detalhadas na fase de planejamento, tendo, em alto nível, uma definição estimada
de tempo e custo do projeto, os critérios de aceitação, e o início da montagem da
estrutura analítica do projeto (EAP, do original Work Breakdown Structure, WBS),
que descreveremos na próxima seção.

Podemos considerar esta fase concluída ao termos todos os interessados e
envolvidos com a clareza do que será produzido, para quem e como.

3.2.1.2. PROCESSOS DE PLANEJAMENTO

Segundo Possi (2004), Trata-se de um grupo de processos de fundamental
importância em um projeto. É nesta etapa que todos os planos do projeto serão
definidos e acordados com todos os envolvidos. O grande objetivo desta etapa é
desenvolver o plano de projeto, contendo os pontos delineados na tabela 4 a seguir.

Nesta etapa, temos a definição das partes interessadas no projeto (gerente de
projeto, equipe, patrocinadores, clientes, stakeholders) e sua adequação à estrutura
organizacional da empresa que está sendo estabelecido o projeto (podendo ser
funcional, matricial ou por projeto). Este definição é importante, pois mostra a
disposição dos participantes no projeto, conforme tabela 4.

Matricial

Funcional Funcional Projeto Balanceada Projeto

Autoridade Nenhuma Limitada Moderada Alta Total
do gerente
de projetos

Dedicação Baixa Até 30% Até 75% Até 100% Total
do gerente
de projetos

Alocação Baixa Parte do Parte do Parte do Total
da equipe tempo tempo tempo

Tabela 4 - Adequação a estrutura organizacional. Fonte: Martins (2007)

Iremos detalhar somente alguns dos processos inclusos dentro da etapa de
planejamento. Segundo PMBOK (2004 apud MARTINS, 2007), os processos de
planejamento essenciais são os indicados na figura 12.

Figura 12 - Processos de planejamento. Fonte: Martins (2007)

Para o planejamento do escopo, é feita uma análise do Project Charter feito na
etapa anterior e feito uma análise mais detalhada. Em projetos de software, por
exemplo, é iniciado um trabalho de engenharia de software a fim de identificar os
componentes necessários ao produto e começar a desenhar suas funcionalidades e
apontar os riscos, soluções e restrições de cada um, a fim de haver um acordo entre
todos os envolvidos quanto à solução a ser executada. É muito utilizado a linguagem
UML para o desenho de soluções de software.

Com os principais componentes do produto desenhados, é construída a estrutura
analítica do projeto, a chamada EAP ou WBS. Com ele, teremos a decomposição do
projeto, indicando os pacotes de trabalho a serem feitos, tentando, segundo Possi
(2004), ao máximo a divisão de subprodutos para uma validação intermediária do
executado, procurando seguir a regra de que suas atividades tenham menos de 8
horas de trabalho e que um pacote de trabalho não tenha mais de 80 horas para ser
completado. Isto é feito para que possibilite a existência de reuniões periódicas (de
quinze em quinze dias de preferência) para divulgação do projeto. A figura 13
exemplifica uma pequena estrutura de um EAP.

Figura 13 - Exemplo de EAP. Fonte: Marquioni (2008)

Para cada pacote de trabalho, é necessário levantar os requisitos, que usualmente
são transformados nas tarefas a serem executadas, ou em requisitos de
dependência de algum outro pacote de trabalho.

Baseado no levantamento, a gestão de aquisição e de recursos humanos iniciam a
compra e/ou alocação de recursos necessários, criando seus controles e prazos.
Havendo já o plano de alocação a ser feito, é montado o controle de tempo e custo,
utilizando ferramentas de analise como as já citadas de caminho crítico e PERT.
Uma das ferramentas mais utilizadas é a solução da Microsoft, o Project. Ele permite
unir todos os controles de um cronograma com o custo, aquisições, alocações e,
dependendo da ferramenta utilizada para a montagem do EAP (por exemplo, a
ferramenta WBSPro), pode inclusive manter a associação do plano do projeto com o
EAP, facilitando a garantia de ter todos os pontos do projeto mapeados em todas as
gestões necessárias estejam consistentes. A figura 14 exemplifica um controle feito
no Microsoft Project, mostrando também a alocação e o custo de cada tarefa.

Figura 14 - Exemplo de controle de projeto pelo Microsoft Project. Fonte: Própria.

Havendo a equipe, o plano básico do projeto montado, é elaborado também o plano
de gestão de comunicação do projeto. Este plano, segundo Possi (2004), deverá
conter a estrutura de coleta e arquivamento de informações com detalhes de como
fazê-lo, a estrutura de distribuição de informações, de quem e para quem devem ser
enviadas, como acessar as informações, e uma regra para a atualização deste
plano. Também é definido o plano de envio de relatórios de desempenho e de
encerramento do projeto. É importante ressaltar que neste documento também
estará definidos os planos de reuniões de acompanhamento, que visam manter
todos os envolvidos alinhados, e de comunicação sobre mudanças de escopo e
riscos.

O gerenciamento de riscos também é iniciado no planejamento e incluso no plano do
projeto. Sendo uma área recente no PMBoK, inclusa na segunda versão, e um
conceito normalmente abstrato, recomendações de medidas para a analise de risco
são feitas não somente pelo PMBoK, conforme dito em Hall (1998), quanto a se
levar em conta a probabilidade da ocorrência do risco. A combinação do grau de
risco, seu impacto nas áreas tempo, custo, escopo e qualidade, e a probabilidade de

ocorrência, levam a uma métrica para cada risco. O projeto deverá ter seu plano de
tolerância, assim como planos de contingência e mitigação para eles.

3.2.1.3. PROCESSOS DE EXECUÇÃO E CONTROLE

Como o controle está intrinsecamente ligado a execução, os processos se
conectam, sendo mais simples a apresentação de seus processos conjuntamente. É
durante esta etapa que o gerente de projeto exerce ao máximo sua função,
garantindo o alinhamento de todas as áreas do projeto e fazendo o máximo para
este não sair do planejado.

O acompanhamento da execução é feito freqüentemente, havendo uma análise dos
riscos e avaliação da qualidade do trabalho. Caso haja algo que faça com que se
tenha um impacto no tempo ou custo, o gerente de projeto deverá agir, seja com sua
autoridade no projeto (dependendo de como este estiver posicionado na
organização como já citado) seja reunindo os tomadores de decisão para discutir
sobre o impacto do risco ou da perda de qualidade e aceitar ou rejeitar o ponto. O
acompanhamento freqüente tem também um intuito de criar uma coesão da equipe,
e de resolver todos os obstáculos encontrados, sejam eles técnicos ou profissionais
e/ou interpessoais.

Baseado no status levantado, o gestor do projeto deverá avaliar o plano de projeto e
fazer análises quanto ao tempo e custo. O PMBoK sugere o uso de métodos de
análise, tanto do tempo e custo, para a avaliação do andamento do projeto, como o
cálculo do valor projetado, custo real, índice de desempenho do custo, desvio de
custo, entre vários outros. Estes dados, caso tenham sido decididos no plano do
projeto, devem ser repassados nos chamados Status Report para os envolvidos
mapeados no plano de comunicação. Ferramentas como o Microsoft Project facilitam
a criação destas métricas e inclusive de gráficos representativos, como exemplifica a

figura 15, que significa, baseada em cálculos do andar de um projeto, que ele está
acima do orçamento, (pois a curva de custo atual, AC, está acima do custo
estimado, EC), porém adiantado no cronograma (a curva de valor de trabalho
projetado, PV, está abaixo de EC).

Figura 15 – Exemplo de curva de acompanhamento de evolução de projeto. Fonte: Martins (2007)

Durante esta etapa, é passível a ocorrência de mudança de escopo, devido a fatores
internos ou externos como variações de mercado e corte de custos. Para a mudança
de escopo ser válida, deverá ser feita uma análise de seu impacto em todos os
planos do projeto, e haver uma aprovação pelos responsáveis deste (stakeholders,
gestor do projeto, clientes, etc). Com a aprovação deste, os planos são atualizados e
repassados a todos os envolvidos, a fim de saberem o caminho a ser seguido a
partir deste momento.

3.2.1.4. PROCESSO DE ENCERRAMENTO

Chegando ao fim do projeto, sendo atendido todos os requisitos definidos (ou
redefinidos) no plano do projeto, é feito o encerramento formal do projeto, onde são
liberados e finalizados as alocações e/ou contratos, liberado o produto final para os
clientes, e executada uma avaliação do projeto como um todos, seguindo o processo
de lições aprendidas apresentado no PMBoK. Esta etapa é de suma importância,

principalmente, em projetos internos de empresas, pois com as lições aprendidas
serão um guia para os próximos projetos a serem executados.

3.2.2. OUTRAS METODOLOGIAS TRADICIONAIS

Durante os anos 90, o PMBoK teve seu uso altamente difundido pelo mundo, sendo
hoje o principal expoente de gestão de projetostendo grande parte das empresas
utilizando as melhores práticas do PMBoK. Muito disto se deve a adesão da
metodologia a outras muito aplicadas no mercado, como ITIL e CMMI.

Porém, outras metodologias seguem a linha tradicional. Uma delas é a PRINCE2,
criada na Inglaterra pelo próprio governo inglês, sendo muito utilizado na Europa,
principalmente no Reino Unido. Muito de seu sucesso, segundo PHARRO (2005),
deve-se a “ser um método facilmente adaptável e de escala ajustável que pode ser
aplicado a todos os tipos de situações e projetos”. A figura 16 apresenta os
principais processos da metodologia.

Figura 16 - Modelo de processos PRINCE2. Fonte: Pharro (2005)

O PRINCE2 é aderente as melhores práticas do PMBoK, porém, segundo Angelo
(2008), existem diferenças a serem consideradas, onde podemos destacar a
materialização de um controle integrado de mudanças bem detalhado.

Apesar de ter o conceito de iteração, o Racional Unified Process, o RUP, é uma
framework de processos tradicional de destaque. O RUP foi criado pela empresa
Rational, pertencente a IBM desde 2003, tendo como expoente a ferramenta
Rational Rose. A principal característica do RUP é, por não ser uma metodologia
rígida, poder se adaptar a necessidade de cada empresa, tendo ferramentas
Rational para a modelagem dos processos, criação de modelos de entradas e
saídas. O modelo que o RUP tenta atender está simbolizado na figura 17, tendo
entregas parciais por iteração.

Figura 17 - Modelo de disciplina RUP. Fonte: IBM (2008)

3.3. METODOLOGIAS ÁGEIS

3.3.1. SCRUM

No mesmo ano da criação da primeira versão do PMBoK, foi lançado na Harvard
Business Review um artigo chamado “The New New Product Development Game”
(TAKEUCHI, 1986), onde os autores argüiam que um projeto não poderia ser
somente focado em métricas financeiras, em processos que atrapalhavam a
produtividade por serem muito rígidos quanto as suas etapas, e sem levar em conta
a motivação e experiência de seus participantes do projeto. Assim como vários
autores já haviam feito comparações de desenvolvimento a estratégias de guerra ou
xadrez, os autores do artigo compararam o processo de desenvolvimento ao jogo de
rugby, onde o time (numa formação original chamada de scrum) avança uma
distância planejada por rodada (sprint), até chegar a sua meta final, mesmo que às
vezes fosse preciso recuar devido à ação do time adversário ou outros problemas
como machucados (os chamados impedimentos).

No começo dos anos noventa, Ken Schwaber e Jeff Sutherland utilizavam

separadamente métodos próprios e semelhantes em empresas focando agilidade.
Ambos utilizavam um modelo iterativo, com uma participação ativa dos gerentes de
produto juntamente a equipe, na priorização do que seria entregue em um período
determinado, sem haver um detalhamento refinado de regras do negócio (como
comumente aplicado em definições de escopo em metodologias como Rup), mas
sim com a necessidade do negócio bem definida, e bem dividida em features que
pudessem ser prototipadas e testadas, até podendo ser lançadas como um produto,
se desejado pelo negócio para marcação de território ou experimento para definição
das próximas evoluções do sistema.

Durante este período, se reuniram a fim de encontrarem uma linha de trabalho única
com o melhor de suas experiências, que resultou em um artigo apresentado na
conferência OOPSLA1 (SUTERLAND, 1997), exibindo o resultado da aplicação feita
da metodologia criada por eles (batizada por Suterland como Scrum) na empresa
IDX.

O conceito original se transformou num manifesto, em 2001 (MANIFESTO, 2009),
onde podemos ver como manifestantes grandes nomes de empresas como
Microsoft, Yahoo, Google e MIT.

No mesmo ano, Ken Schwaber lança o primeiro livro específico sobre o tema, Agile
Software Development with Scrum, onde ainda havia um foco muito forte na
utilização na metodologia eXtreme Programming, o que foi alterado posteriormente
em seu livro seguinte (SCHWABER, 2004), e desincorporado da metodologia como
hoje é conhecida e utilizada.

Com a padronização dos conceitos básicos da metodologia, foi criada a certificação
Scrum, que consiste da aplicação de um curso prático, havendo uma atividade final
com a aplicação de tudo o que foi aprendido. O conceito de uma certificação básica
sem a aplicação de uma prova foi uma das inovações trazidas pela comunidade
Scrum. Similarmente ao PMI, certificações avançadas são feitas pela avaliação da

1
Object-Oriented Programming, Systems, Languages and Applications

experiência e aplicação feita pelo certificado, levando-o, após algumas certificações
e avaliações a ser um certificador da metodologia, seguindo as regras da
certificadora Scrum Alliance.

3.3.1.1. A METODOLOGIA SCRUM

A metodologia, em linhas gerais, é resumida na figura 18. Nela, estão apresentados
os processos, artefatos, e papéis existentes na metodologia. Detalharemos a seguir
cada um destes itens.

Figura 18 - Apresentação do fluxo SCRUM. Fonte: Conchango (2008)

3.3.1.2. PAPÉIS E RESPONSABILIDADES

A divisão de papéis feita no Scrum (SCHWABER, 2004) é bem semelhante à
seguida pelo PMI, mudando as responsabilidades e funções hierárquicas no projeto.

O gerente de produto é chamado de product owner, ou dono do produto. Ele é o
responsável por ter a visão do negócio, saber o desejado pela empresa, como o
produto gerado trará retorno, e é o principal negociador de decisões com os
stakeholders e shareholders. Ele deve estar o mais acessível possível da equipe,
sempre pronto para tirar dúvidas do projeto ou tomar decisões quanto a caminhos do
projeto a serem executados. Ele priorizará os itens de trabalho, validará as
realizações, e definirá o roadmap das features do projeto.

O ScrumMaster, ou mestre scrum, seria o similar ao gerente de projeto, porém com
responsabilidades bem distintas. O scrummaster não tem uma função hierárquica
superior à equipe quanto a decisões, mas sim trabalhando como filtro e solucionador
de conflitos e problemas. Ele deve ser o maior conhecedor da metodologia do
projeto, e deve fazer o máximo possível para mantê-la funcionando. Muitas vezes,
isto poderá não ser possível, e ele deverá utilizar o bom senso, e pesquisar quanto a
situações semelhantes já ocorridas, para ver uma possível adaptação ou solução
temporária para adequar o projeto aos principais dogmas da metodologia. Sua
principal função, além das citadas, é resolver os problemas encontrados pela equipe
que estejam atrapalhando o trabalho, os chamados impedimentos, tais como falta de
software, máquinas, conflitos interpessoais, etc. A velocidade destas resoluções
influenciam diretamente no atendimento das metas colocadas.

A equipe é o item mais diferenciado de outras metodologias. A equipe tem uma
atuação bastante autônoma, sendo auto organizada e autônoma em decisões
quanto o que lhes condiz de desenvolvimento (tipo de documentação, tecnologia,
etc). Seguindo um antigo estudo (MILLER, 1956), uma equipe de boa performance
deve ser formada de sete pessoas, com uma variação de duas pessoas (de cinco a
nove). Ela deve estar totalmente focada no projeto, sendo treinada ou orientada pelo
scrummaster de como será o processo de trabalho.

Comumente é chamada de célula a união do product owner, scrummaster e time. É

desejável que todos estejam no mesmo lugar físico, se possível em uma sala, onde
possam ter um melhor entrosamento e acessibilidade entre si.

3.3.1.3. PLANEJAMENTO

O processo de elaboração de um projeto mantém-se o mesmo de uma metodologia
tradicional, havendo uma avaliação de seu retorno de investimento, posicionamento
no mercado, etc. Porém, o projeto não é elaborado em seus mínimos detalhes, ele é
somente visto em suas funcionalidades ao usuário final numa visão holística e
separado em itens chamados de User Stories (podendo ser Casos de Uso ou
Features, caso a empresa não utilize a metodologia em sua versão ideal), como
explicado por Cohn (2004). A idéia básica da mudança de um caso de uso para uma
user story, normalmente escrita como “Como <tipo de usuário>, quero
<funcionalidade> para <motivo definido de negocio>”, é permitir a discussão de
como ela será feita com o time, que tem conhecimento técnico para, junto com o
product owner, que conhece os benchmarks do mercado, chegar a uma
funcionalidade que possa levar um melhor produto final, com uma identidade da
empresa. É muito importante que as user stories sejam o máximo independentes
entre si, podendo ser repriorizadas e inclusive lançadas sem dependências, o que
nem sempre é possível (COHN, 2004). Dois exemplos com características
diferentes são:

Como usuário do site, quero receber aviso de cobrança 10 dias antes
para poder me planejar e pagar o site em dia

Como servidor, quero receber arquivos XMLs em estruturas pré-
definidas a fim de refinar e garantir os dados que publicarei no site.

Havendo as estórias, prepara-se o plano de lançamento, chamado de release
planning, onde agrupamos as estórias para seus lançamentos intermediários, ou
somente como pacotes de versionamento dentro do controle de versão. Este
planejamento de release é importante para possíveis lançamentos no mercado e
avaliação de seu recebimento, o que poderá fazer com que os próximos
desenvolvimentos sejam alterados devido a este feedback (features não planejadas
foram verificadas como fundamentais, conceito do projeto não seria mais bem aceito
no mercado, etc).

Com a preparação feita, o product owner, juntamente com o scrummaster e
stakeholders, validarão a separação das user stories e farão uma priorização inicial
delas. Caso seja a primeira reunião, será definida a equipe, ou já contratada, será a
ela apresentada o projeto numa visão geral. Este conjunto de user stories forma o
artefato chamado de product backlog, ou backlog de produto, onde temos todas as
estórias que, finalizadas, significariam o projeto finalizado.

O time, então, avalia as estórias criadas. Duas maneiras são utilizadas para serem o
peso da avaliação, conforme explicado em Schwaber (2003): dias ideais
(semelhante às horas tradicionais utilizadas) ou complexidade. A complexidade é
votada pela equipe (no chamado planning poker), utilizando pesos baseados na
seqüência de Fibonnaci (1, 2, 3, 5, 8, 13, 21, etc., até 100). Ao não haver um
consenso, os votos de menor e maior peso explicam seus votos e há uma nova
votação, até haver um consenso. O mais aconselhável na metodologia é a
complexidade, por diminuir a pressão quanto a datas em cima da equipe e por
complexidade, sendo um valor relativo, é algo que se mantém independentemente.
Vale lembrar, como enfatizado em Cohn (2004), que a votação de qualquer item
deve ser feito por toda equipe, o que ajuda a gerar o feeling inter disciplinar e leva a
discussão aberta de soluções que podem não ter sido vistas pelos especialistas, ou
a não especialistas entenderem a dificuldade de alguns tópicos da estória.

Após esta avaliação, começa a primeira atividade Scrum, o planejamento do Sprint
(sprint planning), como explicado em Cohn (2004). Ele é dividido em duas etapas,

cada uma devendo durar até quatro horas. Neste evento, onde somente a célula
deve participar, são verificados os detalhes das estórias, onde se resultam
documentos inicias de critérios de aceite (que poderão gerar casos de teste e
requisitos de funcionalidade), protótipo de telas, se existentes (preferencialmente
feitos em um papel, para manter a velocidade da reunião), tudo que for necessário
de definição das estórias. Vale lembrar que as estórias são as mais atômicas
possíveis, para serem entregas possíveis e ágeis dentro do sprint. Sendo esta a
primeira reunião, também é definida a duração do sprint, sendo de uma semana a
um mês. A equipe, sem influência do product owner, deverá se comprometer a
entregar uma seleção das estórias priorizadas neste período. O total de pontos de
complexidade será a velocidade inicial do time.

Na segunda parte do planejamento, a equipe quebrará em tarefas as estórias,
focando em ter tarefas realizáveis em um dia, no máximo, se possível. Também
serão tomadas decisões pela equipe como, por exemplo, que tecnologia ou
arquitetura de software utilizará para desenvolver uma estória da forma que tenha
uma boa qualidade, menos operação possível, e que seja escalável, tanto em
utilização como evolução. Com as tarefas, é iniciado o preenchimento do dashboard,
o quadro de trabalho, a ser utilizado. É aconselhável ser utilizado um quadro branco
com as tarefas, para ser visível pela empresa toda, porém é possível utilizar-se
ferramentas existentes, como Mingle, Microsoft Team Foundation, Version One,
entre várias outras. A escolha da ferramenta deve refletir o modelo de trabalho
utilizado, pois cada uma segue uma linha (utilização de dias ideais, de horas de
tarefas, de controle de bugs, etc).

Acabado o planejamento, teremos os artefatos: release plan, product backlog,
selected product backlog, sprint product backlog.

3.3.1.4. PROCESSO DIÁRIO

O dia a dia do Scrum é refletido no dashboard, conforme exibido um modelo na
figura 20.

Figura 19 - Apresentação do dashboard. Fonte: Flavio (2008)

Diariamente, em um horário acordado pela célula, preferencialmente no inicio do dia,
a equipe se reunirá em uma reunião, em pé preferencialmente (se for utilizado um
quadro, melhor), para verificarem: o que foi feito no dia anterior (feito, DONE), o que
será feito no dia (em execução, Doing ou Work in Progress), verificando o que será
feito em seguida (a fazer, ou To Do) e o que está impedindo o andamento das
tarefas. O scrummaster deverá agir prontamente na resolução destes impedimentos.
A reunião deverá demorar no máximo quinze minutos.

Demandas adicionais deverão ser sinalizadas no dashboard, conforme a empresa
esteja utilizando: como impedimentos, numa área de demandas adicionais, ou como
uma estória extra que totalizará estas demandas. Elas são importantes para
evidenciar o que está impactando a entrega da equipe.

Havendo estórias finalizadas, a equipe atualizará o gráfico de entregas do sprint,

chamado de sprint burndown chart, a fim que todos consigam ver o andamento do
processo. É necessário lembrar que uma tarefa só é considerada entregue, ou feita,
ao atender todos os critérios previamente definidos, negociados e aceitos pelo
product owner.

Muitas vezes, principalmente no inicio da adoção de Scrum, é necessário se quebrar
mais uma estória durante o sprint, pela falta de maturidade dos participantes na
metodologia. Isto deve ser feito quando necessário e refletido em todos os artefatos
do processo, se todos de acordo com a alteração.

Pessoas que não fazem parte da célula podem participar da reunião, mas o
scrummaster deve verificar sua participação. É comum shareholders quererem
participar para pressionar a equipe, o que somente prejudicará o andamento do
processo. Como ouvintes ou como auxiliadores na remoção de impedimentos
institucionais, são bem vindos à reunião diária.

Diariamente, temos a atualização dos artefatos: sprint product backlog, sprint
burndown chart, dashboard e impedimentos.

3.3.1.5. FINALIZAÇÃO DA ITERAÇÃO

Ao chegar o penúltimo dia do sprint, este é considerado o último dia de atividades de
desenvolvimento, pois o último dia é reservado aos eventos de sprint review e sprint
retrospective.

O Sprint Review consiste em uma reunião onde todos os interessados são
convocados para terem uma apresentação, pelo time e product owner, do que foi
feito. O ideal é não haver uma apresentação tradicional, gerada por ferramentas,
mas sim a exibição das features finalizadas. Esta é a aprovação final do
desenvolvido, onde os shareholders, se presentes, e stakeholders, avaliam o
desenvolvido. Também é nesta reunião onde se discute o produto em si, possíveis

novos caminhos verificados durante o sprint, apresentam-se os problemas
encontrados, principalmente os institucionais, pois os presentes devem saber do que
está afetando a produtividade da equipe, avaliando alguma possível mudança.

Após esta reunião, a equipe se reúne e reavalia como foi o andamento do sprint,
seja montando uma linha do tempo ou somente com suas opiniões. A equipe levanta
o que achou que deu certo no processo, o que deu errado, e o que pode ser
melhorado. O scrummaster e product owner deverão trabalhar em cima dos erros e
possibilidades de melhoria para melhorar a produtividade, o ambiente de trabalho, e
a qualidade do produto final. É muito útil, se utilizado um quadro, colocar em um
espaço dele as melhorias a serem feitas, para diariamente, durante o Daily Scrum,
elas serem lembradas e reafirmadas, a fim de não ocorrerem novamente.

No dia seguinte, o primeiro dia do próximo sprint, é reavaliado as prioridades
estabelecidas anteriormente. Novas estórias podem ser inseridas e priorizadas,
outras podem ser removidas ou despriorizadas, e o time pode solicitar a reavaliação
de alguma estória devido ao aprendido e verificado no último sprint. A experiência
obtida pode levar a uma nova quebra de estórias. Dado isso, há um novo
planejamento de sprint e a iteração se reinicia.

Segundo entrevista concedida por Juan Bernardó, presidente da empresa
Teamware, responsável pela implementação de Scrum em empresas como iG e
Globo.com, entre outros portais de conteúdo de internet no Brasil, os três primeiros
meses são os mais críticos na implementação. É nesta fase que os implementadores
de Scrum (seja uma empresa terceira ou os scrummasters) devem ter o máximo
apoio dos stakeholders, pois será quando os problemas da empresa aparecerão,
tais como impedimentos pelos processos (falta de infra-estrutura, demora em
aquisição de recursos) e operações e demandas adicionais excessivas impactando o
desenvolvimento da equipe (e assim, quebrando a blindagem da célula).

Outro ponto muito importante, decorrente dos resultados destes três meses, é a
adaptação do Scrum a realidade da empresa. Neste ponto, muitas empresas que
não tem a confiança nos seus scrummaster podem falhar e decidir por abortarem a

implementação. É necessário que a metodologia se adéqüe a situação da empresa,
sem abandonar os principais dogmas da filosofia, parafraseando Schwaber(2004),
“Scrummaster bom é Scrummaster vivo”. Exemplos de adaptação são a utilização de
ferramentas online ou de conferências por ferramentas como MSN e Skype para a
sincronia de equipes distribuídas e inclusão de etapas derivadas do conceito de
pronto da empresa (se há uma necessidade de documentação rígida para aplicação
de CMMI, há uma fase pós-aceite do dono do produto de geração de documentação,
só aí a estória estará aceita pela empresa). Como já citado no texto, a metodologia
tem poucos processos definidos, o que facilita a adaptabilidade.

Ao ser perguntado quanto à implementação de Scrum em qualquer tipo de empresa,
Juan defendeu a possibilidade de ser viável, porém não sendo realmente produtivo
em alguns casos, como em industrias de construção civil ou mecânica, que teriam
mais produtividade e controles necessários com outras metodologias, como o
Kanban, que explicaremos a seguir. Porém, sua visão é a de que empresas de
internet voltadas a conteúdo e serviços não financeiros, onde a definição do retorno
de investimento são mais difíceis de mesurar, a aplicação de Scrum torna a empresa
mais produtiva, com facilidade de análise parcial do sucesso de seus produtos.

3.3.1.6. ESCALANDO SCRUM

Uma das principais questões da metodologia é sua escalabilidade: para pequenos
times, a metodologia parecia funcionar muito bem, mas não havia ainda uma
uniformidade em como executá-la em uma empresa multinacional, e como manter
alinhadas todas as células quanto ao trabalho de seus pares, algo que o dogma de
transparência prega fervorosamente, além de ir de encontro com outros conceitos
como Balanced Scorecard.

O principio da transparência, apesar de ser aconselhado o uso de métodos como
quadros e reuniões físicas, certamente não atendem todo tipo de empresa. Nestes
casos, para manter o alinhamento de equipes separadas fisicamente, nada mais
natural que a utilização de conferências, sejam por mensageiros instantâneos (como
MSN e Skype) e vídeo conferencias diárias.

O princípio da melhoria contínua não se limita ao time. Para haver uma melhoria dos
processos Scrum, e de como adequá-los a realidade da empresa, é necessário que
os defensores da metodologia em cada célula se reúnam diariamente para saberem
o que as equipes estão fazendo, o que uma pode estar fazendo que possa impactar
outra, e principalmente planejarem melhorias na aplicação. Esta reunião
normalmente é chamada de Scrum of Scrums. É sugerido que também sempre vá
pelo menos uma pessoa da equipe, não só para ela acompanhar as decisões e
poder tornar-se um scrummaster, caso deseje, mas para haver uma outra visão dos
processos, o da equipe em si.

Em algumas empresas, como Google, há um grande encontro entre todas as células
na finalização do Sprint Review, onde todas as equipes vêem o que as outras
fizeram, e o que planejam fazer. Como esta é uma reunião muitas vezes complexa
de ser executada (pela quantidade de pessoas ou distancia), também é utilizado
ferramentas como vídeos online, comunicações via blogs internos, e-mail, ou o que
for possível pela empresa.

As reuniões de product owner, em contraponto, são normais em muitas linhas de
produção, como gestão de portfolio, de programa, alinhamento estratégico, entre
outras. O aconselhado pela metodologia é que esta reunião tenha os projetos e suas
estórias priorizadas por todos os shareholders necessários, para todas as células
estarem apontando à estratégia da empresa.

3.3.2. OUTRAS METODOLOGIAS ÁGEIS

As principais metodologias ágeis seguem muito dos conceitos apresentados acima,
como reuniões diárias, comunicação livre entre os participantes, transparência do
andar do projeto e aceitação do principio da incerteza do escopo no inicio do projeto.
Todas as metodologias, ou frameworks, também enfatizam a qualidade, sejam
seguindo o ciclo de Deming (Planejar, Executar, Verificar e Agir) ou o chamado Seis
Sigma, que, segundo PIZDEK (2003), foi inspirado no próprio ciclo de Deming.
Podemos exemplificar metodologias como o Agile Project Management e Feature
Driven Development, o chamado FDD, como seguidores desta filosofia.

Uma metodologia que difere do conceito abordado anteriormente é o Kanban. Este
deriva da filosofia Just In Time, criada, segundo Correia (2001 apud PEDROSO,
2007), na Toyota, em meados da década de 70. Segundo Moura (1989 apud
PEDROSO, 2007):

O Just-in-Time é uma abordagem disciplinada para melhorar a
produtividade e a qualidade total, através do respeito pelas pessoas e da
eliminação das perdas. Na fabricação e/ou montagem de um produto, o
Just-in-Time proporciona a produção no custo efetivo e a entrega apenas
das peças necessárias com qualidade, na quantidade certa, no tempo e
lugar certos, enquanto usa o mínimo de instalações, equipamentos,
materiais e recursos humanos.

Como podemos ver, o conceito do Just-in-Time se aproxima da filosofia ágil, pelo
foco na produção voltada ao negócio, com qualidade. Seu grande diferencial é a
utilização de conceitos de fila para o controle da produtividade dos setores.

No processo de linha de produção tradicional, um setor, ao verificar uma
necessidade, demanda a execução ou compra a sua seção seqüente na linha.
Como a produtividade destas seções subseqüentes podem não ter a mesma
velocidade do espaço entre os pedidos, começa-se a ter um armazenamento e uma
fila de produção crescente, levando a demoras na finalização de produtos e a

grandes espaços de estocagem.

As principais características do kanban, segundo Pedroso (2007), são que o
processo posterior deveria respeitar o predecessor, solicitando o necessário, e que
nenhuma execução ou compra deve ser feita sem ter seguido esta linha, simbolizada
numa solicitação em um cartão Kanban. Assim, só será comprado e talvez estocado
por algum tempo, o necessário para atender uma demanda real. Isto faz com que,
além de não haver gastos desnecessários, a produtividade de cada seção seja
detectada e os problemas em alguma seção sejam claros a todos.

O Kanban utiliza um quadro indicando as solicitações feitas, simbolizadas nos
cartões Kanban, e em que seção eles se encontram no momento. Alem das colunas
de seções, há a existência de 3 linhas, cada uma de uma cor, para simbolizar a
urgência da execução de algo do item (seja compra de material, finalização da
montagem, etc.). Um quadro Kanban é exemplificado na figura 20.

Figura 20 – Painel Kanban. Fonte: Pedroso (2007).

Com a utilização do Kanban, podemos chegar a um cálculo da produtividade de

cada seção, sabendo assim o tempo para a montagem de um produto, chegando à
produtividade da fábrica com maior exatidão. Também se controla mais facilmente
os gastos exatos para essa meta, evitando gastos inúteis, com execuções que
podem levar a produtos que não sejam utilizados (um bom exemplo é na indústria
alimentícia, onde há validade dos subprodutos).

Apesar do passado acima estar aplicado em indústrias tradicionais, o kanban tem
sido utilizado em indústrias de software, numa adaptação do modelo de
gerenciamento tradicional, em cascata, utilizando como setores Engenharia,
Aquisição, Desenvolvimento e Qualidade, por exemplo. A aplicação do chamado
Agile Kanban é bem apresentando em Hiranabe (2007), onde, além do quadro
tradicionalmente utilizado pela equipe, podemos utilizar outros quadros para visões
mais holísticas, que simbolizam os estágios do desenvolvimento para uma versão de
uma feature, e outro com o plano por iterações de quando cada release terá uma
versão. Estamos assim criando uma visão para o time (de tarefas), para os gerentes
de produto ou donos de produto (quanto a releases) e para os stakeholders (quanto
aos lançamentos pelo tempo). A figura 21 apresenta como seria esta visão.

Figura 21 – Visualização de projetos ágeis utilizando quadros Kanban. Fonte: Hiranabe (2007).

4. Conclusão

As empresas de internet brasileiras, após o período chamado de “bolha”, se
estabilizaram e somente as que têm uma visão séria do mercado e trabalham com
planos estratégicos sobreviveram e continuarão vivas. Empresas de sucesso rápido,
porém sem visão de retorno de investimento, não sobreviveram. Alguns deles foram
assimilados pelos portais com mais visão, o que gerou no mercado brasileiro uma
polarização em cada segmento: portais de conteúdo (onde a fusão dos portais iG,
iBest e BrTurbo criou um forte pólo), comércio eletrônico (com a junção de
Americanas, Shoptime, Submarino e BlockBuster criou um gigante, tanto eletrônico
quanto no mundo offline), serviços interativos (onde parcerias dos grandes portais
com os maiores players mundiais como Google e Yahoo fez com que tivessem
disponíveis aos seus usuários as melhores ferramentas do mercado), entre outros
segmentos.

Com a polarização do mercado de portais de conteúdo, a competição entre poucos
players com seus serviços sempre em evidência fez com que a agilidade em lançar
serviços de qualidade antes que seus concorrentes se tornasse um pilar competitivo
primordial. Comparando a outra área, o Google, com o lançamento do Gmail, com
sua interface limpa e com um espaço muito maior que seus concorrentes fez com
que dominasse o mercado de emails gratuitos mundialmente, tirando espaço dos
antigos rivais Yahoo e Microsoft (com seu Hotmail), que apesar de lançarem
posteriormente serviços de níveis semelhante, já haviam perdido parte de seu
público e o elemento de inovação aos usuários.

Todos os três sistemas de emails já começavam a utilizar, desde o inicio dos anos
2000, uma abordagem ágil para a evolução de seus serviços. Isto proporcionou com
que constantemente, seus usuários tivessem uma feature nova disponível para
utilização, como por exemplo, corretor ortográfico online, verificação de
disponibilidade com a pessoa que se troca e-mails, salvar em rascunho um email
num webmail, etc.

GESTÃO DE PROJETOS ÁGEIS: UMA ANÁLISE DOS PRINCIPAIS PORTAIS DE CONTEÚDO NA INTERNET BRASILEIRA

GESTÃO DE PROJETOS ÁGEIS: UMA ANÁLISE DOS PRINCIPAIS PORTAIS DE CONTEÚDO NA INTERNET BRASILEIRA

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (10)

Ähnlich wie GESTÃO DE PROJETOS ÁGEIS: UMA ANÁLISE DOS PRINCIPAIS PORTAIS DE CONTEÚDO NA INTERNET BRASILEIRA

Ähnlich wie GESTÃO DE PROJETOS ÁGEIS: UMA ANÁLISE DOS PRINCIPAIS PORTAIS DE CONTEÚDO NA INTERNET BRASILEIRA (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

GESTÃO DE PROJETOS ÁGEIS: UMA ANÁLISE DOS PRINCIPAIS PORTAIS DE CONTEÚDO NA INTERNET BRASILEIRA