IT肥蝦-經濟&科技&專案管理

轉眼到新公司已經三個月，雖然目前還是千絲萬縷，但肥蝦自認為不會是治絲益棼；雖然還有人事的紛擾，但已不會再傾軋糾紛。但想想這三個月來也沒有餘力爬部落格，總覺得少了些東西，所以把在個人臉書上有關工作上的感想整理一下，除了記錄自我外，也與各位先進們分享！
流程，範本，等級，溝通
流程，範本，等級，溝通。
這四項不就是管理的精髓！
作事情不可能沒有流程！惟有流程，才能簡化，才能不斷改善！
作記錄不可能沒有範本！惟有範本，才能週密，才能抓住重點！
作分配不可能沒有等級！惟有等級，才能完善，才能切中利弊！
作運行不可能沒有溝通！惟有溝通，才能暢通，才能取得共識！
流程就是有共識的規則！
範本就是有改善的準則！
等級就是有重點的分則！
溝通就是有利弊的合則！

在系統整合廠商任職的好友艾德華在臉書的封閉社團發佈了一個問題：「該公司因為專案人力不足，故要求各專案經理也要擔任專案之分析、設計與開發工作。」一時之間也引起大家的討論。概括言之，大家的回應主要分為兩大類：(1)不應該：一旦改變可能就變成公司的常態與文化。(2)可以：專案經理可有更多的歷練與經驗。
專案經理應不應該專職？在台灣的環境中，專案經理的角色因不同的產業與不同的公司文化而有一定的差異。在製造業或自有產品銷售的公司中，專案經理專職於負責溝通、協調與協助時程管控事宜；在系統整合或軟體開發廠商，專案經理大多還是以「校長兼撞鐘」的方式，只有少數公司有著專責的專案經理(當然是身兼多案)。

「Rock離職了，他不會再進來，你就暫時用他的位置！」肥蝦到了另一個專案的現場聽到負責該專案經理這樣說，一下子還有點訝異！一轉頭，一位技術能力頗強跟肥蝦一起進入這家公司的DBA也跑來悄悄跟我說：「我已經跟老闆說了，我預計三月底離職。」「太操了嗎？」「我對Oxxxxx的平台沒信心，就算程式都寫完了，最終也可能上不了線。」
   

在臉書的社團中，好友八樓哥提了一個問題：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 B和A1 fs-10 B嗎？
接著，八樓哥又說了以下條件：
條件1.A以及A1的開始跟B有甚麼關聯?? -> 沒關係
條件2.A以及A1的完成條件跟B又有甚麼關聯? -> 沒關係

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

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

十多年前，肥蝦剛轉入金融軟體開發產業，第一個參與的較大型專案是某國營企業的信用卡系統轉置案，負責新系統的客製化功能開發。記得上線的前半年，心中總是擔心系統晚上批次作業會掛掉，針對修改的程式總是一再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或一般專案管理的教科書一直告訴我們，專案有兩大特質：臨時性(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。

2011年開春以來，可說是事務纏身，”戎馬”倥傯！除了負責原有的系統分析與產品開發，又多了個負責部門管理與對業務部門支援的工作，真得讓自己忙得手忙腳亂，更甚者四月底得標案件在諸位上級長官的”禮讓”下，被執行長指定為專案經理，因此學校的論文只得請老師與老婆大人讓肥蝦通融延後畢業，那就遑論紓發與記錄自己對學習上的心得感想。
公司這一個四月份專案的總金額雖然不小，但規模更是金額的雙倍以上，面對的利害關係人又大過規模的雙倍，在目前臺灣這一個乙方弱勢的市場型態中，執行本案已註定要遭受一定的範疇、時程與成本的風險。在長官「讓嫌」下，肥蝦擔任該案的專案經理，在專案初始階段，肥蝦就認真思考過在目前公司缺乏完整的專案管理工具，以及大多同仁對專案管理較為守舊的觀念下，如何進行本案的專案管理工作。
目前公司基本上有制式的工作雙週報，同仁填寫本週已進行與下週預計的工作項目。但在考量此次專案的特殊狀況，因應以往專案團隊的成員只單獨填寫自我自身工作項目下，如何喚起大家一同注意本案目前遭預或感覺到的問題與未來可能的風險，肥蝦就將原有的工作雙週報新增了【問題/風險】與【心得/建議】兩個欄位。為了不讓專案管理工作變相增加原有成員的負擔，原本的應填寫的預計下週工作內容就請成員不用填報，因為就專案工作項目與成員的配置表，以及下一週的工作週報，肥蝦只要動點小手腳還是可以提供出公司所要求的工作雙週報。
本篇的重點不在闡述專案成員必須配合的專案管理工作，肥蝦想說明的是專案經理自身的管控作業。當然專案經理就公司的編制來說，也是公司的員工，因此也要填寫工作週報或工時單，但是肥蝦以為這只是最基本的工作，工時單與工作週報可以配合輸入到專案管理工具作整個專案進度與成本的掌控，但是對專案的整個發展變化，思考與預防專案可能風險與問題，瞭解專案進行的整體動向，尤其是日後僅依憑繁多的專案Records、Log、Information、Documents等資料進行Lessons Learned也並不容易。因此肥蝦就每天記錄專案上的工作與發生事情，寫下專案管理日誌。

肥蝦在【專案管理的生活思維】看到了Mia大大的專作「該如何改變(Part
2) ─TOC單一專案規劃方法」(http://www.projectup.net/blog/index.php？option=com_content&view=article&id=4027:to-what-to-change-to-part-2-toc&catid=8:pmp-pm&Itemid=18#yvComment4027)，因此也來呼應一下TOC！
 
經濟學中很多理論都引用物理學的觀念，如最有名的"彈性"，而TOC的創始人Eliyahu Moshe Goldratt正是一名物理學家！當初看到TOC理論，就覺得好親切！