2012年12月2日 星期日

學而知Localization-參與「一日專案經理模擬營」有感


今天參加了B&J開的「一日專案經理模擬營」課程,朋友說:「都在當PM了,還去花錢上一日專案經理模擬營喔!」上過課後,肥蝦可以理直氣和的說:「是去度假休息,兼溫故知新呀!」

今天的同學除肥蝦外,還有五人分別來自製造、軟體產業,因著產業屬性與公司文化的不同,大家經由課程的參與交流,更可以省視自己的問題與關卡。這一天的課程讓肥蝦感觸最深的就是:「學而知Localization」,何為?

在肥蝦所處的環境中,幾乎專案經理被要求的最重要職責就是「如期收錢」。專案管理所標榜的「如期、如質、如預算」,在現實中變成了「收錢、收錢、收到錢」,公司對於專案經理的惟一殷盼就是專案收到錢(還有少花錢)。專案經理在上有老闆、客戶,右有業務、部門主管,左有成員、協力廠商,動作之間受到整體社會與公司文化的拘束,因此一心一意只記得:「減少被責難,設法收到錢」,如果行有餘力,試圖進而作到「可以被肯定,如期收到錢」。就因為只顧慮著錢、錢、錢,一心想著專案目標、執行策略、作業戰術、保護合約己方權利,蠢蠢記得逢迎老闆與客戶、跟業務與部門主管協調資源分配、努力催促成員與協力廠商達成進度,卻常常忘了專案管理的核心與基本面-五大流程、九大領域。

「一日專案經理模擬營」最後Bryan的一句話讓肥蝦深有感觸,「一個專案不管規畫的好壞,專案的範圍界定、資源分配、人力資源協調、後續的持續溝通與管控,是一個專案管理最基本的要素。」在課程的模擬案例中,肥蝦一心只記得怎創造最大的無形與有形效益,如何極大化自己手中與獲取其他部門的資源,如何躲避或減除限制,擬定專案的目標、策略、完成應交付服務項目與提列風險計提金額;卻忘了擬定與甲方間專案範圍的界定及介面規範,忘了安排完整WBS進而配搭現有RBS,忘記了擬定專案作為應考量的base line schedule忘了設milestone與檢核點,忘了持續溝通機制建立忽略了風險項目的鑑別與評估,忽視procurement管理

專案規畫就如PMBOK所說的是漸進式的完善,因此不可能馬上就能完善,因此在拿到project charter後,專案開始的重點是思考面要足夠與立基點要紮實,促進專案成員大家一同思考一同努力共創大家的目標與夢想,協調專案間利害關係人的溝通機制與作業步伐,建立共同工作的ground rule。就像肥蝦常說的:「作軟體的不要拿到案子就只想著下去寫程式。」相對地,「作專案的也不應看到案子就只想著要完成的項目。」忽略了建立整體的鳥瞰圖或者說是大藍圖。

肥蝦作專案斷斷續續也已十年光景,接觸PMBOK也已八年的時間,雖然考過了PMP,五大流程與九大領域也是熟稔於心,但在面對周遭的環境卻只一心想著合約、完成老闆的交代,對於建構專案管理的應有基礎時常忽略。這態度與習性雖說是因著所接觸的環境與風氣而養成,但也實在太Localization,忘了一個專案經理應有的格局。

「學而知Localization」是肥蝦參加此課程的最大收獲,除了一心鑽營專案目標、執行策略與應交付項目外,整體的專案管理基石也要同步考量並設法紮實奠基-明確協調甲乙方PM與單位負責的範圍與交接介面,建立後續持續溝通與互動回饋的機制;建構包含完成專案交付明確項目的整體WBS,布局專案項目與專案管理項目的大藍圖;建立WBSRBS交叉矩陣專案組織架構,確立專責人員;建立專案過程的重要里程碑與檢核點;估計風險可能因子與因應對策;注意外購資源與人力的安排與訓練等,這都是肥蝦應該再加強的部分。
這是的課程相當有趣,成員間與講師間的互動也很輕鬆愉快,課堂模擬只要動動腦筋想想、動動手指打打字,不用顧慮後續真實承受的壓力,B&J也以專案管理的專業角度指導,肥蝦不僅快樂地渡了個愉快週末假期,也認識新的朋友,更能趁機審視自己,接收新知,還可兼拿七個PDU,實在可說相當划算。

2012年11月28日 星期三

化繁為簡-從活動間的依賴說起


在臉書的社團中,好友八樓哥提了一個問題:MS project中,A活動duration=1 B活動duration=20 B活動開始3天時A就必須要完成。這樣子,任務連結要怎麼寫?我是直接把B切成B1+B2=3+17 然後把A設為B2的前置任務,A要在B進行3天時就要完成。A1要在B進行10天時就要完成。所以B的前置任務是A fs-3 BA1 fs-10 B嗎?

接著,八樓哥又說了以下條件:
條件1.A以及A1的開始跟B有甚麼關聯?? -> 沒關係
條件2.A以及A1的完成條件跟B又有甚麼關聯? -> 沒關係
條件3.A是一個部件到?時間,需要一天處理。
條件4.A1部件是即到即用。

就上述的情境,依據PMBOKGuide,正確的答案應該是【Activity A FS -3 Activity B】,Activity B依賴Activity A,這是非常明確的


但肥蝦這幾年來在執行專案,設定時程與申請資源調度,有兩點想跟各位朋友分享:
(一)  一個活動不要弄太長,並且中間又陸續整合或串接其他活動。
(二)  雖然依賴關係有FSSFFFSS,但其設定除了絕對的因果邏輯外,還要對照合約,並且要易於說明。

PMBOKGuide上,說明WBSPackage要以有交付物或可管理的基礎作為單位較好,activity則為執行的活動,並不一定要有交付物,但應以管理為依據。因此以八樓哥的例子,肥蝦一看,A好像是B開始三天後投入物!因此是否Bactivity搞的太大了,稍為切一下會不會比較好?

當然,如果只是為了表示符號去切割單位packageactivity是不太恰當!如果B不能切割,就該說明來看:「在B活動開始3天時A就必須要完成」,這只有B開始日,以及要求A一定要完成的日子。所以最遲是B開始的第二日A就一定要開始,(A要一個工作天);此外又沒有其它對A的限制,A的完成條件跟B沒關係。因此保守起見,又或者沒有活動A資源調度的問題,那就讓AB一起開始【A SS B】。

PMBOKGuide上也說,FS的關係是最常用的,但是想想:「當活動A完成後要啟動活動B」,對照一下合約!現在台灣的環境有幾份合約會寫說:「簽約次日起三個月內完成需求確認;需求確認完成起三個月內完成系統開發」好像都是「簽約次日起三個月內完成需求確認;簽約次日起六個月內完成系統開發」又再想想,當向老闆報告時,如果太多的FSSF的老闆的反應會如何?如果向部門主管協調人力或資源時,會不會被以「前一項活動都還沒完成,等前一個要項完成了再來討論」的理由搪塞?

記得當the one-page project management剛出來之時,肥蝦也想學學來看看,結果被一位老長官當面批說:「那一頁密密麻麻的,我只在乎合約,以及合約上的milestone」專案管理的資訊很多,不管以何種方式呈現,重點是在溝通!在溝通過程與專案內部的使用工具或語言可否具有相當的一致性!內部使用要求的具體與週延可否順利並迅速的轉換為外部溝通的簡要與效果!

因此就上述的問題,肥蝦以為當活動A一天可完成時,需要活動B先完成三天的進度,因此風險是是B大於A加上A  independent on BB dependent on A,要是B2天進度delay了,A進來的效果也有限。此外,若是從合約的主體與溝通的效果來看,A FS -3 B B SS +2 A哪一個較能觸碰人的感知與警覺?因此肥蝦在考量活動之間的關係時,除了實際的依賴邏輯外,也會儘量考量每個活動在整體風險上的份量與合約規範主體,盡量把那些SFFF轉成SS然後加上每個活動的duration、寬限期與警示期,尤其是那警示日。

如果肥蝦把此問題的答案由A FS -3 B轉成B SS +2 A~~~也許您會問到:「那到時關鍵路徑如何標示?」CP是那完成專案最長時程,因此理論上就算把依賴關係稍微變化也不會有影響的。也許您又會問到:「那把依賴關係弄混了,就看不清楚那前因後果,看不到可能的專案瓶頸。」專案中的每個活動都是重要的,如果不重要也不會排進專案的範圍與時程之中,因此重點是在於那些為瓶頸活動的瓶頸在哪呢?是該活動可使用的資源有限?還是人力技能不足?還是時間不夠充份?就以肥蝦個人有限的經驗,瓶頸活動的瓶頸重點大多還是在是否有適宜的資源,所以使用SS的方式來溝通,也許能夠給予主管較為深刻的印象,看看是否能在專案初期的組織安排上佔得些許許的先機。

專案的目標在達成專案目標,WBS, Activity, CP, Schedule僅是工具,因此專案的任何作為還是要以合約為依據,以合約規定的方式與設定的milestone來作為專案進一步範圍、時程等等細部規畫。因此些許PMBOKGuide說明的方式,也許在實際專案執行上可以再稍為調整簡化一下。

以上蝦扯一通,純是個人的愚見,還請  各位多多包涵。

2012年11月18日 星期日

軟體開發流程、開發文件與系統程式對得起來嗎?


因著前公司的政治糾葛,肥蝦不得不於101日轉移戰場。記得927現在老闆打電話給肥蝦說:「有沒有空跟他去一趟客戶那!」本想說可以接到個新案子,疏緩一下這幾個月來的紛亂。不意去到後發現雙方正為了案子的文件與範圍鬧得不可開交,肥蝦還遭受炮火的轟擊!正所謂吵架無好話,這肥蝦是看淡了,只是這後續如何化解?如何完成專案?才是肥蝦關心的議題。
這個案子的主要爭議點之一就是要交付的文件種類與對文件品質的定義。因著客戶通過CMMI Level3的評審,對於案子文件種類與品質有一定要求;相反的,因著公司(101日上任了)內部進行的開發方式與文件撰寫方式,也因一定時間的累積有著自己的看法。因此就造成甲方嫌棄乙方的文件不夠Qualified,乙方認為甲方是變相增加工作範圍,引起雙方的不快,就變成了肥蝦首要面對解決的問題。
針對爭議,惟一的作法就是回到合約主體,看看原有合約到底有哪些條文是否涉及這爭議項目?盡力就合約記載去縮減雙方認知的差距!因為肥蝦不是本案的PM,因此就去請教PM與申請調閱RFP。結果發現了一條:本案專案開發應遵循CMMI相關規定。哇~~~光這一條,至少就得增加成本30%以上!因為本公司並沒採行CMMI,美其名可說我們Follow的是Agile software development,光就這文件的提供不啻要有專人負責,也要配合開發過程逐步產生才行。
因為甲方已經接受了先前第一、二階段的需求分析書、系統分析書、測試計畫書(雖然對方PM是諸多抱怨與覺得委曲,但木已成舟),因此肥蝦首要的就是設法達成雙方對系統設計規格與程式規格文件的撰寫要項與內容。甲方PM是很有誠意設法完成專案目標(先不論對專案開發範圍的要求是否雙方都能接受!),因此經過幾次的會商,就甲方提供的樣本進行討論與溝通,雙方作了部分的妥協,肥蝦就只好耐著性子、硬著頭皮,就程式碼回頭來寫相關文件。拼了一個月,經過三、四次的磋商,掰出了三十三份的程式規格書,以及系統設計文件,交付給甲方審查。至於第三階段,肥蝦就能本著自己的想法進行撰寫,但是光桿司令一員,也似無多大作用啦!
在軟體開發與測試流程,從需求分析、系統分析、系統設計、程式規格、程式碼,到對應的測試計畫、測試實例,有著一般普遍接受的V模型。

圖片來源:http://arithmandar.blogspot.tw/2009/08/v-model.html
另外,就物件導向開發文件,UML定義了十種圖示文件:使用案例圖(User Case Diagram)、類別圖(Class Diagram)、物件圖(Object Diagram)、順序圖(Sequence Diagram)、合作圖(Collaboration Diagram)、狀態圖(State Char Diagram)、活動圖(Activity Diagram)、套件圖(Package Diagram)、元件圖(Component Diagram)、部署圖(Deployment Diagram)。其中套件圖不是UML正式規定的圖表,而使用案例圖因為太過簡約,也多會配合使用案例文件。
以上各圖表的定義與使用,網路上與市面上均有各樣的資訊提供,肥蝦在此想要說明的是:文件、開發流程與程式間的對應,如何與實務間進行協調,達成一致性的要求,並且有助於後續系統的維護與開發。
就肥蝦所接觸的現況中,台灣除了資本雄厚、稍有制度的軟體公司(這可跟他們有沒有獲得CMMIISO認證無關),一般多在確認需求分析後,程式設計師就著手Coding,開發所需的系統分析與設計等文件,因為在專案合約多未載明交付時程,都在驗收的時候在拼命補,搞得人仰馬翻,寫出來的文件也跟實際有著相當大的差距。甚者,因為每人的開發與coding習慣不一,文件寫得更是參差不齊,搞得一本多綱,連那目錄都難以統合。
就肥蝦經歷與合作過的廠商夥伴而言,基本上純外商的文件在就定義與內容上均優於本土化的外商;本土化的外商又多優於純本土廠商。若只就台灣設有分公司或公司的廠商而言,不可誨言的,I18M的確是較優的,其它有些廠商雖然也有詳細文件,但系統分析或設計文件,應該比較像是既有系統的說明書,多無法實際反應出客製化過的系統,更難以反映出系統從分析、開發到測試的過程。
在系統開發過程中,每個人對於系統文件與圖表的作法均有自己的偏好或公司的規定。肥蝦個人,習慣上喜愛使用案例圖與文件,流程圖或泳道圖(可能是因為一開始肥蝦是從程序式語言Cobol入門),系統模組架構圖,操作畫面輸入/出示意圖,資料庫的ER圖表,模組內的程式設計文件(如果是物件化程式就改以類別圖),並且針對每種圖形,再輔以表格說明。
由於肥蝦是非資訊本科系(後來唸了個世新資管在職碩班,還沒畢業,對不起指導教授ㄚ!),對於【人】的角色與定位,在系統開發中非常強調,也很在意與專案成員的分工互動中,介面的界定。因此,就一個新系統的開發,個人習慣性的步驟會是:
(1)使用案例圖與表:界定使用者在系統中扮演與操作的角色與定位。
(2)流程圖或泳道圖:界定使用者的作業啟始到結束狀態,其間的系統處理過程,以及與其他使用者的互動。
(3)模組架構圖:界定系統處理過程的區塊切分,以及其間溝通的介面。
(4)FrontPage畫個使用者介面輸入/出示意圖:確認使用者操作的輸入與輸出要求。
(5)資料庫的ER圖表:界定系統資料存放的方式與儲存的本體,以及配合系統流程的狀態轉移所要配合的儲存資訊與資料。
(6)就每個模組再進一步寫出程式設計文件:針對系統模塊負責的處理要項,明確對應資料庫的表格儲存。
(7)最後就整體系統繪製系統流程圖:界定細部的系統處理與資料轉接過程。
在遞次撰寫文件的過程中,也能不斷的發現問題,回頭審視上一層的文件,進行修正。至於程式規格,就請程式設計師在Coding的同時,根據個人的實際作法,把相關的細節增添進程式設計文件,成為程式規格書。因此肥蝦在進一步查看同仁的程式前,習慣上會要求讓我先看他()們寫的規格書,如果覺得可疑,再進一步去看程式碼,利用文件來QA程式碼的品質。
古諺有云:「大軍未動,糧草先行。」對應到系統的開發,至目前為止的經驗,肥蝦也深信:「程式未寫,文件先行。」經由文件逐步取得成員間的共識與反饋。使用案例圖與表,可以取得與使用者間對於系統地位與功能的共識;流程圖或泳道圖,取得開發團隊SA人員間對系統整體的共識;模組架構圖取得SA人員與各開發小組成員間的共識;使用者介面輸入/出示意圖進一步確認使用者對系統的認知;資料庫的ER圖表與程式設計文件獲得程式開發成員間coding的共識與基礎;而程式規格書就用來確認開發成員對於SA(SD)要求認知的回應與實現。
在系統開發架構中,肥蝦以為該簡單的就儘量讓它簡單,最後再就那20%較複雜的作業,思考那簡化單元的串接作法,或再進一步要求其他區塊配合。
在這一次後補程式規格文件過程中,肥蝦就深深體會到如果成員間沒有共識,沒有界定好大家可以自行發揮的範圍,先不論那程式的寫法大家差異很大,只光那DAO讀取資料庫的程式,大家就各出奇招,搞得程式規格實在非常複雜。
系統開發的文件類別,不管在教科書或實務上雖然有一定的共識,但對於每種文件的內容與細節卻是要因案、因人而異,重點在於每種文件的功用,以及誰是閱讀者。如果忽略了文件的主要閱讀對象與其資訊能力,以及他()們所盼望從文件中獲得的訊息重點,一份文件不管怎麼寫,一定是大家都有意見的!
以上僅是肥蝦的個人淺見,還請  各位先進多給予指導!在軟體專案的學習中,肥蝦還有很長的路要走、要學,經由您的提攜,希望能縮短一點學習的時間,並且累積更多的能量。

2012年11月4日 星期日

執行中專案的度量



肥蝦今日幫一位好友填寫開放式問卷,肥蝦這位朋友的研究主題是承攬後,或說得標後的專案進度衡量與估算。其實該友已是一位浸潤於軟體專案管理與系統分析多年的專家了,就只為了湊一下訪談人數,只好把肥蝦這濫竽拿來充數;肥蝦為了義氣,也只好厚顏的忝充一下【專家】(好像唸高中同學間為了考卷上的簽名只好彼此充當對方家長一樣)。因為問題還蠻有意思的,因此肥蝦就更無恥的把肥蝦的回應潑到部落格來一同與大家討論與分享!
為了尊重好友的智慧產權,肥蝦就搞了一個山寨版的問卷。

開放問卷的回答
==============
問題一:肥蝦對不同類型的案子是否有不同的進度衡量標準?
回答:沒有針對不同類型的專案訂出不同的標準。原則上採行統一定義的標準,但會根據不同類型給予不同的權數或比重,尤其是對於完工的定義採行不同的百分比法。

問題二:您用的有哪些方式?優缺點?
回答:如果對於程序型的軟體開發專案就以WBS下各Package的完工進度加總後作為衡量;如果是產品客製化的專案,就以完成的交易數作為衡量的基準。
Package的完工進度加總計算優點是各負責人責任明確,回報容易;缺點就是擔心各負責人隱藏訊息。
以完成的交易數作為衡量,優點是客戶容易明瞭,而且有明確的感受;缺點就是客戶看不到的部分,如:架構、品質等工作難以反應,易造成給客戶沒有進度的感受。
但以上兩者都有一個重大的問題,就是實際進度的衡量基準與專案預估時的方法與基準不同,對後續新專案時程與成本預估的Lesson Learned幫助有限。

問題三:能反應實況嗎?
回答:應該可以反應實際狀況的百分之七十到百分之八十或九十,實際狀況要視配合同仁彼此間的合作氛圍與默契。比如就以交易數為例,有些同仁認真負責,瞭解交易的目的與重點,進度的顯示會同時真實反應品質等問題,而有些同仁的作法就有可能增加後續的修改時間。

問題四:影響進度度量的因素有那些?
回答:就軟體開發案來說,個人以為最主要的還是人的問題。
從一開始的Initial階段,參與人員的經驗是否足夠?參與人的是否明確研議招標書,審慎評估專案的風險,研議合約?對於合作的廠商與專案人員是否有正確的評估?
planning階段參與分析的規畫人員是否深入瞭解User的需求?,瞭解產品的架構?是否真實的反應哪些RFP項目是可能有困難的?進一步負責的擬定分析書與設計書?User參與人員是否全心投入?是否對於提出的需求有明確的認識?並且可以與廠商一同以完成專案目標為前提下,探討這需求是否在合約或RFP的範圍內?
Executing階段,公司主管是否認真看待本案?對於人力與資源的分配給予穩定的承諾?還是常常臨時變更指定人員?負責實作與執行的人員是否能確實研究分析人員開列的文件與要求?真實的陳報開發進度與反應問題?
Monitor時,最擔心就是怕因應公司或內部主管的想法就要求變更專案進度與文件,甚至管控方法與記錄?或者主管對專案不明瞭,對於專案的範圍、成本、進度與品質等要件有自己的看法?專案成員是否私下進行承諾?
Closing階段,比較麻煩的就是先前各階段的人員是否真得write down下符合要求的相關文件?業主與廠商參與驗收的人員是否與先前配合的人員是否一致?如果人不一樣,那要求與重點是否差異太多?

問題五:那些階段估算容易失真?為何?
回答:一般來說,比較容易失真或出現失真是在Executing階段。其次是Planning階段或所謂的需求分析階段。但是最可怕的是失真問題出現在Closing階段。
就軟體估算來說,最常發生的就是規畫之時受到不同因素的干擾,對於專案範圍或要項有意或無意的疏漏,導致Executing之時還得不斷回頭重新進行分析,更甚者還必須變更整體的架構。其次,就是配合的廠商與人員不如原先的期待,導致增加的時程或成本遠超出原先的估算,更可怕的就是加時程或成本也無法解決,必須重新更換合作廠商或人員。

問題六:有更好的建議?
回答:軟體開發的平台,在目前的環境下多不是問題,【人】還是整個專案問題的核心!是否有足夠適當的人員參與?業主與廠商間的人際互動是否良善,並真實的立基於合約的規範?
目前任何的度量方式如:EVM是用換算成金額的方式來度量,功能點是將專案交付物各要項轉成另一個所謂點數方式,是依據外顯的特性進行計算與度量。但是軟體專案不似其他土木建案或舉辦party的專案,軟體的特點在於依賴深度的人力與能力,並且一般單一軟體系統專案所交付是一個整體性的產品,各軟體組件間密切相關,難以明確快速替換。
因此,加求度量的方式不是設法強化人的約束,朝向所謂的『工程』導向,如:印度。不然就是設法改善人員的態度,如Google的人性化。期盼藉由人態度的正向改變來確實反應出度量的計算方式。
TOC理論提議了所謂『時間-金錢』計算單位,也許軟體進度度量單位可以設計一個『人性-時間-金錢』的度量單位。

2012年9月23日 星期日

專案經理的十個切忌

最近友人們在臉書上開了個社團,肥蝦想想為了維持該社團的活絡與動力,因此想說就潑個每日話題,有意願或感觸的好友就可回回留言或按個讚。其中一天,提出了男女PM的差異。在大家討論(看得很多,留言的少)中,蔡桑就說他常與男PM發生衝突,並認為女PM比較善長溝通與管理;謝小姐也說:男PM善長技術,女PM專長溝通管理。這讓肥蝦想起自己看得或寫過的一些資料,投射到個人的工作歷程,不禁想說是否男生就不擅長溝通管理嗎?

肥蝦中途轉業進入IT軟體產業,從網路工程師、程式設計師、系統分析師、專案經理這一路走來,發現到個人以往成長與工作的經驗常會影響到下一個職位的工作態度與對特定領域的涉入程度(也許就是那「彼得原理(The Peter Principle)」的成因之一)。傳統觀念上認為:男生似乎長於理工,因此對那IT技術較為專長;女生具有文史方面的優勢,因此長於與人溝通。

不管傳統觀念、亦或個人的成長背景,既然專案經理的重點在於專案管理,至少應如PMBOK 2008所述具有:知識(Knowledge)、執行能力(Performance)、個人特質(Personal)。當然如果一個PM俱備了PMBOK 20041-2 Areas of Expertise Needed by the Project Team(1) Application Area Knowledge Standards & Regulations. (2) Understanding the Project Environment. (3) General Management Knowledge & Skills. (4) Interpersonal Skills. 是很好,但是該圖已明確標示是by the Project Team。如果專案經理又兼任不同的身份,如系統分析師、架構設計師當然有對應的角色與工作,但是在執行專案經理工作與扮演對應角色一定要設法減少混雜,在對的人、事、時、地、物下,去扮演好PM角色。

對於專案經理在凝聚專案團隊與相關利害關係人達成專案目標上,肥蝦以為有幾個切忌可以供大家參考參考:

(1)切忌突顯自己:
PM的首要工作是突顯團隊成員的工作,而不是將光環都弄到自己身上!!!

(2)切忌自以為是:
也許PM出自基層,常會自以為什都懂,而去跨越了其他成員的專業。如果真得擔心,以肥蝦個人的常用作法:就只問問題!讓對方就問題提供回應。

(3)切忌老闆心態:
PM在溝通與協調,不在要求團員要服從自己!團隊要確實服從的是專案目標,因此PM的重點之一為讓大家確實瞭解專案的目標!

(4)切忌跨越界限:
PM在團隊中首要是要建立規則,但忘了自己也要遵守規則,並且要比團員更加嚴苛。

(5)切忌諉過團員:
為讓團隊成形,第一步要建立成員對PM的信任,加上一個專案型組織的PM對於專案本就應負成敗之責,怎能將過失諉於成員!

(6)切忌自我私心:
這也跟第五點一樣,重點就是讓大家能信任PM

(7)切忌縮頭畏尾:
PM應居於第一線面對相關Stakeholder的考驗與挑戰,PM的責仁在於解決問題與化解危難,只要跟專案團隊與目標有關,PM應以捨我其誰態度勇於面對!

(8)切忌荒怠行政:
很多專案的記錄與Log是專案的重要命脈,Stakeholder聯絡表,會議記錄,管控表,專案日誌等這些行政作業雖然繁鎖,但應努力踏實,不可荒怠!!

(9)切忌有失禮儀:
專案經理在於調鼎專案相關之人,事,物~~~所謂見面三分情,場面,情面,人面,應適當顧及,如專案期間佳節將至寄個卡片之類的、沒事問一下狀況,這應該作到!!!(更深的禮儀就歸業務的事!)

(10)切忌四體不動:
不要只出張嘴,多動動,多走走,多聊聊,多看看,多接觸注意整體的風向!!!

以上切忌,肥蝦以為應不分男女。肥蝦以前當助理時,有前輩指導說:要談事情就"男人喝酒,女人喝咖啡" 。雖說應對進退可用性別優勢,但也要看對方的脾味~~~比如:美女計、美食計、先小人後君子、以問代答、,但也要有技巧,並拿捏情況。當使用問答方式詢問團員或相關人,也要看對方或週遭人的臉色變化,當臉色不對,或對方已開始亂套,那就要轉移焦點了,或打哈哈圓場!如果對方是個好咖,那他()會回去思考!如果對方是個爛咖,那你()要回去想!畢竟除了(2)切忌自以為是,也要同時注意(9)切忌有失禮儀。

2012年8月5日 星期日

自我實現的"風險"


十多年前,肥蝦剛轉入金融軟體開發產業,第一個參與的較大型專案是某國營企業的信用卡系統轉置案,負責新系統的客製化功能開發。記得上線的前半年,心中總是擔心系統晚上批次作業會掛掉,針對修改的程式總是一再Review,但是半夜被叫去資訊室的機會還是常常;後續也許是系統穩定了,也許是不那麼在意了,反而半夜被call的機會變少了。

記得心理學上有一個自我實現預言(Self-fulfilling Prophecy)的理論,定義為:「the case whereby people (a) have a n expectation about what another people is like, which (b) influences how they act toward that person, which (c) causes that person to behave consistently with their original expectations.」這不禁也讓肥蝦想到那痛苦的莫菲定理(Murphy's Law)" Anything that can go wrong, will go wrong"。如果把這兩個定理合起來,好像變成肥蝦在管理專案風險時常發生的慘劇-" the case whereby people (a) have a n expectation about what a problem may be happen, which (b) influences how they act toward that problem, which (c) causes that problem to happen consistently with their original expectations."


針對風險這個名詞,雖說PMBOK或一般管理書籍把它視為中性的名詞,即表示它可能是個機會或是個危機,反正不確定性造成專案變化的都是風險。但是,可能案子作久了,再加上肥蝦杞人憂天的天性,總是先想到那不好的一面。

在進入專案之前,預估可能風險是非常重要的,尤其是可能導致專案阻礙或失敗的風險類別。肥蝦習慣上會就個人的經驗與瞭解,努力獲取所有可獲知的訊息去瞭解專案可能的風險,並找三、五個重要成員大家一起集思廣益,先看看案子可能遭遇的問題,然後再找業務來問問看這個案子。說也奇怪,業務老是想的都是那opportunities的風險;執行人員想的都是threats的風險。身為一個PM或Functional Manager一定是要平衡去考量正負兩邊的風險(問題是大老闆都喜歡只聽opportunities,搞得肥蝦在老闆面前老像隻烏鴉,在團隊同仁面前像個聒噪的喜鵲)。

接著,是再進一步確認導致風險發生的可能機率,針對高層次的風險類別,在進而探討其中的可能風險因子(risk factors),以及其間的相關性,並設定相關的警戒線。然後大家再一起來討論因應的對策,決定是否要採行先期的相關作業。也許肥蝦的方式比起PMBOK的順序與流程有些差異,這是因應肥蝦所處的窘困環境,如果有足夠的時間與相關資源,能照著PMBOK這樣一步一步來當然最好,但是在資源及時間有限的情況下,只能作些不得不的取捨。

對於threats,團隊總會想些與作些工作來避免或轉移,如斟酌合約的條款,設計適宜的架構或採行對應的開發方法。而團隊所衷心期盼的就是不要發生;但這十多年的經驗,發現要是愈縈繞在腦中,念茲在茲的問題,並且時刻警醒要避免的,還是會發生。

可能肥蝦碰到的專案環境可能不太成熟,每次問題真得發生了,當跟當初想得差不了太多,雖然會慶幸早有想到,也許也有些因應的方法,但還是多少會有些人仰馬翻的場面。更慘者,有時還像批評得像是田豐一樣剛而犯上的黑五類。這些苦境對應到了自我實現預言與莫菲定理,真讓肥蝦有時候懷疑起自己,是不是因為為了怕專案的不測,特別考量相關風險類別與因子,進而採取相對應的步驟後,才導致不想面對的問題真得就發生了!

俗話說:「傻人有傻福。」但真得可以裝傻就避過那些風險與問題嗎?是不是遮起眼睛,看不見就真得碰不到?還是時到時擔當,沒米就煮蕃薯湯?唉!尤其在跟高層說明之時,這感觸更是錐心刺骨的疼痛呀!

2012年8月1日 星期三

專案vs.營運的流程建構差異


PMBOK或一般專案管理的教科書一直告訴我們,專案有兩大特質:臨時性(temporary)、獨特性(unique)。也強調了專案(Project)與營運(Operations)的重大差別。那在達成臨時性與獨特性組織目標的專案程序,以及在match組織的宗旨、方向與目標所為一般日常營運所需的營運程序是否其間有所差別呢?


記得十多年前肥蝦剛從中正畢業去應徵7-11的大專培訓人員,結果一直沒有訊息,直到三年後突接獲7-11的通知希望我去面試,記得面試當時面試官特別說明他感謝7-11的人事部門XXX,因為當初我以碩士應徵大專培訓人員所以資格不符就未獲通知。三年前,肥蝦主導一個產品開發的專案,上司塞來了一個xxx人,老闆的理由是:「xxx不去你那,那也沒有別的地方可以去了,你就看看要如何用他吧!」


為了完成目標,不管有意無意、有知無知、有章無章,總得一步一步作來,這每一步可說就是程序,當然程序有很多的定義(可參考:http://www.sei.cmu.edu/library/assets/process-pro.pdf)。就以肥蝦的認知:在工作領域中,經由有效的組織資源,採行一定的方式,從事特定的活動,達成期望的要求,這就是所謂的程序(Process)。進一步將程序適當的串連就成為我們常碰到所謂的流程圖(Flow Chart);在IT的UML圖中分析Behavior的也有Activity、State Machine、Sequence等的Diagram;在PMBOK也有work package、Activity到Project Schedule Network Diagrams。




肥蝦就自身的經驗來看,程序與流程在專案與營運中最大的不同來自於專案獨有的特質:臨時性(temporary)、獨特性(unique)。


(一)臨時性(temporary)所導致的差異
不管原先的程序思考多麼週全,程序內容多麼詳盡,程序介面多麼明確,進出條件多麼特定,人員要求多麼確實,防呆機制多麼完備,流程的持續與定期改善,是維持流程符合並促進目標達成的不二法門。但問題點在於您是否有足夠的時間進行調整與改善,甚至挽救?專案的執行在時間上有一定的緊迫性,重新施作的成本也多半非常高昂;相對地,企業營運雖有有相關的問題,但多有在重覆施作的可能。


在於資源的取得、訓練與適用,專案也承受較大的時間壓力。專案資源的取得應設法儘早規畫,但等到要劃下去之時,常會碰到相當的阻礙。所能獲取的人員與資源經常在組織部門的分派下,少能盡如人意,就像肥蝦剛開始舉的例子,「你就看看要如何用他吧!」如果碰到願花錢的老闆可能就專案流程的特性招募特定符合的人員,不行的話也就只能將就,能練盡量練,人不能轉也就只能"路"轉囉;但是企業營運所可進行較縝密的挑選,也因為工作職務的內容與分派多有明規或暗例,企業可進行有計畫的招募與訓練。


企業為一法人,理論上是要長久經營;但是專案確有明確的結束時點,也因此讓組織高層對於專案的投資傾向於保守。不管專案或企業營運,所要達成組織的目標大都是有多元性的:市佔率、獲利率、人員流動率、成本效益比、現金流量狀況、營收比、無形的聲譽、…,這都需要整合考量,但大多而言,專案在於組織之下,決策者與資源掌握者均為組織高層,其思考觀點一定是從組織、從長遠進行思考,而非是專案性與臨時性的思維。


(二)獨特性(unique)所導致的差異
企業營運要符合整體組織的目標,因此程序內容有一定的穩定性,遇到外在環境的變化之時可以有較多的因應與應變時間,因此標準化與防呆機制可以進行較多的要求與協助;相對專案的程序,就必須需要多一點人為的判斷,尤其是關鍵路徑上的程序,更是必須小心謹慎,在風險因應流程的決策上,專案更需要有明快明確的回應與處理。


專案的A unique product, service, or result多是明確的概要載述於合約或者是Project Charter,在Scope的界定之時,專案經理的職責之一就是因應專案成本、時間、品質等限制,還有公司所要的獲利,將需求者或利害關係人的要求聚合到合約的明確條文。不同於企業宗旨與目標,尤其是乙方,這一專案目標是否要盡善盡美?是否要永無止境?答案當然是不可能的。如果在一組織中所執行的專案獨特性(unique)又真得難以整合或分享,那A unique product, service, or result的達成也許只要符合標準規範就好,作得太好也許反而會有意想不到的反效果。


(三)臨時性(temporary)加上獨特性(unique)所導致的差異
就PMBOK與專案管理的要求,Lessons Learned Documentation 可使組織後續的專案在規畫、執行與監控上有更多的參考與資源,減少更多不確定的風險,降低專案的成本。但隨著不同的專案的性質、屬性、期限等不同的差異,尤其是人跟錢的差別,很多原先的參考或工具可不能抄著來用,那反而會畫虎不成反類犬,自掘死路。因此要使用組織非強制性套用的Lessons Learned,得要審慎的停、看、聽、聞。


一般而言,在一個組織會有多個專案的情形下,組織會為了發揮最高的資源效益,並努力減少成本下,單一資源或人員可能會指派到不同的專案,身為一個專案經理依照PMBOK所指示的,專案目標應緊密的與組織目標結合。套句肥蝦最喜歡的法令條文:「…謂以營利為目的…。」如果再加上企業為了市佔不得不以紅海戰術,以及整體環境因素,一個有良心的專案經理就真得在「使用合約金額扣除公司要求利潤與管理成本的餘額資源,盡量使用組織現有的人力,設法達成符合合約條文設法緊縮解釋的明確規範,去進行專案流程與資源安排的規畫。」

2012年4月27日 星期五

2012年4月27日專案執行心情隨筆


我想我後天要來加班弄東西才行!不管怎樣,總要對得起別人跟自己!別人努力,我也得努力配合才行~~~


作專案,以前都是將目標放在規劃跟執行,很少去檢討(因為成功了就不用檢討!或者中途落跑,輪不到我來檢討!)
之前我僅負責一小塊但整個案子失敗,要來檢討,隨著負責的PM們都落跑了,只好我去跟著法律專家來溝通,實在讓自己對專案有了更多更深的體會與學習!也更瞭解法律人的思維(雖然以前當助理時也跑去補過法律~~~)


以前都沒遇到專案團隊的上上上層會出事,現在負責的案子,竟然碰到了!更讓我感受到所謂專案利害關係人是如此的龐大與緊密!


團隊是重要的!一個強人,只有自己強,那專案失敗的機會大於成功的可能!
專案團隊人人努力是達成專案目標的必要條件!但只有專案團隊人人攜手努力才是達成專案目標的必要且充分條件!


作專案就像一些人要在一定的時間內,坐在車上打移動中的指定獵物!車會動;人會晃,會累,會吵;動物會閃躲奔跑;天氣會變;打獵的器具會壞,要更換,要補充!但只要不換車,大家能彼此照應,那打中目標的機會就大大升高了!


每個人努力作事很重要,但就像我老爸以前在作沖床時跟我說的,作事要有一個"勢","勢"對了事情作起來就順了!正確性也提高了!
但大家都努力作事,忘了學"勢"!


我從立委助理轉網路工程師,轉金融應用系統開發,對很多事的看法都有些異於一直在系統開發圈圈的觀點跟看法!但我感謝我這一路走來所有與我共事與接觸過的人,真得助我良多!

2012年1月28日 星期六

檢視2011,展望2012


2012龍年的九天年假已近尾聲,【專案管理的生活思維】中的Bryan寫了一篇「新年計畫的保存期限」,真是汗顏啊!對照看著自己去年(應該說是前年)寫的「檢視今年,展望百年」個人的民國百年計畫目標,其中諸多項目均未達成,雖說方向並未偏頗,但要求的到達的水平卻有很大的差距,尤其世新在職碩班的畢業論文也多遞延了一年,遲至今日也尚未完成!

正如在「檢視今年,展望百年」文末所說的,2011年初肥蝦即任部門經理乙職;此外,更接手原由另一同事的工作,撰寫一大型專案的建議書,以及一失敗專案的法律善後作業。在工作內容與挑戰的變化下,肥蝦戰戰兢兢地試圖凝聚部門的向心力,規畫部門的中近期發展目標;另一方面也投入了諸多的心力執行大型專案的專案經理工作。想著這些天日子所閱讀【福澤諭吉自傳】中的一句話:「我認為人的志向會因為他的環境而改變。一切只靠天資,再加上教育,以及不屈不撓的毅力,不可猶豫,如此堅持到最後才能成功。」2011年的環境確實給了肥蝦很大的考驗,但相對地也賜予肥蝦不同以往的經歷,但是這毅力與堅持卻正是肥蝦個人所最欠缺的能力與特質,因此成功之路還是遙遠不可及啊!

檢視民國百年,肥蝦收獲最多的應是參加了世新傳播所開辦的【MTP中階主管才能認證課程】,以及Bryan & Joe所教授的【專案談判與溝通】。最僥倖的是邊緣地通過了中華企業資源規劃學會的BI規劃師(Business Intelligence Planner)認證考試MTP中階主管才能認證課程】上課時數共有三十五個小時,對於肥蝦的工作認知與態度有著非常深切的瞭解與幫助,省思以往個人自我認知的『管理』更是有了決然不同的體會與定義,體認到管理這一門學問惟有經由內在態度與認知的轉變,才能從種種管理理論中淬鍊出能有效作業並有自我風格的管理行為。【專案談判與溝通】則對肥蝦在與人溝通的應對進退上有著相當的啟迪,對於一向自以為是的肥蝦來說,『溝通與影響』必定是要再努力改變自我,修鍊自我的重要課程。

雖說「十有五而志於學」,但肥蝦在民國九十八年,這已近個人的不惑之年才畫下了個人的學習成長架構圖,設定了專案管理為個人終生學習成長的重要課程,並且要求在系統分析、程式與資料庫開發、網路架構、資訊安全與金融知識上要不斷追求新的成長。這兩年來,肥蝦深深感觸到外在環境激烈的成長與變化,對於自己的學習成長要求應該要能更加的明確,並且似乎應該切分出個人所立定的長期目標,以及因應工作需求的短期目標,以便於排定學習的優先順序與資源的分配。原先「檢視今年,展望百年」所設定學習課程如:微軟Dot NET框架,雲端相關開發技術,Java平台應用上,以及個資法、IFRS等,這些應該說是因應工作需求的短期學習目標。雖然這上述的每個學習項目都是既深且鉅的議題,但是在肥蝦有限的資源下,對以上課題的學習所要設定的學習目標與要求到達的水平,不得已必然將有所取捨。但是對於個人的長期學習目標上-專案管理與商業智慧-個人應該要設法不斷要求自我,並且要能持續努力付出。

『專案管理』一直是肥蝦的最愛,在去年的MTP課程中,肥蝦領略了專案管理的學習除了一般專管指標、模型的學習之外,也應強化自己在一般管理的知識,並且要設法從個人的內在去改變自己的態度與認知,尤其在溝通、說服與影響力方面,個人更應多努力加強。此外,去年在世新研讀在職課程、參與坊間研討會與閱讀資訊的書籍中,『商業智慧』這集合了專業商業知識、資料處理、統計、資料探勘等諸多學問,利用電腦科技為工具,試圖從龐大的商業資料中經由鑑別、分類、淬取、分析、推論,來協助人們訂定較佳商業決策的學門,也對肥蝦產生了莫大的吸引力,並且深刻體認到商業智慧不是就僅僅是所謂的KPI而是有著廣大深邃的內涵

網路上流傳著郭台銘先生的一句話:「經驗和知識要匹配,知識是告訴你怎麼想,經驗是告訴你怎麼判斷。」如果郭先生所說的經驗是自己或可接觸週遭人員的經驗,那麼對於這句話,就肥蝦的成長歷程來說,是較難以接受。就肥蝦自己的認知,知識是可以自我追求的,也較易自己就能掌握的;但是經驗大多時候需要有天時、地利、人和的配合。因此知識的追求必須先於經驗,況且知識也是他人的經驗,要求自己不斷累積有趣、有用的知識,當時機來到將方可藉由實例來印證、培養、鍛練與修正知識的瞭解,並歷練出真正有益處的經驗,並且作到知識與經驗間相互的驗證與成長。因此,今年肥蝦還是會投入較多的心力在延續去年專案管理工作上,除了期望專案能如合約所載要求完成外,也期望從這個案之中歷練出有用的【經驗】,獲得自我的成長。

2011年讓肥蝦更清楚的知道自己要什麼,並依此稍微修正了自己的學習成長路徑。在認清了自己的長短期學習目標下,龍年一年肥蝦所要安排的課程訓練與設定的自我要求,也應該能與個人的學習成長路徑間有著更有效率的配合。努力完成自己在職碩班的畢業論文,以及認真學習與體驗專案管理的實務,培養自我的專業經驗,是肥蝦龍年的首要目標。其次,則依據自己的資源狀況,選擇與長、短期學習目標一致的短期訓練課程與相關書籍,期能累積一貫且有效的知識方塊。

學習與成長需要動力,朋友間的互相砥礪與相互提攜對於意志薄弱的肥蝦是至為重要能源要素,感謝肥蝦周圍親友師長的鼓勵與促勉,也衷心期盼各位好友在龍年都能凡事心想皆成,事事順心,達成自我設定的成長目標!