案例分享：赛季的最有价值球员
球类运动中有一个最有价值球员奖项（Most Valuable Player，MVP）。它会从一个团队或联赛的所有球员中评出。这个概念很简单，在一个赛季结束时，奖励为球队取胜做出最大贡献的球员。当在联赛中评选时，该奖项可能会给予整体表现最佳的球员。
我考虑过是否在软件开发团队中也应该评选MVP奖。基于年度进行奖励，这可以作为一种强调和鼓励团队为导向的技能的方法。由于该奖项的颁发将向受众强调这些指标，因此选出一个MVP可强化程序员对团队贡献的价值度量。奖励可能是一块牌匾，甚至现金。可是我却从来没这么做过。我对给予个人的奖项不喜欢，因为我担心这会导致不满或其他问题，反而事实上不利于团队。尽管如此，类似于MVP的面向团队的奖项却是值得考虑的。
尽管我从未颁发一个MVP奖，但是我有关于一个对该奖项显然受之无愧的程序员的故事——如果该奖项存在的话。在这个案例中，它是如此清晰，以至于我不认为它会产生任何争议或团队内的嫉妒，而是当之无愧的和积极的奖励。
我们处在一个产品的创业阶段，刚刚发布了第2版。在发布第2版的后续6个月中，我提到的这个程序员并没有负责任何新的特性或者增强。因为在这段时间里，这个程序员必须要做：
- 每周花费大约15小时来响应电子邮件或处理新客户和潜在客户的支持电话，包括在深更半夜呼叫有时差的偏远地区。
- 5次到客户现场以协助大规模部署。
- 诊断并修复了超过30个严重的产品bug。
- 我们的产品需要和那些“过时”的但是关键客户仍然在使用的技术协调工作。
- 以远远超出我们预计的速度，调整了关键后端进程的性能，使得可以处理更多记录和更复杂的交互。
有好几个原因导致了这个程序员承担了所有这些工作。他领导了对大规模部署很重要的配置和后端集成工作，并且这个领域需要对外提供许多支持。这个领域也出现了很多bug，因为集成需要处理许多未预见或者未测试的场景。此外，该程序员特别擅长和支持团队以及我们的现场工程师一起工作——部分是因为这个程序员性格很好，部分是因为该程序员乐于提供支持。还有，该程序员年轻而且单身，所以深更半夜工作或者紧急出差不会造成个人问题，甚至在某种意义上，程序员还乐在其中。
在这段时间里，我们转化了超过24个潜在客户，而且绝大多数成为长期的、满意的客户。该程序员修复的错误和完成的改善是促使产品获得进一步成功的重要部分。而且该程序员在此期间的工作保护了团队的其他成员，允许他们可以继续关注于产品的改进。
毫无疑问，这个程序员是该“赛季”中这支球队的MVP。如前所述，虽然我并没有真的颁发MVP奖，但我还是发现这是评估度量的广度和深度时值得牢记的有用概念。我的理论是，使用的任何度量系统都应该有足够的描述性和准确性用来支持MVP的选择。按照这个理论，显然应该有跟踪辅助性工作的度量，并且对于例外的工作量应该有特殊的标记，例如加班或者出差。此外，如果没有对产品发布之后的工作的度量，例如，现场错误的修复和产品调优，我也无法识别MVP。因为MVP应该通过对组织的贡献来测量，显然也应该存在这样的度量：能够适当地追踪和评估程序员将市场机会转换为业务的能力，以及针对未来有类似需求的客户进行适配的能力。
在我的例子中，该MVP由于其对队友的价值，对客户的价值和商业的价值，显然可以在团队中获得认同。无论你是否真的评选程序员中的MVP，你都能够检查你的度量是否足够全面以及有意义，即如果你选出一个MVP，你收集的数据就有助于支持你的选择。
