产品经理系列文—如何做产品的需求分析
作者: 来源: 文字大小:[大][中][小]
我们在做
产品规划的时候，需要回答的第一个问题，就是“这个产品有没有需求？”其实就是在回答这个产品有没有可能生存下去，在市场上建立自己的地盘。这就是所谓的“需求分析”部分。
最近在看一份业务计划，这份业务计划中对于需求的判断过于主观，也过于乐观，我想这也是很多需求分析存在的问题。其原因就在于对于“需求分析”应该怎么分析，没有透彻的了解。
一个产品有没有可能建立根据地，取决于什么？答案包括两个，一个是需求，一个是竞争，这个逻辑推理简单得不能再简单了。可是当你真的去回答这个问题的时候，却当真的并不容易（如果你真的是
产品经理并需要对最终的财务表现负责，或者你想投入的这些钱都是你兜里的J）。这时候就像战场上的将军，我的弟兄们真的要这么打吗？这么打会是大获全胜齐唱凯歌还是会全军覆没鲜血淋漓？每次我在想到这个问题的时候，都会浑身战栗，当军队的统帅着实不容易。由此可以看出，当一个产品经理，当一个公司的CEO，其实都不容易。
回答这个问题，通常还包括几个层面：
l 第一个层面，这个产品有没有需求，有没有人要，能不能卖出去？
l 其次，我们还需要回答市场潜量、未来的发展趋势等等这些方面。
那怎么去判断有没有需求这件事情呢？在回答之前，我们先要明白问题是什么。下面我们就仔细推敲一下什么是需求。
什么是需求？
按说这事还不简单，还用得着这么大费周章？其实不然。我一直觉得只有你自己真的明白来龙去脉，而不是照本宣科，你才能真正掌握并灵活运用。下面我们就推演一下需求的本质。
需求简单说就是我们想要做一件事情，我们为什么想要做一件事情呢？是因为我们想要做出改变。为什么要做出改变呢？因为我们对现状不满，我们遇到了问题，或者想要满足内心的欲望，憧憬着达到一个新的目的地，一个伊甸园。但是，现实总是存在着各种阻力。
所以一个需求的构成是四个方面，现状（源点）、目的地、驱动力、阻力。
源点和目的地构成了需求的两端，就像过一条河。现在身在一边，而想去另一边。为什么我想过河呢？是因为我认知到了源点和目的地之间的差异（这种认知也许是正确的，也许是被人忽悠是错误的），被某种力量所驱动。这正如我们为了说服别人去购买一件商品，通常是陈述现状的问题，或者描述目的地的美好，或者两者兼而有之。
软件领域“SOA能让您实现复用、灵活、随需应变”“您穿这件衣服真漂亮”
这里还需要说明的是，需求是有问题领域的。一个人或者一个企业往往有各种各样的问题，有吃喝拉撒，有结婚生子等等，你必须明确地定义问题领域。
有一种非常有效的定义问题领域的方式：
你想要替代现有的哪个解决方案？（通常客户对于问题总是有某种现状的对策的，没有对策也是一种对策）原来的解决方案存在的问题，就是需要专注的问题
如果用一个模板来说，“我要解决的是A的1/2/3…问题”。
举个例子来说，在软件领域里面，页面开发技术是大家诟病比较多的，技术复杂，效率低下，而业务需求的变化还会导致更改上更大的工作量。页面开发技术有很多，包括JSP、Struts…很多。这时候，去定义领域，就应该表述成“我要解决的是JSP的1/2/3…问题”。
这种对问题的精确定义，能够方便你清晰定义你的竞争对手。
如何判定有没有需求
在明确了什么是需求的情况下，很显然，我们判断一个产品有没有需求，包括4个方面：
l 源点：企业的现状
l 目的地：未来的结果
l 驱动力：问题、某种场景或情况
l 阻力：成本多少？需要付出什么代价？
这里也可以看出，价值是相对的，不是绝对的。你不能仅仅看到目的地的好处，还要看到阻力和成本。
判断这4个方面，特别注意两点：
1） 我们需要了解的不是事实，而是客户对于这些方面的“认知”。这些认知可能不是客观事实，但是是认知决定了他的行为。（在《定位》这本书里面特别强调这一点）
2） 用户表现出“显性需求”，需要对源点和目的地的认知，并且驱动力的强度要远大于阻力的强度
我们看一个例子，“SOA在企业软件市场有需求吗？”
回答这个问题，在这4个方面就如下判断：
源点：中国当前大型企业应用基本都采用J2EE架构，但是一个一个的应用系统建设，带来了将来系统整合的问题，不能快速满足业务的需求；同时各系统之间相似的功能模块重复开发，造成了浪费
目的地：SOA架构，能够为企业整体架构带来重用、灵活性的利益，使得IT能够快速支撑业务需求
驱动力：系统整合问题严重吗？是否愿意去花费成本去解决这个问题？企业在重用上有问题吗？对重用问题是否愿意花费成本去解决？
阻力：需要付出怎么样的成本？有什么风险？怎么做？
我们就需要分别调研这些方面，看看用户对这些方面的“认知”如何，是否能形成一股正向的力量。我们看到国际厂商在国内大肆吹嘘SOA，目前还没有形成规模采用，未来是否会形成变化，取决于成功案例对于“目的地”价值的证明，以及驱动力和阻力的较量。
在开篇提到的业务计划中，就是因为没有分析驱动力和阻力，所以显得非常乐观。要知道，客户认为有问题，不一定会去花精力花成本去解决；即使想要花精力花成本去解决，那也要相对地看需要付出什么代价。
一个人个子矮，他自己也知道（“认知”）这是个问题。但是他是否就想去解决呢？未必，他自己可能觉得无所谓。他自己为什么觉得无所谓呢？因为他自己没有碰到什么事或者他自己也没这种增高的想法。可能有一天他碰到一个女朋友，他很喜欢，希望能追上这位姑娘，但这位姑娘觉得他矮，这时候他恐怕会疯了一样整天想着增高。当然了也有可能他自己就对自己看不顺眼想要增高。
再进一步，如果有问题，并且想解决，是否就能解决呢？显然不是，还受制于经济条件，一个人的收入是有范围的，干这个可能就干不了那个，一个企业也一样。比如我想买所豪宅，还想买辆奔驰，还想…都能买的吗？总有个先后顺序。
这里谈到了显性需求，相对的就有“隐性需求”。所谓隐性需求，就是客户对于目的地不清楚，不了解。这时候就需要去引导，这就叫做“教育市场”。教育是教育什么呢？就是教育目的地是什么，究竟有什么好处，怎么能到达那里，以及是否付出很大成本，有多大风险等等。
企业都比较愿意去捕捉显性需求，因为教育市场是需要花费成本的，而且有时候非常巨大。
在现在的企业软件领域，SOA非常火。那么你知道领头的IBM教育市场化花费多少钱吗？2006年在全球即投入10亿美金。 如何调查需求
如何要知道客户是怎么想的，当然最直接的就是听听客户是怎么想的了，这就需要组织一场需求调研，那么如果是你，怎么来设计需求调研问卷呢？
通常，把调研分为两部分，第一部分为定性调研，用来形成初始的假设，列出客户可能存在的问题。
大概的问卷设计如下：
1）您现在在×××是怎么解决的？采用什么产品或者解决方案？
2）您对现在的解决方案什么地方不满意？
3）您对我们的解决方案什么地方不满意？（如果是还没开发的新产品，可能不存在这个问题）
第二部分为定量调研，用来获得一些统计数据。
在问卷设计我们可能想问如下的问题：
1）是否存在这个问题？（即为定性调研中获得的不满意的地方）
2）是否想解决这个问题？解决这个问题的迫切程度如何（或者问不解决有什么坏处？）愿意最多花多少钱去解决这个问题？
3）如果去解决这个问题，您比较关心什么问题？
对这三个问题的全面回答，能帮助我们甄别我们是否真正仔细定义了需求。在做业务计划的时候，失败的地方就在于：
1） 对于驱动力，来自于主观臆测。一个通常的情况发生在，通过媒体宣传也好或者各种渠道，基于自己的所谓理性或者知识经验，觉得某个方面肯定是趋势。但是趋势归趋势，只有被客户感知到，才形成真正的驱动力
2） 存在这些问题，我们就想客户会去解决。实际上不是这样的。每个企业的资源都是有限的，对于温饱还没解决的人来说，首先考虑的是生存问题，穿衣吃饭可能都不讲究，一个人或者企业往往有各种各样的需求，这些需求有一个优先级，所以这里面必须定义Compelling Events。也就是不得不做的理由。举个例子，很多软件项目必须要求某个日期上线，为什么？有的是因为领导要来检查，有的是为了某项业务顺利推出
乐观是最常犯的错误。所以才有那么多人敢于创业。实际上，创业成功率是非常低的。
需求调研并不容易
对于消费者市场来说，了解需求可能还容易一些，但是对于企业级软件市场，了解需求存在着特别的困难。
第一个困难在于，企业级市场往往存在一个较复杂的决策链，有技术推荐者、技术评估者有决策者。而不同的人有不同的想法，那么你应该去问谁呢？
第二个也许是最大的困难，那就是你以为你是谁啊，想见谁就见谁。有些
大客户的决策者是那么容易让你见到的，那么容易向你吐露心声的？而且这种单次的访谈往往触不到痛处，上来大家都要寒暄半天，而且有些问题可能互相理解也有问题，所以最好是能保持长期沟通的。
所以企业软件市场，做起来真的不容易。这也是很多真正的产品经理从销售做起的原因，因为他们有客户资源，能够通过沟通了解客户的实际需求。