本次月會分享的內容「工程師與專案管理」，本篇心得加了大量我的見解、查的補充資料來提供大家參考，對專案管理有興趣的大家可以繼續看下去！
專案的定義
想要認識專案管理，不可避免我們需要先知道專案的定義，這邊是我目前所知最喜歡的一個定義，來自目前擔任 PM 的第七屆引水人 Alice：
- 如期：有起始跟結束時間，在時間的限制下完成，例如與其他部門的對接測試、與主管或部門的 Demo Day 、客戶的交付時間。
- 如質：專案範疇交付要符合當時定下的規格，例如特定功能流程的服務、有標準的前端頁面切版及互動。
- 如預算：在一定的人力工時內完成，例如：特定的計算資源、開發人力與時間。
了解完專案的定義之後，我們也需要了解一個專案的 Life Cycle ，也就是如何開始、執行到結束。
Initial
確認利害關係人及角色責任 (R&R Role & Responsibility）：
開啟一個專案後，專案中的各個角色有各自負責的工作，定義角色能更清楚知道什麼事該找誰討論、應該告知誰，常見的有以下這些：
- Sponsor： 提供資源，決定專案大方向，通常是大老闆
- Accountable：決定專案細節流程來完成大方向，通常是直屬主管，若有多個團隊合作有多個老闆，應確認最終拍板的人，避免兩邊說法不一致自己變成背鍋俠。
- Responsible：實際執行的人，可能有複數個團隊，如前後端 UIUX 設計師等等。也是實際對功能的成敗當責的人。
- Consulted：顧問型角色，但不參與專案實作，例如資深前輩作為技術顧問，與廠商外部的窗口確認輸入輸出資料格式等
- Informed： 不在團隊內，但需要知道的人決策進度的人，例如業務需要知道功能更新時間和內容
- Influencer：在團隊中或執行上有影響力的人，例如技術顧問、或團隊中最佳人緣的人，獲得這些人的支持可以讓你事半功倍，反之亦然。
- Direct User：會使用成品的所有人，例如部落格中閱讀的讀者、管理文章的作者、下廣告的廣告商等。
雖然以一個 junior engineer 來說，不太可能會碰到所有角色，但往 senior, staff 甚至是工程主管，能碰到的角色會越來越多，能在每次接到專案任務時觀察角色互動也是很好的練習！
專案目標與交付項目
這部分的概念可能 PM 夥伴會比較熟悉，就我目前的了解工程師通常比較沒有機會參與專案目標的設定，但多加了解專案目標，對於開發的方向和解決方案的設計都能更明確！這邊利用 SMART 法則加舉例來切入專案目標的分析：
- Specific (明確)：專案目標應該明確，而不是難以想像的形容，例如：一個網站(X)、 一個有前後台並支援第三方支付的購物網(O)
- Measurable (可衡量)：專案目標應該可以被衡量，例如：能支援高流量的後台(X)、能支援瞬間 50000 次存取的後台(O)
- Achievable (可達成)： 考量現有的時間、資源及技術能力，確保在期限內能完成前面明確且可衡量的目標。
- Relevant (相關性)：目標應與專案的整體策略、公司長遠規劃或核心業務需求一致，確保團隊的工作聚焦於核心需求，例如公司目標是打造高穩定的電商品牌，專案目標：高質感的前端(X)、最多元的金流(X)、具備高可用性及異地備援的資料庫設計(O)
- Time-bound (有時限)：明確的完成期限，用以推動工作並提供進度追蹤的依據。
確認專案目標後，我們需要衡量一些現實，像是有限的執行時間、人力成本及希望的品質要求。
專案鐵三角：範圍、時間、預算
這個鐵三角如果改變了三個邊中的任何一個，中心的品質與另外兩個邊都將受到影響，例如，壓縮了專案能執行的時間，那成本跟範疇還有品質都會相對應的降低，圖片來源的網站也有更多關於這個鐵三角的介紹跟描述可以參考。
因此評估專案進行的人（通常是各級主管或是 PM），在客戶提出需求、交付時間變動或要求新功能時，需要評估鐵三角的壓縮或是增加範圍時，是否依然能夠達成專案目標，或是犧牲某個方向來讓專案順利進行。
確認交付的事項
有了專案目標和實際執行的考量後，會定義出工程師在功能開發完成後需要交付給客戶、上級或其他部門的項目，這些也會因應每個公司、專案有所區別，可能的內容包括但不限於以下：
- Code Base Repo (給維護團隊)
- Demo
- 使用文件
- 測試報告
- Code Review、Reviewer Approve
如果公司現有的交付流程還沒有這些東西，在時間能力許可的情況下可以嘗試討論補充，若能使後續使用或維護更為順暢，也是一個很有影響力的貢獻。
Survey /Planning
確認好專案目標和交付內容之後，接下來需要規劃詳細的專案進程，包含完成專案所需的任務、時間表和資源，以下兩個是常見的規劃方式，WBS 和 User Story Mapping ：
Work Breakdown Structure (WBS)
如題所示，WBS 主要核心是 Breakdown，也就是把專案的 Scope 往下拆成較小的任務 ，拆分任務的方式有以下兩種，Iterative (迭代式)、incremental (增量式)
- Iterative (迭代式)： 整體先做簡單再變複雜，會把所有部分逐步優化到相同水準再一起釋出，例如：前端切版都先拉好純文字的方塊版本，接下來加上 CSS 格式，最後再加上 JS 動畫和互動。
缺點是最賺錢/重要的核心功能可能需要等其他功能優化到同一個程度才能一起上線。
- Incremental (增量式)：將完整大功能拆成小部分，將一個小功能做到一定程度的完整，再進入下一個小功能，例如：先把商品搜尋頁面的搜尋欄做好，再做商品展示的圖片及說明，再做其他頁面的跳轉連結。
缺點是一開始只有一兩個功能可以用，難以串聯上線。
- 組合技：實務上純粹使用兩個方式的缺點都十分明顯，普遍在工作中可能更常出現兩者一起的組合技：先將核心功能做到完美，其他周邊功能有個大概就可以推出使用，再逐步優化周邊功能。
拆分完工作後再根據每個 Task 規劃相對應人力、時間，以 12 週完成一個購物網站為範例，並將專案拆解成特定 Task，：
- 資源估計常見以人時為單位，若有一位 PM 加上三位工程師，一週工時 40 小時，全心投入這個專案時就會 40*4=160 人/時。
- WBS 的特點是能做出甘特圖，來確認任務之間的關聯和相依性，如下圖中的顏色變換就代表不同任務間的相依性：需要等 1.2 架構設計完成後才能執行 1.3 UI/UX設計及2.1架設相關環境、需要 5.1 整合測試後才能交由 5.2 使用者驗收等等。
看到這邊，應該能發現 WBS 最重要的核心是如何切分功能，因此適用在功能範圍明確的任務，例如不同頁面前端等等。
面對複雜龐大的功能，如需要與其他部門協作、同個功能需要滿足多個需求時，任務很難明確切割分配，這時候就可以使用第二種任務規劃方式 User Story Mapping。
User Story Mapping
相比於 WBS 專注於完整功能的切分，User Story Mapping 更專注於以使用者角度出發的每個動作為單位。
對開發工程師而言，參考 User Story 製作功能開發可不只是單純的產品文件，而是一個把「需求」轉換成「可以實作與驗收的開發項目」的橋樑，在解釋之前我們先來看看 User Story 的製作步驟，以購物網站為例：
- 定義使用者旅程（User Journey)
- 先選定某個 User（例如：購買者）
- 研究其某個動作流程（購買商品）的流程步驟：登入→搜尋→加入購物車→結帳
- 細化每個步驟的 Task，如登入可以拆解為：
- 註冊帳號
- 輸入帳號密碼登入
- 忘記密碼
- 依照這些 Task 做出 User Story
格式:「As a（使用者類型）, I want to（我想做什麼）, so that（我為什麼要做）」
- 註冊帳號：「作為一位新購買者，我想用 Email 註冊帳號，以便開始購物」
- 輸入帳號密碼登入：「作為註冊過的購買者，我希望能輸入 Email 與密碼登入，以便取用我的歷史訂單與購物車」
- 忘記密碼：「作為購買者，我希望可以透過重設密碼連結，找回登入權限」
看到這邊你發現 User Story 的好處了嗎？
- 工程師可以理解「為何要做」，而不只是「要做什麼」。
- PM、設計師、QA、工程師可以看懂同一份 User Story，是跨部門溝通的討論語言。
- 每個 Story 都是一個可交付的功能切片，能更精準的評估每個 Story 的開發工時、優先順序。
- 日後維護或新人接手時，能快速理解「這段程式碼是為了哪個使用者需求存在」，減少單純閱讀程式碼時的猜測成本。
實務上 Acceptance Criteria (驗收條件) 會隨 User Story 一起定義，包含功能性需求及非功能性需求，例如：「登入失敗需提示錯誤訊息」、「密碼錯三次需鎖定帳號」、「應於10秒內回傳授權失敗」等，工程師能依據這些寫測試或更好與 PM 確認完成度。
Executing
文章看了這麼久，終於可以開始執行了，也就是工程師們最擅長的開發階段，但先別急！我們來看看工作被分配出去前還需要衡量的任務大小與優先排序。
Sizing 衡量任務大小
都拿到 WBS 或 User Story 了，為什麼還會需要衡量任務大小呢？因爲前期討論規劃時，不一定都會將任務切割到最小的維度，每個人的能力、所能分配運用的時間也不同。所以在任務被分配下去執行前，進一步衡量每個任務的大小，能讓管理者更好地決定是否要將任務切分的更小、如何分配給現有的人力、或需要多久來完成這個任務等等。
在不同公司中負責衡量分配任務的角色不同，但通常會需要開發背景的角色一同參與(例如工程主管、資深工程師），在執行細節得衡量上會更精準，也更能對決定負責。
Prioritizing 優先排序
將任務切分成合適大小分配下去後，執行前確認任務的優先順序也是很重要的。
功能完成順序也很容易影響整個專案交付的時間，因此通常是越靠近核心功能的重要性越高，如果手上的每個任務都非常優先難以分配、抉擇時，可以考慮找主管討論。
注意與主管討論時應著重事實而不是情緒，避免過度強調很累很忙很煩等主觀感受，而是以手上任務的數量、內容、技術細節等來討論。
Agile 敏捷開發
真正開始執行、開發專案時，許多公司會採用敏捷開發，相關概念可以參考敏捷宣言，敏捷強調的是快速適應變化，看重人與人之間的配合，提倡靈活改變並且不怕失敗，用以快速、頻繁地交付出對用戶有價值的產品。
因此，敏捷方法通常會出現短週期的迭代、日常的短會議、以及頻繁的回顧與改進。工程師在開發中、與 PM 的合作中，都可以更注重與同事的討論合作，有初步的成果就快速交付，並依據客戶或用戶的回饋即時調整。
Kanban 看板
這邊介紹一個執行敏捷開發的一個方法，Kanban 是一個視覺化的工作流程。我們將工作任務拆成數個階段，然後將把每個階段（通常是 Todo/ Progress/ Done）所有的任務都列出來，能幫助：
- 資訊透明：團隊所有人都能知道某個任務的進度，有沒有遇到瓶頸
- 專注任務：可以看到每天要做什麼事、或什麼事還沒做完
- 團隊協作：方便在團隊中迅速同步參與人員或相關任務的當前進度
同時，透過定義出 Work In Progress(WIP) Limit，也就是一個人在一個階段的 task 上限，例如：一個人正在執行的 Task 最多 5 個，可以避免任務過度集中在特定的人身上造成專案的執行瓶頸，或是被不同專案的任務卡住。
Definition Of Done, DOD
開發完功能到交付給客戶前，還需要確認你所認為的完成有沒有符合 Definition Of Done（完成的定義）！
Definition Of Done 通常適用於一個普遍的環境，如工程師與 PM 合作，可以視為開發團隊與負責人的一種共識，是對產品的品質與完成程度的一種衡量標準，它定義除了前面提到過的 Acceptance Criteria (驗收條件）之外的上線前檢核標準（Checklist），通常也會因應公司的規模和習慣有所不同，例如：
- 完成程式碼開發
- 完成單元測試
- 完成 Code Review
- 完成整合測試
- 完成故事中所有的驗收條件
這部分的說明參考了這篇，它的舉例跟說明非常貼切易懂！
Retrospective Meeting
每次專案的人員組成可能不同，要面臨的核心任務也不同，代表團隊也會遇到不同的問題和挑戰，在結束時可以來一場 Retrospective Meeting 幫助團隊：
- 檢視成功與挑戰，從中學習與改進
讓團隊可以辨別哪些事情運作順利、哪些遇到障礙：
- 做得好的應該被肯定，並複製經驗到下次；
- 開發過程中遇到的障礙，通當下會更專注「如何在期限前解決問題」，只能用最快、最省力的方式，嘗試從中找出可改進或復用的具體方案，作為未來的行為標準。 - 促進團隊溝通與共識
建立一個安全、開放的對話環境（《心理安全感的力量》），讓成員能自在地分享意見，這有一些小重點：
- Don't force it 不強迫成員，強迫就會有壓力
- 讓成員感覺反映的事情是被重視的
- 若是主管自己當 Scrum Master或會議主持人，要注意會不會有人因而不敢發聲 - 防止重複錯誤
藉由會議建立 feedback loop 持續追蹤調整，避免過去的問題可能在下一次重現。只有討論但沒有實際行動或改變，也可能會讓成員失去信心。
因此回顧會議不是批鬥大會要抓戰犯、也不是取暖大會要互相抱怨或無腦互誇，重點在於如何增進團隊效率和工作品質！
以上就是這次月會的內容及心得分享啦！轉載請附上原文連結～
這次的內容出現了大量專案前期的規劃，很多階段都是目前還沒有參與過的，因此花了大量的時間在搜集資料跟確認範例，希望這篇能讓大家更容易理解專案的全貌，期許自己有一天能參與到完整的專案設計！
也很歡迎PM或是參與過完整專案設計、執行的各位來跟我分享對這篇的看法！
曼陀號是一個邀請各領域專家擔任船長分享經驗的計劃，我參加的是 Enginearing 組，在今年擔任助教的角色~第七屆 Enginearing 組的船長是顧職創辦人 Bryan，總是跟大家精彩地分享職涯能力，如果喜歡分享內容的話，還有其他次月會的心得可以參考喔！
