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 的原因。

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

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

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

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

出類拔萃的項目管理

本blog 一向介紹的都是項目管理的思維，主要是範圍管理、需求管理、團隊管理等，或是一些新技術介紹，通常也較為General，少有特別就個別項目介紹。

本篇有點特別，介紹的是人物，他是剛在這週宣佈將要在明年不再續約的港交所行政總裁李小加。

坦白說，如果要用項目經理來形容李小加的工作，實在是大大貶低了他工作的難度和複雜之處。實際上，港交所過去十年的成就，也是由無數項目的成功落實而帶來的，有參與其中的朋友應也為自己投入的成果感到自豪吧。

項目管理的 Circle of Competency

股神Warren Buffett 有很多投資名言，其中一句是如下的：
"What an investor needs is the ability to correctly evaluate selected businesses. Note that word ‘selected’: You don’t have to be an expert on every company, or even many. You only have to be able to evaluate companies within your circle of competence."

本篇是假借了這個字，用以分辨項目管理的好與壞，只為標題吸睛，與股神的說話原意基本上沒有太多關連，按錯連結進來的朋友可以先行離去了 ^_^

在現實中，不難會遇上一些項目經理，對產品、流程和系統也不太熟悉，更莫說認識團隊各人的能力，但就特別著重於數字上的管理。例如項目的測試案例有多少、defects 有多少、或者牽涉修改的系統有多少個，測試人員有多少個等。又或者是在日子上，例如 task A跟task B跟task C有dependency，task B 要等task A 完成才可以開始，task C 又要等task B，項目時間就一直叠加延長。

如果項目管理真的就只是日子和數字的管理，那麼各行各業的項目經理基本上也可以互相調用的。例如一個銀行業的 PM ，其實也可以試著去地盤做工程管理，因為那裏的項目也會有Gantt Chart，也會有defects 的數字。這個例子當然有點極端，但項目管理中更需要注重的項目的細節，用有限的資源達致最大的效率，這些都是透過認識行業、認識產品、認識流程、認識系統而磨練出來的。

在項目管理的道路上，持續學習和改良技巧是相當重要的過程。為了能讓項目有效推進，筆者認為項目經理都應該要擴大自己能力圈 (Circle of Competency) 覆蓋的知識範圍，歸類為以下幾點：

首先是了解項目優化的產品和流程 (P&P)。大部份項目的開展，通常也與優化產品或優化流程有關，能夠了解產品本身的定位、優勢、客源，或是流程上的現有痛點，對於項目進行是大有幫助的。

在互聯網世代，產品更多是以持續優化的形式進行發展，未來也應該不會再有所謂「已完成」的產品。在這樣的情況，我們除了對當前項目範圍了解之外，更需要對產品有一個整體認識，知道產品現時狀態跟願景的差距，建立更長遠的發展路向，這樣將可為各個項目建立優先排序，安排資源更多花在重要的項目上。

操作上，可以嘗試用Agile Methodology 的Product Backlog去理解，讓產品持續進行迭代開發。即使機構內開發是用SDLC而不是用Agile，沒有Sprint 或者stand-up meeting，我們也至少可以為產品平台保持一張持續發展的清單，並且定期檢視（例如每季一次）以align 優先序，這張清單也可以讓項目團隊更了解現況和未來的發展，安排以個人career path 發展來配合。

其次是了解項目牽涉的系統 (S)。鑑於這個Blog重點談的是IT項目管理，牽涉的都是系統改造工程 (System Engineering)，在這些類型的項目，項目經理對於系統背後有所了解就甚為重要。

對於系統，很多項目經理對系統的印象就是系統的名稱，以及它的相關負責人，或者跟這個系統相關的task 清單，這當然是外行人或初入行者的做法。在項目管理上，就算是用戶部門擔任PM，也需要對系統功能至少有個整體認識，進而按項目需要再深入了解各個模組，這些知識通常不會一蹴而就，但卻是可以在持續進行項目過程中慢慢掌握的。尤其是當在一個行業內有一定日子，更會發現同一個行業或同一個產品，即使在不同機構上實施，也會有一套類似的系統，這也是由於每個產品背後實際上也是一個專業，會培訓出專業的人員承擔其職務，自然就會發展出提供類似功能的系統出來。

第三個是認識參與項目的團隊 (T)。不時會見到一些項目經理，由於是把重點看在WBS上，眼中就只有task 和負責人，對於他們來說就是一堆系統名稱和負責人名稱，實際上卻不是十分認識團隊的成員，以及各成員的能力和喜好。

要知道一個團隊入面，其實不是只有幾個負責人，當中也有不同的成員，負責承擔落實各項工作。進行項目會議時，筆者較傾向是鼓勵各個成員也要發言（換另一句話是不發言就不如不要來），希望各成員也有所實則參與，也盡可能匯報自己的工作。這樣項目經理也可借此了解成員的能力和喜好，以便後續安排，尤其是把成員配對成sub-team 作進一步工作分配。

當然，每個人參與項目其實也是有不同的aspiration。有些人是以發展建立自己career path的milestone 為目標，有些人則會視為BAU。大家能夠互相了解所需，就不會有太多不必要的比較。

最後一點是了解項目背後的目的 (G)，其實也是最重要的一點。每個項目的出現也有其背後原因，但不是每個項目也很容易見到這個原因，更多的是幾個項目的進行，達到更大的目標，這在較大的機構也較為常見。

在推動項目的同時，項目經理除了要自己明白項目的目標，更需要適時與團隊分享並align，確保項目發展保持在適當的方向上，亦防止項目中途加入一些不是原項目目標的新需求，導致項目大失預算。
　
最後引用C AllStar 的一些歌詞作結：
　高速的經濟 天天推展 為了計算出目前
　摩天的都市 事事但求膚淺 No...
　歪曲的真相 天天加演 在那推土機面前
　為數據比賽 這理念孕育二三十年

無論是機構內以至整體社會的發展，都需要更多注重細節，耐心處理和解決問題的人。了解細節很重要，衷心希望社會風氣不要把所有人都機械化或把事情簡化為數字的競賽。

How to screw-up project without taking responsibility (and how to prevent this)? (4)

Mentioned in other articles in this series, they are quite some "ways" for project managers to screw-up a project, yet not taking the responsibility for the project failure. These include setting up external dependencies that are uncontrollable to the project, allowing or even encouraging conflicts in the team, or enlarging project scope by bundling projects with minor linkage. Here comes the fourth article in this series, and it's related to communication.

Within the project management domain, or under the PMP framework, maintaining effective communication is one of the most critical processes throughout all stages of the project. Highly effective communication ensures key decisions of the project are made with consensus among the team. It keeps everybody in the team informed on the latest project progress, key milestones, key bottlenecks, and especially getting attentions on items that require immediate follow-up.

For full article, please visit Medium.

項目管理 - 開發量估算 (2)

繼上篇寫了開發量估算的重要性，本篇繼續，並會較具體說明估算的方法。

在進行IT項目時，合理的做法是就項目範圍及需求評估開發量及測試量，合理估算項目時間。當遇到項目需求有多種方法落實時，也就不同方案評估。不過，不時也會遇到一些情況，參與項目的成員沒有合理評估開發量的方法，或用了不準確的方法進行評估。

其中一個很常見的誤區，是按項目需要作出改動的系統數量作出評估。例如項目實施方案有兩個，A方案牽涉3個系統改動，B方案牽涉2個系統改動，就直接下結論說B方案較簡單。另一個類似情況，評估不同項目的大小，沒有仔細看項目內容，就看項目各自牽涉的改動系統數量作比較。這種方法是過份簡化了評估的過程，無視各個系統的改動範圍，也無視了系統本身的複雜程度。情況就比如比較任何兩個地點的距離，就用兩地相隔多少個地鐵站來比較，大家也可以想像到當中的誤差了。

不過，上述這個誤區之所以常見，除了是因為這種方法最為簡單，更重要是因為可以將比較數字化，這種做法能讓人自我感覺已做了breakdown，在不想仔細了解系統組成部份又想表示已做了什麼的話，就變成最好的方法了。

筆者也曾經遇過有些人參與項目，要做一個系統，就只看到一整個系統，沒有把系統的各個模塊或功能進行邏輯性分柝，情況就像要做一架車，他/她就只看到一整架車。這樣去做評估的話，法拉利也跟豐田一樣是一架車，各個系統也只是一個名稱而已。當問到要breakdown 時，就drill down 到逐個data field 去看，就像汽車的逐粒逐粒螺絲去看，這樣也同樣看不到有系統性或邏輯性。

實際上，在計算項目中系統開發量的時候，我們可以學習嘗試應用功能點分析 (Function Point Analysis，或FPA)的方法，把項目中所牽涉的系統開發各項功能分解，以協助了解並評估項目範圍的大小。就系統功能而言，我們可以把功能簡單分為數據及操作過程兩類。

先談數據 (FPA 以Data Function 來表示)。在評估數據功能時，最好是使用用戶能夠理解，有邏輯性關連的主數據群，例如客戶資料、交易紀錄、Static Data、市場數據、交易過程中數據等。數據又可以再細分為內部數據及外部接口數據，存儲在同一系統內的為內部數據，由其它系統調用的為外部數據。

其次是操作過程功能 (FPA 以Transaction Function來表示)。這裏我們要能夠看到系統的界線 (application boundary)，並以此界線分隔開系統和用戶以及和其它系統的關連，並細分各項功能的Input 及Output。例如系統讀取其它系統的數據是一個功能，提供數據接口是另一個功能。又例如用戶經介面輸入是一項功能，從另一介面查看數據又是另一項功能等。

當然也還要包括系統的internal process (FPA以Elementary Process 來表示)。Elementary Process 最好是能夠提系統提供的功能有邏輯性地拆解，愈細愈好，當然細的程度也要用戶能夠理解。如較複雜的流程，可以是流程上一個節點所進行的邏輯計算或按rule table進行判斷，又例如系統本身每日會行的batch job等。

應用功能點分析的做法，可以更有效地把項目的開發功能分拆，進而就各個功能評估開發量，例如同是調用外部數據，實時讀取和使用批次檔就很不同。亦可按過往項目的類似經驗進行評估，基於功能已經拆分為細件，就更容易找到能夠類似的開發功能進行比較和評估。

不過有不少項目的參與者，尤其是用戶，總會推說用戶的職責只在於提出需求，不需要理解當中IT是如何進行開發，做測試的時候也是用End-to-End方法云云。這種想法實際上也是有誤區的，亦是一種頗常見推卸責任的方法。正如「需求管理」篇章中提到，同一個需求，可以有不止一個實施方法，提供實施的細節亦是為了讓各項目成員判斷是否滿足需求。而至於測試，如果不清楚系統是怎樣實施以滿足需求，又怎能確保所謂End-to-End 測試有涵蓋所有開發功能呢？

當然，推卸責任也可以是無極限的，End-to-End 測試沒有涵蓋，有人可以一句就推說是SIT的不足，是否如此就視乎情況了。項目經理在確保項目質量時，需要能夠判斷項目中各個環節是否有效落實，分析需求、評估開發量是否到位等，這都可以在項目初期就建立較堅實的基礎。

項目管理 - 開發量估算

早一陣子匯豐按英國監管機構要求，公佈今年不派息，就連已除淨的2019年全年派息也hold 起，留作處理經濟危機。

事件後續在本地牽涉了兩件頗有花生味的事件，一是專欄作家早年教人不買樓買匯豐收息，另一是有人開班教人loop loop loop 大法借錢再按股叠加，同樣是買匯豐收息。事件令匯豐股價大跌，不少人也因此而蒙受損失，要求當事人負責。

面對逆境時，想盡辦法將損失轉嫁他人似乎是人的天性，一來是希望減少自己的實際損失，二來也是主觀希望失敗不是自己造成，也算是平衡心理的方法吧。

在進行項目時如面對項目嚴重延期，互相推卸責任也是很常見的事，一來是減少對自己工作表現評估的影響，二來也是主觀期望延期不是由自己造成。在這種情況下，最好的做法就是能替項目的失敗找替死鬼。很多情況下，最好的替死鬼更莫過於推卸給外部供應商。

筆者過去參與不同類型項目，也試過要接火棒處理牽涉龐大成本的開發項目，得到最大的經驗和教訓是，與其要想盡辦法去推卸責任，不如想盡辦法解決問題。尤其是在項目初段，管好項目範圍，管好需求，合理評估開發量及項目時間，明知道項目時間有限制，就不要把不必要的需求加在一起。寧可較保守，也不要over-commit 但最後不能完成，做好期望管理。

在經濟原則行先的社會，我們好像自小被教育要用最小的付出獲得最大的回報，在項目中請外部供應商進行開發，就變成是如何用最小的成本，要求供應商作最大範圍的開發。這種做法無疑可推動項目團隊利用有限資源追求成果的最大化，不過也不是沒有壞處，最容易發生的就是over-commit，或把過多需求合併在同一項目，在多方競爭時為爭取到合同就更容易出現這些情況。

為有效保障項目順利完成及防止over-commit，在「需求管理」的篇章中就提過項目初期的一個重要工作是確定落實方法，而另一個重要工作就是開發量的估算。就算我們多麼的希望用最小成本獲得最大回報，但開發量的估算一定要合理，供應商給出的估算無論是太高還是太低，對項目整體來說都一定不是好事，因為那都代表了供應商不完全掌握需求中的期望結果。太多可能是供應商對不確性的風險而留有buffer造成，太小則可能是供應商低估了開發的難度，或遺漏了一些重要的需求點。換個角度對需求方而言，也要評估供應商報價的合理性，不要一味追求低成本，更要重視項目的整體風險。

另一方面，無論對開發團隊還是需求方而言，都應盡可能將整體項目分開不同的component，分項估算開發量，這樣對開發量的估算就可以更有透明度，亦更有說服力。而隨著項目時間的流逝，項目經理更可以分項評估消耗了的時間是不是換來足夠的work done，以判斷項目的各個組件是on-schedule 還是behind schedule，behind 的話情況是否嚴重能否追趕得上，又或者在更壞情況下是否可以壯士斷臂，把項目變為分段上線以免夜長夢多。

有興趣的朋友，也可參考以下的相關篇章。

《項目管理 - 需求管理》
《需求、目標和口號》
《項目管理 - 「跑馬仔」論》

How to screw-up project without taking responsibility (and how to prevent this)? (3)

The third article in this series, and this time the focus will be related to scope definition.

As mentioned in multiple other blog posts, one of the most critical skills in project management is about scope management. This covers not just the initial scope definition at the start of the project, but also an ongoing effort to understand what is related to the project, what is the priority, and essentially an understanding on the logical dependency for different components of the projects, that allows project managers to determine whether to launch the changes by phases when needed.

There is, however, quite a number of project managers who work in the other way round, which is to unreasonably bundle the different items together, forming huge projects that are not easy to understand the dependencies. Honestly speaking, there're quite some good reasons for combining projects. We have to understand when and why to combine projects, that we can judge whether the reason makes sense from an overall company perspective.

For full article, please refer to Medium.

項目管理 - 需求管理

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

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

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

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

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

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

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

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

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

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

項目管理 - 溝通的管理（二）

早前開始了「溝通管理」的系列，亦提到會議的重要性。在項目過程中，一般我們認為採用會議的模式，可以確保各個項目組成員同步，即時討論及交流項目上一些重要決策信息。與此同時，項目經理在會議上可直接觀察到成員的反應，能判斷溝通的成效及作出調整，例如安排更進一步的討論或作出說明。

不過，我們也要了解以項目成本來說，會議實際上是相當「昂貴」的溝通途徑。為確保會議進行有效討論，以及訊息即時傳遞，通常會議也需要大部份成員出席，假設一個八人會議開一個半小時，就已經用了12個man-hour，這是可以做很多事情的時間，因此我們經常要提醒自己，要想項目能有實則推進，要嚴控會議的時間，讓團隊有足夠時間處理實務工作。

那麼除了項目會議之外，有哪些途徑可維持溝通而又不太耗費大量時間呢？首先我們從學術角度，先認識一下在實際環境中比較常見的幾種溝通模式。

1) Chain-Model
顧名思義，Chain Model 是鏈狀的溝通，溝通只與旁邊的Node發生，不會進一步超越。常見的實際情況是用戶跟IT 部門各自有PM / Leader，即Business PM / Technical Lead，用戶跟IT的溝通主要都由Leader 負責，其它同事則負責執行，有問題就向各自Leader 匯報，同事之間則不會互相溝通。

2) Wheel-Model
這一種是輪狀的溝通，這種溝通模式在實際環境下是Project Manager 處於正中，項目組其它同事則圍著PM。各個同事都只會跟PM溝通，而PM則負責把信息傳送至需要收取的聽眾。

3) Network-Model
這種模式假設所有組員都會互相溝通，每個信息也會發送給組內的所有人員。這種情況除了是會議，也可以在即時通訊軟件的群組內實現。

從以上各種模式來看，Chain-Model 和Wheel-Model 會有較多的間接對話，Chain-Model 情況尤甚，明顯壞處是有機會導致溝通的過程中出現錯誤，兩層是可以接受，三層或以上則應盡量避免。不過好處是可以保證PM對所有溝通都有掌握，不怕出現災難。

Wheel-Model 假設所有溝通都需要經過中間的PM，這會很大機會讓PM overload，雖然能掌握所以項目細節，但卻反而很大機會變成項目推進的bottleneck。

Network-Model 是可以直接對話的模式，不過在實際情況中反而不常出現，原因是對話內容中會有不少並不是需要所有人接收的內容，這個Model 反而會出現大量雜音，也很難確保所有人接收信息得到同樣的理解。

在實際情況，即使在同一個項目團隊，我們通常都需要多種模式，建議做法是項目整體使用Network-Model 作重要信息溝通，與此同時在項目中分為小組使用Chain-Model。原則上除非必要（如項目組員之間有心病），不建議使用Wheel-Model。

在「建立團隊」的篇章中提過，機構中很多情況下業務部門與業務系統會以一個既定的組合關係出現，而我們亦需要刻意讓這種關係出現在項目中，讓業務需求由正確對應的人員負責落實，這很適合用於項目分組上。

另外，我們也可以應用「踩單車」及「跑馬仔」的理論，分別管理各個分組的運作，建立合適的溝通模式。分組的好處是可以讓各分組選用不同的模式運作，這樣項目運行也會更為靈活。

How to screw-up project without taking responsibility (and how to prevent this)? (2)

Today we'll continue on the series that started last week, and discuss another pretty "effective" way that some project managers adopt to avoid taking responsibilities when experiencing project failure, which is to allow conflicts within the project team.

Being a project manager is never an easy task, and to be honest, there're pretty much scenarios or factors that could impact to the project schedule. Without proper project scope definition, efficient communication and control in place, regular monitoring of project pace, or stakeholder expectation management, or an instinct to spot project risks, a project can easily go wrong.

When a project is not delivering the expected result, or when a project is just keep delaying without meeting the milestones, it is not uncommon that a project manager is being asked to explain the root causes. To some project managers, one most important skill is not to deliver the project itself, but to be able to create a sound story, which can explain how unavoidable the delay was.

For full article, visit @medium

需求、目標和口號

過去幾週分別寫了不同範疇的系統需求撰寫方法，相信讀者對系統需求應有基礎了解 ，也應了解定義需求是項目實施中的重要一步，需求能夠愈清晰，最終成品跟期望的距離就愈近。

但在很多情況下，需求是否有足夠細化清晰並沒有一些容易量化或量度的標準，而且亦因人而異，各個團隊都不同。很常見的情況是用戶部門一直說需求已經很清晰，或者「這個需求就是如此簡單」，但IT團隊卻一直未能動工，指需要更細化的需求，這導致項目中出現很多的爭拗。項目經理需要有能力判斷需求是否有足夠的細化，當中包括提出合適的問題，引導團隊內的用戶和IT人員進行更深入討論，亦需要不偏不倚，一切以推進項目作最終目標，從而定義出合適團隊的細化度。

不過以上的情況也是在一些已經相對上互相合作的團隊內發生，而且團隊也有相當項目經驗。在實際環境中我們更常會遇到的情況，是我們發現很多參與項目的人是從根本上分不清「需求」、「目標」和「口號」的，這也就是今日的題目。

在過去數週的篇章，闡述了系統需求是怎麼一回事。首先，系統需求也是開發的一部份，包括定義系統需要的元素、邏輯、流程，以至於UI、報表等最終呈現的模式。另外，系統需求描述了項目的期望結果，讓用戶與IT團隊在初期就期望結果達成一致而開發落實。理想的系統需求通常能夠很容易計算開發量，亦能夠按需求制定測試計劃，進行驗收。

不過在實際情況，有很多人把「需求」寫得過份簡單，或誤把項目的「目標」當成了「需求」，造成很多我們所謂一句說話就講完的需求，例子有：「系統需要就業務紀錄提供報表」，或例如：「系統在出現問題時需要有通報機制」，甚至乎「我們要做一個跟XXX很相似的平台」，開發人員對這些所謂「需求」的理解，從而作出開發量及項目的預算，就可以跟用戶相差甚遠。

例如就業務提出報表，就可以有很多問題。報表內容是什麼？需要有多少份報表？按什麼維度畫分？最終用戶是誰？多久出一次報表？又例如通報機制。什麼的問題需要通報？通報誰？即時通報還是歸總翌日通報？透過甚麼途徑？通報後的處理是怎樣？這些都是在定義需求時需要考慮，而不是在開發甚至測試時才討論。

而至於「我們要做一個跟XXX很相似的平台」，例如我們要做一個流程平台，或者報表平台。作為項目經理，應該都很常聽到「我們要搭建一個新平台，功能要與舊的一樣」這樣的需求吧。在這種情況下，即使我們是希望以別家平台作為藍本，我們也要將別家平台上的功能元素羅列出來，逐點深化討論具體需求，才能夠更準確地確保大家所想的開發範圍一致，合理評估開發量及項目時間。否則的話，這種「需求」就跟「目標」無異，制成品跟期望可以有很大落差。

我們可以嘗試在生活中訓練一下自己思考系統需求的能力，例如「建一個Instagram App有甚麼功能元素？」，很多時我們會只能列出在自己看到的介面上的功能，例如可以upload 相出post，可以follow 別人，比心心、comment、forward、bookmark 等等。深入一點也會看得出user profile setting、privacy setting、notification 等功能。但其實隱藏在後面的還有大量我們未知的功能，例如演算法、post relevancy。如果以為建起介面就等於建起整個平台，這樣作出的估算可以與實際出現極大距離，項目失敗的風險將是極高。

再舉一個例子，在現時疫情下，很多公司也研究在家工作的方案，並評估相關風險，例如customer data leakage。這類型的項目需求似乎可以一句說完，例如「提供notebook讓同事能在家連結到公司網絡工作」，但其實「工作」本身就可以牽涉很多不同種類。收發電郵是一種類型，需要登入業務系統是另一種類型，有些開發人員則只需要登入開發/測試環境，各種類型就可以牽涉不同的安全需求，以致不同的實施方案。

經常聽有些用戶會說，「我已經提出了需求，接下來的工作就是IT去想怎麼實現」，其實這是很不負責任的，尤其是需求就只一句說話。項目的落實方案本身是需要項目團隊一齊決定，不同的實施方案，牽涉不同的風險，更重要是如果項目的範圍牽涉到其它地方的影響，項目團隊就更有責任去評估並作出相應的對策，這些都絕不能是一句「我已經提出需求」就完事的，更何況開發完成後就到測試階段，沒有具體的需求和實施方案，又試問怎樣安排驗收測試呢？

不過在現實中，太多人只談「目標」，太少人參與深化「需求」，漸漸地「目標」甚至發展成一些「口號」，例如「我們要自動化」，「我們要簡化公司的流程」，或者「我們要建立方便同事使用的軟件平台」等。這些「口號」說出來當然大家也是支持的，但如果機構內出現太多這種只有空談沒有落地的團隊，就可以看出機構內部營運正處於危險的境地。大家若是希望機構能作出一些實則改變，就會明白只談「口號」是沒有意義的，更重要是大家要在自己的崗位/domain上參與制定方案的過程，評估方案的優缺點，細化需求，這樣做才可以提高項目成功的機會。

本篇現已在Medium提供英文版本，有興趣的可按此觀看。

項目管理 - 「踩單車」論

延續上周的篇章，不過在進一步寫溝通管理之前，先寫一個筆者在過去一年項目管理的實踐中領略的另一個理論。

在營運IT項目中，一般我們會將項目組的主要成員分為用戶團隊及IT人員，用戶團隊主要負責細化定義需求，IT人員則提供方案並且進行開發實施，再由用戶負責驗收，發現問題則由IT人員修復，重覆這個過程直至最終完成製成品上線。

在一個良性發展的項目組中，雙方在各個環節上其實互相依賴，除了在各自承擔的任務上盡力之外，在另一方進行之時亦協助對方，這樣的項目通常能夠快速推進。筆者想像以「踩單車」來形容這個過程，用戶團隊及IT人員就好像踩單車的左右腳，雖然各自努力，但一人一步單車就會向前進，交互愈頻密則前進速度愈快，這個理論即使對非IT的項目也適用。

特別要用「踩單車」來形容做項目的原因，是因為踩單車過程需要雙腳都出力，才能推動單車，不是說缺少任何一方一定不行，只是說另一方會費更大的力才達到效果，對整體機構來說不合符效益。

事實上，筆者過去見過不少項目中出現用戶和IT團隊不和的情況，項目中浪費大量時間互相指責。在一些極端情況，項目中用戶團隊甚至乎放棄找IT團隊參與，直接與外部廠商談需求，指望這樣項目可以運作更快。這樣的情況特別容易發生在一些新科技項目上，IT部門本身沒有特定團隊負責，用戶一心打算能獨力推進項目，或者找些consultant 幫助就可。

在過去經驗中，用戶與IT團隊各自行事，一般也沒有好結果，最常發生的情況是項目初期評估不足，例如沒有就硬件、網絡及系統安全等需求作出考慮，導致項目在初期好像是快速推進，但在中後期問題卻陸續湧現，例如新系統難於與現有系統對接，或者出現system performance 問題，投產後的系統維護亦遇到重重困難。

另一種極端情況則是只考慮想替換老舊系統，例如廠商不再提供維護的系統，但用戶則不太投入參與。這樣由IT獨力做出來的製成品也不會真正符合用戶所需，系統是換了，但感覺換之後比之前的更不好用，最好的情況是跟之前的做得很接近，但卻沒有借換代的機會提升效能。最重要問題是這樣的項目，連拿個UAT signoff 也難，這會讓IT人員對工作失去熱誠也沒有成就感。

在進行項目中，筆者一直強調的是用戶和IT團隊同心合力，align 大家的priority，包括項目目標、範圍、實施方案，以至大家投入的資源及timeline，這樣的項目做起來會更為順暢，像「踩單車」般共同努力推進項目。而在項目過程中，亦需要持續檢視左右腳的施力及效能，以確保能及早發現出問題的地方作出修正。在一些更大型的項目中，實則上項目並不是只有一架單車運作，而是多架單車並行推動項目（類似情況請參閱「跑馬仔」篇章），這種情況下項目經理更需要同時兼顧看著多架單車的情況。

另一方面，筆者一直創造的是用戶及IT成員互相信任，可放心直接對話的氛圍，讓左右腳可互相配合。這是提升項目中溝通效率的重要方法，下周的篇章會進一步寫。

How to screw-up a project without taking responsibility (and how to prevent this)? (1)

Project manager is a crucial role in a project. A project manager helps define the project scope and project schedule, shapes the implementation approach, establish the team, and ensure the team is working towards the project goal ...

Nevertheless, there're occasions that the project manager is not doing his/her job, or he/she is just not capable to handle a project in such scale. We can see a lot of examples where projects are failed due to wrong determination of project scope, inability to remove project dependencies, or conflicts appeared within the team which hinder the project progress. However, it is also not surprise to see when project is not going in the right way or keep delaying, the project manager is still working without a need to take the responsibility. The blog series in the coming few weeks will try to illustrate the various "method" for this, and talk about how to prevent this from happening again.

Among all the reasons of project failure, one most "effective" way to screw-up project without taking responsibility, is to create dependencies to the project which cannot be managed by the project manager alone.

Full article has been moved to @medium

項目管理 - 溝通的管理（一）

在項目管理系列上，過去幾星期寫了多篇Blog 強調嚴格控制項目範圍的重要性，本篇開始寫其它範疇，先談溝通。

在一個有一定規模的機構內，正式途徑的溝通包括有會議、電郵，隨著科技發展，有些機構也漸漸適應及接受使用即時通訊軟件作為有紀錄的溝通渠道，溝通比以前就更加直接和簡單了。

在項目的框架中，為保持項目組成員之間的資訊同步，必然牽涉溝通。一般在項目中，會議是最主要的溝通途徑。會議是項目組成員需要共同參與的工作，對於項目中較重要的決策，例如項目初期決定產品發展方向，確立項目範圍，時間表，實施框架等，都需要透過會議充份討論，以確保項目組成員的深度參與，訂立合適的項目計劃。初期的項目會議，亦是協助建立團隊的起點，有助成員互相認識，配合後續的分工安排。

隨著項目發展，會議仍然是項目組之間重要的溝通渠道。對於不是放軟手腳做的項目來說，一週最少一次的項目會議是必要的。有持續進展的項目，一周內能發生的事很多，可以積聚不少問題，會議有助讓決策成員聚起來討論和處理問題，同時亦讓項目組成員審視進度，讓項目繼續推進。行Agile的項目，甚至要求每天一次會議，但筆者個人認為會議並不是愈多愈密就愈好，下面會進一步再說。接下來先談一下會議參與成員的安排。

之前在「建立團隊」的篇章亦提過，項目成立時一般會按其核心範圍，訂立需要參與項目的相關業務團隊及系統人員，並透過這些成員的domain knowledge 推進項目。但在實際環境下，項目的範圍始終都會發展至影響一些周邊，如果周邊組員也要同等份量參與項目，這種做法會導致機構內大小項目不能並行，造成浪費，所以我們不能要求每個模組都對項目付出同等的參與程度，反而需要分成核心團隊及周邊成員，適當使用機構內的人力資源。

這個做法對於項目會議的安排尤其重要，每周會議主要是要求項目組核心團隊的參與，對於周邊模組，則應採取按需要而定的策略，切勿強制要求各組成員參與周會。項目經理要控制參與項目會議的人數，盡可能保持在 7-9 人，上限不超過11-13人。但筆者經常也遇到有團隊拉大隊參與會議的情況（單一個部門就7-8人也見過，背後原因可能是寧願浪費時間也不想另作溝通，或者本身團隊內分工不清沒人願意牽頭），但這個也不難處理，因為這種情況來參與會議的人中不少是只參與不發言的，所以控制發言人數在7-9 人也是可以接受的。

另外一點是，項目會議並不是愈多愈好，項目經理更要盡最大努力控制會議的時長。一般來說每周進行的會議應控制在一小時左右，二小時為上限。事實上在進行超過一小時會議後，效率已經會開始下降，超過兩小時效率就更加會大跌。以「嚴控範圍」篇章中所提到的項目為例，這個項目每周會議就是一整個下午，這是相當浪費時間及耗費精力的。事實上，會出現這種長時間會議，對項目本身就是一個警號，首先時間長直接表示的是討論的內容太多而且放在同一個會議上討論，本來就應該要分開不同會議進行。另外再引伸的潛在問題就是項目範圍太闊，而且夾纏不清未能有效分割處理。如果項目長時間會議同時牽涉大量成員參與，問題則更加嚴重，因為大部份人在會議上的大部份時間也是浪費的。

要正確處理項目時間過長的問題，除了全體項目組成員參與的會議，項目亦應該設立個別獨立會議的機制，組織個別成員聚焦討論個別不關乎整體的問題，這亦包括專為周邊模組而開的會議，這可以大大有助減輕佔用全體會議的時間，全體會議亦可聚焦討論較大影響的事項。另外，筆者通常在項目中會刻意安排業務成員與IT成員的配對，確保溝通的過程暢順，這個做法用個別獨立會議進行也會比較容易。當然，更根本的處理方法應該是在項目範圍上設限，或者透過分phase / 分項進行，這樣每個子項目的重點會更加清晰，溝通上亦會更容易管理。

項目管理 - 「跑馬仔」論

早前於「航海論」中寫了筆者用航海類比項目管理的一些看法，本篇以「跑馬仔」來形容項目中並行管理子項目的過程。「跑馬仔」論主要應用於較為大型的項目或項目群，通常牽涉多個部門並行參與，而為了完成項目，大家都需要向終點進發，完成整個項目內歸屬自己的部份。以下會寫筆者的一些想法和應用時必要的思維和考慮。

筆者在不少文章中亦提到，在一般情況下，並不建議進行大型項目，更應奉行「小改變大改善」的理念，這是項目管理最有效的方法，能夠分開的盡量分開做，也好管理改變帶來的風險。不過在很多情況下，大型項目是無可避免的，例如隨著業務需求進行底層系統的更換，或者是項目需要牽涉到核心功能的改變。

既然說得大型項目要同步上線，是否就代表一定要像大笨象般緩慢前進呢？那當然不是。事實上，在管理大型項目時，我們更需要把項目分拆成若干子項目，讓各個子項目更能靈活運用自身資源推進，並透過「跑馬仔」思維同步管理子項目。

以一個更換核心業務系統的項目作為例子，我們就可以有各種維度分拆成子項目：

• 按產品劃分（各團隊包括產品經理，營運部門）
• 按前中後台劃分（前線包括銷售渠道，中台為風控，後台則為後勤營運服務）
• 按客群劃分（如個人客戶，小微企業，大型企業）
• 按部門功能劃分（如將財務及風控劃為獨立子項目）

分拆的方法，最好是按照機構內部門的劃分為基礎，盡量控制每個子項目內的參與部門及成員數目，以減少每個子項目互相影響。另外也需要安排核心項目組成員加入若干子項目進行協調，確保在分拆後仍保留一定程度的互動通訊。而考慮到各個部門的對項目的投入度也有所不一，在分柝上上亦可以做些微調，讓子項目內可以互補不足，確保各個子項目都能夠有效推進。「跑馬仔」論的一個重要理念是不求一枝獨秀，最重要是每個團隊都有能力完成「賽事」。因此，團隊成員也並不一定要保持不變，項目中進行適當的調整是完全可以接受的。

「跑馬仔」論本身最重要的用途是用於同步評估各個子項目的進度，監察並發現出個別較為落後的子項目並予以協助，防止個別問題造成整個項目的延期，本身並不在乎哪個團隊最快完成。不過人與人之間總是會有互相比較的，這會協助人發奮追求更快的速度，亦可用「鯰魚效應」來形容。這可以算是「跑馬仔」論的一個副產品。

有一些KPI或Dashboard 是可以用來比較子項目進度的，例如如果項目是要各團隊同步進行UAT，就可以比較各團隊的測試準備進度，測試進度，剩餘問題等，再早階段的如項目需求也可以。不過比較要合理，如果一個子項目的進度要視乎另一子項目情況的話，就不宜同步比較。當然，發現哪裏出現了問題，最重要是先了解原因，數字只是輔助工具，更重要是背後的原因和適當處理的方法。

在應用「跑馬仔」理論上時也有一些需要特別注意的地方。

首先是在心態上。再重申一次，「跑馬仔」並不是為了定輸嬴，我們用這個方法是為了更有效發現可能出現問題的環節，更快提供協助去處理，要知道一個環節出事，整個項目團隊也會受到影響。另外，不要被表面數字蒙敝，背後的真相更重要，同時也不要只顧著看個別較為落後團隊而忽視了整體。

另外一點要特別小心，人有時會有一種不是太好的特性，就是自己不好也不希望見到別人好。這裏要要特別小心處理有個別團隊並不跟進自己範圍內的進度，反而著眼於其它團隊，故意放大其它團隊做得不好的地方。

其實要做好項目，各個子項目團隊只需要做好自己的本份就已經可以，不過總有些人自己做得不好，卻想靠放大其它人的錯誤來掩飾自己不好的地方。項目經理要保持清晰的頭腦和視覺，確保整個項目團隊不受這些事件影響，並把團隊引導回正確的路上。

相關文章：
《項目管理 - 「航海論」》

How do we manage difficult stakeholders?

Being a project manager is never an easy job. We're continuously dealing with a lot of stuff, and what's more, our work requires us dealing with a lot of people. Believe most project managers would agree that dealing with people is among all the most challenging work in this area.

To start with the topic today, we have to appreciate that a project is a change from an existing state to a future state, and it is indeed the fundamental reason to have a project at the very beginning. In most cases, we believe a change is required to enhance or improve something, maybe to automate or streamline some processes, or in some cases we're tired of dealing with a legacy platform that is no longer able to support the business in many area, and a change is required to replace it. Yet in many cases a change is also introducing big impact to the existing operation flow, requiring people to adopt new processes.

Full article has been moved to @medium

項目管理 - 建立團隊

之前寫了項目範圍管理，本篇談團隊的建立和重要性，某程度也與控制項目範圍有很直接的關係。

在談團隊建立之前，首先簡略介紹為什麼會出現項目 (Why)，項目又是如何出現 (How)。

在一個具一定規模的企業內，企業劃分了各個部門，部門會有不同的整體職能，而部門內的員工會再具體分工，重點負責處理部門被授與的各項職務，當中他們會應用到不同的系統，系統亦由不同的IT團隊負責維護。

在這樣的一個企業內，經常會出現各種優化改進的需求，亦有機會出現公司策略性轉型，再演化成落實方案，這些需求以及方案，建立了項目的鄒型。用PMP的方法，我們會用Project Charter 去紀錄這個項目誕生的過程，包括建立項目的原因，它的具體目標，主要負責人以及初步方案等。

在Project Charter 中我們亦會建立項目的初步團隊，包括牽頭的業務部門以及主要參與的部門的用戶成員，初步評估主要需要改動系統的負責IT人員，這些人員是項目的核心成員，也可稱為項目組成員。

對一個相對有效運作的機構來說，很多情況下業務部門與業務系統會以一個既定的組合關係出現，即一組業務組成員對應一組系統開發成員，雙方都對這個domain 上的日常操作有一定程度的認知。而在項目的架構上，我們也刻意地選擇項目核心成員，確保這樣的關係有出現在項目組之內，讓業務需求由正確對應的人員負責落實，下面會再補充說明這樣做的好處。

在項目組內，我們有所謂「Product Owner」的角色，即代表業務聲音及項目需求的主要負責人。這個角色尤其重要，他/她可以定義需求是否合適，是否必要，優先序等，對項目的最終採納的方案亦擁有決定權。如果Product Owner 本身在機構內亦有被賦與這個權限，他的決定則代表了業務的決定，另一情況Product Owner 如被授權跟進項目，他則負責與最終stakeholder 持續溝通，確保項目的航向正確。如有熟悉項目管理法則的Product Owner，則可兼任項目經理推動項目，在滿足業務需求之餘亦同時考慮項目各項風險。一般來說，Product Owner 會是牽頭部門的成員。

項目團隊的成員則包括以上所說的相關業務部門及系統人員，理想的情況是由7-9人組織成核心項目組，定義項目的核心範圍，亦有情況碰巧有兩組業務的涉及範圍也同樣重要，核心項目組則有機會延伸至11-13人。再多的話，基本上就應該要考慮把項目分拆為細項目，分開跟進了。

限制核心項目組成員人數有很多好處，主要目的是確保溝通的過程順暢，團隊成員互相之間的角色定位較為清晰，亦較易mobilize，另外亦間接限制了項目的範圍，讓項目聚焦於最重要的範圍內進行。牽涉人數再增多，某程度上代表項目有機會分柝出細項目，這個時候，項目經理應考慮另行組織sub-project team，選擇讓部份核心成員加入。這樣sub-project team 成員可以協助參與整個項目的個別任務，而毋須全程投入，這可以為機構節省不少人力資源。

必須要提的一點是，無論是核心項目組或是sub-project team，團隊內建立業務單位與系統開發人員的組合尤其重要，這是由於業務單位所提的需求能有對應的系統人員即時反饋可行性，兩者可合作建立較為合理的方案。否則的話，溝通上會出現不少問題，例如會議上決定的方案有機會在會後否決，或會議未能有效決策，這會大大影響項目的效率。

項目經理在完成建立團隊後，應持續監察項目進行時團隊是否能有效執行項目上各項工作，並能發現團隊中的異常情況並作出適當調節。更進一步，項目經理可嘗試發掘項目團隊成員的優缺點，在不影響成員在機構中的角色為前提，在分配工作上作出微調。能做到這點的話，項目成員將更好發揮實力，對項目有正面影響，成員亦能享有滿足感。

項目管理 - 「航海論」

以前曾經與一些前輩討論關於對項目的看法，有前輩說做項目就如「戰爭」一樣，項目成敗就靠平時團隊是否訓練有素，合作無間。又有前輩說做項目就如「踢波」，每個人都有不同崗位，有人擔當前鋒有人則做後防，筆者個人則喜愛用「航海」來比喻做項目。

做項目跟架船出海航行有很多相似的地方，稍為列舉如下：

第一、項目跟航海都有既定目的

每一個項目都有成立的目的，就好像開一艘船，把船上的人和貨，由現在地帶到目的地

第二、項目有範圍，受限於時間及資源，就像船有載貨量上限
項目要有合理的資源才可以完成，就像船也受限於載貨量
資源不合理的話，有機會用時間搭救，但也不要排除搭沉船的可能

第三、項目有團隊，就像船員一樣

大家上得這艘船，都期望用自己的知識和經驗，協助架駛這艘船到目的地
而船員也有不同的崗位，項目團隊也一樣

第四、項目途中總會遇到難題，就像航海會遇到風浪一樣

預到困難的時候，大家就想辦法去拆解，這可能會影響船期，但通常也是能處理的
不過未到目的地之前，您永遠不知道這次是不是上了鐵達尼號

第五、項目有大有小，就像世上有遠洋渡輪和天星小輪

不同的航線，由不同的人駕駛，也協助不同的人到達他們的目的地
您不會搭天星小輪橫渡大西洋，就像您的團隊要有一定能力才可做一些大項目

有幾個地方是航海時要注意的，可避免出海後處於一直航行的狀態，做項目也適用。

舉例說，在項目的過程中，我們經常碰到有人會突然走進來，說這個項目要處理某個問題，問題可能是項目衍生的，可能是項目讓問題加劇，也有可能是有人碰巧想起的現有問題。以「航海」來比喻這個情況的話，這就像在航行中的船上，突然有乘客說船要到目的地，必須要經過某個中途站一般，而這將令船程加長。

作為一個項目經理，您也像船長一般，在海上會遇到這種情況，而您需要在面對時作出判斷選擇，這裏有幾點是作為船長的考慮。

首先是乘客的話的真確性，海上會有很多機會遇到漂流已久的乘客，總盼望著有天有艘船經過接載他到他的目的地，只不過他不想自己做船開船。這就像機構裏有些現存問題，有人知道這些問題一直存在，只不過總不想去解決，就待有人經過去處理一樣，而漂流乘客的量可能跟機構的現存問題一樣多。

這裏會有幾個可能的情況，最好的情況是乘客的話是真的，船程的確長了，但他的出現協助船避過一些災難，也有可能乘客的話半真半假，但對於船程來說整體影響不大，船長不妨就當做件好事，協助他去目的地，就像協助處理了一件現有問題。當然也有最壞的情況是乘客刻意隱暪了一些事實，船長錯信的話，讓船在海中繞了一大圈。

不過無論是以上任何一個情況，有一點是項目經理要時刻謹記的，就是在未清楚確實狀況之前，您要嚴格避免讓乘客進駕駛艙，以確保船隻不會隨便改變航向。而當最後確認船是真的要轉向，亦要確保所有船員知道這個選擇，以及背後的原因，這點跟項目裏出現Change Request 的處理和道理是一樣的。

而如果您發現這個轉向是不必要的，對船程的影響代價也太大的話，船長也可以選擇有禮貌地請乘客下船。畢竟船出航之後是一直在燒油的，這批船員也要待完成使命才可以安排下一個任務，所以也不要太顧慮這樣做不太人道。而當您在船公司一直走上去的話，可能會去到不止開一艘船，而是管理一個船隊的時候，就更可以建議乘客走另一條航線，可能會更易到達他的目的地。