Blog

Blog

PHODAL

开发者即服务:开发者的被按需即用

开发者即服务,是(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. 促进内部进行改进。

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

小结

没有哪一份工作是容易的。


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《全栈应用开发:精益实践》

这不是一本深入前端、后台、运维、设计、分析等各个领域的书籍。本书以实践的方式,将这一系列的领域及理论知识结合到一起,来帮助读者构建全栈Web 开发的知识体系,并辅以精益及敏捷的思想,来一步步开发Web 应用:从创建一个UI 原型到编写出静态的前端页面;从静态的前端页面到带后台的应用,并部署应用;从Web 后台开发API 到开发移动Web 应用。在这个过程中,我们还将介绍一些相辅相成的步骤:使用构建系统来加速Web 应用的开发;为应用添加数据分析工具来改进产品;使用分析工具来改善应用的性能;通过自动化部署来加快上线流程;从而帮助读者开发出一个真正可用的全栈 Web 应用。同时,我们也将帮助读者把这些步骤应用到现有的系统上,改进现有系统的开发流程。

comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签

最近的一些事

  • 最近我和我的同事们,一起在创建一个新的编程语言:Charj 。它是一个使用 Rust 编写的描述式、中间编程语言。GitHub: https://github.com/charj-lang/charj

    Nov. 14, 2020, 9:27 p.m. | China