另外一方面

除了「捨本逐末」以外，在開發過程中，面對開發者「沒時間」的問題，我們試圖從另一個角度來分析。

我們就說我們遇到的是一個明事理、懂是非的老闆好了。也就是，老闆不會因為他把測試工作從你身上抽走後，看你太閒又塞一大堆新工作給你，我們先假設不會。

然而即便如此，你的沒時間的問題也不會被好好地解決。

我們說老闆人很好，所以上一篇中，把工作分給 QA 後，往左的那個代表副作用的箭頭沒出現，然而，因為測式工作是 QA 在做的，你勢必得等，對吧？這就是第一個問題：等待。

你說等待時間你可以做別的事呀！你可以接下一個 case 呀！反正 QA 有測到問題會來找你。是的，試著想像一下，你正對一個技術問題研究到一半，剛見到一點點曙光，正準備要深入研究，或你甚至已經 Code 寫到一半了，這時 QA 來找你，「唰！」地一聲丟一疊 issue 到你桌上。這時我就問，你怎麼處理？要放著嘛…這東西 deadline 快到了，不解也不行，要解嘛，你就大腦已經是滿滿的都是新問題了，一下子要跳回幾天前的思跛，pick up 是要時間的，思考品質也不可能很高。這就造成了第二個問題：Context Switch。

最後，因為 QA 是人不是機器，QA 也有 Context Switch 成本，於是你不太可能做一點改一點就叫人家測，那沒有人會理你，你只好一整批丟過去，對方測完再一整批丟回來。回來的這些 issue，因為這一批受測功能範圍很大，所以你首先要釐清問題就要花較多的時間，其次，就說讓你釐清問題了。一樣地，因為範圍大，所以要查出錯誤的根本成因，也要花比較久的時間。這就是你會遇到的第三個問題：大範圍的程式碼。

如上圖，我們從沒時間出發，因為沒時間所以多分一點測試給 QA 做，這使得長期下來，我們修 bug 的時間越來越長，但我們一天有多少時間是固定的，因此我們拿來做新功能的時間反而變少了！如果各位還記得，圖中右半邊的「R」-- 增強迴路，就是在講這件事情。

飲鴆止渴

上面講的事，其實也是彼得聖吉在「第五項修練」一書中提到的另一個常見基模：「飲鴆止渴」。

我有一個問題，為了解決這個問題所引入的 Solution，表面上解決了我的問題，但它同時也在背後一點一點的傷害我的體質而我卻渾然不知，等到有一天身體出了大問題，這時已傷筋錯骨，再回頭想戒，就很難了。

小結

連續兩篇文章中，我們透過了兩種不同觀點來分析開發者沒時間時，所採取的行動與整個系統的關係。今天我們得到了結論：「因為開發者沒時間而把原屬於開發者的測試工作交給專職做功能測試的 QA，這是一種捨本逐末，且引鴆止渴的行為，決策者不可不慎。」

謎之聲：「欲止渴而飲鴆，欲療瘡而剜肉。」