本文作者作為一個老程序員，從四個方面來談一談什么樣的產品經理是優秀的。
上上周朋友圈被一個程序員和產品經理互噴、互毆，然后被解雇的事情刷屏了，至于發生了什么，其實并不重要，大家哈哈一笑，第二天可能就全忘記了。我看完后，就在想，什么一個產品經理把程序員激怒了？
作為一個老程序員，我是經常慫產品經理的，有的時候都成習慣了，但我也見過很多牛逼的產品經理。
今天談一談什么樣的產品經理是優秀的（至少是我認為的），這篇文章也是心血來潮，帶有很多的個人情緒，說的也不全面，很多都是泛泛而談。從四方面簡單談一談，如果將來有機會，再做進一步細化闡述。
一、專業性
任何一個崗位都有其專業性，一個產品經理即使溝通能力不佳，協調能力不強，但只要專業能力足夠擅長，也會受到程序員的尊重。那專業性體現在哪兒呢？
一個需求不管多小，也應該有完整的產品需求文檔（PRD），代表產品經理的嚴謹性，以及對這個需求的深刻理解（即使需求錯誤也是可理解的）。產品需求文檔形式不一定需要標準的形式（畢竟不是論文），如果需求文檔格式很完整，但空空無物又有什么用呢？
需求文檔可以有自己的個人風格，只要足夠嚴謹，能讓程序員看懂即可。
具備原型圖設計能力，對于程序員來說，很難有耐心仔細看需求文檔，他們更喜歡“動態”的原型圖；對于產品經理來說，為了理順自己的思路，思考需求的合理性，最好的校驗工具就是畫原型圖。
所以不管從哪個角度來看，產品經理應該學會一種原型圖設計軟件，比如：Axure。原型圖是對產品需求文檔的一個有效補充，從不同維度完善項目需求，極具立體性。
邏輯性，這是非常關鍵的一個能力，產品經理將用戶的需求轉變為產品需求，文檔最重要的就是邏輯正確，經常和一些產品經理開會，發現他們自己都無法將需求理順、也無法說服自己、無法應對質疑，即邏輯性存在很大的問題。
如果一個產品經理存在邏輯性較差的問題，那就要好好修煉內功了，如果無法洞悉用戶的真正需求，會給公司產品帶來萬劫不復的災難，但也從另外一方面體現了產品經理的重要性。
UI 審美能力，我發現很多優秀的產品經理都會畫畫，他們也會 UI 設計，即具備很強的審美能力，知道頁面風格的重要性，或者說這些產品經理的聯想、發散能力是極強的，這也是他們專業能力的體現。而對于程序員來說，這方面可能就是白癡，他們只關心邏輯思考能力，反向說明產品經理是要求非常高的一個崗位。
產品經理在大家看來是一個萬花筒，溝通能力、協調能力非常重要，為什么沒有提及？
其實任何一個行業，任何一個崗位這些能力是必須的，沒有必要強調。這篇文章完全以我的視角解讀優秀產品經理的判斷標準，極具個人色彩，可能存在極大的偏向性。
二、熟知開發流程
產品經理的專業性不可能一步到位，需要慢慢積累才能成長，但對于一個剛入門的產品經理來說，理解項目流程非常重要，否則就像蒼蠅一樣，不知道要干啥好，到處碰壁，四處吃虧，變成程序員眼中的一個傻子。
了解各個崗位的職責，在互聯網公司，分工是非常細化的（尤其是開發人員），一個具有一定規模的公司，有系統開發人員、應用開發人員、前端開發人員、客戶端開發人員、數據分析人員、系統運維人員、應用運維人員。
而且這些崗位人員之間的職責還可能交叉，如果產品經理不了解這些崗位的區別，出現問題或者提需求找不到正確的人，那就非常麻煩了，會極大減少積極性，也會讓人疲憊不堪。所以產品經理平時要多留心，找到解決問題的合適人員。
測試的重要性，在大公司有專門的測試崗位，但不代表產品經理能夠忽視它（很多產品覺得自己怎么成為測試人員了，這也是他們的吐槽點之一，覺得沒有時間干自己的專業了），此處我要強調冒煙測試的重要性，很多開發人員由于多方面的原因，匆匆忙忙完成某個項目，然后將其部署。符合預期嗎？
冒煙測試是校驗預期最好的手段，對于產品經理來說，自己進行冒煙測試，也能以用戶的角度體驗產品功能，進一步思考合理性。所以說產品經理一定要明白測試的重要性，也要熟知測試的流程。
郵件確認機制，很多產品經理和開發人員平時好的就像親兄弟、 親姐妹一樣，項目進度不出問題的時候還好，出現問題的時候就非常尷尬了，產品經理是第一責任人了，也就是說一個項目從構思到上線，甚至到跟蹤。
產品經理必須全程關注，盡力確保項目上線，其中郵件確認機制就是非常重要的一個點，在關鍵節點一定要發郵件周知相關人員，一方面是匯報進度，另外一方面也給程序員提一個醒。
對于非功能需求的把握，非功能需求包括性能、擴展性、可用性等技術指標，雖然這些更應該由程序員關心，但產品經理一定要明白此中的道道，它也是產品開發過程中非常重要的一環，產品經理有必要有義務提醒程序員。
JIRA跟蹤機制，產品或功能上線后，產品經理要及時獲取用戶的反饋，包括用戶遇到的問題、建議，可以通過 JIRA 長期跟蹤，要協助程序員一起分析問題，這樣才是一個善始善終的優秀產品經理。
三、不要讓程序員討厭你
對于產品經理來說，讓程序員尊敬你非常重要，那么如何做到呢？
一方面是提升自己的專業能力，另外一方面就是少做龜毛的事情。尤其程序員的性格非常直接，惹惱他們后果很嚴重，所以某些細節一定要留意，至少對我來說，下面的十個情況要盡量避免。
（1）不要用嘴代替需求
有些產品經理腦子里冒出個想法，一拍腦門覺得自己就是個天才啊，趕緊讓程序員去開發吧，就吧啦吧啦跑到程序員面前，說你開發這個功能吧，接著又語無倫次的描述了所謂的需求。
可這些需求你論證過嗎？用戶需要嗎？流程能跑通嗎？自己都不一定明白，還期待程序員能夠聽懂？
這是一種非常不負責任的行為，久而久之會讓程序員非常反感，所以一定要切記。
（2）程序員的監工
有些產品經理好像保姆一樣，就怕程序員不主動，怕工期來不及，每天趴在程序員后面，盯著他們開發代碼，好像監工一樣。這種行為讓程序員特別不自在，他們有自己的工作方式，不寫代碼不代表不在工作，他們大腦在后臺飛快的思考著，當然要是一個美女產品經理跟在后面就另當別論了。
另外有些產品經理喜歡陪程序員加班，我覺得這種形式也非常不好，只要把需求提清楚了，沒有必要好像虧欠什么的，不一定要用陪同這種形式來支持程序員。
（3）2/8 法則不可違
有些產品經理要求特別嚴謹，但程序員也有難處，比如：某個功能暫時確實不好實現，問產品經理能不能變通一下，將需求弄簡單一點。傻逼的產品經理可能就較真了，說不行，一定要按需求做，此時矛盾就無形中產生了，實際上正確的做法就是問自己：我核心的功能完成了嗎？舍棄的功能影響全局嗎？
如果不大，確實可以尊重程序員的意見，將 20% 的核心時間花在重要的事情上，等后續有時間了再完善，這種做法是毫無問題的。產品經理要有極強的辨識能力，明白一個項目的核心功能是什么，不要太拘泥小節。
（4）討論變成需求
經常遇到這樣的場景，產品經理出了一個需求文檔，然后大家開會討論，開會過程中產品經理的想法被無情的批判，自己也毫無主見了，然后大家互相出主意，程序員也很開心，產品經理也很滿意，因為開會討論出了需求，程序員不會龜毛到反駁自己提出的意見吧，在某種程度上這是一種好現象，實際上我不提倡這種方式。
無情的被人反駁，只能證明產品經理思考不成熟，是自己專業能力不強的一種體現，作為需求方，需要捍衛你的想法，如果輕易被撼動，只能證明自己還要加強學習，說的難聽一點，只要能說服自己，有的時候要堅持自己的想法和需求（和固執是兩碼事）。
（5）你不是開發人員
有些產品經理比程序員還程序員，動不動就幫技術人員想解決方案，說這個應該這么弄，設計方案會不會有性能問題啊，時時刻刻顯示自己的邏輯能力。
俗話說術業有專攻，我希望產品經理不要從程序員的角度去思考問題，而是以用戶的角度去思考問題，提出需求，實現是程序員的事情。如果程序員覺得實現有問題和麻煩，必然會找你，如果你能聽懂、且贊同，那么程序員會覺得你是在幫助他，這才是正確的做法。
在我漫長的職業生涯中，我遇到很多懂行的產品經理，他們邏輯能力比我強多了，但從不喧賓奪主，只在我為難的時候提出一些建議，讓我受益匪淺。反而是一些毛都不懂的產品經理，天天給我秀智商。
（6）需求是否合理
本文開頭說的那個故事，就是需求不合理導致的，產品經理一定要注意這一點，不要站在自己角度出發的，而是站在用戶角度，需求不能想當然，多想想功能是用戶需要的嗎？千萬不要做無用功，不要亂提需求。
有的時候我總有這種感覺，啥也不做比瞎做至少還能節省人力，不浪費公司資源。產品經理也不要動不動就說這是領導要的功能，和我無關。其實應該這么想問題：領導可能有一個想法，其中也許 80% 不可取的，而產品經理要做的就是將 20% 可取的部分強化，以此提出一個合理的需求。
（7）什么時候完成
有的時候產品經理剛把需求發給程序員，或者開會剛討論結束，就迫不及待問啥時候能開發完成，領導急著呢。
有的時候還會抱怨這么小的一個改動就要2天？或者說這個開發很簡單吧？
這是一些非常不職業的做法，軟件開發有其自身的規律，需要設計、架構、編碼、測試、部署等多個過程，是要求非常高的一個過程，所以千萬不要一上來就要開發時間，很容易讓人反感。
更好的做法就是問他們什么時候能評估出開發工作量（包括分析、設計），然后在郵件中周知，為避免程序員遺忘，可以提前詢問一下。如果和某個程序員熟悉了，了解他的風格，可以采取一些策略來推動項目，切記不要動不動就問什么時候完成開發。
（8）我只管提需求
這一句話的下半句其實就是“其他我不負責”，在互聯網企業，產品經理其實包含項目經理的角色，對于一個高速發展的企業來說，不可能按部就班的工作。而推進器其實就是產品經理，他們需要把握整個項目進度，不要認為僅僅提需求就行了。
代碼是開發人員開發，推廣也是運營的事情，產品經理本質上就是指哪兒打哪兒，和設計人員溝通、接受運營人員的需求、給銷售人員數據、給程序員提需求、給測試人員寫測試用例、給用戶解答。
（9）找領導
有些產品經理是急性子，一看程序員不配合，或者進度趕不上，就說找技術總監，好像找了就能解決問題，有的時候也有點欺負人的感覺。可實際上最終配合你的還是這些程序員，這和接下去要講的人治非常類似。
我建議產品經理少拿這個殺手锏，有的時候它還不一定管用，和程序員應該永遠報以合作的態度，合作不順的時候，可以和程序員交交心，互相交流下想法，這樣才有可能解決問題。
（10）缺乏反饋機制
一個產品功能上線后，如果反響比較好，產品經理當然覺得都是他們的功勞，這也無可厚非，可如果不好呢？
產品經理應該分析問題，思考是否需要優化它，也可以和程序員一些討論，共同想辦法。但大部分產品經理卻毫不關心，好像根本就沒有這功能一樣，這種做法非常讓程序員寒心，程序員就會覺得你們也既不不開發代碼，也不關心項目的結果，長此以往，這樣的產品經理會失去程序員的信任。
四、人治而非法治
任何一個行業，人與人之間的關系是必不可少的，對于程序員和產品經理來說，他們之間的溝通是最多的，也是關系最密切的人，相處融洽才能將工作做好。
關于如何相處是一門藝術，可以看專門的一些數據，我從自己的角度出發，簡單列幾點。
（1）理解程序員
程序員是非常獨特的一類人群，性格可能和常人不一樣，但都非常感性，有的時候也會口無遮攔，甚至熟悉后還和你發脾氣。但大部分情況下，他們都非常純真，沒有太多的心機。
對于產品經理來說，面對程序員的各種莫名其妙的表現，一笑而過，大度一點，多想想他們的優點，盡力成為朋友，這是將工作做好的先決條件。
當一個產品經理進入新公司后，一定要仔細觀察各個程序員的性格、特點，針對性下藥，有策略的和他們融入在一起，但需要注意的是，不是讓產品經理忍讓他們，這也不是好策略，只是要盡量避免針鋒相對。
（2）認同程序員
程序員不僅僅是開發代碼，他們邏輯性強，思考問題全面，作為產品經理，要善于合作，尊重他們的觀點，多聽聽他們的意見，千萬不能說“這是需求，趕緊實現吧，其他的不用問”這樣的話。
而是讓程序員發表意見，比如說：“你覺得怎么樣設計比較好一點”、“幫我看看邏輯是不是正確”，讓程序員間接成為一個產品經理，讓程序員意識到他們的重要性，意識到他們是設計者，而非僅僅是構建者。
當一個項目結束后，要多向他們反饋，反饋包括用戶的反饋，也包括產品經理的自我批評。當項目結果不是很好的時候，也要及時和程序員反饋，反思失敗的原因，這樣才能讓程序員意識到“這個項目的背景原來這么復雜啊”。他們也會從內心接收這一切，如果總是沒有反饋，程序員會說“產品經理又做了一堆垃圾”。
（3）目標一致性
面對一個項目，真正推動項目的動力不是產品經理的催促，而是讓程序員和產品經理目標達成一致，對于核心項目來說，他們一致目標就是“這項工程關系到公司的生死存亡，所以必須加油”。
那一般性的項目呢？
即使不重要，產品經理也要有極大的感染力，讓程序員意識到“我在做一件有價值的事情”，只有雙方目標是一致的，項目才能飛快往前走。
目標一致性來源于程序員對產品經理的感受，如果你足夠職業，足夠專業，是很容易感染程序員的。
（4）有自己的人格魅力
通俗的說，就是讓程序員信服你，人格魅力不僅僅體現在工作上，也包括你平時的言行、你的做事方式、你的性格、你的價值觀，只要其中有一件事情讓程序員從內心深處佩服你，那么他會極力的配合好你。
向那些專業的產品同事致敬！！
本文為@運營喵原創，運營喵專欄作者。
