中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

Anyway,「方法只是思維層級里底層的事情」。

最近一直在思考「輸出需求文檔」這件「小事」，發現太多產品經理連需求都沒辦法完全表達清楚，在需求評審會上支支吾吾，被各種挑戰，或者開發階段中多次重復確認，疲于各種溝通。相信每個產品新人都有過這種痛苦，解決的方法只有一種：「產品邏輯想得比任何人都多」。而需求文檔是其中一種思維工具，利用好文檔幫助自己梳理邏輯，掌握自己的節奏。

同時，需求文檔能夠在復雜需求流程中起到重要作用：

1. 表達產品設計的需求，提高團隊協作效率，是最重要的「協作工具」
2. 作為可驗收的「產品標準」

「輸出需求文檔」是每個新人很長一段時間都要做的事情，發現竟然大部分導師或者前輩都不會系統講解的?！篙敵鲂枨笪臋n」是產品經理產品設計能力中最基本的基本功，就像UI同學用PS畫圖，開發哥敲代碼一樣，后兩項技能/工具是需要花4年大學時間或者甚至更長的時間學習的，而大部分產品經理竟然都沒有學習過需求文檔這件事情，如果大學開產品經理專業，「輸出需求文檔」一定是大一就要學的課程。

我這里一直講的是「輸出需求文檔」，不僅僅包括寫需求文檔這件事，「輸出」應該是一個動作?？梢钥吹叫枨蟮耐暾鞒?，「輸出需求文檔」應該分為需求前、需求中、需求后，寫文檔只是其中的一部分。

這次分享的是與需求文檔相關的動作，需求跟進和管理又是另外一個大課題，這次框架里不包括。

一、寫需求文檔

推薦這種結構的需求文檔，采用的是結構化導航模式（網上已經有很多模板了），這樣的好處是清晰明了，開發、測試、設計不同角色可以根據自己需要看自己關注的部分，不用對著文字版需求說明書來回找。
再來，完整又簡潔的需求文檔應該包括：文檔簡介、需求分析、結構流程、原型交互、埋點說明。

沿用了這種模板和結構的不一定是好需求文檔，更重要是每一部分里的思維和邏輯，模板和結構只是表面。

（1）文檔說明

#版本說明

讓參與人員能第一眼清楚看到這次版本或者功能包括哪些部分，能大概有預期工作量。為了清楚描述需求概況應該包括：

1. 序號：有幾個功能需求點。
2. 類型：將需求分為新增、修改、刪除。
3. 功能點：功能名字。
4. 需求描述：簡要描述功能點，理解功能概況。
5. 優先級：功能重要性，分為P0,P1,P2(當然也可以直接分為高中低，或其他寫法)，不建議超過3個優先級，意義不大。P0定義為必須完成，P1定義為無意外的話需要完成，P2可做可不做。
6. 詳情：我這里只是為了方便點擊跳轉到相應需求說明的位置。

#修改歷史

是的，很多情況下需求從開始，到結尾從來沒有更新過。這樣導致的問題會很嚴重，需求版本不同步，驗收時錯誤或漏掉需求，反復修改。需求同步不是一件容易的事情，文檔修改歷史可以幫助需求同步。

1.詳細描述文檔改動點，包括時間、版本號、類型（增刪改）、嚴謹的修改說明。以下是兩類示例：

a. 不合格的修改說明： 修改標簽庫邏輯

b. 嚴謹的修改說明：在評論提醒中

• C回復B不需要通知A的，因為A不會非常在乎B與C討論的內容
• 點擊通知欄的時候如果沒登錄是調起登錄的
• 小紅點邏輯：啟動的時候拉取
• 列表刷新：每次都進入都刷新
• 定位位置，點贊定位問題

特別多人討論確定邏輯后需要修改在文檔里，詳細描述。

2. 同步給所有參與人（這部分目前我是通過公司的協助工具上傳文件，這樣能夠郵件通知，暫時還沒有更好的工具）

（2）詞匯說明

并不是項目組每個人都明白產品經理在需求分析、交互原型里說的名詞，將名詞解釋明白即可。

（3）需求分析

需求文檔里的需求分析，目的很簡單，是說服項目組認可這個功能或需求，能將需求安排下去，常用的方式兩種方式：

1. 邏輯型說服：闡述明白需求是如何產生的，價值是什么，為了達到產品最終目標，這個需求是什么的作用。在我另外一篇文章里已經詳細描述，并且詳細舉例說明，這里不再贅述。請看《如何從分析到需求全過程 | 全民K歌“你點TA唱”實例講解》
2. 數據型說服：通過估算這個需求帶來的直接數據增長，比如用戶數、收入、點擊率等等

（4）原型交互

「最容易理解的需求方式是界面長得怎么樣」，別讓項目組其他同學對著文字版需求理解。原型交互式整個需求文檔中最重要的部分，也是最需要詳細描述的部分，包括客戶端邏輯、服務端邏輯、交互邏輯、邊緣場景（并不是每個需求都有客戶端邏輯或服務端邏輯）。

#客戶端邏輯

描述客戶端界面元素的展示和操作邏輯，推薦圖文結合的方式。

1. 界面原型：可以用各種原型工具完成，積累自己的素材庫能更快的完成高保真原型。（示意圖用的是sketch）
2. 入口：說明功能觸發的入口，哪里觸發是理解的第一步
3. 展示元素：描述界面需要的每個元素和展示邏輯
4. 行為交互：分為加載和點擊，數據/界面是如何加載出來，點擊后會有什么效果

#服務端邏輯

服務端部分指為用戶提供產品服務時涉及的數據邏輯等等，完整梳理應該包括后臺功能和服務端數據邏輯。
1.后臺功能：指后臺配置功能部分，目的是給運營同學配置內容。一般包括后臺前端，配置項、增刪改功能，可以根據功能難易是否需要后臺原型。

（簡單版）

（可交互后臺原型）

2.服務端數據邏輯：定義數據結構和數據下發邏輯，以熱文庫這個功能為例子解釋下。

功能背景：通過挑選熱點內容，覆蓋頭部內容，提高內容質量和點擊率

#數據定義

• 熱文：分別與內容庫(XX庫、XXX庫)內容匹配，匹配度2.0以上,TOP1匹配度作為熱文
• 熱文庫：每天XX:00點、XX:00點、XX:00點更新和重新匹配，將文章入庫，這些文章集合為熱文庫

#數據下發邏輯

1. 目標：用戶刷新時，將熱文按XX順序下發到XX位置
2. 其他邏輯…

#交互邏輯

指的是界面和元素之間的交互行為。即使公司里有專職的交互設計師，產品經理也不應該省略這一部，只有完整考慮流程和細節，才能和設計師、項目組任何成員流暢討論。

與客戶端邏輯不同的是，這部分更多是界面之間操作流程，輔助界面的交互說明（點擊、加載、動畫），幾個注意點：

1. 交互設計的本質是「讓用戶更快更便捷的使用服務或產品內容」
2. 始終考慮交互設計五個要素，媒介、場景、行為、目的、用戶

#邊緣場景

如果你完成了上面的主要邏輯場景，一般來說功能只完成了一半，甚至沒有。邊緣場景的梳理這部分是最容易遺漏的地方，一旦遺漏就會陷入各種溝通和反復中?？偨Y了常見的邊緣場景，寫完原型說明必檢查。

1. 網絡狀況：移動、WIFI、斷網、弱網
2. 最大限制：字符、數據、等待時長等等
3. 缺省狀態（為零）：輸入/展示為零
4. 多場景：夜間、橫屏、豎屏、不同渠道等等
5. 賬號狀態：未登錄/已登陸、多設備登陸、狀態切換不同步
6. 服務器異常處理

（5）結構流程

#信息架構

當信息項特別多而復雜的時候有必要將信息架構列出來，按照界面、界面元素、信息項逐項拆解，目的是在測試同學在寫用例時更方便查找。

#業務流程

業務流程在技術同學開發時關注的部分，分為數據流程和用戶流程兩類流程。

1. 數據流程：數據交互邏輯，描述前端、客戶端、服務端數據情況。

2. 用戶流程：用戶交互流程，描述用戶操作流程。

（6）埋點說明

埋點的作用是為了功能上線后做分析調整，也是迭代的關鍵輔助，一定要做到「有功能必埋點」。埋點包括三個部分：事件ID、事件名稱、統計口徑、事件描述。

1. 事件ID 事件唯一標識，一般使用英文表述意義，單詞間使用下劃線隔開，如 ?click_add_bookmark_folder
2. 事件名稱：事件的中文名稱。
3. 統計口徑 ?指埋點類型，分別為計數事件、內容計數事件、計時事件、狀態事件。

• 計數事件:只計算次數的事件類型
• 內容計數事件:除了計算次數，還有其他參數上傳，參數一般用英文區分，如 from=下載來 ? 源，package=下載包名， host=下載鏈接 host，此類型多用 于減少計數事件埋點和用于報表生成。
• 計時事件:用于計算用戶使用事件，多用于頁面停留計算，進入頁面開啟計時 器，離開頁面時停止計時器，并生成事件
• 狀態事件:用于上報開關狀態情況，通常用 0,1 表述。

4. 事件描述：什么時候觸發埋點

需要關鍵點是：

1. 減少重復埋點，盡量使用內容計數方式
2. 埋點名稱和參數盡量使用有意義的英文表示，別埋點AA或者BB
3. 埋點的目的是為了生成報表分析，先想好功能要分析什么部分，需要什么埋點，「以終為始」不容易漏掉埋點或者參數。
4. 做好版本管理，云同步或在線協同文檔功能都是不錯的選擇
5. 善用前綴命名，拓展更強

二、輸出動作

需求文檔只是整個流程中將思路文檔化的過程，可見項目完整流程圖，文檔只是很小的一部分。本文先不講需求跟進部分，僅僅「輸出需求文檔」就容易忽略前期和后期，導致需求流程不可控。

（1）需求輸出前

輸出前做好兩件事情分析和溝通，能在需求后續流程中更順暢。

1. 需求分析：想清楚為什么要做這個需求，可以從用戶場景和反饋思考，可以從數據分析，可以從競品中參考，但是一定要比任何人都要想得更多。
2. 溝通：提前將想法和需求參與人員溝通，比如開發、設計。讓他們提前了解需求大概和評估可行性，這樣能避免將需求評審會變成需求討論會，團隊一群人開一整天討論會效率極低。

II.需求輸出后
將需求文檔發出去之后就完事了嗎？在需求跟進過程中，需求文檔是需要維護。

1. 有疑點及時討論（越早發現坑越少），討論后必定要總結，總結必定文檔化
2. 做好需求歷史版本管理，上面已經說過版本歷史是非常好用的技巧，另外文件命名上也需要加上版本號和時間，變更時通知所有參與人（郵件或團隊協助工具）

三、目的和原則

分享了「輸出」和「需求文檔」兩件事情的心得，目的絕不是讓大家下載模板，直接套用，而是參考的同時能理解PRD里每個部分的作用和方法，在實際積累中形成自己的PRD模板，關注需求內容本身而不是需求形式，提高思維效率。另外，想掌握一個方法，形成自己的方法論和認知必須經過具體到抽象，抽象再到具體的過程。

• 具體 -> 抽象：在探索中總結經驗。比如我這份需求文檔總結，也是從無開始不斷迭代，最終總結了所有經驗得到抽象的結果。
• 抽象 -> 具體：結合實際運用。比如我理解了每個部分的意義，在每個項目時間和不同條件下輸出不同的需求文檔。

Anyway,「方法只是思維層級里底層的事情」。

四、最后

• 需求文檔以「梳理清楚需求思路，減少溝通成本」為目標，而不是寫出漂亮的萬字需求說明書，不寫空話廢話；
• 需求文檔不僅僅是個名詞，更應該加「輸出」這個動詞，關注完整輸出過程，能夠使需求流程更加流暢；
• 產品經理應該有自己的技能樹，每次積累總結都能點亮一項技能，「需求文檔」這件“小事”是最應該前期先點亮的技能。

附上axure原型文件，鏈接: https://pan.baidu.com/s/1o8K87Ui 密碼: gtkx，僅供參考。

作者：WinsonL，微信公眾號：WinsonL，魅族科技Flyme產品經理，成長焦慮人群的其中一員，用實例干貨分享思考和經驗。

本文由 @WinsonL 原創發布于人人都是產品經理。未經許可，禁止轉載。