目前我们正在做的RZ项目，其中有一个业务逻辑：订单分配license
订单的商品是服务包（课程&考试），购买的是服务包的有效使用个数
当前线下的分配流程是：管理员向各个部门管理人员收集需要分配的人员-->管理员汇总人员数据-->调整excel表格-->管理员设置分配的人员
因此，业务方对分配的这块提出的需求是：订单分配License时，将人员全部回显，有两种选人方式：1. 手动选择人员 2. excel导入，以实现license占用
这时候，业务方提的是什么？
其实不是，是方案！他在不改变当前线下的操作方式的情况下，在线上完成了分配动作。不过也仅仅是只做了订单分配而已。
那么究竟什么是产品的思考路径及产品解决方案？
订单分配license本质上是一次人员上报的工作流
是管理员自上而下发布各部门待办任务，人员逐级上报、审核最终汇总人员清单后与订单进行关联的行为
所以我们完整正确的逻辑应该如何做呢？
应该做工作流。工作流也可根据类型配置流转规则。
首先，管理员发起工作流：XXXX人员上报-->各部门管理人员-->按组织架构逐级流转直到最小层级-->勾选本部门人员，点击上报-->逐级领导审批（根据组织架构控制数据权限）-->汇总至管理员审核
若最终审核通过，则可将工作流关联订单，去做license占用
这样以来，线下收集的过程可以完全线上化，也可体现收集的整个流程，让线下不规范的工作和行为标准化。同时，线上化后可以直接反应出哪一次的上报有哪些人未通过。甚至还有更多的可能性。
总结：不要将业务提出的需求当做的方案，别做需求翻译工。自己从业务逻辑中梳理能够解决更核心问题的解决方案
网友评论