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

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

• 搭建内容排期、选题流程、生产架构，内容分发机制；
• 明确社区内开发者服务响应机制；
• 制定自有活动计划，制定活动SOP，筹备、执行；
• 梳理外部渠道、上下游合作伙伴、KOL目标人群，结合预算制定合作BD计划、落地计划表；
• 全运营流程数据跟踪，包括活跃度等产品层面指标、商机线索等业务层面指标。根据指标评估运营效果，复盘运营方案，进行渠道优化；
• 制定社区鼓励规则，培育社区内贡献者。

2.6 运营考核与评估

在跟老板索要完资源后，我们肯定要设定业务相关目标，来衡量我们所做事情的价值以及ROI。因此，从业务指标、社区运营指标、内容运营指标进行衡量：

• 业务指标：商机线索数量、机会金额、Up-sell金额；
• 社区运营指标：常规包括社区渗透率、新用户注册量、用户互动率、社区功能留存、社区用户留存、人均使用次数、人均登陆时长、活动报名等；
• 内容运营指标 ：可能包含PGC数量、UGC数量、人均阅读篇数、文章点赞、评论、点赞评论、评论回复等。

在明确老板的北极星指标要求后，我们可以具体拆解长期指标与短期指标。并且依靠这些指标，更好地驱动我们制定详细运营计划。

2.7 开发者社区常见通病

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

• 软件基础设施缺乏适配，相关资源获取困难，缺乏开发测试环境，这个主要集中开源社区，厂商社区一般不会出现；
• 开发工具不完善，开发、迁移、调优困难，这个主要由于厂商的产品矩阵造成的，一些工具的厂商可能存在竞争关系，但自研成本又太高；
• 开发资料、文档匮乏，缺乏足够代码实例和模板，这个主要是厂商内部开源团队是否有足够的精力或者资源完成相关内容；
• 主导企业相对封闭，软硬件开源力度问题，这个主要由于行业竞争与产品战略；
• 开源内未完成商业孵化闭环，开发-发布-销售-服务链条断裂，这个主要是小厂妄图开源却没想清楚商业价值的会遇到的多；
• 相关技术布道较少，难以获得解决问题的最佳实践；
• 生态内企业技术能力不够强，产品竞争力有限，无法满足客户业务需求。

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

三、开发者社区运营细则

Ok，在整理完用户画像、用户分层、社区运营目的、已有资源后，那我们来说说具体的运营，即「高层用户做价值，普通用户做口碑」。具体工作可以拆解为内外部两部分。

3.1 内部运营

（1）社区主站运营

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

一般而言，我们采用PGC+UGC+PUGC+OGC的形式进行内容运营，确保内容的不断产出，并建立「内容采集 – 审核 – 结构化 – 推送 – 召回」的内容链路。并针对新老用户，分别明确运营的干预程度和基础排序规则，在保证优质内容触达用户的前提下，引导用户完成对社区的探索。主要内容形式包括：

• 培训课程、认证；
• 使用文档、手册、案例、问答；
• 白皮书、图谱；
• 话题讨论。

在确保内容运营后，明确社区形态是问答类（技术产品答疑）还是阅读类（技术学习），内容强调人（专家、大咖）还是强调内容。甚至需要明确浏览过程哪些互动形式需要进行强引导，相关页面是否要进行关联推荐。

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

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

（2）内容分发运营

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

• 专栏类：技术Blog、外部社区的专栏；
• 自媒体 ：公众号、简书、头条号；
• 外部投稿：技术媒体投稿、社区投稿；
• 问答：知乎类大众社区问答、思否等专业社群问答 。