Quản lý backlog của đội IT: Phân loại, ưu tiên và xử lý công việc tồn đọng.

Backlog là những lựa chọn chưa được giải quyết

Một đội IT có thể đóng nhiều ticket mỗi tuần nhưng danh sách tồn đọng vẫn tăng. Khi đó, câu hỏi quản lý không chỉ là “làm sao xử lý nhanh hơn”, mà là việc nào đang được giữ lại, vì sao chưa làm và rủi ro nào doanh nghiệp đang chấp nhận. Backlog thiếu cấu trúc khiến yêu cầu không còn phù hợp vẫn tồn tại, còn việc quan trọng bị che giữa nhiều mục nhỏ.

Đừng đồng nhất backlog với toàn bộ việc đang mở. Cần phân biệt yêu cầu chưa được chọn, công việc đang làm và công việc bị chặn. Ba nhóm cần quyết định khác nhau: chọn hay loại bỏ; hoàn tất trước khi bắt đầu việc mới; hoặc tháo gỡ phụ thuộc. Nếu tất cả đều nằm ở trạng thái “đang xử lý”, giám sát viên khó nhận ra luồng đang tắc ở đâu.

Backlog cũng không phải bằng chứng tự động rằng đội thiếu người. Nguồn yêu cầu, quy tắc ưu tiên, việc lặp, thiếu thông tin và phê duyệt chậm đều có thể tạo tích tụ. Muốn quyết định tuyển thêm hay cải tiến, cần nhìn được cấu trúc công việc và nguyên nhân chờ trước.

Tạo cửa vào có đủ thông tin để ra quyết định

Yêu cầu mới cần mục tiêu, người yêu cầu, dịch vụ bị ảnh hưởng, hạn nghiệp vụ, bằng chứng cần thiết và điều kiện nghiệm thu. Chưa đủ thông tin thì chưa thể ước lượng hay cam kết hợp lý. Tuy nhiên, với sự cố có tác động khẩn, ưu tiên khôi phục trước và bổ sung hồ sơ khi có thể; không để thiếu một trường biểu mẫu chặn phản ứng cần thiết.

Đặt quy tắc xử lý mục trùng hoặc chưa có chủ sở hữu. Hai ticket về cùng một vấn đề nên được liên kết để giữ thông tin người dùng, không đóng tùy tiện chỉ để giảm số lượng. Công việc ngoài phạm vi IT cần được chuyển đúng đầu mối và có thông báo, thay vì để nằm vô thời hạn trong hàng đợi.

Tư duy quản lý dịch vụ IT theo ITSM giúp phân biệt những loại công việc này. Không nên áp dụng cùng một thời hạn hoặc một quy tắc đóng cho sự cố, yêu cầu dịch vụ và sáng kiến cải tiến.

Ưu tiên theo tác động, tính khẩn và rủi ro trì hoãn

Việc cũ nhất chưa chắc quan trọng nhất; người gửi nhiều tin nhắn nhất cũng chưa chắc có yêu cầu ưu tiên cao. Dùng tiêu chí nhìn thấy được: mức ảnh hưởng đến dịch vụ, người dùng hoặc quy trình kinh doanh; thời điểm kết quả cần thiết; rủi ro nếu tiếp tục trì hoãn; và phụ thuộc mà công việc có thể giải phóng.

Giám sát viên cần phân biệt hạn thực sự của nghiệp vụ với ngày mong muốn. Nếu bên yêu cầu cần trước một cuộc kiểm tra hoặc kỳ chốt số liệu, hậu quả trễ phải được ghi rõ. Với hạn chưa có cơ sở, cần thương lượng theo tải và năng lực đội. Việc đánh dấu mọi yêu cầu là “khẩn” chỉ đẩy quyết định ưu tiên sang nhân viên trong lúc thực hiện.

Có thể dùng bảng đánh giá ngắn thay vì điểm số phức tạp. Nếu cần chấm điểm, trọng số phải được thống nhất với chủ dịch vụ và được rà lại khi bối cảnh đổi. Không để công thức che khuất các nghĩa vụ bảo mật, tuân thủ hoặc rủi ro không thể đánh đổi bằng điểm trung bình.

Giới hạn việc đang làm để tăng khả năng hoàn tất

Khi mỗi người mở nhiều việc cùng lúc, chuyển đổi ngữ cảnh tăng và công việc gần xong vẫn bị dừng bởi yêu cầu mới. Giới hạn công việc đang làm, thường gọi là WIP limit, tạo cơ hội tập trung vào hoàn tất và phát hiện điểm tắc. Atlassian mô tả giới hạn này như một công cụ quản lý luồng Kanban; đội IT có thể thử trên một loại công việc phù hợp.

Không chọn một con số theo cảm tính rồi coi đó là quy định bất biến. Hãy bắt đầu từ năng lực, mức gián đoạn và loại việc; thử trong một thời gian đủ để quan sát; xem có mục nào bị chờ do giới hạn hoặc vì thiếu người có kỹ năng. Công việc khẩn có thể cần luồng riêng, nhưng mỗi ngoại lệ phải được nhìn thấy cùng tác động tới cam kết khác.

Khi một cột đầy, đội nên hỗ trợ hoàn tất hoặc tháo gỡ trước khi kéo thêm yêu cầu. “Đang chờ” vẫn cần được quan sát; chuyển việc sang cột chờ chỉ để làm đẹp WIP không tạo thêm năng lực. Ghi rõ phụ thuộc và tuổi chờ để giới hạn không bị vô hiệu hóa bởi đổi nhãn.

Dọn backlog bằng quyết định, không bằng xóa hồ sơ

Định kỳ rà mục đã lâu chưa thay đổi: nhu cầu còn tồn tại không, người yêu cầu có xác nhận không, dịch vụ đã đổi hay vấn đề đã được giải quyết bằng cách khác? Nếu không còn cần, đóng theo quy trình với lý do và thông báo. Không xóa dấu vết để tạo cảm giác tiến độ tốt; lịch sử có thể cần cho truy vết và học hỏi.

Với mục chưa đủ thông tin, đặt thời điểm yêu cầu bổ sung và phương án nếu không nhận được. Với mục có giá trị nhưng chưa thể làm, ghi lý do hoãn và điều kiện xem xét lại. Điều này cho người yêu cầu khả năng hiểu lựa chọn, đồng thời bảo vệ đội khỏi những cam kết không có nguồn lực.

Những công việc lặp nhiều cần đưa sang quản lý nguyên nhân và cải tiến. Nếu liên tục cấp lại quyền do quy trình nhân sự thiếu tích hợp, xử lý nhanh từng ticket không giải quyết gốc. Năng lực quản lý bộ phận IT giúp kết nối quyết định về backlog với năng lực, quy trình và ưu tiên kinh doanh.

Tình huống minh họa: số lượng giảm nhưng rủi ro tăng

Tình huống giả định: nhóm chọn đóng yêu cầu ngắn để giảm danh sách tồn. Một số việc chuẩn hóa quyền truy cập và xử lý lỗi lặp được hoãn vì khó, cần phối hợp nhiều bên. Báo cáo cho thấy số ticket giảm nhưng người dùng tiếp tục gặp cùng sự cố, còn rủi ro quyền không phù hợp chưa được xử lý.

Giám sát viên tách backlog thành các nhóm, xem tác động và tuổi việc theo từng nhóm. Các mục xử lý nguyên nhân, kiểm soát truy cập và việc gần hạn được đưa ra quyết định rõ, thay vì cạnh tranh bằng số ticket đóng. Nhóm giữ một phần năng lực cho cải tiến theo thỏa thuận, ghi những việc bị hoãn khi sự cố khẩn xuất hiện.

Sau thử nghiệm, đánh giá lỗi lặp, thời gian chờ và rủi ro tồn đọng bên cạnh sản lượng. Nếu không có đủ dữ liệu, báo cáo mức chưa chắc chắn thay vì tuyên bố hiệu quả tăng. Bài học là chỉ số ít tồn hơn cần đi cùng bằng chứng về chất lượng dịch vụ và mức rủi ro còn lại.

Một buổi rà soát backlog nên tạo ra những quyết định gì?

Chuẩn bị danh sách ngắn gồm việc tác động cao, mục có tuổi lớn, đầu việc bị chặn và yêu cầu chưa đủ thông tin. Mời đúng người có quyền đổi ưu tiên hoặc xử lý phụ thuộc; cuộc họp có nhiều người nhưng không ai quyết định sẽ chỉ chuyển backlog sang một bản biên bản mới.

Với từng mục, chọn một hướng rõ: đưa vào thực hiện; giữ lại và đặt điều kiện xem xét; trả yêu cầu bổ sung; chuyển phạm vi; hoặc đóng có lý do. Ghi người chịu trách nhiệm và ngày rà tiếp theo. Những mục được đưa vào làm cần phù hợp năng lực hiện tại; chọn quá nhiều việc nhưng không có thời gian thực hiện sẽ làm cuộc rà soát mất ý nghĩa.

Sau buổi họp, thông báo những thay đổi cam kết cho người yêu cầu. Nếu quyết định có đánh đổi rủi ro, chuyển tới chủ sở hữu phù hợp để xác nhận thay vì chỉ ghi nhận trong nhóm kỹ thuật.

Đo luồng và dùng dữ liệu để chọn hành động

Quan sát công việc mới vào, số hoàn tất, tuổi backlog, thời gian từ nhận đến xong và số việc đang làm. Với mỗi thước đo, giữ định nghĩa phạm vi và trạng thái nhất quán. Tránh so sánh nhân viên bằng ticket nếu độ khó khác nhau; dùng dữ liệu để nhìn xu hướng luồng và nhóm công việc tắc nghẽn.

Nếu lượng vào liên tục cao hơn khả năng hoàn tất, cần quyết định giảm nhu cầu, cải tiến, đổi cam kết hoặc tăng năng lực. Nếu thời gian chờ phê duyệt chiếm phần lớn, vấn đề cần xử lý ở trách nhiệm và phản hồi liên nhóm. Nếu lỗi lặp nhiều, dành nguồn lực cho nguyên nhân có thể hữu ích hơn thêm người xử lý từng yêu cầu.

Chương trình Quản Lý Giám Sát IT hỗ trợ kỹ năng phân công và theo dõi để biến dữ liệu backlog thành quyết định thực thi. Hãy bắt đầu bằng một buổi rà soát hàng tuần với những mục tác động cao, già nhất và bị chặn; kết thúc bằng lựa chọn, người chịu trách nhiệm và ngày xem lại.

Bài viết liên quan

• Giám sát tiến độ công việc mà không biến thành quản lý vi mô.
• Bàn giao ca trực IT không bỏ sót: Kiểm soát sự cố và công việc tồn đọng
• Nhân viên báo cáo “chưa xong”: Giám sát viên cần hướng dẫn cách trình bày vấn đề thế nào?
• Xây dựng quy tắc escalation: Khi nào nhân viên phải báo cáo lên cấp quản lý?

Nguồn tham khảo

1. Atlassian – What is Kanban?
2. Atlassian – Working with WIP limits for kanban
3. Atlassian – Four Kanban Metrics