項目管理 - 需求管理

應朋友提出的問題，今天寫的是關於項目管理中的需求管理。

在進行IT項目過程中有個相當common的情況，就是開發出來結果與需求不符，這個情況又可以分成幾類：
1. 需求清晰，唯開發出來的產品不符合需求，需要進行修復
2. 需求不清晰，大家對期望結果的理解不合，導致開發結果不符合需求
3. 需求實際上已經有所更改，但基於各種原因，提出需求方不承認有更改需求

在項目過程中，同時碰到以上各種情況並不出奇，本篇暫不討論面對以上情況的處理方法，先討論如何避免情況出現，尤其是在需求管理上，避免第二種情況發生。

在之前「需求、目標和口號」的篇章中有介紹過，在現實中有不少人是從根本上分不清三者的分別，這導致了不少人以為已經提出需求，而實際上只是提出了目標，或者甚至乎只是叫了幾聲口號。但很多時候項目的delay，尤其是在測試階段才發現，一直不能完成測試而導致的delay，正正就是因為需求不明確。

在需求管理上，筆者認為有幾個原則是特別重要的。

首先是落實方法。同一個需求，可以有多種實現的方案，有一些較容易，一些較難。但不論選擇甚麼方案，開發團隊除了提出方案的框架外，亦應盡可能在項目初段已列出框架內的實施細節，盡可能列出方案可見的優缺點、假設等，盡量提供多一點透明度。作為IT人，我們的目標是讓提出需求的一方也有系統的思維，明白什麼是系統可以做，什麼是系統不可以做，或者某些方案是根本上不合乎邏輯或不適合系統做。用戶能夠多明白背後的邏輯，就不會提出過份和不合乎常理的訴求。

另外，設計系統時更重要是了解並討論用戶的流程。系統和流程，就像人體的骨架和血液，兩者共存人才能夠生存。同樣地，業務的運作也需要系統和流程的配合。能夠在項目初段時更詳細討論流程，通常都能夠設計出更合乎常理的系統。常見很多人是先想系統，因為要趕schedule，但把流程放到最後，以為流程設計總可以配合到系統，這種思維現在來說已很落伍。即使是外購的罐頭軟件，也要在選擇不同軟件時考慮實則流程，以決定哪個軟件最適合現有流程，自家開發就真的不要把流程拖到最後再想了。

另外，在撰寫需求時，我們要盡可能避免寫得太虛。有時寫需求的人員總希望留一點灰色地帶，「不寫得太死」，留少少後著可以在項目後段「微調」需求。其實這種心態對項目是一點好處也沒有，太多的灰色地帶，更會惹來無限想像空間，對項目造成極大的風險。同樣地，開發團隊也不應報一個大數，以為這樣可以有機會賺多一點水份，其實這種做法也會容易給人「包生仔」的遐想，結果就很容易事與願違。

在牽涉vendor 進行開發的項目，需求管理是尤其重要，無論對外判服務一方或vendor 一方而言都是。無論是業務部門還是開發團隊，都應在分析需求時，盡量的去問問題，在評估開發量時列出合理的假設 ，並且詳細描術開發方案。報價方面，亦應該盡量按合理邏輯分開不同的component 報價，透明度高一點，就可以避免後續無盡的爭拗。人有時很奇怪，看一整份需求書或實施方案會有看漏眼，但當開發方案的內容與價錢配上，大家都會金精火眼，看看有沒有遺漏的地方。

有時反而擔心的是團隊中有能力不足的人，打算魚目混珠，故意制造模糊的地方，所以業務部門及開發團隊的項目經理都要盡量保持溝通，合力維護需求的完整性。雖然大家是不同公司，但其實大家本質也是希望項目成功，按時完成的。對外判一方，項目本身是提升業務能力，而對vendor 來說，項目成功也是一個成功案例供他們去pitch下一個項目。大家將焦點放在合力完成項目上，會對項目推進有很大幫助。