來人人都是産品經理【起點學院】，BAT實戰派産品總監手把手系統帶你學産品、學運營。

“擦！又來一個需求？不是上個月剛提了XX需求，讓往西嗎？怎麼今天又讓往東了？”

是不是老感覺被業務代表牽着鼻子走？産品經理的工作難道就是去實現業務方提的需求？很多産品汪都會遇到這個問題，不知道如何拿捏和業務方的關系，太聽話會被牽着走，太叛逆又會被責怪不了解業務需求。

關于産品和業務方的關系如何拿捏這個話題，讓我們分兩個部分來解答：

一、 業務方和産品經理的職責範圍

業務方：

1. 當然最重要的還是提需求啦~ 但是僅僅隻是需求，不是指使你設計什麼功能，按鈕怎麼擺放，不然就會淪為僞需求。
2. 提供業務場景，闡述現有業務流程，對産品提出的新的業務流程進行确認。這一點，在我看來是一個合格的業務方需要做的最重要的事情。不要瞎BB，有效利用起産品提供的服務，保證業務流程的暢通，這才是業務方的主業。獲取需求的神書《掌握需求過程》裡說，“業務範圍大于産品範圍”說的就是這個意思，在一個完整的業務流程中，産品不可能完全cover所以業務場景，所以業務方和産品在立場和認識上肯定存在差異，但是雙方需要站在對方立場考慮。
3. 産品上線前驗證。當然，這個動作，也是可以由産品來完成的。如果這個産品是為了滿足一個新的業務流程裡的新需求，這個驗證的動作可以由業務代表來完成。

産品經理：

1. 梳理業務需求。思考業務方提出的需求背後的含義，也許他說想要建一座橋，但其實他隻是想和河對岸的人說一句話，那這樣解決方案就不止建橋這一種了嘛。
2. 需求優先級排序。需求很多，很零散，怎麼組織他們，找到彼此之間的關系，排序，确保你所做的事情是當下最緊急且最重要的事。
3. 産品規劃，确定産品邊界。在前面提到，業務邊界大于産品邊界，因此，産品經理在設計産品的時候，需要考慮有限的開發時間，能搭起多少塊磚？需要如何演進優化，建成一棟樓？
4. 産品設計，這裡包括了很多，包括界面交互設計，抽象業務實體設計，數據庫表設計(新系統)，功能擴展的考慮，信息架構設計(包括導航，頁面層級，搜索)，太多了，媽蛋，才發現産品經理需要做這麼多事。
5. 産品推廣。類似于公關的角色，這時候顔值高可能會發揮點小作用，哈哈。
6. 應付上下遊系統的産品。一方面，你出去找接口的時候，就是出去化緣嘛，想辦法應付下嘛，高度拔高，讓人家不得不把家裡的饅頭拿給你。另一方面，其他人找你拿接口或者改字段的時候，你就随機應變吧，太不靠譜的事，從系統定位，項目邊界這些角度忽悠吧。

P.S. 産品經理和業務方不是對立面，兩者的工作職責不同，卻有交集，不能任何一方處于絕對強勢的地位，否則設計出來的産品就會過于偏激，要麼就是過于簡單的滿足目前業務需求，要麼就是脫離業務變成了空中樓閣，設計的再好也沒有業務價值。

二、 業務邊界和産品邊界

前面說的業務需求和産品設計不一定長一個樣，業務方不應該牽着産品的鼻子，讓他做一個四不像出來。舉個例子，前端時間遇到的，涉及到公司業務，這裡的一些細節就不方便細說了哈。

是這樣的，業務方提出要在系統上加一個模闆，因為政府新出的政策，要求供應商按照新的模闆提供材料。但是這個材料供應商之前已經提供過了的！難道還要他們再提交一遍？顯然這并不是一個産品的total solution。

首先，政府政策經常變，難道每次變，我都要改一次嗎？能不能做一個後台配置功能，一旦有新的政策，隻需要人在後台添加就好了。

其次，供應商需要配合做這麼無效率的事情嗎？第一次提交的材料完全不能用了嗎？能不能利用供應商第一次提交的那些字段，根據後台設置的規則，自動抽取需要的字段，這樣就可以滿足新政策的需求了。

再次，後台的規則，誰來負責配置？一般來說，産品是不負責數據的維護的，那能否提供一個入口，給相關的業務方權限來維護，底層數據服務可以放在我們系統。

以上，是我們的産品思路，對比一下，和業務需求差别還挺大吧。這也是一個産品的價值。

本文由 @舊無痕授權發布于人人都是産品經理 ，未經許可，禁止轉載。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部