Project 🚩隔離變化是並行工作的關鍵
筆者曾任職 Yahoo，現在區塊鏈產業打滾，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》
「快！快！快！！！」
每一位老闆心中都希望能夠盡快完成產品，無論是搶佔市場或是拉近和競爭對手的距離，專案執行的速度夠不夠「快」都是十分重要的考量。
這導致了專案中各組人馬需要並行地工作，因為沒有那個美國時間等 A 組全部做完，才輪到 B 組開工。通常是定好一個藍圖，A 組和 B 組同時開始做各自的部分。
━━
「並行工作」這個道理看似很好懂，但為什麼有些團隊執行起來一團亂，有些團隊卻能高效前行呢？
亂的原因在於變動 (Change)。可是在專案執行上，沒有什麼事情是不會變的，只有分「變動多」和「變動少」的差別，因此：
能不能有效地「隔離變化」是並行工作可否成功的重要關鍵。
假設有 10 個小組並行工作，小明是其中一個小組的組長，小明需要盡可能地讓組員以「變動少」的部分做為「起點」來開展工作。這也意味著組內工作內容的根基是穩固的，不容易被變化給擊倒。
━━
如何選擇起點來隔離變化呢？以軟體開發為例：
❶ 前端和後端工程師間，以 API 文件來隔離變化
先把 API 文件定義好，以 API 文件為起點，前端和後端工程師可以跟據 API 定義的請求 (Request) 和返回 (Response) 並行開工，不用互相等對方。當然，API 文件不是完全不會變，但通常變動不大，頂多是些欄位的微調，不影響主要架構。這個例子中，API 文件是「變動少」的部分，而前端和後端程式碼則是「變動多」的部分。
想想人們是常改程式碼還是 API 文件？當然是程式碼的改動多。所以，依賴變動較少的 API 文件來開展工作，可以降低變化帶來的衝擊。
❷ PM 和業務，以產品需求規劃文件 (PRD) 來隔離變化
PM 將功能定義在產品需求規劃文件 (Product Requirement Document, PRD)，業務就能開始依功能去想行銷方案。而 PM 可以轉頭與工程師協作，或是規劃下一期的產品功能。PM 和業務可以並行地工作，互不影響。
這個例子中，行銷方案是「變動多」的部分，而 PRD 是「變動少」的部分。即使行銷方案千變萬化，也很少會因為行銷方案突然要增加賣點，轉過來要求 PRD 新增功能的。
❸ 系統之間，以工程設計文件 (EDD) 來隔離變化
一間公司通常涵蓋多個系統，當軟體專案發起時，像朝湖裡扔一顆石子，改動的漣漪會擴散到其他系統中，因此需要預先定義漣漪的範圍。工程設計文件 (Engineering Design Document, EDD) 就是專門做這件事情的：定義有哪些資料庫會被動到、需要新增哪些架構元件、有哪些定期任務 (Scheduled Jobs) 需要調整等等。
漣漪的範圍一旦確定，工程設計文件就是「變動少」的部分，而程式碼實作則是「變動多」的部分。劃定好範圍可以避免在專案後期才發現：
「原來改 A 這項功能，還需要 B 和 C系統支援。」
「改了 A 系統，結果壞了 B 系統」
「B 系統剛好也在改這個地方，跟你們做的 A 功能衝突」
這些問題都會造成無謂的資源浪費：不僅本次專案的架構要改，別人系統的工程師也要跟著動起來。起因都是一開始就沒有把「變化」隔離好。
❹ QA 工程師，以測試案例 (Test Case) 來隔離變化
在工程師實作系統前，測試案例 (Test Case) 是可以先準備的。QA 工程師可以根據產品需求規劃文件 (PRD) 還有 API 文件來建立測試案例。
測試案例可以預先劃定測試範圍，告訴其他人「你打算怎麼測」也能夠提前把「測試觀點」植入實作的人心中，讓他們早期就想清楚各種邊界值限制、例外情況處理等等，避免後期工程師實作改來改去，新增校驗條件或是另開流程分支，讓測試腳本不得不跟著調整。
━━
無論是 API 文件、工程設計文件、產品需求規劃文件或是測試案例，都是用來隔離變化的「隔離點」：
這些隔離點就是你的護城河，在專案前期把護城河建立起來非常重要。
許多混亂的專案，通常是護城河沒有建立好，導致城門大開，讓「變動」魚貫而入，例如：產品定位模糊，功能改來改去，PM 疲於奔命地協調資源，後端工程師則加班趕工。API 變動導致前端工程師臨時補互動效果，而 QA 是最後一棒所以更慘，等到所有人做完，QA 最後測試驗收上線。
反之，如果能事先建立好隔離點，團隊形成共識後，依賴「變動少」的部分為起點開展工作 ，就能大大地降低變化所造成的衝擊。劃定好藍圖範圍，小組們各自衝鋒，才能讓並行工作的效果發揮到最大。
若是喜歡我分享的內容，歡迎幫我按個拍手，可拍 50下，給我一點鼓勵，或是加入我的粉絲團《程式猿吃香蕉🍌》，一起分享軟體知識與心得！
