策划案例分析（几个案例解析）

　　策划案例分析（几个案例解析）
　　做产品方案的时候，我们经常会走进死胡同或者跑错路，最后不论是开发还是市场，对结果都不满意，产品自然就成了背锅侠！但是往往我们出方案的时候，多想一些问题，或许结果就不一样，跟新人交流的时候，发现一些能力需要可以单独训练，有意识的去理解一些东西，长期积累就会有自己的一套解决问题的思路。
　　1. 辨别真伪的能力
　　辨别真伪也就是老生常谈的真伪需求的能力，在产品经理的行业里，经常会进行需求的评审，需求的界定，看这个需求是否是真的有效
　　举个例子
　　行业：外卖行业
　　案例：打包费审核的功能
　　功能出发点：解决商家乱设打包费的需求
　　解读：如果从这个角度来讲，打包费审核完全没必要，原因有
　　未必所有的商家都乱设打包费，只是个别现象
　　及时设置了打包费审核，后台审核了，也没办法解决，除非后台做强制性的更改或下架商品的功能
　　打包费是商家自主行为，如果商家恶意设置打包费，是给自己添堵
　　如果真想解决此问题，在商家上传商品的时候设置打包费的选项，一个餐品打包费最多是多少
　　或许极个别的商家的打包费真的会比较高，可以在商家管理后台做好打包费配置即可，从源头控制
　　很显然，要在后台做一个打包费审核的功能，还需要让人专门处理此业务，对系统来说，是降低效率又不见得有效果的，所以，界定为伪需求。那么既然存在这样的问题，可替代方案如下：
　　商家添加商品时打包费又两个选择【收打包费】【不收打包费】，打包费为行业标准，1元/份餐品；
　　对于大型的打包盒，比如说探鱼这些商家，打包费可以开放设置（大型连锁或者知名品牌可以认定为不需要通过打包盒来赚取利润）。
　　辨别真伪的能力不仅仅体现在能辨别出来，更多的是能够用更灵活的方式来解决来自运营、消费者产生的问题，且不增加过多的额外工作。
　　2. 找到合适定位的能力
　　合适定位的能力，这个说的有点虚，用通俗的话来讲，就是找个抄的对象。在国内想要做一个App有大量的抄袭模仿对象，各大知名厂商已经做了很多的研究，剩下的就是模仿和创新。能不能找到合适的模块去进行创新，这个就比较重要。
　　案例1：外卖行业，推荐商家
　　功能出发点：外卖行业的推荐商家，很多事按照细分的行业来做的，比如说美团跟饿了么的【必吃菜品】【品质联盟】这些，但是对消费者来说，这真的是我想要的选择么？
　　解读：从消费者的心理出发，我去找吃的，可能出于几点
　　找新鲜：看看这附近有什么新鲜的店铺开业或者新的口味，外卖一个月都是那几家，早就腻了
　　找实惠：外卖分量不够，10块钱管饱的那种最好
　　速度快：能告诉我最快的是哪家么？
　　其次还有可能
　　这两天身体不舒服，想吃点口味淡的
　　我是湖南湖北人，我想吃点重口味的
　　……
　　因此，从这类具有标示性的标签入手，会更有效果。此类功能类似于一点点的餐牌设计以及lofter的标签设计，将商家分配不同的标签跟消费者的消费场景对应上，交叉进行推荐，比如说一个商家有很多种口味，那对应的消费者人群也会多，消费者通过对应标签可以快速找到对应的商品，对消费者和商家都是互利的，我们经常会遇到一个外卖店铺有几十种餐品，找半天还是不知道吃啥。
　　（配个截图，此功能已实现，后续看数据情况，再做追踪）
　　顺便说一下，之前饿了么有个版本放大对餐品的显示，做餐品的推荐，后来又改回来，具体是什么因素，不确定，但那也是一种尝试。
　　案例2：荔枝FM飞机稿
　　出发点：那是很早以前的一个版本，因为不好用，所以就干脆做一个交互飞机稿，当时做的时候有以下几个因素：
　　体验不好，最古老的版本体验非常不爽（详情可以戳这里：http://www.woshipm.com/ucd/209199.html）
　　当时在做交互设计，就尝试用新的交互设计思路去设计
　　解读：
　　当时荔枝FM算是国内比较早做电台的，同期出了喜马拉雅听，刚开始也没有荔枝FM那样火，但从交互上，主要由两个点：
　　模拟电台操作：荔枝FM当时还是走拟物化设计（新进入互联网的可能觉得是历史），那从FM收音机的角度来说，都有一个旋钮，或者是老式的随身听，因此在主页的界面设计以及播放界面设计都有参考古老随身听的样式，既然复古，我们就彻底点
　　数据整理：在当时做荔枝FM的飞机稿时，主要做的是数据层的整理，把繁杂的内容数据变得有序可循，让用户和博客可以更快找到合适自己的内容
　　对于合适的定位可以理解为：每个事物或许有自己固有的长相，但或许我们找到合适的逻辑后，只要抓住根本，那最后怎么玩，还是大家说了算，打破陈规，才更好玩。为什么音乐软件就一定要有那么大的播放界面；为什么订餐软件就一定要宣传店铺，不能是商品？
　　3. 解决问题的能力
　　这个就老生常谈了，解决问题的能力体现在对系统的掌握程度和开发自由度两个层面，产品经理实质是提供解决方案的，任何需求到手后，我们需要分析如何快速解决该问题。
　　案例1：招聘面试流程
　　出发点：销售类岗位进行招聘时，都是一大批一大批的面试，一个人可能同时面试很多岗位，一个公司会面试很多个求职者，因此提高效率，对求职者和公司都是最大的需求
　　解决方案：排队叫号，跟银行排队一样，针对这个场景，我们梳理了核心的问题
　　面试人员取号
　　面试人员查看各岗位当前排队情况及投递请求
　　企业招聘人员查看简历并选择是否面试，对面试的人进行初步评论
　　叫号及数据导出
　　针对以上四个问题，设计出如下流程（省略取号的环节，主要核心的流程是企业的发送通知循环以及面试后的符合不符合操作循环）
　　从流程图可以发现，核心逻辑并不复杂，解决了通知求职者来面试的需求以及对求职者进行评价需求即可；除此之外还可以做一些其他的功能，如求职者可以看到当前排队情况，根据实际情况进行简历投递，避免出现大量等待情况，可预知自己还要多久可以面试，在这时间内是否可以投递其他公司，进行多项选择；对于企业解决各种纸质简历分辨不清，电子档简历，电子记录每一个求职者和操作，可以清楚知道今天面试记录，电子档案，更清楚，提高双方的效率。
　　4. 了解数据的能力
　　对于数据，很多人应该不会陌生，如何从杂乱的数据找到规律，怎么处理数据之间的关系？
　　一级页面到二级页面的流失率和转化率
　　每个页面转化功能的设计及数据统计
　　数据解读
　　最近在做小程序相关的项目，把腾讯的数据统计贴上来:
　　访问趋势类：
　　time 时间
　　session_cnt 打开次数
　　visit_pv 访问次数
　　visit_uv 访问人数
　　visit_uv_new 新用户数
　　stay_time_uv 人均停留时长 (浮点型，单位：秒)
　　stay_time_session 次均停留时长 (浮点型，单位：秒)
　　visit_depth 平均访问深度 (浮点型)
　　访问分布：
　　access_source_session_cnt 访问来源分布
　　access_staytime_info 访问时长分布
　　access_depth_info 访问深度的分布
　　访问留存
　　visit_uv_new 新增用户留存
　　visit_uv 活跃用户留存
　　访问页面：
　　page_path 页面路径
　　page_visit_pv 访问次数
　　page_visit_uv 访问人数
　　page_staytime_pv 次均停留时长
　　entrypage_pv 进入页次数
　　exitpage_pv 退出页次数
　　page_share_pv 转发次数
　　page_share_uv 转发人数
　　总结
　　产品经理从拿到需求开始就需要对需求进行分解，判断到底什么样的方案可以解决此问题，并结合当前系统的一些功能点，给出最佳的方案；在交互设计的时候是参考竞品还是微创新，就看实际业务需求；最后就是核心业务梳理，一个功能的核心业务是什么，还有哪些可以搭配让功能更完善的，考虑进去，做产品是一个分解、组合、删减、再组合的过程！