代码写的都是人情世故

问题说明

在仓储物流系统中，资产的入库与出库流程是核心业务环节之一。最近在仓储服务优化升级过程中，发现了当前系统在处理回购和经租退还资产时，存在一些逻辑问题，导致资产状态记录与系统实际业务需求不一致。

发现问题后我们当然首先是对问题进行分析，并梳理出合理正确的逻辑，然后给出后续处理方案

1️⃣ 问题梳理

1. 入库流程问题：

   • 当外部服务经租退还业务调用仓储服务进行资产直接入库时，系统会判断当前入库仓库对应产品下是否已存在该资产的库存记录。如果不存在，则新增记录；如果存在，则将对应产品下资产的出库状态改为在库状态，修改时间自动更新为当前时间。
   • 在回购业务场景中，调用仓储服务直接资产入库时，对应产品下资产需要被标记为“已回购”状态，且不区分仓库。此时，系统会将当前产品下对应资产的修改时间都会自动更新为当前时间。这种处理方式会导致当前资产的修改时间失去准确性，无法反映真实的最近修改时间。

2. 出库流程问题：

   • 当业务需要出库时，系统会查询对应产品下某资产库存记录的在库状态。然而，由于入库时逻辑问题，查询出来的记录可能并不只有一条，且最近一次修改的记录并不一定是实际最新的资产记录，从而导致出库操作的不准确。

2️⃣ 系统设计合理性分析与改进

1. 当前系统设计合理性分析：

   • 系统将库存与履历概念混杂，即存在履历记录，又存在同一产品下统一资产在不同仓库下的库存记录，设计方面不合理，导致业务逻辑混乱。
   • 不同业务由于开发时间及设计人员不同，设计理念相差较大，没有一个统一的审核及复盘工作，导致同一业务在不同业务处差异较大，给系统带来很多未知隐患。
   • 开发人员变动较多，且无人熟悉整体系统设计，导致系统不合理问题一直隐藏。

2. 改进措施：

   • 统一设计理念：将库存及资产履历概念区分开，统一资产可以在不同仓库中存在出入库履历，但在库存中有且只应该存在最近一次库存记录。
   • 梳理现有业务：对系统现有业务出入库操作代码进行梳理，对与设计冲突的地方进行标记并记录待办事项，画出相应业务流程图、状态图等便于团队开发人员统一认知。团队评估影响范围及排期。

3️⃣ 系统流程合理性分析与改进

1. 当前流程合理性分析：

   • 对统一资产仅应该存在唯一一条资产库存记录，出入库操作根据当前记录状态判断业务是否合理，并变更此库存状态。

2. 改进措施：

   • 优化入库逻辑：在经租退还及回购入库时，判断资产库存存在且是已出库状态，入库完成则改为在库状态；否则状态异常不允许入库。
   • 优化出库逻辑：出库时，判断资产库存存在且是在库状态。

方案、影响评估及方案确认

写到这里，各位看官是不是认为这就是个简单的系统问题，分析完干他就完了，有啥好说的是吧？但现实中我们要考虑的往往更多。

1️⃣ 影响评估

1. 方案及影响范围评估
   当问题梳理完成后，我们对问题产生的原因及影响范围心里是有数的，此时我们需要判断是否需要改造，给出改造方案及评估对应成本。
   这个说起来可能很简单，但现实中我们要考虑的点往往很多，比如：系统当前状况、本开发团队排期、相关联团队开发排期、测试团队排期、产品计划排期、公司对系统改造的态度等等，每一个都可能对我们最终方案产生影响。

   • 方案1：按照上述分析改进方案来，并评估出影响范围及影响人力成本，包括：开发成本、测试成本等
   • 方案2：我们要思考是否有其它代替方案解决当前问题，评估影响范围及人力成本，当然不一定是最完美，但可能是当前环境下最合适的方案。

     • 比如：出库时将查询当前出库产品出库资产最近一次出入库记录作为是否在库条件，这样影响范围则缩小至少三分之一，开发及测试成本也降低了很多。但本质上问题依然存在，我们只是临时性解决当前问题，甚至会给后来人留下大坑。

2. 个人、团队、相关团队及产品综合评估

   • 分析完影响范围后，我们大概知道问题不同解决方案对自己产生的开发成本
   • 影响范围对当前工作计划的影响程度评估；

     • 需求分析阶段：如果问题是需求分析阶段发现的，那解决起来就容易很多了，我们分析完影响点，把分析结果及方案梳理出来加到我们的需求排期计划内，到时候再把整体排期给团队内其它成员分享出来即可。当然如果周期过长，肯定是需要对整体需求排出优先级再确定的。
     • 开发阶段：如果问题是开发阶段发现的，这时候我们排期肯定是已经给出去了，

       • 开发能消化：我们首先要评估自己是否能够消化新增影响工作量，如果开发团队能内部消化，再去与测试团队及产品沟通排期，看对他们影响范围是否能被消化；

         • 测试接受&内部消化：如果测试也能接受且可以在排期内消化，那当然也是一个不错的结果，正常开发提测即可。
         • 测试接受&无法消化：如果对测试来说影响很大，已经给出的排期内无法测试完成，虽然测试愿意接受改变排期，但这时还需要与产品沟通延期上线，看产品接受与否决定。

           • 产品接受：产品如果愿意接受延期，各方商量一致，也是一个解决方案
           • 产品不接受：产品如果不愿意延期，毕竟产品也可能已经对外给出了排期，这时我们给出另外解决方案来评估时间大家是否接受，如果还不能接受，那就需要找更高层来决定。

       • 开发不能消化：当方案我们自身都无法消化时，首先我们要积极反馈，要么重新排期、要么重新定义需求优先级、要么优先以最小影响成本开发，沟通比上一步可能更复杂，流程类似，或者直接拉会各方一起参与。

     • 测试阶段：这个阶段发现问题一般是测试发现问题，此时我们大概率已经在另一个需求中，首先我们要自己评估问题原因、影响范围以及问题等级；

       • 本需求BUG：无论怎样都是要解决的，
       • 历史BUG：

         • 优先级低：此时如果我们工作量饱和，可以直接拒绝；
         • 优先级高：此时一般要优先配合处理，并及时向上反馈，一般优先选择影响最小方案临时解决，再与产品沟通将完整方案作为优化排期处理。要么以完整方案解决问题，整体需求改变排期。当然这些都要看具体问题来分析

当然，这里只是给出个大概的处理流程，实际问题处理过程可能简单也可能比这个更复杂。比如公司制度是任何BUG都要人背锅时，那就更复杂了。。。

作为开发，看似是与代码打交道，其实处处都要与人沟通协调，处处都有人情世故，不同的人与不同的人沟通同一个问题，得到的结果也不尽相同。

比如一个开发与产品、测试关系不错，大家相互理解，就能快速配合协调解决问题；
假如一个开发与产品、测试关系有点不不拍，大家不仅不配合反而相互扯皮，可能问题要上升到更高层才能处理；特别是当问题被发现需要人来背锅时，那就会产生更多的问题；

当然我这里只是基于我这种底层牛马角度来分析问题，如果是中高层大佬，一句话可以决定整个团队的方向，以上都都是屁话。