iT邦幫忙

2021 iThome 鐵人賽

DAY 18
1
IT管理

專案/團隊管理的無字天書系列 第 18

用一半的時間做兩倍的事

聽說,這個書名引發了一些爭議。老闆角色的人看這本書都認為RD團隊讀完後就是吃了大補丸,以後做專案只需要一半的時間就好,所以都樂於引進SCRUM。(燦笑)

如果不要使用這麼聳動的書名,中庸一點的,應該是使用「事半功倍」這句成語來說明Scurm,才是比較精準的吧。

但是,不管在原本的書名中,「用一半的時間」,與成語的「事半」,還是會讓人有偷雞的想像覺得好像不用付出什麼力氣,就能得到兩倍的效果。但事實上,付出多少,就獲得多少的等價概念,基本上還是存在於大部分的情況,鮮少有例外。

因為我的教會正在建新堂中(募款中,願意奉獻者請私訊),我大概能理解建築業應該是最計較時程的行業,因為他們的工作階段非常多,不同類型的工班有不同的進場時間,可能還要顧慮現場施工環境、設計圖仍可能有錯誤需要現場修正等等細節。而建築合約中也可能有提早完工的獎勵條款,或者時程延遲的懲罰條款等,因此一個複雜建築工程專案有著不同的拉力與推力冥冥之中拉扯著。

但建築類的專案,前期花費大量的溝通時間與精力與發案方進行溝通與細節確認,沒有定案之前你很難有可以偷跑的工作先進行。因此這類的專案就是標準的瀑布流的專案進行方式。工作就是一環卡一環,前置作業沒有完成前,下一個步驟無法進行。所以這類的工作被詬病的就是通常時程會拉很長,需求方發想開始到最後完成都是很長的期限,但是這樣的優點基本上只要前一手的工作做的確實沒有問題,下一手工作範圍很明確,產出也很清楚。

只是,在軟體業,或者新創業圈,時間就是金錢,一個概念的發想,就是要早點丟到市場上運作,才會知道是否有效,或者如何修改,因此不可能讓專案人員paper work到天昏地老後才開始動工。

所以相對於建築類的專案,軟體類的專案是最有可能可以多個子專案多箭齊發同時進行,讓一組序列的工作可以透過多執行緒的概念同時併發執行出去,達到真正縮等待時間的期望。

但是,寫過多執行緒的人應該知道,執行緒的管理才是最頭痛的事情!!!更何況,如果發出去的多執行緒彼此還需要溝通,這個管理機制的設計過程才是真正會讓人想死的!!

所以想要「事半」「功倍」,我認為不是不行,而是你需要花更多的力氣,做更多的事前準備工作,才能讓不明就裡的人覺得你只用「別人一半的時間」做出「別人好幾倍的事」。

首先,你要知道什麼是「對的事情」,要先做;
再來,因為你不是自己做,所以要讓大家知道如何「把事情做對」;
再來,因為不是一個人/團隊做,所以要讓多人/團隊之間學會溝通;
再來,因為市場變化快,要不斷的與需求方溝通確認「對的事情」持續是對的;
再來,團隊一定會犯錯,所以要給團隊不斷地做心理建設與良性溝通;
再來,產品上線後要面對時間與人力被新需求與線上問題給瓜分;
再來........

想敏捷,卻沒有決心自己要比其他人承擔更多的SM或者專案管理人,也不要把敏捷的責任推給工程師了。


上一篇
強人PM與敏捷相遇 -2
下一篇
甲方 vs 乙方
系列文
專案/團隊管理的無字天書30

尚未有邦友留言

立即登入留言