基於什麼樣的背景，我們要做什麼事情，

滿足什麼使用者哪一個需求？

需求分解出來，產品的邏輯如何？

互動圖如何？

設計圖如何？

哪些功能點？

哪些細節？

實現進度如何？

產品健康運轉的閉環如何形成？

文件，就怕寫複雜了，連開發都看不明白的文件，必然不是一份好文件。

抽象了一份文件出來，供大家參考，根據各自公司的具體情況進行修訂完善吧。

1. 文件歷史

2.目錄

1. 文件歷史

2. 目錄

3. 專案說明

3.1 專案背景

3.2 專案目標

3.3 專案概述

3.4 專案排期

4. 專案策劃

4.1 產品邏輯圖

4.2 功能與特性簡述列表

4.3 互動/視覺設計

4.3 需求詳細描述

5. 資料需求

5.1 資料建設：考核評價指標

5.2 指標定義與計算邏輯

5.3 資料報表

6. 客服文件

7. 運營方案

3. 專案說明

3.1 專案背景

專案需求不是產品經理拍腦袋想出來的，一定有個出處，例如，

l 使用者需求驅動，解決哪一種使用者什麼樣的問題？

l 市場競爭驅動，有了什麼新的變化？

l 技術驅動，有什麼技術創新可以應用在產品上，讓解決問題的效率更高？速度更快？

案例：目前繁瑣的註冊流程導致使用者註冊成功率僅為20%，本專案主要是優化註冊流程，提升註冊成功率。

3.2 專案目標

由背景推匯出的目標，符合SMART原則，簡明扼要，一般通過資料衡量，目標通常是貫穿整個需求的線索，整個需求都應該是圍繞目標在進行的，包括優先順序的排列，也是綜合考慮需求點能實現目標的程度、效率、緊迫性、成本控制等各方面因素。

目標舉例，2013年8月10日完成註冊流程優化，提升註冊成功率10個百分點，從原有的20%提升到30%。

3.3 專案概述

將涉及到的頁面做個列表，可以幫助評估設計、開發需求所耗費的時間

3.4 專案排期

專案進度時間表，也是一個不斷推動、修訂的過程，協調各方資源，儘量給出靠譜的時間進度，並推動按期完成需求。一般用表格形式，包括欄位：專案名稱、專案內容、負責人、開始日期、完成日期。

4. 專案策劃

4.1 產品邏輯圖

按照邏輯線索理出邏輯圖，便於閱讀者組織對該專案的理解思路，涉及流程的必須給出流程圖，一般用VISO繪製。

4.2 功能與特性簡述列表

產品需求的核心部分，詳細的功能列表對需求評審、開發時間評估、測試用例撰寫具有重要價值，列表可以儘量詳細，一個功能/特性點都可以單獨一項，基本可以和測試用例對應，同時，需要給出優先順序和測試重點。

1．功能列表：簡潔概要的描述要實現的功能點， 就是讓使用者做什麼，可以按照使用者場景和產品流程進行描述，第一步、第二步、第三步……成功、失敗。

2．具體描述：給出在某場景下，使用者的具體操作實現過程。例如使用者身份變化對應的不同產品表現形態、使用者每一步操作需要對應的產品功能、產品的數值變化，數值極端情況。儘可能的考慮全面，細化，具體，可操作，可讀性強。

3．優先順序：最高階，本期必須實現。中級優先，二期需求，視第一期產品表現後決定做哪些優化。低優先順序，本期可以不實現或延後實現。

4. 測試重點：從測試的角度，給出具體描述的各個場景下的一些需要關注的主要測試點。一些細節可以在需求詳細描述中說明，可以寫上詳見第幾點詳細描述，這裡只需要給出一些方向即可。

4.3 互動/視覺設計

這個部分，一般會有多個修訂稿，注意文件的儲存與更新。修訂文件的時候應該補充好互動/視覺設計稿，便於其他閱覽者清晰還原需求所在的產品場景，文件描述所見和開發出的產品所得相統一。

4.3 需求詳細描述

每個產品功能、特性的詳細描述，可以和前文的專案概述一一對應，也是對功能與特性概述的詳細說明，一般

例如一個註冊功能詳細描述：

(1) 功能或特性名稱：使用者註冊流程

(2) 需求描述：一句話描述，簡化原有註冊流程；

(3) 使用者：什麼樣的使用者會使用這個功能；

(4) 前置需求：這個需求的前置需求如何？基於前面的需求，進行功能的進一步開發，說明前一個需求對該需求的影響或者創造的條件；

(5) 後置需求：該需求完成後，會對哪些需求產生影響；例如使用者註冊後成功後的使用者教育引導需求、註冊填寫資訊對構建使用者關係鏈的影響；

(6) 主流程描述與業務規則：使用者的主要操作流程，及其每個步驟的規則說明。例如，對展示的內容進行描述，如果有可操作部分，需要單獨列出：操作前後的狀態，操作後的反饋，連結到具體位置等；如果涉及數值等級，對不同數值等級，不同的狀態，不同的操作反饋

舉個例子：對註冊流程的規則描述：

A. 註冊頁面開啟，滑鼠焦點定位在註明名輸入框；支援TAB鍵進行輸入框切換；

B. 每個輸入框的狀態：輸入前、輸入過程、輸入結束；

C. 輸入型別：字元、數值；字母、漢字、數字、符號；非法字元；

D. 敏感詞問題；輸入長度；是否必填；是否聯想；是否記憶；是否有預設值？如何對齊？過長後如何顯示？

E. 輸入後多久給出判斷？

F. 一個IP每天可以註冊多少個帳號？

G. 是否可以採用OPENID的形式註冊？

H. 是否需要郵箱、手機進行註冊成功驗證？

I. 一個手機或者郵箱是否是唯一繫結關係？

J. 註冊成功後，跳轉到使用者引導頁面；

K. 註冊失敗，引導重新註冊；

(7) 產品效能要求：能達到一定的效能指標，比如速度快、軟體穩定性、併發使用上限

(8)其他補充說明（視具體情況選擇是否需要）

A. 安全需求：能夠抵擋黑客攻擊，保證使用者的資料不會丟失，防止黑客刷等級，暴力註冊等；

B. 相容性需求：如瀏覽器相容性、系統版本相容性；

C. 財務需求：如一定預算，需要提前找財務審批，產品收入與財務的對接

D. 法律需求：需要法務部門協助的需求，如何同稽核、使用者協議、版權

5. 資料需求

5.1 資料建設：考核評價指標

[考核評價指標是評估產品目標的重要標準，在專案策劃的前期就必須制訂]

l 訪問量

l 轉化率

l 留存率

l 使用者活躍天

l 產品收入

l 任務、活動完成量、質量

5.2 指標定義與計算邏輯

資料指標的含義是什麼，開發上報哪些資料欄位，可以通過公式計算出這些指標；

5.3 資料報表

用Excel畫出需要檢視的報表；如果需要統計圖的，說明需要什麼類別的圖形，柱狀圖、折線圖、餅圖等等。

6. 客服文件

讓客服了解產品，周知客服本產品有可能遇到的使用者問題，給出常見問題解答。

7. 運營方案

需求完成後的功能點說明或描述，使用者周知推廣。

產品不只是上線，後期的運營需要提前考慮。在產品策劃階段或許很難有一個詳細的運營方案，但至少有產品成長運轉的運營保障，例如從產品生命週期考慮運營方案，在啟動期、成長期、成熟期等各個階段的運營對策；在啟動期，第一批種子使用者從哪裡來？如何保證產品的灰度放量到健康成長的正迴圈養成？需要提供哪些運營資源的支援？

一般的運營，都會考慮：拉新、留存、活躍、迴流等運營策略。有的只是一個小功能優化，這裡可以省略。