在本章中，我们将深入探讨所谓的“业务”或“产品”需求，这些需求可以应用于任何类型的开发工作，而不受技术栈的限制。它们是系统的核心与灵魂，是我们了解应用程序时的第一要素。**需求决定了产品的运行机制。**毕竟，如果我们要开发软件，必须要有一个明确的理由。
需要理解的一点是，软件开发的最佳实践并不仅仅存在于开发的中后期，而是从我们开始构思项目之初就已经介入。
因此，在本章中，我们将首先明确我们要解决的问题，然后再开始清晰地阐述这些问题的解决方案。
以下是本章将涵盖的内容：
- 用 Spring 框架释放你的潜力
- 本书是如何帮助你成功的？
- 为什么我们需要理解业务需求？
- 明确无误的需求——确保企业正确把握需求
- 产品需求中的常见陷阱
业务需求的世界充满了值得挖掘的洞察。当我深入探索时，惊讶地发现能从以往的经验中提炼出许多宝贵的知识。如果忽略这些，可能会导致时间、金钱和精力的浪费。想象一下，你在建造梦想中的房子，但没有设计蓝图，这听起来是不是很冒险？这正是软件的蓝图——需求——的重要性所在。
用 Spring 框架释放你的潜力
理解 Spring 框架在当今后端开发中的重要性至关重要。它是目前最有价值的工具之一。
它的声望很大程度上归功于其建立在 Java 虚拟机（JVM）之上，而 JVM 是拥有 30 多年历史、成熟度极高的技术基石。
JVM 与 Java 编程语言共同打造了一个强大的软件开发平台，原因包括以下突出特点：
- 编译后的包具有跨操作系统的通用兼容性
- JVM 字节码几乎可以在任何硬件上运行
- Java JIT 编译器在运行时将字节码优化为本地代码，提供接近 C 语言程序的高性能，同时避免了内存管理的复杂性
- 拥有庞大的全球开发者社区
- 持续的支持和年度更新
- 顶级 IDE 的支持，为开发者提供卓越的开发体验
这些只是 Java 和 JVM 强大之处的冰山一角，而这也是 Spring 框架享有盛誉的原因之一。
Spring 专家在市场上供不应求，未来也是如此。
此外，Spring 生态系统已经确立了它作为最有益、实现最快、最容易理解的 Java 编程框架的地位。这一优势源于 Spring 框架在所有框架中采用了最优的设计原则。
Spring 框架诞生于 2003 年，至今已有二十多年的演进历程。每一次版本迭代，Spring 社区都在努力保留最佳的模式和标准，淘汰不再适用的部分。你能想象拥有如此庞大的、经过验证的理念和概念库供你免费使用吗？
专注于 Spring，你就能掌握这个建立在最优秀的编程平台上的顶级框架，为最苛刻的场景——企业级应用——服务。Spring 框架尤其在构建后端微服务架构方面至关重要，而后者正是全球最大公司的基石。
企业后端微服务构成了一个数十亿美元的产业，而 Java 在其中扮演着领导角色。因此，掌握 Spring 框架，你就成为全球范围内极具价值的专业人才，跻身世界级的技术专家之列。
尽管企业后端系统中也存在许多优秀的框架和语言，但没有任何其他框架能像 Spring 生态系统一样，在企业级后端场景中提供庞大的活跃社区、丰富的就业机会，以及结构良好的语言与框架的完美结合。Spring 生态系统在市场上无与伦比。
“Spring 框架太复杂了！”这是常见的看法吗？
的确，庞大的 Spring 项目生态系统乍一看会让人望而生畏。深入 Spring 生态系统，就像进入一个充满无限可能性的迷宫。翻阅 Spring 文档，对于很多人来说，都是一项艰巨的任务。
甚至是最资深的开发者，包括技术负责人和架构师，往往也承认缺乏对整个 Spring 项目的全局概览。
无论你是其他语言或框架的资深开发者，还是刚开始接触 Spring，你很可能会遇到以下关键问题：
- 使用 Spring 框架构建系统有哪些选择？
- Spring 系统开发的核心组件是什么？
- 什么时候应该选择某个组件而不是另一个？
- Spring 的各个组件和项目是如何协同工作的？
- 每个 Spring 项目的主要用途是什么？
在本书结束时，你将能够自信地回答这些问题，清晰理解 Spring 各种组件如何应对现实开发挑战。虽然没有哪个系统是完美的（是的，Bug 永远存在），但你已经踏上了学习 Spring 生态系统的旅程，准备好开启这场冒险了吗？
当别人还在为如何选择合适的 Spring 组件而犹豫不决时，本书将为你提供一条清晰的路线。从理解最初的业务需求，到自信地用正确的方法开发软件，本书帮助你简化那些看似复杂的过程。
本书是如何构建结构来帮助你成功的？
通过深入阅读本书，你将学会如何解读最具挑战性的业务需求。你将学会如何将这些需求转化为清晰且可执行的用例，就像绘制一张详细的地图，指导系统应如何实现。
从这张“地图”（用例）开始，你将逐步设计一座充满活力的城市（领域、服务和时序图），最终构建起屹立在生产环境中的“建筑”（代码）。在这个过程中，我们将采用自动化测试，就像值得信赖的指南针，确保开发过程不仅高效，而且安全、可靠。
在这一部分，我们将正面解决“软件开发人员的两难困境”。
在大型企业公司中，软件工程师常常面临一个十字路口——决定是成为有远见的架构师，还是专注编码的大师：
- 架构师花费大量时间与产品团队沟通，探讨如何将业务需求拆解为较大的工作单元：服务、API 和接口。他们擅长创建高层设计，并将明确的任务分配给团队和个人成员。许多架构师可能已经很久没有写代码，但他们在设计和规划方面的专业知识仍然至关重要。
- 而大多数程序员则喜欢处理架构师和技术负责人准备好的明确任务。他们享受独立编码，常常希望远离那些业务讨论，因为这些讨论对他们而言缺乏吸引力。程序员通常更专注于开发的技术细节，而不是直接从业务对话中提取服务。
本书的设计目标是融合高层设计和细致编程这两个世界。结构如下：
- 起初，你将在前三章学习如何识别需求并将其转化为高层服务设计。
- 接下来，第 4 到第 10 章将指导你解决技术和非功能需求，以实现基于 Spring 的简单服务。这包括编写 API、管理数据、确保安全，以及处理更复杂的任务，例如基于事件的架构。
- 进一步，第 11 和第 12 章将提升你的理解，帮助你构建一个完整的基于 Spring 的微服务云，具备自愈能力，并包含优化服务性能的原则和技巧。
本书涵盖了这一整段旅程。我很期待你能发掘 Spring 框架在行业和职业发展中的全部潜力。
在你踏上这段旅程之前，我只有一个请求：
始终保持微笑，尤其是在面对挑战时。
坚持学习，这才是 IT 和软件开发职业中最有价值的精髓。我们所处理的是一个复杂的话题，变量无穷无尽。记住，你只是人类，软件的完美是一个不断演进的目标。你最初写的代码可能需要优化，这完全正常。下周，你可能会发现改进的机会——这种循环几乎不可避免。
接受偶尔的错误，并及时修复 Bug；这种心态将在你的职业生涯中带来巨大回报。
你准备好采用这种方法，成为你所在组织的 Spring 技术专家了吗？你是否希望成为顶尖的 Spring 框架架构师？
那就让我们马上开始吧！
为什么我们需要理解业务需求？
你可能会说：
“我们直接开始写代码吧...”
别急！缺乏对业务需求的理解将导致 Spring 框架的大量误用。
我理解你迫切想使用行业内最佳、最可靠的设计模式来创建基于 Spring 的服务。
我现在就可以展示一些基于 Spring 构建的服务。但是，问题不在于缺乏意愿，而在于不知道该从哪里入手。Spring 生态系统非常庞大，涵盖了无数用例，因此我们必须回答以下问题：
- 关键要素是什么？
- 什么是“起点”和“终点”？
事实上，Spring 生态系统没有明确的“起点”或“终点”；每个组件都是为互相配合而设计的。因此，关键在于理解驱动你选择每个组件或 Spring 项目的具体需求。
一个常见的障碍是：很多人不知道该选择哪个 Spring 项目来解决软件问题。更重要的是，许多人在将现实需求转化为有效的 Spring 架构和实现策略时面临巨大挑战。
这一行业问题的根源在于：开发人员难以理解客户视角，因为他们长期专注于技术讨论和编码，鲜少参与客户沟通或采用不同的思维方式。很多软件开发者困在自己的技术世界中，难以跳脱出来。
理解业务需求，是程序员提升开发能力和架构能力的核心技能。
这正是本书要帮助你培养的技能。
为什么完善业务需求很重要？
这一原则将帮助你避免在 Spring 实现中出现重大损失，因为业务需求是引导你和你的团队走向成功（或失败）的最高杠杆点。
其中的细节和变量非常多。一份完整且精心编写的需求文档，可以让团队对下一步行动一目了然。而需求中的漏洞，则会导致混乱、延误，甚至在日常工作中不断出现意料之外的麻烦。
我见过很多由于需求不清晰导致的严重后果：
- 团队可能不得不废弃几个月的开发成果
- 系统可能在发布时缺失核心功能，影响用户体验
- 集成问题可能在项目后期才暴露
- 项目时间表被一再延迟，影响上线计划
- QA 团队不知道该测试什么、如何测试，导致遗漏
- 架构决策错误，影响项目长期可维护性
- 短视选择可能带来巨大的未来成本
- 为了赶工，团队可能不得不加班，打击士气、增加预算
如果你忽视这些章节，请记住这段“诅咒”：
你的项目将不得安宁，每天醒来都要面对 Slack 上的新灾难！
但不要害怕，只要确保所有需求符合最佳实践，你的 Spring 开发之路将更加顺畅。
什么是业务需求？
业务需求、产品需求和功能需求，是公司用来描述系统如何解决客户问题的术语。
理解业务需求，首先要理解什么是客户问题。
什么是问题？
你能简洁定义客户的问题吗？很多人凭直觉知道什么是问题，但却难以清楚表达。这是一个常见的盲点，许多人没有意识到自己在定义或处理业务需求时存在漏洞。
这种理解上的缺口会严重影响架构决策的质量。
我见过许多团队反复讨论，试图搞清楚一个产品到底要做什么。但通过我即将介绍的概念、定义和工具，你可以将几周的混乱讨论压缩到一小时的高效会议。
它既强大，又简单。
用一个简洁且深刻的定义来揭开业务需求的神秘面纱：
客户问题来源于一种不理想的现状。
这句话意味深长。它意味着软件开发的目标，始终是将客户从“不理想的状态”带到“理想的状态”。你的软件应该成为一座桥梁，引导客户从问题走向解决方案。
如果我们把问题理解为“不理想的现状”，而解决方案理解为“未来的理想状态”，
那么业务需求，本质上就是一组精确描述的软件行为，用来帮助客户从现状过渡到理想状态。
接下来，我们将深入解析这个概念。
晶莹剔透的需求——确保企业正确获取需求
本节将介绍一种方法，帮助为需求讨论带来结构和清晰度。这一方法基于我在神经语言程序学（NLP）领域学到的核心概念开发而成。虽然我们无需深入探讨 NLP 的技术细节，但学习这种业务需求结构化方式将有助于你更好地理解业务需求的本质。
业务人员通常会自由地描述他们希望创建的解决方案特征。但实际上，在这些常见的自由文本描述中隐藏着一些关键变量。一旦你真正理解这些变量，就能识别出任何业务需求中的缺口和缺失部分。
用时间线可视化问题解决
使用可视化时间线可以简化业务需求的定义，聚焦于两个关键节点：现状和未来状态。
- 现状 描述客户当前面临的挑战
- 未来状态 则展望实施你的解决方案后客户的处境
从脑科学的角度来看，视觉化非常重要。使用图片或图表时，我们的大脑会在更多区域“亮起来”。通过调动更多神经元，我们能更好地理解事物。我们的大脑非常擅长理解并处理图像。
举个例子，想想我们是如何把时间理解成一条直线的——这是我们用图像来理解抽象概念的体现。因此，当我们用视觉方式来解释系统时，它利用了大脑处理图像的强项，使我们更容易掌握信息，哪怕是非常复杂的业务需求。
简而言之，使用图像不仅有帮助，而且是充分发挥大脑学习和解决问题优势的一种聪明且必要的方式。
下图提供了一个清晰的框架，帮助你理解软件为用户带来的转变过程：
要编写一份全面且有效的业务需求文档，必须收集能够清晰呈现客户当前状态与未来状态对比的描述。可以将该文档想象成一个两栏布局：
- 左侧 描述客户目前不理想的现状
- 右侧 则描绘使用你的软件后，理想的未来状态
更重要的是，文档还必须明确说明该软件将如何帮助客户从不理想的现状过渡到理想的未来。
这种结构不仅能澄清软件的目的和功能，还能确保所有利益相关方对项目目标及其转型潜力达成共识。
以社交媒体平台解决的问题为例，我们可以将这些元素放在一个基本的时间线上：
在图表中，我们可以看到两个截然不同的阶段，清晰地描绘了社交媒体平台出现前后的生活对比。
在左侧，情景展示了一个时期，当时用户在快速、轻松地了解朋友日常生活方面面临挑战。
而在右侧，则呈现了采用社交媒体后的转变：用户能够方便、即时地与朋友连接，这标志着沟通和社交互动方式发生了显著变化。
这种鲜明的对比突出了社交媒体平台在弥合沟通鸿沟、促进用户间联系方面的重要作用。当然，社交媒体解决的问题不止这些，这只是一个用来说明的例子。
制定业务需求
既然我们已经在时间轴模型中明确了“问题”和“解决方案”，下一步至关重要的工作就是对你的产品进行全面描述。从本质上讲，你的产品就是帮助客户从当前困境走向预期解决方案的桥梁。
为了确保产品兑现承诺，必须定义其所需的属性和特质，使其能够有效地将客户从“问题”状态过渡到“解决方案”状态。这也正是业务需求（business requirements）、产品需求（product requirements）或简称需求（requirements）这些术语发挥作用的地方，不同组织常常会交替使用它们。
制定一套完整的业务需求通常包括以下四个步骤：
- 识别客户面临的所有问题，即你的产品要解决的痛点。
- 定义解决方案，清楚地说明产品如何转变用户体验。
- 为每一对问题-解决方案制定高层次需求，详细说明实现目标所必需的要素。
- 将高层次需求细化，生成针对特定用例、业务规则和流程的具体需求，以指导开发和实施解决方案。
如果需要更直观地呈现这些步骤，可以参考下图：
在接下来的章节中，我们将更深入地探讨这些步骤，并提供一个清晰的框架，将客户需求转化为可执行的产品功能和特性。
识别客户的核心问题
假设你刚刚加入了一家名为 HomeIt 的初创公司，这家公司专注于帮助租户找到符合其生活方式需求的理想公寓。
租户可能面临哪些问题？
以下是我们可以列出的一些可能问题。记住，“问题”是指目标用户当前面临的某种现状或不理想的情况：
- 并非所有房产中介都值得信任
- 租赁房源广告有时会隐藏现有问题
- 与房东和中介的关系可能难以管理
- 可用的支付方式有限
- 合同签订时间过长
- 缺乏良好的保险选择
你还能想到租户在租房过程中会遇到哪些问题吗？
在进入下一部分前，请花一些时间思考一下。
创建问题-解决方案矩阵
现在我们已经列出了租户当前面临的问题，接下来为每个问题创建可能的解决方案清单。注意，一个问题可能对应多个解决方案：
-
并非所有房产中介都值得信任：
- 提供一个值得信赖的中介名单
-
租赁房源广告有时隐藏现有问题：
- 允许租户报告在入住后发现但广告未提及的问题
- 当租户发现未披露的问题时，给予赔偿
-
支付方式有限：
- 提供多种支付选项
- 让中介、房东和租户都能轻松、快速完成支付
- 为房东提供财务担保，以防租户某个月无法支付租金
- 为租户提供财务保障，以防他们在某个月无法支付租金
我并未考虑这些解决方案的商业可行性，以上示例仅用于说明。
接下来，请继续完成练习：
- 为之前列出的问题提供更多解决方案示例
- 使用你想到的其他问题创建新的解决方案
在继续下一部分之前，请花一些时间进行此练习。
描述解决方案的高层次需求
现在，我们已经明确了客户面临的问题以及他们所需的解决方案，接下来要概述一种软件的需求，使其能够将客户从“问题”状态带到“解决方案”状态。
以下是 HomeIt 的一个场景：
HomeIt 系统在这种情况下应提供哪些必备功能？
让我们通过一些简单的段落示例来说明产品的价值：
我们的系统将为每位房产经纪人配备业务质量评分，这是一种基于租客和房东在成功交易后所提供反馈得出的 1 至 5 星评级。此功能将充当“信任计”，帮助用户通过选择与高评级专业人士合作来做出明智决策。
此外，HomeIt 平台将包含调解功能，使租客、房产经纪人和房东能够在系统内直接处理和解决纠纷。这确保了在交易过程中出现的小摩擦可以高效化解，营造一个值得信赖和支持的社区。
另外，HomeIt 将为租客和房东提供保险选项，以防范可能由其他方引起的意外事件。
这三大功能——可靠的经纪人评级、简明的纠纷解决机制和全面的保险保障——为建立一个可信赖的环境奠定了基础，让每个人都能安心开展业务。
此示例提供了一个宽泛的概览，重点关注系统应采取的通用措施，以帮助用户从面临问题转向未来的解决方案。
在这一阶段，详细的具体规则或业务流程并不是核心。可以将这种高层次需求视为初步头脑风暴阶段，后续会进一步细化。虽然我们可以深入一些规则和细节，但现在的主要目标是开放地提出想法，而不必过于关注精确性。
这些宏观的产品需求勾勒出了我们解决方案的愿景。
采用这种结构化的方法，可以简化识别客户问题、构想解决这些问题的目标，并定义需求以引导客户迈向我们设想的系统。
现在轮到你了。 回顾我们讨论过的问题和解决方案，为 HomeIt 初创公司列出一些高层次需求。
在后续章节中，我们将深入探讨“细化”阶段，讨论用例、顺序图、领域模型等。
在本章的下一部分，我们将研究定义业务需求时可能遇到的陷阱。这些原则将为你节省大量时间。
产品需求中的陷阱
以下指南来自多年在不同项目中的亲身经验。即使是每月收入数百万美元的产品也可能存在这些错误。若放任这些问题发生，可能会给公司带来大量额外时间和金钱成本，并导致技术债务、糟糕的架构设计、交付延迟等。请从我的经验中学习，不要让这些错误发生在你身上。
模型设计是否属于业务需求？
虽然视觉模型和 Figma 设计如今是软件开发的核心部分，但它们本质上是对明确定义的业务需求的诠释。
这点非常重要，因为有时你可能会质疑，一个功能的用户旅程模型是否真正完全满足了需求。作为软件工程师和分析师，你也有责任再次检查这些视觉方案在开发过程中、用户体验或性能方面是否会导致问题，甚至这些视觉是否揭示了业务需求和用例中未明确提及的业务规则（下一章会讨论用例）。
当仅提供视觉方案而没有明确的业务需求时，开发风险会显著增加。清晰、书面的产品团队期望定义对于平稳的开发过程至关重要。
需求不应表达技术选择
在我们的领域中，常会遇到业务需求中指定某种技术实现方式的情况。然而，必须明白，技术建议不应被误认为是“业务需求”的定义。
将技术指令当作不可更改的业务需求，可能会限制选择，阻断发现更好解决方案的可能性。这种做法可能会为企业带来巨大盲区。
将技术选择纳入业务需求的另一弊端是，会限制产品团队在所选技术能力范围内。开发团队凭借对各种技术及其权衡的深刻理解，更有能力确定最适合满足需求的技术。
指出业务需求应避免包含技术指令，可以让产品团队更广泛地定义功能，并保持更多的思维自由度。这种方法能带来更多创新，让开发团队自由选择最佳实现方式。
客户知道他们遇到的问题吗？
有趣的是，有些问题在解决方案出现之前对客户来说是“不可见的”。通常，创新型公司会揭示这些隐藏的问题，并提供客户从未意识到的解决方案。事实上，客户可能一直处于不理想的状态，而没有意识到存在更好的替代方案。
想想社交媒体平台的发明。它们引入了一种全新方式，让人们可以快速与朋友分享并接收动态。最初，这项服务主要面向技术达人，而其他人则持怀疑态度或不了解其好处。我记得当时试图让朋友加入，但他们大多无动于衷。
然而，随着时间推移，社交媒体已成为普遍工具，甚至不擅长技术的老年人也发现它的价值，用来保持联系。如今几乎找不到不用至少一个社交媒体平台的人。例如，我的祖母现在比我还活跃在 Instagram 上，而且乐在其中。
这一转变凸显了社交媒体如何满足了曾经未被认识的需求。最初被许多人视为不必要的东西，如今已成为我们日常沟通的重要组成部分。
解决方案是最终步骤吗？
当然，每种情况都可能代表一个问题。因此，将客户引导到解决方案状态，可能实际上会揭示新的问题。
以社交媒体为例，人们蜂拥而至，是为了与更多朋友和意见领袖保持联系，这是现代互联的奇迹。
然而，问题在于，成为社交媒体的忠实用户可能导致过度刷屏，浪费大量时间，甚至因不断比较而引发心理压力，更不用说过度分享所带来的隐私风险。真是个悖论吧？这种促进联系的绝佳解决方案，同时也滋生了许多新问题。
这种循环正是创新的核心。每个解决方案都会揭示新的改进空间，意味着无尽的优化和演进机会。软件开发，就像航行在社交媒体的海洋中，是一个不断发布、反馈和迭代的循环过程。
打破技术债务的诅咒
技术债务类似于软件开发领域的财务债务，它代表那些虽然快捷，但未来可能带来复杂问题的编码选择：
- 缺乏自动化测试的代码更容易因变更而崩溃
- 设计不良的软件会危及生产环境的稳定性
- 低效的交付管道可能导致更新期间的停机
在我在各家公司积累的经验中，平衡技术债务偿还与功能开发并非易事。许多团队更优先考虑新功能，而不是解决潜在问题。以下是我们如何转变这种思维方式：
将技术债务解决纳入功能交付
让重构与功能更新一并实施，确保在交付新功能的同时提升系统架构和工程质量。
积极寻找机会，将重构融入产品实施的技术方案中。这是我们主动改善系统、防范潜在问题的责任。
一个非常简单的例子是，要求每个版本发布时必须创建自动化测试。这不仅要覆盖新功能，还要扩展测试覆盖率到可能测试不足的现有功能。这一策略能逐步提高系统可靠性，增强其在生产环境中的性能信心。
明确技术债务如何让用户失望
通过检查技术债务并追踪其对用户旅程的影响，我们可以识别并量化系统中由此引发的问题。例如：
- 性能问题：如同堵车，技术债务会严重拖慢流程，甚至导致用户放弃
- 数据不一致：用户可能丢失或看到错误数据，引发挫败感和信任问题
- 可用性差：界面复杂、不直观甚至无法使用，让用户困惑、失望甚至愤怒
- 部署延迟：更新速度慢，用户等待改进的时间变长，公司上市时间也会受很大影响
要真正理解影响，请花时间量化受特定技术债务影响的用户数量及其严重程度。
当你能直接将糟糕的设计决策与用户不满联系起来，并量化浪费的时间、金钱和精力时，说服产品团队优先解决技术债务就容易得多。
如果你能用金钱量化技术债务带来的问题，并证明浪费巨大，高层管理基本不可能不优先考虑这些变更。
这两种策略——将技术债务偿还作为当前发布任务的一部分，以及衡量其直接用户影响——都是逐步改善系统的良好方法。
密集型文档
在不良的敏捷实践中，经常会遇到那种信息过于密集以至于难以解读的需求文档。这种方法可以追溯到 2000 年代初，当时软件通过安装光盘交付，开发周期可能长达六个月甚至数年，才能发布一整套功能更新。
快进到今天，应用程序通常由一系列微服务组成，有时还伴随遗留的单体系统。这种转变意味着更新通常是按功能逐步进行，甚至每天在生产环境中发布部分更新，直到整个功能准备好通过功能开关启用。现实中，一个功能的描述不应超过 1000 行代码，更不可能扩展到数百页。
如果你发现自己在即将发布的功能中被大量细节淹没，并被要求同时上线所有内容……是时候表达你的担忧了。以这种方式发布产品严重偏离敏捷原则，而敏捷原则通常非常适合实现平滑过渡和用户旅程改进。偏离良好的敏捷实践会显著增加出错风险。在数字时代，敏捷与清晰不仅是锦上添花，它们是成功的关键。
模糊文档
另一方面，如果需求文档仅提供高层业务目标，就会引发严重警示。缺乏细节会让开发者停滞不前，因为缺少必要的流程和业务规则而无法开始编码。
开发者虽然擅长将复杂的用户需求转化为功能代码，但通常不熟悉业务运营的细节。他们是技术爱好者，专注于最新技术，而非特定市场的细微差别或产品的法律细节。他们的优势在于构建，而不是揣测业务或客户未明说的需求。
在当今快速发展的科技环境中，找到既懂技术又了解用户需求的开发者越来越可行。这类开发者就像技术宇宙中的探索者，总在寻找下一个颠覆性技术。然而，他们的旅程往往远离市场细节和产品相关的法律框架。与紧密与客户互动的产品和支持团队不同，开发者可能无法深入理解客户需求或影响产品开发的法律框架。
如果你收到的需求更像是预告片而非完整剧本，必须提出异议。向产品团队索取完整的业务流程和规则。在没有这些信息的情况下投入项目规划，会让你不得不从技术专长领域偏离，进入一个即便全力以赴也可能无法满足项目需求的领域。记住，你的主要角色是实现技术解决方案，而不是猜测业务缺失部分。
超越理想路径
在产品开发中，需求文档常常描绘一幅一切顺利的理想画面，我们称之为“幸福路径”。这就像计划一次完美的公路旅行，没有交通堵塞和坏天气；然而，现实总需要备用方案。
有效的需求文档会考虑“如果发生……会怎样”，确保系统的稳健性：
- 如果用户偏离产品的预期使用方式？
- 如果系统性能出现小故障？
- 如果第三方服务暂时不可用？
良好的需求会预测并计划所有非理想情况。确保需求文档能够应对“坏日子”至关重要。通过规划异常和不良场景，我们能够直面挑战，系统从一开始就更具应变能力。
忽视其他业务领域与流程
有时，产品经理提供的需求没有考虑其他公司部门的运作。在产品开发中，确保每个部门都做好准备，是成功推出服务的关键。
比如，你公司要求你开发网站上的一项创新服务。你和团队以惊人的速度将服务上线生产，通过所有质量和用户验收测试。上线成功，客户满意，销量暴涨。
然而，负责交付该服务的部门在开发期间未参与其中，突然出现瓶颈——他们没有准备好应对这项新服务的独特需求。
无论组织规模大小，必须确保没有部门被忽视。你可以：
- 从一开始就让所有相关部门参与
- 提出深入问题，了解服务如何融入公司整体生态
- 确保业务需求文档反映每个部门的角色和需求
- 确保文档得到所有可能相关部门签署，即便某些部门未受变更影响，也最好标明他们未参与
采用这种全局项目规划方法，不仅能避免临时障碍，还能促进协作和创新文化。
对其他领域假设过多
经常会看到产品团队提出的需求，可能未完全理解公司不同部门之间的互动。
例如，你正在处理前述产品，需要将请求转发给配送部门。在未与该部门开发团队同步之前，即便是测试阶段，也不要盲目推进。
这点呼应了一个关键问题：需求文档是否已获得公司所有关键利益相关者批准？文档必须经过熟悉各系统和部门细节人员的审查。
想象你即将踏上一段旅程，你不会在没有大家认可的地图的情况下出发，对吧？根据未经检查的文档直接编码，就像拿着误导地图导航，你可能走错路，基于不成立的假设做出决策。
总结
本章到此结束。我们探讨了编写业务需求时的注意事项和常见误区，这些需求为成功的软件开发奠定基础。
关键要点：完备且结构良好的需求不仅支持良好的架构设计，它们本身就是基础。优秀的系统设计源于清晰表达的业务需求。记住，从一开始，你就在为成功铺路。
练习：现在轮到你了。花些时间思考一个现有的问题，尝试想象用软件解决它的可能性。不要太严肃，只需以游戏心态进行，假装你能用软件解决任何问题。
你可以继续 HomeIt 场景：
- 扩展到租赁行业的其他现有问题
- 创建一个愿景，表示对你想象的问题的解决方案
- 编写一些高层次需求以交付这些解决方案。记住，可以设想多个不同的需求和功能来增强预期解决方案
在下一章中，我们将讨论如何将需求组织为用例、故事，以及如何添加细节、循环、流程和业务规则。我们将把你在本章学到的高层次需求赋予生命和乐趣。
