Product Owner là người đại diện cho các bên liên quan?

Tác giả: kiendt at 04/06/2021

Danh mục

Agile cho công nghệ

Thẻ

Ngày hôm nay chúng ta sẽ cùng tìm hiểu về hiểu lầm khi nghĩ rằng Product Owner hoạt động như một đại diện của các Bên liên quan. Đơn giản hơn, đây là việc cho rằng trong Scrum, Product Owner nên là người thay mặt toàn bộ Nhóm Scrum và là người duy nhất giao tiếp với các bên liên quan (ví dụ như khách hàng, người dùng).

>> Download miễn phí Ebook “Bí quyết kiểm soát tiến độ dự án” => Sách tặng

Chúng tôi đã thấy nhiều Nhóm Scrum có biểu hiện đúng với cách nghĩ trên thông qua những hành vi dưới đây:

Bất cứ khi nào xuất hiện một câu hỏi về một tính năng, các Nhà Phát triển sẽ yêu cầu Product Owner làm rõ/giải thích nó với các bên liên quan. Chúng tôi từng chứng kiến một nhóm trên thực tế dành hẳn một tiếng để thảo luận và làm rõ với các bên liên quan về một yêu cầu không rõ ràng (mà đáng lẽ ra chỉ cần một cuộc gọi 1-phút là có thể giải quyết được).
Bất cứ khi nào một bên liên quan đưa ra các ý tưởng mới cho các Nhà Phát triển, các thành viên này sẽ chuyển chúng sang cho Product Owner mà không có ghi chú thêm gì.
Product Owner được mong đợi sẽ tự phát hiện/khám phá ra công việc trong Product Backlog thay mặt toàn Nhóm Scrum.

Giải mã hiểu lầm

Hướng dẫn Scrum (Scrum Guide) đã nói ra rằng Product Owner là người chịu trách nhiệm cho việc tối đa hoá giá trị của sản phẩm được tạo ra từ các công việc của các Nhà Phát triển. Công việc được thực hiện minh bạch trong Product Backlog và được quản lý bởi Product Owner. Nhằm xác định công việc nào có giá trị giá trị, sau đó sẽ sắp xếp thứ tự cho chúng, thông tin đầu vào từ các bên liên quan hiển nhiên là cần thiết. Tuy nhiên, trong Scrum Guide không có chỗ nào nói rằng Product Owner là người duy nhất chịu trách nhiệm việc giao tiếp với các bên liên quan.

Ý nghĩa của Scrum thật sự đến từ mục tiêu mà chúng ta đang cố để đạt được. Scrum được xây dựng dựa trên sự thực nghiệm mà trong đó Nhóm Phát triển là một tổ hợp rất phức tạp. Khám phá ra chúng ta cần gì cũng như cách để thực thi tốt nhất sẽ yêu cầu Nhóm Scrum cần phải làm việc rất nhiều cùng với các khách hàng, người dùng cũng như các bên liên quan khác.

Scrum là một “khám phá mang tính hợp tác”. Bắt đầu chỉ với một vài đường vẽ nguệch ngoạc trên chiếc bản đồ kho báu, Nhóm Scrum bắt đầu tiến vào cuộc hành trình với các bên liên quan để tìm ra nơi kho báu ẩn giấu. Nguyên lý hợp tác này được lặp lại ở dòng thứ 3 của bản Tuyên ngôn Agile: “Hợp tác với khách hàng hơn là đàm phán hợp đồng”.

Khi chỉ riêng Product Owner giao tiếp với các bên liên quan sẽ có nhiều chướng ngại xảy đến:

Các bên liên quan không cảm thấy được lắng nghe khi Nhóm Phát triển muốn họ nói chuyện trực tiếp với Product Owner để thảo luận các ý tưởng mới. Bằng cách biến Scrum trở thành cách thức hoạt động “quan liêu”, Nhóm Scrum sẽ phản hồi chậm hơn so với nhu cầu của người dùng;
Việc tiếp thu các thông tin hữu ích mới/ý tưởng mới và các cơ hội giá trị sẽ có thể không được phát huy tốt;
Tính linh hoạt của Nhóm Scrum sẽ bị hạn chế khi Product Owner trở thành nơi tập trung duy nhất và là nút thắt nhằm giải đáp/làm rõ các yêu cầu với các bên liên quan;
Nhóm Phát triển sẽ không tạo ra đúng sản phẩm mà người dùng cần, do vậy dẫn đến kết quả là sản phẩm khó hiểu, khó dùng và không thật sự đáp ứng được nhu cầu thật sự.

Do vậy, việc coi Product Owner như là đại diện cho các bên liên quan sẽ không giúp cho nhóm trở nên Agile. Nhưng vậy thì vai trò của Product Owner được định hướng như thế nào?

Người Đại diện hay Hỗ trợ?

Thay vì để họ là những người đại diện cho các bên liên quan. Chúng tôi thích giải thích rằng Product Owner là một nhân vật có trách nhiệm như là tiếng nói của các bên liên quan trong quá trình “khám phá cộng tác”. Làm thế nào để hoàn thành thì sẽ phụ thuộc hoàn toàn vào Product Owner và Nhóm Scrum, cũng như phụ thuộc vào sự có mặt của các bên liên quan, hay bản chất của sản phẩm trong quá trình phát triển. Nhưng chúng tôi thấy một số việc đã hoạt động hiệu quả rất hiệu quả, ví dụ:

Product Owner mời các bên liên quan tham gia Sơ kết Sprint, đây được coi là “cơ hội tối thiểu” trong Scrum khi các thông tin từ các bên liên quan được thu thập;
Product Owner tổ chức các hội thảo nơi anh/cô ấy, các bên liên quan và thành viên Nhóm Phát triển cùng nhau làm việc để phát hiện/làm rõ những công việc có giá trị sắp tới cho sản phẩm;
Product Owner tạo ra những cơ hội và nền tảng để Nhóm Phát triển có thể làm việc cùng các bên liên quan nhằm kiểm thử các giả định hoặc làm rõ các nhu cầu cần thiết;
Product Owner tổ chức các sự kiện hay chuyến tham quan thân mật để Nhóm Phát triển có cơ hội tìm hiểu rõ hơn về nhau, đặc biệt là những ai đang sử dụng sản phẩm.

Thay vì tạo ra các bức tường cản trở Nhóm Phát triển, Product Owner nên kết nối khoảng cách tổ chức giữa các Nhà Phát triển và Bên liên quan (cụ thể là Người dùng). Trong bất cứ trường hợp nào, việc này nên được thực hiện theo cách tôn trọng trọng tâm của Nhóm Phát triển cần trong một Sprint.

Chúng tôi muốn nhấn mạnh rằng Product Owner cần giữ trách nhiệm cho những việc xảy đến trong Product Backlog cũng như thứ tự của các công việc trong đó. Sau cùng, họ vẫn là Người-sở-hữu sản phẩm (Product – Owner). Nhưng không phải là làm việc theo cách thức truyền thống, khi mọi việc đều phải qua tay của Product Owner.

Vai trò của Product owner

Thủ thuật

Nếu bạn là ScrumMaster, hãy hỗ trợ Product Owner bằng cách đưa ra cách tiếp cận nhằm thu hẹp khoảng cách giữa bên phát triển và bên liên quan;
Liberating Structure “25/10 Crowd Sourcing” là một phương pháp tốt nhằm phát hiện nhanh chóng các tính năng có giá trị cao cho bên liên quan và Nhóm Phát triển. Một số cấu trúc khác cũng rất hữu ích như Wise Crowds, Celebrity Interview;
Tổ chức các buổi thảo luận gồm Bên liên quan và các thành viên nhóm Phát triển cùng ngồi lại với nhau để tạo ra các “Bản đồ thấu cảm” ( Empathy Maps), “Thiết kế hộp” (Design the box) hoặc thực hiện “Ước tính thần kì” (Magic Estimation);
Tạo các Personas (nhân vật tưởng tượng mô tả kiểu người dùng khác nhau) dựa theo các Bên liên quan có thật và liên kết họ với các hạng mục của Product Backlog. Bất cứ khi nào có câu hỏi phát sinh trong quá trình làm việc, Nhóm Phát triển sẽ biết cần phải liên hệ với ai để có thể trả lời các câu hỏi rõ ràng hơn cũng như đánh giá các luận định.

Lời kết

Trong bài này chúng ta đã giải mã một hiểu lầm khác, rằng Product Owner là Đại diện cho các bên liên quan. Kết quả cuối cùng cho thấy rằng Nhóm Scrum trở bên ít Agile hơn khi chỉ có mình Product Owner thực hiện việc giao tiếp với các bên liên quan. Thay vì chỉ định Product Owner như là một người đại diện, chúng tôi muốn giải thích Product Owner như là một cá nhân có trách nghiệm kéo bên liên quan vào các cuộc hội thoại. Chúng ta đã đi qua một vào mẹo cụ thể. Bạn nghĩ gì về hiểu lầm này? Bạn có đồng ý không? Và bạn đã học được những điều gì?

Bài viết liên quan: