Bảo trì phần mềm gồm những gì?
Sửa lỗi sau phát hành, cập nhật thư viện và thêm một loại dịch vụ mới là ba công việc khác nhau. Nếu chỉ thỏa thuận “có bảo trì”, doanh nghiệp vẫn có thể chưa biết việc nào được bao gồm và ai sẽ xử lý.
Ví dụ giả định: hệ thống đặt lịch gặp lỗi hiển thị, dịch vụ gửi thư đổi cách xác thực, trong khi bộ phận kinh doanh muốn thêm quy tắc đặt lịch. Cả ba cần được phân loại và đánh giá, thay vì chuyển chung vào một danh sách sửa lỗi.
Để biết cần liên hệ ai và chuẩn bị nguồn lực nào cho từng trường hợp, doanh nghiệp cần đối chiếu phạm vi hỗ trợ với hệ thống đang sử dụng và thỏa thuận cụ thể. Những nhóm công việc dưới đây giúp doanh nghiệp xác định rõ nhu cầu khi lập kế hoạch bảo trì.
1. Phân biệt các công việc sau phát hành
Sửa vấn đề không đúng với yêu cầu đã thống nhất
Ví dụ, một lịch bị hiển thị sai múi giờ dù yêu cầu đã xác định rõ. Đội phụ trách cần kiểm tra nguyên nhân, xác định cách sửa và kiểm tra lại phần liên quan.
Cần đối chiếu với phiên bản, dữ liệu và điều kiện xảy ra lỗi. Không phải mọi phản ánh đều do mã phần mềm; có thể liên quan cấu hình, dữ liệu đầu vào hoặc dịch vụ bên ngoài.
Điều chỉnh theo thay đổi của môi trường
Thư viện, trình duyệt, hệ điều hành hoặc dịch vụ tích hợp có thể thay đổi theo thời gian. Hệ thống cần được đánh giá để biết thay đổi nào ảnh hưởng và khi nào phải xử lý.
Theo hướng dẫn NIST SP 800-40, quản lý bản vá bao gồm nhận diện, ưu tiên, cài đặt và kiểm tra bản cập nhật. Khi áp dụng cho hệ thống cụ thể, cần đánh giá rủi ro và tính tương thích, đồng thời có bước kiểm tra phù hợp trước khi đưa thay đổi vào sử dụng.
Cải thiện khả năng sử dụng và vận hành
Có thể phát sinh nhu cầu làm rõ thông báo, tối ưu truy vấn hoặc cải thiện khả năng theo dõi. Đây không nhất thiết là sửa lỗi, cũng chưa chắc là một chức năng mới lớn.
Điều quan trọng là mô tả kết quả cần đạt và đánh giá ảnh hưởng. Một thay đổi ngắn trên giao diện vẫn có thể liên quan nhiều vai trò hoặc dữ liệu.
Phát triển thêm để đáp ứng nhu cầu mới
Khi đơn vị mở thêm loại dịch vụ và muốn đổi quy tắc đặt lịch, đây có thể là phần phát triển bổ sung. Cần phân tích, ước tính và xác nhận phạm vi theo quy trình đã thống nhất.
Không nên mặc định mọi nhu cầu sau phát hành đều có trong gói bảo trì. Ngược lại, cũng không nên tự coi mọi yêu cầu người dùng là phát sinh trước khi kiểm tra căn cứ.
2. Ranh giới giữa bảo hành, bảo trì và phát triển thêm
Các thuật ngữ này có thể được dùng khác nhau giữa các hợp đồng. Doanh nghiệp cần đọc điều kiện cụ thể thay vì dựa vào tên gọi.
Bảo hành thường được mô tả gắn với việc xử lý những sai khác thuộc phạm vi và thời hạn xác định. Bảo trì có thể bao gồm hoạt động định kỳ hoặc hỗ trợ trong quá trình sử dụng. Phát triển thêm hướng đến yêu cầu mới hoặc thay đổi đã được chấp thuận.
Ví dụ, lỗi đặt lịch trong điều kiện đã được quy định có thể thuộc phạm vi xử lý đã cam kết. Yêu cầu đặt lịch cho một loại hình dịch vụ chưa từng có cần được đánh giá riêng.
Cần ghi rõ thời điểm bắt đầu hỗ trợ, thời hạn, điều kiện áp dụng và phần loại trừ. Khi đánh giá chi phí dự án, nên xem các mục này cùng chi phí triển khai và vận hành.
5 sai lầm khiến chi phí phát triển phần mềm vượt dự kiến
Đọc báo giá phần mềm: Cần hỏi rõ những gì?
3. Khi có sự cố, điều gì cần xảy ra?
Giả sử khách không thể hoàn tất đặt lịch. Người tiếp nhận cần biết kênh báo lỗi, dữ liệu cần cung cấp và ai đang chịu trách nhiệm điều phối.
Thông tin ban đầu có thể gồm thời điểm, phạm vi ảnh hưởng, thông báo lỗi và một mã tham chiếu đã được xử lý phù hợp để tránh lộ dữ liệu. Không nên yêu cầu nhân viên gửi mật khẩu hoặc toàn bộ dữ liệu khách hàng trong tin nhắn.
Mức độ ưu tiên nên gắn với ảnh hưởng thực tế. Một lỗi chặn toàn bộ đặt lịch khác với lỗi căn lề trên màn hình ít dùng. Tuy nhiên, cách phân mức và thời gian mục tiêu cần được thống nhất, không tự đặt khi sự cố đã xảy ra.
Cũng cần phân biệt phản hồi, khắc phục tạm và giải quyết nguyên nhân. Việc nhà cung cấp xác nhận đã nhận thông tin chưa đồng nghĩa hệ thống đã được phục hồi.
Trong khi xử lý, người phụ trách nghiệp vụ cần hướng dẫn cách tiếp tục công việc nếu có phương án thay thế. Sau phục hồi, kiểm tra dữ liệu đã phát sinh, giao dịch chờ hoặc thao tác nhập tay để tránh thiếu và trùng.
4. Những nội dung cần thống nhất trong kế hoạch hỗ trợ
Trước hết là phạm vi tài sản được hỗ trợ: phần mềm, môi trường, kết nối và những dịch vụ bên thứ ba nào. Với dịch vụ bên ngoài, cần biết ai là chủ tài khoản và ai có quyền yêu cầu hỗ trợ.
Tiếp theo là giờ hỗ trợ, kênh liên lạc và đầu mối. Không nên hiểu “hỗ trợ hệ thống hoạt động liên tục” thành “mọi yêu cầu đều được xử lý ngay ở mọi thời điểm” nếu chưa có cam kết tương ứng.
Nhóm nội dung thứ ba là quản lý thay đổi. Cần có cách thử bản cập nhật, phê duyệt thời điểm triển khai và xử lý nếu thay đổi gây ảnh hưởng. Những hệ thống quan trọng có thể cần yêu cầu kiểm tra khác với công cụ nội bộ ít người dùng.
Cũng cần xác định việc theo dõi: chỉ kiểm tra khi người dùng báo hay có giám sát chủ động? Nếu có cảnh báo, ai nhận, nhận trong khung giờ nào và có quy trình phản ứng không?
Cuối cùng là tài liệu và quyền truy cập. Đội hỗ trợ cần được cấp quyền phù hợp, ghi nhận thay đổi và có cách thu hồi khi nhân sự hoặc nhà cung cấp thay đổi. Nội dung này liên quan đến bàn giao và quản trị vận hành, không chỉ sửa lỗi.
5. Theo dõi bảo trì mà không chỉ đếm số lỗi
Số lỗi được xử lý là một thông tin, nhưng cần xem thêm mức ảnh hưởng, thời gian gián đoạn, vấn đề lặp lại và công việc phòng ngừa đã thực hiện.
Nếu số lỗi thấp vì người dùng không biết cách báo, hệ thống chưa chắc ổn định. Nếu số yêu cầu tăng do mở thêm phạm vi, không thể kết luận chất lượng giảm chỉ từ số lượng.
Nên rà soát định kỳ những thay đổi của nghiệp vụ, công nghệ và dịch vụ liên quan. Kế hoạch bảo trì phải được điều chỉnh theo hệ thống đang vận hành, thay vì giữ nguyên vì đã dùng cùng một mẫu nhiều năm.
Một kế hoạch hỗ trợ rõ phải trả lời được ba câu hỏi: ai theo dõi, ai xử lý và dựa vào đâu để xác nhận hệ thống đã hoạt động trở lại. Doanh nghiệp nên rà soát các câu trả lời này khi phạm vi sử dụng hoặc các dịch vụ liên quan thay đổi.
