“这个场景没有考虑到”，这句话是否很熟悉？
产品方案设计时，需求文档写着写着发现一个场景没有考虑到，结果之前写的文档都要重新修改；
产品方案评审时，在面临同事的连环提问，不得不当场梳理该业务场景的产品设计方案，或者另外组织时间需求评审；
功能上线后，才发现给自己埋了一个大坑，运气好的话只需要跪求开发上线补救版本就能解决。运气差的话，版本回滚，推翻重做。
因此，为了避免以上事件发生，我以自己曾经写的需求<面料下单判断>为例，讲述我是如何避免产品设计时遗漏业务场景。
注1：公司产品为服装定制平台
注2：实际逻辑较多，为了便于文章的表达，仅描述主流逻辑。
需求背景
1、作为服装定制平台，面料库存可代指商品库存
2、商品超卖会对极大伤害用户体验，同时处理超卖订单的处理也会耗费一定的人力和时间
3、对于实际有库存但由于误判断导致无法下单，不仅影响订单的成交率，也会造成库存的无辜积压
4、需求原则：无可用库存避免漏判断导致超卖，有可用库存避免误判断导致订单流失
5、库存预占条件：付款即预占
一、描述主流业务场景
举例：在ipad端用户创建了正常订单，选择面料时，若订单未付款，需要什么判断，操作会变成什么？
这个业务场景描述可以总结为：前提（ipad端&正常订单）-操作（保存面料）-判断条件（订单未付款）-判断内容-后置状态；
前提：在描述业务场景时，难点在于描述<前提>，要描述同该需求有关的产品前提才更聚焦于需求本身。这依赖于产品经理对产品的理解，以文中为例，ipad端和app端是用户的下单入口，且不属于同一个判断接口，因此要注明产品线是属于IPAD端；正常订单和售后订单的下单路径不一致，因此要注明创建的是正常订单。
操作：整理用户可操作的全部点击按钮即得出触发判断的入口。
判断条件：已付款的订单预占库存，未付款的订单未预占库存；
判断内容：根据本次需求本身，确定判断内容；
后置状态：注明每次操作后，结果是什么。
有序的思考不仅可以避免维度遗漏，还可以随着时间的积累形成自己适合的产品思考维度，在遇到同类需求时能快速整理归纳。
二、罗列需求维度
产品线：ipad端、app端；
订单类型：正常订单、售后订单；
前置状态：已付款，未付款；
操作：保存面料，订单支付；
判断内容：面料库存；
后置状态：预占库存，未预占库存；
注1：常见操作场景有，增，删，修改，撤销
注2：我往往借助xmind罗列需求维度，如图所示
三、排列组合
取ipad端&正常订单为前提，以操作入口来整理该需求的全部业务场景；
保存面料
未付款订单，则判断面料库存，若库存充足则保存成功且不预占库存，若库存不足则报错；
已付款订单，不判断面料库存，保存成功并预占库存；
订单支付
未付款订单，则判断面料库存，若库存充足则支付成功并预占库存，若库存不足则报错；
付款订单，不判断面料库存，支付成功并预占库存；
