我真正开始做需求相关的事情，是从2006年年底开始的，直到2007年夏末，大半年的时间过去，总算对需求要做哪些工作有了比较全面的了解。本章将从“需求采集”开始，一直讲到“确定某个项目的需求范围”为止，从需求被发现到决定实现，这就是一个需求的奋斗史，如图2-1所示。
图2-1 “一个需求的奋斗史”缩略图
首先说说“从用户中来到用户中去”，做任何产品都是一个端到端的过程，端即用户，所以“用户是需求之源”，我们要拥有“以用户为中心的思想”，不断“体会真正的用户”，于是，本章开始就会和大家“聊聊用户研究”。
然后我带着大家发起“需求采集的大生产运动”，与用户接触的过程就是需求采集的过程，我们来看看几种常用的需求采集方法，如“数据分析”、“调查问卷”、“用户访谈”等。并且希望大家意识到“需求采集人人有责”，从而“尽可能多地采集”。
用户说了很多需求，产品经理要“听用户的但不要照着做”，必须“明确我们存在的价值”是“把用户需求转化为产品需求”，这一过程即需求分析过程。产品经理要通过“给需求做一次DNA检测”，来“确定需求的基本属性”、“分析需求的商业价值”、“初评需求的实现难度”，从而计算出需求的“性价比”。
资源总是有限的，所以我们只能做那些性价比高的事情，通过残酷的需求筛选，“活下来的永远是少数”。看看“永远忘不掉的那场战争”，给自己打打气，“别灰心，少做就是多做”，我们要有意识的“尽可能多地放弃”。
最后，是需求管理的话题。任何东西多了都需要管理，做产品更是“心急吃不了热豆腐”。这里与大家聊聊“一个需求的生老病死”，“需求管理的附加值”。再次回顾需求的奋斗史，也回顾我自己“和需求一起奋斗”的第一年。
也许大家已经发现，本章的讨论还仅仅局限于有一堆需求的时候应该“做哪些”、“做多少”的问题，并没有谈及需求“怎么做”。我会在第3章“项目的坎坷一生”里和大家仔细聊聊项目里的“需求阶段”要做的事情，我将其称为“需求开发”，如产品需求文档、用例文档应该怎么写。
很多人，包括我，入门的时候都是从写文档做起的，但事后想起，那种“接到一个任务，然后把它完成”的味道很没有产品经理的感觉【1】，所以我在本书第2章就会说明这个任务是怎么一步步明确的。当然，如果你现在已经被这样的任务弄得焦头烂额，急需一些拿过来就能用的指导，也可以先去本书第3.3.1节“真的要写很多文档”，看看“需求开发”应该怎么做，只是你心里得清楚，其实对于产品经理来说更重要的是“发现一个问题，然后设法将其转化为一个任务来解决”。
2.1 从用户中来到用户中去
从图2-1中可以看到，需求或直接或间接都是“从用户中来”的，所以我们要“到用户中去”【2】。第2.1.1节，我们先了解需求的本质，再了解用户的本质，接下来谈到要有“以用户为中心的思想”，但也“不要试图满足所有的用户”。在第2.1.2节中，通过了解别人、认识自己，来“聊聊用户研究”的话题。
2.1.1 用户是需求之源
用户是需求之源，如图2-2所示，还是我们的衣食父母，他们能给我们带来金钱的回报，或者优雅一点说是“可持续发展的机会”。不过，要研究用户的需求，我们首先得弄清楚，需求的本质是什么？
图2-2 用户是需求之源
人类为什么有需求
关于这个问题，有一次和朋友闲聊，他给出过一个很有趣的解释：
“食色性也”，“食”是为了生存，保证个体延续，“色”是为了繁衍，保证种族延续，这是生物（包括人）的本性，即最基本的需求。
这个说法让我想到了马斯洛的需求层次理论【3】：
1943年，由美国著名犹太裔人本主义心理学家亚伯拉罕•马斯洛（Abraham Maslow）提出了需求层次理论（Need-hierarchy theory），此理论将人的需求划分为五个层次，由低到高，并分别是：生理需求、安全需求、社交需求、尊重需求、自我实现需求。
人类生活在地球上，为什么会有各种各样的需求？那是因为生活中存在太多的问题，从而产生了不满意，而问题就是“理想与现实的差距”，那么人类会很自然地产生“减少甚至消除这个差距”的愿望，这就产生了需求。我们之所以做一个产品，肯定是为了解决某些问题，满足某些需求，而这些需求深挖到底，多问几个为什么，总可以归结到马斯洛说的那几个层次里。
一个很经典的例子，小明说：
“我需要买一个电钻。”
大毛问：
“为什么？”
“我想在墙上打一个洞。”
“为什么？”
“我想把一幅画挂在墙上。”
“为什么？”
“因为这面墙显得太空旷了，看着不舒服。”
“为什么？”
“因为太空旷就没有家的感觉，不够温馨。”
“为什么？”
“你烦不烦啊……”
“好吧，这个电钻其实是你对马斯洛的需求层次理论中第二层“安全”和第三层“社会交往”的需要。你想让家里看起来更温馨，从而产生安全感和归属感。”
……
通过小明的故事，我们发现，研究需求可以增强对用户的理解，而理解用户，是产品经理最重要的素质之一。
小结一下，需求的本质就是“问题”，问题的本质就是“理想与现实的差距”。作为产品经理，我们每天都在设法满足用户的需求，其实就是在解决各种各样的问题【4】，而解决这些问题的方法与思路，对任何人都有帮助，而任何人也都多少知道一点，所以，你现在理解为什么我一直说“人人都是产品经理”了。
用户VS.客户
用户与客户，这两个词在中文里似乎很容易混淆，换作英文会稍微清晰一些，用户是User，有时也叫做终端用户，End User，是使用产品的人；而客户是Customer，是购买产品的人、为产品付钱的人。举两个例子。
比如你觉得新浪的免费邮箱用得不爽了，忍不住付费买了新浪VIP邮箱，这时候你既是新浪的用户、也是客户。又如某天你在路边的超市买了一瓶娃哈哈矿泉水，这时你是娃哈哈的终端用户，是超市的客户，同时超市是娃哈哈的客户。
可以看出来，用户与客户可以是同一个人，也可以不是同一个人，对某个产品来说，产业链越复杂，这其中的关系也就越复杂。所以我们平时也经常不去刻意区分这些概念，而是统一用“用户”这个词来代表“广义用户”，它指的是所有和产品有关的人，或者叫产品干系人，除了终端用户、各种客户，还包括你所在的公司里与这款产品有关的老板、销售人员、服务人员、技术人员等。但我们一定要做到心中有数，不同的用户有重要程度之分，我们必须、也只能有所偏重。
某著名的电子商务网站建设服务提供商的演示文档里有这样一句明确的话——“相比您的需求，我们可能更重视您的用户的需求”。对此服务提供商来说，他在“您”（他的客户）与“您的用户”（客户网站的终端用户）之间，做出了明确的取舍，即优先满足产品使用者的需求，而不是付钱者的需求。
不管怎么说，“广义用户”是需求之源。
以用户为中心的思想
既然用户那么重要，很自然地就要把它放在最中心的位置。UCDChina.com【5】上有不少相关话题，能给做产品的同学很多思路上的启发。
公司有UCD的环境是产品经理的幸运，但，对这本书的大多数读者来讲，我估计BCD更多。BCD是我自创的一个词，Boss-Centered Design，以老板为中心的设计。对于中小型公司，需求的一个很大来源不是终端用户，而是老板——一种广义用户。一般来说，在这类公司中，老板反而是最接近业务、最了解用户的，加之老板的经验阅历又超过我们，所以他高屋建瓴、高瞻远瞩，会抓住一些商机，他觉得这些商机能够创造价值，很多时候比产品经理的观点更合理，这时候老板肩负起了部分产品经理的职责，起到了采集用户需求并分析、筛选的作用。创业阶段的公司是没有太多时间和精力“从用户中来到用户中去”的，一来一去可能公司都关门了，研究清楚了又怎样？因此有时一个问题和需求的诞生，就是靠老板凭经验拍脑袋。这种情况下，我们应该本着实用主义的思路，绝对不能一开始就想着“造反”——“我要见终端用户，我听用户的，不听你的”，而是要尽可能地帮助老板明确问题和需求的价值，为其决定方向提出参考建议，或协助其实现目标（当然，前提是老板要做的事情不违背你的价值观）。
所谓“酒肉穿肠过，佛祖心中留”，这样，我们便同时拥有了“以用户为中心的思想”和“以老板为中心的行动”（或者说“以实际情况考虑如何行动”）。以老板这种广义用户为中心，在小团队里其实反而是一种较优的实践。
不要试图满足所有用户
不仅要区别对待广义用户，对于狭义的终端用户，我们也无法一视同仁。新人常见的状态就是听到用户的新需求就很兴奋，特别想赶紧给他解决。随着你和用户的接触越来越多，某天，你兴冲冲地拿着收集来的100个需求，跑到团队里跟大家说：
“看，用户提了那么多需求，我们全做了吧。”
技术部门的同学说：“这起码得做半年。”
老板说：“不行，2个月后必须要上线。”
……
你很快就会发现，用户的需求实在太多了，根本做不过来，这就有了优先级评估，需求管理，此是后话，暂时按下不表。更有甚者，不同用户或某个用户自己提的需求有时候是互相矛盾的，所以根本做不到听到什么需求就做什么功能。
试图满足所有用户的需求是一个灾难，那会让产品变成一个臃肿不堪，谁都不满意的四不像。
我们心中充满疑惑：我想以用户为中心，但是各种各样的用户根本不在一起，出现了N个中心，到底哪个中心才是中心中的中心啊？
事实就是这样，我们无法满足所有用户的需求。那么我们应该优先照顾哪些人？
谁对我们重要就照顾谁吧，如何评估是否重要？
腾讯CEO马化腾说应该关注核心用户的需求。
我做过的一款产品刚起步的时候，老板跟我说先满足大量的一般用户的需求。
矛盾？谁错了？其实谁都没有错，我是这么考虑的，腾讯的产品已经充分占据了市场，拥有霸主地位，所以用户数不可能再有爆发式增长，于是只能考虑从已有的用户身上深挖用户价值，而最有价值的一批用户无疑是核心用户；而我做的那款产品刚起步，没什么用户，急需把池子做大，所以我们会先做一些大众功能，满足一般用户的需求，让用户数先爆炸起来。
所以说，优先满足哪些用户需要和产品的商业目标要结合起来考虑，简单说就是看KPI【6】是什么，值得注意的是，不要把KPI狭义地理解成一些数字，可以把它想象成一种综合的指标，也可以包含客户的满意、员工的开心等。既然我们的产品目标是用户数、活跃用户数，而不是销售额，那么从一开始就注定了我们更要代表的是大多数用户的利益。这并不是说核心用户不重要，而是产品的不同阶段，目标自然不同。
当然，你也可以从其他维度划分出优先满足的用户，如男女、地域、年龄段等，其中的道理都是相通的——我们无须满足所有用户的需求。
2.1.2 你真的了解用户吗
很多时候，我们埋头做事，项目的时间很紧，根本没空去接触用户，直到产品发布。突然有一天接到一堆反馈，我们措手不及，都是些原来根本没想到的问题。有一些前辈曾在网上讨论过“装不装用户”的问题，我的想法是，如果你做的东西确实是自己平时就会用的，那么可以试着装一下，不过要记住你装的用户只能代表一部分用户，而对于自己不怎么用的产品，千万别去臆测用户的情况。
真正的用户，他们想的，他们做的，你真的了解吗？
体会真正的用户
我开始做的是互联网的个人应用，去和用户接触的时候感觉还好，后来做企业应用产品的时候，一次次地被那些正在“电子商务”门口晃悠的用户们震撼了，以此为例来看看真正的用户吧。
他们是中国最典型的中小企业，从十几个、几十个人的贸易型企业到百来个、几百个人的生产型企业，年销售额几千万元人民币左右，只是顺应潮流，或者说被忽悠着建了个网站，没做网络推广，网站几乎没有访客。但是，他们却买了我们的营销管理工具，而这个工具是帮助用户更好地管理网站的访客，促进“访客变客户”的……于是我们做了一批电话访谈，套用郎咸平2008年底讲的一句话：“惨得我都不想说了……”，还是听听怎么回事吧。
有的用户是被经销商忽悠进来的，有没有需求不知道，而且他们都不知道自己买的是什么产品。
► “我没有买你们这个东西，不要不要不要不要不要，嘟嘟嘟……”
原来经销商把我们的产品和其他东西一起打包成了个“忽悠套装”，也不跟用户讲到底是个什么，唉。
► “原来这个买了还要账号密码啊，经销商没给我……”，“经销商说他们全程服务的，我们不需要做什么。”
他们以为和做网站一样，付了钱就没事了，可是这次买的是个软件呀。
► “我们公司嘛，只有一台电脑，因为放在我办公室，所以就让我用用，但我不懂电脑的嘛。”
老板随便找了个人用，可是这位大叔听上去有五六十了吧？
有的用户，打电话过去找不到想找的人。
► “我不懂这个的……”停顿3秒，“我不懂这个的……”停顿3秒，“我不懂这个的……”
一个有耐心的阿姨，可惜只会说这句话……
► “你是哪里？”“BlaBlaBla……”“不要再给我打电话了！啪，嘟嘟嘟……”
有时候你会碰到个火气大的。
► “我～听不懂～～普通～话。”
好吧，再见。
有些，让我们了解到了一些需求，不过都挺偏门。
► “我忘了账号了，忘了网址了……”
这点，我们要好好反省，有办法解决的。
► “我们做的东西很专业啊，都是上年纪的人，习惯电话联系，效率高，说得清楚，不懂网络的。”
好，电话，是个方向，网络的价值最终还是要通过与线下结合来体现。
► “我们主要靠老客户，熟人介绍的，都是大单，网上来的小单子不要做的。”
嗯，总算听到些靠谱的，他们的业务地域性很强，对业务员来说，老客户已经足够吃饱了，网络带来的小单是有点看不上眼。
还有一些，聊来聊去都是闲谈。
► “啊，你是阿里巴巴的啊，我来考考你，阿里巴巴是哪年成立的？”
无语……顺便说一句，1999年。
► “一年几千万、上亿的销售额，几千块钱哪里花不是花，呵呵。”
还算有点让人欣慰的。
经历了这些对话，我想表达的就是，想了解用户，光靠空想是不行的，他们是真实的，是五花八门的，必须得真刀真枪地去研究他们。
试着描述用户
看到这里，你有没有跃跃欲试，想和用户来个亲密接触？可惜产品经理在公司里有时候只不过是一杆枪，要按照老板的需要指哪打哪，不是随时都有那么多资源让我们折腾的。好吧，告诉你一个几乎零成本的做法，它可以让你增加一点对“用户”这个词的感觉。
我们来做一个简单的练习，你很可能是做互联网、软件相关产品的，即使没做过，也一定用过，试着描述一下自己在用各种互联网应用的时候，是个什么样的用户。我先描述一下自己。
E-mail：2000年的时候申请了第一个，Sina的，是私人E-mail，但是在学生时代利用率不高，没什么邮件，到2007年的时候用Gmail代收，之后就不再对外留这个地址了。现在私事用Gmail，强大的搜索功能让邮件整理的工作变得不那么重要，节省了很多时间，很喜欢它把同主题邮件合并的处理方式，适合群聊，有些文件备份也放在里面，空间够大，而且防垃圾功能做得很不错。公事用公司的邮箱，没什么好说的。
IM【7】：最主要取决于自己认识的人都用什么，各种功能用得很少，能打字就行了，所以私事用Gtalk、MSN，喜欢Gtalk的简单。公事用阿里旺旺，表情是亮点。QQ不时地会挂一下，不过总是没什么人在，2009年7月又开始用了，很诡异的原因，因为自己打球受伤，跟腱断裂了，没想到QQ上有个跟腱断裂群，在用户基数这点上不得不感叹QQ的强大。
RSS【8】：最早用过客户端的阅读器，周博通，后来因为公司和家里用不同电脑的问题，开始把能在线解决的事情都转移到线上，所以改用抓虾（zhuaxia.com），2006年底那会儿选抓虾而没用Google Reader的原因完全是当时Google Reader做得还比较粗糙，不过后来因为使用习惯的原因，直到2009年初才狠心转用Google Reader，这次改用是因为抓虾的速度慢了，团队出现了问题，产品不再更新，另外一些小体验上确实不如Google专业。
Douban.com（豆瓣）：对我来说是个很好的工具，基本上在别处了解到某部电影和某本书以后，决定是否看之前都会来看看评价，我还是比较信任群体智慧的，特别是在这个群体人员与我的口味比较相似的情况下，比如我抛弃IMDB的电影评分转向这里，是因为总发现有些评分超过8分的看了毫无感觉，而豆瓣就很准，看来我的口味非常本土……我会标记“想看”、“看过”作为一个记录，但是很少留下评论，就算有也就是几句话而已。
好了，上面说的这些使用习惯只是截取了几个点，你还可以写写SNS【9】、博客、微博客、网络浏览器等的使用习惯。可能有人已经发现了，这有点像创建人物角色（Persona）做的事情，没错，在刚才这些内容之上再加上用户的个人信息、配一张照片，写上公司与用户的目标等，就是著名的Persona了。我试着为某个汽车网站设计了一个用户角色，如表2-1所示。
表2-1 人物角色（Persona）
充实人物角色的内容有很多方法，在下一节“聊聊用户研究”中会给大家介绍一些资料。
2009年秋我做了一个产品整合项目，要把手头的产品和另外一个我完全不了解的产品做一些功能的合并。那时，我才体会到，有形的Persona存在的更大意义，可能并不是给创建者自己看，而是有新人进团队的时候，可以迅速了解用户，理解产品，同时忙碌的无法关注细节的老板也可以利用Persona迅速进入状态，保证他们也能像创建者一样，时刻心中想着正确的用户形象。
还记得本节开头说到“我们只不过是一杆枪”的抱怨吗，有一次我和同事说了，他哈哈一笑，说“美得你，我们的老板也只不过是一杆枪，你我就是一颗子弹而已”。当工具的滋味是不好受的，特别是当产品经理很有想法的时候，所以我们要争取主动，不过是在诸多限制下“带着镣铐跳舞”。
聊聊用户研究
比较早的时候，我总把用户研究当做产品设计过程中锦上添花的事情，每到没什么事可做，闲得无聊的时候，就跑去跟老板说：
“我们这两周做点用户研究吧。”
“你的目的是什么？”
……
后来我渐渐明白，用户研究不是附属内容，而是前提，必须在做产品的过程中随时纳入计划。也许，突然有一天，当你有了机会去接触用户，却很可能不知所措，我到底应该找谁？通过什么方式？聊些什么？如何指导产品发展……对于这些问题，我的启蒙书是《赢在用户：Web人物角色创建和应用实践指南》【10】。
全书讲了用各种用户研究的方法创建Persona，然后加以应用，目的是在设计产品的过程中时刻不忘用户，做到以用户为中心。其实“用户研究”、“市场研究”、“需求采集”等，都是为确定产品应该有哪些功能服务的。书中有一张关于用户研究方法的二维图，如图2-3所示，值得牢记。
图2-3 用户研究的方法
此图来自《赢在用户：Web人物角色创建和应用实践指南》，稍有修改
横向，用户的说和做。
怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。两方面都很重要，我曾经认为“耳听为虚，眼见为实”，所以看到用户怎么做会比听他们说更真实有用，但后来体会到，只了解做是没办法知道背后原因的，而不知道问题的原因也就意味着没法从根本上解决问题。所以我们既要看用户怎么做，也要听用户怎么说，虽然他说的不一定是真话。
纵向，定性与定量。
定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实。两者都很重要，缺一不可，只定量会“以标代本”，看到问题但不知道原因，只定性会“以偏概全”，很可能被部分样本的特殊情况带入歧途。人们认知新事物的过程通常都是从定性到定量，再定性再定量，并且螺旋上升，而了解和证实也是不断迭代进化的。
说和做、定性与定量，合理的搭配组合使用，才能发挥最大的作用，下面的这个产品调研的小例子，就是用了各种用户研究方法来交替解决问题的。
第一轮，听用户定性地说，确定产品方向，做什么？随机抽样40个用户做访谈，据此写出需求列表。
第二轮，听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。
第三轮，看用户定性地做，要先做的那几个需求，应该怎么做？一边设计，一边陆续找了10个用户来验证，做可用性测试。
第四轮，看用户定量地做，根据产品的用户使用情况做数据分析，不断改进产品。
当然，这是一个比较重要的产品，所以在用户研究上投入了较多的时间与人力，更多的时候，我们会视情况采取简化的方案。
上述维度的划分【11】可以帮助我们更好的理解用户研究各种方法的特点，以便在现实工作中更加灵活地应用。每类方法都有其优势和劣势，对应了不同的适用场景，使用之前要认真考虑清楚产品的目标，是新产品定位？老产品优化？预测某新功能的用户数？提高用户活跃程度？验证某个改动的效果？……
说到底，我们做用户研究的目标是：坚决杜绝“经组织研究决定，用户需要一个××功能”这类事情发生，要实实在在地把用户当做需求之源。每个产品经理都应该看一些用户研究基本理论，最起码，可以避免犯一些低级错误，比如做调查问卷的时候，通常需要给用户激励，但不能使用被调查的产品作为激励，因为这对人群有一个筛选的作用，可以更多地吸引对产品感兴趣的用户参与调查，从而让结果偏向乐观的方向。
回到上面那张用户研究方法的图，我在实际工作中就是用这些方法做需求采集的，下一节和大家聊聊其中的故事。
2.2 需求采集的大生产运动
实际工作中，到底采用哪种用户研究方法，往往取决于资源，比如人员数量与能力，老板给你多少时间、经费。如果资源非常少，我们甚至可能简化出很不正规的方法，比如只是查一些二手资料然后和同事们一起讨论，猜测一下用户是怎么想、怎么做的，而有了资源以后，我们可能会叫几个用户过来访谈，请咨询公司协助出报告，或者出差做用户调研等。每个人所处的团队条件不一样，也只能在实践中慢慢总结出适合自己的方法。
但这些用户研究，或者说需求采集的过程，都会有如下几步：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。
把图2-3“用户研究的方法”简化为如图2-4所示的需求采集方法，对应图中4个象限，第2.2.1节至2.2.4节分别通过一种最常见的方法来谈这类方法的特点、如何操作及注意事项。
图2-4 常用的需求采集方法
最后，提出“需求采集人人有责”的概念，这样，我们才能“尽可能多地采集”。
2.2.1 定性地说：用户访谈
用户访谈通常采用访谈者与被访者一对一聊天的形式，一批次用户访谈的样本比较少，一般是几个到几十个，但在每个用户身上花的时间比较多，通常为几十分钟到几个小时，围绕着几个特定的话题，我们问，用户答，用户说，我们听，这是一种典型的定性研究。用户访谈可以了解用户怎么说，即他们的目标和观点。根据我自己的经验，用户访谈经常用在新产品方向的预研工作中，或者通过数据分析发现现象以后，去探索现象背后的原因。
用户访谈的常见问题与对策
用户访谈经常出现如下问题：
第一，“说”和“做”不一致的问题。
用户经常会骗我们，先看一个经典的索尼游戏机的故事。
索尼找了一些用户来，问他们喜欢黄色的还是黑色的游戏机，结果发现说喜欢黄色的用户比较多。之后，索尼告知用户为了感谢他们的配合，将送他们一台游戏机，颜色可以任意挑选，而同样一批用户选择黑色的游戏机带回家的更多。很明显，有部分用户说喜欢黄色却带走了黑色的游戏机。
用户倒不是想故意欺骗我们，而可能是：他们被问了自己也没仔细想过的问题，又不想回答不知道，就在现场编造了一个看似有理有据的理由，或者他们有讨好访谈者的心理，会回答他们觉得你希望听到的答案，而不是自己真正的想法【12】。
对我们来说，防止被骗的方法恐怕像索尼一样，尽量在用户可以和产品发生交互的场合下进行，让用户在“说”的同时也“做”，只不过，这样访谈的成本会明显高于电话访谈或邀请用户来公司的会议室访谈。另外，我们也可以注意区分用户说的事实与观点，一般来说，诸如“我做了什么，步骤如何，碰到了什么问题”这类事实的可信度更高一些，而“我觉得、我认为”这类的观点，则需要带着大大的问号去听。
第二，样本少，以偏概全的问题。
选择样本的时候需要多加注意，尽量做到随机，举几个常见的“不随机”的例子。
比如为了成本考虑，我们上门访谈的时候只找了本市的用户，这样很可能得出一些与地域有关的错误推论；又如电话访谈时，为了提高联系成功率，我们优先拨打留了手机的用户，而留手机很可能代表这批用户忠诚度已经比较高；再如邀约用户来公司访谈，“愿意来的用户”，就已经和全体用户有差异了……
对于这个问题，我常用的几个对策如下。首先，我们应该尽量识别出各种可能引起偏差的因素，并在访谈的报告里标明，让读者了解。然后，为了用尽可能少的样本得到尽可能正确的结论，我会以增量的方式做访谈。举个例子，我会先访谈5个用户，得出基本结论，然后再访谈5个，观察结论是否有改变，如果有改变，就继续加大样本量，或者思考问题是否合适？样本集是否合适？如果没有改变，就停止继续访谈，节省成本。
样本的选取，其实属于概率与数理统计的范畴，想深入的同学可以自行研究。
第三，用户过于强势，把我们往沟里带。
我在2006年底做网店版的用户访谈的时候，就经常犯这个错误：
当时我们找来了很多淘宝的大卖家，问了几个问题以后，那些卖家的情绪就被调动起来了，似乎好不容易有个倾诉者来听他们创业过程中的成就与艰辛，然后就开始讲故事，比如卖水货手机的帅哥给你讲中国整个水货手机市场，第一级只有深圳的几个人，每天凌晨两点他们会在某个秘密地点出货给第二级，都是以“百台”为单位叫价，和古老的证券交易所一样，然后四点左右第二级就会把当天的价格传真给他……改天又来一位卖钻石的少妇给你讲他老公多有钱，就是没空陪她，给她在上海最繁华的地段买了个门店卖钻石，她经常去南非采购，一次买好多，轮着戴，不喜欢的就折价卖掉，不为赚钱就是找点事情做……真假不论，反正都是无比精彩，我们又不够老道，完全被忽悠得入神了，原本一个小时的访谈变成三个小时，最后送走用户，一看访谈记录，一片空白。
要解决这个问题，需要时刻牢记访谈的目的。如果发现话题不对，就赶紧往正道上扳，若发现多次都扳不过来，就可以考虑尽快结束了，用户很多，不要在一个不合适的对象上花费太多时间。当然，有时候用户侃得十分精彩，如果你不是很忙的话，听听长长见识也可以，这个就自行把握吧。
第四，我们过于强势，把用户往沟里带。
原来我们团队有一位做销售出身的女生，改行做产品，在新产品中负责了几个模块的设计，设计好了邀请用户来做访谈。她的故事很有趣——
开始挺好的，她慢慢深入地问着，用户小心翼翼地答着。随着访谈的进行，用户渐渐地放开了，开始对产品提出自己的看法，于是砖头一块一块的向那位女生的头上抛去，只见她的脸越来越苦，然后终于忍不住了，心说“老娘当年可是做销售的，看我怎么收拾你”……接下来只见风云突转，她给用户晓之以理动之以情，指出了用户的理解有哪些不对的地方，她的产品确实很好，很值得买，几十分钟过去，用户完全被说动（不得不赞叹她的销售功底就是扎实），就差道歉了，觉得这确实是一款好产品，并且承诺说上市以后一定买。用户走后，她心满意足，回来大家一讨论这个过程，都傻了。
这个问题的对策，同样是牢记访谈的目的，并且管好自己的嘴。
我在看《软件观念革命：交互设计精髓》【13】的时候，发现里面也讲了不少关于用户访谈的注意点，在本节最后分享给大家。
► 避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读。
► 首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。
► 避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面。
► 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。
► 鼓励讲故事：故事是最好的帮助设计师理解用户的方法。
► 避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用吗？”一般来说用户会给出毫无意义的肯定答复。
记一次用户大会
用户大会，是邀请产品的用户到某一集中地点开会，人数一般在几十人到几百人不等，可以短时间内从多人处收集大量信息，是一种特别的用户访谈形式。我在2007年6月组织过一次阿里软件网店版的用户交流会。这种会耗费资源较多，一般机会不多，所以要充分利用。按时间分几步重点摘录如下，结合这个提纲，我们来看一下这种用户访谈形式应该如何准备、如何操作，如果把“用户大会”也视为一个产品的话，大家也可以从中看到一些做产品的通用思路。
明确目的：
会前最重要的是明确这次用户大会的目的和意义，这在争取资源的时候会更有说服力，比如：产品二期卖点确认，辅助运营决策；三期需求收集；现有产品用户体验改进等。
资源确定：
► 时间：日期、几点、时长。要考虑淘宝卖家的空闲日子和时间段。另外注意要把整个活动各项准备的时间点掐准，留余量。
► 地点：场地、宣传用品、IT设备、礼物、食品饮料、桌椅。
► 人物：
工作人员：大家一起上，人人有事做，分组分工，注意产品、运营、开发人员的搭配，要有冗余；
用户：确定目标用户、数据提取、预约，要充分考虑人数弹性；
嘉宾：相关老板、合作部门的同事，不管来不来，邀请要发到。
► 材料：用户数据、产品介绍材料（测试环境确保当时可用，静态Demo备用）、可用性测试【14】材料。
► 各项备用方案的准备，用户大会前两天开一次“确认会”。
现场执行：
► 辅助工作：场地布置（轻松一点，不要像开会）；引导/拍照/服务/机动；进场签到（给礼品）；全程主持（进度控制）；送客/收拾残局。
► 主流程：
产品介绍：重点是卖点介绍，与用户互动，观察用户更关注哪些功能，辅助上线前的运营决策，到底主推哪些卖点；
抽取部分用户做焦点小组【15】的讨论，收集后续的需求，产品三期开始启动；
同时抽取部分用户做可用性测试，帮助产品二期做最后的微调；
最后，合影留念。
结束以后：
► 资料整理：卖点总结报告、需求收集报告、可用性测试报告。
► 运营：本次活动在淘宝论坛发帖；内部邮件。
► 整个活动资料的整理归档，包括照片、各项材料/报告信息、用户数据等。
一个三四小时的会，我们好几个人前后忙了有半个月，从计划制定、资源申请、各种材料准备，到当天执行、之后的分析整理……不过这些辛苦都有了回报，在短短几个小时内，从三四十位用户那里获得了很多有价值的信息，比如确定了产品二期主推的3个卖点；明确了产品三期优先级最高的几个需求；与这些用户成为朋友，将来可以作为产品的种子用户【16】等。这些都为今后的产品发展提供了指导。
2.2.2 定量地说：调查问卷
同样是听用户怎么说，常见的定量研究方法是——调查问卷。
调查问卷和用户访谈的提纲是有区别的：用户访谈的提纲通常是开放式问题【17】，适用于我们心里还比较疑惑的时候去寻找产品的方向，适合与较少的访谈对象进行深入的交流；而调查问卷通常封闭式问题比较多，适合大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案，调查问卷不是考试卷，不适合安排问答题。用户访谈与调查问卷之间也有联系，我们经常通过前者的开放式问题，为后者收集具体的封闭式问题。
无论是网上还是线下，作答时间最好不要超过10分钟，否则很多人看一眼就被吓跑了。开篇一般放一些简单的不需要思考的问题；很想知道的内容，需要思考的，较敏感的问题一般放在中间；而有关被访者个人信息的题目一般放在问卷的最后，以免应答者在回答这些问题时有所顾忌，进而影响其他答案。
调查问卷的常见问题与对策
调查问卷一人一份，独立作答，可消除“焦点小组”、“论坛发帖征集需求”等具有群体讨论性质的方法的弊端。这是因为用户有其特点——沉默与骑墙的总是大多数。
《长尾理论》里说到“沉默的大多数”，那么站出来的总是很少数，而且往往是非典型的用户，不能保证其代表了目标用户的想法；而“骑墙的大多数”说的是，大多数人是没有明确观点的，尤其在网络这样一个不用负责任的环境下，所以常见的情况就是开始表态的那几个人的观点引导了群体的观点，随机的初始值决定了结果，这个时候你只有单独和跟风者交流，才会发现他根本不是那么想的。
调查问卷的客观性、多份问卷之间的独立性，可以有效避免上述问题，但其容易出现的问题在于：
第一，样本的偏差，即样本与想了解的目标用户群体出现偏差。
之前我们谈到，用户访谈由于样本量的限制，始终只能听到目标用户群体中很少部分用户的声音，而调查问卷可以更多地采样，我们应该充分利用。所以，调查问卷的样本选择，就有几个注意点【18】：尽可能覆盖目标群体中各种类型的用户，比如性别、年龄段、行业、收入等，要保证各种类型用户的样本比例接近全体的比例，比如目标用户中男女比例为7:3，那么我们的样本也应该保持这个比例。
但在实际工作中，经常会因为各种原因没法做到样本选择的合理性，比如我们的产品全国销售，但要做街头的拦截调查，出于成本考虑，只能选择特定城市的目标用户；又如利用网络做调查问卷，能在特定时间、特定页面上看到问卷的人，已经是一种筛选；再如在各种场景下，愿意填写问卷的人，也许与目标群体的整体也有不同，又是一种筛选。
所以，在类似情况下得出结论的时候，大家最好把这些潜在的筛选条件标明，让报告的读者知道数据获得的方法与来源，同时如果我们是报告的读者，也要一直带着问号去阅读里面的数据。
还有一个小技巧，就是可以把目标群体的特征也定义成一系列问题，放入问卷中，待我们回收问卷以后，就可以通过这些问题评估作答者是否能代表目标群体了。如果发现了偏差，我们也可以从回收的问卷中再筛选出一个接近目标群体的子集来分析。
第二，样本过少的问题。
样本量过少时，采用百分比来分析是没有意义的。这是很多新人会犯的错误，比如只问了5个人，3个人选A，就在报告中说有60％的用户选A，这是很不严谨的。因为如果换5个人再做一次，很可能就是40％了，而这样的数字百分比要具备稳定性才有价值。所以，此时只能说“问了5个用户，有3个用户选A”。抛开严谨的统计理论不谈，要给出百分比答案的话，至少得有大约100份的答案。
第三，问卷内容的细节问题。
首先，问题表述应无引导性，这点和用户访谈类似。比如，不要问“你喜欢某个产品吗”，这时用户可能会考虑到提问者的情感而回答“是”，正确的问法是“你是否喜欢某个产品？”
答案的顺序，可能产生“顺序偏差”或“位置偏差”，即被调查者选择的答案可能与该答案的排列位置有关。有研究表明，对陈述性选项被调查者趋向于选第一个或最后一个答案，特别是第一个答案；而对一组数字，如价格和打分，则趋向于取中间位置。为了减少顺序偏差，可以准备几种形式的问卷，每种形式的问卷选项排列的顺序都不同。
因此，对于重要的问卷，为了避免上述问题，还有个通用的办法就是先进行小范围的试答，根据反馈修改后，再大面积投放，这和互联网产品的灰度发布【19】有着同样的理念。
设计一份实际的问卷
我们来试着设计一份实际的问卷。和做任何产品一样，先想清楚目的，然后明确样本对象、调查渠道、时间计划等，最后才是问卷内容本身。
给大家举一个实例，我为这本书的读后反馈设计了一份调查问卷，有兴趣的读者可以做一下。
问卷目的：收集本书的读者反馈，总结得失，希望以后能做得更好。
样本对象：本书读者，扩大到博客读者，以及对产品经理感兴趣的人。
调查渠道：网络，个人博客上发布。
时间计划：本书上市后放出问卷，收集至少3个月后给出一份分析报告。
问卷内容：不断优化，你真正看到的可能与下面有区别。
同学你好，我是《人人都是产品经理》的作者苏杰，这个问卷是为了……，作答大约需要2分钟，完全匿名，非常感谢。
首先，是一些简单的问题，帮助我对作答者进行分类。
► 你看过《人人都是产品经理》这本书吗？单选
是，否
► 你看过“iamsujie的产品设计”这个博客吗？单选
是，否
► 你是怎么知道这个问卷的？单选
通过书，通过博客，其他网上渠道，其他线下渠道
然后，是一些我最想知道的问题。
► 你工作多久了？单选
还是学生，1年以内，1到2年，3到5年，6到10年，11年及以上
► 你是几岁的产品经理？单选
-1到0岁，1到2岁，3到5岁，6到10岁，11岁及以上
► 你的岗位？单选
产品经理，其他产品相关（如需求分析、用户体验、交互设计、运营），商业相关（如市场、销售、服务），技术相关（如开发、测试、架构、运维），各种管理岗位，其他
► 你的行业？单选
互联网，软件，其他IT类，其他
► 你的公司规模？单选
10人以下，10到100人，100到1000人，1000人以上
► 你工作中接触最多的主题？多选
用户，需求，项目，文档，流程，战略，修养，职场，其他
► 你希望我多说些什么主题？多选
用户，需求，项目，文档，流程，战略，修养，职场，其他
► 你觉得我的优势在于？多选
用户，需求，项目，文档，流程，战略，修养，职场，其他
► 你觉得我的劣势在于？多选
用户，需求，项目，文档，流程，战略，修养，职场，其他
接着，想了解一些你的情况。
► 你的性别？单选
男，女
► 你的年龄？单选
20岁以下，20到25岁，26到30岁，31到40岁，41岁及以上
► 你所在的城市？单选
北京，上海，杭州，深圳，广州，其他
► 你的月收入？选择
1k以下，1k到2k，2k到4k，4k到8k，8k到16k，16k以上
最后，还有什么想说的？
2.2.3 定性地做：可用性测试
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。
它是UGC【20】理念的一种很漂亮的实践，在目的明确的前提下，简单介绍一下主要过程。
首先要招募测试用户。招募测试用户的主要原则是，这些用户要能尽可能地代表将来真实的用户，比如说，如果产品的主要用户是新手，那么就应当选择一些对产品不熟悉的用户。
然后是准备测试任务，测试的组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。
接下来的重头戏是测试过程。可用性测试的基本过程就是用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。
测试结束后：组织者可以询问用户对于产品整体的主观看法或感觉。另外，如果用户在测试的过程中没有完全把思考的过程说出来，此时也可以询问他们当时的想法，询问他们为什么做出那些操作。
最后是研究和分析：在可用性测试结束之后，组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。
可用性测试的常见问题与对策
和用户访谈、调查问卷一样，可用性测试也有其特别需要注意的问题。
第一，如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了。
其实，可用性测试在产品的各个阶段都可以做。在尚无任何成型的产品时，可以拿竞争对手的产品给用户做；在产品只有纸面原型的时候，可以拿着手绘的产品，加上纸笔给用户做；在产品只有页面Demo的时候，可以拿Demo给用户做；更多的时候，在产品已经可以运行以后，可以拿真实的产品给用户做。不同阶段不同做法，从中都能发现相应的问题。
第二，总觉得可用性测试很专业，所以干脆不做。
可用性测试，听着很专业，但收益又无法量化，所以对很多老板来说，不太愿意在这个上面投入资源，经常因为项目时间过紧被略过。我们知道，可用性测试通常来说做5个左右的用户才可以发现大部分的共性问题，前前后后的准备也耗时不少，但只做一个用户，并且简化步骤，也比不做要好。
对一个内部使用的用户管理平台，我自己尝试过一次最轻量级的可用性测试，表现为：一个同事，半个小时，在我的座位上，简单的几个任务，比如“将XXX用户的有效期增加一年”，“将YYY公司的状态设置为冻结”，“查询ZZZ公司的员工数”等。结果发现了十几个问题，效率很高。
第三，明确是测试产品，而不是测试用户。
可用性测试要邀请用户来做测试人员，我们在开始之前，应当明确地告诉用户，这个测试的目的是发现软件产品中的问题，而不是要测试用户是否有能力来很好地使用软件。所以，不要让用户听到“可用性测试”的术语，而是说“来试用一下我们的新产品，提点意见”。清楚地说明这一点将有助于减轻用户的压力，使得他们能像在真实环境中一样来使用软件。
第四，测试过程中，组织者该做的和不该做的。
刚开始的时候，可以告知用户大概持续的时间，要做哪些事情，让用户心中有数，轻松愉快地完成任务。
可用性测试中，我们可以要求用户在使用产品的过程中采用一种名为“发声思维”的方法，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作等。
做测试的过程中千万不要有任何的引导与暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，实在进行不下去的时候，给予提示。记住，一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了。
结束之后，如有可能应该送个小礼品，当然在邀请的时候就要告诉用户会有一些对他付出时间的补偿。尽快总结，并且发给用户，一方面让用户感到他做了一件有意义的事，另一方面也是表示感谢，建立长期和谐的“用户参与产品设计”的氛围。最重要的，这份总结要用于指导产品改进，这才是可用性测试的根本目的。
产品改版的一次冒险
每一个优秀的产品（Gmail、豆瓣（douban.com）、微信也许是），都是靠着不断的升级、优化、改版才逐渐获得认可的。改版的初衷都是为了产品升级，更好地服务用户，但改版在客观上会挑战用户现有的习惯，所以必须慎之又慎。可用性测试就是一种很合适的方法，来保证产品改版的安全性。对于一个产品经理来说，如何在合适的时机推动一次合理的改版，是一大考验，本节回忆2007年我发起的一次产品改版——网店版从1.0升级到2.0，当时的可用性测试做得太晚，想想真是后怕。
这次改版在页面风格上有极大的变化，如图2-5、图2-6所示，网店版1.0的时候，考虑到我们的目标用户全部是淘宝的大卖家，所以沿用了淘宝网“我的淘宝”的页面风格，之后的几个月，随着产品的发展，我们发现在1.0的页面框架下，很多功能设计起来都要瞻前顾后，所以决定颠覆性地把导航菜单从左侧移到上方，释放页面空间，并且改变了很多交互、视觉的细节。
图2-5 网店版1.0首页示意图
图2-6 网店版2.0首页示意图
整个过程几乎完全凭借我们的喜好改进，直到上线前几天，才叫了几个用户来做可用性测试，而这时候其实我们已经知道没时间改了，只是想听用户说一声“Yes”来增强自己的信心，如果这时候用户说“No”，绝对是一个灾难。
好在参加测试的用户对我们说了“Yes”，上线后数据分析的答案也是“Yes”，我们才没有因为缺乏经验而造成太多损失。在这之后，我再也不敢这么晚才做可用性测试，联想一下淘宝网“我的淘宝”曾经做过的改版、2007年底豆瓣为了庆祝注册用户过100万的改版、2009年百度贴吧的改版，都因为用户的反对声音太大不得已道歉、改回去，我们真的很幸运。
不好的过程，还算OK的结果，让我事后去恶补了不少常识，对于改版，除了“可用性测试”要在足够早的时候做以外，发布后也是有一些方法改进的。
比如先从部分次级页面改起，像“我的淘宝”历时多年的改版；
再如新旧版本并存一段时间，并允许用户自由选择，比如2007年的雅虎邮箱和新浪邮箱改版；
三如小面积试验，选择一小批测试用户放出新版本，监测效果，做用户调研，比如Gmail在发布某些新功能的时候；
四如傍上一个用户已经习惯的风格，比如网店版的前身“高级店铺”升级到网店版1.0的时候，讨论了很多方案，最终还是决定模仿“我的淘宝”的页面风格。
总之，对于改版，对于升级，我们要把“暴力革命”变成温柔和谐的“和平演变”。
2.2.4 定量地做：数据分析
只要你做的是一个大用户量的产品（互联网产品往往都有这个特点），那么我们总会惴惴不安：上述3种方法，就算做问卷的普查，回收到的有效问卷也可能不到用户总数的10％，或者说，在样本的选择上都有一定的被动性——需要样本同意参与，所以它们都只能接触特定的少部分用户，那么到底能不能代表目标用户群体？
虽然绝大多数情况下的经验证明，只要在用户的选择上没犯什么低级错误，他们是“具有代表性的”，或者说接受这种假设是一种性价比很高的廉价解决方案。不过，我们还有数据分析，一种定量的研究方法，数据来说话，看看用户到底是怎么做的，不论是考察目标用户全体、还是采样，都完全可控，所谓“According to the data”是最难被驳倒的。
数据分析时，根据不同的目的，数据来源多种多样，常见的有用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等。数据分析的方法，最简单的可以用Excel，复杂一点的可以用一些统计软件、数据库软件，或者直接自己写程序解决。而最关键的就是对结果的解读，通常数据分析只能发现一些现象和问题，并不能了解原因，所以分析完成后通常会伴随着一些用户访谈，听听用户怎么解释。
数据分析的常见问题与对策
我们要意识到，用户“怎么说”和“怎么做”不同，甚至经常有矛盾，有时候用户的行为比语言更能反映出他的真实需求。比如用户说在搜索买家的时候应该加一个“按交易额搜索”的条件，也许只是他某次特殊的需要使然，但如果我们听他的做了这个功能，之后通过用户行为的数据分析发现，只有1/10000的人用过，那就表明我们被用户的说法骗了，但数据永远不会骗我们。不过，在数据分析时也会有一些特定的问题，下面让我们逐一分析。
第一，过于学术，沉迷于“科学研究”。
我在读研的时候，做的就是统计分析、数据挖掘相关的课题，所以工作中开始遇到数据分析的时候，我挺兴奋的，感觉可以好好地研究一番了。但渐渐我体会到，实际的生产和科研是有很大不同的。科学研究通常只注重“性价比”的性，只要结果好，方向新，往往不在乎投入，因为相对而言科研的结果不是为了马上应用，而是为了证明实力。
但实际生产环境就更注重综合的性价比了，所以我们日常的数据分析方法也就显得不那么严谨了，我特指小步快跑的创业团队，他们可能不需要在每次分析前都去验证样本群体是否符合某种统计分布，也可能不需要用“人工神经网络”等“高科技手段”去预测产品将来的用户数，甚至给出“A>B”的结论时也用不着做“显著性检验”，一切的一切需要的只是一种感觉，一种对数据的敏感，对商业的敏感。
第二，虽然数据不会主动骗人，但我们经常无意或有意地误读数据。
无意地误读数据，举个例子，对一个人群，人们的身高用平均数来衡量是有意义的，因为我们知道身高属于典型的正态分布，中间多两边少，所以一个平均值就能了解群体的大致情况，而对人们的收入，就不能用平均值来衡量了，一个超级富豪和1000个零收入的人一平均，很可能得出人均收入100万的荒谬结论。这个问题的对策，是学习统计学的知识【21】，努力提高自己的水平。
主动地误读数据，是比较有趣的现象。在提取数据之前，我们心中通常已经有一些结论了，无非是想验证它，而抱着这点思想，就总能找到数据来证明自己已有的想法，并且技术越娴熟的人越容易做到这点。对于这点，我想一个简单的对策就是对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯，比如为了证明老板的判断，或者为了保持自己之前拍脑袋的英明形象等，你明白我的意思。
第三，平时不烧香，临时抱佛脚。
这是一个很实际的问题，我们经常在做决策的时候才想起数据分析，但忽然发现手头没有数据可分析。一次又一次地发生同样的情况……为了避免，我们应该在产品设计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等，这也算一种典型的非功能需求，这样做对产品的可持续发展非常必要。
日志分析的商业价值
下面举个小例子，看看数据分析是如何转化为商业价值的。整体的思路是：在对产品足够熟悉的基础上，先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。
2008年底的时候，我们希望产品的用户能更活跃，活跃的衡量指标是更多的登录次数，方向确定之后，我们假设有方法可以促使某类用户更多地登录，于是对产品的用户登录日志【22】做了一些分析，希望找到方法和对应的用户。结果，发现了一条很有趣的曲线，如图2-7所示。
图2-7 用户登录产品的情况【23】
直接看图，图中的横轴是把所有付费用户的第一次登录日期对齐，表示用户从这一天开始使用产品，查看他们在此之后半年，也就是180天的活跃情况；纵轴是这几千家公司的总体活跃情况，可以简单地理解成纵轴数值越高，用户登录次数越多。可以看到，活跃公司比例的变化明显分为4期，特别是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人天，也就是两个人一周半的时间。整理报销费用的时候，我简单算了一下，给上门的用户礼品平均每家50元，差旅费用，在选了本地和附近用户的基础上，均摊到每家，大约150元，人力成本1人天粗略记为500元，平均分摊给最终上门的10家用户，每家大约要1000元人民币，不算不知道，确实挺贵的……这还只是很简单的调研，所以用户研究的成本真的很高，很多小公司都能省则省，我们很无奈，老板也很无奈，以后在抱怨老板没用户研究意识的时候，也需要体谅一下他们的难处。
2.2.5 需求采集人人有责
上面用很大篇幅说了一些常用的需求采集方法，这一节，我想先抛出一个“一手需求与二手需求”的概念，有个很形象的比喻就是“生孩子与养孩子”，话糙理不糙，我们内部经常这么说。
我们首先把“生孩子”——需求采集视为己任，人人有责，希望所有人都参与，都来“生孩子”，我们帮大家养，这就要给他们一个简单的“生孩子”的工具——“单项需求卡片”，最后，简单介绍一下其他常用的方法，这样才能做到“尽可能多地采集”。
生孩子与养孩子
之前所述的各种方法，都是直接从用户那里得到需求，我称之为一手需求，就像“生孩子”。其实很多时候，我们还会接受二手需求，比如老板说要给用户做个××功能、销售人员说用户哪里用起来不顺等，这些需求和一手需求比起来，就像“养孩子”。
“生孩子”，更多的时候发生于新产品诞生前，这时候外部没有用户，内部没有运营、销售、服务等，所以对于需求而言，更多的是产品人员驱动，去主动采集需求，比较常见的就是直接去潜在的目标用户那里采集。这个从无到有的过程，个人觉得发挥的空间最大，是最有成就感的。
小明：“还是‘生孩子’好啊，痛并快乐着……”
而“养孩子”，通常是产品已经运行了一段时间以后，用户也有了，公司内部也多了很多相关的人员，比如销售和服务。虽然产品部门与用户的直接接触变少，但多了很多间接来源，即与终端用户接触的干系人，他们会向你反馈很多需求，而用户也开始主动提出需求了。
对比一下，生孩子的时候，我们去主动“拉”需求的比例较高，需求都是直接从用户那里得到的，有点“进攻”的感觉，而孩子生出来以后，就不再是你一个人的孩子了，必然是大家一起养，所以我们需要照顾的各方各面也会更多，我们会收到很多“推”过来的需求，比较像“防守”的感觉。
有很多同学从一开始工作接触的就是已经存在的老产品，需求始终堆积如山，如果碰上销售强势的产品，那更是连响应销售提过来的需求都来不及，也许做了半年一年，突然回想，发现自己连真正的用户都从来没接触过，而是始终在满足销售的需求。个人感觉，这种二手需求，或多或少有扭曲，以销售为例，他们的考核指标决定了会比较注重眼前，希望产品的卖点越多越好，而之后用户用得如何，就不那么关心了。比如我就经历过一些让人很抓狂的二手需求，销售希望产品增加一个功能，这个功能在说服客户购买产品时有“临门一脚”的作用；而用户买完以后，最好又别用这个功能，以免增加服务部门的压力……所以在公司层面上看，我觉得产品部门至少应该和销售、服务等部门有平等的地位，坚持不懈地从终端用户那里直接获得需求，才能保证产品的可持续发展。
但二手需求毕竟是常态，我们经常接到的就是口头上的几句话，或者一封邮件的几行说明，这中间理解的偏差只能靠我们主动的、反复的沟通来弥补，那么有没有什么办法解决呢？下面我就介绍一种简单的二手需求采集工具——单项需求卡片。
单项需求卡片
单项需求卡片的理念就是：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程，理想的状态是产品的所有干系人都参加过“需求采集”的培训，然后在日常工作中养成主动提交需求给产品人员的习惯，但实际很难做到，所以作为专业的需求分析人员，就应该尽量降低同事们，比如销售、服务、技术人员提交需求的成本，也是节省我们自己的时间。
一张单项需求卡片描述了一个用户的需求到底包含哪些内容，重点是描述用户场景，谁在什么时间、地点产生了何种需求，先看一个模板，如表2-3所示。
表2-3 单项需求卡片模板
由于填写卡片的人经常不是专业的需求人员，所以卡片的质量无法保证，比如下面这个例子就是一个典型，如图2-9所示。
图2-9 单项需求卡片实例
图2-9是工程师提的一个需求，就像我们永远无法猜到用户会怎么使用我们的产品一样，“单向需求卡片”原本是让大家给产品提需求，而工程师却拿它来给产品经理提意见，很有意思。从表格的填写就可以看出来，实际工作中我们能拿到的都是填写不完整的，甚至是字迹难以辨认的，当然，也可以尝试电子版，那样我们整理的成本低一些，不过很可能愿意填的人就少了。但我们心里得有个底线，一张有价值的单项需求卡片，至少得有“需求描述”，需求编号、来源、场景最好也能有，其他的，其实很少有人愿意填写了。
回到这张卡片，工程师描述的一个需求也很有意思，值得我们共勉——“PD慎重地考虑一些细节的改变，在没有大影响的前提下，不要对稳定的版本做一些鸡毛蒜皮的动作”。工程师们也希望自己做的事情都能产生商业价值啊。
每当我们拿到这样的卡片，就需要主动去和提交人交流，完善卡片的内容。真实的工作中你能体会到，这张卡片只是需求过程的中间产物，所以我们在这上面花费的精力也是尽量缩减，单向需求卡片所描述的用户需求，最终要转化为产品需求才有真正的价值。
尽可能多地采集
需求采集，并不是产品设计之前的工作，而是一个贯穿始终的过程；它并不是产品人员的事情，而是所有人的责任；它没有特定的方法，不管白猫黑猫，抓到老鼠就是好猫；它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求……这才是需求采集的大生产运动。
最后再简单分享几个有特点的需求采集方法，希望大家能灵活应用，尽可能多地采集。
现场调查。说简单一点就是打入“敌人”内部，和客户一起工作一段时间，深度了解需求。它是一种典型的定性分析，持续时间长，从几个小时到几个月，既能听到用户怎么说，也能看到用户怎么做，不过受众面极其狭窄，一次只有一个，要特别小心被“非典型”用户带到沟里去。
AB测试。基于大用户量比较合适，比如有一个按钮不知道是放在页面的左边好，还是右边好，而我们有10万个用户，那就先随机挑选少量的用户发布这个按钮，1000个人放左边，另外1000个人放右边，然后过一段时间分析结果，再决定剩下的98％用户该怎么办。很明显，这也是让用户直接参与了设计，这样低成本的方法让很多传统行业的同学羡慕不已。
日记研究。互联网新兴的个人应用比较适合，某个新产品出来以后，很多业内的朋友都会去尝试，然后写一些使用体会，但作为产品设计者在看这些日记的时候，要明白日记的作者往往是同行，而不是主流用户。
卡片分类法。我们把产品的各种需求写在便利贴上，让用户一起讨论并完成分类。这能让你深入了解用户是怎么给产品划分模块的，用户认为这个网站应该是什么结构。因为产品设计人员的思维和用户的思维通常不一样，这也就导致了如果是产品设计师来单方面决定网站结构的话，很可能导致用户理解的困难，所以卡片分类法能让最终的产品更加符合用户的心理模型。
自己提需求。这是最简单的方法。每一个靠谱的产品都会有一群粉丝用户，不用你去找他们采集需求，他们也会给我们惊喜，主动提出很多需求，作为产品的主人，我们好意思还没有用户了解产品么？产品要用才能感觉出好坏，特别是自己做的产品。产品做多了，我们随便看看别人做的产品，总能一下子挑出很多问题，提出很多需求，反过来看自己的产品越看越完美，这一定有问题，所以必须用自己的产品，最好是发动认识的人都来用。
需求采集的各种新方法层出不穷。和学习任何领域的知识一样，建议大家在了解知识框架后，坚持“需求驱动学习”。
2.3 听用户的但不要照着做
采集了很多需求，但是一团乱麻，从哪里着手？
用户都帮我们想好该怎么做了，照他说的做吗？
在开始需求分析之前，我们先回到2007年7月——我写了一篇里程碑意义的博文，是《产品设计体会》的第一篇，也可以看做是为这本书写的第一笔。
2007年6月28日，网店版2.0上线，这是我主导的第一个付费产品，之后的三周我基本天天都会在淘宝论坛上泡不少时间，最大的体会就是：要听用户的意见，但不要照着做。
有的用户很“危险”，在提意见的同时还说你们应该做成什么样子，这时候产品经理一定要头脑清醒，用户提的解决方案往往是站在自己的立场上考虑的。比如对“快递单打印”的功能，用户提出要添加一个他经常用的小快递公司的快递单模板，而我们会发现，这家快递公司可能只是一个区域性的快递，最终的解决方案是做了一个“自定义快递单”的功能。
有时候，用户给出的做法存在明显的逻辑矛盾，就算他给出的解决方案合理，也要再深挖用户内心根本的需求，比如用户描述“新建非支付宝交易订单的时候必须要选择用户不合理，希望能自己填写客户”。这里更深层的需求就可能是他需要把线下客户也管理起来，所以我们或许更应该做一个新增线下客户的功能，而不是在新建非支付宝交易的时候让用户自己填写客户姓名。
我们是产品经理、产品设计师，最终怎么做应该由我们决定。
2.3.1 明确我们存在的价值
用户跟福特要一匹更快的马，福特却给了用户一辆车。
这就是我们存在的价值。还记得小明吗？
他说他需要一个电钻，这是他提出的解决方案，但在大毛的刨根问底之下，发现小明其实想要的是一种温馨的家的感觉，有了这个认识，我们就可以给出很多产品来满足。比如卖他一套实施方案，带着电钻、油画，上门安装；比如用背面有强力胶的钩子挂画；比如直接把画黏在墙上；比如直接在墙上画，并且让小明自己画；再比如放一组书架在那里……经过我们分析得到的解决方案，比起小明自己说的，优势就在于可能省了钱、省了时间、更温馨等。
对同一个问题，这两套解决方案的区别就是，一个是用户需求，一个是产品需求。而这中间的转化过程，就是这节的主题——需求分析。
用户需求VS.产品需求
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程【24】。
听到过一个说法，说需求分析与常见的技术分析最大不同是思路的本质差异，技术分析是“树干——树枝——树叶”的任务分解过程，技术人员很适应并乐于用这种方式思考，可以把大问题分解成小问题，发现难点逐一攻克。不少需求人员都是做技术出身的，所以开始往往会用这种思路做需求，听到客户提出的功能点，直接想怎么做系统设计了，这导致有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。大多数人在生活中也习惯于用这样的思路来对付问题，而真实情况是，需求分析是“首先：树叶——树枝——树干，其次：树干——树枝——树叶”的分析过程，所以说完整的需求分析是一个“分-总-分”的过程。一方面不能漏掉提炼用户需求的这个过程，目的是透过现象看本质，另一方面也不能停在本质上，试想如果做到“树干”就结束，后端的执行人员可能还是不知道要做什么东西，所以我们还要继续把树干再重新分解成树枝、树叶。
小明又出现了，这次他说要吃猪骨头火锅（用户需求），80块吧，但没想到又碰到了大毛。
“真的想吃？”
“想吃！”
“为什么？”
“我饿了……”（找到了本质！）
“哦，这里是两个馒头（产品需求），请你吃，才1块钱。”
“……”
小明无比不爽，但没办法，真的饿，还是吃了。
大毛是这样分析的，想吃猪骨头火锅，这个用户需求无非两个原因——饿了或者馋了。如果他真的是馋了，那就吃吧，不过如果是饿了，那我完全可以用一个低成本的解决方案——馒头。虽然小明眉头紧锁，但现在经济不景气，毕竟节省了98.75％的成本啊！
伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西，这就是本节标题的意思——我们存在的价值。
说到这里有必要提一下，销售人员经常说：“用户是为想要的东西买单，而不是需要的”，用我们上面分析翻译一下，其实是“用户是为自己提出的解决方案买单，而不是我们的解决方案”。是不是很纠结？那我们还分析个什么劲啊，直接做用户要我们做的得了。
其实这是短期利益和长期利益的权衡，如果是一锤子买卖，卖出以后又不用售后，那么采用实用主义，不妨用户要什么就给他什么，这样他掏钱最爽快，你回忆一下在风景区买的纪念品的情景，大多数情况下，是不是你要啥卖家就给你啥？这种情况下就要追求短期利益。但是，我们的产品通常都是希望用户长期使用的，并且后续的服务也是我们来做，所以为了长期利益，我们就有必要找到用户的真实需求，然后给他真正合适的产品了，哪怕这个过程不那么讨好。不知道你有没有帮女生买电脑的经历，帮她买也就意味着将来的售后服务、技术支持、维修都是你了，所以你才会在型号和配置上和她争吵，努力说服她不要买那些中看不中用的，而要买“真正的需求”。
满足需求的三种方式
我们通过产品需求来满足用户，顺着这个思路，就是要做一些用户真正需要的功能或服务，虽然这是最常用的办法，但也是最“劳民伤财”的。在甩开膀子干活前，我们有必要扩展一下思路，从问题的本质出发，寻找新路。
之前我们说过，需求来源于理想与现实的差距，那么减小这个差距就有三种方式：
改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法。
降低理想。不要忽视精神的力量，什么“打预防针”、“丑话说在前头”这类句子想必大家都经常听到。
转移需求。因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会觉得这个差距没那么可憎了。我们也可以说，人的行为是需求驱动的，想改变人的行为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求。
给大家说一个写字楼电梯的故事。
某写字楼可能是因为建造得比较早，考虑不周，电梯明显不够用，每天中午吃饭的时候总是很挤，最上面几层的小白领们平均要等20分钟才能下到3楼的餐厅吃饭，于是抱怨很多，他们给物业提意见，要求解决。物业公司找到了大毛，大毛帮他们分析了一下。
改变现状。对现有产品做一些改进，在这个案例中就是增加电梯数目，或者加快电梯运行速度，但成本太高，直接被否定。
降低理想。告诉楼里的小白领们，隔壁那个写字楼中午要等40分钟呢。俗话说“不患寡而患不均”，人们更在意的是相对而不是绝对，这样确实可以减少抱怨，但是一种低水平的满足需求，对产品美誉度没有帮助。
转移需求。电梯门上贴一些锻炼身体的公益广告，当然内容是说爬楼有益身体健康。有效，部分用户走楼梯去餐厅了，但是刚吃过饭怎么办？爬几十层楼要得阑尾炎的。最后，采用了一个看起来很傻的方案，在电梯门旁边安装一面镜子，让等待的人们可以整理一下仪表，或者搔首弄姿一番，不至于那么无聊。
我们后来发现还有其他的解决方案，比如电梯广告，不但可以转移用户注意力，减少抱怨，而且对写字楼来说，既不用花钱，又额外挣得一笔广告费；又如错开午饭时间，让人们都能更少地等待。所有这些，都是想告诉大家，满足用户的需求，不一定要做新产品或者新功能，而是更应该想想是否有“四两拨千斤”的妙招。
也谈创造需求
满足需求的方式，我们开阔了思路以后从一种变为了三种，但毕竟都是用户提出来的需求，我们能不能再开阔一点？不劳用户的大驾，直接达到产品设计的最高境界——创造需求！
工作中典型的场景，就是老板或者产品人员的突发奇想，这些灵感在潜意识里都有一定的依据，是基于对用户、市场、产品的充分理解，也有过不少案例，这些需求最终获得了用户的认可，但更多地被证明是过于天马行空。
苹果公司的乔布斯，可以说是创造需求的大师，但我不建议大家学，这是需要天赋的，但这份天赋非常值得保护，产品的进化和生物的进化一样，需要如基因突变一般的胡思乱想。而且，有不少人只看到了乔布斯的“不照着做”，没有看到他之前“听用户的”过程。
更实际的，我认为需求分析的过程其实也有创造需求的成分，当一个新人真的能力不足的时候，不妨先做用户提出的需求，而不要自己去胡乱分析用户需求，而对于一个团队来说，要尽量避免“只有能力不足的需求分析人员”这种情况出现。
我们刚上路，既要怀揣梦想，也要脚踏实地，所以接下来我们老老实实地开始给需求做一次DNA检测。
2.3.2 给需求做一次DNA检测
整个检测过程不妨用如图2-10所示的示意图来表示，我们先把用户需求转化为产品需求，然后一步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。
图2-10 需求的DNA检测过程
特别提一下，这里确定的是产品需求的各种属性，不同于之前提到的“单项需求卡片”，那张卡片里描述的是用户需求的各种属性。
把用户需求转化为产品需求
检测的第一步就是“需求转化”，现在我们有很多用户需求，可能记录在“单项需求卡片”里，可能记录在Excel里，可能是用Word随意写的几段话，也可能是一张思维导图，如图2-11所示，图看不清没关系，我只是想表达采集来的需求非常多。当然，在一个团队里，还是建议大家统一一种记录用户需求的形式。
图2-11 网店版的一部分用户需求
现在我们就要发挥出“我们存在的价值”，在这个阶段，团队经常举行头脑风暴【25】，大家天马行空地讨论一番之后，对用户提出的需求有了比较全面的了解，对用户的内心世界有了比较统一的认识，对我们的解决方案也有了一些不成熟的想法，然后通常每个人分一块，去把它们都转化为产品需求，最后记录在一起。
举个例子，对于我经常做的软件产品，用户需求是“删除数据之前需要我确认，以免误删”，转化分析以后，我们给出的产品需求可能是“数据回收站：删除的数据进入回收站，如果是误删，用户可以去回收站找回数据”。
因为我做的几个产品都是用Excel来记录需求的，所以下面也以Excel为例来讲述，大家可以用其他工具来记录需求，但核心思路都是大同小异的。整理好的产品需求列表如图2-12所示，因为有商业隐私问题，所以我把具体内容弱化了。我们把它叫做Feature List（功能列表）。一些Excel的简单技巧，建议大家还是学习一下，比如条件格式、筛选、单元格有效性、单元格锁定、隐藏等，可以让表格管理起来轻松一点，看起来也美观一点。
图2-12 产品需求的列表
表格中每一行是一个产品需求，而每一列描述了产品需求的一种属性。
值得一提的是，用户需求与产品需求是多对多的关系，我们可能用多个功能来满足一个用户需求，也可能用一个功能来满足多个用户需求，甚至是用几个产品需求来满足几个用户需求，其中并没有一一对应的关系。
对任何产品来说，只要需求采集的工夫做足了，你就会发现上面这个产品需求列表行数超多，所以在需求转化过程中，我们也会做一轮筛选，把明显不靠谱的用户需求直接过滤掉，不计入上述列表，当然，是否“明显不靠谱”就要由你来把握了，不要把“没资源做”、“短期内有技术难点”的用户需求给错杀了。
小明：“我知道了，我想去火星就是明显不靠谱，而想去月球就是钱不够的问题。”
大毛：“那也是明显不靠谱……你想去欧洲玩一个月才是钱不够的问题。”
确定需求的基本属性
对于产品需求列表的维护，有时候我们是在产品团队里指定一个人负责，所有的需求都由他来录入，有时候是采取共享文档的形式，大家共同维护，更多相关话题我会在第3.5.1节的“多人协作与版本管理”中和大家讨论，但不管怎样，我觉得对于每个需求，提交人都可以独立确定一些基本属性，这些属性如表2-4所示。
表2-4 需求的基本属性
编号：看似作用不大，最初表格中没有这一项，但有一次大家把列表打印出来讨论，当提到某个需求的时候，发现很难告诉大家是哪个，因为Excel的行号没有一并打印出来，所以后来我们都把序号加上了，作为需求的唯一性标识。有时候在某个需求的备注里，也会写“与273号需求类似，可以参考”。
提交人：必填，提交人是PD，我们的需求管理方法比较轻量级，更多的是只管理产品需求，而用户需求并没有很好的整理，经常只是一堆各种格式的文档，所以提交人要负责在今后的任何时候解释这个需求的来源，提交人有义务充分理解原始的用户需求。
提交时间：这是一个辅助信息，记录提交人是何时录入这个需求的。
模块：一般来说，根据人类记忆的特点，产品有5±2个模块比较合理，如果超过7个，你就要考虑重新划分，甚至增加一个基本属性叫“二级模块”。如果你是做网站产品，这些模块的划分就很可能影响到网站的导航结构，这属于信息架构【26】领域的知识。当然，在设置自己电脑里的文件目录结构时，也可以遵循这个原则。
举个例子，如图2-13的网店版菜单结构，就可以从其产品需求列表里的“模块”设置里看出来。
图2-13 网店版的需求模块与菜单结构
名称：用简洁的短语描述需求，要给用户提供什么功能，比如黑名单。
描述：这里可以具体解释一下名称里说的功能是什么意思，比如用户可以选择联系人并加入黑名单，或者将某联系人移出黑名单，在黑名单里的联系人无法给用户发消息。描述只要说此功能要做什么，无须解释怎么做，注意语言的无歧义性、完整性、一致性和可测试性等，关于具体怎么写，可以参考第3.3.1节中“用例文档，UC”里的讲解。
提出者：即用户需求的提出者，有疑惑时便于更进一步追溯。
提出时间：原始需求的提出时间，区别于提交时间，这是个辅助信息。
Bug编号：可选，这是因为我们把产品的某些Bug也视为需求，所以加入这个表格统一管理。
上述基本属性只是我做过的产品中常用的，大家可以按照自己产品的不同自由定义，原则是为了便于需求的管理。对比一些需求管理软件，这里的处理已经很简化了，尤其是表2-4中标了星号（*）的几项，是产品做大、需求增多的过程中必需的。
需求种类知多少
然后，需求的提出者需要自己辨别一下这个需求的种类，为后续的商业价值判断提供一些辅助信息。我们尝试过几个维度，如表2-5所示。
表2-5 需求的种类
分类：可以分为“新增功能、功能改进、体验提升、Bug修复、内部需求”等。
其实产品需求远非我们直接可以想到的功能需求，还包括了很多非功能需求，比如：性能、可培训、可维护、可扩展……有很多需求不是为终端用户做的，而是为销售、服务、测试团队的同学做的。
举几个例子，“论坛需要支持1000人同时在线”，这是一个性能需求；“系统功能升级，必须在发布2周以前完成对客服部门的培训”，这是一个培训需求；“如果硬件压力突增，应该有报警，具体细节是……”，这是一个运维部门的维护需求；“在用户数增加10倍的情况下，硬件投入必须小于10倍”，这是一个可扩展需求；“此功能的用户操作日志需要记录”，这是一个内部数据分析的需求。
当然，对于一些边缘的需求，是列入这个表格统一管理，还是另外单独对付，这可以随机应变。
通常来说“产品功能需求+产品非功能需求＝产品需求”，而“产品需求+市场需求+开发需求+测试需求+服务需求+……＝产品包需求”，对这些概念感兴趣的同学可以去查阅“需求管理”相关的资料。
层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，理论依据参见KANO模型【27】。
小明：“我想到一个手机的例子，打电话、发短信是基本功能；给电话录音是扩展功能，和基本功能相关；而如果这个电话特别结实，可以当锤子砸钉子，或者当砖头防身，那就是增值功能了。”
大毛：“嗯，好多山寨手机的特点就在于满足了一些诡异的增值需求，比如可以当手电筒、当验钞机、当剃须刀……”
小明：“你是在夸还是在贬呢？”
大毛：“我也不知道，那些已经超出普通手机的范畴了……”
对需求种类的区分其实没那么绝对，取决于很多因素，比如商业目的变了，某个功能的分类也就变了，我自己经常从“雪中送炭”还是“锦上添花”的角度去理解：雪中送炭是基本功能，对用户很有用，产品缺了这个功能根本跑不起来，比如E-mail系统里的“收发邮件”；锦上添花的功能是指非必须的，用户有时用得到，有的话会给用户的使用带来方便，比如在发E-mail填写收件人的时候，系统根据你输入的内容自动提示你曾经发送过邮件的联系人，如图2-14所示。
图2-14 Gmail的收件人提示功能
我们在和用户接触的过程中会很明显地感受到这两种需求的不同，没有雪中送炭的功能就像系统有缺陷一样，所以应优先考虑。而当一个锦上添花的功能被用户普遍接受以后，几乎所有的产品也都拥有了，也就渐渐提升为雪中送炭的功能了，就像现在的手机，几乎没有人能接受黑白屏一样，当初彩屏可是作为一大卖点来宣传的。
分析需求的商业价值
一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的，所以“需求的商业价值”是最关键的内容，有条件的团队最好利用群体智慧，我们通常在这个时候举行“需求讨论会”。
正因为商业价值如此重要，所以最复杂的时候我们尝试过用重要性、紧急度、持续时间3个指标来衡量，如表2-6所示。
表2-6 需求的商业价值
重要性：可以参考时间管理里“重要与紧急”的概念。这里的重要度又可细分为满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼”，更多可以学习KANO模型加深理解。
紧急度：在时间维度上判断这个需求是否迫切，紧急不重要的需求通常表现为解决了短期的问题，如果熬过去没做，对长期影响不大；或者解决了局部的问题，如果不做对于大多数用户没有影响。比如某个用户是大老板的朋友，通过大老板“天外飞仙”地提过来一个需求，就很可能是一个超级紧急的需求，但重要性未必很高。
持续时间：需求是有生命的，有的长寿有的短寿，比如迎合过年过节的运营活动需求，一般就比较短寿。试想8月我们录入了一个国庆的主题运营活动，如果到了9月底还没有资源做，那一年内也就不用再考虑这个需求了。
商业价值，或者叫商业优先级，是对上述几种商业价值指标的综合评判。这一条是整个需求列表中最核心的部分，这里的判断直接影响着产品未来的方向。有时候我们还在列表里增加一列“商业价值描述”，通俗点就是这个需求的卖点是什么，可以给用户提供什么价值，对公司又有什么帮助。
如此重要的商业价值评估，我们的做法是在需求讨论会上由产品团队集体讨论，再叫上有必要的干系人，比如销售、服务等。对于某个需求，需求提交人是对它最熟悉的，提交人先基于自己对商业目标的理解，做一番陈述，主观定个级别，比如高中低。然后大家讨论，所以在这个讨论会之前，每个人都应该做好功课。
尚书那么多的维度，可以加权平均得到综合的商业价值，我们甚至还尝试过在列表中增加“某关键人物的打分”一列，但绝大多数实际操作中，我们都是直接把商业价值抽象为一个指标，用“高、中、低”，或者“5、4、3、2、1”来衡量。而具体讨论的时候，大家充分表达意见之后，安全的做法是谁官大谁负责，俗称老板拍脑袋，最终由会场上级别最高的人报一个数字结束，这就是现实，也是一种高效的办法。我曾经考虑过群体打分取均值等方式，可是实施起来成本太高，很难推动，也不是很有必要。
初评需求的实现难度
绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。
我们现在知道了每个需求的商业价值，接下来决定做哪个还需要另一个关键指标，那就是——实现难度。有时候我们会叫上技术人员代表参与需求讨论会，当场确定这个指标，但更多的情况是留给做技术的同学一点时间，会后与相关的PD讨论确定。
但实现难度这个词太难量化，所以在实际操作中我们会对它进行大刀阔斧的简化。
首先简化为人力成本，即工作量，其他资源的消耗，比如额外的硬件成本，我们会发现只有极少数的需求会有这样的问题，不具有普遍性，所以碰到的时候都做特例处理。
其次，我们把工作量再简化为开发量。我经历的项目，各类人力资源有：产品、开发、测试、服务等。但一般情况下，团队里产品人员资源相对富裕，测试资源可以调配，服务资源可以临时补充，所以开发资源经常成为瓶颈。于是，我们一般评估每个需求的开发工程师工作量来表征其实现难度，这背后的道理是以团队里的瓶颈资源为评估基准，如表2-7所示，大家视自己团队的情况灵活应用。
表2-7 需求的开发量
在这个时候，需求其实并不明确，只知道要做哪些，还是比较粗略的要点，而具体怎么做根本还没有考虑，所以有的技术人员会觉得无法评估开发量，这很正常，这个问题我们和技术人员纠结过许多次。他们说你们不明确每个需求怎么做，他们就无法准确评估开发量，我们说没那么多时间明确每个需求该怎么做，你们不评估每个需求的开发量，我们就不知道哪些值得进一步分析怎么做，而哪些又不值……于是就死循环了。这类先有鸡还是先有蛋的问题也无须纠缠，我们继续讲实际的。
开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的人来评估，通常是技术经理，或者系统分析师、架构师。他们做出简单的评估，并且靠不断的实践来反复修正，评估者通常估计自己做这个需求要多少时间，然后乘以一个系数，这个系数大于1，反映着相应技术团队的平均技术能力。这里的评估一般用“人天”作为单位，某个需求需要“1人天”意味着需要1个人做1个工作日。
相对于“初评”，在项目启动之后，制定项目开发计划的时候还会有一次更精确的评估，那时候需求怎么做已经知道、由哪位开发工程师来做也知道，所以可以推算出相对准确的工期，工期和工作量是有很大区别的，比如生一个小孩，需要1个女人10个月的时间，工作量可以说“10人月”，但10个女人1个月的时间，同样“10人月”是绝对完成不了这个任务的，不管几个人，工期都只能是10个月……这个话题在第3章还有机会慢慢谈。
性价比啊性价比
我们已经做了需求采集，把用户需求转化为产品需求，知道了某个需求的基本属性、种类、商业价值、开发量，现在似乎应该开始写文档、干活了，但经验告诉我们不是这样的：
绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。
一个实际的例子：
我做过的某个产品页面的访客，在2009年某段时间内使用各种网页浏览器的比例如图2-15所示，第一名是微软的IE，99.14％（其中IE6.0又占75％）；第二名Firefox，0.45％……
图2-15 某产品页面的浏览器使用情况
对应的需求是：“产品页面在Firefox下显示有问题，比如……”，而我在注释里写道“对不起，我们就是不支持Firefox”。当然，这句话是写给自己人看的，千万别对用户讲。
这个需求实现难度不大，但一直在功能列表里放着没动，说实话，能在列表里出现的需求，严格意义上讲，没有任何一个是没有价值的，也没有任何一个是做不了的，那么到底先做哪个，后做哪个？
就像早在第2.1.1节中就谈到的“不要试图满足所有用户”，一切皆看性价比。
有了那么多的准备，现在我们只要做一道简单的小学算术题就可以回答上面的问题了。
性价比＝商业价值÷实现难度（简化为开发量）
现在可以做决定了，我们把产品需求列表按照“性价比”一列从大到小排序，先做排在上面的就可以了，如表2-8所示。
表2-8 需求的性价比
但是工作中对“性价比”的判断还是会经常有偏差，很实际的一个原因，是自己经常和哪类人接触。2007年下半年的工作中，由于一直和工程师直接接触，经常听到他们抱怨某个需求太麻烦之类的，所以综合考虑时有点倾向于做实现难度小的；而如果经常和销售、运营的同学一起开会，就会倾向于更多的考虑商业价值，这点与大家共勉，时刻注意。
道理说完了，对需求的DNA检测也暂告一个段落，接下来我们将迎来一场残酷的“战争”。
2.4 活下来的永远是少数
2008年春。
每个月来一次的，除了账单，还有那场“战争”。虽然活下来的永远是少数，但我越来越觉得，为了我们的产品，有些需求死得其所。
这是一场公司内部的战争，每个产品的产品经理都要上场，打仗总是为了抢点什么，我们争夺的是下个月的人力资源，即总是不够用的开发工程师、测试工程师等。战场就是闻之色变的产品会议，而我们手上的武器，则是精心准备的商业需求文档。
这个过程，就是需求筛选，如图2-16所示，也有个很传神的说法：需求PK。
图2-16 需求筛选
2.4.1 永远忘不掉的那场战争
为什么原来没有这样的战争？
我没找到理论支撑，但就个人经历和与同事的交流来说，下面是一个因素：更早的时候，公司是按照产品线划分部门的，对于某个产品来说，有自己的产品设计师、开发与测试等，下一段时间要做哪些需求，完全可以在产品经理的层面上决定，所以就算有战争也是部门内部的，比较温和，基本上在分析商业价值的需求讨论会上，也就顺带着确定了下一段时间做哪些。
为什么现在有战争了？
2008年初，公司组织结构调整，变成了按职能线划分团队，有了统一的产品中心，包括所有的产品经理和设计师；研发中心，包括所有的开发工程师、架构师等；质控中心，包括所有的测试工程师……这样的话，每个产品还是由原来的产品人员做，但是开发与测试资源在一定程度上就有了流动的可能。每个产品想做的需求都很多，所以都想尽可能多地抢到开发与测试的资源，然而人力资源总是严重不足的，所以最终把资源投给哪个产品，就必须上升到几个中心的大老板层面来决定了，而大老板的决策依据就是各个产品团队制作的商业需求文档。
其实，后来我们又经历过几次反复，部门总是一会儿按产品线划分、一会儿按职能线划分，这让我忍不住也对这个问题给出点自己的解释。
按产品线划分的团队对产品本身是有利的，产品经理权力更大，可以按照自己的想法做，资源有保证，产品规划不容易被动改变。此外，各种职能的员工之间沟通顺畅，单线领导，开发的领导、测试的领导等都对产品经理负责。
按职能线划分的团队对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高，由于产品规划的决策需要在更高层面上敲定，单个产品的发展速度会有所降低。此外，资源战争可以把“鲶鱼效应【28】”从产品内部扩大到公司层面，使产品经理和设计师们更抓狂地为产品的发展而苦苦思索，这是一件好事。
两种组织结构，给我“一攻一守”的感觉，产品在创业期的时候，需要全速发展，必然是产品线结构，产品经理带头往前冲。而当公司里有多个产品慢慢成熟之后，就多用职能线来更充分地利用资源，因为在成熟的产品团队中，要做的事情通常比创业时期少，或者说没那么急，那么各种资源就显得有富裕，可以更加稳扎稳打，所以按职能线划分以实现资源共享，同时还可以促进不同产品团队之间的互相学习，让员工的个人能力得到更多的提升。
更多有关组织结构的话题，将在第4.1.3节“团队之大”与大家讨论，到时候再见。
准备出发：把需求打个包
上战场之前，就像战士要把自己的物品打包一样，需求也要打包。我们现在来解决这个包有多大的问题，即某个将来的潜在项目里，到底应该包括多少需求的问题。这里不得不提前谈一点项目管理的内容了。
做项目，终极目标就是：多快好省【29】，即范围大、时间短、品质高、资源省。
但又要马儿跑又想马儿不吃草的事情是没有的，所以我们通常是在上述4个要求中做平衡。我经历的互联网、软件项目，比较推崇敏捷方法【30】，所以有比较固定的项目时间，专业点叫“迭代周期”，一般是2～4周。然后有一个人员相对固定的团队，意味着项目资源确定，此外任何时候都要保证项目品质，最后能变的只能是量——项目范围。
继续，我们有了项目时间长短，也就意味着可以按经验的比例估计出留给开发的时间有几天，然后团队里有多少开发工程师也是知道的，所以我们可以直接算出有多少“可用工作量”，同样以“人天”为单位。还记得我们把产品需求列表按照“性价比”从大到小排序过了么？从上往下看，每一行后面都还对应着一个“工作量”，现在我们只要做一个简单的加法，一行又一行地从上到下依次纳入项目，能做多少，一目了然，我们把这个动作叫“需求打包”，而对这些需求的整体描述，也就是商业需求文档里的功能说明了。
当然，这只是一个基准，可变因素很多。我们每次产品会议都要准备好几个项目让大老板们选，每个项目也有可能在产品会议上被砍掉部分需求，所以可以先相对随意地超出“可用工作量”。
这个过程完全定量地回答了“做多少”的问题。但，真实情况哪会这么简单明了，就像课本里总是给出一个简单到不真实的例子，然后再告诉你还有很多特例，而到了实际操作中，你会发现又要复杂很多，没办法，大家都尽力吧，让每个项目的大小相对靠谱，下面说几个需要注意的地方。
第一，“需求打包”最好打包类似的功能点。是否类似取决于需求的基本属性，这是“确定需求的基本属性”那一节里做的事情。一般来说业务上逻辑关系密切的需求才会包含在一个项目里，这也很好理解，否则就是一个纯粹修修补补的“小需求项目”了。实际操作中打包多大，更多的是取决于这一点。更好的方式是，需求在打包以后，通过业务逻辑图的方式可视化，可以更直观地给别人讲解。
如图2-17所示，是我在2009年春天做的一个项目的业务逻辑图，因为涉及一些商业问题，所以图中有些关键词隐去了。
图2-17 魔方计划的业务逻辑图
第二，需求依赖，功能互相之间有依赖关系。那些只能先做的功能，应该在产品需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做。在这里评估工作量的时候不会考虑“谁来做”的问题，在正式立项以后，组建团队的时候会重点考虑，当然长期来说，为了避免这类风险，提升与平衡团队成员的能力是王道。
第三，需求的粒度大小问题。商业价值很高的功能，如果细分的话，我们会发现其中也有价值相对低的部分，所以需求的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内，举个生活中的例子帮助大家理解：大开间办公区域里的灯，不可能用一个开关控制，也不可能每一个开关只控制一盏灯。具体细到多少，要根据具体情况具体分析。我们的经验是，在需求列表里出现的任意一行，工作量最好不要超过“5人天”。
战场：产品会议
需求打包完成了，战争就要打响了。
某天，各个部门的老板们都聚集到一个大会议室，准备待上一整天。各个产品的产品经理和设计师们等着被轮流召唤，当然如果你有空且愿意，也可以旁听一整天。其实对资源的争夺，在部门内讨论商业价值的时候已经预演过了，通常来说每个人都会尽力为自己提出的需求说好话，毕竟实现自己想法的感觉总是好过帮别人实现想法。
一般来说产品会议一个月一次，当然这和产品性质有关，如果你们公司的产品周期比较长，那也可以两三个月一次。
当某个产品团队开始登场亮相的时候，一般要先回顾上一次产品会议通过的项目，现在进展如何，是否需要调整时间进度、是否需要追加资源、是否有重大需求变更，已经发布的项目有什么问题等。这样一方面是为了让大老板们更新对各个项目的信息，更重要的是为了积累经验，让今后产品会议上的决策越来越合理。
回顾之后，就是最关键的部分了，我们会拿出准备好的商业需求文档，每个产品都会拿出三五个，占满2～3倍的潜在资源。这里说的潜在资源，是指相对固定的开发、测试人员，因为技术人员有对产品的熟悉问题，所以在短时间内，不可能太多的人同时转去做其他产品，这也就意味着潜在的人力资源数量是在一个值附近做微小浮动的，所以我们也可以认为，在一定程度上，资源的争夺是以产品间的争夺为辅，产品内多个项目的争夺为主。很有意思的是，这三五个商业需求文档通常是产品团队里不同的人做出来的，所以内部也会争夺得你死我活。
接下来的重头戏是一直提到的商业需求文档。
武器：商业需求文档
我们刚刚把需求打好包，接下来就要描述一下这个包了，这就是商业需求文档，Business Requirement Document，简称BRD，它也是我们参加资源争夺战的武器。
先看一下几个长得很像的词：BRD、MRD【31】、PRD【32】。按顺序来讲，这几个词是从商业的描述渐渐过渡到对技术的描述。我经历的团队在实际操作中通常只写两种文档，一个是给大老板们看的BRD，包含了BRD以及MRD的部分内容；另一个是在项目中写的PRD。
下面来聊聊我们的武器——BRD怎么写，都包含哪些内容。
项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。
商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。
非功能需求描述：提一下重要的非功能需求，如果有的话。
资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。
风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。
从BRD中的“商业价值”、“资源评估”两个重点中大家可能也发现了，其实本质上大老板们也是在追求那个词——性价比。大家都希望花费最少的资源获得最大的商业价值。
下面通过一个BRD的实例，再给大家讲一点直观的认识。
首页，我们会给BRD，也意味着将来的项目，起一个有意义的名字，再配上一幅图，这样有助于团队的归属感，比如下面这个BRD叫“魔方计划”，如图2-18所示，是因为这个项目打算将两个老产品整合为一个新产品，有点像魔方一样，通过打散、组合，得到一个全新的结果。
图2-18 魔方计划PPT的首页
商业价值如图2-19所示，给老板们看他们最关心的指标，比如魔方计划就聚焦在“活跃用户数”上。
图2-19 魔方计划的商业价值
功能需求描述，这里给出了业务逻辑图，如图2-20所示，若能给出一些简单的Demo更好，让老板们提前看到产品完成后的样子，很可能成为争取资源的加分因素。
图2-20 魔方计划的业务逻辑图
资源评估如图2-21所示，我们会根据团队的实际情况，重点评估主要功能对产品设计师、用户体验师、开发工程师的人力需求。
图2-21 魔方计划的资源评估
BRD转化为项目也并非一一对应，很可能老板会把多个BRD合并为一个项目，或者把一个BRD拆成多个项目，或者直接砍碎了再重新组合，这都无所谓，不管怎么说，产品会议开完以后，我们终于确定了接下来一段时间要做哪些需求了，准备启动项目，迎接新的开始。
等等，我们还需要先安抚一下“被砍得遍体鳞伤”的兄弟们。
2.4.2 别灰心，少做就是多做
有100个需求，资源只够做10个，是的，当时就是这样。
一直都是这样。
2007年国庆长假回来，我在全力做网店版“自动上架”的功能，简单解释一下：淘宝为了防止一些没人打理的商品始终在搜索结果中，稀释了有效信息，所以所有商品会隔一段时间后自动下架，不再被搜索到，这时就需要用户重新将商品上架。而网店版的用户都是淘宝的优质卖家，所以我们给他们提供了一个“自动上架”的功能。
这是一个确定“怎么做”的过程，当时的体会能很好地表达我的想法，借用一下。
两个礼拜，整天的PK、评审、确认，搞得头晕脑胀，不过终于算是把需求定下来了。
一个功能的多次需求会议中，必然有这样一个过程：开始对一个功能想得不完整，说着说着大家都想把这个功能做得再强一点，这里加一点那里加一点，但后来通常因为技术实现、资源等原因，又把这些加上去的功能点一个又一个地砍掉，甚至会发现砍到最后和一个月前的第一次方案是一样的。看似白搭的这个过程其实是有用的，这是一个“见山是山，见山不是山，见山还是山”的三段过程，对于那些加上又砍掉的功能点，在第一个阶段我们根本没有想到，第二个阶段想到了，很兴奋，那就做吧，而第三个阶段的砍掉是权衡了利弊之后的决定，和“没想到”是完全不同的。我们无法绕过第一阶段的无知，也千万别停在中间那个功能点“大而全”的时候，必死无疑！而第三阶段的“少做”则是超越第二阶段“多做”的“少做”，这才是真正的“多做”。
有很多文章谈到这样的思想，用100％的质量去实现75％的数量，而不是反过来！吸引用户的往往只是功能模块中的一两个点，我们一开始只要让其拥有100％的质量其实就够了，这样留给用户的是升级的期待，而如果反过来，功能铺得很开，但每个点都不爽，反而喧宾夺主，把闪光的地方给掩埋了。
情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。越来越觉得当发现一个功能可有可无的时候，甚至只要是没有强烈的理由要做的时候，要明确的选择：不做！现在我们可以自我安慰了——少做就是多做！
最爽就是“四两拨千斤”
做得少不如做得巧。
第2.3.1节中我们提到满足需求有三种方式，其实就算“改变现状”这样一种最常用的办法，也有很多“四两拨千斤”的方案。如果机会闪现，就千万不要放过，因为做这样的事情实在太爽了，让我对下面这个故事过目不忘。
话说某跨国日化公司，肥皂生产线上面存在包装时可能漏包肥皂的问题。
于是该公司总裁命令组成了以博士牵头的专家组对这个问题进行攻关。该研发团队使用了世界上最高精尖的技术（如红外探测、激光照射等），在花费了大量美金和半年的时间后终于完成了肥皂盒检测系统，探测到空的肥皂盒以后，机械手会将空盒推出去。这一办法将肥皂盒空填率有效降低至5％以内。
问题基本解决。
再说某乡镇肥皂企业也遇到类似问题，老板命令初中毕业的流水线工头想办法解决，经过半天的思考，该工头拿了一台电扇到生产线的末端对着传送带猛吹，那些没有装填肥皂的肥皂盒由于重量轻就都被风吹下去了。
这样做得更少，但是效果更好，至少性价比更高。当然，具体情况要具体分析，任何事情总有它的两面，上例中乡镇企业的解决方案换到跨国公司的环境中，也许并不适用，比如会造成肥皂盒无规律地四处翻滚，引起更大的问题，但我想表达的意思是：
我们用不着觉得只有“吃苦耐劳”，做了很多事情才是贡献，而应该直接从目的出发。有一句话说得好：内部（指偏技术）的大改动往往是外部（指偏商业）的小改动，反之亦然，所以我们应该在动手前先找找有没有成本低，收效大的解决方案！
尽可能多地放弃
第2.2.5节里，我说“尽可能多地采集”，这里，我又说“尽可能多地放弃”，看似矛盾，其实正反映了我们对事物的认识过程，只有在收集阶段没有遗漏，才可能完整地看到事物的全貌，有了大局观，在放弃的时候才知道孰重孰轻，也更下得了手。
多年以前我看到白鸦【33】写过的一段例子，发现如果不放弃，最终会被自己折腾死，他是这么说的：
比如，一个最简单的“评论”功能：既然可以发评论，那么……
是不是需要改评论？
删评论？
发的权限是否要管理员设置？
那么改的权限呢？
删的权限呢？
是否可以引用别人的评论？
评论被人引用了是否可以再改？
如果可以改那么是不是要保留修改记录？
如果管理员改了一个评论那么作者是不是不能再改？
评论是否要有数量和时间限制？
评论要不要翻页？
如果要翻页是在本页翻还是打开新页？
评论能不能带图片？
带了图片那么是不是能上传？
能上传之后是不是要删除？
是不是要提供自定义评论排序？
是不是要xx？
是不是xx？
xx？
……
“需求越来越多，让人崩溃，但是要做的事情太少，似乎也会有问题。”小明忍不住跳出来问。
小明：“有资源空出来了怎么办？”
大毛：“要做的数量是少了，但要达到100％的质量，一般很难空出资源。”
小明：“真的空出来了怎么办？”
大毛：“去找其他意义更大的功能。”
小明：“找不到怎么办？”
大毛：“把空闲下来的人拉去做另外一个意义重大的产品，这不可能再找不到了。”
“少做就是多做”，阿里巴巴的马云也说过。
2.5 心急吃不了热豆腐
没有产品是生下来就完美的，一天又一天，一月又一月，我们的产品反复地经历着需求采集、需求分析、需求筛选的过程，不断进化。我们不要想一口吃个胖子，很多案例表明，追求一步到位的产品经常像陷入沼泽的巨兽，挣扎着一步步走向死亡，用户甚至根本都不知道它曾经存在过。
在这个过程中，需求会越来越多，永远做不完，就像工作永远做不完一样。而我们要做的事情是，在资源限制下找到最有价值的需求，然后把它做好。那么，新的问题产生了，我们得找个办法把越来越多的需求管理起来。
一个需求的生老病死
这是一个真实事例：
网店版2.0发布上线后的两个月，从各个方面采集到的需求多达四五百个，经过PD们的初步判断，记下来供团队讨论的有200多个，决定暂缓的有60多个，7月一个月发布掉了70多个……
这其中每个需求的去留，去的怎么去，留的怎么留，一定是需要管理的。于是我们在产品需求列表上再加几个属性项，试着管理需求的生命周期。
我们之前谈到了不断举行产品会议，其目的也就是让产品持续发展，那么对于产品需求列表，也就有必须每隔一段时间、或是新需求积累到一定数量、或是由特别事件触发，拿出来大家一起讨论，这次讨论也就是更早谈到的“分析需求的商业价值”。但是，需求那么多，不可能每次都把所有的需求拿出来讨论，所以我们必须有所选择，这也就意味着需要标明需求的状态。需求的状态随时改变，但每个阶段都是谁来负责？所以我们还需要知道需求在各个阶段的负责人，以及其他一些需求跟踪的信息。
需求状态。通常有“待讨论”、“拒绝”、“暂缓”、“需求中”、“开发中”、“已完成”几个状态，可按照实际情况有所增减，比如管理的粒度细一点，还可以增加“测试中”。
负责PD。在需求状态变为“需求中”时指定，最可能是此需求的提交人，在需求的整个生命周期中，此人要从头到尾跟进，是这个需求的主人。
开发工程师。在需求状态变为“开发中”时指定，负责这个需求的技术实现，以及将来可能的故障解决。其他比如测试负责人，项目经理，大家可以按需要决定是否填写。
项目名称。辅助信息，在需求进入“开发中”时确定，用来筛选某个项目的需求。
发布时间。辅助信息，在需求状态变为“已发布”时填写，用来查看某段时间发布的需求。
备注。其他任何信息都可以写在这里，如：需求被拒绝的理由，需求被暂缓的理由和重启条件，其他相关文档，等等。
至此，我们终于得到一个需求完整的DNA，如表2-9所示，整个表中星号（*）标识的项目，是我心目中的必填项。
表2-9 一个需求的DNA
我们每次“需求讨论会”讨论的，自然是状态为“待讨论”的需求了——所有的需求由提交人录入列表，初始状态都标为“待讨论”。“商业价值”讨论确定的时候，它们的状态一定要变化，或是进入“需求中”，意味着要继续“初评工作量”，“计算性价比”，甚至进行“需求打包”并做成BRD了；或是被“拒绝”，拒绝的需求是被认为对产品的商业目标在相当长时间里没有价值的，不那么明显的最好在备注里注明拒绝理由；或是“暂缓”，暂缓的需求是“有价值，但是现在不做”的，通常要表明重启的条件，常见的有“3个月后再拿出来讨论”、“某相关产品实现某功能后再拿出来讨论”等。
而产品会议上通过的需求，状态会变成“开发中”，正式进入项目，项目发布，这个需求的状态又变成“已发布”。产品会议上没通过的需求，连同“需求中”但未被打包的需求，状态可以转移到“暂缓”，并备注说明情况。
现在，我们可以把“一个需求的DNA”从静态变成动态，画成“需求的生老病死”，让我们实时看到每个需求的“何时做，谁来做，状态如何”等信息，如图2-22所示。
图2-22 需求的生老病死
在第3章讲到项目的时候，我们会再配合项目生命周期，加上团队里其他角色，如开发和测试等，在一个更大的视图里来重新审视一个需求的生老病死。
在一个需求“死了”之后，我们也有了这个需求完整的DNA。
最后，也是我反复说的，工具和方法都是为了目的服务的，我给大家说了我们是怎么做的，但大家应该了解背后的原因，根据自己的实际情况，比如产品的大小、资源多少，做出最合适的表格。
需求管理的附加值
在实际工作中，我们发现需求管理还可以带来额外的价值。
这里要用到一些Excel的统计功能，对产品需求列表做一些简单的统计，就可以形成一份需求简报，形式如图2-23所示，举几个应用实例。
图2-23 需求简报
统计每个“提交人”的需求数量：可以看出产品团队里每个人提交了多少需求，如果再加上时间段的条件，就可以从一个侧面反映出某段时间每个人的工作情况，老板们一定喜欢看这样的内容。
统计“提交时间”、“发布时间”等信息：比如按月统计，可以从需求数量的侧面看出产品发展是在增速还是在减速。如果需求提交的数量明显减少，我们就需要考虑对策了。
统计每个“模块”的需求数量：因为需求都是直接或间接的从用户那里采集的，所以从各个模块的需求数量分布可以看出，用户对产品的哪些模块感兴趣，可以指导产品发展的方向。
统计每个“分类”的需求数量：从各种分类的变化，看出最近是在做新功能，还是更多地做老功能优化，从而了解产品是在成长期还是成熟期。
统计需求的“商业价值”、“性价比”变化：可以看出这个产品的发展空间还有多大，如果连续几个月，需求的“商业价值”、“性价比”都不高，就要考虑改变方向以求突破了。
除了可用Excel来管理需求之外，还有更专业的需求管理方法和工具，如Mantis系统、Mercury Interactive公司的Quality Center、IBM的Rational RequisitePro等，可以根据自己的产品与团队的情况选用。毕竟，把需求管理的工具视为产品，我们自己就是用户，所以这时候难得可以以自己为中心了。
和需求一起奋斗
本章说到这里，一个需求的奋斗史结束了，而我的奋斗才刚刚开始。让我们再一次看看下面这幅图，如图2-24所示，这是一个需求的奋斗史，也是我的第一年。
图2-24 “一个需求的奋斗史”详图
在这期间，我也经历了一次因为产品发布的感动，也是做产品以来最激动的一刻，只有做得很辛苦，才能修成产品经理最基本的素质之一——热爱产品。
所以，最后感性地回忆一下2007年6月28日，我作为主力PD的第一个付费产品发布的日子。临近发布的最后几周，因为各种原因，几乎是一个人扛下来的，非常辛苦，事后感觉真是很大的锻炼。当时在博客里写道：
从4月18日网店版1.0上线以来，到6月中旬：
用户数破20万，活跃用户破2万！
网店版2.0，经过70天来xdjm们的努力，一次一次的PK，几个小时前终于上线了～～～
一个月的预热～～～
几天前，几十万的消息发出去说今天19～22点上线～～～
今天傍晚还玩了个刺激的～～～
18点左右收到消息，网通的淘宝专用机房断电！淘宝数据库全挂，万年一遇！
19点多的时候淘宝还是只有主页面可以看到……首页顶端红红的告示……后台全挂……
20点20分左右，终于淘宝起来了～～～
20点58分左右我们发布成功～～～
21点出头，第一笔到款来啦～～～
22点47分，现在，又刷了一次账户：1770～～～
24小时不间断“数钱”终于实现，哈哈～～～
毕竟是第一次，作为产品主设计做出来的收费产品～～～鼓励一下鼓励一下～～～
继续努力～～～
其实到了23点左右，我坐在显示器前，不愿意走，鼻子泛酸，真的有点激动了。这可能是我做产品经理几年来最激动的时刻，是真心觉得“这个产品是我的【34】”。后来都没这样的感觉了，是因为记忆模糊而变得美好，还是真的美好？我不知道……
注释
【1】我觉得，做产品经理最大的快乐来源于实现自己的想法，而不是执行别人给的任务。
【2】顺便提一句，“从用户中来到用户中去”还有一层意思是说产品设计的过程是一个闭环，需求的源头是用户，而产品发布以后，在整个生命周期中，仍然要不断地“到用户中去”收集反馈，作为产品改进的依据。
【3】马斯洛需求层次理论（Maslow's hierarchy of needs），亦称“基本需求层次理论”，是行为科学的理论之一，由美国心理学家亚伯拉罕·马斯洛于1943年在《人类激励理论》论文中所提出。
【4】做产品就是在解决问题，从这个角度看这本书，第2章讲的就是如何发现问题，分析问题；第3章讲如何解决特定的问题；第4章讲如何发挥团队的力量来解决问题；第5章讲如何选择大方向，决定要解决哪些问题；第6章讲解决问题需要的自我修养。
【5】UCD是User-Centered Design的缩写，中译“以用户为中心的设计”。Ucdchina.com这个网站对我的帮助很大，让我认识到做产品是一件很有意思的事情，推荐给大家。
【6】KPI：Key Performance Indicator，关键业绩指标。
【7】IM：Instant messenger，即时通信软件。
【8】RSS：Really Simple Syndication，一种获取信息的方式。
【9】SNS，全称Social Networking Services，即社会性网络服务，专指旨在帮助人们建立社会性网络的互联网应用服务。
【10】《赢在用户：Web人物角色创建和应用实践指南》的英文原版叫The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web，译者范晓燕（Angela），也是UCDChina的创始人之一。
【11】近年来，老外在对用户研究方法分类的两个维度之上又研究出了一个新的维度——产品使用场景，有以下4种，其优劣势我还没能充分体会，有兴趣的同学可以自行研究：1．自然地或是接近自然地使用产品，如在用户真实环境下的现场调查；2．脚本化使用产品，按照预先安排的方式使用，如让用户完成任务的可用性测试；3．在研究中不使用产品，如在路边对路人做的调查问卷；4．以上各项的混合，也是各种研究方法的混合。
【12】这些原因都很有意思，想深入研究的同学可以去看社会心理学，里面有详细的相关论述。
【13】本书的作者是交互设计之父Alan Cooper，附录里有对本书的简单介绍。
【14】可用性测试（Usability Testing）是指在设计过程中被用来改善易用性的一系列方法，下文有详细描述。
【15】焦点小组（Focus Group）是由一个经过训练的主持人以一种无结构的自然的形式与一个小组的被调查者交谈，可以视为一种一对多的用户访谈形式。
【16】种子用户，是指某产品的一些忠诚度很高的用户，产品设计者与他们长期保持交流，让他们试用最新产品，可以经常从他们那里获得产品的建议和意见。
【17】开放式问题像问答题，不是一两个词就可以回答的；封闭式问题有点像判断题或选择题，回答只需要一两个词。
【18】更理论化的内容，大家又可以去翻《概率与数理统计》的课本了。
【19】灰度发布是互联网产品发布上线的一种常用形式，先让少量用户看到新产品，利用他们的反馈进行修正，逐步把新产品展现在所有用户眼前。
【20】UGC：User Generated Content，用户产生内容。UGC其实并不是新概念，传统行业的宜家（IKEA）早在50年前就有所行动，让终端用户参与到产品的设计的各个环节中。
【21】推荐阅读《黑天鹅》和《统计数字会撒谎》这类统计学的图书，不似教材那般枯燥，适合工作以后的人阅读，附录中会有简单介绍。
【22】因为是企业用户，所以本例中“用户”与“公司”是一个概念。
【23】这次的数据分析是我用一款工程软件——MATLAB做的。这完全是个巧合，正好上学的时候一直拿它做数据挖掘。常有这种体会，之前学过的东西，当时不知道有什么用，多年以后说不定什么地方就真的用上了，很惊喜。所以早年的学生时代，当你还没想清楚将来要做什么的时候，也就意味着不知道应该学什么，也不要就真的一直空想而什么都不学，不妨先学着别人安排你学的东西，等想清楚自己的目标以后，再优化自己的知识结构。
【24】有关需求分析的方法论，我后来又提出了一个更详细的“Y理论”，有兴趣的同学可以去这里查看：http://iamsujie.com/1000/1017/。
【25】头脑风暴（Brainstorming）的发明者是现代创造学的创始人，美国学者阿历克斯·奥斯本。他于1938年首次提出头脑风暴法。Brainstorming原指精神病患者头脑中短时间出现的思维紊乱现象，病人会产生大量的胡思乱想。奥斯本借用这个概念来比喻思维高度活跃，打破常规的思维方式而产生大量创造性设想的状况。
【26】信息架构（Information Architecture），简称IA。它的主要任务是为信息与用户认知之间搭建一座畅通的桥梁，是信息直观表达的载体。通俗点讲，信息架构就是研究信息的表达和传递。
【27】KANO模型以东京理工大学教授狩野纪昭（Noriaki Kano）的名字命名，是一种对顾客需求或者说对绩效指标的分类，通常在满意度评价工作前期作为辅助研究模型，KANO模型的目的是通过对顾客的不同需求进行区分处理，帮助企业找出提高企业顾客满意度的切入点。
【28】鲶鱼效应即采取一种手段或措施，刺激一些企业活跃起来投入到市场中积极参与竞争，从而激活市场中的同行业企业。其实质是一种负向激励，是激活员工队伍之奥秘。
【29】“多快好省”对比经典的项目TRQ：项目时间（Time）、项目资源（Resource）、项目质量（品质Quality和数量Quantity），大同小异。
【30】敏捷方法，一种项目管理方法，在本书第3.5.3节“敏捷更是手段”里有相关描述。
【31】MRD：Market Requirement Document，市场需求文档。
【32】PRD：Product Requirements Document，产品需求文档，在本书第3.3.1节的“产品需求文档，PRD”里有详细讲述。
【33】白鸦，支付宝产品设计师，UCDChina发起人，5G咨询合伙人，专注于以用户为中心的互联网产品设计的Blogger。个人博客uicom.net。
【34】给新人们一句话，也是我到目前为止仍然信奉的：在高层决定公司战略的前提下，好的产品对我们的帮助会远远大于我们对产品的帮助。所以，产品经理的前若干年，好的公司、好的产品、好的老板，很重要。
