《探索需求》读书笔记
关于需求的书籍太少了，温伯格的《探索需求》是一本不错的关于需求的教材，对于深刻到社会学和心理学的软件需求工作，温伯格给出了很多实用的方法和技巧。正如UML China所评，“本书是现代需求技术的基石”。
读书笔记：
如果我们都不知道自己的所作所为能给社会或自己带来什么，那么技术是毫无价值的。
明白自己在做什么，是走向成功的必要条件。那些能够很早地领会或感悟到自然发展、社会发展、人类发展、行业发展、软件发展在很长一段时间内的可能趋势的先知先觉者，虽然在这个世界上不到万分之一，但是他们是时代的智者，只要他们愿意去做，他们就能够很快地获得成功。他们具有非常敏感的嗅觉和洞察力，能够很好地把握未来几年的软件需求，从而进行应用解决方案的设计、前卫体验理念的构建。或者说，他们能够在行业内把握方向，技术上突破，特别是在一些尚未发掘的领域异军突起。他们属于时代或行业的领导者，其成功一半是天才，一半是勤奋。
一.讨论一个共识
对需求的描述是很难的，绝大多数客户并没有清楚地告诉程序员他们想要什么。
第1章 方法论是不够的
映射图最重要的特性是使所有相关人员都能够理解。
但是，需求的映射图并不是真正的需求。
因为我们使用的通常都是需求映射图，而不是需求本身，这就是需要“探索”的原因。人们探索制作映射图，最终得到一张足够接近实际形态的映射图，并为了一个“现实的”目的把它表达出来。
第2章 在陈述需求中的含混性
攻击含混性是因为含混性需要成本。
尽可能早地攻击含混性，因为即使你最终消除了它，在产品开发的早先阶段改正所需要的成本要比以后改正的成本少很多很多。
如何攻击含混性是全书的主题。但首先，一定要记住用一种非常有趣的方法来使用你的智慧－探索应该是一种乐趣。
探索的基本步骤：1、向某个方向移动；2、看看在那里发现了什么；3、记录所发现的东西；4、有目的地分析所发现的东西；5、通过对所发现东西的分析和记录选择下一个方向；6、跳回到第1步，继续探索。
第3章 含混性的来源
来源：解释和回忆错误；问题陈述的含混性。
试着逐字回忆需求或问题陈述，这将能够揭示那些必须在一个成功的需求被开发出来之前清除掉的含混性。
第4章 可靠但不真实的直接问题的方法
直接提问没有什么错。甚至如果你期望成为一名胜任的设计员，最好掌握直接提问、直接观察和常规的面谈技巧。然而，还是有一些主题在某个地方好好地隐藏着……
我们，作为常人，并不擅长发现我们已经忽略的东西。
你需要其他的工具和技术来辅助直接提问，因为为了获得成功，完全直接提问的方法将需要一个完美的人。
决策树模型是一个用于辅助直接提问的显著的工具。
二.开始之路
第5章 切入点
问题的最佳定义是：感受到的事情和期望的事情之间的差别。这个定义可以作为一个模板来衡量启动开发项目的每一个想法。
最常用的切入点有可能是对某个解决方案的考虑，却又陈述不清该方案到底将要解决什么问题。
第二是手头有一个解决方案，需要通过这个解决方案来寻找问题所在。
第三是许多产品的开发源于多种比喻性思考。
还有标准、实体模型和名称。
减缓切入阶段的进展，去调查需求，仔细考虑需求，就像禅宗所说的要尽可能地保持一个“初学者的念头”。对于初学者而言，所有的事物都是平等的、新奇的。
第6章 自由问题
自由提问让你在设计过程中找到那些有关全局的问题，这样你就能够进入正确的方向而远胜于孤立无援。
一些常用的自由问题：
谁是客户？
对该客户而言，什么样才成为非常成功的解决方案？
解决该问题的真实原因是什么？
我们是否建立单独的设计团队，或者是多余一个的团队？
团队成员应包括哪些人？
我们会有多少时间来做这个项目？
项目开发时间和价值的平衡是什么？
关于这一设计问题的解决方案我们还能在什么地方获得？
我们可以复制一些已有的资料吗？
这个系统解决了什么问题？
这个系统会带来什么问题？
这个系统最有可能遇到的环境是什么？
我们需要或期望这个产品有什么样的精确程度？
万一要是这次有什么漏掉的内容，以后我可以再来或给您打电话问一些问题吗？
第7章 找到正确的相关人员
客户和用户
采用一种包含用户的策略和计划以保证所有用户都始终如一地处理了。
做法：1、相信在需求开发团队中必须有负责的包含用户的策略，这样远比任其自然好。2、集体讨论一个潜在用户列表。3、通过把他们分类成友好的、不友好的、客户略的三类来简化列表。4、使用参与者的三位坐标，为每个你不想忽略的用户群制作一个对策。5、执行你的参与计划，用你的想象力和机智去获得你所需要的全部参与。
第8章 为每个人准备工作会议
由于其在探索需求中的重要地位，会议必须像其他的工具一样来考虑：设计它们，适当地选择它们，在使用时训练每个人，然后就是练习，练习，再练习。
第9章 自始至终降低含混性
含混性是需求定义中的一个重要问题，而启发则是降低含混性的有力工具。
记忆启发：不同的人都试图精确地根据记忆回顾问题的描述。对于那些不能够很好地回忆起来的地方很可能是含义不清楚的。
玛丽从前有一只小羔羊的启发：把问题描述大声地朗读几次，每次重读不同的字或词语，直到发现尽可能多的解释为止。
玛丽欺骗商人的启发：确定在问题描述中起重要作用的词，然后列出其所有可能的解释。再把这些定义混合配对来组成另外的解释。
三、探索机会
需求的过程不是线性的，而是围绕目标转圈，一点一点地接近。
第10章 产生想法的会议
头脑风暴：不许批评和责备；让想法自由飞翔；想法越多越好；更改和合成想法。
第11章 右脑方法
为了记录我们在需求过程中所处的位置，我们需要使用映射图。因为大多数有效的映射图都是可视化的，所以我们如果能够激发我们的右脑，那么可以用于减少含混性方面的方法就会扩大一倍。
探索来源于开发者的处理对象是需求的映射图，而不是需求本身。我们探索是为了制作映射图，而且最终我们制作了一张能够和地图非常接近的地图，以满足实际的目的。
第12章 项目的名称
名称总会被重复使用，它们容易章控思想。如果它们被误解或者具有含混性，那么就会成为麻烦的起点。
启发式命名：1、提出一个名称；2、给出三个该名称不不合适的原因；3、提出另一个可以消除这三个问题的名称；4、重复这个命名过程，知道你找到一个可用的名称为止。
第13章 面临冲突时推动进程
每一个项目都会经历冲突，如果没有某种推动力的话就很难成功消除它。
作为一个好的推动者，你必须发展注意力完全集中的艺术——随时随地关注，随时随地发问，随时随地评价，但是要比大猩猩温柔一点。
四、明确期望
第14章 功能
通常，获取信息的过程中第一步就是定义功能。
功能启发式方法：1、通过头脑风暴，开发潜在功能的原始列表；2、区分开每一种功能为明显、隐藏和装饰性三类；3、利用这个分类结果，努力揭示没有提到的隐藏功能；4、当你进行分类时，寻找暗示了一些解决方案的限制条件的功能描述，并且将这种措辞转变为问题的描述，而非解决方案的描述；5、为装饰性功能创建如果你能够就是现它的功能列表。
第15章 属性
属性是客户希望的特征。
头脑风暴产生属性的愿望列表。
第一次列出功能列表后就为功能分配属性。
将属性分为必须、希望和忽略。
第16章 约束条件
仅当属性已经被完全制定并分类后再制定约束。
第17章 偏好
偏好是附加在属性上的一种愿望，但却是可选择的条件。任何一个满足了所有约束条件的最终解决方案都是可以接受的，但其中某些可接受的解决方案可能更符合某些人的胃口。偏好这个概念使得设计者把那些可接受的方案进行比较，并从中选出较好的。
偏好来自于用户，而不是设计者。
第18章 期望
事先诚实地表达过限制的问题，客户会更加容易接受产品和系统。
五、极大提高成功的可能性
需求是需要测试的。
含混性度量
技术复审
衡量满意度
测试用例
学习已存在的产品
达成协议
结束
读书笔记：
如果我们都不知道自己的所作所为能给社会或自己带来什么，那么技术是毫无价值的。
明白自己在做什么，是走向成功的必要条件。那些能够很早地领会或感悟到自然发展、社会发展、人类发展、行业发展、软件发展在很长一段时间内的可能趋势的先知先觉者，虽然在这个世界上不到万分之一，但是他们是时代的智者，只要他们愿意去做，他们就能够很快地获得成功。他们具有非常敏感的嗅觉和洞察力，能够很好地把握未来几年的软件需求，从而进行应用解决方案的设计、前卫体验理念的构建。或者说，他们能够在行业内把握方向，技术上突破，特别是在一些尚未发掘的领域异军突起。他们属于时代或行业的领导者，其成功一半是天才，一半是勤奋。
一.讨论一个共识
对需求的描述是很难的，绝大多数客户并没有清楚地告诉程序员他们想要什么。
第1章 方法论是不够的
映射图最重要的特性是使所有相关人员都能够理解。
但是，需求的映射图并不是真正的需求。
因为我们使用的通常都是需求映射图，而不是需求本身，这就是需要“探索”的原因。人们探索制作映射图，最终得到一张足够接近实际形态的映射图，并为了一个“现实的”目的把它表达出来。
第2章 在陈述需求中的含混性
攻击含混性是因为含混性需要成本。
尽可能早地攻击含混性，因为即使你最终消除了它，在产品开发的早先阶段改正所需要的成本要比以后改正的成本少很多很多。
如何攻击含混性是全书的主题。但首先，一定要记住用一种非常有趣的方法来使用你的智慧－探索应该是一种乐趣。
探索的基本步骤：1、向某个方向移动；2、看看在那里发现了什么；3、记录所发现的东西；4、有目的地分析所发现的东西；5、通过对所发现东西的分析和记录选择下一个方向；6、跳回到第1步，继续探索。
第3章 含混性的来源
来源：解释和回忆错误；问题陈述的含混性。
试着逐字回忆需求或问题陈述，这将能够揭示那些必须在一个成功的需求被开发出来之前清除掉的含混性。
第4章 可靠但不真实的直接问题的方法
直接提问没有什么错。甚至如果你期望成为一名胜任的设计员，最好掌握直接提问、直接观察和常规的面谈技巧。然而，还是有一些主题在某个地方好好地隐藏着……
我们，作为常人，并不擅长发现我们已经忽略的东西。
你需要其他的工具和技术来辅助直接提问，因为为了获得成功，完全直接提问的方法将需要一个完美的人。
决策树模型是一个用于辅助直接提问的显著的工具。
二.开始之路
第5章 切入点
问题的最佳定义是：感受到的事情和期望的事情之间的差别。这个定义可以作为一个模板来衡量启动开发项目的每一个想法。
最常用的切入点有可能是对某个解决方案的考虑，却又陈述不清该方案到底将要解决什么问题。
第二是手头有一个解决方案，需要通过这个解决方案来寻找问题所在。
第三是许多产品的开发源于多种比喻性思考。
还有标准、实体模型和名称。
减缓切入阶段的进展，去调查需求，仔细考虑需求，就像禅宗所说的要尽可能地保持一个“初学者的念头”。对于初学者而言，所有的事物都是平等的、新奇的。
第6章 自由问题
自由提问让你在设计过程中找到那些有关全局的问题，这样你就能够进入正确的方向而远胜于孤立无援。
一些常用的自由问题：
谁是客户？
对该客户而言，什么样才成为非常成功的解决方案？
解决该问题的真实原因是什么？
我们是否建立单独的设计团队，或者是多余一个的团队？
团队成员应包括哪些人？
我们会有多少时间来做这个项目？
项目开发时间和价值的平衡是什么？
关于这一设计问题的解决方案我们还能在什么地方获得？
我们可以复制一些已有的资料吗？
这个系统解决了什么问题？
这个系统会带来什么问题？
这个系统最有可能遇到的环境是什么？
我们需要或期望这个产品有什么样的精确程度？
万一要是这次有什么漏掉的内容，以后我可以再来或给您打电话问一些问题吗？
第7章 找到正确的相关人员
客户和用户
采用一种包含用户的策略和计划以保证所有用户都始终如一地处理了。
做法：1、相信在需求开发团队中必须有负责的包含用户的策略，这样远比任其自然好。2、集体讨论一个潜在用户列表。3、通过把他们分类成友好的、不友好的、客户略的三类来简化列表。4、使用参与者的三位坐标，为每个你不想忽略的用户群制作一个对策。5、执行你的参与计划，用你的想象力和机智去获得你所需要的全部参与。
第8章 为每个人准备工作会议
由于其在探索需求中的重要地位，会议必须像其他的工具一样来考虑：设计它们，适当地选择它们，在使用时训练每个人，然后就是练习，练习，再练习。
第9章 自始至终降低含混性
含混性是需求定义中的一个重要问题，而启发则是降低含混性的有力工具。
记忆启发：不同的人都试图精确地根据记忆回顾问题的描述。对于那些不能够很好地回忆起来的地方很可能是含义不清楚的。
玛丽从前有一只小羔羊的启发：把问题描述大声地朗读几次，每次重读不同的字或词语，直到发现尽可能多的解释为止。
玛丽欺骗商人的启发：确定在问题描述中起重要作用的词，然后列出其所有可能的解释。再把这些定义混合配对来组成另外的解释。
三、探索机会
需求的过程不是线性的，而是围绕目标转圈，一点一点地接近。
第10章 产生想法的会议
头脑风暴：不许批评和责备；让想法自由飞翔；想法越多越好；更改和合成想法。
第11章 右脑方法
为了记录我们在需求过程中所处的位置，我们需要使用映射图。因为大多数有效的映射图都是可视化的，所以我们如果能够激发我们的右脑，那么可以用于减少含混性方面的方法就会扩大一倍。
探索来源于开发者的处理对象是需求的映射图，而不是需求本身。我们探索是为了制作映射图，而且最终我们制作了一张能够和地图非常接近的地图，以满足实际的目的。
第12章 项目的名称
名称总会被重复使用，它们容易章控思想。如果它们被误解或者具有含混性，那么就会成为麻烦的起点。
启发式命名：1、提出一个名称；2、给出三个该名称不不合适的原因；3、提出另一个可以消除这三个问题的名称；4、重复这个命名过程，知道你找到一个可用的名称为止。
第13章 面临冲突时推动进程
每一个项目都会经历冲突，如果没有某种推动力的话就很难成功消除它。
作为一个好的推动者，你必须发展注意力完全集中的艺术——随时随地关注，随时随地发问，随时随地评价，但是要比大猩猩温柔一点。
四、明确期望
第14章 功能
通常，获取信息的过程中第一步就是定义功能。
功能启发式方法：1、通过头脑风暴，开发潜在功能的原始列表；2、区分开每一种功能为明显、隐藏和装饰性三类；3、利用这个分类结果，努力揭示没有提到的隐藏功能；4、当你进行分类时，寻找暗示了一些解决方案的限制条件的功能描述，并且将这种措辞转变为问题的描述，而非解决方案的描述；5、为装饰性功能创建如果你能够就是现它的功能列表。
第15章 属性
属性是客户希望的特征。
头脑风暴产生属性的愿望列表。
第一次列出功能列表后就为功能分配属性。
将属性分为必须、希望和忽略。
第16章 约束条件
仅当属性已经被完全制定并分类后再制定约束。
第17章 偏好
偏好是附加在属性上的一种愿望，但却是可选择的条件。任何一个满足了所有约束条件的最终解决方案都是可以接受的，但其中某些可接受的解决方案可能更符合某些人的胃口。偏好这个概念使得设计者把那些可接受的方案进行比较，并从中选出较好的。
偏好来自于用户，而不是设计者。
第18章 期望
事先诚实地表达过限制的问题，客户会更加容易接受产品和系统。
五、极大提高成功的可能性
需求是需要测试的。
含混性度量
技术复审
衡量满意度
测试用例
学习已存在的产品
达成协议
结束
