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

讀「百年招牌靠「數據」絕處逢生！《金融時報》發現獲利桃花源！」有感
昨天(2013年4月18日)肥蝦在臉書上看到朋友分享了一篇WIRED.tw的新聞「百年招牌靠「數據」絕處逢生！《金融時報》發現獲利桃花源！」(http://wired.tw/2013/04/18/financial-timesdata/index.html)

「我們採用Agile開發流程，使用雲端軟體Atlassian confluence、Jira作專案管理與問題的追蹤；用Sourcetree、Bitbucket作版本管控；並考量未來每天千萬次的連線請求與後續資料探勘的運用，使用了SPDY與HAProxy…」一天擔任專案經理的好朋友跑來跟肥蝦說：「他們家的RD團隊要離職了！」肥蝦兩肋插刀的跑去聽朋友公司的交接說明。
 
看到對方RD團隊作了那麼多版本與專案管理的作業，並考量後續的發展，如此煞費苦心、深謀遠慮的作了那麼多預先工作，肥蝦不禁深感佩服！但聽到程式架構與資料庫結構，一下就傻眼了！肥蝦疑惑地問：「資料庫全部十幾個表格，那…表格是作什麼用的？系統有些類別是何用途？」準備離職且異常年輕的技術總監說：「因為很多歷史因素，所以有些程式與表格用不到，但因為時間與工作優先順序安排的關係，所以沒有刪除與修正。」那肥蝦又問說：「請問有沒有作業流程圖或使用案例之類的文件？」技術總監說：「我們完全從系統技術的角度來思考！」肥蝦是不敢直接問說：「目前該系統的開發只有兩位成員，系統尚未成熟到產品的地步，而PM也才一位，這那麼多工具會不會花了太多的功夫？」
 

最近網路上有一段影片【What most schools don't teach】(http://www.youtube.com/watch?feature=player_embedded&v=nKIu9yen5nc)，是code.org放上去的，在肥蝦觀看此片時的點閱率已有一千萬人次。該影片在強調Coding是一個可以促進社會與個人最好生活的方式，希望大家都能學習程式開發的思維與程序。

【創造雙贏的溝通表達魅力】課後心得分享
    「分享就是力量！」2013年3月21晚上，王介安老師的這一句話深深地憾動著肥蝦的心。肥蝦先前並未上過王老師的課程，對於他如此精湛的”口技”與神態的教學深感佩服，上課過程中更是笑聲不斷，經由大家反思自己切身言語的問題中體會溝通與表達的語氣、語詞與語意竟是如此重要與必要。

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

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

思考的源起
「為什麼花了那麼多錢引進資料探勘工具，但是產生的報表不能反應出現在市場的變化？並且因應市場的改變而產生新的報表？」朋友提出她老闆的疑問。加上肥蝦以往參與銀行業務應用系統的開發，在配合業主資料倉儲系統要求，客製化產出所需資料之時產生的疑問：「被要求匯入的資料已經在原有系統的報表中，並且更為完整與正確，為何還要再匯入別的系統？針對同一業務要求的資料，原有系統當初使用者的定義使用資料欄位與被要求匯入資料倉儲的資料欄位並不相同，如果出現誤差，使用者要以哪一份為準？」
因著以上的親身經歷，引發了肥蝦想進一步探討：
(1)可否從原有系統的資訊中產生資料倉儲系統建構的參考，

時程壓縮的討論
一般專案管理的書籍中對於壓縮時程通常有著趕工(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%

「蔡桑，我們也合作那麼久了，就不要因為XXX專案經理的無能與無知影響到您跟這個案子…」在這【303 經理人的溝通方法學】的模擬案例中，肥蝦用這博感情的方式試圖去與SA溝通，嘗試解決因為PM與SA無法合作導致專案的困境。

除夕當天下午三點肥蝦竟然有了個半日閒，就跑去誠品忠誠店逛逛，好久沒有這樣一個人可以獨自享受這書香的氣味與優閒。這三個小時的時間肥蝦買了三本書：「伊莉莎白」、「囚犯的兩難」、「偉大經濟學家薩繆森」。
 
其中這「囚犯的兩難」這一個有名的賽局理論範例，記得在大學唸經濟學中老師也有特別說明；雖說在研究所，肥蝦則因自認數學基礎不夠不敢修讀，但同學間私下也多少討論了一下；出社會後也買了些社科讀物，初淺進行些閱讀與瞭解。