創業者思考:明明有想法為何卻比別人慢

29

文:曹政

一般人寫文章,寫到一些不那麼好的案例呢,都是我的朋友誰誰。

不過我這邊呢,就不太敢這麼寫,因為我的朋友都太厲害,各個搞個上市公司跟玩一樣,所以呢,成功的案例,我的朋友比較多,失敗的案例,我自己比較多。

所以今天說的其實是我自己。

很多時候,看到一個非常不錯的產品上市發佈瞭,好評和口碑如潮,那個,朋友圈裡我偶爾會得瑟一句,看到沒,這不就是之前我提到的過的那個啥啥麼,瞧瞧,我說這個領域有機會吧。

別人呵呵一下,心裡說,就你懂,你早幹嘛去瞭。

其實,很多創業者都會遇到類似的問題,就是明明自己有一個很好的點子,很正確的判斷,但是最後眼巴巴看著別人把事情做成。

這就是創業中最重要的一項素質,也是我最欠缺的一項素質,執行力。

這也就是為什麼我天天寫創業,自己做的事情卻不值一提的原因。

執行力的雞湯文章多的不要不要的,但如果隻是強調執行力的重要,那實在沒有意義。關鍵是,如何提高執行力。

執行力的要點

第一,從空想到方案

你有一個想法,和你有一個可操作的想法,這是兩回事。將想法變成可操作的方案,並且相對準確和實際的評估出操作成本。

第二,確認你或你團隊的能力足以覆蓋你的方案

我想發明一款高智能無人駕駛飛機,上班不堵車,還能自動規避其他飛行器,而且晚上充電白天就能飛。控制成本在30萬人民幣以內,以後買房在遠郊,省下的錢飛去上下班。機翼可以收縮很容易進入普通停車位。

我這想法不錯吧。我自己搞得定麼?肯定沒戲。我的團隊搞得定麼?還是沒戲。我能延攬到搞得定的技術人才麼?想瞭想,還是沒戲。這種想法,再好的機會和市場空間,和自己沒關系。

在這裡,很多空想創業者會認為,隻要融到足夠的錢,就很容易找到滿足訴求的人才。我不能說這種情況不會發生,但我肯定的說,如果你欠缺的是技術門檻比較高的人才,不管你融資多麼順利,在短期內找到合適的技術人才都是小概率事件,除非你的影響力跟李開復一樣。

第三,抓住問題的核心

影響執行力的一個非常大的問題,也是我一直以來沒有克服和解決的問題,就是想太多。

但我和很多創業者不同。

一些創業者是想的過於美好,在產品還沒有發佈的時候,就會想到太多後續的形態和商業路線圖,然後把太多精力放在根本不需要開始就準備的事情和問題上。

我的問題在於,我的負能量比較高,考慮太多負面的,不確定的,潛在的風險和麻煩,所以在這方面思考過度,也就影響瞭產品的快速設計和實現。

快速原型,快速迭代,快速試錯,一定是需要拋棄太多細微末節,拋棄太多不必要的考慮和設計,拋棄一切過度的思考,緊緊圍繞整個方案的核心來進行。

第四,克服問題的能力

很多創業者,遇到問題會停下來等,等找到合適的人,等找到合適的技術,等找到合適的資源,然後等著等著項目就黃瞭,或者看著別人做起來瞭。

克服問題的能力是,不代表你具有足夠的技術,足夠的資源,足夠的人才,是的,很多成功的項目,你仔細分析,他們都不存在這樣優越的背景。

你知道如何在人才,技術,資源不足的情況下做好你的產品,這也是非常重要的一種能力。

當年李興平在即缺乏技術人才,也缺乏足夠的其他資源的情況下,先後做出瞭中國最大的網址導航網站,小小遊戲網站,音樂網站,以及一堆七七八八訪問量很高的網站。這絕不是運氣,隻是我們很多人會有一種思維定式,以為做個成功的網站必須有技術,有人才,有優秀的設計,其實你抓住瞭核心後,發現很多都不是必須的。

前段時間我看到知乎有個熱帖特別好,題目大約是,哪些看上去很強大的技術其實實現方式很簡單。(記不清具體題目瞭。。。) 我看瞭很多答案也是非常有意思,其中不少遊戲行業的案例,一些小設計團隊,小的開發團隊,用很簡單復用性極強的一種常人想象不到的設計思路,以最低的技術成本,實現瞭看上去很復雜很高大上的產品效果。 這樣的案例在很多類型的項目中其實都有體現。

以前我也提過這個能力,就是簡化的能力,將復雜的東西簡化的能力。

在把握核心訴求不損失的情況下,能夠善於簡化工作,就能極大提高執行力,減少不必要的成本支出,特別是時間成本。以及,規避一些看上去很復雜的技術問題,或者其他各種設計問題。

第五,步步尋求反饋,進度分解到位。

又是我做的非常不夠的地方。

創業者,覺得自己想清楚瞭,任務也佈置下去瞭,團隊也都表態瞭,好像也沒啥困難和問題瞭,然後,忙其他事情去瞭,過瞭倆月,拉團隊出來說,進度咋樣瞭?那麼結果有以下幾種。

1、啊,延誤瞭?為什麼?

2、產品出來瞭,趕緊瞅瞅,等等,做的這個是啥。

3、產品出來瞭,趕緊瞅瞅,看上去不錯啊,上線發佈,哎呦,用戶一上就垮,趕緊修復,啥,無法修復,要全部重構???

以上幾種可能,結果其實都一樣,就是在你預期的時間內,完全,徹底的達不到你預期的效果。

步步尋求反饋,從產品的原型設計,到技術的原型設計,到技術的核心模塊,數據結構,都要求給予明確的反饋,你說你不懂技術,但你要瞭解一些最基本的指標,比如說,這個產品最頻繁的調用請求會集中在哪裡,這個請求頻次會在什麼量級上。

很多技術人員有個誤區,覺得說我做完瞭代碼,做完產品,然後再去做壓力測試,再去調優。

當然,實話說,作為快速實現的產品,我們也許不奢求性能多麼卓越,或者考慮多麼長遠,但是對一些核心訴求的部分,至少應該有一個及格標準,也就是至少可以保證穩定發展種子用戶的能力,如果連這個都做不到,這個東西就沒有可用性瞭,那麼這個壓力測試應該在什麼時候做呢? 你的數據結構出來,你整個功能裡最核心的幾個高頻次SQL寫出來的時候,這個壓力測試就可以做瞭,灌進去幾百萬條數據,關掉query cache,做壓力測試,看看是否符合預期,這個及格瞭,你後面寫代碼就心裡有底瞭,但如果這步沒有做,等你上線後發現,哎呦,這裡有問題,這改動就小不瞭瞭。

從產品的設計,到技術的實現,每一步都要得到執行者的反饋,和預期進度的對比,並且要清楚在整個團隊裡,誰可能成為瓶頸,誰可能正在坐等他人的進度而無所事事。

而這種反饋,必須是實實在在的,有真正的彼此共識和細節的認知,並將各種可能理解歧義或者產生隱患的問題盡早暴露出來,達成共識,而不是一句空洞的總結,“今天,完成模塊1,明天,計劃模塊2。”

很多時候,團隊人越多,這種反饋和進度的確認就越難。

有些創業團隊,在這裡的時間,精力,人力和資金的消耗,簡直是驚人的。

第六,不論成敗,認真細致的總結

有很多情況,也許做的已經足夠努力,但結局依然不盡人意。

一句簡單的方向錯瞭,或者說能力不足,或者說資源不足,來蓋棺定論,是對不起所付出的努力和工作的。

作為創業者,做壞一個項目,做壞一個產品,沒什麼大不瞭,重頭來過就是瞭,但學費要交的有價值,團隊和創業者的成長要有價值,否則就等於是白交學費,白浪費瞭時間和精力。

所以認真細致的復盤非常重要,對事不對人,在哪個環節,哪個步驟上,思考的地方錯瞭,還是執行的方式錯瞭,還是選擇的技術方案,產品設計路線圖錯瞭,要認真的總結到位,不推諉,不埋怨,找到真正的問題,這學費才算值瞭。隻有這樣,下一次的成功率才會更高一些。

想到瞭,隻是很小的一步,從想到 到做到,要邁很多很多步。

Comments are closed.