比较好的棋牌游戏

產品經理怎麼和程式設計師打交道

經常有人問我:「嗨,費傑你好!請問阿里巴巴的需求文檔怎麼寫?「,但很少聽到人談:「嗨,哥們你好!請問產品經理怎麼和程式設計師打交道?」你回去稍微琢磨了一下,心里就會得到下面三種情況:

1)很多產品經理之前就是程式設計師,所以非常了解程式設計師是什麼樣的一個狀態;

2)很多產品經理還停留在關注自己產品規劃、設計本身,缺乏對團隊配合的思考;

3)很多產品經理,其實是有和程式設計師打交道的實踐技巧、心得的,但沒有重視和分享。

 

事實上在很多產品研發體系下,產品經理和程式設計師因爲思考方式、關注範圍、職能職責的差異,導致了溝通上的困難。如何更好的與程序員建立起一座暢通的橋樑也是每位產品經理需要思考的問題。

一般情況下,產品經理和程式設計師溝通困難大概的原因:

 

1、得到信息不對稱;

 

產品經理得到的信息一般集中在:商業需求、商業策略、戰略方向、產品規劃、運營數據、整體營收、目標任務等方面。產品經理往往在根據公司現階段的情況,以及市場的競爭情況,做一些產品策略或者一些產品的方案的策劃、發起、實施。
所以這個過程中,產品經理扮演的角色是翻譯:「市場需求、商業需求」,成爲:「產品需求」,所有的信息全部圍繞需求本身。爲什麼要做需求?怎麼做需求?先做什麼需求、後做什麼?基於怎麼樣一個思路去推送產品進行實施、從一個利益平衡獲得空間增長指標後達到另外一個利益平衡。

程式設計師不一樣,很多時候程式設計師得到的信息是:有一個需求,可能是小需求、產品需求、或大到項目需求,然後得到一系列需求列表,然後產品經理會讓程式設計師看:「需求」哪些通過code改改就可以實現,哪些是需要開發可以實現,哪些是技術或構架或因爲成本的原因不能實現。
所以在這個過程中,程式設計師扮演的角色是翻譯:「產品需求」,成爲:「技術語言」的評估,所有的信息全部圍繞開發需求本身。如何開發這些需求?是溝通資料庫增加欄位?調用接口?開發新的接口?需要開發組件?重新構架引擎?來實現滿足或支撐這些需求?

那這個時候問題來了,很多情況下我們只是把程式設計師當做一個寫代碼,通過程式語言來操作計算機完成需求的工具了。

 

2、溝通語言不對稱;

 

說到兩者溝通的語言,這肯定是困擾產品經理本身的。產品經理的語言是:「描述「、」形容「,我也見過很多產品經理,很多人的需求文檔就是漫天飛舞的文字,一整段的描述+描述,不要說程式設計師看不清,可能過段時間連自己都看不清楚。除了書面語言,產品經理的溝通語言也是含糊的,沒有太多的邏輯去組織,很多時候總是試圖去述說一個需求,被程式設計師的一個計算機術語而打斷。

程式設計師的語言,更偏向於技術化。很多產品經理做過技術,有技術背景,但是還有很多產品經理不懂得技術。所以在這個時候,程式設計師在解說或回答一個需求的時候,會把自己習以爲常的變量、函數、實現方式說出來。於是很多產品經理聽到:「Sdk、webshell、select、api、組件、插件、控制項「等等的時候會雲裡霧裡,

那這個時候問題來了,很多情況下我們總站在自己的立場上、自己的世界裡認爲別人也懂自己在說什麼?實際呢?大家都是聽得一半一半,溝通沒有徹底到位。

 

3、思考角度不對稱

 

產品經理思考的角度在於產品本身,對技術的細節、技術的性能沒有太多的發言權。很多產品經理要是的實現的業務邏輯,不管程式設計師是採用:c++ 、java、php、Python、找開原始碼改的,還是自己寫的都沒有關係。程式設計師只要在約定的時間裡,把約定的業務邏輯開發出來就可以,產品經理不去會考慮目前伺服器的配置、程式設計師手上任務的配置、技術能力的情況,要的是結果。而且很情願的認爲團隊中的工程師都是世界上最好的工程師,想做什麼都可以做,對因爲技術原因而不能支持實現需求不能接受。

程式設計師思考的角度有點區別,我也看到不到程式設計師本身對產品追求完美對需求的背景、意義去研究了解;但很多程式設計師還是停留在自己接單子任務一樣來一個做一個的境界,做好了自己玩自己的。程式設計師考慮程序實現的方式同樣的一個請求是get還是post,程式設計師考慮代碼的性能,從而採取不一樣的方案去實現需求,考慮請求並發量壓力和安全性。但是很多情況下,程式設計師對技術的理解會導致有一些業務需求滿足不了,不是因爲不能實現,是因爲實現了覺得是廢代碼,或者構架不完美了。

那這個時候問題來了,很多情況下到底傾斜誰的立場上思考問題?我之前也會碰到很多情況程式設計師就程序的角度說業務需求不合理,產品經理說程式設計師消極罷工、霸得蠻。

 

4、考核標準不對稱;

 

誰也不尿誰,哼!你能把我怎麼樣。產品經理和程式設計師有爲完全溝通或誤會的時候,極端情況下,有一方會罷工。這個時候主要是2個角色的各個考核標準不一樣,所以在很多情況下顯得非常的無奈。

產品經理很可能考核的是方案和上線的時間、產品上線後的數據;而工程師考核的是程序的性能、很多時候產品經理催的急要的急,但程式設計師每天的時間有限,還是得慢慢構架慢慢開發,程式設計師開發時間少了,未知的執行BUG沒考慮過是要負責的。

這個時候問題又來了,產品經理天天干著急!咋辦?

以上是我結合幾年來的工作經驗總結出來的,當然這4大因素把很多共性的因素概況進來了。當然過程中還是會因爲很多產品經理或程式設計師本身(個性)的溝通技巧、態度、情商等因素導致的溝通不倡,影響了彼此之間的默契。

 

其實仔細的分析一下,產品經理和程式設計師打交道的過程中不管是共性的因素還是個性的因素,也不是想像中那麼困難。通過一些努力之後,我們總是會找到一些快速和程式設計師建立溝通橋樑的辦法。我個觀點如下:

 

1、 要看到項目層面,不要只看需求本身。

 

上面說到的幾點不管是:「信息不對稱「、」溝通的語言不對稱「、」思考角度不對稱「還是」考核的標準不對稱「是我們常見的幾個客觀隱私。把幾個因素抽取出來剖析,發現還是由於我們站問題的視角的高度不一致造成的。

產品經理只是看到自己得到了商業的需求,策劃了產品的需求,接下來會把很多事情拋給程式設計師做了,那還是站在需求方的角色中。那如果真正的是站在意識層面的項目經理的角度,這個時候看待問題的視眼會廣很多。

這個時候你就想著爲了做這個項目這個需求,程式設計師是不是明白了爲什麼要做?是不是對這哪些需求的優先級有了重要的認識?作爲產品經理我用怎麼樣一種表達方式程式設計師更明白?是不是需要把時間點等劃定?目前程式設計師的資源和伺服器情況允許他們能做的空間是多大?怎麼樣才能拉動他們的積極性更好的完成這個項目?適當的時候,需要幫助程式設計師做哪些申請或讓步?

對產品經理來說,同樣張羅一件事情,同樣會了得到一個結果,但是中間的過程很可能是完全不一樣的。所以因爲思考角度僅僅從做完一個需求死磨硬泡上升到,站在項目的角度去考慮各個關節的風險點、時間點,得到的效果是完全不一樣的。

 

2、從理解程式設計師開始,換位思考會更好。

 

一直在問一個問題:「程式設計師是什麼一羣人?「就和問自己:」產品經理是什麼一羣人?「一樣,有點好笑、有點幼稚。從小工到專家,從CSDN到走出軟體作坊,發現很多很多非常優秀的程式設計師的心聲。

程式設計師是什麼樣一羣人?像切西瓜一樣一刀一刀切:

寫php的

寫Java的

寫windows C的

寫liunx C的

寫C++的

 

編程水平一般的

編程水平還行的

編程水平牛逼的

編程水平大師級的

 

構架牛的

資料庫牛的

勤奮的

懶于思考的

 

不會JavaScript的

積極的

喜歡鑽研的……

好像都不太合適,因爲你找不到解決和工程師溝通的好的辦法。而且這些很多是外在的條件,隨隨都在改變。看到很多朋友一年之間經歷幾個大項目水平突然猛進,態度、一些特點也變得完全不一樣。這個時候你需要的是了解和掌握程式設計師,作爲職場的人,和我們一樣的人共同需要的一些特點。

如下4點:

1) 是不是特別想被肯定、獲得尊重;

理解、肯定、尊重。這3個詞或許非常的空但確確實實是一個非常好的方子。靜下心來走近程序員,聽聽他們的心聲、他們的抱怨,或許產品經理和程式設計師的距離將不再是那麼遙遠。

雖然很多時候我們講德行說尊重,但真正領悟到心裡、落實到行動、表現在態度上的完全不一樣的。真正,你是不是一言、一行本真理解、肯定、尊重程式設計師的,程式設計師是有感知的。

 

2) 是不是想給產品提供自己的建議,而不是僅僅做一個編程的機器;

很多程式設計師對產品非常熱愛、對產品有獨特的想法,但多數又局限於技術情節對產品的建議常常被忽視。相信很多程式設計師都希望參與產品,通過自己的專長改變產品,進而打磨出一款完美的產品。

所以產品經理也可以適當的給程式設計師一點發揮的空間,特別是在技術創新、產品需要技術驅動的方面,在商業可控的層面讓程式設計師發揮排頭兵的作用。這樣程式設計師會開足馬力投

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. #非技術出身產品經理的技術溝通祕籍#
    15天補齊程序/代碼、前端、後端、資料庫4大模塊基礎技術知識。助你日常溝通更順暢,產品設計不挖坑!
    詳情戳> 或諮詢起點學院蘑菇(wx:qdxymg)

    回復
  2. ceshihyongli

    回復
圈子
  • 產品經理羣
  • 運營交流羣
  • 營銷增長羣
  • 文案交流羣
  • Axure學習羣
關注微信公衆號
大家都在問