我曾經接手一個大型網路專案,當時專案距原定上線日已經延遲半年多,由於該網站是老闆殷切期盼的產品,從理念生成到正式開始規劃也已超過兩年,若加上開發時間,等於是苦等了三年以上還沒看到結果,因此全公司都伸長脖子看著它何時能真正被落實成產品。由於這一層關係,讓專案本身增添了縮短上線時程的壓力,但專案內部卻還有不少問題等待處理,如果你是PM,應該如何應對?
先將場景從現實拉到電影【寒戰】的世界內,在第一集中,郭富城飾演的警務處長劉傑輝在苦思找不出兇手及內賊的情況下,用有違既定程序(匿名通報廉政公署介入調查,並讓自己成為被調查的嫌疑犯)的方式引對方上鉤,用的就是保安局長(劉德華飾)提醒他的「非常時期用非常方法」。在專案管理的思維中,我們被教導善用經驗、工具與資源,一切都是有憑有據,當專案延遲,最直接的想法必然是增加資源或工時,再不然就是變更範疇讓產品能盡早通過品質檢測。但我們也知道軟體專案最大的迷思就是人月神話(註1),尤其在產品開發後期,增加的人力絕對無法帶來及時的幫助。此時,專案背負老闆期望(時程不能變)、產品也已經多數進入收尾的段落,加上其規格複雜,牽一髮動全身(範疇不能少),甚至連人力都短缺的狀況下(資源不增加),還能做些什麼?
(相關文章可以查看寒戰的戰略思考)
軟體專案的周期內,包含了企劃、設計、開發、內部測試、產品驗收、上線等幾個重要的階段,其中「內部測試」在專案管理的分類中屬於「範疇驗證」的一環,也就是當交付標的完成時,必須先經過團隊內部的檢視,確保與專案的範疇一致。經過範疇驗證後的產品,再送交品保團隊進行「產品驗收」,如功能測試、壓力測試、弱點掃描等關卡,確定其錯誤率低於一定數值後,才能正式對外發布。但完整的產品驗收過程冗長,對於創新研發或者有時程壓力的專案來說,絕對是一個影響期程的關鍵,於是我們決定讓專案的驗證過程採用滾動式進行,也就是將預期交付的產品拆分成不同的單元,先開發完成的單元先進行檢測,並且讓內部與外部的驗收同時、分梯次進行。例如產品共包含A、B、C... J十個單元,當A單元通過內部測試後,便交給品保團隊進行驗收,專案團隊則繼續進行B、C...J的內部測試,等到全部單元都通過驗收後,再針對產品做一次整體性的品質驗證。這個做法與公司內部的運作方式不同,卻是一個爭取時間的方式,避免內部測試與產品驗收兩個階段分開執行而延誤了整個專案的上線日期。
不過,非常方法的執行總是有風險的,一旦成效不如預期,或者即便達成目標卻衍生其他風險,便有可能成為被放大檢視的目標,因此,在【寒戰2】中我們看見劉傑輝遭受司法調查,被資深律師簡奧偉質疑濫用職權,「即便非常時期都不能用非常方法」簡奧偉這麼說。
從電影中我們也可以看出,簡奧偉並非執意挑劉傑輝的毛病,而是希望透過強勢的質詢方式逼出事實。儘管辛苦不被肯定,但若遇見理性的監管者,對PM來是還是一件值得慶幸的事,至少對方也是出自於善意,只是雙方對於執行方法有不同的見解。在我前述的那一個專案裡,最後很可惜受到前人遺留的技術債(註2)影響,沒能透過滾動方式縮短驗證時程,並且被CIO以重工的理由駁回重新進行內部測試。專案的重整並非壞事,最後不僅老闆重新編製資源,CIO也直接掌管技術團隊,更有趣的是,後來的品質驗證模式,也是採用相似的方式進行,這便代表著當時的決策並非錯誤,只能怪當時團隊準備還不夠充分,還沒到最佳的執行時間。
到底非常時期能否使用非常方法!? 這並不是一個有標準答案的問題,真正的關鍵在於企業文化是否鼓勵創新思維? 是否賦予團隊足夠的決策權? 假如企業內部分工細緻,彼此有一套固定的運作模式,而專案又屬於跨部門性質,那麼執行過程便會有許多「眉角」必須先了解,避免誤踩了其他部門的地雷區。與跨部門協作順暢,當非常時期到來,才有本錢與對方討論非常方法的可能性。如果專案團隊沒有實質的決策權,就很難打破既有的工作流程,除非專案團隊本身包含了產品週期的不同角色,可以一手包辦全部流程,否則,終究還是得尊重不同單位的作業方式。
註1 : 人月神話,知名的軟體專案管理著作,作者Frederick P. Brooks, Jr. 。主要是闡述多數人對於「人月」的迷思,以單純的人月方式來計算專案所需資源與時程是有風險的,因為軟體專案的人力投入,還必須考量人員的學習曲線、難易度等。
註2 : 技術債, 指開發人員為了加速軟體開發,在應該採用最佳方案時進行了妥協,改用了短期內能加速軟體開發的方案,從而在未來給自己帶來的額外開發負擔。這種技術上的選擇,就像一筆債務一樣,雖然眼前看起來可以得到好處,但必須在未來償還。
文章標籤
全站熱搜
留言列表