MVP / MVE Scoping

MVP để học, không phải bản v1 thu nhỏ

Ở nhiều công ty Việt Nam, "MVP" đã trở thành tên gọi khác của "phiên bản đầu tiên, làm gấp". Đội lấy danh sách 40 tính năng, cắt còn 25, làm năm tháng, gọi đó là MVP. Khi ra mắt không ai dùng, không ai biết vì sao — vì 25 tính năng thay đổi cùng lúc thì không thể biết cái nào sai.

MVP tồn tại để trả lời một câu hỏi với chi phí thấp nhất có thể. Câu hỏi đó thường là: "Giả định rủi ro nhất của chúng ta có đúng không?" Nếu một bản thử làm trong hai tuần trả lời được câu hỏi đó, thì hai tuần chính là MVP — dù nó không có một dòng code nào.

Minimum Viable Experience — khi người dùng không tha thứ cho sự thô sơ

MVP thô sơ hợp lý khi người dùng sẵn sàng chịu đựng để giải quyết một vấn đề đau. Nhưng ở nhiều thị trường, người dùng đã quen với ứng dụng ngân hàng, ví điện tử và sàn TMĐT rất mượt. Một sản phẩm tài chính trông cẩu thả không chỉ bị chê — nó bị nghi là lừa đảo.

Minimum Viable Experience (MVE) giữ nguyên tinh thần của MVP — tối thiểu, để học — nhưng đổi cách cắt: cắt chiều rộng, không cắt chất lượng. Làm ít việc hơn, nhưng mỗi việc làm được phải trọn vẹn và đáng tin.

Ví dụ: một ứng dụng đầu tư chứng chỉ quỹ không cần mười loại quỹ, biểu đồ phân tích và mạng xã hội nhà đầu tư. MVE có thể chỉ là một quỹ, một luồng nạp tiền, một màn hình xem lãi lỗ — nhưng luồng eKYC phải mượt, số liệu phải chính xác tới từng đồng, và có số hotline thật.

Sáu loại MVP, và chọn loại từ giả định rủi ro nhất

Bắt đầu từ giả định, không bắt đầu từ loại MVP. Viết ra các giả định mà nếu sai thì dự án chết, xếp theo mức độ chưa chắc chắn, và chọn loại MVP kiểm được giả định đứng đầu với chi phí thấp nhất.

Ghép giả định với loại: nếu rủi ro lớn nhất là "người ta có muốn không" — fake door. "Có chịu trả tiền không" — pre-sale. "Mình có làm ra kết quả tốt được không" — concierge. "Có làm được bằng máy không" — Wizard of Oz rồi mới đầu tư kỹ thuật. "Có dùng được không" — prototype test. "Có quay lại dùng không" — single-feature.

Ví dụ đã điền: problem brief và tiêu chí dừng cho ThợNhanh

Bối cảnh (giả định): một nhóm ở TP.HCM muốn làm ứng dụng đặt thợ sửa điều hoà, máy giặt, với đặt cọc trước để giảm tình trạng khách huỷ và thợ bùng hẹn. Họ đã có danh sách 30 tính năng và định thuê một công ty outsourcing làm trong 4 tháng.

PROBLEM BRIEF — ThợNhanh, MVP vòng 1

Vấn đề: Hộ gia đình ở quận 7 và Bình Thạnh khó tìm thợ đến đúng giờ;
thợ mất 20-30% lịch hẹn vì khách huỷ phút chót.

Giả định rủi ro nhất: Khách chịu đặt cọc 50.000đ online trước khi thợ đến.
(Nếu sai, mô hình đặt cọc không đứng được, phải đổi toàn bộ cách làm.)

Loại MVP: Concierge. Zalo OA + Google Form + chuyển khoản QR.
3 người trong nhóm tự điều phối 15 thợ quen. Không viết code.

Thời gian: 3 tuần. Chi phí: khoảng 12 triệu quảng cáo Facebook theo khu vực.

Tiêu chí thành công (viết trước, không sửa sau):
  - Ít nhất 200 yêu cầu đặt lịch
  - Ít nhất 30% số yêu cầu chuyển khoản đặt cọc
  - Tỉ lệ huỷ trong nhóm đã cọc dưới 10%

Tiêu chí dừng:
  - Dưới 10% đặt cọc, HOẶC dưới 80 yêu cầu sau 3 tuần

Vùng giữa (10-30%): phỏng vấn 15 khách không cọc, thử một biến thể
(cọc hoàn lại 100%) thêm 2 tuần.

KHÔNG làm trong vòng này: ứng dụng di động, đánh giá thợ, chat,
thanh toán trong app, các quận khác, máy lọc nước, tủ lạnh.

Vì sao viết tiêu chí trước: sau ba tuần làm việc vất vả, mọi người đều muốn thấy thành công. Con số 18% sẽ được gọi là "khá hứa hẹn" nếu không có ngưỡng đã chốt. Ngưỡng viết trước bảo vệ đội khỏi sự lạc quan của chính mình. So với kế hoạch ban đầu, nhóm tiết kiệm được gần bốn tháng và vài trăm triệu nếu giả định đặt cọc là sai.

Cắt phạm vi: phải có, nên có, có thì tốt, và danh sách "không"

Cắt phạm vi khó vì mọi tính năng đều có người bảo vệ. Câu hỏi giúp cắt nhanh nhất là: "Nếu bỏ cái này, chúng ta có còn trả lời được câu hỏi của MVP không?" Nếu vẫn trả lời được, nó không thuộc nhóm phải có.

Danh sách "không" quan trọng ngang danh sách "có". Nó cho phép đội nói với sếp và khách hàng: "Chúng tôi biết, chúng tôi đã cân nhắc, và cố ý chưa làm." Thiếu danh sách này, mỗi cuộc họp sẽ có người thêm một tính năng "nhỏ thôi" và MVP phình thành v1.

Với dự án outsourcing: khách hàng thường muốn hợp đồng cho toàn bộ sản phẩm. Đề xuất chia giai đoạn có điểm quyết định — giai đoạn một là MVP với tiêu chí rõ ràng — vừa giảm rủi ro cho khách, vừa xây niềm tin để có giai đoạn hai.

Đọc tín hiệu sớm: tiếp tục, xoay hướng, hay dừng

Dừng không phải thất bại. Một MVP ba tuần dẫn tới quyết định dừng đã tiết kiệm cho công ty nhiều tháng làm sản phẩm không ai cần. Đội nên được ghi nhận vì điều đó, nếu không lần sau sẽ không ai dám đặt tiêu chí dừng thật.

Cẩn thận với tín hiệu giả: lời khen trong phỏng vấn, người quen đăng ký ủng hộ, lượt bấm từ quảng cáo nhắm sai đối tượng. Tín hiệu thật là hành động có giá: tiền, thời gian, dữ liệu cá nhân, hoặc quay lại lần thứ hai mà không ai nhắc.

Lỗi thường gặp

Luyện trong tuần này

• Lấy dự án hoặc tính năng lớn tiếp theo của đội và viết ra năm giả định mà nếu sai thì dự án thất bại. Khoanh tròn giả định bạn ít chắc nhất.
• Chọn loại MVP rẻ nhất kiểm được giả định đó từ bảng sáu loại. Nếu câu trả lời là "phải làm app thật", thử ép thêm một lần — gần như luôn có cách rẻ hơn.
• Viết problem brief một trang theo mẫu ThợNhanh, gồm tiêu chí thành công, tiêu chí dừng và danh sách "không".
• Đem brief cho một người hoài nghi đọc và hỏi: con số nào ở tiêu chí dừng khiến bạn thật sự sẵn sàng dừng?
• Nếu đang có một "MVP" chạy quá ba tháng, viết ra câu hỏi nó đang cố trả lời. Nếu không viết được trong một câu, đó là việc đầu tiên cần sửa.