tft每日頭條

 > 職場

 > 産品經理最需要關注什麼

産品經理最需要關注什麼

職場 更新时间:2024-06-11 10:52:58

職場沒有彼岸,隻有在路上,且行且珍惜~

産品經理最需要關注什麼(産品經理與程序員溝通的藝術)1

還是在幾年前,一個普通的工作日,我正準備完成滴答清單上今天最後一個任務-清理郵箱。此時一封“情感豐富”的郵件映入眼簾,“U CAN U UP, NO CAN NO B B”。

直覺告訴我,一定是某個RD又被PM逼瘋了。

想想也挺有意思的,這幾年的工作中,不斷重複上映着類似的一幕。

下面我們就看看這五個小技巧, 有那些親還沒有“掌握”?

第一招:高山流水

“這個實現起來,應該很容易吧!”,一個懷疑的小眼神,像激光一樣在RD身上掃來掃去。

這句話的潛台詞是:你最好給我的工期短一些,否則就是你能力不行!

這句話不是不能說,是要分誰說。

如果是該RD的leader,研發總監之類的說,有資格。為啥?因為他了解開發原理、理解開發過程和熟悉工程代碼現狀。

如果是你說,就不行。為啥?你不懂開發啊~

越俎代庖不但不會拿到好的結果,還會暴露你的情商。有的人會說了,我也是為了給對方點壓力,盡快上線給公司創造價值啊。

這個出發點是沒有錯的,有問題的是方式方法。

例如:先不着急下結論,聽聽對方給的排期自己是否能接受?不能接受的話,可以詢問一下主要的工程量在哪兒,PM是否可以做些什麼,好加快進度?技術難點是否需要和組内leader一起讨論一下,必要的時候PM可以再進一步精簡方案等。

第二招:綿裡藏針

“那個,實在不好意思啊,這兒在改一下哈~”,嬌滴滴的一個小女生面紅耳赤的望着RD(有的時候确實是半蹲着,好吧其實是跪着~)、

頻繁的改需求,你的形象值出現了赤字。

究其原因,主要是兩方面:客觀原因和主觀原因。

前者,典型案例如下:

  • 老闆臨時要求 :提前做好預期管理,充分溝通,一般是可以避免的。但如果真遇到了老闆不方便說(eg.資金壓力),或者還處于試用期的你,就先強調執行力吧(在做了充分溝通的情況下)。
  • 業務變更了需求(部分修改):重點在于引導業務同學關注目标,隻要是當前方案能解決業務痛點,達成業務目标,産品應堅持不調整或下個版本調整。
  • 業務反水(全盤否定):利用業務評審會、會議紀要和測試驗收充分做好風控流程。
  • 技術瓶頸:很多技術難點是在開發過程中暴露出來的,這種情況下的修改産研雙方都能理解,重點是最大程度的複用方案,将工程資源浪費降到最低。

後者,主要是方案設計能力出了問題,出門左拐看《寫給RD的一份情書-PRD》.

沒有人敢承諾開發過程中方案一定不會發生改變,但是發生頻率還是可以控制的,以上概括起來就三點:

  1. 尊重過程
  2. 關注目标
  3. 嚴謹負責

第三招:八步趕蟬

“兄弟,啥進度了?”

經常看到小白産品,不是釘釘催,就是跑到工位問,要不就用老闆壓。

說真的,沒必要。

你可能會說了,站着說話不腰疼,不催領導找我要進度,我怎麼說。

不是不讓你催,而是不建議你“愣頭青”式的催,可以試試“灰度催工法”。

具體如下:

  • 針對信用值高且技術能力的強的大牛,你根本就不用催,這些人把職業形象看的比什麼都重,你的催促除了給對方帶來反感,傷害彼此的合作信任關系以外,不會有任何效果。
  • 針對信用值高但技術能弱的研發,其實也不用催,為了他的信用值,他自己就會想辦法保證進度,你根本不用操心。

以上兩種都比較省心,最怕的是信用值低的研發(無論其研發能力如何),需要費些心思。

例如:

  • 可以詢問PRD是否有不清楚的地方,自己可以在單獨給詳細講一下,捎帶在确認一下進度;
  • 工程開始時候,可以參與工程早會關注進度,哪怕是催圖這種事也要積極參與,營造一種重視感;
  • 公開場合贊揚改研發,并“無意間”提到排期,以便引起對方的重視;
  • 通過roadmap,倒逼時間,提醒QA同學,利用團隊的壓力避免其失信;
  • 和其領導強調該工程的意義,并确認時間。

項目管理用情商,關注進度重技巧。

第四招 :霧裡看花

“這個PRD裡竟然出現了【可能】!!!”RD抓住了自己本已稀疏不多的頭發說道。

如果說研發同學最恨的是什麼,那“不确定性”一定能夠名列前茅。因為,在研發的世界裡,開發的過程就是将PRD裡的内容翻譯成高級語言,再由計算機講高級語言翻譯成機器語言執行的過程。

研發最願意花時間的地方是“研究如何用高性價比的方式實現需求”而不是“理解這是個什麼玩兒意兒?”

想象一下,一名出色的翻譯官面前站着一個“外國人”和一個“外星人”的畫面,你就應該能理解我在說什麼了。

你的“不确定性”,是在扼殺RD的青春(如果他們還有的話~)。

第五招:鹞子翻身

“這TM弱智也能看出來設計不合理”,胖胖的RD開始嘟哝着。

經常聽到工程評審時候,PM以這些詞彙開頭“我覺得”、“我認為”、“我想”、“我猜”……

騰訊UDC提出來的一個概念,有源設計,即堅持每個方案決策都有依據支撐。

深以為然。隻有堅持有源設計,這種科學的決策方式,PM個人才能在工程團隊中建立起來專業的形象,成為大家嘴裡的“靠譜人士”。

經過多年的被噴經驗,我總結了如下幾個打死都能說得過去的決策依據,僅供參考:

  • 數據 :用數據說話,這個一般不會有人質疑,除非你的數據本身經不起挑戰。
  • 調研:隻要樣本量和質控制好了,可信度是很高的(京東的物流就是這麼決策的,見《創京東》)。
  • 競品:隻要是選擇的是一直表現不錯的競品,用好MVP,被挑戰的可能性不大。
  • 标品:一句話,這是用戶的系統習慣,你不應該也沒必要去改變。
  • 專家:代表着未來,老闆支持就幹呗。
  • 老闆:還用問?

有源設計,不要意淫。

最後,老生常談一下。職場沒有彼岸,隻有在路上,且行且珍惜~

本文由 @吳天 原創發布于人人都是産品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

,

更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!

查看全部

相关職場资讯推荐

热门職場资讯推荐

网友关注

Copyright 2023-2024 - www.tftnews.com All Rights Reserved