一、需求复盘=产品经理自我迭代

这周看了俞军的《产品方法论》，里面一章介绍到了滴滴在产品演进的路径上遇到的几个有意思的产品需求决策问题，比如快车在高峰期应该用动态调价模式还是排队模式，如何满足酒后乘客打车的问题（又要减少对司机带来的影响），书中写下了具体实现的方法、遇到的问题以及后续的优化等思考决策的全过程。

受此启发，我决定制作一个需求复盘模板，方便自己对一些重要的需求实现进行复盘和思考，同时也公开给大家使用。复盘模板具体分为以下5个步骤：

需求复盘模板：

1. 需求背景
2. 初始做法
3. 遇到的问题
4. 分析原因
5. 下一次行动与洞察

下面我们通过4个具体的需求复盘例子来看看应该如何使用这个模板。

二、案例① 出行高峰如何打到车？

1. 需求背景：出行行业有明显的峰值，且峰具有非常强的时间、地点属性，比如下班时的CBD，同时因为道路拥挤、司机供给等因素，最终结果就是供需失衡：司机在高峰期不愿意去热区；用户在高峰期打车难。

2. 初始做法：采用动态调价，在高峰期临时调整打车价格，让出价意愿高的用户得到打车的机会，其实本质上是用高价格打压打车的需求，但是用户打车的需求又是刚需，这样会导致用户体验很差。要回归解决问题的本质，要考虑”更快打车“的三层含义：

1. 第一层是对何时能打到车的预期（预计多久打到车倒计时）；
2. 第二层是这个预期是否准确（预测的打车时间是否准确）；
3. 第三次是这个预期能否做得更快。

因此滴滴推出了排队的模式：在出行高峰时，会出现排队队列序号、排队计时、预计打到车的时间等提示给用户端，控制用户预期并给司机供给侧更多的调度时间。

3. 遇到的问题：有不可预测的紧急情况下，也有用车需求，排队功能无法满足迫切打到车的需求。

4. 分析与解决：引入排队功能后，隐含的是大家对于出行的紧急程度都是一样的一种假设公平状态，事实上还会有很多紧急状况，导致每个打车用户的紧急程度（或者说产品效用）是不一样的。这时需要滴滴需要引入“紧急程度”的处理机制。

5. 下一次行动与洞察：只有用户可以表达自己紧急的诉求，因此这个紧急程度应该是用户主动评判的，在用户主动发出“紧急”的信号后，可以走排队的快速通道（很容易理解），然后通过限制每月使用次数来保证公平性。次数可以通过会员等级获得，也可以通过积分兑换（这点可以和会员体系、积分系统打通，对产品总效用提升大）。后面类似的增值服务，都可以通过会员体系来解锁，增加了滴滴的替换成本（加深护城河）。

三、案例② 醉酒乘客打车问题的权衡

1. 需求背景：醉酒乘客乘车，容易和司机发生纠纷，平台也存在比较严重的安全风险和服务难点：

1. 容易发生性骚扰或者影响司机驾驶
2. 乘客到目的地后无法保持清醒，司机没办法开始下一笔订单
3. 乘客可能呕吐弄脏车辆，产生额外的清洁费用

2. 初始做法：保持司机不能随便拒绝订单的限制（司机每天有2次无责任拒单机会），但引导酒后用车的用户主动报备。

3. 遇到的问题：没有特别好的方法满足该场景下多方的需求，即使用户主动报备，还是会出现需求背景中提到的问题场景。

4. 分析原因：在该场景中，不确定性是由酒后乘车的用户带来的，作为平台只能对自身以及司机的行为进行约束，而无法约束用户行为，也就是无法先验地防止这类事情发生，平台能做的事情是意外发生后进行及时的弥补措施。通过引导用户主动报备，可以提前告知司机潜在的风险以及进行心理建设。

5. 下一次行动与洞察：

1. 大部分意外情况的结果都转化为经济纠纷，比如清理费用、等待超时的费用，这方面可以由平台作为第三方把账单给用户进行收取，平台可以垫付或者等用户支付后转给司机；
2. 本身滴滴存在会员体系，可以在会员体系中引入黑名单或者通过会员权益收回达到惩罚违规用户不守信用用户的目的，书中也提到过“权力三角”的原则，通过教育用户珍惜和保护自己的权力来进行行为引导和约束。这样也避免了平台向乘车用户的绝对倾斜，损害了司机侧的效用。

四、案例③ 乘客中途需要修改目的地

1. 需求背景：乘客已经上车，在需要修改目的地时，平台没有提供对应的功能，都是用户与司机进行线下沟通，因此可能产生不可控的司乘纠纷。

2. 初始做法：滴滴上线了允许修改目的地的功能，用户在上车后，可以在app上更改目的地。

3. 遇到的问题：对用户来说，提供了功能代表允许（至少功能上允许）更改目的地，但是这引起了司机的不满。对于滴滴平台来说，司机代表供给侧的用户，乘客代表消费侧的用户。消费者的效用提升是以司机侧的效用降低为代价的，长远来说带来的总效用可能是负的。

4. 分析原因：在平台、司机、乘客的三角关系中，其地位乘客>平台>司机，司机处在相对弱势的地位，同时修改目的地的需求损害了司机的效用（具体可能表现为订单收益降低，期望收益受损，人是有损失厌恶的），但是平台和司机也只是合作关系，司机离开滴滴的沉没成本低，可能会导致司机出走，供给端被削弱，直接抬高了运力成本，最终还是反映到用车成本上升上。那么修改目的地的决策问题就转化成满足乘客修改目的地的效用提升和用车价格上升，最终还是成本问题。

5. 下一次行动与洞察：保持司机无法随意拒单的限制（实际一天有2次拒单机会），在此基础上允许乘客有限制地修改目的地（只能改一次/只能改为原目的地范围内/加钱改目的地等），在尽量不损失司机收获效用地基础上，满足乘客修改目的地的需求。

五、案例④ 门户内容的置顶和排序

1. 需求背景：对于类似今日头条等资讯类web或者app，发布在门户的内容，需要人为控制排序，有些内容是日常置顶，其余内容也想手动调整排序。

2. 初始做法：在列表页中直接加操作列，控制某个属性的开关，比如首页的轮播位置，对应的开关列属性就是首页轮播。不过轮播的位置容纳的数量有限，因此如果有超过容器上限的内容数量开启了轮播，会再过滤最新的N条（N是容器上限）。

排序则直接新增排序操作列，通过控件的置顶、上移一位、下移一位、置底4个icon操作按钮进行位置的调整。

3. 遇到的问题：属性开关多了之后，虽然取了发布时间进行过滤，但是在列表页上是允许操作比展示数量上限多的开关，会造成后台和前台的数量不对应（反直觉）；排序调整在跨页的情况下失效，在筛选状态下执行的操作难以理解。

4. 分析原因：属性开关的只考虑了需求实现，没有考虑网站运营人员的使用体验。排序的功能则是比较粗暴地实现，没有挖掘背后的需求。

5. 下一次行动与洞察：目前只用一个集中的内容列表，是对全状态内容的维护，包括审批、二次编辑、删除、上下架等，但是对展示属性控制以及顺序调整，要针对已发布状态下的内容才有意义，而且一般对内容的顺序管理会要求在最新的一批，不会总是对内容进行全量的排序调整，因此隐含着只对最新一定数量的内容进行顺序管理。

那么改进的做法就是新起一个tab，专门展示状态为已发布的，集中对已发布的内容进行置顶和顺序的管理。具体改进措施有：

1. 对特殊属性的控制依旧使用开关的形式，问题转化为如何控制数量。可以考虑采用冒泡的形式，限定上限为N时，当开启第N+1个属性时，会自动关闭第1个，保持总数最多为N
2. 针对顺序控制：列表带有分页器，假设对最新的前50条内容进行属性和排序控制（具体X条每页可以根据实际情况调整）。如此可以保证用户在1页内对内容进行排序调整，规避了排序时跨页的问题，同时针对已发布状态单独切tab，也过滤了无关的内容，保持页面展示的内容是必要的。

六、案例需求复盘模板小结

经过上面几个具体的例子，我自己给每个步骤定义的具体内容如下：

1. 需求背景：描述需求产生的背景、原因、必要性等；
2. 初始做法：记录第一次产品需求实现的思路和方案；
3. 遇到的问题：产品需求实现后，遇到的新问题；
4. 分析原因：从新的问题，反推是需求处理的时候，是解决方向错误/边界没有确定好/对分支、异常情况的处理有遗漏等哪些原因导致目前的问题。为什么不能提前就考虑到这些方面？
5. 下一步行动与洞察：经过1-4的分析，我们就可以得到：①下一次迭代改进的方向；②通过错误总结形成经验沉淀；③在同一个需求上进行深挖，形成更深或者触类旁通的洞察！

这次的分享就到这里！希望大家也可以用上这个需求复盘模板，在产品经理的成长路上驶入高速公路！开瓶冰可乐奖励自己！[]~(￣▽￣)~*