本文开发者作为互联网企业中不可或缺的重要群体，一直是ToB厂商（比如PaaS、IaaS）所关注的重点。那今天来说一说如果将开发者社区作为产品进行运营，我们到底该怎么做（部分内容将以云原生作为示例）。

由于使用相关技术产品或服务的企业用户，大多具有企业属性且内部包含多个角色属性。想要构建完整开发者用户画像，就需要对决策链上所有相关角色进行调研。因此，调研需要包含行业属性、企业属性、角色属性这几个主要维度：

1. 行业属性：如不同行业的市场结构、运作模式/规律。通过行业特征，了解行业现状和发展趋势；以云计算举例，银行业的上云需求一定会比房地产更强，且需求更严苛 、预算更充足。
2. 企业属性：如企业规模、收入规模、活跃用户、使用评价等。通过企业特征，了解目标开发者的业务需求现状与企业发展的痛点；
3. 角色属性：如决策者（CIO、CTO）、中间层（技术专家、研发总监）使用者（一线员工），决策者、中间层、使用者关注点和需求存在很大差异，明确其间的分水岭；
4. 个人属性：如年龄、技能等需求，更多是关于马斯洛理论上层相关的问题。

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

1. 定性分析：通过访谈、问卷等方式，结合行业研究报告、过往经验等手段，挖掘开发者用户的行为动机、需求、变化规律；
2. 定量分析：基于已有数据与行业Benchmark的研究，对开发者用户进行各项指标、特性、相互关系的对比与分析。

在实际操作过程中，于小规模核心高贡献用户进行访谈。于大规模普通用户通过调查问卷形式完成调研。在一度猛如虎的操作后，我们可以勾勒一个相对完整的用户画像。通过标红的Key Messagge，我们可以看到相对清楚、强烈的开发者用户特征（这里引用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小时。

从上述描述，我们总结可以看到开发者群体的行业、地域属性相对集中且普遍学历、认知较高；学习欲望很强且有一定参与活动的兴趣。虽然会参加社区或者开源项目，但是并没有赚到钱。

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

对于开发者社区，我们是这样定义的：「连接厂商与开发者，围绕对某种技术的共性需求，通过双方产生内容形成互动的（线上/线下）商业价值孵化平台」。所以，我们可以抓住其中的几个重点：

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

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

比如开发者想要通过云原生社区了解DevOps 相关的自动化发布管道、CI工具以及如何实现开发、运维协同合作。那么，他就会选择对应的垂直开发者社区进行查找相关资料。

（2）双方产生内容

社区的基础是内容，内容类别决定了社区氛围与运营调性。在构建完整结构化内容后，结合用户和平台属性，推荐分发相应内容，完成内容对用户的触达。

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

比如阿里云原生开发者社区提供了完善的云原生技术公开课，帮助用户理解云原生知识。用户获取知识的同时可以结合课程展开讨论或分享自己的最佳实践，与同业者产生互动。

（3）互动

用户在社区内产生的UGC、评论、转发等互动行为，都具备着可量化、可商机培育的价值。通过互动频率、互动质量评估用户粘性，也进一步验证社区搭建的核心目的是否与开发者需求相符合。

通过内容互动引导完成开发者完成「认知 – 用户 – 客户」的角色转化，并增加开发者对社区依赖。借助场景化社交，让用户间形成相对稳固的社交链。比如对热门技术话题的讨论各种形式的 Meet-up，杰出贡献者奖励公示、贡献排行榜、赋予大使头衔等等。

（4）商业价值孵化

ToB厂商做了很多事情，虽然会强调推动行业技术发展，但其实核心目的始终是卖货挣钱，开发者社区其实也是手段之一。利用用户对社区及内容的认可，实现商机线索的获取与孵化甚至是售后客户的Upsell。

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

在列举所需资源前，我们需要明确社区的运营目的。这样才能更好的去协调公司内外部资源，常见目的主要涵盖两个维度：产品层面、营销层面，具体包括以下几个方面：

• 产品品牌传播：提高厂商品牌在开发者群体中的认知度、美誉度，实现技术、产品普及；
• 建立用户流量池：为产品拉新、转化提供流量池，为产品测试、市场反馈提供载体支持；
• 商业价值孵化：完成从认知到使用用户到付费客户的转化；
• 产品服务：替代传统帮助文档、工单系统，降低售后服务成本，提升售前服务体验；
• 建立社区生态：优化技术、完备场景、整合资源，通过外部开发者完善厂商现有产品；
• 学习平台：作为技术布道者，帮助更多大众认知深入了解、学习相关技术领域。

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

在明确目的后，那我们运营的人群是谁呢？决策链上各个角色对于商业价值孵化又有什么意义呢？

• 决策层：企业CTO/CIO，信息化VP等技术产品采买决策人；
• 意见领袖（KOL）：行业技术大牛，其观点对其他开发者甚至决策层有较大影响，如各类协会大佬、技术社区活跃专家、系列课程讲师、基金会大使、某领域布道师；
• 选型者、评估者：企业中的技术/研发/运维总监、系统架构师等对产品选型具有评估权、推荐权的用户群体；
• 一线使用者：资深程序员、产品采买后的直接使用者；
• 大众认知：普通开发者，听闻过相关产品、技术，有兴趣了解相关领域。

对于日常运营而言，商业价值随着上文介绍顺序而逐渐降低。我们希望通过各种大型活动将业务价值信息和品牌力精准传递给决策层，影响决策层决策。对于意见领袖，希望能够帮助我们有效覆盖传统媒体渠道所无法触达的相关受众，并融合更多外部观点。对于意见领袖，虽然BD难度相对较大，但合作价值巨大。

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