工程師心目中的「頂尖產品經理」長這樣:邏輯強、即時反饋、尊重工程師意見

【我們為什麼挑選這篇文章】工程師跟產品經理如何搭配,才能「相親相愛」而非相愛相殺?

本文作者虞衛東,從工程師的角度提出專業的產品經理的特質,點出產品經理為趕火車,忽略許多細節的盲點,幫助工程師跟產品經理這兩類特別的群體,創造 1 加 1 大於 2 的雙贏局面。(責任編輯:鄧天心)

作者:虞衛東 公眾號:yudadanwx

上上週朋友圈被一個工程師和產品經理互噴、互毆,然後被解僱的事情洗版了,至於發生了什麼,其實並不重要,大家哈哈一笑,第二天可能就全忘記了。 我看完後,就在想, 一個產品經理怎麼把工程師激怒了

作為一個老工程師,我是經常慫產品經理的,有的時候都成習慣了,但我也見過很多厲害的產品經理。

今天談一談什麼樣的產品經理是優秀的(至少是我認為的),這篇文章也是心血來潮,帶有很多的個人情緒,說的也不全面,很多都是泛泛而談。 從四方面簡單談一談,如果將來有機會,再做進一步細化闡述。

一、專業性

任何一個崗位都有其專業性,一個產品經理即使溝通能力不佳,協調能力不強,但只要專業能力足夠擅長,也會受到工程師的尊重。 那專業性體現在哪兒呢?

一個需求不管多小,也應該有完整的產品需求文檔(PRD),代表產品經理的嚴謹性,以及對這個需求的深刻理解(即使需求錯誤也是可理解的)。

產品需求文檔形式不一定需要標準的形式(畢竟不是論文),如果需求文檔格式很完整,但空空無物又有什麼用呢?

需求文檔可以有自己的個人風格,只要足夠嚴謹,能讓工程師看懂即可。

a. 具備原型圖設計能力

對於工程師來說,很難有耐心仔細看需求文檔,他們更喜歡「動態」的原型圖;對於產品經理來說,為了理順自己的思路,思考需求的合理性,最好的校驗工具就是畫原型圖。

所以不管從哪個角度來看,產品經理應該學會一種原型圖設計軟件,比如:Axure

原型圖是對產品需求文檔的一個有效補充,從不同維度完善項目需求,極具立體性。

b. 邏輯性

這是非常關鍵的一個能力,產品經理將用戶的需求轉變為產品需求,文檔最重要的就是邏輯正確,經常和一些產品經理開會,發現他們自己都無法將需求理順、也無法說服自己、無法應對質疑,即邏輯性存在很大的問題。

如果一個產品經理存在邏輯性較差的問題,那就要好好修煉內功了, 如果無法洞悉用戶的真正需求,會給公司產品帶來萬劫不復的災難 ,但也從另外一方面體現了產品經理的重要性。

c. UI 審美能力

我發現很多優秀的產品經理都會畫畫,他們也會 UI 設計,即具備很強的審美能力,知道頁面風格的重要性,或者說這些產品經理的聯想、發散能力是極強的,這也是他們專業能力的體現。

而對於工程師來說,這方面可能就是白痴,他們只關心邏輯思考能力,反向說明產品經理是要求非常高的一個崗位。

d. 溝通能力

產品經理在大家看來是一個萬花筒, 溝通能力、協調能力非常重要,為什麼沒有提及?

其實任何一個行業, 任何一個崗位這些能力是必須的,沒有必要強調

這篇文章完全以我的視角解讀優秀產品經理的判斷標準,極具個人色彩,可能存在極大的偏向性。

二、熟知開發流程

產品經理的專業性不可能一步到位,需要慢慢積累才能成長,但對於一個剛入門的產品經理來說,理解項目流程非常重要,否則就像蒼蠅一樣,不知道要幹啥好,到處碰壁,四處吃虧,變成工程師眼中的一個傻子。

a. 了解各個崗位的職責

在網路公司,分工是非常細化的(尤其是開發人員),一個具有一定規模的公司,有系統開發人員、應用開發人員、前端開發人員、客戶端開發人員、數據分析人員、系統運維人員、應用運維人員。

而且這些崗位人員之間的職責還可能交叉, 如果產品經理不了解這些崗位的區別,出現問題或者提需求找不到正確的人,那就非常麻煩了 ,會極大減少積極性,也會讓人疲憊不堪。

所以產品經理平時要多留心,找到解決問題的合適人員。

b. 測試的重要性

大公司有專門的測試崗位,但不代表產品經理能夠忽視它 (很多產品覺得自己怎麼成為測試人員了,這也是他們的吐槽點之一,覺得沒有時間幹自己的專業了)。

此處我要強調冒煙測試(Smoke Testing)的重要性,很多開發人員由於多方面的原因,匆匆忙忙完成某個項目,然後將其部署。 符合預期嗎?

冒煙測試是校驗預期最好的手段,對於產品經理來說,自己進行冒煙測試,也能以用戶的角度體驗產品功能,進一步思考合理性。

所以說產品經理一定要明白測試的重要性,也要熟知測試的流程。

c. 郵件確認機制

很多產品經理和開發人員平時好的就像親兄弟、 親姐妹一樣,項目進度不出問題的時候還好,出現問題的時候就非常尷尬了,產品經理是第一責任人了,也就是說一個項目從構思到上線,甚至到跟踪。

產品經理必須全程關注,盡力確保項目上線,其中郵件確認機制就是非常重要的一個點,在關鍵節點一定要發郵件周知相關人員,一方面是匯報進度,另外一方面也給工程師提一個醒。

對於非功能需求的把握,非功能需求包括性能、擴展性、可用性等技術指標,雖然這些更應該由工程師關心,但產品經理一定要明白此中的道道,它也是產品開發過程中非常重要的一環, 產品經理有必要、有義務提醒工程師

d. JIRA 跟踪機制

產品或功能上線後,產品經理要及時獲取用戶的反饋,包括用戶遇到的問題、建議,可以通過 JIRA 長期跟踪,要協助程序員一起分析問題,這樣才是一個善始善終的優秀產品經理。

TO 編按:

JIRA 中文為「缺陷跟蹤管理系統」,為針對缺陷管理、任務追蹤和專案管理的商業性應用軟體。

三、不要讓工程師討厭你

對於產品經理來說,讓工程師尊敬你非常重要,那麼如何做到呢?

一方面是提升自己的專業能力,另外一方面就是少做龜毛的事情。 尤其工程師的性格非常直接,惹惱他們後果很嚴重,所以某些細節一定要留意,至少對我來說,下面的十個情況要盡量避免。

a. 不要用嘴代替需求

有些產品經理腦子裡冒出個想法,一拍腦門覺得自己就是個天才啊,趕緊讓工程師去開發吧,就吧啦吧啦跑到工程師面前,說你開發這個功能吧,接著又語無倫次的描述了所謂的需求。

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

這是一種非常不負責任的行為,久而久之會讓工程師非常反感,所以一定要切記。

b. 工程師的監工

有些產品經理好像保姆一樣,就怕工程師不主動,怕工期來不及,每天趴在工程師後面,盯著他們開發代碼,好像監工一樣。

這種行為讓工程師特別不自在,他們有自己的工作方式,不寫代碼不代表不在工作,他們大腦在後台飛快的思考著,當然要是一個美女產品經理跟在後面就另當別論了。

另外有些產品經理喜歡陪工程師加班,我覺得這種形式也非常不好,只要把需求提清楚了,沒有必要好像虧欠什麼的,不一定要用陪同這種形式來支持工程師。

c. 2/8 法則不可違

有些產品經理要求特別嚴謹,但工程師也有難處,比如:某個功能暫時確實不好實現,問產品經理能不能變通一下,將需求弄簡單一點。

傻逼的產品經理可能就較真了,說不行,一定要按需求做,此時矛盾就無形中產生了,實際上正確的做法就是問自己: 我核心的功能完成了嗎? 捨棄的功能影響全局嗎?

如果不大,確實可以尊重工程師的意見,將 20% 的核心時間花在重要的事情上,等後續有時間了再完善,這種做法是毫無問題的。

產品經理要有極強的辨識能力,明白一個項目的核心功能是什麼,不要太拘泥小節。

d. 討論變成需求

經常遇到這樣的場景,產品經理出了一個需求文檔,然後大家開會討論,開會過程中產品經理的想法被無情的批判,自己也毫無主見了。

然後大家互相出主意,工程師也很開心,產品經理也很滿意,因為開會討論出了需求,工程師不會龜毛到反駁自己提出的意見吧,在某種程度上這是一種好現象, 實際上我不提倡這種方式

無情的被人反駁,只能證明產品經理思考不成熟,是自己專業能力不強的一種體現。

作為需求方,需要捍衛你的想法,如果輕易被撼動,只能證明自己還要加強學習,說的難聽一點,只要能說服自己,有的時候要堅持自己的想法和需求(和固執是兩碼事)。

e. 你不是開發人員

有些產品經理比工程師還工程師,動不動就幫技術人員想解決方案,說這個應該這麼弄,設計方案會不會有性能問題啊,時時刻刻顯示自己的邏輯能力。

俗話說術業有專攻,我希望產品經理 不要從工程師的角度去思考問題,而是以用戶的角度去思考問題 ,提出需求,實現是工程師的事情。

如果工程師覺得實現有問題和麻煩,必然會找你,如果你能聽懂、且贊同,那麼工程師會覺得你是​​在幫助他,這才是正確的做法。

在我漫長的職業生涯中,我遇到很多懂 Code 的產品經理,他們邏輯能力比我強多了,但從 不喧賓奪主 ,只在我為難的時候提出一些建議,讓我受益匪淺。

反而是一些毛都不懂的產品經理,天天給我秀智商。

f. 需求是否合理

本文開頭說的那個故事,就是需求不合理導致的,產品經理一定要注意這一點,不要站在自己角度出發的,而是站在用戶角度,需求不能想當然,多想想功能是用戶需要的嗎? 千萬不要做無用功,不要亂提需求。

有的時候我總有這種感覺,啥也不做比瞎做至少還能節省人力,不浪費公司資源。

產品經理也不要動不動就說這是上級要的功能,和我無關。

其實應該這麼想問題:上 級可能有一個想法,其中也許 80% 不可取的,而產品經理要做的就是將 20% 可取的部分強化,以此提出一個合理的需求

g. 什麼時候完成

有的時候產品經理剛把需求發給工程師,或者開會剛討論結束,就迫不及待問啥時候能開發完成,上級急著呢。

有的時候還會抱怨這麼小的一個改動就要 2 天? 或者說這個開發很簡單吧?

這是一些非常不專業的做法,軟體開發有其自身的規律,需要設計、架構、打 Code、測試、部署等多個過程,是要求非常高的一個過程。

所以千萬不要一上來就要開發時間,很容易讓人反感。

更好的做法就是 問他們什麼時候能評估出開發工作量(包括分析、設計),然後在郵件中周知,為避免工程師遺忘 ,可以提前詢問一下。

如果和某個工程師熟悉了,了解他的風格,可以採取一些策略來推動項目,切記不要動不動就問什麼時候完成開發。

h. 我只管提需求

這一句話的下半句其實就是「其他我不負責」,在網路企業, 產品經理其實包含項目經理的角色,對於一個高速發展的企業來說,不可能按部就班的工作

而推進器其實就是產品經理,他們需要把握整個項目進度,不要認為僅僅提需求就行了。

程式碼是開發人員開發,推廣也是運營的事情,產品經理本質上就是指哪兒打哪兒,和設計人員溝通、接受運營人員的需求、給銷售人員數據、給工程師提需求、給測試人員寫測試用例、給用戶解答。

i. 找上級

有些產品經理是急性子,一看工程師不配合,或者進度趕不上,就說找技術總監,好像找了就能解決問題,有的時候也有點欺負人的感覺。

可實際上最終配合你的還是這些工程師,這和接下去要講的人治非常類似。

我建議產品經理少拿這個殺手鐧,有的時候它還不一定管用,和工程師應該永遠報以合作的態度,合作不順的時候,可以和工程師交交心,互相交流下想法,這樣才有可能解決問題。

j. 缺乏反饋機制

一個產品功能上線後,如果反響比較好,產品經理當然覺得都是他們的功勞,這也無可厚非,可如果不好呢?

產品經理應該分析問題,思考是否需要優化它,也可以和工程師一些討論,共同想辦法。

但大部分產品經理卻毫不關心,好像根本就沒有這功能一樣,這種做法非常讓工程師寒心。

工程師就會覺得你們也既不不開發程式碼,也不關心項目的結果,長此以往,這樣的產品經理會失去工程師的信任

k. 人治而非法治

任何一個行業,人與人之間的關係是必不可少的,對於工程師和產品經理來說,他們之間的溝通是最多的,也是關係最密切的人,相處融洽才能將工作做好。

關於如何相處是一門藝術,可以看專門的一些數據,我從自己的角度出發,簡單列幾點。

l. 理解工程師

工程師是非常獨特的一類人群,性格可能和常人不一樣,但都非常感性,有的時候也會口無遮攔,甚至熟悉後還和你發脾氣。

但大部分情況下,他們都非常純真,沒有太多的心機。

對於產品經理來說,面對工程師的各種莫名其妙的表現,一笑而過,大度一點,多想想他們的優點,盡力成為朋友,這是將工作做好的先決條件。

當一個產品經理進入新公司後,一定要仔細觀察各個工程師的性格、特點,針對性下藥,有策略的和他們融入在一起

但需要注意的是,不是讓產品經理忍讓他們,這也不是好策略,只是要盡量避免針鋒相對。

m. 認同工程師

工程師不僅僅是開發代碼,他們邏輯性強,思考問題全面,作為產品經理,要善於合作,尊重他們的觀點,多聽聽他們的意見。

千萬不能說「這是需求,趕緊實現吧,其他的不用問」這樣的話。

而是讓工程師發表意見,比如說:「你覺得怎麼樣設計比較好一點」、「幫我看看邏輯是不是正確」, 讓工程師間接成為一個產品經理 ,讓工程師意識到他們的重要性,意識到他們是設計者,而非僅僅是構建者。

當一個項目結束後,要多向他們反饋,反饋包括用戶的反饋,也包括產品經理的自我批評。

當項目結果不是很好的時候,也要及時和工程師反饋,反思失敗的原因,這樣才能讓工程師意識到「這個項目的背景原來這麼複雜啊」。

他們也會從內心接收這一切,如果總是沒有反饋,工程師會說「產品經理又做了一堆垃圾」。

n. 目標一致性

面對一個項目, 真正推動項目的動力不是產品經理的催促,而是讓工程師和產品經理目標達成一致 ,對於核心項目來說,他們一致目標就是「這項工程關係到公司的生死存亡,所以必須加油」。

那一般性的項目呢?

即使不重要,產品經理也要有極大的感染力,讓工程師意識到「我在做一件有價值的事情」,只有雙方目標是一致的,項目才能飛快往前走。

目標一致性來源於工程師對產品經理的感受,如果你足夠職業,足夠專業,是很容易感染工程師的。

o. 有自己的人格魅力

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

公眾號:yudadanwx

 

作者 虞衛東 新書 〈深入淺出 HTTPS: 從原理到實戰〉:
https://www.tenlong.com.tw/products/9787121341786

__

(本文經公眾號 yudadanwx 授權,並同意 TechOrange 編寫導讀與修訂標題,原文標題為 〈程序员:我心目中的优秀产品经理 〉,圖片來源:YouTube。)

延伸閱讀

在矽谷最搶手的工作不是工程師,是台灣最不重視的「產品經理」

【投稿】為什麼台灣人會以為自己不需要「產品經理」?

從菜鳥到經理,PM 的職涯發展路徑以及「技能樹」該怎麼點?


邊緣運算的應用可行性在人工智慧技術演進下快速演進
台灣應該如何從中挖出商機,看見未來?

10/12(五)9:30 ~18:00,南港展覽館 504 會議室
把握數位轉型升級關鍵要素

立即購票

點關鍵字看更多相關文章: