开发者体验反模式:开发者即服务

目录

  1. 基础设施团队的挑战
  2. 开发者即服务
  3. 解决方式
  4. 缺失的关键角色
    1. DevRel

开发者即服务,是(Developer-as-a-Service)的简称,亦可称为 “按需即用的开发者”。即当开发者使用某一工具、库,遇到任何相关的问题,可以随时找开发者为我们提供服务。哪怕是使用者使用了我们的 A 框架,但是遇到 B 框架有问题,他/她们也会觉得 A 框架有问题 ——因为 A 框架的开发者们是一种服务,一种开箱即用的服务。

最近几年,我陆陆续续参与了一些公司的基础设施的开发和咨询。从组件框架、组件、平台到 IDE,各式各样的基础设施都有。作为一个参与者或者是负责人,我经历了一些辛酸的故事:要快速响应所有的问题、要提供贴身的技术支持……。所以,我决定写一篇文章来调侃一下使用者,并解释一下开发者的不易。

基础设施团队的挑战

每当有同事从我司离职时,我们通常的一个反应是,去的是技术为主的部门还是业务为主的部门。因为,从待遇上来说,技术部门和业务部门就是两个截然不同的存在。相同的月薪之下,业务部门可能会多个月的奖金,而技术部门这样的可能性极极极低。在这里我们简化一下这两个概念:

  • 技术部门。组织中的技术支持部门,提供各种基础设施能力,如 DevOps 平台、框架、工具、组件库等。
  • 业务部门。仍然是开发人员,只是围绕着业务构建应用的,如 Web 应用、APP 等。

值得注意的事,对于有些公司来说,这可能是三个组织:业务部门是纯粹的业务人员,不包含技术相关的东西;而技术部门是支持所有业务的一个大部分;同时,还会在技术部门内构建一个基础设施团队。

所以,在这里我们简化模型为:基础设施团队,即那些提供各种 平台、框架、工具、组件库等开发应用所需基础能力的团队。

作为基础设施团队的一员,我们可以发现项目中的一些挑战:

挑战与收入不成正比。我们所知道的市场的一个现状,作为一个基础设施团队:有着极高的技术挑战待遇不与之成正比。当难度和收入没成正比时,基础设施部门的架构腐烂就非常快,不过这是另外一个故事了。

过长与破碎的『售后』服务时间。当开发的工具被越来越多的人使用时,我们就面临着需要随时支持他/她人的处境。这样一来,我们就不可避免地需要花费大量时间在支持开发者,并且我们的开发时间就会不断被打扰。如此一来,我们在做这事上的成就感就会越来越低。甚至于我们会觉得这是一项累赘。

推广与 KPI 压力。这个怕是众所周知的问题。不过呢,多数时候,团队需要换一个角度来考虑问题:其它团队使用框架时,能给自身真正地带来什么好处?

提升开发者体验与成本的均衡。提升开发者体验,就意味着我们要用更高的投入,换取一点点的更好的开发者体验。比如说,提供长期性的完整文档、交互性的 API 试用、友好的报错机制等等。

缺少高水平开发人员(潜在)。原因同上,收入与难度不能成正比时,容易导致招不到高水平的开发人员。同样的原因,也会导致另外一个问题,高水平的开发人员在项目中流失。对于一些大公司来说,这并非是问题。

过高的生态建设期望。我们经常指望组织内能有其他人为工具贡献代码。而这种期望往往是非常不现实的。一来,缺乏明显的奖励机制;二来,需要提升他们的能力。

开发者即服务

于是呢,在早期推广的时候,团队会为了更多人的使用,在模式上发生的一些变化。它会导致基础设施团队的开发人员变成了一种开箱即用的服务,就有了开头的定义。

开发者即服务,是(Developer-as-a-Service)的,亦可称为 “按需即用的开发者”。即当开发者使用某一工具、库,遇到任何相关的问题,可以随时找开发者为我们提供服务。哪怕是使用者使用了我们的 A 框架,但是遇到 B 框架有问题,他/她们也会觉得 A 框架有问题 ——因为 A 框架的开发者们是一种服务,一种开箱即用的服务。

在这种工作方式之下,会出现一些特定的服务模式:

  • 一对一的专属支持
  • 及时响应问题请求
  • 优先帮助开发者解决问题。即使判断不是工具的问题,还要给开发者一些方案。
  • ……

在些模式之上,开发者就好像一种随时可使用的服务。这和我们日常使用的 SAAS 服务一样,被期待开箱即用,被期待没有 bug。

解决方式

尽可能的开箱即用

繁琐的安装过程须完成各种的自动化。

构建开发者社区

让开发者帮助开发者,并赋予活跃的用户荣誉或利益,以此来促进生态的发展。

详尽细致的文档

作为服务的提供方,我们一直都有一个共识:开发者们不会看文档。以致于有些人走入一些误区,既然不没看,那我就写少一点。事实上,这是一个误区。

经常写作的人,会达成一种共识:文章写给自己看的,而文档也是写给自己用的。作为一个在社区上活跃的开发者,我经常看到别人的提问,于是我就从我的 800+ 的博客里找到一个链接,然后你懂的。

同理于,当我们作为一个基础设施团队服务时,使用者们不懂得也占多数,所以你只需要抛出一个链接即可。

缺失的关键角色

对于一个提供基础设施服务的团队来说,他/她们急需要一种方式来推广服务,并希望能获得反馈,以完善工具。

而在最近的几年里,在我经历了亚马逊、腾讯云、阿里云等公司的邀文之后 —— 它们需要在行业内有一定经验的云开发者,还需要有一定的写作和演进能力。我便意识到『开发者关系』将是一个非常稀缺的岗位 —— 市场上缺少这样的人才。与此同时,从来没有这样一个工作,它的要求高,但是它的工资确……。

DevRel

我所说这个关键性角色便是,DevRel,即开发者关系(Developer Relations)。对于这个词,不同的公司有不同的岗位,还有一种相近的岗位是:开发者布道师。这个职位的产生便是国外的公司也有类似的痛点而导致的,它们都想要:

  1. 维护开发者关系
  2. 在社区进行宣传
  3. 对社区进行支持、收集社区反馈
  4. 建立连接内部的通道
  5. 促进内部进行改进。

于是,便诞生了这么一个岗位。即要与代码打交道,而且还要与人打交道。