Angelo翻译的《大教堂与市集》第四章 “早发布，常发布”中，埃里克"斯蒂芬"雷蒙（Eric Steven Raymond）用Linux之父李纳斯的实践为例，说明“快速发布，汲取用户反馈”可以使产品及早并持续获得改进，同时由于用户获得参与的激励和奖赏而更加忠诚；以及通过“足够多的眼睛，就可让所有问题浮现”，并通过群体智慧防止致命错误，或让致命错误及早暴露而减小损失。由此，Linux也逐渐侵蚀着Windows的市场、而成为主流操作系统之一。

苹果公司却是“早发布，常发布”的反例，为了防止“产品未发布之前就遭到一些无耻公司的克隆”，“iPhone的所有细节保密了长达30个月”：

苹果公司一向有着严守新产品机密的传统，但此次将iPhone的所有细节保密了长达30个月也是他们的第一次……
乔布斯称，尽管Yahoo和Google的程序对于iPhone软件来说至关重要，但他们（包括开发人员甚至公司老板）都是在发布会之前才第一次看到 iPhone真机。软件的开发都是在没有见过原型机的情况下完成的，苹果还故意伪装了软件版本，让程序员无法看到真正的界面。
作为销售方的Cingular在几周以前才看到iPhone原型机的真身。在之前的大部分情况中，Cingular拿到的都是一款专门制造出来的“假原型机”，而就算苹果自己的员工经常看到的也是它。
苹果公司营销总监Phil Schiller从头到尾参与了iPhone的开发过程，他说他必须对老婆和孩子保密。当他昨天启程赶往发布会的时候，他的孩子还在问：“爸爸，你终于能告诉我你在干什么了吧？”

最终iPhone“时尚流行核爆炸轰然爆发”！

Linux对比iPhone，一面是“赤条条毫无牵挂”、“妹妹大胆地往前走”，另一面却是“养在深闺人不识”、“千呼万唤始出来，犹抱琵琶半遮面”。李纳斯成功了，乔布斯也成功了，那么到底早发布，还是晚发布呢？

在用户成为产消者的今天，“快速发布和淋漓尽致的使用网络协作”原则上是没有错的，但是我们要控制好产品发布的粒度和范围，处理获得好用户反馈和保守创新秘密、防止恶意克隆的关系，处理好适度披露产品信息、以便合作伙伴协同和赢得早期用户口碑与制造营销事件轰动的关系。

1. 产品发布的粒度

我们需要注意到李纳斯是一名技术专家，而目前广泛采用“快速发布和淋漓尽致的使用网络协作”的Web2.0创业团队们往往是技术人员主导的、或还处于技术主导时期。

技术主导一般意味着功能主导(Feature-Oriented)，或者说技术主导的产品发布往往是以功能(feature)为粒度(granularity)或基本单位。我们可以看到他们的发布公告中提到“这一版的新功能是……”，此外“这一版改正了多少错误(Bug)”。

功能为粒度(feature-based granularity)的产品发布的弊端，在于以产品为中心、而非以用户为中心，在于以功能为中心、而非用户价值为中心。

这种方式或态度的第一个明显的恶果，就是发布公告只有技术型用户才能看懂，而且发布公告缺乏煽动力、缺乏诱使用户试用的冲动。因为往往使用技术语言，忘记解说功能的用户价值，更没有展现用户使用场景。

第二个恶果将是，即便有产品经理掌握用户价值，却因为功能为粒度、以及计划中的发布期限的限制，而割裂了用户价值，结果发布的是一个半成品、是用户价值残缺的版本。这样往往导致用户的恶评，让用户对产品进而远之。

功能为粒度的产品发布只适合于技术型产品，只适合于跟随型产品(比如Linux vs. Windows)，因为用户价值成熟清晰、或专业型用户对用户价值有清楚认识或能够快速理解。

功能为粒度的产品发布往往是技术型创业团队不得已而为之的举措，因为缺乏产品经理或缺乏相关的知识和训练。

在如今用户注意力稀缺的年代，在面向消费者的产品的情况下，必须采用以用户价值为粒度(user-value-based granularity)的产品发布，产品的发布必须由产品经理主导，产品发布公告应该由产品经理撰写。也就是说面向最终消费者的“早发布，常发布”必须提供完整的用户价值，必须有完整流畅的用户使用场景。

在完整的用户价值粒度版本之下，可以通过“受控的Beta”，向有控制的少数典型用户(Pesona)多次发布功能为粒度的产品版本，以便验证对用户价值的猜想、验证产品设计(比如使用场景)。

千万别向最终消费者发布你的Beta，别糟蹋你的Beta版！

待续：

Technorati Tags: beta, value, feature, granularity