目录 6
序言 13
第一部分 为共识而谈判 17
1 方法论是不够的 18
1.1 case，cad和灭蟑仪 18
1.2 方法作用于问题 19
1.3 映射及其符号系统 20
1.4 确保每个人都能读懂映射图 21
1.5 需求的映射图并不是需求 21
1.6 提示和变化 22
1.7 小结 24
2 在陈述需求中的含混性 24
2.1 含混性的例子 24
2.1.1 缺少的需求 25
2.1.2 含混的词语 25
2.1.3 无意中引入的假设 25
2.2 含混性的成本 26
2.3 为消除含混性而探索 27
2.3.1 需求的图片 27
2.3.2 需求的模型 28
.2.4 提示和变化 28
2.5 小结 28
3 含混性的来源 29
3.1 实例：收敛设计过程演讲 29
3.2 注意力的测试 30
3.3 聚类启发 31
3.3.1 观察和回忆错误 31
3.3.2 解释错误 32
3.3.3 错误来源的混合 32
3.3.4 人们交互的作用 32
3.4 问题陈述的含混性 33
3.5 提示和变化 35
3.6 小结 35
4 可靠但不真实的直接问题的用法 36
4.1 决策树 36
4.1.1 问题的次序 37
4.1.2 穿越决策树：一个实例 37
4.2 含混性投票的结果 38
4.3 可能会是什么错了？ 39
4.4 现实生活比我们想象的要现实 40
4.5 提示和变化 40
4.6 小结 41
第二部分 开始之路 42
5 切入点 43
5.1 一个通用的切入点 43
5.2 不同切入点的通用化 43
5.2.1 来自解决方案的想法 43
5.2.2 来自技术的想法 44
5.2.3 比喻 45
5.2.4 标准 45
5.2.5 实体模型 46
5.2.6 名称 46
5.3 存在性假设 46
5.4 一个升降机的例子 47
5.4.1 命名我们的项目 47
5.5提示和变化 48
5.6 小结 48
6 自由问题 49
6.1 过程的自由问题 49
6.2 自由提问的潜在影响 50
6.3 产品的自由问题 50
6.4 连环问题 51
6.5 自由提问的好处 52
6.6 提示和变化 53
6.7 小结 54
7 找到正确的相关人员 55
7.1 辨别正确的人员 55
7.1.1 客户和使用者 55
7.1.2 为什么要包括使用者？ 56
7.1.3 铁路的矛盾 56
7.1.4 产品能够创造用户群 56
7.1.5 失败者是使用者吗？ 57
7.2 启发式包含使用者 57
7.2.1 列出可能的用户群 57
7.2.2 修葺使用者清单 59
7.3 参与者 59
7.3.1 谁参与？ 60
7.3.2 他们什么时候参与？ 61
7.3.3 我们如何得到他们的判断？ 61
7.4 为抓获使用者而计划 61
7.5提示和变化 62
7.6 小结 62
8 为每个人准备会议工作 63
8.1 会议：离不开又无法忍受的工具 63
8.1.1 一个可怕而典型的会议 63
8.1.2 为度量而开会 65
8.2 参与和安全 65
8.2.1 建立一个打断机制 66
8.2.2 设置时间限制 66
8.2.3 反对人身攻击和贬低 66
8.2.4 缓解压力 66
8.2.5 承认结束时间，并且按时结束 66
8.2.6 处理相关问题 67
8.2.7 改进规则 67
8.3 不出席会议也感到安全 67
8.3.1 公布一个议程并且坚持它 68
8.3.2 不插手突发模式 68
8.3.3 处理好不相关的人员 68
8.3.4 包含正确的人员 68
8.4 设计你需要的会议 69
8.5 提示和变化 69
8.6 小结 70
9 自始至终降低含混性 70
9.1 利用记忆启发 70
9.2 延伸含混性投票 71
9.3 "玛丽从前有一只小羔羊"启发 71
9.4 详述"玛丽欺骗商人"启发 73
9.5 在星星问题上应用启发 75
9.6 提示和变化 78
9.7 小结 78
第三部分 探索机会 79
10 产生想法的会议 81
10.1 典型的头脑暴风雪 81
10.2 头脑风暴的第一部分 82
10.2.1 不允许批评和责备 82
10.2.2 让你的想象自由飞翔 83
10.2.3 为数量而努力 83
10.2.4 改变和合成想法 83
10.3 头脑风暴的第二部分 83
10.3.1 门限投票法 83
10.3.2 竞选演讲投票法 84
10.3.3 合成想法 84
10.3.4 应用判据 85
10.3.5 打分或者排名系统 85
10.4 有益的提示和变化 85
10.5 总结 85
11 右脑方法 87
11.1 地图工具 87
11.1.1 草图 87
11.1.2 画曲线图 87
11.2 头脑作图 88
11.3 右脑运动 88
11.4 有益的提示和变化 89
11.5 总结 89
12 项目的名称 91
12.1 工作名称，绰号和正式名称 91
12.2 名称的影响 91
12.2.1 一个命名的证明 92
12.2.2 命名完成了什么？ 92
12.3 启发式命名方法 93
12.4 有益的提示和变化 94
12.5 总结 94
13 面临冲突时推动进程 95
13.1 处理无关紧要的冲突 95
13.1.1错误的时间，错误的项目 95
13.1.2 个性冲突 96
13.1.3 必不可少的人 96
13.1.4 组内的偏见 96
13.1.5 级别不一样 97
13.2 注意力完全集中的技巧 97
13.3 处理本质的冲突 98
13.3.1 重塑个性差异 98
13.3.2 协商 99
13.3.3 处理政治冲突 99
13.4 有益的提示和变化 100
13.5 总结 100
第四部分 明确期望 102
14 功能 103
14.1 定义功能 103
14.1.1 存在功能 103
14.1.2 测试功能 103
14.2 记录所有且唯一的功能 104
14.2.1 记录所有潜在的功能 104
14.2.2 理解明显的、隐藏的以及装饰性的功能 105
14.2.3 识别未注意到的功能 106
14.2.4 避免隐含的解决方案 107
14.2.5 "如果你能够就实现它"列表 107
14.3 有益的提示和变化 108
14.4 总结 108
15 属性 110
15.1 属性的愿望列表 110
15.2 改变愿望列表 111
15.2.1 区分属性和属性细节 111
15.2.2 揭示属性的含混性 111
15.2.3 组织列表 112
15.2.4 从改变后的列表揭示内幕 112
15.3 为功能分配属性 113
15.3.1 属性如何修改功能 113
15.3.2 从新格式中获取内幕 113
15.4 去掉属性 113
15.4.1 将属性分类为必须，需要和忽略 113
15.4.2 隐式和显式地排除属性 114
15.5 有益的提示和变化 114
15.6 总结 115
16 约束条件 116
16.1 定义约束 116
16.2 考虑作为边界的约束 116
16.3 测试约束 118
16.3.1 过于严格？ 118
16.3.2 不够严格？ 118
16.3.3 不清楚吗？ 119
16.3.4 产生新的想法 119
16.4 相互关联的约束 119
16.5过度约束 120
16.6 心理约束 120
16.6.1 倾斜观念 121
16.6.2 打破约束 121
16.6.3 自负与糟糕设计的循环 122
16.7 约束产生自由 122
16.7.1 标准 122
16.7.2 语言和其他工具 122
16.8 有益的提示和改变 123
16.9 总结 124
17 优先级 125
17.1定义优先级 125
17.1.1一个例子 126
17.1.2 优先级的来源 126
17.2 让优先级可量化 126
17.2.1 针对度量的合理方法 126
17.2.2让优先级可量化 127
17.3 区别约束和优先级 127
17.3.1 满足进度是约束吗？ 127
17.4 受到约束的优先级 128
17.4.1 它值什么图（what's-it-worth?graphs） 129
17.4.2 什么时候你需要它图（when-do-you-need-it?graph） 129
17.5 重新将约束定制为优先级 130
17.5.1 在优先级之间交易 130
17.5.2 产品开发的决定律 131
17.6 有益的提示和变化 132
17.7 总结 132
18 期望 134
18.1 限制期望的原因 134
18.1.1 人们不是完美的 134
18.1.2 人们并不都是有逻辑的 134
18.1.3 人们对事情的感受不一样 135
18.1.4 设计者也是人 135
18.2 采用期望限制过程 136
18.2.1 产生专门的期望列表 136
18.2.2 电梯的例子 136
18.2.3 产生期望列表 137
18.2.4 限制期望 138
18.3 限制条件不必被限制 138
18.3.1 轮椅的例子 138
18.3.2 让可能性保持公开 139
18.3.3 包括限制的来源 139
18.4 有益的提示和变化 139
18.5 总结 140
第四部分 极大地增加成功的可能 141
19 含混性度量 142
19.1 测量含混性 142
19.1.1 使用含混性投票 142
19.1.2 使用投票方法 143
19.1.3 在不同的基础上投票 143
19.2 将度量作为测试 143
19.2.1 度量三类含混性 143
19.2.2 解释结果 144
19.2.3 通过聚类得来信息 144
19.2.4 选择被投票的人群 144
19.3 有益的提示和变化 145
19.4 总结 145
20 技术评论 146
20.1 一个走过场的例子 146
20.2 技术评论的角色 148
20.2.1 正式和非正式的评论 148
20.2.2 技术评论与项目评论 148
20.3 评论报告 149
20.3.1 评论报告所需的东西 149
20.3.2 创造问题列表 150
20.3.3 技术评论总结报告 150
20.4 评论的主要类型 151
20.4.1 香草评论 151
20.4.2 检查 152
20.4.3 预演 152
20.4.4 联名声明评论 152
20.5 真实与理想的评论 152
20.6有益的变化和提示 153
20.7 总结 153
21 衡量满意度 154
21.1 创建用户满意度测试 154
21.1.1 测试属性 154
21.1.2 为每个项目采取的客户测试 154
21.2 使用测试 155
21.2.1 好处 155
21.2.2 绘制改变和趋势 156
21.2.3 解释评论 156
21.2.4 感觉就是事实 156
21.3 测试的其他用处 157
21.3.1 交流工具 157
21.3.2 贯穿项目的持续作用 158
21.3.3 对设计者的用处 158
21.4 其他测试 158
21.4.1 原型作为满意度测试 158
21.5 有益的提示和变化 159
21.6 总结 160
22 测试用例 160
22.1 黑箱测试 160
22.1.1 外部与内部的知识 160
22.1.2 构建黑箱测试用例 161
22.1.3 测试这些测试用例 162
22.2 应用测试用例 162
22.2.1 示例 162
22.2.2 反复测试和回答 163
22.2.3 清晰地指明含混性 164
22.3 以测试用例为证 164
22.4 有益的提示和变化 165
22.5 总结 166
23 学习已存在的产品 166
23.1 把现存产品当作标准来使用 166
23.2 访谈 167
23.2.1 新产品中有什么不见了？ 167
23.2.2 为什么不见了？ 167
23.2.3 在旧产品中遗漏了什么？ 168
23.2.4 在旧需求中遗漏了什么？ 168
23.3 用特征代替功能 169
23.4 有用的提示和变化 170
23.5 小结 170
24 达成协议 171
24.1 决策从哪里来 171
24.1.1 选择，假设和强迫接受 171
24.1.2 电梯设计决策的例子 171
24.1.3 撰写可追溯的需求 172
24.2 错误假设从哪里来 173
24.2.1 有效信息的缺乏 173
24.2.2 超时失效 173
24.2.3 收费公路效应 173
24.2.4 需求渗漏 174
24.3 把决策转化为协议 174
24.4 有用的提示和变化 174
24.5 小结 175
25 结束 175
25.1 对结束的害怕 176
25.2 结束一切的勇气 176
25.2.1 自动化设计和开发 176
25.2.2 堆土窑方式 176
25.2.3 冻结需求 177
25.2.4 重新谈判过程 177
25.2.5 对做出清晰假设的害怕 177
25.3 不够格的勇气 178
25.4 有用的提示和变化 178
25.5 小结 179
参考文献 179
索引表 179
· · · · · · (收起)
序言 13
第一部分 为共识而谈判 17
1 方法论是不够的 18
1.1 case，cad和灭蟑仪 18
1.2 方法作用于问题 19
1.3 映射及其符号系统 20
1.4 确保每个人都能读懂映射图 21
1.5 需求的映射图并不是需求 21
1.6 提示和变化 22
1.7 小结 24
2 在陈述需求中的含混性 24
2.1 含混性的例子 24
2.1.1 缺少的需求 25
2.1.2 含混的词语 25
2.1.3 无意中引入的假设 25
2.2 含混性的成本 26
2.3 为消除含混性而探索 27
2.3.1 需求的图片 27
2.3.2 需求的模型 28
.2.4 提示和变化 28
2.5 小结 28
3 含混性的来源 29
3.1 实例：收敛设计过程演讲 29
3.2 注意力的测试 30
3.3 聚类启发 31
3.3.1 观察和回忆错误 31
3.3.2 解释错误 32
3.3.3 错误来源的混合 32
3.3.4 人们交互的作用 32
3.4 问题陈述的含混性 33
3.5 提示和变化 35
3.6 小结 35
4 可靠但不真实的直接问题的用法 36
4.1 决策树 36
4.1.1 问题的次序 37
4.1.2 穿越决策树：一个实例 37
4.2 含混性投票的结果 38
4.3 可能会是什么错了？ 39
4.4 现实生活比我们想象的要现实 40
4.5 提示和变化 40
4.6 小结 41
第二部分 开始之路 42
5 切入点 43
5.1 一个通用的切入点 43
5.2 不同切入点的通用化 43
5.2.1 来自解决方案的想法 43
5.2.2 来自技术的想法 44
5.2.3 比喻 45
5.2.4 标准 45
5.2.5 实体模型 46
5.2.6 名称 46
5.3 存在性假设 46
5.4 一个升降机的例子 47
5.4.1 命名我们的项目 47
5.5提示和变化 48
5.6 小结 48
6 自由问题 49
6.1 过程的自由问题 49
6.2 自由提问的潜在影响 50
6.3 产品的自由问题 50
6.4 连环问题 51
6.5 自由提问的好处 52
6.6 提示和变化 53
6.7 小结 54
7 找到正确的相关人员 55
7.1 辨别正确的人员 55
7.1.1 客户和使用者 55
7.1.2 为什么要包括使用者？ 56
7.1.3 铁路的矛盾 56
7.1.4 产品能够创造用户群 56
7.1.5 失败者是使用者吗？ 57
7.2 启发式包含使用者 57
7.2.1 列出可能的用户群 57
7.2.2 修葺使用者清单 59
7.3 参与者 59
7.3.1 谁参与？ 60
7.3.2 他们什么时候参与？ 61
7.3.3 我们如何得到他们的判断？ 61
7.4 为抓获使用者而计划 61
7.5提示和变化 62
7.6 小结 62
8 为每个人准备会议工作 63
8.1 会议：离不开又无法忍受的工具 63
8.1.1 一个可怕而典型的会议 63
8.1.2 为度量而开会 65
8.2 参与和安全 65
8.2.1 建立一个打断机制 66
8.2.2 设置时间限制 66
8.2.3 反对人身攻击和贬低 66
8.2.4 缓解压力 66
8.2.5 承认结束时间，并且按时结束 66
8.2.6 处理相关问题 67
8.2.7 改进规则 67
8.3 不出席会议也感到安全 67
8.3.1 公布一个议程并且坚持它 68
8.3.2 不插手突发模式 68
8.3.3 处理好不相关的人员 68
8.3.4 包含正确的人员 68
8.4 设计你需要的会议 69
8.5 提示和变化 69
8.6 小结 70
9 自始至终降低含混性 70
9.1 利用记忆启发 70
9.2 延伸含混性投票 71
9.3 "玛丽从前有一只小羔羊"启发 71
9.4 详述"玛丽欺骗商人"启发 73
9.5 在星星问题上应用启发 75
9.6 提示和变化 78
9.7 小结 78
第三部分 探索机会 79
10 产生想法的会议 81
10.1 典型的头脑暴风雪 81
10.2 头脑风暴的第一部分 82
10.2.1 不允许批评和责备 82
10.2.2 让你的想象自由飞翔 83
10.2.3 为数量而努力 83
10.2.4 改变和合成想法 83
10.3 头脑风暴的第二部分 83
10.3.1 门限投票法 83
10.3.2 竞选演讲投票法 84
10.3.3 合成想法 84
10.3.4 应用判据 85
10.3.5 打分或者排名系统 85
10.4 有益的提示和变化 85
10.5 总结 85
11 右脑方法 87
11.1 地图工具 87
11.1.1 草图 87
11.1.2 画曲线图 87
11.2 头脑作图 88
11.3 右脑运动 88
11.4 有益的提示和变化 89
11.5 总结 89
12 项目的名称 91
12.1 工作名称，绰号和正式名称 91
12.2 名称的影响 91
12.2.1 一个命名的证明 92
12.2.2 命名完成了什么？ 92
12.3 启发式命名方法 93
12.4 有益的提示和变化 94
12.5 总结 94
13 面临冲突时推动进程 95
13.1 处理无关紧要的冲突 95
13.1.1错误的时间，错误的项目 95
13.1.2 个性冲突 96
13.1.3 必不可少的人 96
13.1.4 组内的偏见 96
13.1.5 级别不一样 97
13.2 注意力完全集中的技巧 97
13.3 处理本质的冲突 98
13.3.1 重塑个性差异 98
13.3.2 协商 99
13.3.3 处理政治冲突 99
13.4 有益的提示和变化 100
13.5 总结 100
第四部分 明确期望 102
14 功能 103
14.1 定义功能 103
14.1.1 存在功能 103
14.1.2 测试功能 103
14.2 记录所有且唯一的功能 104
14.2.1 记录所有潜在的功能 104
14.2.2 理解明显的、隐藏的以及装饰性的功能 105
14.2.3 识别未注意到的功能 106
14.2.4 避免隐含的解决方案 107
14.2.5 "如果你能够就实现它"列表 107
14.3 有益的提示和变化 108
14.4 总结 108
15 属性 110
15.1 属性的愿望列表 110
15.2 改变愿望列表 111
15.2.1 区分属性和属性细节 111
15.2.2 揭示属性的含混性 111
15.2.3 组织列表 112
15.2.4 从改变后的列表揭示内幕 112
15.3 为功能分配属性 113
15.3.1 属性如何修改功能 113
15.3.2 从新格式中获取内幕 113
15.4 去掉属性 113
15.4.1 将属性分类为必须，需要和忽略 113
15.4.2 隐式和显式地排除属性 114
15.5 有益的提示和变化 114
15.6 总结 115
16 约束条件 116
16.1 定义约束 116
16.2 考虑作为边界的约束 116
16.3 测试约束 118
16.3.1 过于严格？ 118
16.3.2 不够严格？ 118
16.3.3 不清楚吗？ 119
16.3.4 产生新的想法 119
16.4 相互关联的约束 119
16.5过度约束 120
16.6 心理约束 120
16.6.1 倾斜观念 121
16.6.2 打破约束 121
16.6.3 自负与糟糕设计的循环 122
16.7 约束产生自由 122
16.7.1 标准 122
16.7.2 语言和其他工具 122
16.8 有益的提示和改变 123
16.9 总结 124
17 优先级 125
17.1定义优先级 125
17.1.1一个例子 126
17.1.2 优先级的来源 126
17.2 让优先级可量化 126
17.2.1 针对度量的合理方法 126
17.2.2让优先级可量化 127
17.3 区别约束和优先级 127
17.3.1 满足进度是约束吗？ 127
17.4 受到约束的优先级 128
17.4.1 它值什么图（what's-it-worth?graphs） 129
17.4.2 什么时候你需要它图（when-do-you-need-it?graph） 129
17.5 重新将约束定制为优先级 130
17.5.1 在优先级之间交易 130
17.5.2 产品开发的决定律 131
17.6 有益的提示和变化 132
17.7 总结 132
18 期望 134
18.1 限制期望的原因 134
18.1.1 人们不是完美的 134
18.1.2 人们并不都是有逻辑的 134
18.1.3 人们对事情的感受不一样 135
18.1.4 设计者也是人 135
18.2 采用期望限制过程 136
18.2.1 产生专门的期望列表 136
18.2.2 电梯的例子 136
18.2.3 产生期望列表 137
18.2.4 限制期望 138
18.3 限制条件不必被限制 138
18.3.1 轮椅的例子 138
18.3.2 让可能性保持公开 139
18.3.3 包括限制的来源 139
18.4 有益的提示和变化 139
18.5 总结 140
第四部分 极大地增加成功的可能 141
19 含混性度量 142
19.1 测量含混性 142
19.1.1 使用含混性投票 142
19.1.2 使用投票方法 143
19.1.3 在不同的基础上投票 143
19.2 将度量作为测试 143
19.2.1 度量三类含混性 143
19.2.2 解释结果 144
19.2.3 通过聚类得来信息 144
19.2.4 选择被投票的人群 144
19.3 有益的提示和变化 145
19.4 总结 145
20 技术评论 146
20.1 一个走过场的例子 146
20.2 技术评论的角色 148
20.2.1 正式和非正式的评论 148
20.2.2 技术评论与项目评论 148
20.3 评论报告 149
20.3.1 评论报告所需的东西 149
20.3.2 创造问题列表 150
20.3.3 技术评论总结报告 150
20.4 评论的主要类型 151
20.4.1 香草评论 151
20.4.2 检查 152
20.4.3 预演 152
20.4.4 联名声明评论 152
20.5 真实与理想的评论 152
20.6有益的变化和提示 153
20.7 总结 153
21 衡量满意度 154
21.1 创建用户满意度测试 154
21.1.1 测试属性 154
21.1.2 为每个项目采取的客户测试 154
21.2 使用测试 155
21.2.1 好处 155
21.2.2 绘制改变和趋势 156
21.2.3 解释评论 156
21.2.4 感觉就是事实 156
21.3 测试的其他用处 157
21.3.1 交流工具 157
21.3.2 贯穿项目的持续作用 158
21.3.3 对设计者的用处 158
21.4 其他测试 158
21.4.1 原型作为满意度测试 158
21.5 有益的提示和变化 159
21.6 总结 160
22 测试用例 160
22.1 黑箱测试 160
22.1.1 外部与内部的知识 160
22.1.2 构建黑箱测试用例 161
22.1.3 测试这些测试用例 162
22.2 应用测试用例 162
22.2.1 示例 162
22.2.2 反复测试和回答 163
22.2.3 清晰地指明含混性 164
22.3 以测试用例为证 164
22.4 有益的提示和变化 165
22.5 总结 166
23 学习已存在的产品 166
23.1 把现存产品当作标准来使用 166
23.2 访谈 167
23.2.1 新产品中有什么不见了？ 167
23.2.2 为什么不见了？ 167
23.2.3 在旧产品中遗漏了什么？ 168
23.2.4 在旧需求中遗漏了什么？ 168
23.3 用特征代替功能 169
23.4 有用的提示和变化 170
23.5 小结 170
24 达成协议 171
24.1 决策从哪里来 171
24.1.1 选择，假设和强迫接受 171
24.1.2 电梯设计决策的例子 171
24.1.3 撰写可追溯的需求 172
24.2 错误假设从哪里来 173
24.2.1 有效信息的缺乏 173
24.2.2 超时失效 173
24.2.3 收费公路效应 173
24.2.4 需求渗漏 174
24.3 把决策转化为协议 174
24.4 有用的提示和变化 174
24.5 小结 175
25 结束 175
25.1 对结束的害怕 176
25.2 结束一切的勇气 176
25.2.1 自动化设计和开发 176
25.2.2 堆土窑方式 176
25.2.3 冻结需求 177
25.2.4 重新谈判过程 177
25.2.5 对做出清晰假设的害怕 177
25.3 不够格的勇气 178
25.4 有用的提示和变化 178
25.5 小结 179
参考文献 179
索引表 179
· · · · · · (收起)
具体描述
本書將與您一起尋找"什麼是客戶真正想要的"這一問題的答案。
本書著眼於係統設計之前的需求過程，它是整個開發過程（如何設計人們想要的産品和係統）中最有挑戰性的那部分。通過對一些需求分析中的常見誤區和問題的分析和討論，從和客戶溝通開始，深入研究一些可能的需求，澄清用戶和開發者期望值，最終給齣瞭能夠大幅度提高項目成功幾率的一些建議方法。
本書由該領域內公認的兩位作者閤著，搜集瞭他們在大大小小的公司裏加起來超過60年的在工作中發現、提煉和檢驗之後的觀點。在本書中描述的原則並不局限於軟件開發，還涉及到所有需要為彆人設計和製作産品的領域。這些技巧已經成功的應用於開發所有類型的産品和係統--包括計算機硬件和軟件、傢具、建築和書籍等等。
本書認為，開發是把人們的期望轉化成一種能夠滿足其期望的産品的過程。本書的討論圍繞著需求過程--在開發中人們試圖發現其期望的産品--的那一部分。通過對五個關鍵詞語"期望"、"産品"、"人們"、"試圖"和"發現"的層層分析，給齣瞭大量使用的技巧和觀點。 産品開發項目可能失敗的原因非常多，最糟糕的莫過於在需求過程帶入的缺陷。目前已有瞭很多書籍來闡述避免那些缺陷的方法，而本書則是集中在需求過程的以下三個危險而又被忽視的人性視角：
1． 在所有參與者中開發一種對需求的可靠的理解。
2． 開發一種項目的團隊工作期望。
3． 開發一些必要的技巧和工具以能夠有效的像團隊一樣來定義需求。
由於這些主題或多或少有些被有關係統開發的著作所忽略，《探索需求》可以用作對你當前的任何需求過程的一個補充，而不管其是否正式。本書的很多章節都設計成獨立的模塊，每一個都介紹瞭一到幾種用於提高需求技術的工具或方法。讀者可以逐頁閱讀本書，也可以在任何時間隻讀那些你最需要的章節。 全書通俗易懂、層次分明，其中共有上百幅插圖，便於讀者深入理解，是需求分析人員的入門和提高必備指南。
用户评价
评分
##做好需求分析，保证在设计前的质量
评分##翻译很烂，稍微有些过时。适合速读。
评分##翻译很烂，稍微有些过时。适合速读。
评分##绝对的经典！看之前没想到探索需求竟然自成体系，有这么多的方法、思想和工具。作者娓娓道来的需求探索中存在的各种问题是此书的精华，对于零基础的人可以借此构建对需求探索领域的基本认识。
评分##翻译很烂，稍微有些过时。适合速读。
评分我真没想到一本主题为“探索需求”的书可以写这么多，但这本书的确抓住了日常需求分析中最关键的问题：含混性。在互联网开发中时常出现这样的情况，老板提出了以一个需求，小弟们想了想的确是存在的，好！那就做吧。然后发现这个功能和需求差之甚远。这就是含混性。大部分时候，产品经理做出决断很简单，但其实在不断陷入自己设下的陷阱而不自知。
评分##翻译很烂，稍微有些过时。适合速读。
评分##尽管是从软件开发角度讲述客户需求，但也很有借鉴参考意义，尤其关于如何进行头脑风暴和如何开会部分更有普遍性。
评分##温伯格的研究方法违背了基本的心理学原理：心理捷径
相关图书
本站所有內容均為互聯網搜索引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2026 tushu.tinynews.org All Rights Reserved. 求知書站 版权所有