Scrum框架下的风险管理合作伙伴认证资质关注我们

传统的项目管理PMBOK中对风险管理有详细的描述。我们不禁要问Scrum框架下如何应对风险？与传统项目的风险管理有什么不同？PMP教材就像一部宝典，涵盖了所有风险的方方面面，但你会发现Scrum中没有专门的文字论述风险管理。

我查了一下对风险的定义：风险是那些可能发生的事件或者条件，如果它确实发生了，则它的发生会对项目产生有害的或者负面的影响。另一方面，风险是一种概率事件，可能发生也可能不发生。风险管理（Risk Management）试图使由于意外事件而导致项目失败的概率降到最小。

因为我没有考过PMP，激发了我的好奇心学习，特地请教我们Scrum学员中对PMP的理论知识熟知的专家，看到下面这张图。

看来项目的风险无处不在，我们撇开传统项目管理中定义的五花八门风险类型，拍拍脑袋想想，大体不外乎这几个方面：

1.业务 (business)风险，是不是做正确的事情，是否真正满足客户的需求，解决痛点，交付的项目或产品有无真正的商业价值，发布的产品能否在市场上卖出去？商业模式是不是有一定的利润空间等等。2.技术风险，技术方案的可行性，有无大的瓶颈和突破性的技术难点，包括获取知识的能力和渠道。3.社交风险，做事情最终靠的是人和团队，每个人不是孤立的，他们做事的方法，流程，工具，理念和工作方式，价值观和团队文化有无冲突。这群人靠不靠谱，能不能干成事情。4.成本预算和时间的风险管控。预算有上限，市场有时间点。

作为外聘敏捷教练，我在协助企业转型，帮助企业实施敏捷项目的时候，也见证了项目的风险以及不同的应对方式带来的不同结果（下图）。正好在讨论Scrum是如何对风险管理之前，我们先看看传统项目管理和Scrum敏捷项目管理有什么不同。

计划驱动 VS 目标驱动

不管是传统的项目管理还是敏捷项目管理，我认为最初设定项目的目标应该是一致的，比如解决客户什么样的问题和痛点。我们打造的产品和服务(以项目形式交付的成果物)，目的是为人们的生活和周围的环境产生正面的影响(positive impact)，让人们的生活更加美好。项目初衷是目标导向的，只不过驱动项目的方式有区别，一个是计划（合同）驱动，线性的流程。传统项目的风险管理是围绕项目的预定计划和路径，保证不要偏离，减少变量和变数的引入，有项目经理来把控，拿捏，并一路负责到底。项目经理手中有好多工具和方法论可以使用。项目通常分两个阶段，计划+执行，因为我们花大量时间制定了详细而周全的计划，我们假设计划是完美的，项目执行阶段要严格按计划和流程走，如果偏离就会有风险，要求PM的执行能力要特别强。核心思想是任何变数都会带来风险，我们要规避它，包括需求变更。项目经理对整体的风险管控负责，而风险清单内容由项目经理指定处理及负责人员，项目经理统筹分配人员、机制等后续响应措施。

敏捷项目是价值驱动，非线性流程。Scrum框架本身承认不确定性的存在，Scrum重在积极应对避免风险发生，而不是风险发生了如何去处理和救火。比如如何积极应对下面这些情况：人员的流动，太多的需求变更，不切实际的计划和进度，业务知识不充分，强加于项目的外部决策，不清晰的需求，新技术的探索和使用，等等。

 

项目管理的职责 — 全知全能一人 VS Scrum三个角色分担

传统项目管理依赖一个全知全能的PM。关于传统项目管理方式，下面的文字来自学员May Liu：“我来说一下我的感受哦，PMP教材就像个词典，涵盖了所有risk的方法论，你做过一些项目后去跟这个理论对比，觉得是那么回事，可是你反过来拿着理论去应用，又发现他解决不了真正的问题。关于项目风险承担问题，要看项目规模。一般大的global 推广的项目，依托于咨询公司的规模，会有一个特别的部门专门制定项目管理的method & tool，根据行业会有个risk checking list，任何一个稍具规模的项目都会派一个专人来参与项目的管控，所以项目经理承担的责任会弱化，同时也避免了PM个人能力以及稳定性这方面的风险，因为一个项目最难以臆测的就是参与项目的人，核心人员的变动或者重大错误都是对任何contingency plan的考验。另外还会有个专门的OCM-org change mgmt team来专门负责项目的change mgmt，比如role mapping，training等，比如企业会通过ERP项目做组织架构调整，不缺乏政治目的，因此牵涉到很多stakeholder的利益，这都是risk。另外，大的项目前期要投入大量时间做调研，因为初衷就是要一步到位，做模版然后roll out，实现集团统一，流程统一，report统一。前期花费了大量时间做的POC，真正到了实施阶段又要面临业务的变更、组织架构变的引起的Sponsor职位的变动等等，PM即便力挽狂澜顶着schedule做下去了（偷工减料技术债一堆），结果往往都是技术上线系统ready，业务部门不买账。咨询公司拿不到尾款PM是最终的背锅侠。对于中小型项目，PM就要承担所有职责，从立项，选人（更糟糕的是人被事先安排好了或者固定的IT团队），做plan，确认scope，定期向下review deliverable，向上汇报进展，所有risk都压在PM头上，budget不够，项目成员能力不足，项目内部矛盾，不同系统开发团队踢皮球，隐瞒bug，虚假汇报进展，全部依赖一个全知全能的PM，即便很有经验的PM手里心里有那么一份risk checking list，往往墨菲定律应验，做了backup的risk都没发生，发生的risk都意想不到。所以往往做了一大半的项目被迫终止，投入都白费”。 传统项目的风险管理是一个全知全能的项目经理，这样的人或许存在，大多情况下是假想的。在Scrum中，项目经理的职责被拆分分解了，一个迭代的小项目有开发团队自我管理跟踪和报告。比如站会，Sprint计划会议，Scrum白板，Sprint的燃尽图都是团队的沟通工具和沟通机制。开发团队成员集体对迭代的计划执行，进度和进展，成果物负责。SM负责Scrum的落地和实施，同时帮助团队移除障碍，PO对整个产品的方向负责，包括业务价值，正确的需求，产品的定位，在发布的时间，成本，范围之间平衡和取舍。所以传统项目经理的职责由Scrum 中三个角色一起分担了。 

 

领导力关注点 — PM控制命令式 VS SM服务型领导

项目经理的领导风格大多是，分配任务式或控制命令式。Scrum的领导力则有不同的关注点，SM关注人和团队 (process and people leadership), 属于服务型的领导力；团队是稳定的，团队= “产品”，SM教练团队提升整体效能；PO关注在产品和业务领导力（product and business leadership）, 团队重心在技术的领导力上（tech leadership），Scrum是共享的领导力(shared leadership)， 团队的对产品的激情被激发，潜能被释放，责任感倍增。

我们定义了4个方面的风险，业务 (business)风险；技术风险；社交风险；成本和时间的风险；同时讨论了传统项目和敏捷项目本质上的不同。不难得出结论： “Scrum是内嵌的风险驱动管理框架”。

 

Scrum本身是一个反馈的机制。越是存在风险的项目或产品，越应该尝试Scrum来管理，Scrum给了我们一个非常精益的框架来管理风险，或者说Scrum就是一个内嵌的管理风险的敏捷方法。为什么？

1.Scrum的核心是基于围绕目标的实验性过程控制（empirical process control）理论

三大支柱是本质，检视，调整，透明。一个Sprint 就是一个戴明环(PDCA), Scrum是一个基于反馈的框架，所有的Scrum的事件设计都是围绕这三大支柱展开。比如说站会是围绕Sprint的目标，团队成员相互检视前一天的工作和障碍，暴露问题，同时调整我们当天的工作计划。Scrum一次只做一次迭代的计划，站会是计划会议的延伸, 站会也是planning的活动。Scrum的三个工件，产品待办列表，Sprint待办列表，产品增量都是为了增加灵活性，拥抱外界变化，在一定的边界条件下基于不同层次的反馈来调整计划。这个自我调整的机制就是为了积极主动减少各种风险的自适应系统, Scrum在计划和做计划之间找到平衡点。Scrum本身通过一系列的活动和输出来规避和评估风险。

2.Scrum的三个拆分降低复杂性（业务风险+技术风险）

Scrum中的三个拆分降低了风险和不确定性。第一个拆分，需求的拆分和排序, 通过产品待办列表的梳理（PBR）的活动来实现，持续的对话(PO+Dev team+干系人ST), 识别风险和依赖（团队外的依赖）， 技术难点探索(spike)，需求的渐进明细。第二个拆分，拆分时间轴为Sprint, 一次只做一个Sprint的计划，一个迭代就是一个小的项目。Sprint项目若失败，最多也就两周，风险是可控的，而且我们不会等到项目结束再开总结会，而是在每个Sprint的回顾会上照镜子，如何小步改进和避免犯同样的错误。第三个拆分把大团队拆成小团队，降低人的复杂性和风险，小团队是跨职能和自组织，鼓励T型人才的培育。一句话“Small Everything is a key”。

3.Scrum的价值驱动的具体实践（业务风险）

价值体现在非常具体化和可操作性上：以客户和用户为中心的用户画像和用户故事需求对话来识别正确的人做正确的事情；产品愿景和路线图，发布目标和迭代目及每天的工作目标为导向来规划调整不同阶段的工作；以需求排优先级和关注最大化团队工作的价值；准确的确认每个需求的业务范围和验收标准来保证把事情做对。

4.Scrum比传统项目风险管理更加可控（团队社交风险）

风险控制在一个迭代，控制在每天的工作规划，控制在每天每个团队成员的工作任务，障碍不超过24小时曝光，团队集体对一个迭代的项目交付结果负责。集体问责制，因为授权给团队来拉动（pull system）在一个时间盒内的工作范围，权力（Power）和责任是对等的，授权同时也要问责。每个人都有责任把自己的工作内容和风险透明出来，可视化的任务板和Sprint燃尽图都可以让大家看到一个迭代的进度和进展。如果早期引入工程实践的技术，反馈的周期会更短，甚至分秒之间，比如结对编程和暴徒式编程（mob programming）。

5. 持续的发布计划 (成本和时间的风险的评估)

你会注意到，Scrum中没有专门的对发布计划会议的描述。Scrum认为发布计划是持续的活动，不是一次性的拍板。所以每次迭代评审会结束后，PO拿到了上个迭代交付的实际数据，以此来更新发布燃尽图，调整和更新发布计划。和干系人沟通管理预期，与干系人谈判和沟通，在范围，时间，和成本之间做出取舍和妥协。要么追加预算，砍范围，或延长发布时间， 这些活动是持续和动态的监控，也是为了响应变化，降低风险，根据当前的项目进度和进展，调整产品发布策略，以做出最经济和明智的商业决定。

小结一下，Scrum框架风险管理的机制：

（1）风险管理不是依赖于：一个假想的天才项目经理，也不是靠繁琐的流程和厚厚的文档来操控，避免纸上谈兵。

（2）风险管理依靠的是每一个角色的明确分工和职责，依靠透明性包括可视化的机制，依靠集体智慧。大家都在一条船上，目标是一致的。

（3）Scrum的内核就是风险管理反馈机制，即检视，调整，透明三大支柱。它是内嵌的风险驱动管理框架，风险管理融入到Scrum的骨子里的，其自身具备了对风险的免疫能力。

（4）Scrum不是银弹，Scrum也不是万能的，不能保证项目或产品成功。但至少可以尽可能早暴露问题，避免传统项目面临的晚期才发现的灾难性失败。

（5）PMP好用的风险评估和管理工具可在Scrum的框架下结合使用，Scrum设计的本意就是不完整的，要求我们容纳和填充好的实践。理解Scrum框架对风险管理的设计机理，便于我们建立“预防大于治疗的理念，并根植于团队的内心，在实践中通过Scrum框架的应用，团队会更有信心持续不断的交付产品增量，那么项目的成功率也会大大增加。Scrum是一个指导帮助我们团队持续反馈和学习改进，降低风险，落地马上见效的框架。

作者：Jim Wang王军 

写于2020年7月20日疫情期间 

致谢学员May Liu，Jenny Tao, 柏霖，Tu Wei，Emma Ye对传统项目管理PMP知识和经验分享。

参考资料：

（1）CSM 课件  

（2）“30天敏捷软件开发”

（3）Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin.