本文来自微信公众号：caoz 的梦呓（caozsay），作者：曹政
一般人写文章，写到一些不那么好的案例呢，都是我的朋友谁谁。不过我这边呢，就不太敢这么写，因为我的朋友都太厉害，各个搞个上市公司跟玩一样，所以呢，成功的案例，我的朋友比较多，失败的案例，我自己比较多。所以今天说的其实是我自己。
很多时候，看到一个非常不错的产品上市发布了，好评和口碑如潮，朋友圈里我偶尔会得瑟一句，看到没，这不就是之前我提到的过的那个啥啥么，瞧瞧，我说这个领域有机会吧。
别人呵呵一下，心里说，就你懂，你早干嘛去了。
其实，很多创业者都会遇到类似的问题，就是明明自己有一个很好的点子，很正确的判断，但是最后眼巴巴看着别人把事情做成。
这就是创业中最重要的一项素质，也是我最欠缺的一项素质，执行力。这也就是为什么我天天写创业，自己做的事情却不值一提的原因。
执行力的鸡汤文章多的不要不要的，但如果只是强调执行力的重要，那实在没有意义。关键是，如何提高执行力。
执行力的要点：
第一，从空想到方案
你有一个想法，和你有一个可操作的想法，这是两回事。
将想法变成可操作的方案，并且相对准确和实际的评估出操作成本。
第二，确认你或你团队的能力足以覆盖你的方案
我想发明一款高智能无人驾驶飞机，上班不堵车，还能自动规避其他飞行器，而且晚上充电白天就能飞。控制成本在 30 万人民币以内，以后买房在远郊，省下的钱飞去上下班。机翼可以收缩很容易进入普通停车位。
我这想法不错吧。
我自己搞得定么？肯定没戏。
我的团队搞得定么？还是没戏。
我能延揽到搞得定的技术人才么？想了想，还是没戏。
这种想法，再好的机会和市场空间，和自己没关系。
在这里，很多空想创业者会认为，只要融到足够的钱，就很容易找到满足诉求的人才。我不能说这种情况不会发生，但我肯定的说，如果你欠缺的是技术门槛比较高的人才，不管你融资多么顺利，在短期内找到合适的技术人才都是小概率事件，除非你的影响力跟李开复一样。
第三，抓住问题的核心
影响执行力的一个非常大的问题，也是我一直以来没有克服和解决的问题，就是想太多。
但我和很多创业者不同。
一些创业者是想的过于美好，在产品还没有发布的时候，就会想到太多后续的形态和商业路线图，然后把太多精力放在根本不需要开始就准备的事情和问题上。
我的问题在于，我的负能量比较高，考虑太多负面的，不确定的潜在的风险和麻烦，所以在这方面思考过度，也就影响了产品的快速设计和实现。
快速原型，快速迭代，快速试错，一定是需要抛弃太多细微末节，抛弃太多不必要的考虑和设计，抛弃一切过度的思考，紧紧围绕整个方案的核心来进行。
第四，克服问题的能力
很多创业者，遇到问题会停下来等，等找到合适的人，等找到合适的技术，等找到合适的资源，然后等着等着项目就黄了，或者看着别人做起来了。
克服问题的能力是，不代表你具有足够的技术，足够的资源，足够的人才，是的，很多成功的项目，你仔细分析，他们都不存在这样优越的背景。
你知道如何在人才、技术、资源不足的情况下做好你的产品，这也是非常重要的一种能力。
当年李兴平在既缺乏技术人才，也缺乏足够的其他资源的情况下，先后做出了中国最大的网址导航网站、小小游戏网站、音乐网站，以及一堆七七八八访问量很高的网站。这绝不是运气，只是我们很多人会有一种思维定式，以为做个成功的网站必须有技术，有人才，有优秀的设计，其实你抓住了核心后，发现很多都不是必须的。
前段时间我看到知乎有个热帖特别好，题目大约是，哪些看上去很强大的技术其实实现方式很简单。（记不清具体题目了） 我看了很多答案也是非常有意思，其中不少游戏行业的案例，一些小设计团队，小的开发团队，用很简单复用性极强的一种常人想象不到的设计思路，以最低的技术成本，实现了看上去很复杂很高大上的产品效果。 这样的案例在很多类型的项目中其实都有体现。
以前我也提过这个能力，就是简化的能力，将复杂的东西简化的能力。
在把握核心诉求不损失的情况下，能够善于简化工作，就能极大提高执行力，减少不必要的成本支出，特别是时间成本。以及，规避一些看上去很复杂的技术问题，或者其他各种设计问题。
第五，步步寻求反馈，进度分解到位
又是我做的非常不够的地方。
创业者，觉得自己想清楚了，任务也布置下去了，团队也都表态了，好像也没啥困难和问题了，然后，忙其他事情去了，过了俩月，拉团队出来说，进度咋样了？那么结果有以下几种。
1、啊，延误了？为什么？
2、产品出来了，赶紧瞅瞅，等等，做的这个是啥。
3、产品出来了，赶紧瞅瞅，看上去不错啊，上线发布，哎呦，用户一上就垮，赶紧修复，啥，无法修复，要全部重构？
以上几种可能，结果其实都一样，就是在你预期的时间内，完全彻底的达不到你预期的效果。
步步寻求反馈，从产品的原型设计，到技术的原型设计，到技术的核心模块、数据结构，都要求给予明确的反馈。你说你不懂技术，但你要了解一些最基本的指标，比如说，这个产品最频繁的调用请求会集中在哪里，这个请求频次会在什么量级上。
很多技术人员有个误区，觉得说我做完了代码，做完产品，然后再去做压力测试，再去调优。
当然，实话说，作为快速实现的产品，我们也许不奢求性能多么卓越，或者考虑多么长远，但是对一些核心诉求的部分，至少应该有一个及格标准，也就是至少可以保证稳定发展种子用户的能力。如果连这个都做不到，这个东西就没有可用性了。
那么这个压力测试应该在什么时候做呢？ 你的数据结构出来，你整个功能里最核心的几个高频次 SQL 写出来的时候，这个压力测试就可以做了，灌进去几百万条数据，关掉 query cache，做压力测试，看看是否符合预期。这个及格了，你后面写代码就心里有底了，但如果这步没有做，等你上线后发现，哎呦，这里有问题，这改动就小不了了。
从产品的设计，到技术的实现，每一步都要得到执行者的反馈，和预期进度的对比，并且要清楚在整个团队里，谁可能成为瓶颈，谁可能正在坐等他人的进度而无所事事。
而这种反馈，必须是实实在在的，有真正的彼此共识和细节的认知，并将各种可能理解歧义或者产生隐患的问题尽早暴露出来，达成共识，而不是一句空洞的总结，“今天，完成模块1，明天，计划模块2。”
很多时候，团队人越多，这种反馈和进度的确认就越难。
有些创业团队，在这里的时间，精力，人力和资金的消耗，简直是惊人的。
第六，不论成败，认真细致的总结
有很多情况，也许做的已经足够努力，但结局依然不尽人意。
一句简单的方向错了，或者说能力不足，或者说资源不足，来盖棺定论，是对不起所付出的努力和工作的。
作为创业者，做坏一个项目，做坏一个产品，没什么大不了，重头来过就是了，但学费要交的有价值，团队和创业者的成长要有价值，否则就等于是白交学费，白浪费了时间和精力。
所以认真细致的复盘非常重要，对事不对人，在哪个环节，哪个步骤上，思考的地方错了，还是执行的方式错了，还是选择的技术方案，产品设计路线图错了，要认真的总结到位，不推诿，不埋怨，找到真正的问题，这学费才算值了。只有这样，下一次的成功率才会更高一些。
想到了，只是很小的一步，从想到到做到，要迈很多很多步。
如需授权请联系微信公众号：caoz 的梦呓（caozsay）