Bạn đang gặp vấn đề gì khi chọn đối tác phát triển phần mềm?
Nếu bạn đang đọc trang này, nhiều khả năng bạn đã từng nhận một hệ thống chạy đúng đặc tả nhưng không tạo ra kết quả. Đây là tình huống phổ biến, và nguyên nhân thường không nằm ở năng lực lập trình.
Ba dạng thất bại lặp lại trong các dự án thuê ngoài:
- Đúng thuật toán, sai thao tác. Hệ thống tính chính xác, nhưng một nghiệp vụ vốn mất 3 bước nay mất 8 bước. Nhân viên quay lại dùng Excel.
- Đúng đặc tả, sai dữ liệu thật. Đặc tả viết trên dữ liệu mẫu sạch. Dữ liệu production có trường trống, mã trùng, ký tự đặc biệt — luồng xử lý vỡ trong tuần đầu.
- Đúng tính năng, sai mục đích. Khách yêu cầu nút xuất Excel. Mục đích thật là báo cáo gửi hội sở mỗi sáng thứ Hai. Nút được làm đúng, việc làm báo cáo vẫn mất cả buổi.
Cả ba trường hợp đều có biên bản nghiệm thu sạch. Cả ba đều là dự án thất bại. Chúng tôi đã phân tích chi tiết bốn chỉ số nên dùng để đo chất lượng phần mềm sau bàn giao trong một bài riêng.
Khi chọn cách triển khai, bạn đang cân nhắc giữa các lựa chọn sau:
| Lựa chọn | Ưu điểm | Hạn chế |
|---|---|---|
| Tuyển in-house tại Nhật | Kiểm soát cao, hiểu nghiệp vụ | Chi phí nhân sự cao, thời gian tuyển dài |
| Outsource nội địa Nhật | Giao tiếp không rào cản | Chi phí cao nhất trong các lựa chọn |
| Freelancer | Chi phí thấp, khởi động nhanh | Chất lượng không ổn định, rủi ro bỏ ngang giữa dự án |
| Offshore không có người điều phối | Chi phí thấp | Sai lệch yêu cầu, khối lượng rework lớn |
| Offshore có kiểm soát + BrSE thường trú | Cân bằng chi phí và chất lượng, một đầu mối chịu trách nhiệm | Cần tiêu chí nghiệm thu và nhịp báo cáo rõ ràng ngay từ đầu |
VAON hoạt động theo mô hình cuối cùng. Bạn có thể xem đội ngũ và cách VAON làm việc với khách hàng Nhật trước khi đọc tiếp.
VAON cung cấp những gì trong dịch vụ trọn gói?
VAON nhận trách nhiệm từ giai đoạn làm rõ mục tiêu kinh doanh đến giai đoạn cải tiến sau khi hệ thống đã chạy thật. Bạn làm việc với một đầu mối duy nhất thay vì điều phối nhiều nhà cung cấp.
Phạm vi dịch vụ ánh xạ trực tiếp với các hạn chế ở bảng trên:
| Hạng mục | Nội dung |
|---|---|
| Tư vấn & làm rõ mục tiêu | Xác định chỉ số cần cải thiện trước khi chốt danh sách tính năng |
| Thiết kế UI/UX | Thiết kế trên luồng nghiệp vụ thật, không thiết kế trên đặc tả giấy |
| Phát triển | Web, mobile, hệ thống nội bộ, tích hợp AI |
| Kiểm thử hai lớp | Kiểm thử kỹ thuật (unit/integration) + kiểm thử trải nghiệm sử dụng |
| BrSE (Bridge System Engineer) | Người thông dịch nghiệp vụ giữa khách hàng Nhật và đội phát triển |
| Vận hành & cải tiến sau release | Theo dõi chỉ số sử dụng, đề xuất và thực thi điều chỉnh |
Điểm cần nói rõ: VAON cam kết đo và báo cáo kết quả sử dụng, không cam kết một con số ROI cụ thể. Lý do đơn giản — ROI phụ thuộc cả vào biến số marketing, vận hành và thị trường nằm ngoài phạm vi kiểm soát của một đối tác kỹ thuật. Nhà cung cấp cam kết ROI bằng hợp đồng là nhà cung cấp đang bán một thứ họ không kiểm soát được.
VAON làm việc theo quy trình nào, mất bao lâu mỗi bước?
Quy trình gồm năm bước. Thời gian dưới đây là khoảng điển hình cho một hệ thống quy mô vừa; dự án phức tạp hơn sẽ dài hơn và được nêu rõ trong đề xuất.
- Audit hiện trạng — 3–5 ngày làm việc. Rà soát hệ thống hiện có, dữ liệu sẵn có, và tiêu chí nghiệm thu đang dùng. Kết quả là một báo cáo ngắn, miễn phí, không ràng buộc hợp đồng.
- Làm rõ mục tiêu & ước lượng — 1–2 tuần. Xác định chỉ số cần cải thiện, phạm vi tối thiểu để đạt chỉ số đó, ước lượng nhân lực và thời gian.
- Thiết kế & chốt tiêu chí nghiệm thu — 2–4 tuần. Thiết kế UI/UX trên luồng nghiệp vụ thật. Tiêu chí nghiệm thu do hai bên cùng viết, bao gồm cả chỉ số đo sau release.
- Phát triển theo sprint 2 tuần. Mỗi sprint có bản chạy được để bạn xem. Báo cáo tiến độ hàng tuần bằng tiếng Nhật hoặc tiếng Anh qua BrSE.
- Go-live & cải tiến — vòng cải tiến đầu tiên nằm trong hợp đồng. Số giờ giới hạn được ghi rõ từ đầu để hai bên không phải tranh luận về ranh giới khi phát sinh.
Ngôn ngữ làm việc: tiếng Nhật (qua BrSE) hoặc tiếng Anh. Nhịp báo cáo: hàng tuần, cộng một buổi review cuối mỗi sprint.
Xử lý thay đổi yêu cầu: thay đổi trong sprint đang chạy được đưa vào backlog sprint kế tiếp, kèm ước lượng tác động lên tiến độ trước khi bạn quyết định. VAON không từ chối thay đổi bằng lý do "không có trong đặc tả", nhưng cũng không nhận thay đổi mà không ước lượng lại.
Ba lớp kiểm soát chất lượng
| Lớp | Ai thực hiện | Bắt loại lỗi nào |
|---|---|---|
| 1. Tự kiểm theo tiêu chí nghiệm thu | Lập trình viên phụ trách | Sai lệch so với tiêu chí đã thống nhất |
| 2. Kiểm chéo | Đồng nghiệp không tham gia phần đó | Lỗi logic, trùng lặp, thiếu xử lý ngoại lệ |
| 3. Nghiệm thu theo góc nhìn nghiệp vụ | BrSE | Code đúng nhưng nghiệp vụ sai |
Lớp thứ ba là lớp quyết định, và cũng là lớp mà phần lớn mô hình thuê ngoài bỏ qua — nó đòi hỏi người hiểu cả nghiệp vụ lẫn kỹ thuật.
VAON đã làm được gì?
OneBot — hệ thống tự động hoá chăm sóc khách hàng. VAON phát triển OneBot theo đúng mô hình mô tả ở trên: làm rõ mục tiêu trước, thiết kế trên luồng xử lý yêu cầu thật của bộ phận chăm sóc khách hàng, và tiếp tục theo dõi dữ liệu sử dụng sau khi hệ thống chạy thật.
Tại một doanh nghiệp cung cấp dịch vụ hỗ trợ vận hành chuỗi cửa hàng, khoảng 60% câu hỏi lặp lại đã được chuyển sang trả lời tự động. Phần còn lại vẫn do nhân viên xử lý, và đội chăm sóc khách hàng tập trung được vào những yêu cầu thật sự cần người trả lời.
Đội ngũ
VAON vận hành một đội 15 người với đủ vai trò để nhận trọn vòng đời, không thuê ngoài phần nào:
| Vai trò | Ghi chú |
|---|---|
| BrSE (Bridge System Engineer) / PM | 2 BrSE, đều trên 10 năm kinh nghiệm làm việc với khách hàng Nhật |
| Technical Leader | Chịu trách nhiệm kiến trúc và lớp kiểm chéo |
| Fullstack Developer | Web và hệ thống nội bộ |
| Mobile Developer | Ứng dụng iOS / Android |
| Designer | UI/UX trên luồng nghiệp vụ thật |
| QA | Kiểm thử kỹ thuật và kiểm thử trải nghiệm sử dụng |
Quy mô 15 người là con số có chủ đích. Đội đủ nhỏ để hai BrSE nắm được bối cảnh của mọi dự án đang chạy, và đủ lớn để không phải thuê ngoài vai trò nào trong vòng đời phát triển.
Chi phí được tính như thế nào?
VAON không áp một bảng giá cố định. Chi phí được xây dựng ngược từ ngân sách và mục tiêu của bạn: xác định chỉ số cần cải thiện trước, rồi xác định phạm vi nhỏ nhất tạo ra được chỉ số đó trong ngân sách hiện có.
Cách làm này có nghĩa là ngân sách quyết định phạm vi, không quyết định quy trình kiểm soát chất lượng. Một dự án nhỏ vẫn đi qua đủ ba lớp kiểm soát và vẫn có vòng cải tiến sau release; thứ thay đổi là số lượng nghiệp vụ được đưa vào phạm vi.
Ba yếu tố quyết định chi phí:
| Yếu tố | Ảnh hưởng thế nào |
|---|---|
| Phạm vi nghiệp vụ | Số luồng nghiệp vụ cần số hoá — yếu tố tác động lớn nhất |
| Thành phần đội | Dự án cần mobile, AI hoặc tích hợp hệ thống cũ sẽ cần thêm vai trò |
| Thời gian cam kết | Cam kết dài hạn cho đơn giá theo tháng thấp hơn so với thuê theo đợt ngắn |
Hai mô hình tính phí:
| Mô hình | Phù hợp với | Cách tính |
|---|---|---|
| Dedicated Team | Doanh nghiệp có lộ trình sản phẩm dài hạn, cần đội ổn định | Đơn giá theo kỹ sư / tháng, cam kết theo quý hoặc năm |
| Dự án trọn gói | Hệ thống có phạm vi xác định, bàn giao theo mốc | Báo giá một lần cho toàn bộ vòng đời, gồm cả vòng cải tiến đầu tiên |
Buổi Audit hiện trạng miễn phí và trả về một ước lượng dựa trên hiện trạng cụ thể của bạn, không phải một con số chung.
Khi nào VAON không phải lựa chọn phù hợp?
Ba trường hợp bạn nên chọn phương án khác:
- Cần bắt đầu trong vòng một tuần. Quy trình làm rõ mục tiêu và chốt tiêu chí nghiệm thu mất tối thiểu 3–6 tuần trước khi viết dòng code đầu tiên. Nếu bạn cần người bắt tay vào code ngay, freelancer hoặc staff augmentation phù hợp hơn.
- Bạn chỉ cần bổ sung lập trình viên vào đội sẵn có. Nếu bạn đã có PM, có quy trình riêng và chỉ thiếu người viết code, mô hình staff augmentation thuần sẽ rẻ hơn. Vai trò BrSE và lớp nghiệm thu nghiệp vụ của VAON sẽ trùng lặp với những gì đội bạn đang làm.
- Không thể cấp quyền truy cập log hoặc tiếp cận người dùng cuối. Không có dữ liệu sử dụng thì mọi chỉ số sau release đều là ước đoán, và phần giá trị khác biệt của mô hình này không phát huy được.
Nói rõ giới hạn rẻ hơn nhiều so với phát hiện sự không phù hợp ở tháng thứ ba.
Bước tiếp theo
Nếu bạn đang vận hành một hệ thống chưa rõ tạo ra kết quả gì, hoặc đang chọn đối tác cho một dự án sắp khởi động, bước hợp lý là đánh giá hiện trạng trước khi cam kết ngân sách.
Buổi Audit của VAON kéo dài 3–5 ngày làm việc và trả về một báo cáo ngắn: tiêu chí nghiệm thu đang dùng có lỗ hổng nào, chỉ số nào đo được ngay với dữ liệu sẵn có, và cần bổ sung ghi log ở đâu trước khi triển khai giai đoạn tiếp theo. Không kèm ràng buộc hợp đồng.
Đăng ký buổi Audit miễn phí · sales@ai.vaon.com.vn · vaon.com.vn/vi
Câu hỏi thường gặp
Ngân sách của chúng tôi có đủ không? VAON làm việc được với nhiều mức ngân sách khác nhau vì phạm vi được xây dựng ngược từ ngân sách, không phải ngược lại. Chúng tôi bắt đầu bằng câu hỏi bạn cần cải thiện chỉ số nào, rồi xác định phạm vi nhỏ nhất đạt được chỉ số đó trong ngân sách hiện có. Quy trình kiểm soát chất lượng giữ nguyên ở mọi quy mô dự án.
Rào cản ngôn ngữ được xử lý thế nào? BrSE (Bridge System Engineer) thường trú làm việc trực tiếp bằng tiếng Nhật với phía bạn và chuyển thành yêu cầu kỹ thuật cho đội phát triển. Báo cáo tiến độ hàng tuần và biên bản review sprint đều bằng tiếng Nhật. Bạn không cần trao đổi trực tiếp bằng tiếng Anh với lập trình viên.
Chất lượng code được đảm bảo bằng gì? Ba lớp kiểm soát: tự kiểm theo tiêu chí nghiệm thu, kiểm chéo giữa lập trình viên, và nghiệm thu theo góc nhìn nghiệp vụ do BrSE thực hiện. Ngoài ra VAON theo dõi tỷ lệ lỗi lọt production và trình bày số liệu này trong buổi review định kỳ, kể cả khi số liệu không tốt.
Nếu dự án không đạt tiêu chí nghiệm thu thì sao? Sai lệch so với tiêu chí nghiệm thu đã ký thuộc phạm vi bảo hành, do VAON chịu chi phí. Trường hợp đặc tả đúng nhưng thực tế sử dụng cho thấy cần thay đổi thiết kế thì thuộc phạm vi cải tiến — vòng cải tiến đầu tiên đã nằm trong hợp đồng với số giờ ghi rõ. Hai phạm vi này được tách bạch từ khi ký, không đàm phán khi phát sinh. Xem thêm cách phân biệt bảo hành và cải tiến sau release.
Quyền sở hữu trí tuệ thuộc về ai? Toàn bộ mã nguồn và tài sản trí tuệ thuộc về khách hàng khi hoàn tất thanh toán theo hợp đồng. Điều khoản này được ghi trong hợp đồng, không phụ thuộc vào việc bạn có tiếp tục sử dụng dịch vụ vận hành của VAON hay không.
Sau buổi Audit có bắt buộc sử dụng dịch vụ không? Không. Buổi Audit trả về một báo cáo hiện trạng độc lập và bạn có thể dùng báo cáo đó với bất kỳ nhà cung cấp nào, kể cả đội in-house của bạn. Đây là cách VAON tự đánh giá mức độ phù hợp trước khi cả hai bên bỏ thời gian vào đàm phán hợp đồng.
Mất bao lâu để bắt đầu? Audit 3–5 ngày làm việc, làm rõ mục tiêu và ước lượng 1–2 tuần, thiết kế và chốt tiêu chí nghiệm thu 2–4 tuần. Sprint phát triển đầu tiên thường bắt đầu sau 4–7 tuần kể từ buổi Audit, tuỳ độ phức tạp của hệ thống.
