Gerenciamento de Comunicações em Projetos - Matriz de Comunicação

Uma parte importante em um projeto, que freqüentemente acaba não sendo muito privilegiada, é o gerenciamento das comunicações.
Dentro da Engenharia de Requisitos a comunicação formal se torna bastante importante na gestão das mudanças nos requisitos (solicitações de mudanças).
O gerenciamento das comunicações do projeto é o setor que emprega os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação final das informações aos envolvidos no projeto. Devem ser especificados métodos que permitam a transmissão da informação de maneira clara e sem ruídos (alterações).
A matriz de comunicação é uma ferramenta que especifica quais documentos serão comunicados, para quais stakeholders (envolvidos no projeto), em que freqüência (quando) e por qual meio (como). Ela deve estar presente dentro do plano de gerenciamento das comunicações do projeto (documento de planejamento das comunicações). Ela pode ser criada em qualquer software básico de escritório.

Exemplo de Matriz de Comunicação

Uma matriz de comunicação tem as informações (poderão ser alteradas/adaptadas conforme necessidades específicas):

1.    Tipo - tipo da comunicação. Ex: reunião de status mensal, reunião com usuário, prestação de contas semanal, relatório de status do projeto, etc.
2.    Objetivo - descrição da comunicação. Ex: informar status atual aos participantes do projeto, informativos financeiros de gastos/receitas, etc.
3.    Meio - meio da distribuição da informação. Ex: e-mail, telefone, comunicador instantâneo, vídeo-conferência, reunião presencial, etc.
4.    Periodicidade - freqüência, motivo ou datas específicas que deve ocorrer à comunicação. Ex: semanal, mensal, em qualquer “estouro” de prazo, em qualquer “estouro” em custos, etc.
5.    Destinatário(s)- envolvido(s) que deve(m) receber a comunicação. Ex: usuários, stakeholders, analistas de sistemas, programadores, gerente do projeto, diretor técnico, patrocinador, fornecedor, etc.
6.    Responsabilidade- responsável pela informação. Ex: gerente do projeto, analista de sistemas responsável, etc.
7.    Documento(s) - documento(s) gerado(s). Ex: ata de reunião, relatório de status do projeto, planilha de custos do projeto, etc.

Negligenciar a comunicação em um projeto poderá trazer diversas conseqüências negativas.  Membros da equipe terão diferentes conhecimentos sobre projeto, patrocinadores não estarão informados sobre o andamento, membros participantes poderão não receber informações vitais e necessárias, entre outras conseqüências, que poderão trazer impactos em cronograma, prazos e custos.

Fonte:
Project Management Institute Inc. Guia PMBOK. 3. edição. Project Management Institute Inc. 2004.

Custo de erros em projetos de desenvolvimento de software

Cada projeto é único (mesmo projetos semelhantes terão diferenças significativas) e é impossível fazer estimativas ou ter fórmulas genéricas para estimar o custo de erros que poderão acontecer.

Na monografia de Marco Aurélio Cordeiro para o curso de Pós Graduação em Informática Aplicada da Pontifica Universidade Católica do Paraná (Curitiba, 2002) ele cita um estudo realizado nos anos 70 pelas empresas GTE, TRW e IBM, onde um custo relativo de um erro localizado durante a análise de requisitos é 0.1, já um erro localizado na fase de implementação é 1 (10 vezes mais), na fase de testes seu custo relativo sobe para 2 (20 vezes mais), terminando com um custo relativo de 20 (200 vezes mais) na fase final de manutenção. O gráfico abaixo retrata essa situação.

 

Vale ressaltar que esse é um estudo realizado numa outra realidade de desenvolvimento de software muito diferente da atual (anos 70), mas que já mostra que há muito tempo o custo para correção de erros é uma preocupação nas organizações.

Já na monografia de Paulo Henrique Ramos apresentada no curso de Mestrado em Ciência da Computação na Universidade Federal de Pernambuco (Recife, 2011) ele cita um estudo onde o custo de uma falha localizada na fase de testes pode ser 30 vezes o custo inicial, se ele fosse localizado na fase inicial (análise de requisitos).

Roger S. Pressman no livro Engenharia de Software (6. edição, 2006) declara que o custo de defeitos na fase de projeto é cerca de três a seis vezes mais alto do que na definição de requisitos e o custo é ainda maior em fases finais como na fase de testes.

Seja qual for a metodologia usada ou o estudo utilizado, a conclusão é sempre que o custo de correção de um defeito é sempre muito inferior quando identificado no inicio de um projeto e muito superior quando identificado na finalização do projeto.

A importante fase Análise de Requisitos exige maior qualidade, pois suas falhas poderão comprometer todo o projeto.

Documento de Lições Aprendidas em Projetos

Um importante documento em um projeto que muitas vezes é visto com pouca importância ou apenas como mais uma formalidade a ser cumprida é o Documento de Lições Aprendidas. Esse documento visa que os erros passados não sejam mais cometidos e que acertos possam ser mais facilmente repetidos.

Muita da experiência (boas e ruins) adquirida em um projeto acaba permanecendo apenas na memória de seus participantes e a documentação dessas “memórias” é importante para melhoria contínua de projetos atuais e futuros de uma organização.

A construção dessa documentação não exige um software específico ou complexo, mas poderá ser construído em software básico de escritório como um processador de textos ou uma planilha eletrônica.

No geral eu utilizo as seguintes informações a serem preenchidas (colunas de uma planilha):

1) Área – área, setor ou departamento dentro do projeto. Ex: Custos, Aquisições, etc.

2) Assunto – uma breve descrição da lição a ser documentada. Ex: Arrecadação financeira, Controle dos riscos, Atrasos, Problema com fornecedor, etc.

3) Descrição – uma descrição mais detalhada e explicativa da lição a ser documentada.

4) Pessoa – nome (em alguns casos pode ser necessário também um código) do integrante do projeto que está documentando a lição.

5) Efeito – Positivo ou negativo para o projeto.

6) Resposta/Ação – Atitudes que podem ser tomadas para evitar (ou minimizar) um efeito negativo ou favorecer um efeito positivo.

Vale lembrar que o caráter desse documento é de livre acesso (mesmo que com algumas restrições) por pessoas de diferentes projetos dentro da organização. Informações confidenciais devem integrar outros documentos mais restritos.

Fatores como prazos, falta de interesse ou conhecimento e preocupação em iniciar novos projetos muitas vezes fazem com que esse importante documento deixe de ser feito.

Causas de Fracasso de Projetos de Desenvolvimento de Software

Periodicamente é realizada no Brasil a Pesquisa Archibald & Prado (ocorreram nos anos de 2005, 2006, 2008 e 2010) onde organizações de diversos portes e ramos de atividade respondem um questionário a respeito de projetos realizados.

Na pesquisa realizada entre setembro e dezembro de 2010 participaram 345 organizações brasileiras e num dos tópicos analisaram as 3 principais razões do fracasso no desenvolvimento de software. O gráfico abaixo mostra as causas apontadas:

O conceito de fracasso utilizado na pesquisa foi: "projeto foi paralisado ou o produto/serviço entregue não está sendo utilizado por não atender às expectativas dos usuários ou o atraso foi tal que implicou em perdas para o negócio. O usuário/cliente ficou profundamente insatisfeito."

Frequentes mudanças de escopo (76%)

Freqüentes alterações de prioridade (34%)

Alterações em necessidades do cliente e identificação de novas necessidades é um fato comum dentro dos projetos de desenvolvimento e um processo formal de Gerenciamento de Mudanças se faz necessário para manter os controles de prazo e custo.

Ocorre que uma mudança muito grande (sendo ou não uma alteração no escopo) e não esperada fará com que qualquer margem de segurança ou plano de contingência percam a sua eficiência ou se tornem inúteis.

Tal ocorrência força a uma renegociação entre cliente e fornecedor, mas nem sempre cliente pode alterar seu investimento no projeto ou conceder mudanças no prazo de entrega e nem sempre o fonecedor pode assumir maiores custos com o projeto alterando assim sua receita (em casos graves podendo chegar até a uma receita negativa).

Comprometimento insuficiente ou inadequado das áreas usuárias envolvidas (38%)
Comprometimento insuficiente ou inadequado da alta administração (7%)

Diversos motivos podem levar a um "boicote" por parte de usuários chave. Usuários frequentemente são resistentes a grandes mudanças, mas eventualmente podem estar envolvidos demais com as atividades cotidianas e sem tempo disponível para dedicação ao projeto.

Usuários podem se desinteressar do projeto ao perceberem que gestores de cargos mais altos não estão comprometidos. Sem apoio desses gestores outras atividades receberão maiores atenções.

Em qualquer causa identificada, é importante que sejam procuradas soluções e buscado um maior envolvimento dos usuários. Em casos graves tem que existir uma requisição para que usuários participantes do projeto sejam substituídos. Uma permanência com esse problema levará a problemas no cronograma e consequentemente a estouro no prazo final do projeto.

Precariedade de método, ferramentas e técnicas para o gerenciamento dos projetos (38%)
Insuficiente capacidade gerencial dos Gerentes de Projetos (7%)

Processos formais de gerenciamento de projetos, como por exemplo o Guia PMBOK do Project Management Institute, são importantes para descrever de forma organizada o trabalho a ser realizado por diferentes áreas e especialidades durante o projeto possibilitando o intercâmbio eficiente de informações entre os profissionais envolvidos.

Quanto maior e mais complexo o projeto, maior a necessidade de diferentes profissionais e equipes conseguirem atuar em conjunto com eficiência.

Tamanho da carteira de projetos muito além da capacidade de atendimento do setor (31%)
Habilidade técnica da equipe, em T.I., insuficiente ou inadequada para os desafios (7%)

A demanda cada vez mais crescente das empresas por tecnologia também exige cada vez profissionais mais qualificados. O problema central é que maior qualificação exige maior investimento, mas acompanhando notíciais, percebo que nem governo e nem indústria privada querem arcar com esses custos, deixados para investimento maior dos profissionais interessados e quem possam pagar esses custos.

É importante uma parceria maior entre universidades e indústrias privadas, a fim de qualificar profissionais com necessidades reais do mercado.

Falta de recursos humanos, financeiros e materiais (24%)
Estudo de Viabilidade incompleto ou incorreto (21%)
Prazos inexeqüíveis (17%)
Riscos não adequadamente gerenciados (14%)


Um planejamento adequado feito com processos adequados minimiza problemas com prazos e custos. Da mesma forma uma Análise de Riscos poderá prever contingências e provisões para muitos problemas que podem ocorrer durante o projeto. Mas alterações muito expressivas durante a execução de um projeto poderão fazer fracassar qualquer planejamento.

Ocorre que pressões por soluções rápidas pode forçar que um projeto seja aprovado com uma expectativa de conclusão não viável. Nem sempre argumentos de profissionais responsáveis poderão persuadir uma reavaliação de projetos com essa característica.

Conforme um professor meu dizia, com tantos riscos, problemas e possibilidades de fracasso que ocorrem e projetos bem organizados acabam fracassando, existe uma solução concreta?
A solução concreta não existe, mas fazer de forma adequada favorece uma maior chance de êxito e fazer de forma incorreta chances mais certas para o fracasso.