如何从0开始搭建开发者社区运营策略.docx

如何从0开始搭建开发者社区运营策略.docx

《如何从0开始搭建开发者社区运营策略.docx》由会员分享，可在线阅读，更多相关《如何从0开始搭建开发者社区运营策略.docx（13页珍藏版）》请在冰豆网上搜索。

如何从0开始搭建开发者社区运营策略

如何从0开始搭建开发者社区运营策略？

本文作者从用户画像出发，结合用户分层、以及社区运营层面，共同探讨了：

“如何从0开始搭建开发者社区运营策略？

”

随着Mar-tech等技术飞速发展，ToB营销相较以往发生了天翻地覆的变化。

相较于短平快的直接BD手段，建立长期关系营销方案、拉长客户关系生命周期已经成为可执行、可持续、相对低成本的营销策略。

与此同时，由于客户关系生命周期的拉长，这也开始要求在营销过程中对不同用户群体都能提供对应价值。

开发者作为互联网企业中不可或缺的重要群体，一直是ToB厂商（比如PaaS、IaaS）所关注的重点。

那今天来说一说如果将开发者社区作为产品进行运营，我们到底该怎么做（部分内容将以云原生作为示例）。

一、开发者画像

由于使用相关技术产品或服务的企业用户，大多具有企业属性且内部包含多个角色属性。

想要构建完整开发者用户画像，就需要对决策链上所有相关角色进行调研。

因此，调研需要包含行业属性、企业属性、角色属性这几个主要维度：

行业属性：

如不同行业的市场结构、运作模式/规律。

通过行业特征，了解行业现状和发展趋势；以云计算举例，银行业的上云需求一定会比房地产更强，且需求更严苛、预算更充足。

企业属性：

如企业规模、收入规模、活跃用户、使用评价等。

通过企业特征，了解目标开发者的业务需求现状与企业发展的痛点；

角色属性：

如决策者（CIO、CTO）、中间层（技术专家、研发总监）使用者（一线员工），决策者、中间层、使用者关注点和需求存在很大差异，明确其间的分水岭；

个人属性：

如年龄、技能等需求，更多是关于马斯洛理论上层相关的问题。

这里我们可以使用两种调研手段：

定性分析：

通过访谈、问卷等方式，结合行业研究报告、过往经验等手段，挖掘开发者用户的行为动机、需求、变化规律；

定量分析：

基于已有数据与行业Benchmark的研究，对开发者用户进行各项指标、特性、相互关系的对比与分析。

在实际操作过程中，于小规模核心高贡献用户进行访谈。

于大规模普通用户通过调查问卷形式完成调研。

在一度猛如虎的操作后，我们可以勾勒一个相对完整的用户画像。

通过标红的KeyMessagge，我们可以看到相对清楚、强烈的开发者用户特征（这里引用CSDN的报告，来做一个示意）。

（1）互联网、软件、IT制造三个技术领域涵盖了国内84%以上开发者

30岁以下开发者人数占比超8成，全国近半数开发者工作在一线城市；

61.6%的开发者从业年限在1-5年，从业年限在1年以内的占到18.3%；

66%开发者拥有本科学历，12%开发者拥有硕士或以上学历。

（2）开发者学习热情高涨，近6成开发者每周学习6小时以上；

5成开发者通过自学，31%接受了软件开发在职培训；

37%开发者愿意付费学习；

7成的开发者参加培训的预算来自个人。

（3）6成开发者在使用Java语言，近5成开发者近期最想学Python语言

开发者的云/容器使用率仅15%，超6成开发者在使用Notepad++文本编辑器；

34%的开发者用容器进行开发，基于云上/浏览器IDE进行软件开发方面，普遍看启动速度快，操作便利性和桌面版IDE可以媲美。

（4）Apache项目和Linux是开发者较为喜欢的开源项目

68%的开发者接触开源的时间在2-5年；

半数开发者很少参与开源项目的开发、维护、运营和社区发展等，全职参与仅7%；

超过6成开发者未从开源项目获取收入；

77%开发者每周在开源上投入不超过5小时。

从上述描述，我们总结可以看到开发者群体的行业、地域属性相对集中且普遍学历、认知较高；学习欲望很强且有一定参与活动的兴趣。

虽然会参加社区或者开源项目，但是并没有赚到钱。

二、开发者社区定位

在明确我们的开发者用户画像、产品后，我们希望建立一个开发者社区来作为载体，实现用户的转化与留存。

那么，开发者社区是什么，需要什么？

2.1什么是开发者社区

对于开发者社区，我们是这样定义的：

「连接厂商与开发者，围绕对某种技术的共性需求，通过双方产生内容形成互动的（线上/线下）商业价值孵化平台」。

所以，我们可以抓住其中的几个重点：

（1）对某类技术的共性需求

结合前面的开发者画像，我们可以看到针对特定产品或者技术领域，开发者会有强烈的欲望希望深入学习某类技术、产品或解决具体工作过程中某产品的使用难题。

比如开发者想要通过云原生社区了解DevOps相关的自动化发布管道、CI工具以及如何实现开发、运维协同合作。

那么，他就会选择对应的垂直开发者社区进行查找相关资料。

（2）双方产生内容

社区的基础是内容，内容类别决定了社区氛围与运营调性。

在构建完整结构化内容后，结合用户和平台属性，推荐分发相应内容，完成内容对用户的触达。

用户在PGC基础上实现UGC，形成完整内容产出闭环。

从而实现「厂商+忠实用户丰富基础内容，普通用户通过内容产生评论、转发参与互动，厂商+内容监督者通过审核平台内容，维持社群秩序，增强社区归属感」，使得不同角色都能通过内容与社区产生互动。

比如阿里云原生开发者社区提供了完善的云原生技术公开课，帮助用户理解云原生知识。

用户获取知识的同时可以结合课程展开讨论或分享自己的最佳实践，与同业者产生互动。

（3）互动

用户在社区内产生的UGC、评论、转发等互动行为，都具备着可量化、可商机培育的价值。

通过互动频率、互动质量评估用户粘性，也进一步验证社区搭建的核心目的是否与开发者需求相符合。

通过内容互动引导完成开发者完成「认知用户客户」的角色转化，并增加开发者对社区依赖。

借助场景化社交，让用户间形成相对稳固的社交链。

比如对热门技术话题的讨论各种形式的Meet-up，杰出贡献者奖励公示、贡献排行榜、赋予大使头衔等等。

（4）商业价值孵化

ToB厂商做了很多事情，虽然会强调推动行业技术发展，但其实核心目的始终是卖货挣钱，开发者社区其实也是手段之一。

利用用户对社区及内容的认可，实现商机线索的获取与孵化甚至是售后客户的Upsell。

但ToB技术类产品存在商机培育周期过长、决策链条过长等问题，所以一般社区运营更多的会追求社区活跃、产品使用活跃等运营指标，并不会考核直接的线索数量或者商机金额。

2.2开发者社区运营目的

在列举所需资源前，我们需要明确社区的运营目的。

这样才能更好的去协调公司内外部资源，常见目的主要涵盖两个维度：

产品层面、营销层面，具体包括以下几个方面：

产品品牌传播：

提高厂商品牌在开发者群体中的认知度、美誉度，实现技术、产品普及；

建立用户流量池：

为产品拉新、转化提供流量池，为产品测试、市场反馈提供载体支持；

商业价值孵化：

完成从认知到使用用户到付费客户的转化；

产品服务：

替代传统帮助文档、工单系统，降低售后服务成本，提升售前服务体验；

建立社区生态：

优化技术、完备场景、整合资源，通过外部开发者完善厂商现有产品；

学习平台：

作为技术布道者，帮助更多大众认知深入了解、学习相关技术领域。

其实可以看到，营销层面的多个目标是完整漏斗，因此这也要求了我们在运营过程中对不同环节、决策链上不同角色都要提供对应内容，从而产生互动。

那么用户我们该如何分层呢？

2.3开发者社区用户分群

在明确目的后，那我们运营的人群是谁呢？

决策链上各个角色对于商业价值孵化又有什么意义呢？

决策层：

企业CTO/CIO，信息化VP等技术产品采买决策人；

意见领袖（KOL）：

行业技术大牛，其观点对其他开发者甚至决策层有较大影响，如各类协会大佬、技术社区活跃专家、系列课程讲师、基金会大使、某领域布道师；

选型者、评估者：

企业中的技术/研发/运维总监、系统架构师等对产品选型具有评估权、推荐权的用户群体；

一线使用者：

资深程序员、产品采买后的直接使用者；

大众认知：

普通开发者，听闻过相关产品、技术，有兴趣了解相关领域。

对于日常运营而言，商业价值随着上文介绍顺序而逐渐降低。

我们希望通过各种大型活动将业务价值信息和品牌力精准传递给决策层，影响决策层决策。

对于意见领袖，希望能够帮助我们有效覆盖传统媒体渠道所无法触达的相关受众，并融合更多外部观点。

对于意见领袖，虽然BD难度相对较大，但合作价值巨大。

选型者、评估者、一线使用者，商业价值居中且基数巨大，相对于上述两类受众的触达与转化成本较低，也是社区的重要流量来源。

大众认知作为外部流量基数，决定了我们社区未来的体量天花板。

前面我们描述了厂商对于开发者社区的目的，那么对于用户的实际价值呢，可以归纳为：

解决业务中的实际产品使用问题；

获得培养技术技能、探索新技术机会；

获得与不同公司技术专家合作讨论机会；

在未来工作面试中，借助社区贡献者身份进行背书；

物质奖励。

我们在前面提到开发者社区是厂商与开发者围绕着产品、技术需求产生内容互动的平台，也讲到厂商与开发者用户的各自诉求，所以我们需要协调厂商以下内部资源支持。

2.4开发者社区需要哪些支持

俗话说，有人的捧个人场，有钱的捧个钱场。

基于我们前面罗列的厂商与开发者双方诉求，所以需要跟老板索要人员、内容、资金三方面的支持，才能有效开展运营工作。

（1）人员支持

基础支持：

社区平面设计师、前端开发工程师，支持日常活动；

社区运营：

线上/线下活动落地执行人员，线上内容渠道分发执行人员；

社区答疑：

结合社区活跃度与体量，设置1-2名长期技术支持（TS），回答社区内常见技术问题；

技术布道：

3-5名技术专家不定期活动支持，包括但不限于培训讲师、沙龙嘉宾，CTO/CIO不定期的大型活动、大型活动的站台支持。

产品带货：

目标行业的行业解决方案专家结合销售节奏的活动支持，包括但不限于培训讲师、沙龙嘉宾。

（2）内容支持

技术文档：

产品使用文档、技术文档；

场景案例：

最佳实践、行业场景案例、行业解决方案；

学习资料：

产品上手教程、技术原理学习；

问答内容：

常见故障答疑、大咖问答；

技术认证：

技术or厂商认证公开课；

开发工具：

产品、上下游延展工具集合。

（3）资金支持

常规扶持：

包括对各种学校、中小企业、协会机构的产品、资金孵化支持。

2.5运营启动节奏

在明确人群、目标、资源后，结合产品研发节奏（技术产品主要就是开源），就可以开始制定相关计划。

针对开源社区型产品，我们可以试着结合下述主要关键节点，开始筹备运营计划（下面的流程图，腾讯云曾在某次分享中提到）。

梳理已有内部资源、用户调研结果报告；制定运营启动计划与分工；

搭建内容排期、选题流程、生产架构，内容分发机制；

明确社区内开发者服务响应机制；

制定自有活动计划，制定活动SOP，筹备、执行；

梳理外部渠道、上下游合作伙伴、KOL目标人群，结合预算制定合作BD计划、落地计划表；

全运营流程数据跟踪，包括活跃度等产品层面指标、商机线索等业务层面指标。

根据指标评估运营效果，复盘运营方案，进行渠道优化；

制定社区鼓励规则，培育社区内贡献者。

2.6运营考核与评估

在跟老板索要完资源后，我们肯定要设定业务相关目标，来衡量我们所做事情的价值以及ROI。

因此，从业务指标、社区运营指标、内容运营指标进行衡量：

业务指标：

商机线索数量、机会金额、Up-sell金额；

社区运营指标：

常规包括社区渗透率、新用户注册量、用户互动率、社区功能留存、社区用户留存、人均使用次数、人均登陆时长、活动报名等；

内容运营指标：

可能包含PGC数量、UGC数量、人均阅读篇数、文章点赞、评论、点赞评论、评论回复等。

在明确老板的北极星指标要求后，我们可以具体拆解长期指标与短期指标。

并且依靠这些指标，更好地驱动我们制定详细运营计划。

2.7开发者社区常见通病

放眼望去，开发者社区、开源社区非常的多，但是不管是厂商还是第三方运营得非常好的却寥寥无几，问题主要集中在：

软件基础设施缺乏适配，相关资源获取困难，缺乏开发测试环境，这个主要集中开源社区，厂商社区一般不会出现；

开发工具不完善，开发、迁移、调优困难，这个主要由于厂商的产品矩阵造成的，一些工具的厂商可能存在竞争关系，但自研成本又太高；

开发资料、文档匮乏，缺乏足够代码实例和模板，这个主要是厂商内部开源团队是否有足够的精力或者资源完成相关内容；

主导企业相对封闭，软硬件开源力度问题，这个主要由于行业竞争与产品战略；

开源内未完成商业孵化闭环，开发-发布-销售-服务链条断裂，这个主要是小厂妄图开源却没想清楚商业价值的会遇到的多；

相关技术布道较少，难以获得解决问题的最佳实践；

生态内企业技术能力不够强，产品竞争力有限，无法满足客户业务需求。

那在明确我们已有资源、目的、用户画像、可能的坑，那么就可以开始细化运营策略。

三、开发者社区运营细则

Ok，在整理完用户画像、用户分层、社区运营目的、已有资源后，那我们来说说具体的运营，即「高层用户做价值，普通用户做口碑」。

具体工作可以拆解为内外部两部分。

3.1内部运营

（1）社区主站运营

作为开发者社区的运营主要承载体，在运营过程中起到了重要作用，因为我们所有外部流量最终都将着陆于开发者社区主站，因此主站非常重要。

一般而言，我们采用PGC+UGC+PUGC+OGC的形式进行内容运营，确保内容的不断产出，并建立「内容采集审核结构化–推送召回」的内容链路。

并针对新老用户，分别明确运营的干预程度和基础排序规则，在保证优质内容触达用户的前提下，引导用户完成对社区的探索。

主要内容形式包括：

培训课程、认证；

使用文档、手册、案例、问答；

白皮书、图谱；

话题讨论。

在确保内容运营后，明确社区形态是问答类（技术产品答疑）还是阅读类（技术学习），内容强调人（专家、大咖）还是强调内容。

甚至需要明确浏览过程哪些互动形式需要进行强引导，相关页面是否要进行关联推荐。

这一过程，如果同领域有友商已在做相同的事情，可以将之作为参考材料；如果已是领先者或者探索者，则建议通过A/BTest去探索功能留存与价值，确定产品合适的社区形态。

在搞定内容、基本主站运营后，我们还需要建立相关的用户会员体系，通过积分、等级、成就等形式明确用户成长路径，并在这一过程中辅以现金、勋章等物质/精神激励引导用户。

（2）内容分发运营

这一部分基本属于常规操作，所有ToB厂商（比如PaaS、IaaS厂商）都非常的驾轻就熟，毕竟ToB的玩法相对单一且无趣，一个全职带俩个实习生就完全可胜任，比如

专栏类：

技术Blog、外部社区的专栏；

自媒体：

公众号、简书、头条号；

外部投稿：

技术媒体投稿、社区投稿；

问答：

知乎类大众社区问答、思否等专业社群问答。

但值得说明的是，随着内容发展，外部渠道非常容易让人眼花。

在筛选渠道的过程中，需要明确不同渠道的分发目的，是搜索引擎收录还是媒体权威性、还是受众精准。

比如，搜索引擎收录我们会选择简书、知乎（虽然现在知乎收录权重掉了好多），权威媒体就选择InfoQ、CSDN、SF，受众精准就选择对应社区。

（3）社群运营

除去主站外，社群应该是我们运营开发者的最重要方式之一。

但由于社群的即时性，导致它作为日常交流最为合适，但并不能作为内容记录与承载。

在社群运营过程中，我们可以根据开发者来源、讨论话题、身份进行区别运营，比如：

各种开发者活动的现场活动群；

围绕某个话题（比如敏捷开发）进行交流的技术社群；

围绕某个开源项目日常运维的贡献群；

由企业CTO/CIO、信息化VP等技术产品采买决策人、各类协会大佬、技术社区活跃专家、系列课程讲师、基金会大使、某领域布道师构成的高端社群。

通常这里需要Wetool等等工具的帮助社群运营人员进行群管理，在社群运营的相关内容会独立单写一篇，因为内容实在太多了。

（4）活动运营

如果说社群、主站都是开发者运营的常规操作，那么各类活动才是真正凝聚用户的有效手段。

活动形式非常的多，比如：

线上调研、问答、测试，比如Hackerrank等；

线上课程直播、系列视频，系列课程非常多，比如阿里云与CNCF的云原生课程；

线上编程活动、线上实验室，比如阿里云的天池大赛、天池实验室；

产品内测优先资格；

线下Meet-up、专家问诊、开发者日；

线下Hackthon，安全厂商做线下24h的黑客马拉松相对多；

线下培训、认证，比如CNCF的各类认证；

线下技术大会，比如AWSsummit、华为开发者大会。

小公司参加大厂活动，包括但不限于展位、演讲、圆桌等等；土豪公司直接开自己的大会，比如青云Qingcloud的大会CIC大会。

（5）开源项目

开源项目主要集中在Github上的项目管理，这其中包括：

相关文档、代码提交规范的制定/发布；

开源团队对项目的定期维护；

与外部贡献者的互动/激励；

外部托管渠道的运营。

3.2外部运营

如果说内部运营是留住用户，那么外部运营很大程度上是帮我们吸引用户。

这里不做详细展开，仅简单描述，避免广告之嫌。

（1）技术类知识付费

（2）技术社区合作

综合技术类社区

垂直领域社区

IT类出版社

（3）非技术类社区

B站、抖音等年轻化平台

（4）高端俱乐部社区

（5）机构、协会

信通院、CNCF等

（6）高校

四、竞品分析

在讲我们自身规划完成后，了解竞品的动态与玩法也同样重要。

以云计算行业举例，腾讯云、阿里云、华为云在各自的开发者社群运营上，内容形式、社区目的都相对接近，但在实际运营过程中却有着细微差别。

4.1腾讯云

除去常规玩法外，腾讯云采取了更多的ToC的社交玩法，比如：

线上课程打卡；

基金会支持；

奖励支持：

各技术社区及平台百万级流量推广；

不同价值云服务器资源、域名服务一年使用权；

线下技术大会及沙龙门票；

技术书籍；

腾讯云社区成长值激励；

腾讯云周边礼物；

与开源项目大牛零距离接触；

腾讯云新品内测体验。

4.2华为云

华为云则将重点放在我们前面提到的意见领袖的运营。

华为云KOL进行分等，包括mvp、云享专家，在这其中对应不同的权益。

从而鼓励其对外发声，在覆盖目标人群的同时，也实现KOL背书的作用。

相对于其他受众群体，我认为开发者是更加纯粹的用户群体，他们是一群能够理性客观评估某项事物价值、沟通方式直来直往、渴望荣誉与认可的“钢铁直男”（此处为褒义）。

因此，在开发者运营过程中不太需要小心机，而更需要帮助他们解决实际的业务问题或者获得荣誉。

因此，也许对于开发者运营而言，坦诚相待就是最好的运营态度。

PS.作为一个非纯正开发者运营，把自有业务经验与开发者运营内容结合，原初衷是作为学习笔记应对某考试。

仅做抛砖引玉，如有纰漏，欢迎补刀。