需求分析 - UCD大社区

需求管理之需求收集

chuanliang — 2010-04-11 13:44:27

需求收集是进行产品需求管理的第一步。需求收集得到的各种用户需求素材是产品需求的唯一来源。可以说需求收集的质量影响着产品最终的质量。

1、需求收集目的

需求收集的目的在于：通过以市场为导向的客户需求收集，保持公司产品的核心竞争力，最终实现产品创新。具体说来：

1）、深刻理解市场需求、用户需求，准确把控行业发展趋势，保持高度的市场敏感度。

2）、保证产品研发是围绕客户需求来展开，真正实现产品研发“以市场为导向、以客户为中心”，而不是闭门造车。

3）、实现产品创新。通过有创新性的新卖点、新产品的持续不断推出，保证公司产品核心的竞争优势

4）、及时获得竞争对手相关产品及市场策略，做到“知己知彼”

5）、通过需求收集等相关活动，有机串接市场营销部门与产品研发部门，建立跨职能部门、端到端的流程进行需求开发

6）、加强与用户互动，提升用户忠诚度及粘性

2、需求收集指导原则

互联网并不缺少用户需求，恰恰相反，用户需求泛滥。面对市场上众多的“需求”，那些才是真正的用户需求呢，那些需求符合公司的产品战略要求呢？

需求采集的指导原则：

以公司的产品愿景、产品战略为指导

产品愿景及战略决定了：需求采集应该面向那些细分的目标用户群，而非普遍撒网；对不同的用户需求进行优先级排序出现需求冲突时候取舍的标准；确定能实现或者不能实现的需求；

以用户欲望为准绳，给用户带来“价值”而非“功能”

3、需求收集方法

1）、建立需求收集机制：明确每个需求收集活动参与者的岗位职责、建立需求预处理流程、周期性的重复需求收集活动

2）、使用统一的需求收集系统

3）、采取一定的需求收集技术和方法

关于需求收集的方法，如何做好需求收集这篇文章讲解得比较详细，可以参考其内容。

用于需求收集的常见手段包括：

原型法
头脑风暴
用户访谈法
问卷调查法
标杆分析法
观察不期而遇的用户
各种会议（如用户大会、展览会、学术研讨会等）
现场支持
和支持团队（运营团队、技术支持团队）谈话
客户热线
客户满意度调查
用户行为分析
合作开发

一些思考：

1）、需求收集应该收集用户真正面临的问题和业务场景，这样才能够捕获用户真正的需求，而不是只盯住用户提出系统需要实现什么样的功能，“需求收集”不是“需求汇总”。

2）、用户要的是产品的“价值”，而非产品的“功能”。只有当一个产品功能真正帮客户解决问题，这个功能才具有价值，也才真正有“功能”。

3）、需求收集流程要真正发挥作用，必须在组织层面通过组织管理制度及绩效考核制度来保证，将需求收集纳入到各相关部门的绩效考核中。不能指望大家三分钟的热情。

4）、需求收集流程的执行情况是一个公司管理是否规范的试金石，也可以衡量一个公司是否真正“以市场为导向、以客户为中心”。

5）、需求收集既要避免“什么都要做”的冲动，又要避免“只关注当下需求”，核心根源还是在于产品战略是否清晰。

6）、常规的需求收集手段并不能够解决产品创新问题，但如果没有持续的需求积累，创新就无从谈起，创意的灵光源于专业。

7）、尊重竞争对手和用户。竞争对手和用户并不像我们想象的那么愚蠢，以自己的标准来度量别人的产品才是真正的愚蠢。很多时候我们从自己的预设立场出发，否定掉了众多创新机会。对竞争对手，我们应当首先成为其产品忠实用户；对用户，我们应当通过用户社区等互动手段来“倾听用户的心声”。

4、需求收集理论模型

4.1、$APPEALS：收集市场需求的工具

$APPEALS方法是IBM在IPD总结和分析出来的客户需求分析的一种方法。它从8个方面对产品进行客户需求定义和产品定位。

$-产品价格（Price）
A-可获得性（Availability）
P-包装（Packaging）
P-性能（Performance）
E-易用性（Easy to use）
A-保证程度（Assurances）
L-生命周期成本（Life cycle of cost）
S-社会接受程度（Social acceptance）

关于$APPEALS可以参考 $APPEALS市场需求和产品定位工具

4.2、客户满意度模型（Kano模型）

KANO模型定义了三个层次的顾客需求：基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。

基本型需求：顾客认为产品“必须有”的属性或功能。当其特性不充足（不满足顾客需求）时，顾客很不满意；当其特性充足（满足顾客需求）时，无所谓满意不满意，顾客充其量是满意。

期望型需求：耍求提供的产品或服务比较优秀，但并不是“必须”的产品属性或服务行为有些期望型需求连顾客都不太清楚，但是是他们希望得到的。在市场调查中，顾客谈论的通常是期望型需求，期望型需求在产品中实现的越多，顾客就越满意;当没有满意这些需求时，顾客就不满意。

兴奋型需求：要求提供给顾客一些完全出乎意料的产品属性或服务行为，使顾客产生惊喜。当其特性不充足时，并且是无关紧要的特性，则顾客无所谓，当产品提供了这类需求中的服务时，顾客就会对产品非常满意，从而提高顾客的忠诚度。

一旦每个需求都得到了明确的分类，就能够在需求收集过程对需求进行优先次序排序。

关于Kano模型的详情，可以参考kano模型及需求入门－用Kano模型来确定需求优先级

4.3、层次分析法（AHP, Analytic Hierarchy Process)

在做需求收集时候，最为麻烦是确定用户需求的优先级，利用层次分析法（AHP, Analytic Hierarchy Process）可以从不同的方面（如重要性、风险、成本）等角度去比较每两个用户需求之间的优先顺序。

层次分析法将决策总是有关的元素分解成目标、准则、方案等层次，在此基础之上进行定性和定量分析的决策方法。这种方法的特点是在对复杂的决策问题的本质、影响因素及其内在关系等进行深入分析的基础上，利用较少的定量信息使决策的思维过程数学化，从而为多目标、多准则或无结构特性的复杂决策问题提供简便的决策方法。尤其适合于对决策结果难于直接准确计量的场合

在IBM Rational Focal point中提供了层次分析法对需求进行排序。

4.4、四象限定位法

四象限定位法以需求的急需性作为横轴，需求的重要性作为纵轴，可以建立如下的消费者需求四象限图：

具体内容可以参考四象限定位法

当然还是其他的一些方法，例如：Delphi方法、亲和图法（Affinity Diagram）等

5、创新产品的需求收集：你是否有自己的idea bucket？

对于众多颠覆性创新的产品，其核心的创意很多时候与现有产品的需求及要求是相互矛盾的，因此这些创意是不可能完全依赖现有产品的需求收集过程得出来。

当然任何创意也不可能从空而降，这些创新性产品之所以能够脱颖而出，根本原因还是在于这些产品经理们对于所在行业的用户真实需求及痛苦之处有深刻的了解，然后“Think Different”。别的产品经理们在审视收集的各种需求时候把这些创意作为“不靠谱”的需求而过滤掉了，而这些创新产品的产品经理去把这些需求作为一个创新的机会来把握住了。

因此创新产品的需求仍然可以收集，只不过相对于普通产品的需求收集过程，我们在标准上应当更加开放。在需求收集平台中，我们应当单独留出一个创意桶（idea bucket），专门用于收集、汇总各种产品需求、创意、设想等，并定期在公司层面回顾这些创意，以发掘产品创新的机会。

前面的Kano模型也经常用于产品创新领域。

6、常用需求管理软件

除了使用自行开发的软件来实现统一需求收集外，一些常用的需求管理软件也可以用于类似场合：

IBM Rational Focal Point

IBM Rational Requisite Pro

IBM Rational DOORS

Jira

Borland Caliber RM

其中Focal Point用于需求收集是最为合适的工具。

设计师挖掘用户需求浅谈

咏沙 — 2009-10-20 22:39:42

分享人：月漓

作为交互设计师，你是否在一个项目中花费大量的时间来沟通、修改、明确需求？其实这些前期工作（设计原型前）是我们和PD、运营、开发之间必须要做的功课，如果没有，你就会陷入如下窘境：

–莫名其妙的开工，根本不清楚自己接的什么产品；

–或是MRD\PRD一应俱全，却是依葫芦画瓢，只专注于界面的设计；

–或者热情高涨很有见解，却PK的不是那么有理有据。

当然我们的终极目的并不是尽早拿到一份数据翔实的MRD或者缜密完善的PRD，这个产品/项目概念是什么，动机是什么，怎么做比较好等等，才是设计师们前期想要了解的，而且我们希望是越早越好、越多越好.也就是说我们要主动向前站，搞需求。也许有人说产品的需求是PD、运营和用研负责的，产品的架构是架构师搞定的，至于设计师先把自己交互和视觉做好就已经不错了，为什要趟这个水呢？

一、设计师为什么要深入了解用户需求？
我们都很清楚用户研究的价值，但是设计师为什么要自己做用户研究挖掘需求呢？我总结了几点必要性。

1.对于设计师

——做好本职工作的入门课
之前看了篇文章，作者主张先做行业专家，然后才有资本做体验专家。设计师具备了一定UE领域的专业知识，但还需要加上对行业的用户行为、行业规则、行业特点的深度了解，才算具备产品体验设计师的基本条件。总之是说我们要先把自己打造成行业的专家或者至少是资深用户。我是豆瓣的忠实用户，我是Google的热情粉丝，作为淘宝的设计师，贴近用户深入持久地了解这个行业是我们的入门课。即便在用研团队接入的情况下，设计师依然需要关注和参与整个研究的过程。

——使设计师关注大交互
不要先入为主，不要陷入细节。如果只是抱着MRD\PRD依葫芦画瓢，我们就只会专注于交互方式是否优异，控件用的是否正确这样的交互细节。不是说细节不重要，如果产品的功能设定有问题，细节处理的再精妙也只是舍本求末，缘木求鱼，因为那不是用户需要的，他们totally不care。关注用户、关注行业可以在不经意中把我们的注意力转移到产品的大交互上来。

——提升设计师的专业技能
师夷长技以进取。学工业设计的时候，我们有市场调研这一课。在做设计的过程中，前期调研也是一个必经环节。虽然学校时调研往往流于形式，使设计总充满学院味，但可见这项技能重要性。掌握独立研究的方法和流程，可以帮助我们更有效的开展工作。而且方法是通用的，即便不是设计师的角色，学会了很受益。

2.对于项目

——要保证项目顺利执行，交互和视觉设计能够更好的表达产品意图，我们须要对这个产品的前世今生有个了解，不能望（PRD）文生义

——可以帮助PD去验证产品的规划和功能点是否与用户的需求有太大的差异，及时调整我们的产品。

——即便所得研究结果与PD的规划的内容一致，我们所做的依然不是徒劳，可以让团队对将要做的事抱有强烈的认同感和使命感

3.对于产品

——摸清产品的底线，抓住基础需求，改善基础体验，才能降低了用户的门槛。

——有利于项目、产品的可持续发展
淘宝的设计师们大都身兼数条产品线，每天都是多任务处理，需要对自己的产品有很深入的认识，开发亦然。举个例子：物流产品的前端开发工程师一年换了5人，工作量大的话，他们只能按照我的描述去纯写代码，因为没有时间了解业务。不同的PD规划了不同的方向，不同的设计师设计了不同的风格，不同的开发人员写了不同的代码，致使产品不能持续发展，严重影响了用户体验。如果设计师可以持续跟踪用户的需求变化，并形成文档记录，一来方便自己对产品的理解，二来可以降低其他人的学习成本，即便换了设计师也能把产品的原主旨贯彻下去。

4.对于资源

在没有用研团队支援的情况下，通过快捷、便利的方法，独立研究，产生结论。

最后，这件事完全无害，且不具风险^_^。

二、我们要做的是什么？

说的很简单，但对于身在淘宝的我们做起来其实难度很大，时间不允许，流程没保障，再加上自己想的比做的多，如果再没有用研同学刺激的话，基本上就把了解用户当成了一种愿景。
我把自己的项目工作分成4步，其中最难就是第一步——明确需求，所以有意识地实践了一下自主研究用户的方法和流程，仅供参考。

设计与艺术都是富余创造性的，但它们的本质区别在于设计是为了解决问题而创造。设计师的任务是把一个抽象的概念打造成一个具象的、可用的产品。设计师和PD的工作范畴有关交集地带，就是战略层和范围层。针对某些大的项目我们可能只参与全局中的一部分，所以范围层（功能和内容）与我们走的更近的。
用户体验要素——产品开发流程——关注点
表现层 ——视觉设计 ——装扮
框架层 ——信息组织、导航、界面布局——血肉
结构层 ——信息架构 ——骨架
范围层 ——功能组合、内容需求——轮廓
战略层 ——用户需求、商业需求——基因

设计师的研究可以产出那些交付物呢？
1.persona——给谁做
2.用户需求清单——做什么
3.重要性排序——先做什么
4.风险点清单——不做什么
5.产品设计建议——怎么做

三、设计师什么时候独立研究？

——用户研究团队资源有限的时候
用研团队更专业，更高效，而且不要浪费团队资源，设计师更重要是如何运用研究的结果。

——系统性的项目
相对比较有可能争取时间对产品和用户做研究，研究产出给项目开发带来的价值也高，更受益。

——关键性、且使用频度高的页面
淘宝的用户算是最反感改版了，尤其是那些他们每天都要高频使用的页面，哪怕是好的改版也会使用户短期难于适应。所以为了保证这个优化的质量，前期做些功课还是必要的。

四、怎么做？

——心理按摩：
A.主动出击，当作自己应该且乐于做的事。不要觉得我们是在帮别人做事。
怎么做：主动联系项目其他角色，索取已有数据和资料—-向BI和运营要数据，检测日常数据动向；
通过旺旺、帮派等途径，和你的用户保持联系—-建立产品的帮派（淘江湖的论坛）；
主动作用户体验讨论的发起人，带动你的合作伙伴—-用邀请卡提起其他成员的关注度

B.“ta”的立场，避免自以为，客观看待得到的反馈。有文章说用户并不像我们一样关注创新，因为他们使用产品一定是有需要的，优化（前提是真的“优”）可以使他们开心，但为了图新鲜所做的创新就不一定了。
怎么做：多看多听用户是怎么说、怎么做；少说“我觉得怎样怎样”

C.高执行力，贯彻始终，产出结果。
怎么做：三力：制定专项计划的日历；给自己一点压力，定时检查进度；给自己一点奖励。

D.心态平和，不急功近利，做了就比没做好。卖家用户相对于买家用户是更苛刻的，他们的真心更难了解，往往对产品的优化改版并不会像频道改版那样短期内大幅度提升数据，我们更要持续不断的关注这些用户。

E.协同工作，搞研究应该结伴而行，三人行必有我师。好的分享不能忘了各位同学，好的研究课题也不能忘了各位同学，协作是成功的重要元素。

怎么做：想让别人帮助你，要做好充分的准备——给大家留个作业吧，之前比如可以之前给大家分享一下和用户在线访谈的技巧，让大家分别review自己获得的信息，提炼关键词句，做成告示贴，之后白板汇聚信息，每个人描述自己的关键词句，再对告示贴分类

——执行方法：
前提是要设置研究目的，和用研的同学做过一次脑爆，建议抓重点，战线不要太长。

A.收集信息——努力了解那62%的现象
如果允许，最好可以做定量的方法，可以拿到很多可靠的数据，作为论据更充足。
-在用研团队的支持下先行收集问卷，分析数据，整理出报告。
-没条件时，建议在相关产品的页面自行设计问卷（请定量组审核一下问卷哦）或设置入口收集用户反馈。

以定性研究为主。毕竟人单力薄，很难完成定量的工作量。
注意：保留用户的信息

a-用户访谈
数量：8-15人
准备：访谈提纲
方式：现场、一对一网络、电话
交付物：访谈记录
tips：1.访谈提纲长什么样（样例）
2.访谈礼节
3.注意控制谈话范围，用户有时会拿你当客服MM，要有职业底线
4.整理访谈记录
5.给用户打上标签

b-观察法
-测试观察
数量：3-6人（依条件）
准备：相机、录音设备、笔记、观察的要点清单
方式：笔记、工具辅助、清单标注

tips：提前列出关注的要点清单，

-实地调查
本次主要是PD提供的资料
准备：相机、录音设备、笔记、观察的要点清单
交付物：调查报告

c-偷窥法^_^
数量：不定
准备：每天给自己半个小时，去帮派转转
方式：笔记

——收集资料的渠道：
线上：IM访谈在线问卷帮派收集邮件拜访在线焦点小组
线下：面对面访谈电话访谈可用性测试实地调查 “以身试法” 其它项目的资源

B.信息的整理、筛选和分析——为了发现那7%的本质
——整理
-集合所有渠道的信息，整理成附录；
-回顾所有信息，尤其是那些别人收集的；

——筛选
-甄选有效的信息，可以用批注、记笔记、引用原话的方式。
tips：并非只要用户说的我们就要听，哪些信息是有效的呢？
和产品直接相关信息；外围信息-对产品有价值的；与设计师关注或困惑相关的信息；从用户行为或语言推论的信息

-提取关键词、关键句，他们可能隐藏着潜在的需求信息

——分析
-分类
×建议制作成告示贴，找个白板，摆开、贴出来比较直观；
×建立坐标系，设置一个维度，把告示贴贴上去

tips：
用户的角色（因为要做persona）
目的、动机
用户身份——比如同一家店的老板和客服员工关注的层面肯定一同
态度、观点、建议——我们关注的需求
禁忌——我们要规避的需求

-联系、比较、总结
×视觉化思考，图表方式便于我们找到各个点之间的关系
×谁在什么时间在哪里怎样的做什么，把点串联起来
×发现不同用户角色的共同愿景
×比较不同用户角色关于同一事物的差异
×用户需求权重排序

tips：用户需求权重排序的标准？
1.是否具有一定严重性，是否影响基础体验
2.是否具有普遍性
3.结合商业利益对比，需求的性价比如何
4.结合其他用户体验对比（比如一个小功能，却影响了重要页面的加载速度）
5.不盲目的参考、追随

C.结果的展示和运用
描述性结果–用户需求清单（含排序、建议）、风险点清单
差异性结果–persona

tips：关于我们希望规避的需求，不要说“我们不做….”，二是说“为了….，我们可以转而这样做….”

运用方式：
×建立项目/产品的资料库，可做积累沉淀，将文档共享给项目组的成员或想要了解到人；
×主动邀请项目组成员，对他们做一个或连续报告，去推动需求变为现实

tips：记得实时更新新增需求，跟随着产品发展调整这些文档。

相关话题：需求分析源地址：http://ued.taobao.com/blog/2009/10/20/tansuan15-2/

打动用户的需求

heavenhanwei — 2009-10-08 20:23:54

今天在邮箱里面看到虫子给我推荐的周鸿伟产品秘笈

打动用户的产品需求，我非常欣赏这句话，每次讨论网站的方向时，我都会问大家一个问题，用户在完成目标的情况下为什么一定要用你的网站，为什么一定要使用你的服务

周鸿伟有几句话说的很好总结如下
无论你的想法高明或者不高明，都不如用户的选择高明
伤其十指，不如断其一指。在产品方向上一定要先学会做减法，而不是做加法。

假期的时候和liza姐、pizza老大、老马探讨了很多问题，大多纠缠在起点的问题上，什么是打动用户的需求。

在情感化设计中提到目的明确、使用场景、美好的外观,
书中有更加详细的归纳，设计的三种水平：本能的、行为的和反思的

产品是做什么用的，诉求的重点是否突出，就如周鸿伟所说，伤其十指不如断其一指，形象的比喻。印象中最为深刻的一个案例是muji家的卷筒纸，圆形方的处理，使的在拉动卷筒纸受到一定的阻力，不至于失手扯下的是大半卷。产品的存在不是为了标新立异，跟老马探讨问题的时候，我说福特的那句话，当人们没有见到过汽车的时候，只知道需要一匹更快的马。老马说，那是因为没有看到人们本质的需求是速度，福特的成功在于重新思考了如何满足更快速度的需求，正如同Jobs在指导ipod等产品时提出的问题什么是MP3.

无论是马还是汽车，使用起来目的明确，代步工具速度快节省时间，这样的设计水平处在行为水平上，，行为水平的设计需要解决的最重要的问题是功能。
Ipod的创新性体现在重新解读了什么是MP3的问题，读到了用户需要音乐时的本质，经典的反思水平案例。

在设计中的设计中原研哉提到清晰、独创、幽默
原研哉用了简洁的几段话描述了其中的基本原则，这三个基本原则一直贴在我的桌子上，用这三个原则观察自己和其他人的设计。通常我在评价一个设计作品（注：是设计作品不是艺术作品），找到产品的诉求点是什么，这诉求是不是清晰，然后自己会说，恩及格了，清晰让作品及格，至少这是个有价值的产品，在逐步的阅读使用中发现这些元素都是作者经过思考的创作，有意思很不错哎，80分~~，最后一步幽默就是那些产品给你带来不可替代的影响和趣味性，经典总是经得起推敲的。

在designing pleasurable products中提到生理快乐、社交快乐、精神快乐、思想快乐
生理快乐Physio-plaeasure把情感化设计中的描述的本能水平的许多方面和行为水平的一些方面结合了起来。发自本能的设计，也许是泰坦身边的双头犬吧。
社交快乐Socio-pleasure。社交快乐从与其他人的交互中得到。Jordan指出许多产品发挥着重要的社会作用，也许是出于设计也许是偶然。有时社交的快乐是作为使用的一个副产品而得到的。利用这种快乐而迅速成长起来，也就是为什么SNS会大行其道的原因了。
精神快乐Psycho-pleasure 这种快乐包含在人们在使用产品时的反应和心理状态。精神快乐存在于行为水平。
思想快乐Ideo-pleasure 这种快乐存在于对经历的思索。这里，人们欣赏产品的美感、质量或者产品可能改善生活和尊重环境的程度。Jordan指出许多产品的价值来自他们自身功能的外在表现。在一定程度上象征了它们主人的价值判断。毫无疑问，思想的快乐处与反思水平。

打动用户的需求，必然有以用户为中心的设计思想，需求的实现是个复杂的过程，只有一个突然冒出的很好的IDEA，但是却不留给用户一个快乐pleasure的体验，产品的存在便没有了意义。

如何准确把握客户需求

David — 2009-08-13 11:47:12

今天有点空隙，将这几天跟客户沟通的一点感觉结合以前的经验总结一下。

简单归纳一下，客户可分成三类：

第一类：对自己需求模糊的客户

这类的客户已经很少，以前多是广告公司的客户。现在也不时有遇到，多是因为见的是经办人，而不是直接的负责人。所以对需求一知半解。

另外，也有些直接的负责人只知道自己想做调查，但对调查需求的表达只限于：“我有个新产品想了解下消费者的看法。”之类的

当然最好是请直接负责人见面。不行的话，只能：

1、多问背景。了解为什么要做调查，企业处在怎样的阶段？

2、测试想法。将一些常规的相关方法和内容拿出来沟通，可帮助了解客户到底需要的是什么

3、采用标准方法。客户实在没想法，也就说明需要的只是标准操作模式。这样就只能根据以前类似的经验判断客户属于哪一类型的需求，做出方案再沟通了。

第二类：有很多想法的客户

这类客户思维活跃，对自己的需求有很多思考，对如何通过调研去解决自己的需求也有很多的想法。这类客户是很好讨论一起分享想法的客户。但其特征就是想法变化特别快，今天确认好的事情，第二天就可能有变化了。甚至一场会里的想法都会是在不断的变化当中。这样就给调研公司带来很多的困扰，搞得不好，就容易给转迷糊了。

与这类客户沟通的要点：

1、心中一定要明晰调研背景和客户面临的营销问题。万变不离其宗，客户无论思维怎么变化，都会是紧靠这些基础而来；

2、沟通中要抓住客户思维的变化脉络。要抓线，不能抓点。一定不能只抓住客户的某一句话或某一段话。因为这类客户很多时候都是在自我否定之中。

3、要抓实质。客户在说想怎么做的时候，特别在说应该怎样调查或采取怎样的方法的时候，往往只是想通过具体的方法来表达他想要的是什么，这时千万不要只是记住他的方法。

4、要有最后的确认。在会议结束的时候最好是对最后的结论有个总结并确认；

第三类：清晰自己需求，能有效分解课题的客户

这类最好办。不过也有很多研究人员做套路做惯了，遇到这样的客户也根本不听客户讲什么，也还是照套标准做法。

很简单，这类客户沟通的时候关键是要把握重点，也就是他最关心的是什么。

怎样把握？就看他哪些内容是讲得最多的，反复讲的就是了。

相关话题：需求分析源地址：http://www.dmworld.com.cn/blogger/?p=559

需求挖掘及用户研究的利器：MACUEE模型

Felix Ding — 2009-07-14 00:28:17

前言

用户研究到底研究什么？各公司情况不一样，做法自然也不同。比较常见的情况是，很多公司根本不做用户研究，完全凭行业经验和拍脑袋来决定“用户需求”。有一些公司想到了要做用户研究，拿起电话就问：你觉得我们的产品怎么样……哦，挺好的……那就好，于是得出结论：用户喜欢我们的产品。还有一些公司觉得面对面访谈效果好一些，便约好用户，闲聊了几句发现没话说了，好像用户对产品也没什么意见，结果只能结束访谈，最终也没能拿到什么结论。

那么，用户研究到底研究什么呢？这个问题貌似并没有一个大家都认可的答案。我则一直在使用一个我称之为MACUEE模型的方法来做用户研究。

MACUEE的原型来源于Idean的培训课程，我看到其中一页幻灯片后，觉得它刚好可以适用到用户研究上，经过在项目中不断地摸索和揣摩，最终将其发展成了现在的MACUEE模型。

MACUEE解决什么问题

这一模型主要解决以下一些问题：

如何有效地挖掘用户需求？
从哪些方面着手进行用户研究？
从哪些角度去访谈？

MACUEE详解

完整的MACUEE模型可以用下面的图来表示：

由上图可见，MACUEE分别代表“动机（Motivation）”、“操作（Action）”、“情境（Context）”、“用户（User）”、“经验（Experience）”和“期望（Expectation）”。解释如下：

用户

我把“用户”放在最前面了，因为你得首先搞清楚你的用户是谁。这个要是弄错了，后面的方法和流程再对，结果也是错的。简单地说，找什么样的用户取决于你产品的目标用户。比如你想开一家麦当劳那样的快餐连锁店，你的客户群就可以是已有的麦当劳消费者。

但这个问题远没那么简单，实际上我觉得这是整个环节中最难的。就拿上面的例子来说，什么叫“麦当劳消费者”？我这辈子第一次到麦当劳买东西，你说我算不算消费者？每天都到麦当劳吃早饭，你说我算不算？或者我只是喜欢那里自由的环境，却从不在那里吃东西，这样算不算？说白了，就是符合什么样条件的人，才是你的用户？

这个问题绝不是三言两语可以说得清的。总之，找到你的用户，了解他们都是一群什么样的人，他们自身的特质，将会影响到其行为方式。因此你对他们了解越多越好，最好是无所不知，无所不晓，呵呵。

动机

我一般把用户需求分为两个层面：动机层面的需求和操作层面的需求。这里先说动机。

所谓的动机，就是要做某事的原因。比如我肚子饿了，想吃东西；或者朋友给我发了一封邮件，我需要去看一下。动机回答的是用户为什么要用你的产品的问题。这很关键，可以说是用户使用某产品的最原始的需求，研究过程中必须得找出动机来。有了动机，你可以知道该做什么产品，此产品应具有哪些功能。

情境

情境就是用户所处的时间和环境等外部因素，这也是需要搞明白的地方，因为情境会影响用户的动机、操作和期望。比如说“肚子饿了，想吃东西”是动机，那么当我看到街上有个面包店时，我的动机会变为“肚子饿了，想吃面包”。

情境有时候可以对产品设计产生非常大的影响。比如我同事在非洲做过一个地下矿井挖掘机的项目，工人在深入地下一公里的位置操作机器，环境非常恶劣，高热、潮湿、尘土飞扬，现有的挖掘机操作面板上常常覆盖了一层尘土，很难看得清楚；而长时间在潮湿高热的环境里工作又会使人多少有些神志不清，此时情境无疑会对工作有着至关重要的影响。

操作

当用户有了动机后，他会考虑如何操作以便实现动机，这就是操作层面的需求。比如当我来到面包店后，我应该拿起一个托盘自助挑选呢，还是请服务员帮忙？我付款时要用现金还是刷卡？这些都是具体的操作层面的需求。操作层面的需求对交互设计帮助最大，充分了解操作层面的需求，可以让设计师设计出与需求相一致的界面。

经验

用户过去的经验也会产生影响。这个很好理解，我就不举例了。但要注意的是，在调查用户过去的经验时，不妨也使用MACUEE模型，即从这六个方面去了解他过去的情况。

另外经验也可以被称为“用户习惯”，我们知道习惯是很强大的，尽量不要去改变用户的习惯。有一些新产品就是因为没有充分调研用户经验和习惯而失败。

期望

用户在具体操作前往往会对操作结果有一定的期望。比如上面买面包的例子，在我拿出银行卡付款时，我显然期望这家店可以支持刷卡。Apple的产品能够给人带来惊喜，一个很重要的原因就是它不仅仅是满足期望，而是超越期望。

一个完整的例子

现在我们来看一个完整的例子。

假设我们打算设计生产一款全新的mp3播放器，不妨叫它Zunee（嗯，显然，这又是一款iPod杀手）。这款播放器定位高端，价格不菲，专门卖给有钱有闲的人。

那么第一步我们先来做用户模型（Persona）。不妨假设经过调研，我们发现符合条件的用户都具有如下特点：年龄介于28-35岁，月收入在5万左右，明天早上晨跑，边跑边听激烈的音乐。

第二步我们找出用户动机－为什么在晨跑时要听音乐？经过研究发现边跑边听音乐可以减少运动时的孤独感，听激烈的音乐运动起来更带劲儿。

第三步看看使用情境。研究发现用户在跑步时往往身穿体恤短裤，播放器放在哪里成了问题；此外由于用户此时需要听些激烈的音乐，而目前的播放器里面什么音乐都有，因此每次跑步前不得不设置好播放列表，很麻烦。

好了，问题出来了。记住，用户往往是在特定的情境里面产生问题，所以如果访谈时你上来就问：你觉得你现在的播放器使用起来有什么问题。用户多半回答不上来。

第四步挖掘操作层面的需求。由前文可知，用户在操作上需要1）以合理的方式携带播放器；2）以最便捷的方式播放激烈的音乐。

第五步则是以往的经验。研究发现，用户觉得用袜套把播放器固定在胳膊上觉得很热，此外，他很喜欢以前用过的一个播放器，这个播放器可以利用内建的运动感应器来自动选择合适的音乐。

瞧，随着研究的深入，用户甚至自己提出了解决方案！这就是为什么要调查以往经验的原因之一。

最后一步就是获取用户期望。研究得知此类用户希望播放器能够更加便携、能够适应不同的天气情况（比如下小雨）、能够自动化地播放合适的音乐等等。

经过对上述这六个方面的研究，用户及其需求已经比较清楚了，接下来就可以进入产品设计的工作了。

一些注意事项

看完了介绍先别急着尝试，下面的注意事项也很重要：

要以用户为基础进行调研。对什么样的人用什么样的方法、问什么样的问题。比如我们前段时间作了一个关于油漆软件的项目，大部分用户都没有受过良好教育，抽象的、概括的问题人家根本听不懂或答不上来。
要以情境为基础进行调研。无论是调查动机也好经验也罢，一定要以一个个情境为中心来推进话题，在每一个情境中分别挖掘动机、操作、经验和期望。最好是陪用户一起体验情境，在用户使用产品的过程中进行访谈。
在调查期望时小心不要被用户带到沟里。调查期望不是让用户畅想这产品能具有什么功能，而是为了满足现有需求应该具有什么功能。我记得有一次做对讲机的项目，当时在场的用户挺多，客户代表也在，场面不太好控制，用户居然说要在对讲机上集成WiFi和3G……我后来和同事打趣说，当时要是再不收住，一会儿要上4G LTE了，呵呵。

差不多就这么多吧，有问题欢迎讨论。

相关话题：需求分析源地址：http://dingyu.me/blog/posts/view/macuee-model

分离需求与GUI设计 - 保持项目节奏实践之七

小熊 — 2009-06-18 00:14:18

我们希望系统解决的问题通过需求得以体现。GUI设计是要体现出GUI如何引导用户使用系统以解决他们的问题。很多项目都将GUI设计混同于需求的假面之下，这很让人讶异。如果你的项目总是陷于无尽的需求工作之中，看看问题是不是出在GUI设计上。

GUI是设计，不是需求

凯伦，程序经理

我在一家新公司工作时，试图拯救一个陷入“需求地狱”的项目。需求文档已经达到300多页，而且远未完成。

阅读这些文档后，我找到了原因。所有的GUI设计都被记录在需求文档中。GUI设计没有放在项目的设计阶段，业务分析人员和GUI设计人员试图将所有的GUI需求都放在需求文档中。他们使用了功能强大的图形设计工具，并在需求文档中定义GUI。

我向他们询问原因，他们看着我，说道：“这些是GUI需求。”我建议他们认真看看GUI设计，并且考虑这些设计是否应该跟希望系统解决的问题放在一起。GUI设计不应放在需求文档中。

最终，他们同意采纳我的建议，我们也可以逃离需求地狱了。而且，由于我按照逐个功能重新组织了项目，GUI设计也就跟各个功能结合在一起了。我们定期检查整个GUI的一致性，但是这与需求无关，这属于设计。

人们很容易在项目开始阶段设计GUI，并称其为需求。如果要这么做，项目就永远无法找到自己的节奏。它会一直陷于需求的泥沼之中，直到最后，无法完成任何客户需要的功能，虽然到时候能够得到精美无比的GUI。

相关话题：需求分析源地址：http://bearwhisper.blogbus.com/logs/41051564.html

需求何来?

axuan — 2009-06-16 23:25:55

两年之后的10天前，Gofeeling在餐桌上偶然又问起我如何发现和发掘新需求，锻造新产品。对比之前在Yupoo的时候，自己的回答完全是两种答案。我觉得很有意思，在这里记录一下。纯属设计师个人想法，不代表任何人观点。

先介绍一下自己亲身经历的两种截然不同的服务背景：

Yupoo: 当年领先的中文影像分享服务，超过2百万用户，致力于成就伟大的影像分享社区。

Taobao: 亚洲最大的c2c电子商务平台，超过1亿1千万用户，致力于成就全球最大的零售商。

1，我经历的Yupoo如何产出需求？

初看这个问题，仿佛有很多很多答案。如果头脑风暴一次，我们可以想象很多答案，冲印、相册加密、Flash展示..等等。不管怎样，还是要承认当时的Yupoo是Flickr的模仿者。回答问题之前我们有必要先来看上面这张图示－两年前美国在线照片市场形势。Photobucket以超过40%的市场占据绝对优势，Flickr仅以4.5%的市场占据一小块蛋糕。但是，这却毫不影响Flickr在Alexa排名长年累月打着Photobucket耳光，毫不影响它成为互联网领域已探明的清晰盈利模式，毫不影响它成为“静观世界变化”的伟大服务。单单从这些数字表现就可以看得出来它要做的事情早已超越存储之外。

我们可以越清晰的看到，Flickr的目标是希望以照片为媒介，通过社交体系达到人与人分享、交流的目标。这就意味着，这套产品需要不停的Follow这批目标用户群，而放弃另外“大多数”的用户，产品的需求从开始就注定：不断调整算法，让那些真正优秀的照片和用户能通过一定体系浮现；不断优化4维社交基础，强调个体的真诚付出与相应的参与回报；不断对页面进行精雕细琢，逐个消除产品的破窗…这些需求看似简单乏味，却要紧紧Follow目标用户步步为营，Web 2.0的服务的产品气质和市场环境很可能因为需求某一环节判断失误而贻误最好时机，而使伟大构想逐渐偏离走样。

2，我经历的Taobao如何产出需求？

· 从竞争对手手里

大家明白Taobao是参照eBay为基础搭建的中文C2C交易平台，加入了本地化的优化和改造。时至今日，仍然承认eBay、Amazon是非常优秀的产品，是持续研究的对象。例如增值服务一项，有上百家公司为eBay的产业链提供着各种各样的服务，通过研究了解到在这个产业链中存在图片存储、客观关系营销、货物仓储、分销供应、数据管理、多媒体展示、商品管理、增值物流等等几十个方面，这些服务商乐此不彼的持续提供付费服务，促进了eBay完整的零售产业链。然后拿回来逐个衡量，去论证在中国市场的可行性和可能性，再通过一系列的策略讨论，最后按重要成都形成产品需求。从竞争对手手里分析需求成为非常重要的需求发现发掘方式。这个过程中需要对竞争对手的业务模式、市场和用户成长周期有精准的把握，否则很可能弄巧成拙。

· 从线下零售业方式

作为一家零售公司，对传统零售市场的分析和学习似乎从没停止过。例如，我们经常在超市中被派发洗发水试用装等产品小样。但企业主也为此遇到了一些麻烦，他不知道派发员有没有私自截留赠品；他不知道派发的这些人对赠品是否真的需要；他不知道客户会不会拿回去用；他更无法测算有多少人是因为试用了赠品而购买的产品…这些头疼的问题让这个体验营销的过程成本不断增加。好吧，如果这一切发生在有着丰富用户资源的互联网站上，上面的问题似乎都迎刃而解了。通过对数据库中的用户档案和浏览、购买数据来分析他是不是产品的目标用户，然后相应给用户投递相应主题，告诉他只要选择几个按钮就可以马上收到一份适合自己的快递试用装。当然，系统还会记录这位用户在一段时间内有没有在网上购买这个产品，形成精确的用户激活率。从线下零售方式提取新需求和产品也是另一个重要方面。当然，它也面临很大的挑战，就是如何根据市场反应来让这些方式更加持续可复制。

· 从用户反馈及调研结果

对现有用户的反馈及调研成为发现用户需求的非常重要来源，是产品保持鲜活的源动力。有几次跟随用户研究的同学到用户家里，是一个网店卖家。他就抱怨，因为生意庞大需要把帐号给n个下属来使用，分别负责不同的方向来打理网店。但是遇到问题是，经常会出现一些严重性失误，比如误删商品、误点退款等等，因为互相职责不同不熟悉而任务交叉误操作，造成很大损失。后来又通过一次大面积的定量调研后发现这个用户权限管理需求的普遍性。

到这里可以看出，这两个截然不同类型的服务对于新需求的发现、发掘形式也各不相同。

但是，我们又能看出一些共性：

· 明白自己是谁，要到哪里去

· 关注你的用户，他们的生活、他们的工作和他们的梦想

· 对现有产品的Beta与新产品同样重要

· 紧盯你的竞争对手，理解它优秀何来

相关话题：需求分析源地址：http://www.a-xuan.cn/?p=239

从需求到产品转化中的理性与感性？

huihuilo — 2009-05-17 00:44:05

从需求到产品的转化过程中主要有两大阶段的工作：需求的调查分析和产品的规划设计。在每一阶段的过程中都有关于理性与感性的诸多争论，那么我们该如何看待它们呢？

下面是个人的一些认识与大家分享。

一说到需求调查无非能做的就是查看行业报告、设计调查问卷、对比数据统计、约见特征用户等。我们本能的希望通过理性的客观存在让调查报告越详细越好。这些调查当中既有关于项目背景、市场规模、投资环境、竞争关系的项目调查，也有关于受众的年龄、地区、职业、喜好、心理、期待等用户特征调查。

遗憾的是我们作为非专业调查机构也有诸多因素影响着我们的调查结论：

1) 搜到的免费行业报告多有空、泛、夸大数据结论之嫌；
2) 使用调查问卷对如何设计一套无心理暗示与情景假定的问卷题目又感到头痛不已；
3) 对比数据统计则需要一个长时间的原始数据积累，且数据的变化与当时发生的事情密切相关。如何解读对比的结果也是观点不一； 4) 约见特征用户有时间愿意谈的不多，且行程安排费事；
5) 项目启动时间不等人，老板一直希望你短、平、快。

由此可见，期待能够全面客观的得到需求调查分析报告在大多数公司中都只是一种假设。这一阶段如果过分强调了全面和细节中的理性，那么一是该为你的项目时间捏把汗，二是该为日后你规划产品时，为左右兼顾使产品变复杂而担心。

当然了需求调查是必须的，个人认为凡事抓主要矛盾就具备了成功要素的一半，在调查分析中主要有以下几个要素需要抓住：
1) 要进入的行业市场规模和前景大概多大；
2) 当前的行业发展水平如何，主要的竞争点或关注点在哪些方面；
3) 资本对这个行业的关注及投资环境如何；
4) 行业服务受众的主要用户特征及主要的供需矛盾是什么。
5) 是在主要竞争点上通过高质来竞争，还是通过细分挖掘市场空白切入；

在抓住主要要素的前提下，有目的地进行某方面的问卷调查就更具指导意义；关注数据统计中的热门关键字同样有价值；用户座谈则更多的用在需求验证时更有成效。自然通过这几种手段也就基本达到了需求调查分析的目的。在需求调查基本完成后进入向产品转化阶段。

近年有关用户体验及UCD（以用户为中心）的设计思想得到了更多的重视。UCD思想对于提高设计人员的意识很有帮助，不过我们也要清醒的认识到产品设计只是项目模式中的其中一个环节，同样我们不会得到无限的资源去做到设计过程的完美。在项目中任何有关UCD的调研、取舍、验证都是建立在遵从了项目所倡导的商业价值与模式之上。UCD也许能帮你解决一些用户使用过程满足度的问题，但却解决不了你项目生存成败的问题。UCD的设计思想是一种意识，而非过程中帮助我们执行的方法。

在拿到需求帮助客户向产品转化方面，我趋于主张“我是什么，我就是什么，我强调我就是什么”的设计理念，强调在产品特色和专注深度上提升产品的价值。因为在一个行业中人们也许仅仅能记住前三名，如果产品不能更接近于去实现项目所倡导的价值，即使优良的设计也只能躺在实验室当中。当然了这种理念的前提是设计师首先要具备一定较高的设计水准，能够做到思想、风格一致，并符合自己制定的设计规范。所以如果你是一个项目经理的话，与其过多的在非专业角度上去质疑设计师的作品，不如更直接的去向设计师阐述你所倡导的价值究竟所在何处。设计师就是需要提炼与放大这种价值，结合市场部营销与品牌推广使这种价值得以被更多的人了解。产品提炼与放大的过程要暂时去掉一些对服务全面的要求。“我是什么，我就是什么，我强调我就是什么”的设计理念就是为了把特色突出，让人们对你的认识更趋于一致。有关从需求到产品转化中的理性与感性，对于产品设计师来说是探讨不尽的话题，抓住主要矛盾依然是解决问题的不二法宝。说一点题外话，认识到主要矛盾不是难事，关键是贯穿项目过程当中面对纷繁的具体事务时，依然能时刻记得的主要矛盾，那样很多问题都将迎刃而解。

很多人在过程中都做不到，你呢？

简单实用的需求流程

iamsujie — 2009-04-29 16:58:16

接着上一回说网店版的日常小需求的发布流程，本篇是一个日常需求的提出到发布的流水账，后面有图有真相，对于小公司应该比较实用。大到功能模块级的需求自然是要起一个项目的，不再讨论之列，但原理上也是相通的。

需求人员是产品变动的发起方，所以前期的需求相关会议会比较多，我觉得可以用三个会议来概括。这里不要理解成严格的会议室里几个人正襟危坐，更多的是两三个人围在电脑前谈几分钟就搞定。

（iamsujie补，可以结合“1010：需求管理”那篇来读。）

第一， 需求pk会。一直觉得pk这个词用的很传神，每个PD带着自己的需求来讨论，争夺那仅有的开发和测试资源，人性的本能让每个人都极力的维护自己提出的需求，设法反驳别人的，当然出发点都是为了客户，最终会达成一致，哪些进入“需求中”，哪些“拒绝”，哪些“暂缓”。

第二， 需求评审会。“需求中”的需求，PD觉得需求分析差不多了，就会召集一个评审会，大家会一起讨论下这么做有哪些问题，PD收集到意见以后去修改需求，这是一个视需求复杂度可能反复多次的环节，当大方向都没问题时，评审通过。

第三， 需求确认会。在进入实施前，最后要有个需求确认（这个通常也可能和最后一次需求评审会合并），具体负责开发、测试的同学都要参加，大家一起保证对需求的理解是一样的，没问题后，就开始做吧！

接下来进入开发和测试阶段，PD需要不断的和开发、测试确认各种细节，一直想在之前的步骤中尽量减少这种费时费力的确认（也许真的已经减少了不少），但事实证明细节总是多到无法预计，甚至有的会要上线后才发现。

（iamsujie补：这其实是符合敏捷思想的，小步快跑，不要需求过度，利用开发和测试过程完善需求，特别是对市场环境、用户情况等等变化超级的互联网产品。）

最后一步，当功能上到测试环境之后，负责的PD需要去确认一下与自己设计是否相符，或者说是做一下验收测试 & 代表用户做一下可用性测试，没问题的话，就ok发布，结束一个小需求。

当然功能上线后会有升级的可能，或是客户反馈或是自己发现问题，但我们把这视为一个新的需求，重新进入流程，或者当作一个bug。

相关话题：需求分析源地址：http://iamsujie.com/3000/3006/

excel需求管理实战：状态跟踪

iamsujie — 2009-04-22 14:32:34

我们已经做了需求采集，需求分析，现在似乎应该甩开膀子干活了，但经验告诉我们不是这样的，一个实际的例子：

网店版二期上线后两个月，各方各面提出过的需求也许有四五百个，经过PD们的初步判断，记下来供团队讨论的有200多个，决定暂缓的有60多个，七月一个月发布掉了70多个。其中每个需求的去留，去的怎么去，留的怎么跟进，是一定需要管理的，这时候我们要考虑的，是在评估出“性价比”的情况下，到底什么时候来做，谁来做。

其实在功能列表上做一些简单的扩充，就可以得到一个简单的需求管理工具了。

首先，功能列表是静态的，现在要变成动态的，对每个功能（视为一个需求）加上跟踪状态的属性，让我们能实时看到“何时做，谁来做，状态如何”。

负责人：细分为需求提出者（很可能是用户，有必要备注一下最原始的需求）、需求负责人、开发负责人、测试负责人，属于哪个项目……

需求状态：通常有“待讨论”、“拒绝”、“暂缓”、“需求中”、“开发中”、“已完成”几个状态，可以按照实际情况有所增减。

时间信息：提出时间、录入时间、发布时间……

有了如上信息，然后我们就可以制定每个需求的状态变迁的流程，举个例子， “待讨论”状态的需求应该多久讨论一次；讨论完了就应该转为三个状态：“拒绝”、“暂缓”、“需求中”；而“暂缓”的又应该再多久以后激活，等等。

此外，各种状态的需求个数，也可以通过excel的基本统计功能的实时监控。

做完这些，基本就可以得到文中的图了。

至于更专业的需求管理方法和工具，也看了一些书和软件（比如IBM的Rational RequisitePro），确实是相当的有学问，不过还是觉得暂时不合适游击队，而对于正规军是绝对必要的。

最后说一下我对管理的理解，管理并不是部门经理们才需要掌握的技能，而是每个人都必备的，只是每个人可以使用的资源不同，所以需要管理的资源也不同。当资源充分的时候，我们会觉得“正确的做事很重要”，事实也确实如此，比如被分派了某个重要任务的时候，我们的目标就是做好这件事。而一旦资源出现了瓶颈，“做正确的事”就立刻变得更重要了。比如同时有3个人要请你吃饭（当然这种好事比较难得），资源（你的时间）不够了，你就需要迅速判断吃谁的请更有价值，谁的请可以搁置住但不会丢掉……

每个人需要管理的，必定有自己的时间，也许还有自己的抽屉、硬盘空间、钱等等。经理们需要管理的通常有人员、经费等等。一个共同的特点，这些资源总是处于不足的状态！管理做的事情就是合理分配不足的资源让结果最优。

相关话题：需求分析源地址：http://iamsujie.com/1000/1010/

项目如何开始：怎样和客户一起搞定需求

西乔 — 2009-04-19 20:01:24

项目刚刚开始的时期，项目经理做的主要事情是搜集客户需求，这是一个项目经理非常头疼的阶段，合作的磨合刚刚开始，需求问题上的失误又会导致无穷的后患。

三种客户类型：

1 的确很专业。能提供基本可用的文档，能给出要求规范，能向你提出有价值疑问和担心。能快速回答你的问题。

2 以为自己很专业。 给的文档基本没法用。没法提供规范和标准，喜欢指指点点和挑毛病。只会向你提傻逼问题。基本回答不了你的问题。

3 啥都不懂。 不给文档。能给你几个参考范例（打开数个网站，告诉你我要做成和它们一样的。）只能等着你来问100个问题。。。

四种合作方式：

1 创始人直接和你接洽：
交流结果的协商余地很大，需求不易反复，细节不会被过分追究。更容易统一想法，执行力高，你能对项目和产品产生更大的影响。但往往甲方会过于急进。

2 项目代表和你接洽：
这是非常理想的状况了。甲方有一个产品经理或IT经理能作为代表，负责汇总甲方的所有需求和标准和你沟通，他有过与外包方合作的经验，知道危险的环节所在，能承担翻译和桥梁的角色，帮助你阻挡和说服不恰当的需求。能集中地承担责任，也会积极地和你一起规避项目失败的风险。非常lucky！

3 专业部门和你接洽：
IT部门或技术部门的某个高级别工程师负责和你沟通，你们会比较有共同语言，甚至惺惺相惜。技术方面的合作会很顺利，但是涉及到产品和需求，他们无法帮你挡住来自市场或内容部门的麻烦。合作开始后，很有可能在技术思路上产生分歧；如果在程序部分耽误了太多时间，而产品端被忽视，你有可能受到其它部门及上层的质疑。

4 市场部门（内容部门）和你接洽：
最好你先去烧烧香，准备好最坏打算。专业和思考模式的差异会导致你们关心的问题完全不一样。你首要满足了他们关心的地方后，切记留出不少时间来解决那些他们看不见但实际上非常重要的问题。另外你需要做更多的事，写更多的文档，主动和专业部门联系，力争和决策层有沟通。

如果你面临了第3和第4种状况，

请先熟悉一下甲方的组织机构。例如一般 内容型、媒体、渠道、宣传类项目的开发：

需求和市场部门沟通
功能和内容部门沟通
软硬广告位或专题等和销售部门沟通（如果是改版类，广告位合同可能提前半年签订，一定要和销售协调好）
技术、系统、安全、统计问题等和IT、网管、数据统计部门沟通
某些问题需要和总裁助理、行政等官僚部门沟通。
部分特别的内容需要和创意、美工、文案部门沟通

当以后确定需求的时候，如果发现这些部门的人没有参与，请提前与之沟通。

第1和第2种状况可跳过上述步骤。

八步流程:

第一步：听听客户想要什么。

以及预计工期和预算（这两件事上一点都不要腼腆，这是关系项目成本最重要的元素）。

第二步：提问。

1 项目的目的是什么。（品牌、渠道、流量、广告费、用户数、VC、其它商业模式）

2 甲方的优势和资源是什么。(钱，内容资源，人力大战，传统行业优势)

3 尽量提供可视的参照及借鉴对象。（应用上有没有可解决的。界面上比较喜欢哪个站点的设计。交互上有没有可参考的对象）

4 其它工程的细节问题。
比如（工期上的上下限是什么？
是否会需要与现有系统整合、是否需要数据迁移？是否会需要甲方的工程师合作？
是否有开发平台的限制？
是否有代码规范及标准？最终需要哪些开发文档和源码）

第三步：取得共识。

与甲方取得共识非常重要，保证你所理解的那他们所理解是同一个东西。这一步需要你根据掌握的情况列出提纲，画出草图或框架图。有参考对象的，标注上，哪个部分会比较像某某。

然后请甲方确认，这个框架是他们想要的。

第四步：给出工程时间轴。

到了这一环节，就需要你的项目经理组织所有团队成员坐下来讨论，先划分功能模块，然后讨论每个功能模块的可行性、难度、花费时间、bug发生率、测试耗时。再讨论一头一尾系统搭建和系统整合的所需时间。

项目经理对工程耗时和可行性完全心里有数后，画出工程的时间轴。包括并行状况，里程碑节点、测试期、缓冲期等（如何画工程时间轴，甘特图，我以后会专门写一篇）。时间轴要实事求是，并且预留好充分的缓冲期（工程师估时*2*110%）。

第五步：需求做减法。

大部分情况下，时间轴表现的状况都会超出客户的预期。如果客户对工期没有要求，也要提醒客户考虑项目可行性风险、市场等候成本、市场或战略变化导致的浪费。

韩磊有一篇《大褂还是内裤》的blog很形象地描述过这个问题。

所以要和甲方一起尽量对需求做减法。把整体需求拆成2~3期，落实只开发最基础和最必要的一期需求。

这时签订正式开发协议。
不要忘了计算需求文档和产品方案的费用。

第六步：撰写详细的需求文档。
《框架图》下载西乔的模版。可视化表现产品的框架、布局、细节、部分交互。
《流程图》》下载西乔的模版。理出产品的逻辑关系。
《功能需求文档》》下载西乔的模版。罗列功能、应用、交互上细节，分离基础件，作为开发分工和系统及数据构造的基础文档。

第七步：商讨需求文档

尽量召集甲方所有相关部门的负责人一起召开这次会议，商讨需求文档。

在阅读到你的需求文档之前，可能甲方的大部分人都对产品没有可视和具象的理解。也从未关注到细节和逻辑关系。所以需要产品经理从全局角度和逻辑线索讲解文档。

更可能发生的状况是，没有人坚持看完或仔细看过你写的文档。

所以这次会议是一场耐心和体力的考研。

文档作者需要分别向各个部门指出他们需要关注和拍板的地方，听取他们的建议，将任何变动要求都分类记录。

安抚情绪。解答困惑。控制需求变动。

第八步：定稿需求文档

分职能（部门）类建立表格文档。将会议协商中所有分歧性意见和变动意见都逐条写下。抄送所有相关负责人。并要求他们纠正分歧和确认变动。

所有会议中可能被提出但是未出现在此邮件文档中的意见，不会列入需求文档中。当然允许可以书面反馈补充。

根据确认过的反馈回复，修改需求文档。直到需求文档定稿。

协商讨论和文档修改可能经过2~3轮。所以需要项目经理提前提醒客户注意，搜集需求和文档定稿的时间线里程碑。如果这个阶段耗时过久，会严重延误整个项目进度。要求客户尽量集中地谨慎地提出建议和修改。

三种武器：

需求问卷：无论是面对专业还是不专业的客户，交流中都有很多没考虑到的遗漏点，这些他们看不到的点往往是最关键的点，也有可能是被客户故意规避掉的点。

此时撰写一份需求问卷非常有效。

问卷里提出重要的全局性的问题，需要客户逐条书面回答。

某些问题可以提供多个选项答案，及补充区域。
某些问题需要确凿的态度，Yes或NO。
不要提出需要客户写一大段表述性文字的问题。

需求问卷精简扼要，有针对性，重要，不要浪费客户的时间，不要把写字的工作量丢给客户。

书面确认：
书面确认一方面包括：所有讨论结果、建议和变更都要有书面文字备查。电话和开会上说说的这些口头表达都没有效应。这一点一开始你就要声明，甚至有必要写在合同里。

另一方面包括：你要尽量提供书面的可视化的东西来让甲方确认。
甲方很难完备或是提供适合工程使用的文档。所以千万不要在项目初期的需求文档上省懒。

邮件抄送：
邮件抄送一种明确职责的方法。对方可能不看你的邮件，但代表你告之过。
尽可能地抄送重要邮件给战略层，可以能避免一些重大问题的出现。

结语：

到此看起来，搜集和确定需求真是一件耗时耗力的工程。

其实在理想的工程项目时间分配中，1/3的时间用于确定所有需求和开发文档。 1/2的时间用于测试，解决bug，安全测试、压力测试等。真正用于开发的只应该占1/6。

当然web项目的开发肯定达不到这个理想状况。但是也由此可见需求阶段的重要性和工作量。这一阶段省一分力或有一分遗漏，到了项目后期可能需要十分力来弥补。

相关话题：需求分析项目管理源地址：http://blog.xiqiao.info/2009/04/17/277

需求，还是需求！

Ray — 2009-03-26 22:55:56

回想起2006年入行不久的时候，贪婪的去看Techweb和donews上那些“牛人”的博客，看他们对于SNS对于社会化商务对于互联网的产品从社会学人口学经济学管理学数学逻辑学统计学历史学营销学各个方面种种分析，每次看完都晕了半天没明白到底在说什么，只好心想，哎，写出来给你看你都看不懂，这种高度实在是高不可攀啊。

后来我看到Techweb上有位仁兄说了一句我以为很经典的话：凡是说的好的人，都做不好；凡是做的好的人，都说不好。一篇日志写完发出来，不光是读者看完不知道说什么，也许自己就不知道自己在说什么，那就不好说了。Keso也喜欢博，但是他博的俺看得懂，所以一直在订阅。

回想起这段经历，我就发誓自己在写日志时绝对不扯的天花乱坠最终却不知所云，

我这种资历的人是不敢妄谈商业模式和市场战略的，但是我觉得，越是成功的商业模式越是可以用一句话说出来。越是成功的站点越是抓住了用户的需求，一个最关键的需求，而不是，全部！

我想，在中国[国内国外国情相差太大]，大多数情况下[不说所有的是避免有人钻牛角尖]，我们在做每一个以盈利为目的的产品[站点]前，都应该问自己三个问题：

1.用户为什么要使用我的产品？

2.为什么是我的产品？

3.为什么用户[第三方]愿意为此付费？

第一个问题，用户为什么要使用我的产品？我的产品能够给他带来什么？一句话：解决他最根本最主要的需求，而不是全部的，亦歌解决我听歌的需求，picasa[Flickr]解决我存储照片的需求，网易解决我看新闻的需求，Blogger解决我写博客的需求。虽然网易也提供写博客，但是对于网易来说，那不是我的主要需求，我去网易就是看新闻。
看到这里一定会有人说：难道这个主要的需求是天生的？难道不可以转移，当然可以，这就是第二个问题：为什么是我的产品？

为什么去网易看新闻而不去新浪搜狐？因为我喜爱看网易的评论，为什么去亦歌听歌不去yobo和虾米，因为我喜欢亦歌的UI。为什么我放弃了用了两年多的谷歌拼音改用QQ输入法，因为谷歌拼音经常在新版live messenger下无法输入汉字。为什么是我的产品？因为我有特点，我在某一方面完全超越了对手并把他们甩在身后。

第一个问题是解决把用户带进来，第二个问题是解决把用户留下来，好产品吸引用户并能通过对用户需求分析来不断自我完善，从而让用户留下来，没有需求分析，第一个问题解决再好，后来者很快可以干掉你[咱啥都不会，咱就会抄]。

第三个，为什么愿意付费？上高中时老师说过一句话到现在我还记得：行为日久成习惯，习惯日久成性格，性格日久定乾坤。用户对产品产生依赖性，并认为这个产品能够满足了自己的需求，他是愿意付费的，换句话说，抓住他核心需求的那个点，不停地“挠”，让他自己心痒痒，欲罢不能。在这点上，最成功的例子就是网游，我一个前同事几天前发给我两张图片，我不知道是PS还是真的，但是如果是真的足可以说明这个问题了。

扯了半天，就为了说明一个问题：需求不是在会议室里面几个人哼哼哈哈想出来的，需求是从用户那儿提炼的，记得马云有次演讲中提过：把做的东西给那些做生意的人看看，问他们：“这个东西你愿意用吗？你会付钱吗？”

互联网在国内发展到现在，成功的有几家？失败的有多少？拿了一笔一笔投资烧光死掉的又有多少？
他们，都问过自己这三个问题了吗？

网站为谁服务背后的逻辑

trier — 2009-03-23 05:37:32

定位！定位！定位！有多么重要无需赘言。它是一个网站的魂，也是一个网站为什么要存在的理由，只有具备了这个明确的理由，你才可能存在下去，没有可能无理由的存在！

定位，首先要解决的一个问题就是，面向的群体。这有两个答案 1、一个清晰特定的群体；2、所有网民

第一种，必须回答满足了哪一个清晰特定群体的哪一个具体现实的需求。但凡发展相对比较好的网站似乎在回答这个问题方面都做的比较好。比如，开心：通过玩web游戏，满足了办公室白领打发大把空闲时间的需求；校内：早期满足了在校大学生和陌生男女生交往的需求。例子可以举出很多，大家可以顺着这个思路思考一下是不是这样。对于那些现在开始多元化发展的网站，不要被它现在的产品战略迷惑了眼睛，想想它的发展早期，想想它是怎么起家的，它能发展到今天一定是在起家的早期很好的回答了上面那句话。

第二种，服务所有网民。这个定位，目前会被很多人鄙视，因为能做到太难了。如果你要真想这么确立产品战略，那么就想想已经做到这点的大佬们为什么做到了吧。我的理解是它们颠覆了人们既有的生活结构。人们在某一方面既有的生活方式完全变了。比如QQ，颠覆了人与人之间的现实交流，实现了和任何人的虚拟沟通。比如google，人们获取信息的旧有方式被颠覆。比如新浪，获取新闻的方式被颠覆。使用facebook，虽然已经融入国外很多人的生活方式，与朋友的沟通已经被很大程度转移到了这个平台，但目前能够表现非常清晰的仍然是提供给了人们好友沟通的更多的便利，而究竟在哪一个方面可以“颠覆”既有的好友沟通模式或生活，这些方面仍未有清晰的体现。提供多一种选择的便利和颠覆既有结构从而创造出一个全新的价值空间，这是完全不同的两个层次。因此我们可以判断，对于这样一个面向全体网民服务的facebook还有很长的路要走。

对于那些能满足人们哪些需求都还没搞明白的网站，还是别去想服务所有网民了吧，“颠覆”不是每个人都能做到的，找对一个群体，满足一个需求，足矣我们的职业生涯为之奋斗的了！

相关话题：需求分析源地址：http://trier.blogbus.com/logs/36899940.html

需求分析，要先归纳再分析

iamsujie — 2009-03-18 13:59:45

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

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

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

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

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

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

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

伟大的需求分析师。

相关话题：需求分析源地址：http://iamsujie.com/1000/1007/

需求分析中的用户识别与调查

胡海林 — 2009-03-13 01:15:06

如何确定我们的访问对象？如何对确定用户对象进行调查？
需求来自于用户，不论是用什么方法，首先应是找到我们需要访问的对象，然后对对象进行分类，再逐步对对象进行访问。具体访问过程中可以针对不同的访问对象采用不同的方法，根据访问的内容进行确定。本文要讨论的是，如何确定我们的访问对象，以及如何对确定用户对象进行调查。
讨论的前提条件是针对用户的需要进行的系统开发，或针对用户的需要进行的定置，而不是仅仅将我们已经成型的产品推销给用户。
这样就会面临两种情况，一种是我们可能对这个系统有一定的背景，有一定的开发经验，有不少相关的成功案例，但面对的用户实际上却是一个全新的用户，该用户的要求可能是全新，仅管从管理上讲，该系统的管理实质是一致的，但却许多细微的区别，让我们不能照搬以前的需求与设计，这就要求我们重新访问用户；第二种情况是我们根本对所需开发的系统的行业知识一点也不了解，需要从头认识与理解。无论是哪种情况，我们都要按照以下步骤来慢慢的完成我们的用户需求分析工作。
第一步是找出系统的未来推进者。通过与用户开发任务的提出者进行初步确认，由用户任务提出者指出我们所要开发的系统的最直接用户，或者说是系统的职能管理者，该用户也是未来的系统推进者。只有得到该用户的认可，未来的系统的推行，才能得到他的积极支持与推进。
第二步是把握系统的整体流程。通过对系统的推进者的访问，我们将能知道他的前面用户将向他提供什么信息，并完成哪些处理，信息到了他这里之后，他要做哪些处理，还要提交给另外哪些用户进行处理或访问，他所处理的这些内容，目的是什么，在管理中起什么作用，应该产生什么的管理绩效，有哪些量化的东西加以评价。通过这些问题的确认，我们会基本上形成系统的总体认识，整个系统经过了多少步骤，每个步骤都由谁来完成，应做哪些操作，形成哪些报表，通过整理，形成初步的系统模型。
第三步找出真正的用户。这里所讲的真正用户也要分开谈，一种是指系统的直接用户，另一种指系统的最终用户，即服务对象。我们这里首先要找直接用户，通过直接用户找到最终用户。需要注意的是，因为所站的角度不一样，可能最终的用户也不一样。如开发物资管理系统，直接用户是指参与物资管理系统使用的所有用户；但最终用户可能是财务人员，也可能是计划人员，甚至可能是公司经营老总。正因为如此，我们在确定需求分析的对象时，就要站在不同的角度对系统进行分析，以确定各种对象的需求。当然需求提出来以后，并不一定都要实现，可以根据用户的需要进行取舍，但这种全面的对系统进行认识与理解，有助于我们整体把握所要开发的系统在企业各项工作中的地位与相互之间的关系，从而为系统的接口与升级留有余地。
第四步掌握一手资料。在经过与管理者的交流，建立初步印象以后，再与各个用户进行交流，我们所记录与整理的内容是否真实反映了用户所说的内容或意思，以及他们对系统实现过程中所期望能带来的改进，这一点很重要，因为只有他们最在意一些操作的可行性与实用性要求，而领导者与管理者更重视总体的功能需求。要尽可能的访问到每一个用户，如果不允许，也要保证所访问的用户具有权威性性与典型性。
第五步协助用户进行流程重组。收集好用户的各种需求与意见后，接下来，我们再与该项业务的主管人员进行交流，对我们在访问过程中，各级用户对系统提出的改进，或者说是感到不顺的地方加以澄清，并提出我们以往针对类似情况的处理案例以供决策。某种程度上讲，这是一个协助用户进行管理流程标准化或说是管理流程重组的过程（BPR）。这样的过程，看起来是增加了开发商的工作量，而且对开发商而言似乎未增加任何价值。但这个过程是值得的。用户希望利用信息系统的目的，有些用户是明确的，有些用户不明确，无论是什么情况，内心里都有这样一个想法，利用信息系统提高企业的管理效率，通过信息共享、提高效率等手段，来降低成本，实现企业竞争力提高的目的。因此，既然他们存在需要改进的地方，而且表达过了，如果此时不加以改进，未来也会进行改进，这种过程如果发生在我们系统开发的过程中，势必还会需要我们对系统的开发进行调整，以便能实现他们所提出来的新功能，也许我们可以说时间不允许加以推托，或通过价格来阻止这种情况的发生，但都会引起用户的不满意，这对开发者来说就是利益的损失。从这种意义上讲，尽可能的避免损失就是尽可能的创造效益。
第六步正确理解需求列表。通过需求分析，最终我们会形成需求文档，文档最重要的内容就是需求列表，这表示我们未来所开发的系统应该实现的功能。不过我们对此要有正确的理解，虽然在系统开发中不提倡开发人员自作主张对系统增加功能，但因为见识的面不同，可以用户一时未看到过的东西，在我们其他的项目早就实现过了，这一类情况我们要注意合理的取舍，以通过与用户交流即时的确定是否需要。另外，不能认为用户在需求文档上签过字了，以后有一点改动，都需要再行签字。要知道，有些企业的管理人员，当时认识上确实有不足的地方，后来发现了，如果你现在不让他改，对他要求这么严，他为了顾全面子，不作修改，将来使用以后，尽说你的系统的坏话，或专挑毛病，非搞死你不可。总之，在不影响到系统的根基的情况下，或者说对系统的开发成本没有太大的影响的情况下，应该尽可能的让用户在开发完成之前提出任何功能的变更需求，这是没办法的办法，这显然与开发的理论文章的说法不一致，但却是非常实在的一种做法。
需求分析是一门学问，不仅要掌握需求分析的相关工具应用，还要掌握人际交往的技巧，还要善于演讲，懂得管理的艺术，并且能综合运用这些知识。因此一个系统分析员，一个好的系统分析员真的很难做，至少比系分考试的东西要难得多。
这里讲了一些实际工作中碰到的问题，以及我们的经验之谈，当然实际工作，可能因为面对的人不一样，所要处理的问题也不一样，但有一点没变，即需求面对的人，而不仅仅是事，只有明白这一点，才能成为用户的朋友，做好我们的需求分析工作。

相关话题：需求分析源地址：http://yh.gzntax.gov.cn/k//2005-7/712998.html

如何确定需求

非法操作 — 2009-03-03 20:47:00

需求并不是设计人员自己想出来的，我们只能与用户去交流，使用科学的方法去搜集充分的信息，从而找出一组稳定的需求，那么我们先研究一些数据搜集的方法：

一、数据搜集：

1.问卷调查

所谓问卷调查，也就是设计出一系列的问题，通过网络（EMAIL、IM、website），电话，纸张等形式大面积铺放，然后回收问卷导出特定的信息。设计问卷时，首先要搞清楚调查的目的是什么，然后对每一个问题进行仔细审核，保证它们的含义清晰并且能够容易回答，并且在问卷设计完成之后先找一小部分人试答一下。

在设计问卷和分析结果时，可能任何一点细节都会影响到结论的准确度和可信度，例如：

参加调查的用户并不一定就代表所有用户
用户参加问卷调查的动机可能会影响研究结果，例如有些用户为了表示友好，让调查方高兴，甚至猜测问卷人所期望的答案
问卷来源可能会影响研究结果，有些人对某个组织单位没有好感，可能会心情不好等
研究问题的措辞可能会影响研究结果，他可能既不同意也不反对，但是没有给他机会让他说出他的想法

2.用户访谈

也就是个人采访，可以是面对面的也可以是电话的。访谈最好是在用户的工作环境或者家里。访谈更能激发被访者的响应，不过比较耗时，可以先访谈一些代表性用户，在对更广的用户进行问卷调查，以验证得到的信息。

3.观察和提问

人们有时候很难说清楚自己在做什么，也很难描述自己是如何执行这个任务的，所以我们需要观察他是如何完成任务的，并在他自然情形下的工作过程，同事记录和提出适当的问题，有助于我们更透彻的理解用户理解任务。

我们应该注意的地方是：观察的人应当是最具代表性的用户；要想透彻理解用户，就需要在他的工作环境中观察；提问要具体，重点放在他们正在做和刚刚做完的事情；你在这一过程中产生的想法要马上告诉用户以验证你的理解是正确的。

4.集体讨论

用户访谈是一对一的，只能知道一个人的看法，你也可以召集若干用户一起进行讨论。一般需要一位主持人来组织，集体讨论适合了解多数人的意见，能突出有冲突不一致的观点。不过应该特别注意避免一个或几个人垄断谈话的内容或者主导讨论，尤其是职位高或者非常有影响力的人，应该保证所有人都有平等机会发表自己意见，有些人天生内向，有些人看到领导在场就想特意表现，针对这些不利于讨论的行为，可以通过这个方式来避免：让参与讨论的用户各自使用一台电脑匿名在线会议。

二、各种方法比较

	适用情形	优点	缺点
问卷调查	回答特定问题	适用资源少，调查人数多	问卷设计很关键，回答率不高，可能答非所问
用户访谈	发掘和深入研究问题	必要时引导被访者，促进开发人员和用户的沟通	耗时，人为环境影响被访者
观察和提问	理解用户活动环境	观察实际工作，提供更多的细节	非常耗时，数据量巨大
集体讨论	搜集多方观点	突出不同观点，促进开发人员和用户沟通	讨论可能由少数人主导与实际有偏差

三、数据搜集一些要注意的地方：

一切重点都是为了搞清楚用户需要什么，每个用户类别只派一位代表参与是不充分的，打组合拳，不要单一套路，在可能的情况下先小规模试验，记录数据同样重要，如果得到的需求信息太多，我们可以采取以下步骤：

让用户列出他们希望通过产品完成的各种目标
让他们笼统列出达到目标的各种需求
按自己的理解，把这些需求转述给用户，让他们判断是否正确
鼓励用户以更开放的思路提出更多需求
你提供几个需求类别，让用户将所有需求“对号入座”。
列出各项需求的衡量标准，对不易衡量的，修改或删除

四、解释分析数据

在我们拿到了厚厚的一沓数据之后，可能会没有一个清晰的思路，它们可能是音频的视频的文字的，看着就烦，但是我们又马上必须去整理它，越早整理，记忆越清晰，出现的偏差也就越小，尤其对于访谈这类的，用户在说话时的动作语气还会回荡在你脑海中。这个时候我们需要把需求文档规范化，VOLERE需求记录卡是非常实用的：

需求编号： 101
需求分类：故障安全
描述：当通信系统终端无法传输数据时，系统发生警告
原理：如果无法传输数据，则可能是系统终端发生故障需要维护，或数据定义可能出问题
来源：客户系统安全工程师
满足标准：当每小时每个类型通信数据超出制造商指定的误差范围，产品应当通知客户
完成后客户的满意程度：满意
未完成客户的不满意度：极为不满意
相关需求冲突：无
支持材料：产品规格说明
历史：**提出，于*年月日

相关话题：需求分析源地址：http://www.czlands.cn/?p=272

潜在需求

萋萋 — 2008-10-03 09:10:01

潜在需求，也就是用户的“期望”。

都说成功的产品往往能超越表象，超越用户自身对需求的描述，直达底层的“期望”，从而让用户格外满意。例如用户说想要跑得快的马车，我们给他一辆汽车。但，越是到“潜在需求”层面，需求的定位越模糊，因而实现的具体方式也愈发多样化。
比如用户的潜在需求是安全舒适快捷的从A地到B地，实现方式会从以前的汽车，火车，进而转化为乘坐飞机旅行。再比如，用户潜在需求是用一种轻松的方式打发无聊时间，那么他可能会去选择玩电脑游戏，看肥皂剧，看电影或者阅读小说。

同样是满足潜在需求，如何能让自己的产品在一大堆的同类品，以及替代品的竞争中脱颖而出，成为用户的最终选择呢？
一，市场宣传，媒体轰炸，让产品形成精准需求定位。比如，解决上火的需求就应该喝王老吉；
二，用户之间的口口相传，借助已有的用户群拉动潜在用户加入，比如我的朋友正在看某本网络小说并强烈推荐，这本小说就会成为我打发时间的不二选择，至少，我会去尝试阅读；

没有明确需求指向的用户，做决定时往往十分随机化，而且，愿意随大流。

大需求有大deal

麦田 — 2008-10-11 10:56:14

有两类需求。一类是单价高，总量小，比如钻石；一类是单价低，总量大，比如粮食。后者基本是快速消费品范畴。互联网是快速消费品。

互联网之所以是快消品，在于互联网平台的特点：低成本，快速，浅，不用“面对面”的交流等等。这些特点使得互联网和传统产业相比，在“大单”上没有优势；但在快消品范畴，优势就很明显了。

如果你相信“互联网是快速消费品”，那么问题就只在于：第一，如何发现真正的大需求？第二，如何低成本有效率满足大需求

什么是网民的“大需求”。这里最常见的误区是以己度人。“我需要这个功能”，“我肯定会为这个功能付钱”，一些朋友这样想，然后就把他所希望的功能看作别人也需要的；更进一步，看作网民的普遍大需求。这个误区太常见了，以至于很少见到不是这么想的人。这里最需要的就是“数字”，用“数字”说话，让“数字”告诉你，你虽然自认为自己很重要，但你在茫茫人海中，只是数字的一个1。互联网是个性化的，但是真正悖论在于群体的个性，最后呈现的是共性。即，你只是群体中的一个1。

什么是网民的“大需求”。有一个简单的硬性指标：至少千万级用户需要的服务。网络新闻，网络游戏，这些都符合这点，所以这里有大需求，因此有大deal。

有且只有的一条硬指标：千万级用户需要的服务。

有点晚了，过几天我再继续写这个话题。

需求VS功能

Ami — 2008-10-14 00:33:57

小兔生活中犯职业病，不过觉得这是个挺有意思的例子，拿来和大家说说

自己在外租房子住了几年，老爸买了新的房子，有我的一间房间，打算让我去住。房间不大，2.7m*4.3m，规划到底怎样安置家具。

普通人的思维，比如我爸，“你房间里么，放个书橱，放个单人沙发吧……”

而我，“先别说放啥，先让我想想要在房间里干嘛，有什么需求……”

于是这奇特的讨论进行一段时间后，自己得出两个发现，一是自己在犯专业病，二这是个解释“功能”和“需求”区别的好例子。

很多人都容易在产品的需求规划阶段一个劲儿地讨论“我们要做个xx功能”，好像“功能”就是“需求”，以前也的确见过很多这样的“需求文档”和“需求讨论会”啥的，还遇到过PM斩钉截铁地坚持“讨论功能就是讨论需求”。我认为这些人的思路，就如同一装修就谈放什么家具、用什么地板什么灯一样。产品的初期规划就直奔功能和表象而去，我认为总是很让人忧心的现象。

来说说我是怎样从“职业病”的思路考虑房间的问题的：

首先，由于这房子离公司路程较远，主要应该是为了每天下班回来后能够好好休息，和双休日不出门的时候能休闲放松、并且提升自己知识能力。

具体来说，每天回到家就要有个缓解体力疲劳休息的地方，可能是个沙发、躺椅，能坐下休息的；晚上睡觉要舒适；

要满足舒适的阅读需求，因此书籍要便于管理取阅，阅读时要姿势舒服光线充足；要有个用电脑的区域，不愁电源和网络，使用电脑姿势要舒适；要看DVD要玩wii，电视机前坐得要舒服，还要有足够活动空间放wii balance 板和活动；

为此，我可以弄个写字桌，但是也考虑书橱旁边一个单人沙发、配上一落地阅读灯、再配个笔记本电脑桌；若不配沙发和扶手椅，可以考虑把床换成坐卧两用床，对着电视机放，可以坐着看电视，晚上睡觉……等等等等

为了满足上面自己归纳出来的需求，比如回家能坐下休息”，我有很多解决方式(功能)，沙发、躺椅、坐卧两用床、甚至榻榻米……至于具体用哪个，还看哪个最能满足需求，而且方便实现。实现需求难免会有局限，房子有大小和装修预算，产品有技术局限和开发成本……至于具体怎样设计，是根据需求考虑的组织过程。曾和我们的设计师说，解决用户或者运营编辑的需求，他们提出要个“xx功能”，若你能挖掘出背后的需求来设计，给他一个完全不同的功能，说不定更能让人满意。反之，他们说啥你做啥，有时候反而不见得是好主意。

在要决定“需要坐下休息”的阶段去决定“要放沙发”，甚至是“放个黑色真皮沙发”，是我身边经常见到的误区。若能回答“为什么放沙发”的还好，有人连个为什么也答不出来，遇见这样的我只觉得额头上直挂下三条竖线，那个汗啊…这些人也很容易就这样盯着一个功能一路钻下去了，顶多想到沙发是不是还能换成个扶手椅什么的。

你是否真正思考了用户要什么？为什么要？作为产品的规划者或设计者，是否都该审视自己有意无意拘泥在了“沙发”上。在白鸦来培训的时候，我也提出这个现象来请他们解答。起码在你决定功能的时候，应该已经想明白了需求。

相关话题：需求分析源地址：http://www.amizhang.com/?p=80

何为需求？

Yvonne — 2008-10-14 23:30:59

白鸦老师拿一位网友订机票的经历（订张飞机票真是麻烦）作为应用情景设计的案例，抛砖引玉，发起讨论，让大家思考从这个场景中，你发现了什么需求？

确实，从用户经历中我们看到的购票不便、支付不便等。但是我想说的是，究竟什么是需求？在各类用户的全服务链体验过程中，哪些需求才是企业需要真正关注的？

需求分析是产品设计的基础，但是常常在做需求分析时会进入一个误区，觉得这个也需要，那个也需求，试图想让自己的产品满足所有用户的需求，结果却迷失了方向。If you want to please everyone, I can’t please anyone. 因此，在做需求分析时，企业的战略定位是核心。在满足基础共性需求的基础上，根据自己的战略定位，满足目标客户群的需求，并提供略高于目标客户期望的需求，这里的略高于是需要随着客户成熟度的提高而递增。

回过来看这个案例，简而言之，用户需要买低价机票，而低价机票很紧俏，需要随订随售。而用户只有一张建行卡，没有U盾，按照银行规定，网上支付有500元的限额。

从航空公司的角度来说。如果是一家以商务客为目标客户群的公司，那么这个用户的需求可以忽略不计，因为商务客对价格不敏感，并且一定会有多张支持网上支付的信用卡，也有较为丰富的网上交易经验（在现在网上交易已经比较普遍的环境下，如果再早几年，另当别论）。显然，此用户并非这类航空公司的主要目标客户，如果为了满足这类用户的需求，而增加资源的投入，投资回报率不高。同时，呼叫中心的电话支付也可以成为网上支付瓶颈的一项补充。

如果是一家价格导向的航空公司，以低价来吸引客户，那么此用户的需求将成为这类航空公司考虑网上交易的主要因素。比如，低价搜索，低价通知，一笔订单的多次支付等。

从支付平台来讲。交易网站与银行一家家做直连的成本太高。因此，通常会选择1-2家主要银行直连，再接入第三方的支付平台来加大银行的受理面。但是我们看到现在大部分的第三方支付平台，只是做了一个各银行接口的统一，却受到了银行更为苛刻的出于安全性考虑的金额限制。如何帮助商户来减少限额问题引起的交易壁垒，是第三方支付平台需要解决的问题。在这点上，支付宝抓住了需求，虚拟账户的储值功能，无疑是超出同类支付平台的制胜法宝。

但是，从这个案例中，也看到了支付宝的一个盲点，虽然能够多次储值、一次支付，但是仍然没有绕开银行单日限额的尴尬，当用户支付宝帐户内没有储值，又急着支付时，支付宝的储值功效就无法显现。如果说网上交易安全性防范更严格，不接受预授权的话，那么是否可以增加电话支付方式储值，通过预授权操作，缓解限额问题。我想这样做的话，能够更大的发挥支付宝的优势。

何为需求？需求并不是所有用户的每一个需要满足的渴求点。一方面，需要以战略定位为核心，锁定目标客户群，另一方面，需要把握市场竞争中的空白点，找到企业进入市场，体现核心竞争力的切入点。

相关话题：需求分析源地址：http://www.melrhy.com/blog/2008/10/14/292/