很多同学分不清楚项目经理和PMO，用一句话说，项目经理是要为一个项目结果负责的，PMO是为项目管理体系建设负责的。这里不展开，不明白的同学可以百度一下，有很多非常好的分享。

好的项目经理，或者说有好的项目经理特质的人，对于团队非常重要。好的项目经理是你放心把事情给他都能拿结果的人，是团队真正的骨干力量。

好的项目经理应该有哪些突出的能力呢？主要有三大能力：

1. 方案能力
2. 实施能力
3. 汇报能力

我们一个一个讲下。

一、方案能力

方案能力，就是解决问题的能力，能够找到问题、分析出原因、制定出解决方案的能力，方案的落地就属于实施能力了。

1. 搞清楚真正的问题

解决问题的第一步肯定是先定位问题，这个很不容易。很多年轻的同学冲劲十足，得到一个信息就冲进去做事，可能做了很久才发现自己找错了问题，甚至南辕北辙。

定位问题的方法主要是多问几个为什么，客户给你描述的问题大部分都是表面的，内在的问题需要我们自己去挖掘。

举个例子，有一次客户给我们提了一个需求，让我们做一个批量导入，我们跟客户沟通后才发现这个场景一个月才发生6次，6次手工提交工作量也不大，为什么要做批量导入呢？后来问清楚了才知道，这个场景在录入时有些信息是不完整的，系统是必填的，他们无法录入，所以每次都攒几条数据之后，让研发后台导入，因为导入时没有前台的必填校验，他们就以为“批量导入”就可以不校验，所以提了“批量导入”的需求。从这个例子我们可以看到，客户的问题是他们录入的时候缺少一些字段信息，无法通过系统校验。如果我们再深入问一下，录入的时候为什么没有采集到这几个字段，可能就会发现更深层次的问题，有可能是业务流程的不合理。所以，多问几个为什么，不放过任何可疑点。

2. 探查背后真正的原因

搞清楚问题的同时，大部分原因也都就清楚了，但是这里面会有一些坑。我们经常会遇到一些反常识的问题，这里面大概率都是坑。比如，我们都知道从A走到B直线最近，但是现在为啥A没有直接到B，而是绕到了C呢。很多同学不去探究这背后的原因，就会吃大亏。更有一些同学，大骂 “前任”傻×，把这么简单的事情搞那么复杂。

遇到这类的问题，我们一定要把背后的原因给搞清楚，有可能是几种情况：

• 历史上的临时方案，没有来得及改，这种情况改了就好
• 有特殊需求要求如此，不得已做的，现在这种情况已经不存在了，可以改回来
• 特殊需求要求如此，现在依然存在，那就要考虑修改的方案，是特殊需求单独处理，还是继续保留现状
• 历史上的特殊要求，但是现在不知道还需要不需要，这种情况最麻烦，要么盘点清楚，要么做好验证

总之，遇到历史问题只要做到“认真细致、不自大”，一直探查到背后真正的原因，就能给出合适的解决方案。

3. 评估各种解决方案

找到问题、找到问题背后的原因，很多方案也就呼之欲出了。一般情况下，我们会遇到两类问题，一类是关键影响因素多，不知道先做什么后做什么；一类是问题比较清晰，但是解决需要较长时间和投入，怎么办。

对于第一类问题，基本思路是“假设-验证-推广”，先根据自己的经验做出一个假设，然后小范围试点，试点通过了再推广，试点不通过就换一种假设。或者干脆做一个对照组，同时验证不同的假设。

对于第二类问题，一般情况下，需要做长中短期规划，对于业务着急的问题，短期如何快速解决，同时中长期如何进行能力迭代。

对于客户来讲，不论内部客户和外部客户，一定是希望短期内有所改善的，所以一般情况下先短期内通过打补丁、临时方案解决问题，再规划长期去解决流程、机制问题。

4. 识别关键路径

大致的解决方案定下来了，基本上自己心里就有数了，识别出关键路径，是让别人心里有数。

识别关键路径，是一个项目可能是多个方向并行、多个角色分头行动、或者多个阶段进行，我们要把最关键的那些举措识别出来，并且明确每个关键举措的目标。比如你要推行一套新的需求管理体系，关键举措可能有新体系设计和发布、需求管理工具的落地以及在某个部门试点跑通。

关键路径定下来了，基本上项目大的计划就出来了，剩下的是把各种辅助目标达成的任务加入到项目计划中。

5. 考虑风险和成本

最后，还是要考虑项目的风险和成本投入。

风险，核心是识别一些项目各任务、干系人、资源投入等方面有没有风险，风险大致分几类。一类是可能存在的阻碍性风险，比如技术攻关，存在一定的风险无法攻克，这种有没有PlanB；一种是可能存在的非阻碍性风险，比如工期预估不准，或者资源投入不足，都会导致延期，项目经理要及早识别这些风险，并且尽量规避。

成本是大部分人会忽略的，尤其是项目都使用的内部资源的时候，大家可能意识不到内部资源也是成本、甚至更贵。所以一个好的方案，一定是在成本可接受的范围内，尽量解决客户的问题，如果不限制成本，那可选择的方案就多很多。

二、实施能力

实施能力，有点类似大家通常说的项目管理能力。但是我觉得比项目管理能力要更贴近业务一些。项目管理能力，给人的感觉是一种普世能力，有了项目管理能力，什么项目都能管理，其实不是这样的，要想管理好项目，必须有业务上的积累，不能只停留在PMP层面。概括地说，项目经理首先是业务专家，其次才是项目管理专家。

实施能力包括了几个方面的内容：

• 理解项目的定义
• 做好立项
• 项目过程管理
• 项目结项与评估

1. 理解项目的定义

项目经理，首先还是要了解什么叫项目，为什么要按照项目来管理。

项目，就是要攒一伙人、在一段时间内、做成一件事，这三个要素缺一不可。我们经常看到的几类事情，都不能算是项目：

第一类，是日常持续推进型的事情，没有很明确的时间段和目标，比如需要攻关，可以启动一个项目，设定一个具体的时间和目标。例如系统的运维，每天都在进行，就不算项目，但是如果我们希望通过一段时间的攻关，把系统的反馈量降下来，就可以启动一个专项项目，目标是3个月系统反馈量降低50%。

第二类，定期重复的事情，一般不按照项目来管理，但是可以根据事情大小来决定是否分别作为项目来推进。比如新人培训，如果每个月都要搞一次，这就不能算一个项目。但是如果每次培训环节很多，干系人、合作方很多，那么每次培训活动都可以作为一个项目来推进。

第三类，没有强时间要求的事情，不建议作为项目来管理。有些事情一个月做完也可以，两个月做完也可以，那就不要当做项目来管理，即便立成了一个项目，也没有那种目标的紧迫感，拖拖沓沓的也没有起到任何作用。

第四类，运动式的工作不要作为项目，运动就是运动，需要造声势、重激励、强仪式感，本质上并不是通过科学的管理达成项目目标，所以虽然形式上类似项目，但是本质上不是项目。

最后，大家要思考一点：一件事作为“项目”和不作为“项目”，有什么变化吗？如果通过项目化的规范管理，能有效提升项目的成功率和质量，那是有意义的，如果只是希望通过“项目”获取一些额外的激励，那就是为了“项目”而“项目”，没有意义。

2. 做好立项

立项这个动作非常重要，更重要的是立项前的问题分析洞察。曾经有一位老板跟我们讲，他希望项目组花三分之二的时间在立项上，剩下三分之一的时间做项目。虽然听起来有些夸张，但是一语道破立项阶段的重要性。

立项阶段，做的最重要的事情，本文第一部分已经详细说了，即找出真正的问题，找出问题背后真正的原因，制定相应的解决方案，比较方案的优劣势，识别出关键路径和风险，最后做好成本收益的评估。

做好这些工作后，立项会议其实是一个共识的场合，需要所有项目成员、干系人和赞助人都理解项目的重要意义，要解决的核心问题，大家的如何协同推进。最关键的有几点：

• 鼓舞士气，尤其是老板的站台支持就很重要
• 锁定资源，一些核心资源一定要有保障
• 目标澄清，大家对目标有一个共识
• 责任认领，让每一个负责人清楚自己的目标和压力
• 提前暴漏一下风险，让大家一直有意识去规避和解决

立项会议本身还是一个项目经理“汇报能力”的体现，在第三部分里我会简单再展开一下。

3. 项目过程管理

项目过程过程管理，反而是PMP里的主要内容，核心是通过各种科学管理手段来消除一切不确定性，让项目过程和目标可控。结合以往的经历，有一些好的做法推荐给大家：

• 责任到一个人，这个非常重要，每一项工作责任人只能有一个，如果是多个人做，那也必须有一个人对结果负责，一个任务如果没有一个人明确知道自己对这个事情负责，那就是没有人负责；有时候当你把一项任务安排给一个人、他拒绝的时候，反而会反映出团队合作的问题
• 合理的项目会议、汇报制度，项目紧张的时候可以通过日会来每日跟进，一般情况下可以通过周会和双周会来同步进度，但是一旦开周会和双周会，就要避免平时不沟通只有周会上沟通的错误做法；合理的汇报制度，是定期向老板汇报，也会给团队制造一些良性的压力
• 会议纪要和TODO跟进制度，会议一定要有纪要，尤其是反复讨论、踌躇未决的事情，一旦有结论，就要正式通报全项目组，甚至有必要翻来覆去强调多次；TODO的及时跟进解决是避免项目延期的有效手段，TODO尽量每天跟进，一周没有进展就要升级，这样就不会造成项目更大的风险，很多事情是前后关联的，一件事情延期就会导致连锁反应
• 即时激励，项目经理要花一些时间去激励团队，尤其是即时激励很重要，当攻克一个难题，当取得一个小目标，当收到客户的正反馈都要及时同步给团队，鼓舞大家的士气；阶段性地，跟大家一起聚聚餐，举办一些团体活动，都有助于增强团队凝聚力；当然老板的鼓励，和给老板汇报过程中对团队成员的表扬，效果会更好；最后项目顺利结项，要让大家都有精神和物质的激励
• 及时复盘，每经历一个小目标或者一个小挫折，都及时让团队停下来做一下复盘，复盘不是论功行赏、更不是秋后算账，是大家一起看下哪些事情做得好，为什么做得好，什么措施发生了意想不到的效果，能否推广；哪些事情没有达到预期效果，是措施不对，还是执行不彻底；大家合作上有没有问题，流程、信息是否通畅；当然也可以略微表扬一下表现非常突出的成员和子项目以表示肯定

以上都是通过项目实践中总结出来的，希望对大家有用。

4. 项目结项与评估

项目的结项和评估，是普遍被忽略的缓解，我觉得大部分项目做的都不好。项目做到尾声，只有做了结项和评估才算阶段性结束。

结项需要做什么，结项包括两部分，一部分是交付内容的评审，比如目标达成情况、交付的文档制度等等。另一方面是一个整体回顾和总结，在结束之前回顾一下我们项目出发的时候的初心是什么，我们的策略是什么，策略生效了吗，发生了什么变化，目标是什么，达成了吗，优秀实践有哪些，缺憾和教训有哪些，这部分回顾和总结反而比交付内容对项目成员更重要。

项目的评估，是对项目实际达到的效果和投入的成本做一个评估，有些项目刚做完可能还没有明显效果，所以评估需要过一段时间做才有意义。我认为评估的阶段，要勇敢面对现实，我们的项目按照时间和任务是做完了，但是问题被解决了吗，我们看到现实世界发生了什么变化，符合我们的预期吗？

项目评估的另一方面是成本收益评估，即ROI，我们的投入是否值得。经历过一些项目是不敢看成本的，有一个项目按照产研投入大概需要60万，实际上如果增加人工去做的话，大概2个操作人员就够，基本40万就可以了，肯定是不划算的。有些人可能会反对，说两年就划算了，不就节省20万了吗？账不能这么算了，你今年投入60万，明年就不需要一点投入了吗，按照我们的经验，只要做一个系统，后面是无穷无尽的投入，因为业务也在持续变化，系统就要相应调整，调整两年业务发生大变化，系统就不得不推倒重来，所以很多项目的投入是根本不可能回本的。这还不算投入的硬件费、网络费、运营投入等费用。

所以一般情况下，我们看一个项目的投入，不考虑后期大的版本迭代升级，可以参考市场上软件公司的计费方式来计算：

初期的投入人力成本 + 维保期投入人力成本 + 正常运维投入人力成本 + 硬件网络持续性投入成本

如果考虑每年的需求迭代，基本每年还要增加½或⅓初期建设投入的人工成本。

用一个实际例子来算，如果一个项目初期投入了5个人，做了两个月，总计10人月，大概人力成本约50万；假设每年硬件和网络成本5万；维保期大概2个人月，约10万；日常运营每月3万。以上在不考虑第二年的需求迭代情况下，一年投入是89万，两年是130万；如考虑第二年的需求迭代，则两年投入是150万~160万。所以，如果这个项目目标是线上化提效，节省不了8人年，就是赔本的。

还有些同学会说，线上化代表着管理水平提升，我们有数据了，可以做分析了，能够预测什么的。我只想说，那都是理想很丰满，现实很骨干，很多公司建系统，只是实现了原来手工做的事情线上做，没有做流程优化，没有引入先进管理经验，结果管理水平没提升，线上数据也没啥用，常常线上做一套，线下还要做一套，实操同学苦不堪言。所以说数据有价值的，先通过Excel把价值发挥出来再谈上系统的事，没有数据化思维，神仙都救不了你，别难为系统了。

所以我总结一下项目结项和评估做的不好可能有几个原因：

• 有些项目是不敢结项，因为项目效果不好，远不及预期，觉得不好交代
• 有些项目是ROI太低了，花了10个人的资源省了1个人的工作，哪好意思说
• 有些项目是管理不善，没啥管理措施，交付东西也平平常常
• 有些项目是合作不好，互相推诿扯皮，也就没有结项和评估的动力

一个好的项目经理一定要敢于面对项目的结果和ROI评估，才能得到快速的提升。

三、汇报能力

汇报能力，是大家往往忽略的一块，有些人觉得我做事做得好就行了，看结果就行，其实没有那么简单。

好的汇报，是争取项目资源的关键环节。很多项目，只有项目中的人知道项目的重要性，外人是不知道的，你不汇报，尤其是让高层老板知道这件事的重要性，就很难投入足够的资源，别人的配合也不会那么积极，这本身就是很现实的问题。

好的汇报，是团队盘整的重要环节，该表扬的表扬，该批评的批评，该施压的施压，该让老板站台的就要站台。

怎么才算一场好的汇报呢，我总结了几点：

1. 目标清晰

每一次汇报，要知道这次汇报的目标是什么，比如有些汇报是为了争取、锁定资源，有些汇报是让老板重视、帮忙协调，有些汇报是让老板对关键点进行决策等等。

你所有的汇报会的组织都要围绕目标推进，谁汇报，重点讲什么，议程怎么安排，要请那些人，怎么能够不知不觉达到目的。

2. 内容扎实

每一次汇报的主汇报内容，一定要足够扎实。

• 如果是讲方案，那就把方案前因后果、长期意义都讲清楚，当然也要考虑负面影响
• 如果要讲进度，重点讲那些做的好的，为啥做的好
• 如果要报风险，那就重点讲预期有风险的地方，让大家一起了解并应对
• 如果要让老板决策，你就要把老板关心的、支撑他决策的内容都准备充分，而且尽量事前沟通过，不要会上给惊喜

3. 兼顾感受

汇报，一方面是要达成项目经理对于项目推进的目标，另外一方面也要兼顾项目各方对于汇报会的期待：客户关心什么、老板关心什么、成员关心什么、支持方关心什么。如果不知道大家的期待，很有可能事与愿违。

• 对于客户来讲，项目是否还在正常推进中，有没有风险，他们的担忧你们有没有充分考虑
• 对于老板来讲，他对这个项目有什么期待，项目是否能够解决他的问题，项目当前是否验证了一些假设的成立等
• 对于项目成员来讲，汇报中自己那部分是不是完成的很好，是不是收到了点赞，还是说横向比还有差距，需要更加努力
• 对于支持方来讲，他们的支持是否得到了肯定，他们的老板知道吗…

汇报也需要让大家有参与感，比如让一线用户反馈一些实际的声音？让优秀的子项目介绍介绍经验？让老板多给一些指导和点评？ 汇报切忌变成进度同步会，把所有事情进度同步一下就完事，那样就浪费了一次汇报机会。