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

筆者整理了上、下兩篇《產品經理工作指南》文章，核心只針對產品功能、設計方面，不囊括日常溝通、項目管理、資源協調等方面；文章將從產品評估、產品需求、產品結構及流程、原型設計及邏輯規則四個方面進行闡述。enjoy~

一年前，結合自身工作經歷談到《如何用Axure輸出一份結構清晰的prd 》文章發布后收到很多小伙伴的相關反饋，截止目前為止來自小伙伴們的反饋中主要為以下幾個方面：

1. 需求分析不夠透徹
2. 產品設計不夠嚴謹
3. 異常流程考慮不夠全面
4. 邏輯規則不夠完善

以及一些剛入坑的朋友們很好奇產品從0~1到底要做些什么工作，需要哪些文檔資料等。

因產品經理日常工作沒有明確定義和標準，所以筆者針對上述問題結合自身工作經歷，和大家聊一下：一個產品從0~1，或是一個訴求到產品功能的誕生，需要做些什么事情、輸入什么內容，又如何保證輸出內容的完善。

為此筆者整理了上、下兩篇《產品經理工作指南》文章，核心只針對產品功能、設計方面，不囊括日常溝通、項目管理、資源協調等方面；文章將從產品評估、產品需求、產品結構及流程、原型設計及邏輯規則四個方面進行闡述。

一、產品評估

產品從0-1，首要任務是進行充分的產品評估，評估你和你的產品是否有可能性，而不是立馬去分析需求，進行產品設計、投入開發。而產品評估的內容涉及以下14項：

1. 背景、痛點：用戶存在什么不能忍受的且持續反復出現的問題。
2. 產品價值：產品要解決什么問題。
3. 目標用戶/市場：為誰解決這個問題。
4. 解決方案：如何解決這個問題，產品核心所在，我們的產品核心功能。
5. 產品目標：目標一定是可以用數據去衡量的（沒有出現數據的目標不是合格的目標），而這個目標則是可以被拆解到各項目子線上，各項目子線再根據這個目標去制定對應的策略。
6. 度量指標：怎么判斷產品的成功與否。
7. 市場規模：成功的機會有多大。
8. 市場時機：切入市場的時機合適么。
9. 競爭格局：有哪些同類產品、競品；對手的功能和體驗如何。
10. 競爭優勢：為什么我們最適合做這個產品；是否還有競爭對手未滿足用戶痛點可共產品進行差異化。這一點很重要，企業一定要形成自己的護城河，不然在這個模仿的時代，很容易被別人取代。
11. 渠道、營銷策略：是否有現成的合作伙伴，如何尋找客戶，如何把產品推向市場。
12. 必要條件：解決方案必須滿足的條件是什么，缺少必要條件會導致失敗。
13. 成本分析：產品開發成本、拉取客戶成本、銷售產品成本、人力資源成本等。
14. 收入分析：盈利模式有哪些、收入、毛利等。

在進行好所有的產品評估之后，并且評估結果是這個產品真的值得做，那我們方可進行下一步，不然乘早結束為好，以免浪費不必要的財力物力。

當然通常會出現公司領導、老板強烈要求必須要做的情況，那我們應做的是除了服從命令立即執行之外盡量做一份產品評估報告給領導（或許領導在做之前并沒有考慮這么多，也或許站在領導的角度有更深層次的考慮，不過有了這份報告，說不定就會發生一些改變），如果明知山有虎偏向虎山行，既然領導、老板堅持那就做了，但是有這么一份產品評估報告，總能夠避免一些不必要的坑！

二、 產品需求自查

在產品評估之后、產品設計之前，我們還要進行產品需求自查的工作。包括以下內容：需求收集；需求分析；需求管理。

2.1 需求收集

如何收集需求，從哪些渠道去收集需求？

需求收集的方式和渠道有很多種，如：用戶訪談、調查問卷、實地調研、數據分析、業務部門訴求等。除此之外，還包括：線上產品bug修復、性能優化、用戶體驗提升等等，都是需求收集的范圍，總之，用適合當前公司、當前產品的方式去做即可。

2.2 需求分析/篩選

收集的需求是否經過認真地需求分析？

聽用戶的但不要照著做！特別是用戶自以為是的需求，（這里的用戶不僅僅指ToC產品的用戶，還包括老板、領導、運營、客服同事等等）我們要將收集來的需求，運用kano模型、四象限法則等方法過濾掉無用需求、反向需求，挖掘出深層次的含義，找到的真實需求，并表達為產品的解決方案，即轉化為真正的產品需求并為產品需求排定優先級！

2.3 需求管理

①需求問題池

將收集好的需求放進需求問題池，標明：需求描述、需求來源、提出時間、狀態、解決方案、分析人、處理時間。

• 需求描述：闡述清楚‘用戶’的問題、訴求及希望達到的目標；
• 需求來源：注明問題的來源，在需求分析后必要的情況下和關系人進行回復、溝通；
• 狀態：包括未分析、不予解決、確認為產品需求；
• 解決方案：特別是針對不予解決的需求，一定要備注好因為什么原因不予解決，比如該需求是偽需求、重復需求或者有另外實現方式等等。

②需求跟蹤矩陣

將需求問題池中問題，經過需求分析后，轉化為產品需求的需求匯總到需求跟蹤矩陣中，記錄好每個需求從確認到規劃到開發到測試上下的每個狀態，方便準確的跟蹤需求狀態。

矩陣包括：需求功能名稱、需求概述、需求類型、需求屬性、優先級、需求來源、需求狀態、對應原型及文檔、需求完成時間、責任人、備注等。

• 需求功能名稱：簡要說明功能定義，比如：新增電子發票、優化意見反饋、優化賬單詳情頁；
• 需求概述：大致闡述該需求的主要功能及效果，比如：支持用戶所有消費訂單進行開電子發票；
• 需求類型：即該需求的分類，包括原本的產品規劃的新增功能、運營/客服/老板等部門提的內部需求、bug修復、體驗優化、性能優化等等；
• 需求屬性：原始需求、修改需求、增加需求、刪除需求，主要為了記錄該需求進入需求跟蹤矩陣后的變更情況（個人認為該屬性的記錄十分重要），即便通過需求分析，轉化為真正的產品需求，在實際設計、開發過程中，仍存在增、刪、改等變更情況，所以一定要記錄好每個需求的屬性，并在每次版本迭代后，進行復盤，統計4種屬性的需求數量，若原始需求比例過少，就需要認真反思自己在需求分析過程中是不是考慮不全面、分析不嚴謹等等；
• 對應需求文檔及原型：簡單標注需求對應的原型或者文檔所在位置，方便快速檢索、查看。

三、產品結構及流程自查

通過需求分析，整理好真實的產品需求之后，就開始進入具體的設計階段。

如果是新產品或者某個大的功能模塊，需要提前進行產品功能結構設計，涉及較為復雜的流程，還需考慮是否繪制時序圖、業務流程圖等進行分析。

3.1 產品功能結構圖

是否有產品功能結構圖、產品模塊劃分是否合理、功能層級、分類是否合理，產品模塊是否包含該有的功能、產品模塊是否有優化的地方，同時需要將功能結構圖和信息圖區分開來，網上有很多關于產品功能結構圖和信息結構圖的區分，本文不再作過多的闡述。

3.2 系統交互圖

也稱為時序圖，描述對象是如何交互的，消息是如何在對象間發送和接收的，通常用來描述前端、客戶端、服務端或者本系統和其他系統之間的數據交互邏輯。如下圖：

3.3 業務流程圖

業務流程圖主要是為了描述作業順序和管理信息的流向，業務流程圖的繪制是按照業務的實際處理步驟和過程進行的。對于APP或者管理平臺等產品，也可以簡單的理解為用戶操作流程，你如何進行操作，系統如何進行反饋。其中需要充分考慮流程設計是否合理、異常流程是否設計、逆向流程的設計是否考慮周全，以及操作的容錯性等。

如下圖：

本文為《產品經理工作指南（上）》，以上內容就是產品評估、產品需求、產品結構及流程三部分內容。因篇幅有限，原型設計及邏輯規則稍后會在《產品經理工作指南（下）》中為大家分享，敬請期待！

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

題圖來自 Pexels，基于 CC0 協議