Team bạn vừa bổ sung một tính năng mới sau 2 tháng làm việc vất vả. Trái ngược với kì vọng của team, rating sản phẩm “cắm đầu” tụt dốc không phanh. Mọi người đổ lỗi cho nhau.
– Bọn em đã phát triển tính năng này giống sàn S của nước ngoài như anh bảo! Anh còn duyệt trước khi deploy mà!
– Thế tại sao người dùng phàn nàn dữ vậy?
Cách đó không xa, một cuộc tranh cãi nảy lửa đang diễn ra phía sau quầy bar của một nhà hàng:
– Bọn em đã làm đúng công thức anh mang từ Singapore về! Anh ăn còn khen ngon mà!
– Thế tại sao khách lại chê món này?
Hai câu chuyện ở hai bối cảnh khác nhau, một bên là team product, còn bên là nhà bếp. Vậy có điểm chung nào ở đây không? – Có, đó là ngay từ đầu, họ đã không có một requirement phù hợp!
Đây là hiện tượng phổ biến trong giới phát triển sản phẩm. Thay vì xây dựng requirement xuất phát từ nền tảng của doanh nghiệp & thị trường, một số stakeholder thường chọn cách sao chép giải pháp, mô hình bên ngoài. Và thông thường, kết quả họ nhận lại đều không được như mong đợi.
Có nhiều lí do để các stakeholder chọn đi tới solution trước thay vì chuẩn bị requirement cẩn thận: Giải pháp sẵn có, nguồn nhân lực hạn chế, áp lực thời gian, thị trường biến động và đối thủ cạnh tranh gay gắt.
Tuy nhiên, ngọn nguồn của mọi vấn đề trên đều dẫn về một lí do: Họ đã chọn cách research không phù hợp để có một requirement.
Trong bài viết này, OLabs sẽ mổ xẻ và gợi ý những phương pháp có thể giúp xây dựng một requirement phù hợp. Và để dễ tiếp cận hơn, bài viết này sẽ sử dụng những ví dụ liên hệ tới nhà bếp trong bộ phim Ratatouille. – Nơi những con người có cá tính trái ngược hợp tác với nhau để nâng “rating” cho nhà hàng!
Requirement có thể hiểu đơn giản là những mô tả giúp sản phẩm đi đúng định hướng. Đối với lĩnh vực phát triển sản phẩm số / chuyển đổi số hiện nay, requirement hầu như đều xoay quanh nhu cầu người dùng.
Để hiểu về tầm quan trọng của requirement, ta có một ví dụ gần gũi: Một công thức nấu ăn luôn có danh sách nguyên liệu chuẩn bị nằm trên đầu. Để làm món trứng rán, ta cần có trứng gà, gia vị và dầu ăn. Cho dù có thay đổi cách chế biến thế nào, thì ta vẫn cần đảm bảo có những nguyên liệu trên để rán trứng thành công.
Trong một bức tranh rộng hơn, khi liên hệ đội phát triển sản phẩm với một nhà bếp bận rộn. Mỗi cá nhân đều có một cách giải quyết vấn đề khác nhau – cũng như mỗi đầu bếp đều có cách chế biến theo khẩu vị của riêng họ.
Công thức nấu ăn sẽ là thứ giúp các đầu bếp thống nhất cách làm việc. Cũng giống như requirement sẽ là một mục tiêu chung để cả nhóm phát triển sản phẩm nhắm tới. Câu hỏi được đặt ra tiếp theo là: OK, tôi biết requirement quan trọng rồi, vậy có thể lấy nó lúc nào?
Như đã đề cập trong phần mở bài, ta hiếm khi được thấy team phát triển sản phẩm hoàn thiện requirement vì nhiều lí do. Mà sau cùng tất cả đều xoay quanh việc không có phương pháp research phù hợp.
Các PM không thể dành quá nhiều thời gian trao đổi với khách hàng hay stakeholder. Một survey có thể tốn kém mà không mang lại bất kì giá trị thực tiễn nào.
Sơ đồ dưới đây được tổng hợp từ kinh nghiệm của OLabs về những thời điểm phù hợp để bắt đầu research xây dựng requirement:
Đây là thời điểm phù hợp và quan trọng nhất để thực hiện các research. Thông thường trước khi dự án bắt đầu, ta sẽ có nhiều thời gian và nguồn lực để dự đoán, cân nhắc mọi yếu tố.
Trong nấu nướng, giai đoạn này tương tự như việc tìm hiểu, liệt kê những nguyên liệu, cách nêm nếm phù hợp. Một nhà bếp xịn thậm chí còn cân đo đong đếm từng chiếc bánh mì được nhập vào kho.
Tất nhiên không ai có thể tiên đoán chính xác 100% những gì có thể xảy ra ở các giai đoạn sau. Sẽ có rất nhiều bài học khiến ta ngã ngửa dù đã tính toán mọi thứ. Nhưng hãy coi chúng là những bất ngờ thú vị trong công việc!
Hãy nhớ rằng đôi khi các đầu bếp vĩ đại nhất thế giới cũng phải để sự bất ngờ dẫn dắt khi xây dựng một nhà hàng chuẩn Michelin!
Giai đoạn hoàn thiện thiết kế hệ thống và prototype là một bước thích hợp để research tìm vấn đề (VD: Heuristic Evaluation, Usability Testing) trước khi tiến hành develop.
Một món ăn được sơ chế không tốt sẽ làm lãng phí tất cả các bước trước và sau. Để có thể đánh giá chất lượng món ăn ở gian đoạn này, người đầu bếp cần phải có chuyên môn và kinh nghiệm dày dặn.
Đôi khi dù ta có xin feedback từ các đầu bếp khác, ý kiến họ nhận về được sẽ không thể chuẩn xác bởi những thiên kiến đã có sẵn.
Trong nhóm phát triển sản phẩm, nếu chỉ đánh giá design dựa trên cảm quan của đồng nghiệp,tTa cần chấp nhận kết quả sẽ không thể chính xác. Bởi mọi người đều có quan điểm riêng của mình về “độ ngon” của một sản phẩm.
Vai trò của PM lúc này là làm sao để chốt lại design và vạch ra kế hoạch làm việc cho developer. Bởi chỉ một sai sót nhỏ lúc này sẽ phải trả giá bằng rất nhiều thời gian và công sức của tập thể!
Một món ăn gần hoàn thiện sẽ khó chỉnh sửa. Lúc này những gì đầu bếp có thể làm là nêm nếm những gia vị cuối cùng. Khách hàng đang rất nóng lòng chờ món ăn này!
Trong phát triển sản phẩm, dù đây là giai đoạn nước rút, ta vẫn sẽ có những phương pháp research hiệu quả! Đây là thời điểm việc research phải diễn ra nhanh chóng, mục tiêu của research cũng cần rút gọn tránh kéo dài thời gian phát triển.
Lưu ý rằng, trong trường hợp xấu nhất, người quản lý sẽ cần đưa ra quyết định chỉnh sửa lại sản phẩm. Điều này giống như việc bếp trưởng cần đưa ra quyết định liệu có thể phục vụ một món ăn không đạt yêu cầu của mình hay không!
Đây là giai đoạn cuối cùng trong một sprint. Mọi phản hồi sau giây phút deploy sẽ quyết định cho công sức của cả nhóm phát triển sản phẩm.
Với vai trò là người quản lý hay nghiên cứu sản phẩm, công việc của bạn chưa dừng lại. Cũng như là một bếp trưởng, bạn cần lắng nghe phản hồi của thực khách. Những phản hồi này sẽ là yếu tố then chốt dẫn tới quyết định họ có quay lại nhà hàng hay không. Và cho dù phản hồi là tích cực hay tiêu cực, thì nếu vẫn sẽ tác động tới lần phục vụ món tiếp theo.
Research ở thời điểm này quan trọng không kém bước xây dựng requirement. Đây cũng là các dữ liệu định lượng trở nên rõ ràng hơn bao giờ hết. Kết quả của research sẽ ảnh hưởng trực tiếp tới requirement ở giai đoạn tiếp theo của sản phẩm.
Tóm tắt lại bài viết:
1. Requirement rất quan trọng, research có thể giúp tìm ra requirement
2. Thời điểm research phù hợp:
– Trước khi xây dựng requirement
– Sau khi thiết kế
– Trước khi deploy
và Sau khi deploy
Không có một người đầu bếp vĩ đại nào có thể xây dựng nhà hàng tiêu chuẩn Michelin của mình trong một ngày. Dù anh ta hay cô ta có gặp may với một món signature, thì cũng không thể đảm bảo rằng nhà hàng sẽ duy trì được vị thế của mình nếu nhưng không liên tục nghiên cứu và đổi mới.
Cho dù bạn là bộ phận nào trong nhóm phát triển sản phẩm. Hãy đặt vị trí của mình vào trong vai trò của một đầu bếp và tự hỏi rằng: Món ăn này cần phải làm gì để thu hút khách hàng?
Bài viết dựa nhiều vào những bài học tới từ quá trình học tập và làm việc của các thành viên trong Onteractive và OLabs. Vì thế, sẽ không có bài học nào trong bài viết là đúng tuyệt đối và cứ áp dụng là bạn sẽ cầm chắc chiến thắng! Là một thành viên của nhóm phát triển sản phẩm, hãy nhớ rằng: không ai hiểu rõ bản chất sản phẩm hơn chính bạn!
Phần 2 của bài viết “Cách lựa chọn phương pháp phù hợp” sẽ ra mắt sớm trên blog của OLabs.
Cập nhật những thông tin mới nhất về UX mỗi ngày.
