案例详解某网络招聘平台版本升级迭代全过程

　　本文作者主要是将详细解析某网络招聘行业巨头平台v3.4版本升级迭代全过程，enjoy~
　　好久不见，对于数千订阅粉丝表示歉意，今天更新给大家剖析某次平台版本升级迭代全流程。
　　经常被问：如何定义一个优秀的产品经理？
　　借用一句话简述，能够在宏观环境和微观场景里持续输出高质量决策的产品人员就是优秀的产品经理。
　　刚入门做产品时，总是希望能看到一些大厂产品大神们剖析分享产品迭代升级的案例，满足自己这个小白的学习欲和崇拜感。这个需求不是个例，对于产品入门小白或者打算入门产品的朋友都希望能一窥究竟，这篇文章将详细解析某网络招聘平台v3.4版本升级迭代全过程。
　　前公司背景：行业巨头，上市公司。
　　产品形态：PC端。
　　产品定位：网络招聘求职平台。
　　迭代背景
　　周五，产品中心收到客服团队发来的近两周客户留言记录，反馈＂招聘效果不佳＂的频次占比较高。
　　产品团队与业务团队针对客户反馈问题进行讨论分析，最终得出三个可能的影响因素：
　　职位曝光度不够高，无法吸引求职者进行相关行为操作，如浏览、收藏、投递；
　　收到的主动投递简历量有限，未达到企业预期；
　　简历存量有限，企业无法搜索到合适的简历。
　　综合分析，简历库的资源存量短期暂时无法解决，收到的简历主动投递数量同时也受职位曝光度高低的影响，因此优先解决职位曝光量问题。另外大部分企业反应招聘效果好，只有小部分企业反馈效果不佳，因此这个功能要考虑做成一个增值业务，提供给有需求的企业客户自由选择。
　　需求分析
　　输出需求1：新增业务-为有需求的企业提高职位曝光度
　　用户分析：企业客户分为3种角色，付费会员客户、体验客户、非会员非体验状态客户。
　　提高职位曝光度的方法：增加职位权重，同一搜索结果下优先排序。
　　业务分析：考虑到业务逻辑设置，职位曝光度排序优先级是在固定逻辑上进行权重的灵活增减。如果按照原有合同套餐模式来销售【新增值业务】，需要服务顾问与客户再次接触，输出电子合同、发票等，整个周期被拉长，成本增加。因此，不考虑按照原有合同套餐来售卖【新增值业务】。
　　输出需求2：平台支持在线支付购买【新增值业务】
　　在线支付沿用自建的支付平台还是第三方支付平台？购物车、订单、交易记录、电子发票申请/寄送、已购商品数量怎么呈现？如何避免最小化干扰原定企业管理中心的功能模块？支付失败页面效果？支付成功，引导用户下一步操作逻辑？
　　原来一个坑挨着一个坑，这也是做产品的乐趣所在了，平平淡淡一眼看到头的工作不太适合我这种多动症人群。
　　输出需求3：【新增值业务】高辨识度的名称
　　职位置顶、金牌职位、置顶刷新，置顶刷新与平台的自动刷新、客户的人工刷新在功能逻辑上如何拉开差异。平台服务器轮询会导致刷新结果有时间延迟，现在变成付费增值功能，客户对时间的敏感度提升，如何告知客户，并让客户实时感知无差别对待的使用体验。
　　输出需求4：新增值业务售价
　　和公司现有业务进行对标，新增值业务在产品集群的定位，承担怎样的角色。另外对标行业友商，有无此类功能，定价高低，是以单次使用来售卖定价，还是按照打包服务来周期性定价。
　　按照单次使用定价售卖，用户认知度高，感谢多年来电商平台的使用习惯教导，但是对业务集群而言，客单价低，在推广资源上就不会占优势。如果按照打包售价，客户对剩余数量要有强感知，平台需要增加显示入口，类似账户余额之类的窗口。
　　关于解决方案的细节，暂不啰嗦，简单介绍结果。购买主入口是企业管理中心的增值业务货架，次级入口是中心横幅广告，三级入口是职位管理界面【置顶服务】按钮，不设计购物车，交易记录纳入账户管理中一个二级子模块，售价采用单次使用定价，支付接口沿用自建，在交易数据上做特殊处理和业务集群其他交易做区分。
　　解决完第一个需求，突然冒出一个隐形需求。少部分企业反应招聘效果不佳，大部分企业反应招聘好，企业客户是否需要评估在招聘平台的投入产出比，即招聘效果数据报告。
　　输出需求5：招聘效果数据报告
　　和业务部门商量后，联合客服团队发起一轮用户抽样调研，调研的主旨是招聘效果报告对企业而言是否有吸引力（付费购买的乐意程度）。
　　调研细节不一一赘述，抽样方法简单描述如下，调研小组从数十万企业客户中按照＂会员/非会员＂、＂所属行业＂、＂企业规模＂、＂所在地区＂、＂网络招聘支出成本高低＂、＂在招职位数量＂等维度进行归纳整合，并从中抽样1000家展开为期2天的用户调研访谈。
　　调研结果出乎意料，客户对招聘效果报告、薪酬报告需求旺盛，付费意愿强烈。
　　招聘效果报告需要采集的数据维度根据企业客户需求的本质来判断，单个职位的投入产出比、哪些职位的受欢迎度高不需要额外增加＂置顶服务＂、哪些职位与同行友商相比竞争力如何等等。一定是根据客户的需求来推断，报告被使用的目的和意义。获知了需要采集的数据类别后，查询系统的数据库数据存量现状是否能够满足需要，如果不能，查找需要补充的数据源，在平台上设置采集入口，同时根据采集进度来实时调整入口的流量分配，保证在一定时间内，数据源采集充分。
　　说到这里，你们大概就能明白，一个招聘平台最宝贵的财富是什么了吧？信息【数据】。数据来源是B【招聘企业】和C【求职者】，经过我们的加工和萃取，然后把整合后的数据向应用对象进行分发，收费变现。＂取之于民，用之于民＂大抵就是这样了吧（偷笑）！
　　剧情走到这里，就快到领盒饭的阶段了。每次产品迭代都会先定一个迭代主题，围绕主题来规划版本需求，不是靠产品经理随便拍板就做这个做那个，没有章法没有套路是不行滴。这次版本v3.4除了解决以上描述的5个需求还穿插了上个版本遗留的Bug和一些零碎的小功能优化，总体拼凑成一个完整的版本进行上线发布。测试、验收、事件埋点跟踪、数据监控等这些常规流程就省去了，更多是分享此次迭代如何评估需求、拆分需求、根据需求提出解决方案的思考过程，仅供参考，欢迎指教。
　　补充一个被问得最多的问题回答：如何定义一个优秀的产品经理？
　　借用一句话简述，能够在宏观环境和微观场景里持续输出高质量决策的产品人员就是优秀的产品经理。