做產品到底是要找人還是外包 - 創業

因為看到前面有版友討論做APP產品
才想到要貼一下這篇文給大家看
作者是版友但不是我，請不要來信問我技術問題XD

做產品，到底該外包還是自己聘人？

「委託外包？還是內部聘技術人？」這個問題對於非技術背景的經營者而言，一直是個兩
難的抉擇。如果此時，你正好準備創業，擁有自己領域的商業資源，該如何讓一個產品快
速進入市場，發揮所有商業資源的效益？我希望以中立的角度來剖析優劣勢提供各位參考
，希望對於大家產品開發的過程，有更深入的幫助。

怎麼考慮要不要外包？
一般來說，如果是短期的產品或是專案開發，大部份人會選擇外包，不只小公司，中大型
公司開發新的技術領域時，其實也常常如此選擇，然後打的如意算盤就是，價格低、開發
速度快、工程團隊不需要管理、產品做出來後再找來工程師接手即可。然而從我聽到的、
看到的案件之中，大部份的案件都不是如此的順利。

因為當公司選擇價格低的開發團隊時，通常就會遇到高風險，而管理外包的方式，絕大多
數就是「一紙合約」，說實在話，以我經歷接案事業將近快十年的時間裡，即使每個接案
公司都希望在合約中詳細規範規格，但從來沒有遇過任何專案的業主是不會改變規格的，
也因此造就業主的美好想像和開發結果天差地遠，雙方都有說不完的苦衷，而那「一紙合
約」在此時的效力跟墊便當的宣傳單差不多，通常這種案件結果就像是情侶分手，不是草
草結束，就是另尋他人。

既然這是常見的外包慘況，為什麼還要選擇外包呢？我認為外包提供最大的優勢是「彈性
支援」，因為一個月內臨時要內聘到兩、三個資深的開發者開發產品除非祖上有積德，然
而透過找外包的話，這絕對是有可能的事情。

自己人是否比較好？
technical_resource

上圖是我最常用來說明聘人會遇到的問題，簡而言之，當公司剛開始開發產品時，很可能
聘用多個領域的工程師，但是當產品發展逐漸邁向穩定時，工程師的工作量隨之降低，代
表產品更新的需求減少時，工程師的管理成本顯得大幅浪費，甚至有的工程師在團隊就直
接乾脆被拉去當業務，當然這對公司經營而言應該不是最好的配置，套句鄉民的說法，凡
事還是讓專業的來比較好。

公司聘人，很多人會覺得優點當然是自己的人比較好使喚，或是起碼資料不會外洩，要不
然就是開發能量充足的時候，想做什麼都可以做，如果公司制度和配套全面，這些理想狀
況確實可行，偏偏筆者也常聽到許多「意外」，除工程師能力不夠全面等普遍問題，公司
文化跟工程師不合造成工作效率低，或是工程師拿翹，自己在程式碼裡面留一手，甚至擅
自離職，當然也有公司業務成長或資金擴充時，工程師認為自己的技術成本應該提升，導
致團隊失和，偏偏請神容易送神難，讓產品開發原地打轉。這類「人的風險」狀況都相當
常見，也成為內部聘人最大的隱憂，只能說聘人的成敗，多取決於老闆自己看人的經驗。

如何做出選擇？
要回答這個問題，我認為最重要的因素為「公司內有沒有技術架構者？」。這位架構者或
許是 CTO，或許就是 CEO，當然也有神人等級的 UI 設計師有能力自己規劃系統架構。擔
任「技術架構者」有個極為重要的工作：切割系統並且分派工作。大部份剛成立的團隊，
有些成員是工程師，但一般工程師並沒有能力構築整個系統，舉例來說，假設今天要做一
個像是 Instagram 的 App，架構者必須明確定義資料結構，並建構資料庫大概的樣貌，
然後拆解 App 要處理的工作項目與 Server 端要處理的工作項目，最後再用 API 的規範
文件規範出來，這樣剩餘的工作，就可以分別找 App 工程師、 Server 工程師個別開發
，此時可以選擇再搭配外包進行單純且密集的合作，運用外包的彈性，在短期內完成工作
。

如果公司沒有架構者就進行開發，光在釐清產品規格時，就會遇到很大的阻力，因不清楚
產品的技術架構，也沒辦法實踐找尋從開發到上線的最短路徑。此時，我通常建議團隊至
少招聘兩種人，UI 設計師以及後端工程師，UI 設計師必須對於使用者經驗有認知的，這
兩種角色都必須要思考整個產品面向的規劃，聘到這兩種人，對於產品的開發過程來說，
絕對會是很大的幫助，也可以將從這兩種人手開始訓練成公司的架構者。

關於降低外包的風險
在產品開發的過程，為了規避工程師掌權的風險，最重要的兩件事情，就是技術文件以及
程式碼的透明管理，不管聘人也好、外包也好，一定要在早期就規範這兩者資料文件，筆
者已經耳聞太多工程師離職後，接手工程師乾脆整個案子做重構的慘案，或是外包跑掉，
連資料庫的密碼都沒留下。

因此在我管理的專案中，都十分要求技術文件以及程式碼的管理，即使這會讓成本上升，
卻會大大降低風險，如果你是屬於非技術底的創業者，不管你聘用自己的 CTO 或是外包
團隊為你開發產品，請一定要記得讓他們教會你怎麼看資料庫、怎麼進到產品的 Server
、所有系統的帳號密碼、程式碼放置的位置（最好是使用原始碼管理的工具）以及產品設
計的原圖一定要留下來，這都是為了追溯產品架構的最佳資料，即使多花點錢，都會是值
得的。

做一個尊重技術專業的老闆
我們總是聽到業主說：「既然你們是專業的團隊，應該大小事都要能夠處理好，我就不用
擔心這些事情，應該時間到了，產品就要完整呈現在我眼前」。通常遇到這種業主，我建
議接案團隊，有機會就不要跟這個客戶合作了，因為他們對於軟體服務的產品開發毫無概
念。

在產品開發的過程，一定會有規格的改變，哪怕是一個按鈕的位置要改變或是顏色要調整
，甚至是一連串改變設計的過程，都是常見的狀況，在這過程中，業主不願意了解為什麼
改變一個東西，會造成工程師的困擾，會造成架構的改變，或是業主連最基本的技術架構
都不願意花時間理解，說要做軟體服務的領導者，這實在是一件可笑又可怕的事情，當然
不只是業主，很多公司的老闆也都是如此。

我目前合作的夥伴，對技術開發的專業都是相當尊重的，即使改變產品方向，也知道取捨
，盡量減輕開發工程中的負擔，一起了解也許會多花一點時間，但也一定會讓產品的營運
端跟開發端合作更為緊密順利。漸漸的，你也會發覺，即使你並非技術背景，但也會知道
什麼是Git、什麼是 Linux、什麼樣的工作是 Backend 的人在做、什麼樣的工作又是
Frontend 跟 app 開發者在做的工作，這些眉眉角角，會讓你了解產品開發狀況的最佳
切入點。

不管找外包還是自己人，找對人最重要
對我而言，不管是外包也好，自己聘人也好，都希望是以「長期合作」為雙方共識，該付
的價錢先談好，大家合作的底線也都說好，遇到不願意提供程式碼的工程團隊，我會寧願
不合作，也不要為了趕進度硬要合作，因為那只會造成後續開發的問題。我最強調的是，
不管在哪種合作模式下，誠信一直都是最重要的事情，找到跟自己最合調的工作團隊，即
使遇到了問題，也可以一起共度難關，一起為開發延遲的狀況找個最好的解法，而不是互
相歸咎責任，畢竟，增加產品開發的速度還不是為了把產品更快更完整的銷售到市場上，
依此共識，不論是聘人也好，外包也好，只要大家目標一致，剩下就是創造雙贏的分潤過
程了。

文章連結 http://bit.ly/1EPO1wd

--