第2部分(第4/4 頁)

ZBB，Zero　Bug　Bounce），　你突然意識到，你又迎來了一個“工作淡季”。任何從事零售軟體產品開發、並且碰到過零Bug反彈的開發人員都知道這個“工作淡季”。但如果你的團隊是提供網際網路服務的，你現在可以停止閱讀了。（等一下，你一開始讀本欄目的時間哪來的？回去幹活！）

作者注：零Bug反彈（ZBB，Zero　Bug　Bounce）描述了第一次出現專案中的所有功能都完成了、並且所有工作條款都解決了的那個時刻。這個時刻很少會長時間持續。透過進一步的系統測試，通常在1小時之內就會有新的問題暴露出來，隨後團隊又必須埋頭去工作。儘管如此，零Bug反彈意味著專案在可預見的將來就要結束了。

零Bug反彈標誌著專案狀態從“瓶頸在開發方”到“瓶頸在測試方”的轉變（“瓶頸在專案經理”沒有類似的這種轉變）。在處理完產品出貨後最初幾周內的一批新發現的Bug之後，大部分開發團隊進入了“時而加速，時而等待”的模式——當有新Bug分配過來的時候奮力去解決它，否則就閒著不知道該做什麼了。

最可怕的是，“工作淡季”有時候可能從零Bug反彈開始，一直持續到下一個版本產品的第一個里程碑。這在大專案中可能有幾個月之多！開發經理手上總是忙著各種各樣的事情，因而很容易就會忽略，其實三分之二的團隊成員都閒在那裡。你知道他們怎麼說閒置人手的——嗯，不是很好聽！

以下是閒置的開發人員經常做的一些壞事：

？ 搶修Bug。零Bug反彈之後，你的團隊應該處於“禁閉”狀態，這意味著，所有Bug在被修復之前都要透過分診會議的慎重考量。閒置的開發人員有時坐在他們的位置上，敲擊RAID（現在叫Product　Studio）上的F5功能鍵等待Bug的出現。如果透過這種方式沒有發現Bug，他們就會把視線轉到正在被分診討論的那些Bug上，挑一�