日常需求分析

开发团队收到一条变更优化型需求时，最好按以下步骤处理：

还原需求的核心要素是 why、who、how，也就是谁的需求、解决什么问题、解决问题的成本是否合适。

澄清问题的思考过程，也就是使用过去时回答：这个需求要解决谁的问题。

明确是谁的需求时，不应该把关注点放在需求提出者身上，还应该思考三个问题：

需求提出者和需求使用者是否一致？如果不一致，应该尽可能收集需求使用者的真实反馈。
这个需求是否存在潜在影响者？他们有什么不同的想法？通常，需求涉及业务操作流程时，业务管理者会是影响者；设计业务数据时，数据上下游采集者和下游使用者可能是潜在影响者；涉及业务规则时，风控、审计等相关部门可能是潜在影响者。
这个需求是否能代表主流用户的声音？很多需求源于专家型用户，因为这类用户通常热衷于提出反馈，但提出的需求经常偏向复杂解决方案，所以需要找相对沉默的主流用户进一步验证。

最后要确定解决方案。提出解决方案时，应该站在用户立场说明这种方案的优点。毕竟产品经理是问题解决者，而不是简单的需求传递者。

补充需求的时候，可开展的角度有三个：

要首先将 Who + Why 整合成的业务场景放入流程里，然后识别出流程上游环节、下游环节以及流程的管理者、协作者。针对识别出来的影响者，逐一站在其视角，识别出其关注的问题以及问题衍生的需求。

因为对于问题的探讨，客户是理性的；而对于方案的探讨，客户是感性的。无论怎么做，这些工作都要投入更多的精力和时间，因此在实践中要有取舍。通常来说，这一环节要只挖掘问题，不挖掘方案。

评估需求时，最好针对已投产的系统、已发布的产品，构建各自的待处理需求合集，也就是 Backlog。

然后从 Backlog 里，根据优先级和成本评估，筛选出每个开发迭代要处理的需求集合。

最终要输出对应的需求分析文档。文档里有这么几个部分：

用户需求：说明需求是谁提出的（提出人，必填），他属于哪个部门（客户信息，建议填），原话是什么（原始描述，必填）；如果有需要，则还可以对其进行编号（编号）。
问题澄清：说明这个用户需求背后的问题级需求是什么（要解决的问题，必填），现在如何应对该问题（现状，选填），问题描述中是否有需要澄清的定义（概念澄清，选填），以及是否还有相关的其他需求（相似问题场景挖掘，选填）。
业务环境描述：说明该需求未实现会对谁产生直接影响（不做谁生气，建议填），产生这种影响的频率如何（多久生气一次，建议填），存在哪些对非功能需求产生影响的因素（其他非功能需求，选填）。
业务场景描述：当需求分析人员或开发人员不理解该问题发生在什么样的业务场景中时，可以选填本部分。主要包括该需求发生在哪个业务场景中（场景名称），这个场景是怎么样的（建议采用子任务、任务变体的形式整理）。
业务术语说明：如果需求分析人员或开发人员对该需求中相关的业务术语有理解歧义，那么建议选填本部分。
解决方案概述：必填，针对该问题可以有哪几种解决方案，各有什么优缺点，推荐哪种？为什么？