规模化敏捷发展三部曲：敏捷领导力、运转敏捷和整体敏捷

多数公司领导如今对敏捷创新团队都有所了解。敏捷创新团队规模较小、具有创业性质，和客户关系密切，能快速应对多变的商业环境。

若应用得当，敏捷团队相较于传统部门，具备以下优势：生产率更高、士气更高、产品交付速度更快、质量更好、风险降低。

所以，了解或体验过敏捷团队的领导，自然会有许多感兴趣的问题。比如说，公司能不能在内部实现数十个甚至成百上千个敏捷团队？业务各个细分市场能否都按敏捷方式运营？整个组织敏捷化，是否和单个团队敏捷化效果一样好？

目前的市场环境动荡，在位企业不断遭到初创公司等竞争对手的挑战，保卫战如火如荼，如果能增强自身适应性，变得更加机动灵活，这对企业来说极具吸引力。但愿景虽好，成真不易。企业往往难以辨别哪些部门可以重组为跨学科的敏捷团队，哪些不能。另一种常见情况是：企业准备启动数百个全新的敏捷团队，在落地时却受到低效的官僚体系掣肘。

我们研究了数百家企业的敏捷规模化，有些小公司运用敏捷法运营整个公司；还有一些大企业在创立之初就具备敏捷基因，在发展中不断强化，例如Spotify和Netflix；另外还有类似亚马逊和USAA(美国联合服务汽车协会)这种，从传统层级结构向敏捷化过渡的公司。一些企业取得成功，另一些则失败了。例如，一家著名工业公司过去5年一直在效仿精益创业的创新方式，但至今都未能实现维权投资者和董事会期待的财务结果，几位高管不得不在最近引咎辞职。

我们的研究表明，能够有效完成敏捷规模化的公司受益匪浅。但领导者务必要脚踏实地。要注意没必要将所有部门都敏捷化，敏捷方法也不是放之四海而皆准。公司一旦启动了数十个或数百个敏捷团队，不能对其余部门置之不理。如果重组的敏捷团队得不到运营部门和其他创新团队的配合，又不断被官僚主义掣肘，机构内部的摩擦引发的星星之火，会拖垮整个组织，导致不良后果。公司要进行改革，确保敏捷团队能获得其他部门的支持。

知行合一的领导力

如果你还不太了解敏捷，先作一简单介绍。敏捷团队最适用于创新，即用于改良产品、服务、流程或业务模式的盈利性的创造力应用。敏捷团队规模较小且跨学科，而创新团队常常会遇到复杂的大型问题，要将其拆解成不同模块，通过快速试制原型和紧密的反馈回路，找到每个模块的解决方案，然后把所有方案整合为有机整体。这样的团队更看重随机应变而非墨守成规，对结果（增长、盈利能力和客户忠诚度等）而非产出（代码数量或新品数量）高度负责。

公司遇到的问题如果很复杂、没有清晰的解决方案，项目要求可能随时变化，和终端用户能紧密合作，创造力团队比指挥-控制团队表现更好，就具备了使用敏捷团队的条件。而设备维护、采购和财务等日常运营部门则不太适合采用敏捷法。最初使用敏捷法的是公司的IT部门，现在则被广泛应用于软件开发。产品研发、营销甚至人力资源部门也逐步加入。（见《哈佛商业评论》2016年5月刊文章《拥抱敏捷》及2018年3月刊文章《HR迈向敏捷》）

敏捷团队的管理方式有别于层级体系，多采用自治：高管会告诉团队成员创新方向，但不对具体方法发表意见。团队从内到外都和顾客紧密联系。理想情况下，创新的责任就落在了和客户最紧密的人肩上，减少了中间层对流程的控制，提高了工作速度，更好地激励了团队。这也让高管能集中精力完成本职工作：树立并传达长期愿景，制定战略优先级，构建实现这些目标所需的机构能力。

领导者如果没有理解敏捷方法就仓促使用，可能以为它和其他变革的推行方式一样——通过上情下达的规划和指令。但如果他们能使用敏捷方法，则有更好效果。具体做法是，将各个部门当成和顾客一样有不同需求的群组，随着敏捷化的发展，需求也不断变化。管理层列出工作优先事项，为提高顾客体验，成功完成任务，将不同机遇排序。领导者不把任务委派给下属，而是亲自解决问题、扫清障碍。敏捷领导力团队和其他敏捷团队一样，由“项目负责人”（initiativeowner）负责整体结果，流程促进员则负责指导成员、确保参与度。

博世（Bosch）公司案例

全球领先的技术服务供应商博世（Bosch）公司就采用了这种方法。博世拥有40多万名员工，分公司遍布60多个国家。领导者发现，在快速变化的全球化市场环境下，自上而下的传统管理方式已然失效，于是博世成为较早采用敏捷方法的公司。然而，不同业务需要不同方式，博世最初尝试的是“双机构”模式，也就是由敏捷团队运营炙手可热的新业务，传统部门则维持原状——也因此未能实现整体变革。

2015年，由CEO福尔克马尔·登纳（Volkmar Denner）领导的管理委员会成员决定，在全公司推行敏捷化。委员会充当指导委员会，任命软件工程师、敏捷专家菲利克斯·希罗尼米（Felix Hieronymi）领导变革。

起初，希罗尼米准备按博世大多数项目的管理方式，来管理这一项目：设立目标，预计完工日期，定期向董事会汇报进展。但这一方法似乎偏离了敏捷原则，公司上下怀疑它将沦为另一个中央控制的项目。因此，团队转变了方向。

“指导委员会变成了工作委员会，”希罗尼米告诉我们，“大家讨论时热烈了很多。”团队重新梳理了公司的积压优先事项，并按照等级排序，重点扫除敏捷化障碍，拓展敏捷化范围。委员会全体成员和各部门领导对接，“按公司最初战略，该计划为期一年，现在不设截止日期，持续进行。”希罗尼米说，“管理委员会进一步拆分为敏捷小组，试验各种方式——有些和‘产品负责人’及‘敏捷专家’合作，解决难题，研究基础性问题。其中一个小组草拟了2016年发布的十个新领导力原则。成员亲身体验了工作速度和效率提升的成果，获得了理论学习无法带来的感受。”

如今，博世公司既有敏捷团队，也有传统部门，但几乎所有领域都使用敏捷价值观，合作更见成效，面对快速变迁的市场，反应更及时。

博世等领先的敏捷企业在愿景上志存高远，但在奉行敏捷原则方面，领导层并未事先规划好细节。领导层意识到，自己并不知道企业究竟需要多少敏捷团队，如何把握转型节奏，怎样在不陷入混乱的情况下，解决官僚制度带来的问题。

典型做法是，领导者先启动一批敏捷团队，收集这些团队创造的价值数据和所遇障碍，决定是否继续变革，以及变革的时间和方式。他们可以通过比较敏捷团队所带来的价值（财务结果、客户结果、雇员表现）和公司投入成本（资本投入和组织挑战）之比。

若收益大于成本，公司继续敏捷化——部署新团队、扫清组织障碍、重复这个周期。若收益小于成本，公司就暂缓计划、监测市场环境、尝试提高现有敏捷团队的价值（例如改变工作优先事项或升级原型设计能力），并降低变革成本（宣传敏捷带来的收益或聘请经验丰富的敏捷专家）。

领导团队通常会使用两种必要工具启动这个“测试-学习”循环：对潜在团队的分类和工作优先事项的排序。我们先来看看如何使用这两种工具。然后再探讨如果要完成大规模、长时间的敏捷项目，还需要什么。

团队分类

敏捷团队会把未完成的积压工作整理出来。成功完成规模化敏捷的企业也会做类似的事，将所有机遇进行分类。

他们可能会按敏捷的模块化方法，将其分成三个类别：客户体验团队、业务流程团队和技术系统团队，然后再整合。

第一个类别包括所有影响外部及内部顾客决策、行为和满意度的关键因素，通常分为十几种关键体验（例如，零售业顾客的关键体验之一是购买产品及支付），接着再分为更具体的十几种体验，（顾客选择付款方式、或使用优惠券、用积分兑换、完成结账并拿到小票）。

第二种类别研究体验间的关系和关键业务流程（例如提高结账速度，减少排队时间），目标是厘清责任并增加流程团队和客户体验团队间的协作。

第三类聚焦于技术系统升级（例如更优化的手机结账应用程序），借此提高对顾客体验团队的支持。

如果对价值100亿美元的公司做这种分类，大概能得到350-1000多个潜在团队。数字看上去吓人，高管们往往不愿面对这样量级的变革（“要不我们先试两三个，再看看情况？”）。但分类的价值是，有助于企业探索变革未来，并将过程拆分为具体步骤，任何时间都能暂停、变换方向或停止转型。同时，它也能帮助领导们看清障碍。

比如，一旦我们确定要转型的团队和人员类型，领导就必须回答以下问题：公司有没有这类人才？如果有，他们在哪儿？分类会让你看清人才缺口，并了解到该如何通过招聘或重新培训填补缺口。领导者还能看到，每个潜在团队能为改善顾客体验做出哪些贡献。

USAA目前有500多个敏捷团队，计划在2018年再增加100多个。该公司的分类情况对所有员工公开。COO卡尔·利伯特（CarlLiebert）告诉我们，“如果做不好分类，公司会人浮于事，事倍功半。”“如果我在全体员工面前提问，‘谁负责会员更改地址体验？’我希望负责的相关团队能清晰自信地作答。（希望）无论是会员服务热线，用笔记本登录网站或者手机app（都有相应的负责人）。大家不互相推诿，不会听到‘这事儿很复杂……’这样的解释。”

USAA通过分类，把敏捷团队的工作内容，和业务部门及产品线负责人联系在一起。这样做是为了确保对公司损益表负责的高管明白，团队跨部门协作会给他们带来什么影响。企业中某些高管的角色相当于业务部门总经理，对该业务负全责。但他们工作的很大一部分，需要顾客导向的跨部门团队为其完成。此外，还要依赖各类体验负责人所获得的技术和数字资源。

之所以进行分类，目的是确保业务负责人拥有完成业务目标所需的端到端资源，让他们能够将合适的人安排在恰当的位置，避免发生混乱。在官僚体系和顾客行为错配时，这种联系尤为重要。比如说，很多企业线上和线下业务的运营构架和损益情况是分离的，但顾客却想要无缝整合的全渠道体验。在这种情况下，企业如果分类清晰，能组建起恰当的跨部门团队，就有可能实现这样的对接。

转型次序

完成分类后，领导团队下一步就可以安排工作优先级和项目次序。领导者必须要考虑多种标准，包括战略地位、预算限制、人员能否到位、投资回报率、延误成本、风险级别以及团队间的相关性。最重要也是最容易被忽视的有两个，一个是顾客和员工的痛点，另一个是组织的能力和存在的障碍。它们决定了转型节奏，以及机构能同时管理的团队数量之间的平衡点。

一些企业形势严峻，急需彻底变革、调整战略，因此在转型时，对某些部门采取了大爆炸式、全面出击的方式。

例如2015年，荷兰ING银行集团预计，消费者对金融解决方案的需求将大幅增加，数字化对手（“金融科技”）的竞争威胁日益加剧。管理团队决定激进地完成变革。公司将最具创新性的部门，例如IT研发、产品管理、渠道管理和营销部门的构架推倒重建，基本上撤销了所有职位，重新设计了拥有2500个职位的敏捷“小分队”，让近3500名员工去申请。成功入选的员工中，约40%需要重新学习工作内容，几乎所有人都要从根本上改变思维方式。（见《哈佛商业评论》2018年3月刊的《ING的敏捷团队实验》一文）

但大爆炸式的转型相当困难。领导层需要全心投入，企业需具备接纳型文化，并储备有经验丰富的敏捷专家，足够支持数百个团队，同时不破坏其他能力；企业有高度规范的操作手册，便于整体步调一致；还需要对风险有较强容忍度，准备好应急计划，以防出现意外故障。ING在敏捷化过程中，一直在不断处理各种层出不穷的小问题。

缺乏这类资源的企业，最好按测序步骤逐步敏捷化，面对机遇，每个部门在实践时要量力而行。以3M公司为例，在敏捷项目启动之初，该公司卫生信息系统的先进技术小组，每个月或每两个月组建8-10个团队。两年后，90多个团队正常运行。而3M公司研究系统实验室稍后也加入转型，但每三个月只组建20个团队。

不同节奏或终端的结果都会很快显现，但财务表现则要等待一段时间。亚马逊CEO杰夫·贝索斯（Jeff Bezos）认为，多数计划都需要5-7年时间才能看到红利。但如果在消费者行为和团队问题解决方面，出现积极的变化，那就意味着变革走在正确的道路上。 “敏捷方法提高了我们的产品交付速度，测试版应用的发布比原计划提前了6个月。” 3M公司卫生信息系统的高级项目经理塔米·斯百若（Tammy Sparrow）告诉我们。

和敏捷团队一样，部门领导可以决定转型顺序，应当率先选择有潜力创造最大价值和最多学习信息的项目。

软件公司SAP在十年前就开始了转型，是最早完成敏捷规模化的公司之一。SAP从软件研发部门开始推行敏捷，该部门客户导向程度高，可以测试并优化敏捷方法。领导团队组建了咨询小组，负责培训、指导、嵌入新工作方法，并使用结果追踪工具，让大家清晰地看到成果。“用实实在在的例子向大家展现出敏捷法带来的生产率提升，这增强了组织内部对敏捷的兴趣。”当时咨询小组负责人塞巴斯蒂安·瓦格纳（Sebastian Wagner）说。接下来的两年间，公司在超过80%的研发团队中推广了敏捷法，创造出2000多个团队。销售和营销部门的员工为了能跟上步伐，相继敏捷化。一旦公司的前端部门快速转型，后端要马上跟上，因此SAP内部的IT系统也采用了敏捷方法。

然而很多企业想走捷径，却适得其反。面对系统化障碍，它们选择绕道而行，将团队交给外部孵化器。“温室培育”的方法也许会提高单个团队成功率，但无法在机构中创造学习环境，也不能带来变革，这些都是敏捷规模化必不可少的。公司第一批敏捷化的团队肩负着最终能否成功的重担。企业要像测试原型那样，在多样化的现实条件下测试这些团队。SAP等在这方面最成功的企业，都很重视关键客户体验，即孤岛部门最难解决的棘手问题。

无论如何，敏捷团队都应该准备充足再进行实践。充足并不代表计划详尽、胜券在握，而是这些团队：

聚焦于一个利益攸关的重大商业机遇

对具体结果负责

可以独立自主地工作——拥有清晰的决策权、合适的资源，团队成员为跨学科专家，人数虽不多，但都对这个机遇充满热情

承诺使用敏捷价值观、原则和实践

有权和顾客紧密合作

能够快速设计出原型，拥有快速反馈回路

拥有高管的支持，能够为其扫清障碍，并推广团队工作成果

按照这个列表自检，可以帮助你安排出对顾客和机构都拥有最大影响力的测试顺序。

完成大规模敏捷项目。许多高管难以想象小的敏捷团队可以完成大规模的长期项目。但原则上讲，敏捷团队的数量和项目规模并无上限。你可以在相关项目中，分离出“组中组”，这种方式扩展性很强。

举例来说，瑞典公司萨博（Saab）的航空业务部拥有100多个敏捷团队，负责软件、硬件，以及价值4300万美元、堪称全球最复杂产品之一的“鹰狮”（Gripen）战斗机机身的制造。该项目通过每日组中组的站会（stand-ups）协调工作。每天早上7：30，一线敏捷团队进行15分钟站会，列明工作中遇到的障碍，其中一些无法在组内解决。7:45，该小组将需要其他部门配合的障碍上报给另一个组中组。领导们可以选择解决该问题，或继续上报。接着不断重复这一方式，直到8:45，主管行动组拿到一份关键问题清单，想保持工作进度必须解决清单上的问题。航空业务部门协调团队的方式是：采用通用的为期3周的“冲刺”（sprints，创造迭代产品的一个周期——译者注）；制定项目总计划（一份动态文件）；让过去分散各处的部门同地办公。例如，让试飞员和模拟器组加入研发团队。这样做的结果相当显著：简氏信息集团（IHS Jane's）将鹰狮战斗机认证为全球成本效益最好的军用飞机。

在建立敏捷团队之后，协调其与传统架构部门之间的合作同样重要。下面将从四个领域进行阐释。

增加敏捷团队的数量是提高业务整体敏捷度的重要步骤。但这些团队和机构其余部门之间的互动也同样重要。即便最先进的敏捷企业，例如亚马逊、Spotify、谷歌、Netflix、博世、萨博、SAP、Salesforce、拳头公司（RiotGames）、特斯拉以及SpaceX等，都是既有敏捷团队，也有传统构架部门。为了确保官僚部门不给敏捷团队的工作造成障碍，不妨碍敏捷团队的创新成果商业化，这些企业一直在以下四个领域不断推进更深入的变革。

1价值观和原则

如果敏捷团队的数量不多，可以“寄居”在传统层级结构之中。部门间的冲突可以通过个人交流或变通的方法解决。但当公司推出数百个敏捷团队时，寄居就行不通了。敏捷团队在各方面以势不可挡的速度推进工作，而传统部门则誓死捍卫现状。面对任何变革，怀疑论者都能制造出攻击敏捷的抗体，包括拒绝配合敏捷团队时间表（“抱歉，我们没法按你说的6个月就完成这个软件模块”），或者在需要新式解决方案的大机遇面前，拒不拨款。

因此，领导团队如果希望规模化敏捷，就要逐步在机构中渗透敏捷价值观和原则，不转型的部门也要参与。这也是为什么博世领导层决定创建新领导力原则，并在全公司实施：他们希望每位员工都能意识到变革正在发生，敏捷将成为企业文化的核心。

2运营架构

在全公司推行敏捷，需要模块化和无缝整合工作流。例如，亚马逊公司每日能部署上千个软件，因为其IT构架的设计就是为了帮助开发人员在不损害公司复杂系统的情况下，快速、高频地发布内容。但在很多大型公司，无论开发人员编程速度多快，每日或每周部署的软件数量也有限，这是由其架构决定的。

丰田公司首创了应用在产品研发的模块法，特斯拉公司在此基础上精心设计了汽车不同组件间的接口，以便各模块独立创新。因此，保险杠团队可以随意改动，只要和其他部件的接口保持稳定即可。为了实时回应顾客反馈，特斯拉还抛弃了传统的年度发布周期。CEO埃隆·马斯克（Elon Musk）表示，为了改进Model S的制造和性能，公司每周会完成约20项工程改动。改动包括新电池组、更新版本的安全及自动驾驶硬件、自动调节方向盘及座椅让驾驶员进出更方便的软件等。

在大多数先进的敏捷企业中，创新产品和流程架构为了进一步敏捷化，需要扫除组织中最棘手的障碍。美国拳头公司研发出广为人知的多人在线竞技类游戏《英雄联盟》，该公司重新设计了敏捷团队和传统支持-控制部门（包括设备部门、财务部门和人力资源部门）之间的关系。

该计划的产品负责人布兰东·熊（Brandon Hsiung）说，过程包括两个关键步骤：

第一，转变这些部门对顾客的定义。“它们的顾客并非部门经理，也不是CEO和董事会，”他解释说，“他们的顾客是服务的研发团队，而这些团队最终服务的是我们的用户。”公司设立了净推荐调查，搜集反馈，调查这些顾客是否会向他人推荐某些部门，并清楚表明，如果顾客不满意，以后可能外包这部分工作。“我们都不想走到那一步，但公司必须确保所有部门都拥有在自由市场竞争的顶级能力。”熊说。

第二，拳头公司还改造了公司职能部门和敏捷团队的互动方式。职能部门的一些员工被安插在敏捷团队中，或者分出一部分人员专门处理敏捷团队的要求。还有一些部门，在和敏捷团队沟通并划清界限后，基本上很少有正式交集。熊说，“没有相关性的部门，例如不动产和培训及研发部可能会公布自己的工作方式、指导原则及规则，然后申明‘这是我们的方针，只要你不违反，随便做什么都行，只要为用户好，都可以尝试’。”

成功实现敏捷规模化的企业，支持部门的组织结构图和日常运营和过去没有太大变化，可能管理层级减少了，管理幅度扩大了，因为主管懂得信任和赋权手下。更大的变化是职能部门的工作方式。职能部门的工作优先项往往和企业战略更加一致。如果一家公司的主要任务是提高顾客的移动体验，这件事就不可能排在财务经费表或人力资源招聘方案的第15项。法务等部门可能需要缓衡容量，应对来自高优先级敏捷团队的紧急要求。

假以时日，传统层级结构的日常运营部门，也很可能发展出更敏捷的思维方式。财务部门当然还是负责管理预算，但它们不需要总是质疑敏捷项目负责人的决定。“我们的CFO一直在下放权力给敏捷团队，”拳头公司研发管理负责人艾哈麦德·西德基（Ahmed Sidky）说，“他会说，‘我的工作不是管理整个公司的财务，这是你作为团队领导的工作。我只是你的顾问。’在日常工作中，财务部门的合伙人会加入具体团队。他们并不掌控每个团队的计划，更像是财务导师，提出尖锐问题，提供深度的专业知识。最终做决定的是团队领导者，站在拳头公司所有用户的角度，为他们做出最好选择。”

一些企业和个人也许很难接受这种放权，实践难度也太大。减少控制总是令人不安，直到你尝试并发现大家的情绪有所改善，成功率也高了三倍。贝恩近期调研了近1300名全球高管，这一说法获得了最多人的赞成。 “今天的商业领袖必须学会信任和赋权，而不是管理和控制员工。”（只有5%不同意）

3招贤纳士，激励人才

成功敏捷化的企业需要招贤纳士的系统，并激励人才不断推动团队进步。如果你不善待明星员工，他们会忽然被性感的初创企业挖走。还需要释放出更多普通员工被浪费的潜力，构建共同为结果负责的敬业心和信任感。如果不改变HR流程，无法做到这些。例如，在选择人才时，企业不应只看重专业能力。现在公司需要既有专业能力，又热爱协同工作的人。在评估员工时，企业也不能只审查他/她是否完成个人目标，而要审查员工在敏捷团队中的表现，并参考同事评价。

年度绩效评估一般变为由系统几周或几个月提供一次反馈和指导。培训和指导项目，有利于员工获得定制化的跨职能技能发展。在自治团队和简化的层级结构中，头衔变得不那么重要了，相对也会比较稳定。职业通道要体现出产品负责人，即制定愿景并对敏捷团队结果负责的人，可以如何获得个人发展、拓展影响力并提高薪资待遇。

企业可能还需要修改薪酬体系，奖励团队而非个人成就。企业要及时奖励和认可员工的贡献。从倡导敏捷价值观角度讲，公开认可比私下给予现金奖励更好，因为这样可以激励获奖者继续进步，同时鼓励其他人向他学习。领导者奖励最佳员工的方式包括，给予他们最关键的机遇，最先进的工具和最大程度的自由度，并为他们联系行业内最具才华的导师。

4年度规划和预算周期

官僚制度的企业，往往将年度战略会议和预算计划作为统一各部门，确保上下一心、实现延展性目标的强大武器。但敏捷团队的运行规则有所不同，它们认为顾客的需求不断变化，突破性洞见随时可能发生。在敏捷团队眼中，年度周期会限制创新及适应性：低效项目在耗尽预算前一直在浪费资源，而关键的创新则要等到下个预算周期才能申请资金。

如果企业有很多敏捷团队，募资流程也有所不同。出资人知道，大约三分之二的成功创新，初始概念会在研发中发生重大变化。他们希望团队能随时调整取舍，不必等到下个年度周期。融资过程因此演变为类似风投资本家的募资方式。风投往往将募资的抉择视为进一步开发的认购机会。目标并非立刻打造一个大规模企业，而是为最终的解决方案找到一个关键组件。表面上，这会失败很多次，但却加速了学习过程，也降低了成本。这种方法在敏捷企业运行良好，极大改善了创新速度和效率。

成功敏捷化的企业会发现自身业务中的重大机遇。敏捷规模化改变了企业运营内容的比例，相比日常运营，企业花更多精力在创新上。公司对变化的环境和战略优先级有了更清晰的认识，同时也能找到应变方案，避免了在传统官僚机构中频繁爆发的危机。即使遭遇颠覆式创新，企业也不会被颠覆得太严重，更像是正常的业务调试。

即使企业很多日常运营活动保持不变，敏捷规模化还能将敏捷价值观和原则引入这些支持部门。这将提高公司开销巨大的某些部门的效率和生产率，也能改善运营架构和组织模式，增强敏捷团队和日常业务间的协作。企业变革速度更快，对消费者需求的反应速度也更快。最后，公司能够交付可量化的改进，不只包括财务结果，还有更高的顾客忠诚度和员工敬业度。

敏捷的“测试-学习”方法往往被描述为渐进和迭代的，但渐进式开发并不等同于渐进式思考。

SpaceX的目标是利用敏捷创新，在2024年将人类送往火星，并在火星上建立能够自给自足的殖民地。如何做到呢？公司员工并不完全清楚，至少目前还不清楚。但他们相信未来有可能实现，心中也有了计划。他们计划像利用飞机那样重复利用火箭，极大提高目前技术的可靠性，降低成本。改进推进系统，发射至少运载100人的火箭，想办法在太空中完成燃料补给。其中的某些步骤需要将现有技术推向极致，然后等待新的合作伙伴及新技术的出现。

这就是现实版的敏捷法：雄心勃勃，步履不停。即使常常在黑暗中摸索，我们也总能通过敏捷找到前进的方向。

文章来源：哈佛商业评论

规模化敏捷发展三部曲：敏捷领导力、运转敏捷和整体敏捷相关推荐

敏捷开发人员结构_开发人员可以在敏捷外观方面发表意见的4种方法
敏捷开发人员结构敏捷已成为开发软件的默认方法. 有时,似乎每个组织都在做(或想做)敏捷. 但是,许多公司没有尝试改变其文化以使其变得敏捷,而是试图将诸如scrum的框架强加给开发人员,寻找提高生产率 ...
CODING 敏捷实战系列加餐课：CODING 做敏捷这一年 - 理解一站式 DevOps 产品思想
在数字化协同的大背景下,过去一年 CODING 以老牌代码托管工具为基础,华丽转型为一站式 DevOps 研发管理工具.本次课程 <CODING 做敏捷这一年:理解一站式 DevOps 产品思想 ...
敏捷 | 【万字长文】说透如何学习敏捷开发流程和运用
作为程序员如果说你不了解敏捷开发流程,不能说你不是一个好程序员,肯定的是你一定很痛苦,你将面临项目周期和版本无序的困扰. 针对这种情况,建议你看看这边文章,看完你完全能够明白敏捷. 敏捷开发是目前很 ...
敏捷教练是什么_教练还是顾问？敏捷与否？我是什么？
敏捷教练是什么我是: 专门研究敏捷技术的软件开发顾问或者也许: 我是一位专门从事软件开发的敏捷顾问. 今早, Marcin Floryan在Twitter上问了一个有趣的话题 ,他问道:" ...
2017 企业服务创新大会启动，助力中国企业敏捷发展
2017 年 4 月, 3W 传播及一站式人事管理平台拉勾云人事联合主办的「 2017 企业服务创新大会」正式启动. 大会以"我们的时代"为主题,面向全国中小企业及企业服务从 ...
敏捷领导-第一章领导力之源(1)
引子每个人都会有恐惧的事情.如果有一个人类的恐惧列表,这个列表恐怕会非常长.小虫子,蛇,死亡.以前还听说演讲是人类排名第一恐惧的事情.在现在这个社会,年轻人最恐惧阶层固化,老年人最恐惧没有钱养老. ...
赋能打造应对不确定性的敏捷团队 pdf_赋能——打造应对不确定的敏捷团队｜《赋能》斯坦利...
云书领读 | 读职场 | <赋能>[美]斯坦利·麦克里斯特尔赋能(Empowerment)是近年来最热门的管理课题. 所谓赋能就是授权给员工更多的权力来参与决策,让员工对工作有更好的掌控 ...
敏捷外包工程系列之三：固定合同（敏捷外包工程，敏捷开发，产品负责人，客户价值）...
本文是敏捷外包工程系列的第三篇.(之一,之二,之三,之四) 下面的很多外包场景以国内的外包为例,因为往往这些项目更加严苛. 外包合同常常是固定价格固定工期固定需求(一般称为定额合同),这个时候&quo ...
组织敏捷程序：第2部分，用于管理敏捷程序的网络
在组织敏捷程序:第1部分,简介中,我讨论了层次结构和网络之间的区别. 我以Scrum of Scrums为例. 它可以是任何组织层次结构. 记住,我喜欢 Scrum作为组织项目团队工作的一种方式. 我 ...

规模化敏捷发展三部曲：敏捷领导力、运转敏捷和整体敏捷

规模化敏捷发展三部曲：敏捷领导力、运转敏捷和整体敏捷相关推荐

最新文章

热门文章