Início > Gerenciamento de Projetos, Scrum > Priorizando o desenvolvimento de funcionalidades utilizando ROI

Priorizando o desenvolvimento de funcionalidades utilizando ROI

Continuo estudando o livro “Professional SCRUM with Microsoft Visual Studio 2010” e me deparei com um conteúdo muito interessante sobre priorização de tarefas (PBIs ou Product Backlog Item).

Apenas como explicação, no SCRUM um PBI é uma funcionalidade (em inglês “feature”) à ser implementada que deve ser criada pelo “product owner”. Em um projeto temos o momento inicial aonde o product owner escreve todos os PBIs necessário para o projeto funcionar. Mas durante o andamento do projeto os PBIs podem diminuir (a partir do momento que vão sendo entregues) ou aumentar (quando surgem novas funcionalidades a serem implementadas).

O mais complicado de tudo isso é como priorizar o desenvolvimento de todos os PBIs. Nem todos os PBIs tem o mesmo benefício para o negócio. Algumas são imprescindíveis, outas necessárias, e outras “seria interessante ter” (nice to have). Por outro lado, existe a complexidade e o esforço necessário para entregar aquela funcionalidade. Um PBI pode ser imprescindíveis e de fácil desenvolvimento ou “nive to have” e de difícil implementação. Abaixo segue técnicas de como medir numericamente o que é mais prioritário em um projeto através do ROI (Return of Investiment).

ROI é uma medida que indica o valor que aquele PBI tem para o projeto. Na maioria dos projetos ele é medida em valor monetário (dólar, real, …) . Você divide o retorno (preço de venda – preço de compra) pelo investimento (preço de compra) para chegar no valor do ROI. Um valor alto de ROI é um bom investimento, enquanto um baixo valor, é um mal investimento. Controlando o valor de retorno e o valor de custo, chega-se ao ROI ideal. Se você não controlar os dois valores, nunca saberá se o valor gasto em um projeto está lhe trazendo retornos reais de dinheiro.

Na utilização de SCRUM, o product owner é responsável por definir o “business value” e a equipe técnica mede o esforço. Nessa metodologia não utilizamos dólar para medir “business value” e nem horas para medir esforço (A metodologia de medida de esforço será comentada mais abaixo). Mas é possível utilizar o ROI para mensurar relativamente o custo de cada um utilizando as métricas abaixo.

Supondo que estamos desenvolvendo um site de ecommerce e temos dois PBIs.

  • Pagamento do pedido utilizando mais de 1 forma de pagamento
    Business Value: 80
    Esforço: 13Utilizando a escala de 1 a 100 o product owner diz que esse backlog será de grande valia, pois pesquisas feitas indicam que muitos pedidos de valor alto não são fechados devido ao limite dos cartões de crédito. Disponibilizando mais de 1 forma de pagamento no mesmo pedido, as vendas aumentariam.
    Por outro lado, a sistemática para controlar o pagamento e liberar o pedido é muito complexa. A equipe de desenvolvimento coloca um valor de esforço alto para esse backlog. Dessa forma, calculamos:ROI = 80 / 13 = 6,15
  • Integrar redes sociais com o ecommece para incentivar a propaganda.
    Business Value: 30
    Esforço: 😯 Product owner acha a tarefa interessante, mas acredita que o retorno não será muito grande, e não é uma funcionalidade imprescindível para o projeto. O Business Value dele é indicado como 30.
    A equipe de desenvolvimento considera a dificuldade de integrar várias redes sociais distintas e como será arquitetado o sistema. É indicado um esforço de 8 pontos.ROI = 30 / 8 = 3,75

No exemplo acima fica claro que o primeiro PBI tem um ROI muito maior do que o segundo. Logo, tem uma  prioridade maior e será desenvolvido primeiro.

O trabalho do product owner de listar todos os PBIs e indicar o “business value” é mais simples. Apenas lendo o título das funcionalidades é possível colocar analisar quais tem um peso maior ou menor. Mas para a equipe técnica, não é tão simples. Como no exemplo acima, como chegar nos valores 13 e 8? Abaixo algumas metodologias:

Plannig Poker
Criado por Mike Cohn, a metodologia é simples e divertida de se implementar.  Parte-se do pressuposto que muitas equipes tem problemas em medir o esforço que será gasto (em horas, dias, …) para cada tarefa. Mais complicado ainda é quando existem tarefas com índices de esforço muito próximos (Ex: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, …). Como medir o esforço gasto entre os pesos 7 e 9, sendo que os dois são muito próximos. Lembrando que muitas vezes a própria equipe não sabe quanto tempo vai demorar para desenvolver uma tarefa.

Então utilizasse a um conjunto de cartas (valores) pré-definidos. Cada carta tem um valor e deve ser associado com o conjunto de tarefas que será entregue em um sprint. A maioria dos Planning Pokers utiliza a sequência de Fibonacci (1, 2, 3, 5, 8, 13, …).  Dessa forma um ítem de difícil implementação pode ter o peso 55, enquanto que um item de dificuldade parecida que deve ser entregue no mesmo sprint, só pode ter os valores intermediários (34 ou 89).

No decorrer do projeto, e com um controle do projeto, é possível medir quanto “esforço” é entregue em cada sprint e prever quais tarefas podem ser entregues nos próximos de acordo com o seu peso.

Anúncios
  1. Well
    05/07/2011 às 11:08

    Boa Gutao! Compreendi superficialmente. Nao estou atuando diretamente em projetos… mais a metrica me pareceu bastante interessante!!!

    Abs

    Wellington

    • 05/07/2011 às 13:56

      Fala Well, tudo legal?

      A metodologia tem como premissa priorizar os desenvolvimentos das tarefas de um projeto medindo cada funcionalidade pelo “Valor de negócio” vs “Tempo de execução”. Pode ser implantado em qualquer mercado, não apenas na área de TI. Se tiver dúvidas, me pergunte que nós aprofundamos a conversa!

      Abraços.

  2. 05/07/2011 às 14:59

    Fala Gutão!
    Muito interessante seu post.

    Não seria um tanto quanto comercial demais pensar apenas no ROI como forma de se avaliar o desenvolvimento de uma nova funcionalidade? Muitas vezes temos muitos benefícios não mensuráveis e que devem ser levados em conta também. O ROI pode ser pequeno, mas o ganho de “satisfação” do usuário, do funcionário, ou mesmo do cliente, por exemplo, não é tão levado em conta…

    Claro, falando de “Projetos”, sempre pensamos nos números, nas cifras gastas e no retorno que isso nos proporciona (o lucro). Mas tem horas que vale a pena também levar em conta o que está “além do lucro” não acha?

    É uma boa discussão… hehehehe

    Abraços!

    • 05/07/2011 às 20:37

      Na verdade, em última instância um usuário mais satisfeito te gera mais renda, se for um clinte, na medida em que compra mais, ou torna-se mais produtivo, se for um colaborador. Enfim, no frigir dos ovos, na última ponta a medida vira dinheiro. A diferença é que a previsão de retorno financeiro pode ser mais ou menos subjetiva, aumentando ou diminuindo o erro do cálculo de ROI.

  3. Marcio K
    05/07/2011 às 17:57

    E ai Gutão,

    Muito interessante esse artigo sobre priorizar tarefas e estimar prazos. Em um projeto que participei usávamos um método para medir o nível de dificuldades das tarefas da seguinte maneira:

    Foi aproveitado do TFS o campo Rank, e com base em uma planilha de “Nivel de Dificuldade” foi estimado o prazo em horas das tarefas.
    Ex:
    Task 0001 – Elaborar chamada de um pop-up para pagina de terceiros – Rank 06
    Task 0002 – Implementar classes de controle de banco de dados – Rank 10
    Task 0003 – Alterar caminho dos arquivos de log do sistema – Rank 02

    A planilha consistia o tempo em horas +/- da seguinte forma:

    01 a 03 – tempo médio gasto 8hrs
    04 a 06 – tempo médio gasto 16hrs
    07 a 10 – tempo médio gasto 24hrs
    11 em diante – negociável

    Um outro validador usado no TFS, era que um recurso teria em rank’s no Maximo 1 semana de trabalho ocupada, e na semana seguinte, como reza o Scrunm segue para o próximo Sprint.
    As tarefas tinha um prazo longo, justificando que a equipe de desenvolvimento era pequena, e trabalhávamos com integração com sistemas Informix-IBM, o que demandava muito tempo.

    []’s

  4. 06/07/2011 às 8:17

    Fala Rods, tudo bem!

    Realmente isso gera uma boa discussão, mas enxergo de outra forma. Vamos lá!
    Eu vejo que todo benefício/funcionalidade pode e deve ser mensurado em questão de “valor”. No post estamos falando em questão de ROI, mas não necessariamente precisa ser esse indicador. Podemos analisar o retorno de uma melhoria para um usuário do sistema. Vamos a um exemplo.

    Imagine que existe um auxiliar administrativo que trabalha com uma tela específica do sistema e sempre que tem que analisar um pedido de compra deve navegar até a página 5 do mesmo. Atualmente o sistema só permite navegar de uma em uma página, então para cada pedido ele precisa dar 4 cliques (sendo que o pedido inicia-se na página 1). Se contarmos que ele faz esse processo operacional o dia todo, ele está gastando muito tempo (e teoricamente dinheiro, já que “time is money”).
    Então o product owner sugere duas opções de melhoria na navegação da tela:

    1. Colocar uma navegação aonde seja possível navegar diretamente até uma página específica
    2. Colocar as informações necessárias na primeira página

    Independente da solução, a produtividade do profissional melhora e ele mesmo se sente mais capaz ao aprovar mais pedidos.
    Linkando com o post, o product owner tem que levar toda essa análise em conta no momento de indicar o peso do “Valor de negócio” (Business value). Inicialmente esse é um PBI simples, que seria tratado sem prioridade. Mas vemos que é muito importante essa análise.

    Agora outra coisa que deve ser mensurada de outra forma, realmente são features “intangíveis”, como por exemplo, a personalização do sistema para deixa-lo mais amigável para o usuário. Uma personalização de Skin (cor, modelo, background, etc) em um sistema trará retorno financeiro (ROI) para a empresa? Se for um sistema proprietário, como por exemplo um ERP desenvolvido internamente, provavelmente não fará diferença. Mas se analisarmos a personalização do seu Google Chrome, com certeza existe retorno. Mais pessoas vão utilizar o navegador e indicarão o mesmo. É uma forma de fazer o marketing/divulgação dos seus produtos através de serviço. Como mensurar o retorno disso? Boa pergunta! 🙂

  5. 11/07/2011 às 16:53

    Olha pessoal… o artigo saiu na E-Commerce Guide

    http://www.e-commerceguide.com.br/2011/07/priorizando-o-desenvolvimento-de.html

    Show de bola!!!

  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: