首页  思维导图  详情

项目管理学习笔记

2022-05-26 19:43:54   0  举报





AI智能生成

为你推荐

查看更多



项目管理学习笔记

软件

项目

管理

作者其他创作

大纲/内容

走个人能力线

领域专家

借助团队能力

管理者

在多人协作团队里

项目经理

职业精进方向.png

职业精进方向

项目管理是在不确定性、多变的环境下，追求确定的项目产出。只有通过在目标、人力、计划、行动四个维度上，不断对焦和清晰，才能真正带领项目走向成功

本质思维：对焦

目标的失焦：发起人的预期模糊，目标不清晰，产出无法衡量。

人力的失焦：项目团队及干系人，各自有各自的诉求，形不成合力。

计划的失焦：团队成员不知道什么时候该干什么，互相依赖冲突。

行动的失焦：遇到问题时，你说要这样，他说得那样，没有统一落地的解决方案。

项目失败原因：失焦

项目管理思维

授权工作时，需成功施加影响，成功施加影响包含三个层次：从让人知道要做（Awareness）、到有动力做（Desire），再到有能力做（Ability）

恨不得事必躬亲

要明确目标，建立机制，并让这个机制运转起来，最终在项目组形成一种良性的秩序，要始终依靠流程和规则来约束大家的行为，真正做到变“赶”为“引”

追在别人屁股后面做监工

每个项目的现有执行方式，都有它本身的背景和成因，要与项目中的重要干系人加强沟通，理解前因后果，从项目和团队当前的真实痛点出发，找到真正解决问题的方法和步骤。

拿着锤子，看哪里都是钉子（问题）

项目管理的三大误区

项目管理就是指把各种系统、方法和人员结合在一起，在规定的时间、预算和质量目标范围内，完成项目的各项工作，对组织资源进行计划、引导和控制，本质上是变理想为现实，化抽象为具体的一门科学和艺术

什么是项目管理

欧洲的国际项目管理协会

IPMA

美国项目管理协会

PMI（普及最高）

英国

PRINCE2

项目标准体系

围绕组织绩效目标，定位出核心的 3～5 件要事，即关键战役，再把关键战役进行规划分解，拆到可交付可验收的里程碑，最后落地到版本 / 迭代的工作安排中

保目标

通过清晰而系统的反馈机制和平台，把执行中的进展状态、变更、风险等集中呈现，以帮助管理者更好地进行优化和调整

助决策

关注和消灭团队中的低价值工作所引发的效能痛点。

提效能

着眼于使用各种项目管理方法和工具，让高价值工作者，也就是一堆牛人放在一起，如何可以更好地合作

促协作

项目管理职责

进度管理

成本管理

质量管理

范围管理

核心领域

风险管理

沟通管理

采购管理

相关方分类与管理

如果进行相关方管理？

对工作进行WBS分解，创建 WBS 的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程

将工作项拆解到 3 个工作日以内，每项任务都对应到个人

具体

识别依赖并画出关键路径

为各个阶段设定合理的里程碑节点

全面

执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。也可对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。

需求 / 设计确认

所有定义的功能都已经完成（比如冒烟测试通过率高于 90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪。一些质量基础比较好的团队，也可以把冒烟测试通过率，CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准

功能完成 / 提测

质量已经达到适当水平（如不存在 P0 及 P1 优先级的 Bug），可以上线发布，或者可以开始下一个里程碑

里程碑完成

尽早定义完成标准

准确

召开全员规划会，对齐信息，达成共识，发邮件给相关方，正式告知

共识

与进度计划有关的任何变更，都需要提交给项目管理人员，最好由团队中对应功能小组的成员（该功能模块涉及的策划、设计、开发、测试）及其他相关干系方共同讨论，明确计划变动可能对各方造成的影响，最终做出决策，并公开告知所有项目组成员

变更即时调整，并公开告知所有项目组成员

即时

项目计划需具备的特点.png

项目计划应具备的特征

如果制定项目进度计划？

OARP方案评审流程.jpg

OARP流程

项目中常见文档OARP 角色.png

项目中常见文档OARP 角色

方案评审（OARP 决策机制）

Bug Bash，也叫 Bug 大扫除，最初来自微软，是指在项目开发里程碑的末期（比如 Beta 版发布前），划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找 Bug，目的是从各个维度衡量和体验产品

定义

测试类的 Bug Bash，你可以选择在全面功能测试结束后，Bug 趋于收敛的时间段开展；需求设计类的 Bug Bash，一般会放在需求或设计稿完成后举行。这个活动需要一到两个小时的时间，你一定要提前排除所有干扰

时间

需要设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力做这一件事。同时，作战室可以提供一些零食和饮料，让活动更有氛围

地点

除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群，都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角

参与者

你可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新 Bug 或建议的排名情况。需要注意的是，营造互动的氛围非常关键，如果因为空间受限，参与者做不到在同一地点进行，你至少也要在通信群中实时更新排名情况的变化

现场安排

在活动结束后，要直接公示 Bug 或建议数，现场给奖品，并发邮件通报全组。最后，在对 Bug 进行去重后，还要分类定级，确定哪些是必须修，哪些是改了会更好。另外，千万不要忘记公示结果，明确修复计划

活动结束

组织方式

Bug Bash（Bug 大扫除）

在进入开发环节后，你需要安排专门的测试用例评审，让开发和测试对标准冒烟用例集达成约定，这个约定就会成为进入测试的准入标准

正常冒烟通过率为100%，视团队差异至少应>80%

冒烟用例评审

如何进行执行阶段闭环验证？

购物车改造功能高延期风险

事件描述

由于此功能在项目的关键路径上，很有可能会造成项目整体延期两周；

影响后果

本期购物车改造功能，有部分调整涉及到底层订单系统，里面有大量遗留代码，已经很久没有人维护了。之前对此风险的评估不够充分，改动风险很高，可能会影响全站订单系统的稳定性，具体影响仍需要详细分析；

跟进分析

主程全力以赴做好技术评估，本周内给出详细任务评估时间表；与此同时，产品人员介入，调研规避老系统又能满足需求的可行性，本周内给出调研结论；

响应措施

熟悉老系统的资深技术人员，以及红牛一箱。

所需支持

紧急汇报：坦诚，直面问题有章法，包含5 个基本元素

好的周报，应该让大家对我们刚刚提到的项目现状的三个问题形成统一、清晰的整体认知。这份整体认知，可以让平时扎在细节工作中的人，从全局视角来了解和看待整体，从而更好地完成自己的工作

忌事无巨细，只写要点就够了

一份周报的阅读时间不应超过 5 分钟

注意事项

项目周报模板.png

周报模板

项目周报模块图.png

项目周报

想要改善什么，你就去透明什么，越直观越好

数据汇报

如何巧用数据进行项目监控和汇报？

复盘不是来挑问题的，而是为了找到问题的根源并改进的

明确复盘基调

复盘会流程.jpg

流程

与会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点，按照项目的各个环节分类，分别贴在白板上

在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论

对大家总结出的好和不好的点，进行集体投票

由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案

三点法复盘投票结果.png

3 点法

奏章法

当团队士气遇到挫折时，凝聚士气的一个方法。每人发一张白纸，在上面画出自己进项目组以来的心情曲线，轮流公开呈现，并讲出自己的波峰和波谷事件及感受。具体操作起来，让 Leader 先讲，创造坦诚氛围，大家自然就踊跃了

状态图法

复盘方法

改进措施一定要落地，重点行动不要太多，一个就够了

复盘的次数也不宜太多，确保每个季度有一到两次里程碑复盘，可以完整地对项目做系统化的梳理，达到真正的落地效果，才是更重要的。

复盘会流程

每次复盘后聚焦一个改进点。再提醒你一句：聚焦点别太多，一个就够了

让团队进入自发改进的正向循环，激发团队的主人翁意识，让团队成为复盘的主角，而不是你。最重要的是，你不仅要关注事，还要关注人

持续改进

如何组织项目复盘会？

需求变更流程.jpg

需求变更流程

以疏治堵，源头治理，顺势而为，闭环优化，数据说话

核心思想

所有需求及所有变更必须建单，无单需求开发有权不接

需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员

对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道

找到合适的时机，树立对变更的最小共识

需求变更成本表.png

需求变更成本表

达成最小共识：变更是有代价的

从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式

一些上线时间有严格要求的复杂项目上，小黑屋 + Deadline 的实践效果奇佳

源头治理，一次把事情做对

要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求

就快速尝试，小范围灰度发布，用对比数据说话

快试错，不可抗力巧应对

流程控制方法

如何控制需求变更？

对于发生概率很高的严重风险，一定要提前准备风险应对方案和危机应急预案

每周的项目状态同步会议上，对风险进行再评估，并通过周期性的风险审查，来识别新的风险

事后不如事中控制，事中不如事前控制

要致力于持续改善人与人之间的互动品质，提升项目团队的健康度

对这个版本研发过程的综合评分（包括迭代方式、工作量、工作压力、团队配合、时间管理等各个方面），这反映了过程满意度

对这个版本功能设计的满意度，即产品认可度

做匿名的问卷收集或访谈

治未病，建立系统性保健机制

挖掘出这些致命风险，把它们变为可见的、可谈的。

正视风险，不存侥幸心理。你要和发起人一起想办法，发动核心团队，合力去制定应对策略。

在项目核心团队中，周期性地梳理和同步风险状态

积极管理致命风险

树立正确的风险观

风险登记表.png

制定风险等级表

如何进行风险管理？

质量标准定义.png

质量标准定义

各阶段质量保障手段.png

各个阶段的质量保障手段

质量规划，明确项目的质量标准；

可以召集产品、研发、测试，一起对过去一个月的线上问题，进行深入的根因分析，制定策略并推进落实

每月坚持开线上 Bug 分析会

从不同维度分析 Bug 原因，你可以按照具体引入阶段给 Bug 分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发、覆盖升级、历史遗留等，也可以按照 Bug 类别分为功能问题、性能问题、界面问题、兼容性问题等。从数据统计上，你就可以准确地知道，自己项目的质量问题主要出在哪个环节，下一步是要先规范代码准入标准，还是加强需求评审，以及哪些保障措施会更有效

持续进行内部 Bug 分类

对齐千行代码 Bug 率、Bug 数 / 需求数的比率、Reopen Bug 率等，对低于平均线下的业务线或模块进行有针对性的原因分析

建立质量大盘，拉通不同业务线或模块的每月 Bug 趋势

质量分析，追根溯源，找到质量差距的根本症结

质量活动概览图.png

质量控制，在需求到发布过程中，设置层层卡点来控制质量。

如何进行质量管理？

Project

Visio

WBS 及甘特图

里程碑规划

Tower