我承認,標題下的很果斷,但是我覺得我必須將事實說清楚,讓不懂軟體開發的管理者能夠知道為什麼會失敗,也讓想這樣作的管理者知道,失敗只是必然的事
我承認,標題下的很果斷,但是我覺得我必須將事實說清楚,讓不懂軟體開發的管理者能夠知道為什麼會失敗,也讓想這樣作的管理者知道,失敗只是必然的事
故事必須從大約15年前開始說
當時的資訊產業在全球各地開始一片火熱,各大大小小的軟體開發公司也如雨後春筍般的成立,並開始製作各方面的軟體
以軟體開發來說,必須經過幾個階段,軟體才能完成製作,這個流程以萬惡的瀑布式開發的描述方式,依序為
需求訪談==>系統分析==>系統設計==>程式開發與製作==>系統測試==>驗收
當軟體製作公司在經歷了上述一連串的工作,並累積了許多專案的經驗之後,發現在這些階段中,程式開發與製作似乎是花費專案中最多人力與時間的一個階段.
但是花費了這麼多成本,時間與人力後,開發出來的程式卻一直被測試人員或是客戶在驗收階段中被打槍,因此必須投入更多的人力進行程式的修改與開發.
管理者在此時開始思考,為什麼開發軟體會需要花費這麼多的成本,尤其是在程式實際進行開發時,投入的成本遠比其他階段更多.當然,問題說不定並不出在程式開發人員的程度差,有可能是需求訪談時就誤會了客戶的需求,導致後面的階段作白工,也有可能是在系統設計上出了問題.
anyway,這些又是另外的議題.
管理者在不確定這些問題的因素下,想要將開發成本作cost down的動作,所以就冒出了一個程式碼開發outsourcing(委外)給其他公司,或是個人工作室進行開發的動作,也就是說,公司的員工本身只負責進行需求訪談,系統分析,與系統設計,至於程式碼開發的動作,就交由其他公司的人員進行製作,待製作完成後,再送回公司進行測試的動作,有問題再請委外的公司進行修改,而公司只要與委外公司簽訂定額的開發合約即可.
在這樣的合作模式下,看似彷彿一切都很合理,公司將程式開發階段所花費的成本降低了(因為與委外公司簽定訂額合約),公司不用聘請程式開發人員,照理來說應該可以大大的降低成本的開銷,但是,我想問的是,真的成功了嗎??
在針對各項問題點進行分析前,我先來說個有趣的例子
大約在2002年左右,筆者所工作的公司,老闆也有著相同的想法,就是將程式碼委外到其他公司進行開發與製作,而當時最熱門的,就是委給印度的公司作程式碼的開發,所以老闆當然也找了兩個印度工程師來進行開發動作啦,不過不到兩個月就宣告失敗,為什麼呢?理由很簡單,就是
我說的英文他聽不懂,他說的英文我聽不懂
真是個他媽的簡單的理由,但是卻也一語道破軟體開發的一項重點,軟體開發是需要專案團隊成員密切與緊密的溝通的,一旦沒有明確的溝通,想要順利完成軟體的開發幾乎是不可能的一件事.
但是,我想說的,不止是語言的問題
台灣委外給印度,與美國委外給印度,是兩種不同的工作模式!
美國與印度剛好是在兩邊不同的半球上,美國人白天編寫規格時,印度是半夜,當美國公司下班,系統分析師與系統設計師透過email寄出規格到印度公司的信箱時,印度公司才正準備要上工,而當印度委外公司完成了當天所開立的規格並下班後,美國才剛準備要上班呢,所以對美國公司來說,我只不過是晚上寄出程式規格,睡一覺醒來程式就作好了,這是他們先天上的優勢,且在語言的溝通上可能比較沒有問題
但是反觀台灣,與印度的時差是-2,也就是台灣人下班後,再過兩小時印度也下班了,對專案執行來說,並沒有擁有時間上的優勢
當然,這只是眾多例子中的一個,失敗的原因百百種,我相信這只是冰山的一角,因此,讓我從頭開始說起,為了節省成本而將程式碼委外將會失敗的原因
1. 委外規格文件不完整
很多人會對這點質疑,既然已經委外了,文件當然要作完整,不然委外公司怎麼能夠瞭解要作的內容?
其實答案很簡單,就是規格文件作的詳細度夠不夠.
今年已經2012年了,軟體開發的複雜度已經不是以前只要懂得C++就可以搞定一切的世界,光ASP.NET來說,就有ASPX(頁面),ASCX(使用者控制項),ASMX(WEB服務),HTML,XML等等等等的,光設計一個頁面,文件可以只說明在頁面上放置一個文字方塊與按鈕就可以了事的嗎…我可不這麼認為,光把頁面與使用者控制項之間的互動關係說明清楚,再將頁面設計中控制項擺放的位置說明好,我想系統設計師應該會想直接把UI拉好給工程師作比較快
如果真的要落實系統設計師將文件交給委外工程師進行開發,那系統設計師勢必要花費3~5倍的時間在製作文件上,而委外的工程師也必須花費3~5倍的時間來閱讀,這樣真的有達到成本降低嗎?
系統設計師花費3~5倍的時間在製作文件上,意謂著工時增加,工時增加代表成本增加,我想即使不是管理者,也都很清楚這一點吧
2. 需求變更的修改不易
軟體開發可不像蓋房子一樣,軟體開發作不好是很容易就打掉重作的,所以當委外的程式開發完成後,在驗收或是測試階層時發現必須要修改需求或是更改開發的架構,試問,由誰來進行修改動作?
通常來說,是由委外公司進行功能的修改,一般都會在合約中有簽訂相關的事項,但是又會回到問題1上,系統分析師與系統架構師必須將那厚厚的一疊文件拿出來作修改,修改完再告知委外公司進行修改,相對一來一往的時間就會是相當的費時費工,更別提到需求訪談與系統分析若是沒有作好時,系統變更的項目是多到信箱滿出來都改不完的.
3. 後續維護不易
既然公司將程式開發委外了,公司留下的程式開發人員應該就不會太多,當有案子客戶驗收後,但是在往後的兩三年保固期內,有需要進行修改動作時,可想而知的是,那位苦命的程式開發人員必須在短短的幾天,甚至幾小時內將那本厚厚的規格書讀完,並找出問題修復它,或是更改它的功能,若是遇到文件內容不完整的情況下,那我也只能請那位程式開發人員看開點…
4. 軟體版權問題
當委外公司完成了軟體的開發後,該軟體的擁有權與使用權為何,通常在合約中會有說明,但是如果沒有附上相關的條文,那意味著委外公司可以拿這套軟體進行商業行為,由原本的合作夥伴變成競爭對手
5. 委外公司報價高於員工薪資
近年來,由於大陸的掘起,所以有許多的公司也打算由原本委外給印度的方式,再度嘗試委外給中國大陸,但是這時就必須考量到委外成本的問題,雖然說台灣與大陸在語言溝通的問題上比較不像跟印度一樣那麼大,但是往往對方報價的費用比起自己公司聘用一位程式設計師還來得高,在這種情況下,委外是否就顯示很不划算?
6. 軟體開發極為著重溝通
由於軟體在開發上的複雜性越來越高,系統分析師,架構師與程式設計師彼此之間面對面的溝通就變的相當的重要,且時間也相對的變的較為長,若是委外的成本與公司聘用程式開發人員差不了多少,那為什麼不任用程式設計師在公司工作,員工彼此之間的溝通與專案成員的互動也較為密切.
我相信,失敗的原因絕對非常的多,但是我只是簡單的舉了幾個顯而易見的例子,來說明為什麼程式碼開發委外會失敗的原因,當然,我相信也有成功的例子,但是成功的方向不全然是在成本降低上,而是順應公司政策的變更,付出較多的成本,以達到程式碼開發完全委外的目的,但是若是站在cost down的角度來看,程式碼開發outsourcing,失敗只是必然的
