一個成功的溝通需要雙方積極參與加上高度意願。
這句話解釋了，當你想要跟一個人溝通時，還必須要對方有意願參與，也要加上對方有高度意願，這樣才能彼此瞭解對方在說的是什麼，並且使得溝通順利成功。否則一個溝通將會拖得非常久，甚至溝通失敗。
這篇可以說是 Day21 的延續，所以推薦先看完再來看這篇。在 Day21 中，說到的整個團隊中，我需要跟他們有大量的溝通，這些我都還可以一一的解決，只是就需要消耗時間而已。接下來要說到的部分，就可能跟一間公司的文化有關係。
App 團隊 Adam(假名) 的影響力：最初，我誤以為 Adam 僅作為協助角色參與，但後來發現他在公司內部已經做了五年，所以具有相當多的影響力。到後來，被提拔為前端組長，但他是開發 Java 的。
產品經理 Tim(假名) 的經驗：與 PM 進行了一次深入的交流後，我了解到他之前是一名後端工程師，並且只有一年的工作經驗。這次擔任 PM 更像是一次嘗試，而非基於豐富的經驗。
這家公司總共有超過 40 名員工，其中自然少不了一個專門負責產品外觀設計的部門。當我一開始得知會有專門的設計稿供我參考時，心情是相當高興的。這點我在 Day17的文章中也有提到。通常，通常的合作的方式會只會提供一份 excel 寫的規格書，然後我就會根據規格書進行實作。最多也就是給我一些 JPG 格式的圖片。
然而，當我最後拿到設計稿時，發現還是一堆 JPG 格式的檔案。更令人失望的是，這些都是 App 開發團隊之前用過的設計。這些設計明顯是針對 App 開發而設計的，而不是網站開發。
我心裡不禁想，如果能有像 Zeplin 這樣的專業設計稿工具就好了。因此，我又花了不少時間與設計部門進行溝通，最後他們終於同意提供更專業的設計稿。
但當我拿到這些所謂的“專業設計稿”後，發現其實就是將原來的 JPG 檔案直接轉成 Zeplin。更糟糕的是，一些元素的水平對齊還出了問題，左右可能會相差 10 到 20 像素。
原本我以為這會是一個 RWD（Responsive Web Design）的網站，因為這是 Tim 告訴我的。但實際情況卻不是這樣。後來我們又開了一次會議，討論了這個問題。因為原來的設計稿只有 375px 的寬度，但有的 android 手機會超過 375px，所以一般來說會設定在 480px，這並不符合一般對 RWD 的設計需求。我提出了這個問題，並請設計主管作出決定。
設計主管的回應是，直接要求我用一個框弄起來，他要求我們只需要針對 480px 以下的螢幕尺寸進行設計。這就導致了一個問題：我們需要不斷地進行尺寸的換算，而這最終導致了實作出來的成果與預期有所出入。
整個會議過程中，我感覺到設計主管似乎並不太願意積極參與。他給人的感覺就是想要趕快結束這次的會議。因此，他最後決定讓我們用 375px 的設計稿來實作 480px 的網頁。
在會議結束後，我立即通知了 Tim（PM），讓他明白這個設計 其實並不是RWD，而是僅適用於移動設備(Mobile only) 。
設計部門主要成員都是女生，有一個是跟我們合作的設計師，跟她溝通時，她的溝通意願也很高，我也感受到她很有意願跟我們合作。
但是設計主管卻不樂意，設計主管時常說， 他很忙，沒空幫我們弄這麼多東西。 後來他甚至阻止起那個設計師我們交流，因為他認為過多了，個人認為滿奇怪的，畢竟這是公司將來重要的產品線，卻是被設計部門主管這樣對待。
在後來我有一次跟 Adam 討論起來時，他才脫口而出說， 設計主管是老闆的親戚 ，而且他好像是土木工程學還是地質學畢業的，跟設計一點關係都沾不上。
我瞬間就理解為什麼那個主管會一直不在線上了，可能我說的很多名詞他都聽不懂，所以決定也亂下，這導致了一大堆的災難。
總結來說，這次的經驗讓我再次體驗到了所謂的“外行領導內行”的困擾，以及所謂的“空降主管”帶來的各種問題。
正如我之前提到的，PM 將「Mobile Only」稱為「RWD」，這種用詞不準確直接導致了我對整個專案方向的誤解。而這樣的問題在這家公司層出不窮。
比如，他們會用「商店首頁」和「會員首頁」這種詞彙，讓我不禁思考：首頁不就是用戶首次訪問一個網站時看到的那個頁面嗎？
經過多次的溝通才讓我明白，他們所稱的「首頁」實際上是各個特定功能頁面的起始頁。也就是說，「商店首頁」指的是商店功能的起始頁，「會員首頁」則是會員功能的起始頁。在他們的語境下，一個 App 可能有多達十幾個「首頁」，這與我對「首頁」的一般理解截然不同。
為了釐清這個「首頁」的問題，我甚至與他們召開了數次會議。直到最後我才明白， 原來在這家公司，我才是那個對「首頁」一詞感到困惑的人。
後來，我特地查了「首頁」的正確定義：
首頁：全球資訊網站引導使用者進入該站的第一張畫面。經常提供該站的介紹、資源索引、使用方法或約定。
by 國語辭典：首頁
看來，我的理解並沒有錯。
這種對詞語的不準確使用不僅提高了溝通成本，甚至可能是一家公司招不到合適人才的隱性因素。
由於先前提到的多項因素，開發進度未能達到公司高層的預期。儘管我在會議中已經詳盡說明，並且積極與各方溝通，Adam 和 Tim 也有協助進行這方面的工作，畢竟這是他們的職責所在。
然而，最終的結果卻是我們前端團隊和 Adam 被迫加班趕工。根據 Tim 的指示，我甚至不能使用一些常用的開發套件，例如 formik 和 yup，即使這些工具相對簡單且容易上手。
因此，為了「迅速」完成任務，我只能退回到我最熟悉的原生開發方式。這讓我回到了像機器人一樣不斷重複使用熟悉技術的日子。然而，原生開發方式相對耗時，這也是為何會有各種便利工具出現的原因。
由於我全程使用原生 React 進行開發，這導致 Adam和 另一名前端同事難以理解我的程式碼。舉例來說，formik 能大大簡化 React 表單的開發，而 React 的原生表單寫法則相對抽象，特別是涉及 option 和 select 等元素時。
儘管為了加快開發速度，不必要的會議已被取消，但 Tim 後來幾乎如同消失一般，那些已完成、未完成等等任務管理負擔幾乎全落在我身上。
最終，這樣的壓力讓另一名前端同事選擇離職，我也隨後提出了離職申請。
另外，值得一提的是，那名前端同事已經找到了下一份工作，而且還是在一家大公司。這或許證明了我之前對他的指導相當成功。
在另外一名前端同事提出離職後，公司明顯改變了先前的強硬立場，顯得更為靈活，甚至願意調整工作時程。儘管如此，該同事依然堅持離職。Adam 在跟他溝通時，甚至提到我，表示還有很多可以向我學習的地方。最終，該同事選擇留下。
然而，我其實已經有離職的打算。當我正式提出離職後，該同事最終還是選擇走人。後來我的主管找我談話，希望能以加薪的方式留住我，但我已經找到了新的工作機會，並且薪資提升超過 30%。加上公司文化的種種問題，讓我更加堅定不再留下的決心。對我來說，心理壓力遠比工作負擔更為沉重。而且，我很懷疑這家接案公司能否開出如此高薪資。
離職後，我注意到公司的招聘需求有所變化。原先主要招募初階工程師，但在我離職後卻開始尋找資深工程師。然而，即便過了兩年，這個職缺依然未能填補。
可見公司終於知道資深工程師有多珍貴了。
這間公司提供了非常好的磨練機會，讓我有機會可以磨練自己，使得自己成長，而這麼高強度的溝通需求，應該也是前所未見，這很好的鍛鍊到我的溝通能力。
也讓我體認到溝通不是只有一個人的事情這件事，除了自己要有意願外，還要有對方的意願我們才可以順暢的溝通。
接案公司為什麼會不受軟體工程師的歡迎，也可以這幾天的文章看得出來，就是經常性地為了趕案子，會有壓時間的問題，然後是公司沒有制度，甚至還有一些不良的職場文化出現，這些我就不多說什麼，留待自行想像。
也因為沒有制度，所以如果有能力卻沒有挑戰機會的話，接案公司會給予一個人非常好的機會挑戰，就像我這次分享的文章那樣。所以再給我一次機會，我應該還是會願意下來挑戰自己一次。因為每一次的機遇都是最好的機遇，在這份工作中的經歷，也讓未來的我更加的強壯。
這篇文章就到這邊了，下一篇我們來談經鬆點的，也就是我這份工作之餘發生的一些趣事分享，跟通勤和租屋的比較。
謝謝你的觀看，希望你會喜歡這篇文章。
文章就說到這，有什麼想法或問題，歡迎隨時找我聊聊！
這篇文章也會同步發在 medium 上，如果有興趣歡迎追蹤我。
medium: https://medium.com/@hugh-program-learning-diary-js
email: u88803494@gmail.com
iThome鐵人賽
看影片追技術