PRIORITIZATION - PHẦN 2 - DỄ MÀ KHÓ
Ở Phần 1 - Khó mà dễ, ProUp đã giới thiệu các phương pháp để đánh giá và sắp xếp độ ưu tiên cũng như các trường hợp cần áp dụng. Tuy nhiên, thực tế có nhiều vấn đề khác xảy ra xung quanh bài toán prioritization này.
Phần 2 - Dễ mà khó: Những lỗi sai phổ biến và Nguyên tắc chung khi đánh giá độ ưu tiên
Đánh giá độ ưu tiên là trách nhiệm của ai
Mục tiêu của đánh giá độ ưu tiên là để chọn ra những sản phẩm, tính năng, dự án, … cần làm để giúp doanh nghiệp đạt được kết quả tốt nhất với nguồn lực và thời gian có giới hạn.
Để làm được điều đó, cần nhiều thông tin từ các team khác nhau, business, operation, marketing, product, tech. Tuy nhiên, vẫn cần một người, một team điều phối, thực thi việc đánh giá độ ưu tiên này. Đó chính là team Product.
“Lỗi sai” phổ biến
Sau đâu là một vài “lỗi sai” phổ biến mà mình đã từng gặp
“Idea của sếp nên cần được ưu tiên”. Mình từng gặp và cũng từng phỏng vấn một vài bạn PO/PM mà “idea của sếp” chính là thứ được ưu tiên làm trước, làm liền. Hoặc từng có BA (Business Analyst) đưa ra yêu cầu làm một tính năng và mong muốn được làm sớm với lý do là: “đó là idea của anh A, chị B”. Việc idea đó được ưu tiên có thể đúng, có thể sai. Idea có sếp có thể mang tính chiến lược (từ những nghiên cứu, quan sát, báo cáo, … nào đó), cũng có thể đang có một deadline nào đó liên quan, hoặc cũng có thể chỉ là một idea mà sếp nghĩ ra và gửi cho team. Với vai trò là PM/PO, bạn vẫn cần tìm hiểu, phân tích, đánh giá, không những để xem xét độ ưu tiên, mà còn để quay về xem vì sao có idea đó (why?), idea đó sinh ra để làm gì (for what?).
Không thống nhất với các bên liên quan (misalignment), đặc biệt là PIC (person in charge), ở đây là PO/PM. Ví dụ trường hợp mình từng gặp: Team tech quyết định làm một dự án X mà PO không biết khi lên roadmap đầu quý, khi được hỏi thì lý do là: “Sếp Y giao deadline cho team vào cuối tháng này”. Ở đây, việc dự án đó cần làm và hoàn thành vào cuối tháng vẫn có thể đúng, để đạt được một mục tiêu nào đó, hoặc để thống nhất về thời gian với nhiều nhóm khác. Tuy nhiên, cho dù đó là một dự án về tech, thì cũng cần được đưa ra để đánh giá độ ưu tiên chung với các dự án khác, đồng thời để cho các stakeholder từ các team cùng biết về sự tồn tại của dự án đó để có kế hoạch hợp lý.
Đây là quyền của PM/PO? Điều này không đúng. PM/PO sẽ là người cầm cân nảy mực, phân tích, đánh giá, … các initiatives từ tất cả stakeholders để đưa ra thứ tự ưu tiên hợp lý, chứ không phải là người quyết định 100%. Sau khi PO/PM đưa ra đề xuất, mọi người có quyền thắc mắc tại sao lại chọn dự án này, không phải dự án kia, hoặc đưa ra những lý do nên ưu tiên một dự án khác hơn. PO/PM có trách nhiệm đưa ra những tìm hiểu, phân tích, đánh giá, tại sao lại đề xuất như vậy và chỉnh sửa nếu cần thiết. Tuỳ vào công ty, tuỳ vào business, tùy vào vị trí mà người quyết định và chịu trách nhiệm cuối cùng là ai.
PO/PM hoặc một người nào đó chỉ quyết định/đề xuất, không trao đổi thường xuyên trong quá trình prioritize và không thông báo (kèm lý do cụ thể) sau khi thực hiện xong việc sắp xếp độ ưu tiên. Ví dụ: Mình từng hỏi một bạn Business Analyst, tại sao lại sắp xếp roadmap như vậy, tại sao lại là dự án A chứ không phải dự án B? Cá nhân bạn BA này cũng tin rằng nên làm dự án A chứ ko phải dự án B, nhưng bạn lại trả lời mình là: “Không biết, PO quyết định như vậy”. Ở đây, PO cần chủ động chia sẻ cho các stakeholder về roadmap và lý do tại sao lại lựa chọn, sắp xếp như vậy. Đồng thời, bạn BA cũng nên đưa ra ý kiến của mình và hỏi lại PO lý do vì sao nếu chưa rõ.
Chỉ dựa trên kết quả dự kiến. Mình đã từng chứng kiến PM/PO xây dựng roadmap chỉ dựa trên kết quả dự kiến. Giả sử những dự đoán đó là tương đối chính xác, thì điều này vẫn khiến cho roadmap đó thiếu đi các yếu tố khác, ví dụ như: Mức độ phức tạp của dự án (ease), khả năng thành công của dự án (confidence). Có trường hợp các dự án khác mặc dù rất nhỏ nhưng có thể tăng nhanh một chỉ số nào đó bị bỏ qua. Có trường hợp dự án đó cần được đầu tư trong 6 tháng để đem lại tác động lớn, nhưng sau 1-2 tháng chưa có kết quả tốt thì đã bị dừng.
Chỉ xét đến việc “được gì” nếu làm, không xét đến việc “mất gì” nếu không làm. Điển hình là không xét đến các tech debt, những “món nợ” về kiến trúc, về kỹ thuật, mà trước đó team đã chủ động “mượn” để ưu tiên “release fast” hoặc do quá trình xây dựng thì những hệ thống cũ dần không còn phù hợp. Các tech debt nếu để lâu, không trả thì sẽ gây ra rất nhiều lỗi, cản trở quá trình phát triển tính năng mới trong tương lai.
Ưu tiên dự án mới, bỏ qua các tính năng cũ, trong khi cải tiến các tính năng cũ thì thường có ROI (return on investment) cao hơn, bởi lẽ đã có sẵn, không tốn quá nhiều công sức (ease) để cải tiến và cũng đã có những learnings (confidence) sau khi release (xét cả công sức và thời gian của business và product).
Đánh giá, sắp xếp độ ưu tiên khi chỉ mới có idea, chưa rõ về vấn đề cần giải quyết, tại sao cần tính năng đó, tính năng đó dùng để làm gì. Sau đó, vì nó được ưu tiên, cần làm sớm, nên để kịp với kế hoạch đặt ra, kịp develop thì làm discovery rất sơ sài, đi luôn đến thiết kế tính năng.
“Dự án đã ở trong hàng chờ quá lâu, cần được ưu tiên” hoặc do áp lực từ các cá nhân, một dự án được nhắc lại quá nhiều lần khiến cho PO/PM bị biased. Nếu toàn bộ quá trình prioritization trước đó là hợp lý, thì một dự án đã ở trong hàng chờ quá lâu có nghĩa là nó không nên được ưu tiên, hoặc nguồn lực của công ty quá mỏng so với các mục tiêu cần đạt được. Mỗi lần đánh giá độ ưu tiên, thì tất cả các dự án đều được xem xét các tiêu chí một cách khách quan, việc một dự án đã ở trong hàng chờ quá lâu không đồng nghĩa với việc nó cần được ưu tiên để làm sớm.
Một vài nguyên tắc cơ bản
Để tránh các lỗi sai trên, ngoài việc cần phân tích, sử dụng các framework để đánh giá một cách hợp lý, thì cũng cần có những nguyên tắc cơ bản khi sắp xếp độ ưu tiên và lập kế hoạch.
Tối ưu nhưng không nhồi nhét: Cần dựa trên nguồn lực và thời gian, đồng thời có thể áp dụng các kỹ thuật để lập một kế hoạch tối ưu nhất, tuy nhiên không nhồi nhét. Tránh trường hợp sau khi phân tích, đánh giá độ ưu tiên rồi, dựa vào nguồn lực đã có để lên kế hoạch rồi vẫn muốn chọn thêm một vài dự án không được ưu tiên nữa, bởi vì cho dù có chọn thêm thì cũng không thực thi được (thông thường ở giai đoạn planning chúng ta thường underestimate sự phức tạp, thời gian, công sức cần thực hiện một dự án).
Cần có cơ chế, quy trình để nhận nhu cầu từ các team, sau đó phân tích, đánh giá, lập kế hoạch và đồng bộ thông tin rõ ràng cho các stakeholders đó. Đảm bảo không bị thiếu, không bị misalignment trong quá trình lập kế hoạch. Phần này do team Product chịu trách nhiệm, nhưng mọi người đều có quyền được biết và hỏi lại nếu thấy chưa thuyết phục hoặc có ý kiến khác.
Phân tích, đánh giá khách quan, đồng nhất. Có thể xem xét các trường hợp ngoại lệ với các lý do cụ thể.
Yêu cầu từ các stakeholder đều như nhau (idea từ sếp có thể được backup bởi những lý do mang tính chiến lược, cần tìm hiểu rõ nếu cần).
Tổng kết
Mục tiêu của đánh giá độ ưu tiên là để chọn ra những sản phẩm, tính năng, dự án, … cần làm để giúp doanh nghiệp đạt được kết quả tốt nhất với nguồn lực và thời gian có giới hạn. Do đó, tất cả mọi công việc, nguyên tắc, quy trình, trách nhiệm về việc đánh giá độ ưu tiên là để đạt được mục tiêu này.
Tuy đã có các framework để phân tích và đánh giá độ ưu tiên, lập kế hoạch (DỄ), nhưng để áp dụng được thì cần hiểu được bản chất của nó và mục tiêu của công việc là gì (MÀ KHÓ).