Biểu đồ Gantt là cách trình bày lịch dự án bằng các thanh ngang đặt trên trục thời gian: mỗi hàng là một công việc, độ dài thanh là thời lượng, vị trí thanh là ngày bắt đầu và kết thúc. Bản hiện đại còn thể hiện mũi tên phụ thuộc, mốc (milestone), phần trăm hoàn thành và đường cơ sở để so kế hoạch với thực tế.
Gantt là công cụ lập kế hoạch được dùng rộng rãi nhất vì ai cũng đọc được trong vài giây. Chính sự dễ đọc đó cũng là cái bẫy: một biểu đồ đẹp có thể che giấu logic sai, nguồn lực chồng chéo và tiến độ ảo. Bài này đi qua lịch sử, cách lập Gantt đúng từ WBS, cách đọc chênh lệch so với đường cơ sở, các lỗi thường gặp và khi nào nên dùng công cụ khác.
Lịch sử: từ Adamiecki đến Henry Gantt và đập Hoover
Biểu đồ mang tên kỹ sư người Mỹ Henry Laurence Gantt, người phát triển nó trong khoảng 1910–1915 khi làm tư vấn quản lý sản xuất, cùng thời với phong trào quản lý khoa học của Frederick Taylor. Biểu đồ ban đầu của Gantt dùng để so sánh sản lượng kế hoạch với thực tế theo từng ngày cho từng công nhân và máy móc, chứ chưa phải lịch dự án như ngày nay.
Trước đó, kỹ sư người Ba Lan Karol Adamiecki đã xây dựng một dạng biểu đồ tương tự gọi là harmonogram từ năm 1896, nhưng công bố muộn và bằng tiếng Ba Lan, Nga nên ít được biết ở phương Tây. Đây là ví dụ quen thuộc về việc một ý tưởng gắn với tên người phổ biến nó hơn là người nghĩ ra đầu tiên.
Biểu đồ Gantt được dùng cho các công trình quy mô lớn đầu thế kỷ XX, thường được nhắc tới cùng đập Hoover (khởi công 1931) và hệ thống đường cao tốc liên bang Mỹ. Thời đó biểu đồ vẽ tay, mỗi lần đổi kế hoạch là vẽ lại, nên khó theo kịp dự án phức tạp. Phải tới khi máy tính cá nhân và phần mềm quản lý dự án phổ biến từ thập niên 1980, Gantt mới trở thành công cụ cập nhật liên tục, có liên kết phụ thuộc và tự tính lại lịch như hiện nay.
Cách lập biểu đồ Gantt đúng thứ tự
Sai lầm phổ biến nhất là mở phần mềm và kéo thanh ngay. Gantt chỉ là cách hiển thị; chất lượng của nó phụ thuộc vào các bước phía trước:
- Bắt đầu từ WBS: lấy các gói công việc, phân rã thành công việc cụ thể có kết quả kiểm tra được. Giữ mã WBS để gom nhóm trên biểu đồ.
- Ước tính thời lượng: theo ngày làm việc, do người sẽ làm ước tính hoặc ít nhất được hỏi ý kiến. Ghi lại giả định, ví dụ “hai thợ, làm một ca”.
- Khai báo quan hệ phụ thuộc: nối công việc bằng liên kết thay vì gõ ngày cố định. Đây là điều kiện để lịch tự cập nhật khi một việc chậm.
- Đặt lịch làm việc: ngày nghỉ lễ, Tết, ca làm việc, ngày nghỉ của nhà cung cấp chính. Lịch dự án vắt qua Tết Nguyên đán mà quên khai báo là nguồn trễ cổ điển.
- Đánh dấu mốc: mốc là điểm có thời lượng bằng không, thường là nghiệm thu, cổng phê duyệt, bàn giao. Mốc giúp lãnh đạo đọc biểu đồ nhanh.
- Gán nguồn lực và kiểm tra quá tải: xem một người có bị giao ba việc cùng tuần không, rồi điều chỉnh.
- Rà đường găng: bật hiển thị đường găng để biết chuỗi nào quyết định ngày xong.
- Chốt đường cơ sở: khi kế hoạch được phê duyệt, lưu lại bản này làm mốc so sánh. Không có đường cơ sở thì không đo được chậm hay nhanh.
Với dự án vài chục công việc, bảng tính có thể đủ. Từ vài trăm công việc trở lên, hoặc khi cần liên kết nhiều dự án dùng chung nguồn lực, nên dùng phần mềm chuyên dụng để tránh cập nhật tay sai lệch.
Đọc biểu đồ Gantt: các yếu tố và câu hỏi cần đặt ra
Một biểu đồ Gantt chuyên nghiệp mang nhiều lớp thông tin hơn những thanh màu. Khi được trình một biểu đồ, có thể dùng bảng sau để đọc có phê phán:
| Yếu tố | Ý nghĩa | Câu hỏi nên đặt |
|---|---|---|
| Thanh công việc | Thời lượng và vị trí trên trục thời gian | Thời lượng này do ai ước tính, dựa trên giả định nào? |
| Mũi tên phụ thuộc | Thứ tự bắt buộc hoặc tuỳ chọn giữa các việc | Có công việc nào không có mũi tên vào hoặc ra không? |
| Thanh tóm tắt | Gom nhóm công việc theo WBS hoặc giai đoạn | Tóm tắt có che mất công việc găng bên trong không? |
| Mốc | Điểm kiểm tra không có thời lượng | Mốc có gắn với sản phẩm nghiệm thu được không, hay chỉ là ngày tượng trưng? |
| Phần trăm hoàn thành | Phần đã làm của từng công việc | Con số này đo bằng gì: giờ công, sản phẩm, hay cảm tính? |
| Đường cơ sở | Thanh mờ thể hiện kế hoạch đã duyệt | Đường cơ sở có bị chốt lại nhiều lần để che chậm trễ không? |
| Đường ngày hiện tại | Đường dọc đánh dấu hôm nay | Có công việc nào lẽ ra phải xong trước đường này mà chưa xong không? |
Câu hỏi về phần trăm hoàn thành đặc biệt quan trọng. Hiện tượng “90% xong” kéo dài hàng tuần là kinh nghiệm chung của nhiều ngành: phần dễ được làm trước nên tiến độ báo cáo nhanh, phần khó dồn cuối. Cách khắc phục là đo theo sản phẩm hoàn thành, ví dụ chỉ dùng 0% hoặc 100% cho công việc ngắn, hoặc 0–50–100 khi bắt đầu và khi xong.
Theo dõi tiến độ: đường cơ sở, chênh lệch và cập nhật hằng tuần
Gantt chỉ trở thành công cụ quản lý khi được cập nhật đều. Nhịp phổ biến là hằng tuần: mỗi người phụ trách báo ngày bắt đầu thực tế, phần còn lại tính theo ngày, và ngày dự kiến xong mới. Phần mềm tự đẩy các công việc phụ thuộc và cho thấy ngày kết thúc dự án mới. Người quản lý dự án so với đường cơ sở để thấy chênh lệch theo từng công việc và từng mốc.
Nên báo cáo bằng chênh lệch có ý nghĩa thay vì toàn bộ biểu đồ. Lãnh đạo cần biết ba điều: mốc nào đang trễ và trễ bao nhiêu, nguyên nhân, và phương án xử lý cần ai quyết định. Một biểu đồ hai trăm dòng chiếu lên màn hình trong cuộc họp thường chỉ làm mọi người lạc.
Về đường cơ sở, nguyên tắc là chỉ chốt lại khi có thay đổi phạm vi được phê duyệt chính thức, không chốt lại chỉ vì đang chậm. Một số tổ chức lưu nhiều phiên bản đường cơ sở để thấy lịch sử thay đổi. Nếu đường cơ sở được “làm mới” mỗi tháng cho khớp thực tế, biểu đồ luôn đẹp nhưng không còn đo được gì. Khi muốn đo chậm trễ kết hợp với chi phí, Gantt cần được bổ sung bằng phương pháp quản lý giá trị thu được, trình bày ở một bài khác trong danh mục này.
Những lỗi biến Gantt thành bức tranh trang trí
Gõ ngày cứng thay cho liên kết. Khi mỗi thanh có ngày bắt đầu cố định, một công việc chậm không làm dịch chuyển các việc sau. Biểu đồ trông đúng hạn cho tới khi mọi thứ vỡ cùng lúc.
Công việc quá dài. Một thanh kéo dài ba tháng “thi công phần thô” không cho biết gì về tiến độ cho tới tháng thứ ba. Nên chia để mỗi công việc không vượt hai đến bốn kỳ báo cáo.
Thiếu công việc chờ. Chờ phê duyệt, chờ giấy phép, chờ hàng nhập khẩu thông quan là thời gian thật, thường dài và khó đoán. Bỏ qua chúng làm lịch lạc quan hệ thống.
Không thể hiện nguồn lực. Hai thanh song song cùng một người làm là mâu thuẫn mà Gantt không tự cảnh báo nếu không gán nguồn lực.
Một biểu đồ cho mọi đối tượng. Nhóm thực hiện cần chi tiết hằng ngày, ban giám đốc cần bản tóm tắt theo mốc. Dùng chung một bản thì cả hai đều không đọc.
Lập xong cất đi. Gantt không cập nhật trở thành tài liệu lịch sử của một kế hoạch đã không còn tồn tại, nhưng vẫn được dán trên tường như thể còn hiệu lực.
Gantt cho nhiều dự án dùng chung nguồn lực
Doanh nghiệp vừa và lớn hiếm khi chỉ có một dự án. Khi năm dự án cùng dùng một nhóm kỹ sư, một đội lắp đặt hay một phòng pháp chế, biểu đồ Gantt của từng dự án có thể đều hợp lý mà cộng lại thì không khả thi: cùng một tuần, ba dự án đều xếp kỹ sư trưởng đi công trường. Đây là giới hạn của việc nhìn từng dự án riêng lẻ.
Cách xử lý phổ biến là dựng lịch tổng hợp (master schedule) liên kết các dự án, kèm biểu đồ phụ tải nguồn lực theo tuần. Khi thấy cột phụ tải vượt năng lực, người điều phối có ba lựa chọn: lùi công việc có dự trữ, thuê thêm nguồn lực, hoặc để cấp trên quyết định dự án nào ưu tiên. Quyết định cuối cùng là quyết định danh mục, thường thuộc về ban điều hành hoặc văn phòng quản lý dự án, không nên để từng người quản lý dự án tự giành nhau.
Một thực tế nữa là các liên kết giữa dự án: dự án mở kho chỉ chạy được khi dự án phần mềm kho xong một phân hệ. Nên khai báo những mốc này thành mốc liên dự án, có người chịu trách nhiệm ở cả hai phía. Khi một dự án trễ, lịch tổng hợp cho thấy ngay dự án nào khác bị ảnh hưởng. Không cần mọi chi tiết của từng dự án trong lịch tổng hợp; chỉ cần các mốc chính, công việc dùng nguồn lực khan hiếm và các điểm giao nhau giữa dự án.
Gantt, sơ đồ mạng, bảng Kanban: chọn công cụ nào
Gantt không phải công cụ duy nhất để quản lý tiến độ. Mỗi công cụ trả lời một câu hỏi khác nhau:
| Công cụ | Trả lời tốt câu hỏi | Yếu ở | Hợp với |
|---|---|---|---|
| Biểu đồ Gantt | Việc gì diễn ra khi nào, mốc ở đâu | Logic phụ thuộc phức tạp, dòng chảy công việc liên tục | Dự án có trình tự rõ, nhiều bên cần đọc lịch |
| Sơ đồ mạng | Việc nào phụ thuộc việc nào, chuỗi nào găng | Khó đọc với người ngoài nghề, không thể hiện thời gian trực quan | Phân tích tiến độ, rút ngắn lịch |
| Bảng Kanban | Việc đang ở trạng thái nào, ách tắc ở đâu | Không cho ngày kết thúc dự án | Dòng việc liên tục, nhóm agile, bảo trì |
| Biểu đồ mốc (milestone chart) | Các điểm then chốt có đạt đúng hạn không | Không thấy công việc bên trong | Báo cáo cho ban giám đốc, hội đồng quản trị |
| Biểu đồ burndown | Khối lượng còn lại giảm nhanh hay chậm | Không thể hiện phụ thuộc | Vòng lặp ngắn trong Scrum |
Trong thực tế, nhiều dự án dùng kết hợp: Gantt ở cấp lộ trình và mốc, Kanban ở cấp nhóm thực hiện hằng ngày. Điều quan trọng là các công cụ lấy chung một nguồn dữ liệu, tránh tình trạng biểu đồ của quản lý nói một đằng, bảng công việc của nhóm nói một nẻo.
Câu hỏi thường gặp
Có thể vẽ biểu đồ Gantt bằng bảng tính không?
Được, bằng cách dùng biểu đồ thanh xếp chồng hoặc định dạng có điều kiện tô màu ô theo ngày. Cách này hợp với dự án nhỏ, ít phụ thuộc. Hạn chế là phải tự tính lại ngày khi một việc chậm, dễ sai khi số công việc tăng lên.
Mốc khác công việc thế nào trên Gantt?
Mốc có thời lượng bằng không, thường hiển thị bằng hình thoi, đánh dấu một sự kiện như phê duyệt hay bàn giao. Công việc có thời lượng và tiêu tốn nguồn lực. Mốc không nên dùng để thay cho công việc chờ có thời lượng thật.
Nên chia công việc trên Gantt chi tiết tới mức nào?
Đủ để mỗi công việc xong trong khoảng một đến bốn kỳ báo cáo và có một người chịu trách nhiệm. Chi tiết hơn thì khó duy trì, khái quát hơn thì không theo dõi được. Phần xa về thời gian có thể để khái quát và chi tiết hoá dần.
Vì sao phần mềm cho ngày kết thúc khác với ngày ban giám đốc yêu cầu?
Vì phần mềm tính từ logic và thời lượng, còn ngày yêu cầu là mong muốn. Khi lệch, cần xem đường găng để tìm công việc có thể rút ngắn hoặc làm song song, hoặc thương lượng lại phạm vi; ép nhập ngày cứng chỉ che vấn đề.
Gantt có phù hợp với dự án agile không?
Ở cấp vòng lặp thì ít phù hợp vì nhóm tự chọn việc. Ở cấp lộ trình, Gantt vẫn hữu ích để thể hiện các đợt phát hành, phụ thuộc giữa nhóm và mốc với đối tác, miễn là hiểu rằng nội dung từng đợt có thể thay đổi.