產品經理如何贏得程序員的尊重和支持?
問題:好多技術覺得PM可有可無,甚至無勝于有,因為他們覺得:事兒都是我們干的,自己不會干還指揮我們干,還嫌我們干的慢 ……
回答:先肯定一個前提,你作為PM,你的工作你的決策你的制衡你的項目行為都是為了讓項目按時按量更好更快完成。所以不論對項目團隊還是虛擬團隊的控制,都應如此。當然特定環境下你可能要考慮立威、拉攏、人際制衡等項目之上的問題。但若沒有,請不要熱衷于斗爭,你不是來尋求尊重的。
不說PM的職業技能,只針對團隊管理說幾點:
了解美術/前端/后端工作原理。
如果你知道美術設計主菜單懸停二級的不規則投影會浪費前端大把的時間調試,你還能想像前端看到了多難過,你就及時建議改用規則統一透明度的投影。如果你知道后端用for循環輸出20條左右結構的新聞列表,你就讓前端用css控制自動左右布局,而不是左右拆成兩份。他們去到其它團隊時,會懷念你的。
給團隊成員足夠的信息和空間。
這三個職業都不是工具,尤其后端攻城師。再初級的程序員也會向往人月神話,他們能為你提供合理的高效的架構設計。你要給予他們足夠多的信息,給他們留出恰當的時間,讓他們完成合理的架構。前后端工程師大多對復用和高性能保有成就感,你盡可能提供多的信息,由他們來處理。這也是為他們后期維護和迭代提供便利,你不要有所保留!如果你真的思維不縝密,藏不住的,最后連朋友都交不成。
勇于溝通和學習。
工程師跟你說以后用velocity來編輯頁面,你不理解,那么就問。如果他鄙視你,那么是他的問題,也可能是你的問題。大多數工程師愿意給你講解的,他們也害怕表達,這是雙方的修為。如果工程師說必須從mysql換成oracle了,你問為什么,他說無法承載了,你問要多久,他說要兩周,你崩潰了但是問為什么,他說要寫數據轉換腳本,你問為什么,他說兩個數據庫之間數據類型不同需要有一些轉換,索引規則也不同,你問什么是索引……這都是可以的,你要帶著學習的心態而不是問責,否則他越答越反感。最后你若懂了,他會覺得你理解他。
小心處理需求變更。
這是個永恒的話題,出了各種凡客體愛情買賣體來鄙視需求變更。你可以坦誠表達:需求變更是難免的,是不斷探索和調整而來的,作為PM我自認無法一次性想到最好,很抱歉。接著就是技巧活了,原則是盡可能避免反復修改。如果有一個頁面的數據呈現,你無法想象怎樣更好,你可以用chrome開發者工具先去調整查看,別直接讓技術修改并當作你的參考。如果你不會用工具可以去學,實在復雜你就懇請技術輸出兩份效果給你比對,而不是改了說不好再改回去。第二點就是,如果有的數據呈現模塊要裁剪,但有可能日后換個形式換個地方呈現,你就要跟技術說明白,讓他只是注釋暫時隱藏。你不知道一個簡單的數據呈現它用了緩存還是別的什么。
成就感是你能給予的共鳴。
你要知道各位同學都在意什么,物質需求可能你無法給予,吃個飯之類的其實是順理成章,不必刻意。各位同學踏入互聯網江湖,大多想在各門個派混出個名堂。如 果你有機會,不要吝嗇這樣的稱贊。代碼注釋,產品主創介紹,向上匯報各同學的技術成果,鼓勵同學往各渠道分享技術心得。同時適當認同各位在架構性能上的新想法新思路,包括交互體驗上也應該給前端人員發揮空間如果他們愿意。其實最根本的,你要熱愛產品并竭盡所能,產品的受眾范圍和影響力是個天然的成就感。
勇于擔當
你多承擔一些考核壓力和物質壓力,同學們才能更有精力投入到工作中。同為打工的你,能做的不過如此了。特別是當項目失敗時,怎么可能跟你沒關系,該推的不該推的都不該推,早干嘛去了?若出現項目成員能力問題和態度問題,盡早反映,說按此下去結果最好只能如何,把問題丟給你的頭。那么他要么換掉你,要么換掉該成員。
本文由@邊緣 整理自知乎問答,轉載請注明來源于人人都是產品經理并保留原文鏈接
#非技術出身產品經理的技術溝通秘籍#
15天補齊程序/代碼、前端、后端、數據庫4大模塊基礎技術知識。助你日常溝通更順暢,產品設計不挖坑!
詳情戳>http://996.pm/7daXE 或咨詢起點學院蘑菇(wx:qdxymg)
感覺有點跑題了。。。說服力好像不是很強。