雷蓓蓓项目管理课总结
2025-03-04 10:44:45 0 举报AI智能生成
《雷蓓蓓项目管理课总结》是一份精心整理的资料，核心内容涵盖了项目管理的基础知识、实用工具和方法论。这份总结不仅提炼了雷蓓蓓讲授课程的关键点，还结合了案例分析和实践经验，使得理论知识更加生动和易于理解。本文件为PDF格式，以其易于共享和打印的特点，方便专业人士学习和参考。其内容条理清晰、逻辑严谨，配合富有激情和专业的讲解风格，旨在帮助读者高效掌握项目管理的核心技能，提升职场竞争力。
作者其他创作
大纲/内容
项目管理
最精炼的总结：“使众人行”的协同能力：不断跨越我的职责边界，带领一群人，从头到尾把事做成。
目标
做好
谁
我
一群人
地点、做什么
做同一件事情
时间
项目周期内
项目经理12字箴言：保目标、助决策、提效能、促协作。
保目标：：把业务最顶层的战略意图，清晰地反应在每个人每一天的执行中，其实是件非常不容易的事情，需要一层层地进行拆解。首先，你要围绕组织绩效目标，定位出核心的 3～5 件要事，即关键战役，再把关键战役进行规划分解，拆到可交付可验收的里程碑，最后落地到版本 / 迭代的工作安排中。
助决策：要通过清晰而系统的反馈机制和平台，把执行中的进展状态、变更、风险等集中呈现，以帮助管理者更好地进行优化和调整，比如，结合产出进度来调整业务策略，通过里程碑状态信息来调整目标和规划的节奏，根据人力投入的分布，来优化整体的资源配置。这就是助决策的部分。
提效能：要去关注和消灭团队中的低价值工作所引发的效能痛点。举个例子，假如测试环境的部署耗时很长，这已经成为了整个团队的瓶颈，那你就要想办法通过技术的手段实现自动化，从而为整条链条提速。
促协作：是着眼于使用各种项目管理方法和工具，让高价值工作者，也就是一堆牛人放在一起，如何可以更好地合作。比如，建立清晰有效的信息渠道和沟通机制，积极推动各角色达成共识等，实现全局价值的最大化。
常见问题及对应的深层次项目问题
1“队友不给力”——如何调动干系人的积极性？
2“XXX 怎么到现在才开始”——如何对齐一群人的行动步调？
3“我早就说了要这样干，没人听我的”——遇到问题如何统一行动方案？
4“这……不是我想要的”——如何清晰我们共同的目标？
2“XXX 怎么到现在才开始”——如何对齐一群人的行动步调？
3“我早就说了要这样干，没人听我的”——遇到问题如何统一行动方案？
4“这……不是我想要的”——如何清晰我们共同的目标？
别人经验的总结
1、沟通！沟通！沟通！重要的事情说三遍，对业主、上级、下属建设不同的沟通渠道，不同的沟通方法及频次。
2、计划做的好，没啥用，也得做；风险控制很重要，提前暴露风险，做好风险应对策略。
3、脸皮要厚，敢说也得敢干，不要怕说错，敢于试错。
4、让自己成为业务专家才有更多话语权，领导力来源于岗位，能让人尊重的更多是专业技能。
5、习惯复盘，对制定的项目计划出现偏差及时修正。
2、计划做的好，没啥用，也得做；风险控制很重要，提前暴露风险，做好风险应对策略。
3、脸皮要厚，敢说也得敢干，不要怕说错，敢于试错。
4、让自己成为业务专家才有更多话语权，领导力来源于岗位，能让人尊重的更多是专业技能。
5、习惯复盘，对制定的项目计划出现偏差及时修正。
1、项目管理最大的能力就是要会整合资源，将合适的团队的成员用于合适的位置；
2、其次就是项目进度的把控 一定要掌握，并根据项目进度和状况，分清目前影响进度主次原因，并根据原因想对应的策略；
3、再次是沟通，与客户沟通与团队沟通和上级沟通都是不一样。
2、其次就是项目进度的把控 一定要掌握，并根据项目进度和状况，分清目前影响进度主次原因，并根据原因想对应的策略；
3、再次是沟通，与客户沟通与团队沟通和上级沟通都是不一样。
所有导致项目失败的问题，冰山下都有同一个源头，那就是“失焦” （关注力不在同一个点上）。这包含以下四个方面。
1、目标的失焦：发起人的预期模糊，目标不清晰，产出无法衡量。
2、人力的失焦：项目团队及干系人，各自有各自的诉求，形不成合力。
3、计划的失焦：团队成员不知道什么时候该干什么，互相依赖冲突。
4、行动的失焦：遇到问题时，你说要这样，他说得那样，没有统一落地的解决方案。
1、目标的失焦：发起人的预期模糊，目标不清晰，产出无法衡量。
2、人力的失焦：项目团队及干系人，各自有各自的诉求，形不成合力。
3、计划的失焦：团队成员不知道什么时候该干什么，互相依赖冲突。
4、行动的失焦：遇到问题时，你说要这样，他说得那样，没有统一落地的解决方案。
项目经理和产品经理的区别：前者是正确的做事，后者是做正确的事
项目管理的几大误区
凡事都要亲力亲为
转变为：给别人授权工作时，成功施加影响的三个层次
让人知道要做（Awareness）
有动力做（Desire）
有能力做（Ability）
追着别人做监工
转变为：要明确目标，建立机制，并让这个机制运转起来，最终在项目组形成一种良性的秩序
要始终依靠流程和规则来约束大家的行为，而不是当监工
要始终依靠流程和规则来约束大家的行为，而不是当监工
项目经理要带大家一起开启动会，清晰愿景目标，定义阶段里程碑和完成标准，接着制定分段执行的计划，把事情的所有环节从头到尾捋顺了；项目经理要建立上下游协同的流程规则，明确各个角色在整个过程中的职责，获得大家的认同和共识；项目经理还要建立站会、周会等制度和模版，让进展和风险通过这些良好设计的信息渠道汇聚，借助规则和工具来达到监控的目的。
拿着锤子看哪里都是钉子
转变为：每个项目的现有执行方式，都有它本身的背景和成因，你要与项目中的重要干系人加强沟通，理解前因后果，从项目和团队当前的真实痛点出发，找到真正解决问题的方法和步骤。
不能只懂技术
撇开技术不说，项目经理是一个管理者，而不是一个纯粹的技术者。
不能苛求技术细节
项目经理应该把目标放在项目本身的实施上，而不是过多地扎在技术的细节上作文章。
不能以个人能力代替团队思考
与其过分依靠个人能力， 不如激活团队的潜能， 让每个成员都能发挥他们的最大能力， 这样对项目的帮助会更大。
不能沟通不畅
不能让它变成拖延时间的罪魁祸首
优秀的项目经理，90%的时间都是花在沟通上
项目管理的五大过程组和十大知识领域
五大过程组和十大知识领域
进度、成本、质量、范围是 4 个核心领域，风险、沟通、采购、资源、干系人管理是 5 个辅助领域和 1 个整体领域
举例说明，任何项目无论大小，都可以拆解成十大知识领域
十大知识领域
子主题
五大过程组
PDCA
五大过程组
启动过程组（千里之行，始于足下）
正式宣告一个新项目或新阶段的开始，公开确认项目章程，包括明晰各方干系人的期望和诉求，设定愿景目标和重要里程碑，确定责任分工和沟通机制等。
规划过程组（运筹帷幄，决胜千里）
规划就是要把愿景目标转化为可落地的行动方案和工作路线
定计划
排期
资源
定方案
需求方案
技术方案
测试用例
风险预案
执行过程组（言出必行，行之必果）
监控过程组（审时度势，沉着应变）
收尾过程组（慎终如始，则无败事）
不管项目成功与否，“趁热”复盘都是极为重要的一步。
互联网项目
硬技能
启动过程组：做好识别干系人
干系人分析，是对项目干系人进行分析和归类，有针对性地规划管理其核心诉求和期望，让干系人可以更好地参与项目，对项目产生积极影响，从而保障项目目标的成功达成。毛主席说过：“要把拥护我们的人搞得多多的，把反对我们的人搞得少少的。”干革命如此，做项目也是同样！
干系人权利利益方格（矩阵）
“高利益 - 高权力”代表：项目发起人；
“低利益 - 高权力”代表：职能经理；
“高利益 - 低权力”代表：项目组成员；
“低利益 - 低权力”代表：外围支持人员。
“低利益 - 高权力”代表：职能经理；
“高利益 - 低权力”代表：项目组成员；
“低利益 - 低权力”代表：外围支持人员。
举例：项目管理就是去西天取经，途中会遇到各种想吃唐僧肉的人，于是干系人都成了你的资源，随时随地都能用，比如孙悟空一会儿请观音菩萨，一会上天请太上老君，总会有一款神仙，可以制服想吃唐僧肉的妖怪。干系人分析就是要对这些神仙好好管理，每个神仙有什么核心诉求，要非常清楚，管理好预期。
规划过程组：扫除五大延期地雷，规划是用来对焦的
计划是贯穿始终的重要课题，是各个角色协同工作的基准。
计划是用来对焦的！做计划，是个集体对焦的过程。
做计划的五大雷区
不够具体
工具：WBS工作任务分解
不够全面
识别依赖并画出关键路径，就是我要讲的做计划的第二个标准动作，这一步意味着我们开始从目标的角度对资源进行统筹思考。
关键里程碑节点图
节点图表示
不够准确
方法：事先定于完成标准
以最关键的几个常见时间节点为例，完成标准如下：
1、需求 / 设计确认：执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。值得一提的是，有些团队还会对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。
2、功能完成 / 提测：所有定义的功能都已经完成（比如冒烟测试通过率高于 90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪。一些质量基础比较好的团队，也可以把冒烟测试通过率，CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准。
3、里程碑完成：质量已经达到适当水平（如不存在 P0 及 P1 优先级的 Bug），可以上线发布，或者可以开始下一个里程碑。
1、需求 / 设计确认：执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。值得一提的是，有些团队还会对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。
2、功能完成 / 提测：所有定义的功能都已经完成（比如冒烟测试通过率高于 90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪。一些质量基础比较好的团队，也可以把冒烟测试通过率，CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准。
3、里程碑完成：质量已经达到适当水平（如不存在 P0 及 P1 优先级的 Bug），可以上线发布，或者可以开始下一个里程碑。
没有共识
做计划本身并不是最难的，真正难的是什么？对焦！没有达成共识的计划，是不具备任何效力的。
做完计划，要及时向团队成员、相关干系人公布，至少要通过邮件的方式让相关干系人了解到项目计划，小项目也要如此
不够及时
重要的是，每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。
计划永远是个反复修正、渐进明晰的过程，我们要对计划进行持续地跟进与调整
做计划的 5 个标准动作
WBS 工作分解
识别依赖及各环节关键路径
定义完成标准
达成共识并公开透明
变更即时调整
执行过程组：三种执行验证过程，保证执行不走样
在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制，减少返工、降低偏差
方案评审（OARP 决策机制）
需求评审
技术方案评审
用例评审
风险方案评审
Bug Bash（大扫除活动）
测试基本完成后
产品方案、原型设计完成后
冒烟用例评审（其实：在执行过程中，用例评审已经包含了冒烟用例评审）
冒烟通过率：作为研发进入测试的前提
监控过程组：监控：“巧”用数据说话，让汇报告别流水账
紧急汇报直面问题，常规周报简明扼要，数据透明直观清晰！
紧急汇报：直面问题有章法
事件描述
影响后果
跟进分析
响应措施
所需支持
常规汇报：项目周报要回答的三个问题
项目的整体进展状态到底如何？
风险可控吗？
目标达成有没有问题？
数据汇报：善用“透明”的力量
在项目汇报和日常跟进中，能够用图表和数据的，我就不会用文字。作为项目管理人员，你手中不见得有多少权力，但有一种强大的力量，你一定可以无限获取，那就是“透明”。
想要改善什么，你就去透明什么，越直观越好！
收尾：持续改进，从真正有效的复盘开始
复盘会前基调的设定和充足准备，会后改进措施的落地，才是最重要
会议的开始，定下基调：在会议刚开场，就要展示出自己的开放与坦诚，给复盘会奠定基调：这次复盘不是来挑问题的，而是为了找到问题的根源并改进的。
会议前的准备
包括项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等
团队满意度调查
每次迭代的视频、照片等
会议的形式和简易流程
复盘会的流程，其实并不复杂。在实战中，我总结出了一套最为高效的复盘流程。
1、现场回顾总结项目 / 里程碑的整体概况，包括目标达成情况、进度计划及变更情况、需求变更情况、质量报告等项目历程记录。
2、与会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点，按照项目的各个环节分类，分别贴在白板上，确保大家的意见能够充分、自由地表达。
3、在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论。
4、对大家总结出的好和不好的点，进行集体投票。
5、由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案。
1、现场回顾总结项目 / 里程碑的整体概况，包括目标达成情况、进度计划及变更情况、需求变更情况、质量报告等项目历程记录。
2、与会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点，按照项目的各个环节分类，分别贴在白板上，确保大家的意见能够充分、自由地表达。
3、在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论。
4、对大家总结出的好和不好的点，进行集体投票。
5、由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案。
流程
投票结果
会后的落地
改进措施一定要落地，重点行动不要太多，一个就够了
复盘的次数不宜太多，你并不需要每个版本、每个迭代都例行公事地去做一遍，确保每个季度有一到两次里程碑复盘，可以完整地对项目做系统化的梳理，达到真正的落地效果，才是更重要的。
打造团队持续改进能力
实际上，想要让团队进入自发改进的正向循环，你需要更好地激发团队的主人翁意识，让团队成为复盘的主角，而不是你。最重要的是，你不仅要关注事，还要关注人。
复盘的方法
1、3 点法：使用最多也是最常见的一种复盘方式，文中已经有详细流程步骤。
2、奏章法：文中提到的“坑爹功能大搜罗”“研发代表大会”都是用的这个方法，可以用来集结群智，每人发一张白纸，写上几条意见，然后依次传给左边的同学批阅，同意就 +1，也可以在上面盖楼写评论。
3、状态图法：当团队士气遇到挫折时，凝聚士气的一个方法。每人发一张白纸，在上面画出自己进项目组以来的心情曲线，轮流公开呈现，并讲出自己的波峰和波谷事件及感受。具体操作起来，让 Leader 先讲，创造坦诚氛围，大家自然就踊跃了。
2、奏章法：文中提到的“坑爹功能大搜罗”“研发代表大会”都是用的这个方法，可以用来集结群智，每人发一张白纸，写上几条意见，然后依次传给左边的同学批阅，同意就 +1，也可以在上面盖楼写评论。
3、状态图法：当团队士气遇到挫折时，凝聚士气的一个方法。每人发一张白纸，在上面画出自己进项目组以来的心情曲线，轮流公开呈现，并讲出自己的波峰和波谷事件及感受。具体操作起来，让 Leader 先讲，创造坦诚氛围，大家自然就踊跃了。
需求变更：三个锦囊，让需求变更不再是洪水猛兽
变更流程
锦囊 1：达成最小共识：变更是有代价的
好方法1：复盘会上的团队成员匿名纸条，点出需求变更对于各端的影响，产品经理自会反省和收敛
锦囊 2：源头治理，一次把事情做对
产品需求的deadline和bug bash
产品们的小黑屋集中设计和评审
团队成员的提前bug bash
锦囊 3：快试错，不可抗力巧应对
方法1：版本迭代，多次长期合作解决需求变更
方法2：快速试错，快速上线
0 条评论
下一页
