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