Evilom
4.8 KiB
QlkHwnISsiFSLRk6Q2PcyIn3ntc
Source: https://ocnmca6f1o0p.feishu.cn/wiki/QlkHwnISsiFSLRk6Q2PcyIn3ntc
工作内容概述
1、财务取数工具取数源增加地区 2、财务取数工具增加取数明细利于错误检测 3、同比环比没有根据输入月份切换公式修复
一、提升适配性，避免反复踩坑
不做"哪疼治哪"的临时差异修复，重点归拢易反复触发的共性问题，从根本上减少工具被动跟随业务调整的频率。 最初任务仅为按财务反馈逐条修正数据差异。实际推进中发现，仅修复当下问题意义有限，财务侧稍作底稿结构调整，同类问题就会重现。因此重点梳理高频复现风险点，提升工具自身适应性。 "报哪修哪"的处理方式本身无错，但不符合财务实际工作节奏：财务底稿格式调整频繁，每月都可能因业务口径变化新增列、补充月份或调整表头位置，导致刚修复的问题下月复发，工具始终处于被动追赶状态。
- 表面问题：个别科目数据不一致、同比环比计算异常、金额与样表存在小额差异
- 根本原因：取数规则、月份口径、表头位置、字段顺序等仍为工具内部硬编码，财务底稿调整后，固定值与实际数据脱节 若继续沿用"单点修复"模式，将带来明确隐患：修复永远滞后于业务；同类问题分散，重复劳动量大；规则逻辑高度依赖个人记忆，不利于交接；回归测试成本持续累积，一处硬规则错位可能影响多处逻辑。
二、寻找问题的共性问题
多月数据支持、新增地区维度、修复同比环比基准三项任务，经分析它们本质上都是硬编码导致的适应性问题，因此整合处理，寻找他们的共性解决问题。 财务底稿中1~5月数据并存，但工具此前仅输出1月结果。表面看是循环逻辑不完整，实际是工具聚合口径缺少"月份"维度——若源数据出现跨月情况，后写入的月份会覆盖前面的数据。因长期单月跑数，该隐患从未暴露。 优化动作：改造补全了月份维度，并统一处理财务底稿中多种日期格式，借此次需求一并封堵潜在口径漏洞。 财务要求在取数结果中新增"地区"字段。最朴素的改法是将后续列整体后移一位，但实际影响面很大。根本原因是工具下游一直按"列的位置"而非"列的名字"取数，列顺序一变，下游逻辑就要全部调整。 优化动作：借此将下游取数逻辑统一改为按字段名匹配。此后财务调整列顺序、插入新列，只需在配置中修改一行即可，无需改动工具代码，将"新增一列"从工程改造降为简单配置维护。 切换到5月跑数时，所有同比环比未计算。排查后发现问题具有典型性：报表模板中的月份表头是早期版本固化的字符串，工具运行时只读不写。工具以为在计算7月数据，模板仍停留在1月，两边口径不匹配导致计算失败。 优化动作："模板实际内容"与"工具对模板的认知"两个未对齐。将模板月份改为由工具运行时统一生成并覆盖。
三、重新理解交付物的本质
工具内部的数据存储格式是技术问题，但交付给业务的产物必须完全贴合业务习惯。信息齐全不等于好用，易用性比信息密度更重要。 第一版取数明细报告整理成了Json文件，我处理是方便了，但可能增加使用者的使用困难程度，后面我将内容输出成了Excel，然后通过分项目跟会计科目进行整理，这样我感觉能增加易用性跟快速根据问题查找校验报告。 工具最终使用者是财务同事，他们判断"好用"的标准不是"信息是否齐全"，而是"能不能快速查找数据跟快速点定位问题"。第一版报告过于技术化，未充分站在使用者角度设计产物形态。 重做后的校验报告做了三个关键调整：
- 结构贴合业务：按"项目→科目"两级组织目录，贴近财务日常查找路径；
- 文件颗粒度拆解：将大文件拆分为总览+命中/排除/分摊三类明细，每个文件可独立打开审核；
- 交付界面隔离：中间过程文件保留用于后续追溯，但不直接交付给财务。 经验沉淀：
四、总结与后续计划
本次优化核心是将工具从"业务一变就要追着改"的被动状态，调整为"业务有调整时工具能自主适应"的主动状态。这一调整虽不带来新功能，但能显著降低后续维护成本，提升工具的可靠性和可交接性。 工作逻辑： 从财务具体反馈出发 → 确认问题真实性 → 追溯根因判断是否为共性问题 → 识别高频触发点 → 将硬编码规则迁移至配置层 → 用历史与当前月份数据交叉验证，确保改造不引入新偏差。 后续工作计划：