项目管理学习

https://time.geekbang.org/column/intro/245
总结：保目标、助决策是要打通从战略到执行的闭环，提效能、促协作则是打通上下游协同的闭环

三个误区

• 凡是恨不得事必躬亲
• 跟在屁股后面做监工
• 拿着锤子，看哪里都是钉子

解决方法：

• 与自己直接去做相比，想办法影响他人去把事情做好，要难得多。从三个层次：让人知道要做作，有动力去做，有能力去做
• 建立机制，始终依靠流程和规则来约束大家的行为
• 找到团队的痛点，最迫切要解决的是什么问题。把握好解决的时机。

项目管理的十大知识领域（每个项目都要从这几个领域去思考）

1. 干系人管理（直接干系人是谁，间接关系人是谁）
2. 范围管理（各方面的诉求是什么，要做到什么样子才能平衡好他们的诉求）
3. 进度管理（对项目进行阶段规划，任务拆解）
4. 成本管理（要投入多少成本）
5. 质量管理（要达到的交付标准）
6. 资源管理（有哪些可以利用的资源，可以帮助你完成这个项目）
7. 采购管理
8. 沟通管理（建立沟通机制）
9. 风险管理（可能存在的风险）
10. 整合管理（统筹全局）

总结起来就是：保目标，助决策，提效能，促协作

项目管理的五个过程组

1. 启动过程组
   项目启动，明确干系人，目标愿景，制定章程。项目启动会是非常有必要的。
2. 规划过程组
   把愿景目标转换成可执行的方案和工作路线。
3. 执行过程组
   这个环节最重要的是执行力。确保每个关键节点都能正常完成。
4. 监控过程组
   定期对项目质量、范围、进度进行监控，有偏差及时纠正。
5. 收尾过程组
   交付，归档，复盘，复盘，复盘。

识别项目中的四类干系人

对项目干系人进行分析和归类，了解他们对项目的期望和诉求，得到干系人的支持对项目的成功至关重要。
按照“权利-利益”分为干系人四象限：

高权力高利益干系人一般是项目的发起人，最终项目完成没完成，能不能完成是掌握在项目的最高权力者手中的，所以对于这类干系人需要重点管理。
要清楚他对这个项目最看重的是什么？

然后是了解其他干系人的诉求，使他们成为项目的拥护者。

规划-避免项目延期

做计划，是个集体对焦的过程。
总体分为4个步骤：

1. WBS工作分解，把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分。
2. 识别关键资源和关键依赖，进行资源统筹，明确依赖关系，制定项目里程碑。
3. 定义完成标准，对每一个阶段或者每一个模块完成的标准进行定义。
4. 及时同步，任何规划或者变动要及时公开，跟项目成员及时同步。保证大家对目标的理解一致。

总结起来就是：做规划的时候首先要按照资源依赖关系进行工作拆解，拆解成阶段性目标，制定每个阶段的详细工作内容和责任人，制定每个工作内容的完成标准，制定项目里程碑，并且把规划内容和项目整体情况及时跟团队成员进行同步。

执行-需要从一开始就闭环

在项目中可能会遇到这样的问题，项目开发执行到最后跟产品经理想要的结果不一样，导致重新返工。
解决这样的问题就需要从一开始就建立一种反馈机制来达到闭环的效果，在环节结束通过各方反馈来进行调节和矫正。
具体的方法有：

1. 方案评审（OARP）
   比如 需求稿，需求变更，设计稿，开发设计文档，测试用例
2. Bug Bash
   在项目开发里程碑的末期，专门划出一段时间让所有人都来找bug。
3. 冒烟用例评审

总结：方案评审是必须的，方案评审一方面可以找出方案中的漏洞，还可以使大家的信息保持同步。Bug Bash可以在里程碑末期由产品经理和测试人员配合进行。

监控-汇报

项目经理需要在项目中监控项目的状况并汇报，运用好汇报这个技能，可以成为项目经理有力的杠杆力量。
汇报的类型一般分为三种：

1. 紧急事件汇报：
   突发事件，跟规划，预期偏离较大，需要调整预期的紧急事件需要及时汇报。
   紧急事情汇报的格式为：
   1. 事件描述（发生了什么事）
   2. 影响后果（造成什么影响）
   3. 跟进分析（为什么会发生这个事）
   4. 响应措施（怎么解决）
   5. 需要支持（需要的帮助）
2. 常规向上汇报
   常规汇报的格式：
   1. 项目进度状态
   2. 存在的风险和问题
   3. 项目进展概况

附一张项目状况晴雨表：

3. 向下汇报
   把当前项目的进度向项目成员透明，可以让项目成员参与进来，有更多的责任感和目标感，项目进展越透明，对项目推进越有利。
   每周结束报告格式：
   1. 本周完成的工作内容
   2. 本周计划内要完成的里程碑及完成情况
   3. 已经延期的里程碑
   4. 下周计划完成的里程碑
   5. 整体进度总结

收尾-复盘

复盘是一个向过去学习的一个重要的项目过程。
做好复盘需要做好一前一后两件事情：
一前就是在复盘前需要先做好准备工作，定基调，明确目的。
一后就是在复盘后根据复盘结果进行改进，而不是为了复盘而复盘。

应对需求变更

把需求变更当成一种很正常的项目过程，不需要过分纠结。我们最终的目的是达成项目目标。那么在处理需求变更这个头疼的问题时可以使用一些方法去巧妙的应对。

1. 达成最小共识：需求变更是由成本的。找个合适的机会让大家都认可这个观点，这个时候需要提供一些数据进行支持。
2. 从源头治理，减少需求变更：
   2.1 Bug Bash，发动全体成员对需求进行检查提问，减少需求上面的漏洞。
   2.2 小黑屋+deadline，使用一些上线时间有严格要求的复杂项目，但是实施难度较大。
3. 快速试错：如果需求变更为不可抗力的话，要尽量减少试错成本，快速尝试，巧妙应对。

风险管理：

要有风险管理的意识

质量管理：

预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多。
从一开始就要注意质量，不论什么情况。程序员都知道从一开始就注意代码质量，成本一定是最低的。

高效会议：

https://blog.csdn.net/weixin_43513459/article/details/106329322

软技能篇-沟通：

向上沟通的三个误区：

1. 误区一：所有问题，都自己扛。
   不要所有问题都自己扛，保证项目落地是项目经理的工作核心。客观的描述和反馈问题也是项目经理的必修课。有重大影响的问题，千万不要自己去扛，应积极和上级商讨解决方案，也让上级有一个心理预期。
2. 误区二：只知道吐槽，不知道争取。
   找到吐槽问题的根源，做好“连接器”，该向领导争取的就向领导争取。
3. 误区三：抓不住重点，给不出方案。
   向上沟通的时候一定要抓住上层所关心的问题核心，并且要阐明这种问题的影响，并且提出一种可执行的方案。

向下沟通

非职权领导力的六力模型。“六力”分别是执行力、信息力、感知力、透明力、影响力和整合力。

1. 执行力：主动担责，有始有终。
2. 信息力：谁掌握着数据和信息，谁就拥有更强大的力量和权力
3. 感知力：对环境的观察和感知。
4. 透明力：想要改善就要透明，透明可以成为改变行为，解决问题的一个重要工具。
5. 影响力：学会倾听。放下自己主观的想法，了解别人真正的需求和意图。
6. 整合力：两个“凡是”：凡是能促进业务良性运作的，凡是能促进团队健康发展的，都是整合管理的范畴

进阶：PMP认证