IT项目管理第一招：摆正心态，做好沟通_it项目经理 沟通

这个系列的开篇早早写好了，但是好长时间没想好这第一招是什么。我自己想的是第一招必须是非常关键和重要的，想来想去觉得对于一个程序员来说，如果要转项目经理，最重要的是要摆正自己的心态，做好自己的心理建设，让自己的思想先做好准备。第二就是从面向机器工作和面向人工作的转变，最重要的问题就是要做好沟通。所以，我决定把第一招命名为：摆正心态，做好沟通。

摆正心态

很多IT项目经理都是从程序员转行的，所以对于程序员来说，摆正心态，或者说是改变自己看问题的方式，接受不一样的工作方式和理解项目的基本原则是第一要务。

对个人目标负责 vs 对团队目标负责

程序员一般来说是搞定分到自己手上的需求，写出高可用的代码，基本上一个人可以从头到位搞定，所以往往看到程序员们都是扣上一个大大的耳机，沉浸在自己的工作当中。
而项目经理要思考的问题是如何群策群力的打胜仗，他需要协调一定规模的团队去达成目标，这个目标往往不是一个人能搞定。而项目经理是对这个团队目标负责的。

机器 vs 人

程序员的大部分时间是和代码，计算机打交道。而项目经理大部分时间是和人打交道。机器是确定的，理性的；而人是有情绪的，感性的。以对待机器的方式去和人打交道肯定是行不通的。
所以，了解团队里的人，了解团队里人的想法，怎么去了解团队里人的想法都是项目经理需要思考的问题。
让团队保持在一个好的工作氛围中，是项目经理必须做好的功课之一。

不要事必躬亲

程序员老鸟们成为项目经理后，面对问题往往喜欢自己扑上去解决。这当然很好，体现出了老鸟的价值，有项目成员求助时，老鸟们会说到：“来来来，我来帮你”，直接上手解决问题。但是这不是一个项目团队好的运作方式。
成员赋能，这是一个项目经理需要考虑的问题。
很多情况下老鸟们会说：“有这个时间教他，不如我自己搞完来的快些”。确实，面对一个人的一个问题时，这种方式确实会快些，但是如果你的团队有5个人，10个人，或者50个人呢？你还忙的过来吗？这样会使自己成为整个团队的瓶颈。
一个好的办法是在团队内部做好知识沉淀，讲脑袋里的知识和经验文字化，并留出新人成长的时间。磨刀不误砍柴工。

承认技不如人

孔子说过：“三人行，必有我师”。没有人会熟悉所有领域的知识，就算你博古通今，上知天文下知地理，也一定有某个人在某个细节上会强过你。所以，承认自己不是所有东西都知道，所有技术细节都清楚，这是程序员向项目经理转型的一个必要的心理建设。只有这样，你才能调动起团队内的专业人才一起为项目出力。
此时，项目经理需要做的评估技术方案的可行性和难度，而不是陷入技术细节，这其实对项目经理的技术能力提出了更高的要求。
不要让自己的技术水平和认知成为整个团队的天花板。

项目管理的重要原则：天下没有免费的午餐，也没有完美的项目

在程序世界中，程序员们都知道一个道理：天下没有免费的午餐。在工作过程中有很多做平衡的决策：是选择成熟的框架还是需要更加灵活的原生代码；是优先查询优化还是优先插入删除的优化等等。和程序世界里的平衡一样，在项目管理的世界中，也有一个关键的平衡点需要项目经理时时刻刻去做取舍，这个平衡点是什么呢，在这里需要拿出来好好讲一下：
一个项目可以简单看作是：为完成某一独特产品或服务所做的一次性努力。这句话不需要记住，但是从这句话中可以抽象出项目的几个关键属性，或者说要素：

• 目标&范围。也就是某一独特产品或服务，这对于项目来说至关重要，没有目标的项目就像是一个无头苍蝇，不知道从哪里来也不知道要到哪里去。接下来，一个项目通常是一个大的目标，我们需要对其进行拆解，拆分成一个一个的小目标，这样才能进行落地和跟踪。这样的一个大目标+小目标就形成了项目的第一个要素：范围。
• 时间。定义中提到了项目是一次性的，也就是说项目是有开始和会结束的，或者说项目是一个时间段，这个时间段就是项目的时间要素。
• 成本。努力两个字就表示一个团队在这个时间段内，对需要达成的目标付出的成本。这个成本包括了时间，金钱等各方面的成本。

这三个要素组成了一个不可能三角：

也就是说，如果需要达成某种质量目标，范围，时间和成本中不可能都满足，想增加范围，就必须增加时间或者成本。想要减少成本就必须减少范围或者增加时间。
拿上一篇的那个需求打架的例子来说，在固定时间窗内的补丁版本，也就是说时间这个要素是固定的。那么我们只能从范围和成本这两个手段上入手。而任何一个团队或者说公司都是需要控制住成本的，或者说成本是有限的；所以，解决这种问题的的方案一般来说只有一个，范围的取舍。也就是说，必须在需求范围中根据优先级来做取舍。那又根据什么来做优先级排序呢？每个人都会说自己的需求是重要的，这就需要引入另一个关键因素了：项目目标。我们只有精确定义好了项目目标，并认真理解了这个项目目标，才能有效的定义好需求的优先级，从而指导范围的取舍。具体怎么制定项目目标，我们在本文的后面会提到一些。
如果真的讨论后发现，确实需求都重要，无法再次挑选，那么去协调更多的人力争取更多的资源，或者说协商一个更加合适的时间就是考验项目经理能力和经验的时候了。
也就是有了这个不可能三角，让项目管理充满了不确定性和各种可能性，更高层次的来说称为一种管理艺术：一种平衡的艺术。
认识到项目的这个平衡性，是程序员向项目经理转行的一个重要心理建设，所以将这部分内容放在了摆正心态这里，程序员出身的技术极客们，必须认识到合适的技术才是好的技术，没种技术方案都是有其成本在，项目经理必须将这个成本考虑在内。

做好沟通

沟通原则

我自己对沟通的原则有两个：

1. 就事论事，平等地进行讨论。这个不需要多说。
2. 双向。在项目过程中，这个是最容易被忽视的，项目经理在过程中往往是说的多，听的少。在沟通过程中不能忽略掉反对意见，这极有可能是一个项目的风险；特别在几乎所有人都赞成时的反对意见，这个时候的反对意见就尤为重要，所谓“众利勿为，众争勿往”。
   建立健康的双向沟通对团队成员的存在感和成就感都会有很大的帮助。

沟通对象及内容

项目从来都不是一个人的事情，所以一个项目经理最重要任务之一就是对接好这些和项目相关的人：我们称之为干系人。而项目经理的重要任务就是做好和这些人的沟通工作。
项目经理在整个项目过程中需要协调这些人一起推动项目往前，其中的一个关键问题就在于如何在这些人中将信息同步。
我们可以按照沟通方向来分

1. 向上沟通。从一个项目结构上来讲，项目经理大概位于这么个位置：
   

那么，项目经理向上沟通一般来说就是和项目赞助人来沟通。这个项目赞助人可能是一个人，也可能是一个组织。
这里提到的沟通的一个前提是同步信息，而不是其他的内容。在向上沟通中，主要有如下的几个注意点。

• 不要陷入细节。程序员出身的项目经理在这个问题上最容易犯的问题就是和上级沟通技术细节。巴拉巴拉讲了一大堆技术问题，可能十多分钟了还没说明白你要表达的意图是什么。我个人的经验是：向上沟通最重要的首先讲结论。比如你的项目要延期，那么先说项目要延期多久这个结论，如果上级有心想知道细节，再描述为什么延期的理由。如果需要申请资源，同样的道理，先说需要多少资源，再阐述技术上或者其他方面的理由。
• 数字化。尽量避免使用很多，少量这种非常模糊的字眼。因为你觉得的多，不一定是上级觉得的多。比如说一个版本有多少问题单，比较好的一个方式就是一共多少，重要的多少，已解决多少等等；而不是说这个版本问题单不多，问题单还可以这种描述。这样大家都可以针对数字来讨论，而不是感觉。
• 提出问题的同时给出可选方案。在上级面前，最熟悉最专业的是你，如果只提出问题而不给出可选方案。问题很容易就聊死在那里了。

2. 向下沟通
   从上面的结构上来看，项目经理向下沟通就主要是和项目组成员沟通了。和向上沟通不同，向下沟通的频次就会多很多，每天，每小时，每时每刻都会有。同样，也有几个注意事项：

• 明确地提出自己的要求。分配任务时，必须非常明确地传达自己的指令。何时(when)何地(where)需要完成什么事情(what)，为了让成员更好的理解你的指令，必要的时候还需要指出为什么这么做，这么做的目的是什么(why)。看下下面两个例子：
  1. 项目经理A通知成员B准备一份材料：“这份资料很重要，你回去整理一下，一定要尽快准备好”。这句话说了等于没说，很重要是有多重要，特别是尽快这个含糊的字眼，尽快是要多快？每个人对这个尽快理解都会不一样。如果换成：“这份资料是下周一向XX汇报的材料，需要把最近我们项目的进展整理一下，我需要在这周四准备好，周五我们可以一起核对一下内容”。这样的话，最起码你的成员是会和你在时间上保持一致，对材料的重要性有自己的判断。
  2. 有这一个例子：某项目经理让一位女性成员把某文件“漂亮地装订一下”。接到任务后，这位女士按照自己的理解，把白色A4纸打印的文件包上红色的皮，再别上了一个粉色的蝴蝶结。结果只能是让项目经理哭笑不得。因此，自己的指令必须是言简意赅，特别是不能有歧义。
     简单的说，就是不能理所当然的认为自己知道，别人就一定会知道。必须反复的进行确认，达成一致的理解。
• 如何合适地否定成员的意见。团队中需要每个人的意见，但是项目经理肯定不能是个软耳朵，来一个人就听一个人的意见。在项目经理这里是必须要有取舍的，那就意味着你会否定某些人的意见。在自己想清楚了之后，必须和当事人以互相***尊重***的前提将意见沟通清楚。可以从意见方案的某个点进行推演，在推演的过程中去发现对方意见的缺点和不足，从而从道理上来否定这个意见，切记不能直接去否定成员的意见而不给出任何的解释。
• 如何协调成员之间的意见。任何的一个问题，都会有不同的意见和方案。如何项目组的两个关键成员各执一词，给出了不同的方案。作为项目经理如何去协调，也是沟通的一个关键。这种问题的解决没有固定答案，我自己的总结是：
  第一，倾听双方的详细意见，并一起推演出意见的优缺点。
  第二，根据项目目标和当前情况进行分析。这个地方就凸显出项目目标的重要性了，你的项目要做成什么样子，只有对这个事情有深刻的理解，才能做好取舍。
  第三，引导意见双方将所有意见都摆到桌面上讲清楚。千万不能因为脸面等原因藏住不讲，这样当下是和谐了，但是会导致后续项目过程中的各种不愉快。

3. 另外，还有一个横向沟通和对外沟通。横向沟通是指一个项目过程中，横向沟通主要是和其他项目组或者项目支撑部门进行沟通。
   上面提到的几种沟通都是和项目内部的人沟通，而对外沟通是指对企业外部，比如客户，供应商，合作伙伴的沟通。这两种沟通对于技术项目而言，相对上面两种情况会相对较少，所以这里就不展开说了。

怎么做好沟通

3F倾听法

沟通方法有很多种，怎么去说的也不想讲，只想在这里介绍一下我认为很有用的方法：3F倾听法，也就是先学会怎么去听。
所谓3F，就是：

• FACT，事实
• FEELING，感受
• FOCUS，意图
  简单的说，就是听出对方讲的事实，基于事实去体会对方的感受，从而理解对方的意图。只有理解了对方的意图，才能去有的放矢的沟通。
  引用网上的一个例子：

1. （背景）某项目原定于 6 月 7 日完成，可是实际到 6 月 9 日才完成，
   于是研发经理刘备就找负责的工程师张飞沟通。
   刘备说：“咱们这个项目按计划 7 号完成，你 delay了两天也不跟我说一声，我是最后一个知道的！”
   张飞说：“我跟负责项目的产品经理孔明说了啊，他也觉得没问题，大家没有异议就行了呗，项目不是成功发布了吗！”
   刘备说：“那也应该提前跟我说一声啊，我如果提前知道就会让子龙来帮你，最后也不至于 delay两天。”
   张飞说：“我觉得我能搞定，你不要动不动就让子龙来帮我，这是对我的不信任。要不是最近孩子生病我也不会 delay。即便 delay了，我也和合作方都沟通好了，什么事都没耽误。而且我已经尽最大努力了啊，你还要怎么样呢？信不过我的话，下次这样的项目你交给二哥去做吧！”
   刘备说：“我就是想让你提前告诉我一声，你急啥！”
   张飞说：“你先急的好不好！”……

2. 再看看另一番对话：
   刘备：
   “(Fact1)老张啊，虽然这个项目delay了两天，(Fact2)但我知道你最近压力大，一个人当两个人用；
   (Feeling1)看你这么幸苦做大哥的我过意不去，并且我手上就你们这几个可靠的兄弟，千万不要有个三长两短。
   (Focus)如果下次还有类似的情况一定提前告诉我，这样一方面我可以给你加人手，你不用这么累；另一方面可以保证项目不delay；可否？”
   张飞：
   “(Fact)大哥，项目delay两天主要怪我没有处理好。
   (Feeling)我知道大哥日理万机，不想拿这个项目打扰你，我也想用这个项目证明我的能力，没成想变成delay两天，还好PM觉的问题不大。
   (Focus)多谢大哥对我的理解和信任，以后在有类似的问题我会提前跟大哥沟通”

自己体会吧。

会议

很多程序员出身的项目经理很不喜欢会议，认为会议是浪费时间。其实会议在项目过程中是一个很重要的沟通过程。我认为会议的两个主要目的是向下传达信息和向上收集信息，并将这些问题同步至必要的项目干系人。如何开好一个会是一个很大的话题，不过简单来说是关注三个点

• 会前。
  第一要想好会议的目标和主题，预期要取得什么样的效果，
  第二要想好参加会议的人员并控制在最小范围，提前通知会议相关人员准备材料。
  第三在会前与关键与会人员针对会议议题做好沟通。
• 会中。
  第一在会议开始时明确会议目标于议程。
  第二是尽量让每位与会人员都发言
  第三是会议结束时的口头总结
• 会后。
  形成会议纪要并知会与会人员。
  最重要的一点是，会议的结论要有执行计划，否则会议结论会成为空中楼阁。

搭建沟通渠道

一般的项目来说，固定的几个沟通渠道，比如项目例会，启动会，关键节点的评审会等等都是非常有必要的，不是为了开会而开会，开会的目标是做好信息同步和收集。