Scrum,敏捷,專案管理,PMP,領導統御,甘特圖,排程軟體

    為什麼 Scrum 敏捷方法倡導「團隊一次專注在一個專案上」


    曾經有學員在課程的中場休息時間跑來問我,「老師,我們公司都是一個人要同時負責好幾個案子的,你講的『專注在一個專案上』,根本就不可能實現的啊?那是不是我們公司就無法使用敏捷方法了?」

    這位同學的問題其實有兩個,一個是「一人專注在一個專案上」,另外一個是「公司適不適合使用敏捷方法」。說實話,這兩個問題不只一個人問過,我相信,這必定也是許多對敏捷方法有興趣的人心中的疑惑。既然如此,我們就先來聊聊「一人專注在一個專案上」這個主題好了。畢竟,在現今的職場環境當中,能夠專注在一個專案上的人,還是屬於較為少數的。

    我們先倒過來問一下這個問題:一個人同時負責多個專案,真的就會降低個人和團隊的工作效率嗎?

    過去的職場經驗教會了我一件事,就是在回答別人一個問題之前,一定要再先多問對方幾個問題!這是什麼意思呢?例如,像上述的問題,我就會多問對方下面的幾個問題:
    1. 此人在這幾個專案中,負責的工作內容是屬於創意型還是屬於勞力型的工作?
    2. 此人在這幾個專案中,負責的工作內容的相似度有多高?
    勞力型或相似度高的專案工作

    我們知道一個專案之所以是「專案」,就是因為她有「新東西」要被產出,這個新東西可能是個全新的功能特色(feature),也可能只是舊功能的小改版(improvement)或錯誤修正(bug fix)。然而,很少有產品是所有功能特色都是從頭到尾全新打造的,大多數所謂的「新產品」其實都是舊款產品的「改版」。

    改版型的專案,大多數的功能特色都是從舊產品直接複製移植過來的。像這一類的工作,就比較偏向是勞力型的工作。對專案工作者而言,其實只是把原本既有的元件或零組件,直接拿過來用在新專案上罷了,並不需要花費太多的時間和心力,這就是我所謂的「勞力型」專案工作。

    因此,如果一個人同時參與數個這種改版型專案,而且負責的多為勞力型專案工作,那麼,此人的「個人工作效率」也許的確會有些許的負面影響,但從整體而言,這「幾個專案的團隊總效能」卻是大幅提昇的。

    舉個例子來說,如果一個工程師正在測試剛剛從舊專案移植到甲專案上的 功能,突然間因為乙專案比較急的原因,工程師被乙專案專案經理叫去處理同樣的 功能瑕疵,工程師在乙專案所花費的心力,其實並不會是一種浪費。此話怎講呢?

    因為,這個在乙專案發現的 功能瑕疵,有極大的可能也同樣會發生在甲專案上。乙專案專案經理調度工程師所造成的中斷干擾(interrupt)正好也讓工程師可以一箭雙雕,同時解決兩個專案上的相同瑕疵。因為有這個好處,工程師在甲、乙兩個專案之間來回切換所產生的額外浪費成本(overhead)也就微乎其微,幾乎可以完全忽略不計了。

    如果像上述的例子那樣,明明兩個專案內的工作是一樣的或是極其相似的,我們卻還緊咬著「每個人都應該專注在一個專案上」的原則,硬要派出兩個人分別負責這兩個專案的工作,那就顯得太頑固、太不食人間煙火了。

    但是,對於負責「非勞力型」專案工作的人而言,事情可就完全不是這麼回事了。

    創意型或相似度低的專案工作

    不論是負責改版型專案的新功能特色,還是參與全新產品的打造,專案工作者都需要付出極大的心力。這些心力包含許多的創意發想、邏輯思考、集體腦力激盪等,耗費腦力甚巨,這些都是所謂的「創意型專案工作」,而我相信,我們在執行創意型工作的時候,是無法多工的!

    舉個例子來對照一下勞力型專案工作。如果一個工程師正在發想、設計甲專案上的 功能,突然間因為乙專案比較急的原因,工程師被乙專案專案經理叫去處理 功能的瑕疵,而 和 是兩個完全不同的功能特色,試想一下,接下來會有哪些事情發生在工程師的身上呢?我們來分解一下:
    1. 專案專案經理對工程師造成了一個中斷干擾(interrupt);
    2. 工程師被迫放下手頭上正設計思考到一半的甲專案 B 功能工作;
    3. 工程師將思緒轉到乙專案上,花時間回想當初在乙專案上的 C 功能設計,也就是「重新暖身 C 的記憶」;
    4. 工程師在乙專案上,花時間調查、解決 C 功能的瑕疵;
    5. 工程師將思緒轉回到甲專案,花時間回想、整理上次暫停的 B 功能的設計狀態,也就是「重新暖身 B 的記憶」;
    6. 工程師在甲專案上,花時間逐漸恢復至原來的 B 功能設計思考速度。
    以上的過程就是工程師同時負責甲、乙兩個專案的額外時間浪費成本!不僅如此,步驟 還會令工程師心情低落沮喪,就像把一盆冰水澆在正燒得火熱的新設計柴火上。步驟 35則是對甲、乙兩個專案的客戶來說都完全沒有價值產出的浪費,也是透過「一個人專注在一個專案上」可以避免得掉的。

    工程師同時負責愈多專案,上述的六個步驟輪迴就會愈頻繁,步驟 做得不完整的機會就愈高,遺漏掉的東西就愈多,然後就會造成各專案更多的瑕疵,繼而讓步驟 花費更長的時間和心力。如果在每個步驟期間,又還發生新的中斷干擾,進入另一個循環,那就更不用我來說,工程師會有多慘,整個公司的專案管理專案治理會有多慘了!

    我給上面的這些步驟和惡性循環一個總稱:「產品開發的撒旦循環」。因為,不讓一個人專注在一個專案上所造成的後果,就像是跟撒旦借人力一樣,撒旦並沒有真的給你多一個人,而是用壓榨現有的人「假多工」來騙你,然後要你用你靈魂來還債!

    回歸原始初衷

    傳統式專案團隊多以「元件/零組件」的打造來分工,而 Scrum 敏捷專案團隊則是以用戶看得見、用得到的「功能特色」的打造來分工。「元件/零組件」著重於可重複使用,因此,在各個專案上的應用相似度高,而「功能特色」卻是較為多變,著重於滿足各種用戶的不同需求,在各個專案上的實現相似度低。因此,Scrum 敏捷專案團隊在打造功能特色時,不但需要應付用戶多變的心,還必須投注極大的心力於此。

    所以,如果 Scrum 敏捷專案團隊成員(以及打造相似度低的功能特色的傳統式專案團隊成員)無法「專注在一個專案上」的話,顯然,敏捷式團隊工作方法的成效將被大打折扣,甚至很可能會比傳統式專案管理還要糟糕,結果導致「敏捷方法無用論」的聲音出現!

    無論是 Scrum 敏捷式或是傳統式的專案管理,其實皆能受益於「一人專注在一個專案上」的做法。比方說,許多的新創公司,一開始的人力資源都很有限,不也都是傾全公司之力,專職專注在一個產品專案上,讓團隊的效能極大化嗎?那為什麼組織變大了,就變了個樣了呢?又比方說,為什麼大家在傳統式專案管理方法的使用這麼歷史悠久了,又開始回頭想使用處處回歸人性初衷設計的敏捷式方法了呢?值得大家好好思考一下!