肥蝦的專案"瞎"日誌-預設Deny的需求收集

肥蝦花了兩天的時間，終於把近80M的原系統相關文件看完，把原系統所具有的優點與架構，東貼西補的彙整了近三十頁的資料。

想起在PMBOK的收集需求流程，其投入只寫了專案許可證與利害關係人登記簿；所用的工具與技術，主要是訪談、焦點群組、研討會、群組創造、群組決策、問券調查、觀察與雛型，這幾招。但在內部產品升級的專案中，原有產品文件與文件的檢視也是非常重要的。

在昨天終於將原系統功能與架構彙整文件寄給了John協理、阿強機器人、韓舊都、小甜業務與一把刀工程師，原本個人的如意算盤，打算是以此為基底，進行群組的會議討論，用大家聰明的腦袋勾勒出一個較為明確的需求清單。

會是開了，但效果大打折扣。原因有三：一是John協理太忙碌了沒有參加。二是兩位IT AP設計人員已有心中預設的底線。三是肥蝦主持會議的功力太差了。因此會中的討論都在角力原有的功能是不是不需要，真得很可悲！

在群組的決策技巧中有：全體同意(Unanimity)、過半數決(Majority)、多數決(Plurality)與獨裁(Dictatorship)。因為可以獨裁的人-John協理-未到；多數決是IT獲勝。因此弄得四人成三派，大家互不相讓，最後我只能提出我的建議：「大家針對有爭議的需求，寫下自己的評估看法，對自己的立場，在評估意見後加註建議方案。」

「可不可以口頭討論就好？」幾乎是異口同聲的回應肥蝦。肥蝦笑著說：「既然有些事項我們不能決定，那得請協理裁定ㄚ！而且留下決策過程的文件，不也能幫助各位去進一步思考嗎？」文件化，其實是很多IT人員的心痛。有時我也很納悶，一個人可以把程式寫的很有邏輯，但對寫文件卻是極力推拖。

阿強機器人眼見碰到難關，轉口說：「協理非常忙碌，因此不需要事事都要他決定。肥蝦你是專案的主導人，只要跟協理報告我們的作法與需求就好了！」「是ㄚ！專案一定要有一個主導人，但卻不一定由主導人作決定。」韓舊都接著說。肥蝦心裏是一陣XXOO。肥蝦只能笑著說：「由於這些是原有的功能，我想我們都不方面有任何的決定。協理的意思是要我們至少要能達到原有系統提供的功能，至於原有功能是不是良善與合適？我建議由協理來判斷。」最後，大家勉強同意試著把自己的意見與立場用筆寫下來，肥蝦真是感到欣慰。

雖然此次會議無法產生相關的需求文件(Requirements Documentation)與需求追蹤矩陣(Requirements Traceability Matrix)，但對需求管理計畫(Requirement Management Plan)算是有了一點的收獲。