大家好！
我是爱喝冰可乐的产品经理P仔！
一、需求复盘=产品经理自我迭代
这周看了俞军的《产品方法论》，里面一章先容到了滴滴在产品演进的路径上碰着的几个故意思的产品需求决策问题，比如快车在高峰期该当用动态调价模式还是排队模式，如何知足酒后搭客打车的问题（又要减少对司机带来的影响），书中写下了详细实现的方法、碰着的问题以及后续的优化等思考决策的全过程。
受此启示，我决定制作一个需求复盘模板，方便自己对一些主要的需求实现进行复盘和思考，同时也公开给大家利用。复盘模板详细分为以下5个步骤：
需求复盘模板：
下面我们通过4个详细的需求复盘例子来看看该当如何利用这个模板。
二、案例① 出行高峰如何打到车？
1. 需求背景：出行行业有明显的峰值，且峰具有非常强的韶光、地点属性，比如放工时的CBD，同时由于道路拥挤、司机供给等成分，终极结果便是供需失落衡：司机在高峰期不愿意去热区；用户在高峰期打车难。
2. 初始做法：采取动态调价，在高峰期临时调度打车价格，让出价意愿高的用户得到打车的机会，实在实质上是用高价格打压打车的需求，但是用户打车的需求又是刚需，这样会导致用户体验很差。要回归办理问题的实质，要考虑”更快打车“的三层含义：
第一层是对何时能打到车的预期（估量多久打到车倒计时）；第二层是这个预期是否准确（预测的打车韶光是否准确）；第三次是这个预期能否做得更快。因此滴滴推出了排队的模式：在出行高峰时，会涌现排队行列步队序号、排队计时、估量打到车的韶光等提示给用户端，掌握用户预期并给司机供给侧更多的调度韶光。
3. 碰着的问题：有不可预测的紧急情形下，也有用车需求，排队功能无法知足急迫打到车的需求。
4. 剖析与办理：引入排队功能后，隐含的是大家对付出行的紧急程度都是一样的一种假设公正状态，事实上还会有很多紧急状况，导致每个打车用户的紧急程度（或者说产品效用）是不一样的。这时须要滴滴须要引入“紧急程度”的处理机制。
5. 下一次行动与洞察：只有用户可以表达自己紧急的诉求，因此这个紧急程度该当是用户主动评判的，在用户主动发出“紧急”的旗子暗记后，可以走排队的快速通道（很随意马虎理解），然后通过限定每月利用次数来担保公正性。次数可以通过会员等级得到，也可以通过积分兑换（这点可以和会员体系、积分系统打通，对产品总效用提升大）。后面类似的增值做事，都可以通过会员体系来解锁，增加了滴滴的更换本钱（加深护城河）。
三、案例② 醉酒搭客打车问题的权衡
1. 需求背景：醉酒搭客乘车，随意马虎和司机发生轇轕，平台也存在比较严重的安全风险和做事难点：
随意马虎发生性骚扰或者影响司机驾驶搭客到目的地后无法保持复苏，司机没办法开始下一笔订单搭客可能呕吐弄脏车辆，产生额外的清洁用度2. 初始做法：保持司机不能随便谢绝订单的限定（司机每天有2次无任务拒单机会），但勾引酒后用车的用户主动报备。
3. 碰着的问题：没有特殊好的方法知足该场景下多方的需求，即利用户主动报备，还是会涌现需求背景中提到的问题场景。
4. 剖析缘故原由：在该场景中，不愿定性是由酒后乘车的用户带来的，作为平台只能对自身以及司机的行为进行约束，而无法约束用户行为，也便是无法先验地防止这类事情发生，平台能做的事情是意外发生后进行及时的填补方法。通过勾引用户主动报备，可以提前奉告司机潜在的风险以及进行生理培植。
5. 下一次行动与洞察：
大部分意外情形的结果都转化为经济轇轕，比如清理用度、等待超时的用度，这方面可以由平台作为第三方把账单给用户进行收取，平台可以垫付或者等用户支付后转给司机；本身滴滴存在会员体系，可以在会员体系中引入黑名单或者通过会员权柄收回达到惩罚违规用户不取信誉用户的目的，书中也提到过“权力三角”的原则，通过教诲用户珍惜和保护自己的权力来进行行为勾引和约束。这样也避免了平台向乘车用户的绝对倾斜，危害了司机侧的效用。四、案例③ 搭客中途须要修正目的地1. 需求背景：搭客已经上车，在须要修正目的地时，平台没有供应对应的功能，都是用户与司机进行线下沟通，因此可能产生不可控的司乘轇轕。
2. 初始做法：滴滴上线了许可修正目的地的功能，用户在上车后，可以在app上变动目的地。
3. 碰着的问题：对用户来说，供应了功能代表许可（至少功能上许可）变动目的地，但是这引起了司机的不满。对付滴滴平台来说，司机代表供给侧的用户，搭客代表消费侧的用户。消费者的效用提升因此司机侧的效用降落为代价的，长远来说带来的总效用可能是负的。
4. 剖析缘故原由：在平台、司机、搭客的三角关系中，其地位搭客>平台>司机，司机处在相对弱势的地位，同时修正目的地的需求危害了司机的效用（详细可能表现为订单收益降落，期望收益受损，人是有丢失厌恶的），但是平台和司机也只是互助关系，司机离开滴滴的沉没本钱低，可能会导致司机出走，供给端被削弱，直接抬高了运力本钱，终极还是反响到用车本钱上升上。那么修正目的地的决策问题就转化成知足搭客修正目的地的效用提升和用车价格上升，终极还是本钱问题。
5. 下一次行动与洞察：保持司机无法随意拒单的限定（实际一天有2次拒单机会），在此根本上许可搭客有限定地修正目的地（只能改一次/只能改为原目的地范围内/加钱改目的地等），在只管即便不丢失司机收成效用地根本上，知足搭客修正目的地的需求。
五、案例④ 门户内容的置顶和排序
1. 需求背景：对付类似今日头条等资讯类web或者app，发布在门户的内容，须要人为掌握排序，有些内容这天常置顶，别的内容也想手动调度排序。
2. 初始做法：在列表页中直接加操作列，掌握某个属性的开关，比如首页的轮播位置，对应的开关列属性便是首页轮播。不过轮播的位置容纳的数量有限，因此如果有超过容器上限的内容数量开启了轮播，会再过滤最新的N条（N是容器上限）。
排序则直接新增排序操作列，通过控件的置顶、上移一位、下移一位、置底4个icon操作按钮进行位置的调度。
3. 碰着的问题：属性开关多了之后，虽然取了发布韶光进行过滤，但是在列表页上是许可操作比展示数量上限多的开关，会造成后台和前台的数量不对应（反直觉）；排序调度在跨页的情形下失落效，在筛选状态下实行的操作难以理解。
4. 剖析缘故原由：属性开关的只考虑了需求实现，没有考虑网站运营职员的利用体验。排序的功能则是比较粗暴地实现，没有挖掘背后的需求。
5. 下一次行动与洞察：目前只用一个集中的内容列表，是对全状态内容的掩护，包括审批、二次编辑、删除、高下架等，但是对展示属性掌握以及顺序调度，要针对已发布状态下的内容才故意义，而且一样平常对内容的顺序管理会哀求在最新的一批，不会总是对内容进行全量的排序调度，因此隐含着只对最新一定数量的内容进行顺序管理。
那么改进的做法便是新起一个tab，专门展示状态为已发布的，集中对已发布的内容进行置顶和顺序的管理。详细改进方法有：
对分外属性的掌握依旧利用开关的形式，问题转化为如何掌握数量。可以考虑采取冒泡的形式，限定上限为N时，当开启第N+1个属性时，会自动关闭第1个，保持总数最多为N针对顺序掌握：列表带有分页器，假设对最新的前50条内容进行属性和排序掌握（详细X条每页可以根据实际情形调度）。如此可以担保用户在1页内对内容进行排序调度，规避了排序时跨页的问题，同时针对已发布状态单独切tab，也过滤了无关的内容，保持页面展示的内容是必要的。六、案例需求复盘模板小结经由上面几个详细的例子，我自己给每个步骤定义的详细内容如下：
需求背景：描述需求产生的背景、缘故原由、必要性等；初始做法：记录第一次产品需求实现的思路和方案；碰着的问题：产品需求实现后，碰着的新问题；剖析缘故原由：重新的问题，反推是需求处理的时候，是办理方向缺点/边界没有确定好/对分支、非常情形的处理有遗漏等哪些缘故原由导致目前的问题。为什么不能提前就考虑到这些方面？下一步辇儿为与洞察：经由1-4的剖析，我们就可以得到：①下一次迭代改进的方向；②通过缺点总结形成履历沉淀；③在同一个需求上进行深挖，形成更深或者举一反三的洞察！这次的分享就到这里！
希望大家也可以用上这个需求复盘模板，在产品经理的发展路上驶入高速公路！
开瓶冰可乐褒奖自己！
~(￣▽￣)~🍻
本文由@产品经理P仔 原创发布于大家都是产品经理，未经容许，禁止转载。
题图来自Unsplash，基于CC0协议。
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。
