這幾天心中不斷地思考著要如何去界定WMONEY應用系統的範圍！其實整個專案的範圍界定最麻煩也是最困難的不在範圍的中心地區，而在如何界定範圍的邊界！WMONEY應用系統為自原有產品進行升級，因此基本的交易自是不可免除，也不會招致爭議。但是如何界定邊界就是明確標明排除條款，講明什麼東西是未來系統不提供的，這就非常棘手！
小甜業務多年來實地接觸客戶，難免的會將一些客戶的"wants"想趁此次的升級加入未來的系統之中。而此次計劃可能採用微軟dotNet的新架構，一把刀工程師也是磨刀霍霍，想趁此次一顯身手，對於一些的作法與整體架構提出他的看法。而當初的收集需求產生的requirements documentation，是在阿強機器人與韓舊都的把持之下產生，此次韓舊都病倒送醫至今未醒，小甜業務也希望能回頭修改requirements documentation。但是肥蝦知道此時回頭再翻版可能引起更多的麻煩與誤會，只得跟小甜業務口頭敷衍的說：「因為requirements documentation已送呈給John協理了，現在此刻，如果沒有重大的理由，不太適合再從頭去修改requirements documentation，可否先討論WMONEY的範圍後再來重新檢視！」
今天討論一開始，肥蝦首先表明：「此次範圍界定的會議我們將依據三月二十八日的會議記錄，逐條的對requirements documentation的需求要件討論！」開會的時候先界定一些規則是很重要的，以免會議偏離了主題或落入意氣之爭的窘境。
經過四小時的討論會議，初步的產生了WMONEY的專案範圍說明文件(Project Scope Statement)。在會議的討論中有兩點肥蝦認為可以寫出來分享給大家的。
(一)功能要求－專案範圍的排除(Project Exclusions)
原系統的功能這部份比較沒有爭議，因為基本上都必須保留。另外對於權限的控管與作業流程的方式上，大家也同意以現有方式為基準。最重要的癥結在小甜業務提到了：「我們客戶常常反應我們目前的系統提供的訊息廣播服務沒有提供編、審、放、移除的權限管理功能，只能單純的把訊息與發佈對象或群組打上去，不符合客戶現有的內控規章，因此希望把權限控管與作業流程功能加入訊息廣播服務。」馬上阿強機器人就提出異議：「我們是交易作業系統(TPS)耶！如果客戶需要這個服務應該去買另外的系統嘛！」其實肥蝦也是限入兩難的境地！因為訊息廣播的功能服務是現有的，可是要作到訊息廣播的作業流程管，可不是如此容易地！加以目前的權限管控是以交易為基礎，並不會再根據交易的內容分類進行管控；而且以肥蝦先前的經驗，這部份將來會因為每個客戶內部作業規章的不同會有不同的修改。因此肥蝦趕緊出面說：「我們在此次的會議記錄先寫下小甜業務的提議，因為正如阿強機器人所說的我們是交易作業系統，因為我們可能要採用新的架構，升級原有的功能服務的風險已經很大了，而且我們採用的是開放的系統架構，也許將來可以開發新的模組的達成小甜業務的建議，但是此次我建議先不考慮在這一次的專案範圍內。」
在PMBOK的Project Scope Statement要項內有特別標明需要列出Project Exclusions，這一部份在如上述"wants"是處於模糊地帶時是非常困難界定的，這就要憑藉一些經驗與知識進行判斷了！
(二)連結資料庫的方式與那個資料庫比較好？－選擇方案的確認(Alternative Identification與Project Assumptions)。
因為原有系統會連結微軟資料庫(MS SQL)，小甜業務說：「微軟的資料庫要成本，有時後客戶會希望我們用自由軟體如MySQL，以減低報價。」阿強機器人可是微軟的擁護派，馬上接著反對：「MySQL如果發生問題怎麼辦？而且用MS SQL已經那麼久了現有的functions都是現成的，不應該換成MySQL。」沒想到平常冷若冰霜、沉默不語的一把刀工程師突然說話：「聽說微軟現在有一種LINQ的技術，可以作到更換不同的資料庫只要變更設定並不需要修改原有程式與語法。」肥蝦心中歡喜著：「我想小甜業務與一把刀工程師所說的，也許我們可以先把它當成此次專案假設(Project Assumptions)，但我想首先要去釐清LINQ的確實功能，如果LINQ真得work那我們就可以不管資料庫的種類了！不過這部份可否請一把刀再去詳細瞭解，我們就先列在專案範圍文件內。
其實很多時後一些選擇方案的採行與專案的假設有緊密的關聯。我們會選擇特定的一個方案通常是基於某些認知或假設，一旦我們選擇了該方案，就應特別列註其所使用的認知或假設，以便去檢測，管理專案的風險。
會議之後，肥蝦得專心整理一下會議記錄，並寫出WMONEY應用系統專案範圍文件。以便進行分割與定義工作包(Work Package)的討論了！
沒有留言:
張貼留言