同在一艘船:部門溝通


第一屆開發者寫作松,軟體工程師軟實力系列第四篇

有意義的溝通

「拜託!到底誰才是專家呀?!」- The Expert — 希平方 影片裡面,PM和客戶要求RD用紅色的筆畫藍色的線,並且畫七條互相垂直的線,這是個很經典的調侃劇情,但現實生活中會不會發生?其實會,我有遇過… QAQ


影片中有兩個關鍵:

  1. 當客戶遲疑,回答七條線需互相垂直時,已經表現出她並不了解自己的需求,因為被提問而強硬擠出答案的,並不是真正的需求。
  2. 當客戶提出用紅色的筆畫藍色的線時,其實PM和RD只需要聽一半:”她要一條藍色的線”,至於怎麼產出那條線,其實不是由客戶決定的。

開規格的人必須有專業,並且是實際上能夠解決問題的。

了解真正需求

處理方式有很多,但通常都是PM的職責,包含提供客戶所需的相關知識教學、使用需求訪談的方式協助他們了解,溝通出主要解決問題或痛點,如果有需要更多的時間或資源讓客戶思考,PM要協助安排。
厲害一點的PM會在察覺問題後提供解決方式給客戶選擇,有些餐廳的服務員會提供推薦餐點一樣,但前提是:PM要先了解有哪些解決方式,這就是為什麼大部分有資訊相關背景的PM會表現得比較優秀。
延伸:【每分每秒都在問自己】PM 們不敢說的職場辛酸:為什麼要會寫程式?

提出有建設性的解決方式

但問題來了,大家都知道有程式概念的PM相對優秀,那為什麼大部分PM都還是不會?就跟優秀的工程師難求一樣,在台灣軟體產業蓬勃的現在,若只挑會寫程式的PM,那應該有很多專案是沒有PM的。

專案經理跟資深工程師一樣,是需要經過長時間訓練的。

菜鳥工程師通常是前輩、團隊協助訓練,或者自立自強。那菜鳥PM呢?就我目前的觀察和體會,PM的專業知識和技術背景,通常都得靠跟RD交流。

給他魚不如給他釣竿,給他欄位不如教他怎麼呼API。

我真心覺得一個APP專案經理會用Postman真的很有幫助。

讓專業的人決定實踐方式

若PM沒有足夠的專業能力能提出解決方法,那就必須尊重RD,就像你訂了一個Pizza時不會管它順時鐘還是逆時鐘加料一樣,只需要看結果。
但所謂的尊重也不是完全依照RD提供的方法,而是互相溝通需求與顧慮後,協調出最佳解法。

跨部門溝通

在溝通時,出發點要是利於他人的,並且先了解別人再表達自己,拿出誠信,希望別人配合時,那就自己多付出一點。

跨組織時,誰都不欠誰。

溝通的三個層級:閒聊、會議、談判。但無論哪種,都很吃團隊領導人的人脈,因此平時培養良好的人際關係,絕對是有助於跨部門溝通順利。

做人一定比做事難。

溝通的核心

APP最常需要溝通的對象包含PM、QA、UIUX、前後端、硬體等部門,每個部門背景都有其造成的原因,不同角色有不同的立場和需求。
專案溝通的核心是PM:

組織溝通的核心是APP自己:

PM

上一篇文章提到,無論積極消極的PM,都很重視dead line,因此跟PM培養出時程預估和溝通的默契,就成為RD快樂上班的關鍵因素之一。
除此之外,RD自己也要有原則,不要看到迷你裙就少兩週,免得PM每天穿絲襪你就每天加班(雖然我也喜歡看絲襪)。

UI、UX

介面設計重視美觀簡單容易使用、體驗設計則是以流程和使用者體驗為優先。由於兩者與APP有共同的目標,因此在立場上不太容易對立,除非RD犧牲美觀和體驗只想節省成本。以目前的經驗最容易需要溝通的,不外乎是iOS和Android的系統差異,包含元件更新、使用習慣、設計規範等等,這需要另一個長篇大論來說明,這裡先點到為止。

後端

我遇過欄位沒傳但打死不認,非得抱著筆電坐在他旁邊才會找問題的後端,但我相信那是個案,大部分的後端仍然是品格正常、有責任感的好夥伴。
屏除這種極端個案,通常只要文件完整,資料更新同步,在討論解決方案時提出自己的顧慮和能提供的方式,由於工作性質相似,溝通上通常是阻礙最少的。

網頁前端

同樣也是工作性質相似的部門,但在APP與網頁串接上,最常出現的問題仍然是Android和iOS的系統差異,還有Webview、使用者權限的相關問題,這也值得用一篇文章分享,詳細內容就先跳過。

硬體

通常是藍芽,除了傳遞資料有長度限制,要考慮Timeout和異常斷線等問題以外,基本上都跟後端一樣,文件完整並且同步更新,就不太有技術落差產生的溝通問題。

QA

這是除了PM以外最容易跟RD有對立的部門,但87%是心態問題,想像一下如果沒有QA團隊,產品會是什麼樣子?測試工作誰來執行?就能心平氣和的面對如雪片般飛來的測試報告。但QA的職責絕對不是只有產出測試報告,參與開發流程與規格制定的QA,更能了解如何提升產品品質並降低測試成本。
講歸講,但技術落差還是會產生不少溝通問題。

  1. 沒錯一樣是系統差異。
  2. 環境問題,收到報告後RD一臉黑人問號???我在開發環境沒這個問題啊?!
  3. 責任歸屬,在最接近使用者的那端(APP、Web)發現問題,哪知道是APP、Web、API、DB的問題?

我必須老實講,這就是溝通的藝術了。指著別人要他解決問題,和告訴他我發現問題了,我們一起來研究是哪邊出問題,是兩種完全不一樣的過程,甚至會影響結果。
QA容易產生對立是因為人性本來就不會喜歡被指責(注意是指責而不是指正),營造同一條船上生死與共的團隊意識,對QA的跨部門溝通來講就更為重要了。當然QA也有自己的難處,而且通常測試成本的重視程度都會低於開發成本,因此提出團隊顧慮、改善方式,與開發團隊達成默契,才是上上之策。
延伸:我就是不會寫程式才來做測試的啊

團隊合作的能力

不要有別人團隊和我們沒有關係的心態,記住:

不怕神一樣的對手,就怕豬一樣的隊友。

發現別人的問題後視而不見,就像BUG回報一樣,不回應就當作沒有,就不要期望會被改善。

積極面對問題才是工程師該有的態度。

無論是伸出友誼之手主動提出資源協助,還是將所有責任和問題列表打包快遞到其他部門主管手中,有動作才會有改變,就跟減肥一樣。

#APP #iOS
APP工程師軟實力
工程師有很多新技術要學、舊技術要補,但在軟體開發過程中,有更多的是軟實力和經驗累積。 希望可以藉由文字傳遞,讓團隊學習沒有斷層,自我學習更加突破。






Related Posts

[ week 2 ]  打造 JaveScript 的基礎 - 基本運算 &位元運算

[ week 2 ] 打造 JaveScript 的基礎 - 基本運算 &位元運算

React - 理解Virtual DOM

React - 理解Virtual DOM

Firebase Storage 入門

Firebase Storage 入門

[6] 持續整合,自動化測試的價值

[6] 持續整合,自動化測試的價值

Day5 跟一般的指令可不一樣啊!跟我所認識的指令不同啊!

Day5 跟一般的指令可不一樣啊!跟我所認識的指令不同啊!

GIT Github

GIT Github



Comments