前言

在這個蔬菜是有機的、水果都會甜、衣服耐洗不縮水、滿街百年創始老店、車子很省油、房…的社會當中，只要我們肯問，大概都能得到一些標準回答，甚至還會有數字佐證。

我們是否已對數字習以為常，極度仰賴它進行決策呢？一起來看看數字背後有什麼我們可以再思考的地方。

量化

在求學階段的課程、各方文章、書籍，時常看到「沒有量化，就無法管理」這樣的說法，通常會再搬出管理學之父「彼得・杜拉克」的名號，但在撰寫這篇文章時，為了考證此言出處，找到一篇文章「過度神話的「可測量性」：從管理學到哲學的視角」對這件事做了澄清。

但不管是誰說的，透過量化進行管理在現代來說看起來天經地義，也確實有各種管理的手段、方法、理論在探究「量化」這回事，因此這個主題不是在挑戰量化管理，而是想要醒量化之下潛藏的疑慮。

量化後的結果可以方便我們看出結論、看到變化的軌跡與趨勢，從而產出管理應對方針。量化過程把複雜的現實「摘要」成可以比較的數字，期望將雜訊給過濾掉，這容易落入「類比轉數位」的挑戰中，現實有些東西是數字難以表達的。

我們必須謹慎面對數字，評估它的可信度，了解它如何產生、如何被記錄的、如何被計算的？以及，誰來確保這個數字的有效性？

真切知道數字只是一種「代表」，雖然有些無奈，若數字傳達不怎麼好的提示時，先不要妄下定論，即使這樣很節省時間。真正走入團隊，與參與者一同看到問題，思考如何解決才是關鍵。

量化陷阱

正因為量化是那麼夢幻，好似一瞬間簡化了各個問題，以為我們可以透過儀表版掌握一切。若就這樣一路發展下去，恐怕是另一條歪路的開始，一些被拿來揶揄的 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 這種估算方法相信會帶來很大的衝擊，但這也只是明白地展現「沒有精準的估計」這個概念，特別是在軟體開發這種變數多端的工作當中。試問，原本的估計方式又有多大的準確度呢？既然估算難以精準，團隊若想要改善什麼，應該是強化應對能力，讓自己能夠在各種充滿變化且不準確的情況下仍然可以運作。

後記

面對數字，我們也有保持開放的態度嗎？