开源社区运营经验分享（二）：从0搭建开发者社区运营策略

上一篇写了《开源社区运营经验分享（一）：我们为什么要做社区？》，明白了我们为什么要做，接下来的动作并不是立刻去做，而是要理清运营策略，搭建运营框架，再坚定地去执行。所以这一篇重点讲述《如何从0到1 运营开源社区》。

有很多小伙伴习惯了追求速度，一有问题，常常是依靠下意识去处理，以为这就是职场上所强调的执行力。其实不是，执行力是指带来结果。

思与行的关系，我认为沈鹏在《详谈》中提到的尤为准确：真正的执行力应该是想得足够清楚的时候，你拼了，这才是执行力。不是说你什么都没想就瞎搞，那不是执行力。

说回开源社区运营，本质仍是社区运营与用户运营。前者是后者的子集，是一种相对小众的特殊情况，但仍旧逃不开用户运营的共性，即围绕人这一核心，梳理用户画像，理解用户需求，通过各种资源配置，让用户来到你的地盘，留下来，玩得爽，自觉维护你，还要对外说你的好话。

成也规模，败也规模。

社区运营因为用户规模小、重人力、琐碎的事情多，常常被人看做是鄙视链最末端。是的，你没看错，尽管运营已经在互联网鄙视链的底端，但不妨碍内部仍有更精细的鄙视链划分。

但也是因为规模不算大，社区运营才有可能对这群人进行更加人性化甚至是人格化的运营。尤其是在一对一的用户运营中，往往能够挖掘出社区关键人物，撬动更大贡献。

毕竟一个社区真正能够产出、有话语权的人物，也只有20%不到。而社区运营本身也可以作为更大范围内的用户运营或者功能产品化的前期测试，给其他团队以一些新的思路和支持。

做完了社区运营的心理建设，接下来讲讲如何从0到1运营开源社区。

01、了解用户，梳理开源社区用户画像

运营开源社区的第一步就是了解你的用户。

只有知道了他们是谁，多大年纪，做什么工作，内容消费习惯是什么样的，喜欢什么时候摸鱼，有什么需求，你才知道要如何满足对方的需求，从而让他们也能为你所用。

除了梳理出典型用户画像（物理属性+社会属性）之外，还要了解用户结构和了解用户的分级、分类、分阶段情况，具体来说包括各类典型用户的数量、占比、每日增长规模大概是多少、不同生命周期的用户占比是否健康、成长速度是否会导致青黄不接（新用户不够，老用户流失，无人活跃）……

一般C端业务的社区用户画像到这里就够了，但对开源社区这种和B端业务强相关的社区来说（因为B端业务决策是集体决策，更多是取决于角色决策，详细差异可以查看我的B端运营三部曲，放在文末），还需要在用户画像时加上行业（行业现状、市场规模、发展趋势）、企业（如企业规模、收入规模、活跃用户、公司评价）、职位（CTO、技术总监、专家还是一线人员）等标签，以此来做用户分级，方便评估后续运营成本的投入。

就真的还蛮现实的。用户进入社区之初，就已经分出了三六九等，应用广泛、需求强的行业比试水行业优先级搞，大公司职员比小公司职员待遇好，技术大咖比小白用户得到更多青睐……

如果说C端社区运营像自由恋爱，讲感情，看感觉，那么B端社区运营更多就是相亲，各种条件摆得清清楚楚，评估过后再来看以什么姿态、用几分力。

那要如何了解用户呢？

我自己常用的调研手段主要有以下三种：

1）用户访谈：一对一访谈和群访都有，但规模都比较小。一对一可以聊的更深度，用户也会有比较好的体验，感觉被尊重和独家对待。群访可以撬动一些相对不愿意透露信息的企业人员，给人以更强的安全感。

很多人以为访谈很容易，不就是聊天嘛，但其实访谈是需要提前设计问题的，而且在访谈时要尽量客观记录和分析，记录时不要加入自己的理解，以防信息变形，导致后续分析离用户的真实想法越来越远。同时也要学会追问，挖掘用户深层次的真实需求，在初次交锋时，用户可能会讲一些很表象的想法和需求。追问可以验证用户是不是真的有这样的需求，真的这样想。

2）问卷调研：比较适合更大规模的用户研究，但问卷的设计很考验人，这里有需要的话，以后单独开一篇来讲。

3）看行业报告：结合报告数据与自己的一线经验，对照分析自己的目标用户有哪些共性特点，有哪些是报告所未能涉及到、属于你的小洞察的。

这里还要着重讲一下心态问题，因为社区运营工作多且琐碎，反复遇到一些问题以后，不免会有些烦躁和抱怨，比如用户这么笨，这么简单都不会操作？他怎么这么懒，文档不是都有吗？怎么又问重复的问题？

做社区运营，尤其是不断滚动的成长型社区，就像生育孩子一样，大孩长大了，二胎又来了……然后还有三胎、四胎。

对你来说重复的问题，对他们来说可能是第一次。他们也不是笨，最多只是懒，习惯了伸手问妈要。放下不耐烦，打破「知识的诅咒」，多看用户的留言和评价，针对性解决问题，才能把你的“孩子”带起来。

02、定位先行，一切运营动作围绕定位展开

完成「了解用户，梳理用户画像」这个步骤以后，基本掌握了我要运营的社区的目标用户情况，概括起来就是企业侧以技术人员为主，还有少量的商务、市场以及高管；校园侧会有一些相关专业的学生及教授，需求方面依次有技术需求、交流需求和商业合作需求。而社区只是作为一个满足用户需求的载体，也是实现企业目的的工具。

因此需要给社区一个定位，一来是设定核心目标以及边界，夯实这个定位的，我们可以做，其余不做；二来也是为了让每个第一眼看到社区、第一次进入到社区的用户就知道“这个社区是做什么的，能够提供什么价值，都有谁在里面，我能够在其中做什么”。

问题来了，定位要怎么去做呢？尤其是那种看起来高大上的slogan要怎么写呢？

首先是要站在用户视角，看用户最需要什么，而不是你有什么。我相信每个人不论是对自己运营的社区还是运营的产品，都能够说出来一大堆的优点，但问题是你写的那一点，用户真的care吗？同样是写“全球首个XXX社区”“全国最大XXX社区”，B端用户会考量技术积淀、开发者支持力度、生态丰富度，但如果是小众社区呢？这些用户会希望被冠以“大众化”的title吗？未见得。不管你是从行业价值角度、自身优势角度、还是诸如建立时间这样的客观描述角度，只有当你的定位话术刚好戳中用户最关心的那个点，才是有效定位。

其次是明确开源社区的内部定位。截至目前，开源技术本身也没有找到很好的商业模式，开源不是出发点，也不是终点，而依托开源技术而生的开源社区既然动用了人力物力财力，必然也承载着自己的企业使命。

如在《开源社区运营经验分享（一）：我们为什么要做社区？》中所言，我自己所运营的开源社区对于企业的作用在于反哺产品迭代、为品牌传播建立种子用户群以及孵化商机，本质还是为商业化做产品和流量准备。

可能会有小伙伴说“不就是一个小小的社区运营，至于搞得这么饿复杂嘛”。越是难以量化、不被重视、承载误解的工作，越需要自己去厘清眉目，才能避免做着做着失去了工作的热情，陷入机械的重复中。

而有了定位，知道自己所做的事情到底能给公司业务带来什么价值以后，面对该做的事情，你会有自己的标准去判断优先级；面对一些突然而来的dirtywork，你才知道如何巧妙的拒绝。

有了定位以后，不管是按照KPI还是OKR拆解和制定一版运营规划，和上级对齐自己的工作内容。这样既可以体现你的工作态度和能力，也便于你去争取工作所需的资源。

03、开源社区运营，分级、分类、分阶段

1.用户分级运营

资源永远是有限的，而我们的工作就是要在将有限的资源利用最大化。除去显性的金钱与物料，你的时间也是极其宝贵的资源。

即使是小规模的社区运营，可能也有小几千人，如果对每个人投入都一样多，最后大概率只会累死自己，还照顾不好用户。海王或许有，但即使是最优秀的时间管理大师，也绝对不会同时应付超过150个人（邓巴数，即150定律：人类智力将允许人类拥有稳定社交网络的人数是148人，四舍五入大约是150人）。

同时，你会发现这个世界遵循着帕累托原理（又名28定律，即最重要的只占其中一小部分），80%的人消费着20%的人生产出来的内容，20%的人占据着这个世界上超过80%的财富（这一趋势只会越来越极端，比如5%的人占据着世界财富的95%）。

80%是多数，但却是次要的。开源社区不过是世界的一个缩影，20%的用户创造80%的价值，20%的客户创造了80%的利润。作为一个运营，也需要花费80%的精力去服务20的优质用户。

用户分层是按照重要程度、贡献价值等标准来划分，有比较鲜明的等级差异（没有到不尊重，只是指投入程度和运营优先级的差异）。用户分层的判断核心在于用户对产品或者业务的ROI，以便后续根据预期收益投入相应的成本。

一般来说，我们会把用户按照贡献价值从高到低分为以下五种：

名人用户（行业大佬、学术权威等，平时不怎么发言，但可以为社区权威性背书，必要时也能为合作牵线搭桥）＞贡献用户（资深开发、技术大牛等，可以贡献代码方案）＞活跃用户（一般的技术开发者，氛围担当的同时可以解决一些基础问题和提建议）＞普通用户（反馈产品问题，参加社群的有奖活动）＞入门用户（一般是学生，处于研究阶段，最常干的事情就是提问和薅羊毛）。

以上数字只是示意并非不同级别用户的实际贡献

2.用户分类运营

有时候也会被称为「分层运营」，但我还是认为分类一词更加清晰，因为分类运营没有明确的等级差异，不存在谁高谁低。而「分层」本身就有高低之分。

用户分类的判断核心源自于用户本身的差异，如行为习惯、需求场景、技术水平、企业背景不一样，分类的目的是方便运营以特定手段和内容来触达和满足不同类型的用户。

比如，同样处于普通用户层级的两人，可能一个来自金融行业，另一个是零售行业的，他们的核心需求就不太一样。

用户分类的标准相对比较灵活，除去行业属性、职业属性、企业属性之外，城市、甚至是设备类型都可以分类。由于用户价值也是分类的标准之一，所以有些人会把用户的分类与分级搞混。

完成用户分类以后，抽象出共性，再进行针对性运营即可。

3.用户分阶段运营

而不管用户分级还是用户分层，都需要分阶段运营用户，这里的判断依据在于用户与产品的交互和认可程度：是只听过没用过，还是刚安装不会用，又或者是已经非常熟练到可以去教别人？这个部分相对复杂一些，涉及到用户生命周期管理、用户成长体系以及用户激励体系的搭建。

考虑到篇幅过长，将在下一篇中重点讲述这个很多人好像明白但又容易搞混的部分。