同在一艘船：部門溝通

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

有意義的溝通

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

影片中有兩個關鍵：

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

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

了解真正需求

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

提出有建設性的解決方式

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

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

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

給他魚不如給他釣竿，給他欄位不如教他怎麼呼ＡＰＩ。

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

讓專業的人決定實踐方式

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

跨部門溝通

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

跨組織時，誰都不欠誰。

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

做人一定比做事難。

溝通的核心

ＡＰＰ最常需要溝通的對象包含ＰＭ、ＱＡ、ＵＩＵＸ、前後端、硬體等部門，每個部門背景都有其造成的原因，不同角色有不同的立場和需求。
專案溝通的核心是ＰＭ：

組織溝通的核心是ＡＰＰ自己：

PM

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

UI、UX

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

後端

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

網頁前端

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

硬體

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

QA

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

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

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

團隊合作的能力

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

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

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

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

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