一、需求分析基础：需求分析的流程、需求获取的方法、需求文档的编写规范

做数据看板这么多年，我最大的感触就是——需求分析做不好，后面全是白忙活。你想想看，一个看板做出来，业务方说「这不是我要的」，开发说「你当初没讲清楚」，这种场景我见过太多次了。

所以今天咱们就聊聊需求分析的基础。说白了，就是搞清楚三件事：怎么问、怎么记、怎么理。

1.1 需求分析的流程：别急着动手画图

我刚开始带项目的时候，也犯过这个错。客户一说「我要个大屏看板」，我立马打开 Figma 开始画。结果呢？画了三版，全被推翻。后来我总结了一套流程，分享给你：

1. 需求收集——先听，别急着说
2. 需求整理——把听到的东西分类、去重
3. 需求确认——跟业务方对一遍，确保没理解错
4. 需求优先级排序——哪些必须做，哪些可以缓一缓
5. 需求文档输出——把共识写下来，签字确认

嗯，这里要注意：第3步和第5步最容易跳过去。我见过太多团队，需求收集完就直接开干，结果做到一半业务方说「不对，我要的不是这个」。你说冤不冤？

1.2 需求获取的方法：别只靠「聊」

很多人觉得需求获取就是开会聊天。其实不然。我常用的方法有这几种：

方法	适用场景	我的经验
用户访谈	了解业务痛点、使用习惯	一对一聊，比开大会有效得多
问卷调研	收集大量用户的共性需求	问题别超过10个，否则没人填
竞品分析	看别人怎么做，找差距	别照抄，要思考「为什么这么设计」
原型演示	让用户「看到」需求	用 Axure 或 Figma 做个低保真，比说一万句都强
数据分析	从现有数据中发现需求	用户行为不会骗人

我个人习惯是先做数据分析，再做用户访谈。为什么？因为数据能告诉你「发生了什么」，访谈能告诉你「为什么会这样」。两者结合，需求才完整。

1.3 需求文档的编写规范：写清楚，别留坑

需求文档这东西，写得太细没人看，写得太粗又容易扯皮。我踩过这个坑，所以现在有一套自己的规范：

1.3.1 文档结构

一份标准的需求文档，至少包含这几部分：

• 项目背景——为什么要做这个看板？
• 用户角色——谁在用？老板看？还是运营看？
• 功能清单——每个模块做什么？
• 数据指标——每个指标怎么算？口径是什么？
• 交互说明——点击、悬浮、跳转，分别怎么处理？
• 优先级标注——P0、P1、P2，哪些是必须的？

1.3.2 编写原则

我总结了四个字：清、准、细、稳。

• 清——语言清晰，别用「大概」「可能」「差不多」
• 准——数据口径要准，比如「销售额」是含税还是不含税？
• 细——细节要到位，比如「图表颜色用蓝色」比「用好看的颜色」强一百倍
• 稳——逻辑要稳，别出现前后矛盾

1.3.3 一个简单的模板示例

给你看看我常用的需求条目写法：

模块名称：销售总览看板
需求编号：REQ-001
优先级：P0

功能描述：
  展示当日、本周、本月的销售额、订单量、客单价。

数据指标：
  - 销售额：当日已支付订单的总金额（含税）
  - 订单量：当日已支付订单的数量
  - 客单价：销售额 / 订单量

交互说明：
  - 默认展示当日数据
  - 点击「本周」标签，切换为本周累计数据
  - 鼠标悬浮在数值上，显示同比/环比变化

备注：
  数据每5分钟刷新一次

你看，这样写出来，开发一看就懂，测试也知道怎么测。业务方签字确认的时候，也不会说「我没看清楚」。

小结一下

需求分析这件事，说白了就是把业务方脑子里的「想法」，变成开发能执行的「方案」。流程要跑通，方法要用对，文档要写清。这三样做到了，你的看板项目就成功了一半。

下一章咱们聊聊数据指标体系的设计——这可是看板的灵魂，别错过。