Lemon's Tribe

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

5. Weighted Shortest Job First (WSJF)20

Weighted Shortest Job First (WSJF) – ưu tiên nhiệm vụ có thời gian hoàn thành ngắn nhất, là một mô hình sắp xếp thứ tự ưu tiên các công việc nhằm tối ưu lợi ích kinh tế, được sử dụng phổ biến trong mô hình phát triển phần mềm Agile. Trong một hệ thống dựa vào dòng chảy (flow-based system), thứ tự ưu tiên của các tính năng sẽ cần được xem xét liên tục nhằm đạt được lợi ích kinh tế tốt nhất, thay vì tập trung vào tỷ suất hoàn vốn dự tính ban đầu của tính năng đó (ROI – return on investment). Hay nói đơn giản hơn thì WSJF chú trọng vào chi phí phát sinh khi trì hoãn hoàn thành một tính năng (cost of delay – CoD), hơn là việc tính toán tính năng sẽ đem lại bao nhiêu lợi nhuận cho doanh nghiệp. Tính năng nào có chi phí trì hoãn càng lớn thì độ ưu tiên càng cao.

Công thức tính WSJF

Theo mô hình Scaled Agile Framework (SAFe – một hệ thống các quy trình giúp doanh nghiệp áp dụng Agile ở quy mô phức tạp), WSJF được tính toán bằng cách lấy giá trị tương đối của chi phí trì hoãn thực hiện một tính năng trong một khoảng thời gian nào đó (relative cost of delay, ví dụ: giả sử như chi phí trì hoãn để phát triển tính năng phân loại ticket tự động cho Chăm sóc Khách hàng là 50 triệu/tháng, và nếu không làm tính năng này 3 tháng tới thì chi phí trì hoãn sẽ là 150 triệu) chia cho thời gian tương đối để hoàn thành tính năng đó (relative job duration).

Hình 5. Phương pháp WSJF21

Cách tính chi phí trì hoãn (CoD)

Sẽ rất khó để tính toán chính xác CoD hay thời gian hoàn thành tính năng, đặc biệt đối với những tính năng mới tinh. Vì vậy thường các con số này sẽ được ước chừng một cách tương đối, dựa trên một số cơ sở nhất định. Dưới đây là các yếu tố ảnh hưởng đến chi phí trì hoãn:

User-Business Value
Giá trị mà tính năng (job) mang lại cho người dùng và doanh nghiệp		Time Criticality
Mức độ cấp thiết của tính năng – giá trị mà tính năng mang lại cho người dùng và doanh nghiệp sẽ khấu hao như thế nào nếu trì hoãn việc hoàn thành tính năng?		Risk Reduction and/or Opportunity Enablement
Việc hoàn thành tính năng sẽ giảm thiểu được rủi ro nào, hoặc/và thúc đẩy cơ hội nào cho doanh nghiệp?
– Người dùng thích tính năng này hay tính năng khác hơn?
– Tính năng này mang lại doanh thu như thế nào cho công ty?
– Nếu trì hoãn làm tính năng này thì hệ quả sẽ như thế nào?		– Có thời hạn hoàn thành cố định cho tính năng này không?
– Liệu người dùng có chờ giải pháp này được hoàn thành hay sẽ tìm kiếm giải pháp khác thay thế?
– Việc đang không có tính năng này ảnh hưởng như thế nào đến độ hài lòng của người dùng?		– Rủi ro nào sẽ xảy ra nếu không hoàn thành tính năng nay bây giờ mà là lúc khác trong tương lai?
– Việc hoàn thành tính năng này có mang lại cơ hội phát triển nào cho doanh nghiệp hay không?

Khi tính toán Cost of Delay, các bạn sẽ cần so sánh các tính năng (items/jobs) có trong backlog dựa trên 3 yếu tố và quy đổi theo dãy số Fibonacci. Sau đó cộng chúng lại theo công thức sau:

Cost of Delay = User-Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement

Cách tính thời gian hoàn thành tính năng (job duration)

Việc tính toán thời gian hoàn thành của một tính năng có thể dựa vào:

  • Độ lớn của tính năng: một tính năng có thể không khó nhưng nhiều chi tiết cần phải thực hiện thì thời gian hoàn thiện có thể kéo dài
  • Độ khó của tính năng: tính năng phức tạp (lưu ý là phức tạp so với kỹ năng của nguồn lực hiện có) thì sẽ cần nhiều thời gian hơn để hoàn thành
  • Kỹ năng của nguồn lực hiện có:

Dựa vào các yếu tố trên, chúng ta cũng ước tính thời gian hoàn thành tính năng theo dãy số Fibonacci.

Sau khi có được số liệu của CoD và job duration, các bạn sẽ áp dụng công thức tính WSJF = CoD/job duration để tính ra con số cuối cùng.

Thông tin thêm

  • Flow-based system là hệ thống phát triển sản phẩm liên tục, làm xong tính năng nào thì ra mắt sản phẩm đó ngay. Trong khi đó, iteration-based system là phát triển các tính năng trong một khoảng thời gian cố định (từ 2 đến 4 tuần) và hoàn thành tính năng vào cuối chu trình, và sau đó tiếp tục lặp lại chu trình đó cho các tính năng còn lại trong backlog

Làm thế nào để chọn được phương pháp sắp xếp thứ tự ưu tiên phù hợp với đội nhóm của bạn?

Ngoài những mô hình và phương pháp kể trên, còn nhiều cách thức khác có thể được sử dụng để sắp xếp thứ tự ưu tiên cho các tính năng hoặc công việc trong quá trình phát triển sản phẩm. Nhưng khi có quá nhiều sự lựa chọn thì bạn sẽ dễ cảm thấy bối rối và phân vân giữa các phương thức.

Để chọn ra phương pháp phù hợp với đội nhóm của bạn, bạn sẽ cần phải xem xét các yếu tố sau21:

  • Mục tiêu của sản phẩm hoặc dự án
  • Mức độ phức tạp của sản phẩm
  • Chuyên môn của đội nhóm
  • Dữ liệu quá khứ, hoặc kinh nghiệm từ các sản phẩm/dự án trước đó

Ví dụ như mục tiêu của sản phẩm là độ hài lòng của khách hàng thì Opportunity scoring sẽ là mô hình mà bạn cần sử dụng. Còn với những sản phẩm mà mục tiêu cần đạt được và tính chất sản phẩm phức tạp hơn thì RICE có thể là một mô hình đáng xem xét.

Tuy nhiên, không phải một phương pháp phù hợp tại một thời điểm thì nó sẽ phù hợp mãi mãi. Trong quá trình làm, bạn cũng cần thường xuyên xem xét lại hiệu quả của việc sắp xếp thứ tự ưu tiên của mình. Nếu kết quả ngày càng đi xuống thì có vẻ như phương thức mà bạn đang áp dụng đang không còn đủ tốt. Ngoài ra, khi công ty thay đổi mục tiêu kinh doanh hay chiến lược thì bạn cũng cần chủ động đánh giá lại mô hình sắp xếp thứ tự ưu tiên nào là phù hợp với bối cảnh diễn ra.

Nguồn tham khảo

  1. https://www.aha.io/roadmapping/guide/release-management/prioritization-framework ↩︎
  2. https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html ↩︎
  3. Clegg, Dai; Barker, Richard (1994). Case Method Fast-Track: A RAD Approach ↩︎
  4. “MoSCoW Analysis (6.1.5.2)”. A Guide to the Business Analysis Body of Knowledge (2 ed.). International Institute of Business Analysis. 2009 ↩︎
  5. Davis, Barbee (2012). Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage. Project Management Professional Series. J. Ross Publishing ↩︎
  6. https://www.atlassian.com/agile/product-management/prioritization-framework ↩︎
  7. Wiegers, Karl; Beatty, Joy (2013). Software Requirements. Washington, USA: Microsoft Press. pp. 320–321 ↩︎
  8. McIntyre, John (October 20, 2016). “Moscow or Kano – how do you prioritize?”. HotPMO!. Retrieved October 23, 2016 ↩︎
  9. https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/ ↩︎
  10. https://handbook.gitlab.com/handbook/product/product-processes/#using-the-rice-framework ↩︎
  11. https://intercom.com/blog/wp-content/uploads/2016/03/RICE-scoring-example-spreadsheet-1.xlsx ↩︎
  12. https://www.productplan.com/glossary/kano-model/ ↩︎
  13. https://productschool.com/resources/glossary/kano-model ↩︎
  14. https://www.productplan.com/glossary/kano-model/ ↩︎
  15. https://www.atlassian.com/agile/product-management/prioritization-framework ↩︎
  16. https://www.iapm.net/en/blog/opportunity-score/ ↩︎
  17. https://www.iapm.net/en/blog/opportunity-score/ ↩︎
  18. Anthony Ulwick, What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services, 2005 ↩︎
  19. https://innovationroundtable.com/summit/wp-content/uploads/2014/05/Strategyn_what_is_Outcome_Driven_Innovation.pdf ↩︎
  20. https://scaledagileframework.com/wsjf. ↩︎
  21. https://scaledagileframework.com/wp-content/uploads/2022/12/WSJF_F01.svg ↩︎
  22. https://www.atlassian.com/agile/product-management/prioritization-framework#:~:text=Choosing%20the%20proper%20prioritization%20framework,opportunity%20scoring%20may%20work%20well. ↩︎

Pages: 1 2 3

trachanh71

Leave a Reply