编辑导语：曾经，系统分析员负责需求、逻辑分析并出方案。如今，系统分析员的部分职责被产品经理分担。那么，从需求到方案确认，产品经理们需要考虑哪些核心步骤与因素？本文以“锁库”为例，总结了五点应对的方法。
曾几何时，当有系统分析员角色时，系统分析员负责需求、逻辑分析并出方案。
在产品经理时代，系统分析员的工作有相当一部分被产品经理分担。产品经理的角色位于：用户和开发人员之间，他们既要懂客户和业务，也要了解大致的开发逻辑。这样才能尽可能接近系统分析员的初级能力。
从需求到方案，需要哪些核心步骤，考虑哪些因素，才能做出一份完整的需求和业务方案？我们以“锁库”实例解构这个过程，共同提取步骤和因素的要点。
- 原始需求：客户希望能锁库，销售遇到核心保障的订单，在订单执行前锁库。
- 汇总分析：需求方向明确：锁库；需求细节模糊；没有完整逻辑。
- 重点思考：如何应对类似：方向明确、强业务场景、细节模糊、缺乏完整结构的需求？从下面5点展开分析：
一、产品经理，需明确理解
用户提供需求经常是碎片式的。我们需根据碎片补充：
- 业务逻辑：场景、场景的上下文（或者叫前后相关的业务）、岗位、职责、异常处理、设备载体（PC，手机、打印纸张）
- 数据逻辑：角色、权限、状态机、数据动作、看门狗
- 泳道图：当需求涉及多角色多状态时，最能清晰表达业务流程
- 流程图：程序处理的主逻辑
二、基于现软件已有逻辑来分析
需求的实现前提，必须基于现软件系统的已有逻辑。
即：不能和既有逻辑冲突，也不能和既有的名词、定义或操作习惯冲突，所以必须在熟悉现软件数据结构的前提下做可行性思路。
锁库的核心需求：在发货时，能保护锁库的数量不会被发出。2个可行思路：
A：虚拟库方案：
- 建立一个虚拟仓库A，专门用于存放锁库产品
- 锁库时，所有锁库产品均调拨到仓库A
- 锁库产品出库时，从仓库A出库发货，或调拨到正常发货仓发货
- 其他出库时，因为锁库产品在专用仓，所以不用特殊校验
B：锁库明细方案：
- 新增锁库明细表，用于承载锁库数据
- 锁库时，创建锁库明细数据
- 出库时，判断条件增加锁库数量
方案对比：在对比方案前，均需要细化方案到具体功能描述和数据结构，特别是状态机。只有在方案层展开细化，才能避免开发中途遇到难以逾越的逻辑卡点经过两套方案的细节展开后。
A：虚拟库方案：
优点：没有新增表，基本为原逻辑的组合；
缺点：虚拟库+调拨的过程比较复杂，在用户理解角度会感觉不太直接。
B：锁库明细方案：
优点：业务含义明确，执行逻辑虽然新增校验，但是整体理解更顺畅；
缺点：新增数据表：锁库明细。
小结：功能是为了解决用户问题，一般我们会优选用户角度易用好理解的方案，除非是完全没有交互的后台功能。虽然锁库增加了实体表（除非必要勿增实体），但对比可知，显然是必要的。
三、根据经验补充为完整逻辑
到这里，主方案思路确定：锁库明细表方案。继续完整逻辑：
1）锁库有锁，就要有解锁
2）解锁有多种情况
- 手工解锁，比如订单取消了；
- 发货解锁，已经发货，就无需继续锁定；
- 超期解锁，锁库不能没有期限，虽然手工解锁可弥补，但加上期限自动化程度就更高。
3）锁库的角色权限
- 销售提请锁库；
- 库管确认锁库；
- 库管可手工解锁。
四、按场景业务推演，查漏补缺
补充完整逻辑后，要做业务功能的要点和场景总结：
1）销售基于订单明细申请锁库，由库管确认；
2）库管确认后的锁库会参与出库校验；
3）出库校验时算法为：库存-锁库总量+当前出库明细对应的锁库明细量。即：出库自动解锁当前锁库，所以校验锁库数量时，需去除当前锁库量；
4）锁库超期自动解锁（颗粒度：X天）。
五、异常情况复盘，查漏补缺
上述主体结构已经比较完善，仍然需要根据所有步骤相关的数据表找异常数据情况做一遍复盘：
1）如果当前库存不够，是否允许锁库？
其业务逻辑是：虽然库里没有，但我需要提前锁定，因为这个客户重要。
2）如果当前库存不够全部锁库，且当前出库有锁库，是否允许当前出库？
其业务逻辑是：库存不够全部锁库，但是够我这单锁库的数量，是否让我出？
不难看出，上述问题均为数据异常时（这里的异常，指的是不满足业务必要条件）出现的；所以我们在分析需求时，特别要注意，不能只考虑正常逻辑，异常逻辑的处理、容错非常重要，这决定了软件的鲁棒性。
分析：
1）库存不够，提前锁库。——业务角度合理，应支持实现。
2）库存不够全部锁库，但是够当前出库的锁库，是否允许发？这背后是一个锁库优先级的问题：
这里的优先级应该由人来判断，需增加当前产品锁库相关明细的查看，而不是做严格逻辑约束，以应对各种可能性。因为锁库本身就就是一个出库的高优先，如果再增加内部优先排序，反而会增加系统使用的复杂度，意义不太大。
至此，锁库的需求分析和基础解决方案确定。中间省略了大量的展开细节文档，是为了更容易展现这个过程的结构。在实际工作中，展开细节文档很重要，不能用一个粗线条的方案来确定整体可行性。把80%的精力放在20%的关键事情上，底层逻辑一旦打通，再由程序员把需求转化为代码，可大大减少不必要的试错！