對不了解系統上線流程的人來說，他們會覺得這不過就是個小調整，為什麼每次都要我三催四請的？

對開發的工程師來說，他們會覺得這些人有完沒完啊？這些文字不是都已經討論過了，為什麼每隔幾天，甚至幾小時就要改一次？

實際上，改動文字對工程師來說可能花不到 1 分鐘的時間。

但對有上版流程的公司來說，每次更新可能都要花 1 小時以上（就算只有改一個字）。

今天這篇文章不是要談誰對誰錯，或是如何用技巧來迴避問題；而是要分享面對問題時，可以如何一步步「解決」他。

文章寫完後，感覺自己在寫技術發展史；另外，這是朋友向我分享的經驗，絕對不是我自己的。

石器時代：寫死在程式碼

在最遠古的時期，網頁上的文字是寫死在程式碼的。

雖然直觀，但維護性極低。

因為面對「修改文字」的需求變更，開發人員可能改了 A 頁面，卻忘了還有 B、C、D 等頁面也用到一樣的詞彙。

大航海時代：建立語言包維護

如果系統只用同一種語言，那寫死在程式還勉強能維護。

但如果接下來要進軍國際市場，有中、日、英、法等多國語系的需求時，我想工程師就會崩潰了。

因為寫死在程式碼是完全行不通的，雖然很痛苦，但開發人員會需要把系統中所有的文字抽出來，建立「語言包」來維護才能解決這個需求。

這樣未來在面對「修改文字」的需求變更時，開發人員只要在單一檔案處理，透過模組化的管理，可以大幅降低遺漏的可能性。

工業時代：提供 Google Sheet 讓產品方填寫

把文字集中到語言包維護後，其實面對修改文字的需求就很容易處理了。

但…接下來要討論的是「人」的問題。

因為產品方會一直看系統的文字，看著看著可能就覺得哪裡不順眼，不順眼就要改！

所以在新版本上線後，可能一週內會收到多次文字變更的需求。

在這樣的狀況下，現實生活中最容易遇到的就是「漏訊息」；當訊息有前後因果關係、重複資訊的時候，失誤在所難免。

為了減少產品方打擾 PM 與工程師的頻率，以及減少訊息遺漏的問題。

提供一份格式律定好的 Google Sheet，讓產品方在線上「修改文字」是一個不錯的方案。

這樣雙方約定一個時間一次性更新即可（會跑一個將 Google Sheet 轉成語言包的腳本）。

科技時代：直接透過管理介面修改文字

改成 Google Sheet 後，雙方和平了好一段時間。

但還有一個問題，那就是這種修改沒有「即時性」。

因為程式每次上版都需要 Build Docker Image、跑回歸測試、上多個環境確認…

你可以理解為這些步驟至少要花費一小時以上的時間，而且會涉及到不同團隊的人（開發、QA、PM…）。

如果今天只是要修改文字，這樣的操作完全不符合成本效益。

所以目前的最新方案，就是在後台管理介面中，新增修改文字的功能，讓產品方可以依照自己的需求即時進行調整（搭配預覽頁）。

總結

修改文字是一個常見的需求變更，而且很多時候是在系統上線後才發生。

對工程師來說，修改文字這件事的確很簡單，但背後所需花費的時間與人力成本其實很高。

相信看完這篇文章後，大家可以理解為什麼有些小變更需要等一段時間才能更新。

儘管這篇不是純粹的技術文，但還是提醒一下讀者，每個時代的演進都需要不少時間成本。

這些改進所用到的技術並不困難，但問題在於：

• 有足夠多的時間來做優化嗎？
• 這個問題真的有優化的必要性嗎？
• 優化帶來的效益符合成本嗎？

因此千萬不要看完這篇文章後，就拿他去跟工程師吵架，我可不背這個黑鍋。

也許最後的方案在不久後會遇到其他挑戰，但這不就是「有問題我才有工作嗎？」

身為工程師，我理解大部分的人都想把精力放在寫出更好的程式，但專案能否長期發展，其實是取決於「文件」；如果文件亂七八糟，或者甚至根本沒有制式文件，那這個專案的未來發展性堪憂。

從管理的角度來說，我們要去思考：「如果負責專案的工程師明天就不在了，這個專案能否進行下去？」

大綱
一、為什麼 README.md 很重要？
二、有哪些是 README.md 一定要提供的資訊？
 ➤ 專案介紹 — Description
 ➤ 運行環境需求 — Requirement
 ➤ 環境檔（.env）有哪些欄位要自己填寫 — .env Setting
 ➤ 在 Local 端的安裝＆運行步驟 — Build Setup(Local)
 ➤ 在 Server 端的安裝＆驗證步驟- Build Setup(Server)
 ➤ 可提供支援的同仁 ── Support
 ➤ 注意事項 — Warning
三、如果 README.md 有這些資訊，會讓日後維運更加順利
 ➤ 系統架構圖 — System architecture
 ➤ 使用者操作手冊 — User Manual
 ➤ Demo 影片 — Demo Video
 ➤ UI/UX 設計稿 — UI/UX Design
 ➤ Function map
 ➤ 單元測試、整合測試 — Unit Testing、Integration Testing

一、為什麼 README.md 很重要？

因為開發人員第一次接觸專案時，就是透過 README.md 來了解的。

它就像是一張專案的地圖，如果破損、缺乏維護，那踏上旅途的人勢必會遇上迷航、陷阱。

在沒有律定 README.md 該有什麼內容時，每個人都是自由發揮；除了內容可能有短缺外，每份專案的撰寫風格也不盡相同，因此想透過這篇文章律定基礎架構。

這邊提醒讀者，本篇文章所建議的 README.md 內容是提供給「內部開發人員」看的；如果你的專案是對外開放，部分內容請自行斟酌。

二、有哪些是 README.md 一定要提供的資訊？

下面列出的項目，是筆者認為對第一次接觸專案、準備維護專案的人有幫助的資訊。

專案介紹 ── Description

簡述專案目標，讓第一次接觸的人也能在短時間初步了解專案（如果使用到少見的專有名詞，請附加說明）。

如果是前後端分離的專案，請附上前端/後端的專案連結。

運行環境需求 ── Requirement

描述這個專案運行所需要的環境，比如說：

• 前端（Frontend）：NVM、Yarn、Node.js
• 後端（Backend）：PHP、Composer、Laravel、MySQL

隨著技術進步，各項工具的版本不斷更迭；因此建議要附上能讓專案順利運行的「版本」，因為許多工具並沒有向下相容。

環境檔（.env）有哪些欄位要自己填寫 ── .env Setting

以後端來說，涉及機密、隱私、個人化的參數會需要自己填寫，比如：

1. DB 帳號密碼、IP、Port
2. JWT 有效期限
3. Mail 相關參數
4. Storage 路徑

在 Local 端的安裝＆運行步驟 ── Build Setup (Local)

是那種「複製貼上」就能夠順利安裝的步驟，可以放一些參考連結，但不要讓使用者需要去閱讀官方文檔才知道怎麼安裝。

以後端舉例，指令需至少包含如下內容：

1. 專案安裝步驟
2. DB Migration
3. DB Seeder
4. 運行專案

如果採前後端分離，可以附上 POSTMAN 的 collection 方便前端驗證。

在 Server 端的安裝＆驗證步驟 ── Build Setup (Server)

如果不是採取自動部署的策略，那筆者建議紀錄如下內容：

1. 專案運行所需套件，及其對應的指令
2. 伺服器端參數（ex：API 最長可執行時間、可上傳檔案容量限制、單個 IP 每分鐘存取次數）
3. 不同環境對應的 Server ip
4. 相關參數調整後，重啟使其生效的指令
5. 部署完成後，可以透過什麼方式（工具）驗證功能皆如預期運行

可提供支援的同仁 ── Support

讓初次接觸專案的人知道遇到問題可以找誰詢問，建議在這個部分放上開發人員的聯絡方式（ex：座位、email）。

有時問題可能有其歷史背景，所以可以用附註形式，放上了解這份專案歷史的同仁（ex：主管、負責的 PM）。

注意事項 ── Warning

每個專案或多或少都會有一些特別的設計，時間拉長難免遺忘，建議把他們記錄下來，比如：

1. 如果 API 文檔是用指令產生的，請記得記錄下來
2. 如果有設計排程（Schedule），把觸發的時間點列出
3. 前端在不同環境的建立指令（Script）
4. 如果用到特別的套件，建議簡單說明在什麼時機應用，並放上官方文檔連結
5. 專案的授權條款（License）

三、如果 README.md 有這些資訊，會讓日後維運更加順利

系統架構圖 ── System architecture

如果專案結構複雜，或是需要串接多個系統，那建議放上系統架構圖，否則接手的工程師會需要花很多時間去研究他們之間的關聯性。

使用者操作手冊 ── User Manual

每份專案都一定要製作使用者操作手冊，否則 PM、工程師會不停被重複的問題打擾；有了這份手冊後，之後負責維運的工程師也能更快上手。

形式可以是 Wiki、Word…等等，讓使用者方便閱讀為第一優先。

Demo 影片── Demo Video

如果可以，建議在專案完成後錄製「簡單」的 Demo 影片；主要目的是讓工程師知曉專案「正常」的狀況下應該長什麼樣子。

有時專案看似順利啟動了，但實際上部分功能是不完整的（ex：前端順利啟動了，但 WebSocket 異常）。

UI/UX 設計稿 ── UI/UX Design

放上 Wireframe、Mockup、Prototype 等設計稿連結（如果有的話）

Function map

通常會以心智圖來呈現，PM 可以透過它讓工程師快速了解、評估初期的功能。

在遇到需求要新增或變更時，有這張圖工程師能也更快回憶，並掌握重點。

GitMind 是個不錯的工具，推薦大家使用看看。

單元測試、整合測試 ── Unit Testing、Integration Testing

專案的穩定，是建立在有寫測試程式的前提下；否則系統很容易因為需求的新增、變更，而導致過去的功能毀損。

在測試方面，除了「整體」的測試外，有時我們只需要測試「特定功能」；可以把常用的測試指令紀錄在這裡（ex：邏輯複雜、關聯廣泛的測試）。

以上內容是筆者過去專案經驗的彙整，若有未盡之處，歡迎留言補充。

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

由於過去許多工作流程都是口頭制定，沒有明確的文字敘述，因此想透過這篇文章來整理流程，並在日後的實踐中不斷優化與完善。

大綱
ㄧ、專案初始
二、初始任務
 ➤ 評估每個階段的時程
 ➤ 撰寫 Ticket 的需求規格
 ➤ 估計每個 Ticket 的時數
 ➤ 確認 Ticket 的總時數是否在專案的截止日期內
 ➤ Ticket 分配
 ➤ 專案初始環境建置
 ➤ Server 建置
三、專案進行中
 ➤ 進度回報
 ➤ 工程師之間的合作
 ➤ 工程師與 PM 的合作
 ➤ 了解為什麼都要由 PM 來開 Ticket

ㄧ、專案初始

STEP 1：由 PM 與客戶討論具體需求。

STEP 2：請 UI/UX 設計師依造需求初步完成 Wireframe。

STEP 3：PM、UI/UX、Tech Lead 一起確認流程、功能的可行性，判斷是否有需要調整的部分。

STEP 4：待客戶認可 Wireframe 後，請 UI/UX 設計師將其升級成 Mockup。

STEP 5：由 Tech Lead 確認 Mockup 上需要注意的細節（ex：哪些欄位適合拿來搜尋、不同權限看到的畫面、有哪些元件可以設計為共用模組）。

STEP 6：在 UI/UX 設計師調整為 Prototype 後，由 PM（或 UI/UX 設計師）向團隊成員說明系統的功能與流程，確保大家理解這個專案要完成的目標。

STEP 7：由 Tech Lead 向工程師團隊說明各功能在設計上要注意的細節（ex：哪些欄位要設計 Auto-Complete、是否有特別的 Validation Rules、某些功能需要提前 Survey 避免卡關）。

良心建議：專案初始的設計盡量從 Wireframe 開始，就算專案規模較小也不要直接畫 Mockup；因為客戶的需求在前期會時常變動，就算突然加大投資，小專案突然變成大專案也是很常見的，若使用 Mockup 會要花更多的時間在調整上面。

二、初始任務

評估每個階段的時程

由 PM 將專案的需求拆分成不同的 Phase，這樣工程師比較能集中注意力在特定事物上，每個 Phase 都需要把如下的任務納入考量：

1. 要完成的功能（ex：前端、後端）
2. 撰寫測試程式的時程（ex：單元測試、壓力測試）
3. QA 團隊測試的時程
4. 測試、正式環境部署的時程

規劃時要保留「緩衝時間」，因為測試一次就過基本上是不可能發生的事情，往往需要預留 15~30% 的時間來修 Bug。

撰寫 Ticket 的需求規格

由 PM 在專案管理系統上為每項任務建立 Ticket，建議需求規格的內容要包含：

1. Prototype 截圖：讓工程師明白功能具體的位置在哪。
2. 需求描述：說明這個功能是用來做什麼的，它跟哪些功能有相依性。
3. 相關計算規則：以計算商品總價來說，就會有「產品搭配、折價卷、信用卡優惠…」等多種排列組合。
4. 使用的邏輯：搜尋欄位可以查詢的欄位有哪些？搜尋的邏輯是 And 還是 Or？
5. 關聯需求：像是後端做完 API 後交付給前端，就需要將兩個 Ticket 關聯。

估計每個 Ticket 的時數

不同 Ticket 的難易度不同，這邊會由 Tech Lead 分別向 Frontend、Backend 工程師確認 Ticket 的估時。

此時工程師千萬不要勉強自己，估出一個很難完成的時數，不然在卡關時，會影響到後續一系列的時程規劃。（但也不要估出不合理的時數）

如果某個 Task 預估的時程超過 6 小時，建議要再做細分，否則很難衡量每天實作的進度。

確認 Ticket 的總時數是否在專案的截止日期內

只要是專案就一定有截止日期，如果將每個預估的時數加總後，發現已經超過了專案的截止日期，那勢必要做一些調整，比如：

1. 簡化部分功能（ex：原本要用 Auto-Complete，現在改用一般的搜尋）。
2. 規劃 MVP 先交出去讓客戶使用（ex：原本要經過一系列複雜的流程才能建立的資料，先用 Seeder 代替，以此大幅減少工程師的開發時程）。

這邊不建議堅持原計劃完成所有功能，因為快速開發所累積的技術債，於未來要花更多的時間處理。

Ticket 分配

由 PM 規劃在這個 Sprint 中要完成的 Ticket，然後在 Sprint Planning 時進行細節分工；假設一個 Sprint 為 2 週，建議每個人身上掛的 Task 時數不要超過 60 小時，因為：

1. 時常會有臨時的會議、需求、Bug…等意外事件，需要保留緩衝時間。
2. 在專案的初始階段，我們無法保證是否由遺漏的規劃、邏輯的錯誤，若把時間塞滿就很難有轉圜的餘地。
3. 舊的維護專案，有時會有緊急的狀況需要優先處理，這也會吃掉不少時間。

專案初始環境建置

由 Tech Lead 或是 Senior Engineer 負責專案初始環境建置，初始化的專案需要在 README.md 中有以下說明：

1. 環境需求：Node.js 版本、PHP 版本、MySQL 版本…
2. 如何在 Local 端建立：安裝流程、環境變數…

Server 建置

由 Tech Lead 開出專案系統所需的硬體配置（正式機、測試機）、DNS、要安裝的軟體/套件（ex：Ubuntu Server、MySQL、Node.js、PHP…各自的版本），並請 PM 填寫需求單讓 MIS 依照此規格進行建置。

三、專案進行中

進度回報

如果團隊有使用專案管理系統，為了日後方便追朔與釐清狀況，建議填寫的內容如下：

1. 如果實作的方向是討論出來的，請紀錄「與會人員」與「決議結果」。
2. 如果使用到特別的演算法、技術、套件，請特別附註。
3. 如果該 Ticket 完成後要由其他人接手處理（ex：後端完成 API 後交付給前端），請說明要執行哪些指令（ex：DB Migration、Seeder…），並提供相關的 API 文件。
4. 如果發現該 Ticket 完成所花時間與當初的估計有所不同，請與 PM 討論並調整。

工程師之間的合作

1. Ticket 執行順序：一個 Sprint 中，每個工程師都會有很多的 Ticket，但有些 Ticket 會有所謂的「前置條件」，建議在開始作業前要先彼此商議，避免出現等待的空窗期。
2. 回報 API Bug：請說明是在「哪個系統」、「哪隻 API」、「什麼參數下」會發生。
3. 回報 Web Bug：請說明是在「哪個系統」、「哪個畫面（截圖）」、「什麼操作下」會發生。
4. 遇到自己無法解決的問題：請說明是在「哪個系統」、「哪個 Ticket」、「你做過哪些嘗試」、「你認為可能的解決方案」。

工程師與 PM 的合作

1. PM 請工程師完成 Sprint 以外的需求時，請說明「任務優先度」、「為什麼會有這個需求」、「可以先將哪個 Ticket 排後面一點」。
2. 如果工程師在開發過程中收到其他團隊的需求，請將對話窗口轉移到 PM。
3. 如果工程師要請 PM 協助開 Ticket，需描述：「哪個系統」、「要處理的任務/Bug」、「預計要做的事項」、「預計完成所需時間」。
4. 若身上的 Ticket 數量爆炸多、任務分配不均，請及時反應。

如果是同一個專案，我們可以輕鬆的排出任務的優先順序；但如果多個專案同時發起優先度高的任務，工程師在這種狀況下會不知所措，需要由 PM 協助排出優先順序。

了解為什麼都要由 PM 來開 Ticket

1. 如果大家都自己開 Ticket，PM 會無法掌握每個人實際在做的任務，即使有 Tag 到 PM，PM 也未必有辦法看到每一則訊息。
2. 工程師心中的任務優先順序可能與 PM 不同，這會造成最後在核對完成的任務時，因為彼此的認知落差產生爭執。
3. 每個任務完成所需的時間成本不同，可能有些任務是可以不必做，又或者是能交給其他人去做的，讓 PM 從整體的角度去看較不會出現勞逸不均的狀況。

制定大家願意共同遵守的工作流程，在了解彼此的權利＆義務後，相信團隊的運作會更為順利；文章的流程未必適用於每個團隊，僅為筆者過去經驗的彙整。

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

這篇文章將與您分享我們是如何調整，以及調整後發生哪些改變。

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

大綱
ㄧ、調整的目的是什麼？
二、定義 Scrum Master 跟 PM 的權限
  ➤ Scrum Master
  ➤ PM
三、調整後發生哪些改變
  ➤ 成員對專案、團隊有更深刻的認知
  ➤ Scrum 參與度提升
  ➤ 回顧時發表更踴躍
四、總結

ㄧ、調整的目的是什麼？

明明跑的是 Scrum，卻沒有團隊合作的感覺。

每間公司跑 Scrum 的方式與目的不同，有些 Scrum 跑起來更像是傳統的工作匯報；即使在身處在同一個會議中，卻只有主管跟 PM 關心每個人的工作內容。

如果團隊成員不關心彼此的工作內容，單獨匯報或是用紙本報告其實更加省時；開 Scrum 的目的是希望大家了解彼此的任務，確認是否有需要調整的地方，避免任務的先後順序、優先度搞錯，導致專案進度延宕。

但如果只是口頭上說希望大家積極參與，實際效果就跟老師要學生好好聽課一樣，因此想透過流程來進行改善。

而我們選擇的方案是 — 讓團隊成員輪流擔任 Scrum Master。

二、定義 Scrum Master 跟 PM 的權限

我們希望在提升成員參與度的同時，盡可能不要增加負擔。

因為 Scrum Master 的工作內容與 PM 高度重疊，如果沒區分好彼此的界線，勢必會導致其他成員的困惑，比如：

1. 開單要找誰？
2. Sprint Planning 的規劃由誰負責？
3. 需求規格由誰來寫？

所以我們做了如下區分：

Scrum Master

1. 主持 Daily Scrum Meeting：了解每個人工作的進度、預計要做的事、以及遇到的問題。
2. 主持 Sprint Review、Retrospective 會議：讓大家報告在這個 Sprint 中做了什麼，有哪些好的可以繼續保持，有哪些壞的要進行調整。
3. 參與 Sprint Planning 會議：了解下個 Sprint 要完成的事項。

PM

1. 專案管理：追蹤成員的進度、討論需求、協調資源…原則上工作內容不變，只是部分工作交由 Scrum Master 主持。
2. 輔助 Scrum Master：儘管已經簡化許多 Scrum Master 的工作，但因為部分成員並沒有接觸過敏捷開發，因此需要幫忙拾漏補遺。
3. 規劃 Sprint Planning：無論是規劃要完成的工作，還是與每位工程師確認工時，都是需要花費不少心力的任務，因此主要還是由 PM 專職處理。

之所以這樣設計，是希望成員在擔任 Scrum Master 的同時，儘可能不影響到他的本職工作，我們期待這樣的流程可以讓每位成員更融入專案，而不是取代 PM 的工作。

三、調整後發生哪些改變

目前實行了 3 個 Sprint，成員的接受度還算高（希望不是敢怒不敢言 😅）。

成員對專案、團隊有更深刻的認知

不管是否願意，主持 Daily Scrum 時一定要了解每個人具體的狀況；原本專注在自己任務的人，也會因為主持 Sprint Review、Retrospective 而強迫了解整個專案，並更加認識團隊。

Scrum 參與度提升

因為 Scrum Master 是輪流的，如果我今天不給你面子好好聆聽跟報告，下次換我當 Scrum Master 時可能大家會不理我；同儕間的心理因素會讓參與度變得更高（但這個情形未必適用在每個團隊身上）。

回顧時發表更踴躍

由成員來做 Sprint Retrospective 時，大家相對來說更敢發表意見；這就跟同學分組討論時比較熱絡，但當老師問同學有沒有問題時，台下直接靜音的道理一樣。

四、總結

花的時間越多，就會越認真投入。

其實並不是每位成員在剛開始的時候都願意跑 Scrum 的，因為他們覺得這是在浪費時間、單純走一個形式、對專案沒有幫助…

因此初期更像是每天集合匯報工作，直到要輪流當 Scrum Master 時，因為無法拒絕，所以每位成員都一定要有所了解，而這個過程促使團隊往好的方向發展（應該 🤔）。

當然還要更多時間來驗證，相信每次的 Sprint Retrospective 都能讓原本的流程更加完善。

如果讀者有敏捷開發的經驗，歡迎留言分享，你的留言或許可以幫助到其他人。

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

其實大部分的工程師都是可以理性溝通的，但我們無法接受一直做「白工」和「重工」，今天筆者想透過一個案例來跟大家分享「客戶、PM、工程師」之間思維的差異，並提出可以改善的方案。

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

大綱
一、工程師說 Loading 太重，可以請你幫忙分擔嗎？
二、需求不斷變更，緩衝時間再多也不夠用！
三、可是客戶態度很強硬啊！東西真的不符合他們需求
四、整理不完的例外，變更不斷的需求
五、從源頭解決問題，不是每個問題都要靠程式解決
六、客戶未必具備工程背景，要協助他們表達需求
七、我們要如何調整，讓未來的合作更加順利

一、工程師說 Loading 太重，可以請你幫忙分擔嗎？

PM 反饋這個問題後，我打開專案管理系統，看那位抱怨 Loading 太重的工程師手上有哪些 Ticket，是否需要做適當的調整。

結果仔細一看才發現，儘管那位工程師在這個 Sprint 中只剩下 2 張 Ticket 尚未完成，但有一張「匯出 Excel 報表」的 Ticket 預估時程遠遠超過之前在 Sprint Planning 的預估（4➝15）。

因為剩下的 2 個 Ticket 都是這次 Sprint 的核心功能，且距離結束只剩不到 2 個工作天，因此 PM 希望我可以接手那個估時已經到達 15 小時的 Ticket，讓工程師專注處理剩下的 Ticket。

跟 PM 談到這裡的時候我覺得有點奇怪，之所以將匯出 Excel 報表的 Ticket 分配給那位工程師，就是因為他之前有實作的經驗，沒道理在這個地方卡這麼久。

二、需求不斷變更，緩衝時間再多也不夠用！

為了釐清這個問題，我跟 PM、工程師開了一個臨時會議，去了解是什麼原因導致一個不困難的 Ticket 花了這麼多時間。

此時我才從工程師那邊了解到另一個事實，其實對他而言，匯出 Excel 報表的功能並不複雜，Loading 太重的原因是客戶不斷變更需求，導致這個 Ticket 的估時不斷增加，但預計交付的日期並沒有延長，因此時間壓力會全部壓到工程師身上。

我在詢問這個需求變更的頻率有多高時，工程師表示把新版交付出去後，可能再過 3、4 個小時就會收到新的需求變更；儘管每次修改都不會花太多時間，但架不住這麼頻繁的更動啊！

當需求變更導致一直做白工、重工，就可能讓工程師工作效率下降，甚至可能在完成功能後故意拖一段時間再交付；畢竟提早交付沒好事，只是讓自己的工作量變更多而已。

三、可是客戶態度很強硬啊！東西真的不符合他們需求

客戶花錢請我們做系統，當然是希望做出符合他們實際業務需求的產品；站在客戶的立場上，他們當然會用最嚴格的標準在看待每一個功能。

但站在我們的立場上，在人力資源固定的狀態下，每多一次需求變更，我們就需要花更多的時間與精力去完成，甚至導致部分同仁需要加班。

為了解決這個問題，我請 PM 跟客戶約一個時間，一起了解需求不停變更的原因是什麼，不然這樣一直改下去其實是在浪費彼此的時間。

四、整理不完的例外，變更不斷的需求

客戶是一個專門提供材料出貨的公司，在深入訪談後，才了解需求之所以會一直變更，是因為這個 Excel 報表始終沒有決定一個固定的版本，會這樣是因為過去客戶在填寫出貨單時沒有律定格式，同一個材料可能有 10 幾種表達方式。

過去沒有遇到這個問題，是因為之前的出貨單都是 Case by Case，所以他們材料名稱儘管不統一，但依舊能夠看得懂；可是如果把好幾張出貨單放在一起看，就會因為資料很難整合而產生許多問題，這也是客戶找我們做系統化的原因。

下面用手機來舉個例子，我們手機有前鏡頭，假使在出貨單上顯示：「前鏡頭、前置相機、front camera、Front Camera、frontCamera」我相信大家都看得懂這是指同一個東西；但如果管理階層想要知道公司這個月到底賣了多少個「前鏡頭」，下屬就需要畫很多時間做比對跟整合。

除了相機的案例外，這邊再舉一個螢幕的例子，每個手機螢幕的尺寸大小不同，因此出貨單上有各自的命名；當管理階層想了解這個月總共賣了多少個「螢幕」，下屬會因為出貨單的材料沒有階層的概念而整理到崩潰。

在了解客戶的痛點後，我們就知道這是因為過去「命名不統一、材料缺乏階層概念」導致的問題。

PM 一開始也是從這個方向去處理問題的，他先請客戶將期望的命名、材料的階層整理出來，然後請工程師依照規格去統整；儘管這個方案看似沒有問題，但因為客戶當時在填寫出貨單時，命名太過狂野，因此有非常多的例外需要處理，而每發現一個例外就要請工程師調整程式。

五、從源頭解決問題，不是每個問題都要靠程式解決

了解來龍去脈後，我想也許我們都把問題搞複雜了，既然我們都知道問題是在出貨單上，為什麼不要從源頭來解決這個問題呢？

如果出貨單的格式沒有律定，在未來同樣的問題還是會發生；因為出貨單上每天都可能會誕生新的名詞，而新的名詞會無法自動歸類，可以料想到就算現在符合客戶的需求，在未來還是會有許多衍生問題。

當然過去的歷史業障很難要求客戶調整，「統一名詞、確定階層」還是一個必要的工作；但也許我們可以先用過去的出貨單模擬客戶期望的 Excel，而不是不斷請工程師修改程式。

若發現有缺少、錯誤的材料先記錄下來，累積到一定的量後再請工程師修正，不然他會改到瘋。

同時為了讓錯誤的歷史在這個階段就停下，我們需要請客戶與填寫出貨單的部門溝通，律定「出貨單」填寫的格式。

如果涉及到客戶公司內部，盡可能讓他們「自行協調」，我們做好「引導的角色」就夠了，如果由我們向客戶的其他部門提出需求，那破局的機率非常高。

六、客戶未必具備工程背景，我們要協助他們表達需求

其實就算是公司內部的溝通也是不容易的，起初填寫出貨單的部門對律定格式這件事反彈極大，因為他們原本都做得好好的，現在變得要依規範行事。

在了解到客戶推行的困難點後，我們製作了一張高達數百個欄位的 Excel，並請客戶向填寫出貨單的部門展示，讓他們體會到混亂的格式造成什麼後果。

在這之後他們才理解為什麼格式需要律定了，也了解公司導入這個系統就是希望把流程標準化，減少報表製作的時間，不是想要刁難他們。

七、我們要如何調整，讓未來的合作更加順利

儘管這個問題最後在多方的協作下圓滿解決，但其實中間有許多摩擦是可以在初期避免的。

Tech Lead

若發現某個 Ticket 的估時逐漸增加，要主動向工程師詢問實際狀況，因為有些細節在 Scrum Meeting 並不會提及。

若發現工程師在做重工、白工，要先釐清問題來源；不是每個問題都要靠程式解決，我們可以先嘗試跟客戶溝通。

PM

如果客戶提出的需求變更太過零碎、頻繁，可以先記錄下來，等累積到一定的量，或是明確需求後再交給工程師處理。

如果發現需求能用模擬的就先用模擬的，盡可能不要讓工程師把時間耗在有高機率做白工的需求變更上。

工程師

如果發現需求變更的內容不合理、次數太多，可以即時與 Tech Lead 反應，而不是用加班默默把需求的吃下來。

希望這個案例對讀者日後執行專案時有幫助，如果還有其他建議也歡迎留言分享喔～

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

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

大綱
ㄧ、客戶、專案經理、開發人員，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 有多麼重要嗎？