我被拉去救火的那些项目，烂摊子多半不是烂代码造成的，而是该知道的信息没能及时传到该知道的人那里。在公司开始带项目之后，我一直在记笔记：如果哪天坐上CTO的位置，沟通该怎么管。这里整理出来。

先定好谁需要知道什么

#

不起眼但打底的东西是沟通计划：谁需要被告知、需要什么信息、多久一次、走哪个渠道。每个项目开始时就该定下来，而且要落到具体人头上——沟通一旦成了"大家的事"，就成了没人管的事。利益相关方也一样：理清谁真正关心这个项目，摸清每个人喜欢的汇报方式。发给CEO的更新，不能跟发到开发频道的一模一样。再定几条明文规则：多久之内该回复、什么算紧急、哪个渠道干什么用。所谓"沟通问题"，多半只是没说出口的期待对不上。

一份软件项目的沟通计划示例

#

这是我会先拿来用、再按项目调整的版本。每一行是一类受众，不是一场会议：

表格下面写规则，越直白越好：紧急指的是挡住了发版或者影响到客户，这时候直接打电话，别发消息；问题在聊天里问，决定记进任务跟踪系统；一个工作日内回复。决策日志我用的是决策文档，以GitHub Issues的形式保存，跟具体的工作放在一起。

这种计划能不能转起来，关键在两点：每一行的最后一列都写着一个具体的人；给管理层的更新是写下来的，不是口头说的，这样转发出去也不会丢信息。

工具和节奏

#

工具没有大家争论的那么重要。聊天用Slack，任务用Trello，需要见面聊就开Zoom——选个适合团队的，赶紧翻篇。更要紧的是节奏：敏捷团队就每日站会，周期长的项目就每周同步，然后真的坚持下去。还有，把东西写下来。决定、变更、待办事项，记进Notion或Jira，当成流程的一部分，而不是事后补的作业。半年之后，大家唯一的记忆就是那份文档。

软的部分才是硬骨头

#

上面说的都是机械层面。更难的在后头：问问团队现在的沟通方式到底管不管用，不管用就改。还有培养人——团队成员背景各异，有的人还没见过一个运转良好的项目长什么样。认真听别人说话，而不是等着轮到自己说；冲突要趁小趁早处理。而且这些问题解决一次不算完，上个季度好使的办法会悄悄失灵，只能定期回头检查。

分布式、异步开发团队怎么协作

#

如果你的团队是远程或以异步为主，这个演讲值得一看：

这些我自己也没全做到——没人能全做到。但回头看，进展顺利的项目大都占齐了这几条，而让人头疼的项目至少缺了三条。