專案中一個幾乎遙不可及的夢 - 專人專用
這是一篇我很早就想寫的文章。
我常常把標題列著，放在Blog的文章清單裡，但放著放著，半年就過去了，可能只是因為我一直找不到好的例子，把我想解釋的想法或概念，有條理地跟大家分享。這一篇，就是最典型的狀況。
我一放，就放了半年。直到今天和Team Member剛好討論起相關的議題，才讓我重新把這篇整理出來。
想說的很多，但題目卻很簡單，就是『專人專用』。
自己做專案很多年，不僅接觸過很多公司，也接觸很多接案的外包的單位。我可以說，幾乎沒有任何一個開發團隊，團隊中負責Coding的開發人員，是100%的專人專用。幾乎每一個所謂的『團隊』，開發成員身上都是兼著2-3個案子。也就是說，絕大部分的開發團隊成員，身上都不只一個案子。如果是PM，那就更慘，大多數的PM肯定都身兼多個案子。這還不包含不需要談規格和需求的維護案。
其實對我來說，這是一件很弔詭的事情。但，在這業界似乎卻是常態。
年輕時，不只一次，我曾在專案裡要求我的team member是100%投入，不得兼任其他案子的任何角色，然而，過去幾乎每一家公司的老闆，都曾跟我說過：不可能。
不管我擔任甲方或乙方，這種結果幾乎如宿命般的相同：就是開發人員『總是』身兼多職，同時也身兼多案。在比較具有規模的接案團隊中，『搶資源』有時候還變成某些PM的強項咧。
但有趣的是，任何腦袋清楚的Developer，都會告訴你，只要身兼兩三個案子後，自己的工作效率就會開始變糟、程式碼的bug數也開始變多。事實上最理想的狀況，其實是讓Developer同一個時間，只參與一個案子。但任何老闆都會跟你說：我知道，我也希望這樣，但這是理想狀況，現在實際上....(後面的就不用多說了)
(我甚至聽過有公司應徵developer的時候，其中的問題是...你的『抗壓性』如何? 你可不可以身兼多案? 能不能在專案中快速的轉換? 碰到這種公司，我勸Developer好自為之。)
因此，只消幾年業界經驗之後，Developer就知道，這是一個不用抗爭的事情，幾乎在任何公司、任何老闆、都會讓你身兼多案，屢試不爽，毫無討論的空間。
但有趣的是，任何客戶都不希望這樣，如果是賣人力的time material合約，大部分的買方，即便沒有要求on site，也會要求人力不能兼任其他客戶的案子。當然，沒有on site就不好控制，因此很多控制的手段就出現了，包含daily report, daily meeting, worklog tracking...etc)
回頭想想...
專人專用，真的有那麼困難嗎？
專人專用，真的有那麼重要嗎?
我得說，這麼多年下來，特別是run scrum之後，我發現，專人專用絕對是案子成敗與否的重要關鍵。事實上是，只有在專案團隊成員是100%的投入時，才有所謂的『品質』可言，也才有『合理的績效』可以要求。
我不需要(也不想)花太多時間去解釋開發人員身兼多個案子，在兩三個案子之間switch時的轉換成本。因為你只消做過一兩年developer就知道，在關鍵的時刻，一點點的interrupt對開發來說都可能是一種罪惡。更何況腦袋要常常在兩個案子中轉來轉去，常常需要開不同的專案會議，常常需要參與不同的daily meeting，寫不同的專案報告、改不同的程式碼...對於一個擁有正常腦袋的開發人員來說，這不僅僅是一種試煉，這根本可以說是一種折磨。
我甚至可以很武斷的說，你想搞砸一個案子? 只需要讓團隊中大部分人都身兼多職就可以了。
我得嚴肅地說，成員身兼多職的團隊並不是一個真正的團隊(如果你了解我對團隊的定義的話 - 詳見筆者拙著)。你能想像一個職業籃球隊裡面的成員有一半晚上都在兼職踢足球嗎? 我得說，所謂的一心多用，根本是個業餘的做法。很多廠商所謂的品質，都只是掛在嘴邊說的，因為嚴格說起來，一心多用是不會有品質可言的。
也就是說，當專案的老闆和PM，開始允許團隊成員身兼其他案子的成員的那一刻起，就表示他心裡已經默許這個專案的品質是可以降低的了。
從這個角度來說，台灣很多的開發團隊，其實從來沒有從頭到尾好好做過一個案子。許多Developer從一踏入專案領域開始，每天就是在身兼許多案子的狀況下過日子，久而久之，甚至習以為常了。
有一天當他變成PM甚至老闆之後，他會認為本來就可以(應該是)這樣(因為他以前就是這樣的)，卻不知道，其實身兼多案才是專案失敗的重要原因之一。
即便專案成員或PM有點sense，但軟體公司老闆卻往往不接受在專案中的專人專用，而總是讓開發人員或PM身兼很多案子，除了人手不足迫於無奈的因素之外，很多老闆甚至打從心底認為，人是可以一心多用的，因為他自己就是這樣。
許多業務或是非技術出身的老闆(或PM)，把開發人員當成resource，把team當作生產程式碼的機器，但卻忘記了，所謂的『開發』本質上並不只是一種『生產』，而是一種『創作』!你會要求畫家或是作曲家同時間畫兩張畫，或是同時彈奏兩首曲子嗎? 你會常常要求演員同時演兩場舞台劇? 或是同時間軋很多角色? 你不該會這樣的。
如果可以，我們都會盡量讓畫家、作曲家、演員...做完一件事情後，再去做另一件，因為知道這樣才能真正有『效率』，因為知道這樣才能開始談『品質』，一心多用中間的轉換成本很高很高。人腦要一心多用，在創作上是很困難的。
但老闆們(或PM)們卻常常不以為意，因為從他們的經驗上來說，人是可以一心多用的。不是很多主管同時帶兩三個部門嗎? 不是很多老闆同時間負責很多決策嗎? 不是很多經理同時間看很多案子嗎?
我要說，實際上很可能是，因為他一直沒有真正的投入過，才會以為人可以一心多用。
不要拿管理部門來說，拿養家活口來說吧，正常來說，一個負責任的男人要養一個家庭，再帶2個小孩， 如果真要認真投入，幾乎得要花上自己的全心全力。你能想像一下，如果你要同時養兩個家庭，同時照顧四個(兩組)小孩，同時有兩個老婆要養，同時有兩個結婚紀念日要過，同時有兩個年夜飯要吃...那...會是一種怎樣的人生呢? (相信我，這該不會是一種幸福的)
有另一件事情說起來也很弔詭，幾乎每一家公司，都不希望員工晚上兼差， 幾乎每一家公司，也都不希望員工下班後額外接自己的案子，理由不外乎是，兼差會讓員工分心，無法專注在公司的工作云云...
有趣的是，若老闆真的這麼相信，那為何在公司自己的案子上，卻又總是讓員工『兼差』呢?
的確，或許能否一心多用可能跟這個人本身的能力有關，歷史上也不乏可以身兼多職的能人異士，但，這畢竟是少數，且不管能力再強，每個人都有上限。經驗上告訴我，越能夠『快速專注』的人，越有機會可能可以同時間參與很多專案，但這很難，也很少見，並不多人擁有超人的專注力。(更何況是薪資領得比較少的junior developers)
因此，對專案最好的狀況是：讓團隊成員就只負責一個案子，並且讓團隊的成員盡可能的專注，always focus在自己的專案上。
我在帶專案時，非常討厭聽到成員跟我說...因為在處理另一個案子的OOXX，或是另一個案子必須開什麼會議、趕什麼文件，所以導致這個案子發生了什麼問題。也因此，如果可以，我幾乎讓專案成員同時間只專注在一個案子，專注在一個目標上，真的非得一人多用，也必須以Sprint為單位，不能在同一段時間，讓團隊成員同時在兩個案子的Sprint中出現。
你還必須知道，除非專人專用，否則時程預估和成本預估所得出來的數值，幾乎會接近沒有意義。
我們在專案中太多的預估，都是假設在專案成員不被其他專案所打擾的狀況下所建立的。因此，只要專案成員開始被其他案子打擾(開始必須要在2,3個案子上switch)，那所有的預估值很可能立即開始失效。(這也是專案拿時程預估值轉換成成本來報價時，大多數sale都會乘上2-3倍的原因) 我幾乎可以說，在軟體開發專案裡面，沒有專人專用的化，那麼用多麼豪華的Excel表格或Project做出的時程預估，根本上就是個謊言(或是不切實際的猜測)。
往往你對task的預估，在這個人身上是5，在另一個人身上會變成10，換了人，開發時間膨脹一倍這種事情根本屢見不鮮。如果再加上團隊人員又兼了其他案子，你很快就會知道下場有多悲慘了...
說了那麼多，你就知道我對專人專用有多麼在意了。
但無奈的是，專案身涯至今，只有極少數的partner能夠在不on site的狀況下給我專人專用的承諾(而這樣的partner，也才是我理想的合作夥伴)，更好笑的是，我時常看到有些團隊即便on site了，卻還無法實現專人專用。團隊成員人明明被綁在客戶C公司的辦公室，卻依然在處理另一個B客戶先前還沒收尾的案子，然後C客戶的PM打開門進來，整個team把螢幕關掉這樣的狀況...
這不是很可悲嗎?
『沒有專注，就沒有效率。 』這在哪裡都會是個定理。
本篇收錄自 - 『敏捷開發專案管理與架構設計實務』
我常常把標題列著，放在Blog的文章清單裡，但放著放著，半年就過去了，可能只是因為我一直找不到好的例子，把我想解釋的想法或概念，有條理地跟大家分享。這一篇，就是最典型的狀況。
我一放，就放了半年。直到今天和Team Member剛好討論起相關的議題，才讓我重新把這篇整理出來。
想說的很多，但題目卻很簡單，就是『專人專用』。
自己做專案很多年，不僅接觸過很多公司，也接觸很多接案的外包的單位。我可以說，幾乎沒有任何一個開發團隊，團隊中負責Coding的開發人員，是100%的專人專用。幾乎每一個所謂的『團隊』，開發成員身上都是兼著2-3個案子。也就是說，絕大部分的開發團隊成員，身上都不只一個案子。如果是PM，那就更慘，大多數的PM肯定都身兼多個案子。這還不包含不需要談規格和需求的維護案。
其實對我來說，這是一件很弔詭的事情。但，在這業界似乎卻是常態。
年輕時，不只一次，我曾在專案裡要求我的team member是100%投入，不得兼任其他案子的任何角色，然而，過去幾乎每一家公司的老闆，都曾跟我說過：不可能。
不管我擔任甲方或乙方，這種結果幾乎如宿命般的相同：就是開發人員『總是』身兼多職，同時也身兼多案。在比較具有規模的接案團隊中，『搶資源』有時候還變成某些PM的強項咧。
但有趣的是，任何腦袋清楚的Developer，都會告訴你，只要身兼兩三個案子後，自己的工作效率就會開始變糟、程式碼的bug數也開始變多。事實上最理想的狀況，其實是讓Developer同一個時間，只參與一個案子。但任何老闆都會跟你說：我知道，我也希望這樣，但這是理想狀況，現在實際上....(後面的就不用多說了)
(我甚至聽過有公司應徵developer的時候，其中的問題是...你的『抗壓性』如何? 你可不可以身兼多案? 能不能在專案中快速的轉換? 碰到這種公司，我勸Developer好自為之。)
因此，只消幾年業界經驗之後，Developer就知道，這是一個不用抗爭的事情，幾乎在任何公司、任何老闆、都會讓你身兼多案，屢試不爽，毫無討論的空間。
但有趣的是，任何客戶都不希望這樣，如果是賣人力的time material合約，大部分的買方，即便沒有要求on site，也會要求人力不能兼任其他客戶的案子。當然，沒有on site就不好控制，因此很多控制的手段就出現了，包含daily report, daily meeting, worklog tracking...etc)
回頭想想...
專人專用，真的有那麼困難嗎？
專人專用，真的有那麼重要嗎?
我得說，這麼多年下來，特別是run scrum之後，我發現，專人專用絕對是案子成敗與否的重要關鍵。事實上是，只有在專案團隊成員是100%的投入時，才有所謂的『品質』可言，也才有『合理的績效』可以要求。
我不需要(也不想)花太多時間去解釋開發人員身兼多個案子，在兩三個案子之間switch時的轉換成本。因為你只消做過一兩年developer就知道，在關鍵的時刻，一點點的interrupt對開發來說都可能是一種罪惡。更何況腦袋要常常在兩個案子中轉來轉去，常常需要開不同的專案會議，常常需要參與不同的daily meeting，寫不同的專案報告、改不同的程式碼...對於一個擁有正常腦袋的開發人員來說，這不僅僅是一種試煉，這根本可以說是一種折磨。
我甚至可以很武斷的說，你想搞砸一個案子? 只需要讓團隊中大部分人都身兼多職就可以了。
我得嚴肅地說，成員身兼多職的團隊並不是一個真正的團隊(如果你了解我對團隊的定義的話 - 詳見筆者拙著)。你能想像一個職業籃球隊裡面的成員有一半晚上都在兼職踢足球嗎? 我得說，所謂的一心多用，根本是個業餘的做法。很多廠商所謂的品質，都只是掛在嘴邊說的，因為嚴格說起來，一心多用是不會有品質可言的。
也就是說，當專案的老闆和PM，開始允許團隊成員身兼其他案子的成員的那一刻起，就表示他心裡已經默許這個專案的品質是可以降低的了。
從這個角度來說，台灣很多的開發團隊，其實從來沒有從頭到尾好好做過一個案子。許多Developer從一踏入專案領域開始，每天就是在身兼許多案子的狀況下過日子，久而久之，甚至習以為常了。
有一天當他變成PM甚至老闆之後，他會認為本來就可以(應該是)這樣(因為他以前就是這樣的)，卻不知道，其實身兼多案才是專案失敗的重要原因之一。
即便專案成員或PM有點sense，但軟體公司老闆卻往往不接受在專案中的專人專用，而總是讓開發人員或PM身兼很多案子，除了人手不足迫於無奈的因素之外，很多老闆甚至打從心底認為，人是可以一心多用的，因為他自己就是這樣。
許多業務或是非技術出身的老闆(或PM)，把開發人員當成resource，把team當作生產程式碼的機器，但卻忘記了，所謂的『開發』本質上並不只是一種『生產』，而是一種『創作』!你會要求畫家或是作曲家同時間畫兩張畫，或是同時彈奏兩首曲子嗎? 你會常常要求演員同時演兩場舞台劇? 或是同時間軋很多角色? 你不該會這樣的。
如果可以，我們都會盡量讓畫家、作曲家、演員...做完一件事情後，再去做另一件，因為知道這樣才能真正有『效率』，因為知道這樣才能開始談『品質』，一心多用中間的轉換成本很高很高。人腦要一心多用，在創作上是很困難的。
但老闆們(或PM)們卻常常不以為意，因為從他們的經驗上來說，人是可以一心多用的。不是很多主管同時帶兩三個部門嗎? 不是很多老闆同時間負責很多決策嗎? 不是很多經理同時間看很多案子嗎?
我要說，實際上很可能是，因為他一直沒有真正的投入過，才會以為人可以一心多用。
不要拿管理部門來說，拿養家活口來說吧，正常來說，一個負責任的男人要養一個家庭，再帶2個小孩， 如果真要認真投入，幾乎得要花上自己的全心全力。你能想像一下，如果你要同時養兩個家庭，同時照顧四個(兩組)小孩，同時有兩個老婆要養，同時有兩個結婚紀念日要過，同時有兩個年夜飯要吃...那...會是一種怎樣的人生呢? (相信我，這該不會是一種幸福的)
有另一件事情說起來也很弔詭，幾乎每一家公司，都不希望員工晚上兼差， 幾乎每一家公司，也都不希望員工下班後額外接自己的案子，理由不外乎是，兼差會讓員工分心，無法專注在公司的工作云云...
有趣的是，若老闆真的這麼相信，那為何在公司自己的案子上，卻又總是讓員工『兼差』呢?
的確，或許能否一心多用可能跟這個人本身的能力有關，歷史上也不乏可以身兼多職的能人異士，但，這畢竟是少數，且不管能力再強，每個人都有上限。經驗上告訴我，越能夠『快速專注』的人，越有機會可能可以同時間參與很多專案，但這很難，也很少見，並不多人擁有超人的專注力。(更何況是薪資領得比較少的junior developers)
因此，對專案最好的狀況是：讓團隊成員就只負責一個案子，並且讓團隊的成員盡可能的專注，always focus在自己的專案上。
我在帶專案時，非常討厭聽到成員跟我說...因為在處理另一個案子的OOXX，或是另一個案子必須開什麼會議、趕什麼文件，所以導致這個案子發生了什麼問題。也因此，如果可以，我幾乎讓專案成員同時間只專注在一個案子，專注在一個目標上，真的非得一人多用，也必須以Sprint為單位，不能在同一段時間，讓團隊成員同時在兩個案子的Sprint中出現。
你還必須知道，除非專人專用，否則時程預估和成本預估所得出來的數值，幾乎會接近沒有意義。
我們在專案中太多的預估，都是假設在專案成員不被其他專案所打擾的狀況下所建立的。因此，只要專案成員開始被其他案子打擾(開始必須要在2,3個案子上switch)，那所有的預估值很可能立即開始失效。(這也是專案拿時程預估值轉換成成本來報價時，大多數sale都會乘上2-3倍的原因) 我幾乎可以說，在軟體開發專案裡面，沒有專人專用的化，那麼用多麼豪華的Excel表格或Project做出的時程預估，根本上就是個謊言(或是不切實際的猜測)。
往往你對task的預估，在這個人身上是5，在另一個人身上會變成10，換了人，開發時間膨脹一倍這種事情根本屢見不鮮。如果再加上團隊人員又兼了其他案子，你很快就會知道下場有多悲慘了...
說了那麼多，你就知道我對專人專用有多麼在意了。
但無奈的是，專案身涯至今，只有極少數的partner能夠在不on site的狀況下給我專人專用的承諾(而這樣的partner，也才是我理想的合作夥伴)，更好笑的是，我時常看到有些團隊即便on site了，卻還無法實現專人專用。團隊成員人明明被綁在客戶C公司的辦公室，卻依然在處理另一個B客戶先前還沒收尾的案子，然後C客戶的PM打開門進來，整個team把螢幕關掉這樣的狀況...
這不是很可悲嗎?
『沒有專注，就沒有效率。 』這在哪裡都會是個定理。
本篇收錄自 - 『敏捷開發專案管理與架構設計實務』
留言