Arquivos do Blog

Project Model Canvas: a alma do projeto

Introdução

Em um mundo globalizado, onde as organizações buscam constantemente ampliar seu market share e entregar valor mais rapidamente aos seus clientes, o ritmo das mudanças se torna mais intenso. Dessa forma, o volume de projetos tem um crescimento acima do normal, justificado pela necessidade de implementar as mudanças, e que provavelmente irá ocasionar o envolvimento de um maior número de interessados. Essa reação em cadeia torna o ambiente de negócios mais complexo e a vida do gerente de projetos mais árdua.

Crescimento do número de partes interessadas.

Leia o resto deste post

Anúncios

Matriz RACI: a matriz de responsabilidades

Quando pensamos em gerenciar recursos humanos alocados em um projeto, logo nos vem a mente os papéis e as responsabilidades a serem definidos. Esse é um passo fundamental para o desenvolvimento das mais diversas  atividades planejadas para o projeto.  Assim, a matriz RACI surge como uma importante ferramenta de apoio no gerenciamento dos recursos humanos e das comunicações. RACI é o acrônimo em inglês para: Responsible, Accountable, Consulted e Informed. É utilizada para “formalizar os papéis e responsabilidades durante um projeto, programa ou mesmo qualquer mudança organizacional. Este modelo é apresentado como melhor prática (best practice) no PMBOK© e pelo ITIL© v3” [1].

Nesta matriz são definidos os seguintes papéis:

  • Responsible – responsável pela execução da tarefa. Podem ser uma ou mais pessoas designadas a executarem a tarefa.
  • Accountable – prestador de contas. Haverá somente uma pessoa designada para esse papel.
  • Consulted – consultor da tarefa. São pessoas com maior “know how” sobre determinados assuntos, responsáveis por fornecerem informações úteis para a conclusão da tarefa. A comunicação com esse grupo será de duas vias.
  • Informed – pessoas informadas sobre o progresso e status da tarefa. A comunicação com esse grupo será de mão única.

Observe abaixo um exemplo de matriz RACI:

Figura 1 – Matriz RACI [2].

Com a adoção dessa matriz fica claro na organização quem é o responsável pelo processo e quem são os demais envolvidos.  A fim de evitar confusões, é recomendado ter apenas um papel atribuído a cada pessoa em cada atividade. Entretanto, muitas vezes o prestador de contas da atividade também pode ser o responsável pela sua execução.

Há somente uma regra para a criação da matriz RACI: cada atividade deve possuir apenas um prestador de contas. Mas, segundo [1], existem algumas boas práticas a serem seguidas:

• Tente limitar o número de pessoas executores em uma atividade para um – mais do que isso e provavelmente haverá a duplicação de trabalho. Caso tenha mais de uma pessoal executora, pense em dividir a atividade.
• No mínimo tenha uma pessoa responsável e uma pessoa executora atribuídas para cada linha da matriz.

Durante o processo de criação da matriz pode surgir a seguinte dúvida: se o Analista X faltar no dia da entrega da atividade 1, quem ira realizar atividade? Ou seja, o RACI é bonito no papel, porém na prática possui alguns gaps.

Mesmo a atividade apresentando mais de um responsável, não fica claro quem irá substituir o recurso ausente. Sendo assim, foi desenvolvido uma variante da matriz RACI que apresente o papel BACKUP, responsável por substituir algum recurso. Observe abaixo:

Figura 2 – Variação da Matriz RACI [1].

Desta maneira, todas as atividades possuem duas ou mais pessoas para executar a atividade na falta do executor oficial.

A matriz RACI, pode apresentar outras variações a depender das necessidades de controle. Segundo [3], a tabela abaixo apresenta alguns exemplos de códigos de responsabilidades que você poderá utilizar.

A Aprovação das entregas
C Criador, ou seja, o responsável pela criação da entrega. (Normalmente há somente uma pessoa responsável pela criação da entrega, entretanto poderá haver mais pessoas envolvidas. Neste caso as pessoas poderão ser representadas da seguinte forma:)C1 Responsável primárioC2 Responsável suplente
I Fornecer Informações
N

Notificar quando uma entrega for concluída

M

Gerenciar as entregas. Por exemplo: um bibliotecário, (ou a pessoa responsável pelo repositório de documentos)

“Matrizes RACI são fáceis de criar e poderosas para definir/esclarecer os papéis e responsabilidades de um projeto entre pessoas de diferentes partes da organização” [1]. Isso facilita a comunicação e o gerenciamento das expectativas dos stakeholders.

[1] KUMASAKA, Fernando. Matriz de RACI ou RACIB? Parada pro Café.  em <http://www.paradaprocafe.com.br/2010/10/28/matriz-de-raci-ou-racib/>. Acesso em 30 de Abril de 2012.

[2] ANGOTTI, Kleber. Matriz RACI. Disponível em <http://www.angotti.com.br/index.php?option=com_content&view=article&id=28:matriz-raci&catid=2:gp-informacoes&Itemid=2>. Acesso em 30 de Abril de 2012.

[3] Gerentes de Projetos. Matriz de responsabilidades (RACI). Disponível em <http://projetosbrasilce.blogspot.com.br/2009/11/matriz-de-responsabilidades-raci.html>. Acesso em 30 de Abril de 2012.


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.