我心目中的優秀產品經理
掃描關注公眾號（yudadanwx，虞大膽的嘰嘰喳喳），了解我的最新文章。
上上周朋友圈被一個程序員和產品經理互噴、互毆，然後被解僱的事情刷屏了，至於發生了什麼，其實並不重要，大家哈哈一笑，第二天可能就全忘記了。我看完後，就在想，什麼一個產品經理把程序員激怒了？
作為一個老程序員，我是經常慫產品經理的，有的時候都成習慣了，但我也見過很多牛逼的產品經理，今天談一談什麼樣的產品經理是優秀的（至少是我認為的），這篇文章也是心血來潮，帶有很多的個人情緒，說的也不全面，很多都是泛泛而談。從四方面簡單談一談，如果將來有機會，再做進一步細化闡述。
專業性
任何一個崗位都有其專業性，一個產品經理即使溝通能力不佳，協調能力不強，但只要專業能力足夠擅長，也會受到程序員的尊重。那專業性體現在哪兒呢？
一個需求不管多小，也應該有完整的產品需求文檔（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）有自己的人格魅力
通俗的說，就是讓程序員信服你，人格魅力不僅僅體現在工作上，也包括你平時的言行、你的做事方式、你的性格、你的價值觀，只要其中有一件事情讓程序員從內心深處佩服你，那麼他會極力的配合好你。
向那些專業的產品同事致敬！！
TAG:虞大膽的嘰嘰喳喳 |