成为产品经理那天到现在，刚好一个月。期间发生了很多细碎的支线，我记录在了「2017年的出发」的第一篇中。在这里，我想梳理下的，是对于产品本身的思考，算是一些沉淀。

首先是项目周期流程，从前做游戏的时候，公司的流程在很大程度上被简化了，在闪电购，我也觉得很多东西都不够规范，但是受制于敏捷开发、快速迭代的策略，倒也无可后非。

大致上，目前实施的流程是这样：需求收集 - 需求调研／撰写方案 - 需求评审 - 交互评审 - 开发中 - 提测 - 用例评审 - 测试 - 上线。

详细说这样：1.需求收集，需求确认。需求来自于很多方面，有之前因为时机不够成熟而没有能做的优化提升，运营的反馈，用户的反馈，数据分析得到的沉淀。在收集到需求后，产品人员对于每个需求会做一些定型的大致的排列，选出重要紧急的进行需求确认，这一步很重要，怎么做是个技术活，做什么则是一种艺术。研发过程中做错了可以调整，但是做了错的事走错了方向，就只能重新来过，假如做了没用的事，那就是白花了精力和投入，在产品本身之外，交互研发测试的投入也被浪费了，这属于很严重的事故。这一切，都是由产品把关和掌舵的。关于需求确认，目前主要是三种考量因素，首先是负责的产品人员的分析的结果，其次是与需求方通常是用户进行求证，还不行可以找有经验的信得过的人帮助把关。

2.需求调研，出方案。确认了需求之后，就可以细化需求，出方案了。在细化需求这点上，一来是要落实需求的一些细节，二来是要看到需求背后对于产品真正的欠缺是什么，也就是被说腻味的那句“用户真正需要什么”。进行了需求的落实调研之后，就可以结合已经掌握到的信息，开始出方案了，方案最重要的是背景和目标，这直接影响了在出方案时产品人员脑海中的那个想要解决的问题，根本上左右了功能具体的解决方法和方法后面具体的逻辑方式。期间需要与开发和实施人员，包括客服运营进行交流，深入理解他们的要求，尽力进行配合。尤其是开发，如果一个功能在现有架构下无法被实现，那什么样天花乱坠的方案也是扯淡。这关联到与开发的交流。我们公司的一个产品说的一句话，让我觉得很赞同，“不要与开发像同事那样进行业务上的对接，要像伙伴那样商量解决办法”。在产品的整个周期中，与产品最为接近的就是开发，可以这么说，开发的能力是产品经理能力的一个延伸，是产品方案本身，是考量逻辑本身的组成部分。

3.需求评审。假如前面在方案时，与工程师们交流到位，那么这一步就会轻松很多。在这个阶段，产品和开发的组合需要与运营／客服／市场／测试／交互等等的人进行接触，目的是博采众长，对PRD方案中没有考虑到的进行一次众包式的兜底。在各个立场上，项目都没有什么问题，那么在方案和功能层面就算通过了，但是本身而言，各方都只是提出了在他们工作会接触到的部分的验证，总体上很多问题都是需要产品人员自身进行产品方案的审验，不能因为有评审就疏忽对于产品品质的把控。

目前做的最多的就是前三部分，其他的后面体会深了再做总结。

产品流程之外，产品方法论也有一些。首先是工具和PRD的书写。对于工具，目前主要用的是文本编辑工具、表格、Axure、基本的图片修改工具（主要用到的是截图、剪裁、文本输入和简单图形的添加）。在闪电购，文本工具用的是在线的Wiki，功能足够，还有不少扩展插件，由于没有太深入的研究现在还没法多说。在产品PRD书写上，我也自己总结了一套要点。首先是项目的概要，包括需求的背景，解决的问题，本期的目标，方案的逻辑示意图，目前还没用到的是用户画像，这一点我目前也还不了解，做了些询问求证但是还不能确定。其次是项目的配置，涉及到的人员、联系方式，需求方的一些资料联系方式，数据等等。第三部分是功能的细节介绍，原型和基于原型图的解释说明，这部分的说明包括了功能的入口、前置的条件、操作的方法、实现的效果以及一些需要注意的规则等的说明，我目前通常会罗列很多说明，这本身是由于前面的叙述一些要素缺失，而前面部分中缺失的要素又被全部解耦之后汇总列举。最后我会补上一些附录，包括一些说明、培训会要用到的东西、表格以及本期不能解决需要留到下期做解决的问题。在评论中，我会加入一些我本身对于这个项目的一些看法，感受总结和接下来的计划

产品方法论之外，对于产品本身也有一些思考，之前虽然知道产品需要对产品本身负责，但是对于这句话的理解还是没有透彻，现在看来，产品的目的就是保证产品的成功，与产品的成功相关的一切都与该产品的产品经理有关。

为了避免闭门造车，加深对于市场和大环境的感受，我也保持阅读一些产品相关的资讯，网站入口是从产品经理导航进入的，这个网站目前对我这样的一个从产品第一阶段走到第二阶段的人还是蛮有价值的。

这次先说到这里，主要是一些比较基础的论述，在下一部分，我想归纳下一些产品设计的思路，和在产品设计过程中会考虑的问题。