Các bạn đã từng nghe thấy MVP ở bất kỳ đâu chưa ? Chắc hẳn nếu các bạn là một người chơi thể thao hay là một game thủ thì các bạn đã nghe đến cụm từ này rồi MVP - Most Valuable Player nhưng thực sự tôi không muốn đề cập đến nó trong bài viết này. Trong lĩnh vực phần mềm nó lại là một khái niệm hoàn toàn khác MVP - Minimum Viable Product.
Chúng ta không tìm kiếm cái tốt nhất mà chúng ta tìm kiếm cái tối giản nhất.
Khái niệm MVP có thể hiểu là một phần mềm hay một hệ thống có vừa đủ các chức năng có thể bàn giao cho khách hàng và đem lại các giá trị cho họ. ( Đấy cũng là lí do mà một số người lại bị nhầm MVP là Minimal VALUABLE Product )
Đây thực ra là một ý tưởng cho việc bàn giao sản phẩm một cách nhanh chóng. Sau đó sẽ tiến hành đánh giá chặt chẽ các ý kiến từ phía khách hàng ( bao gồm cả đánh giá trực tiếp cũng như gián tiếp qua việc giám sát sử dụng ) để tiếp tục tiến hành phát triển, hoàn thiện thêm các chức năng cũng như sản phẩm theo đúng những gì khách hàng thực sự mong muốn.
Mục tiêu của việc này là giữ cho những phán đoán để phát triển phần mềm nằm ngoài Product Management & Design. Thay vào đó, chính khách hàng nói cho chúng ta biết chính xác những gì cần nâng cao ở các chức năng mà họ mong muốn.
Đây chính là cách để chúng ta không phí thời gian cho những chức năng mà khách hàng không cần thiết cũng như không sử dụng.
Vậy như nào là Minimal đối với một sản phẩm ?
Đây thực sự là một câu hỏi gây nhiều tranh cãi và luôn luôn là vấn đề trong các buổi thảo luận giữa các bên.
Lập trình viên thì luôn muốn làm ít nhất có thể, đồng nghĩa với việc ít rủi ro.
Product Owners thì luôn muốn cho vào thật nhiều các chức năng dựa trên những gì họ cho là cần thiết (hoặc ít nhất là họ nghĩ vậy) thông qua những nhận xét của đại đa số người dùng.
Sales và đội ngũ hỗ trợ ưu tiên bàn giao những thứ có vẻ là đã hoàn thành rồi hoặc những thứ phát triển được một nửa. Sau đó, họ sẽ là người đi giải thích với khách hàng tại sao mà chúng ta lại chọn những thứ đó để bàn giao mặc dù biết là yêu cầu cần nhiều hơn thế.
Về chất lượng, với ý tưởng này chúng ta có thể cung cấp những giá trị quý giá ban đầu của sản phẩm cho khách hàng nhưng sâu xa hơn nó giúp chúng ta cân bằng giữa việc bàn giao sản phẩm một cách vừa đủ và cung cấp những giá trị cần thiết cho khách hàng. Đồng thời nó cũng sẽ tạo ra những khoảng thời gian cho chúng ta nghiên cứu là sẽ phát triển thêm những chức năng nào cần thiết.
Vậy để tìm được Minimal đối với sản phẩm để bàn giao, Tester phải đóng vai trò như những khách hàng nội bộ vậy, thực sự nắm được và hiểu được hệ thống chức năng trong hệ thống, có kiến thức đánh giá để giúp cho đội phát triển đưa ra các quyết định quan trọng và phức tạp.
Chuẩn bị sẵn sàng để ghi nhận các ý kiến phản hồi từ phía người dùng.
Ok, bây giờ bạn đã xác định được Minimum Viable Product và đã cùng đội phát triển bàn giao xong sản phẩm cho khách hàng. Vậy là công việc đã hoàn thành, đúng không ? Thực sự là không phải vậy.
MVP chỉ như là một bài thực hành hay một loại hình bàn giao để đội phát triển có thể thu thập được các ý kiển phản hồi và tiếp tục phát triển sản phẩm của mình. Tuy nhiên, phải chắc chắn rằng sản phẩm sẵn sàng để có thể tiếp nhận chúng cũng như đội phát triển sẵn sàng để tiếp thu nó và tiến hành tiếp các công việc cần thiết.
Các ý kiến phản hồi có thể đến dưới dạng các mẫu đánh giá cũng như ở các kênh khác nhau. Đơn giản nhất và gần như ngay lập tức bạn có thể tiếp nhận được các ý kiến phản hồi khi người dùng trải nghiệm các chức năng mới. Cần phân biệt rõ người dùng nào đánh giá chức năng đó theo kiểu họ chỉ lướt qua và đưa ra ý kiến một cách nhanh chóng (họ chỉ click-click chuột và hoàn thành) với những người thường xuyên sử dụng chức năng đó như một phần công việc của họ, đưa ra những ý kiến đánh giá tâm huyết, tỉ mỉ.
Ý kiến phản hồi có thể thu thập bằng việc bạn hỏi khách hàng một cách trực tiếp xem họ nghĩ gì về sản phẩm hay qua những cách gián tiếp như đo lường sản phẩm thông qua các hoạt động của người dùng hoặc phân tích các log được ghi nhận trên hệ thống.
Thông thường chúng ta cần sử dụng cả 2 cách này.
Chuẩn bị cho người dùng gửi phản hồi.
Một điểm quan trọng mà bạn nên nhớ rằng đó là người dùng không phải là người làm việc cho bạn - Đó luôn luôn là một con đường vòng.
Bạn không thể kỳ vọng một cách đơn giản là họ sẽ làm và trả lời các emails của bạn khi bạn yêu cầu họ cung cấp các ý kiến thông qua các chức năng của hệ thống.
Một số người dùng họ sẽ rất vui vẻ để đưa ra các ý kiến phản hồi, các bình luận hoặc thậm chí là cả những đoạn văn để nói về các cảm xúc cũng như các suy nghĩ của họ về sản phẩm. Tuy nhiên phần lớn người dùng thì hoàn toàn ngược lại, họ thường sẽ không mấy quan tâm đến mục gửi ý kiến phản hồi này.
Một cách hiệu quả để lấy được các ý kiến phản hồi đó là cho người dùng biết tầm quan trọng trong các ý kiến của họ đóng góp, đồng thời gắn liền việc lấy ý kiến phản hồi này như một phần của chức năng hệ thống, người dùng muốn sử dụng thì phải hoàn thành nó.
Cuối cùng hãy làm cho việc này càng mang tính chất cá nhân nhiều càng tốt (ví dụ như sử dụng tên của người dùng, nghề nghiệp của họ ...) để họ có thể hiểu là mình đang quan tâm và hỏi ý kiến họ thay vì hỏi rất nhiều những người khác.
Nâng cao chất lượng để khách hàng có thể hài lòng.
Chất lượng của một sản phẩm không phải chỉ là việc số bug của sản phẩm đó hay thời gian phản hồi của hệ thống mà nó còn chính là sự hài lòng của khách hàng (Customer Happiness). Nói như vậy thì khá là bao chùm và mông lung, tuy nhiên điểm mấu chốt chính là lắng nghe, thấu hiểu ý kiến của khách hàng để có thể hiểu họ thực sự muốn gì, từ đó để nâng cao chất lượng sản phẩm mà mình đã tạo ra.
Link tham khảo: https://qablog.practitest.com/finding-your-mvp/
