《从点子到产品》读书笔记（一）
背景
五一期间，花了两天的时间阅读完本书。这是一本讲述产品经理将点子实现为产品过程中，围绕着产品问题展开，论述了产品应该思考哪些问题，如何思考问题，以及如何解决问题。此外，作者还结合自己做的项目，传授了一些需求管理、工作流管理的经验。
如何确定需求优先级
对于需求的优先级有两种常见的排序方法。一种是基于四象限法则，另一种则是基于 KANO 模型。
四象限法则
image.png
我们要把紧急且重要的需求排在最前，不紧急但重要的需求其次，紧急不重要的需求再次，最后是不紧急不重要的需求。（突然想到了，时间管理也是遵循这样的法则）
而在判断是否重要时，可以参考这样的排序（重要程度由强到弱）：
- 不做，会造成严重的问题和恶劣的影响
- 做了，会产生巨大好处和极佳效果
- 跟核心用户利益有关
- 跟大部分用户权益有关
- 跟效率或成本有关
- 跟用户体验有关
判断是否紧急，可以参考以下排序（紧急程度由强到弱）：
- 不做，错误会持续发生并造成严重影响
- 在一定时间内可控但长期会有糟糕的影响
- 做了，立刻能解决很多问题、产生正面的影响
- 做了，在一段时间后可以有良好的效果
KANO 模型
另外一种很常用的方法是东京理工大学教授狩野纪昭（Noriaki Kano）提出的 KANO 模型。下面是作者简化版的KANO模型，如下：
image.png
作为一个需求对应的功能，「行」描述的是「如果有的话」，用户会「开心」、「无所谓」还是「不开心」；「列」描述的是「如果没有的话」的情况。具体分析如下。
矛盾：如果用户觉得功能存在和不存在都很开心，或者都不开心，显然是有问题的，这种矛盾的情况是存在逻辑问题的，不予考虑。
错误：如果功能不存在让用户很开心，或者功能存在让用户不开心，那么这个功能显然是错误的功能，不予考虑。
无关：如果功能存在和不存在，用户都觉得无所谓，那功能也就无关紧要了，同样不予考虑。
最重要的就是以下三类需求：
必要：如果功能存在，用户并没有特别的感觉，但功能不存在，用户会不开心。这说明这个功能是要满足基本需求的，也就是大家常说的「痛点」。
期待：如果功能存在用户很开心，功能不存在用户很不开心，这就是满足用户最直接、最明显的需求了，因为在用户内心已经有所期待。
惊喜：如果功能不存在的时候用户并没有感觉，说明对这个功能，用户之前没有预期，但功能存在用户很开心，也就是说达到了惊喜的效果。这就是我们在第 2 章所说的能够超预期满足用户。
这三种需求的优先级的次序：必要 > 期待 > 惊喜
小结
基于四象限法则或者 KANO 模型，可以完成优先级的标注。通常我们会用 P1、P2、P3、P4 来标注不同优先级的需求，P1 优先级最高，P4 优先级最低。
如何安排开发需求次序
面对已经排好优先级的需求，我们还不要急着安排开发。作者认为「开发需求次序」可以按照「需求性价比」进行排序。那么，如何得到「需求性价比」呢？
开发成本 + 需求的优先级 = 需求的性价比
下面结合书中的例子，简单描述一下如何得到「需求性价比」
Step 1 将各方的需求按照重要紧急程度进行分类
书中以美甲项目为例，作为产品经理会收到各方的需求：
来自老板的：
实时记录美甲师的 GPS（要解决刷单的问题）
首页有点杂乱，不够简洁（纯粹视觉上的问题）来自运营的：
要统计用户对每个 Banner 的点击率（看活动结束后的效果）
秒杀功能（下周就要做活动，通知发出去了，必须做）
需要提供给用户在线改单的功能（比如换样式，补差价）
提供私人订制的功能（包括用户上传图片、美甲师提供参考价、双方确认等步骤）来自产品的：
用户下单时，支付失败后需要重新下单，不能继续支付，应做优化
下单步骤要跳转太多页面，应该集中在一页输入信息
根据关键词筛选样式的功能
这些需求结合作者判断重要紧急程度的方法，给每一个需求按照优先级分类(P1、P2、P3 优先级由高到低)，记为P图：
image.png
Step 2 与开发同事讨论开发成本，并按照开发成本排序
开发成本按照D1、D2、D3 根据实现成本由低到高排序：
- 记录 GPS：D1（定时记录 GPS，并不复杂）
- 首页简洁：D3（排版布局会耗费大量时间）
- banner 点击率：D1（注入 log，很简单）
- 秒杀功能：D1/D3（可以分简单和复杂两个版本上线，难度不同）
- 在线改单：D2（功能交互比较复杂）
- 私人订制：D3（同样是功能交互复杂）
- 可继续支付：D1（页面改动少，主要是调试接口）
- 简化下单步骤：D2（还是功能交互比较复杂）
- 筛选：D3（后台逻辑需要做大的改动，数据处理也很麻烦）
绘制出图（记为D 图），如下：
image.png
Step 3 结合P图和D图绘制需求矩阵图
image.png
有了矩阵图我们就可以从性价比由高到低的顺序，依次完成需求了。可以按照从1到9的次序。如下图：
image.png
关于产品需求会议需要注意的事项
- 确定需求的优先级
- 确定方案的草稿（与需求方或业务部门根据某一需求，讨论几种方案，并共同认可一个方案）
- 确定负责人
- 划定时间节点（时间节点主要是指方案完成的截止时间，即可以提交给开发的方案）
- 及时更新需求状态给需求来源方。
