需求诊断清单：项目开始前该问清楚的十件事

一、需求不清，是项目里最贵的隐性成本

大多数软件项目的问题，不是在编码阶段出现的，而是在编码之前就已经埋下。需求没有问清楚，开发方就只能在假设上做设计；假设一旦和现实不符，返工、延期、争议就会接踵而来。

有意思的是，需求不清的成本往往不被记在账面上。客户看到的是「功能都做了」，开发方看到的是「需求一直变」，双方都觉得委屈，但谁也算不清究竟在哪里走了弯路。真正的问题在于：项目启动前，有很多关键问题没有被明确问出来，而是默认「到时候再说」。

这篇文章给出一份可以直接使用的需求诊断清单，包含项目开始前应该问清楚的十件事。它不是走流程的表格，而是十类容易遗漏、又足以影响项目成败的信息。清单之后，我们还会说明这些问题背后的共同逻辑，以及怎么把它们用起来。

如果你正在评估一个项目，也可以先结合 常见问题 页面看看有没有类似情况。整体服务范围见 服务与能力。

二、第一组：业务与目标

问题一：这个系统的「成功」如何定义

这是清单里最重要、也最常被跳过的一问。

「做一个系统」不是目标，只是手段。真正的目标可能是「把某类人工操作的时间降下来」「让数据能按时汇总」「减少某类差错」。同一句「做个系统」，目标不同，设计就不同。

问清楚这一点，需要在项目开始时就约定：这个系统上线后，用什么来判断它成功了。是一个业务指标（例如差错率下降），还是一个过程指标（例如某类任务完成时间缩短），还是纯粹的「替代现有的人工流程」。定义清晰的成功标准，会在后续每一个取舍决策中充当裁判——当两个方案都能实现功能时，选更靠近成功标准的那个。

问题二：现在这件事是怎么做的

不要只问「你要什么」，也要问「你现在怎么做」。

现状调研能揭示很多需求文档里不会写的信息：现在用的是 Excel、纸质单据、还是多个系统拼起来？过程中有哪些「约定俗成」的做法？哪些环节是低效但被习惯了的？哪些信息只在某个人的头脑里？

现状往往也是新系统最大的竞争对手——如果新系统的操作体验明显比现状繁琐，即使功能更全，用户也可能抵触。理解现状，才能知道新系统要替代的到底是什么，以及替代的难点在哪里。

问题三：数据从哪里来，可不可靠

很多项目的成败，取决于数据是否可得、是否可信。

需要追问的是：系统的输入数据来自哪里？是人工录入、其他系统推送，还是历史数据导入？如果是外部推送，推送方是否可靠、有无接口文档？如果是人工录入，谁来保证录入质量？历史数据是否完整、是否存在格式冲突？

数据问题的一个典型陷阱是：系统本身做得很好，但因为上游数据质量差，输出结果不可信，最后被归咎于系统。所以数据来源必须在诊断阶段就明确，并约定「数据质量由谁负责」。

三、第二组：边界与约束

问题四：并发与数据规模是什么量级

「多少人用」和「同时多少人用」是两个不同的问题。

需要评估的量级包括：日常使用人数、峰值并发人数、单次操作的响应时间要求、系统需要保留多少年的数据、单表预期行数。这些数字直接决定架构选择：几十人的内部系统可以简单设计，而促销期瞬时高并发的交易场景就必须考虑缓存、限流、异步与读写分离。

量级不必精确到个位，但必须有数量级的概念。如果完全无法估计，退一步的做法是先按保守规模设计，并明确记录「规模超出预期时需要额外评估」。

问题五：权限结构有几层

「谁能看什么、谁做什么」这个问题，答案往往比预想的复杂。

需要澄清的是：系统里有几类角色？角色是否跨越组织层级（例如集团与子公司）？同一个人是否会在不同场景下拥有不同权限？数据是否要按组织、按区域、按人员做行级隔离？权限变更是否需要审批与留痕？

权限结构一旦定错，后期调整的成本很高，因为它会渗透到几乎每一个功能里。因此权限模型适合在诊断阶段就画出来，而不是等到开发某个模块时才临时决定。

问题六：要和哪些外部系统集成，边界在哪里

集成是项目延期的高发区，必须在开始前把边界划清。

需要逐项确认：要对接哪些系统？接口由哪一方提供？有没有可用的接口文档与测试环境？认证方式是什么？数据格式如何约定？联调由谁牵头？如果对方接口出问题，责任如何划分？

一个实用的做法是画出「集成边界图」：本系统负责什么、外部系统负责什么、两者之间的接口谁定义谁维护。边界清楚，联调才顺畅。

问题七：有哪些合规与安全约束

这类约束常常在项目后期才被提出，而它恰恰是最需要提前识别的。

需要问的是：系统是否涉及个人敏感信息？数据是否允许出内网、是否需要私有化部署？是否有行业监管要求？操作是否需要全量留痕、能否追溯？敏感字段是否需要加密或脱敏？导出行为是否需要受控？不同行业的具体约束差异很大，可以参考 行业解决方案 中的拆解。

合规约束的特点是「早问成本低、晚问成本高」。在诊断阶段问清楚，才能把要求设计进架构，而不是后期打补丁。

四、第三组：交付与运维

问题八：验收口径怎么定

「做完了」需要一个双方都认可的判定方式。

验收口径至少要明确三件事：范围（哪些功能必须交付）、标准（每项功能达到什么状态算通过）、方式（怎么测、由谁测、在什么环境测）。如果只写「功能可用」，那在验收时几乎一定会有争议——因为「可用」的解释权在双方手里。

把验收标准写具体，对双方都是保护：客户知道自己会拿到什么，开发方知道什么算完成。完整交付过程可参考 交付流程。

问题九：最终使用者是谁，上线后谁维护

系统交付之后的故事，往往比开发本身更长。

需要确认：系统给谁用、他们愿不愿意用、需要什么样的培训；上线后谁负责日常运维；出现问题时联系谁；内容或数据由谁更新；后续迭代由谁承接。很多项目「上线即停滞」，根源就是没人在交付后继续负责。

维护责任越早明确，越能避免「上线后没人管」的局面。这部分也涉及文档与知识转移，属于交付的一部分，而不是额外服务。

问题十：需求变了怎么办

最后一问，也是最现实的一问：需求一定会变，变了怎么办。

需要约定一个变更机制：需求变更由谁提出、如何评估影响、如何计入工作量、是否需要调整排期与费用。机制的意义不是限制变更，而是让变更在可控的轨道上发生。没有机制的变更，最后就变成无休止的扯皮。

五、十个问题的共同点

把这十个问题放在一起看，会发现它们有三个共同特征。

第一，它们大多不是技术问题，而是边界问题。 要做什么、不做什么、由谁负责、到哪算完成——这些问题的答案决定了技术方案，而不是反过来。

第二，它们的成本都是「早知道便宜、晚知道贵」。 权限结构、合规约束、数据质量、验收口径，越晚澄清，返工代价越大。有些问题在项目后期才提出的修改成本，可能是早期提出时的数倍。

第三，它们逼着双方把假设显性化。 项目里最危险的不是「需求没写」，而是「双方都以为自己知道」。把这些假设写下来，哪怕暂时没有答案，也比默认一致要安全。

六、把清单变成一次有效的诊断会

知道这十个问题还不够，还需要一个把它们真正用起来的方式。以下是一个可操作的流程。

会前准备。 把清单提前发给双方，让参与者带着答案或疑问到场，而不是在会上第一次看到这些问题。同时准备一份现状材料——现有的流程、表格、系统截图，能显著提升讨论效率，也能避免「你说的和我理解的不是一回事」。

人员组成。 一次有效的诊断会，至少应包含三类角色：能对业务目标拍板的人、熟悉现有流程的人、以及未来要使用或维护系统的人。只有管理层参与的诊断会，容易漏掉实际操作层面的细节；只有执行层参与，又可能定不了方向。

先目标后细节。 会议顺序应先过「成功如何定义」「现状怎么做」这类目标性问题，再进入权限、集成、数据这些技术性问题。顺序颠倒的话，讨论很容易被某个具体功能带偏，最后发现方向还没对齐。

当场标记，而不是当场解决。 不是所有问题都能在会上定论，有些需要回去查证。对暂时没有答案的，当场记录、指定责任人与收敛时间，而不是强行给出一个不成熟的结论。强行定论往往比暂时留白更危险。

输出一份纪要。 纪要至少包含三部分：已确认的结论、待确认的问题及其责任人、以及由此得出的初步范围与风险提示。这份纪要将成为后续需求文档、技术方案与报价的共同基础。

会后跟进。 待确认问题要有明确的收敛时间表。诊断会的价值不在于开了一场会，而在于把模糊变清晰。如果会后没有跟进，那些被标记的问题会重新回到模糊状态，诊断会也就白开了。

一个务实的判断是：诊断会不需要一次解决所有问题，但必须让每个问题都有一个明确的归属——要么已确认，要么有责任人和期限。

七、落地建议

给准备启动项目的团队几条可操作的建议：

1. 用清单开一场需求诊断会。 不要急着谈技术方案，先把这十个问题过一遍，把不清楚的地方标记出来。
2. 先答能答的，记录不能答的。 有些问题一时给不出答案很正常，关键是把它们记录下来，指定责任人和时间。
3. 把结论写成一份简短的诊断纪要。 包括成功标准、数据来源、量级估计、权限结构、集成边界、合规要求、验收口径、维护责任与变更机制。
4. 区分「必须现在定」与「可以迭代」。 边界类问题尽量早定，细节类问题可以放进迭代。
5. 让使用者也参与。 需求不只来自管理层，最终使用者的意见往往更接近实际场景。

一份好的诊断纪要，本身就是项目的护栏。它不能消除所有风险，但能让风险被看见、被讨论、被提前处理。

还有一个常被忽略的细节：清单要按项目类型裁剪。一个内部小工具的诊断，可能只需重点关注成功定义、数据来源与验收口径；而一个涉及多组织、多系统、敏感数据的平台，则需要把权限结构、集成边界与合规约束作为重点。清单是起点，不是教条，重点在于「不要因为项目小就跳过关键问题」。

八、小结

需求诊断不是项目开始前的形式主义，而是把项目从「凭感觉推进」转向「凭共识推进」的关键一步。这十件事问清楚了，报价会更准、方案会更稳、验收会更顺。

对开发方来说，愿意在项目开始前花时间做需求诊断，本身就是一种专业性的体现；对客户来说，配合梳理这十个问题，是在用最低的成本降低最大的风险。如果你的团队正准备启动一个新项目，不妨先把这份清单过一遍。相关的服务方式与协作流程，可以参考 关于我们 与 交付流程。