一个需求的奋斗史
文章目录
导引
2.1 从用户中来到用户中去
“从用户中来到用户中去”，“用户是需求之源”，我们要拥有“以用户为中心的思想”，不断“体会真正的用户”。
实际工作中，到底采用哪种用户研究方法，往往取决于资源，比如人员数量与能力、老板给你多少时间、经费。
说需求采集的过程，都会有如下几步：明确目标、选择采
集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。
2.2 需求采集的大生产运动
与用户接触的过程就是需求采集的过程，常用的需求采集方法，如“数据分析”、“调查问卷”、“用户访谈”等。
2.2.1 定性地说：用户访谈
用户访谈的常见问题与对策
| 问题 | 对策 |
|---|---|
| 第一，心口不一（需求模糊） | 1.物质引诱； 2.判断说话方式(要求采集人员有合理的判断能力) |
| 第二，样本少，以偏概全的问题。 | 1。随机选样； 2.首先，我们应该尽量识别出各种可能引起偏差的因素，并在访谈的报告里标明，让读者了解。然后，为了用尽可能少的样本得到尽可能正确的结论，我会以增量的方式做访谈。 3.应用概率和数理统计对样本进行选取。 |
| 第三，用户过于强势，把我们往沟里带。 | 1.需要时刻牢记访谈的目的。 2.如果发现话题不对，就赶紧往正道上扳; 3.若发现多次都扳不过来，就可以考虑尽快结束了，用户很多，不要在一个不合适的对象上花费太多时间。 |
| 第四，我们过于强势，把用户往沟里带。 | 1.牢记访谈的目的，并且管好自己的嘴。 |
《软件观念革命：交互设计精髓》中访谈注意点：
► 避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读。
► 首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用
户为什么这么做。
► 避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、
片面。
► 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。
► 鼓励讲故事：故事是最好的帮助设计师理解用户的方法。
►避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用么？”一般来说用户会给出毫无意义的肯定答复。
2.2.2 定量地说：调查问卷
（1）两种方式的区别和联系
| 调查方式 | 区别 |
|---|---|
| 用户访谈 | 用户访谈的提纲通常是开放式问题,用于我们心里还比较疑惑的时候去寻找产品的方向，适合与较少的访谈对象进行深入的交流； |
| 调查问卷 | 调查问卷通常封闭式问题比较多，适合大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案，调查问卷不是考试卷，不适合安排问答题。 |
| 联系 | 通过前者的开放式问题，为后者收集具体的封闭式问题。 |
(2) 调查问卷的设计技巧：
无论是网上还是线下，作答时间最好不要超过 10 分钟，否则很多人看一眼就被吓跑了。开篇一般放一些简单的不需要思考的问题；很想知道的内容，需要思考的，较敏感的问题一般放在中间；而有关被访者个人信息的题目一般放在问卷的最后，以免应答者在回答这些问题时有所顾忌，进而影响其他答案。
(3) 调查问卷的常见问题与对策
| 问题 | 策略 |
|---|---|
| 第一，样本的偏差，即样本与想了解的目标用户群体出现偏差。 | 1.尽可能覆盖目标群体中各种类型的用户； 2.把目标群体的特征也定义成一系列问题，放入问卷中，待我们回收问卷以后，就可以通过这些问题评估作答者是否能代表目标群体了。 |
| 第二，样本过少的问题。 | 1.样本量过少时，采用百分比来分析是没有意义的。 |
| 第三，问卷内容的细节问题。 | 1.问题表述应无引导性，这点和用户访谈类似； 2.答案的顺序，可能产生“顺序偏差”或“位置偏差”，即被调查者选择的答案可能与该答案的排列位置有关。 3.通用的办法就是先进行小范围的试答，根据反馈修改后，再大面积投放，这和互联网产品的灰度发布设计一份实际的问卷有着同样的理念。 |
2.2.3 定性地做：可用性测试
可用性测试定义：可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。
（作者讲的模糊，过于高深，给出如下定义：可
用性测试的概念是：让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。
可用性有五个指标，分别是易学性、易记性、容错性、交互效率和用户满意度。
可用性测试适于解决的问题：
1） 确定测试产品的可用性水平
2） 与预期目标、与竞争对手、与老版设计相比的可用性水平
3） 比较不同方案，确定哪个方案更加可行
4） 现测试产品的可用性问题
）
主要过程：
- 首先要招募测试用户。招募测试用户的主要原则是，这些用户要能尽可能地代表将来真实的用户，比如说，如果产品的主要用户是新手，那么就应当选择一些对产品不熟悉的用户。
- 然后是准备测试任务。测试的组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。
- 接下来的重头戏是测试过程。可用性测试的基本过程就是用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。
- 测试结束后：组织者可以询问用户对于产品整体的主观看法或感觉。另外，如果用户在测试的过程中没有完全把思考的过程说出来，此时也可以询问他们当时的想法，询问他们为什么做出那些操作。
- 最后是研究和分析：在可用性测试结束之后，组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。
可用性测试的常见问题与对策
| 常见问题 | 对策 |
|---|---|
| 第一，如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了。 | 1.可用性测试在产品的各个阶段都可以做。 2.在尚无任何成型的产品时，可以拿竞争对手的产品给用户做； 3.在产品只有纸面原型的时候，可以拿着手绘的产品，加上纸笔给用户做； 4.在产品只有页面 Demo 的时候，可以拿 Demo 给用户做； 5.更多的时候，在产品已经可以运行以后，可以拿真实的产品给用户做。 |
| 第二，总觉得可用性测试很专业，所以干脆不做。 | 1.可用性测试，听着很专业，但收益又无法量化，所以对很多老板来说，不太愿意在这个上面投入资源，经常因为项目时间过紧被略过。(可用性测试通常来说做 5 个左右的用户才可以发现大部分的共性问题) |
| 第三，明确是测试产品，而不是测试用户。 | 1.可用性测试要邀请用户来做测试人员，我们在开始之前，应当明确地告诉用户，这个测试的目的是发现软件产品中的问题，而不是要测试用户是否有能力来很好地使用软件。 |
| 第四，测试过程中，组织者该做的和不该做的。 | 1.可用性测试中，我们可以要求用户在使用产品的过程中采用一种名为“发声思维”的方法，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作，等等。 2.做测试的过程中千万不要有任何的引导与暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。(用户行为和预想的不一样时，可以提问，实在进行不下去的时候，给予提示。记住，一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了。) 3.结束之后，如有可能应该送个小礼品，当然在邀请的时候就要告诉用户会有一些对他付出时间的补偿。 |
作者以网页改版为例，提出处理过程：
- 除了“可用性测试”要在足够早的时候做以外，发布后也是有一些方法改进的。
比如先从部分次级页面改起，像“我的淘宝”历时多年的改版； - 再如新旧版本并存一段时间，并允许用户自由选择，比如 2007 年的雅虎邮箱和新浪邮箱改版；
- 三如小面积试验，选择一小批测试用户放出新版本，监测效果，做用户调研，比如 Gmail 在发布某些新功能的时候；
- 四如傍上一个用户已经习惯的风格，比如网店版的前身“高级店铺”升级到网店
版 1.0 的时候，讨论了很多方案，最终还是决定模仿“我的淘宝”的页面风格。
总之，对于改版，对于升级，我们要把“暴力革命”变成温柔和谐的“和平演变”。
2.2.4 定量地做：数据分析
| 常见问题 | 对策 |
|---|---|
| 第一，过于学术，沉迷于“科学研究” | 1.科学研究通常只注重“性价比”的性,只要结 果好,往往不在乎投入,因为相对而言科研的结果不是为了马上应用,而是为了证 明实力. 2.但实际生产环境就更注重综合的性价比了,所以我们日常的数据分析方法也就显 得不那么严谨了 |
| 第二，虽然数据不会主动骗人，但我们经常无意或有意地误读数据。 | 1.无意地误读数据，这个问题的对策，是学习统计学的知识 ，努力提高自己的水平。(推荐阅读《黑天鹅》和《统计数字会撒谎》这类统计学的图书，不似教材那般枯燥，适合工作以后的人阅读，附录中会有简单介绍。) 2.主动地误读数据，是比较有趣的现象。个简单的对策就是对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯 |
| 第三，平时不烧香，临时抱佛脚。 | 1.应该在产品设计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等，这也算一种典型的非功能需求，这样做对产品的可持续发展非常必要。 |
数据分析是如何转化为商业价值的.整体的思路是：在对 产品足够熟悉的基础上,先做出方向性的假设,再提取相应的数据并分析,得到一些 现象,最好是之前没发现的现象,然后尝试解释,接下来做用户调研修正解释,最终 指导产品发展方向。
2.2.5 需求采集人人有责
单项需求卡片
单项需求卡片的理念就是：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程.
尽可能多地采集:
- 需求采集，并不是产品设计之前的工作，而是一个贯穿始终的过程；
- 现场调查。说简单一点就是打入“敌人”内部，和客户一起工作一段时间，深度了解需求。
AB 测试。:其实就是对比测试，选择少量用户分成两组对两种情形进行测试，然后根据测试结果决定剩下的大数据用户改如何修改，胡总和操作。
日记研究。:日记的作者往往是同行，而不是主流用户。即对于同行的日记研究应该加以研究防止内容和自己的工作内容，或者所涉及的内容不符，或者故意误导。
**卡片分类法。**我们把产品的各种需求写在便利贴上,让用户一起讨论并完成分类.
自己提需求。自己对自己的产品应该更加了解，并且，可以自己使用，自己提出改进；另一方面通过认识的人对产品进行使用，并通过他们的反馈修改产品。也就是说，自己看待自己的产品要客观，也需要听取别人的见解。坚持“需求驱动学习”。
2.3 听用户的但不要照着做（需求分析）
必须“明确我们存在的价值”是“把用户需求转化为产品需求”，这一过程即需求分析过程。（通过用户的要求，提升我们设计产品的需求）
2.3.1 明确我们存在的价值
用户需求 VS.产品需求
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需
求的过程。
有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。需求分析是“首先：树叶——树枝——树干，其次：树干——树枝——树叶”的分析过程，所以说完整的需求分析是一个“分-总-分”的过程。一方面不能漏掉提炼用户需求的这个过程，目的是透过现象看本质，另一方面也不能停在本质上，试想如果做到“树干”就结束，后端的执行人员可能还是不知道要做什么东西，所以我们还要继续把树干再重新分解成树枝、树叶。
伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西，这就是本节标题的意思——我们存在的价值。（可能这种需求，既解决了用户的需求，又节约了用户成本）
长短期盈利（满足客户长期需求）：为了长期利益，我们就有必要找到用户的真实需求，然后给他真正合适的产品了，哪怕这个过程不那么讨好。
满足需求的三种方式
之前我们说过，需求来源于理想与现实的差距，那么减小这个差距就有三种方式：
-
改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法。
-
降低理想。不要忽视精神的力量，什么“打预防针”、“丑话说在前头”这类句子
想必大家都经常听到。 -
转移需求。因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会觉得这个差距没那么可憎了。我们也可以说，人的行为是需求驱动的，想改变人的行为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求。
创造需求
满足需求的方式，我们开阔了思路以后从一种变为了三种，但毕竟都是用户提出来的需求，我们能不能再开阔一点？不劳用户的大驾，直接达到产品设计的最高境界——创造需求！
2.3.2 给需求做一次 DNA 检测（确定产品需求）
先把用户需求转化为产品需求，然后一步步确定每个产品需求的基本属性、商业价值、实现难度、性价比等。
把用户需求转化为产品需求(第一步就是“需求转化”)
对任何产品来说，只要需求采集的功夫做足了，你就会发现上面这个产品需求列表行数超多，所以在需求转化过程中，我们也会做一轮筛选，把明显不靠谱的用户需求直接过滤掉，不计入上述列表，当然，是否“明显不靠谱”就要由你来把握了，不要把“没资源做”、“短期内有技术难点”的用户需求给错杀了。
确定需求的基本属性
(本人总结)人人参与其中，通过明确的表格文档形式就行展示和共享，有益于共同谈论与改进。
需求种类知
其实产品需求远非我们直接可以想到的功能需求，还包括了很多非功能需求，比如：性能、可培训、可维护、可扩展……有很多需求不是为终端用户做的，而是为销售、服务、测试团队的同学做的。
通常来说“产品功能需求+产品非功能需求 = 产品需求”，而“产品需求+市场需求+开发需求+测试需求+服务需求+…… = 产品包需求”。
分析需求的商业价值
商业价值，或者叫商业优先级，是对上述几种商业价值指标的综合评判。这一条是整个需求列表中最核心的部分，这里的判断直接影响着产品未来的方向。
初评需求的实现难度
绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。
- 首先简化为人力成本,即工作量;
- 其次，我们把工作量再简化为开发量。
一般情况下，团队里产品人员资源相对富裕，测试资源可以调配，服务资源可以临时补充，所以开发资源经常成为瓶颈。
性价比
（本人总结）似乎是矛盾的，要求分母大（商业价值大），那么对于一个产品也相应的会增加实现难度；如果要求分子小（实现难度小），那么会出现商业价值不高的问题。对于此处作者没有给出明确答案，但作者的意思应该是在相同需求中选取实现的难度较小的更为合适，对于不同的商业价值，也要谈论它的实现是否可以满足：同样的商业价值，对于需求相同的解决方案，选取最小的实现难度，以求达到最高的性价比。另外作为性价比的选取，不要因为个人，或者其他人的原因，而偏于哪一个！！
2.4 活下来的永远是少数(需求筛选）
2.4.1 永远忘不掉的那场战争【部门分配方式的不同（产品线&职能线）】
按产品线划分的团队对产品本身是有利的，产品经理权力更大，可以按照自己的想法做，资源有保证，产品规划不容易被动改变。此外，各种职能的员工之间沟通顺畅，单线领导，开发的头、测试的头等都向产品经理负责。
按职能线划分的团队对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高，由于产品规划的决策需要在更高层面上敲定，单个产品的发展速度会有所降低。此外，资源战争可以把“鲶鱼效应 ”从产品内部扩大到公司层面，使产品经理和设计师们更抓狂地为产品的发展而苦苦思索，这是一件好事。
两种组织结构，给我“一攻一守”的感觉，产品在创业期的时候，需要全速发展，必然是产品线结构，产品经理带头往前冲。而当公司里有多个产品慢慢成熟之后，就多用职能线来更充分地利用资源，因为在成熟的产品团队中，要做的事情通常比创业时期少，或者说没那么急，那么各种资源就显得有富裕，可以更加的稳扎稳打，所以按职能线划分以实现资源共享，同时还可以促进不同产品团队之间的互相学习，让员工的个人能力得到更多的提升。
需求打个包
需要注意的地方
- 第一，“需求打包”最好打包类似的功能点。
- 第二，需求依赖，功能互相之间有依赖关系。
- 第三，需求的粒度大小问题。
商业价值很高的功能，如果细分的话，我们会发现其中也有价值相对低的部分，所以需求的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内，给个生活中的例子帮助理解：大开间办公区域里的灯，不可能用一个开关控制，也不可能每一个开关只控制一盏灯。具体细到多少，要根据具体情况具体分析。我们的经验是，在需求列表里出现的任意一行，工作量最好不要超过“5 人天”。
产品会议
商业需求文档Business Requirement Document，简称 BRD
BRD 怎么写，都包含哪些内容。
项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。
商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。
非功能需求描述：提一下重要的非功能需求，如果有的话。
资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多
大的花费以后，才能做出决策。
风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。
从 BRD 中的“商业价值”、“资源评估”两个重点中大家可能也发现了，其实本
质上大老板们也是在追求那个词——性价比。大家都希望花费最少的资源获得最大的商业价值。
2.4.2 别灰心，少做就是多做
- 情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。
- 做得少不如做得巧。
- 尽可能多地放弃
105
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
