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

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

不過，我們也要了解以項目成本來說，會議實際上是相當「昂貴」的溝通途徑。為確保會議進行有效討論，以及訊息即時傳遞，通常會議也需要大部份成員出席，假設一個八人會議開一個半小時，就已經用了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

需求分析入門 - 用戶介面 (UI)

踏進互聯網時代，我們生活中大小事務也與電腦/手機息息相關，也可以說是電子化協助了我們與世界的互動，世界發展亦會愈趨人機交互。

對於日常生活使用的軟件，尤其是手機平台上的App，相信今天不會有哪個App 是需要看說明書才可以用了。但回到公司的軟件系統，很多人也遇到同樣問題，為什麼工作上的軟件這麼難用，難道就不能做好一點給自己的同事？

就筆者個人意見，UI 需要簡潔、實用，即使不看說明書也能夠學懂怎樣使用，就是好的UI。對外部用戶來說，好的UI 可以提升客戶體驗，吸引客戶繼續使用，這當然重要，但也別忘了內部用戶。能夠設計出好用的軟件供內部用戶使用，能夠提升生產力，間接帶動業蹟，這是企業內部核心競爭力的一部份。本篇會寫幾個設計用戶介面時需要有的心態。

（一）重點是人，而不是資料

內部使用的系統，一般會牽涉不少資料輸入的頁面。我們所設計的系統，將要由人來使用，要用得方便，就必須要合乎邏輯且有條理。在設計的時候，我們要清醒地想著這是做給人使用的系統，而不是把現有流程或紙張表格直接搬進系統就了事。

因此，在用戶介面上，需要配合適當的元素去展示，例如文字、圖片、下拉框、按鈕，方便用戶使用，並且配合適當的提示及反饋報錯信息。流程相關的介面，更應該提供navigation bar 及/或 status bar，引導用戶使用。

記著，重點是人，而不是資料。

（二）不僅是功能和技術，更重要是同理心

很多人在開發內部人員使用的平台，都會先想開發技術，想功能清單，其實同理心更重要。

不要以為有內部用戶使用，就代表有人可以包底。實際上內部用戶與客戶一樣是產品的使用者，要做出真正好用的產品，要減少出錯，減少需要人手處理，另外也要盡量提供一統的體驗，讓用戶建立使用習慣並且適用於多個平台功能上。

與此同時，像之前的篇章所提的，嘗試在設計的時候檢查現有流程的合理性，盡量把不必要的流程刪除、整合、自動化。

（三）從需求出發，尤其是終端用戶的需求

在設計時，也別忘了要把終端使用者的需求放進設計，當中包括功能顯示的順序，盡量讓操作更加順暢自然，合乎需要。對於設計供外部用戶使用的軟件，我們一般也會考慮軟件的實用性，並且會想盡辦法提升客戶體驗，對內部用戶也是一樣。

事實上在有一定規模的機構內，有不少前線業務人員例如銷售組，是不會直接參與開發平台的，但他們卻是平台的最終使用者。在開發時，要盡量收集他們的需求，並且在產品推出後，繼續持續獲取他們的反饋意見優化產品。

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

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

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

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

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

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

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

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

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

四周總結

很努力的維持了四周連續每天寫Blog，中間也有些時候是覺得挺辛苦的，每晚也花不少時間去研讀，盡量確保自己寫出來的東西言之有物。

坦白說，有不少之前寫的題目，寫之前以為自己已經有相當了解，但到真正寫的時候，才發現有不少也未完全了解，或者概念上可能與另外一些內容有重叠，需要再上網找些資料才可落實。

事實上寫Blog是一直想實行的事，應該由數年前開始已經每年寫在新年目標的清單，在疫情之下，反而有一個落實的機會。

早幾天在一個電台節目中也有主持提到，今次疫情讓不少人的生活出現大幅改變，工作上有部份人變成work from home，有人甚至要變成返shift / part-time。沒有了日復日重覆上班，反而讓不少人重新思考生活，思考工作的意義。

筆者本人並不討厭上班，但當上班是日復日做同樣的工作，而並不知道工作的目標，就很讓人喪失意志。很希望透過這個Blog，讓更多人了解和擁抱互聯網世界帶來的轉變，並且投身其中，引導各項轉變的落實。

需求分析入門 - Automation

需求分析入門系列，今次寫的是「自動化」（Automation）。

很久以前就聽有人說過，如果有某個工序是在一個月內重覆超過5次，就已經值得考慮將它「自動化」。的確，沒有太多需要用腦的工序，不值得耗費人的時間去執行，除非這個工序需要精湛工藝，或者是因為原材料(source data)無法standardize，才需要人的介入實時判斷。如果現有工作都已經是跟著manual 做，就更加應該完全實現自動化。

系統上的「自動化」基本上可以分兩種，一種是event-driven 的，另一種是scheduled job。Event-driven 意指系統detect 到某種狀況的出現而發起的「自動執行」，例如收到客戶下單，系統背後進行一連串的操作，而scheduled job 則是定點時間進行。如果進行的是一連串的automated job，我們則用batch automation 形容。

要將人手執行的工序「自動化」， 首先是把routine執行的所有動作紀錄。這個跟早前另一篇章的「流程化」也頗為相似，不同的地方是「流程化」更著重的是整體流程，尤其是牽涉不同組織的操作，而這裏「自動化」則聚焦於個別工序。

初步紀錄後，通常會發現到工序大致上是按照一既定程序，若干中間步驟則會出現不同情況需要作出判斷。這裏可以把不同情況列出，寫得出的都盡量寫。寫需求的時候，我們也跟以上一樣，要先判斷是event-driven 還是scheduled automation，這會是程序的第一步。

完成以上幾步，基本上已經可以開始設計方案，實現automation。如果懂得programming的話，可以直接把步驟轉化成code level，未掌握好的話也可以先嘗試用logical statement 寫，再交由IT人員落實。

以下是一些common 的logical statement：

1. 「If-then-else」，主要用於邏輯判斷，可理解為如果發生某種情況，則做一些動作，否則則做另一些動作。如果並列有大量不同情況，則可用「case-if 」並用rule table表示執行上的不同。又如果邏輯之間有dependency，稍為進階的則可用把不同case 整合為「nested-if」。

2. 「Loop」，主要用於重覆執行一些步驟，當中又可以分為確切執行一定數量，或是持續執行直至達成某個條件。

3. 「When」，主要用來描術自動程序的啟動點，例如是某種情況發生，或者到了某個時間。

按現時Automation的成熟程度，要實現全自動化主要仍有兩大難點，一是數據不是formatted data，另一個就是工序牽涉多個系統。

原則上，如果用來作邏輯判斷的數據已經是formatted data，coding 會相對簡單得多，因為可以直接取用數據，如果不是的，就要考慮機構內的基建是否足夠方便轉化成formatted data，例如OCR，不能的話也只能繼續使用人手錄入數據。（但筆者的建議是源頭減廢，即在數據進入系統那刻開始就收集formatted data，詳情可看「無紙化」編）。至於牽涉多個系統的情況，則可以考慮用流程系統連接各個系統，但開發時間會較長，較新的方法是用RPA的工具協助。

今時今日，學懂一種programming language，就跟學懂一種國際語言般重要，而隨著世界大趨勢發展，可以想像未來懂基礎programming 基本上是必要的技能。對初學者而言，macro 算是比較易上手的language，而且excel 就已經有build-in 作coding 的平台，作為試驗學習性質就極之方便。如想要學習syntax，上Google也基本上用"How to xxxx"就可隨時找到，希望更多的人也可作出嘗試。

有一點在寫需求時切勿忘記，就是Automation 中可能出現的Exceptional Handling，簡單來說就是要為automate job 出現error 時的通報及恢復處理機制。千萬別以為系統自動化後就與人無關，Automation的作用是把重覆性的工序交由系統處理，但並不代表以後沒有人再需要為工序負責。在開發時候，可以建立一些手動重啟的切入點，也可以嘗試把簡單的重啟都設定為自動化。

另外是從項目管理的角度，切勿妄想可以一次過把所有工序都全自動化。「自動化」需要有計劃，大規模的「自動化」需要整體規劃然後分階段落實，另一方法則是由小做起，逐步將現有手工操作「自動化」。每一次的改變過程中都要仔細考慮所帶來的影響及風險，以及與整體操作的銜接。分階段落實可以每次聚焦個別板塊，由團隊成員評估方案，減低big-band 帶來的風險。

需求分析入門 - 相關篇章
《電子表格》
《流程設計》

項目管理 - 「跑馬仔」論

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

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

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

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

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

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

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

有一些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

需求分析入門 - 報表 (Report)

今次寫的需求分析系列，是另一個也相對入門級的範疇。作為學習和理解系統邏輯的初階應用，「報表」是相對容易理解的，不過「報表」也有分好壞，要做好報表，一般也需要較強的分析及整理能力，這需要時間培養。「報表」作為機構內部溝通的中介手段，對外部用戶來說更加是做業務分析（例如業績）的重要工具，學習做好「報表」清晰表達信息就甚為重要。

業務上一般也有各種各樣的報表需求，做報表時我們需要清楚知道自己要甚麼數據。一般我們用的文字報表，有特定樣版，selection criteria，sorting，grouping。用Excel的角度去理解，就是select column, filter row, sorting order 及分類summary table。

為了方便用戶確認需求，第一步建議用Excel形式寫低想要的Report 「樣板」，例如需要甚麼column 資料，通常一開始時也不會想得太仔細，例如customer list, transaction record，但這個也不緊要，可以後續再優化。這一步最重要是大概訂下框架，知道需要哪些類型的資料，預算要造多少份報表。原則上，報表以內容類型為單位，切忌把不同類型的數據放在一起。

再來就是「Filtering Criteria」，包括甚麼，不包括甚麼，這裏最重要是知道Filtering Criteria 將來會不會改變，如果基本上不會變，可以直接code做得較為簡單一點，但如果可見將來都知道要改變，就要做得比較flexible，例如用parameter table 控制，這樣就不需要經常改logic。

然後是「Sorting」，基本上是optional的一步，反正用excel 都可以做得到。「Summary table」 也是差不多，對懂得使用excel pivot table 的用戶意義不大，pivot table 基本上可以做到任何形式的summary table。

確認以上各點後，記緊與用戶確認Report Frequency，是定點時間如Daily, Weekly, Monthly, Quarterly, Yearly等，還是需要adhoc real-time 出，這個按需要去做，沒有用的就不要把所有report 都做daily。還有就是Owner 及Target Recipient，每份Report 都一定要有Owner，作為開發人員，應在開發報表的量上作出適當平衡，能夠重用的盡量重用，但也要考慮將來優化的安排。另外也要為Report 起一個名稱，這個很重要，一個好名稱讓用家一看就大約知道用途，也可以在Report 下面做個remarks 上補上一些例如filtering criteria logic，用的時候會更加方便。最後別忘了給一個Report ID作識別。

對一般用戶來說用Excel來學習整報表會較容易理解，因為Excel上基本上已經把所有數據都平放出來，但系統背後儲存的數據，一般是分佈在不同的table 上，所以要讓用戶明白系統怎樣把數據整合，而不是要把數據抄貼到同一sheet上，起碼要先讓用戶認識Excel 的vlookup。

一般來說，在項目初期並不需要完全確認所有報表的需求，確認了基礎框架和數量，大約每份的內容就好，因為隨著項目的進程，過程中也會有所增減。不過要特別留意的是，用戶一般在開始階段只會想到正常需要有的報表，而根據經驗絕大部份用來做exception handling 的report都不會再初期提出，所以項目團隊宜在項目預算時留有一些buffer 空間，例如就每個模塊或用戶組，預留小量時間作特殊需求用。

不過報表也有它的limitation，業務7x24 在跑，報表某程度上是在某個時間做snapshot，到看報表時已經不是即時數據。如果機構內做PDF format 的報表就更傻，把本來是數字化的數據變回不能容易調用的Format，只有守舊派純粹想印份report 出來tick 才會這樣做，一般想用數據作進一步分析的都應該用excel format。另外也有部份人花大量時間在需求上優化報表，又要做summary table又要做graphic，希望自己用的時候只需要copy and paste。別傻了！這樣requirement 一變就要重做，而且這些用excel 做一定美觀得多，絕對不應浪費開發人員的時間。

以往報表絕大多數是直接在產品平台上做，如果機構內有很多產品平台，用戶就要適應看不同format 的report，體驗就不很好。現在的趨勢是後台透過API 提供即時數據，或批量出batch file，而前端就專門優化顯示，這樣大家可以各司其職，而且亦可更容易處理原始數據來源不同系統的問題。有好些專做output management 的平台就做得十分出色，定義好source data 的分類標籤，end-user 也可以在UI上隨意調用，亦可就report 做返version history，這樣做report 就不用寫code，快捷方便得多。

項目管理 - 建立團隊

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

在談團隊建立之前，首先簡略介紹為什麼會出現項目 (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，團隊內建立業務單位與系統開發人員的組合尤其重要，這是由於業務單位所提的需求能有對應的系統人員即時反饋可行性，兩者可合作建立較為合理的方案。否則的話，溝通上會出現不少問題，例如會議上決定的方案有機會在會後否決，或會議未能有效決策，這會大大影響項目的效率。

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

兩周總結

堅持努力完成了兩周每天寫Blog
老實說讀者並不是很多
不過也很有得著

在寫Blog這個過程中
發現自己要深入一點去寫一個命題
也需要多找點資料
無論是項目管理或需求分析的思維
又或是Cloud, Open API, Gov 2.0 等新理念
可以培養自己多閱讀多思考
也是不錯的學習

本世紀第三個十年
就這樣就過了兩個月
十年相等於120個月
代表已經過了2/120
這樣想一想就真的覺得時間過得太快
更不想再多浪費作無謂的事