有一天，在“技术管理交流群”中，一位管理者抛出来一个问题请求支援，他说：“目前碰到一个问题，困扰我一段时间了。之前自己负责开发的时候，数据基本没问题。做管理之后，数据开发就分给别人做了。由于做管理沟通协调的工作占了我大量时间，团队成员的项目质量也没很好地把控，导致这次上线后出现问题较多。本来想着用人不疑，于是就大胆放权，结果出现了这么多问题。如果我自己亲自做是可以保证质量的，但时间又不够用，大家帮忙想想办法！”

如果当时你也在这个群里，你会怎么回复他呢？

要想有效地支持到他，我们首先得弄清楚问题的核心是什么。那么，这到底是个什么问题呢？人家已经交代得比较清楚了：数据开发这个工作，他没时间做，别人又靠不住，怎么办？显然，这是一个来自工作授权的挑战。

对于工作授权，在前面的第21篇文章中我们提到过，授权分为主动授权和被动授权。显然，对于这位管理者来说，他想做的是一次被动授权，即，自己忙不过来了，必须得有人来替他完成数据开发这项工作。他第一想要的是项目结果，只是他自己没有意识到这一点，把培养人的诉求也糅合进来了，比如他说“本来想着用人不疑，于是就大胆放权……”就显示出这种诉求的模糊。如果确定是要拿项目结果，就需要做出确保结果的安排，那被授权者的感受就不是第一位了。

能够兼顾做事和培养人，那自然是很美好的。但如果两者不能兼顾的时候，就需要非常清楚我们优先保证的是什么了。

当然，我并非是抓住这位管理者在授权方面的一点瑕疵不放，因为这并不是解决问题的关键。即便他非常清晰地意识到这就是一次被动授权，为了让别人把数据开发这项工作搞定，该怎么做呢？作为群友，我们是要给出建设性意见的。

我们说，要想让员工分担我们手头上的工作，要么靠梯队，要么靠机制。

所谓靠梯队，就是团队里有胜任度非常好的人，可以帮我们搞定这件事，并且这个人已经是这方面可靠的梯队人才。显然，我们案例中的管理者在数据开发上的梯队是靠不住的，那么就只能是靠机制了。

所谓靠机制，就是设计一套方案，来专门应对某个场景出现的问题，这套方案可以指导和“搀扶着”员工做好这类工作。你可能会说，带着员工一起做，不是会产生更好的效果吗？你说的有道理，但是这样做的最核心的目的达不到，即，要减轻管理者的负担和精力开销。

那么，机制要怎么建呢？

你可以先看看我们的对话。我是这样回复他的：“你这个问题并不难解决，因为你具备一个关键条件，就是你有成功经验。因为你亲自做这件事，是没有问题的，所以你要做的，要么就是把你的经验和能力迁移给员工，要么就是把你的经验和能力提炼出一套机制，让他们遵循这套机制来做就可以。作为管理者，如果你想抽出时间干别的，梯队和机制的建设会把你解放出来。”

“那么，我接下来梳理一下我的经验，形成文档。”他回答道。

“形不形成文档不是关键，很多文档整理出来也发挥不出作用。关键问题是，你觉得你做到了哪几点，让你可以保证项目质量？即，如果让你检查员工的工作，你检查哪几个点？”

“你提到的关键检查点的确很重要。我现在检查的时候，都是看到什么就问什么，觉得需要的话就去员工电脑上看一眼，这样可能会造成遗漏。”他想了想，继续说：“至于我为什么能保证质量，我觉得可能有三个点我做得比较好：第一，我特别关注数据指标的定义；第二，我会把数据计算逻辑和需求方进行确认；第三，我在交付项目前，会先做数据校验。”

“非常好，那么在你看起来，如果你的员工在这三个环节也都不出问题，你觉得他交付的项目质量能否得到保障？”我继续问道。

“八九不离十，不会出大的偏差。”

“那么如果你只是检查这三个关键点，你的时间和精力开销是否可以接受？”

“可以接受。”

“那么，这就是一套关于数据开发这件事的授权机制，你可以和员工商量一下怎么配合执行。”我总结道。

说到这里，我们就演示完成了一个授权机制的建立过程。在这个过程中，到底涉及到哪些步骤呢？归结起来，大体上是五步：

首先要明确该机制要解决什么场景下的什么问题，即明确目标。机制的一大特点，就是场景化特性非常明显，因为它们都是为了应对好特定场景下的问题而产生的。比如服务报警响应机制、公关事件应对机制、新人入职培养机制、项目沟通机制等等，你会发现前面的定语都是场景化的。对于我们前面的案例来说，就是为了应对“梯队靠不住，自己又没时间时，数据开发项目如何推进”这个场景。所以，你建立一个机制时，首先要描述清楚场景是什么。
提炼应对该场景的关键点。从你和其他经验丰富的人身上提炼出应对该场景的关键环节，因此当有成功经验时，这些关键点的提炼会容易得多。这里，我并没有说要去整理一个流程文档，因为和一个步骤完整的文档相比，关键点的提炼更为重要，这会让执行成本降低，也更有可操作性。这就是为什么在前面的案例中，我要问“你觉得你做了哪几点，让你可以保证项目质量？”而没有说：“你可以把你的经验整理成操作文档让员工照做。”
明确由谁来确保机制的执行，即谁在什么时候检查什么关键点。每个流程和机制的执行情况如何，谁来检查和确认呢？如果少了这个监督者，流程和机制的有效性就得不到保证。所以，每个机制，都要设立监督者或检查者。显然在前面的案例中，这位管理者本人就是那个检查者，也只有他自己才可以胜任。
确认操作成本。即，确认该机制对于执行者来说是可操作的。你建立机制是为了简化工作，最好能够做到“自动驾驶”，如果建立的机制反而给执行者带来更大的操作成本，那你就得反思这个机制建立的必要性。所以在前面的案例中我才会问：“你的时间和精力开销是否可以接受？”
沟通，并和其他执行人取得共识。由于机制的制定者和执行者常常不是同一个人，所以，该机制是否有效，以及能否实施，需要和其他执行人沟通，并达成一致。这就是我在前面的案例中最后所交代的“和员工商量一下怎么配合执行”。

通过这五个步骤，相信你也会制定出应对各种场景的机制。不过，随着日积月累，你会发现机制和流程越来越多，它们慢慢变得不再那么好用，最后甚至长篇累牍地躺在一些页面上“睡大觉”。那如何才能让这些流程机制得到有效的执行呢？

我认为，要想让机制具有可执行性，建立机制时还要遵循如下的四个原则：

可操作，即简单原则。也就是说，机制要以最小的学习成本和操作成本为原则，这是最首要的原则。如果建立的机制不具备可操作性，那么你自我感觉再完美，能应对的问题再多，最后也要被抛弃掉的。因为不具备操作性的机制是没有意义的。
只打关节点，即关键原则。建立一套机制，不必要对所有的细节进行完整的描述，没有人喜欢看长篇大论的文字，你只要告诉大家，在哪几个最关键的节点，做什么样的动作即可，而且这样的关键点也不能太多，以不超过5个为宜。这样做可以大大降低执行成本，提升机制的可操作性。
明确到人，即问责原则。在各个关键点由谁来跟进呢？这个问题要有明确的约定，不能完全靠人的自觉性。比如，你建立一个发红包的机制，若你只是说一句“迟到的发红包”，那你会发现，经常有人迟到了也不发红包；但如果你指定了一个监督人，由他去监督执行，那这个红包机制的运作就没有问题了。这就是所谓的问责原则。
从case中来，到case中去，即实用原则。千万不要为了建机制而建机制，每一个机制都要有实用价值。由于机制都是有场景化特性的，当场景发生了变化，机制也要随着升级，而对于机制的重新审视和学习都意味着额外的开销，所以，每个机制的维护都是有成本的。如果没有随着场景更新升级，那这些机制也就成了没有意义的机制，时间长了就变成大家常遇到的情况：什么机制都有，但是大家不执行，或执行效果不好，反而成了管理的累赘和负担。

如果我们在建机制的时候能够遵循上面四个原则，就可以大大提升机制的可执行性了。

在文章的最后，我想再分享两个关于机制的观点。

机制不是越多越好，而是越少越好。这个观点和前面提到的关于机制的简单原则、实用原则一脉相承。你要明白一个道理：机制的建立并不会解决问题，对机制的执行才能解决问题，而机制的建立、执行和后期维护都是需要成本的，所以，千万不要贪多，在风险可控的前提下，机制能不建就不建，能少则少。
关于到底是人靠谱还是机制靠谱。很多管理者都认为，事情都是人做的，人如果足够靠谱，机制就没什么用了。对此，我的看法是，人的靠谱度的方差比机制大，即，人靠谱的时候比机制靠谱，人不靠谱的时候会比机制更加不靠谱。即便是最靠谱的员工，也会由于身体状态、精神状态、情绪状态以及外部干扰变得偶尔不靠谱，而机制的意义就在于，当人不靠谱时，事情也不至于变得很差。所以，机制是为了保证做事的“下限”的。同时，机制有很好的迁移性和传承性，不会随着某个人的缺位而产生大的影响。因此，必要的机制是不可或缺的。

好了，关于如何让流程机制得到有效的执行，我们就先探讨到这里。逐步健全的梯队加上良性运作的机制，可以让管理者越来越体验到“自动驾驶”的感觉，你有此期待吗？