也許，你可以購置這個「盾牌」？
搜索關鍵詞：刺蝟包
但是，以暴制暴是不對的朋友，畢竟就算打贏了也是真的疼啊。
想要當一個不被打的產品經理真的挺容易的。
首先，你可以提升你的專業度。方法不要太多，比如：產品經理需要懂技術嗎？懂到什麼程度？。說什麼沒渠道沒方法瞭解的都是活該被打（大誤）。
其次，你需要有一顆同理心。比如臨近下班給程序員小哥說需要實現一個功能，然後你就開開心心和朋友胡吃海喝去了。你就算真的長成國民老婆新垣結衣的樣子，也很難被原諒吧？這個時候，EQ 一定不要下線，幫開發小夥伴拿點零食充充飢也是極好的。
最後，你需要了解到你和開發小哥其實是一條船上的小夥伴，如果你能跟他講清楚業務的輕重緩急，提出合理的需求，其實程序員也會願意為了共同的目標而努力的。
從業這些年，還沒有被打過，挺遺憾的 :)
產品這個崗位，混合了很多角色的成分，決策者、檢驗者、管理者。如何避免被打，我這裡有幾條切實可行的建議。
首先，作為一個產品，你應該比其他人更瞭解一切。
最近團隊在做 Google Eddystone EID，我閱讀了相關的所有 API 和 Paper，站在設計者的角度搞清楚協議的設計機制，確保團隊每一個對於協議的認知都是一致的，然後跟工程師一起設計了項目的實現邏輯以及驗證方式。
團隊在做一件事，如果沒人能從全局的角度做決策，是一件很可怕的事情，所以產品在這裡要儘可能瞭解一切。但你不一定要成為那個決策者，其實，很多時候你會發現業務太過複雜，已經超過了你的能力範圍。我們要做的是找出那個最適合做全局決策的人，然後把你知道的一切傳遞給他，確保他了解一切。但信息傳遞是有成本和損失的，這裡面需要做一個權衡。
其次，不要做一個獨裁者。
產品，往往是最後的決策者。前面提到儘可能地瞭解一切，是為了避免當團隊遇到問題時來找你，你卻不知所措。你有很強的決策能力，但是要警惕成為一個獨裁者。廣泛聽取團隊中的各種看法，權衡利弊，選出最適合做決策的人，讓團隊最後可以拿出共識的方案。
然後，親自做檢驗者。
作為產品，你可能是產品質量的最後一道防線，所以一定要自己動手去做測試。信息的傳遞，不可避免地會產生偏差，從你這起也從你這收，才能所做的是對的，當然這需要你深度地瞭解業務。
接下來，做好向上向下管理。
管理需求，是很重要的一項職責。無聊是客戶還是老闆，需求總是無盡的，時間總是越快越好的。向上管理，就是要管理好他們的預期，屏蔽掉對團隊的負面的影響。向下管理，最好的方式就是沒有"管理"。
然後，項目進度上要鬆弛有度。
我一直提倡，以80％的精力去做事情。因為現實情況往往比預計地要糟糕，長時間滿負荷工作會韌性消失，土崩瓦解。其實從目前的運轉情況來看，即使準備做鬆弛有度的安排，最後其實也是忙的不可開交。-_-#
最後，偷句名言。
「讓正確的事情相繼發生」，其實這點很難，產品經理自身所在的角度很重要。把功能做好，把項目做好，還是把公司做好，學會隨時把自己切換到合適的角度。
末尾再做一個小分享。
團隊中可以沒有產品，但是不能沒有產品這個角色。
當事情多到你無法處理的地步時，找到一個可以替代一部分你的人，才是你的唯一出路。
難不成要這樣提需求？
當產品經理當到至於要被打，是一件很弔詭的事，你是亂答應廠商要求，亂跟老闆開預算，還是跟工程師們胡說八道了呢？
重新認清一下，產品經這份工作到底是什麼？我說當產品經理就是協助你的團隊做出對的產品。
很多人將產品經理形容成產品規格的訂定者、團隊的領導者，但那實在太誇張了，我想更像是產品的協調者，要做的概括就是兩件事：A.協調老闆、廠商和所處的團隊；B.確保專案週期的時間和質量。
我知道協調、溝通有一點天份，不會說好聽的話起碼學著把事情講清楚，相信看錶達專門用書、關於表達的討論，可以給你更好的參考，我就不廢話了，這邊只給你最基本的原則：
一，專案開始時：
- 跟工程師、設計師討論該怎麼做，確保項目不會浪費時間在已經有的替代方案上重做輪子。
- 確認死線，以及最少該完成什麼。
- 讓工程師參與工作分配的討論，同等級的工程師專長也是有差異的。
- 完成工作分配和時程規劃時，請教資深前輩 是否過於理想化。
二，專案進行中：
- 儘可能瞭解團隊中的專業。不論是設計師出生，資工、計算機科學本科出生，甚至是商科來的，請儘可能去了解團隊中其他人的專業，這能幫助你更好的估算時間，以及避免去承諾上司或廠商一些異想天開的想法。
- 像成員提問。在閱讀技術文件後找不到答案時（請確定有找過），像團員請教，請教並不可恥，也不是在浪費其他人時間，錯誤認知下的指揮更為恐怖。
- 把 task 跟 issue 分開來。別邊做邊修、一次想完成所有事情只是把一切搞混、浪費大家時間。。
- 不要輕易的承諾。PM 會面臨很多的反饋，團隊的、老闆的、使用者的，更為恐怖的廠商的，但請挺起胸膛有擔當的頂住壓力（女生挺起更有效），不要隨便受影響變更設計。
- 拍板決定、改變一個功能之前，請先讓團隊有參與討論的空間。終於走到這一步了，被強行塞了一個工作，千萬要知道你不是在線的工程師（哪怕是資深工程師轉過來）不會比正在做的人，更清楚需要花多少時間，不是設計師，也很難全方位理解設計語言。所以在改變前請至少跟成員一起討論兩次，相信我，肯定會對你有幫助的。
- 項目時程內報表、成果展現自己做。Excel 很方便，老闆很喜歡看圖，我跟你一樣在開會時上臺表演有快感，但記著別對成員搞什麼每日工作報告、團隊中也沒人對什麼敏捷法、要徑法、Scrum 之類有什麼鬼興趣，自己上臺怎麼帥怎麼來，但別拿這為難自己團隊成員，鬼才知道一個功能 coding 到一半是 75％ 還是 85％？
- 先護住自己的團隊成員。要資源、與其他團隊拉扯時，只要有爭議，永遠站在自己團隊這邊，看起來有點不分是非，但保證來一次信任感直線上升，公司內也是有口碑的。至於真的因果、對錯、效率，我們等檢討報告再來。
三，專案完成後：
- 別把功勞都當自己的，永遠先把團隊成員推上去，上臺表演的是 PM 你，大家都記得住，不用擔心會沒有功勞。
- 將產品做總結，包括了「這麼做的理由」、「資源運用」、「最後怎麼 WORK」、「帶來的影響」，美化一倍送上去。
- 把項目遇到的困境、相處習慣記下來，方便下次執行類似項目時參考，有好的團隊成員也可以優先跟上司要求。
- 為團隊和產品感到驕傲。
尊重設計師、工程師，團隊中所有成員。PM不是任何人的上司，大家工作都只是想做出心目中最好的東西，沒有人需要去承受其他人的壓力與情緒。除了個別情況，大家都只是為了完成心目中那項最屌的產品，工作累的半死也只是想有口飯吃，你好好待人家，別人哪來那麼多時間會去針對你。
閱讀更多 西部遊星 的文章
