软件需求层次理论

作为一名产品经理，为了首先识别出最有价值的特性，我希望在待办事项列表中排定特性的优先级。

但是，对客户和用户而言，什么有价值？业务人员告诉我们，从前，决定将哪些特性包含在下一个版本中非常容易。而现在，软件几乎成为每个人日常生活 的一部分。如果客户和用户工作在一个为人熟知的业务环境里，那么关于什么最有价值这个问题非常容易回答。但是，在一个松散的、完全个性化的市场中，我甚至 不知道客户是谁，我怎么知道什么有价值？

价值绝不仅仅是可用。价值关乎质量和情感。高质量的产品比低质量的产品更有价值。质量模型有若干种，比如，基于可靠性、效率、安全性和可维护性的 CISQ质量模型。但是，由于这些质量模型没有包含情感因素，所以它们无法完全解释为什么一个应用让人满意、受人欢迎，而另一款类似的应用却没有。为了理 解对用户而言什么让软件有价值，我们需要一个增强的质量模型。如果某个东西满足了我的个人需求，它就是有价值的。这似乎显而易见，但这有用吗？

在待办事项列表中查找最有价值的特性时，它能给我一些指导吗？我甚至都不知道我的客户是谁，我怎么知道他们的个人需求？

这时，心理学可能会有用。在20世纪中叶，亚伯拉罕·马斯洛提出了需求层次理论——人类动机论。这个需求层次也许可以映射到软件质量方面的层次。这样，我们就可以得到一个完整的软件质量模型，用于满足未知客户的个人需求。

图1：马斯洛需求层次到软件质量方面的映射

在马斯洛需求层次理论中，生理需求是最基本的需求。例如，睡眠和食物需求。在软件质量上下文中，基本需求是软件可以在客户的设备上使用和操作。在 Kano模型中[1]，这些基本需求称为“必需特性（Mandatories）”、“基线特性”或者“应达质量（Must-be Quality）”。（关于其它排定待办事项优先级的方法，请看下文。）如果软件在功能上满足需求，并且性能也不错，那么客户已经可以对软件质量有个大致 的感受。

基本需求的上一级是安全需求。在这个模型的需求层次中，并不是说只有低一级的需求得到百分百的满足后才会出现更高级的需求。通常，只要低一级需求 得到最低限度的满足，就足以产生更高水平的新需求。另一方面，一个人不可能无限地满足单个需求。如果你休息好了，也吃饱了，那么更多的睡眠和食物不会再是 最能激励你的需求。

谈及软件质量，这意味着，只有软件可以在客户设备上运行，并按照客户意图执行任务，健壮性、安全和可理解性才会提上日程。另外，这还意味着，如果 他或她的功能需求已经满足，但更高级的需求没有满足，那么功能的增加可能不会为客户带来更高级的质量体验。对于一个潜在的客户而言，功能是核心。但对于使 用软件的客户而言，功能已经成为既定的事实。通常，他或她反而会期待新版本带来其它更高级的属性。

除了健壮性和使用安全外，安全需求还包括可理解性。如果用户觉得简单易用可理解，那么就不会害怕错误和失败。另外，无障碍可达也属于这一类需求。

当物理和安全需求至少在某种程度上得到了满足，社交需求才会出现。软件在客户的社交圈中是否受到欢迎和认可可能会变得更加重要。这可能会引发额外 的特性需求，如直接发布到社交媒体、推荐或等级系统，或者在Web商店中包含一个聊天室，在购买特定的产品前，用户可以在那里讨论产品的优点和不足。常 常，产品是市场领导者这样一个事实比功能完整性更重要。即使其它供选方案更合适，也只会成为第二选择。之所以会这样，部分也是出于安全需求的考虑。如果用 户可以从社区或社交网络中找到软件方面的帮助，那么他或她会觉得更安全。

但是，情况也可能恰好相反。有些人希望通过不使用市场领导者的产品将自己和他人区分开来。为了与众不同，即使是一定的质量损失也可以接受。为了将 你的产品与市场领导者的产品区分开来，你可能会努力在更高级的需求类别上变得更好，即使你的产品没有包含市场领导者提供的所有低级需求。

你可能会注意到这样一个事实，这个例子中的模型并不是一个完美的层次。一方面，基本需求必须得到一定程度的满足，高级需求才可以发挥作用。另一方面，对客户而言，高级需求常常更有价值，这可能导致客户推迟基本需求，设法从满足部分高级需求中获益。

下一步，在社交需求之上，马斯洛看到了个人需要，他将之归结为“尊重”。这个领域不仅涉及权力、自主和自由，还包含声誉、认可和尊敬。对于软件质 量和价值，这意味着他们能够做一些没有这个软件或一项特定特性就没办法做的事情，以及一些可以提升他们的地位或开阔他们的眼界的事情——既酷又可以让个人 需求得到满足的事情。这个模型的第五层，也是最后一步，留给了自我实现（马斯洛后来重新定义了他的模型，并增加了一步自我超越）。人们认为，一个可以让用 户按自己的方式做事并实现自己的想法的软件，或者是一个可以培养用户创造力的软件，比一个只专注于狭窄的解决方案空间的软件更有价值。连接或协作特性，如 移动应用和云服务的“分享”特性，或者桌面应用程序的“导入/导出”特性，可能属于“尊重”或“自我实现”的类别，因为它们经常使用户超出单个设备上单个 应用程序的限制，创建他或她自己的工作流（参见下面的例子）。

对软件质量的传统理解主要是基于生理和安全需求。相比之下，当今软件的质量模型应该基于完整的需求层次。因为在我们的生活中，软件进入了越来越多 的个人和私人领域，除了安全和隐私外，对于软件质量，一些社交和个人方面的新需求开始发挥作用。在用户看来，可用性、健壮性以及恰当的功能都是理所当然 的。实际上，缺少这些基本的属性通常会在应用商店或社交网络上招致不友好的评论。

这种趋势不只是在消费者市场上显而易见。事实上，我们所有人一直都是软件消费者，这也塑造着我们对于商业软件的预期。软件必须有用，而且不需要一个深入、冗长的用户手册学习过程，现如今，这被视为是理所当然的，对任何软件的成败都至关重要。

那么，这如何用于排定优先级呢？在《谷歌软件测试之道》一书中[2]，James Whittacker等人提出一种名为ACC的测试计划和风险评估技术，其中A、C、C分别为“属性（Attribute）”、“组件 （Component）”和“能力（Capacity）”。其思想是生成一个矩阵，一个轴表示承诺的产品属性，另一个轴表示产品组件。在矩阵的单元格中填 入组件的能力，降低组件无法满足已承诺属性的风险。例如，如果市场部门承诺产品用户可以快速找到搜索项，那么这可能就会使搜索引擎具备在一个给定的小时间 窗口内返回结果的能力。这个思想启发了我，我可以使用类似的方法，根据产品特性所能满足的马斯洛人类需求种类的多少来排定其优先级。我将这种方法称为 NFC方法。NFC代表“需求（Need）”、“特性（Feature）”、“能力（Capacity）”。在这个模型中，一个轴表示需求种类，另一个轴 表示需要排定优先级的特性，生成一个类似ACC的矩阵，矩阵单元格描述特性满足需求的方式。与只满足低级需求的特性相比，满足更高级需求的特性会获得更高 的优先级——前提是更基础的产品特性至少已经得到了部分的满足。

下面是一个例子。比如说有一个移动应用，用户可以用它传真文档。该应用自己有一个基础的编辑器，而作为产品经理，你必须决定是否在编辑器中包含更 高级的特性，是否增加一个允许用户在发送前从发件箱中删除传真的功能，或者是否允许接收其它应用通过它们的“分享”功能发送的文档。表1是由上述内容得出 的NFC矩阵。

表1：特性如何服务用户需求？

表1显示，接收其它应用发送的文档满足了最高级的需求，使用户可以做没有这项功能就无法做的事。这也许还能提高用户的地位（我能做某件事，而你不 能）。这两种能力都可以满足人的尊重需求。根据表1中列出的特性能力，作为产品经理，你可能会赋予“接收文档”最高的优先级，“增强编辑器”次之，而“从 发件箱删除”是第三个最有价值的特性。虽然“增强编辑器”和“从发件箱删除”均满足安全需求，但因为“增强编辑器”额外满足了生理需求，而“从发件箱删 除”仅能满足安全需求，所以“增强编辑器”比“从发件箱删除”更有价值。在排定待办事项列表中特性的优先级时，作为产品经理，你的工作是根据马斯洛的需求 层次理论，考虑待办事项列表中的特性如何满足用户的需求。在更低级的需求充分满足的情况下，总是为满足最高级需求的特性赋予最高的优先级。

还有一些其它的技术可以用于排定待办事项的优先级，其中许多是基于业务价值或风险的。要了解更多其它有关排定待办事项优先级的方法，你可能会希望 看下Mike Cohn在敏捷2008大会上就这个主题所做的演讲[5]。“验证学习（validate learning）”[4]是一种排定优先级的精益创业方法。这项技术根据最高市场风险选择特性。市场风险最高的特性最先在产品中构建并推向市场，所获得 的经验用于选择下一个特性。

根据Kano模型[1]进行分析是其中一个最著名的排定待办事项优先级的方法。Kano模型非常适用于分类从客户访谈（客户之声[3]）中获得的品质属性（兴奋、期望、不满意、必备，等等）。它侧重于分析用户的满意度，而不是从一般意义上预测对客户而言什么可能有价值。

我的想法和由此产生的NFC方法是一种排定特性优先级和预测用户满意度的理论方法，应该总是通过访谈真实用户、试验和测试来补充使用这种方法得出 的结论。但我相信，当需要找出在客户和用户看来最有价值的特性时，你甚至都不认识他们，这些想法和NFC方法可以提供一个良好的开端和指导。

延伸阅读

[1] Kano模型

[2]James Whittaker，Jason Arbon，Jeff Carollo.《谷歌软件测试之道》，2012，培生教育出版集团.

[3] 客户之声

[4] 验证学习

[5]Mike Cohn. 产品待办事项优先级排序 .

关于作者

Manfred Rätzmann 是E-Post Development公司质量保证部门的负责人。该公司总部位于德国柏林。在加入E-Post Development之前，他是Hypoport AG的一名产品经理，这是一家总部位于柏林的互联网公司，提供金融服务。他骨子里是一名软件开发人员，从很早开始就一直关注敏捷软件开发以及构建高质量软 件的工具和实践。他是“*Software Testing and Internationalization*”一书的作者之一。他已经写了若干文章，并且经常在有关质量和敏捷软件开发的大会上演讲。

查看英文原文： The Hierarchy of Needs