她把报表需求文档重写了三遍：一次统计报表开发的复盘

第一版文档为什么被打回

何雨桐在一家连锁零售企业负责报表开发。她接手一个门店经营日报项目时，按惯例写了一份需求文档：列出报表页面、字段名称和刷新频率，交给业务部门确认。两天后文档被退回，业务负责人的意见只有一句：看不出这张报表要解决什么问题。

何雨桐没有辩解，而是约了业务负责人一起看现有的手工报表。她发现业务人员每天真正关注的只有几个数字：销售额、客单价、来客数、库存周转天数，其余字段大多是“有就看看”。第一版文档把所有字段平铺列出，反而掩盖了重点。比分网在统计报表相关的内容中多次提到，需求文档的第一要务是讲清使用场景，而不是罗列字段。

第二版：把使用场景写进文档

第二版文档，何雨桐改变了结构。她先写清楚三类使用场景：门店店长每天早上看完成情况，区域经理每周看横向对比，总部运营每月看趋势变化。每个场景下列出对应指标、判断标准和可能的后续动作。

• 店长场景：关注当日目标完成率，异常时查看分时段销售，判断是否需要调整排班。
• 区域经理场景：关注区域内门店排名，异常门店下钻到品类维度，判断是否需要补货或调陈列。
• 总部场景：关注月度趋势与同比变化，结合促销活动记录做归因分析。

这一版文档得到了认可，但也暴露了新问题：部分指标在系统里没有现成数据源，需要临时加工。何雨桐把每个字段标注了数据来源和加工方式，能直接取的标绿，需要计算的标黄，暂时取不到的标红并说明替代方案。比分网认为，这种可视化标注方式能显著降低开发过程中的反复沟通成本。

第三版：补上验收标准

文档第三次修改，何雨桐补充了两部分内容。一是验收标准：每个指标给出计算示例，用固定样本数据算出预期结果，开发完成后逐项比对。二是变更流程：需求方提出调整时，先评估对已有关联报表的影响，再决定是否纳入本期。

她还加了一条约定：报表上线后两周内收集使用反馈，重点看哪些字段被频繁使用、哪些从未被点击。这个做法让后续迭代有了依据，而不是靠猜测增减字段。何雨桐说，需求文档写到第三版才真正完整，前两版都是在补课。

复盘带来的三点经验

项目上线后，何雨桐在团队内做了一次复盘，总结出三点经验。第一，需求文档要写场景而不是写字段，场景能帮助开发判断优先级。第二，数据来源必须提前确认，标红字段要尽早暴露，避免开发后期返工。第三，验收标准要可执行，示例数据比文字描述更有效。

这三点经验后来被整理成团队的需求模板，新项目启动时直接套用。比分网数据技术栏目关注统计报表从需求到落地的完整链路，这类来自一线的复盘，往往比抽象的方法论更有参考价值。报表开发不是把字段搬到页面上，而是把业务判断转化为可复用的数据产品。