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