透明思考


Transparent Thoughts


技术领导者即服务

八年前我写了一篇文章《Tech Lead的三重人格》。迄今为止为数众多的敏捷交付团队中,Tech Lead(技术领导者)对于交付的效能和质量起着至关重要的作用。我在那篇文章中指出,Tech Lead需要扮演三种重要的角色:技术决策者、流程监督人、干扰过滤器。一支团队能否有效采用架构最佳实践、交付流程最佳实践和项目运作最佳实践,很大程度上取决于Tech Lead把自己的工作完成得多好。

如果更进一步把这篇文章中Tech Lead承担的责任做一个拆解,我们可以看到,一个称职的Tech Lead是这样去为项目的顺利交付做出贡献的:

  • 首先,他要制订适合该项目要求的技术方案。他要参与架构设计,了解平台和编程语言、主要的框架和库、集成点、部署策略、数据迁移策略,确认总体技术方案能够支撑系统的业务要求。
  • 随后,他要保障交付顺利开展。他要确保环境的一致性,搭建和管理持续集成流水线,指导并监督团队遵循持续集成的流程和实践。
  • 最后但绝非最不重要的,他还要管理和提升团队的能力。他需要确认团队是否熟悉用到的技术栈和工具,而且——虽然这一点在我写文章时的ThoughtWorks还不那么凸显——要帮助团队成员组织刻意练习来提升能力。

正如当时那篇文章的一位读者非常正确地指出的,要一个人做这三方面的贡献很多时候是不切实际的。在很多组织里,这三件事是在三个环节中分别进行的,这三个环节的彼此割裂造成了很多问题:

  • 在方案环节,架构师根据客户的要求和痛点,基于自己的知识储备设计技术解决方案。他是如何分析客户的要求和痛点,他的知识储备是什么,组织里的其他人不一定知道,于是不同架构师提出的解决方案就很可能不一样。
  • 在交付环节,交付团队基于自己的知识储备来交付技术解决方案。方案背后隐含的知识储备,交付团队未必具备,所以屡屡会出现交付质量不佳的问题。不是他们没有能力,只是能力与方案的需要不符。
  • 组织感到团队的能力有不足,于是找来教练提升能力。然而教练基于的是一个标准的能力集来训练团队,这个能力集与项目实际需要的能力又不一定匹配。于是出现能力发展计划不对症、能力建设效果不明显的问题。

由此可见,只有当方案、交付、能力三者有很好的协同,项目和团队才能健康成长。而这个协同之所以尤其困难,是因为它跨了三个非常不同的问题域(在很多组织是三个不同的功能部门),需要三种非常不同的能力,对这个居中协调者的要求非常高。

所以,如果我们能用一个云上的平台来承载这个居中协调者的能力,对整个组织的交付质量和能力成长都会有帮助。这个平台的核心实际上就是技术栈管理:针对典型的应用场景(例如企业资源服务化、移动数字化渠道),制订组织统一的技术栈,并从技术栈推导出对应的能力评估模型和刻意练习课程。于是我们就得到了以技术栈为核心的IT能力三环联动模型:

当提供技术方案的架构师选择一个技术栈,用这个技术栈交付软件的能力要求就被明确地传达到交付团队。交付团队不用自己去设置开发环境和持续交付流水线,用云原生的持续交付环境即可启动开发,并复用在技术栈上积累的交付最佳实践。通过云上的能力测评系统,能力教练可以清晰地知道哪些成员已经具备需要的能力、哪些成员能力还有差距,然后为有差距的成员提供针对性的刻意练习和指导。

云计算已经成功地模糊了硬件与软件的界限,使IT的一大挑战——管理设备——极大简化。现在,对于IT的另一个大挑战:人才短缺,云计算的“XXX as a service”模式是否可以继续发挥作用?IT组织是否可能借助云计算获得优质IT人才的弹性和伸缩性?这是一个值得去探索的课题。在这个方向上,将对交付质量与效能起着重要影响的Tech Lead的能力以云平台服务的形式提供,有可能是触手可及的一个目标。

(本文作者熊节是ThoughtWorks的总监咨询师)