PoC hay MVP: Cần thử điều gì trước?

PoC là viết tắt của Proof of Concept, thường được gọi là kiểm chứng tính khả thi. Hiểu đơn giản, đây là một thử nghiệm giới hạn để xem giải pháp dự định có thực hiện được hay không. Trong dự án phần mềm, PoC thường tập trung vào một điểm kỹ thuật còn chưa chắc, thay vì xây cả sản phẩm.

Ví dụ, giả sử doanh nghiệp muốn khách tự đặt lịch trên website, trong khi lịch hẹn vẫn được quản lý bằng một hệ thống cũ. Trước khi làm website, nhóm phát triển cần biết có lấy được thông tin giờ trống từ hệ thống đó không. PoC có thể chỉ thử việc kết nối, đọc lịch và cập nhật khi giờ trống thay đổi, chưa cần xây đầy đủ màn hình hay báo cáo. Đây là ví dụ giả định để minh họa.

Kết quả PoC cần nêu rõ đã thử được gì và còn giới hạn nào. Đọc được lịch không đồng nghĩa với giữ được chỗ khi hai người cùng chọn một giờ. Kết nối thành công trong môi trường thử cũng chưa xác nhận đã có đủ quyền và điều kiện để dùng thật. Những điểm chưa kiểm tra phải được ghi lại để tránh hiểu rằng toàn bộ hệ thống đã sẵn sàng.

MVP là viết tắt của Minimum Viable Product, thường được gọi là sản phẩm khả dụng tối thiểu. Đây là phiên bản có phạm vi vừa đủ để đưa đến người dùng, quan sát cách họ sử dụng và tìm hiểu sản phẩm có đáp ứng nhu cầu hay không. Điểm quan trọng là học được từ hành vi thực tế, thay vì chỉ hỏi người dùng có thích ý tưởng đó không.

Với ví dụ đặt lịch, doanh nghiệp có thể chỉ mở cho một dịch vụ và một nhóm khách. Khách chọn giờ, gửi thông tin và nhận thông báo đã xác nhận hay cần chờ. Qua đó, doanh nghiệp theo dõi khách có hoàn tất việc đặt hẹn không, vướng ở bước nào và còn phải gọi điện vì lý do gì. Những thông tin này giúp quyết định nên cải thiện hay mở rộng dịch vụ.

“Tối thiểu” không có nghĩa là cắt chức năng đến mức người dùng không làm được việc cần thử. Nếu mục tiêu là xem khách có tự hoàn tất đặt lịch hay không, chỉ có trang giới thiệu và nút “đặt ngay” chưa đủ để trả lời. Tuy nhiên, một số bước phía sau có thể do nhân viên làm thủ công, miễn là kết quả được giải thích đúng và thông tin người dùng được xử lý phù hợp.

Phạm vi hẹp vẫn cần đáp ứng các điều kiện sử dụng đã cam kết, gồm cách bảo vệ dữ liệu, xử lý khi có lỗi và hỗ trợ người tham gia. Nếu mỗi khách đều cần nhân viên làm thay nhiều bước, hãy ghi nhận phần việc đó. Việc khách đặt được lịch chưa chứng minh hệ thống có thể phục vụ nhiều người hơn với cùng cách vận hành.

Hãy chọn theo điều chưa biết có thể khiến dự án đi sai hướng. Nếu chưa chắc giải pháp có kết nối, xử lý hoặc đáp ứng điều kiện kỹ thuật cần thiết hay không, PoC là cách để kiểm tra phần đó. Nếu câu hỏi chính là người dùng có cần, có sử dụng và có nhận được giá trị từ cách làm mới không, MVP phù hợp hơn để thu thập phản hồi thực tế.

Trong ví dụ đặt lịch, lấy được giờ trống từ lịch cũ mới trả lời câu hỏi kỹ thuật. Nó chưa cho biết khách sẽ chọn đặt trên web thay vì gọi điện. Ngược lại, nếu nhân viên tự kiểm tra lịch và hỗ trợ từng khách hoàn tất, kết quả có thể giúp tìm hiểu nhu cầu nhưng chưa xác nhận việc kết nối tự động đã làm được.

Không phải dự án nào cũng cần làm đủ PoC rồi mới đến MVP. Nếu công nghệ đã quen thuộc và rủi ro chính nằm ở nhu cầu sử dụng, có thể không cần một PoC riêng. Nếu việc kết nối là điều kiện bắt buộc nhưng chưa biết có thực hiện được không, nên kiểm tra sớm trước khi đầu tư vào nhiều chức năng phụ thuộc vào nó.

Trước khi bắt đầu, hai bên cần viết rõ câu hỏi cần trả lời, phạm vi làm thử, thời gian, ngân sách và người xác nhận kết quả. Với PoC đặt lịch, phải thống nhất chỉ thử đọc giờ trống hay thử cả giữ chỗ. Với MVP, cần xác định nhóm khách nào sẽ tham gia và việc đặt hẹn được coi là hoàn tất ở bước nào.

Cũng cần chuẩn bị dữ liệu, quyền truy cập và người hỗ trợ. Nếu không được phép dùng lịch thật, phải ghi rõ dữ liệu thử khác thực tế ở đâu và điều gì chưa thể kết luận. Kết quả chỉ có ý nghĩa khi người ra quyết định biết nó được tạo ra trong điều kiện nào.

Để đối tác đề xuất phạm vi thử phù hợp, doanh nghiệp cần giải thích công việc đang làm, ai sẽ sử dụng và những hệ thống phải kết nối. Nếu chưa biết nên tập hợp thông tin từ đâu, bài Cần chuẩn bị gì trước một dự án phần mềm? sẽ giúp bạn chuẩn bị nội dung trao đổi, tránh bắt đầu từ một danh sách chức năng chưa rõ mục đích.

Ngoài việc kết nối có hoạt động hay không, doanh nghiệp có thể cần biết lịch trống được cập nhật nhanh đến mức nào hoặc điều gì xảy ra khi kết nối bị gián đoạn. Những điều kiện này phải được thống nhất cùng cách đo trước khi thử. Bài Yêu cầu phi chức năng là gì? giải thích cách xác định các yêu cầu về tốc độ, độ ổn định và điều kiện vận hành bên cạnh chức năng.

Khi nhận kết quả, hãy quay lại câu hỏi ban đầu. Báo cáo PoC cần chỉ ra phần nào làm được, phần nào chưa được và còn phụ thuộc vào điều kiện gì. Với MVP đặt lịch, cần xem người dùng có hoàn tất không, gặp khó khăn ở đâu và nhân viên phải hỗ trợ bao nhiêu. Một nhận xét “demo chạy tốt” hoặc “khách thấy dễ dùng” chưa đủ thay cho những thông tin này.

Nếu kết nối chưa đáp ứng, nhóm cần tìm cách khác hoặc thu hẹp phần phụ thuộc vào nó. Nếu khách bỏ dở vì không có khung giờ phù hợp, hãy xem lại cách cung cấp dịch vụ trước khi kết luận giao diện có vấn đề. Nếu khách hoàn tất nhưng nhân viên phải làm thay nhiều bước, cần tính lại công vận hành trước khi mở rộng.

Bước tiếp theo có thể là tiếp tục, sửa rồi thử lại hoặc dừng phương án hiện tại. Hãy ghi rõ lý do và phần việc cần làm, thay vì coi thử nghiệm “đạt” là đủ để duyệt cả dự án.

Khi quyết định đầu tư tiếp, doanh nghiệp còn cần cân nhắc ý tưởng này với các nhu cầu CNTT khác đang chờ xử lý. Bài Lộ trình CNTT: Nên làm dự án nào trước? giúp bạn xem xét thứ tự triển khai theo mức độ cần thiết và điều kiện thực hiện, thay vì ưu tiên chỉ vì vừa có kết quả thử tốt.

Trước khi phát triển rộng hơn, cần kiểm tra phần nào có thể dùng tiếp, phần nào phải xây lại, còn thiếu kiểm thử gì và ai sẽ vận hành. PoC không mặc nhiên là mã nguồn sẵn sàng dùng thật; MVP cũng chưa chứng minh đã đáp ứng quy mô lớn hơn phạm vi được thử. Việc tiếp tục đầu tư phải dựa trên giới hạn đã biết và phần chuẩn bị còn cần thiết.

Nếu bạn đang có một ý tưởng phần mềm nhưng chưa biết nên thử phần nào trước, có thể trao đổi với Fenix từ công việc muốn cải thiện và điều còn băn khoăn. Xác định đúng câu hỏi sẽ giúp chọn PoC, MVP hoặc cách kiểm tra phù hợp hơn với nhu cầu thực tế.

Trao đổi nhu cầu với Fenix