作者：拼搏的80後

全文共 3280 字，閱讀需要 7 分鐘

———— / BEGIN / ————

眾所周知，網際網路行業的產品經理每天需要與形形色色、不同崗位的人溝通，上至老闆，下至測試、客服等。

產品經理的日常事務性工作有一大半都花在了與不同崗位的溝通協調上，自然在工作中也會和各崗位產生諸多交集。

都說產品經理是CEO的學前班，所以就該你這麼忙。

那麼在團隊協作中，產品經理與各崗位之間的工作界限是如何劃分的？

對於很多“佛系”的產品經理，可就是個難題。

下面我們就來聊一聊，“佛系”產品經理在日常工作中是怎樣處理的。

一、與運營的愛恨交織

行業中，很多人都會認為運營與產品是不分家的：他們需要共同為產品的績效考核指標負責，為使用者體驗負責，

記得某一年的4月份，運營總監找到我，說老闆需要一份關於產品的年度規劃方案。對於這份方案，老闆只有一個要求：希望今年的新增使用者達到1000萬，要求在一週內完成方案。

聽完後，我的直覺是這應該是一份關於運營的年度規劃，哪裡是產品設計、產品研發的規劃方案。

我試圖向他解釋說明：這是一個運營工作中關於拉新的方案，不是產品的規劃方案，也不應該由產品經理來編寫這份方案。

嘮叨了半天，我的解釋說明是無效的，最終還是被運營總監懟回去了——他認為這個目標的完成，和產品設計、研發關係緊密，需要我們產品研發部先給出一份年度規劃方案。然後還和我說了一堆產品經理也需要對考核指標負責，接著還向我說明了他的思考方向與思路。

就這樣，一臉無奈的接了這麼個重要任務。

方案中，將1000萬的目標拆解到每個月，從運營的手段，產品的改版、優化，營銷策略等幾個維度來規劃具體工作。後來這位總監還找到我，幫忙完成了多個營銷活動方案的策劃，甚至活動效果的總結。

說實在的，也感謝他給我安排的這些任務，提升了自己的全域性性思維，提升了自己看問題的高度與深度。

二、與設計師的千絲萬縷

日常工作中，產品經理與UI設計師、視覺設計師之間的溝通合作也很頻繁，大家都同屬設計這一寬泛領域——只不過產品經理強調的是邏輯設計、結構設計，而他們更多關注的是視覺效果層面。

視覺設計師通常是在收到產品經理的原型設計後，才開始處理視覺顯示的問題。

很多視覺設計師都是直接按照原型的佈局、結構、甚至顏色來設計介面，在他們看來：只需要做好給頁面配色，僅僅處理好這個層面的視覺顯示問題就算完成了工作。

如果做完後，發現還需要調整按鈕或文字的位置，修改字型的大小或字型，他們會認為這是產品經理的原型設計有誤，沒有明確表達出這一效果。

在與這類設計師工作配合中，我們只能儘量嚴格要求自己，提高原型的保真度，按鈕的位置、顏色、字型的選擇、字型的大小，還有一些陰影、透明度效果儘量表現出來。

有一次在做高保時，需要從網上摳取一張圖片，當時想找一位設計師幫忙，那位設計師貌似有些不耐煩的說道：摳圖這麼簡單的事情都不會啊，哪個產品經理不會使用PS。

所以，只能自己琢磨如何摳圖，當即從百度搜索了一些摳圖的技巧，業餘時間還將框選、套索、魔鏡、鋼筆等所有的摳圖方法系統性的學習了一遍，從此摳圖不求人。

三、與程式設計師的不打不相識

產品經理與程式設計師打交道的機會就更多了，他們之間的故事不勝列舉，在很多公司這兩個崗位似乎總是對立的，產品經理與程式設計師的撕逼大戰每天都有人在上演著。

不是程式設計師在抱怨產品經理不懂技術、更改需求，就是產品經理在抱怨程式設計師的研發能力不足、拖延需求等。

對於很多沒有技術背景的產品經理來說，在與程式設計師溝通的時候會顯得格外困難。

當你在和他們描述業務需求的時，他們的評估反饋通常是這樣的：這裡需要一個什麼樣的介面來實現，這些內容儲存在客戶端本地會比介面呼叫效率更高；資料庫應該怎麼樣設計，包含哪些表，表裡包含哪些欄位。

他們不停的向你反饋這些內容，以表示他們對業務需求的理解，希望得到你的確認。

相信很多產品經理，在聽到程式設計師的這些話，是處於一臉茫然的狀態。

如果你不能明白他們這些話，隨意進行確認，而事後等到測試階段又發現了問題，這個時候在去找程式設計師去提BUG的時候，程式設計師通常會覺得這個產品經理不靠譜——又是在隨意更改需求？同時也會引發很多爭吵的聲音。

既然程式設計師不能在溝通中轉變他們的思維，那麼身為產品經理怎麼辦？

我們只能自己去學習瞭解介面能夠實現的功能、瞭解介面規範、瞭解資料庫設計的一些基礎理論。懂得去分析：哪些功能或者內容需要依賴於介面的開發傳遞，哪些功能或者資料更適合客戶端的本地開發，瞭解在前後端介面聯調過程中有哪些注意事項。

記得曾經有一位技術總監要求我監控程式設計師的開發進度，他讓我建立了這樣一個表格，羅列出專案中包含的頁面、每個頁面包含的介面、介面的名稱、介面的說明、介面的完成情況、介面開發的實際工作量。在技術評審會上，他們要求我一起參與確定關於介面的名稱、定義、說明，確認資料庫結構、資料表的欄位設計。

起初，在制定、維護這樣的專案進度監控表時，遇到了很多困難，心裡也有過很多抱怨——因為按照這樣的要求來監控專案進度，必然需要產品經理對開發常用的技術原理非常熟悉，這樣的進度表似乎有點超出了產品經理的監控範疇。

雖然對於這樣的專案進度監控，還是頭一次，完全從技術開發的角度來監控專案進度，但確實也讓我學到了很多，對技術原理的認識更加深刻了。

四、與測試工程師的脣亡齒寒

大家都說產品經理需要對產品的結果負責，所以上線前的需求確認自然成為了產品經理的份內工作。

在上線前，有些產品經理都會仔細確認產品的文案，確認產品的核心功能是否完善，操作流程是否順暢，業務流程是否正確。

很多時候，其實是產品經理和測試工程師一同對產品質量負責，甚至在上線後出現重大問題，產品經理可能是第一責任人。

我們團隊的測試工程師都沒有編寫測試用例的習慣，他們總是說很忙，認為有了詳細的需求用例，沒有必要在編寫測試用例文件。

所以在閱讀需求文件時，常常會要求我們將需求用例寫的足夠詳細，包含哪些操作步驟，期望輸出結果，限制條件等。

為了滿足開發、測試他們的要求，希望從他們的思維角度能夠準確理解業務需求，編寫PRD時，再一次妥協了。

在需求文件中，當你將需求用例描述的儘可能詳細時，意味著你對使用者操作流程的理解也會更加深刻，對很多細節的把控也會更加到位。

我們的測試工程師還有一個習慣：在測試過程中，如果遇到不清楚的需求或者不能推動開發解決BUG時，通常會在禪道系統中將問題提交給產品經理。

每次產品進行大版本的改動時，都能收到來自測試提交的幾十個BUG——他們不願意做推動問題解決的第一人，這個重擔還是落在了我的身上。

有時候一個BUG問題可能會牽涉到好幾個開發之間的配合，所以我想這也是測試工程師將一些BUG指派給我的原因：麻煩事都落在我的身上。

但從另一個角度來說，我也感謝他們：正是因為這樣的一些經歷，使得我在開發專案中遇到問題時，能夠較快的定位問題出在哪裡，並給出一些建設性的解決方案，開發同學們也更願意與我合作了，對我也多了一份信任。面對專案實施中遇到的問題，也能更從容應對。

五、最後的總結與期望

“佛系”產品經理的工作似乎沒有邊界，在溝通過程中不夠強勢，工作也比較辛苦，勞心勞力。

身為一個產品新人，自己還不夠強大時，很多“佛系”產品經理的一些習慣能夠促使自己變得更加強大，能夠獲得快速提升自己綜合能力的機會。

平時工作當中謙虛點、低調點、溫柔點，從某種角度上來說，吃虧也是一種福分。“佛系”產品經理能夠鍛鍊自己的意志，不斷提升自己的綜合實力，使得自己成為團隊當中不可替代的一類人。

佛系產品經理是團隊當中的多面手，哪裡需要就去哪裡，遇到問題不閃躲，快速解決問題，是團隊當中的救火隊長。

“佛系”的做法，只是我們在職場當中打怪升級的一些方法，但並不等同於工作中沒有立場，沒有原則。

希望各位產品人，能夠利用自己“佛性”的一面，提升自己的綜合能力，在工作中，綻放你的光芒。

———— / END / ————

作者：拼搏的80後，行業資深PM，樂於分享網際網路的那些事

點選“閱讀原文”下載APP