曾經有學員在課程的中場休息時間跑來問我 :「老師，我們公司都是一個人要同時負責好幾個案子的，你講的『專職專注在一個專案上』，根本就不可能實現的啊？那是不是我們公司就無法使用敏捷方法了？」
這位同學的問題其實有兩個，一個是「一人專職專注在一個專案上」，另外一個是「公司適不適合使用敏捷方法」。
說實話，這兩個問題不只一個人問過，我相信，這必定也是許多對敏捷方法有興趣的人心中的疑惑。既然如此，我們就先來聊聊「一人專職專注在一個專案上」這個主題好了。畢竟，在現今的職場環境當中，能夠專職專注在一個專案上的人，還是屬於較為少數的。
我們先倒過來問一下這個問題：一個人同時負責多個專案，真的就會降低個人和團隊的工作效率嗎？
過去的職場經驗教會了我一件事，就是在回答別人一個問題之前，一定要再先多問對方幾個問題！這是什麼意思呢？例如，像上述的問題，我就會多問對方下面的幾個問題：
- 此人在這幾個專案中，負責的工作內容是屬於創意型還是屬於勞力型的工作？
- 此人在這幾個專案中，負責的工作內容的相似度有多高？
勞力型或相似度高的專案工作
我們知道一個專案之所以是「專案」，就是因為她有「新東西」要被產出，這個新東西可能是個全新的功能特色（feature），也可能只是舊功能的小改版（improvement）或錯誤修正（bug fix）。然而，很少有產品是所有功能特色都是從頭到尾全新打造的，大多數所謂的「新產品」其實都是舊款產品的「改版」。
改版型的專案，大多數的功能特色都是從舊產品直接複製移植過來的。像這一類的工作，就比較偏向是勞力型的工作。對專案工作者而言，其實只是把原本既有的元件或零組件，直接拿過來用在新專案上罷了，並不需要花費太多的時間和心力，這就是我所謂的「勞力型」專案工作。
因此，如果一個人同時參與數個這種改版型專案，而且負責的多為勞力型專案工作，那麼，此人的「個人工作效率」也許的確會有些許的負面影響，但從整體而言，這「幾個專案的團隊總效能」卻是大幅提昇的。
舉個例子來說，如果一個工程師正在測試剛剛從舊專案移植到甲專案上的 A 功能，突然間因為乙專案比較急的原因，工程師被乙專案的專案經理叫去處理同樣的 A 功能瑕疵，工程師在乙專案所花費的心力，其實並不會是一種浪費。此話怎講呢？
因為，這個在乙專案發現的 A 功能瑕疵，有極大的可能也同樣會發生在甲專案上。乙專案專案經理調度工程師所造成的中斷干擾（interrupt）正好也讓工程師可以一箭雙雕，同時解決兩個專案上的相同瑕疵。因為有這個好處，工程師在甲、乙兩個專案之間來回切換所產生的額外浪費成本（overhead）也就微乎其微，幾乎可以完全忽略不計了。
如果像上述的例子那樣，明明兩個專案內的工作是一樣的或是極其相似的，我們卻還緊咬著「每個人都應該專職專注在一個專案上」的原則，硬要派出兩個人分別負責這兩個專案的工作，那就顯得太頑固、太不食人間煙火了。
但是，對於負責「非勞力型」專案工作的人而言，事情可就完全不是這麼回事了。
創意型或相似度低的專案工作
不論是負責改版型專案的新功能特色，還是參與全新產品的打造，專案工作者都需要付出極大的心力。這些心力包含許多的創意發想、邏輯思考、集體腦力激盪等，耗費腦力甚巨，這些都是所謂的「創意型專案工作」，而我相信，我們在執行創意型工作的時候，是無法多工的！
舉個例子來對照一下勞力型專案工作。如果一個工程師正在發想、設計甲專案上的 B 功能，突然間因為乙專案比較急的原因，工程師被乙專案的專案經理叫去處理 C 功能的瑕疵，而 B 和 C 是兩個完全不同的功能特色，試想一下，接下來會有哪些事情發生在工程師的身上呢？我們來分解一下：
- 乙專案專案經理對工程師造成了一個中斷干擾（interrupt）；
- 工程師被迫放下手頭上正設計思考到一半的甲專案 B 功能工作；
- 工程師將思緒轉到乙專案上，花時間回想當初在乙專案上的 C 功能設計，也就是「重新暖身 C 的記憶」；
- 工程師在乙專案上，花時間調查、解決 C 功能的瑕疵；
- 工程師將思緒轉回到甲專案，花時間回想、整理上次暫停的 B 功能的設計狀態，也就是「重新暖身 B 的記憶」；
- 工程師在甲專案上，花時間逐漸恢復至原來的 B 功能設計思考速度。
以上的過程就是工程師同時負責甲、乙兩個專案的額外時間浪費成本！不僅如此，步驟 2 還會令工程師心情低落沮喪，就像把一盆冰水澆在正燒得火熱的新設計柴火上。步驟 3、5、6 則是對甲、乙兩個專案的客戶來說都完全沒有價值產出的浪費，也是透過「一個人專職專注在一個專案上」可以避免得掉的。
工程師同時負責愈多專案，上述的六個步驟輪迴就會愈頻繁，步驟 5 做得不完整的機會就愈高，遺漏掉的東西就愈多，然後就會造成各專案更多的瑕疵，繼而讓步驟 4 花費更長的時間和心力。如果在每個步驟期間，又還發生新的中斷干擾，進入另一個循環，那就更不用我來說，工程師會有多慘，整個公司的專案管理和專案治理會有多慘了！
我給上面的這些步驟和惡性循環一個總稱：「產品開發的撒旦循環」。因為，不讓一個人專職專注在一個專案上所造成的後果，就像是跟撒旦借人力一樣，撒旦並沒有真的給你多一個人，而是用壓榨現有的人「假多工」來騙你，然後要你用你靈魂來還債！
回歸原始初衷
傳統式專案團隊多以「元件/零組件」的打造來分工，而 Scrum 敏捷式專案團隊則是以用戶看得見、用得到的「功能特色」的打造來分工。「元件/零組件」著重於可重複使用，因此，在各個專案上的應用相似度高，而「功能特色」卻是較為多變，著重於滿足各種用戶的不同需求，在各個專案上的實現相似度低。因此，Scrum 敏捷式專案團隊在打造功能特色時，不但需要應付用戶多變的心，還必須投注極大的心力於此。
所以，如果 Scrum 敏捷式專案團隊成員（以及打造相似度低的功能特色的傳統式專案團隊成員）無法「專職專注在一個專案上」的話，顯然，敏捷式團隊工作方法的成效將被大打折扣，甚至很可能會比傳統式專案管理還要糟糕，結果導致「敏捷方法無用論」的聲音出現！
無論是 Scrum 敏捷式或是傳統式的專案管理，其實皆能受益於「一人專職專注在一個專案上」的做法。比方說，許多的新創公司，一開始的人力資源都很有限，不也都是傾全公司之力，專職專注在一個產品專案上，讓團隊的效能極大化嗎？那為什麼組織變大了，就變了個樣了呢？又比方說，為什麼大家在傳統式專案管理方法的使用這麼歷史悠久了，又開始回頭想使用處處回歸人性初衷設計的敏捷式方法了呢？值得大家好好思考一下！
部落格 : 威廉網紙
圖片來源：pixabay.com
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
