"Chúng tôi đã bàn giao đủ tính năng theo danh sách, và nghiệm thu đúng số ngày-công trong hợp đồng."
Cả hai vế đều có thể đúng trong khi dự án vẫn là một thất bại về mặt kinh doanh. Đó là vấn đề cấu trúc của hợp đồng ngày-công: nó trả tiền cho công sức bỏ ra và tính năng bàn giao, chứ không trả tiền cho bất cứ thứ gì doanh nghiệp thực sự thu về được.
Hậu quả cộng dồn theo ba hướng.
Động lực bị đặt ngược. Với hợp đồng tính theo giờ hoặc ngày-công, nhà thầu làm nhanh hơn thì thu ít tiền hơn. Nhà thầu vẽ tính năng phức tạp hơn thì thu nhiều hơn. Mọi cải thiện hiệu suất — kể cả những cải thiện mà công cụ AI hiện đã biến thành chuyện thường ngày — đều là một khoản cắt doanh thu của chính bên tạo ra nó. Không ai cố tình thiết kế hợp đồng để trừng phạt hiệu suất, nhưng mô hình này làm đúng điều đó.
Bên mua gánh toàn bộ rủi ro triển khai. Nhà thầu có thể bàn giao 100% đặc tả đã thống nhất mà phần mềm vẫn không ai dùng. Với hợp đồng ngày-công, hóa đơn vẫn hợp lệ trong cả hai trường hợp.
Agency và SIers bị đẩy vào thế hàng hóa hóa. Nếu thứ bạn bán là giờ lập trình viên, đòn bẩy duy nhất của bên mua là đơn giá giờ, và cuộc đàm phán chỉ đi theo một chiều.
Giải pháp thay thế không phải là "hãy tin chúng tôi nhiều hơn". Giải pháp là viết các kết quả đo lường được vào chính hợp đồng. Việc này khó hơn vẻ ngoài của nó, và phần lớn các nỗ lực thất bại vì cùng những lý do. Bài viết này nói về lý do chúng thất bại, sau đó là mô hình 4 tầng chúng tôi dùng với khách hàng Nhật, và bốn thành phần mà mọi điều khoản Outcome đều cần để tồn tại được trong thực tế.
Vì sao phần lớn điều khoản Outcome thất bại
Nói về các chế độ thất bại trước, vì một điều khoản Outcome không thể phân xử được còn tệ hơn là không có điều khoản nào. Nó tạo ra một vụ tranh chấp thay vì một dự án.
- Không có mốc nền (baseline). "Giảm 50% thời gian xử lý" không có nghĩa gì nếu chưa ai đo thời gian xử lý trước khi dự án bắt đầu. Mốc nền phải được đo và ký xác nhận trước khi lập trình, không phải dựng lại từ trí nhớ sau đó.
- Không chỉ định ai đo. Nếu chỉ số nằm trong hệ thống phân tích của khách hàng mà nhà thầu không có quyền truy cập, nhà thầu không thể quản trị thứ mình đang bị ràng buộc. Nếu nhà thầu tự báo cáo, khách hàng không thể tin con số. Cả hai bên cần thống nhất ai đọc chỉ số và đọc lúc nào.
- Không có ranh giới quy trách nhiệm. Tỷ lệ chuyển đổi có thể giảm vì đối thủ hạ giá, vì khách hàng đổi trang giá, hoặc vì phần mềm chậm. Một điều khoản không tách được phần nhà thầu kiểm soát khỏi phần không kiểm soát là điều khoản không thể thực thi.
- Không có hệ quả. Một chỉ số viết vào hợp đồng mà không gắn với hệ quả nào — nghiệm thu, đợt thanh toán, nghĩa vụ khắc phục — chỉ là một KPI trong tài liệu, không phải điều khoản hợp đồng.
Mô hình Outcome 4 tầng
Các tầng đi từ thứ nhà thầu gần như kiểm soát hoàn toàn đến thứ nhà thầu chỉ ảnh hưởng và chia sẻ quyền kiểm soát với doanh nghiệp. Độ dốc này quan trọng: nó quyết định mỗi tầng được phép gắn chặt với tiền đến mức nào.
- Tầng 1 — Tốc độ bàn giao. Tần suất deploy; thời gian từ yêu cầu đã thống nhất đến phần mềm chạy được trên môi trường khách hàng truy cập được. Đây là tầng nhà thầu kiểm soát trực tiếp nhất, nên cũng là tầng an toàn nhất để viết thành cam kết cứng. Tại VAON, mục tiêu vận hành là rút ngắn 40% thời gian từ yêu cầu đến bản chạy được, đạt được bằng cách đưa công cụ AI — bao gồm Claude Code của Anthropic — vào vòng lặp đặc tả–demo, chứ không chỉ vào bước viết code. Giá trị thương mại ở đây không phải code rẻ hơn. Giá trị là một giả định sai lộ ra trong bản demo ở tuần thứ hai thay vì lộ ra trong UAT ở tháng thứ tư.
- Tầng 2 — Hiệu năng và độ tin cậy hệ thống. Phân vị thời gian phản hồi API dưới một hồ sơ tải xác định; tỷ lệ lỗi lọt ra theo cấp độ nghiêm trọng; độ phủ kiểm thử tự động trên các module trọng yếu. Phải viết các chỉ số này gắn với môi trường kiểm thử cụ thể và hồ sơ tải cụ thể, nếu không chúng vô nghĩa. Một con số p95 latency không nêu mức đồng thời thì không phải cam kết.
- Tầng 3 — Mức độ chấp nhận và khả năng sử dụng. Thời gian hoàn thành tác vụ của người vận hành thật; tỷ lệ người dùng hoạt động trên tổng số người dùng mục tiêu; tỷ lệ rời bỏ tại các bước quan trọng. Tầng này đòi hỏi nhà thầu ở lại sau bàn giao, vì hệ đo chỉ sinh tín hiệu sau khi có sử dụng thật. Nó cũng đòi hỏi khách hàng cấp quyền truy cập vào hệ đo đó.
- Tầng 4 — Tác động kinh doanh. Tỷ lệ chuyển đổi, lượng ticket hỗ trợ, số giờ cắt được khỏi một quy trình vận hành, tổng chi phí sở hữu. Đây là tầng ai cũng muốn đưa vào hợp đồng, và cũng là tầng sinh tranh chấp nhiều nhất, vì nhà thầu chia sẻ quyền kiểm soát với giá bán, marketing, nhân sự và cả thị trường.
Khuyến nghị của chúng tôi ở Tầng 4 là thận trọng có chủ đích: gắn nó với tiêu chí nghiệm thu và với thiết kế của giai đoạn tư vấn đầu vào, không gắn với phạt thanh toán — trừ khi nhà thầu thực sự kiểm soát toàn bộ vòng lặp. Ở những chỗ cơ chế nằm trọn trong phạm vi công việc — ví dụ tự động hóa một nhóm yêu cầu hỗ trợ đã định nghĩa rõ, hoặc cắt một số giờ đo được khỏi một quy trình cụ thể — Tầng 4 có thể mang trọng lượng thương mại thật. Ở những chỗ không phải vậy, ép nó vào hợp đồng sẽ tạo ra một điều khoản hai bên tranh cãi thay vì một dự án hai bên hoàn thành.
Bốn thành phần bắt buộc của mọi điều khoản Outcome
Với mỗi chỉ số đưa vào hợp đồng, hãy viết kèm bốn thành phần sau. Thiếu bất kỳ thành phần nào, điều khoản sẽ không đứng vững.
- Mốc nền. Giá trị khởi điểm đã đo, ngày đo, phương pháp đo, và chữ ký xác nhận của cả hai bên. Đo trong giai đoạn đặc tả.
- Phương pháp đo và người chịu trách nhiệm đo. Công cụ đo, định nghĩa truy vấn hoặc sự kiện, môi trường, và bên được chỉ định thực hiện. Nếu công cụ thuộc khách hàng, hợp đồng phải cấp quyền đọc cho nhà thầu.
- Cửa sổ đo. Ngày lấy số và khoảng thời gian lấy. "30 ngày sử dụng production tính từ Go-Live cộng hai tuần" là một điều khoản. "Sau khi ra mắt" thì không.
- Hệ quả và các trường hợp loại trừ. Điều gì xảy ra khi đạt và khi không đạt — nghiệm thu, một đợt thanh toán, một nghĩa vụ khắc phục có phạm vi cố định — và các sự kiện được nêu tên làm treo điều khoản, chẳng hạn khách hàng thay đổi quy trình nghiệp vụ nền hoặc bên thứ ba đổi API.
Cam kết thật sự nằm ở đâu
Chỉ số Outcome không xử lý được nguồn thất thoát lớn nhất trong phát triển phần mềm theo yêu cầu. Nguồn đó không phải là lập trình chậm. Đó là một bản đặc tả sai hoặc thiếu, bị phát hiện muộn. Khoảng một nửa số dự án thất bại truy về đây.
Vì vậy cam kết hợp đồng của chúng tôi nằm ở thượng nguồn của các tầng, chứ không chỉ ở hạ nguồn. VAON vận hành giai đoạn đặc tả theo giá cố định — định nghĩa yêu cầu, thiết kế màn hình, thiết kế cơ sở dữ liệu, kiến trúc, và một báo giá cố định cho giai đoạn build — với thời lượng xác định và giá công bố trước. Nếu trong giai đoạn build phát sinh rework mà nguyên nhân gốc truy về lỗi hoặc thiếu sót trong bản đặc tả do VAON viết, VAON chịu chi phí đó.
Ranh giới được viết ra minh bạch, vì một cam kết không có ranh giới không phải cam kết mà là một khoản nợ chưa định giá. Lỗi và thiếu sót trong đặc tả của chúng tôi thuộc về chúng tôi. Thay đổi yêu cầu sau khi chốt, thay đổi điều kiện nền như API bên thứ ba hay thay đổi quy định pháp luật, và các quy tắc nghiệp vụ không được cung cấp dù đã được hỏi trong biên bản, thuộc về khách hàng. Mỗi ticket rework được phân loại theo bốn nhóm đó kèm biên bản, và mọi yêu cầu ngoài phạm vi đều đi qua quy trình quản lý thay đổi bằng văn bản: báo giá và tác động tiến độ bằng văn bản, khách hàng duyệt bằng văn bản, trước khi bắt tay làm. Bạn sẽ không bao giờ nhận hóa đơn cho công việc mình chưa duyệt.
Đó cũng chính là kỷ luật mà bốn tầng chỉ số phụ thuộc vào. Chỉ số chỉ phân xử được khi bản đặc tả mà nó tham chiếu là rõ ràng, và khi mọi quyết định đều có dấu vết giấy tờ.
Bảo mật và xử lý dữ liệu
Cam kết Outcome giả định hệ thống luôn sẵn sàng và dữ liệu nằm đúng chỗ. Chúng tôi triển khai tại vùng mà khách hàng yêu cầu, bao gồm Tokyo, khi data residency là điều kiện bắt buộc. Sản phẩm OneBot của chúng tôi — một trợ lý RAG đang chạy production, tích hợp LINE — được xây với ràng buộc kiến trúc có tính đến APPI, nên đây là bài toán chúng tôi đã giải trong chính sản phẩm của mình chứ không chỉ trong một tài liệu chính sách. Phân cấp sự cố và cam kết thời gian phản hồi, bao gồm mục tiêu phản hồi trong một giờ cho sự cố nghiêm trọng, được định nghĩa trong hợp đồng thay vì trông vào thiện chí.
Từ mua "ngày-công" sang mua "kết quả"
Mục đích của một dự án phần mềm không phải là tiêu hết ngân sách hay tích đủ ô trong bảng đặc tả. Mục đích là gỡ một nút thắt vận hành và tạo ra một chuyển biến thương mại đo được.
Nếu bạn muốn cấu trúc hợp đồng tiếp theo quanh Outcome, chúng tôi sẽ cùng bạn lập bản đồ chỉ số theo từng tầng, trước khi bất kỳ ai báo giá.
🤝 Tư vấn hợp đồng hướng Outcome & hợp tác OEM — Liên hệ VAON để thiết kế bộ chỉ số cho dự án của bạn, nhận báo giá tổng thể, hoặc tham gia chương trình OEM / Technical Partnership dành cho Agency và SIers.