顶级活动策划进阶：执行篇，执行的关键在于公共人力资源

主题篇，既要被发现，也要被传播

奖励篇，调动用户参与意愿的关键

规则篇，让双方交换更容易达成

宣传篇，不是通知用户，而是打动用户

成本篇，控制活动成本的四个环节

风险篇，正确认识风险，积极拥抱风险

数据篇，必须了解的数据分析方法论

执行篇，执行的关键在于公共人力资源

复盘篇，团队加速成长的秘密

做活动从来都不是单打独斗，活动的阵势越大，调用的其他部门的人力资源越多。

活动从设计到开发到最后执行，运营都需要其他部门同事的帮助，这个其他部门，我们可以统称之为公共资源，他们是技术，美术，运维，客服，财务，行政等一切二线后勤支援部门。

尽管我们拥有了完整、系统的活动方法论，准备大干一场，但实际的工作之中，发现这个不可以（别人家可以，我们为什么不可以），那个又很难（功能、接口、人力资源支持有限），感觉处处受到限制。

于是我们尝试努力，但事情并不如人所愿，然后开始默默抱怨队友烂，条件不给力，自己的才能没法得到发挥等等，这些境遇我们都会遇见，小到一个活动的开发，大到一个公司的运转。

没有人一开始就拿着一副好牌的，没有资源就创造资源。

换位思考，自己能拿到多少支持？

活动是运营设计并执行的，用户是参与活动的。前者的方案越诱人，执行越出色，后者越愿意参与。即：运营付出精力，设计“活动规则和奖励”，通过运营，来交换用户能付出的“参与支持”。

同样的思路，你同样可以把组织当成你的用户，付出精力，通过运营，来交换组织能付出的“公共资源支持”。

此前我们很多次提到过，如果站在用户的角度，你会参与自己设计的活动么？同样，如果你是公司负责人，面对着诸多部门的需求，你会对哪些部门给予最大的支持？

这就是付出与得到之间的关系，也是商业的最基本逻辑，我们每个人都得玩好与世界交换的游戏。

举个游戏公司极其常见的场景，要在微信上设计一个9宫格的抽奖转发，注册下载游戏的活动，完成这么一个功能至少需要找到3个部门。

1、找网站部门提供静态页面开发。

2、找技术部门提供功能逻辑开发。

3、找运维部门提供服务器支持。

公共资源部门每天各种事，抽调多少人力资源帮你？

你运营的游戏并非公司王牌产品。凭什么给你资源？

这个活动做好了，能给公司和对方部门带来什么好处？

你找高层的BOSS出马说？他凭什么排优先级？

高层的BOSS出马了，如何选到最好用的人，并压榨具体执行人的工期？

写的活动开发案不到位，人家做出来后不是你想要的，如何让人家改？

假设活动假期间出了问题，希望提前结束，凭啥让对方在假期为你收拾？

很多的新公司的基础活动模板建设并不完善，甚至没有积累，越是复杂的东西越是需要人去收拾，几乎可以100%的告诉大家，这些问题和境遇我们都会面对，而且对于公共资源部门而言：

公司的公共支持部门总是都是没油水的，因此人力资源极为稀缺。

每天都有忙不完的事情，做谁的工作都是一样的，根本不关心哪个重要与否。

长期做的都是一些基础业务，有些人成长到一定地步就不愿意继续待了开发高手能实现任何东西，开发菜鸟才会说这个有点难。

高手从来都是稀缺的，会被优先分配给重点项目。

从上往下推，还是从下往上推？

很多人单纯的以为推进工作是从上而下的，但实则不然，我们想做一件事情，一定要做到为“用户”考虑问题。在解决上述问题中，我们的用户就是公共支持部门，我们先定义一下身份。

执行人——被安排的，负责处理具体业务的

负责人——执行人老大，管事的，负责分配具体工作的

BOSS——管人的，真正影响“负责人”那个人

我的工作推进策略如下：

1、通过各种方式，找到能把事做成的、靠谱的“执行人”；2、获取“执行人”最近部门内的工作强度，部门负责人的压力；3、向“执行人”确认方案可行性以及开发周期、困难度；4、找“负责人”咨询下方案可行性，试探性预约对方档期；5、找“BOSS”强调收益比，以及争取公共人力资源；6、预约一场会议，把相关人员都请到场，获得档期安排；7、事情进行中，确认“负责人”和“执行人”的精力主次分配8、事情结束后，公开和私下分别感谢“负责人”和“执行人”

整个过程中，跟BOSS诉求收益比；跟负责人、执行人诉求情感和利益分配。诉求策略、节奏有明显区别，比如第8条，除了公开外，一定要私下，“如果当初不是问你，这件事根本做不好啊，多亏了你的帮助！”。

何时旁敲侧击，何时开门见山，此间有无数的技巧、细节、话术值得细细斟酌和把控。 

在推进业务执行的过程中，从下至上（先试探请教后积极争取）绝对比从上往下（先圣旨命令后给予弹压）要好，对于负责人和执行人而言，这是两种完全不同的用户体验。把事情做砸的和做成的，都是执行人。限于篇幅原因，本章节不展开，我会在后面的章节里具体展开。

如果我们直接找BOSS，强调强调再强调，出于面子，以及你的把握，你一定可以搞定的，然后BOSS安排负责人，然后依次推进，但是我们无法预知风险，比如负责人当下的压力，优秀执行人的档期，遇见一个糟糕的，伤害得是整个业务线。

就跟我们设计活动框架一样，完成一件事情，你看到别人表面（只是看到主题、时间、规则、奖励），但是真正的决定质量的是底层，他人背后付出了多少心血，一般人是看不见的。

搞关系会来事，有多大的作用？

做运营，推进其他人协同执行是非常常见的，但工作中我们也会发现很多会来事，但是业务能力差得一塌糊涂的人。

这种人把所有的精力都用来修炼“会来事”了，而对业务能力的修炼，则停滞不前，对于此，大家要刻意避免。

举个简单的例子，怎样搞定BOSS，让他批给我们额外的资源，靠会来事么？这跟创业公司见投资人的心态差不多，说服策略是绝对的硬实力。

同理，如何搞定开发人员，他们每天都面对着会来事的人，听好话，收礼物，搞团建，然后强调自己的事情最重要，希望能给予最多的支持。这些方式人人都用，效果就不那么好了。

真正地在活动的过程中，推进得高效顺利，靠得还是硬实力。

先说讨论环节，任何活动开发的商讨会议，十个人以内的参与者，30分钟以内才是合格，业务能力越强，需要确认的东西就越少，我见过一个拥有开发经验的运营高手，开会基本就等于是在跟开发布置实现的细节，以及注意要点，这就是硬实力极强的体现。

会议上抛出能执行没有遗漏的活动方案，本身就是一件难事。要知道，在会议上被技术负责人不断挑出漏洞，然后提需求的人不断妥协，一改再改是一件很难看的事情，这样的事情多了，会对运营的能力产生不信任感。

讨论会议上说好的，跟实际的开发是两回事。前者讨论可行性，实际的开发就是无数细节的补充。

如果开发执行人因为工作忙，未跟开发负责人一起参与会议就非常糟糕，且还有可能出现开发了一半，由于各种转交给其他人员收拾的情况，更是糟上加糟。

大家都知道传话的痛苦吧，运营总得有个基础的开发文档吧，然后对方问出一堆你也听不懂的话术，所以“照着某某来，就某几个地方改一下”是运营的终极招数了。好的活动开发文档对一般运营人员而言，真挺难的，已经超出能力边界了，如果做好了，即可转岗做产品了。如果两个竞争部门的运营同时跟开发沟通，一定是文档能力更强的那一个，具备更多优势。

很多活动执行的层面，这在开始的时候就应该是想好的。

比如此前在【成本篇】里提到的，因为结算方式的不同，0点开始24点结束，12点开始次日12点结束，我们到底用哪种？就是一种提前规划好的表现。

那些曾经因为自己的设计傻，而折磨其他人被动加班的运营人员，相比换位思考，照顾好其他人的运营人员，两者拿到的口碑能一样么？

复杂活动类型的实现和运营往往调动多个部门，笔者也曾作为公共开发资源，在二线后勤配合一线运营完成活动的开发和运营，长期以来，发现有些部门的同事安排业务是如此从容，有些则是混乱不堪，设身处地的想一想，如果你是配合别人的程序、美术、测试、客服，你喜欢跟怎样的同事合作。

安排好时间，照顾好别人也是照顾好自己。安排好是能力强的体现，而不是会来事的体现。

活动运营执行层面多数是经验复盘总结得来，当感觉自己控制不住的时候，我们就得安排得足够合理，如果安排不合理，折磨跟你配合的“用户”，多会来事也不管用。要知道，但凡是公共人力资源都是被争抢的，他们每天接触“会来事”的人，这个能力真的值钱么？

不是说“会来事”这种软实力不管用，起初我们可以不会，只能靠“会来事”，但是时间长了，你会发现，拼同理心，真正站在对方角度考虑问题，拼能力，真正能够节约彼此时间，把事情安排得井井有条的人才是最受欢迎的合作对象。

我见过太多的人，每天哄着这个哄着那个，除了打杂传话，监控进度外，疏于打造自己的核心竞争力，然后蹉跎了多年，依旧停驻不前。

做运营自然是要打造多维竞争力，软实力要修炼，硬实力更是要刻苦攻坚，当软实力和硬实力都过关，我们将无往不利。

如何搞好关系，打造口碑？

很多的时候，靠得是无数的细节。很多的时候，都是比出来的。

从推进阶段，我们自下而上推进，扫除掉无数的问题，把这个事情变得只需要对方老大点个头就能执行的事。

整个过程中，不仅仅关注他人感受，跟执行者的交流过程中，无形之中自己的业务能力得到大幅提升，这将更加有利于让事情变得更加高效，自然而然就成为了受欢迎的对象。

当然这是属于顺风的时候，还有逆风的时候，我们的处理方式才是真正的影响关系深浅的核心要素。

说一件我的个人经历。

某次维护后，一部分用户活动奖励补偿未发放，造成用户投诉，后来调查事故，运营和技术均有责任，很不幸，我本人就是那个运营，因为邮件中的描述不精准，有歧义导致的操作失误。

实际的执行过程中，在技术操作发奖之前，我就发现了问题，并找到对方的老大，说这个邮件，写得可能理解有歧义，实际情况应该是怎样怎样，我询问了是否需要重新补发邮件的时候，对方的老大一摆手，说不用，我跟某某某（发奖执行人）交代一下就行。后来因为忙，他忘记了交代，执行人也发现了歧义，但是没问，按照自己的理解操作了。

如果这个事情，技术部门内互相沟通一下，就不会出问题，整个事件的过程大家都清楚明白。

按照公司的规定，此次事故罚款5000元。部门老大在内部复盘会议上，我站起来的开场白是：“我个人承担所有的罚款，事情的经过是……”我向团队里复述了所有的细节。

照理说，此事以我交罚款就结束了。我的部门老大于心不忍，私下找到对方的老大确认此事，后来对方也觉得我挺冤枉自己也有责任，主动也承担了一部分罚款。

这件事情直到后来分奖金的时候我才发现，我问怎么我的罚款额度少了，部门老大告诉了我的原委，实际的执行是，我扣掉3000，我老大扣掉1000，对方老大扣掉1000。

运营事故产生了，同样是被处罚，协同的部门可能关系越来越铁，也有可能互相积怨老死不往来。这类事情在职场上永远不会停止。

这件事情，当然也不会传多远，但相信一定传遍了整个技术部门，由此往后，我在那边提什么需求，都是无往不利。就算因为自己的愚蠢造成的对方加班，对方也心甘情愿，并安慰我说小事情不要在意，要知道，由于运营犯蠢，导致的技术部门加班，不给脸色看就是好的，内心一定会被鄙视到土里去，而其他的运营人犯错，大家都可以想象。

我不抽烟也不喝酒，团建的时候也不懂得敬酒，平常也不主动请技术吃饭，相反技术还经常请我吃饭，说是“回请”。

“回请”的由来，每次做成了事，拿到的公开表彰（每次都有钱），我都想办法给花光，其中的参与者，哪怕在这个过程中出了微末之力，我也会给予馈赠，以感谢对方的支援。

技术同学请我吃饭的理由很简单，跟其他的人共事，由于对方的安排不好，则经常是陪着加班擦屁股解决问题。跟我共事，不容易犯错，更容易拿到表彰，更重要的是：

“因为安排得好，节约了彼此的时间。”当初主动跟我承担罚款的那个老大，在饭桌上跟我说到。“而且还有今天这顿饭！”当初一起参与的活动的执行人补充到。

在跟对方交流的过程中，自己的开发知识，业务能力蹭蹭蹭涨，提出的开发需要确认的内容就越来越少，当其他的运营找技术寻求确认，技术忙的时候，面对低级问题表现出一脸的不耐烦，而我早已经不问了。

一个不抽烟不喝酒不主动请客吃饭的运营，凭借自己的专业硬实力，为自己，为部门赢得了足够好的口碑。拿着这种“随时随地为对方考虑的”工作姿态去对待所有的公共支持资源的同事，绝对是无往不利。

把事情搞成，让正确的事情相继发生，每个人都有无数的手段，不过说真的，当软实力和硬实力都同时修炼到位的时候，渐渐的，你根本不屑于用软实力了。