MVP là gì? MVP (Minimum Viable Product) là phiên bản nhỏ nhất của sản phẩm vẫn dùng được thật và cho bạn biết ý tưởng có đúng hay không. Với phần mềm nội bộ của doanh nghiệp, hiểu đơn giản: đó là bản đầu tiên chỉ làm tốt một quy trình quan trọng nhất, đưa vào dùng thật, rồi mới mở rộng.
Khái niệm này thường gắn với công ty khởi nghiệp, nhưng nó hữu ích không kém cho chủ doanh nghiệp đang số hóa một phần công việc. Lý do rất thực tế: làm toàn bộ hệ thống một lần dễ trễ, khó đoán chi phí, và đến lúc dùng mới phát hiện hiểu sai quy trình.
MVP không có nghĩa là làm sơ sài
Đây là hiểu lầm phổ biến. Bản đầu tiên có ít chức năng, nhưng những chức năng đó phải chạy ổn định, an toàn và đủ dùng cho công việc thật. Một MVP tốt:
- Giải quyết một vấn đề cụ thể, có người dùng thật cần mỗi ngày
- Có phân quyền và sao lưu dữ liệu ở mức cơ bản
- Cho phép nhập và xem dữ liệu thật, không phải dữ liệu mẫu
- Được thiết kế để thêm tính năng sau mà không phải làm lại từ đầu
Cắt tính năng khác với cắt chất lượng. Bạn bớt phạm vi, không bớt độ tin cậy.
Cách chọn bản đầu tiên cho phần mềm nội bộ
Bắt đầu từ chỗ đau nhất
Hỏi các bộ phận: việc nào đang tốn công nhất, hay sai nhất, hay làm chậm các việc khác? Đó thường là ứng viên cho bản đầu. Ví dụ giả định: nếu công ty hay nhầm tồn kho, bản đầu nên là nhập xuất kho và tồn kho, chưa cần báo cáo doanh thu phức tạp.
Chọn một quy trình trọn vẹn, đừng chọn nhiều quy trình dở dang
Một quy trình từ đầu đến cuối (ví dụ nhận đơn, duyệt, xuất kho) hữu dụng hơn mười màn hình rời rạc. Người dùng thấy được lợi ích ngay vì công việc thật được hoàn tất trong phần mềm.
Dùng ba nhóm để phân loại tính năng
- Phải có: thiếu thì không thể dùng thật, ví dụ nhập đơn, phân quyền, in phiếu.
- Nên có: tiện hơn nhưng có thể làm tạm thủ công, ví dụ báo cáo tự gửi qua email.
- Để sau: ý tưởng hay chưa cần ngay, ví dụ ứng dụng di động, tích hợp phụ, bảng điều khiển đẹp.
Chỉ đưa nhóm "phải có" vào bản đầu. Nhóm còn lại ghi vào danh sách để xếp ở các giai đoạn sau.
Hỏi "nếu bỏ tính năng này thì sao"
Với mỗi tính năng, hãy thử hỏi: nếu chưa có, nhân viên có thể làm tạm bằng cách thủ công trong thời gian đầu không? Nếu được, nó có thể dời lại.
Những thứ nên giữ dù là bản đầu
Một số việc rẻ khi làm sớm và đắt khi làm muộn:
- Cấu trúc dữ liệu đúng, vì sửa dữ liệu sau khi đã nhập nhiều rất khó
- Phân quyền theo vai trò
- Sao lưu và khả năng khôi phục
- Nhật ký thao tác với dữ liệu quan trọng
- Khả năng nhập dữ liệu từ Excel hiện có
Đo bản đầu như thế nào
Trước khi bắt đầu, hãy thống nhất vài dấu hiệu thành công bằng lời, không cần con số. Ví dụ: nhân viên kho nhập xuất trên phần mềm thay vì sổ tay, kế toán không phải gõ lại số liệu, chủ doanh nghiệp xem được tồn kho mà không cần gọi hỏi. Sau một thời gian dùng thật, thu thập phản hồi và quyết định giai đoạn tiếp theo dựa trên điều người dùng cần thật, không phải điều ta đoán.
Làm gì sau bản đầu tiên
MVP chỉ là điểm bắt đầu. Sau khi dùng thật, bạn sẽ thấy tính năng nào hay dùng, chỗ nào vướng, ý nào ban đầu tưởng quan trọng hóa ra không cần. Từ đó lên kế hoạch mở rộng theo từng bước nhỏ. Cách chia mốc và nghiệm thu được trình bày trong giao phần mềm theo giai đoạn.
Khi nào cách làm MVP không phù hợp
Cần thành thật: không phải dự án nào cũng nên chia nhỏ.
- Hệ thống buộc phải đầy đủ ngay ngày đầu vì lý do pháp lý hoặc quy định, ví dụ phải có đủ nghiệp vụ mới hợp lệ.
- Phần mềm thay thế hoàn toàn một hệ thống cũ không thể chạy song song, nên phải chuyển một lần.
- Nhu cầu rất phổ thông, đã có phần mềm đóng gói đáp ứng, khi đó mua có thể tiết kiệm hơn.
- Doanh nghiệp chưa chốt quy trình. MVP không thay thế được việc thống nhất cách làm việc.
Với những trường hợp này, vẫn có thể chia giai đoạn nội bộ, nhưng bản đầu có thể lớn hơn bạn nghĩ.
Bước tiếp theo
Nếu bạn đang cân nhắc bản đầu cho phần mềm của mình, hãy liệt kê chỗ đau nhất và ba nhóm "phải có", "nên có", "để sau", rồi trao đổi với chúng tôi. Xem cách chúng tôi làm tại trang viết phần mềm theo yêu cầu cho doanh nghiệp. Nếu bản đầu thiên về quản lý đơn hàng, kho hay nhân sự, bạn có thể xem phần mềm quản lý theo yêu cầu.
