【项目跟进】避坑指南（2）- 做的系统没人用

背景

做的系统，本文是指的对内和2B客户用，本质还都是2B公司内部的人员使用。
之所以这个会成为数据人的痛点，是因为2C的产品基本都严密论证，做不好大家一起背锅。
但2B的产品有问题，很多时候可能是产品设计不完善系统功能不支持，但被迫增加工作量的都是数据人，背锅和加班的也是数据人。

常见场景比如：

• 系统功能没法用，你线下给我导数据吧
• 没有修改功能，你后台给我改下数据吧
• 研发说该数据就要发版，还是数据这边改最方便
• 这个数据有问题
• 数据源有问题，你需要加个XXX逻辑判断，研发那边不好改
• 研发说下个版本改，这个版本先手工弄下
• 这东西没法用

原因猜想

很多时候，数据人也是系统中的一个环节，也要参与开发工作，而很多时候变成最后的维护者和运营人员。

• 系统不好用，不是业务人员吹毛求疵
  一个小功能点不能用，导致预期结果不能输出，基本等于系统没法用了。有时业务为了完成工作，甚至愿意用excel，虽然工作量激增，但有保障啊。
• 预算不足
  对内的系统，只要能用就行，老板一般不会给太多预算，所以很多功能也是一砍再砍。比如给个几百万，就想要微信+飞书的功能，臣妾真的做不到。
• 业务没想清楚
  业务每天面对工作很杂，当产品调研需求时，一般不会想的很全面，说一些大的方向，等到产品做好开始用了，才会后悔之前没提好多需求，也不好说什么。而且很多时候调研的不是一线人员，高等级人员关注的功能还是有些区别。
  一般来说，业务永远都想不清楚，想的清楚系统早就做出来了。
• 产品不完善
  业务需求一般都很杂很乱，不可能一两个版本做完。产品经理一般都会排很多个版本，而很多时候，底层的声音甚至都会被排到后续的版本中，优先满足大老板需求。
• 开发没重视
  业务失去的只是饭碗，但开发失去的是周末休息的权利啊。
  有时开发严格按需求来，有些很重要的需求，因为不好做，或者好像不重要，开发和产品一合计就往后排了。
• 数据有锅
  产品推广了不会不能用，一般就是某些功能不支持，只能后台改。后台开发改东西基本要发版，所以修改的动作都压到数据这边，数据工作量激增。

考虑点

无论是数据还是产品，其实都可以在系统设计时多考虑些点：

• 业务全面熟悉
• 主流程影响
• 准备预案
• 留下后门
• 规范流程
• 分析监测
• 培训教育

详细方案

业务全面熟悉

系统的研发，很多时候是业务知识的沉淀，所以最好能全面熟悉业务。
如果有行业相关工具书，可以买一本参考，知道整个体系会包含哪些内容。我曾经认为买教科书学习是很麻烦的方法，又不是学生，学完几个方向才发现，真香，什么都给你写好了有木有，总结的太全面了，就差用代码实现了。

主流程影响

一般来说这个是最核心的，主流程走通就能上线了。但也需要注意，主流程包含了哪些环节。
假设每个环节都会出问题，则可以梳理出来哪些功能要多注意的。很多时候产品只梳理主流程，而不关注哪些因素影响主流程

准备预案

假设自己设计的软件天然就有缺陷，则需要梳理准备下预案，避免出问题时没法解决。
反向也是让自己了解，研发只看主流程还不够。想象自己就是抢银行的赫尔曼·卡尔·拉姆，这么难的事情，怎能没有预案呢。

• 系统数据丢了：做好备份机制，提前知道备份数据在哪，可以怎么恢复
• 系统挂了：那要有其他系统顶上，下游系统最好有保护机制，不要影响操作
• 系统计算出问题：监控数据情况，评估数据量级，定制脏数据处理流程，及时停止操作
• 性能扛不住：关注扩容流程，注意保障系统是能扩容的；定位是哪里引起性能问题
• 未按时上线：提前关注风险，严格按照时间计划执行，保证未来团队正常进展；周知各方。
• 异常情况要处理：后台改数据
• 源数据有问题：源数据防御处理机制；定制后处理方案，因为源数据有问题就拦截，基本要出事
• 人工维护数据有问题：推动人工优化，增加识别异常模块
• 计算逻辑不匹配：最好使用规则引擎之类的，最不济也是要有调整数据方案
• 算法效果不好：随时回滚历史版本，再定位问题
• 特征偏移：重新建模，并发布上线
• 输出结果有异常：增加后处理流程
• 统计结果不对：线下统计
• 。。。。。

这一轮梳理后，就会发现，之前评估的研发时间还不够，以及产品经理的文档，考虑的也太简单了。

留下后门

业务流程，很多时候也是对数据的处理，则会遇到以下问题：

• 功能不完善，就要后台改数据的问题。
• 数据源有问题，一旦进了系统，就影响后续服务了。
• 分析不够完善，要自己分析
• 需要查明细定位问题
• 实时好过离线，刷新速度越快越好
• 留下数据调整证据

所以要注意留好后门，能够方便的输入和输出数据，减少工作量。

规范流程

功能是做不完的，但流程要规范，不然大家都要加班：

• 需求沟通规范：不要随便接不合理需求，不然大家都要加班，年底还没绩效
• 研发流程规范：上下线有保障
• 数据验证规范：不能接入问题数据，不然后期很难清理
• 异常处理规范：虽然有留后门，也不能随便改，留好有标准流程
• 权限规范：控制使用权限，避免扰乱数据，也避免被人盗走数据

分析监测

老板做系统，一般还有隐形的需求，就是把所有流程都标准化监控。所以监控看板不能少。
功能用的好不好，不能只看人说，不然永远会关注鸡毛蒜皮的功能，还是要有监控指标，从宏观进行分析。

培训教育

标准的培训流程，从目标到使用手册。完整的文档省去太多沟通的工作。
每个功能旁边都有介绍就更好了。
相信我，时间长了，设计者自己都不一定知道这个功能咋用的。

后记

对内的产品，也好做也不好做，把握住重点，就更能得心应手。