编辑导语：在职场上，常常都会遇到业务多变的时候，业务多变导致的需求变更案例也有许多，本篇文章作者分享了具体的案例分享，讲述了具体的解决方法等，一起来学习一下吧。
这次分享上个月两个和需求变更相关的案例。
案例一
1. 背景
公司的经营模式是同款先卖一个颜色，根据销售情况再开发其它颜色。以往没有一套推荐颜色的算法，今年算法确定了，但问题是推荐范围外的款式是否允许业务自由开发新颜色。如允许可能会浪费不必要的时间开发无用款，如不允许可能会扼杀由于算法不准漏掉的好款。
2. 问题
推荐范围外款式的卡控方法。
3. 需求变更经过
- 第一个版本：推荐范围外用配置性的阈值控制，每个部门，超过范围的开发比例不同；
- 第二个版本：不控制，任业务自由开发，跑一段时间再讨论卡控方式；
- 第三个版本：放弃方法一的严控，需要额外开发的走管理部门审核。
总结：整个管控方案先紧——后松——后紧， 不仅仅影响产品方案设计、排期，还有上下游其它业务部门的信息同步。
4. 原因
- 早期没有识别业务人员特性（火车头部门，负责制定业务方向，但对接经历上需求确定后的变化频率较高）；
- 作为需求分析人员未及早深入参与共识（被其它项目干扰）；
- 未及早拉通下游业务人员共同讨论（短时间内对业务理解无法深入，需要专家参与，不便做独立决策）。
5. 应对措施建议
- 通过业务人员的历史决策判断需求变更的风险几率；
- 多项目并行时需要和上级协同优先级和处理预期（另外一个很大的话题，并且在敏捷性项目中，很难提前预判，不容易实现）；
- 项目变更巨大、影响范围广，要提前识别引入专家一起决策，先发制人把多种处理方式的利弊及早和管理部门沟通清楚。
案例2
1. 背景
原本商品的外型标准审核流程中，如商品和预期不符，需要重新走审核流程。但为了业务快速推动，如果是小的改动，曾经做过一个小功能，允许先审核通过但是做标记，通过寄送新的拍照样品重新确认后取消标记。
2. 问题
样品变更后，由于系统上审核状态已通过，关闭了上游重新上传新图片的入口。业务希望在打标记后，允许上游更改商品图片，否则商品查看和仓库收货都会有问题。
3. 需求分析
- 了解背景—— 业务通常只会提出需求，不讲背景，先确认需求目的是否解决业务背景；
- 进一步明确业务真实的目的？—— 是解决商品查看和仓库收货标准不统一的问题；
- 识别需求能否实现业务目标？——可以解决；
- 此需求会否带来其它问题？—— 会。
①商品审核状态需要重启，会和原本审核状态通过矛盾；
②增加新图片上传，内部是否需要新的审核流–需要审图员重新复核。
4. 识别本需求产生的真正原因—— 业务对于便捷功能的滥用
5. 最终实际处理方法
沟通的两种方式：我说和他说。
- 原本打算说服业务状态重启的状态矛盾，但是业务不能理解，只提问状态需要重启就重启，不能理解对于全流程冗余的影响。沟通陷在我一直在解释，而他一直重复自己的需求的循环里。
- 改用让他说的方式。我假设开放功能带来的审核流和工作量增加，他回答是否能接受。后沟通后需求取消，通过规范和优化业务对于不完全合格品标签的打标标准，在整体审核环节即让商家重新传图。
总结
本次仅分享经验教训，不能算典型的成功方法和案例。
作为流程人员，虽无法代替关键业务决策，但需要尽早识别各种方案利弊和长期影响，在评审前做好方案确认，减少来回变更。
如岗位职能有限，可拉动项目经理，请求专家或者上级介入，给予合理的评估。在沟通过程中减少和业务的对抗感，要能从对方角度出发争取全局利益最大化的方案。
理论容易，难在实践、难在平衡，多思考、多分享、多讨论。
本文由 @我叫更更 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议