Sắp xếp thứ tự ưu tiên trong Phát triển Sản phẩm – Product Prioritization Frameworks

Nếu bạn đã từng đi phỏng vấn cho vị trí Product Owner/Product Manager, chắc hẳn bạn sẽ không ít lần được hỏi một câu hỏi quen thuộc: “Làm thế nào để sắp xếp thứ tự ưu tiên các tính năng cần phát triển cho sản phẩm?”. Câu hỏi nghe có vẻ đơn giản nhưng đánh đố không ít ứng viên. Không ít PO/PM sẽ làm theo bản năng, nghĩ cái nào quan trọng thì làm cái đó trước, hoặc dựa vào một số yếu tố thường gặp (ví dụ như ảnh hưởng đến job-to-be-done của người dùng, hoặc ảnh hưởng đến việc vận hành của công ty) để sắp xếp độ ưu tiên cho các tính năng hoặc nhiệm vụ. Nhưng cũng có những trường hợp mà bản thân kinh nghiệm của ứng viên chưa đủ bao quát, sẽ rất dễ dẫn đến việc bị người phỏng vấn “bắt bẻ”. Vậy với vai trò là một ứng viên đi phỏng vấn, nếu bạn nắm chắc một hoặc hai kỹ thuật/phương pháp sắp xếp thứ tự ưu tiên trong phát triển sản phẩm (product prioritization frameworks), thì câu hỏi này sẽ không còn là vấn đề đối với bạn.

Ví dụ trên chỉ là yếu tố rất bé nhỏ của việc vì sao nên nắm các phương pháp sắp xếp thứ tự ưu tiên sản phẩm (vì mình không khuyến khích bạn học lý thuyết chỉ để đi “bán bản thân”, mà phải thực làm và thực sự đạt được kết quả trong công việc của bạn). Vậy thì sâu xa hơn tại sao chúng ta cần các phương pháp sắp xếp thứ tự ưu tiên sản phẩm và một số kỹ thuật thường được sử dụng là gì, chúng ta hãy cùng tìm hiểu trong bài viết này nhé.

Phương pháp sắp xếp thứ tự ưu tiên sản phẩm là gì và tại sao lại cần chúng?

Như Lemon’s Tribe đã từng đề cập ở các bài viết trước trong việc xây dựng sản phẩm, hoặc quá trình thiết kế trải nghiệm người dùng (bạn có thể xem lại bài viết Làm thế nào để thiết kế trải nghiệm người dùng – UX Design?), sau khi xác định được Product vision (tầm nhìn của sản phẩm) và Product strategy (chiến lược của sản phẩm), thì bước tiếp theo chính là xây dựng Product roadmap (lộ trình sản phẩm) và Product backlog (danh sách tính năng cần phải thực hiện). Và bạn biết đấy, bạn có thể viết ra rất rất nhiều stories hay epics trong backlog của mình, nhưng chắc chắn rằng, bạn không thể thực hiện tất cả trong một thời gian ngắn, hoặc nói đơn giản hơn sản phẩm của bạn không thể chờ có đầy đủ các tính năng trong backlog mới được ra đường (vì còn ảnh hưởng đến việc kinh doanh của công ty). Vậy để xác định nên làm tính năng nào trước, tính năng nào sau thì cần phải có những phương pháp nhằm xác định được thứ tự ưu tiên phát triển của các tính năng. Các phương pháp đó sẽ bao gồm các tiêu chí được đồng thuận giữa các đội nhóm liên quan, để đánh giá mức độ quan trọng và khẩn thiết của các tính năng có trong danh sách chờ. Chúng là những công cụ hữu ích giúp đội phát triển sản phẩm đi theo đúng chiến lược, tránh được những thiên kiến của bất kỳ cá nhân nào, tối ưu nguồn lực và giúp cả đội dễ dàng giao tiếp với nhau về thứ tự ưu tiên, cũng như giải thích cho ban lãnh đạo về quyết định của mình.¹

Các mô hình/phương pháp điển hình cho việc sắp xếp thứ tự ưu tiên sản phẩm

1. Phương pháp MoSCoW²

Một trong những phương pháp phổ biến nhất được sử dụng trong việc phát triển sản phẩm chính là phương pháp MoSCoW. Phương pháp này được tạo ra bởi Dai Clegg vào năm 1994, phục vụ cho việc phát triển ứng dụng một cách nhanh chóng (Rapid Application Development – RAD), và bắt đầu được sử dụng rộng rãi từ năm 2002³. Phương pháp MoSCoW chia tính năng sản phẩm thành 4 danh mục: M – Must have, S – Should have, C- Could have, và W – Won’t have. Cụ thể như sau:

• Must have: là những tính năng (stories/epics) cần phải được thực hiện trong giới hạn thời gian nhất định để đảm bảo thành công của sản phẩm hoặc dự án. Nếu như một tính năng thuộc nhóm Must have không được thực hiện thì đồng nghĩa với việc sản phẩm đó thất bại hoặc không thể ra mắt người dùng. Từ “MUST” còn được coi là viết tắt của từ “Minimum Usable SubseT”, có nghĩa là tập hợp con các tính năng tối thiểu để người dùng có thể sử dụng được⁴.
• Should have: là những tính năng quan trọng nhưng không “cháy nhà”, có thể tìm cách làm thay thế (workaround). Ví dụ như một công ty tín dụng sẽ cần cung cấp cho nhân viên tư vấn khoản vay một ứng dụng hỗ trợ công việc tư vấn và đăng ký khoản vay cho khách hàng, trong đó cần có tính năng tính toán số tiền phải trả hàng tháng của khách hàng. Giả sử như có nhiều tính năng khác cần phải ưu tiên làm trước, thì người nhân viên tư vấn vẫn có thể dùng file Excel hoặc Google Sheet để tính khoản vay và tư vấn cho khách hàng trong lúc chờ tính năng được lên ứng dụng.
• Could have: là những tính năng được mong muốn đưa vào nhưng chưa cấp bách (add-on). Mình ví dụ như việc xây dựng sản phẩm cũng như xây nhà. Các tính năng Must haves sẽ được ví như vậy làm móng, đóng cọc,… làm nên căn nhà thô. Trong khi đó, các tính năng Should haves sẽ được coi như việc sơn tường, lắp cửa,…. Và các tính năng Could haves chính là việc trang trí nhà cửa cho thêm phần lung linh, theo ý muốn của chủ nhà.
• Won’t have (this time): là những yêu cầu ít cần thiết nhất tại thời điểm lên kế hoạch, và sẽ không được thực hiện trong khung thời gian đã được chỉ định trước đó (ví dụ như sprint thực hiện sắp tới). Một số biến thể sẽ thay từ “Won’t have” thành “Wish to have” hoặc “Would have”, đồng nghĩa với việc là các yêu cầu đó vẫn có thể được triển khai những không phải lúc này.

Ưu điểm của phương pháp MoSCoW là dễ dàng sử dụng và truyền đạt giữa các đội nhóm với nhau. Ngoài ra thì phương pháp này cũng giúp cả đội đảm bảo xây dựng được Mininum Viable Product (MVP) hoặc Minimum Marketable Features (MMF)⁵. Đồng thời, MoSCoW cũng là một phương pháp hữu hiệu cho Product Owner hay Product Manager xây dựng lộ trình sản phẩm (product roadmap)⁶.

Tuy nhiên, cũng có không ít ý kiến cho rằng MoSCoW không hỗ trợ được trong việc đánh giá các yêu cầu có cùng độ ưu tiên. Ngoài ra thì cũng phương pháp này cũng được cho là mơ hồ và không rõ ràng về thời điểm thực hiện đối với các tính năng thuộc nhóm Won’t have: nếu chúng không được thực hiện bây giờ, vậy thì là khi nào? Và đặc biệt đối với đội ngũ kỹ thuật thì phương pháp này cũng có hạn chế khi dễ bị sa vào việc ưu tiên cho các yêu cầu mang tính “chính trị” mà không có chỗ cho việc cải tiến kỹ thuật (chẳng hạn như tái cấu trúc hệ thống để nâng cấp chất lượng kỹ thuật của sản phẩm).⁷⁸

2. Phương pháp RICE

Phương pháp chấm điểm ưu tiên các ý tưởng phát triển sản phẩm RICE bao gồm 4 yếu tố:

• Reach: dùng để tính toán số lượng người dùng ảnh hưởng bởi tính năng hoặc số lượng sự kiện xảy ra với tính năng qua thời gian (ví dụ: số lượng giao dịch hàng tháng, hoặc số lượng đoạn hội thoại chatbot được ghi nhận hàng tháng). Điểm Reach càng cao thì tổng điểm RICE càng cao, cụ thể là¹⁰:
  • 10.0 = chạm đến phần lớn người dùng hoặc sự kiện (>=80%)
  • 6.0 = tiếp cận 50%-80% người dùng hoặc sự kiện
  • 3.0 = từ ~25% đến ~50%
  • 1.5 = từ ~5% đến ~25%
  • 0.5 = ít hơn ~5%
• Impact: giúp xác định tính năng có hỗ trợ đạt được mục tiêu kinh doanh hay giải quyết được nhu cầu của người dùng hay không. Chẳng hạn như một tính năng được tạo ra với mục đích hỗ trợ người dùng giải quyết vấn đề thay vì liên hệ nhân sự Chăm sóc khách hàng, vậy PO sẽ cần xem thử tính năng mà bạn định triển khai sẽ giúp giảm bao nhiêu ticket/giao dịch, hoặc tăng bao nhiêu tỉ lệ tự phục vụ (% self-served). Điểm Impact càng cao thì tổng điểm RICE cũng càng cao:
  • Massive = 3x
  • High = 2x
  • Medium = 1x
  • Low = 0.5x
  • Minimal = 0.25x
• Confidence: dùng để tính toán mức độ tự tin của team phát triển đối với thành công của tính năng, dựa trên ba mức – Cao (100%), Vừa (80%), và Thấp (50%). Ví dụ: nếu bạn tự tin với yếu tố Reach và Effort, nhưng không quá chắc chắn về Impact, thì Confidence của bạn sẽ là 80%.
• Effort: là yếu tố dùng để đo lường tổng thời gian mà cả đội dự án cần phải bỏ ra để hoàn thành việc phát triển tính năng. Điểm Effort càng thấp thì tổng điểm RICE càng cao.

Từ 4 yếu tố trên, ta sẽ có công thức để tính tổng điểm RICE như sau:

(Reach x Impact x Confidence) / Effort = RICE

Bạn có thể tham khảo thêm biểu mẫu tính điểm RICE tại đường dẫn này¹¹.

Ưu điểm của phương pháp RICE chính là khả năng số hoá việc sắp xếp thứ tự ưu tiên cho tính năng. Mặt khác, việc chấm điểm từng khía cạnh có trong mô hình RICE lại phức tạp, tốn nhiều thời gian, và đôi khi dễ bị cảm tính (ví dụ như với yếu tố Impact hay Confidence). Và khi có quá nhiều tính năng cần xem xét, có sự tham gia của nhiều người thì việc đánh giá cũng dễ bị mất tính thống nhất.

3. Mô hình Kano¹²

Mô hình Kano được tạo ra bởi nhà nghiên cứu – Giáo sư ngành Quản trị Chất lượng của trường Đại học Khoa học Tokyo, Noraki Kano vào năm 1984, nhằm giúp các Product Manager sắp xếp thứ tự ưu tiên phát triển các tính năng của sản phẩm dựa trên độ hài lòng và nhu cầu của người dùng. Ông đã nghiên cứu ra mô hình Kano trong quá trình tìm hiểu các yếu tố tác động đến độ hài lòng và trung thành của khách hàng đối với sản phẩm và doanh nghiệp.

Theo mô hình Kano, team phát triển sản phẩm sẽ cùng xem xét qua các tính năng có trong backlog, và đánh giá chúng dựa trên 2 khía cạnh:

• Khả năng làm hài lòng khách hàng (the potential to satisfy customers)
• Mức độ đầu tư cần bỏ ra để triển khai (Implementation investment)

Từ đó, mô hình Kano phân loại các tính năng làm hài lòng khách hàng theo 3 nhóm, sắp xếp theo khả năng làm hài lòng người dùng của chúng theo thứ tự từ thấp đến cao. Cụ thể như sau:

• Basic features: đây là nhóm các tính năng tối thiếu giúp người dùng có thể hoàn thành được hành trình của họ trên sản phẩm. Một số đội nhóm sẽ coi nhẹ các tính năng này, triển khai một cách qua loa hoặc thậm chí bỏ qua các tính năng cơ bản này sẽ dẫn đến sự khó chịu của người dùng. Tuy nhiên, các tính năng này cho dù bạn đầu tư càng nhiều thời gian để thực hiện hay cải tiến, thì ngưỡng hài lòng của người dùng sẽ chỉ có một giới hạn nhất định (như trong biểu đồ thì đường basic needs đến ngưỡng sẽ đi ngang).
• Performance features: nhóm thứ 2 là nhóm các tính năng cải thiện về khả năng thể hiện của sản phẩm, đồng thời làm tăng độ hài lòng của người dùng. Ví dụ như các ứng dụng sẽ cố gắng cải tiến các tính năng để làm giảm mức độ hao tốn dung lượng của chúng, giúp ứng dụng ít tốn bộ nhớ trên thiết bị của người dùng, đồng thời giúp ứng dụng chạy nhanh hơn. Các tính năng này cũng bắt buộc phải thực hiện để có được sự hài lòng tối thiểu của người dùng. Đường vẽ biểu thị cho Performance features là đường thẳng, cho thấy mối liên hệ tỉ lệ thuận giữa công sức bỏ ra để triển khai, nâng cấp và độ hài lòng của khách hàng.
• Delighters (hay còn gọi là Excitement features): cuối cùng là nhóm tính năng tạo yếu tố bất ngờ cho người dùng và làm cho họ cảm thấy thích thú. Các tính năng thuộc nhóm này cho dù không có thì người dùng cũng không cảm thấy khó chịu. Dẫu vậy thì khi bạn càng đầu tư công sức vào phát triển các tính năng này thì mức độ hài lòng của người dùng đối với sản phẩm của bạn cũng sẽ nhảy vọt. Ví dụ như trong imess (công cụ nhắn tin trên các thiết bị của Apple) sẽ có tính năng thêm hiệu ứng cho tin nhắn, bằng cách nhập tin nhắn > nhấn lâu vào nút gửi > và bạn có thể tuỳ ý thêm hiệu ứng cho tin nhắn. Hoặc đặc biệt hơn là bạn có thể nhấn vào một tấm hình trong mục Photos trên iPhone, hình sẽ được tự xoá bỏ background > bạn nhấn lưu vào clipboard > sau đó dán (paste) lại vào khung chat của imess > thực hiện thao tác tương tự thêm hiệu ứng cho tin nhắn văn bản > bạn sẽ thấy ngay các sticker được tạo từ hình ảnh mà bạn đã copy trước đó, cùng hiệu ứng đã chọn. Tính năng này cũng đã gây được sự hào hứng của người dúng trong quá trình sử dụng. Một ví dụ khác: ở nhóm 1, khách hàng có thể được cung cấp tính năng thanh toán có xác thực bằng mã OTP được gửi qua SMS; nhưng ở nhóm thứ 3, tính năng được bổ sung sẽ là cơ chế tự động hiển thị mã OTP trên bàn phím để người dùng không phải mở tin nhắn SMS, ghi nhớ và tự nhập lại dãy số.

Bên cạnh ba nhóm tính năng làm hài lòng khách hàng, thì còn có 2 nhóm tính năng khác mà nhóm phát triển cần tránh: nhóm tính năng Indifferent (thờ ờ) và nhóm Dissatisfaction (bất mãn).

• Indifferent features: là những tính năng mà người dùng chẳng ngó ngàng tới
• Dissactisfaction features: là những tính năng làm cho người dùng cảm thấy khó chịu, hoặc thậm chí là ức chế

Mô hình Kano tập trung chặt chẽ vào độ hài lòng của người dùng, cũng như phản ứng của người dùng đối với sản phẩm, và lấy điều này làm căn cứ để đưa ra quyết định về thứ tự ưu tiên mặc cho mô hình vẫn có sự đối chiếu giữa mức độ hài lòng của khách hàng và chi phí triển khai cần phải bỏ ra. Điều này tạo nên cả ưu điểm lẫn nhược điểm cho mô hình này. Việc chú trọng vào thúc đẩy sự hài lòng của khách hàng sẽ giúp các tính năng tạo ra mang đến trải nghiệm không những tốt, mà còn lý thú đối với người sử dụng. Bên cạnh đó, việc xem xét kỹ lưỡng và đặt nhu cầu của người dùng lên hàng đầu, cũng giúp các nhà phát triển tránh được các sản phẩm không cần thiết, hay thậm chí khó chịu cho người dùng. Đồng thời, mô hình này cũng là một công cụ hữu dụng giúp cho đội phát triển sản phẩm có thể nhanh chóng hình dung được tính năng nào bắt buộc triển khai trước, và tính năng nào đặc biệt cần nhiều đầu tư hơn để phát triển.

Tuy nhiên, mô hình này mang tính định tính cao, yêu cầu nhiều sự thu thập và phân tích dữ liệu thực tiễn về phản ứng của người dùng đối với các ý tưởng sản phẩm. Hơn thế nữa, để thực hiện các tính năng có trải nghiệm mượt mà, mang tính “Wow” thuộc nhóm Delighters đòi hỏi đội ngũ phát triển sản phẩm cũng phải dành nhiều nguồn lực đển nghiên cứu, phân tích, thử nghiệm, cải tiến hệ thống. v.v¹⁵. Và tất nhiên, nếu bối cảnh thị trường cạnh tranh hối hả thì để làm được hoàn chỉnh những điều này dần trở nên xa xỉ với nhiều doanh nghiệp.