需求分析入門 - 系統化流程

前一篇Blog 提到「流程化」，本篇為實戰教學，簡單介紹使用系統進行流程化管理的需求分析技巧，讀者需要對IT系統有最基本程度的認識，有需要的話建議可與修讀IT的朋友進一步討論。

使用系統進行流程化，一般需要有一些重覆性的流程程序，意即有不同的工作，當中存在既定的關連性及邏輯關係。透過系統整合，可以standardize整套流程，避免做錯、做漏。下面以一個申請入會的流程作為例子，牽涉的節點包括：
填寫資料 -》提交申請 -》內部審批 -》通過申請並保存紀錄資料

第一步 繪畫流程草圖（可以用BI Tool，更簡單則用白紙畫）

• 按現有已知的流程，嘗試繪畫出流程的初稿
• 繪畫時宜先針對Normal Positive Case，即正常情況下完成的流程，作為流程基礎
• 在基礎上加入特殊情況，對出現Branch的情況，配上condition
• 一般做法正常流程節點使用長方形標示，出現 condition 則使用菱形標示
• 盡量把所有想得到會出現的各種情況加入流程
• 太複雜的地方可先留白，後續再補上（記著80-20 rule）

第二步 整理流程節點清單 （建議用Excel 整理）

• 按第一步繪畫的流程，以文字列出整個流程的所有步驟
• 同樣地，先列出Positive Case所牽涉的步驟，即正常情況下完成的流程
• 再加入特殊情況的流程節點
• 為所有節點配上編號，編號盡量是由小到大排
• 流程太長的話，編號可使用點數分隔 (e.g. 2.1, 2.2)，以便將幾個關連節點整合
• 流程節點旁邊加入Action Owner，可以為內部人員或客戶
• 每個節點標上所使用的系統
• 加入Dependency資料，即開始進行本項節點前，必先完成的上一個部驟的編號
• 一般來說，較大的編號通常depends on 較小的編號

在經過第二步後，項目團隊應已更深入地想到流程上各種可出現的情況

而對於在第一步留白的地方，在第二步內一般能以文字詳細列出現有做法

有了第一步和第二步基礎，正式可以整合出仔細的流程圖

以下做法是筆者在一次項目中跟日本人所學，再進行了一些優化

第三步 整合仔細流程圖 (可用專門畫流程的軟件如Visio，但筆者也只是用Excel)

• 將整體流理以橫向平坦形式顯示 (X-Axis)
• 流程所牽涉系統以直向形式分類 (Y-Axis)
• 將流程節點放在對應系統的列上
• 正常流程節點使用長方形標示，邏輯判斷則用菱形
• 以不同顏色分辨角色 (i.e. Action Party)，例如客戶，內部用戶及系統操作
• 配上Step No. （最好跟第二步的編號一致）
• 為每個牽涉人為操作的節點配上狀態名稱
• 補上 Start 及 End 後，理論上所有箭咀都一定要有頭有尾

下面為一流程製成示圖

當然以上這個例子是極為簡單的一個流程圖，僅作參考展示用途，實際上一個入會申請流程應牽涉更多步驟及系統。

以下為一些較common 要注意的地方

• 在第三步的流程圖，盡量要做到流程從左向右及從上到下發展，不要回帶
• 較多使用到的系統應盡量置頂
• 如果系統做判斷的邏輯較為繁複，可考慮在附頁詳細列出criteria，以保持流程圖整潔
• 畫箭咀時必須與圖形相連，確保移動步驟時可連帶箭咀一齊移動

做系統流程化項目是需要多做多學的，在做這類型項目的同時也會不斷學習，所以如果機構內有專門負責流程的部門，應可整合出更好的經驗，事半功倍。

關於電子表格的需求分析技巧，可參與這篇Blog

最後要特別點出的是，Workflow Diagram 跟State Diagram 並非一樣，也並不可共用，下次可開另一個Post 寫State Diagram 的用法。

項目管理 - 「航海論」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一周總結

開站一個星期
繼續保持著每日寫一篇Blog 的習慣
這個也是花挺多時間的
希望能為世界帶來一點點的改變吧

未來一段日子會盡量繼續保持著一日一篇
盡力去寫
鑑於最近腦中出現很多很多的想法
也要訂一些優先次序逐步實行
並且能保留一些時間繼續學習
以下稍為整理了未來一段時間出post的安排

• 星期一將集中為新科技介紹，短期內將會寫的包括個人很喜愛的Microservices, Open API 和DevOps，稍後也會寫關於Robotics, Blockchain 等之前也有研究過的題目
• 星期二將會是項目管理思維的整理，控制範圍仍然會是主線，也會談一下團隊管理
• 星期三初期預留給數字化轉型，暫時有的題目並不多，主要先集中無紙化、流程化及系統集成
• 星期四集中介紹促進生產力軟件的應用
• 星期五為實戰經驗分享，初期會談需求分析，稍後會有測試管理
• 星期六預留為嘗試解答一些項目管理上較難的問題
• 星期日為休息日，也預留作調整及學習

How to manage "difficult" project?

The topic today is one of the many questions that has been discussed in many forums in the project management community. To try to answer this, first we have to define what do we regard as a "difficult" project.

When talking about difficult project, people usually link this up with "big project" at the first instinct - projects having a wide scope, projects involving a large number of users, or projects introducing numerous changes in multiple systems.

Let's try to think about this question in another way. Consider in a theoretical case that a project can be divided in pieces with equal size, which can be evenly assigned to a team of people, who can work individually and with no dependency to other's work. In such case, once the work schedule for each member is estimated, that would contribute to the overall project timeline. That would mean, no matter how "big" is the project, given there's sufficient amount of skilled workers, the project can eventually be finished when the time comes.

Obviously there's no such theoretical project in the real-life. First of all, projects can never be divided in equal piece, but this is not the main point. What's the most important part is that we are living in a world where each of us depends on one another. For example, we work on our domain to produce result which benefit one another, and at the same time we also rely on another domain to provide necessary input to us. While a project introduces changes to an existing function, inevitably the change may cause impact to the others. This creates the dependencies and makes the project scope difficult to confine, and it's this dependency that can cause a project "difficult" to manage.

Full article can be found in @medium

需求分析入門 - 電子表格

前一篇Blog提到「無紙化」，其中一個實現方向就是把紙張表格變為電子表格，這應該是眾多IT項目當中比較入門級的一類，本篇稍為整理此類型項目的需求分析技巧，專為從未參與過IT項目的朋友而設，任何人也可以為環保盡一分力。

轉用電子表格的前提，通常是已有existing紙張表格作為基礎，這類型項目好處除包括減省紙張使用和人手輸入電腦，亦可在raw data 輸入時更好的控制data quality，即避免填錯、填漏情況，需求分析可採取下面步驟進行，下面假設是用web page形式做的電子表格。

第一步 整理欄位清單 （最好是用Excel整理）

• 先從現有紙張表格抽取所有需要填寫的欄位字段 (Field List)
• 定義每個欄位的Field Format (如TEXT, Numeric)
• 為欄位訂立字數上限, 例如：
• TEXT方面比較通用的如"X(10)"代表最長十個character
• Numeric 方面通用的如"(10,2)" 代表10個個位數digit，2 個小數位
• 如果欄位是選項(例如：先生/女士)，則列出可以選擇的全部value
• 欄位是否必填?
• 某些欄位如果是基於另一欄位判定其是否必填，可用remarks 補充
• 有些欄位的可選範圍與另一欄位有關，亦可用remarks 補充
• 用地址欄位作例子：即先選HK/KLN/NT, 再選的district就不是所有區
• 最後為所有欄位配上編號，以作記認及cross-reference

第二步 選擇顯示模式

• 不同的Field Format, 在顯示時可以選用不同模式，提升用戶體驗
• 筆者註：這是電子表格更為優勝的地方
• Free Text Input 通常是一行的Text Field, 按字數上限調教長度
• 較長的Free Text Input 可以選用Multi-line Text Box
• 選項欄按選擇的數目多少而定，少的傾向用Radio button，多的時候則用dropdown list
• Dropdown list 盡可能按英文字母或筆劃排，亦可選業務常用的先置頂
• 如果欄位容許選多於一項 (例：您從什麼途徑知道這個網站），則用Tick Box
• 如果是一組欄位（例如聯絡人資料包括姓名，電話，電郵），而又容許輸入多組數據（多個聯絡人），則可使用＋，讓用戶有需要時增加一整組欄位填寫
• 這樣做就不用好像紙張表格般預留多組空白欄位，不過記緊設上限

第三步 Field Validation

• 在各個欄位加入validation rules
• 基礎通用的validation包括Field Format validation, 字數上限檢查，mandatory field 檢查
• 特殊的檢測如身份證號碼，電話號碼字頭，電郵地址

第四步 配上Error Message

• 用戶提交表格時如系統檢測到錯誤，當然要能夠即時反饋報錯，讓用戶更正
• 筆者註：紙張表格就要重新填寫了..
• Error Message 最好是放在欄位旁邊提示

以下為一些比較common 要注意的情況

• 機構如有一定規模，通常已有既定系統儲存數據，Data Field Format 及字數上限最好都參考一下系統數據庫現有配置，不要憑空估計（例：不要設1000字上限的地址）
• Error Message 要就Field Validation rules 設計，要簡單易明，切忌放入組織內的專用名詞，要讓一般用戶亦能夠明白錯誤原因
• 如果要填寫的資料很多，可考慮分section甚至分頁，唯分頁需要對已填寫的資料作暫存，技術要求高一點，亦要考慮收集個人資料的問題（筆者按：理論上客戶未提交申請之前，資料不應被收集儲存），因此如果對象並非現有客戶，同一頁分section 較可取
• 避免用戶不小心按錯而離開頁面，加入一些離開頁面的提示訊息

另外，現有紙張表格可能出現多處要求填入重覆資料的情況，這可能是因為多年沒有整合表格而造成，當中申請按揭應該是我看過最差的例子，很多頁的表格，不停重覆要填寫姓名及其它個人資料，轉用電子表格的時候，可一併考慮將這些欄位合併，由系統邏輯把資料分配到需要的流程上，就不需用戶重覆輸入了。

項目管理第一原則 - 嚴控範圍

在云云眾多的管理技巧中，個人認為管理項目範圍是當中最重要一環，控制得宜項目可進行得事半功倍，控制不當則後患無窮。

曾經在一間大型機構裏參與一個巨型項目，事實上項目本身並不巨型，或者說可以有很多方法令它不致變成如此。純粹是一個產品平台的換代項目，不過經歷多次人為影響，一個平台換代項目竟然要整個機構差不多一半的IT系統作出改動，二十多個用戶部門/sub-team需要參與，每周開一次項目例會要有二三十人來，一開就是一整個下午，在我首次接手這個項目的時候，對這種狀況當真有種嘆為觀止的感覺 ...

接手了項目一段頗長時間後，終於漸漸看出苗頭，了解這個項目的一些背景發展。（寒戰 - 梁家輝：第一步，你要學會它。第二步，從中找出一個線頭。）這個項目之所以變成這個模樣，主要原因就是沒有做好範圍管理 (scope management)，甚至可以說它是反其道而行，把本來應該是十數個項目放在一起，以一個項目來推行。這個項目無論從渠道、從產品，以至從客群來看，都有多種方法可以把它砍件，拆開幾個phase 進行，就算項目的理想有多遠大，只要把項目有效分割，分段進行，始終會可以完成，不知為何一定要一起推進，而每個細項則是龜速移動。我當時舉了「沙中線」作為一個對比，「如果沙中線一直未能通到中環，難道到紅磡的路建好也不允許通車？」，除了用「無知」和「好大喜功」來形容，也找不到更好的原因去理解這件事。（筆者註：在多次問題出現後，上星期鐵路通到啟德就已經通車了）

嘗試了幾次在不同階段希望遊說各方把項目重新砍件分phase，結果也失敗了，大概是沒有人願意承擔起當初「建成」這個項目的責任，或者沒有人願意說自己做不起這個巨型項目吧。最後我也放棄了遊說工作，基於我相信的「小改變 大改善」法則，我改為在這個項目做了一些「小改變」，可以說是沒有辦法中的辦法。

首先一個改變，是把項目分拆成多個條線，當中包括按產品劃分，按渠道劃分，按客群劃分

安排好了條線，就是安排團隊，每個條線按其domain加入product owner及相關IT人員組成主幹，工作目標為重新定義或細化需求，落實開發及測試驗收，各團隊則按自身需要編配開會時間跟進項目進度。這樣做，各團隊就可以重建自己的項目及職責範圍，合理定義工作進度，上面一層則主力監察有否出現沒有團隊跟進的灰色地帶，以及處理不同團隊出現相互有dependence 的情況。

做這幾個小改動的首要目標，就是要把工作分派出來，由專責團隊人員承擔。大家才是各自domain 的專家，最有資格去決定需求和系統方案，旁人加把嘴給些意見可以，但絕不能dominate這個討論。

另一重要作用則是減少開週會的時間，這裏本來就是不同的項目團隊，本身關連不大，放在一起開會是沒有意義的，只會浪費大家時間，把問題放在周會上討論，更加是風馬牛不相及（況且周會大多數時間也是個別數人討論個別幾個問題，效果有多好可想而知）。後來這些團隊索性直接在自己的sub-team 裏解決問題，解決了就完事，也不再在周會上報告，省回不少開會時間做更多正經事情。

整理這些經驗，嚴控項目範圍的主要目的：

1. 控制範圍，以便建立團隊

2. 責任與榮耀到人：團隊由具domain knowledge人員組成，並為製成品負責

3. 由團隊制定合理時間表，然後 commit schedule，最終合併成整體項目時間表

就這樣，PMP中的四大重點 - Scope, Schedule, Cost (人力成本), Quality, 就基本確立了

後記：

雖然進行了一番改動，畢竟項目整體範圍並沒有因此而收窄，而且這些改動也是在幾個dominator 離開之後才能正式推動，這個項目在進入UAT階段後，也經歷了慘不忍睹的黑暗狀況，這些經驗會在另一篇blog 繼續整理。

新的開始

說了很多年想要開Blog
但一直都沒有切實執行
過了十多年社交媒體的洗禮
大家也習慣了短篇comment 快速share
現在大家連FB也不多用，IG也開始out了
反而想走回舊路，用長篇文字整理一下思緒

早幾年在一間銀行工作時
有名IT主管提議我將一大型項目的各種失敗之處整理出書
我也的確有此想法，連書名也想好
叫做"10 ways to screw-up a system implementation project"
（中文名是"十個有效搞砸項目的方法"）
銀行這行業一年到晚也有IT項目
好的差的項目經理也有
好的項目經理可以建造團隊群策群力一齊向目標衝刺
差的則可以制造內部矛盾互相指責，項目則一再超支延期
就過去幾年所見
有些項目管理上的common mistake 是絕對可以避免的
亦有好些通用方法可以做好項目
但說到要出書整理，目前來說距離還是很遠
寫Blog 作為開始可能比較合理

新年伊始，社會剛在持續多月的社會運動稍為喘息
立即又遇上傳染力極強的新型肺炎
社會充滿矛盾及對立
人民對政府不滿情緒在各處發洩
街道上網絡上也很不平和

無論如何
這是一個需要改變的時代
而我相信改變是可以透過項目形式和原理去進行
引導相關持份者參與
合理定義目標範圍，合作推行

以下會是這個Blog 的初步方向：
1. IT 項目管理的思維整理
2. 應用科技解決問題
3. 長遠投資於科技公司的考量