转朋友博客的一篇新文章，讲产品经理分析需求的，有兴趣的可以多去朋友博客逛逛，帮宣传下：饭窝，http://finewo.net/
产品经理在产品设计前，最头疼的问题多是需求的满足度，该如何保障在满足当前需求的前提下还能顺应产品的未来扩展性，往往使产品经理抓耳挠腮。本文先简单介绍几种笔者常用的需求分析法，再与大家探讨下需求该如何采纳。
一、需求分析方法
1 公司级服务型产品
公司级服务型产品是指由公司发起，以大众服务为目的，用户对象为互联网大众的产品。这类产品最终的需求的定拍方为公司方，需求调研对象为大众，调研方法也很多，本文不多述，可以使用调研问卷、面对面交谈、根据历史积累订立初级需求等。
在对各种用户角色进行需求调研后，通常我们的做法是按用户的优先级排序，将各级用户的需求按用户分组整理，取各级用户的需求交集，整理进需求报告中作为第一批需求，然后按优先级高的用户需求依次放入需求报告中，最终结合设计团队前期预见的需求集形成出版的需求列表，进行讨论会，可以通过头脑风暴或delphi法，定出中版的需求列表，值得注意的是讨论会的讨论方法是非常占用人力成本，所以会议主持人要非常清晰本次会议的讨论内容，避免问题扩展太多偏离太大，导致会议迟迟不能结束。讨论出的中版需求列表后，是需要进行更高层次的会议讨论，至少要有一位产品总监或项目高管参与，用来定拍，否则所有的之前的讨论基本都是不算数的，对未来预期的风险如发生后是没有援军的。
2 客户级定制型产品
客户级定制型产品是指由客户发起，以方便客户使用解决客户某种现存问题为目的，使用对象为专有客户群体的产品。这种产品最终的需求定拍方为专有客户群体，可以是一个人或多个人，需求调研对象也为客户方，调研方法同样也有很多，如召开项目启动会，要求客户代表和产品团队代表进行需求讨论，或也可以根据历史积累做出初版原型后，使用原型法进行多轮调研得出最终定拍版原型后则为需求列表。注意，以上所说为通常情况，特殊情况则需特殊处理，比如大型产品则需要采用螺旋模型，多次螺旋后得出最终产品，小型项目则可以直接采用较敏捷方法通过原型法直接定拍，中型的可以采用瀑布等，依实际情况而论。
笔者比较喜欢召开项目启动会的方式，因为这种比较直接也是最效率的，一轮不够可以开两场，直到没有异议为止，然后做出产品原型。项目启动会的产品团队成员在条件允许的情况下，笔者通常会安排以下几种角色参与：UI、开发经理、一个高级开发工程师。为什么安排这几种角色？通常这样的产品团队，是不具备交互设计师的，UI和产品经理就担当了此角色。叫上开发经理为什么还要再叫上一个高级开发工程师？从经验上来讲，产品团队里的高级开发工程师是长期驻留在产品团队里的，对产品的开发细节很了解，方便在关键需求做出强硬判断，可以及时给用户反馈避免“浮夸风”和“冷场”的情况出现；开发经理有可能是经常流动的，虽然对公司大部分的产品很是了解，但对细节的了解程度没有高工更有深度，但产品经理对整体产品开发的框架有全局观，如一个需求需要哪些硬件资源配合等，可以很快做出大方面的技术把控，所以这两个角色是都需要的，但如果有那么一种全能的开发经理就不需多此一举了。为什么没有见到项目经理？这个问题就很奇妙了，通常来讲，这种类型的产品团队中，产品经理即项目经理，项目经理即产品经理了，呵呵！
二、需求如何满足
1 公司级服务型产品
服务型产品在确定出最终的需求列表后，产品经理可以叫上交互设计师、开发经理三个人，找间小会议室，用思维导图工具以产品为核心将产品的需求列表画出来，并标出各类需求的优先级。确立优先级的原则是以大部分用户的一般需求为主，确保最高优先级的需求为最基础的需求，即用户最需要的需求，比如你要设计一个电风扇，一级需求应该包括扇叶、电源开关，有了这两个功能就可以保障电风扇的最基本运转，二级需要可以考虑设计风速控制、外观装饰等。我们的产品也是如此，将大部分用户最需要的一般需求设立为一级需求，作为1.0版本发布，包含基础需求，一些个性化的需求或一些亮点需求可以逐步扩展，放到2.0、3.0中，这样可以很好的控制产品经理的发散思维，因为通常产品经理在产品进入到执行开发阶段时，总是会突然的冒出一些很奇怪的想法，就迫不及待的在晨会或小组会时提出，希望开发经理给加到产品功能里，在1.0时发布，有了这样的方式，产品经理可以将突发奇想的好想法放到思维导图里，标出优先级，作为2.0需求集里发布。
2 客户级定制型产品
可能做过此类项目的产品经理或项目经理都会有这样的经历，客户提出的需求较多的时候，需求比较乱，虽然最终定拍了，但结合产品的合同额度、时间、人力成本做出初版project后，才恍然发现超期了很多，这时就要祭出我们的宝剑“砍需求”了，这个“砍”就比较难了，砍大了产品不能验收，砍少了到了期限做不完还是不能验收。这时该怎么办？
保持冷静的思考是很重要的，切忌不能急躁，容易做出冲动的决定，比如冲动的去和公司提出加人，疯狂的让开发人员加班，这些都是不理智的，最理智的是多翻几遍需求列表和讨论会的会议纪要，仔细分析里面的细节，这里面的需求其实并不全是客户最需要的，在项目启动会时，客户一口气全提出来，多半都是产品经理引导的，说道一个功能时，客户就跟着顺下去了，顺着顺着就出来了更多的需求。客户也和我们一样，是可以商量的，仔细分析过这些需求后，找出一些你认为可以暂缓甚至留到后期再做的整理出来，可以单独找客户方可以定拍的代表，在一起屡一遍，只要你的理由充足，客户多半都是会同意的，如果实在不同意的可以变通一下，用另一种容易实现的方式来满足用户。
以上一些是笔者在实际运作时遇到过的一些情况和应对方法，时间比较晚了可能有些没有写清楚，后面我会整理一些具体的内容写写，像需求调研的细节和需要注意的地方，风险的预测，做计划时的一些技巧等。
原文链接：http://www.cnblogs.com/saisky/archive/2011/10/04/2198929.html
【编辑推荐】
