PM篇 - 工程師如何與 PM 溝通
想了很久,都在想說我到底要針對工程師面向來解釋 PM,還是由 PM 視角來切入,所以我決定兩方都來寫下,這篇主要先針對工程師如何與 PM 溝通來進行介紹。
褪下身為工程師的心中自傲,才能達到友善溝通
當我累積數年開發經驗後,我發現自己開始有著「有一點點小成就,就以為自己是專業工程師的自傲」,對 PM 窗口也越來越不客氣,每次 PM 提需求,就直接噴 PM 這個根本不可能,也完全不想跟 PM 解釋為什麼不行。甚至會說:「你不是工程師,我很難跟你解釋。」
直到有次 PM 很生氣的和我說:「你這麼行,下次換你來跟我去需求訪談啊!」
我:「好啊,我直接跟客戶解釋~」
結果我發現自己在人際溝通根本智障,到了現場後,客戶問我事情時,我竟然會怕生,講沒幾句話就開始結巴,結果最後都是 PM 在主導整個會議推動,反而我都在扯後腿。我才知道自己原來在溝通技能上簡直是 LV1 的新手。我只是因為跟同事比較熟,所以在討論上才比較順。
會議結束後 PM 才語重心長和我說:「我只是想讓你了解,每個領域都有其專業,我擅長的就是在專案管理、人事協調上,而你的專業就是在程式開發,我們都得仰賴彼此的專業,一起合作,才能確保產出的東西能夠是客戶需要的。」
也因此我也褪下了「自傲」,了解到一個專案我並不是主角,大家身上都有特殊的專長來共同推動專案,自己會的東西其實少到爆炸。
我也藉由社群聚會發現到,有些懂得很多的開發者其實越謙虛,因為他們也理解當自己懂得更多時,也會發現其實世界相當浩瀚,自己知道的東西也相對有限,必須時常跨域了解,才更開發出更複雜的系統。
需求訪談階段 - 要有心理準備會接受許多天馬行空的需求
我們先帶情境來介紹吧,先來個小劇場。
PM:「客戶想做直播服務,但不想用 APP,說可不可以打開網頁,就能直接開始直播?」
PM:「客戶想要做一個 Facebook 社交平台,但是預算只有 20 萬」
PM:「客戶想要做個電商平台,但時間很趕,只有一個月時間」
我得老實說,當時我聽到這些需求時真的超幹,到底是在公三小,到底懂不懂技術啊??然後也會想說 PM 你連這種需求都在問,你到底有沒有 sense 啊!?更有幾次有萌生乾脆離開公司的念頭。
但自從上面發生的事情後,我開始有認知到一件事,我本來就必須與 PM 討論出能夠符合客戶需求的服務,案子才有辦法談成,也讓我開始能耐著性子去和 PM 討論。
所有專案都來自於預算、時程、系統範圍三大關鍵
那麼 PM 最著重的是哪些切入點呢?有很多工程師都會認為 PM 有很多腦內劇場,但其實 PM 最重視的其實只有三點,那就是預算、時程、系統範圍
- 預算:例如客戶預算只有 100 萬,但客戶開出來的需求,PM 跟工程師討論需要 150 萬,那 PM 就必須與客戶討論,是否有哪些項目可以增減,主要先將客戶核心功能做出來為第一優先
- 時程:如果預算可行的話,某個系統專案兩個月你是否可以做完?身上有沒有卡其他的專案?
- 系統範圍:有沒有超出自己能力範圍的功能?如果是自己沒接觸過的東西,那麼是否需要花時間研究?
一樣我們來個小劇場來向各位分析:
PM:「我剛有發客戶的功能需求單給你,他的預算是 100 萬,預期要做三個月時間,你覺得時程點上怎麼樣?」
工程師:「之前都有做過相似的,沒太大問題,只是線上支付種類太多,如果全部都接會很趕。」
PM:「例如哪些呢?」
工程師:「像是 PayPal 和微信支付,雖然我沒接過,但是只要牽涉到跨境金流的細節都會很繁瑣,裡面只有綠界是沒問題的」
PM:「那如果要延長時間,大概要多久呢?」
工程師:「這專案人力只有兩位工程師,我們兩個開發好整體架構後,才會開始碰支付,我想至少要四個月時間」
PM:「所以你是指在兩個人力,都要各加一個月的工作天,才有辦法再做出來?」
工程師:「對,如果你想要更確切時間,可能要給我兩天時間,先去研究他的申請流程,才有辦法推估開發時間,而且對方客戶也必須跑申請流程」
PM:「我突然想到我們的合作外包公司,好像有做過這兩個金流?」
工程師:「哦哦我恢復印象了,沒錯他們有做過」
PM:「那如果他們一起加入進來的話,有可能在三個月內完成嗎?」
工程師:「應該可以,我記得那裡的 B 工程師蠻常做跨境電商,只是這樣預算可能就得提高了?因為人力變多的關係?」
PM 深深嘆了口氣說:「對啊,因為他們就是希望能在三個月內完成,我們老闆和他又是舊識,所以我剛預估了下人力投入成本,兩位工程師,一位 UI、一位 PM ,再加上外包的費用,報價可能會報 150 萬才合理,但可能也要老闆和客戶同意才可以呈報。」
工程師:「這樣子就合理,不要像上次另外那位客戶,以為多加很多人力,就能將需要一年的開發濃縮成一個月。都忘了申請金流需要時間、前期規劃、中期開發、後期測試的時間都能跟著縮減 OTZ」
--
相信各位從上面看得出來,PM 就是要與工程師針對預算、時程、系統範圍三大面向來環繞進行討論,所以如果換個場景,如果你的討論項目是向下面這樣:
PM:「請問這個第三方金流介接可以在期限內做完嗎?」
工程師:「我認為這東西有兩個切入點要討論,一個是這金流 API 不穩定,我必須寫個排程定期去戳他,當他壞掉時,系統才能回饋因應,第二點是 $^&#)$#$#」
講了半小時後,工程師還是沒回覆 PM 最想知道的時程問題。比較好的講法就是:
「這東西我還有兩個問題要處理,但如果週五你要對外跟客戶講是否完工,那是 ok 的」
「這個功能我沒做過,但是做得出來的,我再去 Github 或 Stack Overflow 翻下資訊,後天再跟你說是否做得出來,以及確切開發時程」
「專案太大了,沒辦法在兩個月做出來,如果小傑工程師可以拉進來參與某個子系統,花兩週時間,那就可以。」
「我完全沒做過,而且我是寫 web 的,而且就我認知這個功能用 APP 也寫不出來,站上手機上就可以測體重,因為 APP 沒支援這寫法,當然我也可以去 Google 一下,那我覺得答案可能也一樣。」
總結
針對上面的例子,相信工程師們已經知道,為什麼 PM 針對 預算、時程、系統範圍對他們來說有多麽重要,因為有這些資訊他們才可在初期需求訪談時,確保推出來的專案服務內容,能夠依照客戶需要,在符合預期的預算與時程下,做出想要的功能 :D