导读：对于一个初创企业来说，有什么比速度更珍贵的呢？Sam Altman如是说:“快速推进。速度是你逃离巨大竞争吸力的最主要的方法”。 而Eric Ries所提出的当前炙手可热的“精益创业”理念大部分说得也就是速度的问题。那么对于一个初创企业来说，速度最大化以避免你的企业坠毁得灰飞烟灭尸骨无全究竟意味着什么呢？下面我们就好好分析分析！
物理学上有个术语叫“逃逸速度”，指的就是一个物体如果要逃离万有引力的约束所要达到的速度。一个火箭上升的初始速度如果能达到11.2km/s以上的话就能够冲出地球走向宇宙一去不复还。如果低于这个速度的话，那对不起，你将需要消耗更多的燃料慢慢的推动着火箭往上升，最终的结果可能就是上演一出真实版的“重返地球”最终坠毁化作一团火球，只是电影《重返地球》中人家是从外太空来回到地球，而你却从来没有离开过地球。
对于一个初创企业来说，有什么比速度更珍贵的呢？Sam Altman(天地会珠海分舵注：大名鼎鼎的YC董事长，更是大名鼎鼎的”硅谷创业教父“Paul Graham的接班人，他说的话我们就别怀疑了。本人有幸翻译过他们两者的文章，大家有兴趣的可以到本人官网进行查看和参考阅读。)如是说:“快速推进。速度是你逃离巨大竞争吸力的最主要的方法”。 而Eric Ries所提出的当前炙手可热的“精益创业”理念大部分说得也就是速度的问题。那么对于一个初创企业来说，速度最大化以避免你的企业坠毁的灰飞烟灭究竟意味着什么呢？下面我们就好好分析分析！
初创企业发展速度模型
初创企业跟火箭一样都是按着一个速度往前推进的。在物理学中速度指的是在某个时间内推进的距离。而对于初创企业来说，速度意味着企业发展的进度(上图右上的Progress)除以所需的时间(上图右下的Time)。假设一个初创企业所需要投入的资源成本就是时间，进度就等同于获取到的商业价值，那么替换到以上的公式就得出了你的ROI(投资回报率)！
作为一个初创公司来说，你将会面临很多的不确定性。你很难去预测你下一次迭代的功能点收效如何。你的预测结果也许会命中，，但大部分情况下往往结果会是错的。你所能做的事情就是去快速投放市场验证然后观察效果。总的来说，初创企业在每次迭代时所取得的进展平均起来都是很小的，因为在10个功能点快速验证当中，你如果有几个效果是很成功的话已经是非常阿弥陀佛的了。
为了在我们的初创企业速度模型中更好的描述这些令人担忧的因素，让我们把迭代进度进一步细化成“预期功效“(下图右上的Expected Win)和“成功机率”(下图右上的Success Chance)。在下图中你就能看到每次迭代中低迷的”成功机率“会大大的拖住每个初创企业的发展速度。这我们总不能坐视不管啊。
好消息是在上面的迭代效率模型的底部你还有个叫做时间(Time)的东西让你扳回一城。你将需要竭尽所能的在每次迭代中用尽量短的时间将功能推出市场进行快速验证。同时，迭代时间又可以细分成以下两个主要部分：
开发时间(所有直接对产出做出贡献的活动—编码，设计，测试，以及部署速度)
间接消耗时间(研究，讨论，头脑风暴，计划，等等。)
最终得出的细分的迭代效率模型图如下：
从中可以看到，如果能把开发时间(上图右下的Development Time)和所有间接消耗时间(上图右下的Overheads Time)拉下来的话，你就能大幅度的提升你的初创企业的迭代速度。如果仅仅测试一个小改动你就需要花费几个小时的测试时间的话，那么，兄弟，这意味着你的产品开发正面临着一些严重的问题，是时候开始做点事情了。同理，在你费尽口舌耗费几个小时来说服你的小伙伴们来认同你的观点期间，你其实已经可以将它实现出来并开始进行测试了。少说，多做！
那么我们可以做些什么事情来加快我们每次迭代的进度呢？答案是肯定的，建议如下：
好的，理论分析完了，完整的初创企业速度模型和迭代效率模型我们都有了，那么是时间来找个麻雀来解剖下了。
案例分析
不久之前我正好给一个面临着开发时间严重挑战的初创企业进行指导。他们的组成成员其实都是一级棒的，非常有天分。其实他们都非常想做出点改变，但是事实上又对他们的产品开发进程裹足不前这种状态束手无策。开发和部署一个小功能往往都会耗掉大家超过一个星期的时间。很多不错的功能点一直都只能在他们的Product Backlog(Scrum术语：产品清单)或者Sprint Backlog(Scrum术语: 冲刺清单)中长眠不醒无人触碰。大伙慢慢变得意志消沉备受打击但又无可奈何。
为了解决这个问题他们也尝试过想出一个这样的解决方案来：根据商业价值和实现技术复杂度来对每个功能点进行评估(其实和我们上面的迭代效率模型已经很接近了，只是他们没有把风险/成功机率给考虑进去)。他们希望对每个功能点都做详尽的分析以便更精确的把握这些功能点的潜在回报率，然后再从中挑选一些出来进行迭代实现(天地会珠海分舵注:可以想象这样的流程在一个迭代中将消耗大量的间接时间)。
为什么他们得做法不奏效呢？
所以，该方案一开始就走错了方向，因为没有把问题定位到过慢的开发时间上面来。通过限制从Product Backlog中取出的功能点数量，并要求对每个功能点投入额外的调研时间来确定哪些功能点需要放进当前的Sprint Backlog上面，这只会大大的拖住你的初创企业往前迈进的后腿。其实他们更应该关注的是去降低开发部署时间以及其他间接消耗时间(包括那些额外的调研)，以确保尽量多的功能点能得到尽快实现并投入市场进行验证。
结论
以下各点就是从初创企业速度模型提炼出来精髓：
最后容天地会珠海分舵感叹下：道理每个人都懂，为毛国人都这么浮躁没人去总结呢！？
版权:本作品采用[创作共用署名3.0中国大陆版许可证], 若非授权，转发时切勿删除以下联系信息，否则追究相应责任。
提醒:更多最新文章将首发本人官网和微信公众号:techgogogo。敬请大家期待。
人爱美，不仅需要服饰居室之美，还需要心灵品德之美。
