决定去学PMP

入行的时候一直都觉得PM这个角色好像没啥了不起的，可有可无（可无居多）。需求是需求人员谈下来的，软件是技术人员做的，测试人员测试的，实施人员部署的...还要PM干吗用？在个别环境下也确实认证了这一点。我想很多技术人员也有这样的感觉。

就这样过了很多年，中间也接触了很多各式各样的人物，有技术有业务有PM。渐渐的已经不再纠结这个问题了。反正不指望他们实现软件。随着接触的项目越来越多，成功的失败的也渐渐的多了起来。有时间的时候就会不由自主的在想。为什么软件明明做的很好啊，设计功能很符合永续需要啊。时间也没拖延啊。为什么，内部的外部的相关人士都不是很看好呢？问题千奇百怪，失败的表现趋势一致的：有人不满意。

示例1记得很久以前吧，一个朋友找到我想做一个网站平台，供给有需要的人，留下联系方式，方便有合作可能的其他人联系自己。对于朋友的需要必然倾尽全力。绞尽脑汁的想啊，设计啊。后来等网站完成的时候，朋友看完给了一句“没想这么多复杂”。虽然人家肯定了我的工作，却不肯定工作的结果。

示例2，那是多年以前的一个进销存项目，零售行业，老板急着上线。业务却还没有确定，但公司已经开始运转不可能等完全确定，软件再完全开发完成。难道大家都去喝西北风啊。迫于无奈，决定，分模块，快速建立原型，在使用中完善的方式进行开发。虽然有很多重复的劳动，不过至少保证了，公司业务的运转。

示例3，记得那时一个法律系统。刚接手的时候，作为程序员。在了解了项目进展和大致情况，并对软件进行了认真的学习后，发现存在很多问题，技术上的业务上的设计上的。虽然软件能用，可以不尽人意。当时项目已经进入了暂停状态。客户不摧，大家都去忙乎其他的项目去了。处于负责的出发点，上书领导，要求完善项目。结果给予的回复出人意料：等客户要求再说".。结果转眼1年过去了，客户要见面了，一切都提上了日程。结果呢？不言而喻，很多问题自己知道，硬着头皮去见了客户。客户也很认真提出了上百个问题。客观的说，大部分我们都知道，也是应该修复的。也有少部分不合理的。但由于大部分问题是客户发现的，我们已经失去了专家的权威性。在后来的交涉中，步步被动，毫无还价的余地。

示例4，一个公司内部系统，开始被公司外派总部学习业务，结果其他同事(相对年轻)已经开始谈需求，设计功能实现。学习归来后发现系统基本成型。但随着继续开发完善，发现问题不断出现，常常是修复1个，又出现1个。被领导调派过去协助。了解了全部文档资料后觉得业务上好像不对正确。虽然找不到具体例证，不过感觉有些问题要问，于是就问题了，比如系统要统计的多个销售代理点，会不会隶属于一个公司。答案是否定的，客户没说有这种情况，给的示例性数据中也没有这种情况出现啊。后来没办法，联系客户，找来熟悉专家帮忙确定这个问题，原来真的存在。当时修改核心业务设计是不明智的。只能曲线救国（技术解决方式没啥可写的，只要找到问题，技术没啥不能解决的）

示例5，最近来接触一个监控系统，比较奇葩的是，接手之前已经宣告开发完成了。我的角色类似维护，之前开发单位为公司，有一个正式的团队，结果仅有使用说明书。了解过程可不堪言。由于名义上开发是正式团队，项目软件已经验收等等。过于乐观的人为，至少此软件不会有太多低级问题。或者是基本是正确的。开始实施后，问题接踵而至。由于之前的盲目乐观，导致个别问题追查的时候，追错了方向，耽误了不少时间。最后几乎等于重新开发。

例子还有很多，但很多失败都不是发生在技术上的，几乎没有几个是技术上实现不了的设计或者需求无法显示。越是思考越是觉得奇怪。总结一下过往的经历，尤其是失败的，发现很有意义，大致可以分为那么几大类：

类似示例1，不明白用户到底要什么？

类似示例2，用户也不明白他到底要什么？如果你要等全部确定，那就别做了。

类似示例3，如果给用户一个权威的，专家的形象，方便在整个开发中确定良好的沟通。

类似示例4，用户如果意识不到的问题就不是问题了吗？

类似示例5，对于可能的错误，或者阻碍没有防范意识。只会盲目乐观。

示例很多，总结归纳之后，无非就那么几个大类，在PMP的系统学习之后，对应的都找到了相关的知识点。需求，沟通，风险等等。由此看来学习PMP是有必要的。于是下定决心，认真的学习一下PMP知识。