定义“开发者关系”
越来越多的开发者服务公司投入重金，围绕自己公司产品、服务、API等在组建自己公司的DevRel团队。
但是，不同的公司对DevRel有着不同的理解：有的雇佣专职 “技术推广的工程师（Developer Advocate）”；有的雇佣 “技术布道师（Developer Evangelists）”; 有的认为DevRel就是“针对开发者的市场行为”；也有人把 DevRel 当作获取产品的反馈、推广产品成功的关键。如何来判断什么样的岗位角色、活动形式对你的公司是最合适的呢？不同的岗位称呼到底有什么区别呢？
“开发者关系”对于公司来说到底意味着什么呢？这取决于公司对目标是什么。为了说明情况，让我们来引用一下Google和Twilio的DevRel部门的使命，但是，注意一条简短的语句未必能够呈现DevRel团队实际做的全部事情。
开发者关系的角色，是通过双向沟通开发者和公司的平台产品、工程、设计，来创造一个充满活力的第三方开发者生态系统。
Twilio
我们的工作是激励和帮助开发者建立下一代令人震惊的应用。这意味着要理解他们正在努力想要做什么，给他们指明工具并进行培训，以及帮助他们取得成功。
Google 使用“the interface between”词眼。表明DevRel期望的是建立产品决策者和开发者（即产品使用者）间的一个双向沟通桥梁。Twilio的态度表明DevRel更像是一个单向的“教育的角色”，帮助开发者使用Twilio产品。
Michael Mahemoff最近写了一篇Developer Relations: A Five-Level Maturity Model. 在这篇文章中他阐述了一个公司DevRel部门发展的不同阶段。从没有DevRel部门到可以完全量化策略的价值。
针对在“如何制定本公司的DevRel策略” 的情境下，我需要对Michael的定义做些调整：
无（None），公司内部没有支持开发者 或 收集开发者反馈的机制；
不正规（Informal），由公司其他部门 承担 DevRel 的部分角色，PR 负责公司品牌的提升、BD 承担部分支持开发者任务，而产品的专职开发者却也要承担部分社区演讲；
合作伙伴（Partnerships），和珍贵的合作伙伴间的关系，通常比较隐蔽 （通常是大公司、拥有足够资源来构建新的产品特性）；
布道师（Evangelism），通过会议、合作伙伴、在线媒体来大规模提升、支持公司产品；
技术推广工程师（Advocacy），一种双向的关系，不仅为参与产品的开发，也鼓励外部开发者使用本公司产品、收集bug反馈及新特性请求。同时，开发支持工具来提升开发者的使用体验；
根据以上分析，总结：Twilio是以“技术布道师”的方式来运营DevRel，而Google是“技术推广工程师”的方式。
Michael指明：DevRel正确的运营方法取决于公司对于DevRel项目的目标。比如，如果一家公司仅仅是期望品牌知名度的提升、或者参加少量的活动来减少开销，那么该公司应该采取“技术布道”的方式来运营DevRel。如果优先考虑从第三方开发者收集产品的使用反馈的话，采用“技术推广”的方式也许效果最好。
总之，投资DevRel对于公司的各个业务都有促进作用。所以，你策略的目标是什么，就显得尤为重要了。Dave McClure的AARRR模型可以用来作为指导DevRel策略的基石。
然而，我建议我们稍做两个修改：
因为DevRel可以增加开发者们对一个产品的认知度，根据传统的营销习惯，在AARRR缩写前再增加一个‘A’；
在DevRel团队日常活动中可能会涉及到开发者们对产品的反馈，为了表明这一点在AARRR缩写后面增加一个‘P’；
这样话就产生一个新的模型：AAARRRP模型。与其仅仅把这个当作DevRel指标，不如把它们当作你DevRel项目的潜在目标（虽然‘如何来度量这些指标’也需要去考虑的，详见：What's the ROI of Developer Relations）:
认知度（Awareness）产品平台的认知度
获取 （Acquisition）注册量、下载量、安装量
激活 （Activation）平台使用的活跃度
留存 （Retention）持续使用平台、使用新的特性
盈利 （Revenue）为平台的付费
自传播（Referral）把平台告诉其他人
产品（Product）涉及到构建和收集产品的反馈
在DevRel日常运营中有各式各样的活动形式。每种类型的活动都与之对应一个或多个 DevRel的指标，从而实现一个或多个AAARRRP目标，比如：
成功保证这些行为的结果将对开发者有着积极意义，公司的声誉将得到提升。这样的话有提高“自传播”的可能性。但是，开发者和公司间这样的关系，需要花时间来构建。
盈利：显然从上述的行为中省略了。盈利取决于开发者使用产品的程度。因此，非常依赖产品价格结构。因此，盈利，不能简单的添加到上述的列表中，但是，可以确定的是：暂时不考虑盈利的话，可以让你更加专注于很有可能带来大量的ROI的活动及目标开发者。
尽管我个人不认可通过职位Title来定义一个人，而是，职位Title反应了公司或者其他开发者对于他在DevRel团队中的角色定位。
因此，基于常见的职位Title，来看看不同的角色参与什么样的活动？
技术推广工程师（Developer Advocates）：承担上述大部分职责作为DevRel工作的一部分，尤其是与产品或留存相关的职责；
技术布道师（Developer Evangelists）：也许更加专注于用户的获取相关的活动，比如：写文档、发布博客、赞助活动、演讲。查看更多和“认知度”和获取相关的活动。
| 总结
如何来定义DevRel ? 以及那种方式是对你公司最适合？下面是我的建议：
根据 AAARRRP 模型 来制定出你对 DevRel 团队期望的目标；
选择与这些目标最匹配的活动形式；
根据这些活动形式，可以确定招募技术推广工程师（Developer Advocates）还是技术布道师（Developer Evangelists）；
作为另外一种帮助我自己的方式，或至少是建议。针对这种持续的关于职位Title的争论，我创建了一个DevRelOMeter的项目——根据你期望DevRel团队开展的活动类型，会建议你进行技术布道还是技术推广？
| DevRelOMeter
您是否在参与或者考虑参与到开发者布道这个事业当中来呢？
https://leggetter.github.io/devrelometer/
作者：Phil Leggetter
编译：Jack Jin
订阅号：开发者关系
版权声明: 本文为 InfoQ 作者【开发者关系】的原创文章。
原文链接:【http://xie.infoq.cn/article/507ac51ed4a50dae21e4a0e56】。文章转载请联系作者。
订阅号：开发者关系 2018.08.20 加入
还未添加个人简介
评论