在体育运动中，每个团队都为胜利而战，而成功的定义也很清晰、精确。软件开发与此不同，我们缺乏对成功的恰当测度。我所发现的最佳策略是软件开发团队的成功三角形，它基于三方面的因素：客户响应、质量指标和效率。这些都能按发布版、特性来测量，并且可以相对于先前的水平、团队目标和组织目标加以评估。
开始时，你可以考虑以三个月为周期测量用户对新发布版的采用率是否达到了20%。你能够同设定的目标相比较。为客户响应、质量指标和效率进行这种检测，为团队提供了一种客观及全面的方式来分析团队成功。从历史上看，产品经理负责收集这样的数据，事实上你也确实可以从产品管理团队获得部分或全部数据。但我相信，这一数据更应被软件开发团队自己定期和仔细地研究。无论你是否有产品经理的协助，你都应该努力收集这些数据。建立一种测量进步和成功的方法，是能够识别软件团队成功的模式和有利因素的基础。测量成功或失败的第一部分是测量响应。当客户尝试或测试产品或特性时，他们的响应明显地呈现了关注度。它包括采用（当客户对产品进行注册时），或选择购买或积极地使用产品或特性。测量消极响应也很重要，例如当客户选择停止使用某个产品或特性时，或者当客户测试了产品或特性，但后来决定不使用它的时候。显然，客户的某些选择不能直接反映软件开发团队的情况，例如，客户之所以选择不买产品是因为价格或产品本身以外的其他一些因素。但是，由于缺乏更精确的方法来测量产品的成功，客户关注与否、采用与否，是我们大多数人所拥有的最佳指标。客户可能是付费用户，也可能是非付费用户。当为自己公司内部提供工具或开发项目时，也可能是内部用户。很多人把产品的成功和收入相关联。当前以及估计的产品收入对于建立预算和产品规划显然是重要的，并且在一定程度上，程序员关心收入和预测也是健康的，这样他们可以了解业务决策和产品规划的缘由。但是显然，在某些情况下，收入并不合适，因为某些产品或特性可能不收取费用。而且，即使在收入存在的情况下，我认为最好也是关注用户数量和使用量。我感到当人们查看收入的时候，倾向于将重点放在现金上（这可能导致他们过分关注与收入相关的指标，而不是其他同样或更重要的指标）。同时，人们更易于对大额的收入留下深刻印象而对少量的收入漫不经心，虽然他们可能都不是关于成败的准确指标。例如，如果一个产品挣了1000万美元，这令人印象深刻，软件开发团队的感觉良好以至于会无视讨论的其他方面。但如果客户采用率存在10%的下降，并且距离组织目标有33%的差距，团队也许有些问题。单纯对收入数字的关注可能会导致程序员不能完全明白实际结果是如此糟糕。或者，考虑产品仅仅挣了5000美元的情况。无论在其他方面如何，团队会对自己以及结果都感觉不太好。但如果其实客户采用率在快速增长（或许这是一个只是售价2美元的手机应用），那么这可能是一个了不起的结果。关注用户数而不是收入，你能够消除或者至少降低一些主观方面的副作用。在许多场合讨论收入可能是有价值的，但作为一个软件团队经常审视的度量指标，我认为会分散他们的注意力。
尽管我不建议使用产品的收入进行比较，但我极力推荐你弄清楚产品与竞争对手相比如何。这是另一种评估你的产品在顾客关注度和响应方面做得如何的方法。为了能获取这些数据，你可能会在产品特性或用户采用方面与竞争对手进行排名。也可能有可供使用的第三方的竞争力分析。当然，排名情况并不仅仅归因于程序员和软件开发团队。市场营销、销售以及其他许多外部因素，包括企业规模和经营时间都可能会影响你的产品的竞争地位。因此竞争力的排名并非你成功的唯一测量标准，而是为你评定相对成功水平提供了一个额外的输入。
软件质量的测量是成功测量的另一个方面。通常，在这方面有一个很好的测量，就是生产过程中发现的bug数量。客户支持问题的数量和频率也是产品质量的一个间接测量，同样也包括客户的感受。成功或失败取决于对质量测度的趋势的研究，以及和目标进行的比较。随着时间的推移，质量测度的趋势不仅仅揭示了每个后续发布版的成功，而且揭示了成功的软件架构和设计。
决定软件开发团队的成功的最后一个测量的因素是效率，也就是说软件团队在预算限制内、在某一特定时间内能够提供多少功能。团队的工作效率和交付速度可以相对于过去的业绩、团队的目标来测量，从而决定成功的程度。非常低效的团队即使取得了良好的质量和正面的用户响应，可能也不能看做是成功的。同样，一个软件团队虽然准时地发布新版本，但顾客的响应不佳或质量糟糕也不是成功。这是为什么我建议查看所有的三个领域：响应、质量和效率。
相关资源：七夕情人节表白HTML源码(两款)