近期负责的一个卡券功能，即我们通常所说的代金券功能已在网站上线并投入使用。这部分工作算是暂且告一段落，也差不多可以此做一个阶段性的总结。
　　通常，一个产品（或功能模块）从需求到上线需要经过：
　　认识产品
　　分析产品
　　交互原型
　　界面设计
　　技术开发
　　测试
　　上线
　　反馈
　　这些流程。然后，我们在执行这些流程的过程中，会有各种大坑小坑，可能填完了一个坑又挖了另一个坑。为了下次挖的坑能够少一点小一点，我们需要不断的自我总结提高。


　　需求的收集&分析
　　需求的收集&分析，算是产品开始的一个七点，通常吹牛逼的往大了说我觉得是日常所说的发现用户的痛点，解决用户的某个问题。但真相是：我们所谓的需求收集&分析，实际上是来源于领导或者其他部门的要求，更常见的是往往已经有了明确的目的，而我们所需要做的是去想办法实现它。本质上，领导或其他部门的要求是我们这种初级产品汪的需求来源。在这一阶段，我们所要做的是了解我们要做什么，目的是什么。
　　初，从运营部门接到了这个代金券功能的要求，之所以要做这个功能，主要有 2 个原因：
　　对比其他同类平台，我们网站欠缺该功能；
　　网站的线上运营手段缺乏功能支撑，做这个功能可以增加运营手段，以此提高相关的业绩。
　　可以说，初的需求已经确定，增加代金券功能，作为一种线上营销工具，为运营部开展线上推广提供支撑。在这一阶段，基本没有遇到太大的问题。
　　分析产品
　　分析产品是在明确了我们要做什么后，为自己接下去工作的开展所做的一系列准备工作，这一阶段，常见的是竞品分析（突然想到孔乙己说的，读书人不叫偷，叫拿）。除此之外，还有流程的逻辑梳理，利用思维导图、流程图等工具将我们接下去打算做的事情形成一个体系，有一个基本的架构。这一阶段的工作，算是初期的一个重点。
　　在做代金券功能的时候，有调查了很多其他同类平台，尤其是行内的平台，对于前端平台用户的操作使用逻辑倒是较快的梳理了出来，因为这一阶段，竞品分析并不会有较大的难度，只要注册其他平台，可以从一个正常用户的角度去知道别的平台如何做的，基本上算是大同小异。
　　比较困难的在于网站后台对于代金券的创建管理，以及公司内部如何进行代金券的创建-操作-审核的流程等。之所以这部分难度较大，有如下几个原因：
　　1. 对于其他平台的操作后台，我们很难有渠道可以进行参考分析。
　　实际上，对于做后台的产品经理，能够做竞品分析的很少，通常体验竞品的难度更大。因此，我通过其他途径，例如淘宝、微博、微信公众平台的卡券功能出发，获得一定的参考。但总体而言，这部分依然差的比较多。因此在后续原型的设计当中，也遇到了较多的问题。
　　2. 流程方面的问题。
　　这方面主要（1）代金券的不同创建方式及流程;（2）内部审核流程。其中，内部的审核流程算是比较艰难。主要在于后台卡券的创建及投放流程。这个流程的推演只是个人的假想，是从我自己的经验知识角度出发。功能实现后，发现这个流程虽然能用，但并不是一个顺畅的流程。
　　总之，从代金券功能来说，可以分为用户端及管理后台两个端口，而这个功能的难点及绝大部分工作也基本集中在管理后台。而对后台的流程梳理上工作做得不充分， 虽然通常说做后台的产品经理更重要的在于弄清业务逻辑。但实际上，绝大多数的业务逻辑也并不清晰，而且受限于职位角色，有些业务逻辑也不是产品经理容易理解的。不过，这阶段我所犯的一个大错误在于，没有对从运营部接收到的所有需求逻辑进行更深次的衡量及分析。其中，明显的一点在于代金券的规则投放方式 ——即在后台配置一系列规则条件，当用户的行为触发这个条件后，即可获得一张代金券。而当时提出的规则是尽可能的要满足所有可以想到的场景，方便以后的拓展，因此我对这一部分的构想是通过罗列十几种单独条件由运营人员进行各种组合排列，来形成不同的规则。然而实际上调查其他平台，常规的规则也基本只有两三个，基本没有其他特殊的规则条件出现。而现在想来，我当时如此做，原因在于对从运营接收到的这个需求没有经过更深次的思考其是否确实会存在这种使用场景，以及竞品的调查做得不够充分，没有及时的发现通常使用的常规规则只有两三个，只要将其常态化即可。不过，技术在实现的过程中，认为这个实现难度非常大，终是采用了将常规规则常态化的方案。
　　交互原型
　　再将所要做的功能模块梳理清楚后，通常要做的是画原型。感觉目前在初级产品经理的工作中，原型设计占得比重较大。实际上，我个人在工作中而言，通常是画原型的过程中再去进行思维导图的梳理，可能是因为觉得有逐渐成型的东西，才会再去考虑到更多的细节。
　　原型通常有低保真、高保真的说法，通常原型的输出是为了能够更好地进行沟通交流，交付技术、设计等相关人员进行开发。如果是较小的需求等，原型的输出通常都比较快速。但在一些大的功能模块，或者新的产品规划，原型的输出需要耗费大量的时间。并且，如果有变动，改动起来也非常麻烦。
　　通常，比较好的做法是：以小可能原型先简单的输出一个框架，然而邀请相关的人员进行初步的评审，快速的沟通想法见解，然后再进行更改；直到初步确认后，在开始输出高保真原型。不过，我自己在实际工作中，画原型可能会有点强迫症，或者说这是大部分初级产品的通病，总是纠结在画原型无关紧要的细节中，比如按钮的摆放，tab 的排列样式，导航样式或者某个小的功能的展现形式等，实际上这些并不重要。
　　快速的将产品框架通过原型进行输出，然后邀请相关的人员进行初步评审，才是我们在交互原型中所该做的。当一切沟通得差不多后，在根据实际的需要去输出原型的细节。
　　我觉得，一个产品经理是否成长，需要看他对工具的使用上，如果能够尽可能快速的输出交互原型，没必要去死抠原型的细节。真正的界面设计等是需要依靠 UI 等去实现的，产品经理核心的工作还是该聚焦在产品规划的是否合理，如果一个产品的逻辑等没有思考清楚，原型画的再好看也只是个空壳。另外，当原型输出后，通常会在输出产品需求文档(PRD)，如果专业一点的，应该都是用 word 等形式输出，但目前，我们都是直接在原型上直接进行相应的需求说明。这方面，老实说，真正的产品需求文档，还真是不专业。。。心塞。。。
　　讲到这里，我觉得需求评审可以重点说一下。实际上，产品经理只是一个产品的规划设计者，并不是终的使用者。对于后台产品的开发，基本上是为公司内部的其他部门人员开发的。比如，这次的代金券功能，终的交付对象是运营部。因为所处的角色不同，产品经理很容易在设计产品的过程中脱离实际的使用情况，但由于使用者在产品为上线使用时，通常也不清楚自己真正需要使用的是什么。因此，在需求评审的过程中，实际上经常会出现的是，产品经理在进行需求讲述的时候，运营人员也不觉得有问题。这个时候，所有的相关人员都觉得是合理的。我想，这其中有个很重要的原因在于，当我们在进行讲述的时候，听的人很容跟随着你的思路进行思考，也是需求评审时，思维逐渐同步了，因此有很多问题，实际上在需求评审中也很难发现。我觉得要减少这种情况的出现，让需求评审帮助产品经理发现更多的问题，有这么几种方法：
　　在需求评审前，让相关人员，尤其是产品完成后的一线使用者先熟悉你的原型。好的办法是，产品经理单独跟一线使用者进行沟通，由他详细的讲解跟使用者。
　　模拟使用者日常的一些操作流程，或者更多的观察一线使用者实际工作中的情况。实际上，后台的相关产品是日常操作流程的程序化。
　　产品的快速迭代开发，一个新的产品功能规划时，事实上的情况是使用者提出了很多的要求，可以说把他们能想到的都说出来了。而实际上，核心的只有几项。而且，在产品没有上线投入使用前，很多要求实际上都只是一种假想状态。因此，很重要的一点，我们在接收到很多的要求时，实际上应该把所有可剔除的东西都剔除，只保留核心的东西。快速进行开发输出，只有在使用后，很多问题我们才能够发现。这大概也是互联网推崇敏捷开发的一个重要原因。要知道没有经过实践检验的产品，很多假想可能只是我们想得太多。而真正重要的一些东西，却没有提出来。
　　这次的代金券功能，有一个指定投放的需求，罗列了很多的筛选条件来筛选符合条件的用户。但在功能上线后，发现这个功能更多的是需要一个导入名单的功能。而这个功能在开发时浪费了很多的时间，但上线后，我觉得并没有达到当初设计的目的。因此，我觉得在产品的技术开发过程中，如果有的功能技术实现起来很复杂，那么需要认真的思考沟通，这个功能到底有无其意义。
　　后，在原型设计时，通常随着沟通及技术开发过程中，我们通常会发现很多问题，从而需要对原型进行修改。比较好的方式是又进行的任何修改等都需要有相应的版本记录，改动记录，以便可以进行追溯。不过与相关人员进行沟通后，例如和技术沟通后，有些功能实现需要修改，却没有对原型进行相应的调整修改，这会导致后期遇到一些问题没办法追根溯源。而且，我们很容易忘记当时沟通的内容，事后再查看时需要花费很多的经历，甚至回想不起来。这个问题，目前我在实际的工作中，做的并不是很好。
　　界面设计
　　界面设计是 UI 设计稿的输出，主要是设计的工作。这方面我一般接触的较少，不做太多详述。
　　有的时候，产品经理需要对界面设计的风格例如主色调、布局等提出自己的一些要求~（这个老实说，我这方面挺差的）；还有一点是在界面设计完成后，要检查是否所有需要的元素都体现出来，设计师是否有遗漏。因为，实际上，你的原型设计出来后，一般技术也是不看的~通常是看 UI 进行开发的~相信我，这是真相。
　　另外，因为不同的设计方式，尤其是交互方式，对前端开发的影响非常大，所以如果是针对用户的产品，对于 UI 设计出来后，进行检查是很有必要的~起码，你要保证，重要的元素没有遗漏。不然，等技术实现了，你要再改，技术 GG 会想拿刀捅你的。