MVP là gì? Làm bản nhỏ 15 triệu trước, hay làm hẳn luôn?

Bạn có một ý tưởng. Bạn đi hỏi giá, và người ta trả lời: “Cái này nên làm MVP trước.”

Nghe như một cách nói khéo để bán bạn bản rẻ hơn. Thật ra thì ngược lại — trong phần lớn trường hợp, đó là lời khuyên tiết kiệm tiền cho bạn nhiều nhất mà bạn sẽ nhận được.

MVP là gì, nói cho gọn

Phân biệt chỗ hay nhầm nhất:

Không phải MVP	Là MVP
Làm hết mọi tính năng nhưng cái nào cũng nửa vời	Làm một tính năng cho tới nơi
Giao diện xấu, chạy chậm, hay lỗi	Ít màn hình, nhưng màn hình nào cũng chạy đúng
“Bản thử, khách chịu khó thông cảm”	Bản khách trả tiền được ngay

Cắt bớt phạm vi, không cắt bớt chất lượng. Đó là toàn bộ ý tưởng.

Vì sao nên bắt đầu từ đây?

Không phải vì rẻ. Vì phần lớn ý tưởng ban đầu đều sai ở đâu đó — và cái sai chỉ lộ ra khi có người thật đụng vào.

Thường không sai kiểu “không ai cần”. Sai kiểu tinh vi hơn: người ta cần, nhưng cần khác cách bạn nghĩ. Bạn dựng cả hệ thống đặt lịch, rồi phát hiện khách chỉ muốn nhắn tin rồi bạn tự xếp. Bạn làm mười tính năng, rồi thấy khách dùng đúng hai.

Sai trên một bản mười lăm triệu thì rẻ. Sai trên một bản tám mươi triệu, mất ba tháng, thì đắt gấp năm lần — và đắt nhất là ba tháng đó không lấy lại được.

Khi nào KHÔNG nên làm MVP?

Có thật, và ít người nói.

Khi bạn đã biết chắc thứ mình cần, vì đang làm việc đó bằng tay mỗi ngày rồi. Một cửa hàng ghi đơn vào sổ suốt ba năm không cần “thử xem có ai cần phần mềm quản lý đơn không”. Họ cần đúng cái đó, làm luôn cho đủ.

Khi phần lõi chính là phần khó. Nếu giá trị nằm ở chỗ tính toán phức tạp hay nối với hệ thống khó tính, cắt nó đi thì còn lại cái vỏ, không thử được gì.

Khi có ràng buộc pháp lý hoặc tiền của người khác ngay từ ngày đầu. Chỗ đó không có bản tối giản.

Đợi chút đã — tôi có cái này muốn giới thiệu với bạn. Đây là quảng cáo, không quan tâm thì cuộn qua vài dòng.

Hết quảng cáo. Quay lại bài.

Cắt cái gì, giữ cái gì

Cắt được	Đừng cắt
Giao diện vẽ riêng — dùng bộ có sẵn	Luồng chính chạy đúng từ đầu tới cuối
Trang quản trị đầy đủ — sửa tay trong dữ liệu cũng được	Chỗ dính tới tiền
Báo cáo, biểu đồ, thống kê	Không được mất dữ liệu của người dùng
Ứng dụng điện thoại — web mở trên điện thoại là đủ	Chạy được trên máy người dùng thật, kể cả máy cũ
Nhiều vai người dùng — bắt đầu bằng một vai	Đăng nhập an toàn
Nhập dữ liệu cũ — nhập tay vài chục dòng trước	Có cách biết ai đang dùng và dùng ra sao

Dòng cuối cùng bên phải là dòng hay bị bỏ nhất. Làm MVP mà không đo được gì thì hết một tháng bạn vẫn không biết nó có chạy hay không, và lại quyết định bằng cảm giác.

Ba câu hỏi MVP phải trả lời được

Trước khi bắt đầu, viết ra ba câu này. Xong việc thì đối chiếu lại.

1. Có ai dùng không? Bao nhiêu người thử, bao nhiêu người quay lại lần hai.
2. Họ có trả tiền không? Nói “hay đấy” không phải câu trả lời. Chuyển khoản mới là.
3. Chỗ nào họ bỏ giữa chừng? Đây là câu đắt nhất — nó chỉ ra thứ phải sửa trước khi làm tiếp.

Nếu MVP của bạn không trả lời được cả ba câu này thì nó chưa phải MVP, nó chỉ là một bản nhỏ.

Sau MVP thì làm gì

Ba đường, và đường thứ ba mới là đường hay bị bỏ qua:

• Chạy tốt — làm tiếp, mở rộng dần theo thứ người dùng thật đòi.
• Chạy nhưng lệch — người ta dùng theo cách bạn không ngờ. Xoay theo hướng đó, thường đây là kết quả tốt nhất.
• Không ai dùng — dừng lại. Bạn vừa tiết kiệm được số tiền lẽ ra đã đốt vào bản đầy đủ. Đây là thành công, không phải thất bại, dù không ai muốn nghe câu đó.

Tóm lại một câu

MVP không phải bản rẻ tiền của thứ bạn muốn. Nó là cách rẻ nhất để biết thứ bạn muốn có đáng làm không — trước khi bạn bỏ vào đó số tiền lớn và ba tháng không lấy lại được.

Muốn biết khoảng tiền cho từng nhóm việc thì xem bài về chi phí và thời gian. Sắp đi hỏi báo giá thì xem trước bảy câu nên hỏi.