Boas Práticas de Gestão de Projetos – Parte 2

Olá! Vamos continuar neste artigo a apresentação da sequencia de boas práticas para uma boa condução de projetos…

Aqui vamos tratar de mais 5 boas práticas (6 a 10), se você não leu as 5 primeiras, segue o link do primeiro artigo.

Como comentei no artigo anterior, todas estas boas práticas são fruto da minha experiência (e de meus colegas) nestes últimos 20 anos como consultor na área, envolvido em projetos de diferentes naturezas e em diferentes ramos de negócio.

Vamos então às boas práticas…

BP#6: Crie uma lista de características da sua solução (ou requisitos), tenha conciência que ela evoluirá à medida que as hipóteses da solução forem comprovadas (ou não).

Como citamos na BP#5, projetos envolvem o estabelecimento de hipóteses para a solução de um problema (ou explorar uma demanda), tais hipóteses estão atreladas às características daquilo que vai ser construído (um produto e/ou serviço).

Os mais conservadores em gestão de projetos chamarão tais características de requisitos, os agilistas chamarão de user stories, não importa a denominação, tais atributos da solução são uma ótima forma de descrever o que vai ser criado, clarificando os horizontes para os que vão usufruir dela, assim como para o time que vai construí-la, servindo de direcionador (uma bússola) para os trabalhos.

Muitos até relacionam tais características a serem criadas com o chamado Sprint Backlog, que nada mais é que uma lista de coisas que precisam ser feitas, na forma de funcionalidades (features) da solução.

Deixo claro aqui que isto vale para a grande maioria dos projetos, e não somente para os de software…

BP#7: Identifique os stakeholders (partes afetadas), entenda como influenciá-los em favor da condução do projeto.

Um projeto é um evento político, explico, a equipe de projeto e a comunidade de stakeholders (partes afetadas) que assiste os trabalhos tem demandas e percepções diferentes. Fazer com que todos caminhem para um objetivo comum consiste na da arte da política de condução de um projeto.

Assim, para conseguir esta coesão, inicialmente faz-se necessário entender como cada indivíduo enxerga o projeto, fazendo uso da empatia.

Compreendendo como cada stakeholder é afetado parte-se para a segunda e terceira etapas do gerenciamento político de um projeto, priorização e resposta.

Como priorização entendo em identificar quais são os stakeholders que podem impactar de forma significativa a entrega de valor do projeto (o seu legado), o que não necessariamente quer dizer que estamos tratando de um gerente ou executivo, pois um usuário de uma solução mal envolvido no projeto pode por muita coisa a perder…

Cabe ressaltar que um dos princípios da geração de hipóteses em projetos é testá-las, e quem vai fazer isto e nos dar feedbacks é peça-chave na nossa jornada de entrega de valor e descoberta.

Identificados os stakeholders mais importantes, inicia-se uma reflexão sobre como se pode obter o apoio de cada um deles (etapa de resposta), Alan Cohen, autor do Livro “Influência sem autoridade” costuma dizer que todos, de alguma forma, esperam algum tipo de recompensa. Exemplos de recompensas podem ser oferecer um desafio ao indivíduo, dar um significado ao seu trabalho, dar-lhe visibilidade, etc, ou seja, entender como se pode estabelecer uma zona de sombreamento entre os interesses e objetivos do projeto e os interesses e objetivos do indivíduo.

Em alguns cenários stakeholders relevantes podem nos trazer novas demandas, a fim de criarmos esta zona de sombreamento, o que pode, em última instância, a reconfigurações no projeto. Destaco que isto está longe de ser um descontrole no projeto, mas precisamos sempre ter em mente o velho ditado que “o melhor é inimigo do bom” e política (no bom sentido) faz parte do contexto.

BP#8: Cuide do engajamento do time.

Certamente você já deve ter ouvido uma dica desta natureza em outros posts, mas aqui queria deixar algumas questões um pouco mais práticas.

Além de identificar o que motiva cada indivíduo na equipe, é pertinente estabelecer um senso de urgência, a fim de “elevar a temperatura” do time.

John Kotter, autor do livro “Liderando mudanças” explica que o senso de urgência é o combustível da equipe, assim estabelecer metas ou entregas muito distantes não funciona, pois o indivíduo em última instância se questiona…”Em que isto vai mudar minha vida agora?”

Logo a procrastinação, este fantasma corporativo, precisa ser exorcizado, metas próximas são uma alternativa, muitos denominam tais metas como quick wins, ou seja, vitórias de curto prazo.

Cumpridas estas vitórias, nada mais justo que pequenas comemorações, a fim de estabelecer uma retribuição ao time, um reconhecimento pelo trabalho feito.

Só tome um cuidado, não comemore em demasia, se não o jogo vira e a equipe acha que “já ganhou”, ok?

Um outro ponto a se comentar que ajuda muito no engajamento do time é a presença do líder, assim nada de ficar no seu computador disparando emails somente fazendo cobranças (já vi muito disso…), é preciso ter skin on the game, ou seja, estar junto do time.

Vamos esclarecer melhor este ponto, visite a equipe com maior frequencia, tenha conversas com cada um deles (não necessariamente sobre o projeto), procure identificar reais ou potenciais bloqueios para a realização dos seus trabalhos e atue como um jardineiro.

Um jardineiro!?! Isso mesmo, o novo paradigma de liderança não é mais o de um comandante, mas de um jardineiro que identifica impedimentos e procura retirá-los, permitindo que cada indivíduo (ou planta do jardim), floresça e se desenvolva melhor.

BP#9: Identifique quais são as premissas e restrições do projeto, entenda suas relações com os riscos.

Acho que aqui é importante trazer as definições de premissa, restrição e risco, visto que em workshops e consultorias rotineiramente me deparo com situações as quais revelam a confusão dos termos.

Como restrição podemos entender todos os fatores que limitam as opções do projeto, quer em termos de tecnologia, pessoas, recursos financeiros e tempo. Também é muito comum verificar questões de compliance como restrições, visto que a adequação às boas condutas da organização, e em última instância às leis, servem de condições de contorno na definição de hipóteses e realização de testes.

As premissas podem ser entendidas como fatores que assumimos como verdadeiros no contexto do projeto, ou seja, são pontos de partida nos quais o projeto é construído.

Costumo usar a seguinte metáfora para explicar este conceito, imagine que seu projeto é uma grande torre, na sua base temos os alicerces de concreto, entenda cada alicerce como uma premissa, note que ele não faz parte da torre (o seu projeto), mas depende totalmente dele para não cair.

Um exemplo que acabo me deparando com frequencia é o caso de projetos na área de business intelligence, os quais buscam gerar dashboards para análise de dados, gerando informação para a tomada de decisão da alta gestão, seja na área financeira ou operacional.

Nestes projetos uma premissa certamente está na fidedignidade dos dados que serão utilizados na criação do dashboard, pela minha experiência esta premissa costuma falhar em muitos casos e o projeto acaba atrasando porque foi necessário enxertar uma etapa de tratamento de dados (remoção de redundâncias, verificação de valores, adequação de formato do banco de dados, etc).

Daí que se conclui que é importante estudar o contexto do projeto para mapear as premissas, visto que elas são fontes de riscos para o projeto.

Deixo aqui o link de um outro artigo interessante que escrevi sobre competências necessárias para a boa condução de um projeto, nele detalho mais quais as questões do contexto que precisam ser levadas em conta.

Há quase um axioma nesta questão….“toda premissa tem ao menos um risco associado”.

Bom, agora que mencionamos a relação entre premissas e riscos, precisamos definir o que é um risco.

Risco é um evento que pode ou não acontecer e, em acontecendo, trará um impacto positivo (isso é bem raro) ou negativo ao projeto, este impacto normalmente se materializa em atrasos nas entregas por conta de retrabalho.

Assim é importante mapear os riscos do projeto, pode-se começar analisando cada uma das premissas e refletindo….“e se esta premissa se mostrar falsa, qual ou quais serão os desdobramentos sobre o projeto?”

Uma simples pergunta como esta levada ao time pode levantar várias respostas ou, como gosto de dizer, contramedidas para reduzir a chance do risco acontecer ou minimizar os impactos.

Tais reflexões do time pela minha experiência acabam em contramedidas que trazem em um ligeiro aumento no prazo, por conta da criação de contingências, mas é importante dizer que isto faz parte do contexto, pois o que se quer é aumentar a chance de sucesso (entrega de valor) do projeto.

Riscos devem ser mapeados continuamente ao longo dos sprints, incite este tipo de pensamento no time, o maior inimigo neste momento é o excesso de confiança…

BP#10: Defina entregas bem claras para demonstrar a geração de valor contínua do projeto.

Alguns chamam as entregas pelo seu termo em inglês: deliverables. Entende-se entrega como qualquer artefato gerado ao longo do projeto, pode ser o resultado de um teste, a criação de um protótipo, a validação de uma hipótese, todos estes e mais outros momentos importantes do projeto, os quais relacionam a materialização de uma descoberta à linha do tempo.

Este tipo de artifício é ótimo para acalmar os ânimos dos executivos, os quais normalmente estão ansiosos por resultados…Assim não demore muito para gerar entregas, crie uma linha do tempo macro do projeto com, pela minha experiência, ao menos uma entrega importante por mês.

Aliás este conceito vai de encontro com as quick wins que mencionamos na prática #8.

Uma expressão que se costuma ouvir neste caso é “temos que alimentar os tigres…”, entendendo o tigre como um animal corporativo (executivo) ansioso por resultados. Assim, gere entregas continuamente, mesmo dentro do contexto dos sprints (geração de hipóteses, condução de testes e tratamento dos feedbacks).

Esta estratégia te dá um pouco mais de calma para trabalhar com a equipe, reduzindo a pressão externa.

Muito bem, concluímos aqui o segundo artigo, falamos de mais 5 boas práticas de gestão de projetos, perfeitamente aplicáveis quer em um contexto ágil ou mais ortodoxo.

Aguarde o próximo artigo com mais 5 boas práticas… Espero que este material o ajude a ter melhores resultados em seus projetos, quer pessoais ou profissionais…

Até mais!