今天我们要针对造成“需求不明确”的主因之一—— 场景不明，来详细讨论在需求讨论阶段，如何锁定“场景”，让sprint的具体内容能够紧扣需求本身，避免不必要的开发资源浪费。

在互联网产品开发领域，产品经理与开发团队间的有效协作是决定项目落地阶段的关键，这里不仅包含了讨论沟通，还包含了大家对“需求”的理解。虽然有产品文档或Sprint ticket来保障大家对同一个需求的理解，但是实际工作中依然逃不开有需求不明确的时候，这个系列就来详细讨论如何破解需求不明确，多了解些思考方式，应用在工作中，让自己或团队不再因为“需求不明确”而买单（付出时间精力）。

不管是产品和开发都要重视对“需求的场景”具体是什么，通常会用用户故事（User stories）来描述场景，可以借助“5W1H”来思考，即What（用户需要什么）、Why（为什么需要）、Who（服务于哪类用户）、Where（在产品哪个环节使用）、When（何时会选择使用）和How（如何操作以解决问题）六个维度来精确描绘用户需求的全貌。但实际操作起来还要避免忘记了目标，只按照模版来描述场景的内容。比如user stories的描述是：因为某个原因，A要在什么时候，什么环节，需要使用B功能，从而解决C问题。

从描述的模版的角度来说，没有什么问题。但是还要注意：

• 这个场景和当前的核心目标的完成度关系怎么样？比如这个场景的问题被解决了之后，对于目前产品的目标完成的帮助有多大？如果大的话，自然ok，但如果不是很大，是否可以先放一放，看看是否有跟目标关联较大的场景需要先开发。例如：“新增功能是否契合目前每月新客户10%增长的首要目标？如果有更高优先级的需求，该如何调整资源的分配？” 通过将需求与业务目标相挂钩，我们可以合理分配资源，优先满足关键性需求。
• 这个场景中描述的“解决了某个问题”，对于客户（继续或新）使用我们的产品起到了多大作用。只有客户留存下来了或带来了更多新客户，产品才有更多的盈利可能性。需求的场景可能是使用者的一个小困扰，但是对于他们的续约或继续使用的影响有多大，需要认真调研并讨论。如果解决了这个问题可以让用户对我们的产品提升更多的信心，从而继续帮我们拉新或自己留存下来，自然是极好的，如果不能，只是一个锦上添花的功能（不是说锦上添花不能有，只是要看优先级），那就要看下是否有其他更重要的场景需要先解决问题了。
• 这个场景中描述的某个原因是否是真正的原因或核心动机（学习柯南的动机法，对动机要进行验证），如果动机分析的不对或由于信息的调研传递过程中，误解了动机，那在解决方案的制定时也会走偏方向，结果不尽如人意。多问些为什么，可以更深入的挖掘场景中的真正动机。比如，“用户下载内容的真正目的是什么？下载格式的选择是否因用户的目的不同而有所差异？”通过不断地提问和深挖，可以帮助团队发现需求背后用户的真实动机，避免在需求不明晰（或表象清晰）的情况下盲目开发，从而保护宝贵的开发资源，提升团队的整体效率。
• 这个场景中解决问题的方法只有用户故事中的一种方法吗？是否有替代的更简单、更快速的方案？有时候我们在听用户故事的描述时，就像看电视剧一样容易被已有的剧情带着往下走，只是像看故事一般的看着用户故事，但如果用户故事里的结局（解决方案）不是团队在有限资源下可执行的方案，那剧的结局（解决方案）也很难及时被拍摄出来。所以，时不时地从用户故事的描述中，跳脱出来想想对于用户的这个场景，更简单、快速（更具性价比）的方案是不是还有？要知道，如果有人能提出更简单的方案，对于研发的资源和大家的精力（不管是产品、开发、测试）都是一件大好事。生活和工作能平衡的关键所在，就靠“好钢用在刀刃上了”，节省精力，做最重要、最具影响力的事情才是提升效率的关键。这一点，建议开发人员积极参与到需求讨论中，提供专业的技术意见和建议。这不仅包括对需求解决方案的可行性评估，还涉及到可能的技术限制和挑战。通过团队共同探讨需求的实现方式、所需的资源，可以挖掘更具性价比的场景解决方案。
• 这个场景中出现的频率有多高？需求所对应的使用场景进行频率分析也是一个很重要的维度。针对低频场景的需求，研发团队需要审慎对待，通过提问来促使自己的反思：“此功能是否确实是用户频繁使用的必需功能？若仅为偶尔发生的特殊情况，是否有其他临时解决措施或现有的低成本工具可以替代？” 例如，在处理少数的退款情况时，可以提议先采用人工加内部工具的组合方式，待该场景频次提升后再做系统开发升级。通过量化场景发生的频率和影响范围，可以帮助我们从迷雾中走出来，看清团队真正应该要做的是什么。

总的来说，锁住“场景”，既要围绕场景本身来详细分析需求，还要跳出场景，看场景与业务目标，研发成本，用户动机等的关联如何，从而真正锁住紧扣市场需求的“场景”，进而付出的研发精力才可最大限度地避免成为“试错成本”。

还等什么，收藏起来，后面在工作中练习下吧！