paulasilvatech ASP Personas do SDLC Agêntico v1.0.0
EN PT ES
01 product · Planning

Product Owner

Escreve e governa a spec.

Atualizado: 2026-04-24 14 seções Baixar .zip

O Product Owner é a persona que escreve, governa e fecha o loop da especificação. Em um SDLC AI-native, o Product Owner opera uma pilha de primitivas validadas que transforma intenção em um contrato legível por máquina.

Resumo executivo

O Product Owner converte intenção de negócio ambígua em uma especificação aprovada e testável que o resto do SDLC pode executar sem perda de tradução. Em um SDLC AI-native, o Product Owner opera dentro da fase de Planning com um conjunto fixo de primitivas: um agente de specification, quatro slash prompts, instruções escopadas, hooks validados por schema e uma lista curada de MCPs validados. As saídas primárias são documentos SPECIFICATION.md em formato EARS, critérios de aceitação em Given-When-Then, links de rastreabilidade de requisito para teste e registros de decisão para toda mudança de escopo.

Papel e responsabilidades

Pense no Product Owner como um engenheiro civil que escreve a especificação de uma ponte. Os construtores, inspetores e reguladores leem todos o mesmo documento e derivam seu trabalho a partir dele. O Product Owner não despeja concreto, mas é responsável pelo fato de cada despejo, solda e cabo corresponder a uma cláusula numerada que alguém pode verificar sob carga. Em um SDLC AI-native, a especificação é o contrato entre humanos e agentes, e o Product Owner é seu editor-chefe.

Responsabilidades primárias:

  • Escrever e manter o SPECIFICATION.md para toda feature, usando requisitos EARS e critérios de aceitação Given-When-Then
  • Governar o backlog no GitHub Projects ou Azure Boards, garantindo que todo item aponte para uma seção da spec
  • Definir e proteger a hipótese de outcome do produto, não a lista de outputs
  • Resolver conflitos de escopo entre stakeholders antes que cheguem ao Developer
  • Operar o agente Spec Scribe e os prompts /draft-spec, /earsify, /review-spec, /link-acceptance
  • Fechar o loop confirmando aceitação em pull requests merged no GitHub
  • Manter a matriz de rastreabilidade de requisito para teste para artefato implantado
  • Publicar release notes a partir do diff da especificação, não do diff de código

Jobs to be done

  1. Como Product Owner, eu quero converter uma conversa com stakeholder em um draft de spec em até uma hora, para que o time nunca fique esperando por mim para iniciar a descoberta.
  2. Como Product Owner, eu quero todo requisito em formato EARS, para que os agentes possam parseá-lo sem interpretação.
  3. Como Product Owner, eu quero todo critério de aceitação em Given-When-Then, para que o QA Engineer possa gerar testes direto da spec.
  4. Como Product Owner, eu quero um link de rastreabilidade ao vivo de cada requisito para seu teste e seu artefato implantado, para que eu consiga responder a questões de auditoria em minutos.
  5. Como Product Owner, eu quero que a spec recuse merge quando a aceitação estiver ausente, para que o desvio de escopo seja pego antes de o código ser escrito.
  6. Como Product Owner, eu quero release notes geradas a partir do diff da spec, para que stakeholders vejam valor entregue, não commits enviados.

Dores antes da era AI-native

  1. Tickets ambíguos. Descrições em texto livre em um tracker forçam todo leitor a adivinhar a intenção. Developers implementam a interpretação mais fácil; QA testa a mais defensiva.
  2. Handoffs verbais. O escopo vive na memória da reunião. Quando a reunião termina, o escopo silenciosamente bifurca.
  3. Critérios de aceitação inventados na hora do review. Revisores negociam a definição de pronto depois que o código já foi escrito, então retrabalho é inevitável.
  4. Rastreabilidade construída à mão em planilhas. A matriz está obsoleta no dia em que é publicada, e os auditores sabem disso.
  5. Release notes escritas pelo release manager a partir de logs de commit. Stakeholders veem churn técnico, não outcomes de produto, e a confiança se deteriora.

Fluxo diário AI-native

O Product Owner opera um loop fixo todo dia. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code e Claude Code no terminal, além de um pequeno catálogo de MCPs validados para contexto externo.

Setup da manhã

  1. Abra o repositório no Visual Studio Code. GitHub Copilot Chat carrega o AGENTS.md e as instruções escopadas da spec.
  2. Puxe o último main e abra a branch ativa da feature para a spec em andamento.
  3. Revise inputs noturnos de stakeholders capturados em threads do Microsoft Teams e no Outlook via o Microsoft 365 Agents SDK MCP.
  4. Rode /review-spec no draft do dia anterior para capturar violações de EARS e aceitação ausente.

Execução no meio do dia

  1. Coleta de stakeholder. Invoque /draft-spec com a transcrição da reunião ou thread do Teams. O agente Spec Scribe produz um primeiro draft com requisitos numerados e questões em aberto sinalizadas.
  2. Conversão para EARS. Invoque /earsify em qualquer declaração em texto livre. O agente reescreve cada uma no formato WHEN ... THE system SHALL ... e se recusa a emitir requisitos sem uma condição de disparo.
  3. Vinculação de aceitação. Invoque /link-acceptance para anexar critérios Given-When-Then a todo requisito. O agente bloqueia a spec de ir para review até que todo requisito tenha pelo menos um critério.
  4. Sincronização do backlog. Use o GitHub MCP ou o Azure DevOps MCP para criar ou atualizar work items que referenciem âncoras de seções da spec, não resumos em prosa.

Revisão no fim da tarde

  1. Invoque /review-spec para rodar a varredura final de governança. O agente verifica testabilidade, contradições, duplicatas e requisitos órfãos.
  2. Abra um pull request no SPECIFICATION.md. GitHub Copilot Code Review comenta em problemas estruturais; stakeholders humanos aprovam o conteúdo.
  3. Atualize a matriz de rastreabilidade. Um hook de post-merge regenera a matriz a partir das âncoras da spec, IDs de teste e registros de deploy no GitHub Actions.
  4. Publique o digest diário da spec no canal do Teams via Microsoft 365 Agents SDK, resumindo requisitos aceitos e questões em aberto.

Primitivas recomendadas

Agente

AgenteArquivoPropósito
spec-scribe.github/agents/spec-scribe.agent.mdEscrever, earsify, revisar e vincular aceitação para o SPECIFICATION.md

O Spec Scribe usa claude-sonnet-4-6 por padrão. Ferramentas: read, edit, search, grep, glob. Sem acesso a bash, porque a persona Product Owner nunca executa código. Extended thinking é habilitado apenas para /review-spec, onde a detecção de contradições se beneficia de raciocínio profundo.

Slash prompts

ComandoArquivoPropósito
/draft-spec.github/prompts/draft-spec.prompt.mdTransformar um input cru de stakeholder em um draft numerado de spec
/earsify.github/prompts/earsify.prompt.mdReescrever requisitos em texto livre na sintaxe EARS
/review-spec.github/prompts/review-spec.prompt.mdVarredura de governança para testabilidade, contradições, órfãos
/link-acceptance.github/prompts/link-acceptance.prompt.mdAnexar critérios Given-When-Then a todo requisito

Instruções escopadas

applyTo com escopo reduz o custo em tokens em aproximadamente 68 por cento comparado a instruções globais.

Escopo (applyTo)ArquivoPropósito
docs/specs/**/*.md.github/instructions/specs.instructions.mdFormato EARS, numeração, âncoras e verbos vagos banidos
docs/adr/**/*.md.github/instructions/adr.instructions.mdFormato do registro de decisão quando uma spec exige uma escolha arquitetural
docs/releases/**/*.md.github/instructions/release-notes.instructions.mdRelease notes geradas a partir do diff da spec, não do log de commits

Hooks

Hooks custam zero tokens de LLM. São a camada de governança mais forte para especificações.

  • pre-commit: rejeitar qualquer arquivo de spec com um requisito sem trigger EARS ou um critério de aceitação órfão
  • post-commit: regenerar a matriz de rastreabilidade a partir das âncoras da spec e IDs de teste
  • pre-merge: bloquear o merge de qualquer mudança de spec que não inclua uma entrada de changelog e um work item vinculado

MCPs validados

MCPPropósitoDono
GitHub MCP ServerLer e atualizar GitHub Projects, issues e PRs para governança de backlogGitHub (oficial)
Azure DevOps MCP ServerLer e atualizar work items do Azure Boards quando o time usa Azure DevOpsMicrosoft (oficial)
Microsoft Learn Docs MCPBuscar documentação atualizada de produtos Microsoft ao escrever specs para features M365 ou AzureMicrosoft (oficial)
Microsoft 365 Agents SDK MCPPuxar threads do Teams, decisões do Outlook e artefatos do SharePoint para dentro da coleta da specMicrosoft (oficial)
Azure MCP ServerConsultar Application Insights e Azure Monitor para ancorar specs em comportamento de produçãoMicrosoft (oficial)

Exemplos reais

Exemplo 1: escrever uma spec a partir de uma conversa no Teams

Entrada: Uma thread de 45 minutos no Microsoft Teams entre vendas e suporte propondo um fluxo de renovação de contrato self-service.

Invocação: /draft-spec com a thread exportada via o Microsoft 365 Agents SDK MCP.

Saída esperada:

  1. Um docs/specs/contract-renewal/SPECIFICATION.md com seis requisitos EARS numerados, cada um seguido por critérios de aceitação Given-When-Then.
  2. Uma issue do GitHub por requisito criada através do GitHub MCP, vinculada à âncora da spec.
  3. Uma seção de perguntas em aberto listando quatro pontos que exigem decisão antes da aprovação.

Exemplo 2: varredura de governança antes do merge

Entrada: Uma spec de 28 requisitos para um upgrade de billing, já earsified em uma passagem anterior.

Invocação: /review-spec.

Saída esperada:

  1. Um relatório de review sinalizando duas contradições entre os requisitos 7 e 14, uma duplicata entre 19 e 22, e três critérios de aceitação órfãos não anexados a nenhum requisito.
  2. Um comentário de pull request com sugestões vinculadas por âncoras.
  3. Um merge bloqueado até que o autor resolva as três categorias.

Anti-padrões

  1. Escrever specs como prosa. Parágrafos escondem contradições e não podem ser consumidos por agentes. Mitigação: enforçar EARS via o hook de pre-commit e o prompt /earsify.
  2. Pular critérios de aceitação. Um requisito sem Given-When-Then não é testável. Mitigação: /link-acceptance se recusa a fechar o loop, e o hook bloqueia o commit.
  3. Itens de backlog sem âncoras de spec. Se o ticket não aponta para um requisito numerado, o escopo vai derivar. Mitigação: o GitHub MCP auto-injeta a URL da âncora na criação da issue.
  4. Release notes geradas a partir de commits. Stakeholders veem ruído técnico. Mitigação: release notes são geradas a partir do diff da spec via as instruções escopadas.
  5. Verbos ambíguos. Palavras como “suportar”, “tratar”, “melhorar” são banidas pelas instruções da spec. Mitigação: o hook de pre-commit as rejeita.

KPIs e métricas de impacto

KPILinha baseMetaMedição
Lead time da spec, coleta até aprovada5 dias< 1 diaTimestamps de PR do SPECIFICATION.md no GitHub
Requisitos em formato EARS20 por cento100 por centoRelatório do spec linter no GitHub Actions
Cobertura de aceitação, requisitos com Given-When-Then40 por cento100 por centoMatriz de rastreabilidade
Taxa de mudança de escopo pós-aprovação35 por cento< 10 por centoContagem de PRs de spec reabertos
Tempo de resposta a uma consulta de auditoria2 dias< 1 horaLog de consultas da matriz de rastreabilidade
Satisfação de stakeholder sobre clarezaDesconhecido> 4.2 de 5Pesquisa trimestral via Microsoft Forms

Maturidade em quatro níveis

NívelNomeMarcadores
L1ManualTickets em prosa, sem EARS, sem aceitação, escopo negociado no review
L2AssistidoGitHub Copilot usado para polir o texto do ticket, ainda sem spec legível por máquina
L3AumentadoAgente Spec Scribe, quatro slash prompts, instruções escopadas, um ou dois MCPs, EARS enforçado
L4AutônomoKit completo de primitivas, hooks enforçados, rastreabilidade auto-gerada, release notes a partir do diff da spec, digest de stakeholder automatizado

Integração com outras personas

  • Para o Requirements Engineer: SPECIFICATION.md aprovado com requisitos EARS numerados como input canônico para decomposição detalhada
  • Para o Business Manager: hooks de KPI em nível de requisito para que outcomes possam ser atados à história de valor
  • Para o Enterprise Architect: cláusulas da spec que disparam um novo ADR ou invocam um princípio existente
  • Para o Software Architect: superfície de contrato usada para derivar CODEMAP.md e contratos de API
  • Para o QA Engineer: aceitação Given-When-Then como fonte direta de casos de teste
  • Para o Developer: âncora da spec em todo pull request para implementação rastreável
  • Para o Tech Writer: release notes geradas a partir do diff da spec, não do diff do commit

Glossário

  • EARS: Easy Approach to Requirements Syntax. A forma canônica WHEN ... THE system SHALL ... usada no SPECIFICATION.md.
  • Given-When-Then: formato de critério de aceitação que vincula uma pré-condição, uma ação e um outcome observável.
  • Âncora da spec: âncora markdown estável sobre um ID de requisito, usada como alvo canônico de link a partir de issues, PRs e testes.
  • Matriz de rastreabilidade: tabela gerada que mapeia cada requisito para seus testes, pull requests e artefatos implantados.
  • Hipótese de outcome: o resultado de negócio mensurável que a feature deve produzir, distinto da lista de outputs.
  • Backlog: a lista ordenada de work items no GitHub Projects ou Azure Boards, cada um vinculado a uma âncora da spec.

Referências