系统需求分析

我看过很多项目翻车的案例。
功能做了一大堆，上线之后客户不买账。需求文档写了几十页，开发做完才发现方向就是错的。
后来我慢慢发现，绝大多数项目翻车，根本不是开发的锅，也不是设计的锅。
是需求分析这一步，就没做对。
尤其是B端系统，动不动就是几十个角色、上百条流程，稍微一个环节漏了，后面全得返工。
我自己踩过坑，也看别人踩过坑，本篇文章将介绍如何进行系统性的需求分析。
notion image

一、先搞清楚：需求到底是什么？

很多刚入行的产品经理，一听到"需求"，第一反应就是客户说要什么功能。
客户说要个审批流程，那就做审批流程。客户说要个报表，那就加报表。
但其实，这根本不是需求分析，这是需求记录。
真正的需求，其实是一个公式：
需求 = 预期 - 现状
就是用户心里想的那个样子，跟现实之间的差距。
这个差距有时候是用户自己能感知到的——比如他觉得现在的流程太慢了，效率太低了，这叫问题场景，你去聊一聊就能聊出来。
但有时候呢，用户自己都不觉得有问题。现状挺好的，为啥要变？
这时候你就得帮他发现"机会"——就是告诉他，其实还可以更好，你看别人家都已经这样做了。这叫机会场景。
举个例子，AI大模型技术出来之后，很多企业原来觉得自己的客户筛选流程挺好的。但你一分析，其实用AI做智能线索筛选，效率能提升好几倍。
这就是机会。用户没意识到，你帮他找到了。
所以需求分析的第一步，不是问用户要什么，而是搞清楚用户的预期和现状之间到底差了什么。

二、需求分析的两条主线

系统需求分析这件事，说复杂也复杂，说简单也简单。
你只要抓住两条主线就行：
第一条：价值需求主线——这个系统到底为谁解决什么问题？
第二条：详细需求主线——具体要做哪些功能、管哪些数据、达到什么质量？
先从宏观到微观，先从"为什么做"到"怎么做"。
很多项目出问题，就是因为价值需求这一层没想清楚，直接就冲到详细需求去了。结果做了一堆功能，客户说这不是我要的。
我们一条一条来说。

三、价值需求主线：搞清楚三件事

价值需求这条线，核心就是搞清楚三件事：

1. 目标/愿景分析

就是搞明白，这个系统到底要解决什么问题，或者抓住什么机会。
怎么搞？分情况。
如果项目是因为外部原因触发的——比如老板出去考察了一圈回来说"我们也要搞数字化"，那你就得用分享收获的策略，让他还原看到了什么，从他的描述里提炼出真正的目标。
如果是因为竞争对手搞了个什么东西——那你就得做竞品分析，帮客户搞清楚对手到底做了什么，我们要不要跟，怎么跟。
如果是内部自己提出来的——那相对简单，发起人通常已经想过一轮了，你通过访谈就能识别出来。
但不管哪种情况，最终你都要做一件事：把问题或机会定义清楚。
这里有三个要求：
  • 说业务话，不要说系统话。不是"需要一个审批模块"，而是"采购流程缺乏风险管控，导致超预算采购频发"。
  • 要客观，不加主观判断，真实还原。
  • 跟高层视角匹配，要聊经营层面的事，不要聊按钮放哪里。
最后还要提炼一个"一句话目标"，格式是"措施+效果"。
比如"通过智能线索筛选系统，将优质客户识别效率提升3倍"。
这种就很好。
而"全面提升沟通效率"这种就太空了，验证都没法验证。

2. 干系人识别

干系人就是跟这个系统有利益关系的人。
别小看这一步。我见过太多项目，做到一半突然冒出来一个部门说"你们这个系统影响到我们了"，然后整个需求推翻重来。
所以一开始就要把干系人找全。
怎么找？四种方法：
  • 组织结构分析法：看组织架构图，找相关部门和角色
  • 业务流程走查法：沿着核心流程走一遍，看涉及谁
  • 文档检查法：从立项报告、合同里面扒
  • 利益相关矩阵法：从权力和利益两个维度全面梳理
而且这不是一次性的工作，随着分析深入，你可能会发现新的干系人，要持续更新。

3. 干系人分析

找到人之后，你得搞清楚每个人关心什么、担心什么、态度如何。
管理层关心的是数据决策支持，操作人员关心的是好不好用，运维人员关心的是稳不稳定。
不同的人，关注点完全不一样。
而且你要特别注意识别需求冲突。
比如我之前遇到过一个典型的：销售部门希望审批流程越简单越好，恨不得一键通过，因为他们要快。但风控部门希望审批越严格越好，因为他们要控风险。
这俩需求就是矛盾的。如果你不在需求分析阶段就把这个冲突暴露出来并协调好，后面一定会打架。

四、详细需求主线：四大块缺一不可

价值需求搞清楚之后，就进入详细需求了。
详细需求分四大块：业务子系统划分、功能需求、数据需求、非功能需求。

1. 业务子系统划分

就是先把一个大系统，拆成几个相对独立的子系统。
拆的方法有好几种：
  • 按业务职能拆：比如电商系统拆成"商品管理""订单管理""物流管理""会员管理"
  • 按产品/服务拆：比如银行系统按"一卡通""信用卡""理财"来拆，而不是按"查询""转账"来拆
  • 按关键特性拆：从用户价值角度来拆，比如安防系统按"防盗""灾害预警""家庭看管"来拆
这里有个很重要的原则：要从用户视角拆，不要从技术视角拆。
你按"传感器模块""录像模块""报警模块"来拆，那是技术架构，不是业务需求。

2. 功能需求

功能需求是详细需求里面最大最核心的一块。
它有三个来源：业务支持、管理支持、维护支持。

2.1 业务支持（重头戏）

业务支持的核心方法就四个字：流程建模。
说白了就是：先找流程 → 再分析优化流程 → 再从流程里提取场景 → 再从场景导出功能。
第一步：找流程。
找流程有个"四步法"：
先找外部客户引发的主流程、变体流程、支撑流程。比如酒店主流程是办理入住，变体流程是换房续房，支撑流程是行李寄存。
再找内部引发的流程，比如交接班。
然后找管理流程，从事前预防、事中控制、事后分析三个维度去找。
最后排优先级，核心主营业务 + 高频的排前面。
第二步：分析优化流程。
这一步有个很好用的工具，叫ESIA四策略。
  • E（清除）：把不增值的环节干掉
  • S（简化）：把复杂的操作简化
  • I（整合）：把分散的环节合并
  • A（自动化）：用系统替代人工
ESIA 的核心思路就是 —— 先问"能不能不做"（E），再问"能不能更简单"（S），然后看"能不能合并"（I），最后看"能不能让系统自己干"（A）。按这个顺序过一遍，流程基本都能精简不少
示例：电商退换货流程优化
优化前（6步）
优化后（3步）
说明
用户提交申请
用户提交申请
ㅤ
客服人工审核
ㅤ
简化：不需要每单都人工看，可以设定规则：金额低于 50 元、信用良好的用户 → 自动通过，只有高风险订单才转人工
客服通知仓库
ㅤ
清除：这一步其实是多余的传话环节，可以直接让系统在审核通过后自动通知仓库
用户寄回商品
用户寄回商品（自动生成运单）
自动化：退货申请提交后，系统自动生成退货运单号、推送物流信息给用户，不再需要客服手动操作
仓库人工验货
仓库验货通过 → 自动退款
ㅤ
财务手动退款
ㅤ
合并："仓库验货"和"财务退款" 可以整合：验货合格后系统自动触发退款流程，不需要财务再单独操作
第三步：识别业务场景。
这里有个很经典的故事：教外婆用相机。
你跟她说"这是开关，这是快门，这是光圈"，她一脸懵。但你跟她说"你按这个就能拍照，按那个就能看照片"，她一下就懂了。
这就是场景思维和功能思维的区别。
需求分析要关注的是用户的使用场景和目的，不是罗列系统功能清单。
而且场景的粒度也很重要——不要搞成"新增""删除""修改"这种CRUD式的命名。图书管理系统里，"新增图书"不是一个好场景，"图书入库"才是，因为它有业务含义。
第四步：分析场景，导出功能。
这一步的核心框架是：场景 → 挑战 → 方案。
就是你把用户场景还原出来，看每一步会遇到什么困难，然后这些困难自然就导出了系统需要提供的功能。
比如旅游行程规划，用户在"找攻略"这一步，遇到的困难是"不知道哪些值得去"，那解决方案就是"提供智能推荐 / 分类查看 / 收藏比较"。
你看，功能是从场景里自然长出来的，而不是拍脑袋想出来的。

2.2 管理支持

管理支持的核心逻辑就一句话：事前规避风险，事中控制风险，事后优化决策。
具体包括审批管控流程、预警监控、权限与数据隔离，还有各种管理报表。
报表这块我多说一句，很多产品经理做报表就是去问领导"您想看什么"，然后领导说啥就做啥。
更好的做法是从管理场景出发——领导在什么场景下需要做什么决策，倒推需要什么数据支撑。
这样做出来的报表才是真的有用的。

2.3 维护支持

这块是最容易被忽视的，但特别重要。
基础数据管理、系统配置、用户权限、监控运维、数据迁移……
不做这些，系统上线之后就是"能用但难管"。运维同事会恨死你的。。。

3. 数据需求

数据需求回答的是：系统需要管哪些数据？数据之间什么关系？
核心就是领域建模——找出业务里的核心实体（客户、订单、商品……），搞清楚它们的属性和关系。
再深入分析数据的生命周期、校验规则、增长量、权限、迁移需求。
很多时候数据需求在功能需求里被"顺带"提了一嘴，但缺乏系统性梳理。独立做一遍数据需求分析，能避免后期频繁改数据结构，那个痛苦，谁改谁知道。

4. 非功能需求

非功能需求就是系统"好不好用"的标准——性能、可用性、安全性、易用性、可扩展性、可维护性、兼容性。
这块最容易踩的坑就是写得太模糊。
"系统响应要快"——这不叫需求。
"页面加载时间不超过3秒，系统支持1000人同时在线"——这才叫需求。
非功能需求必须具体、可测量、可验证。
而且不同质量属性之间是可能冲突的。安全性搞得太严，易用性就会下降。你得根据业务优先级做权衡。
我之前做过一个金融项目，安全性要求极高，导致操作流程特别繁琐，一线业务员天天抱怨。后来不得不在保证安全合规的前提下，重新简化了几个高频操作的流程。
非功能需求是项目成败的"隐形杀手"——功能做对了但性能不达标、安全有漏洞，一样翻车。

五、写在最后

讲真，系统需求分析这件事，没有捷径。
但它确实有方法。
总结一下，核心就两条主线：
价值需求主线：搞清楚为谁解决什么问题——目标分析、干系人识别、干系人分析。
详细需求主线：搞清楚具体怎么做——子系统划分、功能需求（业务+管理+维护）、数据需求、非功能需求。
先宏观再微观，先价值再细节。
这套方法特别适用于B端系统从0到1的阶段，也适合你刚入职一家新公司，需要快速了解和梳理一个复杂系统的时候。
我自己每次接手新项目，都会先按这个框架走一遍。虽然不一定每个环节都做得很深，但至少保证不会遗漏关键的东西。
希望这套方法，也能对你有用~