《{产品管理产品规划}产品经理的第三项修炼如何进行需求管理中企开源》由会员分享，可在线阅读，更多相关《{产品管理产品规划}产品经理的第三项修炼如何进行需求管理中企开源（14页珍藏版）》请在金锄头文库上搜索。
1、产品经理的第三项修炼 -如何进行需求管理？,2008-12 华南研发中心产品策划部,需求是一切产品管理工作的基础，对于这点，大家的意见是一致的，但是说到如何对需求进行有效的管理，我想很多人就很困惑了。 在本篇文章里，我们重点介绍产品经理如何对需求进行管理，在进入正题之前，先来说几个产品经理在进行需求管理时存在的问题。,需求是一切产品管理工作的基础.,问题一：完全不进行管理 这个问题的最直接的表现就是没有一个标准的工具对需求进行管理，做到哪里，记到哪里，随意性很强，看起来也是在对需求进行管理，但实际上其实并没有进行管理。 问题二：分割的进行管理 这个问题的最直接表现就是不能连贯的来进行需求的管理
2、，产品经理的眼光只放在一个一个独立的版本上，而不能把这些版本的需求用整体的思路来管理起来。 问题三：不完整的进行需求管理 这个问题的最直接表现就是对要管理的需求理解不够全面，自身就把许多市场需求给剔除掉了，当然，要弥补这个问题，还是要对一些产品管理的基本概念有所了解才好。 以上三个问题概括来说，其实分别涉及到就是“需求管理的方法、需求管理的思路、需求管理的概念”。 对于需求管理的概念，本文就不进行说明了，因此，在这里重点说一下前两个问题：需求管理的思路；需求管理的方法。,需求管理存在的问题,1、需求管理的思路 产品管理工作的每一件具体事情，思路是第一位的，有了好的思路，做任何事情都没问题。 需
3、求管理应该说是产品经理要执行的第一个，也是最重要的具体工作了，有一个良好的思路是做好需求管理的关键，而做好需求管理则是做好接下来工作的关键。 那么，做需求管理应该有什么样的思路呢？有两点需要把握： 1）始于需求，终于需求。 大家知道，产品管理的一切工作都是在围绕需求做文章，但是在需求满足，产品却逐步消亡后，它的最终归宿又是什么呢？产品消亡后的最终归宿依然是需求，就如同种子发芽、生长、成熟、衰亡，直到融入到大地中，成为培养新生命的养料。,1、需求管理的思路,2）对市场需求的管理需要遵循“一致、回溯、编号”的方法。 一致就是要求产品管理者在进行产品管理的具体工作时，无论产品出现什么问题，都可以找到
4、原始的需求数据来进行支持。 回溯就是要求在完成了需求转变为产品的过程后，要对原始需求数据进行回溯评估，重新定义需求矩阵。 编号就是要求在产品管理工作中，要对所有的需求进行编号，编号的原则是按照类别来进行，这样，在任何时候，任何文档中，出现的都是唯一的编号，而不是模棱两可的文字描述，这样可以让需求具有唯一性，并通过编号中包含的信息来判断需求的特征，就如同身份证号一样。,1、需求管理的思路续,2、需求管理的方法 工欲善其事，必先利其器。 要想把需求管理做好，肯定得有一个合适的管理方法才行，其实作为产品经理个人来说，这个方法并不难找，或者说，如果你有了一个好的产品管理思路，那么就能自己创建出一个适合
5、自己使用的需求管理工具来。 刚才说到了，既然产品管理是始于需求，终于需求的，那么，每一个需求就如同一个生命一样，有生有灭，在这个由生到灭的过程中，我们应该如何来管理呢？其实很简单，通过需求矩阵表来进行管理。 这种表的作用，就是对每一个需求进行记录并进行跟踪，直到这个需求的消亡。 这里强调的一点是，需求没有“有用”和“无用”之分，而只有“现在有用”和“将来有用”之分，因此，在这张表中，一定是要对所有的需求进行记录，并且也不仅仅限于某个具体版本的产品，而是要长期的、持续的对需求进行记录。,2、需求管理的方法,这也正是为什么，在制定具体的产品计划之前，我们一再强调要做需求工作的原因。 因此可以看出，
6、这里的需求工作不是针对某个具体版本的产品的，而是一种“长期的、持续的”工作，而我们通常理解的需求管理工作只是这个长期过程中的某个阶段的具体工作而已，两者要区分清楚才行。 在这个工作中，有些需求的变化是比较频繁的，例如功能性的需求，而有些需求则是比较固定的，例如外观性的需求，因此，作为产品管理者，要对这些需求有足够的认识和强有力的把握才行。 接下来，就重点讲一下，如何创建自己的需求管理工具需求矩阵表。 在这个表中，至少应该有四大类的信息来对某个需求的由生而亡的过程进行记录，但必须存在的应该有三类：,2、需求管理的方法续1,1）需求的原始信息 这类信息应该包含如下项： 需求编号：这里的编号不是简单
7、的ID，而是有一定属性的ID，例如MRXXX,意义就是“市场需求（MR）的第几个需求”，并且要再次提醒一下，这个编号不是说仅仅在这个表里出现，而是要贯穿于这个产品的全部过程里，例如，在写市场需求文档（MRD）的时候，一旦涉及到表中的某个需求，严格的要求是，必须用该需求的编号来进行说明，而不像现在有些公司用文字描述来进行。 记住，对于需求的描述只存在于这个表中，以后凡是涉及到需求溯源的，肯定是用需求编号来表述的。 这样有两个明显的好处：第一是容易管理，不会出错；第二是能够在长期的产品管理工作中实现需求表述的一致，因为，谁也不能保证每次用语言描述需求就和上一次是一样的，尤其是像产品管理这种涉及环节
8、、流程和部门比较多的工作，如果需求描述的前后有偏差，肯定会对产品造成一定的影响。,2、需求管理的方法续2,需求说明：用简单易懂的语言来记录反馈上来的需求，建议是在得到反馈的第一时间就进行记录。 记住，需求说明不用做太多的加工，不要用写产品需求文档（PRD）的语言进行记录，这里的需求要的就是最原始的信息。 需求类别：就是要说明这个需求是属于产品哪一个方面的，是针对产品功能的，还是针对产品市场的，还是针对产品价格的，或者是针对产品UI的。 记住，通过良好的对需求进行分类，在经过一段时间的工作后，能让你对产品的问题和优势看得更加透彻。 需求来源：就是要说明这个需求是由谁反馈上来的，是客户，是销售，是
9、高层还是产品团队的成员。 记住，有了明确的需求来源，在你做市场调研的时候，就知道在样本获取上，有哪些优势，有哪些不足。,2、需求管理的方法续3,2）需求的过程信息 这类信息应该包含如下项： 需求是否可实现：这就是要求产品经理在评估一个需求的时候，知道从哪几个方面来评估这个需求“能不能做”，并且要把结果记录到这个表中。 在这个项中，具体包含三个指标： 是否具有难度 是否具有可行性 是否具有风险 需求是否符合年度产品规划目标：这就是要求产品经理在评估一个需求的时候，知道从哪几个方面来评估这个需求“不应该做”，并且同样要把结果记录到这个表中。 在这个项中，具体包含四个指标： 是否有助于改善产品功能
10、是否有助于改善产品性能 是否有助于增加用户满意度 是否有助于增加产品竞争力,2、需求管理的方法续4,3）处理信息 这类信息应该包含如下项： 是否实现：就是说在经过了上面的评估筛选过程后，这个反馈上来的需求最终的结果是什么，是要去实现，还是暂时不去实现。 优先级：就是说如果要去实现的话，这个需求的优先级是什么，通常用“L（ow）”、“H（igh）”来表示就可以了，如果公司有具体的要求，可以根据实际情况来定。 产品需求文档（PRD）ID：这个需要重点说明一下，这里就是记录PRD中的某个产品需求是哪个原始需求而来的，我们知道，只要是要做的需求，最终都会以产品需求的形式表现出来，这样，就需要在矩阵表中
11、有一个记录。 例如，在PRD中有一个产品需求是要求“支持现在流行的视频媒体的播放，具体包括MPEG1、MPEG2、MPEG4、RM、RMVB、WMV、MOV以及FLV等”，这个PR在文档中的编号是PRD10，那么，在这个项中就要和原始的需求对应起来，例如该PR的来源是一个编号为MR3的需求，这个需求的内容是“用户要求能够播放VCD、DVD和网上的媒体格式”。,2、需求管理的方法续5,未实现原因：这个就很简单了，是针对“是否实现”来进行说明的，要说清楚为什么这个需求没有实现，是技术原因、风险太大还是暂时不符合公司计划。 4）变更信息 准确的说，这类信息不属于顺序流程的信息，而应该属于随机信息，因
12、为，从理论上来说，谁都不希望在产品过程中出现太多的需求变更的情况，但是现实的情况是这种可能性几乎没有，或者说，需求出现变更才是正常的。 因此，如果某个需求发生了变更，也要在需求矩阵表中进行记录，这样在某个产品结束后，才知道哪个需求发生过变化，是如何进行处理的。 在这类信息中，应该包括如下项： 是否出现变更：说明“是”还是“否”就可以了。 变更基线：对于变更基线是什么，简单的说，就是要说明这个需求是属于什么性质的变更。 变更记录：就是要记录这个需求如何进行了变更，变更的结果是什么。,2、需求管理的方法续6,以上四点就是产品经理在做产品需求管理时，应该具有的思路和工具，其实思路很简单，也没必要花很
13、多时间去说明，关键还是在个人理解上，而大家似乎对工具都比较感兴趣，就多说了一些。 从那个需求矩阵表中，可以很清晰得看出一个需求的走向：先获得原始的需求，然后经过筛选，得出要用的需求，然后进入到PRD中，形成产品需求供相关部门使用，如果发生了变更，也会有所记录。 就有点像人和档案一样，人发生什么变化，档案中都会有相应的记载，在要调查某个人的时候，无需找到具体的人，只要调出相应的档案一看便知。 其实说到需求管理，以上只是提到部分知识而已，在整个管理过程中，可不是简单的完善一下这个表格就可以了，许多具体的工作，例如如何进行需求的筛选，如何控制需求变更，如何进行需求的回溯，都是要花独立的篇章来讲的，因为不是本文的重点，在此就不介绍了。,2、需求管理的方法续7,谢谢！,
