如今的互聯(lián)網(wǎng)有個傳說中很神奇的職位，叫做「程序猿鼓勵師」，據(jù)說都是童顏巨X的妹子；今天看到一個文章，某公司程序猿過生日，請了好幾個身穿比基尼的俄羅斯外模（如下圖所示）；更不用說某互聯(lián)網(wǎng)公司年會請島國女優(yōu)的事情了。

好像程序員給業(yè)界的印象通常都是：死宅，蘿莉控，難以溝通，通常非常難以合作。特別是對于產(chǎn)品經(jīng)理來說，好像必須哄著程序員干活，得用盡各種辦法哄，否則程序員不配合。我其實一直很奇怪，程序員群體究竟怎樣被妖魔化成這樣的。

前幾天carol寫了一篇非常棒的文章：「技術人員愿意親吻怎樣的運營？」，這篇文章從運營人員角度去談怎樣和程序員合作，我也推薦給產(chǎn)品經(jīng)理看，因為道理都是一樣的。我就從產(chǎn)品經(jīng)理角度再補充一些建議：

產(chǎn)品經(jīng)理和研發(fā)共同參與產(chǎn)品設計

一般的產(chǎn)品流程都是從產(chǎn)品需求搜集，到產(chǎn)品原型設計，這個階段都是產(chǎn)品經(jīng)理來執(zhí)行，然后產(chǎn)品經(jīng)理把原型交給視覺設計，視覺設計出高保真的設計稿，最后交給程序員開發(fā)。

在這個產(chǎn)品經(jīng)理，視覺設計，程序員共同參與的產(chǎn)品生產(chǎn)過程中，程序員是最后的環(huán)節(jié)，當程序員在代碼實現(xiàn)的過程中發(fā)現(xiàn)了產(chǎn)品邏輯的錯誤，或者產(chǎn)品設計的問題，是非常被動的。這個時候程序員再要求產(chǎn)品經(jīng)理更改設計，修正產(chǎn)品交互邏輯，產(chǎn)品經(jīng)理通常的反應就是：「程序員又和我討價還價，產(chǎn)品deadline又要延后了」，跟著雙方就開始劍拔弩張的對峙。

我在帶團隊做產(chǎn)品的時候，從產(chǎn)品立項一開始，就召集產(chǎn)品經(jīng)理、視覺設計、研發(fā)負責人、運營負責人、運維工程師一起參與，把產(chǎn)品的目標定下來，然后讓大家各自從自己工作分工的角度去討論產(chǎn)品需求，產(chǎn)品功能，產(chǎn)品應該采取什么視覺風格，產(chǎn)品實現(xiàn)是否有難點，產(chǎn)品部署需要預先考慮些什么等等。之后每周產(chǎn)品例會都會召集大家一些開會討論產(chǎn)品進度。

盡管產(chǎn)品立項之后，是由產(chǎn)品經(jīng)理負責搜集和定義產(chǎn)品需求，整理產(chǎn)品邏輯規(guī)則，設計產(chǎn)品原型稿和交互，這個階段并不需要程序員開始寫代碼，但是從一開始就讓程序員，運營，甚至運維工程師都參與進來，是非常有益的：

1. 程序員從一開始就了解了產(chǎn)品的來龍去脈，對產(chǎn)品需求和產(chǎn)品要達到的目標非常清楚，這樣在和產(chǎn)品經(jīng)理的配合中，就非常容易理解產(chǎn)品經(jīng)理提出的很多功能要求，溝通起來非常順暢；
2. 程序員從一開始就參與，并且持續(xù)參與產(chǎn)品設計的過程，最大的好處在于從一開始就可以糾正可能出現(xiàn)的產(chǎn)品設計邏輯錯誤，以及評估技術難以實現(xiàn)的產(chǎn)品功能。這樣等到真正進入開發(fā)階段，研發(fā)周期是非常可控的，基本不會出現(xiàn)延誤。
3. 一些有良好產(chǎn)品意識的程序員，可以幫助產(chǎn)品經(jīng)理從一開始就完善產(chǎn)品邏輯，從實現(xiàn)上修正產(chǎn)品可能遇到的問題，讓產(chǎn)品開發(fā)過程變得更加有保障。

很多產(chǎn)品經(jīng)理犯的一個重大錯誤就是：直到原型稿交互稿定稿之后，才交給程序員，之前全無溝通，然后逼著程序員立刻評估一個精確的開發(fā)周期。

這個時候程序員內(nèi)心是非?？咕艿摹Ｒ粊砦彝耆涣私膺@個產(chǎn)品，不知道做這個產(chǎn)品是干啥的？能夠解決什么問題？是否有更好的替代解決方案；二來我也不清楚這個產(chǎn)品邏輯是否有需要調整和修正的地方，以及有些技術上需要投入很多資源但是不劃算的功能。

所以程序員通常只能硬著頭皮估一個時間，然后實現(xiàn)過程當中一旦出問題，就是雙方互相扯皮，互相推卸責任。

產(chǎn)品不是產(chǎn)品經(jīng)理的，而是大家的

互聯(lián)網(wǎng)公司通常是產(chǎn)品經(jīng)理負責制，產(chǎn)品經(jīng)理往往認為我是這個產(chǎn)品的owner，你們其他人都是配合我工作的。但其實除了創(chuàng)業(yè)者CEO自己就是產(chǎn)品經(jīng)理之外，通常大公司的產(chǎn)品經(jīng)理并不真的是產(chǎn)品的owner，不具有對產(chǎn)品最終負責的權利。這個時候就產(chǎn)生了認知的錯位和工作對抗：

產(chǎn)品經(jīng)理認為：你們都應該聽我的指揮，我是產(chǎn)品的owner，你們都要配合我的工作。但是程序員會想：我憑什么聽你指揮？我還有我的上級領導呢。我和你就是平級關系而已，我又不是向你匯報，你憑什么對我頤指氣使？

在這種情況下，產(chǎn)品經(jīng)理應該傳遞一個信息：產(chǎn)品是大家的，需要大家共同合作，一起努力把產(chǎn)品做好，無論是產(chǎn)品，視覺，研發(fā)，還是運營，大家都是為了一個共同的目標而努力。我作為產(chǎn)品經(jīng)理并不天然具有命令大家的權力，如果大家愿意聽從我的意見，那也是因為我更加努力，更加專業(yè)，做出的貢獻能夠得到大家的認可。

你真的需要這個功能嗎？

產(chǎn)品經(jīng)理面臨最大的自我拷問就是：「你確定你真的需要這個功能嗎？」。產(chǎn)品經(jīng)理提出一個功能需求是很容易的事情，不浪費什么資源，可是一個功能一旦確定需要做，后面跟著的就是大量的設計，開發(fā)，測試，以及產(chǎn)品上線無休無止的維護工作。

另外一個特別常見的現(xiàn)象就是一個功能開發(fā)出來以后，很快又拋棄掉了，改過來改回去。而產(chǎn)品經(jīng)理通常又不需要為此決定而買單，擦屁股的都是程序員，所以這也是非常招人恨的原因之一。

好的產(chǎn)品經(jīng)理總是在思考應該再去掉哪些功能，而不是毫無節(jié)制的添加產(chǎn)品功能。即使添加一個功能，也要再三拷問自己，真的需求嗎？真的必不可少嗎？

不需要懂技術，但是邏輯要嚴謹

其實產(chǎn)品經(jīng)理并不需要懂技術，很多優(yōu)秀的產(chǎn)品經(jīng)理也并非技術出身，但是產(chǎn)品經(jīng)理必不可少的一項基本功就是：邏輯要嚴謹。因為一旦產(chǎn)品經(jīng)理思考不周全，或者產(chǎn)品邏輯出現(xiàn)了自我矛盾，最終都是程序員要為此買單，要么產(chǎn)品功能實現(xiàn)不下去，要么到處都是漏洞，程序員變成了救火隊長。

產(chǎn)品經(jīng)理犯的錯誤，最后買單的都是程序員，這也是為什么一個差的產(chǎn)品經(jīng)理通常很招程序員恨的主要原因

以身作則，以德服人

產(chǎn)品經(jīng)理可以是很忙碌的，也可以是很清閑的。

什么叫做清閑的產(chǎn)品經(jīng)理：等著用戶（或者客戶）反饋bug和問題，整理到工作任務列表，指派給程序員，然后定期監(jiān)督程序員工作完成狀態(tài)。新的產(chǎn)品立項，畫個簡單的原型線框圖交給視覺，然后催著程序員定deadline。

什么叫做忙碌的產(chǎn)品經(jīng)理：主動找用戶（或者客戶）做訪談，搜集產(chǎn)品反饋，根據(jù)產(chǎn)品反饋，思考產(chǎn)品未來的改進方向；將用戶的反饋和自己的產(chǎn)品規(guī)劃定期和程序員溝通，大家一起商量制定產(chǎn)品迭代改進的roadmap；仔細鉆研產(chǎn)品界面的每個元素，動手畫出高保真的產(chǎn)品原型和交互，羅列產(chǎn)品每個分支邏輯，以及異常處理流程；整理產(chǎn)品的所有功能點，設計完備的測試用例，并且在產(chǎn)品的每個發(fā)布點做詳細的完備的測試驗收工作；和程序員每周定期溝通，互通有無，推進產(chǎn)品開發(fā)進度。

如果你是一個清閑的產(chǎn)品經(jīng)理，只是動動嘴皮，敲敲鍵盤，那么你的價值在哪里？你怎么可能取得程序員的信任？如果你是一個忙碌的產(chǎn)品經(jīng)理，你承擔了產(chǎn)品大量的工作，成為一個產(chǎn)品事實上的靈魂，程序員怎么會不喜歡不配合你呢？

一個產(chǎn)品經(jīng)理如果能夠做到以上幾點，我相信一定能夠成為程序員非常喜歡的產(chǎn)品經(jīng)理。其實程序員這個群體和任何其他群體沒有什么特別的不同，也不是真的需要什么程序猿鼓勵師，需要產(chǎn)品經(jīng)理哄著才能干活。說到底其實就是一條：踏踏實實做好自己的本職工作，才能贏得程序員的尊重。

作者：范凱（robbin），微信公眾號：技術創(chuàng)業(yè)空間（ID：itstarter）

本文由 @微信公眾號：技術創(chuàng)業(yè)空間 授權發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉載。