续重是什么意思(快递首重15续重10是什么意思)

编辑导读:每个人的职业道路都不是一帆风顺的，总会遇到一些绊脚石，产品经理也是如此。在工作的过程中，前人的意见可以减少踩坑，获得更快的成长。本文作者根据自己的经验总结了一些容易踩的坑，希望对你有所帮助。

本文主要是分享和记录我的小指南和一些小案例。减少踩踏，人人有责。包括产品思考过程中的五个方面:历史数据兼容、版本历史兼容、数据初始化方案、灰度设计、数据嵌入。

一、不要忘记-兼容历史数据

产品的很大一部分工作是优化和迭代，也就是说我们在升级一些已经在使用的功能，所以这些历史功能在上线使用的时候肯定已经产生了数据。在设计新功能时，我们需要考虑历史数据信息的集成，以及已经在使用当前数据的上下游系统。否则可能会导致上下游调用异常或系统数据使用异常。

小案例分享-1

近几年笔者在负责物流相关系统，涉及到内部员工车辆的管理。前期管理比较松散，只涉及车牌、车型、品牌等信息，但这些信息在下游业务中一直正常使用。随着业务的精细化运营，业务方对车辆管理做了整体规划，提出需要对车辆的用途(可以理解为使用场景)、车辆合格证、运载量、车辆基本信息进行管理。

因此，需要在新的功能中与原维护的数据做相应的兼容，哪些字段需要被丢弃，哪些字段对应于本计划中的字段，字段的必选/非必选属性是否改变，相关的表设计和提供给下游的接口(原接口和当前接口中的字段改变)需要兼容，避免对下游造成影响。

OS:马失前蹄，人也失足。项目上线前发现某个字段允许为空与原表定义不一致，导致DBA审批失败，间接导致项目上线延迟。同时，上线后，当用户的系统使用数据，当历史用户没有车辆信息时，系统会出现异常。[/k0/]指针也让我们吃了亏。

小案例分析-2

第二个案例发生在最近，我属于下游系统。前提:在物流系统中，维护物流供应商之间的合作关系是根据供应商当前的业务来源(可以简单理解为业务条线或事业部)进行一层过滤，用户只能选择指定业务来源下的供应商。所有供应商可选信息来自商家系统。

然后有一天，一个业务同学说，不能选择某个供应商。在查看的过程中，我发现商家系统页面找不到【商家来源】这个字段。同时在维护信息的时候也无法维护相关数据。

和对接的产品经理沟通后，我才知道他们在迭代过程中觉得这个字段没用，直接去掉了。导致物流系统功能使用异常。

二、不要忘记-兼容历史版本

考虑到用户的体验，通常不建议发布强制升级的APP版本，除非功能真的很有价值或者存在阻塞问题。所以，当APP升级后才能使用功能时，一定要提前考虑。如果用户不升级，系统应该如何处理，如何使用旧的前端兼容新的后端，保证系统不会报错。这种情况下，如果前端是新入口后的功能，通常影响不大。毕竟用户不升级的时候看不到新的功能入口，所以新的逻辑不会被触发。对于用户来说，只是他因为没有升级而继续使用老功能而已。

但如果入口本身存在于历史中，就需要慎重考虑了。

小案例分享

前提:业务预期限制了APP端某类仓库的退货功能。系统原来的操作流程是点击返回。进入新页面后，您可以创建不同类型的退货单进行退货处理。其实这是一个比较简单的小功能。对于特定类型的仓库，您只需在单击退货按钮时阻止或不显示退货按钮。但一开始并没有考虑到主页代码是原生的(即版本升级后才能生效)。上线后发现退货单据还是会出现。追根溯源，发现部分仓库人员没有升级安装包的习惯，导致老包一直在用，所以这个“漏洞”依然存在。

最终的解决方案是增加后端约束——在提交退货单据时，增加仓库类型的判断和约束，这样无论用户使用什么版本都可以解决这个问题。

虽然我也认为产品不必过多关注开发代码逻辑实现的细节，但是新老版本的考虑个人认为产品还是需要关注的。

(当然，不可否认商业实践的培训和执行确实是有问题的)。

三、不要忘记-数据初始化方案

以上两点是优化现有功能时需要注意的点。第三点——数据初始化旨在启动新功能。所有进程都会生成数据，离线进程往往先于系统进程。那么系统上线后，如何将现有的数据“搬到”网上呢？这就是我所说的数据初始化。

(不代表系统上线后一些配置的初始化)。

数据初始化实际上不会影响后续功能的正常使用，但对于系统初始推广和用户录入是必须的。

如果你上网，业务需要马上用，才觉得现在数据不对，可能显得有点不专业。

这里有两个初始化思路，供大家参考。

小案例分享-1

第一个想法是，你可以利用现有的功能，这通常需要业务合作。比如我们对X业务线实施仓储平台，因为X业务线的线下仓库都在正常运营，所以仓库里一直有库存。实现上线时，系统初始化的存货都是0(因为系统无法知道仓库里的存货)。那么如何才能保证在开始运营前，仓库的实际库存是一致的呢？

我们可以通过现有的后台手工创建入库申请单的功能，为X业务线下的所有仓库创建特殊场景下的入库申请单(所有物料)。仓库在开始使用系统之前，会对仓库中的物料进行清点，并通过仓储将库存添加到系统中。

–不使用盘点的原因是系统的盘点功能限制了只有有缺货记录的物料才能在仓库进行盘点。

小案例分享-2

第二个想法是开发脚本，需要在产品需求计划中考虑，并向开发提出。比如去年我在做一个线上物流费用相关的项目时，为了防止业务操作异常导致费用数据错误，系统功能只允许创建当前发货的物流相关费用，不支持手工创建(日常使用中确实没有这种场景进行评估)。

但由于费用结算的对象是全月的数据，实际的项目在线计划时间不会仅仅停留在月初，所以问题是在无法手工创建历史费用数据的情况下，如何弥补当月已经发生的物流费用用于月账单的结算。

最终的解决方案是R&D方面提供按月+供应商+物流公司手工生成物流费用的脚本，用于上线时补费用。这是给自己留的一个小后门。

四、不要忘记-灰度设计

有时候，我们会发现，即使前期设计的更细致，开发的更细致，测试的更严谨，仍然有可能出现Xi安航空的问题。所以，当函数范围较大，原有流程改动较大时，通常建议不要单个stud直接上线，谨慎回归除外，这可能会导致因一个小问题而需要整体回滚的悲剧。

而是提前和业务沟通，推进进度。试点单位成功后，会逐步推进，把异常控制到最小。

但是一旦捕捉到异常，如果是非阻塞的，可以通过快速响应在最小范围内解决问题，如果是阻塞的，可以通过灰色开关快速切换回原来的进程。

尺寸设计需要根据实际项目的内容来确定。我们遇到过按照供应商、仓库、城市、单据尾号进行灰度化(主要是按照百分比对单据进行灰度化)。

小案例分享

给我印象比较深的这部分案例，是我做供应商，以固定采购成本结算项目的时候。按销售采购是指供应商向我方主体发货，我方主体签收时，不触发结算，而是根据前端销售信息发起结算。环节很长，涉及商家、采购、仓储、前端销售、财务等系统。除了要保证环节系统没有问题，还要保证环节上的相关业务方都清楚新流程的执行和处理，所以还是有难度的。

但是因为以销定购的模式供应商不多(不超过10家)，所以确实疏忽了。第一，他们不做主功能切换，第二，他们不做灰度切换。也就是说，他们一旦上线，如果出现问题，只能回滚代码，而代码回滚后，可能要修复生成的数据。尤其是结算这样的项目，每一个都对应着公司需要支付的货款，还是需要非常谨慎的对待(当时年轻人还没有意识到)。

但是，我们只是碰巧可悲地碰上了，最后只能回滚重新添加格雷码，先贯穿第一个基准供应商再推进后续的实施。

五、不要忘记-数据埋点

所有的产品都是为特殊的背景和目的而设计的，需要相应的经营成果来体现产品价值。那么如何才能有效体现产品价值呢？当然是数据。

在项目初期，我们通常会计算产品的预期结果，比如人力的提高和成本的降低。后期需要确认实际项目结果是否达到预期。

这就要求我们在前期就已经考虑好需要收集哪些数据进行验证(这也考验了我们自己对产品的理解和设计)，并在方案中提前提出需要在具体埋点收集相关数据。

严格来说，这不是一个坑，但却是一个很容易被忽略的重要点。

小案例分享

笔者之前做过一个关于降低性能成本的项目，其中一个子项目涉及到拆迁顺序的优化。原有订单履行的拆分逻辑会导致约30%的概率将多个商品的包裹拆分成两个包裹进行配送，即使用户购买的商品在同一个仓库，可以通过一个包裹配送，从而大大增加了履行成本。

当时物流成本在业绩成本中占比较高，物流成本本身就存在第一包和第二包价差大的客观问题，所以多包的成本必然高于单包。

笔者的计划主要是优化拆包策略，减少不必要的拆包。以及如何证明策略的有效性？

最直接的方法就是在订单进入流程后，调用新老算法，记录同一订单的拆箱数量和新老算法对应的性能代价。最后用数据验证了新算法，因为从掩埋的数据中可以直接看出，当前的实际解包和性能代价远低于原来的策略。

六、总结

这就是我这期想分享的。总结一下，优化旧功能的时候不要忘记历史数据和版本历史的兼容性；

别忘了新功能设计中的数据初始化方案和灰度方案；

而该做的数据埋点还是要做。

还有很多坑还没说。人不是在坑里就是在去坑的路上。还有一些我打算再救一波。希望这篇文章能对你有所帮助。如果里面有不好的地方请指正。

如果你遇到了其他什么坑，也欢迎在后台分享给我。

感谢您的关注。让我们一起欢呼吧。

#专栏作家#

麋鹿产品，微信官方账号:麋鹿产品手册，人人都是产品经理专栏作家。专注挖掘升级供应链，热爱生活，热爱产品。

本文由人人作为产品经理原创发布。未经许可，禁止复制。

标题来自Unsplash，基于CCO协议。