mod

极客时间专栏/项目管理实战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="">
+
+## 畅所欲言
+
+下一讲，我想跟你聊一聊如何在实践中进行学习，希望可以进一步帮你巩固学习成果。如果你在学习和实践的过程中，有特别需要解答的困惑，可以留言告诉我。
+
+欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
+
+