到目前为止，在社区指标剧本专栏中，我已经讨论了设定目标以指导指标流程的重要性，概述了可用于研究您的社区的通用指标类型，并回顾了可用工具的技术细节。当您决定要为您的社区跟踪哪些指标时，更深入地了解每个领域非常重要，这样您不仅可以选择好的指标，还可以了解和计划当数字与预期不符时该怎么办。
在评估您正在考虑纳入指标计划的特定指标时，您应该回答四个问题
- 它是否有助于实现我的目标？
- 它的准确性如何？
- 它与其他指标的关系是什么？
- 如果指标变“坏”了，我该怎么办？
与目标相符
从我之前关于目标的讨论来看，这一点现在应该很明显了：您为什么需要知道这个指标？这个指标与您的项目目标有关系吗？如果没有，那么您应该考虑忽略它——或者至少减少对它的重视。对实现目标没有帮助的指标会浪费时间和资源，而这些时间和资源本可以更好地用于开发更好的指标。
需要考虑的一件事是中间指标。这些指标可能与您的目标没有明显的直接关系。当单独考虑时，它们可能是危险的，并且可能导致不良行为，仅仅是为了“达到数字”，但当与其他中间指标结合并在上下文中解释时，可以帮助项目改进。
准确性
准确性定义为正确或精确的质量或状态。衡量具有内置主观性和偏差的指标（例如调查问题）的准确性很困难，因此在本次讨论中，我将讨论通过计算机获得的目标指标，这些指标在很大程度上是高度精确和准确的。数据不会说谎，那么我们为什么还要讨论计算指标的准确性呢？指标不准确的潜力源于人类的解释。这里的经典例子是下载次数。这个指标很容易衡量——通常作为下载站点内置指标的一部分——但如果您的软件被分成多个包，或者已知的系统流程产生人为夸大（或缩小）的数字，例如执行重复下载的自动化测试系统，则该指标将不准确。
只要您认识到并避免固执于绝对正确性，那么拥有略微不准确的指标通常也比根本没有指标要好。由于 Web 服务器、浏览器、代理、缓存、动态寻址、Cookie 和其他可能混淆访问者参与度指标的计算方面的底层技术性质，Web 分析臭名昭著地成为不准确的现实衡量标准；然而，随着时间的推移，多个略微不准确的 Web 指标可以准确地表明您所做的网站刷新使您的重复访问量减少了 30%。因此，不要害怕您可能永远无法实现 100% 的准确性。
理解关系
数据来源：NHTSA, DOT HS 810 780。美国农业部 (pdf)
指标的领域充满了源于统计短语“相关性并不意味着因果关系”的例子。在选择指标时，仔细考虑所选指标是否可能与其他指标直接或间接地存在关系。相关的指标通常可以帮助诊断成功和失败，并指出您的项目需要进行的更改，以推动您正在寻求的改进。
真正证明一个指标的行为会导致另一个指标的可预测变化需要大量的实验和统计分析，但您不必做到那一步。如果您怀疑存在某种关系，请记下并观察它们随时间的行为，如果证据表明存在关系，那么您可以在自己的项目中进行实验以检验该假设。
例如，开源项目的典型目标是通过吸引新的开发人员来推动创新，这些开发人员将他们多样化的经验和背景带到项目中。一个给定的项目注意到，当“从贡献到代码提交的平均时间”减少时，来到项目的新贡献者的数量就会增加。如果随着时间的推移，证据保持这种相关性，则项目可能会决定投入更多资源来处理贡献。这可能会在其他地方产生影响——例如，由于大量新代码的涌入而导致错误增加——因此在使用您新发现的知识时，请尽量不要过度旋转。
为失败做计划
在评估指标的准确性和适用性之后，您需要思考和计划当事情没有按计划进行时（这将会发生）您将做什么。考虑以下情景：您为您的项目选择了几个与质量相关的指标，并且普遍认为它们对于项目是准确且重要的。QA 团队正在努力工作，但您选择的指标仍然持续恶化。您会怎么做？您有几个选择
- 什么都不做。
- 让 QA 团队周末来编写更多测试。
- 与开发人员合作，找出所有错误的根本原因。
- 选择不同的指标。
哪个是正确的选择？答案不应该让您感到惊讶：这取决于。如果趋势是预期的，例如，如果资源限制迫使您为了其他一些指标而牺牲质量，那么您可能不需要做任何事情。如果您已知测试覆盖率较差，那么 QA 实际上可能需要编写更多测试。或者您可能需要对开发中的系统性问题进行根本原因分析。最后一个在任何计划中都特别重要；您的指标可能已经过时，不再与您的项目目标保持一致，应该定期评估并在需要时删除或替换。
很少会有一个唯一的正确选择——更重要的是，对于每个指标，概述失败的潜在原因，以及您需要提出的问题以及在各种情况下您将做什么。它不必是每个可能原因的冗长行动清单，但您至少应该列出一些潜在原因以及如何继续调查失败。
通过回答关于您的指标的这四个问题，您将更深入地了解它们的目的和有效性。更重要的是，与项目的其他成员分享答案将使您的社区成员拥有更大的自主感和目标感，这可能比仅仅要求他们达到一组看似任意的数字更能激励他们。
评论已关闭。