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

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

一、场景再现

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

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

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

我们在接盘一个产品时经常会遇到此类问题,那么我们正确的接盘和重构的X是什么呢?

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

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

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

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

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

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

由于门店人员经常在完成备货后不手动X【拣货完成】,造成外mài平台侧的拣货时长过长,进而导致平台X评分下降,影响营收。

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

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

经过用户调研和实际cāo作体验:

  • 门店作业系统中,备货cāo作的入口太深,导致门店人员cāo作过于繁琐。
  • 采用纸质小票的方式进行拣货,拣货完成后需要再进入门店作业系统中X【拣货完成】,cāo作liú程过于gē裂。

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

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

从实际X场景来说,订单的状态会影响退单的cāo作,举例:

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

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

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

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

参与者X了现实X的“人”参与者是模型信息来源的X者,也是第一驱动者。要建立的模型的意义完全被参与者决定,所建立的模型也是完全为参与者X的。

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

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

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

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

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

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

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

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

具体来说:

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

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

5. 真的需要重构吗?

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

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

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

当然,我们也可以从投入、收益(ROI)的角度来评估,重构的效益是否超过了重构的投入,如果重构的收益。

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

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

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

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

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

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

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

例如,我们一般xí惯从用户角度和非用户角度进行分析:

四、结尾

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

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

  • 新的解决方案中,决定去除系统自动拣货完成的逻辑,并使用移动端拣货APP的方式替代依赖纸质小票拣货的方式,将拣货作业在线化,解决拣货作业和在系统中X【拣货完成】动作的gē裂;
  • 增加最迟拣货时间的提醒,增加拣货时长的统计分析,增加多人同时拣货的机制以应对X高峰期造成的拣货延时,设计由X考核门店人员拣货时长的工作机制,最终提高外mài平台侧对商户的拣货X的评分;
  • 增减配置,兼容新老解决方案,方便新老解决方案的切换;
收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 1-2年产品经理:教你接盘与重构的姿势 https://www.xiongfawang.com/748.html

常见问题

相关文章

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

分享本文封面