前言

在这个蔬菜是有机的、水果都会甜、衣服耐洗不缩水、满街百年创始老店、车子很省油、房…的社会当中，只要我们肯问，大概都能得到一些标准回答，甚至还会有数字佐证。

我们是否已对数字习以为常，极度仰赖它进行决策呢？一起来看看数字背後有什麽我们可以再思考的地方。

量化

在求学阶段的课程、各方文章、书籍，时常看到「没有量化，就无法管理」这样的说法，通常会再搬出管理学之父「彼得・杜拉克」的名号，但在撰写这篇文章时，为了考证此言出处，找到一篇文章「过度神话的「可测量性」：从管理学到哲学的视角」对这件事做了澄清。

但不管是谁说的，透过量化进行管理在现代来说看起来天经地义，也确实有各种管理的手段、方法、理论在探究「量化」这回事，因此这个主题不是在挑战量化管理，而是想要醒量化之下潜藏的疑虑。

量化後的结果可以方便我们看出结论、看到变化的轨迹与趋势，从而产出管理应对方针。量化过程把复杂的现实「摘要」成可以比较的数字，期望将杂讯给过滤掉，这容易落入「类比转数位」的挑战中，现实有些东西是数字难以表达的。

我们必须谨慎面对数字，评估它的可信度，了解它如何产生、如何被记录的、如何被计算的？以及，谁来确保这个数字的有效性？

真切知道数字只是一种「代表」，虽然有些无奈，若数字传达不怎麽好的提示时，先不要妄下定论，即使这样很节省时间。真正走入团队，与参与者一同看到问题，思考如何解决才是关键。

量化陷阱

正因为量化是那麽梦幻，好似一瞬间简化了各个问题，以为我们可以透过仪表版掌握一切。若就这样一路发展下去，恐怕是另一条歪路的开始，一些被拿来揶揄的 KPI 就是一种体现，例如：

• 程序码行数
  • 对於一位知道自己在做什麽的工程人员，如果被要求程序码行数，大概会回敬一股尴尬又很想失礼貌的假笑，直到他真的确认事实是如此，真的要如此衡量，便会毫不费力达成目标。
• Commit / Push 次数
  • 一样的道理，要刻意冲高 Commit 与 Push 一点难度也没有。
• 工作时间
  • 做越久，越努力。真的吗？聪明的你马上发觉这之中的怪异了。
  • 我们怎麽取得时间资讯？所有成员的时间流速是一致的吗？
• Bug 修正数 (与任务完成数)
  • 修了越多 Bugs 越好吗？这还得思考这麽多 Bugs 是好事，还是坏事呢？
  • 每个 Bugs 难度都相同吗？那难度又该如何量化呢？
• 测试覆盖率
  • 我们了解帐面上的 90% 究竟是怎麽来的吗？它是 Line coverage？还是 Branch converage？

以上任何一条，单独来看，显然都有对应冲高的技巧，而且普遍相当简单，我们不会希望团队专心在这些事情上面，这很可能将团队推向一个奇怪的方向。

就算数字是对的

就算团队真的找到有用的指标，也用了很好的统计方式，确保这些数字是精确反应现况，具有代表性的，接下来问题也还没有结束。

自己的谎言

我们自己如何理解数字，有可能受到经验与偏好影响，一不小心产生专属於自己的谎言。不乐见的情况是，为了证明什麽，联合了许多支持自己观点的数字来备书。

总之，心态要健康且开放，从数字嗅到问题时，应该同时兼具广度与深度的观察，避免不必要的张扬与指责，不妄下评断，也是一种「尊重」的展现。

90-90 法则

90-90 法则 (Ninety-ninety rule) 来自一句格言，我们可以在《More Programming Pearls》一书当中找到。在谈论专案管理时，我们可能也听过 90% 症候群 (90% syndrome)，在概念上基本是一致的。

这边参考该书的简中译本《编程珠玑：续(修订版)》之箴言集章节，它是这样描述的 (以下仍保持简中版的用词)：

前 90% 的代码占用了 90% 的预定开发时间，余下的 10% 代码又花费了 90% 的预定开发时间 －－ Tom Cargill，贝尔实验室。

我特别把它归到「就算数字是对的」环节来讨论，是因为 90-90 法则有各种应验的可能，就算我们避免人为因素，仍然无法保证其他不可抗力事件的发生，因此 90% 的表象可能是一个暂时结论，对於专案进展而言，该有的备案与应对措施仍然会需要，不宜过度乐观。

二元对立

我在「面对拒绝」有提起二元对立，今天趁这个主题做一些补充。

二元对立的例子包含「对」或「错」；「是」或「否」；「好」或「坏」，二元只是基础，普遍存在於生活的每个角落，真正带来误会的是二元之间的「比较」，也就是「对立」。

比较无所不在，但现实往往是复杂的，若把事情精简为两个端点，在这种情况下进行比较，必须承担见树不见林，或见林不见树的风险。这时候我们又会抓取更多比较项目，进行一连串的比较，经过无数「二元对立」的运算後得到我们想要的结果，例如：绩效评估、贡献排行。

随着经验累积，我们渐渐会知道对於他人的评断，不应该是果断的「谁是好人，谁是坏人」，在团队内的运作也是这样，没有绝对好的成果，也没有绝对不好的失败，同时一件事情的好与坏也是因人而异的，事情本身没有绝对好坏。

以 Scrum 的冲刺来说，有没有达成冲刺目标(Goal) 可能会是个武断的判断，也有团队选择将所有 PBI 都完成才视为完成，这种「完成」与「未完成」也是一种对立。假若真的遇到「未完成」的情况，团队也不需过度灰心，按照价值排序理应会有高价值的东西被实作，并且透过接下来的回顾反思一下，找出对未来更好的尝试，这是敏捷精神的积极发挥。

估算陷阱

最後，再谈点在 Scrum 当中时常被讨论且富有争议的议题－－「估算」。

我们通常会透过 Planning Poker 或 T-Shirt Size 的方式对 PBI 进行难度的估算，同时为了避免估计上的讨价还价，以及过早陷入时间的谜思，我们更会选择为 PBI 估计故事点 (Story Points) 而非时数。在这个过程中，团队若相当在意估算的准确度，开始烦恼该如何估计，质疑这套估计方法是否准确，就相当可惜，因为忽略了这个估算活动背後可以带来凝聚共识、认知校准与厘清问题的好处。

以 Planning Poker 为例，通常以费式数列来编排，因此 Poker 点数可能是 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144，采用这种方式有助於快速收敛，让团队不落入细微数字上的纠结，这套方法无法产出最精确的估计，仅呈现了相对的比较结果，更多的是作为一种促进沟通的工具。

在站传统工作规划的观点上，Scrum 这种估算方法相信会带来很大的冲击，但这也只是明白地展现「没有精准的估计」这个概念，特别是在软件开发这种变数多端的工作当中。试问，原本的估计方式又有多大的准确度呢？既然估算难以精准，团队若想要改善什麽，应该是强化应对能力，让自己能够在各种充满变化且不准确的情况下仍然可以运作。

後记

面对数字，我们也有保持开放的态度吗？