问题定义与需求澄清

第 11 章 · 架构师成长

「需求都做完了，为什么业务还是不满意？」「我们按 PRD 做的，结果上线没人用。」 很多时候，失败不是因为实现不好，而是解决错了问题：把表象当根因、把方案当需求、没搞清用户要什么就开干。架构师和产品/业务一起，要把「问题是什么、为谁、达成什么目标」先厘清，再谈怎么做。本章讲如何区分表象与根因、区分需求与方案、理解用户目标与业务目标，在软件里如何用用户故事、用例与约束提炼需求，以及如何避免范围蔓延。

一、表象与根因：别在症状上猛下药

用户或业务说的往往是表象（「页面慢」「经常报错」「想加个导出按钮」），背后可能有多种根因（慢是因为接口慢还是前端渲染多？报错是环境问题还是逻辑 bug？要导出是为了对账还是为了汇报？）。若不对根因做一点追问，很容易在表象上堆功能，结果问题没解决、还多了维护负担。

常用方法：5 Why（连续问「为什么」直到触及可行动的原因）、问题树（把现象拆成可能原因，再逐条验证或排除）。目标不是非要找到一个「唯一根因」，而是避免把表象直接当需求，从而设计出更对准目标的方案。

左：错误路径——对着表象直接上方案。右：先澄清根因，再设计方案

5 Why 示例（简化）

为什么用户说「页面慢」？ → 列表加载要等好几秒。
为什么列表慢？ → 接口一次返回几千条。
为什么要一次全返回？ → 历史设计如此，没分页。
为什么没分页？ → 当时量小，没人提。
现在可行动的原因？ → 数据量上来了，需要分页或懒加载 + 接口改版。

追问到「可改的点」（接口与前端一起改），再设计方案，比一上来就「加个缓存」更对准问题。

二、需求与方案：别把「怎么做」当「要什么」

需求是要解决的问题、要达成的目标（What & Why）；方案是怎么实现（How）。很多人会直接说「我们要做一个 XX 功能」「加个中台」，这些往往是方案。若不加区分就照做，可能做对了方案、却解决了错误的问题，或者漏掉更简单的实现方式。

需求（问题 / 目标）

描述「谁在什么场景下有什么问题、希望达成什么结果」；不绑定技术形态。

「运营需要快速看到昨日订单异常」
「用户希望找回密码时不用等邮件」

方案（实现方式）

具体做法：功能、技术选型、流程。需求澄清后再讨论方案，并允许用不同方案满足同一需求。

「做一个监控大屏」 vs 「每日报表邮件」
「短信验证码」 vs 「安全问题」

需求 vs 方案：先锁定问题与目标，再谈实现

习惯问一句：「这是需求还是方案？若这是方案，背后的需求是什么？」能避免很多「做了没人用」或「做了一半发现方向错了」的情况。

三、用户目标与业务目标

用户目标：用户本人想达成的结果（例如「快点付完款」「查清楚这笔钱去哪了」）。业务目标：公司/产品要达成的结果（例如「提升转化率」「降低客诉」）。两者有时一致，有时不完全一致；好的设计是在满足用户目标的前提下达成业务目标，而不是牺牲体验硬推业务指标。

用户目标

用户想完成什么、得到什么。例如：快速下单、查订单状态、退款到账可追踪。

业务目标

产品/业务要的结果。例如：转化率、复购、合规、降本。设计时两者都要考虑，避免只盯业务忽略体验。

用户目标与业务目标需同时考虑，对齐后再拆需求

四、软件中的提炼：用户故事、用例与约束

在软件研发里，把「问题与目标」落成可开发、可验收的表述，常用用户故事（User Story）、用例（Use Case）和约束（Constraint）。

用户故事：「作为 [角色]，我希望 [做什么]，以便 [达成什么价值]」。强调角色、行为与价值，便于排优先级和验收。
用例：描述具体场景下的步骤、前置条件、后置条件、异常分支，适合复杂流程与对接。
约束：非功能或边界条件：性能、安全、合规、依赖系统、上线时间等，要显式列出，否则容易在实现时被忽略。

As a [role], I want [action], so that [benefit].

即：作为 [角色]，我希望 [做什么]，以便 [达成什么价值]。

例：作为买家，我希望在订单详情里看到物流轨迹，以便知道包裹到哪了、何时能收到。

用户故事模板与示例

约束要单独列：例如「列表接口 P99 < 500ms」「支付流程需符合 PCI 要求」「一期只支持国内手机号」。这些会直接影响架构与排期，不能藏在「尽量做好」里。

五、避免范围蔓延

范围蔓延（Scope Creep）指需求在未受控的情况下不断加码：「顺便把 XX 也做了」「再加一个小需求」。结果工期拖长、核心目标被稀释、质量难保。应对：明确本期范围与「不做」清单、变更走评审与排期、新需求进 backlog 而非直接塞进当前迭代。

核心范围 vs 蔓延：守住本期边界，新需求进 backlog

实践建议： 本期目标用一两句话写清；需求列表里标出「Must / Should / Could」或等价优先级；明确「本期不做」的几类需求；变更必须经过评审并调整排期或下期再做。

反例：把方案当需求、不追问根因，结果做偏。

业务说「我们要做一个数据大屏」，团队按「大屏」做了一版：多图表、实时刷新。上线后使用率很低。后来发现业务真正需要的是「每天一早能看到昨日异常订单汇总并导出」，大屏只是他们随口说的形态。若一开始问清「谁、在什么场景、要解决什么问题」，可能用一份每日报表邮件 + 导出就能满足，成本低、也更贴合习惯。再如：用户抱怨「提交总是失败」，团队直接加重试和提示，后来才发现根因是某地区网络对某个域名不稳定，改 DNS 或换接入方式更治本。把表象当需求、方案当目标，很容易做出「正确但无用」的东西。

小结： 很多失败源于解决错误的问题。要区分表象与根因（如 5 Why、问题树）、需求与方案（先 What/Why 再 How），并兼顾用户目标与业务目标。在软件中用用户故事、用例与约束把需求提炼成可开发、可验收的表述；同时避免范围蔓延，明确本期范围与「不做」清单，变更走评审。

自检： 最近接到的需求里，有没有被直接当成「要做的功能」的？试着用一句话说出「要解决的问题/目标」；若说不清，和提出方做一次澄清。再问：本期必须交付的是哪几项？「顺便做」的有没有列入 backlog 而不是塞进本期？

六、小结

问题定义与需求澄清是减少「做错题」的关键。区分表象与根因、需求与方案，明确用户目标与业务目标；用用户故事、用例与约束在软件中落地需求；避免范围蔓延，守住本期边界。下一章讲目标设定与成功标准：如何定义「做完」与「做好」、让目标可衡量可验收。