【AICon】硅谷视野+中国实践,汇聚全球顶尖技术的 AI 科技盛会 >>> 了解详情
写点什么

想像亚马逊或 Netflix 一样酷?抱走敏捷转型五大秘籍

对于许多希望变得“更敏捷”的组织来说,他们实施敏捷转型的理由都是一样的。

  • 2018-11-01
  • 本文字数:4837 字

    阅读完需:约 16 分钟

想像亚马逊或 Netflix 一样酷?抱走敏捷转型五大秘籍
复制代码
成功的转型需要强大的领导力来支持和保护敏捷文化;
帮助团队和利益相关人等实现自组织;
借助结果(而不是输出)来管理项目;
系统性消除敏捷团队面临的浪费和延迟等问题;
通过频繁反馈(检查和调整)来评估和改进交付。

敏捷转型很困难,但有必要

随着数字化时代的到来,组织越来越希望变得更加敏捷。也许是因为损失客户、员工、市场份额或品牌价值倒逼这种需求出现;也可能是出于“攀比”的需要,希望像亚马逊或 Netflix 一样酷。对于许多希望变得“更敏捷”的组织来说,他们实施敏捷转型的理由都是一样的。

然而,对于许多组织来说,变得“更敏捷”的旅程开始时充满了错误——利益相关人不满意,领导者烦恼而困惑。变得敏捷是很困难的,这不仅仅是因为敏捷本身,而且还因为任何改变对于组织来说都是很困难的。尼古拉·马基雅维利说过这样一句话:

没有什么事比推行新秩序更难以掌控、更充满风险、更难以成功了。——《君主论》

而敏捷转型就是要建立一种新秩序,是比采用一种新方法或过程框架更根本的变革。世界著名经济学家 Carlota Perez 将这种变化描述为对数字时代的常识性反应。

如今,没有人会提出一个集中式的、僵化的、自上而下的组织结构,在这种结构中,除了通过老板之外,你无法跨职能进行沟通。然而,这正是 Alfred Sloan 在通用汽车创立的结构,在他那个时代占据了很大优势。借助现如今的通信和弹性技术,灵活的创造性网络更有意义,会产生更大的生产力。

Perez 继续写道,上一个时代的重点是大规模生产。从本质上讲,它与数字化生产是不同的。大规模生产关注的是降低单位成本,通过工艺优化、一致性、标准化提高质量。另一方面,数字化关注的是一个单位的规模,在这个单位中,所有的问题、解决方案和最终的价值流都是独一无二的。但是,有多少组织仍然使用同样的大规模生产模式来管理他们的数字化产品?对于结果、工作、团队和管理,敏捷时代都需要一种不同的方法。

关注结果——为业务价值负责

敏捷团队不是专注于以最具成本效益、一致性、风险趋避的方式完成工作,而是专注于以最有效的方式交付价值。他们关注的不是工作,而是他们想要交付的结果。Scrum 是世界上最流行的敏捷框架,其方法是以实验为依据的。因此,问题被分解成小的实验,通过密切观察来确定哪一项可能会导致变化。小批量的工作加上关注价值的需要意味着:

  • 所有权成为最优先考虑的事情——在大多数传统的组织中,决策是以一种缓慢而一致的方式做出的。使用文档保存详细信息,通过签名确保每个人都知道涉及到谁。变更被视为一个问题,涉及昂贵的管理过程、审查委员会和升级方法。敏捷需要做出决策,需要根据反馈改进交付的工作。

  • 价值需要能够清楚地理解和度量,这似乎是一个简单的要求——事实上,很多工作与价值之间没有明确的联系。度量也是非常困难的,因为组织需要设法解决可见性、透明性和所有权。

  • 团队必须与客户保持一致——通常,团队对他们与客户的关系知之甚少,即使他们可以从了解客户获得好处,但他们既没有与客户保持一致,也没有访问客户。客户由前端的业务、销售、营销和支持部门来管理。产品开发必须与这些组织合作以获取反馈。

  • 经常了解需要经常观察——对于数字化产品,这意味着要将它们交付给客户使用。频繁交付对从需求管理到产品测试的开发过程的每个部分都有巨大的影响。为了支持更小更频繁的变更,底层软件的架构方式也会改变。对于非数字产品或混合产品,频繁收集反馈的需要也改变了工作方式,团队更关注频繁地评审、模拟和测试。

工作并非归管理者所有

在新的敏捷世界中,不可能要求人们在相同的广度或深度上完成特定的任务或计划。工作是由被授权的团队定义、管理和执行的,这些团队不关注任务,他们关注的是需要设法实现的结果。质量,包括技术债务在内,其处理方式与价值的处理方式相同,团队和业务在权衡的基础上做出明确、透明的决策。但是,从传统的管理工作转向更敏捷的方法,不仅需要管理人员走开,也需要组织:

  • 明确责任制和所有权——在大多数现代化组织中,每个人都有责任,但没有人负责。在敏捷组织中,很明确,团队要对结果负责,业务要决定团队在价值方面把重点放在哪里,组织要负责为团队的成功创造环境。通过明确责任和允许团队做出决策,敏捷组织可以大幅减少与传统自上而下的管理方法相关的大量浪费。

  • 管理层专注于建立适当的环境——许多管理者得到他们的职位是因为他们擅长工作。这导致了一种“家长主义”的文化,管理者告诉人们该做什么。对于简单的工作,这可能是有效的,但当工作变得复杂,流程变得多变,很难要求管理者始终在那里。因此,管理角色必须转变为教练和仆人式领导,帮助团队处理工作并关注结果。

  • 用产品替代项目——对于许多组织来说,工作是通过项目完成的,任何时候都有成千上万的项目在进行。每个项目都有资金、资源和大量的文档。人们在多个项目上工作,团队经常创建和解散。敏捷并不强迫组织不去做项目,而是鼓励组织采用一种更集中的、以团队为中心的工作方法。通过减少项目并转而向产品或客户看齐,团队可以更好地关注结果。其他的好处还有计划周期更简单、沟通的复杂性更低以及令人提心吊胆的上下文切换问题更少。项目仍然存在于跨多个客户 / 产品 / 结果边界的计划中,但它们不是常态。

团队是真实存在的

敏捷组织的核心是一系列自组织、有决策权的团队。他们拥有交付价值所需的所有合适的技能,并且,组织支持他们填补任何空白并帮助他们变得更好。在规模很大的情况下,这意味着团队的团队以及采用确保可以有效管理依赖关系的实践。但是与大规模生产不同的是,敏捷组织并不是从“把很多人投入到一个问题上”获益,而是鼓励更精简、“更聪明”的组织模型。组织可能需要通过以下方式改变他们对待团队的方式:

专注于构建长期团队——对于组织来说,团队并不是一个新概念,事实上,对于许多组织来说,他们都非常喜欢把人安排到多个团队的理念。敏捷组织鼓励更专注的、以人为中心的模型,团队有身份认同和协调一致的成员。也就是说,工作被带到团队中,而不是围绕着工作形成团队。对于许多项目管理组织而言,这需要思维和流程的变革。

将工作管理与人员管理分离开来——当对你进行评估、决定你的奖金和晋升机会的人每天都和你一起工作时,很难做到透明。通过在敏捷团队中明确地将工作管理和人员管理分离开来,可以鼓励透明度和开放性。工作由团队管理,人才的发展与管理要么由某种社区或协会管理,要么由更传统的管理层管理。

组织结构逐步向客户演化——对于许多组织来说,个人与应用程序一致,而这些应用程序在许多不同的客户或价值上下文中被重用。这就导致了每件事都会相互影响的复杂性。现代化的敏捷企业结构关注的是针对敏捷性进行优化。这可能意味着有些东西是重复的,单个应用程序的总拥有成本可能更高,但最终响应市场需求的价值超过了这个成本。优化根据其在栈中的位置进行,就像之前修改磁盘空间或整理的成本那样。

多样性很重要——要应对复杂的问题,需要有经验的团队具有各种不同的观点和技能。意见、想法和解决方案的多样性对实现价值至关重要。但是,对于许多组织来说,团队边界重新加强了部门、系统和经验的边界。对于敏捷地开展工作,对于组织交付优秀的客户解决方案,构建挑战现状、看上去大不相同的多样化团队是很重要的。

敏捷转型的五项挑战

进入“新秩序”并不容易,许多组织已经开始了采用 Scrum 的旅程,并且正在考虑扩展框架,如 LeSS、SAFe 和 Nexus,以及像 Spotify 这样的组织模型。遗憾的是,没有一种通用的方法可以将组织“转换”成敏捷的数字原生企业。查看组织框架和扩展模型是很好的工具,但只是其中的一部分,因为这一举措需要更全面的敏捷方法。也不能将其视为是用一种方法代替另一种方法,而应该看成是对于组织市场响应和价值交付方式而言更基本的东西。组织应该专注于 5 个广泛的挑战。

通过强大的领导力来支持和保护敏捷文化
帮助团队和利益干系人实现自组织
借助结果(而不是输出)来管理项目集合
系统性消除敏捷团队面临的浪费和延迟源
通过频繁反馈(检查和调整)度量和改进交付的价值

通过强大的领导力来支持和保护敏捷文化

组织文化是由组织制定的工作规范来定义的。领导者在行动和语言上定义并强化了这些规范。可以体现敏捷价值并强化其原则的领导者对任何转型都至关重要。例如,敏捷需要一种持续的学习和理解方法,但是,如果领导者专注于错误和责任分摊,那么很可能任何经验性过程都不会奏效。

帮助团队和利益干系人实现自组织

创建一个环境,使团队自组织并有权做出交付价值决策是敏捷的基础。遗憾的是,仅仅告诉团队他们获得了授权,并且可以自组织,这并不是引入这些理念的有效方法。相反,变革需要渐进引入,而类似管理 3.0 中的“授权板(Delegation Board)”这样的实践可以帮助团队慢慢获得主动地位。

借助结果(而不是输出)来管理项目集合

和任何事情一样,敏捷只会和你关注的结果一样好。通过构建一个关注客户成果而不是工作的敏捷企业,你不仅可以实现更好的一致性,而且还可以推动一个清晰的愿景和目标。传统的组织总是关注系统,只有组织的一小部分与客户和他们所追求的结果联系在一起。现代化的敏捷企业把结果作为客户需求的核心,让每个人都对结果负责。

系统性消除敏捷团队面临的浪费和延迟源

浪费不是效率的敌人,而是价值的敌人。敏捷团队的浪费是任何阻止他们交付价值和改进的东西。诸如移交给外部部门这样的浪费浪费了花在审查会议上的时间。要变得更敏捷,把一切都放在“清除浪费”的议程上,没有什么是“一成不变”的。这意味着,诸如财务、审计和遵从性之类的组织需要成为变革的一部分,使他们以变革的视角审查现有的流程。规划通常是一个存在浪费的领域,长期的规划周期和变更管理过程占用了关键利益干系人和交付团队的宝贵时间。在 Scrum 中,浪费的管理是通过在每日 Scrum 中把它们透明化,并在冲刺评审和回顾中讨论改进。但是,除了任何特定的框架之外,敏捷团队都以学习和改进的眼光看待一切。他们也有挑战现状的勇气。

通过频繁反馈(检查和调整)度量和改进交付的价值

如果你打算通过衡量一件事来确定一个企业是否敏捷,那就是他们多久一次让他们的客户、利益干系人和团队来检查交付项。获得关于所交付内容的真实使用数据,以及创建最简单的东西以获得反馈,这是敏捷的基础。以客户为中心的敏捷组织亚马逊以每 11.6 秒交付一次软件而闻名。不是因为它想要增加更多的功能,而是因为它想和客户一起尝试新的想法,并得到客户的反馈。

小结

这似乎有点讽刺意味,但许多组织认为向敏捷转型就像使用传统的方法爬山一样。制定计划,寻找资源,然后执行。但是,成为一个敏捷企业不仅仅是采用一个特定的过程框架或者改变职位名称。这是你对市场响应方式的根本性改变。组织模型、过程、工具,甚至是基础产品都会根据客户、市场和利益干系人的需求而频繁地改变。敏捷企业的核心是一个以客户为中心的学习型组织。Peter Senge 在其著作《The Fifth Discipline - The Art & Practice Of The Learning Organization》中描述了组织专注于学习的必要性。

“唯一可持续的竞争优势是一个组织比竞争者更快速地学习的能力”。

最终,通过专注于敏捷领导力、自组织、以客户结果为中心、消除浪费以及了解组织文化并频繁交付这 5 项挑战,组织将变得更加专注于学习并变得更加敏捷。

作者简介

Dave West 是 Scrum.org 的产品负责人和 CEO。他经常在主要行业会议上发表主题演讲,并发表了许多文章和研究报告。他还与人合著了两本书《The Nexus Framework For Scaling Scrum》和《面向对象的分析与设计》。他领导了 IBM/Rational Rational Unified Process(RUP)的开发。在 IBM/Rational 之后,West 重新回到了咨询行业,并负责 Ivar Jacobson 咨询公司北美分公司的管理。然后,作为副总裁兼 Forrester Research 研究总监,他负责软件开发和交付实践。在加入 Scrum.org 之前,他是 Tasktop 的首席产品官,负责产品管理、工程和架构。作为公司高管团队的一员,他帮助 Tasktop 从一个服务公司成长为一家团队将近 100 人的、VC 支持的产品公司。

2018-11-01 17:342499
用户头像

发布了 40 篇内容, 共 13.7 次阅读, 收获喜欢 6 次。

关注

评论 1 条评论

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

生产环境 TiDB V5.0.3 集群部署

TiDB 社区干货传送门

实践案例

SQLserver迁移TiDB场景的实践

TiDB 社区干货传送门

迁移 管理与运维

TiDB K8S 删除备份阻塞问题排查

TiDB 社区干货传送门

TiDB 底层架构 管理与运维

TiDB 集群跨平台在线迁移方案(离线环境下从 x86 节点迁移到 arm64 节点)

TiDB 社区干货传送门

管理与运维

TiDB 集群 TiKV 节点内存占用较高问题排查

TiDB 社区干货传送门

故障排查/诊断

【TiDB CPU使用率过高之一】Scheduler worker CPU

TiDB 社区干货传送门

实践案例

TiDB for PostgreSQL 学习指南

TiDB 社区干货传送门

实践案例 管理与运维

TiDB 在 2021 易车 818 汽车狂欢节的应用

TiDB 社区干货传送门

实践案例

【SOP 系列 19】region 分布不均问题排查及解决不完全指南

TiDB 社区干货传送门

管理与运维

TiDB在X86和ARM混合平台下的离线部署和升级

TiDB 社区干货传送门

安装 & 部署

TiDB集群的GC不回收案例(案情二)

TiDB 社区干货传送门

故障排查/诊断

TiDB 配置参数修改与系统变量修改步骤

TiDB 社区干货传送门

实践案例

TiDB K8S 定时备份状态异常问题排查

TiDB 社区干货传送门

管理与运维

【联合方案】神州信息 - 新一代分布式网贷系统

TiDB 社区干货传送门

实践案例

【TiDB 最佳实践系列】海量 Region 集群调优

TiDB 社区干货传送门

实践案例

SQL上线引发的血案

TiDB 社区干货传送门

伴鱼数据库之性能大盘

TiDB 社区干货传送门

事务前沿研究丨事务测试体系解析

TiDB 社区干货传送门

TiDB 底层架构

TiDB和MySQL的锁一些分析比对

TiDB 社区干货传送门

实践案例 TiDB 底层架构

干货分享丨携程国际业务动态实时标签处理平台实践

TiDB 社区干货传送门

实践案例

【精选实践】58 集团的数据库技术选型思路

TiDB 社区干货传送门

数据库架构选型

使用 TiCDC 实时同步 TiDB 数据到备用逃生环境的实践

TiDB 社区干货传送门

实践案例 安装 & 部署

从TiDB中学习代码提交规范的重要性

TiDB 社区干货传送门

TiDB 底层架构

扩容TIKV节点遇到的坑

TiDB 社区干货传送门

管理与运维

TiDB SQL调优实战——索引问题

TiDB 社区干货传送门

性能调优 实践案例

TiDB 对大事务的简单拆分

TiDB 社区干货传送门

性能调优

TiDB 入门运维基础教程(二)--生产环境安装

TiDB 社区干货传送门

安装 & 部署

TIDB:分布式事务算法Percolator学习笔记

TiDB 社区干货传送门

TiDB 底层架构

TiDB 集群跨平台在线迁移方案(离线环境下从 x86 节点迁移到 arm64 节点)

TiDB 社区干货传送门

管理与运维

Tidb duration 耗时异常上升案例

TiDB 社区干货传送门

故障排查/诊断

TiDB SQL 自动重试调研

TiDB 社区干货传送门

TiDB 底层架构

想像亚马逊或 Netflix 一样酷?抱走敏捷转型五大秘籍_架构_Dave West_InfoQ精选文章