project-retrospective

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Project retrospective writer

项目回顾文档撰写指南

Create LESSONS.md files that capture institutional knowledge, especially failures. Think like a journalist writing about your own project—be specific, be honest, name the actual mistakes.

创建用于捕捉机构知识（尤其是失败经验）的LESSONS.md文件。请站在记者复盘自身项目的角度来撰写——内容要具体、真实，明确指出实际存在的错误。

When to use

适用场景

After completing an investigation or project
When shutting down or pausing a publication
Post-mortem for events
Handing off a project to someone else
Annual review of ongoing initiatives

完成调查或项目后
停更或暂停出版物时
活动事后复盘
项目交接给他人时
正在推进的举措年度复盘

The critical section: "The real problem"

核心板块：「真正的问题」

This is the most valuable part of any retrospective. It answers:

"What did we THINK we were building vs. what was ACTUALLY needed?"

Good example:

We built a comprehensive tagging system when users just needed full-text search. Three weeks on features no one used.

Bad example (too generic):

We learned the importance of user research.

这是所有回顾文档中最有价值的部分。需要回答：

「我们原本以为要做的是什么？而实际需求又是什么？」

正面示例：

我们开发了一套全面的标签系统，但用户真正需要的只是全文搜索功能。我们花了三周时间开发的功能无人问津。

反面示例（过于笼统）：

我们认识到用户调研的重要性。

Template structure

模板结构

markdown

undefined

markdown

undefined

LESSONS.md

Project

项目信息

Name: [Project name]
Dates: [Start - End]
Status: [Completed / Abandoned / Ongoing]
Author: [Your name]

名称： [项目名称]
周期： [开始 - 结束]
状态： [已完成 / 已终止 / 进行中]
作者： [你的姓名]

Summary

项目概述

[One paragraph: what it did, what impact it had, why it matters]

[一段文字：项目内容、产生的影响及其重要性]

What worked

成功经验

Technical wins

技术层面的成果

[Specific decision and WHY it worked]
[Tool/pattern that saved time]

[具体决策及成功原因]
[节省时间的工具/模式]

Process wins

流程层面的成果

[Methodology that helped]
[Communication pattern that worked]

[有效的方法论]
[可行的沟通模式]

What didn't work

失败教训

Critical failures

关键失误

[Thing that blocked progress - be specific]
[Wrong assumption and its cost]

[阻碍项目推进的具体问题]
[错误假设及其造成的损失]

Technical debt

技术债务

[Shortcut that hurt later]
[Complexity that wasn't needed]

[后续引发问题的权宜之计]
[不必要的复杂设计]

External factors

外部因素

[Things outside your control that impacted project]

[超出控制范围、影响项目的事件]

The real problem

真正的问题

[This is the most important section]

What we thought: [Initial assumption] What was actually needed: [Reality] The gap cost us: [Time/effort/money wasted]

[这是最重要的板块]

我们原本的假设：[最初的设想] 实际的需求：[真实情况] 差距造成的损失：[浪费的时间/精力/资金]

Recommendations

建议

If continuing this project

若继续推进本项目

[First priority]
[Second priority]
[Third priority]

[首要任务]
[次要任务]
[第三优先级任务]

If starting fresh

若重新启动项目

[What to do differently]
[What to skip entirely]

[需要做出的改变]
[完全可以跳过的内容]

Tech stack verdict

技术栈评估

Keep: [Tools that worked well]
Replace: [Tools that caused problems]
Add: [Tools you wished you had]

保留： [表现良好的工具]
替换： [引发问题的工具]
新增： [当初希望拥有的工具]

Reusable artifacts

可复用资产

Component	Why it's valuable
[Name]	[Specific reuse potential]
[Name]	[Why someone else should use this]

组件	价值所在
[名称]	[具体复用价值]
[名称]	[他人使用该组件的理由]

Questions for next time

后续待解问题

[Unanswered questions worth investigating]
[Things you'd research before starting]

undefined

[值得深入研究的未解决问题]
[下次启动项目前需要调研的内容]

undefined

Voice guidelines

语气要求

Honest, specific, slightly self-deprecating
Like explaining to a friend why the project took twice as long
No corporate speak or blame-shifting
Name specific mistakes, not vague "challenges"

诚实、具体，略带自嘲
就像向朋友解释项目为何耗时翻倍
避免官话套话或推诿责任
明确指出具体错误，而非模糊的「挑战」

What to include vs exclude

内容取舍原则

Include	Exclude
Specific failures with context	Vague "learnings"
Actual time/cost of mistakes	Blame for individuals
Tools that helped or hurt	Generic best practices
Decisions you'd reverse	Obvious statements
Surprising discoveries	Information in other docs

应包含内容	需排除内容
带有背景信息的具体失败案例	模糊的「经验总结」
错误造成的实际时间/成本损失	指责个人
对项目有帮助或造成阻碍的工具	通用最佳实践
希望推翻的决策	显而易见的陈述
意外发现	其他文档中已有的信息

The specificity test

具体化测试

For each item in "What didn't work," ask:

Can I name the specific decision?
Can I quantify the impact?
Would this help someone avoid the same mistake?

If no to any → Be more specific.

针对「失败教训」中的每一项，问自己三个问题：

我能否说出具体的决策内容？
我能否量化其影响？
这能否帮助他人避免重蹈覆辙？

若有任何一个问题答案为否 → 请进一步具体化内容。

Examples of good vs bad entries

正反示例对比

Bad - too vague:

Communication could have been better

We underestimated the complexity

Testing was insufficient

Good - specific and actionable:

Skipped schema validation on data files. Cost: 3 hours debugging a typo that caused silent failures.

Built custom date picker when browser native input would have worked. 2 days wasted.

No error messages when data fails to load—users just see blank screen.

反面示例（过于笼统）：

沟通本可以更顺畅

我们低估了项目复杂度

测试不够充分

正面示例（具体且可落地）：

跳过了数据文件的 schema 验证，导致花费3小时排查一个引发静默失败的拼写错误。

自行开发日期选择器，而原生浏览器输入框完全可以满足需求，浪费了2天时间。

数据加载失败时无错误提示——用户只能看到空白页面。

"The real problem" examples

「真正的问题」示例

Weak:

We learned that requirements can change.

Strong:

We built an admin dashboard for editors when they actually needed a Slack bot. They live in Slack—forcing them to open a web app was friction they'd never accept. The dashboard has 2 monthly active users; the Slack bot prototype we built in a day has 47.

薄弱示例：

我们认识到需求可能会变化。

优秀示例：

我们为编辑开发了一个管理后台，但他们实际需要的是一个Slack机器人。编辑日常工作都在Slack中，强制他们打开网页应用会带来无法接受的操作阻力。该后台每月仅2名活跃用户；而我们用一天时间搭建的Slack机器人原型已有47名活跃用户。

Red flags in your writing

写作中的警示信号

If you find yourself writing these, stop and be more specific:

"Communication is key"
"We learned the importance of..."
"Going forward, we should..."
"Challenges included..."
"There were some issues with..."

These are placeholders for real insights. Replace them.

如果你写出了以下内容，请停下来并进一步具体化：

「沟通是关键」
「我们认识到……的重要性」
「未来我们应该……」
「挑战包括……」
「存在一些……问题」

这些都是缺乏实际洞见的套话，请用具体内容替代。

Journalism-specific templates

新闻行业专属模板

Templates are in the

templates/

directory:

Template	Use for
`research-project.md`	Investigations, data journalism projects
`event.md`	Conferences, workshops, campaigns
`publication.md`	Newsletters, podcasts, ongoing content
`editorial-tool.md`	Newsroom software, AI tools

模板位于

templates/

目录下：

模板	适用场景
`research-project.md`	调查报道、数据新闻项目
`event.md`	会议、工作坊、推广活动
`publication.md`	通讯简报、播客、持续更新的内容产品
`editorial-tool.md`	新闻编辑部软件、AI工具

Template selection

模板选择指南

What kind of project?
├── Investigation/analysis → research-project.md
├── Conference/workshop → event.md
├── Newsletter/podcast → publication.md
└── Newsroom tool → editorial-tool.md

The best retrospectives are written by people who got burned and want to save others from the same fate.

项目类型？
├── 调查/分析类 → research-project.md
├── 会议/工作坊类 → event.md
├── 通讯/播客类 → publication.md
└── 编辑部工具类 → editorial-tool.md

最有价值的回顾文档，来自那些吃过亏、希望他人避免重蹈覆辙的人。