“一般人寫文章，寫到一些不那么好的案例呢，都是我的朋友誰誰。不過我這邊呢，就不太敢這么寫，因為我的朋友都太厲害，各個搞個上市公司跟玩一樣，所以呢，成功的案例，我的朋友比較多，失敗的案例，我自己比較多。所以今天說的其實是我自己。”

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

　　別人呵呵一下，心里說，就你懂，你早干嘛去了。

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

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

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

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

　　執行力的要點

　　第一，從空想到方案

　　你有一個想法，和你有一個可操作的想法，這是兩回事。

　　將想法變成可操作的方案，并且相對準確和實際的評估出操作成本。

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

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

　　我這想法不錯吧。

　　我自己搞得定么？肯定沒戲。

　　我的團隊搞得定么？還是沒戲。

　　我能延攬到搞得定的技術人才么？想了想，還是沒戲。

　　這種想法，再好的機會和市場空間，和自己沒關系。

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

　　第三，抓住問題的核心

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

　　但我和很多創業者不同。

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

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

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

　　第四，克服問題的能力

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

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

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

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

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

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

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

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

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

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

　　1、啊，延誤了？為什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　想到了，只是很小的一步，從想到 到做到，要邁很多很多步。

　　文 / 曹政 來源 / 微信公眾號caoz的夢囈