如何對付那些覺得 PM 可有可無的程序員？

12-18

好多技術覺得PM可有可無，甚至無勝於有，因為他們覺得：

事兒都是我們乾的

自己不會幹還指揮我們干

還嫌我們乾的慢 ……

先肯定一個前提，你作為PM，你的工作你的決策你的制衡你的項目行為都是為了讓項目按時按量更好更快完成。所以不論對項目團隊還是虛擬團隊的控制，都應如此。當然特定環境下你可能要考慮立威、拉攏、人際制衡等項目之上的問題。但若沒有，請不要熱衷於鬥爭，你不是來尋求尊重的。

不說PM的職業技能，只針對團隊管理說幾點：

了解美術/前端/後端工作原理。
如果你知道美術設計主菜單懸停二級的不規則投影會浪費前端大把的時間調試，你還能想像前端看到了多難過，你就及時建議改用規則統一透明度的投影。如果你知道後端用for循環輸出20條左右結構的新聞列表，你就讓前端用css控制自動左右布局，而不是左右拆成兩份。
他們去到其它團隊時，會懷念你的。
給團隊成員足夠的信息和空間。
這三個職業都不是工具，尤其後端攻城師。再初級的程序員也會嚮往人月神話，他們能為你提供合理的高效的架構設計。你要給予他們足夠多的信息，給他們留出恰當的時間，讓他們完成合理的架構。前後端工程師大多對復用和高性能保有成就感，你儘可能提供多的信息，由他們來處理。這也是為他們後期維護和迭代提供便利，你不要有所保留！如果你真的思維不縝密，藏不住的，最後連朋友都交不成。
勇於溝通和學習。
工程師跟你說以後用velocity來編輯頁面，你不理解，那麼就問。如果他鄙視你，那麼是他的問題，也可能是你的問題。大多數工程師願意給你講解的，他們也害怕表達，這是雙方的修為。
如果工程師說必須從mysql換成oracle了，你問為什麼，他說無法承載了，你問要多久，他說要兩周，你崩潰了但是問為什麼，他說要寫數據轉換腳本，你問為什麼，他說兩個資料庫之間數據類型不同需要有一些轉換，索引規則也不同，你問什麼是索引……這都是可以的，你要帶著學習的心態而不是問責，否者他越答越反感。最後你若懂了，他會覺得你理解他。
小心處理需求變更。
這是個永恆的話題，出了各種凡客體愛情買賣體來鄙視需求變更。你可以坦誠表達：需求變更是難免的，是不斷探索和調整而來的，作為PM我自認無法一次性想到最好，很抱歉。
接著就是技巧活了，原則是儘可能避免反覆修改。如果有一個頁面的數據呈現，你無法想像怎樣更好，你可以用chrome開發者工具先去調整查看，別直接讓技術修改併當作你的參考。如果你不會用工具可以去學，實在複雜你就懇請技術輸出兩份效果給你比對，而不是改了說不好再改回去。
第二點就是，如果有的數據呈現模塊要裁剪，但有可能日後換個形式換個地方呈現，你就要跟技術說明白，讓他只是注釋暫時隱藏。你不知道一個簡單的數據呈現它用了緩存還是別的什麼。
成就感是你能給予的共鳴。
你要知道各位同學都在意什麼，物質需求可能你無法給予，吃個飯之類的其實是順理成章，不必刻意。各位同學踏入互聯網江湖，大多想在各門個派混出個名堂。如果你有機會，不要吝嗇這樣的稱讚。代碼注釋，產品主創介紹，向上彙報各同學的技術成果，鼓勵同學往各渠道分享技術心得。同時適當認同各位在架構性能上的新想法新思路，包括交互體驗上也應該給前端人員發揮空間如果他們願意。
其實最根本的，你要熱愛產品並竭盡所能，產品的受眾範圍和影響力是個天然的成就感。
勇於擔當。
你多承擔一些考核壓力和物質壓力，同學們才能更有精力投入到工作中。同為打工的你，能做的不過如此了。特別是當項目失敗時，怎麼可能跟你沒關係，該推的不該推的都不該推，早幹嘛去了？若出現項目成員能力問題和態度問題，儘早反映，說按此下去結果最好只能如何，把問題丟給你的頭。那麼他要麼換掉你，要麼換掉該成員。
在知乎到現在為止寫得最長的了...若有所得...甚幸...

本人經驗總結：
要訣一，盡量在需求確定後再提交開發，需求變更要給出充分的理由
要訣二，隨時準備著，並盡量用最短的時間為技術解決任何非技術問題。例如部門間協調、文檔和素材的準備
要訣三，言之有物，不要說空洞的片兒湯話，一針見血、思路清晰的描述需求
要訣四，謙虛和威信並存，不懂就問，虛心接受技術提出的產品意見，但原則問題不妥協

由於今天被技術哥們感動了，特意抽出點時間來回答這個問題。心中思緒萬千啊~
說一些反面教材。
2011年末做的產品：

彈性上班，拍板的事情經常找不到人。前任上司自己首先實行彈性上班制度，下午才來，技術經理經常都找不到他，我們也不敢去拍板。就算問題是解決了，技術也會覺得你一點都不緊張項目（產品）。連自己的孩子都不緊張，誰替你去緊張；
前端做到想吐也要做。跟前任上司討論關於項目的問題（我的意見是第一版不用做得太精美，以後可以迭代上線，他的意見是第一版就要做到很出眾，以便日後更好地請求資源）。上司跟我談到他以前的經歷：他說在以前公司做，他們策划出的效果有N種情況，由於策划出來的時間點比較靠後，導致前端切圖切到想吐，最後還是如期上線，勸我不要太過於考慮實現方面的問題。當時我就想，就為了那些效果而把別的同事搞到想死的趕腳，值得么？效益與成本對比如何？你咋知道那些效果就是好的？或者是壞的呢？反正到最後，那期的項目還是有各種效果，同時也讓設計加了三周的班，技術到最後上線的時候，連續做到第二天早上（第二天是公司年會）；
技術加班，產品跑去吃飯。在上線deadline，前任上司跑去跟人吃飯了（交代下背景，在策劃期間，他經常都出去吃飯看電影，我跟另外一位策劃都只是出去過幾次，周六日都在做），而技術兄弟姐妹都在修復bug。我跟另外一位策劃不斷在檢查，有問題馬上反饋修復。某經理晚上十點回來，我立馬就訓斥他一頓：人家技術都在為我們的項目而加班，晚餐是吃餅乾、喝汽水，你他媽還出去吃飯？太說不過去吧？被我訓斥了一頓，某經理就馬上搞了個麥當勞外賣，還算是將功補過。後來我再提出，要讓某經理自己出錢給技術搭的士。
項目失敗了，沒有後續的反饋。我的個人意見，就算項目失敗了，作為項目或產品的發起人，都需要跟大家講清楚情況（特殊情況除外），在最後總結一下。然後在請大家吃飯啊什麼都好，畢竟大家都是為了項目認真努力付出過的，就算失敗，也要慰勞一下。

個人的一些看法：

事前溝通：作為策劃，自己首先得明確這個項目（產品）的定位，到底是解決什麼問題，然後把這些都灌輸給相關的寫作部門，讓他們知道自己為了什麼而設計、寫代碼。每一個頁面，每一個功能點都是有根有據，背後都有Why去支持，這樣跟協作部門宣講的時候，都能站得住腳，讓他們去相信、去憧憬；
自身定位：產品人員其實跟古代的謀士差不多（個人意見，歡迎拍磚），設計、技術都是同一陣線的，而不是產品人員高高在上地指揮大家。成功是協作部門的功勞，失敗的話自己必須主動承擔責任；
同理心：這個不用多說了，人家吃餅乾喝汽水，尼瑪你在外邊快活？
上線後反饋：上線之後，好的情況必須第一時間反饋給協作部門，讓大家都了解到自己的工作是有意義的，並不是一堆堆無意義的設計圖或代碼；
榮辱與共：並不是只有產品人員想讓產品好，設計、技術都希望自己的勞動成果得到用戶的好評。部分產品人員學習設計、技術方面的知識，僅僅是為了不被他們「坑」，生怕協作部門為了省事、省時間而偷工減料，這種觀念絕逼不對的！你這樣想，行為上就會表達出來，對方也會懷疑產品人員的能力。

技術哥們在群上說：大家都是一個項目組的兄弟。真讓人感動。
第一次在知乎回答這麼長的一段，希望能對大家有用。

題外話（剛看的）：一封程序員的苦逼辭職信，鏈接：http://www.kuqin.com/job/20120505/320357.html

忍不住想嘮叨幾句，首先欣賞短片：The Expert (Short Comedy Sketch)2_Hereinuk英國那些事

其實Product Manager是個難度很高的職業，每一個精準需求的提煉需要千錘百鍊次的推敲和嘗試，所以合格的PM除了本職工作之外還要涉及到計算機，美學，統計學，心理學，邏輯學，哲學等等很多很多複雜的周邊學科的融會貫通，

PM可以不是技術出身，但至少不能對行業內的技術不聞不問啊，這麼說吧，你想做iOS產品，那怎麼著也要能寫個簡單的demo吧，而且移動開發的門檻也不是特別高，至少你知道了導航頁面的切換方式，才能明白怎樣設計頁面職責才能對數據和模塊進行解耦，知道了事件響應鏈的傳遞順序，才能明白怎樣的手勢交互算是合理的設計，知道了iOS每個sdk版本之間的迭代差異，才能明白怎樣的效果才能更好的兼容體驗等等等等……如果說連蘋果人機交互指南都不願意仔細研讀，那從一開始就失去了對項目負責的態度。

這些都是最最基礎的技術儲備，了解技術原理不是說用來在需求評審的時候贏得辯論，而是更好的合作來推動項目的運轉，反過來這也會良性的刺激到需求的產出啊，而不是單純的在白板上寫寫畫畫。

非常同意「作為PM，你的工作你的決策你的制衡你的項目行為都是為了讓項目按時按量更好更快完成。」這個觀點，所有追求極致和完美都是以不破壞項目運作和質量為前提。我接觸過的一些PM，他們為了所謂的一點點體驗上的優化，竟然不顧技術團隊所有人的反對，不惜犧牲一切開發和維護上的成本來完成，且不說這種需求是否真的能帶來數據和流量的增長，單這種不顧大局的決策而言最終勢必會造成迭代維護上的惡性循環。

至於需求本身，工程師最需要的是邏輯，而不是給不完整的需求填坑，永遠不要把自己的職責定位在「我提需求，你來做」的角度，產品需要職能單一化，但團隊需要儘可能多的多面手。所以需求的產出是雙方乃至多方共同溝通的結果，所以PM更重要的是掌握產品的原則形態和方向，協同多方的資源讓team work起來。

扯了這麼些廢話，其實要做的只有兩點：1.知道程序員都在做什麼，2.讓程序員知道你在做什麼。

1.想清楚策略，別總反覆；
2.錯了就是錯了，別裝B；
3.有點兒技術可實現性的常識，別提腦殘策略；
4.只管給目標，別告訴技術怎麼做；
5.有事兒沒事兒請吃飯；
6.產品決策要快、准、穩！

我就是做JAVA出身的，現在也算是個產品經理吧。其實做技術的人性格內向，但是都很善良的。很多事情你需要多溝通，盡量聽聽他們的看法。而不是去跟他們說這個應該怎麼做，程序上應該很容易實現這些話。如果你不懂技術本身就跟他們有代溝，個人建議你稍微補充一點技術相關的知識（至少技術上的術語你能明白），私下多請他們吃吃飯喝喝酒就好了，做技術的沒什麼心眼的，哈哈

其實一切都需建立在一個產品經理本身的能力之上。

事情干不好，請客吃飯不管用。
事情干不好，你的親兄弟程序員都會煩你。
事情干不好，別人看到你努力的過程但受不了你努力後給出的結果。
事情干不好，信任感不會有。

這個問題比較有意思，雖然大家基本上都回答完了，我還是說點自己的看法：
1. 要靠譜，不要瞎提需求，不要讓RD覺得被忽悠；
2. 要分享，因為PM手上各方面的資源是最全面的，可以從最廣的範圍把握產品，PM應該將這種vision分享一些給engineer讓他們明白自己究竟在做什麼；
3. 要擔當，銷售、市場端永遠會覺得產品出的太慢，用戶永遠會覺得產品不夠完美，PM應當在他們罵RD時站出來；
4. 要溝通，當需求有變動、項目團隊內部有分歧、人員有變動時PM要從中協調、溝通，不要把問題與不滿積累在那裡導致最後的爆發；
5. 要激勵，給RD一個遠景，讓他們了解到自己工作的價值與意義，當他們更加珍視自己的工作時便會更加尊重讓他們明白此點的那個人。

至於學歷、學校、技術、長相、經驗、背景云云，不該成為PM贏得程序員尊重和支持的原因，只是推動項目的一點優勢而已。

一次又一次的證明你對用戶的判斷是對的，同時，勇於承認那些失誤的判斷

事兒都是我們乾的----------------發工資就是要幹活的，這都要商量？實在不行，把PM和其他人打交道的苦水說一說，博取一下同情如何？大家都不容易嘛。
自己不會幹還指揮我們干--------------------------程序員最討厭的就是外行，所以把自己變成內行吧，就算不是非常深入，至少要有基本的了解。至少Web開發的門檻很低很低。
還嫌我們乾的慢-----------------------同上，內行是不會錯誤估計工數的，至少不會太離譜。

很多情況下，PM就是可有可無，有時候還能產生反效果，幫倒忙。
一個沒有服務意識只有領導意識的PM是程序員的噩夢。
一個資深PM，他懂得什麼時候該閉嘴，什麼時候該把程序員從牛角尖里拉出來，什麼時候該……程序員知道的，他知道，程序員不知道的，他也知道。在這種PM的壓力下，程序員會很緊張自己的存在價值，因為程序員清楚，一旦自己能做到的PM都能做到，那自己的存在價值就危險了。
這樣的PM，你覺得至少得多少年的工作經驗？
我覺得怎麼也得三四年吧？
錯！五年起，你別嫌多，還不算非的PM工作經驗，人家軟體團隊一個資深PM的地位是戰略級的，微軟的XP為什麼能如此成功？後面的VISTA怎麼就那麼渣？PM！
當一個PM在考慮「如何對付那些覺得我可有可無的程序員」的時候，這個PM已經是可有可無了。一個成功的PM，那必然是會讓程序員覺得自己離了PM就是個渣，他根本不會提出這個問題。
綜上，一流的PM讓程序員覺得自己需要他，二流的PM讓程序員覺得他不存在，三流的PM讓程序員討厭他，最差勁的PM讓程序員討厭他，而他自己還在想「如何對付那些覺得我可有可無的程序員？」

必須是升職加薪啊。

因為我是pm+程序員，確實不需要你們啊。
我老東家的公司口號就是：you are the one
我們翻譯為：就你丫一人

兩個方面：
1、做事勤奮。把應該寫的需求寫清楚，邏輯里清晰，該什麼時候出製作稿，時間進度等都跟技術兄弟提前敲定好。
2、為人謙卑。要盡量跟技術的兄弟們打成一片，吃吃飯，喝喝酒，公司說不了的話，飯桌上可以說。

1.做一款強大的產品，不要三天兩頭的推翻重來
2.文檔寫明白，哪怕是個小問題
3.做需求的時候最好聽聽技術的意見

程序員這樣認知有錯？

1、別玩心計，玩心計絕對不長久，只能遭到道德上的鄙視。

2、把他當朋友，多溝通。所謂給出充分的信息，包括你為什麼要這麼做，這麼做在全局上有什麼意義，完全說出來，這是最基本的。

3、無論如何，你得有讓對方信服的能力。哪怕是尿尿特長，最遠5米。

4、多為對方著想，為對方提供儘可能多的時間。

5、儘可能在講問題時幽默一些。

6、讓他認同你的產品觀，以及對整個事情的理解，乃至價值觀。讓他覺得做這件事，有意義。

其實這都是些很家常的觀點，一切還是實力說話。

問題分兩段說：
===========第一段===========
請你修改掉「對付」兩個字。
團隊裡面的每一個人，都是你的夥伴。你是整個項目的Master，你需要每一個的共同努力，你才能完好的完成你的工作。
這段講得是你，以及你團隊裡面每一個人的態度：對待夥伴的態度，對待工作的態度，對待整個項目過程中遇到的所有問題的態度。
===========第二段===========
說幾個問題，建議你思考一下。
0.你可以寫出你心中PM的職能，然後跟我後面說的幾個問題對比一下，你自己來決定咱倆誰說的對。
1.你帶領的團隊裡面的人，他們的工作和生活開心么？
2.你團隊裡面的人，會因為你帶領的項目而加班么？如果有，加班的頻率是多少？
3.你帶領的項目，會提前結束或者延遲發布么？
4.項目開發過程中，需求變化的頻繁程度如何？你們是怎麼處理的？
5.項目中每一個的決定，考慮過所有相關人的利益么？徵詢過他們的意見么？
6.看到我上面寫的那幾個問題，你有沒有一種「我艹，這些關他媽我屁事」的想法？如果沒有，我表示感謝；如果有，為什麼？

實話實說在某個特定的環境階段，產品經理真的可有可無；
但是針對題主所說的這個環境感覺是你們直接產生了誤會，應該大家坦白地溝通避免隔閡導致更深的誤解。
不建議，決裂；大家都是為了工作，能夠工作之餘結交一個朋友也是不錯的哦，做不了朋友就做普通同事也挺好。

最後一個很不人道的做法，慎用：這個人對你有偏見，你就徹底放手一個項目，讓業務方直接對接他一周試試，你的價值就被認知到了。

大多數情況下，RD並不了解PM想要的功能是拿來幹什麼用的，典型的語言是你要什麼，我給你什麼，哪怕你要的是垃圾。對於RD而言，需求是輸入，結果是輸出，考核RD的，是開發時間和最少的Bug。

PM關心的，是
1，進度；
2，用戶體驗；
3，成本；
4，產品的演進。
這中間，至少有兩個是有missing part的，一個是用戶體驗，一個是產品的演進。但這兩部分，從RD角度，不是考慮的重點，糟糕的是，在開始提需求的時候，往往產品經理也不一定能說的很清楚。造成的結果，一個是需求的變化，再就是最終的結果不是產品經理想要的。有很多feature，產品經理take for granted. 研發認為需求里沒有。

改變這樣的情況，有幾種方式：
1 需要RD離用戶更近，至少要讓他們知道做出來的東西用戶怎麼用，在什麼場景下用；
2 產品經理要儘可能多的和研發交流產品的演進，方便研發一開始從構架上多考慮；
3 有效和隨時的交流，這個在產品Prototype出來之前尤為重要；交流的能力對於產品經理，我認為可以排在對於行業和產品本身的理解之後排在第二位，如果和研發都交流不好，也不要指望產品經理可以和用戶有效的溝通。

總而言之，產品經理是公司裡面除了老大以外，對於產品負責的人，可能根據JD的不同，不一定看產品的PL，既然是own這個產品，就需要協調各種資源，達到自己想要的結果，研發對於產品經理來說是資源，而且是非常重要的資源，這個資源能否用好，直接決定了產品經理的Baby是否健康。