Think Like a Developer #6: MVP Thinking - "Đừng build cái hoàn hảo, build cái chạy được"
Bạn mất 3 tuần vibe code một app quản lý quán cà phê. 20 tính năng. Quản lý menu, đặt bàn, loyalty point, chat nội bộ, báo cáo doanh thu, quản lý kho, tích hợp thanh toán, gửi email marketing...
3 tuần. Hàng trăm prompt. Sửa tới sửa lui. Cuối cùng bạn hào hứng đưa cho chủ quán dùng thử.
Chủ quán mở app. Lướt qua. Rồi hỏi: "Ê, tìm món trong menu ở đâu vậy?"
Search bar. Cái thứ duy nhất chủ quán thật sự cần mỗi ngày. Và bạn không có.
20 tính năng. Không ai dùng tính năng nào. Vì cái duy nhất họ cần thì bạn quên build.
Đây là sai lầm phổ biến nhất của người mới build sản phẩm. Không chỉ người no-code. Cả startup triệu đô cũng chết vì lý do này. Build quá nhiều, quá sớm, trước khi biết ai cần gì.
Developer có một tư duy để tránh cái bẫy này: MVP Thinking.
MVP là gì? Không phải cái bạn nghĩ
MVP là Most Viable Product. Sản phẩm khả dụng tối thiểu. Nhưng mọi người hiểu sai chữ "tối thiểu".
Tối thiểu không phải là làm ẩu. Không phải là cắt hết cho nhanh. Tối thiểu nghĩa là: chỉ giữ lại cái quan trọng nhất, và làm cái đó cho tử tế.
Ví dụ đời thường. Bạn muốn mở quán bán nước ép.
Cách sai: Thuê mặt bằng lớn, mua 10 loại máy ép, thiết kế menu 50 món, in brochure, làm website, setup hệ thống delivery, mở app đặt hàng. 3 tháng chuẩn bị. Mở ra không ai mua vì khu đó toàn dân uống cà phê.
Cách đúng: Mượn xe đẩy, mua 1 máy ép, bán 3 loại nước. Bán ở góc ngã tư 1 tuần. Xem có ai mua không. Có thì mở rộng. Không thì thử chỗ khác.
Một bên mất 3 tháng + hàng trăm triệu để phát hiện sai. Một bên mất 1 tuần + vài triệu để biết câu trả lời.
MVP trong vibe code cũng y chang vậy.
Skateboard, không phải bánh xe
Có một hình ảnh mà developer nào cũng biết.
Cách sai để build xe hơi: Tuần 1 làm bánh xe. Tuần 2 làm khung. Tuần 3 làm động cơ. Tuần 4 lắp ráp. 4 tuần trôi qua, chưa có gì chạy được.
Cách đúng: Tuần 1 làm skateboard. Chạy được. Tuần 2 nâng cấp thành xe đạp. Chạy nhanh hơn. Tuần 3 thành xe máy. Tuần 4 thành xe hơi.
Mỗi tuần đều có thứ gì đó chạy được. Mỗi tuần đều có thể test với người dùng. Mỗi tuần đều có thể quyết định: tiếp tục hay đổi hướng.
Khi vibe code, bạn hay mắc lỗi "build bánh xe". Bạn làm hệ thống auth phức tạp với OAuth, forgot password, 2FA. Rồi database schema chi tiết. Rồi admin panel. Rồi notification system. 2 tuần trôi qua, chưa có màn hình nào mà người dùng thực sự dùng được.
Thay vào đó, build skateboard. Cái gì người dùng cần nhất? Build cái đó trước. Cho họ dùng. Xem phản hồi. Rồi mới build tiếp.
Công thức "1 vấn đề, 1 giải pháp, 1 màn hình"
Developer luôn hỏi 3 câu trước khi build:
Câu 1: "App này giải quyết VẤN ĐỀ gì?"
Không phải "app này có tính năng gì". Mà là "ai đang đau ở đâu". Chủ quán cà phê đau ở chỗ nào? Không tìm được món nhanh khi khách hỏi. Vậy vấn đề là: tra cứu menu nhanh.
Câu 2: "Giải pháp ĐƠN GIẢN NHẤT là gì?"
Không phải giải pháp hay nhất, đẹp nhất, đầy đủ nhất. Mà đơn giản nhất. Giải pháp cho "tra cứu menu nhanh"? Một danh sách món + search bar. Hết.
Câu 3: "Chỉ cần 1 MÀN HÌNH thì nó trông thế nào?"
Nếu toàn bộ app chỉ có 1 màn hình, bạn sẽ để gì trên đó? Cái đó là MVP.
Ví dụ. Ý tưởng: "App quản lý chi tiêu cá nhân."
Vấn đề: Không biết tiền đi đâu mỗi tháng. Giải pháp đơn giản nhất: Ghi lại mỗi khoản chi. 1 màn hình: Form nhập số tiền + danh mục, danh sách các khoản đã chi bên dưới, tổng tiền ở trên.
Đó là MVP. Không cần biểu đồ. Không cần xuất báo cáo. Không cần sync nhiều thiết bị. Không cần đăng nhập. Chỉ cần ghi và xem.
Build xong trong 1 prompt. Test ngay. Nếu bạn dùng mỗi ngày và thấy thiếu gì, thêm sau.
Tại sao MVP quan trọng hơn khi vibe code?
Với developer truyền thống, build nhiều feature cùng lúc cũng khó nhưng kiểm soát được vì họ hiểu code.
Với vibe code, mỗi feature thêm vào là thêm một lớp phức tạp mà bạn không kiểm soát được. AI generate code, bạn không đọc code. 5 tính năng thì 5 phần code đan xen. Sửa 1 chỗ, hỏng 3 chỗ khác. Bạn rơi vào vòng lặp sửa không hồi kết.
Nhưng nếu bạn chỉ có 1 tính năng? Sửa đơn giản. Test dễ. Hiểu được chuyện gì đang xảy ra. Thêm tính năng tiếp theo trên nền tảng đã chạy ổn.
Nguyên tắc: Build ít hơn bạn nghĩ. Rồi build ít hơn nữa. Cái còn lại mới là MVP.
Cách cắt tính năng mà không đau
Bạn biết MVP quan trọng. Nhưng cắt tính năng thì đau lắm. "Thiếu cái này thì chưa đủ hay." "Không có cái kia thì ai dùng." Mình hiểu.
Đây là cách developer cắt:
Viết ra tất cả tính năng bạn muốn. Không giới hạn. Cứ liệt kê hết.
Với mỗi tính năng, hỏi: "Nếu không có cái này, app có còn giải quyết được vấn đề chính không?"
Nếu CÓ, bỏ nó ra. Nó là "nice to have", không phải "must have".
Nếu KHÔNG, giữ lại.
Thường thì sau khi lọc, bạn chỉ còn 1 đến 3 tính năng. Đó là MVP.
Ví dụ: "App cho thuê đồ giữa hàng xóm" (ý tưởng từ bài 2).
Liệt kê tất cả: Đăng ký/đăng nhập, đăng đồ cho thuê, tìm đồ, đặt thuê, chat, thanh toán online, đánh giá, notification, bản đồ hiển thị đồ gần bạn, lịch sử thuê, hệ thống báo cáo vi phạm.
Vấn đề chính: Tìm được đồ cần thuê gần nhà.
Lọc: Không có auth, app còn giải quyết được vấn đề không? Được, dùng tạm số điện thoại. Không có chat? Được, trao đổi qua Zalo. Không có thanh toán online? Được, trả tiền mặt khi nhận đồ. Không có đánh giá? Được, chưa cần. Không có notification? Được.
MVP: Trang đăng đồ cho thuê (tên, ảnh, giá, khu vực) + trang tìm đồ có filter theo khu vực + nút liên hệ (hiện số điện thoại).
3 tính năng. 1 buổi chiều vibe code. Cho 5 người hàng xóm dùng thử. Nếu họ thật sự thuê đồ qua app, bạn biết ý tưởng đáng đầu tư tiếp. Nếu không, bạn tiết kiệm được 3 tuần build cái không ai dùng.
Template Prompt cho MVP
Bước 1: Xác định MVP.
"Tôi muốn build [mô tả app]. Vấn đề chính cần giải quyết: [1 câu mô tả pain point]. Hãy giúp tôi xác định MVP: tính năng nào là must-have, tính năng nào là nice-to-have? Chỉ giữ lại những gì cần thiết để giải quyết vấn đề chính."
Bước 2: Build MVP.
"Build MVP cho app [tên app]. Chỉ cần [liệt kê 1 đến 3 tính năng must-have]. Không cần [liệt kê vài thứ bạn cố tình bỏ]. Giữ mọi thứ đơn giản nhất có thể."
Ví dụ:
"Build MVP cho app quản lý chi tiêu. Chỉ cần: form nhập khoản chi (số tiền + danh mục), danh sách các khoản đã chi, tổng tiền hôm nay/tuần/tháng. Không cần đăng nhập, không cần biểu đồ, không cần xuất file. Giữ mọi thứ đơn giản nhất có thể."
Trước và sau khi áp dụng MVP Thinking
TRƯỚC:
Prompt: "Tạo app quản lý quán cà phê: quản lý menu, đặt bàn, loyalty point, chat nội bộ, báo cáo doanh thu, quản lý kho, thanh toán, email marketing." Kết quả: AI tạo ra 1 đống. 8 tính năng nửa vời. Không tính năng nào hoàn chỉnh. Sửa chỗ này hỏng chỗ kia. 3 tuần vật lộn.
SAU:
Prompt 1: "Tạo app quản lý menu quán cà phê. Chỉ cần: danh sách món (tên, giá, danh mục), search bar tìm món nhanh, nút thêm/sửa/xóa món. Không cần gì khác." Kết quả: App chạy. Chủ quán dùng được ngay.
Prompt 2 (tuần sau): "Thêm phần đặt bàn: khách chọn ngày giờ, số người. Hiển thị bàn trống. Xác nhận đặt." Kết quả: Tính năng mới chạy ngon trên nền cũ.
Prompt 3 (tuần sau nữa): "Thêm dashboard đơn giản: tổng đơn hôm nay, doanh thu hôm nay, món bán chạy nhất." Kết quả: Mỗi tuần thêm 1 tính năng. Không bao giờ hỏng. Vì mỗi lần chỉ thay đổi 1 thứ nhỏ trên nền đã ổn định.
Kết hợp với 5 bài trước: Flow hoàn chỉnh Phase 1 + Phase 2
6 bài rồi. Bạn đã có bộ công cụ tư duy hoàn chỉnh cho Phase 1 + 2:
Phase 1 (Cách nhìn):
Decomposition: Chia nhỏ ý tưởng
Pattern Recognition: Nhận diện pattern
Abstraction: Chọn level chi tiết phù hợp
Phase 2 (Cách thiết kế): 4. Algorithm Thinking: Vẽ flow từng bước + điều kiện 5. State Thinking: Liệt kê state + quy tắc chuyển state 6. MVP Thinking: Cắt xuống còn cái quan trọng nhất, build cái đó trước
Ví dụ tổng hợp: "App đặt sân bóng"
Decomposition: Đăng nhập, danh sách sân, đặt sân, thanh toán, lịch sử đặt, đánh giá Pattern Recognition: Auth, List/Filter/Search, Booking, Payment, CRUD, Rating Abstraction: Bắt đầu high-level, chi tiết khi sửa Algorithm Thinking: Flow đặt sân: chọn sân, chọn ngày, chọn giờ trống, xác nhận, thanh toán. NẾU hết giờ trống THÌ hiện thông báo. State Thinking: Đơn đặt sân: chờ thanh toán, đã thanh toán, đã xác nhận, đã hủy, hoàn tiền. MVP Thinking: Cắt hết. Chỉ giữ: danh sách sân + đặt sân + xác nhận. Không cần auth, không cần payment, không cần rating. Build trong 1 buổi. Test với 5 người chơi bóng.
6 bước tư duy. Áp dụng theo thứ tự. Từ ý tưởng mơ hồ đến prompt chính xác mà AI build đúng ngay lần đầu.
Bài tập thực hành (15 phút)
Chọn 1 ý tưởng app (hoặc dùng app bạn đang build):
App ghi chú công thức nấu ăn
Landing page cho freelancer
App quản lý thói quen hàng ngày
Làm theo 3 bước:
Bước 1 (5 phút): Liệt kê TẤT CẢ tính năng bạn muốn. Không giới hạn. Cứ viết hết ra.
Bước 2 (5 phút): Với mỗi tính năng, hỏi "Nếu không có cái này, app còn giải quyết vấn đề chính không?" Gạch bỏ những cái trả lời "có".
Bước 3 (5 phút): Viết prompt cho AI chỉ build phần còn lại. Ghi rõ "không cần" những gì bạn đã cắt.
Bài tiếp theo: Debug Thinking - "Lỗi không phải là thất bại, lỗi là manh mối." Màn hình đỏ lòm error. Bạn panic. Developer thấy cơ hội. Phase 3 bắt đầu: Tư duy Giải quyết Vấn đề.