从 Devver 失败看程序员创业容易陷入的盲点

今天分享最有趣、最具启发性的Startup创业失败故事，失败并不可怕，一切都可以从来，希望这个故事能给正在创业的程序员一点启示。

这次要说的故事值得所有有志创业的程序员作为借鉴，纯技术型的开发者在创业时会遇到什么样的困难和挑战？

来看看Devver的失败案例吧！

一、Devver简介与历史

Devver创立于2008年，主要提供开发者云端测试的服务，他们开发出了一套独家的技术，让开发者可以把测试工作分布在多台远端服务器上处理，这比在本地单一机器处理快上许多。测试工作常常耗掉开发者许多的时间，透过这个方式开发者可以把测试时间降低到只剩原本的三分之一，大大地提升了开发者的工作效率。

经过估算，他们的产品的市值高达数十亿刀，听起来就让人觉得非常靠谱？Devver原本只支持Ruby这个语言，后来还打算推出Python、PHP、Java的版本，不过这个愿望最后都流产了，因为他们只撑了两年他们就正式宣布关闭服务。Devver在成立之处就获得了50万美金的A轮融资，在Ruby开发者圈子里面中也算小有名气，但一直到最后，再也没有从资本市场的亲睐…这中间到底发生了什么事？且让我们看下去……

二、失败原因探讨

就在Devver于官方博客宣布关闭服务后，两位创办人Ben Brinckerhoff和Dan Mayer共同写了一篇文章回顾了这趟惊奇的两年创业之旅，这篇文章中他们深刻地反省了过去所犯下的错误，笔者整理如下：

（1）团队只有技术型创办人

相信这里应该不难猜到，这么宅的创业idea是程序员想到的，事实上Devver的原型正是两位工程师创办人做project时无意间的产物，而且团队也只有他们两个创办人了。

在硅谷有个很普遍的说法：“你可以教Hacker做生意，但你很难教商人Hacking”，这句话或许是对的（很多技术型创办人同时也是伟大商人），不过他们认为团队中只有技术型创办人，并不是最有效率的配置方式。理由是即便Hacker可以学怎么做生意，但并非所有Hacker都对这件事很有热忱。

程序员或许可以学Business Model、Pitch、社交、行销、客服等做生意的技巧，但他们最擅长的一定是写代码，即便是一间技术性的创业项目，仍然有许多非技术性的重要工作需要完成，若能把这些工作交由专业的商业人才处理，可以省下很多宝贵的时间，让程序员专注在擅长的事情上才是最明智的选择。

（2）远距离管理运营团队

Devver的团队一直保持着远程开发沟通，这当然有相对应的好处，譬如更能吸引到优秀的人才、增加程序员的生产力等等，不过行政上的管理就变得非常棘手了，Devver的团队成员分布在三个州，每个州管理薪资、失业和保险的法规都不同，这对于小型Startup来说简直就是噩梦，这也迫使创办人花了很多时间处理行政上的琐事，无法将100%的心力投注在产品上，就拿目前我们程序员客栈来说，我们有100%的信心可以解放开发者，却没有百分百的信心解放我们的自己的运营团队，总不能让我们公司的BD、PR、行政、财务都兼职吧？

（3）他们以为产品很有市场，但其实很小众

第三点是关键中的关键，当两位创办人开发出Devver的原型后，许多潜在顾客都对他们的产品都很有兴趣，他们以为自己找到了MVP（minimum viable product，最小可生存产品），然后他们就开始「埋头苦干」全力开发产品，这段期间几乎没有跟潜在顾客接触，等到他们把产品做出来之后，才发现自己根本没搞清楚市场大小跟技术上会遇到的问题，如果他们这段期间有好好的接触使用者的话，他们应该会早点发现：

虽然有些程序员觉得等待测试的时间很烦人，但大部分的人都不觉得有必要缩短测试的时间。反倒是很多人希望有一个更简单、无加速功能的云端测试服务。

他们花了太多时间在钻研「缩短测试时间」的技术上。当然这点很重要，但在推出产品之后，他们才发现针对不同的Rails application「调整服务器设定」才是最麻烦的地方，这件事情没做好，使用者会很难使用他们的产品。但因为他们一开始没有先想到这点，所以在早期产品开发时做了程序工程上的错误决定，导致调整服务器设定这件事情变得异常的棘手。

如果当时有一位非技术性的创办人，或许就可以由他来负责与消费者沟通，早点理清楚市场潜质和开发方向，当他们已经投注大量资源和心力推出产品后才发现这些问题时，一切都已经太迟了。

三、结论

留言最热门的Ben Brinckerhoff在文章底下回复了一位读者的留言，笔者认为很适合作为创业经验的总结：

Customer development is an ongoing process.Once you’ve identified an MVP（which is an iterative process itself），the next step is to keep iterating as you add or improve features.Measure how the product is performing along key metrics，talk to customers，merge customer feedback with your vision，build and improve features，and then do it all over again！

与客户沟通是一个不容间断的过程。一旦你决定了你的MVP，就必须在开发期间保持与客户的联系。这三件事—运用关键指标测量产品表现、收集客户反馈、根据反馈改良产品，必须一直重复地做下去！
Devver的失败可说是「产品凌驾使用者」的经典案例，这个故事告诉我们，创业者必须保持与使用者沟通的习惯，绝对不要做好产品才发现解决了错误的问题，或发现idea缺乏足够的商业价值。很多程序员热衷于解决技术上的挑战，却忘了使用者实际的使用状况，这在创业场上是兵家大忌，时时刻刻倾听使用者的心声，才是致胜的不二法门！