科技即商业
TECHNOLOGY IS BUSINESS
数字化大时代下传统企业面临着种种挑战：效率永远跟不上市场业务需求，质量总是修修补补过日子，协同在部门墙面前无从谈起。很多企业结识了「敏捷」，开始尝试用敏捷组织转型来应对这些问题。2008年我在国内接到了第一个敏捷转型项目，一转眼八年过去了。尽管在这个领域里，持续交付（Continuous Delivery）、开发自运维（DevOps）、规模化敏捷框架等一系列新概念如雨后春笋般冒出来，但敏捷宣言没变，敏捷核心实践没变，敏捷咨询好像也没有太大变化。最近在研讨和推广「精益企业」的时候，「精益企业和敏捷的关系」这个问题突然让我有机会反思这八年不同组织里「敏捷」到底发生了什么样的变化：显然目标没变，都是组织敏捷转型，解决的问题也都是上述这些挑战，那么这个领域里什么变了呢？ 要回答这个问题首先要澄清对时下流行的「规模化敏捷」这个提法的理解。由于一些框架的提出，如SAFe、LeSS等，「规模化」成为了这两年敏捷转型领域里的热点（也被大家看成了敏捷转型领域的发展）。但我尝试过在一个组织里询问不同角色对规模化的期望，结果是大相径庭的。比如在一个典型千人规模的IT组织里交付团队认为「规模化敏捷」应该标志着绝大部分团队已经采用了迭代开发的模式，而业务人员却认为这样的「规模化」对他们没有意义，「规模化敏捷」的实施应该是让团队具备在开发过程中快速响应市场变化的能力。所以「规模化」的提法是模糊的，咱们需要更实例化地来看组织敏捷转型这些年的演进历程。 更深入的敏捷实践2008年请我去做敏捷教练的组织是一个传统行业的线上服务平台IT团队。这个组织拿出了一个网络平台组来实施敏捷开发。于是我们从Scrum入手，建立了两个全功能团队，把以前部门割裂的需求分析、开发、测试拉到了一起。由于组织领导者的高度关注和试点「特区」运作的模式，这两个团队很快按照迭代的模式运作了起来。 三个迭代后这两个团队都能够自发的组织各种关键会议，如迭代启动、回顾会议等，大家的交流沟通也日趋默契。如果身临其境，你会觉得这个团队很敏捷，但外部看来问题还是挺严重：迭代计划的需求基本上完不成，测试普遍滞后，用户故事（User Story）普遍达不到完成(DoD， Definition of Done）标准。 当然现在看来问题很明确，稍微有经验的读者都会说他们需要加强技术实践了。在后期，团队敏捷教练的时间主要都投入到了如持续集成、自动化测试这样的技术实践辅导里。作为程序员出身的我当时并没有从组织转型的角度思考，只是在解决现实问题罢了。如果你想提升用户故事的交付效率，显然必须考虑工程技术方面的问题。 2009年我又作为教练加入了一家大型通讯设备厂商的敏捷转型。面对复杂的组织结构和百人的开发团队，我自己有些迷茫了。经常会被一些部门领导问得不知所措，怎么把Scrum这种小团队模式在百人的团队里实施成了一个难题。回想起来，如何应对当时组织里的各种约束条件，比如绩效考核怎么搞、预算怎么做，这些企业转型后必须面对的问题，我当时并没有答案。 但有意思的是，在我参加的几个试点团队里，由于我们同步推进了不少技术实践（如重构、TDD），得到了出乎意料的认可。经典的案例是在一个项目上通过代码重构减少了三分之一的代码量而实现了同样的功能，并且代码结构变得清晰简洁。现在可能这样的案例或成果已经随处可见了，但大家可以想想在2009年，大多数企业度量程序员效率还是依靠单位时间代码行产量的环境下，这会带来什么样的冲击。 在之后的咨询生涯里，每个企业我都会要求管理和技术实践同步进行。成功的敏捷转型团队几乎都可以看到技术实践的持续进步。2013年当我接触到敏捷流畅度模型（见下图）时，图中第一颗星所要求的团队文化转变需要引入管理框架完成，如Scrum和Kanban；通往第二颗星所要求的团队能力转变，却必须依靠技术实践的落地。所以技术实践的引入是组织敏捷转型演进过程中的重要一步，让敏捷实践更加深入。此时，我茅塞顿开。 
图1. 敏捷流畅度模型（图片来源：http://www.）
回想2012年后，作为咨询顾问的我，已经没有听到任何团队说只引入管理实践了。即使在一些非常传统的技术领域，如嵌入式设备（甚至是芯片开发）和大型机（Mainframe），敏捷提倡的技术实践也被不停地尝试。业界敏捷转型很成功的一家大型海外金融保险机构，先期也大刀阔斧地通过重构、自动化测试等技术手段简化了自己的整个大型机生态系统，成功把部分核心系统迁移到更为开放的技术平台上，大大降低了维护成本。 更大规模的敏捷推广敏捷实践深入后的效果在一些团队中很明显，我还记得好几个团队告诉我效率提升在50%以上。但作为顾问，我面临的组织不可能是两三个由7到9人组成的开发小组，而是少则百人、多则上千人的大型组织。这时候就面临着真正意义上的「规模」问题了。 2012年之前我还是比较「幸运」的，无论是教练还是顾问，我都回避了这个「规模」问题，因为企业认为敏捷是一种新的尝试，所以一般都是试点，意味着我带着几个小团队就可以了。最后可能交付一些组织级的方案，当然其中不会涉及到组织结构、流程再造、绩效激励等小团队可以暂时「忽略」的问题。以至于2012年我觉得敏捷没啥好讲的了，每个企业都大同小异。 2013年在互联网金融繁荣的背景下，很多金融保险机构的IT组织开始进行敏捷转型。首先遇到的挑战就是严格的部门划分和职责定义。由于业务监管及合规性的强要求，金融保险机构的IT组织一般继承了业务这方面的特点，倾向于流程上的集中强管控，稳定是首要任务。很多组织都首先拿出了互联网相关的IT系统来做试点，但不同于之前试点的是，由于组织的集中管理结构，必然要求最后站在整个组织的角度来定义敏捷的实施和推广。另一方面我们也看到更多的复杂产品团队加入到敏捷转型的阵营中来，特别是一些大型嵌入式设备的研发团队，上千人的规模是比较普遍的。 
图2. 典型金融保险IT组织结构
这样的背景下，前文提到的规模化敏捷框架（如SAFe）开始流行起来。敏捷提倡的「以价值为导向的高响应力小团队结构」，在这些大型组织里如何落地，成为了第一大挑战。作为咨询顾问，尽管这些框架有很多可取之处，但在组织的流程运作和管理方法上，还是需要考虑组织的特点加以定制。即使在宣称直接应用这些框架来实施转型的组织里，最后的实施结果与原框架的差异往往也是非常巨大的。 经历了两年这样的大规模敏捷转型后，我开始认识到这样的大型IT组织存在必然的「二元性」，如核心清算系统的开发模式，不可能和移动互联网应用的开发模式保持一致。只有承认这种二元性，才能在这样的组织里实现真正意义上的敏捷！得出这样看似明显的道理和论断，花了我们很长的时间。Gartner在2014年总结出了BiModal（双模）IT，基本描述清楚了这种二元结构存在的合理性。 
图3. Gartner BiModal(双模) IT
(图片来源：https://juanjesusros.files./2015/02/tabla-bimodal-it-gartner.jpg)
（注：BiModal在明确指出了复杂IT组织二元性的同时不免也过度简化了问题，比如两种模式应该如何协作、企业的创新如何开展等。笔者建议在采纳时根据组织的具体情况进行更为细致的分析。） 追求更大规模的敏捷推广仍然是现在大部分企业面临的变革性课题。随着敏捷开发模式在全球范围内的主流化，很多组织已经不希望再通过试点的方式来引入敏捷了，这个时候认识到IT复杂度带来的二元性就显得至关重要。这两年我们也看到了很多组织生搬硬套如SAFe这样的框架而形成了一套新的瀑布流程，不但没有获得敏捷提倡的高响应力，反而在动荡中牺牲了效率。 更广阔的精益组织2015年，我作为咨询顾问加入到了一个千人的IT组织里开展敏捷转型咨询。借着前面更深入、更大规模推行敏捷的经验，我已经能够很快「按部就班」地和企业的转型推进者们一起制定出转型的节奏和目标。从试点到推广的效率也越来越高，内部改进人才的培养也有章可循。 但新的问题来了，团队开始反馈「立项太复杂了，不支持敏捷迭代」、「外包人员流动性太快了，无法深入敏捷实践」、「采购要求范围确定，敏捷模式下没法通过审计」、「敏捷技术能力要求太高，招不到合适人员」，这样林林总总的问题纷至沓来。 2015年初，我又幸运地接触到了前文提到的《精益企业》一书，发现原来这些挑战在各种组织中都普遍存在。跟几位作者交流后，发现大家的认知是一致的：敏捷转型绝不仅仅是研发团队的变革，而是涉及到一个企业的方方面面，是一项包括行政、财务、人力资源等部门的综合工程。由于过去十年大家对敏捷先入为主的观念（即敏捷是一种软件开发方法），《精益企业》作者们为了明确敏捷作为一种思想，对于一个企业来说绝不仅局限于IT，所以特别用了「精益」来加以区分。 在精益企业的架构（见下图）中，我们可以明确地看到，探索新商业模式和拓展已验证商业模式这两种不同业务形态的显式区分。通过企业运营、IT架构、目标制定和组织结构的精益化来打造一个高适应力、持续创新的高绩效组织。这毫无疑问将是企业敏捷转型的下一个必由之路：一种全新的生机勃勃的产品开发模式，在产品的探索期、拓展期和成熟期采用不同的工作方式，并顺利实现从一个阶段到另一个阶段的跨越。依托设计思维、实验性交付、精益看板、持续交付和持续改善等方法最大化产品所创造的用户和业务成效。 
图4. 精益企业架构
（该模型根据《精益企业》书中对高适应力、持续创新组织的描述建立）
前文中提到的海外大型金融保险企业，在敏捷转型取得巨大成功后也开始对组织结构进行深层次的调整，先后围绕用户体验和创新技术成立单独运作单元，目的是能够更好地支撑探索型的创新商业模式。可以说没有这样的调整就不会有这个组织在移动、云及大数据等新兴技术领域的快速应用。整个企业也因此能够在用户体验和技术能力上持续创新。 总结回顾组织敏捷转型这8年，从简单的小团队引入敏捷管理框架开始导入，敏捷转型经历了对技术实践的更深入尝试、对团队规模的更大范围采用、以及对整个组织的更广阔精益变革。随着IT行业的颠覆式发展，敏捷转型涉及的范围也在不断扩大，今日我们谈论「精益企业」时，已经把敏捷的思想运用到了企业运营的方方面面，对价值的追求也不再局限于高效的软件交付，而是持续创造市场价值。 展望未来，「科技即商业」正在逐步成为现实。全球著名的在线影业公司Netflix公开宣称自己是一家技术公司，经营电影视频只不过是他们利用自身技术创造社会价值的一种方式。传统企业，如通用电气（GE）布局数字化多年，形成了自己的数字化工业架构，具有自己的智能机器数字线、数字分析应用产品、以及工业互联网云平台等，转身成为世界上最大的“软件公司”之一。中国的新兴互联网企业如滴滴、乐视也在纷纷效仿，在创新技术上进行了大规模投入。在这样的时代背景下，如何打造精益企业、拥抱技术变革必然成为企业市场成败的关键。标普S&P500中的企业平均寿命已经从上世纪六十年代的60多年逐年下降到现在的不足20年，创新技术正在以越来越快的速度颠覆着企业的市场环境，如果谁对技术即业务的未来还存在一丝一毫的犹豫，那么被挑战的不仅仅是企业的发展，而是企业的生存。所以当下的企业转型绝不再是简单的敏捷开发方法的导入，而是围绕企业经营环境的精益生态圈的建立！
作者介绍 
肖然，ThoughtWorks中国区咨询总监
国内最早一批精益、敏捷咨询顾问，参与了电信、金融、保险、物流、企业IT等领域多个大型组织的精益敏捷转型。肖然目前专注于将精益思想引入到企业管理及组织创新过程中，和组织一起梳理、制定目标，并规划迭代的实施方案，致力于打造适合互联网时代的精益企业，在大型组织里植入创新的基因。
- 精彩商业洞见回顾 -
《商业洞见正式创刊》 《实体零售突围》 《场景化金融时代的平台建设》
- 小编推荐 - 文中多次提到的《精益企业》一书被Upwork公司CEO史蒂芬·卡斯瑞尔列举为「20本最有影响力的书目」之一，并被「哈佛商业评论」推荐。点击了解本书
|
