突破限制最好办法是接纳限制

各种各样的限制真的限制了设计师、开发人员和项目经理的选择，希望是有充分理由的。找到、交流和在这些限制内工作是软件开发成功的重要部分。我们先来定义一下：

“限制就是一些规则，它们限制了产品怎么设计、怎么做、怎么配置或者项目怎么管理。”

软件计划主要有三种限制：产品、项目和流程。

1、产品限制
产品限制说的是正在做的软件必须有或者不能有的功能或特点。这听起来和需求很像，对吧？

产品限制其实也是一种需求信息。业务分析师 (BA)在收集需求时要找出这些限制并记下来，这样设计师和开发人员才能正确处理。有些人认为所有需求都是限制，但我不这么看。比怎么叫它们更重要的是发现、理解、确认、记录、传达和尊重这些重要信息。

在收集需求时，注意听那些可能暗示设计或实施限制的词，比如必须、不能、不可以：

• “…不能超过<某个限制>”
• “…必须用<特定的用户界面控件>”
• “…必须用<特定的加密技术>”
• “…必须用<一种特定的编程语言>写”

不要只是记下相关人说的限制。问问为什么有这个限制，确认它是不是真的必要，看看有没有什么假设（这些假设可能已经过时或不对），并记下为什么要有这个限制。记下理由可以快速解决可能的争论，比如开发人员问：“我必须这么做吗，还是可以用我想的另一种方法？”

需求里的设计限制规定了产品设计的某些部分必须怎么做。注意那些有特定用户交互语言的需求：“当用户点击提交时……”BA 应该确定这些是真的限制还是只是某人的想法。如果不是真的限制，就把需求语言改得更通用，不要妨碍其他创意设计：“当用户选择提交时……”

可以把解决方案想法和需求一起列出来。只要确保读者知道这是限制（“你必须这么做！”）还是建议（“这是我们的一个想法，你可以看看我们在想什么。”）。BA 应该避免把太早、不必要、无意加的限制记成需求。

限制可能来自很多地方。带嵌入式软件的设备通常要遵守物理限制，比如大小、重量、用的材料、形状、物理和软件接口以及环保问题。计算环境、平台、操作系统、物理基础设施和其他技术因素可能会因为内存、处理器能力、磁盘空间、网络速度和容量、安全性或兼容性而加限制（比如同时用的人或事务的数量）。

业务规则也规定了很多限制
事实上，根据业务规则组的说法，“业务规则是定义或约束业务某些方面的声明。它旨在确立业务结构或控制或影响业务行为。”业务规则可以规定某些操作必须做或不能做，或者只有某些用户角色才能做特定的事。

遵守软件解决方案里的业务规则可能会导致强制执行用户访问权限、特权级别或类似使用限制的功能。限制可以指定系统必须怎么算某些东西。需要接受监管认证的产品（比如运输和医疗设备）必须遵守一系列已定的限制，这些限制被记成业务规则或标准。

非功能性需求通常也会加限制。安全需求就是个好例子。企业标准或行业最佳实践通常会规定用户和设备身份验证的特定协议。你的应用里能用生物识别技术做用户身份验证吗，还是用户必须用身份验证应用、物理安全密钥、短信或邮件发的密码或其他多因素身份验证技术？实施 MFA 的方法有很多；你的需求可能会指定哪些方法是必须的、允许的和不允许的。

产品限制的其他来源包括外部行业、产品或政府标准（比如数据保护和访问安全）以及与旧系统或相关产品系列成员的兼容性。和需求一样，BA 需要广泛撒网，确保团队在流程早期找出相关的产品限制。忽视限制可能会导致大量、计划外的设计和代码返工。没人希望这样。

在软件需求规范里记下确认过的产品限制。它们应该符合写清楚、完整、没歧义等要求。

2、项目限制
当人们说软件限制时，通常指的是项目限制。这些限制通常以时间、成本和范围的经典铁三角形式表示：

限制：时间、成本、范围——划分铁三角

也叫三重限制，基本意思是如果其中一个变了，其他两个也得跟着变。项目经理必须根据他们在三个维度上的灵活性做权衡决定。这个三角模型太简单了，有各种表示方式。质量在某些图里有，但不常见，表示方式也不一致。

我觉得从五个项目维度想更有启发性：功能（或范围）、进度（或时间）、成本（或预算）、人员和质量。把质量当成一个独立维度，因为人们通常会为了速度或范围牺牲质量，不管对不对。我不会像有时那样把人员和预算混在一起叫“资源”。有时项目团队有足够的钱，但雇不到更多人。有些人还觉得风险是一种限制，因为风险分析可能会导致团队限制技术选择或指导业务战略。

这五个维度里的每一个在任何项目里都可以扮演以下三个角色之一：限制、驱动或自由度。不给灵活性的维度就是限制。比如，不变的交付日期、有限的团队规模、固定的预算或不可谈的功能集。那些不是限制的维度给了一些可调性。所以，项目经理的挑战是调整更灵活的维度，让项目在限制内实现成功驱动因素。

一个重要提示：不是所有五个维度（或者三个，如果你更喜欢铁三角）都可以是不灵活的限制。每当项目现实变了，必须能有所让步。团队和领导层需要在开始时就对哪些维度是限制、哪些是灵活的达成一致。

3、流程限制
流程限制限制或规定了开发团队可以用的方法或它产生的开发工件，通常是因为组织或外部标准。我知道一个大组织要求所有项目都用企业敏捷框架，不管这是不是特定计划的最佳方法。根据管理法令，团队必须按这种方式做，即使它不适合这个活动。在一个要求用 Scrum 的组织里，团队必须填 Scrum 定义的团队角色；执行 Scrum 活动、事件和仪式；并创建 Scrum 工件，比如产品待办事项、冲刺待办事项和完成定义。

某些需要接受监管审查和认证的产品必须用某些协议和标准开发。它们可能需要生成包含以特定形式呈现的指定内容的特定可交付成果。可能需要进行某些检查点审查和批准。如果你的组织想保持 ISO 9000 认证，它的质量管理系统必须符合既定标准。为了达到特定的 CMMI 成熟度级别，组织需要建立并遵循适当的流程。

其他可能的流程限制来源包括：

• 用于软件分析和设计建模的工具和图表约定
• 可交付文件所需的模板
• 开发环境、配置管理工具和存储库等
• 由于可移植性或兼容性原因而用或避免用的编程语言或语言特性
• 表达需求的方法
• 用第三方供应商的工具或服务（比如大型语言模型 (LLM) 或其他 AI 产品、基于云的服务等）的安全性和可靠性问题
• 项目规划、跟踪和报告惯例

限制的重要性
找出相关限制是项目规划和需求开发的一个重要部分。规划人员必须知道他们的灵活性在哪，才能应对变化的现实。设计师必须确保他们的产品符合相关规则、法规、政策和标准。

设计限制不一定是坏事。它们可以通过为产品内部和跨产品逻辑上相似的操作提供一致性来提高可学习性和可用性。一个例子是我可以从手机里删东西的方式。不同的应用用各种交互技术、视觉设计元素和语言。方法可能因你是一次删一个还是多个而异。你可能需要或不需要确认删除。这很让人困惑。定义用户界面标准会给用户体验设计师加限制，但对用户有好处。

有创造力的人可能不喜欢工作中有限制，但这就是现实。提前知道限制可以减少混乱，做出更合适的产品。

富有创造力的人可能不喜欢在工作中受到限制，但这就是现实。提前了解限制条件可以减少混乱，生产出更合适的产品。