專案外包的衝突與兩難–到底什麼是需求變更

一份軟體的規格書,包含了白紙黑字的規格和Common sense,譬如說好了,註冊功能是屬於需要白紙黑寫在規格書上,但註冊時使用者要輸入兩次密碼以作確認,就是屬於commone sense的範圍,通常不需要寫在規格書上,外包商也應該實作給客戶。

但是問題就出在,客戶認為理所當然的事情,外包商可能會因為文化、背景與domain knowledage的不同,造成對common sense的理解不太一樣。舉個例子來說,簽約時只提到登入功能,但是客戶的common sense可能還意謂著可以用Open ID來做登入,但是外包商的common sense可能就不含這項功能。

理想的軟體外包專案,外包商和客戶對Scope的認知,其收斂過程應該就跟下圖一樣,隨著時間的經過,產品也慢慢做出了雛形,雙方各自的common sense,也會依照技術可行性、商業目標…等外在條件,順利的收斂並結案。

但在這收斂的過程當中,有非常多的issue會產生,諸如:

  • 客戶到了測試階段時,才發現外包商deliver的產品和自己的預期落差相當大。因為整個專案在進行的過程,雙方在common sense的溝通上,相當的不足,造成在設計與實作階段,雙方的認知幾乎都沒什麼收斂(如下圖)。而且往往在最後要結案時,才開始急速收斂,但是雙方也會因此產生很大的不愉快,造成雙輸的情況。

  • 外包商在deliver後,客戶開始進行測試時就根據著客戶自己的common sense,發了一堆不在規格書中,但又不算是bug的issue,例如:在表格中增加排序的功能、在輸入手機號碼的欄位限定只能填數字、要把相片覆蓋前要有提示…等,而且客戶非常堅持這些本來就是該做的,但是外包商在deliver後,接受這些客戶提出的issue,人力成本與機會成本已大大提高,不可能永無止盡的吃下來。
  • 客戶認為應該要含括在專案裡面的common sense,外包商卻認為當初簽約時沒提,所以要額外收費,但是客戶卻會認為,外包商做這些理所當然的功能竟然要另外收費,是一件很不可思議的事情。

由於這樣的common sense很難有辦法在專案開始之前就白紙黑字的定義下來,即使是在開發過程當中有著密集的溝通和demo,雙方也對規格書作簽名確認的動作,還是會遇到這種對於common sense的認知落差的問題。所以就筆者經驗來說,這這就只能訂立一些「事前的協議」和「事後的談判」的原則來做處理,而所謂「事前的協議」和「事後的談判」的原則各是什麼呢?筆者各分述如下:

事前的協議,指的是在不同的時期,外包商針對超出認知範圍的common sense,有不同的接受標準,例如:

  • 在設計期間,採取寬鬆的態度,雖然客戶的common sense可能不落在外包商的認知範圍內,但只要在合約中沾到邊的,且大部分同業產品(可以請客戶先行列出參考同業)也有類似功能,都可納入專案Scope。
  • 在測試期間,採取較嚴格的態度,針對落在外包商認知範圍外的,已不和客戶討論是否應該涵蓋在scope內,而是開始進行所謂的「事後的談判」了。
  • 常被忽略的一點,就是外包商和客戶之間,沒有做好將設計期「Close」的動作,讓客戶以為外包商還處於寬鬆的認定方式,造成雙方的衝突。

事後的談判,指的是當事前協議無法涵蓋時,就得進行事後談判,筆者有些想法可以給大家在談判時作為參考:

  • 外包商對於超出任之範圍的common sense,是否要承接,要以是否合乎自己機會成本和未來利益作為退讓的考量。
  • 在事前協議的時候,應該先請客戶定義好幾個reference site,可以做為在common sense有爭議時的依歸。
  • 外包商根據此一需求對客戶的重要性來作退讓,也就是說雖然超出外包商認知範圍,但是因為這功能對客戶太重要,外包商為了客戶滿意度,還是應該忍痛吃下來。
  • 在事前協議的時候,外包商就承諾會贈送客戶額外的一段工時,實作所有超出認知範圍的common sense,做為妥協條件。
  • 外包商若還是必須得承接認知外的功能,也可以選擇將認知外的功能包成一個package,和客戶爭取延後交付的妥協。
  • 客戶也應該考量自己的商業目標,必須在「爭取單一外包案最大利益」與「Time to Market」之間做妥協,不要陷入和外包商爭取那一丁點利益,而失去最寶貴的上市時間。

在管理common sense這一塊領域上,客戶和外包商之間的利益是衝突的,雙方在交手的時候,真的是藝術成份居多。筆者也在前文提到,外包商必須要把自己當作服務業,不只交付產品,在整個交付產品的過程當中,也要能服務客戶的心,創造客戶的滿意度,如此一來,才能算是一個雙贏的外包專案啊!

留言