產品經理(PM):該怎么樣贏得技術人員和前端人員的尊重

6 評論 10188 瀏覽 68 收藏 17 分鐘

  

  產品經理如何贏得開發人員的尊重和支持?

對于產品經理來說,贏得開發人員的尊重和支持,從某種意義上講,是產品邁向成功的堅實一步。最近,知乎社區上的開發人員和管理者在前、后兩個帖子中對此展開了激烈的討論,其中不乏真知灼見。

林志霖Cray認為產品經理的決策和行為都應該為項目的目標服務,不要熱衷于斗爭,團隊管理值得注意的幾點包括:

了解美術/前端/后端工作原理。

如果你知道美術設計主菜單懸停二級的不規則投影會浪費前端大把的時間調試,你還能想像前端看到了多難過,你就及時建議改用規則統一透明度的投影。如果你知道后端用for循環輸出20條左右結構的新聞列表,你就應該讓前端用CSS控制自動左右布局,而不是左右拆成兩份。

 給團隊成員足夠的信息和空間。

這三個職業都不是工具,尤其后端工程師。再初級的程序員也會向往人月神話,他們能為你提供合理的高效的架構設計。你要給予他們足夠多的信息,給他們留出恰當的時間,讓他們完成合理的架構。前后端工程師大多對復用和高性能報有成就感,你盡可能提供多的信息,由他們來處理。這也是為他們后期維護和迭代提供便利,你不要有所保留!如果你真的思維不縝密,藏不住的,最后連朋友都交不成。

  勇于溝通和學習。

工程師跟你說以后用velocity來編輯頁面,你不理解,那么就問。如果他鄙視你,那么是他的問題,也可能是你的問題。大多數工程師愿意給你講解的,他們也害怕表達,這是雙方的修為。如果工程師說必須從MySQL換成Oracle了,你問為什么,他說無法承載了,你問要多久,他說要兩周,你崩潰了但是問為什么,他說要寫數據轉換腳本,你問為什么,他說兩個數據庫之間數據類型不同需要有一些轉換,索引規則也不同,你問什么是索引……這都是可以的,你要帶著學習的心態而不是問責,否則他越答越反感。最后你若懂了,他會覺得你理解他。

 小心處理需求變更。

這是個永恒的話題。你可以坦誠表達:需求變更是難免的,是不斷探索和調整而來的,作為PM我自認無法一次性想到最好,很抱歉。接著就是技巧活了,原則是盡可能避免反復修改。如果有一個頁面的數據呈現,你無法想象怎樣更好,你可以用Chrome開發者工具先去調整查看,別直接讓技術修改并當作你的參考。如果你不會用工具可以去學,實在復雜你就懇請技術輸出兩份效果給你比對,而不是改了說不好再改回去。

第二點就是,如果有的數據呈現模塊要裁剪,但有可能日后換個形式換個地方呈現,你就要跟技術說明白,讓他只是注釋暫時隱藏。你不知道一個簡單的數據呈現它用了緩存還是別的什么。

  成就感是你能給予的共鳴。

你要知道各位同學都在意什么,物質需求可能你無法給予,吃個飯之類的其實是順理成章,不必刻意。各位同學踏入互聯網江湖,大多想在各門各派混出個名堂。如果你有機會,不要吝嗇這樣的稱贊。代碼注釋,產品主創介紹,向上匯報各同學的技術成果,鼓勵同學往各渠道分享技術心得。同時適當認同各位在架構性能上的新想法新思路,包括交互體驗上也應該給前端人員發揮空間如果他們愿意。其實最根本的,你要熱愛產品并竭盡所能,產品的受眾范圍和影響力是個天然的成就感。

  勇于擔當。

你多承擔一些考核壓力和物質壓力,同學們才能更有精力投入到工作中。同為打工的你,能做的不過如此了。特別是當項目失敗時,怎么可能跟你沒關系,該推的不該推的都不該推,早干嘛去了?若出現項目成員能力問題和態度問題,盡早反映,說按此下去結果最好只能如何,把問題丟給你的頭。

 流浪貓則舉了一些親身經歷的反面教材:

彈性上班,拍板的事情經常找不到人。

前任上司自己首先實行彈性上班制度,下午才來,技術經理經常都找不到他,我們也不敢去拍板。就算問題是解決了,技術也會覺得你一點都不緊張項目(產品)。連自己的孩子都不緊張,誰替你去緊張。

 前端做到想吐也要做。

跟前任上司討論關于項目的問題(我的意見是第一版不用做得太精美,以后可以迭代上線,他的意見是第一版就要做到很出眾,以便日后更好地請求資源)。上司跟我談到他以前的經歷:他說在以前公司做,他們策劃出的效果有N種情況,由于策劃出來的時間點比較靠后,導致前端切圖切到想吐,最后還是如期上線,勸我不要太過于考慮實現方面的問題。當時我就想,就為了那些效果而把別的同事搞到想死的感覺,值得么?效益與成本對比如何?你咋知道那些效果就是好的?或者是壞的呢?反正到最后,那期的項目還是有各種效果,同時也讓設計加了三周的班,技術到最后上線的時候,連續做到第二天早上(第二天是公司年會)。

  技術加班,產品跑去吃飯。

在上線deadpne,前任上司跑去跟人吃飯了(交代下背景,在策劃期間,他經常都出去吃飯看電影,我跟另外一位策劃都只是出去過幾次,周六日都在做),而技術兄弟姐妹都在修復bug。我跟另外一位策劃不斷在檢查,有問題馬上反饋修復。某經理晚上十點回來,我立馬就訓斥他一頓:人家技術都在為我們的項目而加班,晚餐是吃餅干、喝汽水,你還出去吃飯?太說不過去吧?被我訓斥了一頓,某經理就馬上搞了個麥當勞外賣,還算是將功補過。后來我再提出,要讓某經理自己出錢給技術搭的士。

  項目失敗了,沒有后續的反饋。

我的個人意見,就算項目失敗了,作為項目或產品的發起人,都需要跟大家講清楚情況(特殊情況除外),在最后總結一下。然后在請大家吃飯啊什么都好,畢竟大家都是為了項目認真努力付出過的,就算失敗,也要慰勞一下。

吳偉以其7年的PM經驗來看,說服他人,特別是研發、設計、前端這些研發部門的同事,最重要的不是口才、溝通能力和數據,而是專業。專業就是:第一,你要用內行的思維方式、表達方式和處理方式來思考、溝通和執行;第二,你要經??梢宰龀稣_的決定。 他介紹了幾個小技巧:

  盡量說術語。

在我們與研發人員溝通的時候,盡量不要說大白話,而是使用術語。這樣會讓人家感覺我們很懂技術。例如有一次我和一個客戶端工程師說:”我希望彈出的窗口是模態的。”工程師聽完后很詫異的說:”你還知道模態?”我說:”當然啦,這對交互設計很重要啊。”于是工程師立刻就把窗口改成模態的了,根本沒問我為什么。那么什么叫模態呢?用大白話說就是彈出一個窗口,窗口以外的地方都是黑的,或者不可以操作,只有這個窗口可以操作,類似于Windows里面經常彈出來的討厭的錯誤提示。但是你要是跟工程師這么描述,碰上脾氣好的說不準幫你改改,碰上不好的準保反問一句:那多討厭啊,我就討厭Windows彈錯誤提示。

思維要周密,在說話之前要盡量把所有可能的情況及其解決方案想清楚。

比如你要修改一個按鈕的位置,人家自然要問你,空出來的位置怎么辦,改過去之后會不會影響現有的功能,用戶能不能習慣等等,如果你能胸有成竹的一一化解,別人自然會聽從你的建議。

 讓對方自己得出結論。

人都是有自尊心的,都希望自己的決定是正確決定,如果你總是說:”你這樣是錯的,我是對的”必然引起別人的反感。所以你可以先把遇到的問題擺出來,在提出自己的解決方案后立刻說:這方面你是專家,如果你覺得這個方案能用就用,如果有更好的方案我也沒什么意見。人嘛,通常都是比較懶的,既然你能提出一個還算說得過去的解決方案,而且又讓對方覺得是他自己的選擇,通常也就不會為難你了。

看人下菜碟。

不是對每個都用同樣的話說服的,人和人都有所不同。以我的經驗,對待工程師、設計師、老板是不同的。對待工程師要有條理,邏輯要清晰,講究數據。例如:方案1會造成數據服務器負荷過重,并發量在2萬/秒以上,并且至少要占用10g的儲存空間,最重要的是,我們付出了這么大的代價,其實只滿足了20%的用戶,而且這部分用基本上都是不付費的用戶。這一大套話說完,研發人員會認真想一想:也是啊,萬一服務器宕機了責任就大了,還是用方案2吧。對待設計師要以情動人,因為設計師一般都是學美術出身的,特別感性。例如:大姐,你就給我改改吧,為了畫這個原型我昨天都加了一宿班了,你今天不改,明天指不定又插進來什么活兒呢,我這個項目得什么時候上線啊。再說也不是我想改啊,是銷售那邊兒一會兒說用戶喜歡這個,一會兒說用戶喜歡那個,我們也擰不過他們啊。設計師一聽,都是同事,誰還沒個難處啊,得了,加班兒給人做了吧。對待老板要學會畫藍圖,例如:根據競品研究的結果看,這個產品非常有前景,XX剛上線1個月,就已經有100萬用戶,10萬同時在線,收入也差不多有400來萬。我們在技術上、渠道上、政府關系上都比他們強,我覺得只要能夠在2個月內推出,各項數據肯定比他們強。更何況,我們的產品線目前缺乏的就是用戶沉淀,而這個產品正好提供了強大的社交功能,彌補了產品線的空缺。老板一聽,小伙子想的挺清楚啊,成,給你兩個工程師,一個設計師,1萬塊項目獎金,1個月給我做出來。業績好的話再給你發年終獎。

 人格魅力。

做人要有幽默感,要學會緩和氣氛。沒必要每次需求討論的時候都板著臉訓人。說說笑話,插科打諢,給設計師倒杯水,給工程錘錘肩,送給運營的小姑娘幾塊兒巧克力,給運維的同事買幾瓶水。你平時這么注重積累,在你需要的時候別人自然不會為難你。能做的就做了,不能做的睜一眼閉一眼也就做了。

 Hexybaby的經驗總結包括:

盡量在需求確定后再提交開發,需求變更要給出充分的理由。

隨時準備著,并盡量用最短的時間為技術解決任何非技術問題。例如部門間協調、文檔和素材的準備。

言之有物,不要說空洞的片兒湯話,一針見血、思路清晰的描述需求。

謙虛和威信并存,不懂就問,虛心接受技術提出的產品意見,但原則問題不妥協。

關於如何建立與攻城師的良性合作關係,大家已經說了很多,我就不再贅述了。

想補充一點,要解決別人對你定位的疑惑,首先要解除自己對自己定位的模糊。

作為產品首先要懂得自己的價值所在:

一、我們是推手

設計師是針,攻城師是線。沒錯,有針有線就可以織出錦繡河山了??墒?,如果沒有手,針和線是不會自己開動的。

二、我們也是針線

用戶表達著自己的需求,運營經營著自己的項目,市場開拓著自己的用戶,開發編寫著自己的代碼,每個人面前都有自己的一幅畫卷需要描繪,誰能在他們之間穿針引線、把他們各自的畫縫合成一幅完整協調的作品?那就是我們產品要干的活

三、我們和他們,其實是一母同胞的兄弟

十年前產品經理這個概念還幾乎不存在,或者僅存在於一些大型公司的內部。可是為什么今天產品經理越來越多的被提及,行業規模和文化越來越龐大。做產品的我們都應該懂得,有需求才有存在的可能。早期的個人站長們隻身就可以完成從需求管理、功能策劃、介面設計、代碼開發這些所有的事情,但是隨著需求和技術的不斷發展、細化,行業必然會趨於細化,因為不做細就無法做的更好。所以我們其實本就是從一個身體上分生出來的兄弟,只是每人繼承了身體的一個部份。我們的存在就是因為我們可以專心的做好我們的事,而讓別的兄弟姐妹可以專心做好他們的事。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 總結起來就是,怎樣做一枚能讓別人開開心心完成自己項目的產品經理

    來自北京 回復
  2. 說白了這篇文章的“產品經理”看上去是個“管理層”,可能不同公司對產品經理定義不一樣,有些公司的產品經理說白了就是一個“領導助理”,自己沒啥權利,最終還得領導拍板。在國內,哪有那么多正規的“產品經理”,甚至老板都不知道啥叫產品經理,做了很多事情,總覺得你沒做啥事情,拿錢不多,做事最多,還沒權利。。。

    來自北京 回復