Trong công việc, nhiều lúc chúng ta căng thẳng bởi vì quá tải công việc, quá nhiều thứ mà chúng ta "muốn" làm, nó là một mớ hỗn độn, khiến chúng ta không biết bắt đầu phải làm gì trước. Cách đây vài năm bản thân mình từng trải qua câu chuyện tương tự như vậy, những công việc phát sinh cứ xuất hiện, những ý tưởng mới liên tục khiêu khích bản thân mình, mình không đánh giá, kiểm soát được, và rơi vào trạng thái căng thẳng, quá tải. Lý do chính là: Bản thân mình không sắp xếp được thứ tự ưu tiên, không đánh giá được cái nào PHẢI LÀM (MUST DO), NÊN LÀM (SHOULD DO), CÓ THỂ LÀM (COULD DO) và KHÔNG NÊN LÀM (WOULD'T). Ngoài ra, bản thân mình cũng chưa học được cách từ chối (say no), kể cả trong quá trình làm quản lý sản phẩm (product management).
Mình bắt đầu ứng dụng hai từ "Ưu tiên" này vào cuộc sống, công việc từ khi mình trải nghiệm làm product managemer cho chính startup mình, và một số product khác cho khách hàng.
Ưu tiên là hai từ rất quan trọng, giúp chúng ta giảm bớt lãng phí thời gian, bớt căng thẳng.
Trong bài viết này, mình chia sẻ về chủ đề "Chọn tính năng ưu tiên (Feature prioritization)" để giúp các PM định nghĩa các stage trong product road map như thế.
Trong quá trình xây dựng sản phẩm, nhiệm vụ của Product Owner (PO) hoặc Product manager (PM) phải chọn các danh sách tính năng ưu tiên cho từng giai đoạn ra mắt sản phẩm (các giai đoạn MVPs, Release 1, Release 2,...). Chọn các tính năng ưu tiên phụ thuộc vào nhiều yếu tố, thường thì dựa vào giá trị của tính năng đó với khách hàng, chi phí phát triển tính năng đó (hay nói cách khác là nguồn lực: nhân lực, tài lực), thời gian làm việc, mục tiêu kinh doanh, tính quan trọng, mức độ khẩn cấp.
Đầu tiên, dùng customer journey map để tìm ra pain point và đánh giá mức độ pain point này tác động đến khách hàng như thế nào.
Sau khi biết được tính quan trọng, giá trị, mức độ khẩn cấp thì bước tiếp theo sẽ phân tích tổng quan về tính năng.
Ở bước phân tích này, mình dùng user story map. User story map, giúp chúng ta nhìn tổng qua về Epic, story, step by step, từ đó liệt ra ra tất cả tính năng liên quan đến pain point này.
Sau khi đã liệt kê ra hết rồi, chúng ta bước sang công việc quan trọng tiếp theo để chọn các tính năng release theo từng giai đoạn, tạo road map, tạo sprint.
Bước này, cũng là nội dung chính của bài viết này. Mình sẽ giới thiệu 3 frameworks mà mình thường sử dụng. (Thực tế thì có rất nhiều framework mà mỗi trường hợp, mỗi người sử dụng khác nhau)
Ma trận Giá trị và nổ lực/chi phí/ thời gian. (Value vs Effort)
Ma trận Tính quan trọng và sự hài lòng của khách hàng. (The Importance vs Satisfaction Framework)
Kano model
Ở bài biết này, mình giới thiệu 3 phương pháp trên mà bản thân mình thường dùng. Ngoài ra, các bạn có thể tham khảo thêm nhiều phương pháp để chọn tính năng ưu tiên như: RICE framework, MoSCoW Method. The product tree, hay Priority poker.
Ma trận Giá trị và nổ lực/chi phí/ thời gian. (Value vs Effort)
Gồm có trục đứng thể hiện trục giá trị của tính năng cho khách hàng và trục ngang thể hiện thời gian hoàn thiện hoặc chi phí hoàn thiện hay còn gọi là sự nổ lực để hoàn thiện tính năng.
Việc này rất quan trọng, nó giúp chúng ta cân nhắc có nên triển khai tính năng này không? Có đáng để làm không? Khi chúng ta nổ lực quá nhiều nhưng tính năng đó chẳng mang lại giá trị nhiều cho người dùng, hoặc khi triển khai thì tính năng này nó ảnh hưởng đến các bộ phận khác liên quan đến sản phẩm, liên quan đến quy trình công ty hay không. Nghĩa là, ngoài 2 biến value và effort, chúng ta còn các có biến xem xét khác, điển hình là mức độ ảnh hưởng của tính năng này đến nội bộ công ty (sản phẩm), nguồn lực công ty (team).
Gồm 4 phần tư trong ma trận giá trị và nổ lực: Phần tư 1: Giá trị cao, nổ lực thấp --> Làm ngay, tạo sprint để kick-off.
Phần tư 2: Giá trị cao, nổ lực nhiều --> Phân tích thêm, thậm chí chia nhỏ ra để phân tích thành nhiều tính năng nhỏ. Từ đó xem xét có nên đưa vào sprint hay không.
Phần tư 3: Giá trị thấp, nổ lực thấp --> Nếu thời gian trong sprint còn dư hoặc thời gian không đủ để hoàn thiện các tính năng trong sprint đã tạo. Thì sử dụng thời gian này để xem xét phần tư này.
Phần tư 4: Giá trị thấp, nổ lực nhiều --> Loại bỏ, tuy nhiên chúng ta nên lưu trữ ở một thư mục tính năng chưa được phân loại. Bởi vì biết đâu chúng ta lấy ra để tiếp tục brainstorming.
Trên đây là phương pháp "Ma trận Giá trị với nỗ lực". Mình sẽ viết tiếp 2 phương pháp còn lại ở bài sau. Khi nào hoàn thiện sẽ link bên dưới bài viết này.
Tái bút: Bài viết được viết qua sự trải nghiệm, quan điểm, góc nhìn cá nhân, tổng hợp kiến thức có dẫn nguồn, kiến thức luôn có những giới hạn nhất định. Vì thế, bài viết có thể còn hạn chế trong khuôn khổ hiểu biết, trải nghiệm cá nhân và có thể không phù hợp với các góc nhìn của một nhóm người đọc. Rất mong, các bạn đọc hãy tiếp thu một cách có chọn lọc và xem đây là một góc nhìn khác trong hành trình thu thập thông tin, kiến thức.
Cuối cùng, trên tinh thần chia sẻ là một phương pháp học hiệu, như slogan website này - Learning by sharing, rất mong nhận được sự góp ý của quý bạn đọc để mình cải thiện và trau dồi thêm, cũng như thêm góc nhìn.
Xin cảm ơn quý bạn đọc!
Comments