Olhe tudo o que já apareceu
Abrir ordem, registrar diagnóstico, gerar orçamento, registrar decisão, controlar reparo, consultar situação, usar peças, enviar mensagens, gerar relatórios...
Se tentarmos construir tudo de uma vez, vamos demorar muito para descobrir se as decisões principais estavam certas.
Primeiro vamos separar o que é grande do que é pequeno
Pense em “acompanhar atendimento”. Isso é grande demais para virar uma única pequena entrega. Podemos quebrar em partes menores.
| Nome | Pense assim | Exemplo na Conecta |
|---|---|---|
| Épico | Um objetivo grande que ainda precisa ser dividido. | Acompanhar atendimento |
| Feature | Uma funcionalidade importante dentro desse objetivo. | Consulta da ordem pelo cliente |
| História de Usuário | Uma necessidade pequena escrita pela perspectiva de quem recebe valor. | Como cliente, quero consultar a situação da ordem para saber se houve avanço. |
| Tarefa | Um trabalho técnico necessário para construir alguma coisa. | Validar o número da ordem |
Feature é uma palavra inglesa para funcionalidade. User Story significa História de Usuário.
Uma diferença importante
“Cliente consulta a situação” fala de valor para quem usa. “Criar campo no banco” fala de trabalho técnico. Os dois podem ser necessários, mas não são a mesma coisa.
Como escrever uma História de Usuário sem complicar?
Use três perguntas: quem precisa, o que precisa e para quê?
Como atendente, quero localizar rapidamente uma ordem, para responder ao cliente sem procurar em várias fontes.
Perceba como a frase se conecta ao problema que vimos lá no começo. Ela não nasceu de uma reunião abstrata; nasceu do retrabalho do atendente.
Uma frase curta não substitui conversa
Se escrevermos só a História de Usuário e nunca mais conversarmos sobre ela, muita coisa fica escondida. Por isso algumas equipes usam a ideia dos 3 Cs:
- Card — cartão: o registro curto da necessidade;
- Conversation — conversa: o diálogo para esclarecer a situação;
- Confirmation — confirmação: como vamos verificar se aquilo funcionou.
Você não precisa decorar “3 Cs”. Basta lembrar: anotar, conversar e confirmar.
Agora temos vários itens. Onde colocamos tudo?
Precisamos de uma lista organizada do que ainda pode ser feito no produto. Essa lista é chamada de Backlog.
Backlog é uma palavra inglesa usada para indicar trabalho ainda pendente. No nosso caso, é uma lista ordenada do que pode entrar no sistema.
| Ordem | Item | Por que vem cedo? |
|---|---|---|
| 1 | Abrir ordem | Sem ordem, o atendimento nem começa. |
| 2 | Registrar diagnóstico | O orçamento depende dele. |
| 3 | Gerar e registrar decisão do orçamento | Isso libera ou impede o reparo. |
| 4 | Atualizar situação da ordem | Resolve o problema central de acompanhamento. |
| 5 | Consulta do cliente | Entrega valor visível para Ana. |
Essa ordem não é “o que parece mais legal”. Ela leva em conta dependência, valor, risco e aprendizado.
Chegamos à pergunta que realmente importa
Qual é a menor versão que já resolve o problema principal?
Não queremos uma versão enorme. Também não queremos algo tão pequeno que não sirva para nada.
É aqui que aparece o conceito de MVP.
MVP — Produto Mínimo Viável
MVP vem de Minimum Viable Product, em português Produto Mínimo Viável.
Pense assim: é a menor versão coerente que já entrega valor e permite aprender com uso real.
Mínimo não é malfeito
O MVP pode ter menos funções, mas aquilo que ele oferece precisa funcionar de forma adequada. Segurança básica, integridade dos dados e regras importantes não viram “luxo para depois”.
O que precisa existir para Ana acompanhar o notebook?
Poderia entrar no MVP
- cliente e equipamento;
- ordem;
- diagnóstico;
- orçamento e decisão;
- situação;
- consulta simples.
Poderia esperar
- pagamento integrado;
- notificações automáticas;
- relatórios avançados;
- IA de triagem.
Perceba a lógica: primeiro garantimos uma cadeia completa de valor. Depois aprofundamos.
Story Map: enxergar essa fatia de ponta a ponta
Story Map significa Mapa de Histórias. Ele ajuda a organizar as necessidades seguindo a jornada do usuário.
| Receber | Diagnosticar | Orçar | Reparar | Entregar |
|---|---|---|---|---|
| Abrir ordem | Registrar diagnóstico | Gerar proposta | Registrar reparo | Marcar entregue |
| Foto do equipamento | Anexar evidência | Enviar mensagem | Controlar peças | Registrar pagamento |
Leia a primeira linha inteira: ela percorre o atendimento de ponta a ponta de forma simples. A segunda linha acrescenta detalhes. Isso ajuda a escolher uma primeira versão sem construir “um pedaço enorme de um setor” e esquecer o resto do caminho.
E o INVEST?
Aprofundamento Algumas equipes usam INVEST como lembrete para revisar Histórias de Usuário. As letras vêm de palavras em inglês como independente, negociável, valiosa, estimável, pequena e testável.
Para começar, guarde a ideia principal: uma boa história deve ser pequena o suficiente para entender, discutir e testar.
Ready e Done, em português claro
Ready — pronto para começar
Temos informação suficiente para iniciar este trabalho?
Done — concluído
Quais condições precisam estar satisfeitas para dizer que terminou de verdade?
Um critério de aceitação verifica um comportamento específico. A definição de concluído pode incluir coisas que valem para vários itens, como revisão e testes.
Faça agora
- Escolha um problema real da Conecta e escreva uma História de Usuário ligada a ele.
- Explique com suas palavras o que é backlog.
- Olhe os cinco primeiros itens e explique por que alguns dependem dos anteriores.
- Explique o que MVP significa e por que “mínimo” não quer dizer “malfeito”.
- Monte uma primeira fatia do sistema que percorra o atendimento inteiro.
- Diga conscientemente o que ficou de fora e por quê.
O que entra primeiro
Guarde o backlog, o recorte do MVP e a justificativa das prioridades. Cada item importante deve continuar ligado à necessidade que o originou.
Checkpoint 6 — Você consegue escolher sem perder o problema?
Você consegue explicar o que deve entrar primeiro, por que entra e qual necessidade isso resolve?