程序猿如何「智鬥」產品經理

RD和PM的恩怨是歷年來有目共睹的,算法

每個項目迭代中,RD都是但願能獲得更多的「空閒時間」,這時間能夠養精蓄銳或是技術學習。 PM則但願可以盡最大效率使用RD,把本身堆着的那些prd都能最快落地,但願無論出現任何問題都別延期。 這也是形成了二者最直接的矛盾。 xcode

 

但每天重複類似的問題,有沒有通用的解決方案? 秉承多年與PM周旋的經驗下面主要從如下八點開始闡述微信

  • 求其上得其中函數

  • 合理的攢人情工具

  • 如何給PM施壓學習

  • 該正面交鋒時,毫不手軟spa

  • 先小人後君子code

  • 如何砍需求blog

  • 不應背的鍋不背遊戲

  • 工做同事和生活朋友角色轉換

 

1、求其上得其中

有的PM很是兇悍,說話好像沒商量似得, 這裏的緣由有幾個(級別高,或是上級拍板的重要需求,或是那廝最近幹了什麼自信爆棚的事,或是看不起大家RD以爲只能幹活),這種人就是很是討厭的,以爲好像只有他本身有產品思惟,其餘人都是棋子,估時必定要往多幾倍估,12天的需求 就估18天,他確定會縮時間,由於他確定不想吃虧,就是想壓榨大家。 有的時候讓你改3個需求,若是你以爲最多隻能改2個了,就先說全不改,討價還價以後讓你改1~2個。  這個求其上得其中 你們基本都有理解,具體不作贅述。

 

2、合理的攢人情

PM崗位換的比RD要勤,常常會有一些PM剛來不久心裏比較虛。

有時他明知道本身的錯誤(需求文檔哪裏寫的產生了歧義,或是漏了哪一種場景)想找你改需求。假如這個地方很好改,你眉頭一鎖(裝的很難的樣子),說:「哎,當時需求咋不早說,我等會晚上幫你改了吧」 或是 「哎,好吧,那我以前的幾個函數要推倒重寫了」。  其實可能就是一個if分支或是循環算法改下,PM會立刻說 謝謝謝謝... 多謝理解... 給你添麻煩了....  害得你要加班了...  我幹過一次,一個改動秒改,而後晚上我看開發文檔很晚才走,新來的PM膽小看咱們沒走也很差意思走,覺得我幫他改需求呢,每次見面都客客氣氣的。

 

3、如何給PM施壓

場景:PM在羣裏說:這裏咱們改爲這個邏輯了...  很明顯這是對咱們不利的,須要給他施壓讓他放棄。

方法一(揭竿起義)拉動本身組或是別的組的(好比安卓和iOS)都在羣裏回覆「臥槽,改不了啊!」 ,「根本無法改!」,「之前的多好,我都寫完了!」 PM看着羣裏一條條的刷屏不禁的菊花一緊...

方法二(嚇唬外行)「這樣改的話風險不可控!」,「這樣改可能會和咱們XX組件背道而馳,發生衝突」,「這樣改咱們須要重構了!」 (PM很懼怕「重構」這個詞) PM心想我也不懂啊,這麼嚴重啊,要不就算了...

方法三(事情鬧大)「這樣改須要發郵件抄送雙方上級周知一下」 ,PM心想我可不想驚動老大啊...  老大們若是看到個郵件都會覺得出大問題了

 

4、該正面交鋒時,毫不手軟

樓主有的時候也是被PM氣的無語了,那時候沒經驗,本身生悶氣一週。 這就比如於,大學裏有時誰和你爭吵說的很難聽,那時你也許是慫也許是當時腦殼卡殼,就認輸了,後來回頭想一想,無限後悔我當時真應該怎麼怎麼懟他。 對於PM我以爲也是,該交鋒時毫不手軟。 我建議「得理不饒人」的作法,只要你不理虧,必定要爲本身爭得最大利益。

有些人可能會問,PM也是同事也是要好好相處的,之後低頭不見擡頭見,鬧翻了很差吧? RD爲何老是這麼自做多情,大部分RD少言寡語,木訥。PM則是油滑,三寸不爛之舌。 你想和他好好相處,人家照樣當你是傻子。 其實咱們能夠利用咱們傻子的形象,全部玩過度了的事,說過度了的話 咱們均可以用 「咱們RD一直面對代碼比較呆,不會說人話,你們不要放在心上啊」 相似這種策略爲本身洗白減輕罪名,大事化小小事化了。 相反若是你當時認了慫,那加班12點改bug都只能賴你本身無能。

大媽和賣菜的討價還價說的面紅耳赤,這邊說菜不太新鮮,那邊說原料漲價了,互噴爭吵到最後買了菜,之後見面仍是樂呵呵,中間有來有往固然不是仇人啊。 和PM討價還價砍需求也是這樣,爭吵沒有你想的那麼嚴重。

 

5、先小人後君子

在開發前期和PM各類互撕絕不收斂...加需求一概不改...估時估的多...增長了細節還一概從新估時...PM哪裏漏了分支立刻提出讓PM丟臉...  一整個版本下來PM對你的仇恨值已經達到了峯值!! 而後等到版本正常發佈上線以後,你能夠主動和PM示好,安撫他,好比中午食堂吃飯的時候,誇他這個版本需求很贊;那幾張流程圖用什麼工具畫的這麼好看;你需求寫的很清晰我開發也很順暢。 又好比在版本總結會上,你們心情相對輕鬆,你能夠說咱們這個版本按時上線按時發佈毫無delay,PM們功不可沒!指揮若定啊!...

這樣一個版本下來你既沒累到,也沒受委屈,PM呢也安撫了毫無問題,你們還都是好同事,結果是很好的。 不少RD不會說這些打圓場的話,多是內向,也多是以爲不必,這些都是你不成熟的表現。   我問你一個問題,你微信裏有上級,有領導,平時也不說話,過年羣發一個很土的拜年信息 有沒有必要?

 

6、如何砍需求

方法一:(優先級法)PM出了需求池後,必定要讓他們列出優先級。 優先級排的低的直接砍掉。

方法二:(場景弱化法)有些場景,可能幾乎不會出現,可是大多數bug都容易出如今極端場景疊加時,這種地方的需求從一開始就應該從簡處理。能夠利用埋點工具,看看有的需求作了都沒人用獲得,反過來黑PM。

方法三:(不吃螃蟹法)不吃螃蟹就是不去第一個踩坑的意思,人家PM出的需求以爲不合理的就讓他找出業界有哪些其餘公司作了這個功能? 你能找到個例子我再作。 這一點很是有用,有的PM和UI天馬行空想的需求,你和他說人家能作出來的我都能作,人家作不了的我也不作。 若是你態度很是強硬不少不合理需求能夠過濾掉,或是用業界經常使用做法,那就比較簡單了。 通常很不合理的需求很難找到業界例子。

方法四:(價值觀法)有不少需求不是不能作,而是這麼作值不值得? 原本能夠用系統組件的,你非要有一點不同,叫我單獨寫個自定義控件?有的組件用戶基本不會用,你讓我投入這麼多精力 這也是不合理的。

方法五:(無奈哭窮法)估時估好了,上線時間也肯定了,我反正就是作不完了怎麼着吧,要否則你去別的組看能不能借人來,要否則就是我給你作上線時間順延。 這是大實話啊。

 

7、不應背的鍋不背

工做中最怕的是幹一些費力不討好的活,開發到了後期全部可能形成風險的需求必定要拒了或是聲明風險。 有時最後PM實在仍是改了需求,或是第三方緣由致使延期,必定要在延期郵件裏明確說明,由於不少上級官員並不太清楚下面發生了什麼,有時你覺得別人都知道了以爲不必那樣去申明,忽視了這一點,那吃虧就是本身。 別人看到的是最後那幾天你還在提PR,都覺得是你沒作完呢,汝不知是PM改的需求。 咱們公司有Task的工具,有的bug不是你的鍋,必定要在下面評論,我給你改能夠,但不是個人鍋是產品bug。

還有一點也是須要提早聲明的,就是工程層面的時間消耗,好比水平低的產品覺得你改一個邏輯1分鐘就ok了,其實你須要經歷:暫停當前開發分支→切到stage分支→拉代碼→新建fix分支→解決→自測→提pr→組內review並merge→部署到jekins-ci打包→新包在內網可下載 。 經歷這麼多的步驟 中間還不算編譯的時間,若是是Android studio那就慢慢等着吧,iOS xcode編譯的倒挺快,可是若是涉及到pod install那也得等會。 這些你不說他們是不知道的,因此在他們說:「你怎麼這麼慢啊」 以前必須先給他們科普。

 

8、工做同事和生活朋友角色轉換

相似於NBA賽場上的科比詹姆斯,賽場上是對手,賽場下是朋友 這種關係。 這裏倒不是說要在工做上和PM作對手, 重點是在你本身的人脈,前面對PM又黑又罵的,可是要讓他們知道你們都是爲了本身工做上的事在互噴, 這並不影響生活中你們仍是朋友,職業生涯也是我的脈。有的之前爭論需求差點打起來的PM轉組了不和咱們直接對接了,你們見面依然都是老熟人,打招呼,微信遊戲有時還邀請下。 有些時候兩個男人之間的需求更好解決,你們認識時間長了,漸漸也就知道對方的底線了,並且供需不對等時,你們也知道這是兩邊上級的緣由,不能把氣撒在好友身上。 相比之下男女之間的關係較爲複雜,女生不太會和你講道理講底線,除非你長得帥。

 

最近業務需求太多,沒啥長進,遂吐槽之餘整理了這篇雜文,但願能引發共鳴,轉載需註明出處。

相關文章
相關標籤/搜索