Release Note
Bản ghi ngắn đi kèm mỗi lần phát hành: phiên bản này có gì mới, sửa lỗi nào, còn hạn chế gì, cần làm gì trước và sau khi cập nhật. Người vận hành và khách đọc nó để khỏi bị bất ngờ sáng hôm sau.
Định nghĩa
Bản mới lên lúc 23h. Sáng hôm sau, nhân viên vận hành mở hệ thống, thấy một nút đổi chỗ và một trường bắt buộc mới, rồi gọi lên tổng đài. Release note tồn tại để cuộc gọi đó không xảy ra.
Release note nói cho người dùng và cho đội vận hành biết phiên bản này đổi cái gì, và họ phải làm gì với thay đổi đó.
Viết cho ai
Trả lời câu này trước, rồi hãy viết. Cùng một lần phát hành thường cần hai bản khác nhau:
- Bản nội bộ: đủ chi tiết kỹ thuật, danh sách mã ticket, thay đổi cấu hình, script chạy trên database, cách quay lui nếu hỏng.
- Bản gửi khách hoặc người dùng cuối: viết theo góc nhìn công việc của họ, bỏ hết mã ticket và tên nhánh code.
| Nội dung | Bản nội bộ | Bản gửi khách |
|---|---|---|
| Mã ticket, tên nhánh code | Có | Không |
| Script chạy trên database | Có | Không |
| Thay đổi ảnh hưởng thao tác hằng ngày | Ghi gọn | Ghi kỹ, kèm ảnh chụp màn hình |
| Phương án quay lui | Có | Không |
| Khung giờ ngừng dịch vụ | Có | Có |
Gửi nhầm bản nội bộ cho khách thì khách sẽ đọc được dòng "sửa lỗi tính sai thuế cho hợp đồng cũ" và bắt đầu hỏi những câu bạn không muốn trả lời qua email.
Cấu trúc thường dùng
Phiên bản: 2.6.0
Ngày phát hành: 12/08/2026, 23h00 - 23h40
Môi trường: PROD
TÍNH NĂNG MỚI
- Xuất báo cáo doanh thu theo chi nhánh, có bộ lọc theo nhóm hàng
- Cho phép hủy đơn đã thanh toán trong 15 phút đầu
SỬA LỖI
- Sai phí giao hàng ở mốc đúng 2kg
- Danh sách đơn không hiển thị đơn cuối ngày khi lọc theo ngày
THAY ĐỔI CẦN LƯU Ý
- Trường "Mã chi nhánh" trở thành bắt buộc khi tạo đơn thủ công
- Người dùng cần đăng xuất và đăng nhập lại một lần
HẠN CHẾ ĐÃ BIẾT
- Báo cáo doanh thu chưa hỗ trợ xuất Excel, dự kiến bản 2.7
LIÊN HỆ HỖ TRỢ
- Nhóm Zalo vận hành, trực tới 9h sáng ngày 13/08Phần "hạn chế đã biết" hay bị bỏ vì nghe như tự nhận điểm yếu. Ngược lại, ghi ra thì bạn tránh được cả chục ticket báo lỗi cho thứ mình đã biết và đã có kế hoạch.
Ví dụ thực tế
23 cuộc gọi trong hai tiếng đầu buổi sáng, phần lớn hỏi cùng một câu: vì sao không lưu được đơn thuốc. Chuỗi nhà thuốc 58 điểm bán, bản mới lên đêm hôm trước, thêm ràng buộc bắt buộc nhập số lô cho thuốc kê đơn. Thay đổi đúng theo yêu cầu quản lý dược, chỉ có điều release note gửi đi ghi vỏn vẹn một dòng: "bổ sung quản lý số lô".
Lần phát hành sau, đội đổi cách viết: mỗi thay đổi ảnh hưởng thao tác hằng ngày đều có một dòng mô tả trước và sau, kèm một ảnh chụp màn hình gửi qua nhóm Zalo của các nhà thuốc. Số cuộc gọi đợt đó còn 4.
Lỗi hay gặp
- Chép nguyên danh sách ticket từ Jira dán vào. Người đọc thấy 37 dòng kiểu "ORD-1123 fix null pointer" rồi bỏ qua toàn bộ.
- Viết bằng ngôn ngữ kỹ thuật cho người dùng nghiệp vụ.
- Không ghi thời gian ngừng dịch vụ, trong khi đội vận hành cần đúng con số đó để bố trí ca trực.
- Không ghi phương án quay lui. Lúc cần thì cả nhóm ngồi hỏi nhau xem ai có quyền thực hiện.
Và cái hay gặp nhất: phát hành xong mới ngồi viết. Viết bản nháp trước, cập nhật lại sau khi deploy, vẫn hơn ngồi nhớ lại lúc 1h sáng.
Ai viết
Ở dự án nhỏ, BA hoặc PM viết là hợp lý nhất, vì họ hiểu tác động nghiệp vụ. Dev cung cấp danh sách thay đổi kỹ thuật, QC xác nhận phần lỗi đã fix và phần còn tồn. Bản nháp nên có trước ngày phát hành ít nhất một ngày để người phụ trách nghiệp vụ đọc lại — họ sẽ là người chỉ ra thay đổi nào cần báo trước cho khách hàng.
