来源：CIO Talk
作者：常红平
关注本公众号回复“研发效能”可获取常红平老师《互联网研发效能方法工具落地金融行业的实践经验》回放地址~
如果现存的组织架构与转型目标不符，组织架构的调整是所有转型工作的第一步。即使只是转型试点，组织架构转型暂时不在全组织铺开，新的组织架构也要在试点团队先构建好。根据康威定律，组织产生的系统设计受制于这个组织的沟通结构。意思就是说你想要什么样的系统架构，就组建什么架构的团队。如果你希望团队能够基于现代化的技术栈和架构来提高市场竞争力，那么你的组织架构就要和新的技术架构相匹配。如果你希望团队采用敏捷开发流程来加快交付速度，那么你就应该拥有全功能、自组织的团队架构来支持敏捷开发流程。
组织架构的变化必然会导致研发流程、沟通方式的巨大转变。这时正好整体梳理一下研发流程，让整个团队按照新的敏捷研发流程运作。广义的敏捷转型中也包含组织架构、文化等方面的转型。但为描述清晰起见，我们这里特指狭义的敏捷转型，即更多关注在研发流程、敏捷实践、沟通方式等方面的变革。除去组织架构转型中可能会遇到的政治风险，敏捷转型应该是组织转型的五个维度中会遇到问题最多的一个维度。而且如果有问题长时间不能被解决，前文提到的观望派很可能会转变为反对派。因此大多数失败的组织转型都是败在了这个维度。转型领导者必须要重视。敏捷转型在业界有很多方法论、框架等等。在实施过程中也一般会引入敏捷教练，并根据团队的特定情况量身定制转型方案。跳出各种敏捷框架之争，我建议敏捷转型按照下面三个阶段进行：这个阶段的目标是让团队能把原先几个月发布一次的瀑布式开发流程改为迭代式。如果团队能够稳定地在每个迭代中至少实现一次发布，基本可以认为这个阶段的目标就达成了。这个阶段在业界有大量成熟的、可以直接采用或参考的流程、实践等等。比较共通的有用户故事、各级待办列表（backlog）、Scrum系列实践和角色等等。实施难度相对不大。但这个阶段经常会遇到的问题是用新瓶装旧酒。很多团队为了应付上级转型目标，即使把所有流程实践都换成了敏捷术语，但骨子里其实仍然是瀑布。团队也因此并没有感受到敏捷所带来的益处，反而是各种转型中的阵痛。如果敏捷转型中出现了这个问题，一旦上级放松要求，团队就很容易自己退回到原先的瀑布模式。所以其实敏捷转型的失败大多是在这一个阶段。这就要求领导者自身具备丰富的敏捷知识、脚踏实地而不是好大喜功、深入到团队之中进行变革，帮助团队切实解决转型过程中的具体问题，而不是一味强推。本阶段转型成功后，虽然团队已经可以感受到一些转型所带来的益处、但因为执行效率尚且不高，受益效果仍然有限。此时需要尽快深入到下一个阶段，否则团队很有可能因为受益暂且有限，而失去继续深入转型的动力甚至开倒车。在这个阶段，团队基本上都是照猫画虎地执行现成的、或者敏捷教练所教授的流程和实践，属于执行敏捷“doing agile”。在敏捷管理中，我们经常会借鉴日本剑道中“守、破、离”的说法。此阶段也是典型的“守”的阶段，即一招一式都是在学习模仿，还没有能力进行突破、创新。这个阶段如果成功了，虽然表面上的成果是团队具备了迭代能力，但更深层次的成果应该是团队思维的转变——团队开始接受敏捷这个新鲜事物，从执行敏捷“doing agile” 向拥抱敏捷“embracing agile”转变。这个阶段的目标是在第一阶段的基础上大幅提升效率。在此阶段纯粹的敏捷流程已经不足以完成转型的需要了，更多的是要加强技术实践，比如自动化测试、持续集成、持续发布等等。因此团队的技术实力和工程能力必须同步加强。提升效率最有效的方法是全面自动化。因此自动化的程度也是衡量此阶段是否成功完成的标志。并且随着迭代效率的提升，一般来讲，团队也会具备从每迭代发布一次到发布多次，甚至是每日发布多次的能力。在这个阶段的推进过程中，团队能够更加切实地感受到敏捷带来的巨大益处，因此会形成深入敏捷-〉更多受益-〉更加深入的正反馈。这个阶段遇到的问题更多工程能力上的硬坎儿。比如为了提升测试自动化程度，对于遗留系统怎么办？数据相关项目怎么做DevOps？开始有很多问题没有标准答案，甚至根本没有很好的答案。这时就需要团队自己去摸索、寻找答案。同时随着敏捷的不断深入，因为各个团队所面临的具体情况不同，教科书上的敏捷流程实践开始不能完全满足团队的特定需要了，于是团队也开始思考并尝试一些新的方法，这也是“守、破、离”中“破”的阶段。随着团队全面接受并拥抱敏捷，敏捷已经慢慢成为团队的习惯和基因。团队由此开始从拥抱敏捷“embracing agile”跨入到第三阶段我即敏捷“Being Agile”。进入到这个阶段，团队已经切实感受到了敏捷转型的巨大益处，敏捷转型在某种意义上其实已经成功了。团队不会接受、也不太可能再倒退到瀑布模式了。但敏捷的原则之一就是持续提升，因此本阶段仍然有很多实质性的提升工作可以做，比如完全的、高效的自组织；使用价值驱动的、全方位的度量来指导全面地、持续地提升等等。此阶段的实践已经脱离具体的流程、技术，敏捷也不止局限于软件研发，而是全方位的、文化层面的深入转型。此阶段也没有结束点，而是提升永无止境。在这个阶段团队可能会遇到问题是，在团队人员流动比较快的时候，如何保持团队整体的敏捷成熟度。团队需要有很好的新人成长、融入机制。但这对于敏捷成熟度已到达较高层次的团队应该不是大问题，团队自组织持续提升的文化会自动修复这个问题。在这个阶段，团队已经不需要时刻思考“我这样做符合敏捷原则吗？”敏捷已经深入团队的基因。敏捷这个词甚至已经被很少提及了，但是团队做事情时会很自然地遵从敏捷的原则。这就是敏捷的最高境界“Being Agile”我即敏捷，也是“守、破、离”中“离”的阶段。
在敏捷转型的过程中已经涉及到了文化转型。但文化转型有必要单拿出来特别展开。因为文化转型才是所有转型的根本，也是所有转型的保障。文化转型在整个组织转型中必须是贯穿始终的。是否完成了文化转型是整个组织转型成功与否的标志。在文化转型过程中，领导力的作用至关重要。作为组织领导者，必须具备文化再造的魄力、顶层设计的能力、强大的沟通和执行力、和以身作则的精神。领导力是个很大的话题，这里简单谈几个文化转型中的关键实践。文化本身是无形的。但文化是一个组织所共享的、特有的信念、仪式、价值观、行为、制度、沟通方式的集合。这里面很多东西又是有形的。而通过改造这些有形的部分，如行为、制度、沟通方式等，可以反过来影响到无形的文化本身。让文化有形化的一个重要方法是编写文化手册。文化宣传不能仅仅靠标语。文化的内涵非常丰富，但边界可能非常模糊。同样一个行为，不同的人也许会有不同的理解。用文化手册将那些容易引起歧义的、模棱两可的行为逐一澄清，可以有效的保证整个团队对文化的理解是一致的。团队清楚了符合组织文化的行为是什么，组织也需要理顺内部流程让团队能很容易地实践这些行为。通过理顺流程或流程再造，消除践行组织文化的阻力，让践行组织文化成为最自然的选择。组织还要通过制度建设，尤其是度量、考核、激励机制的建设，来保护和激励文化的践行者，而不是只靠道德和价值观的灌输。例如在阿里的绩效考核中文化价值观部分甚至占到了50%。通过把文化手册、流程改造、和制度建设，让团队践行文化有据可依，执行无阻力、行为可度量，慢慢团队对文化就会形成肌肉记忆和习惯，组织文化就逐步形成了。敏捷本质上也是一种文化。你会发现敏捷转型所用的方法（先规范做事方法、然后提升熟练度、最后忘掉这些方法）其实和本节所述的文化转型方法的本质上是一样的。敏捷转型也可以被认为是文化转型中的一个特例。
所有的工作，包括转型本身毕竟都是团队完成的，所以为团队赋能，就是为转型赋能。构建团队文化本质上也是对团队的培养，为团队赋能。为团队赋能最容易想到的方法是培训。但实际上培训是经常达不到预期目标的，或者不是所有培训参加者都能达到预期的目标的。究其根源，主要是因为下面两点：- 培训对学员来讲是无差别的。在参加培训之前，学员的水平就参差不齐，有些人甚至没有达到参加培训的最低标准，甚至不想参加培训。培训过程中讲师也不可能面面俱到，照顾到所有学员，导致学员接受效果不同。
- 培训之后没能将培训内容立刻学以致用。事实上很多企业培训都是前置性的，学员能立刻应用上培训内容的机会很少。如果学员不能将培训的内容加以实践，很快就会把学到的知识遗忘。
虽然必要的培训还是应该做，在我看来，对于一个组织而言，更加有效地提升团队能力的方法有下面几种：团队教练：团队教练本质上是提供定制化的培训，也就是解决普通培训遇到的第一个问题。好的团队教练必须具备丰富的理论知识和实战经验，能根据团队的特点因材施教、因地制宜，切中要害，必要的时候能亲自上阵言传身教。团队教练必须深入团队，才能深刻了解团队痛点，切实解决团队问题。团队教练最忌讳照本宣科，光说不练，头疼医头、脚疼医脚。团队教练的考核标准不是举办了多少场培训，而是团队的360度反馈，团队自身的成熟度提升等等。把工作中的一切都看作是能力建设：这个解决普通培训遇到的第二个问题。大部分人都知道学以致用，刻意练习是个人能力快速提升的有效方法。对于一个组织而言，应该思考的是如何帮助每个团队成员达成这一点。ThoughtWorks有一个口号叫做“把项目成功交付看作能力建设的副产品“。这一点我非常认同。对于一个公司或组织而言，股东利益一定是排在员工前面的，所以员工的工作产出必然比员工的个人能力提升更重要，这一点毋庸置疑。但员工的个人能力提升是典型的重要但不紧急的工作，我们不希望因为对这件重要但不紧急的工作的忽视，导致把其它同样重要但不紧急的工作（如项目交付）拖延成紧急的。如果员工能力提升了，员工的产出自然会提升，进而会减少出现因为某些工作太紧要而只能依赖某些员工，而其他人得不到锻炼机会的情况。这就是应该把工作中的一切都当作是对员工能力的培养的本质。导师制度：就是让老员工带新员工，资深员工带资历浅的员工。这个制度本身并不是什么新鲜事物，很多团队都在做，但贯彻得好的并不多。做好的关键有下面两点：- 一是对导师本人的考核和激励。做导师就像当教师一样是崇高而需要辛勤付出的工作。如果对这些付出无视或者无法考核并予以激励的话，导师的激情会很快消退。
- 二是对学员的习惯培养。再好的老师遇上不爱学习的学生也是无能为力的。导师制度的主导权应该在学员手里，这一点必须非常明确。学员必须知道自己主动地虚心求教才是高效利用导师制度快速提升自己的关键。
重塑招聘、员工晋升、绩效管理体系：团队级别的能力提升必须从招聘就开始做起。在转型初期就需要招聘具备目标技能的人才。这些人才会在团队中形成鲶鱼效应，激活整个团队的氛围。新人招得快和招得精是无法兼得的，必须根据实际情况有所取舍。针对初创公司，快也许更重要。针对成熟的大企业，精更重要。招聘标准、员工晋升标准、绩效管理体系要依据转型所需要的人才作出统一调整。这个体系会激发员工自我提升的动力。这些标准也是促进文化形成的重要因素。打造组织中持续学习、成长的文化：兜兜转转总是离不开文化的话题。上面每一个实践、每一条制度，也都是文化的具体体现。这里再次提及的目的是提醒组织最好把持续学习、成长作为文化中的一条价值观着重强调。用这条价值观来指导包括但不限于上述实践、制度的制定和执行。以上是对于组织而言团队能力如何提升。对于个人成长，除了有目的地刻意练习外，最好的方法是搭组织的便车——跟随一个快速成长的组织以实现个人的快速成长。如果个人的成长速度和渴求已经远超所在组织的成长速度，就是时候换个地方了。反之，如果个人跟不上组织的成长速度，那么非常危险，他/她很可能也要被换个地方了。
科学技术是第一生产力。技术转型的目的是提升生产力。它所带来的生产力提升也是整个组织转型的重要目标。
在敏捷转型第二阶段中提到过，工程能力、技术能力在转型中期是极为重要的。技术转型可以极大的提升工作效率和组织竞争力，是加速组织转型进程、夯实转型结果的重要手段。
同时，如同项目交付是能力建设的副产品一样，技术转型也应该是能力建设的自然结果。技术转型被放在组织转型五个维度中的最后一个谈，是因为技术转型不能在其它维度的转型到达一定水平前就贸然开始。它需要与现有组织架构、团队成熟度等组织内部环境相匹配。
技术转型与其它维度的转型的关系犹如生产力与生产关系原理。
生产力决定生产关系，生产关系反作用生产力。在生产关系与生产力相匹配的时候，生产关系可以极大的促进生产力提升。而二者不匹配的时候，生产关系会阻碍生产力。当二者严重不匹配时，甚至会引发激烈的变革。
作为管理者，我们当然不希望被迫发生激烈的变革，所以必须及时地、动态地调整技术提升所需的各种内部环境，为技术升级换代创造环境。
技术转型必须是价值驱动的。不能只是为了用新技术而用新技术，必须使用由价值驱动的度量指标来持续衡量新技术、新架构的产生的业务价值。
举个例子，微服务、中台技术这些年在业界非常火，但失败的案例也非常多。事实上很多失败的原因是没有充分考虑业务价值，没有使用敏捷、精益的思想推进项目进程。这也是组织的敏捷能力没有到达一定水平后贸然开始技术转型而造成的。
技术转型不可以脱产。技术转型的成果必须在生产系统及时被验证。团队通过及时收集反馈，迭代式地调整技术转型的战略战术。这也是敏捷、精益思想的体现。
《DevOps实践指南》一书中提到过团队应至少预留20%的时间用于非功能性需求、技术债务等用户不可见的价值。业界因为没有这么做而产生的教训非常多，包括一些顶级的跨国公司，包括亚马逊、谷歌等。
但事实上很多组织并没有因此引以为戒，反而在不断重复这些犯过的错误。这也是很多组织到后来被迫开始激进的、运动式的技术转型的原因。但最好的技术转型应该是时刻持续进行的。
假如你的团队确实因为技术债务积累太多而不得不进行激进的技术转型，在转型期间，可以将上面20%原则适当调整，改为分配30%，40%甚至更多到技术革新，但不建议超过50%。再次强调技术革新必须是为业务服务的，并且被业务持续验证的。
以上简述了组织转型中的五个维度，以及在这个五个维度上转型的原则和实践。经常听有人说这个行业是个传统行业，那个行业是新兴行业等等。在我看来，没有所谓的传统行业，只有传统公司。一个公司如果因循守旧、不知主动进取、变革和迭代，即使处在新兴行业也是一个传统公司，从而无法在激烈的市场竞争中胜出甚至生存。而一个积极创新、主动转型、快速迭代的公司则可以在各行业中脱颖而出，甚至在同行业或跨行业进行降维打击。在VUCA时代，希望更多的领导者能够持续提升自身和组织的能力和适应性，在危机到来之前就主动寻求变革，提升企业和组织竞争力。IT职场老兵，在做过除用户体验设计师外的所有软件研发团队中的角色后，于10年前开始专注于管理。爱技术、爱敏捷、爱读书、爱分享。现在IBM CIO中国实验室作为IBM全球软件和云服务销售系统负责人，领导IBM年交易量数百亿美金的核心系统的研发和运维工作。近年来，他还带领跨国团队成功实施了一系列敏捷转型、技术革新、和组织文化转型。拓展阅读：通过组织转型打造高效研发团队的三个步骤 | IDCF
高效研发组织的七个习惯 | IDCF
从一线经理到全球副总裁 — 小中大型团队的组织架构设计原则 | IDCF
FDCC - Fundamental DevOps Capability Certification【基础认证-⽩腰带】，限时免认证费，回复“FDCC”即可申请。
