思考的源起
「為什麼花了那麼多錢引進資料探勘工具，但是產生的報表不能反應出現在市場的變化？並且因應市場的改變而產生新的報表？」朋友提出她老闆的疑問。加上肥蝦以往參與銀行業務應用系統的開發，在配合業主資料倉儲系統要求，客製化產出所需資料之時產生的疑問：「被要求匯入的資料已經在原有系統的報表中，並且更為完整與正確，為何還要再匯入別的系統？針對同一業務要求的資料，原有系統當初使用者的定義使用資料欄位與被要求匯入資料倉儲的資料欄位並不相同，如果出現誤差，使用者要以哪一份為準？」
因著以上的親身經歷，引發了肥蝦想進一步探討：
(1)
可否從原有系統的資訊中產生資料倉儲系統建構的參考，IT肥蝦 發表在 痞客邦 留言(0) 人氣(328)
時程壓縮的討論
一般專案管理的書籍中對於壓縮時程通常有著趕工(Crashing)與同步跟進(Fast-Tracking)兩種作法。在作業管理書本中，對於時程壓縮的考量，僅僅單純強調趕工的直接成本與間接成本間的比較，針對關鍵要徑上的工作項目，經由比較趕工所增加的加班成本與縮短專案期限的間接成本，而決定是否採取趕工的策略。但是因為資訊軟體專案，因為建構專案所需的資訊工具技術日新月異；專案需求所依賴的作業流程因應不同產業、不同公司而異；專案的品質除了操作上的可信度與有效度，對於近來日益重視的資訊安全與個人資料保護等議題更有著嚴謹的要求。【表 一】1994-2009年資訊科技專案結案狀態，為依據CHAOS Report 2009調查資訊專案的開發結果，專案在超時、或縮減範圍、或降低品質下，完成的比率，以及完全無法交付專案產出的比率合計高達七成。
【表 一】1994-2009年資訊科技專案結案狀態
狀態分類
|
1994
|
1996
|
1998
|
2000
|
2002
|
2004
|
2006
|
2009
|
Successful
|
16%
|
27%
|
26%
|
28%
|
34%
|
29%
|
35%
|
32%
|
Challenged
|
53%
|
33%
|
46%
|
49%
|
51%
|
53%
|
46%
|
44%
|
Failed
|
31%
|
40%
|
28%
|
23%
|
15%
|
18%
|
19%
|
24%
|
IT肥蝦 發表在 痞客邦 留言(0) 人氣(1,036)
十月底，肥蝦報名了學校傳管所
吳美娥老師所開設的MTP課程，從十一月二十日起，連續五個週日到校上課八個小時。每次上完MTP課程後回到家總是累得晚上呼呼大睡，上整天課使得身體勞累？
”不”，這八小時課程對於從事IT整合工作的我豈能造成負擔！而是心累跟腦袋累。「作事要用科學的方法，帶人要以啟發激勵的方式。」老師這句話不斷地在腦袋裏盤旋，不斷回想自己在職場、在生涯上過往的種種；努力思考自己在工作、在生活上未來的走向，讓自己腦袋一直轉個不停，真得好”累”。
MTP課程主要區分為「管理的基礎(4)」、「變革的管理(2)」、「管理的流程(4)」、「培育與發展(2)」、「信賴關係的形成(3)」、「良好管理的推展(2)」。
IT肥蝦 發表在 痞客邦 留言(0) 人氣(2,935)
什麼是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)
昨天在床上看論文第二章文獻探討要用的英文期刊，一時煩悶下就拿了本【科學人雜誌(第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)
Organizational Structure and Project 第八組三位同學分別報告了【軟體專案管理】的第十章 專案組織與團隊運作與第十一章 軟體人力資源管理，雖然負責的範圍遠大於其他的分組，但是報告的書本與期刊內容卻是一樣完整與精彩。說實在的，肥蝦對於專案管理中的人力資源管理與溝通管理向來較為weakness，當然一方面因為自己對於人資管理較為缺乏興趣；另一方面也是肥蝦的主觀意識過於強烈，對於傾聽他人的發言與意見，會因為自我的主觀意見與認知，直接給予對方相當直接的反應，也是肥蝦一直被批評為太”機車”的原因之一。(另一個重要原因是肥蝦對於文件的要求較坊間的”陋俗”多一些！) IT肥蝦 發表在 痞客邦 留言(0) 人氣(158)
品質規劃(Quality
Planning)、品質保證(Quality Assurance)與品質控制(Quality Control)在台灣的工作環境中，除非有一定規模或一定制度的公司，遵循一定的品質作業規則，不然很難體會軟體專案中品質管理的程序與作業。最最簡單的一個問句：「您們工作團隊，是否有程式撰寫作業準則或者變數編碼規則？」這也是國珍與東豪同學對於軟體專案品質管理的疑問？我們是否真正的重視與落實品質管理？還是它只是一個空頭的名詞，以讓公司可向客戶多爭取點專案的經費？【軟體專案管理】書本上將軟體品質定義為：軟體產品整體的功能和特性滿足既定需求的能力。更白話一點的說，就像日本的Mint(經營情報研究會)所著，周明憲所譯的【軟體工程實務】所寫的：「(1)正確的運作。(2)不會當機。(3)容易使用。(4)回應快速。(5)易於維護。(6)易於移轉。」這些要求可概括的區分為功能性與非功能性的要求；就過程而言，就如Deutach與Willis(1988)所分別的程序品質(Process Quality)與產品品質(Product Quality)。目前，對於專案一般認知的”triple
constraint” - scope, schedule, cost，目前很多的討論與研究中已經把”quality”或”performance”抽離出來成為第四個constraint。就肥蝦的觀點，原本的專案管理三角形(Project Management Triangle)，可以畫成下圖：
IT肥蝦 發表在 痞客邦 留言(0) 人氣(1,600)
資管在職碩班課程 (2)