Como levantar e priorizar Features com seu time

Durante o desenvolvimento de um app mobile com o Fabio Gushiken, um dos designers aqui na Caelum, desejavamos criar sistema de cartão de fidelidade virtual pra substituir o cartões de fidelidade impresso, que costumam aparecer em cafés. Tipo esse abaixo de um café em Moema:

No verso do cartão tem a quantidade de pontos que você precisa ter pra ganhar um café. E pra preencher os pontos você precisa tomar cafés.
DSC_2300

Só vou mostrar a frente do cartão porque achei ela muito bonita . 🙂
DSC_2299

Eu e o Fabio pensamos que seria simples relacionar as features dado que é app bem enxuto. Mas com o passar de algumas horas percebemos que estávamos fracassando em um tarefa aparentemente simples.

Quando nós falhamos em uma missão que achávamos que era simples. O próximo passo é procurar entre nosso amigos pra ver se alguém já teve a mesma dificuldade. Infelizmente ninguém tinha uma ideia de como resolver esse problema.

Aí eu me lembrei que o aluno de UX, Diogo Riker da turma de Manaus na FPFTech tinha me passado por email um PDF interessante de como levantar e priorizar features. Ah! Ele também tem um post sobre priorização: A Arte da Priorização.
Que por coincidência o autor do PDF escreveu um livro na Casa do Código. O livro é o Direto ao Ponto de Paulo Caroli com um capítulo de feature que tem um conteúdo bem parecido com o do PDF. 🙂

Começamos a ler o capítulo de feature e gostamos muito da ideia. Mas como toda ferramenta é criada pra resolver um problema pessoas ou de um determinado time. Acabamos pegando a ideia do Caroli e modelando pra nossa necessidade. O resultado disso foi dois Gamestormings: brainstorm de features e Priorizando feature.

O que é uma Feature?

A descrição de um interação ou ação com o sistema é o que chamamos de feature. Por exemplo, escrever uma mensagem pra compatilhar uma ideia, pensamento ou conteúdo relevante dentro do Twitter é um feature que chamamos de tweet.

Toda feature (funcionalidade) tem que atender um objetivo (necessidade) que seja claro e relacionado a uma persona ou proto-persona do seu sistema. Por esse motivo, antes de sair pensando nas features do sistema, precisamos entender quem é o nosso público alvo.

Gamestorming – Brainstorm de features

Objetivo

Realizar um brainstorm de features classicados por proto-persona e objetivo.

Ambiente

1. Proto-personas do seu produto;
2. Cartolina;
3. Canetinha azul, verde e preta;
4. Post-its.

Regras

– Duração de 20 minutos.

Passo a passo

1. Classificar as proto-personas no eixo Y. A mais prioritárias ficam no top;
2. Cada integrante do time define um objetivo pensando nas proto-personas;
3. Classificar os objetivos no eixo X. O mais prioritários ficam mais a esquerda;
4. Brainstorm de features pra solucionar os objetivos pensando em cada proto-persona escrita em post-its e colado conforme exemplo abaixo:

objetivos-proto-persona

Depois de levantar todas as features que o seu time conseguiu pensar até o momento pro produto. O próximo passo é priorizar as features.
Em alguns cenários corporativos a priorização de feature é definida somente pelo cliente. A opinião do cliente realmente tem o seu valor. Mas é importante levarmos em consideração 4 pontos: valor pro usuário, valor pro negócio (visão do cliente), esforço técnico e MVP.

Valor pro usuário:

Tem o objetivo de entender qual feature vai entregar mais valor pro cliente, e deixar ele mais feliz. Esse é o momento de entrarmos no modelo mental do usuário, pra classificar quais features entregam um valor pequeno, médio ou grande pro usuário.

Valor pro negócio:

Utilizado pra priorizar qual feature entrega mais resultado financeiro pro nosso cliente. Importante classificar junto com nosso cliente quais features tem um valor alto, muito alto ou altíssimo pra ele. Pro cliente nunca vai existir um funcionalidade de baixo ou médio valor.

Esforço técnico:

É o valor que deve ser levantado com o time técnico do sistema. Com o objetivo de classificar quais features tem um esforço pequeno, médio ou grande pra equipe que está criando o produto.

MVP (Minimum Viable Product)

É uma versão com o mínimo de features que possa ser colocado em produção, agregando valor pro usuário e negócio. Gosto da imagem abaixo pra explicar MVP:

dS-D6wj

Agora que entendemos todos os passos podemos seguir pro gamestorming de priorização das feature.

Gamestorming – Priorizando features

Objetivo

Priorizar tarefas levando em consideração o valor pro usuário, valor pro negócio (visão do cliente), esforço técnico e MVP.

Ambiente

1. Features levantadas;
2. Cartolina;
3. Canetinha azul, verde e preta;
4. Bolinhas de 2 cores (azul e verde).

Regras

– Duração de 30 minutos

Passo a passo

1. Criar o canvas conforme imagem abaixo;
2. Priorizar as features no eixo x com base no esforço técnico. Quanto mais pra direita maior o esforço;
3. Priorizar as features no eixo y com base no valor de pro negócio. Quanto mais pro topo maior o valor;
4. Marque as features com as bolinhas azuis levantando em consideração o valor pro usuário: 1 bolinha (baixa), 2 bolinhas (médio) e 3 bolinhas (alto);
5. Marque quais são as features necessárias pro MVP com as bolinhas verdes.

priorities

Depois só separar as features com as bolinhas verdes. E partir pro processo de desenvolver o produto.

Lembre-se! Que essa ideia não é minha, 90% dos dois gamestormings saiu do livro Direto ao Ponto de Paulo Caroli. Realmente vale a penas ler o livro dele é muito mais completo do que este post. 🙂

Gostou do fluxo dos dois Gamestorming?
Você utiliza algo diferente pra levantar e/ou priorizar suas features?

9 Comentários

  1. Danilo Siqueira 25/02/2016 at 15:33 #

    Muito, muito bom!!!

  2. Jana 25/02/2016 at 16:21 #

    Muito show! Parabéns!
    Como sugestão, ao conversar com o cliente, evitar o termo baixa, média e alta, novamente toda feature é alta para o cliente (rs). Recomendo uso do termo alto, bastante alto e altíssimo. É algo tão sutil, mas faz uma diferença.

    Vou tentar aplicar no próximo MVP.

  3. Diogo Riker 25/02/2016 at 17:31 #

    Muito bom, Marco.

    Uma dúvida, quanto tempo durou mais ou menos esse processo todo de reconhecimento de levantamento de requisitos e suas priorizações?

    Forte abraço!

  4. Marco Bruno 26/02/2016 at 14:31 #

    Boa Jana. O Paulo Caroli também recomenda no livro Direto ao Ponto pra utilizar essa mesma comunicação com o cliente.

    Depois conta pra gente como foi sua experiência. 🙂

  5. Marco Bruno 26/02/2016 at 14:34 #

    Obrigado Diogo.

    O tempo de cada passo foi:

    30 minutos pra montar as proto-personas;
    20 minutos pro gamestorming de brainstorm de features;
    30 minutos no gamestorming de priorizando features.

  6. Jhonatan Morais 15/03/2016 at 14:05 #

    Fala Marco beleza? Eu fui um feliz aluno do curso formação Java da Caelum em Brasilia, e desde então fiquei maravilhado com a supremacia do ensino e também com a qualidade de seus instrutores. Um salve para o Professor Guilherme!

    Desde então sempre que posso sigo a Caelum em tudo que ela faz, e por isso em meu pensamento se uma pessoa trabalha na Caelum, só por estar lá, pra mim ela já e F#D@!. Então parabéns. Mas com a melhor das intenções do mundo vou te falar isso. Achei seu artigo “Corrido demais” eu li ele duas vezes e ainda sim não encontrei as respostas para as lacunas que foram abertas, além de uma série problemas que mostram que o texto não foi revisado antes de sua publicação.

    Considere a análise abaixo, pontuada por paragrafos:

    Paragrafo 1:
    Frases como as abaixo quebram a construção da ideia na cabeça do leitor, pois a disposição de seus elementos não colabora para a apresentação do tema principal, veja:

    “Desejávamos substituir cartões de fidelidade” – Me abriu a ideia que vocês queriam criar OU uma solução nova para ‘Cartões de fidelidade’ OU talvez apenas criar um ‘Cartão de Fidelidade’ que fosse virtual. Enfim o artigo acabou e eu fiquei sem saber o que foi que vocês criaram/Fizeram…

    “Tipo esse abaixo de um café em Moema”: – Eu sei que logo abaixo (no artigo) estão as imagens do cartão, mas como primeiro li e depois vi as imagens imaginei algo em baixo de uma xícara de café. Parece bobagem, mas é verdade. Por exemplo, um ovo rosa. Opa… Provavelmente você deve ter desenhando em sua mente a imagem de um ovo rosa. Isso que ocorreu comigo. Palavras geram imagens na cabeça do leitor.

    Paragrafo 2 e 3:
    O tempo das ações não está de acordo com os elementos verbais que descrevem os fatos ocorridos, veja:

    “Eu e o Fabio pensamos que era simples relacionar as features dado que é app bem enxuto” – Mude ‘era’ para ‘seria’, coloque ‘o’ antes do ‘App’

    Observe também, neste paragrafo, o uso excessivo do termo ‘simples’.

    Paragrafo 5:
    “[…] Criada pra resolver um problema pessoas […]”
    “[…]O resultado disso foi dois[…]”

    Paragrafo 6:
    Não entendi o que você quis falar com a primeira oração “O primeiro Gamestorming e de brainstorm de feature”. – o primeiro de que? …. e o segundo? Tem terceiro? …

    Por fim, vamos utilizar um checklist para relacionar as ideias apresentadas no artigo (estrutura e ciclo de vida):

    1. O artigo iniciou com uma chamada interessante… (Joia! Foi por isso que decidir ler ele)

    2. Apresentou uma dificuldade “A”. (Perfeito!)

    3. Apresentou um exemplo real contextualizando a dificuldade “A” (Café em Moema). (Perfeito!)

    4. Fez uma propaganda bacana pra cafeteria ‘Freak’. (Normal! Quando em Moema tentarei passar por lá. 😀 )

    5. Apresentou a introdução para a técnica que resolveria o problema, (Fiquei empolgado!)

    6. Fez a introdução a um livro da casa do código (Normal!).

    7. Usou um parágrafo para descrever o que é uma feature (Acontece! Mas caberia aqui usar também um hiperlink para chamar uma definição externa, como o que foi feito com o termo “proto-persona”) .

    8. Depois apresentou um exemplo da nova técnica, sobre a perspectiva de um outro problema “B” (Gerenciador de novelas) que inclusive entrou seco no texto sem contextualização.( WTF!!! Agora pouco estava em Moema tomando um saboroso café e agora estou em casa favoritando novelas… Que loucura!)

    9. E depois em uma conclusão rapidíssima falando que “Realmente vale a penas ler o livro dele é muito […]” (Desanimei… e me arrependi de ter parado pra ler).

    Sinceramente confesso que ao chegar ao ponto 8 no fluxo acima já estava tão focado em todos estes outros pontos que desisti de descobrir “Como levantar e priorizar…” e acabei frustrado pois fiquei sem saber como funciona o novo sistema de fidelização da minha cafeteria preferida em Moema, afinal terei que usar ele quando for tomar um café lá…

    Espero que você veja estes pontos com bons olhos. Eu valorizo demais o tempo que as pessoas como vocês dedicam para compartilhar boas ideias, e por isso acho injusto apenas colocar nos comentários “parabéns pelo artigo” sabendo que este pode melhorar.

    Forte abraço campeão e sucesso.

  7. Marco Bruno 16/03/2016 at 21:27 #

    Fiquei muito feliz pela sua revisão. 🙂
    Fiz algumas alterações com base no que você comentou no post.
    Eu e o Fabio não terminamos App, mas estamos desenvolvendo o protótipo. Tá uma olhada no link abaixo que já tem 3 telas:
    https://xd.adobe.com/view/7202f19c-8308-4a47-6053-1088c50877a1/

    Estamos focado em deixar o MLP (Minimum Lovable Proof) em produção até o final do mês.

  8. Pedro Ferraz 18/03/2016 at 19:52 #

    Oi Marco, não li o texto original que o Jhonatan revisou, mas o texto atual está muito legal. Li o título, fiz uma leitura dinâmica na introdução e fui direto ao ponto (analogia ao livro… rsrs) iniciando a leitura a partir do subtítulo Gamestorming. Gosto muito das técnicas de priorização e desenvolvimento ágil, por isso leio cada ideia apresentada e tento compilar em um modelo personalizado aqui na Target Work. As ideias do artigo já me abriram a mente para algumas alterações no meu modelo e irei apresentar para a equipe na próxima semana. Depois conto se eles aprovaram. Abraço!

Deixe uma resposta