很多程序员升为PM后，发现这个“官”，干的都是“无关紧要”的事——

上午，进度沟通会 

中午，技术实现会 

下午，需求变更会 

晚上，Bug Review 

……

每天做地最多的，就是听不同的人聒噪，哪有敲代码的键盘声来得爽？于是他们就迷茫了，是不是自己根本不适合做管理，应该回到技术序列呢？

我们的故事，是这样开始的……

A公司：创业阶段，刚接到一个新项目，定制化内部管理软件

PM：Patrick，由于开发能力强，刚晋升PM

销售：Sara

工程师：Elsa

客户接口人：Jack

……

Patrick：“小事儿，你直接发给Elsa吧，抄送我一下就好了。”

Sara：“Ok。”

Elsa收到邮件，心想这个需求着实很简单嘛，把手头上的关键代码写完，再处理喽~

很快就到了客户验收的那天。

由于这个项目进展顺利，内部测试结果也不错，大家都信心满满。Sara还特意通过客户接口人Jack，邀请了客户副总一起参与，好加速评审流程，尽快回款。

Patrick打开了软件，正准备激情演示。客户副总冲着自己的接口人发话了：“Jack，咱们换新logo了，你不知道么？”

Jack一脑门子汗，质问Sara：“一个月前就给你新的了，为什么没改？”

Sara看着一样蒙圈的Patrick，强忍着愤怒，和颜悦色地跟客户说抱歉，并承诺半个工作日内，一定完成新logo的修改。

客户副总严肃的态度，让Jack变得吹毛求疵。验收会好歹结束了，但留下一大堆修改意见，也影响了后面客户的整体满意度。

这是个典型的有沟通、没协调的例子。

此话怎讲？我们先来明确一下，到底什么是沟通协调。

“近代管理理论之父”巴纳德（Chester Irving Barnard）认为，“沟通是把一个组织中的成员协调在一起，以实现共同目标的手段”。

这个定义，真是让人惊艳！因为，它挑明了“沟通”与“协调”之间的暧昧关系——艺术色彩的“沟通”与目的性的“协调”。

沟通是为了协调，而协调是为了：

1. 一致理解关键共享信息

2. 做出工作承诺

3. 完成工作

到底怎么沟通协调，才能高效完成项目呢？

管理从无序发展到有序，从没有过程到标准过程。在标准工作过程出现之前，团队成员的沟通协调没有参照，只能依赖个人技巧。这恐怕也是拍马屁能升职的原因之一吧。当标准过程逐渐产生后，我们就要把沟通和协调的部分，定义到工作过程和相应人员的职责中去，最大化降低工作依赖关系间的沟通协调壁垒。这样做，可以识别清楚有工作依赖关系的干系人，明确沟通协调的内容，按照工作流程和岗位要求，获得干系人的工作承诺，从而进行整体的沟通协调计划。大家在整个项目中，也就可以参照沟通与协调计划开展工作了。

从上面的例子我们可以看到，A公司貌似是有流程的，也有明确的干系人关系与职责，Elsa也没不承诺修改。可问题是，Elsa把改logo的优先级放得很低。这时候，对过程的监控管理就显得尤为重要了。作为PM需要将沟通与协调的结果纳入监控管理的范围。监控，也是标准过程的一个部分。说到这里，整个项目内的沟通与协调的管理过程才算完整。

• 识别工作依赖

• 沟通与协调计划

• 沟通与协调的执行

• 监控

尽管说话的艺术对沟通有极大的帮助，但我们无法奢望每个人，都成为语言艺术的大师。因此，在工作的环境中，我们要求的沟通与协调是以完成工作为目标的。

敲黑板，划重点↓↓↓

为了达成这样的目标，同时减少语言艺术等因素带来的干扰，我们要将沟通与协调定义到基本的工作过程中去，并进行管理和优化。

工作过程不仅包含要完成的工作任务，及其之间的关系，还一定要包含执行这些工作任务之间的不同角色的职责与关系。

从实操层面来说，完整的沟通与协调管理，需要关注四个方面：识别工作依赖、沟通与协调计划、沟通与协调执行，以及监控。