项目管理学习笔记

01 程序员  程序员做项目管理的三大误区

误区1:凡事恨不得事必躬亲

想办法影响他人去把事情做好,

影响他人去做好一件事呢?在不断地反思之后,我总结出了成功施加影响的三个层次,分别是让人

知道要做(Awareness)、有动力做(Desire)和有能力做(Ability)

单方面的工作交待和告知,停留在浅层次的信息传达上,只是让人知道要做,但并不足以让人产生动力,去促成有效的行动。

如果现阶段的团队都没有对应的能力,该怎么办呢?项目成功关键路径上的核心能力缺失,是你作为项目管理人员,要当作最高优先级的风险管理的事项。

误区2:追在别人屁股后面做监工

项目经理最该做的,不是每天逐个人逐条事项的监督,而是要明确目标,建立机制,并让这个机制运转起来,最终在项目组形成一种良性的秩序。要始终依靠流程和规则来约束大家的行为。

误区3:拿着锤子,看哪里都是钉子

要与项目中的重要干系人加强沟通,理解前因后果,从项目和团队当前的真实痛点出发,找到真正解决问题的方法和步骤。

02 | 十大领域五大过程组(上)：程序员必须要了解的项目管理常识

“项目管理就是变理想为现实,化抽象为具体的一门科学和艺术。"
保目标,助决策，提效能,促协作。

03 | 十大领域五大过程组(下)：程序员必须要了解的项目管理常识

项目管理的五大过程组

1.启动过程组(干里之行,始于足下)

启动过程组意味着正式开始一个项目,或者是开始一个项目中的新阶段,包括识别干系人和制定项目章程两个子过程。

正式宣告一个新项目或新阶段的开始,公开确认项目章程,包括明晰各方干系人的期望和诉求,设定愿景目标和重要里程碑,确定责任分工和沟通机制等。

2.规划过程组(运筹帷幄,决胜干里)

规划就是要把愿景目标转化为可落地的行动方案和工作路线。

3.执行过程组(言出必行,行之必果)

4.监控过程组(审时度势,沉着应变)

需要定期对项目的进展、范围、质量等进行跟踪和监控,识别目前的进度与计划之间的偏差,从而快速准确地采取办法进行纠正和调整。

5.收尾过程组(慎终如始,则无败事)

不管项目成功与否,“趁热”复盘都是极为重要的一步。

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

促协作则是着眼于使用各种项目管理方法和工具,让高价值工作者可以更好地合作。

04 | 启动：识别项目中的四类干系人

“高利益 - 高权力”代表：项目发起人

为了管理好之后的沟通，你还需要约定好你们之间的沟通频率和方式，以便在项目进 行的过程中做好实时同步。

“低利益 - 高权力”代表：职能经理

强烈的态度背后，一定反映了干系人对现状的某种认知, 只有真正地理解了对方的逻辑，才有可能进一步对其施加影响。

“高利益 - 低权力”代表：项目组成员

要做到项目事项的随时告知，及时通报项目的进展和困难。

“低利益 - 低权力”代表：外围支持人员

可以跟他们提前约定好，每天或者每周进展汇报的格式和内容，确保他们的工作职责和任务明确，进展符合预期就可以了。

05 | 规划：排除计划中的“延期地雷”

在项目管理中，计划是贯穿始终的重要课题，是各个角色协同工作的基准。

要利用一切可以利用的资源、尽自己最大的努力达成项目目标，而计划是你可以借助的重要工具。

从本质上来讲，计划是用来对焦的！做计划，是个集体对焦的过程。

雷区 1：不够具体

计划是一种集体对焦的方式。好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦。

WBS 工作分解(Work Breakdown Structure)，这是我 们做计划的第一个标准动作。 WBS工作分解结构法：项目管理工具，细分你的工作 - 知乎

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

雷区 2：不够全面

只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节。

识别依赖并画出关键路径，就是我要讲的做计划的第二个标准动作，这一步意味着我们开始从目标的角度对资源进行统筹思考。

进行全面地 规划和安排，为各个阶段设定合理的里程碑节点，确保考虑周全。

雷区 3：不够准确

做计划的第三个标准动作了，就是定义完成标准。越早定义完成标准，计划按照期望完成的概率就越大。

雷区 4：没有共识

没有达成共识的计划，是不具备任何效力的。

达成共识并公开透明，就是做计划的第四个标准动作。

雷区 5：不够即时

每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。而及时调整变更，就是做计划的第五个标准动作。

WBS 工作分解，识别依赖及各环节关键路径，定义完成标准，达成共识并公开

透明，即时调整变更。

06 | 执行：打造品质，要从头开始“闭环”

想要降低偏差、减少返工,就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制。

开环与闭环之间的关键差异，就在于有没有反馈环节，以及系统是否会根据反馈自动调节。

方案评审(OARP 决策机制)

负责人(Owner)：负责给出方案，组织各方讨论并推进做出最终的决定；

批准者 (Approver)：最终批准者；

审核者(Reviewer)：负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论 分析，并提出反馈意见，负责人必须重视并给予回复；

参与者 (Participant)：其他提供意见的人。参与者会收到文档的相关信息，可以对相关问题做出反馈。

Bug Bash(Bug 大扫除)

划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起

来给项目找 Bug，目的是从各个维度衡量和体验产品。

冒烟用例评审

先从测试人员记录冒烟测试通过率开始。收集相关数据，和你的团队在回顾会上一起看看冒烟用例失败所导致的后期 返工成本，讨论出一种更好的确保质量的做法。

07 | 监控：进展“巧”汇报，学会用数据说话

紧急汇报：直面问题有章法

紧急报告，是指在项目发生突发事件，或者提示重要风险状态变化时的实时报告,

紧急报告会包含 5 个基本元素：

1. 事件描述；

2. 影响后果；

3. 跟进分析；

4. 响应措施：包含负责人及时间表；

5. 所需支持。

执行过程中突发的紧急情况，非常考验项目经理的专业素养。必须要直面问题，在紧急时刻勇于站出来承担责任，不仅不会让老板对你的印象减分，还能让决策者在第一时间选择更好的应对方式。

另外，你要尽可能简洁地描述清楚可能的影响和后果，目前的建议方案和所需支持，最大程度地争取各个相关环节的协同配合，共同应对问题。

常规汇报：项目周报回答的三个问题

项目的整体进展状态到底如何？

风险可控吗？

目标达成有没有问题？

最必不可少的就是整体项目状态评估、风险列表、项目概况及计划变更情况。

一份周报的阅读时间不应超过 5 分钟。因此，在写到进展和问题时，切忌事无巨细，只写要点就够了。

数据汇报：善用“透明”的力量

直观地进行过程预测和风险预警，可以帮助大家建立清晰的时间意识，而工作任务的状态分布和剩余工作量分布，可以清晰地展现出每位成员的工作排布情况，帮你快速发现和定位执行过程人员工作量的瓶颈。

不过，比工具更为重要的是，你要结合项目 组中当前需要重点推进或改进的事项，选择合适的数据和图表去做“透明”。

08 | 收尾：项目复盘，小团队也要持续改进

项目复盘会是项目团队有意识地向过去的行为经验学习的过程。

复盘会的基调设定

在复盘会之前，想清楚我们复盘的目的，设定好复盘的基调，其实更为重要

首先，我们自己要先进入反思区。

展示出自己的开放与坦诚，给复盘会奠定基调：这次复盘不是来挑问题的，而是为了找到问题的根源并改进的。

复盘会的会前准备

去梳理整个版本的历程，包括项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等，这些是客观数据的总结。

复盘会的基调设定，以及会前的准备工作，在开会之前，就很大程度地决定了复盘会的效果，你一定要特别留意。

复盘会的简易流程

无法促发行动的复盘，说得再好都是空谈！

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

打造团队持续改进能力

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

09 | 需求变更：化解程序员的“头号噩梦”

锦囊 1：达成最小共识，变更是有代价的

找到合适的时机，树立对变更的最小共识，需求变更是有代价的。

我们追求的是达成项目目标，而不是零变更。

锦囊 2：源头治理，一次把事情做对

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

锦囊 3：快试错，不可抗力巧应对

来自大老板或大客户，这些不可抗力不要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求。

组建了一个老板需求响应小分队，由团队轮流值班，协同提高响应速度，让老板可以试得快，试得爽！同时，对于那些我们并不太认同的老板需求，就快速尝试，先小范围灰度发布，再用对比数据说话。

10 | 风险管理：如何系统化应对风险？

系统化风险识别

风险识别的主体，应该包含项目中的团队成员在内的各方干系人，而不只是项目经理。

系统化的风险识别，是一个反复进行的过程，应该从构思阶段开始，贯穿项目规划和执行的始终。

包括已识别的风险清单，以及潜在应对 措施清单。对于已识别的每个风险，都要评估其概率和影响，并进行优先排序

冰山下的风险

没有人反馈风险，不代表没有风险。

你需要的是一颗真诚交流的心，去关注项目中的每个角色、每个成员的需求，理解他们的困难，愿意为他们提供发展的机会，帮助他们去获得更大的成功，仅此而已。

观察一下，在吃饭的时候，你的团队分 成了哪些群体。

记住，你识别出的风险越多，项目的风险就越低。

风险应对措施

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

在项目排期时，你要确保有相应的故障演练计划，并且做好充分的准备。

通过周期性的风险审查，来识别新的风险。

树立正确的风险观

_**_``_**_

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

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

2. 积极管理致命风险

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

第 2 步：正视风险，不存侥幸心理。

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

11 | 质量管理：一次把事情做对！

质量成本分为两类：一类是事前防止失败的一致性成本；一类是事后处理失败的非一致性成本

事后检查处理的代价其实是最高的。

预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多。

质量规划，明确标准

规划质量，是识别项目及产品的质量要求和标准，并确定用哪些保障方法、改进措施来达到这些标准的过程。

在业务生命周期的不同阶段，质量标准应该是动态变化的。

只能结合具体项目和具体阶段的质量诉求，对质量的标准进行合理定义。

质量分析，追根溯源

1.新功能适当放慢

在基本功能已经成型的情况下，进一步控制新功能开发在迭代中的占比与优先级。当时我们定义的是不超过 70%，在一定时期内，核心功能不再做大的变动

2.回顾总结

将线上 Bug 分析作为周会的一项固定内容，集体讨论出整体层面上的改进措

施，并跟进实施到位。

3.查漏补缺

对已有的测试用例进行全面梳理，与相关的开发、测试、运维一起集体 review，花大力气补充测试代码(增加异常、并发、稳定性测试等)。考虑到这是一项 长期工作，要确保将其分解到各个迭代中，分批实施。

4.走到前面

紧密跟进社区 Bug，分析重现并评估影响，定期总结梳理，并组织讨论应对措施，主动引入必要的补丁。

5.以终为始

新功能需求确定后，测试用例同步设计并进行 review，然后开放冒烟测试标

准，让开发人员在明确“什么是完成”的前提下，进行开发。

质量控制，层层卡点

质量控制及卡点行为，是要结合项目的质量要求和团队的质量成熟度，一层一层地加强质量把关和收口。

12 | 高效会议：项目中要开好哪些会？

“断舍离”，只开最有必要的会，会而有议，议而有决，决而有行。

项目中的重要会议

你要有意识地选择，最适合项目现阶段状况的会议

启动会

启动会的目的是清晰目标，明确授权。要做到这一点，你需要分三步走，分别是 why、what 和 how。

why只有充分理解了项目背景、目的和意义，才能更好地唤起团队的参与热情。

what，描绘蓝图，设定清晰的愿景

how，也就是明确团队之间的责任分工以及合作公约。

关于启动会的内容，你可以从以下十个方面着手准备：

1. 项目背景 2. 项目目标 3. 项目范围4. 里程碑计划 5. 主要风险

2. 组织架构 7. 责任分工 8. 流程机制 9. 沟通方式 10. 支持工具

只有在新项目或新阶段准备启动，涉及到方向、目标、人员、职责的调整的

时候，才需要开启动会来进行公开的澄清和授权。

每日站会

开好站会的关键，是要还政于民。站会满足的是团队的自组织需要，而不是 leader 的监控需求。

项目周会

项目周会的目的，是解决整体计划层面、跨团队协同配合的问题，包括产品、运营、市场、 研发等环节。

根据项目组每个时期的 整体阶段性重点，来设置相应的环节，让大家清晰地感受到项目组明确的导向，也就是什么 是当前最重要的。

保障会议品质的关键

不要盯着会议的数量，而是要追求会议的品质

1. 明确会议边界

每个会议都有特定的主题和目的，并有明确的参会人员范围，这个就叫会议的边界。

确保各部分的进展信息在会前统一提交，会议当场只说重要问题、风险及需要支持的地方；

确保会议当场严格围绕主题开展，对偏离主题的讨论，及时叫停！

2. 建立会议规则

主持人要引导大家建 立会议规则，对于迟到、请假、拖堂、跑题等行为建立公约，并成为规则的守护者。

3. 做好会后跟进

会后所有跟进事项，直接进任务系统，确保跟进到底。

13****| 新手上路，如何引入变化？

“天时”，也就是合适的时机

问题并不等同于时机，只有把问题和痛点关联起来，才能形成一个好的时机。

之所以不能产生改进动力，只能说明，你还没有抓准痛点。

判断是否是痛点的标志，就是看这个问题，如果不解决，对方是否会很苦恼、很痛苦。

要想促发别人的行动，你必须换位思考，去体会和抓住他的痛点

1. 访谈法，也就是直接问。

“你认为项目组当前最大的风险和问题是什么？从你的角度出发，最迫切需要解决的是什么？”

2. 观察法。

去观察那些花他时间和精力最多、他反复强调却又没很好解决的问题，那些才是他真正的痛点。

3. 同理心和倾听。

在变革的早期，最重要的就是寻找到早期支持者。围绕着你想要引入的变化，击中几个重要干系人的痛点之后，这个时机就到了。由早期支持者形成的变革核心团队，就会成 为你在推动变化过程中的重要支撑力量。

“地利”，也就是说，你要学会因地制宜

因地制宜，结合团队的实际情况，为团队定制适合的解决方案

创造一个最小阻力的落地方法，先快速地跑起来，让团队感受到变化带来的闭环成效！

“人和”多聆听彼此，充分理解，找到共同的出发点

在沟通时，你要因人而异，针对不同的人，采用不同的策略。

立场，是指人们在认识和处理问题时所站的位置。立场不同，看问题的视角就不同。 可以把变化涉及到的干系人，按照角色和层级做个初始划分，思考下不同

区域的人，会怎么看待这个变化带给他的影响。

找出更多的积极因素

在引入变化的过程中，面向全员的正式公开沟通，一般会放在最后。

关键问题和主要影响已经处理好了，路障也都清理干净了，变化自然就是水到渠成的了。

总结

首先，你要选择合适的时机，然后，找到因地制宜的解决方案，最后因人而异，采用不同的策略进行有效沟通。之所以要引入变化，不是因为你觉得这个方法好，解决了你的问题，而是要看团队需要的是什么，干系人的痛点是什么。

所有这一切的发生，必须建立在信任的基础上。这个信任不仅仅是对你能力的信任，更重要 的是，你是否能够站在对方的角度设身处地地思考问题。当你是在真心为他着想，为他解决 问题的时候，对方自然会愿意接受你所带来的变化。

14 | 故事案例(下)：小步快跑，小而美的敏捷

为什么引入敏捷？

痛点一：发布时间不可控(快速的增量交付)

提早集成与测试。

及时规避风险。

快速响应变化。

痛点二：摆脱“接力综合征”(从对抗走向协作)

1. 宁愿选择等待

2. 角色间泾渭分明

敏捷的打法，就好比是打橄榄球，所有队员都时刻关注着场上的比分。

设定了共同的 Sprint 目标和完成标准

痛点三：需求理解不一致 (面对面澄清及估算)

15 | 工具方法串讲：手把手教你高效管理

Visio：WBS 及甘特图

Visio：里程碑规划

一页纸项目管理：全局视图及干系人汇报

Overmind：在流程中设置质量卡点

16 | 向上沟通：你必须要注意的三个误区

误区一：所有问题，都自己扛！

迈过自己内心的那道坎，主动大胆地发起沟通，是做好向上沟通的第一步。

不管通过什么途径，我们必须时刻从大局出发，让这些项目关键信息，及时

有效地流动，保障及时有效的决策。

误区二：只知道吐槽，不知道争取

当团队和管理层之间关系紧张时，很多项目经理会特别容易掉进一个误区，那就是，尽自己的努力帮团队解决问题，脏活累活都自己来。

答案就是，把“夹心饼”变成“连接器”，成为高层干系人与团队之间紧密联系的纽带。

作为项目经理，当需要高层重视和支持的事件发生时，该出手时就得出手，引发高层关注，把团队最一手的相关动态信息及时传递给他，争取高层必要的支持，而不是跟着团队一起吐槽。

误区三：抓不住重点，给不出方案

如果你只是这样反映问题，只是说这里不好、那里不好，却没有告诉他，为什么要关注这个问题的话，你的意见不仅不会得到重视，甚至还会产生反效果。

你要反映的问题，与高层干系人的核心关注点是否相匹配，这是能否引起其关注并进一步行动的关键所在。

在向高层干系人提问题的同时，一定要给他一个明确的“点”，让他知道，为什么要关注这个问题。

针对提出的问题，列举可能的解决方案，这一点非常重要。给出前进一小步的解决方案，给领导，也给自己，一个小小的行动暗示。

向上沟通更是职场中的一堂必修课，需要勇气，更需要智慧！

17 | 跨部门沟通：如何巧应对？

约法三章，先说清楚

第一步：建立君子协定

在合作前，你要跟对方建立合约，明确合作目标、合作事项、双方各自的需求和责任、时间进度要求、风险及责任人。要由双方负责人进行邮件确认，公开做出正式的承诺。

在刚开始合作时，建立稳定的预期是关键，双方责任及进度要求，必须要得到公开确认。

承诺越公开，越正式，日后对双方的约束效力就越大。很多公司级的战略合作，都会举办一个签字仪式

第二步：建立机制

合作建立之后，需要建立常规的沟通机制来持续推动。

是否存在“三不管”地带？每个依赖任务的职责是否明确，责任是否具体到个人

第三步：解决问题

1. 己摸清楚状况，尽快启动风险应对机制，确定问题处理方案，比如改变方案、调整时间、增加资源、减少范围等。
2. 今后要采取哪些预防措施，以避免问题的再次发生
3. 打出领导牌,类似这种会影响合作落地的根本机制问题

打开边界，一起想办法

首先，要建立统一、清晰的节奏感。

重新设定节奏之后，如果跨部门协调的问题明显变少了，那么，当前这个节奏就是更合适的。

其次，想要打开边界，你还需要主动往前一步。

总结

我们怎么区分什么时候该使用哪种方式呢？

看双方之间的依赖关系和合作性质。如果更多是单方面依赖、单方面受益，且是 一次性的合作，第一种方式会更加适合。如果是互相依赖，而且是长期合作的共生关系，那么，你就不能只考虑短期利益了。你要从长期的合作关系着眼，建立协同共荣的生态。

18 | 向下沟通(上)：无权无势，他们不听你的怎么办？

非职权领导力的六力模型。“六力”分别是执行力、信息力、感知力、透明力、影响力和整合力，这六力是层层递进的关系，代表了非职权领导力发展之路上的六个层次。

执行力

执行力是非职权领导力的根基，俗称“靠谱”，这是项目经理的立身之本。

我们判断一个人是否靠谱，往往是在说这个人是否具有两个特征：主动担责和有始有终。

1.主动担责

执行力的第一层，并没有什么神奇的，你首先需要跳出自己的小圈圈，主动承

担更大的责任，而不是眼睁睁地看着项目出现问题，放手不管。

2.有始有终

一个有始有终的闭环，意味着你要对自己的每一个行为负责，清楚地了解为什么

做，目标是什么，做完之后效果是怎样的，还有什么问题，以后要做哪些改进。如果中途有变化，也要及时跟相关方明确说明调整或取消的原因是什么。

想要做一个“靠谱”的人，我给了你两条建议：第一，跨出自己的边界，主动担

责；第二，言必信，行必果，做事情有始有终。

信息力

谁掌握着数据和信息，谁就拥有更强大的力量和权力。

当然，信息力可不只是掌握简单的八卦，而是要让流动的信息汇聚起来。作为初学者，你可

以通过信息互通机制和平台来帮助自己做到这一点。比如，周会、站会、周报、邮件列表、 通讯群，甚至是各类数据平台，都可以成为信息力的承载。

感知力

感知力是对“冰山下”隐性信息的敏锐度。种对系统敏锐的感知判断，俗称“闻味道”。

要想培养感知力，你需要经历三个层次。

第一层：现象层。

这一层观察的焦点，是在“冰山上”的行为。

第二层：意图层。

这一层观察的焦点，是在“冰山下”行为背后的真正意图。具体要怎么做呢？

最简单的是，多问几个为什么。

第三层：感受层。

你要试着从这些现象和意图中，去感受每个人的状态和需要。

要想培养感知力，就要在日常的观察之中下功夫。从关注行为，到关注行为背后的意图，再到关注意图背后个体的核心感受和深层需要，最后着眼于团队中的气场和互动品质。

19 | 向下沟通(下)：无权无势，他们不听你的怎么办？

透明力

把你看到的问题可视化，让决策者和团队都能看到这些问题。这就是我经常说到的透明的力量。

想要引发改变，不是仅凭一人之力就可以做得到的。要打破这个恶性循环，就一定得让大家真正地看见问题，并且从心底里达成共识。

一个是“分析−思考−看见”，

一个是“目睹−感受−看见”。

想要改善什么，就把什么透明化！在走脑的同时又要走心，让团队的所有人都

看见问题，调动起集体的关注力和改变的动力。

影响力

影响力的真正秘诀却在于“听”，而不是“讲”。

因为理解，所以才能创造共鸣。

不听，是一切沟通问题的根源。

只有当你真诚地抱着想要了解和倾听对方的愿望，放下对自己的想法的执着时，你 才能留意到对方真正的需要。这样自然的交流分享，反而更容易产生碰撞，引发共振。

整合力

凡是能促进业务良性运作的，凡是能促进团队健康发展的，都是整合管理的范畴。

一群优秀的人结合在一起，也并不一定能成为一个优秀的团队，不一定能真的做成一个业务。

20 | 进阶之路：项目经理预备战之PMP认证攻略

千万不要舍本逐末，为了证书去考试。让考级最大程度地帮助自己提升专业技能，才是最重要的。

为什么要考 PMP？

PMP认证的普及为 我们创造了项目管理专业的共同语境。

PMP 的认证过程也是我们学习并掌握一门项目管理的国际标准语言的过程，就好

比是学会了另一门英语。

如何有效备考 PMP？

第一步：确定考试的目标时间

PMP 每年有 4 次考试，分别在 3 月、6 月、9 月和 12 月。

第二步：完成中英文报名

第三步：课程学习和备考

1. 通读 2. 精读 3. 记忆

项目管理进阶之路

一旦涉及到职业选择，最关键的一点就是，尽可能不要让自己被很多外在的因素所左右。

在拥有热情的前提下，经验背景的差异都是可以用时间弥补的。

此处无广