這幾年認識許多軟體創業的朋友，他們在找尋不到合適的技術合夥人且自己不懂程式的狀況下，會轉向委託軟體外包商開發產品，可是軟體外包涉及的層面非常廣，如果沒有外包的經驗，就算是專業的軟體公司也很難與外包商磨合，更別論沒有資訊背景的朋友了。

軟體外包有著靈活性、開發速度快、降低成本、整體解決方案、不受專業知識限制等優點，不過談到軟體外包，許多人的印象總是｢失敗率很高｣、｢無法掌握開發項目｣或是｢沒有合適的外包商｣等負面觀感，其實這些負面觀感是來自於｢沒有掌握軟體產品的規格｣、｢不了解軟體外包的合作模式｣與｢沒有建立確認（Validation）跟驗證（Verification）產品的方法｣，因為軟體外包商是根據客戶的需求來做開發，如果客戶自己都不清楚要開發的內容與規格，也沒有積極的互動，合作失敗當然是預料之中的事情。

我曾為一些朋友擔任軟體顧問工作，了解沒有資訊背景也沒有外包經驗的朋友在外包軟體時會遇到的困難，希望這篇文章能夠幫助更多有著創業夢想的人，了解軟體外包需要注意的重點，降低不確定因素。

附註：產品的創意與想法是否符合市場需求，不在此篇文章的討論之中。

• 首先要確認產品的可開發性

創業家總會有許多精彩的想法，但應該先確認想法具有可開發性，不然投入的成本可能就會浪費了。過去曾經受朋友委託開發一款自助旅遊的手機應用程式（Mobile App），這位朋友當時已經找了幾個創業夥伴與投資人，甚至還在市場投入了一些成本，不過在我詳細了解產品之後，發現許多重要功能是無法開發出來的，因為系統運算所需的資料大部份都不存在或是取得成本極高，所以這位朋友後來只好放棄這個想法，這樣的情況多發生在沒有資訊背景與資源的人身上。

針對這個問題，其實我們可以先把想法與資訊背景的人討論，不管是朋友、朋友的朋友、網路上的專家或是顧問等，盡量讓自己的想法經過專業的確認，而且通常這些人還可以給出不同的想法或是建議，而如果會擔心創意被抄襲，可以給一點諮詢費然後請對方簽署保密合約（Non-Disclosure Agreement）。

• 想想自己真正要的是什麼

軟體外包商能做的事情就是針對客戶的需求去開發產品，所以我們必須清楚的告訴外包商，開發產品的準則（Criteria）是什麼？這樣外包商才可以根據準則來做討論與發想，開發出真正符合客戶需求的產品。與準則相關的關鍵字有：安全性、穩定性、維護性、擴充性、可靠性、測試性、移植性、可理解性、可用性、互動性、執行速度、低成本、畫面美觀、甚至是「希望產品能夠賺錢」等都可以提出來，讓外包商知道客戶對於「成功產品」的主要定義是什麼，絕對有助於外包的成功機率。

• 該如何撰寫軟體規格書

針對軟體外包，都會在開發產品前撰寫相關的規格書，如軟體需求規格書（SRS，Software Requirements Specification）、系統開發說明書（SDD，System Design Document）、專案執行計畫書（PEP，Project Execution Plan）、系統測試報告書（STD，System Test Document）等相關文件。

撰寫軟體規格書是軟體外包最為重要的一環，有些人會認為撰寫文件浪費時間，在時間比較趕的情況下，會去忽略這個步驟，其實這是錯誤的觀念，因為撰寫文件的目的是要「有系統地分析產品所有細節」，所以越趕或是越重要的案件，更應該審慎地去看待這件事情，而且未來需要再「轉包」或是自己接手產品時，這些規格書將變為非常重要的「技術交接文件」。

不過一個沒有程式或是軟體工程背景的人，是無法自行撰寫以上的專業文件，甚至很難與外包商溝通文件的內容，我的建議是可以「先找軟體顧問撰寫軟體需求規格書（SRS）」。撰寫軟體需求規格書的目的在於「分析並產出客戶、產品與產品組件的需求、期望與限制」，有了這份文件便確認了產品的可開發性，也讓我們可以了解產品的技術需求與風險，而且我們可以用這份文件「快速地」去篩選合適的外包商。至於其他的文件，可以等找到合適的外包商後，再請他們依據軟體需求規格書（SRS）的內容去做分析與撰寫即可。

附註：一般比較不會請同一間軟體外包商撰寫軟體需求規格書（SRS）並開發產品，因為這樣有可能因為「球員兼裁判」而衍生一些利益問題，就像公司不會請同一個人（或是同一間會計事務所）同時擔任記帳與查帳的工作一樣。 

• 篩選軟體外包商的重點與方法

1.要能良性互動

在初步篩選外包商時，最重要的事情就是要能良性互動，因為客戶不見得具有專業知識，所以很難描述出產品需求，有鑑於此，外包商會不會積極展示相關技術或是利用適當的比喻讓客戶了解事情，增進討論的議題並減少溝通的落差，把客戶心中真正的需要、期望、限制誘導出來，是一件很重要的事情。

下圖「How Projects Really Work」便是說明缺乏溝通與良性互動所會發生的情況，雖然有點幽默，但這真的可能會發生。

（How Projects Really Work）

2.不要急著要報價，也不要只採用最低價

軟體開發需要分析的事項非常的多，在雙方還沒釐清所有問題之前，要求報價根本沒有意義。而採用最低價是一種極高風險的行為，低價格意味著將犧牲品質與時間，為什麼政府許多外包道路或建設工程的品質與效率始終這麼糟？答案就在於只採用最低標。此外，也不要把菜市場殺價的那一套用在外包商身上，因為這樣只會讓很多隱性的地雷埋進產品裡面。

附註：如果有請專業的人撰寫出軟體需求規格書（SRS），那便可以直接要求外包商報價，也不會遇到因為需求不明確，而造成不同廠商報價差異過大的問題。

3.經驗比技術重要

「技術」通常是我們考量對方能力的主要條件，但是真正影響開發速度與成功率的關鍵因素其實是「經驗」。我們可以試著想想，其實平時在執行或是經營事務時，多數會卡關或失敗的原因都是在於溝通、流程、人脈、資源與領域知識等問題，與技術較無關。此外，把重點放在經驗的另一個原因是，我們很難從外包商的作品展示或是幾次的對談就真正了解對方的技術能力，因為技術能力的驗證不是光靠「看」跟「聊」就可以了解的。

所以如果我們要做的產品是手機應用程式，在篩選外包商時，就專注找專門開發手機應用程式的外包商，不要因為對方得過網站開發與設計的大獎，就認為對方設計手機應用程式一定也沒問題，這是錯誤的觀念。

4.了解外包商的資源與人脈好不好

有時候產品開發到一半，我們會衍伸許多與開發產品無關的需求，而需要其他的支援，例如製作產品的DM或是網路行銷等，如果外包商本身的資源或是人脈很好，我們便不用再花寶貴的時間找尋與篩選合作的對象，而且因為是外包商本身的資源，所以也降低磨合的風險。

5.確認外包商目前的壓力狀況

也許外包商會在某個時間（點）負擔特別重，或是目前外包商剛好同時接下好幾個案子，我們要去了解外包商目前的壓力狀況，因為在這樣的情況下，外包商很難有多餘的人力與時間跟客戶好好一起討論事情與處理意外狀況。

6.外包商對你的產品有興趣嗎？

如果外包商對客戶的產品有興趣，他會｢主動且熱誠地｣去了解產品的細節，也會詢問與發掘產品的隱性問題，這將會大大的降低外包失敗的機率。

7.可以先嘗試合作看看

根據1-10-100 法則，專案在失敗時的修正成本比專案開始前的預防成本高一百倍，所以在無法評估外包商是否合適的情況下，我們可以先花一點錢，請外包商針對系統的主要功能，開發一個雛形或是設計一個畫面，經由初步的合作來評估合適度。例如我們希望開發一個高互動性的手機應用程式，我們便可以先請外包商使用一些簡單的設計（Layout）工具來做互動的展示與說明，以證明自己擁有這方面的能力與專業。

•  簽約時的注意事項

1.詢問提供程式碼要不要付費

要求外包商提供程式碼可能需要額外付費，這一點許多人會覺得訝異，這是因為有時候程式碼中會包含外包商自己本身的專業知識（Know-how）與技術價值，例如外包商開發某個功能使用了人工智慧的某個演算法解決了客戶的問題，或是程式碼中夾帶了外包商開發許久的函式庫（Library）等狀況，所以在這些情況下，若外包商將程式碼給客戶，也等同於將自己的專業知識與技術價值一併交出。

2.採用分階段付費

我們在事前沒有辦法去度量外包商正式開發時的積極度與態度，而且在與外包合作的過程中也許會有意外狀況發生，例如外包商產品開發到一半遇到旗下重要員工離職等問題，此時分階段付費便可減少傷害，我們可以依據產品開發的里程碑（Milestone）或是與外包商合作的不同階段（Phase）來分次付費，通常會分三至四次給付。

3.別忘了考慮著作人格權

著作人格權可分為公開發表權、姓名表示權及同一性保持權；著作財產權則可分為重製權、公開口述權、公開播送權、公開上映權、公開演出權、公開展示權、改作或編輯權及出租權。

在外包產品時，多數人都知道要簽屬保密合約，保密合約通常會包含著作財產權之歸屬，但不會包含著作人格權之歸屬，而依照著作權法規定，在沒有任何約定的情形下，著作人格權和著作財產權都是屬於受聘人（實際創作與開發的人），所以如果產品有申請專利或發表論文等考量，我們便需要注意著作人格權之歸屬，否則在著作人的掛名上便會有爭議。

一般來說，軟體外包商付出的是寫程式的「技術」而不是做「研究」，所以客戶要求著作人格權並不難。除非客戶需要開發的產品與技術目前不存在，而且也沒有提供外包商任何開發資料與方向，便要求外包商去研究與發展一個「創新的產品」，那著作人格權便較難爭取，不過如果是這樣的情況，我們去要求外包商放棄著作人格權其實也不太厚道。

4.軟體也有保固期

我們不太可能在驗收產品時，能夠完美的查看與測試所有與系統相關的介面、功能、運作環境與有害的風險因子。在接手產品後，我們可能會突然發現一些異常與瑕疵，所以要求保固是十分合理的一件事情。

保固期的協議與條件需要撰寫在外包合約書中，其長短通常會依據系統的運作時間或是使用者使用系統的時間來討論，例如我們委託外包商開發了一個會計系統，而這個系統一個月「只會使用兩天」，那我們就會希望保固期至少能夠半年以上；相反的，如果這個系統天天都有很多人使用，而且系統二十四小時都持續運作，那保固期至多只能談到一個月左右。

需要注意的是，若在保固期後才發現系統有一些異常與瑕疵，我們會比較沒有立場去要求外包商做免費的修改，不過我們可以在事前與外包商協議，如果在保固期後系統發生問題，需要外包商提供修改或維護的服務時，希望可以提供比較優惠的價格。

5.約定軟體教育與諮詢服務

軟體教育主要分為兩類，一類是軟體產品的操作，著重在介紹系統功能的使用，另一類是系統程式的講解，著重在技術人員的交接，不過如果目前沒有合適的技術人員可以辦理系統交接，可以與外包商約定交接的時限。

不管是軟體產品的操作或是系統程式的講解，雙方都可能會遺漏資訊，所以與外包商約定諮詢服務十分重要，通常會我們會與外包商約定三個月至半年或是一定次數的免費諮詢服務。

6.提供軟體使用手冊

軟體使用手冊是將系統所有功能的使用案例透過一步一步（Step by Step）的說明與圖示呈現，讓使用者能夠了解功能並正確地操作系統。如果系統很複雜或是使用者的年紀較大，軟體使用手冊的必要性就會非常高。

• 合作前的準備工作

1.建立溝通與驗證的管道

我們會希望外包商能儘快以及不斷地展示進度，讓我們能夠持續驗證他們在「做對的事情」，所以我們必須與外包商共同建立低成本與高效率的溝通與驗證管道，總不能要求外包商每隔幾天就派人來報告進度與展示成果吧！以此為目的，至少需要建立下列三樣工具

a.使用以溝通為核心的任務管理工具

與外包商合作是一人對多人，甚至是多人對多人的狀態，必須要讓所有人都能在第一時間掌握所有資訊，包含所有項目的負責人員、目前的工作進度與到期時間、每個討論事項與其結果、即時分享檔案等，多虧網路的發展，現在有許多的服務可以使用，例如Trello就提供了上述必要事項的所有功能。

b.使用視訊軟體

我們可以使用視訊軟體來輕鬆地達成對談與系統展示，甚至如果有技術學習的需求，還可以向外包商提出結對編程（Pair Programming）的需求，像是Google Hangouts便是一個很好用且容易上手的工具。

c.使用網路硬碟共享資料

外包合作會產生非常的文件與檔案，這些文件與檔案都需要能夠及時存取與共享，甚至需要版本控管，我們可以使用像是Dropbox或是Google Drive這一類的網路硬碟服務來達成資料的共享。

2.思考那些功能需要後台管理

如果本身不具有資料庫管理的能力，或是在短期之內沒辦法招募合適的技術夥伴來管理系統的資料，那就要好好的思考哪些功能需要實作後台管理。後台管理的需求需要在撰寫軟體需求規格書（SRS）時就列入討論，因為實作後台管理有可能會影響到軟體資料庫的設計。

3.了解需求變更的影響

變更「一點」需求，也有可能要付出極大的成本與代價，因為變更需求是系統性問題，需要追溯是否會變更到其他的需求、功能、流程或是專案進行的順序等事項，不是表面上看到的單一變更而已，舉個比喻來說，當蓋房子時，如果客戶提出想要把某根梁柱移動「一點」就好，結構技師的臉色應該會複雜。

不過在產品開發的過程當中，難免（絕對）會有變更需求的情況，所以我們在開發產品前，要先與外包商釐清需求變更的影響，在高成本、高代價或是高風險的事務上審慎考量，甚至提前想好解決與替代方案。

• 一些你可能不太了解事情

1.功能需要寫測試

應該沒人受的了系統三天兩頭就冒出Bug，所以要保證系統功能的可用性，就需要撰寫測試程式，例如若我們需要實作一個讓使用者登入的功能，為了確保登入功能正確運作，我們就必須撰寫該登入功能的測試程式，這道理就像是許多產品在出廠前要經過各種的測試一樣，而一個高可用性的軟體產品，花在測試功能上的成本，通常會超過實作功能的成本。

2.UI（User Interface）與UX（User Experience）是很專業的事情

縱使我有多年的開發與顧問經驗，也不敢說自己了解軟體介面的設計與使用者體驗的知識，在專業的事情上，請相信專家，千萬不要一開口就批評對方的設計，直接要求外包商依自己的想法去改，可以多多溝通，去了解每個設計的原因與原理，就會知道到UI/UX真的是很專業的事情。這道理就像一般人在沒有美術知識的背景下，常常會去質疑某些美術作品的價值，但是在具備了相關的知識後，反而會去讚嘆這些作品的偉大！

你會如何評論以下兩個作品呢？（於文章最後附註說明）

（雕塑家賈柯梅蒂的作品，作品名稱：指著某物的人，於紐約佳士得拍賣會上，以1億4128萬5000美元（約新台幣43.47億元）賣出　）

（名畫家畢卡索57歲（巔峰時期）時的作品，作品名稱：穿水手服的男孩與蝴蝶）

3.軟體產品的可維護性非常重要

房子蓋好就完工了，但是軟體產品是從開發好後才算正式開始要進行開發，因為軟體產品絕對逃不了要一直增加功能或是做改版，所以若從外包商手上接回一個維護性非常差的產品，縱使當下你非常滿意功能的展現，但這個產品還是算失敗。而軟體產品的可維護性，主要在於軟體架構的設計，一般我們會在撰寫系統開發說明書（SDD）時，去做分析與設計。

• 驗收的注意事項

我們通常會在達成產品開發的里程碑（Milestone）或是在合作過程中不同階段（Phase）的結尾執行驗收。驗收前需要設計驗收的方法與其通過條件，所以在事前，外包商與客戶必須共同蒐集與討論執行驗收時的需求與限制，以期能讓產品或產品組件，可以在預期的情況與環境中執行驗收。

驗收時人員的多寡非常重要，盡量讓不同屬性的關鍵人員能夠同時到場，以便確認產品的正確性，同時我們也能得到不同觀點的意見與發現議題。選擇相關的關鍵人員可以考慮客戶、使用者、開發者、測試者、維護者、供應商、行銷人員、員工，以及其他可能影響產品及流程或是被產品及流程影響的人。

執行驗收不只在於產品功能的確認，與產品相關的組件、文件或是支援與維護產品的項目都是驗收的重點。而在驗收之後我們需要分析缺失並建立驗收報告，以做後續修改與改善的追蹤。

如果外包商有敏捷軟體開發（Agile Software Development）的能力與經驗，驗收的風險將會大大的降低，因為敏捷開發強調緊密協作與溝通，能夠儘早以及不斷地交付有價值的版本，所以許多問題都會在驗收之前就被釐清甚至解決了。

• 以長期合作為前提

更換外包商會增加許多成本與風險，例如公司的產品無法維持一致的品質，或是因為需要磨合降低了效率等，所以如果遇到還算契合的外包商，未來可以嘗試繼續合作。此外，人與人之間的交情與信任，都是建立在長期的相處與合作上，如果客戶能夠以長期創造雙贏為目標，合作將更具彈性，而且相信在遇到困境時，外包商也會幫忙想辦法解決問題，共度難關。
 

作者：江俊志   Gene

文章出處 : TechOrange 科技報橘

原文連結 : 地表最完整軟體外包Know How，所有陷阱、細節都在這講清楚了

圖片出處：https://static.pexels.com/photos/6384/woman-hand-desk-office.jpg

本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。