INFOCHIEF ACADEMY · PROJECT MANAGER KNOWLEDGE SERIES

Lãnh đạo dự án theo mô hình Agile, Waterfall và Hybrid: Lựa chọn phương pháp theo đặc điểm dự án.

Agile, Waterfall và Hybrid phù hợp với những loại bất định và điều kiện phối hợp khác nhau. Lãnh đạo dự án cần thiết kế nhịp học hỏi, kiểm chứng và quyền quyết định theo đặc điểm công việc thực tế.

Biên soạn: Infochief Academy · Chuyên đề: Giám đốc dự án IT – Project Manager

← Trở về thư viện bài viết

Minh họa biên tập: lãnh đạo và đội triển khai xem nguyên mẫu để chọn cách phối hợp phù hợp đặc điểm dự án.

Một dự án đổi nền tảng lõi được yêu cầu chuyển sang Agile vì kế hoạch cũ quá chậm. Đội bắt đầu chia công việc thành Sprint, nhưng vẫn phải chờ quyết định dữ liệu, tích hợp và lịch chuyển đổi từ nhiều đơn vị. Trong tình huống minh họa giả định này, cách tổ chức cuộc họp đã đổi, còn cơ chế tạo ra sự chậm trễ vẫn giữ nguyên.

Lựa chọn Agile, Waterfall hoặc Hybrid cần dựa trên đặc điểm công việc và cách giảm bất định. Phương pháp không thay thế mục tiêu, nguồn lực hay quyền quyết định. Ở cấp lãnh đạo, điều cần thiết là hiểu phần nào phải học qua phản hồi, phần nào cần ổn định trước và các bên sẽ cam kết kết quả như thế nào.

Xem loại bất định trước khi chọn tên phương pháp

Một dự án có thể chưa rõ nhu cầu người dùng, chưa rõ khả năng công nghệ hoặc có yêu cầu ổn định nhưng phụ thuộc nhiều đối tác. Những loại bất định này khác nhau. Nếu sản phẩm cần được thử với khách hàng để biết có tạo giá trị không, các vòng phản hồi ngắn rất hữu ích. Nếu một hoạt động chuyển đổi cần nhiều hệ thống sẵn sàng cùng lúc, lịch phụ thuộc tổng thể vẫn phải được quản lý chặt.

Cần xem mức thay đổi của yêu cầu, khả năng chia sản phẩm thành phần sử dụng được và thời gian nhận phản hồi. Một chức năng chỉ có thể kiểm tra sau khi có dữ liệu toàn bộ sẽ khó được đánh giá như một phần độc lập. Ngược lại, cố chốt mọi màn hình trước khi người dùng trải nghiệm có thể tạo ra một đặc tả đầy đủ nhưng thiếu hiểu biết về công việc thực tế.

Năng lực lãnh đạo dự án IT giúp đặt câu hỏi này cùng chủ nghiệp vụ và đội kỹ thuật. Không nên chọn phương pháp vì nó phổ biến hoặc vì một dự án khác đã thành công. Trước hết cần biết tổ chức muốn giảm bất định nào và có điều kiện cung cấp bằng chứng theo cách nào.

Agile cần phản hồi thật và quyền ưu tiên rõ

Agile là một cách tiếp cận phát triển thích ứng; Scrum là một framework cụ thể, không đồng nghĩa với toàn bộ Agile. Scrum Guide mô tả việc tạo giá trị qua giải pháp thích ứng cho vấn đề phức tạp, dựa trên minh bạch, kiểm tra và thích nghi. Trong dự án IT, điều đó đòi hỏi sản phẩm có thể quan sát, tiêu chí chất lượng rõ và người đủ quyền quyết định ưu tiên.

Chia việc thành Sprint nhưng không có phản hồi từ người sử dụng sẽ khó giảm rủi ro làm sai nhu cầu. Người đại diện nghiệp vụ cần thời gian tham gia và quyền giải quyết những ưu tiên thuộc phạm vi. Một Product Owner chỉ chuyển tiếp yêu cầu giữa các phòng ban mà không được chốt sẽ tạo thêm thời gian chờ. Lãnh đạo phải hỗ trợ vai trò này trước khi kỳ vọng tốc độ tăng.

Agile cũng cần kiểm soát đầu tư. Có thể cố định một khoảng tài trợ và thời gian, rồi ưu tiên kết quả có giá trị nhất trong phạm vi đó. Tuy nhiên, những nghĩa vụ bắt buộc hoặc điều kiện an toàn không được coi là phần tùy chọn chỉ vì backlog có thể đổi. Phải phân biệt sự linh hoạt về thứ tự tính năng với việc tự thay mục tiêu hoặc chấp nhận rủi ro ngoài ủy quyền.

Các nguyên tắc của Agile Manifesto nhấn mạnh phần mềm có giá trị, hợp tác và phát triển bền vững. Không nên diễn giải Agile như lý do bỏ tài liệu cần thiết hoặc kiểm thử. Năng lực quản lý dự án CNTT vẫn cần để giữ minh bạch về chi phí, phụ thuộc và điều kiện hoàn tất.

Waterfall phù hợp khi có thể lập kế hoạch tuần tự đáng tin

Cách tiếp cận dự báo theo giai đoạn thường hữu ích khi yêu cầu tương đối ổn định, đầu ra và phương pháp xác minh có thể xác định sớm. Những hoạt động triển khai hạ tầng hoặc chuyển đổi có cửa sổ cụ thể cần trình tự và điều kiện rõ. Giá trị của kế hoạch nằm ở việc kiểm tra phụ thuộc và chuẩn bị năng lực, không ở việc khóa mọi quyết định dù bằng chứng mới đã xuất hiện.

Waterfall không có nghĩa không được thay đổi. Một phát hiện ảnh hưởng yêu cầu vẫn phải được đánh giá và cập nhật qua cơ chế kiểm soát. Điểm cần cân nhắc là chi phí thay đổi ở các giai đoạn sau. Nếu thiết kế khó đảo ngược hoặc tích hợp có thời gian chuẩn bị dài, quyết định sớm cần bằng chứng đủ mạnh để tránh làm lại lớn.

Rủi ro nằm ở việc nhận phản hồi quá muộn. Chủ nghiệp vụ có thể ký đặc tả nhưng chưa hình dung trải nghiệm thực tế. Vì vậy, dù lập kế hoạch theo giai đoạn, có thể dùng mô hình thử hoặc kiểm tra kịch bản sớm để làm rõ nhu cầu. Những hoạt động này hỗ trợ chất lượng đầu vào cho kế hoạch, không nhất thiết biến toàn bộ dự án thành một mô hình khác.

Doanh nghiệp cần phân biệt phần việc ổn định với phần đang cần khám phá. Nếu tất cả đều được chốt theo cùng mức chắc chắn, dự báo sẽ che nhiều giả định. Khi đặc điểm công việc khác nhau trong cùng dự án, Hybrid có thể hữu ích, nhưng cần được thiết kế rõ hơn việc kết hợp vài cuộc họp của hai phương pháp.

Hybrid cần quy định cách các phần phối hợp với nhau

Hybrid có thể dùng phát triển lặp cho ứng dụng, kết hợp kế hoạch giai đoạn cho dữ liệu, hạ tầng và chuyển đổi. Vấn đề cần giải quyết là điểm giao: khi nào phiên bản đủ để tích hợp, dữ liệu nào sẵn sàng, tiêu chí nào cho phép mở rộng và ai chốt thay đổi. Nếu không có cách nối, đội phát triển có thể tiến nhanh trong khi lịch triển khai tổng thể vẫn bị chặn.

Bảng dưới đây giúp lựa chọn theo đặc điểm dự án. Các gợi ý không phải quy tắc rằng một ngành hay một loại hệ thống luôn phải dùng một phương pháp.

Đặc điểm cần xét	Hướng phù hợp để cân nhắc	Điều kiện phải kiểm tra
Nhu cầu còn cần khám phá	Phát triển lặp, phản hồi sớm	Người dùng và quyền ưu tiên
Yêu cầu ổn định, trình tự rõ	Kế hoạch giai đoạn	Đầu vào và phụ thuộc đáng tin
Sản phẩm chia được phần có ích	Triển khai tăng dần	Chất lượng và khả năng tiếp nhận
Chuyển đổi nhiều hệ thống	Kế hoạch tích hợp tổng thể	Cửa sổ triển khai và phục hồi
Các phần có mức bất định khác nhau	Hybrid được thiết kế rõ	Quyền, mốc và bằng chứng chung

Ví dụ giả định: dự án xây cổng khách hàng có thể thử từng luồng với người dùng, trong khi hệ thống nhận thanh toán cần hoàn tất kiểm thử và đối soát trước mở rộng. Lịch tổng thể phải phản ánh hai loại công việc. Không thể dùng số Sprint đã hoàn tất để thay bằng chứng rằng toàn bộ chuỗi giao dịch sẵn sàng vận hành.

Năng lực quản lý đội ngũ IT hỗ trợ bố trí kỹ năng và cam kết giữa các nhóm. Mỗi nhóm cần biết đầu ra và thời điểm mà nhóm khác dựa vào. Hybrid chỉ có hiệu lực khi những điểm giao được điều hành chung, thay vì để mỗi bên tối ưu phần của mình rồi chờ bên còn lại.

Cấp lãnh đạo cần một cơ chế kiểm soát chung

Dù phương pháp nào, cần giữ mục tiêu, tài trợ, chủ sở hữu lợi ích và quyền quyết định. Dashboard nên cho biết kết quả đã có, phần việc còn lại, rủi ro và quyết định cần chốt. Không so sánh trực tiếp số story point giữa các đội để đánh giá hiệu quả, vì cách ước lượng và bối cảnh có thể khác nhau. Bằng chứng quan trọng là sản phẩm đạt chất lượng và kết quả sử dụng phù hợp.

GAO Agile Assessment Guide trình bày thực hành đánh giá việc áp dụng và kiểm soát Agile trong bối cảnh đầu tư IT. Có thể tham khảo nguyên tắc giám sát thích hợp với phát triển tăng dần, nhưng cần điều chỉnh cho doanh nghiệp. Không nên áp bộ chỉ số tiến độ dự báo nguyên vẹn cho công việc khám phá, hoặc bỏ dự báo tổng thể chỉ vì đội phát triển làm theo vòng lặp.

Hợp đồng và cơ chế mua sắm cũng cần phù hợp. Nếu phạm vi còn nhiều bất định, phải làm rõ cách ưu tiên, chấp nhận đầu ra và xử lý thay đổi. Nếu cam kết mốc cố định, cần biết phần nào không thể thương lượng. Quyền thương mại và pháp lý thuộc người phụ trách có thẩm quyền; Project Manager cung cấp tác động để lựa chọn được nhất quán với cách triển khai.

Chọn phương pháp bằng một thử nghiệm có mục tiêu

Có thể bắt đầu với một phần công việc đại diện để kiểm tra khả năng nhận phản hồi, phối hợp và bàn giao. Trước thử, xác định điều muốn học và dấu hiệu cho thấy cách tổ chức phù hợp. Không nên đánh giá chỉ bằng mức hài lòng với cuộc họp mới. Cần xem phản hồi có làm thay đổi ưu tiên, thời gian chờ có giảm và sản phẩm có đạt điều kiện sử dụng không.

Vận hành phải tham gia những phần liên quan tiếp nhận. Năng lực quản lý dịch vụ IT giúp giữ hỗ trợ và chất lượng dịch vụ trong quyết định triển khai tăng dần. Tốc độ phát triển không bảo đảm tổ chức có thể tiếp nhận cùng tốc độ. Nếu người dùng và hỗ trợ quá tải, cần điều chỉnh nhịp bàn giao hoặc phạm vi.

Với dự án ở mở bài, hãy rà lại loại bất định và phụ thuộc đang gây chậm trước khi chọn một nhãn phương pháp. Giữ kế hoạch cho phần cần phối hợp chặt, tạo vòng phản hồi cho phần cần học và xác định quyền quyết định chung. Lựa chọn phương pháp có ý nghĩa khi nó giúp tổ chức tạo bằng chứng và cam kết phù hợp với công việc thực tế.