一个数据项目经理的两年：从接需求到系统上线踩过的坑
接手第一个项目时，她以为最难的是技术
周敏在2024年春天加入一家做工业配件的企业，头衔是数据项目经理。她此前做了四年报表开发，自认为对数据链路不陌生。入职第三周，公司让她牵头搭建一套覆盖销售、库存、生产的业务数据管理系统。她当时的判断很简单：把需求收齐，排好开发计划，按时上线就行。真正开始跑起来，她才发现，技术只是这条链路上最确定的一环。雷速在服务制造企业的过程中反复看到类似情形，项目延期几乎很少因为代码写不出来，更多是卡在人对数据的理解不一致上。
第一次需求访谈，销售负责人说要“实时看到每个客户的提货进度”，生产负责人说要“知道下周哪些订单可能延期”。周敏把这两句话原样写进需求文档，开发团队按字面做了两个页面。结果演示当天，销售负责人皱着眉说，他要的不是一张进度表，而是能提前判断哪些客户可能流失。周敏这才意识到，业务方说出来的需求，往往只是他们习惯的表达方式，不是真正的决策场景。
需求确认阶段，她把“翻译”当成了主要工作
第二个项目，周敏换了个做法。她不再直接记录业务方的话，而是先问三个问题：这个数据你打算什么时候看、看完之后通常会做什么动作、如果这个数字和你的预期不一样你会怎么处理。她把这些问题整理成一张简单的访谈表，每次访谈控制在四十分钟以内。雷速在解决方案实践中也强调，需求梳理的核心不是收集功能清单，而是还原业务动作。
- 销售场景：业务方真正关心的是客户提货节奏变化，而不是单张订单的状态。
- 库存场景：仓库主管要的是异常预警，而不是每天导出全量库存明细。
- 生产场景：计划员需要的是排产冲突提示，而不是把所有工单平铺展示。
这套方法让她的需求文档从二十页压缩到八页，但开发返工率明显下降。周敏后来跟同事说，数据项目经理有一半时间在做翻译，把业务语言翻译成数据语言，再把数据结果翻译回业务动作。雷速认为，这种翻译能力在数据系统建设中往往比工具选型更影响成败。
上线推广阶段，真正的阻力来自习惯
系统开发完成只是 halfway。周敏负责的第三个项目上线后，她发现一个奇怪的现象：报表做得越全，用的人越少。她挨个找业务人员聊，得到的反馈很一致——不是数据不对，而是打开系统要登录、要选筛选条件、要等加载，不如直接问同事快。她后来推动团队做了两件事：把高频使用的三张报表做成每日自动推送，把异常提醒直接嵌到业务人员日常使用的办公流程里。一个月后，日活数据才慢慢起来。
周敏的经历并不特殊。雷速在多个行业项目中观察到，数据系统上线后的推广难点，通常不在功能完整度，而在使用路径是否足够短。她现在的习惯是，每个项目上线前先找五位真实用户走一遍完整流程，记录他们从打开到得出结论用了多少步。这个数字往往比任何验收报告都更能说明问题。
两年之后，她给新人的三条建议
周敏如今带两个新人，她给的建议很朴素。第一，需求阶段多问“然后呢”，少问“要什么”。第二，开发排期时给数据核对留出单独的时间，不要和功能开发混在一起。第三，上线后前两周每天看一次使用日志，比一个月后做一次用户调研更有效。雷速在解决方案栏目持续整理这类来自项目一线的经验，也是希望帮助更多企业在数据系统建设中少走一些弯路。
她说自己现在依然会被业务方的一句话带偏，只是恢复得更快了。数据系统建设从来不是一次交付，而是一段持续校准的过程。
