Tóm tắt: Offshore development thất bại chủ yếu vì đặc tả không đủ rõ trước khi viết code, không phải vì lập trình viên kém hay vì nước nhận việc. Chỗ trống trong đặc tả chỉ lộ ra khi sản phẩm chạy thử. VAON xử lý bằng Giai đoạn chốt đặc tả (仕様確定フェーズ): chốt yêu cầu bằng văn bản, có báo giá cố định, khách được dừng sau giai đoạn này.
Mục lục
- Offshore development thất bại vì code hay vì đặc tả?
- Một đặc tả thiếu trông như thế nào khi đã giao cho đội offshore?
- Đổi nước hoặc thêm BrSE có giải quyết được không?
- Giai đoạn chốt đặc tả (仕様確定フェーズ) của VAON gồm những gì?
- VAON đã làm gì với Seminar Navi của Đại học Công nghệ Kochi?
- Khi nào giai đoạn chốt đặc tả chưa phải thứ bạn cần?
- Năm câu nên hỏi bất kỳ công ty offshore nào trước khi ký
- Câu hỏi thường gặp
1. Offshore development thất bại vì code hay vì đặc tả?
Offshore development thất bại vì đặc tả nhiều hơn vì chất lượng code. Code chỉ là bản dịch của quyết định. Nếu quyết định chưa được đưa ra, lập trình viên giỏi đến mấy cũng phải đoán, và đoán sai là chuyện thường.
VAON không có thống kê về nguyên nhân thất bại để đưa ra ở đây. Các con số kiểu "X% dự án offshore thất bại vì đặc tả" lưu hành trên mạng thường không truy được nguồn gốc nên chúng tôi không dùng.
Nguồn đáng tin hơn là オフショア開発白書 2025年版 (khảo sát khoảng 1.000 doanh nghiệp đặt hàng và khoảng 200 công ty nhận việc). Theo trang giới thiệu bản này, thách thức mà bên đặt hàng cảm nhận ở công ty offshore vẫn là "năng lực giao tiếp" và "quản lý chất lượng". Khi chọn nhà cung cấp, hai thách thức hàng đầu là "khớp với yêu cầu của công ty mình" và "giao tiếp ban đầu". Trang này không liệt kê đặc tả như một mục riêng và không có tỷ lệ phần trăm cho từng nguyên nhân.
Quan điểm của VAON là: giao tiếp kém và chất lượng kém thường là triệu chứng, còn đặc tả thiếu là nguyên nhân gốc. Đây là nhận định rút ra từ kinh nghiệm làm nghề của CEO, không phải kết luận của khảo sát.
2. Một đặc tả thiếu trông như thế nào khi đã giao cho đội offshore?
Một đặc tả thiếu thường không trông như thiếu. Nó trông như một tài liệu đầy đủ, cho đến khi ai đó hỏi "còn trường hợp này thì sao?".
| Chỗ trống trong đặc tả | Lập trình viên làm gì | Khi nào bị phát hiện |
|---|---|---|
| Ngoại lệ nghiệp vụ không ghi (hoàn tiền một phần, huỷ giữa chừng) | Tự chọn cách xử lý hợp lý nhất theo suy đoán | Khi nghiệm thu bằng dữ liệu thật |
| Quyền hạn từng vai trò chỉ ghi "admin và user" | Làm hai vai trò, các vai trò còn lại thành ngoại lệ | Khi khách thử với nhân sự thật |
| Dữ liệu cũ cần chuyển sang không được mô tả | Giả định dữ liệu sạch | Khi chạy thử chuyển đổi |
| Màn hình lỗi, trạng thái rỗng, định dạng file xuất ra | Làm theo mặc định của thư viện | Khi người dùng cuối phàn nàn |
| Từ "như hệ thống cũ" | Mỗi bên hiểu một kiểu | Cuối dự án |
Điểm chung: mọi chỗ trống đều được lấp ngay bằng một suy đoán hợp lý, nên không ai báo động. Chi phí xuất hiện về sau, dưới dạng làm lại và tranh cãi "cái này có trong yêu cầu không".
Văn hoá làm việc cũng góp phần. Ở Nhật, người nhận thông tin được kỳ vọng đặt mình vào vị trí người viết để suy nghĩ và diễn giải đầy đủ, nên đặc tả thường được viết ngắn. Đội ở nước khác thường làm đúng từng chữ. Không bên nào sai, nhưng khoảng cách giữa hai cách hiểu đó chính là phần đặc tả còn thiếu. Giới hạn kỹ thuật bị giấu đến phút chót cũng đi theo cùng quy luật, như trong bài về nói trước điều không làm.
3. Đổi nước hoặc thêm BrSE có giải quyết được không?
Đổi nước nhận việc hoặc thêm BrSE (Bridge System Engineer, kỹ sư cầu nối) không giải quyết được vấn đề đặc tả. Một đặc tả thiếu quyết định sẽ cho kết quả tệ ở bất kỳ nước nào, kể cả khi giao cho một công ty ở ngay trong nước.
BrSE giải quyết một việc khác: dịch ngôn ngữ và văn hoá làm việc. Họ giúp đặc tả được hiểu đúng. Họ không thể tạo ra quyết định chưa ai đưa ra. Hơn nữa, nếu mọi hiểu biết về nghiệp vụ nằm trong đầu một BrSE, thì khi người đó nghỉ việc, dự án mất luôn phần tri thức ấy. Cách VAON giảm rủi ro này (BrSE dẫn giai đoạn đầu, sau đó kỹ sư thiết kế trao đổi trực tiếp với khách, tri thức nằm ở đội và tài liệu) được trình bày riêng trong bài về offshore development không phụ thuộc BrSE.
4. Giai đoạn chốt đặc tả (仕様確定フェーズ) của VAON gồm những gì?
Giai đoạn chốt đặc tả (仕様確定フェーズ, Spec Lock Phase) là một giai đoạn riêng, có giá cố định, tạo ra đặc tả đủ chi tiết để báo giá phần xây dựng. VAON chạy giai đoạn này trước khi viết bất kỳ dòng code nào.
| Hạng mục | Nội dung |
|---|---|
| Thời gian | 1 đến 2 tuần; dự án lớn 2 đến 4 tuần |
| Giá | Cố định, báo trước, không phát sinh |
| Người dẫn | BrSE và Tech Lead |
| Đầu ra | Tài liệu yêu cầu (要件定義書), wireframe từng màn hình, thiết kế cơ sở dữ liệu, kiến trúc hệ thống, báo giá cố định cho giai đoạn xây dựng |
| Sau giai đoạn | Khách được dừng ở đây, không bắt buộc làm tiếp |
Có hai lối vào, tuỳ khách đang ở đâu.
Lối A: đã có hệ thống. VAON đọc code, phỏng vấn người vận hành, đo lường hệ thống đang chạy. Mục tiêu là biết hệ thống thực sự làm gì, không phải làm theo tài liệu cũ.
Lối B: chưa có gì. VAON phỏng vấn nghiệp vụ, vẽ từng màn hình cùng khách, thiết kế dữ liệu. Phần lớn quyết định bị thiếu lộ ra ở bước vẽ màn hình, vì không thể vẽ một nút bấm mà không biết nó làm gì.
Quyền được dừng là phần quan trọng. Giai đoạn này chỉ có giá trị nếu khách thực sự được tự do đánh giá kết quả, không bị ràng buộc phải làm tiếp.
5. VAON đã làm gì với Seminar Navi của Đại học Công nghệ Kochi?
Với Seminar Navi cho 高知工科大学 (Đại học Công nghệ Kochi), VAON làm cùng nhà trường từ khâu sắp xếp yêu cầu đến vận hành. Hệ thống gồm ứng dụng LINE (LIFF), PWA và màn hình quản trị, mất khoảng 5 tuần từ yêu cầu đến vận hành, chính thức từ ngày 01/10/2026.
Hai ví dụ về loại quyết định phải có trên giấy trước khi viết code: sinh viên bắt đầu dùng sau 4 bước, khoảng 1 phút; hệ thống không thu họ tên; việc gợi ý hoạt động bằng luật, không dùng AI tạo sinh. Mỗi quyết định như vậy nghe nhỏ, nhưng đổi nó sau khi xây xong là sửa lại cả luồng màn hình, dữ liệu và cách báo cáo.
Chúng tôi chưa công bố số liệu về mức sử dụng của hệ thống, nên bài này không đưa ra.
6. Khi nào giai đoạn chốt đặc tả chưa phải thứ bạn cần?
Giai đoạn chốt đặc tả chưa cần thiết khi việc cần làm nhỏ và rõ: sửa một màn hình, thêm một báo cáo, sửa lỗi. Với những việc này, một trao đổi ngắn và báo giá là đủ.
Ba giới hạn khác cần biết:
- Không có người nghiệp vụ thì không chốt được. Giai đoạn này cần người hiểu quy trình thật tham gia phỏng vấn. Nếu chưa ai trong công ty bạn nắm được quy trình, việc đầu tiên là tìm ra người đó.
- Đặc tả từ code (lối A) có giới hạn. Đọc code cho biết hệ thống đang làm gì, không cho biết vì sao. Quy tắc đã chết, thao tác tay ngoài hệ thống, dữ liệu master, cấu hình môi trường thật và hệ thống bên thứ ba không nằm trong code. Bug lâu năm có thể bị ghi nhầm thành quy định. Vì vậy mọi mục phải được đối chiếu với người dùng nghiệp vụ.
- Chốt đặc tả không có nghĩa là không bao giờ đổi. Yêu cầu vẫn sẽ thay đổi. Điều khác là mỗi thay đổi đi qua một quy trình bằng văn bản, nội dung này nằm trong bài về cách nhận biết công ty phần mềm không phát sinh chi phí ngoài thoả thuận.
Ngoài ra, nếu bạn cần một đội lớn bắt đầu code ngay trong vài ngày, giai đoạn này sẽ làm chậm điểm xuất phát, và có thể VAON không phải lựa chọn phù hợp.
7. Năm câu nên hỏi bất kỳ công ty offshore nào trước khi ký
Bạn có thể hỏi năm câu sau cả khi không chọn VAON. Câu trả lời mơ hồ cho thấy đặc tả sẽ là chỗ rủi ro.
- Trước khi báo giá xây dựng, các bạn tạo ra tài liệu gì, và tôi có được giữ nó nếu dừng lại không?
- Ai trong đội sẽ hỏi tôi về ngoại lệ nghiệp vụ, và hỏi theo cách nào (phỏng vấn, wireframe, mẫu dữ liệu thật)?
- Báo giá này dựa trên tài liệu nào? Nếu tài liệu chưa có, giá dựa trên giả định gì?
- Khi tôi muốn đổi yêu cầu giữa chừng, tôi nhận được gì bằng văn bản trước khi việc bắt đầu?
- Nếu người đầu mối nghỉ việc, ai tiếp tục và tri thức nằm ở đâu?
Để thấy các chỗ trống cụ thể trong một dự án sắp làm, bạn có thể bắt đầu từ bài về thời gian, chi phí và cách soạn tài liệu yêu cầu. Nếu bạn sắp thuê ngoài một dự án có dùng AI để viết code, xem thêm 12 câu hỏi cần kiểm tra trước khi thuê ngoài phát triển bằng AI.
8. Câu hỏi thường gặp
Chưa có đặc tả gì cả, có thể nhờ VAON làm không? Có. Đó là lối B của giai đoạn chốt đặc tả. VAON phỏng vấn nghiệp vụ, vẽ màn hình cùng bạn và thiết kế dữ liệu. Bạn không cần chuẩn bị tài liệu trước, chỉ cần có người hiểu quy trình thật tham gia các buổi trao đổi.
Hệ thống đã chạy nhiều năm mà không còn tài liệu thì sao? Đó là lối A. VAON đọc code, phỏng vấn người vận hành và đo lường hệ thống để dựng đặc tả hiện trạng. Kết quả được đối chiếu với người dùng nghiệp vụ từng mục, vì code không cho biết lý do của các quy tắc.
Sau giai đoạn chốt đặc tả tôi có bắt buộc làm tiếp với VAON không? Không. Khách được dừng sau giai đoạn này. Bạn nhận tài liệu yêu cầu, wireframe, thiết kế cơ sở dữ liệu, kiến trúc và báo giá cố định cho giai đoạn xây dựng, rồi tự quyết định có làm tiếp hay không.
Giai đoạn chốt đặc tả có làm dự án đắt hơn không? Đây là một khoản chi riêng, giá cố định báo trước. Đổi lại, báo giá xây dựng dựa trên tài liệu cụ thể thay vì giả định. VAON không có số liệu để so sánh với chi phí làm lại do thiếu đặc tả.
Bạn đang chuẩn bị giao một dự án cho đội offshore? Hãy mang các câu hỏi ở mục 7 vào buổi đầu. Buổi trao đổi đầu tiên của VAON kéo dài 60 phút, có CEO tham dự, không cần chuẩn bị tài liệu và không ràng buộc. Đặt lịch trao đổi 60 phút miễn phí
Tác giả: Đặng Văn Luân, Founder & CEO, VAON. Tốt nghiệp HEDSPI (Đại học Bách khoa Hà Nội), từng làm tại FPT Software, 5 năm tại Digital Plus (Tokyo) với hệ thống 10 triệu người dùng, 8 năm làm COO một công ty ITO 120 nhân sự và xây hệ thống quản lý theo ISO 9001, ISO 27001. 15 năm làm nghề.
Tài liệu tham khảo
- オフショア開発白書 2025年版, Offshore Kaihatsu: https://www.offshore-kaihatsu.com/offshore_hakusho_2025/ (trang giới thiệu, kiểm tra 17/10/2026)
