Nhiều dự án gọi mọi bản build sớm là MVP. Hậu quả là một prototype kiểm tra mechanic bị kỳ vọng phải đẹp như sản phẩm; một vertical slice bị mở rộng thành hàng chục level; hoặc một MVP đưa ra thị trường nhưng không có tracking và operations để học. Ba artifact này có thể nối tiếp nhau, nhưng chúng tồn tại để trả lời ba loại rủi ro khác nhau.
Trả lời ngắn: Prototype kiểm tra một cơ chế hoặc giả thuyết với chi phí thấp. Vertical slice chứng minh một lát trải nghiệm có chất lượng tích hợp gần mục tiêu và pipeline có thể sản xuất. MVP là phiên bản tối thiểu có thể cung cấp giá trị cho nhóm người dùng thực và tạo dữ liệu phục vụ quyết định sản phẩm. Chọn artifact bằng câu hỏi rủi ro, không bằng tên gọi theo xu hướng.
Prototype: Câu hỏi “Có hoạt động/có tạo cảm giác mong muốn không?”; fidelity thấp; test nội bộ/người chơi nhỏ; code và art có thể tạm.
Vertical slice: Câu hỏi “Team có tạo được chuẩn chất lượng và pipeline này không?”; fidelity gần target; nội dung hẹp; tích hợp cross-functional.
MVP: Câu hỏi “Nhóm người dùng thực có nhận giá trị và hành vi có ủng hộ hướng sản phẩm không?”; end-to-end; đủ ổn định, đo lường và vận hành.
Prototype nên cô lập rủi ro lớn nhất. Nếu rủi ro là control feel, prototype tập trung input, camera và feedback. Nếu rủi ro là puzzle depth, cần vài tình huống để quan sát quyết định, không cần shop hoặc narrative.
Tuy nhiên, “code bỏ đi” không đồng nghĩa code tùy tiện. Prototype vẫn cần chạy ổn đủ để test. Nếu bug làm người chơi hiểu sai mechanic, kết quả không còn đáng tin.
Keep, modify, compare alternative hoặc stop. Prototype không thành công khi “đã làm xong build”; nó thành công khi giảm bất định.
Vertical slice chọn một lát đại diện, thường gồm core gameplay, art, UI, audio, performance và content pipeline. Nó trả lời liệu vision có thể tồn tại trong engine và liệu team có lặp được chất lượng đó.
Team có thể tạo một lát đẹp bằng thao tác thủ công, script riêng và overtime, nhưng không sản xuất lần hai. Hãy ghi lại tool, handoff, rework và thời gian thật. Vertical slice chỉ có giá trị production khi pipeline tái tạo được.
Production greenlight, scope reduction, pipeline investment hoặc art/technical pivot.
MVP cần tối thiểu nhưng phải viable. Với game, viable không chỉ là “chơi được một level”. Người dùng phải vào được, hiểu giá trị, trải nghiệm loop đủ để thể hiện hành vi, còn team phải thu được dữ liệu và hỗ trợ cơ bản.
MVP có thể cần:
MVP không nhất thiết public rộng. Closed test hoặc limited audience vẫn là người dùng thật nếu hành vi đủ đại diện và mục tiêu rõ.
Problem/experience validation, iterate, pivot, expand, hoặc stop. Không dùng vài lời khen thay cho evidence hành vi.
“Control có fun không?” → Prototype.
“Art style, combat, UI và performance có đạt target cùng lúc không?” → Vertical slice.
“Người chơi mục tiêu có quay lại sau khi trải nghiệm loop và progression tối thiểu không?” → MVP.
“Team có thể sản xuất 30 level với pipeline hiện tại không?” → Vertical slice + production spike.
“Market có phản hồi với concept/store promise không?” → Store/concept test trước; chưa chắc cần MVP đầy đủ.
Một dự án có thể cần nhiều prototype song song, một vertical slice và vài MVP stage. Tên artifact không quan trọng bằng decision.
Tạo danh sách risk:
Xếp impact và uncertainty. Artifact đầu tiên nên tấn công ô impact cao–uncertainty cao. Nếu rủi ro lớn nhất là combat feel, làm account system trước không giảm rủi ro dự án.
Fidelity gồm visual, interaction, technical và content. Chúng không cần tăng cùng nhau.
Polish chỉ có giá trị khi giảm bias test hoặc chứng minh quality bar. Nếu placeholder khiến người chơi không hiểu affordance, cần nâng UI; nếu art không liên quan câu hỏi, giữ đơn giản.
Task ngắn, think-aloud có chọn lọc, quan sát input/error/decision. Mẫu nhỏ có thể hữu ích cho qualitative learning; không giả vờ có statistical validation.
Cross-functional review, target-device profiling, content-pipeline retrospective, art/UX quality bar và effort capture.
Cohort, event funnel, retention window phù hợp, qualitative interview, review/support, incident và economics hypothesis. Bảo đảm consent và data quality.
Không có câu hỏi dừng: Mỗi feedback tạo thêm feature.
Stakeholder dùng khác định nghĩa: Người muốn pitch, người muốn production proof, người muốn market validation.
Polish để tránh quyết định: Team tiếp tục làm đẹp vì chưa dám kết luận mechanic yếu.
Architecture quá sớm: Xây hệ scale trước khi biết feature sống.
Prototype được đưa vào production không assessment: Temporary code trở thành dependency.
MVP không có đo lường: Có người dùng nhưng không biết học gì.
Không copy toàn bộ prototype vào production. Trước handoff:
Một prototype thất bại có thể là đầu ra có giá trị nếu giúp team dừng sớm. Một prototype “thành công” nhưng không ghi learning có thể bị diễn giải quá mức.
Trước buổi làm việc, mỗi stakeholder viết riêng câu trả lời cho sáu câu:
Trong buổi họp, so sự khác nhau. Nếu một người muốn prototype để kiểm tra mechanic, một người muốn vertical slice để pitch và một người muốn MVP để đo retention, dự án đang có ba mục tiêu. Hoặc tách artifact, hoặc khóa một decision ưu tiên.
Đừng chỉ estimate bằng số màn hình hoặc feature. Chia effort theo build, content, art, UX, tech, data, test, analysis và handoff. Một MVP có ít feature nhưng cần distribution, consent, analytics và support; một prototype có thể có một mechanic nhưng cần nhiều alternative để so.
Mỗi milestone cần “learning complete”:
Nếu chỉ giao build, phần quan trọng nhất của artifact vẫn chưa hoàn thành.
Theo Game Studio brief, SAVA có thể đồng hành từ prototype/MVP đến full-cycle, co-development hoặc dedicated team. Điểm bắt đầu nên do risk và current state quyết định. Nếu client có concept chưa test, một prototype có thể phù hợp. Nếu đã có core loop nhưng cần chứng minh quality/pipeline, vertical slice có giá trị hơn. Nếu sản phẩm cần evidence từ audience, MVP cần measurement và operations.
Discovery cần khóa IP, source asset, technical constraint, target device, quality bar, owner và decision gate trước estimate.
Cần đủ ổn định và rõ để test. Không nhất thiết production-ready, nhưng phải ghi technical debt và không tự động đưa vào production.
Không luôn luôn. Có thể dùng closed/internal distribution nếu người dùng và hành vi đủ đại diện. Store test riêng có thể cần khi câu hỏi là conversion.
Không có số chung. Chọn lượng nội dung nhỏ nhất đại diện cho gameplay, quality bar và pipeline.
Có thể nếu mechanic và risk đã được chứng minh bằng build hiện có. Nhưng vẫn cần evidence; không bỏ qua chỉ vì timeline gấp.
Tùy mục tiêu pitch. Prototype chứng minh ý tưởng chơi được; vertical slice chứng minh chất lượng tích hợp. Cần thống nhất kỳ vọng trước.
Primary CTA: Gửi concept hoặc build để cùng SAVA META xác định artifact nhỏ nhất có thể trả lời rủi ro lớn nhất của dự án.
Bài viết liên quan
