walkthrough

Simulação de processo com parte interessada

Requisitos que ninguém documentou surgem quando alguém que não é o autor tenta fazer a coisa: o operador instalando o serviço, o cientista procurando seus dados, o colega configurando um repositório, o mantenedor lendo um registro às três da manhã. Uma simulação de processo faz isso no papel, com uma persona nomeada e um processo concreto, antes que a mudança seja especificada. Sua saída não é um design: são perguntas para o proprietário, lacunas e exemplos de aceitação que as especificações e os testes podem usar.

Dois hábitos emprestados, com agradecimentos: entrevista de dois chapéus, o chapéu de produto (valor do usuário, metas, sucesso) e o chapéu de desenvolvedor (viabilidade, segurança, casos extremos), como faz o skill Feature Forge (licenciado MIT) por jeffallan; e marcar o que uma parte interessada simulada "disse" como de menor confiança do que o que uma real disse, como fazem os skills de elicitação de requisitos da melodic-software.

Entradas

Combine estas com o usuário antes de simular e escreva-as no topo da saída:

1. A persona. Quem são, o que querem deste processo, o que sabem e não sabem, o que têm em sua máquina e o que nunca leriam. Prefira o papel de uma pessoa real no instituto a um arquétipo; prefira as respostas de uma pessoa real aos seus palpites quando puder perguntar.
2. O processo. A coisa que estão tentando fazer, desde o primeiro passo até o momento em que consideram concluído. Exemplos: instalar o rastreador em um servidor; encontrar a medição da semana passada no índice; adicionar um novo formato de arquivo como uma coleção externa; iniciar um novo repositório para desenvolvimento com agentes; ler o registro de rastreamento após uma execução noturna.
3. O que existe. Os documentos, códigos, comandos e páginas que a persona encontraria, para que a simulação teste a realidade e não um plano. Leia-os como a persona leria: na ordem em que os encontrariam, pulando o que pulariam.

A simulação

Percorra o processo um passo de cada vez, nos sapatos da persona. Para cada passo, escreva:

• O que fazem, concretamente: o comando digitado, a página aberta, o arquivo lido, a pessoa perguntada.
• O que precisam saber naquele momento, e se o que existe lhes diz.
• O que dá errado aqui na prática: a falha silenciosa, a mensagem enganosa, a escolha sem padrão, o passo que precisa de direitos que não têm, a espera sem feedback.
• A pergunta que fariam ao proprietário se pudessem, em suas palavras.

Em seguida, troque de chapéu duas vezes ao longo de toda a simulação: com o chapéu de produto, pergunte o que a persona queria e se o processo entrega isso, como é "concluído" para eles, do que reclamariam; com o chapéu de desenvolvedor, pergunte o que é inviável, inseguro, lento em escala ou frágil na ordem dos passos.

Onde a simulação chegar a um ponto que os documentos não cobrem, não invente a resposta: registre como uma pergunta, e se você teve que assumir algo para continuar, diga e marque o resto da simulação como baseado nessa suposição.

Subia um nível quando um passo revela algo geral (cinco porquês): uma mensagem confusa é um passo; "a ferramenta nunca diz o que fará antes de fazer" é um requisito.

Saída

Escreva a simulação nas notas de design do projeto se ele as tiver (por exemplo design/walkthroughs/<persona>-<processo>.md), caso contrário em docs/walkthroughs/, e dê um breve resumo na resposta. Modelo:

# Simulação: <persona> <faz processo>

Persona: <quem, objetivo, conhecimento, ambiente>. Confiança: <simulada | baseada em entrevistas com ...>.
O que existe: <documentos, códigos, comandos lidos>.

## Passos
1. **<passo>.** Faz: <...>. Precisa saber: <...>. Dá errado: <...>. Perguntaria: "<...>".

## Chapéu de produto
<o que queriam, o que é "concluído" para eles, do que reclamariam>

## Chapéu de desenvolvedor
<inviável, inseguro, lento, frágil>

## Perguntas para o proprietário
- <pergunta, nas palavras da persona, com o passo de onde veio>

## Lacunas
- <requisito, comportamento ou documento que não existe; o passo que precisa dele>

## Exemplos de aceitação
- Quando <situação concreta>, então <resultado observável>.   (pronto para um cenário de especificação ou um teste)

Regras

• Diga quais partes são simuladas. Uma simulação feita por um agente encontra as lacunas que um colega cuidadoso encontraria; ela não sabe o que a persona real valoriza. Passe as perguntas para uma parte interessada real onde uma existir e atualize a linha de confiança.
• Fique nos sapatos. Se você sabe como o sistema funciona, a persona não sabe; escreva o que eles veem, não o que você sabe.
• Concreto sobre geral. "O operador executa modama-crawler crawl e não vê nada por duas horas" é uma descoberta; "feedback poderia ser melhorado" não é.
• Perguntas, lacunas e exemplos são a entrega. Não projete a correção aqui; o proprietário decide o que se torna um requisito.
• Considere um par de olhos novos: para uma ferramenta que existe, um sub-agente recebendo apenas a persona, o processo e os documentos voltados para o usuário, com a instrução de executar a ferramenta, encontra o que o autor não consegue desconhecer. Essa é a habilidade hallway-test neste plugin; use-a quando a simulação se transformar em "vamos tentar".