Agile 方式項目管理名不符實？

面對新一代的技術發展，各行各業都在經歷不同程度的轉型變化。不少公司在進行數字化轉型的過程中，均會嘗試引入各種更為敏捷的方法，代替傳統 waterfall 的項目管理，希望讓項目執行變得更快捷。但在不少的實踐上，也預到不少難題。

例如在早些年不少公司嘗試引入Agile，就有不少意見認為，Agile 的理論只適合完成能自成一角，沒有與周邊系統有太多關連的系統開發項目，當中較多人認為可行的包括前端應用，或是最後端的報表，但一談到中層的product system，尤其是以前在mainframe 上建的那些legacy，就很少人認同可透過agile 方式推動項目。

Agile 在前端系統或末端報表較容易成功，在中層legacy system 則很難推動，有人把這歸咎於系統技術的分別，尤其是legacy system 很多時由較為年長的一輩維護，未必容易接受新思維。有人則認為是中層系統對接大量周邊系統，難以推動Agile。個人對前者說法甚有保留，並認為真正的原因肯定不在於技術人員或歸類為前端後端。是否能推動Agile，更多的是在於團隊是否具有產品思維，以及團隊有多大程度做到self-sufficient。

對於近年不少公司加大投入資源開發網上電子平台，項目就是從零到一把電子平台這個「產品」建立起來。在這個初始階段，項目管理和產品管理表面上看似沒有很大不同，都是希望用最短的時間，把產品最必要的功能在第一階段做出來，只不過用waterfall 的人會開宗明義把這個叫Project Phase 1，而有些公司聲稱自己在用agile 的，就稱這個是MVP。

很多初次試驗Agile的團隊容易在這裏踏入誤區，以為只要把一個項目分開成幾個phase，第一個叫MVP，試着做些stand-up meeting，或兩個星期做一次review進度，定義下兩個星期工作範圍，就等於是在用Agile。有些機構甚至以為這樣就已具備Agile 的能力，準備廣泛推廣，結果大多都以失敗告終。箇中的原因，正是這種所謂行Agile 的模式，只不過是waterfall 的一次重新包裝，把一個大瀑布變成了很多個小瀑布。這樣不但毋助解決waterfall 的問題，反而讓問題變得更糾結複雜。

要知道，Agile 的核心理念，肯定不是那些儀式上的事，或限制團隊會議多少人參加，最重要是adaptive，不要求一次性投產所有features，也不着重第一次做出來就完全正確，反而是透過小規模形式的持續投產，對產品進行持續優化。而這裏的投產是必要的，如果只是把元件開發了出來，或放在UAT等待測試，實際上是難以有效獲取生產環境的真實數據。

透過持續投產及建立持續反饋改錯的機制，團隊可以在產品發展過程中不斷優化改進，這種模式的運作，背後正正需要較為長遠的產品管理思維，一方面整體規劃產品的長遠發展路徑，另一方面在實際操作上不斷改進適應市場需求。更重要是，應用產品思維，定位產品目標和量度成效的標準，並按客戶價值訂立項目開發項的優先序，把資源聚焦在產品最有價值的發展上。

對於用Agile 思維做開發的團隊，如果能夠明白Adaptive 的意思，就能了解定義MVP 範圍其實是一個偽命題。真正要關注的，應該是thin slicing 做的有多充份，是否已真正界定出最逼切做的feature，團隊是否保持專注於最有價值的事項上。MVP 並不一定要在一開始就落實確定，更重要是在過程中，團隊透過不斷學習，定義出達致什麼標準才將產品第一版推出市場。

（註：讓筆者記起的是，數年前見過有團隊在行Agile 的時候弄了個MMVP 出來（即mini-MVP），也可謂相當創新。團隊一方面為了盡快上線，訂立了MVP的範圍，但在過程中亦發現，部份原先定義為MVP的features，也不是必須的，故此MMVP 才是後來判斷為真正必須的範圍。）

本着背靠產品思維的Agile 運作，即使是在出名監管嚴厲的金融業，在風險可控的情況下，例如是過程中加入適當程度的過程檢測，以上描述的方式亦都適用。產品團隊站於一致的目光思路，就能具體分辨出產品哪些元素屬於重要，哪些屬於相對不重要，哪些是真正投產必要，並且按統一價值定位進行有效排序，優先實現最有價值的backlog 並進行持續優化。

不過話雖如此，Agile 即使在真正具產品思維的團隊上實際操作，也還是預到不少困難，尤其是在現今世界，大多傳統企業都以功能對齊 (functional align)，部門各自管理，並且各自有自己的專業所長。在這種按功能對齊的企業，團隊除核心成員外還有大量利益相關者，各自站於自身功能立場上出發，這樣的設定下要去對齊產品目標願景，行動力一定大打折扣。

就以金融業為例，行內就經常有說法指金融業難以推行Agile。箇中原因，是對不少產品團隊而言，監管合規要求就是屬於合規部門的工作，也是一個並非自己本業的專業知識（當然筆者並不認為是這樣）。這種傳統上的思維模式，導致產品團隊對監管合規要求缺少基礎知識，亦未能在項目初段已能基本評估產品必要配合的合規安全要求，並定義出優先序。結果很多時是要等到項目大致完成UAT後，才通過內部或外部第三方審計獲知相關要求，導致大失預算，或最終要走回waterfall 的老路，即透過項目形式集齊項目的利益相關者，然後在既定時間內完成項目，並且一整批投產。

只是，多年的實驗基本上已可證明，在waterfall的世界，強調的是一次性做好，認為犯錯會造成re-work 浪費，但卻花費長時間進行計劃，最終在大量假設不符的時候，跌入不斷重覆的re-plan 上，最終不斷出現無限delay，產品即使最後成功投產，也沒有實現預期的value。

故此，筆者認為Agile在新世代仍是一個必要的轉型思路，關鍵是在於團隊的產品思維，持續交付價值，及在過程中不斷試錯改錯。對產品團隊而言，self-sufficient 也絕對是一個重要的指標，這還很視乎管理層是否相信這種模式，企業整體是否能下大決心重組轉型。

當然，要想一步到位轉型成為Agile，對很多企業而言都是難以踏出第一步的，或者只會是個別項目團隊在形式上進行一些小規模的轉變，難以廣泛推廣。對於一些正在踏出轉型的企業，傳統waterfall 式的項目管理辦法，還是有其重要地位，至少可在機構內未完全轉型的過程中發揮作用。而且，即使是對於產品團隊而言，真正落地做的時候還是需要以項目形式推出各個已排序的features的，分別只是把項目變得更少更容易管理，可預測性更高而已，所以傳統項目經理也確實不應擔心傳統waterfall 會因此沒有出路。

而對很多企業而言，進行Agile 轉型本身也是一件很Adaptive 的事情，甚至乎我們是應該可以把產品思維的轉型看成它本身就是一種產品，不是一步到位，而是需要按企業內部用戶實際情況而調整策略，選擇最大價值的優先推廣，這也是很多企業除了選擇某些項目行Agile，還會建立所謂Agile CoE 的原因。

新一代項目管理

近月在朋友介紹下，非常有幸閱讀了曾參與撰寫敏捷宣言的 Jim Highsmith 的著作，書名是【EDGE: Value-Driven Digital Transformation】。作者曾經參與協助無數企業的數字化轉型，並且把經驗結集成書，希望推廣相關理論能夠協助更多企業，當中不少建議甚為落地，也確實是經驗之談。

當前，全球各行各業甚至包括政府機關及非牟利團體，在科技發展成熟的基礎和助力下，都正在進行不同程度的數字化轉型，整個世界正經歷着百年來未見的深刻變化。而在疫情出現之後，相關的變化更加快速，不少企業更面對不轉型即面臨滅頂的危機。

以往，當談到要為企業機構帶來改變，一般也會以項目作為工具載體，把改變的目標，改變的範圍，納入以項目形式推動，一方面可以有效評估項目範圍及周邊影響，二方面可按項目範圍評估資源所需及規劃時間線，循序落實推動改變，對此筆者在以往篇章已有不少介紹。

在傳統的項目管理上，組織着重項目的目標、範圍、功能點、時間、開發成本等，項目與項目之間則透過上層的program 或portfolio 關連管理。這種模式的運作，在以往相對長的時間廣泛為企業採納，建立了很多應用框架（如PMP, PRINCE2），過去算是行之有效。但面對新一輪的數字化浪潮，傳統的項目管理方式也遇到了不少挑戰。固化的流程，不能因時制宜，過份着重是否按時完成或完成多少功能點，而非着重於項目產出價值；過長的項目周期，過程中亦不歡迎改動，難以適應市場變化，都讓傳統項目管理方式面對不少批評。即使是早幾年不少企業提出引入Agile，當去到要全局規模化應用時，很多時亦走不出最終着重跟流程的困局，sprint planning 或 daily stand-up 等都變成形式主義。在此情況下，企業更需要用新的方法帶動改變。

作者在書中介紹的，是一種基於價值而驅動的數字化轉型，無論是哪個行業，都可以根據自身業務性質，進行價值定位，並基於此價值及一系列思維和實際操作上的改變進行轉型。

一是建立以價值為主導的排序機制。一般企業都會遇到有太多計劃想做，而又沒有足夠資源的情況，傳統方法是透過成本效益 (ROI) 進行計算，但這種方法需要大量數據輸入，最終因數據根本上難以精準，即使花費不少時間收集，最終仍需建基於不少假設，而且在不少情況下，價值亦難以多維量化，導致不少企業最終逃不出變成是表面科學化實則是領導說了算的排序方式，亦經常出現組織內互相爭奪資源的情況。

新型以價值為主導的模式，是透過建立機構上下統一的價值觀，建立由整體戰略願景到具體目標再到倡議計劃和專題的可視關連及統一排序標準，並透過定期進行的Value Realization 檢討，讓機構上下對齊投資方向，並讓資源集中投放到合乎目標及最能體現價值的計劃上。

書中介紹的排序方式，主要是透過相對優先級排序，依賴執行團隊對價值高低而作出的判斷，不講求標準化或表面上看似精準的數字公式計算出absolute value，更講求快捷及適應，並且從不斷嘗試中獲取經驗持續優化團隊的判斷能力，是較為人性化及實務的做法。而在各條線團隊之上，則透過對不同團隊進行適當投資，控制「注碼」，確保整個機構不會過量啟動新項目，讓資源集中在重點業務上。

二是建立產品思維 (Product Mindset) 。傳統項目管理思維較着重項目如期完成指定目標範圍，不歡迎項目過程中一切與原定計劃不同的改變（不論是範圍，時間或人手）。坦白說，這種做法在新型的世界是較難生存的，一方面市場訊息萬變，新機遇時有出現，而這種做法的壞處，是即使項目團隊中發現更有價值的initiative，也可能迫於要趕及時間完成計劃內的事，有價值的也要放到phase 2 才做。在一些機構還為項目設定了cost variance 及schedule variance 等KPI，就會更易出現這種情況。

另一方面，項目按範圍訂立明確的開始和結束日期，並以暫時性形式出現，也會變相鼓勵項目團隊採用可能犧牲長遠考慮的短期方案以能在限期內完成項目，無形中製造不少tech debt。而且基於項目的暫時特性，完成項目還需要伴隨不少向BAU 團隊進行的交接和Knowledge Transfer (KT) 工作，這時候就更有機會把問題留給了後人。

產品思維跟項目管理思維最大的不同，在於產品思維更着重產品的長遠和持續發展。一般而言，產品思維會較傾向着重整體的發展路徑，較少着重單個項目是否如期完成及是否完成所有原定範圍，着重價值結果而非完成多少功能點，對於回應市場或業務改變也更具適應性。同時，具有產品思維及營運模式的機構，一般都會建立較為長期存在的產品團隊，有時按業務需要，更可能會建立跨職能團隊，自身包括產品設計，用戶體驗，流程設計，技術開發等技能。這樣，無論是phase 1 還是BAU 都是同一個團隊，可鼓勵團隊以產品長遠發展思路進行決策，將有助平衡短期利益和長期目標。

而回應以上第一點，產品團隊一般亦需獲賦權規劃決策產品發展路徑。這樣的產品團隊對產品發展具有很大程度的自主權，並為產品負責。這樣的團隊適合由具有自主思維的人擔任，團隊可以通過持續優化，對外不斷收集用戶反饋，持續提升產品質素，對內則不斷優化操作及決策，建立對產品的專業性，並為產品創造價值。

要特別一提的是，推動產品思維的轉變並不是代表完全取代項目管理，反之，項目管理在落實專案上仍然有其重要地位，並且更適合應用在拆細後的短周期項目上，詳細會在另一篇文章上描述。

從《Error 自肥企画》看新世代項目管理

踏入2021年5月，娛樂圈最紅熱話，相信除了Mirror 開演唱會，應該要到《Error 自肥企画》了。

在互聯網媒體的出現和廣泛流行下，現在真的已經甚少看電視節目，會看的通常也是用App看重溫，但今次卻是"Live" 看了一次電視綜藝節目。看《自肥企画》，欣賞的除了是Error的賣力演出，更欣賞制作團隊善用資源和創意，創造價值的能力，正正符合新世代項目管理的必備條件。

無疑，制作《自肥企画》絕對是一個項目。制作範圍為15集的節目 (Scope)，有限的制作時間 (Schedule)，有限的Budget和團隊人力資源 (Resources)，即要面對傳統項目管理的所謂鐵三角，互為制限。制作團隊自稱為「無制限OT編集団」，可能也是有這個願景，努力尋求突破限制。

欣賞制作團隊有很多原因，以創意突破資源限制絕對是一大原因。一般人會簡單以為，要想項目團隊做得更好，只要給多點資源 (Budget) 就行，例如網上也有不少留言會想李澤楷給多點預算ViuTV，或想金生、魯生給預算給制作組。但現實是，無論身處任何一個企業，資源有限本身是必然存在，就算不計營運成本或要向股東交代，企業本身每天也會有不同的機會出現，需要向不同項目押注。如果把預算過份投入單一項目，結果反而會是拖累其它項目的機會，不利企業整體發展。

面對資源限制，團隊並沒有因此退縮，反而努力善用獲分配資源，以創意 (或OT?) 搭救，「死亡恆星」就是一例，創意及視覺效果十足，卻肯定是低成本投入。反觀一些在社會工作十多年，卻已習慣使用傳統項目管理工具的團隊，一遇到資源瓶頸，立即就以此作為原因Cut Scope，或者拖長項目時間，或者以「等、靠、要」的思維，set 個task dependency 在自己不能控制的地方以求開脫，處處為項目設限。究竟這些是真正的依賴，還是給自己不能做得更好的理由，值得每個項目團隊反思。

另一點欣賞團隊，是團隊發現及創造價值的能力。真正的價值不容易被發現，尤其是在工業革命後，明明技術能力上未有條件收集足夠的數據，卻又勉強想用共通指標為各種不同的業務評價，造成了很多膚淺的數字比較遊戲，或設定沒有實際意義的KPI，而社會卻已普遍接納這種生態。不說學校教育中求學是求分數，社會上KOL 也是求Like 數 (或follower 數)，投資習慣用公司股價去評判公司價值，企業內部也用ROI 看業務是否值得投資，因此而埋沒了不少機遇。

在同一個可說是十分荒謬的計分制度下，《自肥企画》要面對收視壓力是必然的，但團隊憑藉想造好節目的信念，開僻新的路徑，線上線下的宣傳攻勢，吸引香港觀眾重新追看電視節目，並且加入討論，正正也是新世代項目管理或產品策略中所強調的反饋迴路 (Feedback Loop)。觀眾欣賞節目，社交媒體上的討論，希望參與其中讓節目變得更好，喝啤酒會想喝藍妹，食薯片會想食熱浪，主持人的人氣提升，團隊的工作能力得到讚賞，吸引更多廣告客戶，這些能不能用舊有的計分標準去評價？當然可以，但肯定不足，技術上也收集不到足夠的數據可進行比較。但不管現時收視點的計算是否仍然有效，節目是否已達完美，毋需置疑的是，公司管理層一定會對團隊有信心，願意投資在團隊下次的節目/項目上。

能夠有下個phase，代表團隊可以有進一步發展的機會，這在任何時代的世界都很重要。新世代的項目管理思維，除要求項目在一般情況下遵照一些規條(如不要隨便加Scope，或要在預算內完成計劃)，更需要團隊有長線發展的產品思維，那即便項目過程中發現有些願景不能在一時間實現，也可望在條件成熟機會出現時再發展。例如「掘洞」的整人環節，原來是3年前已經有的想法，但當時項目擁有的資源不容許該想法付諸實行，到今次在《自肥企画》中以「鳳凰不死鳥」的包裝出現，對觀眾來說肯定是一個驚喜，「笑到停唔倒」。

以產品思維作為項目管理的核心，也可以幫助項目團隊進行決策，度過一些難關。例如在項目過程中，如何選擇在同樣的資源和時間限制下，採納優先處理最有價值的需求 (炸生bear?) 或解決哪些問題，並且隨機應變。反觀傳統的項目管理，明明知道現實世界是充滿變數，也持續會有新的機遇出現，卻仍然妄想項目可以預先制定周詳計劃，寧願花費龐大時間進行規劃，然後一切按計劃進行，並且在中途禁止作出任何改變，或一有改變即延長項目時間。這樣的項目管理模式，項目一定也是可以做完的，也可交付原計劃中的deliverables，是否在預算時間和budget下交付則是另一回事，最後交付的也不一定還有價值。

在節目最終回中，制作團隊提出了產品發展更遠大的願景，在現時的社會氣氛下可說是非常大膽。最終回末段的對話提到，「片段化嘅零碎娛樂，令大家習慣覺得任何意念可以喺幾分鐘或者幾十秒之內表達」，「慢慢所有人都唔能夠再有專注力，承載重大意念」，而制作團隊的願景，是要「用節目凝聚同埋補完專注力」，「對抗零碎娛樂」。零碎娛樂指的是什麼？是那些「缺乏前文後理，了無意義」的娛樂片段 (「邊度多左個噴水池」?)。看清楚哪些網媒是在炒作新聞吸睛，讓人沉迷，或借此逃避現實，制作團隊更宏大的願景，是要借「娛樂」本身讓人恢復體力，「可以不按牌理咁歡笑」，對未來恢復希望，特別是要「張開眼睛活著」。

欣賞制作團隊，不得不提的也是非常欣賞Mike導 (Project Manager?) 。鏡頭上，無論是他建立團隊的能力，重視團隊精神，或是勇於為團隊的作品承擔壓力和責任 (e.g. 花姐Error遊雪地一幕)，團隊是互相指責卸責還是齊心合力，都是判斷是否優秀 Project Manager 的差異因素。當然還有Mike導本身的domain knowledge，思考和自我反省的個人能力。如果還有人以為整張task list，每個task 旁邊放上人名、加個時間，然後定期望一下是否在進行中有沒有delay，就算是在做Project Manager，就真的請「張開眼睛」，看一看真正的 Project Manager 需具備什麼特質。

回想自己最初寫這個blog，原意是希望讓更多人接觸項目管理的理論，可以建立團隊去處理和解決問題，或者至少不要在參與做項目時製造新的問題也是好的。但是，現實的問題錯踪複雜，而且受不少利益團體左右，很容易令人困惑、失望、心灰意冷，繼而用了錯誤的方式去「解決」。特別想提的是節目最終回末段的對話，「世界其實唔係有咁多制肘」，「世界其實唔係有咁多痛楚」，對於那些經常控訴社會或上一代的人，請想一想自己是不是也在用「等、靠、要」的思維，把問題推給別人，為自己不想努力解決問題而找藉口開脫。正如對話也提到，「只要一日仲留喺呢片土地上，每一個人都用自己嘅方式，喺自己嘅崗位戰鬥」，每個人都努力，就有望可以成功。

玻璃瓶的故事

網上流傳着這樣的一個故事。

有一位老師跟學生上一節生活課。老師先拿出一個玻璃瓶，然後拿出一堆拳頭般大的石頭，一塊塊放進玻璃瓶裏。當石塊堆滿出瓶頸時，已放不下一塊石了。老師於是問學生：「這個樽是否裝滿了？」學生都回答說是。

「真的嗎？」老師又拿出了一堆碎石，一粒一粒地地放進玻璃瓶，晃了晃，碎石落在了大石頭的縫隙之間，不一會，碎石都放進了玻璃瓶。老師於是問學生：「現在，這個樽是否裝滿了？」這次，學生們有些謹慎了，只有一位學生說：「應該還未滿。」

於是，老師又拿出了一杯幼沙，倒進玻璃瓶，細沙很快地填滿了碎石之間的空隙，最終全部都放進了玻璃瓶，瓶的表面也已經看不見石頭了。老師又問學生：「這個樽是否裝滿了？」學生們回答說：「還沒有吧。」但心裏沒有把握。老師又拿出了一杯水，慢慢地倒進玻璃瓶，水滲下去了，並沒有溢出來。

老師抬起頭，問學生：「這個小實驗說明了什麼？」一個學生回答說：「這說明了時間可以擠出來。」老師點頭說：「是的，你說對了一個方面，但有更重要的一點，你還未說出來。」

老師接着說：「這個小實驗還告訴我們，時間並不是可以隨便用的。如果不是首先把石塊放進玻璃瓶，就沒有機會放進去了，因為玻璃瓶已經裝滿了碎石和沙。而當你先把石塊放進去，玻璃瓶還會有很多意想不到的空間來裝剩下的東西。我們的人生，總有重要和不重要的事。如果任由不重要的事佔滿時間，那麼真正重要的事便沒有時間去做了。」

如果用這個故事來比喻項目管理的話，在項目的過程中，總會有重要及必須完成的開發需求，同時亦會有不太重要，可選擇後續優化的需求。一般而言，項目需要在既定的時間內完成，則需要有所選擇，揀選並優先完成重要的事項。（筆者註：沒有任何項目是沒有限定時間的）

在項目管理及產品管理中，有兩種情況是需要項目經理和產品經理特別注意的，一種情況是項目內團隊花了很大的力氣在一些支節問題上討論，卻忽視了主幹，造成人力資源和時間的浪費。另一種情況是在項目排序上，產品團隊缺乏產品發展的長遠規劃，無法集中資源在重點項目上。

對於第一種情況，團隊花費大量時間及精力，放在項目上瑣碎及支節的問題上進行討論，力求達致完美，情形就像是先把碎石和沙放進玻璃瓶，佔用了大部份空間一般，大的石頭無法再放下。這樣的花費可說是「一闊三大」，除了用於確認需求的時間，還有開發的時間，以致進行測試，都需要花費大量力氣，才可確保所有情景都有妥善處理。如果在做決定時毫不考慮項目資源的話，這樣的做法很容易造成項目延期，或需要加倍人力才可完成項目，如果因而令到項目團隊忽略了處理重要的問題，更是因小失大。

作為項目經理，需要具備能分辨出需求必要性的能力，並能提出疑問讓項目組成員進行討論，讓團隊永遠集中在重要的問題上，有需要的時候更應選擇提請上級，讓一些具爭議性的問題提早處理，免得團隊陷入無止境的討論，項目亦一直延期難以完成。

至於第二種情況，產品需要有長遠目標，更需要有策略定位，並按此訂立優先序，盡量集中資源在重點項目的開發上，但這卻是知易行難。

在很多時候，產品的開發都面對着選擇的困難。打從產品一期開發開始，項目需求已經多得不能在首階段完成所有需求，有時會以MVP形式先推出，未做完的放在待辦清單再後續處理，但根據過往經驗，項目上線後不是有大量新需求，就是有不少項目內沒有想到的問題要解決。

例如產品上線後，立即收到大量終端用戶的回饋意見，當中很多時都是非常有見地，亦會讓項目團隊不禁回想，自己為何不能早些想到這些需求。又例如看見行業內競爭對手的類似平台，就想想自己的平台可以如何優化，又會出現一系統的改進需求。產品經理一方面要評估新需求的優先序，另一方面也要分配資源去處理修復生產上發現的問題，經常也會有資源爭奪的情況。不過如果產品具有正確的價值定位，並且不要求同時間內方方面面都做足做全，那麼項目團隊就可以集中資源在重點項目上拼搏，持續改良產品。

正如玻璃瓶的故事所說，我們的時間是有限的。如果任由不重要的事佔滿時間，那麼真正重要的事便沒有時間去做了。人生也是一樣的吧。

重新整理 (Introduction)

今年年初開始寫blog，一直以來做法是把項目管理和數字化轉型的篇章放在一起。當時的想法是認為做項目可以更有效帶來改變，而數字化和科技是當中可以應用的手段。

近數星期，在網上閱讀多了一些材料，對數字化有了一個更為全面的認識，亦認為數字化在今日是需要從一個更宏觀角度去分析、了解和應用，而且數字化似乎是這個時代的一個大趨勢。故此，決定重新整理篇章，並把與數字化的相關篇章遷移至新blog《數字化思維》繼續。

至於這個blog，將仍然保留繼續寫項目管理的相關文章，包括範圍管理、溝通管理，亦包括項目周期內的需求管理和測試管理等。至於《政經隨筆》，則會用以紀錄政治經濟相關議題的想法。

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

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

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

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，以便在下次項目上作出調整。