编者按：本文作者是Pragmatic.ly 创始人叶玎玎。Pragmatic.ly 是一个纯技术背景出身的团队，在两年的创业中走了不少技术型团队很很容易会走入的弯路，本文作者分享了其中的一些经验和教训。原文最先发布在他的个人博客，你可以通过微博联系他 @yedingding 。 准确说，Pragmatic.ly 从有这个想法到现在已经有 2 年了。11 年 10 月份的一个晚上跟 Daniel 和 Terry 在对我们所有用过的项目管理工具吐完槽以后，然后决定自己造一个，12 年春节前后真正当个事做，4 月底 Ben 加入，7 月份发布 Beta，先在海外做了差不多 8 个月，今年 4 月份开始调整方向，转向国内，6 月底重新上线到现在，整个过程各种状况各种弯路，但是每天都能感觉到变化，每天都是新的学习，乐在其中。 那些年我们一起走过的弯路现在回过头看看，我们犯了好几个大的错误，当然，也许这些可能很多技术型团队必须得走的弯路。 过早和过多地做开发我们创始团队的构成是两个开发和一个设计，技术能力很强，市场能力很弱。当我们决定要启动这个项目的时候，我们没有去找更多的用户聊天，聆听他们的 想法，而是选择直接进入了开发阶段，美其名曰解决自己的问题。我们不停得去假想用户的需求，所有人都在做开发，直到发布。而整个过程，我们甚至没有去外界 透露我们的产品目标，没有去收集潜在客户，这也造成了后面的被动。也就是说，我们在整个前期过程中，没有一个清晰的特定的用户群，没有去了解这个用户群到 底存在什么问题，再去打造适合他们的产品，而是做出了产品后，再去寻找那个适应于我们产品的用户群体。所以当产品发布后，我们发现推广很难做，各种阻力， 因为定位不清晰，也就很难传递合适的信息给适合的人。 在 YCombinator 有个理论，在产品发布前，你应该专注并只专注两件半事情，1 开发 + 1 跟用户聊天 + 0.5 锻炼身体。了解你的用户群体，很重要。 太注重工程正确性对于一个技术型创业团队而言，而且是外包团队出身，技术研究总是能让人很兴奋，所以很容易就会沉迷于工程细节。开始编码时先设计个好的架构结构，看 到不好的代码就忍不住来几下重构，用 TDD、BDD 恨不得 100% 测试覆盖率，Backbone.JS、Ember.JS、Angular.JS、Marionette，不停地调研哪个最适合自己的项目。总之，洁癖太 重，不停地在追求工程上的正确性，没有把时间花在正确的地方，没有花在能给用户带来真正价值的地方。我们最需要的是什么？是能快速地发布快速地迭代，有反 馈才能有改进，而代码写得再漂亮对你的用户也是没有价值的。 即使到今天，我们也很难做到非常 quick and dirty 的做事情。不过比起第一天开始的时候，我们已经"改进"了很多，Make it work, ship it and then improve it. |
