从业务问题到系统界面：我们如何把需求转化为解决方案

当一位经理对我们说“我需要更好地控制信用”时，他要的并不是一个界面。他描述的是一个业务问题：客户不付款、发货没有依据、应收账款不断增加。我们的工作，就是把这个问题转化为系统能够执行、验证和衡量的东西。

四个层次

1. 业务需求（“为什么”）。 用企业的语言表达的目标。“在不影响销售的前提下，减少逾期应收账款。”
2. 业务规则（“决定什么”）。 企业制定的政策。“客户超出信用额度时不予发货，除非信用部门批准。”
3. 功能需求（“系统做什么”）。 具体且可验证的行为。“确认赊销订单时，系统计算客户的风险敞口；如果超出额度，订单将被冻结。”
4. 验收标准（“如何确认它有效”）。 在编程之前写好的测试用例。

跳过任何一层，都是项目“能运行”却什么问题也没解决的最常见原因。

我们的做法

• 倾听问题，而不是解决方案。 如果用户要求“一个冻结客户的按钮”，我们会问为什么。背后几乎总有一条更普遍的规则。
• 与企业一起写下规则。 规则由业务方决定。我们负责把它们明确下来，包括例外情况以及由谁审批。
• 用实例落实到功能层面。 每条功能需求都附有使用真实数字的具体示例。
• 在编程前定义验收标准。 采用测试驱动开发，每条规则从一开始就有对应的自动化测试。
• 在冲刺中与关键用户一起验证。 不是等到项目结束，而是在每两到四周的交付中进行。
• 衡量结果。 业务需求有其目标；上线后我们会复查相应的指标。

案例 1：一家赊销缺乏管控的批发商

业务问题。 销售人员在接赊销订单时不知道客户欠了多少钱；逾期应收账款不断增加，信用部门总是很晚才发现。

业务规则。

• 每个客户都有信用额度。
• 风险敞口 = 客户已欠金额 + 正在确认的订单金额。
• 如果风险敞口超出额度，订单将被冻结；只有具备权限的人员才能放行。
• 客户的预付款在订单开票时扣除。

功能需求。

• 确认赊销订单时，计算风险敞口并与额度进行比较。
• 如果超出，将订单标记为冻结并通知信用部门。
• 被冻结的订单不能发货，也不能开票。
• 开票时，自动抵扣客户的预付款。

验收标准（示例）。 假设某客户的信用额度为 Bs 50,000，已有 Bs 42,000 的欠款，当销售人员确认一笔 Bs 12,000 的订单时，那么该订单被冻结，信用部门收到通知，发货按钮被锁定。

案例 2：一家不清楚真实成本的进口商

业务问题。 销售价格是按供应商发票金额计算的，没有计入运费、保险费、海关费用和本地费用。有些产品在亏本销售，却没有人察觉。

业务规则。

• 进口产品的成本包含进口的全部费用。
• 每项费用按既定基准在各产品之间分摊：价值、重量、体积或数量。
• 最终成本在进口卷宗结案时确定。

功能需求。

• 一个进口卷宗汇总供应商发票及所有相关费用。
• 每项费用可选择各自的分摊基准。
• 结算时，系统计算每个产品的最终单位成本，并更新库存成本。
• 根据最终成本，按目标毛利率给出建议销售价格。

验收标准（示例）。 假设一批货物中有两个价值相同、重量不同的产品，当运费按重量分摊时，那么较重的产品承担更多运费，其单位成本也相应体现。

为什么这很重要

一个被正确落实为功能需求的业务需求，可以测试、可以维护，也可以衡量。落实得不好的需求，最终会变成一年后谁也看不懂的定制开发。

本文的两个案例最终都成为 MKA 中的流程；第一个可以在订单与发货演示中完整体验。