PMP考试
在去年就报名了今年三月份的PMP考试，着手学习，没想到由于疫情一延再延，等到能考试的时候，这个证书已经变得不那么重要了。
我主要是通过书和习题来准备考试的，外国人考试的思路和中国人非常不同，他们非常在意细节，所以给我的感觉是在看书阶段觉得获益良多，到了刷题阶段反而变得枯燥乏味了，但是这中间依然有很多收获，结合了之前的项目经历也发现了项目中存在的很多问题，整理了这些内容后形成了这篇笔记。
Notes
项目经理的职责
工作态度
项目经理应该积极主动地工作。
是一条是PM指南对项目经理的一项重要要求，也是考试的重要考点（不积极主动的选项基本都是错的），这是一条看起来简单，但是实践起来非常困难的要求。
在项目的开始阶段，大家基本都是斗志昂扬的，但是随着时间的推移，项目遇到的问题可能会逐步累积：
- 不同的用户对产品的需求是不同的，产品总是各方权衡的结果，用户之间的矛盾越大，抱怨就越多
- 部分客户可能会直接要到内部人员的微信，直接找到内部人员下达需求
- 当项目不达预期，会有来自内部和外部诸多的压力，这些压力会直接或间接地传递到团队
- ……
在上述情况发生之后，很可能会形成恶性循环，导致士气不断下降。在这种情况下，项目经理就是必须默默抗下所有的那个人。对内：需要鼓舞士气，激励大家；对外：在客户那里要装孙子。在领导那里还需要表现团队的业绩、秀努力。
因此项目经理反而成为了整个项目最容易崩溃的单点，一旦项目经理干不动了或者灰心了，很可能会带来毁灭性影响，所以这也是项目经理的第一条要求。
主要责任
项目经理需要对整个项目的交付内容负责。
这一条定义了项目经理的主要责任，在实践过程中，可能会遇到的主要矛盾来源于权责不统一。PM指南中将公司从项目和职能的角度进行了分类，主要有：职能型、矩阵型、项目型。其中，只有在项目型的公司里，项目经理拥有对项目内所有资源的直接调配权力。
项目经理面临的巨大挑战是，没有足够的正式权力，也要把项目做成功。
大部分情况下，项目经理是没有直接调配资源的权力的，但是项目经理又需要对项目的交付内容负责，所以项目经理经常需要为他不能控制的事情负责。这种情况也会对项目经理的积极性造成负面影响，另外由于正式权力的缺失，项目经理需要通过专家权力、个人魅力等其他权力进行补充，从而控制项目。
工作内容
项目经理的大多数时间（甚至高达90%）用于沟通，他要通过沟通来协调，通过协调来整合。
项目经理工作的日常就是沟通，这个和技术专家是非常不同的，其实大部分的leader岗位，也兼具了项目经理的很多特点和工作。也因此，技术专家并不能直接提拔为leader或者转职做项目经理。
做技术的总是会调侃“埋头干活的搞不过写PPT的”，以前我也对汇报和润色嗤之以鼻，总会把“talk is cheap, show me the code”奉为真理，但是不可否认的是汇报本身也是沟通能力的一部分。公司对工程师和leader的要求是不同的，必须深刻的理解到这一点，才可以扩宽自己的思路和视野，不断建设自己的沟通能力。
项目管理的注意事项
基本准则
做项目，不能没有项目章程，否则项目就没有基本的保障。
其实在互联网行业，大部分的项目虽然以项目的形式存在，但是其实是没有项目章程的，最多有个共识就已经很不错了。然而很多时候为了快速启动项目，可能连基本的范围、目标都没有定义清楚。
这样做的问题在创业公司体现地淋漓尽致，项目做好了也不知道如何进行奖励，因为一开始就没有成功的标准；相反，如果项目出现了延期等问题，那么立刻会形成一场批斗甩锅大会，尤其因为没有章程的优先级和重要性的定义，在项目索要资源的时候会异常困难，还可能随时被剥夺资源到其他项目上。
这一条是要求其实是为了保护项目经理自己，如果项目非常不明确，风险极高那么接手就需要非常慎重，应该在达成基本共识、或者正式授权以后再开始。
项目执行应该是被计划管着的，而不是被领导管着的。
我想但凡做过项目的人都应该知道这一条有多难实现，很多领导并没有这种意识，甚至对于独裁风格的领导可能会故意弱化计划和规则，让整个管理体系变成完全的“人治”，他们往往会认为这样做才能把所有权力掌握在手中。
即使外部环境恶劣，项目经理还是应该在力所能及的范围内践行这一条准则，将项目管理的规则和推进的方式落到纸上，这也是PM指南中推荐的方式。
范围和变更
现代的三重制约是“范围、进度和成本”，以及夹在中间的质量。 三重制约的更新主要是为了体现“范围”的龙头作用。
很多时候，大家的注意点都会在进度和成本上，这从领导关心的问题中就可以看出来，最常见的问题就是：“这个项目还要多久”以及“这个项目花了多少钱”，却不太关心项目范围的问题。
相反范围才是整个项目的龙头和核心，如果范围都没有被确定，那么范围的蔓延几乎就是板上钉钉的，后面的进度落后、成本超支也就近在眼前了。而且对于老板来说，客户能满意那就是最好的，毕竟新加的需求，都是可以通过加班来解决的嘛。
如果变更超出了一定的数量、一定的规模，项目就会失去应有的控制。
执行项目的时候，客户总会觉得变更是理所当然的，尤其在敏捷管理大行其道的当下，变更似乎就是常态。但是变更也是非常危险的，如果下达变更太容易，变更本身又没有很好的评审，那么变更的规模就会迅速的累积。
在我们的项目实践中，变更的任务量可能会超过原本任务量的数倍，这直接导致了项目的时间和成本也成倍增长。这个时候，老板可能已经找上门质问项目经理为什么项目这么失败了。
所以一定要对变更保持警惕，尤其在项目开始就要对变更的方式和标准达成共识，最好能有文档输出防止扯皮。
镀金
镀金往往是项目工作人员为了“讨好”客户而做出的。
PM指南中是明确反对项目镀金的，甚至直接写明了镀金了的项目是失败的。但是这在实践中几乎是不可能的，项目的甲方随时可能要求增加一些“优化性”的功能，另外由于不同参与人的职位和视角都不同，还可能会提出更多的无理要求。
我们曾经为了一个甲方主要的参与人对我们客气点，主动协助他完成了一部分他分内的工作，但是情况并没有任何好转，对我们的系统还是提了非常多没有根据也不在原本范围内的需求。
质量保障
质量主要取决于管理者所建立和维护的管理系统，而不是每个工人的个人努力。
这一点是提醒项目经理，当质量问题出现的时候，应该先检查管理上面的漏洞，因为有质量问题往往是管理系统有问题导致的。
出现问题之后，最重要的是着手解决它，而不是追究责任。
在实践的时候往往是先追责再解决问题的，反过来的主要问题是在追责的时候可能就产生了很大的内部分歧，变成甩锅大会，从而导致问题迟迟得不到解决，而且越大的问题越容易被延误。
沟通管理
知道个性是引起冲突的最少见原因，有利于处理冲突时对事不对人。
在遇到冲突的时候，很容易会让人有所偏袒，比如：就是因为这个人不爱沟通、或者因为他性格恶劣导致的。但是大部分时候，这些都不是真实原因，需要找到真实原因，对事不对人地解决问题。
避免说“这个方案不好”、“这肯定不会起作用”等不利于沟通的话。
这一条是写给我自己的，并且可能很多技术人员都会容易有这个毛病，因为技术方案常常只有合适和不合适两种结果。但是在沟通的时候不能这么直截了当，最好不要直接说不行，或者说如果真的要说不行，那么也应该给出完整的理由。
风险管理
如果项目整体风险太大，那么无论对当个项目风险的管理做得有多好，项目也是不可能成功的。
在项目的开始阶段，就应该能识别项目的基本情况。对于范围蔓延、时间不够、预算很少的项目，不应该在项目开始之后才去管理范围、时间和成本，而是在一开始就应该对此提出异议，在风险太高的情况下不开始项目，这才是对公司和对自己更好的做法。
