mod

极客时间专栏/项目管理实战20讲/常识篇/01 | 角色转换：程序员做项目管理的三大误区.md

@@ -0,0 +1,91 @@
+<audio id="audio" title="01 | 角色转换：程序员做项目管理的三大误区" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f5/67/f56062c26ec55138580f9f403a342d67.mp3"></audio>
+
+你好，我是雷蓓蓓，今天是专栏的第1讲，主题是从程序员到项目管理的角色转换。我会结合自己的经历，跟你聊一聊在这条赛道切换之路上，容易进入的三个误区。
+
+在成为一名专业的项目经理之前，我曾做过四年的“程序媛”。在那时的我看来，程序员是个很有意思的职业，一个人敲代码的日子，现在回想起来，我依然觉得有很多乐趣。我喜欢用代码尝试各种效果，折腾新的技术和语言，从图书馆背回来厚厚的《设计模式》，一边学，一边在我的项目上应用实践。
+
+那时的我，不怎么需要跟人交流，一天到晚对着屏幕，只要跟我的代码在一起，就觉得自己可以上天入地，玩得不亦乐乎，真当是“代码在我手，天地任我游”！
+
+尽管当一个很牛的程序员是一件很酷的事情，但是我却很早就意识到，做技术大概不是我一生的饭碗和追求。当我开始成为这个岗位上的“熟练工”之后，我发现自己开始有了更多的渴望。
+
+直到有一天，摆在我面前的路，出现了新的转折。那时，组织中成立了新的项目管理部，于是，我通过内部转岗，顺利地成为了第一名全职的项目经理。从此，项目管理的世界向我敞开大门，带领我走上了一条完全不同的人生轨道。
+
+美国电影中经常有句话说，Great power means great responsibility（能力越强，责任就越大）。项目管理这个岗位，让我从管好自己的事，到开始操心别人的事，责任范围一下子扩展开来。这种责任范围的扩大，极大地锻炼了我的全局分析能力、统筹规划能力、以及沟通协调能力。
+
+但由于并非天生适合跟人打交道，刚开始时，我丝毫体会不到什么power，反倒经常感觉有劲儿使不出来，被新的责任压得喘不过气来。正是这段经历，让我对想要从程序员转做项目管理的同学，有了更多的同理心和体谅。
+
+结合我的经历，我把这个转换过程中常见的问题，归纳为以下三大误区：
+
+## 误区1：凡事恨不得事必躬亲
+
+当我做程序员时，我的工作是高度可控的，我可以把每天的工作安排得井井有条。但在做项目管理之后，我发现自己的产出全部依赖别人的工作，于是我会经常性地陷入一种抓狂的状态，着起急来，甚至会忍不住冲上去，替别人做好人家本该做好的事情。但是，后来我慢慢地意识到，对于团队长期的发展而言，这种行为的效率是最低的。可当时的我，跟自己直接去做相比，**想办法影响他人去把事情做好，要难得多**。
+
+那么，如何影响他人去做好一件事呢？在不断地反思之后，我总结出了**成功施加影响的三个层次，分别是让人知道要做（Awareness）、有动力做（Desire）和有能力做（Ability）**。
+
+我曾经跟一位产品总监合作，他交待工作非常言简意赅，团队只知道最终输出的指令和结论，但完全不清楚背景，更不用说明白他的思考过程是什么，以及为什么要这样做了。有一次，他的下属跟我说：“老大昨天晚上突然给我打电话，让我马上把就要上线的活动停掉，不要再做了。”他非常困惑，因为团队已经投入了一个月的精力，马上就要见到成果了，但没等他问为什么，老大就直接把电话挂了。
+
+这样的团队，听上去应该执行力不错，老大的指令都会被立马执行，可事实却并非如此。我发现他们完全谈不上有做事的动力，很多时候都只是照章办事，出了问题也不敢去问，结果往往导致执行效果与预期相差甚远。
+
+对照刚刚我们所讲的三个层次，这应该只是第一个层次。**单方面的工作交待和告知，停留在浅层次的信息传达上，只是让人知道要做，但并不足以让人产生动力，去促成有效的行动。**
+
+事后我了解到，这位总监之所以着急叫停，是为了规避短期的政策风险。在我和他沟通之后，他主动找来这位下属，讲明了自己的意图。随后，他们一起制定了一种合理的策略，经过调整之后，这个活动还是如期上线了。
+
+这个例子告诉我，在把工作授权给别人时，对于动力（Desire）的关注尤为重要。**讲清楚为什么要做，为什么要现在做，获取理解及认同，激发团队的动力是项目经理成功授权工作的关键。**
+
+在动力的基础上，你还要确保你所选择的人有相应的能力来做到这件事情。如果现阶段的团队都没有对应的能力，该怎么办呢？**项目成功关键路径上的核心能力缺失，是你作为项目管理人员，要当作最高优先级的风险管理的事项。**
+
+从外部引入相应的人才，是最直接有效的方式。除此之外，你还可以去积极争取**短期借调、内部转岗**等。从长期来看，你还需要有意识地发现和投资那些团队中最有潜力的人，给他们安排相应的工作辅导，开展有针对性的培训等，帮助项目组成员发展相应能力，让事情真正落地。
+
+以上，就是授权工作时，**成功施加影响的三个层次，从让人知道要做、到有动力做，再到有能力做**。
+
+## 误区2：追在别人屁股后面做监工
+
+在我做项目管理的第一年，经常会有种“赶鸭子上架”的无奈。通常情况下，我会在心里设定一个目标，然后费尽心力地把大家往一处赶，但往往我赶得越是卖力，鸭子们就越是跑得到处都是。
+
+其实，项目经理最该做的，不是每天逐个人逐条事项的监督，而是**要明确目标，建立机制，并让这个机制运转起来，最终在项目组形成一种良性的秩序。**
+
+比如，项目经理要带大家一起开启动会，清晰愿景目标，定义阶段里程碑和完成标准，接着制定分段执行的计划，把事情的所有环节从头到尾捋顺了；项目经理要建立上下游协同的流程规则，明确各个角色在整个过程中的职责，获得大家的认同和共识；项目经理还要建立站会、周会等制度和模版，让进展和风险通过这些良好设计的信息渠道汇聚，借助规则和工具来达到监控的目的。
+
+我会在接下来的内容中，把我的经验系统化、分步骤地传递给你。这里你需要记住的是，项目管理并非要让你成为监工，**要始终依靠流程和规则来约束大家的行为**。当成熟的秩序在团队中形成之后，从日常琐事中解放出来的项目经理，就可以集中精力去做愿景驱动、激励团队等更高层面的工作，真正做到变“赶”为“引”。
+
+## 误区3：拿着锤子，看哪里都是钉子
+
+我曾经见过一位新官上任的项目经理，可能是因为终于得到施展的空间了，一上来就左突右攻，恨不得把十八般武艺全都套上去，结果激起了许多不必要的麻烦。开站会也好，电子看板也罢，本来都是好工具，但是如果引入过程不当或时机不对，会让团队产生抵触心理，最终拿不到好的效果。
+
+看到项目中的问题，哪里都很想修理一下，这种心情我非常能理解。但是，你要知道的是，每个项目的现有执行方式，都有它本身的背景和成因，不管现有方法是否先进，都是更加适应本土环境的。
+
+在这个课程中，我会跟你分享很多新的方法和工具。但我担心的是，越是好学生，越有马上上手实践的冲动：“看到好的东西，我就想马上在自己的实践中尝试一下。”
+
+如果你也是这样，那么，我要提醒你，先不要急，你要与项目中的重要干系人加强沟通，理清前因后果，多想想自己的项目现阶段到底最需要什么，这对项目管理方法的成功推进至关重要。每个项目都有它独特的情境。你可以试着问自己几个问题：
+
+- 在你的项目组中，时间、成本、质量、范围这几个因素，到底哪个更重要？哪些是允许有一定调整空间的？
+- 各个角色目前的痛点在哪儿？哪些是最先需要解决的？这些问题背后潜在的原因是什么？
+- 团队对于这个痛点的改进是否有真实需要？需求的迫切程度如何？
+- 你的老板或项目发起人对于项目管理以及你本人的定位是怎样的？关于这些问题与可能的改进，你是否与其沟通过并达成了一致？
+- 如果你打算引入新方法或工具，更适合用怎样的路径进行，是自上而下地全面推广，还是自下而上地一步步优化呢？最有可能从哪个问题切入？
+
+这些问题能够帮助你理清思路，从项目和团队当前的真实痛点出发，找到真正解决问题的方法和步骤。
+
+回到刚刚说到的那位新官上任的项目经理，在我和他对照着以上这五个问题分析完之后，他终于明白了问题到底在哪儿。在他的项目中，时间绝对是第一要素，拖延一天交付都是直接损失。在这样的情景下，团队对变更的容忍度很低，最头疼的就是客户的需求变更又很频繁……实际上，变更的背后是对客户需求管理的失控，大家对这个痛点的改进要求非常迫切，项目发起人也很是头疼。
+
+之前他看哪儿都是问题，眉毛胡子一把抓，现在经过梳理之后，他意识到自己应该找准变更这个切入口，让大家看到切实的效果，其他的改进一步一步来。说干就干！他和发起人沟通了自己改善变更的思路和方法，很快就得到了认可，而通过这些有效的改进，团队对他的信任也与日俱增了。
+
+## 总结
+
+最后，我们来小结一下。从程序员走向项目管理，是从“左手习惯”到“右手习惯”的转变。其中，思维模式和行为习惯的转变，远比学会使用那些工具方法要有挑战得多。从管好自己的事，到管好别人的事，你需要有意识地避免3个误区。
+
+第1个误区是凡事都要亲力亲为。遇到事情时，你不要自己直接去做，而是要想办法驱动他人去做好事情。在授权工作时，有三个层次，从让人知道要做，到让人有动力做，再到有能力做。你需要**讲清楚为什么要做，为什么要现在做，获取理解及认同，激发团队的动力，同时为每个任务选择能力匹配的授权对象**。
+
+第2个误区是追着别人做监工。做项目管理，不是要你变成监工，而是要你带领团队明确目标，建立机制，并让这个机制运转起来，**要始终依靠流程和规则来约束大家的行为。**
+
+第3个误区是拿着锤子看哪里都是钉子。每个项目的现有执行方式，都有它本身的背景和成因，你要与项目中的重要干系人加强沟通，理解前因后果，**从项目和团队当前的真实痛点出发**，找到真正解决问题的方法和步骤。
+
+如果你已经走上了项目管理之路，在开始系统学习之前，你最好整体梳理一下自己所在项目组的背景情况，这将会为你之后的学习和实践找到方向。
+
+## 畅所欲言
+
+现在，请你对照自己的日常行为，结合以上三个误区完成一个自检。了解自己的行为倾向，并结合你的项目情境，回答误区3中的五个问题。
+
+你可以在留言区写下你的回答，我们一起讨论。同时，我也会在后续的课程中，尽可能结合你的项目情景来组织讲解，期望能为你带来最大的帮助。
+
+

极客时间专栏/项目管理实战20讲/常识篇/02 | 十大领域五大过程组（上）：程序员必须要了解的项目管理常识.md

@@ -0,0 +1,132 @@
+<audio id="audio" title="02 | 十大领域五大过程组（上）：程序员必须要了解的项目管理常识" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b0/f3/b08a60f97f7682e6191dac2ccf95ecf3.mp3"></audio>
+
+你好，我是雷蓓蓓。在上一讲中，我给你分享了程序员做项目管理的三个误区。在留言区，我注意到这样一个问题：“如果我想转岗做项目管理，需要满足什么条件呢？”
+
+其实，想要做项目经理，并没有太多硬性条件的约束，**好的项目经理不问出身**。在我的团队中，那些非常优秀的项目经理，不仅经历、知识背景各不相同，性格特质也都不一样。实际上，理论、经验、知识背景都是可以后天培养的，而意愿是第一位的，其次就是持续不断的学习和刻意训练。
+
+今天，我们来聊一聊项目管理常识。古人云：“会当凌绝顶，一览众山小。”掌握了项目管理的理论常识，就相当于拥有了一幅鸟瞰全局的知识地图。我会花两讲的时间，带你初步领略项目管理的知识体系框架。
+
+项目管理是一门古老的科学，既包含工程技术、管理技术，又与组织行为学息息相关，比如系统科学、行为科学、心理学等，同时还涉及金融、会计等经济学范畴，逐渐发展成为了一门多维度、多层次的综合性交叉学科。
+
+## 项目管理的历史
+
+1917年，美国一位名叫亨利·甘特的机械工程师，发明了著名的**甘特图**，就是一张标明计划与实际完成情况的图表。美国机械工程师协会和管理学会曾经专门设立亨利·甘特金质奖章，并把第一枚授予了已故的甘特，当时他所享有的盛誉可见一斑。
+
+时间切换到1957年，美国的路易斯维化工厂。他们把检修流程精细分解后，竟然发现，只要缩短最长路线上工序的工期，就能够缩短整个检修的时间。这就是至今项目管理工作者还在应用的“**关键路径法**”，简称CPM。
+
+到了20世纪60年代初，举世瞩目的“阿波罗”登月计划，更是让项目管理方法从此风靡全球。进入90年代后，项目管理逐步标准化，国际上逐渐形成了三大项目管理的研究体系，分别是欧洲的国际项目管理协会（IPMA）、美国项目管理协会（PMI）和英国的PRINCE2体系。我要介绍的十大领域五大过程组，就是出自在国内普及度最高的美国PMI标准体系。
+
+## 什么是项目管理？
+
+要登上月球，光有宏大的想法可远远不够，你还需要让这个想法成为现实的大量资源，以及一套科学严谨的落地方法。
+
+**“项目管理就是变理想为现实，化抽象为具体的一门科学和艺术。”**
+
+这是我听到过的对项目管理最为精辟的总结。
+
+《项目管理知识体系指南》这本大部头可以说是项目管理领域的圣经，它的第一版是由PMI组织了200多名世界各国项目管理专家，历时四年完成的，目前已经演进到第六版，可以说是集世界项目管理界精英之大成了。
+
+现在，就让我带你去看看这本书中对项目以及项目管理的官方定义。
+
+> 
+项目是为创造独特的产品、服务或成果而进行的临时性工作。
+
+
+> 
+项目管理就是将各种知识、技能、工具与技术应用于项目活动，以满足项目的要求。
+
+
+具体来讲，项目管理就是指把各种系统、方法和人员结合在一起，在规定的时间、预算和质量目标范围内，完成项目的各项工作，对组织资源进行计划、引导和控制。
+
+由于项目管理的知识体系过于庞大，PMI把它分为项目管理五大过程组和十大知识领域，共49个子过程。今天，我们先来了解一下项目管理的十大领域。
+
+<img src="https://static001.geekbang.org/resource/image/c8/26/c8520ed1bfa559f04ce91d18aea3a426.png" alt="">
+
+## 项目管理的十大知识领域
+
+项目管理的十大领域，将项目管理的工作内容划分为：整合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、干系人管理、风险管理和采购管理。
+
+其中，进度、成本、质量、范围是4个核心领域，风险、沟通、采购、资源、干系人管理是5个辅助领域和1个整体领域，如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/0f/09/0fed5d63487e80ae207ef8df16fa5809.png" alt="">
+
+学会了这些过程方法之后，不管你做什么，都可以按照项目管理的框架和方法去做。我们来借助一个实际场景，帮助你更好地理解。
+
+比如，你的部门最近有大量新员工入职，同时业务发展涉及越来越多的跨部门合作，领导希望你组织一场跨部门的篮球竞技活动，让大家以最快的速度熟悉起来。
+
+接到这个任务以后，如果你熟悉项目管理十大领域，就可以尝试从以下十个角度，快速地进行完整而有效的分析思考。
+
+**1.干系人管理：如何管理干系人？**
+
+首先，你要弄明白一件事：在这个活动中，哪些人会是你的干系人？项目发起人对活动的预期效果是什么？比如说增进团队的协作，提升凝聚力等。
+
+除此之外，这个项目是否存在更多的潜在干系方，可以助力到活动的成功举办呢？比如，经过一番了解，你发现HR部门最近刚刚成立了团建组，很愿意为活动提供赞助，那么，这时你需要思考，如何拿到这笔赞助？HR总监对于活动的诉求又是什么？
+
+最后，分析完干系方之后，你要思考一下，如何更好地管理干系人的期望和影响？活动过程中的各类决定，都需要谁来拍板？干系人要以什么样的方式参与？
+
+**2.范围管理：做什么？**
+
+分析完各方干系人的诉求，就可以进一步来划定项目交付的范围了。在这个过程中，你的主要任务是搞清楚到底要做到哪些事，才能更好地达成各方的期望。
+
+比如，这次篮球赛的预期目标具体是什么？是更关注活动的参与度和投入度、部门之间的合作交流，还是活动的对外影响力？你要**确保围绕着预期目标来设计相应的活动方案**，然后再进一步确定活动前、活动中、活动后分别要完成的具体工作。
+
+**3.进度管理：花多长时间？**
+
+把理想变为现实，你需要一步一步来。进度管理，就是说你**要规划好阶段性步骤，同时明确每个里程碑的目标成果和时间安排**。
+
+比如，活动的总工期是一个月，那么你可以分为四个阶段来进行：
+
+- 第一阶段，启动项目并确认概要方案设计；
+- 第二阶段，规划并落实人力和各项资源的投入；
+- 第三阶段，确定具体的活动流程和详细分工，完成活动前的各项准备工作；
+- 第四阶段，做好活动当天现场的统筹和运作。
+
+**4.成本管理：花多大代价？**
+
+你要思考一下，活动预算有多少？资金什么时候到位？如何使用？你要去关注整个预算中成本最高的开销是什么，比如是一笔价格不菲的教练费，然后，你要判断这笔投入可能带来的收益，也就是说钱是否用到了刀刃上？总之，你要从全局视角去思考，如何更有效地管理项目的各项投入，以达到更加匹配目标的预期效果。
+
+**5.质量管理：达到什么要求？**
+
+从这个角度来说，你需要先确定这次活动圆满成功的标准是什么，是现场参与人数、参与者满意度、管理者的满意度，还是对外传播效果？然后，以终为始，思考一下，你需要引入哪些必要的流程和方法，以保障活动效果的达成。
+
+**6.资源管理：有多少内部资源？**
+
+你要知道，公司内有哪些核心资源是可以使用的？比如，宣传渠道、设计人员和经费支持等。另外，公司内部有哪些人可以作为支援活动的志愿者呢？公司可以提供活动所需的哪些物品？
+
+**7.采购管理：有多少还要买？**
+
+确定了可以使用的公司资源以后，你要接着思考，还有哪些是需要外部采购？有哪些工作需要外部人员支持？如果经费受限，是否可以通过交换资源的方式，来获取更多的外部支持？
+
+**8.沟通管理：如何管理沟通？**
+
+从这个角度出发，你需要考虑的是，活动策划团队、执行团队分别通过什么方式来进行项目沟通？与发起人和赞助方的沟通方式和频率是怎样的？你如何保持团队内外项目信息的高效传递，使用什么方式来同步进展？
+
+**9.风险管理：如何应对风险？**
+
+你要弄清楚哪些风险可能会妨碍这次篮球赛的成功举办，比如天气因素、场地因素、交通管制、赞助方经费紧张、物料供应延期、公司内外政策变化导致活动被喊停、业务压力大导致兼职志愿者流失等等。**你需要提前做好系统性的风险识别，分等级制定应对策略**。
+
+**10.整合管理：如何实现整体最优？**
+
+整合管理是要告诉你，作为这个活动的大内总管，你该如何去统筹全局，整合并协调各个环节的利益冲突和工作安排，在不断变化的情境下，根据活动的目标“裁剪”出合适的过程、方法和工具，进行有效管理，从而达到全局的最优效果。
+
+<img src="https://static001.geekbang.org/resource/image/e2/31/e28d7100d4d65d079da2f070802cb931.png" alt="">
+
+看到这里，你应该会发现，即使只是一场简单的团建活动，想要真正把它做好，其实并不容易，你需要多方位的思考框架来指导落地实践。
+
+有同学给我留言说，自己同时并行着很多项目，一头雾水，不知道从哪里着手。我刚刚介绍的这十大领域，就提供了十个有效的思考角度，包含了你能想到的项目运作的方方面面。不管是多难多复杂的项目，所包含的要素无非就是这些，你都可以借鉴我们刚刚使用的框架进行拆解，逐个梳理，快速理清头绪。
+
+**总结**
+
+我们来回顾下今天的内容。首先，我给你简单介绍了项目管理的发展历程，以及项目管理的官方定义。接着，借助实际案例，我们对项目管理的十大领域进行了层层拆解。
+
+实际上，项目管理工作的涉及面非常广。关于项目管理的职责定位，不同组织在实践应用的过程中，给出的定义各不相同。我所在的网易杭研项目管理部，将我们多年的实践经验提炼总结成了12个字：保目标，助决策，提效能，促协作。
+
+在下一讲中，我会为你介绍在实战过程中，我们团队对互联网项目及项目管理职责的理解和定义。同时，我会带你从项目动态演进的过程维度进行拆解，继续为你介绍项目管理的五大过程组。
+
+**畅所欲言**
+
+给你留一个小作业：请你基于这十大知识领域的框架，对照着自己的项目进行思考，并用脑图的方式完成拆解，以便让自己快速建立起项目全局观。
+
+最后，我想请你来谈一谈，针对我们刚刚讲到的十大领域，你最想了解哪个领域？你遇到的典型问题有哪些？欢迎你畅所欲言，我在留言区等你！如果你觉得文章对你有所帮助，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/常识篇/03 | 十大领域五大过程组（下）：程序员必须要了解的项目管理常识.md

@@ -0,0 +1,112 @@
+<audio id="audio" title="03 | 十大领域五大过程组（下）：程序员必须要了解的项目管理常识" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d2/da/d2776c282d551250d11407a2301fb3da.mp3"></audio>
+
+你好，我是雷蓓蓓。在上一讲中，我给你介绍了项目管理的十大知识领域，今天，我会接着来讲五大过程组。同时，我还会结合在网易的项目实战经验，给你分享一下我对互联网项目管理的理解。
+
+很多人应该都听说过PDCA循环，它最早来自于质量管理领域，意思是做任何事情，都要经过规划（Plan）、执行（Do)、检查(Check)和行动(Act)这四个步骤，又称戴明环。可以说，这四个步骤提供了一个简易的思考和做事框架。需要注意的是，这个循环并不是运行一次就结束了，而是周而复始、螺旋上升的。别看它很简单，实际上，越是简单的东西，就越是普适！
+
+戴明环的应用非常广泛，其中就包括项目管理领域。PMI遵循PDCA的法则，将所有的项目管理活动分成了五大过程组，分别是启动过程组、规划过程组、执行过程组、监控过程组和收尾过程组。如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/85/bc/85a371a880b4ceec3210b641a34eecbc.jpg" alt="">
+
+## 项目管理的五大过程组
+
+**1.启动过程组（千里之行，始于足下）**
+
+**启动过程组意味着正式开始一个项目，或者是开始一个项目中的新阶段，包括识别干系人和制定项目章程两个子过程**。识别干系人是一个非常重要的环节，我会在第4讲中跟你具体分享一下，今天我们先来说说制定项目章程。
+
+启动过程组是最容易被忽略的过程组之一，越是持有结果导向的人，就越容易马上直奔主题去做，根本不管什么项目章程。
+
+最近我的一个项目经理，就遇到了这样的情况。他的团队中来了一位新的负责人，新官上任之后，立马开始快速推进一个新的战略项目。这位负责人总觉得进度太慢，就整天抓着这位项目经理不放，让他反复催着大家每条事项要结果，弄得他苦不堪言。
+
+在了解了具体情况之后，我发现，这个项目之所以推进困难，是因为大家的配合意愿不高。尤其是那些涉及上下游衔接合作的环节，很少有人会主动推着往前走。究其根源，这是因为大家对这个项目有很多疑问，比如，这个项目的整体愿景是什么？做这些任务，是为了达成什么目标？怎么才能把这些任务和现有的工作安排得很协调呢？他们看不到项目整体，只是在完成一条条的具体任务。
+
+这位项目经理非常有责任心，总是各个节点反复不断地去催，一个一个环节去推动，但他越是卖力，越觉得推进困难。我跟他说：“你这样看似很努力，但其实这就像是拿着小铲子推土，效率太低。就算你晚上都不睡觉，恐怕也只能这样。”
+
+那么，更有效率的方式是什么呢？其实，我们在启动一个新项目或新阶段时，首先要建立项目章程，并且通过启动会去公开确认。启动会的作用，就好比一个大型的推土机，是面对项目组全员，**正式宣告一个新项目或新阶段的开始，公开确认项目章程，包括明晰各方干系人的期望和诉求，设定愿景目标和重要里程碑，确定责任分工和沟通机制等**。
+
+很多程序员刚开始做项目经理时，思维没有转过来，一拿到项目，就会立刻进入分析、设计、写代码的状态，却没有意识到，如果在启动会上把这些问题交待清楚了，就会省去非常多的后期沟通成本。
+
+如果涉及到跨部门的项目，启动会就更加重要了。项目经理要积极创造一个场合，邀请更高的管理层出面，讲清楚项目的背景、目标和重要性。除此之外，启动会也是项目管理人员获得公开授权的有效方式，可以让你之后的推进工作更容易开展。
+
+**2.规划过程组（运筹帷幄，决胜千里）**
+
+规划过程组可以说是项目管理工作中最为繁重的一个环节了。如果说启动是要明确目标，那么，**规划就是要把愿景目标转化为可落地的行动方案和工作路线**。对规划过程组进行有效管理,可以更容易地获取干系人的认可和参与。
+
+你需要根据预期目标，明确项目范围，确定项目的里程碑阶段目标，为项目的执行做好各项准备。
+
+对于一个复杂项目来说，规划通常是一个渐进明晰的过程，近期的规划往往是最具体的，需要拆分到具体版本和工作项（如下图所示），而远期的规划则相对比较模糊。随着收集和掌握的信息逐渐增多，规划也要进一步动态细化，不断更新。我会在第5讲中着重讲一讲规划的常见问题，给你分享一份常见的避坑指南。
+
+<img src="https://static001.geekbang.org/resource/image/b9/c4/b93e7e9b14e9a7039e3d8847fe1d96c4.jpg" alt="">
+
+**3.执行过程组（言出必行，行之必果）**
+
+规划做好之后，就是考验执行力的时候了。这个阶段重在整合资源，推进项目落地，完成项目管理计划中确定的工作以实现项目目标。
+
+如果在启动和规划环节做好了，到了执行环节，项目经理反而会轻松一些。这就好比汽车在高速上跑起来之后，如果你设定了100码的定速巡航，汽车自己就会执行运转。这时，你的工作更侧重于确保项目一直在正确的轨道上，确保各个环节按照规划进行，并且能够真正做到位。
+
+那么，怎么来判断是否做到位了呢？这就要讲到监控过程组了。
+
+**4.监控过程组（审时度势，沉着应变）**
+
+执行并不意味着在任何情况下都要一成不变。当外界环境或内部要求发生变化时，项目管理者也要审时度势，沉着应变，适时地调整各方，以更好地实现目标。
+
+为了做到这一点，你需要定期对项目的进展、范围、质量等进行跟踪和监控，识别目前的进度与计划之间的偏差，从而快速准确地采取办法进行纠正和调整。在专栏后面的内容中，我会跟你介绍一下，如何通过一些大盘或报表，有效地监控项目中的各项信息。
+
+**5.收尾过程组（慎终如始，则无败事）**
+
+收尾过程组是五个过程中的最后一个，而头和尾都是最容易被忽略的，所以我要重点强调一下。在这个阶段，你要交付项目成果，组织团队的回顾复盘，归档所有文档等组织过程资产，正式结束一个项目或阶段。
+
+就像刚刚结束一场大考一样，项目发布上线之日，就是项目经理的解放日，项目经理可能会想：“管它是死是活，我都不想再看第二眼了。”这种心情我非常能理解，但虎头蛇尾其实是最应该规避的毛病。
+
+所谓慎终如始，则无败事。重要的事说三遍：“复盘！复盘！复盘！”**不管项目成功与否，“趁热”复盘都是极为重要的一步。**
+
+就我们团队而言，我们不光会复盘正常结束的项目，对于那些中途被叫停的非正常“死亡”项目，我们会格外重视，并立即复盘。我把这种复盘会称为“验尸会”。这样的复盘通常会带给我们很多有价值的信息和启示，比如哪些致命风险需要在一开始就被很好地管理和应对，再来一次的话，我们该怎么做。
+
+## 互联网项目管理的职责定位
+
+五大过程组是非常经典的项目管理模型，但是从互联网类业务的情境来看，我们往往会觉得很迷惑，因为项目与项目之间的边界相互交叠在一起，产品需求就如同海浪一样，一波未平，一波又起，大浪中夹杂着小浪。除非产品下线，否则“造浪机”在整个产品的生命周期中根本就不会停息，看不到哪里是尽头，又哪来的启动和收尾呢？
+
+事实上，对于大多数互联网产品而言，研发期和运营期是交织在一起的，并非像传统软件那样，有个清晰的项目交付目标和时间周期。这样海浪式迭代演进的过程，给追求确定性和控制感的项目管理，带来了新的挑战。
+
+不过，我们需要承认的是，从项目管理的方法层面来看，经典方法仍然是通用和普适的，只是你需要基于你的场景，找到对应颗粒度下的PDCA闭环管理方法。
+
+那么，把我们所讲的十大领域五大过程组，放在互联网的实战场景中，项目经理到底在做什么呢？我们说，项目管理有着天然的无边界属性，这也就意味着，放眼全局你能看到的地方，你什么都得操心、什么活都得干。所以，要搞清楚这件事，其实是很难的。别的角色都有自己的输出、自己的作品和固定的职责，但是好的项目经理却是融于无形的，整体项目团队的产出就是项目经理的作品。
+
+你还记得我在上一讲的最后提到的我们团队总结提炼的12个字吗？“保目标、助决策、提效能、促协作。”这12个字看上去简单，却真的是我们团队整体智慧的结晶，它不仅体现在项目管理的日常工作中，更体现在项目经理的绩效考核、晋升答辩等过程中，是指导项目管理实战工作的基本纲领，下图是这个基本纲领的总览：
+
+<img src="https://static001.geekbang.org/resource/image/c4/29/c44d728a748bb462b99ea26e935de329.png" alt="">
+
+我们先从纵向来看，在从战略到执行的过程中，项目管理的两项职能是保目标和助决策，这形成了一个围绕目标驱动的闭环。
+
+把业务最顶层的战略意图，清晰地反应在每个人每一天的执行中，其实是件非常不容易的事情，需要一层层地进行拆解。首先，你要围绕组织绩效目标，定位出核心的3～5件要事，即关键战役，再把关键战役进行规划分解，拆到可交付可验收的里程碑，最后落地到版本/迭代的工作安排中。
+
+<img src="https://static001.geekbang.org/resource/image/13/ed/137821e7ffe3cd8f7da0a98a7cec9ded.png" alt="">
+
+接着，你还要通过清晰而系统的反馈机制和平台，把执行中的进展状态、变更、风险等集中呈现，以帮助管理者更好地进行优化和调整。比如，结合产出进度来调整业务策略，通过里程碑状态信息来调整目标和规划的节奏，根据人力投入的分布，来优化整体的资源配置。
+
+这些就是保目标、助决策的部分。
+
+然后，我们从横向去看，提效能和促协作，本质上都是工作在上下游跨角色协同的这条线上，链条越长，协同就越是复杂。
+
+- **提效能是要去关注和消灭团队中的低价值工作所引发的效能痛点**。举个例子，假如测试环境的部署耗时很长，这已经成为了整个团队的瓶颈，那你就要想办法通过技术的手段实现自动化，从而为整条链条提速。
+- **促协作则是着眼于使用各种项目管理方法和工具，让高价值工作者可以更好地合作**。比如，建立清晰有效的信息渠道和沟通机制，积极推动各角色达成共识等，实现全局价值的最大化。
+
+总结一下，保目标、助决策是要打通从战略到执行的闭环，提效能、促协作则是打通上下游协同的闭环，这12个字就是我对于互联网实战中项目管理职责定位的理解。关于它们在实战中的具体应用，我会在专栏后面的内容中详细地为你介绍。
+
+## 总结
+
+好了，讲到这里，项目管理的常识我就都介绍完了。十大知识领域和五大过程组，代表了整个项目管理知识领域中的一横一纵两条主线。这个知识地图，为我们后续的学习提供了一套标准框架。
+
+<img src="https://static001.geekbang.org/resource/image/79/3b/794008c28830250ddff2bc6af0cf3d3b.jpg" alt="">
+
+你需要对这些知识有整体的认知，这些基础理论可以给你的实践提供专业科学的指导。不过，你没有必要一一记得，在第二模块“硬技能篇”，我会从这几个过程组和知识领域出发，结合实践中的常见痛点，给你介绍更多实用的方法。
+
+你要知道，项目管理是一门实践科学，并不会有什么一招制胜的银弹，但是，只要你跟着专栏进行系统地学习，认真思考，谨慎实践，就必定会在项目管理领域有所成就。
+
+## 畅所欲言
+
+十大领域五大过程组的内容纷繁复杂，专栏内容不可能面面俱到。好在专栏是个互动性非常强的学习形式，你的每条留言，我都有认真去看，你的问题会成为我的动力，我会竭尽所能地为你答疑解惑。最后，我想请你来谈一谈：在你的应用场景中，你对哪个过程组更为关注？你最想学到哪个过程组的方法呢？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友，我们下一讲再见！
+
+

极客时间专栏/项目管理实战20讲/开篇词/开篇词 | 为什么说项目管理是每个人的底层能力？.md

@@ -0,0 +1,73 @@
+<audio id="audio" title="开篇词 | 为什么说项目管理是每个人的底层能力？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c3/5d/c387e07de36d3071decb4bb0186a6c5d.mp3"></audio>
+
+你好，我是雷蓓蓓，一名程序员出身的项目经理，现在是网易杭研项目管理部总监。
+
+我所负责的网易杭研项目管理部，从2011年成立以来，就一直在互联网项目管理领域深耕，现在我们已经有30多名专业的项目经理，为网易云音乐、网易严选、云计算、智慧企业等产品提供专业的项目管理服务。这八年来，我们做微专业视频课，经营公众号，还合写过一本介绍网易项目管理实战经验的《网易一千零一夜》，帮助更多人掌握项目管理技能。
+
+我始终认为，项目管理这项技能，可不仅仅是项目经理才需要掌握的。当代项目管理发展之快已经超过了我们的想象，美国《财富》杂志就曾经预言，项目管理将是下一个世纪的首选职业。事实上，项目管理能力，已经成为一项职场人士的必备技能。
+
+## 为什么要学习项目管理？
+
+当极客时间的总编邀请我来写项目管理专栏时，我不禁感叹：“一个程序员的项目管理化时代，已经来临了！”
+
+仔细想想，近一年来，在网易内部，程序员学习项目管理的热情也是水涨船高。为此我们专门开设了一个项目管理实战训练营，帮助程序员在实战中操练。这个训练营在网易内部拥有很好的口碑，深受广大程序员的喜爱。
+
+那么，为什么这么多程序员要学习项目管理呢？
+
+通常来讲，程序员精进的道路大概有两条：一条是走个人能力线，成为技术专家；另一条是借助团队能力往前走，成为技术管理者或业务管理者，只是这条路上的管理岗位是需要时机和坑位的，可遇不可求。
+
+但是，项目管理则很不同，只要你在一个多人协作的团队，就一定会有项目管理的需求和机会。蓬勃兴起的项目管理学习热潮，为程序员开辟出第三条精进之路。
+
+而且，不同于技术管理，这条路线走起来，几乎不需要任何外界依赖因素。一开始你甚至并不需要有组织的明确授权，你只需要在做好自己的基础上，学会更多的项目管理技能和方法，以项目整体目标为己任，主动操心和解决项目团队的问题，帮助团队做得更好就可以了。如果你这么做了，你的leader一定会很开心，你的技术之路也会越走越宽广。
+
+实际上，我身边的很多技术管理者，都非常希望自己团队的程序员能够具备项目管理的sense和能力。在网易，已经有越来越多的主程开始承担项目管理职责，在他们的绩效考核中，也会明确写入一定比例的项目管理责任，这种类型的项目负责人已经逐渐成为组织中的中流砥柱。**具备项目管理能力的程序员，无疑会在这个程序员严重同质化的局面下，拥有更多的竞争优势**。
+
+**除此之外，我认为，项目管理是新一代“进化型”程序员的重要底层能力。**
+
+因为说到底，项目管理是一种组织整合能力。在传统的组织模式下，作为程序员，你只需要做好组织中的“螺丝钉”就好了。但超级个体时代的来临，会让项目管理这种组织能力，逐渐迁移到每一个个体身上，成为个体底层能力中全新的扩展接口。
+
+优秀的程序员都很擅长与机器和代码打交道，但是，当场景扩展到需要通过团队去拿到项目结果时，对技术的高度关注，缺乏专业的方法和工具，以及不擅长沟通协作等，会让程序员遭遇到各种团队问题，很难发挥各个角色的协同整合作用，以实现真正的闭环。
+
+想要让你的成果真正转化为对用户或客户有价值的产出，这是一个复杂的系统工程。而项目管理的思维和方法，构建出了一套多人协同的底层操作系统，是你从个体走向团队，必须具备的底层能力升级包。如果你能比别人更早地意识到这一点，你就已经走在了很多人的前面。
+
+## 如何有效地学习项目管理？
+
+那么，如果你真的想要学习项目管理，该从哪里开始呢？
+
+项目管理作为一门学科，经过多年发展已经呈现出庞大的知识体系，光国际标准就有三套。就拿国内普及度最高的PMI标准体系来说，它将项目管理分为十大知识领域和五大过程组，共有49个子过程，600多页内容。对于很多初学者来说，实战经验缺乏，书本知识会显得愈发晦涩难懂。
+
+不是所有人都可以很幸运，能在关键成长期遇到师傅的引导。如果你完全依靠自己去摸索，要么在实践中撞得“头破血流”，要么迷失在大部头理论的海洋中，无法快速找到真正有效的解决之道。
+
+八年的互联网项目管理实践下来，我越来越觉得，项目管理是科学、艺术的结合体，同时也是一门手艺。只有经过实践操作的磨砺，你才能真正掌握使用所有框架、方法和工具的正确时机和火候。
+
+我们借用“体机用”的模型来看，“体”是本体，对应于项目管理的知识体系，比如《项目管理知识体系指南》；“用”是效用，对应于各种纷繁复杂的项目管理实践，比如某某公司的项目管理做法。这些都是可描述、可传授的，市面上你很容易可以找到相应的资料。
+
+但是，这些内容都无法真正满足实战中多样化的学习需求。项目管理作为一门实践科学，最难掌握的，其实是“体机用”的这个“机”。这里说的“机”不光指时机，同时还意味着环境和条件，也就是说将知识技能和具体的“场景”相结合，才能发挥出真正的效用。
+
+作为在项目管理领域磨砺了八年的“手艺人”，我深知，**对“机”的把握是一种非常稀缺且不可替代的能力，这也是我非常想要在专栏里传递给你的核心能力**。在网易长期对程序员进行项目管理实战培训的经历，让我积累出了一套真正着眼于实战“场景”的有效训练方法。
+
+为了让你快速地掌握项目管理这门手艺，我为你梳理了一条项目管理的最佳学习路径。
+
+专栏主要由3大模块组成：
+
+- 在第1模块“常识篇”，我会为你介绍一套最简易的项目管理知识框架，避免你在庞大的知识体系中迷失方向。另外，我还会给你介绍初做项目管理时的误区，以免你走弯路。
+- 在第2模块“硬技能篇”，我会给你展示一个项目的完整流程，结合网易互联网项目中的实战案例场景，详细介绍计划、变更、进展汇报、复盘收尾等过程中最高效的方法，分享给你一些项目管理的实用工具，让你能够迅速上手实践。
+- 在第3模块“软实力篇”，我会聊聊常见的多维度沟通和跨部门协作问题，基于非职权领导力的六力模型，让你学会快速汇集信息数据，定位底层问题，并撬动更大的资源支撑。另外，我还会为你介绍PMP认证攻略，让你在项目管理进阶之路上再往前走一步。
+
+<img src="https://static001.geekbang.org/resource/image/f7/e3/f7345d6e3225297fcd8dcad93732a7e3.jpg" alt="">
+
+## 如果我可以，你也一定行！
+
+很多人跟我说，希望在这个实战专栏中，多听听我在实践中走过的“坑”。我真的很想对这些朋友说：“那你真的是找对人了！”
+
+打从一开始，我就知道，自己并不是天生适合做项目经理的人。我内心敏感，胆子小，脸皮薄，不喜欢勉强别人，更不擅长当众发言。我自己也完全不敢想象，我会在项目经理这个岗位上，一干就是八年。
+
+刚刚从程序员转做项目经理时，每一天我都觉得自己来错了地方。我本来好好的写代码，什么都行的一个人，怎么突然变成了“说的话也没人听，推的事也没人做，哪哪都不行”的人了呢？
+
+现在回头去看时，我发现，这8八年时光，真的是宇宙给我的绝佳馈赠。我不仅学会了如此多样的“爬坑”技能，还学会了在各种充满限制的条件下，创造一切可能的条件，团结所有可以团结的力量，把每一个飘在空中的理想变成现实。
+
+虽然我是项目经理，但我却坚定地认为，**在一个组织中，项目经理并不是越多越好，而具备项目管理能力的人，却真的是越多越好**。人人都可以成为优秀的项目经理，**如果我可以，那么你也一定行！**
+
+最后，我想请你来聊一聊。如果你是刚刚接触项目管理，是什么让你对这个话题感兴趣呢？你对这个专栏会有什么样的期望？对于已经开始进行项目管理实践的同学，你最常遇到的问题或困惑是什么，想要自己在哪些方面有所加强？欢迎你畅所欲言，我在留言区等你！
+
+

极客时间专栏/项目管理实战20讲/特别加餐/特别加餐 ：“学习”到“实战”的距离，到底有多远？.md

@@ -0,0 +1,151 @@
+<audio id="audio" title="特别加餐 ：“学习”到“实战”的距离，到底有多远？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/89/46/89edbd580fe6906a04291489717b1746.mp3"></audio>
+
+你好，我是雷蓓蓓。
+
+经常有同学问我：“我学了很多项目管理知识，但是回到现实之后，我的项目中依然有很多问题，怎么办？”“我想要在实际工作中做好项目管理，可团队基础太差，领导又不在意，怎么办？”这些问题背后，总之就是一句话：“我……太……难……了！怎么办？”
+
+在回答这些问题之前，我先给你讲个真实的故事。
+
+## 当真有那么难吗？
+
+年初，陪娃钢琴考级的经历，让我对“难”这件事，有了新的认识。
+
+随着考级日期的临近，我的焦虑感日渐增强。本来标榜“不以娃考级为目的”的我，架不住培训机构的软磨硬泡，给他报了个考级班，一个号称“零基础也包过”的日本大师班。考级报名费才不到两百块钱，这个考级课就要两千，而且只有三节课，考不过退款。
+
+我不禁感到很好奇：“传说中的日本大师，到底会有什么神奇的学习方法呢？”
+
+第一节课，一个26岁的日本青年，慌慌张张地赶过来，连中国话都说不清楚，完全没看出什么特别之处。
+
+他一上来就花了好长时间讲钢琴的历史，接着就让每个孩子轮流唱谱，一人一句，孩子们唱得稀稀拉拉的。说实话，我真的很替这个老师着急。
+
+接下来，是20分钟的一对一辅导时间。轮到我家孩子由由的时候，他弹得磕磕绊绊的，而且在识谱方面，也很有问题。
+
+他弹了几句之后，老师示意他停下来。由由很委屈，毕竟，这曲子对他来说简直太……难……了。我当时就想，这首曲子我都学不会，我倒要看一下，日本大师怎么在这么短的时间，把一个6岁的孩子教会。
+
+老师看出了孩子内心的抗拒，他拿出白板，画了一个歪歪扭扭的小人，开始用他蹩脚的中文，一边比划，一边真诚地讲：“你刚刚学走路的时候，每走出去一步，都觉得很难，对不对？那么，现在，你还觉得走路很难吗？”他来回走了几步，由由摇了摇头。
+
+他继续说：“你看，路要一步一步走，弹钢琴也是一样，要一个小节、一个小节地弹。今天，我们不用做很多，只要把一个小节弹会就行了，你觉得可以做到吗？”
+
+在获得了内心的认同之后，由由的压力显然减轻了很多，他很认真地配合着老师，反复地练习同一个小节。
+
+20分钟很快到了，我们还在第一个小节打转，我就又开始着急了……
+
+下课时，老师特意跑出来嘱咐我：“由由今天的状态不太好，回去一定不要再让他练了。下周，由由要每天先唱10遍，再左右手各弹10遍，先不要着急合手。相信我，**不要弹得更多，也不需要更多了**。”我心中虽然很怀疑这种做法的效果，但因为钱已经出了，还是严格按照这个“药方”来吧。
+
+在半信半疑之间，我们每天都坚持唱够次数，练够次数。三节课下来，刚开始连两个小节都合不起来的由由，最后竟然顺利考过了！真是让人难以置信。于是，这位26岁的日本大师，就成了我心中为数不多的、堪称大师的人。
+
+## 大师创造的“四步学习法”
+
+从那之后，我一直在琢磨，为什么钢琴班的其他辅导老师只能叫老师，而他年纪轻轻的，却可以被称为“大师”？大师创造的高效学习方法，到底有什么神奇之处呢？我总结了一下，大抵有几点，我来跟你一一分享一下。
+
+**1.破除“魔”障。**
+
+大师不仅教会了我们弹琴的技法，还改变了我们对“难”的定义。
+
+考级曲目难吗？难！就拿《康定情歌》来说，不仅双手不同旋律，而且左右手要依次层叠展开，就连我这个自小有些钢琴功底的，看了谱子之后，都心生畏惧。但一个6岁的孩子，最终却可以弹得行云流水般流畅。
+
+那么，是什么限制了我们，走向更大的可能性？
+
+爱迪生在成功发明灯泡之前，尝试过2000多次。有人问他，失败了那么多次，感受如何？爱迪生霸气回应，**我从没有觉得失败，因为我找到了2000多种不能做成灯泡的方法**！所以，你看，我们和爱迪生的差别，始于我们对失败的定义。
+
+**所以，要留心你的定义**！不只是对失败的定义，你还要留心自己对困难的定义，对问题的定义，对理想环境的定义……**这些定义决定了你的体验，以及你下一步的行动**。
+
+如果你认为，只有在一线城市的所谓一线大公司，在没有那么多复杂关系的“理想”环境里，才能开展工作，那么，你将永远无法真正地开始。即便你有一天来了网易，你对于问题的错误定义，也会让你不断地看到各式各样的问题，遭遇各种各样的困难。
+
+**要想前进，你就必须先破除“魔”障。别让你的定义，限制了你的可能性**。
+
+**2.每次一小步。**
+
+大师永远只是站在离你一步之遥的前方，帮你建立信心，和你一起前进。普通老师越是碰到难教的孩子，越会急于一步到位，想快速地把他教会，恨不得把全部技法都传授给他。结果，越急，效果越差，老师也很受挫。
+
+大师却完全没有这个负担。他无视在外面排队的焦躁人群，只是全情投入于眼前的孩子，尊重孩子现在的样子。
+
+他知道，每个孩子都是创造力的天才，而他自己最需要做的，就是去到孩子当前所在的那个地方，理解他的处境，然后带着他往前迈一小步。**仅仅只是，迈好一小步**。
+
+实际上，如果你把谱子上的每个小节拆开，分步骤去看，你会发现，其实每一步都简单无比。弹钢琴如此，做项目管理也是如此。
+
+十大领域五大过程组，看起来很繁杂，但是，如果你把它们分解开，并且结合我在专栏中介绍的每一个方法去看，每一步都很简单。
+
+比如，如果你尝试了我在[第5讲](https://time.geekbang.org/column/article/162272)中为你分解的做计划的五个步骤，你会发现，做计划并不是一件复杂的事情。
+
+每次一小步，你一定可以做得到！
+
+**3.先找找“感觉”。**
+
+在弹琴之前，为啥一定要先唱10遍呢？实际上，大师是在帮孩子创造一种感觉记忆，让这种感觉来引导他的大脑和动作。每天反复唱10遍之后，这个旋律，就好像已经刻录进他的深层意识了。再去弹的时候，他的手指几乎是下意识地去跟随和重现这个声音记忆，比起直接生硬地啃谱练习，高效了很多倍。
+
+**这就是形象化的感知觉在学习中的运用**。
+
+我在专栏中的每一讲中，都会不遗余力地给你分享很多真实的故事和案例。为什么要分享这些呢？这不是为了说明我经验有多丰富，而是为了给你创造一种体感，让你能够在尝试之前，先去感受一下，这件事情如果做成了，会是什么样子？
+
+如果你在学习某一讲时产生了共鸣，那么，接下来你需要做的，**就是多看几遍，多听几遍，把那种事情已然成真的喜悦和满足感，刻录在心里**。
+
+然后，**试着和自己的经验相关联，在大脑中想象自己已经做到这些的样子，越清晰越好**。最后，你要把这个视觉化的影像记录下来。
+
+这份经过你自己转码后的影像和感觉记忆，会带你突破层层的限制和困难，完成你所需要的无数次练习。
+
+**4.“足”量的刻意练习。**
+
+你看，即便有了再好的大师，要想学会钢琴，仍然需要你自己每天练够10遍，不是吗？
+
+学习是一件需要互动才能产生效果的事。作为学习者，你最需要做的是什么呢？答案就是，**每天“足”量的刻意练习**。
+
+“足”量意味着不多不少，少了达不到效果，多了呢，太过紧张用力，特别想要一步登天，反而会产生反效果，破坏你自然的学习进程。
+
+我在第1讲中说过，程序员转做项目管理，就像是右手习惯转成左手习惯，这种模式转换，需要大量的刻意练习，才能完成。
+
+为什么这么说呢？在《网球的内心游戏》这本书里，网球的大师级教练就描述过刻意练习。他认为，神经系统就好比是一个光盘，第一次在行动时，在大脑的微观细胞上，会留下轻微的印象。这就像一叶微风，正吹在沙滩上，一个细小沙子即将离开时，留下的微弱痕迹。当同一次行动被重复时，凹痕就会变深一点。之后，很多相似的行为，使得行为针，自动地掉进一条更清晰可辨的凹线。这时，新的行为就在潜意识里定型了。
+
+项目管理是实战中的学问，要想获得真正的实战效果，你就需要**通过行动，反复加深神经系统中的凹痕，直到新的行为，巩固成为新的模式**。
+
+在现实生活中，不是每个人都可以找到真正的大师，接受大师的近距离指导。但是，你可以做到的是，**按照大师传授的方法来学习**。
+
+## 实战中的刻意练习
+
+为此，结合专栏的内容，我为你特别设计了一条刻意学习的路径，你可以按照下面的方式，来开展自己的练习。
+
+**1.破除“魔”障**
+
+**找到你心中阻碍你进一步实践的声音，并且直面这些声音**。
+
+比如，“我做的很多事情，领导并不在意，这些事情有什么用？”“我做得再好，别人都不这么干，又有什么用呢？”
+
+相信我，我太了解这种状态了！因为曾经我也和你想得一样。那时，我自告奋勇，离开了我熟悉的项目环境，到一个从上到下几乎是零基础的业务团队，去推广项目管理。我在那里努力了半年，但不管我怎么尝试，都没有任何人在意，我到底做了些什么。
+
+我一度也真的想过放弃，但是我当时的Leader说了一句话，我至今都印象深刻。她说：“**如果万事俱备，还要你干吗？**”
+
+两年之后，我帮助这个几百人的团队完成敏捷转型，同时培养出了好多位合格的Scrum Master，获得了团队上下的一致认可。
+
+难吗？没做的时候，真的觉得很难，但做了之后，再回过头去看，又觉得其实也没啥。要想学有所成，真正带来改变，首先要破的“魔”障，不在别处，在你自己心里。
+
+**2.每次一小步**
+
+引入一个小小的变化，小到你可以完全靠自己的力量做到的变化。比如，写好一份表意清晰的周报，主持好工作中的一个小会……别忘了，在这个变化成真以后，要给自己鼓励和认可！
+
+**3.先找找“感觉”**
+
+每天，找一篇你最有感觉的专栏文章，反复学习5遍，加深感觉记忆，直到你可以形成清晰的视觉化影像，甚至看见自己成功的样子。
+
+**4.“足”量的刻意练习**
+
+你要在自己的环境中，每天持续展开行动。随着实践落地的深入，逐渐加大难度，从开好一个周会，再到设计一个复盘会，从做好WBS工作分解，再到做好整个项目的里程碑规划，开一个成功的启动会。
+
+同时，在实践中遇到阻力的时候，就返回第1步，找出阻碍你进一步行动的真正原因，然后定位出下一个你自己就可以引入的小小变化，不断重复这个过程。
+
+## 总结
+
+今天，我从一个学钢琴的故事讲起，给你分享了我对大师级高效学习方法的四个认知，从破除“魔”障，每次一小步，再到找着“感觉”，并进行“足”量的刻意练习。
+
+孔子说，学而时习之，不亦说乎。小时候，我经常纳闷，学习完了，还要经常复习，这有什么可高兴的呢？后来我才知道，其实，这个习，不是指复习，而是实践；时习之，就是找到合适的时机去实践。你看，孔老夫子也认为，学习了新知，又能找到合适的时机，去付诸实践，这真的是件快乐的事哪！
+
+项目管理的学习，必须植根于实践，落地于实践。那么，“学习”和“实战”的距离，到底有多远呢？
+
+答案可以是很远，因为中间隔着10000小时的刻意练习，你才能从一个学习者，变成身经百战的实战专家。然而，“学”和“习”之间，也可以很近。你只需要把自己的所学，找到一个合适的时机去实践，通过你的行动，真正解决掉一个实际问题。那么，孔子所说的快乐，只需一秒即可到达。
+
+## 畅所欲言
+
+我发现，有很多同学一直在跟着专栏学习，但从来没有留过言。下一讲，我们即将进入“软实力篇”，我会重点讲一讲项目中的各类沟通。项目经理有80%的时间都在进行沟通，那么，我想请你来聊一聊，关于沟通，你最关心什么？你有什么困惑吗？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/用户故事/用户故事 | 小文同学：我想从头到尾把事情做成.md

@@ -0,0 +1,78 @@
+<audio id="audio" title="用户故事 | 小文同学：我想从头到尾把事情做成" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fe/c1/fe194febba9d02dcfafc8b2020a2d5c1.mp3"></audio>
+
+你好，我是雷蓓蓓。在这里，首先我要感恩在疫情中仍然坚持认真学习的你，好久不见，非常想念！
+
+在专栏完结以后，我很想了解我的课程对同学们都有哪些帮助。于是，极客时间帮我邀请了一些同学分享自己的学习故事。今天，我想跟你分享一篇小文同学的故事。小文同学在他的文章里，非常坦诚地记录了他的真实学习经历，一下子把我拉回到了阔别已久的录音笔前。
+
+我在专栏结束语中说过，从程序员转做项目管理，只是因为，我想从头到尾把事做成。Wuli小文同学，每次听课都特别认真，无疑是抓到了精髓。他说，**只具备技术上的积累，很多时候并不能把一件事做成。技术积累就像做加法，而一边做技术一边了解项目管理就像做乘法**。下面，我们一起来看看他的学习收获吧。
+
+**　**
+
+Hi，我是小文同学，一名Java工程师，坐标广州，在一家游戏公司工作快四年了。
+
+我应该算是极客时间最早的一批用户了。可以说，我见证了极客时间从最初的几个专栏到内容不断丰富的发展过程，也可以说，极客时间这个 App 陪伴我度过了初入职场的关键三年。
+
+从2017年开始，我成为了技术负责人，2018年上司离开，我被迫独自面对项目里的技术问题，再到2019年，我开始作为主程研发新项目，这一路走得并不顺利。如果没有极客时间的老师们在知识上的支持，我或许早就已经因为各种困难中途放弃了。所以，这些年，在工作上，除了感谢上司的培养外，就是要感谢极客时间的老师们了，他们的一篇篇文章让我有足够的知识和能力去抓住工作中的机会。
+
+担任新项目的主程是我在2019年遇到的最大挑战。在研发的过程中，项目出现了各种各样的难题，除了技术上的难题，最难的就是解决项目进度和协作等非技术问题。
+
+项目在导用户内测时，很多潜在的问题都暴露了出来，比如说，产品提的需求经常被技术误解，测试的 Bug 跟踪不到位导致修复进度慢，开会时常常只有讨论没有结论……面对这些问题，大家特别像热锅上的蚂蚁，忙得焦头烂额，但却不知所措。那个时候，我每天除了匆匆忙忙地补“锅”之外，就是不停地思考项目的核心问题到底出在了哪里。之前我百思不得其解，直到遇见了雷蓓蓓老师的“项目管理”专栏，我才对项目内部的底层问题有了新的认识。
+
+现在，极客时间的专栏推出得非常快，以致于我都没注意到这个专栏的上线。在我意识到项目管理出现问题的时候，专栏已经更新十来讲了。不过我刚开始订阅专栏的时候，其实并不指望专栏会解决我遇到的问题，我只是希望借专栏的专业知识分析眼下项目的病症所在。
+
+结果，我在阅读第一篇文章《角色转换：程序员做项目管理的三大误区》的时候，就醍醐灌顶，当天我就根据文章里的“三个误区”认认真真地反思了自己的不足。从留言区也不难看出，这篇文章戳到了很多同学的痛点。我有预感，我能在这个专栏里逐步剖析甚至解决自己项目的问题。
+
+## 我是怎么学习专栏的？
+
+有些技术性很强的专栏我会在通勤的时候听，但是在学习《项目管理实战20讲》专栏的时候，我会非常认真地准备好一切，并且确保自己有一个小时以上的空闲时间。我通常会在下班后带上电脑去图书馆或者咖啡厅学习。
+
+不得不说，一些专栏的文章只读一遍是不够的，比如“十大领域五大过程组”这两篇文章可以算是框架级别的内容了，不认真阅读的话，是很难串联起后面的知识的。
+
+项目管理是一个体系的课程，它不同于修 Bug ，找到问题的时候就是解决它的时候，项目管理的学习、项目问题的剖析和修复，都是需要耐心的，这是一个理论、思考和实践都不可缺少的过程。
+
+我认为，阅读专栏文章最好的办法，就是**把自己的项目代入老师的文章中，一边阅读，一边思考团队中的人员分别属于文章提到的哪些角色、自己处在哪个位置，等等**。
+
+在学习“项目管理”专栏的时候，我一般会打开音频（蓓蓓老师的声音非常好听)，对照着文字逐行去读。我会带着自己对当前项目的理解，仿佛老师马上就要剖析自己的项目那样去阅读和聆听，这样就很容易在普普通通的一段话中，发现和自己的项目相契合的问题。这时候，我一般会暂停下来，选定文字，把引起我共鸣的地方写下来，顺便做些分析。在遇到有感觉的内容、但没办法用语言表达清楚的时候，我就划线标注，如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/f2/f4/f2ad2ca0df754ed13c53b3cfefe280f4.png" alt=""><br>
+<img src="https://static001.geekbang.org/resource/image/5f/56/5f6aa62cc305eb384c8663f128243656.png" alt="">
+
+这种阅读方式可能比较苛刻，要全神贯注。但是，每读完一篇文章，我都能发现我们项目的一些潜在问题。最重要的是，蓓蓓老师在分析完问题之后，往往还会给出一些建议，这些建议帮我解决了很多痛点问题。
+
+## 学习专栏有什么收获？
+
+之前，我听过一个观点，大概意思是说，如果一个程序员选择了专攻技术路线，目标是成为一个能解决所有问题的技术专家，他就不需要关注项目管理方面的知识和积累了，可以独来独往，不受公司规则的约束。我刚毕业的时候也多少有点认同这种观点，甚至很仰慕那些技术专家。
+
+以往我订阅的专栏和阅读的书籍一直以硬技术为主，比如Java、算法、计算机网络等，这些知识可以让我稳扎稳打地解决技术上的一个个难题。但是，当我需要承担一个项目的时候，我发现，**只具备技术上的积累，很多时候并不能把一件事做成。**随着自己专业技术的进步，下意识地提升技术以外的软实力，变得越来越重要。这就类似于我们必须用两条腿走路，才能走得又快又稳。
+
+打个不完全恰当的比喻，**技术积累就像做加法，而一边做技术一边了解项目管理就像做乘法。**一个技术人员在拥有深厚的技术积累的同时，能够兼顾一些项目管理工作或者是具备项目管理意识，团队的协作就会更加顺利，自己的技术也可以更好地落地在项目中，技术的价值也会因此大大增加。我所熟知的架构师、技术专家们除了有深厚的技术积累外，大多数在软实力上也都非常出色，尤其是项目管理能力。
+
+读完专栏，我的直观感受是，**虽然不是每一个程序员都要管理项目，但每个程序员都需要懂得项目管理**。我之前算是一个不爱开会的程序员，对于很多项目问题，我都执着于用更好的代码去解决，因此我们团队也很少开会，往往到事情比较严重的时候，我们才会开会，想办法补救。
+
+说到这儿，我很想跟你分享一个我的故事。
+
+在阅读《高效会议: 项目中要开好哪些会?》之前，我们项目内部因为会议过少造成的沟通缺失问题就像推倒的“多米诺骨牌”一样，接二连三地引发了很多新问题。程序员思维让我一直觉得需要用新的工具和技术去解决问题，但在阅读文章之后，我才明白，我需要学习的不是新工具，而是开会的技巧。
+
+在看蓓蓓老师对不同会议的分析时，我经常因为之前思维的固化而感到愧疚，又为不同会议的不同效果而感到震撼。我发现，**能够掌握会议技巧和有效地召开或参与会议，其作用力绝不亚于学会一个高端的技术框架**。学技术框架是一个漫长的过程，而培养高效的会议意识却是现在就可以做到的事情。
+
+我记得，那个时候，我很快就在项目组分别召开了部门负责人会议和技术团队会议。我按照专栏的讲解为两个会议做好了准备。在开会的过程中，我最大的感触是，很多问题单靠自己钻研琢磨是很难解决的，但在开会的过程中，大家一起讨论，问题很容易就会迎刃而解。
+
+会议模块是我通过专栏知识着手优化项目的开始，没过多久，我就看到了成效。紧接着，在一次会议中，我根据《质量管理：一次把事情做对》这篇文章里提到的优化项目版本质量的办法，给我们的项目提出了一些监控的措施。
+
+我的措施并没有立竿见影的效果，毕竟，版本质量的提升不是一蹴而就的事情。但是，因为建立了一套改善版本质量的流程，项目组中的各个同学在面对Bug时都更有信心了。我也相信，我们的版本质量会越来越好。现在，我非常期待继续把专栏中的经验应用到我们团队的项目中。
+
+## 总结
+
+在专栏的结束语中，雷蓓蓓老师写道：“**因为我想从头到尾把事做成。**”我对这句话的印象格外深刻。但凡决定开始做的事情，我也希望都可以做成。
+
+项目在研发过程中确实遭遇过不少困难，甚至有的同学不看好这个项目，于是就选择离开了，我自己一度也非常沮丧。我至今都非常感谢遇到蓓蓓老师，她的专栏给了我不少新的思路，让我重新梳理了项目的问题，确立了中短期的项目目标，我自己也做好了持续精进的准备。我很希望自己的项目管理能力能够不断提升，也希望我能把越来越多的事情从头到尾做成！
+
+**　**
+
+正如小文同学所说，专栏的文章只读一遍是不够的！项目管理是一个体系化的实战课程，你需要先了解整个知识框架，然后把自己的项目代入到专栏文章中，一边阅读一边结合实践思考，逐步剖析并解决项目中的实际问题，这才是实战型专栏的正确打开方式。
+
+感谢极客时间，把我从一个实战中的学习者变成了一个老师。作为一个初出茅庐的“老师”，遇到爱学习的你，有机会分享我的实践心得，我特别得感恩。尤其是当我看到这样一个专栏，能够让人在繁忙工作之余，回到在图书馆学习的状态，一点一滴地从头学习“如何开好一个会，如何做好一个计划…”想到这些实战中带来的变化，我特别得满足。
+
+作为一个学习者，主动学习的最高境界，就是像小文同学这样，能够把自己的学习实践所得讲给别人听。还记得我们的加餐题目吗？“‘学习’到‘实战’的距离，到底有多远？”你，还差一篇用户故事。欢迎你也分享一下你和项目管理的故事。
+
+如果小文可以，你也一定行！

极客时间专栏/项目管理实战20讲/硬技能篇/04 | 启动：识别项目中的四类干系人.md

@@ -0,0 +1,93 @@
+<audio id="audio" title="04 | 启动：识别项目中的四类干系人" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/25/e8/2530146e34d1c07f4fe1d4d27bc2aae8.mp3"></audio>
+
+你好，我是雷蓓蓓。今天是硬技能篇的第一讲，主题是识别项目中的四类干系人。
+
+所谓万事开头难，一个项目刚刚启动的时候，往往是各种混乱夹杂在一起。如果没有经过专业培训，只是凭着一腔热情，一头扎进文山会海之中，那么很可能你做得越久，就会遇到越多的困难，也会越发困惑。
+
+其实，要想在混乱中快速建立秩序，是有章法可循的。今天，我就从最初的一环开始分解。在一个新项目刚刚启动时，干系人分析，可以说是最容易被漏掉的一个重要环节。
+
+干系人分析，是指对项目干系人进行分析和归类，有针对性地规划管理其核心诉求和期望，让干系人可以更好地参与项目，对项目产生积极影响，从而更好地保障项目目标的成功达成。
+
+干系人分析的目的是什么呢？毛主席说过这样一句话：“要把拥护我们的人搞得多多的，把反对我们的人搞得少少的。”干革命如此，做项目也是同样！作为项目管理人员，你需要通过积极的干系人管理，尽可能把反对的力量变成支持的力量，同时发掘和调动中间力量。这样一来，项目才会越做越省力。
+
+<img src="https://static001.geekbang.org/resource/image/6e/97/6ebb1c2aacc4b0d832a391fa61297f97.jpg" alt="">
+
+为了做到这一点，你需要深入了解项目的现状以及各方干系人对项目的期望和诉求，因地制宜地采取相应的策略，才能够做到有的放矢。
+
+如果按照在项目上的权力和利益相关度对干系人进行划分，可以把项目干系人分成四类：高利益-高权力，高利益-低权力，低利益-高权力，低利益-低权力。为了方便你更直观地理解干系人的类别，我给你分享一张干系人的四象限分类图。接下来，我会结合这四类干系人，为你讲解各个象限的应对之道。
+
+<img src="https://static001.geekbang.org/resource/image/95/61/952fa4513faa5f1ec123d4921f86ed61.jpg" alt="">
+
+## “高利益-高权力”代表：项目发起人
+
+《项目管理知识体系指南》把项目发起人称为Sponsor，即项目资助人。项目发起人会定义组织对项目的需求，为项目提供资金支持，并进行人员配备。一般来说，项目发起人天然会成为你强有力的支持者，你需要重点管理。
+
+实际上，了解发起人对项目的真正诉求，对项目的成功至关重要。有很多项目经理只知道保质保量地完成项目是最重要的，却从来没问过发起人，这个项目真正要的是什么。我曾见过很多看上去执行得还挺顺利的项目，中途却突然被撤消，大多是因为没有搞清楚这个项目会为组织带来什么，以及组织对项目成功的定义是什么。
+
+你要知道，发起人所掌握的项目背景信息量肯定比你要大，所以，对发起人做一轮全面而深入的了解，是非常有必要的。我为你精心准备了一个问题列表，你可以找发起人好好聊一聊这些问题。
+
+<img src="https://static001.geekbang.org/resource/image/df/ce/dffb7a0311faefa4814079d6219c2ece.jpg" alt="">
+
+在这个列表里，有一些问题你需要重点跟项目发起人进行沟通。比如，他发起这个项目的背景和初衷是什么？如何才能知道我们做到了？哪些资源是项目获得成功的关键？他最看重项目的哪些要素？是进度、质量、成本还是范围？在极端情况下，我们该如何对这些要素进行排序呢？
+
+即便你的项目已经开始了，你也可以参照这个列表，问问自己是否知道这些问题的答案。需要注意的是，对于你不太确定的地方，特别是我用红色标注的这些问题，不要自认为发起人的想法和你的想法是一致的，你不妨找他当面确认下。
+
+**同时，为了管理好之后的沟通，你还需要约定好你们之间的沟通频率和方式，以便在项目进行的过程中做好实时同步**。比如，可以是每周用邮件同步项目的进展及风险问题、建立核心微信群实时交流、每个月至少进行一次深入面谈等。或者，你们只是简单地达成约定：在你需要支持的时候，随时发起，当日问题当日解决，这也是可以的。
+
+## “低利益-高权力”代表：职能经理
+
+在矩阵式组织结构中，职能经理是资源池的所有者，他们所管辖的团队通常覆盖多个项目或项目群，这也使得他们与单个项目的利益相关度通常比较低，介入程度往往也很有限。但是，因为他们对资源的把控力很强，如果管理不好这类干系人，你的项目资源就很容易受到影响。
+
+我曾经就碰到过这样的情况。有段时间，团队一再跟我抱怨，这个项目中的设计资源成了最大的瓶颈，于是我决定去拜访一下那位传说中性格乖张、超难合作的设计经理。
+
+见面后的前半个小时，他一直在跟我抱怨：“项目进度压得太紧，我的很多设计师都累病了；产品和开发对设计师们太不友好了，产品没有经验，连需求都说不清楚；开发实现得还原度太低，问题一箩筐……”
+
+我没有反驳他，而是把他的话一条条地记录了下来。半个小时之后，我给他看我记的内容，耐心地跟他一一确认，他想要表达的是不是我所记录的意思。看到我认真的笔记，他的态度明显缓和了。
+
+经过一番梳理，我发现，他之所以排斥这个项目，是因为他觉得在这个项目中，设计师没有太多发挥的空间。于是，我问他：“咱们设计团队今年最想做的事是什么？这个项目怎样才能更好地支持你和你的团队呢？”这个问题瞬间打开了他的话匣子，他兴致高昂地跟我描绘了他的期望。这次交流，让我们找到了更多深度契合的合作点。
+
+随着合作的深入，这位经理从一个抵制者慢慢变成了项目的坚定支持者。他调动了资深的设计师来支持这个项目，并且主动发起了Logo和界面主风格改版的创意评选活动，把项目的设计品质提升了一大截，这给项目组带来了非常正向的影响。
+
+所有你看，要想让干系人的态度发生转变，最重要的就是弄清楚他抵制的原因。强烈的态度背后，一定反映了干系人对现状的某种认知，比如，这位设计经理抱怨的“这个项目没有太多设计师可以发挥的空间”，这种认知未必是事实，但你一定不要急于反驳，而是不带评判地去了解他的内心想法，通过积极聆听去建立信任。只有真正地理解了对方的逻辑，才有可能进一步对其施加影响。
+
+总体来看，根据对项目的认知态度，我们还可以把“低利益-高权力”的干系人再细分成以下3类，进行差异化管理。
+
+<img src="https://static001.geekbang.org/resource/image/19/3d/19fcdf9443a976cd0c693412d716b83d.jpg" alt="">
+
+1. 反对者（红色部分）：反对者是最难处理的一类，就像刚刚案例中展示的那样，管理这类人的重点在于建立信任，化解敌意。如果你实在无法争取他们的支持，至少要让他们保持中立，以免对其他成员造成负面影响。
+1. 支持者（绿色部分）：支持者是项目获得成功非常需要依赖的力量。管理这类人的重点是，首先你要明确地知道，他们各自对项目不同的期望和诉求，然后有意识地创造更多的空间和机会，让他们能够深度参与到这个项目的决策或创意环节。这样可以增强他们的主人翁意识，也会给整个项目组带来最大的收益。
+1. 中立者（灰色部分）：对待这类人，总体原则就是，在条件合适时，进一步将其转化为支持力量。但如果你精力有限，可以先不管。
+
+如果你想对这类干系人有进一步的了解，我再给你分享一个问题列表，你要重点关注一下我标为红色的部分。
+
+<img src="https://static001.geekbang.org/resource/image/65/6e/65d87f32dc4efe9676c7a8854324566e.jpg" alt="">
+
+## “高利益-低权力”代表：项目组成员
+
+这是与项目结果直接相关、但对决策影响不大的一类人，广大的项目组成员就属于这个象限的典型代表。你可以借助三类问题，了解流程的基本情况和成员的信息诉求。
+
+<img src="https://static001.geekbang.org/resource/image/bb/b6/bbd61a148eb7622403187e3911eb0bb6.jpg" alt="">
+
+这些问题可以帮你了解项目的规划和实施过程，找出那些没有做到位的地方，弄清楚项目组成员当前最希望通过项目管理看到的变化。这些痛点和渴望，会成为你在团队中促发改变的有力抓手，帮助你找准突破点，集中发力。
+
+有位创业团队的同学给我留言说，他认为，现在团队扩大之后，最大的痛点就是开发流程不规范，但是却得不到老板的重视。那么在这种情况下，对项目组成员的访谈或集体复盘，就是很有效的方法。你可以让更多完善改进的声音和力量汇聚起来，这样一来，就能争取到更多的关注和资源支持。
+
+**管理这类干系人的核心，就是要做到项目事项的随时告知，及时通报项目的进展和困难**。在专栏的第7讲中，我会分享给你进展同步的方法，教你学会用数据说话。
+
+## “低利益-低权力”代表：外围支持人员
+
+我们通常会把一些复杂度低而且非核心的工作，转交给外围支持人员，比如，设计外包、技术外包人员等。在不影响项目的前提下，你可以花最小的力气对他们进行监督。比如，你可以跟他们提前约定好，每天或者每周进展汇报的格式和内容，确保他们的工作职责和任务明确，进展符合预期就可以了。
+
+## 总结
+
+今天，我主要介绍了启动过程中的一项重要活动，叫作识别项目干系人。四象限的干系人分析法，就相当于一个指导原则，可以帮助你明确地管理每一类人的预期。不管你的项目是否已经在进行中，我都建议你对典型的干系人进行分类和访谈，深入地了解干系人的核心诉求（重点关注哪些，对项目有哪些预期），从而制定出合理的干系人沟通管理计划（包括频率、方式、内容）。
+
+## 畅所欲言
+
+请你结合自己的项目情况，制作一份干系人分析表。另外，请你谈一谈，针对每一类干系人，你的管理策略是什么？
+
+<img src="https://static001.geekbang.org/resource/image/17/c5/17758e36defc2dadd499d2e265fad6c5.jpg" alt="">
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/硬技能篇/05 | 规划：排除计划中的“延期地雷”.md

@@ -0,0 +1,129 @@
+<audio id="audio" title="05 | 规划：排除计划中的“延期地雷”" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/80/af/808cc26ac2483abef239492c6b9b7daf.mp3"></audio>
+
+你好，我是雷蓓蓓。今天，我们来聊一聊如何排除计划中的“延期地雷”。
+
+我发现，有很多程序员是根本不做估算的。原因有很多，但总体来说，可以归结为一个：**嫌麻烦**。我的一个程序员朋友曾经跟我说过这样一段话：“我们是创业团队，领导一拍脑袋给个deadline，时间差不多了我们就开干。如果到时候上不了线，我们就再加班呗！反正计划都是倒排的，估不估工作量，问题不大。”
+
+这种现象很普遍，那么，为啥一定要做计划呢？
+
+在项目管理中，**计划是贯穿始终的重要课题，是各个角色协同工作的基准**。程序员在做项目管理的时候，会有个特别明显的优势，就是对项目中涉及到的架构设计、技术难点等问题，有着非常深刻的理解，因此，你对技术类风险会有更高的把控力。
+
+但是，你还需要学习的是，从全局的视角出发，去推进项目整体目标的落地，优化各个角色的协同过程。作为项目经理，你要**利用一切可以利用的资源、尽自己最大的努力达成项目目标**，而计划是你可以借助的重要工具。
+
+那么，计划到底是什么？计划是用来做什么的呢？
+
+实际上，计划是“市场需求或发起人的期望”和“团队生产力”之间平衡的结果。**从本质上来讲，计划是用来对焦的！做计划，是个集体对焦的过程**。如果我们省去对焦的步骤，就会给后续的执行工作埋下很多“地雷”。在执行过程中，这些“地雷”一旦被引爆，就会把我们的项目拖向失控的深渊。
+
+## 扫雷游戏
+
+我们都知道，好的计划是成功的开始。但是，在做计划时，我们很容易遭遇一些雷区，下面我们就一起来玩一个“扫雷游戏”。
+
+我有个程序员朋友小勤，她升任项目负责人之后，在工作中突然多了很多困惑，尤其是在做计划时，她遇到了很多问题。现在，我就带你来看看她在做计划时遇到的典型问题。
+
+这些问题涉及五大常见雷区，希望通过这些讨论，你能对导致计划失败的这五大雷区有更深刻的理解，提早规避。
+
+### 雷区1：不够具体
+
+小勤的第一版计划是这样的：
+
+> 
+网课2.0升级项目计划于9月18日提测，10月1日正式上线。
+
+
+你可能会说，这也太简单了吧？实际上，在程序员自己管理的项目中，这种“一句话式”的计划是很常见的。这份计划规定了提测和上线时间，也算是有了基本的约定。
+
+但是，你还记得我们刚刚对计划的定义吗？计划是一种集体对焦的方式。**好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦。**
+
+这里需要引入一个概念，叫作**WBS工作分解（Work Breakdown Structure），这是我们做计划的第一个标准动作**。
+
+作为一个描述思路的规划和设计工具，WBS可以清晰地表示各项目工作之间的相互联系，帮助团队更高效地管理项目。
+
+WBS是项目管理领域非常重要的方法。**创建WBS的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程**。
+
+简单来说，WBS就是“把大象放进冰箱”的过程，在做计划的时候，我们要把“大象”，也就是我们要做的这件事情真正拆解开，明确要分成多少块工作内容，涉及哪些角色和哪些环节的工作项，你需要将工作项拆解到3个工作日以内，每项任务都对应到个人。
+
+在跟小勤沟通好WBS之后，她很认真地做了改进，以下是她修改后的第二版计划：
+
+<img src="https://static001.geekbang.org/resource/image/fc/e4/fc48769b83279ac847eee1640bfaa7e4.png" alt="">
+
+从这份计划中，我们可以看到，小勤对开发任务进行了详细地拆解，每个人的工作都很明确。你觉得这样很好了，对不对？
+
+No！这恰恰是做计划时最容易忽视的一种“延期地雷”。这份计划，看似很详细，实际上仍然是个任务的集合，没有办法指引我们有效地达到目标。
+
+**做计划的方式的转变，背后其实是思维方式的根本转变**。小勤在做程序员的时候，她的目标就是完成开发任务。但当她的职责扩大之后，她本能地将设定目标默认为完成一堆开发任务，她还没有意识到，作为项目负责人，自己还需要做些什么。
+
+### 雷区2：不够全面
+
+我刚刚说过，项目管理是运用当前一切可用的资源，去完成整个项目目标。这份计划的最大问题就是，**只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节**。这样的计划，无法让我们明确实现目标的关键路径，也无法明确是否可以完成目标以及如何完成。
+
+**识别依赖并画出关键路径，就是我要讲的做计划的第二个标准动作，这一步意味着我们开始从目标的角度对资源进行统筹思考**。
+
+关键路径是决定项目工期的进度活动序列。它是项目中最长的路径，关键路径的工期决定了整个项目的工期。所以，任何关键路径上的延迟都将直接影响项目的预期完成时间。
+
+明确了这一点之后，小勤又进一步调整了计划，我们来看看小勤做的第三版计划。
+
+<img src="https://static001.geekbang.org/resource/image/7c/f2/7c14929c016a6c3a7da15d8df0e1e2f2.png" alt="">
+
+从图中可以看出，小勤已经把工作流中的先后依赖关系识别出来了，这样一来，关键路径也明确了，这份计划总算有个模样了。清晰了关键路径之后，我们要对其进行持续关注，把关键路径上的风险作为最高优先级应对。
+
+除此之外，在核心部分计划出炉以后，我们还要对项目涉及到的其他合作环节，进行全面地规划和安排，为各个阶段设定合理的里程碑节点，确保考虑周全。
+
+听完我的建议之后，小勤再一次改进了她的计划，把其他合作环节也明确地标注出来了，如图所示：
+
+<img src="https://static001.geekbang.org/resource/image/96/55/969a02fcc5ad8b23659978f8efb00c55.jpg" alt="">
+
+明确了和其他合作环节的时间节点之后，我建议你使用**Visio**工具，把整个过程可视化出来，让计划更加直观。
+
+<img src="https://static001.geekbang.org/resource/image/ec/39/ec79d263252f1c47c4e7f8d305515839.png" alt="">
+
+### 雷区3：不够准确
+
+修改过几轮计划之后，小勤对于日常排期越发驾轻就熟。她再一次来找我时，情况已经好了很多。不过，她又碰到了一些新问题。
+
+排在首位的是，当计划在执行中出问题的时候，总是会产生很多纠纷，大多是因为大家对一些节点的定义理解不一致，比如什么叫提测，什么叫里程碑完成。
+
+有一次还发生了“乌龙事件”。在临近上线时，开发同学跟她说：“拜托！我从来没说过XX号完成交付，我说的是XX号开发完，你去看看聊天记录！”这让她很是难堪。
+
+对小勤来讲，这时迫切要做的，就是让节点的定义形成共同的标准。这就要引出**做计划的第三个标准动作了，就是定义完成标准**。
+
+简单来讲，完成标准就是某时间点需要完成的事项列表，或者是应该达到的某项指标（特定水平的Bug数量/性能指标等）。进度计划中的任何重要时间节点，都应该有一组完成标准。**越早定义完成标准，计划按照期望完成的概率就越大**。
+
+以最关键的几个常见时间节点为例，完成标准如下：
+
+- **需求/设计确认**：执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。值得一提的是，有些团队还会对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。
+- **功能完成/提测**：所有定义的功能都已经完成（比如冒烟测试通过率高于90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作Bug来跟踪。一些质量基础比较好的团队，也可以把CI自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准。
+- **里程碑完成**：质量已经达到适当水平（如不存在P0及P1优先级的Bug），可以上线发布，或者可以开始下一个里程碑。
+
+### 雷区4：没有共识
+
+事先定义完成标准，就好比提前约法三章，会让计划有更准确的指向作用。当我继续深挖小勤的烦恼之后，我发现，她做计划还有个毛病，就是进度计划的文档只在她自己的电脑里，在执行计划的过程中，她只和几个开发口头说过，从来没有以任何公开的方式发布过，甚至都没有发邮件、公告等与全员同步信息，更别说开专门的规划会了。
+
+她只是“做”了一份计划，而不是在“做计划”。这真是个惊人的发现。
+
+其实，做计划本身并不是最难的，真正难的是什么？对焦！**没有达成共识的计划，是不具备任何效力的**。
+
+事实上，PM在召开规划会之前，排期的内容已经准备得差不多了。在全员规划会上，除了对齐信息之外，更重要的是当面达成共识，这其实也是仪式感和承诺的象征，对计划后续的有效执行，是至关重要的。因此，**达成共识并公开透明，就是做计划的第四个标准动作**。
+
+对于一些小项目，即便没有全员规划会，我也强烈建议你至少要在确认计划之后，向所有项目组成员，包括项目的所有干系人，发送计划邮件，正式周知，这可以尽早地发现共识的偏差。
+
+### 雷区5：不够即时
+
+计划就像冰箱里的酸奶，即时的，才是有效的。虽然定计划是个谨慎的过程，但我们也需要看到，计划绝不是固定不变的。
+
+在整个项目周期中，由于随时会可能出现变更，加上对估算的不断细化，做计划永远是个反复修正、渐进明晰的过程，我们要对计划进行持续地跟进与调整**。重要的是，每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策**。而**及时调整变更，就是做计划的第五个标准动作**。
+
+你需要注意的是，与进度计划有关的任何变更，都需要提交给项目管理人员，最好由团队中对应功能小组的成员（该功能模块涉及的策划、设计、开发、测试）及其他相关干系方共同讨论，明确计划变动可能对各方造成的影响，最终做出决策，并公开告知所有项目组成员。
+
+## 总结
+
+好了，做计划的五大雷区我都介绍完了，针对这些雷区，我给出了做计划的5个标准动作，分别是**WBS工作分解**，**识别依赖及各环节关键路径**，**定义完成标准**，**达成共识并公开透明**，**即时调整变更**。最后，针对雷区的特征，我用一张图片来总结一下好计划应该具有的特点。希望你在做计划时，能够对照着下表进行梳理，以免埋下“延期地雷”。
+
+<img src="https://static001.geekbang.org/resource/image/c3/9f/c3666af0b298fcad7fc7e819aca33f9f.jpg" alt="">
+
+## 畅所欲言
+
+如果你是我在这一讲开头提到的那位创业团队的程序员，你被老板要求倒排时间，你会怎么办？请尝试运用今天所学的知识，梳理一下自己的行动方案。
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/硬技能篇/06 | 执行：打造品质，要从头开始“闭环”.md

@@ -0,0 +1,92 @@
+<audio id="audio" title="06 | 执行：打造品质，要从头开始“闭环”" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/54/36/543d9bbb6f8914aa4d5a3c4986938d36.mp3"></audio>
+
+你好，我是雷蓓蓓。今天我要跟你分享的主题是：打造品质，要从头开始“闭环”。
+
+不知道你是否经历过这样的场景：你的团队历经一个多月没日没夜的奋斗，终于在圣诞节采购季来临前，完成了“黑五购物节”活动的所有功能，全部测试完毕，马上就要上线了。结果，产品负责人试用之后，皱着眉头说：“这……不是我想要的！” 你说，还有比这更悲惨的吗？
+
+实际上，这种现象并不少见，有些产品经理还美其名曰“允许试错”。可是，最后做完了才发现不是自己想要的，早干吗去了呢？！
+
+之所以会出现这种情况，有很多潜在的原因。比如，在互联网环境下，要弄清楚开发什么产品，准确把握并实现用户需求，对产品人员的要求其实非常高。对于互联网产品而言，从最初的一个想法，到确定规模化的增长模式，通常要经历很多轮的螺旋式迭代，不断调整。
+
+除了这个原因之外，更为常见的情况是，需求和设计根本没有经过严格的把关，就匆忙投入开发；同时，在传统的研发中间过程中，很难看到串连起来的功能效果，产品经理必须等到快上线了，才能看到和真实体验到可完整运行的产品。但是这个时候，再想大幅度修改产品，代价已经非常高了。
+
+很多时候，我们确实没有办法一步到位，但合理试错，减少不必要的浪费，仍然是可以做到的。在项目执行的过程中，想要降低偏差、减少返工，**你就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制**。
+
+说到这里，我想先提一下，到底什么才是真正的闭环。我是学控制工程出身的，大学教科书里的一张展示开环和闭环系统的经典图片让我印象非常深刻。看了这张图，你就会明白，其实，**开环与闭环之间的关键差异，就在于有没有反馈环节，以及系统是否会根据反馈自动调节**。
+
+<img src="https://static001.geekbang.org/resource/image/38/1b/38c702676d0f440f60520b359371221b.jpg" alt="">
+
+那么，既然闭环如此重要，在产品研发的整个过程中，到底有哪些实用的闭环验证方法呢？我来给你介绍三种最实用的方法。
+
+## 方案评审（OARP决策机制）
+
+其实，需求评审、交互评审、视觉评审都是非常基本的闭环验证方法。我在留言区了解到，有些项目是从来不做需求评审和设计评审的，产品人员找某位开发单方面讨论一下，需求就算定下来了，可以直接往下走了，这就是典型的开环系统。
+
+还记得我在刚开始举的“黑五购物节”的例子吗？那次返工，不仅让团队一个多月的辛苦打了水漂，还错过了最黄金的购物节时间。不得不说，这样的开环系统，在上线后出现偏差是很正常的，因为在这个过程中，根本没有任何矫正的机会。
+
+**要想执行中不走样，你就必须把方案评审做到位**。而一说到评审，很多人会说，不就是组织一个会吗？大家就是坐在一起看一看，流于形式。No！你需要理解的是，**评审的精髓不在会，而在于背后的决策机制**。只有决策机制清晰，职责分工明确，方案评审才会有好的闭环效果。我来给你介绍一个典型的决策机制，叫作OARP。
+
+OARP是Owner、Approver、Reviewer、Participant的缩写，分别对应四个关键角色：
+
+- 负责人（Owner）：负责给出方案，组织各方讨论并推进做出最终的决定；
+- 批准者 （Approver)：最终批准者；
+- 审核者（Reviewer）：负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复；
+- 参与者 （Participant）：其他提供意见的人。参与者会收到文档的相关信息，可以对相关问题做出反馈。
+
+<img src="https://static001.geekbang.org/resource/image/7a/84/7aa9eb23f70c57b01fd12126ff059284.jpg" alt="">
+
+这张流程图清晰地展示了一个典型的方案评审流程。OARP是一套决策机制，你需要为项目中每一类方案的评审，确定明确的角色和职责，让各角色应享有的权利、应履行的职责，都得到规则上的保障，这样才能更好地确保方案质量，把后期的返工降到最低。
+
+我把项目中常见文档所对应的OARP角色汇总在了下面这张表格里，你可以参考一下。
+
+<img src="https://static001.geekbang.org/resource/image/3c/47/3cc2175f49b7cc3b39ffb17e4c408347.jpg" alt="">
+
+## Bug Bash（Bug大扫除）
+
+Bug Bash，也叫Bug大扫除，最初来自微软，是指在项目开发里程碑的末期（比如Beta版发布前），划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找Bug，目的是从各个维度衡量和体验产品。
+
+这是一个非常有意思的活动，在网易也很受欢迎，在反复的实战应用中，我们对Bug Bash做了很多的改良，产生了很多有趣的变种。除了应用于测试阶段，我们发现，Bug Bash还是进行产品闭环验证的一个非常有效的方法。通常，在版本的需求稿和交互稿完成之后，我会专门安排一段时间，组织团队成员一起，集中精力给需求稿和设计稿找问题。
+
+记得我第一次组织这样的活动时，程序员们开心坏了！因为，他们终于可以让策划和设计们，也尝尝修Bug的滋味了！曾经，在一次活动的需求设计Bug Bash上，运营同学发现了现有产品的逻辑错误，避免了上线后优惠券发放的漏洞，为我们提前规避了很大的损失。通过这些Bug Bash活动，我们把产品验证环节大大地提前了,不仅达到了更好的体验效果，还有效地保障了上线质量。
+
+那么，想要组织一场Bug Bash活动，该从哪些方面入手呢？
+
+1. 时间：测试类的Bug Bash，你可以选择在全面功能测试结束后，Bug趋于收敛的时间段开展；需求设计类的Bug Bash，一般会放在需求稿或设计稿完成后举行。这个活动需要一到两个小时的时间，你一定要提前排除所有干扰；
+1. 地点：你需要设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力做这一件事。同时，作战室可以提供一些零食和饮料，让活动更有氛围；
+1. 参与者：除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群，都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角；
+1. 现场安排：你可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新Bug或建议的排名情况。需要注意的是，营造互动的氛围非常关键，如果因为空间受限，参与者做不到在同一个地点进行，你至少也要在通信群中实时更新排名情况的变化。
+1. 活动结束：在活动结束后，要直接公示Bug或建议数，现场给奖品，并发邮件通报全组。最后，在对Bug进行去重后，还要分类定级，确定哪些Bug是必须修的，哪些Bug是改了会更好的。另外，千万不要忘记公示结果，明确修复计划。
+
+关于活动的组织方式，你可以加入更多游戏化的玩法，这些都是为了最大程度地调动团队成员的参与热情，让问题在早期得到更好地暴露。你可以在一些重要版本中尝试这样的方法，与很多低效冗长的评审会相比，这个活动在避免返工方面，会有非常好的实战效果。
+
+实际上，有时候，视觉稿我们也会拿出来这么做。曾经，某个已经运营了三四年的重量级产品，要在一个月之内完成全网的视觉改版，工作量巨大到难以想象，寻常做法很容易出问题，影响最终的用户体验。但时间非常紧张，我们根本来不及全部定稿，就必须开始并行开发，怎么办呢？
+
+当时我就想到了Bug Bash，不过这回不是做一次，而是每天都做！我们把计划拆分到按天交付的颗粒度，每天晚饭后的半个小时，大家会聚在一起，给刚刚做好的视觉稿找Bug。开发和测试人员的早期参与，让很多遗漏的视觉问题在早期就得以发现，避免了后期的很多返工。后来，这个视觉改版非常顺利地上线了！
+
+让我没想到的是，在项目组的回顾会上，每天晚上的Bug Bash活动，竟然高票当选最受欢迎的团队活动。仔细想想，Bug Bash也是非常好的团建活动，我至今都很怀念那段虽然无比辛苦，但有吃有喝、充满欢笑的“革命岁月”。
+
+## 冒烟用例评审
+
+有同学留言问我说，当程序员说完成了某个模块的开发工作时，项目管理人员怎么知道100%完成了呢？其实，项目经理最怕听到的一个词，就是“**差不多**”。比如，差不多写完了，差不多测好了，差不多可以发布了……每项工作都是差不多，可是一到测试环节，就会发现，其实还差得很远呢。
+
+在上一讲中，我提到，做计划时要明确定义完成标准，而冒烟测试用例，可以说是开发和测试之间最基础的合约。
+
+虽然“冒烟测试”这个概念很普遍，但是很多团队只是把它作为提测后的测试用例组，并没有真正发挥其合约的作用。要想避免掉进“差不多”的陷阱，在进入开发环节后，你需要安排专门的测试用例评审，让开发和测试对标准的冒烟用例集达成约定，这个约定就会成为进入测试的准入标准。
+
+开发发起提测以后，测试人员就会依照这个标准用例集进行冒烟，并记录冒烟测试通过率，如果通过率不达标，就打回修正并再次提测。
+
+如果你是在完全没有基础的团队中推行这个做法，可以**先从测试人员记录冒烟测试通过率开始**。接着，你要收集相关数据，和你的团队在回顾会上一起看看冒烟用例失败所导致的后期返工成本，讨论出一种更好的确保质量的做法。在我直接管理的项目中，冒烟通过率的要求通常是100%，你可以选择从一个合适的起点开始，比如80%，然后再一步步地逼近更好的提测质量。
+
+## 总结
+
+总结一下，今天，我给你介绍了在项目执行过程中，有效降低偏差、避免返工的三种闭环验证方法，包括方案评审、Bug Bash（Bug大扫除），以及冒烟测试用例评审。
+
+其实说到底，这些方法都是为了保证执行过程不走样。需要注意的是，你并不需要在每一个版本中把这些方法全都用上。你可以结合自己的项目情况，有步骤地开展优化，在核心的输出环节，设置合适的断点和关口，这样就能更好地把控全局了！
+
+## 畅所欲言
+
+这一讲中，我跟你分享的，都是我们自己在实战中积累下来的闭环验证方法。只有到了执行时，你才会发现，理想有多丰满，现实就有多骨感。我想请你来聊一聊，你在项目执行过程中踩过的最痛的“坑”。如果你可以再分享一些你的“爬坑指南”，那就更好了。
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/硬技能篇/07 | 监控：进展“巧”汇报，学会用数据说话.md

@@ -0,0 +1,102 @@
+<audio id="audio" title="07 | 监控：进展“巧”汇报，学会用数据说话" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/28/ca/28668774c7955e7f2b41f7149b56a0ca.mp3"></audio>
+
+你好，我是雷蓓蓓。在前面三讲中，我分别介绍了启动、规划、执行过程中的典型问题和实战解法，今天我们来聊一聊监控过程。
+
+我们在[第5讲](https://time.geekbang.org/column/article/162272)中玩过一个“扫雷游戏”，目标是排除计划中的“延期地雷”，但是，总有些“雷”防不胜防。我们在做计划的时候，明明已经想得非常周全了，可是，真正开工之后才发现，很多事情并没有那么简单。
+
+我曾经就经历过这样一个项目。某个课程系统要对其购物车功能进行扩展改造，最初评估时，研发认为功能并不复杂，三天就够了。但是，开工之后却发现，这个“坑”改动起来牵涉面太大，老的订单系统盘根错节，不好下手，现在看来至少也得两个礼拜才能完成。
+
+可问题是，这个任务正好在关键路径上，如果它延期了，所有都得跟着延。更重要的是，老板特意交待过，这次上线关系到年底最重要的KPI，一定不能延期……万分紧急之下，如果你是项目经理，你该怎么办？
+
+首先，必须要冷静！泰山崩于前而色不变，这是作为一个项目经理必须要修炼的心态。在项目的监控过程中，你会遇到各种各样的情况，甚至是突发的紧急状况，这个时候，有效的沟通汇报是必不可少的。那么，如何更好地进行项目汇报呢？你可以从以下三个方面来展开。
+
+## 紧急汇报：直面问题有章法
+
+在程序员看来，我只管安心干活就好，特别不希望有人打扰，问东问西。假设执行中遇到困难，往往也更习惯于自己琢磨，拼命地想要把进度赶回来，不到最后一刻绝不把问题暴露出来。结果，等到被发现的时候，往往已经是很大的进度偏差了。
+
+承认自己遇到了问题需要帮助，其实是件非常困难的事情。毕竟，很多人都有“特别想要把事情做好，让老板有个好印象”的心态。但是，作为项目管理人员，当事情已经超出了你的可控范围时，你首先要做的，就是第一时间直面问题，如实地呈现和反馈遇到的困难。对于整个项目而言，你的真实和坦诚反而是最重要的。
+
+但是，很多程序员其实并不擅长汇报，更别说这种特别困难的场景了。那么，接下来，我就给你介绍一种紧急问题的汇报方法。
+
+**紧急报告，是指在项目发生突发事件，或者提示重要风险状态变化时的实时报告**，比如遇到高风险延期、线上重大问题、或者重要客户投诉等，目的是向全组或者主要干系人通报项目的重要变化，以及时协调应对工作，或者第一时间寻求外部支援。
+
+由于事发突然，紧急报告一般不需要拘泥于具体的形式，关键在于言简意赅地传递信息，并组织后续的跟进动作。一般来说，紧急报告会包含5个基本元素：
+
+1. 事件描述；
+1. 影响后果；
+1. 跟进分析；
+1. 响应措施：包含负责人及时间表；
+1. 所需支持。
+
+我们来结合实际案例看一下紧急报告要怎么写。以开头的那个项目为例，我们来看看那位项目经理当时的紧急报告：
+
+1. **事件描述**：购物车改造功能高延期风险；
+1. **影响后果**：由于此功能在项目的关键路径上，很有可能会造成项目整体延期两周；
+1. **跟进分析**：本期购物车改造功能，有部分调整涉及到底层订单系统，里面有大量遗留代码，已经很久没有人维护了。之前对此风险的评估不够充分，改动风险很高，可能会影响全站订单系统的稳定性，具体影响仍需要详细分析；
+1. **响应措施**：主程全力以赴做好技术评估，本周内给出详细任务评估时间表；与此同时，产品人员介入，调研规避老系统又能满足需求的可行性，本周内给出调研结论；
+1. **所需支持**：熟悉老系统的资深技术人员，以及红牛一箱。
+
+这份紧急报告提交以后，发起人第一时间就会关注到，项目组正面临着非常棘手的问题，以及可能造成的影响和后果。同时，他也了解到，团队正在试图解决这个问题，目前的解决方案是什么，还需要什么样的支持和帮助。当然，如果你能够第一时间跟发起人当面沟通，效果会更好。关于沟通的具体内容，你同样可以参考我刚刚给你分享的这个模版。
+
+回到刚刚的案例，最后，产品人员跟开发一起修改了产品逻辑，尽可能地规避了一切上线后的高风险项。这次紧急情况的汇报，让他们及时调整了后续灰度发布的时间安排，以及上线后的运营方案，避免了用户侧更大的影响和损失，同时也把对KPI的影响降到了最低。
+
+总之，执行过程中突发的紧急情况，非常考验项目经理的专业素养。首先，你必须要直面问题，在紧急时刻勇于站出来承担责任，不仅不会让老板对你的印象减分，还能让决策者在第一时间选择更好的应对方式。另外，你要尽可能简洁地描述清楚可能的影响和后果，目前的建议方案和所需支持，最大程度地争取各个相关环节的协同配合，共同应对问题。
+
+## 常规汇报：项目周报回答的三个问题
+
+讲完了紧急情况下的汇报，我们再来看看常规汇报该如何做。我看到过很多程序员的项目周报（如下图），虽然周报里清楚地罗列着上周做了什么，下周要做什么，但是看完之后，我经常一头雾水。
+
+<img src="https://static001.geekbang.org/resource/image/34/25/3425cbeb115af894f304407fd6875725.jpg" alt="">
+
+这是因为，周报里只有一堆任务流水账式的罗列，但是，项目的整体进展状态到底如何？风险可控吗？目标达成有没有问题？周报里都没有提到。
+
+实际上，一份好的项目周报，最重要的就是回答好这三个问题。为了更直观地描述项目的状态，我们可以使用天气图标，把项目分成以下六个等级：
+
+<img src="https://static001.geekbang.org/resource/image/80/b2/80faf251e2f15402ae07ee6fbc7441b2.jpg" alt="">
+
+有了天气图标和风险等级提示，项目汇报就清晰多了，如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/51/98/5187a948817865fc2eba4bab1f4f2698.png" alt="">
+
+实际上，项目周报是向项目团队和干系人沟通项目状态的常用手段，你需要用简要的方式呈现项目全貌，客观地展示项目问题，推进问题解决。我给你分享一份周报模板图，你可以根据自己项目组的需要，选择合适的内容模块。具体的模板文件，你可以点击[网盘](https://pan.baidu.com/s/16BJ3qcx_gTMLo7cUSE28tA)获取，提取码是9g99。
+
+<img src="https://static001.geekbang.org/resource/image/1c/ee/1cf7a1592dfe56d4160494201d71efee.jpg" alt="">
+
+在这份项目周报模板中，最必不可少的就是**整体项目状态评估、风险列表、项目概况及计划变更情况**。好的周报，应该让大家对项目现状的三个问题形成统一、清晰的整体认知。这份整体认知，可以让平时扎在细节工作中的人，从全局视角来了解和看待整体，从而更好地完成自己的工作。
+
+需要你注意的是，一份周报的阅读时间不应超过5分钟。因此，在写到进展和问题时，**切忌事无巨细**，只写要点就够了。周报不是为了表现工作量，更不是为了刷存在感，只说重点就够了。
+
+## 数据汇报：善用“透明”的力量
+
+我在[第1讲](https://time.geekbang.org/column/article/156858)中提到过，作为新手项目经理的我，经常觉得哪儿哪儿都是问题，今天催这个，明天推那个，可就是什么事都推不动，谁都不配合。后来，我发现，与其每天挨个去盯梢，不如多花点功夫，把这些状况全部“透明”出来！
+
+说干就干！我开始研究Jira中的各种图表。俗话说，一图胜千言。拿线上事故的改进措施为例，每次都说要建立完善的保障体系，可是经常一个月过去了，也没什么进展。于是，我就把事故数据拉出来，根据原因定位，分门别类地做成直观的数据图表。后来，我发现，只要我坚持在项目组大群里发上三天，表格上的数据就会悄无声息地发生变化，改进项清零的速度也加快好多。
+
+那是我第一次体会到“透明”的力量。在这以后，在项目汇报和日常跟进中，能够用图表和数据的，我就不会用文字。作为项目管理人员，你手中不见得有多少权力，但有一种强大的力量，你一定可以无限获取，那就是“透明”。
+
+我给你介绍几种常见的项目仪表盘，这些图表，你都可以快速地在JIRA中绘制出来。其中，倒计时图是个非常醒目的标志，可以帮助大家建立清晰的时间意识，而工作任务的状态分布和剩余工作量分布，可以清晰地展现出每位成员的工作排布情况，帮你快速发现和定位执行过程人员工作量的瓶颈。
+
+<img src="https://static001.geekbang.org/resource/image/b8/d5/b847db5182816fb78859dc0555a3c1d5.jpeg" alt=""><br>
+<img src="https://static001.geekbang.org/resource/image/01/05/0150ff4b59dd3a87d2dd650e3ad7d305.jpeg" alt="">
+
+这里我想要特别介绍下燃尽图（Burn Down Chart），这是敏捷开发方式中用于表示任务完成趋势的工作图表，横轴表示时间，纵轴表示工作量。如果你在做好规划之后，把任务和工作量录入JIRA，设定好迭代的预期完成时间，就可以自动生成这样的图表。
+
+这种图表可以**直观地进行过程预测和风险预警**，其中，灰色线是计划完成情况的基线，红色线代表实际完成情况。在进展顺利的情况下，红色实际线会紧贴着灰色计划线，一路往下，直到“燃烧殆尽”。每天开站会时，更新完任务状态之后，团队可以一起看下燃尽图的变化。如果红色线连续多天居高不下，一直停留在灰色线上方，这就说明进展持续低于预期，你就要多加关注了，具体分析到底是哪个环节拖了后腿，然后有针对性地发起改善。
+
+JIRA上有丰富的插件去获取各类图表和数据。不过，比工具更为重要的是，你要结合项目组中当前需要重点推进或改进的事项，选择合适的数据和图表去做“透明”。
+
+## 总结
+
+今天我给你介绍了在监控过程中，进行项目进展汇报的几种方法，包括紧急汇报的五个元素，常规项目周报要包含的重要内容，以及如何运用透明的力量，通过数据汇报推动问题的解决。
+
+有同学留言说，自己的项目前期拖沓，需求稿、设计稿经常给得很晚，开发承受着很大的压力，只好拼命加班。我曾经也遇到过类似的情况，为了促发改变，我尝试客观记录了策划、设计、开发、测试等各个环节的时长分布，以及可能带来的后期风险。这份数据在项目汇报中展示以后，引发了管理层的高度关注，在下一个版本中，问题很快就得到了改善。
+
+可以说，项目进展汇报是项目经理面向所有干系人、非常重要的一个沟通和发声的平台，运用得好的话，可以成为项目经理有力的杠杆力量。有效运用这个杠杆的秘诀就是：想要改善什么，你就去透明什么，越直观越好！
+
+## 畅所欲言
+
+最后，我想请你来聊一聊，关于我在第三部分提到的数据“透明”，你如何看待“透明”的力量？在你的项目场景中，你曾经有过哪些应用和体会吗？你觉得未来还可以有哪些应用吗？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/硬技能篇/08 | 收尾：项目复盘，小团队也要持续改进.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="08 | 收尾：项目复盘，小团队也要持续改进" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d2/a0/d229c5de2c7392b07dc46d1cb928f9a0.mp3"></audio>
+
+你好，我是雷蓓蓓。今天我们来聊一聊复盘。
+
+复盘原本是围棋术语，是指每次博弈结束之后，双方棋手把刚才的对局复演一遍，分析对局当中得失的关键，是提升自己棋力的好方法。其实，**复盘是对思维的训练。**通过复盘，当类似的局面再次出现在你面前的时候，你就能够快速地预测接下来的动态和走向，并且更好地应对。
+
+而项目复盘会，可以说是**项目团队有意识地向过去的行为经验学习的过程。**在项目或里程碑完结之后，项目经理会组织召集项目成员，一起回顾一下，在项目的整个历程中，团队做对了哪些事，做错了哪些事，再来一次，如何做得更好，借此把项目行进过程中产生的集体智慧沉淀下来。
+
+但是，现实情况经常是，项目一个接一个地做，忙上线、忙变更、忙返工，哪有时间坐下来复盘？又有多少复盘会，是为了复盘而复盘，逐渐地流于形式，成为了可有可无的摆设？除此之外，还有很多复盘会，成为了追责者的工具，除了锻炼出花样百出的各种甩锅技能之外，留下的只有“一地鸡毛”。
+
+由此可见，要想做好项目复盘，并不是一件容易的事情。今天，我就带你来看一看，如何做好项目复盘，以及如何通过复盘去培养团队的持续改进能力。
+
+## 复盘会的基调设定
+
+我们都知道复盘很重要，但实际上，**在复盘会之前，想清楚我们复盘的目的，设定好复盘的基调，其实更为重要**。
+
+我曾组织过一个复盘，叫作“坑爹功能”大搜罗。参与复盘的十多位团队Leader，在现场写了20多页纸，满满当当地罗列着我们曾经做的、却没什么人用的功能。实际上，只有当大家真正摊开不太愿意面对的真相，去认真思考背后的深层原因时，我们才能共同进入真正的集体反思区。这样坦诚地直面问题的复盘，才能促发有意识的集体学习。
+
+要想让参与者真正进入集体反思区，会前就要设定好开放的复盘基调。其实，我们每个人都可以在自己所处的环境中，看到各种各样的问题。如果复盘是出于追责，那么在会议刚开始时，大家就可以迅速地感受到，这样一来，每个人都会小心地避开自己的问题，转而去说别人的问题，这样的复盘就失去了意义。那么，如何设定开放的基调呢？
+
+**首先，我们自己要先进入反思区**。其实，在那次复盘会之前，我跟这个部门的负责人，就部门中反复出现的各种问题，进行过多次深度沟通。一开始，这位负责人觉得团队里到处都是问题。但当我们把问题一层层地剖开来看时，我们发现了很多问题背后的深层原因。
+
+除此之外，在会议刚开场，就要展示出自己的开放与坦诚，给复盘会奠定基调：**这次复盘不是来挑问题的，而是为了找到问题的根源并改进的**。在那次复盘会上，这位负责人特意讲了自己这一年来的深刻反思，这就带动大家敞开心扉，直面问题。那次会上，大家自发地找到了在各个环节有效避免无用功能的方法。会议结束以后，这个部门还发起了一项“整风运动”，从增强用户意识的讲座，到用户调研方法的培训，再到激励与考核制度的挂钩，让复盘会反思的成果，逐渐渗透到了每个人的日常工作中。
+
+## 复盘会的会前准备
+
+除了设定基调，你还需要充分的会前准备。在复盘会之前，你要去**梳理整个版本的历程**，包括项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等，这些是客观数据的总结。同时，你还可以提前收集这个版本期间，团队满意度的问卷调查，为复盘会引入更多主观的输入。
+
+除此之外，视频也是非常好的回顾材料。曾经，在某次重要版本的复盘会前，我熬夜加班，为团队准备了一段回顾视频。这个团队刚刚完成了一件几乎不可能完成的任务。因为客户的需求非常迫切，往常要做一个半月的大版本，直接压缩到三周内完成，团队非常非常辛苦。虽然视频的制作手法很粗糙，但那些加班到深夜开迭代演示会的照片，还是让现场的很多人感动不已，瞬间为这个疲惫的团队注入了能量。
+
+**其实，复盘会的基调设定，以及会前的准备工作，在开会之前，就很大程度地决定了复盘会的效果，你一定要特别留意**。
+
+了解了这些之后，我们就来看看复盘会的流程。
+
+## 复盘会的简易流程
+
+复盘会的流程，其实并不复杂。在实战中，我总结出了一套最为高效的复盘流程。
+
+1. 现场回顾总结项目/里程碑的整体概况，包括目标达成情况、进度计划及变更情况、需求变更情况、质量报告等项目历程记录。
+1. 与会人员用便签纸写下项目过程中做得好的以及做得不好的3个点，按照项目的各个环节分类，分别贴在白板上，确保大家的意见能够充分、自由地表达。
+1. 在白板前逐条review大家的意见，共同发现问题，并有针对性地展开讨论。
+1. 对大家总结出的好和不好的点，进行集体投票。
+1. 由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案。
+
+<img src="https://static001.geekbang.org/resource/image/d9/7f/d9f22881fbfd8fa77774eaf586d26e7f.jpg" alt="">
+
+我们来看看一次真实的项目复盘会的投票结果：
+
+<img src="https://static001.geekbang.org/resource/image/a2/73/a2b4bbfd7a0e554e7d3bec3392e79c73.png" alt="">
+
+这个项目是第一次引入项目经理。在这次复盘会上，项目经理的工作得到了一致的认可，包括Bug Bash的引入、WBS工作分解、进度控制等措施，帮助团队快速地完成了从混乱到有序的转变。再来看看待改进项，投票最多的一项是，后台研发与各端的沟通瓶颈，那么很显然，这就是你在下个版本一定要去解决掉的问题。
+
+经过分析之后，我们发现，由于工期紧张，在后端接口没有成熟的情况下，前端、客户端必须同时开发，如此快节奏迭代之下，频繁的后台接口变动，牵一发而动全身，这让后台技术成为了整个项目的瓶颈。为了改善这个问题，我们成立了专门的Triage小组（判别小组），由各端的主程组成，每天固定15分钟时间，参与者线上同时连线，对每个端提出的接口变动需求，进行统一判断，并作出决策，确保接口变更信息第一时间的同步。
+
+**无法促发行动的复盘，说得再好都是空谈**！一开始开复盘会，大家会期待，解决的问题越多越好，但焦点增多之后，哪个都是蜻蜓点水地过一遍，哪个都没改彻底。下次再开会的时候，大家发现之前反馈的问题依然还在，那谁还有动力继续提问题呢？
+
+所以，**改进措施一定要落地，重点行动不要太多，一个就够了！**如果每次复盘聚焦于改进项中的Top 1，确保改进措施真正落地，长期坚持下去，就会促进持续的能力提升。同时，**复盘的次数也不要太多，你并不需要每个版本、每个迭代都例行公事地去做一遍，确保每个季度有一到两次里程碑复盘，可以完整地对项目做系统化的梳理，达到真正的落地效果，才是更重要的**。
+
+## 打造团队持续改进能力
+
+其实，项目复盘不只是一次会议，它更应该成为团队持续改进的推动力。那么，怎样才能让一次成功的复盘发展成为复盘文化，激发团队自主地持续精进呢？
+
+**实际上，想要让团队进入自发改进的正向循环，你需要更好地激发团队的主人翁意识，让团队成为复盘的主角，而不是你。最重要的是，你不仅要关注事，还要关注人**。
+
+我曾经为某部门组织过一次复盘会，取名叫作“研发代表大会”。当时，我们把部门中所有资深的程序员召集在一起，让他们给平台越来越严重的技术债问题出谋划策。这次复盘我采用了“批奏章”的玩法，各位代表把自己的意见写在纸上，然后围成一个圈，依次传递给左边的同学，每个人把手上的“奏章”批阅完成后，继续往左传。这样一圈转下来，+1数最多的那份“奏章”，就会被选出成为年度力荐。
+
+最后，这份“奏章”得到了最多的关注和资源，这项建议迅速得到了落实。同时，这样的复盘方式，也让更多的研发同学享受到了“批奏章”的愉悦感，一旦他们发现，自己选出的“奏章”会得到采纳和落地，那么这个“研发代表大会”也就可以真正地自行运转起来，更多人愿意主动参与进来，通过这个平台，发表自己的见解，为整体能力的提升贡献一份力量。
+
+另外，**越是困难时期，越是塑造团队能力的大好机会**。在团队遇到重大困难时，你也可以及时组织一场复盘会，深度关注和调整个人的状态。我就曾经试过让每个人画出自己进入这个项目组以后的状态变化曲线，跟大家分享自己的“高光时刻”和“至暗时刻”。在业务低落期，这样的复盘会会成为一个重要的转折点，让团队的力量得到深度聚合。
+
+这些对人的关注，都会让复盘会超越问题解决的层面，在推进事的同时，促使团队自发地推进问题的解决，并把经验内化下来，从而不断提升团队的持续精进能力。
+
+## 总结
+
+好了，让我们对复盘做个小结。其实，当人们在说复盘时，往往会把焦点放在复盘会本身。但我却认为，**决定复盘成功与否的关键，不在会议本身，而在于复盘会的一前一后两个环节。**
+
+复盘会前，复盘基调的设定是否开放，复盘会前的各项准备是否充分，对于复盘会的效果非常关键。组织一个复盘会本身并不难，难的是在复盘会后，持续跟进这些反思，落地为切实的改进措施，让团队真正看到效果，从而打开团队持续改进的正向循环。
+
+最后，我建议你**认真地做好一次复盘，每次复盘后聚焦一个改进点。再提醒你一句：聚焦点别太多，一个就够了！**
+
+## 畅所欲言
+
+我想请你来聊一聊，你经历过的印象最深刻的一次复盘，打动你的是什么？回顾一下你经历过的那些项目，如果可以再来一次，你最想要做好的是什么？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/硬技能篇/09 | 需求变更：化解程序员的“头号噩梦”.md

@@ -0,0 +1,85 @@
+<audio id="audio" title="09 | 需求变更：化解程序员的“头号噩梦”" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f6/89/f664bbe93a6973f0e6464b8958d53389.mp3"></audio>
+
+你好，我是雷蓓蓓。今天，我们来聊一聊如何应对需求变更这个话题。
+
+需求变更一直都是一个热门话题，特别是在奉行唯快不破的互联网公司，需求变更可以说是程序员的头号噩梦，也是“996”的直接元凶。
+
+阿里有句非常有名的口号，叫作拥抱变化。既然需求变更无法被消灭，那么我们就要通过学习，掌握更好地应对需求变更的方法。我们先来看看常见的需求变更流程。
+
+<img src="https://static001.geekbang.org/resource/image/cd/e8/cda9fd3f18e913820665be99fcb087e8.jpg" alt="">
+
+首先要发起变更申请，由变更委员会来综合评估，评估的内容包括变更范围、风险、对现有计划的影响程度等，以此来判断是否接受变更。变更委员会一般是由产品leader、技术leader、测试leader及项目经理组成，如果接受变更，那么就需要判断项目计划是否需要进行相应的调整，最后公告处理结果。
+
+其实，流程本身很简单，关键在于能否被有效地执行。在这一讲，我会给你介绍几种亲测有用的方式，你可以把它们作为自己的“防身锦囊”。
+
+## 锦囊1：达成最小共识，变更是有代价的
+
+我刚到A团队的时候，交互妹子就可怜兮兮地拉着我说：“2个月过去了，我们的第一个版本还在打磨，80%的交互稿都已经改得大不一样了，越是临近上线越是不断地改。如果去跟策划们争辩，对方就甩过来一句‘老大要加的’，你说怎么办呢？”这个“老大”也就是A业务的负责人。他是产品经理出身，又是完美主义加说一不二的性格。于是，产品策划在团队中就有着绝对的话语权。
+
+在耐心地观察了一番之后，我终于等到了时机。在版本结束的复盘会之前，我跟负责人建议说：“你看，我们项目组是全新的团队，成立两个多月了，这么长时间运行下来，还是有不少问题的。我们需要一次深度复盘，这次复盘非常重要，你一定要来参加！”
+
+复盘会的当天，大家匿名写纸条，分别列出各个环节做得好与不好的地方，贴到白板上。看着满墙花花绿绿的便签，写满了各个角色对需求变更的各种吐槽，这位负责人沉默了好久。
+
+接着，我把事先准备好的表格拿出来，表格中记录着历次变更给团队带来的各项成本增加及引发的返工（如下表）。
+
+<img src="https://static001.geekbang.org/resource/image/52/60/52424a488710a87049f0d7d51e469b60.jpg" alt="">
+
+在复盘会接近尾声的时候，业务负责人当场发话：“从今天开始，团队里的需求变更要严格控制，从我自己做起！”在这之后，产品策划的随意变更行为显然收敛了很多。我也趁势在下一次的全员会上，跟所有团队成员约法三章，把复盘会上的共识，细化成了具体流程：
+
+1. 所有需求及所有变更必须建单，无单需求开发有权不接；
+1. 需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员；
+1. 对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道。
+
+你看，这么一来，大家对于需求变更这件事，就从上到下达成了一个基本共识，需求变更的压力也瞬间得到了缓解。所以，要想改变现状，首先就是**找到合适的时机，树立对变更的最小共识**。之所以说最小共识，是指这个共识不需要一步到位，如果在你的环境中确实比较困难，可以只是前进很小的一步，比如你可以从所有变更都需要记录，并公告周知开始。
+
+达成这个最小共识，是要让团队开始慢慢认识到，**需求变更是有代价的**。不过，毕竟产品仍然在探索期，变更总是在所难免的。
+
+怎么办呢？策划们开始想各种办法，好让技术能够顺利地接受变更。实验下来最有用的一招，莫过于请程序员们吃炸鸡了。当时坊间流传着一个段子：“没有一桶炸鸡解决不了的变更，如果不行，那就两桶！”在整体项目时间有要求的情况下，请程序员吃炸鸡，也确实成了项目快速推进的有效选择。作为项目管理，你要谨记，**我们追求的是达成项目目标，而不是零变更**。
+
+上面讲的这些，其实是变更发生之后的应对方法。那么，回到变更的源头，我们可以做些什么呢？
+
+首先，就是把关需求的质量，避免需求问题流到下游。我在第6讲中介绍的Bug Bash，就是一个好方法，建议你在一些大版本的需求设计稿完成时，发动团队的力量去做一轮全面的需求检查，让各个角色早期深度地参与到项目中，这对防治需求变更非常有效。
+
+## 锦囊2：源头治理，一次把事情做对
+
+有同学给我留言说，上线时间都是定死的，即便认真做了评审，发现了方案的很多问题，一改再改，最后压缩的还是开发时间。其实，要想真正把关需求的质量，还是得从源头开始治理。
+
+接下来，我来跟你分享一个几年前，我在某事业群启动中台建设项目的真实案例。这个事业群当时已经有三四年的历史了，伴随着多条业务线的高速发展，公共平台的架构频频遭遇掣肘。这个事业群的老大几经思索，下定决心花大力气快速进行整治。情急之下，他找到我，让我来负责这个超级复杂的项目。
+
+在四个月内，我们重整了这个平台积累了四年的整个业务和技术架构。当时时间非常紧张，，四五条业务线的产品和设计人员都会参与其中。作为新的中台架构，如果在后续执行中发生变更，往往会产生灾难性的影响。怎么办呢？
+
+我急中生智：“小黑屋集中开发呀！”不同的是，这次被关进小黑屋的，不再是苦哈哈的程序员，而是产品和设计人员。他们以前哪经历过这个啊？纷纷念叨着：“What？项目还没怎么着，先把产品和设计的deadline定了？！”于是，我找来那位老大站台，召集全员，开了次隆重的启动会。会议的第二天，十几位产品和设计人员就搬进来了。
+
+为了减少后期的变更，尽可能一次把事情做对，我们在小黑屋搞起了“上墙文化”，产品和设计的Deadline排期图、产品模块设计图、页面逻辑跳转图……还有各种设计草图，全都被搬上了墙。
+
+没过几天，这里居然成为了程序员午饭后驻足观赏的胜地。见到如此盛况，我们开始给他们准备各色小标签，让他们在游览的同时随时发表各种评论。大家的参与热情空前高涨，很多需求和设计的漏洞就在这里被提前发现、及时讨论并修改掉了，有效地保障了早期需求和设计的质量。
+
+其实，这个项目中每条业务线都有自己的策划，如果采用传统方式，这些需求各自成稿，再加上不同业务线的策划之间、策划和设计之间、设计和开发之间的沟通成本，不知道什么时候才能真正确认，也不知道会埋下多少变更的“坑”。
+
+不得不说，这个锦囊是个大招，使用起来有一定难度。但**从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式**。小黑屋 + Deadline的实践效果奇佳，在一些上线时间有严格要求的复杂项目上，你绝对可以考虑下！
+
+## 锦囊3：快试错，不可抗力巧应对
+
+学会了前面两个锦囊妙计，来自产品经理的变更就不在话下了。不过，现实情况是，很多变更来自大老板或大客户，这些不可抗力，我们又该如何应对呢？
+
+我的建议是，**不要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求**。你可能会说，说起来容易，那如果老板或客户还是一定要改怎么办呢？
+
+我的一个团队在被大老板的各种任性变更摧残了半年以后，终于痛定思痛：“我们一直想着法儿地对抗变更，大家都身心俱疲。反过来想想，其实老板也是人，老板也很痛苦，我们要给老板试错的机会，不是吗？”
+
+后来，我们不再一味地抗拒，不过也并没有放弃努力。相反，我们尽可能想办法降低试错成本。为了隔离老板的需求对整个团队进度的干扰，**我们在常规团队之外，组建了一个老板需求响应小分队，由团队轮流值班，协同提高响应速度，让老板可以试得快，试得爽！同时，对于那些我们并不太认同的老板需求，就快速尝试，先小范围灰度发布，再用对比数据说话**。当这一系列机制运转顺畅之后，我们慢慢发现，老板在提需求时，不会每次都火急火燎了。
+
+很多同学把这类来自老板的变更视为不可抗力，实际上，这背后还是有一定的改进空间的。你可以从建立快速有效的响应机制开始，同时多去总结和剖析这些需求背后的原因，毕竟老板要的是效果，那你就得用数据说话，更好地应对这些需求变更。
+
+## 总结
+
+这一讲，我给你分享了3条锦囊妙计，建议你从达成最小共识开始入手，让团队意识到变更是有代价的。然后，再往前一步，从源头开始深入，集中保障需求质量，争取第一次就把事情做对。另外，关于来自老板或客户的需求变更，你要快试错，巧妙应对。
+
+如果你把需求变更当作洪水猛兽，各种严防死守，那么最后，你很有可能身心俱疲。但如果你换一个视角，从失败中汲取教训，变堵为疏，那么需求变更就不再是你的敌人了。你会发现，那其实是一个产品不断走向完美的底层动力，从而找到更多的锦囊，帮助这个产品走向更大的成功！
+
+## 畅所欲言
+
+听了这么多锦囊，希望你聊一聊你和需求变更的“战斗史”，分享一下你在实战中最有效的方法！
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/硬技能篇/10 | 风险管理：如何系统化应对风险？.md

@@ -0,0 +1,118 @@
+<audio id="audio" title="10 | 风险管理：如何系统化应对风险？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fc/6c/fc1aced71262c57a342625d89fc47a6c.mp3"></audio>
+
+你好，我是雷蓓蓓，今天我们来聊一聊风险管理。
+
+其实，项目风险是一种不确定的事件或条件，一旦发生，就会对至少一个项目目标造成影响，比如范围、进度、成本、质量等，项目风险也可能对**组织或组织的目标**造成影响，比如财务、声誉等。
+
+项目从构思的那一刻起，就存在着风险。而应对风险的方式，并不总是规避。如果风险给项目造成的威胁在可以承受的范围内，并且与可能得到的收获是相平衡的，那么这个风险就是可以接受的。
+
+要想在充满不确定性的大环境下取得成功，组织应该致力于在整个项目期间，积极而又持续地开展风险管理。
+
+## 系统化风险识别
+
+**风险识别的主体，应该包含项目中的团队成员在内的各方干系人**，而不只是项目经理。组织中的每个层级，都必须有意识地积极识别，并有效管理风险。**系统化的风险识别，是一个反复进行的过程，应该从构思阶段开始，贯穿项目规划和执行的始终**。
+
+结合执行中常见的各类风险，我给出了一份项目典型风险列表，你可以在[网盘](https://pan.baidu.com/s/1PsjWdNi2A-UwIrcLkMnycA)中获取，提取码是q45a。你可以对照这个风险清单，对你的项目情境下可能出现的风险，进行概率及影响程度的量化分析，从而形成你自己的初始风险清单。
+
+识别风险过程的主要输出，就是初始的风险登记册，**包括已识别的风险清单，以及潜在应对措施清单。对于已识别的每个风险，都要评估其概率和影响，并进行优先排序**。
+
+其中，风险概率是指每个具体风险发生的可能性，风险影响则是风险对于项目目标（进度、成本、范围、质量）的潜在影响。
+
+<img src="https://static001.geekbang.org/resource/image/61/19/618f09c0f15d71f34fcaa51d356de119.jpg" alt="">
+
+> 
+图片来源：《项目管理知识体系指南》
+
+
+上图是《项目管理知识体系指南》中给出的，风险对项目目标影响程度的评估量表。其中，造成成本增加大于40%、进度拖延大于20%的风险，就属于最高影响程度级别的风险。
+
+你可以通过访谈或会议的形式来进行风险概率和影响的评估，参与人员包括熟悉相应风险类别的人员，以及项目外部的经验丰富人员。以下是一个风险登记册的示例：
+
+<img src="https://static001.geekbang.org/resource/image/04/14/04afc55480897f0fa5d1a1aa85e7d214.jpg" alt="">
+
+## 冰山下的风险
+
+实际上，执行中最大的风险，不是那些显而易见的、冰山上的风险，那些冰山下看不见的风险，往往才是最要命的。通常，项目组中最坏的情况是，大家对项目里的风险避而不谈，避谈风险的原因可能是：
+
+- 缺乏风险的沟通渠道
+- 提出来也没有用
+- 老板会认为自己没能力管好当前的项目
+
+试想一下，你的项目中鼓励坦诚沟通风险吗？你的项目中有恰当的程序和渠道，可以让你跟干系人沟通项目风险吗？
+
+**没有人反馈风险，不代表没有风险**。我曾经见过一个项目组，在某个时间段，他们的业务迅猛扩张，临时招了一大批实习生，从事内容基础建设工作。日常工作时，管理者只是把任务交待下去，跟这些实习生缺乏深度沟通。由于业务繁忙，很少有人带这些实习生，于是，他们逐渐形成了一个与外界隔绝的小集体。直到一次重要里程碑交付前，大量实习生离职，影响到了部门重要KPI的达成，这个群体才引起了部门管理层的关注。
+
+如果一个项目经理只能依靠正常的渠道识别项目风险，这类问题就不可避免。那么，如何识别冰山下的风险呢？
+
+其实，当寻常的渠道不管用的时候，就要看项目经理的信息网络了。项目经理一定不能脱离团队。如果没有群众基础，只是坐等着别人给你上报风险，那你的工作就远远没有做到位。
+
+一个优秀的项目经理，必须是一个优秀的“情报人员”，上至最高的项目发起人及组织的各层决策者，下至项目最边缘的人群，比如外包、实习生、短期借调支持人员等，你都要跟他们建立广泛且深入的联系。
+
+你可能会问：“我不擅长人际交往，是不是就没办法做到这些呢？”当然不是。有很多内向型的项目经理，也做得非常好。其实，**你需要的是一颗真诚交流的心，去关注项目中的每个角色、每个成员的需求，理解他们的困难，愿意为他们提供发展的机会，帮助他们去获得更大的成功，仅此而已**。
+
+如果说，你还需要一个简单有效的办法，**那你就先去观察一下，在吃饭的时候，你的团队分成了哪些群体**。这些自然划分的群体，哪些是你经常交流的？哪些是你缺少交流的？在工作之余，你要多关注和你缺少交流的群体，抽时间和他们多吃饭多沟通，让自己站在他们的视角想问题。这样一来，很快你就可以扩展自己对于冰山下项目风险的理解。
+
+**记住，你识别出的风险越多，项目的风险就越低。**
+
+## 风险应对措施
+
+接下来，你需要为识别出的每个风险，制定相应的风险应对措施。**对于发生概率很高的严重风险，一定要提前准备风险应对方案和危机应急预案**。一旦风险和危机来临，应急预案就可以有效地降低风险的损失和危机带来的灾难。
+
+比如“双十一”之前的故障演练应急预案，你就需要针对每一种可能发生的线上突发状况，提前确定好处理步骤、责任人、预计时长，甚至是每一步的指令或脚本，以免在出现突发问题时，手忙脚乱导致出错。
+
+同时，**在项目排期时，你要确保有相应的故障演练计划，并且做好充分的准备**。也许有些风险预案永远也用不上，但是这并不是说它们是多余的。在风险降临的危机关头，它们的价值就会凸显出来。
+
+在项目执行期间，已识别的风险会不断地变化，新的风险也会产生。你需要在每周的项目状态同步会议上，对风险进行再评估，并通过**周期性的风险审查，来识别新的风险**。
+
+## 树立正确的风险观
+
+### 
+
+**1.治未病，建立系统性保健机制**
+
+举世瞩目的“阿波罗”登月计划，让项目管理开始风靡全球。当时的肯尼迪航天中心，流传着两个很有意思的“黑话”：沙包、打伞。“沙包”指的是把任务的延期藏起来，不到最后一刻不做汇报；“打伞”是说虽然你延期了，但还有更倒霉的家伙也延期了，而且率先被暴露了出来。你看，即便在“阿波罗”计划里，瞒报延迟、寄希望于他人“打伞”也是无法杜绝的事情。
+
+可是，为什么会有那么多的瞒报呢？因为在当时，及时汇报延期往往只会招来一顿责骂。实际上，越是严格控制的系统，越是有问题都窝着藏着，很可能一出问题就是大问题。事物的发展，总是从量变开始的。为了防止风险演变成问题，就要在项目早期，建立系统性的保健机制。所谓的“治未病”，就是说要未病先防，**事后不如事中控制，事中不如事前控制。**
+
+“春江水暖鸭先知”，关于执行中的风险，群众永远是最有发言权的。如果这个系统是健康的，一定是可以自行去呈现和反馈风险的。而建立系统性保障机制的关键就在于，**你要致力于持续改善人与人之间的互动品质，提升项目团队的健康度。**
+
+经常做**匿名的问卷收集或访谈**，定期做一场坦诚布公的复盘会，都是系统性保健的好方法。
+
+做调查问卷，是项目经理了解团队的重要方式之一。在每个重要版本结束时，你都可以用调查问卷的形式，收集大家的意见，其中有两个典型的问题：
+
+- 对这个版本研发过程的综合评分（包括迭代方式、工作量、工作压力、团队配合、时间管理等各个方面），这反映了过程满意度；
+- 对这个版本功能设计的满意度，即产品认可度。
+
+**你要坚持在多个版本中反复使用，积累数据**。这样一来，你就可以通过各个版本的数据变化，看到团队状态的起伏和健康度的走势。当团队对产品的发展方向产生疑虑或不认可，抑或是对过程中的管理方式或协作状态不满的时候，你要允许团队各抒己见，充分沟通表达。事先预防永远胜过事后纠正，如果你有意识地在团队中构建这样的常规反馈渠道，系统性风险提示和保健的作用就会逐渐发挥出来。
+
+上医治未病，如果你还不具备“望闻问切”的功力，那么匿名问卷，就是一个非常简单的措施，你一定可以做到。
+
+### 
+
+**2.积极管理致命风险**
+
+其实，项目经理不是只要管理好常规执行风险就可以了，真正会导致项目失败的致命风险，往往在项目一开始就埋下了。比如，公司高层对于项目的态度和预期、项目目标与组织战略目标的一致性、项目所依赖的重要资源方的合作关系、竞争对手及行业市场状况的变化、政策变化、监管风险等。
+
+我作为项目经理的第一个项目，开工半年多就被紧急叫停，这让我对项目的致命风险有了深刻的体感。要管理好这些致命风险，确实不是仅凭项目经理一人之力就可以做到的。但是，如果我们只是一直做容易的事，做会做的事，对这些致命风险视而不见，就会把项目置于危险的境地。
+
+一旦致命风险真的发生，很可能会回天乏力。有经验的项目经理，可以从过往经历的失败中，敏锐地嗅到危险的味道。那么，项目经理可以做些什么呢？
+
+- 第1步：**挖掘出这些致命风险，把它们变为可见的、可谈的**。很多管理者非常关心执行中的风险，却对于这类致命风险讳莫如深，只留在自己脑子里，这样反而是最危险的。致命风险的挖掘，通常会让我们对项目背景的理解更加透彻，并对那些影响到项目生死存亡的关键要事，有更加清晰的认知和规划部署。
+- 第2步：**正视风险，不存侥幸心理**。你要和发起人一起想办法，发动核心团队，合力去制定应对策略。
+- 第3步：**在项目的核心团队中，周期性地梳理和同步风险状态**。
+
+其实，在互联网领域，成功突围者大多都是一路坎坷，从各种致命风险中爬出来的，堪称九死一生。致命风险的存在，本身就是一种警醒。**加速构建核心能力，不断拓宽“护城河”，才是最根本的应对之道**。
+
+## 总结
+
+总结一下，今天，我给你介绍了系统化风险识别的方法，以及项目典型风险列表。根据风险概率和影响，你需要召集项目组成员完成风险登记册以及风险具体评估，制定相应的风险应对措施及应急预案，同时对冰山下的风险保持敏感。
+
+实际上，风险是一种不确定的事件或条件，用辩证的眼光看，风险的另外一面就是“机”。互联网领域的产品创新，大多是一场跳进未知的冒险，这给传统的风险观带来了极大的冲击。在项目管理的过程中，步步为营的风险管理之外，积极把握不确定性带来的机会，提升系统的反脆弱能力，达到最优的效果，是项目经理需要持续修炼的功课。
+
+## 畅所欲言
+
+最后，我想请你来聊一聊，你自己所在的项目组中，是否存在冰山下的风险？你有哪些识别风险的好办法吗？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/硬技能篇/11 | 质量管理：一次把事情做对！.md

@@ -0,0 +1,95 @@
+<audio id="audio" title="11 | 质量管理：一次把事情做对！" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/53/61/53dfb7864612e7b93a76434aec4ba961.mp3"></audio>
+
+你好，我是雷蓓蓓，今天我们来聊一聊质量管理。
+
+说到质量，很多人会说：“工期太紧了，能按期提测就不错了，Bug多一点也正常。质量好不好？不好说。如何提升？不知道，QA会保证的呀。”
+
+我见过的大部分程序员，对自己的代码质量要求还是很高的。但是，一旦遇到赶工压力，尤其是在deadline之前，就很可能会把完成度很低的代码交出去，心想“反正有人给我检查，到时候再说吧”。但是，这些代码就好比是一台“行走的Bug制造机”，后患无穷。
+
+我曾经在一个技术债特别严重的部门中，面向各级程序员做过一轮抽样的访谈调研。调研的结果是，程序员们只有27.2%的时间在做真正产生价值的编码工作。但是，他们有20.7%的时间，是在做需求质量和代码质量问题所引发的Bug修复、返工和紧急上线工作。
+
+质量成本分为两类：**一类是事前防止失败的一致性成本；一类是事后处理失败的非一致性成本**，包括内部Bug引发的返工成本，以及外部Bug导致的用户侧成本。
+
+近些年来，越来越多的公司在严格控制测试人员的比例，鼓励开发人员通过各类技术手段从上游保障质量，就是因为越发地认识到：**事后检查处理的代价其实是最高的**。
+
+实际上，质量是规划、设计、建造出来的，不是检查出来的。**预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多**。
+
+我们都知道，一次性把事情做对的成本是最低的。而一次性把事情做对就意味着，我们要有意识地提升预防类工作的占比，从根本上降低内部Bug率和外部Bug率。在这个质量改进的过程中，程序员是绝对的关键力量，而非测试人员。
+
+那么，作为项目管理人员，你该如何更好地规划质量管理活动呢？总体来说，你可以从三个方面入手。
+
+## 质量规划，明确标准
+
+**规划质量，是识别项目及产品的质量要求和标准，并确定用哪些保障方法、改进措施来达到这些标准的过程**。
+
+需要注意的是，**在业务生命周期的不同阶段，质量标准应该是动态变化的**。比如，业务初创期追求的是最小化MVP模型的快速迭代，在这个阶段，质量往往不会是最关键的因素。但是，当规模扩张到一定程度之后，对于质量的要求就非常高了。不同的项目对质量的要求也相差甚远，无法一概而论。因此，**只能结合具体项目和具体阶段的质量诉求，对质量的标准进行合理定义**。
+
+你可以参考一下下面这张图片，它展示的是，一个已经进入规模增长期的稳定业务对客户端质量标准的定义。
+
+<img src="https://static001.geekbang.org/resource/image/b3/54/b3eac72d259179a7a6a3d4f085c03854.jpg" alt="">
+
+定义好了质量标准，你要思考的是，在整个项目的进程中，需要规划好哪些质量保障活动，以很好地达到这个标准。
+
+我给你分享一张各个阶段的质量保障手段的列表图。
+
+<img src="https://static001.geekbang.org/resource/image/5e/64/5e1efb123b6e73cd3eb3bf9f248ea464.png" alt="">
+
+其中，你需要特别关注研发过程中的质量保障手段，制定适当的编码规范、提交规范和分支规范，同时设计代码准入标准，确保代码Review、单元测试、接口验证和UI验证等手段与你的项目质量要求相匹配。
+
+项目经理的视角始终聚焦在项目的整体目标上。在项目经理看来，质量作为目标的一部分，达到要求是最重要的，不需要追求质量的无止境提升。因为，质量终究也是有代价的，是否够用则取决于项目目标和要求。
+
+## 质量分析，追根溯源
+
+质量分析，是指识别项目运行期间，整体质量上遇到的问题和制约因素，分析根本原因，并制定相应的预防措施和解决方案。
+
+我曾经给一个底层核心模块的技术团队做项目管理，但我经常听到上层模块抱怨它的质量，有时候甚至在关键流程上都有问题，团队内外都对其质量失去了信心。
+
+从数据上看，这个模块的线上Bug量占项目总Bug量的17%，给上层其他模块和运维都带来了不少麻烦。随着越来越多的外部应用陆续接入，如果这个问题得不到有效解决，内部矛盾很可能就会升级为外部矛盾，不容忽视。
+
+经过深入分析，我对频发的质量问题有了以下认识：
+
+1. 团队扩张得很快，在相当长的时间内，测试人员的配比都非常低，8个开发对应0.5个测试。测试基本上只是给开发打工，只能保证最最基本的功能，其他更深度的测试类型根本无所涉猎；
+1. 团队没有从用户的视角来检验产品，上层模块的应用场景、运维的应用场景与测试的视角相差较大，测试效果很难保障；
+1. 约有五分之一的线上Bug，是来自社区，用户侧出现问题以后才去社区找，再把这个补丁合进来，没有主动应对。
+
+同时，我也做了用户调研，最终的结果显示，用户对底层核心模块的期望更多的是稳定，至于新功能，用户普遍表示暂时没有需要。因此，盲目增加复杂功能其实并不明智，保持产品简单可靠才是王道。
+
+定位完问题，我们就可以采取相应的措施进行改进或预防了。
+
+1. **新功能适当放慢**：在基本功能已经成型的情况下，进一步控制新功能开发在迭代中的占比与优先级。当时我们定义的是不超过70%，在一定时期内，核心功能不再做大的变动。
+1. **回顾总结**：将线上Bug分析作为周会的一项固定内容，集体讨论出整体层面上的改进措施，并跟进实施到位。
+1. **查漏补缺**：对已有的测试用例进行全面梳理，与相关的开发、测试、运维一起集体review，花大力气补充测试代码（增加异常、并发、稳定性测试等）。考虑到这是一项长期工作，要确保将其分解到各个迭代中，分批实施。
+1. **走到前面**：紧密跟进社区Bug，分析重现并评估影响，定期总结梳理，并组织讨论应对措施，主动引入必要的补丁。
+1. **以终为始**：新功能需求确定后，测试用例同步设计并进行review，然后开放冒烟测试标准，让开发人员在明确“什么是完成”的前提下，进行开发。
+
+在坚持了两个月之后，整体的质量状况好了很多。总体来说，质量分析最重要的是要追根溯源，找到问题症结。我给你推荐几种简单实用的方法。
+
+1. **每月坚持开线上Bug分析会**。你可以召集产品、研发、测试，一起对过去一个月的线上问题，进行深入的根因分析，制定策略并推进落实。
+1. **持续进行内部Bug分类**。从不同维度分析Bug原因，你可以按照具体引入阶段给Bug分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发的覆盖升级、历史遗留等，也可以按照Bug类别分为功能问题、性能问题、界面问题、兼容性问题等。从数据统计上，你就可以准确地知道，自己项目的质量问题主要出在哪个环节，下一步是要先规范代码准入标准，还是加强需求评审，以及哪些保障措施会更有效。
+1. **建立质量大盘，拉通不同业务线或模块的每月Bug趋势**，对齐千行代码Bug率、Bug数/需求数的比率、Reopen Bug率等，对低于平均线下的业务线或模块进行有针对性的原因分析。
+
+## 质量控制，层层卡点
+
+如果说质量分析的要点重在追根溯源，那么质量控制，就是将一些明确下来的质量规范和做法，真正落地到各个环节。我给你分享一张样例图，它展示的是从需求到发布的整个过程中的质量活动概览。
+
+<img src="https://static001.geekbang.org/resource/image/97/80/970cbd9cdcfb94f6e9a8a8522f225d80.png" alt="">
+
+想要推动质量改进措施的落地，与之相匹配的工具是必不可少的。在网易，我们使用PMO自主设计开发的企业效能平台Overmind，来完成持续集成和持续交付，并在需求到发布的整个链条中，层层设置相应的质量卡点。你可以根据实际需要，逐步为自己的应用定制合适的持续集成方案，指定代码准入的阈值，比如静态扫描、单元测试、覆盖率测试、冲突检测、Jar包版本检测的通过条件等。
+
+<img src="https://static001.geekbang.org/resource/image/d9/ef/d9c5f2dbeb98d389a0ba651ff26935ef.png" alt="">
+
+需要注意的是，**质量控制及卡点行为，是要结合项目的质量要求和团队的质量成熟度，一层一层地加强质量把关和收口**。即便是在同个项目的不同应用中，也会因为线上要求的不同，而对质量卡点有不同的侧重。通过质量卡点的在线工具化，才能做到真正有效的质量保障。比如，某些团队在特定阶段，会按照静态代码扫描问题的级别来分级计算缺陷值，提交测试申请时，如果系统检测到缺陷值有升高，就不能够成功提交。
+
+## 总结
+
+今天，我跟你分享了项目经理在质量管理过程中的工作，你可以从三个方面入手，分别是质量规划，明确项目的质量标准；质量分析，追根溯源，找到质量差距的根本症结；质量控制，在需求到发布的过程中，设置层层卡点来控制质量。
+
+要想一次把事情做对，你首先得明确什么是对，然后要分析差距，找到相应的质量保障方法，并不断迭代。这三个方面是个螺旋式循环上升的过程，你需要不断地根据质量分析的结果，设置合适的质量卡点，直到达到规划中的质量标准。
+
+## 畅所欲言
+
+最后，我想请你来聊一聊，你所在的项目中技术债的整体情况。另外，你在实践中有什么好办法，来持续保障质量吗？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/硬技能篇/12 | 高效会议：项目中要开好哪些会？.md

@@ -0,0 +1,147 @@
+<audio id="audio" title="12 | 高效会议：项目中要开好哪些会？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6a/fe/6aa8e6dc5a80d9080877ad2f82dacdfe.mp3"></audio>
+
+你好，我是雷蓓蓓。这一讲，我们来聊一聊项目中的会议。
+
+从事项目管理工作之后，你会发现自己一下子多了很多大大小小的会。项目全局涉及到的整个过程，你都要去了解。很多人说，项目经理有80%的时间都用在了沟通上，不是在开会，就是在开会的路上，其实所言不虚。
+
+会就是聚会、见面、集会，议就是讨论、商议，会议作为一种群体沟通方式，决定了正式信息在项目组内的传递路径。实际上，我们的会议，就像现代人的营养一样，过剩了。我们知道，营养过剩就会吸收不进去，那么会议过剩了，会怎样呢？
+
+如果我们把项目组看成一个有机体，这个有机体承载不了那么多的信息，后果就是会而不议。会上说了一堆，却没有决议，没有动作，那么这个有机体是没有办法正常运作的。怎么办呢？
+
+答案就是“**断舍离**”，**只开最有必要的会，会而有议，议而有决，决而有行**。会议不在多，而在于精，每个会议都要真正开出效果来。
+
+## 项目中的重要会议
+
+其实，“断舍离”是一种思维习惯，也就是说，**你要有意识地选择，最适合项目现阶段状况的会议**。
+
+项目过程中有大大小小的会，我把这些会议汇总在了下面的这张图片中，你可以看一下。实际上，这些会分别服务于不同的目的。之前我讲过复盘会、评审会，我们今天重点来看启动会、每日站会和项目周会。
+
+实际上，只要掌握了这些类型的会议要点，其它类型的会议也就不在话下了。
+
+<img src="https://static001.geekbang.org/resource/image/36/c8/364318f76feb43e22d9a2c57336ee7c8.jpg" alt="">
+
+## 启动会
+
+启动会好比是誓师大会，用来快速地聚拢兵力，集中力量干大事！
+
+我曾经经历过一个项目，因为战略调整和重组，这个团队的规模，迅速地从十多个人扩张到了一百多人。这个临时拼凑的百人军团，大多是自上而下从各个部门紧急征集来的。看起来人很多，但因为角色身份混乱，工作习惯不同，团队内部存在着各种冲突和困惑。在这样的情况下，一场启动会就是非常有必要的。那么，怎么做启动会呢？
+
+**启动会的目的是清晰目标，明确授权**。要做到这一点，你需要分三步走，分别是why、what和how。
+
+其中，第一步why是最难讲好的。但实际上，**只有充分理解了项目背景、目的和意义，才能更好地唤起团队的参与热情。**
+
+那个项目的启动会，我们特意邀请到大老板亲自上阵跟大家讲述项目背景。他从公司战略赛道的选择性聚焦，讲到自己对这个事业的追求，话语中所传达出的重视、关注和热爱，是让这个why真正打动人的核心要素。
+
+接着是what，**描绘蓝图，设定清晰的愿景**，包括项目的三年目标、五年规划，越清晰越好，为的是让团队看到未来的样子。
+
+你可以使用直接讲解的方式，也可以采用更加互动的做法。比如，我们曾经组织大家基于项目的背景信息一起共创，分组画画，共同畅想未来的愿景。这种画面感，会形成一种深刻的体感记忆，让大家在开始做事之前，就先有了沉浸式体验，效果非常好。
+
+最后一步是how，**也就是明确团队之间的责任分工以及合作公约**。
+
+对于一些新组建的团队来说，也可以加入一些破冰的环节，让大家打破边界，尽快建立新的协作模式。你还可以留一些时间给重要的角色代表发言，大家的热情相互感染，会让士气空前高涨。这时，启动会的效果就达成了。
+
+关于启动会的内容，你可以从以下十个方面着手准备：
+
+1. 项目背景
+1. 项目目标
+1. 项目范围
+1. 里程碑计划
+1. 主要风险
+1. 组织架构
+1. 责任分工
+1. 流程机制
+1. 沟通方式
+1. 支持工具
+
+其中，沟通方式指的是，会议的时间安排、频率及参与人员；支持工具一般是指项目组统一使用的任务管理、文档管理、代码管理的工具。
+
+需要注意的是，**只有在新项目或新阶段准备启动，涉及到方向、目标、人员、职责的调整的时候，才需要开启动会来进行公开的澄清和授权**。我跟你分享一份启动会的PPT模板，你可以点击[网盘链接](https://pan.baidu.com/s/1Yt7Ps3EpT84faZuauzEkOQ)获取，提取码是v1da。
+
+## 每日站会
+
+随着敏捷的普及，每日站会的概念也是深入人心。然而，很多站会被当作是例行公事的汇报会，枯燥无味，还有一些站会开得冗长且低效。
+
+**其实，开好站会的关键，是要还政于民。站会满足的是团队的自组织需要，而不是leader的监控需求**。
+
+那些把站会开得很持久的团队，往往已经形成了自我管理的氛围，团队每天会通过站会了解整体状态，并对暴露出的风险和问题做出集体决策。
+
+作为项目管理人员，你要引导团队不断建立和完善自己的规则，并在运行顺畅之后，把站会还给大家，让大家自己决定站会要怎么开。
+
+早期我带过一个团队，经过反复尝试，大家决定把站会的时间放在午饭前的11:30开始。这样一来，团队成员可以有相对完整、不被打扰的整个上午的工作时间。另外，吃饭的动力也会让大家集体加速，从而保障站会的高效。如果有一些争议性的话题没有解决，午饭时也可以继续讨论。
+
+**其实，真正自我管理的站会，除了团队成员自己决定站会时间之外，连主持人都是成员轮流来当的**。为了让每个主持人都能把站会开好，有效把握会议节奏，经过长期的实践，我逐渐摸索出来一套“三张牌”式站会法。
+
+站会开始时，主持人将红、黄、绿三张牌分别发给所有的与会人员。在整个站会的过程中，任何人都可以随时举牌来行使自己的权利。
+
+- 举“红牌”：表示叫停谈话，避免过度的讨论和无结果的时间浪费，提高站会效率；
+- 举“黄牌”：表示打断讨论，进行提问，向发言者了解协同及依赖的信息；
+- 举“绿牌”：这是一个token牌，代表每个人的发言权。每次只有1个人发言，按顺序来，将此牌归还给主持人表示同步完毕。
+
+当所有的“绿牌”都已归到主持人手中，而且没有更多疑问的时候，站会就可以结束了。
+
+这样简单的游戏规则，既可以帮助主持人有效地把握节奏，同时还把会议控制的权力和责任交给了与会的每一个人，任何人都可以对过度的讨论随时喊停，从而让站会在“有用”的同时又能保持“高效”。
+
+## 项目周会
+
+通常情况下，对于10人以内的小团队来说，如果已经有了每日站会，就不太需要再另外设置周会了。
+
+但是，当项目组的规模继续扩大，分成了若干的工作小组之后，你就需要利用项目周会，周期性地对项目的各个角色、各条线的进展和风险做全面的检查了。
+
+**项目周会的目的，是解决整体计划层面、跨团队协同配合的问题**，包括产品、运营、市场、研发等环节。由于项目周会是面向各个角色负责人，甚至面向全员的全局性会议，所以，项目周会就天然地成为了一个最能直接把控整体脉搏的地方。
+
+项目周会的内容，除了常规的各角色进度和风险同步之外，你还需要**根据项目组每个时期的整体阶段性重点，来设置相应的环节，让大家清晰地感受到项目组明确的导向，也就是什么是当前最重要的。**
+
+比如，业务初创期，我们每周会一起关注业务数据的实时变化，针对有问题的部分，各个角色及时联动调整策略；对于一些技术保障类的业务，则会每周重点关注客户反馈的工单数据和服务保障SLA的变化；对于ToB类业务，会重点关注付费率、续费和丢单情况的最新变化，从而及时找到问题，快速联动解决。
+
+为了方便你更好地操作，我跟你分享一些项目中常见会议的流程模版，包括需求评审会、技术方案评审会、排期会、站会、周会等，你可以点击[网盘链接](https://pan.baidu.com/s/1N9hCUbWp4Mmu_n8aDApcuA)获取，提取码是4xr2。
+
+## 保障会议品质的关键
+
+实际上，会议的品质，很大程度上可以看出一个项目团队的互动品质。把会开好，看上去很简单，但其实并不容易。我的经验是，**不要盯着会议的数量，而是要追求会议的品质**，这里有三个基本要素。
+
+**1.明确会议边界**
+
+**每个会议都有特定的主题和目的，并有明确的参会人员范围，这个就叫会议的边界**。
+
+你可以写下目前参加的每一个会，问问自己：“为什么要开这个会？会议的边界是什么？哪些议题适合在会上讨论？”对于那些与主题不相干的议题，你要坚决舍弃。
+
+我见过过很多会议，要么是流水账式的汇报状态，一大半人在那儿玩手机、看电脑，要么就是进入了技术细节讨论状态，过分纠结于细节，争执不下，早就偏离了会议主题。这些都是会议边界定义不清的问题。
+
+**想要彻底改善，项目经理要做好两个确保**：
+
+- 确保各部分的进展信息在会前统一提交，会议当场只说重要问题、风险及需要支持的地方；
+- 确保会议当场严格围绕主题开展，对偏离主题的讨论，及时叫停！
+
+另外，参会的人，也应该是有边界的，并不是越多越好。**相关问题的主要决策人，对这个问题有责任的相关人员、负责执行决议的人员是必须参与的**。发送会议邀请时，你要明确哪些是必须参与的人员，并抄送那些可以选择参加的人员。
+
+**2.建立会议规则**
+
+我们曾经做过一个“会议小恶魔”的游戏，就是让每个人想尽办法地破坏会议，借此去体会开好一个会，需要哪些要素。结果我们发现，像迟到、拖堂、开小会、看手机等行为，问题虽然不大，但是频繁发生的话，就会大大地影响会议品质。
+
+特别是对于一些周期性的常规会议，约定好会议规则是非常有必要的。主持人要引导大家建立会议规则，对于迟到、请假、拖堂、跑题等行为建立公约，并成为规则的守护者。
+
+我身边有些做得好的项目周会，光是会议规则就已经迭代过五六个版本，从迟到红包、拖堂红包开始，到轮流担任“规则守护大使”的角色，最后发展成由主持人判定违反会议规则者，即自动成为下次会议的主持人……不得不说，这一招真的很管用。规则上的推陈出新，在活跃了氛围的同时，还共同构建出了高效的会议品质，最终是对每个人的时间负责。
+
+**3.做好会后跟进**
+
+要想真正做到决而有行，最终靠的是有效的会后跟进，真正把决策落到实处。
+
+会议主持人要及时汇总讨论的结果，并形成会议结论。对于无法当场确认的问题，一定也要进行记录，并明确跟进人和完成时间。**会后所有跟进事项，直接进任务系统，确保跟进到底**。同时，要在会议纪要的邮件中明文呈现，下次会议统一回顾。
+
+## 总结
+
+今天，我给你介绍了项目中要开好的重要会议，以及保障会议品质的三个要素。
+
+有同学给我留言说，自己的团队是按照敏捷的框架来开会，每个会都开了，可最后团队都觉得流于形式，组织者也觉得索然无味。
+
+其实，这并不是敏捷方法的问题，流水不腐，户枢不蠹。没有什么东西是一成不变的，会议设计和流程，也需要根据项目各阶段的情况做相应的调整。既然项目的状态和团队的状态一直在变化，那就要根据这种变化去动态调整，想清楚我们到底要开哪些会？不开哪些会？怎么把会开好？
+
+只要你**坚持只开最有必要的会，开真正高效且产生决议的会**，大家不但不会排斥，还会积极参与，会后还会有“这么短时间就达成一致”的满足感！所以你看，会议不是目的，借助会议去做好群体沟通，让大家看到有效的进展，才是最重要的。
+
+## 畅所欲言
+
+请你根据“断舍离”的理念，梳理一下你自己在组织的会，特别那些你自己在内心深处都认为是例行公事的会。然后，请思考一下，哪些会是要舍弃的？哪些会是必要的？接下来，你打算如何开好这些会？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/硬技能篇/13 | 故事案例（上）：新手上路，如何引入变化？.md

@@ -0,0 +1,199 @@
+<audio id="audio" title="13 | 故事案例（上）：新手上路，如何引入变化？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e3/ad/e324a67006ea286cd6a3a0f40eee27ad.mp3"></audio>
+
+你好，我是雷蓓蓓。今天，我们来聊一聊新手上路，如何引入变化。
+
+在留言区，我非常高兴地看到，很多同学已经开始动手实践了。而且，我还了解到，极客时间的研发同学，就把复盘会玩出了新高度。
+
+但是，很多同学在学习之后产生了新的困惑：“我该怎么把这么多的好方法，引入到自己的团队中呢？”
+
+其实，想要引入变化，你并不一定非要是项目经理，或者是有多么大的影响力。今天，我会给你介绍一些每个人都可以学得会的实用方法，帮助你更好地引入变化，尽可能地降低你在尝试过程中的碰壁概率。
+
+新手上路，要想引入变化，简单来说，你需要“天时、地利、人和”。
+
+**首先是“天时”，也就是合适的时机**。时机或早或晚，都会让引入变化的阻力成倍放大。早了，大家还没意识到问题；晚了，他们又找到了可以将就的办法，逐渐形成了惯性，并视为理所当然。那到底什么时候才合适呢？我们先来看一段典型的故事案例。
+
+> 
+小云在半年前刚刚升任项目经理，他跟进的第二个项目，就遇到了麻烦。眼看着距离版本发布的日期只剩两天了，任务系统上还显示着有好几项关键任务并没有完成，之前明明说是这两天就可以弄好的。结果到现在，讨论了一个小时，最后才敲定先用加缓存的方案处理。可这么下来，再加上测试，两天肯定搞不定，要把这个版本做完，恐怕是无望了。
+
+
+> 
+在整个团队中，似乎只有小云一个人在意，目标是不是可以达成。老实说，在做项目经理的半年里，他经常感觉自己脑门上写着“监工”两个大字，非常着急，可又觉得无处使力，只能一个一个去催。那么，这个困境到底要怎么破呢？
+
+
+> 
+一个念头瞬间击中了他：“对了，开每日站会啊！”小云一个鲤鱼打挺，从床上蹦了下来，连忙打开电脑，却马上又陷入了沉思。
+
+
+> 
+以现在的形势来看，跟团队提出要每天开会？小云都可以想象到大家的反应：“开什么玩笑？活儿都干不完，为啥每天开会？安静写会儿代码不行吗？”
+
+
+> 
+是啊，现在缺的就是这个“为啥”，也就是why，可总不能跟大家说为了方便自己跟进问题吧，那样大家会买账才怪！小云心想，这次我得讲究“策略”。
+
+
+好了，现在我要划重点了。
+
+很多同学都觉得，自己的项目组中有着这样那样的问题，而且，问题简直太多了。于是呢，自己一看到问题就想去改变，就想去整治，就觉得这是一个机会。**实际上，问题并不等同于时机，只有把问题和痛点关联起来，才能形成一个好的时机**。
+
+那么，怎么关联呢？我们接着来看故事进展。
+
+> 
+高峰是这个部门的技术总监，当初就是他把小云提拔到项目经理的位置上的。
+
+
+> 
+在每周一次的周会上，高峰和小云的问题特别得多，不知不觉两个小时就过去了。直到预定的会议室到期，他们被撵了出来，状态还没有同步完。
+
+
+> 
+会后，小云叫住了高峰，直接跟他谈起了自己对目前境况的担忧：“现在我们每周开一次同步会，总感觉信息滞后得很。如果我们的同步频率再高一点，就能够提早发现问题，现在也不至于大费周章了。”
+
+
+> 
+高峰没有直接回应，对于小云的建议也不置可否。在他看来，信息同步的问题虽然有，但整体其实还好。
+
+
+> 
+小云猜到了高峰的心思，进一步说：“如果只是开发的问题，倒还好办，可是一旦涉及到其他角色、其他模块的支持，事儿就难办了。我们喊了很久要加强测试，加强运维，可也只是喊喊，喊完之后就没了下文。现在，我们产品的基本功能已经成型，质量和运维才是重中之重啊。”。“没错！”高峰坚定地说。可见，小云的话一下子戳中了高峰的痛点。
+
+
+讲到这里，我要停下来“敲黑板”了。小云第一次和高峰聊到信息同步滞后的问题，对方虽然也知道这里有问题，可显然并没有什么改进的动力。
+
+有同学给我留言说，自己跟老板反馈了一堆问题，老板虽然是认同的，但最后往往就没了下文。
+
+**其实，之所以不能产生改进动力，只能说明，你还没有抓准痛点。**
+
+所谓痛点，简单地说，就是必须及时解决的问题，包含着强烈的迫切感。**判断是否是痛点的标志，就是看这个问题，如果不解决，对方是否会很苦恼、很痛苦。**
+
+小云之所以在意这个问题，是因为这是他的痛点。作为项目经理，小云迫切需要一个抓手，去实时跟进项目的动态，这个问题不解决，小云就会非常痛苦。状态更新不及时，的确是个问题，但这显然并不是高峰的痛点。
+
+真正让高峰苦恼和痛苦的，不是开发状态更新不及时，而是在整体全局的高效协同上，还存在着很多问题，这个才是他真正的痛点。
+
+**要想促发别人的行动，你必须换位思考，去体会和抓住他的痛点**，这才可能一击即中。那么，怎样才能抓到痛点呢？我跟你分享几个方法。
+
+**1.访谈法，也就是直接问。**
+
+我在[第4讲](https://time.geekbang.org/column/article/161108)中，给出了针对不同干系人的问题列表，你可以参考一下。其中，最重要的问题是，“你认为项目组当前最大的风险和问题是什么？从你的角度出发，最迫切需要解决的是什么？”
+
+**2.观察法。**
+
+实际上，与其看别人怎么说，不如看他怎么做。很多时候，人们会说这个很重要，但是一两个星期过去了，他也没有投入任何精力，那么这就是个“伪痛点”。这里有一个简单的方法，就是**去观察那些花他时间和精力最多、他反复强调却又没很好解决的问题，那些才是他真正的痛点**。
+
+**3.同理心和倾听。**
+
+只有你用心倾听，设身处地去理解他人，你才能够准确地感知到他最大的痛点。需要注意的是，抓痛点的过程，并不是一蹴而就的，你需要多观察、多了解，通过非正式的聊天，了解他们对潜在变化的态度，找到合适的契合点。
+
+实际上，**在变革的早期，最重要的就是寻找到早期支持者**。**围绕着你想要引入的变化，击中几个重要干系人的痛点之后，这个时机就到了**。由早期支持者形成的变革核心团队，就会成为你在推动变化过程中的重要支撑力量。
+
+好了，我们继续往下看故事。
+
+> 
+小云心想，终于等到机会了。于是，他把各个角色一起每天开站会的想法，一股脑儿地全告诉了高峰，双方顿时一拍即合。
+
+
+> 
+高峰觉得，这的确是个好办法。考虑到人数众多，他们又一起商议了很久，觉得还是有必要分两组来开站会。
+
+
+> 
+高峰说：“要不我们一开始还是两天开一次，两个组错开进行吧？”小云知道高峰在顾虑什么，连忙回说：“刚开始的确需要慎重些。”
+
+
+到这里，我就要讲到**引入变化的第二点“地利”，也就是说，你要学会因地制宜**，结合团队的实际情况，为团队定制适合的解决方案，而不是照搬理论或所谓的“最佳实践”。
+
+在这个故事中，小云与高峰决定分成两组开站会，每两天轮一次。实践中，你首先要去理解每个团队现有做法背后的历史原因和必要性，**结合每个项目团队的现状，做好本地化的场景适配**，这样才能获得好的效果。
+
+因地制宜的适应性调整，并不是向环境妥协，而是**创造一个最小阻力的落地方法，先快速地跑起来，让团队感受到变化带来的闭环成效**！
+
+> 
+与高峰统一战线之后，小云信心大增。于是，他立刻找来了几个测试，想聊聊看测试这边怎么分组好。几个人坐定后，小云说道：“现在大家都坐得很近，但是团队之间的沟通似乎并不是那么顺畅，我跟高峰商量着，想要引入每日站会。”一句话还没说完，测试巴泰插话说：“我觉得现在的沟通挺顺畅的啊，有什么问题？”
+
+
+> 
+高峰见状，赶紧出来打了个圆场，说：“咱们现在的沟通方式是有事就喊上两嗓子，快是快，可是很多事情喊过之后，经常就没下文了。”
+
+
+> 
+小云接着说：“是啊，就比方说，开发改个Bug没改好，测试等着去测，只好去问开发，开发说正在修，但几天过去了还没动静。再一看，开发已经忘了这茬儿，做其他的去了。这种情况，我想测试肯定碰到过，但我猜，巴泰你也不好意思一次次地去问吧。”
+
+
+> 
+其他两个测试点头应和，说确实是有这个麻烦。
+
+
+> 
+小云继续说：“可是，如果我们每天开站会，花15分钟互相同步下进展，问题很容易就解决了。测试不需要再去找开发催进度了，因为每天开站会的时候，开发自己就会讲进展。如果测试需要开发重新安排开发顺序，也容易多了。”看到巴泰若有所思地点着头，小云就知道，测试这边已经ok了。
+
+
+> 
+接着小云又找到运维同学，把站会的好处说了一遍，有了高峰和巴泰的支持，进行得还算顺利。
+
+
+现在，我就要讲到**引入变化的第三个关键点了，也就是“人和”**。
+
+研究表明，企业变革失败的最常见因素就是人的阻力。面对变革，每个人都有与生俱来的情绪反应。这个情绪，是自动触发的，跟变革的大小无关。大到企业战略转型，小到仅仅是改变一个会议的方式，只要是引入变化，就会触发情绪反应，人们总是需要一个接受的过程。
+
+那么，如何在引入变化的过程中，最大程度地创造出“人和”的局面，让大家更容易接受呢？**解法就是多聆听彼此，充分理解，找到共同的出发点**。
+
+现实中，很可能你觉得是对的事情，不同人去看，会产生完全不同的看法。**在沟通时，你要因人而异，针对不同的人，采用不同的策略**。
+
+那么，如何选用合适的沟通策略？
+
+答案是，先判断立场！**立场，是指人们在认识和处理问题时所站的位置。立场不同，看问题的视角就不同**。
+
+在具体操作时，你可以**把变化涉及到的干系人，按照角色和层级做个初始划分，思考下不同区域的人，会怎么看待这个变化带给他的影响**。
+
+你要做的就是，**找出更多的积极因素**。比如，通过开站会，测试可以更及时地获知和影响开发的进程，这对于测试来说，就是一个积极因素。同时，对于变化所带来的消极因素，你要提前引入相应的工具或方法来规避或改善。
+
+除此之外，就算是立场一致的两个人，也会因为基本假设和价值观的不同，对同一件事有不同的解读，从而呈现出截然不同的态度。
+
+**所以，在大范围公布并引入变化之前，与关键角色进行一对一的沟通，是更稳妥的做法。**
+
+看到这里，你可能会很好奇，故事中的小云进展如何了？别着急，我们一起接着看故事。
+
+> 
+这天，又是一次例行周会。同步完状态之后，近两个小时已经过去了，屋里闷热得很，大家都有些焦躁，有人凑在一块儿开小会，有人低头玩手机。
+
+
+> 
+小云感叹道：“现在我们每次周会的时间好长啊，一转眼，两个小时就没了。”大家早已经开会开得有些生厌，经小云这么一说，纷纷吐起了槽。
+
+
+> 
+小云示意高峰来说两句，于是，高峰就把早就讨论好的分组开站会的想法，讲了出来。
+
+
+> 
+小云接着补充说：“我们现在有15个人，开一次周会要花费所有人30个小时的时间（2小时*15=30小时）。可如果按照刚才高峰的提议，每个人每周开两次站会，也就花30分钟，能给每个人节省一个半小时的时间！”
+
+
+> 
+大家显然心有所动，有人笑着问道：“那以后的周会是不是也不要开了？”
+
+
+> 
+小云说：“以后每周五前，我会收集下大家的议题，如果有需要全员讨论的，我就另行组织周会，没有的话，那就默认不开啦！”看大家的一脸高兴劲儿，小云就知道，这时已经大功告成了。
+
+
+到这里，小云的故事，就告一段落了。你看，由于经过多次提前沟通和铺垫，整个过程进行得非常顺利。
+
+总体来说，在引入变化的过程中，**面向全员的正式公开沟通，一般会放在最后**。因为这时，关键问题和主要影响已经处理好了，路障也都清理干净了，变化自然就是水到渠成的了。
+
+其实，引入站会只是一个例子，无论你想引入什么变化，你都可以从以上三个要素，也就是天时、地利、人和，来一步步地进行分析和推进。
+
+## 总结
+
+今天，通过一个生动的故事案例，我为你呈现了新手项目经理在引入变化的过程中，最关键的三个因素：天时、地利、人和。**首先，你要选择合适的时机，然后，找到因地制宜的解决方案，最后因人而异，采用不同的策略进行有效沟通**。
+
+如果你想成功地把学到的那么多的项目管理方法引入团队，最难的其实不是那些招数，而是招数背后的你的发心。**之所以要引入变化，不是因为你觉得这个方法好，解决了你的问题，而是要看团队需要的是什么，干系人的痛点是什么**。只有解决了大家的问题，这个变化才能最终被所有人打心底里接纳。
+
+所有这一切的发生，必须建立在信任的基础上。这个信任不仅仅是对你能力的信任，更重要的是，**你是否能够站在对方的角度设身处地地思考问题**。当你是在真心为他着想，为他解决问题的时候，对方自然会愿意接受你所带来的变化。
+
+## 畅所欲言
+
+最后，如果你已经在尝试把我之前讲到的方法引入你的团队中了，你遇到过什么困难吗？你有什么需要解答的困惑或者支持吗？还没有投入实践的同学，有哪些顾虑阻止了你进一步尝试呢？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/硬技能篇/14 | 故事案例（下）：小步快跑，小而美的敏捷.md

@@ -0,0 +1,155 @@
+<audio id="audio" title="14 | 故事案例（下）：小步快跑，小而美的敏捷" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a6/b9/a68526f5c1edf28d8a34e5dfd3cda2b9.mp3"></audio>
+
+你好，我是雷蓓蓓。今天，我们来聊一聊敏捷。
+
+很多人认为，每天开站会，有固定时长的迭代，有自己的“Scrum Master”，就是在开展敏捷实践了，其实不然。
+
+具备敏捷之形的团队有很多，但是，真正掌握敏捷精髓的，却并不多见。这是因为，敏捷方法属于simple but not easy（简单但并不好做）。结合我这么多年的体会来看，与其说敏捷是一场研发方式的变革，不如说是一场思维方式的变革。
+
+<img src="https://static001.geekbang.org/resource/image/eb/08/eb18f11588b257425020cb9583bbfd08.png" alt="">
+
+> 
+图片来源：[https://agilemanifesto.org/](https://agilemanifesto.org/)
+
+
+今天，我会结合我在某试点团队中深度实践敏捷的经历，来跟你分享一下，我对敏捷精神的理解，以及在敏捷应用过程中的实施建议。
+
+## 为什么引入敏捷？
+
+敏捷的特点，就是小即是美（Small is beautiful）。这个小而美，体现在人、事、时间三个方面：
+
+1. 人：拆分成小规模（5～7人）、跨职能的小团队；
+1. 事：拆分成一系列小而具体的交付物，按优先级排序，增量交付；
+1. 时间：拆分成固定大小的短迭代（1～4周），在每个迭代结束后，对可工作的产出进行演示。
+
+总体来说，就是用小团队在小块时间，做出小块的东西来，并且周期性地集成组装。为什么我们当时会考虑引入敏捷呢？这就要从第一个版本的发布讲起了。
+
+这个新业务的第一个版本，原本预计在春节前发布。我们基于WBS做了完整的项目计划，用两个月时间进行模块开发，然后用一个月的时间来做发布前的联调、功能及性能测试。
+
+开发联调开始之前，一切都非常理想。我们有自认为完备的计划，有周会、周报和各种文档，还有任务系统的监控报表。我们从种种途径获取到的信息，都在告诉我们：“一切正常！”
+
+直到有一天，我们开始代码集成，准备测试了，“嘭！”各种意外超出了我们的想象，项目越来越不可控：
+
+- 集成联调比我们想像得要更复杂；
+- 性能稳定性调优花了更多的时间；
+- 有一名主要开发人员离职；
+- 这期间赶上了过年，要放十来天假；
+- 测试人员是个新人，还在学习期；
+- ……
+
+所有因素加在一起，把这个项目拖入了完全失控的深渊，一直到“三·八”妇女节才正式提交给了用户……
+
+最初引入敏捷，原因很简单，就是想要**发布周期更短。**
+
+## 痛点一：发布时间不可控（快速的增量交付）
+
+考虑到项目的实际背景，我们把迭代周期定为一个月。我们每个月都会跟内部客户一起做Sprint计划及Review演示。这种做法，给我们带来了哪些改进呢？
+
+- **提早集成与测试**。这让问题得以及时暴露，带来了更快的反馈及应对；
+- **及时规避风险**。意外仍然会有，但大多数情况下，我们可以在Sprint内部消化掉，避免更大的影响；
+- **快速响应变化**。在Sprint 1演示会后，我们收到了新客户提的紧急需求，立即做了相应的调整。如果按照之前的模式，这个时候，可能很多事情我们都只做了一半，想调头没那么容易。短周期让我们可以灵活调整方向，每个Sprint都是**潜在可交付**的产品。
+
+另外，在Sprint 3之后，我们临时安排了一个小的Sprint，用来**快速地将“潜在可交付”变为“真正可交付**”。我们发现，在每个周期内，能够真正把事情做完，跟我们的最终用户一起分享阶段性成果，对团队来说，也是非常好的激励。
+
+这时，发布周期的问题已经基本解决了，我们的交付灵活性高了很多，客户也更满意了。那么，我们是否可以号称是个Scrum团队了呢？
+
+## 痛点二：摆脱“接力综合征”（从对抗走向协作）
+
+经过仔细地观察和总结，我发现，团队各个角色之间的协作方式仍然存在着一些问题，我把这叫作“接力综合征”。虽然交付周期变成了每月一次，但大家却仍然在按照过去的方式工作。具体表现有以下两点：
+
+**1.宁愿选择等待**
+
+每个人都等着上一环节的人把东西弄好送到自己面前来，才能开始工作。比如，我经常听到这样的说法：“需求文档还没理清楚，急啥？”“接口设计文档还没确认，怎么做啊？”这种情况，在传统的项目管理中是很正常的。但是，这些空耗的时间，并不能给产品带来直接的价值。
+
+**2.角色间泾渭分明**
+
+每个人都觉得，只要把自己份内的事做完就行了。比如，开发把工作做完了，也不管做得效果咋样，心想：“反正要丢给测试，我先撤了，测出问题再说。”测试测出来Bug，心想：“等开发全部修完，我再接着测，反正我都测完了。”
+
+在这种情况下，各角色之间是有一定的对抗的。项目中的任何一件小事都有可能造成冲突。最终大家都耗在那儿，每个人更在意的是“这是你的问题，不是我的问题”，却没有把焦点放在达成整体目标上。
+
+在传统的项目管理中，项目经理的很大一部分工作就是要厘清各方责任，界定权利与义务，疏通对抗情绪，并解决随之而来的突发问题。但在敏捷的情境中，更加快速的交付压力，使得这种等待和界限变得越来越不可接受，我们不得不改变思路。
+
+**敏捷的打法，就好比是打橄榄球，所有队员都时刻关注着场上的比分**。虽然彼此之间有分工，但作为一个team，进球才是最关键的。敏捷也是一样。我们从敏捷思想中得到启发，开始进行一系列的改进。
+
+首先，开发和测试把位置搬到了一起，并且设定了**共同的Sprint目标和完成标准**。
+
+开发做完了工作以后，如果发现测试进度被卡，就会跟着一起着急，一起想办法解决问题，因为这影响到了整体的进度。
+
+其次，**从“你完成-我开始”，到我们一起完成**。
+
+在敏捷团队中，开发干得热火朝天的时候，测试也没闲着，测试代码与开发代码几乎是同时在写的。往往代码刚“出炉”就测上了，而且只有在测试结束并确认没有Bug的时候，开发的工作才算结束。
+
+我们使用故事点燃尽图，来衡量整体进度的偏差，并且团队会约定好，只有一个功能点完全测试通过，燃尽图才能往下走。这个燃尽图成了团队的计分牌，每个人都关注着同一个目标。
+
+同时，我们还发明了里程碑燃尽图，用来衡量每个迭代对于整体进度的贡献，以及多个迭代之间累积需求总量的变化，相当于一个赛季的累积记分牌。我给你分享一份**燃尽图型项目进度模版**，你可以点击[网盘](https://pan.baidu.com/s/1mhkKia-mctQbUrJpWTXtoQ)获取，提取码是pmx8。
+
+这些措施打破了角色之间相互切分和推诿的局面，共同的目标让我们变成了一个价值共同体。**毕竟，只有协作，才能达成目标**。
+
+## 痛点三：需求理解不一致 （面对面澄清及估算）
+
+至此，团队的力量得到了很好的凝聚。在复盘会上，大家畅所欲言，共同讨论了下一个待改进项，那就是是需求理解。这应该是技术类项目的一个共性问题。
+
+当时，我们团队没有专职的策划，开发人员在理解需求时，经常会感到非常困难。我们打开敏捷宝箱，找到了一条重要的价值观“**个体与交互  &gt;  过程与工具**”。相比于更多、更长的需求文档，我们决定采用更多的面对面交流来解决这个问题！
+
+于是，我们把迭代计划会分成了两个部分：
+
+1. 产品负责人向团队和用户代表，面对面地讲解收集来的各方需求，最终明确需求的优先级及验证条件，也就是说，在迭代结束的Demo演示会上，我们要给用户呈现什么。
+1. 团队估算。我们采用敏捷估算扑克的形式，由团队成员共同给出估算结果，最后综合得出这个迭代要交付哪些内容。
+
+团队估算的过程，其实是个双向互动的环节，可以帮助团队和产品负责人共同加深对条目的理解。同时，产品负责人也会根据大家的反馈，及时修改条目，完善条目。
+
+具体估算时，为了避免干扰估算结果，当所有成员选择好代表自己估算值的纸牌后，大家同时亮牌。同时亮牌的好处是，**不会有人跟风出牌，每个人的估算都是经过独立思考得出的**，这也是扑克估算的精华所在。
+
+如果估算值差距明显，代表大家对该条目的工作量没有获得共识，团队需要对该条目的评估结果进行讨论，由最大值和最小值的牌主，分别说明自己的估算理由，并重新讨论，确定最终的评估结果。
+
+经过实践检验，这样面对面的需求沟通及评估，至少带来了以下三方面的好处：
+
+**1.需求探索更深入。**
+
+在计划会上，团队会直面一线用户，需求可以得到面对面的交流和澄清。另外，团队估算其实也是一个团队共同探索需求的过程。因为只有到真正考虑要花多少成本去做的时候，才会有各种各样的问题暴露出来。这个方法对于在早期进一步挖掘需求细节，特别有帮助。
+
+**2.估算结果更加全面、细致。**
+
+在传统的项目管理中，我们也做估算。比如，WBS分配好了任务，然后每个人估算自己的。因为每个人都只对自己的那部分任务比较熟悉，估算时往往会有欠考虑，而团队估算，就很好地补足了这一点。
+
+每一个故事都会由全员出牌，各方从自己的角度出发想问题，可以互相补充。比如，在估算时，测试的成本也会被考虑进去。对于测试成本高的功能点，开发会主动想办法加强单元测试等白盒测试手段，这样一来，估算结果自然更细致、全面。
+
+**3.找到了更优的整体解决方案。**
+
+由于各方共同参与估算，前端、中间层、后端、测试的思路可以在一起交流碰撞，这样就非常利于找到最优的解决方案。
+
+**我们团队的这一系列敏捷尝试，始终都是围绕着项目中切实的痛点展开的**。从最开始缩短发布周期、经常交付可工作的软件，到应对“接力综合征”，提升团队的整体目标感和协作效率，再到探索更加有效的需求理解及团队估算方式，在增进团队交流的同时，又保障了需求质量。
+
+敏捷实践的应用，为我们带来了诸多好处：
+
+**1.提升客户体验**
+
+- 更低的延误率
+- 阶段性可见的产出
+- 更快的反馈、适应与调整
+
+**2.提升管理者体验**
+
+- 团队自主运行，管理更轻松
+- 变“赶”为“引”，为共同目标奋斗
+
+**3.提升团队体验**
+
+- 更高的生产力
+- 更强的责任感、主人翁意识
+
+## 总结
+
+今天，借助一个实际案例，我跟你分享了我们在应用敏捷方法的过程中，对于敏捷思想的体会和运用。
+
+你可以看到，对于敏捷方法，我们并不是拿来即用的。我们所采用的这些方法，大多是以敏捷思想为指导，以敏捷方法为基础，在实际场景中不断演化，一点点改进出来的。实际上，没有任何一种方法、工具可以放之四海而皆准，每个人都需要在自己的场景中思考。
+
+真正决定一个团队是否敏捷的，不在于是否应用了那些实践，而在于实践背后是否体现了敏捷精神。通过我们的长期实践和观察理解，我提炼出了实战中三项最重要的敏捷精神，那就是：**快速可靠交付，用户价值驱动，持续自发改进**。
+
+我希望你能坚持敏捷精神，而不是僵化地套用特定的做法。在团队中实践应用敏捷时，也应该遵循小而美的原则，每次一小步，挑一个痛点去集中解决，小步快跑，不断尝试和优化。只要你做到了以上三点敏捷精神，那么，你的团队就是一个敏捷的团队，你的组织就是一个敏捷的组织。
+
+## 畅所欲言
+
+最后，我想请你做个自检：你所在的团队，有哪些敏捷实践已经偏离了敏捷的初衷？从敏捷精神出发，你还可以找到哪些小而美的好方法？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。

极客时间专栏/项目管理实战20讲/硬技能篇/15 | 工具方法串讲：手把手教你高效管理.md

@@ -0,0 +1,197 @@
+<audio id="audio" title="15 | 工具方法串讲：手把手教你高效管理" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b1/6f/b1eb149d226ee72447c49d945d278d6f.mp3"></audio>
+
+你好，我是雷蓓蓓。
+
+很多同学经常问我：“老师，专栏里的图你是用什么工具绘制的呢？有哪些高效的项目管理工具吗？”今天，我就来做一个工具方法串讲，一并回答你！
+
+在这一讲中，我会结合几个常用的工具，从WBS工作分解到制作甘特图、里程碑规划图，再到任务管理、质量卡点、项目全局视图，为你一步步讲解可操作、易上手的方法，手把手教你高效管理你的项目。
+
+另外，这是“硬技能篇”的最后一讲，所以，我会在最后对这一模块的内容做一个简单的总结，帮助你打通整个知识版图。
+
+## Visio：WBS及甘特图
+
+我要介绍的第一个工具就是Visio。我在[第5讲](https://time.geekbang.org/column/article/162272)中介绍“排期地雷”时，很多人在留言区问：“小勤的计划是用什么工具做的呀？”
+
+今天，我们就先来看看小勤的第三版计划，是怎么画出来的。如果你对这部分内容不太有印象了，可以先返回第5讲复习一下。
+
+作为Office官方提供的图表工具，Visio可以帮助我们轻松直观地创建甘特图、流程图、组织结构图等。
+
+今天，我就结合具体例子，带你一起看看，如何使用甘特图完成WBS工作分解。
+
+- **Step 1：选择并创建甘特图**
+
+在Visio中选择“新建”后，你就会看到各个类型的模板，你可以搜索或者直接选择甘特图。选择好样式之后，你就可以点击“创建”，获得模板。
+
+<img src="https://static001.geekbang.org/resource/image/25/08/2586f35d2c314c6dc000dcd68e903908.png" alt="">
+
+创建完成后，你会得到一个标准的甘特图模板（以基本甘特图为例）。其中，横轴是分解的各个任务，纵轴是我们需要展示的属性。
+
+- **Step 2：按照WBS工作分解，增/删任务**
+
+选中表区后，点击右键，就可以看到新建/删除任务的操作链接。这时，你需要逐条地录入WBS工作项。
+
+<img src="https://static001.geekbang.org/resource/image/c8/b9/c8276d24aef83b2aad822943b89b7fb9.png" alt="">
+
+- **Step 3：拆解子任务（升/降级）**
+
+对于小型项目来说，一个层级的任务就可以满足需求了。但对于比较复杂的项目来说，你还需要进行子任务的拆分。在Visio的甘特图中，你使用降级来完成把任务降为子任务的动作，用升级来完成把子任务转为任务的操作。
+
+在具体操作时，选中任务之后（支持多选），点击右键，将其降级，这时，你选中的任务就会自动成为表格中上一级任务的子任务。子任务在格式上会有缩进，而主任务在右侧的日期区域会拥有标识。
+
+<img src="https://static001.geekbang.org/resource/image/52/ee/52daa1a22867749ac66d0d3aa4f18dee.png" alt="">
+
+- **Step 4：配置任务属性（如资源名称、持续时间等）**
+
+在完成任务拆解后，我们就可以开始配置任务属性了。
+
+在制作甘特图时，**我们希望重要的信息能够得到充分的体现**。所以，除了基础的任务名称、开始时间、结束时间等，我们往往还会添加一些属性，比如**资源名称、完成百分比、持续时间**等。
+
+另外，除了计划的时间，你还可以添加实际开始/结束/持续时间，来记录项目的完成情况。
+
+在选中表区之后，可以点击右键，插入列并选择想要插入的列类型。Visio也支持用户自定义的字段，还是比较灵活的。
+
+<img src="https://static001.geekbang.org/resource/image/d5/f7/d599b13e738fa525f9b3afd6563ab2f7.png" alt="">
+
+- **Step 5：设置任务依赖关系**
+
+在项目规划中，我们需要厘清**任务依赖关系**，并借助链接任务功能，来完成在图上的展示。
+
+在具体操作上时，你可以参考下表。在选中有依赖关系的两个任务之后，右键选择“链接任务”就可以了。如果你要取消依赖关系，可以点击“取消链接任务”，也可以在日期区域，直接选中任务间的连线并删除。
+
+<img src="https://static001.geekbang.org/resource/image/9a/fa/9a672cce5675f9a8b517ed9f22e187fa.png" alt="">
+
+三个区域的配置完成后，我们的甘特图就比较完整地呈现出来了。其他几个甘特图模版的具体操作步骤也是类似的，只是最初的模板与样式有略微的不同，你可以根据自己的喜好进行挑选与调整。
+
+到这里，第5讲中小勤的第三版计划就做好了，如下图：
+
+<img src="https://static001.geekbang.org/resource/image/7c/f2/7c14929c016a6c3a7da15d8df0e1e2f2.png" alt="">
+
+## Visio：里程碑规划
+
+在任务规划期间，除了WBS工作分解及甘特图，我们还需要一个可以反映各个阶段时间节点的整体里程碑规划，也就是小勤的最后一版计划图。
+
+里程碑规划图的绘制也可以在Visio中轻松做到，同样也是5个步骤。
+
+**Step 1：选择并创建日程表**
+
+首先，你要搜索日程表模板，并且选择合适的日程表模板，然后就可以开始我们的里程碑制作了。
+
+Visio主要提供四种模板：**日程表**（空白画布提供日程表形状）、**块状日程表**、**垂直块状日程表**和**展开的块状日程表**（用于展示日程中某一部分的详细信息）。
+
+<img src="https://static001.geekbang.org/resource/image/dc/66/dc54da34464da39ccd190f098eeec766.png" alt="">
+
+**Step 2：选择日程表形状，绘制时间线**
+
+需要注意的是，日程表的使用和甘特图有所区别，日程表主要是通过使用Visio工具中的日程表形状来完成展示。拖动下图中的形状到画布，并进行相应属性的配置。
+
+<img src="https://static001.geekbang.org/resource/image/98/67/980bba10b32681c36a10e4d4e897c767.png" alt="">
+
+除了模板中提供的时间线，我们还可以自行拖拽选择三种：**圆柱形、线形和块状**。
+
+<img src="https://static001.geekbang.org/resource/image/00/04/00ec64ab37ecd4303399f2c22cd97e04.png" alt="">
+
+将图形拖拽到画布以后，会自动弹出配置日程表的选项。在这些选项中，你可以选择时间段与刻度，这时，基础的设置就完成了。
+
+**Step 3：设定里程碑时间**
+
+接下来，你需要将里程碑和间隔形状拖拽到画布上，进行日期的配置和形状的调整，以标记重要日期。
+
+可选的里程碑形状有**线形、菱形、针形、双三角形、X形、三角形、圆形和正方形**等，你可以根据自己的使用习惯与定义来进行使用。
+
+当然，需要调整时，你可以右键配置里程碑的属性，更换里程碑类型。
+
+<img src="https://static001.geekbang.org/resource/image/38/67/381c4060f16ed385381865f010d36467.png" alt="">
+
+**Step 4：设定时间间隔**
+
+除了特殊的里程碑节点外，我们有时候还会标记一些重要的时间间隔。你可以选取左侧形状中的间隔，把它拖拽到时间线上，并进行间隔的属性设定，这时，就可以完成时间间隔的标注了。
+
+Visio提供的时间间隔类型有**方括号间隔、花括号间隔和块状间隔**。
+
+<img src="https://static001.geekbang.org/resource/image/c0/03/c0b6451daba4e2a2dcba81ac8644e103.png" alt="">
+
+**Step 5：增加今日标记**
+
+在项目的进程中，**今日标记**也是一个非常实用的功能。你可以选择“自动描述位置”，在项目进度的查看中，也可以把它作为一个标签，来进行进度的观察与把控。
+
+<img src="https://static001.geekbang.org/resource/image/25/86/25818e552362cfc0a38cc9cffa3dbf86.png" alt="">
+
+到这里，小勤的最后一版里程碑规划图就做好了。
+
+<img src="https://static001.geekbang.org/resource/image/d2/6b/d230b2c2877970d29e4c9b838f3d8a6b.png" alt="">
+
+## Tower：在线多人协同
+
+做完了计划之后，你肯定还想知道，后续如何跟进这些任务。这时，你就需要一个**任务管理平台**了。
+
+在我试用过的多人在线协同工具中，Tower使用起来无疑是最流畅的，上手也很简单。同时，它还提供了移动版App，微信里面也能用。
+
+我在几分钟之内，用Tower做出来了一张甘特图（如下图），整个过程操作起来非常简单。你可以用**任务清单**来完成WBS工作分类，在面板上直接拖拽，调整任务的时间安排以及任务之间的前后依赖关系。
+
+<img src="https://static001.geekbang.org/resource/image/c2/cb/c2ef80a47516d108826d00ff21516ccb.png" alt="">
+
+在任务清单上，你还可以**为每个阶段设置清晰的完成标准**。
+
+比如，设计阶段的完成标准是，需求稿和设计稿公开评审通过，且未处理反馈数&lt;5。
+
+<img src="https://static001.geekbang.org/resource/image/4c/11/4ca028d55d6e69c7d937d714bce42411.png" alt="">
+
+在监控阶段， 你可以通过“鹰眼”，了解项目进展、本周任务、延迟任务，以及项目成员延误率。
+
+<img src="https://static001.geekbang.org/resource/image/c7/0f/c7b0d1bb7473771e00032df7e733550f.png" alt="">
+
+同时，你还可以通过看板看到项目全局的各个环节。不得不说，这是一个简易高效的任务协同管理神器。
+
+<img src="https://static001.geekbang.org/resource/image/db/02/dbd9c5909e41ac902cee3e25baf08702.png" alt="">
+
+## 网易Overmind：在流程中设置质量卡点
+
+讲完了任务管理，接下来我们看一看质量管理的工具和方法。
+
+在“[质量管理](https://time.geekbang.org/column/article/168318)”这一讲中，我跟你分享了通过设置质量卡点，在过程中保障质量的方法。如果要做到这一点，你需要一款好用的DevOps配套工具。
+
+**研发的流程和标准管理是所有团队都会碰到的痛点，团队越大，越是如此**。随着团队规模的扩大，如何保障高效率、高质量的交付，自然就成了技术管理中的首要问题。
+
+在网易内部，我们使用Overmind企业效能平台，来做全研发流程的规范化管理。在网易某个明星产品8亿的用户规模之下，日均15次上线，交付周期缩短了58%，依然能够保障超高的质量标准。这是怎么做到的呢？
+
+**答案就是，在流程中设置质量卡点**。
+
+Overmind把以前很难推进的编码、提交等规范化动作，变成了由工具来中心化控制；把以前口头描述的质量、效率问题，变成标准化数据来度量改进。
+
+<img src="https://static001.geekbang.org/resource/image/c6/47/c6239a258a97e97fd74bda98d0d5f047.png" alt="">
+
+这样的DevOps工具让整体技术及质量管理有了尺子，有了抓手，有了助推器。在微服务、DevOps盛行的时代，像Overmind这样的全流程研发效能平台，就成为了技术管理最好的基线，最佳的伙伴。
+
+## 一页纸项目管理：全局视图及干系人汇报
+
+其实，在项目管理的过程中，要关注的事情有很多，工具更是多种多样。除了刚刚提到的这些工具之外，你还需要一个纵览全局的视图，以免陷入细节，“只见树木，不见森林”。特别是你在跟高层汇报项目进展时，如果一上来就好几十页的文档，恐怕半天都说不清楚。
+
+现在，我给你介绍一个足够简单的工具，让你可以用**一页纸看到项目全局**，**更好地进行整合管理，轻松搞定各种干系人汇报**。
+
+一页纸项目管理为项目描绘了一幅高度可视化的项目整体图，**清晰明了地体现了项目管理的五个核心要素**（目标、任务、负责人、时间线及成本），让每一个利益相关人，特别是公司高层管理者，可以快速、直观地了解项目的整体情况。我给你分享一份“一页纸项目管理”模板，你可以点击[网盘](https://pan.baidu.com/s/1yXJDLl1EolnUIw9fQxuGQg)获取，提取码是vg1u。
+
+<img src="https://static001.geekbang.org/resource/image/67/6f/673ecd11261fb3e42fdc00302ac3b96f.jpeg" alt="">
+
+构建这样一个表格，需要12个步骤：**确定项目名称及目标、明确责任人、绘制项目矩阵、划分子目标、拆解主要任务、关联任务与子目标、设置目标日期、完成任务排期、分配任务到个人、设置定性任务、成本预算与监控、概述与风险预测**。
+
+在创造这一页纸的过程中，你会有意识地用更加结构化的方式，从项目全局的视角去思考问题，从而加深对项目本身的理解。你和你的团队只要看到这一页纸，就会明白哪些是最重要的。
+
+同时，一页纸项目管理，强调的不是面面俱到，而是**把最有用、最有价值的东西，用最快捷、最简单的方式呈现出来**，这就是透明。这份透明的清晰，也会让项目的相关人员各就其位，以主人翁的立场来思考和行动。
+
+## 总结
+
+今天，我从可以做出漂亮计划图的Visio，讲到简单易用的多人协作工具Tower，再到Devops工具Overmind，最后落脚在纵览全局的极简主义神器：一页纸项目管理。
+
+只要你能把这几类工具搭配起来使用，并且真正用好，就足以应对日常基本的项目管理需求了！
+
+最后，我用一张表格，带你梳理下“硬技能篇”的主要内容，你可以及时回顾下。
+
+<img src="https://static001.geekbang.org/resource/image/65/04/65ec8b685b0b3c3aa0da71ea8db4ee04.jpg" alt="">
+
+## 畅所欲言
+
+下一讲，我想跟你聊一聊如何在实践中进行学习，希望可以进一步帮你巩固学习成果。如果你在学习和实践的过程中，有特别需要解答的困惑，可以留言告诉我。
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/结束语/结束语 | 如果我可以，你也一定行！.md

@@ -0,0 +1,81 @@
+<audio id="audio" title="结束语 | 如果我可以，你也一定行！" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e3/05/e330b2d334b4e9dea08b36ee666c6505.mp3"></audio>
+
+你好，我是雷蓓蓓。
+
+今天，“项目管理实战20讲”专栏就要跟你说再见了。在专栏的“加餐”文章中，我跟你分享了我对于大师级学习方法的理解和总结，很多同学留言说很有共鸣。
+
+实际上，对我而言，这个专栏的制作过程就是一次特别难忘的学习经历。
+
+写专栏的这两个月里，我的工作和生活都经历着很多起伏。专栏一开工，我就好比在疯狂地打“俄罗斯方块”，面对持续掉下来的一个个“方块”，经常是手忙脚乱。
+
+工作上的一连串紧急事件“掉”下来，我就变作“千手观音”赶紧接住；讲稿存量马上告急，我又通宵达旦地立马补上。可即便是日夜兼程，我还是始终赶不上进度，就想起那句话：“我……太……难……了！”
+
+除了体力上的考验，我还特别羡慕平台上很多老师的写作能力。有次，我跟编辑同学讲：“哎，你说XX老师，他怎么讲得这么好？你再看XX老师，人家怎么就写得那么快？一个周末就能写三篇稿子，还不用怎么改。”回头再去看看自己写的稿子，忍不住嫌弃：“这都是什么啊……”
+
+为了让我掌握好的写作方法，极客时间的编辑同学特意给我寄了一本《风格感觉》。我打开一看，惊讶地发现：“坏了，写作的8大误区，我中了N条！！”
+
+写这个专栏的经历，让我体会到，**从一个分享者到真正成为一个老师，从自己懂到把别人教会，我还有很长的路要走**。
+
+所以你看，我和你一样，都在学习的道路上不断地挑战着自己。我从不敢说自己是个老师，我始终觉得，**我是个学习者，是跟你一样的同路人**。
+
+不过，有意思的是，**学习者本身，恰恰就是最好的老师。**
+
+学习金字塔模型的最后一层，也是最高级的学习，就是把别人教会。可是，我该如何做呢？一路走来，指引我走到现在的，就是我之前跟你分享的学习方法。
+
+<img src="https://static001.geekbang.org/resource/image/cb/19/cbe19aa310119be2a3f7aa203d063519.jpg" alt="">
+
+首先，我得破除自己的“魔”障，这一步是最难的。一开始我觉得，不就是写20篇文章吗？很简单啊！可是，当我交上去的文章反复被打回，怎么改都不对时，我开始发现，完全不是这么回事。在连续几个通宵写稿、改稿之后，我开始怀疑自己到底行不行。
+
+这个时候，我要破的“魔”障，就是不让这种刚开始尝试时体会到的“把别人教会真的好难啊”的定义，限制了我成为一个好老师的可能性。
+
+接着，我每次走一小步。我尝试着把好的写作方法拆解开，先从把语言变得具体开始。每次写完之后，我会多问自己一个问题：“**我这么写，你能够理解究竟该怎么做了吗？**”
+
+说实话，刚开始时，这个问题经常让我搜肠刮肚。一个案例说来说去，我始终不得其法。一次偶然的机会，我在周爱民老师的[一篇文章](https://time.geekbang.org/column/article/171116)中，终于找到了那种面对面地、把自己的经验娓娓道来的清晰感和流畅感。
+
+**“对，就是这种感觉！”**
+
+感觉找到了，再写下去，就顺畅多了。每次感觉来了，文字就像是从我手中流淌出来的，我称之为“天助”。就是这种感觉，带领我突破路途上的所有困难，经过一次又一次的刻意练习，把我的所有经验全部教授给你。
+
+很多同学在留言区讲自己碰到的问题和困难时，会说“自己非常难受”。我很理解你的处境，不过，我想问的是，**作为学习者，你如何看待这种不舒服**？
+
+有一次，在清晨的火车上，我苦哈哈地反复改稿，怎么改都不满意，整个人都不好了。但是，那一瞬间，我突然想明白了：“**贝壳中一旦有异物进来，它就会不舒服。但就是这种不舒服，才刺激它不断分泌，最终结成美丽的珍珠。**”
+
+即便到了现在，我仍然有很多的不舒服，有很多能力不及、做不到的事。可是，作为一个学习者，我知道，路途上的困难和挑战，只会让我们变得更强壮。
+
+**如果我可以，你也一定行！**
+
+有朋友问我说，为什么我明明知道自己并不是天生适合做项目经理，还一定要转岗去做呢？
+
+答案很简单，**因为我想从头到尾把事做成**。当时，我们团队在设计开发一个内部的项目管理平台，在推广应用的过程中，我发现，**要想从根本上影响和改变项目的运作方式，我就必须“深入虎穴”**。你看，就是这种单纯地想把事从头到尾做成的愿望，推动我不断向前，克服自己的种种障碍，在这个岗位上，一干就是八年。
+
+这些年，项目经理的“帽子”让我拥有了比其他角色更多的跨界、多元的历练机会，做了很多自己根本想不到会去做的事情，包括创作这个专栏。
+
+专栏的创作形式与写书大不相同，因为专栏是一个全程高度互动的创作过程，所以，我特别感谢一路陪伴的你。你的每一个问题、每一次反馈，都在不断地激发我进行新的思考，为我增加一份新的经验和了解，共同创造出别样的学习体验。
+
+我很欣慰地看到，有很多同学在从头到尾、一节不落地跟着认真学习。不过，我个人认为，还有一点比这个更重要。
+
+**如果你想获得真知，你就必须“深入虎穴”**。那么，什么叫“深入虎穴”呢？
+
+在写结束语的时候，我正在哥斯达黎加的热带雨林中，开启新一轮的学习突破之旅。房间的观景阳台上，经常会有猴子、大嘴鸟闯进来。酒店的工作人员反复叮嘱我们，不要喂食那些野生动物，不管它们有多可爱。
+
+为什么呢？**因为一旦习惯了被喂养，它们很快就会丧失野生的属性，退化为人类的宠物**。作为一名真正的“野生”动物，它们必须自己到丛林中觅食。**广阔的丛林才是有助于它们成长的最好场所**。
+
+有很多同学今天买这个课，明天因为大家都说那个课好，就再去买那个课来看，**可是，别人给的内容再好，都不如你自己跑到丛林深处，靠自己的力量采来的一个野果香甜**。
+
+这也是为什么我一直在鼓励你说出自己的经验，分享自己的心得，真正地把你学到的内容应用于自己的实践。如果你认为看看文章就是学习了，那么，你将永远无法获得真正的提升。
+
+眼到，手到，心到。**你能在这条路上走多远，不取决于你的起点，也不取决于你当前所处的位置，而是取决于你是否对此有持续的热情和足够的专注，来支撑你真正地付诸行动**。
+
+王阳明曾说：“**知是行之始，行是知之成。**”“**未有知而未行者；知而不行，只是未知。**”通俗点说就是，根本就没有“知道但没做到”这回事，如果你做不到，那就别说自己什么都知道。
+
+通过这个专栏，我用心陪伴你了51天。我在每一讲中分享的实战方法，都可以说都是我特意在你实战的丛林中设置的路标。你只有亲自到丛林中走一走，再看到那些路标时，才能真正领会我的用意。
+
+我希望，有越来越多的同学因着这些路标走上一条亲身实证的道路，用自己的实践和行动不断丰富和扩展新知。
+
+除此之外，你还可以在我给你分享的知识的基础上总结出你自己的一套行之有效的经验方法。如果在这些路标旁边，你能有自己的全新发现，那就太好了！
+
+[<img src="https://static001.geekbang.org/resource/image/7f/e8/7fcfa7faa19e04503f5f2f1c288938e8.jpg" alt="">](https://jinshuju.net/f/arCApu)
+
+最后，我为你准备了一份调查问卷，欢迎你给我和这个专栏提供一些你的反馈和建议。再次感谢你共同参与这个难忘的学习之旅，我们江湖再见。
+
+

极客时间专栏/项目管理实战20讲/结课测试/结课测试｜这些项目管理知识你都掌握了吗？.md

@@ -0,0 +1,10 @@
+
+你好，我是雷蓓蓓。
+
+到这里，《项目管理实战20讲》这门课程已经全部结束了。我给你准备了一个结课小测试，来帮助你检验自己的学习效果。
+
+这套测试题共有 20 道题目，考题范围覆盖专栏的 20 讲正文，题目类型为单选题和多选题，满分 100 分，系统自动评分。
+
+还等什么，点击下面按钮开始测试吧！
+
+[<img src="https://static001.geekbang.org/resource/image/28/a4/28d1be62669b4f3cc01c36466bf811a4.png" alt="">](http://time.geekbang.org/quiz/intro?act_id=82&exam_id=151)

极客时间专栏/项目管理实战20讲/软实力篇/16 | 向上沟通：你必须要注意的三个误区.md

@@ -0,0 +1,155 @@
+<audio id="audio" title="16 | 向上沟通：你必须要注意的三个误区" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/18/07/180c2c480072259c5df71db4c2dbd807.mp3"></audio>
+
+你好，我是雷蓓蓓。
+
+根据多年的实践经验，我发现，项目管理不只是一种硬技能，更是一项软实力。就软实力而言，最重要的不是招式，而是内功。从这一讲开始，我就来教你修炼内功。
+
+今天是“软实力篇”的第一讲，我会结合自己的亲身经历和我踩过的“坑”，来聊一聊向上沟通的三个误区。
+
+## 误区一：所有问题，都自己扛！
+
+不得不说，这一条，在技术人员中相当普遍。
+
+在我还是个刚刚转岗的PM小菜鸟时，我负责管理一个项目，代号叫“KK”，这个项目是为公司的战略项目提供底层支撑的。
+
+在跟进这个项目的前几个月里，我跟技术负责人阿仑配合得还算默契。但是，我发现他有个特点，就是所有问题，都自己扛。
+
+距离里程碑发布只剩一周了，但在测试时，我们还在不断地发现新的Bug。以目前的进度和剩余Bug的潜在影响来看，按原计划上线，质量风险很高。
+
+这天，开站会时，我请团队中的每个人，在白板上画出自己的发布信心指数。总体来看，情况非常不乐观。
+
+我跟阿仑一起做好当天的安排之后，特意提醒他：“现在的情况不是很好，我们最好跟方雷提前报备一下。”我说的方雷，是这个项目的发起人，也是阿仑的上级。阿仑没有应声，转而找旁边的开发，开始讨论别的问题了。我心里很着急，但也只好作罢。
+
+实际上，我的担忧并不是空穴来风。方雷曾经在很多个场合强调过，KK是今年的重点，稳定性更是重中之重。最近几次线上出问题，我们团队没少挨骂。这次的上线风险这么高，要不要及时告诉方雷呢？
+
+我在方雷的办公室门前，绕了两个弯，各种纠结顾虑，再一想到方雷那严厉的神情，就打起了退堂鼓。最终，我什么都没说，就离开了。
+
+新版本最后还是如期上线了，但我却并没有因此感到轻松。且不说遗留Bug的潜在风险，由于时间紧张，我们连线上监控都没做到位，也没时间充分考虑应急预案和演练。
+
+正当团队全力补漏的时候，线上还是出事了：底层依赖的第三方服务报错，导致很多线上用户请求失败。大晚上接到客户侧的紧急电话，我们才知道出了事。
+
+第二天，方雷在邮件里，劈头盖脸就责骂了我们一顿：“之前我一再强调监控，结果已经预见到的问题，你们都没有做应对，这是非常严重的人为事故！”
+
+看到这里，你觉得我冤不冤呢？
+
+其实，我明明知道这样上线会有很大问题，也明白现阶段最好的应对方式是什么，甚至还在心中打了无数的底稿，可以说服方雷调整上线计划。
+
+可是，当我站在方雷的办公室门口时，却死活迈不出自己心里的那道坎，这个“坎”究竟是什么呢？
+
+首先是层级差在无形之中给我带来的心理压力，包括方雷平日里强硬的作风，都让我有点怵，不自觉就想躲开。
+
+其次，都快上线了，项目还有这么多问题，作为项目经理，我也是有很大责任的。
+
+另外，因为阿仑不想去汇报，如果我汇报了，我会觉得像打小报告，不仗义。
+
+实际上，做好一次紧急问题的汇报沟通，并不是什么难事。只要你按照我在[第7讲](https://time.geekbang.org/column/article/164235)中给出的沟通模板，组织好思路即可。
+
+**但是，迈过自己内心的那道坎，主动大胆地发起沟通，是做好向上沟通的第一步**。
+
+事实上，我们首先必须要明确，这类严重影响稳定性的问题，已经不属于可以自己扛的级别了，必须要让上级知晓。
+
+明确了这一点，处理方式可以有很多种。比如，跟阿仑深入探讨下项目的处境，尝试说服他一起去找方雷。即便他不去，我也可以跟他说明自己的判断和接下来的行动，因为客观暴露风险，合理应对，这本身就是项目经理的职责所在。
+
+当然，我也可以尝试用邮件的形式，发一封项目风险告警，客观描述现在的风险和影响，提醒方雷特别关注，等等。
+
+这里的关键是，**不管通过什么途径，我们必须时刻从大局出发，让这些项目关键信息，及时有效地流动，保障及时有效的决策**。
+
+当真正重要、紧急的事情发生时，直接打电话或走过去敲门，确保第一时间沟通，才是更合适的做法。**记住，你不需要所有问题，都自己扛**。
+
+## 误区二：只知道吐槽，不知道争取
+
+在KK项目组，连续加班是常有的事，半夜2点爬起来升级，也是家常便饭。即便我们的工作强度已经这么高了，线上仍然问题不断，项目组从上到下都压力很大。
+
+在如此“恶劣”的生存环境中，团队成员彼此之间就好比“难兄难弟”，私底下经常一起吃饭。当然，少不了的，就是一起“吐槽”。
+
+某个周末，又是一次通宵上线，我们忙到凌晨4点多钟，结果更新之后，出现了个突发情况，按照流程果断回退了。第二天，在定位解决问题后，又重新来过。在连续了两个通宵之后，项目得以成功上线，但团队却撑不住了。
+
+在看不到尽头的艰苦境况中，吐槽似乎成了最有效的排解压力的方式。比如，我们可能经常听到这样的吐槽：“出了问题挨骂”“没出问题是应该的”……
+
+刚开始，我也会跟着吐槽几句，因为我也一样，拼死拼活却得不到认可。可是，除了私下吐吐苦水，又能做什么呢？
+
+你看，这就是我踩过的第二个“坑”。当团队和管理层之间关系紧张时，很多项目经理会特别容易掉进一个误区，那就是，**尽自己的努力帮团队解决问题，脏活累活都自己来**。
+
+这样的“老好人”，在团队中会有很好的人缘，但是，跟着大家一起吐槽，似乎并不能带给团队真正的帮助。特别是当你同时受到高层压力的驱使，被迫去快速拿结果时，就很容易演变成“夹心饼”，吃苦受累，最后反而落得两头埋怨。
+
+那么，破局的点在哪里呢？
+
+**答案就是，把“夹心饼”变成“连接器”，成为高层干系人与团队之间紧密联系的纽带。**
+
+事实上，经过层层汇报，高层干系人能够得到的一线团队的信息，相当有限。很多自上而下的决策，如果不能根据一线反馈，及时调整的话，就很容易走形，偏离本意。
+
+作为项目经理，**当需要高层重视和支持的事件发生时，该出手时就得出手，引发高层关注，把团队最一手的相关动态信息及时传递给他，争取高层必要的支持，而不是跟着团队一起吐槽**。
+
+所以，这一次，我立刻想到了方雷！我应该让他听到团队的声音，让他意识到，长期这样下去的严重影响。而且，他才是解开这个困境的最合适的人。
+
+事实表明，方雷的介入，大大提升了团队士气。
+
+## 误区三：抓不住重点，给不出方案
+
+那么，我是怎么得到方雷的支持的呢？
+
+某次会议散会之后，我叫住了他。我说：“我们团队最近加班很严重，已经连轴工作好几天了，这样下去，恐怕会……”我的话还没说完，方雷就毫不客气地打断了我，说：“现在这些年轻人，加几天班，就叫苦叫累的，想当年，我加班可多了去了……（此处省略一万字）”
+
+你看，在得到方雷的支持之前，我又踩了一个“坑”，也就是我想说的第3个误区：**抓不住重点，给不出方案**。
+
+“团队现在加班很严重”“团队任务不及时更新”“某某工作不主动、总是迟到”……**如果你只是这样反映问题，只是说这里不好、那里不好，却没有告诉他，为什么要关注这个问题的话，你的意见不仅不会得到重视，甚至还会产生反效果**。
+
+高层干系人的时间往往很宝贵，所以，在沟通之前，做好充分的准备，是必不可少的。**你要反映的问题，与高层干系人的核心关注点是否相匹配，这是能否引起其关注并进一步行动的关键所在**。
+
+**在向高层干系人提问题的同时，一定要给他一个明确的“点”，让他知道，为什么要关注这个问题**。在[第13讲](https://time.geekbang.org/column/article/170693)中，我跟你分享了一些抓住痛点的具体方法，如果你不记得了，可以再复习一下。
+
+实际上，抓住了对方真正的核心关注点，你才能在后续的沟通中，更加有针对性地进行高效管理。
+
+虽然我很了解方雷的脾气，但还是被刚刚这架势吓住了。还好，我提前就有所准备了。于是，我打开电脑，把准备好的数据摆在方雷面前，说：“你知道，**我们的线上质量是容不得半点闪失的**。这是我们团队前两个月的连续加班记录。
+
+“有人曾经做过统计，连续加班三周，人的身体、心理、情绪都会降到谷底。现在团队已经连续加班和通宵两个月了。再加上每次上线的心理压力，这样下去，恐怕会很容易犯错。昨天这次上线，团队吸取了教训，最终还是很平稳的，也算是这么长时间以来一次小小的胜利了！我在想，我们是不是应该简单庆祝下，帮大家先从心理上减减压，鼓舞下士气，也好有一个新的开始？”
+
+我一口气说完了事先准备好的“台词”，方雷先是有些吃惊，但他很快认可了我的判断。他说：“确实，我们得想办法鼓励下大家，而且一定要及时！”
+
+我灵机一动，接着说：“嗯！我看今天就是一个很好的时机。我们正打算下午开复盘会，我这就去准备些零食饮料，可以的话，请你到场跟大家讲两句话吧！”
+
+在复盘会上，方雷显然事先认真准备过。他从这个项目对大部门的重要性，讲到对大家的辛苦付出的感谢，再到绩效及奖励措施上的承诺。看得出来，他不太习惯公开说这么多鼓励的话，气氛稍有些诡异。
+
+最后，他说：“我相信这次的成功只是一个开始，希望KK项目以此为始，步入一个正向循环，越做越好！”
+
+方雷的这些话，让每个团队成员的脸上都呈现出了“难以置信又受宠若惊”的表情。最重要的是，在团队的共同努力下，这些话的的确确变成了现实。
+
+你看，这次沟通就很有效，对吧？现在，我就来为你拆解一下，其中做得好的几个地方。
+
+首先，我并没有因为方雷否定了自己的说法，就转向附和跟随，而是在坚持自己的观点的同时，快速改变策略，从方雷的核心关注“点”，也就是线上质量开始说起，一下子就抓住了方雷的心。
+
+在经验、阅历等方面，项目经理可能会跟高层干系人有差距。但是，即使是这样，你也不要一味跟随，而是要努力成为他的“镜子”。高层领导也是人，是人，就有他的盲区。比如，他可能会因为信息不对称，做出错误的决策。这个时候，你就需要大胆说出来。
+
+其次，我不止是空口说说，我还拿出了加班数据和事实结论作为“论点”，很好地阐释了为什么方雷要关注这个问题。这样清晰的逻辑表达，可以很好地帮助干系人快速地做出决策。
+
+最后，对于自己提出的问题，我还**适时地给出了一个小小的“行动点”，也就是近在眼前的解决方案**：下午的复盘会，邀请方雷来为大家打气。
+
+**针对提出的问题，列举可能的解决方案，这一点非常重要**。需要注意的是，你并不需要一下子给出完整的解决方案，因为这些问题通常已经超出你个人的能力范围。但即便如此，我依然强烈建议你，不要只是把锅甩给领导，而是在提出问题的同时，**给出前进一小步的解决方案，给领导，也给自己，一个小小的行动暗示**。
+
+总之，想要抓住重点，高效沟通，你要记住三点：
+
+- 找到“**核心关注点**”；
+- 用数据和事实来作“**论点**”；
+- 给出一个小小的“**行动点**”。
+
+## 总结
+
+今天，我结合我曾经的真实经历，跟你深入剖析了向上管理的三个误区。
+
+- 第一个误区：所有问题，都自己扛。
+- 第二个误区：只知道吐槽，不知道争取。
+- 第三个误区：抓不住重点，给不出方案。
+
+高层干系人，往往会对项目的成败起到决定性的作用，是项目经理需要重点管理的对象。优秀的向上管理能力，不只是对你个人有利，对于项目和团队来说，都是福音。
+
+人们常说“直言不讳”，虽说毫无顾忌的坦率直言，精神可嘉，但同时呢，你也要懂得讲究方法，用对方听得进去的方式来讲，这就是门艺术了。
+
+其实，不光是项目经理，向上沟通更是职场中的一堂必修课，需要勇气，更需要智慧！
+
+## 畅所欲言
+
+今天，我给你分享了三个误区，你对哪个误区比较有共鸣呢？另外，希望你能分享一下，自己在向上沟通的过程中踩过的“坑”，我们一起学习。最后，请你结合自身的项目情况，给自己制定一个向上沟通的行动计划。
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/软实力篇/17 | 跨部门沟通：怎么让不归你管的人积极配合你？.md

@@ -0,0 +1,129 @@
+<audio id="audio" title="17 | 跨部门沟通：怎么让不归你管的人积极配合你？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/dc/32/dce4709cd0f35c16843ccfe866eeb932.mp3"></audio>
+
+你好，我是雷蓓蓓。这一讲，我们来聊聊跨部门沟通。
+
+曾经，有位程序员跟我说：“我们自己内部的进度都很好管，可是，一旦涉及到跨部门合作，管起来就很困难。人家又不归我们管，不可控因素太多了。如果在合作的过程中，出现了什么问题，拿他们也没办法。针对这种情况，你说怎么办呢？”
+
+其实，人类社会的很多冲突，都始于“边界”二字。比如，部门与部门之间存在边界，所以就有了“部门墙”。别看只是跨了个部门，各项沟通的复杂度就会直线上升。
+
+为啥呢？不是“自己人”了啊。那么，我们该如何应对跨部门沟通的问题呢？我跟你分享两种方法。
+
+- 约法三章，先说清楚。
+- 打开边界，一起想办法。
+
+## 约法三章，先说清楚
+
+我们先来看看第一种：约法三章。既然不是自己人，那就要分清楚哪些事情该我干，哪些该你干。那么，该如何约法三章呢？
+
+**第一步：建立君子协定**
+
+在合作前，你要跟对方建立合约，明确**合作目标、合作事项、双方各自的需求和责任、时间进度要求、风险及责任人**。建立合约时，要由双方负责人进行邮件确认，公开做出正式的承诺。
+
+需要注意的是，**在刚开始合作时，建立稳定的预期是关键，双方责任及进度要求，必须要得到公开确认**。否则，这些问题如果不明不白的话，就会给后续工作带来极大的隐患。
+
+我给你分享一份合作说明书的示例文档。你可以点击[网盘链接](https://pan.baidu.com/s/1PFIvDLnvYypmF6k2XhbuJw)获取，提取码是35qw。这是某公共技术部门与某事业部达成的战略合作，里面清晰地约定了合作内容、具体需求及总体进度计划。这份文档就需要两个部门的最高领导通过邮件进行确认。
+
+必要的时候，可以筹备、召开一个跨部门的项目启动会，邀请双方的领导层参与，通过这种正式的仪式，让合作项目成为大家共同的目标。
+
+为什么很多公司级的战略合作都会举办一个签字仪式呢？其实，这就是因为**承诺越公开，越正式，日后对双方的约束效力就越大**。
+
+**第二步：建立机制**
+
+万万不要以为，签完合约就万事大吉了。
+
+曾经，我们就遇到这样的情况：眼看着要到联调的Deadline了，对方的任务还没完成。我问了对方之后，才知道，说好的功能接口不能准时交付了。他们给出了很多原因，比如，工作比想象得复杂，还有人员休产假、离职等等。
+
+在项目进行中，各种情况都有可能发生，只有及时获知、甚至是提前预知风险，才能让项目始终保持可控。
+
+**合作建立之后，需要建立常规的沟通机制来持续推动**。比如，项目信息开放共享，每周在固定的时间开碰头会，双方相关人员交流工作进展及风险情况。更进一步的话，你还可以借助标准的任务管理和文档管理工具，对项目任务和文档做到统一的流程化管理，在过程中确保及时地跟进检查。
+
+常规机制及工具搭建好之后，在运行过程中，你还需要经常自检，确认下流程上是否有疏忽的地方。比如，**是否存在“三不管”地带？每个依赖任务的职责是否明确，责任是否具体到个人？**
+
+如果你发现了模糊地带的存在，要及时明确需要共同协作的内容是什么，该由哪个部门、哪个人负责，做到权责分明和分工合理，避免后期出现相互推诿、扯皮的情况。
+
+**第三步：解决问题**
+
+通过周期检查，我们可以及时发现问题。但是，如果事先约定好了，并做了周期检查，对方负责的事情还是出问题了，该怎么办呢？
+
+有同学会说：“找他们领导！”在跨部门沟通中，打出领导牌的确会起到一定的作用，但是，这张牌属于“王炸”，不到特别时刻，不要随便拿出来用。
+
+在找领导之前，建议你先自己摸清楚状况，**尽快启动风险应对机制，确定问题处理方案**，比如改变方案、调整时间、增加资源、减少范围等。
+
+另外，你要把问题和相应的决议结果抄送给双方的负责人，让双方清楚问题对整体项目的影响及调整方案。同时，你还要明确的是，**今后要采取哪些预防措施，以避免问题的再次发生**。
+
+那么，什么时候该找领导呢？
+
+我曾经就遇到过一种情况：两边的领导已经达成了正式的约定，但是，不是每个牵涉进去的协作方都会立马配合。
+
+原因有很多，比如，这个部门的KPI早就定义好了，目前上面的领导虽然认可了合作方案，但是没改KPI，原来的目标依然有效。对于这部分新增的工作，他们要额外投人去做。因此，他们非常担心，虽然增加了工作量，但产出却不受领导的重视。
+
+类似这种会影响合作落地的根本机制问题，你就需要引入双方的领导，来一起研究解决方案。比如，在双方的绩效考核指标中，加入跨部门利益的指标，来强化这种目标和利益的捆绑，让双方真正把劲往一处使。
+
+我们总结一下“约法三章式”跨部门沟通的要点。首先，在项目合作开始时，要努力争取合作部门上级领导的支持，达成明确公开的“君子协议”，建立稳定的合作预期。然后，你要建立周期检查机制和标准化的流程，而不是想起来才问一句。最后，对于执行过程中的问题，及时跟进解决，对于涉及合作机制类的问题，要及时请双方领导介入进来。
+
+## 打开边界，一起想办法
+
+“约法三章”，可以说是最为常见的一种跨部门沟通的应对方式。接下来，我们再来看看第二种方法：打开边界，一起想办法。尽管不是自己人，咱还是要把对方当成自己人看待，好，就一起好；出了问题，大家就一起扛。
+
+为什么说跨部门沟通还需要打开边界呢？我给你分享一个我经历过的项目，你就明白了。
+
+X项目是一个非常典型的跨部门、跨职能的大型项目集，项目组人员接近两百个，涉及到的跨职能小组就有12个。由于技术复杂性，各模块之间的依赖和耦合很强，再加上各业务模块都有自己的目标和优先级，跨部门沟通的成本很高。
+
+在这样的背景下，每个业务模块都反馈说：“跨部门协调这个事，太难了。”一个很小的改进，可能就需要交互、前端、中间层、后端、各模块的测试都参与其中。即使只是组织一个会议，要想把人叫齐，都颇费周折。
+
+这种跨部门的协作，已经融入到每一天的工作中了。这时，“约法三章”的沟通方式，显然已经不适合我们了。那怎么办呢？
+
+**首先，要建立统一、清晰的节奏感。**
+
+你需要结合不同业务模块的功能、相互之间的依赖关系，来为各个业务模块设计统一的交付节奏，也就是根据项目中的关键依赖，把交付时间错开排布。
+
+比如，在X项目中，我们在每个月固定设置了四个发布窗口，分别是5号、10号、15号和20号。接着，根据这12个模块的先后依赖关系，我们把它们安排在不同的窗口进行发布。
+
+在此之前，这些模块的发布时间都是自行定义的，现在，每月有了统一的规划和交付节奏，协同复杂度降低了很多，因为彼此之间有了稳定的交付预期和协同基准。
+
+需要注意的是，节奏的设定没有固定模式可循，你需要在自己的情境中，尝试总结规律，并把它们固化下来。有一个指示性的指标，就是**重新设定节奏之后，如果跨部门协调的问题明显变少了，那么，当前这个节奏就是更合适的**。
+
+**其次，想要打开边界，你还需要主动往前一步。**
+
+对于这个项目集里的12个子业务模块来说，每个模块既可能是底层服务的用户，同时又是上层服务的依赖方，彼此互为上下游。在这样的情况下，如果没有彼此的通力合作，那就谁也做不好。
+
+曾经，我见过两个部门的负责人来来回回地在邮件里争吵，据理力争地互怼。后来，因为实在无法直接沟通了，他们就跟我说：“给我们加个项目经理吧。”
+
+在了解了需求之后，我发现，每个模块的日子都不好过，要么是被需求的反复弄得焦头烂额，一肚子怨气，说：“明明之前都约定好了，需求还是说变就变。我辛辛苦苦做出来了，说不用就不用，全白搭了。”要么是被频繁的依赖问题折磨得陷入“水深火热”的境地，纷纷吐槽：“底层服务又出问题，害我挨用户一顿臭骂。整天出问题，真是拿我们当小白鼠。”
+
+不管是哪一方，每个人都盯着别人的问题，同时捂住自己的问题。像这样的情况，就算是再放10个项目经理，估计都很难从整体上改善局面。那么，该怎么办呢？
+
+在和项目集的高层领导一起深入地剖析了现状之后，我们都认为，“头痛医头，脚痛医脚”的方式，并不是我们想要寻求的解决方案。
+
+于是，我们在Leader层发起了一次跨部门的交流讨论，取名为“上有老，下有小”，意思是，在这个项目集生态里，各个模块是层层嵌套在一起的，每个模块都在持续建设中，还远未成熟。上面，有人要调用我的服务；下面，我要依赖另外一个服务提供底层能力。每个模块都是“上有老，下有小”，如果我们想要获得整体改善，该怎么做？
+
+我们收集了大家的改进建议，并进行了统一整理，形成了我们所定义的“担当力模型”（如下图所示）。这个模型总共分为四层，它们分别描述了我们在遇到跨部门沟通的问题时的四种不同心态和行为。
+
+<img src="https://static001.geekbang.org/resource/image/28/a0/28d1887e744f28392b5b24f686b4a3a0.jpg" alt="">
+
+- 第一层：放弃。这背后的心态是：“见怪不怪，反正我已经绝望了。”抱着这种心态，于是，你就什么都没做。
+- 第二层；责怪。这背后的心理是：“你怎么搞的，每次都这样？”这样想着，你依然是，什么都没做。
+- 第三层：完成任务。这背后的心态是：“真是不省心，下次我得特意盯着你点！”抱着这种完成任务的心态，你会针对问题做全面的排查，增强对应的监控。
+- 第四层：担当。这一层的表现是：“出问题不可怕，但我们绝对不能再犯同一个错误。”你会把错误当作完善的机会，帮助用户方和依赖方共同成长。
+
+我们把真正的担当解释为“上敬老，下爱小”。什么意思呢？上敬老，是说对于用户方，你要去主动深挖用户方的需求及业务背景，走在用户前面；下爱小，是指对于依赖方，你要全面监控、必要容错、并帮助它不断改进。
+
+通过这次的深入讨论，我们认识到，只有各个模块都往前走一步，才能够引发系统的改善。与其去责怪对方，不如跟他一起找到合作共赢的方式，最终让所有人获益。这四层担当力模型，本质上是心态上的差异，而每次主动往前一步，最终必将体现到工作的长期效果上，从而形成持久化差异。
+
+## 总结
+
+今天，我介绍了跨部门沟通的两种应对之道，分别是约法三章，先说清楚，以及打开边界，一起想办法。那么，我们怎么区分什么时候该使用哪种方式呢？
+
+答案就是，**看双方之间的依赖关系和合作性质**。如果更多是单方面依赖、单方面受益，且是一次性的合作，第一种方式会更加适合。如果是互相依赖，而且是长期合作的共生关系，那么，你就不能只考虑短期利益了。你要从长期的合作关系着眼，建立协同共荣的生态。需要注意的是，这两种方式并不一定是非此即彼的，你也可以结合起来使用。
+
+跨部门协作之所以很难，究其根源，就在于边界所引发的“分别心”，也就是你是你，我是我。如果执着于你我之间的“界限”，必然会导致各种摩擦。也正因为这样，在跨部门合作时，你需要付出更多的努力，在保障项目推进的同时，用心经营、维护良好的合作关系。
+
+共同目标、利益捆绑、流程约束是基础，除此之外，你还需要更加开放的心态，去找到更多合作共赢的方式，共同做大事业。
+
+## 畅所欲言
+
+在跨部门沟通上，你有什么很好的经验吗？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/软实力篇/18 | 向下沟通（上）：无权无势，他们不听你的怎么办？.md

@@ -0,0 +1,109 @@
+<audio id="audio" title="18 | 向下沟通（上）：无权无势，他们不听你的怎么办？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/21/ca/216e39b938f82520a56ba4fde3180cca.mp3"></audio>
+
+你好，我是雷蓓蓓。
+
+在做项目管理的前几年时间里，我经常会听到一种声音：“项目经理无权无势，不就是个打杂的吗？”老实说，刚开始从小白起步时，我也经常有这样的困惑。
+
+没有权力，却要承担很大的责任，还得让别人愿意听我的，互相配合着把事情做好，难度真的非常高。但正因为这样，我们项目管理部的项目经理们，在这些磨练中，个个都发展出了一身武艺。这其中最厉害的一项本事，叫作“**非职权领导力**”。
+
+今天我们就来聊一聊，如何在团队中让自己拥有更大的Power。
+
+在大量的实践中，我逐步总结梳理出了**非职权领导力的六力模型**。“六力”分别是**执行力、信息力、感知力、透明力、影响力和整合力**，这六力是层层递进的关系，代表了非职权领导力发展之路上的六个层次。
+
+在接下来的两讲内容中，我就围绕着这“六力”，来跟你分享一下向下沟通的正确方法。我们今天先来看前“三力”，即**执行力、信息力和感知力。**
+
+## 执行力
+
+执行力是非职权领导力的根基，俗称“靠谱”，这是项目经理的立身之本。我们判断一个人是否靠谱，往往是在说这个人是否具有两个特征：主动担责和有始有终。
+
+1.**主动担责**
+
+管好自己的一亩三分地，并非就是执行力好。
+
+比如，我见过很多策划，在写好策划案之后就甩手不管了。但是，我曾遇到过这样一位策划，他不仅把自己的本职工作做得很出色，还会帮忙给所有策划制作一张总进度表，即时同步信息，汇报进展。
+
+如果中间过程出现了问题，比如开发跟测试发生了冲突，他也会主动想办法协调解决，推进项目落地。
+
+一段时间后，他被Leader点名表扬，很快从几个同级中脱颖而出，得到了晋升。我问他：“你为啥做这么多事？”他笑笑说：“也没啥，我就是很想看到整个产品都做得很好，不能忍受有些环节出了问题没人管，没人上，那就我上呗。”
+
+所以，你看，执行力的第一层，并没有什么神奇的，你首先需要跳出自己的小圈圈，主动承担更大的责任，而不是眼睁睁地看着项目出现问题，放手不管。
+
+2.**有始有终**
+
+言必信，行必果。交给你的任何事情，都有始有终。当很多人都只是在完成任务时，如果你懂得闭环的重要性，势必会事半功倍！
+
+关于这一点，我想跟你分享一下我的第一位项目管理导师给我上的宝贵一课。
+
+当时，我在团队中发起了一项“零Bug”的改进活动，后来因为一些原因没有坚持做下去。她在了解了情况之后，很严厉地跟我说：“作为一个项目经理，你发起的任何一件事都要有‘Close’的动作。你既然跟团队讲过要做这件事，现在不做了，就算自认为原因再合理，都需要给大家一个交待，而不是不声不响地就停止了。”
+
+实际上，**一个有始有终的闭环，意味着你要对自己的每一个行为负责，清楚地了解为什么做，目标是什么，做完之后效果是怎样的，还有什么问题，以后要做哪些改进。如果中途有变化，也要及时跟相关方明确说明调整或取消的原因是什么**。
+
+总结一下，想要做一个“靠谱”的人，我给了你两条建议：第一，跨出自己的边界，主动担责；第二，言必信，行必果，做事情有始有终。
+
+一屋不扫，何以扫天下？执行力可以说是你能够影响他人，继而具备非职权领导力的根本。
+
+## 信息力
+
+在大数据时代，**谁掌握着数据和信息，谁就拥有更强大的力量和权力**。由于自身的职责和信息渠道的便利，项目管理人员会很容易成为团队中拥有最大信息量的人。大到全局的战略、项目的初衷和发展方向、决策的起因和前后变迁，小到每个团队每天在干什么，都尽在项目管理人员的掌控之中。因此，项目经理就好比是项目信息的交换中心。
+
+我曾遇到过一个项目经理，他就拥有这种神通广大的信息力。不只是项目组里，甚至是公司里上上下下发生的事情，他都能第一时间获悉。所以，遇到拿不定主意的事情时，我经常向他打听消息。
+
+有一次，我忍不住问他：“你到底是怎么做到的？”他说：“没什么神秘的，我这个就是好奇心强，而且比较热心。我对别人很感兴趣，就会经常跟大家多聊几句，不管聊的东西有没有用，我都记得清清楚楚。而且，我还特别喜欢帮助别人。比如，我觉得某个机会适合某某，我就会推荐他去试试看。久而久之，大家就会主动给我提供信息，让我帮忙出谋划策，所以我就成了最有信息力的人啦！”
+
+当然，信息力可不只是掌握简单的八卦，而是**要让流动的信息汇聚起来**。作为初学者，你可以通过**信息互通机制和平台**来帮助自己做到这一点。比如，**周会、站会、周报、邮件列表、通讯群，甚至是各类数据平台，都可以成为信息力的承载**。
+
+除此之外，能够**让非正式信息自动流向你**，就属于内功的范畴了。在与人交往与合作时，好奇、关心、真诚、友善……这些特质都会帮助你构建起信任基础。连接多了，覆盖面广了，自然会形成规模效应和网络效应，这时就会产生信息力的红利了。
+
+## 感知力
+
+感知力建立在信息力的基础之上，不同的是，**感知力是对“冰山下”隐性信息的敏锐度**。这种对系统敏锐的感知判断，俗称“闻味道”。
+
+据说，马云就是个“闻味道”的高手。如果他出差一个月不在公司，那么，他回公司之后做的第一件事，就是把十层楼的办公区都跑一遍，然后找副总们开会，精准地说出公司存在的问题，观察之细密往往让人佩服至极。
+
+感知力是日积月累的功力，但也并不是什么深奥的功夫，你也可以做得到，重点就是平常在开会时，你要多练习、多观察。
+
+举个例子，某业务负责人请我给他的管理层做一次共创会，请大家根据总体规划，各个角色共同定义下半年各自的工作重点。拿到这个需求之后，我先跟几个管理者开了一次沟通会。
+
+会后，我找到这位负责人，跟他同步了我对管理团队的观察，并且提出了我的共创方案：“在这次共创之前，我们必须先有个复盘环节，否则，以咱们团队现在的这种合作状态，根本没法很好地共创。咱们得提前准备，我需要你的大力配合。”
+
+他很快就认可了我的方案，并且惊讶地问我：“你是怎么做到在这么的短时间内捕捉到这么多复杂的背景信息的？”
+
+你可能也很好奇，事实上，这就是感知力在现实场景中的运用。要想培养感知力，你需要经历三个层次。
+
+**第一层：现象层。这一层观察的焦点，是在“冰山上”的行为**。比如，你观察到开发和产品在会上吵起来了，这时，你注意到的是行为，还不是真正的感知。
+
+**第二层：意图层。这一层观察的焦点，是在“冰山下”行为背后的真正意图。具体要怎么做呢？最简单的是，多问几个为什么**。比如，他们为什么会吵起来，各自想要达成什么目标。仔细思考之后，你会发现，原来技术已经对于产品的频繁变更忍无可忍了，技术Leader有很大的压力，想要为受苦受难的开发们出头；而产品的意图也很直接，他们的想法是：“业务KPI在那儿摆着，咱能不能别那么磨叽？快速推进不行吗？”观察到这一层，你就很接近冲突的根源了。
+
+**第三层：感受层。你要试着从这些现象和意图中，去感受每个人的状态和需要**。你会发现，开发的核心感受显然是愤怒；产品直接承担着业务指标带来的高压，老大的想法又一直在变，技术的不配合让他们受到双面夹击，早已是苦不堪言，核心感受是苦涩。
+
+体会到这些之后，你会发现，如果不事先处理好这些强烈的感受，这些人是根本没有办法在一起很好地进行共创的。
+
+于是，在共创开始前，我安排了一个之前提到过的复盘环节，就是让每个成员画出自己从项目启动以来的状态、经历，并把其中的“高光时刻”和“至暗时刻”分享给大家。
+
+当天，这位负责人第一个发言，跟大家分享了开创新业务以来自己的坎坷经历。他的开放和坦诚让大家一下子轻松了许多。
+
+接着，轮到产品，她提到了刚上线就被苹果推荐的成就和喜悦，同时又分享了最近“两头受夹板气”的惨痛经历。开发同学则拿出自己的画，说自己自始至终都是“压力山大”，从来都没轻松过……就这样，大家开始一点点地敞开了心扉。
+
+那些平时看不到的真实一面，被集体看见和理解之后，团队内部淤积的压力也终于得到了释放。于是，大家开始聚焦在共创下一步真正有效的解决方案。
+
+**总之，要想培养感知力，就要在日常的观察之中下功夫。从关注行为，到关注行为背后的意图，再到关注意图背后个体的核心感受和深层需要，最后着眼于团队中的气场和互动品质**。
+
+这样一来，你就能找到“四两拨千斤”的杠杆点，从“救火式”的应对问题，变成“治未病”的先知先觉，从而在团队中积累起自己的独特影响力。
+
+## 总结
+
+回到题目中的问题，“项目经理无权无势，别人不听你的怎么办？”如果你想靠自己的力量，让别人真心信服，并没有捷径可走。你只能从自身做起，在一点一滴的行动中，从头构建非职权领导力。
+
+今天，我跟你分享了非职权领导力“六力模型”中的前“三力”，分别是执行力、信息力和感知力。可以说，执行力是所有一切的根基。正人先正己，项目经理要影响别人正确地做事，自己就要先要成为标杆，严格约束自己的一言一行。
+
+信息力和感知力，则是对项目和团队的现状做重新的审视和梳理，是对于环境的观察、观察、再观察。一个有经验的项目经理，可以通过信息搜集和观察感知，“闻”出一个团队的味道，快速定位到问题点。观察的角度、深度、广度，会极大地影响你接下来选择的行动方案。
+
+问题的解决也见功力。“头痛医头、脚痛医脚”的做法，往往治标不治本。在下一讲中，我会接着往下剖析，跟你分享如何运用观察到的事实、信息、数据，有效地影响和整合团队力量。
+
+## 畅所欲言
+
+对照着非职权领导力的“六力模型”，分析一下，哪些力是你最擅长的？哪些力是当前最缺失的？另外，请你谈一谈学习这节课的收获或者是你的困惑。
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/软实力篇/19 | 向下沟通（下）：无权无势，他们不听你的怎么办？.md

@@ -0,0 +1,107 @@
+<audio id="audio" title="19 | 向下沟通（下）：无权无势，他们不听你的怎么办？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/94/63/942bedd09407576fe31366be54e8d163.mp3"></audio>
+
+你好，我是雷蓓蓓。
+
+上一讲，我给你介绍了非职权领导力“六力模型”中的前“三力”，分别是执行力、信息力和感知力。今天，我们接着来看后面的“三力”。
+
+## 透明力
+
+我在上一讲中提到过，信息力和感知力是对环境的观察、观察、再观察。你需要注意的是，这些观察的结果只有透明出来，才能发挥效用。你要想办法把你看到的问题可视化，让决策者和团队都能看到这些问题。这就是我经常说到的透明的力量。
+
+那么，怎么运用透明的力量呢？我给你讲个例子，你就明白了。
+
+我在一个团队中经常听到这样的声音：“搞什么需求评审、交互评审？要做什么先说好，然后就别再来烦我了。让我安静地写会儿代码，不行吗？”
+
+于是，这些评审会能不开就不开。结果，在Deadline之前，需求稿、设计稿和技术方案的问题不断爆发，要熬上好几个通宵，才能保证版本的正常发布。但是到了下一个版本，情况依然如此，循环往复。
+
+经过仔细了解，我发现，如果在早期投入精力的话，这些导致发布延期的大多数问题都是可以有效避免的，发布的风险也会大大降低。
+
+实际上，定位问题并不难，但是要想解决这个问题就很难了。因为这个团队三四年来一直都是这样，他们早就已经习惯这种模式了。**想要引发改变，不是仅凭一人之力就可以做得到的。要打破这个恶性循环，就一定得让大家真正地看见问题，并且从心底里达成共识**。
+
+我教你两个透明化呈现的方法：一个是“**分析−思考−看见**”，一个是“**目睹−感受−看见**”。前者走脑，是指借助数据、事实、逻辑分析等，调动头脑的智慧，创造共识；后者走心，是指运用图片、视频、故事等形象化的元素，调动情绪的力量，创造共鸣。如果你能结合起来用，效果会更好。
+
+看到这里，你可能会问，我是怎么解决那个项目的问题的呢？
+
+在一次版本总结回顾时，我给大家讲了一个“熊猫大侠”的故事。这位“熊猫大侠”是一个苦兮兮的程序员，他有着熊猫一样的黑眼圈，他的黑眼圈是怎么来的呢？
+
+我以这个问题为切入点，以故事的形式**带领大家回顾了整个版本进行过程中的一幕幕场景**，从上个版本结束时的“累觉不爱”，需求评审会上的睡意朦胧，讲到提测前对设计方案的争执不下，最后到上线前的“兵荒马乱”。“熊猫大侠”的故事，使团队成员深度地看到了项目的现状，并产生了共鸣。
+
+接着，我**晒出了各种过程数据**，包括需求变更率、需求和设计问题发生的阶段及成本、各阶段等待时间、研发负荷度等，邀请团队一起来想办法解开Deadline的“魔咒”。
+
+看见这些事实和数据之后，大家才真正地意识到早期那些看似无聊的评审工作的重要性。除此之外，团队还进一步定义了各角色的协作规则，以达到更合理的节奏。
+
+最后，在团队的共同努力下，我们进一步建立了基于过程数据的效能改进机制，各角色的协同状况得到了持续的改善。
+
+所以，你看，**想要改善什么，就把什么透明化！在走脑的同时又要走心，让团队的所有人都看见问题，调动起集体的关注力和改变的动力**。这样的话，这种透明的力量就会自然地推动变化的发生。
+
+## 影响力
+
+项目经理无权无势，行走江湖，靠的是大家肯买你的账。能让他人买账的这种影响力，对个体来说，就是说服力；对群体来说，就是感染力。
+
+人们通常认为，要想提升影响力，一定要能讲，会讲。但很有意思的是，**影响力的真正秘诀却在于“听”，而不是“讲”。**
+
+举个例子，我们在听马丁·路德·金的演讲时，往往会觉得非常震撼。这是因为，真正能够征服人心的演讲都具有强大的说服力和感染力，而这些都是建立在对听众的深度理解的基础之上的。因为理解，所以才能创造共鸣。如果演讲者自己激情澎湃，但听众并不受用，那根本就无法产生真正的影响力。
+
+我曾经跟一位产品总监合作，他本人聪明又强势，属于公认的特别难搞的类型。有一次，他主动跟我说：“别人跟我讲话，我向来只听两句就忍不住想打断，但是你说的话，我几乎全都听完了。”
+
+他之所以会这样说，并不是因为我的表达能力比别人强、我的逻辑更清晰、我的话更有道理，而是因为在他讲话的时候，我做到了**真正的听**。跟其他人相比，我更懂他的逻辑，我明白他是出于什么样的考虑，才会那么说、那么做的。**我给他提的每一条建议都是建立在我对他的理解之上的，所以才能被他听进去**。
+
+**不听，是一切沟通问题的根源**。要想增强你的影响力，你需要先培养“听”的能力。那么，该怎么培养这种能力呢？
+
+我给你分享一个小技巧。你可以找一位项目中的成员，请他聊一聊，在最近的工作中，他有没有什么高兴或者烦恼的事。在听他说话的时候，你一定不要打断他，也不需要特意去想自己该怎么回应。
+
+你只要简单地把注意力放在对方身上，清空你的思绪，打开你的所有感官，留心去体会对方的状态和需求就可以了。试着保持至少五分钟的专注，并在结束后记录自己的体会。
+
+同时，我鼓励你跟对方分享一下，在刚刚的对话中，你留意到了什么。另外，你也可以跟他沟通下，有没有什么事情是你可以帮他一起做的。
+
+实际上，在真正有说服力的对话中，恰恰并不存在什么“一定要去说服”的想法，这又是一个有意思的悖论。
+
+实际上，只有当你真诚地抱着想要了解和倾听对方的愿望，放下对自己的想法的执着时，你才能留意到对方真正的需要。**这样自然的交流分享，反而更容易产生碰撞，引发共振**。
+
+如果你能够在你的每次工作对话中有意识地坚持运用这个小练习，半年之后，你的影响力就能够得到很大的提升。
+
+## 整合力
+
+在一个业务团队中，除了总负责人之外，项目经理往往是唯一站在全局层面的人。毕竟，其他人都各有各的职责分工。在这样的定位之下，项目经理一定要成为一个“多面手”。因此，**优秀的全局整合能力非常关键**。
+
+简单来说，整合力就是把互相分离的部分连接在一起，使它们发挥出整体作用的力量。**一群优秀的人结合在一起，也并不一定能成为一个优秀的团队，不一定能真的做成一个业务**。
+
+作为项目经理，整合力就意味着你要去主动发现项目组中的各类风险和问题，综合运用各种能力，跨部门、跨角色地整合资源，以实现全链条的共同目标。
+
+关于整合力，我定义了两个“凡是”：**凡是能促进业务良性运作的，凡是能促进团队健康发展的，都是整合管理的范畴。**
+
+举个例子，我身边有个项目曾经遭遇到了发展上的瓶颈，军心溃散，士气低落，这时，我就变身成了教练，借助教练技术，给业务负责人及核心团队“照镜子”，帮助他们看到限制他们的模式到底是什么，促发团队进行深度思考和交流，共同梳理出当前局面之下最好的思路和打法，从而帮助团队更好地走出困境。
+
+所以，你看，所谓的整合力，就是不受限于你自己的角色、从头到尾把事做成的能力。这种整合力来源于你对项目环境的观察和感知，最后要落地到全局层面的行动中去。
+
+## 总结
+
+好了， 我们来对这两讲的内容进行一下总结。如何让自己在团队中拥有更大的影响力呢？“六力模型”为你提供了一个知行合一的框架。
+
+在“六力模型”中，执行力是从现在的“行”开始，想要影响别人，就要先做好自己，走出自己的小圈圈，去承担更大的职责，并且把你在日常执行中遇到的每一个问题，都视为一个开启新循环的机会。
+
+信息力和感知力是指你要不断拓展自己对环境的准确认知和把握，观察、观察、再观察，从复杂的系统中找到一个恰当的发力点，通过把它有效地透明出来，让集体共同看见，从而获取新的共识，也就是新知。
+
+最后，你还需要通过影响力和整合力去践行这个新知，反向影响和改造环境，最终推进新知的有效落地。
+
+## 实践中的“六力模型”
+
+讲到这里，关于实战的内容基本上就到尾声了。你还记得我在[第5讲](https://time.geekbang.org/column/article/162272)中提到的刚刚升任项目经理的小勤吗？
+
+我们再见面时，她的气质变了很多，给人一种更有力的感觉。她说，“六力模型”对她帮助很大。之前，她发现产品的问题不是在于研发环节，而是在于销售和研发环节的脱节，可是她很难改变这个现状，她担心直接指出问题的话会得罪别人。
+
+在把研发过程梳理清楚之后，她开始着手收集相关的数据，并且做了大量的调研和分析，摸清问题对整体的影响（**信息力**），然后去感知项目中各个角色的声音和诉求，这让她找到了最迫切想要改变的力量（**感知力**）。接着，她想办法把问题透明给销售主管及各部门的负责人，引发了更大的关注（**透明力**）。除此之外，她还主动找各方讨论可能的应对方案，促成变化的发生（**影响力**）。最终，她推动这件事被列为部门下个阶段的重点改进目标之一（**整合力**）。
+
+现在，这个销售环节的漏洞早已被堵上了，销售和研发之间的衔接流程更加规范化、透明化，甚至还因此增加了相应的考核项。
+
+小勤用自己的实践给我们展示了“六力模型”的魔力。这个知行合一的闭环，是从“行”开始，到让团队获得“新知”，再落地到“行”的转变过程。很显然，这个过程让小勤在团队中积攒了更大的影响力！
+
+我们一起学习了这么久，希望你也能有和小勤一样的变化，如果是这样的话，那就是我最满足的事情啦。
+
+## 畅所欲言
+
+我给你介绍了向上沟通、跨部门沟通、向下沟通的各种方法，现在，关于项目中的各类沟通，你还有什么问题吗？
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/项目管理实战20讲/软实力篇/20 | 进阶之路：项目经理预备战之PMP认证攻略.md

@@ -0,0 +1,145 @@
+<audio id="audio" title="20 | 进阶之路：项目经理预备战之PMP认证攻略" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c6/c3/c656769976568b09a44f35723bea85c3.mp3"></audio>
+
+你好，我是雷蓓蓓。
+
+很多同学留言问我，要不要去考PMP？PMP认证的含金量怎么样？老实说，我一向认为，认证考级不是最终的目的，千万不要舍本逐末，为了证书去考试。**让考级最大程度地帮助自己提升专业技能，才是最重要的**。
+
+## 为什么要考PMP？
+
+在决定投入精力考证之前，我们要先搞清楚，为什么要考PMP？
+
+实际上，PMP®认证近几年在国内的前沿行业很受欢迎。截至2019年10月，全球PMP有效认证人数为99万。其中，中国的PMP认证人数占总人数的三分之一。
+
+PMI的研究报告预测，2027年，中国的项目管理职位空缺将达到4600万个。未来在中国，项目管理岗位将成为最热门的职业之一。
+
+PMI的中国代表曾经专程来网易访谈调研。他们想要了解一下，PMP认证在中国推广了这么多年，它的价值到底在哪里。
+
+调研小组从多个方面进行了探讨，最后得出的最重要的一条结论就是，**PMP认证的普及为我们创造了项目管理专业的共同语境**。比如，我们会自然地讨论“根据当前的WBS工作分解，计划中的关键路径是什么”“风险管理计划要怎么做”，等等。
+
+不要小看这个标准术语带来的好处，统一的共同语境为管理者正确地认知项目管理的作用、为项目运作建立良好的组织环境，都做了非常好的铺垫。
+
+**实际上，PMP的认证过程也是我们学习并掌握一门项目管理的国际标准语言的过程，就好比是学会了另一门英语。**
+
+回到很多同学关心的问题上：“PMP认证有用吗？值得考吗？”其实，这些问题背后的疑惑是：“考了这个证，会给我带来什么？升职加薪？还是增加面试和录用机会？”
+
+我想说的是，对于想尝试转岗项目管理的同学来说，PMP认证的确可以作为“敲门砖”，在一定程度上增加你获取专业面试的机会。但是，在大多数企业中，PMP认证只是一个基础项，**决定你是否被录取的，还是你的实战经验和实战水平。再进一步去看的话，还有建立在实战经验之上的、你对专业方法论的掌握和应用水平**。
+
+所以，你看，**学习中最怕的就是本末倒置**。PMP证书的含金量不在于证书本身，而是在这个准备考试的过程中你所付出的大量努力，以及你把理论框架和亲身实战融会贯通之后，你的自身能力得到的提升。
+
+因此，**我建议你在具备一定的实战经验之后再去系统化地学习这门课程**。否则，对你来说，考这个证无异于超大浓度的理论灌输加知识记忆。如果大量的知识无法被消化和吸收，它们就会成为你的“知识障”，屏蔽你进行自我思考和尝试的动力。
+
+## 如何有效备考PMP？
+
+那么，如果你已经具备了实战经验，决定要考PMP了，就要提早了解一些PMP认证攻略，不打无准备之仗。
+
+接下来，我就给你介绍一下备考PMP的几个关键步骤。
+
+**第一步：确定考试的目标时间**
+
+PMP每年有4次考试，分别在3月、6月、9月和12月。确定要考之后，你要做的第一步就是安排合适的考试时间，给自己锚定一个目标点。
+
+**怎么确定什么是合适的时间阶段呢？**
+
+首先，你要**确保至少完整地经历过两到三个项目周期**，从启动、规划、执行、监控一直到收尾，自己有切身的实践体会。
+
+其次，**避开工作高峰期，选择自己相对空闲的季度**。这是因为，要考PMP的话，你需要投入大量的时间和精力，至少要留出三个月的备考期。对于这一点，你要提前做好准备，因为它真的会占用你所有的业余时间。
+
+必须要提醒你的是，你一定要提前确认PMP认证官方要求的报名条件。实际上，**你并不一定需要有明确的项目经理岗位，只要有相应的项目经验，并且达到足够的时长积累，就可以报名了**。
+
+**第二步：完成中英文报名**
+
+PMP考试属于国际认证，报名需要两个步骤，先进行英文报名，后进行中文报名。确定好考试日期之后，你至少要提前3个月完成英文报名，提前2个月完成中文报名。
+
+为什么我要把“报名”这条单独列出来呢？因为我想提醒你，英文申请全年都可以提交，**没有时间限制，但是有5～7天的审核时间，审核成功后，账户有一年的有效期。如果英文申请没有通过，是不能完成中文报名的**。所以，我建议你尽量在中文报名开始之前完成英文报名，以不耽误考试。
+
+**第三步：课程学习和备考**
+
+PMI规定，报名考生需要具备PMI授权的培训机构所颁发的35PDU培训证书。一般来说，各类培训班的开班时间通常会至少提前三个月，分别在12月、3月、6月和9月。
+
+总体来说，培训班通常分为线下和线上两种。线下培训的话，学习的互动感更强，建议你尽量挑选你所在城市的正规培训机构，线下组队形成学习小组，互相督促，一起学习，效果会更好。
+
+PMI中国联合项目管理专委会开设了官方组织的培训班，目前，浙江地区已经开始招生了，你可以留意一下。
+
+时空受限的同学也可以选择线上培训的方式。我当时就是选择的线上培训，因为时间更灵活，随时可以补课，对于自律性好的同学来说，效果是一样的。
+
+接下来，我们再聊聊备考PMP的学习材料，其实主要就是《PMBOK指南》。这本书很经典，但即便我现在读起来，都感觉并不轻松。全书有600多页，而且大多是理论方法的描述说明，很容易让人望而生畏。
+
+为了帮助你达到更好的学习效果，我结合我的经历，为你梳理、总结出了三步学习法。
+
+**1.通读**
+
+对于十大知识领域五大过程组来说，不同阶段的各种方法浩如烟海，这第一步就好比是在知识的森林里，到处逛一圈，先做个路标。
+
+第一次阅读时，你可以单纯地浏览一下，**别求全部看懂，也不要追求速度**。在读的过程中，建议你结合自己的项目经验，随时做批注，在书上画圈圈，把你感兴趣的内容或者暂时不理解的内容都先标记下来。
+
+**2.精读**
+
+参加培训期间，你要根据老师的讲解和讲义，并结合自己的项目经验和问题，重新检视并深入理解每个概念，建立起对体系结构的清晰认知。
+
+在这个阶段，我建议你跟着培训进度，逐个精读这本书的每个章节，特别要留心那些跟你在实际工作中差距比较大的部分，以及之前做好的路标。
+
+**你要真正把培训老师当作你的资源，遇到问题多思考、抓住时机多提问，在弄懂方法原理的同时，更要去主动思考，你如何将这个学习引入自己的工作**。只有这样去学的话，你才能把枯燥的考级过程变成一个很好的实战能力提升机会。
+
+除此之外，我鼓励你结合专栏中对应章节的内容来学习。对照着实战中的要点，重新温习并深度理解，让理论与实践中的重点、难点充分融合在一起，以提升你的学习效果。
+
+**3.记忆**
+
+在考试之前，你要按照老师划的重点和考点进行必要的记忆，并完成足量的刷题练习。一般来说，培训机构在考前都会为你准备包含记忆点及重点题型的小册子，内容每年会有一定的翻新。
+
+这个阶段的重点是，**多总结学习和做题过程中遇到的问题，回顾书上的常见考点，反复加深理解。对于那些重点、难点，你要刻意去背诵下来。在考试之前，你要对熟练掌握各个知识点，并达到融会贯通的效果**。
+
+以前，我自己在学习的过程中，往往会重理解、轻背诵，特别是对这种应试型的死记硬背，我一点也不“感冒”，不自觉地总会忽视。后来我发现，经典的背诵式学习也是一种科学的学习方法。
+
+举个例子。小时候，我总被要求背诵诗文，可我当时并不理解，甚至还有些抗拒。但是，那些反复背诵下来的诗就好像刻录进了我的深层意识。在我遇到某些情景时，它们就会自然地跑出来，时常让我觉得惊叹不已。所以，**你看，从死记硬背到真正理解诗歌在表达什么，需要时间和阅历**。
+
+在PMP的学习中，有很多东西会超越你当前的经历。如果你实在无法理解，**那就允许自己先囫囵吞枣，考前把它们先背下来，耐心地等待它们自己酝酿、发酵**。总有一天，当你遇到合适的情景时，这些记忆就会跳出来，真正地在实战中帮助到你。
+
+## 项目管理进阶之路
+
+除了拿到PMP认证，有些同学还想在项目管理之路上继续进阶，甚至已经在考虑转型去做专业的项目经理了。这个时候，你需要考虑哪些因素呢？
+
+首先，**一旦涉及到职业选择，最关键的一点就是，尽可能不要让自己被很多外在的因素所左右**。你要回归自己的内心，问问自己为什么要做项目管理。
+
+我在留言区，经常看到两种典型的心态。
+
+**心态一：**
+
+> 
+“Leader安排我做项目管理，可能是看我能担事吧，就把越来越多的事，都往我这里塞。”
+
+
+如果你当前处于这个阶段，我建议你先不要着急进阶，而是**留些空间给自己，先想好，如果没有Leader的影响和要求，你自己个人的决定到底会是什么**。
+
+如果你发现自己的答案也是要做，那就调整心态，**变被动为主动，为自己的职业道路负起责任**；如果在尝试之后，你觉得自己确实不适合做项目管理，那就主动去和你的Leader沟通，把精力用在更适合你发挥专长的领域。这对公司来说，也是更好的选择。
+
+**心态二：**
+
+> 
+“程序员这个工种，可能没法干到老，我年纪也不小了，得提前为自己找条出路。”
+
+
+主动为自己规划未来，这样的做法值得肯定。但是，这种心态最大的问题是，**如果说程序员这个岗位不适合你一直干下去，那么，你如何确定项目经理就适合你呢？**
+
+实际上，想要确认这个职业与自己的匹配度，你需要注意的是，**性格内向或外向并不是影响转型的决定性因素**。如果你结合“六力模型”来看的话，你会发现，外向者在信息力上会更有优势，但内向者普遍拥有更加敏锐的感知力。可以说，对成为项目经理而言，这两种性格各有优劣，不分伯仲。那么，到底该如何确认呢？
+
+答案其实很简单，就是**看这项工作是否能够激发你更大的热情**。程序员和项目经理这两个职位的最大不同就在于，前者研究的是机器，后者研究的是人。如果说，程序员研究的是“**一堆代码在一起，如何运行会更好**”，那么项目经理研究的就是“**一群人在一起共同做一件事，如何运作会更好**”。
+
+要想成为一名专业的项目经理，你需要对人有敏感度，并且要发自内心地认为**研究人比研究代码更加有趣**。这也是我自己虽然在这条路上遇到了很多挑战，但依然乐此不疲的原因。
+
+除此之外，**在拥有热情的前提下，经验背景的差异都是可以用时间弥补的**。只要你坚持将学习与实战相结合，不断在实践中整合自己的经验，你就一定会不断精进。
+
+## 总结
+
+今天，我给你分享了我对PMP认证及考试的认识，希望能真正地给到你一些必要的参考。
+
+项目管理的进阶之路是一个螺旋式上升的过程，每一轮都需要以扎实的实战经验为依托。在这些经验的基础上，理论框架的萃取和点拨，才能起到画龙点睛的作用。
+
+**实战永远是我们不变的基调**。只有你把PMP的认证过程当作对自己的一次系统化的理论充电，让实战经验与理论框架充分碰撞，你才能真正地吸取PMP给你带来的真正价值。
+
+## 畅所欲言
+
+讲到这里，专栏的20讲内容就全部结束了。如果你在项目管理的进阶之路上有任何的疑问或困惑，都可以通过留言反馈给我。
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+