過節前看到一篇文章，講產品專案就應該由工程師來主導，但國內讓pm去驅動專案，搞得亂七八糟，很惱火，怎麼可能做出一款好產品來呢？
很顯然，寫這篇文章的是一位憤怒的工程師，angry engineer！我跟他至少有兩點共鳴：
1、國內的pm確實常常折騰工程師，甚至不乏「把工程師當工具對待」的情況。
2、如果工程師有開闊的產品視野與全面的設計素養，知行合一，由工程師來驅動專案是乙個完美的選擇。
可惜由於教育環境的問題，國內通才太少。乙個優秀的工程師，同時又是乙個優秀的pm，鳳毛麟角，只能人任其長，各自做自己拿手的活兒。這時候更擅長需求分析與產品設計的pm來驅動專案，也是不得已的選擇。
說來慚愧。需求不靠譜，或是來來回回修改，折騰工程師的事兒我也做過不少，直到最近一年多才算是大有好轉。我應該懺悔……雖然能做好pm的工程師極少，靠譜的pm其實也不算多，最後大家都得寫週報對不對？
在產品行業遠遠不夠成熟的現階段，痛苦的來回折騰難以避免。但最起碼，pm應該把工程師作為夥伴而不是工具，想法設法地站到一條戰壕裡去，爭取他們的理解。因此拋開難以鑑定的需求的對錯，僅僅從協作流程的改進上，我積累了以下的經驗。
首 先要得到工程師對整個專案的認同。每個月都有一場一小時的部門月會，對著ppt，我來講下個月乃至下個階段，我們的任務規劃是什麼，目標設定又是什麼，詳 細解釋制定規劃與目標的原因，近景與遠景分析，為咩做這件事情為咩這樣去設計等等。希望工程師能認可他即將做的事情是有價值的，值得為之而努力的。為接下 來pm與工程師的溝通做好鋪墊。
月會上還有乙個環節，詳細分析本月發生的所有資料，尤其是最近發布的新功能的資料。這個環節也是為工程師準備的，使他們了解自己的工作能產生多少實際效果。
至於月會上送出的新功能禮品（以前講過許多次），最開始是為工程師專設的彩蛋，再後來才將pm與運營包括了進來。我得承認自己對工程師偏心眼，因為有信心能激勵pm與運營，卻出於溝通深度不足，需要借助更多的手段來激勵工程師投入專案。
項 目任務分兩種，大版本與小模組。對於大版本，在基本框架定下來之後，pm提前向工程師講解，聽取技術視角對設計方向的建議。整個設計過程中還會反覆討論三 五次，為技術上的合理性徵求意見。小模組則在策劃案基本敲定之後，與工程師共同確認一次，視覺稿出來後再通報一次。（所以pm與工程師坐得近是很有必要 的）
我曾經在部門月會上公開承諾說，任何乙個需求，只要工程師認為是不合理的，都可以停下來不做。直到pm能說服工程師為止。如果死活談 不下來，才由我和技術經理出面來協調。強硬要求服從的情況在我這裡基本上沒有，被工程師說服倒是時有發生，按工程師提出的意見來改方案。我也常常跟pm 講，小分歧你們都聽工程師的，沒有必要堅持己見。你讓他爽一點，開發速度就快一點，大家都獲益。再說你多聽聽技術夥伴的意見有什麼不好呢？幫助你轉換思考 的角度，共同找到提高開發效率的方法。
最後方案定下來了，pm說ok，工程師也覺得方向大致沒錯，細節基本合理；進度方面則由工程師進行 評估。pm覺得時間太長接受不了，再找到我和技術經理一起商量，看是分階段砍需求呢，還是加把力加點班。除了極少數緊急修復任務外，不會由pm單方面確定 開發時間安排。包括一系列任務的優先順序安排，也由pm先提草案，工程師根據開發情況來調整順序，再共同確認。
在pm提出需求的整個流程 裡，始終在進行不斷的協商，保證工程師對任務是理解並且接受的，不會出現抗拒，或者是麻木的心態。如果遇到突發性的需求變更，更加會向工程師反覆解釋，請 求諒解，因為浪費了他們的工作成果而心存歉意。為此而花費的時間對比更高的開發效率，穩賺不賠。雖說具體協作時還有一些不到位的地方，但態度總歸是好的， 基本的效果也是有的。
當然，這套流程的實施得具備兩個前提。第一是有穩定的團隊，如果變成提單協作，這個月一起幹下個月分道揚鑣，那就不 可能實現共同的專案歸屬感。第二是工程師的個人素質基本靠譜，溝通順暢；尤其是技術經理可以服眾，協調好分歧而不護短。比如說乙個功能能不能做，至少開發 多久，我和pm都搞不掂，主要靠技術經理來做最終判斷；如果出現開發過程中的失誤，或是不按照約定好的方案進行開發，則由技術經理進行處罰。我對開發組更 多作行政管理，全靠這位技術核心夥伴來負責業務管理，他也會更深入地參與到產品的結構設計，任務規劃裡來。
這樣做，也就撇開了把工程師當工具對待的嫌疑。我覺得把任何同事當工具都挺可恥。怎樣才算是夥伴呢？比如交流必要的資訊，理解對方；比如能站在對方立場去換位思考；比如多一點點鼓勵與幫助。
換 個角度看，我這邊曾經出現過由工程師來提出大致構思，pm認可並負責細節設計，再由這位工程師來實現的情況。結果皆大歡喜。我後來多次在月會或別的場合徵 求工程師的創意，換一換視角，引入新鮮的想法與靈感。即便想法不一致，也會非常溫和地解釋反對原因，絕不可能一口否決。唯恐工程師們默不出聲悶頭幹活—— 聽不到技術夥伴的意見是多大的損失啊。
今上有敕雲：「科學發展觀的核心是和諧發展。」
PM與工程師
過節前看到一篇文章，講產品專案就應該由工程師來主導，但國內讓pm去驅動專案，搞得亂七八糟，很惱火，怎麼可能做出一款好產品來呢？很顯然，寫這篇文章的是一位憤怒的工程師，angry engineer！我跟他至少有兩點共鳴 1 國內的pm確實常常折騰工程師，甚至不乏 把工程師當工具對待 的情況。2 如果工...
怎麼處理PM與工程師之間的問題
老師教我們怎麼寫程式，但從來沒告訴我們在公司裡，會有個叫做pm的人每天分派作業給我們，還逼著我們趕快做完。這是許多軟體工程師進入職場的第乙個驚喜。隔了不久，還會發現，這些可能把你壓得死死的pm，多半一行程式都不會寫。於是我們會面臨一種很矛盾的心情，有時候會是一種有點被欺負的心理。這篇文章是前一篇文章...
工程師如何不被PM欺負
老師教我們怎麼寫程式，但從來沒告訴我們在公司裡，會有個叫做 pm 的人每天分派作業給我們，還逼著我們趕快做完。這是許多軟體工程師進入職場的第乙個驚喜。隔了不久，還會發現，這些可能把你壓得死死的 pm，多半一行程式都不會寫。於是我們會面臨一種很矛盾的心情，有時候會是一種有點被欺負的心理。這篇文章是前一...