Planejamento Orientado a Valor

Engenharia de Software | Gerenciamento de Projetos de Software | Planejamento Orientado a Valor

Em projetos ágeis, devido a sua própria característica de incerteza, o planejamento de versões e a priorização do que será desenvolvido (backlog) é estratégica para melhorar o ROI (Return Over Investiment).

As técnicas de planejamento de ágil tem forte afinidade com o planejamento em ondas dos métodos de gerenciamento de projetos orientados a planos, porém com algumas diferenças, conforme apresentadas na figura a seguir. Veja que não é interessante antecipar todo o planejamento já que, como temos muitas incertezas, teremos grandes probabilidades de mudanças caso a antecipação seja feita. Ao invés disso, fazemos um planejamento de alto nível para identificar e planejar as releases, e posteriormente planejamos mais detalhadamente cada interação. No fluxo do framework Scrum, tudo se inicia na definição da visão do projeto.

Visão em um projeto ágil

Visão é uma clara imagem que gera uma atração emocional entre pessoas e produto. Por exemplo: quando se fala, a visão de quem escuta deve ser capaz de imaginar como será o produto.

A visão deve responder às seguintes perguntas:

• Quem irá comprar este produto?
• Quem é o cliente-alvo?
• Quem irá usar o produto?
• Quem são os usuários-alvo?
• Quais problemas do cliente (ou usuários) o produto pretende resolver?
• Qual valor o produto adicionará?
• Quais atributos o produto deve possuir para resolver estes problemas e quais garantirão o sucesso do produto?
• Como o produto pode ser comparado a produtos ou alternativas existentes?
• Quais são os pontos diferenciais deste produto?
• Qual o preço-alvo do produto?
• Como a empresa pretende ganhar dinheiro com esse produto?
• Quais serão as fontes de faturamento e qual o seu modelo de negócio? (quando aplicável)

Lembre-se de que uma boa visão de produto permanece relativamente constante, ao passo que o caminho para implementação da visão é frequentemente adaptado. Uma das técnicas bem interessantes de se iniciar a identificação e criação da visão é conhecida como Elevator Statement. Essa técnica prevê que você deve apresentar o produto que será criado em poucos segundos, como em uma viagem no elevador. Como sugestão, existe um modelo proposto. Acompanhe:

Para <cliente/público-alvo> que <necessidade do cliente/público-alvo ou oportunidade> ,  o <nome do produto> é um <categoria do produto> que <principal benefício ou razão para comprar o produto>. Diferentemente do <principal competidor ou alternativa> nosso produto <principal diferenciação>.

ATENÇÃO

Se após apresentar seu Elevator Statement não ficar claro o que é seu produto, qual o objetivo e para quem se destina, ele não está bom!

Materialização do produto

O próximo passo é materializar seu produto, mesmo sendo um software!

A técnica de Product Vision Box propõe a criação da caixa do seu software com informações como:

• Nome do Produto;
• Gráficos;
• Três ou quatro pontos-chave (benefícios) para “vender” o produto;
• Principais funcionalidades no verso;
• Principais requisitos operacionais.

APRENTA +

Para saber mais sobre as técnicas para criação de priorização de backlog, acesse os links indicados:

• Framework Scrum https://www.scrumalliance.org/

• Mind the Product http://www.mindtheproduct.com/2013/07/using-the-kano-model-to-prioritize-product-development/

• Elevator Statement http://www.flyingsolo.com.au/marketing/business-marketing/preparing-your-elevator-statement

• Priority Markets https://www.scrumalliance.org/community/articles/2009/february/priority-markets

• Agile UX http://www.agile-ux.com/2011/03/04/a-day-in-life-of-an-agileux-practitioner-vision/

• Innovation Games http://www.innovationgames.com/

ATENÇÃO

Você pode fazer essa dinâmica com o time envolvido no projeto usando caixa de sapato, cola e canetas coloridas, lembre-se de que na agilidade temos diversas técnicas Low Tech, High Touch. Observe que neste passo conseguimos identificar os principais diferenciais e as funcionalidades essenciais do futuro software, além de alinhar as expectativas dos participantes.

Após a criação da caixa do produto, podemos iniciar o Product Road Map, que apresenta as funcionalidades e características do produto (e em que versão a funcionalidade será inserida). Para essa etapa podemos usar a técnica Remember the Future, que tem como objetivo descobrir o entendimento do sucesso do cliente e iniciar a visualização do Road Map do produto/projeto. Nessa técnica, ao invés de olhar o passo a passo, você deve se posicionar no momento final desejado e “relembrar” o que foi feito para chegarmos nesse ponto.

Lembre-se: A técnica “Remember the Future” não é um jogo de adivinhação do futuro e sim uma ferramenta que nos auxilia no entendimento do sucesso do projeto/produto e como podemos atingir o objetivo final. Logo, não é plano, não é cronograma, não é determinístico!

Após a aplicação das etapas anteriores, conseguimos ter um melhor entendimento da visão do projeto e criar o Project Data Sheet, a planilha de dados do projeto. Ela deve possuir dados tais como: nome do projeto, data de início, clientes, objetivos estratégicos de início do projeto, matriz, pontos estratégicos, benefícios dos clientes, performances  e arquitetura de produtos.

Planos adaptativos

As estratégias, portfólio e produto podem ser planejadas com técnicas de gestão de portfólio, planejamento estratégico e outras conhecidas e utilizadas no mundo dos negócios, porém algumas técnicas ágeis de definição de visão (como vimos anteriormente) auxiliarão a todos a entender o que realmente é necessário para o sucesso do projeto.

Veja a figura que apresenta a cebola do planejamento estratégico em projetos orientados a valor.

Planejamento de release

O planejamento de release é uma reunião de planejamento de alto nível que trata de iterações das futuros sprints. O objetivo é planejar quais itens serão desenvolvidos, quando deverão estar prontos e quais recursos serão necessários para isso. As entregas irão ocorrer ao longo do projeto e a performance do time, assim como as ações de monitoramento e controle.

Acompanhe:

Observe que serão necessários que o Produck backlog já esteja definido e priorizado, as datas dos sprints definidas, e (se for um time já existente) a velocidade média do time.

ATENÇÃO

• As datas de início/fim das futuros sprints já devem considerar os feriados, férias de membros do time e quaisquer interrupções já planejadas.
• A formação do time impactará em todo o andamento, em projetos que temos uma restrição de tempo mais severa, a montagem de um time sênior mitiga o risco de atraso, porém impactará no custo.

Com os itens pontuados e priorizados e com a estimativa média de entregas do Time, podemos definir quantos sprints serão necessários. Por exemplo: Um projeto de 60 pontos com um time de 12 pontos de produtividade por sprint durará 5 sprints (60 / 12 = 5 ).

User story

No levantamento tradicional de requisitos partimos do princípio de que o cliente, em linguagem de negócios, identifica suas necessidades. Essas necessidades identificadas são passadas ao analista que traduz em linguagem técnica e que posteriormente são entregues aos desenvolvedores que as transforma em códigos.

Observe que neste processo temos pontos fracos, como:

• Premissas falsas podem ser geradas pelo cliente ou pelo analista
• Requisitos detalhados desnecessariamente (desperdício)

Na técnica de User Story, o dono do produto descreve o que precisa ser feito, identifica quem usará a funcionalidade e por que (ajuda a não gerar itens que não agregam valor ao negócio). Essa técnica utiliza os 3 C’s:

Cartão: Cada história é escrita em um cartão com um objetivo específico, o que permite mais clareza no que é necessário que seja desenvolvido.

Conversa: Como o cartão é uma descrição simples, ele leva a conversas com o time e com o cliente sobre a funcionalidade, o que permite um melhor entendimento sobre a percepção de valor, identifica riscos e prioridades.

Confirmação: Através das conversas com o time e clientes poderemos entender como validar o cartão e confirmar se o que o temos definido é realmente o necessário o sucesso da demanda.

As histórias também utilizam os conceitos conhecidos com INVEST:

Independente: A histórias são mais fáceis de trabalhar quando são independentes, isto é, não dependem de outras histórias para acontecerem.

Negociável: A história não é um contrato com definição de funcionalidades, ela é negociável para melhor atender as necessidades do negócio.

Valiosa para usuários e clientes: A história precisa estar associada a um valor para o usuário ou clientes, sem isso, não existe razão para ela existir.

Estimável: A história precisa ser estimável, mesmo que com alguma imprecisão, precisamos dimensionar o esforço para implementá-la.

Small (pequena): Histórias representam situações simples, com poucos personagens.

Testável: Toda história precisa ser testável. O cliente deve identificar quais seriam as condições de testes da história escrita. As condições de teste definidas pelo cliente ajudam o time a entender se a meta da história foi bem-sucedida.

Uma boa história deve responder:

QUEM? COMO? POR QUÊ?

Como um <PERFIL> eu posso /gostaria/devo <FUNÇÃO> para <VALOR AO NEGÓCIO> Ou POR QUÊ? QUEM? COMO? Com o propósito de <VALOR AO NEGÓCIO>, como um <PERFIL>, eu posso/gostaria/devo <FUNÇÃO>.

Por exemplo, uma história para criar uma panela específica:

• Como um Cozinheiro (Usuário);
• Quero panela de inox, com fundo oval e antiaderente (Funcionalidade);
• Para cozinhar um salmão (Valor de Negócio).

Outro exemplo:

• Como comprador que não tem cartão de crédito;
• Quero que o sistema suporte pagamento em boleto bancário.

Stories, temas e epics

Algumas histórias podem ser mais complexas e com uma previsão maior do que a capacidade de entrega do sprint. Essas histórias são conhecidas com epic. As epics precisam ser analisadas e revistas com o objetivo de identificar melhor seus objetivos e a sua possível decomposição em histórias menores. (Lembre-se de que as histórias devem respeitar as premissas do INVEST).

Geralmente os Epics aparecem na base do backlog do produto, pois ainda não possuem granularidade para serem implementadas.

Existem casos em que um grupo de histórias está associado a um determinado tema específico, nestes casos, no momento de priorização do backlog do produts essas histórias tendem a serem produzidas no mesmo sprint ou em sprints próximos.

ATENÇÃO

As histórias que estão agrupadas no tema não estão associadas a nenhuma regra de precedência, lembre-se de que as histórias devem ser independentes.

Priorização de backlog

A priorização do Backlog é de responsabilidade do Product Owner e está diretamente associada à melhoria do retorno sob investimento (ROI), pois quanto antes as funcionalidades mais importantes forem entregues, mais cedo gerarão retorno para o negócio. Em geral, a priorização do backlog do produto segue uma sequência lógica, conforme apresentada:

Valor: Qual a importância deste item para que o produto seja lançado? Quanto mais importante, mais no topo ele deverá estar.

Riscos: Qual o nosso grau de conhecimento sobre o item? Quais as incertezas? Identificamos os riscos associados? Em geral, quanto menos conhecemos ou de maior riscos devem ser priorizados. Quanto mais cedo falharmos, mais cedo corrigimos e obtemos sucesso.

Releasability (Capacidade para lançamento): Itens que permitam lançar mais rapidamente o produto devem ser priorizados (Minimum Marketable Feature – MMF), como veremos mais adiante.

“Dependência“: Temas e “dependências” devem ser considerados na priorização.

Priority markets

Na técnica de priorização Priority markets, simulamos um mercado, onde para cada avaliador é dado algum dinheiro virtual (Reais de desenvolvimento), que deverão ser usados ​​para licitar itens do backlog. O método é democrático, em que todos os interessados ​possuem voz no processo de priorização. Também permite transparência para que todos possam ver como ocorreu a priorização de cada item. Essa ferramenta é simples de administrar e se adapta bem a um grande número de interessados ​​e listas longas de itens do backlog, mitigando os debates sem fim em busca de um consenso para a priorização.

Geoff Watts e Jason Haines, em seu trabalho sobre Priority Markets, cita alguns comportamentos que surgem desta dinâmica, o qual os autores chamam de “A psicologia do mercado”. São eles:

1. Negociação: Os interessados ​​podem ver os lances uns dos outros e ajustar o seu lance de acordo com o mercado.
2. Negociação: Uma das partes interessadas podem “vender” seus Reais de desenvolvimento para outro dos interessados ​​para as prestações em espécie.
3. Votação tática: Com base em outros lances, uma das partes interessadas podem alocar mais ou menos Reais para determinados itens.
4. Intervenção governamental: Quando o mercado livre gera prioridades que não estão nos interesses estratégicos do projeto, o Product Owner pode intervir e alocar Reais adicionais para um determinado item. Como em qualquer mercado livre, a intervenção governamental pode ter uma série de consequências negativas: extra Reais injetados no sistema reduz o valor relativo de outros Reais, resultando em inflação; os interessados ​​podem também se sentir marginalizados por terem suas prioridades substituídas.

Theme screening

Uma outra técnica bem interessante de priorização é a Theme Screening. Para essa técnica, geralmente selecionamos de 5 a 9 critérios para avaliar o que é mais importante para o próximo sprint. Esses critérios devem representar aspectos do nosso produto que consideramos importantes para a priorização de requisitos.

Após definir os critérios, selecione um tema que servirá como base para os fatores de comparação. Lembre-se de que temas são grupos de requisitos funcionalmente ligados ou que tenham objetivos de negócio complementares. Esse tema deve ser algo que deveria entrar no próximo sprint.

ATENÇÃO

Esses critérios podem ser definidos a partir da nossa visão de produto, ou de requisitos de negócio a que desejamos atender. Exemplos comuns podem incluir itens como “Colabora para atingir a meta”, “Impacto nos processos organizacionais”, “Elimina problemas antigos dos usuários”, “Facilidade de desenvolvimento”, “Posicionamento do produto” etc.

Um fator importantíssimo a ser considerado na escolha dos critérios de análise e dos temas é que todos devem ser capazes de entender o significado de cada critério de análise e serem capazes de avaliar cada tema relativo a esses critérios.

Por exemplo, após a escolha podemos ter um quadro conforme apresentado:

Devemos agora escolher um tema como baseline (no nosso exemplo, o Tema C) , isto é, um tema que servirá de base de comparação para todos os demais temas. Procure buscar sempre um tema que tenha uma prioridade intermediária entre os temas escolhidos.

Agora, comparamos cada critério de análise com o nosso baseline, ou seja, perguntamos para os nossos envolvidos se determinado tema é melhor ou pior que o baseline em cada critério de análise. No nosso exemplo usamos + quando o tema comparativamente é melhor que o tema base para o critério, – se o tema contribui menos ou 0 se tem a mesma contribuição (Lembre-se de que essa percepção é subjetiva).

Somemos o total para cada tema e teremos uma pontuação total para o tema. Basta então ordenar nossos temas, veja como ficou a priorização de nosso exemplo.

ATENÇÃO

Existem 2 grandes riscos nessa técnica. O primeiro é a escolha de critérios equivocados, geralmente quando não foi bem desenvolvida a visão do produto. O segundo risco está associado à escolha do baseline, um com prioridade muito alta fará com que muitos temas pontuem negativo. Um baseline muito baixo fará com que muitos temas  pontuem muito alto. Assim, a escolha de um baseline intermediário na escala de prioridade é bem importante. Se errarmos na escolha do baseline poderemos criar distorções nos resultados.

Kano Model

A técnica Kano é baseada em entrevistas com os usuários e experts. Ela é bem interessante quando a opinião de todos tem o mesmo valor (diferentemente da técnica de Priority Markets, onde podemos atribuir pesos maiores para os Decision Makers). Essa técnica foi desenvolvida por um professor de gerenciamento de qualidade chamado Noriaki Kano que estudou e classificou as preferências dos clientes em 3 categorias:

1. Mandatório (Basic expectations): são características consideradas básicas que devem estar presentes no produto. A ausência delas irá frustrar o cliente mas a sua presença não irá aumentar a satisfação dele, já que o cliente espera que aquela característica esteja presente.
2. Linear (Satisfiers): são características que quanto mais, melhor, e que podem aumentar ou diminuir a satisfação do cliente. Geralmente estão ligadas à performance.
3. Desejadas (Delighters): são características que satisfazem o cliente quando estão presentes no produto, porém, caso não estejam não irão causar insatisfação.

Após a identificação das funcionalidades, realizamos questionários com grupos de 10 a 30 usuários com perfis variados, com uma pergunta funcional e outra disfuncional.

Então, utilizando-se a seguinte categorização para cada conjunto de respostas (funcional e não funcional):

No caso do exemplo, essa funcionalidade seria Desejada. Agora, agregando os resultados às funcionalidades que estamos verificando, o grau de satisfação que elas apresentam:

Com base nesse último quadro temos que a funcionalidade A é o básico que os clientes esperam ter, veja que temos 29 entrevistados que classificaram a funcionalidade A como Mandatória. Mas é preciso lembrar que, uma vez alcançado o básico, não devemos mais adicionar esforço nessa funcionalidade, pois ela não irá aumentar a satisfação do cliente. Devemos apenas mantê-la. A funcionalidade B parece ser vista por algumas pessoas como básica e por outras como “quanto mais, melhor” e a funcionalidade C é vista como um diferencial. Portanto, a prioridade seria A > B > C.

Para se manter o Product Backlog priorizado por esse modelo é necessário que todas as funcionalidades/características mandatórias estejam no Road Map (sem exceder a quantidade de esforço necessária para alcançar o básico esperado), fazer o máximo de funcionalidades/características lineares e sempre tentar deixar um espaço para as funcionalidades desejadas, pois essas podem aumentar o grau de satisfação do cliente rapidamente a seu favor.

MMF – Minimum Marketable Feature

A Técnica de MMF pode ser utilizada para priorização de seu backlog de produto e para o planejamento de versões. Seu princípio está baseado na identificação das características mínimas comercializáveis de seu produto.

Ela baseia-se no princípio de priorizar o essencial para a geração de valor, por exemplo, para o desenvolvimento de um telefone celular as funcionalidades essenciais são as de ligar e desligar e o envio de mensagens de texto, assim, essas funcionalidades devem ser priorizadas e estarem na primeira versão do produto (ou no topo do backlog de produto), ouvir música, registrar fotografias e outras podem aparecer em versões mais avançadas (base do backlog de produto). A regra de ouro é: desenvolva as características de maior valor primeiro (maximização do seu retorno).

Dica: Para simplificar o planejamento de versões, elimine dependências técnicas, lembre-se de que as histórias devem respeitar o conceito de Invest.

Referencias
SCRUM GUIDE. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf>. Acesso em: 20 jan. 2015.

Engenharia de Software | Gerenciamento de Projetos de Software | Planejamento Orientado a Valor