良心干货！彻底认识产品运营岗的工作及价值体

本文包含内容建设、需求提炼、活动组织、如何与研发建立良好合作4个部分，全面透析产品运营的日常工作及价值体现。全文较长，建议收藏起来慢慢阅读。

关于互联网产品经理的话题历来火爆，产品运营就冷清得多。

产品运营入行门槛通常不高，工作内容又看似琐碎繁杂，面面俱到，易做难精。有这么几种观点：运营就是“做客服的”、“删帖子的”、“论坛版主”、“搬运工”、“保洁员”、“网络运维（完全是两个工种好么！）”……甚至很多从事运营的人自己也说不清楚，只能自嘲“打杂儿的”。

从职位名称到工作内容，产品运营都没有“产品经理”听起来那么“高端大气上档次”，一直缺乏清晰明确的定义跟标准，发展方向就更不明朗啦。我不止一次听到有人抱怨：“运营好没劲，我要改行做产品！”活儿多钱少没发展，产品运营到底是怎样的工作？它的价值究竟体现在哪里？我根据几年来从事社区产品运营工作的经验，尝试做个回答。

首先，什么是产品运营？个人观点，产品运营就是吸引用户使用产品并促使用户持续产出符合产品定位和发展目标的行为和内容、充分挖掘和发挥产品核心价值的一系列运作。例如对于社区产品来说，一定数量的人群在某种形式的网络空间内持续产生互动和内容，就形成了社区，社区运营就是吸引用户加入社区并促使社区用户持续产出符合社区定位和发展目标的互动和内容、充分挖掘和发挥社区价值的一系列运作。

其次，产品运营的工作具体有哪些？在我看来可以分为内容建设、市场推广、活动策划、用户维系、数据分析、规则维护、竞品调研、需求提炼8项，但它们在产品不同的发展阶段所占的比重是不同的；针对不同的产品类型，不同的用户群体侧重也不同。如新产品上线推广阶段，内容建设和市场推广是重点，产品进入稳定发展阶段，用户维系和规则维护的比重将逐渐增大；对BBS来说用户维系是一项主要工作，对于资源下载产品就要更注重内容建设和规则维护，面向学生群体和面向CTO群体的社区产品，运营重点也各自不同。

一、内容建设

1、标准建立：产品的价值观，由其承载的内容体现。

什么样的内容是合适的，希望产生的，什么样的内容是不合适的，应该排斥的，在产品上线伊始甚至产品策划阶段，就应该达成共识，并制定相应的标准，它将是运营人员未来开展工作的重要依据，并会通过产品运营传达给用户，并随着产品运营不断深入而日益清晰完善。

这也是我主张运营人员应该在产品策划阶段就加入产品团队的原因之一，运营人员只有深入了解产品的来龙去脉，充分认同产品体现的价值，才能正确地建立和把握标准并在运营工作中灵活地实施，否则只能做一个机械的“裁判员”。

2.内容初始化：运用技术或人工手段填充一批符合标准的内容作为产品冷启动的基础。

没内容的产品是个空壳儿，不利于产品推广，用户来了也会不知所措。通过内容初始化，吸引用户访问，快速树立示范，便于市场推广，渲染产品氛围，典型的例子：建立一个论坛，需要划分版块对内容主题进行细分；论坛开设新版，需要提前填充一些版面主题相关帖子；资源分享站点开张，也必须事先准备好一批种子资源。初始化内容越丰富，展现形式越生动，对新用户的吸引力越大，可不是简单堆砌一些干巴巴的说明文档就可以的。

3.内容审核：内容有了，用户多了，垃圾广告也就跟着来了。

运营人员需要定期检查并剔除垃圾广告内容，否则它们会充斥网站，严重影响用户浏览访问；如果出现违反国家法律法规、或者侵犯他人正当权益的内容，还可能导致网站发生安全问题无法正常运营。一部分审核工作可以通过技术手段自动完成，但仍然有一些需要人工维护，如敏感词库更新、网站安全监控以及推动审核系统持续升级以应对不断出现的垃圾广告新形式。

4.内容推荐：这里专指在产品内部进行的推荐（在产品外部其他网站上推荐属于市场推广范畴，下文详细介绍），它是非常重要的一项常规运营工作，既能够突出体现产品价值观，又能够鼓励贡献优质内容的用户。

做好内容推荐并不简单：首先运营人员一定得对内容标准把握到位，其次要具备一双能够在海量内容中及时发现优质内容和活跃用户的“慧眼”，还需要有一定的编辑能力，可以对原始内容进行适当的编辑加工使其更利于传播，而且要对产品各个推荐位置和推荐效果了如指掌。

这就要求运营人员熟悉产品，对各种显性隐性信息敏感（足够八卦！），了解社区文化和当下时事热点，能够以用户喜闻乐见的方式进行表达，了解产品数据，知道什么推荐位效果好，什么位置适合开发成推荐位。

简直跟做编辑的要求差不多了有木有？！但与传统编辑不同的是：评估编辑的工作可以直观地通过内容浏览量和传播量，而这两个指标对于运营人员的内容推荐工作并不足以衡量其价值。运营的内容推荐目的在于普及倡导产品价值观，引导用户产出更多符合产品价值观的内容，鼓励产生优质内容的用户，挖掘具备成长潜力的用户，这个效果不是一朝一夕就能够看得出来的，需要达到一定时间的积累方可，因此对运营人员的相关考核也需要综合评估，不能单纯只看某几个数据，做运营的同学本身也需要能“耐得住寂寞”啊。

5.内容整合：产品稳定运营一段时间，有了稳定增长的用户群体，积累了一定数量的优质内容，为了集中充分展示优质内容，更好地打造产品口碑，促进产品价值传播，就需要开展内容整合工作了。

主要有两种方式：

● 一种是给用户提供自主内容整合的工具，运营人员负责质量把关。比如CSDN博客的博客专栏，用户可以自主申请建立自己的博客专栏，收录自己博文中成系列的精华博文，由运营人员遵循一定的标准对专栏申请进行审批，确保专栏的质量和有效性。

● 另一种是由运营人员将已有的优质内容根据不同领域、不同主题进行编辑整理，加工成内容专题形式。如每周博客精华周刊、每周论坛热点回顾、每月下载资源top100、版块精华问题集合等。这是非常受用户欢迎的一种形式，对运营人员的内容编辑能力要求也更高，也可以在活跃用户群体中邀请用户参与编辑工作，但最终的质量把控还是要运营人员来负责的。

6.开发商业价值：做产品，有了人气卖广告，谁不会？还需要开发神马商业价值哇？

你能够做到不让过多的广告干扰用户体验吗？

你能够做到根据产品形式和内容匹配合适的广告吗？

你能够做到根据产品特点和用户人群策划商务项目吗？

你足够了解你的产品和用户吗？

互联网产品简单地卖卖广告就能赚得盆满钵满的时期已经过去了，客户买的其实是产品提供的服务，客户看中的是使用产品的用户群体所能带来的购买力和口碑。而运营人员恰恰对产品能提供的服务和用户群体是最为了解的，产品承载的内容本身就具有潜在商务价值，如资源付费下载、在线付费咨询、精华内容出版等等，各种商务项目的实施最终也是以各种产品内容形式来体现。辣么，在产品商业价值开发中，如何充分发挥运营的价值呢？这个问题，可不仅仅是有志于产品运营的同学应该思考啊。

二、需求提炼

提产品需求是运营同学的日常工作之一，看似简单，其实并不容易。

什么是产品需求呢？产品需求就是对达到某个既定目标需要实现的产品功能和特性的描述，可以从以下几个维度来划分：

1.外部需求和内部需求

前者来自各个渠道收集的用户反馈，如微博微信qq群客服邮箱客服电话，以及产品自身的反馈渠道（如论坛的客服专区、在线即时咨询窗口等）；后者来自公司内部，如老板和其他部门的反馈。这些反馈通常都不会很明确，需要运营同学进行整理挖掘，沟通调研进而提炼出需求。如果不经整理提炼就统统丢给研发同学去处理的话——会被鄙（qia）视（si）的……

2.改进型需求和新建型需求

它们俩是从1到10和从0到1的区别。我个人的建议是已有的产品如果改进优化后能用，尽量不要另起炉灶，除非是原有的产品从定位到风格全都跟新需求不一致。这就要求运营对现有产品定位跟功能了如指掌，能够根据需求制定出合理的问题解决方案，有时甚至可以不需要产品改动就达到目的。这样不是效率很高吗~

最怕的是拍脑袋就做个产品，不考虑是否能利用已有的，导致留下一堆半截子工程，说能用也凑合能用，彼此间定位不清晰，后期运营推广也不好做；同时系统里很多冗余代码难以维护，如果负责人一离职就再也没人能说清这产品的来龙去脉，于是又推倒重来一遍……对人力物力的极大浪费啊。

3.笼统型需求和精确型需求

前者如“现在这个编辑器太难用了换一个吧，好多代码格式都不支持”，后者如“需要一个除现在支持的代码格式外，还能够支持markdown语法的编辑器”。很多用户反馈的需求就是前者那样的，必须深入了解分析，否则过于笼统不具体的需求，是无法实现的，即使勉强上马，也一定会因为需求不明确而导致工期延误和反复修改，最终应付了事，所有参与人忙得够呛都不开心，宁可早期多用一些时间把需求搞清楚。

4.解决问题的需求和提高效率的需求

“我需要一个能给用户群发邮件的后台”和“我需要能够自己导出符合某些特征的用户邮箱列表给他们群发邮件”。不过后者需要评估使用频度，如果是高频使用需求，开发一个还是有必要的，否则每次都要找研发同学给导出邮箱也确实麻烦；如果是为了某个临时性的项目用，或者一年也用不了几次的低频需求，那就没必要开发一个专门的功能了。

为什么要从这些维度来划分呢，因为实现产品需求的资源通常是有限的，因此必须对需求的合理性和优先级做出明确判断，并以此来决定开发的资源投入以及排期先后。

另外有些似是而非的“产品需求”，实际上是bug，bug和产品需求的区别及处理方式的不同如下：

产品需求：

● 针对还不存在的功能提的

● 解决的是“不好用”的问题

● 实现周期通常较长

● 发给产品经理处理（这个要看具体团队构成和分工，是否有专门的产品经理来处理需求，如果运营兼负责产品那就由提出需求的同学自己处理了）

产品bug：

● 针对已经存在的功能提的

● 解决的是“不能用”的问题

● 解决时间视bug严重程度，通常要求尽可能快地处理

● 可直接发给研发人员解决

提需求和提bug的流程

产品需求描述

产品经理通常需要把收到的各路需求整理成产品原型文档，但对于运营同学来说并没有那么严格的文档要求，只要让产品同学能够明白你的意思就可以；不过为了提高沟通的效率，有必要参照一定的格式来描述你的需求，这里举个我现在团队的例子：

1.需求名称：产品名称+功能+提出时间，如“CocoaChina编辑后台改进产品需求-2015-8-17”

2.目的：有助于产品同学充分理解你的需求的必要性和重要程度，如“为了提高编辑发稿的工作效率”或“为了统一网站整体风格而进行UI重新设计”。

3.优先级和时间要求：这个也很重要，因为产品经理通常会收到大量的需求，如何安排优先级处理顺序？如果你在需求里有明确的说明，那么处理效率会高一些。如“第一优先级，需要六月15日前完成”。

4.需求描述：说明用户身份（外部用户和内部用户的处理方式有区别），页面需要包含哪些元素，期待的布局和风格，排列顺序，是否必选项，有何特殊要求，是否需要查询及查询条件设定，是否需要权限管理等信息，尽可能详细，最好给出参考案例或类似竞品截图。

什么情况下需要提产品需求

如果以上你都已经烂熟于心，对于如何提产品需求应该是没有问题了。但是且慢，知道怎么做只是最基础的，对于合格的运营来说，更重要的是判断要做什么和不做什么。

用户的需求永无止境，运营不能只是需求的传声筒，需要深入分析用户需求背后的目的和隐藏的问题，如果能够用已有的产品达到的，就尽量不要重复建设做新产品；如果能用运营的手法解决的，更不必耗时费力地动用产品和研发；如果能够利用已有成熟的渠道跟平台借势推广的，又何苦非要做一个“自己的”独立平台一切从零开始呢？做加法永远比做减法容易，另起炉灶似乎也比在原有基础上修补改进要痛快，但是资源永远都有限，无论是人力还是时间，即使你有一组强悍的产品和研发同学24小时无条件配合，仍然要评估需求真实的价值有多少，衡量投入产出比。运营的强项在于给你一个产品，你能够发掘它的一千零一种用法（玩法）并将其传递给用户来满足不同的需求，如果一接到新需求就要做个新产品，而不是先看看运用已有的产品是否能够解决问题，运营自身的价值何在呢？

案例一：数据分析后台

曾经有同事负责运营一个垂直专业领域的群组，提出要做一个数据分析后台，能够根据加入群组用户填写的个人信息自动生成各种维度的分析图表，“就像专业的数据分析报告那样”，他说。这并不是一个实现起来很简单的需求，虽然对用户的数据分析是有必要做的。但是该群组目前的注册用户只有几千人，且新用户增加速度非常缓慢，用户数据分析的时效性并不是非常高，因此最终解决方案是导出用户数据到excel中，运营自己根据统计需求，利用excel生成分析图表，至于是否像专业报告，那就看自己的excel造诣啦~如果未来用户量和增长速度达到一定规模，人工统计无法满足，才是需要开发数据统计后台的时候。

案例二：大会报名app

我所在的社区运营团队曾经负责组织公司的开发者大会报名，通过社区各个渠道向开发者用户进行宣传，使用的是社区的活动报名系统，可以汇聚各个渠道的报名数据到后台数据库。有同事提议说开发一个大会报名app，以后组织大会都可以让用户通过app报名，这样推广时只要通过app推送提醒就可以啦~~~我说你这个创意不错，你先想法让用户都装上这个app，然后。。就没有然后了。。

总之接到需求后，问自己以下几个问题：

● 目标足够明确吗？

● 已有的产品确实无法满足工作要求吗？

● 已有产品的缺陷已经极其影响工作效率吗？

● 成本是否合适？

● 如果答案是否定的，那就需要重新审视这个需求的合理性，并且和需求方积极沟通确定最终解决方案。

如何促使需求尽快实现

● 需求表述明确，沟通清楚，提交流程规范：该自己做的一定要做到位

● 按流程提交需求后最好再当面跟产品经理沟通，尽快落实需求并启动

● 必要时要舍得砍需求，确保快速上线

● 充分利用各项资源来达到目标：平时和产品设计研发同学搞好关系，必要时通过上级推动都是方法

几点总结

● 产品改进通常要落后于业务需求

● 互联网产品改进伴随整个产品的生命周期，不是一次性的

● 产品改进是由运营驱动的

● 再好的产品，运营跟不上也是白费

● 对内容运营和社区运营来说，产品是辅助手段，不是目标

● 了解产品的互联网编辑/运营会有更多的职业发展机会

三、活动组织

凡是做运营的小伙伴，没有没组织过活动的吧？做活动能够提升产品的口碑影响力，扩大用户覆盖面，提升用户活跃度，提高产品销售额……实在是居家旅行必备技能点啊。关于“如何组织一场成功的活动”，网上已经有了为数众多的经验分享，本文结合我之前负责执行过的一个活动案例加以分析解读，希望能对您有一些帮助和启发。

1.活动KPI的制定：

2010年上海盛大公司推出了一款名为Bambook的电子阅读器，提供应用开放平台，开发者可以向平台提交应用程序，以便用户下载安装新的应用，扩展Bambook的功能。为了推动广大开发者为Bambook开发优质应用，提升Bambook产品的用户体验和人气，同年11月，盛大举办了Bambook程序达人赛（以下简称Bambook大赛）。

了解活动的背景和目的才能确定活动KPI，活动一定要有一个明确的KPI，这样活动策划和活动执行才能有的放矢，活动最终的效果才有衡量依据。KPI可以根据著名的SMART原则来设定，例如这个活动的KPI就是”在大赛作品提交截止日之前通过审核的应用提交数量要达到若干个”。

2.四“W”一“H”：

确定了活动KPI后，就是如下五个问题：需要谁(who)来参加活动？到哪儿(where)去找这些人？为达成KPI需要什么(what)资源？活动为期多长时间(when)？活动如何运营(how)？

比如这个大赛，就是需要找到足够多的开发者来参加活动开发提交应用，大赛是纯线上的形式进行，线上开发者最集中的地方就是各大IT社区（2010年微信微博等社交平台还未兴起，厂商缺乏有力的开发者聚集和推广渠道），盛大自家有IT社区吗？没有，所以直接找大型IT社区来承办大赛是最省力的方式，需要给社区一笔承办费；大赛的奖励也得足够吸引开发者；开发Bambook应用需要特定的工具包和调试环境，因此盛大除了提供工具包和模拟器之外，还提供了一批全新Bambook机器给开发者用于程序开发和调试；此外还要有媒体不断发布新闻配合活动造势；这些都是达成KPI需要的资源。

以上是一个比较典型的线上活动的情况，线下活动还可能增加场租、场地布置、物料、人工等费用。大赛的前期宣传、创意策划、开发调试并提交作品、评奖这些关键环节都需要时间但长短不一，需要提前预估并打出一定的富余以防备突发情况，另外还要考虑是否活动期间有春节国庆等大型节假日，影响开发者参与，这个活动从启动到结束原定是3个半月，后来因春节延期了一个月，总共是4个半月。

4个W都确定了，活动就妥妥儿的了？当然不是，下面着重分享一下“how”。

4.活动如何运营：

CSDN和ITeye（原名JavaEye，2010年被CSDN收购）、InfoQ、51CTO、博客园等国内几大著名IT技术社区都参与了Bambook大赛，当时我在CSDN刚从教育事业部转岗到社区运营部，负责ITeye网站的整体运营。Bambook大赛在ITeye的组织我是全程亲手策划运营的，所以现在还是记忆犹新。

这个项目本来照例是由公司商务部门的执行团队负责在两个社区开展的，我作为社区运营起初并没有参与。但大赛已经开始一个月了，ITeye的会员仅有不到30个人报名，报名的人里没有一个人提交作品！而同期其它社区都已经有不少作品成功提交了，这样下去ITeye社区的参赛结果一定是惨不忍睹的。我在这个时候（12月7日）紧急接手了该项目，颇有点临危受命的性质。

分析之前的活动组织情况，我发现存在以下三个问题：

第一、社区推广力度明显不够。之前的推广就两处：

1.ITeye首页放了一个广告图片，链接到一个大赛专题，这个专题还是个静态页面，包含内容有限，大赛的最新动态也无法及时更新，就算会员有心参赛，点过去也了解不到详尽的信息，很可能就放弃了；

2.开了一个Bambook主题的专栏，用于转载主办方盛大定期提供的大赛资讯，但专栏的访问量在ITeye所有频道中是较低的，日PV只有几千，仅在这里推广是肯定不会有良好效果的。

除此之外再没做过别的推广了。

第二、宣传语太平淡，不能有效激励用户参与。例如首页的广告图文案就是“Bambook程序达人赛”，社区里不是只有这一个大赛，而是经常发布各个厂商组织的各种类型的活动，可以说大家争夺的是同一批开发者的注意力，如果宣传时没有能够打动用户的亮点，如何吸引眼球？

第三、没有体现社区对参赛会员的支持。Bambook大赛同时在各大技术社区开展，开发者在报名时就需要填写通过某某技术社区报名，社区本身也会根据大赛的组织情况和社区会员的参赛情况参与评奖。显而易见，哪个社区能够给予自己的会员更强大的支持，会员就更愿意通过哪个社区报名。否则可能本来是你社区的会员，但是跑到别的社区渠道去报名了……

针对以上问题，我结合ITeye的社区特点制定了大赛运营方案，主要注重三个方面：

一、大力增强大赛推广力度，主要有3点：

1.建立社区自己的大赛推广专题页面：要求有比较大的影响覆盖面，推广位置要固定，大赛动态更新要及时，所有在ITeye站内做的推广内容要统一汇总到该页面，方便感兴趣的会员随时了解信息，促进报名。

我是这样实现的：参考大赛官网，选择最有可能吸引用户的内容（奖项设置、赛程、参赛必要的SDK下载地址、模拟器、已提交的作品案例等）加工撰写了一篇新闻稿——《Bambook程序达人赛——为荣誉而战！》，当作大赛在ITeye的专题页面，大赛期间始终在资讯频道保持置顶推荐。后来我陆续又在资讯频道发布了十多篇报道大赛最新动态的资讯，有我原创的，也有转载盛大提供的内容，所有发布的内容链接，都及时汇总到这篇置顶新闻稿中。原来的那个静态的大赛专题页面放弃使用。

这样做的好处是更新最新动态非常方便灵活，因为新闻稿可以随时修改。而且资讯频道已经是一个具备相当访问量的频道，日PV接近五万，还有很多用户通过RSS方式订阅，覆盖面比较广，是单独的静态专题页面无法相比的。

2.联系社区已经参赛的会员做访谈：树立榜样产生带头示范效应。

大赛期间我共采访了两位参赛会员：

其一是ITeye第一位提交作品的会员，虽然他的作品并不很出众，但毕竟这是一个“零”的突破，我希望能尽量给想参赛的会员一些帮助和提醒，激励更多的人来报名。我把和那位会员的QQ聊天记录整理成了一篇访谈——《Bambook大赛系列报道之二：参赛选手专访》，发布到了资讯频道并在社区各处推荐。访谈中着重强调了两点：要在大赛中获得好的成绩，有哪些方面是参赛者应该格外重视和加强的？比较受欢迎的作品共性是什么？

其二是大赛后期的时候，我发现ITeye会员“拯救与逍遥”的作品“涨停大师”仅上线两天就已经获得了不错的反响，便立即着手联系他做访谈。1月4日，我发布了《Bambook大赛系列报道之十三：参赛选手“拯救与逍遥”专访》。“拯救与逍遥”是ITeye的老会员了，他和参赛伙伴就是看到置顶那篇“为荣誉而战”的资讯才开始参赛的，和他沟通过程中，我真切感受到了ITeye会员对社区的感情和支持。

访谈的好处一是能帮助参赛会员进行宣传，二是访谈形式可以充分体现参赛者的心得体会，能够激励更多的会员参赛，同时我及时把社区的大赛相关原创资讯反馈给盛大，这正是社区宣传组织工作及其有力的证明。这两篇访谈我都同时在CSDN的资讯频道进行了推荐，以充分利用CSDN的强大宣传渠道。

3.利用站内短信进行推广。ITeye的站短是一个非常好的社区推广渠道，它可以精准地发送内容给某个时间段内的活跃用户，且用户阅读率很高。但使用站短要非常谨慎，要防止过度打扰会员引起反感。一个活动中在某几个重要的关键时机定向发送站短是很有效的一种社区推广手段。

我当时是选择了申请Bambook开发机的时机发送了一批站短。大赛主办方为参赛者提供了一批Bambook作为开发机，但数量有限，需要报名参赛者提交作品创意并通过主办方审核，才能发放开发机。这个当然是利好，我就利用了站短给最近一个月内有过登录行为的会员发送了宣传信，告知此事并邀请他们踊跃提交作品创意来争取成功申请到开发机参赛。

推广方案第二个方面——强调宣传关键词：

我在推广中刻意突出一个关键词“为荣誉而战”，目的是希望通过一系列的社区宣传，不仅推动会员积极报名，更能够让会员认为，这件事的结果好坏，关系到ITeye这个社区的荣誉！ITeye历年积累了那么多优质的社区会员，很多会员对ITeye的感情也很深厚，我要做的只是扩大影响面，调动大家的参赛积极性。

结果证明这起到了一定的作用，如上面访谈的那位会员“拯救与逍遥”和他的参赛伙伴，他们起初并没有注意到这个大赛，就是看到“为荣誉而战”的宣传之后才参赛的。

推广方案第三个方面——充分体现ITeye社区对会员的支持：

这里我主要做了5件事：

1.在各个渠道不断通知会员：凡通过ITeye报名参赛的社区会员（以最终提交作品为准），赠送半年程序员杂志，而且ITeye将集合社区资源帮助参赛者推广其作品。因为当时除了CSDN和ITeye，还有其他很多技术社区也在组织会员参赛，ITeye和CSDN的社区影响力和推广渠道当然最大，那为什么不拿出资源大力支持和激励自己的社区会员呢。

2.为ITeye参赛会员开通了申请开发机的“社区绿色通道”。只要报名会员通过社区提交了作品信息，我就马上提交给盛大尽快审核，通过审核就发放BamBook开发机。这样的效率比提交到官网审核要快得多。

3.给已经报名但尚未提交作品创意的ITeye会员发邮件，收集他们的信息，并告知他们社区的支持，督促他们尽快提交作品创意。

4.好消息及时通报。如我撰写的资讯《Bambook大赛系列报道之十：五位JavaEye会员已获得开发机》，大力宣传这个好消息，通知获得开发机的会员尽快上传作品，同时激励其他会员积极提交申请。

5.帮助ITeye会员拉票，宣传他们的作品。春节后，作品提交截止了。大赛进入了投票评选阶段，在初选阶段和第二评选阶段，我分别为所有提交作品的ITeye会员和成功入围大奖角逐的ITeye会员在社区进行宣传，组织广大会员为他们投票。详见《Bambook大赛系列报道之十六：JavaEye参赛会员作品展示》和《Bambook大赛JavaEye最终入围会员作品展示，欢迎投票！》，以及最后的《Bambook大赛JavaEye会员有望获得终极大奖为他加油！》。

经过以上一系列的运营推动，效果如何呢？

12月7日之前大赛开始一个月内，ITeye仅有29人报名，0人提交作品。

12月7日我接手，开展了如上所述的一系列推广工作，逐渐地，效果开始显现了。

12月15日，有64位会员报名参赛，1人提交作品；

12月21日，共有12位会员提交了作品创意；

9天后，12月30日，ITeye共有108位会员报名，5位会员已成功获得了开发机，并已提交了5件作品；

Bambook大赛结束时，ITeye会员共有108人报名，18人提交作品，2人入围决赛，2人获奖；

其中一人获得了媒体关注奖，奖金5万元；

另一人获得了本次大赛的冠军，赢得终极大奖10万元！

他们分别是一位2003年加入的资深会员和一位2010年加入的新会员，他们都选择通过ITeye社区参赛。

ITeye社区也因在用户中的优秀反响荣获最受用户欢迎社区奖，奖金5万元。

整个大赛的组织历经三个月，我当时刚开始独自负责ITeye社区运营，推广大赛同时我还要负责资讯频道的日常内容编辑、ITeye网站的内容审核和客服工作，回想起来那真是一段忙碌充实而又充满激情的日子。通过这次大赛的实践，我总结出了以下几点社区活动运营经验：

1、活动进行宣传时切忌面面俱到，只要突出最有可能吸引用户的某几点即可。拿这个例子来说，如大赛奖项设置（这通常是大家最为关心的）、参赛规则、赛程、注意事项、已提交作品案例这些对想参赛的用户是非常关键的，像大赛评委、比赛背景介绍等较为泛泛的内容略带过即可。

2、掌控好宣传节奏。大力宣传不等于每天狂轰滥炸个没完，否则很可能引起用户反感。在大赛的几个关键时间点，比如出现第一个提交作品的会员、某个时间某个会员的作品非常受关注、大赛即将截止报名阶段、大赛拉票阶段，这几个点要着重密集宣传。其他时间段，维持一个大赛动态的定期更新即可。

3、注意细节。把所有大赛资讯按发布顺序编号，做成系列报道的形式，会显得宣传组织工作很有条理，一目了然。

4、要及时反馈沟通推广成绩。我每周准时提交资讯浏览数据及评论数据作为推广结果给商务同事，如果社区有最新动态，如我做的专访和投票等活动，都及时与商务部沟通，让他们作为社区成绩反馈给盛大。商务同事对这个活动在ITeye社区推广的反馈也很不错。

5、各种宣传渠道要灵活使用，不要单一只用某一种，“组合拳”效果最好。前提是社区运营者要对社区的各个产品了如指掌，要非常熟悉各种社区推广渠道，能够根据不同的宣传需求灵活在相应的产品使用适合的渠道进行宣传，尽量以用户最容易接受的形式进行宣传。这个大赛中，我运用了资讯频道和专栏产品作为推广阵地；通过站短，客服邮箱，首页广告图、各频道置顶公告等渠道进行推广。推广的时机和频率都是精心考虑的。

6、最简单的产品形式也能达到运营目的。心中有剑，一切皆可为剑。做一个活动，不一定非要动用设计研发来制作一个庞大的专题，最基本的资讯、博客、论坛帖子，只要用得好，内容组织到位，都可以达到良好的效果，同时耗费的资源也少。

7、要达到良好的社区推广效果，社区运营人员最好是“多面手”。不仅要了解社区用户，了解社区产品，了解各种推广渠道，更需要具备一定的编辑能力，采访能力，活动策划能力，项目流程把控能力，对沟通能力也要有一定要求。有人说这些完全可以通过具体分工来组织相应的专业人员协作完成，当然是的；但很多时候，尤其在资源紧张，时间有限的情况下，运营人员自己需要承担所有的流程分工，而且，多了解其他方面的专业知识，也有助于社区运营人员与其他岗位的同事高效沟通和良好配合。

四、如何与研发建立良好的合作

一直以来，大家都很强调产品和研发之间的沟通合作，但随着互联网产品逐渐发展成熟，运营的职能和重要性相比以往愈来愈凸显，尤其在产品进入相对稳定发展阶段由运营主导的时候，以及初创公司团队由于人手有限运营可能要身兼数职的时候，运营与团队其他成员尤其是研发（其实也包括设计）是否能够建立良好的合作就显得尤为关键了。

1、运营和研发建立良好合作的重要性：

通常一个互联网项目团队包括如下几个职能的人员（排名不分先后，且根据具体情况和不同时期人员配置会有增减）：产品、设计、研发、测试、运维、运营、市场、商务，其中的产品主要起到业务需求方（运营/市场/商务）和技术研发之间的桥梁纽带的作用，那么运营作为典型的业务需求方，只要把需求跟产品沟通清楚就好了，为什么还要和研发建立良好的合作呢？

第一、很多时候，运营要承担一部分产品的工作，必须和研发打交道

产品都是有生命周期的，一般来说，产品从无到有的孵化阶段是以产品人员和研发人员为主导，确保产品按需完成，如期上线；当产品上线后进入相对稳定的上升发展期时，运营逐渐成为主导角色，收集提炼出大量来自用户的，和运营过程中调研挖掘的产品需求，推动产品不断迭代优化。

而且很多公司里，产品和研发资源并不是完全从属于某一个产品线，这个产品上线稳定一段时间后，可能就会调去参与其它项目，不会有很多精力能够投入该产品的持续优化了。这个时候运营就必须责无旁贷地承担起一部分产品的工作，要和研发同学直接打交道。

第二、运营是最终担业绩的人，但无法独立完成业绩，需要其它职能的配合

在几乎所有的互联网产品中，运营都是最终承担KPI的人，而且运营的工作相对容易量化，可以各种数据指标的变化来衡量。

但互联网产品数据的提升，是不能仅靠运营单方面来达成的，一定是各个职能多方面通力合作的结果：产品界面不友好，运营拉来用户也留不住；系统性能不稳定，经常闪退或者报错，运营每天处理用户吐槽和救火就疲于奔命了，哪里还有精力去完成业绩。

可是往往运营又并不具备能够充分调动产品和研发资源的权限，如果自己团队有配备专属的产品研发还好，否则只能是多方面寻求资源协作，能否与研发建立良好的合作关系就尤为重要了。

第三、靠谱的研发能避免很多不必要的资源浪费

见识过不靠谱的研发，你就知道能有靠谱的研发是多么幸福的事情。

靠谱的研发，

不会拍着胸脯说这东西简单得很两天就上线，但是一旦承诺了排期就不会拖延；

靠谱的研发，

会保证产品开发质量，提交测试基本就是没有bug；

靠谱的研发，

不会想方设法推卸责任，很多拖了很久悬而未决的问题，到他手里研究一番就可以得到完美的解决；

靠谱的研发，

能结合运营的需求，做出方便又好用的后台，大大提升运营工作效率；

跟靠谱研发合作，运营不需要无休止地重复测试，提交bug；不需要没完没了地开需求沟通会，天天追着问进度；不需要担心某个需求无法实现，从而无法开展新业务。你说如果你是运营，是不是一定要努力找出那些靠谱的研发小伙伴组队啊？

2、运营如何和研发建立良好的合作：

第一、谨慎处理需求，不要让研发白做工

通常技术都是业务的支持部门，技术要为业务服务，运营会结合业务发展不断提出需求改进产品是很正常的，但提需求绝不是随意的和漫无边际的。

一定是：

经过充分的论证调研——

现有产品确实无法满足业务发展——

研发成本不会超出现有资源范围——

才靠谱。

心血来潮、拍脑袋就上、不顾实际资源情况就开干的项目多半最后都是惨淡收场，参与人员付出的时间和精力也就白搭了。

研发最怕什么？最怕辛辛苦苦加班加点做出来的产品，最后没人用啊！等于研发这段工作的价值没有得到承认。

你如果说我不在乎，反正做什么不是做，每周都要写工作周报哦，我是研发只管实现你的需求就好了，做完了有没有用那是你们业务部门的事情跟我没关系。这样想的研发也就是混日子的心态，最后业务没发展、公司没发展难道研发日子就会好过吗？

真的有想法有上进心的研发绝不会这样想的，一定是希望自己开发的产品真的能够得到实际的应用，对公司的业务能够起到很好的支撑，进而自己的价值也得到了体现。

我曾经亲眼见过真实的案例：

业务方迫切地要做一个新产品，理由是旧有的产品不适应客户的需求了，必须要有新的产品来承载客户需求的变化，而且给出了要实现的时间点（还比较紧迫）。

当时技术部门派出了最精英的程序员来负责这个产品的开发，产品如期做完了，结果业务方的反馈是：这不是他们要的东西……

后来我自己负责的项目运营中应用过该产品，觉得还是比较好用的，为什么业务方会否定它我个人不得而知，也许公司战略、需求变更、客户变化种种都是可能的原因，但最后的结果是这个程序员被这个项目伤了心，不久离职了。

还有更极端的案例：业务方把业务未完成的原因归结于产品研发不给力，不能对客户的需求做到 7*24 小时响应，百分百解决，客户投诉也让研发来背锅，也许研发可能是存在一些问题，但是这样的合作方式只能是双输，业务完成了吗？也并没有。

所以说运营在处理需求时是一定要谨慎的，关于如何提炼产品需求，我以后会专门发文陈述我的观点。

第二、充分说明需求，调动研发的积极性

上文说过，靠谱的研发，有想法有上进心的研发，一定不是机械地只管接活干活的人。

他们对业务也有自己的理解和想法，有时甚至能从别的角度给出更好的解决方案，前提是要让他们充分了解这个需求的来龙去脉，这个需求的背景，不仅仅是知道我们要做什么事，更重要的是我们为什么要做这个事：现在的这个产品需求是我运营经过调研分析确定的，我的解释是否能让你足够清楚明白了？然后从研发的角度，请你看看是不是有其他的隐藏问题？你有没有更好的解决方案？我们一起再探讨。

最后达成共识确定的需求，并不是运营单方面「压下来」的需求，而是经过业务方和研发讨论后共同认可的需求，研发也充分认识到了这个需求的价值和意义，你说他不会积极主动地完成吗？一定会的。

而且事先双方确认了需求和排期，后期的责任也非常明确，即使又有了临时紧急的需求变更（有时不可避免），也会更容易沟通。

相反，如果运营只是说我要做某个东西，告诉研发我要这样这样实现，你不要管为什么总之你必须给我做了，还得在指定时间点完成，否则到时影响业绩责任在你……这样研发就成了被动接工单的角色，如何规避风险避免担责任是他们要考虑的首要问题。

这过程中各种扯皮推卸互撕都有可能出现，程度轻重取决于工程大小和工期长短。如果遇到在公司里地位相对强硬的研发，还可能出现项目进度推迟甚至根本无法推进的情况。姑且不论责任究竟出在哪一方，宝贵的时间就这么耗过去了，错过了多少好业务。最后谁获利了？都没有啊。

第三、掌握沟通技巧，研发最怕频繁打扰

运营的工作广泛而又琐碎，很多时候要求「多线程任务并行」，经常要和各种用户打交道，因此运营的思维是比较发散的，需要具备相当的灵活性，这是运营工作的特点决定的。

研发则是逻辑性非常强的工作，要求考虑完整周密，天天跟机器打交道，非1即0，非正即负，没有模糊的中间状态可言。

写代码按照一定的逻辑顺序来，据说有人写代码激情迸发，写到high了物我两忘，完全沉浸在代码的世界里也是有的。

如果，隔个几分钟就打扰他一下，改个这里，修个那里，问个问题……研发的思路就中断了，这些单线程的同学们多半会抓狂。

所以我们必须利用工具来管理需求。把所有产生的需求统一放到项目管理工具中，如JIRA就是一种很常用的工具，汇总一批需求定期（这个时间间隔可以和研发事先沟通好，比如每周一次）和研发沟通，确定优先级和排期。

如果是紧急的需求，或者重大的bug出现（比如用户无法登录了），这种可以随时找研发处理，但是尽量不要零敲碎打地报需求，尤其是不要用即时沟通的方式，比如qq，电话给研发报需求，容易遗漏，不好统计和反馈，而且也给研发造成打扰。

第四、最好懂点技术，方便跟研发沟通

看到这里你可能会说：运营要懂技术还要研发干什么？这个当然不一样。

这里指的懂技术不是说运营要会亲手写代码，而是说对技术的一些基本概念，名词，表现形式和行业趋势有点了解是很有好处的。

研发是专业性较强的工作，在和研发沟通产品需求和进度的时候，多少要涉及一些技术相关的问题，如果遇到善于沟通又懂些业务的研发，他能尽量用非技术人员能够理解的方式跟你沟通，但这类人真心不多，能做到的基本都是技术管理层了。有些人还有一种研发范儿的傲娇，哎你们运营连这都不懂……

从我个人经验看来，如果有产品人员在，那么运营基本不用懂技术，只要把业务需求跟产品理清楚，就让产品去跟研发沟通好了；但是在缺乏产品资源，或者要直接和研发合作的场景，以及运营做到一定年限和职位的时候，懂一些技术的运营跟研发沟通会更有优势。

表现在沟通更加顺畅，省去了很多专业方面的铺垫，提需求时能够从研发角度进行一定的考虑，研发提出的方案和排期，心里基本也能有数，效率提高很多。

现在各种学习编程的资源非常丰富，我个人觉得运营学习一些编程知识，对思维的锻炼，产品的了解，视野的提升都有益。

第五、发掘共同利益，大家好才是真的好

说到底，运营的目标是要最大化产品的价值。这中间无论运用何种手段，只要合理合法不违反公司规定都是没问题的。

但如果总想着利用别人，占点便宜，也许一时可以，长久都是不奏效的。

最好的方式：是让参与的人有共同的利益，这事成了，大家都获利，而不只是单纯的部门之间工作配合或者帮忙而已。

一方面，需要从组织结构上理顺，为一个产品线配备齐全人员的产品事业部制，就比按职能划分按任务派活的大部门制更能激发员工对产品的责任感和积极性；

另一方面，要舍得分享，赏罚分明，产品做得好了，大家都有功劳，该分钱分钱，该团建团建。大家都知道跟你做事不吃亏，时间长了，靠谱的人会愿意持续跟你配合，你的口碑和职场信誉也就建立起来了。

3、运营眼中的靠谱研发是什么样的？

技术好，还用多说么。。。

还懂点业务，理解需求快，而且能结合需求完善更好的解决方案；

好沟通，能换位思考，我曾经合作过的一位研发leader，需求完美解决不说，还会自己主动琢磨「怎么把这个后台做得让你们运营好用一些」，好感度提升一万点啊！

最后，颜值还高……这算附加值了，能把自己打理得干净整洁精神焕发的研发更是稀少，遇上请务必珍惜。

以上我从运营角度谈了如何与研发建立良好合作的五点经验总结。

如果你合作的都是靠谱研发那自然好，大多数人没那么幸运，就只能从自身出发，把自己本职范围内的事都做到位，要求对方靠谱，自己一定要先尽量靠谱吧，然后尽量能换位思考理解合作伙伴，帮对方着想一下。

大家都是一起工作的，没有谁天生就和谁是对头，尤其在现在工作压力大的时代，每天和同事相处的时间比和家人都多，如果各个职能的小伙伴都能合作愉快，建立统一战线为实现共同目标高效地工作，那真是个清平安乐的美好人间。 

原作者：产品运营张媛

原文链接：http://www.jianshu.com/users/9d81f0b99aca/latest_articles