想成为合格的产品经理？探索用户的这几个需求是关键

大家好，欢迎来到IT知识分享网。

第2章 一个需求的奋斗史

在一个生态系统中，水是万物生命之源，而水之源又是天上的云，它们转化为雨，滴落并滋润大地。

我真正开始做需求相关的事情，是从2006年年底开始的。直到2007年夏末，大半年的时间过去，我总算对需求工作有了比较全面的了解。本章将从“用户研究”开始，接着实现需求采集、分析、筛选，最后“确定某个项目的需求范围”。从需求被发现到决定实现，这就是“一个需求的奋斗史”，如图2-1所示。

图2-1　“一个需求的奋斗史”缩略图

在本章中，我们首先说说“用户研究”，它的关键在于“从用户中来，到用户中去”。做任何产品都是一个端到端的过程，端即用户，所以“用户是需求之源”。我们要拥有“以用户为中心的思想”，不断“了解真正的用户”。

然后我将带着大家进行“需求采集”。与用户接触的过程就是需求采集的过程。我们将了解到几种常用的需求采集方法，如“数据分析”“调查问卷”“用户访谈”等。我希望大家意识到“需求采集人人有责”，从而“尽可能多地采集”需求。

面对采集到的需求，产品经理要进行“需求分析”，注意要做到“听用户的但不要照着做”，必须“明确我们存在的价值”是“把用户需求转化为产品需求”，这一过程即需求分析过程。产品经理要通过“给需求做一次DNA检测”，来“确定需求的基本属性”“分析需求的商业价值”“初评需求的实现难度”，从而“判断需求的性价比”。

资源总是有限的，所以我们只能做那些性价比高的事情。通过残酷的“需求筛选”，“活下来的永远是少数”。看看“永远忘不掉的那场战争”，给自己打打气：“别灰心，少做就是多做”，我们要有意识地“尽可能多地放弃”。

最后，是“需求管理”的话题。任何东西多了都需要管理，做产品更是“心急吃不了热豆腐”。这里与大家聊聊“一个需求的生老病死”“需求管理的附加值”，以及我自己“和需求一起奋斗”的第一年。

2.1　用户研究：从用户中来到用户中去

从前文的图2-1中可以看到，需求或直接或间接都是“从用户中来”的，所以我们要“到用户中去”^[17]。在2.1.1节，我们先了解需求的本质，再了解用户的本质，接下来谈到要有“以用户为中心的思想”，但也“不要试图满足所有的用户”。在2.1.2节中，通过了解别人、认识自己，我们来“聊聊用户研究”的话题。

2.1.1　用户是需求之源

用户是需求之源，还是我们的衣食父母。如图2-2所示，他们能给我们带来金钱的回报，或者说是“可持续发展的机会”。不过，要研究用户的需求，我们首先得弄清楚，需求的本质是什么？

图2-2　用户是需求之源

人类为什么有需求

有一次我和朋友闲聊起“人类为什么有需求”的问题，他给出过一个很有趣的解释：

“食色性也”，“食”是为了生存，保证个体延续，“色”是为了繁衍，保证种族延续，这是生物（包括人）的本性，即最基本的需求。

这个说法让我想到了马斯洛的需要层次理论^[18]：

1943年，由美国著名犹太裔人本主义心理学家亚伯拉罕·马斯洛（Abraham Maslow）提出了需要层次理论（hierarchy of needs），此理论将人的需要划分为五个层次，由低到高，并分别是：生理的需要、安全的需要、归属与爱的需要、尊重的需要、自我实现的需要。

人类生活在地球上，为什么会有各种各样的需求？那是因为生活中存在太多的问题，让人感觉不满意，而这些问题归根究底就是“理想与现实的差距”，人类会很自然地产生“减少甚至消除这个差距”的愿望，这就产生了需求。一个产品肯定是为了解决某些问题或满足某些需求而出现的。

有一个很典型的例子：

小明：“我需要买一个电钻。”

大毛：“为什么？”

小明：“我想在墙上打一个洞。”

大毛：“为什么？”

小明：“我想把一幅画挂在墙上。”

大毛：“为什么？”

小明：“因为这面墙显得太空旷了，看着不舒服。”

大毛：“为什么？”

小明：“因为太空旷就没有家的感觉，不够温馨。”

……

这个电钻其实是小明对马斯洛的需要层次理论中第二层“安全”和第三层“归属与爱”的需要。小明想让家里看起来更温馨，从而产生安全感和归属感。

通过小明的故事，我们可以发现，研究需求可以增强对用户的理解。理解用户，是产品经理最重要的素质之一。[延伸阅读5]

需求的本质就是“问题”。作为产品经理，我们每天都在设法满足用户的需求，其实就是在解决各种各样的问题。而解决这些问题的方法与思路，对任何人都有帮助，而任何人也都多少知道一点，所以，这也是我一直说“人人都是产品经理”的原因之一。

用户VS客户

用户与客户，这两个词在中文里似乎很容易被混淆，换作英文会稍微清晰一些，用户是User，有时也叫作终端用户（End User），是使用产品的人；而客户是Customer，是购买产品、为产品付钱的人。

比如你付费买了新浪VIP邮箱，这时候你既是新浪的用户，也是新浪的客户；又如某天你在路边的超市买了一瓶娃哈哈矿泉水，这时你是娃哈哈的终端用户、超市的客户，同时超市是娃哈哈的客户。

用户与客户可以是同一个人，也可以不是同一个人^[19]，对某个产品来说，产业链越复杂，其中的关系也就越复杂。所以，我们平时并不去刻意区分这些概念，而是统一用“用户”这个词来代表“广义用户”，它指的是所有和产品有关的人，或者叫产品干系人，除了终端用户、各种客户，还包括你所在的公司里与这款产品有关的老板、销售人员、服务人员、技术人员等。我们要做到心中有数，不同的用户重要程度不同。

某电子商务网站建设服务提供商的演示文档里有这样一句话——“相比您的需求，我们可能更重视您的用户的需求”。对这个服务提供商来说，他在“您”（他的客户）与“您的用户”（客户网站的终端用户）之间，做出了明确的取舍，即优先满足产品使用者的需求，而不是付钱者的需求。

以用户为中心的思想

既然用户那么重要，我们就要把它放在最中心的位置。UCDChina.com^[20]上有不少相关话题，能给做产品的朋友们很多思路上的启发。

公司有UCD的环境是产品经理的幸运，但对这本书的大多数读者来讲，可能更多的公司环境是BCD型的。BCD是我自创的词，Boss-Centered Design，意为以老板为中心的设计。中小型公司需求的主要来源不是终端用户，而是老板——或指以老板为代表的一种广义用户。一般来说，在这类公司中，老板是最接近业务、最了解用户的，加之老板的经验阅历又超过我们，所以他高瞻远瞩地抓住一些商机，并觉得这些商机能够创造价值。这时候老板肩负起了部分产品经理的职责，负责采集用户需求并分析、筛选。创业阶段的公司是没有太多时间和精力去做到“从用户中来，到用户中去”的。这种情况下，我们应该本着实用主义的原则，绝对不能一开始就抱着“我要见终端用户，我听用户的，不听你的”的“造反”想法，而是要尽可能帮助老板明确问题和需求的价值，在老板决定方向时提出参考建议，或协助他实现目标。

这样，我们便同时拥有了“以用户为中心的思想”和“以老板为中心的行动”（或者说“根据实际情况考虑如何行动”）。以老板所代表的广义用户为中心，在小团队里反而是一种较优的实践。

不要试图满足所有用户

不仅要区别对待广义用户，对于狭义的终端用户，我们也无法一视同仁。比如某天，你作为一个新产品经理兴冲冲地拿着收集来的100个需求，跑到团队里跟大家说：“看，用户提了那么多需求，我们全做了吧。”技术部门的同事说：“这起码得做半年。”

你很快就会发现，用户的需求实在太多了，根本做不过来，这就有了基于优先级评估的需求管理。

试图满足所有用户的需求是一个灾难，那会让产品变成一个臃肿不堪、谁都不满意的四不像。既然我们无法满足所有用户的需求，那么我们应该优先照顾哪些人？

谁对我们重要就照顾谁，那么如何评估是否重要？腾讯CEO马化腾会说应该关注高端用户的需求。而我的一款产品刚起步时，老板跟我说先满足大量的一般用户的需求。

谁错了？其实谁都没有错，腾讯的产品已经充分占据了市场，拥有霸主地位，所以用户数不可能再有爆发式增长，于是只能考虑从已有的用户身上深挖用户价值，最有价值的一批用户无疑是高端用户；而我做的那款产品刚起步，急需把用户池做大，所以我们会先做一些大众功能，满足一般用户的需求，让用户数先增长起来。

所以，优先满足哪些用户需要和产品的商业目标结合起来考虑。简单说就是看KPI^[21]是什么。在上文的例子中，既然我们的产品目标是用户数、活跃用户数，而不是销售额，那么从一开始就注定了我们要照顾的是大多数用户的利益。这并不是意味着高端用户不重要，而是产品不同阶段的目标自然不同。

2.1.2　你真的了解用户吗

真正的用户所想的、所做的，你真的了解吗？

了解真正的用户

我开始做企业应用产品的时候，一次次地被那些正在“电子商务”门口晃悠的用户们震撼了，以此为例来看看真正的用户吧。

他们是中国最典型的中小企业，从拥有十几、几十个员工的贸易型企业到拥有上百个员工的生产型企业。他们一般的年销售额有几千万元人民币左右，只是顺应潮流建了网站，没做网络推广，网站几乎没有访客。但是，他们却买了我们的营销管理工具。于是我们做了一批电话访谈。正是这次访谈，让我们更进一步了解了我们的用户。以下是对这次访谈中的部分对话摘录：

►有的用户是被经销商忽悠进来的，不知道自己有没有需求，甚至都不知道自己买的是什么产品。

1.“我没有买你们这个东西，不要不要不要不要不要，嘟嘟嘟……”原来经销商把我们的产品和其他东西一起打包成了“忽悠套装”，也不跟用户讲清楚套装里面到底有什么，唉。

2.“原来这个买了还要账号密码啊，经销商没给我……”“经销商说他们全程服务的，我们不需要做什么。”

他们以为和做网站一样，付了钱就没事了，可是这次买的是个软件呀。

3.“我们公司嘛，只有一台电脑，因为放在我办公室，所以就让我用用，但我不懂电脑的嘛。”

老板随便找了个人用，可是这位大叔听上去并不了解业务……

►有的用户，打电话过去找不到想找的人。

1.“我不懂这个的……”停顿3秒，“我不懂这个的……”停顿3秒，“我不懂这个的……”

一位有耐心的阿姨，可惜只会说这句话……

2.“你是哪里？”“BlaBlaBla……”“不要再给我打电话了！啪，嘟嘟嘟……”有时候你会碰到个火气大的。

3.“我……听不懂……普通……话……”

好吧，再见。

►有些，让我们了解到了一些需求，不过都挺冷门。

1.“我忘了账号了，忘了网址了……”这点我们要好好反省，是有办法解决的。

2.“我们做的东西很专业啊，都是上年纪的人，习惯电话联系，这样效率高、说得清楚，我们不懂网络的。”

电话沟通是个方向，网络的价值最终还是要通过与线下结合来体现。

3.“我们主要靠老客户、熟人介绍的，都是大单，网上来的小单子不要做的。”嗯，总算听到些靠谱的，他们的业务地域性很强，对业务员来说，老客户已经足够吃饱了，网络带来的小单是有点看不上眼。

►还有一些，聊来聊去都是闲谈。

1.“啊，你是阿里巴巴的啊，我来考考你，阿里巴巴是哪年成立的？”

2.“一年几千万、上亿的销售额，几千块钱哪里花不是花，呵呵。”还算有点让人欣慰的。

经历了这些对话，我真正意识到想了解用户，光靠空想是不行的，他们是真实的、是五花八门的，必须得真刀真枪地去研究他们。

试着描述用户

看到这里，你有没有跃跃欲试，想和用户来个亲密接触？可惜现实中不是随时都有那么多资源让我们折腾的。但是，有一个几乎零成本的做法，它可以让你增加一点对“用户”这个词的感觉。

我们来做一个简单的练习，即使你不是做互联网、软件相关产品的，也一定用过，试着描述一下自己在用各种互联网应用时是个什么样的用户。我先描述一下作为互联网应用用户的自己（此段背景为2010年）。

E-maiI：我在2000年的时候申请了第一个私人E-mail，那是新浪的产品。但是在学生时代利用率不高，没什么邮件。到2007年的时候用Gmail代收，之后就不再对外留这个地址了。现在私事用Gmail，它强大的搜索功能让邮件整理的工作变得不那么重要，节省了很多时间。我也很喜欢它把同主题邮件合并的处理方式，适合群聊。我会把一些文件备份也放在邮箱里面，因为空间够大，而且防垃圾功能做得很不错。

IM^[22]软件：如何选择IM软件最主要取决于自己认识的人都在用什么，除打字沟通以外的功能用得很少。私事用Gtalk、MSN，喜欢Gtalk的简单；公事用阿里旺旺。很少使用，再次使用是在2009年7月，当时自己打球受伤导致跟腱断裂，没想到上有个跟腱断裂群，在这点上不得不感叹用户基数的强大。

豆瓣：豆瓣对我来说是个很好的工具。在别处了解到某部电影和某本书以后，决定是否看之前都会去豆瓣看看评价。我比较信任群体智慧，特别是在这个群体人员与我的口味比较相似的情况下，比如我抛弃IMDB的电影评分转向豆瓣，是因为总发现有些评分超过8分的电影我看了毫无感觉，而豆瓣却很准，说明我的口味非常本土化……我会标记“想看”“看过”，但是很少留下评论。

上面提到的只是我所使用过的互联网产品中的三个样本。如果你也想给自己做一次用户描述，可以写写微信、微博、手机上各种应用的使用习惯。这有点像创建人物角色（Persona）^[23]。我试着为某个汽车网站设计了一个人物角色，如表2-1所示。

表2-1　人物角色（Persona）

表2-1中的主要内容包括人物照片、个人信息与简介、行业信息、计算机和互联网使用情况，以及用户目标、商业目标等。充实人物角色有很多方法，在下文“聊聊用户研究”中会给大家介绍一些资料。

2009年秋我做了一个产品整合项目，要把手头的产品和另外一个我完全不了解的产品做一些功能的合并。那时，我才体会到具象化的人物角色的更大意义：它可以帮助新人在刚进团队时迅速了解用户、理解产品，同时帮助忙碌的、无法关注细节的老板迅速进入状态，保证他们也能像创建者一样，心中时刻想着正确的用户形象。

聊聊用户研究

刚工作不久时，我总把用户研究当作产品设计过程中锦上添花的事情。每当没什么事可做的时候，我就跑去跟老板说：

“我们这两周做点用户研究吧。”

“你的目的是什么？”

……

后来我渐渐明白，用户研究不是附属内容，而是前提条件，必须在做产品的过程中随时纳入计划。也许有一天，你接触用户时会感到不知所措：我到底应该找谁？通过什么方式？聊些什么？如何指导产品发展……关于这些问题，我的启蒙书是《赢在用户：Web人物角色创建和应用实践指南》。

全书讲述了各种创建人物角色的方法及其应用。这一做法的目的是在设计产品的过程中时刻做到不忘用户，确保产品以用户为中心。其实“用户研究”“市场研究”“需求采集”等步骤都是为确定产品功能而服务的。书中有一张关于用户研究方法的二维图，如图2-3所示。

图2-3　用户研究的方法

此图来自《赢在用户：Web人物角色创建和应用实践指南》，稍有修改

图2-3中横坐标代表了用户的“说”和“做”。

“说”表现了目标和观点，”做”反映了行为，用户“怎么说”和“怎么做”经常是不一致的。我曾经认为“耳听为虚，眼见为实”，看到用户怎么做会比听他们怎么说更真实有用。但我后来体会到，只了解“做”是没办法知道背后原因的，而不知道问题的原因也就意味着没办法从根本上解决问题。所以，我们既要看用户怎么做，也要听用户怎么说。

图2-3中纵坐标代表了定性与定量。

定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实。两者都很重要，缺一不可。只进行定量研究会导致“以表代本”，我们只能看到问题但不知道原因；只进行定性研究会导致“以偏概全”，我们很可能被部分样本的特殊情况带入歧途。人们认知新事物的过程通常都是从定性到定量，从再定性到再定量，这样螺旋上升，并且了解和证实也是在不断迭代进化的。

“说”和“做”、定性与定量，相互之间各有优势与劣势，合理地搭配使用才能发挥最大的作用。下面这个产品调研的小例子，就是用了各种用户研究方法来交替解决问题的：

第一轮，听用户定性地“说”，确定产品方向要怎么做。随机抽样40个用户做访谈，据此写出需求列表。

第二轮，听用户定量地“说”，确定需求优先级要怎么做。投放了20万份调查问卷，确定了需求优先级的排序。

第三轮，看用户定性地“做”，先做的那几个需求要怎么做。一边设计，一边陆续找了10个用户来验证，做可用性测试。

第四轮，看用户定量地“做”，根据产品的用户使用情况做数据分析，不断改进产品。

上述维度的划分^[24]可以帮助我们更好地理解各种用户研究方法的特点，以便在现实工作中更加灵活地应用。每类方法都有其优势和劣势，对应了不同的使用场景，使用之前要认真考虑产品的目标是新产品定位，还是老产品优化；是预测某新功能的用户数，还是提高用户活跃程度。不同的目标，我们要使用不同的方法。

说到底，我们做用户研究的目标是：坚决杜绝“经组织研究决定，用户需要一个××功能”这类事情发生，要实实在在地把用户当作需求之源。每个产品经理都应该看一些关于用户研究的基本理论，这样至少可以避免犯一些低级错误，比如做调查问卷时通常需要给用户激励，但不能使用被调查的产品作为诱饵，这样做会对人群进行筛选，可能吸引的更多是对产品感兴趣的用户，或者是贪小便宜的非目标用户，从而让结果产生偏差。

2.2　需求采集：产品源头的大生产运动

在实际工作中，到底采用哪种用户研究方法，往往取决于资源，比如人员数量与能力，以及老板给你多少时间、经费。如果资源非常少，可以简化出很不正规的方法，比如查一些二手资料然后和同事们一起讨论，猜测用户是怎么想、怎么做的；而有了资源以后，就可以叫几个用户过来访谈，请咨询公司协助出报告，或者出差做用户调研等。每个人所处的团队条件不一样，只能在实践中慢慢总结出适合自己的方法。

但这些用户研究，或者说需求采集的过程，都会有如下几步：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，最后进入下一步的需求分析阶段。

我把前文图2-3“用户研究的方法”简化为如图2-4所示的“常用的需求采集方法”，4种用户研究方法对应图中4个需求采集方式，接下来在2.2.1节至2.2.4节中，我们会介绍这4类方法的特点、操作方法及注意事项。

图2-4　常用的需求采集方法

最后，在2.2.5小节提出了“需求采集人人有责”的概念，只有这样我们才能“尽可能多地采集”。

2.2.1　定性地说：用户访谈

用户访谈通常采用访谈者与被访者一对一聊天的形式。在访谈中，一批次的用户样本比较少，一般是几个到几十个，但我们在每个用户身上花的时间比较多，通常为几十分钟到几个小时。访谈的形式通常围绕着几个特定的话题。我们问，用户答；用户说，我们听。这是一种典型的定性研究。用户访谈可以了解用户怎么说，即他们的目标和观点。根据我自己的经验，用户访谈经常被用在新产品方向的预研工作中，或者通过数据分析发现现象以后，用来探索现象背后的原因。

用户访谈的常见问题与对策

用户访谈经常出现如下问题：

第一，“说”和“做”不一致的问题。

用户经常会“骗”我们，先看一个经典的索尼游戏机的故事。

索尼找了一些用户，问他们喜欢黄色的还是黑色的游戏机，结果发现说喜欢黄色的用户比较多。之后，索尼告知用户为了感谢他们的配合，将送他们一台游戏机，颜色可以任意挑选，而同样的一批用户，选择黑色游戏机的更多。很明显，有部分用户说喜欢黄色却带走了黑色的游戏机。

用户倒不是想故意欺骗我们，而可能是：他们被问了自己也没仔细想过的问题，又不想回答不知道，就在现场编造了一个看似有理有据的理由；或是他们在讨好访谈者的心理动机下，回答了他们觉得你希望听到的答案，而不是自己真正的想法^[25]。

对我们来说，可以像索尼一样，尽量在用户可以和产品发生交互的场合下进行用户访谈，让用户在“说”的同时也“做”，以防止被“骗”。只不过，这种访谈的成本会明显高于电话访谈或简单的面对面访谈。另外，我们也要注意区分用户说的事实与观点。一般来说，诸如“我做了什么、步骤如何、碰到了什么问题”这类事实的可信度更高一些；而“我觉得、我认为”这类的观点，则需要带着大大的问号去听，并且机智地去探究支撑观点的事实。

第二，样本少，以偏概全的问题。

我们选择样本的时候需要多加注意，尽量做到随机。下面举几个常见的“不随机”的例子。

比如为了成本考虑，我们上门访谈的时候只找了本市的用户，这样很可能得出一些与地域有关的错误推论；又如电话访谈时，为了提高联系成功率，我们优先拨打留了手机号码的用户，而留手机号码的行为很可能代表这批用户忠诚度已经比较高；再如邀约用户来公司访谈，“愿意来的用户”就已经和全体用户有差异了……

对于这个问题，我常用的对策如下：首先，我们应该尽量识别出各种可能引起偏差的因素，并在访谈的报告里标明，让报告的读者了解。然后，为了用尽可能少的样本得到尽可能正确的结论，我会以增量的方式做访谈。举个例子，我会先访谈5个用户，得出基本结论，然后再访谈5个，观察结论是否有改变，如果有改变，就继续加大样本量，或者思考问题是否合适、样本集是否合适；如果没有改变，就停止继续访谈，节省成本。

样本的选取属于概率与数理统计的范畴，想深入了解的读者可以自行研究。

第三，用户过于强势，把我们往沟里带。

我在2006年底做“阿里软件网店版”的用户访谈时，就经常犯这个错误：

当时我们找来了很多淘宝的大卖家，问了几个问题以后，那些卖家的情绪就被调动起来了，似乎好不容易有个倾听者来听他们创业过程中的成就与艰辛。然后大家就开始讲故事，故事的真假不论，反正都是无比精彩，我们又不够老道，完全被忽悠得入了神，原本一个小时的访谈变成三个小时，最后送走用户，访谈记录却一片空白。

要解决这个问题，我们需要时刻牢记访谈的目的。如果发现话题不对，需要及时将话题纠正到正轨上来。访谈的用户很多，不要在一个不合适的对象上花费太多时间。

第四，我们过于强势，把用户往沟里带。

我们团队原来有一位做销售出身的女生改行做产品经理，在新产品中负责了几个模块的设计，设计完成后邀请用户来做访谈。她的故事很有趣—

访谈开始挺好的，她慢慢深入地问着，用户小心翼翼地答着。随着访谈的进行，用户渐渐地放开了，开始对产品提出自己的看法，于是意见一条一条地向那位女生抛去，只见她的脸越来越苦，然后终于忍不住了。她给用户晓之以理动之以情，指出了用户的理解有哪些不对的地方，她的产品确实很好，很值得买，几十分钟过去，用户完全被说动（不得不赞叹她的销售功底就是扎实），觉得这确实是一款好产品，并且承诺说上市以后一定买。用户走后，她心满意足，回来大家一讨论这个过程，都傻了。

解决这个问题的对策，同样是牢记访谈的目的，并且管好自己的嘴。

《软件观念革命：交互设计精髓》^[26]一书中也讲了不少用户访谈时需要注意的点，下面摘录一些要点分享给大家。

►避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读。

►首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。

►避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面。

►避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。

►鼓励讲故事：故事是最好的帮助设计师理解用户的方法。

►避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用吗？”一般来说用户会给出毫无意义的肯定答复。

记一次用户大会

用户大会是邀请产品的用户到某一集中地点开会，人数一般在几十人到几百人不等，可以短时间内收集大量信息，是一种特别的用户访谈形式。我在2007年6月组织过一次“阿里软件网店版”的用户交流会。这种会耗费资源较多，举办的机会很少，所以要充分利用。结合下文这个提纲，我们来看一下这种用户访谈形式应该如何准备、如何操作。如果把“用户大会”视为一个产品的话，大家也可以从中看到一些做产品的通用思路。

明确目的

会前最重要的是明确这次用户大会的目的和意义，这样在争取资源时才会更有说服力，比如：产品二期卖点确认，辅助运营决策；三期需求收集；现有产品用户体验改进等。

资源确定

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

►地点：场地、宣传用品、IT设备、礼物、食品饮料、桌椅。

►人物：

工作人员：大家一起上，人人有事做，分组分工，注意产品、运营、开发人员的搭配，要有多余的人员名额处置突发事件。

用户：确定目标用户、数据提取、预约，要充分考虑人数弹性。

嘉宾：相关老板、合作部门的同事，不管来不来，邀请要发到。

►材料：用户数据、产品介绍材料（测试环境确保当时可用，静态Demo备用）、可用性测试^[27]材料。

►各项备用方案的准备，用户大会前两天开一次“确认会”。

现场执行

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

►主流程：

1.产品介绍，重点是卖点介绍。与用户进行互动，观察用户更关注哪些功能，进而辅助上线前的运营决策，决定到底主推哪些卖点。

2.抽取部分用户做焦点小组^[28]的讨论，收集后续的需求，产品三期开始启动。

3.同时抽取部分用户做可用性测试，帮助产品二期做最后的微调。

4.最后合影留念。

结束以后

►资料整理：卖点总结报告、需求收集报告、可用性测试报告。

►运营：针对本次活动在淘宝论坛发帖，发送内部邮件。

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

一场三四个小时的会，我们好几个人前后忙了半个月，从计划制定、资源申请、各种材料准备，到当天执行、之后的分析整理……不过这些辛苦都有了回报，在短短几个小时内，从三四十位用户那里获得了很多有价值的信息。比如确定了产品二期主推的3个卖点；明确了产品三期优先级最高的几个需求；与这些用户成为朋友，将来可以作为产品的种子用户^[29][延伸阅读6]等。这些都为今后的产品发展提供了指导。

定量地说：调查问卷

同样是听用户怎么说，常见的定量研究方法是调查问卷。

调查问卷和用户访谈的提纲是有区别的：用户访谈的提纲通常是开放式问题^[30]，适合与较少的访谈对象进行深入的交流，以解决困惑、确定产品的方向；而调查问卷中通常封闭式问题比较多，适合大量用户的信息收集，但不够深入，一般只能获得某些明确问题的答案。调查问卷不是考卷，不适合安排问答题。用户访谈与调查问卷之间也有联系，我们经常通过前者的开放式问题为后者收集具体的封闭式问题的素材。

无论是线上还是线下，问卷的作答时间最好不要超过5分钟，否则很多人看一眼就被吓跑了。开篇一般放一些简单的不需要思考的问题，很想知道的、需要思考的、较敏感的问题一般放在中间，而有关被访者个人信息的题目一般放在问卷的最后，以免应答者在回答这些问题时有所顾忌，进而影响其他答案。

调查问卷的常见问题与对策

调查问卷一人一份，独立作答，可消除“焦点小组”“论坛发帖征集需求”等具有群体讨论性质的方法的弊端。这是因为在群体讨论中，沉默者与骑墙派总是大多数。

《长尾理论》^[31]里说到“沉默的大多数”：站出来的总是少数用户，而且往往是非典型的用户，不能保证其代表了目标用户的想法；而“骑墙的大多数”是指大多数人是没有明确观点的，尤其在一个匿名的网络环境下，最早表态的那几个人的观点常常引导了群体的观点，随机的初始值决定了结果。这个时候你只有单独和跟风者交流，才会发现他根本不是那么想的。

保持调查问卷的客观性、多份问卷之间的独立性，可以有效避免上述问题，但容易出现的问题在于：

第一，样本用户与想了解的目标用户存在偏差。

由于样本量的限制，用户访谈始终只能听到目标用户群体中一小部分用户的声音。而调查问卷可以进行更多的采样，我们应该充分利用。所以，调查问卷的样本选择，就有两个注意点^[32]：尽可能覆盖目标群体中各种类型的用户，比如各种性别、年龄段、行业、收入等；要保证各种类型用户的样本比例接近全体的比例，比如目标用户中男女比例为7:3，那么我们的样本也应该保持这个比例。

但在实际工作中，经常会因为各种原因没办法选择完美的样本，比如我们的产品销往全国，但出于成本考虑，只能选择特定城市的目标用户做街头的拦截调查；又如利用网络做调查问卷，能在特定时间、特定页面上看到问卷的人，已经是被筛选过的群体；再如在各种场景下，愿意填写问卷的人也许只是目标群体中特定类型的用户，这是一种潜在筛选。

所以，在类似情况下得出结论时，大家最好把这些潜在的筛选条件标明，让报告的读者知道数据获得的方法与来源。如果我们是报告的读者，也要带着相关问题去分析数据。

有一个设计问卷的小技巧：我们可以把目标群体的特征也定义成一系列问题放入问卷中，待我们回收问卷以后，就可以通过这些问题评估作答者是否能代表目标群体了。如果发现作答者和目标受众存在偏差，我们也可以从回收的问卷中再筛选出一个接近目标群体的子集来分析。

第二，样本过少的问题。

样本量过少时，采用百分比来分析是没有意义的。这是很多新人会有的误区，比如只问了5个人，3个人选A，就在报告中说有60%的用户选A，这是很不严谨的。如果换5个人再做一次，很可能就是40%了。数字百分比要具备稳定性才有价值，所以，此时只能说“问了5个用户，有3个用户选A”。

第三，问卷内容的细节问题。

首先，问题表述应无引导性。比如，不要问“你喜欢某个产品吗”，这时用户可能会考虑到提问者的情感而回答“是”，正确的问法是“你是否会把某个产品推荐给你的亲友？请在0到10之间打分。”^[33]

答案的排列顺序也可能导致“顺序偏差”或“位置偏差”，即被调查者选择的答案可能与该答案的排列位置有关。有研究表明，如果在一组陈述性选项中进行选择，被调查者趋向于选第一个或最后一个答案，特别是第一个答案；而在一组数字中进行选择时，如选择价格或打分，则被调查者趋向于取中间位置。为了减少顺序偏差，可以准备几种选项排列顺序不同的问卷。

对于重要的问卷，为了避免上述问题，我们还有个通用的办法就是先进行小范围的试答，根据反馈修改后，再大面积投放，这和互联网产品的灰度发布^[34]有着同样的理念。

设计一份实际的问卷

我们来试着设计一份实际的问卷。和做任何产品一样，先想清楚目的，然后明确样本对象、调查渠道、时间计划等，最后才是问卷内容本身。

给大家举一个实例，我为这本书的读后反馈设计了一份调查问卷，有兴趣的读者可以做一下。^[35]

问卷目的：收集本书的读者反馈，总结得失，希望本书的2.0版本能做得更好。

样本对象：本书读者，扩大到博客读者，以及对产品经理感兴趣的人。

调查渠道：网络、个人博客等渠道发布。

时间计划：本书上市后放出问卷，收集至少3个月后给出一份分析报告。

问卷内容：不断优化，你真正看到的问卷可能与下面内容有所区别。

同学你好，我是《人人都是产品经理》的作者苏杰，这个问卷是为了……，作答大约需要2分钟，完全匿名，非常感谢。

首先，是一些简单的问题，帮助我对作答者进行分类。

►你看过《人人都是产品经理》这本书吗？（单选）

是，否

►你看过“iamsujie.com”这个博客吗？（单选）

是，否

►你是怎么知道这个问卷的？（单选）

通过书，通过博客，其他网上渠道，其他线下渠道

然后，是一些我最想知道的问题。

►你工作多久了？（单选）

还是学生，1年以内，1到2年，3到5年，6到10年，11年及以上

►你是几岁的产品经理？（单选）

-1到0岁，1到2岁，3到5岁，6到10岁，11岁及以上

►你的岗位？（单选）

产品经理，其他产品相关（如需求分析、用户体验、交互设计、运营），商业相关（如市场、销售、服务），技术相关（如开发、测试、架构、运维），各种管理岗位，其他

►你的行业？（单选）

移动互联网，互联网，软件，其他IT类，其他

►你的公司规模？（单选）

10人以下，10到100人，100到1000人，1000人以上

►你工作中接触最多的主题？（多选）

用户，需求，项目，文档，流程，战略，修养，职场，其他

►你希望我多说些什么主题？（多选）

用户，需求，项目，文档，流程，战略，修养，职场，其他

►你对《人人都是产品经理》的2.0版本有什么意见和建议？（唯一一个问答题）

接着，想了解一些你的情况。

►你的性别？（单选）

男，女

►你的年龄？（单选）

20岁以下，20到25岁，26到30岁，31到40岁，41岁及以上

►你所在的城市？（单选）

北京，上海，杭州，深圳，广州，其他

►你的月收入？（单选）

2k以下，2k到5k，5k到10k，10k到20k，20k到50k，50k以上

最后，还有什么想说的？

2.2.2　定性地做：可用性测试

可用性测试即通过让实际用户使用产品或原型来发现界面设计中的可用性问题，它属于典型的定性研究。这种测试通常只能针对少数几个用户。

它是UGC^[36]理念的一种很实用的实践，在目的明确的前提下，简单介绍一下主要过程。

首先要招募测试用户。招募测试用户的主要原则是，这些测试用户要能尽可能地代表将来真实的用户。比如，如果产品的主要用户是新手，那么就应当选择一些对产品不熟悉的用户。

然后是准备测试任务，测试的组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。

接下来的重头戏是测试过程。可用性测试的基本过程就是用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。

测试结束后，组织者可以询问用户对产品的主观看法或感觉。另外，如果用户在测试的过程中没有完全把思考的过程说出来，此时也可以询问他们当时的想法，询问他们为什么做出那些操作。

最后是研究和分析。在可用性测试结束之后，组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，我们可以根据项目进度来选择哪些优先处理。

可用性测试的常见问题与对策

和用户访谈、调查问卷一样，可用性测试也有其特别需要注意的问题。

第一，如果可用性测试做得太晚（比如在产品马上要上线的时候），这时发现问题也于事无补了。

其实，可用性测试在产品的各个阶段都可以做。在产品已经上线运行时，可以拿真实的产品给用户做；在产品只有页面Demo时，可以拿Demo给用户做；在产品只有纸面原型时，可以拿着手绘的产品，加上纸笔给用户做；甚至在尚无任何成型的产品时，可以拿竞争对手的产品给用户做，以避免我们犯同样的错误。总之，不同阶段有不同做法，我们都能从中发现相应的问题。

第二，总觉得可用性测试很专业，所以干脆不做。

可用性测试听起来名称很专业，但收益又无法量化，所以很多老板不太愿意投入资源，经常因为项目时间过紧被略过。可用性测试通常需要做5个左右的用户才可以发现大部分的共性问题，前前后后的准备也耗时不少。即使只做一个用户，并且简化步骤，也比不做要好。

比如，我自己尝试过对一个内部使用的用户管理平台做了一次最轻量级的可用性测试，设施对象为一个同事，测试时长为半个小时。测试的过程是在我的座位上，让该同事进行简单的几个操作任务，比如“将X用户的有效期增加一年”“将Y公司的状态设置为冻结”“查询Z公司的员工数”等。结果，通过这一测试我发现了十几个问题，可见可用性测试的效率很高。

第三，明确是测试产品，而不是测试用户。

可用性测试要邀请用户来做测试人员，我们在开始之前，应当明确地告诉用户，这个测试的目的是发现软件产品中的问题，而不是要测试用户是否有能力使用软件。所以，不要让用户误解了“可用性测试”的目的，我们应该向测试对象说明“来试用一下我们的新产品，提点意见”。这将有助于减轻用户的压力，使得他们能像在真实环境中一样来使用软件。

第四，测试过程中，组织者该做的和不该做的。

刚开始的时候，我们可以告知用户大概需要的时间、要做哪些事情，让用户心中有数，轻松愉快地完成任务。

在可用性测试中，我们可以要求用户在使用产品的过程中采用一种名为“发声思维”的方法，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户想先做什么、后做什么、为什么要做某个动作等。

做测试的过程中千万不要有任何的引导与暗示，我们只做观察和记录，任何引导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，只有在实在进行不下去时，再给予提示。记住，一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个用户错了。

结束之后，如有可能，应该送个小礼品，当然在邀请时就要告诉用户会有一些对他付出时间的补偿。同时，我们尽快总结测试结果，并且将总结的结果发给用户，一方面让用户感到他做了一件有意义的事；另一方面也是表示感谢，建立长期和谐的“用户参与产品设计”的氛围。最重要的是，这份总结要用于指导产品改进，这才是可用性测试的根本目的。

产品改版的一次冒险

每一个优秀的产品（比如Gmail、微信）都是靠着不断的升级、优化、改版才逐渐获得认可的。改版的初衷都是为了产品升级，以便更好地服务用户，但改版在客观上会挑战用户现有的习惯，所以必须慎之又慎。可用性测试就是一种很合适的方法，可以保证产品改版的安全性。对于一个产品经理来说，如何在合适的时机推动一次合理的改版是一大考验。本节中的案例是2007年我发起的一次产品改版——网店版从1.0升级到2.0。

这次改版在页面风格上有极大的变化，如图2-5、图2-6所示。刚开始考虑到我们的目标用户全部是淘宝的大卖家，所以网店版1.0沿用了当年淘宝网“我的淘宝”的页面风格。之后的几个月，随着产品的发展，我们发现在1.0的页面框架下，很多功能设计起来都要瞻前顾后，所以决定颠覆性地把导航菜单从左侧移到上方，释放页面空间，并且修改了很多交互、视觉的细节。

整个过程几乎完全凭借我们的喜好改进，直到上线前几天，我们才叫了几个用户来做可用性测试，而这时候其实我们已经知道没时间改了，只是想听用户说一声“Yes”来增强自己的信心，如果这时候用户说“No”，绝对是一个灾难。

好在参加测试的用户对我们说了“Yes”，上线后数据分析的答案也是“Yes”，我们才没有因为缺乏经验而造成太多损失。在这之后，我再也不敢这么晚才做可用性测试。联想一下淘宝网“我的淘宝”曾经做过的改版^[37]、2007年底豆瓣为了庆祝注册用户过100万的改版、2009年百度贴吧的改版、2013年手机向微信看齐的改版，都因为用户的反对声音太大而不得不道歉，甚至有的产品不得不重新改回原版，我们真的很幸运。

图2-5　网店版1.0首页示意图

图2-6　网店版2.0首页示意图

这次改版让我事后去恶补了不少常识。对于改版，除了“可用性测试”要在足够早的时候做，发布后还有一些方法可以改进。

首先，先从部分次级页面改起，比如“我的淘宝”历时多年的改版。

其次，新旧版本并存一段时间，并允许用户自由选择，比如2007年的新浪邮箱和2014年的手机支付宝钱包。

再次，小面积试验，选择一小批测试用户放出新版本，监测效果、做用户调研，比如Gmail通过Labs发布某些新功能。

最后，傍上一个用户已经习惯的风格，比如网店版的前身“高级店铺”升级到网店版1.0的时候，讨论了很多方案，最终还是决定模仿“我的淘宝”的页面风格。

2.2.3　定量地做：数据分析

只要做的是一个大用户量的产品（互联网产品往往都有这个特点），那么我们总会惴惴不安：就算做问卷的普查，回收到的有效问卷也可能不到用户总数的10%。或者说，在样本的选择上都有一定的被动性——需要样本同意参与，所以我们只能接触特定的少部分用户，那么这些样本到底能不能代表目标用户群体呢？

虽然绝大多数情况下的经验证明，只要在用户的选择上没犯什么低级错误，他们是“具有代表性的”，或者说接受这种假设是一种性价比很高的解决方案。不过，我们还有数据分析这种定量的研究方法。这种让数据来说话，看看用户到底怎么做的方法，不论是考察目标用户全体还是部分采样，都完全可控。“According to the data”是最难被驳倒的^[38]。

数据来源多种多样。常见的数据来源有用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等。数据分析的方法，最简单的可以制作Excel表格，复杂一点的可以用一些统计软件、数据库软件，或者直接自己写程序解决。而数据分析最关键的步骤就是对结果的解读，通常数据分析只能发现一些现象和问题，并不能了解原因，所以分析完成后我们通常会跟进举行一些用户访谈，听听用户怎么解释。

数据分析的常见问题与对策

我们要意识到，用户“怎么说”和“怎么做”之间常常会有矛盾，有时候用户的行为比语言更能反映出他的真实需求。比如卖家用户说在搜索买家的时候应该加一个“按交易额搜索”的条件，也许只是他某次的特殊需要，如果我们听他的做了这个功能，之后通过分析用户行为的数据发现，只有1/10000的人用过，那就表明我们被用户的说法“骗”了，但数据永远不会骗我们。不过，在数据分析时也会有一些特定的问题，下面让我们逐一分析。

第一，过于学术，沉迷于“科学研究”。

我在读研的时候，做的就是统计分析、数据挖掘相关的课题，所以工作中开始遇到数据分析的时候，我挺兴奋的，感觉可以好好地研究一番了。但渐渐我体会到，实际的生产和科研是有很大不同的。科学研究通常只注重“性价比”的“性”，只要结果好、方向新，往往不在乎投入，因为科研的结果往往不是为了马上应用，而是为了证明实力、做技术储备。^[39]

但在实际生产环境中我们会更重视综合的“性价比”，所以我们日常的数据分析方法也就显得不那么严谨。尤其是小步快跑的创业团队，他们可能不需要在每次分析前都去验证样本群体是否符合某种统计分布，也可能不需要用高科技手段去预测产品将来的用户数，甚至给出“A＞B”的结论时也用不着做“显著性检验”。

第二，虽然数据不会主动骗人，但我们经常无意或有意地误读数据。

什么是无意地误读数据？举个例子，对一个人群，人们的身高用平均数来衡量是有意义的，我们知道身高属于典型的正态分布，中间多两边少，所以一个平均值，最多再加标准差，就能了解群体的大致情况。而对人们的收入，就不能用平均值来衡量了，一个超级富豪和1000个零收入的人一平均，很可能得出人均收入100万的荒谬结论。解决这个问题的对策，是学习统计学的知识^[40]，努力提高自己的水平。

主动地误读数据，是比较有趣的现象。在提取数据之前，我们心中通常已经有一些结论了，无非是想验证它。抱着这一出发点，我们总能找到数据来证明自己已有的想法，并且能力越强的人越容易做到这点。对此，一个简单的对策就是对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯。比如在实际工作中，我们不能为了证明老板的判断，或者为了保持自己之前“拍脑袋”的英明形象而去进行数据分析。

第三，平时不烧香，临时抱佛脚。

这是一个很实际的问题，我们经常在做决策的时候才想起数据分析，但忽然发现手头没有数据可分析。一次又一次地发生同样的情况……为了避免这类问题，我们应该在产品设计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等。这也是一种典型的非功能需求，这样做对产品的可持续发展非常必要。

日志分析的商业价值

下面举个小例子，看看数据分析是如何转化为商业价值的。将数据转化为商业价值的整体思路是：在对产品足够熟悉的基础上先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。

2008年年底的时候，我们希望产品的用户能更活跃，活跃的衡量指标是更多的登录次数。这一方向确定之后，我们假设有方法可以促使某类用户更多地登录，于是对产品的用户登录日志^[41]做了一些分析，希望找到方法和对应的用户。结果，发现了一条很有趣的曲线，如图2-7所示。

图2-7　用户登录产品的情况^[42]

图中的横轴是把所有付费用户的第一次登录日期对齐，表示用户从这一天开始使用产品，查看他们在此之后半年，也就是180天的活跃情况；纵轴是这几千家公司的总体活跃情况，可以简单地理解成纵轴数值越高，用户登录次数越多。可以看到，活跃公司所占比例的变化情况明显分为四个阶段，特别是1～4个月之间出现了先下降再上升的现象，我们先试着解释：

该产品是通过经销商销售的，在卖出去之后，经销商在前期也会登录产品，帮助用户做一些初始化产品的工作，所以产品的登录行为有经销商登录和用户登录两部分，虽然通过已有的数据无法区分这两种行为，但它们确实各有特点。

第一阶段：第1个月，活跃公司所占比例考察的是1个月内用户的登录次数，所以30天内活跃公司所占比例不断上升达到峰值，约60%。这段时间内，经销商登录次数较多，帮助用户初始化，用户的登录次数缓慢增加。

第二阶段：第1～3个月，活跃公司所占比例缓慢下降到约40%，其中包含两部分，经销商行为和用户行为。

►经销商登录次数逐渐减少，导致这条曲线只有一个趋势：衰减，这个衰减绝对比图中的更陡峭。

►用户登录行为有两种趋势：衰减与增加，从第三阶段可以看出增加是大于衰减的。

第三阶段：第3～4个月，活跃公司所占比例逐渐上升到60%，这是因为到3个月之后，几乎再没有经销商登录行为了，完全是用户登录，并且经过两个月的使用，用户已经通过产品体会到了实际的商业价值，所以登录产品并使用的行为越来越多。

第四阶段：第4个月以后，活跃公司所占比例稳定在60%左右，进入动态平衡期，用户使用产品的情况不再有大变化。

上面这些解释，完全是我们根据对用户的认识主观做出的判断，为了验证上述观点，接下来我们做了用户访谈，采取了两种形式——先电话调研、然后有选择地登门拜访，试图区分出经销商登录和用户登录的不同。果然让我们发现，两种人群的主要登录入口不同，经销商通常从A入口登录，因为他们要做的初始化操作从这里进去方便，而用户通常从B入口登录，因为日常操作更多在这里。

由此启发，我们深挖了某段时间内从不同入口登录的日志，验证了用户的说法。于是，我们分离出了经销商和用户两种登录行为的曲线，如图2-8所示。

图2-8　用户登录与经销商登录行为曲线

这么“劳民伤财”的分析，商业价值在哪里呢？

一方面，我们会考核每个经销商下面的用户活跃度，目的当然是为了让他们更多地服务用户、指导用户使用，但有的经销商会耍小聪明，自己登录来忽悠我们。原来我们很苦恼，现在可以通过分析登录行为，对这种情况做一个初步的判断。事实上我们后来就对不同入口的登录行为、同一台电脑登录多个用户账号的行为做了跟踪。如果某些用户登录次数的增加是以A入口为主，或者是某时间段同一台电脑登录多个用户账号，再关联这些用户的经销商进行分析，就能够找出作弊的经销商，以示惩戒。这样一来就增加了经销商作弊的成本。

另一方面，这次分析告诉我们，对我们有实际意义的是B入口用户的登录，所以产品的优化重点应该放在B入口。另一个数据也证明了上面的推论：有某种登录行为的群体，在出现该行为后几个月的活跃度情况如表2-2所示。基本上出现过“B入口登录”行为的用户，之后的活跃度就会很高，这些是真正的用户登录。这次数据分析最终指导了产品改进。后来，我们对B入口登录做了很多引导，比如降低门槛，运营推广，在宣传手册、光盘上重点说明等，这些都起到了很好的效果，用户活跃度真真切切地上去了。

表2-2　登录行为与若干个月后的活跃度

在此次用户研究的过程中，我们抽取了近100个样本，电话有效沟通了30多例，上门拜访了10例，用户所在行业涉及机械、纺织、五金、建筑、服饰等，比较全面，考虑到上门成本问题，所以只在杭州、常熟两地进行。从决定调研开始，加上前期的准备、后期的总结，总共花了15人天，也就是两个人7.5天的时间。整理报销费用的时候，我简单算了一下，上门采访的用户礼品平均每家50元，差旅费用均摊下来，大约每家150元，人力成本1人天粗略记为500元，平均分摊给最终上门的10家用户，每家大约需要1000元人民币，不算不知道，确实挺贵的……这还只是很简单的调研，所以用户研究的成本真的很高。很多小公司都能省则省，我们很无奈，老板也很无奈，以后在抱怨老板没用户研究意识的时候，也需要体谅一下他们的难处。

2.2.4　需求采集人人有责

前文用很大篇幅说了一些常用的需求采集方法，这一节，我想先抛出一个“一手需求与二手需求”的概念。^[43]

有个很形象的比喻就是“生孩子与养孩子”。我们首先把“生孩子”——需求采集视为己任，希望所有人都参与。这就要给他们一个简单的“生孩子”的工具——“单项需求卡片”。本书最后会简单介绍一下其他常用的方法，这样才能做到“尽可能多地采集”。

生孩子与养孩子

之前所述的各种方法，都是直接从用户那里获得需求，我称之为一手需求，就像“生孩子”。很多时候，我们还会接受二手需求，比如老板说要给用户做个××功能、销售人员说用户哪里用起来不顺等，这些需求和一手需求比起来，就像“养孩子”。

“生孩子”更多的时候发生在新产品诞生前，这时候外部没有用户，内部没有运营、销售、服务人员等，所以更多的是依靠产品人员去主动采集需求，比较常见的方法就是直接去潜在的目标用户那里采集。

而“养孩子”通常发生在产品已经运行了一段时间以后，用户也有了，公司内部也多了很多相关的人员，比如销售和服务人员。虽然产品部门与用户的直接接触变少，但多了很多间接来源，即与终端用户接触的干系人，他们会向你反馈很多需求。此时，用户也开始主动提出需求了。

对比一下，“生孩子”的时候，我们去主动“拉”需求的比例较高，需求都是直接从用户那里得到的，有点“进攻”的感觉。“孩子生出来”以后，就不再是你一个人的“孩子”了，必然是大家一起“养”，所以我们需要照顾到各个方面，并且会收到很多“推”过来的需求，比较像“防守”的感觉。

有很多读者从一开始工作接触的就是已经存在的老产品，需求始终堆积如山。如果碰上销售占据强势地位的产品，光销售人员提过来的需求都来不及响应。也许做了半年一年，突然回想，发现自己连真正的用户都没有接触过，而是始终在满足销售的需求。这种二手需求，或多或少有些扭曲。以销售人员为例，考核指标决定了他们会比较注重眼前利益，希望产品的卖点越多越好，而之后用户用得如何，就不那么关心了。比如我就经历过一些让人很抓狂的二手需求：销售希望产品增加一个功能，这个功能在说服客户购买产品时有“临门一脚”的作用；而用户买完以后，销售又希望用户最好别用这个功能，以免增加服务部门的压力……所以在公司层面上看，产品部门至少应该和销售、服务等部门有平等的地位，坚持不懈地从终端用户那里直接获得需求，才能保证产品的可持续发展，或者用流行一点的说法，叫“接地气”。[延伸阅读8]

但接收二手需求毕竟是常态，我们经常收到的可能是口头的几句话，或者一封邮件的几行说明，这中间理解的偏差只能靠我们主动地、反复地沟通来弥补，那么有没有什么办法解决呢？下面我就介绍一种简单的二手需求采集工具——单项需求卡片。

单项需求卡片

一张单项需求卡片描述了一个用户的需求到底包含哪些内容，重点是描述用户场景，谁在什么时间、地点产生了何种需求。

单项需求卡片的理念是：产品的需求工作不只是需求分析人员的事，也是产品的每个干系人应该完成的义务，至少得参与“采集”的过程，理想的状态是产品的所有干系人都参加过“需求采集”的培训，然后在日常工作中养成主动提交需求给产品人员的习惯，但在实际工作中很难做到，所以作为专业的需求分析人员，就应该尽量降低同事们，比如销售、服务、技术人员提交需求的成本，也是在节省我们自己的时间。

单项需求卡片的模板，如表2-3所示。

表2-3　单项需求卡片模板

由于填写卡片的人经常不是专业的需求人员，所以卡片的质量无法保证，比如下面这个例子就是一个典型，如图2-9所示。

图2-9　单项需求卡片实例

图2-9是工程师提的一个需求。“单项需求卡片”原本是让大家给产品提需求，而工程师却拿它来给产品经理提意见。从这份表格就可以看出来，实际工作中我们能拿到的大部分卡片都是填写不完整的，甚至是字迹难以辨认的。当然，也可以尝试电子版，或者直接用某些需求管理系统，那样我们整理卡片的成本低一些，不过这样一来很可能愿意填的人就少了。我们心里得有个底线，一张有价值的单项需求卡片，至少得有“需求描述”，需求编号、来源、场景最好也能有，其他的就很少有人愿意填写了。

每当我们拿到卡片，就需要主动去和提交人交流，完善卡片的内容。在真实的工作中你能体会到，这张卡片只是需求过程的中间产物，所以我们在这上面花费的精力也要尽量缩减。单项需求卡片所描述的用户需求，最终要转化为产品需求才有真正的价值。

尽可能多地采集

需求采集，并不是产品设计之前的工作，而是一个贯穿产品生命周期的过程。它不只是产品人员的事情，而是所有人的责任。它没有特定的方法，“不管白猫黑猫，抓到老鼠就是好猫”。它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求……这才是需求采集的大生产运动。

最后再简单分享几个有特点的需求采集方法，希望大家能灵活应用，尽可能多地采集。

现场调查。说简单一点就是打入“敌人”内部，和客户一起工作一段时间，深入了解需求。它是一种典型的定性分析，持续时间长，从几个小时到几个月不等。现场调查既能听到用户怎么说，也能看到用户怎么做。不过，它的受众面极其狭窄，一次只能针对一个客户开展，我们要特别小心被“非典型”用户带到沟里去。

AB测试。同时做方案A和方案B，并应用在不同的用户身上，然后根据反馈再做下一步决定，这个方法比较适合用户量大的产品。比如有一个按钮不知道放在页面的左边好还是右边好，那就先随机挑选少量的用户发布这个按钮。如果我们有10万个用户，就挑选1000个用户放左边，1000个用户放右边，然后过一段时间分析结果，再决定剩下98%的用户该怎么办。很明显，这也是让用户直接参与了设计过程，这样低成本的方法让很多传统行业的产品同行羡慕不已。

日记研究。即去阅读分析用户写的关于产品的文章。它比较适合新兴的互联网个人应用。某个新产品出来以后，很多业内的朋友都会去尝试，然后写一些使用体会。但产品设计者在看这些日记的时候，要明白日记的作者往往是同行，而不是主流用户。

卡片分类法。我们把产品的各种需求写在便利贴上，让用户一起讨论并完成分类。这能让你深入了解用户是怎么给产品划分模块的，以及用户认为这个网站应该是什么样的结构。因为产品设计人员的思维方式和用户的思维方式通常不一样，如果是产品设计师来单方面决定网站结构的话，很可能导致用户理解上的困难^[44]，所以卡片分类法能让最终的产品更加符合用户的心理模型。

自己提需求。这是最简单的方法。我们可以通过自己多用相关的产品，多看相关的报告来发现需求。比如，每一个靠谱的产品都会有一群粉丝用户，即使我们不刻意去找他们采集需求，他们也会给我们惊喜，主动提出很多需求。作为产品的主人，我们难道还没有用户了解产品吗？产品要用才能感觉出好坏，特别是自己做的产品。产品做多了，我们看到别人做的产品，总能一下子挑出很多问题，反过来看自己的产品却越看越完美，这一定有问题。所以，必须不断使用自己的产品，从中发出产品的不足，才能帮助我们激活成功教程这种敝帚自珍的情结。

需求采集的各种新方法层出不穷。和学习任何领域的知识一样，建议大家在了解知识的框架后，坚持“需求驱动学习”。

2.3　需求分析：听用户的但不要照着做

我们采集了很多需求，但是一团乱麻，从哪里着手？

用户都帮我们想好该怎么做了，照他说的做吗？

在开始需求分析之前，我们先回到2007年7月——我写了一篇里程碑意义的博文，是“产品设计体会”系列文章的第一篇，在这篇文章中，我总结了自己对需求的看法：

2007年6月28日，网店版2.0上线，这是我主导的第一个付费产品，之后的三周我基本天天都会在淘宝论坛上泡不少时间，最大的体会就是：要听用户的意见，但不要照着做。

有的用户很“危险”，在提意见的同时还说你们应该做成什么样子，这时候产品经理一定要头脑清醒，用户提的解决方案往往是站在自己的立场上考虑的。比如对“快递单打印”的功能，用户提出要添加一个他经常用的小快递公司的快递单模板，而我们调查发现，这家快递公司只在一个区域内运营，最终针对这个需求，我们的解决方案是做一个“自定义快递单”的功能。

有时候，用户给出的做法存在明显的逻辑矛盾，就算他给出的解决方案合理，也要再深挖用户最根本的需求，比如用户描述“新建非支付宝交易订单的时候必须要选择用户不合理，希望能自己填写客户姓名”。这里更深层的需求就可能是他需要把线下客户也管理起来，所以我们或许更应该做一个新增线下客户的功能，而不是在新建非支付宝交易的时候让用户自己填写客户姓名。

我们是产品经理，最终怎么做应该由我们决定。

2.3.1　明确我们存在的价值

用户跟福特要一匹更快的马，福特却给了用户一辆车。

这就是我们存在的价值。还记得第1章中的小明吗？

小明说他需要一个电钻，这是他提出的解决方案，但在大毛的刨根问底之下，发现小明其实想要的是一种温馨的家的感觉，有了这个认识，我们就可以给出很多产品来满足。比如卖他一套实施方案，带着电钻、油画上门安装；比如用背面有强力胶的钩子挂画；比如直接把画黏在墙上；比如直接在墙上画，并且让小明自己画；再比如放一组书架在那里……经过我们分析得到的解决方案，比起小明自己说的，优势就在于可能省了钱、省了时间、更温馨，等等。

对同一个问题，这两套解决方案的区别就是：一个是用户需求，一个是产品需求^[45]。而这中间的转化过程，就是这节的主题——需求分析。

用户需求VS产品需求

用户需求：用户自以为的需求，并且经常被用户表达为解决方案。

产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。

需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。^[46]

需求分析与常见的技术分析最大的不同是思路的本质差异，技术分析是“树干——树枝——树叶”的任务分解过程，技术人员很适应并乐于用这种方式思考，可以把大问题分解成小问题，发现难点逐一攻克。不少需求人员都是做技术出身的，所以开始往往会用这种思路做需求，听到客户提出的功能点，直接想怎么做系统设计了，这导致有时候需求分析甚至已经具体到“详细设计”了。大多数人在生活中也习惯于用这样的思路来对付问题，而真实情况是，需求分析是先“树叶—树枝—树干”，再“树干—树枝—树叶”的过程。也就是说，完整的需求分析是一个“分—总—分”的过程。一方面不能漏掉提炼用户需求的这个过程，它的目的是透过现象看本质[延伸阅读10]；另一方面也不能停在本质上，试想如果做到“树干”就结束，后端的执行人员可能还是不知道要做什么东西，所以我们还要继续把树干再重新分解成树枝、树叶。我们可以通过下面的小故事来加深理解：

小明又出现了，这次他说要吃猪骨头火锅（用户需求），预计消费80块，但没想到又碰到了大毛。

“真的想吃？”

“想吃！”

“为什么？”

“我饿了……”（找到了本质！）

“哦，这里是两个馒头（产品需求），请你吃，才1块钱。”

“……”

小明无比不爽，但没办法，真的饿，还是吃了。

大毛是这样分析的，想吃猪骨头火锅，这个用户需求无非两个原因——饿了或者馋了。如果他真的是馋了，那就吃吧，不过如果是饿了，那我完全可以用一个低成本的解决方案——馒头。虽然小明眉头紧锁，但现在经济不景气，毕竟节省了98.75%的成本啊！

伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西，这就是我们存在的价值。

销售人员经常说：“用户为想要的东西买单，而不是需要的”，用上文的分析思路来理解，其实是“用户为自己提出的解决方案买单，而不是我们的解决方案”。那我们为什么不直接做用户要我们做的呢？

其实这是短期利益和长期利益的权衡。如果是一锤子买卖，卖出以后又不用负责售后，那么不妨用户要什么就给他什么，这样用户掏钱最爽快。这种情况下追求的就是短期利益。但是，我们的产品通常都是希望用户长期使用的，并且后续的服务也是我们来做，所以为了长期利益，我们就有必要找到用户的真实需求，然后给他真正合适的产品，哪怕这个过程不那么顺利。

满足需求的三种方式

我们通过产品需求来满足用户，这意味着我们要做一些用户真正需要的功能或服务，虽然在字面上这是最直接的理解，但在实际工作中，它也是最“劳民伤财”的。在甩开膀子干活前，我们有必要扩展一下思路，从问题的本质出发，寻找新路。

之前我们说过，需求来源于理想与现实的差距，那么减小这个差距就有三种方法：

►提高现实。我们最常用的方法，去开发某种产品，但也是最笨的方法。

►降低理想。“打预防针”“丑话说在前头”这类句子想必大家都经常听到。

►转移需求。因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会觉得这个差距没那么可憎了。人的行为是需求驱动的，想改变人的行为，可以寻找更强烈的需求展现给用户，让他不再纠结于原来的需求。

给大家说一个写字楼电梯的故事。

某写字楼因为建造时间较早，考虑不周，电梯明显不够用，每天中午吃饭的时候总是很挤，最上面几层的小白领们平均要等20分钟才能下到3楼的餐厅吃饭，于是抱怨很多，他们给物业提意见，要求解决。物业公司找到了大毛，大毛帮他们分析了一下。

提高现实。对现有产品做一些改进，在这个案例中就是增加电梯数目，或者加快电梯运行速度，但成本太高，直接被否定。

降低理想。告诉楼里的小白领们，隔壁那个写字楼中午要等40分钟呢。俗话说“不患寡而患不均”，人们更在意的是相对而不是绝对，这样确实可以减少抱怨，但是低水平的需求满足对提高产品美誉度没有帮助。这种方法要慎用。

转移需求。电梯门上贴一些锻炼身体的公益广告，内容是说爬楼有益身体健康。这样做的效果不错，部分用户走楼梯去餐厅了。但是刚吃过饭怎么办？最后，大毛采用了一个看起来很傻的方案，在电梯门旁边安装一面镜子，让等待的人们可以整理一下仪表，或者搔首弄姿一番，不至于那么无聊。

我们后来发现还有其他的解决方案，比如电梯广告，不但可以转移用户注意力，减少抱怨，而且对写字楼来说，既不用花钱，又额外挣得一笔广告费；又如错开午饭时间，让人们的等待时间都更少。满足用户的需求，不一定要做新产品或者新功能，而是更应该想想是否有“四两拨千斤”的妙招。

也谈创造需求

我们开阔了思路以后，认识到有多种满足需求的方式。但这些做法的基础都是用户提出来的需求，我们的思路能不能再开阔一点？比如直接达到产品设计的最高境界——创造需求！

工作中典型的需求设计创意大多来自老板或者产品人员的突发奇想，这些灵感在潜意识里都有一定的依据，是基于我们对用户、市场、产品的充分理解。虽然有些创意最终获得了用户的认可，但更多的创意却被证明过于天马行空。

后来，我认为更准确的说法其实是——我们无法创造需求，但是可以创造性地满足用户的需求。

苹果公司的乔布斯，可以说是创造需求的大师，但这是需要天赋的。这份天赋非常值得保护，产品的进化和生物的进化一样，需要如基因突变一般的胡思乱想。

在实际工作中，我认为需求分析的过程其实也有创造需求的成分，当一个新人能力尚且不足时，不妨先做用户提出的需求，而不要自己去胡乱分析，创造用户需求。对于一个团队来说，要尽量避免“只有能力不足的需求分析人员”这种情况出现。

我们刚上路，既要怀揣梦想，也要脚踏实地。接下来我们老老实实地开始给需求做一次“DNA检测”。

2.3.2　给需求做一次“DNA检测”

需求的“DNA检测”过程如图2-10所示，我们先把用户需求转化为产品需求，然后一步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。

这里确定的是产品需求的各种属性，不同于之前提到的“单项需求卡片”里描述的用户需求的各种属性。

把用户需求转化为产品需求

检测的第一步就是“需求转化”。我们有很多用户需求，可能记录在“单项需求卡片”里，可能记录在Excel里，可能是用Word随意写的几段话，也可能是一张思维导图，如图2-11所示。现在我们就要发挥出“我们存在的价值”，在这个阶段，团队经常举行头脑风暴^[47]，大家天马行空地讨论一番之后，对用户提出的需求有了比较全面的了解，对用户的内心世界有了比较统一的认识，对我们的解决方案也有了一些不成熟的想法，然后每个人负责各自的模块，把它们都转化为产品需求，最后记录在一起。

图2-11　网店版的一部分用户需求

举个例子，如果用户需求是“删除数据之前需要我确认，以免误删”，转化分析以后，我们给出的产品需求可能是“数据回收站：删除的数据进入回收站，如果是误删，用户可以去回收站找回数据”。

整理好的产品需求列表如图2-12所示（因为有商业隐私问题，所以我把具体内容弱化了）。我们把它叫作Feature List（功能列表）。

表格中每一行是一个产品需求，而每一列描述了产品需求的一种属性。

用户需求与产品需求是多对多的关系。我们可以用多个功能来满足一个用户需求，也可以用一个功能来满足多个用户需求，甚至是用几个产品需求来交叉满足几个用户需求。

图2-12　产品需求的列表

对任何产品来说，只要需求采集的工作做足了，我们就会发现产品需求列表的行数很多。在需求转化过程中，我们也会做一轮筛选，把明显不靠谱的用户需求直接过滤掉，不计入上述列表。当然，是否“明显不靠谱”就要由我们自己来把握了，不要把“没资源做”“短期内有技术难点”的用户需求给错杀了。

确定需求的基本属性

关于产品需求列表的维护，有时候我们是在产品团队里指定一个人负责，所有的需求都由他来录入；有时候是采取共享文档的形式，大家共同维护，更多相关话题我会在3.5.1节的“多人协作与版本管理”中和大家讨论，但不管怎样，我觉得对于每个需求，提交人都可以独立确定一些基本属性，这些属性如表2-4所示。

表2-4　需求的基本属性（*标注为必填项）

编号：看似作用不大，实际非常有用。有一次大家把列表打印出来讨论，当提到某个需求的时候，我发现很难告诉大家是哪个，因为Excel的行号没有一并打印出来，后来我们都把编号加上，作为需求的唯一性标识。有时候在某个需求的备注里，也会写“与273号需求类似，可以参考”。

提交人：这是必填项。提交人是PD本人。我们的需求管理方法是轻量级的，更多时候只是管理产品需求，而对于用户需求，我们并没有很好地进行整理，经常只是一堆各种格式的文档。所以，提交人要负责在今后的任何时候解释这个需求的来源，并且有义务充分理解原始的用户需求。

提交时间：这是一个辅助信息，记录提交人是何时录入这个需求的。

模块：一般来说，根据人类记忆的特点，产品有5±2个模块比较合理，如果超过7个，你就要考虑重新划分，甚至增加一个基本属性叫“二级模块”。如果做的是网站产品，这些模块的划分就很可能影响到网站的导航结构，这属于信息架构^[48]领域的知识。在设置自己电脑里的文件目录结构时，我们也可以遵循这个原则。

举个例子，如图2-13的网店版菜单结构，就可以从其产品需求列表里的“模块”设置里看出来。

名称：用简洁的短语描述需求，要给用户提供什么功能，比如黑名单。

描述：具体解释一下名称里说的功能是什么意思。比如用户可以选择某个联系人并将其加入黑名单，在黑名单里的联系人将无法给该用户发消息；用户也可以将某联系人移出黑名单。描述模块中只要说明此功能要做什么，无须解释怎么做。另外要注意语言的无歧义性、完整性、一致性和可测试性等，关于具体怎么写，可以参考3.3.1节中“概要设计与详细设计”里的讲解。

图2-13　网店版的需求模块与菜单结构

提出者：即用户需求的提出者，对需求有疑惑时便于更进一步追溯。

提出时间：原始需求的提出时间，区别于提交时间，这是个辅助信息。

Bug编号：这是一个可选项，因为我们把产品的某些Bug也视为需求，所以加入这个表格统一管理。当然，你也可以用其他方法来专门管理Bug。

上述只是我在需求管理时常用的基本属性，为了便于管理需求，大家可以按照自己产品的不同特性自由定义。上文例子中的表2-4是一个简化方案，在实际工作中，我们还可以借助一些更专业的需求管理软件来确定需求属性。

需求种类知多少

确定需求的基本属性后，需求的提出者需要自己辨别一下这个需求的种类，为后续的商业价值判断提供一些辅助信息。我们尝试过两个维度，如表2-5所示。

表2-5　需求的种类

分类：可以分为新增功能、功能改进、体验提升、Bug修复、内部需求等。

其实产品需求不仅仅包括我们可以直接想到的功能需求，还包括了很多非功能需求，比如：性能、可培训、可维护、可扩展……有很多需求不是为终端用户做的，而是为销售、服务、测试团队的同事做的。

举几个例子，“论坛需要支持1000人同时在线”，这是一个性能需求；“系统功能升级，必须在发布2周前完成对客服部门的培训”，这是一个培训需求；“如果硬件压力突增，应该有报警，具体细节是……”，这是一个运维部门的维护需求；“在用户数增加10倍的情况下，硬件投入必须小于10倍”，这是一个可扩展需求；“此功能的用户操作日志需要记录”，这是一个内部数据分析的需求。

当然，对于一些边缘的需求，是将它们列入这个表格统一管理，还是另外单独对付，可以随机应变。

通常来说“产品功能需求+产品非功能需求=产品需求”，而“产品需求+市场需求+开发需求+测试需求+服务需求+……=产品包需求”，对这些概念感兴趣的读者可以去查阅“需求管理”相关的资料。

层次：把需求分成基础、扩展（期望需求）、增值（兴奋需求）三层，理论依据参见KANO模型^[49]。

小明：“我想到一个手机的例子，打电话、发短信是基本功能；给电话录音是扩展功能，和基本功能相关；而如果这个电话特别结实，可以当锤子砸钉子，或者当砖头防身，那就是增值功能了。”

大毛：“嗯，好多山寨手机的特点就在于满足了一些诡异的增值需求，比如可以当手电筒、当验钞机、当剃须刀……”

小明：“你是在夸还是在贬呢？”

大毛：“我也不知道，那些已经超出普通手机的范畴了……”

需求种类的区分标准其实没那么绝对，它取决于很多因素，比如商业目的的变化。有时随着时间的推移，某个功能的分类也会发生改变。对于这个问题，可以从“雪中送炭”还是“锦上添花”的角度去理解：“雪中送炭”的功能是基本功能，对用户很有用，产品缺了这个功能根本跑不起来，比如E-mail系统里的“收发邮件”；“锦上添花”的功能是指非必需的功能。用户有时用得到，有这个功能的话会给用户的使用带来方便，比如在填写E-mail收件人的时候，系统根据你输入的内容自动提示你曾经发送过邮件的联系人，如图2-14所示。

我们在和用户接触的过程中会很明显地感受到这两种需求的不同。没有“雪中送炭”功能的产品就是有缺陷的系统，所以它应被优先考虑；而当一个“锦上添花”的功能被用户普遍接受以后，几乎所有的产品也都拥有了，也就渐渐提升为“雪中送炭”的功能了，比如现在彩屏手机普及之后，几乎没有人能接受黑白屏的手机一样。

图2-14　GmaiI的收件人提示功能

分析需求的商业价值

一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的，所以“需求的商业价值”是最关键的内容，有条件的团队最好利用群体智慧来确定。我们通常在这个时候举行“需求讨论会”。

正因为商业价值如此重要[延伸阅读11]，所以我们用重要性、紧急度、持续时间3个指标来衡量，如表2-6所示。

表2-6　需求的商业价值

重要性：可以参考时间管理里“重要与紧急”的概念。这里的重要性又可细分为满足后“一般”到“非常高兴”；未实现时“略感遗憾”到“非常懊恼”，通过学习KANO模型加深理解如何制定重要性指标。

紧急度：在时间维度上判断这个需求是否迫切，紧急不重要的需求通常表现为短期的、对产品长期影响不大的问题；或者是局部的、对大多数用户没有影响的问题。比如某个用户是大老板的朋友，通过大老板“天外飞仙”地提过来一个需求，就很可能是一个超级紧急的需求，但重要性未必很高。

持续时间：需求是有生命周期的。迎合过年过节的运营活动需求的周期就比较短。比如8月我们录入了一个国庆的主题运营活动，如果到了9月底还没有资源做，那一年内也就不用再考虑这个需求了。

商业价值，或者叫商业优先级，是对上述几种商业价值指标的综合评判。这一条是整个需求列表中最核心的部分，这里的判断直接影响着产品未来的方向。所以，我们在列表里增加了一行“商业价值”。按照通俗的理解，“商业价值”就是这个需求的卖点是什么，可以给用户提供什么价值，对公司又有什么帮助。

如此重要的商业价值评估，我们的做法是在需求讨论会上由产品团队集体讨论，再叫上有必要的干系人，比如销售、服务人员等。对于某个需求，需求提交人对它最熟悉，所以讨论会上提交人先基于自己对商业目标的理解做一番陈述，从主观上判断该需求的级别，比如高、中、低等不同等级。在这个讨论会之前，每个人都应该做好功课。

上述3项指标可以经过加权平均后得到综合的商业价值，我们甚至还可以在列表中增加一项“某关键人物的打分”，在绝大多数的实际操作中，我们都会直接把商业价值抽象为一个指标，用“高、中、低”，或者“5、4、3、2、1”来衡量。而具体讨论的时候，大家充分表达意见之后，可以由团队负责人或者老板来决定商业价值的高低，这是一种高效的办法。我曾经考虑过群体打分取均值等方式，可是实施起来成本太高。

初评需求的实现难度

绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。

我们知道了每个需求的商业价值后，接下来决定做哪个还需要另一个关键指标，那就是实现难度。有时候我们会叫上技术人员代表参与需求讨论会，当场确定这个指标，但更多情况下会留给做技术的同事一点时间，会后与相关的PD讨论确定。

但实现难度太难量化，所以在实际操作中我们会对它进行大刀阔斧的简化。

首先简化为人力成本，即工作量。至于其他资源的消耗，比如额外的硬件成本，只有极少数的需求会有这样的问题，它不具有普遍性，所以碰到的时候我们可以做特例处理。

其次，我们把工作量再简化为开发量。我们工作中有产品人员、开发人员、测试人员、服务人员等人力资源。但一般情况下，团队里产品人员相对弹性，测试人员可以调配，服务人员可以临时补充，但是开发人员经常成为瓶颈。于是，我们一般评估每个需求所需要的开发工程师工作量来表征其实现难度，也就是以团队里的瓶颈资源为评估基准，如表2-7所示，大家视自己团队的情况灵活应用。

表2-7　需求的开发量

在这个时候，需求其实并不明确，往往只是一条“要做什么”的要点，而具体怎么做根本还没有考虑，所以有的技术人员会觉得无法评估开发量，这很正常。对于技术人员来说，产品部门不明确每个需求怎么做，他们就无法准确评估开发量，而产品人员又没那么多时间明确每个需求该怎么做，技术部门不评估每个需求的开发量，产品就不知道哪些值得进一步分析怎么做，而哪些又不值得……在实际工作中，我们不必在这类矛盾的问题上纠缠过多，下面是我的做法。

开发量是非评估不可的，我把它叫作“初评”。初评的开发量允许误差，并且会由经验丰富的人来评估，通常是技术经理，或者系统分析师、架构师。他们做出简单的评估，并且靠不断的实践来反复修正。此时的评估一般用“人天”作为单位，比如某个需求需要“2人天”意味着需要1个人做2个工作日，或者2个人做1个工作日。

初评时常用的方法是“三点估算法”，即评估出最乐观的工作量、最悲观的工作量、最可能的工作量，然后按下面的公式估算出工作量：

“工作量=（最乐观+最悲观+最可能）/3”

或“工作量=（最乐观+最悲观+最可能×4）/6”

在项目启动之后，制定项目开发计划的时候还会有一次更精确的评估，那时候已经知道需求要怎么做、由哪位开发工程师来做，所以可以推算出相对准确的工期。

工期和工作量有很大的区别。比如生一个小孩需要1个女人9个月的时间，工作量可以说“9人月”，但9个女人1个月的时间，同样的“9人月”却是绝对完成不了这个任务的，所以不管几个人，这项工作的工期都只能是9个月。

判断需求的性价比

我们已经做了需求采集，把用户需求转化为产品需求，知道了某个需求的基本属性、种类、商业价值、开发量，现在似乎应该开始写文档干活了，但经验告诉我们不是这样的：

绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。

一个实际的例子：

我做过的某个产品页面的访客，在2009年某段时间内使用各种网页浏览器的比例如图2-15所示，第一名是微软的IE，99.14%（其中IE 6.0又占75%）；第二名Firefox，0.45%……^[50]

图2-15　某产品页面的浏览器使用情况

对应的需求是：“产品页面在Firefox下显示有问题，比如……”，而我在注释里写道“对不起，我们就是不支持Firefox”。当然，这句话是写给自己人看的，千万别对用户讲。

这个需求实现难度不大，但一直在功能列表里放着。说实话，能在列表里出现的需求，严格意义上讲，没有任何一个是没有价值的，也没有任何一个是做不了的，那么到底先做哪个，后做哪个？

就像在2.1.1节中就谈到的那句话：“不要试图满足所有用户”，一切皆看性价比。

做了那么多的准备工作，现在我们只要做一道简单的小学算术题就可以回答上面的问题了。

性价比=商业价值÷实现难度（简化为开发量）

现在可以做决定了，我们把产品需求列表按照“性价比”从大到小排序，先做排在上面的就可以了，如表2-8所示。

表2-8　需求的性价比

尽管可以清晰量化性价比指标，但是我们在工作中对“性价比”的判断还是会经常有偏差。一个很实际的因素是我们经常受哪类人的影响。2007年下半年的工作中，由于我一直和工程师直接接触，经常听到他们抱怨某个需求太麻烦之类的话，所以综合考虑时有点倾向于做实现难度小的需求；而如果经常和销售、运营的同事一起开会，就会倾向于更多地考虑商业价值。这点我们需要时刻注意。

道理说完了，对需求的“DNA检测”也暂告一个段落，接下来我们将迎来一场残酷的“战争”。

2.4　需求筛选：活下来的永远是少数

这是一场公司内部的战争，每个产品的产品经理都要上场，我们争夺的是下个月的人力资源，即总是不够用的开发工程师、测试工程师等。战场就是令人闻之色变的产品会议，而我们手上的武器，则是精心准备的商业需求文档。我越来越觉得，为了我们的产品，有些需求死得其所。

这个过程，就是需求筛选，也有个很传神的说法：需求PK。如图2-16所示。

图2-16　需求筛选

2.4.1　永远忘不掉的那场战争

为什么原来没有这样的战争？

更早的时候，阿里巴巴是按照产品线划分部门的。某个产品有自己的产品设计师、开发与测试人员等。下一段时间要做哪些需求，完全可以在产品经理的层面上决定。在分析商业价值的需求讨论会上，我们也就顺带着确定了下一段时间做哪些事情。

为什么后来有战争了？

2008年年初，阿里软件进行结构调整，变成了按职能线划分团队：产品中心包括所有的产品经理和设计师，研发中心包括所有的开发工程师、架构师等，质控中心包括所有的测试工程师……这样的话，每个产品还是由原来的产品人员做，但是开发与测试资源在一定程度上就有了流动的可能。每个产品想做的需求都很多，所以产品经理都想尽可能多地抢到开发与测试的资源。然而人力资源总是严重不足的，所以最终把资源投给哪个产品，就必须由几个中心的大老板来决定了，而大老板的决策依据就是各个产品团队制作的商业需求文档。

按产品线划分的团队对产品本身是有利的。产品经理权力更大，可以按照自己的想法做。不但资源有保证，产品规划也不容易被改变。此外，各种职能的员工之间沟通顺畅，开发的领导、测试的领导等都对产品经理负责。

按职能线划分的团队对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高。由于产品规划的决策需要在更高层面上敲定，单个产品的发展速度会有所降低。但是，资源战争可以把“鲶鱼效应^[51]”从产品内部扩大到公司层面，使产品经理和设计师们更抓狂地为产品的发展而苦苦思索，这是一件好事。

两种组织结构，呈现“一攻一守”的不同面貌。在创业期，公司需要全速发展，必然是产品线结构，产品经理带头往前冲。而当公司里有多个产品慢慢成熟之后，就可以用职能线来更充分地利用资源。因为在成熟的产品团队中，要做的事情通常比创业时期少，或者没那么急，那么各种资源就显得有富裕，可以更加稳扎稳打，所以按职能线划分团队可以实现资源共享，同时还可以促进不同产品团队之间的互相学习，让员工的个人能力得到更多的提升。

准备出发：把需求打个包

上战场之前，就像战士要把自己的物品打包一样，我们对需求也要打包。

做项目，终极目标就是：多快好省^[52]，即范围大、时间短、品质高、资源省。

但“又要马儿跑又想马儿不吃草”的事情是没有的，所以我们通常是在上述4个要求中做平衡。我负责过的互联网、软件项目，都比较推崇敏捷方法^[53]，它们都有比较固定的项目时间，专业说法叫“迭代周期”，一般是2～4周。同时，我们有一个人员相对固定的团队，意味着项目资源确定。此外，任何时候我们都要保证项目品质，最后可以改变的只能是项目范围。

我们确定了项目时间长短，也就意味着可以估计出留给开发的时间，而团队里有多少开发工程师也是相对固定的，所以我们可以直接算出有多少“可用工作量”，同样以“人天”为单位。上一节中我们把产品需求列表按照“性价比”从大到小进行了排序。如果从上往下看，每一行后面都还对应着一个“工作量”。现在我们只要做一个简单的加法，将每一行需求从上到下依次纳入项目，我们把这个动作叫“需求打包”。而对这些需求的整体描述，即商业需求文档里的功能说明。

当然，这只是一个基准，可变因素很多。我们每次产品会议都要准备好几个项目让大老板们选，每个项目也有可能在产品会议上被砍掉部分需求，所以可以先相对随意地超出“可用工作量”。

这个过程完全定量地回答了“做多少”的问题。但到了实际操作中又要复杂很多，下面说几个需要注意的地方。

第一，“需求打包”最好打包类似的功能点。一般来说业务上逻辑关系密切的需求才会被包含在一个项目里，实际操作中打包多大，更多的是取决于这一点。更好的方式是，需求在打包以后，通过业务逻辑图的方式可视化，可以更直观地给别人讲解。

如图2-17所示，是我做过的一个项目的业务逻辑图，因为涉及一些商业问题，所以图中有些关键词隐去了。

图2-17　魔方计划的业务逻辑图

第二，功能互相之间有依赖关系。那些只能先做的功能，应该在产品需求列表里注明。功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做。但评估工作量时不会考虑“谁来做”的问题，在正式立项、组建团队时才会重点考虑。从长期来看，为了避免这类风险，提升与平衡团队成员的能力才是根本办法。

第三，需求的粒度大小问题。如果细分那些商业价值很高的功能的话，我们会发现其中也有价值相对低的部分，所以需求的粒度应该尽量细，前提是细化所需要的管理成本在可接受的范围内。举个生活中的例子帮助大家理解：大开间办公区域里的灯，不可能用一个开关控制，也不可能每一个开关只控制一盏灯。具体细到多少，要根据具体情况具体分析。我们的经验是，在需求列表里出现的任意一行，工作量最好不要超过“5人天”。

战场：产品会议

需求打包完成了，战争就要打响了。

某天，各个部门的老板们都聚集到一个大会议室，准备待上一整天。各个产品的产品经理和设计师们等着被轮流召唤，当然如果你有空且愿意，也可以旁听一整天。其实对资源的争夺，在部门内讨论商业价值的时候就已经预演过了，通常来说每个人都会尽力为自己提出的需求说好话，毕竟实现自己想法的感觉总是好过帮别人实现想法。

一般来说产品会议一个月一次，当然这和产品性质有关，如果你们公司的产品周期比较长，那也可以两三个月一次。

当某个产品团队开始登场亮相的时候，一般他们会先回顾上一次产品会议通过的项目，现在进展如何，是否需要调整时间进度、是否需要追加资源、是否有重大需求变更，已经发布的项目数据表现如何、有什么问题等。这样一方面是为了让大老板们更新各个项目的信息，更重要的是为了总结经验，让今后产品会议上的决策越来越合理。

回顾之后，就是会议最关键的部分了，我们会拿出准备好的商业需求文档，每个产品都会拿出三五个，占满2～3倍的潜在资源。这里说的潜在资源，是指相对固定的开发、测试人员，因为技术人员对产品的熟悉程度不同，所以在短时间内，不可能太多的人同时转去做其他产品。这也就意味着潜在的人力资源数量是在一个值附近做微小浮动的，所以我们也可以认为，在一定程度上，资源的争夺是以产品内多个项目的争夺为主，产品间的争夺为辅。很有意思的是，这三五个商业需求文档通常是同一个产品团队里不同的人做出来的，所以内部也会争得“你死我活”。

接下来的重头戏是一直提到的商业需求文档。

武器：商业需求文档

我们刚刚把需求打好包，接下来就要描述一下这个包了，这就是商业需求文档，Business Requirement Document，简称BRD，它也是我们参加资源争夺战的武器。

下面来聊聊我们的武器——BRD怎么写，都包含哪些内容。

项目背景：“我们在哪里？”即为什么要做这个项目，这个项目解决什么问题，可以列出一些数据说明项目的必要性。

商业价值：“我们去哪里？”这是最关键的重点。大老板们最感兴趣的是做了这个项目以后有什么价值。这部分内容一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。

功能需求描述：“我们怎么去？”即做哪些事情来达到目标。我们要把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西。

非功能需求描述：如果有重要的非功能需求的话，在这部分内容中提出。

资源评估：这是第二个重点。大老板们在了解达成项目的目标需要多大的花费以后，才能做出决策。

风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。

BRD中的“商业价值”和“资源评估”两个重点在本质上其实是大老板们在追求性价比。大家都希望花费最少的资源获得最大的商业价值。

下面通过一个BRD的实例，再给大家讲一点直观的认识。

首页，我们会给BRD起一个有意义的名字，再配上一幅图，这样有助于提升团队的归属感。比如下面这个BRD叫“魔方计划”，如图2-18所示，因为这个项目打算将两个老产品像魔方一样打散、组合，整合为一个新产品。

商业价值如图2-19所示，它的作用是给老板们看他们最关心的指标，比如魔方计划就聚焦在“活跃用户数”上。

图2-18　魔方计划PPT的首页

图2-19　魔方计划的商业价值

功能需求描述方面，我们给出了业务逻辑图，如图2-20所示，若能给出一些简单的Demo更好，让老板们提前看到产品完成后的样子，很可能成为争取资源的加分因素。

图2-20　魔方计划的业务逻辑图

资源评估方面如表2-9所示。我们会根据团队的实际情况，重点评估主要功能对产品设计师、用户体验师、开发工程师的人力需求。

表2-9　魔方计划的资源评估

注：测试资源有保证，暂不评估。资源单位是“人天”。^[54]

老板很可能会把多个BRD合并为一个项目，或者把一个BRD拆成多个项目，或者直接砍碎了再重新组合。不管怎么说，产品会议开完以后，我们终于确定了接下来一段时间要做哪些需求了，接着就要准备启动项目，迎接新的开始。

2.4.2　别灰心，少做就是多做

2007年国庆长假回来，我在全力做阿里软件网店版“自动上架”的功能。当时，淘宝为了防止一些没人打理的商品始终停留在搜索结果中，稀释了有效信息，所有商品会隔一段时间后自动下架，不能再被搜索到，这时就需要用户重新将商品上架。而阿里软件网店版的用户都是淘宝的优质卖家，所以我们给他们提供了一个“自动上架”的功能。

这是一个确定“怎么做”的过程，当时的体会能很好地表达我的想法。

一个功能的多次需求会议必然是这样一个过程：开始大家对一个功能想得不完整，说着说着大家都想把这个功能做得再强一点，这里加一点那里加一点。但后来通常因为技术实现、资源等原因，又把这些加上去的功能点一个又一个地砍掉，砍到最后甚至会发现和一个月前的第一次方案是一样的。这个看似白搭的过程其实是有用的。大家一起经历了“见山是山、见山不是山、见山还是山”的三段过程。那些加上又砍掉的功能点，在第一个阶段我们根本没有想到；第二个阶段想到了，很兴奋，那就做吧；第三个阶段再次砍掉是权衡利弊之后的决定，和“没想到”是完全不同的。我们无法绕过第一阶段的无知，也千万别停在中间那个功能点“大而全”的时候，因为这样必死无疑！而第三阶段的“少做”则是超越第二阶段“多做”的“少做”，这才是真正的“多做”。

有很多文章谈到这样的思想，用100%的质量去实现75%的数量，而不是反过来！吸引用户的往往只是功能模块中的一两个点，我们一开始只要让这一两个闪光点拥有100%的质量其实就够了，这样留给用户的是对升级的期待。而如果反过来，功能铺得很开，但每个点都不爽，反而喧宾夺主，把闪光的地方给掩埋了。

情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。

当发现一个功能可有可无的时候，甚至只要是没有强烈的理由要做的时候，要明确地选择：不做！因为少做就是多做！

最爽就是“四两拨千斤”

做得少不如做得巧。

2.3.1　节中我们提到满足需求有三种方式，其实就算“提高现实”这样一种最常用的办法，也有很多“四两拨千斤”的方案。如果机会闪现，就千万不要放过。

我对下面这个故事过目不忘。

某跨国日化公司，肥皂生产线上存在包装时可能漏包肥皂的问题。

于是公司组织了以博士牵头的专家组对这个问题进行攻关。该研发团队使用了世界上最精尖的技术（如红外探测、激光照射等），在花费了大量美元和半年的时间后终于完成了肥皂盒检测系统，探测到空的肥皂盒以后，机械手会将空盒推出去。这一办法将肥皂盒空填率有效降低至5%以内。

问题基本解决。

再说某乡镇肥皂企业也遇到类似问题，老板命令初中毕业的流水线工头想办法解决。经过半天的思考，该工头拿了一台电扇到生产线的末端对着传送带猛吹，那些没有装填肥皂的肥皂盒由于重量轻就都被风吹下去了。

这样做得更少，但是效果更好，至少性价比更高。这是个很有“段子感”案例，后来也有观点说，事情没那么简单，比如“生产环境里不可能放一台普通电扇”。不过，故事想表达的意思，我想大家已经明白了。

另外，具体情况还要具体分析，任何事情总有它的两面性，比如上例中乡镇企业的解决方案换到跨国公司的环境中，也许并不适用。

我们不必觉得只有“吃苦耐劳”，做了很多事情才是贡献。产品经理经常犯的错误就是——很努力地做“错误”的事情。回想一下自己做过的部分需求，有些是不是做不做并没什么区别？有一句话说得好：内部（指偏技术）的大改动往往是外部（指偏商业）的小改动，反之亦然，所以我们应该在动手前先找找有没有成本低、收效大的解决方案。

尽可能多地放弃

2.2.5　节里，我说“尽可能多地采集”。本节中，我又说“尽可能多地放弃”。它们看似矛盾，其实正反映了我们对事物的认识过程。只有在采集阶段没有遗漏，才可能完整地看到事物的全貌。有了大局观，在放弃的时候才知道孰重孰轻，也更下得了手。

多年以前我看到白鸦^[55]写过的一段例子，说的是如果不放弃，最终会被自己折腾死。他是这么说的：

比如，一个最简单的“评论”功能：既然可以发评论，那么……

是不是需要改评论？

删评论？

发的权限是否要管理员设置？

那么改的权限呢？

删的权限呢？

是否可以引用别人的评论？

评论被人引用了是否可以再改？

如果可以改那么是不是要保留修改记录？

如果管理员改了一个评论那么作者是不是不能再改？

评论是否要有数量和时间限制？

评论要不要翻页？

如果要翻页是在本页翻还是打开新页？

评论能不能带图片？

带了图片那么是不是能上传？

能上传之后是不是要能删除？

是不是要提供自定义评论排序？

是不是要xx？

是不是xx？

xx？

……

“需求越来越多，让人崩溃，但是要做的事情太少，似乎也会有问题。”小明忍不住跳出来问。

小明：“有资源空出来了怎么办？”

大毛：“要做的数量是少了，但要达到100%的质量，一般很难空出资源。”

小明：“真的空出来了怎么办？”

大毛：“去找其他意义更大的功能。”

小明：“找不到怎么办？”

大毛：“把空闲下来的人拉去做另外一个意义重大的产品，这不可能再找不到了。”

“少做就是多做”，阿里巴巴的马云也说过。

2.5　需求管理：心急吃不了热豆腐

没有产品生下来就是完美的，一天又一天、一月又一月，我们的产品反复地经历着需求采集、需求分析、需求筛选的过程，从而不断进化。我们不要想一口吃个胖子。很多案例表明，追求一步到位的产品经常像陷入沼泽的巨兽，挣扎着一步步走向死亡，用户甚至根本都不知道它曾经存在过。

在这个过程中，需求会越来越多，就像工作永远做不完一样。而我们要做的事情是，在资源在限的情况下找到最有价值的需求，然后把它做好。那么，新的问题产生了，我们得找个办法把越来越多的需求管理起来。

2.5.1　一个需求的生老病死

这是一个真实事例：

网店版2.0发布上线后的两个月内，从各个方面采集到的需求多达四五百个，经过PD们的初步判断，记下来供团队讨论的有200多个，决定暂缓的有60多个，仅7月当月内发布了70多个……

每个需求的去留一定是需要管理的。我们可以在产品需求列表上再加几个属性，试着管理需求的生命周期。

需求状态：通常有“待讨论”“暂缓”“拒绝”“需求中”“开发中”“已完成”几个状态，可按照实际情况有所增减，比如管理的粒度细一点，还可以增加“测试中”。

负责PD：在需求状态变为“需求中”时指定，最可能是此需求的提交人，在需求的整个生命周期中，此人要从头到尾跟进，他是这个需求的主人。

开发工程师：在需求状态变为“开发中”时指定，负责这个需求的技术实现，并解决将来可能发生的故障。其他人员，比如测试负责人、项目经理，大家可以按需要决定是否填写。

项目名称：辅助信息，在需求进入“开发中”时确定，用来确定该需求属于哪个项目。

发布时间：辅助信息，在需求状态变为“已发布”时填写，用来查看某段时间发布的需求。

备注：其他任何信息都可以写在这里，如需求被拒绝的理由、需求被暂缓的理由和重启条件、其他相关文档，等等。

至此，我们终于得到一个需求完整的“DNA”，如表2-10所示，表中星号（*）标识的项目是我心目中的必填项。

表2-10　一个需求的“DNA”

我们每次“需求讨论会”讨论的，自然是状态为“待讨论”的需求了——所有的需求由提交人录入列表，初始状态都会被标为“待讨论”。讨论确定“商业价值”的时候，需求的状态一定要变化，或是进入“需求中”，意味着要继续“初评工作量”“计算性价比”，甚至进行“需求打包”并做成BRD了；或是被“拒绝”，被拒绝的需求通常被认为在相当长时间里对产品的商业目标没有价值，拒绝理由不那么明显的，最好在备注里注明；或是“暂缓”，暂缓的需求是“有价值，但是现在不做”的，通常要注明重启的条件等。

而产品会议上通过的需求，状态会变成“开发中”，正式进入项目。等到项目发布，这个需求的状态又变成“已发布”。产品会议上没通过的需求，连同“需求中”但未被打包的需求，状态可以变成“暂缓”，并备注说明情况。

现在，我们可以把“一个需求的‘DNA’”从静态变成动态，画成“需求的生老病死”流程图，让我们实时看到每个需求的“何时做、谁来做、状态如何”等信息，如图2-21所示。

在一个需求“死了”之后，我们也有了这个需求完整的“DNA”。

工具和方法都是为了目的服务的，大家更应该了解其背后的原因，并根据自己的实际情况，比如产品的大小、资源多少，做出最合适的表格。

图2-21　需求的生老病死

2.5.2　需求管理的附加值

在实际工作中，我们发现需求管理还可以带来额外的价值。

这里要用到一些Excel的统计功能，对产品需求列表做一些简单的统计，就可以形成一份需求简报，形式如图2-22所示，举几个应用实例。

统计每个“提交人”的需求数量：通过这一数据，我们可以看出产品团队里每个人提交了多少需求，如果再加上时间段的条件，就可以从一个侧面反映出某段时间每个人的工作情况。

统计“提交时间”“发布时间”等信息：比如按月统计，我们可以从需求数量的侧面看出产品发展是在增速还是在减速。如果需求提交的数量明显减少，我们就需要考虑对策了。

图2-22　需求简报

统计每个“模块”的需求数量：因为需求都是直接或间接从用户那里采集的，所以从各个模块的需求数量分布情况就可以看出用户对产品的哪些模块感兴趣，这可以指导产品发展的方向。

统计每个“分类”的需求数量：从各种分类的变化情况，我们可以看出最近产品团队是在做新功能开发，还是更多地做老功能优化，从而了解产品是在成长期还是成熟期。

统计需求的“商业价值”和“性价比”变化：我们从这些内容可以看出这个产品的发展空间还有多大，如果连续几个月，需求的“商业价值”“性价比”都不高，就要考虑改变方向以求突破，或者减少对这个产品的资源投入了。

除了可用Excel来管理需求，还有更专业的需求管理方法和工具，如Mantis系统、Mercury Interactive公司的Quality Center^[56]、IBM^[57]的Rational RequisitePro等，可以根据自己的产品与团队的情况选用。

2.5.3　和需求一起奋斗

本章说到这里，一个需求的奋斗史就结束了，而我的奋斗才刚刚开始。让我们再一次看一下图2-23，这是一个需求的奋斗史，也是我的第一年。

在这期间，我第一次因为产品发布而感动，也经历了做产品以来最激动的一刻，只有做得很辛苦，才能修成产品经理最基本的素质之一——热爱产品。

图2-23　“一个需求的奋斗史”详图

2007年6月28日，那是我作为主力PD的第一个付费产品发布的日子。临近发布的最后几周，因为各种原因，几乎是一个人扛下来的，非常辛苦，也有很大的收获。当时我在博客里写道：

从4月18日网店版1.0上线以来，到6月中旬：

用户数破20万，活跃用户破2万！

网店版2.0，经过70天来兄弟姐妹们的努力，一次一次的PK，几个小时前终于上线了！

经历了一个月的预热！

几天前，发出去几十万条消息说今天19点～22点产品上线。

今天傍晚还发生了意外事件。

18点左右收到消息，网通的淘宝专用机房断电！淘宝数据库全挂，万年一遇！

19点多的时候淘宝还是只有主页面可以看到……首页顶端有个红红的告示……后台全挂……

20点20分左右，淘宝终于起来了！

20点58分左右发布成功！

21点出头，收到第一笔款！

22点47分，现在，又刷新了一次账户：1770元！

24小时不间断“数钱”终于实现，哈哈！

毕竟是第一次自己作为产品主设计做出来的收费产品发布，值得鼓励一下！

继续努力！

到23点左右，我仍坐在显示器前，不愿意走，鼻子泛酸。这可能是我做产品经理几年来最激动的时刻，也是真心觉得“这个产品是我的^[58]”的时刻。