项目经理最应该具备的能力是什么？

末蓝、 2022-07-12 15:58 280阅读 0赞

首先明确一下，PM不包括做系统的、coding、数据库、网络等等的，如果你做这些，只是说明你身兼数职了，这里说的就是PM本身的能力。

一、沟通能力。

好像所有的人都会赞同沟通能力最重要，可是什么是沟通能力的内涵呢？我觉得是：清楚的表达、传递，并引导人们的表现朝你的期望发展。怎么才能沟通好呢？可以简单的分为：

A) 领导沟通

1、管理你的领导

PMBOK说PM有权利调配资源，不够就要去要。现实中，基本上我们的项目最大的限制除了钱就是资源，资源很多情况都被领导掌握，PM哪有随便调资源的权利？但是领导们都常常觉得，够了啊，总之你给我搞定。

PM要学会说不，制定计划的时候就要否定老大们不切实际的想法，但是绝对不是上去就狂喊，而是你的说法上要有技巧，说目标-步骤-难点-计划-资源，领导们会容易接受一些。就是说：我们的目标是，要达到什么效果，还有范围是什么——步骤是1、2、3、4，先做什么再做什么——难点是什么，哪个地方容易出错，不管是技术难点还是管理难点，PM都要考虑在内，比如技术上大家都没有做过，就是难点，比如管理上没有某个规则等等——因为有了这些难点和目标，我们觉得时间计划是什么（保留适当的储备）——因为要实现这个计划，我们需要什么资源。

领导们听到最后，嗯，很有道理，他就要权衡了，给你资源么，不给？不给重新讨价还价，目标要不要改，时间要不要延长，范围要不要缩小？给？给当然好了，PM要到自己的东西了。

无论是制定目标还是过程中，你需要资源的时候都可以尝试用这种方法。  
     虽然很多时候资源是被领导掌握，但是身为PM要记着，领导也是我们的资源，你用他的思维方式，引导他去思考。你要学会管理你的领导。

2、 向领导暴露问题

就算这些资源都要到手了，我们就是承诺项目没问题吗？当然不是啦。领导们还是聪明而有经验的，他们都知道项目一定会有问题，他们不期望不出问题（他们基本都认为，不出问题的项目一定是有虚假信息，项目不可能不出问题），他们只是希望可控（问题可以被解决、知道对现有质量、进度、资源、budget的影响）。

所以PM千万不要心虚说，因为前面我要了这个那个，后面我就不可以出问题了，有问题就隐瞒。恰恰相反，PM就是要在过程中暴露问题。你说出来了，领导就是再不开心也知道解决问题最重要，所以他就会帮你解决问题，你就多了一个powerful的资源了。

暴露问题是要说：问题是什么——为什么会出——如果不解决，对目标、范围、进度、质量、客户满意度、预算影响是什么——你觉得解决方案是什么？（或者好几个）-各自对上面6个维度影响是什么，各自都有什么局限和好处？——领导决策。

如果你也没解决方案（这样不算好的PM，但是没辙的时候也是会有的），你就做前面两步好了。问老板，怎么办啊？

但是无论是谁给的解决方案，也无论这个方案是什么，你最后都要向你的领导（当然包括你的所有stakeholder）说清楚，这样一个变更对目标、范围、进度、质量、客户满意度、预算影响是什么。

让你的领导感觉，虽然会出问题，但是你至少让问题的影响可控了。他在下一个问题出来前可以睡觉了。

3、   什么时候汇报？

虽然我认为很少有PM会犯这个错误，但是今天突然想起来了，觉得还是说一说比较好。周报是干嘛的？其实很多时候虽然是一个formal written的DD，但是最大的作用我认为是保持所有人对项目的关注度。让一些更大的BOSS、边缘的team member、边缘的stakeholders保持对项目的关注度；让 core team有成就感：我们做了那么多，还报告领导了。我认为，周报或者叫周期性报告不是解决问题的，只是陈述性、总结性的。

一旦有了问题要马上汇报！当然还要考虑上级领导的风格（他是事无巨细都关注型还是抓大放小型）和PM的权利（什么样的问题有决策权）。但是一旦有了PM搞不定的问题是要马上汇报。你想周期性报告一周一次？一月一次？那时候黄花菜都凉了。所以马上汇报！不要怕你的领导。耽误了时间更可怕。

总结一下，有了PM搞不定的问题要马上汇报！周报、周会做什么用的？保持所有人（包括非core team）的关注度，这个会不是解决问题的，是讲讲总结（上一个周期干什么了）讲讲计划（下一个周期每个人要做什么）讲讲问题（上个周期出什么问题了，我们怎么解决的）和讲讲风险（下一个周期可能出什么问题，要注意什么）的，总之不是解决问题的。出了问题要随时解决、即时解决。

B）同级、下级、供应商

1、 在达不到要求时，引导member继续前进

对于同级、下级、供应商他们都是你的Team Member，不要关键时候不要搬出权利来吓唬他们了。

他们需要被夸奖。听说教育小孩的经典之一是“好孩子是夸出来”，你的member是一样的，好member是被夸出来的。只是他们不像小孩子那样可以说谎的夸，你需要认真的动脑筋想怎么夸才不会显得言不由衷。夸他们除了真的做得好之外，就是你需要他们做得更好的时候了。做得更好其实并不表示他们现在做得很好，恰恰相反，可能他们做得非常糟糕，根本达不到你的要求。

但是发火是于事无补的，甚至可能激起team member的反感，都这么大人了，谁都有个面子问题的，所以我们只是要达到目标，发火不过是手段，不到必要的时候不需要发火，一来让自己心情不好，二来偶尔发火才是杀手锏，发火多了就不值钱了，你已经没有太多可让人畏惧的东西了。

夸他们是要有技巧的，你可以说：做得好啊，我们已经实现了什么什么（他的确有做的东西）——现在该我们考虑下一步的时候了，下一步我觉得还需要做什么什么——这些由你来做？因为前面做得不错。

看上去我们在夸他们，实际上，我们在给他们下套，套住他们，让他们高高兴兴的去实现我们的目的。你不需要说太多的“但是”，这会让你听上去有点虚伪，但是你可以把你的目的拆成两个来说，他实现了第一步，那么第二步不是就该接着做了吗？

2、  翻译能力

PM是什么呢？好的翻译官。客户说的都是他们的业务语言，供应商有的时候说的是技术的语言，PM是什么？多语言外交官。PM有责任将不同团队之间的语言翻译成大家都能正确理解、没有歧义的语言。

只有语言统一了，大家才有交流的基础，否则是鸡同鸭讲，彼此谁也不知道对方说什么。

还是COPY之前已经用到的例子，丰田开发凌志的案例：

日本鬼子做凌志的时候，目标就是改变大家对丰田中档车的观念，要做一款高档车，他做的需求调研就是为客户为什么觉得奔驰、宝马高档，得到的答案就是  
（1） 身份地位与尊容的形象  
（2）高品质  
（3）转售的价值  
（4）性能（例如，操控、乘坐、马力）  
（5）安全性  
最后他根据客户这些感性的词语，翻译出了凌志的目标  
（1）最高时速：250 km/h（比奔驰多28，比宝马多30）  
（2）耗油量：每加仑行驶23.5英里以上（比奔驰多 4.5，比宝马多4.7）  
（3）噪音情形：100km/h 时速为58分贝，200km/h为78分贝（奔驰为 61/76,宝马为63/78）  
（4）空气动力……  
（5）汽车重量……

项目经理就有必要将交流的内容明确化、易于沟通，常用的就是量化和名词解释，重点说名词解释。要进入一个行业就要先了解这个行业的术语。所以供应商、客户之间说不清楚多半都是名词不了解，举个例子，我们说备份好像很easy，觉得根本没有可解释的地方，可是客户根本听都没有听过。

我们首先要察觉困惑的情绪，当一个人脸上呈现出茫然的时候，我们就可以问了？有什么不明白的么？通常他们都可以清楚的说出没听懂的地方。可以看看当中有没有专有名词，有的话，就解释一下，什么意思，最好打个比方（尤其是要客户明白IT名词的时候）——作用是什么——它的变化带来的影响是什么——我们现在讨论它是为什么——你觉得呢？

举个例子备份，备份就是把每天的数据做一个COPY保存在另外的地方，好比你把重要文件COPY在U盘上，万一你硬盘坏了，可以从U盘上COPY回来，保证文件没有丢——就是保证万一服务器坏了，我们做的历史记录都在——备份保存的时间决定你可以恢复到什么时候的数据，比如，我每天备份，备份都保留15天，如果现在是2月16日，我可以恢复到2月1日、2月2日……2月15日，任何一天的状态，但是想恢复到1月30日就不行。所以备份保存的时间就是可以被追溯的时间。——我们现在就是在讨论这个系统的数据备份应该保留多长时间——你觉得你们希望可以被追溯多少时间前的数据状态？

C）冲突管理

冲突在项目中定然是无处不在的。甲方和乙方虽然说是一家人，业务部门和IT部门是利益共同体，可是老婆会向着娘家，老公会向着婆家也是不争的事实，所以大家因为某些利益一定会摩擦。

1、老大观点不同，却要你传话

如果是你的老大告诉你说你要这么这么做，然后你发现乙方的老大或者业务部门的老大其实基本不同意怎么办？老大们之间常常有冲突，可是总是把我们这种小卒推到前面，我们怎么做才不会破坏自己和其他方的关系，但是又完成老大交代的任务？

其实也很简单，你直接告诉其他的头们你的老大要求你这样做，问他们怎么办？一般说来，其他的头们都会直接找你的老大沟通，你就免受夹板气了。万一他没有找你的老大，你就乖乖传话，多的事情最好不要做。

这样说毕竟有点无奈，可是本来很多事情都是我们不能左右的。

2、平级间的冲突

我过去的经验是，这种冲突有很大的概率是沟通不明。人好像都有坏习惯，明明担心某件事，但是不明说，就是绕着说，说来说去，大家就为了绕着的那个东西吵架了，目的是一点没摸着边。所以摊开问是个不错的办法，你就问他，你到底担心什么。一般说来，这样能问出80%的真实目的，当然你事先要卸载他的心理包袱，比如说，你们总部不给资源，我们也能理解，我们的项目小，你们总部不重视也是情理中的，但是不知道问题在哪里我们很难解决不是？态度要诚恳友好。

沟通中很多时候好像方式比内容重要，本来你想关心人家，结果用一种很凶的口气说，人家也不会买账的。所以表述的语气、表情一定要控制好。

问明白人家的担心顾虑是什么，常常解决方案也找到不少了。再不行还可以上报，让你的老大帮你解决。可是你知道根结所在，才能让你的上级帮助你解决吧，不知道根结就走错了方向只能越走越远了。

说好多半也说不上好，只是我们的老大就喜欢突破乙方的底线。其实就是故意给实施经理施压，告诉他，你不听话？我当着你的面给你老大打电话，让他来骂你，我不骂你，怎么样？

这招在通常情况下都是有效的，一般说来，乙方的老大当时会蒙掉，然后一想客户不能得罪呀，然后就把自己的实施顾问骂一顿。其实乙方也不容易呀，但是我们老大的这招其实一招制胜，以后他没事肯定笑嘻嘻的，但是一旦在心理上威慑过对方，乙方的心理阴影就重了，以后知道“XX是非常厉害的，千万不要惹他”。老大的目的就达到了。

a、合作的态度

tony\_sy 说的合作的态度，非常赞同。而且常常会很奇妙的发现，在沟通中，态度甚至有的时候比内容更重要，（不是说55%的信息是通过非语言传递的么），所以合作的态度的确会建立良好的沟通。

我也非常赞同甲方不要指手画脚的指挥，这种强势性领导的结果就会是强势方的实力决定了，不是团队的效果，乙方唯唯诺诺的，成了干活的杂役了。效果的确不好。

沟通、管理的目的都是要激发团队成员（包括乙方之类的人）的“自我管理”，就是他们积极主动的完成自己的事情，还会帮PM想哪些地方会有漏洞。所以一个团结、合作愉快的团队效率会非常高。

b、甲方不信任乙方的后果

这个我也是深刻体会，因为我们的项目就是甲方不信任乙方，然后因为我们的业务部门老大又选了他，我们（IT和业务部门的几个底层人员与乙方）在前期又谈崩过，所以就是甲方的人拼命的考虑合同，怕有东西写漏了，乙方的也拼命的改合同，那段时间，我们甲方改合同的这几个和乙方改合同的这几个差点改崩溃。即便是这样，我们也很清楚，有很多事情是合同之外的，很多事情都是可以协商的，但要看双方态度怎么样。

之后，大家的阴影都很重，有一点事情就会想，当初怎么样怎么样。大家其实是处于一种脆弱的信任关系，非常容易破裂的。

c、倒霉的甲方

只是我们非常郁闷，因为乙方的有点为所欲为了。这个词还真不是瞎说的，我们简直倒霉至极，这个乙方的PM简直可以用见鬼的形容。比如，叫他需求调研完了写报告，人家说不用，说了3遍就是不写，因为选供应商这件事上我们和业务部门也闹翻了，他们的中高层选择的这个供应商，所以这些事情都是业务部门协调，IT把问题、原因都告诉业务部门了，业务部门的人不太理会（他们因为没有项目经验，所以不太重视）。乙方的PM一看，太爽了，甲方是业务部门协调，业务部门的人不太懂又太好说话，就开始无法无天了。

牛到什么程度吧？培训，给全集团十几家厂培训，他说的流程是错误的，后来我们的测试人员发现了，乙方的PM说“我也不知道啊，没人给我培训啊”！还有一个功能，昨天还好好的，今天就不能用了，乙方的PM说“本来就没这个功能”！这些都冰山一角，凡是出一点问题，乙方的PM就是“我也不知道啊，没人告诉我啊”！简直牛到了姥姥家。他们后来来一个高层和我们交流，我们告诉他们高层乙方的PM这样了，人家也不管。我们简直可以吐血了。

关键还是业务部门因为选了这个供应商吧，就心虚，就拼命掩着盖着，替乙方说话。出那种问题，还说“你们沟通不清楚”。乙方的又太不知道收敛，最后才导致连业务部门的这个人都倒戈了。

其实我很奇怪的，一般的乙方都很好的，甚至被甲方打压着喘不过气，这个项目正好相反，我们倒霉得没脾气得不成话。

最后我们对他们不信任到什么程度吧，我们全部自己使用功能，除非bug，否则绝对不问他们，问了乙方一个功能有没有，行不行，他也胡说八道。最搞笑有一次，下面企业的问一个功能行不行，乙方的说可以，我说不可以。开会揪出这个事情了，乙方的理直气壮的说我测试过，我冷笑，现场当着所有人的面测试，果然不行，如我所说。人家就因为“下一步”按钮没点，点了就会弹出错误的提示框了，人家测了前面就不点“下一步”，这个责任心……真是让我无语呀。

他们给个补丁，我们要狂测试好久才敢用。因为以前几次，给一个补丁，得，打上之后其他程序用不了了，因为前面几次我们也大意了，没完全测试就上了，就看补丁的功能可以了，没看其他功能是不是不能用了。和乙方理论，要求他们加强测试，乙方的理直气壮的说“因为你们测试系统最近出问题，你们没测试导致的”！5555555，谁见过我们这么倒霉的甲方？

tony\_sy ，不是和你对着干啊，我只是回忆起心酸的过去，忍不住发发牢骚。我必须承认，这种情况简直万里挑一，可是我们跟中彩票似的居然中了。以前别的项目，乙方真的很好，甲方的有些人就太不厚道了，该自己做的都推给乙方，乙方的都默默接收了。这种甲方的不厚道的人我也很不赞成。  
呵呵，tony说得很是。这一点你说了我忽然恍然大悟，的确应该把利益干系人分成几类，尤其要搞清楚谁有决策权谁没有，还是你总结得好。

这一点在项目中是非常关键的，就像PMBOK里面讲的influencer，这些人也要搞清楚。

其实这个项目中郁闷的是我，明明看着是悬崖，业务要跳，我只能傻看着。但是高兴的是我的老板W。这是个很阴暗的心理，也是我暗自揣测的，说了大家不要鄙视我的人品啊。我的老板因为在选供应商这件事上没有得到业务部门老大的同意，所以其实就是要搞他们一下。我就是觉得告诉我老大项目出问题了他好像很高兴。

但是不能告诉更大的老总BOSS，我们和业务部门是这样的情况。

1、BOSS其实太聪明了，说穿了就知道问题根结，而且马上就知道是供应商选型的事情出了问题。那么一来把业务部门的老大给卖了，得罪了人就傻了；二来，BOSS对我们部门印象也不好，因为觉得我们推责任。

2、我的老大W推责任其实也有道理，供应商我都没法选，我否定的你非要选，那么承担你选供应商的后果，我不是傻瓜？

3、我的老大W其实留了一手，虽然供应商和他闹翻了，但是万一项目做得也不错，我们不是又傻了。所以他命令我项目还是好好做，有问题一定要暴露，只一点不同，凡是要协调和决策的，一定要业务部门来协调来决策，而且事先话一定要说清楚，可能有什么问题，风险是什么等等。这样做好了，我们肯定也要分一羹，可是做砸了，供应商你们选的，决策你们做的，我们该做的都做了。也让BOSS抓不着把柄。如果话说白了，呵呵，我们人得罪了，做什么也分不了一羹了。

办公室当然是有政治的，PM们要分清楚政治风向标呀。前面说的如果遇到老大们打架，就老老实实传话，千万不要参杂个人意见。不要歪曲任何意思。如果有老大问，那个老大什么意思，就乖点说，不知道喔，装傻呀，千万别多嘴……

项目范围对于乙方来说的确难以控制，甲方总是希望乙方能免费的改这改那。而且虽然合同都会签订成多少工作日的开发是免费的，超过之后怎么收费，但是实际上非常难执行。国内项目的信誉度真的不是很好。而且国内的还最喜欢FP合同，乙方真的是难。

说真的，这个也没什么好办法，基本原因还是因为大家太不诚信了。

而且工作量的估计也是个问题，比如，甲方算工作日最爱算开发需要的工作日，乙方肯定把测试的时间也加进去，虽然标准的比例大概是4：2：4，构架时间4成，开发时间2成，测试时间4成，但是乙方多半在测试上大砍时间，构架时间也缩小很多，大家拉拉扯扯的很难说清楚。

同情乙方啊……很多时候一个聪明的乙方老大能作用很大，遇到这种情况一般来说PM处理不了，还是要聪明的乙方老大和甲方老大解释会好很多

至于项目时间，如果不是范围变动了，觉得还可以控制。资源不到位的话，可以让甲方去协调；人员变动也觉得非常难，只能说好的文档会有所帮助，但是实际上来个人也比较难很快的接手。但是PM平日就可以对member说清楚，就是如果要走你绝对不为难，只是要求尽早提出来，留够交接时间。这样子至少PM可以主动一点点，但是人走了肯定会多少有影响的。PM要培养个人魅力呀，其实很多时候人家觉得跟着你可以学到东西，多留一个项目也算OK，所以如果PM够有魅力，撑到项目结束的概率就大很多。

这个绝对是千真万确，所以非常重视双方PM的选择。

我们的项目，在一开始，IT的老大还是参加例会的，参加了2、3次我们的老大不参加了。乙方的PM简直是说不得的人，一说就跟猴子被踩了尾巴一样，拼命顶嘴……我们老大问，有问题么？有搞不定的事情我们给协调。乙方的PM说：没问题。然后等到deadline前2天，说，不行了，咱们要delay。

所以一开始，我的老大就告诉我说这个项目必死无疑，这个PM这样做事只会让项目玩完；可惜供应商不是我们选的，我们也不会出面协调说必须换PM。

说个我的失败吧，一开始挑乙方PM的时候，我的老大W就说，你让他们推荐，万一有什么问题就说你们推荐的，责任就是他们的。我没完全听进去，所以对乙方的PM Y表现得有所偏好。当然乙方的老大推荐的时候开始不是推荐这个人，但是因为我对Y有所偏好，就问他为什么推荐另外一个，而不是Y，其实我的意思只是问清楚，当时还是觉得供应商这样是有道理的。但是乙方老大早就看出来我比较喜欢Y了，所以就顺水推舟推荐了Y。之后，项目还未开始，有一些前期准备，这个时候Y就表现出来没有责任心了，其实事情很小，比如说下午3：00给我文档，但是下班了都没有给过来；比如，会议上说的东西，写漏了。我观察了几次，觉得Y有问题，就像乙方老大提出来换PM，但是乙方的老大信誓旦旦说Y是最合适的。之后就是一连串的事情，我们不再和乙方协调资源，再和业务部门说，他们没有太看出来Y的不好，容忍非常多，换人的事情就不了了之。

这个失败说明什么呢

1、甲方的PM确实应该让乙方推荐PM，而且千万不要表现得有偏好，这会误导大家。更何况，知人知面不知心，Y一开始在我们这里因为态度温和，还是得到了很多好评的。

2、PM的责任心可以说太重要了，能力里面最重要的是沟通，但是态度是能力之外的一个极为重要的因素。如果乙方的PM没有责任心，这个人就没救了。甲方如果发现乙方PM没有责任心，要坚决换人。而且越早越好，如果做了一半去换人对项目影响就很大了。

甲方PM要学会观察对方，专门给一些小事给他做，观察他的责任心和能力。越早发现对方的特性，对自己越有利。  
观察的技巧大家想必都有一大堆，不过分班门弄斧了。随便简单说说。  
     a) 给他几个文档写，一个时间很紧，一个时间很松。很紧的看他在紧迫的情况下，是选择应付，还是选择质量优先，态度上是愤怒和敷衍，还是尽力做到最好，如果他做不完是先敷衍你，到最后才说做不完，还是说坚持原则，并且能有技巧的和你商议。  
      时间松的那个，是看他是不是有学生情节，就是说总是在最后一刻才做完该做的事情，不会提前做好，如果PM有学生情结，那么他的风格可能会导致项目风险偏高，因为事情留到最后才来处理肯定没有回旋余地了。  
     另外文档的组织能力，也代表他的框架思维能力。

b)看他目标性强不强，就看讨论。目标性和思维性不清晰的人，多半说说就跑题了，忘了最初的目的海阔天空去了。

c) 看他沟通能力好不好，故意说些错的，看他是否纠正你，用什么方式纠正。不纠正你的人很危险，以后他会顺着你说，你自己还美着呢，都到悬崖边上了。纠正的方式也很重要，如果他上来就指出，以后就注意一下他可能太耿直了，如果说得太委婉，客户又可能没听懂。

……

这些要说就多了，但是觉得a 的DD比较有用一点，PM态度不可以有问题，责任心不可以有问题，其他的能好就好，不能好也可以慢慢学，或者你来教。

我们不能期望另外一个人完全如己所愿，但是要明白挑选人的原则，必须要有的素质和品德。  
我的感觉是，如果甲方的老大没有明确说过不要用的不是不能用的就不要改之类的，甲方的PM、业务之类的会根据操作人员的反馈不停的加东西，而且加得多的都是功能不好用、操作不方便，加个边边角角的功能，很罗嗦。但是边边角角的功能加一起也很烦人，其实要耗费不少时间。所以乙方可以一开始就想办法和甲方的老大定个基调，如果不是有问题，或者功能不符合，不好用的、操作不便利的地方尽量不改。

超得多的时候反而好谈一点，通常甲方不是蛮不讲理的话，都比较容易谈，常见的就是放在二期之类的。

其实这个尺度要看乙方PM的功力了，还是“能因敌而变之者，谓之神”，如果项目管理能做得就剩这一句的，就真的是神人了。

我这说的无非都是些蝇头小“术”，大道无术啊。  
继续前面的话题

二、全局的掌控

A）理解目标，宣导给team member

PM是最应该做好目标管理的人。

通常在执行过程中会出现什么情况呢？为了实现目标，我们设定了一个策略，为了实现策略，我们制定了步骤，确定了activity，选用了工具和方法，做着做着，大家都忘记目标了，忘记步骤、工具、方法、activity是为了目标而衍生出来的细节，把过程当成目标了。

所以PM一定要做好目标管理。无论是出现risk还是需要决策的时候，PM都应该衡量对目标的实现是否有帮助。

同时，PM也是一个教练，所以一定要记得目标管理并且将目标宣导给team member。

目标管理也是HR的一种方法。就是说，把要做事情的目标告诉team member，让他们自己制定策略、步骤、activity等等，这样手下的人会有更大的决策空间，PM也会有更多的free time。

说个题外的话，如果事情分为4个象限，重要紧急、重要不紧急、不重要紧急和不重要不紧急，PM应该关注哪一类的事情？估计大家都知道了，PM应该关注重要但不紧急的事情。

为什么？以计划为例，重要紧急的是关键路径上的事情，一来因为大家都知道它是关键路径，都会投入相当的关注度和resource，PM反而不需要关心放在桌面的风险；二来，如果PM总是在关注重要紧急的，就是说critical path上的任务总是需要PM去关注，那么一定会有其他3个象限的问题变为重要紧急的事情。什么是重要紧急的呢？比如，一个特殊的材料在一个非关键路径上，早两天晚两天无所谓，但是没了这个材料就是不行，这个DD就是重要但不紧急的。PM一定要把大部分精力放在重要不紧急的事情上面，同时还要关注不重要紧急和不重要不紧急的事情，防止他们变成重要紧急的事情。

这个道理对管理者而言更应该关注。举个例子，一个IT部门的基础构架 ，现在有4件事情，A是ERP系统（全集团关注的重点重点的项目）的基础构架制定，B是IT基础构架的规划、流程的制定，C是接近DeadlineDSS系统的基础构架制定，D是TMS（运输系统）的基础构架制定。A是重要紧急，B是重要不紧急，C是紧急不重要，D是不重要不紧急。如果部门长总是在看A怎么搞定，那么他一定整天忙着救火，等A忙完了，C因为太靠近deadline了就又变成了重要紧急的事情，等C好不容易救火完成了，D拖了太久时间，又成了重要紧急的事情了，而B，重要不紧急的事情就总没有时间做了。

英明的部门长总在做什么？重要但不紧急的事情。就是B这样的事情。他制定好了基础构架的规划、新建系统的基础构架制定的流程，那么A只要照着游戏规则走就好了，而B、D都不需要他关注，自有下属来按照游戏规则来执行。B类事情就是PMBOK里面说的，预防，好的老板在预防问题发生，在混乱发生之前就制定了游戏规则，大家都按部就班了，混乱就被避免了。这也就是“无为而治”的境界。

什么是重要不紧急的事情呢？我的理解就是游戏规则的制定，基础类的规划……当然根据situation的不同也不相同，大家自己分辨吧。

B）解决方案的全面理解

对于甲方PM来说，有供应商撑着，假设以后也不做二次开发等技术工作，那么PM在技术和业务上最少达到什么程度比较合适呢？

技术和业务上当然是越深越好，但是最少我觉得应该可以全面的理解解决方案。I解决方案一般包括业务需求，业务解决方案（系统有什么功能去实现这些业务需求），软、硬件配置及依据，存储备份策略及依据，网络配置及依据，安全配置（比如访问控制）及依据。

也就是说业务和IT方面不仅要知道要什么，而且要知道为什么。这样在以后调整的时候，才知道调整是否是可以满足目标的。

任何时候有变更，虽然很难像PMBOK说的走正规的变更流程，但是评估变更对目标、范围、成本、质量、资源、进度、客户满意度的事情PM还是应该做的。所以知道为什么很重要。

详细一点阐述  
业务要知道什么呢？业务子目标，就是除了前面说的更大的老板给的项目定位，每块业务做什么用的，业务的流程是什么样的，系统中哪些模块对应这些业务的流程和功能。这样在系统做二次开发需求调研的时候，你才知道会影响哪些业务流程、有什么影响，细一点甚至可以说出某些域在模块之间的关联，比如，资金系统里面用到汇率，那么票据、资金计划、银行历史余额与交易明细查询等诸多多币种的地方都可以使用同一个汇率，不能每次用一次输入一次。

做IT的，不要只看着IT那一块，OK了就行了。最好学习一下业务。一来是拓宽知识领域，很多知识都是属于通用知识的，比如，财务、销售之类的，这些知识以后做别的也用得着。二来，好多企业都有类似数据中心这样的地方，就是业务出问题了，可以按照业务流程找到出问题的数据源。做IT的有的时候也会承担数据中心的作用，不了解业务可能没法追溯错误的数据源。三来，从系统设计角度讲，业务、构架都了解才能学习软件设计的思想…………罗嗦了，估计大家都知道了。

对技术方面，我觉得可以不知道怎么做，但要知道能做什么。比如，你可以不知道备份的自动执行脚本怎么写，但是要知道自动执行脚本可以分用户，可以做定时（每周几几点）任务执行，定时备份删除，最好看过那个脚本，有点感性认识。所以PM如果对技术一无所知，其实还是有点困难的。

另外，注意一点，就是全面理解，这个就是PMBOK的单词intergration，整合。甲方技术环境乙方是不了解的，所以他们给的解决方案都是泛泛而谈，通常说来而已。甲方的同志要记得自己家的东西自己最清楚，甲方才是最大的集成商。为了集成的目的，甲方的同志要时刻保持清醒的头脑，在任何时候要反思，为什么如此，能实现业务目标吗？不明白就问乙方的，甲方的同志多幸运呀，有乙方培养我们，把各家解决方案好好的学上一遍就能进步很多。

解决方案的全面理解，就说这么多吧

C）控制变更

中国的项目好像都很难控制变更,像前面说的，小处放行，体现人情，大处握紧，避免成本超支是PM要把握的。但是每次遇到变更，

PM有一件事都可以做，就是按照PMBOK上面说的 日常要影响会导致变更发生的因素，也就是说尽量让变更不要发生，万一发生了，了解清楚变更是什么=》评估变更对范围、成本、资源、时间、客户满意度、质量的影响=》找到多个可选方案Option=》找到客户/高层让他们选择一个Option=》执行变更或取消变更。

PM在变更来临时，能够对变更的影响做出正确的评估，PM的功力就非常了不起了。当然评估不一定是纸面的或者正式的，但是PM心里面一定要有数。如果知道影响不大，就可以实施小处放行的策略了。知道了影响是什么之后，给出可选的解决方案也是非常考校功力的。PM要说出新的方案得到的是什么，失去的是什么，就像PMP考试天天问的，fast tracking带来什么呀？风险增加。PM也要学会在给出解决方案的同时，说出新方案对范围、成本、资源、时间、客户满意度、质量的影响，哪里增加了什么样的风险，多大的风险。这样实施起来，心里面有数。

其实我个人感觉，客户很多时候以为变更很容易是因为不知道变更的影响是什么，所以如果能说出影响和代价，很多变更都会取消，即便实施，也是有言在先。客户和老板很多时候很类似，也是喜欢可控的感觉，PM能说出变更的影响是什么，替代的方案是什么，方案的风险和收益是什么，如果发生风险代价是什么，客户会非常喜欢，执行变更PM也能争取到资源，不执行变更就更好。

变更就说这些。

......

[http://www.itpub.net/viewthread.php?tid=786732&extra=&page=18][http_www.itpub.net_viewthread.php_tid_786732_extra_page_18]

[http_www.itpub.net_viewthread.php_tid_786732_extra_page_18]: http://www.itpub.net/viewthread.php?tid=786732&extra=&page=18