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的產量,也留多一點時間學習多點新知識後再恢復。