既然是創(chuàng)業(yè)團隊，想必初始團隊成員不會很多，但基本上至少會有1~2個人負責技術。我相信選擇創(chuàng)業(yè)的每一個人起初都是滿懷希望，胸有大志的。但是，一 個月后呢？這里我首先想說的就是團隊的執(zhí)行力。

作為創(chuàng)業(yè)團隊都知道這比什么都重要。“設計師已經(jīng)迭代了3個版本了，結果第一個版本都還沒上線”，這種事情在創(chuàng)業(yè)團隊似乎很常見，如果你做了3個月連一個Demo都沒上線，你還如何創(chuàng)業(yè)？天下武功為快不破，創(chuàng)業(yè)者需要具備的基本技能之一就是快，快速迭代，快速成長。這里想到白鴉的逛guang.com，4天就上線了，雖然只有4張靜態(tài)頁面，但至少表達出了自己的產(chǎn)品。不知道是不是受蘋果的影響，很多創(chuàng)業(yè)者非得把產(chǎn)品做到非常完美才愿意上線，我就經(jīng)常聽到某些團隊工作一年多了，產(chǎn)品還未上線，以至于我們以為他們早就洗手不干了。所以，我這里說的快指的不僅僅是沒日沒夜的工作，也要講究一些方法，要有取舍，要丟得起面子，大不了第 二個版本再完善。

從技術角的選擇來看，創(chuàng)業(yè)團隊盡量選擇開源且有良好社區(qū)支持的技術。這樣萬一在使用過程中出現(xiàn)問題也可以快速找到解決方案，就如現(xiàn)在Unix/Linux占領服務器大半市場，必有其合理性。微軟的產(chǎn)品雖然剛開始的時候入門門檻低，但是它其實并不簡單，如果真的碰上什么問題，這個風險和 成本很難控制，如果你不小心已經(jīng)上了微軟的賊船，是否破釜沉舟掉頭就另當別論了。但初創(chuàng)團隊，在決定自己技術之前，我覺得你可以大膽的使用開源技術。但這 時候問題又來了，開源技術就像大海一樣廣闊，人人都可以從中分享和獲取資源。

很多人在大海中拼命的探索最新最酷的技術，我也是一枚Coder，我很能理解作為程序員的這種滿足感，但是這是在創(chuàng)業(yè)，做公司，不是一個釋放自己滿足感的地方，很新很酷技術可以研究，以備將來之用，但不要用在自己的產(chǎn)品上，這樣會 浪費本多不必要的時 間，就如當初在決定小恩愛的技術時，Ruby on Rails也是我能接受的最大尺度。Go、NodeJS、Opa什么的了解了解就可以了。

在研發(fā)的過程中，也會遇到這樣的問題：我們希望把代碼寫得盡量簡潔，美觀。有時候我們會為了把一個50行的代碼優(yōu)化成30行清晰、具有維護性的代碼花去半天甚至一天時間，這樣的錯誤我相信所有閱讀這篇文章的Coder們都犯過。在產(chǎn)品還沒有穩(wěn)定前，不要急于重構代碼。這點不細說，大家應該都明白。但換個角度估計會有很多人想不明白，在產(chǎn)品研發(fā)初期，我們是否需要在效率問題上話太多時間？有些人一開始就用100w用戶的標準做一個網(wǎng)站我覺得是不適合 的，在我看來在初期只要考慮能承受上線后3個月內(nèi)用戶增長規(guī)模的標準就可以了，甚至第一版、第二版壓根不兒用考慮什么效率問題，肯定跑不死。

有了這些技術和素質，作為創(chuàng)業(yè)公司在技術應該80%以上可以站穩(wěn)了，剩下的就是活動你的雙手，用代碼構建產(chǎn)品的靈魂。