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

开发者即服务，是（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）。对于这个词，不同的公司有不同的岗位，还有一种相近的岗位是：开发者布道师。这个职位的产生便是国外的公司也有类似的痛点而导致的，它们都想要：

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

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