产品经理如何做好需求版本控制

　　刚入行的产品经理，往往一提到任何功能，任何需求，立马啪啪的打开电脑，看我给你把原型画出来了，牛逼吧？
　　做了一阵子产品经理之后，一提到任何东西，任何需求，立马用思维导图给你整出一大篇的功能列表，多的电脑屏幕都显示不下了；接着搞出一个看似精美比较保真的原型图，几十上百页的PRD文档，然后扔给RD，就按这个开发吧，这个就是我们产品的1.0版本（RD同学估计此时心中一万只草泥马奔过…）。
　　上面讲到的两个例子，是我在近年来工作中遇到大多数产品经理做事的方法。
　　这里讲的产品经理是指哪些入门1-3年左右的初级PM，大牛们看到这里就可以飘过了。
　　为什么标题要写＂产品经理如何做好需求版本控制＂呢？
　　就拿刚才的例子来说：前一个产品经理只重视了需求的实现，而忽视了去审视需求，调研需求，需求规划等等环节；后一个产品经理想到了需求与需求之间的关联性、扩展性，但是忽略了需求的无限性，这其中都忽视了如何去控制需求。
　　什么是需求的无限性呢？那就是任何一个小需求，如果你顺着边儿去想就能够发散出几十甚至几百个跟这个需求相关的小点。而如果产品经理不去做相关的需求调研，了解需求五层结构中最底层的核心目标是什么，哗啦哗啦全都给一次性实现出来，那么注定这个事情对团队、甚至对公司都会是一个大坑。因为投入了大量的团队资源去做了非常多无用、无意义的功能，却没有对主线的核心需求产生价值。
　　那么，产品经理应该如何做好需求控制呢？以我个人的经验，我认为应该从以下几个方面着手：
　　首先：一定要明白产品要解决的核心问题。
　　作为一个产品经理，应该是自上而下的去看待需求问题。从公司做这个产品或者这个功能要达到什么目的，解决哪方面的用户需求，要实现什么样的商业目的等方面着手。弄清楚我们这次到底是要干什么的。如果这些问题没搞懂做出来的东西要么会被老板骂，要么会被同事骂；自己当老板的产品经理估计会肉痛白花出去的钱，打击创业的自信心。
　　其次：构思需求的完整解决方案，建立需求列表。
　　当你了解清楚需求背后的真实目的的时候，实现这个需求可能有很多种方法。有的需要开发进行实现，有的不需要开发进行实现，这里讲的是需要开发来实现的需求。产品经理应该和团队以及相关部门沟通，想出一套完整的解决方案。这个解决方案可能会有很多相关的功能点、功能细项。没关系，这个时候能想的都想出来，其他人其他部门提出的建议也都包含进来，形成一个需求表（Feature List），留待整个团队一起来讨论。
　　根据公司情况量体裁衣，做好需求版本规划。
　　经过前2个步骤，可能你的需求表上密密麻麻的列出了几十上百，几百上千的功能点和要解决的问题。这个时候不要着急，根据团队的情况，公司的实力、公司给予的资源，来对产品的版本进行划分。也就是说1.0做什么、1.1做什么、1.2做什么，切忌不要想着一股老的全给做了。
　　有些PM看着竞品或是对手公司做了很多领先于自己功能，一下子就急了，恨不得下一个版本当中全部赶上。实际上这样做的结果反而适得其反，一个是弄的开发团队不堪重负，做出来的东西没质量，不稳定，bug一大堆；另一个是一上线之后用户骂声一片，打击整个团队的士气，影响公司对此项目前途的看法。
　　另外，就算是产品1.0如果功能较多也可以分成几个小版本进行开发，注意把握好开发进度以及节奏。
　　曾经看到过一个故事用在此处可能有一定的启发意义：这个故事讲的是有一个人连续吃了7个包子吃饱了，于是乎大家纷纷去研究这第7个包子到底如何神奇，用的什么材料什么秘方啊。而忽视了前面6个包子的重要性。反映到互联网产品当中，那就是任何伟大或者好的产品都是一点一点积累起来的，没有捷径可走。一定要重视好版本迭代的重要性，真正做到跟用户一起小步快跑。
　　一般而言，做产品版本规划应该是根据团队情况分配的工作量适中，一个版本解决1-3个需求即可，保证整个团队能够在一周之内迭代出一个版本。这样的好处就是一月下来，一年下来，整个团队效率处于良性运转状态，并且产品体检相比较一月或者一年前也有较大的改观，用户也能感受到产品在慢慢的成长，增加对产品的信任感。
　　上线之后的版本勿随意修改
　　很多时候在某个版本上线之后，还是会出现一些问题以及用户的反馈。这个时候我建议不要在当前的版本中去修复这些问题（重大bug除外）。因为如果这样做了，肯定是会影响产品的迭代周期的。所以我建议把这些问题或者建议又放入需求列表中，下一个版本中再根据具体的情况决定改进哪些，其余的留着后面去改进，不要想着一次把所有的事情做完。
　　充分运用好运营或者市场团队
　　这2个团队往往处于一线，与用户亲密接触。他们有时候反应上来的问题非常有用，非常接地气，产品经理一定要重视好（如果有可能，我觉得其实产品以及运营部门可以合为一个部门，这个根据每个公司或者产品的情况略有不同吧）。因为这些需求可能隐藏着用户最真实的使用情况，对产品最真实的看法。但是也不要完全信任这2个部门提出的需求，原因太多了，因为有时候用户需求不等于产品需求，有时候某个需求可能包含他们对kpi的诉求…总之需要自己根据数据情况，根据一切看似假象的线索去分析这些需求。
　　以上讲的这些东西，看似简单，却是考量一个产品人功力重要的一环，也许只有在慢慢的实践中才能得其中奥妙吧。