轉職軟體工程師必備，但自學程式無法習得的重要技能
在 Twitter 專案中學到的有效溝通、多人協作、團隊使命感
如果目標轉職軟體工程師，無論透過什麼管道和課程學習，一定要給自己一次機會，找兩三位志同道合的朋友，一起打造一項產品。因為在職場中，與不同職能的夥伴合作才是真實情況。有效溝通、多人協作、團隊使命感，或更多合作技能，都是一個人面對電腦敲鍵盤學不到的。
“Alone we can do so little, together we can do so much.”
— Helen Keller
這篇筆記將回顧我在專案中，向我強大的戰友們 Russell、Leo、Liam 所學到的重要協作技能。
以專案角度看我們在團隊中的角色
在統整重點學習前，先簡述這是怎麼樣的專案、以及我們所做的：
3 ~ 4 人組團一同復刻 Twitter，是 ALPHA Camp 全端開發課程 中，所有畢業生的共同回憶。在這個專案中，我們需要以全端或前後分離的方式來開發，在兩週時限內完成指定及挑戰功能。
在這項專案中，我負責後端 API Server 開發，包含 API 文件起草、routes & controllers 初始化、登入註冊的認證系統、後台管理員操作及前台使用者數據綜覽等功能。在產品開發外，也肩負文件化、視覺化、工具化專案管理程序的任務，這個流程是夥伴們共同討論與不斷試誤中迭代出來的產物。
以限時專案的角度——平心而論，雖然我們對於提供優質的使用者體驗與高效能的系統運作不遺餘力，但整體產品仍有許多可以優化的地方，包含：
- 前端部分：部分畫面上不同區塊間的資料連動、部分表單元件更直觀的設計及操作體驗等。
- 後端部分：將部分服務與錯誤訊息獨立成模組、更詳細易讀的函式命名、以 ORM 限制欄位來處理資料取代
Array.slice()以同時達成效能提升與易讀性的目的等。
然而，在這個轉職生們一起打造產品的專案中，最寶貴的，其實是我們在真正進入職場前，就預習了業界實務必備的團隊協作技能。我認為，這不只是個能寫在履歷上的加分項目，而是扎實能在職場創造價值的「工作經歷」。
以下將逐項剖析，那些「轉職軟體工程師必備，但自學程式無法習得的重要技能」。
有效溝通
“Individual commitment to a group effort — that is what makes a team work, a company work, a society work, a civilization work.” — Vince Lombardi
在與許多軟體業的朋友、資深工作者的對談後，最常聽見大家異口同聲的關鍵能力，就是「溝通」。甚至，可以說不論哪個產業或場合，只要活著、需要與人互動，溝通就極其重要。
在這，我將聚焦在前後端分離協作、開發軟體產品的情境，當然，其中有許多原則是可以借鏡在不同的場合中。
對的媒介
幸福就這樣默默地降臨，我們意外地採用業界最佳實務（the best practice）。
—— Russell
Q: 什麼是有效溝通的正確媒介？
A:「API 文件就是前後端溝通的最佳媒介。」
在這次專案中，由於帶著一種「不能拖累隊友」的使命感，在專案開始前，就找了教材中、網路上一些 API 文件，依樣畫葫蘆地草擬了一份符合規格的文件。加上隊友的力挺，我們在開頭就使用了這份 API 文件草稿當作「前後端唯一的溝通媒介」。雖然經歷了幾番迭代、擴充、和近乎翻版的修正，但我們自始至終都以它來確認所有資料的提供。
而在專案第二週的工作坊、與向助教請益的 Tech hour 中，我們意外發現，業界唯一的前後端資料溝通管道就是 API 文件，而這份文件通常由資深後端工程師來撰寫，因其涉及資料操作、功能完整度、對使用者體驗的想像、未來擴充的變動性等。除了上述技術外，更涉及大量開發經驗與商業情境的理解。
對的方式
Q: 什麼是有效溝通的正確方式？
A:「我們永遠無法精確理解他人的想法，複述促進雙向的理解。」
在這次團隊協作之前，整個學習過程最花時間的部分是大量刻意練習，而在進入這個專案後，溝通成了最費心力的地方，無論在前端間、後端間、或前後端間的討論。因夥伴背景各異、價值觀與思維邏輯也各自不同，對於同一件事情的理解，甚至同一句話的涵義可能都有不同詮釋。
印象深刻的是，我們在專案剛開始時，就很快的進入前後端各自討論分工的階段。直到各自開發一半時，前端才發現缺少部分的資料、及某些路由給的資料內容不正確。
在這個插曲後，我觀察到夥伴間往往不厭其煩地反覆確認某些任務的小細節，並且透過複述來彼此確認對想法的理解程度。看似溝通時間增加，然而卻大大提升了往後的開發效能，並節省大量繞道的時間。
“The most important thing in communication is to hear what isn’t being said.”
— Peter Drucker
對的心態
Q: 什麼是有效溝通的正確心態？
A:「關注團隊及雙方的益處，而非彼此的立場，永遠有第三種解決方案 — — 叫做多贏。」
如果你對自己某些已知或未知的原則有所堅持，在與人互動時必然會遇到衝突，而這個衝突如何化解則仰賴雙方的態度與認知。
這次專案另一項印象深刻的經歷，是一次與後端夥伴 Leo 的討論。那通電話我們講了近 40 分鐘，主要目的在溝通現階段程式碼如何合併。說溝通算是客氣，那次我們以接近爭論的方式闡述彼此的原則和想法，我甚至一度以為對方打算把程式碼砍掉重練是因為生氣了。
雖然我們最後有了共識，專案也順利推進，我卻對這次的討論念念不忘，反覆推敲對方真正的想法、下次如何更好等。兩天後，在一次線上會議中，我們有機會把這個激烈討論的案例，拿出來分享並再次確認彼此想法。
直到那時我才發現是我多慮了，其實 Leo 沒有這樣的情緒。我們不只理解了彼此真實的情緒，更深刻地認知彼此觀點背後的動機與想法，也優化了日後的溝通模式。此後，各種的大小討論，我們都能敞開，且站在如何使團隊和彼此同時獲益的角度思考。這才是真正有效的溝通態度。
Win-win is a belief in the Third Alternative. It’s not your way or my way; it’s a better way, a higher way.
— Stephen Covey
多人協作
“None of us is as smart as all of us.” — Ken Blanchard
軟體業是少數我觀察到非常重視運用科技和方法論，以提升效能的領域；加上各項軟體開發技術逐漸發展與成熟，軟體產品的團隊職能與分工也漸趨清晰。以致運用各種工具輔助線上線下的多人協作，對軟體工作者來說稀鬆平常。
然而，眾人的智慧與才能若沒有充分的互補、結合與發揮，就無法產生一加一大於二的加乘效益。掌握對的原則、流程與工具，有助於提高團隊協作的總體產值。
對的原則
Q: 什麼是多人協作的有效原則？
A:「多人協作往往在反覆迭代中摸索出最佳模式。」
學到 Git 之後，肯定對於 Git Flow 的線圖不陌生，然而要精確的掌握每條分支的使用方法與時機，如何合併與更新遠端和本機的程式碼分支，我真的認為需要大量實戰（或試誤）與反覆練習。
在專案正式開始的第一天，我和後端夥伴 Leo 花了整整 8 小時討論我們的專案進度與分支策略，然而到了真正要上傳到遠端、下載至本機，才驚覺各分支的合併可能會產生衝突，因此常常戰戰兢兢、連線彼此確認，最後才跌跌撞撞摸索出一條路，而專案的前兩天就這樣過了；但我們也淬煉出一個能持續擴充與優化的流程，幫助後面所有的功能開發與進度推動。
就像上圖的發展過程，多人協作往往在反覆迭代中摸索出最佳模式。
對的流程
Q: 什麼是多人協作的有效流程？
A:「將 Git Flow 梳理出 SOP、並納入 code review、單元測試等開發過程注重的原則與步驟，彙整成備忘錄，以循序開發。」
上述提及的流程，最初其實只是一份備忘錄文件，條列了幾個階段。但由於大量的實作，才得以不斷擴充。上圖就是我們目前的最新版本，不只註記了各個階段要達到的成果或基本條件，更註記了許多細節與 Git command，以避免程式碼合併到錯誤的分支，或本地的程式碼版本產生衝突。
這份文件背後反映的，不只是 SOP，更包含許多原則與控管機制，包含：在程式碼品質不下降的情況中合併、每次的 code review 前有適當的單元測試、以測試機和正式機區分部署階段等。
對的工具
Q: 什麼是多人協作的有效工具？
A:「能視覺化專案現況與進度的看板工具，例如 Trello。」
比起文字，圖像更容易讓人記憶、理解概念與掌握全貌，專案管理的過程也不例外。在初步理出 Git Flow 的 SOP 後，我們便將流程建構在 Trello Board 中，每個 List 代表一個步驟，每張 Card 代表一個分支（同時也是一個功能與一項任務）。
會使用 Trello 的主因是，免費、有專門管理專案進度的看板系統、我也已長期用它來管理生活大小事。最重要的是，視覺化能有效幫助我們掌握整體進度現況。
團隊使命感
“Talent wins games, but teamwork and intelligence win championships.” — Michael Jordan
對的自己
Q: 什麼是團隊中合適的自身定位？
A:「反求諸己，勇於承認錯誤並動手解決問題，一同完成目標。」
在這次合作中，我觀察到我的夥伴們都有一種共同特質——反求諸己。當事情成就了，他們總先歸功於隊友的各種協助；然而，遭遇情況或出錯時，他們往往先承認自己的疏失，並積極思考接下來該如何解決。
我真的非常感謝與一群成熟有擔當的夥伴組成團隊，這樣的氣度，是我印象深刻的學習，也令合作過程，順暢了不少！
對的夥伴
Q: 擁有團隊使命感的人如何看待夥伴？
A:「團隊就是一種承諾，只要認定了就是對的夥伴。」
在這裡我想談的是承諾——一種感覺快被這個時代遺棄的品格。也許是後現代主義、個人主義和消費主義猖獗的現代，我們或多或少都染上了較常關注自己的慣性。（舉個例子，當拍完團體照後，你確認拍得好不好，通常是先看照片中的誰來決定呢？先承認，我就是會先看自己的人，但其實我很少拍照哈哈）
我認為，團隊就是一種承諾，當彼此認定後就是對的夥伴。這是一種對人本身的認同與接納。在這次的合作中，我真實感受到這樣的彼此接納與對待，我們原本都不認識、背景各異、在課程中的了解也不深，然而在一次很奇妙的叫賣般的組隊線上會議中，就這樣湊在一起。
在開始合作後，我發現我們作息不同（晨型人與夜貓子）、溝通模式不同、工作習性不同，更遑論性格、想法、思考方式等肯定不一樣了。然而，有一件事是我們堅持一致的——就是對彼此的承諾。
對的方向
Q: 如何定義團隊該往哪去？
A:「『用長遠眼光看仍舊重要的事物』，才是接近真實終點的方向。」
這次的團隊專案中，挑戰功能是倒數第三天的晚上才開放，為期兩天的一個黑客松（hackathon），目標是以 socket.io 這個套件，完成聊天室的三階段功能。
我們在第二天的上午才發現一個重大問題——就是前後端各自寫了一堆 code 之後發現合不起來，也不知道該怎麼測試。在查過各種資料後，仍找不到與我們同樣使用前後分離並在兩個不同專案的做法。隨著時間一分一秒過去，時限逐漸逼近，而我們卻無任何進展。
『我們究竟要妥協採用全端的方式以樣版引擎來完成？還是繼續想辦法攻克前後端分離的連線方式？』
最後，我們選擇了後者。以專案的角度來看，我們甚至連第一階段的挑戰功能都沒完成。然而我們不後悔，在這幾天的反思後，我發現我們真正具備了長遠眼光。（不代表選擇前者就不具備遠見，每個人和團隊的處境不同，我相信大家能做出最適合的選擇。而剛好我們是全職學習，也目標轉職，打算好好準備作品集。）
我們明白，在這個專案中，獲勝不是最重要的，而是在挑戰的過程中，我們累積了什麼。我們也相約在完成課程的各種回顧與期末技術考後，繼續以真實的 Twitter 為模板，復刻相關的功能，並優化這次未臻完善的各個環節。
我們有志一同地選擇了「用長遠眼光看仍舊重要的事物」。這不只體現在這項選擇中，也反映在我們挑戰專案時：仍不忘提醒彼此要休息、運動、陪伴家人，並確實身體力行這些重要的事物。
以職涯角度看我們在團隊中的角色
最後我想用另一個角度來定義我們在團隊中的角色 — — 以職涯的長度來衡量。承接上述：
我們有志一同地選擇了「用長遠眼光看仍舊重要的事物」。
我想用一個這兩年影響我很深的一個概念，「有限賽局與無限賽局」的差異來思考。（這也是此部落格專欄的核心價值之一）
以下這段引文及短片有非常精闢的解釋：
“A finite game is played for the purpose of winning, an infinite game for the purpose of continuing the play.”
— James P. Carse
若以有限賽局來思考這次的專案
- 我們可能會假想這次專案的好結果，就是轉職的敲門磚和入場券
- 或者可以拿到一個漂亮的畢業成績，在 AC 內推時可能會有加分的效果
在這些情境中，有限賽局就是接下來這一次的轉職、或者這個課程本身。
若以無限賽局來思考這次的專案
- 可以把這次專案當作一次模擬業界開發的實戰，在有時間與金錢壓力的限制中，快速完成初步產品，以盡早接觸用戶，再次迭代產品。
- 或者將之視為一個階段性的驗收並獲得反饋，雖過了專案挑戰時限，卻讓我們在求職前獲得可有效完成並優化這項產品的機會。
在上述情況中，真正的賽局是整個職涯——沒有明確獲勝條件、規則，且環境時刻變動、敵人與隊友皆未知的比賽。在這樣的賽局中，超前與落後都是暫時的現象，如何持續進行，才是最佳策略。
