Navegacao Rapida
Conteudo Detalhado
๐ Visao Geral dos Templates
Entenda o fluxo de documentacao do GIPM e como cada template se conecta.
A documentacao no GIPM nao e burocracia - e governanca. Cada documento cria um ponto de auditoria, uma decisao registrada que pode ser revisitada.
Sem documentacao, nao ha como rastrear por que decisoes foram tomadas. Quando algo quebra, voce precisa do historico.
Governanca documental, auditoria, rastreabilidade, decisoes registradas, compliance.
A ordem ideal: 1) Project Brief, 2) PRD, 3) Arquitetura, 4) User Stories, 5) QA Gate. Cada documento alimenta o proximo na cadeia.
Seguir a ordem correta evita retrabalho. Arquitetura sem PRD e chute. Stories sem arquitetura sao incompletas.
Fluxo documental, dependencias, cadeia de valor, sequenciamento, input-output.
Brief e estrategico (por que e o que em alto nivel). PRD e tatico (requisitos detalhados e especificos). Nunca pule o Brief.
Confundir os dois leva a PRDs sem contexto estrategico ou Briefs com detalhes tecnicos desnecessarios.
Estrategia vs tatica, niveis de abstracao, escopo, visao, requisitos.
O documento de arquitetura e um contrato entre o time e a IA. Define padroes obrigatorios, stack tecnologico e estrutura.
Se a IA gerar codigo fora dos padroes definidos, o documento permite identificar a violacao e corrigir.
Contrato arquitetural, padroes, stack, estrutura de projeto, regras tecnicas.
Stories GIPM sao escritas para agentes de IA. Precisam ser atomicas, especificas, com criterios de aceitacao testaveis.
Stories vagas geram codigo vago. A IA nao tem contexto implicito como humanos - precisa de tudo explicito.
Atomicidade, criterios de aceitacao, especificidade, contexto explicito, testabilidade.
Cada documento referencia os anteriores. Arquitetura cita PRD. Stories citam arquitetura. QA valida stories. E uma cadeia.
Essa cadeia cria rastreabilidade total - do requisito de negocio ao codigo, passando por todas as decisoes.
Rastreabilidade, referencias cruzadas, cadeia de evidencias, auditoria end-to-end.
๐ Project Brief
O documento fundacional que define visao, problema, usuarios e escopo do projeto.
Documento que captura a essencia do projeto: problema, solucao, usuarios, restricoes. O "elevator pitch" expandido.
E o ponto de partida de tudo. Sem Brief claro, todo o resto fica sem direcao.
Visao, problema, solucao, personas, escopo, restricoes, premissas.
2-3 frases que qualquer pessoa pode ler e entender o projeto. Se nao consegue resumir, nao entendeu ainda.
Forcavoce a ter clareza. Tambem facilita comunicacao com stakeholders que nao vao ler o documento todo.
Sintese, comunicacao executiva, clareza, pitch.
Descreva o problema de forma mensuravel. "Usuarios perdem tempo" e vago. "2h/dia em tarefas manuais" e especifico.
Problema mensuravel permite medir sucesso. Sem numeros, como saber se a solucao funcionou?
Metricas, quantificacao, baseline, impacto mensuravel, KPIs.
Defina personas concretas. Nao "empresas", mas "gerentes de projeto em empresas de 50-200 funcionarios".
Personas guiam decisoes de UX, features e priorizacao. Construir para "todos" e construir para ninguem.
Personas, segmentacao, perfil de usuario, jobs-to-be-done, necessidades.
Liste explicitamente o que esta IN e OUT do MVP. Essa lista evita scope creep e alinha expectativas.
Sem lista explicita do que esta fora, tudo pode entrar. Scope creep mata projetos.
MVP, escopo, IN/OUT, scope creep, priorizacao, trade-offs.
Documente limitacoes de orcamento, timeline, tecnologia. Premissas sao apostas - se mudarem, o projeto muda.
Restricoes definem o espaco de solucao. Premissas sao riscos - se uma premissa cair, voce precisa revalidar.
Restricoes, premissas, riscos, constraints, validacao de hipoteses.
Use o prompt de geracao de Brief com seu LLM. Forneca contexto maximo. Itere. O Brief final passa pelo crivo humano.
IA acelera a criacao, mas humano valida. O fluxo e: IA gera estrutura, humano refina e aprova.
Geracao assistida, iteracao, validacao humana, prompt engineering.
Atualize quando premissas mudarem significativamente. Mantenha changelog. Versione o documento.
Documentos vivos precisam de gestao de versao. Sem isso, perde-se o historico de evolucao.
Versionamento, changelog, documento vivo, gestao de mudancas.
๐ PRD - Product Requirements Document
Detalha requisitos funcionais, nao-funcionais, epicos e historias de usuario.
O PRD traduz a visao do Brief em requisitos executaveis. E mais detalhado, mais tecnico, mais proximo da implementacao.
A transicao Brief->PRD e onde visao vira especificacao. Erros aqui propagam para todo o projeto.
Especificacao, requisitos, traducao, detalhamento progressivo.
O que o sistema DEVE fazer. Use formato "O sistema deve [verbo] [objeto] [condicao]". Seja especifico e testavel.
FRs sao a base de tudo. Cada feature, cada teste, cada validacao deriva de um FR.
Requisitos funcionais, comportamento, acoes, testabilidade, especificidade.
Como o sistema deve se comportar. Performance, seguranca, disponibilidade. As "-ilities" que definem qualidade.
NFRs sao frequentemente esquecidos ate ser tarde demais. Performance ruim mata produtos bons.
NFRs, qualidade, performance, seguranca, disponibilidade, escalabilidade.
Epicos sao grandes blocos de trabalho sequenciais. Epico 1 sempre e fundacao (setup, CI/CD, auth basica).
Ordem de epicos define dependencias. Construir feature antes de infra e receita para retrabalho.
Epicos, sequenciamento, dependencias, fundacao, incrementalidade.
Formato: Como [usuario], eu quero [acao], para que [beneficio]. Criterios de aceitacao sao OBRIGATORIOS.
Stories conectam requisitos a valor de usuario. Sem AC, nao ha definicao de done.
User stories, criterios de aceitacao, valor, persona, formato padrao.
Must: sem isso nao lanca. Should: importante mas nao bloqueante. Could: nice to have. Won't: fora do escopo.
Priorizacao clara evita discussoes infinitas. MoSCoW e simples e efetivo.
MoSCoW, priorizacao, trade-offs, escopo, MVP, releases.
๐๏ธ Documento de Arquitetura
Define stack tecnico, padroes arquiteturais, componentes, APIs e infraestrutura.
Este documento e o blueprint tecnico. Cada decisao de tecnologia, cada padrao esta aqui. E a fonte da verdade tecnica.
Sem arquitetura documentada, cada dev toma decisoes diferentes. Inconsistencia mata manutenibilidade.
Blueprint, fonte da verdade, decisoes tecnicas, consistencia, padronizacao.
Liste TODAS as tecnologias com versoes especificas. "Node.js 20.11.0 LTS" nao "Node.js". Versoes evitam surpresas.
"Funciona na minha maquina" e causado por versoes diferentes. Documente tudo explicitamente.
Versionamento, reproducibilidade, stack, dependencias, LTS.
Documente padroes escolhidos: Repository Pattern, DI, CQRS, etc. Inclua justificativa. Sao LEI para a IA.
IA so segue padroes se estiverem documentados. Sem isso, ela inventa solucoes inconsistentes.
Design patterns, arquitetura de software, DI, Repository, CQRS, Clean Architecture.
Defina entidades, atributos, relacionamentos. Use diagramas Mermaid. Guia a criacao de banco e APIs.
Modelo de dados errado no inicio e caro de corrigir depois. Defina bem antes de codar.
Modelagem, entidades, relacionamentos, ERD, Mermaid, schemas.
Documente endpoints em OpenAPI/Swagger. Request/response schemas, codigos de erro. A IA usara isso para gerar codigo.
API bem documentada permite geracao de codigo, testes, e clientes automaticamente.
OpenAPI, Swagger, REST, endpoints, schemas, contratos de API.
Documente estrategias de validacao, autenticacao, autorizacao, gestao de secrets. Seguranca nao e opcional.
Seguranca pensada depois e seguranca fraca. Defina no inicio como parte da arquitetura.
Autenticacao, autorizacao, JWT, secrets, OWASP, validacao de input.
๐ User Stories
Template para historias de usuario com criterios de aceitacao e tracking de implementacao.
Status, Story (As a/I want/So that), Criterios de Aceitacao, Tarefas, Notas de Dev, Testes, Dev Agent Record, QA Results.
Cada secao tem proposito. Pular qualquer uma compromete rastreabilidade ou qualidade.
Estrutura de story, AC, tarefas, tracking, registro de implementacao.
Sao o CONTRATO de done. Cada AC deve ser testavel. "Funciona bem" nao e AC. "Resposta em menos de 200ms" e AC.
AC ambiguos geram debates infinitos sobre done. AC claros terminam discussoes.
Criterios de aceitacao, testabilidade, definicao de done, especificidade.
Quebre a story em tarefas atomicas. Referencie qual AC cada tarefa atende. Facilita tracking e QA.
Tarefas atomicas permitem progresso mensuravel e facilitam code review focado.
Breakdown, atomicidade, rastreabilidade AC-tarefa, progresso incremental.
Quando IA implementa, registre modelo usado, logs, notas de conclusao, arquivos modificados. Auditabilidade total.
Sem registro, nao se sabe qual modelo gerou qual codigo. Essencial para debug e melhoria de prompts.
Auditoria de IA, logging, rastreabilidade, modelo, arquivos modificados.
Uma story deve ser completavel em uma sessao (2-4 horas). Se for maior, quebre em stories menores.
Stories grandes demais perdem contexto e acumulam risco. Stories pequenas entregam valor rapido.
Tamanho de story, atomicidade, sessao de trabalho, feedback loop curto.
โ QA Gate - Checklist de Qualidade
Checklist para validar que cada entrega atende aos padroes de qualidade.
Checkpoint que toda entrega deve passar antes de ser done. Sem QA Gate aprovado, nao ha merge.
QA Gate e a ultima linha de defesa contra codigo ruim entrando em producao.
Quality gate, checkpoint, validacao, merge, bloqueio.
Codigo (lint, tests, types), Funcional (ACs atendidos), Seguranca (OWASP), UX (responsivo), e Performance (metricas).
Cada categoria pega tipos diferentes de problemas. Cobrir todas garante qualidade holistica.
Categorias de QA, cobertura, qualidade holistica, areas de risco.
Unitarios, integracao, E2E. Cobertura minima de 80%. Testes passando e pre-requisito de merge.
Testes automatizados sao a unica forma de escalar QA. Review manual nao escala.
Testes automatizados, cobertura, CI, unitarios, integracao, E2E.
Se falhar no QA Gate, documente a falha, corrija, e submeta novamente. Loop ate passar.
Processo claro de correcao evita que problemas fiquem em limbo. Sempre ha proxima acao definida.
Fluxo de correcao, resubmissao, loop de qualidade, documentacao de falhas.
Track taxa de aprovacao, falhas por categoria, tempo medio para resolver. Use dados para melhorar processo.
Sem metricas, nao ha como saber se QA esta melhorando ou piorando. Dados guiam decisoes.
Metricas de QA, taxa de aprovacao, tempo de resolucao, melhoria continua.
๐ค Prompts para IA
Colecao de prompts testados para gerar cada tipo de documento do GIPM.
Prompt estruturado que guia a IA a fazer perguntas e gerar um Brief completo seguindo o template GIPM.
Prompt bem construido extrai informacao que voce nem sabia que tinha. IA como entrevistador.
Prompt engineering, elicitacao, entrevista estruturada, geracao guiada.
Prompt que transforma Brief em PRD detalhado com FRs, NFRs, epicos e stories formatados corretamente.
Conversao Brief->PRD e trabalho pesado. IA acelera drasticamente com prompt certo.
Conversao de documentos, detalhamento, formatacao, consistencia.
Prompt que gera documento de arquitetura com stack, padroes, diagramas Mermaid, e specs de API.
Arquitetura requer pensamento sistemico. Prompt ajuda a nao esquecer componentes criticos.
Geracao de arquitetura, diagramas, specs tecnicas, completude.
Prompt que gera stories atomicas com ACs testaveis, tarefas granulares, e secoes de tracking ja formatadas.
Stories bem escritas sao a base de implementacao com IA. Prompt garante consistencia.
Geracao de stories, atomicidade, ACs testaveis, formatacao padrao.
Tecnicas gerais: seja especifico, forneca exemplos, itere, use personas, defina formato de output desejado.
Prompt engineering e skill transferivel. Melhora resultados em qualquer uso de IA.
Especificidade, exemplos, iteracao, personas, formatacao de output.
Como encadear prompts: Brief -> PRD -> Arquitetura -> Stories. Cada output alimenta proximo input.
Visao end-to-end mostra como as pecas se conectam. Automacao maxima do fluxo documental.
Encadeamento de prompts, fluxo documental, automacao, consistencia.