PM，读《IT项目经理成长手册》

此书是工作后入手的第一本专业书，惭愧两年后才拿出阅读。不过项目管理类书籍，有了实践经验后阅读，体会更深刻。若无相关经历，会像读理论书般，既无趣，也难有感悟。这是项目管理的独特性造成的，凡涉及“管理”二字，往往需要的更多是软技能、综合素质。项目经理的实际工作，80%花在沟通上，一点也不夸张。硬技能，office套件足矣。项目经理看重的，跟进度、管理期望、带团队、定计划、监工、专题会、汇报，所需能力很难通过课本及理论习得。导致相关书籍，要么陷入操作细节，要么严重理论化。未入行的读者，读后很难有较大收获。对于读后的期望，不是“哦，原来项目管理是这样子的，转行后应该这么做”，而是“哦，这块我做时也是这样/相反的感觉。”

序言的作者经历介绍，与书中小M的升级之路类似。如打怪升级，技术员-项目经理助理-项目经理-项目总监-事业线主管，职场的道路，是在翻一座座逐渐高耸的山峰，需要的是无尽的好奇心与持续稳定的学习力。再重复一遍经常念叨的一句话，“系统学过、系统做过、系统总结过”。相信作者也是持续实现这三点，才能输出此书。难得的是项目管理相关任务，都做过，并系统地总结出来，既提供了流程/模板/方案，也分享了感悟/经验教训。

另一个亮点，在于每一章节，没有直接将怎么做。而是从背景出发，先分析为什么要做这个事。然后，是确定怎么来思考这个问题。而不是直接就动手干了。例如计划，先制定计划的计划，考虑项目组应如何制定计划。发现这也是牛人的普遍特点，接到任务，先考虑怎么看待、怎么思考问题，再专注到问题上。

回到项目经理岗位，没在乙方呆过，但有着充分接触。只能说，相比甲方，乙方就是海贼王中的新世界，把人丢到逆境中，借由近乎残酷的磨炼得以快速成长。不过甲方也有好处，对于组织设置、部门管理、业务如何与IT配合、IT流程、项目立项、业务等，可获得独特提升。不过甲方不能待久，尤其职业生涯前期，容易把人待倦了，提前养老。此外，要适应大趋势，产品经理，是个更promising的职业。告别传统IT，互联网产品经理，抓紧跳槽。就是赶上黑天鹅，今天还能是金三银四吗？还是等上三个月，经济回温产生补偿式的大量需求。

1. 概述

   1. 复杂问题，先考虑“怎么思考”，再思考要思考的问题

   2. 计划制定后，从实操、细节层面完整过一遍，考虑可行性

   3. 倾听时想的是“对方的想法是什么”，而不是想着怎么给对方一个回答

   4. 项目一开始就始终奔着结果去，直到结果达成，没人赶你走就坚决不离开项目

   5. 项目中的质量管理人员应该做什么，什么时候、标准下有权利喊停，必须明确。否则无制度保障，质量管理就会不断让路，质量管理成为摆设。

   6. 是“人”在确定项目目标，推动项目进程，使项目成果创造价值

   7. 谈判不仅是信息的交流，还涉及利益的交换。

2. 入门

   1. 因为项目的独特性，不是普通商品交易，交付成果买卖前看不到，对于最终要提供什么没法定义清楚，或达成一致，因此交付产品或服务易发生纠纷。因此为解决此问题，强调项目开始前的合同签订，明确描述最终产品是什么。往往签合同的同时已经决定了项目成败。（独特性的实战意义）

   2. 临时性决定了时间约束的重要性，往往是决定性因素。团队成员，接受任务的同时，必须明白“什么时候需要完成”；临时性造成了团队动态性强，如何快速组建有效的团队。（临时性的实战意义）

   3. 为减少不确定性，在能够满足要求的前提下，尽量采用成熟的技术和方法。因为旧方法的缺陷是清楚的，可以有意识避开，而新方法的缺陷难以预估

      1. 项目目标虽然明确，但事前对于达到目标的路径不清楚，对于项目完成后的确切状态不完全确定

      2. 干系人涉及多个组织单元和个人

      3. 团队面临的任务可能是全新的，许多考虑不周的地方

      4. 计划和预算是基于对未来的假设，执行过程中与实际存在偏差

      5. 执行过程中突发的风险与意外

      6. 周期长，需求、功能甚至目标可能变化

      7. 开发人员的个体能动性、情绪

   4. 里程碑

      1. 时间点、标志性事件、交付物、关闭条件

      2. 达到里程碑后，评估项目，按计划进行，或走变更和调整

      3. 交付物经正式评审，进入受控状态成为项目基线。基线是一些重要里程碑上的交付物。

3. 前期

   1. 产品范围，用需求衡量完成度；项目范围，用计划。

   2. 功能清单

      1. 子系统，独立、完整的一组业务功能

      2. 功能集，子系统内按照业务特性归集的一组操作

      3. 执行单元，一次完成的一个独立业务操作

   3. 启动会后立刻进行培训，统一工作方法，并形成统一规范

      1. 项目管理概述、计划（统一项目管理过程）

      2. 项目开发过程、需求分析方法（流程、模板、样例）

      3. 产品知识培训（业务和技术能力）

      4. 管理工具培训（项目专用工具）

   4. 甲乙双方对于项目生命周期定义不同，乙方的项目起点，已是客户的执行阶段。因此乙方没有参加客户的论证阶段，可能忽视客户，为什么要做这个项目，解决什么问题，上线运行后能带来什么价值？

   5. 按期交付只是项目的最低要求，交付成果要解决客户的问题，给客户带来价值

   6. 项目打破组织的宁静，推动抵触项目的组织，为项目做事

   7. 涉及干系人，遇到困难，识别项目的得益者与失利者。由此可以找到关键点，利用非组织关系，设法得到高层支持。往往就是一句话的事

4. 落地

   1. 工作范围是实现目标的途径，是为目标服务。因此客户的潜在需求，增加工作范围，但大大减少了实施的工作量；确定工作范围的关键，是识别潜在需求

   2. 范围的分歧

      1. 前期没说清楚。商务阶段，销售关注签约，遇到模糊问题避而不谈；甲方有最终验收的主动权，有回旋余地，也无意愿主动提起。

      2. 没想清楚。因为项目的目的，不仅是业务流程电子化，而是业务流程再造或业务创新，很难想清楚，需在过程中逐步明确

      3. 没法控制。长周期，商业环境、政策法规变化，组织结构、人事变动，产生直接影响。

   3. 工作范围说明书

      1. 没有说清楚的，现在就澄清，或记录下来

      2. 没有想清楚的，设定假设条件，目前构想是什么，将来可能变化，或明确有地方需进一步讨论

      3. 无法控制的外部政策变化，在制约条件中列举

      4. 依赖的、无法控制的外部条件，在假设条件中列举

      5. 不但确认范围，确认双方的分工与职责

      6. 不但确认最终交付物，确认中间过程文件。即使不向客户提交，是工作完成的证据，计算完工百分比

   4. 越是无形的交付，越需要有形的文档证明

   5. 需求分析之前，组织客户的产品培训，逐个功能比较客户需求与产品的差异；整理需求报告并完成评审。

   6. 活动分解，第一层次划分

      1. 责任人不同

      2. 交付物不同

      3. 活动周期大于检查周期

   7. 资源配置，参照标准当量。落实到具体人时，再考虑个体的当量系数。

   8. 项目预算，按照科目和时间两个维度展开

   9. 计划与个人工作脱钩

      1. 没有细分项目计划，以班组为单位，公示板布置小组成员每日任务，管理底层计划，根据执行情况随时调整

      2. 返工和复返，导致个人工作集合无法赶上整体计划，因此也就不看计划，抓什么就做什么。好的工作成果，作为样例参考；提交客户前，检查表自检，质量经理统一审核，拒绝边干边改的状态

   10. 周例会先确定真实状态，再讨论如何调整工作或计划；问题、对策、需要的帮助

   11. 计划本身没有用途，不断进行地计划才有用

   12. 只有提前建立了工作结果的验收标准，才能确定如何是完成任务

   13. 变更失控

       1. 私下沟通，总体失控。程序员不做记录，小量积累，需求、设计和代码无法保持一致

       2. 业务未达成一致，反复修改。

       3. 违规操作。直接在测试环境修改，无版本控制

       4. 没说明变更的影响。变更都是有代价的，未让客户清楚代价

   14. 变更控制

       1. 授权；杜绝私下交易，屏蔽客户内部的矛盾

       2. 审核；变更的必要性及优先级，特别是不需要立刻修改，可以后续逐步优化

       3. 评估；变更的代价，对各方面的影响

       4. 确认；评估结果必须要让客户知道，确认是否接受相应的代价，在确认过程中有了与客户协商的机会，这样可以知道项目组的苦劳，吃的是明亏

   15. 变得的目的不是让变更更困难，而是让变更更有序

5. 沟通

   1. IT项目目标不仅在于提供系统，更在于提供的一系列服务。影响客户满意度的不仅在于最终交付物的质量，包括过程中客户对人的体验，对过程满意。

   2. 客户的需求背后隐藏着真正的需要，这才是客户成功的标准

   3. 利益大于立场。将利益相悖，变成利益相同的谈判，与客户绑在一起，共同利益超越双方立场的差异。

   4. 做出让步时，也要达成妥协的平衡，即是双赢。

   5. 软技能涉及的问题，往往解决之前感觉非常难，但解决后又觉得十分简单。实质是改变思考问题的立场与角度，进而不同的解决问题的立场与方法

6. 质量

   1. 质量在过程中产生，在结果中体现

   2. 质量保证

      1. 评审。中间产品检查，早期发现缺陷减少修改和返工

      2. 审计。工作过程检查

   3. 质量控制

      1. 测试。单元、系统、集成、性能

      2. 缺陷跟踪。确保所有问题都有结论，但并非一定解决。

      3. 变更控制。

      4. 配置管理。记录中间和最终配置项变化的历史，确保正确性和一致性

   4. 评审会，关键挑选评审专家。无利益关系的有经验同行，与有直接利益关系人进行制衡，牵涉到责任传递。

   5. 质量的问题往往是基本规律的事，大家都知道，但心存侥幸。因为成本和进度显而易见，但质量问题相比无法直观看出。

   6. 按规范测试短期看是在拖延进度，长期看是降低成本。开发需要的人力时间不能缩减，否则系统少功能。而测试的作用看不出来，因此后期的进度问题，往往压缩的是测试时间。而保证质量最有效的方法，是测试。每道测试尽量多拦截缺陷，才能保证质量，否则缺陷就是在uat阶段面向客户时，集中爆发。

7. 团队建设

   1. 充分授权也要必要的检查。没有检查，完美的计划也会偏差。事前明确，交付物是什么，标准是什么，同时确保说到位了，做事人理解正确。

   2. 平易近人，想掩盖你是管理员的身份反而会失去成员的信任。记住是公司委派，再小也代表公司利益

   3. 团队的问题

      1. 组织结构设置，人为造成的矛盾。没有统一人，对纵向功能负责，沟通成本高

      2. 各小组的目标矢量和，不是总体项目目标

      3. 工作重点不突出，战线拉长。派人支援不必现在进行的工作。导致很多任务分派时，大家知道无法按时完成，反而失去完成目标的动力。大家都知道无法达成的目标，就不会认为是目标了。着急不重要的任务，由项目组解释，顶住压力。

      4. 项目任务存在相关性，工作负载不均衡，缺乏横向的平衡和调度。任务紧急，自然抓好用的人干活，导致忙的越忙，闲的越闲。结果好用的人变得不好用了。

      5. 过于强调领导力，缺乏必要纪律，奖惩不明。

   4. 各小组挑选核心骨干，资源不足时横向补位。但不能让雷锋吃亏，及时激励。

   5. 团队建设不在于管理方法的先进性，而在于准确定位问题，相适应的对策。具体正确的目标+白板就足够了。

   6. 个性成员的问题，从反馈的公正性和被接收程度出发，通过团队会议方式解决。避免项目经理直接找个性成员引起新的矛盾。

8. 项目总监

   1. 关键是找对切入点，前提是能分析现状和问题，进而才能发现改进的机会。

   2. 两头说清，中间透明。立项时说清目标，结项时说清是否做到。中间在里程碑进行检查，每周通过周报跟踪项目的进展、问题和风险。

   3. 项目生命周期的6个事件

      1. 售前立项

      2. 签订合同

      3. 售中立项。内部批准预算、进度计划，可以获取资源执行项目

      4. 组织监控。组织级监控，纠正措施

      5. 验收开始

      6. 关闭项目。系统中关闭项目号

   4. 三分钟说不清项目进展，说明管理没有到点上

      1. 自顶向下，滚动更新三层制定计划，逐渐细化计划

      2. 白板记录及更新底层计划，动态跟踪到每个人的任务完成情况，自下向上逐层汇总，进而确定整体状况

   5. 售前谈是亲兄弟明算帐，以后谈就是撕破脸

9. 项目群质量管理

   1. 组织级配置管理。产品研发项目之间、研发项目与客户化项目之间，版本发布规范不一致，开发进度不同，导致不清楚接口标准变化或最新版本，两个系统因接口报错，或版本错误已修改问题重复出现

   2. 配置管理系统，从面向文件到面向任务。关联文件构建新版本我，修改了哪些文件，修改后版本号

   3. 系统投资一次性，组织能力可以沉淀和固化。管理能力固化到系统中，变成组织能力并不断优化；而增加人员持续成本，管理成本上升，人员变化带走能力

   4. 确定一个角色，职责、范围、方法

   5. 推拉结合点，捂的压力，亮的动力

10. 组织级资源管理

    1. 企业文化、软技能、危机应对恰恰是在管理流程背后最重要的部分，决定了流程和方法的实际效果。

    2. 假设你有一颗银弹，可以解决任何问题，你会解决什么问题。通过银弹讨论，聚焦扫描目前交付中最突出的问题是什么。

    3. 搭班子、定战略、带队伍

    4. “开发中心比他们现在管的部门大近10倍，理论上只要找到10个跟他们一样的人问题就解决了。”