更新 2017-8-10
上个月底收到邮件通知，考试已经通过，成绩差强人意：2P3M。
从备考经历来看，考试通过不是问题(侧面反映出该证的含金量很低)，但学会PMP的思维并应用到工作中，是一长期项目。
引子
4月底开始,主要忙于准备PMP考试。在学习PMP之余，通过freecodecamp学习Bootstrap，通过iTunesU学习Swift，由此技术心得总结没有以前那么频繁了。在学习PMP中，发现PMP中的一般通用理论，对工作、项目以及公司人际交往等都有帮助。下面，就自己的经历发表下个人的浅薄看法（虽然考试成绩还未出来，有可能没有通过:-(）。
PMP项目管理
生活、工作中的事，无论大小，都可以当作一个项目。因此，做事的时候，项目管理的通用理念无疑可以运用其中。简单的事情，可以省略某些环节、步骤，但不意味着处理事情的思路也可以省略。我建议，每一件小事，每一个项目，都能完整地以项目管理的思路去对待，那么个人的职业能力和专业素养会得到很大的提高。
下面，结合所学所思所想，把自己的些许心得记录下来。
干系人
所谓干系人，就是和项目有关系的人。准确的定义囊括两方面的意思：和项目有关的人；受项目影响和自认为受项目影响的人。有利益的地方，就会有纷争，而这说到底，还是由人引起的。所以，识别“人”，识别他们的期望和利益，很重要。而且，越早识别越有利，识别得越充分越有利。
以最近遇到的事情为例：收到某部门求助遇到某issue求解决的邮件，邮件同时抄送了产品支持组和市场组。当时，刚收到邮件的时候，我以为是个技术问题。正准备理清头绪，然后交由产品支持组接手时，我突然想了下，为什么也抄送了市场组。进一步调查才发现，这个issue不单是纯技术性的问题，还兼有业务调整——市场组在两周前对某个环节进行了修改。因此，接下来的步骤，就是召集该部门和市场组代表讨论后进行处理。
沟通
沟通在一个组织中的重要性不言而喻。沟通的目的是弄清干系人的需求，当前发生的问题，和成员共享信息。挖掘需求有很多的方法，如会议、图表、直接谈话。会议怎么开一直是个永恒的话题。就我的经验而言，开会前最好准备个材料（涉及商业机密的不要发），告知开会的主体和议程，带着问题和目的去开户，效率会比较高。还有一个重要的地方，就是会上内容和团队共享。实际中，经常发生团队代表参加了会议，但却没有很好的会议结论和各自团队共享。这种情况下，建议预先定义相关术语，使大家对业务和技术的理解一致。如果是纯技术的沟通，那就会相对简单：技术文档是技师人员的利器，不容易造成误解和盲点。
风险
风险是项目绕不开的问题。对于技术出身的人员来说，最大的问题就是只认为技术上的可行/可能与非作为风险的单一来源。而其实在实践中，技术上造成的风险，可以通过变更范围/时间/技术方案来解决。倒是和组织相关的政策流程、行业约束相关的风险，需要多多分析，免得考虑不全，影响项目进度。
团队建设
一个高效的团队，必定有一位高情商的项目经理。在没有系统学习PMP之前，就深深地体会到团队建设的成败直接影响到项目的成功。团队建设的成功与否，直接取决于项目经理的情商——和不同的人，用不同的方式，说不同的话，解决不同的问题。实际项目中经常会遇到技术“牛人”——就是觉得技术我最牛，没我项目就黄的nerd，与此同时，还经常鄙视不懂技术的PM。和这样的人打交道就要注意既发挥其所长，又在团队中体现出PM的领导力。这样不单单是人际技巧的范畴，更多的是个人的情商。
以冲突解决为例，我印象最深刻的是，在一个开发进入倒数周期的项目，主力前端和后台开发吵起来了。当时，我当机立断，了解情况后，凭着自己的经验，同他们二位一起立马定下方案，避免了延期的风险。这种情况下，立马下决断是必须的选择。后来，我也反思，如果是设计阶段或者开发开始阶段，我又该怎么处理？我想，此时应该收集各方意见，开会讨论，比较论证再做判断。
一些方法和图表工具
我们常见的头脑风暴，鱼骨图，思维导图等工具在PMP都有介绍，主要侧重方法／工具的特点，和应用场合。学习过后，决不意味着掌握了这些方法／工具。比如思维导图，我之前看过相关的书；平时看书的时候，也会用思维导图记录笔记，但我还是觉得没有深刻的理解这个工具。同样的，在学习质量管理的时候，龙卷风图，决策树图等等，都是需要在实践中深入的。就像大家都有一块生铁，需要各自修炼才能铸造成你的利器。
结语
以上是迄今个人的一点体悟，可能不够完成，也有点浅薄，但我个人是深感裨益。正如书中所说：提供了项目管理的一般理念和方法论。运用到实际的时候，还是要根据现状灵活处理。但我想说明的是，运用项目管理的思想来思考问题，处理工作，的确可以大大提高人的思维、工作和业务能力。
其实，原本想打算成绩出来以后再写本文。后来一想，如果考试没过，我就不总结了吗？至少，我还是学到知识的，想到这里，就厚脸皮的把浅见拿出来曝曝光了。
Comments