《产品经理策划培训教材》由会员分享，可在线阅读，更多相关《产品经理策划培训教材（88页珍藏版）》请在金锄头文库上搜索。
1、产品经理（策划）培训产品经理（策划）培训-产品部产品部第一部分：概论为什么要做产品经理？我们到底是不是产品经理？我真的想做产品经理，如何入行？为什么要做产品经理？好产品能改变世界-产品经理的信仰我们到底是不是产品经理？我们从事的是IT行业，具体点说，是互联网和软件行业。很多人可能都会和我一样，入行久了，看了一些资料，发现里面说的产品经理和我们平时做的事情似乎不大一样，于是做得越久越迷茫，总在问自己我们到底是不是产品经理？有这样的疑问很正常，因为有“产品经理”这个词的时候，还没有我们现在熟悉的“互联网”和“软件”的概念呢。从互联网、软件行业巨头的“产品经理”招聘广告中，就可以发现这个职位的内涵和
2、以往的产品经理已经有着很大的不同。那么，互联网、软件行业的产品经理在概念上究竟有了哪些变化，有了哪些发展？为什么会有些变化和发展？这会导致产品经理的职责、技能要求有哪些不同？需要说明的是，我会经常把互联网和软件业的产品经理放在一起讲，这是因为两者同属IT行业，而且现在的互联网产品越来越复杂，越来越像软件，而软件产品也来越多地基于网页浏览器，从产品经理的职责、技能角度来看，两个分支领域日益融合，越来越趋同。移动互联网更是传统互联网和软件业的合成体。引言产品究竟是什么？百度百科里这么解释：产品是一组将输入转化为输出的相互关联或相互作用的活动”的结果，即“过程”的结果。在经济领域中，通常也可理解为组
3、织制造的任何制品或制品的组合。产品的狭义概念：被生产出的物品；产品的广义概念：可以满足人们需求的载体。我的理解则更直白一点：产品就是用来解决某个问题的东西。键盘、显示器、文字处理软件、输入法杯子、果汁导购员的参考意见，其服务也是产品产品究竟是什么？产品这个东西，可以是有形的实物，也可以是无形的服务，多种多样。而解决问题其实就意味着满足人们的需求，这样才能产生价值。这个价值不仅要给产品的使用者，也要给产品的创造者。我们谈到的主要是一类产品商品，并不是所有的产品都要变成商品，公益性、非盈利的产品也随处可见。但我们工作中所做的产品，绝大多数都是在人们的需求，即用户目标和公司的商业目标之间寻找平衡。只
4、考虑用户，公司无法盈利，必然死掉；只考虑商业，光想着公司得好处，用户留不住，公司也会死掉。所以在这里我们说产品是什么，产品就是要同时解决用户的问题和公司的问题，一个都不能少！产品经理横空出世在商品出现了很多年之后，产品经理的概念才第一次在美国的宝洁公司出现。此前，产品经理要做的事情显然也是有人做的，为什么这么晚才有人蹦出来说：“要有专人对这个东西负责”？我们还是先讲故事。全世界的第一位产品经理20世纪二三十年代，宝洁第一次提出了产品经理的概念。当时宝洁推出了一种佳美牌（Camay）香皂，但销售业绩较差。一名叫麦古利的年轻人在一次会议上提出：如果公司的销售经理把精力同时集中于Camay香皂和Iv
5、ory（宝洁的一种老牌香皂），那么Camay的潜力就永远得不到充分发掘。幸运的麦古利赢得了宝洁高层的支持，之后，每一个宝洁品牌都当做一个独立的事业在经营，有专门的产品人员、销售人员给予支持，与其他品牌同时竞争。而麦古利就成了全世界的第一位产品经理，负责Camay香皂的品牌建设、市场销售等几乎所有的事情，他的成功表现使宝洁认识到产品管理的巨大作用，之后，宝洁便以“产品管理体系”重组公司体系。这种管理形式为宝洁赢得了巨大的成功，也导致后来大部分消费性商品业者纷纷沿用和抄袭。由此可见，产品经理的出现是为了适应公司发展的需要。随着企业越来越大，产品越来越多，越来越复杂，原来按职能划分部门的组织结构已经
6、无法适应，所以出现了产品管理的矩阵型组织，而此时产品经理的主要职责是规划产品的生命周期，负责产品的上市策略、定价策略、整合营销策略、销售与分销策略等等。随着产品管理体系的运行，我们发现它还有很多好处，比如鼓励了创新、更重视用户等，这些话题以后再和大家仔细交流。他们真是招产品经理么说到这里，也许在互联网、软件公司中做产品经理的朋友要跳起来了：好像之前产品经理要做的那些事情已经另有分工，由运营部门、市场部门的同事负责啊？！为了进一步验证互联网、软件行业的产品经理确实和传统行业的产品经理不同，我们先来看看几则招聘信息。阿里巴巴产品经理招聘信息：工作职责：负责公司产品规划；根据公司战略，负责产品发展的
7、长期规划，保证业务指标；深入了解方面的业务，挖掘用户的多种需求，不断推出有竞争力的产品；根据产品实施效果及业务发展状况，不断改进产品；组织资源实施产品，对其效益负责。职位要求：熟悉互联网或软件产品整体实现过程，包括从需求分析到产品发布；对工作充满热情，富有创新精神，能承受较大的工作压力；3年以上软件开发或项目管理相关经验者优先；有网站产品运营和发展相关经验者优先。他们真是招产品经理么百度产品经理招聘信息：工作职责：对市场发展趋势有敏锐的洞察力和创新意识及良好的分析、研判能力，能够深刻把握用户需求；制定所负责产品线的发展蓝图和实施路线图；完成需求分析，发起产品研发项目，善于利用设计工具完成产品U
8、C3设计和Demo制作；负责或配合其他部门制定产品运营计划，持续改善产品。职位要求：本科以上学历；熟悉业务者优先；对项目管理的完整流程和环节有比较准确的认识，有实际经验者优先；优秀的理解分析能力、沟通合作能力；执行力强，善于组织协调并推动项目进展；较强的自我情绪调节能力和自我激励能力；具备严谨的工作态度、强烈的责任心和团队精神。他们真是招产品经理么百度产品经理招聘信息：工作职责：对市场发展趋势有敏锐的洞察力和创新意识及良好的分析、研判能力，能够深刻把握用户需求；制定所负责产品线的发展蓝图和实施路线图；完成需求分析，发起产品研发项目，善于利用设计工具完成产品UC3设计和Demo制作；负责或配合其
9、他部门制定产品运营计划，持续改善产品。职位要求：本科以上学历；熟悉业务者优先；对项目管理的完整流程和环节有比较准确的认识，有实际经验者优先；优秀的理解分析能力、沟通合作能力；执行力强，善于组织协调并推动项目进展；较强的自我情绪调节能力和自我激励能力；具备严谨的工作态度、强烈的责任心和团队精神。他们真是招产品经理么腾讯产品经理招聘信息：工作职责：负责某产品的策划、运营、管理；负责用户研究，把握用户需求，实现用户需求；负责公司产品推广、运营等情况跟踪，收集用户信息并根据市场情况提出产品开发和改进方面的建议，提出运营思路。职位要求：本科以上学历，5年以上互联网产品设计经验；熟悉互联网领域产品开发，管
10、理和运营流程；能通过数据分析等系统性方法深刻理解用户需求并予以满足；良好的沟通能力和团队合作精神，出色的组织能力；有良好的学习能力和人格魅力、能承受压力。以上三家公司的业务基本代表了当今国内互联网、软件行业的方向，我们发现，其对产品经理的招聘要求大同小异，“产品经理”这个概念，确实已经和旧有的产品经理概念不一样了。它更多地侧重产品本身“从无到有”、“从有到优”的过程，更多地涉及了“产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法”等内容，而不是如传统的产品经理那样，去做已经有了产品之后需要做的诸如管理产品、推广和营销产品的事情。互联网、软件的产品经理与传统意义下的产品经理的
11、差异是我们把产品经理的概念理解错了，还是产品经理的概念变了？事实表明，在互联网、软件行业，业内称为“产品经理”的，90%都不是传统的那个概念了。没必要纠缠于名词的解释，作为奉行实用主义的职场人士，我们不妨接受事实，就继续使用“产品经理”这个词吧！所以，我们有必要来讨论一下互联网、软件的产品经理与传统意义下的产品经理为什么会有哪些差异？而这些差异又让从业者需要担负哪些不同的职责，提出了哪些不同的技能要求？下面抛砖引玉谈5点看法，如表所示，值得一提的是，我说的对比都是就整体情况而言，相信会有特例。典型的传统行业互联网、软件行业行业形态成熟行业新兴行业产品形态与成本结构实物虚拟物品生命周期几年几个月
12、盈利模式单一卖产品赚钱多元盈利用户心态花钱买免费用互联网、软件的产品经理与传统意义下的产品经理的差异第一，行业形态不同：成熟行业VS.新兴行业。传统行业经过几十年乃至上百年的摸爬滚打，市场已经成熟，产品基本定型，通常只有渐变式的创新，很难有重大突破。另一方面，用户也已经成熟，对产品相当熟悉，也已经形成比较固定的使用习惯，较难改变。所以对于这样的市场和用户，公司会偏重营销类创新。而互联网、软件行业是新兴行业，新兴市场，三天一小变、五天一大变，产品本身在不断取得突破，用户看什么都是新的，所以产品需要推陈出新，尽力先入为主，占领用户，主导用户习惯，这就导致了产品工作的重头戏在前期，从无到有，从有到优
13、，偏重研发类创新。因此，互联网、软件行业的产品经理更重视产品功能本身的规划，需要“对市场发展趋势有敏锐的洞察力和创新意识及良好的分析、研判能力”，要能不断改进产品，要“深入了解业务，挖掘用户的多种需求，不断推出有竞争力的产品”，“制定所负责产品线的发展蓝图和实施路线图”。互联网、软件的产品经理与传统意义下的产品经理的差异第二，产品形态与成本结构不同：实物VS.虚拟物品传统行业的产品多为实物，所以有采购、仓储、物流等分工，产品研发出来以后，还有大量的制造成本，这也使得传统行业的产品经理有相当多的工作是需要考虑如何把整个供应链打通，怎样销售、分销、促销，等等。而互联网、软件产品多为虚拟物品，公司相
14、对而言显得较“轻”，不管是团队，还是成本花费，都更加集中在产品研发的过程中。一个常见的互联网产品，很可能只是由几个人或十几个人、几十个人的团队所做，而用户却是上百万、上千万，甚至亿万量级，这在传统行业不可想象。虚拟物品的复制成本极低，所以重点资源会投入在产品本身，较少考虑实体经济里供应链上下游的事情。于是，对产品经理来说，需求分析、设计的细节尤为重要，必须亲自把握，可能一个细节的改进就能增加上万的用户，杠杆效应也十分明显因此，在招聘的广告词里自然就有“善利用设计工具完成产品UC设计和Demo制作”这样的要求。互联网、软件的产品经理与传统意义下的产品经理的差异第三，生命周期不同：几年VS.几个月
15、。传统行业产品典型的研发生命周期一般是几年，甚至更长，所以需要比较复杂精细的流程来支撑，比如我了解到在汽车行业，做一款新车的整个过程中，有不下300个评审点，这样复杂的过程显然必须由经过专门训练的专人负责。而互联网、软件产品典型的研发生命周期就只有几个月，所以研发管理过程会更精简，一个典型的产品研发过程，一般只有10个不到的评审点。于是，我们推崇敏捷方法，传统行业的精雕细琢不适用了，我们要快，这也是为了顺应新兴市场的需要，而且船小好掉头，有问题也能够快速地改，再发布一次升级就行，不像传统行业改起来那么麻烦，问题产品只能“召回”所以，虽然互联网、软件的项目更加不可控，但项目过程本身看起来并没有传
16、统行业那么复杂，更接近“艺术”而不是“技术”，要依靠丰富的经验，于是产品经理也经常兼顾项目管理，这样自己可以在项目完成度和产品质量之间做平衡，对产品无疑也是一件好事。所以我们在招聘广告中看到公司要求产品经理“发起产品研发项目”，“组织资源实施产品，对其效益负责”。互联网、软件的产品经理与传统意义下的产品经理的差异第四，盈利模式不同，单一卖产品赚钱VS.多元盈利。传统行业的盈利模式多为通过卖产品赚钱，或是直销，或是通过渠道分销，总之是靠产品本身的价值来赚取利润，而互联网、软件产品有很多产品本身是免费的，一部分产品甚至几年内都不考虑赚钱的问题，可想而知，对做这种产品的产品经理，要求肯定不同。而另外
17、一些能赚钱的产品，也有着更多元的盈利模式，比如免费给用户使用，但利用用户的注意力赚取第三方的广告费等。盈利模式的差异造成了产品为谁做的差异，传统行业多是为付钱的客户做，值得注意的是，很多情况下客户只是买产品的人并不是用产品的人，也许搞定几个大客户，就3年不愁吃穿。而互联网、软件产品大多是为使用产品的终端用户所做，而且通常是面对海量的用户，用户数多了，自然就能盈利。所以，互联网、软件行业的产品经理会更重视用户研究、数据分析等工作，要“负责用户研究，把握用户需求，实现用户需求”，而盈利的事情反倒不用直接去管，会有另外的团队负责。互联网、软件的产品经理与传统意义下的产品经理的差异第五，用户心态不同：
18、花钱买VS.免费用。传统行业产品的用户知道，东西是买来的，花了钱的，所以有点不爽的地方也就凑合着用，不至于把产品扔了立刻去再买个新的。而互联网、软件产品就不同，大多数都是免费的，每类产品雷同的还很多，所以只要这个产品用得稍稍有点不爽，用户马上就能很方便地找到另外一个试试。于是，互联网、软件产品更重视用户体验，相应的，出现了很多产品经理会涉及的工作内容，如交互设计、视觉设计、文案设计等。举个例子，有时候为了确定两个按钮是上下分布好，还是左右分布好，我们有可能做大量的用户实验。在互联网、软件行业中，产品经理能真正体会到“用户是上帝”的感觉，辛辛苦苦做一个产品，给用户免费用，还要尽量让用户免费用得比
19、付费的都爽。小结一下，以上五点相互之间也是紧密联系、相辅相成的，共同造就了传统行业与互联网、软件行业的产品经理的差异。比如为了给用户极致的体验，我们需要做很多数据分析，而数据分析的基础在于互联网、软件产品的虚拟特性，可以大量地记录用户的各种行为数据，这是传统行业很难做到的。又如正因为是新兴市场，所以产品不成熟、用户不成熟，于是产品的生命周期缩短，需求变化快，项目中不可控的因素增多，使得敏捷方法备受推崇。非典型产品经理讲了半天，可以看到，尽管都叫产品经理，但我们这里所说的互联网、软件业的产品经理，他们所做的事情和以往传统行业的产品经理相比，已经发生了很大变化。不过，你可能还有一个疑惑和一丝忐忑平
20、时我只做上述谈及的一部分工作，这样也能叫产品经理么？我的回答是：能。这是因为，不单是传统意义下的产品经理，就算是新概念下的产品经理的职责，也通常分给几个人或几个部门做。很少出现全能型产品经理，就算全能，也会因为个人精力所限，在某个时间段只会专注某方面的工作，或者只能是对每个方面都蜻蜓点水，而倘若如此，那么这样的产品经理多半只能是事业部的总经理，或者公司的CEO。于是，我们很多人都成了新概念下的非典型产品经理。这一点在传统产品经理的框架下已有线索：哥乔斯早在其著作产品经理的第一本书的最后一章“产品管理终将走到尽头？”里谈到各界对产品经理、产品管理制度的质疑，提出产品经理制度仍需要不断修正，并指明
21、了三大变化方向：产品管理团队、事业单位经理的任用、更专业取向。其中，产品管理团队顾名思义是用团队的力量来代替单一的产品经理；而任用事业单位经理的制度则是从项目管理团队的概念发展出来的，把产品强调为一个事业单位，也就是我们经常说的事业部，而产品经理也就摇身一变成为了事业部的总经理，区别在于总经理有了更大的权力；更专业取向则可以用下面这段摘录的文字说明，这也比较像我个人的一段经历：非典型产品经理由于企业分派给产品经理的责任愈来愈多，有的公司开始质疑对产品经理一个人来说，这样的负担是不是已经难以负荷。结果造成现在出现缩减产品经理的责任，让他更为专业化的趋势。至于要求产品经理专注的方向，则因公司或行业
22、类别而不同有时高科技企业会采取类似的做法，让产品经理专心处理产品在工程和技术方面的问题，而把大部分营销决定交给另外的职能单位来负责。在这种情况下，产品经理可能会变成产品技术/应用方面的专家，他最主要的工作就是支援、协助销售人员至于了解市场和从市场了解产品利益等工作，则另有他人代劳。像这样把营销功能和产品开发活动分开来处理的做法也有风险：产品经理将失去和顾客间的联系，而且会因为对产品太过熟悉，以致丧失判断上的客观性。不管企业想用怎样的专业取向，以便产品经理更容易地管理他的工作，很重要的一点是，请记住这个职位当初是为何而设想要更了解产品与它面临的竞争情况，最终目的是要满足顾客的需求。不管整天只是写
23、文档、做Demo，还是成了没钱没权的项目经理；或是求完销售求工程师，最后只能欺负客服，到处不招人待见前辈们似乎也认可人人都是产品经理，非典型成了多数，也就变成典型。产品经理的管理能力既然产品经理这个职位中有个“经理”二字，似乎多少就有点管理的味道。而按管理大师德鲁克的说法（我很认同）：管理并不是公司的管理层，如总裁、总监、经理们才需要掌握的技能，而是每个人必备的生存技能，只是每个人可以掌控的资源不同，所以需要管理的对象也不同。当资源充分的时候，我们会觉得“正确地做事很重要”，事实也确实如此，比如被分派了某个重要任务时，我们的目标就是做好这件事。而一旦资源出现了瓶颈，“做正确的事”就立刻变得更重
24、要了。比如同时有3个人要请你吃明天的晚饭（当然这种好事非常难得），这时候的资源，即你的时间不够了，你就需要迅速判断和谁吃饭更有价值，谁的请客可以推到后天或下周OK，你会管理自己的时间么？产品经理的管理能力管理的能力，其实就是“在资源不足的情况下把事情做成”的能力，这里的资源在产品经理的工作中通常表现为以下几种形式：第一，信息不足以决策。时间有限，能力有限，每次决策前不可能掌握所有信息，做决定时总是很头疼，我估计是“拍脑袋”拍得太多的原因。第二，时间不足以安排周密的计划。总是接到3个月、1个月，甚至1个礼拜完成某项目的命令，每次都让我们张大嘴巴说不出话来，应承下来后如何计划？不过一次又一次的实践
25、表明，办法总比困难多。第三，人员不足以支持工作强度和难度。不但时间不足，人员也不足，就算数量足，能力够不够？能力够了，团队士气高不高？哪个公司不加班，又有多少公司有加班工资？但还得完成任务，难不难？难！第四，资金不足以自由调配。俗话说钱要花在刀刃上，买机器要钱，招人要钱，产品推广要钱，而花这些钱的前提是公司还得赚钱，每一分钱都恨不得掰成两半用。以上四点还可以推广到生活中的各方各面，凡是资源，总归不足这是常态！既然不足，就需要学会分配资源、管理资源。比如说自己的时间、衣橱、工资其实，你已经每天都在做了，不是么？所以你已经是产品经理。我真的想做产品经理，如何如行？引言1501年8月，米开朗基罗应约
26、将一块35年前被毁坏的巨大的大理石雕刻成一尊塑像。通过研究这块大理石的原料，考察它的裂缝和纹脉，米开朗基罗感觉到雕像就在这块巨石中沉睡着。面对一块没有生命的石头，他的目光能看见被囚禁在其中的躯体和灵魂。他认为自己所要做的，就是把石头中的人解放出来，给他生命。只有米开朗基罗知道那个人在哪里。雕塑不允许反复修改，他必须一下子找到他，让他呼吸。他一层又一层、一锤又一锤，经过数年与世隔绝的苦干，终于把一个英雄美少年从沉睡的石头中唤醒。这就是举世闻名的大理石雕像大卫的诞生过程。其实，你的灵魂深处也有一个“大卫”，而你就是自己的米开朗基罗。如果把每个人的一生看做一个产品，那么你已经设计了将近20年，一锤又
27、一锤，在召唤着你灵魂深处的那个“大卫”产品经理，没错，他是原先就存在的，并不是谁刻意雕琢出来的，我想和你一起唤醒他。是像平凡的雕塑者一样去努力成为一个产品经理？还是像大师一样解放灵魂里业已存在的“大卫”？任由你选，我希望听到的是你内心的呐喊我真的想做，怎么入行？引言经常被问到这样的问题：“我快毕业了，对产品经理这个职位特别感兴趣，怎么入门？”“产品经理都是招有几年工作经验的，我原来做技术，要转行怎么做？”经常看到这样的帖子：“研发转产品，真的很痛苦！”“我是软件产品项目经理，如何成功转型做产品经理？”既然想做产品经理，我们就学着用产品经理的思路来解决“怎么入行”的问题，分几步走吧。首先来看看招
28、产品经理的公司到底需要什么样的人。然后，再问问自己真的是，或者想成为这样的人么？接下来，在出手之前必须找准自己的位置。最后，我试着给出几个可能的切入点。产品经理的招聘广告回顾一下前面列过的阿里巴巴、百度、腾讯这3家公司的招聘广告，和所有的招聘广告一样，它们分成两部分，工作职责+职位要求。“工作职责”是说产品经理要“做什么”，“职位要求”是说需要“什么人”。上一节我们分析了前者，这一节我们来看看后者，揭示这些招聘广告背后的东西。表中的每一条，分为“官方说法”、背后的“私下交流”及“事实真相”。官方说法需要全面负责产品的整体实现过程。私下交流因为产品经理这个职位比较新，所以具体要做哪些事情没有开发
29、人员、测试人员明确，于是，干多干少全凭自己决定。事实真相具体的职责不清楚，就意味着事情多起来没个谱，任何与产品有关的事情都可以是你的，总是闲不下来。官方说法需要能承受压力、自我调节、自我激励，综合素质要求高。私下交流产品经理做的很多事情都是更看重质量而不是数量，所以很难用工作量和工作时间来衡量绩效，经常好几天没什么产出也很正常。这时候你可千万别崩溃了。事实真相可是，产品的任何方面、团队里其他人做的任何事情如果出了问题，产品经理都很可能要背黑锅。产品经理的招聘广告官方说法对市场发展趋势有敏锐的洞察力，辅助决策公司战略方向私下交流你真的可以决定公司产品长什么样。事实真相产品当然是老板生的，你也就是
30、给它化个妆。官方说法需要很强的沟通能力，出色的团队合作精神。私下交流有很多机会展示你的想法，如果有兴趣的话，可以利用工作机会认识公司里几乎每一个人。事实真相你总是某个产品的信息交换中心，也是各方共同挤压的对象，哪边都不得罪真是一门艺术。官方说法关注业界动态，对互联网产品兴趣浓厚。私下交流因为你要了解行业的最新资讯，做竞争对手分析，所以需要不断去各种网站注册、试用，老板无法判断你是否在冲浪或瞎逛，全凭自觉。事实真相这样时间久了是很痛苦的，整天被那么多垃圾产品恶心，自己做的产品看太多了更觉得恶心做产品经理的关键怎么样，产品经理不好做吧？不过我还是很希望大家都能一起往“火坑”里跳。且慢，等一等，跳之
31、前，我还是再问你一句真的想？你确定？确定自己真的想做产品。这一点非常关键！下面都以互联网、软件产品举例，因为我是干这一行的，对此比较熟悉。做产品的大前提是要喜欢做产品，不然将来你痛苦，团队痛苦，用户也痛苦。网络上那么多好玩的应用，是很有意思，通常自己想做产品的同学都会去大量尝试、注册各种各样的产品，去用，去玩，去想如果你没有这个特点，那就真要好好想想了。你尤其需要进一步明确的是：你说自己喜欢产品，到底是喜欢做用户，还是喜欢做产品经理？如何判断这一点呢？可以这么做：当你对一个产品感兴趣的时候，回想一下脑中萦绕的问题是站在用户的角度，还是站在产品经理的角度。通常，用户会去想怎么用这个产品，才能带给
32、自己更大的好处，产生更大的效用；而产品经理则习惯于绕过表象，从背后看问题的本质，思考怎么设计这个产品才能更好地平衡用户目标与商业目标。做产品经理的关键举例：抢车位的游戏SNS里的抢车位游戏，很多人喜欢。从用户角度出发，考虑的问题就是：我应该怎样玩才能赚更多的钱？怎样最快地买到想要的车？怎么玩最爽而从产品经理角度出发，思考的问题则是：为什么每个人是4个车位？如果车位多了会怎么样？不同档次的车为什么停车费是一样的？如果高档车停车费高了，会有什么优缺点？的确也有人针对产品经理提出的这些问题做过分析，都是和产品的商业目标有关的。举例说，车位多了，停车费高了，对好友数量的需求就会降低，这意味着站内用户互
33、动的减少，与商业目标矛盾；而反过来，如果简单粗暴地试图增加互动，用户又会不高兴，也不行。总之，没那么简单。如果看到这里，你发现自己更多地是站在产品经理的角度想问题，一想到这些问题就热血沸腾，欲罢不能，如果能看到很多让你莞尔的句子，那么我得恭喜自己又多了一位同道年轻的产品经理，整个行业都需要你！找到自己的位置想入行，就要首先明确自己现在的位置。得充分利用已有的知识结构、资源，找到一条最近的入行之路。应届毕业生先说说应届生，应聘机会不可谓少，因为很多公司在校园招聘的时候言明要招聘产品经理，但刚毕业的同学其实只能先跟着前辈学，因为学校里根本没有很对口的专业，也许把类似的职位叫做“产品助理”更准确，我
34、自己就是应届生直接入行的，不过开始的职位是“需求分析师”，比产品经理更偏技术一些，技术相对而言好学一点，可以速成，但是商业感觉没个三五年是磨不出来的。但现在我发现确实有不少（而且越来越多）同学由于求学阶段就在实习或跟着老师做过实践性很强的项目，所以在学校里对这一行就已经相当有感觉了，加之半年到一年的实习，有的刚毕业就能独当一面。应聘这类职位主要看面试，要是我来做面试官，最在乎的是应聘者有没有激情，是否够机灵、好学，逻辑思维是否清晰，沟通表达是否顺畅等。其他的都会次要一些，比如对行业的熟悉，既然是招应届生，这块不会很看重，关键是看潜力而不是看能力，有类似职位的实习经历，只是一个加分项。我可能会问
35、应聘者这样一些问题，比如“谈谈我们生活中经常用的一个产品，它解决了什么问题，要是你来改进，打算怎么做？”；“看电视/书/电影么？举个例子分析一下它的目标用户。”“说说你是怎么准备这次面试的。”产品经理其实算一个非技术的职位，相应的面试经验到处都是，就不赘述了。找到自己的位置有工作经验转行再谈谈工作了几年，来应聘产品经理的人，几乎都可以算是转行了。做产品的人有个特点，那就是从做啥的转过来的都有，我身边就很乱：原先是技术人员的，比如开发工程师、测试工程师、架构师；原先是非技术类的业务人员的，比如市场人员、产品运营师。这些信息至少会给你信心，不管以前是做什么的，都可以转行做产品经理。我想这也是和产品
36、经理需要照顾产品的各个方面有关，所以在构建一个产品团队时，我们也希望招入各种背景的产品人员，这样能让团队在考虑问题的时候思维更加全面。确定自己想干这一行，也知道自己的位置以后，就剩下怎么向目标前进最省力的问题了。也许你要失望，因为真的没有捷径，真的没有银弹！对于想转行的人，我的建议是先在本职工作上找到与产品有关的事情做一些尝试，并且考虑先从产品经理周边的职位做起。好在产品经理的职责范围什么都涉及，这种事情总是能找到的。比如你是做开发的，那就经常要参与需求评审，不妨比别人多用点功，每次都预先了解需求，多多思考，然后在评审会上对需求提出自己的合理建议，时间长了大家都会觉得你很有想法，做产品也许不错
37、。关于职位，可以从“需求分析师”切入，这有些像系统分析的工作，比如业务逻辑、流程图，都是你已经很熟悉的，你可以在这个过程中慢慢培养商业的感觉，重点体会某个产品功能是为了满足商业上的什么需求而做的。找到自己的位置又如做网站运营的人，有时候会要专门做一些活动的页面，通常是把需求提给用户体验部门的同事，这样的事情其实就是在做一个小产品了，你可以改变原来用Word随便写几句要求，甚至口述沟通的方式，而是把这个活动当作一个产品来做，自己练习写一下BRD（BussinessRequirementDocument）、PRD（ProductRequirementDocument），虽然这些文档对于一个小活动作
38、用不大，但这个过程可以帮助自己在以后碰到更复杂的产品的时候，心里会有点底。所以原来职责偏商业的同学，可以先做“运营专员”，对已有的产品做一些推广策划类的工作，增强自己对产品的理解，做一段时间后，相信就能提出自己对产品改进的想法了。而项目经理也比较好切入，我工作过的团队就有很多同事是从项目经理直接转过来做产品经理的，因为多数的产品经理也要带项目，所以找个项目经理来也算先得个便宜，不过以后的课程里“产品经理和项目经理”说到的，这种转行有其特定的优势和劣势。做过上面的这些事情后，至少转行面试的时候可以多点谈资。第二部分：需求分析需求采集听用户的，但不一定照着做活下来的永远是少数心急吃不了热豆腐本课的
39、讨论还仅仅局限于有一堆需求的时候应该“做哪些”、“做多少”的问题，并没有谈及需求“怎么做”。我会在下节课里和大家仔细聊聊项目里的“需求阶段”要做的事情，我将其称为“需求开发”，如产品需求文档、用例文档应该怎么写。对于产品经理来说更重要的是“发现一个问题，然后设法将其转化为一个任务来解决”。需求采集引言实际工作中，到底采用哪种用户研究方法，往往取决于资源，比如人员数量与能力、老板给你多少时间、经费。如果资源非常少，我们甚至可能简化出很不正规方法，比如只是查一些二手资料然后和同事们一起讨论、猜测一下用户是怎么想、怎么做的，而有了资源以后，我们可能会叫几个用户过来访谈，请咨询公司协助出报告，或者出差
40、做用户调研等。每个人所处的团队条件不一样，也只能在实践中慢慢总结出适合自己的方法。但这些用户研究，或者说需求采集的过程，都会有如下几步：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。定性研究：用户访谈用户访谈通常采用访谈者与被访者一对一聊天的形式，一批次用户访谈的样本比较少，一般是几个到几十个，但在每个用户身上花的时间比较多，通常为几十分钟到几个小时，围绕着几个特定的话题，我们问，用户答，用户说，我们听，这是一种典型的定性研究。用户访谈可以了解用户怎么说，即他们的目标和观点。根据我自己的经验，用户访谈经常用在新产品方向的预研工作中，或者通过数据分析发现
41、现象以后，去探索现象背后的原因。定性研究：用户访谈用户访谈的常见问题与对策第一，“说”和“做”不一致的问题。用户经常会骗我们，先看一个经典的索尼游戏机的故事。索尼找了一些用户来，问他们喜欢黄色的还是黑色的游戏机，结果发现说喜欢黄色的用户比较多。之后，索尼告知用户为了感谢他们的配合，将送他们一台游戏机，颜色可以任意挑选，而同样一批用户选择黑色的游戏机带回家的更多。很明显，有部分用户说喜欢黄色却带走了黑色的游戏机。用户倒不是想故意欺骗我们，而可能是：他们被问了自己也没仔细想过的问题，又不想回答不知道，就在现场编造了一个看似有理有据的理由，或者他们有讨好访谈者的心理，会回答他们觉得你希望听到的答案，
42、而不是自己真正的想法。对我们来说，防止被骗的方法恐怕像索尼一样，尽量在用户可以和产品发生交互的场合下进行，让用户在“说”的同时也“做”，只不过，这样访谈的成本会明显高于电话访谈或邀请用户来公司的会议室访谈。另外，我们也可以注意区分用户说的事实与观点，一般来说，诸如“我做了什么，步骤如何，碰到了什么问题”这类事实的可信度更高一些，而“我觉得、我认为”这类的观点，则需要带着大大的问号去听。定性研究：用户访谈用户访谈的常见问题与对策第二，样本少，以偏概全的问题。选择样本的时候需要多加注意，尽量做到随机，举几个常见的“不随机”的例子。比如为了成本考虑，我们上门访谈的时候只找了本市的用户，这样很可能得出
43、一些与地域有关的错误推论；又如电话访谈时，为了提高联系成功率，我们优先拨打留了手机的用户，而留手机很可能代表这批用户忠诚度已经比较高；再如邀约用户来公司访谈，“愿意来的用户”，就已经和全体用户有差异了对于这个问题，我常用的几个对策如下。首先，我们应该尽量识别出各种可能引起偏差的因素，并在访谈的报告里标明，让读者了解。然后，为了用尽可能少的样本得到尽可能正确的结论，我会以增量的方式做访谈。举个例子，我会先访谈5个用户，得出基本结论，然后再访谈5个，观察结论是否有改变，如果有改变，就继续加大样本量，或者思考问题是否合适？样本集是否合适？如果没有改变，就停止继续访谈，节省成本。样本的选取，其实属于概
44、率与数理统计的范畴，想深入的同学可以自行研究。定性研究：用户访谈用户访谈的常见问题与对策第三、用户过于强势，把我们往沟里带。一个淘宝产品经理朋友的经验：“当时我们找来了很多淘宝的大卖家，问了几个问题以后，那些卖家的情绪就被调动起来了，似乎好不容易有个倾诉者来听他们创业过程中的成就与艰辛，然后就开始讲故事，比如卖水货手机的帅哥给你讲中国整个水货手机市场，第一级只有深圳的几个人，每天凌晨两点他们会在某个秘密地点出货给第二级，都是以“百台”为单位叫价，和古老的证券交易所一样，然后四点左右第二级就会把当天的价格传真给他改天又来一位卖钻石的少妇给你讲他老公多有钱，就是没空陪她，给她在上海最繁华的地段买了
45、个门店卖钻石，她经常去南非采购，一次买好多，轮着带，不喜欢的就折价卖掉，不为赚钱就是找点事情做真假不论，反正都是无比精彩，我们又不够老道，完全被忽悠得入神了，原本一个小时的访谈变成三个小时，最后送走用户，一看访谈记录，一片空白。“要解决这个问题，需要时刻牢记访谈的目的。如果发现话题不对，就赶紧往正道上扳，若发现多次都扳不过来，就可以考虑尽快结束了，用户很多，不要在一个不合适的对象上花费太多时间。当然，有时候用户侃得十分精彩，如果你不是很忙的话，听听长长见识也可以，这个就自行把握吧。定性研究：用户访谈用户访谈的常见问题与对策第四、我们过于强势，把用户往沟里带。原来我们团队有一位做销售出身的女生，
46、改行做产品，在新产品中负责了几个模块的设计，设计好了邀请用户来做访谈。她的故事很有趣开始挺好的，她慢慢深入地问着，用户小心翼翼地答着。随着访谈的进行，用户渐渐地放开了，开始对产品提出自己的看法，于是砖头一块一块的向那位女生的头上抛去，只见她的脸越来越苦，然后终于忍不住了，心说“老娘当年可是做销售的，看我怎么收拾你”接下来只见风云突转，她给用户晓之以理动之以情，指出了用户的理解有哪些不对的地方，她的产品确实很好，很值得买，几十分钟过去，用户完全被说动（不得不赞叹她的销售功底就是扎实），就差道歉了，觉得这确实是一款好产品，并且承诺说上市以后一定买。用户走后，她心满意足，回来大家一讨论这个过程，都傻
47、了。这个问题的对策，同样是牢记访谈的目的，并且管好自己的嘴。定性研究：用户访谈我在看软件观念革命：交互设计精髓的时候，发现里面也讲了不少关于用户访谈的注意点，在这里分享给大家。避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读。首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面。避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。鼓励讲故事：故事是最好的帮助设计师理解用户的方法。避免诱导性的问题：典型
48、的诱导问题是“如果有功能，你会使用么？”一般来说用户会给出毫无意义的肯定答复。定性研究：用户访谈用户大会用户大会，是邀请产品的用户到某一集中地点开会，人数一般在几十人到几百人不等，可以短时间内从多人处收集大量信息，是一种特别的用户访谈形式。这种会耗费资源较多，一般机会不多，所以要充分利用。按时间分几步重点摘录如下，结合这个提纲，我们来看一下这种用户访谈形式应该如何准备、如何操作，如果把“用户大会”也视为一个产品的话，大家也可以从中看到一些做产品的通用思路：明确目的：会前最重要的是明确这次用户大会的目的和意义，这在争取资源的时候会更有说服力，比如：产品二期卖点确认，辅助运营决策；三期需求收集；现
49、有产品用户体验改进等。定性研究：用户访谈用户大会资源确定：时间：日期、几点、时长。要考虑用户的空闲日子和时间段。另外注意要把整个活动各项准备的时间点掐准，留余量。地点：场地、宣传用品、IT设备、礼物、食品饮料、桌椅。人物：工作人员：大家一起上，人人有事做，分组分工，注意产品、运营、开发人员的搭配，要有冗余；用户：确定目标用户、数据提取、预约，要充分考虑人数弹性；嘉宾：相关老板、合作部门的同事，不管来不来，邀请要发到。材料：用户数据、产品介绍材料（测试环境确保当时可用，静态Demo备用）、可用性测试材料；各项备用方案的准备，用户大会前两天开一次“确认会”。定性研究：用户访谈用户大会现场执行：辅助
50、工作：场地布置（轻松一点，不要像开会）；引导/拍照/服务/机动；进场签到（给礼品）；全程主持（进度控制）；送客/收拾残局。主流程：产品介绍：重点是卖点介绍，与用户互动，观察用户更关注哪些功能，辅助上线前的运营决策，到底主推哪些卖点；抽取部分用户做焦点小组的讨论，收集后续的需求，产品三期开始启动；同时抽取部分用户做可用性测试，帮助产品二期做最后的微调；最后，合影留念结束以后：资料整理：卖点总结报告、需求收集报告、可用性测试报告。运营：本次活动在论坛发贴；内部邮件。整个活动资料的整理归档，包括照片、各项材料/报告信息、用户数据等定量研究：调查问卷同样是听用户怎么说，常见的定量研究方法是调查问卷。调
51、查问卷和用户访谈的提纲是有区别的：用户访谈的提纲通常是开放式问题，适用于我们心里还比较疑惑的时候去寻找产品的方向，适合与较少的访谈对象进行深入的交流；而调查问卷通常封闭式问题比较多，适合大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案，调查问卷不是考试卷，不适合安排问答题。用户谈与调查问卷之间也有联系，我们经常通过前者的开放式问题，为后者收集具体的封闭式问题。无论是网上还是线下，作答时间最好不要超过10分钟，否则很多人看一眼就被吓跑了。开篇一般放一些简单的不需要思考的问题；很想知道的内容，需要思考的，较敏感的问题一般放在中间；而有关被访者个人信息的题目一般放在问卷的最后，以免应答
52、者在回答这些问题时有所顾忌，进而影响其他答案。定量研究：调查问卷调查问卷的常见问题与对策调查问卷一人一份，独立作答，可消除“论坛发贴征集需求”等具有群体讨论性质的方法的弊端。这是因为用户有其特点沉默与骑墙的总是大多数：长尾理论里说到“沉默的大多数”，那么站出来的总是很少数，而且往往是非典型的用户，不能保证其代表了目标用户的想法；而“骑墙的大多数”说的是，大多数人是没有明确观点的，尤其在网络这样一个不用负责任的环境下，所以常见的情况就是开始表态的那几个人的观点引导了群体的观点，随机的初始值决定了结果，这个时候你只有单独和跟风者交流，才会发现他根本不是那么想的。调查问卷的客观性、多份问卷之间的独立
53、性，可以有效避免上述问题，但其容易出现的问题在于：定量研究：调查问卷调查问卷的常见问题与对策第一，样本的偏差，即样本与想了解的目标用户群体出现偏差。之前我们谈到，用户访谈由于样本量的限制，始终只能听到目标用户群体中很少部分用户的声音，而调查问卷可以更多地采样，我们应该充分利用。所以，调查问卷的样本选择，就有几个注意点：尽可能覆盖目标群体中各种类型的用户，比如性别、年龄段、行业、收入等，要保证各种类型用户的样本比例接近全体的比例，比如目标用户中男女比例为7：3，那么我们的样本也应该保持这个比例。但在实际工作中，经常会因为各种原因没法做到样本选择的合理性，比如我们的产品全国销售，但要做街头的拦截调
54、查，出于成本考虑，只能选择特定城市的目标用户；又如利用网络做调查问卷，能在特定时间、特定页面上看到问卷的人，已经是一种筛选；再如在各种场景下，愿意填写问卷的人，也许与目标群体的整体也有不同，又是一种筛选。所以，在类似情况下得出结论的时候，大家最好把这些潜在的筛选条件标明，让报告的读者知道数据获得的方法与来源，同时如果我们是报告的读者，也要一直带着问号去阅读里面的数据。还有一个小技巧，就是可以把目标群体的特征也定义成一系列问题，放入问卷中，待我们回收问卷以后，就可以通过这些问题评估作答者是否能代表目标群体了。如果发现了偏差，我们也可以从回收的问卷中再筛选出一个接近目标群体的子集来分析。定量研究：
55、调查问卷调查问卷的常见问题与对策第二，样本过少的问题。样本量过少时，采用百分比来分析是没有意义的。这是很多新人会犯的错误，比如只问了5个人，3个人选A，就在报告中说有60%的用户选A，这是很不严谨的。因为如果换5个人再做一次，很可能就是40%了，而这样的数字百分比要具备稳定性才有价值。所以，此时只能说“问了5个用户，有3个用户选A”。抛开严谨的统计理论不谈，要给出百分比答案的话，至少得有大约100份的答案。定量研究：调查问卷调查问卷的常见问题与对策第三，问卷内容的细节问题。首先，问题表述应无引导性，这点和用户访谈类似。比如，不要问“你喜欢某个产品吗”，这时用户可能会考虑到提问者的情感而回答“是
56、”，正确的问法是“你是否喜欢某个产品？”答案的顺序，可能产生“顺序偏差”或“位置偏差”，即被调查者选择的答案可能与该答案的排列位置有关。有研究表明，对陈述性选项被调查者趋向于选第一个或最后一个答案，特别是第一个答案；而对一组数字，如价格和打分，则趋向于取中间位置。为了减少顺序偏差，可以准备几种形式的问卷，每种形式的问卷选项排列的顺序都不同。因此，对于重要的问卷，为了避免上述问题，还有个通用的办法就是先进行小范围的试答，根据反馈修改后，再大面积投放，这和互联网产品的灰度发布有着同样的理念。定性研究：可用性测试可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少
57、数几个用户的测试，看他们怎么做，属于典型的定性研究。它是UGC理念的一种很漂亮的实践，在目的明确的前提下，简单介绍一下主要过程。首先要招募测试用户。招募测试用户的主要原则是，这些用户要能尽可能地代表将来真实的用户，比如说，如果产品的主要用户是新手，那么就应当选择一些对产品不熟悉的用户。然后是准备测试任务，测试的组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。接下来的重头戏是测试过程。可用性测试的基本过程就是用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。测试结束后：组织者可以询问用户对于产品整体的主观看
58、法或感觉。另外，如果用户在测试的过程中没有完全把思考的过程说出来，此时也可以询问他们当时的想法，询问他们为什么做出那些操作。最后是研究和分析：在可用性测试结束之后，组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。可用性测试的常见问题与对策第一，如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了。其实，可用性测试在产品的各个阶段都可以做。在尚无任何成型的产品时，可以拿竞争对手的产品给用户做；在产品只有纸面原型的时候，可以拿着手绘的产品，加上纸笔给用户做；在产品只有页面Demo的时候，可以拿Demo给用
59、户做；更多的时候，在产品已经可以运行以后，可以拿真实的产品给用户做。不同阶段不同做法，从中都能发现相应的问题。第二，总觉得可用性测试很专业，所以干脆不做。可用性测试，听着很专业，但收益又无法量化，所以对很多老板来说，不太愿意在这个上面投入资源，经常因为项目时间过紧被略过。我们知道，可用性测试通常来说做5个左右的用户才可以发现大部分的共性问题，前前后后的准备也耗时不少，但只做一个用户，并且简化步骤，也比不做要好。对一个内部使用的用户管理平台，我自己尝试过一次最轻量级的可用性测试，表现为：一个同事，半个小时，在我的座位上，简单的几个任务，比如“将XXX用户的有效期增加一年”，“将YYY公司的状态设
60、置为冻结”，“查询ZZZ公司的员工数”等。结果发现了十几个问题，效率很高。定性研究：可用性测试可用性测试的常见问题与对策第三，明确是测试产品，而不是测试用户。可用性测试要邀请用户来做测试人员，我们在开始之前，应当明确地告诉用户，这个测试的目的是发现软件产品中的问题，而不是要测试用户是否有能力来很好地使用软件。所以，不要让用户听到“可用性测试”的术语，而是说“来试用一下我们的新产品，提点意见”。清楚地说明这一点将有助于减轻用户的压力，使得他们能像在真实环境一样来使用软件。第四，测试过程中，组织者该做的和不该做的。刚开始的时候，可以告知用户大概持续的时间，要做哪些事情，让用户心中有数，轻松愉快地完
61、成任务。可用性测试中，我们可以要求用户在使用产品的过程中采用一种名为“发声思维”的方法，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作，等等。做测试的过程中千万不要有任何的引导与暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，实在进行不下去的时候，给予提示。记住，一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了。结束之后，如有可能应该送个小礼品，当然在邀请的时候就要告诉用户会有一些对他付出时间的补偿。尽快总结，并且发给用户，一方
62、面让用户感到他做了一件有意义的事，另一方面也是表示感谢，建立长期和谐的“用户参与产品设计”的氛围。最重要的，这份总结要用于指导产品改进，这才是可用性测试的根本目的。定性研究：可用性测试定性研究：数据分析只要你做的是一个大用户量的产品（互联网产品往往都有这个特点），那么我们总会惴惴不安：上述3种方法，就算做问卷的普查，回收到的有效问卷也可能不到用户总数的10%，或者说，在样本的选择上都有一定的被动性需要样本同意参与，所以它们都只能接触特定的少部分用户，那么到底能不能代表目标用户群体？虽然绝大多数情况下的经验证明，只要在用户的选择上没犯什么低级错误，他们是“具有代表性的”，或者说接受这种假设是一种
63、性价比很高的廉价解决方案。不过，我们还有数据分析，一种定量的研究方法，数据来说话，看看用户到底是怎么做的，不论是考察目标用户全体、还是采样，都完全可控，所谓“Accordingtothedata”是最难被驳倒的。数据分析时，根据不同的目的，数据来源多种多样，常见的有用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等。数据分析的方法，最简单的可以用Excel，复杂一点的可以用一些统计软件、数据库软件，或者直接自己写程序解决。而最最关键的就是对结果的解读，通常数据分析只能发现一些现象和问题，并不能了解原因，所以分析完成后通常会伴随着一些用户访谈，听听用户怎么解释。数据分析的常见问题
64、与对策第一，过于学术，沉迷于“科学研究”科学研究通常只注重“性价比”的性，只要结果好，往往不在乎投入，因为相对而言科研的结果不是为了马上应用，而是为了证明实力。但实际生产环境就更注重综合的性价比了，所以我们日常的数据分析方法也就显得不那么严谨了，我特指小步快跑的创业团队，他们可能不需要在每次分析前都去验证样本群体是否符合某种统计分布，也可能不需要用“人工神经网络”等“高科技手段”去预测产品将来的用户数，甚至给出“AB”的结论时也用不着做“显著性检验”，一切的一切需要的只是一种感觉，一种对数据的敏感，对商业的敏感。第二，虽然数据不会主动骗人，但我们经常无意或有意地误读数据。无意地误读数据，举个例
65、子，对一个人群，人们的身高用平均数来衡量是有意义的，因为我们知道身高属于典型的正态分布，中间多两边少，所以一个平均值就能了解群体的大致情况，而对人们的收入，就不能用平均值来衡量了，一个超级富豪和1000个零收入的人一平均，很可能得出人均收入100万的荒谬结论。这个问题的对策，是学习统计学的知识，努力提高自己的水平。主动地误读数据，是比较有趣的现象。在提取数据之前，我们心中通常已经有一些结论了，无非是想验证它，而抱着这点思想，就总能找到数据来证明自己已有的想法，并且技术越娴熟的人越容易做到这点。对于这点，我想一个简单的对策就是对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益
66、牵扯，比如为了证明老板的判断，或者为了保持自己之前拍脑袋的英明形象等，你明白我的意思。定性研究：数据分析第三，平时不烧香，临时抱佛脚。这是一个很实际的问题，我们经常在做决策的时候才想起来数据分析，但忽然发现手头没有数据可分析。一次又一次地发生同样的情况为了避免，我们应该在产品设计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等，这也算一种典型的非功能需求，这样做对产品的可持续发展非常必要。上面用很大篇幅说了一些常用的需求采集方法，这一节，我想先抛出一个“一手需求与二手需求”的概念，有个很形象的比喻就是“生孩子与养孩子”，话糙理不糙，我们内部经常这么说。我们首
67、先把“生孩子”需求采集视为己任，人人有责，希望所有人都参与，都来“生孩子”，我们帮大家养，这就要给他们一个简单的“生孩子”的工具“单项需求卡片”，最后，简单介绍一下其他常用的方法，这样才能做到“尽可能多地采集”。之前所述的各种方法，都是直接从用户那里得到需求，我称之为一手需求，就像“生孩子”。其实很多时候，我们还会接受二手需求，比如老板说要给用户做个功能、销售人员说用户哪里用起来不顺等，这些需求和一手需求比起来，就像“养孩子”。“生孩子”，更多的时候发生于新产品诞生前，这时候外部没有用户、内部没有运营、销售、服务等，所以对于需求而言，更多的是产品人员驱动，去主动采集需求，比较常见的就是直接去潜
68、在的目标用户那里采集。这个从无到有的过程，个人觉得发挥的空间最大，是最有成就感的。而“养孩子”，通常是产品已经运行了一段时间以后，用户也有了，公司内部也多了很多相关的人员，比如销售和服务。虽然产品部门与用户的直接接触变少，但多了很多间接来源，即与终端用户接触的干系人，他们会向你反馈很多需求，而用户也开始主动提出需求了。需求采集人人有责对比一下，生孩子的时候，我们去主动“拉”需求的比例较高，需求都是直接从用户那里得到的，有点“进攻”的感觉，而孩子生出来以后，就不再是你一个人的孩子了，必然是大家一起养，所以我们需要照顾的各方各面也会更多，我们会收到很多“推”过来的需求，比较像“防守”的感觉。有很多
69、同学从一开始工作接触的就是已经存在的老产品，需求始终堆积如山，如果碰上销售强势的产品，那更是连响应销售提过来的需求都来不及，也许做了半年一年，突然回想，发现自己连真正的用户都从来没接触过，而是始终在满足销售的需求。个人感觉，这种二手需求，或多或少有扭曲，以销售为例，他们的考核指标决定了会比较注重眼前，希望产品的卖点越多越好，而之后用户用得如何，就不那么关心了。比如我就经历过一些让人很抓狂的二手需求，销售希望产品增加一个功能，这个功能在说服客户购买产品时有“临门一脚”的作用；而用户买完以后，最好又别用这个功能，以免增加服务部门的压力所以在公司层面上看，我觉得产品部门至少应该和销售、服务等部门有平
70、等的地位，坚持不断的从终端用户那里直接获得需求，才能保证产品的可持续发展。但二手需求毕竟是常态，我们经常接到的就是口头上的几句话，或者一封邮件的几行说明，这中间理解的偏差只能靠我们主动的、反复的沟通来弥补，那么有没有什么办法解决呢？下面我就介绍一种简单的二手需求采集工具单项需求卡片。需求采集人人有责单项需求卡片的理念就是：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程，理想的状态是产品的所有干系人都参加过“需求采集”的培训，然后在日常工作中养成主动提交需求给产品人员的习惯，但实际很难做到，所以作为专业的需求分析人员，就应该尽量降低同事们，比如销售
71、、服务、技术人员提交需求的成本，也是节省我们自己的时间。一张单项需求卡片描述了一个用户需求到底包含哪些内容，重点是描述用户场景，谁在什么时间、地点产生了何种需求，先看一个模板，如下表所示单项需求卡片单项需求卡片见Excel文件单项需求卡片-范例上图是工程师提的一个需求，就像我们永远无法猜到用户会怎么使用我们的产品一样，“单向需求卡片”原本是让大家给产品提需求，而工程师却拿它来给产品经理提意见，很有意思。从表格的填写就可以看出来，实际工作中我们能拿到的都是填写不完整的，甚至是字迹难以辨认的，当然，也可以尝试电子版，那样我们整理的成本低一些，不过很可能愿意填的人就少了。但我们心里得有个底线，一张有
72、价值的单项需求卡片，至少得有“需求描述”，需求编号、来源、场景最好也能有，其他的，其实很少有人愿意填写了。回到这张卡片，工程师描述的一个需求也很有意思，值得我们共勉“PD慎重地考虑一些细节的改变，在没有大影响的前提下，不要对稳定的版本做一些鸡毛蒜皮的动作”。工程师们也希望自己做的事情都能产生商业价值啊。每当我们拿到这样的卡片，就需要主动去和提交人交流，完善卡片的内容。真实的工作中你能体会到，这张卡片只是需求过程的中间产物，所以我们在这上面花费的精力也是尽量缩减，单向需求卡片所描述的用户需求，最终要转化为产品需求才有真正的价值。单项需求卡片-范例需求采集，并不是产品设计之前的工作，而是一个贯穿始
73、终的过程；它并不是产品人员的事情，而是所有人的责任；它没有特定的方法，不管白猫黑猫，抓到老鼠就是好猫；它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求这才是需求采集的大生产运动。最后再简单分享几个有特点的需求采集方法，希望大家能灵活应用，尽可能多地采集。现场调查：说简单一点就是打入“敌人”内部，和客户一起工作一段时间，深度了解需求。它是一种典型的定性分析，持续时间长，从几小时到几个月，既能听到用户怎么说，也能看到用户怎么做，不过受众面极其狭窄，一次只有一个，要特别小心被“非典型”用户带到沟里去。AB测试：基于大用户量比较合适，比如有一个按钮不知道是放页面的左边好，还是右边好，而我们有10万用户
74、，那就先随机挑选少量的用户发布这个按钮，1000人放左边，另外1000人放右边，然后过一段时间分析结果，再决定剩下的98%用户该怎么办。很明显，这也是让用户直接参与了设计，这样低成本的方法让很多传统行业的同学羡慕不已。日记研究：互联网新兴的个人应用比较适合，某个新产品出来以后，很多业内的朋友都会去尝试，然后写一些使用体会，但作为产品设计者在看这些日记的时候，要明白日记的作者往往是同行，而不是主流用户。卡片分类法：我们把产品的各种需求写在便利贴上，让用户一起讨论并完成分类。这能让你深入了解用户是怎么给产品划分模块的，用户认为这个网站应该是什么结构。因为产品设计人员的思维和用户的思维通常不一样，这
75、也就导致了如果是产品设计师来单方面决定网站结构的话，很可能导致用户理解的困难，所以卡片分类法能让最终的产品更加符合用户的心理模型。自己提需求：这是最简单的方法。每一个靠谱的产品都会有一群粉丝用户，不用你去找他们采集需求，他们也会给我们惊喜，主动提出很多需求，作为产品的主人，我们好意思还没有用户了解产品么？产品要用才能感觉出好坏，特别是自己做的产品。产品做多了，我们随便看看别人做的产品，总能一下子挑出很多问题，提出很多需求，反过来看自己的产品越看越完美，这一定有问题，所以必须用自己的产品，最好是发动认识的人都来用。尽可能多地采集听用户的，但不要照着做采集了很多需求，但是一团乱麻，从哪里着手？用户
76、都帮我们想好该怎么做了，照他说的做么？引言用户跟福特要一匹更快的马，福特却给了用户一辆车。这就是我们存在的价值。明确我们存在的价值小说说他需要一个电钻，这是他提出的解决方案，但在大毛的刨根问底之下，发现小明其实想要的是一种温馨的家的感觉，有了这个认识，我们就可以给出很多产品来满足。比如卖他一套实施方案，带着电钻、油画，上门安装；比如用背面有强力胶的钩子挂画；比如直接把画黏在墙上；比如直接在墙上画，并且让小明自己画；再比如放一组书架在那里经过我们分析得到的解决方案，比起小明自己说的，优势就在于可能省了钱、省了时间、更温馨，等等。对同一个问题，这两套解决方案的区别就是，一个是用户需求，一个是产品需
77、求。而这中间的转化过程，就是这课的主题需求分析用户需求：用户自以为的需求，并且经常表达为用户的解决方案。产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。听到过一个说法，说需求分析与常见的技术分析最大不同是思路的本质差异，技术分析是“树干树枝树叶”的任务分解过程，技术人员很适应并乐于用这种方式思考，可以把大问题分解成小问题，发现难点逐一攻克。不少需求人员都是做技术出身的，所以开始往往会用这种思路做需求，听到客户提出的功能点，直接想怎么做系统设计了，这导致有时候需求分析甚至已经越俎代庖到“详细设计”
78、的职责了。大多数人在生活中也习惯于用这样的思路来对付问题，而真实情况是，需求分析是“首先：树叶树枝树干，其次：树干树枝树叶”的分析过程，所以说完整的需求分析是一个“分-总-分”的过程。一方面不能漏掉提炼用户需求的这个过程，目的是透过现象看本质，另一方面也不能停在本质上，试想如果做到“树干”就结束，后端的执行人员可能还是不知道要做什么东西，所以我们还要继续把树干再重新分解成树枝、树叶。用户需求VS.产品需求伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西，这就是本节标题的意思我们存在的价值。说到这里有必要提一下，销售人员经常说：“
79、用户是为想要的东西买单，而不是需要的”，用我们上面分析翻译一下，其实是“用户是为自己提出的解决方案买单，而不是我们的解决方案”。是不是很纠结？那我们还分析个什么劲啊，直接做用户要我们做的得了。其实这是短期利益和长期利益的权衡，如果是一锤子买卖，卖出以后又不用售后，那么采用实用主义，不妨用户要什么就给他什么，这样他掏钱最爽快，你回忆一下在风景区买的纪念品的情景，大多数情况下，是不是你要啥卖家就给你啥？这种情况下就要追求短期利益。但是，我们的产品通常都是希望用户长期使用的，并且后续的服务也是我们来做，所以为了长期利益，我们就有必要找到用户的真实需求，然后给他真正合适的产品了，哪怕这个过程不那么讨好
80、。不知道你有没有帮女生买电脑的经历，帮她买也就意味着将来的售后服务、技术支持、维修都是你了，所以你才会在型号和配置上和她争吵，努力说服她不要买那些中看不中用的，而要买“真正的需求”。用户需求VS.产品需求我们通过产品需求来满足用户，顺着这个思路，就是要做一些用户真正需要的功能或服务，虽然这是最常用的办法，但也是最“劳民伤财”的。在甩开膀子干活前，我们有必要扩展一下思路，从问题的本质出发，寻找新路。之前我们说过，需求来源于理想与现实的差距，那么减小这个差距就有三种方式：改变现状：是我们最常用的，去开发某种产品，但也是最笨的办法。降低理想：不要忽视精神的力量，什么“打预防针”、“丑话说在前头”这类
81、句子想必大家都经常听到。转移需求：因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会觉得这个差距没那么可憎了。我们也可以说，人的行为是需求驱动的，想改变人的行为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求。满足需求的三种方式某写字楼可能是因为建造得比较早，考虑不周，电梯明显不够用，每天中午吃饭的时候总是很挤，最上面几层的小白领们平均要等20分钟才能下到3楼的餐厅吃饭，于是抱怨很多，他们给物业提意见，要求解决。物业公司找到了大毛，大毛帮他们分析了一下。用户需求VS.产品需求生活事例说明改变现状、降低理想、转移需求改变现状：对现有产品做一些改进，在这个案例中就是增加电梯数目
82、，或者加快电梯运行速度，但成本太高，直接被否定。降低理想：告诉楼里的小白领们，隔壁那个写字楼中午要等40分钟呢。俗话说“不患寡而患不均”，人们更在意的是相对而不是绝对，这样确实可以减少抱怨，但是一种低水平的满足需求，对产品美誉度没有帮助。转移需求：电梯门上贴一些锻炼身体的公益广告，当然内容是说爬楼有益身体健康。有效，部分用户走楼梯去餐厅了，但是刚吃过饭怎么办？爬几十层楼要得阑尾炎的。最后，采用了一个看起来很傻的方案，在电梯门旁边安装一面镜子，让等待的人们可以整理一下仪表，或者搔首弄姿一番，不至于那么无聊。我们后来发现还有其他的解决方案，比如电梯广告，不但可以转移用户注意力，减少抱怨，而且对写字
83、楼来说，既不用花钱，又额外挣得一笔广告费；又如错开午饭时间，让人们都能更少地等待。所有这些，都是想告诉大家，满足用户的需求，不一定要做新产品或者新功能，而是更应该想想是否有“四两拨千斤”的妙招。谈创造需求满足需求的方式，我们开阔了思路以后从一种变为了三种，但毕竟都是用户提出来的需求，我们能不能再开阔一点？不劳用户的大驾，直接达到产品设计的最高境界创造需求！工作中典型的场景，就是老板或者产品人员的突发奇想，这些灵感在潜意识里都有一定的依据，是基于对用户、市场、产品的充分理解，也有过不少案例，这些需求最终获得了用户的认可，但更多的被证明是过于天马行空。苹果公司的乔布斯，可以说是创造需求的大师，但我
84、不建议大家学，这是需要天赋的，但这份天赋非常值得保护，产品的进化和生物的进化一样，需要如基因突变一般的胡思乱想。更实际的，我认为需求分析的过程其实也有创造需求的成分，当一个新人真的能力不足的时候，不妨先做用户提出的需求，而不要自己去胡乱分析用户需求，而对于一个团队来说，要尽量避免“只有能力不足的需求分析人员”这种情况出现。我们刚上路，既要怀揣梦想，也要脚踏实地，所以接下来我们老老实实地开始给需求做一次DNA检测。给需求做一次DNA检测整个检测过程不妨用图来表示，我们先把用户需求转化为产品需求，然后一步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。特别提一下，这里确定的是产品需求的
85、各种属性，不同于之前提到的“单项需求卡片”，那张卡片里描述的是用户需求的各种属性。给需求做一次DNA检测把用户需求转化为产品需求检测的第一步就是“需求转化”，现在我们有很多用户需求，可能记录在“单项需求卡片”里，可能记录在Excel里，可能是用Word随意写的几段话，也可能是一张思维导图，像下图这样，图看不清没关系，我只是想表达采集来的需求非常多。当然，在一个团队里，还是建议大家统一一种记录用户需求的形式。给需求做一次DNA检测把用户需求转化为产品需求举个例子，对于我经常做的软件产品，用户需求是“删除数据之前需要我确认，以免误删”，转化分析以后，我们给出的产品需求可能是“数据回收站：删除的数据
86、进入回收站，如果是误删，用户可以去回收站找回数据”。因为我做的几个产品都是用Excel来记录需求的，所以下面也以Excel为例来讲述，大家可以用其他工具来记录需求，但核心思路都是大同小异的。整理好的产品需求列表看起来是下图的样子。我们把它叫做FeatureList（功能列表）。一些Excel的简单技巧，建议大家还是学习一下，比如条件格式、筛选、单元格有效性、单元格锁定、隐藏等，可以让表格管理起来轻松一点，看起来也美观一点。对任何产品来说，只要需求采集的功夫做足了，你就会发现上面这个产品需求列表行数超多，所以在需求转化过程中，我们也会做一轮筛选，把明显不靠谱的用户需求直接过滤掉，不计入上述列表，
87、当然，是否“明显不靠谱”就要由你来把握了，不要把“没资源做”、“短期内有技术难点”的用户需求给错杀了。给需求做一次DNA检测确定需求的基本属性对于产品需求列表的维护，有时候我们是在产品团队里指定一个人负责，所有的需求都由他来录入，有时候是采取共享文档的形式，大家共同维护，但不管怎样，我觉得对于每个需求，提交人都可以独立确定一些基本属性，如表所示，这些属性是：需求属性属性说明编号需求的顺序号，唯一性标识提交人(*)需求的录入PD，负责解释需求提交时间需求的录入时间，辅助信息模块(*)根据产品的模块划分名称(*)用简洁的短语描述需求描述(*)需求描述：无歧义、完整性、一致性、可测试等提出者即需求的
88、原始提出者，有疑惑时便于追溯提出时间原始需求的获得时间，辅助信息Bug编号将一些Bug视为需求，统一管理给需求做一次DNA检测确定需求的基本属性编号：看似作用不大，最初表格中没有这一项，但有一次大家把列表打印出来讨论，当提到某个需求的时候，发现很难告诉大家是哪个，因为Excel的行号没有一并打印出来，所以后来我们都把序号加上了，作为需求的唯一性标识。有时候在某个需求的备注里，也会写“与273号需求类似，可以参考”。提交人：必填，提交人是PD，我们的需求管理方法比较轻量级，更多的是只管理产品需求，而用户需求并没有很好的整理，经常只是一堆各种格式的文档，所以提交人要负责在今后的任何时候解释这个需求
89、的来源，提交人有义务充分理解原始的用户需求。提交时间：这是一个辅助信息，记录提交人是何时录入这个需求的。模块：一般来说，根据人类记忆的特点，产品有52个模块比较合理，如果超过7个，你就要考虑重新划分，甚至增加一个基本属性叫“二级模块”。如果你是做网站产品，这些模块的划分就很可能影响到网站的导航结构，这属于信息架构领域的知识。当然，在设置自己电脑里的文件目录结构时，也可以遵循这个原则。名称：用简洁的短语描述需求，要给用户提供什么功能，比如：黑名单。描述：这里可以具体解释一下名称里说的功能是什么意思，比如：用户可以选择联系人并加入黑名单，或者将某联系人移出黑名单，在黑名单里的联系人无法给用户发消息
90、。描述只要说此功能要做什么，无须解释怎么做，注意语言的无歧义性、完整性、一致性和可测试性等，关于具体怎么写，以后的课程里会具体讲解。提出者：即用户需求的提出者，有疑惑时便于更进一步追溯。提出时间：原始需求的提出时间，区别于提交时间，这是个辅助信息。Bug编号：可选，这是因为我们把产品的某些Bug也视为需求，所以加入这个表格统一管理。给需求做一次DNA检测需求种类然后，需求的提出者需要自己辨别一下这个需求的种类，为后续的商业价值判断提供一些辅助信息。我们尝试过几个维度，如表2-5所示：需求属性属性说明分类新增功能、功能改进、体验提升、Bug修复、内部需求等层次基础、扩展（期望需求）、增值（兴奋需
91、求）给需求做一次DNA检测需求种类-分类分类：可以分为“新增功能、功能改进、体验提升、Bug修复、内部需求”等。其实产品需求远非我们直接可以想到的功能需求，还包括了很多非功能需求，比如：性能、可培训、可维护、可扩展有很多需求不是为终端用户做的，而是为销售、服务、测试团队的同学做的。举几个例子，“论坛需要支持1000人同时在线”，这是一个性能需求；“系统功能升级，必须在发布2周以前完成对客服部门的培训”，这是一个培训需求；“如果硬件压力突增，应该有报警，具体细节是”，这是一个运维部门的维护需求；“在用户数增加10倍的情况下，硬件投入必须小于10倍”，这是一个可扩展需求；“此功能的用户操作日志需要
92、记录”，这是一个内部数据分析的需求。当然，对于一些边缘的需求，是列入这个表格统一管理，还是另外单独对付，这可以随机应变。通常来说“产品功能需求+产品非功能需求=产品需求”，而“产品需求+市场需求+开发需求+测试需求+服务需求+=产品包需求”，对这些概念感兴趣的同事可以去查阅“需求管理”相关的资料。给需求做一次DNA检测需求种类-层次层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，理论依据参见KANO模型。小明：“我想到一个手机的例子，打电话、发短信是基本功能；给电话录音是扩展功能，和基本功能相关；而如果这个电话特别结实，可以当锤子砸钉子，或者当砖头防身，那就是增值功能了。”大
93、毛：“嗯，好多山寨手机的特点就在于满足了一些诡异的增值需求，比如可以当手电筒、当验钞机、当剃须刀”小明：“你是在夸还是在贬呢？”大毛：“我也不知道，那些已经超出普通手机的范畴了”。对需求种类的区分其实没那么绝对，取决于很多因素，比如商业目的变了，某个功能的分类也就变了，我自己经常从“雪中送炭”还是“锦上添花”的角度去理解：雪中送炭是基本功能，对用户很有用，产品缺了这个功能根本跑不起来，比如E-mail系统里的“收发邮件”；锦上添花的功能是指非必须的，用户有时用得到，有的话会给用户的使用带来方便，比如在发E-mail填写收件人的时候，系统根据你输入的内容自动提示你曾经发送过邮件的联系人，如下图。
94、我们在和用户接触的过程中会很明显地感受到这两种需求的不同，没有雪中送炭的功能就像系统有缺陷一样，所以应优先考虑。而当一个锦上添花的功能被用户普遍接受以后，几乎所有的产品也都拥有了，也就渐渐发提升为雪中送炭的功能了，就像现在的手机，几乎没有人能接受黑白屏一样，当初彩屏可是作为一大卖点来宣传的。给需求做一次DNA检测分析需求的商业价值一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的，所以“需求的商业价值”是最关键的内容，有条件的团队最好利用群体智慧，我们通常在这个时候举行“需求讨论会”。正因为商业价值如此重要，所以最复杂的时候我们尝试过用重要性、紧急度、持续时间3个指标来衡量：
95、需求属性属性说明重要性重要程度，辅助确定商业价值紧急度紧急程度，辅助确定商业价值持续时间持续时间，辅助确定商业价值商业价值(*)商业优先级，不考虑实现难度，群体决策给需求做一次DNA检测分析需求的商业价值重要性：可以参考时间管理里“重要与紧急”的概念。这里的重要度又可细分为：满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼”，更多可以学习KANO模型加深理解。紧急度：在时间维度上判断这个需求是否迫切，紧急不重要的需求通常表现为解决了短期的问题，如果熬过去没做，对长期影响不大；或者解决了局部的问题，如果不做对于大多数用户没有影响。比如某个用户是大老板的朋友，通过大老板“天外飞仙”地提
96、过来一个需求，就很可能是一个超级紧急的需求，但重要性未必很高。持续时间：需求是有生命的，有的长寿有的短寿，比如迎合过年过节的运营活动需求，一般就比较短寿。试想8月我们录入了一个庆国庆的主题运营活动，如果到了9月底还没资源做，那一年内也就不用再考虑这个需求了。商业价值，或者叫商业优先级，是对上述几种商业价值指标的综合评判。这一条是整个需求列表中最核心的部分，这里的判断直接影响着产品未来的方向。有时候我们还在列表里增加一列“商业价值描述”，通俗点就是这个需求的卖点是什么，可以给用户提供什么价值，对公司又有什么帮助。如此重要的商业价值评估，我们的做法是在需求讨论会上由产品团队集体讨论，再叫上有必要的
97、干系人，比如销售、服务等。对于某个需求，需求提交人是对它最熟悉的，提交人先基于自己对商业目标的理解，做一番陈述，主观定个级别，比如高中低。然后大家讨论，所以在这个讨论会之前，每个人都应该做好功课。上述那么多的维度，可以加权平均得到综合的商业价值，我们甚至还尝试过在列表中增加“某关键人物的打分”一列，但绝大多数实际操作中，我们都是直接把商业价值抽象为一个指标，用“高、中、低”，或者“5、4、3、2、1”来衡量。而具体讨论的时候，大家充分表达意见之后，安全的做法是谁官大谁负责，俗称老板拍脑袋，最终由会场上级别最高的人报一个数字结束，这就是现实，也是一种高效的办法。我曾经考虑过群体打分取均值等方式，
98、可是实施起来成本太高，很难推动，也不是很有必要。给需求做一次DNA检测初评需求的实现难度绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。我们现在知道了每个需求的商业价值，接下来决定做哪个还需要另一个关键指标，那就是实现难度。有时候我们会叫上技术人员代表参与需求讨论会，当场确定这个指标，但更多的情况是留给做技术的同学一点时间，会后与相关的PD讨论确定。但实现难度这个词太难量化，所以在实际操作中我们会对它进行大刀阔斧的简化。首先简化为人力成本，即工作量，其他资源的消耗，比如额外的硬件成本，我们会发现只有极少数的需求会有这样的问题，不具有普遍性，所以碰到的时候
99、都做特例处理。其次，我们把工作量再简化为开发量。我经历的项目，各类人力资源有：产品、开发、测试、服务等。但一般情况下，团队里产品人员资源相对富裕，测试资源可以调配，服务资源可以临时补充，所以开发资源经常成为瓶颈。于是，我们一般评估每个需求的开发工程师工作量来表征其实现难度，这背后的道理是以团队里的瓶颈资源为评估基准（如表所示），大家视自己团队的情况灵活应用。需求属性属性说明开发量(*)需求的开发工作量，实现难度给需求做一次DNA检测初评需求的实现难度在这个时候，需求其实并不明确，只知道要做哪些，还是比较粗略的要点，而具体怎么做根本还没有考虑，所以有的技术人员会觉得无法评估开发量，这很正常，这个
100、问题我们和技术人员纠结过许多次。他们说你们不明确每个需求怎么做，他们就无法准确评估开发量，我们说没那么多时间明确每个需求该怎么做，你们不评估每个需求的开发量，我们就不知道哪些值得进一步分析怎么做，而哪些又不值于是就死循环了。这类先有鸡还是先有蛋的问题也无须纠缠，我们继续讲实际的。开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的人来评估，通常是技术经理，或者系统分析师、架构师。他们做出简单的评估，并且靠不断的实践来反复修正，评估者通常估计自己做这个需求要多少时间，然后乘以一个系数，这个系数大于1，反映着相应技术团队的平均技术能力。这里的评估一般用“人天”作为单位，某个需求需
101、要“1人天”意味着需要1个人做1个工作日。相对于“初评”，在项目启动之后，制定项目开发计划的时候还会有一次更精确的评估，那时候需求怎么做已经知道、由哪位开发工程师来做也知道，所以可以推算出相对准确的工期，工期和工作量是有很大区别的，比如生一个小孩，需要1个女人10个月的时间，工作量可以说“10人月”，但10个女人1个月的时间，同样“10人月”是绝对完成不了这个任务的，不管几个人，工期都只能是10个月这个话题在以后还有机会慢慢谈。给需求做一次DNA检测性价比我们已经做了需求采集，把用户需求转化为产品需求，知道了某个需求的基本属性、种类、商业价值、开发量，现在似乎应该开始写文档、干活了，但经验告诉
102、我们不是这样的：绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。给需求做一次DNA检测性价比范例：我做过的某个产品页面的访客，在2009年某段时间内使用各种网页浏览器的比例下图所示：第一名是微软的IE，99.14%（其中IE6.0又占75%）；第二名Firefox，0.45%对应的需求是：“产品页面在Firefox下显示有问题，比如”，而我在注释里写道“对不起，我们就是不支持Firefox”。当然，这句话是写给自己人看的，千万别对用户讲。这个需求实现难度不大，但一直在功能列表里放着没动，说实话，能在列表里出现的需求，严格意义上讲，没有任何一个是没有价值的，
103、也没有任何一个是做不了的，那么到底先做哪个，后做哪个？就像早在前面就谈到的“不要试图满足所有用户”，一切皆看性价比。给需求做一次DNA检测性价比有了那么多的准备，现在我们只要做一道简单的小学算术题就可以回答上面的问题了。性价比=商业价值实现难度（简化为开发量）现在可以做决定了，我们把产品需求列表按照“性价比”一列从大到小排序，先做排在上面的就可以了。需求属性需求属性属性说明属性说明 性价比(*)“商业价值/开发量”，用于决定先做哪个 但是工作中对“性价比”的判断还是会经常有偏差，很实际的一个原因，是自己经常和哪类人接触。2007年下半年的工作中，由于一直和工程师直接接触，经常听到他们抱怨某个需
104、求太麻烦之类的，所以综合考虑时有点倾向于做实现难度小的；而如果经常和销售、运营的同学一起开会，就会倾向于更多的考虑商业价值，这点与大家共勉，时刻注意。道理说完了，对需求的DNA检测也暂告一个段落，接下来我们将迎来一场残酷的“战争”。少做就是多做一个功能的多次需求会议中，必然有这样一个过程：开始对一个功能想得不完整，说着说着大家都想把这个功能做得再强一点，这里加一点那里加一点，但后来通常因为技术实现、资源等原因，又把这些加上去的功能点一个又一个地砍掉，甚至会发现砍到最后和一个月前的第一次方案是一样的。看似白搭的这个过程其实是有用的，这是一个“见山是山，见山不是山，见山还是山”的三段过程，对于那些
105、加上又砍掉的功能点，在第一个阶段我们根本没有想到，第二个阶段想到了，很兴奋，那就做吧，而第三个阶段的砍掉是权衡了利弊之后的决定，和“没想到”是完全不同的。我们无法绕过第一阶段的无知，也千万别停在中间那个功能点“大而全”的时候，必死无疑！而第三阶段的“少做”则是超越第二阶段“多做”的“少做”，这才是真正的“多做”。有很多文章谈到这样的思想，用100%的质量去实现75%的数量，而不是反过来！吸引用户的往往只是功能模块中的一两个点，我们一开始只要让其拥有100%的质量其实就够了，这样留给用户的是升级的期待，而如果反过来，功能铺得很开，但每个点都不爽，那反而喧宾夺主，把闪光的地方给掩埋了。情愿把一半的
106、功能做到尽可能完美也不要把全部功能都做成半吊子。越来越觉得当发现一个功能可有可无的时候，甚至只要是没有强烈的理由要做的时候，要明确的选择：不做！现在我们可以自我安慰了少做就是多做！最爽就是“四两拨千斤”我们提到满足需求有三种方式，其实就算“改变现状”这样一种最常用的办法，也有很多“四两拨千斤”的方案。如果机会闪现，就千万不要放过，因为做这样的事情实在太爽了，让我对下面这个故事过目不忘。少做就是多做话说某跨国日化公司，肥皂生产线上面存在包装时可能漏包肥皂的问题。于是该公司总裁命令组成了以博士牵头的专家组对这个问题进行攻关。该研发团队使用了世界上最高精尖的技术（如红外探测、激光照射等），在花费了大
107、量美金和半年的时间后终于完成了肥皂盒检测系统，探测到空的肥皂盒以后，机械手会将空盒推出去。这一办法将肥皂盒空填率有效降低至5%以内。问题基本解决。再说某乡镇肥皂企业也遇到类似问题，老板命令初中毕业的流水线工头想办法解决之,经过半天的思考，该工头拿了一台电扇到生产线的末端对着传送带猛吹，那些没有装填肥皂的肥皂盒由于重量轻就都被风吹下去了。这样做得更少，但是效果更好，至少性价比更高。当然，具体情况要具体分析，任何事情总有它的两面，上例中乡镇企业的解决方案换到跨国公司的环境中，也许并不适用，比如会造成肥皂盒无规律地四处翻滚，引起更大的问题，但我想表达的意思是：我们用不着觉得只有“吃苦耐劳”，做了很多
108、事情才是贡献，而应该直接从目的出发。有一句话说得好：内部（指偏技术）的大改动往往是外部（指偏商业）的小改动，反之亦然，所以我们应该在动手前先找找有没有成本低，收效大的解决方案！尽可能多的放弃我说“尽可能多地采集”，这里，我又说“尽可能多地放弃”，看似矛盾，其实正反映了我们对事物的认识过程，只有在收集阶段没有遗漏，才可能完整地看到事物的全貌，有了大局观，在放弃的时候才知道孰重孰轻，也更下得了手。多年以前我看到白鸦写过的一段例子，发现如果不放弃，最终会被自己折腾死，他是这么说的：少做就是多做是不是需要改评论？删评论？发的权限是否要管理员设置？那么改的权限呢？删的权限呢？是否可以引用别人的评论？评论被人引用了是否可以再改？如果可以改那么是不是要保留修改记录？如果管理员改了一个评论那么作者是不是不能再改？评论是否要有数量和时间限制？评论要不要翻页？如果要翻页是在本页翻还是打开新页？评论能不能带图片？带了图片那么是不是能上传？能上传之后是不是要删除？是不是要提供自定义评论排序？是不是要xx？是不是xx？xx？比如，一个最简单的“评论”功能：既然可以发评论，那么“少做就是多做少做就是多做”，阿里巴巴的马云也说过。，阿里巴巴的马云也说过。
