Tiêu chí done là câu trả lời cho câu hỏi rất đời thường: làm tới mức nào thì xem như xong. Không phải “xây gần đủ”, không phải “đội dev hiểu sao làm vậy”, mà là một mốc rõ ràng để tất cả cùng nhìn vào và biết việc đã đủ điều kiện nghiệm thu hay chưa.
Nhiều brief không có phần này vì brief được viết quá sớm, khi bài toán phần mềm còn đang ở mức mơ hồ. Mọi người mới dừng ở ý tưởng, chưa đi đến mức chốt rõ kết quả mong muốn, phạm vi làm và không làm, các trade-off sản phẩm, và ai có quyền quyết định cuối cùng trước khi build.
Tiêu chí done là gì?
Tiêu chí done là tập hợp các điều kiện cụ thể để xác nhận một tính năng hoặc một hạng mục đã hoàn thành. Nó không chỉ nói làm cái gì, mà còn nói thế nào thì đủ.
Ví dụ, thay vì ghi “làm màn hình đăng ký”, brief có tiêu chí done sẽ ghi rõ:
- Người dùng nhập email và mật khẩu, tạo tài khoản thành công.
- Hiển thị lỗi rõ ràng nếu email đã tồn tại.
- Gửi email xác thực sau khi đăng ký.
- Hoạt động ổn trên mobile và desktop.
- Tracking sự kiện đăng ký thành công được ghi nhận.
- Không làm đăng nhập bằng Google ở giai đoạn này.
Khi có tiêu chí done, đội build không phải đoán. Đội kinh doanh, sản phẩm, thiết kế và kỹ thuật cũng có chung một chuẩn để nói chuyện.
Vì sao nhiều brief không có phần này?
Lý do phổ biến nhất là brief đang mô tả mong muốn, chứ chưa mô tả điều kiện thi công. Nói ngắn gọn: mọi người đã muốn chạy, nhưng chưa buộc nhau trả lời những câu hỏi cần chốt trước khi xây.
Các nguyên nhân thường gặp:
- Bài toán mới ở mức ý tưởng: biết mình muốn tăng doanh thu hay tối ưu vận hành, nhưng chưa rõ phần mềm cần thay đổi hành vi nào.
- Scope chưa được khóa: ai cũng có thêm ý, nên brief luôn ở trạng thái mở rộng.
- Không có Decision Freeze: chưa có thời điểm chốt quyết định trước khi build, nên tiêu chí done không thể ổn định.
- Không rõ quyền quyết định: founder, vận hành, sale, marketing, tech cùng góp ý nhưng không ai là người chốt cuối.
- Sợ mất cơ hội: nhiều người nghĩ ghi quá rõ sẽ làm dự án “kém linh hoạt”, nên để mơ hồ cho dễ xoay.
Thực tế thì ngược lại: càng mơ hồ trước khi build, càng tốn tiền để sửa sau khi build.
Ba mức hiểu bài toán phần mềm
Để hiểu vì sao brief thiếu tiêu chí done, có thể nhìn bài toán theo ba mức:
Mức 1: Biết mình muốn gì, nhưng mô tả bằng cảm giác
Đây là kiểu: “cần app đẹp hơn”, “cần quy trình gọn hơn”, “cần AI hỗ trợ team”. Ở mức này, mục tiêu còn rộng và ngôn ngữ còn cảm tính. Không thể viết tiêu chí done tốt vì chưa định nghĩa rõ đầu ra.
Mức 2: Biết tính năng cần làm, nhưng chưa chốt điều kiện hoàn thành
Ví dụ đã biết cần dashboard, phân quyền, duyệt đơn, thông báo. Nhưng khi hỏi sâu hơn thì chưa rõ ai dùng trước, trường hợp ngoại lệ nào phải xử lý, cái gì là bắt buộc trong phase đầu, cái gì để sau. Đây là mức rất nhiều dự án dừng lại.
Mức 3: Làm rõ đủ để thi công
Ở mức này, đội ngũ đã chuyển từ “ý tưởng tính năng” sang “build-commit brief”. Tức là brief đủ rõ để một đội triển khai có thể cam kết phạm vi và hiểu thế nào là done. Mức 3 thường có đủ:
- Mục tiêu cụ thể.
- Đối tượng sử dụng chính.
- Luồng chính và ngoại lệ quan trọng.
- Scope in scope out.
- Trade-off đã chấp nhận.
- Người quyết định cuối cùng.
- Decision Freeze trước khi build.
- Tiêu chí done cho từng hạng mục trọng yếu.
Nếu chưa lên được mức 3, brief thường thiếu phần done là chuyện rất dễ hiểu.
Bước thực tế để kéo dự án lên mức đủ rõ trước khi thi công
1. Chốt bài toán trước khi chốt tính năng
Đừng bắt đầu bằng danh sách màn hình. Hãy trả lời trước:
- Vấn đề nào đang cần giải quyết?
- Ai đang chịu đau nhất vì vấn đề đó?
- Nếu làm xong, chỉ số hay hành vi nào sẽ thay đổi?
Khi bài toán rõ, việc viết tiêu chí done mới không bị lan man.
2. Viết scope in và scope out
Một brief tốt không chỉ nói làm gì mà còn phải nói không làm gì. Đây là cách giảm hiểu sai và cắt bớt tranh cãi giữa chừng.
Ví dụ:
- In scope: đăng ký bằng email, xác thực email, quên mật khẩu.
- Out of scope: đăng nhập social, SSO, referral, chương trình điểm thưởng.
Khi scope out được ghi rõ, tiêu chí done mới có biên.
3. Chấp nhận trade-off sản phẩm
Nhiều brief thiếu done vì người viết muốn giữ mọi khả năng cùng lúc: nhanh, đủ, rẻ, đẹp, linh hoạt, ít rủi ro. Nhưng phần mềm luôn cần trade-off. Nếu phase 1 ưu tiên ra thị trường nhanh, thì có thể chấp nhận chưa có toàn bộ automation, chưa tối ưu toàn bộ edge case.
Trade-off không phải làm ẩu. Trade-off là quyết định có ý thức để biết cái gì làm ngay, cái gì để sau.
4. Tạo build-commit brief
Đây là bản brief mà sau khi chốt, đội triển khai có thể bắt đầu build mà không phải liên tục quay lại hỏi những câu nền tảng. Bản này nên có:
- Mục tiêu và bối cảnh.
- Persona hoặc nhóm người dùng chính.
- User flow cốt lõi.
- Danh sách hạng mục trong phạm vi.
- Danh sách hạng mục ngoài phạm vi.
- Ràng buộc kỹ thuật hoặc vận hành.
- Tiêu chí done.
- Người duyệt cuối.
5. Chốt Decision Freeze
Decision Freeze là thời điểm tuyên bố: từ đây, các quyết định nền tảng đã được chốt để bắt đầu build. Sau mốc này, thay đổi vẫn có thể xảy ra, nhưng phải đi qua cơ chế change request, không được chen ngang như góp ý bình thường.
Nếu không có Decision Freeze, tiêu chí done sẽ luôn bị xê dịch theo mỗi buổi họp.
Cách chốt cái gì làm, không làm và ai có quyền quyết định
Đây là phần rất nhiều đội bỏ qua. Họ có danh sách việc, nhưng không có cơ chế ra quyết định. Kết quả là brief càng ngày càng dài mà vẫn không thi công chắc tay.
Cách làm gọn:
- Liệt kê các quyết định cần chốt trước khi build: tính năng cốt lõi, đối tượng ưu tiên, mốc thời gian, tiêu chí nghiệm thu, tích hợp bắt buộc.
- Gán người chốt cuối cho từng nhóm quyết định: ví dụ founder chốt ưu tiên kinh doanh, PM chốt phạm vi triển khai, tech lead chốt giới hạn kỹ thuật.
- Ghi lại quyết định bằng văn bản: tránh kiểu “hôm đó em nhớ anh có nói”.
- Tách ý tưởng mới khỏi scope hiện tại: đưa vào backlog thay vì chen vào brief đang chuẩn bị build.
Khi ai có quyền quyết định đã rõ, tiêu chí done mới không bị mỗi người kéo theo một hướng.
Mẫu câu hỏi dùng ngay trong buổi làm rõ đầu tiên
Dưới đây là checklist ngắn để kéo brief từ mơ hồ sang đủ điều kiện thi công:
- Vấn đề kinh doanh hoặc vận hành nào đang cần giải quyết?
- Ai là người dùng chính của tính năng này?
- Hành vi nào của người dùng cần thay đổi sau khi làm xong?
- Luồng chính từ đầu đến cuối là gì?
- 3 tình huống lỗi hoặc ngoại lệ quan trọng nhất là gì?
- Trong phase này, bắt buộc phải có những gì?
- Những gì chủ động không làm ở phase này?
- Nếu phải cắt bớt để ra nhanh hơn, cắt phần nào trước?
- Ai là người duyệt cuối nếu có ý kiến trái chiều?
- Khi nào thì xem hạng mục này là done?
Chỉ cần cả team trả lời rõ 10 câu này, chất lượng brief đã khác rất nhiều.
Một mẫu tiêu chí done đơn giản
Với mỗi hạng mục, có thể dùng cấu trúc sau:
- Kết quả người dùng đạt được: người dùng làm được việc gì.
- Điều kiện vận hành: ai được dùng, trên nền tảng nào, dữ liệu đi đâu.
- Điều kiện kiểm tra: test case chính nào phải pass.
- Giới hạn phạm vi: chưa hỗ trợ điều gì trong phase này.
- Chỉ số hoặc tín hiệu xác nhận: log, tracking, trạng thái hệ thống, báo cáo.
Ví dụ cho hạng mục “duyệt đơn”:
- Quản lý có thể duyệt hoặc từ chối đơn trên web.
- Nhân viên thường không nhìn thấy nút duyệt.
- Khi duyệt thành công, trạng thái đơn chuyển sang “Đã duyệt”.
- Hệ thống lưu người duyệt và thời gian duyệt.
- Gửi thông báo cho bộ phận liên quan sau khi duyệt.
- Phase này chưa hỗ trợ duyệt nhiều đơn cùng lúc.
Các phản đối thường gặp từ founder và cách xử lý
“Cứ làm nhanh đi, done tính sau”
Nếu làm nhanh mà không có done, đội triển khai sẽ phải tự định nghĩa chuẩn hoàn thành. Tốc độ ban đầu có thể nhanh, nhưng chi phí sửa, tranh luận và lệch kỳ vọng sẽ xuất hiện ngay sau đó.
Cách xử lý: không cần biến brief thành tài liệu dài. Chỉ cần chốt tối thiểu các điều kiện done cho những hạng mục quan trọng nhất trước khi build.
“Startup thì phải linh hoạt”
Đúng, nhưng linh hoạt không có nghĩa là mơ hồ. Linh hoạt là biết chỗ nào còn mở để thử nghiệm, và chỗ nào phải khóa để triển khai không đổ vỡ.
Cách xử lý: xác định rõ phần nào mở để học nhanh, phần nào đóng để giao hàng đúng hẹn.
“Viết kỹ quá sẽ chậm”
Viết mọi thứ thật dài có thể chậm. Nhưng chốt những quyết định bắt buộc trước khi build lại giúp tổng thời gian ngắn hơn. Chậm một chút trước, đỡ chậm rất nhiều sau.
Cách xử lý: giới hạn phiên làm rõ trong 60 đến 90 phút và bắt buộc ra được scope, owner quyết định và tiêu chí done tối thiểu.
“Dev cứ làm rồi mình xem”
Đây là cách dễ đẩy rủi ro sang đội build. Khi founder nói “xem rồi sửa”, chi phí học thường bị chuyển thành chi phí code lại.
Cách xử lý: tách phần cần prototype để học nhanh khỏi phần cần build thật để vận hành.
Khi nào brief được xem là đủ điều kiện thi công?
Một brief đủ điều kiện thi công không nhất thiết phải dài. Nhưng nó cần trả lời rõ các câu hỏi nền tảng sau:
- Bài toán là gì?
- Ai là người dùng chính?
- Scope in và scope out là gì?
- Trade-off nào đã được chấp nhận?
- Ai có quyền quyết định cuối cùng?
- Decision Freeze diễn ra khi nào?
- Tiêu chí done cho từng phần quan trọng là gì?
Nếu chưa có các phần này, dự án rất dễ dừng ở mức “brief để thảo luận”, chưa phải “brief để build”.
Kết luận
Tiêu chí done không phải phần phụ. Nó là điểm nối giữa ý tưởng và thi công. Khi brief thiếu phần này, nguyên nhân thường không nằm ở câu chữ mà nằm ở việc bài toán chưa được làm rõ đến mức đủ để cam kết triển khai.
Đầu ra lý tưởng trước khi build là một bản mô tả đã đủ điều kiện thi công: mục tiêu rõ, scope rõ, trade-off rõ, quyền quyết định rõ, có Decision Freeze và có tiêu chí done đủ cụ thể để đội ngũ không phải đoán. Đó là lúc dự án thật sự chuyển từ “nói về phần mềm” sang “xây đúng phần mềm cần xây”.
