Cách nhận biết công ty phần mềm không phát sinh chi phí ẩn
Tóm tắt: Công ty phần mềm không gửi hoá đơn bất ngờ là công ty có quy trình quản lý thay đổi bằng văn bản: mọi việc ngoài phạm vi phải có yêu cầu thay đổi, báo giá và ảnh hưởng tiến độ bằng văn bản, rồi bạn duyệt mới làm. Bài này nêu bốn bước của quy trình, các điều khoản hợp đồng cần có và những dấu hiệu cảnh báo trong báo giá.
Mục lục
- Chi phí phát sinh trong dự án phần mềm đến từ đâu?
- Quy trình quản lý thay đổi bằng văn bản gồm những bước nào?
- Hợp đồng cần viết gì để quy trình đó có hiệu lực?
- Dấu hiệu cảnh báo nào trong báo giá cho thấy phí phát sinh sắp đến?
- VAON xử lý thay đổi phạm vi như thế nào?
- Quy trình này không giải quyết được gì?
- Câu hỏi thường gặp
1. Chi phí phát sinh trong dự án phần mềm đến từ đâu?
Chi phí phát sinh trong dự án phần mềm thường đến từ một chỗ: ranh giới giữa "nằm trong phạm vi" và "là thay đổi" chưa được viết ra. Khi ranh giới đó chỉ tồn tại trong đầu mỗi bên, hoá đơn cuối dự án là lúc hai cách hiểu va nhau.
Có ba nguồn quen thuộc. Thứ nhất, bạn thật sự đổi yêu cầu: thêm tính năng, đổi quy trình sau khi đã chốt. Thứ hai, yêu cầu vốn có nhưng ghi mơ hồ, và bên nhận việc coi phần chưa rõ là "ngoài phạm vi". Thứ ba, một việc được nhờ qua chat hay trong cuộc họp, được làm luôn, rồi xuất hiện trên hoá đơn như một dòng riêng.
Nguồn thứ nhất là chuyện bình thường của mọi dự án. Hai nguồn sau là chuyện của giấy tờ. Nguồn thứ hai bắt đầu từ trước khi ký hợp đồng, từ chất lượng của đặc tả, như trình bày trong bài về lý do thật sự khiến offshore development thất bại.
2. Quy trình quản lý thay đổi bằng văn bản gồm những bước nào?
Quy trình quản lý thay đổi (変更管理, change control) gồm bốn bước, và bước nào cũng phải để lại giấy tờ.
- Lập yêu cầu thay đổi. Mọi việc ngoài phạm vi đã chốt được ghi thành một phiếu yêu cầu thay đổi (変更依頼書), do bạn hoặc bên phát triển lập.
- Báo giá và ảnh hưởng tiến độ bằng văn bản. Bên phát triển nêu chi phí và việc ngày bàn giao có dịch chuyển hay không, kể cả ảnh hưởng đến các hạng mục khác.
- Bạn duyệt bằng văn bản. Người có thẩm quyền phía bạn xác nhận trước khi bất kỳ ai bắt tay vào làm.
- Làm việc. Chỉ sau bước 3.
Hệ quả của bước 3 là một nguyên tắc ngắn: không duyệt thì không làm, không làm thì không tính tiền. Bạn có thể từ chối một thay đổi sau khi thấy giá, và dự án tiếp tục với phạm vi cũ.
Bốn bước này không phải sáng kiến riêng của ai. Hợp đồng mẫu do Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản (METI) và IPA công bố, 「情報システム・モデル取引・契約書」, có điều khoản về quy trình quản lý thay đổi (ở bản thứ nhất là điều 37). Tài liệu này nêu rõ rằng quy trình đó là nơi hai bên bàn về việc làm lại cần thiết và phần chi phí tương ứng. Mẫu này viết cho phát triển theo mô hình thác nước ở hệ thống quan trọng, nên không phải dự án nào cũng áp nguyên văn, nhưng nó cho thấy đây là thực hành được chuẩn hoá.
3. Hợp đồng cần viết gì để quy trình đó có hiệu lực?
Hợp đồng cần viết rõ những điều dưới đây, vì quy trình chỉ nói miệng thì sẽ bị bỏ qua khi đến hạn.
| Điều khoản | Nên có | Vì sao |
|---|---|---|
| Định nghĩa phạm vi | Tham chiếu tài liệu yêu cầu cụ thể (số phiên bản, ngày), không viết "các chức năng cần thiết" | Không có điểm tham chiếu thì không phân biệt được thay đổi và yêu cầu gốc |
| Người được lập và duyệt thay đổi | Ghi chức danh của mỗi bên | Tránh việc đồng ý lẻ qua chat bởi người không có quyền |
| Nội dung phiếu thay đổi | Mô tả, chi phí, ảnh hưởng tiến độ, ảnh hưởng hạng mục khác | Bạn quyết định có đủ thông tin |
| Thời hạn báo giá | Số ngày làm việc tối đa bên phát triển trả lời | Tránh chờ lâu rồi bị ép đồng ý |
| Khi không duyệt | Phạm vi và giá cũ giữ nguyên | Quyền từ chối có thật |
| Phân biệt thay đổi và sửa lỗi | Lỗi của sản phẩm không đi qua quy trình thay đổi, theo điều khoản bảo hành | Tránh việc sửa lỗi bị tính như yêu cầu mới |
| Việc khẩn cấp | Quy định cách duyệt nhanh (ví dụ qua email có chức danh) | Quy trình không bị bỏ vì quá chậm |
Dòng "phân biệt thay đổi và sửa lỗi" đáng đọc kỹ nếu code có sự tham gia của AI. Trách nhiệm khi mã do AI viết có lỗi là một chủ đề riêng, xem trách nhiệm khi mã do AI viết phát sinh lỗi và cách ghi vào hợp đồng.
4. Dấu hiệu cảnh báo nào trong báo giá cho thấy phí phát sinh sắp đến?
Báo giá có thể báo hiệu phí phát sinh ngay từ trang đầu. Sáu dấu hiệu dưới đây là những chỗ nên hỏi lại.
| Dấu hiệu trong báo giá hoặc cuộc họp | Câu nên hỏi |
|---|---|
| Giá thấp hơn rõ rệt so với các báo giá khác, kèm câu "chi tiết sẽ tính sau" | Phần nào chưa nằm trong giá? |
| Giá cố định, nhưng chưa có tài liệu yêu cầu nào | Giá dựa trên tài liệu nào, hay trên giả định gì? |
| Phạm vi viết kiểu "bao gồm các chức năng cần thiết" | Danh sách chức năng cụ thể nằm ở đâu? |
| Không nhắc đến thay đổi, hoặc chỉ nói "sẽ trao đổi khi có" | Thay đổi được báo giá và duyệt như thế nào? |
| Đồng ý thay đổi qua chat hoặc điện thoại là đủ | Tôi nhận được gì bằng văn bản trước khi việc bắt đầu? |
| Báo giá thay đổi chỉ nêu tiền, không nêu ngày bàn giao | Thay đổi này đẩy lịch bàn giao bao nhiêu? |
Một câu trả lời trôi chảy nhưng không dẫn tới tài liệu nào cũng là tín hiệu. Cũng nên hỏi sớm về giới hạn kỹ thuật, vì giới hạn lộ muộn thường kéo theo thay đổi lớn. Chủ đề này có trong bài 5 câu hỏi về giới hạn kỹ thuật trước khi ký.
5. VAON xử lý thay đổi phạm vi như thế nào?
VAON xử lý thay đổi phạm vi theo đúng bốn bước ở mục 2: việc ngoài phạm vi được lập yêu cầu thay đổi, VAON báo giá và ảnh hưởng tiến độ bằng văn bản, bạn duyệt rồi mới làm. Không duyệt thì không làm và không tính tiền. Với khách Nhật, VAON diễn đạt điều này bằng một câu: 「ご承認いただいていない作業の請求書をお送りすることはありません。」 (Chúng tôi không gửi hoá đơn cho những việc bạn chưa duyệt.)
Quy trình này đứng trên hai nền khác. Nền thứ nhất là giai đoạn chốt đặc tả (仕様確定フェーズ), nơi yêu cầu được viết thành tài liệu và giai đoạn xây dựng được báo giá cố định trước khi bắt đầu, để "phạm vi" có điểm tham chiếu cụ thể. Nền thứ hai là cách làm việc hằng ngày với khách. Dự án đi theo từng phần ngắn một đến hai tuần, mỗi phần có thứ chạy được để bạn xem. Báo cáo hằng tuần có mục "việc cần khách quyết", nên nhu cầu thay đổi thường lộ ra sớm, khi sửa còn rẻ, thay vì dồn đến cuối dự án.
Khi bạn cho biết khoảng ngân sách, VAON đưa hai phương án: một vừa ngân sách, một mở rộng hơn. Bạn so sánh được trước khi chọn, thay vì nhận thêm hạng mục giữa chừng.
6. Quy trình này không giải quyết được gì?
Quy trình quản lý thay đổi không loại bỏ chi phí của thay đổi. Một thay đổi hợp lý vẫn tốn tiền và thời gian, chỉ là bạn biết con số trước khi đồng ý. Nếu ngân sách không có chỗ cho bất kỳ thay đổi nào, vấn đề nằm ở kế hoạch, không phải ở quy trình.
Một số giới hạn khác:
- Quy trình tốn thời gian của bạn. Mỗi phiếu cần có người có thẩm quyền đọc và duyệt. Nếu người đó vắng thường xuyên, hãy thoả thuận người thay thế ngay từ đầu.
- Nó không thay cho đặc tả tốt. Đặc tả mơ hồ làm ranh giới phạm vi mờ, và tranh cãi sẽ chuyển sang câu "việc này có phải thay đổi không". Đó là lý do VAON làm giai đoạn chốt đặc tả trước.
- "Không phát sinh" chỉ áp dụng cho phạm vi đã chốt. Thay đổi do điều kiện bên ngoài, như quy định pháp lý đổi hay hệ thống bên thứ ba đổi giao diện, thường cũng phải đi qua cùng quy trình.
- VAON chưa công bố số liệu về tần suất hay giá trị trung bình của các yêu cầu thay đổi. Bài này không đưa con số nào.
7. Câu hỏi thường gặp
Giá cố định có nghĩa là không bao giờ phát sinh chi phí không? Không. Giá cố định có nghĩa là giá được chốt cho phạm vi đã viết trong tài liệu. Khi bạn yêu cầu việc ngoài phạm vi đó, chi phí phát sinh, nhưng chỉ sau khi bạn nhìn thấy báo giá và duyệt bằng văn bản.
Tôi nhờ một việc nhỏ qua chat, có bị tính tiền không? Với VAON, việc ngoài phạm vi chỉ được làm sau khi có yêu cầu thay đổi và báo giá được bạn duyệt bằng văn bản. Việc nhờ qua chat được VAON ghi vào file quản lý phản hồi (feedback) hoặc chuyển thành task trong backlog, rồi gửi bạn xác nhận cùng giá và tác động trước khi làm. Nếu bạn không duyệt, việc đó không được làm và không tính tiền.
Điều khoản quản lý thay đổi nên dài đến mức nào? Không cần dài, nhưng cần đủ các mục ở bảng mục 3: ai lập, ai duyệt, nội dung phiếu, thời hạn báo giá, kết quả khi không duyệt. Ngắn gọn mà đủ chức danh, ngày và tài liệu tham chiếu thì hữu ích hơn một điều khoản dài mà chung chung.
Dự án còn mơ hồ, chưa có tài liệu yêu cầu, có áp dụng được không? Khó. Không có tài liệu thì không có ranh giới để gọi là "thay đổi". Trường hợp này nên làm giai đoạn chốt đặc tả trước, để có tài liệu yêu cầu và báo giá cố định cho giai đoạn xây dựng, rồi mới áp dụng quy trình thay đổi.
Đang so sánh báo giá của vài công ty phần mềm? Bạn có thể mang báo giá và bản nháp hợp đồng đến buổi trao đổi đầu tiên của VAON. Buổi này kéo dài 60 phút, có CEO tham dự, 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
- METI và IPA, 「情報システム・モデル取引・契約書」 (第一版及び追補版, giải thích về quy trình quản lý thay đổi, điều 37 của bản thứ nhất): https://www.ipa.go.jp/archive/digital/model/ug65p90000001lgm-att/000079617.pdf (kiểm tra 17/10/2026)
- IPA, 「情報システム・モデル取引・契約書（第二版）」: https://www.ipa.go.jp/digital/model/model20201222.html (kiểm tra 17/10/2026)
