需求分析 - 不同類型的需求

數月前曾經寫過一篇章，標題是「需求、目標和口號」，是個人很喜歡的一篇，內容簡要分辨項目中真正可以落實的「需求」，只有幾句說話的「目標」以及空喊的「口號」之間的分別。最近剛完成了一個網上課程，更加明確地介紹了不同類型的需求，很能幫助量化「需求」是否到位，本篇將抽取一些內容作分享。

課程中介紹，我們在項目中做需求收集及分析時，可以將需求分為九個類別，列出如下：

1. Business Requirement - 又可以稱為Business Need Requirement，主要用來勾劃出需要完成的項目 (WHAT)，項目的重要性 (WHY)，以及項目可如何處理業務的需要 (HOW)
2. User / Stakeholder Requirement - 主要用作延伸Business Requirement，重點勾劃項目相關持份者的需求，例如是從法規、運營、風險、財務等角度出發的需求
3. Functional Requirement - 是描述系統功能的需求文件，包括系統各功能的定義及其表現，亦描述系統與用戶之間的互動，常見的做法是透過Functional Requirement 仔細描述開發功能，協助定義項目範圍
4. Non-Functional Requirement - 通常用於描述系統運作的環境
5. Interface Requirement - 描述系統與系統之間互動的文件
6. Business Rules - 是描述具體業務邏輯的文件，也包含公式、運算、算法等，例如產品銷售的客群，有哪些客戶可以使用產品，或需要通過哪些客戶風險評估等
7. Data Requirements - 描述數據如何被儲存及用於操作的文件
8. Assumptions / Constraints - 描述系統運作背後的一些假設及限制的文件
9. Meta Information - 通用的資訊紀錄

一般情況下，以上的各項需求會由不同的部門或角色執行落實，例如Business Requirement 由Business Owner 提出，User/Stakeholder Requirement 由End-User 提出並由Business Analyst 收集分析整合，又例如Functional Requirement 通常由System Analyst 編寫等，視乎機構內的部門分工而訂。而項目團隊在機構的項目框架上，通常會進一步細化分工或按情況調整，例如有些項目團隊沒有Business Analyst 的角色時，就需要由用戶部門與IT合作落實相關需求。

為什麼項目有時會出現所謂需求太high-level，以致聽起來似乎只說了目標甚至乎像是口號，難以落實？很大程度是原於需求內容只提供了以上的某些部份，而最常見的情況是只提供了Business Requirement的一項，只說了項目的目標，但未有深化其它各項例如是User Requirement、Business Rules及Data Requirement等，以致項目在需求環節缺少了重要的元素，難於進行評估亦難於落實。

要留意一點是，項目出現需求不齊絕對不是小問題。就項目計劃方面，這種情況會造成項目難以估算開發範圍，評估的開發量很容易因為遺漏需求，而導致項目後期不斷出現Change Request，以致最終延誤項目，嚴重情況甚至可導致要重啟項目。當然更壞的情況其實是項目持續進行而根本看不見盡頭，影響團隊士氣，長期佔用項目資源亦限制了機構的其它發展計劃，為機構帶來不少損失。

明白了以上這一點，在項目初期定義需求的時候，就更需要嚴格執行需求的評審，並盡可能在項目初段時間找齊項目的持份者，如果項目一直延期的話，也應該盡快評估項目當前需求缺少的部分，盡快補足以減少對項目的後續影響。

也有人會問，是否要在所有需求都集齊才開始進入下一步開發階段，筆者個人認為是不需要，亦是不可能的。坦白說，在今時今日的科技發展，最傳統waterfall 的方法實在很難生存，也難以為時刻出現的新機遇作調整，固此，每一個機構和團隊也有必要適度引入Agile ，以便項目在出現雛型後啟動一些部件的開發，並引發其它範圍的考慮和深化。至於具體有多大程度應使用Agile，則有相當大的討論空間，日後會再整理一下思維再寫。

項目管理 - 項目估算

好幾個月沒有出新 post了，幾乎已把這裏荒廢，但這幾個月也一直沒有閒著，先是六月初和朋友吃飯時提到Web Scrape，之後花了六月和七月的時間學習和應用Python，讀取網上的財務數據進行股票分析，後來又完成了一個網上課程，當中也有教授不少關於項目管理和需求分析的要點，稍後會另文分享。

早一陣子疫情相對緩和的時候，約了一位前輩朋友食飯，席間前輩提出一個很多項目經理及管理層也會提出的問題，筆者當時嘗試作答，之後也草稿了這篇文章，不過遲遲未有時間完成，剛完成了的課程，正好提供了一些補充。

前輩提出的問題是與項目估算有關，究竟兩個不同的項目，可以如何對比其複雜程度，進而評估投放資源和項目時間的合理性。

筆者當時的回答是包括三點考慮，首先是項目開發量，其次是參與項目的團隊數量，第三是受潛在影響而需要Regression Test 的範圍。項目開發量方面，之前的另一篇文章內曾經分享過使用Function Point Analysis (FPA)的方法，用以將項目整體範圍拆細，進而分項評估。前輩就指出這個方法的盲點，在於不同項目經理或團隊，也可以有不同的估算，早年也有人做過實戰測試，找來不同項目經理就同一項目作出評估，大家就可以有截然不同的估算結果。又有人就此就提出同一項目取多個估算作平均，但實戰環境下大家也明白這根本很難做到，結果仍然是各有各估算，難於達致統一標準。

事實上，這個問題之所以難於回答，歸根究底是我們在實際環境下是極難出現兩個一樣的項目，即使例如兩間公司就同一業務目標發展，但基於不同的系統，不同的組織架構或項目團隊，以致不同的流程，還是不同的風險偏好，結果是可以很不一樣。而在同一個機構入面，就更不會同時出現兩個一樣的項目了。但這點既是原因，也是結果，正正是這樣的情況，我們更希望能夠更有效的評估和比較，以判斷投放的資源是否合理。

在最近讀的課程中，就提出了另外兩個方法，一個是PMP中也有提過的PERT estimation，另一個是Fermi Estimate。

PERT對大部份項目經理應該不會陌生，簡單來說就是就每個項目中的task 估算最好，一般和最壞情況，然後取weighted average。PERT 跟FPA 主要不同之處，是FPA將產品 (Product) 拆細成functional 組件，容易忽略項目中其它工作的時間，例如regression test。而PERT 則是從項目 (Project) 角度拆細成tasks，是較好的項目估算工具。通常第一次做項目用PERT會是比較痛苦的過程，要把所有tasks 列出清單進行估算，但當之後再用的時候，很多時會發現task 的估算是可以重用，甚至可用上次項目的實際情況作一些調整。另外，PERT estimation 亦強調項目整體團隊的參與，即團隊合作對task effort 和duration 進行估算，過程可以增加團隊對估算的commitment，亦可以預算評估可發生的風險及相應作出計劃。

另一個Fermi Estimate，相對來說不及PERT 的精準，但卻是做快速ballpark估算的一個好方法，尤其是當面對極為龐大的項目，難以把整個項目拆細至最底層進行估算，就很適合使用。Fermi Estimate 不要求把項目拆細是最底層，而是透過已知的數據對未知的整體進行大致估算。舉例說，如果我們要估算一輛私家車的闊度，我們可以大致計算是 3 個成年人(約每人20吋)，加上兩扇門的闊度(每扇6吋)，加起來就是大約72吋。而對於項目來說，我們就可以從整體項目中找尋曾經做過類似項目的組成部份構成已知的數據，對於未有數據的部份則再進一步拆細，或找尋最相近的作為比較。

以上無論是FPA，PERT還是Fermi，方法各有不同，但共通之處是都需要把項目分拆細份以方便進行估算。事實上，分拆估算除了在項目計劃時有用，就算在項目執行過程亦有相當幫助，例如可以分項評估各項task 的variance，以便在下次項目上作出調整。