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

大綱
ㄧ、專案初始
二、初始任務
 ➤ 評估每個階段的時程
 ➤ 撰寫 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 有多麼重要嗎？

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

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