Postmortem Writing🔗

Definição curta: Postmortem é uma análise estruturada de um projeto (completed ou abandoned) focada em identificar o que funcionou, o que não funcionou, e lições para projetos futuros — promoting continuous improvement.

O que é🔗

Postmortem vem de medicina (autópsia) — examinar o que aconteceu após “morte” do projeto. Em game dev, aplicamos após:

• Game launch (sucesso ou não)
• Projeto cancelado
• Fase importante completada (milestone)

O objetivo é aprender, não julgar.

flowchart LR
    subgraph Postmortem["Postmortem"]
        S["Successes\n(O que funcionou)"]
        F["Failures\n(O que não funcionou)"]
        L["Lessons Learned\n(Lições)"]
        A["Action Items\n(Próximos passos)"]
    end

    S --> L --> A
    F --> L --> A

Índice de sub-tópicos🔗

• Por que escrever postmortems
• Estrutura do postmortem
• O processo
• Exemplo de postmortem
• Anti-patterns a evitar
• Distribuindo o postmortem

Por que escrever postmortems🔗

Benefícios🔗

1. Captura conhecimento — team members forget, documents don’t
2. Identifica padrões — same mistakes across projects
3. Previne repeating — se você não documenta, repete
4. Accountability — honest look at failures
5. Team closure — process emotions, celebrate wins

Quando escrever🔗

• Sempre após projeto significativo
• 3-6 meses após launch (tempo para perspectiva)
• Antes de começar novo projeto (while lessons are fresh)

Estrutura do postmortem🔗

Formato canônico🔗

# Postmortem: [Project Name]
**Date**: [YYYY-MM-DD]
**Team Size**: [N people]
**Duration**: [X months]
**Status**: [Released/Cancelled/On Hold]

## Summary
[2-3 paragraph overview: what was the project,
what happened, what was the outcome]

## Successes
### 1. [Title]
**What**: [Description]
**Evidence**: [How we know it worked]
**Impact**: [Why it mattered]

## Failures
### 1. [Title]
**What**: [Description]
**Root cause**: [Why it happened]
**Fix**: [What we would do differently]

## Lessons Learned
### 1. [General lesson]
**Context**: [When applies]
**Action**: [What to do differently next time]

## Action Items
| Action | Owner | Due Date |
|---|---|---|
| [Specific action] | [Person] | [Date] |

## Appendix
- Original goals vs actual
- Timeline of key events
- Budget (if applicable)

O processo🔗

Passo 1: Gather data (1 week before)🔗

• Collect:
  • Original GDD/game design doc
  • Timeline/milestones
  • Meeting notes
  • Analytics data
  • Bug trackers
  • Post-launch reviews

Passo 2: Individual reflection (2-3 days)🔗

Peça a cada team member para escrever:

• 3 successes
• 3 failures
• 3 lessons learned

Não discutir ainda — individual reflection primeiro.

Passo 3: Team session (2-3 hours)🔗

Formato de blameless retrospective:

5 min:   Context — why we're here
15 min:  Each person shares top successes (silent first, then discuss)
15 min:  Each person shares top failures (same format)
30 min:  Group identifies themes
30 min:  Identify lessons and action items
15 min:  Wrap-up

Passo 4: Document and share🔗

• Draft within 1 week
• Share with team for feedback
• Finalize
• Archive in accessible location

Exemplo de postmortem🔗

# Postmortem: "Dungeon Borks" (2024)

**Date**: 2024-08-15
**Team Size**: 3 (1 designer, 1 programmer, 1 artist)
**Duration**: 8 months
**Status**: Released on Steam

## Summary

Dungeon Borks started as a 3-month prototype that
expanded into a full game after positive playtest feedback.
We released on Steam Early Access in March 2024 and
full release in July 2024.

Initial goals: sell 1000 copies in first month.
Actual: 2,340 copies in first month.

## Successes

### 1. Paper prototyping saved us
**What**: We spent 2 weeks prototyping core mechanics
on paper before any implementation.
**Evidence**: Core loop required minimal iteration after this.
**Impact**: Probably saved 2-3 months of wasted dev time.

### 2. Playtesting culture
**What**: Team embraced playtesting from day 1.
**Evidence**: We ran 12 external playtests before launch.
**Impact**: Game felt polished despite small team.

## Failures

### 1. Scope creep in month 4
**What**: Added 3 new enemy types and 2 boss fights
mid-development without cutting anything.
**Root cause**: Didn't say "no" to features despite time
constraints.
**Fix**: Implement formal feature freeze at Milestone 2.

### 2. No QA process
**What**: 40% of Day 1 reviews mentioned bugs.
**Root cause**: Programmer was sole QA; no systematic testing.
**Fix**: Mandatory bug bash before any release. Automated tests
for critical paths.

## Lessons Learned

1. **Prototype first, prototype fast**: If we hadn't done
   paper prototype, we would have built wrong game.
2. **Say no more**: Good ideas that don't fit = no.
3. **Test early and often**: Playtest results got better
   every session. Don't wait until "it's ready."

Anti-patterns a evitar🔗

❌ Blame culture🔗

WRONG: "Marketing failed because John didn't do outreach"
RIGHT: "Marketing didn't reach enough people — we need
        to start earlier and have more dedicated time"

❌ Vague lessons🔗

WRONG: "We need to communicate better"
RIGHT: "We need weekly 30-min standups and a shared
        task tracker with 100% team adoption"

❌ Action items without owners🔗

WRONG: "Improve testing"
RIGHT: "Maria will implement automated tests for
        combat system by Feb 1"

❌ Only focusing on negative🔗

Successes are lessons too! Don’t ignore what worked.

Distribuindo o postmortem🔗

Internal use🔗

• Archive in company wiki/Notion
• Share in team newsletter
• Reference in kickoff of next project

Public postmortem (optional)🔗

Many indie devs share postmortems publicly:

• Blog post
• Gamasutra/GameDev.net article
• GDC talk

Benefit: Helps others, builds reputation Risk: Exposes failures publicly

Veja também🔗

• Tutorial: Como Escrever GDD — planning projects
• Balanceamento com Planilhas — lessons in numbers
• FAQ — common questions

Referências🔗

• GDC Vault — acervo de palestras da Game Developers Conference.
• Fullerton, Tracy (2004). Game Design Workshop. CRC Press. ISBN 978-0-240-80974-8.