曾几何时，当有系统分析员角色时，系统分析员负责需求、逻辑分析并出方案。在产品经理时代，系统分析员的工作有相当一部分被产品经理分担。产品经理的角色位于：用户和开发人员之间，他们既要懂客户和业务，也要了解大致的开发逻辑。这样才能尽可能接近系统分析员的初级能力。从需求到方案，需要哪些核心步骤，考虑哪些因素，才能做出一份完整的需求和业务方案？我们以“锁库”实例解构这个过程，共同提取步骤和因素的要点。

　　●重点思考：如何应对类似：方向明确、强业务场景、细节模糊、缺乏完整结构的需求？从下面5点展开分析：

　　①业务逻辑：场景、场景的上下文（或者叫前后相关的业务）、岗位、职责、异常处理、设备载体（PC，手机、打印纸张）

　　需求的实现前提，必须基于现软件系统的已有逻辑。即：不能和既有逻辑冲突，也不能和既有的名词、定义或操作习惯冲突，所以必须在熟悉现软件数据结构的前提下做可行性思路。

　　方案对比：在对比方案前，均需要细化方案到具体功能描述和数据结构，特别是状态机。只有在方案层展开细化，才能避免开发中途遇到难以逾越的逻辑卡点经过两套方案的细节展开后。

　　小结：功能是为了解决用户问题，一般我们会优选用户角度易用好理解的方案，除非是完全没有交互的后台功能。虽然锁库增加了实体表（除非必要勿增实体），但对比可知，显然是必要的。

　　2）解锁有多种情况：a.手工解锁，比如订单取消了；b.发货解锁，已经发货，就无需继续锁定；c.超期解锁，锁库不能没有期限，虽然手工解锁可弥补，但加上期限自动化程度就更高。

　　3）出库校验时算法为：库存-锁库总量+当前出库明细对应的锁库明细量。即：出库自动解锁当前锁库，所以校验锁库数量时，需去除当前锁库量；

　　不难看出，上述问题均为数据异常时（这里的异常，指的是不满足业务必要条件）出现的；所以我们在分析需求时，特别要注意，不能只考虑正常逻辑，异常逻辑的处理、容错非常重要，这决定了软件的鲁棒性。

　　这里的优先级应该由人来判断，需增加当前产品锁库相关明细的查看，而不是做严格逻辑约束，以应对各种可能性。因为锁库本身就是一个出库的高优先，如果再增加内部优先排序，反而会增加系统使用的复杂度，意义不太大。

　　至此，锁库的需求分析和基础解决方案确定。中间省略了大量的展开细节文档，是为了更容易展现这个过程的结构。在实际工作中，展开细节文档很重要，不能用一个粗线条的方案来确定整体可行性。把80%的精力放在20%的关键事情上，底层逻辑一旦打通，再由程序员把需求转化为代码，可大大减少不必要的试错！【图示：按此方案开发后的锁库部分界面】