产品管理基础知识

1. 产品版本V、R、M介绍

产品版本V、R、M介绍
产品大版本（Version）
代表公司某一产品或其系列产品，并与唯一的产品配套表对应。例如V1等。 根据市场定位或开发平台的不同，一个产品分为若干个V 级版本。每个V 级版本根据市场竞争需要、技术与成本因素等，有一个总体开发计划，按计划向市场发布若干个子版本（Release），因此V 级版本包含若干个Release版本。

特性版本（Release）
每个Release 版本包含若干个特性，可以形成一个具体的系列产品，因此，系列产品与特性版本等同。什么特性纳入一个Release 版本，需要综合考虑市场竞争、技术与成本方面的因素，系列产品也可有自己的特性版本，系列产品可以在特性版本号上用特别的字母或数字表示。

更改版本（Modification）
如果需要在已经发布的Release 版本基础上更改（新增、改变、删除）某个特性，或者对特性下的功能、性能需求进行更改（新增、改变、删除），导致产品规格或总体方案变动，就会产生更改版本（Modification），更改版本是对发布后的Release版本的更新。

 

2. 需求版本控制

为什么标题要写“产品经理如何做好需求版本控制”呢？

就拿刚才的例子来说：前一个产品经理只重视了需求的实现，而忽视了去审视需求，调研需求，需求规划等等环节；后一个产品经理想到了需求与需求之间的关联性、扩展性，但是忽略了需求的无限性，这其中都忽视了如何去控制需求。

什么是需求的无限性呢？那就是任何一个小需求，如果你顺着边儿去想就能够发散出几十甚至几百个跟这个需求相关的小点。而如果产品经理不去做相关的需求调研，了解需求五层结构中最底层的核心目标是什么，哗啦哗啦全都给一次性实现出来，那么注定这个事情对团队、甚至对公司都会是一个大坑。因为投入了大量的团队资源去做了非常多无用、无意义的功能，却没有对主线的核心需求产生价值。

那么，产品经理应该如何做好需求控制呢？以我个人的经验，我认为应该从以下几个方面着手：

首先：一定要明白产品要解决的核心问题。

作为一个产品经理，应该是自上而下的去看待需求问题。从公司做这个产品或者这个功能要达到什么目的，解决哪方面的用户需求，要实现什么样的商业目的等方面着手。弄清楚我们这次到底是要干什么的。如果这些问题没搞懂做出来的东西要么会被老板骂，要么会被同事骂；自己当老板的产品经理估计会肉痛白花出去的钱，打击创业的自信心。

其次：构思需求的完整解决方案，建立需求列表。

当你了解清楚需求背后的真实目的的时候，实现这个需求可能有很多种方法。有的需要开发进行实现，有的不需要开发进行实现，这里讲的是需要开发来实现的需求。产品经理应该和团队以及相关部门沟通，想出一套完整的解决方案。这个解决方案可能会有很多相关的功能点、功能细项。没关系，这个时候能想的都想出来，其他人其他部门提出的建议也都包含进来，形成一个需求表（Feature List），留待整个团队一起来讨论。

根据公司情况量体裁衣，做好需求版本规划。

经过前2个步骤，可能你的需求表上密密麻麻的列出了几十上百，几百上千的功能点和要解决的问题。这个时候不要着急，根据团队的情况，公司的实力、公司给予的资源，来对产品的版本进行划分。也就是说1.0做什么、1.1做什么、1.2做什么，切忌不要想着一股老的全给做了。

有些PM看着竞品或是对手公司做了很多领先于自己功能，一下子就急了，恨不得下一个版本当中全部赶上。实际上这样做的结果反而适得其反，一个是弄的开发团队不堪重负，做出来的东西没质量，不稳定，bug一大堆；另一个是一上线之后用户骂声一片，打击整个团队的士气，影响公司对此项目前途的看法。

另外，就算是产品1.0如果功能较多也可以分成几个小版本进行开发，注意把握好开发进度以及节奏。

曾经看到过一个故事用在此处可能有一定的启发意义：这个故事讲的是有一个人连续吃了7个包子吃饱了，于是乎大家纷纷去研究这第7个包子到底如何神奇，用的什么材料什么秘方啊。而忽视了前面6个包子的重要性。反映到互联网产品当中，那就是任何伟大或者好的产品都是一点一点积累起来的，没有捷径可走。一定要重视好版本迭代的重要性，真正做到跟用户一起小步快跑。

一般而言，做产品版本规划应该是根据团队情况分配的工作量适中，一个版本解决1-3个需求即可，保证整个团队能够在一周之内迭代出一个版本。这样的好处就是一月下来，一年下来，整个团队效率处于良性运转状态，并且产品体检相比较一月或者一年前也有较大的改观，用户也能感受到产品在慢慢的成长，增加对产品的信任感。

上线之后的版本勿随意修改

很多时候在某个版本上线之后，还是会出现一些问题以及用户的反馈。这个时候我建议不要在当前的版本中去修复这些问题（重大bug除外）。因为如果这样做了，肯定是会影响产品的迭代周期的。所以我建议把这些问题或者建议又放入需求列表中，下一个版本中再根据具体的情况决定改进哪些，其余的留着后面去改进，不要想着一次把所有的事情做完。

充分运用好运营或者市场团队

这2个团队往往处于一线，与用户亲密接触。他们有时候反应上来的问题非常有用，非常接地气，产品经理一定要重视好（如果有可能，我觉得其实产品以及运营部门可以合为一个部门，这个根据每个公司或者产品的情况略有不同吧）。因为这些需求可能隐藏着用户最真实的使用情况，对产品最真实的看法。但是也不要完全信任这2个部门提出的需求，原因太多了，因为有时候用户需求不等于产品需求，有时候某个需求可能包含他们对kpi的诉求…总之需要自己根据数据情况，根据一切看似假象的线索去分析这些需求。

以上讲的这些东西，看似简单，却是考量一个产品人功力重要的一环，也许只有在慢慢的实践中才能得其中奥妙吧。

 

3. 产品灰度发布步骤

很多人可能还不是非常了解灰度发布，灰度发布就是将自己的产品首先拿出来给一部分目标人群使用，通过她们的使用结果和反馈来修改产品的一些不足，做到查漏补缺，完善产品的功能，使产品的质量得到提高。这样产品尽早的与用户接触能为以后产品的正式发布打下基础。下面就拿互联网灰度发布来讲一下灰度发布的具体步骤。

第一、确定自己的目标
既然选用了灰度发布这个方法，就首先要确定自己的目标是什么，比如通过让一部门用户先使用产品，从而通过试用结果和用户的反馈来找出产品的不足，从而想办法来提升产品的品质，还有的除了这个目的之外可能还想要借此机会来推广自己的产品。

第二、选择策略
定好目标之后，就要选择策略了，要根据自己产品的规模和功能的多样性来确定互联网灰度发布试用用户的规模和发布的频率，这样才可以提高用户的参与度，全方位的试用产品，这样才能反馈出一个比较全面的结果。

第三、对用户进行筛选
然后就是要对这些用户进行筛选，用户的选择一定要具有代表性，要选择一部分的新用户和一部分的老用户来交替使用产品，还有就是选择的用户要具有敢问好问的精神，善于发现才能发现问题。选择完用户就是产品系统的部署，然后就是对用户参与的结果进行数据分析，找出产品存在的问题。

在上述步骤全都完成之后，互联网灰度发布就基本上是完成了，下面最重要的事情就是全身心的投入对产品的改进中，对产品的不足进行完善，如果产品的漏洞比较大，可以进行再一轮的灰度发布，如果只是一些小问题，那么在修改之后就可以正式的发布了。

 

4.产品定时跟踪 

对于产品的需求功能，按照流程化处理方式；项目需求提交到禅道，产品根据紧急情况进行支撑；产品可以根据其功能纳管产品功能；基于客户需求和业务需求进行产品的研发。

对于功能的实现，每天或者每2天，产品经理进行功能打包部署，测试。基于自己的操作去慢慢发现那些操作按钮不好，那个操作按钮好，进行界面和功能细节的优化。

 

5.产品常使用软件

Axure、思维导图软件MindMaster