有效需求分析读后感1000字

《有效需求分析》是一本由徐锋著作，电子工业出版社出版的其他图书，本书定价：CNY 69.00，页数：240，特精心收集的读后感，希望对大家能有帮助。

《有效需求分析》读后感(一)：说的清楚，讲得明白

读过几个小节后，感觉非常好，有点相见恨晚，正本书读起来轻松，没有那种靠专业词语，客话套话来显现自己，靠的是货真价实亲身经历，对业务流程，优化有自己独到之处，是做需求分析人不可多得参考资料。看过本书之后各种概念，要做的工作一清二楚，对实际工作有指导意义。个人强烈推荐，值得研究。大家可以把自己的读后感一起来分享。聊聊如何做好需求分析。

《有效需求分析》读后感(二)：有效需求分析 | 从问题到产品

之前无知的认为，产品设计是一件简单的工作。

现在真正从事需求分析和产品设计工作时，才发现并不是那么回事。

产品经理门槛看起来并不高，可谓“人人都是产品经理”，但想做到优秀，确实有些难度。

我想有个××功能，你帮我实现？

我碰到这样的问题，你给出个解决方案？

我们想做一个××系统，你看怎么弄？

…………

以上问题是不是经常在工作中遇到？

有时候真是一头雾水，不知从哪着手。

这个问题的真实需求到底是什么？这个系统我该怎么设计？

这本书给了我一个很好的答案。

从问题，到系统，到业务流程、场景、接口，再到数据、质量需求，从大到小，层层递进，让你由上而下，从产品架构上有了比较清晰的把握。

总之，这本书，可实操、可落地。有干货。

《有效需求分析》读后感(三)：如何做好有效需求分析

这是一本从事产品行业的必读书籍，无论你是初入职场的小白，还是久经沙场的专家，想必都能通过此书获取到不同凡响的收获和共鸣。

对于行业小白，这本书为你描绘了一名优秀的产品经理应该具备的能力，也把你提前识别了将来可能遇到的挑战，但更重要的是这本书梳理了需求分析的核心框架及可落地的操作工具。

对于行业老鸟，这本书帮你重新复盘了需求分析中各种经验和教训，也通过作者自己的感悟和体会梳理了不同场景的应对方案，当你回过头来重新审视过去或当前正在面对的需求问题时，或许你会不禁“啊哈”一下，原来是这样啊！

至少对我而言，这部书的启发意义还是极为显著的，至少包括以下方面：

作为B端产品设计，我们在识别业务不同场景下的复杂问题时，不如从这4点做下思考和对齐，通常意义上，提效是任何工具类系统或业务管理系统的核心目标；除外面向不同的执行角色，赋能可以帮助他们实现线上作业和管理；当然对于平台而言，业务流程中的数据也是不可忽视的价值；最后也是最具挑战的便是业务管理数字化，因为这要求业务体系中的所有对象、流程、制度和标准都需要被系统记录和驱动，数字化的背后是业务流程的再造，是管理思维的升级，是对人性的遵从而不是压制！

这是一个初级产品或需求分析师常犯的错误，当我们面对一个具体的业务需求时，往往容易被动地陷入这个需求的实现评估过程，殊不知这是一个巨大的陷阱，不仅会造成需求识别的偏误，更会导致大量的无用功。因此需求识别的关键动作就是要挖掘业务需求的真相，变方案级需求为问题级需求。当然，要做到这一点除了要求我们有专业的需求识别能力，也要求我们对业务有更深刻的理解和体感，这是产品能力的体现。

思维方式和视角的转变对一名优秀的产品而言是极为重要的，当我们习惯性的将业务需求带入到实现评估过程中时，其实就已经犯了混淆方案级需求的错误了，因此为了消除这种固化的思维模式，我们需要刻意训练自己对业务价值和场景的理解，通过与需求人员的反复对话和追问，不断识别其背后的业务诉求和实际场景，刨根问底、不耻下问或许能为你和需求方共同打开一片新天地，在那里或许才是你们真正找寻答案的地方。

既然我们已经意识到了思考视角转变的重要性，我们就需要在遵循照做的过程中坚持某些原则，这其中就包括我们需要深入问题场景，体察用户的感受，了解用户的目标，因为通过这个方法可以帮助我们建立起和用户的共情，从而找到那些被忽视的线头，从而串联起真正的需求主线。同时在这个过程中，我们可以基于主线去梳理核心问题，而将那些与主线无关的噪音和冗余信息剔除，毕竟做减法是为了专注，而无效的加法只会自欺欺人。

实质上这是一种场景化的思维训练，组织在制定业务目标时往往是一个代表某种业务结果达成的指标，但指标本身可能是许许多多生产关系所决定和造就的，它可以代表某种相关性，但或许无法证明因果性，所以我们除了设定业务指标，也可以在需求早期界定时就规划好其如何帮助不同业务角色在场景中解决问题，达成场景目标，相较于静态的指标，这样的描述会显得更生动，也更有指向性，有助于驱动项目相关人员推动需求的达成。

这里提到的本质还是业务视角和思维的养成方法，我们需要珍惜每一次和业务方对话的机会，了解他们的话术风格，表达框架和思考维度，切忌用一些所谓的产品术语去体现自己的专业，放低姿态是为了能更好地收集信息和搭建顺畅的沟通渠道，唯有这样才能真正借助自己的专业去解决业务问题，当然我们在过程中除了对齐语言体系，还要尽可能的利用VOC、统计数据等去建立表达的客观性，最后我们对问题的识别和分析务必要匹配客户的视角，这也是保证我们的分析和判断不会偏离轨道的关键检验方法。

在识别场景化的业务问题时，我们需要识别不同的业务角色及其核心的诉求，正向需求能帮助我们了解用户迫切想要的，可以通过系统赋能支持的部分；负向需求能帮助我们洞察用户担忧焦虑的，需要系统在上线后尽量规避和减少影响的部分，负向需求的识别往往需要配合运营计划，包括用户培训、宣导、制度激励和绩效考核等。如果只有正向而忽略了负向需求的识别，极容易导致需求上线或使用与预期不符，结果不达标等问题。

作为一个B端的业务系统或者产品工具，通常我们说的优化不外乎上面这4类：清除无效指的是剔除流程中的冗余节点，即充分遵循“奥卡姆剃刀原则”（如非必要，勿增实体）；简化高频指的是针对流程中的高频节点，通常也容易成为业务卡点，我们需要不断提升自动化能力，简化人工操作，提升效率；整合依赖指的是将流程节点中的上下游中相互依赖的部分识别出来，通过系统校验和数据流转，实现跨节点的整合，同样提升流程效率；自动化繁琐顾名思义，指的是将流程节点中业务规则复杂、策略判定繁琐的部分单独抽离出来，结合算法、人工智能等技术能力逐步迭代为自动化处理的效能工具，大幅提升流程智能化能力。

人机交互和人机界面的核心差异在于：前者通过情感化的界面交互驱动用户行为，同时在界面设计的过程中也更关心用户的心理活动，期望通过友好的交互引导简化用户的思考和犹豫过程，使其更顺畅平滑的进行作业活动。

用户意图和用户动作的核心区别在于：前者是遵循用户的内心和意愿，后者以管理和规范着手约束用户行为，好的产品设计一定是在用户主动意愿和平台规范管理之间找到合理的平衡点，通过巧妙的制度和策略设计令用户接受甚至有意愿地去执行。

无论是流程图还是用例图，都是产品需求分析和问题识别过程中的有效工具，用例图能帮助我们构建更具体的对象-场景关系，详尽的用例图能让我们还原真实业务场景中的复杂生产关系，有利于后续的方案设计和完善；流程图能将业务的生产活动通过不同对象/组织间的串联完整地表述出来，能帮助我们洞察到当前问题的全局流程、上下游依赖和组织间的联动关系，在向上汇报和管理决策时，更有助于识别作业流程以外的问题，包括组织设计、角色分工、资源分配不均等

《有效需求分析》读后感(四)：做好需求，少走弯路

最近在一个技术群里看到张逸大佬强力推荐一本关于需求分析的书《有效需求分析》，于是在 Kindle 上下单了，读完后有一种相见恨晚的感觉。

从书中的一些案例可以看出，作者擅长 ToB 软件的需求分析，如果您是从事的 ToB 软件的相关工作，那阅读本书时会有更多的共鸣。

书中有大量的案例，阅读起来不仅不枯燥，反倒觉得挺有意思，特别是一些日常生活中例子，能引发我们更多的思考。

每一个章节都有能落地的产物输出，所有的产物整合在一起就是完整的需求文档，可以让你不仅知道一些理论，还知道怎么落地。

1、辛辛苦苦开发的系统，跟客户演示的时候达不到客户的预期；

2、上线后，客户反复提出“变更”，从客户视角来看是功能没有按要求完成，从开发的视角感觉客户在百般刁难；

3、边界难以控制，已经按照“要求”完成了，客户还不断提出新的东西。

读完这本书可以立即解决这些问题吗？答案肯定是不能，但能给我们带来启发和思考，能让我们在解决这些问题的路上往前迈进一步。

书中的内容不少，本文只是我结合自己的认知把觉得重要的点展开来说说。

什么是需求？书中给出了一个非常精炼的回答：现实和期望之间的差距。就是中间这个差距需要我们去思考、调研，这是一个迭代的过程，直到最后达到期望甚至超过期望，如果用了一些错误的方法，或者被客户牵着鼻子走，最后结果可能还不如现实。

开篇例举的一个生活中的小例子充分说明了什么是需求，什么是方案：

如果客户的接口人稍微懂点技术，在做需求调研时就很容易提出方案级的需求，这时就需要警惕了，需要用一些问题来深挖背后的真实需求，比如：

如果能挖到真实的需求，就可以根据情况来制定最优方案了。如果我们“完美”地满足了客户提出的“方案级需求”，最终的结果未必能让客户满意，客户通常善于发现问题，提出问题，但给出的方案往往不能完美解决问题。

在公司的内部其实也存在着这种问题，比如项目团队的同事在遇到产品满足不了的功能时，需要给产品提需求，经常看到的需求描述是：

这些都是方案，而不是需求，项目的同事根据自己的理解和认知完成了从需求到方案的转换，而这个方案很多时候并不是最优。

所以每每收到这种“需求”时，会马上跟项目的同事反复确认客户到底想要什么，了解到真实背景后，才能结合产品的功能给出合适的解决方案。

任何企业准备上一套系统有各种各样的原因，可能是为了提高生产效率、提高协同办公效率，也可能是为了做一些政绩。所以针对不同的场景，我们首先需要找出这个系统的相关干系人。

识别干系人有几个重要的判断标准：

如果能够准确的识别关键关系人，还需要对关系人进行分析：

做项目不光是要做好事，关键还要能搞定人，能让重点干系人感受到系统的价值，项目就容易成功。

我认为项目的前期最核心的就是上面两个步骤：挖出核心诉求和找出重点干系人。剩下的就是分解需求进行开发实现了。不同的团队对需求分解和开发实现肯定都有适合自己的方式和方法，具体可以去阅读本书，下面说说在项目需求调研过程中经常会忽略的非功能性需求。

非功能性需求通常指，安全性、性能、扩展性、稳定性等等，这些非常重要，但也是最容易被我们忽视掉的。

非功能性需求针对不同的客户或系统会有不同的侧重点，比如：

这些非功能性的需求在调研阶段应该和功能性需求一起同步进行，根据客户的特征进行分析和识别，最终作为开发交付的一个检查项进行检查。

上面列举的都是和系统本身相关的一些要求，除此之外，还有很多的外在因素也是在前期调研时就应该考虑的，比如：

现在各种各样的书籍琳琅满目，感兴趣的书买了，就有机会去阅读，这是我一直以来的一个观点，做需求每个项目负责人都有自己的方法，但多读书学习一些方法和技巧，没准哪天就能用上了。再说了，多读书，往上可以提升我们的格局和眼界，往下也能夯实和固化我们的能力。