Construa produtos que as pessoas adorem, mais depressa: Encontrando a próxima funcionalidade mais importante com a Priorização por Objetivos
O backlog tradicional já não nos serve mais. Ele falha em descrever o por quê de algo ser importante e não deixa eventuais dependências claras. Ele acaba sendo um lugar para listar funcionalidades futuras “para que não sejam esquecidas”. O fato é: se algo é suficientemente importante, não será esquecido. Nós acabamos adicionando funcionalidades ao backlog simplesmente porque podemos e isso representa problemas na gestão do escopo, a menos que tenhamos uma forma de justificar seu valor.
Nos dias de hoje, conceber um bom produto rapidamente é a chave para o sucesso tanto de startups quanto de grandes empresas. Ao construir novos produtos (ou melhorar produtos existentes) obter feedback rápido das funcionalidades mais básicas dos recursos de maior valor é fundamental. Story maps, épicos e todas estas camadas de planejamento podem ser úteis em determinados contextos, porém um time que está entregando de forma contínua utilizando testes de usuário e design contínuo precisa de algo que permita uma experimentação mais rápida, sem comprometer a qualidade das estórias de usuário (a não ser quando necessário).
#1 Decida os seus objetivos
Esboce um conjunto de objetivos de negócio de comum acordo com os stakeholders chave. Estes objetivos devem ser específicos o suficiente para que possam ser testados frequentemente e seu progresso medido. Inicialmente, eles serão identificados através do entendimento dos objetivos de negócio, necessidades dos usuários e de como o negócio atende às necessidades destes usuários visando atingir os objetivos. Foque no resultado desejado em vez da solução. Claro, é mais fácil falar do que fazer. Assegure-se de priorizar cedo e esteja preparado para mudar de ideia se a base de sua priorização mudar.
#2 Crie um Quadro de Objetivos
Para se chegar a um modelo que é ao mesmo tempo incremental (para suportar o desenvolvimento iterativo) e diversificado (para suportar experimentação), e manter o alinhamento com os objetivos de negócio, nós elaboramos algo chamado de “Quadro de Objetivos”. Este quadro é uma matriz onde as colunas são os objetivos priorizados (você pode representá-los como hipóteses, por exemplo) e as linhas são níveis de refinamento. É importante lembrar que a força do quadro de objetivos está na facilidade de experimentar e pivotar. Nós obtivemos sucesso utilizando três níveis de atributos de consumidor/produto descritos no Modelo de Kano:
Prover (Básico) – Este é basicamente um experimento para validar uma ideia, com a mecânica elementar e pouco mais. Faça apenas interações simplificadas e sem muita estilização se é isso que você quer validar. É pouco provável que você disponibilize algo neste nível para uso geral, mas... quem sabe?
Satisfazer (Expectativa) – Este nível inclui as melhorias necessárias para tornar uma funcionalidade vendável. Ele indica ainda até que ponto suas funcionalidades serão desenvolvidas. É tipicamente o resultado de algumas estórias que foram escritas baseadas em rápido feedback para refinar algo que foi validado no nível “básico”.
Superar (Extraordinário) – Este é o nível onde se vence a competição. Ele é reservado para as funcionalidades centrais do produto ou coisas que você acertou na mosca em iterações passadas e que merecem mais investimento. Ao longo do tempo, as estórias neste nível se tornam “básicas” e outras funcionalidades atrativas devem ser adicionadas.
O Quadro de Objetivos, por natureza, é extremamente dinâmico, portanto é mais fácil de o manter em uma versão eletrônica. Ao traduzir nosso cenário do mundo real para uma ferramenta, nós quisemos começar da maneira mais simples possível e o Mingle permitiu isso. Para representar as estórias em uma matriz de objetivos por nível, nós criamos atributos para os tipos de nível (assumindo que estes são estáticos), uma árvore de “objetivos” (um tipo de card) e “stories” (outro tipo de card). O quadro multidimensional tratou do resto:
A cor de cada card representa um estado. Quanto mais escuro o tom de verde, mais próximo de pronto está. Desta forma o time pode utilizar este quadro a maior parte do tempo, precisando apenas de um quadro mais tradicional no estilo Kanban como um quadro secundário para alterar o estado dos cards.
#3 Mapeie suas estórias com seus objetivos
Uma vez que seus objetivos iniciais estão definidos, comece a escrever estórias para atingi-los. Lembre-se de focar primeiramente no nível “necessário” – as funcionalidades básicas que irão possibilitar validar o conceito. Não há problema em escrever estórias através dos níveis de refinamento, mas certifique-se de classificá-las no nível certo. Seja agressivo e sempre busque a quantidade ideal de trabalho possível em cada nível. Tire vantagem do fato de haver uma quebra natural entre cada nível para fazer suas estórias do menor tamanho possível e lembre-se de que você pode planejar releases em cada ponto.
Ao adicionar estórias, garanta que apenas aquelas que devem ser colocadas na metade superior esquerda de seu Quadro de Objetivos sejam adicionadas. Não há razão para adicionar escopo para ajudar seu produto a se sobressair em objetivos não prioritários. Se você algum dia desenvolver suficientemente seu produto para que estas estórias sejam a próxima coisa mais importante, você terá adquirido tanto conhecimento novo, que qualquer coisa escrita antes do tempo irá se tornar obsoleta.
#4 Meça o progresso e incorpore feedback
Finalmente, você pode gerar um simples gráfico de progresso indicativo de seu avanço em direção aos objetivos. Aqui, quanto mais escuro o tom de verde, mais perto da produção uma determinada estória está.
Depois que cada nível de um objetivo é concluído a equipe pode desenvolver testes funcionais para ele, fazer o deploy para produção utilizando feature toggles e executar sessões de testes com usuários. Isto permite ao time obter feedback rapidamente e iterativamente construir uma base de conhecimento sobre o software sendo desenvolvido.
O Quadro de Objetivos pode ser uma alternativa ao backlog tradicional por ser uma forma de documentação viva que oferece critérios específicos para controlar o escopo sendo adicionado ao projeto. Ele se torna mais eficaz em equipes que estão prontas para iterar e entregar rapidamente, mas é simples o suficiente para que seja testado e adaptado para se encaixar em outros ambientes. Você pode obter o template do Mingle de priorização por objetivos (descrito neste blog) aqui. Se você tentar, por favor nos envie feedback nos dizendo como foi sua experiência!
Obrigado a Vini Andrade e Alexandre Klaser por sua ajuda com a tradução
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.