Xác định điều cần học trước khi chọn tính năng
MVP nên bắt đầu bằng một câu hỏi kinh doanh chưa có câu trả lời chắc chắn, chẳng hạn khách hàng có sẵn sàng tự nhập dữ liệu hay nhân viên có xử lý công việc nhanh hơn khi dùng quy trình mới. Nguyên tắc Agile ưu tiên bàn giao sớm phần mềm có giá trị, tiếp nhận thay đổi và xem phần mềm hoạt động được là thước đo tiến độ. Cách tiếp cận này phù hợp với mục tiêu học sớm của MVP. [1]
Gợi ý: viết giả định theo cấu trúc “đối tượng nào, gặp vấn đề gì, hành vi nào sẽ cho thấy giải pháp có ích”. Sau đó chỉ giữ những chức năng trực tiếp tạo ra hoặc đo được hành vi đó. Các ý tưởng còn lại nên nằm trong danh sách chờ thay vì mặc nhiên trở thành phạm vi phiên bản đầu.
Chọn một hành trình hoàn chỉnh
Một MVP hữu ích thường bao phủ một luồng xuyên suốt từ đầu vào đến kết quả, thay vì có nhiều màn hình nhưng mỗi quy trình đều dở dang. Doanh nghiệp cần xác định rõ người dùng đầu tiên, điểm bắt đầu, kết quả họ nhận được và cách xử lý khi dữ liệu thiếu hoặc thao tác thất bại.
Ví dụ: với hệ thống tiếp nhận yêu cầu bảo trì, MVP có thể chỉ cho phép nhân viên gửi yêu cầu, người phụ trách cập nhật trạng thái và người gửi xem kết quả. Báo cáo nâng cao, phân công tự động và tích hợp nhiều kênh có thể để sau nếu chúng chưa cần thiết để kiểm tra quy trình cốt lõi.
Tối thiểu phạm vi, không tối thiểu trách nhiệm
Không nên cắt bỏ tùy tiện các yêu cầu về phân quyền, bảo vệ dữ liệu, sao lưu, khả năng theo dõi lỗi hoặc vận hành. Tài liệu kiến trúc Azure nêu rằng thiết kế ứng dụng cần cân nhắc độ tin cậy, bảo mật, chi phí, vận hành và hiệu năng theo yêu cầu kinh doanh. Mức triển khai cụ thể vẫn phụ thuộc dữ liệu, người dùng và môi trường của từng sản phẩm. [2]
Gợi ý: phân loại yêu cầu thành ba nhóm gồm bắt buộc để vận hành có trách nhiệm, cần để kiểm chứng giả định và có thể trì hoãn. Cách phân loại này giúp tránh hai cực đoan: xây đầy đủ như sản phẩm trưởng thành hoặc phát hành một bản thiếu những kiểm soát thiết yếu. Các biện pháp bảo mật chỉ giúp giảm rủi ro, không tạo ra bảo đảm an toàn tuyệt đối.
Đặt tiêu chí quyết định trước khi phát triển
Mỗi tín hiệu nên gắn trực tiếp với giả định ban đầu. Có thể theo dõi người dùng có hoàn thành luồng chính hay không, họ dừng ở bước nào, mất bao lâu để nhận kết quả hoặc cần hỗ trợ ở đâu. Không nên chọn chỉ số chỉ vì dễ thu thập nếu nó không giúp doanh nghiệp quyết định tiếp tục, sửa đổi hay dừng hướng sản phẩm.
Gợi ý: thống nhất trước phạm vi người dùng, thời gian quan sát, dữ liệu cần ghi nhận và người có quyền đưa ra quyết định. Ngưỡng đánh giá nên phản ánh bối cảnh thực tế, không sao chép máy móc từ sản phẩm khác. Phản hồi định tính cũng cần được lưu cùng hành vi thực tế để tránh diễn giải một con số thiếu bối cảnh.
Kiểm soát yêu cầu mới bằng giả định
Trong quá trình phát triển, yêu cầu mới là bình thường. Agile coi khả năng tiếp nhận thay đổi và sự phối hợp thường xuyên giữa người làm kinh doanh với nhóm phát triển là quan trọng; đồng thời nhấn mạnh sự đơn giản, tức tối đa hóa phần việc không cần làm. Điều này không có nghĩa chấp nhận mọi yêu cầu ngay lập tức, mà cần xem lại giá trị và thứ tự ưu tiên. [1]
Gợi ý: với mỗi yêu cầu mới, hỏi nó kiểm chứng giả định nào, có cần cho hành trình chính không và điều gì xảy ra nếu để sang vòng sau. Khi MVP đã có dữ liệu sử dụng, doanh nghiệp có thể mở rộng phần tạo giá trị, điều chỉnh giả định hoặc dừng hướng chưa hiệu quả. Đây là quyết định sản phẩm, không phải đánh giá thành công chỉ dựa trên số tính năng đã hoàn thành.