Definindo responsabilidades

No artigo sobre as diferenças entre gestão de marketing de produtos e gestão de produtos eu comentei sobre como os 4Ps do marketing (Produto, Preço, Promoção e Praça) são distribuídos entre gestores de marketing de produto e gestores de produto. Essa é uma visão macro de divisão de responsabilidades. Como comentei também naquele artigo, esses times (Marketing e Gestão de Produtos) devem trabalhar muito próximos para o sucesso do produtos que eles desenvolvem e administram. O mesmo acontece em relação aos times de Engenharia e de UX, apesar de serem funções distintas, tb devem trabalhar muito próximos com a gestão de produtos.

Essa proximidade costuma gerar algumas dúvidas do tipo “essa tarefa, quem é o responsável?” e “essa outra tarefa, quem eu preciso consultar antes de levar ela adiante?” e “para essa outra aqui, quem precisa estar junto comigo para eu conseguir concluí-la com êxito?”. Muitas vezes acabam ficando bolas divididas, onde um acha que responsável por determinada tarefa e o outro tb acha. Ou pior, um acha que o outro é o responsável e esse outro acha que o um é responsável, e ninguém faz a tarefa.

Para resolver esse tipo de situação existe uma ferramenta muito boa chamada Matriz de Responsabilidade RASCI. Esse RASCI significa Responsible, Accountable, Support, Communicated, Informed:

  • Responsible: é a pessoa responsável pela execução da tarefa, ou seja, quem tem que liderar o esforço de fazer e concluir a tarefa. Não pode existir mais de um responsável por tarefa. É aquela máxima de que cachorro com dois donos morre de fome.
     
  • Accountable: é a pessoa que responde pela tarefa, e que tem o poder de delegar para o responsável a tarefa a ser feita. Responsável e accountable podem ser a mesma pessoa. Também vale a regra de que não pode existir mais de um accountable por tarefa.
     
  • Support: são as pessoas ou equipes que trabalham junto e sob a coordenação do responsável para a execução da tarefa.
     
  • Communicated: são as pessoas ou equipes que não participam da execução da tarefa, mas que precisam ser consultadas antes ou enquanto a tarefa estiver sendo executado, pois elas podem dar inputs relevantes para a execução.
     
  • Informed: são as pessoas ou equipes que não participam da execução da tarefa nem precisam ser consultadas antes ou enquanto a tarefa estiver sendo executado, mas que precisam ser informadas quando a tarefa for concluída.

Abaixo está um exemplo de uma matriz de responsabilidade RASCI entre engenharia, UX, marketing de produtos e gestão de produtos que usamos aqui na Locaweb:

Matriz de Responsabilidade RASCI da Locaweb

Matriz de Responsabilidade RASCI da Locaweb

Como usar?

O primeiro passo é fazer a matriz de responsabilidades. Minha recomendação é preencher essa tabela juntando todas as pessoas envolvidas numa sala, assim pode-se discutir se a divisão de responsabilidade está ok para todos e se tem alguma tarefa faltando. Muito provavelmente irão surgir algumas “bolas divididas”, mas esse é um ótimo momento para discutir essas “bolas divididas” e definir quem é o responsável.

Em seguida, deve-se experimentar fazer as tarefas seguindo a matriz responsabilidade por algum tempo, tipo um ou dois meses. Depois é importante fazer uma retrospectiva para ver se está tudo certo ou se é necessário algum ajuste.

Daí pra frente o uso passa a ser automático e as pessoas não precisarão mais se referir à matriz de responsabilidades. Depois de alguns anos, ou quando surgir alguma dúvida, ou mesmo quando surgir alguma tarefa nova, é bom revisitá-la.

Pronto, todo mundo sabe o seu papel e suas responsabilidades, e agora é só partir para a execução! :-)

Livro sobre gestão de produtos

Vc gosta do tema gestão de produtos de software? Quer se aprofundar mais no assunto? Escrevi um livro sobre o assunto, dividido em 5 grandes áreas:

  • Definições e requisitos
  • Ciclo de vida de um produto de software
  • Relacionamento com as outras funções
  • Gestão de portfólio de produtos
  • Onde usar gestão de produtos de software
Capa do Livro Gestão de Produtos

Esse livro é indicado não só para quem tem software como seu core business, como tb para empresas que desenvolvem software sob demanda e empresas que não tem software como seu core business mas usam software para se comunicar com seus clientes como, por exemplo, escolas, bancos e laboratórios clínicos.

Interessou? Então adquira sua cópia hoje mesmo!

Newsletter

Se você quiser receber artigos por email sobre startup, gestão de produtos e gestão de TI, digite seu endereço abaixo e aperte enter:


Uma ideia sobre “Definindo responsabilidades

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>