如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案(中)


    [上一篇]

    階段式方法

    看到前一篇文章瀑布式方法的眾多缺點,我相信,大多數的組織,應該都感受得到這些痛點!接下來的問題是,組織當中有沒有人有膽識、有魄力、有權力,去推動專案管理的改革!

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



    這樣的方法緩解了相當大部份瀑布式方法的痛點:
    1. 功能團隊之間,在時間軸上開始可以部份重疊地同步工作,專案的時程相對縮減了不少。
    2. 客戶開始有機會在每個階段去建議/要求做些更好的功能變更,客戶滿意度得到了明顯的提昇。
    3. 功能團隊之間的溝通質量變好,溝通頻率增加,技術與知識在組織內開始有更好的擴散傳播,對產品設計上的誤解減少,重工的情形也變得較少!
    當然,要達到上述的成效,組織是需要付出相對應代價的!

    例如,花大錢採購多套的 FPGA 模擬器,以讓 IC Design 團隊和 FAE 軟體開發團隊可以同時並行工作,讓最新設計出來的硬體邏輯電路能夠與最新的客戶端軟體,盡可能無時差、高頻地整合與測試,以早期發現問題,早期治療問題!

    另外,組織內同仁們工作習慣的相應改變,也是當初做此專案管理變革時的巨大障礙之一。例如,以往不同的功能團隊成員之間的溝通比較少,而階段式方法卻需要比較頻繁密切地跨團隊溝通,這對於以研發人員佔大多數的晶片開發專案團隊來說,可是相當難以調適的一個部份,也是各功能團隊主管領導能力的一個挑戰。

    這種階段式方法是目前大多數組織所採用的方法,對許多組織來說,也的確已足以因應其目前的業務需要。但是,在產品需求日益複雜、變化日益快速的現今環境之下,階段式方法其實已經有捉襟見肘,不堪負荷之勢,這也是為什麼很多組織開始感受到強大競爭壓力的主要原因之一。以下就是個人認為最常見卻仍未能靠傳統式專案管理來得到良好改善的幾個問題:
    1. 專案團隊成員之間本位主義的情形仍然相當普遍,不利於團隊績效的進一步提昇!
    2. 專案的進度仍然無法可以被精準確實地掌握,因為專案的延誤而導致的加班,情況依舊嚴重!
    關於第一個問題,大多數施行階段式開發專案管理方法的組織,其專案團隊的屬性多半仍屬於弱矩陣型(專案經理沒得到太大的授權),甚至仍為單純的功能型(沒有專案經理的角色或是僅由某單位主管掛名卻無執行專案經理職務之實)。這兩種類型的專案團隊,成員之間的凝聚力和共同成就專案成果的動機皆明顯不足,功能單位主管仍為專案團隊成員工作安排與績效考核的主掌角色。也因此,專案團隊成員之間本位主義的情形仍然相當普遍,當然不利於高效團隊合作的發展!

    關於第二個問題,在《敏捷方法的成功密技:專案管理的「溝通斷層」》一文當中曾經探討過,多數的產品開發實做人員所認知的「需求」,其實早已在「從客戶/用戶的腦海中轉換為需求文件」的過程當中,被層層誤解、漸次弱化掉其原始目的了。所以,客戶/用戶在使用(或試用)團隊產出的功能的時候,往往很難能盡如人意!也因此,大量的「需求變更」(因為開發者通常會把這種情況定義為「客戶沒講清楚」)和伴隨而來的痛苦重工也就勢所難免了!

    除了因為對於需求的認知落差所導致的「額外」工作量之外,根據國外的研究,以及我自己實際帶領研發和專案的經驗,人腦對於工作時間的估算其實也真的並不擅長,尤其是要對一些從來就沒有做過的工作來估算時間之時,尤為艱困!

    除非是過去曾經實做過類似的功能,開發人員還能夠用比較對照法,來較為精準地估算新功能所需要的時間之外,其他多數的產品功能,實做者只能用「猜」的來估算工時,而且還是在沒有跟客戶(或用戶)實際互動討論的情況之下去猜的!這怎麼可能可以估得準確?

    [繼續閱讀]