2014年3月24日 星期一

PMI-ACP 經驗談: 先求一門深入,再學無量法門

徐柏峰

      開始推廣敏捷式專案管理以來,不但搭上全球PMI-ACP認證的首班車,也透過在理論和實務的整合,在台灣前100名PMI-ACP中,輔導成功超過80名。來和我結緣的同學,最快紀錄是課程結束後隔天,就考過PMI-ACP,而我在每堂課上,最常被問到的問題,就是「敏捷要看什麼書?」、「怎麼快速考過PMI-ACP?」以及「怎麼把敏捷用在實務上?」,我就以念佛人常說的「一門深入」和「無量法門」兩個概念,和大家分享經驗:
1.  資訊成千上萬,猶如「無量法門」
      先說「無量法門」吧!Agile的種子1990年代從軟體業萌芽、2001年敏捷宣言發表時開花,到了2011正式PMI-ACP問世後結果,成為「除了軟體專案以外,其他產品專案也很適用」的顯學。Agile歷經20多年的演進,不論是專書、期刊、雜誌、部落格還是網路上的專文,多到不可勝數,簡直就是「無量法門」,而由於Agile是從軟體業界演進而來的概念,如果沒有軟體開發的背景知識,初學者直接接觸往往不得其門而入。試想,如果沒寫過程式,您知道什麼是「單元測試」(unit test)?什麼是「測試驅動」(test driven)?什麼又叫「重構」(refactor)呢?更惱人的是,這無量法門中包含了很多從實務中歸納出來的最佳實務(best practices),不同作者間的見解時有衝突,讓初學者看得一頭霧水。也因此,有些以取得PMI-ACP認證為目標的朋友,信誓旦旦訂出X個月看完Y本鉅著的讀書計畫,不過實際執行時,看越多越慌張,網路上買考題越做越氣,後來乾脆繼續一直等下去。
2. 先求「一門深入」,打通任督二脈       
      難道學敏捷管理不用看書、不用學嗎?當然不是這樣!不論是要考試,還是要將敏捷精髓應用在工作上,最有效的做法叫做「一門深入」,也就是先選擇一種能快速深入了解Agile的途徑,不論是參加國內顧問公司的特訓,還是花錢買國外的線上課程,只要確定講課的人自己用過敏捷,聽過課的人有口碑,這就是您要找的入門之道。一般來說,不論上哪裡開的課,從上第一堂課開始,花費4~6個周末的時間,加上期間每天不到1個小時的複習,就應該能夠考過認證。如果這樣考不過,這門課本身就不夠敏捷了!!! 好比我們要進入體育館,東西南北中各區,樓上樓下加上地下室,共有幾十個入口,每個入口都通到體育館中央,每個路線就是一個「法門」,選到契合自己的入口,沿著指示標記快步走進去,很快就會到目的地,到了目的地再往四周看,自然會對各個出入口的位置有全盤性的了解。相反的,不斷買書或上網看文章,卻又看一半丟一邊,其實只是在體育館入口進三步退兩步,非常可惜。
3. 笨重的流程,推不動變化的產業
      其實,敏捷式專案管理概念的產生,是因為除了大型國防、交通、建築這類適合瀑布式管理的專案以外,大部分人從事的專案,初期既拿不到詳細的規格,而且隨著專案向前推進,利害關係人的想法還會與時俱進,專案執行是「協助客戶釐清需求、創造價值的過程」,而不是70年代以來那些教科書上寫的「團隊按詳細計畫實踐明確規格的過程」。如果您身處在必須求新、求變、求快的產業,您或許會發現,按表操課如期、如質、如預算實踐客戶原始需求的「成功」專案,最終交付的常常是災難。
(A common cause of disaster in software(product) development is that the end product is precisely what the customer originally ordered)-Team Spirit Agility Counts, The Economist, Sep 20th 2001
4. 學的時候站在巨人肩膀上,用的時候腳踏實地
      您想加入敏捷的行列嗎?建議您,先找到契合自己的課程,一門深入,上課過程中,和有實務經驗的老師以及其他同參道友,討教敏捷的眉眉角角,如果英文能力還可以,上完課就快去考PMI-ACP。經過敏捷訓練之後,定期看國內外敏捷相關的資訊,並在工作中刻意套用敏捷的思維做事,自然會累積出自己的敏捷力!

(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®、台灣、中國兩地首位專案風險管理師PMI-RMP®)

2014年3月20日 星期四

你嘛卡拜託,ALM哪是敏捷

徐柏峰


全球最大的幾個軟體工具廠商,這兩年都趕搭敏捷列車,推出應用程式生命週期(Application Lifecycle Management, ALM)工具,聲稱用了這些商用軟體工具就能實踐敏捷的精神,還有人在產品發表會自行宣告說,用這些ALM工具就代表敏捷2.0時代已經到來,讓當初和Jeff Sutherland一起創始Scrum Framework的敏捷大老Ken Schwaber,氣得在部落格PO文痛批,說這是本末倒置的行為(Putting the Cart Before the Hourse???)[1] 其實,Ken Schwaber也就別氣了,根據VERSIONONE最近的調查報告,全世界敏捷開發團隊中,66%使用Excel來管理敏捷專案,至於那些商用(=所費不貲)的工具,不論是M牌、I牌還是H牌的,在調查中顯示的市占率,都遠比他們聲稱的還低很多。


(本文作者為敏捷教練、、全球首批敏捷專案管理師PMI-ACP®、台灣、中國兩地首位專案風險管理師PMI-RMP®)


[1] Ken Schwaber部落格的原文,Agile, ALM, and Agile 2.0 — Putting the Cart Before the Horse???,請參考http://kenschwaber.wordpress.com/2013/04/04/agile-alm-and-agile-2-0-putting-the-cart-before-the-horse/

2014年3月18日 星期二

敏捷開發(Agile Development)

徐柏峰



        敏捷專案管理就是「應用精實管理原則,帶領敏捷開發團隊,駕馭充滿變數的專案」。敏捷開發法是從軟體產業衍生出來的團隊工作方式,對敏捷專案管理的重要性不言可喻。本文先就敏捷開發法的來龍去脈,做一番介紹:

        厚重的計畫文件,推不動變動的產業
專案管理協會(Project Management Institute, PMI)出版的專案管理知識體系指南(PMBOK ®Guide)在全球流通超過450萬本,專案管理的相關知識,儼然成為當代顯學,不過,很多專案披著「正式」的管理外衣,卻仍在使用1970年代航太和營建業的做事方法,管理新產品開發團隊,試圖透過詳細的事前規劃,從需求、分析、設計、實作、測試到上線,一個階成接著一個階段,打造出「完美」的產品。很不幸地,這些專案通常從啟動日開始,先用超過一半的時間寫文件,剩下不到一半的時間才用來開發。本來以創意活力維生的開發團隊,被當成生產線的機台,不斷加班趕工,而照著白紙文件規格開發出來的成果,交付到客戶手上竟然發現...原來需求搞錯了方向。此時專案不管要不要繼續執行,逾期、超支的這筆帳,通常就算在開發團隊的頭上。
其實,除了航太和營建產業以外,大多數開發專案的本質就是變更,客戶在專案初期只能提出大概的想法,要看到團隊交付實際成果,客戶才會「有感覺」,才能進一步提出比較具體的需求,至於厚重的產品規畫文件,對新產品開發這種充滿變動的產品來說,不但浪費時間,而且根本派不上用場。

開發新產品就像橄欖球爭球,情勢隨時在變化
基於這個體認,日本學者竹內 弘高(Hirotaka Takeuchi)和野中 郁次郎(Ikujiro Nonaka),早在1980年代就曾根據就近觀察產業的心得,在《哈佛商業評論》(Harvard Business Review)上發表專文指出,全球市場求新求變,競爭激烈,新產品開發帶來的營收,是很多大廠賴以為生的命脈,為了快速又有彈性地開發出新產品,很多大廠放棄部門對部門的接力開發方式,改用類似橄欖球賽(rugby)的組隊方法,從各部門挑選出代表性的成員,組成跨職能(cross-functional)團隊,專責在短時間內,開發出公司的明星產品。當年,竹內 弘高和野中 郁次郎把這種團隊開發方式,比喻為橄欖球賽裡面的正集團(Scrum)鬥牛,並以「新新產品開發遊戲」(The New New Product Development Game)來描述這個管理專案的方法。[1]

豐田業績長紅,精實生產獲得各界矚目
大約在同一個時期,以豐田(Toyata)為主的日本汽車,在美國攻城掠地,通用(GM)、福特(Ford)和克萊斯勒(Chrysler)這三巨頭(The Big Three)市占率節節敗退,就連美國政府強迫日本簽下「『自願性』貿易協議」(voluntary trade agreement, VTA),限制日本對美國市場輸出的汽車數量,也無法扭轉美國汽車業的頹勢。對此,美國麻省理工學院(Massachusetts Institute of Technology, MIT),耗費鉅資啟動研究計畫,思索全球汽車產業的未來,並希望瞭解豐田汽車當時攻無不克的原因,時至1990年,沃麥克(James P. Womack)等幾位學者把研究心得,寫成《改變世界的機器: 精實生產個故事》(The Machine that Changed the World: The Story of Lean Production),這本書的副標寫著「豐田在全球汽車大戰的秘密武器,正在掀起世界產業革命」,這就是豐田的生產方式被稱為精實生產(Lean Production)的由來。[2]

傳統無法解決問題,敏捷開發嶄露頭角
90年代資訊科技(Information Technology, IT)蓬勃發展,著重大量文件的傳統專案管理思維,已經和軟體開發的現實脫節。許多有志之士認為,IT業界需要的是輕量級的開發方法(lightweight methodology),其中,當過飛官、醫官的軟體產業傳奇人物--Jeff Sutherland,受到「新新產品開發遊戲」這篇文章的啟發,在OOPSLA'95大會上,和 Ken Schwaber一同發表了軟體開發專案應用Scrum流程的概念,並在接續的幾年內,根據實務經驗,提出舉世聞名的Scrum Framework,這就是後來最多人應用的敏捷開發方法(Agile Development)。約莫在同一個時期,在IT業界推動軟體設計模式(Software Design Pattern)和測試驅動開發(Test-driven Development, TDD)而馳名的Kent Beck,帶領團隊開發克萊斯勒的C3工資系統(Chrysler Comprehensive Compensation Payroll Project)Kent Beck彙整實戰心得,在1999年出版《極致軟體製程》(Extreme Programming Explained: Embrace Change),提出簡稱為XP的開發方法,在當時被視為帶領小型開發團隊,面對需求模糊、變更頻繁專案時的一盞明燈,成為另一個知名的敏捷開發方法。2000年春天,Kent Beck邀請了一群業界先進,在美國奧瑞岡州(Oregon)聚會,討論軟體業應該有的輕量的開發方法,雖然沒有獲得什麼實質成果,倒是開出了第一槍。

2001敏捷開發大會師
到了20009月,軟體業名人Robert C. Martin,透過Email發出英雄帖,並設立網頁籌備下一次輕量開發陣營的聚會,當時的邀請文字寫說:「我打算在200112月間,在芝加哥市舉行一場小型會議(為期2)。會議目的是讓主張輕量方法的各方領袖齊聚一堂,除了受邀的您以外,還希望您告訴我該和誰接觸。」後來這群受邀者幾經討論,決定在猶他州的斯諾柏德(Snowbird, Utah)這個度假勝地聚會,時間就訂在2001年的21113日。聚會當天,來自XPSCRUMDSDMAdaptive Software DevelopmentCrystalFeature-Driven DevelopmentPragmatic Programming7大門派,一共17名大師齊聚一堂,在彼此競爭的軟體開發業界,算是空前的盛況。
會議的主題,是改善既有軟體開發太重視表面文件的笨重流程,希望找出各家能求同存異的看法,會議的成果,就是後來鼎鼎有名的「敏捷軟體開發宣言」(Manifesto for Agile Software Development)。根據Jim Highsmith的說法,兩天的聚會輕鬆愉快,在快要接近尾聲時,Bob Martin開玩笑,要大家留下幾句含糊的聲明(mushy statement)再解散,其他成員聽了之後反而覺得,難得有這麼多派的大師在場,既然大家都覺得傳統開發做法不可取,倒不如利用這次聚會,集思廣益想出一些鼓吹人本、信任、尊重和合作的觀念,敏捷軟體開發宣言,就是這樣產生的。至於為何取名叫敏捷(Agile)呢?據說,當年各派的大師們,雖然都對重量的開發流程覺得不滿意,但也不想把自己鼓吹的做事方法被叫做輕量開發法,幾經討論之後,大家聽取Martin Fowler的意見,才選用了敏捷這個字。至於宣言裡面短短的4句話,目前已經獲得各界認同,成為開發團隊在面臨變動專案時「動則得救」的心法:


       價值驅動,滿足變更需求
敏捷軟體開發宣言問世後,引發了廣大迴響。《經濟學人》(The Economist)刊出「團隊精神:敏捷說了算」(Team Spirit: Agile Counts)專文,介紹敏捷開發法,這篇文章劈頭第一句就說:「開發軟體時,災難的常見原因之一,就是交付的產品和客戶當初訂的一模一樣(A COMMON cause of disaster in software development is that the end product is precisely what the customer originally ordered)。咦,做出客戶期初想要的產品,有什麼不對?相信多數的軟體開發同業都同意,軟體開發專案中,客戶一開始只能講出大方向,大概的講法,不管期初的需求和規格文件怎麼寫,客戶要操作到真正交付的軟體,才會「比較有感覺」,才會進一步講出新的想法,如果開發團隊堅持完全照著期初的文件來做事,或是在客戶有新需求時,推說不在合約內,或是動輒祭出「變更管理委員會」(Change Control Board, CCB)來抗拒變更,就會和客戶實際需求漸行漸遠,到了期末交出來的成果,當然不會獲得客戶認同。這種必須與時俱進的「特色」,就叫做「價值驅動」(value-driven),只要是需求變動快(volatile)、產品上市時程急迫(urgent)的產業,都有類似的情況,其中又以新產品開發的專案最為明顯。

敏捷開發席捲全球,企業和政府全買單
2001年起,敏捷軟體開發宣言的心法,很快就獲得全球主流軟體公司青睞,成為帶領開發團隊的事實標準(de facto standard ),而敏捷開發法用來規劃產品、開會、分工和共享資訊的做法,已經成為舉世公認的最佳實務(Best Practices)。影響所及,國外就連政府機關也開始轉向,英國和美國政府不約而同地從2011年開始,把敏捷方法視為推動資通訊專案的當然作法。其中,英國政府在內閣辦公室(Cabinet Office)下,成立了「政府數位服務團」(Government Digital Service, GDS),組成超過500人的團隊,協助政府以民眾需要為出發點,進行改造;至於美國政府,則是在總務署(General Services Administration, GSA)成立一個超過100人的團隊,幫政府資訊專案進行敏捷轉型。

日前,知名敏捷開發工具供應商VERSIONONE,針對全球軟體產業導入敏捷開發(Agile Development)的情況,發表了年度敏捷現況調查報告 (8th Annual State of Agile Survey),當中針對已經導入敏捷開發的團隊進行調查,詢問敏捷開發對實際專案有什麼幫助,報告中顯示的前5大好處是:管理變更優先順序、增加產能、提升專案能見度、改善團隊士氣,以及提升軟體品質。不過,報告中也提到,如果要在整個公司推廣敏捷,最大的成功要素是要獲得高層的支持,其次是要經過訓練的課程,再其次才是團隊使用共同的工具。由此看來,要在團隊推動敏捷開發,一定要有由上而下的支持,才能真的動起來。

相關文章:靠北不是敏捷開發,不寫文件也不是

(本文作者為台灣敏捷專家協會理事長)




[1] Takeuchi, Hirotaka, and Ikujiro Nonaka. "The New New Product Development Game." Harvard Business Review (January–February 1986)
[2] Matthias Holweg, The Genealogy of Lean Production, Journal of Operations Management 25 (2007) 420–437

2014年3月16日 星期日

有PMP又怎樣,照樣領低薪

徐柏峰
圖片來源:http://learnthat.com/2008/01/how-to-ask-for-a-raise/
踏入專案管理領域以來,常看到業者的文宣說「取得PMP證照 = 增加專業競爭力」,不過這幾年以來,工作上接觸的上千的PMP,幾乎沒聽過哪位前輩,講出飛上枝頭做作鳳凰的故事。身為PMP的過來人,基於不服氣的心態,我試著針對「有PMP能不能加薪?」這個疑問,找出比較可靠的答案。
我推論的假設是:如果具備的能力對工作有用,而且可取代性低,就是值錢的「專業」。換句話說,如果某個「專業」不受到薪資市場的肯定,那麼這個「專業」不是工作上用不到,就是可取代性很高。
PMI釋出的專案從業人員薪資調查(Project Management Salary Survey, 8th),報告中的統計數字,透露出當中的玄機。根據統計,台灣PM的薪水水平,從2007年起算,世界排名從第18名,一直「進步」到第30名,就連年均國民收入只有2,450美元的的奈及利亞,PM年薪中位數都還比台灣高7千多美金;台灣逐年退步的同時,靠著銀彈和組織化戰術,用考古題開PMP課程的補習班,卻每個月卻像工廠一樣,不斷製造只會背題目考試,卻不能上場做事的PMP,這群人就像背口訣考到駕照的人一樣,沒辦法把PMP的原理,真的用在工作上。對用人的公司來說,既然應徵來的人頂著PMP證照,但卻不會工作,而市場上有這張證照的人又那麼多,證照對薪資的加分效果當然很差。
更有趣的地方是,其實,PMIPMBOK® Guide裡面推動的「專案管理」,把專案細分成5大流程群組、10大知識領域,一共47個工作流程,PMI在自己官網上販售的PM文件範本大全》(A Project Manager’s Book of Forms),洋洋灑灑列舉了50多份文件樣本,是的,您沒有看錯,身為一個「專業」的專案經理,竟然有50多份文件要做,在以中小型團隊為主的華人地區,如果業主沒要求,結案也沒用到,老闆會不會投資人力去養這些文件,答案應該很明顯吧?與其抱怨公司文化不成熟、同事懶得寫文件或是客戶不尊重專案管理,不如回頭想想,目前主流的這種「專案管理」,當初到底是怎麼來的?
其實,這套遊戲規則,打從一開始就是從營建和國防航太產業累積出來的做事方法,PMI1989年開始,每年頒獎給「最能代表PMI專案管理理念」的年度專案,這個獎一直到2014為止,一共頒了18座給營建業、5座給國防和政府專案、1座給航太專案,這些專案的預算通常是天價,而且動員的人數也非常可觀,而且專案一開始,客戶就能明白描述最終成品的規格,專案是透過詳細計畫,實踐固定規格的過程,因此需求變更是例外,必須召開正式的「需求管理委員會」,決定是否追加減預算或重訂時程來接受變更。這種「天龍國專案」的遊戲規則,和普羅大眾經手的專案很不一樣,因為很多產業的專案,人數少、時程短、客戶開始只講得出大方向,而且在過程中需求一定會持續變更,硬套「天龍國專案」這種「先寫作文再做事」的工作流程實在有困難。詳細統計請參考天龍國PMP在吃麵,你喊什麼燒?擁抱Wet Agile吧!
Source: 彙整自 PMI Project of the Year 官網

再來看另一組數字。您知道在台灣、中國、新加坡和香港等「大中華地區」,有多少人真的從事營建和國防航太等工作嗎?有多少人有幸在管理這種「天龍國專案」呢?光以台灣來講,PM從業人數最多的資訊科技業,至於天龍國產業的專案從業人員,只有3%多而起。換句話說,有超過96%的專案,根本不適合硬套PMP那些計畫驅動的瀑布式流程。這個情形,在其他華人地區都很像,因為工作用不到,所以薪水當然少囉,這就是當初那些PMP補習班廣告沒有告訴您的事。

相關文章:天龍國PMP在吃麵,你喊時麼燒?擁抱Wet Agile吧PM薪事報你知:想賺高薪,動則得救PM薪事誰人知,全球排名篇:專業人才淪賤民,台灣競爭力悲歌
(本文作者為敏捷教練,全球首批敏捷專案管理師PMI-ACP®、台灣、中國兩地首位專案風險管理師PMI-RMP®)

2014年3月15日 星期六

Every Agile Project Starts with a Need and Is Guided by a Why



為了滿足需要(Need),客戶表達出需求(Requirement)
為了釐清需求,團隊和客戶雙方確定了規格(Specification)
為了做出符合規格的成品,團隊自訂應該做的任務(Task)
為了給團隊方向感,PM協助客戶和團隊勾勒願景(Vision)
為了逐步實踐願景,PM協助客戶和團隊制定目的(Goal)
為了確定達到目的,PM協助客戶和團隊訂定目標(Objective)
聰明(SMART)的目標,就是:
-Specific 明確
-Measurable 可測量
-Attainable 做得到
-Realistic 務實
-Time-bound 有時效性

一切都從需要開始!!!

Pofeng Hsu, PMI-ACP®, PMI-RMP®, PMP

2014年3月6日 星期四

從PMI Fact File,窺探專案管理市場的未來

徐柏峰
每期 PMI Today 的 PMI Fact File,都會公布 PMI 全球會員數、PMBOK Guide®流通數,以及PMI 旗下各大專案管理相關認證的取得人數,持續觀察這幾個數字,可以發現,截至2014年12月底為止:
1. 全球取得PMP的總人數,已經超過63萬人,每月PMP取得人數的成長率雖然不高,細水長流的效果非常明顯。
2. 各版本累計的 PMBOK Guide®計的流通數,已經超過470萬本,足見PMI在專案管理的領域,已經取得別人無法取代的發言權。
3. PMI-ACP® 從2011年第4季問世以來,每月認證取得人數的成長率,持續領先PMI的其他認證,即將成為 PMI 的下一個金雞母。

資料來源:各期 PMI Today

PMI-ACP: 世界正快步走向敏捷,那您呢?

徐柏峰
      The World Is Quickly Becoming Agile, Are You? 這是專案管理協會(Project Management Institute, PMI),在官網介紹敏捷專案管理師認證(PMI Certified Agile Practitioner, PMI-ACP®)的主標,這簡單一句話,也透露出全球專案管理思維的巧妙變化。



      PMI成立於1969年,在專案管理領域,是公認最權威的國際組織。PMI出版的《專案管理知識體系指南》PMBOK® Guide,全球流通超過440萬冊PMI頒出的專案管理師認證(Project Management Professional, PMP)超過60萬張,PMI全球會員將近45萬人,光以2013年度來看,PMI推廣專案管理認證得到的收益超過2億美元,雖說是非營利組織,但收益的能量實在驚人。
Source: PMI Financial Statements


      身為專案管理領域的龍頭老大,PMI約從2007年開始,就在每月出版PM Network雜誌上,登載Agile的相關專文;推廣敏捷專案管理的幾個大師,例如Jesse Fewell,應邀在PM Network上定期發聲介紹敏捷,成為專欄固定班底;Agile相關的文章,是PMI統計讀者最想閱讀的資訊。


資料來源:各期 PM Network
     
      PMI在2014年發表的專案從業人員薪資調查(Project Management Salary Survey, 8th Edition),條列專案經理這項職務相關的13類「技術經驗」(Technique Experiences),推敲同樣從事PM工作的人,到底要具備哪類的「特異功能」,才會拿到比較多薪水。這項薪資調查的主要樣本,全球PMP人數最多的31個國家(PMP人數美國第1、中國其次、台灣第7、南韓第8),各國雖然文化有差異,可以調查結果卻意外的類似。僅以台灣而言,同樣是5年以下經驗的PM,會做敏捷式專案管理(Agile Project Management)的PM,年化所得的中位數就是比其他人還要高,因為這種PM會帶領團隊,因應變更;更有趣的是,最不值錢的專長,就是凡事按表操課的資源管理型PM,以及按照步驟一、步驟二、步驟三......,一個口令一個動作的流程管理型PM。(相關數字請參考 PM薪事報你知:想賺高薪,動則得救)

      PMI既推廣PMP認證的成功經驗後,從2011年第4季起,強勢推出PMI-ACP®認證,並透過官方網站、期刊雜誌和各種文宣攻勢,大力推廣用敏捷方式管理專案的思維。這一波敏捷攻勢,在專案管理業界到底跑得多快呢?

  • 在資訊科技業界最知名的市調單位GartnerGroup表示,到2012年底為止,全球超過8成的軟體開發專案,都用到敏捷的實務;
  • 從全球性大企業現職員工在LinkedIn上的履歷可以發現,敏捷能力是是擠進A咖公司的重要指標,知名的交易支付平台Paypal已經有56%的敏捷履歷、在Gap、Fidelity、Apple、Walmart、Microsoft和Cisco的敏捷履歷,也都已經超過25%。
  • 如果觀察PMI的全球會員數、PMBOK® Guide流通數,以及PMP, CAMP, PgMP, PMI-RMP®, PMI-SP®和PMI-ACP®這6大認證,可以發現,2012年1月起算,PMI-ACP®的每月人數成長率,已經持續蟬連第一了,這個現象凸顯出,整個專案管理的市場,已經一面倒地選擇求快、求變地敏捷式專案管理,才是因應當前環境的最佳解答。(請參考 從PMI Fact File,窺探專案管理市場的未來)
      用敏捷的方式做專案,在講求快速回應市場需求的IT領域,早就是行之有年的實務,全球知名的幾個大廠,從2001年敏捷宣言(Agile Manifesto)出現以來,就陸陸續續以Scrum, XP等敏捷方法在做產品專案,用搜尋引擎找徵才資訊,就會發現原來這些大咖廠商好幾年前就在用敏捷實務人員了。目前這波來勢洶洶的敏捷攻勢,其實是PMI身為專案管理領域的龍頭,有感於長年推行的PMP,其實無法套用在大多數人真實工作的環境,按照PMBOK® Guide的方法做事,在國防、航太、營建、交通、煉油.......這類的天龍國產業以外,根本是「舉步維艱」,因此PMI見賢思齊,把軟體業界的成功經驗,轉化成不分行業,只要是管理充滿變更的專案就適用的敏捷式專案管理,由於PMI的影響力實在太大,因此從PMI-ACP®問世以來,Agile, ACP, 敏捷、快速回應需求......這些字眼,陸續攻佔媒體以及管理雜誌的相關版面,成為一門顯學。
以上商標、Logo為各廠商所有

      有趣的是,在還沒搞清楚Agile是什麼之前,一向靠考古題製造PMP的幾個補習班,紛紛插上ACP的旗號;就連還在推銷笨重管理流程的學者、專家和顧問們,也陸續開班授徒,傳授自己也沒有的「實務技巧」,成為另一項台灣奇蹟。為什麼這套標榜應變的做事方法會受到各方肯定呢?因為它太貼近事實了,它講的是怎麼讓團隊把客戶要的東西端出來,而不是怎麼寫出一大疊文件去表現出「管理專案的樣子」。

後記:PMI的 PMI-ACP®官網原本的標題是The World Is Becoming Agile, Are You? 不過從2012年10月某日開始,標題被悄悄加了一個字,變成The World Is Quickly Becoming Agile, Are You? 如果您也從事專案相關工作,這世界正快速走向敏捷,那您呢?
(本文作者為全球首批敏捷專案管理師PMI-ACP®、台灣、中國兩地首位專案風險管理師PMI-RMP®)