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.1
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 MoSCoW2
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 20023. 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 được4.
- 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òn giúp cả đội đảm bảo xây dựng được Mininum Viable Product (MVP) hoặc Minimum Marketable Features (MMF)5. Đồng thời, MoSCoW 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)6.
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. Bên cạnh đó, 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).78
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:
- 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:
Bạn có thể tham khảo thêm biểu mẫu tính điểm RICE tại đường dẫn này11.
Ư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.