在這個系列的一開始，有提到我們是如何衡量事情的重要性和急迫性，而我們衡量的標準都是蠻主觀的。

在另外一個層面上，我們對自己所花的時間和投入的地方，也很容易失焦，自己的認知和事實其實並不相符的。

驚人的真相

每次加入一個團隊，我都會問團隊成員，通常做「這類型」的專案，所花費的時間大概多久？

有人會回答，大概一個月，有人會回答，大概一個禮拜，也有人回答更久，三個月到半年都有。

因為大部分工程師都只把自己的工作範圍看得很狹窄，所以他們的回答都是以自己的工作範圍來回答，專案上線後，才發現之後為了這個專案所花的維護成本，遠遠超過了開發成本，
如果還要在這個專案上繼續投入開發，那麼維護成本就會越來越高，而且這個專案的維護成本，也會影響到其他專案的開發進度，這種雪球效應，很容易讓團隊陷入無法自拔的困境。

20%的開發，80%的維護

有這樣的錯覺也有可能是因為，我們會認為這些「維護」是正常的，所以不會把這些時間算進去，但是這些「維護」其實是可以避免的，只是我們沒有把這些「維護」的時間算進去，所以才會有這樣的錯覺。

以下是以小團隊為單位，每次投入的開發和維護時間，可怕的是，通常開發團隊都是同一個的話，那麼維運和開發很常就會並行，甚至無法進入「正常開發」

FID希望解決問題，是在開發的前花更多時間去準備調研，在第一次執行，會花差不多的時間，之後每次執行，就會越來越快，而最後我們會累積技術成一個製作流程，透過流程解決後續進來的專案。

收集資訊，計算基本成本

在開始之前，可以先從這些方面收集資訊，來計算基本成本，這些資訊必須包含：

1. 每週（或每日）的工作時數和投入項目
2. 將每個工作項目標籤化，並且分類
3. 只要花時間，都算項目，例如協助其他同事解決問題，或是協助其他同事測試功能

在過去大約50名的members，長達數年累積下來的數據，我看到幾個驚人的數字（以下數字僅供參考，樣本有限，有部分紀錄是根據個人的管理紀錄和心得）

1. 在沒有任何管理制度下的團隊，每週平均維護成本，佔了總工作時數的 20% ~ 30%
2. 在專案上線後（迭代專案不計算），維護成本會持續增加，佔了總工作時數的 30% ~ 50%（包括功能開發，bug修復）
3. 每個工程師長期只能投入在 1 ~ 2 個專案，甚至同一個專案跨度超過 1 年以上
4. 每個工程師每週平均只有 40% ~ 60% 的時間，可以投入在新專案的開發上
5. 工程師在半年後出現 burnout 的機率，超過 50%（面談結果的估算）
6. 工程師在半年後出現職業倦怠的機率，超過 30%（面談結果的估算）

這些數字代表什麼？

這只能解釋一件事，我們看到的是一群工作的人，但是他們的工作效率，其實只有 40% ~ 60%，並不是因為他們不努力，而是因為他們的工作環境，讓他們無法發揮 100% 的效率。

這不但累了工程師，也累了團隊。

衡量的標準

1. 專案啟動調研到開發上線，所花費的時間和人力資源
2. 專案上線後，每週的維護成本和開發成本
3. 每週會議所花的時間
4. 每週的工作時數和投入項目