Getting Real,紧扣关键简单而快速地执行
无意间在Android的电子市场中看到名为“Gr”电子书,我被介绍中“由著名的 37signals 团队/Ruby On Rails 的创造者们撰写”直接拿下,毫不犹豫地下载阅读。但我最终还是PC上读的CNBorn汉化版,3.2英寸的屏幕毕竟还是很不利于快速阅读,查阅资料和记录。现在,在我已经看完的几十个小时之后,Getting Real 提及的原则和经验还是不断在我脑海中激荡,37signals 也变得愈发神秘起来。豆瓣的团队大概很像他们吧,谁知道呢,一样和令人敬佩。
Getting Real 给我印象最深的是:抓住关键,快速执行,避免细枝末节,并且不要在模棱两可的问题上花费时间。
抓住关键
抓住关键告诉我们对于那些不确定的因素不去过多考虑,把节省下来的时间投入到辨识哪些才是我们真正想要的,例如产品的闪光点。要知道前期多规划一个新功能,可能导致后续任务量、开发难度和整体风险呈指数级地增长,给后续工作带来极大挑战,开发人员勤勤恳恳抱怨时间不够,而这个功能却往往最终成为鸡肋。抓住关键也告诉我们要对一些想法说“不”,拉得过长的战线除了风险并不能给我们带来更多的好处。它往往会导致我们无法推出“产品的一部分”,而是“一个残缺的产品”。
快速执行
持续运营的网站面对的是,变幻莫测的市场,复杂的用户群,日新月异的技术,曾书不穷的竞争,完全不同于传统的项目型网站开发。我们的时间很宝贵,很多时候没有时间去做详细的构想和设计,保持警觉,快速响应和拥抱改变才是我们应具有的心态。快速执行而不是停留在脑海里和白板上,在风险可控的范围内让用户和市场去检验。
避免细枝末节
一开始就钻入对细枝末节的注重往往会因为缺少对整体的把握而让我们失去方向,投入细枝末节也会挤占宝贵的时间,而且可能会引出更多的细枝末节。过于细节的东西需要花费大量的时间来思考和设计,需要考虑各种复杂的情境,但如果不做也不会对当下产生过于消极的影响。如果我们第30天的时候才需要这种功能,那我们完全可以把它放在第25天来实施。
简单决策
对于模棱两可的问题就由开发者决定吧,因为这实在不会对产品有什么举足轻重的影响。
37signals 希望团队里的成员个个都是多面手,都对产品和流程有很高的任何并且积极投入工作。我们没有这么好的团队,所以我们要注重内部的培训,注重沟通和建设,让每个人对产品和流程都一致的认可。
Getting Real 并不长,但设计了软件产品生命周期的各个阶段应注意和把握的原则,是一些来源于实践的用于指导实施很有用的经验,值得一读,想品味原汁原味的可以点击这里。

4点都做不到
大概更适合不急功近利的小型项目,尤其是开源项目吧。
给产品做减法,说了一年多了,希望能实现吧。
恩,想实践这些还不是很容易呢。37signals 以及一些国外的团队和国内的情况还不太一样,他们的产品人员都是多少有着开发背景,对用户代码优化甚至市场都有或多或少的综合了解。我非常认同千鸟的一句话:“我希望国内所有从业者都看到老外同行们深厚的技术积累,而不仅仅风光的创意想法。”,国内一些公司,包括腾讯和有着精良团队的豆瓣招聘时也在做交叉面试。但想十足做到这种“境界”还是很不易的。这和国内的hr成本低下,重寻找而不重培养,很多公司在hrm上表现地不够成熟和草率也是不无关系的。当然人的问题只是诸多问题中的一个而已。