Vì sao một sản phẩm chỉ có một Product Owner?

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é:

​Phá vỡ chủ nghĩa kinh nghiệm, vì làm chậm việc học hỏi của Scrum team và sản phẩm

Chủ nghĩa kinh nghiệm được xây dựng trên tính minh bạch. Thiếu đi tính minh bạch sẽ làm mất đi khả năng học hỏi và thích nghi của sản phẩm đó. (Đọc thêm: Transparency, don't left it behind!). Có nhiều Product Owner thường dẫn đến những việc như:

• Có nhiều hơn một Product Backlog, thường được gọi là những "Product backlog con" được chia ra từ một "Product backlog lớn hơn", việc này sẽ khiến cho việc quản lý Product backlog trở nên phức tạp hơn, không đồng bộ, thiếu tính minh bạch vì vậy khó có thể nhìn được bức tranh chung của tất cả Product Backlog cùng một lúc. Việc phân mảnh này cũng khiến cho thời gian để quản lý Product Backlog của các Product Owner tăng lên đáng kể.
• Thiếu tính minh bạch trong việc ai là người quyết định. Việc có nhiều hơn một Product Owner sẽ dẫn đến việc đưa ra quyết định sẽ khó khăn hơn, vì lúc này ai sẽ nghe ai? Thường mỗi Product Owner sẽ bảo vệ cho phần sản phẩm mà họ đang chịu trách nhiệm. Điều này lại dẫn đến một vấn đề khác, đó là các công ty sẽ thêm vào một vai trò như: Head of Product, Product Manager… quản lý và đưa ra quyết định cuối cho các Product Owner. Và thêm cấp quản lý, nghĩa là giới hạn quyền ra quyết định của Product Owner, gia tăng việc phụ thuộc vào quyết định của cấp trên, và làm tăng thời gian chờ đợi cấp trên quyết, dẫn đến thời gian phản hồi của sản phẩm đó đến người dùng chậm đi đáng kể (chủ nghĩa kinh nghiệm bị tổn hại). Điều này cũng khiến Scrum team trở nên bị động hơn, mất khả năng tự chủ và học hỏi, không còn Agile nữa.
• Mọi thứ sẽ còn trở nên tệ hơn nếu bạn có nhiều Product Owner, nhưng chỉ có một Scrum team, lúc này Scrum team sẽ khó định hướng và không biết phải theo định hướng của Product Owner nào… dẫn đến mỗi thứ làm một chút, và không thể tạo ra được Done Increment vào cuối Sprint, làm tổn hại đến khả năng học hỏi từ khách hàng của Scrum team. Ngoài ra điều này còn dẫn đến những mệt mỏi, chán chường cho chính Scrum team, khi liên tục phải chạy theo mong muốn của nhiều Product Owner cùng lúc. Những Scrum team này thường không kết nối được mục tiêu chung, và không biết công việc mình đang làm mang lại giá trị gì.

​

Gia tăng sự phụ thuộc lẫn nhau

Việc nhiều Product Owner quản lý một phần của sản phẩm (dù là tách biệt, mảng sản phẩm cho khách hàng A, B, C. Hay thị trường Châu Âu hay Châu Á...) thì cũng sẽ có những sự phụ thuộc xảy ra:

• Phụ thuộc về nguồn nhân lực dùng chung, vì là kỹ năng hiếm, khó kiếm trên thị trường.
• Phụ thuộc giá trị của sản phẩm, hay còn gọi là mâu thuẫn giá trị nội tại của sản phẩm (Ví Dụ: Product Owner A muốn có được giá trị là X nhưng nó lại giảm và suy yếu đi giá trị mảng sản phẩm mà Product Owner B đang có…)
• Phụ thuộc về việc dùng chung một cơ sở hạ tầng mà nếu thay đổi sẽ ảnh hưởng đến những mảng khác của sản phẩm v.v

Những phụ thuộc này không tự sinh ra nhiều hơn khi có nhiều Product Owner, chỉ là nó sẽ xuất hiện thường xuyên và nhiều hơn theo tỉ lệ số lượng Product Owner của sản phẩm đó. Đơn giản, bạn có thêm Product Owner, nghĩa là có nhiều giá trị cần theo đuổi cùng lúc, nhiều giá trị cần theo đuổi đó luôn có những sự phụ thuộc lẫn nhau. Kết quả là bạn muốn đạt được nhiều giá trị hơn trong thời gian ngắn, thì bạn sẽ nhận được nhiều hơn sự phụ thuộc và phức tạp hơn.
​

Thường sẽ có việc thoả hiệp giữa các PO, dẫn đến lãng phí.

Thường khi có nhiều Product Owner cho một sản phẩm, và mỗi Product Owner lo một mảng nhất định của sản phẩm. Tính sở hữu lúc này bị chia nhỏ, và ít khi có được sự quan tâm toàn vẹn cho sản phẩm chung. Các Product Owner này bị giới hạn bởi mảng sản phẩm mà họ đang quản lý, và chỉ quan tâm đến thành công của mảng sản phẩm của mình. Hiện tượng này được gọi là “Silo” - suy nghĩ cục bộ. Lúc này để có được thành công cho mảng sản phẩm của mình, các Product Owner sẽ thường thoả hiệp để có được lợi ích tốt nhất cho phần của mình, và không ai quan tâm đến lợi ích chung của sản phẩm. Dần những bức tường ngăn cách sẽ lớn hơn, các Product Owner sẽ không hợp tác cho cái lợi chung, mà đa phần sẽ thoả hiệp cho lợi ích của mảng sản phẩm của mình. Điều này sẽ dẫn đến lãng phí như: dẫm chân nhau, hay vì lợi ích cục bộ mà xây dựng những thứ ảnh hưởng đến giá trị sản phẩm chung… Đây cũng là nguyên nhân cho vấn đề tiếp theo.
​

Dễ hướng tới các trò chơi chính trị, những buổi họp dài và mệt mỏi.

Một ảnh hưởng nặng nề hơn khi những “Silo” ngày một lớn, thì dễ dẫn đến văn hoá và cách làm việc không lành mạnh nữa. Mâu thuẫn lợi ích tăng ngày một cao, trong khi đó tính chia sẻ, hợp tác sẽ ít đi. Các Product Owner sẽ “làm sao cũng được” miễn mảng sản phẩm của “riêng” mình tốt. Mâu thuẫn xảy ra thường xuyên, liên tục giữa những Product Owner vì không thể tìm ra quan điểm chung. Sự mệt mỏi và chán chường sẽ tăng theo thời gian, và dần sẽ giết đi những nhiệt huyết ban đầu, muốn xây dựng sản phẩm tốt của những Product Owner này. Thành công chung của sản phẩm ngày càng xa rời. Kể cả lúc này, người được coi là "cấp trên" của những Product Owner đó có trách nhiệm cho việc hỗ trợ và kết nối giá trị chung của sản phẩm cũng không thể giúp thay đổi được tình cảnh này. Những buổi họp sản phẩm không thể giải quyết được vấn đề, và những mâu thuẫn cứ lặp lại như "căn bệnh thâm niên". Theo thời gian, đây là sự thật được chấp nhận ở những sản phẩm có nhiều Product Owner, họ sống chung và không ai buồn thay đổi hiện trạng. Họ gọi nó là “Chuyện bình thường ở huyện”.

Bạn nên nhớ rằng đây không phải là mong muốn của những Product Owner này. Nhưng chính việc có nhiều Product Owner cho một sản phẩm tạo ra những bất cập và hình thành văn hoá làm việc như trên. 
​

Kết Luận

Thay vì có quá nhiều Product Owner cho một sản phẩm, hãy đầu tư và xây dựng một người Product Owner có đủ khả năng và năng lực để tối ưu hoá giá trị sản phẩm. Việc có một Product Owner và hỗ trợ họ thử nghiệm, tối ưu hoá giá trị người dùng sẽ giúp bạn đi nhanh, xa, và không lãng phí tài nguyên vào những thứ không cần thiết. Một Product Owner giỏi giống như có được một mini CEO của sản phẩm của mình vậy. Vì người này sẽ là nhân tố giúp sản phẩm của bạn thành công.

Nếu bạn muốn biết làm thế nào để một Product Owner có thể tối ưu hoá giá trị sản phẩm có nhiều Scrum team đang làm việc cùng lúc, bạn có thể xem qua Nexus Framework. Đây là một Framework được xây dựng trên khung xương sống là Scrum, chính vì vậy nó gọn nhẹ và dễ dàng triển khai với những sản phẩm phức tạp, qua đó giúp sản phẩm đó vượt trội.

Ngoài ra nếu bạn muốn tìm hiểu làm thế nào một và chỉ một Product Owner có thể tối ưu hoá sản phẩm của mình? Bạn có thể tham khảo lớp học PSPO bên dưới: