如何把控产品—产品管理全流程解析

    最近发生了一些事情，促使自己静下心对这些年的工作沉淀和知识积累做系统性的总结与分享。主要是希望通过总结，加深自己对产品把控认知上的理解，强化各个环节中的具体细节，并且通过分享让更多人来检验和审查自己设计产品的方式，进一步发现自己能力上的不足与思想体系上的漏洞，进一步提升自己的能力。

    这篇文章首先总结的是自己对产品设计流程，以及流程中各个环节的认知，在以后的文章中，还会逐一对各个环节中的细节深入总结，从而达到系统性梳理自己认知体系的目的。

    一、需求调研：

    通过面对面访谈，收集需求卡片等方式，对某类或者某行业的用户，进行密集的调研，收集并总结他们在工作或者日常生活中所遇见的一些问题或是建议，找出其中共性的部分，将其总结为某种需求，最终选定其中一个作为核心问题，而解决这个核心问题的功能，将会是日后产品生存的根基。

    二、产品立项与研发

    依据用户的核心需求，提出产品设想，并做好相应的市场调查与可行性分析。在通过决策层评审后，将设想细化成产品原型，提交到UED与研发部门，制作出相应的产品并投放市场。

    三、产品市场化：

    商务部门依据产品设定的目标用户群体，对产品进行包装和宣传，在完成销售任务的同时，与产品经理一起积极收集用户反馈意见，协助产品经理校正与迭代产品，保持产品与市场的同步。

    其中产品设计与研发，又可以细分为五个阶段：

    1、产品立项：主要包括商业需求文档（BRD），市场需求文档（MRD）以及产品需求文档（PRD）的制作，通过BRD获得资源支持，MRD验证产品设想，PRD提交产品模型，确保产品方案的可行性和可操作性。

    2、产品研发：包括用户体验的设计以及具体的功能实现。

    3、产品测试：通过一些的测试，确保产品的质量，及时发现产品的BUG，加速产品的迭代。

    4、产品上线：在产品通过上线评审后，通告与协调相关部门完成产品的上线工作。

    5、产品运营：协助产品经理输出相关的产品文档，以及和产品经理一起策划相关的营销活动。

    有人曾经问过我，为什么这样来划分整个流程，好处与坏处是什么？

    其实工程学上来说，这种模式属于典型的“瀑布模型”：

    好处在于：

    1、各阶段划分的非常清楚，进入下一阶段后不会被上一阶段的事情所负累。

    2、很适合利用此流转对产品进行增量的迭代；

    坏处在于：

    1、需求变动频繁的话会很痛苦；

    2、各阶段之间属于串行连接，版本跨度控制不好的话，会经常出现UED忙的要死的时候，研发很闲，研发忙的要死的时候，UED很闲的情况，团队利用率不高；

    3、最严重的是要是立项没立好，或者立错了方向，基本死翘翘。

    因为自己做产品做的比较多，需求一般自己把控，而且大多要求快速迭代，所以个人觉得这种研发模型，非常适合互联网产品的开发，这些年来自己一直都是使用这样的套路在研发产品，倒也用的顺手，对比以前在FounderRd的时，公司用的CMM3标准，个人最大的感受就是：敏捷。

    所以如果把控的项目，需求不由自己把控，而且质量要求很高的话（比如银行或者电信类产品），相信上述流转将不适合您现在的产品或项目。