在工程師的世界裡，專業技術固然重要，但溝通能力同樣不可或缺。

這句引言揭示了一個常被忽視的事實：工程師的工作遠不止於寫程式跟使用電腦。有效的溝通在這個職業中佔有不可或缺的地位。不僅需要精確地理解客戶或同事的需求，還必須能夠清晰、準確地表達自己的觀點，以促進更好的相互理解。

回顧 Day19、Day20

在 Day19、Day20 中，我提到了公司成立一個新的產品線，在這個產品線中，我因為對於 React 比較熟悉，所以身為初階工程師的我，被當成資深工程師般，也面對並且完成了很多挑戰。今天，我想分享的是另一個同樣重要但經常被忽視的方面：溝通。儘管我已經盡力去溝通和解決問題，但這個過程讓我更加明白，成功的溝通需要雙方的積極參與。

組織結構與角色

App 團隊 Adam(假名) 的影響力：最初，我誤以為 Adam 僅作為協助角色參與，但後來發現他在公司內部已經做了五年，所以具有相當多的影響力。到後來，被提拔為前端組長，但他是開發 Java 的。

產品經理 Tim(假名) 的經驗：與 PM 進行了一次深入的交流後，我了解到他之前是一名後端工程師，並且只有一年的工作經驗。這次擔任 PM 更像是一次嘗試，而非基於豐富的經驗。

溝通障礙

在專案的初期，App 團隊成員 Adam 和產品經理 Tim 在未與我們前端工程師進行充分討論的情況下，就制定了整個專案的大綱。這種方式不可避免地導致了後續的一系列問題。

會議文化與時間管理

狀況

由於公司原先採用瀑布式開發，而 Tim(PM)希望轉向敏捷開發，我們因此進行了一系列敏捷開發相關的會議，包括 Sprint 規劃、每日站會等。

例如說，我們部門每天早上十點就會站立會議一下了。然後按照 Tim 的要求每天 11 點又要再跟他們站立會議。
造成我每次工作剛進入狀態就被打斷，在工程師開發時，進入狀態會很全神貫注的開發，被打斷後要再進入那個狀態要再花點時間。

敏捷開發的會議有：

1. Sprint Planning Meeting：迭代規劃會議。用於規劃即將進行的迭代（Sprint）的工作項目。
2. Daily Stand-up Meeting：每日站立會議。每天短暫的會議，用來更新進度和討論問題。
3. Sprint Review Meeting：迭代回顧會議。在迭代（Sprint）結束後，回顧完成的工作和未完成的工作。
4. Sprint Retrospective Meeting：迭代回溯會議。回顧過去的迭代（Sprint），討論哪些地方做得好，哪些需要改進。
5. Backlog Grooming：產品待辦清單整理。雖然不是每個迭代（Sprint）都會有，但有時會需要進行，以確保產品待辦事項列表（Product Backlog）是更新和優先排序的。

其餘的這些會議，我們每個 sprint 皆會招開，而這些會議則是佔用了大量的工作時間，經常開個半天或是一天，導致實際開發時間大幅減少。

解決方案

我以前的跑 Sprint 的經驗是，大部分都是站會跟週會而已，然後其他的會議大致上都濃縮在週會，週會也大多是了解一下這週的進度跟下週預計要做的事情，通常大概也一小時內就結束了。

不過也讓我確認到敏捷開發的會議並不是應該要照單全收，給予工程師充足的開發時間才是最重要的。

後續影響

按照 Tim（PM）的要求，我們除了每天額外的站會外，還要開足其他的會議，大概讓我們的開發時間少了 1/5 ~ 2/5，到後期我甚至發現很多時候開會，都是我已經盡力表達我在說的東西了，但由於對方資歷尚淺不是很了解，所以我又花了很多時間讓他了解我到底在說的是什麼技術名詞，或著是這個技術的用意是什麼。

不同程式語言的衝突

在專案初階段，我就計劃採用先進的 React Hook 技術，以其簡潔和易用性為優點。然而，當 Adam(Java 開發者) 看到這一點後，他堅決反對。

用 Java OOP 思考 JavaScript

Adam 根據他的 Java 經驗，堅持認為我們應該使用繼承的概念。他甚至引用了資料，指出 JavaScript 也有 Class 結構，因此應該使用 Class。這對我來說是一個挑戰，因為我已經開始編寫部分代碼。

儘管我詳細解釋了在 React 中，Class 已經透過 extends React.Component 已經繼承了 React 本身的變化，所以此 Class 非彼 Class。但 Adam 仍然堅持他的觀點。因此，我只能嘗試演示給他看，但結果總是出現錯誤，然後他還是找各種方法告訴我一定可以解決。

所以我就陪他試了好一陣子，最後我實在無奈，只好去跟外部工程師群族求助（還好的是我本身就有常駐在一些工程師討論群組）。而且幸運的是，有人回應了我，並分享了一篇來自 React 官方網站的關鍵文章。

最後 Adam 終於同意不能使用 Class。

溝通成本

在這裡體認到溝通成本非常的重，我甚至好幾次跟他開了一整天的會，就只是因為他想了一個他們 Java 有實現過的功能，然後要我跟他說明在 React 上怎麼做，但有些概念不是這麼好解釋。

舉例來說，Java 因為可以繼承，所以就可以取得繼承上層的資料，然後要問我怎麼做到，然後我就跟他說在 React 中通常是透過 Redux 之類的工具來達成。但 Redux 本身就是一個挺抽象的概念，不容易了解，我當初在學習時也是花了三個禮拜的時間(邊上班邊學習)才上手。

所以為此我又要跟他解釋很久，這個是什麼？為什麼要這麼做？用意是什麼？然後還要解答他一切的問題，他才同意使用，因為「他是組長」啊。

後續

雖說這種外行領導內行的狀況讓我感覺很糟，但後來還是有注意到一個不錯的點，畢竟 Adam 好歹也在這間公司做了五年以上，對於程式開發的經驗相當豐富。

所以後來他為了加速開發，也自己下來幫忙寫 React，甚至可以感覺到，他只花了一兩個月的時間，卻進步的比另外一名前端工程師還快，甚至後來我大部分都在規劃程式面架構方向跟實作，然後由他帶領另外一名前端，有問題時再來問我。

雖然是這樣，不過後續依然又再次遇到更多的外行領導內行的狀況，因為篇幅限制，這部分就留到明天了

結語

如同文章開頭所述，「在工程師的世界裡，專業技術固然重要，但溝通能力同樣不可或缺。」這一點在面對不熟悉專業領域的人時尤為明顯。

在這份工作中，我大量實踐了與非專業人士的溝通，這不僅提升了我的需求溝通能力，也讓我能夠更精確地識別問題和痛點，並能快速了解後提出合適的解決方案。有趣的是，在現職工作中，我甚至有同事試圖模仿我的溝通方式，但未能成功。

巧合的是，當時，我在假日自我提升的課程中，也正好是學習了溝通的各個方面的原理、演練以及實作，這些學習不僅在課堂上有所應用，也被我運用到實際工作中，這大大的讓我更有應用那些資料的能力。

加上我在程式設計學習中積累的扎實基礎，這使我能夠自信地進行溝通，堅持自己的立場，並推動專案的進展。

接下來，我將分享更多我在工作中遇到的問題，以及最終選擇離職的原因。

感謝你的閱讀，希望這篇文章能讓你有所收穫。

文章就說到這，有什麼想法或問題，歡迎隨時找我聊聊！

這篇文章也會同步發在 medium 上，如果有興趣歡迎追蹤我。

medium: https://medium.com/@hugh-program-learning-diary-js
email: u88803494@gmail.com