3.1 需求工程：发车前核对货单

3.1 需求工程：发车前核对货单

列车从本章正式开跑，第一站是需求工程。第 2 章选运行图时反复出现"需求稳不稳"，本节就负责把需求做稳：从客户的话里挖出真实诉求，写成可验证的条目，冻结成基线，再给后续变更修一条有闸口的通道。本节承上——它消费第 1 章的产品经理角色与原则；启下——它产出的货单是第 3.2 节设计图纸的唯一依据。

一张会撒谎的货单

客户说的需求经常不是他要的东西。经典段子是要一匹更快的马，现实版本更日常：仓库主管说"给我加个批量导出按钮"，他真正的诉求可能是"月底和承运商对账太痛苦"。把按钮做出来，对账痛苦一分没减；把对账流程改顺，也许根本不需要那个按钮。需求工程的第一课：用户表述的是方案，工程要还原的是问题。

业内把需求分成四层，核对货单时各层要对号：

• 业务需求：组织为什么要做这件事——降低对账人力成本、减少错账赔付；
• 用户需求：哪类使用者要完成什么任务——仓库管理员月底导出对账单；
• 功能需求：系统必须做什么才能支撑上述任务——按仓库与月份过滤、导出含三列金额；
• 非功能需求：质量约束——五万行内导出不超时、金额精确到分、操作留审计痕迹。

四层里最常被漏记的是非功能需求。功能没实现一眼可见，"导出太慢""并发一高就挂"这类问题往往上线才爆发。补的办法是把非功能需求也写成带数字的条目，不许写"性能要好"这种无法验收的话。

图 3-1：从客户言语到需求基线的漏斗

把需求写成可验收的条目

合格的需求条目有四个要件：唯一编号、明确主体、可测的验收标准、可追溯的来源。下面是云梯平台真实货单里的一条，两种写法对比：

坏写法：
  支持对账单导出，要求快、好用。

好写法：
  编号 REQ-ACC-014
  来源：仓库主管座谈会 4 月记录第 12 条
  描述：仓库管理员可导出指定月份的对账单，
        用于与承运商逐笔核对。
  验收标准：
    A1 可按仓库、月份过滤，默认本月全部仓库
    A2 导出内容含运费、补贴、扣罚三列，金额两位小数
    A3 五万行以内导出耗时不超过 30 秒
    A4 导出动作记入操作审计日志
  优先级：高（对账流程线上化的前置）
  状态：已评审 · 进入基线
​

注意 A3、A4 这两条：一个限性能，一个限合规，都带数字或可判定的动词。"要求快"永远验收不了，"五万行 30 秒"一声哨响见分晓。验收标准写不出数字时，逼问自己：验收那天，用什么动作判定它过关？答不出，说明这条还没想清楚。

变更控制：给道岔装闸把

基线之后需求还会变——变不是罪，失控地变才是。变更控制的核心是一个五步闸口：提出（书面）→ 评估影响（工期、成本、波及模块）→ 决策（变更委员会或产品负责人按额度授权）→ 更新基线与计划 → 通知所有受影响方。闸口的价值不在于拒绝变更，而在于让提变更的人看见代价——多数变更在看见代价后会自己撤回或降级。

⚠️ 需求工程最贵的坑是"口头同意"。会上口头答应的需求没进基线，三周后双方对"当时说好了什么"各执一词——这种纠纷没有技术解，只有记录解：没进基线的需求视同不存在，要上基线就走过闸。

原型：让"说不清"变成"看得见"

对付"用户自己也说不清"的需求，最便宜的工具是原型——用界面草图或简陋可点的样例把假设摆出来。它的价值不在演示美观，而在把误解的发生时间从测试阶段提前到需求阶段：人对着画面挑毛病的能力，远强于对着文档想象画面的能力。云梯的司机端查询功能先用两天的界面原型在三个仓库巡了一圈，收回来一批"按钮要大""晚上躺卧区光线暗要深色"的反馈——这批反馈若等真实界面开发完再收集，返工至少翻倍。原型的纪律是"便宜到敢扔"：一旦团队舍不得扔原型、开始给草稿精雕细琢，它就从需求工具变质为负债。

需求评审会怎么开才不是走读

需求评审的常见失败是逐条念文档，与会者人到心不到。有效开法是会前分派、会上只议分歧：评审人提前拿到基线草稿，按"验收标准可测吗、与其他条目冲突吗、超没超出业务理由的边界"三个角度提交书面意见；会议议程只包含有分歧的条目，无异议的批量过。云梯的需求评审记录长这样：

需求评审记录 · 基线 v1.3 草稿
  到会：产品 · 架构 · 测试 · 两名仓库主管
  无异议通过：REQ-ACC-010 至 013（批量）
  有分歧条目：
   REQ-ACC-014 之 A3（五万行三十秒）
     测试：现环境跑不到，需压测环境排期
     裁决：目标保留，验收改在压测环境执行
   REQ-ACC-015（按承运商维度汇总）
     主管甲要 · 主管乙称用不上 · 争议超二十分钟
     处置：移出本基线，进商业论证池，本班不做
  结论：基线 v1.3 定稿，两条修订记录归档
​

注意第二条的处置方式：争议条目移出基线，而不是当场说服——把"要不要做"的分歧从"基线是否冻结"里剥离，冻结才有公信力。

需求的两种寿命：班次内与跨版本

管理需求条目时，寿命是个常被忽略的维度。班次内需求（本班交付的小改动）走轻量通道：验收标准写进任务卡，评审在计划会当场完成；跨版本需求（新模块、大改造）走重通道：完整条目、独立评审、进基线、排进路线图。两种通道混用的典型事故是重需求走轻通道——某个数据模型改造被当成"小任务"塞进班次，结果半途发现牵动五个模块，班次报废。判别问句只有一句：这条需求要不要动接口或数据结构？要，就走重通道，没有例外。给需求分寿命，本质是给变更的成本提前定价。

两个高频疑问

问：客户不配合评审，基线怎么立？ 降维求其次：评审会可以不开，但书面确认不能省——把基线摘要成一页"将做与不将做"清单发给对方，请其书面回执。回执拿不到的，把发送记录与催办记录存档。闸口的本质是留痕与共识，不执着于会议室的形式。

问：非功能需求该定多严？ 以"验收动作能落地"为界。定"查询响应一秒内"，就要确认验收那天用什么环境、什么数据量、谁认可结果；定不出来就放宽到可执行的程度。一个无法验收的严格目标，还不如一个能验收的宽松目标有用。

本节要点回顾

• 用户的表述是方案，工程的起点是问题；需求按业务、用户、功能、非功能四层核对。
• 非功能需求最易漏记，必须写成带数字的可验收条目。
• 合格条目四要件：唯一编号、明确主体、可测验收标准、可追溯来源。
• 验收标准的自检问句：验收那天用什么动作判定过关。
• 变更走五步闸口，价值在于让代价可见；口头需求视同不存在。

货单冻结，下一站开进设计车间——把纸面承诺画成能装配的图纸。