组织转型怎么做：原则与陷阱

理解为什么要确保员工拥有完成工作所需的工具和资源，并充分发挥他们的技能与能力。

每个组织都在持续变化。因此，在推动组织转型、技术转型或组织变革管理时，我们需要不断追问几个问题：

这种变化正在朝哪个方向发生？

我们正在努力实现哪些系统层面的目标？

组织是否越来越善于发现客户需求、服务客户，并借此实现自身目标？

组织的商业模式和人才管理方式，是否能够支撑长期可持续发展？

当事情看起来偏离计划时，领导者通常会推出各种转型方案。然而，这些方案往往无法实现预期目标，反而消耗大量资源和组织能力。本文将探讨如何更有效地实施组织转型，并分析一些常见的失败原因。

组织转型如何实施

有效且可持续的变革，通常包含两个关键要素：第一，是一套通过设定目标、支持团队实验来推动组织变革的流程；第二，是一套将优秀实践扩散到整个组织的机制。

用 OKR 和改善 Kata 设定转型目标

用于执行和衡量组织变革的框架有很多，例如平衡计分卡、目标与关键成果（OKR）、改善 Kata 和辅导 Kata。它们看似不同，但都具备一些共同特征。

这些框架通常都从组织或部门层面的方向开始，也就是所谓的“北极星”。这是由领导层设定的、具有愿景性的系统级业务目标。它可以是一个几乎无法完全实现的理想目标，例如“零工伤事故”；也可以是一个需要一到三年才能实现的挑战性目标，例如“将生产力提升十倍”。

下一步，是理解现状。DORA 快速评估可以帮助团队了解自身在软件开发能力和成果方面的进展。另一种分析方式，是开展价值流图绘制或活动核算等练习。关键在于，组织必须以可衡量的方式理解自己当前所处的位置。

第三步，是为未来设定可衡量的目标。这些目标可以用类似 OKR 的格式描述：先设定一个定性目标，再明确一组可衡量的关键结果，也就是目标条件。例如，某国际银行技术负责人曾为每个团队设定过这样一组目标：“每年翻倍、减半、减四分之一：发布频率翻倍；低影响事件数量减半；高影响事件数量降至四分之一。”

最后，在管理层支持下，团队会尝试不同方法来实现这些目标，直到预设周期结束。团队应采用科学方式开展实验，使用 PDCA 循环，也就是计划、执行、检查、改进。这个循环包括以下步骤：

计划： 明确预期结果。

执行： 开展实验。

检查： 研究实验结果。

改进： 决定下一步行动。

团队应该每天开展实验，努力朝目标条件或关键结果迈进。在改善练习中，团队中的每位成员每天都应问自己五个问题：

1. 目标条件是什么？
2. 当前情况如何？
3. 你认为哪些障碍正在阻碍你达到目标状态？你现在正在解决哪个障碍？
4. 下一步计划是什么？你预期会得到什么结果？
5. 什么时候可以评估结果，看看从这一步行动中学到了什么？

当结果被记录下来，并设定新的目标后，这一过程就会重复进行。

由于这个过程是在不确定条件下开展的，结果如何实现并不总是显而易见。因此，进展往往不是线性的，而是会经历波动、反复和阶段性突破。

在计划会议中，参与者会回顾上一轮计划会议设定的目标条件或关键结果，并为下一次迭代设定新的目标。在评审会议中，参与者会检查各团队在实现迭代目标方面的进展，并讨论遇到的障碍以及相应的应对措施。

关于这种组织转型模式，有几个要点需要特别注意。

第一，团队的目标条件或 OKR 必须由团队自己参与设定。如果目标条件完全自上而下设定，团队就很难与结果形成真实的利益关联，也不会真正投入目标实现。相反，他们可能会“操纵指标”，也就是人为改变结果，以便看起来达到了目标。

第二，未能达成目标是可以接受的。有些目标本来就是挑战性目标，设定它们的目的就是提高难度。团队应该预期大约完成 80% 的目标。在文化转型初期，团队未能达成任何既定目标也很常见。如果出现这种情况，团队应该在下一轮迭代中只设定一个目标，并全力以赴去实现它。

第三，随着团队目标和当前状况不断变化，以及团队在实现目标过程中持续学习，许多目标和衡量标准也会随之改变。因此，不要花太多时间试图设定“完美目标”。更重要的是专注于执行流程，让团队尽快开始学习。

第四，团队必须拥有必要的自主权、能力、资源，以及管理层和领导者的支持，才能真正开展改进工作。团队不应让日常交付工作挤占改进工作的时间，因为改进工作正是解决效率低下问题、提升产品和服务交付速度的关键。

对于研发团队而言，这类改进不应只停留在目标表格或复盘会议里，而应进入真实的研发流程。例如，借助 PingCode 这类研发管理工具，团队可以把目标、需求、评审、开发、测试、发布和 Wiki 知识沉淀串联起来，并与代码仓库、CI/CD 等工具打通，使技术转型中的实验、指标和改进行动更容易被持续跟踪和复盘。

用实践社群传播组织变革经验

当团队找到更好的工作方式后，下一步就是将经验教训推广到整个组织。推广方式有很多。某年度 DevOps 调研曾要求受访者分享团队和组织如何推广 DevOps 与敏捷方法，并让他们从以下一种或多种方式中选择：

• 训练道场
• 卓越中心（CoE）
• 概念验证（PoC）但停滞不前
• 概念验证模板
• 将概念验证作为种子
• 实践社群
• 大爆炸式推广
• 自下而上或草根式推动
• 混合策略

分析结果表明，高绩效团队更倾向于在组织内部不同层级构建社群结构。这可能使他们的变革更具可持续性，也更能应对组织重组和产品变化。最常见的两种策略是实践社群和草根社群，其次是概念验证模板，也就是在组织其他层级复制某个 PoC 模式，以及将概念验证作为种子。例如，某海外大型科技公司的单元测试文化，就是由一群志愿者逐步推动起来的，这很好地说明了实践社群如何发挥作用。

绩效较差的组织，则往往更倾向于设立训练道场和卓越中心。这类策略反而容易造成信息孤岛和专业知识隔离。他们也会尝试概念验证，但这些验证经常停滞不前，最终无法产生实际影响。为什么这些策略往往难以带来有效变革？

卓越中心会把专业知识集中在一个团队，由此带来一系列问题。

首先，卓越中心会成为组织中相关专业知识的瓶颈。当组织对专业知识的需求增长时，卓越中心很难随之扩展。

其次，卓越中心会在组织内部形成一个排他性的“专家群体”，而不是一个包容性的、可以共同学习和成长的同侪群体。这种排他性会侵蚀健康的组织文化。

最后，专家往往会脱离实际工作。他们可以提出建议，或者制定通用的“最佳实践”，但从通用学习到具体应用的过程，却完全取决于学习者自己。例如，专家可能会组织一场关于如何容器化应用的研讨会，但他们自己很少，甚至从未真正进行过容器化实践。这种理论与实践之间的脱节，最终会削弱他们自身的专业性。

尽管一些组织通过训练道场取得了成功，但训练道场需要专门的资源和项目，才能执行初始培训计划并支持持续学习。许多组织投入了大量资源来确保训练项目有效：它们设置独立空间，营造与日常工作环境不同的创新场景，并配备专职人员开发培训材料、评估学习进展。

除此之外，组织还需要额外资源，确保学习成果能够持续，并在整个组织中推广。参加训练道场的团队必须得到支持，才能把新的技能和习惯带回日常工作环境，避免重新回到旧有模式。如果这些资源不到位，组织前期投入就可能付诸东流。

训练道场原本应该是团队学习新技术和新流程，并把它们带回组织其他部门的地方。但在很多情况下，新习惯却停留在训练道场内部，形成了另一个信息孤岛，哪怕这个孤岛只是暂时的。训练道场也存在与卓越中心类似的局限：如果只有训练道场工作人员或独立专家负责创建研讨会和培训材料，而他们自己并不实际执行相关工作，那么这些内容就很容易与真实场景脱节。

混合策略非常常见，但它也常常面临一个问题：任何单项投入都缺乏足够的资金和资源。如果组织没有一套清晰的技术转型策略，就很容易犯“盲目扩张”的错误，最终陷入“项目过多导致失败”的局面：组织在太多领域同时启动项目，结果关键工作得不到足够资源，所有项目都难以成功。

更好的做法，是选择少数几个项目，并持续投入资源，包括时间、资金、高管支持和倡导者支持，确保它们真正取得成功。相比之下，“大爆炸式”推广虽然被提及较少，但在绩效较差的组织中反而更常见。

进一步分析发现，高绩效组织常见四种模式，按流行程度排序如下：

社群建设者。 这类组织专注于实践社群、草根社群，以及概念验证的模板化和种子化。这种模式约占 46%。

新兴型。 这类组织主要依赖草根推动和实践社群，看起来是干预程度最低的一类，约占 23%。

实验者。 这类组织约占 22%。除大爆炸式策略和训练道场策略外，它们在几乎所有策略中都表现出很高活跃度。也就是说，它们参与的活动大多围绕社群建设和创造性尝试展开。它们也经常参与那些后来停滞的概念验证项目。它们能够在高度活跃的实验中保持高绩效，说明它们很可能善于利用这些策略快速实验和验证。

学院型。 这类组织专注于教育和培训，把大部分精力投入到卓越中心、实践社群和训练道场。这种模式只占约 9%，说明它虽然可能成功，但并不常见，而且需要大量投资和规划，才能确保经验教训真正推广到整个组织。

组织变革管理的三项原则

所有组织都是复杂系统。每个组织都有不同目标、不同起点，也有不同的挑战应对方式。在一个组织中有效的方法，在另一个组织中未必适用。不过，仍然有一些通用原则可以提高组织转型成功的概率。

原则一：改进工作永无止境

高绩效组织从不满足于现状，而是持续追求更好。改进工作不是额外项目，而是贯穿始终，并融入团队日常运作。

这些组织的成员明白，不改变的风险与改变本身一样巨大。他们不会用“我们一直都是这么做的”来抵制变革。但这并不意味着变革可以无序推进。变革管理仍然应该以科学方式开展，并服务于可衡量的团队或组织目标。

原则二：领导者和团队就可衡量结果达成一致，团队决定如何实现这些结果

组织中的每个人都必须清楚，自己正在努力实现哪些可衡量的业务和组织成果。

在组织层面，这些成果应该简洁明了，最好几句话就能说清，并且与组织宗旨和使命紧密关联。在单个业务单元层面，成果应该可以用一页纸概括。组织层面的成果应由领导者和团队共同制定，但领导者拥有最终决定权。在组织较低层级，目标则需要更详细，并设定更短的时间期限。

对于跨部门组织转型来说，目标共识还需要落到日常协作机制中。像 Worktile 这样的通用项目协作系统，可以承接任务、项目、文档、目标、日历、审批等工作，让不同部门围绕同一组转型目标推进工作、共享信息并沉淀过程，而不是只在会议中形成短暂共识。

然而，如何实现这些目标，应该由团队自行决定。原因有三点。

第一，在充满不确定性的环境中，仅靠计划无法提前确定最佳行动方案。但这并不意味着计划不重要。团队应该做好准备，根据执行过程中发现的新信息，随时调整甚至重写计划。

第二，当人们被告知“做什么”和“怎么做”时，他们会失去自主权，也失去发挥创造力的机会。这不仅会导致更差的结果，也会削弱员工的工作热情。

第三，解决问题的能力，是帮助员工发展新技能和新能力的关键。组织应该给团队需要解决的问题，而不是只给他们需要执行的任务。

原则三：大规模变革应通过迭代和渐进方式实现

年度预算周期往往会促使组织采用项目制模式。在这种模式下，各类工作都被包装成周期漫长、成本高昂的项目。除少数例外情况外，更理想的方式是将工作分解成可以分阶段交付的小块。

小批量工作有许多好处，其中最重要的一点是：它能让组织根据过程中发现的问题及时调整方向，避免在无法产生预期收益的工作上浪费时间和资金。

从项目模式转向产品模式，是一个长期趋势。对大多数行业来说，这种转变可能需要数年时间，但它显然代表了未来方向。甚至一些海外政府机构也已经成功尝试模块化采购，以更迭代、渐进的方式交付大型项目。

项目交付中的问题，同样适用于转型。组织应该找到快速取得成效的方法，分享经验，并帮助其他团队尝试这些新想法。

组织转型中常见的失败陷阱

领导者在试图推动大规模组织变革时，常常会犯以下错误。

陷阱一：将转型视为一次性项目

在高效组织中，持续改进是一项长期努力，也是每个人日常工作的一部分。然而，许多转型项目却被视为大规模的一次性事件：要求每个人迅速改变工作方式，然后一切照旧。

问题在于，团队并没有被赋予改进工作方式所需的能力、资源或权限。随着流程、技能和能力越来越难以适应不断变化的工作现实，团队绩效也会逐渐下降。

你应该将技术转型视为业务中重要的价值交付活动，并持续投入。毕竟，你会停止对客户获取或客户支持的投资吗？

陷阱二：将转型视为自上而下的行动

在这种模式下，组织汇报关系被调整，团队被重新划分或重组，新流程被强制实施。通常，受影响的员工几乎无法控制这些变化，也没有机会提出意见。

这会造成压力和生产力下降，因为员工必须学习新的工作方式，同时还要履行原有职责。如果再叠加转型计划中常见的沟通不畅，自上而下的方法就很容易导致员工不满，并让他们逐渐失去工作热情。

此外，负责规划和执行自上而下转型的团队，很少会系统收集转型效果反馈，并据此调整方案。相反，计划往往会不顾后果地继续执行。

陷阱三：未能就预期结果达成一致并有效沟通

有些转型目标定义不清，或者目标过于定性而非定量，例如“加快产品上市速度”或“降低成本”。有些目标虽然被设定出来，但并不现实，或者目标本身会造成组织内不同部门之间的冲突。

在这些情况下，我们根本无法判断改进工作是否达到了预期效果。当这种失败与自上而下的方法结合时，组织也很难尝试其他可能更快或更经济的方案。结果通常是，计划执行之后造成大量浪费，却无法确定目标是否实现，也无法判断项目是否有效。

在许多情况下，失败并没有被深入分析，也没有被作为学习机会。组织往往会忽视失败，然后启动新的全面变革计划，或者彻底否定原来的方法论。

将转型视为项目，并把它作为一项自上而下的举措，往往会导致一种常见模式：绩效逐渐下降。在转型项目初期，绩效通常会先恶化，然后有所改善。但随后，组织又会回到过去的运作方式。与此同时，整个组织的怀疑、疲惫和疏离感也会不断加剧。

真正有效的组织转型，不是一次性项目，也不是简单的组织架构调整，而是一套持续改进机制。它需要清晰的战略方向、可衡量的目标、团队自主实验、实践社群传播经验，以及领导者长期稳定的支持。只有这样，组织变革才能从短期运动变成持续提升绩效和能力的日常工作。