軟體專案後期的變更會讓團隊無法按照既定計劃進行,然而因應現實需求變更又勢在必行時,我們又該如何取捨呢?學長喲哪桑在〈Late Changes Can Be Good〉提出我們必須認清專案初期的需求規格永遠是不完整的事實,因此好的經理面對專案後期變更應該要懂得取捨,發展出良好的適應變更的機制。他提到:
大家都不喜歡 Late Changes,我也不例外。不過,也不要有受害者的心態,把 Change 當做誰的疏失、誰的錯誤、是誰害的。我們還是得認清事實,就是專案初始時的需求規格永遠是不完整的。
好的機制,是要讓產品專案能夠快速應變,而同時間又能把品質的傷害、生產力的影響降到最低。
好的 manager,要懂得取捨。Late Changes Can Be Good.
學長所提的觀念其實並不難理解,但依據同人實務上的觀察卻發現,在面對壓力時,專案管理者往往無法做適當的取捨。理想上,大家都會以為加一點東西、做一點小改變,程式應該不會有什麼問題才對。但事實往往是「千金難買早知道,萬般無奈想不到」,改變對軟體品質的傷害、生產力的影響總是超乎我們的想像,更可怕的是變更所造成的災難似乎永無止盡。當初取捨時的樂觀,事後我們才會發現那其實是無知。
就拿同人在〈沒有說出來的衝突〉中所提到的故事為例。某個專案在面臨即將驗收之際,一些開發者因為專案的壓力而不遵守修改紀律時,該專案的管理者以為應該不會發生太大問題也沒有予以糾正,但結果卻讓專案失去了控制。經歷過這次經驗及教訓,他分享了他的體會:以放縱不遵守紀律來因應變動需求其實是不智之舉。而從他的經驗我們不難發現到,人們總是習慣高估了自己的能力,低估了風險。因此,在做出自認為臨機應變的取捨之前,不妨先想一想,我們憑什麼認為這次的變更是個好變更?
理論上,依據《專案管理知識體系指南》(PMBOK)的指引,我們可以找到在專案的範疇、成本、以及時間變動管理必須注意的共通要點,以確保專案在變更過程中能夠確實因應實際變化,包括了:
- 確認變更對專案有正面的影響。
- 確認造成變更的因素已經發生。
- 管理變更。
這也就是說,好的變更必須反應專案實際現況、並對專案有實際助益、同時必須要是可管理的。因此,如果只是想到什麼就做什麼並不是好的變更。因為那代表我們對專案變更的想法只是停留在觀念階段,我們必須找到客觀資料來證明它是可行的,然後再進一步地發展出具體可實踐的方法。否則專案將充滿著許多未知的不確定性,將很容易讓專案陷入危難之中。
《孫子兵法》說:「多算勝,少算不勝,而況無算乎!吾以此觀之,勝負見矣。」如果我們發現了變更會帶給專案實際助益,更需要週全的可行計劃來確認它是可以被實現,這才是專案的致勝之道呀。然而,具體做法又是如何呢?同人認為必須客觀而穩定地觀察專案現況,並依據客觀資料來分析變更將對專案所造成的影響。然後再進一步因應實際問題來調整計劃,以做採取行動的有效控制基準。
因此,不須把問題推到收尾巴過程才來解決,也不用在此黑暗時期讓無窮無盡的壓力來讓我們喘不過氣。只有在當我們懂得面對變化不斷地對計劃進行調整時,這才是真正的認清事實。
「菩薩畏因,眾生畏果」,變動所造成品質的傷害、生產效率的低落的苦果往往是因為我們太重視執行結果,卻忽略了規劃與控制的過程。如果我們不懂得專注於過程中,把注意力放在因應變化來進行可行計劃的調整上,我們將很難判斷這次的變更結果是否會造成下次變更原因。過程對了,結果自然就不會錯。雖然 Late Changes Can Be Good,但好的變更也必須是來自於可行計劃呀。
Powered by ScribeFire.