深入了解问题的根源
- 了解项目背景，包括stakeholder都有谁、他们的关系、项目目的、要解决什么问题、相关方都有谁、相关方的类型及参与程度参与方式、现状是怎么样的、期望达到的结果是怎么样的。
- 时常重新审视问题/项目初心。在讨论前，时常回顾项目初心、要解决什么问题，有助于帮助我们决策，避免跑偏/陷入无用的细节。
- 多问为什么、多用 谁、什么时候、什么地方、做什么事情、出于什么样的目的等方式巧妙地往下问。有的时候stakeholder会倾向于直接谈论解决方案，我们可以询问与解决方案相关的问题来发现背后存在的问题。（需求发现阶段的重点，是捕捉需求，而不是直接做解决方案）
- 制作《需求清单》，列出每个功能的可能业务理由，可以帮忙理解业务价值、评估ROI 和回答stakeholder的问题。
学会倾听
- 停止思考。特指一些技术背景的人，不要直接进行可行性分析，要理解真正的需求是什么。（偶尔停一停，不是always）
- 不要害怕提”愚蠢“的问题，最愚蠢的问题是没有说出口的问题。
- 提出follow-up的问题，往下深挖问题能挖掘出更多价值。
- 不要录音。录音说明你跟不上整体会议节奏，说明其他人可能跟你一样也跟不上，那么会议可能无法形成有效的讨论。
提前做好准备
- 使用所有的技巧来发现需求，不要囿于常用的几个。
- 准备mockup（低保真原型、业务流程图、用户故事等等），方便讨论
- 没有stakeholder也先往前推，提前做好准备，届时可以更好地推进和提问。技巧如下 https://www.bridging-the-gap.com/3-elicitation-techniques-you-can-do-without-stakeholder-access/
- 以终为始，有个大的picture。即便是敏捷开发，也最好有后面几个版本的大致规划，这样可以有效减少返工、减少风险，也可以在引导需求的时候 更有方向。
- 提前准备，准备好问题清单，准备好可能存在的解决方案及方案可能存在的点（问题、风险、卡点）。
需求产生的时机很重要
- 需求贯穿整个项目，BA能做的，是尽量在项目早期发现大部分的需求。项目后期做好变更管理。
- 随时准备倾听需求，会议上、午餐时、电梯时
了解stakeholder
- stakeholder都有谁、他们谁发起/结束项目、谁做决策、谁付钱、在项目中有什么作用，和他们应当保持怎样的沟通频次和沟通方式、沟通内容
- 多反馈
有效开会
- 提前准备，明确会议目的、参会人员，包括准备mockup、提前发布agenda、站在对方视角的预设问题、观察自己交付物可能存在的预设问题
- 开会前，明确会议前要完成的milestone，这个会议 是用来同步发现的问题的、还是交付结果的。如果自己show的内容错了，严重影响stakeholder对自己的评价。（如果不明确，可以私下问一下老板）
- 注意会议开场，开场前阐明背景、现状、与参会者的关联（参会者要做什么）
- 做笔记
- 会议尽量小，不要有旁边者存在（如果有的话 尽量多cue一下他们 以防他们有信息 但是shy to show）
- 虚拟会议可以使用一些技术，来促进讨论，比如虚拟白板、虚拟头脑风暴等等）
注意Scope
- 如果话题过大，切分成小的session再针对性地讨论。
- 每个人对于scope的定义不一样，业务发起人可能认为解决特定问题是scope，技术可能认为特定的解决方案是scope，PM可能认为时间、预算是scope。BA应当有自己的scope划分。我们在和业务 尤其是刚开始合作的业务沟通时，一定要提前说好scope。
（我理解BA的scope，首先是判断这个需求到底应不应该进自己的scope，不同公司有不同标准，比如我前司接需求的标准就是 是否能上BI产品、需求是否有价值、需求是否合理、有无替代解决方案； 其次才是这个需求的范围划定，我们要讨论的是XX场景下的XX问题） - 不要overpromise。不要过度承诺，有问题/concern当场就说！！！千万不要大会上承诺/沉默，回来小会上再说做不了！！
- 不要暗示性承诺，讨论/提问，都可能被视为同意提供解决方案。
- 区分发现需求和排期。尽量先列所有需求，最后再排期。（有的时候业务牵着走，容易发生这种问题）
- 对于scope外的需求，一些比较好的想法可以先记录下来，这些想法超越了当前的项目范围，但可以先记录下来，这样有助于保持创意性。
// 原文： https://www.bridging-the-gap.com/53-tips-discover-all-the-requirements
原文+个人整合
