Hirotaka Takeuchi e Ikujiro Nonaka, os criadores do Scrum, acreditam que uma metodologia como um estilo de “corrida de revezamento” aplicada ao desenvolvimento de produtos pode conflitar com os objetivos de velocidade, qualidade e flexibilidade. Ao invés disto, um estilo holístico, onde a equipe busca, como em um jogo de futebol, de forma integrada, chegar ao gol, com passes de bola, pode servir melhor às atuais necessidades competitivas.

Dessa forma as principais características do Scrum são:

• Processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível.
• Isto permite a rápida e contínua inspeção do software em produção (em intervalos de duas a quatro e duas semanas).
• As necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema.
• As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade.
• Entre cada duas a quatro semanas todos podem ver o real software em produção, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um “Sprint”.

Antes de abordar as etapas do Scrum é fundamental entendermos quais são os participantes e quais os seus papéis dentro da metodologia. Nesse ponto não vale a pena se preocupar com o vocabulário, de fato muitos termos serão citados, mas, no momento certo eles serão aprofundados. O objetivo, nessa parte, é apenas situar quem é quem dentro do processo.

Product Owner (P.O) – Define as funcionalidades do produto, decide datas de lançamento além de priorizar as funcionalidades de acordo com o seu valor de negócio. O valor de negócio (Business Value) de uma determinada funcionalidade é estipulado em uma escala de zero a cem.

É responsabilidade do P.O. mensurar a rentabilidade – ROI - do projeto, estabelecendo metas e analisando até que ponto o custo de um “Sprint” é menor que o lucro do projeto. A partir do momento que um Sprint custe mais do que seu retorno é a hora de interromper o projeto. O ROI não é necessariamente um retorno financeiro, podendo ser medido por audiência, aumento de tráfego e outros tipos de benefícios para o negócio.

A última responsabilidade do P.O. é aceitar, ou não, as funcionalidades entregues. Caso uma funcionalidade seja recusada essa volta para o “backlog” e deve ser incluída em um próximo “Sprint”, isso acontece até que determinada funcionalidade seja aceita pelo P.O.

Scrum Master – Gerente de projetos é o termo conhecido que mais se aproxima de um Scrum Master, contudo esse indivíduo não exerce exatamente as funções delegadas a um gerente de projetos. A principal responsabilidade atribuída a um Scrum Master é a de viabilizador.

Dessa forma um Scrum Master deve remover os obstáculos que impeçam ao time atingir seus objetivos, garantir a plena funcionalidade e produtividade da sua equipe assim como a colaboração entre os diversos papéis e funções.

O Scrum Master também é responsável por organizar todos os encontros do ciclo de um Sprint, além de ser um escudo para o time contra interferências externas.

Team (time) – Um time de Scrum é composto entre 5 a 9 indivíduos, esse é um requisito fundamental para a boa prática da metodologia. Os times devem ser multifuncionais, ou seja, devem existir profissionais de diversas especialidades, desenvolvedores, arquitetos da informação, designers, etc.

É importantíssimo que todos os membros se dediquem em tempo integral ao time, as exceções existem, contudo devem ser utilizadas apenas para os profissionais que exercem papéis pontuais como: administradores de base de dados, analistas de suporte e equipe de infra-estrutura.

Os times são auto-organizaveis, não existe títulos ou hierarquia entre os membros, a equipe que decide como será o seu dia-a-dia, sempre focado no objetivo do Sprint. Troca de pessoas entre os times devem ser feitas apenas entre um Sprint e outro.

Apresentados os atores de uma equipe de Scrum o próximo passo é começar a dissecar o ciclo da metodologia. No próximo post vamos desvendar o que é um Sprint, Backlog, Daily Meeting entre outros termos do Scrum.

Quando participei do meu primeiro Sprint em uma reunião de Scrum, achei aquilo tudo uma infantilidade, parecia um grupo de adolescentes jogando RPG. Tinha um tal de ScrumMaster, outros eram chamados de porcos, galinhas não podiam falar, pelo menos eu era um Product Owner, titulo um pouco mais sério. ;-)

Perplexo fiquei quando percebi que dentro de toda aquela aparente brincadeira decisões sérias estavam sendo tomadas, requisitos estavam sendo passados, prioridades definidas, prazos estipulados e uma dezena de pessoas bastante empolgadas e motivadas trabalhando. Fiquei confuso e muito curioso.

Comecei a pesquisar sobre o assunto, logo descobri que a metodologia ou filosofia – segundo os gurus - não era tão jovem assim. Na realidade o Scrum foi desenvolvido por dois executivos da Toyota, Takeuchi e Nonaka em 1985 a fim de aperfeiçoar o processo produtivo da linha de montagem da companhia.

A Wikipedia, define muito bem o Scrum: “A função primária do Scrum é ser utilizado para o gerencimanto de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.”

Casamentos a parte, o Scrum é um framework com algumas regras bem definidas que auxilia um pensamento ágil dentro de uma organização a fim de aumentar a produtividade no desenvolvimento de projetos de qualquer espécie.

No mês de outubro tive o prazer de participar de alguns treinamentos dirigidos pelo alemão Boris Gloger, um dos mais renomados “coach” da metodologia no mundo. Depois dessa bateria de treinamentos – mais de 40 horas - consegui absorver bastante a respeito de como funciona todo o processo. Dessa forma estarei escrevendo, em módulos, um pouco mais sobre o Scrum nos próximos posts.

Aguardem!

Continuando um pouco na linha do artigo anterior, vimos que a restrição tripla ilustra de forma simples como definir as conseqüências de mudanças em projetos. Isso acontece por diversos fatores internos externos ao projeto ou a organização.

Temos ainda um aspecto que não foi mencionado no artigo anterior – a qualidade. Ainda utilizando a figura do artigo passado, a qualidade seria um círculo bem no centro do triângulo, o que simboliza que a qualidade é afetada quando são alterados quaisquer um dos outros aspectos básicos do gerenciamento de projetos. Quem trabalha com projetos, independente da área, sabe como é ouvir que o relatório tem que ficar pronto até o final do dia. Ou que um projeto foi vendido para ser feito em quatro meses e, após um estudo mais detalhado, viu-se que não seria viável nesse prazo. Ou ainda a necessidade de recursos para realizar o projeto dentro de padrões de qualidade aceitáveis está muito acima do orçamento que foi posto a disposição para o projeto.

Um estudo feito anualmente pelo PMI coleta dados de mais de 300 empresas através de formulário de perguntas entregue aos altos gestores de cada uma delas. Dentre inúmeros pontos contemplados pela pesquisa, cito dois abaixo que acredito serem importantes:

Custos – 94% das empresas admitem ter problemas de ultrapassar os custos planejados para seus projetos;

Prazo – 96% das empresas admitem ter problemas de estourar os prazos planejados para seus projetos;

Fonte: PMI RIO*

Esses números, sozinhos, podem nos dar a impressão errada. Existem vários motivos para que esses atrasos e estouros em custos aconteçam. Por exemplo, podemos ter tido um aumento do escopo, levando a mudanças no planejamento original, incluindo prazo e custo. Então é necessário que analisemos mais a fundo esses motivos e proponho que comecemos pela estrutura organizacional na qual o projeto está sendo realizado.

Todas as empresas, ao longo de sua história, desenvolveram culturas, normas, expectativas, políticas e procedimentos que de alguma forma se fizeram necessários aos olhos da alta gerência no intuito de manter a empresa no rumo certo.

Todos esses aspectos influenciam fortemente no modo como as empresas realizam seus projetos. E porque as empresas realizam projetos? Comentei anteriormente que vários podem ser os motivos: econômico, jurídico, mudanças no mercado nacional ou internacional ou pressão da concorrência. Mas, basicamente, todos esses fatores se resumem ao fato de que somente fazer a empresa manter seus processos não é mais suficiente. Todos, inclusive nós pessoas físicas, precisamos nos atualizar constantemente e essas mudanças somente são possíveis quando realizamos projetos, sejam eles de ordem pessoal ou empresarial.

A comunidade do gerenciamento de projetos vem trabalhando para criar padrões e métodos de gerenciamento de projetos. Já existem muitos padrões sendo utilizados na gerência de projetos atualmente, mas nunca poderemos deixar de levar em consideração as características do meio ambiente no qual o projeto está sendo realizado. E é aí que entram a cultura e o estilo organizacional. Essas estruturas organizacionais vão influenciar diretamente nas condições de alocação e disponibilidade de recursos para a execução de projetos.

Existem 3 tipos clássicos de estruturas organizacionais:

1) Organização Funcional – Ainda muito comum hoje em dia, neste tipo as organizações se agrupam em áreas de especialização e a figura do gerente de projetos praticamente não existe. Esse modelo funciona muito bem com organizações que lidam diretamente com processos (p. ex.: Indústria)

2) Organização Matricial – Também chamada de mista, reúne os pontos fortes e fracos das outras duas organizações. As organizações funcionais geralmente caminham para esse tipo de organização quando almejam atingir melhores resultados na gerência e execução de projetos. Nesse tipo, as equipes reportam a dois chefes: o gerente funcional e o gerente de projetos.

Esse tipo ainda pode se subdividir em 3 categorias:
a. Fraca – poder nas mãos do gerente funcional
b. Balanceada – poder dividido
c. Forte – poder nas mãos do gerente de projetos

3) Organização Projetizada – A empresa se organiza por projetos. As “áreas” da organização são os projetos que ela está desenvolvendo. Quando um projeto termina, a “área” se desfaz e é alocada em outro projeto. É interessante notar que um funcionário pode ser gerente de projetos em um momento e no outro ser um analista sênior. É a organização onde o gerente de projetos possui a maior autoridade. (p. ex.: Consultorias)

As organizações não baseadas projetos costumam não possuir o ferramental adequado para suportar as necessidades de projetos de modo efetivo. Já as organizações baseadas em projetos tratam seus processos aplicando técnicas de gerenciamento de projetos, o que as tornam mais eficazes nesse sentido.

“A estrutura da maioria das empresas é burocrática e lenta e esses modelos não conseguem dar uma resposta rápida a um ambiente em constante mutação. Portanto, a estrutura tradicional deve ser substituída por uma estrutura de projetos que seja capaz de responder rapidamente às situações criadas dentro e fora das organizações.”

Harold Kerzner

No próximo artigo, vamos falar dos integrantes de um projetos que podem ajudar as organizações a melhorar nesse sentido, os chamados Stakeholders.

Um grande abraço e até lá!

* Na página inicial do PMI Charpter Rio, existe um link para o documento do estudo citado nesse artigo.

O gerenciamento de projetos no mundo vem crescendo e ganhando maturidade já a alguns anos quando, por exemplo, foi lançada na década de 90 a metodologia PMI. Ela contém 9 áreas de conhecimento, os chamados processos, já descritos no primeiro artigo escrito para esse blog.

No entanto, ainda temos muitos problemas com o gerenciamento de projetos e grande parte dos projetos executados nas empresas não consegue ter sucesso ou tem um sucesso parcial, mas deixa desejar em alguns aspectos.

A aplicação das metodologias existentes não depende apenas do conhecimento do gerente do projeto, mas também do apoio da alta gerência e da criação da cultura dentro das empresas. 

Muitas vezes, um gerente se vê numa posição desconfortável, quando não consegue imprimir seu ritmo e estilo de gerenciar em um determinado projeto. A estrutura empresarial e a cultura vigente não permitem, mas quando existe pelo menos o apoio da alta gerência, é hora de começar a aplicar, mesmo que seja em parte, uma das metodologias existentes para gerenciar projetos. E uma boa forma de manter seu projeto nos eixos e aplicando o uso da restrição tripla.

A restrição tripla é composta pelos processos de Custos, Tempo e Escopo e é representada pela figura de um triângulo. Cada um desses processos representa um lado.

Figura 1: Imagem básica da restrição tripla

Essa representação gráfica nos ajuda, principalmente, a visualizar as conseqüências das mudanças em cada um desses processos do GP. Segue abaixo uma imagem que pode ajudar ainda mais a visualizar como é importante controlar esses três aspectos:

Figura 2: Imagem com mudanças em custo e duração

Tente, num triângulo qualquer, mudar o tamanho de um dos lados sem alterar os outros? Não existe mágica no gerenciamento de projetos. Se o custo aumenta para um projeto no qual o escopo se manteve o mesmo, provavelmente o que se quer é acelerar as entregas do projeto, alocando-se mais recursos ou fazendo os recursos já alocados trabalharem mais (as famigeradas horas extras). Se o escopo (trabalho do projeto) do projeto aumentar, ou será necessário ajustar o cronograma do projeto e alongar sua execução ou vamos precisar alocar mais recursos para realizar as mudanças pedidas no escopo no mesmo tempo previamente definido. Ou ainda existem os casos onde o escopo aumenta, os custos aumentam, pois são alocados mais recursos (tanto humanos quanto materiais) e mesmo assim não é possível realizar o projeto todo no tempo definido durante o planejamento. Neste caso, os três lados desse triângulo vão ser impactados e todo o planejamento precisará ser revisto.

As mudanças vão impactar no mínimo duas dessas visões e, por isso, a necessidade de se gerenciar as mudanças de forma organizada, para que os impactos sejam os mais suaves possíveis é muito importante.

Nota do autor: Caros leitores, sei que o artigo não esta muito detalhado, mas como a semana foi mais curta, o tempo para desenvolver este artigo também diminuiu. Na semana que vem vou abordar o tema a respeito da estrutura organizacional das empresas e como essa estrutura influencia na forma como gerenciar projetos. Um abraço e bom feriado pra todos!
 

Como havia dito no artigo anterior, empreender é inerente ao ser humano, a cultura de todos os povos que existem ou já existiram no nosso planeta. Com o passar do tempo, tudo que fazemos é aprimorado e com o gerenciamento de projetos não é diferente.

Muitas iniciativas de estudiosos do tema fizeram com que a literatura a respeito da gerência de projetos se tornasse bastante vasta, as técnicas evoluíram e atualmente existem organizações que provêem modelos e formas de se gerenciar projetos consagradas em todo o mundo, como o PMI (Project Management Institute), IPMA (International Project Management Association) e a PRMIA (Professional Risk Management International Association), por exemplo.

Todos esses modelos diferem em alguns pontos, mas no geral eles objetivam a mesma coisa: gerenciar projetos de forma organizada, realista e que permita o acúmulo de informações estruturadas para proporcionar aprendizado e evolução contínua.

Estima-se que US$ 10 trilhões são gastos anualmente ao redor do mundo em projetos (o equivalente a 25% do PIB Mundial) e 16,5 milhões de profissionais estão diretamente ligados com o gerenciamento de projetos. (Fonte: PMI)

Estes números nos mostram que o gerenciamento de projetos está se tornando cada vez mais importante para o mundo corporativo e hoje em dia já é um diferencial competitivo para as empresas. Isso pode se observar nos setores onde essa competição é mais acirrada, como o mercado de Telecomunicações.

Mas como estamos gerenciando projetos?

Existem diferenças de maturidade entre as diversas áreas de negócios do mercado. Se formos tomar TI, por exemplo, veremos que ainda estamos engatinhando se comparados com a construção civil, que já emprega conceitos similares aos do PMI há mais de 50 anos. Isso não confirma que a construção civil acerta em todos os projetos que empreende, mas indica pelo menos que projetos de construção civil são gerenciados de forma mais madura.

Projetos podem dar errado?

A resposta é sim. E a verdade é que muitos projetos dão errado atualmente. Ainda estamos muito imaturos no gerenciamento de projetos. Algumas estatísticas para embasar estas afirmações:

• 45% dão errado dos projetos não utilizam ou utilizam de forma incorreta as melhores práticas de gerência de projetos;
• 33% dão errado dos projetos não possuem um comprometimento sério das partes envolvidas (Stakeholders*) no projeto;
• 22% por outros motivos.

Dentro da primeira estatística, listo aqui alguns pontos interessantes:

• Metas e objetivos mal definidos ou mal compreendidos pela equipe do projeto;
• Muitas atividades e pouco tempo para realizá-las;
• Planejamento do projeto baseado em informações insuficientes, inadequadas ou inconsistentes;
• Estimativas de custo e prazo aferidos sem nenhuma metodologia, utilizando apenas o que chamamos de “feeling”;
• Os objetivos do projeto e seus produtos finais mal definidos;
• Falta de uma comunicação efetiva, propagação de informações que prejudicam o projeto, falta de informação no tempo certo;

Na realidade, existem vários razões para um projeto dar errado. E é por isso que precisamos cada vez mais evoluir as técnicas existentes, mas precisamos utilizar as que já existem da forma mais eficiente.

E o que significa “O projeto deu errado”?

Conceitualmente falando, o projeto deu errado porque não aconteceu da forma como foi planejado. É claro que o projeto sofre replanejamentos. O ambiente externo (política, economia) muda a toda hora; fatores como a globalização transformam um projeto do dia para a noite e é preciso estar preparado para essas interferências. Como diz um professor meu “A única coisa que não muda em um projeto é o fato de que o projeto sempre muda”. Mas a alteração deve ser planejada e, se não for feito com bastante critério, vai gerar problemas sérios para o projeto. Quando a parte de gerência de escopo for abordada mais a fundo, vou expor algumas técnicas para minimizar problemas e conduzir as mudanças da melhor forma.

Para planejarmos bem um projeto, seja na definição do trabalho a ser executado ou na mudança de uma atividade já definida, precisamos levar em consideração, no mínimo, três importantes visões do gerenciamento de projetos: custo, tempo e escopo.

No próximo artigo, vamos falar a respeito dessas visões e como a alteração em uma delas pode afetar as outras duas. Vamos falar também de como a cultura organizacional pode influenciar no gerenciamento de projetos de uma empresa.

Um abraço e até lá!
* Stakeholders: partes interessadas no projeto. Será melhor explicado no gerenciamento de escopo.
Fonte: PMI ®
 

Meu grande amigo, e excelente profissional, Bruno Freitas aceitou meu convite e será mais um colaborador do Reflexões Digitais. Partindo do background profissional do Bruno sempre pensei que a melhor contribuição que ele poderia dar ao blog seria escrever sobre gerência de projetos. Dito e feito, ele também achou a idéia excelente, ainda mais agora que está fazendo sua pós-graduação nessa área.

Sua colaboração será semanal, sempre trazendo dicas, cases e diversas informações dessa área. Creio que no mercado web todos devemos saber, pelo menos alguma coisa, sobre gerecimento de projeto. Afinal, organizando o trabalho e processos as chances de sucesso sempre são maiores.

Dessa froma , bem vindo ao Bruno e que sua colaboração seja útil e sua pemanencia por aqui longa.

Seu post de estréia sai ainda hoje!