人人都是产品经理——iamsujie

有了前面需求分析的结果后，我们就要做决定了：到底做哪些需求。其实并没有一个功能是没有价值的，也并没有一个功能是做不了的，某个功能到底做不做？至少要从两个方面来考虑。

第一，商业价值。在我们公司的团队构架里，“商业——产品——技术”是明显的三条线，和用户、商业层面直接发生关系的是运营，我把这看作是前端的内容。那么这里的商业价值也就是对用户意义的大小、以及对公司目标意义的大小。这里需要PD和运营积极配合，充分分析功能给用户/公司带来的利益，但不是说利益大的就做，先把这个分析结果存着备用。

第二，实现难度。换句话说是开发量，需求+开发+测试+硬件等等一共需要的资源。这是技术层面我把它看作是后端，绝对不能因为一个功能很容易实现就马上去做，也不能因为另一个功能很麻烦就不做。

现在可以做决定了，我们做性价比（商业价值/实现难度）高的。无论任何事情都是一个性价比的问题，2007年下半年的工作中，由于一直和工程师直接接触，所以综合考虑时有点倾向于做实现难度小的，这是需要改进的。

再说开一点，谈一下对商业价值的一个判断因素，功能的商业属性：雪中送炭 or 锦上添花。雪中送炭是基本功能，对用户很有用的，产品缺了这个功能根本不可能运行，比如网店版的“我要付费”模块；“锦上添花”的功能是指用户用得到的，但没有时用户也不会跳起来的，也许现在的“客户关怀记录”可以算这类。我们在论坛上会很明显的感受到这两种需求的不同，有一点像“bug”和“需求”的区别。我是一个不那么激进的人，觉得要把“雪中送炭”的商业价值调高，稳定和谐压倒一切。情愿把一半的功能做到尽可能完美也不要把全部功能都做到半吊子。

（iamsujie补：延伸阅读，KANO模型）

另外可能还有些无法控制的因素影响这“做不做”的决定，比如国家、公司的政策指向，这里说了也白说就不说了。

通过各种需求采集的方法，得到很多信息，接下来我们要做的自然就是需求分析了。

听到过一个说法，说需求分析与技术分析的最大的不同是思路的本质差异，技术分析是“树干——树枝——树叶”的任务分解过程，技术人员很适应并乐于用这种方式思考，可以把大问题分解成小问题，发现难点逐一攻克。很多做需求的人都是开发出身的，所以开始往往会用这种思路做需求，听到客户提到的功能点，直接想怎么做系统设计了，有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。而真实情况是，需求分析是“树叶——树枝——树干”的分析过程，一定不能漏掉提炼用户需求的这个过程。

确实很有道理，后来仔细一想，其实另有两个问题值得继续思考补充在这个说法上。

第一，这里玩了一个偷换概念，两者的“分析”定义不同，按照逻辑学的通俗定义，第一种分析是真正的分析，而第二种“分析”似乎更应该被称为“归纳”。可是，如果现在提出一个“需求归纳”的概念，连我自己都觉得拗口，所以继续用“需求分析”这个词。

第二点更关键，“树叶——树枝——树干”的描述并不完整，它只是前半部分。其实完整的“需求分析”是一个先归纳后分析的过程，试想如果做到“树干”就结束，后端的开发人员还是不知道要做什么东西，所以我们还要继续把树干再次重新分解成树枝、树叶。

小结一下，需求分析的目的是把从客户那里收集到的“用户需求（更接近Want，有时候甚至是解决方案，但我们不能不假思考的照做）”做归纳，然后得到一个总体概念（用户的Need，真正的欲望所在）后再分析、分解为“产品需求（给出我们的解决方案）”。

举个例子结束：小明说要吃肥牛火锅（18元，iamsujie补：涨到20+了），我们分析认为他是饿了，不是馋了或者真的想吃牛肉，最后给出我们的方案，扔给他2个馒头（0.5元*2），结果他虽然眉头一皱，但考虑到性价比（省了94.4%的成本啊！他省的多我们的利润空间也会大些），还是很愉快的吃了……

伟大的需求分析师。

我们回到2007年7月，这是里程碑意义的第一篇，机缘巧合，团队要求写周报，我想就写自己产品设计的体会吧。

628网店版2.0上线，这是第一个我主导的付费产品，之后的三周我基本天天都会在淘宝论坛上泡不少时间，所以这次就说说从用户处收集需求的几点体会。

第一，要听用户的意见，但不要照着做。

有的用户会对一个功能提出意见，会抱怨，但没有说希望怎么做，所以我们也没法照着做。而更危险的一种，用户在提意见的同时还说你们应该做成什么样子，这个时候作为PD一定要头脑清醒了，用户提的解决方案往往是站在自己的立场上的考虑的，比如快递单打印用户会提出要添加一个他经常用的小快递公司。更有甚者，用户给出做法的时候根本没有经过大脑（一般来说并没有恶意，呵呵）。就算他给出的解决方案合理，也要再深挖用户内心根本的需求，比如用户描述“新增非支付宝交易的时候必须要选择用户不合理，希望能自己填写客户”。这里更深层的需求就可能是他需要把线下客户也管理起来，所以我们或许更应该做一个新增线下客户的功能，而不是在新增非支付宝交易的时候让用户可以自己填写客户姓名。

我们是产品设计师，最终怎么做应该我们决定。

第二，试图满足所有用户的需求是一个灾难。

听到问题就想解决，一开始的出发点都是好的，公司的价值观也提到了“客户第一”，但n个“第一”同时出现在面前的时候，总还是要评估出一个“第一”中的“第一”。和用户接触多了以后就会发现，他们的需求实在太多了，而且有些需求互相都是矛盾的，所以根本做不到听到什么声音就做什么功能。这就有了后来的优先级评估，需求管理，以后再谈这个话题。

既然不能满足所有人，那么我们应该更照顾那一部分？

第三，我们到底应该关注核心用户还是大多数用户？

我这里的核心用户是指的最活跃的一小部分人，任何一个产品总会有这样一个“短头”，而大多数用户就是那个“长尾”，在资源无限的时候，可以同时满足这两部分人，但一个产品的功能有限，开发时间、人力有限，所以只能挑出我们优先要满足的一批了。实际一点，和产品的商业目标结合起来考虑吧，说白了就是看KPI（Key Performance Indicators）是什么。既然网店版的目标是5万活跃，1.5万付费，而不是销售额，那么从一开始就注定了我们更要关注的是大多数用户的利益。这并不是说核心用户不重要，而是处于产品的不同阶段，我们的目标自然不同。

第四，再说用户另一个特点：沉默的大多数与骑墙的大多数。

好像是长尾理论里说到“沉默的大多数”，跳出来的总是很少数，而且往往是非典型的用户，那么就不能保证这批用户代表的是最广大用户的想法。比如淘宝id是****的用户，他多次提到我们的产品进销存做的不专业，而中小企业版的进销存就很好，明显他就不是我们的目标用户，从一个侧面也证明了公司产品线的划分是英明神武的。

而骑墙的大多数说的就是一种心理因素了，其实大多数人是很没有主见的，尤其在网络这样一个不用负责任的环境下，所以常见的情况就是开始跳出来的那几个人的观点引导了群体的观点，随机的初始值决定了结果，这个时候只有你单独和跟风者交流的时候，才发现他根本不是那么想的。

要满足大多数的需求却只能听到少部分的声音，那我们应该怎么办，我想只能靠更专业的用户交流（涉及用户研究的很多话题）、清醒的头脑和数据分析了。