米柚(MIUI)的迭代开发

，跟信号、周边环境、跟他们装的软件有关的问题等等，用户可以开拓你的想法。从功能来说，很少有人告诉你喜欢什么，很多时候用户告诉你他不喜欢什么。

也有个别靠谱用户，产品设计都给你写好了，那就照着做吧。

容错机制简化管理

TBR：从事迭代开发的组织，你觉得怎么样可以既有序高效又可以保证活力和创新，这方面管理有什么心得和体会？

洪锋：经过一段时间，大家进入角色以后，现在觉得没有太大的困难了。更多还是节奏感的问题：什么时候进代码，什么时候测试，什么时候稳定，什么时候推出。

我们可以保持这种节奏是因为我们有容错机制：

荣誉测试组只有几千个用户，在这个版本上，各种功能包括一些想法激进的功能，都可以拿上去试，不靠谱的主意直接被用户拍死了，这个用户群对版本的稳定性水平有很高的包容度。到开发版上会有更多的用户反馈。最后我们推出稳定版，就相当于一个功能一个主意已经经过了一个月以上的考验，通常不会出很大的问题让我们手忙脚乱。

所以对于快速迭代的产品，要找到开发的节奏感吧。

TBR：现在下面四五百个人，有三十多个项目团队，你有这么多的团队，你可能必须要跟这些teamleader经常沟通，你通过什么样的机制保证沟通充分？

洪锋：确实每天绝大多数时间都在和他们沟通。我尽量不成为所有事情的瓶颈。我基本上给team定一个大方向，我不可能每一个UI（User Interface，用户界面的简称）发布前都去看，这样我会成为他们的瓶颈。

我们为什么分成每天、每周、每月三档来更新，这种迭代开发方式对于我们的管理起到很大作用。很多时候，team或者工程师觉得对了，那就先上，有的时候我和他们有分歧，或者当大家争执不下的时候，我会更倾向于先上。

因为每天一更新的版本，不需要我过问，那是他们的试验田，新功能上去之后，我会看每天的更新，我觉得不靠谱，我就会骂他们，用户觉得不靠谱，骂得比我更严重，因为我要照顾他们的情绪，用户才不管，劈头盖脸就骂，这样其实效果很好，有时候也不需要我说，用户说的比我多。一个功能或者修改在最初版本上可能会有一到两周时间，让几千个荣誉开发组用户用。看设计稿跟真正用这个功能是不一样的——就像喝酒，喝一口跟喝一瓶感觉是不一样的，喝一口觉得不错，喝一瓶，就觉得不能多喝。所以要真正用起来，才知道说不定想错了，觉得不好的主意说不定很不错。最后到稳定版上推出，就相当于一个主意已经经过几百万用户一个多月的使用了。这样我的工作分担到了很多用户身上去，他们会帮我监督。

迭代开发具有极大的容错机制；如果你一上来就面对所有的用户，就让你不敢创新，因为创新如果犯错，代价太大了。通过三个版本的迭代，可以极大地降低犯错几率。

目标第一，手段第二

TBR：据说小米没有KPI考核，但是不同的团队、不同的人，毕竟能力和产出都是不一样的，怎么样保证优秀的团队更能得到激励？

洪锋：“没有KPI”得看如何理解，我们没有那种定量考核的“经典KPI”制度，完全没有数字目标是不可能的。经典KPI更多把这个KPI和收入结合在一起。如果你把KPI和收入紧密结合在一起，很容易奖励短视行为。我觉得上市公司每一个股东都看季度数字，其实是非常奖励短视的行为。KPI很难科学设置，例如我希望提高搜索质量，那搜索次数多了好还是搜索次数少了好？多了可以解释说，因为搜的质量好，所以用户就用得多了