探索需求读后感锦集

《探索需求》是一本由章柏幸 / 王媛媛 / 谢攀 / 杰拉尔德・温伯格 / 唐纳德・著作，清华大学出版社出版的平装(无盘)图书，本书定价：39.00元，页数：362，特精心收集的读后感，希望对大家能有帮助。

《探索需求》读后感(一)：需求在哪里

如何发现需求以及验证需求，大概是每个产品经理都很关注的一个问题。

什么样的需求才算需求？应该向谁，以何种方式提出问题，才能得到关于需求的真实反馈？对于需求的描述是不是足够清晰？如何在探索需求的整个过程中避免含混性带来的影响？在讨论需求的会议上如何最大限度地发挥团队合作的能力？有人说产品经理的核心能力就是问出正确的问题，那么上面这些问题大概就是在探索需求的时候产品经理必须提出的问题了，而本书无疑在这个方面做出了很好的引导。

值得一提的是，这本书的内容很幽默，非常对我的胃口。

如果产品经理的大敌就是在挖掘和分析需求时的盲目、想当然、自以为是，那就真的要感谢上天派这本书来拯救我们了！

《探索需求》读后感(二)：找到客户真正的需要是一个不断求证的过程

这本书是站在软件开发的角度来探讨和分析如何确定客户的真正需求，但有些内容也可以作为软件销售和实施人员了解如何与客户沟通、探寻客户深层次的想法从而将项目更好地进行掌控，下面将书中个人感觉不错的三点做一下简要回顾和感想总结，更详细地可以去看原书，各人根据自己的工作不同可以选看书中相关章节：

决策树：这个决策树和实际的树相反，是倒立着的，如下图所示，它将客户含糊的问题描述作为树根，树的每一个分枝代表一次决策，树的叶子代表所有可能的解决方案，到底这棵树有几层，取决于是否彻底清晰化了问题从而有了答案。这个决策树建立的过程也是讨论、分析、验证、确认的过程，当我们与客户对照着这个决策树进行需求论证的时候，才是真正沟通效率最大化的过程，很多时候，我们仅仅觉得我们理解了客户的需求，或者以为客户理解了我们的解决方案，那都是停留在口头上和大脑中，决策树这个媒介的存在使双方的沟通有了校验的环节，使沟通更准确更顺畅。决策树可以让我们了解对应于客户模糊的需求我们探寻出的一片叶子是否是他想要的那片，理论上只有一片叶子存在于客户的脑海中，其它探寻出来的叶子只是我们所认为的“正确”答案而已，如果不是客户想要的则需要另辟分枝进行下一轮的探寻，以此类推直到双方达成共识。看到决策树的图形笔者感觉最匹配的工具就是思维导图软件，很多思维导图软件支持树形结构的展示，而且操作方便呈现直观。

自由提问：书中提到的自由提问我理解为更加开放式的基于全局的提问，而不是一味地追求是否的答案，或者细抠某些业务细节的打破沙锅问到底式追问，这个自由又是相对的跳跃，不能跑题太远，比如你可以问谁是项目的真正用户，然后又可以跳到对于这个用户，他认为什么才是成功的解决方案，听过了对方的描述，我们可以来验证心中想的答案和对方描述的有多少差异，从而进一步调整我们的答案逼近真正的解决方案，确认了对方的描述我们又可以来了解背后真实的原因是什么，即为什么要这样来解决，不解决有什么问题会产生或存在，从这个角度让客户也来反省到底需求是真需求还是伪需求，这样看似跳跃不连贯的提问反而更能激起客户沟通的欲望，也能让我们从整体上不因开始的可能错误方向而走进死胡同，及时做出调整。

头脑风暴：这种讨论方式近几年很流行，那头脑风暴是不是就是大家漫无边际天马行空地发表意见，当然不是，在书中有很详细的规则介绍，我们经常看到吵成一锅粥的探讨，外面不知道的人以为是在打架；我们也经常看到流程化、官方化的假头脑风暴，大家东扯一句西扯一句，几个小时的时间很快就过去了，但是结果却不知道还在哪里游荡。针对以上现象，作者给出了头脑风暴的几个原则，比如：

不打断别人讲话

穷尽每个人想法

限定每个人的讲话时间

围绕客户需求去开展工作，而不是基于开发者或设计者去想象“对应正确”的答案，选择比努力更重要，在这里也同样适用。

20151229

《探索需求》读后感(三)：面向实现的含混性

给本书评5星，并不是因为我觉得它写得很好，仅仅只是因为没有人比它写得好了。

本书和《你的灯亮着吗》可以看做是姐妹篇，虽然内容上看起来差别很大，但是它们实际上是一个有机的整体。温伯格在本书中着力介绍了降低需求含混性的各种方法，但实际上这些方法仅仅只能用来降低实现的含混性，至于另一方面的含混性的降低，就需要看《你的灯亮着吗》这本书了。

含混性，描述的是不清晰的程度。而对于软件开发来说，事实上含混性存在两个方面，其一就是本书讲的实现方式上的含混性；另一个就是对目标的含混性，即同样的需求可能对于完全不同的目标，而那些潜在的目标直接影响到软件（前卫一点说是服务）未来的演化方向。如果我们希望构造一个软件（或者服务），即能很好的满足用户当前的需求，又能使得我们未来可以比较方便的拓展这个软件（服务）的功能，比较方便的实现软件（服务）的演化，那么在这两方面都降低含混性，就可以很好的帮助我们实现目标。

科学的方法大多需要量化的度量技术，温伯格在本书中提供了一种方法，这也是我选择看这本书的原因。虽然他一开始就说他有这个公式，但是直到本书的最后，他才把这个公式给拿来出来：含混性==实现需求的最大花费/实现需求的最小花费。这个公式非常的好，特别是在报价时期，可以快速的确定是否还需要更详细的需求。如果需求过于抽象，那么这个公式给出的含混性就可能非常的大，而这种随意性很大的估值是非常忌讳的，很可能会造成亏本。

严格的进行分析，这个有利于估价的公式并不一定非常合适，决定含混性的，始终还是应该由实现相应需求的不同方案的数目来确定。含混性毕竟还是对这种实现的不确定性的度量。按照成本来度量，可能会存在两方面的问题，其一，许多不同的方案花费相差不大，在具体实现的时候可能会造成一些执行上的偏差，但是这种偏差在最开始度量的时候体现不明显；其二，虽然成本一般都是连续的对应着相应的解决方案，但是不排除少数解决方案之间存在大的成本跨度。这些大多主要影响到实现，不过确实也需要提前注意。

由于本书的年代比较久远，所以最近的一些新的开发思想和本书所提到的思想之间存在一些偏差的地方。本书着重强调的是通过不断的细化需求来最终减少实现的含混性，但是事实上这并非唯一的办法。

首先需要明白，需求是什么：

1.需求是一个屏蔽了底层实现的操作,它实现了状态的转换.(很抽象吧,那是当然的,因为我们平时说的根本就不是需求,而是另一个东西)

2.用户(提出)的需求是用户个人认为的对自身目标的最佳解决方案中,自己不能或者不愿意完成的部分,目标和解决方案具有相对性.

既然需求被这样定义，那么减少含混性的办法就有两条路，其一，正如书中写的一样，当我们发现存在比较大的歧义的时候，自己通过交流的方式来降低这种歧义；另一种，我们还可以拔高我们的底层实现。很多时候，歧异来自于我们自身一定强大的能力，因为我们有足够的能力做到多样性，而这些多样性都体现出各自的特点，所以我们才会有了如此众多不同的选择。如果这些实现办法最终所表现出来的效果差距不大的时候，是的，我们就可以把他们整合到一个平台上，利用这个平台屏蔽这些具体实现。那么向上来说，歧义被降低了；而向下来说，各种实现之间的差异大大的减小了，具体采取那种方式来实现平台的要求，也差不多无所谓了。对，这就是我们现在很多时候采用的方法。SOA，将底层实现的级别提升到了服务级别；又或者在模型转换中，在4个层次上向下屏蔽了各种有差别的实现。甚至在更早之前，汇编语言，C语言，面向对象语言，动态语言，都曾经提高过这种实现的级别。

未来我们将有机会高枕无忧吗？我们最终将彻底战胜面向实现的含混性吗？也许永远也不可能，因为我们的捆饶正来自于我们的能力，能力越大，梦想就越大，困难也就越大，同样的，我们提出需求的级别也在不断提高，需求与实现之间的差距并没有最终被弥合的可能性。因为向上含混性，是无解的。

《探索需求》读后感(四)：需求文档是一切么？

作为公司中的软件交付团队，如果你能有机会对软件生命周期的其中一个阶段进行改变，你最想改变的阶段是什么？

被访谈到的团队，几乎99%的都选择了需求分析阶段。

需求之痛，最痛包括以下：

如果打算改善需求分析阶段，你想如何来改变？ 这一次，很多同学都指向了一个解决方式：规范化流程，系统化需求文档。甚至大家为应该由哪一个角色来书写需求文档而争论不休。

我们怎么办，我们都很绝望啊

艾森豪威尔将军曾经对于Business Plan有过此经典的评价。

对于上面的解决方式来说，CC先生也想说一句： Documents are nothing,Documenting is everything 文档什么都不是，而编写文档的过程却是一切

对于含混性的理解，就像一千个读者眼里有一千个林黛玉（一般说哈姆雷特）一样。

比如对于以下一首小诗的解读：

黄克孙版译诗： 一箪疏食一壶浆，一卷诗书树下凉。

卿为阿侬歌瀚海，茫茫瀚海即天堂。

郭沫若版译诗： 树荫下放着一卷诗章，

一瓶葡萄美酒，一点干粮，

有你在这荒原中傍我欢歌——

荒原呀，啊，便是天堂！

还有好多的翻译范本。因为不同的译者的经验和能力，出来的翻译各有特色，需求的含混性也是如此。

人的记忆和思维方式各异，可能面对的是同一个用户的需求，不同的需求分析者得出来得用户画像也不尽相同。此时，单纯的追求需求文档的规范性和流程的系统化并不能很好的解决需求理解不一致的问题。

讨论需求文档的过程却是解决这一困局的有效方式。在对需求含混性的不断讨论中，至少团队对一个需求的理解会越来越趋向于一致。敏捷实践中的实例化需求就是一个消除需求含混性的有力手段，它并不能做到穷尽性的需求挖掘，它更大的作用在于促使团队针对需求的含混性、不确定性，不可量化的价值进行进一步的讨论。

Documents are nothing,Documenting is everything

希望下一次写需求文档的时候，大家不会再那么纠结。

《探索需求》读后感(五)：探索需求读书笔记

总结一下本书的要点，适合速读。

关于需求的书籍太少了，温伯格的《探索需求》是一本不错的关于需求的教材，对于深刻到社会学和心理学的软件需求工作，温伯格给出了很多实用的方法和技巧。正如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章 期望

事先诚实地表达过限制的问题，客户会更加容易接受产品和系统。

五、极大提高成功的可能性

需求是需要测试的。

含混性度量

技术复审

衡量满意度

测试用例

学习已存在的产品

达成协议

结束