银行IT的敏捷转身

[摘要]

中国银行业的数字化转型才刚刚拉开帷幕,作为转型重点的银行IT部门正在经历从开发模式到组织定位的巨大变革。本文从时下银行IT广泛的敏捷转型开始分析,揭示了中国银行业面临的数字化挑战,分享了应对挑战的一些共识,同时给出了中国银行数字化转型的大方向。

数字化挑战

过去的3年时间里,我作为敏捷转型顾问,合作频次最多的,就是全国大大小小的银行。银行业IT这一波的敏捷转型,很多人会归因为互联网金融的冲击,认为银行业IT被迫从原来的内部职能部门走上前台,迎战外部市场的挑战。也有不少银行从业人员,对此持有不同看法:类似P2P这样的互联网业务,对中国的银行业还谈不上任何的冲击。在我看来,真正冲击中国银行业的,是以下两个方面:

  • 服务渠道的变迁——渠道从过去实体的网点向数字化渠道转移。注意,这并不是说所有的服务都变成了移动APP,而是所有的服务都会用某种数字化的形式呈现,比如现在到工行建行网点办卡都是通过一台综合服务机;交行几年前开始试点网点机器人,而招行已经在刷脸取款。由于银行之前是没有数字化部门的,所以这些要求自然跟IT挂上了钩。
  • FinTech的冲击——技术突破正在改变业务形态。最近火过了头的加密货币(比特币)正是这样的技术案例,它可能对未来银行业务产生颠覆性影响。在欧美很多利用智能技术做征信的平台也快速崛起,替代了传统费时费力的背景调查。对比之前的传统银行科技,FinTech拥有非常大的不确定性,这给习惯于购买成熟软件产品的银行带来了不小的挑战。当然由于又是科技相关,所以这口锅自然也得IT背了。

以上两点带来的变化显而易见,所以,无论提不提敏捷,银行IT都得转型。建立在支撑基础业务、保证业务稳定运行之上的IT部门,不可能自然而然演进成为“以用户为中心,思考服务体验,并保持对业界先进技术洞察”的新型数字化IT部门。下面就结合我过去3年中,近10家银行的顾问经历,谈谈这个转型中的挑战和可能的应对之策。

稳与快

我们辅导过一家外资银行,一上来就要求全球范围实施DevOps,“全面”敏捷。作为顾问,感觉很爽,改进起来气贯长虹。半年之后,已经没有不做敏捷改进的项目了,就连基于小型机AS/400的系统也都走上了DevOps的持续发布之路。

中国的银行业可就不是这样一个情况了。我和业内熟悉的几个人,经常开玩笑说“‘喝茶’就是悬在中国银行敏捷转型头上的‘达利摩斯之剑’”——高管们心里羡慕着互联网玩法的“小、快、灵”,脑子里却时刻担心着因生产事故被请去“喝茶”。转型需要经历烟斗曲线,当刚好处于曲线下挫点时,很可能因为一次事故而被全面叫停。一位银行科技高管曾经在内部会议上对我直言:“不要以为我不支持敏捷,正是因为我支持,所以才拉着你们跑慢一点”。

团队里有顾问找到我说不想做中国的银行了,太纠结,犹抱琵琶半遮面。于是我反问这位顾问,为什么中国的银行不能像外行一样一步到位呢?是因为太保守或者太官僚?一时问得对方语塞。其实,外行比起咱们可能更保守,生怕有一点负面消息,有的机构更庞大,更官僚。那么是什么原因,让我们中国的银行不敢“全面”敏捷呢?

就我目前认知,中国银行和外资银行有两点显著不同:一是中国银行集中精力办大事儿的构建方式;二是中国银行IT的历史定位。

如果我们对比中外银行的业务架构,会发现咱们的银行在业务设计上非常集中。这样的集中思路投射到IT系统建设上也是非常明显的:一般会考虑一套系统支持多条业务线。经典的例子是咱们的银行一般只有一套清算、核算平台,而外行每条业务线可能有自己的独立平台。集中建设的好处自然已经体现出来了,短时间我们就构建起来了一个相对完善的金融电子平台,但带来的问题就是系统非常复杂。

(图:中外行典型组织结构区别)

在敏捷转型过程中,有两个领域的复杂度是让我头疼的:电信和金融。大家可能想象不到,打通一次电话和完成一笔转账都要涉及近亿行代码!一条业务需求动辄要求修改十几个独立应用!咱们集中建设的银行系统显然不是随便就敢改的,早期即使在银行大型机系统上引入迭代开发都是很困难的。而这些系统往往又是银行的核心主干,任何小错误都可能造成致命的连锁反应。

在IT定位上,从国有五大行到各大股份制银行,基本都将IT归到了科技部下面统一管理。从组织结构上,可以看到IT的定位是一个共享的内部服务部门,或者说,是一个成本中心。最初的IT只是管理一些购买的商业软件和平台,并没有作为一个强自研能力的组织存在。银行IT的自有员工和外包人员比例,普遍都在1:6左右,一个主要的IT系统可能也就能投入两三个长期自有员工。到了现代,这个以科技为核心(Tech@Core)的时代,这样的人员配置显然已经捉襟见肘了。

以上两个因素,从技术架构和人员架构两个方面制约了敏捷的大规模推广。所以,银行想要“快”起来,往往不那么容易。各家银行的转型,都会选择相对新的技术领域,或和用户结合比较紧密的应用开始试点。而初期的转型目标,也会设定为“探索在现有约束条件下,如何进行敏捷模式落地”。最终,大多数银行都会走向“双模”:明确哪些系统和应用更看重业务表现的稳定性(采用瀑布模式),哪些更看重市场变化的响应速度(采用敏捷迭代模式)。

(图:源于Gartner总结的双模IT架构基本示意图)

理论上讲,“双模”只是一个过渡状态,这种方式也受到了不少专家的批评。“双模”可能会掩盖掉一些更深层次的问题,比如系统快不起来,根本原因其实是架构质量问题。从科技的发展趋势来看,确实止步于“双模”是不明智的,微服务化和平台化架构的逐步成熟会让以前稳定第一的系统也快起来。但就目前的约束来看,“双模”是已有成型建制银行IT的必经之路,其意义更多是在组织里植入管理不确定性的能力,从而构建对市场变化的快速响应能力。

效率与响应力

“唯快不破”是互联网服务发展的必备条件,而这个“快”其实是被很多管理者误解的。这个误解也造成了银行IT管理者们对“快”的提法有些许反感。这个误解的根源,在于对效率和响应力的混淆。

如果我们正确分析互联网成功服务的特质,就会发现他们根据市场变化推出和改变服务的速度特别快,而这个快很明确是在响应力上。举个日常生活中的例子,作为干洗店的客户,我们其实并不关心干洗店内部的效率问题(例如单位时间处理多少件衣服、干洗机的利用率等),我们关心的是干洗店能多好多快地把我们衣服洗好。

互联网时代给银行业带来的一个明显转变,就是从过去“以自身服务为中心”,到现在“以客户为中心”。从前在以自身服务为中心的时候,我们的管理方法及技术实践都是围绕效率来做的;到了这个时候,显然我们必须用客户的视角来思考问题,所以就需要更加关注响应力。当我们在追求效率的道路上走到一定程度,就有可能伤害响应力。比如为了干洗机的利用率,我们批量分类客户的同类型衣物放一个批次,显然这样的做法在订单达到一定数量的时候,会减缓每个客户的交货时间,让客户等待更久,伤害了对客户的响应力。

同理,这也是为什么在敏捷组织里,我们提倡少分角色、跨职能协作。当我们的分工过于细化时,对外部的变化响应能力就下降了。在传统银行IT系统里这样的情况是很普遍的,一个业务需求需要分解到十几个应用模块完成,而每个模块都只能由一个专人完成。

理解响应力的重要性并不难,但实践高响应力的管理却是相当困难的。银行业是一个重流程管理的行业,银行IT显然也继承了这样的基因。重流程标准化的管理方法,造成大家习惯性地进行自身局部效率的优化,实则增加了端到端的响应时间。我经常举一个发生在我们每天日常工作中的例子让大家意识到这个问题的严重性。

你是一位IT管理者,小王是一位认真负责的开发人员。一天他告诉你,现在项目A上他的工作进入尾声了,接下来只需要占用他一半的工作时间。这样的情况下,小王希望请示接下来的工作安排。在实际工作过程中,大家会赶快告诉小王启动项目B的工作,或者分配给他项目C的部分工作。假设小王启动了项目B的工作,很快他发现需要小李协助才能开展分析工作,而小李这个时候正在项目A上忙得不可开交。接下来有意思的事情就发生了,小王显然会要求小李配合,而这事儿如果真正发生了,显然就耽误了项目A的工期,那么项目A的完成时间就要推后了。小王和小李有可能找到你来请示工作优先级,然而,可怕地是,在你的意识里,会觉得这显然是“加加班”就能解决的问题!

于是,整个IT产业陷入了做不完的需求和越来越严重的内耗!

(图:小王工作安排示意,由于项目B的引入工作越来越多,成效却变少了)

实际上,如果我们认识到项目A的关键要素是快速推向市场,那么我们给小王的安排应该是让他继续专注于项目A,看看什么地方能够协助团队尽快完成项目。这个认知的转变是困难的:

  • 作为管理者,要放弃过去对人员利用率的执着,理解利用率和响应力不是正比关系,在一定阶段后甚至和效率也没有正比关系。
  • 作为员工,要放弃一个萝卜一个坑的工作模式,保持持续学习和跨职能工作的能力,把自己构建成一个T型人才。这个案例中,小王要能够帮助项目A的其它工作,就要求他具有开发之外的其它能力,比如测试。

在这样一个时代背景下,银行IT的敏捷转型,实际是基于以用户为中心的根本原则,加强整个组织的响应力。如果大家还在以“一个功能实现是不是更快了”来度量和牵引转型方向,那么请尽快调整到“面向市场和用户的端到端交付指标”上来。

业务与技术

懂业务是银行业人员晋升的关键因素。曾经在一次银行IT中层管理干部的培训上,我让大家举手表决是向业务方向发展,还是向技术方向发展,结果是全部都选择的业务方向。不可否认,银行业务的复杂度,要设计一套IT系统需要很强的业务理解。但数字化时代,技术成为了越来越重要的一个支柱,各银行组织如果不能快速构建技术人员的职业通道,必然很难在数字化上取得真正的收益。

我们从两个方面来看看中国银行业技术方面的挑战。

第一点是没有足够的技术封装。经常看到一个有意思的现象是,银行业务人员会看数据库,每一张数据库表就映射一张物理世界的报表。这样的设计结果往往是一张银行数据库表可能有好几百个字段。一段时间内,这样的设计是很流行的,因为沟通需求和最后验收都会相当顺畅,直接看数据库表就完成了技术和业务的交流。隐患就是,数据库根本就没有模型可言,修改任何的数据项都需要波及整个系统,所以大家就倾向于一开始就把所有的数据项全部列好,如果不确定就先留下一些空字段以备后续不时之需。

由于根本没有数据模型封装,看似业务上便于理解的设计,到后来也会因为冗余严重、耦合紧密而变得难于理解,或根本不可维护。只要是在基于如此架构上工作过的IT人员,就特别能理解,“为什么弄懂一个几千行的存储过程,需要花几天时间”。没有封装的结果,就是每个维护修改者都需要理解已有系统的所有复杂细节。这也是为什么我们在银行核心COBOL系统中,会看到大量的冗余代码——与其修改已有的程序,还不如忘记已实现的业务,为新增业务重新开发。

第二点是没有开放的技术生态。银行业经常把基于Java这样现代语言的开发称之为开放平台,与之对比的是传统基于大型机和小型机的封闭开发环境。最近还就开发效率问题和一个老牌银行技术人员进行过讨论。一个观点是,基于成熟封闭环境的开发一旦上手其实效率可以很高,对金融行业来说更加模式化,并且硬件保证了高性能和稳定性。于是我也花了不少时间,来研究这样环境下的开发模式,比如在绿色的传统命令界面上完全采用键盘操作,从代码管理到部署都是私有的平台和工具。

从我的角度来看,传统封闭开发环境有以下几个致命伤:

  • 技术设计的表现力不够,造成可维护性差。长期下来,系统修改十分困难,成本随时间爬升很快。
  • 不能够利用很多已有资源。从开源到云服务,实际上都是开放生态中的可用资源。开放技术的全球知识库早已超越了任何一家企业可以提供的技术服务。使用这些共享资源的门槛,就是需要加入到这样的开放生态中去,随着环境的发展而持续演进。
  • 难以支撑快速的市场和用户扩张,对基础资源抽象隔离不够。以云服务为例,某种意义上,云是对之前我们计算机硬件资源的封装,让其成为像日常生活中水电气一样的公用资源,它使得我们在数字世界扩张的时候可以不再受基础资源的限制。然而,在银行IT中,这样的基础资源和服务抽象很少。

很多银行已经意识到了上述的问题,在科技发展方向上,决定逐步将系统应用向开发技术平台迁移。但还存在很严重地照搬过去架构设计的倾向,如前述数据库设计问题仍然存在于新系统中。在敏捷转型过程中,会发现即使在开放平台上也很难实现端到端的业务价值交付,其中核心症结之一仍然在技术架构上。去年,我花了比较大的精力在领域驱动设计(DDD)的推广上,也是希望通过这个方法让银行IT组织认识到正确的架构设计思想。

未来的银行数字化部门应该在应用设计上达成业务和技术的架构绑定,而在人员任职上形成业务和技术的双通道。

文档与人

曾经一句玩笑话“人走文档留”,引起了我对银行IT人才观的深入思考。从较长一个时期看,IT人才观的转变可能是中国银行业的最大挑战。在前沿程序设计会议上,当我倾听一家外行科技VP讲函数式编程,看到两家美国银行收购硅谷技术公司的业界新闻的时候,就深刻地意识到,把“文档”当成IT资产的观念,将会严重阻碍中国银行的科技发展。

也许,在国家鼓励下的BATJ合作,可能给咱们的银行IT业带来深层次的冲击。从去年开始,这个冲击已经超越了我们经典意义上的敏捷转型,而是银行组织级的变革。在这个过程中,我认为我们要解决三个组织级的定位问题。

  • IT合作伙伴的战略定位——从现在的人员外包模式,到面向价值共享的战略合作模式。现行包人头的方式,是敏捷转型的障碍,在银行数字化转型过程中必须重视并解决。当IT和数字化成为银行业未来业务的重要支柱,合作伙伴的定位及合作方式就必须相应改变。
  • IT人员的能力定位——从现行的流程执行模式,到面向业务和技术创新的持续学习模式。随着智能技术在未来几十年的持续渗透,追求效率的金融领域会逐步用机器替代掉重复性工作中的人。这对IT的影响是更深远的,很快我们就会有机器来代替基础的程序员和测试人员,也不再需要管理这些基础人员的IT自有组织。但更为紧缺的是,具备持续学习能力、能够快速响应市场需求变化的数字化人才。
  • 数字化平台的支撑——从过去组织统一流程、检查规范模式,到平台化快速支撑模式。针对未来的不确定性,做细管理流程、强化检查节点的帮助其实是有限的,而提供快速的试验支撑,能够灵活快速地启动小规模多点尝试,则是成功的关键。

人才这个话题上,有一点是确定的:整个组织需要构建数字化人才的能力模型及持续培养体系。去年在国内,我也很欣喜地看到,若干家银行的高管们,开始过问大数据人才的招聘和留用问题,关心在现有体系下如何开辟新的渠道来灵活留用人才。

数字化未来

前面谈了目前银行业IT转型的挑战,最后让我们展望一下未来可能的方向。在前文中我已经多次提到了“数字化”。一个可以预见的未来就是数字化银行,其实《银行3.0》中已经描述了这样的现实,作者也已经开始讲“银行4.0”了。

应该澄清的一点是,数字化不等于IT系统,数字化能力不等于写计算机程序。IT系统仅仅是数字化的一个基础,数字化包含了以用户为中心的实时战略方法和高响应力的敏捷组织,在这样的组织里对技术卓越及创新生机文化的追求是大家的共同目标。

(图:数字化转型模型)

银行业IT的敏捷转型,显然必须服务于这个数字化未来。通过敏捷转型,我们需要把现行的IT部门变成未来数字化银行业务的支撑平台之一。而IT的敏捷转型最终目标应该明确为:

  • 提升端到端的市场响应能力,从而能够为科技引领创新提供能力支撑。
  • 探索科技和业务融合的新模式,从而能够为数字化业务提供模式支撑。

中国银行业的转型才刚刚拉开帷幕,敏捷转型的模式还需要更多的实践者出来分享和交流,谨以此文作为和大家交流的起点。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

绩效考核 – 敏捷转型的鸿沟

关于敏捷转型,有多个层次和角度去规划、实践、观察和推动。本文的关注点是,以小见大,从一个转型中的团队不断走向成熟必然遇到的一道屏障展开,希望能够给转型伊始的管理者一些实质性的建议。

一、敏捷转型过程中的必然挑战

团队级敏捷转型的成熟过程可以参考一些文章,比如ThoughtWorks同事蔡同写的“团队敏捷转型的三个阶段”,其中详细分析了三个不同阶段的关注点和度量指标。另外,ThoughtWorks在对某家全球性银行实施敏捷转型过程中,定制了一个三层的敏捷成熟度模型如下(其他成熟度模型大同小异):

敏捷团队走向成熟的三个阶段

在团队实施敏捷的过程中,虽然可以按照上述文章或者上图大致的路径推进,但还有很多难以避免的问题,却足以成为敏捷难以为继甚至倒退的关键障碍。典型问题是传统管理方式跟敏捷价值观之间的冲突,其表现如下:

  • 经理:敏捷追求的是打造自组织团队和成员能力多样化,那么我如何考核某个员工做的好还是不好?有哪些新的KPI?
  • 经理:是不是可以按照一个员工完成的用户故事点数来考核他的年终绩效?
  • 经理:怎么样才能促进团队成员之间多协作?一个团队成员请假,这部分工作就搁置在那里了,要是能多协作,就可以替补一下。
  • 经理:小李,你看这个任务你来吧,这周五能不能完成?(殊不知,小李心里想的是本周五休假陪老婆过生日)
  • Scrum Master:为什么站会的时候大家都各自更新各自的,没有任何“相互关心”的交流,站会没啥用啊!
  • 团队成员:我在迭代开始已经认领了卡了,我这周快做不完了,为什么要帮他啊?而且我的确不懂他那一块啊!
  • 团队成员:今年的绩效考核我的目标已经定好了,如果达不到我的工资就加不了多少,我还是多关注自己的事情吧。

以上表现,究其本质原因,就是传统的绩效考核方式跟敏捷价值观和原则的冲突。这道文化和价值观的“鸿沟”可能明显表现在团队从Level 1到Level2,或者Level 2到Level3之间,因为Level 2和Level 3其目标的实现都需要依赖于一支为共同目标协力前行的高绩效团队(见下图)。为何这是一道鸿沟?先认识一下传统绩效考核。

传统绩效考核是敏捷转型过程中需要跨越的一道鸿沟

二、传统绩效考核

传统绩效考核的三个目标是:

  1. 提升员工个人的能力
  2. 提升组织产出
  3. 决定涨薪和升职

一般的做法如下:

  1. 每年进行一次年终考核
  2. 年初设定目标,跟部门、团队的目标对齐然后分解
  3. 半年或者一年跟经理考核一次
  4. 最终评级结果决定涨薪和升职情况

举例说明某家企业的绩效考核方式:

目标设定:设定目标的时候会有模板,这个模板自上而下逐层分发到各个部门,员工导入模板后,开始制定目标。目标包含业务目标和跨职能目标两部分。其中跨职能目标,比如安全条例遵守情况;个人学习提升指标,比如组织活动、分享等情况;业务指标,基于业务线以及个人角色来,比如是QA,如何保证产品质量、成功上线等等;

制定目标时间:年初

考核时间:每年两次,年中和年末;首先需要员工写出Self-assessment,然后跟经理review

考核结果:分为4个档次,Top、Strong、Meet和Below

级别最终评定方式:People Manager会跟员工一对一沟通,很少征求其他员工的意见,会寻求来自于其他管理线的反馈,比如业务线经理,项目经理等等。

如何影响涨薪或升职:某个部门每年涨薪预算是确定的,每个团队会分到不同级别的考核结果比例,比如Top占比5%,Strong 10%,Meet70%,Below15%。People Manager根据团队考核结果排名,上报到更高层级排名,从而在有预算的这个层级大排名确定最终涨幅或者是否升职。

三、绩效考核的困境

绩效考核的核心是使用KPI考核结果来对于员工的绩效进行排名,从而奖励(加薪、升职)那些排名靠前的员工,迫使靠后员工努力改进和提升。事实上,也许绩效工资能够起到激励排名靠前的员工,但最大的问题是:绩效工资并不能激励排名靠后的员工做得更好。

20世纪的管理大师爱德华.戴明认为:

绩效考核、绩效排名以及年度考核是管理上七大顽疾之一。

对于以上表述,我采访过几个HR朋友,他们深有同感,绩效考核的理论和框架很好,但在落地时变成了经理的主观判断。而且绩效考核本身并不是达到绩效考核目标的唯一、有效手段。

以上传统的考核方式跟敏捷原则存在很大冲突,对于建立自组织团队以及职责共享的文化起到十分严重的负面效用。

传统绩效考核与敏捷价值观之间的冲突

显而易见,传统绩效考核已经成为敏捷团队走向成熟的掣肘,成为团队在敏捷之路上走得更远的鸿沟。

四、如何破局?

作为咨询顾问,需要解决的是如何调和敏捷价值观以及原则与传统企业的控制型文化之间的冲突,为一线经理们提出一些切实可行的建议从而保证敏捷转型可以深入展开。不得不承认的是,很难在短时间、小范围内对整个组织的绩效考核机制进行彻底变革,这个话题留到本文最后一部分探讨,但并不是没有可以尝试的方式。

首先讨论一下经理们最关心的如何达到绩效考核目标,其本质是要回答如下关键问题:

  1. 如何决定给员工涨多少薪水?
  2. 怎么决定谁应该升职?
  3. 怎么决定谁应该被解雇?
  4. 员工如何能知道他们需要做得更好并努力提升自己?

其实,答案也很简单:

  1. 即使没有严格的绩效考核过程,作为管理者你也能够知道谁做得好,谁做得不好,所以作为管理者,在践行敏捷价值观和原则的同时,照样可以适配传统的绩效考核来得到结论。而且,除了基于绩效的薪酬方式PFP(Pay for Performance),还有其他值得探索的薪酬方式
  2. 升职对于高绩效人员来说未必是最好的激励方式。因为在敏捷环境下更倾向于扁平的管理模式,对于“升职”应该重新定义,创造更适合、更具挑战性的新职位给员工,帮助其发挥才能,从而帮助企业提升响应力,提升团队敏捷成熟度,比如转型过程中的内部教练。而且,在传统的职业通道里面,“升职”往往意味着承担更多的管理职责,一个高绩效员工真的喜欢或者擅长做管理吗?
  3. 其实解雇一名员工,如果真的必须要发生,不需要等到年度考核或者合同到期再做(虽然好多公司还在这样做,我大学一个朋友最近就遇到合同到期被解约的情况)。这样的做法既不经济,也不高效,对双方来说都是失败的方式。遇到绩效不好的员工,首先应该思考的是团队是否给予他及时反馈以及足够的帮助;其次,他是否被安排到了合适的岗位。如果这些问题答案都是肯定的,那么他的工作自然就会被转嫁到其他员工身上。团队应该请求更高层次的职能经理基于事实的反馈,请他另求更合适自己的工作机会。
  4. 真正的高绩效员工,未必是为金钱而工作,最能激励他们的是有挑战性的工作和合理的自主权。通过对于产品价值、质量以及交付效率的度量,透明公开可视化这些指标,更容易激励员工做得更好。以产品本身做的好坏作为激励,更持久和长远。员工在透明的工作环境里面的表现为所有成员一览无余,同僚的压力会激励他前行。相反,如果发现不为这些指标所动,不愿意把产品做得更好,就回到问题3。

敏捷环境下,绩效考核的关键思想转变

所以为了打造高绩效敏捷团队,结合传统公司的管理方式,作为启动,管理者需要把握三个关键“考核”思想的转变

  1. 从考核个人绩效转移为考核团队成效 – 以产品的好坏来评价团队表现;
  2. 从横向比较员工绩效转移为纵向比较个人成长 – 对于个人的成长,企业应该定义清楚每个角色的胜任力模型,从而帮助员工设定自我提升计划,而不进行员工之间的横向比较;
  3. 从长周期考核转移到及时反馈与调整 – 缩短反馈周期有利于及时改进,相互反馈有利于增进成员之间信任和理解。

基于以上原则,结合转型过程中遇到的实际案例,给予管理者可以落地尝试的建议如下:

  1. 管理者要积极转换思维,参与一线工作,贡献到实际项目中去。这与精益中的“Go see”原则一致,在工作一线才能看到最真实的约束,比如可以尝试做Scrum Master,或者学习成为企业内部敏捷教练,以及其他自己擅长的业务角色;
  2. 通过参与一线工作,改变传统方式中与团队站在对立面的尴尬境地,更有利于建立信任;
  3. 通过参与一线工作,更加深入的观察团队成员的表现,从而及时提出反馈和改进意见;
  4. 定期跟员工一对一沟通,明确团队需要的胜任力。作为团队的管理者,应该有足够的经验和能力对于日常工作中的所见给予员工及时鼓励或者提供建设性反馈,在此过程中明确团队需要的胜任力,听取员工心声,及时反馈,指引方向;更重要的是要收集员工对自己的反馈,及时调整自己的行为;
  5. 透明“考核”过程,全员参与。尝试每月开展一次类似于360°反馈的茶话会,团队轮流分享自己在过去一个月的成长与进步、还存在的不足、面临的挑战,开诚布公的分享自己开心的不开心的事情。也许刚开始大家放不开,多尝试几次,每次换一个主持人,选择比较轻松的环境进行,慢慢就会有所收获;这是对大家的持续“考核”,也是对自己的“考核”;
  6. 鼓励建立敏捷文化,身体力行。深入理解敏捷的价值观与原则,避免微管理,尝试针对不同任务对员工赋权;给予团队成员试错空间,持续从成功和失败中学习,坚持分享,不要置身事外;
  7. 引导团队坚持每个迭代回顾。将团队的注意力集中到改进产品上,而不是关注自己的KPI,强调团队的目标是把产品做好;
  8. 可视化所有产品度量指标。关注产品好坏,比如质量,交付价值等,度量端到端指标,比如cycle time,上线后的缺陷数,缺陷修复时间等等,聚焦团队目标;
  9. 可视化团队成员贡献。比如建立团队成员学习与分享的物理看板,从而形成正向激励,记录每个人的贡献,建立职责共享文化,自己也要积极参与;
  10. 积极与自己的领导明确敏捷价值观和原则,积极争取自主权,影响其他管理者。

如果能够坚持做到以上各条,利用以上渠道获得的团队信任和事实依据,传统的绩效考核结果也会得到团队的认可。

正如《管理3.0》所说,所有变革最后的失败都是管理的问题。对于转型中的组织,特别是一线管理人员,应该把绩效考核这种管理手段当成“敏捷铁三角”中的一角来对待,那就是调整约束。把它当成跟时间、成本、资源等类似的约束因子来统一管理。一家企业之所以存在,有其独有的文化和运作规则,只有调和好约束,才能最大化敏捷的价值,如下图所示。

管理者应该将“传统绩效考核”视为敏捷项目管理中需要调和的约束条件之一

清华大学管理学教授宁向东一针见血地指出,管理,其本质就是关于如何“破局”的智慧。所谓“局”就是管理者周围的各种资源相互联系,相互作用的一种状态。以上约束,也是软件工程表现出来的组织复杂性,也是一种局。

最后,绩效考核的未来有不少探索者认为是没有绩效考核。2017德勤全球人力资本趋势报告指出:

过去五年,新型绩效管理实践成效显著:在重新设计绩效管理的企业中,有90%的企业在员工敬业度方面有直接改进,96%的企业反馈其流程更加简化,而83%的企业称其员工和经理之间的沟通质量有所提升。

绩效考核领域正在飞速改变,让我们拭目以待!


更多精彩内容,请关注微信公众号:软件乌托邦

Share

团队敏捷转型的三个阶段

在国内做咨询的这段时间里,前后帮助三个客户,在数十个团队做敏捷转型。在这个过程中,见到了不同思想的团队Leader,也遇到了能力参差不齐的团队成员,他们都面临着共同的问题:一方面有着自上而下的压力,却缺乏视野和自学能力,不知道自己究竟应该做什么;另一方面,敏捷的定义模糊且众说纷纭,自己又缺乏自主的独立思考能力,对怎么才算敏捷转型成功充满疑惑。

在被客户无数次的问及以上问题后,我自己也感到疑惑,因为即使在ThoughtWorks内部,这也没有标准答案,甚至我在面对不同客户时,会根据当前的目标产生不同的答案。因此我一直在不断思考一个问题:当下一个客户再问我类似问题的时候,我能不能有一个更明确,更体系化的答案。在和工作在各业务的同事交流后,我得到了一些答案,在此先做一些整理,分享给大家,期望引发后续的讨论。

团队敏捷转型的三个阶段

我们假设,敏捷转型的开始是瀑布式开发,我把这个阶段定义为Agile 0,根据我们的敏捷成熟度模型(AMM)里提及的最终形态定义为Agile 5,期间会经历三个阶段。

阶段一(Agile 0 – 1):建立敏捷流程,缩短交付周期

这个阶段,引入迭代或者建立看板是重点,类似于下图:

(Scrum运作全景图)

这个阶段的主要目标,就是将需求的反馈、开发质量的反馈、以及改进周期缩短在一个迭代内(通常2-4周)。 为达到目的,Coach主要会做以下一些事(Actions):

  • 培训 – 给团队培训敏捷流程、各角色的职责,以及各种工具的使用(比如Jira)。
  • 现场指导 – 先带领团队走完整的敏捷流程,通常会有几个迭代;然后观察团队自己执行流程,并帮助团队改进;最后不再参与这类活动。
  • 需求梳理 – 指导PO和BA建立需求全景图(比如Story Map)、拆分Story、排优先级、和团队其他成员协作等;制定Story编写规范,Story价值流和建立Story看板。

这个阶段主要培养的目标,是Scrum Master或者类似的角色,让他们能了解敏捷流程的运作方式,并能带领团队在Coach不在场的情况下,依然按敏捷流程运作。

要走过这个阶段,有一些关键指标:

  • 交付周期 <= 3周:如果是迭代开发,则应该每个迭代小于3周,并且每个迭代都Release;如果是用Kanban,则Story的Lead Time应该小于3周。
  • 上线的已知缺陷数 = 0:有些企业会给缺陷分级,只要求把高优先级的修复,但是我们推动敏捷,要求质量不可妥协,因此需要转变客户的想法,让客户把缺陷修复放到高优先级。
  • Finish Rate / WIP:如果是迭代开发,为了改变瀑布式开发硬塞需求的习惯,一定要控制Finish Rate大于80%。如果是看板,那就要控制到WIP,让每个人专注于一件事的完成。

有些人说为什么不从技术实践开始?设想一下在瀑布式开发中,开发团队几周甚至一个月才交一次版本给测试团队,在这种情况下,开发怎么会有动力写自动化测试?运维怎么会有动力做自动部署?需求没有妥协的空间,设计没有妥协的空间,导致团队的痛点永远是按时交付,质量一定会被牺牲掉的。因此只有先强制缩短交付周期,让团队痛点转移,才能改变开发人员对质量的观念。至于这个过程中导致的交付速率降低,我们会说:

  • 在敏捷转型前期一定是有所付出的,然而你投入越多,进展就会越快,收益就会来的越早。
  • 没有质量的交付不能称为完成,只能叫半成品或者次品。

由此我们来讨论第二阶段

阶段二(Agile 1 – 3):引入技术实践,质量内建,减少返工

这个阶段的主要目标,是提升开发人员的质量意识,从而提升开发阶段产出的质量水平,减少后续环节的返工。用质量内建的话来说,在缺陷时就立刻修复。这样做的好处就是同时提高了质量和团队整体效率。 其实在软件开发中,生产过程随着开发结束而结束,随之而来的都是检查和传递,因此产品的质量实际是由开发阶段就确定的,如下图:

(Story的生命周期)

只有提升生产过程的质量,才能减少返工,提高效率,因此我们在这个阶段会引入技术实践,缩短质量验证的反馈周期,主要包括:

  • 单元测试:单元测试的反馈周期最快,也在测试金字塔的最底层。要求开发人员编写单元测试,一方面可以提升开发人员的代码设计能力,提升代码质量,另一方面可以提升开发人员的质量主人翁意识,让开发阶段的交付物质量有所提高。
  • 集成测试:包括API测试和组建测试、契约测试等。这依然是要求开发人员来编写,提高开发人员的能力和意识。
  • UI自动化测试:如果是带页面的项目,这个阶段通常都会引入UI测试,一般会要求测试人员编写,这个阶段的主要作用是帮助团队提高回归测试的效率。
  • CI:通过CI服务器,将以上测试定期运行,并可视化报告,让所有团队看到。同时要求团队第一时间修复CI。
  • CD Pipeline:建立自动部署流水线到生产环境,并集成冒烟测试,E2E测试等自动化测试,同时实现回滚。
  • Git:建立使用Git的规范,建立分支策略或者指导客户做纯主干开发,培训客户使用GIT高级功能,同时解决一些疑难杂症。
  • Operation相关技术:指导客户实践蓝绿部署、云和容器、金丝雀发布等。帮助客户设计更好的部署架构和技术架构,同时帮助客户架构师做更好的决策。

这个阶段培养的主要目标就是开发,建立开发的质量意识,帮助开发写出更好的开发,培养开发处理复杂问题的能力。同时开阔团队视野,让团队成员了解更多的技术,学习如何利用新技术提升自己效率。

除了第一阶段的指标继续改进外,这个阶段我们会重点关注的一些指标:

CI相关指标:做CI的背后其实是为了培养团队能力

  • CI触发频率 > 开发人员个数:确保开发人员每天每人有提交。
  • CI通过率 > 80%:确保开发人员在提交代码前做了本地自检。
  • 最近一周内的CI修复时长 < 8h:确定团队对CI有足够的关注,没有CI红过夜。

质量相关指标:

  • 一次通过率 > 80%(或者迭代手动Test的缺陷数接近于0):Story开发完成后,会对完成的功能做一轮手动测试。这时得到的缺陷数,代表了开发阶段的质量,缺陷数越少,说明开发人员的自动化测试和CI做的越好。一次通过率可以作为更高的要求,因为包括了后续的测试环境和生产环境中,产生问题的返工。
  • 单元测试覆盖率 > 80%(大家不要纠结为啥是80%,你也可以改成79%,或者100%):首先要确保单元测试的数量在持续增加,同时要有Code Review的机制来保证单元测试的质量。另外,如果覆盖率造假,那一次通过率一定不会得到改善。
  • 测试金字塔:收集各层测试的数据,并关注是否是一个良好的金字塔,给个参考比例1:2:7。这里需要特别关注的一点,如果发现顶层测试数量太多,通常说明开发人员对自动化测试的关注不足,需要加大对单元测试和集成测试的推广力度。

交付相关指标:

  • CD Pipeline的Cycle time < 1h:这个一定要严格控制,假设一个团队有8个开发,每人每天提交一次,那一天至少提交8次,如果Pipeline跑的太慢,就会影响到大家的代码提交。当然,你也可以把这个时间要求减少,只是我的经验里,有些部署环境复杂、UI测试写的有点多的团队中,1h完成已经是一件非常难的事了。
  • 一个月内 Product Incident <= 1:差不多就是1年小于10个的标准,这个数字可以根据不同行业有不同要求,银行业通常会更严格,而创新互联网企业对线上事故的容忍度会更高。
  • 其他SLA指标:比如服务可用率、响应速度、负载等,这些指标关系到的是部署架构和技术架构的设计和实现。

这个阶段会耗时比较长,因此会有两阶的跨度,第一阶是起步,往往会有教练带着团队做重构,写自动化测试Demo,定规范和总结最佳实践。到第二阶后,这些能力就由团队自己去传播了,教练只会偶尔参加一下Code Review来看看团队是否走在正确的路上。

小结:

总的来看,以上两阶段就是帮助客户建立流程,定义参与角色并找到适合的工具,然后通过度量追踪整个转型过程,并逐步引入敏捷实践来提升相关指标。

(敏捷转型内容示意图)

阶段三(Agile 3 – 5):提升价值交付效率和响应力

到Agile 3为止,我们一直在告诉客户你要做什么,通过改变客户团队成员的行为,来改变他们的思想,特别是开发人员的质量意识和团队成员的能力。基于已有的成果,这个阶段的目标,就是培养成员的自我提升意识,团队的自我改善能力,并帮助团队建立自我改进的习惯。

因为团队专注于自我改进,因此大家会有自己的改进线路,不过无论如何,都会专注于以下几个方面:

  • 更高级的能力建设:能进入这个阶段的团队说明已经具备了支撑快速变化业务的基本能力,因此可以推动更高级的能力建设,比如引入微服务、代码共享、特性团队等(这些能力也能在阶段三之前引入,但是只有在有了阶段二的基础后,才能真正做好)。
  • 以Coaching为主:我们Teaching的内容会变少,Coaching的内容会变多,会让客户自己组织更多的分享,鼓励客户自学,并建立学习型文化。我们会和一些关键人物定期的做交流沟通,来帮助他们解决他们所面临的问题。
  • 与业务走的更近:团队可以更好的理解业务,同时能给业务提供更有价值的建议,因此很多业务在决策早期就会引入技术团队的成员。另外团队也能更好的做出业务想要的东西。 在这个过程中,文化贯穿始末。因为团队能力变强,所以更容易建立业务和技术团队的信任,形成信任文化;因为团队养成了自我改善的习惯,所以更容易形成学习型文化;因为大家有信任、有能力,所以会打破原来的控制型文化,培育出创新型文化。这些文化的建立,能更好的帮助企业在未来保持良好增长。

这个阶段度量的内容会关注在响应力、创新上,这里给些参考:

  • 交付周期 < 5d:这是响应力的象征。
  • 假设验证率:这个指标可以用来考核PO,理论上学到的知识越多,这个数字就会越高。
  • 其他业务指标:这时团队关注的是如何帮业务走向胜利,因此在软件开发时就会大量埋点用于业务分析。

总结

整个转型的过程,其实是行为改变思想,再通过思想影响行为的过程,当团队中的人员能力慢慢提升,思想也在随之改变,所有人都能对什么是正确的事作出更好的判断,继而走向持续改进的道路。所以如果定义团队转型成功,我认为就是帮助团队建立起了一群能自己做持续改进的自组织特性团队。 团队要经历这三个阶段必然是一个漫长的过程,很多钱多气粗的企业一定想知道有没有什么捷径,我的答案是有:敏捷转型的过程就是培养大家能力的过程,既然终点是所有人都拥有很强的能力,那为什么不在一开始就找这样的人来工作呢?

PS:

2005年,作为敏捷方法实践领头羊的ThoughtWorks走入中国,并将敏捷方法论首次引进中国。今天,我们想对中国企业敏捷实施情况做个总结报告,让更多人关注并加入敏捷实施的行列。本调查针对已经实施敏捷的中国企业,了解哪些实践比较普遍,在实施过程中有哪些困难。

我们将在2017年北京TID大会(7月18日)分享第一轮结果,参与填写本调查并留下邮箱的朋友,将会优于业界其他人收到最终报告。


更多精彩洞见,请关注微信公众号:思特沃克

Share