Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa thuyết phục được cả tổ chức chuyển sang Agile. Team chạy Sprint trơn tru, backlog được tinh chỉnh đều đặn, khách hàng hài lòng vì mỗi hai tuần lại thấy sản phẩm tiến triển. Mọi thứ hoàn hảo — cho đến khi bộ phận pháp chế và mua sắm (procurement) ném cho bạn một bản hợp đồng dày 40 trang với dòng chữ "Fixed Price, Fixed Scope, Fixed Deadline". Cả triết lý Agile của bạn bốc hơi trong một nốt nhạc.
Đây không phải tình huống hiếm. Trong thực tế, rất nhiều dự án Agile chết yểu không phải vì team yếu, mà vì mô hình hợp đồng bóp nghẹt sự linh hoạt. Hợp đồng truyền thống giả định rằng ta biết trước chính xác mình cần gì (scope cố định), trong khi cả tinh thần Agile được xây dựng trên giả định ngược lại: chúng ta sẽ học hỏi và điều chỉnh dọc đường.
Là một Project Manager hay Agile coach, bạn không thể đẩy hết phần hợp đồng cho luật sư rồi quay đi. Hợp đồng chính là "luật chơi" định hình toàn bộ mối quan hệ giữa nhà cung cấp và khách hàng. Nếu luật chơi sai, bạn không thể Agile dù cố gắng đến đâu. Bài này sẽ trang bị cho bạn cách hiểu, lựa chọn và đàm phán các loại hợp đồng phù hợp với Agile — cùng cách viết một Statement of Work (SOW) không phản bội lại tinh thần thích nghi.
Khái niệm cốt lõi
Mâu thuẫn nền tảng: Iron Triangle bị đảo ngược
Trong quản lý dự án truyền thống, ta có "tam giác sắt" (Iron Triangle): Scope — Time — Cost. Hợp đồng Fixed-Price cố định cả ba: phạm vi xác định, thời hạn xác định, giá xác định. Khi đó, biến số duy nhất còn lại để hấp thụ rủi ro chính là chất lượng — và đây là lý do nhiều dự án outsourcing fixed-price ra sản phẩm chất lượng tệ.
Agile đảo ngược tam giác này. Agile cố định Time và Cost (team ổn định, nhịp Sprint đều đặn, ngân sách theo thời gian), còn Scope là biến số linh hoạt. Ta ưu tiên làm những hạng mục giá trị nhất trước, và sẵn sàng cắt bỏ những hạng mục giá trị thấp khi hết ngân sách.
Vấn đề là: hợp đồng pháp lý cần sự chắc chắn để bảo vệ cả hai bên, còn Agile lại sống nhờ sự bất định. Nghệ thuật của Agile contract là tìm điểm cân bằng — cho khách hàng đủ chắc chắn về ngân sách và rủi ro, đồng thời cho team đủ tự do để thích nghi.
Các loại hợp đồng cho Agile
1. Time & Materials (T&M) — Thời gian và Vật tư
Khách hàng trả tiền theo thời gian team làm việc (thường tính theo ngày công hoặc theo Sprint). Đây là mô hình "thuần Agile" nhất vì scope hoàn toàn linh hoạt. Nhược điểm: khách hàng gánh toàn bộ rủi ro chi phí và thường lo sợ "vô đáy" — không biết khi nào dừng và tốn bao nhiêu.
2. T&M with Cap (T&M có trần ngân sách)
Giống T&M nhưng có một mức trần chi phí. Khách hàng yên tâm hơn vì biết tối đa phải trả bao nhiêu; nhà cung cấp vẫn được trả theo công thực tế nếu dự án kết thúc sớm. Đây là điểm cân bằng phổ biến nhất ở thị trường Việt Nam khi làm với khách nước ngoài.
3. Fixed-Price per Sprint / Capacity-based
Mỗi Sprint là một đơn vị mua bán với giá cố định (ví dụ: 1 team 6 người x 2 tuần = giá X). Scope của mỗi Sprint thì linh hoạt, do Product Owner quyết qua backlog. Khách hàng mua "năng lực" (capacity) chứ không mua "tính năng cụ thể".
4. Fixed-Price with Variable Scope ("Money for Nothing, Change for Free")
Đây là mô hình tinh tế do Jeff Sutherland đề xướng. Tổng ngân sách cố định, nhưng cho phép:
- Change for Free: khách hàng được đổi/thay thế hạng mục backlog miễn phí, miễn là tổng khối lượng công việc không tăng. Vì Agile vốn re-prioritize liên tục, điều này không phát sinh chi phí thực.
- Money for Nothing: khách hàng có quyền chấm dứt sớm khi thấy giá trị đã đủ, và trả một khoản phí nhỏ (thường ~20% phần ngân sách còn lại) cho nhà cung cấp. Cả hai cùng có lợi: khách tiết kiệm, nhà cung cấp giải phóng team đi làm dự án khác mà vẫn có khoản bù.
Chia dự án thành nhiều giai đoạn ngắn, mỗi giai đoạn là một hợp đồng nhỏ. Sau mỗi giai đoạn, hai bên đánh giá lại và quyết định có tiếp tục không. Giảm rủi ro cam kết dài hạn cho cả hai.
Statement of Work (SOW) trong bối cảnh Agile
SOW truyền thống liệt kê chi tiết từng deliverable, từng dòng tính năng — và trở thành "thánh kinh" để hai bên cãi nhau khi có tranh chấp. SOW kiểu Agile khác về bản chất: thay vì mô tả CÁI GÌ sẽ được làm, nó mô tả CÁCH chúng ta sẽ làm việc cùng nhau để khám phá ra cái cần làm.
Một Agile SOW tốt thường gồm:
- Vision / Business Objectives: mục tiêu kinh doanh, không phải danh sách tính năng. Ví dụ "tăng tỷ lệ chuyển đổi giỏ hàng lên 15%" thay vì "xây nút checkout màu xanh".
- Cách thức hợp tác: nhịp Sprint, cadence họp, vai trò Product Owner phía khách hàng (rất quan trọng — khách phải có người cam kết tham gia).
- Definition of Done & tiêu chí chất lượng: chuẩn nghiệm thu chung, không phải nghiệm thu từng tính năng.
- Cơ chế quản trị thay đổi: thay vì "change request" nặng nề, dùng cơ chế re-prioritize backlog.
- Điều khoản thoát (exit clause): cách dừng dự án êm đẹp.
- Mô hình thanh toán và các giả định (assumptions).
Tình huống thực tế
Ví dụ 1 — Công ty outsourcing Việt Nam và cái bẫy Fixed-Price
Một công ty phần mềm tại TP.HCM (tạm gọi là FPT-style midsize agency, ~200 nhân sự) ký hợp đồng Fixed-Price 1,8 tỷ đồng với một khách hàng fintech ở Singapore để xây "nền tảng ví điện tử trong 6 tháng". SOW liệt kê 47 tính năng cụ thể.
Đến Sprint thứ 4, khách hàng nhận ra luồng KYC (xác minh danh tính) ban đầu thiết kế sai so với quy định MAS của Singapore, cần làm lại hoàn toàn. Vấn đề: việc này không nằm trong 47 tính năng đã ký. Phía nhà cung cấp đòi ký phụ lục tăng phí; khách hàng cho rằng "KYC đúng luật là điều hiển nhiên phải có". Hai bên tranh cãi suốt 3 tuần, team ngồi chơi, mối quan hệ rạn nứt. Cuối cùng dự án trễ 2 tháng và agency phải nuốt chi phí phát sinh để giữ uy tín.
Bài học: Fixed-Price + Fixed-Scope tạo ra động lực đối nghịch. Mỗi thay đổi (vốn là bản chất tự nhiên của phần mềm) đều biến thành một trận chiến hợp đồng. Nếu họ dùng T&M with Cap kèm cơ chế Change for Free, việc đổi luồng KYC chỉ đơn giản là re-prioritize backlog — kéo một tính năng giá trị thấp ra để nhét KYC vào, không cần phụ lục, không cần cãi nhau.
Ví dụ 2 — Money for Nothing cứu ngân sách một startup
Một startup thương mại điện tử ở Hà Nội thuê đội ngoài xây sản phẩm MVP, hợp đồng dạng Fixed-Price with Variable Scope, tổng ngân sách 800 triệu cho 10 Sprint, có điều khoản Money for Nothing (phí thoát 20%).
Đến Sprint thứ 6, dữ liệu người dùng cho thấy sản phẩm đã đủ tốt để gọi vốn vòng tiếp theo, và 4 Sprint còn lại chủ yếu là các tính năng "nice to have". Founder quyết định dừng. Theo điều khoản, họ trả nốt phần đã làm (480 triệu) cộng 20% của phần còn lại (20% x 320 triệu = 64 triệu) — tổng 544 triệu, tiết kiệm 256 triệu so với chạy hết hợp đồng.
Nhà cung cấp cũng vui: họ giải phóng đội ngũ sớm để nhận dự án mới, lại được khoản 64 triệu "không công" như phần thưởng cho việc giao giá trị hiệu quả.
Bài học: Một điều khoản hợp đồng thông minh biến quan hệ "tổng bằng không" (zero-sum) thành "đôi bên cùng thắng". Khi nhà cung cấp được thưởng vì giúp khách dừng sớm, động lực của họ thẳng hàng với giá trị thực — chứ không phải kéo dài dự án để tính thêm giờ.
Ví dụ 3 — SOW theo mục tiêu kinh doanh tại một ngân hàng
Một ngân hàng Việt Nam triển khai dự án số hóa quy trình mở thẻ, làm việc với nhà thầu theo mô hình capacity-based (mua 2 Scrum team trong 9 tháng). SOW không liệt kê tính năng mà ghi mục tiêu: "giảm thời gian mở thẻ từ 5 ngày xuống dưới 1 ngày" và "đạt NPS quy trình ≥ 60".
Vì SOW gắn với kết quả kinh doanh, mỗi Sprint Review hai bên cùng nhìn vào chỉ số thực tế để quyết định backlog tiếp theo, thay vì gạch đầu dòng "đã làm xong tính năng A chưa". Khi phát hiện nút thắt thực sự nằm ở khâu duyệt thủ công của khối vận hành (chứ không phải ở giao diện), team xoay hướng ngay sang tự động hóa khâu duyệt — điều mà một SOW liệt kê tính năng cứng sẽ không cho phép.
Bài học: SOW dựa trên outcome (kết quả) thay vì output (đầu ra) cho phép team đi tìm giá trị thật, không bị xích vào một bản kế hoạch đoán mò từ ngày đầu.
Hướng dẫn từng bước
Khi bạn cần thiết lập một hợp đồng Agile, hãy đi theo trình tự sau:
- Đánh giá mức độ bất định của dự án. Scope càng mơ hồ, càng phải nghiêng về T&M hoặc capacity-based. Nếu scope thực sự rõ và ổn định (hiếm trong phần mềm), Fixed-Price mới hợp lý.
- Xác định ai gánh rủi ro nào. T&M: khách gánh rủi ro chi phí. Fixed-Price: nhà cung cấp gánh rủi ro chi phí (và thường hy sinh chất lượng). Mục tiêu là chia sẻ rủi ro công bằng, ví dụ qua T&M with Cap.
- Chọn đơn vị mua bán. Quyết định bạn bán "tính năng" hay bán "năng lực team theo Sprint". Agile khuyến khích bán năng lực.
- Viết SOW theo mục tiêu, không theo tính năng. Bắt đầu bằng business objectives đo được. Chỉ liệt kê một backlog ban đầu mang tính tham khảo (indicative), ghi rõ "có thể thay đổi qua refinement".
- Cài cơ chế linh hoạt vào hợp đồng. Đưa Change for Free và Money for Nothing (hoặc tương đương) vào điều khoản. Định nghĩa rõ "tổng khối lượng công việc" được đo bằng gì (story points capacity, số Sprint...).
- Định nghĩa Definition of Done và quy trình nghiệm thu chung. Nghiệm thu theo chuẩn chất lượng và theo từng increment, không phải nghiệm thu cả khối cuối dự án.
- Cam kết vai trò từ phía khách hàng. Ghi rõ khách phải cử Product Owner hoặc người ra quyết định, mức độ sẵn sàng tham gia. Đây là điều khoản hay bị bỏ quên nhưng quyết định thành bại.
- Thiết kế điều khoản thoát êm đẹp. Cho phép dừng sau mỗi giai đoạn/Sprint với chi phí dự đoán được.
- Kéo procurement và pháp chế vào sớm. Đừng để họ xuất hiện ở phút chót. Giải thích cho họ vì sao mô hình Agile bảo vệ khách hàng tốt hơn (giao giá trị sớm, dừng được khi cần).
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng Fixed-Price rồi cố "Agile bên trong". Nhiều team chạy Scrum nhưng hợp đồng vẫn fixed scope. Kết quả: mỗi thay đổi thành tranh chấp, team không dám re-prioritize. Mẹo: nếu buộc phải Fixed-Price, ít nhất hãy gắn kèm Change for Free để cho phép hoán đổi scope cùng khối lượng.
Lỗi 2 — SOW liệt kê quá chi tiết tính năng. Bản SOW càng cụ thể tính năng, bạn càng tự trói mình. Mẹo: chuyển ngôn ngữ từ "sẽ giao tính năng X, Y, Z" sang "sẽ làm việc theo nhịp Sprint để đạt mục tiêu kinh doanh A, với backlog ban đầu mang tính tham khảo".
Lỗi 3 — Quên cam kết của khách hàng. Agile cần Product Owner phía khách tham gia liên tục. Nếu hợp đồng không ràng buộc, khách "thả" PO và team mất phương hướng. Mẹo: viết hẳn điều khoản về thời gian tối thiểu PO cam kết mỗi tuần.
Lỗi 4 — Không định nghĩa "tổng khối lượng" trong Change for Free. Nếu không đo được, khách sẽ nhét thêm việc và gọi đó là "đổi miễn phí". Mẹo: neo vào capacity (số Sprint, số story point khả dụng), không neo vào danh sách tính năng.
Lỗi 5 — Bỏ qua pháp chế đến phút cuối. Mẹo: chuẩn bị sẵn một bản giải thích ngắn cho luật sư về cách các điều khoản này vẫn bảo vệ quyền lợi — nhấn mạnh tính minh bạch (mỗi Sprint khách đều thấy sản phẩm) và quyền dừng.
Mẹo vàng: Hợp đồng Agile tốt nhất là hợp đồng dựa trên lòng tin được xây qua minh bạch. Cấu trúc giao hàng từng Sprint khiến khách hàng nhìn thấy giá trị liên tục, nên họ không cần "bám" vào điều khoản chi tiết để tự vệ. Hãy bán sự minh bạch đó như lợi thế cạnh tranh.
Bài tập thực hành
- Chẩn đoán hợp đồng hiện tại. Lấy một hợp đồng dự án bạn đang/từng tham gia. Xác định nó thuộc loại nào (Fixed-Price, T&M...) và liệt kê 3 điểm mà mô hình đó cản trở sự linh hoạt của Agile.
- Chuyển đổi SOW. Lấy một SOW liệt kê tính năng. Viết lại phần mô tả mục tiêu thành 2–3 business objectives đo được (outcome), thay vì danh sách output.
- Tính Money for Nothing. Giả sử ngân sách 1 tỷ cho 10 Sprint, phí thoát 20%. Khách dừng sau Sprint thứ 7. Tính số tiền khách phải trả tổng cộng và số tiền tiết kiệm được so với chạy hết.
- Đóng vai đàm phán. Một khách hàng khăng khăng đòi Fixed-Price vì "sếp em cần con số chắc chắn". Viết một đoạn 5–7 câu thuyết phục họ chuyển sang T&M with Cap, nhấn mạnh lợi ích cho phía họ (kiểm soát ngân sách + linh hoạt + quyền dừng sớm).
Tóm tắt
- Mâu thuẫn gốc rễ: hợp đồng truyền thống cố định scope, còn Agile coi scope là biến số linh hoạt. Nếu mô hình hợp đồng sai, bạn không thể Agile thật sự.
- Các loại hợp đồng phù hợp Agile, từ linh hoạt nhất đến chắc chắn nhất: T&M → T&M with Cap → Fixed-Price per Sprint (capacity-based) → Fixed-Price with Variable Scope (Change for Free + Money for Nothing) → Phased Delivery.
- Change for Free cho phép hoán đổi scope miễn phí khi tổng khối lượng không đổi; Money for Nothing cho phép khách dừng sớm và trả phí thoát nhỏ — biến quan hệ thành đôi bên cùng thắng.
- Agile SOW mô tả CÁCH hợp tác và MỤC TIÊU kinh doanh (outcome), không liệt kê chi tiết tính năng (output). Phải có điều khoản cam kết của khách hàng và cơ chế thoát.
- Mục tiêu cuối cùng là chia sẻ rủi ro công bằng và xây lòng tin qua minh bạch từng Sprint — khi đó hợp đồng không còn là vũ khí phòng thủ mà là khung hợp tác.