海外项目里最消耗精力的不是技术问题，而是同一个问题在不同部门有不同的说法， 而且每个说法听起来都合理。
举个真实类型的例子。产品在客户产线出现装配困难：
四个说法可能都对，但项目依然卡着。因为没有人把「问题到底是什么」定义清楚。
不是为了记录下来，而是为了强制三个动作：
| 字段 | 要点 |
|---|---|
| 问题描述 | 只写观察到的现象，不写原因判断。「装配力超出 45N」而不是「来料不良」 |
| 发现来源 | 客户产线 / 内部试产 / 抽检。来源不同，优先级不同 |
| 影响 | 影响哪个节点、影响多少量。要能量化 |
| 责任人 | 一个人名，不是部门 |
| 关闭标准 | 什么条件下本条可以关闭 |
| 状态 | 待分析 / 分析中 / 措施中 / 待验证 / 已关闭 |
「责任人」必须是能调动资源的人，而不是最了解情况的人。 很多时候技术工程师最懂问题，但他没有权限拍板改设计或加预算。 如果让他做责任人，问题会一直停在"分析中"。
清单最容易的死法是：建了一个很漂亮的表，然后没人更新。 我的经验是三条：
统一清单的价值不在于"统一格式"，而在于让责任无法藏在部门名称后面。
问题数量在 50 条以内时，单张表完全够用。 超过这个规模才需要考虑工具化。过早引入复杂系统，反而没人维护。
通常是责任人设置或会议机制出了问题，可以一起看看。