# 團隊在系統開發上遇到了哪些問題 — 工程師血淚史

- 作者：林鼎淵（Dean Lin）
- 網址：https://deanlin.net/blog/202205/team-development-problems/
- 發布：2022-05-27
- 主題：團隊合作
- 系列：工程師血淚史
- 標籤：Scrum Agile、Team Collaboration、Team Management、Problem Solving、Retrospective
- 摘要：「我們學了很多方法，但在實務上卻各種出包。」我想這應該是很多開發團隊的心裡話，儘管大家都能看見問題，也嘗試導入各種方法試圖解決；但很多時候別說進步，有時甚至還會走回頭路，筆者剛好透過這個主題整理團隊過往遇到的問題；不過解決方案是否有效、會不會衍生新的問題，就看之後的連載了😅

「我們學了很多方法，但在實務上卻各種出包。」我想這應該是很多開發團隊的心裡話，儘管大家都能看見問題，也嘗試導入各種方法試圖解決；但很多時候別說進步，有時甚至還會走回頭路，筆者剛好透過這個主題整理團隊過往遇到的問題；不過解決方案是否有效、會不會衍生新的問題，就看之後的連載了😅

> 本文提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

```
大綱
ㄧ、客戶、專案經理、開發人員，3 者沒有共同語言
二、Scrum 淪為形式
三、專案到最後時刻才發現一堆 Bug
四、Tech Lead 沒辦法發揮應有的作用
五、團隊失去成長動能
六、不是每個成員都按照流程走
七、血淚小結

```

## ㄧ、客戶、專案經理、開發人員，3 者沒有共同語言

為了讓每個角色各司其職，在溝通需求時，都是由專案經理跟客戶溝通，得到結論後再跟開發人員說明。

儘管看起來很合理，但在實務上容易遇到以下問題：

1. **名詞定義**：同一個名詞，大家的定義都不一樣；這導致 3 者在溝通上雞同鴨講，彼此以為對方懂了，但根本在說不一樣的東西。
2. **專案經理與開發人員都不具備專案的背景知識**：如果碰上大型專案，在開發團隊沒有相關背景知識的狀態下，光是架構的設計就很容易出問題；又因為沒有相關背景，所以根本沒有共同語言。
3. **規格書不明確**：開發人員按照規格書來開發，但如果規格書很模糊，工程師在開發時會浪費很多時間在額外的溝通。（最悲慘的狀況是工程師放棄溝通，選擇按照直覺來開發）

上面的問題，想嘗試透過以下方法解決：

1. **專案經理與開發人員以「英文」來溝通欄位**：資料庫都是英文欄位，如果規格書上的欄位都以中文表達，就不能怪工程師在開發上直接選擇「感覺」意思最接近的欄位。
2. **由專案經理建立一套「中英文名詞定義對照表」**：內部可以用英文律定欄位，但跟客戶溝通時，大多情況還是使用中文；所以需要建立一份對照表，避免彼此的誤解。
3. **需求規格參數明確**：對客戶來說好像差不多，但對工程師來說，差一個欄位就好似差了一個宇宙。

## 二、Scrum 淪為形式

我們期待導入「Agile(敏捷)」開發後，可以提升團隊的生產力、向心力，但實際上會遇到以下問題：

1. **只在意自己要講什麼**：跑 Scrum 的原意是希望大家瞭解彼此工作的進度，透過資訊透明讓專案更加順利；但很多時候我們只在意自己今天要講什麼，這種狀況在 Scrum Master 為固定人選時更為明顯。
2. **規格不明確導致需求時常變更**：在 Sprint Plan 時，我們會先估點來計算每個人工作需要的時間；但在開發階段若發現規格有問題，專案經理就要再跟客戶溝通，這一來一往與程式調整的時間，將會完全破壞這個 Sprint 預計要完成的項目。
3. **安排額外的任務**：如果臨時安排不在這個 Sprint 的任務給工程師，又沒有明確告知任務優先度，當這種狀況頻繁發生時，Scrum 就變成單純的個人報告，工作內容逐漸與 Sprint Plan 脫鉤。

上面的問題，想嘗試透過以下方法解決：

1. **讓每個人輪流當 Scrum Master**：在這個位置上，就算不願意，你還是得知道每個人的進度、卡住的問題、要做的事。
2. **指派任務前，充分確認客戶需求**：如果在商談時就定下明確的需求規格，那工程師就有開發的依據，發現邏輯問題時也能第一時間提出，不至於自由發揮到一半才發現問題。
3. **盡量不要讓突發狀況影響現在的 Sprint Plan**：工程師也是人，臨時安排的工作勢必會影響到現在的專案，如果可以，突發的狀況盡量安排到下個 Sprint。

## 三、專案到最後時刻才發現一堆 Bug

我們花 20% 的時間完成 80% 的功能，卻在最後 20% 的功能上花了 80% 的時間。

如果問題發生不只一次，那肯定要想辦法解決；通常會有這樣的狀況是因為：

1. **架構規劃不良**：專案啟動後，一開始大家都是摸著石頭過河，無法確定自己現在的方向是否正確；往往到後期，才發現當初的規劃有某些後遺症。
2. **前期進度按照時程走很安心**：因為前期每個 Check point 都很準時，所以產生接下來也會繼續準時的心理預期。
3. **想要一次交卷**：有時我們會想等作品完成到某個程度後再給客戶看，但…有時客戶看過後會發現許多與他們理念不合的設計。
4. **新舊系統功能不吻合**：就算功能都是 Copy＆Paste，但程式底層的運作邏輯往往不同，部分欄位可能也存在誤會；你以為執行得很順利，殊不知早已偏離方向。

上面的問題，想嘗試透過以下方法解決：

1. **別管架構，先交出 MVP**：我們規劃了太多功能，卻沒有一個 MVP，在一切都不明朗的狀態下，能規劃出好架構根本是靠運氣；與其在前期完成那麼多功能，還不如先交一個勉強能動的 MVP，以此向客戶確認是否符合需求。
2. **在一開始規劃時，就把容錯時程拉長**：過往的經驗告訴我，意外通常在最後一刻才發生；因為在後期，我們才有辦法用整體的思維去看專案。（如果團隊有經驗非常豐富的架構師，那有機會規避這些問題，筆者目前還不具備這個實力）
3. **開發階段頻繁更新系統**：讓客戶隨時體驗最新的功能，如果與預想不合也可以盡快作出調整；避免工程師要砍一堆程式，做無意義的重工。
4. **如果要改寫舊系統，就需要對方提供可以驗證的資訊**：通常舊系統程式的參考價值不高，我們只能從操作流程來推估資料間的關聯性，但這些「都是靠想像」的，如果客戶沒有提供足夠的舊系統操作案例給工程師來驗證，就很可能開發出無法與舊系統銜接的系統。

## 四、Tech Lead 沒辦法發揮應有的作用

我們期待 Tech Lead 可以照顧到整個團隊的技術，但如果開發時程太趕，在 Tech Lead 也投入大量時間在開發時，會衍生以下問題：

1. **Code Review 淪為形式**：連自己的任務都快做不完了，Code Review 時頂多看一下 Coding Style，沒辦法從整體的架構去判斷他的演算法、邏輯是否合適。
2. **專案程式碼品質下降**：因為 Code Review 不確實，很多功能只是為了解決當下的問題，這種時候很容易創造出一堆耦合性高的程式。
3. **沒辦法顧及所有人的進度**：如果專案經理與 Tech Lead 配合不夠默契，那很容易發生 Tech Lead 埋頭開發，沒有從整體的視角來看專案的進度。

上面的問題，想嘗試透過以下方法解決：

1. **分配給 Tech Lead 的開發任務，不要超過他 60% 的工作時間**：如果把 Tech Lead 當單純的 Developer 來使用，那團隊程式碼的品質就無法保證；為了避免日後要花更多的時間解決後遺症，建議多給 Tech Lead 一些靈活運用的時間。
2. **專案經理與 Tech Lead 訊息流暢**：就算有專案管理系統輔助，但每個任務進度的細節、時程還是專案經理最清楚；如果能在發現進度 Delay 前期就做適當的調整與釐清，也許不會走到時程緊繃這一步。
3. **律定專案管理系統操作方式**：開發人員 Commit 的內容也需要附註在 Ticket 上面（盡量白話），這樣更方便專案經理掌握實際進度；若該 Ticket 有相依性（後端完成後交付給前端），那開發人員也要將相關的 API doc 附在上面。

## 五、團隊失去成長動能

我們期待團隊裡的每個人都能夠隨著專案持續成長，但在管理出現問題時，團隊會慢慢轉變為 80/20 法則的模式，也就是 20% 的人完成了 80% 的任務，下面是筆者個人推估的原因：

1. **到 Deadline 時，總有人能幫忙解決問題**：如果團隊成員發現沒做完的東西，在接近 Deadline 時就會有其他人來拯救，那很可能就會養成依賴性，喪失自己解決問題的能力。
2. **獎懲機制不夠透明**：如果大家發現拼死拼活的結果跟躺平耍廢一樣，那我們為什麼不躺平？
3. **連坐制度**：Deadline 就壓在那裡，你幫了，他無法成長；你不幫，專案就爆掉，自己也跟著倒霉，這種狀況到底要幫還是不幫？

上面的問題，想嘗試透過以下方法解決：

1. **幫忙時只給方向**：可以提供一些關鍵字、網頁、參考資料、過去的程式碼，但不要直接解決問題。
2. **如果必須親自解決問題，先確認對方已經發揮所有潛能**：儘管我們都希望給方向就能解決問題，但每個人的背景知識不同，如果給方向還是無法解決；在親自解決問題前，要先請對方說出自己過去所做出的研究，確保他已經盡力，任務難度真的超過了他的能力範圍。
3. **不影響健康的壓力**：如果發現成員的能力有提升的空間，那或許可以提醒他，適度犧牲下班後與放假的時間持續鑽研是必須的，唯有做足功課，在上班時才能更快地趕上大家的腳步。
4. **律定獎懲機制**：我們希望每個人都有想成長的自覺，但如果有必要，賞罰機制還是要存在的。

## 六、不是每個成員都按照流程走

我們秉持互信的原則來合作，就算有些人沒按照流程走，只要不出包，也可以睜一隻眼閉一隻眼；但如果這些行為產出的結果不符預期，甚至導致團隊損失，那勢必要做出改善。

這邊就以程式碼 Commit＆Push 舉例，原則上我們期待每位開發人員一天至少 Push 一版程式，且裡面 Commit 都有詳細紀錄更動的部分。

會有這個要求是因為專案是「協作」的，如果有人憋了一個禮拜才 Push 一大包，會衍生以下問題：

1. **Tech Lead 很難 Code Review**：因為內容太多、太雜，釐清功能所需的時間反而更多。
2. **如果架構有問題，改善成本太高**：如果在 Code Review 時才發現程式的結構問題，那又需要浪費很多時間改寫。
3. **如果把所有更新的內容塞到一個 Commit 裡面，很難對應功能與程式**：因為程式往往散落在多個檔案，如果 Commit 內容太多，就很難知道彼此的對應關係。
4. **萬一發生狀況，接手的人會崩潰**：如果做完的功能沒有 Push 上去，接手的人等於要重寫。

上面的問題，想嘗試透過以下方法解決：

1. **向開發人員說明定時 Commit＆Push 的重要性**：開發人員可能不知道自己這麼做會影響到其他人，需要講清楚問題嚴重性。
2. **如果任務太複雜，盡量做功能上的切分**：有時被分配到的任務涉及面太廣，導致遲遲不敢 Push 上去；面對這種情況，可以依據開發的進度來 Commit＆Push，反正有 Git 這種程式碼版控系統，不會影響到主分支。

## 七、血淚小結

1. 問題是長期沒改善積累而成的，想解決肯定會遇到不少阻力。
2. 只有被攤在陽光下的問題，才有機會被解決。
3. 許多問題互為因果，如果不解決，問題會像病毒般不斷變種。
4. 每個人都在適應自己的角色，專案經理不知道需求規格怎麼寫才能讓開發人員理解，開發人員不清楚遇到問題時要如何解決，Tech Lead 不確定怎麼帶人才是最合適的。
5. 規則律定出來就要執行，如果沒有執行；那其他乖乖遵守規則的人，也遲早會學壞。

```
工程師血淚史
 團隊在系統開發上遇到了哪些問題(本篇)
 需求不斷變更，到底哪個環節出錯了
 當 Scrum Master 跟 PM 同時存在，權力與責任該如何區分？
 如果沒有明確的開發流程，團隊將會無所適從
 你知道對專案來說，README.md 有多麼重要嗎？

```

---

關於作者：林鼎淵（Dean Lin），台灣的生成式 AI 企業內訓講師、外商資安公司軟體專家，也是生成式 AI 創新學院發起人。出版 7 本書（包含全台第一本 ChatGPT 應用專書），兩度獲得 iThome 鐵人賽佳作，累積上百場授課與顧問經驗。（https://deanlin.net/about/）
引用時請附上原文網址：https://deanlin.net/blog/202205/team-development-problems/