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

导语：当接手一个产品并发现一个解决方案不好时，我们往往就倾向对这个方案全**否定，并着急去开始重构，但着急重构这个选择往往是不明智的；今天笔者就以一个小事例，给大家介绍接**与重构的姿势。

一、场景再现

看过我其他文章的同学可能知道我是一个零售业B端的产品经理，而我最近在重构公司的门店作业系统。

在对老产品做业务走查的过程中，发现了一个问题：系统存在一个配置，可将订单的作业状态自动置为【拣货完成】状态，同时外卖平台系统从作业状态变为【拣货完成】时开始计算配送员的配送时长，但是实际上门店人员并没有拣货完成。

骑手到店后，由于门店人员实际未完成配货，导致配送员不得不在门店等待，由此触发了配送人员和门店人员的冲突。

我们在接**一个产品时经常**遇到此类问题，那么我们正确的接**和重构的姿势是什么呢？

在这之前，介绍一下我们内部的一个工作习惯：相较于功能，我们更偏向于以一个解决方案的维度去评价好坏。

解决方案是指为了满足一个业务场景而由多个系统中相关联的产品功能、上线交付计划（系统实施与人员培训），运营方案等组成的整体。解决方案可以让我们可以以客户的业务场景出发整体设计，而非割裂的去分析系统中的某一个功能，或者割裂的看待产品功能和后续的交付运营工作。

回到我们遇到的那个具体问题上来，当前的情况无疑说明当前的解决方案是有问题的，那么我们现在就可以立刻着手进行重构了吗，在我们做出这个决策之前，先来尝试回答这些问题：

二、别急着重构，先回答这些问题

1. 该解决方案是为了解决什么业务场景

经过查阅当时的需求工单，发现是为了解决美团饿百等外卖平台对门店拣货时长考核的问题。

由于门店人员经常在完成备货后不手动点击【拣货完成】，造成外卖平台侧的拣货时长过长，进而导致平台服务评分下降，影响营收。

2. 多想一步，问题真的分析清楚了吗？

为什么门店人员经常在完成备货后不手动点击【拣货完成】？

经过用户调研和实际操作体验：

• 门店作业系统中，备货操作的入口太深，导致门店人员操作过于繁琐。
• 采用纸质小票的方式进行拣货，拣货完成后需要再进入门店作业系统中点击【拣货完成】，操作流程过于割裂。

为什么自动备货的方案**造成系统问题？

经过总结，我们认为是由于自动备货的方案造成了系统中的状态没有反应真实的业务场景造成的。那有同学就要问了：为什么系统中的状态要反应真实的业务场景：

从实际业务场景来说，订单的状态**影响退单的操作，举例：

1. 订单还没拣货，此时顾客退单，只需要告知门店人员实际需要拣货数量即可；
2. 订单已经拣货还未发货，此时顾客退单，需要告知门店人员将退货商品捡回；
3. 订单已经发货，此时顾客退单，需要告知门店联系骑手或顾客将货物退回并确认退回数量；

由上面的例子可以看出，由于之前的解决方案滥用自动逻辑，造成了订单状态与实际业务场景不符，进而造成系统给出的退单处理方式不对，由此可能带来诸如拣货操作，退货商品损失等一系列问题；

从产品设计的角度来说：系统是现实世界的抽象，人驱动系统，事件体现过程，物记录结果。

在《THINK IN UML》一书中有这样的表述：

参与者代表了现实事件的“人”参与者是模型信息来源的提供者，也是第一驱动者。要建立的模型的意义完全被参与者决定，所建立的模型也是完全为参与者服务的。

所以在实际的方案设计过程中，系统自动化逻辑，应该是人决策的补充和辅助，或是人决策逻辑的有效和有限的归纳，设计时应尽可能的谨慎。

当系统状态不能反应真实业务场景时，即使可能从某些角度看是合理的，但是确实违反了业务建模过程中的抽象原理。

3. 当时为什么将方案设计成了这个样子

我相信，在设计该方案的时候，当时的产品经理也了解到了这个情况，但是为什么还是选择增加系统自动【拣货完成】的方案呢，经过了解，原因有两个：

• 当时客户的业务量较小，产品的客户群体也小，故只要保证系统自动备货后，门店人员及时拣货即可，当时的条件下认为是可以保证的。
• 如果调整门店前台作业系统的作业逻辑，优化拣货作业流程，需要对系统做较大的改造，投入产出比较低；

当然，从当时的业务场景来看，当时做的产品决策是基本正确的，但是为什么当时认为该方案是好的，但是现在认为是有问题的呢？

4. 为什么当时认为该方案是好的，但是现在认为是有问题的呢？

从上面两问，我们可以发现，该方案在当时的业务场景下，从用户角度来说，确实满足了可用性的要求，但是从现在的业务场景来看，该解决方案的可用性是有问题的。

具体来说：

• 客户的业务量上升，进一步降低拣货效率，当前对状态粗放型的管理不再满足需求；
• 客户精细化运营的诉求强烈，期望降低纠纷，提高企业形象；

事物是动态发展的，系统优化是和实际的业务情况一起螺旋上升的，从来也没有一个产品可以在20年前就考虑满足到今天的业务诉求，所以这种情况是正常的。

5. 真的需要重构吗？

但是当我们发现当前的解决方案是有问题的，就一定要重构吗？答案当然是否定的，那么我们应该从哪些角度来权衡是否要重构呢？

当前方案对于整个产品来说的地位是什么？

• 核心方案：核心方案指该产品为解决主要问题而设计的方案，要求是保证稳定，一般不进行重构。如果重构基本相当于做一个新的产品，从我们内部的经验来看，应以新项目的方式组织评估、生产而非重构的方式进行。两者的区别是，新项目一般需要事业部级别的专家主持，而重构一般由各产品线的中高级产品经理主持；
• 个性化方案：为了解决个别客户更复杂的业务场景，或响应客户更高业务水平的功能，如生鲜电商中的退差价方案，此时如果客户要求或同意，即可进行重构。
• 辅助方案：一般为为了运营设计的数据分析等功能，和为运维搭建的配置调试、监控预警体系，优先级最低，当内部评审认为已经严重影响到内部工作开展时，才**决定重构；

当然，我们也可以从投入、收益（ROI）的角度来评估，重构的效益是否**过了重构的投入，如果重构的收益。

收益：B端产品功能的核心指标就是提高企业的效率，那收益可以直接用为单个企业提高的效率乘以客户基数吗，答案是不可以。因为不同企业的业务开展情况是不一样的，可能有部分企业使用现有方案已经能够满足需求，即时新方案拓展性更好，稳定性更强，作业效率更高，但是企业不愿意承担重新培训人员的迁移成本，或者由此带来的风险；所以我们考虑重构收益的时候发现，可能只有很少一部分企业接受重构后的新方案，对于公司来说收益并不高，这时是否需要重构就要谨慎权衡了。

投入：开发成本（设计，编码，测试），运维成本，功能交付成本,当然还有风险成本，新的方案引入新的风险，切换新方案时，如果新方案出现了问题，**带来一系列的消除影响的工作，也需要当作成本提前考虑在内。

6. 真的要重构了，不要忘记

兼容不同客户的使用情况，可以采用增加功能而非直接替代的方式进行重构，以方便一批一批进行方案切换，或兼容不愿意切换的客户的业务场景。

考虑评价新方案谁否有效性的方法，比如整理运营跟进的方案的使用情况，主动调研企业或者实际使用者的体验等等，如果公司有资源支持，也可以在方案设计后，通过压测，A\Btest等方式，确认是否比老方案更有效（一般大B端产品做AB测试的局限性很大，因为用户基数较小，但是每个客户的业务情况又千差万别，获取到有统计意义的数据的成本很高，同时B端产品的设计开发成本也很高，几乎无法根据测试结果进行高频的方案调整。故B端产品的设计还是依赖于方案设计初期邀请客户或者公司内的专家进行方案评审，以及上线后运营同学的主动跟进）。

三、如何快速定义一个方案的好坏

当然，我们可以尝试总结出自己的标准，方便我们日常工作中快速对解决方案的好坏做出评价并做出决策。

例如，我们一般习惯从用户角度和非用户角度进行分析：

四、结尾

产品经理不是画图崽，产品经理在日常的工作中做的最多也最重要的，就是针对各种问题进行决策。当我们在接**一个产品，并计划计算重构的时候，多想一点，才能帮助我们做出最好的决策。

回到最开始的那个实际问题，我们最终选择的解决方案是什么呢。在这里给大家大致说一下，帮助大家理解接**和重构的姿势：

• 新的解决方案中，决定去除系统自动拣货完成的逻辑，并使用移动端拣货APP的方式替代依赖纸质小票拣货的方式，将拣货作业在线化，解决拣货作业和在系统中点击【拣货完成】动作的割裂；
• 增加最迟拣货时间的提醒，增加拣货时长的统计分析，增加多人同时拣货的机制以应对业务高峰期造成的拣货延时，设计由总部考核门店人员拣货时长的工作机制，最终提高外卖平台侧对商户的拣货服务的评分；
• 增减配置，兼容新老解决方案，方便新老解决方案的切换；

本文由 @kathic 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议