进行系统性的需求风险识别，其核心在于将风险管理，从一种被动的、滞后的“救火”活动，转变为一种主动的、前置的、贯穿需求全生命周期的“排雷”工程。一套全面、有效的风险识别体系，其构建必须依赖于五大关键支柱：进行全面的干系人分析以发现期望风险、采用结构化的分析技术审视需求内部风险、评估需求的技术与资源可行性风险、考察市场与外部环境的变化风险、以及组织跨职能的协同评审与头脑风暴。
其中，组织跨职能的协同评审与头脑风暴，是发现那些隐藏在单一视角下的“认知盲区”风险的最有效手段。这意味着，需求风险的识别，绝不能是产品经理或项目经理的“闭门造车”。必须通过定期的、结构化的评审会议，将业务、产品、设计、研发、测试等所有关键角色都聚集在一起。在这个“集体智慧”的碰撞场中，一个在产品经理看来天经地义的需求，可能会被开发人员识别出其背后的“技术可行性”风险，或被测试人员识别出其“可测试性”的风险。
一、为何要“识别”：从“被动救火”到“主动排雷”
在项目管理的战场上，一个“未被识别”的风险，就是一颗“尚未爆炸”的地雷。它悄无声息地潜伏在你的项目路径之上，你不知道它在哪里，也不知道它何时会爆炸。而当它最终爆炸时（通常是在项目最紧张、最关键的阶段），其结果，必然是计划的混乱、资源的紧急抽调、团队的疲于奔命，以及最终的进度延误和预算超支。
1. “风险”与“问题”的根本区别
我们必须首先从概念上，清晰地辨析“风险”（Risk）与“问题”（Issue）的区别：
风险，是一个尚未发生的、潜在的、不确定的负面事件。
问题，则是一个已经发生的、现实的、确定的负面事件。
需求风险识别的根本目的，就是在“风险”尚处于“潜在”阶段时，就将其“识别”出来，并为其制定应对预案，从而避免其最终演变为一个棘手的“问题”。这是一种**从“被动救火”到“主动排雷”**的、极其重要的管理思维的转变。
2. 识别的巨大价值
根据项目管理协会（PMI）的调查，不成熟的风险管理，是导致项目失败的最主要原因之一。主动进行需求风险识别，能够带来巨大的、可量化的价值：
提升项目的可预测性：一个充分识别了其内在风险的项目，远比一个看似“一帆风顺”但却对风险一无所知的项目，更能获得干系人的信任。
降低“意外”的冲击：通过预先制定应对计划，当风险真的发生时，团队能够从容不迫地、按“剧本”进行处置，而不是陷入手忙脚乱的恐慌之中。
优化资源配置：识别出的高风险需求，可以被赋予更高的关注度，并为其预留出必要的管理储备（时间和预算）。
正如军事家孙子在《孙子兵法》中所言：“无恃其不来，恃吾有以待也。” 需求风险识别，正是为我们的项目，构建起这种“有以待也”的、从容的底气。
二、风险的“藏身之处”：需求风险的分类
要成为一名优秀的“排雷手”，我们首先需要知道，“地雷”通常都埋在哪里。需求风险，根据其性质和来源，可以被系统性地，归纳为以下几个主要类别。
1. 范围与定义类风险 这类风险，源于需求“自身”的描述和定义过程中的不完善。
模糊性风险：需求中包含了大量“友好的”、“快速的”、“灵活的”等主观的、无法被客观检验的词汇。
不完整性风险：需求只描述了“成功”的场景（快乐路径），而完全忽略了对各种“异常”和“边界”情况的定义。
不稳定性风险：需求本身，处于一个极易发生变化的领域，或者干系人本身就举棋不定，导致了极高的“范围蔓延”风险。
2. 干系人相关风险 这类风险，源于项目“人”的因素。
期望不一致风险：两个或多个关键干系人，对同一个需求，存在着根本性的、相互矛盾的期望。
参与度不足风险：某个负有关键信息输入或决策责任的干系人，因为时间或意愿问题，始终无法被有效地“卷入”到需求过程中来。
“隐形”干系人风险：在项目初期，遗漏了某个重要的干系人，导致其需求，在项目后期，才以一种“颠覆性”的姿态出现。
3. 技术与实现类风险 这类风险，源于将“需求”转化为“技术解决方案”的过程。
技术可行性风险：需求的实现，依赖于某项团队从未接触过的、不成熟的新技术，或者需要与一个极其陈旧、文档缺失的“祖传”系统进行集成。
非功能性需求（NFR）冲突风险：例如，极致的“安全性”需求，与极致的“性能”需求之间，天然地存在着权衡和冲突。
高耦合性与依赖风险：一个需求的实现，高度依赖于另一个团队、或另一个项目的交付物，而对方的进度，存在巨大的不确定性。
4. 外部环境风险 这类风险，源于项目所处的、更宏观的商业和市场环境。
市场变化风险：一个强大的竞争对手，可能会在我们之前，发布一个类似的功能，使得我们正在开发的需求，瞬间变得“毫无意义”。
法律与合规风险：一个新的行业法规或数据隐私政策的出台，可能会让我们整个需求的设计基础，都需要被重新审视。
三、识别技术一：基于“文档”的分析
这类技术，侧重于通过对现有项目文档和历史数据的、深入的、结构化的分析，来静态地识别风险。
1. 需求文档的“健康检查” 产品或项目经理，可以制定一份“需求质量检查清单”，并用它，来系统性地，审视每一个重要的需求文档。这份清单，应包含一系列的拷问：
这个需求的价值主张，是否清晰？
它的验收标准，是否是具体的、可测试的？
它是否包含了对“异常”和“边界”情况的考虑？
它的描述中，是否存在任何模糊的、有歧义的词汇？
2. 假设与约束分析 任何一个项目计划，其背后，都隐藏着一系列的“假设”和“约束”。例如，我们“假设”某个第三方API是稳定的，我们“假设”核心团队成员不会离职。 一个强大的风险识别技术，就是将所有这些隐含的“假设”，都明确地、书面化地，列出来。然后，针对每一个假设，进行一次“思想实验”：“如果这个假设不成立，将会发生什么？” 每一个“回答”，都是一个需要被管理的、潜在的风险。
3. 风险管理中的根本原因分析（RCA） 回顾组织内部，过去类似项目的“失败案例”或“复盘报告”，是一个极其宝贵的风险识别输入源。通过对过去的“问题”，进行根本原因分析（Root Cause Analysis），我们常常能识别出那些反复出现的、具有共性的“系统性”需求风险。
四、识别技术二：基于“人”的互动
如果说文档分析是“静态”的，那么，基于“人”的互动，则是“动态”的、能够激发集体智慧的风险识别方式。
1. 头脑风暴（Brainstorming） 这是最经典、也最常用的风险识别技术。要组织一次成功的风险头脑风暴会，需要注意：
参与者要“跨职能”：必须邀请来自产品、设计、研发、测试、运维等所有不同领域的代表。
氛围要“安全”：主持人必须在会议开始时，就强调“没有愚蠢的想法”，鼓励所有人，都将自己能想到的、哪怕是最微小的担忧，都讲出来。
过程要“发散-收敛”：先进行无限制的“发散”思考，将所有风险点，都写在便签上。然后，再进行“收敛”，对所有风险点，进行归类、去重和初步的评估。
2. 德尔菲技术（Delphi Technique） 这是一种匿名的、多轮的、专家驱动的风险识别方法。它通过匿名的问卷，来征询一组专家（可以是内部的，也可以是外部的）的意见，然后，将所有专家的意见，进行汇总和整理，并再次，以匿名的方式，分发给所有专家，让他们参考他人的意见，来修正自己的判断。这个过程，会重复几轮，直至最终，专家的意见，趋于“收敛”和“共识”。德尔菲技术，能够有效地，避免因为“权威效应”或“从众心理”，而对风险判断产生的干扰。
3. 访谈（Interviews） 与那些经验丰富的、曾经做过类似项目的领域专家（Subject Matter Experts, SME）或资深工程师，进行一对一的深度访谈，常常能挖掘出大量在群体会议中，难以被发现的、深层次的技术风险和“暗坑”。
五、在流程与工具中“落地”
风险识别，绝不能是一次性的、在项目开始前的“运动式”活动。它必须被内建到项目的日常流程和工具中，成为一种“持续的习惯”。
1. 将风险识别“仪式化”
在“待办列表梳理会”中：在评审每一个新的、重要的用户故事时，都应增加一个固定的议题：“要实现这个故事，我们预见到哪些主要的风险？”
在“迭代回顾会”中：在回顾上一个迭代时，一个关键的问题是：“在上一个迭代中，有哪些‘意外’发生了？这些‘意外’，是否本可以，在事前，被我们作为‘风险’而识别出来？”
2. 风险登记册（Risk Register）：风险的“身份证” 所有被识别出的风险，都必须被立即地、正式地，记录在一个统一的、共享的《风险登记册》中。这份登记册，是项目风险管理的“中央数据库”。每一个被记录的风险，都应包含：
唯一的ID和清晰的描述。
初步的“概率”和“影响”评估。
指定的“风险责任人”（Risk Owner）。
初步的“应对策略”。
3. 工具的角色 一个专业的项目管理平台，能够将风险的识别和管理，变得更加高效和透明。
在像 Worktile 这样的通用协作平台中，团队可以创建一个专门的“风险管理”看板，将每一个风险，都作为一个“任务卡片”来进行可视化的跟踪，其状态可以是“已识别”、“分析中”、“应对中”、“已关闭”等。在 PingCode 这样的研发管理平台中，其优势在于“关联性”。你可以创建一个“风险”类型的工作项，并将其，直接地、清晰地，链接到那些受其影响的“用户故事”或“史诗”之上。这使得，当开发人员在处理一个需求时，他能够立刻看到，所有与之相关的、需要被特别关注的“风险地雷”，从而在技术方案的设计上，就提前进行规避。
常见问答 (FAQ)
Q1: 风险识别是不是做得越早越好？
A1: 是的。风险识别，遵循“成本最小化”原则。在项目的生命周期中，越早识别出一个风险，我们用以应对它的“时间窗口”就越大，可供选择的“应对方案”就越多，而应对的“成本”，也就越低。
Q2: 识别出的风险太多了，感觉无法管理，怎么办？
A2: 识别，只是第一步。在识别之后，必须立即进行“风险评估”，即，从“概率”和“影响”两个维度，对所有风险，进行一次“定性或定量的分析”，并计算出其“风险值”。然后，我们只需要，将管理和监控的精力，聚焦在那些风险值最高的、排名前20%的“关键风险”之上即可。
Q3: 敏捷开发强调拥抱不确定性，还需要做这么正式的风险识别吗？
A3: 需要。敏捷，拥抱的是“商业和需求”上的不确定性，并通过短迭代和快反馈，来管理这种不确定性。但对于那些“技术”和“执行”上的、可被预见的风险，敏捷同样强调，要通过“风险驱动的待办列表排序”（Risk-driven Backlog）等方式，来进行主动的、前置的管理。
Q4: 谁应该负责主导需求风险的识别工作？
A4: 项目经理或产品负责人，是整个风险识别过程的“主导者”和“组织者”。但他/她绝不应是唯一的“思考者”。最高效的风险识别，必然是整个跨职能团队，以及相关的外部专家，共同参与、贡献智慧的结果。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：百晓生，转转请注明出处：https://www.chuangxiangniao.com/p/640278.html
微信扫一扫 
支付宝扫一扫 
