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也能争取到资源，不执行变更就更好。

变更就说这些。

供应商大抵上都有这样的趋势，每个公司拿得出手的人寥寥2-3人，这两个人一般都跑市场，做售前，通常都是经验丰富、口才出众、履历表精美得难以挑剔的人。可是通常，除了这两三个，估计这个公司就没有人了，或者说其他人常常都是毕业生啊、经验不足者啊。

招投标的时候，这两三个牛哥们出现了，标书非常漂亮（这些牛哥们通常还有大公司、外企背景，所以做的标书常常也漂亮无比），但是甲方要注意看什么，他们的人员计划人天数和人员的履历。一般牛哥们出现在啥地方啊？方案、框架、项目管理这种管理性或者高瞻远瞩性的工作里面，多半还是项目经理，看着人天数也不少。

但是甲方啊，现在看啥啊，看执行、实施这一类角色是谁做，履历如何，自己电话面试一下比较好，以后他们才是真正的PM，实际做事的人。权利在最真实的地方最有效。他们的能力、态度才极大程度上决定了你的项目水平。

呵呵，老实说，大公司也不例外……

一、书
除了大家都知道的PMBOK外，还有一本说得多的书《如何准备PMP考试》。每个章节前面都有不少有用的解释，考试的人不妨一看。但是习题答案错漏百出，简直不敢做。我做过这个书两遍？（要不一遍多）觉得题目还好，答案是：看不懂为什么是选这个的时候，它也不予解释。反正自己理解，就理解不通。还有很多解释，不知所云。所以题的答案能气死你。

建议可以几个人一组，讨论讨论答案，反正我老是觉得看书的答案会让人疯掉。

另外还买了一本《成功通过PMP》，没太仔细看。就是觉得里面很多解释很学究，不是太适合考前快餐式的学习。建议，如果《如何准备PMP考试》里面的知识点让你晕了，就对照看看《成功通过PMP》。

第三本我的参考教材就是 《PMP Exam Prep(第五版 Rita Mulcahy)》。这本书，是真的不错。我好好读了一遍，真的没时间读第二遍。书写得很明白，题也出得清晰，解释也到位，基本上没有看了解释还云里雾里的。但是，觉得题目的难度有点大，是真实考试里难的题那种难度。

虽然我看了一些参考书，但是，郑重的说：如果你没有时间，就参加一个考前培训班，就看PMBOK，就做题，只要按照培训班的要求，做题海战术，应该可以过。至少我考试的时候发现十几二十几道题是以前做过的。

我报的培训班，要求PMBOK中文的五遍，英文的2遍，你就照着这个看就可以了。实话实说，我还真的没有看到那么多遍……哈哈。不过，中文也有3-4遍，英文的1遍。

不得不承认，反复看的确能看明白。第一看跟浆糊似的，不知道说啥。脉络、框架一塌糊涂，细节更不用提。但是看了好几遍之后，终于觉得，恩，看出眉目了。所以就是书读千遍，其义自见。

三、考试的语言

虽然是中英文的考试，但是我们那一次考试，有一道题，非常肯定的说，中文不解其意，英文才是对的，反正就是中文和英文完全对不上。如果英文好的同志，建议以英文为主；e文真的不行的同志，就中文吧。除了前面说的那道题，其实翻译得还是很靠谱的，至少我为了安全，都是一遍英文，扫一遍中文，没有发现大的歧义。

最好一开始就决定考试的主要语言，然后就是练，英文为主的，确定你的阅读方式，比如，英文一遍，不明白再看中文，又或者英文、中文各来一遍；中文为主的，可是中文不懂了，看英文等等。

四、准备时间

个人以为，3个月足够了。反正就是拼命做题和看pmbok，如果按照培训要求做题和看书，偶觉得过问题不大。有些同志，打算6个月准备，原来我也这样打算的，现在瞧瞧，还真的多了，就3个月。一鼓作气就过了。

其实这3个月最有用的是考前1周，正好我运气好，在换工作的空隙，突击看了一周的书+做了一周的题，马上感觉进入状态。所以有时间的同志们，不妨一试呀。

PMP考试过程中，对于 EV （earned value，挣值）的理解是很多同学头晕的，但是我觉得PMBOK说得不是太明白，所以建议大家看参考书，尤其是《成功》那本，说这个DD说得很明白。

其他就是跟着做题，觉得培训班的题目设置还比较合理，渐渐的就把知识点都覆盖到了。所以做题做着做着就明白了。

从我报的培训班这次成绩看来，通过率下降了10%多，看样子PMI的确根据中国考生的通过率调整了一下。我和另外一个朋友拿到分数的感觉都是：应该没有错那么多啊？所以怀疑，200道题中不是有25个不算分，用作PMI调整难度系数的么，PMI根据考试通过率，把中国考生正确率最高的25道题替换了那25 个不算分的题。当然就是臆测。

所以12月份要考试，以及以后的朋友们，要加紧练习。要知道我平日在培训班，最差的正确率都有70%以上，绝大部分都在75%-80%以上，但是这次成绩出来却只有68%左右……差点就要不过了。

虽然感觉有十几道是见过的，但是没准PMI把它们调整成为不算分的题了……

虽然项目的特点是“独特、临时、渐近明细”，但是项目经理也应该具备足够的内省态度，对自己坚持做着PDCA。

通常我自己review的是这几点：

1）这个项目的特点是什么

项目可分为大项目小项目，大项目可能比较关注任命合适的管理人员，尤其某类角色有好几个人的时候，比如，构架师，BA，Testing等等；也可能关注的是协调方面，那么哪些是大项目要控制的点，哪些是要尤其注意协调的地方等等。

小项目可能就要自己做具体的事比较多，那么自己缺乏什么知识、哪些点需要控制，等等

也可以根据项目的领导关注度来分，领导关注的项目，哪些地方不用太操心，用什么方式协调比较见效；领导不关注的项目，业务人员又很忙的时候，用什么方式协调促进？

还可以根据业务的类型来分，比如，财务的项目可能因为系统比较多比较完善，人员的IT素质就会比较高，那么可能在业务需求这个角度会容易，但是也就容易挑剔，财务的及时、准确要求高，数据的分析功能要求多等等。

当然每个人总结特点的方式不一样，但是，总结是为了以后遇到类似CASE的时候能够 认出来：我曾经做过 有信心：我能做更好

2）人的特点

我始终觉得，项目都是人做的，所以学会应对不同的人很重要。

比如，有些领导脾气大、多变，那可能的方式是什么呢，当众他说什么都不要反驳（免得他脾气上来了非要做点怪的事情就麻烦了），待到人少了，单独和他说，好好说：领导，您的……很好，如果……就更好了，然后他一首肯，你就赶紧发出去邮件，敲定事情。（免得他又事后改变主意）

项目经理，永远记得达成项目的效果最重要，途中千万不要意气用事。所以学会对付不同的人，就是为了在不动气的情况下做好项目，损耗还最小。

最近朋友说了个真事，很有意思，一个大项目，前方有BA，项目经理在后方。前方的BA常常写邮件：我们在前方如何辛苦，希望后方的人员对我们支持！（这就明着说后方的人不支持他们） PM很火大。后来遇到前方的BA说后方没有做好一个预定的功能，邮件照样含沙射影，后来发现自己搞错了，这个时候PM回邮件：请前方人员保持镇定，不要慌张……（一样含沙射影说前方的人）忙着和前方打嘴皮子仗了……而且这些吵架的邮件还抄送部长等各位老大……

到了这种时候，大家之间的关系就是冷嘲热讽，虽然没有破口大骂，但是对彼此都无好处。PM一定不可以意气用事，遇到这些事情，要冷静的处理，处理好大家的关系，保持和睦。鼓励内部、私下解决是PM应该做的，并且要针对人的不同特点采用不同的策略。

3）项目管理方法论上还有什么我没有做的吗

虽然国情不同，但是毕竟项目管理方法论都是best practice的总结，那么都有其精髓的地方。对比自己做的和best practice，就能找到薄弱的环节。通常我比较注重有没有，而没有太注重形式。也就是说，我会注重best practice上的事情我有没有做，但是至于人家是要written formal，我可能就是自己脑子里分析总结了，不是太在意。

即便有的模块、方法我不做，也会很清楚为什么我不做，缺乏什么条件做，假设以后要做可以怎么做。

4）多角度分析

这个不是要review的内容，而是review的方式。

可以设想一下自己是领导、是coding的、是testing的，等等不同角色的人，他们的关注点是什么，不关注什么。从这种方法中，找到项目的薄弱环节。

尤其是他们不关心什么，其实是衔接上最容易出问题的地方。比如，coding的最关心的是我赶紧做完交代给我的东西，能run就好；而不太关心这个东西业务上是否合理。哪里容易出错呢：改了这里没有改那里，或者出来的东西没有真实的满足业务的需要又导致一改再改。那么，怎么预防呢，每次都和coding讲讲业务，业务是这样走的，所以我们的程序这样设计。当BA告诉coding为什么的时候，他们的参与感是比较强的，相应的会帮助BA去想，这样可以吗？会不会不合理？所有人都需要被尊重和重视，告诉别的角色的人为什么、目的是什么往往会有比较好的效果。