PD · PB · 279
全要素单一事实源
Canonical Everything · canonical-everything--naomi-gleit
解决什么问题
复杂跨职能项目中,信息分散在数百个文档里,沟通渠道混乱,团队成员对基本事实理解不一致,导致大量时间浪费在误解和对齐上。
核心内容
Canonical Doc(唯一权威文档):每个项目必须有一个 canonical doc,所有人知道它在哪里。它包含:
- Work streams:项目的离散工作领域
- Single-threaded owner (STO):每个 work stream 有且仅有一个负责人;work stream 过大时拆分为 sub work stream,每个 sub work stream 也有 STO,递归到底
- Process:团队的协作方式——canonical 会议、canonical 邮件列表、canonical 聊天群,不要反复创建不同受众组合的沟通渠道
- Canonical nomenclature:把所有关键术语及其定义写出来,确保所有人用相同词汇描述相同事物(例如"consistency"=不同审核员之间是否一致 vs "accuracy"=是否正确,两者完全不同)
- Canonical visuals:用可视化框架图辅助理解
会议中的实时编辑:开会时投射一个 visual(如选项表格),当场实时编辑——选中哪个选项、下一步是什么,所有人看着同一屏幕确认。避免会后"我听到的是 A""我听到的是 B"。
编号列表法则:永远不用 bullet list,一律用 numbered list,因为 bullet 无法被精确引用("第二个 bullet 上面那个"不是 extreme clarity)。
避免 pairwise 对话:与其分别找四个人各聊一次,不如把四个人拉到一起开一次会,所有人获得相同 context。
适用边界
Naomi 承认这套方法会被工程师视为"过多流程"。她强调这不是为流程而流程,最终目的是减少会议、加快速度。适用于跨职能、高复杂度项目;小型团队或早期探索阶段可能过重。
关键引述 · 原话
"I ask five different people, get five different answers. That is unacceptable." — Naomi Gleit
关联卡片
与 extreme clarity 理念配合使用;traffic-light-decisions 是 canonical visual 在决策会议中的具体应用。
出处:Naomi Gleit · 03-podcasts/naomi-gleit.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2