Arquivo mensal: abril 2011

Ferramenta de apoio à comunicação em projetos: A Matriz de Comunicação

Participando de diversos projetos percebi que, geralmente, determinados esforços são privilegiados em detrimento de outros. Isso se deve, muitas vezes, à frequente pressão para se encontrar uma solução rápida e adequada no gerenciamento de determinados projetos. Um dos esforços NÃO privilegiados é o planejamento da comunicação no projeto, igualmente relevante para o sucesso das atividades.

Um fato notório é que em quase todos os projetos com grau de complexidade mais elevado, pode ser constatada a ocorrência de uma abordagem não adequada da comunicação. A ideia de “transparência no projeto” deve fundamentar um bom plano de comunicação sem, contudo, agregar muita coisa no processo de gerenciamento do projeto.

Atualmente, contamos com diversas ferramentas que dão suporte a uma adequada comunicação em projetos. Estudos demonstram que “o sucesso de uma comunicação depende de uma adequada seleção de ferramentas e de suportes de gestão adaptados ao projeto” [VIEIRA, 2011]. Sendo assim, o objetivo deste post é apresentar conceitos e benefícios de uma dessas ferramentas como suporte à gestão da comunicação: a matriz de comunicação.

A matriz de comunicação é uma ferramenta que especifica quais documentos serão comunicados, para quais stakeholders, em que freqüência (quando) e por qual meio (como). Ela deve estar presenta dentro do plano de comunicação do projeto. Para um melhor entendimento, observe a matriz abaixo.

Figura 1 – Matriz de comunicação

Fonte: Revista Mundo PM – Ed. 37.

 Segundo o PMBOK o plano de comunicação determina as necessidades de informação e comunicação dos envolvidos no projeto; por exemplo, quem precisa de qual informação, quando ela será necessária, como e por quem ela será distribuída. Um bom plano de comunicação deve especificar métodos que permitam transmitir a informação sem ruído, de maneira clara, tendo sempre o feedback do receptor. Assim, a matriz de comunicação, exemplificada acima, apresenta informações de grande utilidade para o plano de comunicação do projeto.

A matriz de comunicação pode ainda ser utilizada como ferramenta de apoio para projetos que utilizem metodologias ágeis de desenvolvimento. Vamos tomar como exemplo o framework Scrum, o qual desenvolve a comunicação por intermédio de Daily Meeting, Burndown Charts, Quadro de Kanban, etc. Sim, estas ferramentas permitem a comunicação e visibilidade do projeto, mas existem outras necessidades que estas ferramentas não atendem. É nesse ponto que entra a utilidade da matriz de comunicação: técnica complementar para apoio à adequada comunicação em projetos ágeis.

Figura 2 – Matriz de comunicação para projetos com Scrum.

Fonte: http://blogdoabu.blogspot.com

Para finalizar, gostaria de frisar que a comunicação em projetos tem que ser tratada como as demais gestões (custos, riscos, escopo, integração, etc.): um permanente facilitador para obtenção de sucesso em projetos. Trata-se de uma gestão bastante crítica, pois, se desprezada ou negligenciada, pode produzir onerosos retrabalhos, arruinar cronogramas, aumentar os riscos e custos, etc. Em posts futuros irei apresentar com mais incisão como planejar a comunicação em projetos de forma a criar um ambiente propício ao sucesso.

A engrenagem do Scrum

Muitas pessoas acreditam que Scrum é uma metodologia que ajuda a desenvolver melhores produtos. Isso não é verdade! Se a solução idealizada e projetada for ruim, o produto que será produzido também será ruim, independentemente da metodologia utilizada. Scrum não lhe dá a resposta de como desenvolver software de qualidade mais rapidamente. Trata-se de um framework que pode ser usado para identificar o que precisa ser feito para desenvolver software de qualidade rapidamente. Assim, aqueles que acreditam que o Scrum é uma bala de prata que irá sempre resolver todos os seus problemas de forma simplista e eficiente, se enganou! Tornar o Scrum eficaz e eficiente depende da correta aplicação dos conceitos que norteiam esse framework.

O Scrum, em sua essência, é simples de ser compreendido e aplicado. Porém, antes de explicar como funciona a engenharia desse processo é necessário compreender as pessoas que estão envolvidas e seus papéis. No Scrum existem três papéis de atuação:

  • Product Owner 
    • Define as funcionalidades do produto;
    • Decide a data de entrega e o conteúdo;
    • Responsável pelo ROI (Return of Investiment) do produto;
    • Prioriza as funcionalidades conforme o valor de negócio;
    • Ajusta as funcionalidades e suas prioridades a cada Sprint;
    • Aceita ou rejeita os resultados.
  • Scrum Master
    • Responsável pela aplicação dos valores e práticas do Scrum;
    • Remove impedimentos;
    • Assegura que a equipe está totalmente funcional e produtiva;
    • Permite a cooperação entre os diversos papéis e  funções;
    • Protege o time das interferência externas.
  • Time
    • Grupo formado, preferencialmente, por 5 a 9 pessoas;
    • Deve ser multifuncional;
    • Preferencialmente, dedicado única e exclusivamente ao projeto;
    • Auto-gerenciado.

A engrenagem do Scrum funciona de maneira a proporcionar rápida resposta a mudanças. Observe que primeiramente é concebida uma visão do problema existente. A partir dessa visão o Product Owner constrói o Backlog do Produto, o qual irá conter  tudo o que é necessário para desenvolver e lançar um produto com sucesso. Trata-se de “uma lista de todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para versões futuras” [SCHWABER, 2009]. O Backlog do produto é formado por User Stories ordenadas por prioridade. Ele nunca está completo: evolui à medida que o produto e o ambiente em que ele será usado evoluem.

Figura 1 – A engrenagem do Scrum.

Fonte: Blog Gestão de Projetos Ágeis

Após a definição e priorização do Backlog do Produto, o próximo passo é o Planejamento da Sprint. Sprint nada mais é que uma iteração do projeto. Em um primeiro momento dessa reunião é decidido o que será feito na Sprint, mais conhecido como Sprint Backlog. Em seguida, o Time deverá entrar em um consenso sobre como desenvolverá essa funcionalidade. Cabe somente ao Time a decisão de quanto do Backlog ele deve selecionar. Somente o Time pode avaliar o que ele é capaz de produzir durante a Sprint. As user stories devem ser escolhidas baseando-se nas prioridades definidas pelo Product Owner e no prazo escolhido para essa iteração. Essas iterações são contínuas até que todo o Backlog do Produto tenha sido produzido. Podem ter duração entre duas e quatro semanas e devem ser acompanhadas pelas reuniões diárias. Essas reuniões devem ser conduzidas pelo Time, ter duração máxima de 15 minutos e ocorrerem sempre no mesmo horário e local. Durante a reunião diária, cada membro do Time deve explicar:

  • O que ele realizou desde a última reunião diária;
  • O que ele vai fazer antes da próxima reunião diária; e
  • Quais obstáculos estão em seu caminho.

As reuniões diárias servem para melhorar a comunicação, eliminar outras reuniões, identificar e remover impedimentos para o desenvolvimento, ressaltar e promover a rápida tomada de decisão e melhorar o nível de conhecimento de todos acerca do projeto. Vale ressaltar que o Scrum Master ensina o Time a manter essa reunião com curta duração, reforçando as regras e garantindo que as pessoas falem de forma rápida e objetiva.

Após o término de cada Sprint deverá ser feita a Revisão da Sprint, onde o Time deverá apresentar o que foi feito (produto potencialmente utilizável) e validar com as partes interessadas. Obtém-se assim, entrega de valor ao cliente com uma maior frequência, num menor espaço de tempo. O Time também deverá discutir o que correu bem durante a Sprint, quais os problemas enfrentados e como eles foram resolvidos. A Revisão da Sprint fornece entradas de extremo valor para as próximas reuniões de Planejamento de Sprints.

A Retrospectiva da Sprint é o passo seguinte e deve ocorrer antes da próxima reunião de Planejamento da Sprint. Durante essa retrospectiva o Scrum Master encoraja o Time a revisar seu processo de desenvolvimento, de forma a torná-lo mais produtivo para a próxima Sprint. Neste momento deve ser inspecionado como correu a última Sprint, em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas. Ao final dessa etapa o Time deve ter identificado medidas de melhorias factíveis que deverão ser implementadas na próxima Sprint.

Por fim é válido ressaltar a importância da ferramenta Gráfico de Burndown, a qual nos fornece inúmeras possibilidades, tais como:

  • Permite medir o progresso e velocidade do time.;
  • Apresentar a quantidade de trabalho restante;
  • Ser personalizável, a depender da necessidade do time;
  • Permite avaliar riscos no projeto.

Portanto, vimos como a engrenagem do Scrum funciona de forma simples e objetiva, atacando os principais ideais defendidos pelo Manifesto Ágil: mais indivíduos e interações do que processos e ferramentas; mais software em funcionamento do que documentação abrangente; mais colaboração com o cliente do que negociação de contratos; e responder a mudanças mais facilmente do que seguir um plano. E lembre-se: o Scrum é o seu parceiro e não o seu chefe! Ele lhe fornece suporte (técnicas e ferramentas) para produzir produtos com qualidade mais rapidamente. Jamais ele irá lhe dizer como construir seu produto ou serviço! O leitor que deseja se aprofundar mais no assunto e conhecer mais detalhes sobre esse framework, basta acessar a seção Scrum no menu através da opção Documentos > Metodologias Ágeis ou através desse link.

SCHWABER, Ken. Guia da Scrum. ScrumAlliance, 2009.
GOLDENBERG, Michel. Curso Certified Scrum Master. GoToAgile!, 2010.