Những Điều Không Ai Nói Với Bạn Về Bảo Trì Sau Khi Ra Mắt

Giai đoạn phát triển là lúc mọi người chú ý nhất. Sprint được review. Demo được lên lịch. Kênh Slack nhộn nhịp. Bạn theo dõi từng mốc tiến độ.

Rồi dự án ra mắt, agency hoàn thành công việc, và mối quan hệ lặng lẽ... kết thúc.

Sáu tháng sau, bạn cần cập nhật tích hợp thanh toán. Hoặc một thư viện đã hết hỗ trợ và ứng dụng bắt đầu báo lỗi. Hoặc một nhân viên mới vào không ai giải thích được quy trình deploy hoạt động như thế nào. Bạn liên hệ lại với agency, và hoặc là họ đã chuyển sang dự án khác, developer cũ không còn phụ trách tài khoản của bạn, hoặc báo giá để sửa một vấn đề nhỏ trả về con số không tương xứng với công việc thực tế.

Đây chính là nơi phần lớn các mối quan hệ thuê ngoài thực sự đổ vỡ — không phải trong quá trình xây dựng, mà trong khoảng im lặng dài sau đó.

Tại Sao Giai Đoạn Sau Ra Mắt Quyết Định Lòng Tin

Các agency có động lực để xuất sắc trong giai đoạn giao hàng. Đó là khi bạn đang theo dõi, và đó là khi hóa đơn được thanh toán. Hỗ trợ sau ra mắt thì khác. Nó thường bị định nghĩa mơ hồ, định giá thấp, và bị xếp sau các dự án mới béo bở hơn của agency.

Đây không phải là chỉ trích mọi agency — đó chỉ là cách hầu hết các mô hình hợp tác vận hành. Vấn đề là từ phía bạn, giai đoạn sau ra mắt lại là lúc bạn cần họ nhất. Lỗi xuất hiện trên môi trường production mà không hề lộ ra khi test. Người dùng làm những điều người dùng vẫn làm. Hạ tầng cần tinh chỉnh. Các tính năng được yêu cầu đòi hỏi phải hiểu những quyết định được đưa ra từ sáu tháng trước.

Nếu việc bàn giao rõ ràng và SLA được định nghĩa cụ thể, giai đoạn này hoàn toàn có thể quản lý được. Nếu không có cả hai, bạn đang gặp rắc rối.

Ba Thứ Bắt Buộc Phải Có Khi Bàn Giao

Trước khi agency kết thúc dự án, có ba deliverable không liên quan đến tính năng — và chúng quan trọng hơn danh sách tính năng về lâu dài.

Tài liệu. Không phải file README ghi "đây là ứng dụng Laravel." Mà là tài liệu thực sự: hệ thống làm gì, các thành phần chính kết nối với nhau như thế nào, kết nối tới những dịch vụ bên thứ ba nào và tại sao, những giả định nào được đưa ra trong quá trình phát triển mà developer mới cần biết. Nếu một người gia nhập team sau một năm mà agency không còn liên lạc được, họ có thể tự làm việc được không? Đó là tiêu chuẩn cần đạt.

Runbook vận hành. Runbook là tài liệu vận hành giải thích cho bất kỳ ai — developer, ops, hay chính bạn — cách duy trì hệ thống hoạt động. Deploy như thế nào? Rollback nếu có sự cố ra sao? Các cảnh báo có nghĩa gì? Phải làm gì khi database chậm? Tài liệu này nhàm chán để viết nhưng vô giá khi cần. Hãy yêu cầu bắt buộc.

Giảm thiểu bus factor. "Bus factor" là số người có thể rời đi trước khi dự án trở nên không thể bảo trì. Nếu câu trả lời là một — và người đó làm việc cho agency, không phải cho bạn — bạn đang có vấn đề phụ thuộc nghiêm trọng. Bàn giao nghĩa là chuyển giao kiến thức, không chỉ chuyển giao file. Lên lịch các buổi team agency walk-through codebase cùng developer hoặc technical lead của bạn. Ghi lại nếu cần.

SLA Bảo Trì Tốt Trông Như Thế Nào

Các thỏa thuận SLA bảo trì thường mơ hồ đến mức vô dụng. "Chúng tôi phản hồi trong 24 giờ" gần như không có nghĩa gì về loại phản hồi, loại vấn đề, hay liệu phản hồi đó có dẫn đến giải pháp không.

Một SLA bảo trì thực sự cần phân loại mức độ nghiêm trọng:

• Nghiêm trọng (P1): Ứng dụng sập hoặc tính năng cốt lõi bị lỗi với toàn bộ người dùng. Phản hồi trong 1–2 giờ, mục tiêu xử lý trong 4–8 giờ.
• Cao (P2): Tính năng chính bị ảnh hưởng nhưng ứng dụng vẫn chạy. Phản hồi trong 4 giờ, xử lý trong 24–48 giờ.
• Trung bình (P3): Lỗi không nghiêm trọng ảnh hưởng một số người dùng. Phản hồi trong 1 ngày làm việc, xử lý trong 5 ngày làm việc.
• Thấp (P4): Vấn đề nhỏ, lỗi giao diện, cải tiến UX. Gộp vào chu kỳ bảo trì định kỳ.

SLA cũng cần làm rõ: điều gì được bao gồm trong gói retainer hàng tháng, điều gì tính thêm? Phát triển tính năng mới hầu như luôn tính riêng. Sửa lỗi từ code agency đã viết? Phải được bao gồm. Sự cố hạ tầng? Tùy thuộc vào ai quản lý hạ tầng. Hãy ghi rõ các ranh giới này.

Chuyển Giao Kiến Thức: Tránh Tình Huống Con Tin

Sự thật khó chịu nhất về phát triển phần mềm là: nếu chỉ một team hiểu codebase của bạn, họ sở hữu bạn.

Điều này hiếm khi có chủ ý. Đó là kết quả tự nhiên khi một team duy nhất xây dựng sản phẩm trong nhiều tháng mà không chia sẻ kiến thức dọc đường. Khi họ rời đi, kiến thức cũng biến mất cùng họ.

Tự bảo vệ mình có nghĩa là chủ động đầu tư vào chuyển giao kiến thức trước khi dự án kết thúc:

Quyền sở hữu code từ ngày đầu. Code của bạn phải nằm trong repository thuộc tài khoản của bạn, không phải của agency. Đây là điều không thể thỏa hiệp. Tại bất kỳ thời điểm nào, bạn phải có thể cấp quyền cho developer mới mà không cần xin phép agency.

Các buổi review kiến trúc. Trước khi agency kết thúc, lên lịch ít nhất hai hoặc ba buổi họ giải thích hệ thống cho team nội bộ hoặc technical advisor của bạn. Không phải demo — mà là giải thích tại sao mọi thứ được xây dựng theo cách đó.

Ghi lại các quyết định. Architectural Decision Records (ADR) là các tài liệu đơn giản ghi lại các lựa chọn quan trọng: "Chúng tôi chọn PostgreSQL thay vì MySQL vì..." hay "Chúng tôi dùng microservices ở đây vì...". Không mất nhiều thời gian để viết và giúp team mới không vô tình đảo ngược hàng tháng suy nghĩ cẩn thận.

Chuyển giao dần dần. Nếu ngân sách cho phép, đừng kết thúc quan hệ với agency đột ngột. Duy trì giai đoạn chuyển tiếp khoảng 4–6 tuần khi người bảo trì mới (nội bộ hoặc agency mới) làm việc song song với team cũ. Câu hỏi được trả lời trực tiếp, kiến thức được chuyển giao tự nhiên.

Những Câu Hỏi Cần Hỏi Trước Khi Ký

Hầu hết khách hàng đánh giá agency qua khả năng giao hàng — portfolio, quy trình, tech stack, giá cả. Ít người nghĩ đến việc hỏi điều gì xảy ra sau khi ra mắt. Những câu hỏi này nên là một phần trong mọi cuộc đánh giá:

"Gói bàn giao tiêu chuẩn của bạn bao gồm những gì?" Nếu họ trông có vẻ bối rối hoặc trả lời mơ hồ, đó chính là câu trả lời.

"Bạn có thể cho tôi xem một SLA bảo trì đã dùng với khách hàng khác không?" Yêu cầu ví dụ thực tế phân biệt agency đã làm với agency chỉ hứa để chốt hợp đồng.

"Chuyện gì xảy ra nếu developer gốc của dự án tôi không còn sẵn sàng nữa?" Agency tốt có quy trình đảm bảo tính liên tục kiến thức. Agency kém sẽ nói với bạn rằng điều đó sẽ không xảy ra.

"Điều gì xảy ra nếu tôi muốn chuyển sang agency khác sau khi bạn đã xây dựng sản phẩm?" Câu trả lời phải là: "Chúng tôi làm cho điều đó dễ dàng." Code trong repo của bạn, tài liệu trong tay bạn, hạ tầng trên tài khoản của bạn. Bất cứ điều gì kém hơn là dấu hiệu cảnh báo.

"Ai quản lý tài khoản hosting và hạ tầng?" Mọi thứ phải đứng tên bạn. Tài khoản cloud của bạn, domain của bạn, dịch vụ email của bạn. Bạn là chủ sở hữu sản phẩm của chính mình.

Tầm Nhìn Dài Hạn

Một sản phẩm phần mềm không hoàn thành khi ra mắt. Nó hoàn thành khi ngừng hoạt động — và đó thường là nhiều năm sau. Agency bạn thuê để xây dựng phiên bản đầu tiên đang đặt nền móng cho mọi phiên bản tiếp theo.

Bảo trì sau ra mắt không nên cảm thấy như một ẩn số hay cuộc đàm phán con tin. Khi việc bàn giao kỹ lưỡng, tài liệu thực chất, và SLA cụ thể, nó trở thành những gì đáng lẽ phải là: công việc bảo trì định kỳ trên một thứ đang hoạt động tốt.

Những agency làm tốt điều này không phải đang làm ơn cho bạn. Họ đang làm đúng công việc của họ. Hãy giữ tiêu chuẩn đó với các agency bạn đánh giá — trước khi ký, không phải sau khi đã ra mắt.