基于權益的團隊協作方式思考

　　本文主要說的是，產品設計過程中團隊的分歧是不可避免的，如果控制在范圍內的話是對團隊協作有利的，而基于UCD的理念并由產品經理來推動可以完美的解決這個問題。

　　故事1，我要的是葫蘆

　　小D：小Q，我需要一個沒有籽的葫蘆，能搞定嗎?

　　小Q：葫蘆是可以搞定的，但是，沒有籽的目前無法搞定，不過，搞定是可以的，但是需要很長的時間。

　　小D：都是男人，直接點，我在一周內需要，能不能搞定吧!

　　小Q：這個很復雜，而且目前的工藝還不具備，所以，我實現不了。

　　小D：好吧，我早就聽膩了，我要的是葫蘆而已，你跟說其他的有什么用?

　　故事2，放心大膽的去挑禮物吧

　　小Q：小D，去挑禮物吧，揀你最喜歡的拿，我付錢

　　小D：好啊，我喜歡那個2K的兔子

　　小Q：不行，我只能花20塊，重新去挑吧

　　小D不依不饒又哭又鬧，事情變得無法收場了….

　　故事3，我們種苦瓜吧

　　小M：小D，小D，隔壁種了苦瓜耶，不少人去圍觀了，收效不錯哦，我們也搞顆來玩玩吧

　　小D：呃，苦瓜不適合出現在我們的園子里，而且，來我們園子的家伙們不太適應苦瓜的味道哦

　　小M：為神馬，為神馬?為神馬隔壁搞苦瓜就能火呢?再說了，等我們種了他們自然就能慢慢接受了，說不定能把隔壁的人拉過來呢

　　小D：……

　　故事講完，聰明的你一定也能看出來了，這里小D是個典型的設計師、小Q是典型的工程師、小M是典型的市場運營。是的，就是他們，上面三個故事講的就是他們三個之間的世世代代都無法理清楚的剪不斷的糾葛。

　　在 傳統模式的團隊里，市場運營人員從市場的角度來分析產品概念：誰需要某種產品，誰會購買這個產品，產品講如何被供應和銷售，其成本是多少;設計師根據產品 的賣相(視覺)和人機工程學等方面的知識進行測量，設計師更注重的是某個事物應該是什么樣子而不是它現在是什么樣子;工程師則只會專心的考慮產品技術創新 方面的概念問題，以及開發的技術成本。在這樣的產品研發模式下，各自獨立的專業分工，不可避免的就是出現三個中心。這也是上面三個故事出現的根源。

　　首 先，我們必須承認上述分歧是天然存在的;其次，這種分歧實際上對產品團隊是有利的，當然，這種分歧是必須要控制在工作范圍內的，工作范圍外的分歧必然會危 害整個產品團隊的發展;第三，控制這個分歧的理念應該是“以用戶為中心的設計(UCD)”，而具體執行的家伙應該是產品經理。

　　一般而言，解決團隊的分歧會動用三種手段，分別是：權力、權利、權益。

　　以權力為基準的協商過程，簡單說就是動用等級制度強迫別人做他們不愿意做的事情。其結果必然是產品相互間的矛盾，在協商中輸掉權益的一方在今后的工作中往往會需求反擊的機會，最終損害整個團隊的運轉。

　　以權利為基準的協商手段是運用各種已有的標準、和觀點等來解決紛爭。這里往往會有輸掉沖突的一方，或者必須選擇一種折衷的方案。雖然協商各方的權利在設計過程中都有他的地位和作用，但是這種方法得到的結果往往都是常規的，缺乏新意的。

　　以權益為基準的協商反映了與項目相關的每一個人所關心、期待和需求的事情。我們了解每個人的喜好和工作重點，找到消除障礙的權益措施，從而使所有人所有專業的權益得到兼顧。而更重要的一點在于，用戶的利益也被考慮到其中了!

　　如果我們使用一種以權益做基準的協商手段為主、適當的時候結合權利基準、不得己時小心動用權力的團隊協作方式應該可以得到團隊效率的最大值。

　　所以，在一個團隊里，我們應該鼓勵任何人拿下面的問題去問任何人(注意，是任何人都可以這樣問，特別是產品經理最需要被這樣拷問!)：我們這個產品的核心用戶是誰?我們是在什么情況下，滿足他們的什么需求?這個產品模塊的市場目標是多少?我們面臨多大的技術難度?

　　最后，四個問題的答案必須的是理性的(有數據支撐的)，而不是以“XX這樣說”、“我認為”、“以XX的經驗來看”。正確答案的格式是：“根據我們拿到的數據進行分析…..”、“我們做的用戶訪談說明….”、“根據市場預測并且基于我們產品的成長….”

原文轉自：http://blogread.cn/it/article/2178?f=wb