iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 7
10
Modern Web

菜鳥工程師必修的 30 堂溝通課系列 第 7

PM 篇 - 除了聊貓,教你該如何與工程師溝通

  • 分享至 

  • xImage
  •  

這篇我要以 PM 的角度來分享,該如何與工程師溝通,我相信很多 PM 都會心裡 OS 想說,工程師的腦袋瓜子都在想什麼鬼東西,為什麼常常會雞同鴨講,所以這裡我來分享一些比較常見的面向。

受夠工程師在估時程的反覆

各位 PM 有沒有覺得,每次與工程師討論工時,通常很難討論出一個共識?例如你提出一個功能需求,對方當下跟你說不可能,但過兩個小時就又跟你說功能做好了?然後心裡會 OS 工程師是不是在耍你。

我也看到許多這樣的案例,也因此 PM 因為如此,而不相信工程師,所以這裡我要分享一下為什麼工程師會有這樣的現象。

我這裡也分享一個小劇場給各位 PM 們:

PM:「客戶說他的網頁想要加上這個 A 功能,但後天系統就要上線了,來得及嗎?」
工程師:「嗯..我想不太到該怎麼做,以前沒做過類似的東西,沒辦法在兩天內做好。」
PM:「是哦,那你要不要先去 Google 一下?」
工程師:「好,但是我建議你先推掉,因為我自己沒有把握。」
PM:「好吧,客戶也說若這次不將此功能上線也可以,那你就先準備上線的流程嘍」
過了 30 分鐘後

工程師:「我找到解法了,功能也完成嘍。」
PM:「蛤?你不是說很難嗎?」

工程師:「就去上廁所的途中,突然想到解法惹,ㄏㄏ」
PM:「........」

有沒有感覺很無言?是不是你們很常見的場景呢?為什麼工程師會有這樣的舉止呢?就讓我一一道來。

設計開發難易度量表

工程師在面對一個功能需求時,心中會有一把尺來評估難易度,這裡我給 PM 一個量表提供參考,排序是由簡單到難:

  1. 寫過好幾次,閉著眼睛也可以做出來
  2. 有寫過類似開發,至少 80% 以上有把握,其他 20 % 稍微思考下就可做出
  3. 沒寫過,但腦袋有想到網路資源曾經找過類似的,可能得再重新找資源
  4. 從來沒看過類似開發案例,但覺得「應該寫得出來」,但不是很確定
  5. 超出自己能力太多,就連要 Google 下關鍵字,也想不到該下什麼關鍵字
  6. 覺得完全不可能,對方的需求根本是天方夜譚,連 Google 都不想 Google

通常 1~2 點我們就不討論了,通常工程師都會秒回你工作時程。最重要的當然是 3~6 點,當你提需求時,他都會和你說:「這有點困難」、「不可能,這需求太瞎了」、「我想一下,但我沒有把握」、「我連 Google 都不知道怎麼 Google。」

所以這裡我會建議你將這六點寫下來,並問他說,關於這個需求,是 1~6 點的哪一點,你至少能知道這個需求是屬於哪個區間。

或者是用以下問句來詢問:

PM:「這東西你看過類似需求嗎?」
PM:「那如果讓這個需求分成這六個量表,你覺得他在哪一個等級呢?」
PM:「這個需求是不是完全不可能做到?因為坊間都沒有類似的功能?」

藉由量表的方式,至少你可以從工程師的腦袋瓜子裡,知道這需求到底在他心目中的難易度到多少。

用可評估與可比較的資訊來評估難易度

什麼意思呢?我來舉個例子吧:

PM:「你覺得這個需求從 1~100 分,他難易度大概是多少?」
工程師:「應該是 87 分吧,雖然這需求很瞎又反科學,但加這功能應該可以勉強在專案結束前交付」

PM:「如果給你四天時間,有可能把它做出來嗎?」
工程師:「不行,絕對不可能!」
PM:「那兩週呢?」
工程師:「好像....可以。」

PM:「這個需求跟去年的專案比較起來,哪個難易度較高?」
A 工程師:「當然是去年的!」

PM:「那這個 A 專案你覺得跟 C 專案比較起來,哪個比較龐大?」
後端:「我覺得是 A 專案,他後端結構不是那麼好寫,而且接得第三方服務很多」
前端:「我覺得是 C 專案,那時光是滿足客戶要的 WebGL 動畫就快搞死我,」
PM:「那我再問一下,如果是以百分比來說的話呢?」
後端:「A 專案大概比 C 專案多 35% 工作量吧」
前端:「我反而相反,A 比 C 少 50%,畢竟只有切板和接少數 API,但我覺得 UI 那裡花的時間可能會比較多,你可能要問 UI 一下」

要說好笑點的方法,就是痛苦是比較出來的,所以你用分數或百分比來推敲難易度,或者是用 AB 比較的方式,自然也能逐步推敲出該需求在工程師心目中的難易度。

了解難易度後,自然也可推估出預期時程。

讓子彈飛一會兒,不要急於讓工程師下結論

知道怎麼向工程師問出難易度後,不要急著工程師表態到底要不要做,尤其是上面提到的 3~6 點,我這裡再條列出來:

  1. 沒寫過,但腦袋有想到網路資源曾經找過類似的,可能得再重新找資源
  2. 從來沒看過類似開發案例,但覺得「應該寫得出來」,但不是很確定
  3. 超出自己能力太多,就連要 Google 下關鍵字,也想不到該下什麼關鍵字
  4. 覺得完全不可能,對方的需求根本是天方夜譚,連 Google 都不想 Google

首先 PM 要有個認知,就是:

  1. 就算是簡單的東西,工程師也可能突然卡關而延宕一週以上
  2. 僅管當初說困難的項目,工程師也會突然跟你說他找到解法了

這並不是工程師反復無常,我只能提供一些案例給 PM 們參考

  1. 覺得應該很簡單,但因為某天 chrome 更新了,某個核心重要功能被廢掉,但又找不到替代方案而束手無策。
  2. 運作好好的主機,突然不管怎樣都會出錯,最後花了很多時間查找,才發現是主機商的網路協定問題
  3. 原本覺得完全不可能做到的事情,但因為突然靈感來了而漂亮解決,這靈感有可能是突然去上廁所的途中,或者是躺在床上準備睡覺、抑或是在洗澡的時候。就突然找到解法了
  4. 原本已經信心完全喪失,但從工程師論壇裡找到一個超完美的解決方法,又從網路資源找到符合需求的技術框架,原本需要花兩個月的時間,後來只需要一週。
  5. 雖然已經不想理 PM 兩小時提的奇怪需求,但腦子裡還是會想著解決方案,最後靈感來了,突然想到替代解決方案

所以每次當我提出客戶需求給工程師的時候,工程師若跟我反應:「這有點困難」、「目前想不到解法」的時候。

我就會先讓工程師花多點的時間消化需求,並說:
「不然你先想一下,我先規劃其他時程和報價,反正後天才需要全部報給客戶。」
「沒關係你先評估一下,雖然客戶好想要這個功能,但如果做不到就算了。」

這樣的好處在於先讓彼此先脫離當下溝通環境,能夠更專注獨自思考問題點,另外工程師也會藉由這段時間思考各種可行性解決方案。

累積信心帳戶,讓工程師逐步建立信賴關係

這點我認為是身為 PM 很重要的一環,舉例來說吧,如果 PM 時常就跟工程師說:

「客戶說這功能很重要,我也贊成,請你找時間加上。」
「客戶臨時插件,但為了要結案,你還是幫他做吧。」
「我在開會時答應客戶要做這功能,就請你幫忙嘍。」

有沒有發現上面的客戶,三句不離「客戶立場」,工程師如果聽多了心裡就 OS:「靠北..你到底是哪邊的人啊」、「為什麼 PM 都站在客戶那裡,到底我們是不是同事啊」、「有夠衰小,你出一張嘴我就多了好多事情要做。」

所以我會呼籲 PM 們,在前面的章節有提到「尊重對方時間」的溝通法,這裡也能夠學以致用,您不妨可以試試看以下的切入點。

「我剛剛跟客戶開會時,客戶有提新需求,但我和對方說必須先和你討論,再回覆對方,這樣才能確保你的開發時間不會因此而影響太多。」
「客戶有提了三個新需求,但我擋掉了,我們這裡開發已經很緊了,不可能再答應他們這樣的需求,總不能都是我們吃虧,如果客戶真的非做不可那就請他額外報價。」
「A功能你有提到很困難,我有和客戶說先讓我們開發部門討論一下,等你這邊有結論時,我們會回饋給客戶,不過可以的話看能不能在週五前和我說一個小結論,我這邊也比較好因應後續該怎麼處理。」

結論上其實也是一樣,也就是凡事都想到窗口的立場,不要讓他人認為這東西都是你一個人決定。

這樣自然你的同事才會認為你有尊重他,藉此與對方建立信賴關係。這個關係也會像是你存錢在帳戶一樣,當你建立的信賴感越來越重時,對方才會更加主動地與你合作專案,一起共勉之 :D


上一篇
PM篇 - 工程師如何與 PM 溝通
下一篇
工程師如何結合興趣,探索個人發展
系列文
菜鳥工程師必修的 30 堂溝通課30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

2 則留言

0

哇~ 感覺你寫的溝通術很實用呢,小馬身為學生,
通常是自己打好程式就好,不知職場上的溝通眉角。
覺得看你的文章受益很多,加油!

廖洧杰 iT邦高手 2 級 ‧ 2019-09-08 11:05:41 檢舉

很高興文章對你有幫助,我會繼續加油的 :D

0

上廁所那段太好笑了XDD
不過我是在主管開了issue,我本來說我沒什麼頭緒可能有點難
結果主管去上廁所回來我就把bug解掉了
/images/emoticon/emoticon14.gif

廖洧杰 iT邦高手 2 級 ‧ 2019-09-11 19:57:21 檢舉

除了上廁所,有時候洗澡時也會冒出很多開發靈感,都不曉得要先衝出去先筆記起來還是繼續洗 XD

我要留言

立即登入留言