物理学上有个术语叫“逃逸速度”，指的就是一个物体如果要逃离万有引力的约束所要达到的速度。一个火箭上升的初始速度如果能达到11.2km/s以上的话就能够冲出地球走向宇宙一去不复还。如果低于这个速度的话，那对不起，你将需要消耗更多的燃料慢慢的推动着火箭往上升，最终的结果可能就是上演一出真实版的“重返地球”最终坠毁化作一团火球，只是电影《重返地球》中人家是从外太空来回到地球，而你却从来没有离开过地球。
对于一个初创企业来说，有什么比速度更珍贵的呢？Sam Altman（大名鼎鼎的YC董事长，更是大名鼎鼎的"硅谷创业教父“Paul Graham的接班人）如是说:“快速推进，速度是你逃离巨大竞争吸力的最主要的方法”。 而Eric Ries所提出的当前炙手可热的“精益创业”理念大部分说得也就是速度的问题。那么对于一个初创企业来说，速度最大化以避免你的企业坠毁的灰飞烟灭究竟意味着什么呢？下面我们就好好分析分析！
初创企业发展速度模型
初创企业跟火箭一样都是按着一个速度往前推进的。在物理学中速度指的是在某个时间内推进的距离。而对于初创企业来说，速度意味着企业发展的进度（上图右上的Progress）除以所需的时间（上图右下的Time）。假设一个初创企业所需要投入的资源成本就是时间，进度就等同于获取到的商业价值，那么替换到以上的公式就得出了你的ROI（投资回报率）！
作为一个初创公司来说，你将会面临很多的不确定性，你很难去预测你下一次迭代的功能点收效如何。你的预测结果也许会命中，但大部分情况下往往结果会是错的，你所能做的事情就是去快速投放市场验证然后观察效果。总的来说，初创企业在每次迭代时所取得的进展平均起来都是很小的，因为在10个功能点快速验证当中，你如果有几个效果是很成功的话已经是非常阿弥陀佛的了。
为了在我们的初创企业速度模型中更好的描述这些令人担忧的因素，让我们把迭代进度进一步细化成“预期功效“（下图右上的Expected Win）和“成功机率”（下图右上的Success Chance）。在下图中你就能看到每次迭代中低迷的”成功机率“会大大的拖住每个初创企业的发展速度。这我们总不能坐视不管啊。
好消息是在上面的迭代效率模型的底部你还有个叫做时间（Time）的东西让你扳回一城。你将需要竭尽所能的在每次迭代中用尽量短的时间将功能推出市场进行快速验证。同时，迭代时间又可以细分成以下两个主要部分：
开发时间：所有直接对产出做出贡献的活动— 编码、设计、测试以及部署速度。
间接消耗时间：研究、讨论、头脑风暴、计划等等。)
最终得出的细分的迭代效率模型图如下：
从中可以看到，如果能把开发时间（上图右下的Development Time）和所有间接消耗时间（上图右下的Overheads Time）拉下来的话，你就能大幅度的提升你的初创企业的迭代速度。如果仅仅测试一个小改动你就需要花费几个小时的测试时间的话，那么，兄弟，这意味着你的产品开发正面临着一些严重的问题，是时候开始做点事情了。同理，在你费尽口舌耗费几个小时来说服你的小伙伴们来认同你的观点期间，你其实已经可以将它实现出来并开始进行测试了。少说，多做！
那么我们可以做些什么事情来加快我们每次迭代的进度呢？答案是肯定的，建议如下：
从潜在价值高的功能入手——首要的就是要关注在那些你在短期内可以实现的、给你的产品带来重大改观的那些功能点上面。
好好对你的上一次迭代进行研究分析，以便更精准高效的对这次迭代的预期效果做出评估以提高成功率。
对大功能点要抱着如履薄冰的态度——虽然大的功能点往往会带来可观的赢面（注: 为了方便大家理解，这样说吧，我现在做个产品，有个功能点叫做QQ。这功能点赢面够可观吧？但你不把它细化的话，你根本就会找不着北该如何入手去做，只能东搞西搞的把投资人的金钱烧得无影无踪而已。)，但它们同时也会充满风险和消耗时间（基本上，大功能点会拖你后腿让你行动缓慢）。
好的，理论分析完了，完整的初创企业速度模型和迭代效率模型我们都有了，那么是时间来找个麻雀来解剖下了。
案例分析
不久之前我正好给一个面临着开发时间严重挑战的初创企业进行指导。他们的组成成员其实都是一级棒的，非常有天分。其实他们都非常想做出点改变，但是事实上又对他们的产品开发进程裹足不前这种状态束手无策。开发和部署一个小功能往往都会耗掉大家超过一个星期的时间。很多不错的功能点一直都只能在他们的ProductBacklog（Scrum术语：产品清单）或者Sprint Backlog（Scrum术语: 冲刺清单）中长眠不醒无人触碰。大伙慢慢变得意志消沉备受打击但又无可奈何。
为了解决这个问题他们也尝试过想出一个这样的解决方案来：根据商业价值和实现技术复杂度来对每个功能点进行评估（其实和我们上面的迭代效率模型已经很接近了，只是他们没有把风险/成功机率给考虑进去）。他们希望对每个功能点都做详尽的分析，以便更精确的把握这些功能点的潜在回报率，然后再从中挑选一些出来进行迭代实现（注:可以想象这样的流程在一个迭代中将消耗大量的间接时间）。
为什么他们得做法不奏效呢？
后来的方案没有把大功能点的潜在风险考虑进去，这就导致了他们高估了（拥有最高风险的）大功能点所带来的价值，而反过来又低估了小功能点优化所带来的价值。
最开始方案的过长的开发和部署时间，导致了大量的优秀功能点没有办法在迭代中完成，时间不够。
后来的方案中对每个功能点进行额外分析所带来的间接时间消耗，就让上面模型方程式中的分子变得越加庞大，分子变大了，结果当然是等式左边的迭代效率下降了。
所以，该方案一开始就走错了方向，因为没有把问题定位到过慢的开发时间上面来。通过限制从Product Backlog中取出的功能点数量，并要求对每个功能点投入额外的调研时间，来确定哪些功能点需要放进当前的Sprint Backlog上面，这只会大大的拖住你的初创企业往前迈进的后腿。其实他们更应该关注的是去降低开发部署时间，以及其他间接消耗时间（包括那些额外的调研），以确保尽量多的功能点能得到尽快实现并投入市场进行验证。
结论
以下各点就是从初创企业速度模型提炼出来精髓：
在产品开发期间，把目标瞄准那些具备可操作性的优秀功能点上，把功能点的实现并推向市场的时间最小化。把你的开发周期压缩到以小时为单位，而不是以多少周来衡量。交付MVPs（最小可行产品）而非大而全的产品。
别妄想你能准确预测用户对功能点的接受效果。离开你舒服的椅子，走出你的办公大楼去寻找真正的用户进行验证。别害怕失败，只要你能从中学习，别在同一个位置上栽两次跟斗就行了。
别把好的功能点都放在你的Product Backlog中睡懒觉，确保你有足够的“带宽”来处理那些最“有前途”的功能点。
别让上面说的那些“间接消耗时间”拖了你的后腿。避免那些过长的无谓讨论或所谓的长期计划，快速迭代反馈才是王道。
尽量把大功能点细化成小的步骤来付诸实现和验证。耗时的大功能点只会让你举步维艰。
最后笔者感叹下：道理每个人都懂，为毛国人都这么浮躁没人去总结呢！？
英文文章参考：https://medium.com/@skalskiw/the-physics-of-startups-startup-speed-model-b014fab7deec。作/译者：天地会珠海分舵，原创博客：http://techgogogo.com，微信公众号：TechGoGoGo