|
前置文章：  通过对业务流程的梳理，以及业务问题的整理后，我们需要对获得的需求在业务流程以及业务问题的基础上进行梳理与分析，整理需求，消除需求之间的矛盾，定义产品边界，制定最终大家认可的、可执行的需求方案。 1. 产品需求梳理与分析 我们主要将需求分为业务需求、用户需求以及软件需求，通过建立的需求池，结合整体业务流程对需求池中的需求进行判断与分析，首先对需求池进行初步筛选和评估，保留确实可行的需求。 需求梳理分析时，我们可以通过几个不同的维度进行分析。 2. 需求来源 1）业务需求： 业务需求某种程度可以理解为产品建设的目标 2）用户需求： 使用者需要完成什么任务，完成这个任务的过程中遇到的问题；这里需要注意的是用户需求可能是零散且存在矛盾的，用户会从不同角度，不同层面提出需求，因为用户处于不同层级，不同部门。 3）软件需求： 用户需求类型： 获取用户需求分三类：意识到的需求、无意识需求、进一步的需求。 无意识需求是用户在实际工作场景中「没有意识到是问题」的问题，这种问题需要产品经理对业务有一定理解。 意识到的需求通常是一些困扰用户的问题，或者是用户自己能想到的功能。但是往往无意识需求和进一步需求才是产品设计的功能兴奋点。 侧重点：针对不同层级我们要考虑的侧重点是不同的。 ①高层管理人员
②中层管理人员
③操作层
3. 需求评审 需求评审会： 汇总完所有的需求到需求池后，产品经理需要组织需求评审会议，邀请相关同事参会，围绕风险大小、成本把控、开发难度、现有资源以及版本周期对《需求池》进行评审，讨论V1.0版本需要做哪些需求。 会议结束后，产品经理把需求池列表的需求进行过滤，把V1.0版本初步需要做的需求进行需求整理，确认本版本需求列表。 需求确认会： 汇总完所有的V1.0需求，产品经理需要组织需求确认会议，确定需求评审会议后确定下来的需求。 产品经理需要记录这次会议上针对需求提出来的一些讨论结果的记录。（在此期间可能会爆发新一轮的需求讨论，但产品需要确认好最终的需求版本） 产品会后需根据需求确定的版本进行排期。 最终需求表： 需求确认会后，产品经理需要整理一份《最终需求确认表》，确认本次版本的内容以及排期（排期需要与研发leader先行讨论定制）后，以邮件形式发给需求方，进行需求确认的相关事宜，告之相关部门及人员安排好工作，准时参与需求确认工作，为顺利完成需求确认工作做准备。 产出物：最终需求确认表 此阶段主要在需求确定之后，整理产品需求方案，方案内容主要针对：核心业务流程、产品定位 （在这里也不做深入讲解，后续文章会补足完善） 应用架构、功能模块以及演进蓝图（迭代规划）进行整理。 产出物： 产品流程架构图 产品交互原型图 页面交互说明 产品需求文档 测试验证主要是为了比较实际输入与预期输出的差别，以确定系统的正确性、完整性。可通过设计的产品原型方案给到各部门相关人员体验，体验结果可制定体验反馈表反馈至产品负责人，由产品负责人统一收集处理，修改产品方案并再次进行评审确认直至通过。 这个测试主要是方案（原型），这一步至关重要。 产出物：体验反馈表
|
|
|
