内容建设

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

需求提炼

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

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

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万元。

详见Bambook大赛最终获奖结果通报新闻：《Bambook程序达人赛获奖结果揭晓——JavaEye会员夺冠》。

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

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

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

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

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

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

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

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

网站改版

我在纯银的博客里看到过这样一段话：

在95%的情况下，带着平媒优越感来到网媒做主管的人，都会(很快地)发起一场(以改版为手段的)大跃进，打算做一些标新立异，旁征博引，体现不凡品味，建立江湖地位的事情。然而这些动作(事后总结)大都很蠢，于是他们被老编辑看做是“又来一个大傻逼”。我07年也做过这样的傻逼，现在仍有不少人前仆后继。由于工作环境封闭，单纯，网媒从编辑中培养“有管理气场的”主管比较慢，不得不在管理职位空缺时，不断从平媒空降领导下来，悲剧也不断上演。又来一个大傻逼→傻逼终于知道自己是傻逼了→傻逼走了→又来一个大傻逼……

这里提到的改版不是目的，而是手段，什么手段呢？证明自己比前任高明，比前任能干啊。新官上任迫切要证明自己的能力，靠什么？不整点儿大动作的能行？你不整点儿动静出来高层还看着你呢~

网站改版本身是一件很正常很自然的事情，网站也是一种互联网产品，是产品就有更新换代的生命周期；网站只要在运营，必定会有用户吐槽提建议这里不好用那里有漏洞；同时互联网新生事物层出不穷，也要求网站必须跟上时代，不断有创新，那么改版就自然要提上日程。

改版的周期视具体情况而定，不同的网站有各自的周期，不能一概而论。改版的规模分整体和局部，只要是正常运营的网站，局部改版其实都是一直在进行的（以技术类网站来说，访问量较少的深夜和节假日通常是最合适的改版上线时间）；整体改版由于变动比较大，势必会不同程度影响用户的正常使用，因此需要充分准备和周密规划，制定完善的改版计划，不仅是产品设计研发团队，运营市场甚至商务团队都要共同参与。

网站改版的目的是解决bug，提升性能，优化网站界面和结构，提供更新更好的功能和服务。那么问题来了，改版之前都要做哪些准备？改版过程中运营同学需要如何参与？

一、做调研

• 首先，看数据，数据是最直接的证据。比如历史数据增长和同期数据对比可以看出网站的发展趋势是否健康；访问时长和跳出率可以看出网站结构是否友好，网站性能是否良好；访问来源构成可以了解用户分布和外部推广情况；页面点击分布可以看出内容布局是否合理等。通过数据反映出网站哪些方面有问题，改版的时候就有的放矢了。

• 其次，看用户，用户是哪些人？他们来网站的目的是什么？现有产品和服务能够很好地满足他们吗？用户访谈和调查问卷可以作为改版的参考，但用户的意见不能作为唯一的依据，还需要结合数据和网站定位综合评估，比如用户一定都希望网站广告越少越好，但网站又不能没有广告收入，这时候就得合理规划广告位，尽量把广告设计得美观大方一些，不要影响正常浏览网页，或者通过游戏互动问答活动等方式增加用户对广告的接受度，同时也增加广告的曝光和点击。

• 再次，看竞品，有哪里值得借(chao)鉴(guolai)？并不是说隔壁老王有什么我们就一定要有什么，只是同样的产品和服务，别家做的有什么不同，比我们好在哪里，成本允许的话正好一起改进了；别家有我们没有的产品和服务，是否迎合了用户的需求？我们也做的话能否结合自家的长处和优势？有就上，没有的话抄过来也可能长不大。

二、定目标

调研结果出来，目标就好定了，是以提高网站性能为目标？还是以优化界面提高用户访问时长为目标？抑或是要采用更新的产品来替代已经过时的产品？要面向某个既定用户群体的需求提供更有针对性的产品？确定目标后才能够对实现目标需要的资源和时间进行有效评估，否则就是盲目拍脑袋。

三、定需求

充分收集用户的意见反馈，根据数据和竞品调研结果，提炼总结需要在本次改版中实现的需求，并以产品原型方式展现，经产品设计研发运营人员全体确认，调整为最终需求方案。特别强调一定是在需求确定阶段就要运营参与进来，这个产品的定位符合用户需求吗？要达到同样目的有没有成本低的方案？上线之后怎么运营，需要什么资源支撑……该准备的就要开始准备了。这些事儿不在需求确定阶段想好了，没准备，产品上线无法有效运营，半死不活，光界面好看体验超群那都没用！

这里直接引用一段话——

菜鸟级的产品经理，往往认为自己做一个东东，丢到互联网上，奇迹就会发生。所以，他对一个产品的终极设想，是版本开发完毕后上线的一瞬间。就如同天真的小白少女，对爱情的终极设想就是穿上婚纱走向王子。
而经过腾讯的系统训练的产品经理，非常清楚，第一个版本丢到互联网上，只是未来无尽服务，无尽优化的一个开始。
接着无止尽的：
数据反馈，优化特性，优化服务*

这些反馈优化如何实现呢？就是通过持续运营了。

四、做宣传

做宣传有两个目的，一是让用户知道，一是让同事知道。

无论如何，做出来东西总是希望有更多人知道并且来用的，除非你改版的目的就是补上原有的“大坑”，那还是低调为好。。

做宣传就是定期将网站改版的动态实时通报给用户，及时安抚用户以免用户对改版可能的影响产生不安，在社区中“造势”，让用户对改版产生期待和关注，进而形成良性的反馈。有人说只要产品做得好自然不需要提前说明，用户自己看就行了，这有一定道理，但请注意本文说的是“改版”，意味着用户使用习惯也会随着产品改变而改变（比如说微博v6版），改变本身无所谓好坏，如果有适当的准备和引导让用户更快地习惯新版不是更好嘛？总比到时候“卧槽咋改成这样了，那个入口到哪儿去了，到哪儿去找我的*”好吧~

让同事知道主要是在公司内部宣传，最好让其他有协作关系的部门都知道一下，有利于整体配合，共建安定团结大好局面；别闷声不响自己改自己的，看看是不是会对其它部门造成影响啊，其它部门有没有做同款产品不知道，对其它产品有没有冲击也不知道，上线后抢同一批宣传资源各自宣传基本相同的产品，用户也无所适从，Ok这也算一种丛林法则，最后还是产品和运营强的胜出，只是从公司角度看有点浪费啊~

五、做测试

开发过程中，产品运营研发和UI同学们也要保持频繁沟通，及时测试，并对开发过程中可能产生的问题随时讨论达成一致的最佳方案；开发完成的测试阶段，应该邀请热心用户一起参与内测，根据以往的经验，用户往往能够发现很多潜伏的问题，在内测过程中，也增强了用户的参与感和对社区的归属感。不过有一些问题，仍然是在上线后才会暴露出来的，所以在产品上线的第一周要格外注意用户反馈和产品数据。

六、做客服

正式上线之前，一定要及时以公告的形式，告知用户改版后可能会有的影响，改版的好处，新功能的介绍，遗留问题如何处理，以及很重要的一点：与网站管理人员的沟通渠道都有哪些。最大程度让用户了解改版后的网站，减少陌生感和不适感，实现切换到新版网站后的顺利平稳过渡。

至此，一个完整的网站改版过程结束了，这里是以运营角度来谈，因此没有提及设计与研发相关的工作，另外，改版完成只是网站一个新的阶段的开始，并不是上线就大功告成了的。

最后要说一下，新主管空降后是不是一定都要搞网站改版？

如果公司招你来的目的就是要主持改版，那没什么好说，不过前提仍然是要先摸清楚情况，明确改版的目标，用户的需求，需要的资源再动手；否则目标不清晰，资源没到位，用户需求也没摸透，为了改版而改版，那结果一定不会好，典型案例我见过好几次了；如果你确实觉得，目前的网站存在诸多问题，这里也不好，那里也差劲，那么改版可以成为你的工作目标之一，但决不是首要的工作目标，除非不改这网站马上就倒~~那么你要怎么做？

知己知彼才能百战百胜：跟你的上司沟通，说明你的思路，争取他们的支持；跟你的下属沟通，了解他们的工作，了解目前存在的问题，了解网站现状的由来；跟你的用户沟通，了解用户的需求，他们真的迫切需要一个全新的网站吗？这是用户的首要需求吗？跟你的客户沟通，哪些需求是现在网站无法解决的，必需要通过改版来解决？哪些需求是可以简化的？哪些需求是有替代方案的？

同时，你要自己多使用网站，了解它的各项功能，了解它的历史，了解它的用户和客户，熟悉之后，你对网站哪里存在问题，具体情况就会有相当的了解了。

这时，你与团队应该也相处了一段时间，度过了最初的磨合期，团队成员的优劣势，资源配置是否到位都比较清楚了，组织团队共同进行大型项目协作才是合适的时机；网站改版需要团队各个成员，各个职能部门的密切配合，不是凭个人单打独斗就行的，刚空降入职决不是启动大型改版的好时机。

现在，是不是一定要改版，改版的目标是什么，应该怎么改，需要哪些资源，应该有谱儿了。

我见过很多空降领导，怀着一腔“打碎万恶的旧社会”的热血，指点江山挥斥方遒，觉得以前的网站，包括员工的工作方法，都奇Low无比亟待拯救~个人观点，不要把别人都当成傻子，首先哪个网站都不是一点问题没有，其次一定不是只有你一个人知道有问题，为什么是现在的现状，在不了解网站历史，用户，团队的情况下，不适合做先入为主的判断。觉得自己很牛很厉害，“改版这事儿有什么难的？”不接地气儿不了解情况就大干快上，好听点叫盲目自信，不好听的真的是傻逼。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

跟靠谱研发合作，运营不需要无休止地重复测试，提交bug；不需要没完没了地开需求沟通会，天天追着问进度；不需要担心某个需求无法实现，从而无法开展新业务。

你说如果你是运营，是不是一定要努力找出那些靠谱的研发小伙伴组队啊？

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

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

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

一定是：

经过充分的论证调研——

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

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

才靠谱。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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