學習專案管理的基本思維

2018.09.19 by
游舒帆
游舒帆 查看更多文章

探索原力Co-founder,曾任TutorABC協理與鼎新電腦總監,並曾獲選兩屆微軟最有價值專家 ( MVP ),離開職場後創辦探索原力,致力於協助青少年培養面對未來的能力。認為教育與組織育才其實習習相關,都是在為未來儲備能量,2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》,為培養台灣未來的領袖而努力。

WIN12_ET via Shutterstock
許多學習專案管理的朋友,在初學專案管理時都一頭栽入專案管理工具與框架,卻未曾了解更源頭的問題。

這些年來,許多學習專案管理的朋友,在初學專案管理時都一頭栽入專案管理工具與框架,卻未曾了解更源頭的問題,包含:

「為什麼需要學專案管理?」
「專案管理能解決什麼問題?」
「專案管理不能解決什麼問題?」
「為什麼案子總是做不好?」
「怎麼樣才能做好一個案子?」

在學習一門知識時,我建議大家必須先從問題開始思考,當你對這些問題有了基本的認知,接著開始去找幾個framework、methodology或best practice,然後看看它們用什麼樣的流程與工具來解決你所面對的那幾個問題,唯有經過這樣的過程,你對這門知識才會有更清晰的認知。

PMP或Scrum這類的framework或best practice的出現,都是累積了足夠多的實務案例,並將常見的問題以 框架、流程、方法、工具 來封裝,讓其他人更容易上手。但若你未試圖理解它背後要解決的問題,你就容易錯用。

不管工具有多好,若你運用的場合不對,它就不是個好工具。

CMMI與PMP真的不好嗎?

剛出社會時,我在一家ERP軟體公司從事研發工作,我在哪裡接觸到非常正規的軟體工程,也見識到當研發流程與業務特性匹配時的高效,以及不匹配時產生的諸多問題。在2000年初期,軟體發展大多仍依循瀑布式(Waterfall)方法,必然得先進行需求收集、分析、設計,使得進入開發與測試,經過一道道程式後將成品完整的交付。

我在ERP軟體公司的那些年,我也參與了CMMI Lv4(軟體成熟度模型)的導入與認證,過程中 我見識到CMMI的嚴謹之處,同時也體會到嚴謹背後帶來的低效與冗餘。 由於當時我所負責的產品處於需求不明確,市場性待驗證的狀態,若要依CMMI的規則產出完整需求清單與完整的分析檔,估計是不可能。

因此在過程中我試著提出用假設性需求,以及用雛型替代成品來進行市場驗證。出乎意意料的,這個提議獲得CMMI顧問團隊的認同,而這也是我對CMMI有所改觀的轉捩點,公司內推動小組的負責人告訴我:

「CMMI本來就是一個模型,每家公司得依自己最適合的方式建構流程,但最終須能達到CMMI要求的水準。」

2011年,我開始負責SaaS相關業務,也首次接觸了敏捷觀念以及Scrum,與此同時,互聯網開始進入火爆增長,所有的企業都在求新求快,技術團隊也被要求要具備更靈活、更彈性、更迅速,只是一兩年時光,大陸的公司都在討論敏捷開發,而少有人討論PMP、CMMI所談的瀑布式專案管理與研發流程管理方法 (註:PMI後來也提出ACP這套敏捷框架)

2013年,我開始在團隊中大量引用敏捷觀念,透過頻繁的交付來驗證用戶與市場需求,也在技術社區中與許多朋友交流專案管理與軟體發展方法,我看見愈來愈多人想擁抱敏捷,同時我也發現,許多人因崇尚敏捷,而對PMP及CMMI抱持著嚴重的偏見。

2015年,我進入互聯網公司後,人人口中所談的都是敏捷,若你在討論過程中提到CMMI或PMP,就會有人露出鄙視的眼神。他們誤以為過去專案做不好,是CMMI與PMP所造成的,卻未曾思考過,或許專案失敗的真正原因不在流程與工具,而是運用的那些人。

瀑布式與敏捷並存,可能嗎?

我曾在先前的文章中提過,我認為組織長大到一定規模後,必然會出現混合式的組織架構,當企業內外部狀況穩定,需求的變化性較少,可預測性高,功能型組織是相對適合的組織架構;而當需求變化性較大,不確定性高,變平化的產品型或戰鬥小組可能是更適合組織架構。

而相同的概念,其實也適用於專案管理方法,當你特別強調 分工程序、輸入(input)、輸出(output)與權責,這與功能性組織不謀而合,傳統的專案管理方法可能非常合用;反之,若你強調快速回應、迭代等敏捷特性,則與產品型組織或戰鬥小組更加匹配。

所以,瀑布式與敏捷方法並存在一家公司內,可能嗎?

我的答案是「肯定的」,當我們把重點放在解決問題,而非落入比較方法或工具的優劣時,我們便會理解,沒有必要硬要逼所有人套用相同的工作流程與方法,除非真有必要性。

經過這些年的實戰運用,我試著將這種混合式的專案管理方法整理成如下的框架,多數的專案都是介於完全不確定與完全確定之間,面對不確定性高專案,敏捷方法、分工模糊的戰鬥小組相對較佳,然而面對確定性極高的專案,Waterfall與分工明確的功能型或專案型團隊則相對適合。以目標導向來看,很多時候我們甚至該採用混編的方式同時進行專案。

游舒帆

追求敏捷,但更要重視專案管理基本功

在帶領團隊時,我特別強調專案管理的基本功,因為 我認為多數的問題都是出在基本功不夠扎實。在專案開始前與進行中,一般我會對PM提出很多問題,以確保專案能如原先預期。

在專案啟動階段,一般會由團隊先就已知資訊先擬定draft plan,內容陳述專案要 做哪些事?打算如何進行?由誰來做?預計花費多少時間?以及得到什麼樣的結果?

游舒帆

「這個專案中有哪些不確定性,它們可能會導致你無法準時交付?」

而當團隊將計畫產出後,我會問PM這個問題。從這個問題的回答中,我便能有效檢視PM對這個專案的把握度有多少。

專案管理早期的主要問題大多是「要解決的問題不明確」、「需求不夠清晰」、「專案的deadline太趕」、「不確定人力資源能否配合」、「對工作的估時過長或過短」、「技術可行性待驗證」、「老闆可能還會改動需求」等。

而這些,就是導致專案行階段會頻繁發生變更(change)的重要原因。

這些不確定性,都可能是專案執行時期的風險,你可以選擇在規劃前期就想辦法處理這些不確定性,也可以選擇在執行時,透過變更管理來因應這些不確定而帶來的更動,而成熟的PM會將這些不確定性有效控管,並以面對風險的方式去處理。

敏捷雖強調擁抱不確定性,並歡迎隨時的更動,但不意味著我們要對那些不確定性置之不理,而是要儘快的讓不確定成為確定。

敏捷強調不斷進步與回饋,透過一個又一個專案的磨練,讓我們能把需求看得更清楚,對時程估算更準確,能更有效對齊老闆的期待,而要做到這些,團隊就需要逼著自己不斷進步,透過反覆的迭代,將不確定性一一消除。

若你對Scrum架構有所研究,你便會發現best practice裡頭強調的架構,其實正是針對上述幾個最常見的專案不確定性而來。

針對時程,Scrum強調固定的交付週期,以1–4周為佳;

針對團隊,強調最好是feature team,在過程中也盡可能避免團隊成員同時參與多個專案;

針對範疇,根據迭代週期與team的資源,由Product Backlog中挑選能完成的工作項目;

加上每個迭代的週期較短,工作總量較小,若過程中發生變更或插單,其實影響的範圍相對較小,等待時間也較短,對變更的因應能力自然較強,若你正確的引入Scrum,這將是你可期待的結果。

先思維,後框架、工具

在學習專案管理或其他知識時,我非常建議大家一定要先建立思維,先了解我們要解決的問題,也就是背後的「Why」,例如要確保工作能如期如質的交付。並圍繞著為什麼去找尋別人是用什麼樣的框架與方法去解決的,也是就「How-to」,例如PMP或Scrum,而在框架與方法之下,又分別選用了什麼樣的工具,這就是「What」,例如WBS、user story等等。

學習過程,一定要先搞懂要解決的問題,並進一步思考為何框架的設計與工具能解決我們遭遇到的問題,並思考它的適用範圍。

唯有如此,我們才能跳脫被框架與工具,而不為物所役。

游舒帆

本文由游舒帆授權轉載自其> Mediuam

《數位時代》長期徵稿,針對時事科技議題,需要您的獨特觀點,歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw,文長至少800字,請附上個人100字內簡介,文章若採用將經編輯潤飾,如需改標會與您討論。

(觀點文章呈現多元意見,不代表《數位時代》的立場。)

每日精選科技圈重要消息