專案末期的真實開發成本?


延伸閱讀:Feature Request, Or Bug Fixing?
        前一陣子忙到翻天,我手上的系統距離正式上線不到一個月,現在正進行 UAT 的 Cycle 2。所有該到位的功能性需求都到位,總算追趕上進度。今天我把同事本階段 TODO List 內最後一個項目槓掉,一切都進入收斂的階段。

        儘管到了 UAT ,針對同事負責的 Web UI 這塊,每天下午的 UAT Review 會議由使用者提出突發奇想的意見還是蠻多的,除非只是單純畫面呈現的調整,只要是牽扯到程式邏輯與流程的一丁點變動,幾乎都由我這邊阻擋掉。

        無論是我同事或是客戶,似乎都對變動的總體成本沒有正確的概念,事實上,實際的成本總是他們預估的四倍以上有餘,更不用說一開始就估計錯誤的話。帶回 CR 的同事曾說過這樣的話:他們這個需求很簡單,我最多只要花半小時就搞定了,為何要浪費一個小時在會議室跟他們爭論?


        這真的是對成本估計嚴重的誤解。



  當進入專案尾聲,雖然開發已經結束,但實際上我們的測試進度不如預期,為了系統的穩定性,應該盡可能把所有的心力與資源放在測試工作上。當開發人員認為只需要半小時就可以開發好的東西,至少還需要花半小時做單元測試與驗證的工作吧?這代表不但多花了一個小時幫客戶做了對公司沒有收益的事情,也代表你少了一個小時進行原本該負責的測試工作,這樣的來往之間,就該名開發者的個人生產力而言,整個專案的損失是 2 小時。


        再來我們看看,UAT 是有六到十人的客戶使用者一起進行測試工作,當你要將完成的需求過版上到測試機,意謂著所有測試人員必須暫停手邊的測試工作讓你更換版本,如果只花了十分鐘換新版,這些測試人員就損失十分鐘的操作與測試時間,六個線上的測試人員就代表整個專案的測試進度又損失了一小時。


        新的功能部署上測試機後,客戶的使用者測試人員需不需要驗證?當然要,這等於增加他們的測試項目,每個人就算只要多花十分鐘操作新版的這個小功能 ( ),等於整個專案的測試進度又比原先預期中的損失一小時。


        總計下來,開發人員原本以為只要 30 分鐘可以搞定的事情,實際上以最樂觀的想法總計下來對整個專案造成的時間損失是 4 小時,是他原本預估的 8 倍!光這個倍數的落差就夠驚人的了,更遑論如果開發人員不小心錯估所需的開發時間 ( 是啊,PG 總是以天性樂觀聞名 ),那這場災難會有多可怕。

        除非客戶本身對開發一竅不通,可以讓你隨便唬爛拒絕需求,不然客戶若有專業的 IT / MIS 單位負責坳開發廠商,通常會說:這小調整哪有那麼複雜,若我自己做頂多花半小時就搞定,不過是資料庫加開一個欄位,還是程式邏輯多個旗標判斷一下就好了而已。


        很多新科 PM 跟客戶交涉,遇上對開發稍有經驗的客戶,大多最後就摸摸頭回家去鞭打工程師做了。

        沒辦法說服客戶的關鍵在於:大家都只把焦點放在開發活動的時間上,要認清的一個事實是,開發活動其實本來就只是軟體專案總成本的一小塊,要考量它衍生出的其他成本才是全部!


        在專案末期與專案初期,開發活動所造成的總體成本估算差異是天差地遠的,初期沒有甚麼衍生成本,但後期當測試工作已經開始,許多文件都已經開始製作時,若還抱持著開發初期的那種成本認知,持續著一個又一個失敗的專案的命運的確是應得的報應

  註:同事帶回的是 UI 的 CR,由於 UI 捉摸不定的使用者特性使然,其相關測試決不是隨便花 10 分鐘測試就可達成。一個工作也許在畫面上連續操作三個功能可以達成,代表相關功能的各種操作情境高達 3! = 6 ,共有 6 種不同排列組合的 Test cases。但是如今多安插了一個功能,這代表 4! = 24 瞬間爆增為 24 種不同排列組合的 Test cases。如果真要達到高密度的完整測試,除了之前測過的要重測之外,決不單只是比原本多花 10 分鐘來測某個單一的新功能而已,而是為了這個單一的新功能,工作項目是以階乘的方式爆增數倍。上述多 10 分鐘的例子真的已是掩耳盜鈴的偷工減料測試法。


        延伸閱讀:喲哪桑的 Feature Request, Or Bug Fixing?

        UAT : User Acceptance Test 使用者接受度測試
        CR : Change Requirement 需求變更
        UI : 使用者操作介面
        PG : Programer 程式設計師

熱門文章