Vì sao thay đổi yêu cầu làm dự án đội chi phí?
Thay đổi yêu cầu làm dự án đội chi phí khi báo giá xây dựng được đưa ra trước lúc hai bên hiểu cùng một đặc tả. Câu chuyện thường gặp như sau. Đặc tả nhìn đầy đủ lúc ký. Đến khi chạy thử, người dùng thật nói "không phải thế này".
Từ đó có ba hậu quả quen thuộc:
- Mỗi lần chỉnh, bên làm báo thêm chi phí và lùi lịch, vì việc đó "không có trong đặc tả".
- Tổng chi phí vượt xa ngân sách ban đầu, người phụ trách khó giải trình với ban giám đốc.
- Nếu ở giữa có SIer hoặc agency, họ thường phải tự gánh phần chênh để giữ khách.
Phản ứng tự nhiên là viết đặc tả thật lâu cho chắc. Nhưng đặc tả viết trên giấy vài tháng vẫn có thể sai ở chỗ chỉ lộ ra khi người dùng nhìn thấy màn hình. Vấn đề không nằm ở độ dài của đặc tả, mà ở thời điểm báo giá.
Hợp đồng phần mềm theo giai đoạn là gì?
Hợp đồng phần mềm theo giai đoạn (多段階契約, multi-stage contract) là cách ký một hợp đồng riêng cho từng giai đoạn của dự án. Nó thay cho một hợp đồng trọn gói từ đầu đến cuối. Giai đoạn sau được báo giá khi giai đoạn trước đã có kết quả.
Cách làm này không phải ý riêng của một công ty. [Mẫu hợp đồng hệ thống thông tin của IPA và Bộ Kinh tế, Thương mại và Công nghiệp Nhật (METI)](https://www.ipa.go.jp/archive/digital/model/ug65p90000001lgm-att/000079617.pdf) ký hợp đồng riêng (個別契約) cho từng công việc. Mỗi công việc mang hình thức khoán việc (請負) hoặc uỷ thác thực hiện (準委任) tuỳ nội dung. Trong mẫu này, việc hỗ trợ làm tài liệu yêu cầu được xếp vào dạng uỷ thác thực hiện.
Hai loại hợp đồng này khác nhau ở chỗ bên làm cam kết gì và xử lý lỗi thế nào. Phần đó có ở bài mã AI viết bị lỗi thì ai chịu trách nhiệm.
Ai chịu rủi ro đặc tả ở từng giai đoạn?
Chia giai đoạn không xoá rủi ro đặc tả. Nó chuyển rủi ro về giai đoạn mà sửa còn rẻ, và làm rõ ai chịu phần nào. Bảng dưới so sánh hai cách ký:
| | Một hợp đồng trọn gói | Hợp đồng theo giai đoạn |
|---|---|---|
| Lúc báo giá xây dựng | Trước khi đặc tả được chốt | Sau khi đặc tả được chốt |
| Chỗ đặc tả còn thiếu | Lộ ra giữa dự án, thành tranh cãi phát sinh | Lộ ra ở giai đoạn chốt đặc tả, sửa trên giấy |
| Bên làm thường xử lý rủi ro bằng | Cộng dự phòng vào giá, hoặc báo phát sinh sau | Báo giá sát với đặc tả đã chốt |
| Khách muốn dừng | Khó, đã cam kết toàn bộ | Dừng sau giai đoạn đầu, giữ tài liệu đã nhận |
| Thay đổi sau khi chốt | Dễ cãi nhau "có trong phạm vi không" | Đi qua quy trình thay đổi có văn bản |
Dòng cuối quan trọng. Kể cả khi đã chốt, yêu cầu vẫn sẽ đổi. Khác biệt là mỗi thay đổi được so với một văn bản cả hai bên đã ký, nên không còn là chuyện ai nhớ đúng hơn.
Dự án AI cần thêm bước nào trước khi ký phần xây dựng?
Dự án AI nên có thêm một PoC ngắn trước khi ký phần xây dựng. Ví dụ điển hình là chatbot RAG (hệ thống trả lời dựa trên tài liệu của doanh nghiệp). Lý do đơn giản: độ chính xác của AI không viết trước được trong đặc tả. Phải đo trên dữ liệu thật.
Cách VAON đề xuất là đo trên bộ khoảng 50 đến 100 câu hỏi thực tế, có đáp án do nhân viên nghiệp vụ chuẩn bị. Kết quả PoC trả lời ba câu. Tỉ lệ trả lời đúng có đủ dùng không? Thời gian phản hồi ra sao? Chi phí hạ tầng ước tính bao nhiêu?
PoC không bảo đảm hệ thống thật sẽ đạt đúng con số đó. Dữ liệu thật thường nhiều và bẩn hơn bộ mẫu. Nhưng PoC cho cả hai bên một con số để bàn, thay vì một lời hứa. Cách quyết định bằng PoC có ở bài chatbot RAG chạy trong mạng nội bộ.
VAON chia giai đoạn thế nào?
VAON chia dự án thành giai đoạn chốt đặc tả và giai đoạn xây dựng, mỗi giai đoạn một báo giá riêng. Giai đoạn đầu gọi là 仕様確定フェーズ (Giai đoạn chốt đặc tả, Spec Lock Phase):
1. Thời gian: 1 đến 2 tuần, dự án lớn 2 đến 4 tuần.
2. Giá: cố định, báo trước, không phát sinh trong giai đoạn này.
3. Người dẫn: BrSE (Bridge System Engineer, kỹ sư cầu nối) và Tech Lead.
4. Đầ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.
5. Quyền dừng: khách được dừng sau giai đoạn này.
Trong giai đoạn xây dựng, việc ngoài phạm vi đi qua quy trình thay đổi. VAON báo giá và ảnh hưởng tiến độ bằng văn bản, khách duyệt mới làm. Không duyệt là không làm, không tính tiền. Chi tiết quy trình có ở bài cách nhận biết công ty phần mềm không phát sinh chi phí ẩn.
Một điều bài này không hứa: VAON không nói rằng mọi chi phí làm lại sẽ do VAON chịu. Khi đặc tả sai, phần chi phí của mỗi bên được phân định trong hợp đồng từng dự án.
SIer và agency được gì khi chia giai đoạn?
SIer và agency đứng giữa khách cuối và bên làm thường chịu rủi ro đặc tả từ cả hai phía. Họ báo giá cho khách cuối, nhưng không tự viết mã. Khi đặc tả lệch, họ bị ép từ hai phía.
Chia giai đoạn giúp họ ba việc:
- Báo giá cho khách cuối theo từng giai đoạn, cùng nhịp với bên làm, thay vì ôm một con số trọn gói.
- Dùng tài liệu đặc tả đã chốt làm căn cứ chung cho cả ba bên.
- Khi khách cuối đổi yêu cầu, có văn bản báo giá thay đổi để chuyển tiếp, không phải tự gánh.
Agency muốn có sản phẩm AI chatbot mang thương hiệu riêng có thể xem ba lựa chọn tự phát triển, bán lại hay OEM ở bài agency và SIer muốn có sản phẩm AI chatbot riêng.
Khi nào không nên chia giai đoạn?
Không nên chia giai đoạn khi chi phí của việc chia lớn hơn rủi ro nó giảm. Ba trường hợp hay gặp:
- Việc nhỏ, phạm vi đã rõ. Thêm một màn hình vào hệ thống đang chạy không cần một giai đoạn chốt đặc tả riêng.
- Sản phẩm cần thử nhanh với thị trường. Khi mục tiêu là học từ người dùng, chu kỳ ngắn tính theo thời gian (準委任) thường hợp hơn.
- Không có người phía khách trả lời câu hỏi nghiệp vụ. Giai đoạn chốt đặc tả cần người hiểu việc. Thiếu người đó, tài liệu vẫn sẽ có chỗ đoán.
VAON là đội 15 nhân sự chính thức. Dự án cần vài chục người trong thời gian ngắn có thể vượt khả năng nhận của chúng tôi.
Việc làm được ngay: lấy báo giá phần mềm gần nhất bạn nhận được và tìm dòng ghi "đặc tả được chốt khi nào". Nếu báo giá xây dựng có trước đặc tả, rủi ro đang nằm ở phía bạn.
Nếu muốn xem dự án của bạn nên chia giai đoạn thế nào, đặt lịch trao đổi 60 phút miễn phí. CEO tham dự, không cần chuẩn bị tài liệu, không ràng buộc.