之前看過一個創業者寫的文章，文章裡主要是在吐槽找到合適的技術合夥人是如何的困難。這事情確實困難，一旦當事人失去對人或事的基本判斷能力，隨便什麼事情都會變的比較困難。而隨著網際網路對傳統行業的衝擊，這類不懂技術的創業者應該也會越來越多，這樣一來探討下不懂技術的創業者如何解決技術問題就會比較有現實意義。
解決技術問題的人員模式
找能和自己配合的程式設計師有兩種基本模式：
第一種模式就是大多數人總想用，但進展艱難的。很多人都想找一個或多個很牛的人來搞定自己的所有問題。這能找到合適的當然比較好，但出問題概率其實很高，可執行性並不好。這方法價效比更可能是非常差，而不是非常好。首先你不一定找得到，其次你找到了不一定負擔的起，負擔得起了又不一定合得來，合得來他還不一定做的很爽，因為這工作他做過，很大程度是在重複自己。總而言之，這條道路雖然看著美好，但只要用心一想，滿眼全是坑。
這裡容易出問題的原因在於，如果創業者失去了基本的判斷能力，那彼此間就必須非常瞭解和信任，而不懂技術的創業者往往不在這個圈子裡，找到這樣合適的人其實挺難。
在陌生人之間培養信任這事歷來很難，尤其這兩個人背景又不一樣。在陌生人之間確定利益分配就更難，多少是多呢？所以除非有種特別的緣故，發小、同學、多年同事等，否則這條路出奇的艱難，算是看上去很美，其實不太好用的方法。
但我們得承認雖然實現艱難但這個方法本身沒什麼限制，真能找到合適的人，確實什麼都能搞定。關鍵就是你找不到合適的人。
第二種模式是找到基礎好、潛力好（尤其是學習能力）與自己搭的人。當前他可能不完全滿足需求，但他有很好的成長性，這樣正好在事業的成長中實現自己的價值，同時報價也不會太高。簡單來講這和第一種模式的區別就是找成名前的張小龍還是找成名後的張小龍。成名後的張小龍只有一個，但其實具有張小龍潛質的人還是很多的。在我的感覺中，這類技術人員在大學裡還是很多的，只要你用心去找。
這個方法對產品型別有點額外的要求，它更適合非技術密集型的產品。這和特定技術的學習曲線有關，如果你非要做個科大訊飛那類語音專案，那學習曲線就太陡了，即使個人成長性比較好，但這類產品技術人員必須要花很多的時間才能搞定，並且挫折太多，容易激發各種矛盾。
反過來如果是非技術密集型的創意，那麼只要這個人是願意學習的，那就可以基於現有開源產品迅速完成原型（36kr那種），接下來迅速開始迭代，在使用者增長這類壓力下，這個人也會迅速成長，這種成長本身也可以成為對個人的一種激勵。
國外有個很有名的技術網站叫：http://highscalability.com/ ，上面列舉了很多有名網站的技術架構，就我觀察很多情形下是產品成就了技術人員的威名，而不是現有很牛的技術人員再去打造一個很牛的產品。這網站上的文章往往會很詳細的記錄某個產品的技術變化，記錄這些變化實際上也等價於記錄了當事人自己的成長過程。
這個模式之所以能成立，也和程式設計這項工作的技術特徵有關，這裡就說兩點：
- 第一，程式設計這事入門起點不高，同時由於開源的發展，大多時候可參照的東西很多，能幫助人的社群也比較多。所以持續學習與成長性比經驗重要。
- 第二，開發產品這事大多數人都能做，難的部分往往是漸進的。阿里雙十一問題是不好解決，可也不是創業公司上來就有機會有那麼大流量的。
這裡的關鍵是要找到潛力好、能自我提升的，這樣一來對程式設計師個人會有比較好的成長機會，做產品的同時他可能會成長為以一頂十的超級程式設計師；對於創業者而言，在技術人員的成長過程中也可以收穫逐步改進的產品。
把握基本原則，避開顯然的陷阱
如果能完全彼此相信，那所有技術決策都叫技術人員下就可以了，但如果還達不到那種程度，那創業者自己就需要把握一點基本的原則，來避開顯然的陷阱，而這些陷阱往往純技術人員是不會去識別的。這裡所謂的避開陷阱主要是為了避免掉到大坑裡徹底無法翻盤那類陷阱。
第一是在最開始階段避免技術創新，儘可能隨大流，用極為成熟的方案。原因很簡單，在產品和個人的雙重成長期不適合太折騰，要儘可能把變數控制在某一個方面上。而所謂隨大流有兩個具體要求：用有活躍社群的開源技術，用有類似的產品用過的技術。說到這裡岔開一句找人的時候英語好是一個硬性條件，因為英文不好，可能就不願意讀英文資料，而以分享的深度來看現在英文世界仍然有非常明顯的優勢，比如highscalability，stackoverflow等。不讀這類網站上的內容，眼界就窄，隨大流可能都隨不好。
第二是用開源技術。這又可以分兩個層次，一個層次是選開源技術棧比如Linux， Apache， MySQL，PHP；一個是直接選開源專案的程式碼做開發基礎。只要你的產品不是過於另類，在Github這種地方總是可以找到合適的專案作為程式碼基礎，這與國內很多網站是基於WordPress的是一個道理。從開局的角度看，顯然後一個更實惠些，前提是能找到合適的備選方案，比如Github上很多星星，又有很多人在維護的。
第三是要認識到到有錢後，要還技術債務。這時候要預測技術上可能出現的限制並及早進行解決。技術上的事情總是容易在開局時最重視，越往後重視程度越差。除非發生什麼災難性的事情，否則不懂技術的創業者容易認為都能用不就行了麼，可這是不合適的。軟體產品這東西，除了可見部分比如實現了某些功能之外，還有很大一塊東西是沒法直接看到的，比如程式碼的質量，架構的質量等，而匆忙推出的產品總是容易在這些不可見的地方欠下鉅額債務。在產品發展過程中總是可以找到些時間來還之前欠的債，開發環境上的、結構上的、程式碼上的等等。這事屬於重要不緊急的事情，如果不找空擋處理掉，很可能在未來成為瓶頸。
結束語
上面說的方法，是讓人有個成本低廉、大致不差的開局，但並不是說可以一直這樣；當你想做的事情越來越獨特，這類方案一定會產生某種限制，這類限制也許暫時能對付，但是如果有長遠眼光，則要在有錢後系統做點分析，看看能不能找到這種瓶頸，及早應對。江湖傳說中京東是吃了點沒有及早處理技術債務的虧的。
來自：CSDN
相關閱讀
評論(2)