Mười phút trước, ý tưởng của bạn là “một chỗ để khách đặt lịch”. Mười phút sau, nó đã thành: đặt lịch, thanh toán, điểm thưởng, app điện thoại, báo cáo, chatbot… — và không ai còn biết bắt đầu từ đâu.
Đó là cách gần như mọi web app chết trước khi kịp sinh: không phải vì ý tưởng dở, mà vì bản đầu tiên bị bắt gánh mọi tính năng cùng lúc. Xây dựng web app đúng cách là cắt ý tưởng đó về một việc lõi — việc mà người dùng đầu tiên thật sự cần — dựng nó tử tế, cho người thật dùng, rồi mới quyết định lớn lên theo hướng nào bằng dữ kiện thật.
Hầu hết ý tưởng web app khi được kể ra đều đúng ở tầm nhìn: người kể nhìn thấy cả một hệ thống hoàn chỉnh. Vấn đề là đội xây dựng không thể xây “cả hệ thống hoàn chỉnh” trong một đợt mà vẫn giữ được chất lượng và ngân sách — và người dùng cũng không học được một hệ thống quá lớn trong ngày đầu.
Vì vậy, công việc quan trọng nhất của giai đoạn xây dựng không phải là code nhanh — là cắt. Cắt đúng, bản đầu nhỏ nhưng sắc: nó làm một việc đến nơi đến chốn cho một nhóm người dùng cụ thể, và chính nhóm đó sẽ cho bạn biết tính năng nào trong danh sách dài kia thật sự đáng làm tiếp theo.
Khung cắt phạm vi: ba lớp của một ý tưởng
Lớp 1 — Việc lõi của bản đầu
Một việc duy nhất mà nếu làm tốt, người dùng đầu tiên đã có lý do quay lại. Ba câu hỏi lọc cho mọi tính năng ứng viên:
1. Không có nó, việc lõi có hoàn thành được không? Nếu vẫn hoàn thành — nó không thuộc lớp 1.
2. Nó phục vụ người dùng đầu tiên, hay phục vụ một người dùng “sau này có thể có”?
3. Nó là việc người dùng làm mỗi lần dùng, hay việc thỉnh thoảng mới cần tới (và có thể xử lý tay trong giai đoạn đầu)?
Lớp 2 — Việc của giai đoạn hai
Các tính năng đúng hướng nhưng chưa cần cho việc lõi chạy được: mở rộng báo cáo, thêm kênh thông báo, tự động hóa thêm các khâu phụ. Lớp này được ghi danh sách ngay từ đầu để kiến trúc chừa chỗ, nhưng không xây vội.
Lớp 3 — Việc chưa chắc cần tồn tại
Những tính năng có mặt vì “nhà người ta có”: điểm thưởng, mạng xã hội nội bộ, AI chưa rõ điểm chạm. Lớp này không bị xóa — nó được treo lại, chờ dữ kiện từ người dùng thật phán quyết. Kinh nghiệm cho thấy một phần không nhỏ lớp 3 sẽ không bao giờ cần xây, và đó là khoản tiết kiệm lớn nhất của cách làm theo giai đoạn.
Người dùng đầu tiên: chọn hẹp để học nhanh
Bản đầu cần một nhóm người dùng đầu tiên cụ thể — một cơ sở, một đội, một nhóm khách quen — thay vì “mở cho tất cả”:
Đề xuất lộ trình sẽ giúp bạn chọn nhóm này dựa trên ý tưởng và nguồn lực hiện có của bạn.
- Nhóm hẹp cho phản hồi nhanh và thật: họ nói rõ chỗ nào vướng trong đúng tình huống dùng của họ.
- Tình huống dùng của nhóm này định hình việc lõi: cùng một ý tưởng, người dùng đầu tiên khác nhau thì việc lõi khác nhau.
- Nhóm đầu tiên hài lòng là bằng chứng để mở rộng; nhóm đầu tiên bỏ đi là bài học rẻ nhất bạn có thể mua.
Ba thứ không được cắt ở bản đầu dù cắt tính năng mạnh tay
Cắt phạm vi không có nghĩa là làm ẩu nền móng:
1. Tài khoản và phân quyền đúng ngay từ đầu: thêm một vai trò sau này phải là việc mở rộng, không phải viết lại.
2. Dữ liệu có cấu trúc sạch: dữ liệu của bản đầu là tài sản tích lũy; thu thập lộn xộn từ đầu sẽ làm mọi giai đoạn sau phải trả giá.
3. Đường xuất dữ liệu: bất cứ lúc nào bạn cũng lấy lại được dữ liệu của mình ở dạng dùng được — điều kiện để bạn không bao giờ bị khóa vào hệ thống.
Ba thứ này là phần “không tối thiểu” của một bản tối thiểu làm đúng nghĩa.
Sau bản đầu: quyết định mở rộng bằng dữ kiện, không bằng cảm tính
Khi bản lõi đã chạy với người dùng thật, thứ tự mở rộng được quyết bằng:
Ngược lại, tính năng “nghe hay” nhưng không ai trong nhóm đầu tiên nhắc tới sẽ tiếp tục nằm ở lớp 3. Cách quyết này giữ sản phẩm luôn nhỏ hơn nhu cầu thật một chút — trạng thái lành mạnh để lớn lên.
- Việc nào người dùng đang phải làm tay bổ sung vì hệ thống chưa có — dấu hiệu nhu cầu thật.
- Điểm vướng nào xuất hiện lặp lại trong phản hồi của nhiều người dùng.
- Việc nào trong lớp 2 mở khóa được một nhóm người dùng mới.
Quy trình triển khai
Kể lại ý tưởng thành một tình huống dùng
Ai dùng, trong tình huống nào, hoàn thành việc gì — chỉ cần ở mức câu chuyện, chưa cần đặc tả hay bản vẽ.
Nhận lộ trình trong 24–48 giờ làm việc
Lộ trình gồm việc lõi đề xuất, danh sách ba lớp tính năng, nhóm người dùng đầu tiên gợi ý, các giai đoạn tiếp theo và mốc thời gian dự kiến cho giai đoạn đầu.
Dựng bản lõi
Xây việc lõi trên nền tài khoản/dữ liệu/phân quyền đàng hoàng; bạn duyệt bản dựng bằng tình huống dùng thật của nhóm đầu tiên.
Người dùng thật dùng và vòng quyết định tiếp theo
Theo dõi sử dụng, thu phản hồi có cấu trúc và chốt giai đoạn tiếp theo bằng dữ kiện — mở rộng, điều chỉnh, hay dừng lại đều là quyết định có căn cứ.
Câu hỏi thường gặp
Tôi chưa có đặc tả, chỉ có ý tưởng trong đầu — bắt đầu được không?
Được, và đó là trạng thái phổ biến nhất. Bước đầu tiên của quy trình là biến ý tưởng thành tình huống dùng và cắt phạm vi; bản đặc tả là đầu ra của giai đoạn tư vấn, không phải điều kiện đầu vào bạn phải tự chuẩn bị.
Bản đầu “tối thiểu” có làm khách/người dùng của tôi thất vọng không?
Bản tối thiểu đúng nghĩa chỉ tối thiểu về số tính năng, không tối thiểu về chất lượng của việc lõi: một việc làm đến nơi đến chốn gây ấn tượng tốt hơn mười việc làm nửa vời. Nhóm người dùng đầu tiên được chọn hẹp cũng để họ nhận đúng phần giá trị dành cho họ.
Bản đầu tiên mất bao lâu?
Phụ thuộc việc lõi được cắt ra là gì — đó là lý do lộ trình phải chốt việc lõi trước khi nói thời gian. Mốc cụ thể cho giai đoạn đầu được ghi trong đề xuất phản hồi trong 24–48 giờ làm việc.
Tôi có phải chia sẻ toàn bộ ý tưởng ngay từ lần liên hệ đầu không?
Không. Lần đầu chỉ cần mức đủ để hiểu tình huống dùng và nhóm người dùng. Các chi tiết sâu hơn được chia sẻ theo từng giai đoạn làm việc khi hai bên đã có cam kết rõ ràng.
Nếu sau bản đầu tôi muốn đổi hướng hẳn thì mất những gì?
Nền tài khoản, dữ liệu có cấu trúc và mã nguồn thuộc về bạn; phần việc lõi đã xây có thể được dùng lại ở mức độ tùy hướng mới. Cách làm theo giai đoạn chính là để chi phí của việc đổi hướng ở mức thấp nhất có thể — so với việc đã xây xong một hệ thống lớn sai hướng.
Web app khác gì làm thêm tính năng vào website hiện tại?
Nếu “tính năng” đó có người dùng đăng nhập, trạng thái công việc và dữ liệu nghiệp vụ riêng, về bản chất nó đã là một web app — có thể xây như một phần mở rộng nối vào website hiện tại. Đề xuất sẽ phân định ranh giới này theo trường hợp của bạn.
Ý tưởng của bạn không cần nhỏ lại — nó chỉ cần một thứ tự: việc gì làm trước, việc gì để sau, việc gì có thể không bao giờ cần làm
Lo lắng “ý tưởng còn mơ hồ quá” không phải lý do để trì hoãn buổi trao đổi — làm rõ ý tưởng chính là nội dung của buổi trao đổi đó. Hãy kể ý tưởng của bạn như bạn vẫn kể cho người khác: ai dùng, để làm gì. Lộ trình trả về sẽ biến câu chuyện đó thành một bản đầu tiên cụ thể, có phạm vi, có mốc thời gian — và bạn quyết định bắt đầu hay chưa với đầy đủ thông tin trên tay. Lộ trình và đề xuất phạm vi được phản hồi trong 24–48 giờ làm việc. Văn phòng Hà Nội: 144 Trần Vỹ · Văn phòng Phú Thọ: Số 2 Chùa Cấm, Phúc Yên. Liên hệ nhanh qua các nút Điện thoại/Zalo trên trang.
