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