É incrível como ficamos criativos quando estamos discutindo ideias para um produto de software. A quantidade de funcionalidades que poderíamos adicionar ao backlog certamente tomaria todo o quadro. E mais outro quadro cheio de funcionalidades poderia ser preenchido à medida que cada um fosse interagindo com suas partes no projeto, ao imaginar soluções para as dificuldades, ao encontrar situações inusitadas em casos extremos, ao pesquisar concorrentes, ao interagir com o público nas pesquisas de UX… O mundo é cheio de soluções ainda não implementadas!
Existem formas bem interessantes de limitar as funcionalidades para obter um produto que estimule mais os usuários. Mas nem sempre é fácil remover funcionalidades da lista.
Algumas equipes são forçadas a fazer de tudo para fazer todas elas, incluindo aumentar a quantidade de pessoas na equipe, aumentar a carga horária, reduzir a qualidade das entregas, e até aumentar o prazo para entrega. E é por isso que os projetos de software falham. Essas atitudes nem sempre trazem benefícios, e podem levar a menos concentração, mais dispersão, menos qualidade, trazem prejuízos para o usuário final e prejudicam o desenvolvimento a médio e longo prazo. Simplesmente entregar mais funcionalidades mais rápido não significa sucesso para o produto.
Portanto, o melhor que podemos fazer é separar as mais importantes para fazer primeiro, e ir descobrindo com o tempo se as outras funcionalidades continuam interessantes.
Então, seguem três formas para priorizar as funcionalidades:
1. Poderação por pesos relativos
Com essa forma de priorização, a prioridade deve ser dada para as funcionalidades que trazem o maior valor ao produto com o menor custo de implementação:
Prioridadefunc = Valor%func / Custo%func
O Valor% de cada funcionalidade é calculado levando em conta dois fatores: primeiro, a funcionalidade trará algum benefício que será agregado ao produto; segundo, caso não seja implementada, a funcionalidade fará falta e trará uma penalidade ao produto.
Valor%func = (benefíciofunc + penalidadefunc) / ∑(benefícios + penalidades)
O Custo% de cada funcionalidade é calculado levando em conta os pontos das estimativas de tamanho.
Custo%func = custofunc / ∑(custos)
Então, são priorizadas as funcionalidades com maior benefício e/ou maior penalidade com menos custo.
2. Valor e Risco
Desenha-se um gráfico de risco versus valor. Cada funcionalidade é posicionada no gráfico pelos desenvolvedores e pelo cliente. O cliente pode apontar o valor de cada funcionalidade e os desenvolvedores podem apontar o risco de cada funcionalidade. Assim, cada lado pode alterar as posições das funcionalidades em relação a um eixo de forma relativa. Em vez de perder tempo calculando o valor exato do valor ou do risco, eles são comparados no eixo.
Em seguida, são priorizadas as funcionalidades que apresentam mais risco e mais valor para o cliente. Depois, as funcionalidades com mais valor e risco menor, e por último as funcionalidades com pouco valor e pouco risco. As funcionalidades com muito risco e pouco valor devem ser descartadas ou reavaliadas.
3. Satisfação do Cliente (Modelo Khano)
Essa forma de priorização, baseada na teoria de desenvolvimento de produto e satisfação do cliente de Kano, classifica as preferências dos clientes em categorias. Cada qualidade do produto vai satisfazer o cliente de determinada forma. Algumas funcionalidades afetam diretamente a satisfação: quanto melhor for feita, mais satisfação trará, e se não for feita, trará insatisfação. Outras funcionalidades são básicas, não agradam tanto assim o cliente se estiverem presentes, mas trazem grande insatisfação e fazem muita falta quando ausentes. Outras funcionalidades são atraentes, excitantes: não fazem falta quando ausentes, mas trazem um grande diferencial quando presentes. Algumas funcionalidades não fazem diferença: podem estar presentes ou ausentes, que não alteram a satisfação do cliente.
Para descobrir em qual categoria a funcionalidade se encaixa, é preciso explicar a funcionalidade de forma objetiva para os clientes e fazer duas perguntas:
- Como você se sentiria se essa característica estivesse no produto?
◯Gostaria ◯Espero que esteja ◯Tanto faz ◯Tudo bem ◯Não gostaria - Como você se sentiria se essa característica não estivesse no produto?
◯Gostaria ◯Espero que não esteja ◯Tanto faz ◯Tudo bem ◯Não gostaria
Então, a funcionalidade é colocada em um quadro como o mostrado abaixo. Se, por exemplo, as respostas fossem que os clientes gostariam que a funcionalidade estivesse presente, e que não gostariam que ela estivesse ausente, ela ficaria no quadrinho D.
| Disfuncional (se ausente) | ||||||
| Gostaria | Espero | Tanto faz | Tudo bem | Não gostaria | ||
| Funcional (se presente) |
Gostaria | Q | E | E | E | D |
| Espero | C | I | I | I | B | |
| Tanto faz | C | I | I | I | B | |
| Tudo bem | C | I | I | I | B | |
| Não gostaria | C | C | C | C | Q | |
De acordo com a posição no quadro, a funcionalidade é classificada como:
- D – desempenho: influencia diretamente na satisfação
- E – excitante: não faria falta, mas agrada se estiver presente
- B – básica: faria falta se ausente
- I – indiferente: não faria tanta falta e não agradaria tanto
- C – contrária: desagrada o cliente
- Q – questionável: as respostas são contraditórias
O interessante é que as qualidades dos produtos são diferentes de acordo com o público alvo. Um ar-condicionado no carro em um país quente é quase uma característica básica, mas em um país frio espera-se que o carro tenha aquecedor. Além disso, as características mudam com o tempo: as qualidades que hoje são excitantes acabarão se tornando básicas no futuro.
As prioridades seriam dadas para as funcionalidades de desempenho (D), excitantes (E) e básicas (B), pois influenciam mais a satisfação dos clientes. Essa classificação da satisfação prioriza as funcionalidades que agradam os clientes, e não aquelas que o supervisor ou gerente acha que seria bom ter no produto.
Matruskan 