Một đội chuẩn bị làm cổng khách hàng cho dịch vụ B2B. Product muốn thử luồng gửi yêu cầu, delivery cần biết trạng thái xử lý, còn kỹ thuật hỏi có phải kết nối CRM và phân quyền ngay không. Nếu gọi mọi thứ là MVP, đội dễ viết code trước khi chốt câu hỏi cần trả lời.
Prototype kiểm tra cách người dùng hiểu và thao tác. Sản phẩm chạy thật kiểm tra quy trình với dữ liệu, quyền truy cập và các hệ thống liên quan.
Prototype dùng để kiểm tra cách hiểu và thao tác
Prototype thường là tập hợp màn hình có thể bấm qua mà chưa xử lý dữ liệu thật. Đội dùng nó để kiểm tra tên gọi, thứ tự bước, nội dung biểu mẫu và cấu trúc điều hướng.
Ví dụ, với cổng khách hàng, prototype đủ để hỏi khách có tìm thấy nơi gửi yêu cầu hay không, họ hiểu các trạng thái thế nào và thông tin nào khiến họ yên tâm chờ xử lý. Người thử không cần đăng nhập thật, dữ liệu không cần ghi vào CRM và thông báo chưa phải gửi ra ngoài.
Prototype hữu ích khi cấu trúc giao diện còn thay đổi nhiều. Product có thể sửa sau một buổi thử mà không phải đổi cơ sở dữ liệu hoặc API.
Prototype không chứng minh được quy trình sẽ chạy ổn. Nút "Gửi yêu cầu" có thể hợp lý, nhưng chưa cho biết ai nhận việc, quyền xem hồ sơ được kiểm tra thế nào hoặc hệ thống phản ứng khi CRM mất kết nối.
Sản phẩm chạy thật dùng để kiểm tra điều kiện vận hành
Đội cần phiên bản hoạt động khi câu hỏi nằm ở dữ liệu, tích hợp hoặc hành vi thực tế. Người dùng phải hoàn thành công việc và nhận kết quả đủ tin cậy để tiếp tục quy trình.
Phiên bản đầu có thể chỉ gồm một vai trò, một luồng chính và một tích hợp bắt buộc. Phần đã làm phải hoạt động đúng trong phạm vi công bố. Nếu biểu mẫu tạo ticket, ticket phải được lưu, có trạng thái, có người phụ trách và không lộ sang tài khoản khác.
Bài cách cắt phạm vi sản phẩm mà vẫn kiểm chứng được nhu cầu trình bày cách giữ phiên bản đầu đủ nhỏ. Khi sản phẩm có dữ liệu nội bộ, đội cũng cần chốt vai trò và quyền truy cập trước khi dev hoàn thiện luồng.
Chọn prototype hay sản phẩm chạy thật
Nên làm prototype khi
- Cần kiểm tra người dùng có hiểu đề xuất và luồng thao tác hay không.
- Nội dung, thứ tự bước hoặc cấu trúc màn hình còn thay đổi nhiều.
- Người thử chưa cần lưu dữ liệu hay nhận kết quả để làm việc tiếp.
- Đội cần loại bỏ một hướng thiết kế trước khi viết code.
Nên xây sản phẩm chạy thật khi
- Cần quan sát hành vi sử dụng lặp lại trong công việc thực tế.
- Kết quả phụ thuộc vào dữ liệu thật, API, thông báo hoặc quyền truy cập.
- Người dùng cần hoàn thành một đầu việc và tin vào trạng thái hệ thống.
- Rủi ro chính nằm ở ngoại lệ, bảo mật, hiệu năng hoặc bàn giao giữa các vai trò.
Một luồng có thể đi qua cả hai mức
Hai lựa chọn có thể nối tiếp nhau. Đội làm prototype để sửa luồng, sau đó xây một lát cắt hoạt động cho phần đã đủ rõ. Không nên đưa prototype cho người dùng như sản phẩm hoặc xây đầy đủ hạ tầng cho luồng chưa qua kiểm tra cơ bản.
Với cổng khách hàng, vòng đầu mô phỏng việc gửi yêu cầu và xem tiến độ. Sau khi khách hiểu cách dùng, vòng tiếp theo chỉ xây đăng nhập, gửi yêu cầu, tạo ticket và thông báo cho delivery. Tìm kiếm nâng cao và báo cáo để sau.
Quy trình chọn mức đầu tư kỹ thuật
1. Viết câu hỏi cần trả lời
Product ghi một câu có thể kiểm tra, chẳng hạn: khách có tự gửi yêu cầu đúng nhóm mà không cần nhắn Zalo cho account hay không.
2. Xác định bằng chứng cần thu
Nếu chỉ cần quan sát cách hiểu và thao tác, dùng prototype. Nếu cần đo việc hoàn thành với dữ liệu thật, phải có phiên bản hoạt động.
3. Liệt kê phần bắt buộc phải chạy thật
Đội tách rõ đăng nhập, lưu dữ liệu, phân quyền, tích hợp, thông báo và xử lý lỗi. Chỉ giữ phần liên quan trực tiếp đến câu hỏi.
4. Đặt điều kiện chuyển giai đoạn
Chốt trước kết quả nào dẫn đến sửa prototype, dừng ý tưởng hoặc chuyển sang phát triển. Không dùng cảm giác "người thử có vẻ thích" làm tiêu chí duy nhất.
Đừng dùng prototype để kiểm tra sai loại rủi ro
Prototype không trả lời được hệ thống có đồng bộ đúng trạng thái đơn hàng hay sales có cập nhật dữ liệu đầy đủ hay không. Nếu quyết định phụ thuộc vào các yếu tố đó, môi trường thử phải có dữ liệu và trách nhiệm thật.
Đừng xây đăng nhập, cơ sở dữ liệu và tích hợp chỉ để biết người dùng có hiểu nút nào cần bấm. Bài kiểm chứng nhu cầu bằng dịch vụ thủ công trước khi viết code phù hợp khi đội cần kiểm tra kết quả kinh doanh trước khi đầu tư hệ thống.
Đầu ra cần có trước khi bắt đầu
Quyết định cần ghi rõ câu hỏi kiểm chứng, nhóm người thử, bằng chứng cần thu, phạm vi phải hoạt động thật và điều kiện chuyển giai đoạn.
Nếu chọn prototype, đầu ra là kịch bản thử và điểm cần quan sát. Nếu chọn sản phẩm chạy thật, đội cần thêm dữ liệu, trạng thái, quyền truy cập, ngoại lệ, tiêu chí nghiệm thu và người chịu trách nhiệm.
Đội có thể tham khảo Product Development để chốt câu hỏi kiểm chứng, phạm vi xây và tiêu chí bàn giao.