Mở đầu — vì sao bài này quan trọng
Nếu có một câu hỏi khiến các Project Manager tranh cãi bất tận trong các buổi cà phê và cả trong phòng họp, thì đó là: "Dự án này nên chạy Waterfall hay Agile?". Đáng tiếc là rất nhiều người trả lời câu hỏi này bằng cảm tính hoặc theo trào lưu. Có bạn PM trẻ vừa học xong khoá Scrum liền tuyên bố "Waterfall đã chết", rồi ép một dự án xây dựng phần cứng phải chạy sprint hai tuần — và thất bại thảm hại. Ngược lại, có anh PM kỳ cựu quen quản lý theo kế hoạch cứng, đem đúng tư duy đó áp vào một startup fintech đang dò tìm sản phẩm — kết quả là team làm ra một hệ thống hoàn hảo cho một nhu cầu không còn tồn tại.
Sự thật là: Waterfall và Agile không phải là hai phe đối địch, mà là hai công cụ khác nhau cho hai loại bài toán khác nhau. Người PM giỏi không phải là người "theo phe Agile" hay "theo phe Waterfall", mà là người biết đọc bối cảnh dự án và chọn đúng cách tiếp cận — hoặc kết hợp cả hai. Bài học này sẽ cho bạn khung tư duy để ra quyết định đó một cách có cơ sở, thay vì chạy theo trào lưu hay thói quen.
Khái niệm cốt lõi
Waterfall — dòng chảy tuần tự
Waterfall (mô hình thác nước) là cách tiếp cận tuần tự: dự án đi qua các giai đoạn nối tiếp nhau, giai đoạn sau chỉ bắt đầu khi giai đoạn trước đã hoàn tất và được phê duyệt. Chuỗi kinh điển gồm: Requirement (thu thập yêu cầu) → Design (thiết kế) → Build (xây dựng) → Test (kiểm thử) → Deploy (triển khai).
Triết lý nền tảng của Waterfall là "plan upfront" — lập kế hoạch đầy đủ ngay từ đầu. Ta cố gắng hiểu trọn vẹn yêu cầu, đóng băng phạm vi (scope), rồi thực thi theo đúng bản vẽ. Điểm mạnh của nó là sự rõ ràng và dự đoán được: bạn biết trước sẽ làm gì, mất bao lâu, tốn bao nhiêu, và bàn giao cái gì.
Điểm yếu chí tử của Waterfall nằm ở chi phí thay đổi. Vì mọi thứ được thiết kế nối tiếp, một thay đổi yêu cầu phát hiện muộn (ví dụ ở giai đoạn Test) sẽ buộc bạn quay ngược về Design, kéo theo hiệu ứng domino tốn kém. Có một quy luật kinh điển trong kỹ thuật phần mềm: chi phí sửa một lỗi phát hiện ở giai đoạn vận hành có thể cao gấp 100 lần so với sửa ngay ở giai đoạn yêu cầu. Waterfall vì thế "phạt" rất nặng những thay đổi đến muộn.
Waterfall phù hợp khi: scope rõ ràng và ổn định; yêu cầu tuân thủ quy định (regulatory/compliance) chặt chẽ; sản phẩm vật lý khó "làm lại" (xây cầu, sản xuất phần cứng); và khi khách hàng cần một hợp đồng cố định về phạm vi, thời gian, chi phí.
Agile — thích ứng theo vòng lặp
Agile không phải một quy trình cụ thể, mà là một tập giá trị và nguyên tắc (Agile Manifesto, 2001) đề cao: cá nhân và tương tác hơn quy trình và công cụ; phần mềm chạy được hơn tài liệu đầy đủ; hợp tác với khách hàng hơn đàm phán hợp đồng; và phản ứng với thay đổi hơn bám theo kế hoạch.
Về mặt vận hành, Agile làm việc theo vòng lặp ngắn (iteration): thay vì xây trọn sản phẩm rồi mới giao, ta chia thành các phần nhỏ có giá trị, làm từng phần trong một khoảng thời gian ngắn (thường 1–4 tuần), giao cho khách hàng, lấy phản hồi, rồi điều chỉnh cho vòng tiếp theo. Mỗi vòng lặp đều đi qua đủ requirement–design–build–test — nhưng ở quy mô nhỏ.
Triết lý của Agile là "embrace change" — đón nhận thay đổi. Thay vì cố khoá scope, Agile chấp nhận rằng ta không thể biết hết mọi thứ từ đầu, đặc biệt với sản phẩm mới. Nhờ giao hàng liên tục và lấy phản hồi sớm, Agile giảm rủi ro "làm ra sản phẩm sai" và cho phép chuyển hướng khi thị trường thay đổi.
Đánh đổi là gì? Agile khó dự đoán chính xác chi phí và thời điểm hoàn tất "toàn bộ" sản phẩm, vì scope được phép tiến hoá. Nó cũng đòi hỏi khách hàng cam kết tham gia liên tục — điều mà nhiều khách hàng doanh nghiệp truyền thống ở Việt Nam chưa quen.
Cùng nhìn qua ba trục so sánh
Để dễ nhớ, hãy so ba trục cốt lõi. Trục kế hoạch: Waterfall lập kế hoạch chi tiết một lần ở đầu; Agile lập kế hoạch cuốn chiếu, chi tiết dần theo từng vòng. Trục thay đổi: Waterfall coi thay đổi là rủi ro cần kiểm soát và tính phí; Agile coi thay đổi là lợi thế cạnh tranh cần tận dụng. Trục giao hàng: Waterfall giao một lần "Big Bang" ở cuối; Agile giao từng phần giá trị đều đặn.
Một cách ẩn dụ dễ hiểu: Waterfall giống như bạn đặt xây một căn nhà theo đúng bản vẽ đã duyệt — bạn không muốn kiến trúc sư "thử nghiệm" đổi vị trí cột chịu lực giữa chừng. Agile giống như bạn nấu một nồi phở mới cho quán — bạn nêm nếm, mời khách thử từng bát, điều chỉnh gia vị dần cho đến khi ra công thức bán chạy.
Tình huống thực tế
Ví dụ 1 — Vietcombank nâng cấp cổng Internet Banking (Waterfall thắng thế ở phần lõi)
Giả định một ngân hàng lớn như Vietcombank triển khai dự án nâng cấp hệ thống thanh toán liên ngân hàng, tích hợp với hệ thống của Ngân hàng Nhà nước. Đây là môi trường regulatory nặng: mọi giao dịch phải tuân thủ quy định về an toàn thông tin, phải qua kiểm toán, phải có tài liệu đặc tả đầy đủ để cơ quan quản lý phê duyệt trước khi go-live.
Ở đây, phần lõi giao dịch được chạy theo Waterfall: yêu cầu được đặc tả chi tiết và ký duyệt, thiết kế kiến trúc được hội đồng kỹ thuật thông qua, rồi mới build và test theo kịch bản nghiêm ngặt. Lý do rất chính đáng: bạn không thể "thử nghiệm và điều chỉnh dần" trên một hệ thống chuyển tiền của hàng triệu người dùng. Một thay đổi tuỳ hứng có thể gây sai lệch số dư — hậu quả pháp lý và uy tín là không thể chấp nhận.
Bài học rút ra: Khi scope bị ràng buộc bởi quy định pháp lý và sai sót có chi phí cực cao, tính dự đoán và tài liệu chặt chẽ của Waterfall là một lợi thế thật sự, không phải "lỗi thời". Đừng để trào lưu Agile khiến bạn coi thường giá trị của việc lập kế hoạch kỹ ở những bối cảnh này.
Ví dụ 2 — Tiki thử nghiệm tính năng gợi ý sản phẩm (Agile phát huy)
Hãy tưởng tượng đội sản phẩm của Tiki muốn ra mắt tính năng "gợi ý sản phẩm cá nhân hoá" trên trang chủ. Không ai — kể cả Product Owner giỏi nhất — biết chắc thuật toán gợi ý nào sẽ làm tăng tỉ lệ chuyển đổi (conversion). Nếu chạy Waterfall, đội sẽ dành ba tháng đặc tả và xây một hệ thống gợi ý "hoàn chỉnh", rồi mới biết khách hàng có click hay không — một canh bạc ba tháng.
Thay vào đó, đội chạy Agile với các sprint hai tuần. Sprint đầu họ ra một phiên bản gợi ý đơn giản dựa trên "sản phẩm đã xem gần đây", tung cho 5% người dùng (A/B test), đo lường. Dữ liệu cho thấy chỉ số click-through tăng 8%. Sprint tiếp theo họ thử thêm gợi ý theo "sản phẩm mua kèm", đo tiếp. Cứ thế, sau sáu sprint (khoảng ba tháng), họ đã có một tính năng được thị trường xác nhận từng bước, thay vì một cú đặt cược duy nhất. Điều quan trọng là: nếu sprint thứ hai cho kết quả xấu, họ chỉ mất hai tuần chứ không phải ba tháng.
Bài học rút ra: Khi bạn đang trong vùng bất định cao — sản phẩm mới, hành vi khách hàng chưa rõ, cần học từ thị trường — Agile giúp bạn "sai rẻ và sai sớm". Giá trị lớn nhất của Agile không phải là làm nhanh hơn, mà là giảm rủi ro làm ra thứ không ai cần.
Ví dụ 3 — FPT Software và mô hình Hybrid với khách Nhật
Trong thực tế outsourcing của Việt Nam, một tình huống rất phổ biến ở các công ty như FPT Software là khách hàng (đặc biệt là khách Nhật) yêu cầu hợp đồng cố định phạm vi và chi phí — vốn là tư duy Waterfall — nhưng lại muốn xem tiến độ và phản hồi thường xuyên như Agile. Ép hoàn toàn về một phía đều gây căng thẳng.
Giải pháp thường thấy là Hybrid (Water-Scrum-Fall): giai đoạn đầu chạy Waterfall để chốt yêu cầu tổng thể và ký hợp đồng khung với khách; giai đoạn phát triển ở giữa chạy Scrum với các sprint hai tuần, demo đều đặn cho khách qua video call để lấy phản hồi sớm; giai đoạn cuối lại quay về Waterfall cho khâu UAT, tài liệu bàn giao và triển khai theo quy trình nghiệm thu chặt chẽ của khách. Nhờ vậy, đội vừa giữ được cam kết hợp đồng, vừa linh hoạt điều chỉnh chi tiết trong quá trình làm.
Bài học rút ra: Trong thực tế, câu hỏi hiếm khi là "Waterfall HAY Agile" mà thường là "Waterfall VÀ Agile phối hợp thế nào". Mô hình Hybrid không phải là sự thoả hiệp nửa vời, mà là cách trưởng thành để đáp ứng cả ràng buộc hợp đồng lẫn nhu cầu linh hoạt — rất phù hợp bối cảnh gia công phần mềm Việt Nam.
Hướng dẫn từng bước
Khi đứng trước một dự án mới và phải quyết định cách tiếp cận, hãy đi qua các bước sau:
Bước 1 — Đánh giá độ rõ ràng của yêu cầu. Hỏi: khách hàng và team đã hiểu rõ mình muốn gì chưa? Nếu yêu cầu ổn định, ít khả năng đổi (ví dụ: chuyển đổi một hệ thống đã vận hành ổn định) → nghiêng về Waterfall. Nếu yêu cầu mơ hồ, đang khám phá → nghiêng về Agile.
Bước 2 — Đo mức độ bất định và tần suất thay đổi. Thị trường, công nghệ, hành vi người dùng có biến động nhanh không? Bất định càng cao, giá trị của việc lặp và học càng lớn → Agile. Bất định thấp → Waterfall an toàn hơn và rẻ hơn về mặt quản trị.
Bước 3 — Xem xét ràng buộc pháp lý và chi phí lỗi. Dự án có bị quy định pháp lý ràng buộc, cần tài liệu để kiểm toán, hay chi phí một lỗi là thảm hoạ (y tế, hàng không, ngân hàng lõi)? Nếu có → phần đó cần kỷ luật Waterfall.
Bước 4 — Đánh giá khả năng tham gia của khách hàng. Agile đòi hỏi khách hàng (hoặc Product Owner đại diện) cam kết tham gia đều đặn: dự demo, cho phản hồi, ưu tiên backlog. Nếu khách hàng không thể cam kết điều này → Agile thuần sẽ khó, cân nhắc Hybrid.
Bước 5 — Xét bản chất sản phẩm. Sản phẩm phần mềm có thể triển khai và cập nhật liên tục thì hợp Agile. Sản phẩm vật lý, hạ tầng, hoặc thứ chỉ giao "một lần" (in ấn, xây dựng) thì tự nhiên nghiêng về Waterfall.
Bước 6 — Quyết định và cân nhắc Hybrid. Tổng hợp các tín hiệu trên. Nếu tất cả nghiêng một phía, chọn phía đó. Nếu tín hiệu trái chiều — ví dụ scope pháp lý chặt nhưng chi tiết bên trong lại bất định — hãy thiết kế mô hình Hybrid: Waterfall ở khung ngoài, Agile ở phần thực thi.
Bước 7 — Truyền đạt lựa chọn cho stakeholder. Đừng chọn xong rồi im lặng. Giải thích cho các bên liên quan vì sao chọn cách này, kỳ vọng về cách giao hàng, cách xử lý thay đổi ra sao. Sự đồng thuận về "luật chơi" ngay từ đầu tránh được vô số xung đột về sau.
Lỗi thường gặp & mẹo
Lỗi 1 — "Agile-fall": làm Agile trên hình thức nhưng Waterfall trong tư duy. Nhiều team gọi tên sprint, họp standup, nhưng thực chất đã khoá cứng toàn bộ scope từ đầu và không bao giờ chấp nhận thay đổi. Đó là Waterfall khoác áo Agile — vừa mất tính dự đoán của Waterfall, vừa không có lợi ích thích ứng của Agile. Mẹo: Kiểm tra bằng câu hỏi thật: "Khi khách đổi ý ở sprint 4, quy trình của ta phản ứng thế nào?". Nếu câu trả lời là "không cho đổi", bạn chưa thực sự Agile.
Lỗi 2 — Ép Agile vào dự án không phù hợp. Chạy sprint hai tuần cho một dự án xây dựng nhà xưởng hay tuân thủ quy định nghiêm ngặt thường phản tác dụng. Mẹo: Agile không phải "đúng" mặc định. Hãy để bối cảnh quyết định, không phải trào lưu.
Lỗi 3 — Coi Waterfall là "lỗi thời" nên xấu hổ khi dùng. Waterfall vẫn là lựa chọn tối ưu cho rất nhiều bài toán. Mẹo: Đo bằng kết quả dự án, không đo bằng độ "thời thượng" của phương pháp.
Lỗi 4 — Chọn phương pháp trước khi hiểu bài toán. Một số PM quyết "chạy Scrum" ngay khi nhận dự án, trước cả khi hiểu yêu cầu. Mẹo: Luôn phân tích bối cảnh (bảy bước ở trên) trước, chọn phương pháp sau.
Lỗi 5 — Bỏ qua văn hoá và năng lực tổ chức. Agile đòi hỏi team tự chủ, giao tiếp cởi mở, quản lý chấp nhận trao quyền. Nếu tổ chức còn nặng phê duyệt tầng lớp, áp Agile thuần sẽ vỡ. Mẹo: Đánh giá "độ sẵn sàng Agile" của tổ chức, và nếu cần thì chuyển đổi dần qua Hybrid thay vì lột xác một đêm.
Bài tập thực hành
Bài tập 1 — Phân loại dự án. Với mỗi dự án sau, hãy quyết định Waterfall, Agile hay Hybrid, và viết 2–3 câu lý giải dựa trên các trục đã học: (a) Xây dựng ứng dụng đặt lịch khám cho một phòng khám tư nhân mới, chưa rõ bác sĩ và bệnh nhân cần gì; (b) Di trú hệ thống lương của một tập đoàn 5.000 nhân viên sang phần mềm mới, quy trình lương đã ổn định nhiều năm; (c) Phát triển hệ thống hồ sơ bệnh án điện tử phải tuân thủ quy định của Bộ Y tế nhưng giao diện cho bác sĩ vẫn cần thử nghiệm nhiều.
Bài tập 2 — Bảng quyết định của riêng bạn. Lấy một dự án bạn đang hoặc từng tham gia. Chấm điểm nó trên năm tiêu chí (độ rõ yêu cầu, mức bất định, ràng buộc pháp lý, khả năng tham gia của khách, bản chất sản phẩm) theo thang 1–5. Dựa trên tổng thể, đề xuất cách tiếp cận và giải thích.
Bài tập 3 — Thiết kế Hybrid. Cho một dự án gia công phần mềm cho khách nước ngoài yêu cầu hợp đồng cố định giá nhưng muốn phản hồi thường xuyên. Hãy phác thảo một mô hình Hybrid: giai đoạn nào chạy Waterfall, giai đoạn nào chạy Agile, và điểm bàn giao/nghiệm thu đặt ở đâu.
Tóm tắt
Waterfall và Agile không phải kẻ thù của nhau, mà là hai công cụ cho hai loại bài toán. Waterfall — tuần tự, lập kế hoạch trọn gói từ đầu, giao một lần — mạnh khi scope rõ, yêu cầu ổn định, ràng buộc pháp lý chặt và chi phí lỗi cao. Agile — lặp ngắn, thích ứng, giao từng phần và học từ phản hồi — mạnh khi bất định cao, sản phẩm mới, cần giảm rủi ro "làm sai". Trong thực tế Việt Nam, đặc biệt ở mảng outsourcing, Hybrid thường là câu trả lời trưởng thành nhất: khung ngoài Waterfall để giữ cam kết hợp đồng, phần thực thi Agile để linh hoạt.
Điều quan trọng nhất cần mang theo: đừng chọn phương pháp theo trào lưu hay thói quen. Hãy đọc bối cảnh dự án qua các trục yêu cầu, bất định, pháp lý, sự tham gia của khách và bản chất sản phẩm — rồi mới quyết định. Người PM giỏi được đánh giá bằng việc chọn đúng công cụ cho đúng bài toán, chứ không phải bằng việc trung thành với một trường phái.