如何做好產品的迭代開發(fā)？

確定迭代節(jié)奏

如果產品已經進入維護階段，即無論搞什么都不會造成利潤大幅變動，那大家可以輕松點，每個需求都不限時，做完為止。在前中期，為了配合快速迭代或敏捷開發(fā)，則需要限時。一般會把迭代周期定成兩周或一月。固定節(jié)奏有助于提高團隊凝聚力和協(xié)調度。

請注意，是迭代周期決定周期內做多少需求，而不是需求數(shù)量決定迭代周期。這會要求需求的總工作量貼近迭代周期，否則就得進行拆分（下節(jié)細述）。

實際的迭代計劃可以微調多一兩天，比如：需求真的無法拆或不想拆到兩周計劃內，那可以做三周計劃，或者對此需求安排并行開發(fā)。但如果要四周，最好還是拆成2個兩周。

如果排不滿，那也不用把技術部門的資源用盡?？諜n期可以讓他們組織重構、分享知識等。對不同的技術部門，安排會有差別：

app每月發(fā)布兩個版本：一個版本是大版本，一個版本是修補的小版本。

前端項目：

web app、hybrid app、微信小程序的迭代應該和app一致；網站項目，一般除了第一版和大改版都不會有大需求，所以做完一個需求就上線一個；h5活動頁，無論多小的改動都立刻改好并上線。后端項目：

配合前端或app的項目，跟隨即可；中間件型業(yè)務，可以按app的節(jié)奏迭代；給內部人員用的系統(tǒng)，由使用者決定需求優(yōu)先級，可在閑時更新。如果某些部分是緊急需要的，可以拆出來先做。

需求規(guī)劃

做好規(guī)劃要有需求池的幫助。需求池最基本的作用是防遺忘，就像個記事本。在它的基礎上做好梳理，就可以得出版本規(guī)劃。如果需求池用excel來管理，可以有這些列：

（1）簡述：最好只有一句話；

（2）優(yōu)先級（下節(jié)細述）：可以不要這列，直接在排序上反映；

（3）狀態(tài)：未定，正在寫，正在開發(fā)（哪個版本），已發(fā)布?？梢圆灰@列，通過改變行的背景色來反映，例如已發(fā)布的是灰色，正在開發(fā)的是綠色。已發(fā)布的需求也可以刪除或放到別的地方；

（4）關聯(lián)：依賴哪個需求得先做完。

（5）備注：

可以寫上來源。比如是誰提的需求，真要做了可以再找他討論細節(jié)；可以用來寫更詳細的描述，免得遺忘；預估的開發(fā)時長。請注意，需求不一定只來自產品經理或運營的idea。技術需求、bug修復、運維事項等都可以放進需求池。不會直接影響營業(yè)額或者可隨時修補的東西，可以交給開發(fā)自己規(guī)劃，穿插在日常中實現(xiàn)。

在做整理之前，要對開發(fā)的戰(zhàn)斗力心中有數(shù)，也就是自己能預計開發(fā)說這個需求要做多久。不管是否限時完成，都要對資源占用時長有個預期。如果有需要，可以找開發(fā)主管做個簡單討論。

整理的結果就是讓需求安排符合迭代節(jié)奏，可以對需求做合并、拆分、刪除（不做），其中最多的操作應該是把超過2周工作量的大需求拆成小件，拆分的思路只有一個——不影響核心功能的就可以拆。

比如：

評論需求：在評論中穿插表情可以拆，點贊可以拆；某業(yè)務的推送通知、分享功能；額外的動畫交互效果。確定在下個版本要做的需求，應另外列出帶時間表的開發(fā)計劃。

更大規(guī)模的整理，會得出多個月的迭代路線圖，總結出主題，甚至倒推出產品戰(zhàn)略。清晰的目標能讓團隊更有凝聚力。

優(yōu)先級

優(yōu)先級可以分4級：

核心：必做，先做，不能砍，不做完就不發(fā)布新版本，可單獨形成一輪提測；高：必做。條件不允許的話可以降低為中優(yōu)先級?？蓡为毿纬梢惠喬釡y；中：如果時間允許，會做；低：可以不做。判斷優(yōu)先級最基本的原則是向錢看——對商業(yè)負責。不要用冠冕堂皇的理由，如公司戰(zhàn)略、老板決策什么的來思考，要更直接的。一句話概括，需求的價值等于“產品在單位時間內創(chuàng)造的利潤增幅”。

它可以分解為3個層面：

創(chuàng)造或提升價值；降低成本；提高產出效率。其中第1點是可以估算的。首先我們假定成本在第一個版本時就固定了下來，那么利潤的增幅約等于收入的增幅。

這幾條公式是估算收入的：

收入 = UV * UV轉化率 * 單價。也可以用PV算；UV = 新增量 + 留存量；裂變的新增量 = 分享數(shù) * 分享轉化率；最終轉化率 = 1 – 各環(huán)節(jié)的流失率之和。以上4個公式僅作為舉例，還能繼續(xù)把其中的變量拆分得更細，可留意它們跟價值的正負相關關系。我們要做的是評估需求能影響哪個因子以及程度如何，從而間接得到它對利潤的貢獻程度，以此作為量化手段來得出優(yōu)先級。

這也就是所謂的數(shù)據(jù)驅動，其中的常量可以用現(xiàn)有數(shù)據(jù)、經驗、業(yè)界數(shù)據(jù)、其它案例參照來確定。當然，常量在不同場景下還是會變的。

降低成本的某些方式也是可以量化的，比如提升性能從而降低服務器配置要求，或者進行數(shù)據(jù)壓縮節(jié)省帶寬，這甚至可以得出準確的成本值。除了各種機器投入的成本之外，最大的成本是人的薪酬。這方面的降成本手段通常是做自動化取代或部分替代人工，比如AI客服。

提高效率也就是提高單位時間的產出，一般是實行完畢才能得出它的價值，所以事前只能主觀評定。自動化也是提高效率的方式之一，比如提升后臺系統(tǒng)體驗，讓運營可以一鍵對用戶推送通知或在多個平臺發(fā)廣告等等。

另外，通過重構、規(guī)范化等方式來解決歷史遺留問題也能提高效率。而且效率也應包括質量的考量，能輔助整個迭代過程提高質量的手段也得考慮在內。

并行

團隊人數(shù)足夠多時，不僅是一個版本內的需求可以同時做，跨版本的需求也可以。當然，這時候應該也是多個產品經理同時參與的，最好是各自負責無關聯(lián)的需求。如果能理解程序員的并行開發(fā)方式，知道合并代碼的過程以及風險，那也許能把需求拆得更獨立些。總體來說就是人和需求都要減少耦合。

還有一種并行的方式，可稱作專項：一個大需求被拆分成多個小需求并在多個版本陸續(xù)上線。一些微服務、子系統(tǒng)的需求，相當于子項目，也可以看成專項。專項實施的前提是這個大需求足夠的獨立，跟主線版本的迭代基本沒沖突。這進一步考驗產品經理的需求整理能力。

更大規(guī)模的團隊合作，問題就改變了，不是“這個版本要上線哪些需求”，而是“這個需求要在哪個版本上線”。也就是多個小團隊圍繞著各自的需求來開展工作，做完后再選擇合并到哪個版本上線，這種模式常見于大型開源項目。