Vì sao nhiều dự án phần mềm B2B vỡ trận ngay trước ngày ra mắt?
Khi đánh giá đối tác phát triển phần mềm, doanh nghiệp và các Agency/SIer thường nghe một câu quen thuộc: yêu cầu nào cũng làm được, tích hợp AI cũng làm được, ngân sách thấp và giao hàng nhanh cũng không thành vấn đề. Câu này nghe yên tâm lúc ký hợp đồng, nhưng lại là điểm khởi đầu của nhiều vụ vỡ trận.
Nguyên nhân không nằm ở ý xấu. Nhiều bên phát triển muốn giành hợp đồng, nên chưa kiểm tra kỹ giới hạn kỹ thuật đã nhận lời, với suy nghĩ "ký được hợp đồng trước, việc khó tính sau". Vấn đề là những giới hạn đó không biến mất, chúng chỉ xuất hiện muộn hơn, thường là vài tuần trước ngày ra mắt.
Ba tình huống hay gặp khi điều đó xảy ra: yêu cầu đồng bộ dữ liệu thời gian thực hoá ra không khả thi với cấu trúc database cũ của khách, ngân sách ban đầu đội lên 2 đến 3 lần vì "phát sinh kỹ thuật ngoài dự kiến", hoặc chatbot AI được hứa trả lời chính xác lại đưa thông tin sai cho khách hàng thật khi đã lên production.
Việc giấu giới hạn kỹ thuật gây thiệt hại cho ai?
Không nói rõ "cái gì không làm được" ngay từ đầu gây thiệt hại cho cả ba bên trong chuỗi hợp tác.
Doanh nghiệp đặt hàng nhận về hệ thống không dùng được, hoặc gặp sự cố ngay ngày chuyển đổi, sau khi đã bỏ ra ngân sách và thời gian không nhỏ. Agency hoặc SIer đứng giữa mất uy tín với khách hàng cuối, vì đã chọn một nhà thầu chưa lường trước rủi ro kỹ thuật. Còn chính đội phát triển thì rơi vào tình trạng làm việc quá sức để chạy theo lời hứa ban đầu, dễ dẫn đến bỏ dở dự án.
Sở dĩ nhiều bên phát triển ngại nói "không làm được", phần lớn vì lo mất hợp đồng vào tay đối thủ, và một phần vì chưa đủ năng lực thiết kế kiến trúc để nhận ra giới hạn kỹ thuật từ sớm. Đây không phải là chuyện của riêng một vài công ty, mà là một khuôn mẫu bán hàng khá phổ biến trong ngành.
Nguyên tắc của VAON: nói "không làm" trước khi ký hợp đồng
VAON đi theo hướng ngược lại. Chúng tôi xác định rõ "điều sẽ không làm" (ranh giới phạm vi) ngay từ giai đoạn tư vấn, trước khi bước vào hợp đồng.
Cách làm cụ thể là tách riêng một giai đoạn gọi là Chốt Đặc tả (Spec Lock Phase), kéo dài 2 đến 4 tuần tuỳ quy mô dự án, với giá cố định công bố trước. Kết thúc giai đoạn này, khách nhận được tài liệu đặc tả, thiết kế màn hình, thiết kế database và báo giá cố định cho giai đoạn phát triển.
Cam kết đi kèm là: nếu trong giai đoạn phát triển phát sinh việc phải làm lại, và nguyên nhân truy về được là lỗi hoặc thiếu sót trong chính tài liệu đặc tả do VAON viết, VAON chịu toàn bộ chi phí đó. Trường hợp khách đổi ý hoặc thay đổi yêu cầu sau khi đã chốt đặc tả thì tính riêng, theo quy trình thay đổi phạm vi bằng văn bản.
Case 1: OCR đa ngôn ngữ 132MB, không dùng GPU đám mây
Một khách hàng cần hệ thống đọc tài liệu (OCR) đa ngôn ngữ với độ chính xác cao cho dữ liệu tiếng Việt và tiếng Nhật. Cách làm phổ biến trên thị trường là triển khai mô hình AI cỡ lớn trên máy chủ GPU đám mây.
Trước khi bắt tay vào việc, VAON nói rõ hai điều sẽ không làm: không xây hệ thống phụ thuộc GPU đám mây, vì chi phí hạ tầng hàng tháng sẽ tăng dần theo khối lượng dữ liệu, và không cam kết độ chính xác tuyệt đối nếu thiếu bước tiền xử lý ảnh kỹ lưỡng.
Thay vào đó, VAON tinh chỉnh (fine-tune) một engine OCR riêng, chỉ 132MB, chạy hoàn toàn trên CPU tiêu chuẩn, trên hơn 500.000 mẫu ký tự tiếng Việt thực tế. Trong một dự án đã triển khai, cách làm này đưa độ chính xác trích xuất dữ liệu từ 70% lên mức không còn lỗi trên tập dữ liệu đã kiểm thử, đồng thời giảm 80% chi phí hạ tầng so với phương án dùng GPU cho cùng khối lượng. Toàn bộ dữ liệu xử lý trên hạ tầng nội bộ, không gửi qua API đám mây bên thứ ba, đáp ứng yêu cầu của Luật Bảo vệ Thông tin Cá nhân Nhật Bản (APPI).
Case 2: hiện đại hoá CMS 20 năm tuổi mà không đổi database
Một hệ thống CMS đã vận hành 20 năm, chứa hàng triệu trang nội dung, cần hiện đại hoá. Đề xuất thường gặp cho tình huống này là viết lại toàn bộ từ đầu, cả database lẫn ứng dụng, việc này thường mất 1 đến 2 năm và rủi ro downtime khi chuyển đổi là có thật.
VAON nói rõ ngay từ đầu hai điều sẽ không làm: không đụng vào database đã chạy ổn định suốt 20 năm, vì rủi ro đổ vỡ là quá lớn so với lợi ích, và không chấp nhận phương án khiến hệ thống dừng hoạt động dù chỉ một phút.
Giải pháp là áp dụng mô hình Strangler Fig: giữ nguyên 100% database và quy trình biên tập cũ, đồng thời xây một pipeline tự động sinh HTML tĩnh chạy nền và phân phối qua Edge CDN. Dự án hoàn thành trong 4 tháng, không có thời gian dừng hệ thống (zero downtime), tốc độ phản hồi trang (TTFB) dưới 50ms, giảm 66% thời gian phát triển so với cách làm viết lại toàn bộ, và giảm 70% chi phí hạ tầng máy chủ so với trước. Mức SLA 99.5% uptime là mức VAON áp dụng cho loại kiến trúc phân phối tĩnh này, không phải cam kết mặc định cho mọi dự án.
Nói trước giới hạn mang lại điều gì
Nói rõ "cái gì không làm" không phải là một cách từ chối khéo. Đó là một phần của việc quản lý phạm vi (scope engineering) làm giảm rủi ro thật.
Khi ranh giới kỹ thuật được chốt từ đầu, việc phát sinh chi phí và trễ tiến độ giữa chừng giảm hẳn, vì hai bên đã thống nhất trước điều gì nằm trong và ngoài phạm vi. Việc nêu rõ giới hạn của AI hay của database ngay từ đầu cũng giúp tránh những sự cố bất ngờ khi hệ thống đã lên production. Với các Agency hay SIer đang tìm đối tác kỹ thuật để làm việc dưới thương hiệu của mình, một đối tác nói rõ giới hạn giúp họ tự tin hơn khi trình bày với khách hàng cuối, thay vì phải bào chữa khi sự cố xảy ra.
Cách này chưa xử lý được gì
Cách làm trong bài không phải là công thức áp dụng cho mọi dự án, và có những giới hạn cần biết trước.
Con số 4 tháng và tỷ lệ cải thiện của case CMS gắn với quy mô và độ phức tạp cụ thể của dự án đó. Một CMS nhỏ hơn có thể hoàn thành nhanh hơn, còn một hệ thống có nhiều tích hợp nghiệp vụ nội bộ sâu có thể mất nhiều thời gian hơn. Tương tự, kết quả "không còn lỗi" của engine OCR được đo trên một tập dữ liệu đã kiểm thử cụ thể, không phải cam kết chính xác tuyệt đối cho mọi loại tài liệu hay mọi ngành. Bộ từ điển lọc lỗi dùng cho ngành tài chính bán lẻ cũng cần xây lại riêng nếu áp dụng cho ngành khác như y tế hay ngân hàng.
Việc VAON chịu chi phí rework khi lỗi do đặc tả cũng có ranh giới rõ trong hợp đồng: nếu khách thay đổi yêu cầu sau khi đã chốt đặc tả, hoặc điều kiện nghiệp vụ bên ngoài thay đổi (ví dụ luật hoặc API của bên thứ ba), phần phát sinh đó không nằm trong cam kết này.
Kết
Việc nói trước "sẽ không làm gì" không làm cho một đề xuất kém hấp dẫn hơn. Nó chỉ khiến đề xuất đó đúng với thực tế hơn, và giảm khả năng phải sửa chữa tốn kém về sau.
Nếu bạn đang cân nhắc một dự án phát triển hệ thống hoặc tích hợp AI và muốn biết trước những giới hạn kỹ thuật cụ thể cho trường hợp của mình, VAON có thể trao đổi và đưa ra đánh giá ban đầu. 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 về cách hai bên có thể làm việc cùng nhau.
Website: https://vaon.com.vn/vi