项目沟通计划就是一张简短的表，写清楚项目的哪些事该让谁知道、多久一次、走哪个渠道、由谁负责去说。我的这份一页纸就装得下，每类受众占一行，从开发团队一直到CEO。下面是我开一个软件项目时会先拿出来的版本，还有我一直在记的、关于项目沟通怎样才真正管用的笔记。
我被拉去救火的那些项目，烂摊子多半不是烂代码造成的，而是该知道的信息没能及时传到该知道的人那里。在公司开始带项目之后，我一直在记笔记：如果哪天坐上CTO的位置，沟通该怎么管。这里整理出来。
先定好谁需要知道什么#
不起眼但打底的东西是沟通计划：谁需要被告知、需要什么信息、多久一次、走哪个渠道。每个项目开始时就该定下来，而且要落到具体人头上——沟通一旦成了"大家的事"，就成了没人管的事。利益相关方也一样：理清谁真正关心这个项目，摸清每个人喜欢的汇报方式。发给CEO的更新，不能跟发到开发频道的一模一样。再定几条明文规则：多久之内该回复、什么算紧急、哪个渠道干什么用。所谓"沟通问题"，多半只是没说出口的期待对不上。
一份软件项目的沟通计划示例#
这是我会先拿来用、再按项目调整的版本。每一行是一类受众，不是一场会议：
| 受众 | 需要知道什么 | 多久一次 | 渠道 | 由谁来说 |
|---|---|---|---|---|
| 开发团队 | 正在做什么、卡在哪、会改动代码的决定 | 每天 | 站会和团队的聊天频道 | 技术负责人 |
| 产品负责人 | 离Sprint目标还差多少、范围上的疑问、新出现的风险 | 每周两次，范围一变就说 | 简短通话或聊天里单开一个话题 | 项目负责人 |
| 管理层 | 一句话的现状、工期或预算上的风险、需要他们拍板的决定 | 每周 | 一段话的书面更新 | 项目负责人 |
| 销售、客服和运维 | 要上线什么、什么时候上、对客户有什么变化 | 每次发版 | 发版说明 | 产品负责人 |
| 用户或客户 | 有什么新东西、接下来要做什么 | 每次发版 | 更新日志或应用内通知 | 产品负责人 |
| 所有人 | 定了什么、为什么这么定 | 定下来的时候 | 任务跟踪系统或wiki里的决策日志 | 做决定的人 |
表格下面写规则，越直白越好：紧急指的是挡住了发版或者影响到客户，这时候直接打电话，别发消息；问题在聊天里问，决定记进任务跟踪系统；一个工作日内回复。决策日志我用的是决策文档，以GitHub Issues的形式保存，跟具体的工作放在一起。
这种计划能不能转起来，关键在两点：每一行的最后一列都写着一个具体的人；给管理层的更新是写下来的，不是口头说的，这样转发出去也不会丢信息。
工具和节奏#
工具没有大家争论的那么重要。聊天用Slack，任务用Trello，需要见面聊就开Zoom——选个适合团队的，赶紧翻篇。更要紧的是节奏：敏捷团队就每日站会，周期长的项目就每周同步，然后真的坚持下去。还有，把东西写下来。决定、变更、待办事项，记进Notion或Jira，当成流程的一部分，而不是事后补的作业。半年之后，大家唯一的记忆就是那份文档。
软的部分才是硬骨头#
上面说的都是机械层面。更难的在后头：问问团队现在的沟通方式到底管不管用，不管用就改。还有培养人——团队成员背景各异，有的人还没见过一个运转良好的项目长什么样。认真听别人说话，而不是等着轮到自己说；冲突要趁小趁早处理。而且这些问题解决一次不算完，上个季度好使的办法会悄悄失灵，只能定期回头检查。
分布式、异步开发团队怎么协作#
如果你的团队是远程或以异步为主，这个演讲值得一看：
这些我自己也没全做到——没人能全做到。但回头看，进展顺利的项目大都占齐了这几条，而让人头疼的项目至少缺了三条。