写点什么

定义“开发者关系”

发布于: 2020 年 08 月 17 日
定义“开发者关系”

越来越多的开发者服务公司投入重金,围绕自己公司产品、服务、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),公司内部没有支持开发者 或 收集开发者反馈的机制;



  1. 不正规(Informal),由公司其他部门 承担 DevRel 的部分角色,PR 负责公司品牌的提升、BD 承担部分支持开发者任务,而产品的专职开发者却也要承担部分社区演讲;



  1. 合作伙伴(Partnerships),和珍贵的合作伙伴间的关系,通常比较隐蔽 (通常是大公司、拥有足够资源来构建新的产品特性);



  1. 布道师(Evangelism),通过会议、合作伙伴、在线媒体来大规模提升、支持公司产品;



  1. 技术推广工程师(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)产品平台的认知度



  1. 获取 (Acquisition)注册量、下载量、安装量



  1. 激活 (Activation)平台使用的活跃度



  1. 留存 (Retention)持续使用平台、使用新的特性



  1. 盈利 (Revenue)为平台的付费



  1. 自传播(Referral)把平台告诉其他人



  1. 产品(Product)涉及到构建和收集产品的反馈



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





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



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



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



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



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



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



| 总结



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



  1. 根据 AAARRRP 模型 来制定出你对 DevRel 团队期望的目标;



  1. 选择与这些目标最匹配的活动形式;



  1. 根据这些活动形式,可以确定招募技术推广工程师(Developer Advocates)还是技术布道师(Developer Evangelists);



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



| DevRelOMeter



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





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



作者:Phil Leggetter



编译:Jack Jin



订阅号:开发者关系



发布于: 2020 年 08 月 17 日阅读数: 45
用户头像

订阅号:开发者关系 2018.08.20 加入

还未添加个人简介

评论

发布
暂无评论
定义“开发者关系”