Nhiều dự án phần mềm trượt tiến độ không phải vì đội làm yếu, mà vì bắt đầu build khi bài toán còn mơ hồ. Ở giai đoạn này, hai quyết định quan trọng nhất là scope in và scope out: cái gì được đưa vào để giải quyết mục tiêu hiện tại, và cái gì chủ động loại ra để tránh loãng sản phẩm.
Nói đơn giản, scope in là lời cam kết: chúng ta sẽ làm những phần này. Scope out là lời kỷ luật: chúng ta sẽ không làm những phần này trong vòng build hiện tại. Cặp quyết định này sống còn vì nó quyết định đội ngũ có đang giải đúng bài toán hay chỉ đang gom thật nhiều ý tưởng rồi gọi đó là kế hoạch.
Ba mức hiểu bài toán phần mềm
Phần lớn dự án dừng ở Level 1 hoặc Level 2 nên càng build càng lộ khoảng trống.
- Level 1 - hiểu mong muốn: biết founder hoặc stakeholder muốn gì ở bề mặt, ví dụ “cần app cho khách đặt dịch vụ”, “cần hệ thống quản lý nội bộ”. Mức này mới là mô tả nhu cầu, chưa phải bài toán đủ để thi công.
- Level 2 - hiểu luồng và tính năng: đã có danh sách tính năng, vài user flow, vài màn hình mẫu. Đây là mức phổ biến nhất, nhưng vẫn dễ vỡ vì thiếu ranh giới, thiếu thứ tự ưu tiên, thiếu điều kiện chấp nhận.
- Level 3 - hiểu để ra quyết định build: đã làm rõ mục tiêu, người dùng chính, tình huống sử dụng, phạm vi làm và không làm, trade-off, rủi ro, người có quyền chốt, và điều kiện đóng băng quyết định trước khi triển khai. Đây là mức đủ rõ để viết build-commit brief và giao việc ít lệch nhất.
Nhiều đội dừng ở Level 1 vì quá tin vào trực giác người sáng lập. Nhiều đội dừng ở Level 2 vì nhầm rằng có wireframe là đã đủ rõ. Nhưng khi chưa chốt scope in, scope out và cơ chế quyết định, mọi thứ vẫn có thể thay đổi bất kỳ lúc nào, kéo theo phát sinh chi phí và xung đột ưu tiên.
Vì sao scope in và scope out là cặp quyết định sống còn
Nếu chỉ có scope in mà không có scope out, đội ngũ sẽ liên tục nhặt thêm việc. Nếu chỉ có scope out mà không có scope in rõ ràng, sản phẩm sẽ thiếu lõi giá trị. Hai phần này phải đi cùng nhau vì mỗi lựa chọn đều là một trade-off sản phẩm.
Ví dụ, nếu scope in là “cho phép khách đặt lịch trong 3 bước”, thì có thể scope out sẽ là “chưa hỗ trợ nhiều vai trò vận hành”, “chưa có loyalty”, “chưa đồng bộ ERP”, “chưa cá nhân hóa sâu”. Nhờ vậy đội ngũ giữ được một mục tiêu rõ: đưa hành vi đặt lịch vào vận hành thật trước, thay vì mở rộng khắp nơi rồi không phần nào đủ tốt.
Cách kéo dự án lên Level 3 trước khi thi công
- Chốt mục tiêu ngắn hạn duy nhất: bản build này nhằm kiểm chứng điều gì hoặc tạo ra kết quả kinh doanh nào.
- Xác định người dùng chính: ai là người bắt buộc phải giải quyết trước, ai có thể để sau.
- Liệt kê quyết định không thể mơ hồ: luồng chính, dữ liệu tối thiểu, ngoại lệ chấp nhận được, điều kiện thành công.
- Phân tách phải có - nên có - chưa làm: đây là lúc hình thành scope in và scope out thực chất, không phải cảm tính.
- Ghi rõ trade-off: chọn tốc độ hay độ phủ, chọn thao tác đơn giản hay phân quyền sâu, chọn tính ổn định hay tích hợp sớm.
- Chỉ định người có quyền chốt: ai được quyết định khi có mâu thuẫn về phạm vi, ưu tiên và deadline.
- Viết build-commit brief: tài liệu ngắn gọn nhưng đủ để cả đội cùng hiểu mình sẽ xây cái gì, không xây cái gì, và vì sao.
Decision Freeze: quyết định trước khi build
Decision Freeze không có nghĩa là cấm thay đổi mãi mãi. Nó có nghĩa là trước khi vào sprint build, đội phải có một thời điểm đóng băng các quyết định cốt lõi để tránh việc ngày nào cũng sửa bài toán.
Một Decision Freeze tốt cần trả lời được:
- Mục tiêu bản build này là gì?
- Scope in gồm những hạng mục nào?
- Scope out gồm những gì, và vì sao chưa làm?
- Trade-off nào đã được chấp nhận?
- Ai là người có quyền duyệt thay đổi sau mốc freeze?
- Điều kiện nào đủ để coi là xong?
Khi thiếu mốc này, dự án thường rơi vào trạng thái “vừa build vừa nghĩ”, đội kỹ thuật phải tự lấp chỗ trống, còn người ra quyết định liên tục bổ sung yêu cầu vì cảm giác vẫn chưa đủ.
Chốt cái gì làm, không làm và ai có quyền quyết định
Một cuộc làm rõ đầu bài hiệu quả không nên kết thúc bằng câu “để lúc làm rồi tính”. Nó nên kết thúc bằng một bảng quyết định đơn giản:
- Scope in: các tính năng và luồng chắc chắn được làm trong vòng hiện tại.
- Scope out: các ý tưởng hợp lý nhưng chủ động để sang giai đoạn sau.
- Open questions: các điểm còn thiếu dữ liệu, có deadline để chốt.
- Decision owner: người có quyền ra quyết định cuối cùng cho từng nhóm vấn đề.
Nếu không chỉ rõ decision owner, đội sẽ mất thời gian họp nhiều nhưng không ai dám chốt. Nếu ai cũng có quyền thêm việc, scope sẽ phình mà không ai chịu trách nhiệm cho trade-off.
Checklist dùng ngay trong buổi làm rõ đầu tiên
- Người dùng nào là ưu tiên số 1 của bản build này?
- Hành vi hoặc kết quả nào bắt buộc phải xảy ra sau khi ra mắt?
- Ba luồng quan trọng nhất là gì?
- Những tình huống nào chấp nhận xử lý thủ công ở giai đoạn đầu?
- Tính năng nào nghe hay nhưng chưa tác động trực tiếp tới mục tiêu hiện tại?
- Nếu chỉ được giữ lại 20% phạm vi, 20% đó là gì?
- Rủi ro lớn nhất nếu cắt bớt là gì? Rủi ro lớn nhất nếu ôm quá nhiều là gì?
- Ai có quyền chốt khi founder, vận hành và kỹ thuật nhìn khác nhau?
- Mốc Decision Freeze là ngày nào?
- Đầu ra cuối cùng có được viết thành build-commit brief chưa?
Các phản đối thường gặp từ founder và cách xử lý
“Cứ làm hết để khỏi sửa về sau.”
Thực tế, làm hết từ đầu thường tạo ra nhiều phần chưa được kiểm chứng, tốn chi phí vận hành và khiến lõi sản phẩm thiếu tập trung. Cách xử lý là quay lại mục tiêu ngắn hạn: bản build này cần chứng minh điều gì trước tiên.
“Thị trường thay đổi nhanh, freeze sớm sẽ mất linh hoạt.”
Freeze không chống lại linh hoạt, mà chống lại hỗn loạn. Vẫn có thể thay đổi, nhưng mọi thay đổi sau mốc freeze phải đi qua một cơ chế rõ ràng: ai đề xuất, ai duyệt, đổi cái gì, ảnh hưởng gì.
“Tính năng này có thể cần sau này, sao lại scope out?”
Scope out không có nghĩa là vứt bỏ. Nó có nghĩa là chưa làm ở vòng này để bảo vệ chất lượng quyết định hiện tại. Ý tưởng vẫn được giữ trong backlog, nhưng không được chen vào khi chưa qua đánh giá lại ưu tiên.
“Đội kỹ thuật cứ build bản đầu đi rồi mình chỉnh.”
Đó là cách nhanh nhất để biến kỹ thuật thành nơi đoán ý. Chỉnh sau là bình thường, nhưng phải chỉnh trên nền một bài toán đã đủ rõ, không phải trên một tập kỳ vọng chưa được chốt.
Đầu ra lý tưởng trước khi thi công
Đầu ra tốt nhất không phải là một tài liệu dài, mà là một bản mô tả đủ điều kiện thi công. Nó nên ngắn gọn, rõ ràng, và buộc được các bên cùng cam kết. Một build-commit brief tốt thường có:
- Mục tiêu của vòng build
- Người dùng chính
- Scope in
- Scope out
- Trade-off đã chấp nhận
- Mốc Decision Freeze
- Decision owner
- Tiêu chí hoàn thành
Khi làm rõ được đến mức này, đội ngũ không chỉ hiểu phải xây gì, mà còn hiểu vì sao không xây những phần còn lại ở thời điểm hiện tại. Đó mới là dấu hiệu của một dự án đã lên đến Level 3: đủ rõ để quyết định trước khi build, thay vì trả giá trong lúc build.
