前言
眾所周知，互聯網行業的產品經理每天需要與形形色色、不同崗位的人溝通，上至老板，下至測試、客服等。產品經理的日常事務性工作有一大半都花在了與不同崗位的溝通協調上，自然在工作中也會和各崗位產生諸多交集。都說產品經理是CEO的學前班，所以就該你這么忙。那么在團隊協作中，產品經理與各崗位之間的工作界限是如何劃分的？對于很多“佛系”的產品經理可就是個難題。下面我們就來聊一聊“佛系”產品經理在日常工作中是怎樣處理的。
與運營的愛恨交織
行業中，很多人都會認為運營與產品是不分家的，他們需要共同為產品的績效考核指標負責，為用戶體驗負責，所以這兩個崗位的工作界限真的是說不清，理還亂。
記得某一年的4月份，運營總監找到我，說老板需要一份關于產品的年度規劃方案，對于這份方案，老板只有一個要求，希望今年的新增用戶達到1000萬，要求在一周內完成方案。聽完后，我的直覺是這應該是一份關于運營的年度規劃，哪里是產品設計、產品研發的規劃方案。聽完后，我試圖向他解釋說明，這是一個運營工作中關于拉新的方案，不是產品的規劃方案，也不應該由產品經理來編寫這份方案。嘮叨了半天，我的解釋說明是無效的，最終還是被運營總監懟回去了，他認為這個目標的完成，和產品設計、研發關系緊密，需要我們產品研發部先給出一份年度規劃方案。然后還和我說了一堆，產品經理也需要對考核指標負責，接著還向我說明了他的思考方向與思路。
就這樣，一臉無奈的接了這么個重要任務。方案中，將1000萬的目標拆解到每個月，從運營的手段，產品的改版、優化，營銷策略等幾個維度來規劃具體工作。后來這位總監還找到我，幫忙完成了多個營銷活動方案的策劃，甚至活動效果的總結。說實在的，也感謝他給我安排的這些任務，提升了自己的全局性思維，提升了自己看問題的高度與深度。
與設計師的千絲萬縷
日常工作中，產品經理與UI設計師、視覺設計師之間的溝通合作也很頻繁，大家都同屬設計這一寬泛領域，只不過產品經理強調的是邏輯設計、結構設計，而他們更多關注的是視覺效果層面。
視覺設計師通常是在收到產品經理的原型設計后，才開始處理視覺顯示的問題。很多視覺設計師都是直接按照原型的布局、結構、甚至顏色來設計界面，在他們看來只需要做好給頁面配色，僅僅處理好這個層面的視覺顯示問題就算完成了工作。如果做完后，發現還需要調整按鈕或文字的位置，修改字體的大小或字體，他們會認為這是產品經理的原型設計有誤，沒有明確表達出這一效果。在與這類設計師工作配合中，我們只能盡量嚴格要求自己，提高原型的保真度，按鈕的位置、顏色、字體的選擇、字體的大小，還有一些陰影、透明度效果盡量表現出來。
有一次在做高保時，需要從網上摳取一張圖片，當時想找一位設計師幫忙，那位設計師貌似有些不耐煩的說道，摳圖這么簡單的事情都不會啊，哪個產品經理不會使用PS。所以，只能自己琢磨如何摳圖，當即從百度搜索了一些摳圖的技巧，業余時間還將框選、套索、魔鏡、鋼筆等所有的摳圖方法系統性的學習了一遍，從此摳圖不求人。
與程序員的不打不相識
產品經理與程序員打交道的機會就更多了，他們之間的故事不勝枚舉，在很多公司這兩個崗位似乎總是對立的，產品經理與程序員的撕逼大戰每天都有人在上演著。不是程序員在抱怨產品經理不懂技術、更改需求，就是產品經理在抱怨程序員的研發能力不足、拖延需求等。
對于很多沒有技術背景的產品經理來說，在與程序員溝通的時候，會顯得格外困難，當你在和他們描述業務需求的時，他們的評估反饋通常是這樣的：這里需要一個什么樣的接口來實現，這些內容存儲在客戶端本地會比接口調用效率更高；數據庫應該怎么樣設計，包含哪些表，表里包含哪些字段。他們不停的向你反饋這些內容，以表示他們對業務需求的理解，希望得到你的確認。相信很多產品經理，在聽到程序員的這些話，是處于一臉茫然的狀態。如果你不能明白他們這些話，隨意進行確認，而事后等到測試階段又發現了問題，這個時候在去找程序員去提BUG的時候，程序員通常會覺得這個產品經理不靠譜，又是在隨意更改需求，同時也會引發很多爭吵的聲音。
既然程序員不能在溝通中轉變他們的思維，如何理解專業的開發術語，了解一些基礎的技術原理？那么身為產品經理怎么辦，我們只能自己去學習了解接口能夠實現的功能、了解接口規范，了解數據庫設計的一些基礎理論。懂得去分析哪些功能或者內容，需要依賴于接口的開發傳遞，哪些功能或者數據更適合客戶端的本地開發，了解在前后端接口聯調過程中有哪些注意事項。
記得曾經有一位技術總監要求我監控程序員的開發進度，他讓我建立了這樣一個表格，羅列出項目中包含的頁面，每個頁面包含的接口，接口的名稱、接口的說明、接口的完成情況、接口開發的實際工作量。在技術評審會上，他們要求我一起參與確定關于接口的名稱、定義、說明，確認數據庫結構、數據表的字段設計。起初，在制定、維護這樣的項目進度監控表時，遇到了很多困難，心里也有過很多抱怨。因為按照這樣的要求來監控項目進度，必然需要產品經理對開發常用的技術原理非常熟悉，這樣的進度表似乎有點超出了產品經理的監控范疇。雖然對于這樣的項目進度監控，還是頭一次，完全從技術開發的角度來監控項目進度，但確實也讓我學到了很多，對技術原理的認識更加深刻了。
與測試工程師的唇亡齒寒
大家都說產品經理需要對產品的結果負責，所以上線前的需求確認自然成為了產品經理的份內工作。在上線前，有些產品經理都會仔細確認產品的文案，確認產品的核心功能是否完善，操作流程是否順暢，業務流程是否正確。很多時候，其實是產品經理和測試工程師一同對產品質量負責，甚至在上線后出現重大問題，產品經理可能是第一責任人。
我們團隊的測試工程師都沒有編寫測試用例的習慣，他們總是說很忙，認為有了詳細的需求用例，沒有必要在編寫測試用例文檔。所以在閱讀需求文檔時，常常會要求我們將需求用例寫的足夠詳細，包含哪些操作步驟，期望輸出結果，限制條件等。為了滿足開發、測試他們的要求，希望從他們的思維角度能夠準確理解業務需求，編寫PRD時，再一次妥協了。在需求文檔中，當你將需求用例描述的盡可能詳細時，意味著你對用戶操作流程的理解也會更加深刻，對很多細節的把控也會更加到位。
我們的測試工程師還有一個習慣，在測試過程中，如果遇到不清楚的需求或者不能推動開發解決BUG時，通常會在禪道系統中將問題提交給產品經理。每次產品進行大版本的改動時，都能收到來自測試提交的幾十個BUG。他們不愿意做推動問題解決的第一人，這個重擔還是落在了我的身上。有時候一個BUG問題可能會牽涉到好幾個開發之間的配合，所以我想這也是測試工程師將一些BUG指派給我的原因，麻煩事都落在我的身上。但從另一個角度來說，我也感謝他們，正是因為這樣的一些經歷，使得我在開發項目中遇到問題時，能夠較快的定位問題出在哪里，并給出一些建設性的解決方案，開發同學們也更愿意與我合作了，對我也多了一份信任。面對項目實施中遇到的問題，也能更從容應對。
最后的總結與期望
”佛系”產品經理的工作似乎沒有邊界，在溝通過程中不夠強勢，工作也比較辛苦，勞心勞力。身為一個產品新人，自己還不夠強大時，很多“佛系"產品經理的一些習慣能夠促使自己變得更加強大，能夠獲得快速提升自己綜合能力的機會。平時工作當中謙虛點、低調點、溫柔點，從某種角度上來說，吃虧也是一種福分。”佛系”產品經理能夠鍛煉自己的意志，不斷提升自己的綜合實力，使得自己成為團隊當中不可替代的一類人。
佛系產品經理是團隊當中的多面手，哪里需要就去哪里，遇到問題不閃躲，快速解決問題，是團隊當中的救火隊長。“佛系”的做法，只是我們在職場當中打怪升級的一些方法，但并不等同于工作中沒有立場，沒有原則。希望各位產品人，能夠利用自己“佛性”的一面，提升自己的綜合能力，在工作中，綻放你的光芒。
