Bài 4

Lập kế hoạch & Ước lượng

Lập kế hoạch là quá trình biến mục tiêu thành phạm vi, công việc, lịch trình và thứ tự ưu tiên — để biết phải làm gì, làm theo trình tự nào, mất bao lâu và làm cái gì trước.

Xác định phạm vi & WBS

Vạch ranh giới công việc trước khi ước lượng

Trước khi lên lịch hay ước lượng, bạn phải biết chính xác mình cần làm những gì — và quan trọng không kém: không làm những gì. Đó là vai trò của tuyên bố phạm vi và cấu trúc phân rã công việc.

Scope statement (Tuyên bố phạm vi): tài liệu mô tả rõ kết quả bàn giao (deliverables), những gì nằm trong phạm vi (in-scope), những gì bị loại trừ (out-of-scope), các giả định và ràng buộc. Đây là điểm tham chiếu để mọi người thống nhất về "thế nào là hoàn thành".

WBS (Work Breakdown Structure – Cấu trúc phân rã công việc): chia dự án thành các phần nhỏ dần theo cấp bậc, cho tới khi mỗi phần đủ nhỏ để ước lượng và giao cho người chịu trách nhiệm. Cách phân cấp điển hình:

Cấp 1 – Dự án: toàn bộ kết quả cuối cùng (ví dụ: "Hệ thống đặt hàng online").
Cấp 2 – Hạng mục lớn / sản phẩm thành phần: các khối chính như "Trang khách hàng", "Hệ thống thanh toán", "Trang quản trị".
- Cấp 3 – Nhóm tính năng: ví dụ trong "Hệ thống thanh toán" có "Cổng thanh toán", "Hóa đơn", "Hoàn tiền".
- Cấp thấp nhất – Work package (gói công việc): đơn vị nhỏ nhất có thể ước lượng chi phí, thời gian và giao cho một người/đội phụ trách, ví dụ "Tích hợp cổng VNPay".

Nguyên tắc 100%: WBS phải bao trùm toàn bộ công việc của dự án — không thiếu, không thừa. Tổng các phần con đúng bằng phần cha; việc gì không nằm trong WBS thì không được làm (và không được tính công).

Scope creep (phình phạm vi): tình trạng phạm vi âm thầm to dần qua các yêu cầu nhỏ lẻ ("thêm tí nữa", "tiện thể làm luôn") mà không điều chỉnh thời gian/chi phí — nguyên nhân kinh điển khiến dự án trễ và đội ngân sách.

Có baseline phạm vi rõ ràng để biết cái gì là "thêm".
Thiết lập quy trình kiểm soát thay đổi (change control): mọi yêu cầu mới phải được đánh giá tác động (thời gian, chi phí, rủi ro) rồi mới duyệt.
Luôn gắn yêu cầu mới với câu hỏi: "đánh đổi cái gì?" — thêm việc thì phải dời hạn, tăng nguồn lực, hoặc cắt việc khác.

Ước lượng (Estimation)

Dự đoán công sức và thời gian cho từng phần việc

Ước lượng là việc trả lời câu hỏi "mất bao nhiêu công / bao lâu / bao nhiêu tiền". Có nhiều kỹ thuật, từ đơn giản đến chặt chẽ:

Kỹ thuật	Cách làm	Khi nào dùng
Expert judgment (Phán đoán chuyên gia)	Hỏi người có kinh nghiệm trong lĩnh vực đó cho con số	Nhanh, sớm, ít dữ liệu; làm điểm khởi đầu
Analogous (Tương tự)	So với một dự án/việc cũ tương tự đã từng làm	Có dự án quá khứ gần giống để tham chiếu
Parametric (Tham số)	Dùng đơn giá nhân khối lượng (ví dụ: X giờ / màn hình × số màn hình)	Công việc có thể đo bằng đơn vị lặp lại
Bottom-up (Từ dưới lên)	Ước lượng từng work package nhỏ rồi cộng lại	Cần độ chính xác cao, đã có WBS chi tiết

PERT – ước lượng 3 điểm: thay vì một con số "cứng", lấy ba kịch bản rồi tính bình quân có trọng số, giảm thiên lệch lạc quan:

E = (O + 4M + P) / 6

O (Optimistic – Lạc quan): mọi thứ thuận lợi, làm xong nhanh nhất.
M (Most likely – Khả dĩ): kịch bản hợp lý nhất, thường xảy ra.
P (Pessimistic – Bi quan): mọi thứ trục trặc, chậm nhất.

Trọng số 4 dồn về M nên kết quả nghiêng về kịch bản khả dĩ, nhưng vẫn kéo theo độ rủi ro từ O và P. Ví dụ O=2, M=4, P=12 ngày → E = (2 + 16 + 12) / 6 = 5 ngày.

Ước lượng trong Agile thiên về tương đối thay vì tuyệt đối:

Story Point: đơn vị tương đối thể hiện độ phức tạp + công sức + rủi ro của một hạng mục, thường dùng dãy Fibonacci (1, 2, 3, 5, 8, 13...) vì khoảng cách lớn dần phản ánh sự bất định tăng khi việc to.
Planning Poker: cả đội cùng "đánh bài" số point đồng thời; nếu lệch nhau thì thảo luận để hiểu vì sao — buộc trao đổi, tránh người to tiếng áp đặt.
T-shirt sizing: ước lượng thô theo cỡ áo (XS / S / M / L / XL), hợp cho giai đoạn sớm hoặc cho backlog lớn cần phân loại nhanh.
Velocity: số point trung bình đội hoàn thành mỗi sprint — dùng để quy đổi tổng point của backlog ra số sprint/thời gian dự kiến (ví dụ: 100 point ÷ velocity 20/sprint ≈ 5 sprint).

Ước lượng là dự đoán, không phải cam kết chính xác. Luôn có sai số. Theo "phễu bất định" (cone of uncertainty), sai số rất lớn ở đầu dự án và thu hẹp dần khi bạn hiểu rõ công việc hơn — nên hãy ước lượng lại theo tiến độ thay vì tin tuyệt đối vào con số ban đầu.

Lập lịch (Scheduling)

Sắp xếp công việc theo thời gian và phụ thuộc

Sau khi có công việc và ước lượng, bạn xếp chúng lên trục thời gian. Bước đầu là xác định quan hệ phụ thuộc: việc nào phải xong trước việc nào.

Loại phụ thuộc	Ý nghĩa	Ví dụ
FS – Finish to Start	A xong thì B mới bắt đầu (phổ biến nhất)	Xong thiết kế DB mới code API
SS – Start to Start	A bắt đầu thì B mới được bắt đầu	Bắt đầu code thì bắt đầu viết tài liệu
FF – Finish to Finish	A xong thì B mới được xong	Test xong thì nghiệm thu mới khép lại
SF – Start to Finish	A bắt đầu thì B mới được kết thúc (hiếm)	Hệ thống mới chạy thì hệ thống cũ mới dừng

Sơ đồ mạng (network diagram): biểu diễn các công việc và mũi tên phụ thuộc giữa chúng, để thấy luồng và các nhánh chạy song song.

Đường găng (Critical Path Method – CPM): chuỗi các công việc phụ thuộc nối tiếp nhau có tổng thời gian dài nhất trong dự án. Độ dài đường găng chính là thời gian tối thiểu để hoàn thành dự án — chậm bất kỳ việc nào trên đường găng sẽ làm chậm cả dự án.

Slack / Float (thời gian dự trữ): khoảng thời gian một công việc có thể trễ mà không ảnh hưởng dự án. Công việc trên đường găng có slack = 0.
Quản lý dự án nên dồn sự chú ý và nguồn lực vào các việc trên đường găng trước.

Gantt chart: biểu đồ thanh ngang theo thời gian — mỗi công việc là một thanh, vị trí và độ dài thể hiện ngày bắt đầu/kết thúc, các mũi tên thể hiện phụ thuộc. Đây là công cụ trực quan phổ biến nhất để theo dõi tiến độ.

Milestone (cột mốc): điểm đánh dấu quan trọng (thời gian bằng 0), ví dụ "Hoàn tất bản beta", "Go-live" — dùng để theo dõi tiến độ theo các mốc lớn thay vì từng việc nhỏ.

Đường găng (Critical Path) Scroll / zoom · Mở draw.io ↗

Ưu tiên backlog

Làm cái gì trước khi nguồn lực có hạn

Không bao giờ đủ thời gian để làm tất cả. Các khung ưu tiên giúp xếp thứ tự dựa trên giá trị và công sức một cách có hệ thống thay vì cảm tính.

Khung	Cách hoạt động	Khi nào dùng
MoSCoW	Phân hạng yêu cầu thành Must (bắt buộc), Should (nên có), Could (có thì tốt), Won't (lần này không làm)	Thống nhất phạm vi với stakeholder, đặc biệt khi có hạn chót cứng
RICE	Điểm = (Reach × Impact × Confidence) / Effort — cân giá trị trên công sức bỏ ra	So sánh nhiều ý tưởng sản phẩm bằng con số khách quan
WSJF (Weighted Shortest Job First)	Điểm = Cost of Delay / Job Size — làm trước việc tạo giá trị cao mà tốn ít công	Agile/SAFe, tối ưu dòng giá trị giao ra
Value vs Effort	Vẽ ma trận 2 trục giá trị – công sức; ưu tiên ô "giá trị cao, công sức thấp" (quick win)	Cần quyết định nhanh, trực quan, ít dữ liệu

Mẹo: "Cost of Delay" trong WSJF là giá trị mất đi nếu trì hoãn việc đó — buộc bạn nghĩ tới tính cấp thiết theo thời gian, không chỉ giá trị thuần.

Roadmap & Release plan

Định hướng dài hạn vs kế hoạch giao hàng

Hai khái niệm dễ nhầm nhưng phục vụ mục đích khác nhau:

Roadmap (lộ trình): bức tranh định hướng theo thời gian/chủ đề — trả lời "chúng ta đang đi đâu và vì sao". Mức trừu tượng cao, theo quý hoặc theo chủ đề (theme), linh hoạt và có thể thay đổi. Dùng để truyền đạt tầm nhìn cho stakeholder, không phải lịch cam kết từng ngày.
Kế hoạch chi tiết: cụ thể tới từng công việc, ngày tháng, người phụ trách — trả lời "ai làm gì, khi nào". Dùng để điều hành công việc hằng ngày.

Release planning trong Agile: nhóm các sprint lại để hướng tới một lần phát hành (release) có giá trị cho người dùng. Đội dùng velocity và độ ưu tiên backlog để ước tính một release cần bao nhiêu sprint và sẽ gồm những tính năng nào — cân bằng giữa phạm vi, thời gian và chất lượng.

Ghi nhớ: roadmap là định hướng (có thể đổi), release plan là cam kết giao hàng trong khoảng thời gian gần. Đừng biến roadmap thành lời hứa ngày tháng cứng nhắc.

Baseline & buffer

Mốc đo sai lệch và đệm cho rủi ro

Baseline (đường cơ sở): phiên bản kế hoạch đã được duyệt, "đóng băng" để làm mốc so sánh khi dự án chạy. Có ba baseline cốt lõi:

Scope baseline: phạm vi đã chốt (gồm WBS + scope statement) — đo việc phình/thiếu phạm vi.
Schedule baseline: lịch trình đã chốt — đo trễ/sớm tiến độ.
Cost baseline: ngân sách đã chốt theo thời gian — đo vượt/dưới chi phí.

So sánh thực tế với baseline cho biết dự án đang lệch bao nhiêu, để can thiệp kịp thời (đây cũng là nền của Earned Value Management).

Buffer / Reserve (đệm dự phòng) để hấp thụ điều không lường trước:

Contingency reserve (dự phòng tình huống): đệm cho các rủi ro đã nhận diện ("known unknowns"); nằm trong baseline và do quản lý dự án sử dụng.
Management reserve (dự phòng quản lý): đệm cho rủi ro không lường trước ("unknown unknowns"); nằm ngoài baseline và thường do cấp quản lý cao hơn duyệt khi cần.

Rolling wave planning (lập kế hoạch theo lớp): chi tiết hóa phần việc gần (đủ rõ để thực thi ngay), còn phần xa chỉ phác thảo sơ lược rồi làm mịn dần khi tới gần. Tránh tốn công lập kế hoạch chi tiết cho những thứ chắc chắn sẽ thay đổi.