1-2年产品经理：教你接盘与重构的姿势.docVIP

1-2年产品经理：教你接盘与重构的姿势 / 一、场景再现 看过我其他文章的同学可能知道我是一个零售业B端的产品经理，而我最近在重构公司的门店作业系统。 在对老产品做业务走查的过程中，发现了一个问题：系统存在一个配置，可将订单的作业状态自动置为【拣货完成】状态，同时外卖平台系统从作业状态变为【拣货完成】时开始计算配送员的配送时长，但是实际上门店人员并没有拣货完成。 骑手到店后，由于门店人员实际未完成配货，导致配送员不得不在门店等待，由此触发了配送人员和门店人员的冲突。 我们在接盘一个产品时经常会遇到此类问题，那么我们正确的接盘和重构的姿势是什么呢？ 在这之前，介绍一下我们内部的一个工作习惯：相较于功能，我们更偏向于以一个解决方案的维度去评价好坏。 解决方案是指为了满足一个业务场景而由多个系统中相关联的产品功能、上线交付计划（系统实施与人员培训），运营方案等组成的整体。解决方案可以让我们可以以客户的业务场景出发整体设计，而非割裂的去分析系统中的某一个功能，或者割裂的看待产品功能和后续的交付运营工作。 回到我们遇到的那个具体问题上来，当前的情况无疑说明当前的解决方案是有问题的，那么我们现在就可以立刻着手进行重构了吗，在我们做出这个决策之前，先来尝试回答这些问题： 二、别急着重构，先回答这些问题 1. 该解决方案是为了解决什么业务场景 经过查阅当时的需求工单，发现是为了解决美团饿百等外卖平台对门店拣货时长考核的问题。 由于门店人员经常在完成备货后不手动点击【拣货完成】，造成外卖平台侧的拣货时长过长，进而导致平台服务评分下降，影响营收。 2. 多想一步，问题真的分析清楚了吗？ 为什么门店人员经常在完成备货后不手动点击【拣货完成】？ 经过用户调研和实际操作体验： 门店作业系统中，备货操作的入口太深，导致门店人员操作过于繁琐。 采用纸质小票的方式进行拣货，拣货完成后需要再进入门店作业系统中点击【拣货完成】，操作流程过于割裂。 为什么自动备货的方案会造成系统问题？ 经过总结，我们认为是由于自动备货的方案造成了系统中的状态没有反应真实的业务场景造成的。那有同学就要问了：为什么系统中的状态要反应真实的业务场景： 从实际业务场景来说，订单的状态会影响退单的操作，举例： 订单还没拣货，此时顾客退单，只需要告知门店人员实际需要拣货数量即可； 订单已经拣货还未发货，此时顾客退单，需要告知门店人员将退货商品捡回； 订单已经发货，此时顾客退单，需要告知门店联系骑手或顾客将货物退回并确认退回数量； 由上面的例子可以看出，由于之前的解决方案滥用自动逻辑，造成了订单状态与实际业务场景不符，进而造成系统给出的退单处理方式不对，由此可能带来诸如拣货操作，退货商品损失等一系列问题； 从产品设计的角度来说：系统是现实世界的抽象，人驱动系统，事件体现过程，物记录结果。 在《THINK IN UML》一书中有这样的表述： 参与者代表了现实事件的“人”参与者是模型信息来源的提供者，也是第一驱动者。要建立的模型的意义完全被参与者决定，所建立的模型也是完全为参与者服务的。 所以在实际的方案设计过程中，系统自动化逻辑，应该是人决策的补充和辅助，或是人决策逻辑的有效和有限的归纳，设计时应尽可能的谨慎。 当系统状态不能反应真实业务场景时，即使可能从某些角度看是合理的，但是确实违反了业务建模过程中的抽象原理。 3. 当时为什么将方案设计成了这个样子 我相信，在设计该方案的时候，当时的产品经理也了解到了这个情况，但是为什么还是选择增加系统自动【拣货完成】的方案呢，经过了解，原因有两个： 当时客户的业务量较小，产品的客户群体也小，故只要保证系统自动备货后，门店人员及时拣货即可，当时的条件下认为是可以保证的。 如果调整门店前台作业系统的作业逻辑，优化拣货作业流程，需要对系统做较大的改造，投入产出比较低； 当然，从当时的业务场景来看，当时做的产品决策是基本正确的，但是为什么当时认为该方案是好的，但是现在认为是有问题的呢？ 4. 为什么当时认为该方案是好的，但是现在认为是有问题的呢？ 从上面两问，我们可以发现，该方案在当时的业务场景下，从用户角度来说，确实满足了可用性的要求，但是从现在的业务场景来看，该解决方案的可用性是有问题的。 具体来说： 客户的业务量上升，进一步降低拣货效率，当前对状态粗放型的管理不再满足需求； 客户精细化运营的诉求强烈，期望降低纠纷，提高企业形象； 事物是动态发展的，系统优化是和实际的业务情况一起螺旋上升的，从来也没有一个产品可以在20年前就考虑满足到今天的业务诉求，所以这种情况是正常的。 5. 真的需要重构吗？ 但是当我们发现当前的解决方案是有问题的，就一定要重构吗？答案当然是否定的，那么我们应该从哪些角度来权衡是否要重构呢？ 当前方案对于整个产品来说的地位是什么？ 核心方