Quando falamos sobre “Plano de Comunicação”, a maioria entende como um roteiro, um documento que contém regras, frequência e padrões de como a comunicação acontecerá ao longo do projeto. Estamos falando de modelos padrão de relatórios, de e-mails e até mesmo alguns incluem informações sobre cordialidade.
Não que esta definição esteja errada, mas quando falamos em Modelo Híbrido de Gerenciamento de Projetos precisamos lembrar que a comunicação é mais do que um relatório na data certa, um e-mail bem escrito ou um formato padrão.
Como nesta série estamos abordando as micro e pequenas empresas que precisam gerenciar projetos, precisamos considerar que é bem provável que a maioria das pessoas envolvidas no projeto trabalham juntas, no mesmo prédio, mesmo andar e as vezes na mesma sala. Portanto, temos que otimizar a comunicação.
Levantar e ir até a mesa da pessoa conversar ou pegar o telefone e ligar para um fornecedor, um parceiro fora da empresa ou até mesmo no exterior costuma ser muito mais eficaz que um e-mail ou relatório agendado.
Não se proteja através de um plano
Certamente você já ouviu frases como essas:
- Mas como você não está ciente do assunto X? Eu enviei um email pra você tem 2 dias!
- Espere, esse ponto chave está descrito nos requisitos do projeto, você não leu? Esta na página 57 parágrafo 3.
Se analisarmos apenas o Plano de Comunicação destes projetos é bem provável que lá tenha uma regra sobre sempre enviar e-mail quando se tratar do assunto X, ou sempre criar um documento de requisitos seguindo o modelo da pasta c:\abcd e entregar para os envolvidos na data Y.
Mas veja qual é o primeiro item do Manifesto Ágil:
Indivíduos e interação entre eles mais que processos e ferramentas
Se o projeto é auditado, se a empresa possui um departamento de qualidade, é importante existir sim um plano com estas regras, mas não podemos utilizar estas regras para nos proteger perante nossa própria ineficiência.
Quando o assunto é muito importante, certifique-se de que a pessoa que recebeu o relatório tenha entendido. Faça uma leitura em conjunto, explique os pontos chave do relatório. Levante-se da sua mesa e trate o assunto pessoalmente com a outra parte e apenas use o email para registrar o que foi falado, como uma Ata, se necessário.
Reuniões Diárias
Um dos tipos de reuniões existentes no Scrum é a Reunião Diária. É um evento com tempo determinado de 15 minutos. Podemos aproveitar este tipo de reunião em qualquer projeto, sem se preocupar se estamos aplicando uma metodologia específica.
Nestas reuniões as pessoas devem chegar no horário marcado. Além disso, muitos podem participar mas existe uma lista prévia dos que estão autorizados a falar.
Estas reuniões costumam ser no começo do dia e cada membro autorizado a falar precisa responder 3 questões rapidamente:
- O que você fez ontem para atingir suas metas?
- O que você está planejando fazer hoje para atingir suas metas?
- Existe algum problema, algum impedimento que o impeça/atrapalhe em atingir sua meta?
É o líder da reunião (no Scrum é conhecido como o Scrum Master) o responsável por resolver estes impedimentos, sendo isso feito fora da reunião.
Este papel pode ser assumido em pequenas empresas pelo Gerente de Projetos ou o Líder do Projeto. Ao longo do dia ele irá conversar com fornecedores. parceiros e individualmente com os envolvidos para solucionar estes impedimentos e problemas, ajudando assim o participante do projeto a entregar a atividade pela qual é responsável, atingindo a meta programada para ele.
Mas o que vai no plano?
Segundo o PMBOK, o plano de comunicação determina principalmente:
- Quem precisa de qual informação
- Quando esta informação é necessária
- Como e por quem esta comunicação será distribuída.
Um bom plano de comunicação deve se preocupar em definir métodos de como transmitir esta informação sem ruídos, preocupando-se principalmente no feedback do receptor da informação, garantindo que o mesmo entendeu a mensagem.
Neste ponto, muitos devem se lembrar da “matriz de comunicação”. Uma tabela contendo estas regras e destinatários:
Fonte: Revista Mundo PM – Ed. 37.
Mesmo em projetos pequenos esta matriz poderia ficar enorme. E convenhamos: Quantos stakeholders vão olhar no plano de comunicação para saber como se comunicar com determinada parte do projeto?
Em projetos ágeis ou híbridos precisamos de uma solução melhor. Inicialmente devemos ter o foco na comunicação direta em busca de solucionar o problema. Se existe uma hierarquia na empresa e a mesma não é flexível, busque esta comunicação seguindo a hierarquia e padrões da empresa. Agora, se você tem acesso direto a alguém no projeto que pode ajudá-lo a resolver seu problema, busque diretamente esta pessoa.
Antes de tudo, as Regras
Definnir regras para a comunicação garantirá eficiência, eficácia e agilidade durante a comunicação no projeto. Busque definir apenas as regras importantes, as que façam a diferença no plano. Exemplos:
- Requisitos e Priorização não devem ser comunicados para a equipe de desenvolvimento via e-mail (comunicação verbal)
- Apenas o time de desenvolvimento pode falar nas sprints diárias (para projetos de desenvolvimento)
- Face-a-Face > Vídeo-Conferência > Telefone (Skype) > E-mail > Papel
Neste último item considerei a sequência de comunicação por método mais eficiente até o menos eficiente. Veja que os métodos formais como e-mail e papel no fim desta lista!
Matriz de Comunicação Ágil
Mesmo em métodos ágeis precisamos ter alguns registros formais, desde que estes registros tragam valor ao projeto e sejam usados. Um dos documentos importantes é o plano de comunicação onde podemos resumir em uma matriz. Não a matriz convencional, vamos considerar uma matriz ágil:
Neste exemplo inseri algumas das reuniões formais de um projeto que utiliza métodos ágeis. Note a coluna “Data/Hora”. É fundamental que esta matriz esteja disponível em um local de fácil acesso e sempre atualizada. Empresas que possuem agenda de equipe integrada podem facilmente já reservar os horários durante a duração prevista do projeto.
Porém, alguns destes eventos precisam de um registro formal como atas, lições aprendidas, etc. Após definir os eventos e documentos realmente necessários para o projeto, é válido criar uma tabela separada com o detalhamento destes eventos, sua audiência e o “dono” do evento:
Um “dono” para o evento é importante, pois ele deverá preparar o mesmo além de ser responsável por buscar as entregas e garantir que o evento ocorra como planejado. Esta tabela também é importante pois reforça quem deve ter acesso à determinada informação. Um exemplo que podemos ver nesta planilha é que nem todas as partes interessadas devem ter acesso ao documento de “Lições Aprendidas”.
Procure associar cada documento formal que você precisa no projeto com algum evento gerador. Desta forma você garante que todos os documentos estão indo para as pessoas que realmente devem e precisam ter acesso a ele. Novamente reforço: Crie apenas documentos formais que tragam valor para o projeto, seja para formalização, auditoria ou controle. Não crie documentos que serão lidos uma vez e arquivados e nunca mais serão consultados.
Espero que tenham gostado do artigo. Os próximos serão sobre levantamento de requisitos, riscos e premissas! Obrigado pela leitura e aguardo seu comentário!
Postado originalmente em: http://www.vignado.com.br/?p=405
