业务多变导致的需求变更之反思——案例分享(二)

0 评论 821 浏览 1 收藏 7 分钟

编辑导语:在职场上,常常都会遇到业务多变的时候,业务多变导致的需求变更案例也有许多,本篇文章作者分享了具体的案例分享,讲述了具体的解决方法等,一起来学习一下吧。

这次分享上个月两个和“需求变更”相关的案例。

案例一

1. 背景

公司的经营模式是同款先卖一个颜色,根据销售情况再开发其它颜色。以往没有一套推荐颜色的算法,今年算法确定了,但问题是推荐范围外的款式是否允许业务自由开发新颜色。如允许可能会浪费不必要的时间开发无用款,如不允许可能会扼杀由于算法不准漏掉的好款。

2. 问题

推荐范围外款式的卡控方法。

3. 需求变更经过

  • 第一个版本:推荐范围外用配置性的阈值控制,每个部门,超过范围的开发比例不同;
  • 第二个版本:不控制,任业务自由开发,跑一段时间再讨论卡控方式;
  • 第三个版本:放弃方法一的严控,需要额外开发的走管理部门审核。

总结:整个管控方案先紧——后松——后紧, 不仅仅影响产品方案设计、排期,还有上下游其它业务部门的信息同步。

4. 原因

  • 早期没有识别业务人员特性(火车头部门,负责制定业务方向,但对接经历上需求确定后的变化频率较高);
  • 作为需求分析人员未及早深入参与共识(被其它项目干扰);
  • 未及早拉通下游业务人员共同讨论(短时间内对业务理解无法深入,需要专家参与,不便做独立决策)。

5. 应对措施建议

  1. 通过业务人员的历史决策判断需求变更的风险几率;
  2. 多项目并行时需要和上级协同优先级和处理预期(另外一个很大的话题,并且在敏捷性项目中,很难提前预判,不容易实现);
  3. 项目变更巨大、影响范围广,要提前识别引入专家一起决策,先发制人把多种处理方式的利弊及早和管理部门沟通清楚。

案例2

1. 背景

原本商品的外型标准审核流程中,如商品和预期不符,需要重新走审核流程。但为了业务快速推动,如果是小的改动,曾经做过一个小功能,允许先审核通过但是做标记,通过寄送新的拍照样品重新确认后取消标记。

2. 问题

样品变更后,由于系统上审核状态已通过,关闭了上游重新上传新图片的入口。业务希望在打标记后,允许上游更改商品图片,否则商品查看和仓库收货都会有问题。

3. 需求分析

  1. 了解背景—— 业务通常只会提出需求,不讲背景,先确认需求目的是否解决业务背景;
  2. 进一步明确业务真实的目的?—— 是解决商品查看和仓库收货标准不统一的问题;
  3. 识别需求能否实现业务目标?——可以解决;
  4. 此需求会否带来其它问题?—— 会。

①商品审核状态需要重启,会和原本审核状态通过矛盾;

②增加新图片上传,内部是否需要新的审核流–需要审图员重新复核。

4. 识别本需求产生的真正原因—— 业务对于便捷功能的滥用

5. 最终实际处理方法

沟通的两种方式:我说和他说。

  • 原本打算说服业务状态重启的状态矛盾,但是业务不能理解,只提问状态需要重启就重启,不能理解对于全流程冗余的影响。沟通陷在我一直在解释,而他一直重复自己的需求的循环里。
  • 改用让他说的方式。我假设开放功能带来的审核流和工作量增加,他回答是否能接受。后沟通后需求取消,通过规范和优化业务对于“不完全合格品标签”的打标标准,在“整体审核”环节即让商家重新传图。

总结

本次仅分享经验教训,不能算典型的成功方法和案例。

作为流程人员,虽无法代替关键业务决策,但需要尽早识别各种方案利弊和长期影响,在评审前做好方案确认,减少来回变更。

如岗位职能有限,可拉动项目经理,请求专家或者上级介入,给予合理的评估。在沟通过程中减少和业务的对抗感,要能从对方角度出发争取全局利益最大化的方案。

理论容易,难在实践、难在平衡,多思考、多分享、多讨论。

 

本文由 @我叫更更 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!