关于软件采用、问题以及竞争的数据
除了测量程序员技能，目标受众以及那些通过不同方式和软件打交道的人员（外部用户、内部用户、销售和支持人员或者上述所有人员）对软件的接受情况也是关键的测度。收集那些可以指示软件的成功以及人们对工作的响应的质量数据，包括收集关于采用、效益和问题的数据，还可以相对于已知的竞争对手来评估成功。
关注与采用
作为度量系统的基础，确定一个软件产品、项目或者特性是否可以积极或者消极地接受，以及尝试度量这种响应的程度，非常关键。可用来对响应进行跟踪的最基础的指标是使用情况。但是使用情况自身可能不是一个用户对软件的喜欢程度的指标（因为人们可能会采用或放弃的原因有很多，个人喜好只是其中之一）。使用情况的趋势肯定是对响应的一个重要测量。考虑一个软件产品多大程度符合了组织的目标，对关注以及采用情况的度量可以说比其他都重要。
对于响应和使用情况，可以依赖于核心的软件开发团队之外的数据源，例如，从销售团队、客户支持或者产品管理获得的数据。然而，我的建议是，由于响应和使用的数据对于软件团队是如此关键，应该尽可能自力更生并且创建自己收集和测量他们的能力。在某些情况下，你需要的数据可能已经在那里了，但其他情况下，需要做一些工作和规划。好消息是，在网络化时代，对于现在开发的大多数软件，这都是完全有可能的。
为了跟踪关注和采用，我的建议是，让你的软件能够对处在软件评估阶段（如果存在该阶段）的用户进行识别和跟踪，一直到采用和正常使用。这是可以做到的，例如，在软件安装时（对于预制解决方案）或创建用户账户时收集数据。通过区分不同的安装包，或用户账户类型，就可以在评估用户和“客户”之间进行区分——从而你可以就使用情况进行跟踪和报告。这可以通过事务的持续时间、页面访问、事务数或者相似的类别进行。通过这种方式启用软件，就可以在任何给定的时段，跟踪评估用户的数量、客户的数量以及每种类型的用户的活动数量。（甚至具体到特定的特性或软件部分。）理想情况下，如果你对每个创建的用户账户进行跟踪，还可以跟踪到评估者或客户使用该软件的时长的数据。
所有使用情况的数据必须集中地收集——至少在汇总形式方面。如果你使用托管的软件解决方案，那么这个数据可能只需要提取或定期导出就可以了。如果你有一个预制的或分发式的解决方案，那么可以通过Web服务，或者间接地通过电子邮件（这样就可以自动汇总），将诸如安装和用户注册等数据发送到中央跟踪系统。类似地，关于使用情况的数据可以根据固定的周期或者在用户登录时批量发送。根据这里定义的目的，没有必要发送任何用户标识符或任何其他个人数据。使用情况的数据有一些合法的支持用途。在大多数用户和大多数环境中，只要数量不大，都允许这样的系统级的通信。
每个用户的软件使用量的减少也非常重要。通过跟踪这些数字，就能同另一时间比较，并观察趋势。然后就可以把趋势同你对程序员和软件团队收集的其他度量进行比较，从而分析是否存在因果关系。
最后一个要考虑的元素是“采用”的反面，即客户完全停止使用软件。一些用户可能会通过取消账户或卸载软件来为他们的这种意图发出明确的信号。而另一些用户可能只是不再登录软件。有多种方法可以收集这些损失数据。对于用户卸载软件或取消账户的明确情形，可以使软件将这些事件报告给中央追踪系统，从中可以产生适当的报告。对于不采用明确行动但只是停止所有使用的用户，需要拟定另外一种方法。对于预制的解决方案，可以集中跟踪该安装的最后一次使用报告，如果一个安装在一定期限内没有报告，如60天或90天，就可以标记为非活跃。在这种情况下，如果你集中跟踪每个安装的用户数量，就可以确定应该算作非活跃用户的数量。对于托管的解决方案，可以识别如60天或90天的期限内没有登录的用户，可以获取这些账号然后标记为“非活跃”，这样你就不会在未来重复计数（当然如果他们恢复活动，需要将用户的“非活跃”标志删除）。也有其他的一些方法，可以根据你所设置和定义的规则来确定“丢失”或“非活跃”的用户。
尽可能跟踪每个软件产品或项目的关注和采用，我有如下建议：
- 使软件能够跟踪和集中报告不同类型的用户（评估者和客户）的活动以及活动的日期。
- 使软件跟踪和集中报告能够按用户（如登录次数和持续活跃的时间）进行汇总，如果可能，细化到不同的产品领域或特性（如执行一个特定类型的行为的次数）。
- 用软件或数据采集系统来跟踪和集中报告用户的取消、不再活跃或长时间闲置的情况以及检测到的日期。
显著效益
作为发布版的一部分，如果你的目标是在软件中进行重要的改善，来为现有用户以及新用户带来效益，那么为了确定成功的水准，你会希望能找到测量这些重要效益的途径。可以测量成功的方法之一是bug或支持电话的减少幅度，这将在下面讨论。如果结果不能以这种方式测量，还需要找到替代方法。
例如，假设某发布版的一个主要目标是提高用户界面中页面加载的时间，或者改善后端事务处理的速度。另一个例子可能是提高软件的可扩展性，使之可以处理增加的交易负载或者可以存储大量的记录。
在这些情况下，我建议使软件具备收集和汇总统计数据的监控能力，从而允许你跟踪软件是否满足目标，交付期望的效益。这可以使用与前述的使用情况信息相同的方法来得到。首先，需要在软件中添加监控来测量所需的数据，如页面加载时间、交易时间、并发事务数量或者数据库的记录数。然后，可能要添加某些批处理来汇总数据，也许以天为单位，这样就不需要存储所有的细节。最后，为了能够跟踪，还需要传送数据。对于托管或者本地系统的软件，这可能就不必要，你仅仅检索自己的数据就可以了。对于分发式的软件，可以使用Web服务、电子邮件或其他手段以电子方式传输统计数据。
如果你从前还没这么做，那么在做出关键改进时是在软件中加入这种监控的最佳时机。是的，这确实意味着一些额外的工作，但因为可以重复使用监控代码和模式，后续就会变得更容易。其价值相对于增加的工作量而言非常值得。这不仅给了你一个方法，从获得的成功水平的角度来分析所有的指标，同时也给出了数据，可帮助你在将来考虑进一步的改善。尽管你可能没有历史数据来对新的统计信息进行比较，但你仍然可以通过把结果与目标相比较从而测量你的成功。例如，如果你设法把页面加载时间减少到1秒钟以下，通过收集实际的用户体验信息，你就可以知道做得怎么样。
对于不能从监控中来进行测量的目标收益，我仅仅知道唯一一种评估成功的方式——询问。你需要弄清楚软件的增强旨在为谁带来收益，然后从他们身上看到你成功是否。在我的估计中，最好询问一个简单的问题，例如，要求用户就软件是否提供预期的好处回答“是”或者“否”。这种类型的评价不可能应用于每一个bug的修复或增强，但对于你认为应带来显著的效益的工作，如果不能通过软件监控获得，这就是值得的。我不认为仅仅因为工作已经完成了，就假设已经交付了效益。这是不够的。
对于是否值得以及如何进行更广泛的顾客调查或者用户测试的讨论超出了本书的范围。你的组织也许有相应的资源和时间，也许没有。对于进行客户调查或用户测试的组织，存在一个评价你的工作效益的良好方式。不过，无论你是否有这样的能力，我相信软件团队需要能够确认是否达成了关键的目标效益。如果你没有顾客调查或用户测试来回答此问题，你需要找到一种方法来自己询问客户。
你的目标不应该是评估是否实现了合适的需求或者满足了所有的客户期望（这些也是重要的目标，但不是此处讨论的目标）。你的目标是找出你的团队是否成功地交付了程序员希望提供的效益。例如，你可以发送电子邮件到一组目标用户，请求他们告诉你，他们是否尝试了某个新特性，以及是否提供了期望的特性。如果你为了更好的可用性重新设计了一个界面，你可能想要这样询问用户：“是否新的界面提供了更好的可用性？”由于问题的答案将有助于测量你是否达成了目标，因此你要确保所问的问题恰当地反映了你的目标。
为了测量所做的工作是否交付了关键的用户效益，我建议：
- 使用软件来测量、汇总和集中报告相关的数据和关键统计数据。这将会表明是否该软件满足了设定的目标。
- 对于不能使用软件度量到的效益，确定用户的一个目标子集，询问他们一个具体的判断型问题来确定是否他们获得了预期的效益（如果你的组织有一个方法来进行用户调查或用户测试，这个数据可能会以另一种方式获得）。
用户问题
拥有用户是一回事，让用户满意是另一回事。如果你或者组织做顾客调查，那么这是一种很好地了解用户满意度的方式。另一种间接测量用户满意度的方法是跟踪客户支持活动。
产品bug——包括那些由客户报告的，已经作为质量和程序员准确度的一部分跟踪。除了跟踪错误，我建议你对由客户向支持团队发起的支持问题保持跟踪。我的理论是，支持问题的数量和趋势对确定用户满意度的相对水平而言是一个有用的测度。一般来说，如果一切都满意，没有人会联系支持团队。充分满意的用户通常不会联系支持团队。
“支持问题”的定义是宽泛的。可以是与客户支持团队的单次联系，或者是为一个问题进行的多次联系。联系可以是人的接触，通过电话、电子邮件、聊天或者是任何其他电子通信的形式，包括通过通信产品论坛或社交媒体，如Facebook和Twitter。
如果你有一个专门的客户支持团队，他们可能已经跟踪了支持问题，所以你有希望与他们合作来共享数据。如果你没有一个专门的支持团队，那么你的软件开发团队很可能就是支持团队，如果你还没有基础的问题跟踪系统，你需要建立起来。你也应该考虑如何跟踪你所拥有的“外部”支持团体。例如，如果你有一个产品支持网站论坛，在其上用户可以彼此回答问题，你应该尝试跟踪已贴出来的问题信息。
对每个支持问题，我建议尝试找出问题适用的产品领域，并且从顾客的角度来看问题的严重程度或紧迫程度。个人而言，我愿意选择一个很简单的严重性评分系统，如低、中、高。严重程度应该根据客户联系的时候所需要解决的紧迫程度而定。一个仅仅需要花费技术支持人员5分钟的问题也可能是紧迫的。同样，如果你有一个支持小组或良好的支持政策，你则可能有为问题严重程度评分的正式方式。如果没有，定义一个简单的经验法则应该是可以的。例如，如果客户无法使用软件完成自己的工作，这就是高严重程度。如果顾客感到非常不便，但是有一个临时办法，或者可以暂缓，这就是中等严重程度。如果顾客只是感到烦恼，但可以无限期地等待解决，这就是低严重程度。严重程度评分是从客户的角度来看的。它和解决所涉及的问题以及可能需要解决的潜在bug的复杂性无关。
尝试为每个能够反映程序员工作的问题跟踪其产品领域，除了那些显然无关的问题。例如，如果一个客户因为一个账单问题打电话过来，那么可能和软件开发团队无关（除非你构建的是计费系统）。定义产品领域，以及确保技术支持人员知道如何对问题进行分类，都是必要的。客户投诉特性缺失，或者增强产品的要求，在理想情况下都应该单独放置。最后，支持问题的分类可能不是完美的，但不完美的数据仍然是有用的。关于具体领域的呼叫请求的集合是关于客户不满意情况的一个强有力的指标。
因此，作为一种跟踪顾客满意度的方法，我建议：
保持对客户支持问题的跟踪，并按照软件领域进行分类。
根据客户需要解决问题的迫切程度来对支持问题进行评分。
竞争地位
在软件开发中，最后一个测量用户响应的方式是和已知的竞争对手比较关注和采用情况。目标是通过检验你的竞争地位以及是否正在发展、后退或者原地不动，来确定成功情况。如果你的用户群增长了100%，但是你的竞争对手增长了200%，那么你可能会换个角度来看待你的相对成功。或者，如果你失去了10%的客户，但你的竞争对手失去了更多，那么看起来的失败也许在事实上算是部分的成功。
竞争分析、对你的产品或特性与竞争对手进行排名可能会遇到挑战。如果你有可信的分析数据——例如，Gartner公司的研究，特别是如果你工作在一个成熟的产品领域，拥有众所周知的竞争对手，会比较容易。但即使对于小的创业团队，你也可以简单地通过查看和跟踪竞争对手的网站以及他们自称的客户数量或者利润（可以基于从不同途径获取的价格信息转换为客户数）来收集相当多的数据。收集这些数据并在公司内部共享在许多方面都有价值。通常最开始的时候也是最困难的，但一旦你已经开始记录数据，我相信这将证明对于软件开发团队和其他人相当有用，你将发现自己会获得继续向前的鼓舞。一旦基本的方法已经建立，更新数据就是一件相当容易的事情。
我建议你跟踪的首要因素是与主要竞争对手的功能比较。这是一个关于竞争对手缺乏而你所拥有的功能，或者他们拥有而你欠缺的功能的多少的测度。关于“有用”的特性的全部列表的建立有些主观，但一旦建立后，就应该很一致。了解你的功能比较非常重要，因为这影响到你的软件在多大程度上能够获得积极的用户响应。
其他应该尽量跟踪的竞争因素是客户获取。如果你和上市公司存在竞争，你应该可以从他们的季报中获得关于客户获取比例的评分的优良数据。同样再次希望你的营销部门也已经收集了。但如果没有，这也是管理者自己可以做到的。如果你正在与私营公司，尤其是小的创业企业竞争，这个数据可能要困难得多，精度也可能很值得怀疑。在这些情况下，可以从采访、文章、新闻稿或其网站上其他关于顾客数量或收入的信息中收集材料。因为这些数据可能不精确，所以和竞争对手的数据一起保存的还有“信心指数”。例如，如果你的产品在最近一个季度获得了500个客户，你对此的信心指数是100%。根据你对材料的分析，竞争对手A可能获得了300个客户，你可能对这个数字有66%的信心。竞争对手B获得了50家客户，但他们更小，你有更少的信息，所以你对这个估计有25%的信心。保持这样的信心因子很主观，但这是一种确保大多数度量不如其他度量准确的方法。
虽然通常不认为这是软件开发团队自身应该测量的东西，但是我仍然强烈建议你建立一个持续的过程，收集以下的竞争数据，这些数据可能对测量有用，也可以采取多种不同的方式：
- 与竞争对手对比的产品特性。
- 与竞争对手对比的客户获取评分。