PM 成长之路

这是一篇旧文，最初是在 2007 年连载于一个 EAM 论坛，后来这个论坛整体卖给了 erp100，所以文章最后在互联网可见的位置是在http://bbs.erp100.com。可惜，在互联网的浪潮下，传统的软件行业日渐式微，erp100 也已经关闭了，现在只有在去网站时光机（Wayback Machine）才能找到过去的青葱岁月了。

12 年一轮回，把这个曾经的旧文原封不动的搬运回来，2007 年那个时间段我主要做的是能源行业的项目，尤其是电力行业居多，所以文中基本都是以电力行业为项目背景的。由于当时是在论坛连载，所以上下文之间可能会有一些别的帖子中讨论的内容的说明，非要想弄明白当时的语境的，可以用 Wayback Machine 搜索原贴 http://bbs.erp100.com/thread-59258-1-1.html 的快照。

怀念下过去的时光，顺便审视下 12 年前的自己对项目管理的认识。

前言

应浪迹天涯朋友的要求，在本帖中专题进行项目管理过程中有关于与各方协调问题的的讨论，希望能对哪些由技术转型为 PM 的朋友能有一些帮助。

在说项目协调问题的之前，有必要温习下有关项目管理的一些基本知识，了解了这些基本的东西，应该有去理解项目协调工作都要做哪些事情。

项目的定义：项目是为完成某一独特的产品和服务所做的一次性努力。

• 一次性——项目有明确的开始时间和结束时间。当项目目标已经实现，或因项目目标不能实现而项目被终止味着项目的结束。

• 独特性——项目所创造的产品或服务与已有的相似产品或服务相比较，在有些方面有明显的差别。项目要完前未曾作过的工作，所以它是独特的。

项目管理的定义： 项目管理是在项目活动中运用知识、技能、工具和技术，以满足和超过项目干系的需求和期望。项目管理就是把各种资源应用于项目，以实现项目的目标。

项目管理是一个综合类的学科，涉及多种知识领域：

• 项目范围管理

• 项目时间管理

• 项目成本管理

• 项目质量管理

• 项目人力资源管理

• 项目沟通管理

• 项目风险管理

• 项目采购管理

• 项目综合管理

说明：

上述 9 个知识领域是《PMBOK Guide-V4 版》之前的定义，在《PMBOK Guide-V5 版》中最大的变化是从 9 个知识领域扩展为了 10 个，新增知识领域是“项目干系人管理”。

事实上，干系人管理相关的过程，在 V5 版之前是存在于“项目沟通管理”这个知识领域中的。V4 到 V5 版本最重大的变化应该就是从项目沟通管理中拆分出项目干系人管理。一直对“干系人”管理这个工作非常重视，在 2007 年的原始连载中对于这个问题也有具体的说明，就个人而言，我认为 PMBOK 的这一做法是非常可取的。

万一看此文的又正在备考 PMP 的，另外再啰嗦一句。在最新的 V6 版中，将“项目干系人管理”修改为了“项目相关方管理”。嗯，这样写显得更高大上了，在具体的提法上，也做了微调，从：“识别”、“规划”、“管理”、“控制”，调整为：“识别”、“规划”、“管理”、“监督”。

事实上，项目相关方很多是你 PM“控制”不了的，所以改成“监督”似乎是更科学的提法，但是，PM 想要做好项目相关方的“监督”也不是那么容易的事情。这是一件非常考验情商的事情，也是 IT 类项目执行过程中最难最不可控的一个环节，PMP 考试归 PMP 考试，真正项目管理实践中还是要活学活用，千万不要拘泥于经典，尽信书，等于无书。

项目具有明确的目标，且是一个一次性的活动过程，所以项目经理的任务就是去调度资源利用相应的管理成项目，满足或者超过项目“干系人”对项目的预期和希望。

那么“项目干系人”就是项目经理在项目过程中始终要去关注的一些人，因为项目最终的成败，项目的过程人有关系，甚至这些人就能决定一个项目的命运。

还有一点我们必需承认：只要有组织就有政治。哪怕组只要能够称为“组织”，那么这个组织中一定存在着政治。所以，项目经理在项目开始阶段一定要识别项目能察觉干系人之间的 v 政治关系以及你执行这个项目的组织内的政治关系。当明确的找出了项目干系人并识的政治关系，那么项目经理就可以在这些人中间根据需要展开协调工作了。

这是项目协调的最重要的部分，也就是用户协调工作。

我们必需承认在项目实施公司内部由于资源分配等问题，项目经理有必要也必需就这些问题在公司内部展作，这是项目协调中的内部协调工作。

在项目组内部对于任务分配、工作分工等问题，项目经理同样要进行项目组内部协调工作，有时候，这个甚至比用户协调工作更棘手、更难以操作。

项目启动

在项目开始阶段，一般我们都用过一次会议来明确项目的计划等等东西。在这个会议中，同样会成立一个“项目管理委员会”之类的临时机构，这个机构的人员一般由双方项目经理、高层领导等人员组成，主要目地就是有人能够在项目出现关键问题的时候能够商议和决策。不过话说回来，这个委员会一般都是虚无缥缈的，基本就是一个空架子，很少有项目真的靠这个机构来管理问题（双方高层领导如果整天陷入项目中事务性的工作，这个项目恐怕也悬了。），基本还是靠双方 PM 来协调，或者出现具体问题找分管领导协商解决。

不管怎样，这个“委员会”之类的组织中的用户，显然都是这个项目的“干系人”，不是干系人我想他不会答应去委员会。那么这是 PM 们识别出来的第一批“干系人”。还有谁是“干系人”呢？一般来说，主任级别的用户都是我忽略的，尤其是检修、运行、经营、物资这几个部门的一把手（不好意思，只能用电力做例子了。）

下面说下有关政治的问题。我们不能指望一个企业一团和气，企业内部存在 2 个以上的“阵营”是司空见惯的。一企业内部分管你这个项目的领导都是一个副厂或者总工之类的领导。不管是谁管这个项目，作为 PM 你还是首先想清楚这个企业高层之间微妙的关系比较好。知道关你这个项目的领导，在那个阵营有哪些对手、和哪些人关系好哪些中层“是他的人”，这在 PM 日后进行项目运作和项目协调是很关键的。

作为厂级领导，即使看起来分管的是经营、生产或者是总工甚至是管后勤、三产的，并没有进入“委员会”，作为最好把他们都列入“干系人”来管理比较好。

来，回头总结下。 首先找到干系人，简单的说对于电力项目来说，从厂长开始的厂级领导到关键部门的一把手，再加上用户 PM，是项目干系人。

第二步，快速弄清楚企业的政治环境。这事情说起来容易，真要弄清楚还真不好办。因为这本来就是敏感的事愿意给你说清楚啊。我曾经在项目开始的时候去问这些问题，人家的回答：我们厂的事情，给你说三天三夜你清楚。

这里给大家说几个技巧：

1、和用户 PM 快速搞好关系。项目刚开始，大家没有冲突只有美好的愿景，PM 之间搞好关系这个是比较容易的关系好了，通过他的嘴慢慢了解一些信息。

2、在与中层聊天时可以拿同样的问题都问一遍，从他们的答案中去找到暗示。

3、给高层汇报工作的时候，可以问“这事请要不要再给×总（×厂长）汇报下？”听听对方口气。

4、问问项目的销售经理，中标是找的谁帮忙的。这些人不用说将来都是可以帮助你的人。再问问他，投标对手都是谁。这些人不用说，你就时刻小心他们给你坑吧。

关于客户协调的第一步，弄清对象、理清关系就说这么多吧。

项目开工

随着项目的开工，PM 会很快弄清楚项目干系人都是谁，企业的政治情况也大致了解了。那么首先要做的三个重要工作就是：

• 项目计划的协调

• 需求调研的安排

• 基础数据的采集

项目经理的项目协调工作从此就开始了。这个时候的协调工作还是比较简单的，（原因明显：没有矛盾嘛）主要是道理的说服工作。说服用户配合你的基础数据采集这是一个大事，也是重要的事情。这个时候把道理、需求、日后用效果说清楚了，让用户有了对这工作的认识和不太大的期望（期望太高就要出事了！），可能会配合的好一点。PM 最好能够说服用户成立临时的脱产的数据采集小组（但是对于目前的新建电厂的人力情况看，这个基本没指望，于老厂完全可以这么要求，至少要办脱产。），这样才能保证效率和数据的可用性。

对于需求调研，想对顾问们说句话：任何一个流程不要只听一个负责任的描述和解释，否则你就会面临日后需求调可能性。举个例子，对于物资流程，不能只听负责物资的采购或者经营部门的领导和具体办事人的需求，更要听储、检修甚至总工、生产厂长、经营厂长的想法和要求。对于信息化这个工作，每个人的出发点、认识、目地都是的，做为顾问一个事情多问问多看看只有好处。

为了日后工作开展起来方便顺利，建议 PM 利用需求调研的时间充分的和企业各个层面进行业务交流和个人交流（从解目前国内几个 EAM 实施公司的情况看，PM 貌似都没有这么多时间做这个事情，但是，我仍然建议 PM 们花时间下去们认为“没什么可以交流的”这些用户们多吹吹牛。）。一方面可以协助顾问进行需求调研，一方面混个眼熟、套情，日后有事情了，起码人家知道你是做什么的，叫什么。我做一个项目的时候，曾经用了一个月时间，每天杯子好茶叶，装 2 包烟就四处游荡去了。和我认为必要的人：干系人、关键用户等去聊天，吹牛。对于需求不明确的地带着顾问去，帮顾问问清楚了，我继续吹牛。这些时间的浪费，保证了我在项目后期可以去直接协调用户之间的问用户 PM 协调不开的事情，我去游说一番都能搞定。回头看看那时候抽的烟、浪费的时间是不是都赚回来了？

这就是我要说的客户协调的第一方面：广泛打交道，混个脸熟。在混脸熟的过程，这些人的脾气、爱好、说话做事 PM 们应该都能摸透了。那么以后遇到事情去协调，改怎么说话、说什么话不就心中有数了？

当然了，这样的泛泛之交不能解决所有问题，对于客户协调的第二方面就是关注重点用户。具体的做法还是多交流是对于这些人来说，不就是混眼熟这么低要求了。对于他们 PM 最重要的是扑捉到他们对于这个项目的真实看法。（一点不荒唐，表明支持，实际上不希望项目成功的人大有人在。）这些出于用户内心的对于项目的观点、看法，是 P 日后决定项目走向、在关键问题上做出判断的重要依据。

我曾经就遇到这样的事情：用户直接建议我说，D 经理，你还是做做领导的工作把项目验收了算了。上面曾经要求上过一套系统，我们就随便找了一家做了个程序，等上面来检查，就开机让看看画面，里面连数据都没有。我们不软件，现在就挺好。就这样的用户心态，能配合你做好项目？可怕不。当然了，我还是可以再吹一个牛，上周和这目的用户 PM 聊天的时候还提到这个部门，他说没想到当年那么不配合的部门，现在用系统用的最好。我说我也没想但是，用户 PM 不知道我在他不知道的情况下做了多少工作。（当然，由于他们的存在，项目进度那是不乐观的。）

有的放矢，总是不会错的。

客户协调的第三个层面就是和企业高层打交道了。这可能也是 PM 们最不知道怎么办的事情。

和别的干系人打交道可时间战术、人海战术，慢慢耗，耗也能耗出结果来。但是，领导们绝对没有时间陪你天天吹牛。和领导们的交流，是按“有事启奏、无事退朝”的原则来办。有事，不是说是点事情就要去他哪里问清楚，找领导就是要批量一次性解题。所以，见领导前提前充分准备是很必要的：准备文档（文档要简洁、重点突出，不要太厚），准备时间（领忙，不要你好不容易进门了，人家 3 分钟后有会，给你来一句：你放这吧，我回头看看给你答复。），准备怎么（说话要讲究艺术，和领导沟通尤其如此。我觉得……、我建议……、厂里最好要求……最后结果都可能不一样的。）

再分享点心得吧。

• 见厂级领导，首先和厂办主任（总经理工作部之类了）搞好关系，去他哪里打听领导们的动向，让他帮你预约下（要是预约了就要守时）。

• 提前准备好文档，最好按照你能预估的结果来写东西，谈拢了让领导直发……这多爽啊。根据要谈的内容，考虑好先后顺序，很多时候前面的事情没有谈拢，后面的事情就不要提了，提了也没用。

• 顺序弄明白了之后就开始摆沙盘吧，在脑袋里面设想你怎么提问题、要求，人家可能给你的答复，你再怎么讨价……我坚信，没有谈判天才，只有有准备的谈判天才。

好了，到现在，和三类用户怎么打交道我们都明白了。下面就是遇到具体问题的具体协调手法了。

这里要插一句，PM 们不要指望有事情了再去找谁谁谁沟通、协调，这基本都是很困难的。反正一个项目周期也不短也没法预计以后要找谁，不如先浪费点时间下去。

项目日常管理

前面已经说清楚了 PM 进行客户协调的最重要的东西，就是在问题发生之前和用户多交流、多沟通。人与人之间有了一定的情感基础，谈起棘手的问题来能好一点。

随着项目的深入展开，PM 们面对的最多的问题大致有以下几种：

• 进度计划得不到执行，项目开始延期；

• 用户理由很多，总是不配合工作；

• 需求变更；

• 资源不足，人手不够；

• 长期出差，项目组成员开始烦躁；

• 用户 PM 由于项目的种种问题，开始郁闷，将邪火发到项目组成员身上；

• PM 身兼数职，无法全心进行项目管理，项目组成员开始各自为阵；

面对这些问题，PM 们改怎么办呢？一个问题一问题处理吧，还能怎么办？

1、项目开始延期，这问题太普遍，普遍的大家都觉得正常。但是做为 PM 还是要分析，导致项目计划延期的原因，在你的项目月报中要说清楚你的项目为什么延期吧？上面总结的 2、3、4 基本上都是项目延期的普遍原因。对于项划延期问题，建议 PM 们和用户 PM 做好沟通工作，属于用户方的问题要给他说清楚，必要的可以形成书面的东西给他。

2、这个问题最头疼。人家每个人都貌似很忙，没空配合你的事情，你怎么办啊？常规方案，针对问题开项目协调通过会议解决这个问题。当然了，开会之前 PM 们需要做哪些事情，我在上一个帖子中对于开会有专门的说明，这里罗嗦。如果前期的吹牛工作做的比较好，那么这时候用户 PM 通过官方手段无法协调的事情，你可以去试试看直接和用户沟通下，说不定你就说服人家配合你了。第三个办法，直接找厂领导，摆事实讲道理，让他来协调（找的领导要是“自己人”，找错人了不要怪我出馊注意。）

3、需求变更，痛苦的事情。在这个帖子开头的时候提过需求调研的过程中建议大家一个问题多问几个人，就是为止大面积的需求变更。真的事情来了，也不要骂娘了，骂了也不能让用户不改啊。需求变更问题，是个很大的话题不好说清楚具体怎么操作，才能解决问题。说说我对于这个问题的几个观点吧。

A、面对需求变更，不要在第一时间发表任何看法。先把问题听清楚，然后“站在用户的角度去考虑为什么用户要这求”。

B、从用户角度考虑清楚为什么这么要求了，再回头看看原来的需求是怎么提的，偏差在哪里，是需要配工作流还要客户化程序还是技术上实现困难或者干脆就是不能实现。

C、有一个观点大家可以试着理解（纯粹个人观点，不同意要么扔砖头要么笑笑算了）：管理都是有出发点、管理段以及管理的目地的。其实每个业务流程就是为了实现管理目地的一种管理手段，那么对于需要变更的需求，我们从管理的本质上来分析问题。如果说现有的东西和管理的目地不冲突只是在手段上有差异，那么我们可以和用户商个差异是否可以换第三种方案来实现，这样用户的需求能满足，我的程序修改内容最少。

需要说明的是，这样的处理方法一般都是在处理需要程序规模性的修改的时候采用的（咱当年是做国产自主开发产施的，这样的事情太多，于是就自己找了一个处理这个矛盾的套路。），而且，如果决定和用户去这样研究问题，一定要保证你首先是一个合格的顾问——你要把用户的需求、业务本质都吃透了，才能和用户去研究变通的方案。

D、如果你站在用户的角度分析了，得出的结论是修改，那么就去改吧；如果仍然觉得不需要修改，那么现在可以去商量这个问题了。记住，你分析改不改的理由千万不要是：工作量、技术问题、人手不够、以后再说……一定要站户立场去分析问题，最后让他自己得出你要的结论，这是最理想的结果。

4、内部协调的问题终于出现了，目前电力市场火爆 EAM 同样火爆，基本每个公司都面临人少项目多的问题，那么进行资源（人力资源）的争夺不可避免。做为 PM 向上级领导争取资源的时候，我的建议是：分析事实、计划、进度标以及你争取的资源完对成这个计划实现你的目标的影响。

5、PM 做为公司指定的“项目的总经理”以外，更是项目组的老大哥。在做好项目的同时，更要关心关心手下的兄弟我的观点是，做为 PM 不是技术牛比就是顾问牛比，在项目组收入也应该是在前面的，那么就大方点，公司不报销就请客吧（或者 AA），没事大家出去活动活动，放松下心情。做项目远离家人、朋友而且天天加班很辛苦，如果 PM 法让大家快乐起来，也是一件麻烦的事情。

6、用户 PM 在项目的某个阶段发邪火，PM 们都遇到过吧。这个问题就一句话：有什么事情你给我说就好了，项目组弟们很辛苦了，再错都不要再骂他们，有火对我来。

7、这是技术当家的 PM 最容易遇到的问题，随着项目的深入，任务分配下去就开始各忙各的，做为 PM 也不过多去过最后问题发生了就迟了（想起来雪上情人的一个关于项目组人员辞职的问题，关于这个问题，他的失职再怎么说也分。）。不能说告诫，只能说建议各位技术出事并且同时在项目中做技术活的 PM 们，至少每天回宿舍要抽时时间和每个人沟通下，如果形成每日的宿舍项目例会那是更好不过了。

项目管理策略

前面说到了 PM 在项目过程中会遇到的协调的问题，以及简单的处理方法。当然了，做为 PM 谁也不希望项目中天天都是需要协调的事情，都希望项目在一个正常的轨道上稳步前进。那么如何给项目一个正常的轨道呢？

可以考虑在项目开始阶段做下面这些事情：

A、对于项目进度计划的三级管理

三级管理是这样一个模式：长期里程碑、重点工作计划＋中期工作内容计划＋短期具体操作计划。

这样的计划是一一级的解释与细化，这样就可以将一个漫长的项目过程通过合理的切割与组织，变成可以操作与控制的过程。通过计划的滚动编排，可以很容易发现项目存在的重点问题与急需解决影响进度的问题。

通过这样一个由粗到细，再由细反馈到粗的项目计划管理过程，做为项目高层管理者可以很轻松的得到有关项目进真实情况和存在问题。

对于三级计划的周期个人建议：项目整体、月、周。

B、项目报告与项目例会制度

EAM 项目周期不算太短的，那么 PM 们不要指望靠脑袋将项目中所有的事情都记在脑袋里面。通过阶段的做为项目小方发布的文件，将项目中的进度、成果和问题进行记录、发布是很重要的。

做为 PM 最重要的一个能力就是去“释放”问题，否则，所有问题都压在你身上，你再牛×你也会被压垮。那么，在项始阶段就和用户明确项目例会制度吧，有事情在会议中说清楚。

建议：在正常情况下实施方项目组每周都有内部报告，发布对象就是双方项目组。整个项目官方的报告每月一个，特殊时期（上线过程，需求过程等）可以每周一个官方的报告。

例会可以跟着报告走。但是为了配合顺利，最好一周一次小规模的双方项目组例会，每月的例会需要邀请双方高层管理者（项目管理小组的领导）参加（现实的问题就是实施方的高层管理者会每月参加吗？）。

C、需求管理策略

谁也不希望需求变化，更不希望同样的一件事情，三个用户给了你三个“必需按我的要求来修改”的需求。对于这种左他往右的需求，可能是 PM 和顾问们最头疼的事情。很可能就是今天改过去明天该回来。

当项目确定了项目《需求报告》或者《项目解决方案》后，双方项目经理可以坐下来明确一个可控、可追溯的需求方案，保证所有的需求变更都是“有人承担责任的”。

没有规矩不成方圆，在项目开始阶段明确了计划管理、工作管理和需求管理的方法，我想 PM 后期需要去协调的工作很多的。

项目验收

前面说了项目开始要注意的东西，协调过程中的一些事情，以及如何给项目一个合理、有效的轨道让用户能够配合实施方 PM 的工作，让项目在友好和合作的氛围中前进。随着时间的推移和实施的深入，项目自然会到了需要准备验收的时候。

今天就说说有关项目验收的问题吧。

项目何时验收、如何验收这可能是 PM 们被直接领导、老板们问的最多的问题，也是很多 PM 们很头疼的问题：用户平时配合的挺好，怎么一说准备验收了，什么都不好了，什么都要等等再说了……借口多的很，就是不配合你验收。诸如此类的事情，在项目验收过程都可能遇到。不验收用户不给钱，公司催死 PM；要验收用户提了一堆问题，PM 难死公司……面对验收工作，PM 们该如何展开操作呢？

从个人一贯对于项目验收的理解来看，PM 去操作项目验收工作是没有什么标准方法的。虽然项目验收的标准程序很多，很多地方都能看到：各类验收步骤、各类功能验证、各类文档、各类测试报告、各类手册、功能清单……别的地方都能看到的东西，所以这些不是我想说的。有标准的东西都是可循的、可以量化的，这些东西只要花点时间下去，都能准备完成。真正带给我们项目验收的压力的东西是那些非量化的东西：这个那个功能不符合要求、使用不方便；承诺的某某功能没有实现；与合同、投标文件对比还有×××功能没有实现（这些功能很可能是售前、销售为了拿单子不管死活的写上去的。）；系统才上线×个月问题还没有暴露，再等×个月验收也不迟……这些东西 PM 们该如何应对呢？

在继续开始之前，要说明一个问题。

关于项目，我们可以去追求完美，但是考虑到给我们发工资的老板的心情，所以，在研究收这个问题的时候，让我们先把做个完美的项目这个念头扔到别的地方，重点去关心如何项目在大家都能接受的底线之上去验收。

事实上，项目验收应该从 PM 接到项目的第一天，从看招标文件、投标文件、技术协议那始准备。道理很简单：PM 之后做的所有工作就是要完成这个项目，所以从这天开始 PM 就目验收而准备。

看招标文件、投标文件、技术协议不是去弄明白要做什么事情，而是要“清楚的知道那些求的东西、公司承诺的东西、合同里写清楚的东西，在事实上是无法实现或者在成本分析这些东西是不划算的”。这些东西 PM 要明确的把他们从这三份合同相关的文件中识别出来去和销售经理、售前顾问聊聊，看看这些东西都是怎么跑到合同或者标书里面去的，那些去考虑回避的，那些是用户很关心，需要去考虑实现的。

行了，弄清楚这些事情之后，组织好你的小组成员和顾问，把这些东西说清楚，考虑好需求调研的时候对这些问题采用何种方式去调研之后，可以着手准备项目启动会（第一次设计联络会）了。

其实，做项目的过程，就是去将那三个文件（再罗嗦一次：招标文件、投标文件、技术协逐渐衰的过程，当 PM 所担心的问题都“合理”的衰减了（合理是很重要的，有时候老板们一些“粗鲁”的方解决问题，表面看暂时解决问题，事实上后遗症很厉害。），那么项目以验收了。但愿这个表述大家能理解。

PM 如果能抓清楚影响项目未来发展和验收的主要问题，那么就需要在前面讲的协调、沟通（就是我说的吹牛过程，鉴于大家的理解有误，我改正为协调、沟通）中一点一点去把握用这些问题的心态和想法，然后加以诱导和说服。感觉条件具备的时候去选择一个合理的方式这些心中的石头释放掉。

有那些合理的方式呢？

会议显然是首选了。需要考虑清楚的就是会议的主题是什么，不要傻傻的去开有关功能、需更为主题的会哦，这会吓到用户的。关于开会的问题前面也说了很多，就不多说了。需要注就是选好主题，然后把你想实现的事情合理的安排进去，并讨论通过。

第二选择就是个别沟通了。每个功能点总有核心用户部门的，那么就去和这些部门的领导通、协调吧。

还有第三种好办法吗？

那就是希望用户不要提这些问题了。但是谁能保证他现在不提，你准收的时候不提呢？装傻，不是好办法。还是主动去排雷比较好，免的炸的时候你很惨。

把那些麻烦的需求都合理的处理了，那么面对验收我们还要做什么？

分步验收，分模块验收是个比较好的策略。

古话说一口吃不成胖子嘛，那就慢慢吃吧。分步模块验收从用户心理来说压力相对较小，就是一个模块，验收了你也跑不了，给你签字的可很大。当然了，事情都是两面的。分模块验收是容易，那么需要考虑以下问题：

a、模块验收了，用户来新的需求，做还是不做？

b、模块验收的功能显然不会是三个文件规定的全部东西，如何保证在总体验收的时候用户你回头算旧帐？

说个一家之言：做电力项目，只要钱没拿到手之前，所有的签字都是假的，千万不要以为签就万事大吉了。曾经有 PM 向我说：怎么能这样，原来都签字了，现在怎么又变了，怎么签都不算？我说：你怎么办？去他办公室哭能解决问题不？

c、签字验收的人，对于项目的最终验收是否具备绝对的发言权？人家弄个副主任给你签模收，等最后发飙的时候主任去，一句：模块验收的事情我不知道，我今天提的问题你们必到，要不我不签字验收，谁要验收谁去签字。能气的你想把你的 IBM 扔过去。

不管怎样，事情做的差不多了，项目也超期了，总是要验收的。

上面那个兄弟说了，提前吹风是很重要的。这小风慢慢的吹，一个人一个人的吹，争取在吹时候把问题都提前了解清楚，然后找合理的理由去说服吧。

现在能不能验收了？估计还是比较悬吧？总有不好摆平的用户的，跟你叫上劲了也不是什么的事情。那么就上下活动，团结可以团结的力量，判断清楚问题和形势后开个验收预备会吧。

下面举一个我实战的例子。

你不给我验收，那么我要求开个预备会“诚恳”并且“认真”的听用户的意见和问题，并给出解决问题的时间表，在这个时间表内，谁不配合、谁不能完成任务都要有相应的处理办法。经利用中午吃饭的时间和电厂一把手聊天，除了没说项目的事情，聊了很多话题，还记得有用数学是什么专业，能做什么；拉普拉斯方程；电网潮流计算；电厂主辅分离好不好；他们有没有必要成立检修公司……。一直聊到下午上班，然后跟到办公室跟他谈预备会的事情，要了他一句话：开会的时候我肯定最后发言，你说什么我强调什么，怎样？ 开会的时候，厂长还多说了一句话：“人家 D 经理在这边很久了，也很辛苦，我认为他们的工作很有成绩，今天人家也拿出最后的验收计划了，态度非常好。今天我还要说的就是，那个部门不配合××公司技术人员，导致计划不能完成，到了时间你们那个主任不签字，我来签字验收，验收完了我再找你算帐。”听了这话，心里那个爽啊。当天没有加班，晚上喊小组兄弟们出去喝酒。

个人认为，预备会是个比较好的处理方法。行了，预备会也开了，问题都说清楚了，能不能了？

答案是还有可能出什么鬼问题导致用户提出来不验收，对于老 PM，遇到这样的问题不奇怪怎么办呢？相信通过前期的沟通什么的，PM 对用户的心里底线应该都能把握了，而且前面做了这么多工作了。就差最后一点了，不解决不急死人啊？

备忘吧！我都做了这么多事情了，最后这一点你还担心我不做？但是，说好的要验收啊！总我给公司一个交代啊？而且，没按时验收，你（用户 PM）这不也算没完成工作啊？要不咱一步，你给我验收了，我验收报告后面给你附个备忘录，我答应你做的都写里面去。

事情做到这份了，PM 们项目验收了没有？

总结

通过一个项目从头到尾整个过程的简单解释，希望新的 PM 及技术转型的 PM 们能够从中间得到点自己需要的东西。也算我没有白花这么多时间去打字。

写了不少，回头再来提炼下：

• 项目开始阶段，分析清楚合同相关文件很重要，从中间发现以后需要注意的“特殊”功能要求；

• 在项目开始阶段和用户明确项目的管理体系：报告、例会、需求变更等；

• 排一个比你觉得能实现的计划周期压缩 20％的总体计划；

• 根据自己的能力和优势选择一个理想的介入项目的方法：或者高调（这个不是太好玩）、或真、或者技术很好、或者理解行业需求……

• 开始阶段，多和用户沟通，不一定要有问题才去找用户，电厂的主管们大多时间还是教多的接触接触是好事；

• 刚开始的项目报告一定要言之有物，能客观反应问题（是用户的就指出来，是自己的错误也写上去），让用户领导觉得可以通过这样的形式了解项目情况，并愿意参加例会；

• 滚动计划一定要准确，不要滚来滚去，事情总完成不了，会导致用户对于你计划能力和做事的怀疑；

• 排雷工作早点做，不要等验收前 3 个月才想起来；

• PM 就是 PM，不要再去做技术高手，对小组兄弟多些指导，少做点具体事情，多花点时间去项目整体的事情；

• 对于验收，不要一根筋的去考虑，做多种方案准备，然后考虑清楚后再和用户去谈；

• 最后，关心项目组兄弟们的生活，人性化点。

本文转载自知乎专栏：不如无书

原文链接：

https://zhuanlan.zhihu.com/p/57985267