从产品经理角度透析需求分析

产品需求程可以形象化为“Y”，“需求分析”的过程就是经历图中的“1 –> 2 — >3”，把“用户需求”转化为“产品功能”。 yixieshi

　　需求分析的Y

　　对图做几点解释： yixieshi

　　“Y”的越上面越是解决方案，越下面越是背后的目的。“1-用户需求”，大多表现为用户的解决方案，往往是不好的，但好的“3-产品功能”一定 是从用户需求转化而来，而不是凭空想出来的。所以说，“听不听用户”都是一个意思，更准确的说法是“听用户的，但不要照着做”。同时，也不要误解“创造需 求”，你创造的只能是满足用户需求的解决方案——产品功能，而不是用户需求。

　　1–>2，通过问“Why”，逐步归纳，2–>3，通过问“How”，逐步演绎。过程中都要用到各种辅助信息，比如数据、竞品、行业等。

　　把“2-产品需求”追溯到“4-马斯洛需求”的过程是可选的，画为虚线，只是为了这个理论的完备，如果感兴趣，每个产品需求总能挖到马斯洛的层面。“2-产品需求”的点如何选择，我们到底应该挖到那个层面上，作为产品需求，取决于公司和产品的定位，下面有例子。

　　还是用那个烂大街的“买电钻”的故事吧，假设你是一位婚介所的产品经理，你能从中发现机会么?(这都哪儿跟哪儿啊……) 一些事

　　小明说，“我要买一个电钻。”这是用户需求，他自以为的解决方案。

　　这时候，如果他面对的是一个普通的销售人员，也许就把电钻卖给他了，比方说500元。但，小明遇到了一位产品经理。产品经理会问——

　　“为什么?”

　　“我想在墙上打一个洞。” 互联网的一些事

　　有的产品经理，就此停住，对小明说，那你不用买电钻，我们这里提供上门打洞服务，50元，一下子省了90%。到此，产品需求是打洞，功能就是打洞服务。如果你的公司定位就在于此，那么这样也很好。不过，有的公司并不是提供这类产品的，那么会继续问。

　　“为什么?”

　　“我挂一幅画在墙上。”

　　好了，又有一批产品经理找到了产品需求。他跟小明说，我们是个集团公司啊，也提供卖画的服务，并且买画可以包上门安装的!你看，50块也省了，并且挖掘到新的机会——对画的需求。可是，我是一婚介所的产品经理啊，只好硬着头皮继续问。

　　“为什么?”

　　“因为房间里显得太空旷了，看着不舒服。”

　　Ok，原来产品需求是家装服务啊，再How到具体的产品功能，比如加个暖色调的壁灯，铺上地毯……不过，小明皱起了眉头，感觉好像不对啊，家里装潢一下貌似还是有问题，感觉不对。

　　“为什么?”

　　“是这样的，我是一IT民工啊，忙得没时间找女朋友，晚上加班回家很晚，对着一块大白墙，感觉很凄凉，没有家的感觉，不够温馨。”

　　“Bingo，哈哈哈哈，为什么?” yixieshi

　　“你笑个毛……”

　　好了，你发现没有，对一个买电钻的人，婚介所也有机会。而用户需求，Why到哪里停住，做为产品需求，是完全取决于你的产品定位的，与用户无关。而如果我们要深挖，会发现小明要的其实在马斯洛需求层次理论的第三层——“社会交往(爱、情感、归属感)”。

　　实际操作中，为了方便，“Y”可以简化为“V”，为了返回去验证产品功能是否能满足产品需求，我们可以再Why下去，How上来，反复地做“V”，即把这个过程形象化为“W”。

　　产品团队的一项日常工作就是采集产品干系人，即“广义用户”，提过来的各种需求，并整理转化为产品需求，即图中的“需求转化”，通常转化之前我 们用mindmap较自由的表达，转化之后就成了excel里的功能列表。采集到这个需求的PD，自己可以先“确定属性”，即这个需求是属于产品的哪个模 块?是基本、扩展、增值功能?是功能、性能、用户体验方面的?等等，属性的维度大家可以按照产品的不同自由定义，原则是为了便于需求的管理。

　　这样我们得到的feature list，就有必要每隔一段时间、或是新需求积累到一定数量、或是由特别事件触发，拿出来大家一起过一遍，这是最关键的，即图中用红色突出的“确定商业价 值(产品内PK)”。我们的经验，商业价值由单个PD确定风险很大，所以这个步骤是PD团队集体讨论，再叫上有必要的干系人，比如销售、服务。对于商业价 值可以从多个维度描述，并加权平均得到综合的商业价值，详细描述可参见单向需求卡片，但绝大多数情况下，我们发现只用一个值的高中低，或者5、4、3、 2、1分来衡量就足够了。具体讨论的时候，大家充分表达意见，最终往往是会场上级别最高的人综合以后说一个数字，这是现实，也是一种高效的办法，我想过投 票、群体打分的方式，可是实施起来成本太高。

　　注意一点，讨论商业价值的会议上，会把所有状态为“待讨论”的功能点都过一遍，散会的时候，它们的状态一定要变化，或是进入“需求中”、或是被 “拒绝”、或是“暂缓”。拒绝的需求是被认为对产品的商业目的没有价值的，而暂缓的需求是“有价值，但是现在不做”的，通常要表明重启的条件，比如“3个 月后再拿出来讨论”、“某相关产品实现某功能后再拿出来讨论”等等。

　　对于状态变为“需求中”的功能点，下一步就是初定工作量了，因为需求不明确，所以只是简单的评估，和真实情况的匹配程度很取决于经验,要靠不断 的实践来反复修正。我们通常经历的项目，三大类人力资源是“产品、开发、测试”，用团队里的瓶颈资源做评估基准，所以我们一般评估每个功能点的开发工程师 工作量，因为在我们的团队里通常产品、测试资源相对可以调配，这个大家视自己团队的情况灵活应用。具体的评估，通常是类似技术经理的角色来做，评估者按照 自己做需要多少时间，乘以一个系数确定，这个系数一般大于1。 互联网的一些事

　　继续，既然对于每个迭代周期，我们有多少时间、多少人是早就知道的，那么可用工作量是多少“人日”，也就知道了。有了每个功能点的商业价值和工 作量，很自然的就能算出性价比，简单的说即“商业价值/开发工作量”，我们把feature list按照性价比从大到小排序，再对应考察每行评估出来的开发工作量，从上到下依次纳入项目，我们的可用工作量能做多少个功能点，一目了然。

　　上面谈到的这些，也就是一步步确定某个项目能做多少需求的过程。 yixieshi

　　最后，我们把这些要做的功能点合在一起，把“需求打包”，再往下就要做这个项目的BRD了。BRD通过，立项之后，再全程跟踪某个需求的进度， 上述整个过程就是一步步确定某个需求的各种属性的过程，而对某个需求的描述，可以用下面的表格来表示(不妨起个名字叫做“一个需求的DNA”)，表中红色 星号表示的项目，是我心目中的必填项。

　　这个过程完全是定量的，也就回答了“做多少”的问题。但，真实情况哪会这么简单明了，下面再说几个需要注意的地方。 yixieshi

　　第一，需求打包最好打类似的功能点，是否类似取决于需求的属性，“确定属性”这步做的事情起作用了，一般来说业务上有逻辑关系的需求才会包含一个项目里，否则就是一个纯粹修修补补的“小需求项目”了。

　　第二，需求依赖，功能点互相之间有依赖关系，那没办法，只能先做某些功能，应该在feature list里注明;功能点与人力资源之间的依赖关系也会经常存在，在这里评估工作量的时候不会考虑“谁来做”的问题，但是在后续立项，组建团队的时候需要注 意，当然长期来说，为了避免这类风险，提升与平衡团队成员的能力是王道。

　　第三，功能点的粒度大小问题，商业价值很高的功能，如果细分的话，我们也会发现其中有价值相对低的部分，所以功能点的粒度应该尽量细，前提是细 化引起的管理成本上升在可接受的范围内。具体细到多少，也只能具体情况具体分析，我想工作量的最小单位总不能超过“5人日”吧。

　　总之，站在产品经理的角度，产品需求要注意6大原则： 互联网的一些事

　　原则1：永远不要显得比客户更聪明

　　了解需求，而不是去批评客户。你熟悉的是产品和技术，而客户客户比你更熟悉业务的环境，客户总是知道问题在哪儿，你的工作就是要让他们自己愿意 说出来，而且要深入的去挖掘问题的本质和客户的潜在需求。产品经理应该有逐步成为领域专家的意识，只有这样业务和产品才可能真正匹配。 一些事

　　原则2：尊重用户的现实选择

　　客户永远是对的，许多客户提出的需求，在经过了我们人为的过滤之后，被打上“不现实”、“不可能”的印记而束之高阁。想法一定是建立在客观上 的。因为我们的产品是客观的，用户的使用也是客观的，他们的想法也是客观的，客观的就一定是存在的，存在的就一定是合理的。我们不要轻易否定用户的需求， 不要轻易向用户说：你的想法是错误的。根据现状，我们需要提供最合适的解决方案，而非最好或最贵的方案。我们能够做的不一定是最好的，我们不想做的有时候 往往是客户最需要的，找到最合适客户的，而不是最合适我们的。不要把客户当傻瓜。这个世界上没有傻瓜，自以为对方是傻瓜的人才真的是傻瓜，不要忽悠客户， 不要欺骗客户，如果非要在这个前面加上一个期限的话，我希望是“永远”。 D% *^yi8DGE

　　原则3：转述需求的人也是客户

　　只要是对我们的产品和业务提出需求，就是我们的客户，应该一视同仁。转述者一般会把自己想象成设计者，但是他们对产品或许很熟悉，但是对整个业 务可能不熟悉，因此，他们成不了设计者。因此要考虑到第三方可能会遗漏或补充一些额外的需求。每个人都期望产品能做好，这种强烈的成功心理容易让人们产生 日晕心理，从而影响我们对需求的筛选。

　　原则4：客户和用户要区别对待

　　客户是客户，用户是用户，有时候一致，有时候分离，这是我们首先要搞清楚的。产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定。 用户决定产品，我们需求工作基于用户，始于用户，归于用户。客户是多样的，价值导向也是多样的，我们的产品能否承载多样化的客户价值决定了产品能否实现最 终的交换。因此需要时刻考虑产品真正实现客户价值。产品的最终价值是通过用户来体现的，脱离了用户的产品，就是“皮之不存，毛将焉附”。

　　原则5：用最简单的文字工具记录需求

　　所有人都能懂的东西，最不容易出错;不需要再学习的东西，最不容易出错;不要希望客户能花更多的时间来了解需求转换后的模型;保持沟通的通畅，是了解需求的保障。 yixieshi

　　原则6：天下没有免费的午餐

　　要得到就一定要付出，付出的量并不一定和得到的量相等，作为产品经理来说，就是要让客户尽量少的付出，尽量多的得到，但永远不会是免费的。客户 的需求都是现实的，都是合理的，因为这些需求都是客观的，但我们通常习惯于用主观去看待客观。客户的要求都是可以实现的，没有不可以实现的需求，只有我们 了解的不够深入的需求。成本第一还是需求第一，客户把这个问题交给了我们，我们就用用我们的智慧去解决这个问题。 我们能做这事-这是所需的费用。

本文链接：http://www.yixieshi.com/pd/9240.html