我們的技術如何實現快速迭代？
公司技術的實際情況：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、有條件的話，可以邀請北京附近的粉絲過來面談，或者電話交流溝通。讓技術參與進來。
四、建立容錯機制
待續....