團隊內多新人,專案又僅 100 天,能用敏捷式方法管專案嗎?



    「老師,我們現在的團隊都是新人,而且專案的時間只有 100 天,我們應該用敏捷式,還是傳統式的專案管理比較好?」

    這是一位我敏捷式專案管理課程的學員在下課休息時對我的提問。面對這樣的問題,通常我是不會直接回答給答案的。理由很簡單,因為我根本就不瞭解你的團隊,對你的組織狀況更是一無所知,如果依據這樣的一句簡單提問,我就能直接回答給答案的話,那麼,我絕對是在鬼扯,絕對是個詐神無誤!

    雖然我當下沒給答案,不過,這個問題倒是一個不錯的好問題,啟發了我的一些思考。

    「你的團隊都是怎樣的新人?是剛畢業,完全沒工作經驗呢?還是已經有幾年經驗了,只是剛到職而已?」

    「都有!一個是剛到職,有兩、三年工作經驗的工程師,其他兩個都是剛畢業的社會新鮮人。」

    瞧!我只不過是簡單地回問了一個問題而已,馬上就可以發現,這位學員的原始描述其實並不是太精確!其實這也不是這位學員專屬的情形,許多其他人也都是一樣的習慣,都希望能用簡單的問題描述,就拿到可以治百病的仙丹!

    「喔!那你這個團隊要做的專案是什麼專案?」

    「是一個 IT 軟體系統專案,是公司內部要用的。」

    OK!那你覺得這個專案的需求有很確定了嗎?有夠高層的人可以畫押嗎?」

    「公司裡的需求單位常常都是問他們 SPEC 的時候都跟我們說沒問題,等我們把東西做出來以後,他們又說要改這裡,要改那裏的。」

    「既然如此,你覺得今天講的,快速產出一版給需求單位去試用,然後馬上蒐集使用者的回饋,在下一個或下兩個衝刺去改版,這樣適不適合你這個專案?」

    「如果需求單位願意配合使用,給我們回饋的話,這樣好像就可以耶!可是有兩個新人,我怕他們在一個衝刺內東西會做不出來

    「那傳統式的專案管理方法,也就是你現在在用的,就沒有『預計要做出來的東西結果卻做不出來』的問題了嗎?」

    「ㄟ,其實好像也會有一樣的問題。」

    「那不就得了!反正沒差,那為什麼不換個方法試試看呢?

    「嗯,可是,只有 100 天的時間而已耶?」

    「你用傳統式專案管理方法,一樣只有 100 天,我猜你大概最多只能推出兩版給用戶使用,一個是正式的 release,另一個是在此之前一、兩週的 Beta 版,對吧?」

    「對!也可能不會有 Beta,直接就出正式版,因為反正都會要繼續改下去。」

    「你如果改用敏捷式方法,你覺得應該在這 100 天內 release 幾個版本給用戶會比較好?」

    「ㄜ我想一下應該差不多可以兩、三個禮拜出一次版本那就是可以 release 5 7 次左右。」

    「也就是說,你可以得到用戶 5 7 次的回饋,你覺得這樣的回饋次數夠不夠讓你這個專案在結案的時候變得很完善,以後大改的機會不多?」

    「ㄟ,應該是可以!」

    「好,那我再問你一個問題,剛剛你評估兩、三個禮拜可以出一次版本的時候,是不是已經考量到這兩個社會新鮮人的學習曲線會比較慢的情況了?」

    「是啊!」

    OK!其實,依據我過去帶人的經驗,一個兩、三年經驗的工程師,如果同時要帶兩個這樣的社會新鮮人,大概他就已經滿載了,再多些新人給他帶的話,他應該就會吃不消了,可能自己都沒辦法有任何的產出了,因為他的時間得全部花在新人的指導上了!所以你目前的團隊成員組成,可能已經是最佳化的情況了!不過,你忘了,其實還有一個資深的人也可以拿來用。」

    「喔~誰啊?」

    「就是你啊!其實你剛才已經幫你這個團隊規劃好衝刺的週期,以及版本的規劃了,你已經在做敏捷大師(Scrum Master)的角色了喔!有你這個懂敏捷方法流程施行心法的主管,又有一位資深的工程師可以帶兩個新人技術,在我看來,人力資源的風險是不高的。更何況,專案成果是公司內部要用的,不會有被外部客戶罰款的問題,如果沒有其他的因素非得使用傳統式專案管理的話,我會建議你,不妨就大膽試行敏捷方法看看囉,這不也是你來這裡上課的目的嗎?」

    「對耶!老師,我懂了!謝謝老師!

    敏捷式方法無關乎團隊成員的技術程度高低,年資的深淺,也無關乎專案時間的長短,只要是需求的不確定性高,包括人員能力的不確定性,都可以用這樣的方法來「重複快速實驗」,快速取得用戶對衝刺成果的使用回饋,以及驗證團隊的實際產出能量,然後在下一次的開發輪迴(衝刺/Sprint)中,快速地修正需求的方向,以及團隊的開發速度估算,這才能叫做是「反應敏捷」的團隊,也應該是更聰明的做法,不是嗎?

    圖片來源:pixbay.com