项目经理常见难题知多少？从涣散的团队到左右逢源

（一）项目经理经常遇到的疑难杂症，怎么解决？

1. 症状

项目的最后期限总是一延再延，其原因也各式各样，其中包括计划不周、意外频发及业务复杂等。
你也可以下一道死命令，要求项目必须赶在最后期限内完成，但是这无异于自欺欺人。
不能遵循项目的进度安排或者不断将项目延期，将会导致项目团队成员的行为变得非常糟糕。
如果你的团队总是一而再再而三地贻误项目期限，你凭什么认为他们会改变这种行为？这些问题是贯穿于整个项目，还是仅局限于项目早期的几个阶段？谁应该为此负责？没有项目最终期限也意味着纪律涣散，缺乏约束。

2. 对策

项目经理可以将可交付成果分解开来，要求项目团队每两个星期就要完成一部分有价值且可衡量的成果。这样成果会逐渐越积越多。
对于风险较高的项目来说，这个时间可以设定得更短一些。对可交付成果进行管理使得项目监管变得更加容易，同时也能在连贯的基础上进行风险管理。

1. 症状

即使大家都尽了最大的努力，还是有很多因素会导致项目要求经常发生变化。
例如，提出新的想法；原计划考虑不周；业务的利益相关者改弦更张等。关键是要搞清楚，是要求发生变化了、被修改了，还是有所补充和完善，抑或是被其他要求所取代。
如果某人一直在改变主意，那你就要怀疑他是否真的知道自己要的是什么。
这种症状是项目出现问题的征兆，预示着在项目预备阶段就有可能蕴藏着深层次的矛盾和问题。也许是对项目的预期不明朗，或者真正的决策者没有参与项目的决策，或者真正的利益相关者并没有被识别出来。

2. 对策

要求不断发生变化，背后的动机是为了让客户和用户满意。
在项目启动之初，即应明确变更流程是如何操作的，以及何时需要应用这一流程。让相关方了解，未来的要求变更将要求项目团队再次发布项目信息。

在要求发生改变之初，就应该让相关方了解它将对成本、利益和项目本身造成的影响。让用户或利益相关者在这些事实的基础上做出决策。

1. 症状

业务决策有始无终、摇摆不定是风雨欲来的征兆。
许多项目，不论是二人小组还是价值五千万美金的大型项目，都有可能是建立在某个高层的业务愿景之上，而该愿景则是由若干尚未完成的“故事”大纲和业务章程组成的半成品。

这样的愿景只能带着项目团队前进一小段，直到你发现由于项目缺乏清晰的目标而必须不断返工为止。

2. 对策

项目生命周期之初，就该确定以下几项决策：
谁是企业的所有者，谁决定最终的项目验收条件？
项目的最终产品应该是怎样的？
缺陷率为多少是可以接受的？
最终解决方案的绩效以及运作指标有哪些？
准则有哪些？哪些是关键？
剩下的准则中，优先次序如何？哪些将会被用户所接受？

1. 症状

当某位项目经理第一次听到项目已经完成了90%，肯定会异常兴奋和开心。
项目完成到这个程度是不断累积的成果，而且其成果应该是在定期的进度报告或进度会议上予以汇报的。然而进度报告可能会存在若干问题。
该数据通常都是建立在对项目的不精确评估之上，或出自于项目经理、项目协调员的直觉。剩下10%有多复杂依然是个未知数，而且这个看起来较小的百分比还有可能让人掉以轻心。

2. 对策
项目倾向于滞留在这个阶段。当项目进度在相连的进度报告期间内停滞不前时，要好好想一想原因。这可能是由于新的项目要求所导致的，也可能是早期的进度汇报不真实的结果。
通常，你所看到的下降比率可能并不会很低，因为项目团队出于主观愿望，会对进度报告进行一些修饰。所以问题可能远比报告上所显示的要严重得多。

1. 症状
所有项目，只要不是太过微不足道，都会时不时碰到这样或那样的阻碍和问题。虽然其中的许多困难也许很容易被克服，但还是会出现。
如果这些困难没有上报，就说明项目团队要么是对项目探究得不够深入，要么就是没有就相关信息进行沟通。

2. 对策
项目经理也许需要仔细研究当前的项目进展和可交付的成果，以确保所提出的问题正是要旨所在。
如果项目真的进展得非常顺利，那么在到达某个阶段性里程碑时则理应庆祝一番。

1. 症状

项目的关键可交付成果，有时也被称作阶段性目标，不仅仅指的是项目的最终成果，还包括用以确保项目顺利进展的阶段性可交付成果。
没有阶段性或者最终可交付成果的目标预示着麻烦将至。如果要求提交阶段性或者最终可交付成果会造成混乱，那么就必须借助项目救助方案了。

2. 对策
当项目正处于下滑状态时，项目救助方案是一项旨在迅速改变其方向的阶段性的应对措施。
这要求项目团队必须为实现某些利益而做出相应的妥协。同时救助方案还须为项目设定发展的步调及氛围，从而使得团队成员能够兴奋起来并做到人尽其才。

1. 症状
在推进项目的过程中，人际关系问题不可避免会发生。
然而，对人际关系处理不当，会导致难以挽留员工、员工扬言离职，造成员工间的不愉快、士气低下，出现恃强凌弱、自保反抗的局面，甚至引发无谓的口水战，以及各个层面上的政治纷争。

2. 对策
人际关系问题的出现警示我们应该探寻更为深层次的原因。由此而引发的其他问题将会浮出水面，包括质量不过关及贻误最终期限等。

1. 症状

质量问题在项目的正常发展阶段也许并不明显，因为现在还尚未交付或尚未实现正常运作的成果可在日后另行交付。然而，质量问题的数量也不能超过一定的界限。
质量问题诚然是困难的一种，但是你也可以在出现质量问题时决定是按下求救的按钮，还是认为这尚在可接受的范围之内而予以承受。

2. 对策

我们应在项目的各个阶段通过回答下列问题，对质量期望值及质量保证流程进行界定：何种类型的错误是可以接受的？错误孰轻孰重，如何解决？应进行怎样的测试，从而发现错误？

1. 症状

你肯定曾经多次听到过这种言论：“别把时间浪费在什么进度报告上了，实实在在地干活才是最重要的。”这种言论背后的观点都是非常高尚的，也可以被运用到任何项目管理工具或程序上。
然而，在宣布进度报告完全无用武之地之前，我们还须从以下几个方面多加考虑。首先，如果出了问题，必须依靠这些报告工具来解决。其次，如果没有这些工具，当你知道有问题出现的时候已经悔之晚矣了。

2. 对策

由于缺乏项目报告工具，在那些没有向项目团队进行过汇报或沟通的领域内，铁定会出现问题。如能较早发现这些问题，也许能够将其克服。但是，缺乏报告工具通常意味着这些征兆将被忽视，直到已经太迟。

1. 症状

有些建设单位（甲方），在工程进行中会突然要求加快进度，比如说由于特殊原因工期延误，所以让你在短时间内做好某些分部分项工程。
关键就在这里，时间越紧凑，施工队伍人手一时不够，干活就越忙，这样，会存在只求速度、不求质量的现象，有时候多督促检查，还稍微好点，否则，干活质量会有很大影响。

2. 对策

甲方内部一般都是有考核的时间节点，要试着跟甲方的现场管理人员进行沟通，说明情况。
不要为了一味的追求速度而忽略了最重要的质量保障！另外，要跟班组长强调，多安排工人轮流干活，要是发现存在干活质量问题，直接处以罚款。


（三）项目经理如何才能左右逢源

项目管理最大的挑战之一在于项目经理必须能够快速识别项目利益相关方的性格特点，并能够采取相应的应对策略，使其能够为项目服务。项目经理必须能够迅速判断临时组织起来的项目组成员、第一次接触的项目客户等是什么样的人，并采取适合他们特点的人际交往方式。只有这样，项目才会有一个良好的基础。

对待人的方式有两种：第一种方式是“己所不欲，勿施于人”。这种方式在很多情况下有效，但有些时候也不尽然，你自己不喜欢的不见得别人不喜欢，你喜欢的不见得别人也同样喜欢。因此，就有了第二种待人方式，即别人希望你怎么对待他/她，你就怎么对待他/她。这种方式在商业场合可能更有效，因而，第一种方式可称为“黄金定律”，第二种方式可称为“白金法则”。人的性格一般会通过言谈举止反映出来，同时，既没有哪种性格是绝对的好，也没有哪种性格是绝对的差。下图将人的性格分成了柔性、拘谨、豁达和直性4个大的类型。两个维度结合起来，就有了合作型的人、社会活动型的人、指导型的人及理智型的人这四种人员分类。

项目是有生命周期的，同样，项目组也有生命周期。典型的项目组从建立到解散需要经过5个阶段，即：形成阶段、震荡阶段、 规范阶段、成熟阶段和解散阶段。在不同的阶段，处理人际关系的方式也是不一样的。

一、形成阶段

项目组的组建阶段为形成期。在这个时期，团队的主要特征就是“礼貌”。人员刚刚到来，彼此之间不一定很了解。他们均带着对实现项目成果的期望和个人期望来到一起，彼此之间非常礼貌。

在项目组形成时，确定项目目标和项目组的工作原则与方法，使其成为大家共同关注的焦点是十分重要的。项目组必须能够缩短这个时期。在这个阶段，项目组的每个成员都会自觉不自觉地对自己的行为进行约束，但是，他们会私下自问这么一些问题：这个集体值得我付出努力吗？我到底是否适合这里，还是作为局外人为好？哪些人可能成为我的朋友，哪些人可能成为我的对手？

在这个阶段使项目组成员从心理上融入团队是十分重要的，因此，指导型的人将扮演重要的角色。因为他们善于分析问题、定义概念。凭理性分析能力，他们能够使项目组成员领会到项目的真正目的，使大家看到齐心协力的好处，以及能够帮助大家确定迈出第一步的方法。

不同的团队发展阶段需要选择不同的管理风格。对于形成阶段来说，最好的管理风格是参与式和集权式相结合的方式。通过鼓励成员参与，可以加强彼此之间的理解和信任，也可以提供更多的关于项目方案和风险的设想。通过集权，可以将大家关注的焦点统一起来。

二、震荡阶段

当项目组真正开始工作时，会遇到各种各样的问题，成员之间将产生各种各样的冲突。这个阶段被称为团队的震荡阶段。很多团队因不能平安度过这个阶段而夭亡。

这个阶段是多事之秋。在短暂的礼貌之后，人们就不只是单纯需要精神动力了。现实问题常常会使人们产生困扰，项目组成员开始感到项目任务的艰巨和挑战，人们对项目的观点、方法等产生了不同的理解。在这个阶段，指望项目组成员和谐、全力以赴地投入工作是不切实际的。

这个阶段必须处理好权力、原则等问题。要做到这一点，团队成员必须多沟通、多与他人协作、多提建设性的意见和建议，否则就可能人心涣散。因此，社会活动型的人会发挥其重要作用。社会活动型的人能够鼓励其他团队成员相互沟通想法和感情，从而促使他们对团队工作给予更多的关注，帮助他们树立团队意识和体会到团队的温暖。

有很多项目组不能迈过这个阶段，它们可能会奔命于各种各样的协调会议中。虽然人们都彼此告诫要“精诚团结”，但实际上很少会取得理想的效果。项目组成员之间互相提防或攻击，他们不能将自己视为团队中的一员。

这个阶段项目经理需要同时采取集权、参与和授权三种管理风格。首先需要鼓励大家沟通和交流，因为很多误解和冲突都是由于沟通不够造成的。其次要有意识地授权给那些和你观点一致的人，这样不仅激励了这些人员，也会使更多的人能够帮助你争取更多人的支持。最后可以采取集权方式，不管怎么样，别忘了你是项目经理，你需要对项目成果的实现负总责。 

三、规范阶段

在这个阶段，项目成员之间的冲突得到缓解，他们开始在很多方面达成一致意见。通过风暴期的磨合，沟通和协作的必要性得到广泛认可，团队开始逐渐建立一种公认行为标准或者价值观，团队绩效和士气开始增加。团队成员中的自我意识逐渐被团队意识所取代，团队工作效率得到明显提高。

在这一阶段里，合作型的人悄悄成为举足轻重的人，因为他们擅长包容不同的观点并能够将人们个性上的差异和观念上的分歧转化为工作的合力。

这个阶段较适宜的管理风格同样为参与、授权和集权，但与震荡阶段相比，授权的比重得到明显增加，而集权的比重逐渐下降。

四、成熟阶段

在这个阶段，项目组已经成为一个真正有战斗力的团队，项目组以团队为荣，他们已经知道如何协作和相互支持，团队士气高涨，每个人的自我管理和自我约束能力已悄然变成了他们的习惯。这个时期的特点就是“交付”，会出现大量的项目成果。

对于前三个阶段来说，指导型的人都是需要的，因为需要他们去做出决策和力挽狂澜，但在这个阶段，这种专断、控制型的人已经丧失了用武之地。不仅如此，独断专行、强硬的管理方式反而会造成团队新的不和谐、造成团队效率的降低。在这个阶段，理智型的人如鱼得水，他们会将其专业能力发挥得淋漓尽致。当然，这个阶段的管理风格是以授权式为主流的。

五、解散阶段

随着项目接近尾声，项目的成员就逐渐离开团队，这个时期称为项目组的解散阶段。通常在项目可交付成果完成后，再释放人员，解散团队；或者在结束项目或阶段过程中解散团队。

这个阶段又会出现效率较低的情形，因为项目组面临调整，许多项目组成员必须考虑其将来的去向。在这个阶段，四种性格特点的人各有用处：指导型的人需要确保项目交付，合作型的人需要对业绩评价进行调和，社会活动型的人需要使团队成员对团队留下美好的记忆以及消除他们对未来工作可能出现的彷徨，而理智型的人必须保证项目交付物的质量，以免团队成员离开后出现问题。在这个阶段也需要采取集权、参与和授权三种管理风格：通过参与，积累团队经验教训；通过授权，维持团队效率；通过集权，处理评价和分配中的纷争。

尽管这些阶段通常按顺序进行，然而，团队停滞在某个阶段或退回到较早阶段的情况也并非罕见。如果团队成员曾经共事过，项目团队建设也可跳过某个阶段。

项目需要靠团队来完成，因此，无论是项目经理还是项目组成员都需要理解团队的建设过程、团队成员的性格特点，并寻求适合于项目、团队特点的管理方式，只有这样，才能建设成为一支真正的项目团队。


(三)那些年，被自己的技术者思维虐过的项目经理们

　　不论在哪个国家，IT 公司中的项目经理，很大一部分都是技术出身。的确，工程师背景的项目经理，在开发人员选择，开发进度控制，客户需求把握等诸多方面，有得天独厚的优势，从程序员到 leader 再到项目经理也是常见职场发展方向之一。

　　雷子个人认为，从普遍意义上讲，在日本，只要勤奋努力，向上走是很容易的事。但到了管理岗位，即使勤奋努力，有时候思维没有及时转变，也可能遭遇惨败。我就亲见过智商一流，经验丰富技术人员，初任项目经理时，分外努力却搞得焦头烂额，甚至在项目中途被换下，经过很久很久才熬到第二次被提拔……

　　职场上升之路，有时需要些时运，可能各有不同，但失败的原因，有时却很相似。那么，技术者在初任项目经理时，经常会遇到哪些问题，给自己挖哪些坑呢？

　　故事一

　　有时候，谎话连篇的项目经理才是好经理

　　A 君，认识他时，他是个年轻的 leader，技术很不错，还有开荒牛般的勤勉，性格也非常开朗坦诚，能力人品双佳，当 leader 时成绩斐然，自然的，他很快升到了项目经理，一时间意气风发。

　　A 做 leader 时很受爱戴，成为了项目经理，依旧沿用了一贯的坦率作风，事无巨细，和大家分享所有和项目有关的事。甚至包括：客户方面的负责人突然换人啊，咱们的契约很危险啊这些情报，也全都毫无保留地告诉给组员们。那么，像A预期地一样，全组拧成一股绳，项目圆满顺利地进行下去了吗？

　　实际上，并没有。在充分了解项目的同时，组员们也知道了大量的关于这个项目的不利因素，倍感不安。私底下，咱领导心里也没底啊，项目要扑街啊，这样的议论越来越多，A明明比做技术时更加努力，但项目状况却每况越下，回天乏力。

　　最后，连部长都觉得“怎么搞成这样，哎，A还是太年轻。”无奈在项目中期换下了A，让经验丰富的B顶上。

　　B 是个待人和善，初次见面就会让人印象很好的人。上任后，B和整个项目组的人挨个私聊，发现了问题所在——很多人对本来不用他们操心的事感到不安。这种不安，有时甚至影响到了他们的本职工作。

　　于是，B把大家召集到一起开会，“通过沟通，我了解了大家现在的想法，和对这个项目前景的担心。不过这些担心，很多都是针对潜在的风险的，还有一些问题，是我可以通过斡旋调节解决掉的，balabala……”总之，就是天空飘过几个字儿，那都不是事儿。

　　这个会，开得效果很好，B自信满满，言之凿凿的一番话，很好的安抚了组员们的情绪，大家专心开发，项目进度竟慢慢地赶上了。

　　那么B真的像他表现出来的一样有自信吗？

　　事情的真相是，他非常了解——这个破项目，问题一大把。和组员说的话，很多都是他信口胡诌的……

　　作为项目组的普通成员或者 leader，不管说什么都要有根有据，信口胡诌是绝对不行的。但这不适用于项目经理。有时候就算是睁着眼说瞎话，也得把组员往正确的方向上带。

　　“不管怎么努力也来不及了”，一旦让组员有了这种想法，那项目就必定要完。互相扯皮，产生信任危机，生产性下降，品质恶化，是一连串的连锁反应。无论如何也要避免这种情况的发生。

　　教训一

　　项目经理必须要让组员相信：“这些情况早就在我的预料和控制之内，大家放心。”只有这样，组员才能心无旁骛的做好自己的事情。给组员们吃定心丸——是项目管理的手段之一。　　

　　这时有的同学可能会说，很多项目从一开始就明摆着是坑，瞎子都能看出来。但即使是这样，把真实情况全部如实传达给组员，也是一点好处都没有。就算项目真的无论如何也挽救不了，那也是项目经理一个人的责任。把真实情况隐瞒下来，让组员们安心工作，多少还有一点希望。就算扑街，也不会姿势太惨烈。反过来，把真实情况和盘托出，导致军心涣散，那就真的一点儿机会也没有了。

　　故事二

　　有时候，不会较真的项目经理才是好经理

　　C 君做工程师的时候，非常优秀。思维敏捷，逻辑清晰，精通各种开发语言。最重要的是，发生问题时，他一定要刨根问底的追查，不仅要找到解决方法还要找到问题的根本原因，从流程上改进，防止再发。这样的思考方式和做法，很多工程师都有。

　　当时的上司和同事们对C君都是绝对地信赖，即使有时他在刨根问底上花费了太多时间，导致进度延迟，上司也都是积极地同客户调整进度或者加人，从不给他脸色看。

　　当得知C申请做项目管理，而不是走技术路线的时候，大家都挺吃惊的。不过他作为项目经理，负责的前两个小型案件都完成得满好。这时他的上司有些放心了，觉得聪明又努力的人，做什么都会做得不错吧。

　　之后，他被指定去负责一个具有一定规模的项目。这个项目所开发的系统，有十几个子模块，每个模块有3～4 个成员负责。

　　一天，C收到了客户发来的邮件“项目进度全体看起来很顺利，但是几个子模块开发进度为什么有些延迟？什么地方出了问题吗？”

　　C 作为整个案件的项目经理，通常是掌握项目的大体情况，对于每个子模块开发的具体细节并没有过问。第一次被客户质问开发进度延迟的理由，C有点坐不住了，而且他也产生了同样的疑问。

　　于是，C君询问了这个模块的每个开发人员，得到的回答是：该模块所使用的部分第三方产品，有兼容性问题，加上调用方法不对，不断试错导致了这部分的开发延迟。可是C还是有疑问：“产品兼容性和调用方法不对，真的会导致生产性这么大的降低吗？”

　　于是C又开始了他对于问题刨根问底式的追查。把每个项目组成员负责的工作细细地捋了一遍，得出的结论是——恩，和他们说的一样。于是，他向客户如实地汇报了原因，客户也接受了他的解释。

　　但是他这么一折腾，本就有点儿延迟的项目，又浪费掉了更多的工数，给组员和他自己又加重了负担。

　　本来对客户作出最初的解释就完全够了，可是C并没有那么做。像做工程师时一样，在这个问题上刨根问底，但整个过程却只是他的自我满足。本来项目经理和成员之间是互相信任的，由于这件事，信赖关系也出现了裂痕。

　　在分析问题原因这件事上，项目经理追求的目标应该是客户的满足感。如果弄错了这个目标，花费了大量的精力，那就得不偿失了。

　　比如说客户问，为什么这个系统能够运行？这个时候只要从产品框架的程度上给客户作出解释就完全够了。如果真要从编程语言和计算机原理的开始讲给客户听，只会让客户一头雾水吧。

　　确实，如果花费大量的时间精力，去把一个问题彻底弄清，非黑即白，对今后的工作是有帮助的。但这是工程师该做的事情，而不是项目经理。

　　教训二

　　项目经理应该把更多的精力放在客户和成员的组织协调方面。有时候，不得不对问题的正确性和精准性做出妥协。从工程师出身的经理，往往在这一点上很难转变。

　　故事三

　　有时候，不会和部下同甘共苦的项目经理才是好经理

　　第三个故事，是我的故事。

　　大多数工程师都是很单纯很热心的人。如果组里的其他成员遇到了什么问题卡住了，很多工程师会留下来加班帮他一起把问题解决掉。但这种做法并不适用于项目经理。

　　我以前当工程师的时候，一次遇到客户要求调查一个问题，要的很急。我和项目经理两个人一直调查到很晚，都没有做完。眼看要赶不上终电了，项目经理一脸抱歉地对我说：“不好意思啊雷子君，今天就辛苦一下，加个通宵的班吧。”

　　客户要求的，也没有办法，所以我就很爽快地答应了。本来以为项目经理也会留下来和我一起加班，没想到这个大哥说了一句“后面的就拜托了！”然后拎包就回家了，只剩下我坐在那里独自凌乱。

　　虽然明知项目经理留下陪我加班没有意义，但当时不免心里是颇有微词的。直到后来我自己也当上了项目经理，才体会到他的做法完全正确。

　　我作为一个个体的工程师，只要对项目经理一个人负责就可以了。但是项目经理需要对整个项目负责，对客户负责。如果他留下来陪我一起加班，第二天早晨一起回家的话，那么第二天的项目推进谁来管？如果客户对于调查结果有追加的疑问，让谁来对应？就算他第二天不回家，一直留下来完成自身的工作，那恐怕也是精疲力尽，效率会大打折扣吧。

　　上面这张图是网上流传很久的，leader 和项目经理的区别。作为 leader，和成员们同甘共苦，是很有必要的，但项目经理绝对不可以。反过来，leader 和成员们只要低头努力工作就够了，但项目经理坐的位置，决定了只有他才能看到前方有没有深渊，后面有没有猛兽。这一点谁都代替不了。

　　教训三

　　技术者升级为项目经理，切不可再像做工程师的时候那样事事亲力亲为。懂得自己该做什么，懂得找擅长的人去做他擅长的事情，才是经营之道。

　　故事四

　　有时候，想着「等前提条件都确定了再开工」的项目经理不是好经理

　　这个故事是个段子。

某日，老师在课堂问一个学生： “树上有十只鸟，开枪打死一只，还剩几只？”

学生反问“是无声手枪或别的无声的枪吗？”

“不是。”

“枪声有多大？”

“80-100 分贝。”

“那就是说会震的耳朵疼？”

“是。”

“在这个城市里打鸟犯不犯法？”

“不犯。”

“您确定那只鸟真的被打死啦？”

“确定。”老师已经不耐烦了“拜托，你告诉我还剩几只就行了，OK？”

“OK，树上的鸟里有没有聋子？”

“没有。”

“有没有关在笼子里的？”

“没有。”

“边上还有没有其他的树，树上还有没有其他鸟？”

“没有。”

“有没有残疾的或饿的飞不动的鸟？”

“没有。”

“算不算怀孕肚子里的小鸟？”

“不算。”

“打鸟的人眼有没有花？保证是十只？”

“没有花，就十只。” 老师已经满脑门是汗，且下课铃响，但学生继续问,

“有没有傻的不怕死的？”

“都怕死。”

“会不会一枪打死两只？”

“不会。”

“所有的鸟都可以自由活动吗？”

“完全可以。”

“如果没有其他前提条件，”学生满怀信心的说，“打死的鸟要是挂在树上没掉下来，那么就剩一只，如果掉下来，就一只不剩。”

老师擦了擦汗说：“你一定是个程序员......”

　　编程做久了，往往思维方式会发生固化。工程师都对事物的逻辑性和因果关系有着执拗的追求，“把前提条件全都告诉我”，是工程师的常用语。当然，从工程师的角度来看，前提条件不明确就开工，最后能做出什么样的东西来，只有上帝才知道。

　　但是，这个世界上从来就没有过从最开始就明确了所有前提和需求的项目。这个时候，就需要对案件的情况做出各种假设，分析可能性，然后在保证最大正确性的前提下开工。如果在项目途中，前提条件或者需求发生了改变，那就再根据具体情况进行调整——这考验的是项目经理的能力。不这么做的话，项目永远也开始不了。

　　在设计第一台月球车的时候，如果 NASA 宇航局的工程师说：“请把月球表面的详细情报告诉我，否则我没法设计”，这样的话人类可能永远只能在地球上晃悠。当时，月球表面的状态只能从望远镜里观测到的景象进行推测。虽然前提条件很不充分，但也只有基于最大可能性开始设计，别无他法。

　　做项目也是一样。设计系统的时候，要假设各种各样的前提：系统使用年限，最大并发访问数，相关的法律会不会更改（特别是政府项目或者和金融相关的系统）......

　　教训四

　　先从最确定，可能性最大的部分开始做起，当需求和前提渐渐明确，再逐步调整进度和人员安排。对于项目全局的把握和大局观，往往是工程师初任项目经理时，最为欠缺的部分。

　　今天，和大家分享了几个小故事，愿大家在职场上升道路上避免这些有可能走的弯路，少付出一些成长的代价。

　　看法浅薄，期待与大家更多的交流讨论。更加欢迎老司机们向大家分享自己看到过，经历过的职场经验。

PMP考试时间
PMP考试在国内一年开展四次，分别在每年的3月、6月、9月和12月，一般会选择一个周六的上午来考试。由国家外国专家局培训中心负责组织实施。具体考试时间请您密切关注外专局培训中心网站所发布的信息。
2019年项目管理认证考试时间安排
3月30日
6月22日
9月7日
12月7日

PMP考试内容
PMP考试内容主要包括项目管理五个过程：
启动：确立一个项目或一个项目阶段。
规划：为完成项目，制定和维护一个可操作的计划。
执行：协调人力和其他资源以执行计划。
监控：通过监控和进度测量及必要时采取纠正措施以确保项目目标的实现。
收尾：正式验收项目或项目阶段并使其有条不紊地圆满结束。