你跟装修师傅说'做个大厨房'，他按 20 平做出来，你却摇头——你说的'大'还包含'动线顺、能两人同时下厨'。需求获取就是挖出这种'说出口'和'真正想要'之间的差距。

为什么「做对了」比「做完了」更重要

从启动到验证，需求获取走完一圈才算闭环，少一步都可能在后半段翻车。

你问用户「你想要什么功能」，他说「要好用的」——然后就没了。这是需求获取最常见的开场，背后藏着三个深层难题。

前面走过需求获取的典型流程，但流程再漂亮，没有合适的沟通技术也落不了地。在所有获取技术中，访谈法是最经典、最直接的一种。

把一次结构化访谈拆成五个阶段，每阶段都有明确动作。

两者都叫'访谈'，但执行逻辑天差地别——选错方式会浪费时间、漏掉关键需求。

大规模收集需求的定量手段与设计要点

从问卷设计的两类陷阱出发，沿因果链看它们如何一步步把受访者推向认知偏差，最终造成数据失真。

从存量文档中挖掘隐含需求的方法

融入用户环境获取真实行为数据

观察法看到的是用户「做了什么」，但用户没说出口的、连自己都没想清楚的，往往才是真正的需求。怎么办？

从纸笔涂鸦到接近上线状态，原型保真度逐级提升，每一级解决不同问题。

原型能验证用户怎么用，但不能替你发现用户没意识到的痛——这时需要一群人坐下来，把脑子里的东西倒出来。怎么倒才不浪费？

上次访谈是一对一聊，但需求往往跨多个部门。让业务、用户、开发坐在同一张桌子前，几个小时就把需求敲定——这就是 JAD。

两种方法的参与度、时长、产出差异

前面我们学了访谈、JAD 这些把需求挖出来的方法。但需求拿回来之后，怎么写才能让团队一眼看懂、记得住？这就需要一种贴近用户、聚焦价值的描述方式——用户故事。

好的用户故事要满足六条 INVEST 准则，逐条对照才能挑出问题。

横向时间轴+纵向backlog构建全景视图

Epic→Feature→Story→Task四级分解，INVEST把关后汇入Sprint Backlog

同一份技术清单，在敏捷小队和传统大项目里权重完全相反。

面对一位时间紧张、无法参加长会议的业务专家，以下哪种需求获取策略最合适？

• ✓没有万能方法，按场景组合多种技术
• ✓选型取决于风险、不确定性与利益相关方参与度
• ✓需求获取是迭代澄清过程，不是一次性完成
• ✓用户持续在场比任何工具都关键
• ✓结构化产出支撑团队协作与追踪

先凭直觉想三分钟，再展开参考答案——这些问题没有标准答案。