敏捷方法的成功密技(十八之二):如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案(中)

敏捷方法的成功密技(十八之二):如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案(中)

(Photo by  Parabol | The Agile Meeting Toolbox from Unsplash

二. 階段式方法

看到前一篇文章提到的瀑布式方法的缺點,我相信多數組織都可能感同身受。接下來的問題是,組織當中有沒有人有膽識、有魄力,而且還有權力可以推動專案管理的改革。

很慶幸地,本案例的公司就有這樣有遠見的主管群。該公司的主管們痛定思痛、下定決心去做專案管理的變革,開始採用階段式開發方法。整個流程大致演化為像下圖這樣:

這樣的方法緩解了相當大部份使用瀑布式方法的痛點,例如,

1. 功能團隊之間,很快可以開始同步工作,專案的時程可以相對縮減不少。

2. 客戶開始有機會在每個階段結束就先看到一部分成果,可以有機會建議或要求做些變更,滿意度得到明顯的提升。

3. 功能團隊之間的溝通頻率增加,質量變好,技術與知識在組織內有更好的擴散和傳播,對產品設計的誤解減少,重工的情形也變少。

當然,要達到上述的成效,組織其實是付出不少代價的。例如,該公司就花了不少錢,多採購了幾套 FPGA 模擬器,以讓 IC Design 團隊和 FAE 軟體開發團隊可以同步工作。

這樣的結果是,最新設計出來的硬體邏輯電路,和最新的客戶端應用軟體,就能盡量無時差地、高頻率地整合和測試,以便早期發現問題,早期治療問題,大幅減少重工的成本。

此外,還有一個代價就是,組織內同仁的工作習慣也得做相應的改變。例如,以往不同功能團隊之間所需的溝通比較少,而階段式方法卻需要比較頻繁的、密切的,人和人的溝通,這對於平常大多只需跟電腦溝通的研發人員來說,可就是一個不小的挑戰了。

這種階段式方法,對許多組織來說,確實可以因應多數的業務需求。但是,在產品需求日益複雜、變化日益快速的今天,階段式方法其實已經顯得有點力不從心,捉襟見肘,這也就是為什麼許多組織開始感受到壓力愈來愈大的原因之一。例如,

1.專案團隊成員之間的本位主義仍然相當常見,非常不利於團隊績效的進一步提升。

2.專案的進度仍然難以被確實掌握,專案延誤仍然常見,加班趕工的情況依舊相當嚴重。

關於第一個問題,多數實施瀑布式或階段式開發方法的組織,不是沒有明確指派專案經理,就是隨意在某個部門找個人來當專案經理,而這樣的專案經理根本就沒有得到組織高層的授權,是很難叫得動其他單位的人,配合專案的節奏做事的。

這樣的專案管理方式,團隊成員間的凝聚力,和共同成就專案的動機皆較為不足,功能單位主管也多半會以自己單位的利益為優先考量,來安排部屬的專案工作和優先順序,因此也就常會和專案的利益有所衝突,造成本位主義氾濫的現象。

關於第二個問題,在《敏捷方法的成功密技:專案管理的「溝通斷層」》一文當中我曾經探討過,多數產品功能實作人員所認知的「需求」,和客戶/用戶的原始想像,其實早就已經「失之毫釐,差之千里」了。

因為,在客戶/用戶把腦中的需求,也就是「想像」,用文字或圖形轉換為文件的過程中,「需求的細節」其實早就已經一點一滴地消失或模糊掉了。也就是說,根據文件來打造產品,本來就不太可能讓客戶/用戶感到滿意,隨之而來的大量需求變更和痛苦的重工,當然也就再所難免了,而專案團隊通常都會把這種情況歸咎於「客戶為什麼都不先講清楚?」。

此外,根據國外的研究,以及我自己帶領研發團隊和管理專案的經驗,人腦對於時間的估算真的很不擅長,尤其是要對那些從來就沒有做過的專案工作來說,時間的估算,尤其困難。

如果某個新功能是與過去做過的某個舊功能類似,那麼,開發人員還能用比較或對照的方法,做出較為精準的時間估算。如果不是這樣,其實,開發人員也都只能用「猜」的,而且,這種猜測,還是在沒有跟客戶/用戶討論的情況下,自己瞎猜的。你覺得,這樣還有可能會估得準時間嗎?

 

原文轉貼自:威廉網紙(原文連結)

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。