Decision Freeze là thời điểm hai bên chốt đủ rõ để có thể thi công phần mềm mà không tiếp tục lắc qua lắc lại những quyết định nền tảng. Nói đời thường, đây là lúc bạn ngừng kiểu “để làm rồi tính tiếp” và chuyển sang “đã rõ cái gì phải làm, cái gì không làm, vì sao làm và ai là người chốt”. Chính điểm chốt này cứu ngân sách vì phần lớn tiền bị đốt không nằm ở dòng code, mà nằm ở các lần đổi ý muộn, sửa qua sửa lại và mở rộng phạm vi vô thức.
Với người mua phần mềm, rủi ro lớn nhất không phải là đội kỹ thuật làm chậm, mà là bài toán chưa được làm rõ đúng mức trước khi build. Khi chưa rõ, mọi cam kết về giá, deadline và kết quả đều chỉ là ước lượng mong manh. Càng thi công trong mơ hồ, xác suất phát sinh càng cao. Decision Freeze giúp khóa các quyết định quan trọng ở thời điểm chi phí thay đổi còn rẻ, thay vì để tới lúc đã build rồi mới nhận ra đang đi sai hướng.
Decision Freeze là gì
Decision Freeze là cơ chế chốt quyết định trước khi build. Nó không có nghĩa là từ đây về sau không được thay đổi gì. Nó có nghĩa là mọi thay đổi sau mốc này phải đi qua nguyên tắc rõ ràng: thay cái gì, đổi lấy cái gì, ai duyệt và tác động tới chi phí, thời gian, chất lượng ra sao. Nói cách khác, đây là bước chuyển từ nói ý tưởng sang build-commit brief: một bản mô tả đủ rõ để đội triển khai cam kết thi công.
Một Decision Freeze tốt thường khóa được 5 nhóm quyết định:
- Mục tiêu: dự án phải tạo ra kết quả kinh doanh gì trong giai đoạn này.
- Scope: những gì chắc chắn làm trong phiên bản này.
- Scope out: những gì chủ động không làm ở phiên bản này.
- Trade-off sản phẩm: nếu phải chọn, ưu tiên sẽ nghiêng về tốc độ, chi phí hay độ đầy đủ.
- Quyền quyết định: ai là người chốt cuối khi có xung đột giữa ý muốn và nguồn lực.
Ba mức hiểu bài toán phần mềm
Nhiều dự án phần mềm thất thoát ngân sách vì dừng ở mức hiểu chưa đủ để build, nhưng mọi người lại tưởng là đã rõ.
Mức 1: Biết mình muốn gì ở bề mặt
Đây là mức “tôi muốn một app giống A”, “tôi cần CRM cho đội sales”, “tôi muốn khách đặt lịch online”. Mức này mô tả mong muốn, chưa mô tả bài toán. Nó hữu ích để mở đầu, nhưng hoàn toàn chưa đủ để chốt báo giá hoặc timeline đáng tin.
Mức 2: Biết chức năng cần có
Ở mức này, người mua đã kể được các tính năng như đăng nhập, phân quyền, báo cáo, thông báo, thanh toán. Nhiều dự án dừng ở đây vì tưởng rằng liệt kê chức năng là đủ. Nhưng thực tế, cùng một chức năng có thể có 5 cách làm khác nhau về luồng xử lý, dữ liệu, ngoại lệ và mức độ tự động hóa. Khác nhau ở đây chính là tiền.
Mức 3: Làm rõ được quyết định vận hành và ranh giới
Đây là mức đủ để build. Không chỉ biết chức năng nào tồn tại, mà còn biết trong tình huống thực tế hệ thống phải xử lý ra sao, ai thao tác, dữ liệu đến từ đâu, điều gì là ngoại lệ, điều gì bị loại khỏi scope và khi xung đột xảy ra thì ưu tiên nào thắng. Level 3 là nơi Decision Freeze phát huy tác dụng mạnh nhất, vì nó biến ý tưởng thành một bản build-commit brief có thể thi công.
Vì sao nhiều dự án dừng ở mức 1 hoặc mức 2
- Founder hoặc chủ dự án nghĩ rằng nói càng nhanh, làm càng sớm thì càng tiết kiệm, trong khi chi phí đổi ý muộn thường lớn hơn rất nhiều.
- Hai bên sợ mất momentum nên né phần khó nhất: chốt ưu tiên và chấp nhận đánh đổi.
- Mọi người quen nói bằng tính năng, không quen nói bằng dòng vận hành thực tế.
- Không ai được chỉ định là người có quyền quyết định cuối cùng, nên họp nhiều nhưng không khóa được gì.
- Vendor muốn vào làm sớm để giữ deal, còn phía mua muốn nghe câu trả lời chắc chắn khi dữ liệu vẫn còn mơ hồ.
Kết quả là dự án bước vào thi công với cảm giác “đã thống nhất”, nhưng thực ra chỉ mới thống nhất bề mặt. Khi bắt đầu làm sâu, hàng loạt câu hỏi mới xuất hiện và mỗi câu hỏi đều kéo theo chi phí.
Decision Freeze cứu ngân sách như thế nào
1. Chặn chi phí đổi ý ở giai đoạn đắt tiền
Thay đổi trên giấy luôn rẻ hơn thay đổi sau khi đã thiết kế, code, test và đào tạo người dùng. Decision Freeze buộc các quyết định nền tảng phải được đưa ra trước khi build, khi việc sửa vẫn còn rẻ.
2. Giảm trượt scope
Nhiều khoản phát sinh không đến từ yêu cầu mới hoàn toàn, mà đến từ các câu như “sẵn tiện làm thêm cái này”, “cái này chắc nhỏ thôi”. Nếu không có scope in, scope out và nguyên tắc trade-off, dự án sẽ phình ra từng chút mà không ai nhận ra. Decision Freeze tạo ranh giới để mọi bổ sung đều phải đi qua câu hỏi: thêm cái này thì bỏ cái gì, tăng bao nhiêu thời gian hoặc chi phí.
3. Tạo nền cho báo giá và kế hoạch đáng tin hơn
Khi bài toán đạt Level 3, đội làm phần mềm có đủ dữ liệu để bóc tách công việc, chỉ ra rủi ro và đưa ra cam kết sát hơn. Ngược lại, báo giá trên nền mơ hồ thường chỉ có hai kịch bản: hoặc rẻ để thắng deal rồi phát sinh sau, hoặc đắt để phòng rủi ro mà vẫn không chắc đúng.
4. Tránh tranh cãi cảm tính giữa các bên
Khi chưa có Decision Freeze, mọi cuộc tranh luận dễ quay về cảm giác cá nhân: “em nghĩ nên”, “anh thấy cần”, “bên kia làm được mà”. Khi đã có bản chốt rõ, mọi quyết định được soi lại theo mục tiêu, phạm vi và trade-off đã thống nhất. Điều này giảm xung đột và giữ năng lượng cho việc thực thi.
Bước đi thực tế để kéo dự án lên mức đủ rõ trước khi thi công
Bước 1: Viết lại mục tiêu theo ngôn ngữ kết quả
Đừng mở đầu bằng danh sách tính năng. Hãy bắt đầu bằng một câu rõ ràng: sau giai đoạn này, doanh nghiệp muốn cải thiện điều gì. Ví dụ: giảm thời gian xử lý lead từ 2 ngày xuống 4 giờ, giảm sai sót nhập liệu 50%, hoặc giúp khách hoàn tất đặt lịch không cần gọi điện.
Bước 2: Chọn một luồng nghiệp vụ quan trọng nhất
Thay vì nói chung chung toàn hệ thống, hãy lấy 1 đến 3 luồng quan trọng nhất và đi tới tận cùng. Ví dụ: từ lúc lead vào đến lúc giao sale, hoặc từ lúc khách chọn dịch vụ đến khi thanh toán thành công. Đây là cách làm rõ bài toán phần mềm nhanh và thực tế nhất.
Bước 3: Làm rõ ngoại lệ
Ngoại lệ là nơi ngân sách bị rò rỉ. Ai sửa dữ liệu khi người dùng nhập sai, đơn hàng thất bại thì xử lý thế nào, quyền hoàn tiền thuộc ai, một người có thể giữ bao nhiêu vai trò. Nếu chỉ mô tả luồng đẹp, dự án sẽ vỡ khi gặp đời thật.
Bước 4: Chốt scope in và scope out
Scope in là cái chắc chắn làm. Scope out là cái chủ động không làm ở giai đoạn này. Cả hai đều quan trọng như nhau. Nhiều người chỉ thích nói cái sẽ làm, nhưng không dám nói cái chưa làm. Chính sự mập mờ này làm dự án trượt ngân sách.
Bước 5: Chốt trade-off sản phẩm
Không có dự án nào đồng thời tối ưu mọi thứ. Nếu ngân sách cố định, bạn phải chấp nhận giảm phạm vi hoặc mức độ tinh chỉnh. Nếu deadline cứng, phải bớt tính năng hoặc tăng nguồn lực. Decision Freeze buộc bên mua và bên làm nhìn thẳng vào đánh đổi thay vì né tránh.
Bước 6: Xác định người có quyền quyết định cuối
Nếu một cuộc họp có 6 người góp ý mà không ai có quyền chốt, thì sau họp không có quyết định nào thực sự tồn tại. Cần ghi rõ ai đề xuất, ai phản biện, ai duyệt cuối cùng và trong bao lâu phải phản hồi.
Bước 7: Biến tất cả thành build-commit brief
Đầu ra lý tưởng không phải là file dày, mà là một bản mô tả ngắn gọn nhưng đủ điều kiện thi công: mục tiêu, người dùng chính, luồng chính, ngoại lệ quan trọng, scope in, scope out, phụ thuộc, tiêu chí nghiệm thu và cơ chế xử lý thay đổi. Khi tài liệu này được duyệt, dự án mới thực sự sẵn sàng bước vào build.
Cách chốt cái gì làm, không làm và ai có quyền quyết định
Bạn có thể dùng một khung rất đơn giản trong buổi làm rõ đầu tiên:
- Làm: Những hạng mục bắt buộc để đạt mục tiêu của giai đoạn này.
- Không làm: Những hạng mục có thể có giá trị nhưng chưa cần trong giai đoạn này.
- Điều kiện đổi: Muốn thêm cái mới thì phải bỏ cái gì hoặc tăng nguồn lực nào.
- Người chốt: Một người chịu trách nhiệm ra quyết định cuối cùng cho từng nhóm vấn đề.
Ví dụ thực tế: nếu mục tiêu là ra mắt nhanh để kiểm chứng nhu cầu, trade-off có thể là ưu tiên tốc độ ra mắt hơn độ tùy biến báo cáo. Khi đó, báo cáo nâng cao sẽ được đưa vào scope out. Nếu sau đó founder muốn thêm dashboard phức tạp, cần chốt ngay: lùi ngày ra mắt, tăng ngân sách hoặc bỏ bớt một phần khác. Đây chính là cơ chế scope in scope out vận hành đúng.
Mẫu câu hỏi dùng ngay trong buổi làm rõ đầu tiên
- Bài toán kinh doanh nào đang khiến anh/chị phải làm phần mềm này ngay bây giờ?
- Nếu chỉ được giải quyết một điểm đau trong 8 tuần tới, đó là gì?
- Người dùng chính là ai và họ đang làm việc theo cách nào hôm nay?
- Luồng nào xảy ra thường xuyên nhất và đang tốn thời gian nhất?
- Ngoại lệ nào xảy ra ít nhưng gây thiệt hại lớn nhất?
- Phiên bản đầu tiên chắc chắn phải có gì để dùng được ngoài đời?
- Những gì chắc chắn không làm trong giai đoạn này là gì?
- Nếu muốn thêm một hạng mục mới, anh/chị sẵn sàng đổi bớt phần nào?
- Khi có bất đồng giữa các bên, ai là người quyết định cuối cùng?
- Tiêu chí nào để xem là đã xong và nghiệm thu được?
Checklist Decision Freeze trước khi build
- Mục tiêu giai đoạn đã được viết thành kết quả đo được hoặc quan sát được.
- Người dùng chính và bối cảnh sử dụng đã rõ.
- 3 luồng nghiệp vụ quan trọng nhất đã được mô tả từ đầu đến cuối.
- Ngoại lệ quan trọng đã được nhận diện.
- Scope in và scope out đã được ghi rõ bằng văn bản.
- Trade-off về thời gian, chi phí, chất lượng đã được chấp nhận.
- Người có quyền quyết định cuối cùng đã được chỉ định.
- Tiêu chí nghiệm thu đã rõ.
- Cơ chế xử lý change request sau khi build bắt đầu đã rõ.
- Hai bên cùng xác nhận tài liệu đã đủ điều kiện thi công.
Các phản đối thường gặp từ founder và cách xử lý
“Làm trước đi rồi tính”
Phản hồi phù hợp là: có thể làm sớm, nhưng phải biết đang khóa quyết định nào trước. Nếu không Decision Freeze, chi phí “tính sau” thường quay lại dưới dạng phát sinh, trễ hạn và mệt mỏi cho cả hai bên.
“Startup cần linh hoạt, freeze nghe cứng quá”
Linh hoạt không có nghĩa là thay đổi vô kỷ luật. Decision Freeze không giết sự linh hoạt, mà tạo luật chơi cho thay đổi. Bạn vẫn đổi được, nhưng đổi minh bạch và biết cái giá phải trả.
“Tài liệu nhiều sẽ làm chậm dự án”
Không cần tài liệu dài. Điều cần là tài liệu đủ rõ. Một build-commit brief 2 đến 5 trang nhưng chốt được quyết định quan trọng thường tốt hơn một tài liệu 30 trang toàn mô tả bề mặt.
“Bên làm phần mềm phải tự hiểu chứ”
Đội triển khai có thể giúp làm rõ, phản biện và đề xuất giải pháp, nhưng họ không thể thay người mua ra quyết định kinh doanh. Những câu hỏi về ưu tiên, phạm vi và đánh đổi cần được chốt từ phía chủ dự án.
Kết luận
Decision Freeze là một điểm chốt cực kỳ thực dụng: quyết định trước khi build để không phải trả giá đắt sau khi build. Nó đặc biệt quan trọng với các dự án còn đang mơ hồ ở mức 1 hoặc mức 2. Khi bài toán được kéo lên Level 3, bạn mới có cơ hội kiểm soát scope, quản lý trade-off sản phẩm và đưa dự án vào thi công với kỳ vọng thực tế.
Đầu ra lý tưởng của giai đoạn này là một bản mô tả đã đủ điều kiện thi công: rõ mục tiêu, rõ luồng chính, rõ phạm vi làm và không làm, rõ người quyết định và rõ tiêu chí nghiệm thu. Nếu chưa có tài liệu đó, rất có thể bạn chưa thực sự sẵn sàng để build. Và mỗi ngày build trong trạng thái chưa rõ đều là một ngày ngân sách của bạn ở trong vùng rủi ro cao.
