不仅是创业者，每个人都应该读一读

我这几天看完了《精益创业》，感想颇深。其实在开始读这本书之前，就对它的大名如雷灌耳，而且去年在澳洲的时候还有幸见到了作者Eric本人。但是我心中一直都有些疑问，这本书不是讲“创业”的吗？这本书不是讲在高度不确定的环境下的求生之道的吗？这些离我的现状好像很远，我真的需要读这本书吗？我就是这样带着很多“质疑”开始看这本书的，当刚刚看了一半的时候，我就已经被深深地震撼了。 首先，这并不只是一本告诉你如何“创业”的书。“创业”的确是一个在高度不确定的环境下开展一项新事业的过程，但是这并不仅限于创业，比如在成熟的企业中尝试发展新事业也是这样。或者说，只要是在“高度不确定”的环境下尝试新事物的过程，都是广义上的创业。熊节(http://weibo.com/gigix)前不久在微博上感慨成都Office一年来的发展时，说的就是“创业有艰辛，更多的是快乐。” 另外，说到“高度不确定性”这个事，我也觉得它离我很远。这大概是受到大量文学作品的影响，很多人对那些“天才”企业家的故事耳熟能详，似乎他们拥有卓越的洞察力，能以超人的胆识，在众人皆迷茫的时候为企业的发展指出一条光明之路。而我自己所处的环境其实是稳定的，没有悬念的。不过，书中有大量的例子，非常清楚地告诉我，“高度不确定性”是个普遍的现象，为了不过度剧透，我只举一个例子： －《精益创业》的作者Eric曾经任职于IMVU，一家开发3D人像（Avatar）的公司。在他们发布某一次版本的新产品后，得到了一条用户反馈：希望3D人像能够移动，就像“虚拟人生”游戏那样。但当时作为新创公司的IMVU来说，没有时间和能力去实现什么3D引擎和复杂的算法。因此他们做了一个“艰难的决定”：当用户鼠标点击屏幕上的一点时，让3D人像瞬间移动过去，而不是一步步地走过去——作为一个临时方案，暂时给用户一个反馈。IMVU的团队抱着紧张的心情发布了这个“新功能”，认为客户必定会排山倒海地批评他们。但是，令整个团队震惊的是，他们收到的是排山倒海般的赞美——客户觉得这种移动方式“太帅了，比'虚拟人生'的还高级”，因为用户就想改变人像的位置，而不愿意看着人像在屏幕上慢慢地走动。而且，这个功能在很长的时间里都排在“客户最喜欢特性”的TOP 3。反而很多IMVU认为“我们花很大力气开发的引以为豪的特性”却从来没有被用户注意过。 这个例子像一个触发器，让我想起了很多项目中曾经经历过的故事。比如有一次我出差，到了客户现场，一位同事和客户第一次交流，还没出十分钟，客户已经说出了一个功能模块的某些地方“不是我想要的，这根本不是我的工作方式”。为此我们连夜开发了一个小功能，而这个赶工出来的“补丁”却能为客户和他的同事节省大量时间（但其实这个价值最终并未实现，因为我们从提交代码到生产环境部署的周期（cycle time）太长了）。敏捷软件开发的宗旨是杜绝浪费，但是开发了客户不需要的功能是最大的浪费。我相信，如果你认真思考一下，一定不难在自己的项目中找到这样的例子。 因此，我现在十分肯定地说，我们都生存在一个高度不确定的环境下。这个时代是个普遍高度不确定的时代。《黑天鹅》这本书也验证了我的观点。 但是真正让我转变看法的还是有一次我们给客户的Boss介绍“性能测试策略”时发生的事。客户对系统对性能的要求非常苛刻。于是我们准备了自认为完善的方法、流程，信心十足地要实现客户提出的任何性能的要求。介绍到了最后，我们问这位Boss：“页面加载要几秒，支持的在线客户要多少K，你说个数吧，我们去做。”然而他回答竟然说“我也不知道”。！！好吧，这感觉就好像我们准备好了一辆跑车，就在启动发动机，踩下油门的一瞬间，问乘客“要去哪儿”，乘客却说“随便哪儿”。“呜～～～”发动机一阵空响，我们要做无用功了。 其实，我并不是在抱怨客户“无知”。这是一个“高度不确定”的问题。想想影响性能的因素吧： . 服务器的负载 . 网络带宽 . 浏览器渲染速度 . 同时在线用户数 . 数据库已保存的数据量 . 用户的使用习惯 . 用户所处的地理位置 . 用户的心情 …… 最终这些因素都变成一句“好”，“一般”或者“不好”。这样的问题，是个何等复杂的方程式啊 y ＝ f(服务器的负载, 网络带宽, 浏览器渲染速度, …) 如果这时谁真的给出了一个答案，我倒要怀疑这个答案的真实性了！因此，反思我们（或者说业界）做性能测试的流程通常是： 设定指标 -> 努力完善 -> 达到指标 这个流程只发生在上线前夕。结果要么就是性能问题无法解决，要么延期上线。要解决这个这个问题，就要运用《精益创业》所讲的方法， 经证实的认知（Validated learning） 也就是说，提出一个简单的“假设”，然后快速地“证实”它的真伪，以此改进对最终目标的“认知”。其实就是一个“开发－测量－认知”的过程。不过这个过程要足够快，足够频繁。听着很熟悉？我们开发阶段的简单设计、TDD、重构其实就是编码阶段的“Validated learning”的过程。现在只不过是把相同的过程应用在更大的范围内。客户有这样的担心，说不出到底什么是“好的性能”，但是又担心性能问题会给他们带来“差评”，严重的时候会影响到整个项目的推进。这种担心对于“传统的”项目的确真是存在。如果用户抱怨性能问题，每次抱怨后我们要花六个月的时间来改正错误，那么就是一个极大的风险，因此客户要极力地在前期避免。但现实条件又不允许我们一口气做出梦幻般完美的产品（也许更大的、更富有的公司可以，也许吧）。因此必须不断地调整目标，不断地证实性能问题确实在被改善。试想，如果用户今天抱怨了性能问题，我们能够在第二天就部署新的版本，这个版本不一定彻底解决问题，但是一定要让用户看到改变。我相信，如果能做到这一点，客户就不会对性能问题如此敏感了，也就能有信心了。 说的这里，我想起ThoughtWorks的王鹏超曾经说过，“TDD能让你写出天才般的代码”。好的单元测试催生出好的代码。类似的，好的性能测试（或者性能测试级别的TDD）也应该能催生出好的架构。对此我愿意拭目以待。一个公司要能够在不确定的环境下成功交付软件。即使没有IBM的庞大、微软的资金、Google的基础研究能力，也能够采纳最优化的流程来弥补不足，这依然能帮助我们成功地交付软件，甚至比那些更大、更富有的公司做得更好。 敏捷软件开发方法论经过多年的发展，已经对“开发过程”做了高度的优化；几年前兴起的“持续交付”运动，又对开发后期的“最后一公里”问题给出了药方；今天，“精益创业”和它提倡的价值观与实践，为开发前期确定“做什么”给出了指导。我一直是个持续交付的鼓吹者。如果以前这热情来自于荷尔蒙，那么现在，它是来自于一个更理性的诉求。 最后，推荐你读一读这本书：）