如何让大象般的组织既保持奔跑的速度，又保持平台的稳定？敏捷数字化转型显然是崭新的管理思考纬度和有效的行动指南。但是，敏捷绝不只是追求快，其根本要义在于通过小步快跑的方式，达到提高产品和服务品质的终极目的。换句话说，敏捷不是目的，而是手段。但这套打法恰恰是大型传统成熟企业所不熟悉的。如何让大象起舞？惟有敏捷。然而，除了“生而敏捷”的初创公司和凤毛麟角的领先科技公司，绝大多数传统企业尚未起步 。
虽然技术是数字化中必不可少的一部分，但它并不是全部。数字化也需要转换商业模式、流程、文化和思维。非技术的部分可以用一个词来总结：敏捷。要适应客户不断变化的需求，就要保持敏捷。
数字化转型和敏捷转型有很强的关联。举例来说，亚马逊是数字化企业的领头羊，它本来只是一个电子商务网站，但现已成为市值两倍于沃尔玛的巨头。亚马逊没有把利润回报给股东，而是不断投资于创新，创造更好的客户服务。它是为客户而存在的。同时，亚马逊也是敏捷方面的领头羊。杰夫·贝佐斯提出的控制团队人数，以及他著名的“两个披萨”高效团队原则，都是在谈敏捷。
企业的成功既需要数字化也需要敏捷。数字化提供更好的用户体验，敏捷激发热情与创新。数字化和敏捷是天生一对。坦白来说，根本不能只选其中一个。
那么，到底是什么需要更数字化、更敏捷？
如果数字化和敏捷的都是形容词，它们形容的名词是什么？这个问题很重要，因为它定义了数字化转型的大框架。在这个框架下，需要找到数字化最少、最不敏捷的地方，让它们更加数字化，更敏捷。名词是你希望数字化、敏捷化的个体或组织。这个组织可以是企业也可以是政府。
那么，是什么构成了组织？组织运作的部分都是什么？它们是渠道、职能部门、外部合作伙伴、雇员、技术和领导力（见图3）。
渠道——渠道是组织与客户互动的渠道。渠道可以完全是数字化的，也可以物理与数字并存。好的渠道应该做到有用、有意义、知识丰富、无缝、统一、迅速。作为一个客户，我想与企业中那些了解组织也了解我，同时可以提供优质、迅速服务的人互动；我不想跟不同的人，还有讨厌的聊天机器人不断花时间去解释我的需求；我希望立即得到我想要的服务；我费的力气越少，我的感受就越好；不要让我费劲去想、花时间去等。
职能部门——组织中的各个职能部门齐心协力满足顾客的需要。有些可能在一线接待客户，有些可能在后台做不同的工作，有些可能负责管理与合规等等。不管怎样，他们的工作可以更加数字化、更加敏捷。他们的流程如何？采用什么步骤？可不可以省略或者自动化？有没有其他更简洁的方法达到同样效果？职能部门之间的合作能不能改进？职能部门能不能合并或重组，以精简流向客户的价值流？能不能给职能部门更大的权力去更好地服务客户？
合作伙伴——在全球化的今天，没有企业能独立生存。企业需要与伙伴或供应商合作。企业拥有的是哪种关系？是一方需要不断与另一方协商、再协商才能达成合作的关系，还是互利共赢的关系？合作伙伴能否很容易地纳入其中？信息可以顺畅地跨组织分享，还是有很多交流摩擦？沟通不畅、合作不佳，相关的职能部门就需要花时间等待，最终损害的是客户体验。
员工——有满意的员工才有满意的顾客。工作环境如何？工作环境是促进学习和分享，还是加剧孤立？员工需要每时每刻坐在桌前，还是可以在任何地方工作？举例来说，工作现在越来越移动化，员工可能不在桌前，而是用电子设备完成工作。出差和请假申请可以用电子软件批准。不过还不止于此。考虑一下能不能倾听员工的声音，提高员工参与度吧！考虑提供一个能为不同工作需要，提供不同合作空间的数字化职场吧！
技术——这点可能让人惊讶，不过技术管理及操作自身就需要数字化和敏捷。很多时候，信息技术被认为是要花钱的，我们会抱怨为什么一个系统要投入那么多人力，一个改动要花那么长时间。但是，如果我们相信科技是业务成长之源，那就在源头多投资吧：投资工具，也投资相应的人才，使用最新的技术。让你的IT系统成为“持续成长”的系统，而不是“老旧”的、衰退不能用的系统。顺便一提，英语里“老旧”一词是个多义词，它只有在形容IT系统时才作贬义词用。如果你的系统确实很“老旧”，那么，制定更新换代的计划——考虑一下DevOps（开发与运营一体化）模型，或者云端，或者微服务，或者敏捷与持续交付吧。
领导力——或许领导力改变的时候才能发生最深层次的改变。我并不仅仅指领导者，而是说人们领导组织的总体方式。它包括战略、计划、决策、预算、治理和绩效管理。领导者获得了准确的信息吗？雇员愿意提供信息吗？各层领导都愿意倾听吗？不论个人还是组织本身，都在持续学习吗？牢记沃伦·巴菲特的告诫，时刻警惕：傲慢、官僚主义和自满。
你有多数字化，多敏捷？
如上所述，数字化和敏捷是形容词。它们没有静态的定义，而是相对的概念。没有人能说一家公司满足了一组固定的条件，就是一家数字化公司。因此，不要问“我们是不是数字化”，而要问“跟竞争对手或以前相比，我们的企业数字化程度更高了吗？”。另外，数字化包含很多层面，你的企业可能在一个领域非常数字化，但另一个领域却做得不够。这种情况也不能长久。比如说，渠道十分数字化，但员工和技术的数字化成都非常低，就不明智。对于敏捷，道理也是相似的。敏捷也是一个相对的、包含多个层面的形容词。
在这里，我提出了一些衡量数字化和敏捷程度的评估方法，因为这是与时间、与对手赛跑，所以是相对评估。你可以有一些绝对的评估方法，不过即便如此，它们也是在相对场景下才合理。图4展示了这套评估方法。
敏捷是如何帮助企业小步快跑、试错迭代？
建议从四个方面入手做了探索。
首先是组织逻辑。传统的组织是按照职能来划分部门的，敏捷的做法是从各个相关部门抽调人员，成立跨职能团队。团队成员秉承“端到端”原则，每个人从头到尾对项目负全责，所有人的KPI都是一致的。
其次是工作机制。我们把敏捷小组的人放在一个办公室，面对面工作，集中办公大大降低了沟通成本。同时辅之以敏捷管理的原则快速反应和迭代，如定期培训和检视、两周为一个冲刺，时间短和注重决策的轻量会议等，全面提升反应速度。
再次是授权体系。关键是减少交接和精简流程，把权力下放。用RACI（Responsible-Accountable-Consulted-Informed）分析法可以分清楚谁是负责人，谁是决策者，谁是被咨询的人，谁才是执行的人。比如说，我们通过RACI诊断出开发信用卡新产品的流程里有七八个决策的人，而且决策者和负责人之间存在反复的审批。一旦把冗余层级、重复决策耗时过多的环节砍掉，就可以节省很多时间。
最后是流程优化。传统流程是基于部门设定的，一个人同时支持多项业务，“一心多用”往往效率不高。这也是风险、合规、运营等职能部门经常成为瓶颈的主要原因。敏捷转型带来的转变是基于联合办公的流程优化，即保证员工单线程工作，变串联为并联。
敏捷技术开发是如何做的？
谈到敏捷开发的时候，张小龙直言：“我们今天可以想一些与众不同的点子，然后我们可以很快就看到效果，因为我们可以很快把它上线了，然后可以去验证，如果不对就下线，如果还有改进余地，下个星期再去改它。这是一个能够持续实现你的想法的过程。”
其实这种敏捷开发的方法由来已久，并且被 Google、Facebook等硅谷企业广泛应用。
它已经形成了一套完整的方法论，总结起来就是“MVP”和“精益分析”两个概念。
敏捷的背后：MVP 与精益分析
（一）MVP
MVP 是最简化可实行产品（Minimum Viable
Product）的简称。最简化可实行产品是以尽可能低的成本展现产品的核心概念，用最快、最简的方式建立一个可用的产品原型，用这个原型表达出你产品最终想要的效果，然后通过迭代来完善细节。
什么是最小可行产品 MVP?
最小可行产品（Minimum Viable Product，简称MVP）是一种避免开发出客户并不真正需要的产品的开发策略。该策略的基本想法是，快速地构建出符合产品预期功能的最小功能集合，这个最小集合所包含的功能足以满足产品部署的要求并能够检验有关客户与产品交互的关键假设[1]。该概念由Eric Ries在其著作《精益创业实战》中提出，用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出你产品最终想要的效果，然后通过迭代来完善细节。
假如你的产品愿景是一种高级出行工具，比如小轿车。传统的产品设计思路是一步一步，从车轮、车轱辘、外壳、动力装置、内部装饰一个流程一个流程做起，最后得到一个完善的产品。而 MVP 的思路，我们可能会先做一个小滑板车或者自行车，看看用户对出行工具的认可程度。如果用户认可我们的产品概念，我们可以接下去生产更加高级、完善的摩托车、甚至小轿车。
MVP是最符合敏捷思想的产品迭代开发方法。MVP首先着眼于基本的客户需求，快速构建一个可满足客户需要的初步产品原型。部署之后，通过客户反馈，逐步修正产品设计和实现，最终达到完全满足客户需要。而最关键的是，在各个迭代过程中，做出来的产品始终是可为客户所用的产品，而不是只有一部分功能却不能让客户使用。
（二）精益分析
埃里克·莱斯，硅谷著名的企业家和作家，最先提出来“精益创业”的概念。精益创业的理念涵括精益客户开发、精益软件开发和精益生产实践三大部分，这是一个快速和高效开发产品和服务的框架。
精益创业的本质是精益分析，核心是“构建-衡量-学习”循环。张小龙的敏捷开发想法和这个方法论不谋而合：首先是你有一个想法或者灵感，然后通过 MVP 策略产品快速上线；产品上线后，通过数据来衡量用户的表现，如果好的话就保持、继续优化，不好的下线反思。通过这种循环，产品快速迭代、用户的需求得到更好的满足。
引用参考：
http://36kr.com/p/217020.html
验证最小化可行产品(MVP)的15种方法
http://36kr.com/p/5055438.html
微信教父张小龙所说的敏捷开发是什么？