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

本文提到的產品經理工作流程，主要來源于本人在日常工作中的總結凝練，并不適用于所有公司的實際工作流程，僅供各位大佬參考，歡迎大家批評指正哦。

一個中后臺產品項目從最開始接到需求到最后開發完成上線，這期間產品經理到底運籌帷幄了哪些事情？經過了哪些流程？一個需求到底是怎么完成的？

本文將對產品經理的大致工作流程進行闡述，因為本人做的是中后臺系統方向的產品，所以講述的流程和C端產品經理的工作流程多少會有些出入，當然我會盡量從更廣的維度上去概述產品經理的工作流程，爭取把平常的工作流程都覆蓋到，后續再寫文章對各個流程做詳細的介紹。

一、需求收集

所有的產品需求，必定會有一個需求的來源。

常見的需求來源有：

1、業務人員提需

業務方在使用產品的過程中，會反饋產品的bug、體驗、流程等各方面的問題。

此處的業務人員，你可以將其理解為一個泛稱，它可以是客戶、老板、領導等各個使用產品的角色。

2、技術人員提需

技術方案的升級迭代，有時也需要產品的同步支持?；蛘呖赡軙屑夹g上一些解決問題的手段，需要產品化和平臺化，方便各部門員工的使用。

3、產品規劃

產品規劃，需要適應公司戰略方向，所以當戰略方向有所調整時，產品規劃可能也要跟著有所變動，這個時候，就會有新的產品需求出現。

二、需求記錄

產品經理不可能一下子把所有需求都做完，總要有一個先后順序，所以就會涉及到需求的記錄管理。

一般產品經理會將需求放到需求池中，記錄清楚需求的提出人、提出時間、需求描述/需求場景、需求類型、需求進度等信息。

產品需求池要秉承一個寬進嚴出的原則，在需求收集階段時，可以廣泛的收集需求，不用太過于深究需求的合理性，主要就是做好需求的記錄，便于后期追溯和需求分析。

三、需求分析管理

需求分析到底分析個啥呢？主要就是弄清楚需求的真偽、價值收益、成本、本質、優先級等，進而綜合考慮有哪些需求要做、什么時候做、誰來做、投入多少資源等。

四、需求評審立項

所謂評審立項，各個公司的方式更是五花八門，有的公司需要需求發布，講明需求背景、收益、成本等各個條件，各個有關部門的老板們覺得ok了，這個需求才能安排開發人力，正式提上日程；有的公司產品總監一個人就能拍板做不做一個需求。

雖然立項的方式有繁有簡，各不相同，但立項這個步驟是不可省略的，這標志著一個需求從冷冰冰的需求池中正式提了出來，踏上了即將上線的路程，所以產品經理需要重視立項這個步驟。

五、需求調研

有同學可能會問了，在需求分析管理階段，不是已經分析過需求了嗎，為什么又要有需求調研這一步，兩者有什么區別嗎？

需求分析管理，產品經理解決的是要不要做一個需求的問題，而需求調研，解決的是如何做的問題。

特別是b端產品，涉及到較為復雜的業務場景，以及不同用戶角色間的需求差異，所以在做需求時，就需要通過調研，了解業務實際，綜合的考慮需求實現方式，避免需求場景遺漏，或出現顧此失彼，考慮不全的情況。

至于具體的需求調研方式，常見的有訪談法、問卷調研、觀察法等，產品經理可以根據自身實際情況，靈活掌握并判斷使用什么方式。

六、競品分析

不管是B端產品還是C端產品，競品分析都是一個做好需求的利器，大到產品架構，小到功能交互和文案，都能通過競品分析來獲取靈感。

因為很多東西，你空想的話是很難想出來的，而且還會浪費很多時間，所以要善于使用競品分析，站在巨人的肩膀上。

正所謂天下文章一大抄，就看你會抄不會抄。做競品分析肯定不是讓你原封不動的照搬人家的東西，那樣的話，一是不道德，甚至有法律風險，二是可能并不符合需求的實際情況。所以競品分析更多的是提供方向和靈感，就算是抄，也要有差異化，做到“因地制宜”。

七、需求方案設計

對于新人產品經理來說，這一步往往是最讓人期待和激動的，就好像學了好久的車，終于可以上路行駛了一樣。

不過新手上路，總會碰到一些意想不到的情況，如果沒有什么經驗，或者考慮不周，難免會有些磕磕碰碰，出產品的需求方案也是一樣的道理，需要謹慎細致，考慮全面。

出需求方案，并不是一上來就開始畫原型寫prd，而是還有一些前置工作需要做。

需求調研清楚后，產品經理需要繪制相應的用例圖/業務流程圖/產品結構圖/系統交互流程圖/狀態圖等各種需要的圖，不過這些也要看具體需求的復雜程度，并不是每個需求都要畫一堆圖出來，產品經理可以根據實際情況，判斷是否需要以及需要繪制哪種圖。

一般較為常用的是流程圖和產品結構圖，流程圖幫助產品經理在動手畫原型之前，梳理清楚主干、分支和異常流程，避免遺漏關鍵場景；產品結構圖一般包括了產品信息和功能，基本上產品結構圖畫好后，產品原型圖就能跟著畫出來了。

不要一上來就畫原型的另一個原因，是因為在主要流程還沒有梳理流暢時，原型畫起來會很慢，而且很容易出錯，而錯了改起來又很麻煩，費時費力，還不一定能把邏輯搞清楚。

所以可以先用低成本的流程圖理清邏輯，利用流程圖跟業務和技術去溝通，如果發現錯誤還能及時修正，避免后續大反工。

做完前置工作，再畫原型、寫prd就會流暢很多，即使發現沒有考慮到的地方，也能很輕松的進行修改。

八、需求方案評審

需求方案出來后，如果沒有其他情況的話，接下來的一個大動作就是要需求評審了。

需求評審對于很多產品經理，不管是新手老手，都是一座山，被懟互撕那都是常有的事情。所以產品經理不僅要平時和研發同學搞好人際關系，而且要盡可能的把需求文檔寫好，在實現需求的同時，也要考慮研發成本。

評審前

可以把方案發給關鍵的業務和技術人員看一看，避免用一個有巨大邏輯漏洞的方案來進行評審，否則那種感覺真的會很難受。

另外，大家都很忙，召開評審之前，一定要確定好參會人員，約好大家的時間，將方案發到群里，給大家預留看文檔的時間。

評審中

對于各方提出的問題，要及時做好記錄，如果有會議錄制條件的，最好進行錄制，一是如果會后有遺忘的點，可以回溯查看，二是留下評審的證據，如果后續有甩不清的鍋，可以看看評審記錄到底當時是咋說的。

另外，評審結束時，記得讓開發給排期，有時較為復雜的需求，技術可能還會有一個技術評審才能出排期（如果涉及到ui介入的，還要有ui設計的排期），總之，要及時跟進要排期，防止需求開發被一拖再拖。

評審后

需要將評審中提到的需要改動的點，或者是一些待辦事項總結好發給各參會方，如果有群的話也可以發到群里，并艾特全體成員。有針對某個人的待辦，也可以再單獨私發一次，防止對方遺忘。

九、跟進開發進度

ui、前后端、測試的排期給出后，接下來一段時間，產品經理的主要工作就是跟進開發進度了。

跟進開發進度，除了單純的過問開發進度，保證開發按計劃進行之外，還要積極配合前后端的開發。

因為有些問題在評審中可能并不會暴露出來，對于前后端在開發中拋出的問題，產品經理要及時處理，做出決策，畢竟在沒有項目經理的情況下，產品經理一般是會作為需求的主owner的，一定要對得起崗位名稱中“經理”這兩個字，做一個負責任的產品經理。

在開發過程中，原則上是不做大的需求改動的，如果有需要改動比較大的情況，只要不是本期必須要實現的功能，也不是碰到技術不能實現的功能點，都可以考慮放到下一期需求迭代中，確保當期需求順利開發完成，避免拖泥帶水。

十、走查測試

需求開發完并聯調后，前后端一般會給出一個走查環境（也可以叫測試環境），產品經理需要根據需求文檔進行走查測試，排查問題，由開發人員及時解決。

走查時也要注意，一定要細致全面，如果在走查過程中有什么新想法，或者發現哪里由遺漏（prd中沒寫，但是卻需要的），小改動可以跟開發人員協商直接在當期做了，如果是大改動的話，只要當期需求能跑的通，盡量把改動點放到下一期進行迭代。要是因為產品經理執意加需求導致需求開發延期，那么這鍋是絕對摘不掉的，一定要注意。

測試工程師介入測試，可以和產品經理走查并行，也可以在走查之后進行，具體什么時候開始測試，可以看公司的工作習慣和需求的難易程度，一些太小太簡單的需求，可能不需要測試工程師的介入，走查沒問題即可上線。

十一、上線驗收

終于迎來了這關鍵的時刻了，激動人心啊。

但是也不要高興的太早哦，產品上線后，產品經理也要進行線上驗收，如果涉及到灰度發布，后續還要看什么時候全量發布上線。

為什么上線前也走查了，也測試了，上線后還要再檢查一遍呢？因為產品上線并不是像打開一個開關一樣，點擊一下上線就上線了，在上線過程中，有可能會出現各種各樣的問題，這都會影響產品實際到線上的效果，產品經理要和前后端開發人員一起，防范并處理產品上線后可能出現的風險。

十二、撰寫操作手冊

產品終于成功上線了，對于中后臺產品，或者是B端產品來說，較為復雜的需求上線后，需要撰寫操作手冊，并組織相關培訓，方便業務人員的使用。

十三、數據分析

產品上線后，到底能不能被用戶認可，就要通過相應的數據分析來體現了，如果產品上線后，壓根就沒什么人用，那么很有可能這個需求就是個偽需求，或者是缺乏相應的運營手段支撐。