---
title: O método
route: /pt/method
lang: pt
part_of: Onirion
version: "4.0"
date: 2026-09-22
author: Alexis Boyer
license: Todos os direitos reservados
one_line: "Um Product Builder leva um produto de uma pasta de documentos dispersos até algo rodando em produção, front e back; Design, Frontend, Backend e API, Data, os acessos, a entrega e a revisão são os serviços compartilhados que tornam isso possível."
layers:
  summary: /pt/method
  complete_text: /pt/complete.md
  markdown: /pt/method.md
---

# O método

Um Product Builder leva um produto de uma pasta de documentos dispersos até algo rodando em produção, front e back; Design, Frontend, Backend e API, Data, os acessos, a entrega e a revisão são os serviços compartilhados que tornam isso possível.

Ser responsável pelo resultado não significa fazer todos os trabalhos de especialista nem gerenciar todos os colaboradores. Os serviços horizontais são parceiros na entrega, não uma fila de tickets desconectados.

## O princípio

*Figura — imagem, 3:2: Um responsável por uma capacidade entrega um padrão revisado, entre duas pessoas — o horizontal a serviço do vertical, em uma única troca.*

### As duas dimensões

*Figure — o vertical, um resultado de produto que um único Product Builder leva de uma pasta de documentos até a produção, cruza cinco serviços compartilhados; cada um devolve algo utilizável, e juntos eles formam um produto rodando em produção.*

**Vertical · Um resultado de produto.** Um Product Builder responsável por um produto, front e back, da primeira pasta de documentos até a produção.

| Horizontal · serviço compartilhado | O que ele devolve, utilizável |
| --- | --- |
| Design Ops | Um design system em que tanto o protótipo quanto o front se apoiam: os componentes e seus estados, os tokens, as regras de uso, o que pode ser estendido e quem o mantém. |
| Frontend Ops | Um repositório starter aprovado, em uma versão identificada, com sua arquitetura, suas convenções de roteamento e de componentes, o padrão de cliente de API, as verificações exigidas em uma branch implantável e uma versão que um agente possa reler antes de cada mudança. |
| Backend e API Ops | Um catálogo de APIs com exemplos reais, as regras de autenticação e de permissões, o formato das requisições, das respostas e dos erros, um ambiente de testes com identidades seguras, uma forma escrita de pedir uma API que ainda não existe, e convenções de backend escritas como critérios com os quais uma mudança pode ser confrontada, começando pela receita para as mudanças mais comuns, em uma versão que um agente possa reler antes de cada mudança, com um revisor designado. |
| Data Ops | Onde ficam os dados de referência, o significado de negócio dos campos-chave e dos valores de status, um conjunto de dados de teste que pode ser usado sem risco, e as regras sobre o que pode ser exportado, por quem e para onde. |
| Acessos, entrega e revisão | Um processo de solicitação com um aprovador e um prazo de resposta, um caminho do ambiente local para o repositório, para staging e para produção, uma forma de ver qual versão está em produção, e desenvolvedores que leem o código gerado. |

Um produto rodando em produção.

- *Vertical · Product Builder* — **Assuma um resultado, front e back.** Leve o problema, as decisões, o design que foi aceito, as restrições e a verificação, do discovery até a produção. Você se apoia nos serviços compartilhados e o resultado continua sendo seu.
- *Horizontal · Serviços compartilhados* — **Tornar o conhecimento especializado reutilizável.** Fornecer um responsável designado, um padrão ou contrato aprovado e os limites dele, um processo de resposta, e evidências de que a contribuição funciona no produto rodando — para você e para todos que fazem o mesmo trabalho.

### Um contrato nos dois sentidos

**O Product Builder fornece**

- O resultado, os usuários e o contexto
- A contribuição necessária
- As restrições dentro das quais ela precisa caber
- Um critério de aceitação
- Um prazo para a decisão

**O responsável por Ops devolve**

- Um responsável designado
- Um padrão ou contrato aprovado, e os limites dele
- Um prazo de resposta ou de entrega
- Um processo de revisão
- Evidências de que funciona no produto rodando

**Antes de construir**

### Utilizável, não só documentado.

Um documento sozinho não é um serviço utilizável. Antes de construir, verifique quais funcionam de verdade: um responsável designado, um processo de resposta, acessos aprovados, um ambiente que funciona e uma forma de verificar o que volta. Quando o starter, as convenções ou a API de que você precisa não existem, pare em vez de inventá-los — uma convenção inventada na hora é o que um revisor vai desfazer depois — e peça o artefato ao responsável por Ops, nomeando-o, e diga que resposta você espera.

Enquanto isso, registre o substituto no diário, com data: o que você seguiu no lugar, quem concordou e o que ele substitui. Em uma equipe pequena, uma mesma pessoa pode ocupar vários desses papéis; ainda assim, as responsabilidades precisam ficar visíveis.

**Exemplo**

Em um fluxo de compartilhamento, o Product Builder é responsável pelas permissões que o produto pretende dar e pelo comportamento que as pessoas envolvidas aceitaram. Design Ops fornece o padrão revisado e seus estados, Backend e API Ops o contrato de autorização, Frontend Ops o starter dentro do qual o front é escrito, Data Ops os eventos que mostram como ele é usado. O Product Builder percorre o fluxo de ponta a ponta, com seus estados vazios, de erro e de permissão negada, e o verifica como um único produto.

## O percurso

De uma pasta de documentos dispersos até algo rodando em produção, por conta própria, com agentes de código e de design fazendo o trabalho que você lhes passa: sete marcos em uma única ordem, e três coisas que atravessam todos eles.

### Por que a ordem importa

- Uma pasta de documentos não é um discovery.
- Um discovery não é um PRD.
- Um PRD não é um protótipo que as pessoas envolvidas reconhecem como a ferramenta delas.
- Um front em que você pode clicar não é um produto cujos fluxos se sustentam em profundidade.

**A pergunta.** Qual dessas coisas você tem de verdade em mãos? Comece onde a resposta deixa de ser sim, e não deixe uma sessão passar por um marco que você não fechou: peça a ela, em cada marco, que diga em que marco está, o que tem, o que falta e o que você precisa decidir antes que ela passe adiante. Uma sessão que não sabe responder saiu do método.

> “A linha que fecha um marco é o que você deveria ter em mãos antes de seguir em frente.”
>
> — Alexis Boyer

*Figura — imagem, 21:9: Sete marcadores em fila sobre uma mesma superfície: a sequência como objeto físico, lida da esquerda para a direita.*

### Os sete marcos

Sete marcos, numerados de 0 a 6. Nada acima deles, e nenhuma subfase. Cada um diz o que você faz, o que você tem em mãos quando ele se fecha, e os prompts e modelos que usa.

| Marco | O que você faz | O que você tem em mãos | Recursos |
| --- | --- | --- | --- |
| 0 · Montar a pasta do projeto | Reúna todos os documentos de que o projeto precisa em uma única pasta criada para ele, e abra a sessão nessa pasta. Crie a memória e o diário antes que qualquer outra coisa rode, e o canal do projeto com todas as pessoas envolvidas dentro. O primeiro prompt converte e indexa; não interpreta nada. | tudo em uma única pasta, convertido, inventariado | [Inventariar e converter →](/pt/resources/prompt-inventory) · [Entrada de memória →](/pt/resources/memory-entry) · [Entrada de diário →](/pt/resources/journal-entry) |
| 1 · Reunir o discovery | Faça o inventário do que você tem como ponto de partida, seja o que for, e percorra as fontes em busca de contradições, responsabilidades sem dono e o mesmo nome usado para superfícies diferentes, e não de um resumo. Coloque um agente para ler o que ninguém tem tempo de ler; o que volta é matéria-prima, nunca uma decisão. | o que se sabe, o que falta, o que se contradiz | [Ler os canais →](/pt/resources/prompt-channel-reading) |
| 2 · Escrever o PRD | Rode o prompt de análise na pasta, faça-o separar o que está estabelecido do que se contradiz e do que falta, e responda você às perguntas de alinhamento. Depois refine o PRD e alinhe-o com o pessoal de negócio, incluindo as partes técnicas. | o que entra e o que fica de fora, acordado com o negócio | [Escrever o PRD →](/pt/resources/prompt-prd) · [Modelo de PRD →](/pt/resources/prd-template) |
| 3 · Prototipar os fluxos de ponta a ponta | Nesta etapa, o agente de código assume o papel de PM: escreve o prompt para a ferramenta de design e exige fluxos de ponta a ponta, não só as telas principais. Itere na ferramenta de design, mostre o resultado às pessoas que vão usá-lo e continue até que elas digam que é a ferramenta delas. | um protótipo que as pessoas envolvidas reconhecem como a ferramenta delas | [Especificação de design →](/pt/resources/prompt-design-specification) · [Instrução de design →](/pt/resources/prompt-design-instruction) · [Refinamento →](/pt/resources/prompt-refinement) |
| 4 · Levar o protótipo para o código | Parta do starter de frontend aprovado e das convenções de backend da organização, nunca de uma pasta vazia nem da exportação da ferramenta de design. Depois vêm as idas e vindas: o front rodando ao lado do design, você aponta o que não está certo, o agente corrige, você olha de novo. | um front que roda, em que você pode clicar | [Levar o protótipo para o código →](/pt/resources/prompt-port) · [Sem convenções de backend escritas →](/pt/resources/prompt-observed-conventions) · [Antecipar as necessidades de backend →](/pt/resources/prompt-backend-requests) |
| 5 · Conectar o backend | Troque os serviços simulados pelos reais, fluxo a fluxo, e aprofunde cada um antes do próximo: o estado vazio, o erro, a resposta lenta, a permissão que diz não. Os papéis e a privacidade são aplicados no modelo de leitura, não no componente que exibe os dados. Cada mudança é confrontada com as convenções de backend, ponto a ponto, antes de ir para revisão. | os fluxos se sustentam em profundidade | [Conectar o backend →](/pt/resources/prompt-connect) |
| 6 · Testar e depois lançar | Crie contas para as pessoas que devem testar enquanto o trabalho de conexão ainda está em andamento, compartilhe a vida do produto no canal e corrija o que volta à medida que volta. Depois obtenha o sinal verde dos leads das áreas envolvidas, e lance o produto. | contas em mãos reais, depois a produção | [Preparar a entrada em produção →](/pt/resources/prompt-release) |

### O que os marcos deixam

| O que o percurso deixa | O que responde | O que contém | Marcos |
| --- | --- | --- | --- |
| Memória e diário do projeto | Por que o produto andou nessa direção, e o que aconteceu, e quando? | Dois arquivos criados antes de tudo: a memória guarda a posição atual, as decisões e seus trade-offs; o diário guarda o registro datado, nunca reescrito, incluindo o que se revelou um erro. | 0 |
| Notas de discovery | O que as fontes disseram de fato, e onde elas divergem? | A lista de fontes, as ambiguidades, as perguntas para os stakeholders e uma primeira hipótese sobre os limites do produto, escritas na pasta para que o marco seguinte possa abri-las pelo nome. | 1 |
| O PRD | O que está sendo construído, e o que não está? | Um documento cuja primeira seção é o enquadramento estratégico, com cada premissa marcada como premissa, junto com a fonte em que se apoia ou a pessoa que precisa decidi-la. | 2 |
| O protótipo que as pessoas aceitaram | Esta é a ferramenta de que as pessoas envolvidas precisam? | Os fluxos de ponta a ponta, com seus estados e suas falhas, iterados na ferramenta de design e mostrados a usuários reais até que eles digam que é deles. | 3 |
| O front rodando | Você consegue percorrer os fluxos e clicar neles? | Um front construído dentro do starter da organização, percorrido fluxo a fluxo ao lado do design, com o que foi adaptado e o que foi deixado diferente de propósito, por escrito. | 4 |
| Os fluxos conectados | Os fluxos se sustentam em profundidade, ou só na superfície? | Cada fluxo ligado ao backend real, com seus estados vazios, de erro, de resposta lenta e de permissão negada, os papéis aplicados onde os dados são lidos, e cada mudança confrontada com as convenções de backend, ponto a ponto. | 5 |
| O registro da entrada em produção | O que saiu, verificado como, e quem deu o sinal verde? | O conteúdo da entrada em produção, fluxo a fluxo, o que foi testado e com quais contas, o que se sabe que está quebrado, e qual revisão não aconteceu, se alguma não pôde acontecer. | 6 |

Um marco se fecha quando você tem em mãos o que a linha de saída dele indica. Se não tiver, ele não está fechado, e a sessão diz o que falta e o que você precisa decidir.

**O que é preciso.** De uma pasta com o material de discovery reunido até um front em que você pode clicar: de três a quatro horas no melhor dos casos e vinte e quatro no pior, quando o discovery já foi parcialmente reunido. Cerca de um mês para conectar o backend de modo que os fluxos se sustentem em profundidade, conforme o tamanho da aplicação. E o código ainda passa pela revisão dos desenvolvedores, e é aprovado, porque o agente trabalha dentro do starter e das convenções da organização. Esses números vêm da prática do próprio autor, não de um estudo.

A IA constrói rápido, então as verificações que importam são humanas. As pessoas envolvidas aceitam o protótipo no marco 3, e convencer tem aqui um único sentido: elas dizem que esta é a ferramenta de que precisam. O código passa pela revisão dos desenvolvedores antes da produção, e os leads das áreas envolvidas dão o sinal verde. Nenhuma dessas verificações é uma etapa acrescentada no final.

**Três coisas atravessam os marcos** em vez de ficar dentro de um deles. A sessão de controle é uma segunda sessão cujo único trabalho é questionar a primeira: ela lê, verifica e questiona, não muda código nem decide o escopo, e devolve constatações com suas evidências para que você decida. A salvaguarda permanente manda o agente de volta ao starter de frontend e às convenções de backend da organização antes de cada mudança no código — não uma vez no início, mas toda vez. O aprendizado contínuo não para quando a construção começa: você continua aprendendo sobre o negócio, os usuários e aquilo de que eles precisam, e quando esse aprendizado diz que o produto deveria mudar, você o muda, no marco em que estiver. Ele refina o que já existe em vez de acumular, e continua leve. [Sessão de controle →](/pt/resources/prompt-control-session) · [Restrição permanente →](/pt/resources/prompt-standing-constraint) · [Ler os canais →](/pt/resources/prompt-channel-reading)

**Continuidade.** A construção não para no marco 6. O front continua pronto para demo e segue evoluindo: você volta aos fluxos, os aprofunda, conecta o que ficou pendente e mostra de novo no canal. Uma única coisa é congelada de propósito, e só uma: um MVP que precisa ir para produção, em que o conteúdo da entrada em produção para de mudar até que ela saia.

A versão em inglês para um assistente apresenta os mesmos marcos um por um: [/method.md](/method.md).

### Comece no marco em que o seu trabalho está

Nem todo mundo começa no marco 0. Você começa no marco em que o seu trabalho realmente começa, e os marcos que você pula são aqueles cujo resultado você já tem.

- *Uma funcionalidade em um produto que já existe · começa no PRD* — **O produto já está rodando.** O PRD está escrito e o design está definido. Você não refaz a pasta nem o discovery: começa na seção do PRD que essa funcionalidade altera, depois o protótipo, a passagem para o código, o backend, os testes.
- *Um produto que ainda não existe · começa no marco 0* — **A sequência inteira.** Uma pasta com tudo dentro, o discovery reunido e suas contradições nomeadas, um PRD acordado com o negócio, um protótipo que as pessoas envolvidas dizem ser a ferramenta delas, depois a passagem para o código, o backend fluxo a fluxo, e contas em mãos reais antes da produção.

O que você não pula é um marco cujo resultado você não tem. Não há inventário? Não há PRD? Então é esse marco que você faz.

Esses dois exemplos mostram que parte do percurso um trabalho concreto realmente segue. Eles não descrevem o projeto de nenhum cliente.