打破铁三角:新的项目管理角度

时至今日,依然有很多项目受困于项目管理铁三角:范围,时间,和成本。是啊,

  • 必须在2月底完成,因为报税高峰期3月份就来了。必须在10月底完成,因为要撑过双十一的并发量。必须在10。1前完成,因为要国庆献礼。
  • 这些需求都得做,因为被替换的系统已经有这些功能了,好多人在用,没了他们会叫的。
  • 就这些人了,招人短时间内也招不到,再说你们不是说了加人反而会降低开发速度吗?

这些都是现实的困难,很难突破,这也是前面几项被称为”铁三角”的原因。那是否就一点办法没有了?

打破一条规则最有效的方法是推翻它的前提和假设。当我们重新审视铁三角的时候,会发现它至少有四个假设。其中有两个假设比较明显,早早就被人发现并利用了。而另外两个假设则需更进一步的洞察力,敏捷项目管理正是对准了这两个不那么明显的假设。对这四个不同假设的颠覆,导致了截然不同的软件过程管理方法。下面我们依次来看一下。

时间变慢

第一个假设较为明显,即铁三角中的时间是按每周工作5天,每天8小时来计算的。无数的团队发现了这一点,然后毫不犹豫的打破了它。每周工作6天,每天12小时如何?工作吞吐量立即可以提升(72-40)/40=80%。相当于时间的流逝减缓了近一倍。这就是我们常见的加班背后的原因之一。

牺牲质量

第二个假设也不难发现,即铁三角中没有提及质量,尤其是内部质量。其实就算客户和供应商的合同中对质量做出一定要求,由于其难以衡量和验证,以及延时效应,通常也沦为最弱的一种约束。”精明”的团队对此心知肚明,通过拷贝粘贴等牺牲内部质量的方式来快速堆积功能。这就是我们常见的匆忙赶工的产品其代码难以长期维护的原因之一。

对以上两个假设的颠覆导致了不利于团队,不利于客户的开发方法,长期来看都是输家。所幸我们还有第三和第四个假设,对它们的重新审视把我们引导到更加合理的项目管理角度。

关注价值

第三个假设是这样的:铁三角之所以这么引人关注,是因为大家认为只要在固定的范围,时间和成本的约束内完成项目,就是成功的。

这是一个看似合理的假设。然而考虑以下两种情况:第一种是在规定的时间和预算内完成了全部预期的功能,但产品没人用,投向市场没啥反应。第二种是工期超了一点,预算也超了,计划的功能有很多没做,相反根据变化做了点别的,但产品推向市场后反应不错,带来了利润。那么两种情况哪种算是成功呢?

我会选第二种。这么选的还有一个叫JimHighsmith的。他针对这个问题提出了新的三角,他称之为敏捷三角:价值,质量和约束。见下图(摘自Agile Project Managment):

其中传统的铁三角被局部化成一个维度,称为约束。而引入了新的维度,价值和质量。其中价值代表的是利润等正向的因素,而质量代表的是变化的成本。质量越好,意味着变化的成本越低。据此,我们打破铁三角的第一个手段是,关注真正的用户价值,降低变化成本,并为此而调整计划。

提高生产效率

铁三角的第四个假设是生产效率不会发生变化。因此固定其中两个只能调节第三个,铁三角因而是铁的。

这个假设具备一定合理性的原因是短时间内生产效率很难发生突破性的变化。但这不妨碍我们持续去提高生产效率,从而软化铁三角。

这方面有众多的选择,比如通过自动化减少手工工作,通过预防错误避免返工,而这里面最重要的,是持续学习,提升每个个体的效率。我们通常说程序员之间的效率差异会达到数量级的差别。花些时间在沟通交流培训反馈上,是我们即使在最严格的外部约束下,也可以做的,并且是为数不多的手段之一。

其实我们从来就只有两个问题…

做什么和如何做。

对做什么保持关注,就会得到敏捷三角;对如何做保持关注,就会得到持续改进;不思考才会被约束住。


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

Share

敏捷画卷:中国软件史的精彩侧影

1

如果把软件开发当成一个谜题,数代的软件人在过去的 50 年里前赴后继地尝试解决这个谜题,不过到今天为止,全世界不管是码农还是码神,我们仍在这个谜题当中痛苦挣扎。

1965 年 ~ 1985 年,软件危机逐步浮现,这让刚刚进入科学管理时代的人们极其不爽。1931 年建成的帝国大厦只花了 410 天,还是提前完工,写个软件还能复杂过盖摩天楼?那肯定是方法有问题。

供职于洛克希德软件技术中心的 Winston W. Royce,在其 1970 年的论文 “Managing the Development of Large Software Systems” 中提出了一个长得像瀑布的流程,业界似乎找到了一款灵丹妙药,虽然这位搞了多年航天器的 Royce 老兄并没有在他的文章中提到任何瀑布相关的字眼。之后以 1988 年 CMM 的发布为重大里程碑,剩下的似乎就是沿着既定的路线,细化,标准化,量化,优化,再优化……

直到一线干活的人们发现事情其实不是这样,于是生长出了各家敏捷流派,以期解决 Fred Brooks 在 “No Silver Bullet” 一文里提出的复杂性(Complexity)、配合性(Conformity)、隐蔽性(Invisibility)、易变性(Changeability)这些现代软件开发中本质性(Essence)的难度。

2

中国用 20 年的时间迈过了西方 50 年的软件工程发展史。《敏捷中国史》中一个个鲜活的故事和严谨的数据考证一起,描绘了敏捷方法在中国软件产业的土壤中一步步发芽、传播的画卷,构成了中国软件史一个精彩的侧影。

《敏捷中国史》不仅帮读者在宏观层面理清了中国软件工程领域在过去 20 年里发展的关键脉络;一系列从业者的经历巧妙串联,更让读者从个体视角体验历史,了解众多普通的软件人是如何参与着历史和创造着历史。

我个人的从业经历跟敏捷中国史的跨度大致重叠,因此格外有感触。阅读每篇内容,本以为早就遗忘的画面在脑海之中栩栩如生地一页页闪过。

3

我还记得 2001 年在新加坡的一个社区图书馆,第一次翻开 Kent Beck 的 Extreme Programming Explained 给我带来的冲击。

不过一番琢磨之后,我得出了几个轻率的结论:

  • 迭代开发玩不转,甲方的预算和立项流程根本不可能让乙方这么干(我当时在新加坡的一个系统集成商工作);
  • 结对编程太奢侈,没有老板会让团队这么干;
  • TDD 真是好东西,不过只要团队里有一个人不这么干,其他人也干不下去,让所有人都用 TDD 不现实。

所谓纸上得来终觉浅,直到四年之后,我自己卷起袖子,在全面采用敏捷实践的团队沉浸工作了几个月,才真正体会了那些理念和实践的价值和可操作性。让我很有共鸣的是,文中不少人和公司初步接触敏捷的经历和感受其实也是类似。

看到敏捷中国大会的举办,大型通信企业的敏捷转型,DevOps、设计思维、精益企业、精益创新的推广,ThoughtWorks 相关的记述把影像拉回我的记忆。那些熟悉的名字把他们的面容带回我的眼前,与他们合作中体验到的酸甜苦辣又从心中流过。虽然是文中很多事件的亲历者,我看到的也只是点点滴滴,从没想到有人能如此全局又生动地把握和呈现当时的脉动。

说到合作,我 2007 年加入 ThoughtWorks,那是我真正认识熊节的开始,不过我知道熊节却要更早一些。那时经常在 JavaEye 上津津有味地旁观一个叫熊节的人跟人吵架,觉得这人吵得很有见解,而且吵得很有文笔。于是,我有了无数的机会在现场和邮件里看熊节怼人,以及被熊节怼,从中学到很多。

为什么专门把怼人拿出来说?这其实跟 ThoughtWorks 的风格有关。不满足于现状,寻求更好的理念、方法和工具,追求软件卓越,这是 ThoughtWorks 的使命。ThoughtWorks 期望员工不盲从主流意见,要持怀疑挑战的态度,以求找到不一样的路径,做到比当前更好。熊节就是这种风格的典型代表。

4

20 年中国软件工程方法的变迁也是中国软件行业追赶国际先进水平的历史。巨大的国内市场已经让我们成为一个软件大国,但我们在工程方法领域并没能够取得匹配的领先地位。

我理解《敏捷中国史》不仅仅是对历史的记录和纪念,更是以史为鉴。文中一个个致力于改善工作成效的一线从业者,致力于推广新方法新工具的布道者,正是他们吸引了一批又一批热衷软件开发的人加入进来,一起推动行业的发展。


以上内容来自ThoughtWorks中国区总经理张松为《敏捷中国史》所作的序。在这一系列课程中,作者熊节也用部分章节叙述了在ThoughtWorks与敏捷的不解之缘。

于 2005 年进入中国以后,对中国的敏捷社区发展起到了极大的推动作用。面对行业环境对敏捷并不积极的状况,ThoughtWorks 选择了主动造势。“敏捷中国”开发者大会就是这样启动起来的。

ThoughtWorks 初入中国

从进入中国开始,ThoughtWorks 就在行业中扮演了敏捷先锋的角色。

2005 年,被西安丰富的高校资源和高新区政府的热情态度所吸引,ThoughtWorks 在西安软件园落户,目标是服务中国本土客户。

同年,ThoughtWorks 在国内获得了三个项目:与西安市高新区政府合作的单点登录系统建设项目,与河北省地税局合作的电子政务项目,以及与厦门好望角信息技术有限公司合作的网游物品交易平台项目。其中第三个项目是唯一来自私企的项目、唯一的互联网项目,客户对敏捷方法的配合程度很高。

ThoughtWorks 在这个项目上也投入了很大的资源,Martin Fowler、Fred George、Jim Webber、Perryn Fowler 等全球敏捷和开源社区的知名人物都曾参与过这个项目的架构与开发。在后来的几年中,好望角是 ThoughtWorks 在中国最重要的标杆项目。

Martin Fowler 的中国之行后,一批 BJUG 和 JavaEye 的网友(如徐昊、李默、熊节、陶文、钱安川等)陆续加入 ThoughtWorks,为 ThoughtWorks 在中国业务与影响力的初期发展做出了贡献。

除了在网络社区和《程序员》杂志为主的报刊发表言论之外, ThoughtWorks 开始积极参与国内的行业会议。

2005 年 12 月,熊节代表 ThoughtWorks 出席了微软企业决策者峰会金融行业论坛,并做了题为《敏捷软件开发》的主题演讲。

2006 年 6 月,Martin Fowler 再次来华,出席第十届中国国际软件博览会暨中国软件产业发展高峰论坛,并做发言演讲。第十届软博会由信产部、发改委、科技部三部委主办,发言嘉宾包括时任信产部副部长娄勤俭、科技部部长徐冠华等政府官员,以及来自东软、用友、神州数码、CA 等知名企业的高管,是当时国内档次最高的 IT 行业会议。

但 ThoughtWorks 在这些行业会议上的亮相并不成功。熊节在微软企业决策者峰会上的演讲反响平平,几乎没有得到任何反馈。

Fowler 在软博会的演讲中介绍了 ThoughtWorks 给国外一家投资银行做的项目案例:这个原定计划 8 个月完成的项目,由于采用了迭代式的开发方法,在两个月的时候已经有部分功能上线,并给客户带来真正的经济效益,随后几个星期就收回了整个项目的投资。

当时台下的听众一片茫然。由于政府主导的重点行业信息化工程固有的特点,在当时绝大多数中国 IT 业者的概念中,软件项目就只有一次预算和一次交付(多发生在年初和年末)。一个项目中有多次交付、多次上线、项目还没结束软件已经开始赚钱,这样的事情对于很多人来说不是信不信的问题,而是根本无法理解。

对敏捷方法、迭代式交付基本理念和运作方式的缺乏了解,使得中国的 IT 同行一时无法认识到 ThoughtWorks 独特的价值。

在早期的三个本地项目中,ThoughtWorks 与西安高新区政府和河北省地税局的合作都出现了不愉快,为时不长即告结束,只有与厦门的私企好望角的合作持续了较长时间。Martin Fowler 在短暂的中国之行中已经看到,当时的中国市场并不特别重视软件的价值,行业更关注压缩项目成本,包括缩短项目周期和挤压人力成本,因此更倾向实施成型产品而非定制开发。

这种对软件独特价值的忽视和对成本的极度重视,导致 ThoughtWorks 在与北大方正等典型的本土 IT 企业谋求合作机会时屡屡遭遇尴尬。为此,ThoughtWorks 决定自行营造行业氛围,主办大型行业会议,倡导对软件价值的重视。

“你还不走吗?”熊节问郭晓。

此时已经是夜里 11 点多,熊节跟 CSDN 的一名工作人员正在调试会场的音响设备,猛然回头,发现郭晓坐在会场中间的座位上,两眼呆呆地望着天花板。

“噢,”被熊节问到,郭晓好像突然回过神似的,“再等一会儿。你们不是也没忙完嘛。”

说完,郭晓又进入了入神的状态。他低头看看一张纸卡片,然后又抬头望着天花板,过一会儿开始念念有词,手还不时挥舞两下。熊节好奇地走到郭晓身旁,探头看他手上的卡片写了什么。

“这是我明天的 cheat sheet,”郭晓主动拿起卡片给熊节看,只见卡片正反两面密密麻麻地写着英文小字,“明天不是我讲第一个吗?得抓紧时间练啊。”

“总共 40 分钟演讲还需要准备?”熊节诧异地问道,“你这种外企高管不是张口就来吗?”

“哪儿啊,”郭晓笑着说,“你可不知道,我最怕对着一大群人演讲了。紧张啊,紧张起来腿都会抖,跟筛糠似的。何况这是第一次在中国做这么大规模的演讲,更紧张。所以我得先练好,练得熟了就不那么紧张了。”

说完,郭晓又把注意力放回他的卡片上,一时抬头呆看天花板,一时念念有词手舞足蹈。直到其他人调好所有设备准备关灯,他才离开会议室回房间睡觉, 这时时间已过午夜。

首届敏捷中国开发者大会在 2006 年 6 月 3 日在北京新世纪日航饭店举行,大会的主题是“敏捷释放软件价值”。这次会议由 ThoughtWorks 和 CSDN 共同主办,JavaEye 等网上社区以协办单位身份帮助宣传。除 Martin Fowler 外,ThoughtWorks 还派出了来自澳大利亚的 Scott Shaw 和来自英国的 Liv Wild 作为演讲人,公司创始人 Roy Singham 也专程到中国参会。现场到会听众约 600 人。

在时任 ThoughtWorks 中国区副总经理郭晓的开场演讲中,他一方面迎合了行业对成本的重视,列举 Forrester 的数据说明采用敏捷开发方法可以大幅节省软件项目成本。然而他给出的数据中,产品总体缺陷率的大幅下降或许可以用测试驱动开发和持续集成等实践来解释,但项目速度(如果“速度”定义为项目完工的总体时间的话)的大幅提升是敏捷解释不了的,只能解释为实施敏捷的团队(即 ThoughtWorks 的团队)能力更强。

另一方面,他也指出“软件的功能不等于价值”,因为“实际上很多功能最终用户根本不会用”,反而造成软件的维护和扩展困难。敏捷方法借由充分的沟通避免开发不必要的功能、借助技术和管理手段保障软件的可维护性与可扩展性,从而释放软件的价值。

这个演讲用一种贴近中国市场现状的方式阐述了敏捷的价值:没有超越时代地谈论“迭代式发,而是从避免功能浪费和延长软件生命周期的角度提出论述。后来几年的实践证明,这个演讲的逻辑,比起 Fowler “原汁原味”的敏捷论述,在中国市场上更容易得到认可。 在随后的主题演讲中,来自英国的业务分析师 Liv Wild 具体介绍了如何进行“充分的沟通”。

当时的ThoughtWorks 在启动项目时会采用一套称为“QuickStart”(快速启动)的信息收集方法,以高互动、可视化的工作坊形式厘清项目的愿景、利益相关人、业务流程、功能范围、设计风格、技术架构,并形成明确的交付计划。当时典型的 QuickStart 需耗时 4 周,后来这套方法在中国被压缩到两周甚至一周。即使放下迭代式开发不谈,这套需求获取的方法本身也大大领先于当时国内 IT 企业普遍的水平。

主题演讲之外,ThoughtWorks 的咨询师还在会场组织了一系列“敏捷游戏”,邀请现场听众参与。“折纸帽子”游戏阐述了在开发过程中与客户频繁沟通和反馈的重要性,“搬运气球”游戏阐述了迭代式交付对于消减项目风险的价值。 这两个游戏都是 ThoughtWorks 在印度举行的新员工入职训练营 “ThoughtWorks 大学”(简称 TWU)的课程内容,这种参与性强、寓教于乐的形式,在中国 IT 行业的专业会议中前所未见,令与会者耳目一新。

大会结束后,李默建立了“敏捷中国”邮件列表,并根据签到记录邀请与会者加入。在后来几年中,这个邮件列表中发生了一系列颇有深度的讨论,成为国内敏捷先行者们又一个重要的在线言论阵地。这个邮件列表随着一年一度的“敏捷中国”大会不断成长,正是中国敏捷社区在逆境中砥砺前行的剪影。

结语

在行业信息化项目的甲方与软件企业的高层领导都对敏捷缺乏兴趣的几年时间里,在一线打拼的一批敏捷实践者没有停下脚步。

他们在探寻轻量级开源架构方案的同时,也在各自的工作中采用敏捷方法,尤其是用户故事、迭代管理、持续集成和测试驱动开发等实践,在需求管理、项目管理、配置管理和质量保障等方面获得了扎实的能力提升。

他们在 JavaEye 等在线论坛交流心得、在 BJUG 等线下社区展开深入的探讨和分享。在交换信息、答疑解惑的过程中,他们也结识了同道的朋友,获得了并肩前行的动力。

在整个行业对敏捷缺乏认同的岁月,《程序员》杂志为这些“草根”实践者们保留了一个难得的言论阵地,使他们得以持续发声。当全球敏捷社区的领导者 ThoughtWorks 进入中国,这些敏捷实践者们迅速在其周围聚集,并以行业大会的形式喊出了响亮的宣言。

随后,一些对于软件能力有着最迫切诉求的大企业回应了这一号召,向着“敏捷中国”这面大旗靠拢。


作为中国敏捷十余年发展历程的亲历者与推动者,资深老程序员熊节从整个中国 IT 发展进程审视敏捷,通过本课程带你一起重新经历一代程序员的青葱热血岁月,与你一起梳理中国软件工程领域 20 年发展的关键脉络。

不止于敏捷,你会切实感受到整个中国 IT 行业、乃至中国经济的发展。

作者简介:

熊节,现任宝尊电商成都研发中心总经理,曾任 ThoughtWorks 总监咨询师、 CSDN 技术主编。

IT 行业打拼 18 年,在金融、零售、政府、电信、制造业、全球医疗等行业的信息化建设方面有着丰富经验。翻译了《重构》《软件工艺》《实现模式》等行业重要著作,是中国 IT 浪潮中敏捷发展的领航者之一。熊节拥有利物浦大学 MBA 学位。

插图提供:

虎头锤,旅居墨尔本的老程序员,北邮博士、北大硕士,15 年编程经验。目前从事支付系统相关业务,曾转战区块链、通信行业。敏捷倡导者、手绘爱好者。

Share

以用户为中心的软件开发

问题

今天这个时代迭代开发已经成为常识,甚至政治正确。随便谁就能给你扯两句mvp。敏捷也从一个开发的,名词变成了管理名词。迭代,测试,反馈,名词满天飞。

人人都在说这些术语,仿佛他们真的就懂怎么做软件了。起码,觉得自己真的懂怎么创新了。然而经不起细聊,一旦深入下去聊一个mvp,聊聊他的迭代计划。就会发现露馅了张嘴闭嘴,谈的都是功能。这个迭代要交付几个功能,这个mvp多了什么功能?他的竞争对手都有哪些功能?却很少听到用户人人都在喊,以用户为中心。口号喊得震天响,但你看他们的行为模式,他们的语言,并没有用户的身影。

我时常觉得这个事情不太对劲。但是也没有想到更好的方法。敏捷中使用的故事卡比功能的视角要好一点。因为在故事卡里,你要写下用户的价值。但是,我一直也不知道这个价值是从哪儿来的。是先开枪后画靶子我们想做某个功能了,所以硬按一些价值的。还是真的存在的,价值的单位应该是什么呢?没有单位的东西就无法管理。无法管理,也就无法优化。我们交付的价值是越来越多吗?还是交付的不如以前了?用什么来判断?

回答不了这些问题,不管输赢都是有点不明不白的。这些问题的核心问题就是价值的单位应该是什么?怎么算一个价值?直到我看了,我们公司设计团队的一个框架MERLIN。又在《创新的窘境》,作者的新书《与运气竞争》里,看到了理论依据。这个问题在我这里才算是告一段落。我明白了,以用户为中心的软件开发大概应该怎么做。

方法核心

如果我们想以用户为中心进行软件开发,那么知行要合一,我们的分析方法应该是围绕着用户展开的。

这个方向倒是不新鲜,我们在inception的时候做用需求分析时我们的方法就是围绕着用户展开的。一个典型的分析过程,如下图所示:

​ 我们会在上面画一条轴,标示出用户旅途。这是用户在使用软件的时候的,他的一个全过程。然后在对应的时间点上,标记出,我们的功能。这样我们的功能就不是平白出来的。每一个都联系了用户价值。在ThoughtWorks,我们可能标记的是用户故事,相对于功能,用户故事,首先就是要写出价值。

但是这个图还是不够给力。首先,从用户旅途上的点,到功能的映射简直是个magic move。并不能很好的传递为什么是这样的一个功能,而不是别的功能?毕竟实现一个用户的价值方法有很多。后续在执行的过程当中,难免会僵化行事。 其次,上面的旅途,还可以再抽象和封装。简言之,旅途本身也应该是有抽象层次的。一个旅途上的一个点,可能也是一段新的旅途。

一个更系统的做法是这样的,首先做服务设计:

​ 系统化的分析用户的行为,过程中与企业有哪些触点,在这些触点上用户“雇佣”企业的产品到底是来做什么的,也就是动机。

然后将这些点再进一步细化,采用故事的模式:

​ 图上的一行会讲一个故事,就像电影分镜或者漫画一样,来表达用户使用的故事,真正的故事,而不是用户故事那种东西,我们叫这个东西故事板。 在故事板上,我们描绘了一个故事,这个故事里,用户获得了一种体验。一个故事对应一个体验。在基本需求都已经得到满足的今天,体验是新的最有价值的事情,以体验为中心才是以用户为中心。故事板恰好给了我们一个非常符合人类认知习惯的方式来描述什么是一个体验。也就回答了开头的问题,什么是价值的单位。

​ ​当我们定义出了价值的单位,就可以从这一单位的价值里面映射出故事卡,来进行开发过程的管理。

​ ​这里就是我们的重点,我们将来交付的软件、交付的服务、我们交付的一个MVP本质上是交付给了用户一组体验。MVP的迭代则应该是更多的体验或某些旧体验的升级(也就是同一个动机,换了一个故事来满足)。

这就是以用户为中心的软件开发的核心。最终我们把用户的价值很好的表达了出来,并且找到了用户体验的基本单位——故事板,由于故事板也可以转化为用户故事,结合早已经存在的敏捷开发方法,也就可以对体验的交付进行度量和管理。达到真正的以用户为中心进行软件开发。


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

Share

从王安石变法看“规模化敏捷”

[摘要]

当前敏捷在大型组织中的规模化落地,某种程度上很像历史上的变法。回顾王安石变法的历史,它为什么会失败?对比敏捷的规模化实施,探讨“规模化敏捷”到底可不可取?以史为鉴,我们应该怎么做?


最近在阅读《罗辑思维》全集时,看到一章很有意思的内容,详细分析历史上的变法,其中王安石变法部分让我不断联想起规模化敏捷的实施。两相对比分析,有诸多启发。

一、历史回顾:王安石变法

大事记

王安石变法为什么会失败?

回顾王安石变法过程,会发现其初心很好,实施策略看似做得特别成功:

  • 变法初心:王安石改革之前,司马光问王安石怎么改革?王安石说他有一个方法叫“民不加赋而国用饶”。王安石认为,北宋国家贫苦的症结,不在于开支过多,而在于生产过少;农民之所以贫苦和不能从事生产,一方面是由于官僚富豪兼并了大量土地,另一方面是由于政府把繁重的徭役加在农民身上。因此,最好的理财富国之路,是依靠天下所有的劳动力去开发自然资源,是积极开源而不是消极节流。即不增加赋税,激发社会活力而让国家变得富强。
  • 实施策略:
    • 先定义蓝图:上《本朝百年无事札子》,谈改革之蓝图;
    • 获得高层支持:北宋皇帝宋神宗,本来久慕王安石之名,其变法之道得到了他的绝对支持,他常常跟周围的人说,他跟王安石就是一个人;
    • 清除反对力量:王安石在获得高层的绝对支持后,对变革有异见的大臣比如欧阳修、司马光进行清除,扫清障碍;
    • 全面推广:在蓝图获准、清除变法异己之后,快节奏地全面推广。

然而,结果却失败了。为什么呢?浅析一下,原因可能是:

1. 目标与执行上的不匹配

历史上的变法,可以分为两类:追求效率的“效率型变法”和追求活力的“活力型变法”。

  • “效率型变法”:效率优先、集中财富但不制造资源和财富增量。简单来说,就是围绕单一目标展开,国家要达到这个目标,不惜一切代价集中所有资源都要实现,比如商鞅变法,春秋时代层层分封的财富分配体系被商鞅全部拆掉,他把国家的每一个老百姓、每一粒粮食都镶嵌在国家这个战争机器上,所以秦国变得非常富强。
  • “活力型变法”:激发活力、制造财富和资源增量。这种变法会同时考虑多个目标比如朝廷财源比较丰沛、老百姓安居乐业、市场繁荣稳定、军队能够有战斗力、政府高效廉洁等;在实施时不是调整存量分配,而是想法设法制造财富和资源增量。比如1933年到1941年期间,由美国第32任总统富兰克林·罗斯福发起的罗斯福新政,他围绕经济、农业与工业、社会保障以及政策制度等几个大的维度展开,后人用核心3R来总结,即救济(Relief)、复兴(Recovery)和改革(Reform),也称三R新政。最终,美国经济复苏,政治制度上建立了以总统为中心的三权分立格局,人民生活得到极大改善。

王安石变法,初心上是“追求活力”、有多重目标的,但实施上却采取了“效率优先”的方法,核心是依靠权力把效率推进下去。“效率型变法”要想成功,有一个天然的前提,就是先有蓝图,然后集中快速施工。对一个单目标系统,预先设定一个“正确的”蓝图尚且挑战重重,如果是针对一个多目标系统,几乎是不可能的。这种目标与执行策略上的不匹配,成为失败的原因之一。

2. 低估了制度成本

其实王安石的变法,从制度设计角度是非常好的,比如青苗法的初衷就很好:给老百姓提供低息贷款,避免去借高利贷,以保护和赈济民户。但问题出在制度的实施是表面上附和但内心未必接纳的各级官吏来推进的。最后变成什么了呢?那就是领导意志。比如当时有一个小官叫做邓绾,为了巴结神宗,当听到神宗称赞王安石为“当今之古人”后,瞬间明白领导意思,就神乎其神地夸王安石变法各种好,虽然他不一定懂新法但却得到了重用。这些变法的落地执行者,为了达到目标或超额完成目标,强制摊派老百姓贷款。最后,实际结果适得其反,不仅没有降低老百姓的压力,反而变成了一种变相的赋税。所以,良好的蓝图在实施过程中遇到了制度成本——执行变法的人,没有理解其真实意图,只是围绕既定KPI开展工作,结果自然不好

3. 忽视长期、可持续的变革力量

任何一种变革都不可能一次性成功,新法也可能会失败。如果失败了,那些反对派一定会站出来攻击王安石。所有效率型改革,只要失去高层支持,无论是主动的还是被动的,出路只有一条,那就是失败。宋神宗一死,继位的高太后一上台就把王安石搞下台,新法完全没有了机会,退出历史舞台!王安石阵营在变法期间,并没有能够培养出持续推动变革的力量,比如王安石卸任时推荐了他信任的吕惠卿继任,这个人不但没有继承变法大志,反而落井下石,跟邓绾一起诬陷王安石叛乱。因此,后面即使没有高太后和司马光,变法也难以为继。

二、敏捷的规模化落地与变法实施

敏捷(Agile)是2001年由17位资深软件领域专家们一起发起的针对软件开发工作价值观的倡议。作为一种软件开发理念,与之伴随出现了很多实践框架和方法,如Scrum、Kanban和XP。而这些方法目前已经逐步成为了我们软件开发的实施标准,类似持续集成(Continuous Integration)这种10年前被大家认为是“极限”的方法,现在也已经成了开发团队的一个标配。但在很多大型组织里,敏捷的大规模应用仍然是一个非常有挑战性的任务。软件自身的多样性和这个行业的高速发展,造成了敏捷方法落地的种种挑战。

1. 敏捷的规模化落地,本质是个多目标系统

敏捷的初心,即面向市场和商业模式变化如何提升业务响应力,为用户带来真正有价值、高质量的产品。在整个组织里落地敏捷是一个多目标系统工程,目标至少包含发布高质量、满足用户需求的产品,打造有创造力的文化,建立高响应力的团队等。这带来的第一个挑战就是“蓝图的设定”。没有人可以预先为这个多目标系统设定清晰而正确的蓝图。

最近几年在国际银行届比较知名的数字化转型成功案例非BBVA(西班牙对外银行Banco Bilbao Vizcaya Argentaria)莫属。作为一家拥有6520亿欧元资产的全球银行集团,2007年应对全球金融危机时,BBVA开启其创新旅程,对集团进行数字化革新。尽管拥有上层认可及远见蓝图,BBVA的数字化转型之旅也并非按部就班的沿着蓝图前行,其转型过程大致经历了三个阶段:IT内部创新、扩大团队与银行业务发展重点的创新、数字银行分支匹配敏捷项目管理。一路上尝试不同的结构和方法,通过实验不断调整,最终成为数字化转型的成功典范。

2. 敏捷的规模化落地,是追求活力而不是追求效率

正如前文所述,敏捷的规模化落地,其核心还是围绕敏捷的核心价值观和原则展开,只不过参与的产品更多、人员更多而已。它追求的不是单一目标 —— 规模化,而是价值、质量与其他约束条件的调和所带来的多方优化结果。

笔者曾经参与过一家大型外资银行的敏捷转型辅导,其高管层的目标就是在一年内针对其全球六七万人的IT团队实施敏捷转型,所有部门,包括PMO以及外部教练都要围绕这一目标展开。大部分时间花在了制定各种对团队进行评估的模型上,而团队级别的敏捷实践深入辅导不足,团队对于敏捷理解程度有限。一年之后,形式上虽然绝大部分都参与过敏捷培训,或者敏捷教练辅导,但是对于产品质量和价值的提升非常有限。当这种疾风扫落叶的培训活动结束后,能够保留下来真真正正实施敏捷的团队已经屈指可数,大部分又回到了过去的开发方式。

上面两点,决定了敏捷的规模化落地,如果采用“王安石变法式”的实施方式,必然会失败。

三、规模化敏捷框架与王安石变法

当前大量组织级的敏捷转型需求,催生出了如SAFe、LeSS这样的“规模化敏捷”框架。如果详细研究SAFe的实施过程可以看到,它有完整的白皮书、官网,市面上有各种培训和认证,特别是SAF4.5已经给出了4个经典配置以及10个步骤的实施路线图,看似为组织给出了一个“清晰而正确”的蓝图。

SAFe的蓝图和实施路线图看似很完美,但在落地过程中会遇到诸多挑战,一如一开始看起来很美的“王安石变法”。

1. 追求活力的多目标,实施时变形为单一目标

在实施SAFe的时候,容易想到在组织内部去寻找宋神宗这样的人,这并没有错。但是,根据组织心理学家William Schneider提出的组织文化理论:其中,95%的商业组织都属于控制型文化,这种组织文化强调的是上传下达,领导意志。

(文化四象限)

因此,如果在组织内部发起变革,很容易变成目标问题。也就是王安石遇到宋神宗之后面临的挑战。本来是一个追求活力的变革,最后实施时变成了效率型方式。

2. 因为制度成本,忘记真实意图,仅仅围绕效率指标

前面讲到王安石变法过程中的制度成本问题,在规模化敏捷实施时也普遍存在。无论组织是自我变革,还是请外部教练,很容易变成在领导意志下围绕一个“蓝图”按部就班地展开。而且为了考核规模化的进展,就会设立规模化的指标,比如组织内部百分之多少的团队纳入规模化敏捷运作框架等。再加上出发点就是错误的,失之毫厘谬以千里,离变革成功就越来越远。不难想象,跟王安石变法类似,在实施过程中为了追求规模化的效率指标,往往忽视内功修炼。

笔者刚经历的一个实际案例,某家全球性企业正在实施SAFe,总部请了一名资深的SAFe教练,飞到该公司各个地区负责实施和辅导。当我们作为一线敏捷教练后续进入对中国区团队实施辅导时,某个团队Scrum Master(SM)有一天问我,Sprint长度是不是必须两周?因为他们团队之前一直是三周一个Sprint。我当时很奇怪,问他为什么这么问?他回答说来自Global的教练说了,Sprint必须两周,要不然就不对。我当时听到觉得很震惊,竟然僵化到如此程度!作为一线的SM有此疑惑竟然得不到有说服力的答疑,那么执行过程中僵化就在所难免。

3. 忽视人才和生机型文化,一旦推进不力,一夜回到解放前

当变革推进不力时,反对派的反扑就来了,一夜回到解放前的实际案例不胜枚举。再加上大公司的组织结构重组(re-org)是经常的事,如果支持者不在其位,那么围绕其建立的变革实施人员的动力就会大打折扣。前面提到的大型外资银行的例子,之所以敏捷转型实施一年多以后就没有继续,其中一个很大的原因是全球的高管团队进行了更换,新上任的CXO们并没有认为敏捷转型有价值,所以放弃了之前转型带来的初步成果。更重要的是,在过去一年多的转型过程中,大部分精力并没有放到转型人才的持续培养上,所以当高管团队决定不再投资外部教练,内部的转型力量也没有跟上,变革也就不了了之。

所以,SAFe的蓝图和实施路线图看似很完美,但如同“王安石变法”,注定难以成功。

四、敏捷的规模化落地,如何破?

敏捷的规模化落地,本质是个Complex问题(Cynefin模型)。规模化敏捷框架的最大问题是将一个Complex领域的问题当成Complicated或者Simple领域问题来处理。一个多目标问题,其实是没有Good或Best practices的,唯一有指导意义的是一些价值观和基本原则。对待Complex领域问题,要采取探索-感知-响应模式,快速探索,感知问题的存在,采取行动响应,然后及时调整,对应问题的实践在这个过程中则会涌现出来,而不应该按照一个框架蓝图就开始配置实施。

比如前面提到的BBVA的案例:

  1. 远大愿景:基于对行业趋势的判断,BBVA清楚地认识到,客户的地位在提升,监管的要求趋严,新技术的涌现让银行业面临着前所未有的竞争。BBVA开始以增强与客户的关系作为愿景的转型之路,战略目标定位为成为“数字化时代最好的银行”。而且,基于此愿景制定了6大优先级战略引领集团转型,涵盖了客户体验新标准、驱动数字销售、新商业模式等。所以可见,他们要平衡的是一个多目标系统,既包含用户也包含技术与商业模式等。
  2. 快速行动:BBVA采用实验与学习的方法,将员工、高校研究机构、创新机构、BBVA创新中心、BBVA创业公司比赛、Innova黑客马拉松挑战赛、BBVABeta测试器、BBVA风投以及收购和合作伙伴融入整个创新生态圈,通过各种方式将最新成果快速应用于为客户创造价值,为企业创造收入。
  3. 及时调整:BBVA认为企业应先设立其创新计划并随时准备根据变化对其进行调整,而非盲目的执着于最初计划。比如BBVA的创新项目选择非常灵活,设立指导委员会并根据优先级选择项目,灵活的预算编制以及敏捷的实施,在实施过程中学习,及时调整并探索。

所以,变革成功的哲学是要有一个远大的愿景 —— Think Big;赶紧行动,摸着石头感知河水的深浅、流速,找到可以过河的方案 —— Start Small;根据实验结果,持续学习并改进 —— Learn Fast。

总结

当我们要在一家企业推动敏捷时,首先它是一个活力型变革,多目标问题,而且是一个Complex领域问题,这不是靠套用一种 “规模化敏捷” 框架就能解决的。不要忘记敏捷的初衷,切忌把规模化本身当成目标。当我们忘记“蓝图”,把握“Think BIg, Start Small, Learn Fast”这样的基本原则,更容易找到适合特定企业、组织的敏捷实施方式,比如肖然在《忘记“规模化敏捷”》里所说的“建立持续改进的内部力量、系统思考整个开发过程,以及为创新建立安全试错环境”等。


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

Share

银行业如何建立科技生态圈

上周好几个同事和朋友转给了我一篇《麦肯锡重磅报告:银行业如何超越互联网巨头建立生态圈?》。话题很时髦,读后却印象寥寥,好像说的都对,然则没有什么观点是真正触及问题深度的。于是把这两年自己跟各家银行合作过程中形成的“执念”记录下来,抛砖引玉。

牵手BATJ,是合作还是心猿意马?

在国家的美好期待和祝福下,四大行从去年开始正式牵手互联网巨头。作为科技侧的顾问,这本身是一个利好消息,业务终于得向科技看了,老大难的协作问题终于有希望提上战略议事日程了,毕竟业务和科技总得融合吧!

当然时至今日,这个利好消息并没有变现,拿得出手的合作案例一个没有。问各大行的科技人员,充满了对互联网巨头们的失望;再问BATJ的前同事们,纷纷表示国企搞不定,流程长规矩多。究其原因,如果简单用银行需要从“霸气的主导者”,转变成“聪明的参与者”来形容未免就太过于草率了。

不可否认银行和互联网巨头有着巨大的文化差异,银行业的强风险管控和互联网的快速试错,驱动出了两种业态。是什么让国家都觉得这两种业态需要合作呢?答案显然是数字化。未来的金融服务必然需要依靠数字化技术和渠道,而互联网企业拥有更强大的数字化能力。中国移动支付被这几家互联网巨头雄霸就是最好的案例。

然而看似合理的联姻背后却是两种业态的碰撞。这几家互联网巨头已经各自演变成了平台企业,某种程度上的领域寡头,比如腾讯的社交、京东和阿里的电商、百度的搜索。平台战略是一种经典的商业模式,成为寡头是保证盈利的核心策略之一,比如现在的滴滴。在这个数字化时代,这些巨头们都在想什么呢?答案也是比较明确的,希望自己成为一家科技企业,好像Google和Facebook,能够利用强大的技术力量进入(甚至于创造)新的领域,因为老平台总有一天会被新平台取代。阿里旗下的金融服务公司蚂蚁金服,拥有高达60%以上的科技人员就可见一斑。

自然在这两个业态联姻时,这几家互联网巨头最希望的是合作银行用他们的科技平台,比如云和技术中台。所以自然的结果就是今天一家银行宣布采用阿里云,明天另外一家银行决定腾讯云来试点。然而除了去IOE和国家要求的银行IT系统上云,采用这些巨头的科技平台真的对银行有帮助吗?银行业的安全及监管规则对互联网企业来说很多是完全陌生的,也自然不会存在于这些科技平台中,采用平台带来的风险谁来买单呢?

反观银行方面,最希望合作的是互联网巨头们的流量,能够利用客群资源进行业务的拓展和创新。但作为垄断寡头的BATJ会把流量倒灌给银行?会锁定一家或几家银行合作?这本身就是违背平台战略的问题,自然答案是不会。于是这样的合作从最开始就已经是心猿意马了。

也许现在对这种泰坦级合作下结论还为时尚早,但有一点是肯定的,双方都不会在合作中得到自己最想要的东西

独立科技公司,是破釜沉舟还是文化转型?

以建行和民生为代表的国有和股份制大行纷纷开始独立旗下IT力量,成立科技公司,一时间搞得银行业暗潮涌动,有实力的银行纷纷启动FinTech和数字化转型。多家银行拿出的预算都是按照自身年收入的百分之几计算,一副破釜沉舟的架势。

收集各大银行独立科技公司的初衷超出了我的能力范围,但就我自己的观察,其中一个核心问题就是解决科技生存的文化土壤。当数字化渠道成为银行服务的主流渠道时,原有的IT作为一个成本中心是不可能支撑业务发展需求的。这个矛盾也不是简单将行里的愿景写成“科技引领”就会发生变化的。毫不夸张的说,业务和科技的协作问题已经是银行高级管理者们最头疼的问题。

5年前提出的去IOE对银行IT的影响不大,大量的业务仍然依靠稳定的IBM大型机,数据库也照样是Oracle。短短5年,银行的业务发生了翻天覆地的变化,当然这一点不意外,中国经济超高速增长的大环境下,金融业务必然更快成长。时下去IOE已经不会写在谁的年度目标里了,成为了自然而然的事情。和5年前的差别在于,之前的去IOE并没有客观的业务诉求,而现在不去IOE,可能就支撑不了未来业务了。这实际上也带来了文化上的巨大转变,传统的银行IT职责是使用和运维IOE系统及应用,目标是保持系统的健壮性和稳定运行。而后IOE时代的银行IT必须扩充自身的科技实力,这意味着学习新的技术和培养更强的自研能力。

从银行IT到金融科技,这不应该是一场破釜沉舟的战役,而应该是一次银行组织的文化转型。

不管转型的手段是什么,成立独立科技公司,亦或是增强科技人员占比,都不应该仅仅聚焦于银行的IT部门和团队,银行领导者和业务团队如果不深度参与到这次转型过程中来,文化是不会改变的,而科技和业务不但不会融合,反而会形成更大的鸿沟。这一点上,国内已经有几家银行走在了业务科技融合的正确道路上,展开了广泛的科技赋能。

客户为中心,是时代口号还是业务创新?

大型国有行和股份制银行确实在获取客户的能力方面非常羡慕互联网企业。按照现代资本论的说法,资本的增长包含一个纯人口部分和一个纯经济部分。从这个角度出发,如果能够为一种服务获取更多的“人口” —— 客户,那么增长是自然而然的。

互联网时代在客户管理方面有很多的创新,总结出了不少的分析模型,例如大家比较熟悉的海盗模型 —— AAARRR,据说海盗是这么发声吓唬人的。但其实这些模型存在的目的是帮助大家建立科学的认知方法,套用模型很容易买珠还椟,只记住了这些方法框架,反而忘了真正的客户。比如当我走进银行网点办理开卡业务时,柜员会根据提示发现我有可能正在装修,礼貌询问我是否需要低息装修贷款。这个场景用这些经典框架分析可能是非常正确的,在整个服务流程中嵌入了贷款金融服务。但实际上之所以我来到网点的原因是银行为了满足监管要求不能只通过网络给我开卡,所以我——作为客户——来到网点唯一希望就是快速办理,这个过程中任何的“植入”都会让我反感。

我们很容易喊着客户为中心的口号,做着伤害客户体验的设计。而真正的客户为中心往往需要银行跳出现有的服务模式,从客户的真实述求出发去重新设计业务。

“趣分期”是趣店的前身,由于其目标客户是大学生,所以纳斯达克上市后赶快弱化了其小型借贷公司的身份,成了一家电商。但我们却可以从这个案例中,分析一下为什么各大银行都在做的校园银行没有如此成绩。网上公开的数据显示趣店的大学生客户有3000万,月活2000万以上,这个数字相信足以让各大银行汗颜。

同样是校园信贷服务,我们看到的差异点在于谁真正把客户放到了中心,校园里的客户就是学生,而学生们不是希望贷款,他们希望的是自己拥有一部iPhone,或是能够拥有一台随身笔记本。贷款只是帮助他们达成自己心愿的一种手段(向父母撒娇也许是另外一种)。思维观念的不同自然造就了新兴业务模式的出现,而新业务模式的成功会给缔造者带来高额的回报。

最近在澳洲一家金融机构的数字化转型过程中出现过同样的场景。其中一个目标是帮助这家金融机构推销更多的住房贷款,大家拿出了现在的市场数据和客群分析,也考虑了简化贷款流程,然而一位资深顾问的问题彻底改变了大家的认知,“我们是在讨论提高住房贷款销售,还是在分析如何帮助我们的客户拥有一个美好的家?”这个问题让大家意识到,我们并没有认真去了解客户,我们还是在以自己的服务为中心。

高盛成立零售银行Marcus,直指颠覆传统个人银行业务的当下,各大银行急需的是业务的创新,并且时刻思考客户那个“美好的家”,而不是“住房贷款”。

固本清源,从业务出发建立科技生态

科技能力的建设固然是有很多种方式的,比如时至今日我可能才基本理解为什么华为领袖任正非提出的“用西方的砖修中国的长城”策略。科技能力的建设在当下最挑战的是需要为自己的企业打造一个科技生态圈,每当我看到西班牙BBVA在过去3年打造的科技生态(下图)的时候,都感觉到咱们中国的银行还有相当长的能力建设之路。

https://www.finextra.com/newsarticle/31811/can-banks-be-a-threat-to-big-tech

不仅仅是银行业,在电信运营商领域,最近两年荷兰起家的KPN给我们深刻演义了科技的力量,他们在2个月内完成了跟微信的对接,其直接结果是目前卖给中国游客的预付费SIM卡比自己本国经营的还多。而其它的欧洲运营商,由于不具备这样的科技能力,只能眼睁睁看着业务机会流失。

从科技视角出发,互联网实际只是一个数字化渠道了。在不远的未来,当IoT设备普及,我们会有更多的数字化渠道。针对银行现在的挑战,我们认为以下关注点是当务之急:

  • 从客户视角简化端到端数字化体验
  • 从提升响应力出发打造跨职能团队
  • 从平台思考规划数字化能力,建立能力平台
  • 从业务创新思考合作生态(渠道)


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

Share