產品設計（4）- 產品迭代節奏

來自專欄互聯網之我見

這段時間世界盃，Tiki Taka風格的球隊已經基本都被淘汰了。評論說這種踢法已經沒落，不符合當今主流的足球戰術。個人倒覺得這種踢法並沒有沒落，反而是現在的球員不具備巴薩巔峰的時候的那種能力了。說回產品迭代節奏，同樣也是如此。敏捷開發叫喚了很多年，業務、產品、市場和技術都日新月異，但是敏捷開發的原理還是很適合當下大部分產品開發的。只是執行的人，不像以前那麼符合這套系統的要求罷了。

現在這個社會是個多維度社會，一個人做不了所有的事情，有生之年也學不會所有的知識，必須要協作配合起來才能完成一個項目。如果團隊越小，單個團隊成員從事的事情越大，那項目可以越「敏捷」。敏捷不代表快，而只是在節奏上更加符合客觀規律。用精益創造的思想來看待這個問題，橫向上就是前期快速迭代，出最小功能點產品，儘早地投入到市場獲取用戶反饋來為後面幾次的迭代做參考和依據；縱向上講究獨立團隊制定自己的工作目標和驗收指標，高頻次的計劃、提交和驗收。任務需要縱向地穿插執行，產品需要橫向地統籌考慮和規劃。

最小功能點階段，可以忽略一切細節甚至是bug問題，小範圍傳播和推廣，一周一次迭代，甚至更短的時間。迭代+測試+調試穿插進行，這個階段可以用最小的成本來實現前期的目的。

產品迭代階段，需要放緩迭代速度，延長迭代周期，需要把前一階段的大坑能填的都填上。這個階段另一個關鍵任務是磨合團隊，制定運營措施及任務驗收職責和標準，讓下個運營階段能夠更加順利地展開。

運營階段，這個階段產品還是需要迭代的，只是迭代上的很多策略都會不同。就以APP舉例，前面兩個階段可能要不斷地發版更新，到了這個階段就要謹慎地執行發版，能熱更新的熱更新，能夠後台直接配置更新的都盡量往這方面去想。隨著用戶量或者業務量的上升，高頻次的迭代已經不適合這個階段，一個修改就會影響到很多因素，而且也對運營工作不利。

整個產品還有個比較重要的環節就是後台系統，後台系統的研發開始應該在產品迭代中期之後，明天的篇章會詳細描述下這方面的一些心得。

推薦閱讀：