產品專員年終總結

總結是對某一階段的工作、學習或思想中的經驗或情況進行分析研究的書面材料，它能夠給人努力工作的動力，讓我們一起認真地寫一份總結吧。那麼如何把總結寫出新花樣呢？以下是小編為大家整理的產品專員年終總結，供大家參考借鑑，希望可以幫助到有需要的朋友。

已經將近半年了，一直想做一個總結。於是有了這篇文章，記錄了我作為產品專員的經歷。其中包含了一個產品從0到1的工作內容和自己的個人總結。覺得一個產品的從0到1就像建立一棟大廈，一磚一瓦都是這個大廈的一部分。產品也一樣，有許許多多細小繁瑣的工作。

一、需求調研

經手產品的第一步就是進行需求調研，一般會花近一個月的時間在業務部門對業務進行深度的瞭解與分析。

如果是產品重新開發，那麼首先做得是對現有系統進行調研。針對當前系統中存在的缺陷與不足進行優化，並提出解決方案。對現有系統調研主要採取了以下幾種方式：

1、時間觀察並記錄業務人員操作系統的過程，並在業務人員進行工作的時候與之交流，找出產品還不盡人意的地方。

2、自己親自操作系統，完成相關的業務，記錄下自己在操作過程中的體會。

3、業務人員在不操作系統的環境下進行對話，記錄他們自己對系統提出的需求以及自己的其它想法。這一步是對直接需要操作系統的業務人員進行調研，找出他們在使用現有系統過程中體驗不好的地方。

4、然後，在此調研的基礎上與管理業務人員的管理層進行對話，主要想獲取的信息是從他們角度系統需要滿足他們的哪些需求，以及他們怎樣能更方便地通過系統管理業務人員，實現業務的分配和高效地完成相關工作。

5、同時，在調研過程中更加重要的一點是產品需要和公司的戰略規劃同步。心得體會而公司的戰略規劃與業務息息相關。傳統企業都是業務催生需求，然後將需求傳遞給開發部門，開發部門進行研發以支持業務部門。

一個新型的互聯網公司，做產品的思路與方法與傳統的企業有些不同。先確認公司的戰略規劃，依據公司的戰略規劃與得到的需求調研結果着手進行產品設計與開發。

所以需要多次與管理層對話。如果需要閉門會議也必不可少，旨在會議結束後能確定明確的產品方案與戰略規劃同步。除此之外，也是為了產品需求調研的順利進行以及大家能夠更好地對產品進行認知。定期的跨部門會議也是需求調研的一種方案。多次的會議才能讓需求調研落幕，確認大致的產品方案。

需求調研結束後就需要產出一份mrd來對之前收集的信息整理。mrd裏主要陳述三個內容。要做什麼？為什麼做？怎麼做？mrd內的所有內容都是圍繞着這三點而展開。項目的立項需要mrd經過上級的同意後才可以進行。一般花一週左右時間做mrd，然後進行mrd的評審會議。

在mrd中還有一個很重要的內容，即是該產品開發需要投入的資源到底有哪些。在mrd中一定要明確地提出自己所需要的資源。公司的資源都是有限的，不論是人力資源還是硬件資源，永遠都是不夠的。所以要為自己的產品爭取資源。要正確地評估產品開發的工作量，然後索取對應的資源。不能在資源不足的情況下進行產品開發，如果因資源問題，產品延期或者產品質量不過關，那麼上級看到得只會是因為自己的能力不夠而沒有完成產品的開發。

二、產品設計

後台產品/b端產品，與c端產品有着非常大的差異性。c端產品因為面向對象是用户，所以非常注重用户體驗、交互設計以及視覺設計。c端產品需要在細節上進行不斷打磨，並且需要對用户的心理進行精確的捕捉。除了產品本身以外，還需要考慮許多外部因素，如競品、政策、技術等。c端產品中另一個重要的角色——運營，在後台產品中也得不到體現。往往只需要產品經理一個人就可以代替相關的工作。後台產品更加看重的是產品能夠清晰地體現業務邏輯，功能能夠滿足使用者的需求，首先強調的是產品的可用性，其次是產品的易用性。產品設計的過程當中分了三大步驟。

1、業務邏輯梳理

需求調研與分析完成後，就是自己對內容的消化和吸收。要想設計一個產品首先要做的事情是自己先清晰地理解一個產品。只有自己理解了，才能更好地推進產品進行開發。

先梳理清楚線下的業務流程。將線下的業務流程梳理清楚以後，然後才是對產品的思考。在進行業務邏輯梳理的時候我使用了三種工具。狀態圖，流程圖，泳道圖。為了理清業務邏輯我花了很多時間去畫流程圖。

有些人覺得花這麼多時間畫圖會浪費很多時間。我覺得仁者見仁智者見智了。對於我個人而言，每天搗弄這些圖，會很快加深我對產品的理解。特別是在業務比較複雜，而且之前又完全沒有接觸過相關方面知識的時候，僅靠大腦很難有清楚的思維，但是圖形化後卻能很好地理解。在業務整理上多花點時間整理，我覺得是很有必要的。

2、產品梳理

梳理好線下的業務邏輯以後，要將它抽離搬到線上。這個過程，可能會刪除掉某些線下的環節。所以要針對產品重新書寫流程圖。依據產出的流程圖基本上就可以大致確認產品的功能點，確認好所有功能點產出功能列表後就需要引入角色，將每個角色與功能進行對應。接下來就是搭建頁面架構。先搭頁面，再確定頁面內的功能，最後細化頁面內的信息。在原型出來以前，可以拿產品架構圖先和別人進行一下交流。產品架構圖相較於原型圖，與數據庫的設計思想比較一致。而原型視圖化後，對於數據庫設計卻反而變得抽象了。另外，產品架構圖修改較快捷，返工成本相對較小。

3、原型設計

產品梳理好以後，就要開始搭建原型了。原型就是將之前分析的結果通過具體的視覺展現向別人描述自己思考的過程與內容。繪製原型，先確定通過的.模塊，頁頭、頁尾、一級導航、二級導航……根據不同的產品選擇合適的佈局。再講產品架構圖中的內容填充到頁面內，熱門思想彙報並加入文字説明操作。最後對產品的細節加以説明，相關的文案、頁面寄到、反饋提醒、交互方式……細節內容可以直接在產品原型頁面旁邊進行註釋。

產品設計的內容需要囊括在prd中，為產品的開發提供詳細而明確的信息。更像是一份產品階段就暫時結束了。之後就是與開發溝通，推動產品一步一步往前走了。這個過程中，可能會有許多需求變更和返工。要有充足的耐心慢慢解決問題。

產品設計完成的產出物為prd。prd更像是一個產品字典，獨立於原型外，而又包括原型。prd的作用就是為了能夠讓產品開發人員能夠正確地理解產品然後進行正確的開發。

prd中除了產品設計的內容，還需要有的內容是產品的規劃。產品的總體目標是什麼？為了完成這個總目標需要分幾步，每一步驟完成的標誌是什麼？這和之後的項目排期息息相關。項目開發的進度、人員分配以及項目的優先級定義都會依據產品規劃進行。

prd撰寫完成後，就需要進行prd的評審會議。prd評審會議需要參與該項目的各個團隊的核心人員。包括設計部門的leader，前端的leader，後端的leader，測試部門的leader，項目的發起人，項目的審核人，以及和此項目相關的其它產品負責人。如果有leader無法參與會議時需要該leader指定人員代替參加。

在prd評審會議中，由產品經理對prd進行講解。工作總結在產品經理講解的過程中，與會人員有任何疑問都可以提出。prd評審會議上的主要目的是讓大家對產品達成共同的認知。如果與會人員沒有任何異議，即表示prd審核通過。之後再有任何問題需要直接尋找產品經理溝通。評審會議中，各個leader就需要進行資源的分配。各個部門的資源由各個部門的leader進行分派。資源分配完成後，產品經理特別需要注意的地方就是定下產品開發各個階段完成的時間，以保證產品開發的進度。各個leader確認好資源分配與定下產品開發節點的時間後，prd的評審會議就算告一段落。

prd結束後，就正式進入產品的開發階段了。

三、項目管理

在產品開發階段中，產品經理要承擔一個重要的職責，即是項目管理。項目管理是產品開發中非常重要的一部分，它影響到的是產品開發的進度、產品開發的質量、團隊成員的精神狀態。所以項目管理其實分了兩個部分，第一個就是團隊管理，第二個是項目進度管理。而這兩者又相互影響。

很多產品的開發都採用的敏捷開發流程。在敏捷開發流程中特別注重的是對團隊的管理。這個過程中，要讓每一個參與開發的人員理解了他們參與開發的產品具有什麼價值，讓他們知道，範文寫作這並不是單純的碼代碼，而是為了解決實際的問題而進行的工作。他們在鍵盤上敲出的每一個字母、數字與符號都存在意義。大家有了共同的奮鬥目標後，項目的開發進度會按照之前繪製的甘特圖順利進行。然而在實際的項目開發中，產品往往會因為各種原因延期。其中一個最大的因素就是業務部門的需求產生變動。這時候需要產品經理具有強大的溝通能力以及產品規劃能力去協調開發與業務需求之間的矛盾。

很多時候，業務部門覺得技術部門永遠無法滿足他們的需求，導致很多客户因此喪失或者影響正常工作。而技術部門又會覺得業務部門提出的很多需求都是無理取鬧。兩者站在不同的角度去看待對方是產生矛盾的根源。矛盾是否具有可協調性，就是產品經理需要深度考慮的問題。終於到等到產品開發完成了。但是實際的產品開發還遠遠沒有結束，產品的生命週期才剛剛開始，第一版本的上線產品會存在很多不足的地方。個人簡歷還要根據之前的產品規劃不斷地進行迭代以優化產品與跟戰略規劃和業務線同步。只要產品的週期沒有達到終點，產品經理就不能有一時的懈怠。

四、產品工作的收穫與體會

雖然工作不久，但我對產品這一職位有了更加深刻的認識，也對產品開發流程有了較為清晰的認知。每個公司對產品的認識都不一樣。每個人對產品的認識也不一樣。產品的作用除了在於產品的策劃與設計外，更重要的是要充分調動團隊成員，發揮團隊最大的作用，並推動項目順利前進，解決項目開發過程中遇到的問題。短期的工作中，對產品設計、需求、團隊管理和自我都有了新的認知。

1、對產品設計的認知

prd一定要詳細和完備。如果有開發人員看了prd還是不知道該如何做，那麼就是產品自己撰寫文檔和設計上出的問題了。當然，並不是所有問題都能通過文檔和原型解決，口頭上的交流也是有必要的。其次不同階段，產出的原型圖也是不同的。mrd只需要產品的大概框架，產品業務上的細節信息不需要在這時體現出來。而prd產出時，需要在原有原型上進行迭代。不要在原型設計上主觀地加入自己的ui設計。

第一，限制別人思維與影響別人工作。自己不是交互也不是前端，也就是説並不是專業的，會對團隊其它成員的開發和設計造成影響。

第二，耽誤自己時間，色彩與交互的應用會使工作成本加倍，佔用自己大量的時間。而實際上起到的作用並不大，甚至是負面影響。如axure有自帶的button，就不要自己用矩形做。做出來的效果不一定好，也容易使其它人產生誤解。按鈕用按鈕，文本用文本。原型重要的是簡單明瞭，邏輯清晰。

對於產品而言，時間是非常寶貴的東西。原型越簡潔，修改起來，成本就越低，越能提升團隊的工作效率。同樣在原型迭代的時候也能節省不少的時間。原型不是目的，只是過程。只要能將自己的意思傳達清楚，手繪圖也能解決問題。

2、對需求的認知

什麼才是用户真正的需求？需求評審的時候，團隊其它成員提到了很多的需求。我們也討論了很久，如何在現有流程解決這些需求，技術難點有哪些。等到最後總結時才發現，很多需求其實都只是偽需求。反而還將產品功能砍掉了一些。用户往往不能明確的表達自己的需求，傳遞給我們時也許我們理解上會有偏差。所以我們要多想一下，看清楚用户真正需要的東西和要解決的問題是什麼。

微信產品經理kant將需求的本質理解為“動機”。和最近看的《精益創業》中提高的“五個為什麼”會議非常一致，比找到問題和解決問題更加重要的是探索問題發生的原因。追根溯源，直到觸碰本質。最可怕的事情是全身心地投入到一件毫無意義的事情而且自我感覺良好。其實，很多時候我們都在做無效需求，只是自己並沒有意識到。需求分析時要透過表面，看到用户真正需要的東西到底是什麼，再去提出解決方案。

產品最好快速進行迭代開發，一是在迭代過程中，對需求有更好的理解，二是減少產品維護的成本。除了產品本身外，市場變化的速度實在太快了，也許只要慢一步原有的市場就會被其它產品佔領。

3、對自團隊管理的認知

產品經理要需要管理好團隊就需要具備一定的無授權領導能力。這種無授權領導能力來自於多方面。言表達能力、產品規劃能力、邏輯思維能力、思想高度等多種因素讓一個人具有人格魅力。我所在的公司，熊叔是第一個讓開發與產品在產品立項時，同時主動鼓掌的一個人。其原因在於熊叔將業務需求與產品需求進行了很好的融合，讓大家認識到自己所做的不是枯燥無味的寫完一段代碼，而是在不斷地貼近我們要實現的最終目標。團隊管理時，要讓每一個人意識到自己和自己所做的事情是有價值的。有了這一點，之後的開發大家的積極性和心態都會發生變化。而這僅僅是因為一個人半個小時的產品講解。用心去觸摸產品，用心去傳遞產品。才會讓一個團隊更加高效地發揮價值。

4、對自我的認知

仔細回頭看一看，最開始設計的原型與上線的產品差了很遠。經歷過才明白，需求萬變，努力不變。隨着需求的不停變更，產品的形態也在不停的變化。在不停聆聽需求的同時，有點變得為了做產品而做產品。有點忘記了最初的戰略規劃與解決的主要問題。

每一個人都有一個定位，這個定位來源於對於自我的認識。有的人深謀遠慮，擅長指點江山，站在戰略的層面對產品的全局進行規劃。有的人心思縝密，更加適合在既定的目標之下對每一個細微的模塊進行佈局。在眾多紛繁的任務中保持清醒的頭腦是一件十分不易的事情，並且在高強度的精神壓力下同時準確無誤的把握每一個產品的進程更是一件不易的事情。看一個人在工作上取得的成就，除了能力還有態度。我知道自己還有很多欠缺的地方。我會在今後的工作中更加努力，不斷地完善自我。

不畏懼自己一無所有。不因自己一無所有而陷入迷惘。認識到產品的整體，讓自己知道自己懂的真的很少。虛心若愚，求知若渴。如此，我們才能每天都不一樣。喬布斯説過大概這樣的話，人生是許許多多的點，有一天這些點會連成一條線，這就是你成功的原因。所以我要做到的是將線上的每一點進行拆分，盡力去做好每一點。每一次成功的起步常常看起來都很微不足道。別人眼中流露的不屑與輕視並不會阻礙你前進，而那些愛你的人給予你的力量將支撐着你走過整個風雨飄搖的旅程。

社會在不斷地發展，時代在不斷地進步，尤其是走在社會最前沿的互聯網行業更是瞬息萬變。不論是市場的變化還是相關技術的變更都對產品的從業之路有着深深地影響。而應對這種變化的方式，只有讓自己不斷地學習從而跟上每一次變化的步伐，站在時代的浪潮之巔。不斷地提高自己思考的廣度與深度，尋找到自己能夠適應、跟隨、引領時代的方式。最後牢記。不忘初心，方得始終。