2020年12月29日星期二

玻璃瓶的故事

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2020年11月7日星期六

重新整理 (Introduction)

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

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

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

2020年10月12日星期一

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

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

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

  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,則有相當大的討論空間,日後會再整理一下思維再寫。

2020年10月4日星期日

項目管理 - 項目估算

好幾個月沒有出新 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,以便在下次項目上作出調整。

2020年5月17日星期日

Soft Competence of IT Project Manager

今日在執拾和清理電腦,找回了一個很久以前開的檔案。

很久之前,大約也有差不多十年之前吧,在一個網站裏看到過關於IT Project Manager 的Soft Competence,列出了一系列的標準,用以在各方面綜合評估IT PM 的能力。

當時筆者還是一個剛出社會工作的小伙子,還未有機會開始做PM 的工作,但就按著這個標準來看其它PM的做法,也把這些標準記錄了下來,希望自己也朝著這些目標前進。

以下的標準大約有二十多個,印象中每個也可以由1-5評分,但實際上多少分叫做高我也不太記得了,也覺得這個並不重要,重要反而是這些標準描述本身。

嘗試在Google 上想找回這些標準的出處,但也找不到了,希望原作者不會介意吧。

Communication
  1. Effective Questioning - The IT PM demonstrated his/her ability to ask appropriate question to obtain relevant information. 
  2. Listening Skills - The IT PM understood the meaning of the conversation 
  3. Open Communication - The IT PM allowed everyone to express his/her opinions freely 
  4. Presentation Skills - The IT PM expressed with clarity in the public/meeting environment.
  5. Writing Skills - The IT PM expressed with clarity on paper 
  6. Verbal Skills - The IT PM expressed with clarity orally
Leadership
  1. The IT PM created the right environment for effective performance of team members
  2. The IT PM was able to motivate others 
  3. The IT PM was able to make timely decision 
  4. Goal-Oriented - The IT PM possessed clear future picture and plan everything to achieve that 
  5. The IT PM was able to manage the expectation of stakeholders 
  6. Political Savvy - The IT PM was able to influence through relationships to accomplish the project goals 
Negotiation
  1. The IT PM demonstrated his/her conflict and dispute resolution skills 
  2. The IT PM demonstrated his/her negotiation skills in building consensus 
  3. The IT PM demonstrated his/her persuasiveness, marketing or selling skills 
Ability
  1. Flexibility - The IT PM demonstrated his/her ability to make pragmatic adjustment as necessary for fulfilling project objectives 
  2. Strategic Thinking / Big Picture Perspective - The IT PM demonstrated his/her ability to visualize the organizational impact 
  3. The IT PM demonstrated his/her problem solving skills / solution oriented attitude 
  4. Proactive approach - The IT PM demonstrated his/her ability to anticipate problem/risks and take preventive action 
  5. Risk taking / "Can-do" Attitude - The IT PM took responsibilities under unclear situation 
  6. Respect Difference - The IT PM was willing to listen to different opinions and demonstrated his/her ability to communicate without offending others 
  7. Social Skills - The IT PM demonstrated his/her ability to get along well with others, empathy, interpersonal sensitivity & trustful
  8. Cultural Sensitivity - The IT PM demonstrated his/her ability to detect, respect and accommodate culture difference 
今日回看,仍然覺得這些標準在今日的機構裏仍然是相當適用。作為項目經理,大家也可以用這個來評核一下自己的表現。

2020年5月10日星期日

出類拔萃的項目管理

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

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

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

2020年5月9日星期六

項目管理的 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...
 歪曲的真相 天天加演 在那推土機面前
 為數據比賽 這理念孕育二三十年

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

2020年4月27日星期一

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.

2020年4月24日星期五

項目管理 - 開發量估算 (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的不足,是否如此就視乎情況了。項目經理在確保項目質量時,需要能夠判斷項目中各個環節是否有效落實,分析需求、評估開發量是否到位等,這都可以在項目初期就建立較堅實的基礎。

2020年4月20日星期一

項目管理 - 開發量估算

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

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

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

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

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

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

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

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

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

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

2020年4月12日星期日

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.

2020年4月8日星期三

項目管理 - 需求管理

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

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

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

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

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

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

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

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

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

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

2020年4月4日星期六

三月總結

努力地完成了六周半每日寫blog 的考驗,也有朋友提到有使用本blog 介紹的軟件,實在很感謝朋友的支持,希望寫的內容對大家也有幫助。

現時全球疫情仍然持續,歐美很多地方更出現大爆發,全球也出現醫療用品緊張的情況,尤其是口罩,醫療系統的負荷也十分嚴重。

作為一個普通人,能夠協助解決疫情的,就是減少外出、減少與人接觸、盡量不與其它人同枱食飯,另外也要注意個人衞生,勤洗手、戴口罩。

減少外出的方法有很多,可行情況下盡量留家工作,別為刷存在感而出現在辦公室,開會也請盡量使用電話會議和善用科技,別把同事叫到會議室。假日盡量留在家中,在家運動和學習,減少聚會。外出食飯盡量買外賣自己食,談話可以有很多場合,不必一定在吃飯時,吃完之後戴上口罩再談也可。

世界的問題有很多,但辦法也是一樣的多。今次的疫情需要全人類齊心面對,能否面對和處理,在乎個人的心態和信念,懷疑、埋怨和互相指責則無助解決問題。

後記:最近筆者的題目清單也出現存貨不足的問題,未來一段時間不會維持每日一Blog的產量,也留多一點時間學習多點新知識後再恢復。

2020年3月31日星期二

項目管理 - 溝通的管理(二)

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

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

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

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

2020年3月28日星期六

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

2020年3月27日星期五

需求、目標和口號

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

但在很多情況下,需求是否有足夠細化清晰並沒有一些容易量化或量度的標準,而且亦因人而異,各個團隊都不同。很常見的情況是用戶部門一直說需求已經很清晰,或者「這個需求就是如此簡單」,但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提供英文版本,有興趣的可按此觀看。

2020年3月24日星期二

項目管理 - 「踩單車」論

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

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

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

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

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

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

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

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

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

2020年3月21日星期六

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

2020年3月20日星期五

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

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

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

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

(一)重點是人,而不是資料

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

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

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

(二)不僅是功能和技術,更重要是同理心

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

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

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

(三)從需求出發,尤其是終端用戶的需求

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

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

2020年3月17日星期二

項目管理 - 溝通的管理(一)

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

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

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

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

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

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

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

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

2020年3月15日星期日

四周總結

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

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

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

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

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

2020年3月13日星期五

需求分析入門 - 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 帶來的風險。

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

2020年3月10日星期二

項目管理 - 「跑馬仔」論

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

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

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

以一個更換核心業務系統的項目作為例子,我們就可以有各種維度分拆成子項目:
  • 按產品劃分(各團隊包括產品經理,營運部門)
  • 按前中後台劃分(前線包括銷售渠道,中台為風控,後台則為後勤營運服務)
  • 按客群劃分(如個人客戶,小微企業,大型企業)
  • 按部門功能劃分(如將財務及風控劃為獨立子項目)
分拆的方法,最好是按照機構內部門的劃分為基礎,盡量控制每個子項目內的參與部門及成員數目,以減少每個子項目互相影響。另外也需要安排核心項目組成員加入若干子項目進行協調,確保在分拆後仍保留一定程度的互動通訊。而考慮到各個部門的對項目的投入度也有所不一,在分柝上上亦可以做些微調,讓子項目內可以互補不足,確保各個子項目都能夠有效推進。「跑馬仔」論的一個重要理念是不求一枝獨秀,最重要是每個團隊都有能力完成「賽事」。因此,團隊成員也並不一定要保持不變,項目中進行適當的調整是完全可以接受的。

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

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

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

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

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

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

相關文章:
項目管理 - 「航海論」

2020年3月7日星期六

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

2020年3月6日星期五

需求分析入門 - 報表 (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,快捷方便得多。

2020年3月3日星期二

項目管理 - 建立團隊

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

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

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

2020年3月1日星期日

兩周總結

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

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

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

2020年2月28日星期五

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

前一篇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 的用法。

2020年2月25日星期二

項目管理 - 「航海論」

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

做項目跟架船出海航行有很多相似的地方,稍為列舉如下:
第一、項目跟航海都有既定目的
每一個項目都有成立的目的,就好像開一艘船,把船上的人和貨,由現在地帶到目的地

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

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

第四、項目途中總會遇到難題,就像航海會遇到風浪一樣
預到困難的時候,大家就想辦法去拆解,這可能會影響船期,但通常也是能處理的
不過未到目的地之前,您永遠不知道這次是不是上了鐵達尼號

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

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

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

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

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

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

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

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

2020年2月23日星期日

一周總結

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

未來一段日子會盡量繼續保持著一日一篇
盡力去寫
鑑於最近腦中出現很多很多的想法
也要訂一些優先次序逐步實行
並且能保留一些時間繼續學習
以下稍為整理了未來一段時間出post的安排
  • 星期一將集中為新科技介紹,短期內將會寫的包括個人很喜愛的Microservices, Open API 和DevOps,稍後也會寫關於Robotics, Blockchain 等之前也有研究過的題目
  • 星期二將會是項目管理思維的整理,控制範圍仍然會是主線,也會談一下團隊管理
  • 星期三初期預留給數字化轉型,暫時有的題目並不多,主要先集中無紙化、流程化及系統集成
  • 星期四集中介紹促進生產力軟件的應用
  • 星期五為實戰經驗分享,初期會談需求分析,稍後會有測試管理
  • 星期六預留為嘗試解答一些項目管理上較難的問題
  • 星期日為休息日,也預留作調整及學習

2020年2月22日星期六

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

2020年2月21日星期五

需求分析入門 - 電子表格

前一篇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 較可取
  • 避免用戶不小心按錯而離開頁面,加入一些離開頁面的提示訊息
另外,現有紙張表格可能出現多處要求填入重覆資料的情況,這可能是因為多年沒有整合表格而造成,當中申請按揭應該是我看過最差的例子,很多頁的表格,不停重覆要填寫姓名及其它個人資料,轉用電子表格的時候,可一併考慮將這些欄位合併,由系統邏輯把資料分配到需要的流程上,就不需用戶重覆輸入了。

2020年2月18日星期二

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

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

曾經在一間大型機構裏參與一個巨型項目,事實上項目本身並不巨型,或者說可以有很多方法令它不致變成如此。純粹是一個產品平台的換代項目,不過經歷多次人為影響,一個平台換代項目竟然要整個機構差不多一半的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 繼續整理。

2020年2月16日星期日

新的開始

說了很多年想要開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. 長遠投資於科技公司的考量