读书，为了学习，学习，为了工作。所以读书还是紧密结合工作的，可以绕一点路，从当前的学习兼工作的团队项目说起。
这次软件工程团队作业，Idea主要由我提出，所以需求都在我这里，从此PM坐定了。从学习计算机至今我还只做过全职的dev，单枪匹马，并未做过团队PM的事情。所以读书的时候，也就要着重想着自己作为一个新手PM，该有些全新的学习，也开始有些新的工作。笔记就写些PM做的事吧。
PM做开发和测试之外的所有事情
第一反应：这不科学吧……事略多啊！头很大啊，哪个说开发和测试以外就没事了的？显然不靠谱啊。
揣着怀疑，接着看。
仔细看了看这篇对于PM工作的一个概述的讲义，纠正了一些关于PM的误解。原来这里的PM是Program Manager，不是Project Manager。很明显的一个区别就是前者和后者相对于Dev/Test的关系不一样，PM是管事不管人的，这很靠谱。所以果然看到了开发和测试之外的事情，都需要PM来操刀。
看到一份老师罗列的PM的具体任务：
带领团队形成团队的目标/远景, 把抽象的目标转化为可执行的, 具体的, 优美的设计。
管理软件的具体功能的生命周期 (需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰)。
创建并维护软件的功能说明书 (specification), 让它成为开发/测试的及时准确的指导, 而不是障碍。
代表客户和用户的利益, 主动收集用户反馈, 预期用户新的需求。协调并决定各种需求的优先级。
分析并带领其他成员形成对缺陷/变更需求的一致意见, 并确保实施。
带领其他成员确保项目保持 功能/时间/资源 的合理平衡, 跟踪项目进展, 确保团队发布让客户满意的软件。
收集团队项目管理和软件工程的各种数据, 客观地分析项目实施过程中的优缺点, 推动项目成员持续改进, 从而提振士气。
可见PM能够控制一个项目的方向，比较像一个建筑设计师，他在脑子里有要设计好一副蓝图，有一个目标的印象，然后他要能够告诉建筑工人要做什么、做成什么样，PM的工作，主要在于连接需求与开发；同时又有管理工程的职责，能够安排要能够把项目的进度控制在计划之中，向客户交代——包工头。一个好的PM应当成为团队中重要的邪恶轴心，需要得到团队的支持并且鼓励团队，引导团队，带动士气。可见PM绝不是吃干饭的，只要有当“猪”的心，一样可以忙得跟“狗”一样。
从Steve Jobs和微软PM的故事中，可以看到，PM需要特殊的能力，那就是在发现需求这方面要有过人之处，同时需要有一种个人魅力，使项目能够按照自己的意志进行开发，不过这里就非常可能出问题了。有时候项目需要多个PM，因为软件项目之大，一个PM也许不能主导到方方面面，也不可能有一个人能够通晓涉及到的所有领域，这时候需要多个PM的解决方案
——怎么样使多个PM的协同更为有效靠谱呢？PM之间意见的分歧，是调和，还是相信精英呢？
看完文章，对PM的具体任务、实践指导有了了解的另一面，对于一个从未实际工作过的PM，还是缺少一些方法论。不禁会问，有没有更具体的科学指导方法？还是说，我们的科学在这方面无能为力，更多的还得靠经验呢？
若无前路，总不能、眼看工期降至，No Problem，No Progress，干着急。改变世界任重道远啊。
