Checklist go-live dành cho người không rành kỹ thuật
Nhiều đội xem thời điểm sản phẩm chạy được là đã xong. Thực tế, giai đoạn go-live phần mềm mới là lúc rủi ro vận hành bắt đầu xuất hiện: ai giữ tài khoản quản trị, bản nào đang chạy ở production, có môi trường staging để thử trước hay không, bàn giao source đã đủ chưa, release notes có rõ ràng không, và khi phát sinh yêu cầu mới thì nên sửa nóng hay mở scope mới.
Nếu bạn là founder, chủ doanh nghiệp SME hoặc người phụ trách dự án nhưng không rành kỹ thuật, bài viết này giúp bạn có một checklist tối thiểu để kiểm tra trước và ngay sau khi launch, theo cách dễ hiểu và có thể dùng ngay trong buổi bàn giao.
1. Mục tiêu của checklist go-live là gì?
Checklist go-live không phải để làm khó đội kỹ thuật. Nó giúp hai bên thống nhất một điểm rất quan trọng: hệ thống nào đã sẵn sàng vận hành, ai chịu trách nhiệm ở từng phần, và điều gì nằm trong phạm vi cam kết hiện tại.
Một checklist tốt sẽ giúp bạn:
- Biết chính xác sản phẩm nào đang được đưa lên production.
- Giảm rủi ro phụ thuộc vào một cá nhân hoặc một nhà cung cấp.
- Dễ truy vết khi có lỗi sau launch.
- Phân biệt việc nào là bảo hành, việc nào là yêu cầu mới.
- Giữ được mạch quyết định sau khi sản phẩm đi vào vận hành.
2. Danh sách đầu mục tối thiểu phải có khi bàn giao và vận hành
2.1. Xác nhận phạm vi bàn giao
Trước khi nói đến kỹ thuật, hãy xác nhận lại phần việc đã hoàn thành. Đây là lúc tài liệu build-commit brief hoặc biên bản chốt phạm vi phát huy tác dụng. Bạn cần có một bản tóm tắt ngắn gọn về:
- Mục tiêu của phiên bản hiện tại.
- Những tính năng đã hoàn thành.
- Những gì chưa làm hoặc đã loại khỏi scope.
- Các giới hạn chấp nhận được ở giai đoạn này.
- Tiêu chí nghiệm thu đã được hai bên thống nhất.
Nếu dự án được chia theo mức ưu tiên, hãy đánh dấu rõ đâu là hạng mục Level 3. Đây thường là nhóm tính năng không bắt buộc để go-live nhưng dễ bị hiểu nhầm là “đã bao gồm”. Chỉ riêng việc làm rõ Level 3 và scope đã giúp tránh rất nhiều tranh cãi sau launch.
2.2. Kiểm tra môi trường staging và production
Người không rành kỹ thuật thường chỉ nghe “đã deploy rồi”. Nhưng bạn cần hỏi rõ đang có bao nhiêu môi trường và mỗi môi trường dùng để làm gì.
- Staging: môi trường dùng để kiểm thử trước khi đưa lên thật.
- Production: môi trường thật, nơi người dùng cuối đang truy cập.
Các câu hỏi tối thiểu cần xác nhận:
- Link staging là gì? Link production là gì?
- Phiên bản hiện tại ở staging có trùng với phiên bản chuẩn bị đưa lên production không?
- Dữ liệu trên staging có phải dữ liệu thật hay dữ liệu mẫu?
- Ai có quyền deploy từ staging sang production?
- Nếu cần rollback, quy trình thực hiện là gì?
Bạn không cần hiểu sâu về hạ tầng, chỉ cần đảm bảo đội triển khai trả lời được ngắn gọn, rõ ràng và có người chịu trách nhiệm.
2.3. Tài khoản và quyền truy cập
Sau launch, rủi ro lớn nhất thường không nằm ở code mà nằm ở quyền truy cập bị phân tán hoặc không ai nắm đầy đủ. Hãy yêu cầu danh sách các tài khoản liên quan:
- Hosting hoặc cloud server.
- Tên miền và DNS.
- Kho source code.
- Công cụ quản lý dự án.
- Email hệ thống, SMTP, dịch vụ gửi thông báo.
- Database, dịch vụ lưu trữ file, analytics, monitoring.
- Tài khoản admin trong ứng dụng.
Với mỗi tài khoản, cần rõ:
- Ai là chủ sở hữu.
- Email đăng ký thuộc công ty bạn hay nhà cung cấp.
- Ai đang giữ quyền cao nhất.
- Mật khẩu hoặc cơ chế bàn giao an toàn là gì.
- Có bật xác thực hai lớp hay chưa.
Nguyên tắc an toàn là tài khoản lõi nên thuộc doanh nghiệp của bạn, không nên để toàn bộ nằm ở email cá nhân của bên triển khai.
2.4. Bàn giao source và tài liệu
Bàn giao source không chỉ là gửi một file nén. Bạn cần xác nhận ít nhất các phần sau:
- Kho source nằm ở đâu.
- Nhánh chính để vận hành là nhánh nào.
- Có hướng dẫn cài đặt môi trường mới hay không.
- Danh sách biến môi trường cần thiết.
- Các dịch vụ bên thứ ba mà hệ thống đang phụ thuộc.
- Cách backup và restore dữ liệu.
- Tài liệu cấu trúc cơ bản của hệ thống.
Nếu đội triển khai nói “đã bàn giao source”, bạn có thể hỏi rất đơn giản: “Một đội mới vào có thể dựng lại hệ thống từ tài liệu này không?” Nếu câu trả lời là không chắc, thì việc bàn giao chưa đủ.
2.5. Release notes và danh sách lỗi đã biết
Mỗi lần go-live nên có release notes, tức bản ghi những gì thay đổi trong phiên bản đó. Đây là tài liệu cực kỳ hữu ích cho người quản lý vì nó giúp bạn biết:
- Tính năng nào vừa được thêm hoặc sửa.
- Lỗi nào đã được khắc phục.
- Điểm nào cần người dùng kiểm tra lại sau launch.
- Known issues, tức các lỗi hoặc giới hạn đã biết nhưng tạm chấp nhận.
Nếu không có release notes, chỉ sau vài tuần bạn sẽ rất khó xác định một lỗi phát sinh do phiên bản mới hay đã tồn tại từ trước.
2.6. Kế hoạch hỗ trợ sau launch
Go-live không nên kết thúc bằng câu “có gì báo lại”. Bạn cần có tối thiểu:
- Kênh tiếp nhận sự cố chính thức.
- Thời gian phản hồi dự kiến.
- Mức độ ưu tiên của sự cố.
- Người đầu mối phía business và phía kỹ thuật.
- Khung thời gian hỗ trợ sau launch, ví dụ 7 ngày, 14 ngày hoặc 30 ngày.
Nếu có thể, hãy yêu cầu phân loại sự cố thành mức khẩn cấp, cao, trung bình và thấp để tránh việc mọi yêu cầu đều bị gọi là “cần gấp”.
3. Cách tự kiểm tra trạng thái mà không cần quá rành kỹ thuật
3.1. Kiểm tra phiên bản đang chạy
Hãy yêu cầu đội triển khai chỉ rõ phiên bản hiện tại bằng một cách dễ nhìn, ví dụ mã release, ngày deploy hoặc số phiên bản. Bạn không cần hiểu commit là gì, nhưng cần có một dấu mốc để biết bản nào đang chạy trên production.
3.2. Kiểm tra luồng quan trọng nhất
Đừng cố test toàn bộ hệ thống. Hãy chọn 3 đến 5 luồng quan trọng nhất, ví dụ:
- Đăng nhập.
- Tạo đơn hoặc tạo yêu cầu.
- Thanh toán hoặc xác nhận giao dịch.
- Gửi email hoặc thông báo.
- Xuất báo cáo hoặc xem dữ liệu quan trọng.
Nếu các luồng cốt lõi này hoạt động ổn ở production, bạn đã giảm được phần lớn rủi ro vận hành ban đầu.
3.3. Kiểm tra backup và khả năng khôi phục
Nhiều dự án có backup nhưng chưa từng kiểm tra restore. Bạn nên hỏi thẳng:
- Dữ liệu được backup theo chu kỳ nào?
- Backup đang lưu ở đâu?
- Lần gần nhất kiểm tra restore là khi nào?
- Nếu production gặp sự cố, thời gian khôi phục dự kiến là bao lâu?
Đây là câu hỏi quản trị, không phải câu hỏi kỹ thuật sâu. Một đội vận hành tốt phải trả lời được rõ ràng.
4. Khi nào nên sửa nóng, khi nào nên mở scope mới?
Sau launch, đây là điểm dễ gây xung đột nhất. Từ góc nhìn business, mọi vấn đề đều ảnh hưởng vận hành. Từ góc nhìn triển khai, không phải việc nào cũng là lỗi phải sửa ngay.
Nên sửa nóng khi:
- Hệ thống không chạy được ở chức năng cốt lõi đã cam kết.
- Lỗi gây gián đoạn cho nhiều người dùng.
- Lỗi ảnh hưởng dữ liệu, thanh toán, bảo mật hoặc uy tín doanh nghiệp.
- Hành vi thực tế khác đáng kể so với tài liệu đã chốt.
Nên mở scope mới khi:
- Bạn muốn thay đổi quy trình nghiệp vụ sau khi dùng thử thực tế.
- Bạn muốn thêm báo cáo, màn hình hoặc quyền mới chưa có trong brief.
- Bạn muốn tối ưu trải nghiệm vượt ngoài mức đã nghiệm thu.
- Yêu cầu thuộc nhóm Level 3 hoặc nhóm ưu tiên sau.
Cách đơn giản nhất là quay lại tài liệu build-commit brief hoặc bản chốt phạm vi ban đầu. Nếu yêu cầu mới không nằm trong mục tiêu đã cam kết, hãy coi đó là scope mới. Làm vậy giúp dự án minh bạch hơn và tránh biến giai đoạn bảo hành thành một vòng phát triển không hồi kết.
5. Rủi ro sau launch nếu không có quy trình bàn giao rõ ràng
- Mất quyền kiểm soát: tài khoản quan trọng nằm ở email của một cá nhân.
- Không thể thay nhà cung cấp: có source nhưng thiếu tài liệu và thiếu quyền truy cập.
- Không truy vết được lỗi: không có release notes, không rõ phiên bản nào đang chạy.
- Phát sinh tranh cãi: không phân biệt được lỗi bảo hành và yêu cầu mới.
- Gián đoạn vận hành: không có quy trình xử lý sự cố và không rõ người chịu trách nhiệm.
Phần lớn rủi ro này không đến từ công nghệ quá phức tạp, mà đến từ việc thiếu một checklist bàn giao đủ rõ.
6. Ví dụ checklist thực hành cho SME hoặc founder
Bạn có thể dùng danh sách ngắn dưới đây trong buổi bàn giao:
- Phiên bản nào vừa go-live? Có release notes hay không?
- Link staging và production là gì? Khác nhau thế nào?
- Các luồng cốt lõi đã được kiểm tra lại trên production chưa?
- Danh sách tài khoản quản trị đã bàn giao đủ chưa?
- Kho source ở đâu? Ai có quyền truy cập?
- Tài liệu cài đặt, biến môi trường và hướng dẫn khôi phục có sẵn chưa?
- Backup đang chạy theo lịch nào? Đã từng kiểm tra restore chưa?
- Những lỗi đã biết hiện tại là gì? Có ảnh hưởng vận hành không?
- Khung hỗ trợ sau launch là bao lâu? Báo lỗi qua kênh nào?
- Yêu cầu nào được xem là bảo hành, yêu cầu nào phải mở scope mới?
Nếu 10 câu này được trả lời rõ ràng, bạn đã có một nền tảng vận hành tốt hơn rất nhiều so với đa số dự án chỉ “deploy xong là xong”.
7. Kết luận
Checklist go-live dành cho người không rành kỹ thuật không cần dài dòng, nhưng phải đủ rõ để bảo vệ quyết định kinh doanh sau khi launch. Hãy tập trung vào 4 nhóm chính: phạm vi đã chốt, trạng thái môi trường staging/production, bàn giao source và tài liệu, cùng cơ chế hỗ trợ sau launch.
Khi mọi thông tin được ghi lại rõ ràng, bạn sẽ dễ phân biệt đâu là lỗi cần sửa nóng, đâu là yêu cầu mới cần mở scope, và đâu là phần Level 3 có thể ưu tiên sau. Nếu cần một cách làm việc giữ được mạch quyết định từ lúc làm rõ bài toán phần mềm đến lúc go-live và vận hành, AITaoPhanMem là cách hữu ích để đội business và đội triển khai nói cùng một ngôn ngữ.
