從吉野家到人月神話

中午出門吃午餐的時候,正好是中午用餐的時間,附近的幾間店裡客人都不少。如果要在店裡等座位恐怕會花不少時間,於是臨時決定去買吉野家當午餐。這間吉野家走路過去不要三分鐘,因此經常是銀狐不知道該吃什麼時候的選擇。

像是吉野家這樣的店,某個程度來說算是中式的速食店,因此從客人上門到客人拿到餐點的時間通常不應該太長。不過今天中午為了買這個吉野家,包含來回的走路時間卻花了將近三十分鐘的時間。如果扣掉來回路程的十分鐘,那麼光是在店裡等這個午餐就花掉了二十分鐘,就花費的時間來看可是一點都不『速』。為什麼會發生這樣的狀況,除了因為中午用餐時間客人很多以外,當然還有其他的原因。

銀狐走進這間吉野家的時候,在銀狐前面的只有一對父母和一個小孩子,他們點了兩份套餐和一碗牛丼。接下來就是銀狐,銀狐也只點了簡單的年丼。照數量來算,銀狐的這份餐點也不過是第四份,怎麼算都想不到會這樣一等就等了二十分鐘。到底發生了什麼事,請看銀狐以下的說明。

當時店內有兩名店員,其中一位在櫃台負責點餐(以下簡稱A),另一位在後方的廚房負責出餐(以下簡稱B)。在銀狐後面又陸陸續續的進來了不少客人,因此A就一直守在櫃台幫客人點餐,然後將客人點的餐點用麥克風報給B聽。照理來說,B應該聽了A報的內容就會根據這個開始準備餐點,然後依順序將餐點一一完成才對吧。不過在廚房的這位B似乎非常專心的準備第一組客人的餐點,因此他完全沒有在理會A報的餐點,等到手上的餐點弄得差不多的時候,B就從廚房探了頭出來問A接下來要出那些餐點(換句話說,剛才報了那麼多是在報好玩的嘛?)被櫃台工作綁住的A一方面要應付點餐的客人,另一方面還要不時的回答B的問題(為了重報餐點,他還要翻閱剛才的點餐記錄),於是A送出來已完成的餐點就這麼放在出餐口,第一組客人的餐點就這麼放在那等了好久。

就這樣混亂了一陣子,從顧客用餐區又出現了第三位店員(以下簡稱C)。或許他原本是在用餐區收拾客人用餐結束的餐具,所以現在收拾的工作結束就回到櫃台來幫忙。這個第三名店員的出現,代表著有增加額外的人力,照理來說應該可以解決目前混亂的狀況吧。結果這位C走進了廚房,開始協助B進行出餐的動作,但是C剛才根本不在廚房,完全不知道接下來要準備什麼餐點,於是C向B詢問接下來要做什麼;然後B因為C的出現跑到櫃台前,想將原本放在出餐口的餐點交付給客人,但是剛才負責點餐的人不是他,他根本不知道那份餐點是那位客人的,於是B又向A詢問餐點是要交給那位客人,於是A又被打斷了點餐的動作來說明。

有一本知名的書叫作『人月神話』,裡面提了許多軟體產業對於人月這個數字的迷思。其中有一段話相當的有趣:

生小孩就是需要九個月,你叫多少個媽一起生都一樣。軟體工程就是像這樣的工作,因為它必須除錯,而除錯就具有連續性的本質。

對於許多以為『增加一倍人力就可以縮短專案一半時間』的管理階層來說,這一句話說得其實非常的有道理。有些工作,並不會因為增加了一倍的人力就可以增加一倍的產值,因為在增加人力的過程中,溝通和協調的成本也會隨著增加。而沒有妥善規劃的人力增加,其實只是造成沒有意義的人力浪費。

就以剛才吉野家的這個狀況來看,當C出現的時候,A應該要指揮他去進行特定的工作(因為A是店內目前最瞭解客人點餐狀況的人),像是指揮C去將B送到出餐口的餐點交付給客人,就是A可以做的選擇。這樣的作法,不用改變B目前正在進行的工作,他可以繼續進行準備餐點的動作,而原本卡在出餐口的餐點,也會因為增加了處理的人手而解決問題。當然A也可以叫C接手點餐的工作,因為接下來的點餐都是新的需求,不會改變到目前正在進行中的工作。而A可以憑著剛才幫客人點餐的記憶,將送到出餐口的餐點一份份交給客人,也是解決當時店內處理速度太慢的方法之一。結果當時在吉野家店內卻出現了沒有效率的人力運用方式,反而造成了更多工作進度上的延誤。

買個吉野家也可以想到這麼多,我病得真是不輕呀 …. ()