Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là PM của một dự án xây dựng app mobile cho một ngân hàng, deadline ký hợp đồng là 90 ngày. Sếp hỏi: "Nếu team thiết kế bị trễ 5 ngày thì dự án có trễ không?" Nếu bạn không trả lời được ngay câu này, thì bạn đang quản lý lịch dự án bằng cảm giác, chứ không phải bằng phương pháp.
Critical Path Method (CPM) — Phương pháp Đường găng — chính là công cụ giúp bạn trả lời chính xác câu hỏi đó. Ở Bài 16 bạn đã học cách vẽ Gantt Chart để nhìn thấy lịch trực quan. Nhưng Gantt cho bạn thấy "cái gì diễn ra khi nào", còn CPM cho bạn thấy điều quan trọng hơn nhiều: "task nào thực sự quyết định ngày kết thúc dự án, và task nào có thể trễ mà không sao".
Đây là kiến thức nền tảng bắt buộc của mọi PM chuyên nghiệp, xuất hiện trong đề thi PMP, và quan trọng hơn — nó thay đổi cách bạn ra quyết định hàng ngày. Khi tài nguyên có hạn (mà lúc nào cũng có hạn), CPM cho bạn biết nên dồn người vào đâu, nên theo dõi sát task nào, và có thể "hy sinh" task nào. Trong bài này, tôi sẽ dạy bạn hiểu bản chất, tự tính bằng tay, và áp dụng vào dự án thật.
Khái niệm cốt lõi
Critical Path là gì?
Critical Path (Đường găng) là chuỗi các task liên tiếp có tổng thời gian dài nhất, tính từ điểm bắt đầu đến điểm kết thúc dự án. Chính chuỗi này quyết định thời gian tối thiểu để hoàn thành toàn bộ dự án.
Nguyên tắc cốt lõi phải khắc cốt ghi tâm: Bất kỳ task nào trên đường găng bị trễ 1 ngày, cả dự án trễ 1 ngày. Ngược lại, task không nằm trên đường găng có một khoảng "co giãn" nhất định — trễ trong khoảng đó thì dự án vẫn về đích đúng hạn.
Lý do CPM tồn tại là vì các task trong dự án không chạy độc lập — chúng có quan hệ phụ thuộc (dependency). Bạn không thể sơn tường trước khi xây tường. Không thể test app trước khi code xong. Chính chuỗi phụ thuộc dài nhất này "kéo" thời gian dự án.
Bốn con số then chốt: ES, EF, LS, LF
Để tìm đường găng, mỗi task cần tính 4 giá trị:
- ES (Early Start) — thời điểm sớm nhất task có thể bắt đầu.
- EF (Early Finish) — thời điểm sớm nhất task có thể kết thúc. Công thức: EF = ES + Duration.
- LS (Late Start) — thời điểm muộn nhất task có thể bắt đầu mà không làm trễ dự án.
- LF (Late Finish) — thời điểm muộn nhất task có thể kết thúc mà không làm trễ dự án.
Float (Slack) — con số "cứu mạng" của PM
Float (hay Slack — thời gian dự trữ) là khoảng thời gian một task có thể trễ mà không ảnh hưởng đến ngày kết thúc dự án. Công thức:
Total Float = LS − ES = LF − EF
Điểm mấu chốt: Task nằm trên đường găng luôn có Float = 0. Đó là định nghĩa toán học của "đường găng" — là tập hợp các task không có chỗ để trễ. Task có Float > 0 nằm ngoài đường găng.
Có một khái niệm anh em là Free Float — thời gian một task có thể trễ mà không làm trễ ngày bắt đầu sớm nhất của task kế tiếp. Total Float đo so với cả dự án, Free Float đo so với task liền sau. Trong thực tế bạn dùng Total Float nhiều nhất.
Forward Pass và Backward Pass
Cách tính đường găng gồm hai lượt "quét":
- Forward Pass (lượt xuôi): đi từ đầu đến cuối dự án để tính ES và EF. Khi một task có nhiều task đứng trước, ES của nó bằng EF lớn nhất trong các task đứng trước (vì phải đợi tất cả xong).
- Backward Pass (lượt ngược): đi từ cuối về đầu để tính LF và LS. Khi một task có nhiều task đứng sau, LF của nó bằng LS nhỏ nhất trong các task đứng sau.
Tình huống thực tế
Ví dụ 1 — Dự án mở quán cà phê tại TP.HCM
Chị Lan mở một quán cà phê ở Quận 3. Chị liệt kê các công việc chính:
| Task | Mô tả | Duration (ngày) | Phụ thuộc |
|---|---|---|---|
| A | Thuê & ký hợp đồng mặt bằng | 5 | — |
| B | Thiết kế nội thất | 8 | A |
| C | Thi công sửa chữa | 15 | B |
| D | Xin giấy phép kinh doanh | 10 | A |
| E | Mua & lắp thiết bị (máy pha, bàn ghế) | 6 | C |
| F | Tuyển & đào tạo nhân viên | 7 | D |
| G | Khai trương | 2 | E, F |
- Nhánh 1: A → B → C → E → G = 5 + 8 + 15 + 6 + 2 = 36 ngày
- Nhánh 2: A → D → F → G = 5 + 10 + 7 + 2 = 24 ngày
Diễn giải: Task D (xin giấy phép) và F (tuyển nhân viên) nằm trên nhánh chỉ tốn 24 ngày, trong khi đến điểm hội tụ (task G) cần chờ 36 ngày. Nghĩa là nhánh 2 có Float = 36 − 24 = 12 ngày. Chị Lan có thể thong thả xin giấy phép, tuyển người trễ vài ngày cũng không sao — miễn nằm trong 12 ngày dự trữ.
Bài học: Chị Lan nên dồn sự chú ý vào C (thi công) — task dài nhất và nằm trên đường găng. Nếu thợ thi công trễ 3 ngày, quán trễ khai trương 3 ngày, mất doanh thu 3 ngày. Còn nếu chị lo sốt vó vụ tuyển nhân viên mà lơ là thi công, chị đang tối ưu sai chỗ.
Ví dụ 2 — Dự án phần mềm tại một công ty outsourcing như FPT Software
Một team làm module thanh toán cho khách hàng Nhật. Các task:
| Task | Mô tả | Duration (ngày) | Phụ thuộc |
|---|---|---|---|
| A | Phân tích yêu cầu | 4 | — |
| B | Thiết kế database | 3 | A |
| C | Thiết kế UI/UX | 5 | A |
| D | Code backend | 10 | B |
| E | Code frontend | 8 | C |
| F | Tích hợp & test | 6 | D, E |
- Nhánh backend: A → B → D → F = 4 + 3 + 10 + 6 = 23 ngày
- Nhánh frontend: A → C → E → F = 4 + 5 + 8 + 6 = 23 ngày
Diễn giải: Đây là tình huống nguy hiểm mà nhiều PM bỏ qua. Khi có nhiều đường găng, rủi ro tăng gấp đôi — bất kỳ task nào ở bất kỳ nhánh nào trễ đều làm trễ dự án. PM không có "vùng đệm" nào cả.
Bài học: Khi phát hiện nhiều đường găng, PM nên (1) theo dõi sát cả hai nhánh, không được chủ quan, và (2) cân nhắc thêm buffer hoặc bố trí dev giỏi nhất vào task D (backend, 10 ngày) và E (frontend, 8 ngày) vì đó là những task dài, dễ trở thành điểm nghẽn.
Ví dụ 3 — Rút ngắn đường găng bằng Fast-tracking
Quay lại quán cà phê của chị Lan. Chủ nhà cho biết nếu khai trương trước 30 ngày, chị được giảm 2 tháng tiền thuê. Chị muốn rút từ 36 xuống ≤ 30 ngày. Làm sao?
Chị chỉ có thể rút bằng cách tác động vào đường găng (A → B → C → E → G). Rút task ngoài đường găng là vô ích. Hai kỹ thuật:
- Fast-tracking: làm song song những task vốn tuần tự. Chị cho thiết kế nội thất (B) và thi công (C) chồng lấn — bắt đầu thi công phần trần khi thiết kế mới xong 60%. Tiết kiệm ~5 ngày, nhưng rủi ro phải làm lại nếu thiết kế thay đổi.
- Crashing: thêm tài nguyên để rút ngắn task. Chị thuê thêm một đội thợ, rút task C từ 15 xuống 11 ngày, nhưng tốn thêm chi phí nhân công.
Hướng dẫn từng bước
Đây là quy trình 7 bước để tự tìm đường găng cho bất kỳ dự án nào:
Bước 1 — Liệt kê toàn bộ task. Dùng WBS (Bài 14) để chia dự án thành các task đủ nhỏ, mỗi task có thể ước lượng thời gian.
Bước 2 — Ước lượng Duration cho từng task. Dùng kinh nghiệm hoặc kỹ thuật ước lượng (Bài 15). Ở bước này bạn cần một con số cho mỗi task.
Bước 3 — Xác định quan hệ phụ thuộc. Với mỗi task, hỏi: "Task này cần task nào xong trước mới bắt đầu được?" Ghi rõ Predecessor (task đứng trước).
Bước 4 — Vẽ sơ đồ mạng (Network Diagram). Vẽ các task thành node, nối bằng mũi tên theo thứ tự phụ thuộc. Sơ đồ này giúp bạn nhìn thấy các nhánh song song.
Bước 5 — Forward Pass để tính ES, EF. Bắt đầu từ task đầu (ES = 0). EF = ES + Duration. Task tiếp theo lấy ES = EF của task trước; nếu có nhiều task trước, lấy EF lớn nhất. Đi đến hết dự án — EF của task cuối chính là tổng thời gian dự án.
Bước 6 — Backward Pass để tính LS, LF. Bắt đầu từ task cuối, đặt LF = EF của nó. LS = LF − Duration. Đi ngược về đầu; task trước lấy LF = LS của task sau; nếu có nhiều task sau, lấy LS nhỏ nhất.
Bước 7 — Tính Float và xác định đường găng. Float = LS − ES cho từng task. Chuỗi các task có Float = 0 nối liền từ đầu đến cuối chính là đường găng.
Sau khi có đường găng, bạn dùng nó để: theo dõi sát các task Float = 0, phân bổ tài nguyên tốt nhất vào đó, và biết chính xác task nào có thể trễ được bao nhiêu ngày.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm "task dài nhất" với "đường găng". Đường găng không phải là task có Duration lớn nhất, mà là chuỗi task có tổng dài nhất. Một task ngắn 2 ngày vẫn có thể nằm trên đường găng nếu nó nằm trong chuỗi tuần tự dài nhất.
Lỗi 2 — Quên rằng đường găng thay đổi theo thời gian. Khi dự án chạy, một task ngoài đường găng bị trễ quá Float của nó sẽ "nuốt hết" dự trữ và biến nhánh đó thành đường găng mới. PM phải tính lại đường găng định kỳ, không phải tính một lần rồi để đó.
Lỗi 3 — Dồn tài nguyên vào task không nằm trên đường găng. Đây là lỗi tối ưu sai chỗ kinh điển. Tăng tốc một task có Float = 10 ngày không rút ngắn dự án một ngày nào — chỉ lãng phí tài nguyên đáng ra nên dành cho đường găng.
Lỗi 4 — Bỏ qua dependency ẩn. Nhiều PM chỉ ghi phụ thuộc kỹ thuật (task A phải xong mới làm B) mà quên phụ thuộc tài nguyên (cùng một người làm cả A và B nên không thể song song). Dependency thiếu làm đường găng sai lệch hoàn toàn.
Mẹo 1 — Đường găng thường có nhiều hơn một. Đừng ngạc nhiên khi tìm thấy hai, ba đường găng. Càng nhiều đường găng, dự án càng rủi ro và càng cần theo dõi chặt.
Mẹo 2 — Kết hợp CPM với Gantt. Trong công cụ như MS Project, Jira, hay Smartsheet, bạn bật tính năng highlight critical path để phần mềm tự tô đỏ đường găng. Hiểu bản chất bằng tay giúp bạn không bị công cụ "dắt mũi".
Mẹo 3 — Chú ý task có Float nhỏ. Task Float = 1 hay 2 ngày là "gần găng" (near-critical). Chỉ cần trễ nhẹ là chúng nhảy lên đường găng. Hãy theo dõi chúng gần như task găng.
Bài tập thực hành
Cho dự án tổ chức một hội thảo tuyển dụng IT tại Hà Nội với các task sau:
| Task | Mô tả | Duration (ngày) | Phụ thuộc |
|---|---|---|---|
| A | Chốt chủ đề & ngân sách | 3 | — |
| B | Đặt địa điểm | 4 | A |
| C | Mời diễn giả | 6 | A |
| D | Thiết kế & in ấn tài liệu | 5 | B |
| E | Chạy quảng cáo & bán vé | 8 | C |
| F | Chuẩn bị hậu cần | 4 | D, E |
| G | Tổ chức sự kiện | 1 | F |
- Vẽ sơ đồ mạng và liệt kê tất cả các đường đi từ A đến G.
- Tính tổng thời gian mỗi đường và xác định đường găng.
- Tính Float cho task B và task D.
- Nếu task E (quảng cáo) trễ 2 ngày, dự án có trễ không? Vì sao?
Làm xong, hãy thử tình huống nâng cao: nếu bạn được phép crash task E từ 8 xuống 5 ngày, đường găng mới là gì và dự án còn bao nhiêu ngày?
Tóm tắt
Critical Path Method là công cụ nền tảng để quản lý lịch dự án bằng phương pháp thay vì cảm tính. Những điều cần nhớ:
- Đường găng là chuỗi task tuần tự có tổng thời gian dài nhất, quyết định thời gian tối thiểu của dự án.
- Task trên đường găng có Float = 0 — trễ 1 ngày, dự án trễ 1 ngày.
- Tìm đường găng qua Forward Pass (tính ES, EF) và Backward Pass (tính LF, LS), rồi tính Float = LS − ES.
- Muốn rút ngắn dự án, chỉ tác động vào đường găng, bằng fast-tracking (đánh đổi rủi ro) hoặc crashing (đánh đổi chi phí).
- Đường găng thay đổi theo thời gian — phải tính lại định kỳ, đặc biệt chú ý các task near-critical Float nhỏ.
- Dồn tài nguyên và sự chú ý vào task găng; đừng phí công tối ưu task có Float lớn.