委外開發outsourcing行之有年，它只是另一種形式的分工方式。
然而，委外的軟體開發，卻是困難異常。即便是簡單的網站設計，不複雜的智慧手機程式(app)，在缺乏正確的溝通認知情況下，還是有可能以意想不到的結果。如果你的專案經理，或者是負責與外包商溝通的人，以下是你最少需要知道的要點。對於不了解的事情，有些時候可以用嘗試的方式學習經驗，但很多時候最好還是參考一下過來人的經驗。
這三個要點，是在已經透過正確的方法選到正確的廠商的前提下。如果還不知道怎麼選擇正確廠商，可參見這裡。
(1) 知道這次外包想要的結果是要什麼
作為專案負責人，你需要知道期待的外包的結果。
假設所有的軟體開發，都是外包商進行，那表示你必須期待外包商有負責管理整件事情
所謂的整件事情，是從設計，細部設計，定義管理的方法(例如Scrum, agile)，程式碼版本管理(例如github)，測試，檢查驗收。換言之，雖然你不負責整件事情，但是你卻要比外包商更了解，這整件事情要怎麼處理。這樣你才能有效控制外包結果。
當然如果外包的範圍很小，例如繪製android logo，那麼你只要確定外包廠商知道android logo有哪些尺寸與標準，約定好時間，就可以等著看結果。
如果外包的範圍中等，例如處理前端網頁javascript以及html部分，但是需要存取後端的API，而後端API是核心任務，因此是內部自行開發。那麼就要界定清楚範圍，你需要能完整提供API文件，不然至少要有API簡單的訓練課程，以及範例程式。由於開發活動必須有一致性，因此還得提供廠商版本控制系統的權限(例如gitbucket)，另外還需要控制開發週期，以及哪些使用者功能(user story)需要先完成，哪些後完成。換言之，如果外包範圍是軟體開發的一部分，那有可能關鍵的結果在於某段程式的正確產出。
(2) 清楚說明規格
在台灣對規格書(spec)其實不那麼重視。尤其是所謂的系統整合商的IT專案。因為有太多情況，規格和最後實際的結果已經截然不同，而規格書很有可能是一邊開發，一邊才跟著寫。根本不切實際，最後都淪為最菜的SA所負責最無聊的工作。
清楚說明規格並不代表要有250頁這麼厚的規格書。而是要有在做重要的事情上，有不可否定的結果。舉例來說，google.com的搜尋畫面，其實也有很多功能，但是必有一個規格是：一個讓人輸入資訊的欄位，並且按下enter之後會直接進行搜尋。某些SA/PM在撰寫規格時會無窮盡的增列細節，例如欄位是要多寬，最多輸入多少字元，反斜線要不要處理，諸如此類。當然重要的規格細節要詳述，但是不能無止盡的窮數之。
對於規格書沒有基本認知的話，可以先參考這裏。
已經有很多撰寫規格書的經驗，但自覺從來沒寫對的話，可以參考這裏。這個spec只有短短20頁，去頭去尾真正的spec可能只有17頁，他沒有很多細節，也沒有用很複雜的UML圖。而且spec徹底與實作方式無關。
(3) 確定對方理解什麼
這點聽起來很不可思議。但是在現實，實在常常發生。那就是即便語言上沒有問題，在溝通認知上，還是有極大的差距。有些幫助有效會議的技巧，通常會提到，會議結束的時候，請最重要的幾個人，用很短的時間，簡單說明會議之後他要去做的事情。如果在一個常常進行無聊會議的組織裡面，可能會有很戲劇性，很荒謬的效果。(請參見"開會開到死")
對委外開發而言，很多時候不是面對面的會議，再加上語言的不同，更容易產生誤會。執行者(就是外包商負責人)必須要有創意的使用結構性合理的方式，來讓彼此理解工作內容。
首先，使用文件是最合理的。尤其是對跨國廠商而言。而文件的長短與格式並不是重點，重點在於有沒有表達你要傳達的資訊。
更有甚者，文件常常有先後次序，你需要知道外包商到底有沒有看那份最重要的文件。
一個簡單的作法是：在最重要的文件(例如規格書Spec)的莫約3/4處，夾一段文字，說如果你看到這份文字，要立即email給某人，並且夾帶一段簡單的"口令"，因為這可以證明他有認真看過，如果在X月X日前，沒有回覆給某人，你會假設他無法完成第一個milestone。
這個作法不管在第一次有沒有達到目的，接下來外包商自然就自動被訓練為，你的重要文件，他一定會看。
管理委外廠商有很多創意的作法。可惜的是，這些作法必須根據靠經驗和實際情況而改變與適應。很難光是用教學的方式就體會。
