Mở đầu — vì sao bài này quan trọng
Có một nghịch lý mà gần như team Agile nào cũng rơi vào: càng muốn làm việc tốt hơn, người ta càng thêm quy định. Một bug lọt ra production? Thêm một bước review. Một cuộc họp lan man? Thêm một "rule" về timebox. Một thành viên quên cập nhật task? Thêm một policy bắt buộc. Sau sáu tháng, team của bạn có một "Definition of Done" dài hai trang, một quy trình refinement mười bước, và một working agreement mà chính người viết ra cũng không nhớ hết. Mọi người tuân thủ một cách hình thức, năng lượng cạn dần, và điều trớ trêu là chất lượng vẫn không khá hơn.
Đây chính là vấn đề mà Min Specs — viết đầy đủ là Minimum Specifications — ra đời để giải quyết. Min Specs là một trong 33 Liberating Structures (các cấu trúc giải phóng tư duy nhóm), do Henri Lipmanowicz và Keith McCandless hệ thống hóa. Triết lý cốt lõi của nó nghe có vẻ phản trực giác nhưng cực kỳ mạnh: một hệ thống phức tạp vận hành tốt nhất khi nó có ít quy tắc nhất có thể — nhưng đó phải là những quy tắc thực sự không thể thiếu.
Là một Scrum Master, bạn liên tục đối diện với câu hỏi "Quy định này có thực sự cần không?". Min Specs cho bạn một công cụ có cấu trúc để cùng team trả lời câu hỏi đó một cách công tâm, thay vì để cảm tính hay người có tiếng nói to nhất quyết định. Bài học này sẽ giúp bạn hiểu sâu khái niệm, nắm vững quy trình facilitate, và biết khi nào nên rút công cụ này ra khỏi toolbox của mình.
Khái niệm cốt lõi
Phân biệt "Min Specs" với "Max Specs"
Lipmanowicz và McCandless chia mọi quy tắc trong một hệ thống thành hai loại:
- Max Specs (Maximum Specifications): tất cả những thứ bạn có thể làm, nên làm, hoặc thường làm để đạt mục tiêu. Đây là danh sách dài, đầy đủ, thường được tích lũy qua thời gian. Nó bao gồm cả những điều thực sự quan trọng lẫn những điều chỉ là thói quen, là di sản, là "vì sếp cũ thích vậy".
- Min Specs (Minimum Specifications): tập con nhỏ nhất của Max Specs mà nếu thiếu bất kỳ điều nào trong đó, hệ thống sẽ thất bại trong việc đạt mục đích. Nói cách khác, đây là các ràng buộc tối thiểu — bỏ thêm một cái nữa là sập.
Vì sao "ít quy tắc" lại tạo ra nhiều tự do và hiệu quả hơn
Khi một hệ thống bị nhồi nhét quá nhiều quy tắc (over-engineering, over-specification), ba điều xấu xảy ra:
- Mất khả năng thích ứng: mỗi quy tắc là một ràng buộc cứng. Càng nhiều ràng buộc, team càng ít chỗ để tự ứng biến với tình huống cụ thể. Nghịch lý là quy tắc được tạo ra để kiểm soát rủi ro, nhưng quá nhiều quy tắc lại làm tăng rủi ro vì team không còn dùng được phán đoán của chính mình.
- Tuân thủ hình thức: khi danh sách quá dài, người ta ngừng hiểu tại sao và chỉ làm cho có. Một DoD 15 điểm thường được tick qua loa hơn một DoD 4 điểm mà ai cũng tin.
- Che giấu trách nhiệm thực sự: quy tắc thừa làm loãng sự chú ý khỏi vài điều thực sự quan trọng.
Hai "must-do" và "must-not-do"
Min Specs thường được diễn đạt thành hai loại ràng buộc tối thiểu:
- Must-do: những việc bắt buộc phải làm để đạt mục đích.
- Must-not-do: những việc tuyệt đối không được làm (vì sẽ phá hỏng mục đích).
Tình huống thực tế
Ví dụ 1 — Tiki: khi Definition of Done phình to thành 14 dòng
Một team phát triển tính năng thanh toán tại một công ty thương mại điện tử lớn ở TP.HCM (lấy bối cảnh kiểu Tiki) có một Definition of Done dài 14 mục, tích lũy qua hai năm. Mỗi sự cố production lại sinh ra một dòng mới: "phải có screenshot test", "phải update Confluence", "phải có 2 reviewer approve", "phải chạy đủ 4 loại test"... Velocity của team tụt dần và ai cũng cảm thấy ngột ngạt, nhưng không ai dám đề xuất bỏ bớt vì sợ bị quy trách nhiệm nếu sau này xảy ra lỗi.
Scrum Master tổ chức một buổi Min Specs 50 phút trong retrospective. Đầu tiên cả team viết lại toàn bộ 14 mục lên bảng (đây là Max Specs). Sau đó, với từng mục, họ tự hỏi: "Nếu bỏ điều này đi, liệu chúng ta có còn giao được phần mềm chất lượng, an toàn cho khách hàng không?". Kết quả: 14 mục co lại còn 6 Min Specs thực sự. Ví dụ, "update Confluence cho mọi task" bị loại vì nó không ảnh hưởng đến chất lượng sản phẩm giao cho khách — nó chỉ là di sản từ một đời quản lý cũ. Trong khi đó "code đã qua review bảo mật cho luồng thanh toán" thì bắt buộc giữ lại vì bỏ nó là rủi ro thật.
Bài học: phần lớn quy tắc thừa không độc hại vì bản chất, mà vì chúng làm loãng sự chú ý khỏi vài điều thực sự sống còn. Min Specs cho team một "không gian an toàn có cấu trúc" để dám bỏ — vì quyết định là của cả nhóm, không phải của một cá nhân chịu trách nhiệm.
Ví dụ 2 — Startup fintech Singapore: quy trình onboarding khách hàng
Một startup fintech ở Singapore có quy trình KYC (xác minh danh tính khách hàng) gồm 23 bước, khiến thời gian onboarding trung bình lên tới 4 ngày — trong khi đối thủ chỉ mất 30 phút. Đội ngũ vận hành tin rằng "mọi bước đều cần vì lý do tuân thủ pháp lý".
Trong một workshop Min Specs kéo dài 60 phút, họ tách rõ hai câu hỏi: "Bước nào là yêu cầu pháp lý thật (must-do từ luật MAS)?" và "Bước nào là do chúng ta tự thêm cho yên tâm?". Khi soi kỹ, chỉ 9 trong 23 bước là ràng buộc pháp lý bắt buộc. 14 bước còn lại là "phòng xa" tự đặt ra. Họ giữ lại 9 Min Specs cứng, chuyển phần lớn 14 bước kia thành kiểm tra tự động hậu kỳ hoặc bỏ hẳn. Thời gian onboarding giảm từ 4 ngày xuống còn dưới 2 giờ, mà rủi ro tuân thủ không hề tăng — vì những thứ luật pháp thực sự yêu cầu vẫn được giữ nguyên.
Bài học: Min Specs đặc biệt mạnh khi team đang nhầm lẫn giữa "ràng buộc thật từ bên ngoài" và "ràng buộc tự áp đặt". Tách bạch hai loại này thường giải phóng một lượng lớn hiệu suất bị giam giữ một cách vô lý.
Ví dụ 3 — Team mới thành lập: dùng Min Specs để viết Working Agreement
Một công ty outsourcing ở Đà Nẵng thành lập team mới 7 người gồm các thành viên từng làm ở các dự án khác nhau, mỗi người mang theo một bộ "thói quen quy trình" riêng. Thay vì để Scrum Master áp đặt một working agreement có sẵn, anh dùng Min Specs ngay buổi kickoff.
Câu hỏi đóng khung (framing) là: "Để team này hợp tác hiệu quả và vui vẻ trong 6 tháng tới, điều gì là tối thiểu chúng ta phải cùng cam kết — và điều gì tuyệt đối không được làm?". Mỗi người đề xuất danh sách dài (Max Specs), rồi qua các vòng lọc nhóm, team chốt được 5 must-do (ví dụ: "phản hồi tin nhắn công việc trong vòng 4 giờ giờ làm việc") và 3 must-not-do (ví dụ: "không sửa code của người khác mà không báo trước"). Một working agreement 8 dòng, ai cũng nhớ và tin, thay cho một văn bản 2 trang chẳng ai đọc.
Bài học: Min Specs không chỉ dùng để cắt quy tắc cũ, mà còn để xây bộ quy tắc mới một cách tinh gọn ngay từ đầu, tránh phình to ngay từ ngày một.
Hướng dẫn từng bước
Một phiên Min Specs điển hình kéo dài 45–60 phút, phù hợp cho nhóm từ 5 đến vài chục người (chia nhóm nhỏ khi đông). Cấu trúc chuẩn như sau:
Bước 1 — Đóng khung mục đích rõ ràng (5 phút). Đây là bước quan trọng nhất và hay bị làm vội. Bạn phải nêu rõ mục đích cụ thể mà hệ thống/quy trình cần đạt được. Ví dụ: "Mục đích của Definition of Done của chúng ta là gì?" hay "Mục đích thật sự của quy trình refinement này là gì?". Vì Min Specs được định nghĩa tương đối so với mục đích, nếu mục đích mơ hồ thì cả phiên sẽ trôi dạt. Viết mục đích lên bảng để mọi người luôn nhìn thấy.
Bước 2 — Liệt kê Max Specs (10–15 phút). Mời mọi người liệt kê tất cả những việc họ tin là cần làm (must-do) và không được làm (must-not-do) để đạt mục đích. Cứ để danh sách dài và "thừa thãi" — đây đúng là ý đồ. Nếu đang dùng Min Specs để soi một quy trình cũ, hãy viết toàn bộ quy trình hiện hành lên bảng. Làm theo nhóm nhỏ 3–4 người rồi gộp lại nếu nhóm đông.
Bước 3 — Loại bỏ thử từng quy tắc để tìm Min Specs (15–20 phút). Đây là trái tim của phương pháp. Với từng mục trong Max Specs, nhóm đặt một câu hỏi kiểm tra duy nhất: "Nếu chúng ta vi phạm/bỏ điều này, liệu có vẫn đạt được mục đích không?"
- Nếu câu trả lời là "Có, vẫn đạt được" → quy tắc đó không phải Min Spec → loại bỏ.
- Nếu câu trả lời là "Không, sẽ thất bại" → quy tắc đó là Min Spec → giữ lại.
Bước 4 — Tổng hợp và thử thách lại danh sách Min Specs (10 phút). Khi đã có danh sách rút gọn, hỏi thêm một vòng: "Liệu còn cái nào trong danh sách này vẫn có thể bỏ không?". Min Specs thực sự thường ít hơn nhiều so với cảm giác ban đầu — kinh nghiệm cho thấy team thường rút được từ 70–90% xuống còn một nhúm ràng buộc cốt lõi. Diễn đạt mỗi Min Spec thành câu rõ ràng, kiểm chứng được.
Bước 5 — Chốt và hành động (5 phút). Thống nhất bộ Min Specs cuối cùng, ghi lại ở nơi team nhìn thấy, và quyết định cụ thể: những quy tắc bị loại sẽ chính thức ngừng áp dụng từ khi nào, ai cập nhật tài liệu liên quan. Đặt lịch xem lại sau 1–2 sprint để kiểm chứng giả định.
Lỗi thường gặp & mẹo
Lỗi 1 — Đóng khung mục đích quá rộng hoặc mơ hồ. "Mục đích là làm việc tốt hơn" thì không thể dùng để kiểm tra bất cứ quy tắc nào. Mục đích phải đủ cụ thể để câu hỏi "bỏ cái này có đạt được mục đích không?" có câu trả lời rõ ràng. Mẹo: viết mục đích dưới dạng kết quả quan sát được, không phải khẩu hiệu.
Lỗi 2 — Lẫn lộn "không thoải mái" với "không an toàn". Khi đề xuất bỏ một quy tắc quen thuộc, mọi người sẽ thấy bất an. Nhưng bất an không đồng nghĩa với rủi ro thật. Mẹo: với mỗi mục muốn giữ "cho chắc", hãy hỏi thẳng "Điều tệ nhất xảy ra nếu bỏ là gì, và xác suất bao nhiêu?". Thường thì nỗi sợ lớn hơn rủi ro thực tế.
Lỗi 3 — Biến nó thành phiên cắt giảm cực đoan. Min Specs không phải cuộc thi "ai bỏ được nhiều quy tắc nhất". Nếu bỏ một quy tắc thật sự sống còn, hệ thống sẽ sập. Mẹo: nhấn mạnh tiêu chí kép — tối thiểu nhưng đủ. Bộ Min Specs đúng là bộ nhỏ nhất mà vẫn bảo toàn mục đích.
Lỗi 4 — Người có quyền lực áp đặt câu trả lời. Nếu sếp hay tech lead quyết định "cái này phải giữ" mà không qua kiểm tra, cả cấu trúc dân chủ của Min Specs sụp đổ. Mẹo: nhắc nhở rằng mọi quy tắc đều phải vượt qua cùng một câu hỏi kiểm tra, không có ngoại lệ vì chức danh.
Lỗi 5 — Chốt xong rồi để đó. Bộ Min Specs chỉ có giá trị nếu thực sự được áp dụng. Mẹo: gắn ngay với một hành động cụ thể (cập nhật DoD, sửa working agreement) và một mốc kiểm chứng. Min Specs là giả thuyết cần được kiểm nghiệm qua thực tế, không phải chân lý vĩnh viễn.
Mẹo bổ sung cho bối cảnh Việt Nam: trong nhiều team Việt, văn hóa "thêm cho an toàn" và ngại va chạm với cấp trên khiến quy tắc dễ phình to. Hãy dùng tính ẩn danh/nhóm nhỏ ở bước liệt kê để mọi người dám nói thật, và luôn nhấn rằng quyết định là của cả nhóm — điều này giảm áp lực "ai chịu trách nhiệm nếu bỏ sai".
Bài tập thực hành
Bài tập 1 — Soi Definition of Done của chính team bạn. Lấy DoD hiện tại ra. Đóng khung mục đích: "DoD này tồn tại để bảo đảm điều gì?". Với từng mục, áp câu hỏi kiểm tra Min Spec. Đếm xem có bao nhiêu mục thực sự là Min Spec, bao nhiêu chỉ là thói quen. Mục tiêu: rút ngắn ít nhất 30% mà không tăng rủi ro thật.
Bài tập 2 — Tự thực hành cá nhân trước khi facilitate nhóm. Chọn một quy trình cá nhân của bạn (ví dụ: checklist chuẩn bị cho Sprint Review). Viết Max Specs đầy đủ, rồi tự lọc xuống Min Specs. Quan sát cảm giác "muốn giữ cho chắc" của chính mình — đó chính là thứ bạn sẽ gặp ở team.
Bài tập 3 — Thiết kế một phiên 50 phút. Viết ra agenda chi tiết theo 5 bước cho một phiên Min Specs nhằm xây working agreement cho một team giả định 6 người vừa thành lập. Ghi rõ câu hỏi đóng khung, cách chia nhóm, và câu hỏi kiểm tra bạn sẽ dùng ở bước lọc.
Tóm tắt
Min Specs là một Liberating Structure dựa trên một sự thật phản trực giác: hệ thống phức tạp vận hành tốt nhất với ít nhất có thể các quy tắc thiết yếu, thay vì nhiều nhất có thể các quy tắc "phòng xa". Quy trình gồm năm bước cốt lõi: đóng khung mục đích rõ ràng, liệt kê đầy đủ Max Specs, kiểm tra từng quy tắc bằng câu hỏi "bỏ cái này có còn đạt mục đích không?", thử thách lại danh sách rút gọn, và chốt thành Min Specs kèm hành động cụ thể.
Là Scrum Master, bạn sẽ thấy Min Specs hữu ích bất cứ khi nào team mắc kẹt trong over-engineering: Definition of Done phình to, working agreement không ai nhớ, quy trình refinement quá nặng, hay quy trình vận hành tự áp đặt quá nhiều bước. Công cụ này không chỉ giúp cắt bỏ quy tắc thừa mà còn cho team một không gian an toàn, dân chủ và có cấu trúc để cùng quyết định điều gì thực sự quan trọng. Hãy nhớ tiêu chí kép: bộ quy tắc đúng là bộ nhỏ nhất mà vẫn đủ để bảo toàn mục đích — không hơn, không kém.