MVP là gì? Khi nào doanh nghiệp nên làm MVP

MVP là gì? MVP (Minimum Viable Product, sản phẩm khả dụng tối thiểu) là phiên bản đầu tiên của một phần mềm, chỉ gồm những tính năng cần thiết nhất để người dùng thật có thể dùng được và giải quyết được vấn đề chính. Mục tiêu của MVP không phải là tiết kiệm bằng cách làm sơ sài, mà là kiểm chứng sớm một giả định quan trọng trước khi đầu tư lớn. Bài viết giải thích MVP khác gì bản demo hay prototype, khi nào doanh nghiệp nên làm MVP, cách chọn tính năng và cách đo kết quả.

MVP là gì, hiểu đúng trong bối cảnh doanh nghiệp

Thuật ngữ MVP phổ biến trong giới khởi nghiệp, nhưng áp dụng rất tốt cho doanh nghiệp đang chuẩn bị xây một phần mềm nội bộ hoặc một app cho khách hàng. Ba từ trong tên gọi đều quan trọng:

• Minimum (tối thiểu): chỉ giữ những gì phục vụ trực tiếp vấn đề chính. Mọi thứ khác để sau.
• Viable (khả dụng): phải dùng được trong công việc thật, ổn định, dữ liệu đúng. Một bản lỗi liên tục không phải là MVP.
• Product (sản phẩm): người dùng thật sử dụng với dữ liệu thật, không chỉ xem trình diễn.

Ví dụ: một công ty muốn số hóa quy trình đặt hàng của đại lý. Thay vì xây ngay cổng đặt hàng đầy đủ với khuyến mãi, công nợ, báo cáo, app di động, bản MVP có thể chỉ gồm danh mục sản phẩm, giỏ hàng, gửi đơn và màn hình xử lý đơn cho nhân viên, chạy thử với một nhóm đại lý. Nếu đại lý dùng đều đặn, các phần còn lại mới được bổ sung.

MVP khác gì prototype và bản demo

• Prototype (bản mẫu): mô phỏng giao diện, bấm thử được nhưng thường không có dữ liệu thật phía sau. Dùng để thống nhất yêu cầu và trải nghiệm, chi phí thấp, làm trong thời gian ngắn.
• Bản demo, proof of concept: chứng minh một điểm kỹ thuật có làm được hay không, ví dụ kết nối được máy chấm công hay đọc được một loại chứng từ. Không dành cho người dùng hằng ngày.
• MVP: phần mềm chạy thật, người dùng thật dùng trong công việc, có dữ liệu và có thể đo lường. Là nền móng để phát triển tiếp, không phải bản bỏ đi.

Ba loại này không loại trừ nhau. Một dự án hợp lý thường đi từ prototype để chốt yêu cầu, sang MVP để đưa vào sử dụng, rồi mở rộng theo từng giai đoạn.

Khi nào doanh nghiệp nên làm MVP

• Chưa chắc người dùng sẽ dùng: app cho khách hàng, cổng cho đại lý, công cụ mới cho nhân viên quen làm theo cách cũ.
• Yêu cầu còn mơ hồ hoặc mỗi bộ phận nói một kiểu: dùng thật một bản nhỏ sẽ làm rõ yêu cầu nhanh hơn nhiều vòng họp.
• Ngân sách cần được duyệt theo giai đoạn: MVP cho ban lãnh đạo thấy kết quả cụ thể trước khi duyệt phần tiếp theo.
• Thị trường hoặc quy trình thay đổi nhanh: làm ngắn, học nhanh tốt hơn xây một hệ thống lớn dựa trên giả định cũ.

Khi nào không nên làm MVP theo nghĩa “tối giản”

• Thay thế một hệ thống đang chạy: người dùng không chấp nhận bản mới làm được ít hơn bản cũ. Nên chuyển đổi theo từng phân hệ, mỗi phân hệ phải đầy đủ.
• Nghiệp vụ bắt buộc đúng ngay từ đầu: tính lương, hóa đơn, kế toán, dữ liệu y tế. Phạm vi có thể nhỏ, nhưng phần đã làm phải chính xác và tuân thủ quy định.
• Yêu cầu đã rõ và ổn định: ví dụ số hóa một biểu mẫu đã dùng nhiều năm. Làm MVP lúc này ít giá trị học hỏi.

Cách chọn tính năng cho MVP

Đây là bước khó nhất, vì mỗi bộ phận đều thấy tính năng của mình quan trọng. Một cách làm thực tế:

1. Viết ra một giả định cần kiểm chứng. Ví dụ: “Đại lý sẽ tự đặt hàng qua cổng thay vì gọi điện cho nhân viên kinh doanh.”
2. Vẽ hành trình chính của người dùng từ lúc bắt đầu đến lúc xong việc. Chỉ giữ các bước bắt buộc để đi hết hành trình đó.
3. Phân loại các tính năng còn lại theo nhóm phải có, nên có, có thể để sau. MVP chỉ gồm nhóm phải có.
4. Cho phép làm tay ở phía sau. Ví dụ báo cáo có thể xuất Excel thay vì làm dashboard, thông báo có thể gửi email thay vì làm app. Người dùng không cảm thấy khác biệt, chi phí giảm đáng kể.
5. Không cắt các phần nền móng: phân quyền, sao lưu, nhật ký thao tác, cấu trúc dữ liệu. Cắt những phần này thì sau phải làm lại.

Cách viết yêu cầu theo user story và phân loại ưu tiên được hướng dẫn chi tiết trong bài Cách viết tài liệu yêu cầu phần mềm cho người không làm IT.

Đo kết quả MVP như thế nào

MVP chỉ có giá trị khi trước lúc làm đã thống nhất cách đánh giá. Nên chọn vài chỉ số gắn với giả định ban đầu, ví dụ:

• Tỷ lệ người dùng mục tiêu thực sự dùng sau vài tuần, không chỉ đăng nhập lần đầu.
• Số lượng giao dịch, hồ sơ, đơn hàng đi qua hệ thống so với cách làm cũ.
• Thời gian xử lý một việc trước và sau.
• Phản hồi và các yêu cầu bổ sung lặp lại nhiều nhất.

Sau giai đoạn chạy thử, doanh nghiệp có ba lựa chọn: mở rộng theo kế hoạch, điều chỉnh hướng đi dựa trên dữ liệu thật, hoặc dừng lại với chi phí đã được giới hạn. Cả ba đều là kết quả tốt hơn so với việc phát hiện vấn đề sau khi đã xây xong toàn bộ hệ thống.

Những sai lầm thường gặp khi làm MVP

• Coi MVP là bản làm vội: mã nguồn chắp vá, không thể phát triển tiếp, cuối cùng phải viết lại.
• MVP phình to dần: mỗi buổi họp thêm một tính năng “nhỏ”, đến lúc phát hành đã không còn tối thiểu.
• Không có người dùng thật thử nghiệm: chỉ nội bộ đội dự án dùng thử thì không kiểm chứng được gì.
• Không định nghĩa thành công từ trước: chạy xong không biết nên mở rộng hay dừng.
• Bỏ qua trải nghiệm: tối thiểu về số tính năng, không phải tối thiểu về chất lượng. Người dùng bỏ đi vì khó dùng thì MVP không chứng minh được gì.

MVP trong quy trình phát triển phần mềm theo yêu cầu

Với phần mềm theo yêu cầu, MVP thường là giai đoạn 1 trong lộ trình nhiều giai đoạn. Cách chia này giúp doanh nghiệp kiểm soát ngân sách, có sản phẩm dùng được sớm và giảm rủi ro xây sai. Xem thêm các bước của một dự án trong bài Quy trình phát triển phần mềm theo yêu cầu và các yếu tố ảnh hưởng ngân sách trong bài Chi phí làm phần mềm theo yêu cầu.

Nếu bạn đang có ý tưởng phần mềm nhưng chưa chắc nên bắt đầu từ đâu, DTCSoft có thể cùng bạn xác định giả định cần kiểm chứng, phạm vi MVP và lộ trình các giai đoạn tiếp theo. Tìm hiểu thêm về dịch vụ phát triển phần mềm theo yêu cầu.

Câu hỏi thường gặp