小米开发的米柚(MIUI)操作系统目前已经有5000万用户，是迭代非常成功的案例。小米联合创始人洪锋详细阐释了MIUI的开发经验。
寻找合适的开发频率
TBR：我们知道米柚(MIUI)是经典的迭代开发产品，如果别的互联网企业希望借鉴米柚的迭代开发经验，您可否总结一下做米柚的心得？
洪锋：世界上没有什么事情是绝对对或者错的，只有适合或者不适合。
比如外界一直觉得MIUI每周更新的频率很好，但是这个节奏并不适合每个企业。事实上MIUI的更新频率对不同的用户组是不一样的。MIUI有三个更新频率，一天一更新，面对的用户大概是几千个，这个用户组我们叫荣誉内测组；一周一更新，面对几百万用户，这个组叫开发组；一个月一更新，面对的是90%的普通用户，有几千万（现MIUI总用户数已经超过5000万），推出的版本叫稳定版。
所以，首先，迭代不是越快越好，而是需要一个恰当的频度，这个频度到底怎么合适，要根据自己的用户特点来判断。比如说，你的版本一推出就是面对100%的用户，那可能每周更新的频度就不合适；其次，迭代只是手段，而不是目的，从MIUI来说，迭代最重要的目的是很近地贴近用户，让用户有参与感。如果有更好的手段和用户融为一体，我也会去选择其他手段。
全员与用户交朋友
TBR：对于一天一更新的荣誉内测组用户来说，这种更新频率是相当快的，需要他们有热情有时间，这个用户群稳定吗？怎么管理？
洪锋：这个用户群是一个自治的群体，有它的管理委员会，制定自己的规则和决定怎么发展组织，例如决定发展新会员的方式等等，当然，我们类似“发改委”进行一些调控。
小米手机推出之前，MIUI系统就已经推出运行了，开始是一周一更新。因为我们所面对的人群，是非常愿意折腾的人，他们希望得到更快的更新，他们能够容忍一定的不稳定和一定的不方便，他们觉得“我是来玩的”。就像有的人喜欢开摩托飙车，寻找的是速度的刺激。一开始米粉就是这样一群人。核心发烧友群体的人数应该是在增长。
TBR：荣誉内测组用户群会分享小米的收益吗？还是纯粹的发烧友？
洪锋：纯粹是发烧友。有利益分享的是另外一批用户，叫做开发者，他们帮助我们去适配更多的机型，使MIUI系统适用于更多机型，和更多用户分享，我们会根据活跃用户数给他们一定的工资或者分成，他们和荣誉内测组有一小部分人是重叠的。
TBR：米柚论坛是小米发烧友的重要阵地，是小米的重要反馈机制，随着用户的增多，你们怎么样让这个论坛保持沟通的有效性？
洪锋：其实小米做得特别出色的就是这一点：用户有任何一个想法和意见都可以到论坛上去发表，如果说得靠谱，会有人把帖子顶起来，如果说得不太靠谱，其他的用户很快就把你踩死了，这是一个相当于自由言论优胜劣汰的过程。在这个过程中，用户说的话不管靠不靠谱都得到了回应。最重要的其实就是沟通和交流过程本身，用户的意见得到聆听，他有得到尊重的感觉，而不在于是不是意见得到完全的采纳。现在很多消费电子产品，当用户遇到问题的时候，投诉电话都打不通，更不要说有个想法和意见能商量一下。
对于我们员工来说，每天有20多万的帖子，全体员工发疯也看不完。所以我们一些运营人员会把帖子归纳总结成200个不重复、有价值的，分门别类到各个部门，让工程师去解答。凡是进入到这个模块里的帖子，每一个帖子后面都有跟踪：谁在处理此事、采纳还是不采纳、采纳的话什么时候改好。
更重要的是，我们鼓励和引导全体工程师泡论坛。因为当你在论坛直接接触用户的时候，这种交流是有温度有感情色彩的，有人干脆，有人粗暴，用户他要觉得不对的时候就狠命骂你。所以虽然分给工程师的200个问题属于优先级工作，但是如果他真正跟用户在沟通，他觉得另一个事情确实很着急，需要先做，那就先做。我们希望每一个工程师都是在引导用户，与用户沟通，而不是把处理好的工作列表送给他们。
TBR：但是对于工程师与用户的交流，是没有硬约束的对吗？那么他们可能很忙，可能没有时间泡论坛，怎么引导他们？
洪锋：坦率说，也是因人而异。对用户来说，他们面对的工程师，也不是像客服那样彬彬有礼的，他们也有温度感，有的干脆，有的热情，有的不太理。我每周都会看论坛，加入问答活动，必须要处理的200个帖子的处理率是多少，这些我每次都会看。
引导工程师和用户交流、交朋友，主要还是要让论坛这件事情本身变得有趣。例如我们每两周去一个城市和米粉互动，开米粉会，这就是拉近工程师、产品经理和米粉的距离，工程师、产品经理能感受到用户的感情，用户对我们产品的热爱、期待、不满，人与人之间的沟通就形成了，很多时候他们就变成朋友了，然后就不再需要推动，交流就已经建立起来了，我们非常希望把工作变成是人与人之间的沟通。
TBR：米粉论坛现在已经形成自己具有生长能力的小社会了吗？
洪锋：小米论坛以前就像一个小作坊，有几千个忠实的食客，大家感情都特别好，有时候早期用户到北京来，会经常到我们公司来，大家一块儿吃个饭喝个酒，铁哥们。但是现在人越来越多了，公司越来越大，就变得不一样了。我们需要不停地做调整。
我们要不停地根据变化调整与用户互动的过程，让这个过程变得更有趣，包括我们会尝试新的模式，在YY里办频道，一两个星期办一次虚拟的大厅互动，改版论坛——把它从一个纯粹的产品吐槽论坛进行功能延展，成为一个泛小米论坛，有的人可能不一定是要吐槽小米的产品，而是移动设备爱好者，讨论怎么玩。所以我们一直在调整论坛的定位，一直在调整内容，以组织得更好。这就是我们说的，要把用户当成一个产品来做，论坛是一个和用户沟通的产品。
TBR：论坛上是小米发烧友，但是还有几千万的小米用户，这些用户的沟通怎么进行？
洪锋：我们手机上有一个软件叫“用户反馈”，坦率说，这是我们得到更大信息量的途径。更多的普通用户，是在手机里看到“用户反馈”，然后给我们反馈的，因为这个软件他用起来比较方便。
现在用户群庞大之后，我用更多的精力思考怎样跟用户沟通最有效。
我们希望以后客服更多通过“用户反馈”这种方式来进行：把语音和互联网服务结合起来，用户说有这样一个问题，客服说你截个屏给我，这可能比单纯的语音更能说清楚。
TBR：转化成真正产品功能的想法，大概有多少来自用户？
洪锋：很难算出一个比例，我们每个人都是用户。当你做消费类产品的时候，有一个很好的优势，就是你的员工很有热情，他们都是你的用户。各地的用户帮了很多忙，包括我们很多无法测试的，跟信号、周边环境、跟他们装的软件有关的问题等等，用户可以开拓你的想法。从功能来说，很少有人告诉你喜欢什么，很多时候用户告诉你他不喜欢什么。
也有个别靠谱用户，产品设计都给你写好了，那就照着做吧。
容错机制简化管理
TBR：从事迭代开发的组织，你觉得怎么样可以既有序高效又可以保证活力和创新，这方面管理有什么心得和体会？
洪锋：经过一段时间，大家进入角色以后，现在觉得没有太大的困难了。更多还是节奏感的问题：什么时候进代码，什么时候测试，什么时候稳定，什么时候推出。
我们可以保持这种节奏是因为我们有容错机制：
荣誉测试组只有几千个用户，在这个版本上，各种功能包括一些想法激进的功能，都可以拿上去试，不靠谱的主意直接被用户拍死了，这个用户群对版本的稳定性水平有很高的包容度。到开发版上会有更多的用户反馈。最后我们推出稳定版，就相当于一个功能一个主意已经经过了一个月以上的考验，通常不会出很大的问题让我们手忙脚乱。
所以对于快速迭代的产品，要找到开发的节奏感吧。
TBR：现在下面四五百个人，有三十多个项目团队，你有这么多的团队，你可能必须要跟这些teamleader经常沟通，你通过什么样的机制保证沟通充分？
洪锋：确实每天绝大多数时间都在和他们沟通。我尽量不成为所有事情的瓶颈。我基本上给team定一个大方向，我不可能每一个UI(User Interface,用户界面的简称)发布前都去看，这样我会成为他们的瓶颈。
我们为什么分成每天、每周、每月三档来更新，这种迭代开发方式对于我们的管理起到很大作用。很多时候，team或者工程师觉得对了，那就先上，有的时候我和他们有分歧，或者当大家争执不下的时候，我会更倾向于先上。
因为每天一更新的版本，不需要我过问，那是他们的试验田，新功能上去之后，我会看每天的更新，我觉得不靠谱，我就会骂他们，用户觉得不靠谱，骂得比我更严重，因为我要照顾他们的情绪，用户才不管，劈头盖脸就骂，这样其实效果很好，有时候也不需要我说，用户说的比我多。一个功能或者修改在最初版本上可能会有一到两周时间，让几千个荣誉开发组用户用。看设计稿跟真正用这个功能是不一样的——就像喝酒，喝一口跟喝一瓶感觉是不一样的，喝一口觉得不错，喝一瓶，就觉得不能多喝。所以要真正用起来，才知道说不定想错了，觉得不好的主意说不定很不错。最后到稳定版上推出，就相当于一个主意已经经过几百万用户一个多月的使用了。这样我的工作分担到了很多用户身上去，他们会帮我监督。
迭代开发具有极大的容错机制；如果你一上来就面对所有的用户，就让你不敢创新，因为创新如果犯错，代价太大了。通过三个版本的迭代，可以极大地降低犯错几率。
目标第一，手段第二
TBR：据说小米没有KPI考核，但是不同的团队、不同的人，毕竟能力和产出都是不一样的，怎么样保证优秀的团队更能得到激励？
洪锋：“没有KPI”得看如何理解，我们没有那种定量考核的“经典KPI”制度，完全没有数字目标是不可能的。经典KPI更多把这个KPI和收入结合在一起。如果你把KPI和收入紧密结合在一起，很容易奖励短视行为。我觉得上市公司每一个股东都看季度数字，其实是非常奖励短视的行为。KPI很难科学设置，例如我希望提高搜索质量，那搜索次数多了好还是搜索次数少了好？多了可以解释说，因为搜的质量好，所以用户就用得多了，少了也可以说，因为我质量好了，所以搜一次就搜到了。数字是很难说明问题的。人都是有贪欲的，在互联网上，任何一个简单的数字都能被技术操作，简单用KPI数字来评判结果很容易引起技术变形。
所以我们肯定是有目标的，当然确定数字目标是非常难的。我们更希望大家在做任何事情的时候是本着价值观，而不是本着一个数字——他知道什么是对什么是不对。所以，更多的时候是你招聘的员工有正确的价值观。
TBR：在小米什么是正确的价值观？
洪锋：我觉得雷总说过一句话很对，他希望我们的价值观是普世的价值观，大家都认可。产品货真价实，对客户厚道，克制贪欲，不需要赚很多的钱，这个就是通俗易懂的观念，这些大家都懂。但是人是有贪欲的。这就看你招聘的时候怎么选择人，如果招到合适的人，你是不需要什么价值观管理的，更多时候他本来就是这么想的。
TBR：那么招聘的时候，您如何判断价值观适合不适合？
洪锋：我们现在每两天进一个人，所以更多的是看工程能力、技术能力。有句话叫物以类聚人以群分，所以面试的时候也看感觉。有时候感觉和真正工作中的结果未必一致，所以后期如果觉得不合适，也要有相应的措施。所以我们特别注重内部推荐。
TBR：当一个组织小的时候，一个teamleader自身的行为就可以影响到所有人，如果你是一个很透明很公平的人，团队成员的行为方式都会很类似。但如果组织快速变得庞大，你不可能完全用你的价值观来直接管理，必定要有一些规则或管理工具。那你是怎么做的？
洪锋：我们肯定会提出目标。我现在在实验谷歌OKR(Objective and Key Results)管理，因为我以前是谷歌的。我们在不停地尝试，因为好的管理方式真的是需要与时俱进，很难。
谷歌的OKR非常好——什么是目标，什么是手段，什么是关键结果。我觉得最主要的是让每一个团队和每一个个人明确自己的目标。很多团队在定下一个季度事情的时候，他其实定的是task（任务）——我要把这些事情都做了。我经常问的问题是你为什么要做这个工作？首先你要明确目标，保证目标是对的。手段是不是能达到这个目标，是另外一回事。
我觉得手段也是很重要的。当你确定一个目标数字的时候，你要很清楚这个数字会不会引起歧义动作，因为没有一个数字是完全正面的，人类的智慧无穷，你已经想出可能有什么漏洞，还是会有别的漏洞。但至少到目前为止，我还没有想到不用数字规划怎么样去管理。怎么找到在运行的时候不至于太技术变形的数字，是非常重要的。譬如，对小米应用商店，我会去考量用户通过它下载APP的比例是多少？对MIUI自带的浏览器，则会考量它占用户浏览网页的时长比例是多少。
TBR：瀑布流式的开发，通常是周期比较长的开发方式，迭代开发相较于瀑布流开发模式，您认为对人的要求会有差别吗？
洪锋：其实未必。虽然说世界变化很大，但是什么样的人是靠谱的，这个还是很类似的。说到底最主要还是三个要求：责任心、进取心、大局观。大局观就是知道什么是目标。进取心就是当遇到各种各样不同的问题，怎么样去克服它，怎么样想办法创新。我举个例子，一个团队现在适配了20款手机，我给定的目标是，1个月以后适配100多款手机。有一种做法是，招5倍的人把工作做好；还有一种做法是，我们的工作让整个社会来参与，我付一定的钱，和参与者分成，后者可能是更好的方式，因为激发了社会能量。我们是在做生态，要集中全社会的智慧参与开发，这就是生态。当你只有三个人的时候，怎么做三百个人的事情，这个时候需要想办法创新。责任心是最基本的，做任何一件事，责任心都很重要。
