Definição de metas em projetos

Dois filmes que assisti em sequência trouxeram um tema que foi rapidamente comentado em Definição de Responsabilidades - a meta.

Os filmes O Livro de Eli e A Estrada apresentam um mundo pós apocalíptico, onde a sobrevivência é uma luta diária dos protagonistas. Em meio ao caos absoluto, Denzel Washington caminha rumo ao Oeste, levando consigo um cobiçado livro - a Bíblia. Para ele, essa travessia épica só terminará quando o livro for entregue a um merecedor, para disseminar os ensinamentos.

Viggo Mortensen e Charlize Theron formam um casal em A Estrada. Essa película mostra de maneira bastante convincente a diferença entre alguém que tenha uma meta e aquele que já perdeu suas esperanças. Mortensen permanece focado e determinado, lutando contra seja-lá-quem-for para manter vivo seu filho. Um contraponto a outros que ficam pelo caminho, sem motivação para continuar.

O desafio desse post é manter a ideia do tema sem entregar os filmes. Instigar ao leitor a vontade de assisti-los, mesmo que não sejam nenhuma obra prima.

Eli, em uma passagem do filme me fez recordar do treinamento que tive com Alexandre Magno em Scrum. Um dos exercícios realizados por Magno ocorre dentro da sala de aula, onde uma bola é colocada sobre a mesa do professor. Os participantes divididos em equipes devem propor o menor número de passos para que cada um chegue a meta: pegar a bola. A equipe vencedora deve comprovar a proposta executando o caminho até alcançar a meta. Em um determinado momento a bola é retirada pelo Alexandre sem que ninguém perceba o seu movimento. A equipe continua a execução dos passos e só nota que não alcançou a meta já com a tarefa concluída.

Perseguir uma meta não implica em não acompanhá-la e reavaliá-la no decorrer da atividade. Ao contrário, devemos mensurar frequentemente se estamos no caminho correto, se a meta se mantém inalterada ou se podemos fazer outro caminho de menor custo para atingi-la de maneira mais eficaz. Essa reavaliação da meta é realizada por Eli, mesmo com a meta comprometida, o protagonista reavalia as ações para que a meta seja finalmente alcançada.

Essa meta, trabalhada com maior clareza em metodologias ágeis como o Scrum, é a força motriz das equipes, que iniciam um trabalho sabendo claramente o que deve fazer e até onde devem chegar. Sem esquecer de manter os olhos na atividade e na meta, conforme exemplo supracitado.

Um claro exemplo de metas bem definidas é apresentado no livro A cabeça de Steve Jobs, de Leander Kahney. O autor comenta que diversos produtos são mantidos em absoluto segredo. A maioria dos lançamentos são novidades também para grande parte da Apple. Mas como isso funciona? Como alguém consegue desenvolver sua tarefa de criar a interface gráfica do IPhone sem conhecer todo o projeto? A resposta está na ótima definição de meta utilizada pela empresa.

Defina metas que estejam alinhadas ao projeto ou a seus objetivos pessoais e se torne mais eficaz profissional e pessoalmente.

Abraço.

Referências:

KAHNEY, L. A cabeça de Steve Jobs.

HILLCOAT, J. A Estrada. Filme com Viggo Mortensen e Charlize Theron.

HUGHES, Brothes. O Livro de Eli. Filme com Denzel Washington e Gary Oldman.

Caia na real - ensaio sobre o escopo do projeto

Vamos nos colocar no papel de clientes. Estou prestes a fechar um contrato para desenvolvimento de um produto e quero garantir o escopo. Minha obsessão pelo escopo é diretamente proporcional à expectativa da entrega e alcance da meta. Meu nome está em jogo, e caso um usuário lá da Índia sentir falta de alguma funcionalidade, levarei a culpa.

Do outro lado, eu como fornecedor não questiono o tamanho do escopo, pois este se transforma em horas, que posteriormente materializa-se em dinheiro. O que não consigo ver, como fornecedor, é o quanto de esforço da minha equipe é desperdiçado com questões menores.

Analisando rapidamente o gráfico abaixo é possível notar que quase a metade do que está no escopo nunca, isso mesmo, nunca será utilizado. Na outra ponta temos somente 14% do que foi implementado é vital para os objetivos do sistema.

Média de uso de funcionalidades de sistemas
Fonte: Standish Group (2002)

Temos que acordar! Desconstruir esse paradigma do relacionamento cliente/fornecedor. Duas questões que estão bastante na moda e que realmente tem grande importância em qualquer projeto inteligente são o ROI (return on investment) e o alinhamento estratégico.

Todos os requisitos para a construção de um produto devem trazer algum retorno do investimento, ou seja, cada hora de desenvolvimento do projeto é custo para o cliente, correto? Alinhado com o momento de crise, por que adicionar escopo que não trará retorno considerável? Para que aumentar o escopo com a justificativa de se resguardar? Vale a pena aumentar o valor final do projeto?

E se eu, como cliente, garantisse que o escopo está alinhado com o planejamento estratégico da empresa? Esse não seria um grande argumento para engavetar projetos que não foram previstos no planejamento? O aumento do escopo de um projeto está casado com o plano da instituição? Se sim, ótimo. Mas na maioria dos casos não está.

Nesse momento devemos considerar os resultados dos projetos. Segundo o Standish Group somente 32% dos projetos são entregues com sucesso. O percentual de fracasso de projetos chega a 24%, enquanto 44% dos projetos são desafiados, ou seja, tem custo, tempo ou escopo fora do planejado.

Qual a explicação para os números apontados no gráfico acima? Absurdos 64% das funcionalidades de um sistema são raramente ou nunca utilizadas. Tem algo muito errado. Concorda?

A mudança deve partir dos dois lados. O cliente deve solicitar apenas o que interessa, enquanto o fornecedor deve cumprir a tripla restrição. Sonho? Talvez não.

O objetivo desse post não é apresentar uma solução ideal, mas trazer uma visão otimista para esse cenário.

A redução do escopo ao nível do essencial traria um benefício ao cliente, onde ele teria o produto em mãos com tempo e custo reduzidos.

O fornecedor teria um giro maior entre os projetos. Projetos com anos de duração seriam exclusividade da Petrobrás. O dinheiro entra enquanto o portfólio cresce e a empresa alcança mais presença e notoriedade.

Ideias revolucionárias como as do pessoal da 37signals devem ser disseminadas, adaptadas e recriadas. Os autores do livro Rework e do que podemos chamar de manifesto ousado para desenvolvimento de sistemas - Caindo na Real, assumem que fazem menos que os concorrentes e incorporam literalmente a ideia do "menos é mais".

Estude o novo. Abra a cabeça. Troque hipoteticamente de papel (cliente/fornecedor) com frequência. Caia na real.

Referências:

FRIED, J. HANSSON, H. Rework - Change the way you work forever. Vermilion, 2010.

37signals. Caindo na real. Disponível na Internet em http://gettingreal.37signals.com/GR_por.php. Acessado em 2010.

Escopo Negativo

Você já se deparou com uma solicitação inusitada, de grande impacto ao projeto, mas que não estava prevista no projeto? Você até conhecia os riscos dessa solicitação vir a ser levantada em algum momento, mas preferiu tratá-la de maneira informal.

Muitos autores defendem que grande parte dos problemas em um projeto é devido à má definição do escopo. Investimos boa parte do tempo criando as especificações para definir e gerenciar o escopo. No entanto, basta uma única solicitação para colocar todo esse trabalho em risco.

Como justificar que a alteração de escopo não será desenvolvida? O documento de Declaração de Escopo (download do modelo), no tópico Limites do Projeto, auxilia a evitar que demandas fora do escopo possam comprometer a saúde do projeto e ao mesmo tempo exige que as partes envolvidas entrem em comum acordo na fase de desenvolvimento.

O Limite do Projeto ou Escopo Negativo define funcionalidades relacionadas ao sistema, mas que não serão desenvolvidas. É interessante agregar uma justificativa para o não atendimento desse requisito. Também denominado Não-Escopo ou Exclusões Específicas, esse tópico se tornou importante em um projeto que participei como gerente.

Durante as conversas pré-projeto muita informação importante pode ser levantada. A primeira delas é a necessidade do desenvolvimento de uma nova versão para uma ferramenta já existente. Como seria um novo desenvolvimento foi levantada a necessidade de migração dos dados.

Quem trabalhou com a transposição de dados entre sistemas conhece o quanto é problemático projetos que envolvam migrações entre versões inteiramente diferentes, com impacto grande no fator tempo. Tendo como empecilho o prazo curto, foi realizado um trabalho para levantamento da real necessidade dessa etapa no projeto e chegou-se a conclusão de que a não migração dos dados não inviabilizaria o projeto. Aqui fica a dica: conheça as necessidades do seu cliente para que o esforço da equipe não seja direcionado para requisitos descartáveis.

Como todo projeto, algumas decisões são tomadas depois do escopo fechado. E qual foi a minha surpresa em ver como assunto de uma reunião posterior ao fechamento do documento de Declaração de Escopo, um tema já debatido e acertado entre os envolvidos - a migração dos dados.

Foi graças ao documento de Declaração de Escopo, mais especificamente o tópico Escopo Negativo que garantiu a manutenção dos prazos e continuidade do projeto. 

Meu objetivo com esse post é chamar a atenção para o tamanho do auxílio que esse pequeno item da Declaração de Escopo pode proporcionar. Portanto, da próxima vez que você for determinar o escopo do projeto, não esqueça de fechá-lo definindo quais os seus limites. É imprescindível descrever formalmente até onde vão os requisitos e deixar claro para o cliente o que está dentro e o que está fora.

Abraço.

Referência:

Imagem: Diego de Los Campos: desenhos: Dsc04013. Disponível na Internet em: http://deloscampos.multiply.com/photos/photo/87/13

Definição de responsabilidades

Um dos grandes vilões em projetos, ditos por muitos como a principal causa de fracassos é a comunicação. Assim, utilizo das palavras de Saramago, que exemplifica melhor do que eu em seu livro Caim, os problemas de comunicação:

"Ao contrário do que geralmente se pensa, o burro é um grande conversador, basta reparar nas diversas maneiras que tem de zurrar e resfolgar e na variedade de movimentos das orelhas, nem todas as pessoas que montam jumentos conhecem a linguagem deles, daí que acontecem situações aparentemente inexplicáveis como postar-se o animal no meio do caminho, imóvel, e dali não sair nem que o moam à pancada. Diz-se então que o asno é teimoso como um burro quando afinal do que se trata é de um problema de comunicação, como tantas vezes sucede até entre os humanos." 

Dentro de uma comunicação de qualidade é importante que sejam definidos: metas, funções, responsabilidades e atividades para cada um dos componentes da equipe. Classifico como problema de comunicação pois assumo que seria impossível iniciar um projeto sem que o Gerente não os tenha previamente definido.

Parece simples e claro definir as tarefas dos membros da equipe. Talvez por esse motivo seja frequentemente negligenciada. Não é raro a equipe se perguntar de quem é a responsabilidade por uma tarefa. Quem deveria resolver determinado problema? Qual será minha participação? Como eu contribuo para o projeto? Essas são perguntas que cada membro da equipe deve responder com facilidade, caso contrário, você tem um problema que deve ser rapidamente corrigido.

Definir a Meta

O primeiro passo é a definição da meta. Seja a meta do projeto ou a meta da iteração/sprint, não importa. Os componentes devem visualizar para onde estão indo e concentrar-se nesse objetivo.

Definir Funções

Todos devem ser informados sobre suas funções no projeto. Qual a função que o indivíduo exercerá no projeto, dentro de suas aptidões e interesse? Apresente as posições de cada um, pois um time não vence com 11 atacantes. Parece bobo, e é.

Denomino como função, o cargo que o colaborador vai exercer no projeto. O Gerente deve "distribuir as camisetas" sempre de acordo com as aptidões e interesses dos liderados. Dessa forma, deve definir quem será membro da equipe de execução, coordenador, analista, consultor, por exemplo.

Definir Responsabilidades

Responsabilidades são ações mais gerais que normalmente se encontram até um penúltimo nível da WBS* (Work Breakdown Structure), Figura 1.

 Figura 1 - EAP

A partir de uma matriz são definidas as responsabilidades de forma geral e são formalizadas as ações de coordenação, aprovação, apoio, execução, por exemplo. Esse documento é denominado Matriz de Responsabilidade e pode associar responsabilidade aos componentes do time ou área da organização.

Clique aqui e baixe um modelo de Matriz de Responsabilidade. 

Definir Atividades

Todos os componentes da equipe devem ser comunicados sobre qual é seu papel dentro do time. Devem conhecer suas atividades e como podem contribuir para atingir a meta. As atividades nascem a partir da quebra dos pacotes de trabalho da WBS, gerando o cronograma do projeto.

Regras do Jogo

O líder continua sua tarefa em montar a equipe, agora, comunicando o que ele espera de cada um componente. É uma conversa clara e direta, onde ele deve mostrar as regras do jogo tanto de forma individual quanto coletiva. É o nascimento de um grupo que em breve deve tornar-se uma equipe.

Sempre defina e comunique a meta, as funções, as responsabilidades, as atividades e as regras do jogo, mesmo que não utilize ferramentas gerenciais como a WBS.

Por fim, dentro da proposta do simples, claro e direto, formule documentos que o auxilie, que sejam práticos e fáceis de acessar, ler e gerenciar. Faça o gerenciamento agir ao seu favor, ou seja, não crie uma documentação pesada com informações desnecessárias. Seu tempo deve ser dedicado ao estratégico e ao que trouxer maior retorno.

Abraço.

* WBS ou EAP (Estrutura Analítica do Projeto) é uma ferramenta de gerenciamento do escopo do projeto. Cada nível descendente da EAP representa um aumento do detalhamento. Ouça aqui o podcast do Ricardo Vargas sobre EAP.

Equipes maiores = melhor produtividade?

Um dos pontos de alavancagem de projetos é a relação entre o aumento da equipe e o crescimento da produtividade, sugerido por MEADOWS. Parece um tanto lógico que isso aconteça. No entanto, se pensarmos de uma maneira menos simplista para os famosos cenários apresentados abaixo, veremos que temos um limite e um novo cenário se apresenta: o que era para alavancar acaba prejudicando a produtividade.

"Uma mulher dá a luz em nove meses. Portanto, nove mulheres darão a luz em um mês"

Ou ainda:

"Um pedreiro constrói uma parede em quatro dias. Dois pedreiros as constroem em dois dias. Portanto, cinco mil pedreiros constroem as quatro paredes em 23 segundos"

No primeiro exemplo a limitação é biológica. Já a segunda frase, apresentada por VARGAS, começa bem - é possível diminuir o tempo das quatro paredes em 50% com dois trabalhadores. No entanto é impossível construir 4 paredes em 23 segundos, seja qual for o número de profissionais dedicados.

O comportamento padrão entre os dois fatores Número de Profissionais e Tempo é apresentado no gráfico abaixo:

Temos dois tipos de atividades. Uma que independe do número de componentes que a equipe tenha, denominada Atividades de Duração Fixa (fixed duration). Outra denominada Atividades Orientadas para Recursos (resource driven), que permitem a redução do tempo com o aumento de recursos.

Note no gráfico a existência de um limite para o aumento da produtividade, representado pela área A. Alcançado esse limite, existe uma área de estabilidade, em B, que é logo invertida para um decréscimo de produtividade a medida que sobe o número de componentes da equipe, área C.

Uma das causas para o efeito apresentado no gráfico é a interdependência entre as tarefas. Algumas dessas tarefas são indivisíveis, ou está intimamente ligada a outra(s), impedindo que outro componente da equipe seja responsável. Com isso, podemos propor que no gráfico, da área A até a C, acontece a diminuição das tarefas ditas independentes e o consequente aumento daquelas atividades interrelacionadas.

Contudo, caso a situação obrigue a utilizar melhor os recursos para proporcionar o aumento de produtividade é importante analisar o ponto de inflexão, que pode indicar o aumento de interdependências entre as tarefas acenando para a desmobilização de parte da equipe.

Chegar ao número ideal de time para o projeto é difícil. Alguns autores ágeis defendem equipes entre 5 e 9 componentes. Certamente esse intervalo deve alterar de acordo com as características do projeto, mas sempre que possível, uma grande equipe deve ser segmentada em pequenos times, por alguns motivos, entre eles:

• Comunicação: a redução dos canais de comunicação facilita a disseminação das informações relevantes ao projeto;
• Reuniões: equipes pequenas aumentam a produtividade das reuniões, vide Planejamento de Reuniões;
• Motivação: sensação de time, de trabalho em equipe, devido aos laços criados entre os componentes.

Segundo APPELO seu número de sorte é 5. "Five is my personal 42", afirma o autor. Outra proposta, a Lei de Parkinson, sugere uma equipe menor que 20, mas nunca igual a 8, pois com este número as decisões podem chegar em um impasse. SUTHERLAND defende equipes menores ou iguais a 7.

A definição do número de componentes de um time é um assunto delicado, controverso, cheio de opiniões contraditórias. Analise seu projeto, estude o perfil individual dos profissionais que você tem em mãos, as características da sua instituição e dos clientes e só depois monte sua equipe. É difícil; é uma arte; é empírico.

Abraço.

Referência:

APPELO, J. The Optimal Team Size is Five. Disponível na Internet em http://www.noop.nl/2009/04/the-optimal-team-size-is-five.html. Atualizado em 2009. Acessado em 2010.
HAZRATI, V. SCRUM: Cinco é um Tamanho Ideal para as Equipes?. Disponível na Internet em http://www.infoq.com/br/news/2009/05/agile-optimal-team-size. Atualizado em 2009. Acessado em 2010.
MEADOWS, Donella. Leverage Points - Places to Intervene in a System. Disponível na Internet em: http://www.sustainabilityinstitute.org/pubs/Leverage_Points.pdf. Atualizado em 1999. Acessado em 2010.
SUTHERLAND, J. SCRUM: Keep Team Size Under 7!. Disponível na Internet em http://jeffsutherland.com/2003/02/scrum-keep-team-size-under-7.html. Atualizado em 2003. Acessado em 2010.
VARGAS, R. Gerenciamento de Projetos: Estabelecendo diferencias. 7ed. Brasport.

Eu acredito em Auto-gerenciamento

Apesar de vários autores e pessoas que conheço não acreditarem, eu acredito em auto-gerenciamento porque vivi a autogestão.

É como uma religião, e quem me conhece um pouco sabe que não sou dessas coisas, mas o deslumbramento do novo, do ideal, da fluidez, da eficácia, da pró-atividade, nos incita em disseminar a informação. Queremos que todos sejam convertidos para a igreja do auto-gerenciamento.

Você, leitor, pode se perguntar: Como isso aconteceu na vida dele? E a resposta merece uma pequena história.

Trabalhávamos sem uma metodologia definida, com a sensação constante de desorientação. A desmotivação já abatia boa parte da equipe, que era desacreditada pelas áreas de negócio. Havia um grande controle da gerência onde o micro gerenciamento tomava boa parte do tempo do chefe direto. Até aí parece um grupo qualquer, que poderia estar situado em qualquer empresa do planeta.

Para mudar o cenário desfavorável somente algo de impacto e cuidadosamente avaliado, para evitar uma tragédia maior nos ânimos da equipe e de toda a empresa. 

Após uma análise da metodologia, toda a empresa, com o aval da presidência, abraçou o que seria a arma para reverter o cenário. Nascia a era ágil do Scrum na empresa.

Toda a empresa passou por um treinamento Scrum, desde a área de recursos humanos até as áreas de negócio e logicamente, o desenvolvimento, núcleo que eu fazia parte.

Bom, para encurtar essa história, pouquíssimo tempo depois da implantação do Scrum a equipe estava transformada. O primeiro impacto foi com o Kanban* pendurado em um armário. A ferramenta, que era desacreditada pelos colegas de outras áreas, foi a responsável pelo início da revolução no ambiente. A equipe de desenvolvimento, antes desacreditada por brincadeirinhas do tipo: "não fazem nada", passou a ser vista como eficiente. Isso aconteceu não porque começamos a trabalhar após a metodologia ser implantada, mas pelo fato da informação estar visível para todos na empresa. Isso mudou os ânimos.

Uma competição saudável se iniciou dentro da equipe. Era a busca alucinada pela eliminação daqueles Post-its pendurados na coluna To Do**. Tanto para as áreas de negócio quanto para a própria equipe de desenvolvimento, pela primeira vez o resultado do trabalho estava visível.

Deixou de existir o micro gerenciamento e tornávamos aos poucos independentes, tínhamos autonomia e confiança de todos, naturalmente a motivação da equipe aumentava, as reuniões eram produtivas, encontrávamos o prazer profissional. Esse já não é um cenário tão comum, mas aconteceu. É uma prova que um processo organizado motiva.

Auto-gerenciamento x Maturidade

Como religião, política e futebol geram grandes polêmicas, gostaria de abrir a discussão sobre um assunto controverso na auto gerência: o auto-gerenciamento se aplica somente em equipes com a média maturidade alta?

A equipe da história acima era composta por profissionais júnior e pleno, de maturidades variáveis, mas nenhum dos componentes chegavam a um nível 4 (nível máximo de maturidade, segundo Hersey e Blanchard) individualmente. Mas em equipe mostravam mais. Era o poder da sinergia.

A minha resposta pessoal para a pergunta sobre maturidade e auto-gerenciamento é que não há relação estreita. Podemos sim, ter desempenhos superiores à maturidade individual dos componentes da equipe.  

Por fim, vale a pena ressaltar que essa foi uma experiência pessoal, e que não é uma receita infalível que dará certo em qualquer cenário. Nem que o Scrum seja a solução para os problemas. Mas é certo que a combinação dos fatores estava propícia para o sucesso.

Eu acredito no auto-gerenciamento. E você, acredita?

Abraço.

* Clique aqui e faça o download de uma proposta de quadro Kanban.

** Tarefas para fazer (pendentes).

Lições Aprendidas em Projetos

Você deixa seu carro na mesma vaga em que recebeu multa por estacionamento em local proibido? Dificilmente.

Seu carro bicombustível rende mais com gasolina. Você completa o tanque com álcool? Não, se a gasolina permanecer mais rentável para você, certo?

Tomamos as decisões baseadas em experiências passadas, sejam elas positivas ou negativas. Esse é o mesmo princípio das Lições Aprendidas em projetos.

Define-se Lições Aprendidas como situações não previstas positivas ou negativas que ocorreram durante o ciclo de vida do projeto e que tiveram uma ação para aproveitar a oportunidade apresentada ou corrigir um erro no percurso.

Esse aprendizado auxilia a evitar ou saber qual o caminho tomar no momento da ocorrência do imprevisto e pode ser utilizado tanto no projeto atual quanto em projetos futuros, levando-se em conta as diferenças naturais entre eles. É a melhoria contínua na prática!

O gerenciamento dessas lições deve controlar e monitorar, documentando e disseminando no momento da sua ocorrência. Aqui vai uma dica: não espere o final do projeto para levantar as Lições Aprendidas. Metodologias ágeis oferecem a oportunidade periódica para discutir as Lições Aprendidas nas reuniões de Retrospectiva que acontecem de duas a quatro semanas. Nessa reunião as lições são coletadas, resolvidas e disseminadas através de perguntas simples: O que foi bom na última Sprint? O que deve ser melhorado para próxima? Em projetos tradicionais, essa reunião pode ser realizada ao final de cada etapa ou fase do ciclo de vida.

A forma que será armazenado ou quais informações compõem a lição aprendida depende de cada organização. Você pode criar o formato mais adequado para sua realidade. As lições podem ser armazenadas em planilhas, documentos de texto, mapas mentais ou sistemas próprios. Contudo, uma boa lição aprendida deve ter as seguintes características:

• Simples: deve possuir uma linguagem simples, clara e direta, ou seja, deve ser compreensível a todos;
• Rastreável: montar uma estrutura que permita o gerenciamento e acesso fácil às informações;
• Relevante: somente informações e lições importantes devem ser documentadas. Devemos evitar documentos grandes para estimular a leitura de todos os envolvidos;
• Contextualizada: a informação deve ter um cenário para que seja possível entender o contexto.

Exitem diferentes formas para a construção do documento, sugiro alguns campos que podem contar na sua documentação de Lições Aprendidas (clique aqui para fazer o download do modelo):

• Atividade: breve descritivo sobre a lição, entre 5 e 7 palavras;
• Tipo: classificados como Oportunidade, quando pode trazer uma influência positiva ao projeto; Ameaça, quando a influência é negativa;
• Situação: é o status da lição. Quando ações corretivas ainda estão sendo aplicadas rotula-se a situação como Aberto. Fechado é quando a lição já ocorreu e foi finalizada;
• Lição aprendida: texto que explica em detalhes, preocupando-se em aprensentar o cenário e o contexto;
• Ação preventiva: quais as ações que podem ser realizadas para prevenir a ocorrência de uma influência negativa;
• Ação corretiva: em caso de ocorrência, quais as ações podem ser tomadas para minimizar a influência negativa ao projeto;
• Prioridade: auxilia na criação de um plano de ação e a definição dos itens que devem ser trabalhados em ordem de importância. As colunas Tipo e Impacto podem ajudar a definir as prioridades;
• Impacto: classificação de impacto sobre o cliente e o negócio. Poderemos ter Alto, Médio, Baixo ou Nenhum impacto sobre clientes e negócio;
• Área afetada: áreas afetadas pela ocorrência de um contratempo no projeto. É um campo bastante particular e deve refletir a realidade da empresa;
• Recorrência: classifica a possibilidade de ocorrência da lição em outros projetos;
• Responsável: profissional indicado para tirar dúvidas e auxiliar nas ações para tratar uma lição em outros projetos.

Aprender e se adaptar rapidamente são características exigidas pelo mercado atual, e as Lições Aprendidas podem auxiliar muito a otimizar as respostas frente um contratempo de projeto.

Abraço.

Referência:

Imagem: Diego de Los Campos: unumeno boristefa: verde09. Disponível na Internet em: http://deloscampos.multiply.com/photos/album/30/unumeno_boristefa#photo=17.jpg

VARGAS, Ricardo. Lições aprendidas. Disponível na Internet em: http://www.ricardo-vargas.com/pt/podcasts/lessonslearned/. Atualizado em 2009. Acessado: 2009.

Pressa x Velocidade

Já se tornou comum ouvir fazer uma pergunta despretensiosa do tipo "Como está?" e receber a resposta, em movimento, pois não há tempo, "Tá corrido!".

Seja dentro do seu convívio profissional ou fora dele, a grande maioria está passando pela mesma situação, onde a pressão por resultados distorce a visão do que é pressa e o que é velocidade e quais suas consequências para o indivíduo, para o projeto, para a instituição, ou seja, para todos os envolvidos.

A velocidade é um quesito bastante discutido no mundo ágil, que mede o poder para entrega de uma equipe em pontos, e toda a sequência de atividades leva em conta essa taxa. O quanto posso assumir de responsabilidade para as próximas semanas? Consulte a velocidade da equipe. Qual a próxima release do projeto? Mesma resposta anterior.

Note que existe uma grande diferença entre a velocidade calculada e a pressão desmedida.

É com base nesse tema que pensei e discuti com outras pessoas quais as causas dessa pressa disfarçada de velocidade. Quais são as consequências dessa naturalidade de uma situação negativa e pretensiosamente quais seriam as ações para evitar esse quadro?

INT. ESCRITÓRIO, ÁREA DO CAFÉ - MANHÃ

Ferris Bueller avista da sua mesa Patrick Bateman apanhando COPOS descartáveis para a primeira dose de cafeína matinal.
Ferris levanta-se e vai ao encontro do colega de trabalho levando o STATUS REPORT de um projeto.

FERRIS

Manuseia as folhas de papel do RELATÓRIO.

   Tudo certo para entregar as camisetas até o final da semana?

PATRICK

Nervoso, coloca o COPO de café que queima sua MÃO sobre o BALCÃO de granito.

   Como assim? A entrega vai acontecer dentro do cronograma, ou seja, em 15 dias.

FERRIS

   Não pode! O evento foi antecipado pelos patrocinadores. Vai acontecer sábado.
Ferris desvia o olhar enquanto caminha em direção ao bebedouro.

Você leitor, nunca passou por uma mudança de planos no seu projeto? Este é o primeiro item da lista de causas para a pressa. No caso acima, a mudança de planos partiu do cliente, que por algum motivo alterou a data do evento, antecipando todas as entregas necessárias. Primeiro é inevitável intervir no livre arbítrio do cliente, seja ele interno ou externo, mas nesse caso é necessário se resguardar de contratempos. Um contrato bem descrito delimitando o escopo e o não escopo, bem como as restrições de projetos e datas poderiam ajudar a garantir a tranquilidade e qualidade da entrega.

Para essas situações, a capacidade de negociação de um Gerente de Projetos é bem vinda. Escopo e Preço são quesitos a serem discutidos entre cliente e fornecedor, uma vez que o item Prazo, neste caso não é negociável.

Contudo, gostaria de chamar a atenção para uma questão que deve ficar clara: o impacto na pressa no quesito Qualidade. É válido um fornecedor comprometer sua imagem entregando um produto de baixa qualidade para satisfazer mudanças de planos?

EXT. PRAÇA XV DE NOVEMBRO, CENTRO DE FLORIPA - TARDE

Walter Sochalk e Juno MacGuff caminham em direção ao escritório.

WALTER

   Como está o andamento do relatório que te pedi hoje pela manhã?

JUNO

Olhando séria para o seu chefe, rebate.
   Estava finalizando todos os relatórios previstos para a semana. As compras já foram realizadas e o cliente pediu a você esse relatório há duas semanas atrás. Se atrasarmos mais uma semana perderemos a conta.
Suspira, e lembra da hierarquia.
   Ok, qual dos projetos devo me dedicar?

WALTER

   Os dois!

Trabalho paralelo é uma atividade muito questionável, mas que perdura nas organizações, na falsa ideia de que serão entregues mais produtos. Com o objetivo de paralelizar os projetos, permitindo à equipe o foco necessário para uma entrega ágil e de qualidade, o Gerente de Projetos deve renegociar os prazos com os clientes, tendo como base de negociação o ROI de cada um dos projetos e seguir o Planejamento Estratégico da sua empresa.

INT. SALA DE REUNIÕES - INÍCIO DA TARDE

Frank Drebin reune sua equipe para expor uma nova situação do projeto. Na reunião está presente o funcionário falastrão Daniel Plainview.

FRANK

Folheando um E-MAIL do cliente impresso recebido antes do almoço.
   Pessoal, convoquei essa reunião para mostrar a vocês uma nova ideia do cliente. Essa funcionalidade deve estar presente na nossa próxima entrega.

DANIEL

Inquieto na CADEIRA confortável da sala, questiona.
   Frank, o prazo é curto, estamos no meio da Sprint, cabe inserir uma nova funcionalidade nessa altura do campeonato? Pela regra a Sprint deveria ser cancelada!

FRANK

   Daniel, devemos fazer o nosso melhor para atender o principal cliente da empresa.

A grande parte dos problemas dos projetos consiste na definição do escopo. Um escopo mal definido certamente trará problemas semelhantes a situação supracitada. Para tentar minimizar esse tipo de problema, o projeto deve ter um documento de Definição Formal do Escopo, que deve estar de acordo entre todos os envolvidos.

A participação de componentes experientes, um analista de sistemas sênior, para a coleta de requisitos também é um fator importante. No entanto, em uma situação de mudança, que deve ser recebida, cabe mais uma vez a negociação do que é escopo do projeto e reavaliar as próximas entregas - o que sai para a nova demanda entrar. E uma dica: estamos dispostos a ajudar o cliente, mas não podemos quebrar nosso fluxo de trabalho para adequar a um problema de escopo, inserir itens no meio de uma Sprint, por exemplo (Scrum).

Outras causas que acredito ser próprias para apressar o projeto:

A insegurança de um componente da equipe. Insegurança pela sua situação na empresa, a garantia de emprego, fusões, novos desafios ou novo cargo, são situações que ajudam na pressa desse indivíduo. Cabe ao Gerente, Scrum Master, Coordenador da equipe, ou seja lá quem estiver no comando ter a sensibilidade de observar indicativos de que isso esteja acontecendo e tratá-la de imediato. Investir nesse funcionário, apresentar a realidade da situação, dar o feedback frequentemente pode auxiliar a evitar a insegurança.

Problema técnico de um dos envolvidos na equipe de produção. Primeiro é importante ter esses indicadores de qualidade e produtividade, justamente para tratar essas situações. Acredito que para esses casos, o responsável pela equipe deve seguir uma ordem de ações: dar mais tempo para a execução das tarefas; ser o coaching desse indivíduo; proporcionar o treinamento no ponto fraco; planejar a realocação para uma área de maior afinidade; por fim, mas somente em últimos casos, analisar a demissão desse elemento. O problema técnico traz invariavelmente muito retrabalho e o acúmulo de novas tarefas, com isso, quem paga o preço é a qualidade das entregas.

Os prazos impossíveis não devem ser aceitos. Primar pela qualidade das entregas e a maneira que a empresa é conceituada no mercado são pontos primordiais suficientes para não aceitar em hipótese alguma uma entrega impossível. A VocêSA de Março de 2010 mostra uma empresa - IMI - Instituto de Marketing Industrial, que aceita somente seis grandes cliente por ano. Imagine o motivo que leva uma grande empresa de consultoria em gestão colocar como regra uma limitação no número de cliente por ano. Essa é uma postura fantástica frente o mercado capitalista. É uma atitude quase surreal, concorda? Mas muito provavelmente essa empresa tem como objetivo final a qualidade. Nossos avós estavam certos quando recitavam que "a pressa é inimiga da perfeição". Outras alternativas para não ser pego de surpresa é promover o recebimento de projetos de forma organizada e antecipada ou mesmo antever sazonalidades que provoquem um crescimento nas demandas.

Um prejuízo tão grande que um prazo impossível imposto pelo cliente é um prazo mal mensurado pela equipe. Como em muitas oportunidades o acordo já foi firmado, a equipe absorve o erro e cria um ambiente pouco propício para a criatividade e o bom andamento dos trabalhos. E eis que começa a correria! Para esses casos, capacitar a equipe, ter a ajuda de um colaborador com experiência e realizar uma reunião de brainstorm sobre o projeto podem ajudar no cálculo mais acertado de prazo.

Após toda a reflexão e algumas ideias sobre o culto a pressa, algumas coisas devem ficar como perguntas para um momento de correria em seu projeto:

• Estou ciente que essa urgência poderá acarretar problemas de qualidade nas entregas?
• Estou disposto a colocar em jogo a imagem da empresa para atender essa demanda?
• Minha equipe responderá positivamente a essa pressão inesperada?
• Terei capacidade de prover aos meus funcionários um ambiente confortável e que permita o bom relacionamento e a criatividade mesmo no atendimento de uma urgência?

E lembre-se que dizer não também é sinal de profissionalismo.

Abraços.

Referências:

CORREA, F. (Março 2010). O mal do culto à urgência. VOCÊSA.

Nomes dos personagens inspirados em filmes:

Daniel Plainview (Daniel Day-Lewis - Sangue Negro)
Ferris Bueller (Matthew Broderick - Curtindo a vida adoidado)
Frank Drebin (Leslie Nielsen – Corra Que a Polícia Vem Aí!)
Juno MacGuff (Ellen Page – Juno)

Planejamento de Reuniões

Tenho um amigo que adora reuniões, apesar de comentar comigo que as vezes são improdutivas ou longas demais. A sensação depois de um dia inteiro de reuniões pode ser de frustração ou a impressão de que não produziu o que poderia ter produzido.

Para evitar o mau uso do tempo é preciso em primeiro lugar identificar a necessidade da reunião. Caso a reunião seja inevitável passamos para o seu planejamento.

O planejamento de uma reunião deve prever os seguintes quesitos: objetivo, resultado, tempo, participantes, agenda e infra-estrutura.

Caso você seja o facilitador da reunião, o primeiro item que precisa ser definido é o objetivo da reunião. Esse quesito é fácil e importante para que os participantes se preparem para o tema que será discutido.

Em seguida, preciso antecipar o resultado da reunião. Qual é a minha meta para essa reunião? Ao final da reunião a meta deve ter sido alcançada.

A definição do tempo é primordial para dar foco, manter o objetivo e a agenda da reunião, além de evitar que a reunião se alongue indefinidamente, comprometendo o planejamento diário. O ideal para uma reunião é uma duração entre 45 e 60 minutos.

Devido ao tempo e dependendo do tema, será necessário estudar bem a lista de participantes da reunião. Logicamente o número de pessoas pode comprometer o tempo e até mesmo a qualidade da reunião. "O excesso de gente impede de ver as pessoas" - Mário Quintana tinha razão, no nosso contexto o excesso tira o foco das peças importantes para a resolução do problema e que mereceriam maior atenção. Autores afirmam que o número ideal é de 6 participantes.

Durante a reunião, uma informação que ajudará a manter o ritmo e garantir o atendimento do resultado é a agenda da reunião. Você define o cronograma de informações a serem discutidas, e pode até atribuir o tempo de discussão para cada item, a fim de manter o bom andamento da reunião.

Por fim, garanta que a estrutura esteja disponível para a reunião. O levantamento das necessidades de infra-estrutura e verificação antes do início da reunião evita contratempos de última hora.

Espero que essas dicas simples possam ajudá-lo a tornar sua reunião mais produtiva.

Abraço.

Recuperação do Projeto Problema

Projeto Problema é quando temos uma diferença que ultrapassa os limites aceitáveis entre o que foi planejado e a situação atual.

Assim, identificado o problema, uma análise de viabilidade aponta para dois caminhos: término ou continuidade do projeto. Este será o tema abordado nesse post.

Optando-se por continuar o projeto o primeiro passo é tirar o estigma de projeto problema e transformá-lo em um projeto de sucesso. Fácil? Nunca é fácil! Tirar um projeto do caminho para o fracasso e trazê-lo de volta aos trilhos é um processo bastante desgastante para todos os interessados, principalmente para a equipe e Gerente de Projetos.

Um re-planejamento é obrigatório, uma vez que não será possível manter o plano original na expectativa de alcançar a meta. Será necessária uma intervenção diferenciada para esse tipo de projeto, onde é necessário reavaliar a tripla restrição: Custo, Prazo e Escopo.

Lamentavelmente, ao menos um dos itens da tripla restrição irá pagar a conta para recuperação do projeto. Cabe entender o que é mais importante para o cliente dentro da tripla restrição.

Nesse momento, o Gerente de Projetos deve negociar junto ao Patrocinador e os envolvidos o plano de recuperação que utiliza umas das seguintes alternativas ou variações das mesmas:

1. Manutenção do Escopo com variação do Custo e do Prazo;
2. Manutenção do Custo com variação do Prazo e do Escopo;
3. Manutenção do Prazo com variação do Escopo e do Custo;
4. Variação do Escopo, Custo e Prazo.

Como nota, a quarta edição do PMBOK trata de forma diferente as restrições. As restrições do guia para a nova versão são: Escopo, Qualidade, Cronograma (antigo Prazo), Orçamento (antigo Custo), Recursos e Risco.

Um breve comentário pessoal sobre a alteração do PMBOK: a análise da tripla restrição é propícia em momentos de readequação do planejamento, para corrigir o andamento de um projeto. Não vejo a negociação dos riscos junto ao cliente. Pense na redução da qualidade de um projeto? É possível? Quais seriam os impactos dessa decisão para o projeto?

As seis restrições são requisitos gerenciáveis no projeto, onde devem estar focadas as atenções do Gerente de Projeto, assim como as áreas de conhecimento.

Outras técnicas para estimular o projeto, segundo MEADOWS, em ordem de eficácia:

12. Manipulação de parâmetros, números ou constantes: o acréscimo no número de programadores para aumentar a velocidade de desenvolvimento é um exemplo. Apesar de não alterar o sistema, é utilizado, por vezes de forma eficiente, para otimizar o andamento do projeto.

11. Tamanho do buffer: buffer ou inventário consiste em requisitos não implementados, ou parcialmente desenvolvidos, e deixam o projeto pesado, aumentam a complexidade e dificultam atualização e manutenção do sistema.

10. Fluxo e estrutura de estoques: de acordo com MEADOWS, esse item desfila entre os de menor impacto não pela sua eficácia, mas sim pela dificuldade e custo de implementação, sempre associada a uma profunda mudança no processo. VALE comenta sobre a adoção de práticas ágeis, que proporcionam a mudança bastante satisfatória nesse sentido, como a utilização do kanban para acompanhar o fluxo do inventário.

9. Tempos de resposta às mudanças: em geral, os tempos de resposta são difíceis de atuar, segundo MEADOWS, "as coisas levam o tempo que elas levam", mas se identificado um processo que pode ser otimizado, todo sistema terá grandes mudanças. É a historinha da Teoria das Restrições do Goldratt no livro A Meta.

8. A força dos ciclos de feedback negativo: daqui para diante os pontos de alavancagem deixam de tratar questões ditas físicas para tratar as questões de informação e controle. A força do feedback negativo é composto de monitoramento, controle e ações de correção. Inúmeras técnicas podem ser aplicadas para proporcionar o feedback negativo, afim de estabilizar o projeto que saiu do seu fluxo normal. O Scrum utiliza reuniões para acompanhar e traçar ações - diárias, de review e de retrospectiva.

7. O ganho em torno de condução ciclos de feedbacks positivos: são ciclos de auto-reforço que tem como essência ser a fonte de crescimento do processo. Segundo VALE, "é a potencialização do aparecimento de um determinado evento pelo simples fato de ele existir". Esse evento pode ser bom ou ruim. Como exemplo de um evento ruim, posso citar o desenvolvimento de sistemas com muito erros, e quanto mais problemas um sistema possuir, maior o tempo dedicado para correção, dificultando a manutenção e reduzindo o tempo para aumentar a qualidade da implementação. Utilizar-se de um evento, seja ele negativo ou positivo, é outro ponto de alavancagem.

6. Estrutura do fluxo de informações: consiste em proporcionar a fluidez das informações dentro da equipe de projeto e todos os envolvidos. Proporcionar clareza nos processos e principalmente difundir as informações, pois todo o conceito sobre esse ponto de alavancagem consiste na comunicação. As práticas ágeis promovem a comunicação como elemento norteador das ações, começando pelo próprio kanban. No entanto, a comunicação não é exclusividade ágil. O PMBOK trata como uma das áreas dentro do Gerenciamento da Comunicação.

5. Regras do sistema: consiste no escopo do projeto. Segundo MEADOWS, "se você quer entender profundamente um mau funcionamento do sistema, atente para as regras e quem detém o poder sobre elas".

4. O poder da auto-organização: a habilidade para se auto-organizar frente às alterações no ambiente. Consiste na mais poderosa forma de resiliência. Um sistema auto-organizável, também denominado auto-gerenciável, é um fluxo consciente que não só busca o atendimento das metas, mas também está preparado para atuar proativamente de forma a corrigir o caminho sem a necessidade de intervenção superior. Muitos discorrem negativamente sobre essa ideia. Particularmente acredito em uma equipe auto-gerenciável, pois já fiz parte dessa equipe, e considero, apesar do senso comum afirmar o oposto, que não há relação direta com a maturidade da equipe. A liderança e o coach nesse assunto são essenciais.

3. As metas do sistema: as definições de metas claras e alcançáveis norteiam a equipe de desenvolvimento assim como auxilia os envolvidos no momento de sua validação. O Scrum utiliza bem esse ponto de alavancagem, onde cada Sprint recebe uma meta, que deve ser perseguida pela equipe e posteriormente validada na reunião de review pelos stakeholders.

2. Paradigmas: paradigmas são pré-conceitos. A proposta desse ponto de alavancagem é justamente desafiá-las. A mudança pode acontecer de diversas formas - dentro do modelo de gestão, metodologia de desenvolvimento, arquitetura, testes, ou seja, em qualquer área do processo. Fiz parte de uma equipe que abraçou uma nova metodologia, o Scrum. Essa mudança de paradigma alterou desde a motivação da equipe até o nosso conceito junto aos clientes. O potencial da mudança de paradigma é gigantesco, mas só não é maior do que o próximo item.

1. Transcendência de paradigmas: mais do que desafiá-lo, esse ponto de alavancagem nos abre uma nova perspectiva - a de não abraçar nenhum paradigma. Evitar o fanatismo, reconhecer que não há verdade absoluta e que processos melhores e mais eficazes podem surgir da união de duas propostas ditas antagônicas ou até mesmo da proposição de uma terceira via totalmente nova e revolucionária. O cruzamento entre a agilidade e o formalismo é um exemplo disso, no qual defendo no meu primeiro post (http://tinyurl.com/yjuvbrs).

O assunto Projetos Problemáticos é imenso, cabe uma boa leitura nas referências apontadas abaixo. Um próximo post poderia ser perfeitamente sobre Lições Aprendidas, tema que caberia perfeitamente na sequencia dessa trilogia que virou seriado.

Abraços

Referências

ESI International. The rapid assessment and recovery of troubled projects. Disponível na Internet em http://www.projectsmart.co.uk/docs/rapid-assessment-and-recovery-of-troubled-projects.pdf. Atualizado em 2007. Acessado em 2010.

VARGAS, Ricardo. Identificando e recuperando projetos problemáticos: como resgatar seu projeto do fracasso. Disponível na Internet em:http://www.ricardo-vargas.com/wp-content/uploads/downloads/ricardo_vargas_identifying_recovering_troubled_projects_pt.pdf. Atualizado em 2006. Acessado em 2010.

MEADOWS, Donella. Leverage Points - Places to Intervene in a System. Disponível na Internet em: http://www.sustainabilityinstitute.org/pubs/Leverage_Points.pdf. Atualizado em 1999. Acessado em 2010.

VALE, Alisson. Projetos Ágeis e os 12 Pontos de Alavancagem Sistêmica. Disponível na Internet em: http://www.alissonvale.com/englishblog/post/Projetos-Ageis-e-os-12-Pontos-de-Alavancagem-Sistemica.aspx. Atualizado em 2008. Acessado em 2010.

Imagem: Diego de Los Campos. Disponível na Internet em: http://deloscampos.multiply.com/photos/album/87/desenhos#photo=1

Término do Projeto Problema

Dando continuidade ao post "Projeto Problema", o Gerente do Projeto, o Patrocinador e os envolvidos decidiram por cancelar o projeto. Isso acontece pois em alguns casos a recuperação do projeto é irrecuperável ou inviável. Irrecuperável quando não importa o esforço dedicado para correção da rota, o resultado será o fracasso, geralmente envolve escopo. Inviável quando o esforço alocado não justifica o retorno, nesses casos o tempo e o custo são  justificativas frequentes. Ambos fadados ao fracasso.

No entanto, precisaremos de argumentos para avaliar o término de um projeto. Algumas razões para o cancelamento de um projeto, onde a recuperação é impossível [ESI]:

• O benefício do negócio não pode mais ser entregue;
• Não há suporte político;
• Inexistência do Patrocinador;
• Alteração do negócio;
• Mudanças significativas na tecnologia;
• Quebra de contrato;
• Disputa judicial;
• Mudança de mercado.

Podemos citar também a inviabilidade financeira de trazer um projeto a beira do fracasso para os trilhos. É uma decisão de perder o investimento realizado até o momento para salvar a quantia, que invariavelmente será alta, para a recuperação do projeto.

Verificada a necessidade de término do projeto, a decisão deve estar pautada sobre quatro opções de finalização:

• Adição: acontece quando o projeto problema passa a ser parte de um projeto maior, para onde são destinados o trabalho e os recursos;
• Absorção: é semelhante ao de Adição, porém somente os trabalhos são absorvidos pelo projeto maior. Infra e recursos são liberados para outro projeto;
• Inanição: é o método controverso e impiedoso, onde recursos são eliminados do projeto aos poucos, retirando o alimento de um projeto já enfraquecido, o que literalmente mata projeto de fome;
• Extinção: é o termino imediato do projeto, com o natural redirecionamento dos recursos.

Uma pesquisa nos Estados Unidos apontou as causas mais comuns para o término de um projeto, e não é surpresa que mais de 50% dessas causas é com relação ao escopo, conforme segue [PAIVA]:

• 30% alterações das necessidades do negócio;
• 23% o projeto não entregou o que era prometido;
• 14% o projeto deixou de ser uma prioridade;
• 13% estouro do orçamento;
• 07% não suportava a estratégia de negócios;
• 04% atrasos excessivos.

O próximo post finaliza a trilogia dos projetos problema com a decisão de seguir em frente com o projeto.

Abraços.


Referências

ESI International. The rapid assessment and recovery of troubled projects. Disponível na Internet em http://www.projectsmart.co.uk/docs/rapid-assessment-and-recovery-of-troubled-projects.pdf. Atualizado em 2007. Acessado em 2010.

VARGAS, Ricardo. Identificando e recuperando projetos problemáticos: como resgatar seu projeto do fracasso. Disponível na Internet em  http://www.ricardo-vargas.com/wp-content/uploads/downloads/ricardo_vargas_identifying_recovering_troubled_projects_pt.pdf. Atualizado em 2006. Acessado em 2010.

PAIVA, Luiz. Principais Causas de Cancelamento de Projetos.  Disponível na Internet em: http://ogerente.com/stakeholder/2008/08/28/principais-causas-de-cancelamento-de-projetos/. Atualizado em 2008. Acessado em 2010.

Imagem: Diego de Los Campos: Postura de ausência ou teletransportação (plano físico). Usualmente praticada nos dias de boa ondulação.Disponível na Internet em: http://deloscampos.multiply.com/photos/album/31/31#photo=7.jpg

Projeto Problema

Guias de boas práticas em gerenciamento de projetos, como o PMBOK, apresentam uma realidade um tanto fantasiosa do plano perfeito, que não existe na prática. Quem nunca ouviu "para um projeto dar errado, basta nada fazer", segundo Ricardo Vargas. Basta apenas não assumir o leme quando o barco estiver indo para a direção errada.

Mas afinal, como podemos definir um projeto problema? Aparentemente é fácil de definir na teoria, onde torna-se perceptível um projeto problemático "quando temos uma diferença que ultrapassa os limites aceitáveis entre o que foi planejado e a situação atual".

Durante o projeto será preciso monitorar constantemente sinais de disfunção nos stakeholders, recursos, escopo, riscos, escopo e prazo. Esse monitoramento ajuda ao Gerente identificar possíveis problemas no projeto, entre elas, é possível citar, segundo [ESI]:

• Os envolvidos não tem a certeza quando o projeto será finalizado: uma equipe inexperiente e a falta de recursos [WU], são algumas causas dessa indecisão quanto a entrega do produto;
• O produto do projeto apresenta muitos erros: uma equipe inexperiente e testes funcionais inadequados [WU]. Testes de segurança e desempenho ausentes ou inadequados são outras causas do número de erros no projeto (trazendo para TI). Em casos de entregas com erros vale uma análise um pouco mais fria, pois muitas horas de trabalho, as mudanças de escopo emergenciais, a pressão e o próprio treinamento da equipe podem colaborar para essas entregas problemáticas. Nem sempre a culpa é exclusivamente da equipe;
• Realização de horas extras pelo time: clássico! Horas intermináveis de trabalho extra, seja para cobrir alterações de escopo na última hora, ou para correção de erros, é um fator muito subestimado de problema no planejamento do projeto, que pode acontecer por diversos motivos, sendo um deles a inadequação do patrocinador [WU];
• A gerência perde o controle sobre o progresso ou o status preciso do projeto: a indefinição do escopo ou até mesmo do não-escopo são causas para essa sensação. Aqui entra o Gerente com auxílio da equipe para fechar o projeto junto ao cliente. Formalizar o escopo? O mundo ágil não vê com bons olhos, mas apesar de ser um fã do Agile, esse ponto é bastante polêmico, vale outro post;
• Perda de confiança do cliente sobre o time de desenvolvimento: frequentes atrasos, entregas erráticas, imprecisão quanto a entrega, são fatores que descredenciam a equipe do projeto;
• A equipe é defensiva sobre o progresso do projeto: desacreditada e como citado abaixo, por vezes com a moral baixa, a equipe se torna reativa e defensiva quanto ao andamento do projeto. Por vezes descredita a manutenção do escopo, o que limita a visão do fim que a equipe tem sobre o projeto, fator desmotivador. Bola de neve;
• A relação entre o time de desenvolvimento e os demais envolvidos estão tensas e por vezes desgastadas: erros constantes e atraso por um lado, alteração constante de escopo pelo outro lado acirram os ânimos dos envolvidos. O Gerente deve tomar medidas diplomáticas para resolução desse problema e por vezes, em uma atitude mais radical, isolar a equipe de desenvolvimento, procurando manter o ambiente apropriado para o trabalho;
• O projeto está a beira do cancelamento: quando o próprio patrocinador já questiona a continuidade do projeto é um fator mais do que necessário para desencadear boa parte dos itens citados acima. Por vezes, e iremos ver em posts futuros, o cancelamento é a saída mais plausível a ser tomada, por outras, prejudica o andamento de um projeto já errático. O Sponsor é aquele que acredita e deposita a confiança nos envolvidos. Fala do projeto com entusiasmo e o abraça como se fosse a um sonho pessoal. Isso é inspirador e contagia a equipe;
• A moral o time está abalada e demasiadamente baixa: erros + insatisfação + pressão interna por vezes inevitável + projeto a beira do cancelamento. É uma fórmula bastante depreciativa e certamente abala qualquer equipe. Trazê-la de volta ao rumo certo é tarefa complicada e quase impossível em curto prazo;
• O cliente ameaça tomar medidas legais: projetos com contratos SLA, por exemplo, prevêem a ação judicial em caso de erros por pontos de função, por exemplo, que quando acionados, trazem intranquilidade e aumenta a pressão sobre a equipe de projeto. É um claro indicador de problemas no projeto.

Outros fatores citados por VARGAS, que identificam um projeto problema são:

• Ausência dos envolvidos no projeto: quem define o negócio? Onde está o Product Owner? Essa ausência compromete o produto do projeto, que poderá não atender ao negócio. Uma situação contrária, onde temos dois ou mais Product Onwer é também um problema ao projeto e o seu escopo. Uma fórmula que invariavelmente funciona é de um PO que centraliza ideias dos envolvidos;
• A escassez de recursos: esse é um dos grandes problemas do Gerente de Projetos, lidar com recursos limitados ou concorrentes entre projetos. A arte do gerenciamento de projetos é mensurar o tempo para esses casos, e ainda atender a expectativa dos envolvidos. É uma arte, inegavelmente;
• A saída voluntária de pessoas: aumento da pressão, a insatisfação, a não percepção de valor, a sensação de que aquela obra não é dele, como diria Mario Cortella, desmotiva o indivíduo;
• Indefinição entre as partes do que é ou não escopo: ausência de uma definição formal do escopo e não-escopo. Tarefa do Gerente (note que existe um mix entre termos do Agile e do gerenciamento de projetos tradicional, característica de alguém que flerta com os dois mundos);
• Os impactos dos riscos são maiores: projetos com problemas no escopo, tempo e/ou custo costumam reagir aos riscos de forma anormal, portanto, o planejamento de riscos deve prever uma reação aos riscos mais pessimista que em projetos em situação regular;
• Aumento da informalidade: a documentação do projeto é negligenciada por falta de tempo, diminuindo a confiabilidade desses documentos. É uma atitude desesperada que pode acarretar problemas futuros, principalmente em projetos com alterações frequentes no escopo, sem o controle das mudanças.

Após a identificação de um projeto problema o Gerente tem ao menos dois caminhos: corrigir o rumo ou terminar o projeto, afim de evitar ou minimizar a exaustão dos participantes, a redução da moral e da auto-estima da equipe, a potencialização da sensação de falta de controle, que são o reflexo de um projeto problema.

Nos próximos posts comento sobre essas duas escolhas: cancelar ou tocar em frente? Eis a questão.

Referências:

EIS Internacional. The rapid assessment and recovery of troubled projects. Disponível na Internet em http://www.projectsmart.co.uk/docs/rapid-assessment-and-recovery-of-troubled-projects.pdf. Atualizado em 2007. Acessado em 2010.

WU, Jonathan. Top 10 warning signs of a troubled BI project. Disponível na Internet em http://www.information-management.com/news/2707-1.html. Atualizado em 2000. Acessado em 2010.

VARGAS, Ricardo. Identificando e recuperando projetos problemáticos: como resgatar seu projeto do fracasso. Disponível na Internet em http://www.ricardo-vargas.com/wp-content/uploads/downloads/ricardo_vargas_identifying_recovering_troubled_projects_pt.pdf. Atualizado em 2006. Acessado em 2010.

Agile e PMBOK

    Como primeiro post, apresento uma pequena parte do artigo de conclusão da pós em Gerenciamento de Projetos, que teve como título "A Mudança em Projetos de Software". Apesar de bastante discutido, gostaria de opinar sobre esse controverso tema.

Incertezas e as consequentes mudanças no projeto são inerentes em projetos de desenvolvimento de software. Esse é um dos motivos para o surgimento das metodologias ágeis, como o Scrum, onde segundo Scott Ambler , "times de desenvolvimento de software abraçam as mudanças, aceitam a ideia de que os requisitos serão desenvolvidos durante o projeto".

Muito se ouve sobre a inadequação do formalismo do PMBOK para atender demandas de software. Por vezes, a justificativa é de que o uso de todos os 42 processos oferecidos pelo PMBOK (quarta edição). Que é robusto demais para ambientes de software. O PMBOK é um conjunto de melhores práticas, e segundo Ricardo Vargas, em mais de cem projetos trabalhados, ele nunca utilizou todos os processos idealizados pelo PMI.

Existe um grande muro de mitos criado sobre a afirmação que os dois mundos supracitados não convergem, que são incompatíveis. No entanto, diversas práticas são bastante semelhantes entre Metodologias Ágeis e o PMBOK. O ciclo de vida do PMBOK se assemelha em muito com as iterações do Scrum; ou ainda a Elaboração Progressiva do Agile segue exatamente a mesma ideia do Planejamento em Ondas Sucessivas do PMBOK.

Contudo, erra quem afirma que uma terceira via não existe. A união das melhores práticas das metodologias com o objetivo de gerar resultado. A convergência deve acontecer em busca da meta. E é com base nessa união, na tentativa de mitigar números tão absurdos de insucessos em projetos de software, absorvendo e promovendo mudanças, que deve-se quebrar paradigmas e mesclar ideias.

No Manifesto Ágil, Beck (2008) preconiza: "Software em Funcionamento mais que documentação abrangente". Conforme o próprio manifesto, existe valor na documentação, no entanto, a maior atenção é dada ao software em funcionamento. Além disso, "Responder a mudanças mais que seguir um plano", mostra que para dar suporte às mudanças devemos estar preparados para elas, ou seja, a mudança deve estar presente no planejamento.