开发者关系 像个开发者一样思考

定义“开发者关系”

2020-07-09
开发者关系

越来越多的开发者服务公司投入重金,围绕自己公司产品、服务、API等在组建自己公司的DevRel团队。

但是,不同的公司对DevRel有着不同的理解:有的雇佣专职 “技术推广的工程师(Developer Advocate)”;有的雇佣 “技术布道师(Developer Evangelists)”; 有的认为DevRel就是“针对开发者的市场行为”;也有人把 DevRel 当作获取产品的反馈、推广产品成功的关键。如何来判断什么样的岗位角色、活动形式对你的公司是最合适的呢?不同的岗位称呼到底有什么区别呢?

“开发者关系”对于公司来说到底意味着什么呢?这取决于公司对目标是什么。为了说明情况,让我们来引用一下Google和Twilio的DevRel部门的使命,但是,注意一条简短的语句未必能够呈现DevRel团队实际做的全部事情。

Google

开发者关系的角色,是通过双向沟通开发者和公司的平台产品、工程、设计,来创造一个充满活力的第三方开发者生态系统。

Twilio

我们的工作是激励和帮助开发者建立下一代令人震惊的应用。这意味着要理解他们正在努力想要做什么,给他们指明工具并进行培训,以及帮助他们取得成功。

Google 使用“the interface between”词眼。表明DevRel期望的是建立产品决策者和开发者(即产品使用者)间的一个双向沟通桥梁。Twilio的态度表明DevRel更像是一个单向的“教育的角色”,帮助开发者使用Twilio产品。

Michael Mahemoff最近写了一篇Developer Relations: A Five-Level Maturity Model. 在这篇文章中他阐述了一个公司DevRel部门发展的不同阶段。从没有DevRel部门到可以完全量化策略的价值。

针对在“如何制定本公司的DevRel策略” 的情境下,我需要对Michael的定义做些调整:

  1. 无(None),公司内部没有支持开发者 或 收集开发者反馈的机制;
  2. 不正规(Informal),由公司其他部门 承担 DevRel 的部分角色,PR 负责公司品牌的提升、BD 承担部分支持开发者任务,而产品的专职开发者却也要承担部分社区演讲;
  3. 合作伙伴(Partnerships),和珍贵的合作伙伴间的关系,通常比较隐蔽 (通常是大公司、拥有足够资源来构建新的产品特性);
  4. 布道师(Evangelism),通过会议、合作伙伴、在线媒体来大规模提升、支持公司产品;
  5. 技术推广工程师(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):

  1. 认知度(Awareness)产品平台的认知度
  2. 获取 (Acquisition)注册量、下载量、安装量
  3. 激活 (Activation)平台使用的活跃度
  4. 留存 (Retention)持续使用平台、使用新的特性
  5. 盈利 (Revenue)为平台的付费
  6. 自传播(Referral)把平台告诉其他人
  7. 产品(Product)涉及到构建和收集产品的反馈

在DevRel日常运营中有各式各样的活动形式。每种类型的活动都与之对应一个或多个 DevRel的指标,从而实现一个或多个AAARRRP目标,比如:

  写文档(参考案例、入门指南等)   获取、激活、产品  
  库开发   激活、产品  
  快速启动应用   激活、产品  
  博客文章(教程、黑科技、思想领导力等)   认知度、获取、激活、留存  
  网络研讨会   认知度、获取、激活、留存  
  活动赞助(Meetup赞助商、大会展位等)   认知度、获取  
  演讲(Meetup、大会、社团等)   认知度、获取  
  产品支持(Zendesk、StackOverflow、其他论坛等)   激活、留存、产品  
  售前技术讨论(电话、邮件、支持等)   获取、激活  
  专用论坛(Google Groups、Discourse等)   激活、留存  
  Alpha/Beta程序   留存、产品  
  办公时间   激活、留存  
  收集开发者反馈   留存、产品  
  帮助公司招聘   认知度  

成功保证这些行为的结果将对开发者有着积极意义,公司的声誉将得到提升。这样的话有提高“自传播”的可能性。但是,开发者和公司间这样的关系,需要花时间来构建。

盈利:显然从上述的行为中省略了。盈利取决于开发者使用产品的程度。因此,非常依赖产品价格结构。因此,盈利,不能简单的添加到上述的列表中,但是,可以确定的是:暂时不考虑盈利的话,可以让你更加专注于很有可能带来大量的ROI的活动及目标开发者。

尽管我个人不认可通过职位Title来定义一个人,而是,职位Title反应了公司或者其他开发者对于他在DevRel团队中的角色定位。

因此,基于常见的职位Title,来看看不同的角色参与什么样的活动?

技术推广工程师(Developer Advocates):承担上述大部分职责作为DevRel工作的一部分,尤其是与产品或留存相关的职责;

技术布道师(Developer Evangelists):也许更加专注于用户的获取相关的活动,比如:写文档、发布博客、赞助活动、演讲。查看更多和“认知度”和获取相关的活动。

| 总结

如何来定义DevRel ? 以及那种方式是对你公司最适合?下面是我的建议:

  1. 根据 AAARRRP 模型 来制定出你对 DevRel 团队期望的目标;
  2. 选择与这些目标最匹配的活动形式;
  3. 根据这些活动形式,可以确定招募技术推广工程师(Developer Advocates)还是技术布道师(Developer Evangelists);

作为另外一种帮助我自己的方式,或至少是建议。针对这种持续的关于职位Title的争论,我创建了一个DevRelOMeter的项目——根据你期望DevRel团队开展的活动类型,会建议你进行技术布道还是技术推广?

| DevRelOMeter

您是否在参与或者考虑参与到开发者布道这个事业当中来呢?

https://leggetter.github.io/devrelometer/

作者:Phil Leggetter

原文:Defining Developer Relations

编译:Jack Jin

转载请注明:开发者关系 »


Similar Posts

Content