做產品,到底該外包還是自己聘人?

評論
評論

本文原刊登於 AlphaCamp〈 做產品,到底該外包還是自己聘人?〉。作者 Paul,目前就任 Fable 寓意科技執行長,亦擔任數家公司的技術顧問,作為一個軟體開發的技術人,成立寓意的本意就是希望為每一個產品都是從一個故事開始,藉由探索需求的過程來發展出合理的產品,目前與公司夥伴已協助十多個產品順利上線,並且與客戶一起持續找尋更好的產品定位與方向。

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

怎麼考慮要不要外包?

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

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

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

自己人是否比較好?

0002

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

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

如何做出選擇?

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

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

關於降低外包的風險

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

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

做一個尊重技術專業的老闆

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

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

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

不管找外包還是自己人,找對人最重要

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

關於文章,如果大家有任何想法,歡迎在下方留言指教或交流!

 

照片來源:Andrew MagillGeekettes

歡迎加入「Inside」Line 官方帳號,關注最新創業、科技、網路、工作訊息

好友人數

評論