Mở đầu — vì sao bài này quan trọng
Nếu bạn làm Scrum Master tại Việt Nam hay Đông Nam Á, gần như chắc chắn bạn sẽ va vào một thực tế phũ phàng: rất nhiều dự án của chúng ta là dự án fixed-bid (hợp đồng trọn gói, chốt cứng phạm vi — thời gian — chi phí). Đặc biệt trong mảng outsourcing — vốn là xương sống của ngành phần mềm Việt Nam khi phục vụ khách hàng Nhật, Mỹ, Úc, châu Âu — khách hàng thường yêu cầu một con số cố định, một deadline cố định, và một danh sách tính năng cố định trước khi đặt bút ký.
Vấn đề là Agile và Scrum được sinh ra với một triết lý gần như đối nghịch: phạm vi nên linh hoạt, ta học và điều chỉnh qua từng Sprint, ta tối ưu giá trị chứ không tối ưu việc "giao đủ một danh sách". Vậy khi sếp hoặc khách hàng nói "anh đã ký fixed-bid rồi, làm Scrum kiểu gì?", bạn — với tư cách Scrum Master cấp PSM II — phải trả lời được. Không phải bằng cách lảng tránh ("fixed-bid thì không Agile được đâu"), cũng không phải bằng cách giả vờ ("cứ làm Scrum bình thường thôi").
Đây là một trong những impediment mang tính tổ chức và hợp đồng khó nhất mà một Scrum Master gặp phải, vì nó nằm ngoài tầm với của team. Bài này sẽ trang bị cho bạn cách hiểu đúng bản chất căng thẳng giữa fixed-bid và Agile, các mô hình hợp đồng thực tế để dung hòa, và quan trọng nhất: vai trò của bạn trong việc bảo vệ tính toàn vẹn của empirical process (quy trình thực nghiệm) ngay cả trong khung hợp đồng cứng.
Khái niệm cốt lõi
Tam giác sắt và nghịch lý của fixed-bid
Mọi dự án bị ràng buộc bởi ba biến: phạm vi (scope), thời gian (time), chi phí (cost) — cộng với chất lượng (quality). Trong mô hình truyền thống (waterfall), hợp đồng fixed-bid cố định cả ba: scope, time, cost đều khóa cứng. Khi đó biến duy nhất còn "co giãn" được — một cách âm thầm và nguy hiểm — chính là chất lượng. Đội phát triển bị ép phải giao đủ tính năng, đúng hạn, đúng giá, nên thứ duy nhất họ có thể "cắt" là chất lượng kỹ thuật: bỏ test, nợ kỹ thuật chồng chất, code rác.
Agile lật ngược tam giác này. Trong Agile, ta cố định time và cost (team ổn định, Sprint đều đặn, ngân sách theo thời gian), còn scope là biến linh hoạt. Ta cam kết giao giá trị cao nhất có thể trong khung thời gian và ngân sách đó, chứ không cam kết giao một danh sách tính năng đông cứng từ ngày đầu — khi mà ta hiểu về sản phẩm còn ít nhất.
Nghịch lý là: fixed-bid khóa scope, Agile thả scope. Đây chính là điểm va chạm. Hiểu được điều này, bạn sẽ thấy giải pháp không nằm ở chỗ "ép Agile vào hợp đồng cứng", mà ở chỗ thiết kế lại hợp đồng để chừa chỗ cho sự linh hoạt.
Vì sao khách hàng muốn fixed-bid?
Đừng vội phán xét khách hàng là "lạc hậu". Họ chọn fixed-bid vì những lý do hợp lý: họ muốn kiểm soát rủi ro ngân sách, muốn dự đoán được chi phí để báo cáo cấp trên, và họ không tin rằng nhà cung cấp sẽ làm việc hiệu quả nếu trả theo giờ (Time & Materials — T&M). Nói cách khác, fixed-bid là một cơ chế chuyển rủi ro: khách hàng đẩy rủi ro vượt ngân sách sang phía nhà cung cấp.
Khi hiểu động cơ này, bạn sẽ thấy: giải pháp Agile cho fixed-bid phải trả lời được nỗi sợ của khách hàng — đó là "tôi sợ mất kiểm soát chi phí và không nhận được thứ tôi cần". Mọi mô hình hợp đồng linh hoạt bên dưới đều xoay quanh việc xây dựng lại niềm tin đó.
Các mô hình hợp đồng để dung hòa
Có một phổ các mô hình, từ cứng đến mềm:
1. T&M thuần (Time & Materials): Trả theo thời gian và nguồn lực thực tế. Linh hoạt nhất, hợp Agile nhất, nhưng khách hàng sợ "vô đáy".
2. T&M có trần (T&M with a cap / Not-to-exceed): Trả theo giờ nhưng có mức trần. Khách hàng yên tâm vì biết chi phí tối đa, nhà cung cấp linh hoạt về scope dưới trần đó. Đây là mô hình bản ghi gốc của bài này nhắc tới — và là một lựa chọn rất thực dụng.
3. Fixed price per Sprint (giá cố định mỗi Sprint): Mỗi Sprint là một "đơn vị mua". Khách hàng trả một giá cố định cho năng lực của team trong Sprint, còn nội dung làm gì trong Sprint thì linh hoạt theo Product Backlog ưu tiên. Đây thực chất là "fixed-bid theo lát mỏng".
4. Money for Nothing, Change for Free: Một điều khoản nổi tiếng do Jeff Sutherland đề xuất. "Change for Free": khách hàng được đổi/thêm hạng mục trong backlog miễn phí miễn là tổng khối lượng công việc không đổi (đổi item này lấy item kia tương đương). "Money for Nothing": nếu khách hàng thấy đã đủ giá trị và muốn dừng sớm, họ trả một phần (ví dụ 20%) phần hợp đồng còn lại và kết thúc — đôi bên cùng lợi.
5. Fixed-bid "kinh điển" nhưng quản lý theo Agile bên trong: Đôi khi bạn buộc phải ký fixed-bid thật. Khi đó, Agile vẫn áp dụng được ở cách thực thi nội bộ (Sprint, demo, ưu tiên hóa, giao tăng dần), nhưng bạn phải quản lý scope cực kỳ chặt qua quy trình change request.
Nguyên tắc vàng: cố định ngân sách, linh hoạt phạm vi
Câu thần chú khi đàm phán fixed-bid theo tinh thần Agile là: "Fix the budget, flex the scope" (cố định ngân sách, để phạm vi co giãn). Thay vì hứa "tôi giao đủ 200 tính năng với giá X", hãy đề xuất "với ngân sách X và Y Sprint, chúng ta sẽ liên tục giao những tính năng giá trị nhất theo thứ tự ưu tiên, và tôi đảm bảo bạn luôn nhận được phần giá trị cao nhất trước". Điều này đòi hỏi một Product Owner mạnh và một backlog được ưu tiên hóa nghiêm túc.
Tình huống thực tế
Tình huống 1 — Công ty outsourcing Việt Nam và khách hàng Nhật
Một công ty phần mềm tại Hà Nội (tạm gọi là FSoft-style, khoảng 60 kỹ sư) ký hợp đồng fixed-bid 1,8 tỷ đồng, thời hạn 6 tháng, để xây dựng hệ thống quản lý kho cho một khách hàng Nhật. Hợp đồng có một bản đặc tả 80 trang liệt kê 240 chức năng.
Đến Sprint thứ 3, đội phát hiện khoảng 30% đặc tả ban đầu là sai hoặc lỗi thời — khách hàng đã thay đổi quy trình kho thực tế nhưng tài liệu không cập nhật. Nếu làm đúng hợp đồng, sản phẩm sẽ vô dụng. Nếu làm theo nhu cầu thật, sẽ "vượt scope" và lỗ.
Scrum Master ở đây đã làm đúng vai trò PSM II: thay vì im lặng cày theo đặc tả, anh tổ chức một buổi Sprint Review có khách hàng tham gia trực tiếp, demo phần đã làm và để khách hàng tự thấy sự lệch giữa tài liệu và thực tế. Sau đó anh phối hợp với Account Manager đề xuất chuyển sang cơ chế change request có định lượng: mỗi thay đổi được quy đổi ra "điểm" và khách hàng được "đổi ngang" những chức năng chưa làm lấy chức năng mới có cùng khối lượng (tinh thần Change for Free). Kết quả: scope tổng không đổi, ngân sách không vỡ, nhưng sản phẩm giao ra đúng nhu cầu thật.
Bài học: Sprint Review thường xuyên là vũ khí mạnh nhất trong fixed-bid. Nó biến "tranh cãi về tài liệu" thành "cùng nhìn sản phẩm thật", và tạo cơ hội tự nhiên để đàm phán đổi scope ngang giá.
Tình huống 2 — Startup fintech Singapore và mô hình "giá cố định mỗi Sprint"
Một startup fintech ở Singapore thuê một team 5 người từ một vendor TP.HCM. Ban đầu khách hàng muốn fixed-bid trọn gói cho cả sản phẩm MVP, nhưng vì sản phẩm còn nhiều bất định (chưa rõ nhu cầu người dùng), vendor đề xuất mô hình fixed price per Sprint: mỗi Sprint 2 tuần có giá cố định 22.000 USD cho năng lực team, và đôi bên cam kết tối thiểu 8 Sprint.
Cái hay là rủi ro được chia sẻ: khách hàng biết chính xác chi phí mỗi Sprint (kiểm soát ngân sách), còn vendor không phải gánh rủi ro scope mơ hồ. Sau Sprint 5, dữ liệu thị trường cho thấy một hướng tính năng quan trọng hơn dự kiến; Product Owner phía khách hàng chỉ cần ưu tiên lại backlog cho các Sprint còn lại — không cần đàm phán lại hợp đồng. Đến Sprint 7, khách hàng thấy đã đủ giá trị cho vòng gọi vốn và quyết định dừng ở Sprint 8 đúng cam kết, không kéo dài vô ích.
Bài học: "Fixed price per Sprint" là điểm ngọt giữa nỗi sợ của khách hàng (mất kiểm soát chi phí) và nhu cầu Agile (linh hoạt scope). Scrum Master nên biết mô hình này để gợi ý cho bộ phận sales/đàm phán khi sản phẩm có độ bất định cao.
Tình huống 3 — Khi buộc phải ký fixed-bid cứng
Một doanh nghiệp gia công ở Đà Nẵng thắng thầu một dự án cho cơ quan nhà nước. Theo luật đấu thầu, hợp đồng bắt buộc là fixed-bid cứng: scope, giá, hạn đều khóa, không có cửa đàm phán đổi scope giữa chừng. Đây là thực tế mà nhiều người Việt gặp.
Trong tình huống này, Agile không thể thay đổi hợp đồng, nhưng vẫn cứu được dự án ở khâu thực thi. Scrum Master đã: (1) ưu tiên backlog theo rủi ro và giá trị, làm các phần khó/mơ hồ nhất trước để lộ rủi ro sớm; (2) duy trì Definition of Done nghiêm để tránh nợ kỹ thuật làm vỡ tiến độ cuối; (3) thiết lập một "vùng đệm" (buffer) khoảng 15% thời gian cho rủi ro phát sinh; và (4) demo nội bộ đều đặn để ban lãnh đạo công ty nhìn thấy tiến độ thực và can thiệp sớm khi lệch. Nhờ làm phần rủi ro trước, đội phát hiện một vấn đề tích hợp lớn ngay Sprint 2 thay vì tháng cuối — đủ thời gian để xử lý.
Bài học: Khi không đổi được hợp đồng, Agile vẫn giúp bạn lộ rủi ro sớm và bảo vệ chất lượng. Sắp xếp backlog để "thất bại sớm, thất bại rẻ" là chiến lược sống còn trong fixed-bid cứng.
Hướng dẫn từng bước
Khi bạn đối mặt với một dự án fixed-bid, đây là lộ trình hành động của một Scrum Master PSM II:
Bước 1 — Hiểu rõ ràng buộc thật của hợp đồng. Đọc kỹ điều khoản: scope khóa đến mức nào? Có cơ chế change request không? Có điều khoản nghiệm thu theo giai đoạn không? Bạn không cần là luật sư, nhưng phải biết "luật chơi" trước khi tư vấn.
Bước 2 — Định vị nỗi sợ của khách hàng. Khách hàng sợ vượt ngân sách, sợ không nhận được thứ cần, hay sợ vendor làm chậm? Câu trả lời quyết định mô hình hợp đồng nào phù hợp để đề xuất.
Bước 3 — Đề xuất mô hình hợp đồng linh hoạt nhất khả thi. Nếu còn ở giai đoạn đàm phán, đẩy về phía T&M-có-trần hoặc fixed-price-per-Sprint. Nếu đã ký cứng, chấp nhận và chuyển sang tối ưu khâu thực thi.
Bước 4 — Xây Product Backlog được ưu tiên hóa nghiêm túc. Đây là trái tim của "flex the scope". Sắp xếp theo giá trị và rủi ro. Làm phần rủi ro cao và giá trị cao trước.
Bước 5 — Thiết lập nhịp Sprint Review có khách hàng. Biến mỗi Sprint Review thành điểm đồng bộ kỳ vọng. Đây là nơi đàm phán đổi scope diễn ra tự nhiên dựa trên sản phẩm thật, không phải dựa trên tài liệu chết.
Bước 6 — Bảo vệ chất lượng bằng Definition of Done. Trong fixed-bid, áp lực cắt chất lượng là khủng khiếp. Bạn phải làm cho DoD trở thành đường ranh không thể vượt qua, và giúp lãnh đạo hiểu nợ kỹ thuật sẽ phá vỡ chính cái deadline họ muốn bảo vệ.
Bước 7 — Quản lý change request minh bạch. Mọi thay đổi scope phải được ghi nhận, định lượng, và đưa ra quyết định công khai: đổi ngang, thêm ngân sách, hay bỏ bớt phần khác. Đừng để scope creep âm thầm bào mòn team.
Lỗi thường gặp & mẹo
Lỗi 1 — Im lặng "cày" theo đặc tả dù biết nó sai. Đây là phản xạ phổ biến trong văn hóa outsourcing: "khách bảo gì làm nấy". Nhưng giao đúng tài liệu mà sai nhu cầu là thất bại đắt nhất. Mẹo: dùng Sprint Review để khách tự thấy sự lệch, đừng tranh cãi tay đôi.
Lỗi 2 — Hy sinh chất lượng để giữ deadline. Cắt test, bỏ refactor để "kịp giao". Nợ kỹ thuật trong fixed-bid sẽ bùng nổ đúng vào tháng cuối — lúc bạn không còn thời gian. Mẹo: làm phần khó nhất trước, giữ DoD nghiêm từ Sprint 1.
Lỗi 3 — Coi fixed-bid là "không thể Agile". Sai. Ngay cả hợp đồng cứng nhất vẫn áp dụng được Agile ở khâu thực thi: ưu tiên hóa, giao tăng dần, lộ rủi ro sớm.
Lỗi 4 — Để scope creep không kiểm soát. Vì ngại làm khách phật lòng, nhiều team âm thầm nhận thêm việc "miễn phí". Điều này vừa làm vỡ ngân sách vừa làm cháy team. Mẹo: mọi thay đổi đều minh bạch và định lượng.
Lỗi 5 — Scrum Master đứng ngoài chuyện hợp đồng. Bạn không ký hợp đồng, nhưng bạn là người hiểu rõ nhất tác động của điều khoản hợp đồng lên team. Hãy chủ động đưa tiếng nói của empirical process vào bàn đàm phán — đó chính là vai trò gỡ impediment tổ chức của PSM II.
Mẹo vàng: Khi nói chuyện với sales/lãnh đạo về fixed-bid, đừng dùng từ "Agile" trừu tượng. Hãy nói ngôn ngữ của họ: rủi ro, ngân sách, kiểm soát, niềm tin khách hàng. "Mô hình này giúp khách kiểm soát chi phí tốt hơn và ta giảm rủi ro lỗ" thuyết phục hơn nhiều "ta nên làm Agile".
Bài tập thực hành
Bài 1 — Phân loại hợp đồng: Lấy một dự án hiện tại (hoặc gần đây) của bạn. Xác định nó thuộc mô hình nào trong 5 mô hình ở trên. Scope, time, cost — cái nào đang bị khóa cứng? Biến nào đang âm thầm bị "co giãn" để bù (gợi ý: thường là chất lượng)?
Bài 2 — Đề xuất chuyển đổi: Giả sử bạn được mời tư vấn cho Tình huống 1 (công ty Hà Nội, khách Nhật) trước khi ký hợp đồng. Viết một đề xuất ngắn (nửa trang) thuyết phục khách hàng chuyển từ fixed-bid trọn gói sang một mô hình linh hoạt hơn — và nhớ trả lời nỗi sợ của họ về kiểm soát ngân sách.
Bài 3 — Kịch bản Change for Free: Đội bạn đang làm fixed-bid với 100 điểm story. Khách hàng muốn thêm một tính năng mới trị giá 15 điểm. Hãy soạn cách bạn sẽ trình bày với khách phương án "đổi ngang": bỏ/hoãn 15 điểm tính năng ưu tiên thấp nhất chưa làm để đổi lấy tính năng mới, giữ tổng scope không đổi.
Bài 4 — Bảo vệ chất lượng: Lãnh đạo yêu cầu team bạn bỏ qua automated test 3 Sprint cuối để "kịp deadline" fixed-bid. Viết ra 3 luận điểm bạn sẽ dùng để phản biện, bằng ngôn ngữ rủi ro/chi phí mà lãnh đạo hiểu.
Tóm tắt
Fixed-bid và Agile căng thẳng với nhau ở một điểm cốt lõi: fixed-bid khóa cứng cả phạm vi, thời gian, chi phí — còn Agile cố định thời gian và chi phí để phạm vi linh hoạt. Khi cả ba bị khóa, thứ duy nhất bị hy sinh âm thầm là chất lượng.
Là Scrum Master PSM II, bạn không né tránh thực tế fixed-bid — nó là một phần không thể tránh của ngành, đặc biệt ở Việt Nam và Đông Nam Á. Thay vào đó, bạn:
- Hiểu nỗi sợ thật của khách hàng (mất kiểm soát chi phí, không nhận được thứ cần) và thiết kế hợp đồng để xoa dịu nó.
- Biết phổ các mô hình từ T&M, T&M-có-trần, fixed-price-per-Sprint, đến Change for Free / Money for Nothing — và đề xuất mô hình linh hoạt nhất khả thi.
- Áp dụng câu thần chú "Fix the budget, flex the scope" thông qua một backlog được ưu tiên hóa nghiêm túc.
- Khi buộc phải ký fixed-bid cứng, dùng Agile ở khâu thực thi để lộ rủi ro sớm và bảo vệ chất lượng bằng Definition of Done.
- Đưa tiếng nói của empirical process vào bàn đàm phán hợp đồng — đó chính là cách bạn gỡ một impediment tổ chức ở tầm cao.