文：曹政
一般人寫文章，寫到一些不那麼好的案例呢，都是我的朋友誰誰。
不過我這邊呢，就不太敢這麼寫，因為我的朋友都太厲害，各個搞個上市公司跟玩一樣，所以呢，成功的案例，我的朋友比較多，失敗的案例，我自己比較多。
所以今天說的其實是我自己。
很多時候，看到一個非常不錯的產品上市發佈瞭，好評和口碑如潮，那個，朋友圈裡我偶爾會得瑟一句，看到沒，這不就是之前我提到的過的那個啥啥麼，瞧瞧，我說這個領域有機會吧。
別人呵呵一下，心裡說，就你懂，你早幹嘛去瞭。
其實，很多創業者都會遇到類似的問題，就是明明自己有一個很好的點子，很正確的判斷，但是最後眼巴巴看著別人把事情做成。
這就是創業中最重要的一項素質，也是我最欠缺的一項素質，執行力。
這也就是為什麼我天天寫創業，自己做的事情卻不值一提的原因。
執行力的雞湯文章多的不要不要的，但如果隻是強調執行力的重要，那實在沒有意義。關鍵是，如何提高執行力。
執行力的要點
第一，從空想到方案
你有一個想法，和你有一個可操作的想法，這是兩回事。將想法變成可操作的方案，並且相對準確和實際的評估出操作成本。
第二，確認你或你團隊的能力足以覆蓋你的方案
我想發明一款高智能無人駕駛飛機，上班不堵車，還能自動規避其他飛行器，而且晚上充電白天就能飛。控制成本在30萬人民幣以內，以後買房在遠郊，省下的錢飛去上下班。機翼可以收縮很容易進入普通停車位。
我這想法不錯吧。我自己搞得定麼？肯定沒戲。我的團隊搞得定麼？還是沒戲。我能延攬到搞得定的技術人才麼？想瞭想，還是沒戲。這種想法，再好的機會和市場空間，和自己沒關系。
在這裡，很多空想創業者會認為，隻要融到足夠的錢，就很容易找到滿足訴求的人才。我不能說這種情況不會發生，但我肯定的說，如果你欠缺的是技術門檻比較高的人才，不管你融資多麼順利，在短期內找到合適的技術人才都是小概率事件，除非你的影響力跟李開復一樣。
第三，抓住問題的核心
影響執行力的一個非常大的問題，也是我一直以來沒有克服和解決的問題，就是想太多。
但我和很多創業者不同。
一些創業者是想的過於美好，在產品還沒有發佈的時候，就會想到太多後續的形態和商業路線圖，然後把太多精力放在根本不需要開始就準備的事情和問題上。
我的問題在於，我的負能量比較高，考慮太多負面的，不確定的，潛在的風險和麻煩，所以在這方面思考過度，也就影響瞭產品的快速設計和實現。
快速原型，快速迭代，快速試錯，一定是需要拋棄太多細微末節，拋棄太多不必要的考慮和設計，拋棄一切過度的思考，緊緊圍繞整個方案的核心來進行。
第四，克服問題的能力
很多創業者，遇到問題會停下來等，等找到合適的人，等找到合適的技術，等找到合適的資源，然後等著等著項目就黃瞭，或者看著別人做起來瞭。
克服問題的能力是，不代表你具有足夠的技術，足夠的資源，足夠的人才，是的，很多成功的項目，你仔細分析，他們都不存在這樣優越的背景。
你知道如何在人才，技術，資源不足的情況下做好你的產品，這也是非常重要的一種能力。
當年李興平在即缺乏技術人才，也缺乏足夠的其他資源的情況下，先後做出瞭中國最大的網址導航網站，小小遊戲網站，音樂網站，以及一堆七七八八訪問量很高的網站。這絕不是運氣，隻是我們很多人會有一種思維定式，以為做個成功的網站必須有技術，有人才，有優秀的設計，其實你抓住瞭核心後，發現很多都不是必須的。
前段時間我看到知乎有個熱帖特別好，題目大約是，哪些看上去很強大的技術其實實現方式很簡單。（記不清具體題目瞭。。。） 我看瞭很多答案也是非常有意思，其中不少遊戲行業的案例，一些小設計團隊，小的開發團隊，用很簡單復用性極強的一種常人想象不到的設計思路，以最低的技術成本，實現瞭看上去很復雜很高大上的產品效果。 這樣的案例在很多類型的項目中其實都有體現。
以前我也提過這個能力，就是簡化的能力，將復雜的東西簡化的能力。
在把握核心訴求不損失的情況下，能夠善於簡化工作，就能極大提高執行力，減少不必要的成本支出，特別是時間成本。以及，規避一些看上去很復雜的技術問題，或者其他各種設計問題。
第五，步步尋求反饋，進度分解到位。
又是我做的非常不夠的地方。
創業者，覺得自己想清楚瞭，任務也佈置下去瞭，團隊也都表態瞭，好像也沒啥困難和問題瞭，然後，忙其他事情去瞭，過瞭倆月，拉團隊出來說，進度咋樣瞭？那麼結果有以下幾種。
1、啊，延誤瞭？為什麼？
2、產品出來瞭，趕緊瞅瞅，等等，做的這個是啥。
3、產品出來瞭，趕緊瞅瞅，看上去不錯啊，上線發佈，哎呦，用戶一上就垮，趕緊修復，啥，無法修復，要全部重構？？？
以上幾種可能，結果其實都一樣，就是在你預期的時間內，完全，徹底的達不到你預期的效果。
步步尋求反饋，從產品的原型設計，到技術的原型設計，到技術的核心模塊，數據結構，都要求給予明確的反饋，你說你不懂技術，但你要瞭解一些最基本的指標，比如說，這個產品最頻繁的調用請求會集中在哪裡，這個請求頻次會在什麼量級上。
很多技術人員有個誤區，覺得說我做完瞭代碼，做完產品，然後再去做壓力測試，再去調優。
當然，實話說，作為快速實現的產品，我們也許不奢求性能多麼卓越，或者考慮多麼長遠，但是對一些核心訴求的部分，至少應該有一個及格標準，也就是至少可以保證穩定發展種子用戶的能力，如果連這個都做不到，這個東西就沒有可用性瞭，那麼這個壓力測試應該在什麼時候做呢？ 你的數據結構出來，你整個功能裡最核心的幾個高頻次SQL寫出來的時候，這個壓力測試就可以做瞭，灌進去幾百萬條數據，關掉query cache，做壓力測試，看看是否符合預期，這個及格瞭，你後面寫代碼就心裡有底瞭，但如果這步沒有做，等你上線後發現，哎呦，這裡有問題，這改動就小不瞭瞭。
從產品的設計，到技術的實現，每一步都要得到執行者的反饋，和預期進度的對比，並且要清楚在整個團隊裡，誰可能成為瓶頸，誰可能正在坐等他人的進度而無所事事。
而這種反饋，必須是實實在在的，有真正的彼此共識和細節的認知，並將各種可能理解歧義或者產生隱患的問題盡早暴露出來，達成共識，而不是一句空洞的總結，“今天，完成模塊1，明天，計劃模塊2。”
很多時候，團隊人越多，這種反饋和進度的確認就越難。
有些創業團隊，在這裡的時間，精力，人力和資金的消耗，簡直是驚人的。
第六，不論成敗，認真細致的總結
有很多情況，也許做的已經足夠努力，但結局依然不盡人意。
一句簡單的方向錯瞭，或者說能力不足，或者說資源不足，來蓋棺定論，是對不起所付出的努力和工作的。
作為創業者，做壞一個項目，做壞一個產品，沒什麼大不瞭，重頭來過就是瞭，但學費要交的有價值，團隊和創業者的成長要有價值，否則就等於是白交學費，白浪費瞭時間和精力。
所以認真細致的復盤非常重要，對事不對人，在哪個環節，哪個步驟上，思考的地方錯瞭，還是執行的方式錯瞭，還是選擇的技術方案，產品設計路線圖錯瞭，要認真的總結到位，不推諉，不埋怨，找到真正的問題，這學費才算值瞭。隻有這樣，下一次的成功率才會更高一些。
想到瞭，隻是很小的一步，從想到 到做到，要邁很多很多步。