📚 课程目录第1章需求分析入门

1. 需求分析入门

说实话，我见过太多项目死在需求分析这个环节上。

有的团队上来就写代码，结果做出来的东西客户根本不认。有的团队花了好几个月写文档，最后发现写的全是废话。为什么会这样？说白了，就是没搞明白需求分析到底是个什么东西。

我个人习惯把需求分析比作「盖房子前的图纸」。你想想看，没有图纸就开工，墙砌歪了、窗户开小了，最后只能砸了重来。需求分析就是那张图纸，只不过它画的是软件长什么样、怎么用、解决什么问题。

官方定义我就不念了，说人话就是：搞清楚用户到底想要什么，然后把它翻译成开发能听懂的话。

我在项目中遇到过这样一个场景：客户说「我要一个报表功能」。听起来很简单对吧？结果一细问，他要的是实时数据、图表展示、支持导出、还要能定时发送邮件。你看，一个「报表」背后藏着这么多东西。

所以需求分析要干三件事：

核心观点：需求分析不是记录，而是翻译。把业务语言翻译成技术语言，把模糊想法翻译成明确规格。

我经常用这张图来给团队讲需求分析的位置：

从图上你能看到，需求分析是整个项目的起点。它决定了后面所有工作的方向。方向错了，跑得再快也没用。

我记得有一次接手一个烂尾项目，团队已经写了三个月代码。我一看需求文档，好家伙，连核心业务流程都没定义清楚。结果呢？推倒重来，三个月白干。这就是需求分析没做好的代价。

避坑指南：我曾经见过一个项目，需求分析只花了一周，开发花了半年。最后验收时客户说「这不是我要的」。嗯，那一周省下来的时间，后面花了两个月来补。需求分析的时间，省不得。

说了这么多，需求分析到底能带来什么价值？我总结了三句话：

价值维度	具体表现	我的经验
降低风险	提前发现需求冲突、逻辑漏洞	有一次在需求评审时发现两个模块对同一数据的定义完全相反，改需求文档只花了半天，要是等开发完再发现...不敢想
控制成本	减少返工，避免做无用功	统计过，需求阶段发现的问题，修复成本是开发阶段的1/10，是上线后的1/100
对齐预期	让客户、产品、开发三方达成共识	我习惯在需求文档最后加一页「签字页」，让各方确认。别小看这个动作，它能挡住80%的扯皮

讲几个我踩过的坑，你们以后遇到了能绕开：

「用户说什么就是什么」——用户说「我要一个搜索框」，你直接做了个简单的文本搜索。结果用户要的是模糊搜索、拼音搜索、历史记录、热门推荐...所以，别只听用户说什么，要问他「你搜什么？怎么搜？搜出来干嘛用？」
「需求文档越厚越好」——我见过一份200页的需求文档，光目录就20页。结果呢？没人看。需求文档不是越厚越好，是越精准越好。能用一张图说清楚的，别写三页字。
「需求分析是产品经理的事」——这是最大的误区。需求分析需要产品、开发、测试、运营一起参与。开发不参与需求分析，后面就会说「这个做不了」；测试不参与，就会漏掉关键场景。

我的小技巧：做需求分析时，我习惯准备三个颜色的便签纸。黄色写「用户说的」，蓝色写「用户实际需要的」，红色写「技术限制」。贴满一墙后，需求就清晰了。这个方法我用了十年，屡试不爽。

需求分析做完，要产出什么？我列个清单：

你可能会问，这么多东西都要写吗？我的建议是：看项目规模。小项目一张用户故事地图加原型图就够了。大项目，该写的文档一个都不能少。

好了，第一章就讲到这里。记住一句话：需求分析不是成本，是投资。花在需求分析上的每一分钟，都会在后面的开发中加倍还给你。