INFOCHIEF ACADEMY · IT PROJECT MANAGEMENT KNOWLEDGE SERIES
Áp dụng Agile, Scrum và Hybrid vào quản lý dự án IT trong doanh nghiệp.
Áp dụng Agile, Scrum và Hybrid cần thay cách lấy phản hồi và ra quyết định. Thiết kế quyền ưu tiên, nhịp kiểm chứng và điểm nối giữa các phần việc giúp đội thích ứng trong cam kết doanh nghiệp.
Biên soạn: Infochief Academy · Chuyên đề: Quản lý dự án IT
Trong một tình huống giả định, doanh nghiệp chuyển sang làm việc theo Sprint nhưng vẫn giao đội phát triển một danh sách cố định cho từng tháng. Người dùng chỉ xem sản phẩm khi gần triển khai, còn thay đổi phải chờ một cuộc họp cấp cao. Các buổi Daily Scrum diễn ra đều, nhưng cơ hội học hỏi và điều chỉnh vẫn nhỏ. Tổ chức đã thay tên nhịp làm việc mà chưa thay cách ra quyết định.
Agile hướng đến khả năng thích ứng thông qua phản hồi và kết quả có thể kiểm tra. Scrum là một framework cụ thể để tổ chức công việc phức tạp theo hướng đó. Hybrid là cách kết hợp những phương thức quản lý phù hợp với các phần việc khác nhau. Muốn áp dụng trong doanh nghiệp, cần thiết kế nơi lấy phản hồi, nơi chốt ưu tiên và cách giữ cam kết, thay vì chỉ bổ sung nghi thức.
Chọn phần việc cần học hỏi và phần cần ổn định
Không phải mọi phần của dự án có cùng mức bất định. Một quy trình khách hàng mới có thể cần kiểm chứng qua nhiều phiên bản, trong khi thay thiết bị hạ tầng theo thiết kế đã xác nhận có trình tự tương đối rõ. Đội dự án nên xem nhu cầu, giải pháp và điều kiện triển khai nào còn phải học. Từ đó chọn nhịp kiểm tra phù hợp cho từng phần.
Một dự án không cần mang một nhãn duy nhất để được điều hành nhất quán. Có thể lập kế hoạch những phụ thuộc lớn và cửa sổ chuyển đổi, đồng thời phát triển chức năng theo vòng lặp. Điều kiện là kết quả ở hai nhịp phải nối được với nhau. Nếu phần phát triển linh hoạt nhưng đầu vào nghiệp vụ chỉ được chốt một lần ở đầu, phản hồi sẽ không đi đến quyết định.
Nên làm rõ mục tiêu đầu tư, giới hạn nguồn lực và điều kiện chất lượng trước khi trao quyền thích ứng. Linh hoạt không đồng nghĩa với tiếp nhận vô hạn mọi yêu cầu. Người có quyền ưu tiên cần biết thay đổi nào có thể xử lý trong phạm vi được giao và thay đổi nào làm mất cơ sở cam kết. Những ràng buộc thực sự bắt buộc phải được phân biệt với thói quen quản lý có thể điều chỉnh.
Năng lực quản lý dự án IT giúp tổ chức bức tranh chung này. Khi đã chọn phần cần thích ứng, doanh nghiệp phải bảo đảm có người đủ quyền và đủ thời gian để dùng phản hồi vào lựa chọn sản phẩm.
Đặt quyền ưu tiên và trách nhiệm đội đúng nơi
Theo Scrum Guide, Product Owner chịu trách nhiệm tối đa hóa giá trị và quản lý Product Backlog; Developers tổ chức cách tạo Increment; Scrum Master hỗ trợ hiệu quả và việc áp dụng Scrum. Doanh nghiệp cần làm rõ những trách nhiệm này bằng người thực sự đảm nhiệm, không chỉ gắn thêm chức danh cho người đang quá tải. Một người được gọi là Product Owner nhưng không thể chốt ưu tiên sẽ tạo ra điểm chờ.
Trong dự án có nhiều đơn vị nghiệp vụ, cần cơ chế tổng hợp nhu cầu nhưng vẫn phải có đầu mối ưu tiên rõ. Các bên có thể cung cấp ý kiến và điều kiện, còn quyền chốt phải được thống nhất. Nếu mọi bộ phận trực tiếp giao việc vào nhóm, backlog có thể phản ánh mức độ gây sức ép hơn là giá trị. Người quản lý dự án cần hỗ trợ giải quyết xung đột vượt giới hạn của đầu mối sản phẩm.
Project Manager không phải một trách nhiệm được Scrum Guide định nghĩa. Khi doanh nghiệp có vai trò này trong dự án dùng Scrum, nên xác định phần việc bổ sung như ngân sách tổng, hợp đồng, phụ thuộc bên ngoài và chuyển đổi vận hành. Không nên biến người quản lý thành người giao từng nhiệm vụ hằng ngày cho Developers rồi vẫn kỳ vọng đội tự quản.
Việc phân quyền và xử lý sự đánh đổi gắn với chương trình Giám Đốc Dự Án IT. Cần giữ một đường phối hợp giữa quyền ưu tiên sản phẩm và quyền chấp nhận thay đổi mục tiêu đầu tư. Khi hai quyền này rõ, đội mới có thể lập nhịp thực hiện mà không phải xin lại mọi quyết định nhỏ.
Biến phản hồi thành dữ liệu cho vòng làm việc sau
Vòng lặp cần tạo ra phần sản phẩm đủ để kiểm tra, không chỉ một báo cáo về việc đang làm. Có thể chọn một luồng nghiệp vụ hẹp nhưng đi qua những thành phần quan trọng, thay vì hoàn thành nhiều lớp kỹ thuật mà người dùng chưa thể xem kết quả. Cách chia theo giá trị giúp phát hiện hiểu sai sớm và tạo cơ sở để điều chỉnh thứ tự.
Sprint Review là cơ hội xem kết quả và thích ứng, không nên bị dùng như một buổi trình diễn không có quyền thay đổi. Đội cần mời người có thông tin về cách sử dụng và những người có thể chốt lựa chọn liên quan. Những phản hồi quan trọng phải được ghi về backlog hoặc cơ chế quyết định phù hợp. Nếu chỉ thu nhận ý kiến rồi vẫn giữ nguyên danh sách bằng mọi giá, việc xem xét chưa tạo ra học hỏi thực tế.
Definition of Done giữ chuẩn chất lượng chung cho Increment. Các tiêu chí riêng của một yêu cầu cần được làm rõ theo sản phẩm, nhưng không thay thế chuẩn chung. Phần chưa đạt không nên được báo như đã hoàn thành chỉ để giữ số lượng công việc. Ngoài kết quả kỹ thuật, dự án có thể còn các điều kiện phát hành, hợp đồng hoặc vận hành riêng phải được quản lý minh bạch.
Các hoạt động cải tiến nên chọn vấn đề có thể tác động, giao người thực hiện và kiểm tra kết quả. Ví dụ giả định, nếu môi trường thường chậm, đội có thể chuẩn hóa bước yêu cầu và chuẩn bị trước thay vì chỉ ghi lại vướng mắc mỗi vòng. Nhịp ngắn có giá trị khi làm cho biện pháp cải tiến cũng được kiểm chứng ngắn.
Thiết kế Hybrid quanh điểm nối giữa các phần việc
Hybrid không nên là hai hệ thống báo cáo cùng quản lý một công việc. Đội cần biết phần nào phát triển theo vòng lặp, phần nào theo chuỗi đã xác nhận và cách chúng bàn giao cho nhau. Các phụ thuộc lớn, mốc quyết định và nghĩa vụ hợp đồng vẫn cần lịch chung. Chi tiết chức năng có thể được làm rõ dần trong những giới hạn đã thống nhất.
Bảng dưới đây là một thiết kế tham khảo cho dự án giả định thay cổng dịch vụ. Nó không phải một quy trình Hybrid chuẩn áp dụng cho mọi doanh nghiệp.
| Phần công việc | Cách tổ chức đề xuất | Điểm nối cần kiểm soát |
|---|---|---|
| Khảo sát luồng người dùng | Thử nguyên mẫu và lấy phản hồi | Chủ quy trình chốt vấn đề ưu tiên |
| Phát triển chức năng | Vòng lặp có sản phẩm kiểm chứng | Phiên bản, chất lượng và backlog |
| Chuẩn bị hạ tầng | Kế hoạch theo phụ thuộc đã xác nhận | Môi trường sẵn sàng trước kiểm tra |
| Chuyển dữ liệu, Go-live | Diễn tập và kế hoạch chuyển đổi | Dữ liệu, quyền quyết định và phục hồi |
Trong thiết kế này, nhóm phát triển cần biết ngày có môi trường và dữ liệu để kiểm tra kết quả. Nhóm chuyển đổi cần biết phiên bản nào sẽ được sử dụng và thay đổi nào còn có thể xuất hiện. Nếu điểm nối không được xác nhận, mỗi nhóm có thể đạt kế hoạch riêng trong khi dự án tổng vẫn thiếu khả năng triển khai.
Sự tham gia của Quản Lý Dịch Vụ IT – ITSM giúp đưa điều kiện tiếp nhận vào từ sớm. Một vòng phát triển tạo sản phẩm có thể sử dụng chưa mặc nhiên đáp ứng mọi điều kiện chạy trong môi trường doanh nghiệp. Cần giữ các điều kiện ấy nhìn thấy được mà không dồn toàn bộ phản hồi đến cuối dự án.
Dự báo bằng kết quả đã đạt và điều kiện còn lại
Đội cần phân biệt mục tiêu với dự báo. Mục tiêu tạo hướng đi, còn dự báo dựa vào phần đã hoàn thành, công việc còn lại và năng lực thực tế. Có thể dùng dữ liệu thông lượng hoặc lịch sử của đội khi phù hợp, nhưng cần giữ giả định về quy mô và mức ổn định. Không nên lấy vài vòng đầu rồi xem tốc độ ấy là cam kết chắc chắn cho toàn bộ dự án.
Story point nếu được sử dụng là thước đo tương đối trong bối cảnh đội, không phải đơn vị giờ chuẩn để so sánh hiệu suất giữa các nhóm. Một biến động về cách chia yêu cầu hoặc quy tắc ghi nhận có thể làm biểu đồ đổi mà năng lực thật chưa đổi. Người quản lý nên nhìn sản phẩm, thời gian hoàn tất và những việc bị chờ, thay vì thúc đội tăng một con số.
Lịch nguồn lực phải phản ánh khả năng thực tế. Một đội chỉ có mặt theo phần thời gian cần dự báo khác với đội ổn định. Khi người bị điều chuyển liên tục, dữ liệu cũ có thể không còn phù hợp. Sự phối hợp với Trưởng Phòng IT – IT Manager giúp bảo vệ năng lực cần để nhịp làm việc tạo ra kết quả có thể dự báo.
Báo cáo cấp dự án nên tổng hợp tiến triển về mục tiêu, phần còn chưa rõ, phụ thuộc và quyết định cần chốt. Không cần dịch mọi chi tiết backlog thành một lịch giả chính xác. Điều cần cho lãnh đạo là mức tin cậy của hướng đi và phần can thiệp có thể làm tăng khả năng hoàn thành.
Thử trên một phần có phản hồi thật rồi mở rộng
Có thể chọn một luồng công việc đủ nhỏ để kiểm tra cách ưu tiên, thực hiện và nhận phản hồi. Trước khi bắt đầu, xác định ai xem sản phẩm, ai chốt lựa chọn và điều kiện hoàn thành. Sau vài vòng, đánh giá xem đội có phát hiện hiểu sai sớm hơn, giảm thời gian chờ và tạo kết quả được sử dụng hay chưa. Số buổi họp đã tổ chức không phải thước đo đủ.
Nếu thử nghiệm chưa hiệu quả, cần xem nguyên nhân thuộc cấu trúc công việc, quyền quyết định hay điều kiện đội. Một nhóm thiếu kỹ năng tích hợp không được giải quyết chỉ bằng đổi nhịp họp. Một người dùng không tham gia xem sản phẩm khiến vòng phản hồi thiếu đầu vào. Cải thiện nên dựa trên những điểm cụ thể này trước khi mở rộng phương thức cho toàn tổ chức.
Với đội ở mở bài, thay đổi đầu tiên nên là cho người có quyền ưu tiên xem một phần sản phẩm có ý nghĩa và chốt việc điều chỉnh trong giới hạn rõ. Sau đó tổ chức kế hoạch chung để bảo vệ các phụ thuộc bên ngoài. Agile, Scrum và Hybrid tạo giá trị khi cách học và cách quyết định phù hợp với công việc, đồng thời trách nhiệm đối với cam kết doanh nghiệp vẫn được giữ rõ.