技术领导者即服务

标签: 技术 服务 | 发表时间:2017-06-23 05:01 | 作者:
出处:http://gigix.thoughtworkers.org/

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

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

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

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

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

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

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

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

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

相关 [技术 服务] 推荐:

架构面向服务的技术

- - 博客园_新闻
在其新作 《架构面向服务的技术》中,Philip Wik 总结了使用面向服务的技术搭建解决方案的三大阻力:. 如何在恰当的细节和抽象层次上为复杂的事物建模. 服务技术架构(Service Technology Architecture,后简称 STA)的基础元件是什么. 如何提升 STA 解决方案的速度和质量.

高并发web服务技术选型

- - 崔永键的博客
主要问题集中在单个GB级数据使用何种DFS的问题上,目前还没有得到可靠的结论. 采用:nginx或 lvs: https://github.com/alibaba/LVS. 实施自己的调度策略:学习配置lvs或改造lvs或自己重写. 调研下采用hdfs还是fastdfs还是其他的:Fastdfs,ZFS,Lustre,HadoopHDFS,GlusterFS.

服务化框架技术选型

- - 企业架构 - ITeye博客
基本的服务化框架包括如下模块:统一的RPC框架,服务注册中心,管理平台. 有了这三个模块,就能实现基本的服务化. 为什么一定要是统一的RPC框架,而不是随便啥框架,这里主要是为了技术对齐,减少开发人员的学习成本,减少团队间沟通成本. 好,那么选择一个RPC框架,我们都需要考量什么东西呢. 代码规范:例如是对已有代码透明,还是代码生成;.

技术领导者即服务

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

地理位置技术将如何将改变服务业

- 彭全兵 - 互联网的那点事...
据国外媒体报道, 现场服务管理应用套件ServiceMax的首席执行官戴夫·约诺德(Dave Yarnold)今天发表署名文章,讨论地理位置技术在服务业中的应用,以下为全文摘要:. 面向消费者的地理位置服务如雨后春笋般冒出来,它们无处不在,比如Uber,它可以派一辆轿车到你的门口,速度比出租车快一倍,又比如应用程序Bizzy,它显示你的朋友们最近在哪里吃饭,并为你提供朋友们的推荐.

让网站飞起来02--服务器缓存技术

- Bloger - 博客园-首页原创精华区
第一个介绍的是《让网站飞起来01---浏览器缓存技术》. 介绍服务器,肯定要先支持服务器在网站架构中的位置和作用,然后在介绍几种常见的服务器缓存配置. 对服务器在网站中位置作用有个大概了解:lamp架构图. 上图主要介绍了三种服务器,也是比较常用的服务器,下面就介绍这三种服务器的缓存配置. apache是作为正向代理服务器缓存,nginx和squid主要作为反向代理服务器缓存..

BitTorrent 开发出摆脱服务器的安全通信技术!

- - TECH2IPO创见
自从斯诺登揭露了美国国家安全局的监听项目后,如何使得线上的通信变得更加安全,就变成了当务之急. BitTorrent ,这种点对点的文件分享,多年来依赖于服务器处理,环节尽管易被攻击和侵入,但是就这么磕磕绊绊沿用下来了. 但是,现在基于 BitTorrent 开发出的技术,出现了更加先进的不依赖于服务器的通信方式:BitTorrent Chat.

腾讯新闻如何以技术支撑海量服务

- - 极客公园-GeekPark
[核心提示]腾讯新闻海量用户访问的背后有着怎样的技术支持. 编者注:本文转自  InfoQ. 在 2014 年 4 月 11 日的腾讯分享日活动上,腾讯 OMG 移动媒体产品部助总郑坚分享了有关腾讯新闻海量服务的一些技术技术原则. 腾讯很多海量服务的意识和规则都是从 QQ 演化出来的,即使从移动互联网的角度来看,当时的很多规则也很贴切.

从 MVC 到微服务,技术演变的必经之路

- - CSDN博客推荐文章
编者按:近两年很火的微服务是什么. 本文将为大家介绍微服务的来龙去脉. CGI 出现于 1993 年,图 1 是 CGI 模式比较简单的结构图. 开源电商软件等都是采用 MVC 模式,MVC 模式是做软件开发必学和必经历的一个阶段. 1970 年提出了 MVC 的概念,当时的主机和客户端早已凸显了这个概念.

Spotify工程师讲述如何使用“无聊”技术完成服务发掘和数据库服务

- - InfoQ cn
Björn Edström是互联网音乐服务Spotify的工程师,在Spotify的官方博客中,他讲述了 Spotify为什么要使用一些“无聊”技术的原因. 在Spotify的后端服务和架构中,我们使用了这些成熟和经过验证的技术,我会说明如何实现,以及这样做的原因. 此外,我们还会试图说明Spotify何时不会使用某些经过验证的技术,背后的原因以及它们的问题.