从需求到上线,产品经理你挖了多少坑？.pdfVIP

从需求到上线 ，产品经理你挖了多少坑 ？ 近期负责的一个卡券功能 ，即我 通常所说的代金券功能已在网站上线并投入使用。这部分工作算 是暂且告一段落 ，也差不多可以就此做一个阶段性的总结。 通常 ，一个产品 （或功能模块 ）从需求到上线需要经过 1. 认识产品 2. 分析产品 3. 交互原型 4 . 界面设计 5. 技术开发 6. 测试 7. 上线 8. 反馈 这些流程。然后 ，我 在执行这些流程的过程中 ，会有各种大坑小坑 ，可能填完了一个坑又挖了另 一个坑。为了下次挖的坑能够少一点小一点 ，我 需要不断的自我总结提高。 需求的收集分析 需求的收集分析 ，算是产品开始的一个七点 ，通常吹牛逼的往大了说我觉得就是日常所说的发现 用户的痛点 ，解决用户的某个问题。但真相是 ：我们所谓的需求收集分析 ，实际上是来源于领导 或者其他部门的要求 ，更常见的是 已经有了明确的目的 ，而我们所需要做的就是去想办法实 现它。本质上 ，领导或其他部门的要求就是我 这种初级产品汪的需求来源。在这一阶段 ，我 所 要做的就是了解我 要做什么 ，目的是什么。 最初 ，从运营部门接到了这个代金券功能的要求 ，之所以要做这个功能 ，主要有2个原因 ： 1. 对比其他同类平台 ，我 网站欠缺该功能 2. 网站的线上运营手段缺乏功能支撑 ，做这个功能可以增加运营手段 ，以此提高相关的业绩 可以说 ，最初的需求已经确定 ，增加代金券功能 ，作为一种线上营销工具 ，为运营部开展线上推广 提供支撑。在这一阶段 ，基本没有遇到太大的问题。 分析产品 分析产品是在明确了我 要做什么后 ，为自己接下去工作的开展所做的一系列准备工作 ，这一阶段 ，最常见的就是竞品分析 （突然想到孔乙己说的 ，读书人不叫偷 ，叫拿 ）。除此之外 ，还有流程的 逻辑梳理 ，利用思维导图、流程图等工具将我 接下去打算做的事情形成一个体系 ，有一个最基本 的架构。这一阶段的工作 ，算是初期的一个重点。 在做代金券功能的时候 ，有调查了很多其他同类平台 ，尤其是行内领先的平台 ，对于前端平台用户 的操作使用逻辑倒是较快的梳理了出来 ，因为这一阶段 ，竞品分析并不会有较大的难度 ，只要注册 其他平台 ，就可以从一个正常用户的角度去知道别的平台如何做的 ，基本上算是大同小异。 比较困难的在于网站后台对于代金券的创建管理 ，以及公司内部如何进行代金券的创建-操作-审核 的流程等。之所以这部分难度较大 ，有如下几个原因 ： 1. 对于其他平台的操作后台 ，我 很难有渠道可以进行参考分析。实际上 ，对于做后台的产品经理 ，能够做竞品分析的很少 ，通常体验竞品的难度更大。因此 ，我通过其他途径 ，例如淘宝、微博、 微信公众平台的卡券功能出发 ，获得一定的参考。但总体而言 ，这部分依然差的比较多。因此在后 续原型的设计当中 ，也就遇到了较多的问题。 2. 流程方面的问题。这方面主要 （1 ）代金券的不同创建方式及流程; （2 ）内部审核流程。其中 ，内 部的审核流程算是比较艰难。主要在于后台卡券的创建及投放流程。这个流程的推演只是个人的 假想 ，是从我自己的经验知识角度出发。功能实现后 ，发现这个流程虽然能用 ，但并不是一个顺畅 的流程。 总之 ，从代金券功能来说 ，可以分为用户端及管理后台两个端口 ，而这个功能的难点及绝大部分工 作也基本集中在管理后台。而对后台的流程梳理上工作做得不充分 ，虽然通常说做后台的产品经理 更重要的在于弄清业务逻辑。但实际上 ，绝大多数的业务逻辑也并不清晰 ，而且受限于职位角色 ， 有些业务逻辑也不是产品经理容易理解的。不过 ，这阶段我所犯的一个最大错误在于 ，没有对从运 营部接收到的所有需求逻辑进行更深次的衡量及分析。其中 ，最明显的一点在于代金券的规则投放 方式——即在后台配置一系列规则条件 ，当用户的行为触发这个条件后 ，即可获得一张代金券。而 当时提出的规则是尽可能的要满足所有可以想到的场景 ，方便以后的拓展 ，因此我对这一部分的构 想是通过罗列十几种单独条件由运营人员进行各种组合排列 ，来形成不同的规则。然而实际上调查 其他平台 ，常规的规则也就基本只有两三个 ，基本没有其他特殊的规则条件出现。而现在想来 ，我 当时如此做 ，原因在于对从运营接收到的这个需求没有经过更深次的思考其是否确实会存在这种使 用场景 ，以及竞品的调查做得不够充分 ，没有及时的发现通常使用的常规规则只有两三个 ，只要将 其常态化即可。不过 ，技术在实现的过程中 ，认为这个实现难度非常大 ，最终是采用了将常规规则 常态化的方案。 交互原型 再将所要做的功