專案怎麼管？ | Terry's Guide

為什麼專案總是 delay？

如果你在軟體業待過一陣子，你一定經歷過這種事：專案說好兩個月做完，結果做了四個月還在「收尾」。這不是因為工程師偷懶，而是因為從一開始就有很多東西沒搞清楚。

最常見的原因就是 scope creep——需求不斷追加。一開始說「做一個登入頁面」，後來變成「要加社群登入」、「要有忘記密碼」、「要有兩階段驗證」、「順便做個會員中心」。每加一個功能，時間就往後推。

另一個原因是估時太樂觀。工程師被問「這個要做多久？」的時候，通常會想到最順利的情況。但現實是，你會遇到文件沒寫清楚的 API、莫名其妙的 bug、突然插進來的緊急需求。

「這個功能很簡單」是工程界最危險的一句話。每次聽到這句話，資深工程師心裡都會默默加上一倍的工時。

需求拆解是專案管理最核心的技能。拆得好，團隊知道在做什麼、做到哪了；拆得不好，大家在一團迷霧裡摸索。

基本的拆法是三層：Epic 是大目標（例如「做一個購物車」），Story 是使用者的動作（例如「使用者可以把商品加入購物車」），Task 是工程師要做的具體事項（例如「建立 cart API endpoint」）。

舉個例子，「做一個購物車」可以拆成：

設計購物車的資料結構

建立「加入購物車」的 API

建立「移除商品」的 API

建立「修改數量」的 API

做購物車頁面的 UI

串接前端和後端

計算小計和總計金額

處理庫存不足的情況

寫測試

拆到每個 task 都能在一天內做完，就對了。如果一個 task 估計要做三天以上，那它還可以再拆。拆得越細，進度越好追蹤。

Agile（敏捷開發）不是一套方法論，它比較接近一種「態度」。核心概念很簡單：與其花半年做一個完美的產品，不如每兩週交付一個能用的版本，然後根據回饋持續改進。

Agile 底下有很多具體的做法，最常見的兩個是 Scrum 和 Kanban。

Bad

我們用 Scrum 所以每天站著開會

Good

我們每天花 10 分鐘同步進度

不管用 Scrum 還是 Kanban，重點都是一樣的：小步快跑、快速回饋、持續改進。形式不重要，精神才重要。

為什麼工程師的估時永遠不準？因為我們在估時的時候，想到的都是「如果一切順利」的情況。但事情從來不會一切順利。

一些實用的估時技巧：

乘以二法則

心裡想的時間乘以二，通常就是比較接近現實的時間。聽起來很粗糙，但準確率驚人。

加上緩衝

每個 Sprint 留 20% 的時間給意外。有人請假、線上出 bug、需求臨時改——這些都需要時間處理。

用 Story Points 取代時間

不要估「幾小時」，改估「相對複雜度」。一個簡單的 API 是 1 點，一個複雜的功能是 5 點。跑幾個 Sprint 之後，你就知道團隊的速度了。

被問「還要多久？」時，最好的回答是告訴他剩多少事，不是剩多少時間。「還有三個 API 要做、一個頁面要串、測試還沒跑」，比「大概還要五天」有用得多。

其他主題