近期负责的一个卡券功能，即我们通常所说的代金券功能已在网站上线并投入使用。这部分工作算是暂且告一段落，也差不多可以就此做一个阶段性的总结。

通常，一个产品（或功能模块）从需求到上线需要经过：

1. 认识产品
2. 分析产品
3. 交互原型
4. 界面设计
5. 技术开发
6. 测试
7. 上线
8. 反馈

这些流程。然后，我们在执行这些流程的过程中，会有各种大坑小坑，可能填完了一个坑又挖了另一个坑。为了下次挖的坑能够少一点小一点，我们需要不断的自我总结提高。

需求的收集&分析

需求的收集&分析，算是产品开始的一个七点，通常吹牛逼的往大了说我觉得就是日常所说的发现用户的痛点，解决用户的某个问题。但真相是：我们所谓的需求收集&分析，实际上是来源于领导或者其他部门的要求，更常见的是往往已经有了明确的目的，而我们所需要做的就是去想办法实现它。本质上，领导或其他部门的要求就是我们这种初级产品汪的需求来源。在这一阶段，我们所要做的就是了解我们要做什么，目的是什么。

最初，从运营部门接到了这个代金券功能的要求，之所以要做这个功能，主要有 2 个原因：

1. 对比其他同类平台，我们网站欠缺该功能；
2. 网站的线上运营手段缺乏功能支撑，做这个功能可以增加运营手段，以此提高相关的业绩。

可以说，最初的需求已经确定，增加代金券功能，作为一种线上营销工具，为运营部开展线上推广提供支撑。在这一阶段，基本没有遇到太大的问题。

分析产品

分析产品是在明确了我们要做什么后，为自己接下去工作的开展所做的一系列准备工作，这一阶段，最常见的就是竞品分析（突然想到孔乙己说的，读书人不叫偷，叫拿）。除此之外，还有流程的逻辑梳理，利用思维导图、流程图等工具将我们接下去打算做的事情形成一个体系，有一个最基本的架构。这一阶段的工作，算是初期的一个重点。

在做代金券功能的时候，有调查了很多其他同类平台，尤其是行内领先的平台，对于前端平台用户的操作使用逻辑倒是较快的梳理了出来，因为这一阶段，竞品分析并不会有较大的难度，只要注册其他平台，就可以从一个正常用户的角度去知道别的平台如何做的，基本上算是大同小异。

比较困难的在于网站后台对于代金券的创建管理，以及公司内部如何进行代金券的创建-操作-审核的流程等。之所以这部分难度较大，有如下几个原因：

1. 对于其他平台的操作后台，我们很难有渠道可以进行参考分析。

实际上，对于做后台的产品经理，能够做竞品分析的很少，通常体验竞品的难度更大。因此，我通过其他途径，例如淘宝、微博、微信公众平台的卡券功能出发，获得一定的参考。但总体而言，这部分依然差的比较多。因此在后续原型的设计当中，也就遇到了较多的问题。

2. 流程方面的问题。

这方面主要（1）代金券的不同创建方式及流程;（2）内部审核流程。其中，内部的审核流程算是比较艰难。主要在于后台卡券的创建及投放流程。这个流程的推演只是个人的假想，是从我自己的经验知识角度出发。功能实现后，发现这个流程虽然能用，但并不是一个顺畅的流程。

总之，从代金券功能来说，可以分为用户端及管理后台两个端口，而这个功能的难点及绝大部分工作也基本集中在管理后台。而对后台的流程梳理上工作做得不充分， 虽然通常说做后台的产品经理更重要的在于弄清业务逻辑。但实际上，绝大多数的业务逻辑也并不清晰，而且受限于职位角色，有些业务逻辑也不是产品经理容易理解的。不过，这阶段我所犯的一个最大错误在于，没有对从运营部接收到的所有需求逻辑进行更深次的衡量及分析。其中，最明显的一点在于代金券的规则投放方式 ——即在后台配置一系列规则条件，当用户的行为触发这个条件后，即可获得一张代金券。而当时提出的规则是尽可能的要满足所有可以想到的场景，方便以后的拓展，因此我对这一部分的构想是通过罗列十几种单独条件由运营人员进行各种组合排列，来形成不同的规则。然而实际上调查其他平台，常规的规则也就基本只有两三个，基本没有其他特殊的规则条件出现。而现在想来，我当时如此做，原因在于对从运营接收到的这个需求没有经过更深次的思考其是否确实会存在这种使用场景，以及竞品的调查做得不够充分，没有及时的发现通常使用的常规规则只有两三个，只要将其常态化即可。不过，技术在实现的过程中，认为这个实现难度非常大，最终是采用了将常规规则常态化的方案。

交互原型

再将所要做的功能模块梳理清楚后，通常要做的就是画原型。感觉目前在初级产品经理的工作中，原型设计占得比重较大。实际上，就我个人在工作中而言，通常是画原型的过程中再去进行思维导图的梳理，可能是因为觉得有逐渐成型的东西，才会再去考虑到更多的细节。

原型通常有低保真、高保真的说法，通常原型的输出是为了能够更好地进行沟通交流，交付技术、设计等相关人员进行开发。如果是较小的需求等，原型的输出通常都比较快速。但在一些大的功能模块，或者新的产品规划，原型的输出需要耗费大量的时间。并且，如果有变动，改动起来也非常麻烦。

通常，比较好的做法是：以最小可能原型先简单的输出一个框架，然而邀请相关的人员进行初步的评审，快速的沟通想法见解，然后再进行更改；直到初步确认后，在开始输出高保真原型。不过，我自己在实际工作中，画原型可能会有点强迫症，或者说这是大部分初级产品的通病，总是纠结在画原型无关紧要的细节中，比如按钮的摆放，tab 的排列样式，导航样式或者某个小的功能的展现形式等，实际上这些并不重要。

快速的将产品框架通过原型进行输出，然后邀请相关的人员进行初步评审，才是我们在交互原型中所该做的。当一切沟通得差不多后，在根据实际的需要去输出原型的细节。

我觉得，一个产品经理是否成长，需要看他对工具的使用上，如果能够尽可能快速的输出交互原型，没必要去死抠原型的细节。真正的界面设计等是需要依靠 UI 等去实现的，产品经理最核心的工作还是该聚焦在产品规划的是否合理，如果一个产品的逻辑等没有思考清楚，原型画的再好看也只是个空壳。另外，当原型输出后，通常会在输出产品需求文档(PRD)，如果专业一点的，应该都是用 word 等形式输出，但目前，我们都是直接在原型上直接进行相应的需求说明。这方面，老实说，真正的产品需求文档，还真是不专业。。。心塞。。。

讲到这里，我觉得需求评审可以重点说一下。实际上，产品经理只是一个产品的规划设计者，并不是最终的使用者。对于后台产品的开发，基本上是为公司内部的其他部门人员开发的。比如，这次的代金券功能，最终的交付对象是运营部。因为所处的角色不同，产品经理很容易在设计产品的过程中脱离实际的使用情况，但由于使用者在产品为上线使用时，通常也不清楚自己真正需要使用的是什么。因此，在需求评审的过程中，实际上经常会出现的就是，产品经理在进行需求讲述的时候，运营人员也不觉得有问题。这个时候，所有的相关人员都觉得是合理的。我想，这其中有个很重要的原因在于，当我们在进行讲述的时候，听的人很容跟随着你的思路进行思考，也就是需求评审时，思维逐渐同步了，因此有很多问题，实际上在需求评审中也很难发现。我觉得要减少这种情况的出现，让需求评审帮助产品经理发现更多的问题，有这么几种方法：

1. 在需求评审前，让相关人员，尤其是产品完成后的一线使用者先熟悉你的原型。最好的办法是，产品经理单独跟一线使用者进行沟通，由他详细的讲解跟使用者。
2. 模拟使用者日常的一些操作流程，或者更多的观察一线使用者实际工作中的情况。实际上，后台的相关产品是日常操作流程的程序化。
3. 产品的快速迭代开发，一个新的产品功能规划时，事实上的情况是使用者提出了很多的要求，可以说把他们能想到的都说出来了。而实际上，核心的只有几项。而且，在产品没有上线投入使用前，很多要求实际上都只是一种假想状态。因此，很重要的一点，我们在接收到很多的要求时，实际上应该把所有可剔除的东西都剔除，只保留最核心的东西。快速进行开发输出，只有在使用后，很多问题我们才能够发现。这大概也是互联网推崇敏捷开发的一个重要原因。要知道没有经过实践检验的产品，很多假想可能只是我们想得太多。而真正重要的一些东西，却没有提出来。

这次的代金券功能，有一个指定投放的需求，罗列了很多的筛选条件来筛选符合条件的用户。但在功能上线后，发现这个功能更多的是需要一个导入名单的功能。而这个功能在开发时浪费了很多的时间，但上线后，我觉得并没有达到当初设计的目的。因此，我觉得在产品的技术开发过程中，如果有的功能技术实现起来很复杂，那么需要认真的思考沟通，这个功能到底有无其意义。

最后，在原型设计时，通常随着沟通及技术开发过程中，我们通常会发现很多问题，从而需要对原型进行修改。比较好的方式是又进行的任何修改等都需要有相应的版本记录，改动记录，以便可以进行追溯。不过与相关人员进行沟通后，例如和技术沟通后，有些功能实现需要修改，却没有对原型进行相应的调整修改，这会导致后期遇到一些问题没办法追根溯源。而且，我们很容易忘记当时沟通的内容，事后再查看时需要花费很多的经历，甚至回想不起来。这个问题，目前我在实际的工作中，做的并不是很好。

界面设计

界面设计就是 UI 设计稿的输出，主要是设计的工作。这方面我一般接触的较少，不做太多详述。

有的时候，产品经理需要对界面设计的风格例如主色调、布局等提出自己的一些要求~（这个老实说，我这方面挺差的）；还有一点就是在界面设计完成后，要检查是否所有需要的元素都体现出来，设计师是否有遗漏。因为，实际上，你的原型设计出来后，一般技术也是不看的~通常是看 UI 进行开发的~相信我，这是真相。

另外，因为不同的设计方式，尤其是交互方式，对前端开发的影响非常大，所以如果是针对用户的产品，对于 UI 设计出来后，进行检查是很有必要的~起码，你要保证，重要的元素没有遗漏。不然，等技术实现了，你要再改，技术 GG 会想拿刀捅你的。

技术开发

技术开发阶段，这方面产品的工作相对较少。

这一阶段，主要是技术在开发过程中遇到问题，产品经理需要一起沟通解决，针对一些技术实现难度大或不合理的地方，需要去想办法解决。另外，我觉得这阶段重要的一点是，需要定期的和技术进行沟通。因为在技术开发过程中，通常也是阶段或者一个模块一个模块的完成的，所以每完成一个模块，产品经理有必要去对完成的模块进行测试检查。

这阶段，如果能够尽早的发现问题，改动的成本是最小的。在技术开发阶段，不闻不问的产品经理实在是不太好。对，说的就是我~自我反省 ing……

之所以这一点要重视，是因为技术在实现的过程中，一些看似不起眼的改动可能是需要进行大的框架改动的，甚至代码需要重构。因此，在产品的规划设计之时，框架一定要确保尽可能的无误，并且要跟技术沟通，尽可能的为后续的一些想要实现的功能留有余地。虽然不可能完全避免，但总归是可以减少很多无用工作。尽可能的定期与技术沟通，并且对开发完成的功能模块进行测试检查。及早的发现问题

测试

测试阶段，一般主要是发现产品开的一些 bug。虽然主要是由专门的测试人员负责，但产品经理也需要参与测试，主要是去发现功能上的一些问题。比如是否有功能缺失，是否有重大的 bug。一些测试发现的问题，也需要产品经理去决定怎么处理，是需要立即处理，还是可以暂时忽略。另外，因为整个功能是由产品经理进行规划设计的，所以实际上，产品经理参与测试，才能够判断产品的实现是否有按照当初的规划进行。

这次的代金券功能的测试，仔细回忆了下，我并没有比较好的进行。所以，后面发现，没有自己走一遍功能，有些地方的实现，测试也很容易忽略~

不过，虽然有测试，但要知道，测试只是减少 bug 的产生，有很多东西也是测试阶段不能发现的。

上线

产品在经过了上面的一系列过程之后，就需要上线进行使用了。上线通常会有一个内测阶段，例如几个人进行小范围测试，或者邀请一些用户参与内测。上线前，通常产品经理需要做一些准备工作，包括对相关人员的培训，针对相关人员输出操作说明等。我觉得上线前的试用期最好是能够长一点，因为这期间能够发现很多的问题，需要快速的迭代改进，才能够拿出一个差不多的版本。

在这次的代金券功能上线后，我发现了挺多问题。由于身份角色的不同，产品经理并不是最终的使用者，再设计产品时，考虑的角度都是完美情况，但实际的使用中，基本不存在这种完美情况。因为你是产品的设计者，所以你觉得整个使用过程很简单， 没有觉得有什么不能理解的地方。但 too young too naive，事实上，当真正的使用者在使用的时候，一定会喷死你的。“这什么鬼啊”、“怎么是这样的啊”、“产品经理这个傻逼”……表示到现在我还记忆深刻。

由于这次正式上线的时间很紧迫，在交付使用时，发现了很多问题。例如在创建代金券的时候， 有一个使用条件字段，我在规划的时候，使用条件有一个专门的样式，所以没发现什么问题。但实际上，运营在填写这个字段时，输入的内容跟设想的差不多少。所以我被吐槽了~更坑的可能就是指定投放做的是内部的条件筛选机制，而实际上运营是从外部导入名单的，因此他们就一个用户名一个用户名的搜索，然后去投放。 我想，那个时候他们一定是崩溃的。但老实说，在最初的规划设计时，真的没人提过这个外部导入功能啊。。。而且，由于时间紧迫，外部导入功能也并不能马上加入。

所以，我觉得，产品在正式的上线时，先投入使用一定的使用周期；发现问题后，能够预留一段时间进行。如此反复几次，在进行最终的上线， 是比较好的方式。预留较长的一段时间，进行反复的测试迭代，在进行最终上线当然，这也印证了我前面说的，只有当产品上线后，实际使用才能发现产品设计的很多不足，很大程度上这是受限于你的身份角色，毕竟实际的工作流程你并不是真正的熟悉，所设计的会有很大出入，而使用者也很难表述自己真正需要的是什么，所以快速的先做出一个最小的可用产品投入使用，不要考虑太多的复杂细节和功能。只有在使用过程中，才能发现真正的问题。

反馈

反馈阶段就是产品在使用过程中，不断地寻找发现不足，包括一些测试时没有发现的 bug，没有考虑到的功能，一些功能的设计问题等。这些都需要在使用过程中，不断地收集。可以说反馈就是迭代的主要需求来源。

结语

做产品需要不断的审视自己，不断地反思总结。产品的设计事实上不存在完美的使用情况，你所设想的只是你自己认为的一种理想环境，这种理想环境通常都是不存在的。

链接: https://fly63.com/article/detial/9594