国内很多公司比较多认同的是这样一些职位：开发者社区运营、技术品牌运营、开发者市场运营等，这些都是偏运营的职位。在挺多的职位描述中，往往只需要比较少的工作经验。

在国外也有很多公司正在寻找 DevRel 方面的人才，他们对这个角色的意义和价值也不尽相同，具有明显的差异性。因此这个职位的定位其实和公司的目标是紧密相关的。

Google 的定义

Developer Relations’ role is to create a vibrant ecosystem of 3rd party developers, by being the interface between those developers and your platform’s product, engineering, and design teams. (From)¹ 中文翻译：开发者关系的作用是为第三方开发者创建一个充满活力生态系统，成为开发者和你们公司平台的产品经理、工程师和设计团队之间的接口。

Twilio 的定义

Our job is to inspire and equip developers to build the next generation of amazing applications. This means understanding what they are trying to do, pointing them to tools and training and generally helping them be successful. (From)² 中文翻译：我们的工作是激励和装备开发人员建立下一代令人惊叹的应用程序。这意味着理解他们正在努力做什么，为他们指出工具和培训，并普遍地帮助他们取得成功。

以上两种定义的区别是：这个职位在Google偏重于双向接口，在Twilio偏向于单向对外赋能。

Michael Mahemoff 曾经写过一篇博客文章《Developer Relations: A Five-Level Maturity Model》

注：在以上的表格中，每一行最后一句话，在方括号中的内容，是我添加的观点。参考资料：

• Developer Advocate versus Technical Evangelist; When names change the tone ³
• Developer Relations: A Five-Level Maturity Model ⁴

在以上的表格中，我们可以清晰的看到 DevRel 不同的风格或者做法，任何公司根据他们当前的现状和目标，而选择了其中的某一种，然后逐渐演变。如果一个公司希望把重点放在推广和宣传上，或者可能通过参与较少的活动来降低成本，那么他们可以决定把重点放在 Evangelism 宣传上。如果一家公司优先考虑从开发者那里收集产品反馈，那么 Advocacy 宣传可能是更好的方法。

开发者关系有可能帮助到企业的许多领域，所以你在业务拓展（技术/平台）方面确定的战略和目标很重要。因此可以使用 Dave McClure 的 AARRR 指标可以作为一个基础，从而证明开发者关系是怎样帮助到业务拓展的。

Developer Relations 的定义

DevRel, or developer relations, is a process for nurturing mutually beneficial relationships between organisations and software developers. (From)⁵ 中文翻译：‘开发者关系’是一个培养组织和软件开发者之间互利关系的过程。

换句话说，这是一个战略和战术的集合，帮助公司与软件工程师更好地合作。开发者关系团队到底做什么，为什么要做，取决于他们的组织需要是什么，目标是什么。

为什么要做开发者关系？

从不同公司的角度，所追求的 DevRel 的战略动机可能有很大的不同。例如，X公司做DevRel可能是为了推动其API的采用，而Y公司的团队可能是为了提高公司雇用软件工程师的机会。

这些动机的差异导致了不同DevRel战略、战术的采用，和对DevRel工作成果成功的定义。事实上，理解你的组织为什么需要开发者关系，是你需要知道的关键，而不是其它任何DevRel的工作事项。它可以帮助你理解DevRel该做什么，需要让谁参与，以及如何度量你的投入。

那么，开发者关系的战略原因是什么？今天，大多数开发者关系计划都集中在鼓励采用产品/技术方面，如API。然而，至少还有其他五个常见的原因。包括采用，大多数公司投资于DevRel是因为他们想影响下面的各个方面：

• 采用：该组织希望更多的开发者使用他们的产品。
• 产品构建：该组织依靠开发者社区来建设他们的（可能是开源的）技术。
• 产品与市场的契合：了解开发者的需求和愿望对产品的成功是必要的。
• 开发者支持：提供教育、工具和基础设施，以便开发者在其雇主采用产品后使用该产品。
• 开发者认知：该组织认为当前的开发者认知是其产品成功的潜在障碍。
• 招聘：该组织希望改善其雇主品牌，以便对他们需要雇用的开发者更具吸引力。

在实践中，组织的DevRel活动的是为了满足以上这些战略驱动力的某种组合。例如，一个需要推动采用的公司，很可能也想确保其产品具有良好的市场适应性。

尽管公司在做开发者关系时有各种不同的原因和动机，但不论他们怎样做，都是基于一套类似的技能和策略，我们称之为开发者关系的四个支柱。

“DevRel的四大支柱”

就像市场营销不全是广告一样，开发者关系也不只是建立知名度。虽然不是每个人都同意这个命名，但DevRel有四个互补的领域。

• 开发者营销｜Developer marketing：理解产品的目标开发者是谁，然后确保他们有信息和工具来做决定（是否使用你们的产品）。
  • 内容创作、投放和分发
  • 活动Event的赞助、演讲、出席、组织
  • 广告和其他付费宣传活动
  • 竞争和市场研究
• 开发者支持｜Developer enablement：提供开发者成功使用产品所需的一切。
  • 开发者教育：文档、教程、视频、指南
  • 开发者体验：API设计、SDK、参考应用程序、示例代码
  • 支持和帮助开发者取得成功
• 开发者布道｜Developer advocacy：作为开发者和组织之间的支持者和渠道。
  • 作为技术品牌的公众形象
  • 在社交媒体、论坛和活动中与开发者直接互动
  • 在活动（会议、meetup）中发言/分享
  • Twitch线上直播、视频制作、播客制作
  • 充当从开发者到公司的反馈回路
  • 创建宣传和教育材料
• 开发者社区｜Developer community：创建和维护一个可持续的环境，使开发者
  • 提供并主持论坛、聊天和其他渠道，为开发者提供直接交流的平台。
  • 实施冠军计划（类似于微软的MVP，Google的GED，AWS的Hero等）和其他激励/奖励参与者的形式
  • 设定互动的标准和基调（社区行为准则）
  • 创建一个可持续的流程和环境，使人们能够满足他们的需求，为一个共同的目标而努力。

什么是开发者市场营销（developer marketing）？

开发者营销–也被称为B2D，或企业对开发者的市场营销，是与软件开发者受众打交道的市场营销方式。开发人员是一种不同的受众，根据2020年的官方统计数据，中国有七百万软件从业人员。对这么多人进行归纳总结是很难的。即便如此，开发构建软件的工作其实也产生了一些共性的特征，这些特征对于任何想向软件开发者推销的人来说都是很重要的。⁶

软件开发者们实际上倾向于：

• 希望得到事实，而非完美的、用于市场宣传的产品推广信息
• 在他们选择某一项技术时，会把他们的声誉风险也绑定在了一起
• 拥有深厚的专业知识，可能比产品/技术/平台的厂商更了解他们的细分市场
• 从非主流的来源获取信息
• 重视实践经验，而非豪言壮语的保证
• 在技术供应商的选择方面，产生直接的影响

这影响到信息传递、渠道、语气、战术组合，以及市场营销人员可能做的几乎所有其他事情。

B2D 的产品是不同的

这不只是因为开发者是一个不同类型的受众。以开发者为目标产品在这一点上是不同的。

• 要了解他们的能力，以及所需要的专业知识
• 他们的观点可以在相对较短的时间内得到证明
• 购买者往往是用户
• 失败到产品可以迅速的升级到影响数百万人

综合来看，根据开发者目标产品的特殊性，根据软件开发者的需求的不同，我们需要专门的开发者市场营销战略和策略。

但是，开发人员不讨厌市场营销吗？不，开发者并不讨厌营销。像所有人一样，开发者不喜欢很差劲的市场营销。

有时，当非开发者试图谈论一项针对开发者有好处的技术，或者尝试理解开发者常见的情况时，他们就会暴露，其实对开发者根本缺乏理解。而这并不是不可逾越的。任何人都可以学习，第一步是认知到开发者受众们都有其特定的需求。

这一点很重要，因为开发者在研究产品时要寻找值得信赖的信息。如果你所传递的信息感觉"不对劲"，也许是因为它掩盖了一些关键的细节，那么就很难相信你所提供的产品。

构建开发者市场营销策略

构建B2D的市场营销策略与构建任何营销策略都很相似。从目标开始，然后制定如何达到目标的方案。

更详细地说，建立开发者商营销战略的阶段如下：

1. 广泛的了解公司的战略，并确定服务于该战略服务的北极星目标。
2. 通过对现状的情景分析来评估你的起点。
3. 对你的开发者受众进行细分，然后决定哪些是目标人群。
4. 开展一些用户调研，来了解这些开发者。
5. 开发针对性的信息，用于和这些开发者对话，表达他们的需求和你的解决方案。
6. 创建战略方案，帮助你的目标开发者经历你所设计的用户漏斗旅程。
7. 定义衡量方案成功的指标，并反馈到你的整体开发者营销目标。

在深入理解 DevRel 前，希望现在大家已经对开发者市场营销有了大概的理解，其实他们是紧密相关的。

从 AARRR 指标的角度看 DevRel 的工作内容

Phil Leggetter 将 AARRR 【客户生命周期：成功获客的5个步骤】做了两头的扩展，变成了 AAARRRP， 在头尾分别增加了新的’A’和‘P’。下面用 AAARRRP 7步法来勾勒出 DevRel 可能会影响到的日常工作内容。

1. Awareness ｜宣传 – 对平台/技术/产品和它的功能的认识
2. Acquisition ｜获取 – 注册/下载/安装
3. Activation ｜激活 – 在自己开发的应用中积极使用该平台/技术/产品
4. Retention ｜保留 – 持续使用和跟踪该平台/技术/产品，使用新的/附加的功能，并在新的应用程序中继续使用。
5. Revenue ｜收入 – 付费使用该平台/技术/产品，或者从开源软件版本用户提升为付费版客户。
6. Referral ｜推荐 – 告诉别人这个平台的情况，分享自己踩过的坑和技术。
7. Product/platform ｜产品/平台 – 用户参与上游厂商的产品构建协作，并提供对平台/产品和技术的反馈。

有一系列广泛而多样的活动可以归入开发者关系DevRel的日常工作中。这些活动中的每一项都可能与实现AAARRRP目标的计划的一个或多个属性相关。

• 编写文档（获取、激活、产品）。
  • 参考资料
  • 指南（How-to）
• 库开发（激活，产品）
• 快速上手的杨例应用程序（激活、产品）
• 博客文章（认知、获取、激活、保留）
  • 教程
  • 实用技巧
  • 思路指导
• 网络研讨会 (认知、获取、激活、保留)
• 活动赞助（认知、获取）。
  • Meetup 赞助
  • 会议展位
• 分享演讲（认知、获取）
  • 聚会
  • 会议
  • 社区/社团
• 支持（激活、保留、产品）
  • 用户支持系统，如：Zendesk
  • StackOverflow 回答问题
  • 公司和第三方论坛，如：Discuss等
• 售前技术讨论（收入、激活）。
  • 呼叫 Calls
  • 电子邮件
  • 技术支持
• 专用论坛，如Google Groups或Discourse，如SmartThings社区（激活、保留）。
• Alpha/Beta 产品试用计划（保留、产品）
• 办公时间 Office Hours（激活、保留）。
• 获取开发者的反馈（保留、产品）
• 帮助公司招聘（宣传）。

成功地开展这些活动的结果是：对某受众产生积极的影响，并与之建立关系，对公司的形象和公司本身的可信度将提升。这可以增加被推荐的可能性。但这些建立这些关系是需要时间的。

‘商业收入’在上述活动中被明显的遗漏了。收入可能与开发者使用产品的水平有关。它还依赖于产品的定价结构。所以，还这不能笼统地纳入上述活动清单，但它肯定可以帮助你专注于可能提供更大投资回报的活动或目标中的开发人员。

那么，根据最常见的工作头衔，这些不同的角色会参加什么活动？

• 开发者布道师 Developer advocate ： 可以进行上述所有的活动，作为其开发者关系计划的一部分。特别是那些标有产品或保留的活动。
• 开发者代言人 Developer evangelist ： 可能会更多地关注引导新用户的活动，如文档、博客文章、活动赞助和分享演讲。请看那些有助于认识和获取的活动。

好了现在你可以使用‘DevRelOMeter’下面这个工具来测试一下，你自己的日常工作中都从事了以上那些工作，包括主动和被动的，看看你的工作性质是偏 Advocate 还是 Evangelist。

点此进入测试页面

下面再从Google专家的角度看看DevRel这件事。下面转载 Reto Meier 【Developer Advocate @ Google, software engineer, and author of “Professional Android” series from Wrox. All opinions are my own.】到两篇文章的部分内容：

1. Why Do We Pay These People Anyway?
2. The Core Competencies of Developer Relations

Reto Meier是从谷歌的Android的生态系统方向考虑和描述DevRel的，Google擅长通过构建平台的方式在全球的范围规模化推广自己原创产品和技术。这有其特殊性，在阅读下面内容的时候，请注意保持第三方的视角。在后需的文字中，读者需要通过上下文辨别‘开发者’，有时候是厂商原厂开发者，有时候是第三方开发者。

我们为什么要付给这些人钱？

在我看来，建立一个平台的决定是基于如何最好地服务你的用户。

一个健康的生态系统会提升你的平台，通过填补你自己没有准备、不能或不愿意填补的空白，提供比你的产品更丰富的产品。你牺牲了市场上的独占性，但作为交换，你为自己和他人创造了更大的机会。你创造了一个更大的馅饼，以换取将其中切的较小的一片。

如果一个平台能从与日俱增的用户采用中获益，那么它就需要用产品和服务来吸引这些用户；构建一个第三方开发者的生态系统就是这些产品和服务的发展方式。

生态系统还为其他僵化的垂直结合到产品提供了灵活性。安卓和iOS都是应用开发者的平台，因此，对于每个设备的使用价值来说，只限于由谷歌或苹果为它们编写软件，倒不如开放给所有开发者能加有意义。安卓则更进一步，构建了一个对于所有设备制造商开放的生态系统。

在不同的规模上，谷歌地图API创造了一个由数百万个应用程序和网站所组成的生态系统，每一个App都有一个嵌入的谷歌地图。这种开放第三方实施开发方式增加了谷歌地图的使用度，这远远超过了谷歌自己可以构建的规模。

在实践中，创建开发者生态系统的基本目标是复杂而交织的。对平台拥有者来说，它为他们贡献的第一方App和服务到受众增加了，他们可以通过向开发者收取使用平台的费用，或在生态系统内再次分发来实现盈利。一个平台也可以是对冲对竞争对手的屏障，或刺激创新的尝试。考虑到创建一个平台和生态系统的成本，最有可能的目标是这些因素的组合。

把一个产品变成一个平台并不总是合理的。这样做有可能使竞争对手从你自己的产品中吸纳用户，或者使你的产品的用户体验下降。

一个健康的生态系统是可自我持续发展，且获利中立的，第三方开发者的成功会帮助你的用户并支持你的目标，反之亦然。

开发者关系是什么？

Developer Relations’ role is to create a vibrant ecosystem of 3rd party developers, by being the interface between those developers and your platform’s product, engineering, and design teams. 中文翻译：开发者关系的作用是为第三方开发者创建一个充满活力生态系统，成为开发者和你们公司平台的产品经理、工程师和设计团队之间的接口。

为了确保界面（接口）的高保真度，开发者关系部必须由工程师组成；这些工程师将同样能够在核心平台或第三方开发者的角色中工作。

除了建立认知，开发者关系还负责创作，第三方开发者使用你的平台构建伟大产品所需的一切。从收集开发者提出的bug和功能请求、执行早期访问计划（beta和试用）、编写文档、创建样例程序、编写教程和技术视频、在会议上发言、以及在论坛和Stack Overflow上回答问题，等等的一切。

他们还帮助应用平台的开发者的需求，通过与社区接触–通过社交媒体在线，以及亲自参与到Meetup和会议中–并在你的产品和工程团队中充当社区开发者的代言人。这确保了平台的开发与你的生态系统的需求的一致性。

最终，开发者关系负责你的平台的开发者体验。这将帮助开发者打造更好的产品，从而创造更好的用户体验，从而能构建更成功的应用程序，以及更成功的生态系统–这反过来又鼓励开发者打造更好的应用程序。

“开发者关系的良性循环”

在小公司（或新生产品），开发者关系任务往往是产品和工程团队的责任。最终你的平台会成熟到需要有工程师来全职专注于这些活动，并扩大他们的工作范围，包括更复杂的项目，如培训和社区参与，并通过开发更丰富的场景来支持外部互动，并包括多个平台和API。

开发人员需要信任你的DevRel团队；要做到这一点，他们必须是正统的。

开发者关系是你的开发者产品的公众形象–第三方开发者的主要信息来源，以及与他们的互动。将这些互动转化为一种可信赖的关系至关重要。

开发者关系团队的可信度将由厂商所产生的代码的质量，以及他们所提供的建议来衡量。最终，平台本身的质量将通过你的开发者关系团队制作的材料的质量、全面性和可用性进行评估。

第三方开发人员必须能够信任你的DevRel团队，以及所提供的代码、技术答案、最佳实践和培训，将其作为开发者信息的最佳、最准确和最正规的来源。

你的开发者关系团队也必须得到你的内部工程团队的信任，确信他们可以准确的表达第三方开发者的想法和体验，给予坦率的技术反馈，并面向开发者受众们诚实地代言平台。

他们会因为是平台提供方原厂公司的代言人而轻易获得一些最初的信任，但为了产生真正的影响，他们还必须用独立于他们所代表的公司的方式，通过其展现的正统性建立与他人的信任。

开发者关系并不是市场营销、业务发展BD或销售–这些都不在工程团队。

• 开发者市场：与开发者关系DevRel一起工作，帮助提高对市场内容的认知，提供市场研究，支持开发者活动，并创造统一的品牌形象。
• 业务发展-BD团队与商业决策者合作，他们需要的不仅仅是良好的开发者体验，以说服他们投入资源在你公司的平台上构建应用。BD通常与少数知名的合作伙伴合作，他们各自的成功可以加速你的平台在用户中的采用。一旦做出承诺，开发者关系部经常与相应的工程团队合作，以确保成功的合作。
• 销售团队通常用于开发那些直接为为平台消费的客户，例如云或广告平台。销售团队有时会与销售工程师配对，他们的技术同行，能够与客户的工程团队进行1对1的合作，以支持销售或基于商业关系。

注：以上是源于Google的组织者结构，一个成熟的大型商业组织，内部团队分工和配合都非常明确。

一个繁荣的开发者生态系统需要一个由工程师组成的值得信赖的开发者关系团队，他们是第三方开发者和构建底层平台的工程和产品团队之间的接口。

“开发者关系的持续的接口循环”

图片翻译（从左到右，从上到下的顺序）：

• 平台产品和工程
• 平台、API和SDK的更新
• 开发者的反馈
• 开发者关系
• 认知和激励
• 开发者资源
• 开发者反馈
• 开发者观点
• 第三方开发者

开发者关系是真相的官方来源，既适用于寻找文档、最佳实践和培训的第三方开发者，也适用于需要了解第三方开发者的想法和体验的内部工程团队，并获得有关其开发者产品的坦率技术反馈。

在Reto Meier看来，以下是建立一个能够产生真正积极影响的开发者关系团队所需的最重要的价值和能力。

• 他们需要是合格的工程师 ： 工程师们并不信任伪开发者，所以开发者关系团队需要由合格的开发者组成。即使如此，他们也不会轻易相信任何工程师–我们DevRel需要证明自己。
• 他们需要成为优秀的沟通者 ： 你的开发者关系团队需要创造出能解决问题的材料，同时也要有启发性、趣味性和娱乐性。
• 他们需要有多样性 ： 开发者关系的目标是与尽可能多的开发者受众合作，创建一个充满合格工程师的多元化开发者关系团队，使其包容更多的受众。
• 他们不可能销售任何东西 ： 开发者关系部不能成为销售活动的拉拉队，或是伪装的销售人员。他们应该让马认识到水的存在，展示水对它的帮助，引导它去喝水，并让水尽可能地容易喝。
• 他们需要感受开发者的痛苦 ： 如果一个好的开发者关系团队不相信他们能够诚实地推广和宣传一个产品，他们就不会成为它的代言人。
• 他们需要去倾听和响应。
• 他们需要成为多产的人 ： 开发者关系是你对你的开发者受众说话的声音–重要的是，他们经常发声，而且声音很大。
• 他们需要规模化地工作 ： 想想开发者关系团队需要面向全球开发者。

一个有效的开发者关系团队是由一群具有超强沟通能力的合格的工程师所组成的，他们并不会推销任何东西，而会与他们的受众心心相印–他们不断倾听和回应。他们必须以一种能够规模化到全球千万级万开发者受众的方式来做这一切。