4.4 分析需求：用图形代言需求
4.4.1 需求蛋模型（理论，了解即可）
Gerald M.Weinberg在《探索需求》中提到了需求理论：需求是我们想要的东西和我们不想要的东西。同时，我们收到的需求，总是含混的。做需求相关的工作，就是不断地降低含混。
由于每个人生活背景、知识体系不同，对事物的理解也不一样，这就造成了用户在表述需求时的含混。产品经理的工作，就是不断的讲波浪线拉近成直线，从成本和实现价值的角度来对需求进行分类，从而找到必不可少的需求及锦上添花的需求。
4.4.2 思考需求：痛点×收益×明确、可行、简单的第一步 > 维持现状（理论，了解即可）
痛点：客户迫切需要满足的需求。（B端产品多业务走一走，容易发现痛点）
收益：收益是投入资源后获得的成果。（需要可以量化，提升多少，降低多少），关键还是改变用户的行为。
明确、可行、简单的第一步：我们所提供出来的需求方案，是投入资源立刻就可以开发的。产品经理思考出可行性方案需要简单，方案可以快速迭代。当遇到多个方案无法抉择时，选择最简方案。
维持现状：收到的需求，如果用户对这个需求的痛点感觉不强烈、收益不高或者没有可行、确定、简单的方案。只要满足其中一个条件，那么这个需求就可以暂时维持现状。
4.4.3 解析需求：用图形为需求代言
解析业务和探索需求的方法论：UML（统一建模语言）
注意：数据驱动：行为产生数据，数据联系行为
数据流动形成数据流，从而把业务中的人联系在一起。（数据的流动一定是有输入和输出）
一些常用图解：
流程图（把业务流程描述清楚）必须懂
第一步：先总结主要流程。
举例（吃饭）：进店—点餐—下单—制作食物—送餐—就餐—结账—离店
第二步：再对框架进一步细化。
举例（点餐）：查看菜单—介绍菜品信息—选择菜品—添加至订单—结束选菜—核对订单—下单
实物关系图（ER图，用于数据库和表结构的设计）了解就行
数据之间的三种关系：一对一，一对多，多对多
用例图（UC）了解就行
（网上随便找的图，仅做了解）
4.4.4 需求的输出物：需求文档
1.需求文档包含的内容
需求范围：包含用例名称、使用角色、优先级、备注
业务概念（不一定要有）：放实体关系图，解释每一个元素具体定义，包括的属性数据有哪些。
流程展示：流程图和页面流程图
需求描述：
非功能需求：
把性能的好坏拆分成各种具体的参数和跑分，比如：搜索单号要在0.5秒反馈结果。
总结：分析需求
产品经理做什么？
使用图形化的工具，对业务方的需求进行抽象和具象化并形成结构化的文档，以推进后续开发。
有什么可以提供帮助的工具？
会议产品经理与需求方坐在一起讨论需求，往往会比较高效的了解需求。
UML。通过学习UML，使用流程图、实体关系图等工具来高效地分析需求。
做完得到什么？
需求说明文档
4.5 管理需求：打造简单可实践的需求池
4.5.1 为什么要做需求管理
产品经理在工作中每天忙碌地处理需求，虽然每天都很充实，但极为耗费精力，时间长久的话就会缺乏动力，不容易朝着战略规划的方向走。
需求管理的宗旨
积极主动：核心，主动承担责任，去推进事情的落地。（执行力和推动力）
知识共享：分享不同团队的领域知识，减少沟通的未知区域，从而减少沟通中的误解。（协作沟通，及时备注说明）
相互尊重：每个人站在不同的立场，有着不同的知识储备，看待问题必然会有不同的观点和角度（换位思考，以目标结果、数据为导向）
4.5.2 需求管理中的干系人和角色
干系人：是能影响项目决策、活动或结果的个人、群体或组织，以及会受或自认为会受项目决策、活动或结果影响的个人、群体或组织。
在需求中每个人都会从自己的立场出发提出需求，可能会不经意间破坏别的业务线的流程，所以需要产品经理从全局的角度去思考需求，把不同的关注点都考虑到位。
需求管理中的角色：需求人，负责人，产品经理，研发经理，研发工程师，测试工程师。
4.4.3和4.4.4不属于核心知识点，不做展示
4.5.5 需求池的核心：优先级和重要性
1.什么是需求池
需求的状态：筹备中、待排期、待开发、开发中、待测试、测试中、待上线、已完成。
需求池是为了帮助产品把握产品的发展状态，把控项目进度的工具。
作者的需求池
书中的需求池属于大公司业务下多个产品线才使用到，我个人建议做一下精简优化，找到合适自己的就是最好的：
守约的需求池
2.优先级——需求分类和排序
优先级表现形式多样数字、汉字、字母都可以，选择适合自己的去使用即可。
我们可以对优先级定义，便于我们快速的对需求进行归类。（根据所在公司和组织及所经营的业务来进行综合评估，比如有些公司的当前业务流程繁琐，员工效率低下，只要优化就一定可以极大的提高人效，那么这时候提高工作效率的需求就会到最高优先级，实际情况实际分析）
大多数需求的评定标准
3.重要性——优先级的辅助
重要性是对需求进行打分，用户对同一个等级的需求进行排序不代表其他信息。
4. 统一地看优先级和重要性
优先级和重要性一旦确定，将贯穿需求的整个生命周期，所有的资源将根据优先级和重要性被安排。
划分需求的优先级和重要性是围绕企业和组织的战略。
4.5.6 需求收集的工具
收集需求的模板：用户的愿望清单
4.5.7 需求管理的证伪
值得思考的三个问题
问题一：如何评估工作量？
让研发经理或者研发工程师评估工作量，以天数为单位。一方面要看开发，一方面产品要自己通过经验累积去评估。
问题2：如何确定需求完成的时间？
根据需求管理周期进行测算，比如会在1周内发布，或者2周内完成。当然也可以问开发需要多久
问题3：如何处理长期堆积在需求池中的需求？（重点）
产品经理需要时常关注已经积累了很长时间的需求，可以以三个月的时间为标准。产品经理要通过各种方式与需求人和负责人沟通，分析在需求池长达三个月的需求到底出现了什么问题。看看这些需求是否不适于公司的发展方向，若它们已经被部门战略规划抛弃，是否可以将这些需求删除或者重新修订后再提出。
总结：管理需求
产品经理做什么？
产品经理通过协作，管理需求从建立到发布上线。（优先级，重要性，排期）
有什么可以提供帮助的工具？
项目管理
SWOT分析、KANO模型等分析工具
做完得到什么？
需求池
需求排期计划