INFOCHIEF ACADEMY · IT SUPERVISOR KNOWLEDGE SERIES

Áp dụng phương pháp 5W-1H-1M để giao việc IT rõ ràng và có thể đo lường.

“Kiểm tra máy chủ trước cuối ngày” nghe có vẻ rõ, nhưng người nhận có thể không biết kiểm tra gì, tiêu chí đạt ra sao và phải báo ai nếu phát hiện bất thường. 5W-1H-1M biến yêu cầu thành thỏa thuận công việc có thể thực hiện và nghiệm thu.

Biên soạn: Infochief Academy · Chuyên đề: Quản Lý Giám Sát IT – IT Supervisor

← Trở về danh mục IT Supervisor

Giám sát viên IT làm rõ nhiệm vụ, phạm vi, thời hạn và tiêu chí đo lường với kỹ thuật viên
Minh họa biên tập: “Kiểm tra máy chủ trước cuối ngày” nghe có vẻ rõ, nhưng người nhận có thể không biết kiểm tra gì, tiêu chí đạt ra sao và phải báo ai nếu phá

Từ yêu cầu ngắn đến brief có thể hành động

Giao việc thường thất bại không phải vì nhân viên thiếu cố gắng, mà vì hai bên hình dung hai kết quả khác nhau. Người giao muốn chắc rằng bản sao lưu có thể khôi phục; người nhận nghĩ chỉ cần thấy lịch chạy thành công. Khác biệt lộ ra khi sự cố xảy ra thì chi phí sửa sai cao hơn nhiều so với vài phút làm rõ.

5W-1H-1M là khung câu hỏi: Who (ai), What (việc gì), Why (vì sao), When (khi nào), Where (phạm vi), How (cách thực hiện) và Measurement (đo kết quả). Đây là công cụ thực hành giảm mơ hồ, không phải tiêu chuẩn bắt buộc. Hãy xuất phát từ kết quả mong muốn rồi mới thống nhất phương pháp.

Bảy câu hỏi làm rõ nhiệm vụ

Thành tốCâu hỏiVí dụ trong IT
WhoAi chịu trách nhiệm, phối hợp, nghiệm thu?Kỹ thuật viên thực hiện; quản trị ứng dụng xác nhận
WhatĐầu ra cụ thể là gì, gồm và không gồm gì?Kiểm tra khôi phục một bộ dữ liệu thử
WhyNhu cầu hoặc rủi ro nào khiến việc cần làm?Xác nhận khả năng phục hồi trước diễn tập
WhenHạn, mốc giữa và khung giờ hạn chế?Trước thứ Năm, không ảnh hưởng giờ giao dịch
WhereHệ thống, môi trường, địa điểm nào?Môi trường thử nghiệm, không phải production
HowQuy trình, quyền hạn và điều kiện dừng?Dùng bản sao dữ liệu; báo nếu xác thực lỗi
MeasurementBằng chứng nào xác nhận đạt, ngưỡng escalaton?Log, thời gian khôi phục, kiểm tra toàn vẹn

Measurement không nhất thiết là KPI phức tạp. Với tác vụ một lần, tiêu chí nghiệm thu, bằng chứng và ngưỡng báo ngoại lệ có thể đủ. Với công việc lặp lại, mới cần xem xu hướng thời gian, lỗi, tải và chất lượng dịch vụ.

Measurement xác định thế nào là hoàn thành

Tiêu chí hoàn tất cần quan sát được, liên quan tới mục tiêu và tương xứng với rủi ro. Có việc dùng tiêu chí nhị phân: tài khoản đã thu hồi trên toàn bộ hệ thống được liệt kê. Việc khác cần ngưỡng: dịch vụ đáp ứng mức đã thống nhất, hồ sơ thay đổi đủ bằng chứng và người dùng xác nhận chức năng.

Tránh chỉ đo sản lượng như số ticket đóng nếu chưa xem chất lượng và độ bền. Chỉ số có thể bị tối ưu sai khi nhân viên chạy theo số lượng hoặc chuyển ticket sớm. Kết hợp thước đo kết quả với kiểm tra chất lượng/phản hồi.

  1. Đầu ra: cấu hình, báo cáo, thay đổi hoặc hồ sơ đã tạo.
  2. Chất lượng: kiểm thử, rà soát, bảo mật hoặc phê duyệt.
  3. Tác động sử dụng: dịch vụ khôi phục, người dùng được hỗ trợ, quy trình tiếp tục.

Năng lực quản lý ITSM giúp gắn việc thực hiện với trải nghiệm người dùng và kết quả dịch vụ.

Mẫu giao việc kiểm tra bản sao lưu

Tình huống minh họa: trưởng nhóm cần xác minh quy trình khôi phục trước diễn tập. Brief một trang có thể gồm:

  • Who: kỹ thuật viên lưu trữ thực hiện; quản trị ứng dụng xác nhận; giám sát duyệt phạm vi.
  • What: khôi phục thử một bản sao vào môi trường kiểm thử cô lập.
  • Why: kiểm chứng bản sao có thể sử dụng, không chỉ job báo thành công.
  • When: trước 16 giờ thứ Tư; báo sớm nếu nguy cơ trễ.
  • Where: môi trường được chỉ định; không đưa dữ liệu nhạy cảm ra thiết bị cá nhân.
  • How: theo quy trình hiện hành, lưu log, dừng nếu xác thực hoặc toàn vẹn không đạt.
  • Measurement: có bằng chứng khôi phục, thời gian ghi nhận và chủ ứng dụng xác nhận dữ liệu mở được.

Nếu kiểm tra thất bại, đầu ra vẫn có giá trị khi nguyên nhân và bước khắc phục được ghi rõ.

Điều chỉnh brief theo rủi ro và năng lực

Không biến khung thành biểu mẫu dài cho mọi yêu cầu. Tác vụ nhỏ có thể trao đổi và ghi kết quả; thay đổi ảnh hưởng rộng cần nêu phạm vi, phụ thuộc, phê duyệt, khôi phục và truyền thông. Độ chi tiết tăng theo rủi ro và tính mới. Người quen việc có thể tự đề xuất cách làm; nhân viên mới cần điểm rà soát sớm. Mời người nhận nhắc lại cách hiểu để kiểm tra chất lượng brief, không phải kiểm tra trí nhớ.

Với công việc dự án liên phòng ban, xác định trách nhiệm, mốc và phụ thuộc để tránh tình trạng mỗi bên tưởng bên kia đang làm. Chương trình quản lý dự án IT bổ trợ kỹ năng lập kế hoạch và theo dõi cam kết.

Lỗi khiến khung này thành thủ tục

  • Điền đủ mục nhưng mục tiêu không rõ.
  • Ghi “theo quy trình” mà không nêu phiên bản hoặc nơi truy cập.
  • Đặt hạn không tính thời gian phê duyệt và phụ thuộc.
  • Đo cái dễ đếm thay vì chất lượng hoặc tác động.
  • Giao trách nhiệm nhưng thiếu quyền, dữ liệu, công cụ.
  • Không cập nhật brief khi phạm vi thay đổi.

Hành động: chọn đầu việc hay bị trả lại, viết lại bằng bảy câu hỏi và hỏi người thực hiện xem tiêu chí hoàn tất có kiểm chứng được chưa.

Biến brief thành thỏa thuận hai chiều

Brief không nên chỉ là mệnh lệnh một chiều. Sau khi mô tả công việc, hãy hỏi người nhận: điều gì đang chưa rõ, giả định nào có thể sai, phụ thuộc nào cần xác nhận và nguồn lực nào còn thiếu? Người thực hiện thường thấy sớm hơn người giao việc các vấn đề như thiếu quyền, thiết bị không sẵn sàng hoặc thời gian bảo trì xung đột. Phát hiện trước khi bắt đầu giúp bảo vệ hạn và chất lượng.

Ghi lại thay đổi phạm vi có tác động tới thời gian, tiêu chí hoặc người phối hợp. Nếu yêu cầu mới chen vào, thống nhất việc nào bị lùi thay vì âm thầm cộng thêm. Đây là điểm quan trọng trong nhóm IT nơi sự cố khẩn cấp và yêu cầu lãnh đạo có thể làm đảo thứ tự công việc nhiều lần trong ngày.

Đánh giá chất lượng giao việc bằng dữ liệu

Sau vài tuần, xem tỷ lệ đầu việc phải hỏi lại vì thiếu thông tin, tỷ lệ hoàn tất đúng hẹn, số lần thay đổi phạm vi, số lỗi phát hiện ở nghiệm thu và thời gian chờ phản hồi. Không dùng các chỉ số này để đổ lỗi cho người giao hay người nhận; mục đích là tìm mẫu lặp. Nếu hạn trễ tập trung ở việc chờ một nhóm khác, cần làm rõ trách nhiệm liên phòng ban. Nếu làm lại do tiêu chí mơ hồ, sửa câu hỏi What và Measurement.

Chọn vài loại công việc lặp lại để tạo mẫu brief ngắn, nhưng luôn cho phép điều chỉnh theo rủi ro và bối cảnh. Mẫu tốt làm giảm thao tác nhập liệu, không buộc nhân viên điền những mục không liên quan. Mỗi trường nên có ví dụ chất lượng, người chịu trách nhiệm cập nhật và nơi lưu bản chuẩn.

Khi đánh giá kết quả, phân biệt phần nhân viên kiểm soát được với kết quả phụ thuộc bên ngoài. Nếu nhiệm vụ phụ thuộc phê duyệt nhà cung cấp, hãy đo thời gian phản hồi và chất lượng hồ sơ gửi đi, không đánh đồng độ trễ bên thứ ba với hiệu suất cá nhân. Tính công bằng này giúp nhân viên báo rủi ro sớm thay vì che giấu để bảo vệ chỉ tiêu.

Rà soát brief trước khi giao việc quan trọng

Với thay đổi ảnh hưởng hệ thống quan trọng, dành vài phút rà brief cùng người nhận và bên liên quan. Kiểm tra tính nhất quán giữa lý do, kết quả, hạn và cách đo. Nếu “Why” là giảm rủi ro mất dữ liệu nhưng tiêu chí hoàn tất chỉ là chạy xong tác vụ, thước đo chưa phản ánh mục tiêu. Nếu một người chịu trách nhiệm nhưng thiếu quyền truy cập, phân công chưa khả thi.

Đặt câu hỏi phản biện: điều gì có thể làm giả định này sai? Có hoạt động nào bị ảnh hưởng ngoài phạm vi dự kiến? Nếu công việc không thể hoàn thành đúng hạn, ai cần biết trước và lựa chọn nào có sẵn? Các câu hỏi không nhằm tạo bi quan; chúng giúp chuẩn bị cho ngoại lệ khi chi phí xử lý còn thấp.

Giữ bản brief ngắn và dùng liên kết tới quy trình chi tiết. Khi nhiệm vụ lặp lại, chuyển phần lặp thành mẫu được quản lý phiên bản. Khi nhiệm vụ có tính khám phá, ghi rõ điều chưa biết và thời điểm sẽ quay lại quyết định phạm vi. Như vậy, công cụ vẫn hữu ích cho cả công việc chuẩn hóa lẫn điều tra sự cố.

Nguồn tham khảo

  1. Atlassian Team Playbook – Project kickoff meeting
  2. Atlassian Team Playbook – Problem framing
  3. CIPD – Effective performance management

Nguồn tham khảo hỗ trợ nguyên tắc quản lý hiệu suất, vận hành dịch vụ và phương pháp thực hành. Nội dung bài viết là diễn giải của Infochief Academy; tình huống minh họa được ghi rõ là giả định.