本文作者作為一個老程序員，從四個方面來談一談什么樣的產(chǎn)品經(jīng)理是優(yōu)秀的。

上上周朋友圈被一個程序員和產(chǎn)品經(jīng)理互噴、互毆，然后被解雇的事情刷屏了，至于發(fā)生了什么，其實并不重要，大家哈哈一笑，第二天可能就全忘記了。我看完后，就在想，什么一個產(chǎn)品經(jīng)理把程序員激怒了？

作為一個老程序員，我是經(jīng)常慫產(chǎn)品經(jīng)理的，有的時候都成習(xí)慣了，但我也見過很多牛逼的產(chǎn)品經(jīng)理。

今天談一談什么樣的產(chǎn)品經(jīng)理是優(yōu)秀的（至少是我認(rèn)為的），這篇文章也是心血來潮，帶有很多的個人情緒，說的也不全面，很多都是泛泛而談。從四方面簡單談一談，如果將來有機會，再做進一步細化闡述。

一、專業(yè)性

任何一個崗位都有其專業(yè)性，一個產(chǎn)品經(jīng)理即使溝通能力不佳，協(xié)調(diào)能力不強，但只要專業(yè)能力足夠擅長，也會受到程序員的尊重。那專業(yè)性體現(xiàn)在哪兒呢？

一個需求不管多小，也應(yīng)該有完整的產(chǎn)品需求文檔（PRD），代表產(chǎn)品經(jīng)理的嚴(yán)謹(jǐn)性，以及對這個需求的深刻理解（即使需求錯誤也是可理解的）。產(chǎn)品需求文檔形式不一定需要標(biāo)準(zhǔn)的形式（畢竟不是論文），如果需求文檔格式很完整，但空空無物又有什么用呢？

需求文檔可以有自己的個人風(fēng)格，只要足夠嚴(yán)謹(jǐn)，能讓程序員看懂即可。

具備原型圖設(shè)計能力，對于程序員來說，很難有耐心仔細看需求文檔，他們更喜歡“動態(tài)”的原型圖；對于產(chǎn)品經(jīng)理來說，為了理順自己的思路，思考需求的合理性，最好的校驗工具就是畫原型圖。

所以不管從哪個角度來看，產(chǎn)品經(jīng)理應(yīng)該學(xué)會一種原型圖設(shè)計軟件，比如：Axure。原型圖是對產(chǎn)品需求文檔的一個有效補充，從不同維度完善項目需求，極具立體性。

邏輯性，這是非常關(guān)鍵的一個能力，產(chǎn)品經(jīng)理將用戶的需求轉(zhuǎn)變?yōu)楫a(chǎn)品需求，文檔最重要的就是邏輯正確，經(jīng)常和一些產(chǎn)品經(jīng)理開會，發(fā)現(xiàn)他們自己都無法將需求理順、也無法說服自己、無法應(yīng)對質(zhì)疑，即邏輯性存在很大的問題。

如果一個產(chǎn)品經(jīng)理存在邏輯性較差的問題，那就要好好修煉內(nèi)功了，如果無法洞悉用戶的真正需求，會給公司產(chǎn)品帶來萬劫不復(fù)的災(zāi)難，但也從另外一方面體現(xiàn)了產(chǎn)品經(jīng)理的重要性。

UI 審美能力，我發(fā)現(xiàn)很多優(yōu)秀的產(chǎn)品經(jīng)理都會畫畫，他們也會 UI 設(shè)計，即具備很強的審美能力，知道頁面風(fēng)格的重要性，或者說這些產(chǎn)品經(jīng)理的聯(lián)想、發(fā)散能力是極強的，這也是他們專業(yè)能力的體現(xiàn)。而對于程序員來說，這方面可能就是白癡，他們只關(guān)心邏輯思考能力，反向說明產(chǎn)品經(jīng)理是要求非常高的一個崗位。

產(chǎn)品經(jīng)理在大家看來是一個萬花筒，溝通能力、協(xié)調(diào)能力非常重要，為什么沒有提及？

其實任何一個行業(yè)，任何一個崗位這些能力是必須的，沒有必要強調(diào)。這篇文章完全以我的視角解讀優(yōu)秀產(chǎn)品經(jīng)理的判斷標(biāo)準(zhǔn)，極具個人色彩，可能存在極大的偏向性。

二、熟知開發(fā)流程

產(chǎn)品經(jīng)理的專業(yè)性不可能一步到位，需要慢慢積累才能成長，但對于一個剛?cè)腴T的產(chǎn)品經(jīng)理來說，理解項目流程非常重要，否則就像蒼蠅一樣，不知道要干啥好，到處碰壁，四處吃虧，變成程序員眼中的一個傻子。

了解各個崗位的職責(zé)，在互聯(lián)網(wǎng)公司，分工是非常細化的（尤其是開發(fā)人員），一個具有一定規(guī)模的公司，有系統(tǒng)開發(fā)人員、應(yīng)用開發(fā)人員、前端開發(fā)人員、客戶端開發(fā)人員、數(shù)據(jù)分析人員、系統(tǒng)運維人員、應(yīng)用運維人員。

而且這些崗位人員之間的職責(zé)還可能交叉，如果產(chǎn)品經(jīng)理不了解這些崗位的區(qū)別，出現(xiàn)問題或者提需求找不到正確的人，那就非常麻煩了，會極大減少積極性，也會讓人疲憊不堪。所以產(chǎn)品經(jīng)理平時要多留心，找到解決問題的合適人員。

測試的重要性，在大公司有專門的測試崗位，但不代表產(chǎn)品經(jīng)理能夠忽視它（很多產(chǎn)品覺得自己怎么成為測試人員了，這也是他們的吐槽點之一，覺得沒有時間干自己的專業(yè)了），此處我要強調(diào)冒煙測試的重要性，很多開發(fā)人員由于多方面的原因，匆匆忙忙完成某個項目，然后將其部署。符合預(yù)期嗎？

冒煙測試是校驗預(yù)期最好的手段，對于產(chǎn)品經(jīng)理來說，自己進行冒煙測試，也能以用戶的角度體驗產(chǎn)品功能，進一步思考合理性。所以說產(chǎn)品經(jīng)理一定要明白測試的重要性，也要熟知測試的流程。

郵件確認(rèn)機制，很多產(chǎn)品經(jīng)理和開發(fā)人員平時好的就像親兄弟、 親姐妹一樣，項目進度不出問題的時候還好，出現(xiàn)問題的時候就非常尷尬了，產(chǎn)品經(jīng)理是第一責(zé)任人了，也就是說一個項目從構(gòu)思到上線，甚至到跟蹤。

產(chǎn)品經(jīng)理必須全程關(guān)注，盡力確保項目上線，其中郵件確認(rèn)機制就是非常重要的一個點，在關(guān)鍵節(jié)點一定要發(fā)郵件周知相關(guān)人員，一方面是匯報進度，另外一方面也給程序員提一個醒。

對于非功能需求的把握，非功能需求包括性能、擴展性、可用性等技術(shù)指標(biāo)，雖然這些更應(yīng)該由程序員關(guān)心，但產(chǎn)品經(jīng)理一定要明白此中的道道，它也是產(chǎn)品開發(fā)過程中非常重要的一環(huán)，產(chǎn)品經(jīng)理有必要有義務(wù)提醒程序員。

JIRA跟蹤機制，產(chǎn)品或功能上線后，產(chǎn)品經(jīng)理要及時獲取用戶的反饋，包括用戶遇到的問題、建議，可以通過 JIRA 長期跟蹤，要協(xié)助程序員一起分析問題，這樣才是一個善始善終的優(yōu)秀產(chǎn)品經(jīng)理。

三、不要讓程序員討厭你

對于產(chǎn)品經(jīng)理來說，讓程序員尊敬你非常重要，那么如何做到呢？

一方面是提升自己的專業(yè)能力，另外一方面就是少做龜毛的事情。尤其程序員的性格非常直接，惹惱他們后果很嚴(yán)重，所以某些細節(jié)一定要留意，至少對我來說，下面的十個情況要盡量避免。

（1）不要用嘴代替需求

有些產(chǎn)品經(jīng)理腦子里冒出個想法，一拍腦門覺得自己就是個天才啊，趕緊讓程序員去開發(fā)吧，就吧啦吧啦跑到程序員面前，說你開發(fā)這個功能吧，接著又語無倫次的描述了所謂的需求。

可這些需求你論證過嗎？用戶需要嗎？流程能跑通嗎？自己都不一定明白，還期待程序員能夠聽懂？

這是一種非常不負責(zé)任的行為，久而久之會讓程序員非常反感，所以一定要切記。

（2）程序員的監(jiān)工

有些產(chǎn)品經(jīng)理好像保姆一樣，就怕程序員不主動，怕工期來不及，每天趴在程序員后面，盯著他們開發(fā)代碼，好像監(jiān)工一樣。這種行為讓程序員特別不自在，他們有自己的工作方式，不寫代碼不代表不在工作，他們大腦在后臺飛快的思考著，當(dāng)然要是一個美女產(chǎn)品經(jīng)理跟在后面就另當(dāng)別論了。

另外有些產(chǎn)品經(jīng)理喜歡陪程序員加班，我覺得這種形式也非常不好，只要把需求提清楚了，沒有必要好像虧欠什么的，不一定要用陪同這種形式來支持程序員。

（3）2/8 法則不可違

有些產(chǎn)品經(jīng)理要求特別嚴(yán)謹(jǐn)，但程序員也有難處，比如：某個功能暫時確實不好實現(xiàn)，問產(chǎn)品經(jīng)理能不能變通一下，將需求弄簡單一點。傻逼的產(chǎn)品經(jīng)理可能就較真了，說不行，一定要按需求做，此時矛盾就無形中產(chǎn)生了，實際上正確的做法就是問自己：我核心的功能完成了嗎？舍棄的功能影響全局嗎？

如果不大，確實可以尊重程序員的意見，將 20% 的核心時間花在重要的事情上，等后續(xù)有時間了再完善，這種做法是毫無問題的。產(chǎn)品經(jīng)理要有極強的辨識能力，明白一個項目的核心功能是什么，不要太拘泥小節(jié)。

（4）討論變成需求

經(jīng)常遇到這樣的場景，產(chǎn)品經(jīng)理出了一個需求文檔，然后大家開會討論，開會過程中產(chǎn)品經(jīng)理的想法被無情的批判，自己也毫無主見了，然后大家互相出主意，程序員也很開心，產(chǎn)品經(jīng)理也很滿意，因為開會討論出了需求，程序員不會龜毛到反駁自己提出的意見吧，在某種程度上這是一種好現(xiàn)象，實際上我不提倡這種方式。

無情的被人反駁，只能證明產(chǎn)品經(jīng)理思考不成熟，是自己專業(yè)能力不強的一種體現(xiàn)，作為需求方，需要捍衛(wèi)你的想法，如果輕易被撼動，只能證明自己還要加強學(xué)習(xí)，說的難聽一點，只要能說服自己，有的時候要堅持自己的想法和需求（和固執(zhí)是兩碼事）。

（5）你不是開發(fā)人員

有些產(chǎn)品經(jīng)理比程序員還程序員，動不動就幫技術(shù)人員想解決方案，說這個應(yīng)該這么弄，設(shè)計方案會不會有性能問題啊，時時刻刻顯示自己的邏輯能力。

俗話說術(shù)業(yè)有專攻，我希望產(chǎn)品經(jīng)理不要從程序員的角度去思考問題，而是以用戶的角度去思考問題，提出需求，實現(xiàn)是程序員的事情。如果程序員覺得實現(xiàn)有問題和麻煩，必然會找你，如果你能聽懂、且贊同，那么程序員會覺得你是在幫助他，這才是正確的做法。

在我漫長的職業(yè)生涯中，我遇到很多懂行的產(chǎn)品經(jīng)理，他們邏輯能力比我強多了，但從不喧賓奪主，只在我為難的時候提出一些建議，讓我受益匪淺。反而是一些毛都不懂的產(chǎn)品經(jīng)理，天天給我秀智商。

（6）需求是否合理

本文開頭說的那個故事，就是需求不合理導(dǎo)致的，產(chǎn)品經(jīng)理一定要注意這一點，不要站在自己角度出發(fā)的，而是站在用戶角度，需求不能想當(dāng)然，多想想功能是用戶需要的嗎？千萬不要做無用功，不要亂提需求。

有的時候我總有這種感覺，啥也不做比瞎做至少還能節(jié)省人力，不浪費公司資源。產(chǎn)品經(jīng)理也不要動不動就說這是領(lǐng)導(dǎo)要的功能，和我無關(guān)。其實應(yīng)該這么想問題：領(lǐng)導(dǎo)可能有一個想法，其中也許 80% 不可取的，而產(chǎn)品經(jīng)理要做的就是將 20% 可取的部分強化，以此提出一個合理的需求。

（7）什么時候完成

有的時候產(chǎn)品經(jīng)理剛把需求發(fā)給程序員，或者開會剛討論結(jié)束，就迫不及待問啥時候能開發(fā)完成，領(lǐng)導(dǎo)急著呢。

有的時候還會抱怨這么小的一個改動就要2天？或者說這個開發(fā)很簡單吧？

這是一些非常不職業(yè)的做法，軟件開發(fā)有其自身的規(guī)律，需要設(shè)計、架構(gòu)、編碼、測試、部署等多個過程，是要求非常高的一個過程，所以千萬不要一上來就要開發(fā)時間，很容易讓人反感。

更好的做法就是問他們什么時候能評估出開發(fā)工作量（包括分析、設(shè)計），然后在郵件中周知，為避免程序員遺忘，可以提前詢問一下。如果和某個程序員熟悉了，了解他的風(fēng)格，可以采取一些策略來推動項目，切記不要動不動就問什么時候完成開發(fā)。

（8）我只管提需求

這一句話的下半句其實就是“其他我不負責(zé)”，在互聯(lián)網(wǎng)企業(yè)，產(chǎn)品經(jīng)理其實包含項目經(jīng)理的角色，對于一個高速發(fā)展的企業(yè)來說，不可能按部就班的工作。而推進器其實就是產(chǎn)品經(jīng)理，他們需要把握整個項目進度，不要認(rèn)為僅僅提需求就行了。

代碼是開發(fā)人員開發(fā)，推廣也是運營的事情，產(chǎn)品經(jīng)理本質(zhì)上就是指哪兒打哪兒，和設(shè)計人員溝通、接受運營人員的需求、給銷售人員數(shù)據(jù)、給程序員提需求、給測試人員寫測試用例、給用戶解答。

（9）找領(lǐng)導(dǎo)

有些產(chǎn)品經(jīng)理是急性子，一看程序員不配合，或者進度趕不上，就說找技術(shù)總監(jiān)，好像找了就能解決問題，有的時候也有點欺負人的感覺。可實際上最終配合你的還是這些程序員，這和接下去要講的人治非常類似。

我建議產(chǎn)品經(jīng)理少拿這個殺手锏，有的時候它還不一定管用，和程序員應(yīng)該永遠報以合作的態(tài)度，合作不順的時候，可以和程序員交交心，互相交流下想法，這樣才有可能解決問題。

（10）缺乏反饋機制

一個產(chǎn)品功能上線后，如果反響比較好，產(chǎn)品經(jīng)理當(dāng)然覺得都是他們的功勞，這也無可厚非，可如果不好呢？

產(chǎn)品經(jīng)理應(yīng)該分析問題，思考是否需要優(yōu)化它，也可以和程序員一些討論，共同想辦法。但大部分產(chǎn)品經(jīng)理卻毫不關(guān)心，好像根本就沒有這功能一樣，這種做法非常讓程序員寒心，程序員就會覺得你們也既不不開發(fā)代碼，也不關(guān)心項目的結(jié)果，長此以往，這樣的產(chǎn)品經(jīng)理會失去程序員的信任。

四、人治而非法治

任何一個行業(yè)，人與人之間的關(guān)系是必不可少的，對于程序員和產(chǎn)品經(jīng)理來說，他們之間的溝通是最多的，也是關(guān)系最密切的人，相處融洽才能將工作做好。

關(guān)于如何相處是一門藝術(shù)，可以看專門的一些數(shù)據(jù)，我從自己的角度出發(fā)，簡單列幾點。

（1）理解程序員

程序員是非常獨特的一類人群，性格可能和常人不一樣，但都非常感性，有的時候也會口無遮攔，甚至熟悉后還和你發(fā)脾氣。但大部分情況下，他們都非常純真，沒有太多的心機。

對于產(chǎn)品經(jīng)理來說，面對程序員的各種莫名其妙的表現(xiàn)，一笑而過，大度一點，多想想他們的優(yōu)點，盡力成為朋友，這是將工作做好的先決條件。

當(dāng)一個產(chǎn)品經(jīng)理進入新公司后，一定要仔細觀察各個程序員的性格、特點，針對性下藥，有策略的和他們?nèi)谌朐谝黄?，但需要注意的是，不是讓產(chǎn)品經(jīng)理忍讓他們，這也不是好策略，只是要盡量避免針鋒相對。

（2）認(rèn)同程序員

程序員不僅僅是開發(fā)代碼，他們邏輯性強，思考問題全面，作為產(chǎn)品經(jīng)理，要善于合作，尊重他們的觀點，多聽聽他們的意見，千萬不能說“這是需求，趕緊實現(xiàn)吧，其他的不用問”這樣的話。

而是讓程序員發(fā)表意見，比如說：“你覺得怎么樣設(shè)計比較好一點”、“幫我看看邏輯是不是正確”，讓程序員間接成為一個產(chǎn)品經(jīng)理，讓程序員意識到他們的重要性，意識到他們是設(shè)計者，而非僅僅是構(gòu)建者。

當(dāng)一個項目結(jié)束后，要多向他們反饋，反饋包括用戶的反饋，也包括產(chǎn)品經(jīng)理的自我批評。當(dāng)項目結(jié)果不是很好的時候，也要及時和程序員反饋，反思失敗的原因，這樣才能讓程序員意識到“這個項目的背景原來這么復(fù)雜啊”。他們也會從內(nèi)心接收這一切，如果總是沒有反饋，程序員會說“產(chǎn)品經(jīng)理又做了一堆垃圾”。

（3）目標(biāo)一致性

面對一個項目，真正推動項目的動力不是產(chǎn)品經(jīng)理的催促，而是讓程序員和產(chǎn)品經(jīng)理目標(biāo)達成一致，對于核心項目來說，他們一致目標(biāo)就是“這項工程關(guān)系到公司的生死存亡，所以必須加油”。

那一般性的項目呢？

即使不重要，產(chǎn)品經(jīng)理也要有極大的感染力，讓程序員意識到“我在做一件有價值的事情”，只有雙方目標(biāo)是一致的，項目才能飛快往前走。

目標(biāo)一致性來源于程序員對產(chǎn)品經(jīng)理的感受，如果你足夠職業(yè)，足夠?qū)I(yè)，是很容易感染程序員的。

（4）有自己的人格魅力

通俗的說，就是讓程序員信服你，人格魅力不僅僅體現(xiàn)在工作上，也包括你平時的言行、你的做事方式、你的性格、你的價值觀，只要其中有一件事情讓程序員從內(nèi)心深處佩服你，那么他會極力的配合好你。

向那些專業(yè)的產(chǎn)品同事致敬?。?/p>

作者： 虞大膽，公眾號：虞大膽的嘰嘰喳喳（ID：yudadanwx）

本文由 @虞大膽 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議

愛盈利-運營小咖秀(www.jza6.com) 始終堅持研究分享移動互聯(lián)網(wǎng)App運營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運營從業(yè)者的知識啟蒙、成長指導(dǎo)、進階學(xué)習(xí)的集聚平臺；

想了解更多移動互聯(lián)網(wǎng)干貨知識，請關(guān)注微信公眾號運營小咖秀（ID: yunyingshow）