在开始正文之前，先向朋友们说明一下，本来写东西就不是我擅长的，并且平时工作也多，人也懒，在可写可不写的时候通常就放弃了，即使写，也是想到什么写什么，没什么体系，还是最早说的：胡言乱语，大家看之，笑之即可。
      上篇写了一些我个人对需求的来源和分类的认识，朋友们反响不错，这次我就顺着上篇的主题，继续说说我个人对需求管理的想法。

      我刚到这家公司的时候，也不能说公司对产品管理没有重视，其实，高层还是挺希望在这方面有些规范的，因此，就把这个任务指派给我了，希望我能发现一些问题，并进行改善。

      我花了一个多月的时间把整个公司的产品管理情况摸了个底，也大概翻看了所有的我来之前，产品经理做的各种文档，结果发现，问题还挺严重，具体问题包括：

      1、产品部门虽然是独立的，但是内部人员几乎都是技术部调出来的，有以前做开发的 ，有做ue的，名义上是独立的部门，但实际上还是脱离不了血缘关系，因此造成了产品部在技术部面前底气不足，毕竟面对的都是以前同一个部门的领导和同事。

      2、虽然也重视规范，但是不得要领：看过他们以前做的产品文档，我归了一下类，就两种：一个产品设计文档，一个用户手册。暂且不说用户手册，就说那个产品设计文档吧，在我看来，那就是开发人员编码设计文档的概要版，文档中竟然还要产品经理去设计数据表结构，当然了，刚转过来的这些兄弟们做这个是内行了，因此，倒也做的十分专业。人虽专业，但文档太业余了，这和我以前接触过的IT公司差不多，按照一份技术开发文档做一些产品层面上的修改就认为这是PRD了。

      3、无头无尾：我开了几次交流会，问几个已经转型为产品经理的兄弟，问他们写PRD的依据是什么，有人答是“市场安排的，我只是按照市场的想法形成可开发的产品，源头应该就是市场的要求”，还有人答“是市场、技术一块讨论出来要做的东西，具体做什么，是集体认识，市场、技术都认为没问题，难道我还能说什么吗？”，后来，我只问了他们两个问题：

“这些工作，交给一个开发人员或者一个其它的人来做，是否可以完成？”
 他们答“可以，不就是写文档吗！写文档还不快！”
 然后我继续问：
 “既然这样，那公司设立产品经理干什么呢？”
  他们无语。

       这就是现状，在许多公司，先不说高层，只说其它部门的同事，好多都认为产品经理就是写文档的，大家是不是会经常被上面的人嘱咐：好好做产品设计文档！一定要写好呀！尽量写的详细些！

      我想，至少有80%的朋友被这样或者经常被这样告知。

      又是一个典型的“舍本逐末”的认识。

      好，有朋友会问我了，这和今天的主题有什么关系呢？这些我们都知道的。

      当然有关系了，刚才我提到了，写一个PRD的源是什么呢？是需求！

      我听到了朋友们在笑，你们肯定在想，“这不是废话吗，谁不知道这个呀！”，真的吗？我可以肯定的说，有超过一多半的朋友根本不知道需求管理的真正含义，或者知道但是不知如何去做。

      说这些话，或许有些过了，但是我希望我说的稍微严重一些，能够引起大家的重视，需求管理对产品经理的工作影响是非常大的，可以说，做好了需求管理，那么你的产品管理工作就成功了一半，那些什么“MRD”、“PRD”、“UG”等文档，那只不过是思想的体现形式而已，我们没有必要在形式上下太多功夫，花太多时间。

      我们经常被告知“至少要花60%的时间在文档上（好像是微软这么说过，结果被中国的IT公司引为经典）”，在我看来，这句话不够准确，这句话的的对象是特指“programmer”，而不是“product manager”，结果呢，这被当成了所有涉及到文档的员工的准则，产品经理也不能幸免于难，哈哈。

      我个人认为，这句话这样对产品经理说就对了：至少要花60%的时间在需求管理上。

      说了半天，需求管理到底是什么呢？

      很简单，只要明白了需求管理的根本目标是什么就可以了。

      需求管理的目标是：知根、知面、知广、知细。简单解释一下：

      知根：根为源，源为一切事物之本，需求也一样，需求的源是什么呢？是心理，是动机，一位老前辈告诉过我，“洞悉人之悲欢离合为做产品之根本”，含义就是只有明白人的真实心理才可知道他真正的想法是什么，有时候，我们必须承认，人会欺骗自己，连自己都骗，我们当然就不在话下了。这即为根。

       知面：面为像，像分为真像和假像，这是可以表现出来的，可以直接被我们感知的，用户告诉你“我需要这样或者那样的功能”，这就是像，也就是像，就是用户的心底期望，在上一篇文章中，说到市场会反馈给我们好多用户的需求，其实就是基于这个层面的，也就是用户的心里所想，心中所望。这即为面。            

     “知根”和“知面”这两者互为依托，前者是基础，后者是展现，因此，我在指导兄弟们做需求管理的时候，会要求他们尽量把用户动机想一想，用户反馈某个功能，他的真实动机是什么呢？他为什么会有这样那样的想法，然后尽量归成类，并记录下来，作为“文档回归”的根据。虽然这种工作不会直接对产品造成太多影响，但是这对产品经理更好的理解自己的目标用户群，理解他们的所思所想，进行一定程度上的换位思考是有好处的。

      （产品经理，多少应该学一些心理学方面的知识的。这算友情提示，不作为本篇主题。）

      知广：广为界，界是什么呢？界就是边界，也就是范围，任何事物都是有范围的，孙悟空再NB，如来佛的手掌就是他的上限，阎罗殿的地狱就是他的下限，宇宙的范围都逐渐在被人发现，既然宇宙都如此，更别说一个小小的需求了。

      因此，知广就是要求产品经理知道某个需求能够延伸的范围是什么，具体来说，就是要知道一个需求的可能性来源有多少，都是什么，我们知道，同一个需求的用户原始提法一定是千奇百怪的，因为用户对一个问题的理解是不一样的，但是通过产品经理的提炼，我们发现，其在本质上其实是一样的，这就是需求的可能性来源，只知道了可能性来源是第一步，接下来要做的就是要把这些本质的需求再升华成一个具体和形象的理解。

      其实这就是一个“获取->提炼->塑造”的过程，而需求在这个过程中也就实现了“由杂乱无章到去伪存真”的提炼。

      知细：细为知，知是什么呢？知不是知识，而是认知，我个人认为，“一个好的产品经理，不是说你知道用户有多少需求，而是你能认知到有多少有质量的和可做的需求”，数量多，只能说明你跑的勤，但是认知的多，才能说明你想的勤，产品经理不应该是一个动腿比动脑多的职位，什么是智囊，智囊就是干这个的。

      这里有两个标准：一个就是“质量”，一个就是“可做”。其实这就是在考察产品经理对需求性价比是否有一种意识，200个需求，哪个先做，哪个后做，哪个风险高，哪个风险低，哪个适合现在做，哪个适合将来做，哪个可行，哪个不可行，以及根据这些要素最终交给企业的产品策略，你都做了吗？  
      “知广”和“知细”这两者互为补充，前者是让产品经理去考虑需求的原型，后者则是让产品经理去考虑在此原型上如何操作。一个原型的建立依靠的是大量数据的积累、分析、归类、和再形象化，但是只有了原型而不去产品化，那就成了实验室了。

      我把我做需求管理的四个标准概括成“4K（konw）”原则，说了那么多，我认为那是为了凑字数，其实只要明白这四个原则的核心就可以了：

      四个原则针对需求管理，要分别解决的问题是：

      用户想了什么（think）->用户说了什么（say）->我们明白了什么（learn）->我们要做什么（do）。

      这个过程实现了从“模糊”到“清晰”，从“用户”到“产品经理”，从“用户要求”到“用户需求”，从“个人诉求”到“群体诉求”的变化，实现了一次主体的转变。

      这才是我认为的需求管理要做的工作，需求管理是一切产品管理工作的开始，什么产品策略了，市场策略了，价格策略了，这都是对基于需求管理的具体工作了，大家可以想了，如果你把你的用户摸的透透的，并且可以随时拿出任何依据来支持各种工作，你还会觉的工作没有头绪吗？

      不行了，写到这里，感觉脑袋里这点东西要被汤圆榨干了，哈哈，脑袋开始有些沉了，写不下去了，今天就到这里了，大家凑合着看，这篇文章只说到需求管理的原则和目标，没有写方法，其实在我来看，方法倒是可说可不说的了，毕竟大家的情况都不一样，方法也不能照搬，一个原则，管理的方法和工具，只要个人用的顺手，企业能够认可就可以，并且一旦提到需求管理的方法，又必然会联系到一大堆的东西，我从来没有认真整理过，就暂且搁置吧。

      如果大家有兴趣，可以回个帖子，一是对我的支持，二是给我些信心，谢谢大家！

      到不到的，大家多担待了！