產品工作中的溝通

產品工作中的溝通

來自專欄 一隻產品汪的心路歷程1. 與需求方

需求方通常希望自己提出的需求能優先做，如果不是部門負責人統一提需求，而是所有運營或市場的同學都可以來找PM提需求的話，那就需要PM建個需求池，根據自己的經驗來判定優先順序。所以要懂得如何優雅的拒絕需求，或用更好的方式替代。

2. 與設計師

設計師都是需要靈感和創意的，因為這是藝術。他們是人，不是機器。有的需求方嫌棄設計師做的圖片不夠好，我知道這個是需要靈感的，如果和設計師混的熟，我很樂意和他們一塊兒聊天。

我也知道他們是最溫和的，一般讓他們做啥就做啥，改來改去也不怎麼生氣，比程序猿們溫柔多了。但是，我不會說因為這個就胡亂改東西。啊~感謝設計師們~

3. 與開發人員

PM認為理所當然的事，開發人員卻不一定。PM認為可以省略不說的事，開發人員卻不一定。我不寫上，一般情況下開發們默認是沒有的。只有好心的開發會提醒我漏掉了什麼，但如果一直丟三落四，人家就懶得理我了。

一開始我只關注了產品主要流程，也就是正常情況下的流程。卻經常忽略掉else的情況：比如註冊成功的提示、註冊失敗的頁面，還有輸入框內容是否有效的判定、一頁應該顯示幾行，是自動載入還是上劃載入等等。。隨著經驗逐漸積累，慢慢的思考的也越來越多。但一個原型圖，如果時間充裕，通常改10遍也不稀奇。可能還是不夠經驗豐富，所以一次性想不了這麼充分。

需求評審，原型和業務邏輯流程給後台開發確認後，開始做設計圖，設計圖要和需求方以及前端開發確認，因為設計圖上的一些東西可能不符合前端開發的標準。比如SEO說，把一段文字設置為h1標籤，但大段文字應該是p標籤，這樣前端同學就會覺得這樣很不科學。PM就是平衡各部門各崗位之間的潤滑劑和溝通的橋樑吧。

4. 與測試人員

測試同學思維很嚴謹，專業找茬人員，(*^__^*) 嘻嘻……。他們很犀利，不僅PM的漏洞，連開發同學的漏洞也經常毫不費力的找出來。很厲害。所以我一般都會虛心聽取測試同學給我的建議。然後完善自己的思維。
推薦閱讀：