第四章 项目需求分析与理解：用户痛点挖掘、需求确认方法、需求文档撰写、常见误区
做遥感项目这么多年，我最大的体会是：技术方案写得再好，需求理解错了，一切归零。说白了，需求分析就是整个投标方案的“地基”。地基没打牢，上面盖多漂亮的楼都没用。
这一章，我把自己踩过的坑、总结的方法，掰开了揉碎了讲给你听。
一、用户痛点挖掘：别听他说什么，要看他做什么
很多新人一上来就问用户：“您需要什么？” 用户通常会说：“我要一个遥感监测系统。” 然后呢？然后就没有然后了。这其实是个大坑。
用户说的需求，往往是“解决方案”，而不是“真实痛点”。
举个例子。有一次我去对接一个林业局的项目。对方领导说：“我们需要一个森林火点自动识别系统，精度要95%以上。” 我追问了一句：“您目前最大的困扰是什么？” 他想了想说：“其实吧，我们每年防火期，值班人员盯着屏幕看十几个小时，眼睛都快瞎了。漏报率倒不高，但误报太多，每次都要派人去现场核实，人力成本太高。”
你看，他的真实痛点是“误报导致的人力浪费”，而不是“识别精度不够”。如果我只盯着95%精度去写方案，方向就偏了。
挖掘痛点的三个实用方法：
- 场景还原法：让用户描述一次完整的工作流程。比如“你早上8点上班，打开系统，第一步做什么？第二步做什么？哪一步最让你头疼？”
- 5Why追问法：用户说“我要高分辨率影像”，你追问“为什么需要高分辨率？” 他说“为了看清地物细节”，你再问“看清细节之后要解决什么问题？” 连续问5个为什么，往往能挖到根上。
- 反向验证法：“如果这个功能不做，会有什么后果？” 用户如果支支吾吾，说明这个需求可能没那么重要。
我个人习惯，在第一次和用户沟通时，会带一个录音笔。回去反复听，把用户的原话摘出来。你会发现，很多关键信息都藏在那些不经意的抱怨里。
二、需求确认方法：签字画押，不如原型验证
需求确认，最怕什么？最怕“我以为我懂了，用户以为你懂了，结果最后发现谁都没懂”。
我早期吃过一次大亏。一个水利项目，用户说要“洪水淹没范围分析功能”。我按照标准算法做了，交付时用户说：“不对，我要的是实时动态推演，不是静态分析。” 那一刻我真是欲哭无泪。
后来我总结了一套“三遍确认法”：
| 确认步骤 | 具体做法 | 我的经验 |
|---|---|---|
| 第一遍：口头复述 | 用自己的话把需求讲给用户听 | “您看我的理解对不对，您是要……对吗？” |
| 第二遍：书面确认 | 输出需求要点清单，请用户签字 | 别用邮件，用纸质版当面确认 |
| 第三遍：原型验证 | 做一个简单的界面原型或流程图 | 哪怕用PPT画个草图，也比文字强10倍 |
一个小技巧： 做原型时，故意留一个“明显的小错误”。比如把某个按钮颜色弄错。用户看到后会立刻纠正你，这说明他真的认真看了。如果用户说“没问题”，反而要警惕——他可能根本没仔细看。
三、需求文档撰写：别写成“技术说明书”
需求文档是给谁看的？给用户看，给评审专家看，给开发团队看。这三类人关注的点完全不同。
用户关心的是： 这个系统能帮我解决什么问题？
专家关心的是： 需求是否完整、合理、可落地？
开发关心的是： 输入是什么？输出是什么？处理逻辑是什么？
所以，一份好的需求文档，应该有三个层次：
- 业务需求层： 用用户的语言，描述业务场景和痛点。比如“防火期值班人员每天需要查看12小时监控画面，容易疲劳漏报”。
- 系统需求层： 用技术语言，描述系统要具备的功能。比如“系统应支持24小时不间断的卫星影像自动接收与火点识别”。
- 功能规格层： 用精确的描述，定义每个功能的输入、输出、性能指标。比如“火点识别算法在单景影像上的处理时间不超过30秒，漏报率低于1%”。
我建议你写需求文档时，先写“用户故事”。比如：
用户故事：作为防火值班员，我希望系统能在火点出现后5分钟内发出警报，
并且附带火点的经纬度和周边地形信息，这样我就能快速判断是否需要派无人机去核实。这种写法，比干巴巴的“系统应具备火点报警功能”要生动得多，也更容易发现需求漏洞。
避坑指南： 我曾经见过一份需求文档，写了80页，全是技术参数。用户根本看不懂，专家也懒得看。最后评审时，专家问了一句：“你们这个系统，到底要解决用户的什么问题？” 全场沉默。记住，需求文档不是技术说明书，它是沟通的桥梁。
四、常见误区：我踩过的那些坑
做需求分析这么多年，我总结出几个高频误区，你千万要避开。
- 误区一：把“用户想要”当成“用户需要”。 用户说“我要0.5米分辨率影像”，你直接写进需求。但也许他真正需要的是“能看清地面上的电线杆”，而1米分辨率配合AI增强算法也能做到，成本却低得多。
- 误区二：需求越细越好。 不是的。需求太细，反而限制了技术方案的灵活性。比如你写“必须使用Landsat 8数据”，万一Landsat 8出故障了呢？应该写“需要30米分辨率的多光谱影像，优先使用Landsat 8，备选Sentinel-2”。
- 误区三：忽略非功能性需求。 很多投标方案只写功能，不写性能。结果系统做出来，功能都有，但慢得要命。用户说“我要查历史影像”，你做到了，但查一次要5分钟，用户能接受吗？
- 误区四：需求确认一次就够了。 我告诉你，需求是会变的。项目周期越长，变化越大。我建议在关键节点（比如方案评审、中期检查）都做一次需求回顾，确认有没有新的变化。
我的个人经验： 有一次做国土调查项目，用户一开始说“不需要变化检测功能”。做到一半，上级领导突然要求增加。幸好我在需求文档里留了“扩展接口”的说明，否则整个方案都要重写。所以，需求文档里一定要有“可扩展性”的描述，哪怕只是提一句“系统应支持后续功能模块的灵活接入”。
五、本章知识体系图
下面这张图，是我自己梳理的需求分析核心逻辑。你可以把它当作一个检查清单，每次做项目前过一遍。
嗯，这张图你保存好。每次做项目需求分析时，拿出来对照一下，基本不会出大问题。
最后说一句：需求分析不是一次性工作，它贯穿整个项目周期。别想着一次搞定，要随时准备调整。但核心原则不变——永远站在用户的角度，去理解他真正想要什么。
公众号:蓝海资料掘金营，微信deep3321