最新发布《数智时代的AI人才粮仓模型解读白皮书(2024版)》,立即领取! 了解详情
写点什么

凯捷中国万学凡:IT 团队的数字化转型实践

  • 2022-08-31
    北京
  • 本文字数:5431 字

    阅读完需:约 18 分钟

凯捷中国万学凡:IT 团队的数字化转型实践

数字化转型的思考框架是什么?


大家好,首先特别感谢各位能够出席 DTDS 全球数字人才发展峰会,我是万学凡。


我今天分享的主题是 IT 团队的数字化转型实践,希望就大型 IT 团队在数字化转型过程中如何发展、建设分享一些我的经验。在切入正题之前,我有两个问题和大家探讨。


这两个问题来自于我三个月前在 InfoQ 组织的 TGO 鲲鹏说上分享的《大型研发团队的数字化魔方》,主题思想是:在数字化转型时代,随着研发团队越来越大,组织该如何思考研发团队的建设?



有两个主题方向,一个是 IT 团队的核心价值是什么?在思考这个问题的过程中,我从两个角度来分析。


第一个角度是规划视角,即如何和竞争对手在战略上形成差异,以及为目标顾客创造什么样的价值。如果将它深入解读,即如何在战略上形成差异化的竞争力:

  • 我们的研发团队核心价值是什么?

  • 如何真正地以客户为中心,为客户创造什么样的价值?


第二个是能力视角,即如何做组织设计:

  • 如何真正地围绕企业战略目标和业务目标有效分配资源,以此来提升组织能力,更好地支撑数字化转型的落地?


这是我思考这个问题的两个基本逻辑,围绕这两个大的逻辑,我们从规划战略入手,形成业务框架,进而形成技术框架,再到我们的组织架构、运营模型,以此来支撑整体的数字化转型。这是我与大家分享的第一个框架。



第二个主题,是企业在规划 IT 团队数字化转型的过程中,什么样的工作矩阵是行之有效的?我认为有三层:


第一层是战略与组织,这里要考虑两件事情:第一个是围绕着战略的投资组合如何做?哪些方向上要加大投资,哪些方向会延缓投资,哪些方向维持投资,这是 IT 团队 Leader 需要思考的问题;第二个是组织架构如何搭建和治理?这是战略与组织层面的内容,很多时候要和 HR 一起思考。


第二层有很多细节,这里只聊五大块。第一是产品管理,很多组织里也叫需求管理;第二个是技术架构;第三个是现在很火的研发效能;第四个是项目治理;第五个是运维演进。其实这 5 大块可以层层展开,总体说我把它归纳为产品与研发。


第三层叫运营平台,一支 IT 团队需要关注什么?关注财务指标,关注人才的选用育留,以及相应的能力建设和绩效评估体系。


切入正题之前,快速介绍一下我自己,我叫万学凡,是凯捷中国 VP、数字化团队的负责人,也是凯捷咨询的首席顾问。


在行业摸爬滚打多年,我正在组建着越来越大的数字化研发团队,现在团队有超过 1200 名专业顾问,我们组织本身也经历着数字化转型。我常常思考我的团队如何变得越来越高效,如何去搭建更好的工程师文化并建立人才观。


在服务众多客户的同时,我有幸参与到他们的数字化转型实践之中,了解到这些企业的 IT 团队如何从组建走向成熟。



今天的分享将围绕黄金圆环展开,什么是黄金圆环?最里层的是 WHY,中间层是 HOW,最外层是 WHAT。很多人思考问题的方式是从外向内的,先看外面的表象是什么,再看如何做,最后思考问题本身。在过往 10 余年的工作中,我认为这是一个比较好的框架,思考问题、构建问题、构建问题解决方案的方式应该是由内向外的,即先谈 WHY,再谈 HOW,最后谈 WHAT。这也是我今天分享的主线。


数字化团队应具备的能力


首先,IT 团队应该具备的数字化能力是什么,先讲 WHY,应该是什么样子;然后讲 HOW,主要分享两个方面:一个是组织设计,另外一个是工程师文化;最后讲 WHAT,以此做一个总结,即 IT 团队的组织能力构建应该是什么样子。



IT 团队应该如何构建、具备哪些数字化能力?这是我过去一年在搭建上千人的数字化研发团队中总结的三个点。


第一点是业务思维,或者叫商业思维,就是如何以客户为中心。在很多大型的数字化 IT 团队中,有的把精力放在技术本身,有的放在业务解决方案上,却往往忽略了商业思维。我经常与团队探讨,我们既要“埋头拉车”,又要“抬头看路”,真正地围绕“以客户为中心”,构建商业思维。


第二个是解决方案思维。很多 IT 团队在数字化转型的过程中,思考解决方案思维的时候都会比较狭隘,微服务架构,领域驱动设计,DevOps,BDD,TDD……这都很好,但是我认为脱离了业务谈技术是空谈,所以解决方案思维一定是解决某个场景的具体业务问题,基于此提出业务和技术相融合的解决方案。


第三个是团队思维。IT 团队在不断地发展过程中,需要培养一群真正的技术领导者,技术领导者能带领团队朝目标更好地前进。我们今天看到很多 IT 工程师聚焦在技术本身,力争写出更好的代码。真正好的技术领导者要不要写出很好的代码呢?要,但同样也需要有很好的团队思维:需要能够培养团队、发展团队、建设团队,这样才能真正地让整个团队具备好的数字化能力。



以赋能为核心的组织架构设计


HOW,就是该如何做。第一,做组织设计的时候,要搭建以能力为核心的平台型组织架构,这个非常重要。什么叫“以能力为核心”?我认为在未来的 IT 团队数字化转型过程中,能力发展、能力建设是最重要的话题,所以我在搭建自己团队的组织架构的时候,也是通过这个维度来思考的。


最上层的是战略与规划,包括业务架构设计,技术架构治理;中间一层围绕着各个 Account(你可以认为是各个产品线)的产品与研发。但是各个产品线之间往往会形成竖井,这是很难避免的,如何打破组织间的竖井?通过最上一层的战略与规划,通过业务架构设计,技术架构治理,能够横向地把能力打通;第三层,通过运营平台的人才培养、赋能体系、绩效评估,能够进行横向能力建设。



在 IT 团队数字化转型过程中,“以资产为核心的解决方案管理”是其中的一个核心要素,很多企业都在谈如何能够提升 IT 团队的能效,建议从三个方面入手:资产、技术和胜任力。


很多 IT 团队在谈及组织能效提升的过程中,首次谈到的是研发效能,研发效能就是以技术为核心,提升 IT 团队的效率。但也要思考另外两个因素,一个是人的因素,人的因素如何考量?这里我提到的叫胜任力。


第二个是如何形成好的资产?很多组织里面建设平台型组织架构的时候,往往忽略了这一点,或者大家觉得这一点很难在组织中落地实行。对于产品型公司,可能相对来说较容易落地,可以在不断地打磨组织的业务资产和技术资产中形成一套产品,但是对于非产品型公司则会困难一些。


今天先谈两点:一是以资产为核心,该怎么做?第二点是以胜任力为核心,该怎么看?


以资产为核心,解决方案的孵化特别重要,包括四个方面:第一,标准化解决方案。一定要形成不一样的解决方案,解决客户不同的问题,但是在这些不一样的解决方案层面,有一些共性的东西可以抽象和提炼出来,这就是标准化的解决方案。


比如研产供销服,供应链等等,一定要有可以沉淀的标准化的解决方案,通过标准化解决方案来打破产品和产品之间、部门和部门之间的“部门墙”,横向拉通整个部门的能力。


第二,标准化文档。很多的企业推行敏捷,在践行敏捷的过程中,一定要有标准化的文档构建组织能力。


第三,可以执行的代码。无论是产品进公司还是非产品进公司,构建组织级平台的时候,一定有通用的组件或者 API,可以包装、固化下来的,就叫做可执行的代码。


第四,相应的人与组织、以及核心团队。以上就是以资产为核心的解决方案管理。


胜任力模型是 HR 行业里面通用的一套框架,每个企业规划胜任力模型都不太一样,比如技术团队的胜任力如何看?如何为一个好的 IT 技术人员?可以从以下三个方面进行评价:


第一,他应该充分意识到自己专业技术领域的最新发展和最佳实践,比如一个非常好的 Java 后台工程师,应该具备理解 Java 的行业发展趋势是什么,最佳实践是什么。


第二,他不仅能和相关的 IT 工程师讲清楚某个技术的好处和限制,还能和不懂技术的人讲清楚。


举个例子:我在一个行业领域讲,什么是数字化转型?数字化转型对于一个企业意味着什么?工程师文化又是什么?这并不难,但是要给我 70 多岁的父亲母亲讲清楚什么是数字化转型?什么是工程师文化?这就很困难。但是如果能用他们的语言讲清楚,那么我对数字化转型的理解就又上升了一个台阶。


第三,如果我们精通一个工具,一门技术,在去完成一项工作的时候,紧迫感会更强,效率会更高。每个人都有自己擅长的技术,需求分析师擅长需求分析,咨询顾问擅长咨询方法论,程序员知道如何写好代码、如何搭建好的体系架构、如何践行 DDD,无论是什么样的人物画像,都有自己的技术专长。


衡量一个人的技术专长好或者不好,都有一套胜任力模型的框架,以此来指导一个团队或个体,在其发展过程中应该如何去演进发展。



再举个例子,我的团队如何用胜任力模型去评估一个人的通用胜任力和专业胜任力?大家可以看到如上这个图,有 CI/CD 的能力、架构能力、英语能力等等,根据每个人的情况打出相应的分数——从 0 分到 5 分做出评估。这样就知道他在不同维度中的评分,以此来指导这个员工在组织中的晋升和发展方向。


为团队成长投资



第二个 HOW,是工程师文化。凯捷沈阳刚刚装修设计了一个新的办公室。关于敏捷团队的办公室设计,我在公众号中写过三篇文章,最近的一篇就是关于这次沈阳办公室的装修设计:面向未来的办公室:敏捷团队的办公室设计


我认为工程师文化建设,能够让一个 IT 团队在数字化转型过程中变得更加高效,这里需要关注三件事情:


第一,需要有更加敏捷的工作环境。关于更加敏捷的工作环境,我思考了两个方面:第一作为社会锚点,专为人情来设计。好的工程师文化的工作场景是,大家在一起不仅是为了工作,也包含了很多“人情”,所以在这个工作的场所里面,可以创造很多偶遇的机会,可以进行除了工作之外的交流。第二,专为分享而设计。一个好的 IT 团队,一定有很多学习和分享的活动发生,我也鼓励在 IT 团队中专门设置读书角,鼓励团队成员更多地阅读。


第二,有公共开放区,大家可以在开放区进行主动的学习分享活动,这是作为学习分享空间而做的设计。


第三,作为合作枢纽,专为协作而设计,在办公空间中要有很多的白板和小会议室,大家可以在会议室里展开充分的讨论,也可以随时停下来,在白板上展开互动和协作。



讲到学习和分享的氛围,向大家推荐一个工具叫技术雷达。什么叫技术雷达?我们主张每个大的 IT 团队都有自己的技术雷达,这个技术雷达会分享未来的 6-12 个月,哪些技术是要采用的,哪些技术是要探索的,哪些技术是要停下来缓一缓的,把这个技术雷达张贴在办公室公共区域,让所有人都能去理解和学习。


每个团队也会看到他们要采取的新技术栈是什么,要尝试哪些不一样的技术方向,理解行业最新发展的趋势。技术雷达能够帮助我们打造学习和分享的氛围,构建工程师文化。


这里面我总结为两个点:


第一,通过技术能力组建,来加速整个 IT 项目的开发与交付,这个与资产相关。


第二,以人为本,通过学习和分享的氛围、技术雷达,让团队中的工程师都能找到属于自己的技术信仰。同样,我认为很多 HR 同学,以及技术领导者需要注意一个点,为团队的成长投资。


为此,我专门成立了一个叫数字化研修院的团队,就是把团队的能力做整合,从业务解决方案到软件架构,到开发运维、通用能力、业务建模、测试等等整合起来,形成一个大的能力建设图谱,赋能团队。


再深入讲一下,如何在团队里面形成很好的学习和分享氛围?有个比较好的实践,大家看到课程体系图谱里面的所有课程,包括业务、技术、运维、测试,所有的课程都来自于团队。


我们团队里有一个很好的学习和分享文化,就是我们鼓励团队能够主动开发、设计一些好的培训课程。开发和设计完成之后,面向整个大团队,做培训和分享,这是一个方面。


同样我们也鼓励团队能够举起手来说,我想去获取什么样的知识——一方面有人说,我愿意主动地去分享这些知识,一方面有人说我想去获取这样的培训,这样就在我们就形成了一个有效的学习和分享的闭环。


同样作为一个团队的 HR,作为一个团队的 Leader,要形成非常好的 OKR 或者 KPI 的体系,来鼓励团队做更多的学习和分享,为团队的成长投资。



HOW 就是如何去搭建更具包容性的 IT 团队?这里分享一个话题,叫做要消除隐性偏见。


在 IT 团队里,很多时候会有一些隐性偏见,比如说认为女性 IT 工作者不如男性程序员,其实这是完全不对的。现在在我的团队中,IT 女性的比例超过了 40%,我们希望要让消除隐性偏见能够弥漫在公司的氛围中,能够形成 IT 团队的文化和价值观,构建更具包容性的 IT 团队。如果一个团队的包容性好,它会提升团队的集体智力,进而提升整个团队的生产力。


所以说另外一个 HOW,就是在招聘过程中就要消除隐性偏见,不断地构建更加包容性的 IT 团队,来提升整个团队的集体智慧。



推荐一本书,《卓有成效的工程师》,今天很多内容也来自于这本书。我认为卓有成效是一种超凡的境界,全书描绘了一种迅捷、高效、积极、友善的工作方式,在这个不断内卷的数字化时代,很多人都习惯于把血汗和泪水当做勋章,我本人并不赞同,我认为一定有一种更加从容的解决之道,让我们在工作中提高效率,在生活中更加自如。


最后总结,我认为在数字化转型中 IT 团队组织能力的构建,包括三个大的方面:


  1. 员工思维:需要具备三大思维,第一,商业思维,以客户为中心;第二,解决方案思维,如何去形成好的解决方案,包括核心团队、标准化的代码、标准化的解决方案等等;第三,团队思维,我提倡大家要有团队意识,成为技术领导者。

  2. 员工能力:以能力为中心的组织设计,有三层:第一层,战略与组织的架构设计;第二层,产品与研发;第三层是运营平台。搭建以能力为核心的组织架构需要通过解决方案、胜任力、研发效能,横向地打通不同产品线、不同部门,建立以能力为核心的平台型组织。

  3. 员工治理:重点分享的是团队胜任力,包括如何用胜任力模型指导员工和团队的发展。我们谈的不仅是敏捷研发,而是整个组织的敏捷性。

2022-08-31 10:172011

评论

发布
暂无评论
发现更多内容

架构师训练营第十周学习总结

Gosling

极客大学架构师训练营

架构师训练营第10周课后练习

薛凯

一次有效的产品需求头脑风暴

Bruce Talk

敏捷开发 Agile Product Owner

10.5软件组件设计原则

张荣召

学习总结--week10

张荣召

内推阿里,朋友说让我学会这46道面试题,我不信,现在我后悔了

小Q

Java 学习 编程 架构 面试

第十周总结

睁眼看世界

极客大学架构师训练营

架构师Week6作业

lggl

作业

一万三千字的HashMap面试必问知识点详解

Java 编程 面试 计算机

STL 源码剖析之五大组态常量介绍

herongwei

c++ 源码 后端 stl

10.7作业

张荣召

Mybatis【3】-- Mybatis使用工具类读取配置文件以及从属性读取DB信息

秦怀杂货店

Java 数据库 mybatis

【Java基础】-- isAssignableFrom的用法详细解析

秦怀杂货店

Java 关键字

架构师Week6总结

lggl

总结

Mybatis【2.2】-- Mybatis关于创建SqlSession源码分析的几点疑问?

秦怀杂货店

Java 数据库 mybatis

10.1微服务:服务本身的设计,维护及治理

张荣召

10.4领域驱动设计DDD

张荣召

食堂就餐卡系统 UML 设计

心晴雨亦晴(~o~)

极客大学架构师训练营

接口测试--接口文档规范

测试人生路

接口文档

码了2000多行代码就是为了讲清楚TLS握手流程

Gopher指北

https 后端 Go 语言

架构师训练营第 10 周作业

netspecial

极客大学架构师训练营

Mybatis【2.3】-- Mybatis一定要使用commit才能成功修改数据么?

秦怀杂货店

Java 数据库 mybatis

10.2微服务:落地实践的策略与思路

张荣召

10.3微服务网关的技术架构

张荣召

最佳的思维导图生成工具——markmap 使用教程

白色蜗牛

Java 程序员 职场 实用工具

Mybatis【4】-- 关于Mybatis别名定义

秦怀杂货店

Java mybatis

架构师训练营-week10

睁眼看世界

极客大学架构师训练营

JDBC【4】-- SPI底层原理解析

秦怀杂货店

Java 源码 spi

架构师训练营 1 期第 10 周:模块分解 - 作业

piercebn

极客大学架构师训练营

今日份学习之Spring Boot自动配置实现原理

比伯

Java 编程 架构 面试 计算机

redis 基础数据 sets 业务场景分析

sinsy

redis 业务场景分析

凯捷中国万学凡:IT 团队的数字化转型实践_技术管理_极客时间企业版_InfoQ精选文章