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

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

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