转载自 http://36kr.com/p/5043427.html

编者按：本文作者老万，36 氪经授权转载自其个人微信公众号“老万”（ID：laowanweixin），欢迎关注讨论。

昨天中午发生的一件小事儿，引发了我的一些思考。所以想聊一聊这个话题。

我跟项目组的一个同事说：这周五晚上我们项目组一起去公司旁边的『沪茗轩』聚餐，算是今年的开工饭吧。大家一起坐下来吃吃饭、聊聊天。你来统计一下具体人数。午休结束刚一上班，该同事就在项目群里面发了一条消息，内容为『周五晚上吃饭，统计一下 有谁有事儿不去的嘛？』 过了大概 10 分钟仍然没有人回复他『项目组大概 20 人左右』，我知道这个事儿他可能搞砸了。那么这个事儿如果我来执行，我会怎么做呢？以下是我写的一个脚本：

项目组年后开工聚餐，参加人数统计：

时间：本周五（16.02.19）晚 具体开餐时间待定

地点：沪茗轩 (出公司南门，向南走 800 米，马路右手边)

请大家在看到消息后及时给予反馈。如果确定去，请回复数字 1；确定不去，请回复数字 0。

回复截止时间今天下班前。

下班前十分钟，对于没有回复的人单独『电话或微信』确认一下。

最终输出统计结果。

从最终的执行结果来看，第二种肯定是更加有效的。那么我们可不可以通过学习，掌握如何更加有效地执行呢？

执行必须要基于故事化场景

其实，熟悉 GTD 的人应该可以很清楚的认识到：上面我写的脚本只不过是按照 GTD 的核心原则『收集、分类整理、拆分、执行和回顾（输出）』这五个步骤来具体把事情做完。我个人喜欢把 GTD 的这五个步骤进一步通俗化，称之为『故事化场景』

1、收集：这里面任务包含的信息有『项目组』、『吃饭时间』、『吃饭地点』、『需要确定多少人参加聚餐』

2、分类整理：『项目组』、『吃饭时间』和『吃饭地点』属于一类；这些是这个任务的输入，也可以称之为『因』。而『需要确定多少人参加聚餐』这个则是输出，也就是这个任务的『果』

3、拆分：拆分就是对上一步『分类整理』之后的每个元素进行进一步细化。细化必须要达到一个原则：参与输出的人（项目组的每一个成员）必须对你细化后的结果没有任何歧义或将歧义降低到你能控制的最小程度，而且参与者可执行。只有这样，拆分才是成功的、有价值的。我的拆分是这样的吃饭时间拆分：

明确周五的具体时间，并交代了一下具体开餐时间待定，因为这个虽然暂时未定，但是对大家可能比较重要。

周五晚 → 本周五（16.02.19）晚

具体开餐时间待定吃饭地点拆分：有些人可能不知道沪茗轩在哪，不知道周五下班后怎么过去。所以有必要查一下，详细说明下怎样才能到那边。

沪茗轩 → 沪茗轩（出公司南门，向南走 800 米，马路右手边）

项目组拆分：首先，需要确认一下项目组的成员列表；哪些今天在公司，哪些今天不在公司。然后，将项目组所有成员拉一个多人会话，通知聚餐事宜。对于特殊情况还没有来上班的同事，通过电话或微信等单独确认。

项目组 → 在公司的同事和不在公司的同事

确定参加人数拆分：首先，需要有效的统计方法，可以通过『软件投票统计』、『0 和 1 简单选择投票』。然后，需要对投票的结果进行跟踪。会不会有些人不在座位上或者根本没看到消息？想办法建立一种『提醒机制』。注意：这里的投票截止时间其实就是留给自己的一种『提醒机制』

确定参加人数 → 建立投票机制和最终确认提醒机制

4、执行：以上三个步骤都是为高效执行做的准备。执行才是至关重要的。

5、输出结果：将最终得到的统计情况进行整理，并最终输出。任务完成。整个事情的执行过程其实就是：任务的下发者讲诉了一个故事「任务」，并告诉了你故事的开头「输入」和结尾「输出」。而具体的执行者就是要把这个故事基于现实这样一个场景把它讲出来。而且故事讲的越好「高效执行」，大家也就越喜欢听「乐于参与」。

看来会讲故事还是真的挺重要的。

执行最终要关注效果，而不是效率

现代管理学之父彼得·德鲁克先生在谈到他是如何认识到效率和效果的区别时，讲诉了他和夫人 Doris Drucker 相识相爱的一个小故事。

德鲁克曾经暗恋一个女孩子 Doris，两人认识有六七年的时间，彼此印象深刻。后来，德鲁克去了伦敦并和这个女孩子失去了联系。突然有一天，他在伦敦的一个很长的地铁里面，突然看到了这个女孩子 Doris。 他乡遇故知，他们两个都是欣喜若狂。两个人这时都在扶手电梯上，德鲁克在上去，Dorish 在下来。然后德鲁克上来电梯以后，马上就掉头转到往下的那个电梯。而 Dorish 则在下了那个电梯之后，马上就掉头转到往上的那个电梯。这样他们就再一次擦身而过、失之交臂。因为两个人还都沉浸在相逢的那种狂喜当中。这种情景又重复了一次。最后，德鲁克终于意识到了：必须有一个人停下来，两个人才能真正的见面。所以他就停下来，等 Dorish 过来，他们才真正的拥抱在一起。这就是效率和效果的区别。电梯只是解决了效率的问题。但是，无论电梯多快，它只能解决从上到下或从下到上的问题，它不能保证你有效果，即：两个人能够最终拥抱到一起。

我们再想一想刚才聚餐的那个例子。

想象一下：如果项目组只有 5 个人，而且大家都坐在一起。那我刚刚写的那个故事场景的脚本肯定就要变了。『同事可以站起来，大声吼一声！而根本没必要码字、拉多人群等等。就可以高效的完成任务』。如果仍然采用我的那个脚本，无疑就是低效率的。

再想一下：如果是整个项目组有 50 个人呢？那可能我这个脚本也不一定合适，可能他需要写一封邮件。

如果是整个公司呢？他可能要发个广播消息或者在 OA 办公系统上发个通知。因为，这个时候，我的那个脚本注定无法产生最终的效果了。当然，我们根本就没有那么多活动经费，操这个心干啥呢...

执行必须要形成闭环，不断的输出和反馈

现实生活中，我们接收到的任务肯定比『聚餐统计人数』这个任务要复杂得多。形成执行闭环就是让事情有始有终，任务从启动到结束，形成一个完整的链条。

CTO 给你安排了一个技术预研任务，你应该定期反馈的工作包括：技术选型，遇到的困难，解决的办法，最终的预研结果等等。这些工作你都可以基于『故事化场景』来进行收集、分类整理、拆分、执行和输出。任务的最后，你应该提交一份技术预研报告，并针对这样一个结果发起一次评审。可惜的是，很多技术人员只对技术有热情，对反馈毫无概念。接到任务之后默默预研，完成之后默默等待下一个任务的降临，只要没人问，就一直牙关紧咬，目光坚毅，打死也不说。如果分配任务的人疏忽了，这个任务可能无疾而终了。

还有些技术人员，对任务的产出结果根本没有理解透彻，就立即开始执行。执行起来倒是非常迅速，看起来很努力、很高效。殊不知，这样的情况下，你做的越多，错得就越多。离最终的任务达成也就越来越远。这也就是傅盛所说的『不要用战术上的勤奋，来掩盖战略上的懒惰』这句话的一种真实写照。

近几年来，互联网行业、软件开发管理为什么一直在强调『敏捷』和『迭代』的原因。通俗来讲，就是要把一个较大任务的执行过程进行分解和拆分，形成若干个可以迅速执行的小任务。而每个迭代的产出都会是一种输出和反馈，用来验证这个迭代是否是朝着最终的目标更近了一步。一旦发现偏离了方向，一切的调整和改进都还来得及。

总结

总结一下，如何有效的执行。

首先，一定要明确执行的目标，执行的效果「而不是效率」决定了执行的最终意义和价值。

然后，具体执行时，一定要将任务进行『故事化场景』输出。这会帮助你有效的梳理清楚执行的方法，保证执行的过程更加有效率。

最后，在执行的过程中，一定要不断的迭代输出和反馈，不断地修改执行脚本。这个过程会帮你发现执行过程中出现的问题，及时作出调整。避免做很多毫无意义的努力。

希望这篇文章能够对我的那位同事有所帮助。也希望他能不断的学习和进步，执行更加高效，为项目和公司作出更多的贡献！

本文来自读者投稿，不代表 36氪 立场，如若转载，请注明出处：http://36kr.com/p/5043427.html

“看完这篇还不够？如果你也在创业，并且希望自己的项目被报道，请戳这里告诉我们！”