Làm MVP trước hay làm đủ tính năng: tính bằng tiền, không bằng cảm giác

Mọi người đều khuyên làm MVP trước. Lời khuyên đó đúng phần lớn thời gian và sai một cách tốn kém trong vài trường hợp cụ thể. Bài này nói về cả hai.

MVP thực sự là gì, và không phải là gì

MVP không phải "phiên bản rút gọn". Nó là phiên bản đủ để trả lời một câu hỏi bạn chưa biết đáp án.

Nếu bạn không nêu được câu hỏi đó thành một câu, bạn không đang làm MVP — bạn đang làm phần mềm thiếu tính năng, và đó là thứ khác hẳn.

Câu hỏi tốt: "nhân viên bán hàng có chịu nhập đơn vào điện thoại ngay tại chỗ, hay vẫn ghi giấy rồi nhập cuối ngày?" Đó là câu hỏi về hành vi, không đoán được, và trả lời được bằng một phiên bản nhỏ.

Câu hỏi giả: "phần mềm có hoạt động không?" Cái đó không cần MVP để biết.

Khi chia giai đoạn là đúng

Bạn chưa biết người dùng sẽ dùng thế nào. Đây là lý do số một và đủ để quyết định một mình. Mọi phần mềm nội bộ đều gặp chuyện này: quy trình trên giấy và thói quen thực tế không giống nhau.

Nghiệp vụ của bạn đang thay đổi. Nếu công ty bạn vừa mở chi nhánh thứ hai hoặc vừa đổi cách tính hoa hồng, đóng băng nghiệp vụ vào phần mềm lúc này là đóng băng một thứ đang di chuyển.

Bạn cần thấy kết quả để thuyết phục người khác. Một bản chạy được sau sáu tuần thuyết phục hội đồng quản trị tốt hơn một tài liệu 40 trang.

Ngân sách theo quý. Chia giai đoạn cho bạn điểm dừng hợp lý ở cuối mỗi giai đoạn, thay vì một cam kết duy nhất.

Khi chia giai đoạn đắt hơn

Đây là phần ít ai nói, và nó có thật.

Khi nền dữ liệu phải làm lại giữa các giai đoạn. Ví dụ cụ thể: giai đoạn một làm cho một chi nhánh, giai đoạn hai thêm nhiều chi nhánh. Nếu giai đoạn một không thiết kế dữ liệu theo nhiều chi nhánh từ đầu, giai đoạn hai là viết lại, không phải thêm vào. Chi phí cộng lại lớn hơn làm một lần 30–50%.

Cách xử lý: thiết kế dữ liệu cho đích, xây giao diện cho hiện tại. Bảng dữ liệu có cột chi nhánh từ ngày đầu, dù giao diện giai đoạn một chưa cho chọn chi nhánh. Chi phí thêm gần như bằng không, và nó cứu bạn khỏi việc viết lại.

Khi quy trình là một khối không chia được. Có những nghiệp vụ mà nửa quy trình không dùng được. Một hệ thống tính lương làm được phần chấm công nhưng chưa tính được lương thì không ai dùng — họ vẫn phải làm Excel song song, và bạn trả tiền cho phần mềm không ai mở.

Kiểm tra bằng câu hỏi: sau giai đoạn một, có ai bỏ được cách làm cũ chưa? Nếu không, đừng gọi nó là giai đoạn một; đó là phần một của một khối.

Khi chi phí chuyển đổi cao và phải làm hai lần. Đào tạo 40 nhân viên hai lần, chuyển dữ liệu hai lần, chạy song song hai lần. Với đội ngũ lớn, chi phí này vượt phần tiết kiệm được từ việc chia giai đoạn.

Phép thử ba câu

1. Sau giai đoạn một, có người nào bỏ được công việc thủ công không? Không → đừng chia giai đoạn theo cách bạn đang định.

2. Giai đoạn hai có cần đổi cấu trúc dữ liệu của giai đoạn một không? Có → thiết kế dữ liệu cho cả hai ngay từ đầu, dù chỉ xây giao diện cho giai đoạn một.

3. Bạn có câu hỏi nào về hành vi người dùng mà không đoán được không? Có → chia giai đoạn, và thiết kế giai đoạn một quanh đúng câu hỏi đó.

Con đường trung dung mà chúng tôi hay dùng

Một giai đoạn, nhưng phạm vi hẹp và đủ để thay thế.

Cụ thể: chọn một quy trình hoàn chỉnh, làm hết nó, làm tốt. Không phải nửa quy trình của ba việc — mà toàn bộ một việc. Sau bốn tới tám tuần có người thật bỏ được Excel, và bạn có dữ liệu thật để quyết định việc tiếp theo.

Đây khác MVP ở chỗ nó không phải bản thử; nó là một phần mềm hoàn chỉnh cho một phạm vi nhỏ. Và nó khác "làm đủ" ở chỗ bạn chưa cam kết với năm quy trình còn lại.

Dịch vụ của chúng tôi mặc định chạy theo cách này, và trong giai đoạn chốt phạm vi chúng tôi sẽ chủ động đề nghị bạn cắt bớt — thường là cắt vai trò người dùng, vì đó là chỗ tiết kiệm nhiều nhất.

Một điều đáng nhớ

Quyết định sai đắt nhất không phải chọn MVP hay làm đủ. Nó là chia giai đoạn mà không thiết kế dữ liệu cho đích — vì lúc đó bạn trả hai lần cho cùng một thứ và không được lợi gì từ việc chia.

Khi bàn phạm vi với bất kỳ ai, hãy hỏi câu này: "cấu trúc dữ liệu của giai đoạn một có chứa được giai đoạn hai không?" Bên nào trả lời chi tiết là bên đã nghĩ tới nó.