Khi đàm phán giá cho các dự án phần mềm tùy chỉnh, đơn vị thường được hai bên A và B thống nhất nhất là “người‑ngày” : bao nhiêu kỹ sư, làm trong bao nhiêu ngày, đơn giá bao nhiêu. Mô hình này chỉ hoạt động hiệu quả khi yêu cầu ổn định, ranh giới giao hàng rõ ràng; nhưng một khi quy tắc tại hiện trường thay đổi liên tục, các công cụ AI nâng cao hiệu suất lập trình, còn bên A vẫn tiếp tục nghiệm thu theo kiểu “đổ thêm người”, mâu thuẫn sẽ bùng phát — phía B cảm thấy yêu cầu bị lan rộng, còn phía A thì cho rằng “người chẳng tăng, mà đồ lại chẳng nhiều”.
Tín hiệu chính sách: từ bán nhân lực sang bán kết quả
Tháng 9 năm 2026, Bộ Công nghiệp và Công nghệ Thông tin đã ban hành “Kế hoạch triển khai chuyên đề ‘Trí tuệ nhân tạo + Phần mềm’”, trong đó nhiều lần nhấn mạnh việc thúc đẩy chuyển đổi mô hình sản xuất phần mềm, phát triển các dịch vụ “Mô hình như một dịch vụ” và “Thể chế thông minh như một dịch vụ”, đồng thời nêu rõ đến năm 2028 sẽ xây dựng các ứng dụng tiêu biểu về phần mềm thể chế thông minh trong các ngành trọng điểm. Văn bản không phủ nhận phát triển theo yêu cầu riêng, nhưng truyền tải một định hướng rõ ràng: đánh giá giá trị phần mềm ngày càng chú trọng vào hiệu quả thực tế, chứ không chỉ xem xét số lượng người‑ngày đã bỏ ra .
Đối với các doanh nghiệp đang triển khai ERP, MES, CRM hay các hệ thống quản lý ngành, điều này có nghĩa là nếu hợp đồng vẫn chỉ ghi “XX người × XX ngày”, sau khi đưa vào vận hành rất dễ rơi vào tình trạng “mã đã viết xong, nhưng nghiệp vụ thì không dùng được” gây tranh cãi. Cách viết bền vững hơn là chia nhỏ công việc giao hàng thành các kết quả nghiệp vụ có thể nghiệm thu .
Logic nghiệp vụ: các mốc里程碑 cần cụ thể hơn cả số người‑ngày
Chuyển dự án từ “thanh toán theo giai đoạn” lên “thanh toán theo mốc milestone”, mỗi mốc phải đồng thời đáp ứng bốn điều kiện:
- Tình huống nghiệp vụ : ai đang sử dụng, giải quyết thao tác gì (ví dụ “nhân viên kho quét mã nhập kho” thay vì “hoàn thành module nhập kho”).
- Quy chuẩn dữ liệu : bao gồm những dữ liệu chủ nào, các trường trạng thái, phạm vi quyền hạn ra sao, quy tắc lấy mẫu thế nào.
- Kịch bản nghiệm thu : với dữ liệu thử nghiệm đã định sẵn, cần chạy qua những quy trình nào, cho ra những chứng từ hoặc báo cáo gì.
- Xử lý ngoại lệ : khi thất bại, hệ thống sẽ thông báo ra sao, ai có quyền sửa đổi, có lưu lại dấu vết không.
Một mốc milestone không nên kéo dài quá 2–4 tuần ; nếu quá dài sẽ lại quay về kiểu “phát triển hộp đen”. Ví dụ điển hình về cách chia nhỏ: dữ liệu chủ và quyền hạn → chu trình khép kín của chứng từ cốt lõi → báo cáo và đối chiếu → giao diện và chuyển đổi vận hành.
Logic thiết kế: phạm vi, thay đổi và “hỗ trợ thông minh” cần được ghi rõ trong hợp đồng
AI hỗ trợ lập trình, tự động sinh test case, tự động bổ sung tài liệu… sẽ làm thay đổi mức tiêu hao người‑ngày cho cùng một chức năng, nhưng không tự động làm thay đổi độ phức tạp nghiệp vụ . Trong hợp đồng và đặc tả yêu cầu, nên tách riêng:
- Đường cơ sở phạm vi (Baseline) : danh sách tính năng + danh sách những hạng mục nằm ngoài phạm vi (Out of Scope), mọi thay đổi đều phải thông qua phiếu thay đổi.
- Quy tắc định giá thay đổi : bổ sung mốc milestone sẽ được định giá theo “tình huống + kịch bản nghiệm thu”, chứ không phải thêm người‑ngày đột xuất.
- Ranh giới hỗ trợ thông minh : những khâu nào có thể dùng AI để tăng hiệu quả (sinh mã, soạn thảo tài liệu), những khâu nào bắt buộc phải có chữ ký con người (an toàn, tuân thủ pháp luật, cam kết đối ngoại).
- Thuộc tính kiến thức tích lũy : ai nắm giữ tài liệu quy trình, cấu hình, script, tránh tình trạng sau bàn giao bị đứt gãy vận hành bảo trì.
Triển khai phát triển: tự động hóa nghiệm thu và khả năng giám sát
Để “định hướng kết quả” trở nên khả thi, phía kỹ thuật cần phối hợp ba việc:
- Lưu trữ các trường hợp nghiệm thu vào hệ thống : mỗi mốc milestone tương ứng với một bộ test case tự động hoặc bán tự động, có thể chạy lại nhiều lần.
- Cách ly môi trường và dữ liệu : dữ liệu môi trường UAT có thể thiết lập lại, tránh tình trạng “chỉ qua được ở môi trường demo”.
- Nhật ký giám sát : các thao tác then chốt đều có nhật ký kiểm tra, khi xảy ra tranh chấp có thể truy vết xem ai đã sửa gì.
Nếu dự án có thể chế thông minh hoặc engine quy tắc, nghiệm thu cần bổ sung cơ chế kiểm tra ngẫu nhiên : nhập ngẫu nhiên các trường hợp biên giới, kiểm tra xem việc từ chối trả lời, nâng cấp lên nhân sự, chặn quyền hạn có đúng thiết kế không, chứ không chỉ xem “có thể trò chuyện” hay không.
Ba loại tranh cãi thường gặp và biện pháp phòng ngừa
Tranh cãi thứ nhất: “Đã làm đủ chức năng, sao nghiệp vụ vẫn không dùng?” — Phòng ngừa: gắn milestone với các thao tác vị trí công việc và đăng ký đào tạo, khi nghiệm thu phải đi thực địa, không chỉ trình bày trên PPT.
Tranh cãi thứ hai: “Thêm một yêu cầu nhỏ, sao lại phải trả thêm tiền?” — Phòng ngừa: phiếu thay đổi cần ghi rõ milestone, script và thời hạn ảnh hưởng, hai bên ký xác nhận rồi mới triển khai.
Tranh cãi thứ ba: “AI đã tăng hiệu quả, vậy có thể giảm số người‑ngày không?” — Phòng ngừa: hợp đồng cần phân biệt “chi phí thực hiện” và “độ phức tạp nghiệp vụ”; lợi ích tăng hiệu quả có thể thể hiện qua tổng giá hoặc chu kỳ, nhưng tiêu chuẩn nghiệm thu không được hạ thấp.
Đề xuất thí điểm: bắt đầu từ một module khép kín
Không cần đợi toàn bộ hệ thống viết lại hợp đồng. Chọn một module có thể khép kín trong 2–3 tuần (như nhập xuất kho, báo công đơn, phê duyệt chi phí), dùng mẫu mới ký thỏa thuận bổ sung: liệt kê tình huống, script, ngoại lệ, mốc thanh toán. Sau khi vận hành thành công mới mở rộng ra toàn dự án. Đánh giá thành công bằng cách xem số phiếu thay đổi có giảm thời gian tranh cãi không , tỷ lệ đạt UAT ngay lần đầu có tăng không , chứ không phải xem phía B đã báo ít người‑ngày bao nhiêu.
Số người‑ngày sẽ không biến mất chỉ sau một đêm, nhưng nó đang dần chuyển từ “đơn vị định giá duy nhất” thành “tham khảo ước tính chi phí”. Ghi rõ milestone và kịch bản nghiệm thu vào hợp đồng mới là bí quyết căn bản giúp phần mềm tùy chỉnh vẫn có thể mang lại kết quả đáng tin cậy trong bối cảnh “trí tuệ nhân tạo + phần mềm”.
Phối hợp với hợp đồng giá cố định và phương pháp lặp agile
Nghiệm thu milestone không hề loại trừ agile: mỗi Sprint vẫn có thể bàn giao các bước tiến có thể trình diễn, nhưng thanh toán và nghiệm thu chính thức lại gắn với milestone lớn hơn. Hợp đồng giá cố định đặc biệt cần ghi rõ “điểm đóng băng phạm vi” — sau lần thẩm định nào thì yêu cầu mới phải thông qua phiếu thay đổi, tránh việc thêm chức năng bằng miệng. Đối với các module có thể chế thông minh, nên nghiệm thu từng milestone riêng biệt “phiên bản quy tắc + tỷ lệ kiểm tra đạt”, không nên gắn chung với việc đưa toàn bộ hệ thống vào vận hành.
Dữ liệu ngành cho thấy khoảng một phần ba dự án phần mềm thất bại xuất phát từ việc định nghĩa yêu cầu và tiêu chuẩn nghiệm thu chưa rõ ràng, chứ không phải do bản thân kỹ thuật thực hiện. Trước hết hãy ghi rõ “điều gì được coi là hoàn thành” vào hợp đồng, điều này có giá trị hơn cả việc tranh cãi xem AI đã thay thế bao nhiêu lập trình viên. Lần tới khi họp thẩm định dự án, có thể đặt câu hỏi trước: nếu ngày mai toàn bộ phía B nghỉ phép, liệu chúng ta có thể dựa vào script để đánh giá xem milestone hiện tại có đạt chuẩn không — nếu không trả lời được, tức là tiêu chuẩn nghiệm thu vẫn chưa được làm rõ.