在最近的一次活動中，有一位經理把我拉到一邊，對我說：“Johanna，對于敏捷這東西，我總有些不太明白。顯而易見，并不是所有人都被100%利用了?！?/p>

“他們沒有被100%利用又怎么樣呢？你覺得這有問題？”

“見鬼，是的。我付他們工資！因此，我想知道我會從他們身上獲得滿滿的價值！”

“如果我告訴你，你獲得的價值可能比你支付的要多，也許有1.5～2倍，你覺得怎么樣？那樣你就開心了吧？”

那位經理平靜下來，然后轉向我，繼續(xù)問：“你怎么知道的？”

我微笑著說：“以后再告訴你。”

有太多太多的經理相信“100%利用”的神話。那是一種信仰——每個技術人員在每一天里的分分秒秒都必須被充分利用。這個神話的問題在于，人們沒有時間去創(chuàng)新，沒有靈感，也沒時間去探索。

更糟糕的是，還會出現(xiàn)僵局。在一個人被100%利用的情況下，你在A項目上需要他的時候，他可能正在做著B項目。你們無法聚集起來開一個會。你不能打一通電話。你甚至沒有合理的時間去回復郵件。為什么呢？因為你對各種其他打擾已經應接不暇了。

我們?yōu)槭裁磿@樣？

回到早期的計算，機器比程序員要昂貴幾個數(shù)量級。在20世紀70年代，在我開始以程序員身份打工那會兒，那時的公司可能會給經驗極其豐富的程序員支付5萬美元的年薪。而對于那些剛剛從學校走出來的新手，公司支付的年薪可能不到1.5萬美元。我們當時覺得已經賺得非常多了！相比之下，公司可能每年花很多萬美元的錢去租賃機器，或者花數(shù)百萬美元買下機器。你可以看到，薪資水平與機器成本之間相去甚遠！

在電腦有那么貴的時候，我們利用了機器時間的每一秒鐘。為了上機，我們需要登記。我們在桌上檢驗自己的工作。我們進行設計評審和代碼評審。我們珍惜上機時間的每一分鐘—沒錯，我們的工作常常受限于CPU的一分鐘時間。如果你想用更多的時間，那就預約下班時間吧，比如半夜2點～4點。

需要注意的是，那時候珍稀的不只是上機時間，還有內存。在那古老的歲月里，我們的內存只有256字節(jié)，代碼是用匯編語言寫的。我們的代碼要分頁。如果你有一段程序超過一頁，你得在一頁的末尾轉移到另一頁有空的地方，以便于換入。（這常常需要手工完成。噢……我一點也不懷念那個舊年代?。?/p>

到20世紀70年代后期以及80年代，微型電腦的出現(xiàn)拉近了程序員薪水與電腦價格之間的差距。不過，也只有當微型電腦的價格真正下來了、并且個人電腦開始主導市場的時候，程序員的身價才變得比電腦貴多了去了。到那時候，很多人都覺得，讓程序員獨占電腦的工作方式成本更低，這比設計評審、代碼評審或與其他人討論架構更有效。

到了20世紀90年代，盡管電腦、硬盤和內存的價格持續(xù)下跌，程序員和測試人員的身價也變得越來越貴，我們中的一些人清楚地認識到，軟件開發(fā)更多是一種合作，而不只是程序員單獨面對電腦那么簡單。這也便是為什么Watts Humphrey和軟件工程研究所在90年代備受矚目的原因。不是因為人們喜歡繁瑣的流程，而是因為（特別是在一個串行周期里）你必須采取一些措施，以使得系統(tǒng)開發(fā)收獲更大的成功。很多管理者陷入了“100%利用”的思維泥潭。需要注意的是，“100%利用”的概念在當時被提出了沒多久，并且很受重視！

譯者注：Watts Humphrey（1927—2010）在軟件工程領域享有盛譽，被美國國防軟件工程雜志《CrossTalk》評為影響軟件發(fā)展的十位大師之一。他在IBM工作了27年，負責管理IBM全球產品研發(fā)。離任后，受美國國防部委托，加入卡內基·梅隆大學軟件工程研究所（SEI），領導SEI過程研究計劃，并提出了能力成熟模型（CMM）思想。在CMM浪潮席卷軟件工業(yè)界之時，他又力推個人軟件過程（PersonalSoftware Process，PSP）和團隊軟件過程（TeamSoftware Process，TSP），成為軟件開發(fā)人員和開發(fā)團隊的自修寶典。他的著作頗豐，《軟件工程規(guī)范》、《個體軟件過程》、《軟件制勝之道》等都已成為經典。

當一臺單進程的電腦被完全利用的時候，請記住這意味著：它一次只能做一件事；它不能服務于任何中斷；它不能響應任何鍵盤輸入；它不能更新狀態(tài)；它只能一直處理下去，直到完成。

如果程序表現(xiàn)良好，并且不受限于I/O、內存或CPU，運行在一臺單用戶、單進程的機器上，比如只有加減乘除功能的個人計算器，那也許還沒事。但只要你加入另外一個用戶或者另一個進程，你就麻煩了。（或者，如果程序表現(xiàn)不正常、沒能很好地完成，你也會陷入麻煩之中。）

現(xiàn)代的電腦就是那樣。現(xiàn)代電腦都是多進程的機器。

對于多進程的機器，如果一臺電腦被完全利用，你會看到系統(tǒng)抖動，可能還會僵死。想一想高峰時期的公路，沒有一輛車動得了；這時候，公路是被100%利用了啊。但是，我們不想公路被100%利用。我們也不想讓眼前的電腦滿負荷運行。如果你的電腦被用到了50%～75%，你會感覺它變慢了。而高于85%時，電腦會有難以預期的表現(xiàn)。它們的生產力是不可預期的，你無法判斷會發(fā)生什么狀況。

遺憾的是，人類也面臨同樣的問題。

為什么100%利用不適用于人

現(xiàn)在，想一想我們自己。當我們在100%利用的狀態(tài)中時，我們根本沒有閑暇時間。我們在各種任務或干擾之間疲于奔命，沒時間思考。這時候，至少有兩方面的問題：難以避免的多任務，以及沒有思考。

實際上，我們根本不是多任務并行——只不過是快速切換而已。我們不像電腦；電腦在切換時，它們把內存里的東西完美地拷貝到磁盤上，當需要換入的時候，能夠再次把數(shù)據(jù)讀進來。因為我們是人，我們不能完美地把我們腦子里的東西備份出來，后續(xù)也無法再完美地恢復。因此，切換是有成本的，因為我們在處理其他事的時候必須記住之前腦子里在想的東西。那也需要占用時間。

因此，這里有一個情境切換的問題，我們需要花費時間把腦子里的東西換出去、換回來。所有這些時間和不完美會累加起來。因為我們是人，我們不能為各個任務完美地分配自己的時間。假設我們手上有3個任務，我們不能做到在每個任務上花費33%的時間——只要我們樂意，我們想在一個任務上花多少時間就花多少時間，平均33%只是一個假設罷了。

接著，讓我來解決100%利用中沒有思考的問題。如果你想讓大家考慮換一種新的工作方式，怎么辦？如果你令他們滿負荷地工作，他們會嘗試嗎？沒機會！他們不會考慮，因為他們沒有時間。

因此，你讓大家機械地工作：用他們了解的最佳方式去服務于各種中斷、做盡量小塊的工作、做到足夠多就算通過。他們不會想辦法去提高。他們不會想辦法去幫助別人。他們不會嘗試創(chuàng)新。他們只是在想，“我怎樣才能從這堆積如山的工作中解脫出來？”這對他們來說是很恐怖的，對產品也不好，對與他們打交道的任何人都不好。

當你讓人們工作在100%利用的狀態(tài)，與你計劃讓他們每天大概只干6小時的技術活比起來，你從他們那里得到的工作成效會小得多。人們需要時間去閱讀郵件，去參加臨時的會議，休息一下，進行一些架構方面的討論，喝杯咖啡，或者做點別的什么事。如果你為上午計劃一大塊的工作，為下午再安排幾個大塊的工作，并把會議的數(shù)量降到最低，技術人員會很好地完成分配給他們的工作。

如果你在一個喜歡開會的組織里工作，你甚至不能計劃每天6小時的技術活——你必須計劃得更少一點。會議在浪費人們的時間。

但不管怎么樣，如果你按照100%利用來計劃，在整個組織范圍內完成的工作會少得多。你營造了一個可怕的工作環(huán)境，這還是一個沒有創(chuàng)新的環(huán)境。那不像是一條成功之道，是吧？

敏捷和精益讓神話破滅

敏捷和精益不會使“100%利用”煙消云散，但它們讓神話破滅了。通過把所有的工作裝進Backlog（一個管理積壓工作的倉庫），這有助于管理層和研發(fā)團隊看清楚每個人應該做的事情，以及大家面臨著多大的挑戰(zhàn)。這很不錯！

一旦每個人可以把工作可視化，你就能圍繞它開展工作了。也許某些工作確實與產品路線圖相關，但不必在這個迭代里完成。也許有些工作是為另外一個項目做的，應該被推遲到下一個迭代周期。這很好——這就是項目組合管理。也許有些工作應該由某人來做，而不是這個團隊來做。這很好——相關管理者需要出面協(xié)調。

不管你做什么，只有你看到了工作，你才能有所作為。只要你完全地把工作可視化，你就能管理。

記住，如果你被100%利用，那就沒人能做事了。如果你想為你的組織貢獻實足的價值，你需要讓自己被“利用”到50%～60%。因為浪費思想（不管什么思想）是件可怕的事。