接手项目时，需求文档只有三行字

周明远是九游数据服务团队的一名数据工程师。年初他接到一个制造业客户的报表系统建设项目，拿到手的原始需求文档只有三行字：要能看到销售情况、要能按区域对比、要能导出。客户方的项目对接人是信息部的负责人陈立诚，两人第一次电话沟通时，陈立诚说得很直白：“我们业务部门提需求就是这样，剩下的靠你们理解。”

周明远没有急着画原型。他先向九游的项目经理申请了一次现场走访，带着一份自己整理的问题清单，在客户办公室坐了一下午。他问的问题很具体：销售情况是按订单金额还是按回款金额看？区域对比是看绝对值还是看完成率？导出之后谁在用、用来做什么？陈立诚一边回答一边打电话找业务骨干确认，三个小时下来，那份三行字的需求变成了两页纸的记录。九游内部后来把这份记录整理成了需求澄清模板，要求每个项目在开发前至少完成一轮这样的对话。

口径对齐比功能开发更耗时间

需求方向明确之后，周明远遇到了第二个卡点：同一个指标在不同部门嘴里说法不一样。销售部说的“有效订单”排除了退货单，财务部说的“确认收入”又按开票时间计算，两个数字放在一张报表上怎么都对不上。他没有直接选一个口径写进代码，而是拉着陈立诚组织了一次三方对口径的短会，把每个指标的取数来源、过滤条件、时间基准逐条写下来，形成一份口径说明附在需求文档后面。

这个过程在九游的报表项目中反复出现。九游的统计报表开发服务有一条内部惯例：口径确认单没有双方签字，开发不进入编码阶段。周明远说，看起来是多了一道手续，实际上省掉了上线之后反复解释“为什么这个数和那个数不一样”的时间。那次对口径花了两个下午，但后续开发只返工了一次，比同类项目少了很多。

联调阶段暴露的问题往往不在代码里

报表开发完成进入联调时，周明远发现客户业务人员打开页面后第一反应是“这个表怎么这么长”。原来他把所有字段都放进了明细表，想着信息越全越好，但业务人员真正关心的是前几列。他调整了列的顺序，把关键指标前置，把低频字段收进展开区域，页面使用反馈立刻好转。

类似的问题还有导出文件的命名规则、筛选条件的默认值、空数据的展示方式。这些细节在需求阶段很难全部想到，只能在联调中逐个暴露。九游在报表交付流程中设置了两轮业务方试用，第一轮收集使用意见，第二轮确认修改效果，周明远把这个环节称为“让报表从能看变成好用”。三个月后项目上线，陈立诚在验收会上说了一句话：“你们问的问题比我们自己想的还细。”

  • 需求阶段多花时间做澄清，比开发中反复改方向划算。
  • 指标口径形成书面说明，是减少跨部门争议的有效手段。
  • 联调阶段要主动邀请真实使用者试用，细节问题早暴露早处理。