Quản lý dự án: truyền thống, lặp lại hay kết hợp?

Giống như hầu hết các quản lý dự án (và các tổ chức), bạn có lẽ đang phải vật lộn để lựa chọn một phương thức triển khai tối ưu. Phần lớn chúng ta đều nhận thấy rằng các phương pháp truyền thống không đảm bảo triển khai thành công, và chúng ta luôn tìm kiếm một hướng đi tốt hơn.

Các kỹ thuật phát triển lặp (iterative) hoặc linh hoạt (agile) đã nhận được rất nhiều đánh giá tích cực từ truyền thông trong những năm gần đây như một bước cải tiến vượt bậc, giúp triển khai dự án thành công hơn. Do đó, giống như hầu hết các tổ chức hiện nay, tổ chức của bạn có lẽ đang tự hỏi nên ứng dụng các kỹ thuật phát triển lặp hoặc agile này ở đâu và như thế nào là tốt nhất để cải thiện cả tiến độ lẫn mức độ thành công khi triển khai dự án.

Nói một cách ngắn gọn, các kỹ thuật phát triển lặp sẽ lên kế hoạch, phát triển và triển khai các tính năng của dự án theo từng phần nhỏ (hoặc các phân kỳ lặp). Chìa khóa để triển khai lặp đi lặp lại thành công là mỗi phần nhỏ thực sự hoạt động như một dự án mini nhỏ hơn nằm trong phạm vi của toàn bộ dự án. Nhờ vậy, mỗi phân kỳ lặp của dự án mini có thể lập kế hoạch tốt hơn cho các nỗ lực cần thiết để hoàn thành một phân kỳ kéo dài hai tuần, thay vì phải xử lý một kế hoạch dài hạn hai năm. Ngoài ra, vì chúng ta lập kế hoạch theo từng khoảng tăng hai tuần một, chúng ta có thể dễ dàng điều chỉnh kế hoạch cho hai tuần tiếp theo để thích ứng với bất kỳ thay đổi nào được ghi nhận.

Nghiên cứu tình huống về Agile so với phương pháp truyền thống

Tôi muốn tạm dừng một chút để mô tả một tình huống không mang tính kỹ thuật, nơi mà phương pháp tiếp cận agile mang lại nhiều thành công hơn so với một kế hoạch truyền thống.

Hãy lấy ví dụ về việc lên kế hoạch cho các hoạt động của cả một ngày—đó chính là dự án. Giống như một dự án lớn, việc này chứa đựng rất nhiều yếu tố không chắc chắn và rủi ro: chúng ta không biết điều gì sẽ xảy ra sau bữa trưa có thể tác động đến kế hoạch của mình, nhưng theo truyền thống, chúng ta vẫn lập một kế hoạch toàn diện cho những gì sẽ làm trong từng giờ của ngày, từ lúc thức dậy lúc 6 giờ sáng cho đến khi đi ngủ lúc 11 giờ đêm.

Đến 9 giờ sáng, chúng ta đã bị chậm lịch trình vì tắc đường khiến chúng ta đến công sở muộn; đến 10 giờ sáng, chúng ta bị gọi vào một cuộc họp khẩn cấp; và cho đến trưa, nhiệm vụ duy nhất trong ngày được hoàn thành là đến được văn phòng, và ngay cả việc đó cũng bị chậm tiến độ.

Bây giờ, hãy coi đây là một dự án agile, nơi tất cả những gì chúng ta lập kế hoạch chỉ là cho phân kỳ lặp (iteration) tiếp theo: chuẩn bị rời khỏi nhà (vì vậy các câu chuyện người dùng - story sẽ là: tắm rửa, ăn sáng và đưa con đến trường). Tất cả việc này đã được triển khai thành công, đúng tiến độ, và trong phạm vi ngân sách.

Vì vậy, với sự tự tin, chúng ta lập kế hoạch cho phân kỳ lặp tiếp theo, đó là đến văn phòng (lái xe đến bến xe buýt, đi tàu ngoại ô đến nhà ga, rồi đi xe buýt thành phố đến văn phòng).

Việc này triển khai không được suôn sẻ cho lắm: Story đầu tiên (lái xe đến bến xe buýt) gặp sự cố tắc đường, vì vậy chúng ta thay đổi user story thành lái xe thẳng đến văn phòng và đồng ý rằng hai story còn lại có thể được loại bỏ khỏi kế hoạch phân kỳ lặp này. Khi đến nơi, chúng ta lập kế hoạch cho phân kỳ lặp tiếp theo. Nhưng ở giữa chu kỳ lập kế hoạch, một story mới được thêm vào (cuộc họp khẩn cấp), và nó sẽ chiếm toàn bộ thời gian của phân kỳ lặp tiếp theo.

Cuối cùng, sau bữa trưa, mọi thứ dịu xuống và chúng ta có thể nhìn vào danh sách công việc tồn đọng (backlog) rồi bắt đầu thực hiện các tác vụ có ưu tiên cao nhất; chúng ta hoàn thành xuất sắc hai phân kỳ lặp để giải quyết các hạng mục có ưu tiên cao nhất trong buổi chiều.

Nếu chúng ta cứ bám lấy kế hoạch truyền thống, chúng ta sẽ chẳng bao giờ hoàn thành được các hạng mục có ưu tiên cao nhất này, vì chúng đã bị dời lịch sang ngày hôm sau do kế hoạch bị trễ bởi việc di chuyển đến văn phòng.

Đâu là phương pháp tiếp cận tốt nhất—agile (linh hoạt), truyền thống, hay hybrid (kết hợp)?

Chính khả năng linh hoạt để thích ứng với các nhu cầu kinh doanh liên tục thay đổi này là điểm mạnh nhất của các phương pháp agile hoặc lặp, và đó là lý do tại sao nhiều tổ chức đang áp dụng phương pháp này. NHƯNG, tổ chức của bạn đã thực sự sẵn sàng để "tất tay" (all in) với mô hình agile (linh hoạt) chưa? Theo kinh nghiệm của tôi, thường có rất nhiều rào cản đối với việc áp dụng agile trên quy mô toàn diện, cụ thể nhất là các chính sách đã ăn sâu bám rễ của tổ chức vốn thường không hoàn toàn tương thích với các phương pháp tiếp cận agile.

Các chính sách như cần có ngân sách cố định, bản tuyên bố hiện thực hóa lợi ích và ngày mục tiêu trước khi một dự án có thể được phê duyệt là rất quan trọng (nhưng thực tế không hề mang tính agile). Tương tự như vậy, các chính sách triển khai của tổ chức cần phải được tuân thủ để đảm bảo không có tác động nào đến các hoạt động hiện tại là điều cốt lõi (nhưng chắc chắn cũng không phải là agile).

Hệ quả là, nhiều tổ chức đang phải vật lộn với cách làm thế nào để vừa duy trì một số "quy trình truyền thống" then chốt, vừa thích ứng được với các phương pháp lặp. Câu trả lời chính là một mô hình triển khai kết hợp (hybrid). Một số phần của dự án có thể được bàn giao bằng các phương pháp quản lý truyền thống, và những phần khác có thể áp dụng phương pháp lặp.

Mô hình triển khai kết hợp

Mô hình kết hợp phổ biến nhất mà tôi từng gặp sẽ hỗ trợ việc khởi động và lập kế hoạch dự án theo kiểu truyền thống, tiếp theo là một chuỗi các phân kỳ lặp (iteration) xen kẽ với các khoảng nghỉ dành cho các hoạt động triển khai phát hành sản phẩm (release) truyền thống, sau đó lại là một chuỗi các phân kỳ lặp và triển khai truyền thống khác.

Trong mô hình này, tôi xây dựng một cấu trúc phân rã công việc (WBS) dựa trên sản phẩm bàn giao truyền thống, giúp xác định các sản phẩm bàn giao cốt lõi cần thiết trong tổ chức để dự án được phê duyệt, chẳng hạn như Điều lệ dự án (Project Charter), Kế hoạch quản lý dự án (Project Management Plan) và Ngân sách dự án (Project Budget).

Các sản phẩm bàn giao ban đầu này có thể được phát triển và quản lý bằng các phương pháp truyền thống để chứng minh cho ban quản lý thấy rằng dự án này là phù hợp và là một nơi xứng đáng để đầu tư nguồn lực.

Khi dự án đã được phê duyệt, nó có thể chuyển sang phương pháp tiếp cận lặp, trong đó một danh sách công việc tồn đọng (backlog) gồm các câu chuyện người dùng (story) được duy trì, và những story có ưu tiên cao nhất sẽ được lựa chọn và phát triển toàn diện trong phân kỳ lặp tiếp theo. Góc nhìn về dự án sẽ thay đổi từ sơ đồ Gantt truyền thống sang một bảng tương tác kéo-thả cho phép phân bổ linh hoạt các story vào các phân kỳ lặp.

Tại bất kỳ thời điểm nào, thường là hàng ngày, chủ sản phẩm (product owner) đều có thể thêm, xóa và thay đổi các story trong backlog để phản ánh các nhu cầu kinh doanh đang thay đổi.

Vào cuối mỗi phân kỳ lặp, chúng tôi tạm dừng và thực hiện một buổi đánh giá cải tiến (retrospective) về những thành công và thất bại, từ đó đưa ra các thay đổi để triển khai những cải tiến cần thiết. Tiếp theo, và là điều quan trọng nhất, chúng tôi xem xét lại danh sách product backlog và chọn ra các story quan trọng nhất để làm trong phân kỳ lặp kế tiếp. Cách tiếp cận này đảm bảo dự án luôn tập trung vào phần việc phù hợp nhất và có giá trị cao nhất tại mọi thời điểm.

Trong mỗi phân kỳ lặp, đội ngũ có thể áp dụng các nguyên tắc agile như họp đứng hàng ngày (daily standup) và thảo luận về trạng thái của các story được lên lịch cho phân kỳ hiện tại. Bằng cách này, đội ngũ có toàn quyền kiểm soát đối với phần việc được hoàn thành trong một phân kỳ lặp, trong khi vẫn đảm bảo rằng dự án tổng thể vẫn được cập nhật và sẵn sàng cho các báo cáo của doanh nghiệp về năng suất nguồn lực cũng như trạng thái của danh mục (portfolio) và chương trình (program).

Một chìa khóa trong các nguyên tắc agile là khả năng triển khai giải pháp cuối cùng thông qua các đợt phát hành nhỏ. Điều này mang lại lợi ích là có thể sử dụng các tính năng sơ bộ để đạt được một số lợi ích kinh doanh dự kiến càng nhanh càng tốt.

Ngoài ra, việc này còn có lợi thế là xác thực sớm giải pháp, để mọi điều chỉnh có thể dễ dàng được đưa vào các story còn lại trong product backlog. Do đó, ngay khi có đủ số lượng story ưu tiên cao được hoàn thành trong các phân kỳ lặp, dự án sẽ chuyển hướng quay trở lại chu kỳ truyền thống và thực hiện các tác vụ triển khai tiêu chuẩn do tổ chức yêu cầu.

Dùng thử Microsoft Project miễn phí

Dùng thử Microsoft Project một tháng miễn phí

Tìm hiểu cách thức

Các hoạt động phát hành và triển khai này sẽ được lập kế hoạch và kiểm soát bằng cách tiếp cận truyền thống, nhằm đảm bảo tuân thủ các quy trình đã định để giảm thiểu mọi tác động đến các hoạt động hiện tại khi triển khai dự án mới.

Sau khi đợt phát hành đầu tiên hoàn tất, dự án sẽ quay trở lại với phương pháp tiếp cận agile và bắt đầu thực hiện một chuỗi phân kỳ lặp khác để tiếp tục phát triển các câu chuyện người dùng (story) còn lại.

Mặc dù cách tiếp cận "theo từng giai đoạn" này để pha trộn giữa agile và truyền thống là phổ biến nhất, bạn vẫn có thể kết hợp các phương pháp để hỗ trợ các yêu cầu triển khai dự án đặc thù. Ví dụ, tôi từng quản lý một dự án đòi hỏi mức độ tuân thủ và xác thực cực kỳ cao khi triển khai một sản phẩm mới vào một ngành bị kiểm soát rất nghiêm ngặt. Do đó, phần lớn dự án của tôi đã được lập kế hoạch và kiểm soát bằng các phương pháp truyền thống.

Tuy nhiên, dự án có một phần về trí thức doanh nghiệp (BI), trong đó công ty chúng tôi khai thác lượng lớn dữ liệu hiệu suất mà hệ thống tạo ra; phần việc này lại được hỗ trợ tốt nhất bằng phương pháp tiếp cận agile. Đối với cấu phần BI của dự án (chạy song song với các phần việc truyền thống), chúng tôi sẽ chọn ra các story có mức độ ưu tiên cao nhất—những việc có thể hoàn thành trong một phân kỳ (sprint) ba tuần—và hoàn thành một phân kỳ lặp.

Vì nhiều story trong số này mang tính chất khám phá thử nghiệm, chúng tôi thường tạo ra các story mới để tiếp tục khám phá sâu hơn hoặc để tạo ra các báo cáo hiệu suất cụ thể. Những story này chỉ đơn giản được thêm vào danh sách công việc tồn đọng (backlog) để xem xét cho sprint tiếp theo.

Với cách tiếp cận này, tôi có một lịch trình dự án duy nhất giúp đảm bảo đạt được tất cả các bước báo cáo và quy định cần thiết, trong khi vẫn cho phép một phương pháp cực kỳ linh hoạt để phát triển cấu phần báo cáo kinh doanh không bị kiểm soát của dự án.

Việc gom toàn bộ công việc vào một lịch duy nhất mang đến một góc nhìn thống nhất về mọi việc đang diễn ra trong dự án này:

Thông tin tôi cần để quản lý việc phân bổ nguồn lực vào các nhiệm vụ phù hợp nhất (truyền thống hoặc agile) luôn có sẵn ngay lập tức

Khả năng tạo ra các báo cáo trạng thái hàng tuần và hàng tháng mạnh mẽ luôn nằm trong tầm tay

Agile là một phương pháp tiếp cận triển khai dự án cực kỳ mạnh mẽ, hứa hẹn mang lại những lợi ích đáng kể cho bộ công cụ triển khai dự án tổng thể của tổ chức bạn. Bạn có thể dùng Agile như một giải pháp độc lập, như một phần của phương pháp triển khai theo giai đoạn, hoặc tích hợp vào một cấu trúc triển khai kết hợp.

Điều quan trọng là áp dụng các nguyên tắc agile sẽ giúp tổ chức bạn đạt được thành công trong triển khai, đồng thời vẫn tuân thủ các quy trình truyền thống đã giúp tổ chức bạn thành công cho đến nay.

Steve Caseley có hơn 35 năm kinh nghiệm với Microsoft Project và là người dùng tích cực của Microsoft Project ngay từ khi sản phẩm được phát hành lần đầu. Ông là biên tập viên của nhiều cuốn sách liên quan đến Microsoft Project và các phương pháp hay nhất trong quản lý dự án. Ông là Tư vấn viên trưởng tại Sensei Project Solutions, nơi ông giúp các tổ chức lớn đạt được hiệu quả xuất sắc trong việc triển khai dự án bằng cách sử dụng bộ công cụ Quản lý danh mục dự án Microsoft (PPM).

SẢN PHẨM LIÊN QUAN
Office 365

Bắt đầu với Microsoft 365

Vẫn là Office quen thuộc, cùng với các công cụ giúp bạn cộng tác tốt hơn, để bạn có thể hoàn thành nhiều việc hơn – mọi lúc, mọi nơi.

Mua ngay

Nội dung liên quan

Quản lý doanh nghiệp của tôi

Tại sao các nhà quản lý cấp cao lại ghét các quản lý dự án?

Đọc thêm

Các thông tin chuyên sâu về doanh nghiệp và ý tưởng kinh doanh không cấu thành tư vấn chuyên môn về thuế hay tài chính. Bạn nên liên hệ với chuyên gia thuế hay tài chính của riêng mình để thảo luận về trường hợp của bạn.