公司技术的实际情况：APP产品定位涵盖内容、社交、交易、工具、智能等综合性平台。而我们的技术团队包括2个前端，2个后台，1个UI，成员能力都偏向于初级。
对于三星和苹果系统不满意的地方，MIUI马上在自己的系统中快速改进，就这样以周迭代的方式，小米不断听取用户意见。
“马上在自己的系统中快速改进，就这样以周迭代的方式”针对这句那我们该如何实现快速迭代？我们的组织如何快速适应碎片化原则？我们的技术应该怎么做能适应周迭代？
解决方案：
一、迭代效率确定
1、迭代最重要的目的是很近地贴近用户，让用户有参与感
2、迭代不是越快越好，而是需要一个恰当的频度，这个频度到底怎么合适，要根据自己的用户特点来判断。比如说，你的版本一推出就是面对100%的用户，那可能每周更新的频度就不合适
3、事实上MIUI的更新频率分为每天，每周，每月，对不同的用户组是不一样的。MIUI有三个更新频率，一天一更新，面对的用户大概是几千个，这个用户组我们叫荣誉内测组；一周一更新，面对几百万用户，这个组叫开发组；一个月一更新，面对的是90%的普通用户，有几千万（现MIUI总用户数已经超过5000万），推出的版本叫稳定版。
1、针对我们实际情况，可以先尝试按照2天、1周、1月三种方式迭代。实验时间定为三个月，之后根据实际情况来调整时间。
2、三种迭代方式对应三种用户组，分别为内测组、体验官组、泛用户。其中
（1）内测组为公司内部员工组成的专门小组。成员由临时董事会 + 需求相关人员。他们主要测试的是这两天的开发成果，包括完整的和不完整的。暂定叫为“小内测版”
（2）体验官组为世界钥匙的外部活跃用户，这些是已经与其建立一定联系，愿意参与体验，有一定发烧友程度的用户，他们能够接受最初期的“不完善”。再没有这些外部用户的时候，由公司全体员工作为体验官。他们主要测试的是某些具体成果，主要是一些小的功能，包括app本身的bug，操作感较差的交互，部分界面的美化等。暂定叫为“大内测版”
（3）泛用户组，所有建立联系的外部用户，或者新拉的用户。他们主要测试的是一些较大的功能，与之前版本改进明显，或者某个较大需求PD的成果。暂定叫为“开发版”
这里面要明确下，我们暂时不进行稳定版开发，上传到应用商店的版本一定是经过评审同意后的稳定版。
二、需求的快速反应
荣誉组的用户群是一个自治的群体，有它的管理委员会，制定自己的规则和决定怎么发展组织，例如决定发展新会员的方式等等，当然，我们类似“发改委”进行一些调控。
人群，是非常愿意折腾的人，他们希望得到更快的更新，他们能够容忍一定的不稳定和一定的不方便，他们觉得“我是来玩的”
用户有任何一个想法和意见都可以到论坛上去发表，如果说得靠谱，会有人把帖子顶起来，如果说得不太靠谱，其他的用户很快就把你踩死了。这是一个相当于自由言论优胜劣汰的过程。在这个过程中，用户说的话不管靠不靠谱都得到了回应。最重要的其实就是沟通和交流过程本身，用户的意见得到聆听，他有得到尊重的感觉，而不在于是不是意见得到完全的采纳。
优先处理浮出水面的需求
三、技术怎么适应迭代
对于我们员工来说，每天有20多万的帖子，全体员工发疯也看不完。所以我们一些运营人员会把帖子归纳总结成200个不重复、有价值的，分门别类到各个部门，让工程师去解答。凡是进入到这个模块里的帖子，每一个帖子后面都有跟踪：谁在处理此事、采纳还是不采纳、采纳的话什么时候改好。
引导工程师和用户交流、交朋友，主要还是要让论坛这件事情本身变得有趣。例如我们每两周去一个城市和米粉互动，开米粉会，这就是拉近工程师、产品经理和米粉的距离，工程师、产品经理能感受到用户的感情，用户对我们产品的热爱、期待、不满，人与人之间的沟通就形成了，很多时候他们就变成朋友了，然后就不再需要推动，交流就已经建立起来了，我们非常希望把工作变成是人与人之间的沟通。
1、由各运营项目定期收集需求反馈，整理后提到产管部、技术部，由技术部解答。
2、产管部建立建立跟踪机制：谁在处理此事、采纳还是不采纳、采纳的话什么时候改好。
3、引导技术部与用户交流，建立微信群或QQ群，让技术参与进去。
4、有条件的话，可以邀请北京附近的粉丝过来面谈，或者电话交流沟通。让技术参与进来。
四、建立容错机制
待续....
网友评论