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

9,742 views
9,553 views

Published on

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

Published in: Education, Technology, Business
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,742
On SlideShare
0
From Embeds
0
Number of Embeds
41
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

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

  1. 1. 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
  2. 2. CLAUDIO MONTEIRO DA SILVA PAULO MOREIRA MARINHO GESTÃO DE PROJETOS ÁGEIS: UMA ANÁLISE DOS PRINCIPAIS PORTAIS DE CONTEÚDO NA INTERNET BRASILEIRA 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
  3. 3. CLAUDIO MONTEIRO DA SILVA PAULO MOREIRA MARINHO GESTÃO DE PROJETOS ÁGEIS: UMA ANÁLISE DOS PRINCIPAIS PORTAIS DE CONTEÚDO NA INTERNET BRASILEIRA 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
  4. 4. 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.
  5. 5. 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ó.
  6. 6. 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.
  7. 7. 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.
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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.
  13. 13. 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
  14. 14. (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.
  15. 15. 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
  16. 16. 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;
  17. 17. 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
  18. 18. 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/
  19. 19. 2. Fontes secundárias: Textos de gerenciamento de projetos usados durante o curso; Experiência profissional vivida, trazida em alguns casos de uso.
  20. 20. 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
  21. 21. 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).
  22. 22. 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.
  23. 23. 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.
  24. 24. 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,
  25. 25. 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;
  26. 26. 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
  27. 27. 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).
  28. 28. 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
  29. 29. 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
  30. 30. 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.
  31. 31. 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.
  32. 32. 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).
  33. 33. 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)
  34. 34. 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
  35. 35. 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
  36. 36. 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).
  37. 37. 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.
  38. 38. 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.
  39. 39. 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-
  40. 40. 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.
  41. 41. 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
  42. 42. 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).
  43. 43. 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
  44. 44. 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)
  45. 45. 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.
  46. 46. 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.
  47. 47. 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.
  48. 48. 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.
  49. 49. 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
  50. 50. 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
  51. 51. 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,
  52. 52. 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.
  53. 53. 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.
  54. 54. 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
  55. 55. 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
  56. 56. 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
  57. 57. 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. É
  58. 58. 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.
  59. 59. 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,
  60. 60. 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
  61. 61. 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,
  62. 62. 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
  63. 63. 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
  64. 64. 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.
  65. 65. 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.
  66. 66. 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
  67. 67. 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
  68. 68. 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).
  69. 69. 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.

×