這篇我要以 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

通常 12 點我們就不討論了，通常工程師都會秒回你工作時程。最重要的當然是 36 點，當你提需求時，他都會和你說：「這有點困難」、「不可能，這需求太瞎了」、「我想一下，但我沒有把握」、「我連 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