生机型文化之使命式指挥

摘要:

为了让精益敏捷转型顺利和持久,做出精益敏捷的“神”,必须努力建设生机型文化;而在生机型文化中,一个重要的实践是使命式指挥。如何践行使命式指挥呢?


从生机型文化谈起

越来越多的企业进行精益敏捷转型,但是有一个很普遍的问题:当外部顾问离场后,回退很严重,流于走形式。其中,一个很重要的原因在于精益敏捷文化。文化建设对精益敏捷转型的持久性和高效性非常重要,如同塑造一个人的“性格”,组织的“性格”决定了结果。

什么是文化?文化是为共同目标而工作的员工之间的共同的信仰、价值观以及假设。管理大师沙因用钻石模型描述了文化的三个层次:

  • 外在表现形态:“外部人看到的”组织结构和组织过程等;
  • 规范和价值观:“组织所说的”的理念等,包括战略、目标、质量意识、指导哲学等;
  • 基本隐性假设:“组织所深信和践行的”,包括潜意识的、暗默的一些信仰、知觉、思想、感觉等。

( 文化的三个层次,沙因,1984)

后面两层文化在精益敏捷中体现为生机型文化,是精益企业文化的重要部分,其主要特征是:

  • 成效导向:绩效评价以实际的用户和业务成效依据,而不是过程指标;过程度量则仅用来发现问题和推动改进;
  • 高度合作:个体之间、组织的各部分之间高度合作、相互支持、充分分享;
  • 鼓励连接:鼓励跨越职能、组织和层级的沟通连接,而不是设置阻碍;
  • 风险共担:风险与责任共担,而不是逃避责任或各扫门前雪;
  • 信息辐射:组织内信息顺畅流动,有效辐射,鼓励发现并上报错误与风险的行为,而非掩盖或阻挠;
  • 采纳新鲜事物:鼓励尝试新想法,并采取措施来限制潜在失败带来的损失,提供“安全”的试错环境;为组织带来新思想,新方法和新技术的传播者、先驱者及具有成长型思维模式、学习能力和领导力的人,会得到重视和培养;
  • 失败产生根因调查:当事情出现错误时,尝试去发现根因,采取措施优化系统,而不是寻找替罪羊或追究责任并惩罚。

(生机型文化的核心转变)

生机型文化主要实践,包括了相对“流行”的自组织团队、跨职能团队、持续改善、内在激励、适应性领导力等,还有如文化度量、Y理论、使命式指挥、信任但验证、非指责性事后调查、成长性思维性模式等。本篇文章将重点阐述生机型文化的一个实践:使命式指挥。

(生机型文化的主要实践)

什么是使命式指挥(Mission Command)?

我们先看一个来自麻省理工大学研究的使命式指挥的成功案例:

耐克旗下的两个工厂

A工厂:传统的控制型管理,员工制定产量、生产实践,统一安排工作,相对高度控制。

B工厂:员工自由选择搭档,制定团队生产产量,决定在出现问题时停掉哪条生产线,等等,相对自由。

结果:A工厂的生产效率为B工厂的一半,B工厂的制作成本比A工厂降低40%。因此,即使是在这样一个传统的服装制造业,对团队的组织方式赋予自由的时候,也是有可能让他们的效率比在高强度管理的情况下还要有更好的成就。

在这个案例中B工厂采用使命式指挥充分发挥团队潜力,从而得到更好生产成果。

使命式指挥替代命令和控制指挥,是高度信任的组织文化表现形式。

首先,企业或组织确定好使命并且说明使命的意图和原因,在大范围内形成一致目标;

然后,在一致目标使命下,赋予组织成员更多的自主权——也就是说在职权范围内,每人都有做决定和行动的自由,自行决定达成目标状态的细节;充分发挥个体的创造力,而不是试图控制。

用很形象的战场来比喻,战场上千变万化,很多情况下指挥官都必须靠自己的判断来决定军事行动,而不是完全听命于后方司令部的指挥。使命原则的关键在于建立一致性、实现自主性,必须坚定的把“人”放在核心位置。

为什么采用使命式指挥?

随着组织的快速发展,组织的规模不断变大,就形成了一个“复杂系统”。要想让整个组织快速动起来、提高效率,必须进行系统解耦,让组织中的每个单元独立高效运作,充分发挥组织中个体的能动性。高层管理机构的职责,应该聚焦于局部无法执行的任务,对局部职权进行辅助,实施使命式指挥。例如,年产值25亿美元的化工产品公司戈尔,成立65年来,从未有过亏损的时候,他们就是在没有管理层的情况下运作的。在戈尔公司:

  • 人们选择自己的工作;
  • 领导者就是吸引了跟随者的人;
  • 独立业务部门就是小型、自治且自给自足的;超过150人就拆分。

ThoughtWorks自身也是使命式指挥的践行者。对组织内各项工作,管理层发布使命——愿景、目标和价值观,具体达成目标的细节过程,由员工充分发挥创意完成。我们能展现出各种不同创新模式,得益于这种核心推动力。

如何采用使命式指挥?

在谈如何采用使命式指挥前,得先看看如何建立使命。

一. 如何建立使命?

1.逐层建立组织级战略

从建立使命的人来说,可以分为三层:高层管理、业务线投资组合管理人员、团队。

  • 首先高层管理设立组织级的愿景使命;
  • 业务线投资组合人员分解成业务目标使命;
  • 团队依据整体业务目标设定各自团队的具体目标。

比如,下面的精益价值树就是逐层目标分解。

(精益价值树)

也可以采用接球(Catch Ball)的方式,制定逐层组织级战略。

(采用接球的方式,制定逐层组织级战略)

2.不同类型的使命

通常,使命可以分成:业务使命、过程使命、技术使命、财务和预算使命。

  • 业务使命:上面的精益价值树是一个例子:根据精益企业中提到的业务地平线, 确定三条业务线的比例,然后对于H3类型的创新业务,高层管理需要确定创新的愿景、创新的过程;对于H2类型的拓展业务,需要确定年度的拓展使命和阶段性拓展使命,特别是商业模式;对于H1类型的稳定业务,除了驱动团队围绕以用户为中心的渐进性创新外,高层和业务线投资组合人员还需要确定未来生命周期的使命路线。
  • 技术使命:比如亚马逊的面向服务的架构,还有微服务、自动测试、移动优先、推进云战略等;CEO、CTO、CIO需要很关注这些技术使命。
  • 过程使命:比如:团队用精益敏捷方式开发产品,快速学习,快速反馈,创造对客户有价值的产品;具体可以再按精益敏捷成熟度分解成几个阶段性使命;过程使命需要与业务使命和技术使命紧密结合在一起。
  • 财物和预算使命:如按季度的滚动预算,要与业务和过程使命相互配合。

3.使命一旦确定,必须遵循

需要特别说明的是,使命一旦确定,必须遵循。在现实过程中,经常会出现不遵循使命的问题。碰到这种情况:

  • 首先分析不遵循的原因:可能是使命有问题,或者使命没问题但不想执行;
  • 如果使命有问题,需要立即修正;
  • 如果是执行的问题,需要严肃对待,否则企业和团队处于一切无所谓散沙的状态,一事无成。

典型的亚马逊的案例:

2001年,亚马逊遇到了一个难题:支撑他们网站运行的Obidos系统,是个巨大且铁板一块的“大泥球”,无法进行扩展,其制约因素是数据库。首席执行官Jeff Bezos将这个问题变成了机会。他希望亚马逊变成一个其他企业都可以利用的平台,最终目的是更好地满足客户的需求。因此,他给技术人员发了一封邮件,要求他们创建一种面向服务的架构。Steve Yegge对此总结如下:

  1. 所有团队以后都通过服务接口来暴露他们的数据和功能;
  2. 团队之间必须通过这些接口彼此通信;
  3. 不允许其他任何形式的进程间通信:不能直接链接,不能直接读其他团队的数据库,没有共享内存模式,不能有任何形式的后门;唯一允许的通信是通过网络调用服务接口;
  4. 采用什么技术都行:HTTP、Corba、PubSub、自定义协议,都无所谓;
  5. 所有服务接口,无一例外,都必须要一开始设计就考虑可外部化——也就是说,团队必须要有计划地做出设计,让接口能开放给外部的其他开发人员;不允许例外;
  6. 任何不这样做的人都将被开除。

Bezos雇佣了西点军校毕业的前陆军突击队员Rick Dalzell来强制实施这些规则。和这些规则一道,他还强制推行了另一个重要变革:每一个服务由一个跨职能的团队负责,团队要在服务的整个生命周期里负责其开发和运行。就像亚马逊的首席技术官Werner Vogels所说的,“谁开发,谁运维”。

这条规则和所有服务接口设计必须可外部化这一要求,一起产生了一些重要影响。正如Vogels指出的,这种团队组织方式“让开发人员接触到其开发软件的日常运作,也让他们每天接触到客户。这种客户反馈环对于提高服务质量非常关键”。

二. 如何使用使命式指挥?

1. 首先要建立跨职能的团队

首先,改变组织结构,建立去中心化的、跨职能的、目标高度一致的、松耦合的小团队。确保团队对他们正在工作的系统有清晰一致的理解,以更好地发挥主观能动性。团队一旦超过10人,群体的变动和协调就会变得难以管理,也变得难以达成决策共识,难以确保团队的每个人都对上下文理解一致。

(建立小团队)

比如,可以以API接口边界来划分团队边界。这种方式,我们可以将团队分布在全世界。只要每个服务都由一个同地点工作的、自主的跨职能的团队来开发和运维,团队之间就不再需要大量的沟通。

很有代表性的是,亚马逊的“两个披萨”组织结构。

随着组织的发展,最大的问题之一就是保持人与人之间及团队与团队之间有效的沟通。一旦将人员搬到另一个楼层、另一栋建筑或另一个时区,沟通有效性就会大大受限,要继续保持共识、信任和有效协作就很困难。为了控制这个问题,亚马逊规定所有团队必须能遵循“两个披萨”法则:团队应该小到两个披萨就够所有人吃——通常大概5到10人。

对团队大小的限制会产生四个重要影响:

  1. 确保团队对他们正在工作的系统有清晰一致的理解;
  2. 限制团队正在开发的产品或服务的增长速度——通过限制团队大小,我们限制系统所能演进的速度,这同样有助于保证团队对系统始终保持理解一致;
  3. 可能最重要的是,这让权力去中心化,带来了自主性,遵循了使命原则——每一个“两个披萨”团队(2PT)尽可能自主;团队领导者会和管理层一起决定团队所要负责的关键业务指标,称之为“健康函数”,进而成为团队进行实验的整体评价标准;
  4. 领导“两个披萨”团队可以让员工在一个失败不会产生灾难性后果的环境里获得一些领导力经验——这“有助于企业吸引和留住创业型人才”。

2. 建立团队的自主性策略

建立了跨职能的“两个披萨”小团队后,还需要建立团队的自主性策略:

  • 给予团队工具和授权,可将变更部署至生产环境,开展自运维:这看起来很明显,但很多传统组织会基于安全性为由,导致这一点在实际中很难执行,部署生产环境都要提申请走很多流程,生产环境的部署改革极其缓慢。在亚马逊、Netflix和Etsy这样的公司,变更部署下放到团队,特定的高风险变更,团队商讨措施。高层管理相信团队能够采取恰当的措施,并进行自动化测试。另外,我咨询过的一家公司,开始尝试授权团队做自运维,但也担心安全性问题,他们的措施是自运维的同时做好各种日志和流程的跟踪记录,出了问题可以立刻找到问题点,后续持续改进。这也是一种过度改进措施,先要勇敢地做起来迈出第一步;
  • 确保团队有权利选择自己的工具链:尽量让团队自主选择技术栈;在生产环境中,可以限制团队采用由内部IT部门或外部供应商提供的一致平台或基础设施服务,使团队能够向生产环境进行自主部署;
  • 确保团队不需要拨款审批就能进行试验:只要是在使命范围内的具体实验行动,应该有滚动预算的支持,不会因为资金预算问题阻碍验证新的想法;
  • 确保领导者专注于实现使命式指挥:领导者首先要敏锐地根据市场和用户变化,阶段式定义正确的使命,并有效的传达使命,同时协助建立跨职能小团队,采取各种形式提升人员的胜任力,营造充分发挥个人自主性的氛围,提高最小单元的有效性,并从这些组织单元中培养出新的领导者。

在使命式指挥中,团队有权利和责任对他们所处的特定场景下的成本和风险进行恰当的管理。而财务、项目管理办公室(PMO),治理、风险与合规管理(GRC)团队,以及其他集中式机构的角色,都要发生改变:他们指定目标成效,协助将当前状态透明化,并在需要时提供支持和工具,但不强制规定成本、流程和风险要如何管理。

3. 建立改善形

改善形是一种遵循使命原则,将实现那些成果的主人翁意识推向组织基层的一种方法。改善形为团队建立一致的目标, 并将其分解为一个个小的、渐进的成果(目标状态),能够逐步接近目标。改善形的关键特征是它的迭代性,以及能够驱动一种实验性方法来达到期望的目标状态 。改善形的迭代几乎过程产生效果是一组我们希望下个迭代能叨叨的可衡量的目标状态,它描述了我们要努力的方向,并且遵循使命原则。使命的具体目标跟踪管理也可以采用OKR体系。下面是一个团队利用改善形迭代式遵循使命达成目标的例子:

(利用改善形迭代式遵循使命达成目标)

最后要使使命式指挥真正起效,还需要“信任但验证”的机制保证,确保使命的达成。

著名的瑞典商业银行,给分行授予了高度的自主权,但是有一套非常完善的事后核算反馈成效体系,验证自主行动的效果,持续改进;给团队更多灵活支配使用预算的自主权,同时要定期监控预算使用的成效。

总结

为了让精益敏捷转型顺利和持久,做出精益敏捷的“神”,必须努力建设生机型文化。在生机型文化中,一个重要的实践是使命式指挥,在一致性使命的指导下,充分发挥每个小团队的自主战斗力,从而加快整个组织的响应能力,进而获得市场竞争力。


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

Share

提升业务响应力:践与行

金融企业转型的三个挑战

从2009年到现在,我们在包括国有商业银行、股份制银行等传统金融企业里做敏捷转型咨询时,为了提升业务响应力,发现他们常常面临一些相似的挑战。

挑战1:业务侧敏捷的滞后

业务部门花好几个月、甚至半年的时间讨论业需求,整理出完备的SRS(软件需求规格说明书),通常是一份厚重的文档,而此时业务部门发现预算所能支撑的软件开发和测试时间已然不多,因此要求开发团队在三个月内开发完成,估计只有一个月用来测试,然后就要上线。更麻烦的是,在开发过程中业务人员发现用户需求在最近已经发生更改,他们必须修改需求规格说明书,而且还非常频繁,开发团队开始抱怨压力太大,测试团队更是热锅上的蚂蚁。

这个场景表现出的一些特征如下:

  • 需求分析过程非常长,常常是好几个月
  • 需求池(产品待办事项列表)常常处于干枯状态,或者是井喷填满
  • 开发和测试团队抱怨时间不够
  • 开发过程中大量需求变更带来很多浪费
  • 发布时间一拖再拖

这个场景中,突出的问题是超长业务决策时间压缩开发测试时间,需求变更成本高。

深入分析来看,是传统金融企业业务侧缺乏一套行之有效的方法用以提升投资决策效率,从而快速将市场需要转化为业务需求,让交付团队开发并及时上线。除此之外,业务人员缺少用户价值驱动的理念和方法,常常凭个人一厢情愿和拍脑袋规划需求,缺失了用户研究和运营数据分析环节,导致浪费。

我们咨询过的传统银行,有几款产品,做了很多功能,但是仅仅百分之几的功能被用户使用,很多功能用户从来没有用过,造成大量浪费,业务人员还要在从来没有使用过的功能上再增加新功能,犹如火上浇油。

在敏捷的浪潮下,交付侧已经有很好的方法论支撑,无论是流程还是技术实践,都可以快速响应,比如Scrum这样的敏捷方法,持续集成和持续交付这样的技术实践。

如何从业务侧改进,做到精益产品开发,快速应对市场变化是一大挑战。

挑战2:项目驱动交付的掣肘

业务侧以项目为中心立项,立项过程需要层层审批,特别是预算部分。有时立项没有及时审批通过,导致隶属于它的需要快速实现的高价值需求被延误,无法及时抓住对应用户。更糟糕的是,产品团队被打散,多个项目并行开发,没有统一的优先级,不能聚焦在高价值功能点上,等开发团队反应过来时,这个需求已经失去价值,无需再开发,延误了商机。

这个场景中,暴露的是关于项目立项的问题。常见的做法是,业务侧根据需求立项,导致项目多如山,每个交付团队同时承担多个项目开发,其后果是:

  1. 超负荷
  2. 流动性差
  3. 交付慢

每个立项还要经过层层漫长审批,特别是预算部分非常敏感。为了减少审批次数,在立项之初,项目管理人员期望把项目范围扩大,使得预算同时变大。当业务人员看到预算增大,把该有的不该有的功能都添加到交付范围内,结果导致交付更慢。更可怕的是,很多功能并没有业务价值。

我们正在负责一个大型全球跨国银行的IT研发中心,常见一个团队十来个人,同步并行的项目有三到四个,两三个人负责一个项目。在开发过程中,交付团队将注意力集中在按时交付项目划定的范围,跟业务部门分离,沟通方式局限于文档和电话,对于业务变更需求抱怨颇多。

以项目为中心交付时,如何优化治理结构和既定流程,为第二个典型挑战。

挑战3:唯“快”不破与核心安全求稳

企业在提升业务响应力过程中,受到互联网行业的冲击和影响,觉得敏捷是一颗银弹,对于后台核心业务开发也花了大量时间来尝试敏捷方式运作。然而核心系统业务需求趋于常规化和周期化,比如存款、利息重新计算等,比较稳定、可预测;其次,因为是核心业务,影响范围深而广,上线前的回归测试周期长,需要特别谨慎不能有任何失误,业务部门求稳胜过高响应力。最后发现应用敏捷方式来提升业务响应力效果并不理想。

这里暴露的问题是没有区别对待不同业务,进而采用不同开发模式。面对移动互联网的迅猛发展及互联网金融的竞争,传统金融企业纷纷提出“移动优先”、“数字优先”等IT战略,以提高响应力和适应性。对于金融行业的新兴业务或者前端系统,比如手机银行、自助服务以及渠道拓展、互联网平台接入等业务,需要对终端用户的需求快速响应,才能扩大用户群体,迅速占领市场。

然而对于金融IT传统的后台核心业务系统,却表现出如下一些特点:

  • 安全性要求极高:国家各种法律法规对于金融系统安全性有严格要求;
  • 稳定性要求极高:必须保证7X24X365的可用性;
  • 需求变更频率不高:比如银行中的存款、清算、结算等核心IT系统;
  • 受限于以上要求,功能常常是集中交付,而非迭代交付。

我们在咨询过程中客户会经常询问一个问题,“我的产品或者项目适合采用敏捷开发吗?”,如上所述的两种业务模式应该如何处理?是应该不加区分全部采用敏捷开发模式吗?这就是在传统金融企业产品研发过程中面临的“快”与“慢”并存之挑战。

以上提到的传统金融企业具备如下一些特点,决定了其业务响应力提升面临上述挑战,要想让“大象灵活的可以跳舞”,实属不易。传统金融企业特点如下:

  • 组织机构庞大,交付团队动辄上万人
  • 组织结构复杂,管理效率低下
  • 产品创新、投资决策流程复杂且低效,很难快速响应市场需求
  • 跨部门协作比较困难,业务、开发、测试、运维分离,“顽固”的职能划分,而且团队物理分散在不同地域
  • 拉通业务端敏捷阻力大,业务人员的意识转变慢
  • 企业IT表现出“慢”、“贵”、“难”等特点

正因为“大象”的特点,要提升其业务响应力困难重重,但并不是没有解决方法。

应对之策

策略1:价值驱动决策撬动业务敏捷

图1: EDGE(价值驱动产品组合管理)提升业务侧响应力

前面谈到,业务侧人员在面对敏捷的交付团队时,如何让自己变得更敏捷?其本质上是如何让业务和产品管理人员聚焦于价值,通过价值驱动决策,快速决定应该投资哪些产品功能,并创建产品待办事项列表用于交付团队开发。

EDGE是ThoughtWorks提出的一套基于组织的愿景和目标进行投资分配和监控的决策系统,立足于寻求企业投资组合管理价值最大化。它使得企业可以快速响应市场机遇,有效的将组织的战略目标与执行能力紧密的联系在一起。通过明确商业愿景、制定产品策略、专题分析和组合管理、制定最小可行产品、精益交付以及持续衡量价值来提升业务响应力。

实施策略和步骤

第一步:对业务管理机制达成共识

给业务人员、业务部门领导和业务线高层宣讲整个EDGE的业务管理机制,并达成共识。

第二步:通过精益价值树规划战略

业务人员邀请业务部门领导和业务线高层,建立精益价值树,从组织层面全局思考业务线商业愿景、目标、机会点以及行动方案。这部分非常重要,笔者在咨询过程中听到过业务人员经常猜测领导的想法,领导的话有时也被曲解,双方并没有以用户为中心。要想让业务部门从高到低所有人就战略达成一致,应当遵循精益价值树,如图2:

图2: EDGE(价值驱动产品组合管理)价值树

需要着重指出的是,精益价值树不是一成不变的。通常采用每季度组织工作坊的方式,根据市场运营的价值反馈对精益价值树进行评审,调整商业目标和后续投资。

第三步:采用可视化方法建立投资组合待办事项列表

将精益价值树中每个目标的愿景、核心价值和机会点可视化,并且对每个专题方案进行分析,输出投资组合待办事项列表,示例如下图3。

图3: 某银行专题分析示例

第四步:建立PVR(Periodic Value Review)评审与决策机制,审核及调整投资组合待办事项列表。

PVR会议由产品经理或产品负责人召集,邀请管理层、相关业务人员、市场、运营和技术专家共同参与,需要做如下事宜:

  • 回顾近期发布专题的用户反馈、运营数据,决策后续演进措施,包括是否需要调整产品策略
  • 产品经理讲解近期新的专题分析,共同讨论决策专题优先级
  • 审视和更新持续三个版本的滚动规划
  • 建议每月至少一次

第五步:通过MVP和滚动版本计划实现产品设计

滚动的版本计划将最高优先级的专题拆分为故事,分别规划到可以交付的版本中,形成持续几个迭代的滚动规划。

到此,就可以将待办事项列表中的用户故事交给交付团队开始迭代开发,进入传统的敏捷交付流程。

策略2:以产品为中心的交付

为了进一步明确这两者的区别,特对比如下:以项目为中心,其核心是以需求立项,带来的主要问题是项目周期长、需求力度大、反馈周期长、多并发项目、团队无节奏,直接结果是无法快速交付对终端用户有价值的产品;相比之下以产品为中心的交付,统筹所有需求、需求力度更小、采用持续滚动计划、团队节奏感更强,从而使得所有成员关注最有价值的高优先功能,持续交付价值。

企业创造产品的目的就是要解决用户或企业自身所面临的问题,因此以产品为中心也就是以解决问题为中心;相反,以项目为中心则是以计划、预算和职能为中心。

图4: 项目为中心交付流程 vs 产品为中心的交付流程

产品为中心的团队组建

虽然提到要“围绕产品组建跨职能团队”,但是传统金融行业的组织结构是典型的职能矩阵式, 业务部门通常在总部,开发、测试、运维部门分离,物理地理位置上也分离,很难做到理想的敏捷团队同地共置,即使是把开发和测试放在一起,也不容易;再加上外包团队,分布式团队更复杂。如何快速解决这种复杂的分布式团队的敏捷协作问题,各大银行纷纷借鉴学习了ThoughtWorks的Always-on工作模式来构建高效的分布式虚拟团队。

图5:Always-on可以帮助分布在不同地点的团队成员虚拟的面对面沟通,及时解决问题。敏捷12条原则中第四条“敏捷在整个项目开发期间,业务人员和开发人员一起工作”,这种Always-on的模式,就是为了实现这个原则。

策略3:差异化交付模式应对“快”与“慢”

差异化交付模式,是一个能够很好应对传统金融行业在“快”与“慢”的挑战下落地敏捷的一个可选方式。所谓“快”,就是变化快,需要快速响应,及时调整;所谓“慢”就是在已经非常熟悉的领域,可预测性强,需求变化慢。下面详细介绍如何使用这种模式实施交付。

差异化交付模式

差异化的交付模式如下图。模式1进行很多内部迭代,上线之前专门有个Launching阶段,与各个依赖之间进行联调测试,以免出现上线前的集成风险。模式 2结合了LSM(Lean Startup Methodology)以及Scrum,对于一个产品的研发包含:产品的Vision设置、概念剖析、MVP发布以及后续的持续迭代交付阶段。

图6: 差异化交付模式

模式1:长迭代与版本火车

不需要频繁的上线发布,而更强调稳定性。因此在每一个版本周期内以小瀑布方式完成计划、设计、开发和测试,并准备发布。开发过程以2到4周为迭代,可以在每个迭代结束时给业务和产品负责人做一次演示,尽早获得反馈;也可以更好的支持敏捷团队尽早开始联调测试。每年固定4或6个版本火车,各产品的版本节奏基于版本火车时间点对齐,利于进行跨产品间集成的协调和共同上线。某国际银行的Core Banking核心后台业务,也希望进行敏捷转型,选择了适合的模式1。

图7:版本火车

模式2:在进入迭代开发之后,就是传统的Scrum流程,迭代开发、持续交付。

差异化互相依赖的协作模式

作为前台系统,经常要与核心中后台系统做对接,差异化的两种模式进度如何匹配?具体实施方式如下:

  • 前后台Scrum团队密切合作,建立Scrum of Scrums机制,定期沟通,互相协调配合,提前规划好依赖日历,明确好先后顺序,并且避免两边需求偏离太远;
  • 从项目第一天开始进行系统集成,及时发现问题;
  • 有时候后台资源不足,这时候采用Mock服务的方式,先保证前台的功能满足业务需求,而后根据中间层的Contract ,作为接口需求,与后台系统集成;
  • 在上线前,后台会有长期的System Test、UAT 时间,这时候前台的开发计划尽量匹配后台的 ST 进行测试,以免出现上线前的集成风险。

图8:差异化交付协作方式

应对之策纵观

所有应对之策结合使用,其全局效果如下:

图9:应对之策全景图

写在最后

诚然,以上应对之策其实施流程不可谓不简单明了。然而,我们发现在过去几年的咨询过程中,企业高层在推动时却面临重重困难、层层阻挠。其本质原因在于,企业在变革过程中,推动变革的中坚力量是中层管理者,大量中间层管理者在企业响应力的提升以及责任承担方面起着举足轻重的作用。

如何撬动中层,确保以上策略落地。从组织级角度,需要提升其敏捷适应性领导力。Jim Highsmith作为敏捷宣言签署人之一提出的“适应性领导力模型”[1],要求管理者专注于如下行动:

  • 提升价值交付速度
  • 充满激情地改进质量
  • 少做:精益思考,交付客户必需的功能和稳定的产品,少即是多
  • 融入员工并持续激励他们

其核心思维转变如下:

  • 适应:从“完美计划以预防变化”转变为“接受变化”是不可避免的,唯一可控的是如何适应变化,拥抱变化
  • 探索:从传统的“计划并执行”模式,转变为设定愿景并持续探索,敢于挑战未知世界,从探索中学习并不断演进解决方案
  • 引导:从传统的“命令进而控制”思维转变为融入员工,引导建立自组织、自我约束的团队
  • 驾驭矛盾:从面临抉择时做“A或B”的选择、择其一个则牺牲其二,转变为处理好矛盾统一体,兼顾“A与B”创造性地提出新的更优解决方案

在合理采用以上策略之后,企业在不断敏捷化的道路上还将面临规模化的挑战。规模化并不是简单的从两三个小团队转到几百个团队的敏捷运作,其范畴更宽,囊括了整个企业的所有职能,包括财务预算、人力资源规划、安全与合规等,其终极目标是打造一个“持续创新的、高适应力、高绩效”的精益企业。

【作者介绍】

张岳,ThoughtWorks高级咨询师,近十年的软件行业从业经验,服务过电信、能源、金融等不同行业的客户,帮助他们交付软件产品、实施精益敏捷转型。

白玉,ThoughtWorks资深精益敏捷教练和高级咨询顾问,在金融、电信和教育行业的软件研发管理、咨询等方面有丰富的经验。

Share