在产品刚开始开发时，因为设计和运维方案不完善，后期常常会进行修改数据等调整操作。这种时候，在各个协同的岗位眼里，是一个什么操作？我们来看看作者的分析。

【产品经理小白】：没事儿别改数据好不好！

修数据修数据，在我做B端产品经理前两年的产研经历中，倒是不少听到开发人员（主要还是服务端程序员）提及修复数据，提sql。要知道这都是上帝之手，时光倒流，机关巧妙说不定就被触发了啊！

粗犷的研发初期，因为产品和运维方案的不完善、应急预案、兜底机制的缺失，不排除会导致从产品功能层面的数据不闭环，出现业务死锁，无法进行的局面，往往初创不规范的阶段会采用直接修数据，也称为“改库”。我想对应到人体大概属于，直接换骨头、移植器官。

【业务人员小黄】：修数据是什么？

一个产品是包含了数据、业务逻辑、系统逻辑的解决方案集合。各种逻辑的实现又依赖程序，程序是按照一定的规则和顺序的任务执行过程，是一套指令集合，在软件开发中，程序由数据结构和算法组成。

由此可见，数据本身其实并不关心上层的各种指令集合和逻辑。数据它就以自己最优美而舒服的姿态存在就好。

人为修数据，就是越过山和大海（各种业务逻辑、系统逻辑和校验、数据关联），直奔数据库改动值。比如：将日期类型的字段从2008-01-01改为2028-10-01、将数量从10改为1000（如果你的银行账户可以改，哦，不要太爽！）。

【管理者小菜】：这是一个什么级别和性质的动作？

数据可以说是在严密的业务、系统、程序逻辑结构框架中，经过业务输入+逻辑指令的框架构建和判断，最终形成数据的写入、修改、查询、删除。

比如：在微信上对手机话费充值，简单点需要最终把你微信账户余额的数字改小、手机卡话费账户余额的数字改大。如果你有修改数据的权限，可能出现的是，你的微信余额有多少钱你说了算。月光宝盒不过如此，你随意的穿梭时空，无视世界的运行和发展，修改天道玄机。

【程序员小星】：修数据有什么风险吗？

首先是体验秩序的打破，社会能够稳定运行是因为社会秩序的建立，法律、道德、组织、宗教、经历、历史各个维度互相交纵并拥有一套运行的规律。

我们天天快乐耍手机，是因为有一套稳定的运行程序，可以给用户确定性的逻辑，如果faceid识别之后是关机、微信发图片是视频电话、删除聊天是自动转账。面对混沌的表现，用户侧面临巨大的隐患，没有用户行为输入而产生的结果，伤害的将会是用户最宝贵的信任。

无视系统逻辑、产品逻辑的数据修改，同时可能造成上层逻辑的短路、断路，反噬产品。也在削弱产品自身应该考虑和完善的东西。产品和程序的逻辑本身如果不能够完善，我只能说这是产品经理和开发者必须承认的锅。

业务风险巨大，就如你有一双摸金手，怎么可能一直去搬砖呢？从管理的视角，我们希望体系的运行是基于完整的业务和逻辑框架，而非业务的断路+数据的操控，这本就是失败品。

为什么会需要修数据？

产品功能缺失、产品逻辑不闭环、代码bug、无法业务补偿还原、跨系统的数据不一致，以及系统闭环功能之外的业务诉求，面对以上无法通过业务方式进行数据修正的情况下，不得不去做的妥协…

再加上一条：时间限制，以上的外界约束条件导致业务、产研团队走向将修数据的处理方式作为当下最优解。理论上我们应该优先通过程序增补的方式，让业务人员通过系统操作的方式自行完成数据的修正，方为良策。

怎么避免修数据？-切准用户诉求、早做风险识别/评估、做好风险处理预案

• 从产品概念设计到产品架构设计、技术架构设计，功能框架设计、交互体验设计，各个层次都需要充分的对标业务目标，确保支撑业务诉求的一致性，也可以说：业务、产品、代码、技术设计的一致性；
• 实现容错、补偿等机制的考虑和建设，会大大降低修数据的概率。这部分属于风险处理-自留处理的范畴，
• 研发过程的质量把控更不容小觑，交付出具备可用性的产品是整个团队的目标，开发者为代码质量、测试为文档要求，而产品经理一定要为用户负责
• 风险的评估需要全面，项目资源风险、业务实施风险、外部政策风险等，甚至于服务器压力风险，都可能会最终导致修数据

以上的内容，乍看起来有不少离产品经理很远，比如：技术架构设计、开发者的核心代码逻辑实现、业务上的降级预案，虽然不少团队还会有诸如pmo、实施团队的防线，但确都是一名优秀产品经理不得不具备的素质。