从敏捷转型到精益企业
2019-12-16
来源：ThoughtWorks商业洞见 肖然
行。成功的敏捷转型团队几乎都可以看到技术实践的持续进步。2013年当我接触到敏捷流畅度模型（见下图）时，图中第一颗星所要求的团队文化转变需要引入管理框架完成，如Scrum和Kanban；通往第二颗星所要求的团队能力转变，却必须依靠技术实践的落地。所以技术实践的引入是组织敏捷转型演进过程中的重要一步，让敏捷实践更加深入。此时，我茅塞顿开。
回想2012年后，作为咨询顾问的我，已经没有听到任何团队说只引入管理实践了。即使在一些非常传统的技术领域，如嵌入式设备（甚至是芯片开发）和大型机（Mainframe），敏捷提倡的技术实践也被不停地尝试。业界敏捷转型很成功的一家大型海外金融保险机构，先期也大刀阔斧地通过重构、自动化测试等技术手段简化了自己的整个大型机生态系统，成功把部分核心系统迁移到更为开放的技术平台上，大大降低了维护成本。
更大规模的敏捷推广
敏捷实践深入后的效果在一些团队中很明显，我还记得好几个团队告诉我效率提升在50%以上。但作为顾问，我面临的组织不可能是两三个由7到9人组成的开发小组，而是少则百人、多则上千人的大型组织。这时候就面临着真正意义上的「规模」问题了。
2012年之前我还是比较「幸运」的，无论是教练还是顾问，我都回避了这个「规模」问题，因为企业认为敏捷是一种新的尝试，所以一般都是试点，意味着我带着几个小团队就可以了。最后可能交付一些组织级的方案，当然其中不会涉及到组织结构、流程再造、绩效激励等小团队可以暂时「忽略」的问题。以至于2012年我觉得敏捷没啥好讲的了，每个企业都大同小异。
2013年在互联网金融繁荣的背景下，很多金融保险机构的IT组织开始进行敏捷转型。首先遇到的挑战就是严格的部门划分和职责定义。由于业务监管及合规性的强要求，金融保险机构的IT组织一般继承了业务这方面的特点，倾向于流程上的集中强管控，稳定是首要任务。很多组织都首先拿出了互联网相关的IT系统来做试点，但不同于之前试点的是，由于组织的集中管理结构，必然要求最后站在整个组织的角度来定义敏捷的实施和推广。另一方面我们也看到更多的复杂产品团队加入到敏捷转型的阵营中来，特别是一些大型嵌入式设备的研发团队，上千人的规模是比较普遍的。
典型金融保险IT组织结构
这样的背景下，前文提到的规模化敏捷框架（如SAFe）开始流行起来。敏捷提倡的「以价值为导向的高响应力小团队结构」，在这些大型组织里如何落地，成为了第一大挑战。作为咨询顾问，尽管这些框架有很多可取之处，但在组织的流程运作和管理方法上，还是需要考虑组织的特点加以定制。即使在宣称直接应用这些框架来实施转型的组织里，最后的实施结果与原框架的差异往往也是非常巨大的。
经历了两年这样的大规模敏捷转型后，我开始认识到这样的大型IT组织存在必然的「二元性」，如核心清算系统的开发模式，不可能和移动互联网应用的开发模式保持一致。只有承认这种二元性，才能在这样的组织里实现真正意义上的敏捷！得出这样看似明显的道理和论断，花了我们很长的时间。Gartner在2014年总结出了BiModal（双模）IT，基本描述清楚了这种二元结构存在的合理性。
（注：BiModal在明确指出了复杂IT组织二元性的同时不免也过度简化了问题，比如两种模式应该如何协作、企业的创新如何开展等。笔者建议在采纳时根据组织的具体情况进行更为细致的分析。）
追求更大规模的敏捷推广仍然是现在大部分企业面临的变革性课题。随着敏捷开发模式在全球范围内的主流化，很多组织已经不希望再通过试点的方式来引入敏捷了，这个时候认识到IT复杂度带来的二元性就显得至关重要。这两年我们也看到了很多组织生搬硬套如SAFe这样的框架而形成了一套新的瀑布流程，不但没有获得敏捷提倡的高响应力，反而在动荡中牺牲了效率。
更广阔的精益组织
2015年，我作为咨询顾问加入到了一个千人的IT组织里开展敏捷转型咨询。借着前面更深入、更大规模推行敏捷的经验，我已经能够很快「按部就班」地和企业的转型推进者们一起制定出转型的节奏和目标。从试点到推广的效率也越来越高，内部改进人才的培养也有章可循。
但新的问题来了，团队开始反馈「立项太复杂了，不支持敏捷迭代」、「外包人员流动性太快了，
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
