报告创作者：优普丰AI敏捷创新培训与咨询机构 & Agile Consulting

获取报告pdf，添加小助手微信：iris202407

作为敏捷从业者，你是否正面临这样的困惑：ChatGPT、GitHub Copilot等AI编码工具普及后，传统规模化敏捷的协作模式失灵了？团队效率看似提升，代码漏洞却暴增？Scrum Master、产品负责人的角色，在AI时代该如何转型？

不用慌！优普丰AI敏捷创新培训与咨询机构&Agile Consulting，重磅发布《生成式AI和编码智能体对规模化敏捷影响的研究报告2026》（以下简称《报告》），基于2023-2025年海量实证数据、企业案例和专家洞见，系统性解答了AI时代规模化敏捷的所有核心难题，堪称敏捷从业者的“生存指南”。

一、报告背景：AI与敏捷的碰撞，倒逼行业重构

当下，生成式AI（GenAI）正经历爆发式发展，GitHub Copilot、Claude、Cursor等编码智能体已成为开发者的日常工具——麦肯锡2024年调查显示，94%的员工和99%的高管都已了解GenAI工具。

与此同时，LeSS、SAFe、Nexus、Scrum@Scale等规模化敏捷框架，已在大型组织软件开发中普及多年，其核心假设是“复杂产品需要多人协作，人际沟通成本随人数指数级增长，需结构化协调机制”。

但AI的崛起，正在彻底挑战这一核心假设：如果AI增强型个人能完成传统团队的工作，规模化敏捷的定义、价值和实践方式，是否需要彻底重构？

正是在这样的背景下，《报告》应运而生——它填补了“GenAI与规模化敏捷交叉领域”的研究空白，通过多维度实证分析，理清了AI对规模化敏捷的影响、风险与未来方向，为从业者提供了可落地的参考。

二、这份报告，能给你和企业带来什么？

无论你是企业管理者、首席技术官、首席信息官、敏捷教练、Scrum Master，还是一线开发人员，这份报告都能精准匹配你的需求，带来实实在在的价值：

（一）对企业：规避风险，找准AI时代敏捷转型的正确路径

1. 破解“不可能三角”困境：明确企业在“生产力、质量、技能”三者间的权衡策略，避免盲目追求AI效率而忽视代码安全和团队能力建设。
2. 建立AI治理体系：针对AI生成代码40-45%的漏洞率、影子AI（员工未经授权使用公共AI工具）等风险，提供可落地的安全管控方案。
3. 优化团队与框架：明确不同规模企业该如何选择敏捷框架（SAFe/LeSS/Nexus等），以及如何调整团队结构，实现“小团队办大事”。
4. 抢占趋势先机：提前布局AI时代敏捷的短期、中期、长期趋势，避免被行业变革淘汰。

（二）对个人：明确角色转型方向，提升核心竞争力

1. 敏捷角色升级指南：清晰告知Scrum Master/敏捷教练如何从“流程守护者”转型为“AI赋能者”，产品负责人如何聚焦业务洞察，开发人员如何从“代码编写者”转向“代码审核员/架构师”。
2. 掌握正确AI使用模式：区分“高分AI使用模式”（生成-理解、概念探索）和“低分模式”（完全委托、过度依赖），避免技能退化。
3. 提升AI+敏捷技能：明确未来3-5年敏捷从业者的核心技能要求，提前布局学习，实现职业升级。

三、报告核心内容拆解：这些重点，必看！

《报告》全文近100页，涵盖研究背景、核心发现、跨领域洞见、实践建议、未来展望等8大模块，以下是最关键的核心内容提炼，帮你快速抓住重点：

（一）核心发现：AI对规模化敏捷的5大颠覆性影响。

1. 协作模式重构：从“顺序交接”转向“平行共创”，设计师可直接修改代码，非专业人士可完成小幅变更，角色边界模糊。
2. 效率与质量失衡：AI可使开发速度提升12-55%，但40-45%的AI生成代码存在安全漏洞，代码质量指标持续恶化（重构率下降60%，代码克隆率上升48%）。
3. 技能退化风险：AI辅助编程会导致开发者代码理解能力下降17%，调试能力差距最显著，过度依赖AI会丧失核心技能。
4. 框架适配差异：仅SAFe框架发布了AI相关指导，LeSS、Nexus、Scrum@Scale官方文档均未提及AI，理论滞后于实践。
5. 影子AI风险凸显：员工未经授权使用公共AI工具处理敏感代码，易导致商业秘密泄露（如三星开发者将机密代码粘贴到ChatGPT）。

（二）跨领域洞见：3个关键结论，打破认知误区

1. 不可能三角：企业无法同时实现“生产力、质量、技能”三者提升，必须根据业务目标做出战略取舍（如“生产力优先+自动化安全测试”“质量优先+选择性使用AI”）。
2. 人机协作范式转变：AI不再是工具，而是“机械队友”，具备激励、协作、知识补充等社交属性，团队协作从“人类协作”转向“人机混合协作”。
3. 规模化重构：AI可能实现“去缩放”——10-20名AI增强型员工，可完成传统50人以上团队的工作，传统规模化框架的必要性面临挑战。

（三）可落地建议：分层次给出行动方案

《报告》针对企业、团队、框架采用者，分别给出了不同周期的行动建议，直接套用即可：

• 企业层面：0-3个月制定AI使用政策、部署自动化安全测试工具；3-6个月构建AI治理框架、开展技能培训；6-12个月重新设计敏捷角色、评估团队规模需求。
• 团队层面：推广高分AI使用模式，避免完全委托；扩展“完成定义（DoD）”，增加AI代码安全验证；重新设计敏捷仪式（如AI辅助冲刺计划、回顾会议）。
• 框架采用者层面：不等待官方指南，主动试点AI+敏捷实践；重新评估规模化需求，避免过度设计；重视敏捷价值观，灵活调整实践形式。

（四）未来展望：3个周期趋势，提前布局

1. 短期（0-1年）：主流敏捷框架将加速更新AI相关指南，AI技能培训爆发式增长，自动化安全测试成为标准流程。
2. 中期（1-3年）：部分企业实现“去缩放”，团队规模缩减；敏捷角色发生显著变化，人机协作模式成熟；技术债务危机可能爆发。
3. 长期（3-5年）：规模化范式彻底改变，团队平均规模缩减至3-5人；AI成为“真正队友”，参与规划、审查等全流程；敏捷本身可能需要重新定义。

四、报告获取，free！

这份凝聚了麦肯锡、GitHub、斯坦福大学等20个权威数据源、近100页的实证研究报告，涵盖了AI时代规模化敏捷的所有核心要点，无论是企业转型还是个人成长，都能从中找到答案。

想要获取完整报告？

✅ 添加小助手微信：iris202407

✅ 发送关键词【2026AI规模化敏捷报告】

✅ 即可领取完整电子版报告，还可加入敏捷交流group，和同行一起探讨AI+敏捷的实践难题～

（温馨提示：报告限时free领取，手慢无，建议敏捷从业者、企业管理者尽快领取！）

AI正在重塑软件开发行业，规模化敏捷的变革已不可逆转。与其在迷茫中试错，不如借助这份权威报告，找准方向、规避风险，在AI时代实现企业和个人的双重升级！

史诗负责人（EO）与利益相关者协作定义史诗、精益商业案例和最小可行产品（MVP）的定义，并负责引导史诗通过组合看板系统。如果精益组合管理（LPM）批准了史诗，史诗负责人会协调将史诗引入到敏捷发布列车的实施过程中，而Scrum 培训能帮助史诗负责人掌握跨团队协调的核心方法。

需求史诗负责人详解

在投入实施之前，史诗需要进行分析、制定精益商业案例以及定义 MVP。史诗负责人负责引导史诗完成这一过程所需的关键协作。企业架构师通常担任使能史诗的史诗负责人。史诗的实施通常需要多个敏捷发布列车（ART）的协作，史诗负责人负责协调这项工作，而敏捷培训中的跨团队协同模块能进一步提升协调效率。

“协作” 是该角色的关键定位与目标

史诗负责人可以来自企业的任何地方，但只有通过与其他利益相关者的密切协作，他们才能发挥效力。他们帮助填补规划和执行中可能出现的空白。图 1 突出显示了通常担任史诗负责人角色的人员以及他们促进的关键协作。

图 1. 史诗负责人与关键利益相关者的协作

通常，史诗负责人会处理其专业领域和当前业务使命范围内的史诗。史诗负责人负责通过与这些团体的密切合作来制定和细化史诗，并分析其成本和影响。这种跨部门协作的规划与执行能力，也是企业管理培训中的核心教学内容。

需求史诗负责人的工作职责划分

图 2 展示了史诗负责人的四个主要职责领域。

图 2. 史诗负责人的四个职责领域

以下部分描述了这些职责。

1. 引导组合史诗

史诗负责人引导史诗通过组合看板系统，从识别到实施，与利益相关者和主题专家密切合作。图 3 展示了史诗负责人在组合看板系统每个状态中的角色。

图 3. 史诗负责人引导史诗通过组合看板的角色

史诗负责人在引导组合史诗的过程中，需要熟练掌握迭代规划、优先级排序等实践，这些内容在Scrum 认证培训中均有系统讲解，能帮助其更规范地推进史诗流转。

2. 创建精益商业案例

进入分析状态的史诗需要更严格的探索、精益商业案例和进一步的投资来评估其成本和收益。这种分析通常需要以下角色之间的积极协作：

• 业务负责人
• 系统架构师和解决方案架构师
• 产品管理和解决方案管理
• 敏捷团队

史诗负责人、利益相关者和内部团队协作确定史诗的规模，并基于加权最短作业优先（WSJF）、精益商业案例和其他相关信息为经济优先级提供输入。

史诗负责人负责分析史诗和创建精益商业案例所需的关键协作。同时，企业架构师通常协调支持业务史诗技术考虑的使能史诗。

史诗负责人主要负责创建精益商业案例并向精益组合管理（LPM）展示，以获得 “通过” 或 “不通过” 的决定。然而，批准并不是保证的，因为企业通常有比他们能够执行的更多想法和机会。因此，在展示史诗时，史诗负责人应关注商业案例的优点，确信构成 LPM 基础的协作讨论将确保他们做出最佳投资选择。而企业管理培训中的商业案例分析课程，能为史诗负责人提供更专业的方法论支持。

3. 支持 MVP 的开发

史诗获得批准后，史诗负责人与 ART 合作启动 MVP 的开发活动，遵循 SAFe 精益创业策略来评估业务成果假设。

该策略推荐用于产品创新和战略投资的高度迭代的构建 – 测量 – 学习循环。它通过增量管理投资和风险，同时利用 SAFe 的流动和可见性优势，提供精益创业的经济和战略优势（参见史诗）。

开发 MVP 并收集必要的数据来证明或反驳史诗假设是一个高度迭代的过程，持续进行直到获得积极结果，或者团队消耗了为 MVP 分配的投资。已证明假设的输出是一个适合获取客户反馈的 MVP，这将保证价值流的进一步投资。如果假设被证伪，则停止对史诗的投资。这种迭代开发的思路与Scrum 培训中强调的冲刺交付、快速验证理念高度一致。

4. 协调史诗的开发过程

如果史诗假设被证明，史诗负责人通常在跨价值流协调其实施方面发挥重要作用，包括：

• 与产品和解决方案管理以及系统和解决方案架构师协作，将史诗分解为特性和能力，并帮助在各自的 ART 和解决方案列车待办事项中确定这些待办事项的优先级
• 每当有与史诗相关的关键活动时，参与 PI 规划、系统演示和解决方案演示
• 与执行研究冲刺、创建概念验证、原型等的敏捷团队合作
• 与销售、营销和其他业务部门协调和同步史诗相关活动
• 促进史诗通过持续交付管道的实施和按需发布
• 了解史诗的进展并向关键利益相关者和 LPM 报告

史诗负责人的角色通常持续到 ART 将史诗充分整合到他们的路线图中，并且不再需要史诗负责人的专业知识或协调为止。这一过程中的跨团队沟通、冲突解决能力，可通过敏捷培训中的实战演练进一步强化，而Scrum 认证培训能为其提供标准化的协作框架和工具。

在软件时代竞争

在她的著作《技术革命与金融资本》中，Carlota Perez基于她对过去三个世纪五次重大技术革命的分析，解释了商业、社会和金融周期的演变。她的研究始于工业革命，然后是蒸汽和铁路时代、钢铁和重型工程时代，以及现在的软件和数字时代，如图1所示。Perez得出结论，这些革命导致了大规模的社会变革、市场颠覆和全新的经济秩序。事实上，这些是震撼世界的颠覆，通常一代人只会发生一次。

图1. 技术革命改变社会

我们现在正处于其中一个时代，即软件和数字时代的部署阶段。在这个时期，每个企业都是软件企业。简单地说，在这个时代竞争需要大规模的软件和系统开发能力，以实现真正的业务敏捷性，而Scrum认证培训能为企业提供规模化敏捷开发的标准化框架。

为什么组织难以实现业务敏捷性

我们在20世纪创建的组织设计更多是为了可靠性和效率，而不是敏捷性和速度。— John P. Kotter，《加速》

大多数传统组织的领导者都意识到数字化颠覆的威胁，但许多人未能过渡到在下一个经济时代占据一席之地。问题是，为什么？

组织始于快速适应的网络

作为组织研究员和作者，John Kotter在他的著作《加速：为更快速变化的世界构建战略敏捷性》中阐述，成功的企业并非一开始就庞大而笨重。相反，它们通常始于一个快速移动、适应性强的有动力的个人网络，专注于响应客户和新的商业机会。角色和汇报关系是流动的，人们有机地合作，以确定客户需求、探索潜在解决方案，并以任何可能的方式提供价值。换句话说，它是一个适应性强的”创业网络”，人们致力于利用机会（图2）。

图2. 新企业作为专注于客户和新商业机会的网络运作

层级形成，然后不断增长

随着企业的成功，它自然希望扩大其成功并成长。这种增长意味着个人责任必须变得更加明确。结果，企业雇佣专家来增加专业知识，创建新的职能领域。政策和程序确保法律遵守和合规，推动可重复、成本效益高的运营。业务开始在功能上组织起来以实现规模化，导致孤岛形成。同时，并行运行的网络继续寻求提供价值的新机会（图3）。实现更大的规模经济需要层级结构的增长。它不断增长，直到与创业网络发生冲突。

图3. 不断增长的层级结构与创业网络并行运行

层级结构与适应网络发生冲突

最终，层级结构与移动速度更快、更具适应性的网络发生冲突。结果如何？适应性网络被压垮。对客户的关注往往是主要的牺牲品之一（图4）。

图4. 创业网络与不断增长的层级结构发生冲突

没有创业网络，当客户需求发生重大变化或出现颠覆性技术或竞争对手时，组织缺乏响应的敏捷性。一场紧急危机爆发，公司的生存现在处于危险之中。然而，过去五十年来建立的组织层级结构提供了经过时间检验的结构、实践和政策。它们支持在全球范围内招募、保留和发展数千名员工。简单地说，它们仍然是需要的。

在解决这个困境时，Kotter指出：”解决方案不是丢弃我们所知道的并重新开始，而是重新引入一个更敏捷、类似网络的结构”，该结构与层级结构协同运作，创建他所谓的”双操作系统”。如图5所示并在以下部分描述的这个系统，允许公司利用快速战略挑战并保持其稳定性[3]。

解决方案：SAFe是第二操作系统

现有的层级结构、人员和管理仍然有其目的，并在很大程度上保持不变。然而，SAFe创建了第二个虚拟操作系统，围绕开发价值流而不是职能孤岛（或部门）组织，形成创业网络。每个开发价值流创建一个或多个敏捷发布火车（ART），具有共享的业务和技术使命。每个ART一起规划、承诺、开发和部署。它们是开发创新产品（解决方案和服务）的创业网络的组成部分。

尽管层级结构中的管理汇报结构可能基本保持不变，但ART中的团队是自组织和自管理的，他们不再需要日常任务指导。ART是虚拟组织，拥有定义、交付和运营解决方案所需的人员。这个新的虚拟组织打破了阻碍流动和创新的传统职能孤岛。通过围绕价值流而不是部门组织第二个操作系统，SAFe为组织提供了一种方式，在与现有层级结构和谐相处的同时，专注于客户、产品、创新和增长。

此外，这个操作系统是灵活的。它建立在经过时间检验的精益敏捷SAFe实践之上。它可以组织和快速重组，而不会完全破坏现有的层级结构，如图5所示。这就是业务敏捷性的要求。

图5. SAFe作为第二个组织操作系统

响应市场变化和新兴机会对于在数字时代生存至关重要，在这个时代，颠覆是常态而非例外。技术进步通过开辟各种在市场上获胜的方式，彻底改变了竞争游戏的动态。快速响应创新业务解决方案的能力——我们称之为业务敏捷性——是成功与失败之间的决定性因素。因此，实现业务敏捷性是每个组织领导者的关键任务目标，而企业管理培训能帮助领导者掌握双操作系统的构建与协同管理能力。

组织必须首先理解然后应用SAFe业务敏捷性价值流（BAVS），以更快地交付价值，留住今天的客户并赢得新客户。BAVS帮助组织可视化步骤并实施所需的SAFe核心能力，以在最短的时间内从识别机会转变为交付客户价值。以下部分更详细地描述了BAVS。

业务敏捷性的核心能力

实现业务敏捷性需要这种双操作系统和SAFe七个核心能力的显著专业知识，如图6所示。幸运的是，它们是SAFe的一部分，随着组织采用框架，他们会随着时间的推移逐步获得这些能力。虽然每个能力本身都能提供价值，但只有当企业在所有方面都取得显著掌握时，真正的业务敏捷性才会出现。这是一个很高的要求，但路径是明确的。

图6. SAFe核心能力

每个能力都在同名文章中描述。您可以轻松地从SAFe概述选项卡或SAFe主页导航到每个能力。

为什么需要业务敏捷性价值流（BAVS）？

数字化转型几乎在所有业务流程中都在推进。人工智能、大数据和云计算等技术正在解锁创造新客户价值的可能性。新的商业机会更频繁地出现，许多有潜力颠覆市场现有企业。不断利用这些技术的公司将获得更多客户，并为现有客户提供更好的价值。最终，他们将主导各自的市场。例如：能够通过易于使用的移动应用程序无缝满足其主要银行需求的客户将对该银行保持忠诚；开创家庭虚拟紧急护理的医疗机构将赢得所有需要帮助的人的感激和忠诚；车辆每天变得更智能、更安全的驾驶员更有可能对该汽车制造商保持忠诚。

传统开发无法帮助您实现目标

在这个新现实中，竞争力等同于快速交付数字化支持的解决方案。如图7所示，响应传统的阶段门开发过程可能意味着错过机会。

图7. 利用商业机会的传统方法太慢了

等待资金周期、前期大设计和长开发周期导致技术和客户反馈延迟。而且很可能，在这个周期结束时的学习并不积极。简单地说，使用传统开发方法很难（如果不是不可能的话）理解和适应客户需求并快速交付解决方案。

引入业务敏捷性价值流

相反，我们需要的是一个快速的感知和响应周期，帮助企业驾驭未知因素并在机会窗口关闭之前到达理想的解决方案。这就是业务敏捷性价值流（BAVS），如图8所示。它明确设计用于促进快速学习并实现更有利的业务成果。通过实施SAFe，企业本质上发展了精益、敏捷和DevOps能力，这些能力将允许规模化增量交付。虽然这些能力是必不可少的，但建立真正的业务敏捷性需要培养和加速整个BAVS的流动，从感知新兴机会到交付正确的解决方案（图8）。

图8. 利用新商业机会的更快方法

业务敏捷性价值流中的步骤

虽然BAVS的具体实施取决于业务环境（组织、市场、客户、技术和解决方案），但步骤和基本结构基本相同。此外，成功完成BAVS每个步骤所需的知识、技能和行为在相关的SAFe核心能力中描述，如下所示。这种敏捷性要求端到端的所有功能、流程、活动、团队和事件都要对齐并优化，以实现最大速度和质量。以下步骤构成了这个价值流：

感知机会

第一步，当然是能够感知机会！这一步需要SAFe组织敏捷性核心能力，该能力促进以下活动：市场研究、定量和定性数据分析、直接和间接客户反馈、在市场中直接观察客户。大多数直接精明、精益思维的领导者都会”亲自去看”，并在客户工作的地方花费大量时间。他们带着关于其产品和服务现实的当前、相关、直接和具体的信息回来，并确定创新新解决方案的机会。

为MVP提供资金

企业必须能够通过灵活的资金快速响应这些机会。精益组合管理（LPM）是支持这一步所需的核心能力。通过LPM，精益预算提供了快速分配足够资金以构建最小可行产品（MVP）的能力——用于评估主要业务假设的解决方案早期版本。MVP中的”最小”指的是测试假设和建立解决方案可行性所需的实验成本低。随着新计划流经SAFe组合看板系统，这些资金决策变得可见并得到解决。

围绕价值组织

下一步是组织——或根据需要重组——以应对新机会。MVP通常可以由现有的敏捷团队或敏捷发布火车（ART）构建，因为新工作会进入各自的待办事项。然而，创建MVP也可能涉及修改现有团队和ART。在更极端的情况下，可能需要形成一个全新的开发价值流。两个核心能力——团队和技术敏捷性和组织敏捷性——实现了这种灵活性，而团队的敏捷组织能力可通过Scrum培训强化。

连接客户

敏捷开发本质上专注于确保与客户的直接连接，而以客户为中心是支撑它的思维方式。这种经营方式专注于在企业的整套产品和服务中，以及在整个客户旅程中为客户创造积极体验。设计思维提供了工具，帮助团队和ART通过与用户共情来设计正确的解决方案。敏捷产品交付是实现这种连接的核心能力，而团队对设计思维的应用可通过敏捷培训提升。

交付MVP

证明在于行动。敏捷团队和ART遵循精益敏捷实践，迭代和增量地交付MVP。然而，团队和火车在MVP上的工作方式与在成熟解决方案中发展功能有所不同。首先，风险和不确定性更大。未知数可能在关键领域表现出来，包括技术选择、实施策略、组织专业知识、部署、运营、客户接受度和业务效益。需要更多的实验甚至更快的反馈。但这正是SAFe优化的目的。根据解决方案的范围，敏捷产品交付和企业解决方案交付是实现这一步的两个核心能力，而团队的迭代交付能力离不开Scrum认证培训的系统培养。

调整或坚持

MVP的结果是一组事实，支持关于是否继续进一步解决方案开发的决策。如果假设被证明是错误的，组织接受沉没成本并转向其他商业机会。如果假设被证明是有益的，额外的资金随之而来，以支持进一步的开发。然而，MVP的结果并不总是简单的是或否。实验可能产生重要的见解，揭示新的替代解决方案。这个决策点是一个关键的投资里程碑，是组合看板系统中的关键阶段。同样，精益组合管理是实现这一步的核心能力。

持续交付价值

确认假设的成功MVP打开了大门，通过额外的解决方案功能持续交付价值。这个过程依赖于敏捷产品交付，促进由ART直接驱动的迭代和增量开发。在DevOps的基础上，这些实践包括优化持续交付管道，确保价值的稳定流动和按需发布的能力，以满足客户和企业的需求。对于一些组织，这些解决方案代表大型、重要和复杂的应用程序和网络物理系统，需要数千名开发人员和许多有能力的供应商在解决方案火车内协调他们的努力。企业解决方案交付是在这种情况下实现这一步的核心能力。

学习和适应

学习和适应不是最后一步。单个计划很少决定业务成果。相反，企业从BAVS和过程中学习，并根据这些学习进行适应。测量是改进的一个组成部分。如图9所示，三个测量领域——能力、流动和结果——提供了关键的视角和组织绩效的度量，有助于识别障碍和改进机会。持续学习文化核心能力是积极变化背后的主要驱动力。学习型组织有一种紧迫感，不断寻找新的商业机会和现有流程和解决方案的改进。事实上，BAVS是持续学习的一个例子，实现持续创新。此外，通过SAFe操作系统各级的定期检查和适应活动，还会发生其他形式的学习和适应。

精益敏捷领导力赋能BAVS

没有精益敏捷领导力，这一切都不会发生，它是SAFe和BAVS的基础。BAVS代表了大多数企业的一种新的工作方式，这与现状有很大不同，并影响现代企业的大多数方面。精益敏捷领导者将组织视为一套动态的业务敏捷性价值流，追求并利用关键的商业机会。重要的是，他们领导变革以达到这个新状态。之后，他们将组织的重点放在成功的BAVS执行和随着时间的推移改善BAVS绩效上。只有这样，才能实现业务敏捷性，而领导者的精益敏捷思维可通过企业管理培训和敏捷培训的结合培养。

测量业务敏捷性价值流

如图9所示，SAFe提供了三个测量领域——流动、结果和能力——适用于测量和改进任何价值流，包括至关重要的BAVS。

图9. 三个SAFe测量领域支持业务敏捷性的目标

• 流动。指标有助于确定价值流创建和交付价值的速度，由流动分布、速度、时间、负载、效率和可预测性表示。
• 结果。指标有助于确保交付的解决方案对客户和业务有益。价值流KPI主要用于测量这些结果。
• 能力。测量在两个层面评估组织熟练程度：SAFe业务敏捷性评估，为业务和组合利益相关者提供了一种评估其整体进展的方法；各个SAFe核心能力评估，帮助团队和ART改进他们的技术和业务实践，以实现组合的目标。

业务敏捷性的道路漫长而无止境。测量它有助于企业了解他们在旅程中的位置，并提醒他们庆祝小的成功。

写在业务敏捷性的最后

欢迎来到软件和数字时代，在这个时代下，业务敏捷性将是决定新经济中赢家和输家的最重要因素：精益敏捷的商业企业将创造更高的利润，提高员工参与度，并更彻底地满足客户需求；精益敏捷的非营利组织将建立韧性、可持续性和实现其使命所需的一致性；精益敏捷的政府将交付更好地确保公众安全、经济和一般福利的系统。这三个市场细分都依赖于比以往更快、更高效地交付创新业务解决方案。每个都需要一个双操作系统：一个用于效率和规模的层级结构，以及一个提供创新解决方案的以客户为中心的网络操作系统。大规模敏捷的七个核心能力将使这个至关重要的双操作系统成为可能，而Scrum培训和Scrum认证培训则是企业掌握这些核心能力的关键路径。

产品为王

银行产品的内涵与外延

虽然在系统建设中，我们总是想办法去建构“产品工厂”或“产品中心”，但实际上，即使是对银行产品下定义都是非常困难的。与手机、电脑等显而易见的有物质实体承载的产品不同，商业银行的“产品”，多数时候实际上是一揽子为客户提供的服务的组合，而服务通常极其复杂。《设计心理学》一书中，作者诺曼不无吐槽地指出，“我们最常见的服务，驾照、护照签发、缴纳所得税…都有庞大的官僚主义规章制度，一大批机构内部的人，经常还有公司里面都会有的很多个部门，声称负责所有非常规性问题。….所有那些在幕后的东西–那些神秘地运作着，形成顺利、高效或者令人困惑的运作效果的东西，被称为’后台’….”

循着诺曼对服务的解释，银行产品的定义从狭义上可以做如下概括：“银行产品，是银行基于特定金融需求，面向特定客户群体（个人或企业），设计并提供的、具有明确功能、使用规则、定价机制和服务流程的金融服务方案。它本质上是银行与客户之间围绕资金流动、风险管理、价值增值等核心金融活动所建立的契约化服务载体”。在这一定义中覆盖的产品包括两类，一种是面向规模化长尾客户提供的标准化产品（比如微粒贷、余额宝）；另一种是面向特定行业，甚至个别客户定制的，但又具备可复制、推广的金融服务解决方案/产品，比如面向特定行业，甚至特定核心企业的定制化现金管理、分级账簿、供应链金融解决方案等。

面向客户的银行产品可以做以上定义，但因前、中、后台的存在，银行产品常常在内部管理及部门协同过程中造成困扰，一款产品，你是站在客户视角，还是中台业务，或是后台运营、财务视角，看到的情况是不一样的。银行中对客户来说是后台的部分对业务管理部门来说就是前台，而对业务管理部门来说是后台的部分，对运营或者财务来说，又是前台，每个角色都有自己的前台和后台。举个例子，以最近国内新能源汽车供应商应收账款账期问题为例，在此案例中，供应商可以向商业银行转让对整车厂的应收账款债权而获得现金流。在这个业务中，供应商，即银行的企业客户感受到的产品是“应收账款债权转让融资”，而在银行中台–一般是负责贸易融资管理的中台部门（如交易银行部或贸易金融部、企业金融部之类的），这个产品一般被定义成“保理融资”（并细化成有追索权、无追索权、需要进行债权转让确权的明保理，或者无需确权的按保理等等），而到了财务部门编制会计科目时，这个产品可能就变成了“前收息模式的预支价金”，最后在IT系统中，这本质上与一笔预收息的贷款没有任何区别…

从上述例子中不难看出，正如诺曼所言，“成功的产品必须合并内部和外部成分的所有不同层面，协调地支持所有可见和隐藏的服务和操作。产品存在于一个复杂的交互网络中….”

为什么需要重视产品

其一，做好产品论证与分析，有利于资源的有效投入，获得正向回报。有过银行系统的开发经验的工程师们或许都有过这样的经历：一个被催的十万火急，必须限期完成的项目或者需求，在项目组人员加班加点、蓬头垢面地忙活一圈，上完线后过几个月一统计：新增客户数0，新增收入0，业务价值0。随之而来的解释通常是这样：业务效果未达预期，是因为这是一次“快速试错”，潜台词则是“因为是试错，所以没有业务效果是正常的”。只不过，如此试错的代价是银行的宝贵预算，以及其他更有价值的项目或产品被影响，还有倒霉的程序猿们的加班加点。

当然，这里面，有一部分的确是面对不确定的市场，不得不付出的试错成本（毕竟成功很大程度上是概率事件），又或者是为了营销客户，必须付出的成本，即某个产品或解决方案，你有，客户不一定选择你，但如果你没有，客户连机会都不会给你。有问题的是不经研究和论证，拍脑袋决策、仓促开干的项目和产品，提出者将开发压力交给IT，将客户经营压给分支行，将业务效果交给天意。

其二，银行产品不仅仅是功能工具，更是银行定位战略的载体和品牌形象的关键塑造者，通过产品建立的印象有利于建立正面的客户心智。特劳特在《定位》一书中，提出企业成功的关键，就是“如何在潜在顾客的心智中占据一个有利位置”，而在“信息传播过度的社会里，传播简化的信息是唯一有效的方法。” 产品便是那个能够简化信息传播的关键抓手。“微粒贷”的成功，不仅仅是为webank的资产规模、利润规模作出重要贡献，其形成的客户对微众银行提供的服务便捷、科技、专业、普惠的印象，也被投射到微业贷、微众银行智能存款等产品中，奠定了微众银行在客户心智中的整体印象。

其三，银行产品不仅是满足需求的工具，更是低成本、高效率获客的核心引擎。原因有三：1）、一款具有强吸引力的“钩子”产品，本身就是最低成本的获客广告。2）、产品体验（流畅度、功能满足度、收益/利率竞争力）是用户是否留下的关键。糟糕的产品体验会让辛苦营销来的客户瞬间流失。3）、产品内设计交叉销售路径（如理财用户看到专属贷款优惠、贷款客户引导开通关联还款账户/信用卡）和用户分层运营机制（如VIP等级体系对应专属产品/服务），可以提高客单价，让存量用户产生更多价值。

产品设计需要关注的高阶问题

大多数机构的没有华为那种可以建立IPD（集成产品管理）的能力，也没有腾讯那种刻在基因里的产品文化。有什么办法能够一定程度上做到“谋定而后动”呢。这便是通过一定的流程和机制设计（比如产品审批、产品委员会审核），确保在一个需求或一款产品开始建设前，一定要将如下问题回答清楚，即经典的5W1H分析法：

WHO：产品为谁设计？目标客户是谁？目标客群有什么特点？购买者和使用者是同一个吗？目标客群有多大规模？最乐观与最悲观的情况下，分别的转化率与留存率预计有多少？

WHY：我们的产品有什么差异化竞争优势？客户为什么选择我们？产品有哪些竞品？有可替代产品吗？（比如信用卡与花呗）

WHEN：用户什么时候使用我们的产品？多久用一次？产品有政策窗口期吗？（商业银行产品必须非常关注的，比如票据市场、外汇市场、债券市场的阶段性机会）产品有市场窗口期吗？（比如ETC扣费的短暂窗口期）

WHERE：产品有可能完全线上化？用手机用方便还是电脑用方便？（这在企业银行业务中，尤其是中大型企业中特别需要关注，因为企业员工坐班原因，网银比手机银行更受青睐，再大的企业，则需要银企直连，因为企业员工只想在自己的ERP等内部系统上操作）可以使用H5进行场景投放吗？

WHAT：产品的具体形式，或载体是什么？产品要做成怎么样？产品的定价如何？

HOW：用户怎么交互？交互设计涉及的概念模型、示意符号、功能入口布置等等。（在互联网想方设法投入巨资仅仅是为了客户少点一下手机的当下，商业银行的很多设计还是不惮于打扰客户，有些交互的设计简直就是为了刻意给客户制造麻烦….）

在”5W1H分析法”之外，还要考虑产品建设的“时间成本”、“资金成本”、“风险成本”与“行动成本”等等。一份需求也好，一个产品也罢，事前做好分析论证：判断要不要做，值不值得做，做完了怎么获客，怎么演进，比知道产品和需求怎么去做更重要。如果说IT的能力养成是为了能够“正确的做事”，那么，产品论证分析则指向一个更重要的命题–如何尽可能保证“做正确的事”。一件事不值得做的事，自然就不值得做好。

产品团队责任重大

在传统商业银行的组织架构模式下，以前、中、后台条块化组织的一个机构中，要确保“做正确的事”殊非易事，如果组织不能实现有效的协同，就会出现好像个个部门都在认真履职，而最后什么事都做不成的情况。而要做好这些，除了董事会及经营管理层的决策部署外，在执行层面，需要有人来完成“市场分析、用户研究、收益成本分析”，并对“产品定位、产品设计、产品推出时机、产品营销方案”等进行说明，最后还要想办法协同相关部门，取得配合部门的支持。总之，要向前能够连接起分支行，向后能够协调好风险、财务、法规、营运、IT，为达成一个共同的目标而努力。这在商业银行，从来都是一个不易解决的问题。

在商业银行的机构设置中，处于“中台”位置的总行业务主管部门，比如零售的消费金融、财富管理、汽车金融、信用卡，对公的交易银行、贸易融资、国际业务、商业汇票专营等部门，以及具有全线上产品设计、运营职责的网络金融部门，专注SME经营的小微或普惠金融部门，天然具备深耕本领域业务，知晓领域业务特性，向前可连接并向分支行下达经营指标，横向可以拉通兄弟部门，实现公私联动、存贷联动产品设计，向后可以拉通风险、财务、法规、财务、IT等的能力，作为利润创造中心的特点，这些部门也最有能力和动力通过整合资源达成业务目的。统筹产品设计与经营，中台产品部门责任重大、使命光荣。

要完成如此重要的工作，对产品经理的能力要求自然被显著地放大了。与风险、IT、法律、财务等仅需要专注于某一领域的专业技能不同。一个好的产品经理，除了需要对本领域的银行业务有深入且独到的理解外，通常还需要具备一定的法律基础知识，比如知道《民法典》中关于合同、担保、物权的法律条款。如果产品经理正好对会计知识有所了解，那么在跟财务部门争取更优惠的FTP定价，在思考如何通过非融资性保证业务降低RWA占用方面，就会占有优势；产品经理如果有IT背景，知道一个功能大致的实施难度与实施周期，就能避免“这个需求很简单、怎么实现我不管”的冲突；如果产品经理对设计有基本的了解，就能在产品设计中很好地完成关于等待、推荐、反馈、提示及概念模型的设计；如果产品经理对宏观经济学、货币银行学、监管法规有好的了解，那么就更能敏锐的发现监管政策窗口与市场机会。最后，产品经理还需要有天然的直觉，对人性的洞察，以及卓越的沟通能力。

“With great power comes great responsibility”，这也正是乔布斯、马斯克、马化腾、雷军、余承东、张晓龙等一众大佬，都被认为是大产品经理的原因。

产品思维

产品设计者面临的困境

在“传统”商业银行中，产品部门、产品经理要做成一件事，需要有效协调前、中、后台部门的支持，需要识别市场机会，又要面对监管约束，常会面临三重困境。一是专业深井困境。在商业银行中，一款产品通常涉及的风险、法规、财务、科技等部门，各有各的专业语言，比如风险中的PD、LGD、EAD、M、RAROC、EVA、FPD、DPD、AUC、KS等；法规中关于要约、承诺、无因性、善意取得、质权、债权、留置权、一般保证、连带责任等；财务中的各种资产、负债、收入、支出、费用、未分配利润、表外、FTP定价、利率重定价曲线等等。IT则自不必说，从应用架构到数据模型，知识体系纷繁芜杂。也因此，产品也成为“翻译损耗”的重灾区。所谓对“跨界复合型人才”需求最高的领域，产品类岗位首当其冲。二是创新悖论困境。商业银行因为其经营特点的特殊性及对国民经济的特殊重要性，受到央行、金融管理局等的强监管约束，以巴塞尔协议“资本约束 – 监管干预 – 市场制衡” 为内核的三维监管体系需要商业银行的“创新”活动必须在规定的框架内进行。而与此同时，一些泛金融机构，如商业保理公司、金融租赁、消费金融公司、网贷公司、第三方支付公司等，其监管约束（从监管主体到监管细则）与商业银行不可同日而语。部分机构因此得以进行的“擦边球”创新，对商业银行构成极大的竞争压力，此其一；其二，以互联网，尤其是头部互联网公司为代表的，金融产品获客、交互体验创新，则对商业银行形成了降维打击。因此，对商业银行而言，一方面需要“守正”，一方面又需要“创新”。三是价值量化困境。财务可以通过利润表直接记录收入、支出和利润，风险可以通过五级资产分类和不良率计量损失，IT可以通过刚性费用衡量投入，而产品价值却往往与市场、营销、内部的资源投入及协同等众多因素相关，因此难以剥离归因。产品部门的绩效计量，在缺乏产品基因的机构，向来都不容易。《人人都是产品经理》一书中提出：“产品是解决问题的载体”。而银行问题的复杂性在于——它既是数学问题（定价模型、资本计量）、工程问题（系统架构、流程耦合）、行为问题（用户心理、组织协同），更是哲学问题（风险与效率的永恒博弈）。

五大产品思维

在2015年“互联网+”时代前后，商业银行曾掀起一股向互联网学习的热潮。彼时，”互联网的13种思维”，”互联网独孤九剑”等曾被商业银行奉为圭臬。其中的内容鱼龙混杂，不少指向的不是踏踏实实的价值创造，而更像某种方式的割韭菜指南。当然，其中也不乏值得学习借鉴的，但那并不仅仅是互联网特有，而是各行各业的普遍性真理，也即《腾讯产品法》中提到的五项思维模式，分别是：第一性原理思维、系统性思维、相对思维、抽象思维和演进式思维。在“技术可购买、流程可复制、客群需要争夺”，金融产品同质化加剧的今天，产品设计者这这些方面的思维认知能力，对构建商业银行全局或局部竞争优势十分关键。第一性原理思维。第一性原理思维要求只采用最基本的事实作为依据，在传统的产品设计的前提下重点观察它的前提条件是否发生了变化、是否有优化的空间、是否还有更优的解决办法。通过不断追问的方式，剥离所有表象后，识别产品解决的最原始需求是什么。第一性原理最需要挑战的，是对商业银行“传统”做法的挑战–即“祖宗之法可不可变”的灵魂追问。以笔者曾经历过的一个项目为例，因为历史上票据贴现账务在核心的贷款模块记录的原因，即使在投产了商业汇票系统后，这一“传统”仍然被保留，因而导致客户每次在申请票据贴现时，运营部门都需要先为客户开立一个贴现账号。但实际上，贷款业务首先从本质上就不需要所谓的“账号”，而只需要编列“借据–IOU”，其次，贴现业务与贴现票据强相关，其明细账在票据系统分录，科目账在总账系统反映即可。基于这一原理性分析，后来我们在方案实施过程中，就直接取消了贴现账号，既减少了系统间交互（信贷、票据与核心之间的多次交互），又简化了作业流程。

系统性思维。银行产品的本质是多重复杂系统的耦合体，其跨度涉及用户行为系统（心理学、社会行为学范畴）、金融基础设施系统（如支付清算体系）、监管政策系统（动态变化的合规边界）与商业价值系统（FTP定价、RWA占用、客户LTV等）。以一款高利率存款产品的发行为例，在系统工程视角下，除了存款部门的考虑外，还需要如下的考虑：从资产负债角度，会否在未来导致资产负债期限错配？从流动性角度，会否在产品到期后因赎回导致流动性风险？会否导致全行FTP定价失效？对全行利润的侵蚀度如何？是否会引致监管处罚？总而言之，传统的线性思维模式–要揽存就提高利率，已经越来越需要让位于系统性的思维，即将产品置于生态网络中做整体性思考。相对思维。相对性思维是摒弃掉非黑即白的二元对立思想，不轻易贴标签，不轻易下论断，看到事物之间的内在关系和动态变化，以此来指导产品设计。相对性思维在银行产品设计中的核心运用，是需要把握银行产品的”最优解”只存在于具体约束条件下，在约束条件下需求“整体收益、风险成本、监管合规”的有机统一。监管约束下的相对思维运用，反而会成为机构获得差异化竞争优势的突破口。比如，“宝”类产品在表面上会导致商业银行存款搬家，但如果能够获得货币基金的代付资格，则通过基金公司的托管，活期存款的“流失”则可以得到超额补充，产品竞争力带来的流动资金池（当日购买与赎回的差额），事实上对活期存款的损失可能会非常小，而商业银行则能获得资金托管带来的存款、客户粘性、费用收入等一揽子收益。
抽象思维。抽象思维通常与系统性思维相辅相成，是指在产品设计及实施过程中，需要提取不同事物性质相同的内核;通过功能与能力要素的抽象，支持产品的快速组装。这一思维，不仅是产品经理的契约，更应是IT架构师们的圣经，在分布式微服务架构中经常提及的共享服务抽象，以及前些年被推崇备至的“中台”，本质上都是在产品或者系统实现过程中，需要进行充分抽象，在不同产品、不同功能间寻求最大公约数，将公约数沉淀为稳定的，后续可复用的产品功能。比如在融资业务中，对押品管理、额度管理、核算账务的共性抽象和服务共享，可以实现对消费信贷、汽车金融、小微信贷、对公信贷的普遍支持，避免重复造轮子。
演进思维。演进思维是商业银行在面对不确定的宏观经济环境、快速进步的技术条件、不断变化的产业环境等情况下，结合用户认知和竞争对手情况，依靠快速试错、快速选代、用最小可行性验证产品假设的一种产品思维。这种思维模式下，要求产品经理对产品核心功能有高度的提炼能力，技术能力上能够支持AB测试与灰度流量验证等。以互联网贷款为例，在演进思维指导下，对风险控制指标的预测、验证、反馈、调整需要反复不断地进行，通过A/B测试，选择最优解。

局中人的破壁之道

银行产品创新的最大障碍，往往不是技术瓶颈或资源限制，而是对问题本身的错误锚定。爱因斯坦说，“我们不能用制造问题的同一思维水平来解决问题”。当我们能够新的思维模式重新审视产品，那些曾经的困境，就可能显露出隐藏的破局点。但“you can’t be what you can’t see”，思维模式的建立依赖于认知，而认知的建立需要大量的训练，对身处局中的我们（产品经理、架构师、开发工程师）而言，或者可以在如下方面进行努力：一是尽可能建立跨学科的知识体系。除自身岗位的专业技能外，通过在金融工程、法律法规（比如民法典、人民银行发布的各项法规）、用户体验（交互设计）、技术架构等方面，尽可能地进行积累，形成跨学科的知识体系。突破性创新通常来自跨学科的灵感启发，一专多能不但有利于跨越专业深井，还有可能为产品创新提供火花。二是基于“压力测试”的思维训练。在产品设计或需求分析过程中，通过“三问”不断强化思维练习。包括：本质之问–今天我们讨论的“账户分级”需求，用户想解决的原始问题是什么？系统之问–这个功能上线，关联到哪些系统，有更简单的设计方案吗？抽象之问–这个功能有现成的功能可以复用吗？新建功能能否沉淀为标准组件？三是对成功经验和失败教训进行复盘与解剖。“案例教学”是最直观、最有体感的认知体验。通过问题复盘过程中的五步法：问题定位–根因分析–思维盲区–制度改进–能力沉淀，建立制度化的事后学习机制，让成功的经验得到推广，失败的教训不再重演。

洞见需求

要做成一个项目，或一个产品，通常需要做3段式的准备，即：需求定义–“define what you want”，清楚地知道要解决的问题、痛点是什么； “know how” –有能力进行可行性评估、知道怎么做任务分解、以及有能力完成总体设计和子系统的设计；“enable”–执行、完成实施、达成目标。三项工作可以简单地分别对应为产品经理的工作、架构师的工作与程序员的工作（画外音：要让一家银行的产品/系统好用，服务体验如沐春风，你需要同时拥有优秀的产品经理、架构师、以及程序员）。其中，需求定义是任何复杂工程或产品项目的基石，它直接决定了项目/产品能否成功、做的工作是否具有价值、付出的成本是否值得，以及问题是否真的得到了解决。需求是所有产品设计的起点，“修炼对需求的认知，是所有产品设计者的终身课题”。

需求通识

《人人都是产品经理》一书中，将需求定义为“用户的问题”，产品经理的使命是“发现问题、定义问题”，通过产品“解决问题”，最后为用户“创造价值”。

如雷贯耳的马斯洛需求层次理论，是大家最耳熟能详的“需求”定义，马斯洛将人的需求分为5个层次：生理需求、安全需求、社交需求、尊重需求以及自我实现的需求。汉语中有于此对应的另一句话，“仓廪实而知礼节”。马斯洛定义的需求，是从心理学角度描述的需求。而在经济学意义上，《腾讯产品法》一书对需求做过非常简单精炼的概括：需求，是想要，且要的起的产品或服务。“想要”是需求的起点，“要得起”才构成真正的有效需求。对身处商业组织中的管理者、产品经理、架构师、程序员来说，更重要的是，是“借我一双慧眼”，能够在纷繁芜杂的用户诉求中，判断哪些是“显性需求”，哪些是“隐性需求”，哪些是“刚性需求”，哪些是“弹性需求”，总而言之，在商业机构中，需要产品经理能够“去伪存真”，通过表层用户直接表达的需求，挖掘用户行为背后的真实目标或痛点，最终回归人性的底层动机–本质需求。
那么，在一般性方法论的层面，可以这么做呢？通常涉及到4个步骤，分别是挖掘和识别需求，定义需求，方案设计，以及持续验证。

在需求挖掘和定义阶段，需要回归第一性原理，通过追问“为什么”，挖掘表象背后的真正问题，弄清楚用户真正想要的是什么。当拿到一份需求，通常可以做如下发问：用户为什么会有这样的需求？提出这样的改造，是基于什么样的前提条件？这些条件至今没有变化吗？有其他替代方法吗？随着技术、经济、文化潮流的发展，有引入新的变量吗？….《腾讯产品法》一书中，用微信群的案例举过一个经典的案例：我们知道，在微信群之前，腾讯其实是有QQ群的，QQ群需要由发起人在群功能中创建一个群，让后将群ID分享给需要入群的人，经过群主审核后，才能入群。如果是一般的产品经理，在设计微信群的时候，将不可避免地受到QQ群设计的影响，但是。运用第一性原理的追问：QQ群设计时的目的与微信群一样吗？不一样，QQ群更像是满足某种特定功能或提供特定服务而存在的，微信群则与大家聚在一块聊天没区别；QQ群设计时的情景与微信一样吗？不一样，QQ是“虚拟社交”，微信则是“实名社交”；使用环境变了吗？当然，QQ群时代以PC为主，微信时代则是手机入口为主。于是，情况一目了然，微信群是为了满足熟人社群互动而存在的，他的特点与线下社交一样，需要支持可以随时随地，几个人聚在一块就可以聊天，也不需要有所谓的群ID，于是，微信群的形态就是我们今天见到的这样。

商业银行的“需求”

商业银行的需求，在具备需求的一般通识性特征外，回到第一性原理视角，还带有大量的行业特征。本文试仅就银行零售与对公业务作少许讨论：

零售银行。零售银行中的产品需求，追根溯源后，金融需求是第二位的，其第一推动来自人的需求，即“生、老、病、养”，“衣、食、住、行”，与社交、娱乐等的需求，由这些需求衍生出个人客户需要的资产增值需求、资产保障需求、交易需求、消费信贷需求、信用卡需求、汽车金融需求、住房信贷需求，最后以存款、汇兑、基金、保险、理财、消费贷、汽车贷、信用卡、房贷等产品的形态体现。

这些需求的特点，对商业银行的产品设计和业务拓展而言，最终被归纳为业内常见的一个词–“场景金融”。在零售业务中，需要追求让金融服务无感地嵌入到场景之中。而场景资源通常是宝贵的，在互联网时代，优质的场景入口，几乎都被互联网巨头或垂类的公司所占据，而场景拓展的难度，常被商业银行简化为“开放银行”的建设，甚至是进一步简化为“openAPI”建设。“开放银行”从第一性原理视角，是毫无疑问的本末倒置，是银行中心论在今时今日仍不能放下身段的表现。openAPI在产品设计上，从银行的视角，试图通过封装银行内部的金融服务接口，提供标准化的对外服务暴露来支持任意第三方按需适配。问题在于，是银行需要场景，而不是场景需要某家发布了openAPI的银行，所谓的ApiBanK，在逻辑上并不成立。不信的话，去看看微信、支付宝的绑卡，是按银行的标准来，还是按两个巨头的标准来，联合贷的话语权是在银行还是发起方。因此，在零售银行领域，面向个人客户的场景拓展，以及开发适配具体场景的产品，比搞开放银行重要。而在技术准备上，不要去试图制定标准，而应该通过适配层的抽象，通过sdk / h5等，考虑如何敏捷、快速、低成本地接入场景。

企业金融。与零售金融的需求围绕个人的需求展开不同，企业金融业务的第一驱动来自于企业经营过程中的金融服务需求，它包括企业的“生产制造”、“贸易结算”，以及企业运营过程中的企业并购、补充资本、税费缴交、招投标、采购、销售、发薪、福利报销等等。企业金融服务的需求，根据企业类型、企业规模的不同，体现出明显的产业、行业甚至个性化特点。

也因此，企业金融业务中的需求提炼、挖掘，其实更考验产品经理的能力。以广义的贷款业务为例，假设某个企业提出需要一笔“流动资金贷款”，对客户经理而言，站在客户角度，则需要了解，这笔“流动资金贷款”的用途是什么，如果是用于向上游付款，该产业链上可以接受商票吗？如果可以接受商票，是否可以改为签发银行承兑汇票？对应地，融资品种一换，企业就可以将需要付息的贷款，转变为无需付息的银承，减少有息负债，对优化企业的资产负债表，显然更有价值。又比如，在为客户办理信用证开证时，要求缴纳的保证金，银行是否有能力分户核算到企业自己的账户上，而不是都缴纳到内部户中，不同的缴交方式，虽然对银行都是一样的存款，但对企业而言，保证金存款将仍然体现在企业的流动性中，这显然对企业资产负债表、现金流量表都更有价值。
不同于零售业务，在企业金融业务中，光融资工具就有贷款（可进一步根据具体的场景细分为一般性贷款、贴现、预支价金、押汇）、票（商票、银票）、信用证、保函，以及由此衍生的各种担保承诺类产品。在支付工具中，在普通账户之外，则有票据、信用证；在公私联动中，有代发、代扣的专门解决方案；在存贷联动解决方案中，有法人账户透支等等…也因此，企业金融业务尤其需要回归企业的需求本心，真正深入企业，针对性地提供金融解决方案（内容太多，未来专题讨论）。

需求分析的若干案例

商业银行中，除了上述面向客户的产品化需求外，还有一类面向内部作业的需求，这一类需求提出时，通常从提出者的视角出发，基于其岗位痛点提出需求，是最需要回归第一性原理，进行全局性考虑的一类需求。看几个具体案例：

CASE1：保证金开户同屏授权改异步。

需求背景：在银行承兑汇票业务中，保证金开票时需要开立保证金账户，保证金账户的开立需要同屏授权，由于业务量大，主管需要频繁离开座位，进行同屏授权。因此提出需求：请将保证金授权由同屏授权改为异步授权。根因分析：银承汇票业务保证金开户过程中，因为保证金账户业务业务合同一一对应的关系，当银承合同多的情况下，需要频繁开立保证金分账户，每次分账户开立，不只是需要授权，还需要填写申请表，并经支行行长签字，开立时不仅是需要主管授权，操作人员还需要录入一系列开户信息，并验证支行行长签字。所以，这个需求的根本痛点其实是，在银票业务中“开立保证金账户的操作十分复杂，影响作业效率，最终影响银票的签发效率”。方案设计：完成根因分析后，我们继续追问，保证金账户的开立只是银行承兑汇票签发的其中一个环节，在开户申请前，还做了什么？了解后发现，在开户前，客户经理已经录入了银承业务合同、为客户开立了结算账号，保证金开户的所有要素都已经具备了，银承业务合同在业务审批过程中，本身就需要支行行长及放款中心线上审批。这也即意味着，保证金开户的要素已经全部具备，保证金开户可以随业务合同一起审批。于是，这个需求被调整为“银行承兑汇票签发的流程优化”，将保证金开户、应解汇款户开户，与银承业务合同的审批进行了自动关联。改造完成后，不仅仅是保证金开户不需要同屏授权，是保证金开户的所有操作直接变成了线上化，客户经理不需要再去柜面，运营同事也不需要再操作开户，对应的签字、验签，线下资料存档等所有内容，也都被撤销，银票签发效率大幅提升。

CASE2：帮我做个RPA，支持开户信息录入。
需求背景：某银行开户，采取线上预约机制，客户预约填写的开户信息及开户资料，在完成审核后，需要通过手工重新录入到交易系统，十分繁琐。
根因分析：这看起来是个开发RPA的需求，但RPA是否能够彻底解决问题，是值得怀疑的。问题的根本在于，预约开户信息及资料，为什么不能直接传递给客户信息系统与账户系统，需要反复多步操作的客户信息录入与账户开立，综合签约等，可以通过服务调度，完成自动化处理吗？
方案设计：答案显然是可以的。于是，需求转变为“实现预约开户的全流程线上化”。负责实现的系统，从RPA，改为预约开户系统，通过打通预约开户系统与后台交易系统，实现信息传递的线上化，并通过预约开户系统实现服务接口的编排，将开户变成客户申请、运营检查、自动开立的自动解决方案，大幅提高了开户效率。

复杂系统

简约崇拜天文学家开普勒说，“大自然喜欢简约和统一”，哈代也宣称，“美是首要的试金石，丑陋的数学不可能永存”。数学和物理学中那些充满美感，而又蕴含宇宙普遍真理的方程–如爱因斯坦质能方程、麦克斯韦方程组、欧拉恒等式等等，常常被用来证明–简单的才是美的。（下图为欧拉恒等式，它将数学里最重要的几个数字联系到了一起：两个超越数：自然对数的底e，圆周率π；两个单位：虚数单位i和自然数的单位1；以及被称为人类伟大发现之一的0。在数学分析领域，以及复变函数论中都占有非常重要的地位，被称为“上帝创造的公式”）

“奥卡姆剃刀原理”同样强调“若无必要，勿增实体”，主张剔除冗余，直击事物本质，避免引入不必要的复杂性。在产品设计哲学中，“简约”也经常被作为衡量产品设计成功与否的标准之一，尤其在消费者业务（to C）中，以苹果、腾讯等为代表的产品设计，充满了简约的美感。有如此多的珠玉在前，于是在产品设计中，“简约”常常被作为“产品经理”的追求之一，只是这种“简约”经常被有意或无意的曲解：其一，数学与物理学中的简约，是对本质和原理的解释，其推导、论证过程充满了复杂性，混沌系统的复杂性研究，甚至发展出了一门专门的学科–混沌工程；其二，产品中的简约是对用户而言的，要达到对客户简约呈现的目的，产品设计者需要有效管理和整合后台的复杂；其三，并不所有的产品都可以做到“简约”，比如下图这个：

管理复杂

事实上，工程领域，以及我们生活中的大部分场景，复杂才是常态，无论是操作一台汽车，还是理解一款金融产品，或是管理一个大型项目。唐纳德·诺曼曾一针见血地指出：问题不在于复杂本身——复杂是客观存在的常态——而在于我们如何理解、沟通和驾驭这种复杂。对产品设计而言，复杂并不是问题，令用户困惑，甚至导致用户不会使用，才是问题。关于复杂的一个例子，是男士们的书桌或房间，在一堆乱七八糟中，主人总是可以很容易地找到需要的物品，但经过太太的精心收拾后，很多东西通常神秘地不知所踪。

糟糕的设计，无论是物理产品、数字界面、流程还是组织架构，会将本源的复杂放大成令人望而生畏的困惑，而优秀的设计则能化繁为简，让复杂变得驯服、透明，甚至富有力量感。管理复杂，并非追求绝对的简单，那往往不切实际，而是追求“可理解的复杂”和“可管理的复杂”。诺曼为我们提供了几个至关重要的手段：

建立有效的心智模型。 这是管理复杂性的基石。用户需要一个关于系统如何运作的“模型”。这个模型需要能预测操作的结果。优秀的设计通过界面、反馈、文档甚至隐喻主动提供并强化这种模型。这个最佳的例子是最近华为推出的尊界S800，通过手势可以开关车门，控制车窗的亮度，将操作与大脑的自然反应进行了映射，当然前提是有黑科技支撑。

合理的分层。分层简直是解决复杂问题的不二法门，面对庞大的复杂性，人类认知的天然策略就是分解。比如，以JAVA编程为例，可以分层为：JAVA源码、.class字节码、JVM、操作系统、计算硬件资源；银行应用架构中，我们将系统分层为渠道层、产品层、风控层、账务层及数据层；管理大型项目时，WBS也是典型的层级化应用，将大目标拆解为可执行的小任务。模块化降低了认知负担，使聚焦和掌控成为可能。

设计及时且明确的反馈。在复杂系统中操作，用户需要清晰地知道“发生了什么”以及“我做得对不对”。反馈是建立和修正心智模型的关键。 优秀的反馈是即时的–操作后马上有反应，在银行应用系统的异步响应模式中，通常以“请求已受理作为即时ack的反应”、明确的–清晰地指示状态变化或结果，银行系统如果报错，得给出明确的报错提示、匹配的–反馈的形式和强度与操作本身相称。下载文件时的进度条、提交表单后的成功提示或错误信息框，都是反馈的体现。缺乏反馈（点击后没反应）或反馈模糊（提示不清晰）会极大增加不确定性。让用户感到失控，是导致问题的常见源头。

利用约束引导行为。复杂系统中存在无数可能的操作路径，但并非所有路径都是正确或安全的。优秀的设计通过物理约束，比如特定形状的插头只能插入对应的插座；逻辑约束，如必须先填写A才能填写B，常见于客户填写表单信息时进行关联检查；文化约束–比如通用的红色代表停止/危险，以及语义约束（如旋钮的箭头方向指示旋转效果）来限制可能的操作选项，引导用户走向正确的行为。这些约束像无形的轨道，防止用户误入歧途，减少错误和认知负担。例如，转账提交后，一定时间内将按钮置为“灰色不可点击”，就是运用逻辑约束和文化约束建立心智模型的典型案例，常用于避免重复转账。

善用默认值与预设。面对大量可选项时，用户容易陷入“选择悖论”的焦虑。优秀的设计提供经过深思熟虑的、适合大多数场景的默认值或预设方案。这并非剥夺用户的选择权，而是提供一个安全的、合理的起点。用户可以在此基础上轻松地进行个性化调整，而不是一切从零开始。例如，软件的“推荐安装选项”、银行系统各种产品、核算、费用参数的初始化，都大大简化了初始操作，降低了入门门槛。

标准化与一致性。当不同的系统、不同的界面、不同的流程遵循相似的规则和模式时，学习成本会大大降低。一致性是易用性的核心原则之一。相同的图标代表相同的功能，相似的操作产生相似的结果，术语的使用保持统一。这使得用户可以将在一个系统中习得的经验（心智模型）迁移到另一个系统，形成规模效应，有效管理跨领域的复杂性。想象一下，如果每个网站的“保存”按钮图标和位置都不同，那将是多么混乱。

容错设计。 在复杂环境中，犯错是常态。优秀的设计能预见到可能的错误，并使其可逆或易于纠正。典型的如“撤销”功能、“幂等”设计银行应用系统是容错设计的典范。清晰的错误提示、提供简便的修正方式、以及防止灾难性后果（如删除前的二次确认），都能极大降低用户面对复杂操作时的恐惧和挫败感，鼓励探索和学习。

商行产品缘何复杂

以上是产品设计的一般通识，是需要在产品或方案设计中遵守的常识性守则。而对商业银行而言，因为行业的特殊性，使其产品或方案设计，更加不可避免地具备复杂系统的特点。这些特点体现在：

需求的多元性。不同于一般行业直接面向客户需求，以解决客户痛点为核心诉求的产品设计原则，商业银行的产品设计，需要根据产品特性，同时考虑“客户、合规内控、监管”三方面的需求。其中，客户需求自然是毫无疑问的，满足个人客户在日常生活、工作、学习中面临的支付结算、保值、资产增值需求，满足企业客户在生产经营、贸易结算中的金融需求等等；但在满足这些需求的过程中，因为银行业的特殊性–经营和管理风险，对应标的是“资金”，因此，对应的内控合规、营运安全求，同样非常重要，比如流动性安全、不良率的控制、审贷分离原则等等，均需要在产品需求中得到充分考虑；在内控合规之外，商业银行还面临不同于其他行业的强力监管要求，包括巴塞尔协议中对rwa、ifrs9等相关的刚性约束，以及不同国家、地区监管机构要求的诸如窗口指导、贷存比、mpa考核、信贷行业投向、占比等要求。举个例子，以设计小微企业贷款产品为例，需要统筹考虑3个方面的需求：

• 客户需求包括：目前客群画像、申贷方式（H5、APP、小程序…）、核身方式（五要素核身、活体检测….）、风控批核模型申请评分卡设计（不同指标的权重测算）、选择何种的还本付息方式、客户申请到放款的周期和流程设计、还款方式（是否支持快捷代扣等等）；
• 内控合规需求：贷款合同的条款设计是否合规、事前反欺诈方式、行为评分卡的评分模型设计、贷后预警信号的设计，放款是否需要人工审查等内部流程设计；
• 监管需求：信用贷款的报送口径，企业规模、类型的认定要素，是否符合产业政策等等，相关贷款产品的rwa、ftp、i9的影响以及对应的数据下送等等。

内部流程设计将直接影响客户体验。与一般的物理商品不同，商业银行的产品实际是一揽子服务的集合，在物理产品的世界中，如果一款产品品质极其过硬，后续客户与商家/厂家发生联系的概率不大，但银行产品与此不同，包括开户、大额汇款、贷款申请等在内的服务，都会涉及到流程设计，部分需要与银行的营业网点、反洗钱部门、集中作业部门发生联系，此时，流程设计中，哪些可以由计算机自动化，哪些需要人工进行审核，就不仅仅是银行内部降本增效的问题，而是会直接影响到客户的使用体验，比如一笔开户申请，A银行依靠技术手段，可以实现秒开，而B银行手工操作，需要个几天，客户会选择谁将显而易见；同样的例子是贷款（包括开票、开证）申请，如果一家银行依靠技术手段，可以做到秒批、秒贷（在有效实现风险控制的前提下），其带来的产品竞争力讲师不言而喻的。因此，从客户与银行建立联系开始，针对客户旅程的全生命周期进行有效的流程设计，将是产品设计面临的必然命题，而这通常涉及多个节点的跨系统交互。

差异化竞争优势获取需要跨域联动的设计。高维打低维的降维打击模式从来都是产品创新的灵感来源，微信红包的社交打金融，余额宝通过将货币基金的投资功能叠加支付功能的产品升维，都取得了巨大的成功。这种现象级的产品当然可遇不可求，但是商业银行中存在大量的存贷联动、公私联动的产品却是不争的事实，比如代发薪、担保承诺类业务中，授信业务与保证金存款的联动，法人账户透支产品中负债产品与融资产品的联动等等，这通常会涉及到跨业务形态、跨业务领域的复杂设计。

银行业系统架构分层的必然结果。在商业银行长期的组织架构和IT系统应用架构的演进过程中，逐步形成的“前、中、后”台模式，天然地需要进行跨部门、跨系统的协作以有效支持一款产品的有效实现。商业银行常见应用架构的分层分布，如下图：

从这一分层架构看，负债产品的产品实现，将不可避免地需要统筹考虑渠道层、公共服务层、账务作业层、数据层的功能需求；而融资产品，则在负债业务的基础上，还需要考虑风险控制层的功能实现；跨域联动类产品，则在以上两者之外，还需要考虑产品层的跨域联动，如果涉及支付业务，还需要考虑与外部的适配等等。

应对之道

商业银行的行业特点决定了银行产品不可避免地需要管理复杂，而在可操作性层面上，有什么可行的办法来管理这种复杂性呢，分为组织层面与个人层面。

组织层面。首先仍然是人才先行，针对性地建立一支优秀的跨领域复合型人才队伍（产品经理、体验设计师、流程设计师、业务架构师、开发经理等等），通过轮岗、深度参与大型项目等方式，培养队伍成员一专多能的专业素质；其次是有条件的情况下，建立有渠道、产品、风险、财务、运营、IT、合规人员组成的产品委员会，对新建设产品，充分听取各不同专业委员的意见和建议，对产品差异化竞争优势、预期回报、合规可行性等进行充分讨论和论证，产品建设做到谋定而后动；再次是有效的需求流程设计，比如最简单的，一份需求在签批环节，比如按流程经过风险、合规、相关配合的业务单位、营运、财务等的审阅，并充分发表意见，才可以进入到产品实施环节；最后，需要有充分的需求评审，将需求对应的业务背景、增长预测、功能说明、关联需求等，向相关方进行完整的阐述并取得支持，需求评审时可以要求需求以模版方式呈现，如下图所示需要覆盖的内容：

个人层面。无论是产品经理、业务架构师还是开发负责人（一般也是技术方案设计者），首先是需要具备一些关于产品设计的通识性知识，比如知道基本的关于反馈、约束控制、有效心智模型设计的知识，了解基本的交互设计基础知识；其次是需要养成系统性思维能力，多以全局视角审视和思考问题，强迫自己尽可能“知其然，且知其所以然”；再次是不断学习，在深化本专业知识的基础上，尽可能拓展“多能”的跨领域业务能力，在知识的深度和广度上，都有所精进（毕竟艺多不压身）；最后是要多实践，尽量多地主动请缨，参加一些大型项目或产品研发，如果条件允许，可以考虑在一个领域待够3~5年后，寻求感兴趣的领域转岗锻炼，“纸上得来终觉浅、绝知此事要躬行”，理论无论写的多好，都不如动手来得更有体感。

显性与隐性特征设计

每一个让用户感觉“简单好用”的产品或功能背后，都是产品设计者对产品显性特征和隐性特征的统筹考虑，并通过一体两面的兼顾实现和谐统一的最终结果。

产品经理的双面视角

如何做好用户体验设计

怎么抽象复杂系统交互

持续敏捷

演进思维要求在面向不确定的市场与激励的竞争时，需要快速低成本试错、快速迭代，即用最小的可行性产品验证假设，总之，需要进行敏捷。这一源自互联网行业的方法论，在印象中应该偏稳健、保守的商业银行，也被越来越多地推广及运用。

为什么需要敏捷

商业银行的产品敏捷，最直接的原因大概是“卷”，这大概是中国大陆，或者是带互联网基因的商业银行–比如Shoppee Bank，特有的现象。“卷”是竞争，有竞争才会有进步，物竞天择，面对市场的波动性、不确定性、复杂性和模糊性（VUCA），那些能够比竞争对手更快学习、决策和行动的机构，将获得显著的竞争优势。除了竞争之外，商业银行的一些经营特点，也是对敏捷能力的现实要求：

因应监管政策变化的要求。金融行业的强监管特性、央行的货币政策变化，都要求商业银行的业务开展需要迅速适应政策变化的要求。如2013年至2016年期间狂飙突进的影子银行业务中的“产业基金”模式、“票据资管”、“黄金租赁”业务等等，都是只在一定时期内被允许的业务，在一定时期内为开展这类业务的商业银行创造了客观的利润。其他的，诸如央行LPR利率的推出、针对小微的再贷款专项计划、再贴现利率调整对票据市场的调节、国家金融管理局对消金公司杠杆率、同业拆入规模、担保增信的限制及由此影响商业银行联合贷、助贷业务的发展，都需要商业银行进行快速的反应，在资源投放、政策修订、产品调整、系统开发等方面，快速作出反应。

市场时机的的快速把握。包括以下几类，1）、面向特定热点事件、或者特殊时间窗口的产品设计。比较有代表性的，如AlipayHK为香港地区年底缴税专门推出的缴费易产品（包括营销补贴）、银行当港股行情好时为投资者开发的IPO融资产品及专项孖展授信产品、因应黄金行情而开发的积存金产品等等；2）、以快制胜的市场竞争需要。以对公业务领域为例，高价值头部对公客户通常会成为多家商业银行的潜在竞争客户，此时，而他们需要的产品通常都需要定制化，谁能以最快的速度满足从一线客户经理传递上来的客户需求，谁就可能获得先发优势，获得更多的业务机会。

经营特点的客观需要。商业银行生息资产投放的特点及KPI的考核需要，尤其是在信贷投放领域，新产品的建设往往需要在年底前完成，并在来年通过开门红，甚至在上一年年底就产生足够的规模，然后在未来一年中的尽可能长的时间内，带来经营收益。这种情况在贷款产品领域经常发生，常常需要贷款产品的产研团队能够对业务作出敏捷响应。其他因诸如适应季末、月末存款规模等考核要求而进行的产品开发，也在此列。
当然，最终还有一点更现实的，就是强KPI考核下的压力传导。大致有如下几种情形：第一自然是自上而下的压力传导。来自于行长、分管副行长、各业务部门总经理依据全行经营战略，分解落地而需要研发产品，在相当一部分机构中，管理者似乎缺乏耐心，大多按“一万年太久、只争朝夕”进行要求，一旦提出，就希望尽快看到成品；二是产品团队本身，在对产品团队强考核的商业银行，产品团队需要要么通过质量（产品完成的营收、利润数字）、要么通过数量（没有功劳，总要抢个苦劳），作为KPI的关键支撑，由此带来的所谓“敏捷响应”需要；三是业务一线，分支行、客户经理发现的市场机会（或误以为的市场机会），其中一部分除了需要关系营销外，还需要银行中后台以最快的速度为前线提供好的产品、解决方案以满足前线的需要。
总而言之，”持续敏捷”能力建设，对银行产研团队而言，早就不是一个选择题，而是银行产研团队生存与发展的必修课。

敏捷的误区

然而，在实际工作过程中，“敏捷”却常常被玩坏了：将违反科学规律、极致压缩研发周期的蛮干当成敏捷；将缺乏规划的功能堆砌，以战术勤奋替代战略懒惰当成敏捷；将scrum的引入，完成各种敏捷工具的部署，实则不计效果的形式主义当成敏捷；将频繁的变更、碎片化的优化当成敏捷，勤奋地对客户进行打扰。几种在工作过程中常见的敏捷误区包括：

多加资源就能缩短产品研发周期。这一点常见于很多银行业机构，当一个产品、项目研发需要8个人，3个月的周期时，业务方、管理者经常会产生的一种迷思是，加到20个人，能不能将研发周期缩短到2个月？这就好比一个妈妈要怀胎10月，才能生出1个孩子，现在给你两个妈妈，能不能帮忙将生孩子的周期压缩到6个月？这一误区不仅见于银行产品、项目研发，也常见于银行战略中的所谓加大对“金融科技战略”的支持–让科技部门多招人。事实上，团队也好、项目也罢，人都不是越多越好（当然更不能人手不足），维持一个“小而精”的团队，是研发团队或者项目组织的最佳策略。《人月神话》一书中，弗雷德里克・布鲁克斯提出，向进度落后的项目中增加人手，往往会使进度更加落后。这是因为软件开发是一种复杂的创造性工作，随着团队规模的扩大，沟通和协调的复杂性会呈指数增长。团队成员之间的沟通渠道数量可以用公式n(n−1)/2来计算，其中n为团队成员数量。例如，当团队有5名成员时，沟通渠道有5×(5−1)÷2=10条；当团队扩大到10名成员时，沟通渠道则增加到10×(10−1)÷2=45条。如下图示意，曲线处于最低点时的人员规模，才是最佳规模，跨过最低点后，随着人手的增加，效率反而下降：

碎片化需求而非价值交付。敏捷多数时候离不开迭代，迭代最终表现为做了多少次发布，这最终导致很多产研团队有意或无意地误入歧途：将需求拆得稀碎，发布的内容能不能给客户带来闭环的价值不重要，重要的是完成了多少次需求发布。这种本末倒置的做法，本质上是一种”交付的幻觉”——团队沉浸在频繁交付的成就感中，却忽略了每一次交付是否真正解决了用户的问题或带来了业务价值。其典型的症状包括：1）、功能肢解。一个完整的用户旅程被拆分成多个互不关联的迭代，用户需要等待数月才能体验到一个完整可用的功能；2）、指标异化。团队关注的不再是“是否提升了客户满意度”或“是否增加了业务转化”，而是“本期完成了多少个用户故事点（需求点）”；3）、伪敏捷。保持着两周一次的发布节奏，但发布的内容多是 Bug 修复、体验调优或边缘功能，核心痛点始终得不到解决。

形式主义敏捷。形式主义敏捷是许多组织在推行敏捷过程中最容易陷入的误区，通常是在“领导的亲切关怀下”，引入所谓的“敏捷教练”，然后将Scrum的几件套–站会、看板、待办事项清单一一执行到位。笔者的亲身经历，本来运转良好的产研团队，在敏捷教练的一通指导下，搞得怨声载道，开发效率急剧下降。其问题表现包括：1）、晨会是形式主义的重灾区。一群人神经病式的围成一圈本身就挺有喜感的，每个成员再按顺序讲一圈“昨天做了什么、今天要做什么、遇到什么问题…”，这简直是荒谬。第一，这么公开的场合，能听到多少真话？第二，产品负责人或者研发负责人，如果连团队成员的工作进度、项目风险都不掌握，还要通过晨会了解的话，那就要赶紧换人了。如果领导者只是想通过晨会搞服从性测试，那请继续，如果是为了敏捷，赶紧取消才是正道；2）、看板成为额外的负担。除了给领导表演外，谁会真的通过看板去了解项目进度。真实的项目进度只在钉钉、企微的聊天记录中，只在实实在在的文档和代码中，只在团队日积月累的相互信任中。所谓看板，不但增加成员的双重填写压力（他们还得在项目管理工具中再填写一遍），还常常弄成表演者的舞台–代码一般是没有领导看的，看板可不一样，做的花样百出指不定哪天就被表扬了。凡此种种，不一而足…敏捷的本质是适应性和快速响应变化，而不是对特定流程的宗教式恪守。当团队忙于完美执行敏捷仪式而忘记了为什么要这样做时，敏捷就已经失败了。

勤奋的懒惰。在腾讯的产品哲学中，有一条非常令人印象深刻，即“避免勤奋地打扰客户”。我们看到，腾讯系的产品很少会发生那种交互习惯被改的面目全非的情况，这后面一定包含着对产品迭代的严谨论证和产品功能上新、体验改变的充分论证。但与此相对，银行业机构似乎并不如此，笔者自己用过的手机银行app，都经常出现过段时间就改头换面一次的骚操作，一个手机银行app，居然一路从1.0，发布到1x.0…事实上，在产品进入成熟期后，更多的精力应用用在功能细节、交互体验的反复雕琢，对特别成熟、用户早就已经习惯的产品而言，什么都不做，也比瞎折腾要好。在”敏捷”的旗帜下，产品很容易陷入功能主义的误区，堆砌功能（甚至是堆砌产品）本质上是用“战术的勤奋掩盖战略的懒惰”，不仅浪费大量宝贵的开发资源，还会让产品变得臃肿不堪，给用户带来困扰。

实现持续敏捷

事实上，真正的敏捷必须是以价值交付和用户体验优化为中心的。每一次迭代都应回答一个问题：”这次发布为客户或业务带来了什么新价值？”如果答案不明确，那么这次迭代可能就是不必要的。
实现持续敏捷，不能仅仅停留在引入Scrum仪式或部署管理工具上。这些形式若没有内在能力的支撑，终将流于表面。真正的敏捷源于以下核心要素：

建立良性的敏捷评价机制，始终坚持价值驱动下的敏捷。1）、迭代评审机制。每次迭代，都需要向管理者及敏捷小组成员说明这个迭代“可验证的用户价值”是什么，而不仅仅是以提出需求，完成开发任务为目标。哪怕这个价值很小，它也应该是一个完整的、可用的功能切片。2）、建立清晰的价值评估框架。在迭代开始前，要明确“如何验证这个功能成功？”–是通过用户反馈、业务指标还是A/B测试？3）、敢于说不。对那些不能带来明显用户价值或业务价值的需求（如一味的领导偏好、盲目的竞品跟随），产品经理、研发经理要勇于拒绝，保持团队的专注力。4）、用成果而非产出衡量敏捷的成功：团队追求的不应是发布了多少功能，而是通过这些发布获取了多少用户增长、提升了多少客户满意度或降低了多少运营成本。

充分的组织准备，跨职能团队与授权机制建设。传统银行科层制组织结构是敏捷的最大障碍。组建跨职能的特性团队(feature team），将产品经理、体验设计师、运营经理、开发工程师、测试工程师（在融资业务中，通常还会加入风险人员）等凝聚成一个目标明确、被充分授权的小型作战单元，是进行能力闭环，形成团队默契，通向敏捷的重要保证。互联网企业中，除了按矩阵模式进行临时的团队编组外，还常常将一个个跑出来的产品线固化下来，形成有福同享、有难同当的利益共同体。这种”产品+研发+运营”的铁三角团队，在被赋予明确的业务目标和对实现路径的决策权后，需求决策周期、需求澄清周期、研发周期、发布周期都将得到大幅压缩。

服务抽象与架构支撑。后端架构的灵活性是前端业务敏捷的基石。以信贷业务为例，通过共享服务抽象，可以将指标模型、决策引擎、账务记账、额度计算、押品管理、客户评级，分别抽象成独立的共享服务，在零售信贷、小微融资及一般企业级授信业务中，共享这些能力，支持信贷类产品在推陈出新时，只需要改变准入模型、变化还款周期或还款方式、变更担保模式等等，极大压缩产品研发周期，实现有效敏捷。

需求分析与分解。Scrum从来都不是敏捷的核心，需求的分析与拆解，按冰糖葫芦式组织一个一个交付闭环的功能点，才是敏捷的核心与关键。它要求产品经理能够精准捕捉用户和业务痛点，确保解决真正有价值的问题按MVP（最小可行产品）思维，优先被交付；它还要求产品和交付团队，能够将大型需求拆解为独立的、可交付的小用户故事。以下是腾讯8分钟产品课中分享的产品迭代原则，以支付业务为例：

他将产品需求分为“安全可用”、“使用体验”、“扩展兼容”、“生态体系”四级，与马斯洛需求层次理论类似，因为支付涉及到资金安全，支付资金的安全、避免陷入反洗钱的麻烦，就成为支付产品的最基础需求，这个都做不好的话，遑论其他；之后是使用体验，而使用体验的核心便是支付成功率，Lucy（彭蕾）在带支付宝团队的时候，其重要贡献之一，就是大幅提升了支付宝的支付成功率；再之后是能力的扩展，对多类型支付工具的兼容；最后是构建庞大的生态，形成产品的深度护城河，在支付业务中，这包括线上、线下收单场景、商户的推广，用户使用习惯的培养等等。

Devops体系的构建。如果说服务抽象为敏捷提供了可复用的能力积木，那么DevOps体系则是确保这些积木能够被快速、可靠、高质量组装和交付的流水线。如果一次需求上线需要经历冗长的部署文档编写、人工申请、多环境手动部署与测试，那么敏捷必然就会以IT人员的加班、人肉运维为代价。Devops体系的构建需要在至少3个方面完成能力建设：1）、自动化工具链贯穿全过程。从开发人员提交代码开始，通过版本控制工具(如Git）、持续集成（CI）工具自动触发编译、单元测试与代码质量扫描；通过持续交付（CD）工具自动完成测试环境、预生产环境乃至生产环境的自动化部署与回归测试；最终通过自动化监控工具持续观察应用性能。这条工具链将人工从重复、易错的流程中解放出来，使数小时内完成一次高质量发布成为可能。2）、实现基础设施即代码。通过代码来定义和管理基础设施，使得服务器、数据库、负载均衡器等资源的申请、配置与销毁均可通过自动化脚本完成，实现基础环境的版本化、可追溯和快速重建，为业务的快速弹性扩缩容奠定基石；3）、构建完备的可观测性体系。构建包括日志、指标核对与链路追踪的全方位可观测能力。实现从敏捷开发态下，生产运维由“被动救火”到“主动预警”乃至“故障自愈”的演进。

结语

在组织架构设计、文化特点、支撑体系迥异于互联网的传统商业银行，持续敏捷对身处前线的产品经理和开发人员而言，多数时候是一种无奈的奉命行事。但在局部的微观生态中，它仍然应该是产品经理、开发经理、运维经理应该努力追求的目标。因为要达成真正的持续敏捷，它要求我们能够练就一双慧眼，能够洞悉用户真正的问题和关键痛点，对最小可验证需求进行提炼；它还要求我们不断掌握更多的业务知识，在专业能力的牵引下，去规划产品的迭代方向；它还要求我们去理解和驾驭复杂，养成“系统化”、“结构化”思考问题的习惯；它更不断启迪我们不断去思考如何构建能够快速响应的团队、架构与文化。而所有这些方面的历练，终将会千磨百炼出一个更好的自己。

作者：高尔斯基

以下结合该工厂开发“市民不动产登记系统”（简称“登记系统”）的全流程，对照CSF 2.0 三大核心架构元素（Core、Profiles、Tiers）说明其作用。

一、CSF 2.0 Core（核心功能）：政务工厂的“安全操作指南”

CSF 2.0 Core 定义6大顶层功能（Govern、Identify、Protect、Detect、Respond、Recover），每个功能对应政务工厂的具体运作场景，确保“登记系统”开发全流程安全可控。

1. Govern（治理）：统筹安全战略与供应链风险

• • 运作场景：项目启动前，政务工厂成立“供应链安全委员会”，对照CSF 2.0“治理”功能下的“供应链网络安全风险管理（C-SCRM）”要求，开展两项核心工作：
  1. 1. 供应商准入审核：审核第三方服务商“政务汉东”（提供身份认证接口）的安全资质——要求其提供ISO 27001认证、近1年漏洞响应时效报告（需≤24小时），并通过NIST SP 800-161标准评估其供应链韧性；
  2. 2. 安全政策落地：制定《政务软件工厂供应链安全管理规范》，明确“登记系统”需使用的开源组件需从工厂“白名单库”选取（如Spring Boot 2.7.10，已提前通过安全扫描），禁止引入EOL（停止维护）版本。
• • 作用：将安全风险纳入工厂顶层决策，避免因第三方供应商漏洞或不合规组件导致项目返工（如曾因某供应商未及时修复SQL注入漏洞，导致旧项目延期15天）。

2. Identify（识别）：摸清资产与风险底数

• • 运作场景：“登记系统”需求分析阶段，政务工厂通过以下动作落实“识别”功能：
  1. 1. 资产台账建立：在工厂“智能资产平台”登记项目全量资产——包括开发工具（GitLab、Jenkins）、开源组件（Vue.js 3.3.4、MyBatis 3.5.13）、客户数据（市民身份证号、不动产信息）、第三方接口（“政务汉东”认证接口、“天地图”地理信息接口）；
  2. 2. 风险评估：使用工厂“风险评估工具”关联NVD漏洞库，发现Vue.js 3.3.4存在“跨站脚本（XSS）”中危漏洞（CVE-2024-XXXX），同时评估“政务汉东”接口中断风险（历史中断2次/年，单次恢复4小时），将两项风险均标记为“需优先处理”。
• • 作用：避免“看不见的风险”（如未登记的开源组件漏洞），为后续防护措施提供靶向依据。

3. Protect（保护）：构建全链路安全护栏

• • 运作场景：“登记系统”开发阶段，政务工厂按“保护”功能要求，嵌入三层防护措施：
  1. 1. 访问控制：代码仓库（GitLab）启用MFA（多因素认证），仅“登记系统”开发组（5人）有权限提交代码，且需通过“工厂统一身份认证平台”（对接政务网账号）登录；
  2. 2. 数据保护：市民不动产信息存储在工厂“加密数据库”（采用AES-256加密），传输至前端时通过HTTPS加密，且仅保留“必要字段”（如隐藏身份证号中间6位）；
  3. 3. 员工防护：组织开发组参加“政务数据安全培训”，包含钓鱼邮件演练（模拟“政务汉东”发送的虚假接口更新通知），最终5人全部识别出钓鱼链接，防护意识达标。
• • 作用：从“人、数据、工具”三方面堵上安全漏洞，比如MFA有效防止了去年某离职员工尝试登录代码仓库的事件。

4. Detect（检测）：实时捕捉异常行为

• • 运作场景：“登记系统”测试阶段，政务工厂通过以下工具落实“检测”功能：
  1. 1. CI/CD流程扫描：在Jenkins流水线中集成Snyk（开源漏洞扫描）和SonarQube（代码安全扫描），自动检测出“登记系统”中MyBatis 3.5.13的“SQL注入”漏洞（低危），以及3处硬编码密钥（高危），触发即时告警；
  2. 2. 日志监控：通过ELK Stack（SIEM工具）监控GitLab操作日志，发现某开发人员尝试“批量下载代码”（异常行为），系统自动触发告警，经核查为误操作（该人员需导出代码做本地测试），及时排除风险；
  3. 3. 第三方接口监控：工厂“接口监控平台”实时跟踪“政务汉东”接口响应时间，发现某时段响应延迟从50ms升至500ms，立即通知供应商排查，避免影响测试进度。
• • 作用：将“被动等待漏洞暴露”转为“主动实时检测”，测试阶段累计发现并修复7处安全问题，未带入生产环境。

5. Respond（响应）：快速控制风险影响

• • 运作场景：“登记系统”上线前3天，工厂收到NVD紧急通知——“登记系统”使用的Spring Boot 2.7.10存在“远程代码执行”高危漏洞（CVE-2024-XXXX），需12小时内修复，工厂按“响应”功能要求启动应急流程：
  1. 1. 事件分级：根据工厂《安全事件分级标准》，判定为“一级事件”（高危漏洞+上线临近），启动应急响应团队（ERT），成员包含开发组长、安全工程师、“政务汉东”对接人；
  2. 2. 临时处置：安全工程师先在工厂“WAF防火墙”添加漏洞防护规则，临时阻断攻击路径；
  3. 3. 漏洞修复：开发组2小时内完成Spring Boot 2.7.11版本升级，安全工程师通过“漏洞验证工具”确认修复效果；
  4. 4. 外部协作：同步通知区县政府客户“上线时间延迟1天”，并说明修复进展，避免客户焦虑。
• • 作用：12小时内完成“发现-处置-修复-沟通”闭环，未影响项目最终交付（仅延迟1天，客户认可）。

6. Recover（恢复）：减少故障长期影响

• • 运作场景：“登记系统”上线后1周，工厂“生产环境服务器”因硬件故障宕机，按“恢复”功能要求执行：
  1. 1. 业务连续性启动：切换至工厂“备用生产环境”（与主环境实时同步数据），15分钟内恢复“登记系统”访问，市民可正常提交申请；
  2. 2. 数据恢复验证：通过工厂“备份管理平台”确认——市民提交的327条申请数据已通过“每日全量+实时增量”备份恢复，无数据丢失；
  3. 3. 复盘改进：故障后3天召开复盘会，将“服务器硬件巡检频率从每月1次提升至每两周1次”，纳入工厂《运维SOP》。
• • 作用：最小化业务中断影响（仅15分钟不可用），且通过复盘避免同类故障重复发生。

二、CSF 2.0 Profiles（配置文件）：政务工厂的“安全差距地图”

Profiles 分为“当前态（Current Profile）”和“目标态（Target Profile）”，政务工厂通过两者对比，明确“登记系统”及工厂整体的安全改进方向。

1. 构建当前态：梳理现有安全措施

• • 运作动作：工厂安全团队基于“登记系统”开发流程，在CSF 2.0 Profiles模板中勾选已落实的控制项——如“Govern”功能下已勾选“供应商准入审核”“供应链安全政策”，“Protect”功能下已勾选“MFA访问控制”“数据加密”，但“Govern”功能下的“供应商定期审计”未勾选（当前仅准入时审核，无后续审计）。

2. 定义目标态：锚定合规与业务需求

• • 运作动作：结合政务行业要求（等保2.0三级、《政务数据安全管理办法》），设定目标态——需补充“供应商每季度审计”“客户数据脱敏（如身份证号、手机号）”“应急演练每季度1次”等控制项。

3. 差距分析与改进

• • 运作动作：通过工厂“安全差距分析工具”对比两者，发现3项关键差距：
  1. 1. 供应商管理：缺少定期审计（当前仅准入审核）；
  2. 2. 数据防护：市民敏感数据未脱敏（仅加密存储，前端展示时未隐藏）；
  3. 3. 应急能力：应急演练频率不足（当前半年1次）。
• • 改进计划：1个月内完成“数据脱敏模块”开发，3个月内开展首次供应商季度审计，将应急演练调整为每季度1次。
• • 作用：避免“安全建设无方向”，为工厂后续安全投入提供清晰优先级（如优先开发数据脱敏模块，因涉及市民隐私合规）。

三、CSF 2.0 Tiers（层级）：政务工厂的“治理成熟度标尺”

Tiers 评估组织网络安全治理的严谨性，政务工厂通过CSF 2.0 Tiers 标准，自评成熟度为Tiers 3（整合型），具体对应运作场景如下：

1. 风险决策整合（Tiers 3核心特征）

• • 运作场景：工厂将安全风险纳入“项目评审流程”——“登记系统”立项时，评审会不仅评估技术可行性、成本，还需通过“风险评分卡”（基于CSF 2.0风险评估要求）确认安全风险可控（如开源组件漏洞风险评分≤3分，方可立项）。

2. 资源投入保障

• • 运作场景：工厂年度预算中，安全投入占比15%（高于行业平均10%），用于采购Snyk漏洞扫描工具、ELK监控平台，以及安全工程师培训（如NIST CSF认证培训）。

3. 外部协作能力

• • 运作场景：工厂与地方网信办、NVD漏洞平台建立常态化协作——网信办定期向工厂推送“政务行业高风险漏洞清单”，工厂向网信办反馈“登记系统”安全运营数据（如每月漏洞修复率98%），形成“政企协同”安全机制。
• • 作用：明确工厂当前安全治理处于“整合型”水平，既非“基础型（Tiers 1，仅被动应对风险）”，也未达到“优化型（Tiers 4，可自动预测风险）”，为后续向“优化型”升级提供方向（如引入AI风险预测工具）。

总结：CSF 2.0 对软件工厂的核心价值

在“登记系统”开发全流程中，CSF 2.0 并非“额外的安全负担”，而是政务工厂的“安全运作骨架”——通过Core明确“怎么做”（6大功能落地动作），通过Profiles明确“差在哪”（安全差距），通过Tiers明确“到哪步”（成熟度水平），最终实现“项目安全交付+工厂能力提升”的双重目标。这种模式可复用到工厂其他政务项目（如“企业税务申报平台”），成为软件工厂规模化、安全化运作的“通用语言”。

作者：thetasong

企业当中常见的运营价值流包括制造产品、履行订单、接纳和治疗医疗患者、提供贷款或提供专业服务。大多数员工都在直接服务最终客户的运营价值流中工作，他们可能是：

• 营销企业的产品和服务
• 销售和处理订单
• 制造产品
• 提供客户支持并提供相关服务

开发产品和服务的人员在开发价值流中工作，这是配套文章《开发价值流》的主题。了解企业的OVS对于有效的解决方案设计和实施至关重要。这些人使用解决方案。了解他们意味着了解您的客户，这是以客户为中心和设计思维的关键方面。OVS向客户提供产品或服务，这有助于保持业务盈利和健康。

运营价值流详解

价值流是精益思维最基本的构建块，也是SAFe的基础。精益思维可以概括如下[2]：

• 精确地按产品指定价值
• 识别每个产品的价值流
• 使价值流动不间断
• 让客户从生产者那里拉动价值
• 追求完美

在大规模敏捷中有两种类型的价值流：运营价值流和开发价值流。

每个价值流代表企业向客户交付价值的一系列步骤。每个价值流都突出显示了价值流、延迟、返工和瓶颈。它们说明了当前流程如何影响所有工作的人员。识别、可视化和优化价值流是精益企业用来缩短上市时间同时提高其产品和服务的及时性、质量和价值的主要方法。

定义运营价值流

无论是否明显，每个产品或服务都已经有一个OVS，即用于向客户交付特定产品或服务的一系列步骤。例如，履行订单、接纳和治疗医疗患者，或提供贷款或专业服务。

图1说明了价值流的结构和流程。一个”触发器”，通常是对产品或服务的请求，启动了流程。每个V形符号标识一个”步骤”——处理订单所需的活动。每个步骤都需要时间来完成。所有处理步骤时间的总和，加上它们之间的延迟时间，就是”总前置时间”（或流动时间）。缩短前置时间是缩短上市时间的最快方法。

图1. OVS的示例结构和流程

只要客户继续订购其产品或服务，价值流就会持续存在。它们跨越部门和职能，每个价值流都包含：

1. 将触发器转换为价值交付所需的所有步骤
2. 执行这些步骤的人员
3. 他们用于工作的系统
4. 满足该请求所需的信息和材料流

理解上述四个步骤对于理解价值如何流向客户至关重要。图2说明了OVS的这种扩展视图。

图2：运营价值流的扩展视图

运营价值流的类型

有四种常见的OVS模式：

1. 履行代表通过交付数字化产品或服务并接收付款来处理客户订单的过程。例如，为消费者提供保险产品或履行电子商务销售订单。
2. 制造将原材料转换为客户购买的产品。例如，消费品、医疗设备和复杂的网络物理系统。
3. 软件产品提供和支持向最终用户或企业销售的软件应用程序和解决方案。例如，ERP系统、SaaS以及桌面和移动应用程序。
4. 支持价值流是各种重复性和内部支持活动的端到端工作流程。例如，员工招聘、建立和执行供应商合同、执行年度审计以及完成企业销售周期。

图3说明了每种类型OVS的示例。

图3. 四种类型OVS的示例

尽管公司需要职能部门来构建和共享知识，但它们不是价值流，因为它们不会从触发器（请求）到向最终客户交付产品或服务的过程中传递价值。然而，这些部门中的许多人参与一个或多个OVS。

大型企业通常向客户提供各种产品和服务，这是它们成长的方式之一。因此，可以推断这些企业内部有大量的价值流。图4说明了”消费贷款“价值流如何只是大型银行的产品和OVS之一。

图4. 商业银行中消费贷款的突出运营价值流

识别运营价值流

价值流提供了企业如何为客户服务的最基本和最根本的知识。这是无可替代的，精益企业通过识别、分析和优化其价值流来持续改善其业务绩效。DVS的目的是为OVS创建和推进系统和产品。因此，了解这些价值流对于业务绩效也是不可或缺的。

然而，与黑暗剧院中的小径照明不同，价值流不会自我照亮。它们很复杂，企业中可能没有人完全了解任何单个OVS的流程。这意味着SAFe实践顾问（SPC）和他们的精益敏捷领导者经常被要求了解并帮助优化他们所服务的组织的OVS。以下问题可以帮助进行这种分析：

• 谁是您的用户和客户？他们是内部的、外部的还是两者兼而有之？
• 您营销、销售和支持哪些产品和服务？
• 您为内部用户提供哪些解决方案？
• 什么触发了价值流？
• 您的客户认为您提供了什么价值？

一旦确定，图5中的模板可用于捕获特定价值流的目的和属性。

图5. 带有消费贷款示例的价值流定义模板

运营价值流和客户旅程地图

如图6所示，客户旅程地图是强大的设计思维工具。它们说明了客户与公司的OVS及其产品和服务互动时的用户体验。它们允许团队确定一个或多个DVS如何改善客户旅程，创造更好的端到端体验。

图6. 消费贷款价值流的客户旅程地图

许多开发人员构建和支持OVS用于创建客户旅程的内部系统。改进这些基础系统可以改善外部客户的旅程。因此，OVS中使用这些内部系统的人员是DVS的客户。以客户为中心和设计思维在这里同样适用。

改进运营价值流

最后，价值流实现了价值流映射，这是一个协作过程，其中一组利益相关者定义价值流的步骤、交接和延迟。这种映射突出显示了完成请求所需的总时间，同时突出了需要改进的领域。

图7说明了支持产品发布的营销活动的价值流图。

图7. 营销活动的价值流图

对于大多数未优化的价值流，步骤之间的等待消耗了大部分流动时间。在此示例中，总活动时间仅占流动时间的11%。其余89%是等待步骤开始的时间。

自然的倾向是减少活动时间。毕竟，那是实际工作完成的地方。然而，仅关注活动时间可能会对人员、文化和质量产生负面影响。这反过来可能会增加流动时间并降低经济成果。

减少步骤之间的等待时间通常更有效。SAFe中的许多指南直接关注这个问题。原则#6——使价值流动不间断描述了几种实现这一点的实用方法。

投资组合是指企业当中一组协调的、持续的数字化解决方案，旨在实现特定的业务愿景和目标。在大规模敏捷SAFe中，投资组合代表了企业用于投资、开发和维护这些解决方案的预算和人员。

它是SAFe的四个运营层次之一，包含一组开发价值流（DVS），这些价值流负责持续开发、交付和维护一组数字化解决方案。每个DVS都拥有自己的解决方案和用于实现其业务愿景的ART。

在某些情况下，投资组合可能承担一个或多个运营价值流（OVS）的责任，并应用业务与技术中描述的模式。

投资组合支持企业的战略目标，同时将资金分配给不同的DVS和解决方案，以确保它们获得所需的资源来实现其使命。

每个投资组合都有一个清晰的投资组合愿景，描述其预期的业务成果，以及一组投资组合战略主题，这些主题指导投资决策并确定资金分配的优先级。

投资组合具有以下特征

1. 目的

投资组合的目的是通过确保资金和人员资源分配给最能支持企业战略目标的DVS和解决方案，来优化企业的价值流动。这包括：

• 建立投资组合愿景和战略主题，以指导投资决策
• 应用精益投资组合管理（LPM）实践来管理投资组合预算、史诗和治理
• 通过在价值流级别进行持续投资和改进，确保解决方案的持续价值交付
• 确保投资组合中的DVS和解决方案相互协作，以支持企业的整体目标

2. 背景

投资组合在企业的组织结构中占据重要地位，负责协调跨多个DVS和解决方案的投资和交付。投资组合管理通常由一组经验丰富的业务和技术领导者组成，他们共同做出战略投资决策，监督投资组合的健康状况，并确保投资组合与企业的整体战略保持一致。

3. 结构

投资组合的结构反映了企业的战略目标和市场需求。投资组合通常由以下部分组成：

• 投资组合愿景和战略主题：指导投资决策的高层次方向
• 投资组合预算：分配给投资组合的资金，用于支持DVS和解决方案的开发和维护
• 投资组合史诗：跨多个DVS和解决方案的大型工作项目
• 开发价值流：负责持续开发和交付特定解决方案集的团队集合
• 解决方案：投资组合交付的产品或服务
• 精益投资组合管理实践：用于管理投资组合的流程和工具

投资组合通过分配预算给DVS和解决方案来支持企业的战略目标。每个DVS负责开发和维护一组解决方案，这些解决方案共同实现特定的业务目标。

注意：在某些情况下，投资组合可能承担一个或多个运营价值流（OVS）的责任，并应用业务与技术中描述的模式。

如图3所示，投资组合画布通过使以下内容可见来捕获投资组合的当前状态：

• 投资组合的DVS
• 价值主张和它们提供的解决方案
• 它们服务的客户
• 分配给每个价值流的预算
• 实现投资组合目标所需的其他重要活动

投资组合愿景流程使用投资组合画布来探索和考虑不同的投资组合配置。有关使用投资组合画布的更具体指导，请参见投资组合愿景文章。

如何开展投资组合以及有哪些类型

确定单个投资组合的目的和内部结构代表了一系列重要的战略决策。大型企业还必须解决组织和运营多个投资组合的潜在需求。这就增加了关于投资组合的外部结构及其与企业中其他投资组合关系的决策。最初，公司在采用SAFe和LPM时必须决定如何构建其投资组合设计。随着企业和投资组合环境的变化，他们应该定期重新审视这一决定。事实上，这种围绕价值组织和重组的能力是组织敏捷性能力中描述的战略敏捷性的关键组成部分。关于LPM初始采用的指导可以在实施路线图的增强投资组合步骤中找到。

与投资组合初始配置相关的组织变革可能相对较小，特别是对于采用下面描述的单一投资组合模式的公司。通常，初始工作重点是捕获或代表现有的总体预算、系统和人员作为SAFe投资组合。这导致应用围绕价值组织和增强投资组合步骤的实施路线图来迭代地改善通过投资组合的价值总体流动。

围绕价值组织投资组合

较小的企业和政府机构可能只需要一个单一的SAFe投资组合来构建实现其使命所需的所有数字化解决方案。如图4所示，较大的企业可能有数以千计甚至数以万计的IT、系统、应用程序、硬件和软件开发从业者，在数百或数千个解决方案中工作。这些解决方案支持各种业务线、客户细分和特定的业务能力。通常，这些较大的企业识别并实例化多个投资组合，以有效地集中精力、资金和战略意图，同时分散决策。

图4. 企业可能包含单个SAFe投资组合或多个SAFe投资组合

当需要多个投资组合时，它们通常按照最重要的业务、产品和市场边界划分。每个投资组合旨在优化所有包含的DVS的流动，同时还允许它们通过在其价值流之间重新分配资金来快速响应市场中出现的威胁和机会——实质上是在最大的企业中实现业务敏捷性。

以下是如何围绕价值组织投资组合的几个示例。在每个示例中，投资组合支持相关的业务战略，同时避免与其他投资组合进行导致延迟的协调和谈判。

注意：这是一个部分列表，旨在启发和提供组织投资组合的不同方式。大型企业将混合和匹配这些以实现其组织目标。通常可以通过”由外而内”地查看公司网站以及它如何向公众解释其产品和服务来获得更多灵感。

示例A – 单一投资组合

• 大量人员
• 复杂的技术景观
• 不同的业务单元解决方案集
• 具有挑战性的地理动态
• 不同程度的监管风险

单一投资组合的好处包括：

• 影响整个企业的投资组合决策在一个单一的论坛上与所有必要的利益相关者一起做出
• 投资组合作为一个单一的精益预算获得资金，允许根据市场条件和新兴机会进行重大变化
• 企业架构师可以维护整体解决方案景观的单一视图，以确保所有解决方案都有足够的架构跑道
• 维护流动简单且具有成本效益，没有协调和管理多个投资组合的复杂性

单一投资组合的挑战包括：

• 由于其规模，一些特定于单个领域或业务单元的史诗和决策成为投资组合关注的问题，并被许多投资组合协作成员视为干扰
• 由于投资组合协作时间可能集中在更令人兴奋或战略上重要的追求上，一些领域无法获得所需的领导关注
• 解决方案可能变得比预期的更加相互依赖，在快速增长的情况下导致未来的依赖管理挑战
• 业务单元难以追求不同的战略，因为单一投资组合必须支持所有业务单元的目标和需求

示例B – 业务单元投资组合

企业经常发现，它们的业务单元使用不同的解决方案在不同的市场环境中追求不同的战略，以提供相关的客户体验。在这些情况下，企业可能创建特定于业务单元的投资组合。该投资组合包含运营业务和追求其战略所需的所有解决方案，包括运营和扩展支持该业务的解决方案所需的人员、资金、权限和责任。

注意：在组织有多个投资组合的情况下，可以使用企业投资组合管理（EPM）来协调大型跨领域计划。企业文章包含更多关于EPM的信息。

业务单元投资组合的好处包括：

• 市场变化和战略决策通常在不同的时间和节奏发生在各个业务单元，允许每个投资组合在不干扰其他投资组合的情况下做出本地响应
• 支持每个业务领域的平台和解决方案大多是不同的，必要的交互通常通过合作伙伴在公司外部也使用的易于理解的接口发生
• 企业的整体财务将投资组合视为非常不同的业务领域，包括董事会级别的投资计划和季度收益报告
• 业务领域追求非常个性化的业务战略，相互影响相对较小

业务单元投资组合的挑战包括：

• 同样的人经常是多个投资组合的客户，由于分离，他们面临脱节的体验
• 由于具有不同的战略主题集，以及由此产生的不同的OKR和绩效激励，业务领域之间的交叉销售工作经常面临重大的协调挑战和内部阻力
• 需要业务之间密切协调的新战略机会在跨投资组合协调时引入重大挑战。这给试图领导相关史诗的人带来了相当大的压力
• 其他领域所需的共享服务可能仅存在于一个业务领域的投资组合中，导致依赖和优先级管理挑战

多个业务单元投资组合的具体示例包括：

• 一家大型银行将支持其各种投资和咨询服务的解决方案放在与支持其零售和商业银行业务不同的投资组合中
• 一家企业软件产品公司为每个产品单元创建一个投资组合，使其战略重点更加突出，专注于创建、发展和支持服务于单一市场或类别的产品
• 一家大型飞机制造公司为设计和制造军用飞机与制造商用飞机创建不同的投资组合

示例C – 平台投资组合

大型企业经常发现，各个业务单元在追求各自独特的战略时，依赖于相同的解决方案进行核心运营。这些解决方案可以通过向战略合作伙伴公开功能或通过API商业模型直接货币化。在这些情况下，企业可能创建一个负责运营和扩展核心平台的投资组合。这允许投资组合开发所需的架构，投资以确保未来的能力，并保持低技术债务，以便为具有许多客户端的高可用性、高弹性服务集提供支持。平台投资组合遵循独特的战略，基于整体企业战略和平台吸收各种请求变更的能力，优先考虑其众多客户的需求。

平台投资组合的一个特例是”企业系统投资组合”。这通常是一个小型投资组合，包含运营业务所需的所有解决方案，同时作为企业运营平台。这些解决方案通常不直接支持任何OVS。相反，它们支持特定功能或通常支持所有员工。企业系统投资组合中常见的解决方案包括企业通信、员工生产力、薪资、财务报告和人才获取。

平台投资组合的好处包括：

• 将业务单元视为平台客户，确保所有投资组合内部和外部投资组合客户的一致服务和安全
• 平台投资组合可以独立探索和测试面向外部客户的新产品，同时保持清晰的接口并简化与业务单元客户的上市工作
• 平台投资组合可以保持独特的外部市场战略，同时允许业务单元推进其战略
• 较少的未经验证的功能想法被实施到平台中，因为它们作为史诗被更严格地检查，这意味着新请求有明确识别的MVP和业务成功标准

平台投资组合的挑战包括：

• 平台投资组合可能产生与业务单元明显不同的公司文化，导致大型项目的协作障碍
• 业务单元领导者有时会因满足其平台投资需求而感到沮丧。平台投资组合有直接的收入目标，而业务单元请求与推动平台投资组合直接业务价值的特性和史诗一起被优先考虑和排序
• 没有一致的客户联系，平台投资组合可能与公司的整体业务模式和目的脱节
• 平台投资组合必须保持强大的战略和清晰的愿景，否则它可能沦为一个”接单”实体，可能导致显著的客户不满和更高的技术债务

平台投资组合的具体示例包括：

• 一家汽车公司在一个单一的平台投资组合中维护和推进其核心车辆平台。产品线利用它来生产各种车辆品牌和型号
• 一家金融服务公司将其核心处理能力放在一个平台投资组合中，为销售金融产品的各个业务单元提供服务，并向小型金融科技合作伙伴公开商业API，以创建独特和创新的产品
• 一家旅游服务公司将其核心预订、定价和可用性服务放入一个平台投资组合中，用于其品牌产品。它还将API授权给第三方用于定制旅游网站，从而为平台生成的消费者旅游数据暴露数据市场

示例D – 区域运营投资组合

全球企业经常发现，由于当地客户期望和竞争环境，不同的运营区域必须以不同的方式参与区域市场。通常，它们的大部分收入来自单一的”家乡”区域，同时需要补贴向新区域的扩张。在这些情况下，企业可能将在其家乡区域交付和改进业务所需的所有解决方案放入一个单一的投资组合中，然后建立一组与单个国家或地理区域对齐的小型投资组合。

家乡投资组合负责维护、运营和改进核心业务解决方案，并向所有区域运营投资组合公开其能力。同时，每个区域运营投资组合将根据其区域业务战略和监管环境的要求消费和扩展这些解决方案，通常作为业务和技术中描述的组合投资组合工作。企业根据公司的整体国际业务战略向区域投资组合分配资金。在实践中，这些区域运营投资组合通常比家乡投资组合小得多，观察到的几个案例中预算和人员比例为100:1。

区域运营投资组合的好处包括：

• 区域运营投资组合可以访问他们无法在当地资助的尖端能力
• 区域运营投资组合可以专注于快速参与和发展当地市场，而不会陷入大型技术投资
• 家乡投资组合确保全球网络风险暴露得到良好管理，符合最严格的安全标准
• 家乡投资组合可以通过重大投资和转型做出响应，保护和增长公司最大的利润来源
• 资金通常与各个国家的独立运营实体保持一致，简化了遵守国际财务报告法的要求

区域运营投资组合的挑战包括：

• 主要投资组合经常未能将国际投资组合视为需要”开箱即用”解决方案的客户，导致过高的采用成本
• 国际投资组合难以获得其需求的优先级
• 独立运营实体对投资组合之间的财务转移设置限制，要求以增加开销的方式对内部服务进行定价和跟踪，直到建立可重复的模式

企业可以通过让区域运营投资组合的代表参加家乡投资组合的参与式预算活动来减轻上述许多挑战。这将”区域投资组合开发人员”作为明确的用户角色引入，用于创建旨在国际使用的解决方案的ART。

区域运营投资组合的具体示例包括：

• 一家大型保险公司在美国拥有家乡投资组合，并在世界各国拥有各种区域运营实体
• 一家总部位于德国的制造公司从其德国家乡投资组合为欧洲市场提供服务。区域运营投资组合在世界各地扩展、制造和支持本地化产品
• 一家流媒体和媒体服务公司从其位于欧洲的家乡投资组合为世界大部分地区提供服务，同时在几个需要广泛本地内容审核和监管监督的国家建立小型运营投资组合

示例E – 监管和风险投资组合

由于人类安全、国家安全、反垄断或内幕交易问题，一些企业经营高度监管的业务。在这些情况下，企业可能创建包含共享监管背景的产品和服务解决方案的投资组合。通常，这些监管背景也与特定的市场细分相关。这种与市场细分和监管背景的对齐允许每个投资组合更快地创新，而不会限制或给其他投资组合带来风险。

监管投资组合的好处包括：

• 每个投资组合可以以最快的速度运营，同时尊重其市场和监管背景的特定安全问题
• 可以访问其他受限技术（例如，受出口管制的军事技术）的投资组合可以基于该解决方案背景进行创新，而不会给其他投资组合带来风险
• 信息可以在投资组合内部普遍可用，同时提供更强大的控制以防止在投资组合外部共享，降低暴露风险（例如，重大非公开交易信息、机密数据）
• 投资组合之间的协作是透明和良好治理的，在需要时提供满足投资组合特定法律和监管义务的明确证据（例如，反垄断情况）

监管投资组合的挑战包括：

• 由于知识共享边界，跨投资组合共享的新见解和实践较少
• 创建跨投资组合的客户体验和解决方案更具挑战性，并在寻找共享品牌声音方面引入营销复杂性
• 不同程度的安全文化导致对其他投资组合背景的误解和不尊重
• 投资组合之间的不同期望可能限制员工在公司内部的职业流动性
• 共享职能（例如，财务、企业审计）可能无意中默认采用最严格的标准，为监管较少的投资组合带来延迟和不必要的摩擦

监管投资组合的具体示例包括：

• 一家医疗设备公司将其最严格监管的医疗设备的解决方案放在与风险较低的设备和其他医疗保健解决方案不同的投资组合中
• 一家发动机公司将其与出口管制军事发动机相关的所有开发放在与全球可用的商用发动机产品不同的投资组合中
• 一家金融服务公司将其投资银行的解决方案与其他业务隔离开来，放在不同的投资组合中，以限制对重大非公开信息的访问并降低内幕交易风险

示例F – 创新投资组合

大型企业通常发现，创建与先前成功业务有实质性差异的新业务模型具有挑战性。实现新业务模型通常需要一系列新解决方案和对现有解决方案的重大修改，以支持不同的运营流程。这些变化可能会在条件反射式支持不同业务模型的投资组合中遭到抵制。在这些情况下，企业经常创建新的投资组合来为该新兴业务单元提供完整的解决方案集。为此，企业可能：

• 构建新解决方案
• 收购具有兼容业务模型和解决方案的公司
• 从企业其他部分获取现有解决方案

追求新业务模型通常需要频繁且重大的转型。因此，创新投资组合必须与面向市场的业务伙伴密切合作，很少有有意义的长期路线图，并且经常选择作为组合投资组合运营，如业务和技术文章中所述。由于协调成本和所需的不同转型速度，创新投资组合参与企业史诗的情况不太常见。事实上，创建创新投资组合的主要原因是消除需要众多企业史诗来协调新业务模型的许多解决方案变更的需求。

创新投资组合的好处包括：

• 新业务和相关解决方案获得专注的领导时间和关注，同时暂时摆脱季度收入和利润率目标的压力
• 与单一目标密切相关，它可以跟上新兴业务模型中频繁、重大的转型，不必支持全方位的企业需求
• 它提供了一个更小、更安全的空间来整合新收购的业务，允许它们独特的能力和文化贡献在收购公司中扎根
• 它将许多破坏性的”打破规则”行为隔离在一个单一的投资组合中，最小化日常业务的中断，并允许更有意地设定未来的运营指南
• 新业务的焦点和紧迫性创造了对新实践和方法的接受度，这些实践和方法可以在新业务中孵化，然后传播到整个企业

创新投资组合的挑战包括：

• 投资组合按照不同规则行事并被视为特殊的看法会给公司文化带来挑战
• 其他业务中的人员发现新业务模型具有威胁性，降低了生产力和与工作的联系
• 支持多个投资组合的职能（例如，财务、人力资源）不习惯以新投资组合的加速速度工作，对其流程造成压力并挑战关系

创新投资组合的具体示例包括：

• 企业购买或大量投资多个小型初创公司，利用创新投资组合结构来决定随着时间推移将哪些解决方案拉入/合并到其他SAFe投资组合中
• 一家汽车制造商创建一个新的投资组合来设计和原型概念车，专注于品牌知名度、客户反馈和定价
• 一家拥有极高技术债务和对遗留系统依赖的企业创建一个投资组合，专注于仅使用当前技术的新业务。然后，这些能力迭代地过渡到遗留解决方案中（例如，使用绞杀模式）。随着时间的推移，这些新解决方案和习惯消除了创新投资组合的需求
• 一家医疗设备公司采用与其习惯截然不同的业务模型，因为它进入基于订阅的患者监测和连接护理。然后，它将该业务的解决方案放入不同的投资组合中，以允许密切联系和随着业务学习如何交付新产品而快速转型。

—2022 年联邦劳动力优先事项报告

SAFe for Government 是一套成功模式，通过实施 SAFe 的精益-敏捷价值观、思维模式、原则和实践，帮助公共部门组织获得更好的解决方案开发成果。而系统的敏捷培训能为政府机构团队奠定转型基础，Scrum 认证培训则可进一步规范实践落地标准。

精益和敏捷思维的基础在私营部门的软件和系统开发中带来了比瀑布方法更高的成功率。政府项目开始使用这些相同的模式取得类似的结果。然而，政府机构在精益 – 敏捷转型中必须解决独特的挑战。SAFe for Government 中的建议和最佳实践提供了特定的指导来解决这些问题，而企业管理培训能帮助政府管理者掌握组织变革的统筹方法，确保转型有序推进。

政府特定的 SAFe 指导体系

政府特定的 SAFe 指导在以下九篇文章中提供：

• 建立在精益 – 敏捷价值观、原则和实践的坚实基础上 (https://framework.scaledagile.com/government-building-a-solid-lean-agile-foundation/)
• 创建由政府和承包商人员组成的高绩效团队 (https://framework.scaledagile.com/government-creating-high-performing-teams-of-teams/)
• 使技术投资与机构战略保持一致 (https://framework.scaledagile.com/government-aligning-technology-investment-with-agency-strategy/)
• 从项目过渡到精益的史诗流 (https://framework.scaledagile.com/government-transitioning-from-projects-to-a-lean-flow-of-epics/)
• 采用与开发价值流一致的精益预算 (https://framework.scaledagile.com/government-adopting-lean-budgeting-aligned-to-value-streams/)
• 应用节奏中的精益估算和预测 (https://framework.scaledagile.com/government-applying-lean-estimating-and-forecasting-in-cadence/)
• 修改采购实践以实现精益 – 敏捷开发和运营 (https://framework.scaledagile.com/government-modifying-acquisition-practices-to-enable-lean-agile-development-and-operations/)
• 构建质量和合规性 (https://framework.scaledagile.com/government-building-in-quality-and-compliance/)
• 调整治理实践以支持敏捷性和价值的精益流动 (https://framework.scaledagile.com/government-adapting-governance-practices-to-support-agility-and-lean-flow-of-value/)

本摘要文章的其余部分阐述了为什么精益 – 敏捷和 SAFe 的原则和实践对政府机构特别相关的背景，并提供了该系列中每篇文章的摘要。

政府为何尝试大规模敏捷

精益 – 敏捷和 DevSecOps实践正在引起全球负责为政府构建最大、最复杂系统的领导者的兴趣。这种兴趣很大程度上是由改变政府机构如何向公民、政府工作人员和作战人员提供服务的内部和外部力量驱动的。政府关注的是任务敏捷性。虽然管理有限的资源和资金是一个问题，但政府不是以利润为导向的，而是将成功衡量为解决方案提供的影响价值。在这方面，政府类似于非常大、复杂的非营利组织，努力以尽可能有效和高效的方式运营业务。

这些需求驱动因素包括：

• 对业务（任务）敏捷性的需求
• 数字化转型的影响
• 社交媒体的兴起和对 IT 支出信息的即时访问
• 公民期望的提高
• 技术债务和过时系统推动 IT 现代化计划
• 防御系统的快速变化和全球网络威胁环境
• 为政府工作人员培养敏捷组织和成长思维

与营利性组织一样，政府越来越依赖技术。然而，过去 60 年来开发和维护解决方案的传统方法在开发现代技术能力时已被证明是不够的。敏捷实践已显示出潜力，而Scrum 培训能帮助政府团队掌握迭代开发的核心方法。然而，政府系统的规模和复杂性 —— 从法国公民的失业福利网站到大型网络物理哨兵导弹系统 —— 需要团队级敏捷和 DevSecOps 实践之外的更多内容。

美国联邦政府采用敏捷的背景

自 2022 年以来，美国对政府技术开发项目的精益 – 敏捷方法的兴趣呈指数级增长。同年 7 月，美国政府问责局（GAO）发布了一份报告，推荐了敏捷开发的特定实践，以及在政府中采用敏捷的 14 个独特挑战。同年，美国管理和预算办公室（OMB）指示各机构将其采购实践从臃肿的长期项目转变为更模块化的合同方法，与迭代开发模式保持一致。尽管这些都是积极的迹象，表明数十年来对瀑布流程的承诺正在减弱，但各机构仍然缓慢地采用不同的工作方式。图 1 显示了推动美国联邦政府采用精益 – 敏捷重大事件的时间线。

2013 年末美国 Healthcare.gov 网站的麻烦启动几乎在一夜之间增加了对采用敏捷的兴趣。该网站允许公民获得作为平价医疗法案（ACA）一部分的健康保险。几周来，该网站的初始困难在全国新闻中被突出显示，暴露了政府技术项目常见的传统开发实践中的许多弱点。这些事件对政府 IT 项目的公众关注推动了对采用更现代开发实践的更大开放态度。在德勤 2017 年发布的美国联邦政府敏捷采用分析中，报告使用敏捷或迭代流程的联邦 IT 项目的百分比自 2012 年以来大幅增长，如图 2 所示。

当两个新的美国政府机构——18F和美国数字服务——成立以吸引行业人才帮助将现代、硅谷式实践带到联邦IT项目时，对精益、敏捷和DevOps的兴趣加速增长。数字服务手册和TechFAR手册是他们提供的两个早期资源，帮助政府项目的领导者了解如何现代化开发实践并调整采购流程以支持敏捷合同。政府撰写的关于敏捷采用的额外资源数量以及已发布的联邦项目在转型为精益-敏捷实践后取得更好结果的成功案例数量都显著增长。其中一个机构，国土安全部，已将敏捷作为软件开发的正式标准。2020年9月，政府问责局（GAO）发布了其GAO敏捷评估指南：敏捷采用和实施的最佳实践的草案，供使用敏捷实践的政府项目参考。国会继续通过立法（如年度国防授权法案（NDAA））指导增加敏捷培训并授权现代化采购实践以支持敏捷，而敏捷培训的普及也为政策落地提供了人才支撑。

全球政府采用敏捷的趋势

州和地方政府以及全球各国政府的系统开发也经历了类似的趋势。英国政府多年来一直在进行敏捷转型工作，涵盖其许多部门和机构的数百个敏捷团队。法国就业局（Pôle Emploi）、荷兰税务局和澳大利亚邮政（邮政服务）是使用 SAFe 指导其向规模化精益 – 敏捷转型的全球政府机构的例子。就法国就业局而言，其转型已导致更好地按时交付就业福利，并提高了招聘企业和求职者对该机构服务的满意度。这些成功案例背后，离不开Scrum 认证培训为团队提供的标准化实践框架支持。

作为精益企业的政府

越来越多的政府机构面临着与商业同行相同的变革力量，促使他们加速精益 – 敏捷转型。对业务（任务）敏捷性的需求、数字中断、全球化、不断增加的网络威胁、老化的遗留系统以及对技术实现业务和任务成功的日益依赖，只是政府和行业共同关注的几个因素。

精益企业的标志是能够在可持续的最短交付时间内提供最佳质量和价值。SAFe 通过描述帮助组织实现这些能力的成功模式来提供指导。许多政府机构 SAFe 实施的案例研究的证据表明，这些能力以与商业企业相同的方式适用于公共部门组织。而企业管理培训能帮助政府管理者建立精益思维，从组织层面推动价值流动优化。

SAFe 如何在政府中实现精益 – 敏捷和 DevOps

“在 10 个月的时间里，我们将一个失败的努力转变为作战人员、我们的组织文化和纳税人的成功故事。没有 SAFe，我们不可能如此快速地执行转变……”

—Scott Keenan，JLVC 项目经理，联合参谋部（美国国防部）

政府中的 SAFe 采用正在增长

许多政府技术项目规模庞大且复杂，涉及数百名（有时数千名）从业者。解决方案由多个团队组成的团队构建，这些团队需要：

• 一起规划和工作
• 管理跨团队依赖关系
• 频繁集成
• 迭代地展示工作软件和系统
• 分享学习以不断改进

通常，这些大型解决方案包括与大量承包商人员密切合作的小规模政府员工团队。不同合同上的多个供应商可能在分散的地理位置上从事同一项目。高保证和合规要求、繁重的治理法规以及异常长的采购前置时间进一步复杂化了政府项目。

这些挑战中的大多数在大型商业组织中也很常见。全球 1000 强企业已经使用精益 – 敏捷构建核心银行系统、卫星、农业联合收割机、健康网络的临床和金融系统等等。对于这些组织，SAFe 已经成为规模化精益 – 敏捷实践的领先框架；其积极结果已在已发布的案例研究中得到记录。许多政府机构采用 SAFe 作为技术开发的流程模型，原因与商业同行相同。在两种环境中都使用过 SAFe 的从业者报告说，行业和政府之间的开发相似之处远多于差异。如图 3 所示，SAFe 现在正在大量政府机构的数百个项目中使用，而Scrum 培训则为项目团队提供了关键的迭代执行能力。

政府在精益 – 敏捷采用之路上面临独特挑战

尽管向精益 – 敏捷和使用 SAFe 的势头有所增加，但几个障碍延迟了广泛采用。最常被引用的挑战包括：

• 过去敏捷的糟糕实施导致不愿再次尝试
• 以瀑布为中心的治理和生命周期政策不容易改变
• 采购人员缺乏敏捷合同和精益合同实践的经验
• 项目导向而非持续价值流动思维在政府文化中根深蒂固
• 长采购生命周期造成巨大浪费和交付价值的延迟
• 缺乏共同的企业精益 – 敏捷框架导致项目之间的协同作用有限

尽管这些问题看起来与商业公司面临的问题相似，但公共部门环境中的组织背景、文化和政府权力是独特的。政府采购流程和法律旨在为潜在提供商创造公平的竞争环境，但它们也可能创造出私营部门无法体验的官僚主义和延迟。此外，政府机构没有驱动商业环境中快速变化和创新的竞争市场动态和利润动机。相反，立法机构通常在政治化的年度拨款过程中提供资金，而这些过程进展缓慢。即使是政府技术项目的 “价值” 概念也往往难以概念化和衡量。这些挑战的解决，需要结合敏捷培训的实践指导与企业管理培训的战略统筹能力。

解决方案 —— 政府特定的 SAFe 指导

由于政府技术开发中的因素特定于这些环境，因此需要专门的指导来帮助变革推动者领导转型。以下链接连接到解决在政府项目中采用 SAFe 最常见挑战的文章，以及支持向精益 – 敏捷模式过渡的最佳实践。

建立在精益-敏捷价值观、原则和实践的坚实基础上。 瀑布式思维和流程在政府技术项目中根深蒂固。简单地模仿团队同步和从待办事项工作等实践不会实现机构敏捷性。政府领导者和从业者及其行业合作伙伴必须了解精益-敏捷与过去的技术开发方法在根本上的不同之处以及原因。

创建由政府和承包商人员组成的高绩效团队。 精益-敏捷开发是一项团队运动。政府项目中的团队通常包括政府和承包商人员的组合。这些实体之间的关系往往更具对抗性而非合作性。这种摩擦抑制了高绩效团队的发展，并最终阻碍了有价值的高质量解决方案的快速交付。

使技术投资与机构战略保持一致。 政府技术项目可以出于各种原因提出、批准和资助。技术投资通常基于对过去计划的假设资金，而没有定期审查系统的整体组合。通过确保优先事项与机构的战略要务保持一致和协调，可以最佳地利用有限的开发资金。

从项目过渡到精益的史诗流。 技术开发的”项目隐喻”的开始-停止性质导致在过程中过早地承诺点解决方案，此时未知因素太多，并且即使仅完成最高优先级的功能就能提供大部分价值，也承诺交付所有计划的功能。项目还鼓励将人员转移到工作，而不是通过单件流待办事项将工作流向团队。精益的替代方案是将大型工作组织成史诗，并从由长期存在的团队组成的优先待办事项中以流动方式管理它们。

采用与开发价值流一致的精益预算。 随着从项目向精益史诗流的转变，预算方式也发生了变化。预算不是为单个工作提供资金，而是为”工厂”提供资金，该工厂可以根据优先事项构建机构需要的任何东西。由于优先事项可以持续变化和调整，这种方法避免了更改订单或全新招标将投资从一个计划转移到另一个计划的浪费和延迟，从而实现机构敏捷性。

应用节奏中的精益估算和预测。 精益-敏捷实践认识到，传统的估算和预测技术往往会失败，因为在构建全新系统时存在太多未知因素。这些传统技术还将项目锁定在前期创建的一个正确答案上，并用于定义与多个供应商的合同条款。精益估算和预测技术是轻量级的，提供对不断变化的条件的必要适应性，同时仍然提供关键的报告和问责制。

修改采购实践以实现精益-敏捷开发和运营。 政府采用精益-敏捷的障碍中，很少有像传统采购流程那样令人生畏的。合同官员依赖于为每个新采购使用久经考验的样板语言，这些语言牢固地基于瀑布条款和条件。如果要求承包商以与精益-敏捷价值观和原则相悖的方式执行，项目就不可能真正敏捷。向新的开发方式转型需要为合同官员提供新的模板，允许供应商合作伙伴也采用精益-敏捷。

构建质量和合规性。 精益-敏捷的目标是在技术解决方案中创建价值的持续和可持续流动。如果我们的治理流程（如验证和确认）仍然是仅在项目结束时执行的大批量活动，那么持续流动就会受到阻碍。改变开发团队的工作方式只是答案的一部分。技术价值流的每个方面，包括运营和治理，也必须以更小的批次流动工作。这将质量和合规性构建到解决方案中，而不是在发布前将其作为一个大批量的一部分进行检查。

调整治理实践以支持敏捷性和价值的精益流动。 技术开发的传统治理标准也深深扎根于瀑布模型。它们要求项目在前期规划一切，在工作开始前承诺并预算一个正确的解决方案，为未知工作提供详细的项目计划，通过任意的阶段门，等等。精益-敏捷方法服务于原始意图——提供足够的监督，确保在合理的时间和成本内交付支持任务的能力——但通过使用支持价值持续流动的替代流程和工件。

注意：这些关于政府采用精益 – 敏捷的建议不需要不同版本的 SAFe，也不建议修改 SAFe 术语和实践以适应政府协议。政府服务中的有经验从业者报告说，当 SAFe 模型和术语未经修改使用时，他们取得了最佳结果。使用 SAFe 原生术语允许项目人员利用成功实施 SAFe 实践所需的课程、文章、书籍、论坛和其他信息来源。上述每种实践背后的文章解释了政府项目用来克服将联邦 IT 计划过渡到 SAFe 时最常见问题的特定模式，而敏捷培训和Scrum 认证培训则为这些模式的落地提供了关键的能力支撑。

一个企业是每个大规模敏捷SAFe投资组合所属的业务实体。企业还提供投资组合成功所需的资源和支持。SAFe企业组织其投资组合，以确保有价值的解决方案持续流动，从而实现其业务使命。企业和投资组合利益相关者需要确保每个投资组合中的解决方案不断发展，以满足企业更广泛的战略。当多个SAFe投资组合需要更广泛的协调和协作时，企业投资组合管理（EPM）就会被应用，而企业管理培训能帮助管理者掌握这种跨组合协调的核心方法。

企业战略与投资组合

一切都始于企业战略——实现企业使命的行动计划。企业战略应回答四个关键问题：我们服务哪些客户和市场？我们提供哪些产品和解决方案？我们为这项事业带来了哪些独特的价值和资源？我们未来将如何扩展这些？每个企业都必须有一种方法来确定其战略，这通常是逻辑合理的业务流程的自然结果。

较小的企业和政府机构可能只需要一个投资组合，它可以构建和管理实现其使命所需的所有解决方案，并帮助实现这一企业战略。投资组合通过战略主题与企业战略相连，并被分配了精益预算（图1）。投资组合文章更详细地解释了SAFe投资组合的构造、互动和活动，其中精益预算的分配逻辑可结合敏捷培训中的资源优化模块深入理解。

图1. 小型企业和政府机构可能只有一个投资组合

投资组合高管和业务所有者之间的协作决定了投资组合预算，确定了战略主题，并支持其他LPM活动。

然而，世界上许多最大的组织都在使用SAFe。这些企业拥有数千名，甚至数万名IT、系统、硬件和解决方案开发从业者。并非所有这些从业者都在同一个投资组合中工作。更可能的是，人们被组织起来支持各种业务线、内部部门、客户群、区域和特定的业务能力。在这些情况下，通常需要协调跨投资组合的工作，创建连接它们的战略主题，并在它们之间分配适当的预算（图2）。在这种情况下，企业投资组合管理（EPM）是必需的，而团队的跨组合协作能力可通过Scrum培训中的协同实践得到强化。

图2. 大型企业和政府机构可能有多个SAFe投资组合

企业投资组合管理（EPM）

企业投资组合管理（EPM）确保相关投资组合集与企业整体愿景和战略保持一致。一个有效的EPM团队使最高优先级的工作能够从战略和投资规划到执行有清晰的路径。这种方法授权各个投资组合在其背景下做出本地化决策，同时保持与企业战略的联系。这种分散的决策制定使投资组合能够快速响应不断变化的客户需求和市场环境，这与Scrum认证培训中强调的去中心化决策原则高度契合。这对于需要快速响应市场条件的公司来说至关重要。

企业投资组合管理协作

确保与企业愿景和战略保持一致需要关键人员共同努力。推动EPM的协作（图3）由可归类为以下类别的现有角色代表：企业高管——组织中最高级别的高管；投资组合负责人——领导每个SAFe投资组合的战略和投资活动的人员，包括业务所有者和企业架构师；企业战略家——通过持续分析和研究，帮助企业高管和投资组合负责人确定长期战略目标的人员；投资组合利益相关者——拥有确保每个投资组合内解决方案成功交付所需的关键知识和见解的人员。业务单元和部门高管通常代表这些人员；企业史诗所有者——负责通过企业投资组合看板系统引导跨投资组合倡议的人员。

图3. 企业投资组合管理协作

这些是具有挑战性和回报的角色，需要在不断变化的环境中将战略转化为可操作的目标，角色间的高效协作可通过敏捷培训中的团队角色定位课程优化。

定义企业投资组合战略主题

SAFe建议使用战略主题（通常使用目标和关键结果（OKR）格式描述）来传达每个SAFe投资组合的战略意图。当组织拥有多个投资组合时，可能需要一组企业投资组合战略主题来协调、告知和连接每个投资组合战略与企业战略，如图4所示。这架起了整个企业与创新和开发新解决方案的投资组合之间的桥梁。EPM协作创建并传达这些企业投资组合战略主题，并确保它们与企业整体愿景和战略保持一致。

图4. 企业投资组合战略主题告知并连接投资组合

企业高管对每个投资组合的成果负责，精心编写的战略主题应有助于回答以下问题：我们的价值流工作如何与企业战略连接？投资组合未来的潜在价值是什么？应该如何花费资金来满足客户和利益相关者的期望？哪些能力可以促进积极的收入和价值流动？这些问题的答案不仅为每个投资组合的个人支出和执行奠定了基础，也为它们之间所需的协调奠定了基础。

分配投资组合预算

除了战略主题外，每个投资组合实现企业战略所需的另一个关键组成部分是投资组合预算。正如精益投资组合管理（LPM）核心能力提醒我们的那样，战略和投资资金确保整个投资组合协调一致并获得资金，以创建和维护实现所需业务目标所需的解决方案。

许多业务挑战、市场机会和条件可能对各种解决方案是本地的。因此，预算讨论需要与每个投资组合进行持续的协作、沟通和协调。为了支持灵活性和分散决策，EPM向投资组合分配预算，包括适当的护栏，每个投资组合可以根据自己的判断使用这些预算为其价值流提供资金（图5）。预算分配过程中的动态调整思维，与企业管理培训中的柔性资源管理理念相契合。

图5. 通过EPM进行投资组合预算分配

协调跨投资组合倡议

新的倡议通常包含在单个投资组合内。然而，一些倡议需要多个投资组合的协作。许多是关键的，不容讨论。然而，如果管理不当，这些跨领域的倡议可能会盲目地推给繁忙的投资组合，使系统过载。

可以创建企业史诗来定义和推理这项重要工作。像投资组合史诗的投资组合看板一样，企业投资组合看板的工作接收流程有助于将需求与能力相匹配，防止过载并促进更快的价值交付。图6展示了企业投资组合看板系统的示例。

图6. 企业投资组合看板系统示例

该过程可以总结如下：所有重要的新跨投资组合倡议进入看板的漏斗，并在与将执行工作的投资组合密切协作下，通过审查和分析。至关重要的是，要模拟很少有项目退出漏斗。这保持了专注，减少了在制品，并加速了价值流动；像投资组合史诗一样，史诗假设陈述和精益商业案例可用于定义和进一步阐述企业史诗；分析完成后，做出继续/不继续的决策；已批准的企业史诗被投资组合拉入实施，这些投资组合创建投资组合史诗来描述其部分工作；测量和史诗所有者的参与持续到看板的完成状态之后，以推进史诗的领先指标和业务成果假设。

企业史诗的例子可能是：跨所有解决方案现代化企业品牌；将断开的体验和架构整合在一起，优化技术流程和客户旅程；合并客户群以创建差异化的混合产品；实施新兴技术，如应用AI助手，以在整个组织中赋能角色和创新。

企业史诗所有者促进并推动围绕跨投资组合倡议的协作。在许多情况下，相应投资组合史诗的范围和实施节奏可能需要在企业范围内进行同步。例如，企业史诗可能需要协调的最小可行产品（MVP）来验证业务假设（图7）。这限制了投资风险，并允许对最重要和最关键的企业倡议进行探索性发现（参见史诗中的SAFe精益创业周期），而MVP的构建与验证方法可在Scrum培训中系统学习。

图7. 跨多个投资组合协调MVP

衡量企业投资组合绩效

SAFe的衡量和成长指南帮助投资组合评估和提高其快速交付创新业务解决方案的能力。它要求它们测量流程、成果和能力。此外，随着每个投资组合采用LPM实践，EPM可以利用透明的投资组合成果和数据，以市场所需的速度发展企业战略（图8）。此外，可以系统地识别和解决跨投资组合流程的中断，以实现关键倡议的持续价值交付。

图8. 跨投资组合成果影响企业战略

衡量企业投资组合战略主题和价值流KPI

EPM需要特别关注每个投资组合在实现其战略主题和整体企业投资组合战略主题方面的进展。他们还应该审查由关键绩效指标（KPI）捕获的投资组合绩效的持续衡量。这实现了学习，并帮助他们做出明智的决策，决定是继续一项倡议或战略，进行更改，还是完全取消它。

考虑以下来自现代汽车企业的示例（图9）。在这个示例中，已经衡量了每个投资组合在企业投资组合战略主题方面的进展。季度协调会议是典型的，用于审查战略主题及其相关的关键结果，庆祝成功，并解决问题以帮助每个投资组合前进。

图9. 跨投资组合衡量战略主题

此外，KPI是用于评估每个价值流及其相关解决方案表现如何的可量化指标。示例KPI可能包括收入增长、利润增长、市场份额、客户满意度、员工敬业度、产品质量、回头客率、创新率和上市时间。其中一些最好在每个投资组合中汇总，而另一些则是EPM选择衡量的特定KPI。

评估跨投资组合的价值流动

EPM负责改善所有投资组合的价值流动。以下是EPM如何开始衡量和改善流动的一些建议：通过价值流映射活动衡量每个投资组合的流动效率。使用合并数据识别和改进系统性的延迟和浪费区域；保持系统中有健康数量的活动项目。使用流动负载确保企业投资组合看板系统和相关的投资组合看板系统是可管理的，并确保能力和需求平衡；审查企业投资组合流动分布，以跟踪跨投资范围的资金分配，并使工作与短期和长期战略保持一致。投资组合流动文章包含更多关于加速流动以实现投资组合愿景和战略主题的指导，价值流映射技巧也可在Scrum认证培训中学习掌握。

组织投资组合

随着组织的增长，他们经常需要根据学习、不断变化的市场格局和新解决方案重新组织投资组合。拥有多个投资组合的企业通常定义它们以推进战略、加强流动并最小化成本。为了确定未来最大的变革机会，EPM必须首先了解当前的投资组合组合。随着更多SAFe投资组合的启动，该方法固有的透明度使其能够考虑随着时间的推移将价值流置于不同的投资组合中，以加速企业战略。

下面是围绕价值组织投资组合的几个示例。投资组合文章提供了关于每个示例的更多信息。注意：这是一个部分列表，旨在告知和启发组织投资组合的不同方式。较大的企业将混合和匹配这些方式以实现其组织目标。

• 业务单元投资组合——企业经常发现，他们的业务单元针对不同的市场格局追求不同的战略，使用不同的解决方案来提供相关的客户体验。在这些情况下，企业可能会创建特定于业务单元的投资组合。该投资组合包含运营业务和追求其战略所需的所有解决方案。
• 平台投资组合——较大的企业经常发现，各个业务单元在追求每个业务单元独特的战略时，依赖于相同的解决方案进行核心运营。在这些情况下，企业可能会创建一个负责运营和扩展核心平台的投资组合。
• 区域运营投资组合——全球企业经常发现，由于当地客户期望和竞争格局，不同的运营区域必须以不同的方式参与区域市场。在这些情况下，企业可能会将其母国地区交付和改进业务所需的所有解决方案放入单个投资组合，然后建立一组与单个国家或地理区域对齐的小型投资组合。
• 监管和风险投资组合——由于人类安全、国家安全、反垄断或内幕交易问题，一些企业经营高度监管的业务。在这些情况下，企业可能会创建包含共享监管背景的产品和服务解决方案的投资组合。
• 创新投资组合——较大的企业经常发现，创建与其先前成功业务有实质性不同的新业务模式具有挑战性。在这些情况下，企业通常会创建一个新的投资组合，为该新兴业务单元提供完整的解决方案集。

在整个企业中，可以利用这些投资组合设计的混合来以创新的方式创建流动。此外，随着EPM和投资组合负责人发现工作如何随时间真正流动，可以重组投资组合以限制跨投资组合重叠的需求。而这种动态组织调整能力，需要管理者具备系统的敏捷思维，可通过敏捷培训和企业管理培训的结合培训体系逐步培养。

业务敏捷性是在数字时代通过快速响应市场变化和新兴机遇，以创新性数字化业务解决方案参与竞争并蓬勃发展的能力。对传统企业而言，认识到成功如今取决于创造这些解决方案的能力，如同一次”警醒”甚至生存危机。即使对数字时代诞生的公司，未来成功也非必然。SAFe实践顾问（SPC）在组织内外开展工作，提供连接整个企业与业务敏捷性原则的新方法。这一关键角色回应了构建未来工作方式的迫切需求，而Scrum认证培训和敏捷培训是SPC掌握核心方法的重要途径。

为实现有意义且持久的变革，John P. Kotter指出利益相关者需要”足够强大的指导联盟”。此类联盟需要：能设定愿景、指明方向并扫除障碍的领导者；可实施具体流程变革的从业者、管理者和变革推动者；足够的组织公信力以推动变革；快速明智决策所需的专业知识。在采用SAFe的企业中，这些联盟需要经验丰富且经过培训的SPC，而企业管理培训能帮助SPC提升组织变革的统筹能力。

职责

作为知识型变革推动者，SPC在SAFe实施路线图描述13项关键行动中承担主要角色。他们还需超越路线图，作为专家和教练帮助组织实现业务敏捷性。这需要履行广泛职责，如图1所示。

图1. SAFe实践顾问职责

体现精益-敏捷思维

SPC引领跨业务部门和组织层级的变革对话。为保持公信力与有效性，他们必须具备专业知识和能力。此外，为激励他人行为改变，SPC需率先自我革新。必备的专业能力包括：

• 展现精益-敏捷思维 – 为帮助他人达成精益-敏捷思维，每位SPC必须率先垂范。这是每位SPC持续选择的旅程。SAFe SPC在日常互动中践行精益思维与敏捷宣言的价值观和原则。
• 践行SAFe核心价值观 – 通过体现尊重个体、协调一致、透明公开和持续改进，SPC展示共同价值体系并激励他人认同。SPC对践行核心价值观以身作则怀有个人责任感。
• 运用SAFe原则 – SPC内化SAFe原则，并懂得运用其发起和维持激励变革的对话。他们洞察阻碍敏捷性的问题，运用理解清晰传达指导行为与实践转型的原则。

引领变革

SPC深知实现变革愿景”必须完成的工作”。他们借助专为组织变革设计的SAFe培训与资产，传达业务需求、紧迫性和变革愿景。SPC懂得在正确时机运用恰当资产，将SAFe广度作为实施工具包。变革活动包括：

• 传达变革愿景– SPC明白变革涉及微妙的交叉阶段。他们指导组织各层级团队，处理变革周期并在每个阶段传达愿景。为清晰有效沟通，SPC与企业领导者合作阐明前进路径并辅导领导者。当变革在组织内受阻时，SPC识别改进机会。
• 维护指导联盟– 随着转型推进，指导联盟的需求同步增长。SPC协助组织建立和发展LACE及价值管理办公室（VMO），并帮助甄选合适人选。SPC还鼓励这些群体的新兴成员成为SPC以全面理解转型。随着组织透明度提升，各层级将涌现新领导者。SPC识别并将其纳入不断扩展的互联指导联盟网络（参见扩展指南文章示例）。
• 维护转型待办列表– 组织内SPC、LACE和VMO协同维护转型待办列表，就改进流动、提升技能、发展基于角色的能力、培育思维模式等所需变革达成共同愿景。团队、火车、LACE和组合均有本地改进项。SPC通过积极沟通和能量促进协同，避免自满和局部优化。SPC鼓励实践实验以把握当下机遇，运用SAFe原则、价值观和精益思维保持实验关联性。
• 启动示范实践社区（CoP）– 随着SPC社区在支持组织中成长，他们将协同识别优势。SPC常组建实践社区共享知识并相互支持。SPC还协助创建和增强其他CoP，营造协作环境以提升组织解决问题、学习发展和保留顶尖人才的能力，这一过程可结合敏捷培训中的社区建设方法提升效果。

实施SAFe

实施路线图协助SPC完成引领变革所需的战术步骤，确保每个”下一步”执行时兼顾仍需关注的先前变革。SPC以初次实施的热忱对待每次部署，激励新参与者。

在此过程中，SPC应用并常主导SAFe实施路线图的关键行动：

• 触及临界点 – 传达业务需求、紧迫性和变革愿景。
• 创建精益-敏捷卓越中心（LACE） – SPC协助LACE构建并执行转型待办列表。
• 培训高管、经理与领导者 – 推广新概念并提供定向概览培训，特别为转型相关的所有总监、经理、高管和领导者在Leading SAFe课程中授课。
• 数字时代的领导力 – SPC为领导者、经理和利益相关者主持”数字时代领导力”系列模块，并在模块结束后持续帮助领导者形成和实践新行为方法。
• 围绕价值进行组织 – 协同利益相关者理解价值流动，SPC引导识别运营价值流、开发价值流、ART和组合，寻找最具启动潜力的部分。
• 制定实施计划 – SPC参与制定推广计划，传达即将到来的变革并建立度量指标。
• 准备ART启动 – SPC协助LACE规划并准备ART启动。他们辅导领导层并引导创建新敏捷团队。他们还培训或协调高管、领导者、敏捷团队及专业角色（如产品负责人、产品经理、Scrum主管和发布火车工程师）的培训。同时评估并优化启动准备度和待办列表。
• 培训团队并启动ART – SPC常直接规划执行”快速启动”或其他推广策略。他们培训或协调团队培训，并参与PI规划和检视与调整等关键初始活动。SPC协助确定ART启动日期及ART与团队事件日历。
• 指导ART执行 – SPC辅导领导者和利益相关者构建维护愿景、路线图和待办列表。他们辅导团队、产品负责人、产品经理、架构师和RTE。引导从项目到产品的转变，聚焦作为敏捷产品交付组成部分的客户中心性与设计思维。参与教练同步和系统演示，主持检视与调整并跟进改进项。协助团队建立DevOps文化思维、持续交付流水线、基础设施及相关内建质量实践。
• 启动更多ART与价值流 – SPC赋能新变革推动者以提升组织能力，支持新价值流、启动更多ART并扩展LACE覆盖范围。传达进展并突出早期成果。
• 优化组合 – 当精益-敏捷实践形成势头，SPC可在组合层级推广优化实践，包括组合愿景、参与式预算的精益预算及精益组合管理。
• 加速推进 – 企业的SAFe旅程不因启动火车或采用精益组合管理而结束。SPC精通精益企业的七大能力及其对实现业务敏捷性的贡献。

辅导价值流动

SPC在帮助组织全员理解价值流动及如何实现无中断的价值流（SAFe原则6）中发挥关键作用。有效辅导流动要求组织内SPC：

• 引导价值流映射 – SPC主持价值流映射工作，识别并维护完整价值流或局部的整体流动效率。运用团队数据、工具及改进项成果维护价值流图，优化持续交付流水线。
• 建立看板系统 – SPC帮助团队理解运用看板板和贯穿SAFe各层级的实践，包括敏捷团队、ART、解决方案火车和组合。SPC协助建立看板系统连接，使战略能贯穿执行。
• 度量流动 – SPC理解流动指标及其如何与能力和成果指标协同促进企业流动改进。帮助组织运用定量定性数据验证流动改进并指导后续步骤。SPC促成领导层定期参与改进活动，并适度分权决策使知识工作者能直接优化工作环境实现更快流动，同时鼓励全程透明度量。
• 应用流动加速器 – SPC运用流动加速器在组织情境中提升流动绩效。根据应用层级（团队流动、ART流动、解决方案火车流动、组合流动）差异显著调整应用方式。SPC在各类SAFe事件、工作坊和培训中持续获得加速流动的机会。
• 培育流动思维 – SPC积极参与关于系统流动改进的社区讨论。他们以事实为基础展开对话，实现流动可视化并解决障碍。流动可视化是多层面工作，需广泛运用流动指标、信息辐射源、工具及围绕流动问题的有效沟通。SPC促进领导者与团队互动，建立健康可见度及现场管理。在组织见证流动改进带来的价值交付成果时，SPC持续通过1对1及小组讨论在工坊和事件外培育流动思维。逐步建立共享流动心智模型，助力组织完成流动优化与转型之旅。

加速业务敏捷性

SPC推动长期业务敏捷性愿景。他们通过整体系统优化（而非局部过度优化）实现业务敏捷性。此外，SPC度量培育各层级能力，开展工作坊，创造培训机会，并协助新SPC履职。SPC感知并创造机会：

• 扩展业务敏捷性– 组织可能在特定业务部门（通常是IT、信息物理或数字部门）启动SAFe旅程。SPC发现整个组织应用敏捷模式的机会，培育新的转型领域。借鉴业务与技术模式并识别分享新模式，助力企业实现全面业务敏捷性。
• 度量与发展核心能力– SPC通过度量与发展各层级核心能力帮助企业实现业务敏捷性。他们与其他SPC协同，在企业上下左右创造系统性改进浪潮。辅导能力提升，使他人成熟以简化规模化伴生的固有复杂性。
• 扩展SPC人才池– 随着SPC人才池扩大，资深SPC协助新SPC建立信心和理解，同时支持转型。为在转型中实现组织各层敏捷领导力的广度深度，SPC必须赋能其他SPC，可通过组织Scrum培训分享实战经验。
• 维持变革– 根据需要，SPC持续主持价值流与ART识别工作坊和讨论，围绕价值进行组织与重组。与组织内精益-敏捷领导者合作，持续提升指导联盟和变革流程。参与并主持支持业务增长的活动，包括设计思维工作坊、史诗编写、故事映射等。在维护初始敏捷实验基础的同时，帮助在新领域应用测试学习技术。

上述战术项将构成新的工作方式，节奏与协同成为习惯。SPC持续保持工作方式的意义和流动导向。SPC懂得倾听组织中预示成长停滞和改进受阻的信号，利用这些信号跨解决方案凝聚人员，建立透明度以推动对话从单纯跟踪工作转向战略决策。SPC还需意识这是基于价值观和原则的体系，事件和活动必须保持激活状态。新思维需由SPC及更广泛的指导联盟锚定于组织思维模式和文化中。否则团队和领导者终将回归旧有行为模式。组织中担任SPC的多个角色对持续参与至关重要。

需要多少SPC

初看上述职责似乎艰巨。单凭一名SPC无法独立完成，因为SPC的知识技能不能局限于规模化企业中的少数人。例如，辅导高管的SPC通常不同于辅导敏捷团队技术实践的SPC。相反，新兴精益-敏捷业务中的众多领导者必须掌握这些独特的新能力。这意味着多数企业需要多名SPC（约每100名从业者配5+名）来推动和维持实施，而批量培养SPC可通过标准化的Scrum认证培训结合定制化的企业管理培训实现高效落地。