Bối cảnh
- Trong giai đoạn đầu dự án, mình đề xuất tạo tài liệu logic xử lý + mô tả màn hình
- Khách phản hồi:
“Không cần đâu. Làm xong rồi chúng tôi xem trực tiếp là được.”
👉 Mình ghi nhận và không làm thêm tài liệu để tiết kiệm effort như họ mong muốn.
6 tháng sau – hệ thống xảy ra lỗi phức tạp về xử lý nghiệp vụ.
Khách hỏi:
“Có tài liệu mô tả xử lý phần này không?” → Mình trả lời: “Phần đó chưa có tài liệu chi tiết ạ, vì lúc trước bên mình được yêu cầu không cần làm.”
Phản hồi:
“Dù vậy thì bây giờ cũng nên có gì để tra cứu chứ. Sao không chủ động tạo?”
Cảm xúc & sai lầm ban đầu
- Mình thấy khó chịu và bất công – vì đã làm đúng theo yêu cầu
- Nhưng mình không phản hồi rõ ràng, cũng không đề xuất giải pháp ngay
➡️ Kết quả: tạo cảm giác như team thiếu trách nhiệm và bị động
Cách mình xử lý lại lần sau
1. Ghi log rõ ràng việc khách từ chối tài liệu – lưu lại trên wiki hoặc mail
Không phải để đổ lỗi, mà để làm rõ ngữ cảnh khi cần xem lại
2. Tự tạo bản tài liệu nội bộ đơn giản – chỉ cần 30% effort
Có thể không gửi cho khách, nhưng có để khi cần thì cập nhật nhanh
3. Đề xuất làm tài liệu sau release như một hạng mục riêng
Gọi là “Tài liệu vận hành” hoặc “Document bổ sung sau triển khai”
Bài học rút ra
- Dù khách bảo không cần – BrSE vẫn nên có bản tài liệu thô trong tay
- Giao tiếp cần log lại – để khi có vấn đề thì dễ xác minh
- Khi có sự cố – điều quan trọng không phải “ai đúng” mà là “giải quyết được đến đâu”
Kết luận
Tài liệu không chỉ để khách đọc – mà còn là tấm bản đồ để bạn điều phối team khi có sự cố.
Là BrSE, bạn cần biết lúc nào “cứ làm âm thầm” – để bảo vệ cả team khỏi những trách móc không đáng có sau này.
👉 Bài tiếp theo mình sẽ kể tình huống: “Dev từ chối task vì ‘không phải trách nhiệm của tôi’ – mình xử lý ra sao?”