2014年11月6日 星期四

專案中一個幾乎遙不可及的夢 - 專人專用

這是一篇我很早就想寫的文章。

我常常把標題列著,放在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把螢幕關掉這樣的狀況...

這不是很可悲嗎?

『沒有專注,就沒有效率。 』這在哪裡都會是個定理。

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

沒有留言: