作者：板栗，前阿里、京东运营，6年资深互联网运营，成功从C端转B端，擅长用户运营、内容营销和个人IP打造，人人都是产品经理/鸟哥笔记等平台专栏作者

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

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

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

成也规模，败也规模。

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

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

毕竟一个社区真正能够产出、有话语权的人物，也只有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.用户分阶段运营

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

04 搭建用户体系之前的5个问题

随着用户不断深入了解、使用和感受产品，加深与产品的关联度，用户身份也是在不断变化的，比如导入期对应新用户，成长对应普通用户。

之所以这么划分，是为了更加清楚用户在不同阶段的核心需求。在这个基础上，运营利用已有的资源，引导用户进入或者更持久的停留在“运营期望的阶段和状态”，进一步提高LT和Value，完成产品从用户价值到商业价值的统一。

为了达成这一目标，我们可用的手段包括但不限于“用户成长体系”和“用户激励体系”。

而不管是成长体系还是激励体系，都要先思考下面几个问题：

问题1：哪些用户行为是我们希望看到的？

问题2：判断用户行为是否值得被激励的标准是什么？

问题3：如何判断这些行为之间的权重？

问题4：用户为何会按照我们的预期行动？我们能提供什么价值？

问题5：这个价值要怎么给，给多少，多久给一次，给的形式……整个玩法要如何设计，才能更好地刺激用户完成既定行为？

1、哪些用户行为是我们希望看到的？

对于一个开源技术社区来说，我认为可以从技术使用深度以及社区交互深度两个角度去思考。用户来到社区的初衷是技术互动，和同行交流并解决技术问题。一个人只要他提出的问题能够得到及时有效的回复，他就能留下来。如果他还能解决别人的问题，得到来自其他用户甚至是社区官方的认可，他就会更有动力在社区活跃。但如果只停留在技术交流，那么就低估了社区尤其是开源社区的价值空间。

PingCAP 联合创始人&CTO黄东旭在采访中说到，对于社区运营者来说，最关键的任务不是让沉默者更多或更深度地使用，而是让他们和网络中的其他用户建立更多的连接。将网络效应从使用者的网络效应转移到基于信仰的网络效应，将社区中心从开源公司内部转移到外部以获得更大的势能。

翻译过来就是，技术层面的交流，只能算是物理反应。当用户之间的连接程度超越技术转向共同信仰或者价值观的时候，社区才开始有了化学反应。这个时候社区的势能呈指数级增长，社区成员不仅可以自治，还能以共同体的身份对外发声与合作。

1）技术使用深度具体来说，包括但不限于使用技术产品、提bug、提issue、提PR等；

2）社区交互深度具体来说，包括但不限于参与官方内容转赞评，帮助社区其他用户解决技术问题，参与社区活动，在社区进行主题分享等。

2、判断用户行为是否值得被激励的标准是什么？

一个用户行为是否值得被激励的标准，一是用户行动以后会给社区好评吗，也就是说用户自己觉得舒服吗，有没有被满足；二是用户行动以后对社区有没有正外部性，也就是其他用户有没有因此受益。因为符合这两个标准的才能让用户玩得爽，以及社区健康可持续地发展。不能说，这个用户爽了，其他用户都跑了。虽然我们经常说运营用户就是伺候上帝，但问题是社区不只一个“上帝”，更何况上帝之间的行为是会相互影响的。

3、如何判断这些行为之间的权重？

还是上面两条标准，优先考虑社区整体的健康发展。

其余行为，要结合投入成本来看。一般来说，用户投入越重的行为，我们越鼓励。我们也很希望每个用户都能成为contributor，但很可惜达不到。对此大家也可以通过“官方投入”去观察产品和社区到底鼓励用户做什么。从某种程度来说，这也是一次交易。

4、用户为何会按照我们的预期行动？我们能提供什么价值？

用户愿意听你的、按照你说的做，是因为他愿意这么做来交换你手中的资源，并不是因为你牛逼。

而我们能够提供的资源或者说价值一般包括以下四种：

1）物质：现金激励，购物卡，周边，苹果产品等硬通货；

2）内容：技术文档，经典QA，行业资讯，白皮书等；

3）服务：一对一技术专家答疑，与权威专家交流机会，企业参观；

4）荣誉：社区认证讲师、技术布道者等荣誉；

这里提醒一下，还是要学会通过荣誉激励用户去完成预期行为。

大多数时候，钱都是不够的，我还没有听过谁的预算是花不完的。同时，人为了物质激励去做事是会疲乏且滥竽充数来薅羊毛的，只有内在动机才会让一个人真正优质高量输出（比如我现在一毛钱都没有，但心甘情愿在这里写内容）。

5、这个价值要怎么给，给多少，多久给一次，给的形式……整个玩法要如何设计，才能更好地刺激用户完成既定行为？

这个比较复杂，需要具体情况具体分析。由于工作内容暂时不便公开，所以细节也没法说。但是有些原则可以和大家分享。

首先是有多大金刚钻，揽多少瓷器活儿。

一定要结合现有资源去设计整个体系，不要空头支票。钱不够的时候，一定一定要取舍，做好重点，而不是均摊费用！

其次是设计用户行为时，要时刻考虑降低用户行动成本，不改变用户本来的行为路径，除非真的有必要。

比如说一个技术用户进来，在部署安装的过程中大概率会遇到问题，在他解决完以后，你引导他写一个注意事项文档，这是OK的。但你不要妄想一点点诱惑可以让用户专门为你创造一个东西。再比如，用户习惯了在GitHub上面提issue，用Markdown写作，你就不要非得要求别人和你一样用飞书文档交流。

最后要注意结合用户自然行为的特征（行动极限，行动频率等）去设计你的目标。

比如说，一般情况下一个用户每天也就是下午摸鱼的时候能够来给你当志愿者维护社区秩序，答上那么七八个问题，你就不要设计成每日答疑数量满50个可以获得XXX。人又不傻，放在面前的胡萝卜才去够，放太远了就直接放弃掉了。你设置奖励的目的是让用户完成从现状到理想的跃迁，不是“我不玩了”或者干脆“跳他个粉身碎骨”。

微信公众号：南有板栗

终身学习，定期分享运营经验和个人成长经验

 本文来源于开源精选集《开源观止》第 4 期，更多精彩内容，请点击下载：

https://oscimg.oschina.net/public_shard/opensource-guanzhi-20220915.pdf