项目管理学习笔记
2022-05-26 19:43:54 0 举报AI智能生成
项目管理学习笔记
作者其他创作
大纲/内容
职业精进方向
领域专家
走个人能力线
管理者
借助团队能力
项目经理
在多人协作团队里
项目管理思维
本质思维：对焦
项目管理是在不确定性、多变的环境下，追求确定的项目产出。只有通过在目标、人力、计划、行动四个维度上，不断对焦和清晰，才能真正带领项目走向成功
项目失败原因：失焦
目标的失焦：发起人的预期模糊，目标不清晰，产出无法衡量。
人力的失焦：项目团队及干系人，各自有各自的诉求，形不成合力。
计划的失焦：团队成员不知道什么时候该干什么，互相依赖冲突。
行动的失焦：遇到问题时，你说要这样，他说得那样，没有统一落地的解决方案。
项目管理的三大误区
恨不得事必躬亲
授权工作时，需成功施加影响，成功施加影响包含三个层次：从让人知道要做（Awareness）、到有动力做（Desire），再到有能力做（Ability）
追在别人屁股后面做监工
要明确目标，建立机制，并让这个机制运转起来，最终在项目组形成一种良性的秩序，要始终依靠流程和规则来约束大家的行为，真正做到变“赶”为“引”
拿着锤子，看哪里都是钉子（问题）
每个项目的现有执行方式，都有它本身的背景和成因，要与项目中的重要干系人加强沟通，理解前因后果，从项目和团队当前的真实痛点出发，找到真正解决问题的方法和步骤。
项目管理常识
什么是项目管理
项目管理就是指把各种系统、方法和人员结合在一起，在规定的时间、预算和质量目标范围内，完成项目的各项工作，对组织资源进行计划、引导和控制，本质上是变理想为现实，化抽象为具体的一门科学和艺术
项目标准体系
IPMA
欧洲的国际项目管理协会
PMI（普及最高）
美国项目管理协会
PRINCE2
英国
项目管理职责
保目标
围绕组织绩效目标，定位出核心的 3～5 件要事，即关键战役，再把关键战役进行规划分解，拆到可交付可验收的里程碑，最后落地到版本 / 迭代的工作安排中
助决策
通过清晰而系统的反馈机制和平台，把执行中的进展状态、变更、风险等集中呈现，以帮助管理者更好地进行优化和调整
提效能
关注和消灭团队中的低价值工作所引发的效能痛点。
促协作
着眼于使用各种项目管理方法和工具，让高价值工作者，也就是一堆牛人放在一起，如何可以更好地合作
项目管理十大知识领域
概述
核心领域
进度管理
成本管理
质量管理
范围管理
辅助领域
风险管理
沟通管理
采购管理
相关方管理
资源管理
整体领域
整合管理
各领域工作定义
各领域事项说明
项目管理五大过程组
启动：千里之行，始于足下
规划：运筹帷幄，决胜千里
执行：言出必行，行之必果
监控：审时度势，沉着应变
收尾：慎终如始，则无败事
项目实战技能
如果进行相关方管理？
相关方分类与管理
“高利益 - 高权力”代表：项目发起人
“低利益 - 高权力”代表：职能经理
“高利益 - 低权力”代表：项目组成员
“低利益 - 低权力”代表：外围支持人员
如果制定项目进度计划？
项目计划应具备的特征
具体
对工作进行WBS分解，创建 WBS 的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程
将工作项拆解到 3 个工作日以内，每项任务都对应到个人
全面
识别依赖并画出关键路径
为各个阶段设定合理的里程碑节点
准确
尽早定义完成标准
需求 / 设计确认
执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。也可对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。
功能完成 / 提测
所有定义的功能都已经完成（比如冒烟测试通过率高于 90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪。一些质量基础比较好的团队，也可以把冒烟测试通过率，CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准
里程碑完成
质量已经达到适当水平（如不存在 P0 及 P1 优先级的 Bug），可以上线发布，或者可以开始下一个里程碑
共识
召开全员规划会，对齐信息，达成共识，发邮件给相关方，正式告知
即时
变更即时调整，并公开告知所有项目组成员
与进度计划有关的任何变更，都需要提交给项目管理人员，最好由团队中对应功能小组的成员（该功能模块涉及的策划、设计、开发、测试）及其他相关干系方共同讨论，明确计划变动可能对各方造成的影响，最终做出决策，并公开告知所有项目组成员
如何进行执行阶段闭环验证？
方案评审（OARP 决策机制）
OARP流程
项目中常见文档OARP 角色
Bug Bash（Bug 大扫除）
定义
Bug Bash，也叫 Bug 大扫除，最初来自微软，是指在项目开发里程碑的末期（比如 Beta 版发布前），划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找 Bug，目的是从各个维度衡量和体验产品
组织方式
时间
测试类的 Bug Bash，你可以选择在全面功能测试结束后，Bug 趋于收敛的时间段开展；需求设计类的 Bug Bash，一般会放在需求或设计稿完成后举行。这个活动需要一到两个小时的时间，你一定要提前排除所有干扰
地点
需要设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力做这一件事。同时，作战室可以提供一些零食和饮料，让活动更有氛围
参与者
除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群，都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角
现场安排
你可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新 Bug 或建议的排名情况。需要注意的是，营造互动的氛围非常关键，如果因为空间受限，参与者做不到在同一地点进行，你至少也要在通信群中实时更新排名情况的变化
活动结束
在活动结束后，要直接公示 Bug 或建议数，现场给奖品，并发邮件通报全组。最后，在对 Bug 进行去重后，还要分类定级，确定哪些是必须修，哪些是改了会更好。另外，千万不要忘记公示结果，明确修复计划
冒烟用例评审
在进入开发环节后，你需要安排专门的测试用例评审，让开发和测试对标准冒烟用例集达成约定，这个约定就会成为进入测试的准入标准
正常冒烟通过率为100%，视团队差异至少应>80%
如何巧用数据进行项目监控和汇报？
紧急汇报：坦诚，直面问题有章法，包含5 个基本元素
事件描述
购物车改造功能高延期风险
影响后果
由于此功能在项目的关键路径上，很有可能会造成项目整体延期两周；
跟进分析
本期购物车改造功能，有部分调整涉及到底层订单系统，里面有大量遗留代码，已经很久没有人维护了。之前对此风险的评估不够充分，改动风险很高，可能会影响全站订单系统的稳定性，具体影响仍需要详细分析；
响应措施
主程全力以赴做好技术评估，本周内给出详细任务评估时间表；与此同时，产品人员介入，调研规避老系统又能满足需求的可行性，本周内给出调研结论；
所需支持
熟悉老系统的资深技术人员，以及红牛一箱。
项目周报
注意事项
好的周报，应该让大家对我们刚刚提到的项目现状的三个问题形成统一、清晰的整体认知。这份整体认知，可以让平时扎在细节工作中的人，从全局视角来了解和看待整体，从而更好地完成自己的工作
忌事无巨细，只写要点就够了
一份周报的阅读时间不应超过 5 分钟
周报模板
数据汇报
想要改善什么，你就去透明什么，越直观越好
如何组织项目复盘会？
明确复盘基调
复盘不是来挑问题的，而是为了找到问题的根源并改进的
复盘会流程
流程
复盘方法
3 点法
与会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点，按照项目的各个环节分类，分别贴在白板上
在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论
对大家总结出的好和不好的点，进行集体投票
由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案
奏章法
“坑爹功能大搜罗”“研发代表大会”,可以用来集结群智，每人发一张白纸，写上几条意见，然后依次传给左边的同学批阅，同意就 +1，也可以在上面盖楼写评论
状态图法
当团队士气遇到挫折时，凝聚士气的一个方法。每人发一张白纸，在上面画出自己进项目组以来的心情曲线，轮流公开呈现，并讲出自己的波峰和波谷事件及感受。具体操作起来，让 Leader 先讲，创造坦诚氛围，大家自然就踊跃了
注意事项
改进措施一定要落地，重点行动不要太多，一个就够了
复盘的次数也不宜太多，确保每个季度有一到两次里程碑复盘，可以完整地对项目做系统化的梳理，达到真正的落地效果，才是更重要的。
持续改进
每次复盘后聚焦一个改进点。再提醒你一句：聚焦点别太多，一个就够了
让团队进入自发改进的正向循环，激发团队的主人翁意识，让团队成为复盘的主角，而不是你。最重要的是，你不仅要关注事，还要关注人
如何控制需求变更？
需求变更流程
核心思想
以疏治堵，源头治理，顺势而为，闭环优化，数据说话
流程控制方法
达成最小共识：变更是有代价的
找到合适的时机，树立对变更的最小共识
所有需求及所有变更必须建单，无单需求开发有权不接
需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员
对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道
需求变更成本表
源头治理，一次把事情做对
从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式
一些上线时间有严格要求的复杂项目上，小黑屋 + Deadline 的实践效果奇佳
快试错，不可抗力巧应对
要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求
就快速尝试，小范围灰度发布，用对比数据说话
如何进行风险管理？
对于发生概率很高的严重风险，一定要提前准备风险应对方案和危机应急预案
每周的项目状态同步会议上，对风险进行再评估，并通过周期性的风险审查，来识别新的风险
树立正确的风险观
治未病，建立系统性保健机制
事后不如事中控制，事中不如事前控制
要致力于持续改善人与人之间的互动品质，提升项目团队的健康度
做匿名的问卷收集或访谈
对这个版本研发过程的综合评分（包括迭代方式、工作量、工作压力、团队配合、时间管理等各个方面），这反映了过程满意度
对这个版本功能设计的满意度，即产品认可度
积极管理致命风险
挖掘出这些致命风险，把它们变为可见的、可谈的。
正视风险，不存侥幸心理。你要和发起人一起想办法，发动核心团队，合力去制定应对策略。
在项目核心团队中，周期性地梳理和同步风险状态
制定风险等级表
如何进行质量管理？
质量规划，明确项目的质量标准；
质量标准定义
各个阶段的质量保障手段
质量分析，追根溯源，找到质量差距的根本症结
每月坚持开线上 Bug 分析会
可以召集产品、研发、测试，一起对过去一个月的线上问题，进行深入的根因分析，制定策略并推进落实
持续进行内部 Bug 分类
从不同维度分析 Bug 原因，你可以按照具体引入阶段给 Bug 分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发、覆盖升级、历史遗留等，也可以按照 Bug 类别分为功能问题、性能问题、界面问题、兼容性问题等。从数据统计上，你就可以准确地知道，自己项目的质量问题主要出在哪个环节，下一步是要先规范代码准入标准，还是加强需求评审，以及哪些保障措施会更有效
建立质量大盘，拉通不同业务线或模块的每月 Bug 趋势
对齐千行代码 Bug 率、Bug 数 / 需求数的比率、Reopen Bug 率等，对低于平均线下的业务线或模块进行有针对性的原因分析
质量控制，在需求到发布过程中，设置层层卡点来控制质量。
实用项目管理工具
WBS 及甘特图
Project
Visio
里程碑规划
Visio
在线多人协同
Tower
禅道
一页纸项目管理
0 条评论
下一页
