1、OKRs助力团队与战略对齐，摆脱传统IT服务模式

传统组织通常以有限的方式采纳敏捷，她们将敏捷视为一种方法，用来更快更好地交付由业务部门确定的战略项目。

敏捷通常是在IT服务部门内实施的。但这并不能引发组织结构的重新设计，也没有让团队得到管理层的充分授权去执行业务战略。

产品负责人（PO），本应是被充分授权的产品经理，作为连接业务机会和技术团队的桥梁，实际上大多仍然只是“代理人”或敏捷项目经理。

然而，OKRs提供了一个改变这一现状的机会。让我们来看一个例子：

公司OKR

• 目标：提高客户对健身房预订的满意度。
• 关键结果1：75%的预订可以由客户自行完成。
• 关键结果2：客户能找到80%及以上他们喜欢的课程的可预约时间。

以下团队OKR则没有意义：

• 业务目标（运营）：为客户提供一个可以自行预订的应用程序。
• 技术团队OKR：为健身房客户实施一个应用程序。

相反，在定义和对齐团队OKRs时，运营和技术团队应该就共同的OKRs达成一致，以服务于公司的OKRs。

或者，他们也可以共同定义与公司OKRs一致的举措或任务。

这种定义技术团队工作的方式使他们摆脱了根据”业务需求“来交付技术的IT服务模式。

2、OKRs为产品负责人提供问题的清晰度和结局方向

当产品负责人收到一个功能或项目的请求时，他们通常得不到创建这个请求的完整战略背景。

例如，请求是“我们需要一个用于网站的AI聊天机器人。”大家都知道它应该可以减少对支持部门的呼叫，但没人知道它如何与公司战略或其他部门对齐。

如果公司今年的目标是：

• 目标1：将客户服务时间减少30%。
• 目标2：更好地了解事件的来源，以提高客户满意度。

那么产品负责人就会得到非常有价值的信息来了解这个聊天机器人应该解决的业务问题。

这将使他们能够与支持和工程部门互动，找到使支持更高效的最佳方式，而不会失去这些部门之间的协调。

换句话说，OKRs可以帮产品负责人更清晰地了解需要解决的问题以及提供解决方案可能的最佳方向。

3、OKRs促进与利益相关者的透明度及沟通

组织中透明度的定义可以是“共享理解”。

OKRs促进所有团队理解大家对他们有何期望，以及他们应如何与其他团队合作，以服务于公司期望的结果。

没有OKRs，沟通可能会变得支离破碎，每个团队应该做什么以及他们应该如何合作的共享愿景也会变得割裂。

有了OKRs，规划共享工作和每个人的职责将变得简单。在前面的工作中：

• 目标1：将客户服务时间减少30%。
• 目标2：更好地了解事件的来源，以提高客户满意度。

支持部门、工程和开发团队理解共同目标，并确定每个部门可以采取的行动，以及他们之间的依赖关系。

OKRs有频繁的检查会议，例如每周或每两周一次。这使得部门很难采取不一致的行动或延迟。优先级和联合协调得到改善。

4、OKRs促进以结果为导向的团队工作方法并简化层级

产品团队可能对划分Sprint工作的优先级有不同的标准。

最简单的Scrum认为，所有优先级划分都由产品负责人完成。但这：

• 使这个专业人员超负荷，
• 限制了其他团队成员对划分标准的贡献，
• 可能会挫败其他成员的积极性，觉得他们只是“遵循产品负责人的命令”。

OKRs鼓励整个团队参与定义目标和关键结果，以及共同规划Sprint工作并执行它们。

尽管保留了OKR斗士（类似于Scrum Master）和OKR负责人（类似于产品负责人）等角色，但使用OKRs有利于促进团队自我管理和以结果为导向的工作方法。

5、OKRs赋予团队自主权，质疑非战略性请求

要让敏捷团队在对业务战略产生真正影响，面临的挑战之一就是不断收到来自业务部门的各种请求。

虽然这些请求对于提出它们的人来说可能很重要，但它们也可能与组织的战略不一致。这是一个问题，因为团队的时间是一种稀缺资源。

而OKRs使产品负责人更容易专注于战略目标。继续使用前面的OKRs示例：

• 目标1：将客户服务时间减少30%。
• 目标2：更好地了解事件的来源，以提高客户满意度。

如果我们收到一个业务请求“为其他国家的客户服务添加多语言选项”，产品负责人可以评估这个请求与战略OKRs不一致。

这并不意味着它必须被自动拒绝。在时间允许的情况下，仍然可以在交付OKRs的同时满足这个请求。但这提供了一个明确的标准来区分战略性和非战略性请求。

6、OKRs改进学习，使规划与战略对齐

最后，使用OKRs为敏捷或Scrum团队带来的另一个优势是，它们加强了学习和实证主义，以定义：

• 如何设定产品和冲刺目标。
• 如何规划实现这些目标的工作。

OKR方法，像Scrum一样，需要通过回顾和总结来提高团队的内部效率和与改善外部利益相关者的关系。

Scrum回顾会议更频繁，例如，如果我们有2周的Sprint工作，同时OKR实行季度考核，我们可以为每个OKR周期回顾会议设定6个Sprint回顾会议。

这有助于提升团队在OKR周期中的效率，让我们有更多机会纠正团队的操作。

另一方面，虽然Scrum回顾会议可以专注于技术或流程改进，但OKR回顾会议专门关注改进团队的工作成果。

这些OKR改进可以带来想法，例如：

• 更深入地了解客户以更好地识别需求。
• 改善产品战略，更好地规划功能优先级。
• 从为客户和业务提供价值的角度改善指标。

7、反思和行动

在本文中，您已经看到了OKRs如何提高敏捷和Scrum团队工作的有效性，以及一起使用这两个模型的优势，例如：

• OKRs帮助团队与战略对齐，使他们可以摆脱传统IT服务模式。
• OKRs帮助PO更清晰地了解问题以及提供解决方案的可能最佳方向。
• OKRs促进与利益相关者的透明度和沟通。
• OKRs赋予团队自主权，允许他们挑战不符合战略的请求。
• OKRs促进以结果为导向的团队工作方法并简化层级。
• OKRs改进学习和实证主义，增强战略和战术。

课程优势

• 国内最强敏捷管理讲师亲自讲授；
• 讲师具备Scrum联盟认证培训师CST资格(Certified Scrum Trainer)；
• 打开敏捷思路，启发性强；
• 精辟比较敏捷和传统项目管理；
• 项目实用效果驱动；
• 多元培训方式和丰富手段，生动有趣；
• 互动性高，中西文化结合；
• 项目实战演练＋多个动手游戏练习；
• 有问必答

授课顾问

Jacky Shen 申健, Scrum联盟CST-认证Scrum培训师、Scrum联盟CTC-认证敏捷教练及评审委员会成员，全球首位双料认证Scrum导师。专业教练CPCP，认证LeSS大规模敏捷专家，CSD认证课程授权讲师，管理3.0认证讲师。他在跨国企业（包括诺基亚西门子通信和渣打银行等）从事10多年研发和管理工作，涉及电信、金融、互联网等领域，擅长移动产品整体解决方案，面向服务架构分析和嵌入式系统开发等。2007年开始实战敏捷开发，历任过工程师、研发经理、敏捷教练等职务。对大型组织(500人以上)的大规模敏捷转型，以及各种工程实践的落地运用具有丰富的经验。他感兴趣于结合教练技术等软技能来帮助组织提升领导力和导入工程实践，从而提升产品开发的效果与质量。他常年担任全国敏捷社区组织者、评委和嘉宾。 培训和咨询辅导过的客户包括：浙江移动、平安保险、招商银行、思科、oTMS致新物流、凡普金科、CVT视源科技、唯品会VIP、IGT国际游戏技术、晨星MorningStar、埃森哲Accenture、惠普HP、赛门铁克Symantec、南大通用数据观、果壳网Guoker、趣加游戏FunPlus等

课程大纲

VUCA时代已经进化为AI时代，响应变化的能力成为任何有远见的个人和组织的竞争利器。敏捷是目前最有效的解决复杂项目中面对的挑战的新思维与方法，以及快速学习的利器。这些挑战包括需求的不确定性和渐进性、市场的时刻变化、技术的快速更新、计划赶不上变化、团队过度劳累及缺乏动力与激情、沟通的失效、质量问题及技术债务的累积、项目严重超时超支、无法交付用户及客户真正需要的产品等等。

这是一个2天的敏捷项目管理强化集训课程，详细阐述Scrum框架的所有元素，以及Scrum Master／敏捷项目教练，项目团队及利益相关人如何运用轻巧的Scrum敏捷框架及相关的敏捷实践在频繁及限时的迭代中快速地交付及持续验证潜在的可交运产品或项目成果。结合最新AIGC提示词工程技巧，从团队管理和个人能力两个方面提高组织的响应力和一致性。

随着AI和机器学习技术的飞速发展，Scrum团队将获得更先进、精准的洞察力。

1. **提升自动化水平**：通过自动化日常任务和决策流程，Scrum团队能够将更多时间用于战略性和创造性的工作。分析历史数据以确定影响力高的事项，洞察分析团队绩效能力，识别模式和趋势以改进未来的Sprint，根据团队能力和依赖关系建议优先级调整
2. **增强沟通与协作**：AI驱动的聊天机器人和虚拟助手将大大改善团队成员与利益相关者之间的沟通与协作。识别依赖关系和潜在风险，为用户故事和验收标准提出改进建议，创建“完成定义”和验收测试
3. **推动创新**：持续的研究和实验将带来更多创新和高效的方法，头脑风暴进行创意生成，从原始想法自动起草用户故事，模拟Persona，识别定义不清或模糊的用户故事，促进持续的待办事项管理以保持关注和目标一致等

行业专家预测，通过这些AI驱动的提升，Scrum团队的生产力到2030年将提高10到100倍，实现事半功倍的效果。

课程收益

– 身心松弛

– 敏捷思维即学习力

– 让AI成为团队伙伴，打造一只铁军

– 提高组织灵活度和一致性，让业务敏捷起来

– 考取国际证书，更好找工作

关键学习目标

• 什么是敏捷；
• 敏捷究竟想应对什么问题和机会；
• 产品价值思维对比项目管理思维；
• 敏捷思维与具体落地实践Scrum之间的关系；
• Scrum组织框架的亮点及框架要素；
• 迭代化增量式的价值创造及交付；
• Scrum中的角色、责任、流程划分；
• 可视化看板追踪进展和暴露障碍；
• 共创式的团队融合与加速成长对于业务增长的作用；
• AIGC大模型最新发展概述
• AIGC提示词工程和写作初体验
• 用AI辅助工具提升“非技术团队“的战斗力
• 用一手咨询案例分析实施敏捷转型的经验教训；
• 对敏捷需求/用户故事和内建质量的探讨；
• Scrum Master角色作为教练式领导者；

目标受众

– （任何规模的）团队管理者

– 敏捷从业者，包括敏捷教练及Scrum团队成员

– 创新创业领导者

证书及其他

课程结束后完成注册手续时，每位学员获得Scrum Alliance颁发的Certified Scrum Master证书及2年的联盟会员资格，同时获得PMI的PDU学分及ACP Contact Hours。课程结束后学员将获得课程电子版材料。

报名咨询及获取详细课程大纲：

Tel: 021-34753688

Email: Service@UPerform.CN

整个世界的全球化、自动化、各类监管合规要求、7×24小时的流动性和各种颠覆性变化极大地影响了我们的工作和生活的方方面面。领导者们无法仅仅依赖于过去的成功模式，在当前时代的环境中有效运作。在这个具有高度复杂性、不确定性和快速变化的时代，敏捷领导力是具有更高的适应性、更好的赋能、更高的有效性，及更有影响力的领导方式。

规模化敏捷框架似乎已成为组织通常采用的一种“简单”的解决方案，但无法解决组织中有关人的问题，而且也未能达成预期的成果。低效的流程和实践并非是组织的核心问题，这些只是更系统性的挑战所产生的症状，而这更系统性的挑战就是低效的领导力。

敏捷领导力工作坊会为所有领导者提供新的灵感，提高自我认知，找到关注焦点，并提供相应指导，帮助每个人探索提高领导力有效性和提高组织有效性的属于他们自己的独特道路。

我们致力于培养更优秀的领导者！

那些寻求提高组织敏捷性的领导者们，请看看镜子中的自己。组织的情况是其领导者们的思维模式和行为模式的映射。

我们并不向领导者们讲授敏捷框架的细节。

我们讲授敏捷领导力以激活并发展敏捷工作方式， 从而提升业务成效！

所有的领导者都在塑造文化。虽然高层领导者的影响范围更广，但一线领导者能更直接地塑造员工文化。我们致力于打造领导力，也就是说，我们致力于培养所有人的能力，以提高他们在做的每件事中的影响力和有效性，无论他们做事的方式是执行、领导或教练。

90% 的领导者都没有发挥出他们的潜力。这并不是因为他们没有努力，而是因为他们并没有意识到他们的潜力。我们为领导者打开一扇新的大门，使他们走上一条提高自我认知，提高调适性和有效性的不同道路。成为正在帮助自己和组织转型的那 10% 的领导者中的一员！

课程收益

理解 VUCA 时代企业与领导者面临的变化与挑战

建立自我认知，开启敏捷领导者意识进化的旅程

识别自己的领导力风格，逐步培养敏捷领导力

理解敏捷团队的形态，打造高绩效的敏捷团队

获得国际Scrum Alliance颁发的CAL-1认证证书，及16个SEU学分

受邀加入优普丰专属的高阶敏捷学友群，及私董会交流活动

目标受众

任何面临下列疑问或挑战的人士

如何应对快速变化的外部市场环境

如何打造高绩效的敏捷团队

如何领导年轻人为主体的团队如何带领团队

开创新方法、探索新技能

如何增强领导能力，提升领导思维

本课程适合企业内的中高层管理者，如董事长、CxO、总经理、HR总监、部门经理、条线经理、转型负责人、敏捷教练等。（行业不限）

本课程并不适合普通团队成员，参加者需要具备带领至少10人以上团队的管理经验。

课程优势

全程采用视觉化引导方式授课。

注重敏捷思维模式的培养，兼顾大量敏捷实践。

采用游戏、视频、练习、讨论、模拟、复盘等多元教学方式。

互动性高，注重学员体验。

课程中随时为学员答疑解惑。

由国际认证敏捷领导力导师（CAL Educator）授课

课程大纲

课程讲师

倾向于单独做决策的PO，会把注意力放在我方的解决方案上，而不是关注客户的问题。因此，在团队中与团队成员就产品目标、产品待办列表进行对齐与讨论，是PO带领降低产品风险的关键策略。这也是Scrum的内置制衡机制，我们也可以看到现在市场上对于产品运营模型的关注是越来越多。

PO并不只是管理产品待办列表，而是创造透明一致性的参与者环境

根据Scrum指南，我们可以看到描述了产品负责人的工作如下：

• 从Scrum团队的工作中最大化产品的价值。
• 明确、建设、沟通该产品目标。
• 管理产品待办列表，即使部分委托他人，也要保持最终负责。
• 与利益干系人沟通，并作为代表澄清产品待办列表中的需求。
• 确保产品待办列表是透明的、可见的，并且被团队所理解。
• 对产品待办列表条目进行排序。
• 为Sprint制定目标。
• 若Sprint目标变得过时，PO有权中止Sprint。

大多数PO实践过程中的失败原因，往往是源于对产品待办列表管理方面的误解，这是PO责任的核心。特别是不太成功的PO，经常未能与团队成员、利益干系人沟通。从客户的角度出发，最大化Scrum团队的工作价值，同时在给定的约束条件下为组织的利润做出贡献，不仅仅是项目管理技能的问题，也不是处理产品需求文档或保持Jira更新的问题。

因此，成功的PO在处理产品待办列表上花费的时间较少，而更多地投入到产品探索中，特别是创造所有参与者之间的一致性。对他们来说，产品待办列表是手段，而不是工件存在的目的。

相反，成功的PO花费时间创建一个透明的系统，让他们能够从所有来源识别潜在有价值的想法，不懈地沟通“为什么”和与开发人员合作“做什么”。

产品待办列表和梳理细化的反模式

我们经常在产品待办列表，及其梳理细化中，发现许多PO的反模式（失败原因）：

• 存储想法：PO将产品待办列表作为想法和需求的存储库。
• 兼职的PO：PO不是每天都在产品待办事项列表上工作。
• 复制粘贴PO：PO通过将从利益干系人那里收到的需求文档分解成更小的块来创建产品待办列表条目。
• 主导型PO：PO创建产品待办事项列表项时，不仅提供“为什么”，还提供了“怎么做”和“做什么”。
• 代理优先级：会给某单个利益干系人、利益相关者委员会，在产品待办列表中优先排序他的内容。
• 100%提前：Scrum团队预先创建了一个涵盖整个项目或产品的待办列表。
• 超大型：产品待办列表包含的条目，超过了Scrum团队在三到六个Sprint内可以交付的数量。
• 过时问题：产品待办列表包含过去几周或更长时间内，不被触及（提及）的条目内容。
• 全部详细和估算：所有产品待办列表条目都被完全详细地进行描述和估算。
• 基于组件的项：产品待办列表条目是基于组件水平分割，而不是基于端到端功能的垂直分割。
• 缺少验收标准：有些产品待办列表条目需要额外的验收标准，但没有列出它们。
• 不超过标题：产品待办列表包含的条目，仅包含了标题。
• 用户故事作者：PO在创建产品待办列表条目时，前期投入了太多时间，使它们过于详细。
• 没有研究：产品待办列表中很少有甚至没有，利用Spike、Sprint进行研究和学习的任务。
• 涉及Scrum团队——为什么：PO没有让整个Scrum团队参与产品待办列表细化过程。

Sprint计划的反模式

Sprint计划的反模式

PO反模式（失败原因）列表中的第二大领域，是Sprint计划本身：

• 我们为什么而战？：PO无法将即将到来的Sprint的业务目标与产品目标和整体产品愿景对齐。
• 没有业务目标，没有Sprint目标，只是随机事项：PO提出的方向类似于随机任务的组合，没有目标方向。
• 未完成的业务：上一个Sprint中未完成的用户故事和其他任务未经讨论就流入新的Sprint。
• 最后一刻变化：PO试图在最后一刻加入一些未经细化的产品待办列表条目。
• 输出焦点：PO推动开发人员承担比他们实际能处理的更多任务。

Sprint的反模式

另一个容易出现PO反模式（失败原因）的领域是Sprint冲刺：

• 缺席PO：PO在Sprint的大部分时间里缺席，无法回答开发人员的问题。
• 坚持任务的PO：PO一旦产品待办列表条目成为Sprint待办列表的一部分，就无法放手（丢弃）。
• 不灵活的PO：PO不灵活地调整验收标准。
• 延迟PO：PO没有在Sprint待办列表项完成后立即提供反馈。
• Sprint填充：开发人员提前完成了Sprint目标，PO强烈推动他们接受产品待办列表中的新工作以填补“空白”。
• 未经协商取消Sprint：PO未经与Scrum团队协商就取消Sprint。
• 不取消Sprint：PO不取消Sprint，但其Sprint目标不再可实现或已过时。

每日Scrum的反模式

我们观察到，与其他Scrum事件相比，每日Scrum对PO反模式的抵抗力较强，但仍然容易有以下问题：

• 分配：PO直接向团队成员分配任务。
• 额外工作：PO甚至其他利益干系人试图在每日Scrum期间，引入新工作至当前Sprint。

Sprint评审反模式

最后，还有Sprint评审。尽管这是PO、利益干系人、开发人员改善合作并共同确定产品下一步方向的绝佳机会，但某些PO还是没有领会到这一点：

• 自私的PO：PO向利益干系人展示“他们”的成就。
• PO的“接受”：PO在Sprint评审中“接受”开发人员认为“完成”的产品待办列表条目。
• 不易接近的PO：PO不接受利益干系人或开发人员的反馈。

小结

在Scrum模型中，产品负责人角色是模型中最具挑战性的角色，是价值创造的关键，因为他们决定Scrum团队的下一步方向。幸好的是，即使在具有挑战性的产品负责人角色中，总有改进的空间。这份产品负责人反模式列表可以作为成长和发展的起点。

若你还观察到了哪些不在列表中的产品负责人PO反模式？可与我们联系并分享。

任何受产品结果影响并对其成功感兴趣的人都被视为利益相关者。
Scrum 团队利益相关者的示例可能包括：
客户——产品的用户和购买者
内部利益相关者——公司管理层和其他组织，如人力资源/人才管理、合规、财务等。
合作伙伴——供应商、供应商和其他业务合作伙伴
影响者- 外部影响者，例如贸易组织、媒体或行业分析师
与利益相关者合作是任何产品开发成功的核心。只有他们才能提供必要的反馈，以确保产品满足他们的需求和期望。

Scrum 中利益相关者的重要性

Scrum 的核心原则是 Scrum 团队快速、频繁地接收利益相关者的反馈，以便检查和调整其工作。整个 Scrum 团队负责利益相关者的协作，而不仅仅是产品负责人的责任。 Scrum 提供了许多支持 Scrum 团队与关键利益相关者协作的元素：
Sprint Review – 此 Scrum 活动是 Scrum 团队的一次工作会议，旨在向利益相关者寻求反馈和指导
产品目标——这个具体的、可衡量的目标帮助 Scrum 团队和利益相关者了解他们是否在实现产品愿景方面取得了进展
产品待办事项列表- 这个 Scrum 工件为 Scrum 团队和利益相关者提供了一种方法，以推动对实现产品目标和交付产品必须做什么达成共识
增量- Scrum 团队致力于提供产品增量，供利益相关者在 Sprint 评审中进行评审
这些元素被内置到框架中，为冲刺期间的利益相关者互动提供正式的机会。然而，这些不应被视为与利益相关者互动的唯一机会。鼓励 Scrum 团队经常与利益相关者互动。

识别并了解主要利益相关者

虽然了解 Scrum 团队的所有利益相关者可能是谁很重要，但并非所有利益相关者都必须以相同的方式对待。 Scrum 团队应该以适当的方式与利益相关者互动，以获得他们所需的反馈。例如，一些利益相关者应该使用 Scrum 工件和 Scrum 事件定期与 Scrum 团队互动，但其他利益相关者可能会分散注意力。所有利益相关者都很重要，但只有关键利益相关者被邀请参与 Scrum 活动和工件。
Scrum 团队可以通过以下不同的方式来尝试了解他们的主要利益相关者是谁以及如何与他们互动：
参与利益相关者映射活动，以更好地了解他们的利益相关者是谁
创建利益相关者参与方法，在正确的时间让正确的人参与进来，以最大限度地提高产品的价值

学习和使用技术来更好地了解客户和客户的需求


利益相关者参与的常见挑战

以下是 Scrum 团队在与利益相关者互动时面临的一些常见挑战以及克服这些挑战的方法：

利益相关者没有来或充分参与冲刺评审

如何克服这一挑战
频繁、迭代的利益相关者反馈是 Scrum 的关键部分。此反馈有助于：
将创造客户价值的理念放在 Scrum 团队的首要位置
验证 Scrum 团队对用户需求所做的假设以及他们在 Sprint 期间所做的任何权衡
通过尽早且经常发现问题来降低风险
限制 Scrum 团队在尝试解决客户问题时走入错误方向的可能性
当利益相关者不参与 Sprint 评审时，整个 Scrum 团队，尤其是产品负责人，应该请求利益相关者的意见，以改进产品。

利益相关者在与 Scrum 团队合作时不了解自己的角色和职责

如何克服这一挑战
如果是这种情况，请帮助利益相关者认识到他们在向市场提供更好的产品方面所发挥的重要性，从而帮助他们提高对 Scrum 及其实证性质的理解。同时，Scrum 团队需要明白，Sprint 评审并不是他们获得利益相关者意见的唯一时间。他们可以根据需要参与和学习，以帮助完善产品待办事项列表项目并捕获更详细的期望。在 Scrum 团队和利益相关者之间建立更牢固的关系有助于推动长期协作。至少对于前几次 Sprint 评审，首先要解释 Sprint 评审的目标以及每个人在其中扮演的重要角色。

利益相关者要求在产品待办事项列表中添加或排序更高的 PBI

如何克服这一挑战
产品负责人负责产品待办事项管理，包括订购产品待办事项 (PBI)。将这种责任集中在一个人身上可以增加注意力，简化决策，并增加考虑最有价值的反馈而不是最有影响力的利益相关者的想法的可能性。

Scrum 将这种责任委托给产品负责人，而产品负责人有责任根据需要反击强有力的利益相关者。说“不”可能很困难，但在某些情况下是必要的。这种对优先级的分歧也为产品负责人提供了一个机会，可以围绕建议如何支持产品目标进行对话。当利益相关者毫不妥协并坚持认为他们的建议就是客户想要的时，产品负责人必须更多地了解利益相关者坚持的根源，并自己确定该建议是否有价值。

利益相关者要求提供具体的发布日期以及届时将包含的功能列表

如何克服这一挑战
利益相关者渴望收到产品并想知道何时可以期待它，这并不奇怪。然而，当使用经验过程解决复杂问题时，我们会迭代地构建解决方案，一路学习，并且不知道何时能完成。我们根本还没有得到所有的答案！也就是说，通过提醒利益相关者 Scrum 专注于尽早且经常地交付客户价值，具有明确定义的目标，并为他们提供在 Sprint 评审期间检查进度的机会，可以帮助他们感到更放心。

此外，还可以通过共享预测和产品路线图来帮助他们可视化所取得的进展。必须明确的是，Scrum 团队唯一能提供的就是估计，因为他们不知道在工作时可能会遇到什么问题或反馈。

(全系列6篇完结）

SAFe是目前国际上最流行的规模化敏捷方法，将敏捷实践从团队级有效扩展到敏捷发布火车级乃至企业级；SAFe也是一套开放的精益-敏捷知识体系，基于客户的实践与反馈来快速迭代完善并吸收新的卓越实践。

本课程由SAFe官方授权，基于SAFe 6.0的认证课程，目的就是培养组织的规模化敏捷领导者。

课程由SAFe授权认证讲师SPC授课，学员完成课程的学习，并通过考试后，可获得权威SAFe Agilist证书（SA认证）。

课程中，将学习如何将精益敏捷的核心原则协同一致的应用于大型产品开发及企业整体运作中，如何通过敏捷发布火车来执行和发布价值，如何建立精益投资组合管理，如何在企业层面领导精益-敏捷变革，从而帮助产品与企业实现经济视角的成功。

课程收益

系统性学习如何将精益敏捷的核心原则协同一致的应用于大型产品开发及企业整体运作中；通过敏捷发布火车来执行和发布价值，如何建立精益投资组合管理；如何在企业层面领导精益-敏捷变革，从而帮助产品与企业实现经济视角的成功。

授课过程中结合游戏化、以引导思考为主，充分运用课堂空间与现场学员互动，结合实践案例、现场练习，生动有趣的氛围中更有效地掌握规模化敏捷的精髓。

完成课程的学习，并通过考试后，可获得权威SAFe Agilist证书（SA认证）。

加入优普丰“AI·U学友会”，与学友一起交流成长，探索更多职业/事业可能性。

课程对象

决策层和领导者、经理、董事、首席信息官和副总裁；

开发，QA和基础设施管理；项目总监、项目经理；

产品线经理、产品经理；

投资组合经理，项目管理办公室和流程负责人；

企业，系统和解决方案架构师；

以及任何其他的期望了解SAFe的人士。

课程大纲

然而，许多组织是以“项目”为工作单位。大家对于“项目”这个词的含义理解也有着极大的分歧，通常来说，是认为它是指为实现某个目标而进行的某段时间内的一系列活动。而企业的运营却是长期存在的（排除企业倒闭等原因不考虑），正是因为这样的特性，使得我们在应用“项目”来管理企业的事务时，引发了许多短期上满足项目目标，但长期上有损企业利益的问题。

热爱敏捷的人通常对项目该词没有太多好感。这就像公牛对红布的反应一样。这一点从那些充满激情的敏捷实践者的坚定言辞中便可见一斑，比如“敏捷关注的是产品，而非项目”或“在敏捷中，项目没有立足之地”之类的言论。

然而，许多组织是以“项目”为工作单位。大家对于“项目”这个词的含义理解也有着极大的分歧，通常来说，是认为它是指为实现某个目标而进行的某段时间内的一系列活动。而企业的运营却是长期存在的（排除企业倒闭等原因不考虑），正是因为这样的特性，使得我们在应用“项目”来管理企业的事务时，引发了许多短期上满足项目目标，但长期上有损企业利益的问题。

本期，我们将探讨长期以来都有争议的话题。“产品”还是“项目”，也许有人认为这只是概念名字的定义讨论，没有实际意义。但我们认为，用词本身是具有意义的，因为它总是在更广泛的上下文语境中被使用，我们真正需要讨论的是那些上下文前提的区别。这比单纯讨论敏捷到底是“产品”还是“项目”更具备现实意义。

什么是项目

在深入探讨这个讨论之前，我们首先需要明确“项目”的定义。在我们的工作中，我们注意到人们往往将项目定义为具备以下特征的长期的活动：

1）需要交付的范围

2）实现这一目标的预算

3）需要交付的日期都是固定的

4）项目只在结束时交付

5）可以永远持续下去。

美国项目管理学会（PMI）将项目定义为“为创造独特的产品、服务或成果而进行的临时性努力”。维基百科将其定义为“任何单独或协作进行的，可能涉及研究或设计，经过精心策划以实现特定目标的活动“。这两个定义都没有明确指出项目的范围、预算和截止日期，也没有明确指出项目仅在结束时交付或永久持续。因此从不同来源方来看，我们似乎在讨论不同的事物。

抛开正式的定义不谈，即便是最热衷项目管理的项目经理也会承认，对于项目所代表的复杂性，仅靠确定项目的预算、范围和交付日期来进行管理保障，未免过于乐观，甚至是天真的。事实证明，无论是PRINCE2还是PMI协会，都基于这样一个假设：项目代表了复杂的工作，具有不可预测性和风险性。因此，许多敏捷主义者对“项目”的定义似乎比通常意义上的更为极端，认为复杂工作根本不可预测，这使敏捷主义成为容易被”项目管理“攻击的假想对手。

项目和项目管理

因此，尽管项目与敏捷框架并不相互排斥，但它们的不确定性和风险的管理方式却往往不同。像PRINCE2和PMI这样的基于计划的方法更依赖于预先规划和治理来控制风险。而敏捷框架遵循的原则是，无论预先规划多少，都无法控制风险或以小而有价值的增量发布产品。敏捷将每个发布视为一个反馈循环来调整过程。敏捷框架更依赖于经验主义（从经验中学习），而像PRINCE2这样的基于计划的方法则更依赖于理性主义（通过推理学习）——这是两种根本不同的管理风险方法。

打破敏捷无法适用于项目管理的谬论

为了更好地讨论“产品”与“项目“的对比，我们还是从源头开始。再浏览一遍《Scrum Guide》，就能为我们在敏捷Scrum框架内理解项目提供一个有益的视角：

“每个Sprint都可以被视为一个不超过一个月的项目。与项目一样，Sprint也是用来完成某项任务的。”

《Scrum Guide》也明确提到了产品而非项目。其中提到的是产品负责人和产品待办事项列表，而不是项目负责人和项目待办事项列表。这样做有几个很好的理由：

• 产品更加有形。这使它们与向用户提供有价值的东西这一理念联系得更加紧密。
• 产品都有生命周期。没有人知道产品何时会达到成熟期，或者何时会被停产。这个周期可能很短，也可能很长。无论哪种情况，在产品生命周期中都需要进行很多调整。这就要求我们将长期思考与短期思考结合起来。如果我们现在走捷径，以后就得为此而付出代价。但同样地，我们也必须尽快交付一些东西以获取短期收益。

我们并不是说项目不会给用户带来价值，也不是鼓励走捷径。我们只是指出，“产品”这个词能引发更具长期建设性的讨论，因为它必然与用户、持续变化和价值等是息息相关的。

使用敏捷推进项目的技巧

所以，假设你发现自己身处一个充分应用”项目“的组织。其中一种策略是坚决主张从组织词典中剔除”项目“这个词。但一个更有效的策略是从现有资源出发，以支持实证主义的方式使其发挥作用。以下是我们喜欢采取的做法：

• 在产品待办事项列表上明确项目的范围，并在出现新见解时进行调整。
• 思考确保“项目”取得有价值且高质量成果所必需的条件，并将其纳入你的“必需完成”的事项中。
• 项目预算决定了产品待办事项列表中可以完成的工作量。当预算用尽，但继续推进可以带来更多价值时，可以在必要时适当地扩展待办列表的内容。
• 每个Sprint带来的成果增量都会作为里程碑交付给利益干系人，并实现一个关键的业务目标。如果需要，可以根据反馈来调整产品待办事项列表的内容。
• 产品负责人、Scrum Master和开发团队，对所有关于他们正在进行的“项目”（或项目的一部分）的决策拥有完全的授权。
• 将产品待办事项列表放在旁边，为你的项目创建一个路线图。这会有利于告诉我们事情发生的顺序和进展。
• 如果有项目管理办公室或指导委员会，与他们合作，来促进上述目标成为可能。
• 只要项目经理尊重产品负责人和Scrum Master的职责，他们可以成为敏捷团队的重要资产，可以帮助协调与利益干系人的关系，处理组织内部的政治问题，并消除障碍。

“作为敏捷团队的一员，项目经理可以成为一笔宝贵的财富。”

在进行上述工作时，你所进行的以上思考，将比反对使用“项目”一词更有成效。或者声称每个人都“需要采用产品思维，而不是项目思维”这种言论更有成效。如果你从现有情况出发，并以实证的方式开展工作，你会发现所有这些情况都会开始发生变化。

咬文嚼字很少能有效地促使人们切实地改变他们的行为

过去我们常犯一个错误，那就是开始纠正人们谈论工作的方式。每当有人提到“项目”时，我们就会纠正为“产品”。我们会用一种迂腐的口吻解释说，“我们在这里建造的是产品，而不是做项目”。但这真值得我们纠结不已吗？在我们看来，还有更多关键的对话、思考、讨论需要展开，比如：

• 我们如何确保利益干系人参与到项目中来？
• 我们如何利用每个Sprint来交付一个有形的成果——即增量——以便与利益干系人一起检查？
• 我们该如何开始消除那些阻碍我们前进的问题？

这些话题都很重要，并可能间接推动向更以产品为导向的方法转变。与其在强迫让他们出现在我们强调的地方（显然当前找不到有他们的身影），不如在他们目前所在的地方创造条件与他们相见。

咬文嚼字很少能有效地促使人们改变他们的行为，并对事物运作方式产生正确理解的。相反，过分纠结于人们已经习惯的表达方式，更有可能引发抵触情绪。这样做只会让对话陷入僵局，而非开启新的对话。

归根结底，持续进行透明、检视、调整的目的就在于此。

组织的使命宣言表达了组织的宗旨并定义了组织存在的原因。它重点关注组织今天的情况。
组织的愿景声明表达了公司的长期愿望以及未来希望实现的目标。它没有说明它将如何实现这一愿景。
组织中的高级管理人员通常负责制定组织的使命和愿景。这些驱动着组织的业务战略。

什么是商业战略？

业务战略是公司或组织如何实现其长期目标的计划。它概述并为组织为组织及其利益相关者创造价值而追求的战略举措提供指导。
业务战略由公司的使命和愿景决定，进而影响个人产品的愿景。组织根据从交付产品增量中收集的反馈来检查和调整其业务策略。

使命/愿景、业务战略、产品愿景和产品战略之间的关系
业务战略通常包括：
整个组织的战略目标和目标
组织的产品应瞄准的市场和客户
组织为其客户、员工和合作伙伴提供的价值主张
组织愿意为支持其目标而进行的投资
产品处于生命周期的阶段
组织中的高级管理人员通常负责制定组织的业务战略。业务战略的内容和格式因组织而异，并且高度依赖于环境。一些组织进行严格的规划，从而产生详细的信息。然而，其他组织似乎没有参与任何战略规划。拥有广泛产品组合的大型组织与规模较小、单一产品的公司的规划环境有很大不同。事实上，一家单一产品的公司可能不需要同时制定公司业务战略和产品战略。

Scrum 和业务策略

尽管 Scrum 指南中没有提到“业务策略”的概念，但它提供了帮助组织定义产品及其目标的重要背景。
 

使命/愿景、业务战略、产品愿景、产品战略和产品目标之间的关系
产品负责人使用业务策略作为其产品规划活动的指导。从业务战略出发，他们为公司产品组合中的每种产品制定产品愿景和产品战略。由此，他们设定了第一个产品目标，团队创建了一个产品待办事项列表来实现它。
制定业务战略是一个复杂的问题，需要采用实证方法。随着学到的知识越来越多，业务策略应该不断调整。理想情况下，业务战略应概述几个实验，以验证战略中所做的假设。例如，实验：
研究扁平化组织结构有助于创造价值的假设
验证新的细分市场是否值得投资
了解新技术的使用是否可行并值得必要的支出
敏捷的战略规划方法是通过提供明确的目标、边界和责任来支持产品团队的自我管理。这可以通过执行足够的业务战略规划来提供产品领导者做出决策和制定公司产品或产品组合所需的指导来实现。
 有用的工具
商业模型画布，一种促进业务或产品策略讨论的工具
Lean Canvas是另一个促进业务或产品策略讨论的工具，它使用了从精益创业社区借用的概念

循证管理 (EBM) 和业务战略

循证管理 (EBM) 是一种实证方法，可帮助组织持续改进客户成果、组织能力和业务成果。 EBM 的核心理念是，使用有意的实验和证据将使组织能够系统地提高绩效并根据更好的信息完善目标。

业务战略至少定义了组织的战略目标。如果战略目标如此崇高并且其实现要在未来进行，以至于组织需要近期目标来指导其决策，那么它可能会更进一步，并为组织定义中期目标。
当 Scrum 团队向客户交付产品、衡量结果，然后根据其产品目标评估结果时，组织就朝着其目标取得了进展。总的来说，所有团队在实现产品目标方面取得的进展应该使组织更接近实现其目标。如果没有，则应重新评估目标。
下图中显示的“实验循环”总体上代表了 Scrum 团队开发和交付有价值的产品增量的所有 Sprint。

影响业务策略的实验和反馈循环可能发生在组织内的多个层面。例如，它们可以位于：
组织层面。例如，从项目转向产品交付模式时，可能会有与组织结构相关的实验。结果可能会影响产品组合和产品
投资组合级别。例如，组织可能想要验证扩展到新市场是否是正确的做法。这些实验的结果可能会影响业务策略。
产品级别。 Scrum 团队定期进行实验，以了解他们的工作是否正在缩小客户满意度差距（例如，减少客户对安全问题的焦虑）。 Scrum 团队的发现和增量以及利益相关者的反馈和输入可能会影响业务战略并经常重新定义战略目标
这样，各个层面通过验证结果、持续反馈和市场变化不断连接并相互影响。

通过关注产品、产品组合和组织层面的未实现价值（潜力、机会、差距和期望结果），战略目标可能会更容易定义（或完善），此外，还拥有来自所有 4 个 EBM 关键价值的当前和相关数据各个产品的领域可能会增强组织的视角，从而影响业务战略和产品组合决策。
未实现价值 (UV)：潜在价值
当前价值 (CV)：今天交付的价值
创新能力 (A2I)：有效提供新功能以满足客户需求
上市时间 (T2M)：能够快速提供新功能以满足客户需求

引导能帮助到我什么？

有效的引导可以帮助一个团队或者团体，通过互动的方式来帮助他们创造意义的结果。

• 是否觉得团队缺乏良好的讨论气氛？是否每次讨论都是漫无目的、失焦、冗长、繁琐、毫无成果？
• 你的团队是否让你压力倍增，无法轻松自如地表达自己的想法？
• 团队会议是否经常只有少数人的发言，其他人变成沉默的大多数？
• 团队经常欠缺好的讨论方式来达成共识？

也许这个时候我们需要——    

• 一种技能——应用引导技能来帮助进行有意义和真实的对话；    
• 一个流程——创建并持续支持人们共同思考的流程，它简易却易上手；
• 一个角色——引导师；他利用引导的力量帮助个人、团队、组织进行有意义的对话，激发出团体的创造力。

这是一个Scrum联盟推出的为期两天的引导思维和引导技能的训练营，无论您是团队领导者， 团队工作者，不限于任何组织内组织，或是仅仅希望培养引导能力，以便更好地促进团队的互动协作，都能够从课程中得到学习和提升。两天课程中包含多场沉浸式的引导演练，通过演练，学员能够识别不同团队面临的不同问题，以及不同团队的背后诉求，能够识别团队动态，学习如何处理冲突，能够识别团队当前心理安全水平以及如何提高心理安全水平，等等。学员通过对一系列真实场景的模拟演练，逐步培养引导思维并提升引导技能，能够有效地促进团队进行更好的互动协作。

课程收益

在课程中通过一系列的练习、逐步体验引导的魅力。在真实场景的模拟演练环节，学员需要从客户访谈开始，理解客户面临的问题，设计整个工作坊，模拟引导演练，并进行自我反思及收集反馈。学习会议引导/团队讨论的基本思路、引导流程、设计方法；学习带领高效会议，在企业的战略、文化、变革、创新、团队协作、流程改进、工作复盘等关键领域如鱼得水。通过学习演练不仅收获理性的团队产出，还绽放了团队的智慧掌握「窍」开团队智慧、激发讨论、提高团队生产力、共创有意义结果的有效方式。学员们将组成学习小组，进行大量的小组讨论、共同设计工作坊、共同模拟演练，并共同进行自我反思。课程结束后将收获——

• 学习设计富有影响力的引导过程
• 探索引导者的心态、职责以及位置
• 培养引导思维、提升引导技能
• 进行现场沉浸式的引导案例演练
• 结束课程并通过考试可获得广受认可的国际Scrum联盟认证：CAF证书，成为专业引导师

课程受众

如果您符合以下任何一条：

• 想要成为有影响力引导师
• 期望精进引导软技能
• 想要通过引导技能发展职业生涯
• 希望能共创有效讨论结果的团队管理者、引导者或协调者
• 改变传统课堂教育，增进互动式体验形式
• 想在会议中发声却不知道如何介入并产生促进和影响的人
• 任何渴望快乐团队和高效讨论的人士不限于职场任何职能

课程大纲

Brenda（布老师）

换言之，我们可以在这过程中发现团队的成长和改进机会。

然而我们的工作范围不只是当前团队，更是应该包括整个组织。因此我们该与所负责的团队、利益干系人、以及支持他们的更上层结构（例如，他们的经理、领导）进行紧密合作，发挥出我们的最大影响力。

在这过程中，一种最常用的策略是，使用我们的直觉，如：

“我（敏捷教练）有一种预感，我们需要提高发布的频率。”

这可能是正确的，但直觉也可能充满了个人偏见、个人偏好、错误的想法等。直觉是系统1思维的典型例子，而系统2思维则是分析数据和仔细做出合理决策的过程。（系统1、系统2理论可参见丹尼尔·卡尼曼的《思考：快与慢》）。

所以我们的首推的方法是与系统2思维相结合。使用数据、基于证据的反馈和科学研究成果来提高团队和组织效能。

以下都是一些我们作为敏捷教练可以关注的行动项目：

1. 收集团队数据

• 邀请团队进行自我诊断、评估。
• 收集数据，例如“团队士气”、“价值聚焦点”、“利益干系人地图”、“发布频率”、“质量回顾会议”等约15个其他主题。
• 及时发现团队遇到的障碍、趋势，进行持续改进。

2. 收集多团队数据

• 邀请组织中的多个团队一起进行自我诊断、评估。
• 识别跨团队协作的方式、发现问题。
• 解决和处理更广泛的组织上的挑战。

3. 收集定性数据

• 收集包括团队成员、利益干系人、客户、支持者（领导、经理和教练）的观点。
• 一起分析数据，进行访谈，分享观察结果。
• 共同确定下一步改进措施。

**4. 利用科学的方法论 **

• 使用经过科学验证的敏捷团队效能模型进行诊断。
• 基于证据的反馈、学术研究的结论，帮助其进行改进。
• 学习同行的案例与研究，比较不同的主流敏捷扩展框架中的团队效能，以及多样性、冲突和心理安全如何影响敏捷团队。

我们坚信，如果敏捷教练、Scrum Master和其他敏捷实践者想要生存、产生更大影响并提供更多价值，他们应该使用更多的数据源，进行其他访谈，探索市场趋势。收集数据，汇集定性和科学洞察，并相信你的直觉。用它来制定改进行动和策略，解决团队和组织的挑战。并不要止步于此，持续帮助团队与组织优化。