2011年開春以來，可說是事務纏身，”戎馬”倥傯！除了負責原有的系統分析與產品開發，又多了個負責部門管理與對業務部門支援的工作，真得讓自己忙得手忙腳亂，更甚者四月底得標案件在諸位上級長官的”禮讓”下，被執行長指定為專案經理，因此學校的論文只得請老師與老婆大人讓肥蝦通融延後畢業，那就遑論紓發與記錄自己對學習上的心得感想。
公司這一個四月份專案的總金額雖然不小，但規模更是金額的雙倍以上，面對的利害關係人又大過規模的雙倍，在目前臺灣這一個乙方弱勢的市場型態中，執行本案已註定要遭受一定的範疇、時程與成本的風險。在長官「讓嫌」下，肥蝦擔任該案的專案經理，在專案初始階段，肥蝦就認真思考過在目前公司缺乏完整的專案管理工具，以及大多同仁對專案管理較為守舊的觀念下，如何進行本案的專案管理工作。
目前公司基本上有制式的工作雙週報，同仁填寫本週已進行與下週預計的工作項目。但在考量此次專案的特殊狀況，因應以往專案團隊的成員只單獨填寫自我自身工作項目下，如何喚起大家一同注意本案目前遭預或感覺到的問題與未來可能的風險，肥蝦就將原有的工作雙週報新增了【問題/風險】與【心得/建議】兩個欄位。為了不讓專案管理工作變相增加原有成員的負擔，原本的應填寫的預計下週工作內容就請成員不用填報，因為就專案工作項目與成員的配置表，以及下一週的工作週報，肥蝦只要動點小手腳還是可以提供出公司所要求的工作雙週報。
本篇的重點不在闡述專案成員必須配合的專案管理工作，肥蝦想說明的是專案經理自身的管控作業。當然專案經理就公司的編制來說，也是公司的員工，因此也要填寫工作週報或工時單，但是肥蝦以為這只是最基本的工作，工時單與工作週報可以配合輸入到專案管理工具作整個專案進度與成本的掌控，但是對專案的整個發展變化，思考與預防專案可能風險與問題，瞭解專案進行的整體動向，尤其是日後僅依憑繁多的專案Records、Log、Information、Documents等資料進行Lessons Learned也並不容易。因此肥蝦就每天記錄專案上的工作與發生事情，寫下專案管理日誌。
IT肥蝦 發表在 痞客邦 留言(0) 人氣(1,070)
記得大年初五在家裡跟家人聊天之時，小妹說到她先前看電視介紹胡適的節目，她覺得胡適的小腳夫人根本配不上胡適。肥蝦自己對於胡適的生平、研究與家庭實是所知甚少，除了年前看了唐德剛先生所寫的「胡適雜憶」外，家中也只有那本以前讀過「四十自述」，對於胡適的豐功偉業都是在以往的教科書中所得之。只是就夫妻相處來說，以肥蝦個人的感受是覺得外人應該沒有任何立場去評論夫妻兩人有沒有配不配的問題，因此回了一句：「說不定胡夫人剛好就是胡適生活中不可或缺的伴侶。」個人以前已讀過唐德剛先生所著的李宗仁與張學良兩人的回憶錄，也曾在【傳記文學】中看過一些唐先生的文章，對於唐先生在專業上的學養有一定的瞭解和崇敬，此「胡適雜憶」之中，唐先生以亦文亦白的文筆，亦尊重亦詼諧的態度，從胡適所言的：「哲學是他底職業，歷史是他底訓練，文學是他底娛樂。」中，評論「胡氏『中學』也止於『乾嘉』，西學亦未超過『赫胥黎』」的看法，來探討胡適先生的治學與生活態度，一路看來真得讓人興會淋漓，大呼過癮。 就肥蝦從該著作中所接觸到唐德剛先生對於史學研究的變遷；對於拉丁化語文與歷史的互動；經濟在史學中的角色；對於中西文化與中人西化的分類；「自傳」與「傳記」的界定，等論述，實是非常佩服，使肥蝦這個以歷史為生活娛樂的人有無比的收獲。個人將書中一些字句，斷章取義的整合為肥蝦目前個人所感受到「專案管理」此門學問在台灣發展境況的體認，以及個人附會穿鑿的初淺想法！IT肥蝦 發表在 痞客邦 留言(0) 人氣(187)
IT肥蝦 發表在 痞客邦 留言(0) 人氣(59)
肥蝦上任，一下子除了自己原有的專案外，還要作一些Presale的工作，過年前就這樣一直忙到了2/19，好不容易2/20有個空檔，跑去聽了金融研訓院開辦的「中小企業授信產品風險管理實務」課程。看了金研院的網站，想不到身為IT人員的我，在金研院也是花了將進一、二十萬，唉！只能怪自己的”好奇心”太重。在課堂中，老師提到了中小企業在信用評分的項目，以及事前的實勘與後續的複審之中要特別注意一些企業異常警訊及癥兆，其中在管理上的重點有著：負責人或重要主管辭職、重要主管調動反常、員工出勤情況不佳、人員離職率高、士氣低落等項。這就讓肥蝦想起前陣子，在FaceBook上也看到一個在User Side工作的年輕朋友，說她的處境艱困，委外廠商駐點的工程師每個都掛什”處長”、”經理”之類的，可能他們這些人欺負她年輕，所以壓不住陣腳，使得她公司內外遭收煎熬。另外，上週一個哥們告訴我他們公司的狀況，以及他自己也要離職。其中最大的導火線就是一個剛上任的專案經理跟公司高層報告說團隊中有老人不願跟他配合，希望能殺雞儆猴一下。我朋友可說已是該公司的創業元老，更是這新初任專案經理的指導前輩，因此我這換帖的就成了那隻雞。殺雞儆猴、陣前立威！？一個專案經理或是部門經理，當然都希望專案團隊的成員，部門內的同仁，個個都要聽命於他，以他馬首是瞻；在與公司其他部門溝通，以及與專案利害關係人的互動中，大家都只以他為窗口，只有他說了才能算數；在面對專案贊助人或公司高層，他就代表這個專案、整個部門，所有光芒都在他身上。當然，以上所寫應該是每個專案經理或部門經理所想的；但說實在的，確也是最不應該發生的！記得2009年寫過一篇「專案經理追求的修為－"Pursuing the
Perfect Project Manager"讀後感」，在Permalink這一篇文章中所載明專案經理的特質中，第一項－自我與無我(Total ego/No ego)；第二項－獨斷者/委託者(Autocrat /
Delegator)；第三項－領導者/管理者(Leader/Manager)；第八項－急迫/耐心(Impatient/Patient)的說明，特別可以說明肥蝦對於【殺雞儆猴、陣前立威】目前的想法－「有功不必在我」，才能使您達到「我在必成功」的終極目標！IT肥蝦 發表在 痞客邦 留言(0) 人氣(186)
什麼是configuration
management光就譯名，Configuration
Management這在台灣有人翻譯成建構管理、組態管理、構型管理、或稱之為型態管理；在大陸則稱為配置管理。Configuration Management這個管理作業，因為台灣專案管理環境尚未成熟使然，常常使得光看字意而缺乏實際運作經驗的人很難瞭解其中的要義，或者與version control很難界分清楚。本周的第十五章型態管理，因為焜安同學有事未能與課故由老師代打，老師在課堂直接就指出現實環境中因為軟體專案的成本與期限壓力，台灣地區甚少有軟體公司會於專案團隊中安排專門的Configuration Management人員與工具，加以Configuration Management也會增加程式開發人員開發作業的複雜度，因此一般有規模的公司也僅僅是作到版本控管(version control)。接續報告的子嵐同學因為並未實際接觸到軟體的開發與維護，因此對於此部分有著些許的陌生。幸而代興同學於銀行的資訊單位工作，無私的與大家分享了銀行在資訊系統的維護或者建構上，對於系統維護與變更的流程規定與實際經驗，其中從需求的提出到確認，以及程式變更的分析、申請、測試與上線都有著一套秩序井然的規定。說實話，肥蝦也是身處在台灣的軟體產業之中，雖然也”呆”過使用單位，但對於Configuration Management也是僅有初淺的認識，尤其是對應到PMI所出版的”Practice Standard for Project
Configuration Management”這一本內文僅有26頁，加上附錄也才共51頁的手冊，更是顯得所知有限，在此就只能以管窺天的向大家報告肥蝦的認知與心得，還請 先進們不吝指正。IT肥蝦 發表在 痞客邦 留言(0) 人氣(1,655)
風險值多少？
12月28日尚文與仕賢同學報告第十四章風險管理之時，正巧班上的一位任職於富X證券的同學，因為27日晚機房起火，正忙著幫忙處理善後，不克與課！這對風險的管理，正是一個絕佳的範例。
在書本中，對於風險的定義為：
公式一：
IT肥蝦 發表在 痞客邦 留言(0) 人氣(436)
轉眼間，秋去冬至，2010年已邁入尾聲計時，民國百年就將到來。檢視肥蝦這一年的目標達成率與成本效益比，實在是令人汗顏呀！今年一年除了養家糊口必要的工作之外，一年來擔任社區的主任委員也是耗費了不少的時間與精力，更因著自己的怠惰，使得個人設定目標的達成上，以及自我知識的充實上更是一事無成。在專案管理交流論壇上的線上讀書會的導讀只完成了一本Edward De Bono所著，吳春諭先生所譯的【在沒有問題裡找問題(Powerful Tools to Transform Your Thinking)】；在專案管理智能的學習上，只參加兩次Bryan & Joe所舉辦的workshop、PMI-TW所舉辦的「2010台北國際專案管理論壇」、熊博士的「專案經理軟技能學習」；在IT技能的學習上，也只能參加些微軟、甲骨文、優利的一些研討活動；其他一切所設定的資安、財務金融專業，以及語文的學習上，都是付之闕如，甚者更是半途而廢。今年在學習上最愉悅之事，大概是參加了Bryan & Joe舉辦的Workshop，認識了這兩位”清新”的專案管理先進，以及他倆所聚攏的一些專案管理學習的粉絲了！從他們身上，肥蝦看到了、也學到了不少的智識與經驗，尤其是不同於現今專案管理教育與顧問市場中的風格與活力，更使肥蝦有著不同的感受。他們以靈活、彈性與活潑的教法，付予了台灣地區專案管理研習課程的不同面貌；更藉由他們的部落格、臉書，宣傳了生活與工作中專案管理的應有內涵，而不是短視應付認證考試的不當態度，真得是讓肥蝦激賞不已。延續著原有Matt、Erin、小歆、Honda、信輝，五位好友的心力，一同在小歆創建的專案管理交流論壇上結識了雲翔與foolboy，一同分享與討論，更讓肥蝦深受感動。因著時境的變化，與Matt、Erin、小歆、Honda、信輝等雖不似以往般時常見面，但是定期的聚餐與臉書上的溝通，對於他們的情誼，肥蝦深深感謝！IT肥蝦 發表在 痞客邦 留言(0) 人氣(13)
昨天在床上看論文第二章文獻探討要用的英文期刊，一時煩悶下就拿了本【科學人雜誌(第105期)】來看！其中有一篇短文「失之毫釐，差以千里」，講得是統計抽樣誤差的問題，內容是說美國在調查軍中同性戀的比例，因此進行軍中同性戀的調查。這直覺看起來好像沒有問題，可是卻會導致情況為真(異性戀)但被誤認為假(同性戀)的型一誤大於情況為假(同性戀)但被誤認為真(異性戀)的型二誤高的統計問題，就是所謂的非對稱性族群數目，或稱類別資料不平衡(class-imbalanced)的問題。一時之間突然想到曾在第132號數學傳播季刊看到的一篇統計思維文章，以及同學在上資料探勘之時常會詢問的問題－「統計跟資料探勘差在哪裡？」
肥蝦不是一個專業的統計學家或者專研資料探勘的學者，因此一些想法並不一定正確，但寫此文的目的只想拋磚引玉，順便也能確認自己的思維與認知是否正確！
【數學傳播季刊】統計思維乙文的作者為黃文璋教授，任教於高雄大學應用數學系，是一個聲譽卓著、著作等身的統計專家。該文除了詳細說明統計的觀念之外，對於一些重要的概念更是旁徵博引一些文學典故，一文讀來有讓人不忍釋手之快。文章一開頭就引用了馬克吐溫的名言：「There are three kinds of lies: lies, damned lies, and statistics.」(有三種類型的謊言：謊言、可惡的謊言跟統計。)文中也說明統計能達到的作用：(1)在允許誤差下的機率保證。(2)允許誤差下的無罪推定。因此機率跟誤差是為統計學裏的兩大支柱，黃教授並根據統計學的六項要點─善用資訊、了解變異、相信機率、合理估計、無罪推定、紙上談兵─逐一說明。本文可說是字字珠璣，要肥蝦寫出心得，真得就只能把文章照抄一遍了！ IT肥蝦 發表在 痞客邦 留言(0) 人氣(235)
軟體專案委外之深思與迷思12月21日士東與玉蓮同學報告第十三章外包管理。在專業分工的現在，不管是為了書中所言的：「維持核心能力、小型化的趨勢、降低成本、爭取時效、取得新技術、解決資訊中心無法滿足的需求…」等原因，或者其他理由，一個中、大型的軟體專案，大都是業主與一些廠商共同合作來完成。在先不討論原合約甲方的立場下，對於委外合約的上包或下包角色，肥蝦都有過些許的經驗。如果是第一次與他人合作開發專案，不管是上包或下包，對於開始合作的態度與模式都需要一段時間的磨合期。尤其是跟國外的廠商合作之時，一般上這磨合期間的互動，更是相對的痛苦！就以往的經驗，上包若是基於要設法將原有組織人員進行縮減或只圖降低成本，下包商就真得不好做！記得肥蝦有次擔任委外下包的專案經理，因為原廠的合作人員聽聞公司與我們合作的企圖就是要把他們的工作以後轉包給我們，然後降低成本，可想而知這案子這專案經理做起來真得很窩囊。不管是上包有無道理，每次主管跟我去上包開會都是我被釘，都是我的錯！然後主管出來後才給我摸摸頭，做起來真得很XX。其實除了第一次的合作，不然都像肥蝦在修讀企管所的作業管理中所介紹【供應鏈】機制。而且，若主要是以風險轉移或控制為考量重點，在其他如價格、能力等能配合下，一般廠商如果要將工作委外，基本上都會先尋求以往有合作經驗的廠商。委外作業的程序，以及應該注意的要項 這裡，肥蝦想先討論一下的是委外作業的程序，以及應該注意的要項。補充的資料是PMBOK的第十二章，以及金管會下的金融檢查局九十四年所頒行的「金融機構作業委託他人處理內部作業制度及程序辦法」中有關資訊委外的部分。後續上，目前檢查局已有新版的檢查手冊，而且目前也在推出新的草案，但是都把委外分攤在各相應的手冊中，因此肥蝦就九十四年的辦法進行討論。IT肥蝦 發表在 痞客邦 留言(0) 人氣(531)
軟體專案選擇的時點,構面與決策模式
本來第十二章應該是於第十二週報告，但是因為李老師龍體微恙，因此博專與時雨同學改於上週進行第十二章軟體專案的選擇的報告。軟體專案的選擇為何落在第十二章？在介紹過了軟體開發模式、專案規劃、時程、監控、品質等章節之後？又在尚未介紹風險、委外、專案的量度與評估等章節之前呢？這倒是令肥蝦茅塞不解！專案的選擇，如果依課文所述：「任何企業的軟體部門擁有的資源均相當有限，軟體專案的選擇其成敗與否決定了整個專案的成敗，…」那麼就邏輯來說，應該在專案規畫之前就要有專案的選擇，但是選擇之前也應該要有專案的評估才能作為專案選擇的依據！因此專案的選擇應於專案流程中的何時進行？專案選擇所定義的內容與範圍為何呢？就如老師於課堂上所言：「一般實務上，能嚴謹的落實專案選擇作業，是少之要少，一般對專案經理來說，都是從拿到案子以後就才進行專案的規劃與管理，也許對於user單位來說，專案選擇就比較有機會進行！」先從Vendor單位來說，就肥蝦有限的經驗，老師講的是非常貼乎實際的現況！雖然肥蝦所待的公司有進行所謂的成本效益分析，總公司也定義了一個基本的效益比率作為專案評選的基礎，但是在這都「吃不飽」的環境之中，又有那幾家公司能真得進行專案的選擇呢？為了接案，為了生存，所謂的成本效益分析不過是徒具形式，反正就像很多業務人員常說的：「只有接不到的案子，沒有作不完的案子！」因此就算賠錢的生意也是有人搶著作！反正賠是賠公司的，要是今年沒有Revenue的話，我這位子就馬上不保了！專案進行的艱苦與挫折也是要真的做下去了才知道呀！在PMBOK的流程說明中，在Develop Project Charter中的輸入Business Case中提到了：「Business Case與相關的文件中必須以商業的角度提供必要的信息，以供決定專案是否值的投資。」「一個專案的產生可以基於以下一個或幾個原因：市場需求、組織需要、技術進步、法律要求、生態影響、社會需要。」既然在Project Charter之前就要有Business Case的資料，所以專案的選擇應該於專案核准之前就要完成必要的分析與選擇。IT肥蝦 發表在 痞客邦 留言(0) 人氣(493)
資管在職碩班課程 (2)