一 、文檔概述

1.1為何要做

產(chǎn)品優(yōu)化迭代是需長(zhǎng)期打磨的過程，產(chǎn)品本身的可用性，易用性，直接影響到用戶的選擇及公司的效益，因?yàn)樾杞⒁环N版本迭代需求管理分析設(shè)計(jì)到技術(shù)開發(fā)測(cè)試上線的完善流程，使得產(chǎn)品迭代工作中人員分工合理，匹配無間，健康持續(xù)，以此來保證產(chǎn)品迭代科學(xué)，保質(zhì)順利上線。

1.2迭代主線流程圖

二 、優(yōu)化方案

2.1發(fā)現(xiàn)問題

誠(chéng)然，從來沒有一款產(chǎn)品是絕對(duì)完美的存在，相對(duì)優(yōu)秀的產(chǎn)品一定是不斷的聽取用戶的建議，一點(diǎn)點(diǎn)打磨優(yōu)化的產(chǎn)品，發(fā)現(xiàn)問題的方式是多種多樣的包括但不限于：1.測(cè)試產(chǎn)品中的漏洞。2.用戶反饋的問題。3.同行產(chǎn)品的新功能。4.市場(chǎng)變動(dòng)的新方向，等等。

產(chǎn)品需收集來自各方反饋的需求，將明確的需求整理到項(xiàng)目需求管理文檔上，匯總之后在一定時(shí)間進(jìn)行分析。

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

注：不明確的需求，一概不予記錄至項(xiàng)目需求管理文檔。

2.2產(chǎn)品評(píng)估需求級(jí)別

需求的形式是多種多樣的存在，在不同的階段對(duì)需求的對(duì)待是不一樣的，具體情況根據(jù)產(chǎn)品的生命周期而定，如產(chǎn)品早期應(yīng)更多對(duì)業(yè)務(wù)流程的關(guān)注，首先保證日常使用流程的平緩安全，接著才是用戶體驗(yàn)。

首先所有的需求整理出來擱置在需求文檔上，那么將要對(duì)所有需求進(jìn)行判定，此時(shí)可參考四象限法則：緊急且重要，緊急不重要，不緊急但重要，不緊急不重要，進(jìn)而分析，最后得出產(chǎn)品需求的級(jí)別：

產(chǎn)品需求級(jí)別

2.3技術(shù)評(píng)估成本級(jí)別

當(dāng)分析得出需求級(jí)別之后，需要召開技術(shù)部門的初步評(píng)估會(huì)議，對(duì)已有的的需求進(jìn)行技術(shù)角度的評(píng)估，涉及的評(píng)估維度可參考：開發(fā)周期，開發(fā)難度，團(tuán)隊(duì)技術(shù)儲(chǔ)備等，最后得出開發(fā)成本級(jí)別：

開發(fā)成本級(jí)別

2.4迭代申請(qǐng)確認(rèn)

到此產(chǎn)品部門已得到版本迭代所需的產(chǎn)品需求級(jí)別和開發(fā)成本級(jí)別，將已獲得的信息填至需求評(píng)估矩陣模型：

接著可根據(jù)產(chǎn)品的具體情況，參考下圖進(jìn)行需求優(yōu)先級(jí)的確認(rèn)：

最后我們可將產(chǎn)品開發(fā)的功能列表和開發(fā)成本撰寫成一份版本優(yōu)化申請(qǐng)，交至領(lǐng)導(dǎo)確認(rèn)，如獲確認(rèn)，則進(jìn)行下一步，否，則暫停。

2.5產(chǎn)品設(shè)計(jì)低保真原型

經(jīng)過上述科學(xué)的論證過后，產(chǎn)品方可設(shè)計(jì)原型，在一遍遍的論證中，產(chǎn)品經(jīng)理已心有所想，此時(shí)在設(shè)計(jì)產(chǎn)品原型想必條理清晰知所云，切記，不得不知所云就上手設(shè)計(jì)，原型工具只是表達(dá)思維的一種方式，僅此。

設(shè)計(jì)包含：整體布局，操作邏輯，用戶體驗(yàn)等。

原型設(shè)計(jì)完畢后，召開評(píng)估會(huì)議，參與人員：UI設(shè)計(jì)，程序員，部門領(lǐng)導(dǎo)等。

2.6 UI設(shè)計(jì)高保真原型

產(chǎn)品完成低保真設(shè)計(jì)且評(píng)估合格后交至UI，進(jìn)行高保真原型的界面美觀設(shè)計(jì)需備注出原型中設(shè)計(jì)的文字字號(hào)，顏色碼值，的等等。

設(shè)計(jì)完成后需召開會(huì)議評(píng)估：參與人員：產(chǎn)品經(jīng)理，前端工程師，部門領(lǐng)導(dǎo)等。

2.7產(chǎn)品撰寫PRD文檔

到此，已是產(chǎn)品前半部分工作的尾端，已按流程得到：需求獲取及整理，需求分析評(píng)估，開發(fā)評(píng)估，版本優(yōu)化申請(qǐng)確認(rèn)，低保真原型設(shè)計(jì)，高保真原型設(shè)計(jì)，接下來撰寫PRD文檔作為技術(shù)部門的一個(gè)參考，撰寫的方式多種多樣，唯一的檢測(cè)標(biāo)準(zhǔn)是開發(fā)部門閱讀流暢減少溝通成本。

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

三 、項(xiàng)目管理

3.1項(xiàng)目管理文檔

版本迭代可分為兩個(gè)部分：1.優(yōu)化方案。2.項(xiàng)目管理。

前半部分已完成，此時(shí)開發(fā)部門leader已收到來自產(chǎn)品部門：1.低保原型圖。2.UI高保真原型圖。3.PRD文檔?？筛鶕?jù)現(xiàn)有的資料和項(xiàng)目經(jīng)理共同制定出開發(fā)周期，定出每個(gè)任務(wù)的具體責(zé)任人，項(xiàng)目難點(diǎn)，應(yīng)對(duì)措施等。

3.2開發(fā)跟進(jìn)

技術(shù)團(tuán)隊(duì)根據(jù)項(xiàng)目管理的文檔，明確自身的模塊及進(jìn)度安排，進(jìn)入開發(fā)階段。

產(chǎn)品負(fù)責(zé)人根據(jù)項(xiàng)目管理文檔上的時(shí)間周期，進(jìn)行項(xiàng)目進(jìn)度的查詢，如有較大進(jìn)度問題及時(shí)上報(bào)部門leader說明情況。同時(shí)產(chǎn)品負(fù)責(zé)人對(duì)技術(shù)團(tuán)隊(duì)的相關(guān)疑問，進(jìn)行全程解答，保障產(chǎn)品順利上線。

3.3產(chǎn)品驗(yàn)收

產(chǎn)品迭代優(yōu)化完畢后，內(nèi)部進(jìn)行測(cè)試，主要針對(duì)本次版本迭代功能和基礎(chǔ)功能做相應(yīng)測(cè)試，合格，則本版本完成迭代，否則優(yōu)化至驗(yàn)收合格為止。