Buy a Feature
Você ja pensou em comprar uma funcionalidade?
Como assim comprar uma funcionalidade? É uma nova forma das fábricas de software venderem seus serviços?
Nada disso, a “buy a feature” — que pode ser traduzido como “compre uma funcionalidade” — é uma dinâmica de priorização, muito utilizada para entender quais são as prioridades dos stakeholders para o negócio.
Consequentemente, onde for dada maior prioridade, será onde o time de desenvolvimento dedicará maior esforço e começará a desenvolver mais cedo para entregar o maior valor de negócio no menor espaço de tempo possível.
Mas agora, vamos entender como a dinâmica funciona. Começamos colocando as features a serem priorizadas em um board, planilha ou no Miro. Para o exemplo desse texto, vamos utilizar o modelo de planilha.
Colocadas as tasks, definimos um limite máximo de gasto para cada stakeholder, geralmente gostamos de disponibilizar 500$ para cada um, pois não é um número muito pequeno então os stakeholders conseguem colocar múltiplos de 5 e também não é muito grande, fazendo com que eles tenham que pensar onde realmente vão alocar cada fração do dinheiro.
Agora, cada um dos stakeholders deve começar a alocar seus 500$ em todas as tasks dispostas. Vale ressaltar que cada stakeholder teu sua própria aba e deve se ater a ela, para não se influenciar pelos valores que os demais participantes estão dando.
É importante também deixar claro que cada stakeholder deve utilizar exatamente os 500$, nem um centavo a mais e nem um centavo a menos.
Agora que todos os participantes alocaram seu capital, gostamos de antes de darmos início a discussão, complementarmos a dinâmica de buy a feature com uma breve e adaptada dinâmica de MoSCoW, onde cada um dos stakeholders responderão essas quatro perguntas:
- A funcionalidade está presente em todos os produtos da mesma categoria de mercado?
2. O produto é considerado pronto para o mercado sem essa funcionalidade?
3. O produto é considerado pronto se entregarmos essa funcionalidade como uma atualização?
4. O produto é considerado pronto se nunca entregarmos essa funcionalidade?
Tendo todas essas informações computadas, devemos procurar inconsistências muito grandes entre os valores alocados. Se um dos stakeholders colocou 100$ em uma funcionalidade e outro colocou 20$, temos que abrir o debate e entender a visão de cada um deles.
O ideal aqui não é chegar em um consenso nos valores, mas sim alinhar as expectativas dos stakeholders em relação a cada uma das tarefas.
Dando um exemplo simples, quando falamos da funcionalidade “Login”, um dos stakeholders pode ter dado nota 20$ pois entende que um login não deva ser prioridade e logo pode ser o mais simples possível e por outro lado, outro stakeholder pode ter imaginado um login por biometria e considerado isso muito importante, investindo seus 100$ nela.
Alinhar esses pontos é importante e ajuda times que estão começando a desenvolver um novo produto em toda a parte de priorização do product backlog e das sprints.
E se você quiser bater um papo sobre esse e outros assuntos, vamos adorar marcar um horário por aqui.
Se você quiser utilizar o modelo de planilha que utilizamos aqui na Inventos para facilitar essa dinâmica, é só clicar aqui.
