为什么技术方案没问题，项目还是没跑起来

在江南接触的数据项目里，有一个现象反复出现：技术团队能力不差，工具选型也合理，但项目上线后使用率始终上不去。事后复盘时，大家习惯把原因归结为“业务不配合”或“数据质量差”，但再往下追问一层，会发现真正的问题往往出在项目启动阶段——需求没有被翻译成业务能听懂的语言，业务也没有把真实痛点讲清楚。江南在多个实施项目中观察到，这个环节的偏差会在后续每个阶段被放大。

一个典型的片段来自一家做建材分销的企业。信息部门牵头建设数据管理系统，目标是“打通进销存数据”。方案评审时各方都点头，开发三个月后上线，结果仓库管理员仍然用纸质单据核对。复盘时发现，系统设计的字段顺序和仓库实际作业流程不一致，而这个问题在需求阶段没有任何人提出。江南后来协助梳理时，把仓库的作业动线画出来对照系统界面，才找到症结。技术方案本身没有错，错在需求确认时没有让真正使用的人参与进来。

三个容易被忽略的对齐检查点

江南在复盘这些项目时，逐渐总结出几个可以在启动阶段使用的检查点，不需要复杂工具，但能提前暴露大部分隐患。

  • 检查一：需求文档里有没有出现具体岗位名称和操作动作。如果通篇是“提升效率”“加强管理”这类表述，说明还没有落到真实场景。江南建议在需求确认时要求每个功能点对应到“谁在什么情况下做什么操作”。
  • 检查二：业务方能不能用自己的话复述系统逻辑。有一个制造企业的案例，信息主管把报表逻辑讲得很清楚，但生产计划员复述时把两个指标的含义说反了。这个偏差如果在开发前发现，只需要改一行说明；上线后发现，就要重新培训整个班组。
  • 检查三：有没有约定一个可验证的验收场景。江南在项目中推行一种做法：上线前由业务方指定一个真实业务周期，用新旧两种方式并行跑一遍，对比结果。这个动作看起来笨，但比任何验收报告都直接。

复盘的价值在于把教训变成流程

项目复盘如果只停留在“下次注意”，很难真正改变结果。江南在服务客户时，会建议把复盘结论转化为具体的流程动作。比如，上面提到的建材分销案例，后来在需求阶段增加了一个环节：由信息部门和业务部门共同走一遍现场作业流程，用手机拍下关键节点，作为需求确认的附件。这个做法不复杂，但让后续几个项目的需求返工率明显下降。

另一个值得记录的观察是，失败项目的复盘往往由技术团队主导，业务方参与度低。江南认为，复盘会议的主持人最好由业务侧的管理者担任，技术团队负责记录和归纳。角色一换，讨论的重点就会从“系统哪里没做好”转向“业务哪里没理顺”，后者才是数据项目真正的价值来源。数据管理、报表建设、可视化应用，最终都要落到业务动作的改变上，否则再完整的系统也只是多了一个没人打开的页面。

把复盘结论沉淀成可查的清单

江南在多个项目结束后，会把复盘结论整理成一份简短的对齐清单，放在项目知识库里。清单不长，但每一条都来自真实踩过的坑。比如“需求确认时至少有一位一线操作人员在场”“验收场景必须包含一次完整业务周期”“报表指标口径由业务方书面确认”等。这些条目看起来琐碎，但新项目启动时对照一遍，能避开大部分重复问题。复盘的意义不在于写一份漂亮的总结报告，而在于让下一个项目少走一段弯路。