如何收集用户需求

目录

背景和价值

你所引用的观点——“我们常常只和客户打交道，却忽略真实用户需求”——是《需求分析》《软件需求》《用户故事地图》等多本经典书籍都反复强调的核心问题，也是企业内部 IT 系统最常见的失败根源之一。

你提到的 OPPO 场景（IT 部门只听业务部门，但业务部门不直接代表用户）非常典型，属于“中间客户代理问题（Proxy Customer Problem）”。

下面我将对该问题进行系统性拆解，并给出成体系的解决方法（企业可执行）。

一、为什么“只听业务部门”会导致需求失真？

1. 业务部门 ≠ 最终用户

业务部门往往是 “客户”，但不是真正的“使用者（user）”。
他们的需求往往是“他们认为用户需要的”，但并不是实际行为。

IT 团队得到的是：

  • 转述后的需求
  • 过滤后的需求
  • processed information
  • 甚至是“业务部门想要的”，不是“用户真正痛点”

这会造成典型问题：
构建出来的功能满足了业务部门，但用户根本不用或用不明白。

2. 客户通常无法准确代表用户体验（尤其内部业务部门）

原因包括：

  • 业务部门经常关注 KPI、流程、成本，而不是用户可用性
  • 他们不了解系统使用细节（高频错误、瓶颈、实际环境）
  • 对用户行为缺乏一线观察
  • 会把“流程需要”误当成“用户需要”

这种“需求代理链”越长，失真越严重。

3. 客户说的往往是解决方案，而不是需求

比如：

业务部门：
“我需要一个字段，让员工自己填采购原因。”

但真实用户痛点：
“我不知道选哪个原因，也不知道选择依据。”

用户痛点是“信息缺失”，而客户提的是“加一个字段”。

二、中大型企业为何普遍忽略“用户需求采集”？

通常有三类原因：

1. 组织结构导致：

IT = 服务部门
业务部门 = 需求来源方
用户 = 前线员工（往往无权出声）

IT 很难越级直接访谈用户，往往会被业务认为“绕过他们”。

2. 项目周期短，赶进度

直接让业务部门写需求，然后 IT 实现，看起来效率更高。

但长期来看：

  • 系统难用
  • 重复建设
  • 大量返工
  • 培训和维护成本极高

3. 企业文化问题

一些公司习惯“流程驱动”，而不是“用户体验驱动”
导致用户（例如客服、销售一线）没有参与设计的机会。

三、如何解决？（企业 IT 项目可用的方法）

以下方法在阿里、腾讯、OPPO、华为等企业均已实践过。

方法 1：IT 团队必须参与“用户需求收集”（Elicitation）

不是业务部门写 PRD，而是：

  • IT 参与用户访谈
  • IT 参与用户观察（Shadowing）
  • IT 分析用户使用链路
  • IT 自己做任务分析（Task Analysis）

《软件需求》特别强调：
凡是让项目组无法亲自观察用户的公司，需求质量必然偏低。

方法 2：建立“双来源需求”机制（业务 + 用户）

例如：

需求类型 来源 职责
业务需求 BRD 业务部门 说明业务规则、流程、目标
用户需求 URD 用户访谈、用户观察、日志分析 说明用户行为、痛点、场景

最终合并为 PRD/SRS。

这样能有效避免“只有业务视角”。

方法 3：每个项目必须做“用户接触（User Touchpoints）”

例如强制要求：

  • 至少 3 个用户访谈
  • 至少 1 次用户工作流观察
  • 至少 1 次日志分析（真实行为）
  • 至少 1 次可用性测试（低保真/高保真）

这些工作不需要很贵，也不需要 UX 团队。
产品经理或需求分析师都能做。

方法 4：引入“用户代理人（User Proxy）”角色

如果无法直接接触用户，可以建立以下代理角色：

  • 一线主管
  • 高频系统使用者
  • 客服/销售/运营团队代表

他们比业务部门更贴近用户。

方法 5：引入“需求验证环节”（用户必须确认）

流程示例（可直接用于团队）：

  1. 业务提供业务需求
  2. 产品/需求分析师补充用户需求
  3. 用户验证（真实使用者 或 代理用户）
  4. 技术评审
  5. 再由业务确认

这能让用户视角不被业务部门盖住。

基于《软件需求》（Software Requirements, Karl Wiegers）中的原则，以及你所描述的组织场景（如 OPPO：业务部门是“客户”，真实用户却未直接出现），以下提供一个专业、可落地、且符合大企业 IT 部门现实约束的答案。

IT 团队应该以什么频率收集用户需求（Elicitation）？

先给结论：
频率不应该由“业务提需求的频率”决定，而应该由“用户行为变化速度 + 系统使用重要性 + 需求风险”共同决定。

结合大中型企业实际情况，一个成熟 IT 团队的用户需求收集频率一般如下：

标准参考频率（企业级 IT 场景）

1. 月度（1 次/月）——例行“轻量 Elicitation”

适用于 IT 团队长期维护的系统（如销售系统、运营后台、供应链系统）。

典型动作：

  • 1 次用户访谈（远程或面对面）
  • 采集核心用户行为数据（日志、埋点）
  • 进行典型用户工作流复查（Task-flow Review）
  • 复核业务部门给的需求是否与用户痛点一致

目的：

  • 发现业务部门无法表达、但用户真实存在的痛点
  • 强制保证用户视角不会被忽略
  • 避免需求完全被“内部客户（业务部门）”主导

适用于：大多数运营类、支撑类系统。

2. 季度（1 次/季度）——系统性 Elicitation Cycle

适用于业务变化周期较长的系统（如供应链、财务、人力）。

典型动作：

  • 现场观察（Shadowing）半天以上
  • 用户旅程（User Journey）复审
  • 工作任务分析（Task Analysis）
  • 关键角色的深度访谈（深度访谈 1 小时+）

目的：

  • 全面刷新对用户的理解
  • 识别长期未暴露的结构性问题
  • 为年度 Roadmap 提供真实用户输入

适用于：
流程稳定但系统复杂的场景。

3. 版本前（每次迭代前）——需求风险驱动

所有重大功能上线前，必须执行一次“针对性用户需求验证（Validation Elicitation）”。

动作包括：

  • 小范围用户对原型（Prototype）的可用性测试
  • 使用场景验证（Scenario Validation）
  • 定义验收标准是否符合用户任务（不是业务部门的 KPI）
这个验证确实发生在需求设计阶段，但有几个关键点需要澄清：

阶段定位

这是在开发团队开始编码或构建功能之前的阶段，也就是在 PRD 或设计文档基本完成之后，但在开发之前。

主要目的是确认“我们准备做的功能，用户真的需要，且使用起来是合理的”，避免浪费开发资源。

验证对象

原型（Prototype）：通常是低保真或高保真的原型，不是最终产品。

使用场景（Scenario）：模拟用户在实际业务流程中使用功能的情况。

验收标准：确保定义的成功标准真正衡量用户能否完成任务，而不是仅仅满足业务指标或 KPI。

与需求阶段的关系

属于需求验证（Validation），而不是需求收集（Elicitation）或分析（Analysis）。

典型流程是：需求收集 → 需求分析 → 原型设计 → 用户需求验证（Validation） → 开发

目的：
确保“需求不是错的”。

适用于：
任何重要版本、涉及用户操作流程变化的功能。

4. 事件驱动（Triggered Elicitation）——用户出现异常行为时

触发条件：

  • 投诉激增
  • 用户行为指标下降
  • 业务部门提的需求明显与用户数据不一致
  • 出现反复返工的需求

动作：

  • 快速用户访谈
  • 收集真实使用中的阻碍点

目的：
及时修正方向，降低返工。

为什么不能以“业务提需求”来作为收集频率？

《软件需求》观点：
业务部门是“客户”，不是“用户”。
如果 IT 不直接接触用户，会出现 3 个严重问题：

  1. 需求偏差
    业务要求 ≠ 用户想要
    PRD 可能完全是业务视角，不代表用户体验。

  2. 隐性需求丢失
    真实用户的隐性痛点无法体现，例如流程断点、效率瓶颈。

  3. 返工率高
    IT 做出的东西满足业务，但用户用不动，最后全部推倒重来。

给你一个“企业级 IT 部门用户需求收集制度模板”

你可以直接用于你的团队：

A. 固定节奏

  • 每月：轻量用户访谈 + 用户数据回顾
  • 每季度：现场观察、深度访谈、Journey review

B. 版本前强制验证

  • 每个版本必须做“用户任务验证（Task Validation）”

C. 事件驱动

  • 指标异常必须立即用户访谈

D. 需求必须包含“用户输入来源”

所有需求文档必须写明：

  • 用户访谈记录
  • 用户痛点证据
  • 用户任务链（Task Chain）
  • 用户场景及限制条件

没有用户证据的需求 = 不合格。

参考资料

posted @ 2025-12-08 09:58  向着朝阳  阅读(9)  评论(0)    收藏  举报