《并非附注，而是核心重点：质量计划如何推动你的 IT 项目》—— 博客系列第一部分

​​

为什么要使用质量计划？

曾以任何角色参与过 IT 项目的人都深知其中的挑战。项目启动时，你有着宏伟的计划、热情高涨的利益相关者，以及无数的好点子。但随着截止日期的临近，你会发现需求出现偏差，风险突然变成现实，或者测试过程陷入困境，导致问题发现得太晚。结果如何呢？交付延迟，团队沮丧，利益相关者则在疑惑他们的投资都花到哪里去了。

​​​

你将学到什么？

质量计划并非可有可无。它是一种系统的方法，不仅能确保项目按时交付，还能保证交付质量。在这个博客系列中，我将全方位地为你讲解质量计划的各个方面 —— 从让合适的人员参与其中，到规范定义（完成定义和准备就绪定义），再到使非功能性需求符合 SMART 原则，以及建立你的开发和测试流程。我们将深入探讨，我还会分享一些实用的例子和技巧，你可以立即应用到自己的项目中。

并非只是理论

这个博客并非只是理论探讨或理想情况下的场景 —— 我曾在为一家大客户开展的实际项目中构建并应用了这种方法。我们共同制定了一个质量计划，它成为了项目背后的驱动力。结果，我们提前完成了交付，因为我们掌控了每一个步骤 —— 这在公司内是一项独特的成就。

1. 确定利益相关者：任何项目的基础
   IT 项目很少是一个独立的个体。它与其他部门、外部各方、预算负责人、终端用户等相互交织，不一而足。这正是为什么在项目初期就清楚地了解你的利益相关者是谁以及他们的利益所在至关重要。这不仅是因为这样可以避免意外的挫折，还因为你确切地知道该向谁寻求决策和反馈。

1.1 利益相关者矩阵
一个行之有效的方法是利益相关者矩阵，在这个矩阵中，你可以区分两个维度：

• 影响力（高 / 低）
• 利益关联度（高 / 低）

然后你就可以在矩阵中 “绘制” 出各个利益相关者的位置。这样，你一眼就能看出谁在战略上非常重要，谁主要需要被告知项目情况，以及谁可能只是爱发表意见但在正式决策方面话语权不大。举例如下：

• 高重要性 / 高影响力：例如，负责预算的产品负责人。你应该让这个人密切参与所有重大决策。
• 高重要性 / 低影响力：这些可能是终端用户。他们很重要（因为他们日后要使用这个项目成果），但他们对预算或技术没有决策权。然而，他们的反馈对于项目的可用性至关重要。
• 低重要性 / 高影响力：可以想想合规或安全团队，他们会发布对业务至关重要的指导方针，但他们自己并非日常用户。他们可能对功能方面的兴趣较小，但由于相关规定，他们具有相当大的影响力。

​​

有了这个矩阵，你就能避免在项目进行到一半时才发现，比如安全专家必须在项目上线前对所有内容进行正式审批，从而导致项目延误。​

快速见效的方法：

• 尽早使用利益相关者矩阵
• 提前确定关键决策者和有影响力的人，以避免最后时刻出现障碍。

• 明确谁需要定期获取最新消息，谁负责做出关键决策。

• 需求收集（并使非功能性需求符合 SMART 原则）
  IT 项目中出现问题的最常见原因之一是范围蔓延：突然出现新的需求，或者现有需求被证明比预计的要复杂得多。为了避免这种情况，在项目早期就要在一个集中的环境中记录所有（已知的）需求，这样每个团队成员都知道在哪里可以找到这些需求。明确每个需求的来源（来自哪个利益相关者），并针对每个需求定义其重要程度（例如通过 MoSCoW 方法：必须有、应该有、可以有、不会有）。

这与敏捷工作方式如何契合呢？

虽然尽早收集需求可能感觉有点传统，但在敏捷环境中提供清晰的信息尤为重要。这并不是要把每个需求都固定下来，而是要在像 Confluence 或 Jira 这样的集中环境中持续跟踪和审查待办事项列表。这样你就能保持敏捷性：从细化或回顾会议中获得的新见解可能会促使你调整优先级，甚至删除某些需求。

2.1 不要忘记非功能性需求
通常，正是非功能性需求在日后会让人头疼：性能、安全性、可用性、可扩展性等等，不一而足。风险在于这些需求要么没有被提及，要么仍然很模糊（比如 “它必须是安全的”）。结果就是，没人确切知道多安全或多快才算 “足够安全” 或 “足够快”。为了有个全面的了解，最重要的质量属性列在 https://iso25000.com/index.php/en/iso-25000-standards/iso-25010 上。

提示：不要把你的非功能性需求命名为 “非功能性需求”。它们可能会被利益相关者忽略，因为 “它们没有功能”。就把它们命名为 “需求” 吧，因为它们本来就是需求！

​​

2.2 使它们符合 SMART 原则
SMART 代表具体的（Specific）、可衡量的（Measurable）、可接受的（Acceptable）、现实的（Realistic）和有时限的（Time-bound）。举个例子：
“具体来说，网页必须在 2 秒内加载完成，可根据自动化性能测试来衡量，符合用户需求，在现有基础设施条件下是现实可行的，并且有时限（例如，在项目启动后的六个月内）。”

通过这样表述非功能性需求，你就明确地设定了标准。像 “它必须快速加载” 这样模糊的需求就变成了一个明确的、可测试的需求：“在 80% 的访问情况下，主页的平均加载时间不得超过 2 秒。” 这使得测试人员和开发人员能够更有针对性地开展工作，而且你以后也不会遇到任何意外情况。

说明一下这个需求存在的理由，那就更完美了。

2.3 需求的所有权和管理
没有什么比需求不断增加却无人管理更糟糕的了。因此，要指定一名分析师或产品负责人，由他最终负责所有需求的验证和记录工作。这个人还要监控项目范围不会在团队或利益相关者不知情的情况下暗自扩大。毕竟，每出现一个新需求，都必须问一问：“这个需求是否仍符合我们的最小可行产品（MVP），它与之前的优先级有什么关系？”

快速见效的方法：

• 明确非功能性需求
• 集中跟踪和管理需求
• 将需求分类为 “必须有”“应该有”“可以有”“不会有”。
• 在每个迭代周期（Sprint）中细化需求
• 定期与利益相关者验证需求

总结

一个结构良好的质量计划能确保 IT 项目按计划进行，减少延误、避免期望偏差以及避免最后时刻的紧急应对。通过尽早确定利益相关者、明确需求以及制定符合 SMART 原则的非功能性需求，团队能够掌控局面并充满信心地交付项目成果。

下期预告：设计、文档与规避灾难！

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

‍