Khi nói một dự án phần mềm thất bại, nhiều người thường nghĩ nguyên nhân nằm ở công nghệ, năng lực lập trình hay ngân sách. Thực tế, rất nhiều dự án chết sớm hơn thế: chúng chết ở giai đoạn hiểu bài toán. Đội ngũ lao vào làm khi mọi người mới chỉ hiểu mơ hồ mình đang giải quyết điều gì, cho ai và bằng cách nào. Đó là lý do khái niệm Level 1, Level 2, Level 3 rất quan trọng nếu muốn làm rõ bài toán phần mềm trước khi bắt tay vào build.
Nói đơn giản, Level 1 là biết mình muốn gì ở mức khẩu hiệu. Level 2 là mô tả được tương đối rõ tính năng và luồng chính. Level 3 là mức đủ rõ để build: biết cái gì làm, cái gì không làm, ưu tiên nào thắng khi có xung đột, ai có quyền quyết định và điều gì sẽ bị đóng băng trước khi thi công. Nhiều dự án dừng ở Level 2 vì đội ngũ cảm thấy “đã khá rõ rồi”, nhưng thực ra vẫn còn mơ hồ ở những chỗ quyết định sống còn.
Level 1, Level 2, Level 3 là gì?
Level 1: Biết mong muốn, chưa rõ bài toán
Đây là mức rất phổ biến ở giai đoạn đầu. Founder hoặc team có một mong muốn như “cần app để tăng doanh số”, “muốn số hóa quy trình”, “muốn làm nền tảng kết nối”, “muốn AI tự động hóa”. Những câu này đúng, nhưng chưa đủ để build phần mềm. Nó giống như nói “tôi muốn một căn nhà đẹp” mà chưa biết xây cho ai ở, cần mấy phòng, ưu tiên ánh sáng hay chi phí, ở lâu dài hay cho thuê.
Dấu hiệu của Level 1 là các cuộc họp nghe rất hào hứng nhưng khó chốt đầu việc cụ thể. Mọi người nói nhiều về tầm nhìn, ít nói về ràng buộc. Nếu đội phát triển nhận brief ở mức này, họ chỉ có thể đoán.
Level 2: Mô tả được giải pháp, nhưng chưa chốt quyết định
Ở Level 2, nhóm đã tiến bộ hơn nhiều. Họ mô tả được persona chính, luồng sử dụng cơ bản, danh sách tính năng, thậm chí có wireframe hoặc prototype. Nhìn vào, ai cũng cảm thấy dự án “có vẻ sắp làm được rồi”. Đây là mức khiến nhiều người chủ quan nhất.
Vấn đề là Level 2 vẫn thường thiếu các quyết định cứng. Ví dụ: tính năng nào là bắt buộc cho bản đầu tiên, tính năng nào để sau? Nếu trải nghiệm người dùng mượt nhưng vận hành nội bộ phức tạp hơn thì chọn gì? Nếu cần ra mắt trong 8 tuần thì cắt phần nào? Nếu dữ liệu đầu vào bẩn thì hệ thống cho nhập tự do hay bắt chuẩn hóa ngay? Khi có mâu thuẫn giữa sale, vận hành và sản phẩm thì ai chốt?
Nói cách khác, Level 2 mô tả được nhiều thứ, nhưng chưa khóa được trade-off. Mà phần mềm chỉ thực sự bắt đầu khi phải chấp nhận đánh đổi.
Level 3: Đủ rõ để thi công
Level 3 là khi bài toán được làm rõ đến mức có thể build với rủi ro kiểm soát được. Không phải là biết mọi chi tiết, mà là đã chốt được những điểm ảnh hưởng trực tiếp tới phạm vi, ưu tiên và cách ra quyết định. Ở mức này, team có một build-commit brief rõ ràng: mục tiêu, người dùng, use case chính, phạm vi in scope, phạm vi out of scope, tiêu chí thành công, ràng buộc, giả định, rủi ro, cách xử lý thay đổi và người chịu trách nhiệm chốt.
Quan trọng nhất, Level 3 thường đi kèm một Decision Freeze: một thời điểm hoặc nguyên tắc mà sau đó các quyết định cốt lõi không còn thay đổi tùy hứng. Không có đóng băng quyết định, dự án sẽ vừa làm vừa lắc, chi phí tăng mà chất lượng giảm.
Vì sao nhiều dự án chết ở Level 2?
1. Cảm giác rõ giả
Level 2 tạo ra cảm giác tiến triển rất mạnh. Có slide, có mockup, có backlog, có user flow. Mọi thứ trông rất “sẵn sàng”. Nhưng cái thiếu không nằm ở số lượng tài liệu, mà ở chất lượng quyết định. Nhiều tài liệu không đồng nghĩa với đã rõ bài toán.
2. Mọi người né trade-off
Không ai muốn là người nói “cái này chưa làm”, “cái kia bỏ sau”, “trường hợp đặc biệt này chưa xử lý trong phiên bản đầu”. Vì sợ mất cơ hội hoặc sợ bị đánh giá thiếu tham vọng, đội ngũ giữ mọi thứ mở. Kết quả là scope phình ra, ưu tiên mâu thuẫn và không ai thật sự biết sản phẩm đang tối ưu cho điều gì.
3. Không có quyền quyết định rõ ràng
Một dự án có thể có nhiều bên liên quan, nhưng không thể có nhiều trung tâm ra quyết định ngang nhau ở mọi vấn đề. Nếu founder, vận hành, sale, đối tác và kỹ thuật đều có thể thay đổi yêu cầu bất kỳ lúc nào, team sẽ mắc kẹt trong vòng lặp chỉnh sửa vô tận. Dự án chết ở Level 2 không phải vì thiếu ý tưởng, mà vì thừa tiếng nói mà thiếu cơ chế chốt.
4. Đồng nhất “có thể làm” với “nên làm ngay”
Trong phần mềm, gần như cái gì cũng có thể làm nếu đủ thời gian và tiền. Nhưng bản build đầu không phải nơi để chứng minh mọi khả năng. Nếu chưa chốt rõ mục tiêu của phiên bản đầu là học gì, kiểm chứng gì, giảm rủi ro gì, team sẽ ôm quá nhiều thứ cùng lúc và mất đà.
5. Lao vào build để giảm lo âu
Nhiều nhóm thấy khó chịu khi phải tiếp tục làm rõ nên chọn cách “cứ làm trước rồi tính”. Đây là phản xạ dễ hiểu, vì build tạo cảm giác đang tiến lên. Nhưng nếu bài toán chưa đạt Level 3, việc build chủ yếu tạo ra chi phí thay đổi. Càng code sớm khi chưa chốt, càng đau khi phải sửa.
Bước đi thực tế để kéo dự án từ Level 2 lên Level 3
Bước 1: Viết lại bài toán bằng ngôn ngữ đời thường
Trước khi bàn tính năng, hãy trả lời thật ngắn: ai đang gặp vấn đề gì, họ đang giải quyết theo cách nào, điểm đau lớn nhất ở đâu, vì sao phải xử lý bây giờ. Nếu câu trả lời vẫn toàn thuật ngữ hoặc khẩu hiệu, nghĩa là bài toán chưa rõ.
Bước 2: Chốt outcome thay vì chỉ chốt feature
Đừng chỉ hỏi “làm màn hình nào”. Hãy hỏi “sau 60 ngày dùng, điều gì phải thay đổi trong thực tế?”. Ví dụ: giảm thời gian xử lý một yêu cầu từ 2 ngày xuống 4 giờ; tăng tỷ lệ hoàn tất đăng ký thêm 20%; giảm sai sót nhập liệu ở khâu X. Outcome giúp lọc bớt những thứ nghe hay nhưng không phục vụ mục tiêu chính.
Bước 3: Lập danh sách scope in, scope out
Đây là động tác rất quan trọng nhưng hay bị làm qua loa. Hãy viết rõ những gì thuộc bản đầu và những gì cố ý không làm trong bản đầu. Scope out không phải bỏ vĩnh viễn; đó là quyết định trì hoãn có chủ đích để bảo vệ tiến độ và độ tập trung.
- In scope: các luồng bắt buộc để giải quyết use case cốt lõi.
- Out of scope: tích hợp phụ, trường hợp hiếm, dashboard nâng cao, tự động hóa thứ cấp, vai trò người dùng chưa cần.
Bước 4: Ghi rõ các trade-off sản phẩm
Mỗi dự án đều có đánh đổi. Nên viết thẳng ra thay vì để ngầm hiểu. Ví dụ: ưu tiên tốc độ ra mắt hơn độ linh hoạt cấu hình; ưu tiên thao tác đơn giản cho người dùng hơn việc bao phủ mọi trường hợp; ưu tiên quy trình chuẩn hóa hơn quyền chỉnh sửa tự do. Khi có trade-off được ghi rõ, team sẽ bớt tranh luận vòng quanh.
Bước 5: Tạo build-commit brief
Một build-commit brief tốt thường có các mục sau:
- Mục tiêu của bản build đầu.
- Người dùng chính và use case chính.
- Tiêu chí thành công đo được.
- Scope in và scope out.
- Giả định đang chấp nhận.
- Rủi ro lớn nhất và cách giảm rủi ro.
- Trade-off đã chốt.
- Ai có quyền quyết định khi phát sinh xung đột.
- Điểm Decision Freeze và cơ chế xử lý thay đổi sau mốc đó.
Bước 6: Thiết lập Decision Freeze
Decision Freeze không có nghĩa là cứng nhắc. Nó có nghĩa là sau một mốc nhất định, thay đổi ở các quyết định cốt lõi phải đi qua cơ chế rõ ràng: thay đổi gì, đổi lại mất gì, ai duyệt, tác động đến timeline ra sao. Nếu không có cơ chế này, dự án sẽ luôn trong tình trạng “gần xong”.
Chốt cái gì làm, không làm và ai có quyền quyết định
Nếu chỉ nhớ một điều, hãy nhớ điều này: dự án phần mềm không thất bại vì thiếu ý tưởng, mà vì thiếu biên giới. Biên giới của phiên bản đầu cần được viết thành văn bản ngắn, rõ, dễ kiểm tra. Ít nhất phải chốt:
- Phiên bản đầu tồn tại để giải quyết use case nào.
- Những use case nào cố ý chưa xử lý.
- Chỉ số nào dùng để đánh giá bản đầu có giá trị hay không.
- Những quyết định nào đã khóa trước khi build.
- Ai là người chốt cuối cùng khi có tranh luận.
Nếu các câu hỏi này chưa có câu trả lời rõ, dự án vẫn chưa ở Level 3.
Checklist dùng ngay trong buổi làm rõ đầu tiên
- Người dùng chính là ai, và ai không phải người dùng chính?
- Vấn đề cụ thể họ đang gặp là gì?
- Nếu không làm phần mềm này, họ đang dùng cách nào thay thế?
- Use case nào bắt buộc phải chạy trơn ở bản đầu?
- Ba tính năng tưởng quan trọng nhưng có thể để sau là gì?
- Điều gì sẽ khiến bản đầu bị xem là thất bại dù code chạy ổn?
- Trong các ưu tiên sau, cái nào đứng cao hơn: tốc độ ra mắt, độ chính xác, độ linh hoạt, trải nghiệm đơn giản, chi phí vận hành?
- Khi có yêu cầu mới giữa chừng, ai có quyền nói có hoặc không?
- Mốc Decision Freeze là khi nào?
- Sau Decision Freeze, thay đổi sẽ được đánh giá bằng cơ chế nào?
Các phản đối thường gặp từ founder và cách xử lý
“Thị trường thay đổi nhanh, chốt sớm sẽ mất linh hoạt”
Đúng là thị trường thay đổi. Nhưng không chốt gì cả không tạo ra linh hoạt, mà tạo ra hỗn loạn. Linh hoạt tốt là thay đổi có kiểm soát, biết rõ đổi cái gì và trả giá gì. Decision Freeze giúp bảo vệ điều đó.
“Cứ làm MVP trước rồi học”
MVP không đồng nghĩa với làm khi chưa hiểu đủ. MVP tốt là phiên bản nhỏ nhưng sắc, không phải phiên bản mơ hồ. Nếu chưa rõ scope in, scope out và tiêu chí học gì, bạn không có MVP; bạn chỉ có một bản thử tốn tiền.
“Đội kỹ thuật cứ build đi, chi tiết tính sau”
Kỹ thuật có thể build khi bài toán đủ rõ, không phải khi mong muốn còn lỏng. Nếu chi tiết ở đây là những quyết định ảnh hưởng đến phạm vi, ưu tiên và trải nghiệm cốt lõi, để sau đồng nghĩa với sửa lại sau. Chi phí sẽ cao hơn nhiều.
Kết luận
Level 1 là biết mình muốn gì. Level 2 là mô tả được mình định làm gì. Level 3 là đủ rõ để commit build. Phần lớn dự án chết ở Level 2 vì đội ngũ tưởng rằng có tài liệu là đã rõ, trong khi thứ còn thiếu lại là quyết định: cái gì làm, cái gì không làm, đánh đổi nào được chấp nhận và ai có quyền chốt.
Đầu ra lý tưởng trước khi thi công không phải là một bộ tài liệu dày, mà là một bản mô tả ngắn, rõ, đủ điều kiện build: bài toán được gọi tên chính xác, phạm vi được đóng khung, trade-off được viết ra, Decision Freeze được thống nhất và build-commit brief được cả đội hiểu như nhau. Khi đó, bạn không chỉ bắt đầu nhanh hơn mà còn tránh được kiểu nhanh ban đầu nhưng trả giá rất đắt về sau.
