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

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