如何建立產品迭代管理制度

05-12

一、文檔概述

1.1為何要做

產品優化迭代是需長期打磨的過程，產品本身的可用性，易用性，直接影響到用戶的選擇及公司的效益，因為需建立一種版本迭代需求管理分析設計到技術開發測試上線的完善流程，使得產品迭代工作中人員分工合理，匹配無間，健康持續，以此來保證產品迭代科學，保質順利上線。

1.2迭代主線流程圖

二、優化方案

2.1發現問題

誠然，從來沒有一款產品是絕對完美的存在，相對優秀的產品一定是不斷的聽取用戶的建議，一點點打磨優化的產品，發現問題的方式是多種多樣的包括但不限於：1.測試產品中的漏洞。2.用戶反饋的問題。3.同行產品的新功能。4.市場變動的新方向，等等。

產品需收集來自各方反饋的需求，將明確的需求整理到項目需求管理文檔上，匯總之後在一定時間進行分析。

正確的需求記錄（問題+方案）如下圖：

註：不明確的需求，一概不予記錄至項目需求管理文檔。

2.2產品評估需求級別

需求的形式是多種多樣的存在，在不同的階段對需求的對待是不一樣的，具體情況根據產品的生命周期而定，如產品早期應更多對業務流程的關注，首先保證日常使用流程的平緩安全，接著才是用戶體驗。

首先所有的需求整理出來擱置在需求文檔上，那麼將要對所有需求進行判定，此時可參考四象限法則：緊急且重要，緊急不重要，不緊急但重要，不緊急不重要，進而分析，最後得出產品需求的級別：

產品需求級別

2.3技術評估成本級別

當分析得出需求級別之後，需要召開技術部門的初步評估會議，對已有的的需求進行技術角度的評估，涉及的評估維度可參考：開發周期，開發難度，團隊技術儲備等，最後得出開發成本級別：

開發成本級別

2.4迭代申請確認

到此產品部門已得到版本迭代所需的產品需求級別和開發成本級別，將已獲得的信息填至需求評估矩陣模型：

接著可根據產品的具體情況，參考下圖進行需求優先順序的確認：

最後我們可將產品開發的功能列表和開發成本撰寫成一份版本優化申請，交至領導確認，如獲確認，則進行下一步，否，則暫停。

2.5產品設計低保真原型

經過上述科學的論證過後，產品方可設計原型，在一遍遍的論證中，產品經理已心有所想，此時在設計產品原型想必條理清晰知所云，切記，不得不知所云就上手設計，原型工具只是表達思維的一種方式，僅此。

設計包含：整體布局，操作邏輯，用戶體驗等。

原型設計完畢後，召開評估會議，參與人員：UI設計，程序員，部門領導等。

2.6 UI設計高保真原型

產品完成低保真設計且評估合格後交至UI，進行高保真原型的界面美觀設計需備註出原型中設計的文字字型大小，顏色碼值，的等等。

設計完成後需召開會議評估：參與人員：產品經理，前端工程師，部門領導等。

2.7產品撰寫PRD文檔

到此，已是產品前半部分工作的尾端，已按流程得到：需求獲取及整理，需求分析評估，開發評估，版本優化申請確認，低保真原型設計，高保真原型設計，接下來撰寫PRD文檔作為技術部門的一個參考，撰寫的方式多種多樣，唯一的檢測標準是開發部門閱讀流暢減少溝通成本。

原則上此時不在加入新的需求，新的需求暫緩擱置需求池。

三、項目管理

3.1項目管理文檔

版本迭代可分為兩個部分：1.優化方案。2.項目管理。

前半部分已完成，此時開發部門leader已收到來自產品部門：1.低保原型圖。2.UI高保真原型圖。3.PRD文檔。可根據現有的資料和項目經理共同制定出開發周期，定出每個任務的具體責任人，項目難點，應對措施等。

3.2開發跟進

技術團隊根據項目管理的文檔，明確自身的模塊及進度安排，進入開發階段。

產品負責人根據項目管理文檔上的時間周期，進行項目進度的查詢，如有較大進度問題及時上報部門leader說明情況。同時產品負責人對技術團隊的相關疑問，進行全程解答，保障產品順利上線。

3.3產品驗收

產品迭代優化完畢後，內部進行測試，主要針對本次版本迭代功能和基礎功能做相應測試，合格，則本版本完成迭代，否則優化至驗收合格為止。