Nhiều đội nghĩ rằng khi phần mềm đã chạy được là dự án coi như xong. Thực tế, giai đoạn dễ phát sinh rủi ro nhất lại thường nằm ngay sau launch: vendor rút đi, đội in-house tiếp quản nhưng thiếu tài liệu, thiếu quyền truy cập, thiếu bối cảnh quyết định và không rõ phải sửa gì trước. Nếu không chuẩn bị kỹ, một sản phẩm vừa go-live có thể nhanh chóng rơi vào trạng thái “chạy được nhưng không ai dám chạm vào”.
Trong các dự án AITaoPhanMem, đây là lúc cần làm rõ bài toán phần mềm ở Level 3: không chỉ biết hệ thống làm gì, mà còn biết phạm vi hiện tại đến đâu, ai đang giữ quyền gì, quy trình release thế nào và sau này mở rộng dựa trên nguyên tắc nào. Nói cách khác, bàn giao không phải là gửi một file source code rồi kết thúc, mà là chuyển giao năng lực vận hành.
Danh sách đầu mục tối thiểu phải có ở giai đoạn bàn giao
1. Source code và lịch sử thay đổi
- Toàn bộ source code đang chạy thực tế, không phải bản sao cũ hoặc nhánh thử nghiệm.
- Quyền sở hữu repository, danh sách branch đang dùng, quy ước merge và tag release.
- Commit history đủ rõ để đội in-house lần lại các thay đổi quan trọng.
- Danh sách thư viện, package, phiên bản và các dependency bên ngoài.
Nếu có thể, hãy yêu cầu vendor bàn giao thêm một build-commit brief: tài liệu ngắn mô tả build nào hiện đang chạy, commit nào tương ứng, release gần nhất gồm thay đổi gì và các điểm còn dang dở. Đây là cầu nối rất hữu ích giữa code và bối cảnh kinh doanh.
2. Môi trường vận hành: local, staging, production
- Mô tả rõ từng môi trường: local, staging, production dùng để làm gì.
- Cấu hình deploy, biến môi trường, secrets, domain, SSL, cron job, queue, storage.
- Danh sách server, dịch vụ cloud, tài khoản thanh toán và người sở hữu.
- Quy trình đẩy bản mới từ staging lên production.
Một lỗi phổ biến là staging và production khác nhau quá nhiều, khiến đội in-house kiểm thử một kiểu nhưng lên thật lại hỏng theo kiểu khác. Khi bàn giao, cần xác nhận rõ trạng thái staging production: staging có đủ giống production để test release hay không, dữ liệu test có an toàn hay không, ai được quyền deploy.
3. Tài liệu hệ thống
- Tài liệu kiến trúc tổng quan.
- Sơ đồ luồng nghiệp vụ chính.
- Danh sách API, webhook, tích hợp bên thứ ba.
- Tài liệu database: bảng chính, quan hệ dữ liệu, trường nhạy cảm.
- Hướng dẫn cài môi trường dev cho người mới.
- Runbook xử lý sự cố thường gặp.
Tài liệu không cần dài dòng, nhưng phải đủ để một người mới vào đội có thể đọc và làm việc trong thời gian ngắn. Nếu tài liệu quá sơ sài, chi phí tiếp quản sẽ bị đẩy sang những cuộc họp hỏi lại hoặc những lần sửa nhầm nguy hiểm.
4. Quyền truy cập và phân quyền
- Repository code.
- Cloud, VPS, container registry, CI/CD.
- Database, log system, monitoring, analytics.
- Domain, DNS, email gửi hệ thống, SMS, dịch vụ thanh toán.
- Công cụ quản lý công việc, tài liệu, thiết kế.
Đừng chỉ hỏi “đã bàn giao tài khoản chưa”. Hãy kiểm tra cụ thể: tài khoản đứng tên ai, có bật xác thực hai lớp hay không, có dùng email cá nhân của vendor hay không, và quyền admin tối cao đã nằm trong tay công ty chưa. Đây là điểm sống còn sau khi vendor rút đi.
5. Release notes và backlog tồn đọng
- Bản release notes gần nhất: sửa gì, thêm gì, ảnh hưởng gì.
- Danh sách bug đã biết nhưng chưa sửa.
- Danh sách tính năng đã hứa nhưng chưa nằm trong phạm vi hiện tại.
- Các giới hạn kỹ thuật đã biết và cách né chúng tạm thời.
Release notes giúp đội in-house hiểu trạng thái hiện tại thay vì đoán mò. Đồng thời, backlog tồn đọng cần tách bạch giữa lỗi thực sự, cải tiến nhỏ và yêu cầu mới để tránh tranh cãi về trách nhiệm sau bàn giao.
6. Dữ liệu, backup và bảo mật
- Chính sách backup: tần suất, nơi lưu, thời gian giữ bản sao.
- Quy trình restore đã được thử chưa.
- Dữ liệu nào là dữ liệu nhạy cảm, ai được truy cập.
- Danh sách key, token, secret cần xoay vòng sau bàn giao nếu cần.
Không ít đội chỉ phát hiện backup không dùng được khi sự cố đã xảy ra. Vì vậy, bàn giao phải bao gồm cả kiểm tra khả năng phục hồi, không chỉ là danh sách “có backup”.
7. Vận hành sau launch
- Ai là người trực theo dõi cảnh báo.
- Các chỉ số tối thiểu cần xem mỗi ngày hoặc mỗi tuần.
- Kênh tiếp nhận lỗi từ người dùng.
- Quy trình phân loại mức độ sự cố.
- Thời gian phản hồi mong đợi cho từng loại vấn đề.
Vận hành sau launch là phần dễ bị xem nhẹ nhất. Nếu không có người chịu trách nhiệm rõ ràng, mọi việc sẽ dồn vào founder hoặc PM, tạo ra tình trạng xử lý sự cố theo cảm tính.
Cách kiểm tra trạng thái môi trường, tài liệu, release notes và quyền truy cập
Kiểm tra môi trường
- Đăng nhập được vào staging và production hay chưa.
- Thử một lần deploy lên staging theo đúng quy trình bàn giao.
- Đối chiếu version đang chạy với tag hoặc commit trong repository.
- Kiểm tra log, monitoring, alert có đang hoạt động.
Nếu đội in-house chưa tự deploy được lên staging thì bàn giao chưa hoàn tất, dù vendor nói hệ thống đã đủ tài liệu.
Kiểm tra tài liệu
- Chọn một thành viên chưa tham gia dự án từ đầu và yêu cầu họ cài môi trường theo tài liệu.
- Yêu cầu họ tìm vị trí một luồng nghiệp vụ chính trong code.
- Yêu cầu họ mô tả lại kiến trúc sau khi đọc tài liệu.
Nếu người mới không thể tự làm ba việc này, tài liệu vẫn chưa đạt mức sử dụng được.
Kiểm tra release notes
- Xem 3 bản release gần nhất có ghi thay đổi rõ ràng không.
- Đối chiếu release notes với ticket hoặc commit thực tế.
- Xác nhận có ghi chú về thay đổi ảnh hưởng đến dữ liệu, bảo mật hoặc tích hợp.
Release notes tốt sẽ giúp đội in-house giảm thời gian điều tra khi có lỗi phát sinh sau go-live phần mềm.
Kiểm tra quyền truy cập
- Lập một bảng gồm dịch vụ, tài khoản chủ sở hữu, quyền hiện tại, người tiếp quản.
- Xác nhận mọi tài khoản quan trọng không phụ thuộc email cá nhân của vendor.
- Đổi mật khẩu hoặc xoay vòng token với các hệ thống nhạy cảm.
Đây là bước rất quan trọng khi bàn giao source và bàn giao hệ thống thực tế. Có code mà không có quyền truy cập môi trường thì đội in-house vẫn bị khóa tay.
Khi nào nên sửa nóng, khi nào nên mở một scope mới
Sau khi tiếp quản, đội in-house thường gặp áp lực “có gì sửa ngay nấy”. Cách làm này dễ khiến hệ thống rối hơn. Hãy tách bạch như sau:
Nên sửa nóng khi
- Lỗi làm gián đoạn giao dịch hoặc mất doanh thu.
- Lỗi liên quan bảo mật, rò rỉ dữ liệu, sai lệch dữ liệu nghiêm trọng.
- Lỗi khiến người dùng không thể hoàn thành tác vụ cốt lõi.
- Thay đổi nhỏ, phạm vi hẹp, có thể kiểm soát rủi ro nhanh.
Nên mở scope mới khi
- Yêu cầu làm thay đổi luồng nghiệp vụ hoặc cấu trúc dữ liệu đáng kể.
- Cần sửa nhiều màn hình, nhiều role hoặc nhiều tích hợp.
- Phát sinh mong muốn mới ngoài cam kết đã có trong dự án.
- Cần thêm thời gian phân tích để tránh sửa một điểm hỏng ba điểm khác.
Muốn phân biệt đúng, trước đó phải có tài liệu phạm vi rõ ràng. Một bản scope được chốt tốt và một build-commit brief rõ ràng sẽ giúp đội in-house biết đâu là lỗi thuộc phần đã cam kết, đâu là yêu cầu mở rộng.
Rủi ro sau launch nếu không có quy trình bàn giao rõ ràng
- Không ai biết bản nào đang chạy và sửa ở đâu.
- Không deploy được vì thiếu secret hoặc tài khoản.
- Không khôi phục được khi production lỗi.
- Founder bị kéo vào các quyết định kỹ thuật lẽ ra đội vận hành phải xử lý.
- Vendor và đội in-house tranh cãi về việc nào là bug, việc nào là tính năng mới.
- Chi phí bảo trì tăng nhanh vì phải “đọc ngược” hệ thống thay vì tiếp quản có cấu trúc.
Điều đáng ngại là các rủi ro này thường không bùng nổ ngay ngày đầu, mà xuất hiện vài tuần hoặc vài tháng sau go-live phần mềm, khi đội cũ đã rút hẳn và bối cảnh ra quyết định không còn ai nhớ rõ.
Checklist thực hành cho SME hoặc founder không rành kỹ thuật
- Yêu cầu một danh sách đầy đủ các hệ thống, tài khoản và người sở hữu.
- Đảm bảo công ty giữ quyền admin cao nhất ở repo, server, cloud, domain và analytics.
- Yêu cầu vendor chỉ rõ commit hoặc tag đang chạy trên production.
- Yêu cầu một buổi walkthrough kiến trúc và một buổi walkthrough quy trình deploy.
- Yêu cầu release notes của 3 lần phát hành gần nhất.
- Yêu cầu danh sách bug đã biết, giới hạn đã biết và việc còn dang dở.
- Kiểm tra có tài liệu cài môi trường dev cho người mới hay chưa.
- Kiểm tra có backup và đã từng thử restore hay chưa.
- Chốt kênh xử lý sự cố trong 30 đến 60 ngày đầu sau bàn giao.
- Phân loại rõ: lỗi cần hotfix, yêu cầu mới cần đưa vào scope kế tiếp.
Nếu làm được 10 bước này, bạn đã giảm đáng kể nguy cơ bị phụ thuộc vào một cá nhân hoặc một vendor sau launch.
Kết luận
Một sản phẩm vận hành bền không chỉ nhờ build nhanh mà còn nhờ bàn giao rõ. Sau khi vendor rút đi, đội in-house cần tiếp nhận không chỉ code mà cả quyết định, phạm vi, quy trình và quyền kiểm soát hệ thống. Khi bạn làm rõ bài toán phần mềm ở Level 3, có scope minh bạch, có build-commit brief, có quy trình từ staging đến production và có kế hoạch vận hành sau launch, việc tiếp quản sẽ thực sự khả thi.
Nếu muốn giữ mạch quyết định xuyên suốt trước, trong và sau launch, AITaoPhanMem là cách tốt để biến các đầu việc tưởng rời rạc thành một hệ thống bàn giao có thể kiểm tra và vận hành được.
