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