快速迭代

出自 MBA智库百科(https://wiki.mbalib.com/)

　　快速迭代是指產品與服務要快速地適應不斷變化的需求，不斷推出新的版本滿足或引領需求，永遠快於對手一步，例如蘋果。

• 第一、環境，周圍環境在快速變化、產品沒有足夠的時間來進行需求分析及相關測試；

• 第二、用戶，用戶不知道自己真正想要什麼，產品需要通過迭代的方式進行試錯；

• 第三、成本，一般情況下可迭代產品的成本都很低，並且可以快速的進行版本更新。

　　快速迭代最大的優點是及時的用戶反饋，這樣可以快速的調整產品的方向，避免在無用的功能浪費時間和精力，減少風險。也就是說真正的迭代必須把每一個迭代周期的成果交給用戶，而且每次的成果都是完整可用的。如果一個迭代周期結束後，成果被內部否定定而沒有推向市場，那這就不算是真正的迭代。每一次迭代必須以產品的發佈結束。

　　相對一個需求大而全的產品，迭代更加適合創新型的產品，特別是對產品最終形態還缺乏概念的時候。但是迭代仍然應以一個明確的目標和原則為前提，否則容易出現偏離最初意圖的情況。從開發的角度來說，對開發人員的整體水平要求較高，因為迭代意味著每一個迭代周期或多或少的代碼重構，這對於產品的任何一個開發人員的設計水平和全局觀都有一定要求。

　　有些產品或者產品的某些階段並不適合迭代的方式，比如游戲的第一個版本，因為只有成為一個相對完整的產品以後才能推向市場，不可能像工具類應用一樣先推出一個能解決部分問題的比較粗糙的版本，游戲用類似的方式推向市場會自砸招牌。但是開發組內部仍然可以通過階段性的工作確認成果，也可以稱之為迭代，但和前面的迭代含義上有一些差異。

　　在產品快速迭代的過程中，有很多地方需要進行主導優化：

　　1、思想優化。在開發過程中一定會出現研發人員的意見與產品經理、交互設計師的意見不一致的情況，因為從人性的角度分析，每個角色都一定會用自己慣性思維去思考問題，比如工程師會告訴這個 Banner 放在左面程式運行效率最高，而交互設計師認為放在右邊會更符合行為習慣，產品經理則認為放在更上方一點會換來更多的點擊率，此時一定要引導大家站在更高層、更客觀的角度去尋找解決方案。

　　2、代碼優化。這一點更多的是指代碼 review，一般會採用每天團隊成員交叉 review 和每周團隊一起進行重點功能 review 兩種模式。有句話叫磨刀不誤砍柴工，代碼 review 是發現潛在BUG、發現功能偏差的最低成本投入。

　　3、文檔優化。推薦使用類似wiki的系統來統一管理產品文檔，在寫文檔的過程中不要因為怕麻煩就降低文檔的可讀質量。

　　4、流程優化。需求管理系統、BUG管理系統、產品打包機制最好都是高度智能化的，可以讓團隊成員第一時間找到自己想要的信息。