Vì sao giới hạn kỹ thuật thường chỉ lộ ra sát ngày bàn giao?
Giới hạn kỹ thuật thường lộ ra muộn vì không ai có động lực nói ra nó lúc bán hàng. Hồ sơ đề xuất và hợp đồng tập trung vào tính năng và tiến độ. Phần "hệ thống sẽ không làm được gì" hiếm khi có một mục riêng.
Phía nhà thầu, nói ra giới hạn nghe như tự làm yếu đề xuất của mình, nhất là khi đối thủ đang hứa "làm được hết". Phía khách hàng, nếu không biết hỏi gì, thì cũng không có gì để đối chiếu. Kết quả là một khoảng im lặng mà hai bên đều ngầm chấp nhận, với câu trấn an quen thuộc: "Cứ triển khai đi, vận hành rồi tính."
Khoảng im lặng đó thường vỡ ra theo ba cách:
- Đội chi phí sát ngày ra mắt: cuối dự án mới phát hiện cấu trúc database không đáp ứng được tải thật, phải thiết kế lại phần lõi.
- Sự cố khi vào vận hành: ngưỡng chịu tải chưa từng được đo, hệ thống quá tải đúng ngày chạy chiến dịch lớn.
- AI chatbot trả lời sai (hallucination, tức AI "bịa" câu trả lời): phạm vi dữ liệu AI được phép trả lời chưa được khoanh vùng, khách hàng thật nhận thông tin sai.
Giới hạn bị giữ im lặng gây thiệt hại cho ai?
Một giới hạn kỹ thuật không được nói ra từ đầu gây thiệt hại cho cả ba bên trong chuỗi hợp tác, không chỉ khách hàng.
Lý do nhiều nhà thầu ngại nói ra giới hạn thường có hai phần: sợ mất hợp đồng vào tay đối thủ, và chưa đủ năng lực phân tích kiến trúc để tự nhìn ra giới hạn từ sớm. Phần thứ hai nguy hiểm hơn, vì khi đó nhà thầu không giấu, mà thật sự chưa biết.
5 câu hỏi buộc giới hạn kỹ thuật lộ ra trước khi ký
Cách chắc chắn nhất để thấy giới hạn kỹ thuật là hỏi thẳng, bằng câu hỏi có thể kiểm chứng. Năm câu dưới đây dùng được với bất kỳ nhà thầu nào, kể cả VAON.
- “Phần nào trong đề xuất đã chạy thật ở dự án trước, phần nào cần làm PoC?”
Câu trả lời tốt chia rõ hai nhóm. PoC (Proof of Concept, kiểm thử tính khả thi) là bước chạy thử trên hạ tầng của bạn trước khi triển khai rộng. Dấu hiệu cần cẩn trọng: mọi hạng mục đều "làm được", không hạng mục nào cần kiểm thử. - “Hệ thống chịu được tải bao nhiêu, và con số đó được đo bằng cách nào?”
Câu trả lời tốt có con số, có điều kiện đo và có mốc thời gian. Dấu hiệu cần cẩn trọng: "hệ thống chịu tải tốt" mà không có số, hoặc có số mà không nói đo trong điều kiện nào. - “AI sẽ từ chối trả lời trong những trường hợp nào?”
Câu hỏi này dành cho mọi dự án có chatbot hoặc RAG (Retrieval-Augmented Generation, AI trả lời dựa trên kho tài liệu được chỉ định). Câu trả lời tốt nêu được phạm vi dữ liệu và điều kiện AI phải nói "không có thông tin". Dấu hiệu cần cẩn trọng: "AI trả lời được mọi câu hỏi". - “Phần nào của hệ thống hiện tại sẽ không bị đụng tới?”
Với dự án nâng cấp hệ thống cũ, câu trả lời tốt liệt kê rõ vùng không can thiệp, ví dụ database lõi. Dấu hiệu cần cẩn trọng: đề xuất viết lại toàn bộ mà không đánh giá rủi ro chuyển đổi. - “Nếu lỗi nằm ở chính tài liệu đặc tả, ai trả tiền sửa?”
Câu trả lời tốt tách rõ lỗi đặc tả của nhà thầu với thay đổi yêu cầu của khách, và ghi điều đó vào hợp đồng. Dấu hiệu cần cẩn trọng: mọi phát sinh đều tính vào khách.
Nếu một nhà thầu trả lời được cả năm câu bằng văn bản, bạn đã có trong tay thứ quan trọng hơn bản đề xuất: một bản giới hạn kỹ thuật.
Một bản giới hạn kỹ thuật thật trông như thế nào?
Một bản giới hạn kỹ thuật tốt ngắn, cụ thể và kiểm chứng được. Ví dụ dưới đây là phần giới hạn VAON công bố cho service OCR trích xuất mã định danh đa ngôn ngữ do chính VAON phát triển (2026).
Service này có 54 test tự động: 42 unit test và 12 integration test chạy trên model thật. Trong quá trình phát triển, một route mới bị phát hiện chưa áp giới hạn dung lượng upload. Lỗi được vá trước khi release, và file 11MB hiện bị từ chối đúng như thiết kế. Ba giới hạn được ghi lại nguyên trạng:
Bản giới hạn này không làm service kém giá trị đi. Nó cho người dùng biết chính xác được dùng service ở đâu, và phải bổ sung gì trước khi dùng ở chỗ khác. Chi tiết nằm trong case study OCR trích xuất mã định danh đa ngôn ngữ.
VAON đưa giới hạn vào tài liệu dự án ra sao?
VAON viết Bản Phân Tích Giới Hạn Kỹ Thuật song song với danh sách tính năng, ngay từ giai đoạn tư vấn. Ba nguyên tắc dưới đây quyết định nội dung của bản đó.
Nguyên tắc 1: Tách "vùng đã kiểm chứng" và "vùng cần PoC".
VAON không dùng câu "chắc chắn làm được" một cách cảm tính. Hạng mục nào đã chạy thật ở dự án trước được ghi riêng. Hạng mục nào phụ thuộc hạ tầng riêng của khách được ghi là cần PoC, kèm kế hoạch kiểm thử.
Nguyên tắc 2: Khoanh vùng dữ liệu và điều kiện từ chối cho AI chatbot ONEBOT.
Khi triển khai ONEBOT, VAON xác định phạm vi tài liệu RAG được phép dùng, và điều kiện để AI trả lời "không có thông tin" thay vì đoán. Cách này giảm mạnh rủi ro trả lời sai, nhưng không có hệ thống AI nào loại bỏ được hoàn toàn rủi ro đó. Vì vậy VAON cũng nói rõ phần rủi ro còn lại. Trong dự án OCR tiếng Việt cho ONEBOT, độ chính xác trích xuất tăng từ 70% lên mức không còn lỗi trên tập dữ liệu đã kiểm thử, và bài viết đó ghi rõ con số này không áp dụng cho mọi loại tài liệu.
Nguyên tắc 3: Tuyên bố "vùng không can thiệp" khi nâng cấp hệ thống cũ.
Với hệ thống cũ (legacy system), VAON áp dụng mô hình Strangler Fig: xây phần mới bao quanh phần cũ thay vì đập bỏ. Trong dự án hiện đại hoá CMS 20 năm tuổi, VAON cam kết từ đầu không đụng vào database đã chạy ổn định. Dự án hoàn thành trong 4 tháng, không có thời gian dừng hệ thống. Kết quả này gắn với quy mô của dự án đó, không phải con số mặc định cho mọi dự án.
Ba nguyên tắc trên nằm trong giai đoạn Chốt Đặc tả (Spec Lock Phase) của VAON. Cách VAON chia trách nhiệm khi lỗi nằm ở đặc tả được trình bày trong bài Nói trước điều không làm.
Minh bạch giới hạn không giải quyết được gì?
Minh bạch giới hạn kỹ thuật giảm rủi ro bất ngờ, nhưng không xoá được mọi rủi ro. Có ba điều bạn nên biết trước.
- Bản giới hạn chỉ đúng bằng thông tin đầu vào. Nếu một quy tắc nghiệp vụ ngầm không được nêu ra trong giai đoạn tư vấn, bản giới hạn cũng không thể phản ánh nó.
- Vùng cần PoC vẫn là vùng chưa biết. Việc ghi rõ "cần PoC" giúp bạn biết rủi ro nằm ở đâu, nhưng kết quả PoC vẫn có thể cho thấy phương án ban đầu không khả thi.
- Năm câu hỏi ở mục 3 không thay thế thẩm định pháp lý và bảo mật. Với dự án có yêu cầu chứng chỉ bảo mật hoặc điều khoản tái ủy thác, bạn vẫn cần quy trình kiểm tra riêng.
Kết
Một nhà thầu nói trước giới hạn không yếu hơn một nhà thầu hứa làm được hết. Họ chỉ đang cho bạn thấy sớm hơn điều mà sớm muộn bạn cũng sẽ thấy.
Nếu bạn đang chuẩn bị một dự án phần mềm hoặc AI, hãy gửi cho VAON mô tả ngắn về hệ thống bạn định xây. Chúng tôi sẽ trả lời 5 câu hỏi ở trên cho chính trường hợp của bạn, bằng văn bản. Nếu bạn là Agency hoặc SIer đang tìm đối tác kỹ thuật cho mô hình OEM, chúng tôi cũng sẵn sàng trao đổi.
Gửi dự án của tôi để nhận bản giới hạn kỹ thuật: https://vaon.com.vn/vi/contact