引子:產品經理(product manager-PM)這個崗位,名叫“經理”卻不是名詞那個經理,工作內容更是被很多人認為就是個寫文檔的低級工種。實際上,誤解多源于不了解,產品經理所做的腦力和體力工作是否就一定比開發工程師的幾萬行代碼少呢?下文為知乎上一篇關于產品經理工作內容的轉載,原文地址:http://www.zhihu.com/question/19906787/answer/23271174?utm_campaign=official_account&utm_source=weibo&utm_medium=zhihu&utm_content=answer,特注明出處,作者為魏暢然,PM@多聽FM。
“好久不在知乎冒泡,正式在國內互聯網創業公司工作三個月,趁著這個問題整理下最近略為凌亂的思路。
略微拓展下問題的范圍,不局限于產品上線前,而將其放在產品需求文檔交付之后,即產品正式進入全面開發階段,產品經理每天的工作是什么。
參與制定詳細的項目開發時間表
項目開發時間表應該在與開發人員一起評審完需求文檔之后的一至兩天內制定出來,根據需求文檔中的用例細化每一部分的開發時間。此項任務需與程序員哥哥們通力配合,首先要全面地收集他們在聽完需求文檔評審后對于產品本身的意見與建議,然后逐項予以合理的解釋,以保證程序員哥哥們打心底里認同這個產品,認同形成這個產品的每一個需求。另外作為一個PM,也應該要對基本的開發流程有所了解,在制定每個需求的開發周期時提出正確的建議,保證最終的項目開發時間表既不會拖慢整個項目的進度,也沒有超出程序員哥哥們每天正常的工作量,保證他們不會感到過大的開發壓力。
補充程序開發過程中所缺失的資源
如果是一個客戶端產品,則最重要的兩部分開發資源,一是后臺測試接口,二是前端UI切圖。這些資源在與技術人員一起評審完需求文檔之后都應立刻提上日程,接口方面PM應盡可能地給出一份所需要的接口列表以及每個接口的基本字段,完成后將接口文檔郵件給后臺及客戶端開發工程師,以方便他們在這份文檔的基礎上更為快速地完成正式測試接口需求的對接,并在雙方對接的過程中,提供相應的產品方面的支持。UI切圖方面,前期可以先讓客戶端開發工程師參考原型圖搭基本的界面框架,并在這段時間內盡快與UI方面保持溝通,快速迭代出滿意的設計圖。設計圖通過后,一到兩天的時間內讓UI設計師將設計圖切圖后打包,發送給客戶端工程師以方便他們完善界面。
客戶端后臺的需求文檔撰寫
思考產品正式上線后各部分的內容該如何維護、如何更新、以什么樣的頻率更新,即如何以最有效率的方式在客戶端后臺更新客戶端顯示數據。
對于后臺需求文檔,UI不重要,邏輯很重要。要求PM對整個產品的架構爛熟于心,哪個模塊需要以什么樣的方式進行更新,如何在網站版的后臺組織這些所需要的數據。一個優秀的PM頂半個架構師,這一點不僅僅體現在產品本身某些重要的大邏輯上,在撰寫后臺需求文檔時一樣可以體現得淋漓盡致。
項目整體進度跟進
對于整體項目的進度,要做到心里有數,每天更新項目進度表,了解最新的項目進展與動態,解決開發過程中已經出現的問題,并將自己看到的潛在問題盡量扼殺在萌芽之中。當然,最重要的是,所謂跟進,不是每天盯著工程師問進度,更多地是要以描繪產品未來愿景的方式鼓舞士氣,讓團隊中的每一個人都感受到自己肩上的重任并愿意主動地去承擔。
下一階段的產品規劃
此處的下一階段應分為兩個部分,一是目前的開發周期完成后就需要添加的新需求或老需求的優化,二是目前產品上線后下一個版本可能要做的需求更新或整體產品的改版。優先級為先做第一部分的事情,再做第二部分的事情。第一部分的事情應形成正式的需求文檔,第二部分的事情更多的是以bullet-point的形式出現在PM的記事本中,以方便在產品正式上線后結合用戶反饋,快速形成一份新的產品2.0版需求文檔。
與運營同事合作制定產品的營銷推廣計劃
PM生孩子,運營養孩子。產品這個小娃娃已經接近出生,后續的養育工作自然應該列入工作計劃之中。在這一方面,PM重點需要去做的并不是制定出一份完整的營銷推廣計劃,而是盡可能多地讓同你合作的運營同事了解你做出來的這個產品。這個產品是什么?以怎樣聰明的方式解決了用戶的哪些痛點?這個產品身上所帶的情懷與氣質是怎樣的?這個產品的目標用戶群在哪?商業模式又是怎樣的?相信如果PM可以幫助一起合作的運營同事搞清楚以上的這些問題,專業的PO同事一定會拿出一份讓你拍案叫好的推廣計劃的。當然,如果PM有一些抖機靈的點子,自然也可以多于PO同事分享,這世界上哪有什么軟文,被叫做軟文的文章不過是寫得爛到家的推廣文案。
利用專業的測試工具進行有效的QA
千呼萬喚始出來,猶抱琵琶半遮面。產品終于開發完畢,正式進入QA階段,沒有大公司必備的專業測試框架,我們至少還有這雙手。撰寫測試用例,然后逐條測試,以保證產品的穩定性、流暢性、易用性?!?/p>