这5个容易踩坑的点，请不要忘记

本文来自微信公众号“人人都是产品经理”（ID:woshipm），作者：麋鹿产品手册，36氪经授权发布。

每个人的职场之路都不是一帆风顺的，总要经历一些磕磕绊绊，产品经理也是如此。在工作过程中，前辈的意见能够减少踩坑，更快获得成长。才能本文作者从自身经验出发，总结了一些容易踩的坑，希望对你有帮助。

本篇文章主要是为了分享和记录我整理的避坑小指南和一些小案例分享。

减少踩坑，人人有责。

主要包括产品思考过程中针对：历史数据兼容、历史版本兼容、数据初始化方案、灰度设计、数据埋点这五个方面内容的思考。

产品的工作很大一部分是在优化和迭代，也就是说我们在对一些已经在使用中的功能进行升级；那么这些历史功能在线上使用时必然已经产生过数据，新功能的设计时，需要考虑融合历史的数据信息，同时还要考虑到已经在使用当前数据的上下游系统。否则可能导致上下游的调用异常或者本身系统数据使用的异常。

笔者近年在负责物流相关的系统，其中涉及到对内部员工车辆的管理，前期管理的较为宽松，因此只涉及到车牌、车型、品牌的信息。

但这些信息已经在下游业务中进行了正常的使用，随着业务精细化运营，业务侧对车辆管理进行了统筹的规划，提出了对车辆的用途(可以理解为使用场景）、车辆证件、承载量、车辆基本信息均需要进行管理。

因此势必需要对原有维护好的数据，在新功能里进行相应的兼容，哪些字段是需要废弃的，哪些字段对应本次规划中的字段，字段的必填/非必填属性是否有变更，相关的表格设计以及提供给下游的接口（原接口中的字段和当前有所变更）需要如果兼容才可以避免对下游的影响。

OS：马有失蹄，人有失手，项目上线前发现由于某个字段允许为空和原来的表定义不符导致DBA审批不通过间接导致项目上线延期了。同时，上线后，在用户系统使用数据时，历史用户无车辆信息时会导致系统异常空指针也让我们吃了一亏。

第二个案例就是最近发生的，我属于其中的下游系统。

前提设定：在物流系统中，维护物流供应商的合作关系是会根据供应商当前合作的业务来源(可以简单的理解成业务线或事业部）进行一层过滤，用户只能选择指定业务来源下的供应商。所有供应商可选信息来源于商户系统。

然后某天业务同学说某个供应商选不到，我在排查过程中发现商户系统页面找不到[业务来源]这个字段了；同时在维护信息时也无法进行相关数据的维护。

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

由于考虑用户使用感受，除非功能真的极具价值或存在阻断型问题，通常是不建议发布强制升级的APP版本的。因此当功能涉及到APP端升级后才可以使用时，必须要提前考虑到，如果用户不升级，那系统要怎么处理以及如何用旧前端兼容新后端且确保系统不会报错。

这种情况，如果前端是新增入口后的功能，则通常影响不大，毕竟用户不升级时，是看不到新功能入口的，则不会触发新逻辑，对用户来说只是因为个人没有升级而继续使用老功能而已。

但是如果本身入口是历史存在的，那么就需要谨慎考虑了。

前提设定：业务期望限制某种类型仓库在APP端的退货功能。系统原操作流程是点击退货，进入新页面后可以创建不同类型的退货单进行退货处理。

这其实是一个比较简单的小功能，只需要对于特定类型的仓库在点击退货时进行阻断或者不展示退货按键就可以了。

但是由于起初没有考虑到首页代码是原生的（即依赖版本升级后才可以生效），上线后发现还是会出现退货单据，溯源后才发现部分仓库人员并没有升级安装包的习惯导致一直使用旧包在操作，所以还有这个“漏洞”在。

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

虽然我也认为产品确实可以不用太关心开发代码逻辑实现的细节，但是新旧版本的考虑个人认为产品还是需要关注到的。

（当然，不可否认的，业务实操培训和执行确实也是有问题的）。

上面两个点都是针对于现有功能优化时，要注意的点。而第三点-数据初始化则是针对于新功能上线来说。

所有的流程都会产生数据，而线下流程的运行往往是先于系统的流程化的，那么在系统上线后，已经有的数据如何“搬到”线上来，这就是我所指的数据初始化

（并不是指系统上线后一些配置的初始化哦）。

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

如果上线后，马上业务要用了才想到现在数据不对，可以就显得略有些不专业了。

这里主要提供两种初始化的小思路供大家参考。

第一个思路是：可以利用已有的功能，通常需要业务配合执行。

比如，我们在做仓储平台向X业务线实施时，由于X业务线的仓库线下都是在正常运营中的，所以仓内一直是有库存的，而在实施上线时，系统初始化的库存均为0（因为系统是无法知道仓内库存的）。

那么，如何能确保开始操作前仓内账实库存一致呢？

我们可以通过后台现有的手动创建入库申请单的功能，对X业务线下所有仓库创建特殊场景的入库申请单(全物料），仓库开始使用系统前，清点仓内物资，将库存通过入库的方式增加到系统中。

–不使用盘点的原因是因为系统盘点功能限制仓内只允许盘点有过出入库记录的物料。

第二个思路则是通过开发脚本的方式，这就需要前置在产品需求方案中就考虑到并向开发提出。

比如，笔者去年在做物流费用线上化相关的项目时，为了防止业务异常操作导致费用数据错误，系统功能上是只允许创建当下发运的物流相关的费用，不支持手动创建（评估在日常使用中确实也没有这样的场景）。

但是因为费用结算的对象是整个月的数据，实际项目上线计划时间也不会正好卡在月初。

所以问题是在于：无法手动创建历史费用数据的情况下，如何补齐当月已经发生的物流费用用于月账单的结算呢。

最终的解决方式是研发侧提供根据月份+供应商+物流公司手动生成物流费用的脚本，用于上线时费用的补齐。这也算是给自己预留的一个小后门吧。

有时候我们会发现，哪怕前期设计再谨慎、开发再小心、测试再严谨还是有可能会出现西安航问题。

因此当功能范围涉及较大且对原流程改动较大时，除了谨慎回归外，通常建议不要一把梭哈直接全部上线，很有很可能出现一个小问题导致整体需要回滚的悲剧。

而是提前和业务沟通好推进进度，试点单位成功后逐步推进，将异常控制在最小范围内。

一但捕捉到异常，如果是非阻断性的，则快速响应在最小范围内解决问题，而如果是阻断性的也可以通过灰度开关快速的切回原流程。

灰度维度设计需要根据实际项目的内容进行确定，我们有遇到过按照供应商、按照仓库、按照城市、按照单据末尾号（主要是为了按百分比灰度单据）等方式进行灰度。

这部分让我印象比较深的案例是在做供应商以销定采费用结算项目时。

以销定采是指，在供应商发货给我方主体及我方主体进行签收时并不触发结算，而是根据前端销售信息发起结算。链路很长，涉及到商户、采购、仓储、前端销售、财务等系统。

我们除了要保证链路系统没有问题之外，还需要保证链路上的相关业务方都清楚的新流程的执行和处理，所以还是有一定难度的。

但是因为以销定采模式的供应商不是特别多(不超过10家)，所以确实也疏忽大意了，一没有做功能总开关，二没有做灰度开关；也就是说一旦上线，如果有问题，就只能回滚代码了，而且代码回滚之后还可能要面临着已经产生的数据的修复。特别是像结算类的项目，每一笔对应的都是公司需要支付的货款，还是需要非常谨慎的对待的（当时年轻还没有意识到）。

而我们正好也悲催的碰上了，最终也只能回滚后重新增加灰度的代码，先把第一个标杆供应商跑通再推进后续的实施。

所有的产品都是出于特地的背景和目的来设计的，需要对应的业务成果来体现产品价值。那么如何能够有效的体现产品价值呢，当然是数据。

在立项初期，我们通常就会预计算好产品大概会带来的成效，比如人力的提升、成本的降低等。而后期在复盘时，则需要确认实际带来的项目成果是否达到预期。

这就需要我们在初期就已经考虑好哪些数据是需要采集用于验证的（这也考验我们自己对产品的理解和设计），提前在方案中提出需要进行特定的埋点采集相关数据。

严格的说这其实不算是个坑，但确实是一个很容易被遗漏的重要点。

笔者之前做过一个关于履约成本降低的项目，其中的一个子项目是涉及拆合单优化。

原订单履约的拆单逻辑会导致多商品的包裹有约30%左右的概率被拆分为2个包裹发货，哪怕用户购买的商品在同一个仓库有货可以通过一个包裹发出（详细拆单逻辑此处不展开讲解），也因此大幅增加了履约成本。

当时物流成本在履约成本中占比较高，而物流费用中本身存在首重续重价格差异大的客观问题，所以多包裹的费用必然会高于单包裹。

笔者的方案主要是优化了拆包的策略，减少不必要的拆包数。而如何证明策略的有效性呢？

最直接的办法就是在订单进入流程后，同时调用新老算法埋点记录对于同一笔订单新老算法的拆包裹数及对应的履约成本。而最终通过数据也确实验证了新算法，因为从埋点数据可以非常直接的看出当前实际拆包裹及履约成本是远低于原策略的。

以上就是本期想分享的内容啦，总结下来就是：旧功能的优化不要忘记历史数据和历史版本的兼容；

新功能设计不要忘记数据初始化方案和灰度方案；

以及该做的数据埋点还是要做起来。

有很多坑其实还没有提到。

人嘛，要么是在坑里，要么是在去往坑的路上。

本篇分享希望可以对你有所帮助，如果写的有不好的地方欢迎指正。