Lời khuyên kiểu "hãy sa thải agency nếu họ trễ deadline" hay "đừng ném tiền tốt vào chỗ tệ" thì không thiếu. Bạn có thể tìm thấy khắp nơi.
Điều không ai nói là: đổi agency sẽ tốn thêm bao nhiêu.
Sự thất vọng là thật. Trễ deadline là thật. Giao tiếp chậm chạp là thật. Nhưng cảm giác thất vọng không phải là ngân sách. Và quyết định thay một agency bằng agency khác giữa chừng dự án là một trong những quyết định đắt đỏ nhất bạn có thể đưa ra — dù đôi khi đó vẫn là lựa chọn đúng.
Dưới đây là những gì bạn thực sự phải trả khi chuyển đổi.
Chi Phí Chìm vs. Chi Phí Chuyển Đổi — Hai Vấn Đề Khác Nhau
Hầu hết các founder khi quyết định đổi agency giữa chừng đều đang nghĩ đến chi phí chìm (sunk cost): số tiền đã bỏ ra cho công việc không ra kết quả. Con số đó thật và đau.
Nhưng chi phí chìm là khoản lỗ cố định. Bạn đã trả rồi. Chi phí chuyển đổi mới là điều bạn sắp phải trả — và hiếm ai tính toán kỹ trước khi ra quyết định.
Chi phí chuyển đổi bao gồm: thời gian để onboard agency mới, giai đoạn làm quen trước khi họ thực sự làm được việc, thời gian "khảo cổ code" để hiểu những gì agency cũ đã làm, các bug xuất hiện trong quá trình bàn giao, và hàng tuần mất tốc độ trong khi team mới mò mẫm codebase cũ.
Hầu hết khách hàng chỉ muốn thoát khỏi tình huống tệ. Ít ai dừng lại để hỏi: thoát ra có giá bao nhiêu?
Những Gì Bị Mất Khi Agency Ra Đi
Dự án phần mềm tích lũy một thứ không bao giờ xuất hiện trong hợp đồng: context — hiểu biết ngữ cảnh.
Context là sự hiểu biết về tại sao các quyết định được đưa ra, không chỉ là quyết định gì đã được đưa ra. Tại sao luồng xác thực lại được cấu trúc như vậy? Tại sao tích hợp bên thứ ba kia bị bỏ qua? Tại sao module này lại có timeout bất thường đó? Câu trả lời thường nằm trong một cuộc trò chuyện Slack từ ba tháng trước, hoặc trong đầu một lập trình viên không còn trong dự án nữa.
Khi agency cũ ra đi, context đó biến mất theo họ. Agency mới kế thừa code — không phải hiểu biết. Họ đọc được các file. Họ không đọc được lý do.
Khoảng cách này chuyển hóa trực tiếp thành thời gian. Team mới phải "giải mã ngược" những quyết định mà team cũ đã tốn nhiều tuần để đi đến. Họ sẽ phỏng đoán ở những chỗ cần sự chắc chắn. Một số phỏng đoán sẽ sai — và bạn sẽ phát hiện sau, thường là khi đã lên production.
Ngoài context, bạn còn mất:
- Tài liệu — nếu có. Nhiều agency viết tài liệu sơ sài vì áp lực deadline.
- Quy ước code — cách đặt tên, cấu trúc thư mục, các pattern nhất quán nội bộ nhưng không được ghi lại.
- Vốn quan hệ — sự tin tưởng không chính thức giúp giao tiếp nhanh hơn. Agency mới bắt đầu từ điểm 0.
- Kiến thức ngầm — những gì team biết về business của bạn, người dùng của bạn, ưu tiên của bạn. Kiến thức đó mất thời gian mới xây dựng được.
Không có gì trong số này có thể phục hồi bằng cách gửi link repository GitHub.
Khoản Thuế Thời Gian Ẩn
Đây là con số hầu hết khách hàng đánh giá thấp: một agency mới có năng lực cần bốn đến tám tuần mới thực sự làm việc hiệu quả trên codebase kế thừa.
Không phải vì họ chậm. Mà vì việc hiểu code của người khác — được viết với các giả định khác, quy ước khác, bởi những người không còn để hỏi — đòi hỏi thời gian. Kỹ sư giỏi coi trọng thời gian đó, vì làm ẩu thì chỉ tạo thêm bug.
Trong những tuần đó, bạn vẫn đang trả tiền cho agency mới. Và bạn cũng mất luôn những tuần đó — những tuần đáng lẽ phải là thời gian phát triển, không phải onboarding.
Nếu agency cũ đã trễ bốn tuần, và agency mới cần sáu tuần để làm quen, bạn không giải quyết được vấn đề — bạn đang kéo dài nó.
Cộng thêm thời gian tìm kiếm và lựa chọn agency mới (thường hai đến bốn tuần thời gian của bạn), đàm phán hợp đồng mới, chuyển giao thông tin đăng nhập và quyền truy cập, brief team mới về sản phẩm — bạn đang nhìn vào độ trễ thực tế từ hai đến bốn tháng trước khi agency mới chạy hết tốc lực.
Đó là chi phí thời gian. Chi phí tiền bạc chạy song song với nó.
Khi Nào Chuyển Đổi Thực Sự Đáng
Tất cả điều này nghe như lý do để ở lại, đúng không? Không hẳn.
Có những tình huống mà chuyển đổi là quyết định đúng — và chi phí chuyển đổi, dù có thật, vẫn thấp hơn chi phí tiếp tục ở lại.
Bạn nên nghiêm túc xem xét việc chuyển đổi khi:
Chất lượng code về cơ bản là sai. Không phải chậm, không phải thô — mà là sai. Nếu những gì đã được xây dựng không ổn về mặt kiến trúc, hoặc nợ kỹ thuật nghiêm trọng đến mức mọi tính năng mới đều đòi hỏi xây lại nền móng, thì ở lại còn tốn kém hơn ra đi.
Niềm tin đã sụp đổ. Giao tiếp ngừng lại. Cam kết được đưa ra nhưng không được giữ. Giải thích không khớp với thực tế. Một mối quan hệ agency không có niềm tin không phải là partnership — đó là gánh nặng.
Scope đã lệch hướng không thể cứu vãn. Nếu những gì đang được xây dựng không còn là những gì bạn cần, và agency không thể (hoặc không muốn) điều chỉnh, ở lại có nghĩa là hoàn thành sản phẩm sai.
Agency đang tan rã. Nhân sự biến động, lãnh đạo rời đi, tình hình tài chính bất ổn — đây là dấu hiệu cho thấy sự liên tục bạn cần không tồn tại, bất kể hợp đồng nói gì.
Trong những trường hợp này, hãy chuyển đổi. Nhưng chuyển với đôi mắt mở. Chi phí chuyển đổi vẫn là thật. Bạn không tránh được nó — bạn chỉ quyết định rằng nó đáng để trả.
Cách Bảo Vệ Bản Thân — Dù Dùng Agency Nào
Cách bảo vệ tốt nhất trước chi phí chuyển đổi là làm cho việc chuyển đổi trở nên rẻ hơn — trước khi bạn cần đến nó. Điều đó có nghĩa là xây dựng từ ngày đầu:
Yêu cầu tài liệu trong hợp đồng. Không phải "chúng tôi sẽ ghi lại vào cuối dự án." Tài liệu hàng tuần, gắn với từng milestone. Các quyết định kiến trúc phải được ghi lại, không chỉ được thực hiện.
Code review định kỳ. Không chỉ review nội bộ — mời người ngoài xem tại 30%, 60%, và 90% tiến độ xây dựng. Điều này phát hiện drift kiến trúc sớm, khi còn dễ sửa.
Kênh chia sẻ kiến thức. Team của bạn nên có quyền đọc vào giao tiếp dự án (hoặc ít nhất là một brief văn bản thường xuyên) để kiến thức không chỉ nằm ở phía agency.
Kiểm soát quyền truy cập và thông tin đăng nhập. Bạn phải sở hữu tất cả thông tin đăng nhập, môi trường, và repository từ ngày đầu. Điều này không thể thỏa hiệp. Khi bạn cần chuyển đổi, bạn không nên phải vừa đấu tranh để lấy lại quyền truy cập.
Review milestone trung thực. Mỗi milestone lớn là điểm dừng tự nhiên. Đánh giá tại mỗi điểm — không chỉ deliverable, mà cả sức khỏe của mối quan hệ và quy trình. Vấn đề nhỏ phát hiện ở milestone thứ hai là một cuộc trò chuyện. Cùng vấn đề đó phát hiện ở milestone thứ năm là một cuộc khủng hoảng.
Kết Luận
Đôi khi chuyển đổi agency là quyết định đúng. Nhưng không bao giờ là quyết định miễn phí. Nó tốn thời gian bạn không lên kế hoạch, tiền bạc bạn không dự tính, và đà phát triển bạn phải xây dựng lại từ đầu.
Trước khi đưa ra quyết định đó, hãy tính toán. Không chỉ những gì bạn đã mất với agency hiện tại — mà cả những gì bạn sắp chi cho agency tiếp theo.
Những agency đáng để ở lại là những agency làm cho việc chuyển đổi trở nên không cần thiết. Họ giao tiếp sớm khi có vấn đề. Họ ghi lại tài liệu liên tục. Họ đối xử với codebase của bạn như thứ gì đó có thể phải bàn giao lại — vì họ biết điều đó có thể xảy ra.
Đó là loại agency bảo vệ dự án của bạn bất kể mối quan hệ kết thúc như thế nào.
