mod

极客时间专栏/技术管理实战36讲/任务执行篇（管理三部曲之三）/25 | 多任务并行该如何应对？.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="25 | 多任务并行该如何应对？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3c/84/3c5c4e3c59cffd6b7ebdacd9b52b9c84.mp3"></audio>
+
+管理工作的三部曲——管理规划、团队建设和任务管理，到现在我们已经探讨完了管理规划和团队建设，从本文开始，我们进入任务管理的章节，也就是我们口头说的“做事”。
+
+**如果说我们研究管理规划，是为了把事儿做对，我们研究团队建设，是为了理顺做事儿的主体，那么，我们研究任务管理，就是为了把事情做出来，产出实实在在的业绩和成果**。作为结果导向的管理者，这才是管理工作的落脚点。同时，也是验证管理规划是否合理、团队建设是否有效的最重要的标准和依据。
+
+因此，“做事”是非常重要的管理内容。
+
+既然这个事情这么重要，那我们是不是要花很多篇幅来探讨呢？不是的，我们从整个专栏的目录也可以看出，“任务管理”的比重并不高。这是为什么呢？因为这部分内容在大多技术管理者看起来都不是问题。
+
+我在各种规模的公司都做过调研，所有的统计结果都显示，相对于其他管理话题，任务管理是技术管理者们最拿手的一项，不只是他们自己这么认为，他们的上级也是如此评价的。我想，这可能和工程师出身有关，工程师有一种确定性思维， “靠谱”是好的工程师天生的品质，凡是明确答应过的事情，往往都会如数兑现。
+
+仔细回忆一下你遇到的执行问题，你也会发现，几乎大部分执行问题的主要症结不在执行本身，而是在角色认知、管理沟通、管理规划和团队建设上，因此，我们在“任务管理”这个主题上，也主要是探讨一些要点。
+
+对于很多团队来说，大部分工作都是以“项目”形式存在的，因此，任务管理大体上又是项目管理，只是为了涵盖非项目的那些工作，我才把“做事”叫做任务管理。
+
+话说回来，“做事”这个话题依然很大，我们要如何探讨呢？既然做事是一个过程，那么我们就分成“事前”“事中”和“事后”三段来探讨。
+
+**在做事之前**，我们需要回答的问题是：要做哪些事？先做哪件，后做哪件？也就是分清楚轻重缓急，也叫优先级梳理。
+
+**在做事过程中**，我们要确保事情的进展按照计划推进，尽在掌握之中，也就是有效地推进执行。
+
+**在做事之后**，我们要复盘做事的整个过程，并从过去的经验之中抽取一些流程机制，以便以后在类似的场景下也可以做得更好、更顺畅。
+
+因此，我们把事前的**轻重缓急**、事中的**有效执行**和事后的**流程机制**，称为任务管理三要素。这也是接下来三篇文章的三个主题。今天，我们就首先看看第一个要素，关于轻重缓急的梳理。
+
+<img src="https://static001.geekbang.org/resource/image/2a/1e/2ae92847af34409a489198a7a1a6911e.png" alt="" />
+
+虽然大部分技术管理者都不认为自己在任务管理方面是短板，但是仍然有一些问题困扰着大家，比如，“多任务并行该如何应对”，就是其中最突出的一个，特别是刚刚走上管理岗位不久的新经理尤其如此。为什么大家会头疼这个问题呢？因为大家面临的问题常常是人手不够，时间不多，但是要完成的工作却还在一件一件挤进来，这可怎么办呢？
+
+实际上，对于每个团队来说，当下能做的工作是有限的，增加并发并不会让大家的产出更高效，所以，多任务并行问题归根结底还是优先级问题，即，你要优先保证哪项工作的顺利进行。
+
+排项目优先级对于管理者来说是必备技能了，每月、每周甚至每天都在训练，相信你也对于“重要紧急四象限”耳熟能详了。我其实挺好奇，这个“四象限”对于盘点各项工作的优先级是否好用呢？
+
+<img src="https://static001.geekbang.org/resource/image/60/a9/60986386cc4cb09e2af292315d205da9.png" alt="" />
+
+我了解到的情况是，大家都很清楚“重要紧急的工作要排在最前面”“重要的工作要像大石头一样做长远安排”“紧急的工作要立即着手”“不重要不紧急的工作直接丢弃”等应对策略。可是令大家最困惑的是，到底怎么判断一项工作重要不重要，紧急不紧急呢？这个前置步骤才是最难以判断的，我举两个例子：
+
+1. 老板刚刚口头交代的临时任务，这到底是紧急重要的、紧急不重要的，还是重要不紧急的呢？这个场景常常被倾向于认为是紧急重要的情况，必须如此吗？
+1. 锻炼身体、学习培训常常被倾向于认为是重要不紧急的事情，情况真的如此吗？
+
+对于上面的这两个场景，不同的人、不同的上级、不同的任务和不同的情况下，可能会被归入不同的象限，这并没有一个可供遵循的一定之规。那么当我们面对这样的问题时，该如何判断其是否重要紧急呢？
+
+我采取的策略是问自己这两个问题：
+
+1. 如果做，收益是否很大？收益越大，这个事情就越重要。
+1. 如果不做，损失是否很大？损失越大，这个事情就越紧急。
+
+你可能会有疑问，不做的损失越大，不也意味着很重要吗？为什么只强调紧急呢？我想说的是，如果想简化问题，就需要结合我们的实际工作场景。在实际的工作中，我们经常做的并不是梳理轻重缓急四象限，更常见的情形是，我们要把日常的工作分为两种情况：一种是计划内的，也就是按照我们的规划进行的；另外一种是计划外的，即突发的情况和任务。
+
+我们的应对策略其实非常简单：
+
+1. **对于计划内的工作**，我们更关注它在一个规划周期内的价值和收益有多大。我们会把价值足够大的任务安排进来，并持续地往前推进。
+1. **对于计划外的工作**，由于是一种突发情况，是否要中断既有安排来高优先级跟进呢？中断既有安排一定是会影响正常推进的收益的，所以我们要做的决定是，是否要立刻跟进？如果不立刻跟进，带来的损失有多大？我们是否愿意并能够承担？如果不能，那就立即跟进。如果可以不立即跟进，那就转化为一个可以安排到“计划内”的工作，并参考第1条的策略就可以了。
+
+**总结起来，对于任何工作任务，决策的步骤就两步：**
+
+1. **对于“计划内工作”，看收益是否足够大。收益越大就越重要，也就越需要给予相匹配的优先级、资源和关注度；收益相对不大，就放入“To do list”，作为待办任务处理。**
+1. **对于“计划外的工作”，看损失是否足够大。损失够大，就按照紧急任务安排，以止损为核心目的；如果损失可控，就放入“计划内工作”列表。**
+
+这样是不是就容易操作了呢？
+
+于是，我们可以改进一下“紧急重要四象限”，让它更加方便实操。既然我们可以通过看收益来判断重要性，通过看损失来判断紧急性，那么这个四象限我们就可以调整如下。
+
+<img src="https://static001.geekbang.org/resource/image/d4/41/d423f48eae814f84bdd2ee52a8c96241.png" alt="" />
+
+关于任务优先级的安排，除了决策的步骤和方法，还有几个重要的原则，这里我特别交代一下，方便我们对齐认知。
+
+**第一，目标是需要一以贯之的**。前面我们提到，通过看收益来判断一个任务是否重要，那么你参照什么来衡量收益呢？答案是目标。我们规划的目标里蕴含着我们一段时期内最重要的诉求和期待，也是衡量一项工作收益大小的坐标轴。
+
+于是你会发现，目标的设定和评估贯穿着整个管理工作的全过程，目标越明确，在关键时刻我们的方向感就越强；反之，我们就会瞻前顾后，反复掂量却不得要领。所以，好的决断力，往往基于明确的诉求和目标。
+
+**第二，任务安排是弹性的**。很常见的一个情况是，我们在做任务安排的时候，往往不自觉地会在心里做一个设定，即，这个项目做成某个样子才叫完成，所以需要预算这么多时间。而实际上，对于一个任务来说，其进度、质量和效果这三个要素是可以此消彼长的，所以在拆解任务的时候，对进度的预期不同，对质量的要求不同，对效果的期待不同，都会导致时间预算和优先级的变化。
+
+所以，不能用固化的视角看待一个任务，每一个任务其实都是可以弹性安排的，不一定是你需要的4周，也不见得是上级希望的两周，根据进度、质量、效果的不同期待，你可以给出很多种排期方案。这体现一个管理者的经验是否丰富。
+
+**第三，沟通是不可或缺的**。虽然排优先级主要是管理者来做，但是这并不意味着排好优先级之后就大功告成了。只有和所有相关的人员充分沟通了之后，才算是调整完毕，尤其是和自己的上级，一定要和他沟通新的工作安排方案。告诉他，你优先保证了什么，从而可能会影响什么。
+
+一个有意思的情况是，上级更倾向于告诉你，他们想要什么；而不会主动告诉你，他们愿意用什么来交换。这不是他们“唯利是图”，也不是他们“只让马拉车不让马吃草”，而是因为评估影响并给出应对方案是你的工作，这是你最清楚且拿手的，而上级判断不出对你既有安排的影响到底多大。
+
+所以，很多上级管理者跟我说，他们默认是需要沟通的，而不是默认不沟通，最怕大家最后给他们一些“surprise”。
+
+此外，很多上级倾向于告诉你，每件工作都是重要的，都是要正常推进的。但这其实只是美好的愿望，你心里要有数。如果所有的工作都重要，那就意味着没有重要的工作，所以，你要清楚上级最核心的期待是什么，这就需要看你们长期合作磨合出的默契了。
+
+好了，关于“做事”之前，我们如何安排任务的轻重缓急，我们就先探讨到这里。这篇文章，我们主要探讨了做事所包含的三个要素，以及在做优先级梳理时，可以遵循的步骤和原则。如果这恰好是你擅长的管理内容，欢迎你留言和大家分享你的经验和技巧。
+
+

极客时间专栏/技术管理实战36讲/任务执行篇（管理三部曲之三）/26 | 如何确保项目的有效执行？.md

@@ -0,0 +1,104 @@
+<audio id="audio" title="26 | 如何确保项目的有效执行？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7c/99/7c2f91b2a57df2b54d66e039f4adda99.mp3"></audio>
+
+在上一篇文章，我们探讨了如何梳理任务优先级，解决了“做什么”的问题。本文我们来看看如何把任务列表中的这些事儿都落实到地上，也就是“怎么做”的问题，即，如何确保执行过程可控、执行结果符合预期？
+
+关于如何确保项目的有效执行，我们有两个探讨的角度。
+
+第一个角度是充分条件视角，即，列出有效执行的所有要点，大家照着做就可以把项目执行好。估计这是很多新经理都希望的一个方案，但是，这基本是实现不了的。就别说是适用很多公司各个场景了，即便是总结出一套适用于一个公司多类项目的方案，也很难做到。所以，我们还是从另外一个角度来看项目执行的问题。
+
+第二个角度是必要条件视角，即，我们探讨出一些要点，在项目执行中，只要有一个要点没有做到，项目就很难得到有效的实施。我们把这些要点整理出来，为我们的项目执行提供有价值的参考。
+
+那么，都有哪些要点呢？换句话说，有哪几件事做不好，就必然会引发项目执行过程的不可控呢？结合我过去的项目管理经历和调研访谈来看，我发现有四大类问题最为集中。
+
+**第一大类**，不知你是否遇到过如下的情况呢：
+
+<li>
+虽然你很清楚做某项目的初衷，但是并没有去设定可以衡量的目标。比如某次技术重构、某个模块性能优化等。也就是说，虽然你知道自己想要什么，但是不知道出于什么原因，你没有设定一个清晰可衡量的目标，而目标不够清晰的话，必然会引发时间预算、人力预算，以及优先级决策的模糊。
+</li>
+<li>
+虽然在你眼中目标很清晰，比如“到年底某模块单机性能达到500qps”，但是负责项目实施的员工并不知道该从哪里下手去执行。
+</li>
+<li>
+在你看起来，两周能搞定的事情，员工却花了3周时间。诚然，完成质量的确很高，可是和质量比起来，你更希望在2周内发布。
+</li>
+<li>
+项目交付时间提前到这个周末了，员工没有完成，可他为什么还一副很无辜的样子呢？
+</li>
+<li>
+项目是如期发布了，可是这不是你想要的效果啊！
+</li>
+
+诸如此类的状况层出不穷。它们的共同特点在哪里呢？显然，它们都是有目标的，但是这个目标出现了三个情况：
+
+1. **目标不够明确具体，至少没有具体到执行人员可以执行的程度。**
+1. **上、下级对目标的理解看似一致，实则有偏差，尤其是对进度、质量和效果的拿捏上。**
+1. **目标发生变化了，没有及时同步给相关的人员。**
+
+归结起来，这三种情况都导致了目标不清晰的后果。当目标不清晰的时候，必然会引起员工在紧急程度、质量水平和效果取舍上的偏差，最后也就引发了执行上的偏离预期。你也可以回忆一下那些执行良好的项目，你应该不难发现，它们都有一个共同而又必要的条件：清晰的目标，只不过在实际执行过程中，每个人对“清晰”的理解会有所不同。
+
+**第二大类**，请你回想一下在执行上令你不够满意的那些项目。然后问自己如下三个问题：
+
+1. 这个项目涉及到的各个相关团队，是否都有一个明确的负责人呢？
+1. 这个负责人和所有项目组成员，是否都清楚各方面的负责人呢？
+1. 这个项目是否有唯一的总负责人，以及总负责人是否有效呢？
+
+这些看上去非常普通的问题，却是很多项目执行障碍的一大源头。其中有两个模糊的地方，让“责任人”这个简单的问题变得失控。
+
+**第一个地方是：各负责人对于“负责”的理解常常是不一致的**。很多负责开发的工程师，他们认为的“负责”就是承担自己份内的开发工作，而项目某一角色的负责人是指对该项目中所有涉及项目执行和协调的问题都要负责。
+
+**第二个地方是：总负责人无效**。即，虽然有名义上的总负责人，但是总负责人顾不过来也好、自己不认同也好，都会在项目执行过程中“缺位”。比如，各个角色的负责人，都会把他们的共同上级作为默认的总负责人；还有些创业公司干脆是创始人号称要自己带项目，但是这些人实际上又没这个时间和精力，在其位不能谋其政，所以导致的后果就是项目总出问题，然后就怪这个怪那个……
+
+对于这个问题，我有个经过验证的方案可供参考。即，把上级作为“客户”来看待，并另寻总负责人和这个“客户”来对接需求。而这个总负责人，是从项目的各个角色的团队负责人中产生，来总体负责和协调该项目。如果各个角色之间有长期稳定的合作关系，比如某APP的迭代团队，就可以把各个角色的负责人组织起来，组成一个项目管理的虚拟组织，大家轮流来做总负责人。这样既解决了项目总负责人缺失的问题，还培养出多个更高级的项目管理人才。并且假以时日，整个团队甚至整个公司的项目交付水平，都会有明显的提升。
+
+这归结起来，第二类问题是集中在大家认为最简单、最容易，但又最容易忽视的项目总负责人的“缺位”上。
+
+**第三大类**，常见的说法有：
+
+1. “如果A也像B那么积极主动，这个项目就不会出问题了，所以A，你能不能更主动一些呢？”
+1. “我们明明约好了有问题及时通报，为啥总有些人不通报呢！”
+1. “我们各种各样的流程都有，很完整也很系统，但是大家就是不按照流程办事……”
+
+你能看出上面这些说法反映了一个什么问题吗？
+
+由于我们见识过某些优秀人员的优秀表现，所以我们就过于迷信人的主动性和职业水平，等出现了问题的时候，就总觉得是“人不行”。事实上，团队成员的能力水平都是正态分布的。另外，如果真的是“人不行”，那么人从“不行”到“行”也会是一个缓慢的过程，而此时此刻你就得做事，那你打算怎么办呢？这就要靠流程和机制了。
+
+于是很多管理者就制定了全套的流程让团队遵循，但由于学习和执行成本很高，员工遵循起来非常痛苦，因此就干脆让流程机制去“睡大觉”。这也是很多团队的真实情况，他们有很多流程机制、规章制度的页面，但是还是做不好项目。
+
+归结起来，这类问题主要体现为：
+
+1. 过于依赖人的主动性，缺乏基本的流程和机制。
+1. 虽然有机制，但是没有人监督执行。
+1. 虽然机制有人监督执行，但是大家依然不愿意执行。
+
+关于这个问题，我们会在下一篇文章中专门探讨，此时我们先不展开。只要了解到，这是项目执行问题的一个关注维度即可。
+
+**第四大类**，常见的说法有：
+
+- “我通知了啊，为啥他们就是不听呢？”
+- “对方有问题不主动找我沟通，关我什么事！”
+- “我不知道啊！什么时候变更的？”
+- “不是说好了周五交付的吗，他们没有如期交付啊！”
+
+类似的说法还有很多很多。相信你一眼就可以看出，这类情况就是“信息不对称”，大家在一些事情上没有达成共识，由此产生了协作上的偏差和误会。原因可能是对信息本身的理解就不一致，也可能是没有有效传递和同步，总之在沟通这个问题上有诸多的不顺畅，归结起来就是：
+
+1. 主动意识不足，沟通不够主动。
+1. 通报意识不足，没有知会到所有相关人员。
+1. 闭环意识不足，广播出去了，就默认对方收到了。
+
+无论是哪种情况，导致的后果就是沟通没有到位。关于管理沟通的问题，是我们下一个篇章的主题，到时候我们也会做更详细的探讨。这里，我们先了解到，沟通不畅，是项目执行不到位的主要原因之一。
+
+至此，我们就了解了项目执行过程中最常见的四类问题。
+
+当然，关于项目得不到有效执行，也许还有许许多多的其他问题，就好像“不幸的生活各有各的不幸”一样，项目执行不好也各有各的原因。上面我们阐述的，只是最常见的四类问题。如果你的项目没有这四类问题，不见得一定执行良好，但是如果出现了这四类问题中的某一类，执行上一定会有问题。
+
+所以，我把避免这四类问题的钥匙归结为“有效执行四要素”，即**目标清晰**、**责任明确**、**机制健全**和**沟通到位**，以方便我们梳理和诊断执行问题。
+
+<img src="https://static001.geekbang.org/resource/image/15/98/15a71a04ffeaa5b09c1aa6952d6ae298.png" alt="" />
+
+为了提升可操作性，我把这四个要素扩展为12个问题，如果你对某个项目的执行不够满意，又想了解到底是哪里出了问题的时候，就可以参照这个“问题清单”检查一下。相信很快你就可以找到问题所在，从而对症下药。
+
+<img src="https://static001.geekbang.org/resource/image/8a/6f/8a6ec8ff2d0a9efb23b5585a5ef1536f.png" alt="" />
+
+项目或任务的管理和有效执行，是很多技术管理者的拿手好戏，本文可以算是抛砖引玉。你是否愿意分享你的心得和方法呢？欢迎你留言和大家分享。
+
+

极客时间专栏/技术管理实战36讲/任务执行篇（管理三部曲之三）/27 | 如何让流程机制得到有效的执行？.md

@@ -0,0 +1,89 @@
+<audio id="audio" title="27 | 如何让流程机制得到有效的执行？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/df/e5/df7650f44c8a811dbff8917498c94ae5.mp3"></audio>
+
+有一天，在“技术管理交流群”中，一位管理者抛出来一个问题请求支援，他说：“目前碰到一个问题，困扰我一段时间了。之前自己负责开发的时候，数据基本没问题。做管理之后，数据开发就分给别人做了。由于做管理沟通协调的工作占了我大量时间，团队成员的项目质量也没很好地把控，导致这次上线后出现问题较多。本来想着用人不疑，于是就大胆放权，结果出现了这么多问题。如果我自己亲自做是可以保证质量的，但时间又不够用，大家帮忙想想办法！”
+
+如果当时你也在这个群里，你会怎么回复他呢？
+
+要想有效地支持到他，我们首先得弄清楚问题的核心是什么。那么，这到底是个什么问题呢？人家已经交代得比较清楚了：**数据开发这个工作，他没时间做，别人又靠不住，怎么办**？显然，这是一个来自工作授权的挑战。
+
+对于工作授权，在前面的第21篇文章中我们提到过，授权分为主动授权和被动授权。显然，对于这位管理者来说，他想做的是一次被动授权，即，自己忙不过来了，必须得有人来替他完成数据开发这项工作。他第一想要的是项目结果，只是他自己没有意识到这一点，把培养人的诉求也糅合进来了，比如他说“本来想着用人不疑，于是就大胆放权……”就显示出这种诉求的模糊。如果确定是要拿项目结果，就需要做出确保结果的安排，那被授权者的感受就不是第一位了。
+
+能够兼顾做事和培养人，那自然是很美好的。但如果两者不能兼顾的时候，就需要非常清楚我们优先保证的是什么了。
+
+当然，我并非是抓住这位管理者在授权方面的一点瑕疵不放，因为这并不是解决问题的关键。即便他非常清晰地意识到这就是一次被动授权，为了让别人把数据开发这项工作搞定，该怎么做呢？作为群友，我们是要给出建设性意见的。
+
+我们说，**要想让员工分担我们手头上的工作，要么靠梯队，要么靠机制**。
+
+所谓靠梯队，就是团队里有胜任度非常好的人，可以帮我们搞定这件事，并且这个人已经是这方面可靠的梯队人才。显然，我们案例中的管理者在数据开发上的梯队是靠不住的，那么就只能是靠机制了。
+
+所谓靠机制，就是设计一套方案，来专门应对某个场景出现的问题，这套方案可以指导和“搀扶着”员工做好这类工作。你可能会说，带着员工一起做，不是会产生更好的效果吗？你说的有道理，但是这样做的最核心的目的达不到，即，要减轻管理者的负担和精力开销。
+
+那么，机制要怎么建呢？
+
+你可以先看看我们的对话。我是这样回复他的：“你这个问题并不难解决，因为你具备一个关键条件，就是你有成功经验。因为你亲自做这件事，是没有问题的，所以你要做的，要么就是把你的经验和能力迁移给员工，要么就是把你的经验和能力提炼出一套机制，让他们遵循这套机制来做就可以。作为管理者，如果你想抽出时间干别的，梯队和机制的建设会把你解放出来。”
+
+“那么，我接下来梳理一下我的经验，形成文档。”他回答道。
+
+“形不形成文档不是关键，很多文档整理出来也发挥不出作用。关键问题是，你觉得你做到了哪几点，让你可以保证项目质量？即，如果让你检查员工的工作，你检查哪几个点？”
+
+“你提到的关键检查点的确很重要。我现在检查的时候，都是看到什么就问什么，觉得需要的话就去员工电脑上看一眼，这样可能会造成遗漏。”他想了想，继续说：“至于我为什么能保证质量，我觉得可能有三个点我做得比较好：第一，我特别关注数据指标的定义；第二，我会把数据计算逻辑和需求方进行确认；第三，我在交付项目前，会先做数据校验。”
+
+“非常好，那么在你看起来，如果你的员工在这三个环节也都不出问题，你觉得他交付的项目质量能否得到保障？”我继续问道。
+
+“八九不离十，不会出大的偏差。”
+
+“那么如果你只是检查这三个关键点，你的时间和精力开销是否可以接受？”
+
+“可以接受。”
+
+“那么，这就是一套关于数据开发这件事的授权机制，你可以和员工商量一下怎么配合执行。”我总结道。
+
+说到这里，我们就演示完成了一个授权机制的建立过程。在这个过程中，到底涉及到哪些步骤呢？归结起来，大体上是五步：
+
+<li>
+**首先要明确该机制要解决什么场景下的什么问题，即明确目标**。机制的一大特点，就是场景化特性非常明显，因为它们都是为了应对好特定场景下的问题而产生的。比如服务报警响应机制、公关事件应对机制、新人入职培养机制、项目沟通机制等等，你会发现前面的定语都是场景化的。对于我们前面的案例来说，就是为了应对“梯队靠不住，自己又没时间时，数据开发项目如何推进”这个场景。所以，你建立一个机制时，首先要描述清楚场景是什么。
+</li>
+<li>
+**提炼应对该场景的关键点**。从你和其他经验丰富的人身上提炼出应对该场景的关键环节，因此当有成功经验时，这些关键点的提炼会容易得多。这里，我并没有说要去整理一个流程文档，因为和一个步骤完整的文档相比，关键点的提炼更为重要，这会让执行成本降低，也更有可操作性。这就是为什么在前面的案例中，我要问“你觉得你做了哪几点，让你可以保证项目质量？”而没有说：“你可以把你的经验整理成操作文档让员工照做。”
+</li>
+<li>
+**明确由谁来确保机制的执行，即谁在什么时候检查什么关键点**。每个流程和机制的执行情况如何，谁来检查和确认呢？如果少了这个监督者，流程和机制的有效性就得不到保证。所以，每个机制，都要设立监督者或检查者。显然在前面的案例中，这位管理者本人就是那个检查者，也只有他自己才可以胜任。
+</li>
+<li>
+**确认操作成本**。即，确认该机制对于执行者来说是可操作的。你建立机制是为了简化工作，最好能够做到“自动驾驶”，如果建立的机制反而给执行者带来更大的操作成本，那你就得反思这个机制建立的必要性。所以在前面的案例中我才会问：“你的时间和精力开销是否可以接受？”
+</li>
+<li>
+**沟通，并和其他执行人取得共识**。由于机制的制定者和执行者常常不是同一个人，所以，该机制是否有效，以及能否实施，需要和其他执行人沟通，并达成一致。这就是我在前面的案例中最后所交代的“和员工商量一下怎么配合执行”。
+</li>
+
+通过这五个步骤，相信你也会制定出应对各种场景的机制。不过，随着日积月累，你会发现机制和流程越来越多，它们慢慢变得不再那么好用，最后甚至长篇累牍地躺在一些页面上“睡大觉”。那如何才能让这些流程机制得到有效的执行呢？
+
+我认为，要想让机制具有可执行性，建立机制时还要遵循如下的四个原则：
+
+<li>
+**可操作，即简单原则**。也就是说，机制要以最小的学习成本和操作成本为原则，这是最首要的原则。如果建立的机制不具备可操作性，那么你自我感觉再完美，能应对的问题再多，最后也要被抛弃掉的。因为不具备操作性的机制是没有意义的。
+</li>
+<li>
+**只打关节点，即关键原则**。建立一套机制，不必要对所有的细节进行完整的描述，没有人喜欢看长篇大论的文字，你只要告诉大家，在哪几个最关键的节点，做什么样的动作即可，而且这样的关键点也不能太多，以不超过5个为宜。这样做可以大大降低执行成本，提升机制的可操作性。
+</li>
+<li>
+**明确到人，即问责原则**。在各个关键点由谁来跟进呢？这个问题要有明确的约定，不能完全靠人的自觉性。比如，你建立一个发红包的机制，若你只是说一句“迟到的发红包”，那你会发现，经常有人迟到了也不发红包；但如果你指定了一个监督人，由他去监督执行，那这个红包机制的运作就没有问题了。这就是所谓的问责原则。
+</li>
+<li>
+**从case中来，到case中去，即实用原则**。千万不要为了建机制而建机制，每一个机制都要有实用价值。由于机制都是有场景化特性的，当场景发生了变化，机制也要随着升级，而对于机制的重新审视和学习都意味着额外的开销，所以，每个机制的维护都是有成本的。如果没有随着场景更新升级，那这些机制也就成了没有意义的机制，时间长了就变成大家常遇到的情况：什么机制都有，但是大家不执行，或执行效果不好，反而成了管理的累赘和负担。
+</li>
+
+如果我们在建机制的时候能够遵循上面四个原则，就可以大大提升机制的可执行性了。
+
+在文章的最后，我想再分享两个关于机制的观点。
+
+<li>
+**机制不是越多越好，而是越少越好**。这个观点和前面提到的关于机制的简单原则、实用原则一脉相承。你要明白一个道理：机制的建立并不会解决问题，对机制的执行才能解决问题，而机制的建立、执行和后期维护都是需要成本的，所以，千万不要贪多，在风险可控的前提下，机制能不建就不建，能少则少。
+</li>
+<li>
+**关于到底是人靠谱还是机制靠谱**。很多管理者都认为，事情都是人做的，人如果足够靠谱，机制就没什么用了。对此，我的看法是，人的靠谱度的方差比机制大，即，人靠谱的时候比机制靠谱，人不靠谱的时候会比机制更加不靠谱。即便是最靠谱的员工，也会由于身体状态、精神状态、情绪状态以及外部干扰变得偶尔不靠谱，而机制的意义就在于，当人不靠谱时，事情也不至于变得很差。所以，机制是为了保证做事的“下限”的。同时，机制有很好的迁移性和传承性，不会随着某个人的缺位而产生大的影响。因此，必要的机制是不可或缺的。
+</li>
+
+好了，关于如何让流程机制得到有效的执行，我们就先探讨到这里。逐步健全的梯队加上良性运作的机制，可以让管理者越来越体验到“自动驾驶”的感觉，你有此期待吗？
+
+