Các nhà sáng lập và đội ngũ sản phẩm thường được khuyên "hãy xây dựng một MVP", trong khi điều họ thực sự cần là một prototype (bản mẫu) hoặc một bằng chứng khái niệm (proof of concept). Mỗi loại trả lời một câu hỏi khác nhau, đòi hỏi mức công sức khác nhau và tạo ra kết quả khác nhau. Chọn đúng loại giúp tiết kiệm thời gian và giữ ngân sách cho bước thực sự cần đến. Hướng dẫn này giải thích sự khác biệt và đưa ra một cách đơn giản để quyết định.
Đây là gì
Bằng chứng khái niệm (PoC) trả lời một câu hỏi kỹ thuật: điều này có làm được không? PoC có thể kiểm tra xem một API có trả về dữ liệu bạn cần hay không, một mô hình có phân loại tài liệu đủ chính xác hay không, hoặc hai hệ thống có thể tích hợp trong giới hạn chấp nhận được hay không. PoC thường có phạm vi hẹp, dùng xong bỏ và không được giới thiệu cho khách hàng. Prototype trả lời một câu hỏi về thiết kế và khả năng sử dụng: người dùng có thấy điều này hợp lý không? Đó có thể là các màn hình có thể nhấp hoặc một giao diện front-end gọn nhẹ không có dữ liệu thật, dùng để kiểm tra luồng thao tác, thu thập phản hồi và thống nhất quan điểm giữa các bên liên quan. Sản phẩm khả dụng tối thiểu (MVP) trả lời một câu hỏi về thị trường: người dùng thực có sử dụng sản phẩm này không, và họ có quay lại hoặc trả tiền không? MVP là phần mềm hoạt động với dữ liệu thật, được triển khai cho người dùng thật, được cố ý giới hạn ở tập tính năng nhỏ nhất mang lại giá trị cốt lõi. Vì có người thật sử dụng, MVP cần được chú trọng đúng mức về xác thực, xử lý dữ liệu và khả năng bảo trì, ngay cả khi tập tính năng nhỏ.
Dành cho ai
Bảng so sánh này hữu ích cho:
- Nhà sáng lập đang chuẩn bị đặt hàng bản xây dựng đầu tiên
- Đội ngũ sản phẩm tại các công ty đã phát triển đang tìm hiểu một dịch vụ số mới
- Nhà đầu tư hoặc hội đồng quản trị đang hỏi cột mốc tiếp theo cần tạo ra điều gì
- Đội ngũ đã xây dựng prototype và chưa chắc liệu nó có thể trở thành sản phẩm hay không
Giúp làm rõ điều gì
Việc lựa chọn giữa các phương án giúp làm rõ:
- Rủi ro nào lớn nhất ở thời điểm hiện tại: tính khả thi kỹ thuật, khả năng sử dụng hay nhu cầu thị trường
- Quyết định tiếp theo cần bằng chứng gì, và ai sẽ đưa ra quyết định đó
- Bao nhiêu phần công việc dự kiến được giữ lại so với bị loại bỏ
- Các yêu cầu về bảo mật, bảo vệ dữ liệu và kho ứng dụng đã áp dụng hay chưa
Những gì được bao gồm
- Chọn PoC nếu công nghệ cốt lõi, tích hợp hoặc nguồn dữ liệu chưa được chứng minh
- Chọn prototype nếu luồng công việc hoặc trải nghiệm người dùng chưa rõ ràng, hoặc các bên liên quan chưa thống nhất về hình hài sản phẩm
- Chọn MVP nếu tính khả thi và các luồng cốt lõi đã được hiểu rõ và bạn cần bằng chứng sử dụng thực tế
- Với bất kỳ phương án nào: ghi lại câu hỏi mà phương án đó phải trả lời và cách bạn sẽ đánh giá kết quả
- Xác định điều gì sẽ diễn ra tiếp theo cho từng kết quả: tiếp tục, điều chỉnh hay dừng lại
- Quyết định sớm liệu mã nguồn của PoC hoặc prototype có được tái sử dụng hay không; thông thường là không nên
- Với MVP: xác nhận các lựa chọn về xác thực, lưu trữ dữ liệu, quyền riêng tư và hạ tầng lưu trữ trước khi xây dựng
Những gì không được bao gồm
- Khẳng định rằng bất kỳ phương án nào trong số này bảo đảm sự phù hợp sản phẩm - thị trường hoặc mức độ chấp nhận của người dùng
- Biến một prototype dùng xong bỏ thành phần mềm production mà không qua rà soát
- Tiếp thị hoặc thu hút người dùng
- Con số ngân sách cố định; công sức phụ thuộc vào phạm vi, được xác nhận bằng văn bản
Khi nào nên chọn
Nếu bạn có thể nêu ẩn số lớn nhất của mình trong một câu, bạn thường có thể lựa chọn. "Chúng tôi không biết việc tích hợp có hoạt động không" hướng đến PoC. "Chúng tôi không biết người dùng có hiểu luồng thao tác không" hướng đến prototype. "Chúng tôi không biết người dùng có chấp nhận sản phẩm không" hướng đến MVP. Nếu bạn chưa thể nêu được ẩn số đó, hãy bắt đầu bằng công việc khám phá để xác định nó.
Phương pháp của chúng tôi
Hãy làm theo thứ tự loại bỏ nhiều rủi ro nhất với ít công sức nhất. Nhiều sản phẩm được hưởng lợi từ một giai đoạn khám phá hoặc lập bản thiết kế ngắn, một PoC tập trung vào câu hỏi kỹ thuật khó nhất, rồi đến một MVP được xây dựng dựa trên những gì đã học được. Dịch vụ Technical Feasibility & PoC của chúng tôi tạo ra hồ sơ quyết định về tính khả thi và bản tóm tắt xác thực cho một câu hỏi kỹ thuật đã xác định. App MVP Sprint của chúng tôi bàn giao một phiên bản đầu tiên hoạt động được, có phạm vi xác định, kèm tài liệu bàn giao, được xây dựng với sự chú trọng đến xác thực và xử lý dữ liệu ngay từ đầu. Khi người dùng, luồng thao tác hoặc phạm vi vẫn chưa rõ ràng, có thể thực hiện trước một Discovery Sprint hoặc một hợp đồng dịch vụ Product Blueprint & Scope. Dù chọn con đường nào, hãy thống nhất bằng văn bản về câu hỏi, ranh giới và nội dung bàn giao trước khi bắt đầu công việc, để kết quả có thể được đánh giá so với mục tiêu ban đầu.
Câu hỏi thường gặp
Bài viết liên quan
Bắt đầu
Quý doanh nghiệp chưa chắc nên bắt đầu với PoC, prototype hay MVP?
Hãy mô tả ý tưởng, ẩn số lớn nhất và quyết định mà bước tiếp theo cần hỗ trợ cho doanh nghiệp của bạn. Chúng tôi sẽ đề xuất một phạm vi khởi đầu tương xứng.
Yêu cầu phạm vi bằng văn bản