人人都是产品经理——iamsujie

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

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

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

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

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

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

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

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

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

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

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

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

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

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

伟大的需求分析师。

可用性测试也是用户研究/需求采集的一个常用方法，从理念上讲就是：让产品的最终使用者（end user）尽可能多的参与到产品设计的各个环节中去，深入一点就很2.0了——“UGC，用户创造内容”（这也不是什么新概念，传统行业的宜家IKEA早在50年前就有所行动，让用户参与到产品的设计），把用户参与扩展开，还可以包括前期调研、demo评审等等。

而可用性测试是在产品成型但尚未发布的时候进行，效果往往无法量化，所以经常因为项目时间过紧被略过，好不容易2008年春有了一些空闲，正好手头产品的部分模块是给阿里内部人员使用的，所以就很低成本的执行了一次可用性测试。

最最轻量级的，表现为：一个人，半个小时，在我的座位上，结果提出了15个左右的问题，效率很高。

讲几点要注意的地方。

可用性测试开始之前，要邀请用户来做tester，不要给tester看到“可用性测试”的术语，而是说“来试用一下我们的新产品，提点意见”，一定不要让用户误以为是我们拿着新产品测试他，而是我们和他一起测试新产品。告知大概持续的时间，给一点产品的背景知识，测试内容是做哪些事情完成哪些任务，让tester心中有数。

做测试的过程中千万不要引导，而只是观察和记录，用户行为和预想的不一样的时候，提问，进行不下去的时候，给与提示。记住一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了，：）

结束之后，如有可能应该送个小礼品，但这次内部的就免了呵呵。尽快的总结，发给tester，一方面让tester感到他起到了作用，另一方面也是表示感谢，建立长期和谐的“用户参与产品设计”的氛围。最重要的，这分总结要用于指导产品改进，这才是可用性测试的根本目的。

有兴趣的继续去搜搜：《进行可用性测试的8个指南》、《了解可用性测试》。

用户大会是一种常用的需求采集方法，可以短时间内从多人处收集大量信息，本篇回忆一下2007年夏天组织过的一次阿里软件网店版用户交流会。这种会耗费资源较多，一般机会不多，所以要充分利用。会议虽小但需要注意的东西都一样，按时间上分几步重点摘录如下：

会前最重要的是明确这次用户大会的目的和意义，这在争取资源的时候会更有说服力，比如：产品二期卖点确认，辅助运营决策；三期需求收集（用户怎么说）；现有产品用户体验改进（通过可用性测试，用户怎么做）。

之后就是资源确定：

Ø   时间：日期、几点、时长。要考虑淘宝卖家的空闲日子和时间段。另外注意整个活动各项准备的时间点要掐准，留余量。

Ø    地点：场地；宣传用品；IT设备；礼物食品；桌椅。

Ø   人物：工作人员（分组分工，注意PD、运营、开发的搭配，要有冗余）；用户（确定目标用户、数据提取、预约，要充分考虑人数弹性）；嘉宾邀请。

Ø    材料：用户数据；问卷；产品介绍材料（测试环境确保当时可用， Demo备用）；可用性测试材料。

Ø   各项备用方案，定一个合适的“确认会”时间。

会议当天：

Ø   辅助工作：场地布置（轻松一点，不要像开会）；引导/拍照/服务/机动；进场签到（给礼品、发问卷）；全程主持（进度控制）；送客/收拾残局。

Ø   主流程：产品介绍（重卖点，观察用户更care哪些）；“焦点小组（需求收集） + 可用性测试”并行；合影留念。

后续：

Ø   资料整理：问卷报告；需求收集报告；可用性测试报告。

Ø   运营：活动的淘宝帖子；内部邮件。

Ø   整个活动资料的整理归档，包括照片、问卷、各项材料/报告信息、用户数据等。

（iamsujie补：其实很多市场活动，也就是这种会的放大版）