工程師和產(chǎn)品經(jīng)理之間的恩怨情仇，一直是科技圈茶余飯后久盛不衰的一個話題。"產(chǎn)品狗”?摧殘 "碼農(nóng)”的故事、或者工程師吐槽產(chǎn)品經(jīng)理什么也不懂只會亂提需求的段子屢見不鮮。那么，產(chǎn)品經(jīng)理和工程師到底能不能和諧共處，成為一個戰(zhàn)線上的好伙伴?
其實，一個優(yōu)秀的產(chǎn)品經(jīng)理不僅能和工程師有效合作，甚至可以讓工程師覺得跟定了你，沒你不行。
在硅谷，我們常說一個頂尖的產(chǎn)品經(jīng)理每次跳槽，都能拉走一堆優(yōu)秀的?工程師，究其原因：一是，這樣的產(chǎn)品經(jīng)理確實不多見；二是，遇到一個好的產(chǎn)品經(jīng)理，工程師可以把更多精力花到他們感興趣的、有巨大影響力的方面，可以更有效率地做出優(yōu)秀的產(chǎn)品。
優(yōu)秀的產(chǎn)品經(jīng)理能激發(fā)工程師的能動性
在硅谷的很多頂尖科技公司，都是"工程師導(dǎo)向”?的文化，也就要求產(chǎn)品經(jīng)理不能像監(jiān)工一樣告訴工程師應(yīng)該做什么。如果產(chǎn)品經(jīng)理對工程師指手畫腳，那工程師會頓時失去工作的興趣，吵著嚷著要換組、換產(chǎn)品經(jīng)理。但是，一個真正優(yōu)秀的產(chǎn)品經(jīng)理能夠讓工程師興奮起來，滿腔熱情地投入到產(chǎn)品開發(fā)中；而這種熱情一旦被激發(fā)出來，產(chǎn)品經(jīng)理就再也不用擔(dān)心工程師會拖延工期、消極怠工，相反工程師甚至?xí)饶愀e極。
那怎么才能激發(fā)工程師的能動性呢?我至少和百位不同背景、不同資歷的工程師工作過，在無數(shù)次"踩坑”后，我總結(jié)了下面的這些建議。
第一，作為產(chǎn)品經(jīng)理，你應(yīng)該知道這個工程師在乎的是什么。
他是一個剛畢業(yè)不久、滿腔激情、想趕快升職加薪的工程師?還是一個想解決最高難度的技術(shù)問題，哪怕產(chǎn)品沒人用，只要解決的問題難度足夠高就高興的工程師?還是一個滿肚子主意，極其討厭產(chǎn)品經(jīng)理告訴他該做什么的“點子大王”?還是一個有些害羞、很多想法都憋在心里，但其實特別希望自己有存在感的人?
知道了他在乎什么，你才能知道怎么激發(fā)他的能動性，以及該讓什么人做什么樣的項目。
● 想升職的工程師肯定喜歡做老板能看得見的項目，哪怕這些項目沒有多高的難度，幫助這些工程師在老板面前"出出風(fēng)頭”，他們肯定對你死心塌地。
● 技術(shù)宅？那你就給他們強調(diào)一下，這個項目的哪些技術(shù)問題是其他工程師想想就頭疼、根本解決不了的，滿足他們的虛榮心。
● “點子大王”?那就找機會表揚他的點子又多又好，就算這個想法是你先想出來的，你也可以在和他交流時循循善誘，引導(dǎo)他說出你的想法，然后贊嘆他的想法真厲害。
比如，如果你認(rèn)為應(yīng)該在視頻平臺上做一個讓用戶發(fā)彈幕的功能，不要直接和”點子大王”說:”你負責(zé)做彈幕”?，而是要從問題出發(fā)，你可以說”我們的視頻互動性太差，用戶都不喜歡發(fā)評論”，然后引導(dǎo)他說出做彈幕的主意。
● 至于害羞的工程師，你可以在開會的時候刻意給他們表達自己的機會，他們絕對對你感激涕零，期待和你繼續(xù)合作。
知道工程師要什么，想辦法在現(xiàn)有的項目里給他們相應(yīng)的機會，會讓你們之間的合作事半功倍。至于怎么知道工程師要什么，你不如和他約個時間喝杯咖啡私聊一下，了?解他的個人情況，你甚至可以直接問他:”你是如何決定自己做的事情有沒有價值的，你在乎的是什么?”
第二，產(chǎn)品經(jīng)理應(yīng)該知道怎么和工程師溝通最有效率。
很多工程師最討厭的就是開會，因為30分鐘的會議打斷了他們的思考時間，拖慢了他們寫代碼的進度。
所以作為產(chǎn)品經(jīng)理，雖然你每天要花很多時間在開會上，但是要考慮一下這個會到底有沒有必要讓工程師參加，可不可以安排到這個工程師其他會議之前或者之后的時間，這樣盡量少地打斷他們的思考，以便于他們有效率地編程。
你還需要思考，除了開會之外，還有沒有其他可以高效做決定的方式，比如發(fā)個郵件。
第三，產(chǎn)品經(jīng)理要弄清楚什么決定需要自己領(lǐng)導(dǎo)大家做，什么決定可以放心地交給工程師們自己做。
比如，某個按鈕是100像素還是120像素，類似這樣的決定，是不是可以讓工程師和設(shè)計師自己決定?
很多產(chǎn)品經(jīng)理常犯的錯誤是，自己做出所有的決定，和工程師交流時只是要求他們按照指定要求來做，但實際上有些要求根本就不切實際。更或者，?按鈕是100像素還是120像素，可能對于產(chǎn)品的成敗來說，并不是最重要的決定，你完全沒必要在這種決定上花時間。
還有些產(chǎn)品經(jīng)理只告訴工程師要做什么，從來不解釋產(chǎn)品的目的、成功的標(biāo)準(zhǔn)，工程師完全不知道這些決定背后的策略和思考過程，結(jié)果就是事事都需要產(chǎn)品經(jīng)理告訴他們要怎么做。
其實，一個好的產(chǎn)品經(jīng)理一定會清晰表達產(chǎn)品要解決的問題、如何衡量成功、需要最先解決的用例以及原因，讓產(chǎn)品團隊的工程師、設(shè)計師、數(shù)據(jù)科學(xué)家等都有足夠的背景信息。這樣，?很多的小決定完全可以讓團隊成員自己做，從而既可以大大提高產(chǎn)品效率，又可以提高團隊成員的能動性。
當(dāng)然，這并不是說產(chǎn)品經(jīng)理什么決定也不用做，一個優(yōu)秀的產(chǎn)品經(jīng)理，會確保自己的時間花在”非我不可”的事情上,其他決定都會交給他人。設(shè)想，如果一個產(chǎn)品經(jīng)理把每天的時間都花在解決按鈕是100像素還是120像素這種問題上,他們哪還有時間去和客戶做一對一交流、制定產(chǎn)品戰(zhàn)略、思考"腦洞大開”的新功能。
第四，產(chǎn)品經(jīng)理應(yīng)該幫助工程師解決開發(fā)過程中的一些困難。
很多工程師在開發(fā)過程中會遇到一些困難，比如因為其他組工程師進展緩慢而導(dǎo)致開發(fā)工作停滯，因為開發(fā)的新功能被律師認(rèn)為風(fēng)險太大而面臨一些質(zhì)疑，?等等。因此，產(chǎn)品經(jīng)理應(yīng)該積極詢問工程師:“你需不需要我為你提供一?些幫助”?，幫助工程師解決開發(fā)過程中遇到的障礙。
因此，幫助工程師掃清開發(fā)路上的各種障礙，可以提升你的產(chǎn)品開發(fā)效率，而這正是優(yōu)秀的產(chǎn)品經(jīng)理需要做的事情。??比如，我常常對工程師說:“現(xiàn)在有哪些?工作是你不喜歡做的，告訴我，無論是臟活累活，我來幫你做”。其實，這也是一一個幫助你和工程師建立信任關(guān)系的過程。
怎么催工程師加快進度?
這個問題是很多剛?cè)胄械漠a(chǎn)品經(jīng)理最擔(dān)心的，我的建議是，讓工程師先自己估計需要的工期,然后再設(shè)定截止日期。如果他們預(yù)估的工期太長，我可能會提出一些問題，弄清楚為什么需要這么長時間，看看哪些部分可以砍掉，到底值不值得為截止日期砍掉這些功能。
工程師估計完自己需要的時間后，我會和工程師說明我們的發(fā)布計劃，比如某月某日營銷團隊會開始宣傳產(chǎn)品功能、某月某日我們需要開始運營工作等等，這樣可以讓工程師了解其他部門的進度,增強他們的歸屬感。
剛?cè)胄胁痪玫墓こ處煿烙嫻て诘哪芰Ρ容^差，如果他們的工期估計得太長，我就會想方設(shè)法讓他們告訴我工期是怎么估計出來的，然后跟他一起討論，哪些部分可以用現(xiàn)成的API，哪些部分可以少花些時間。
如果遇到確實要將截止日期提前的情況，我會告訴工程師需要提前的詳細原因。這樣做的目的是，讓工程師覺得你和他是一起的，讓他感覺到你的信任、你在思考如何一起解決I期提前的問題。
所以，我一般不會直接說要花多長時間，而是讓工程師先估計工期，如果我覺得估計得過長，我會誠懇地告訴他我們需要加快進度，看看有沒有什么方式能夠重新組合一些計劃，?以加快工期。
在這里，一定要讓工程師覺得自己是有掌控權(quán)的，而不是產(chǎn)品經(jīng)理一拍腦袋，就決定個截止日期。就算這個截止日期是你自己拍腦袋決定或者老板要求的，在表達日期的時候也要盡量體現(xiàn)出對工程師的尊重,用問問題的形式表達自己的看法，積極地和工程師一起尋求提前工期的方式。
產(chǎn)品經(jīng)理常見的棘手問題：需要改需求怎么辦?
改產(chǎn)品需求是一個非常常見的過程，有些時候前期計劃做得很好，開始Beta測試時卻發(fā)現(xiàn)，用戶對某個功能根本不理解，還是需要改動。
其實，開發(fā)本來就是一個不斷迭代的過程，所以應(yīng)該首先認(rèn)識到，產(chǎn)品開發(fā)不是產(chǎn)品經(jīng)理悶頭花幾個星期寫一個文檔，然后再拋給工程師讓他們按照這個文檔執(zhí)行的過程。
但是，改需求并不代表產(chǎn)品經(jīng)理可以在產(chǎn)品需求文檔上胡寫亂寫，做出一些不靠譜的決定，這是在浪費工程師的時間。這里我就跟你說說有哪些方式能夠避免在開發(fā)后期改需求，如果真的要改需求，如何和工程師有效溝通。
1.盡早和工程師進行產(chǎn)品功能設(shè)計的討論，讓他們提前了解各種背景信息。
我平時的工作方式是，先在產(chǎn)品需求文檔中寫明需要解決的問題、如何判斷成功，并寫幾個產(chǎn)品方案的初稿，和工程師、設(shè)計師們進行討論，回答他們的問題，讓他們一開始就參與進來。通過這個討論過程，我可以知道有什么技術(shù)上的局限性，然后根據(jù)大家的反饋修改產(chǎn)品需求文檔。這樣可以避免在工程師花費大量時間后才發(fā)現(xiàn)問題，然后重新來過，導(dǎo)致工程師做無用功。
2.如果確實需要讓工程師們重新寫已經(jīng)寫好的東西，或者砍掉他們已經(jīng)寫好的東西，一定要積極承擔(dān)責(zé)任。
這種情況，可能是因為你作為產(chǎn)品經(jīng)理少考慮了某些情況，也可能是突然發(fā)生了一些變故，比如公司改變了策略、競爭對手突然"搞事情”。雖然這并一定是你的責(zé)任，?但是這時你還是應(yīng)該積極和工程師交流，主動承擔(dān)責(zé)任，告訴他們:?"這個賴我，辛苦你了”。
其實很多時候，就算產(chǎn)品經(jīng)理自己主動承擔(dān)責(zé)任，工程師也不會“順桿爬”埋怨你，他們反而覺得你是個靠得住的好產(chǎn)品經(jīng)理，甚至?xí)^來安慰你。
積極承擔(dān)責(zé)任，說句”抱歉，辛苦了”，雖然對你來說就是一句話的事兒，但這可以很好地安撫已經(jīng)努力工作了一個月、每天加班加點兒的工程師。很多時候，給工程師們一些鼓勵和溫暖，雖然看上去微不足道，但卻能讓他們干勁兒百倍，對你死心塌地。
總結(jié)
最后，提煉一下今天的要點。
要做到和工程師的有效溝通，你作為產(chǎn)品經(jīng)理需要做到：第一，知道這個工程師在乎的是什么；第二，知道怎么和工程師溝通最有效率；第三，弄清楚什么決定需要自己領(lǐng)導(dǎo)大家做，什么決定可以放心地交給工程師們做；第四，幫助工程師解決開發(fā)過程中遇到的困難。
接下來，分享了怎么催工程師加快進度，以及怎么處理改產(chǎn)品需求這種常見的棘手問題，歸納起來不外乎這幾點：第一，盡早和工程師進行產(chǎn)品功能設(shè)計的討論，讓他們提前了解各種背景信息；第二，積極承擔(dān)責(zé)任，把過錯往自己的身上攬，而不要拋給工程師；第三，要讓工程師覺得自己是有掌控權(quán)的，而不是產(chǎn)品經(jīng)理一拍腦袋就決定了截止日期和產(chǎn)品的需求。
思考題
1.你的一個工程師鄙視你沒有工程背景，在做決定的時候并不信任你提出的建議，你該怎么取得他的信任?
歡迎大家在打卡區(qū)留言。
