第三章 需求收集与分析：利益相关者访谈、用户故事与场景分析、技术债务与痛点识别、竞品技术分析

做技术路线图，最怕什么？

怕闭门造车。

我见过太多团队，上来就画架构图、排时间表，结果做到一半发现需求全是错的。说白了，路线图的根基是需求。根基不稳，后面全是白费功夫。

这一章，我们就聊聊怎么把需求「挖」出来，而不是「等」出来。

3.1 利益相关者访谈：别让关键人成为盲区

利益相关者是谁？不只是你的老板和产品经理。

我个人习惯把利益相关者分成三类：

• 决策者：CTO、技术VP、业务负责人。他们关心「为什么做」和「什么时候做完」。
• 执行者：开发、测试、运维。他们关心「怎么做」和「会不会增加我的工作量」。
• 受影响者：客服、销售、最终用户。他们关心「对我有什么影响」。

访谈时，我有个小技巧：不要只问「你想要什么」。

你想想看，大多数人说不出自己真正想要什么。他们只能说出自己「不想要什么」。

所以我会问：

• 「当前最让你头疼的三个问题是什么？」
• 「如果有一个魔法棒，你最想改变哪件事？」
• 「过去半年，你因为技术问题被投诉过几次？」

3.2 用户故事与场景分析：把需求讲成故事

用户故事不是写文档，是讲故事。

标准的用户故事格式大家都知道：

作为 <角色>
我希望 <功能>
以便 <价值>

但光有这个不够。我建议加上「场景分析」。

举个例子：

用户故事	场景分析
作为运维，我希望看到服务器实时监控数据，以便快速定位故障。	正常场景：打开仪表盘，看到绿色指标，安心下班。 异常场景：CPU飙到90%，自动触发告警，需要5秒内看到根因分析。 边界场景：凌晨3点，手机端查看，网络延迟高，数据加载不能超过2秒。

为什么要加场景？因为同一个功能，在不同场景下，技术方案完全不同。

我记得有一次，产品经理说「用户需要导出报表」。我们做了个Excel导出功能，结果用户骂翻了——因为他们是移动端操作，导出Excel根本打不开。后来改成PDF预览+邮件发送，才解决问题。

3.3 技术债务与痛点识别：别假装看不见

技术债务这东西，就像信用卡账单。你不看它，它不会消失，只会利滚利。

怎么识别？我有个四步法：

1. 翻代码仓库：看TODO、FIXME、HACK注释。这些是技术债务的「自首书」。
2. 查工单系统：哪些Bug反复出现？哪些模块改一次崩一次？
3. 问一线开发：「哪个模块你最不想碰？」——如果超过两个人提到同一个模块，那就是重灾区。
4. 看部署日志：回滚频率、构建失败率、测试通过率。数据不会说谎。

痛点识别还有个技巧：看「沉默成本」。

如果一个功能，每次迭代都要花20%的时间去维护，但只服务5%的用户——这就是痛点。要么砍掉，要么重写。

3.4 竞品技术分析：别只抄功能，要抄思路

做竞品分析，最忌讳什么？

把竞品的功能列表抄一遍，然后说「我们也要有」。

我个人习惯从三个维度看竞品：

• 技术栈：他们用了什么数据库？什么框架？什么部署方式？
• 架构演进：他们3年前的架构和现在有什么不同？踩过哪些坑？
• 性能指标：他们的QPS、响应时间、可用性是多少？我们差在哪？

举个例子，当年我们做即时通讯功能，看了竞品的技术博客。发现他们从「单机Redis」迁移到「Redis Cluster」花了半年时间，中间还出了几次数据丢失事故。

这个信息太值钱了。我们直接从一开始就设计成Redis Cluster架构，省掉了后续迁移的痛苦。

3.5 本章知识体系

下面这张图，是我做需求收集与分析时的核心框架。你可以把它当成一张检查清单：

这张图的核心逻辑是：四个方向同时推进，最终汇总成一份「需求优先级矩阵」和「技术债务清单」。有了这两样东西，你画路线图时就不会拍脑袋了。

嗯，这一章的内容就到这里。需求收集是个慢功夫，但值得花时间。你想想看，如果连需求都没搞清楚，后面画的路线图再漂亮，也只是空中楼阁。

---

公众号:蓝海资料掘金营，微信deep3321