作为乙方参与过软件项目的同学大多遇到过以下情况：
1. 客户什么功能都想要又不想多给钱；
2. 需求改来改去，没完没了，最可气的是改了半天改回到了最初的设计；
3. 系统上线前几天通宵改BUG；
4. 上线后明明功能齐全客户还是叫着不好用，不满意，要投诉；
5. 好不容易验收了客户又拖着不给钱，结果自己的项目奖金也跟着无限期延迟发放了。
我有幸经历过上述所有情况，还都不止一次。在经历过碎碎念、拍桌子、画圈圈、扎小人等各种发泄方式后不禁反思一个问题：这些情况的出现到底是谁的原因？我？还是客户？
如果是我的原因，我对自己的技术水平和职业精神还是有一定自信的，当程序员时开发出的软件产品最多有些小BUG，不会影响核心功能；后来转DBA，SQL方面也没有实现不了的需求，性能也都是刚刚的；再后来转BI工程师，做的报表也都是质量和进度都满足要求，但上面那些情况还是经常出现。
如果是客户的原因，一家客户是这样也就罢了，为什么那么多家客户都出现这种情况？总不可能这世界上无理取闹的客户都让我赶上了吧？
再后来我干脆跑到甲方，从甲方的视角来看乙方的软件开发工程师，才发现上面的那些情况大多数是双方都有负责。从项目管理的角度来看，是甲方项目经理和乙方项目经理的工作没做好，导致各种双方都不愿看到的情况发生。想要避免这些情况发生，光加强技术、做好开发工作是没用的，还要从项目管理的方面入手改善。
在项目管理这个领域，最有代表性和知名度最高的培训就是PMP培训。因此我就去参加了PMP的培训和考试，在完成了学习和通过认证后，感觉确实是有帮助的，以前自己确实有做的不对的地方。我就以上面那5种情况为例，简单说明一下为什么会出现。
1. 客户什么功能都想要又不想多给钱；
客户并不了解自己要的功能需要多少工作量，一些他认为很简单的功能其实完成起来很复杂，而他在这个项目上的预算是有限的。这里不应该直接报价，而是应该先分析需求，在得到客户对需求的确认后再估算工作量，然后再给客户报价。这时的报价应该是既能满足客户确认的需求，又能保证我们的收入。如果客户对报价不满，可以讨论能否去掉一些不必要的功能来减少报价和加速完成。
2. 需求改来改去，没完没了，最可气的是改了半天改回到了最初的设计；
客户提的软件需求并不一定是他真正想要的东西。项目经理应该在开始开发之前充分理解客户的软件需求及其背后的业务需求，并将自己设计出的产品通过DEMO之类的方式使客户充分理解其功能，确保双方对产品功能的理解一致，确保这个产品确实能满足客户的业务需求。
达成上述条件后应该与客户做书面的确认，并说明后面如果再改就需要走需求变更流程并可能产生额外的费用和完成时间推迟。
另外，最后改回到最初的设计这种情况，基本都是客户发现改完还是不能满足其业务需求，甚至还不如原来的稳定，所以只能退而求其次选择最初的版本，至少那个版本是已经验证过，知道有哪些问题的，可以减少功能验证的时间成本，最多通过其它方式补救。这种情况还是由于项目经理对客户的需求没分析清楚导致的。
3. 系统上线前几天通宵改BUG；
需求调研没做好，开发过程中也没充分沟通，留给客户验收的时间不够，就会出现这种情况。上线前客户追着问开发的怎么样了才急急忙忙的部署一个开发版本上去，客户随便点点就是一堆BUG，又没有合理的延迟上线理由，就只能通宵改BUG了。
这里的核心问题，是沟通和时间管理没做好，如果需求改的多，应该提需求变更，申请进度延后；如果出现了意外情况导致开发进度延迟，应提前通知客户。
4. 上线后明明功能齐全客户还是叫着不好用，不满意，要投诉；
参见第2条，同样是业务需求不满足的原因导致的，虽然这种情况乙方的责任会小一些，但最终项目还是失败的。
5. 好不容易验收了客户又拖着不给钱，结果自己的项目奖金也跟着无限期延迟发放了。
客户有可能是迫不得已验收的，可能在项目进行中对我们的某些行为不满意，总之就是对我们不爽，所以不想给钱。如果把客户伺候的很舒服，他为了以后还能找你合作肯定不会死命拖着不给钱的。
上面这些情况，虽然在PMP中没有具体说明原因和解决方法，但学完自然能把这些情况分类到一块知识领域中，并大概知道该怎么解决。然后自己再按那个思路多加思考，就能给出比较合适的解决方案了。PMP的理论本身并不能解决问题，但能给我们解决问题提供一个合理的指导框架。开发出身的项目经理普遍智商较高情商较底，学一学PMP能使自己的思路开阔许多，看到很多原来看不到的东西。所以只要你有做项目管理的工作，推荐都学一下PMP的知识。
