《设计、文档与规避灾难》—— 博客系列第二部分

​​

我们已涵盖的内容及后续内容

到目前为止，我们已经探讨了一个可靠质量计划的基础内容 —— 识别利益相关者、收集和管理需求，以及确保非功能性需求符合 SMART 原则且切实可行。现在，你应该已经掌握了从项目一开始就掌控 IT 项目的方法，并且能够避免诸如范围蔓延和职责不明确等常见陷阱。

现在，我们将进入项目质量的下几个关键支柱：

• 设计 —— 确保技术设计和用户体验（UX）设计切实可行。
• 文档 —— 使知识结构清晰、易于获取且保持最新状态。
• 风险 —— 主动识别并减轻潜在的障碍。
• 依赖关系 —— 管理外部和内部的依赖关系，以防止项目延误。

让我们继续在项目的每个阶段都融入质量因素。

1. 确定设计方案：用户体验设计与技术团队间的协作

3.1 早期协作避免失望情况

对于开发人员来说，设计有时就像一个 “黑洞”：在某个地方设计出了精美的方案，但在构建阶段却突然发现某些元素在技术上非常复杂，甚至根本不可行。这会导致沮丧情绪、时间浪费，有时还会让利益相关者不满意（“设计方案都已经通过审批了！”）。另请参阅 8.1 参与式设计。

解决方案是进行早期协作。让用户体验设计师、开发人员（有时还有测试人员）一起参与一个会议。讨论模型、线框图或流程图，并且不要犹豫，要立即给出反馈。例如，开发人员可能会指出某些动画对性能影响很大，或者某种布局不适合响应式框架。通过尽早提出这些问题，你就能得到一个既美观又切实可行的设计方案。

​​

3.2 文档记录与迭代

以可共享的形式（例如使用 Figma 或 Sketch 软件）记录设计方案，并保持其为最新版本。就像需求一样，设计方案永远不会 “完成”。你希望能够根据反馈或新的见解进行迭代，而不必从头重新思考设计原则。把它当作一份动态的文档，团队可以随时参考。

实现更好设计协作的快速有效方法：

• 尽早让开发人员参与
• 保持设计方案为最新版本

• 使用可点击的原型

• 依赖关系：尽早发现总比事后发现好

4.1 内部和外部因素

在现代 IT 领域，你很少能独立开展工作。你可能依赖其他团队来交付他们的微服务，或者依赖外部方来提供应用程序编程接口（API）。每一个依赖关系都可能成为潜在的瓶颈。因此，尽早识别这些依赖关系并与你的利益相关者和项目团队进行讨论至关重要。例如，通过项目增量（PI）活动或大型会议室规划会议，在这些会议中你可以与不同的团队一起识别依赖关系和风险，以便做出适当的规划。

​​

4.2 采取措施

一旦你知道存在依赖关系，就可以采取行动。也许在真正的服务还未准备好时，你可以部署模拟服务来提前进行开发或测试。或者你可以设计最小可行产品（MVP），这样即使没有后续的额外集成，你也能够交付项目。最重要的是，在发布临近时你不会遇到任何意外情况。

如果你依赖于其他方或团队，你能做的可不只是干等着看。一个明智的方法是使用功能标志。这使你能够在缺少集成功能不影响发布的情况下构建功能。你只需在连接准备好时才启用该功能即可。

另一个实用的解决方案是契约测试。这使你能够记录关于 API 或数据交换的协议，并自动对其进行测试。这样，你就可以避免在首次建立真正连接时才发现接口无法按预期工作的情况。

​​

建立回退机制也很有帮助。假设某个外部服务暂时不可用，你该如何应对呢？你能暂时使用缓存数据吗？或者在整个应用程序不崩溃的情况下给用户发送通知吗？

最后，要保持沟通。每周与你所依赖的团队进行协调可以避免意外情况发生，并且如果某些事情最终未能按时交付，你也有时间进行干预。

管理依赖关系的快速有效方法：

• 尽早梳理依赖关系
• 使用模拟服务
• 使用功能标志和回退机制

• 应用契约测试

• 识别风险（并运用 ROAM 方法处理风险！）

5.1 为什么风险分析是必须的

每个 IT 项目都存在不确定性。也许你担心加载时间过长，担心成本会大幅上升，或者担心迁移过程不会像期望的那样顺利进行。通过尽早进行结构化的风险分析，你可以减轻甚至完全避免许多问题。

​​

5.1.1 如何进行风险分析？
一个方便、简洁的方法是与你的团队一起进行头脑风暴，列出每一个潜在风险。然后为每个风险确定其发生的概率（可能性有多大）和影响（如果出现问题会怎样）。你可以将这两个维度放入一个矩阵中：这样就能清楚地知道哪些风险真正需要关注。

5.2 ROAM 方法
一种管理风险的实用方法是 ROAM，它代表：

• 已解决：风险现在已经得到解决。
• 已归属：有人已经承担起处理该风险的责任。
• 已接受：团队或组织认可并接受了剩余风险。
• 已减轻：已经采取措施来减轻风险带来的影响。

​​

假设你发现某个外部插件的安全性尚未通过正式审核。你可以决定仍然使用该插件，但要在质量计划中注明你 “接受此风险”。或者你可以通过自己进行额外的安全扫描来 “减轻” 风险。这样一来，每个人都清楚可能产生的后果，并且知道由谁来关注这个问题。

1. 对需求的最终检查：最终审批

6.1 正式确认时刻的重要性
一旦收集完所有的需求 —— 包括功能性需求和非功能性需求，明智的做法是安排一个正式的达成共识的时刻。在这个时候，你要与主要的利益相关者讨论究竟需要交付什么以及适用哪些标准。非功能性需求的 SMART 表述方式在这里也会再次派上用场。这样可以避免在项目进行到一半时有人说：“哦，但是我原本期望加载时间是在 1 秒以内，而不是 3 秒以内。” 这本身并不符合敏捷原则，但确实能让情况更加清晰明了。

6.2 记录并获得支持
要让这个共识成为一个切实的事实。这可以是在 Confluence 上的电子签名，或者是一份明确写明每个利益相关者都已达成一致的会议纪要。通过这种方式，你能获得支持，并且当有人提出新的要求时，你可以依据这份协议来应对。通常情况下，这时的原则是：可以，但这将对时间、预算或项目范围产生影响。

风险与需求管理的快速有效方法：

• 使用简单的风险矩阵
• 明确风险的负责人
• 保持敏捷性，避免官僚主义 —— 使用轻量级的最终检查，而不是冗长的正式评审

总结

到目前为止，我们已经为 IT 项目的质量奠定了坚实的基础 —— 涵盖了利益相关者的参与、清晰的需求定义，以及使非功能性需求符合 SMART 原则且切实可行。现在，我们正在更深入地探讨关键的质量支柱：通过早期协作确保设计方案可行，保持文档结构清晰且为最新版本，主动管理依赖关系，以及使用 ROAM 方法尽早识别风险。最后，我们强调了进行正式需求审批的重要性，以防止在最后时刻出现意外情况。通过应用这些策略，你将加强项目质量，避免常见的陷阱，并确保项目从始至终都能顺利进行。

下期预告：避免过度构建 —— 最小可行产品（MVP）和故事映射如何让你保持专注

如果你对如何引入最优质量计划有疑问，请随时通过邮件 qa@the-experts.nl 与我们联系。

‍