确认没有法务风险之后，小帅却又得知老大有了最新指示，需求变更在所难免。几乎所有的百度项目都遭遇过需求变更，或者有潜在的需求风险。为了应对这一类最典型的风险，我们准备了离别钩。

关键词

“你用离别钩，只不过为了要相聚。”

演绎

管理风险，只不过为了将风险发生的概率将到最低，或者风险发生时损失降到最少。

需求风险是最典型的风险，针对最典型的风险，使用80:20原则，重点跟进，要么把风险的收益最大化要么就把风险的损失最小化。这就是我们使用离别钩的目的。

可能存在需求风险的情形

1. 团队新成员较多、研发流程不熟悉

2. 项目涉及人员较多，跨团队跨体系（HTTPS项目）

3. 项目处于探索阶段，中间需求随着市场反应变化频繁

4. 项目依赖较多，双方接口、数据格式、进度等需要及时同步沟通

有效的应对方案和注意点

1. 需求（用户故事）的价值难以评估的情况

2. 产品架构复杂，依赖关系复杂的情况

3. 业务知识缺乏而业务流程长导致学习成本高的情况

4. 组织架构调整后，项目目标需要重新对齐的情况

5. 新产品上线后，随着运营宣传的加强，新需求太多的情况

6. 项目后期发现需求遗漏的情况

7. 项目后期需求变更的情况

8 .项目安全相关的需求不受重视的情况

9. 需求来源多，协调优先级困难的情况

10. 跨团队合作中，需求沟通不及时（需求提交时间晚）的情况

11. 需求太多，人力不足的情况

12. 需求来源多，且需求间可能冲突的情况

13. 业务知识不充分，难以提出有效需求的情况

14. 对非功能性需求不重视的情况

15. 开发团队同时进行多个项目，遇到高优需求插入的情况

16. 不同角色对产品用户体验要求不同的情况

17. 多端需求同步的情况

接下来进入一个真实的项目

1.特点如下：

• 产品发展阶段：方向探索

• 项目组织结构：跨体系

• 产品包含的端：PC、SDK

• 项目周期：长（2+2年）
  

• 项目分类：商业，平台类

• 研发模式：迭代

2.背景描述：

• 项目一期，二期，三期集中在产品的功能需求开发和产品的稳定性提升方面，四期的目标是达到商用试运行的质量要求。

3.风险识别：

• 识别阶段：商用试运行计划的制定过程中发现客户关注的几个重要需求没有梳理。

• 触发条件：正式商用的付费客户使用产品必须具备这些功能。

• 发生概率（高、中、低）：高
  

• 影响评估（高、中、低）：高

4.应对措施（避免、缓解、转移）：

• 避免

• 从竞品进行学习；跟内部成熟产品学习并复用架构；成立专项小组快速开发；协调RD高工进行架构评审（保证兼容性和灵活性）。目前是保障架构设计满足商用试运行期间的重要功能可以灵活快速上线。
  
  

总结提炼：需求梳理时，对于商业用户的分析不到位，为避免类似问题，需要加强用户分析和StoryMapping加以解决。

他山之石，可以攻玉。小帅赶紧针对需求变更和PM讨论了起来。

博客转自：《项目风险管理七种武器之离别钩丨百度敏捷教练 》

本文转自SanMaoSpace博客园博客，原文链接：http://www.cnblogs.com/SanMaoSpace/p/5126674.html，如需转载请自行联系原作者