Product Owner là tên gọi mới/ khác của Business Analyst?
Tôi không hiểu sự hiểu lầm này đến từ đâu, nhưng càng ngày tôi càng nhận thấy nhiều người hiểu lầm về hai vai trò này. Đơn giản, Product Owner (PO) là một vai trò trong Scrum team, và nó chẳng có liên quan hay lịch sử gì từ Business Analyst cả. Scrum Team của bạn đang luôn bị quá tải bởi công việc? Scrum Team của bạn đang chịu áp lực phải làm nhiều hơn? Bạn không hiểu được mục đích công việc hiện tại của bạn đang làm là gì? Những thay đổi cứ diễn ra liên tục, khiến Team bạn mệt mỏi và mất phương hướng? Có cái gì đó cứ sai sai trong cái guồng quay công việc này? Hãy cùng Scrumviet bắt mạch xem vì sao nhé.
Cùng xem qua biểu đồ dưới đây:
Trong những tổ chức đang áp dụng Scrum vào công việc, rất nhiều tổ chức đang áp dụng Scrum ở quy mô lớn, nhiều Scrum team cùng làm việc trên một sản phẩm. Việc mở rộng nhiều Scrum team cùng làm trên một sản phẩm sẽ là cơ hội cho sản phẩm được phát triển nhanh hơn, mang lại nhiều giá trị hơn đến người dùng. Nhưng nó cũng chứa đựng nhiều thử thách và khó khăn trong việc làm sao để các Scrum team phối hợp với nhau một cách hiệu quả. Có một sai lầm cố hữu mà tôi nhận thấy đa phần các nhóm Scrum cùng làm trên 1 sản phẩm mắc phải, đó là có nhiều hơn 1 Product Owner cho sản phẩm đó. Không phải tự nhiên mà Scrum guide trực tiếp đề cập đến việc:
The Product Owner is one person, not a committee - Scrum guide 2020
Vậy khi một sản phẩm, có nhiều hơn một Product Owner thì chuyện gì sẽ xảy ra? Hãy cùng tôi điểm qua những vấn đề mà sản phẩm, và Scrum team sẽ gặp phải nếu có nhiều hơn một Product Owner nhé:
Goal Oriented Product Roadmap (GO Product Roadmap) là gì?
Goal Oriented Product Roadmap hay GO Product Roadmap là một trong những cách trình bày Product Roadmap tập trung vào mục tiêu (Goal) của sản phẩm trong tương lai. Việc trình bày Product Roadmap hướng đến mục tiêu của sản phẩm, sẽ giúp Product Owner có thể dễ dàng hơn trong việc quản lý Product Backlog cam kết với Product Goal, tránh việc chỉ chú tâm đến chức năng mà quên mất giá trị người dùng.
Lean Canvas là gì?
Lean Canvas là một công cụ giúp xây dựng chiến lược kinh doanh một cách đơn giản và nhanh chóng. Khi áp dụng Lean Canvas, chiến lược kinh doanh của sản phẩm sẽ được trình bày trong một trang duy nhất. Ash Maurya là tác giả của Lean Canvas, và ông đã tạo ra Lean Canvas dựa trên Business Model Canvas (được tạo ra bởi Alexander Osterwalder) kết hợp với tư duy khởi nghiệp tinh gọn (Lean Startups).
Trong khi kế hoạch/ chiến lược kinh doanh mất quá nhiều thời gian để viết, hiếm khi được cập nhật và hầu như không bao giờ được người khác đọc. Việc dễ dàng ghi chép lại, theo dõi và cập nhật kế hoạch của bạn là chìa khóa quan trọng góp phần thành công. Lean Canvas sẽ thay thế các kế hoạch kinh doanh dài và nhàm chán bằng một cách trình bày trong một trang duy nhất. Nó sẽ tạo ra tính đơn giản, gọn nhẹ, dễ thay đổi và có thể dễ chia sẻ để tương tác với các bên liên quan khác nhau. Những lợi điểm này mà đã giúp Lean Canvas được rất nhiều tổ chức hay các Scrum team sử dụng, và cũng trở thành một trong những công cụ hữu ích được sử dụng bởi Product Owner, khi xây dựng mô hình kinh doanh cho sản phẩm của mình.
Now - Next - Later Product roadmap là một công cụ giúp cho Product Owner có thể dùng để trình bày và truyền đạt ý tưởng về độ ưu tiên của các PBIs trong Product Backlog. Nó cũng được xem như là một cách trình bày Product Backlog của Product Owner nhằm nhấn mạnh và thể hiện rõ giá trị sản phầm nào có mức độ ưu tiên cao hơn. Cách trình bày này cung cấp cho nhóm và các bên liên quan một cách trực quan dễ hiểu và dễ dàng thay đổi trong bối cảnh những nhu cầu về sản phẩm thay đổi liên tục.
Bài viết này tôi xin chia sẻ về những sai lầm trong vai trò Product Owner (PO) mà tôi thường thấy nhất (Tôi phân tích và tổng hợp lại thành một vài sai lầm thường gặp nhất trong rất nhiều sai lầm khác nhau). Mục tiêu là để các Scrum Team nhận thấy được những ảnh hưởng từ những sai lầm này, để tránh hoặc thay đổi cách làm việc của mình, qua đó có thể xây dựng một Scrum Team tốt hơn.
Chú ý: Một Product Owner có thể đang mắc một hoặc nhiều sai lầm được liệt kê ở dưới cùng lúc. Empathy Map là gì?Empathy Map là công cụ giúp chúng ta có thể liên kết, và hình dung rõ hơn về hành vi và cảm nhận của người dùng sản phẩm, qua đó có được sự hiểu biết sâu hơn về khách hàng, để có sự điều chỉnh phù hợp làm hài lòng khách hàng hơn. Trong quá trình bạn lập lên biểu đồ, những khoảng trống, hay câu hỏi chưa được trả lời sẽ giúp bạn nhận ra được những thiếu sót, lỗ hỗng nào mà bạn chưa nhận ra để cải thiện.
Công cụ này được sử dụng rất nhiều bởi các nhóm làm việc chuyên về UX (User Experience), cũng như là một công cụ chủ lực cho Product Owner hiểu và định hình hành vi của khách hàng với sản phẩm. As the product owner, you are well aware that part of the success of your product depends on your decision. Every day, you must be facing:
Để có thể tối ưu hoá được giá trị sản phẩm của mình, các Product Owner phải làm chủ được Product backlog. Nhưng việc quản lý Backlog không hề dễ dàng. Các Product Owner luôn gặp khó khăn trong việc xác định sự ưu tiên của các Product Backlog Items. Sự khó khăn này bắt nguồn từ việc các Product backlog thường chứa đựng rất nhiều thứ khác nhau, đến từ nhu cầu của nhiều bên khác nhau: Khách hàng, CEO, các phòng ban… hay còn là các lỗi hoặc nợ kỹ thuật cần được xem xét.
Sự hỗn tạp này khiến nhiều Product Owner bối rối, và gặp khó khăn khi đưa ra quyết định nên ưu tiên Product Backlog Items nào trước. Hay làm sao kết nối những ưu tiên đó với mục tiêu chung của sản phẩm hoặc doanh nghiệp. Với lý do đó Jeff Patton đã nghĩ ra một phương pháp gọi là User Story Mapping, để giúp Product Owner có thể dễ dàng hơn trong việc sắp xếp thứ tự của các Product Backlog Items (PBIs). Nói đơn giản: User Story Mapping là một phương pháp sắp xếp phân loại, trực quan hoá Product backlog, giúp cho Product backlog của bạn trở nên dễ quản lý hơn, và thể hiện được sự liên kết giữa người dùng và giá trị mà bạn muốn xây dựng cho họ. Phương thức này vô cùng đơn giản (Xem hình dưới):
Nội dung đã được cập nhật theo bản Scrum guide 2020
Nhiều năm trước, tôi bắt đầu tìm hiểu và quan sát cách thức hoạt động của các dự án phần mềm. Lý do tôi quan tâm đến việc này là vì, nhiều dự án thậm chí đã rất thành công trong việc deliver đúng hạn, đạt được đúng yêu cầu đề ra ban đầu, và hoàn thành trong chi phí cho phép. Tuy nhiên, khi nó được đưa ra thị trường thì không ai sử dụng cả. Sau đó sản phẩm đó cũng chết đi để lại nhiều sự lãng phí trong đầu tư và sức lực của các bên để đảm bảo nó được hoàn thành. Từ đó, trong đầu tôi luôn tồn tại một câu hỏi: Điều gì tạo ra khoảng cách giữa một sản phẩm thành công, được đón nhận bởi người dùng và một sản phẩm thất bại? Qua nhiều năm quan sát, tôi rút ra được một điều, một trong những lý do sản phẩm không được đón nhận như nó được kỳ vọng đa phần là vì nó bị đánh giá sai giữa "Input", "Output" và "Outcome".
Product Owner là một trong ba vai trò chính của Scrum Team. Product Owner như là một mini CEO của sản phẩm, người có trách nhiệm tối ưu hoá giá trị sản phẩm đó mang lại cho người dùng.
Vai trò Product Owner đối với Việt Nam còn mới mẻ, chỉ mới vài năm trở lại đây, người ta mới bắt đầu nói về nó, và nhiều công ty bắt đầu cần và tuyển dụng những ứng viên cho vị trí Product Owner. Nhưng thực ra vai trò Product Owner không hề mới, Product Owner là một trong ba vai trò của Scrum, mà Scrum thì đã hơn 20 năm tuổi.
Scrum đề ra ba vai trò trong Scrum Team: Product Owner, Scrum Master và Development team. Nhưng cũng có nhiều câu hỏi được đặt ra, liệu một người có thể vừa làm Product Owner vừa làm Scrum Master?
|