Những sai lầm Product Owner nên tránh

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.

5 sai lầm thường gặp của Product Owner

​Product Owner là người thống trị.

Đây là một trong những sai lầm mà tôi thường thấy nhất. Những Product Owner này sẽ có khuynh hướng ra lệnh và điều khiển Scrum Team làm theo ý của mình. Họ không lắng nghe những chia sẻ từ Scrum Team về những giải pháp, hay những rủi ro trong quyết định của mình. Mối quan tâm của họ là khi họ đưa ra yêu cầu thì Scrum Team phải làm được cái họ cần vào cuối Sprint. Tức là người PO này chỉ quan tâm và chia sẻ với Team về What (team phải hoàn thành được gì) mà không chia sẻ hay quan tâm về vì sao team lại cần hoàn thành những việc đó (Why).

Thường điều này hay xuất hiện khi một người có cấp bậc cao trong tổ chức (CxOs, Line manager... ) trở thành Product Owner mà chưa thay đổi được cách làm việc cũ của mình.

Kết quả của việc này thường là thiếu sự tương tác giữa Developers và Product Owner, Team không biết mình làm việc cho mục đích gì mà chỉ chịu áp lực phải làm theo những gì PO yêu cầu, dẫn đến việc thiếu lòng tin trong Team (lâu ngày sẽ hình thành việc Team không còn xem PO là một phần của Scrum Team nữa). Và những giá trị của sản phẩm được xây dựng thường là thiếu góc nhìn đa chiều (cái nhìn của các thành viên trong Scrum Team). Từ đó dẫn đến việc xây dựng sản phẩm cũng kém hiệu quả, thiếu chiến lược trong lúc triển khai và thường giảm đi chất lượng sản phẩm. Người Product Owner giỏi không chỉ là người biết cách tham gia cùng Scrum Team là một phần của team, lắng nghe và thu thập những chia sẻ và ý tưởng, cùng nhau xây dựng giá trị của sản phẩm, mà còn phải là người dẫn dắt Scrum Team bằng tầm nhìn của sản phẩm, qua đó tạo động lực cho Team phát triển.

Product Owner không quản lý được các Stakeholders.

Đây là một vấn đề thường gặp khác khi Scrum Team có một người PO thường không thể nói “không” với các mong muốn của các Stakeholders. Dẫn đến thay vì Scrum Team tập trung để xây dựng giá trị sản phẩm cho người dùng để mang lại outcome, thì lại phải chạy theo những nhu cầu không thực sự cần thiết cho sản phẩm. Điều này thường đặt Scrum Team vào tình huống luôn bị áp lực về phải làm nhiều hơn trong một Sprint, hoặc có quá nhiều thay đổi đưa thêm vào trong Sprint, dẫn đến việc nhóm không thể tập trung vào Sprint Goal.

Có rất nhiều lý do dẫn đến việc này:

• Product Owner đang thiếu khả năng quản lý các Stakeholders. Không biết nói “không”. (bạn phải hiểu nói “không” ở đây là nghệ thuật, không phải là một cách đóng cửa và từ chối một cách vô lý.)
• Product Owner đang không được tôn trọng đúng vai trò của mình, mà chỉ được xem như một người chuyển giao thông tin, hay nhận yêu cầu từ một người hay nhóm có quyền quyết định cao hơn.
• Product Owner không biết, hoặc không hiểu cách làm sao để hiểu được khách hàng, và xây dựng sản phẩm mang lại giá trị người dùng, dẫn đến dễ bị ảnh hưởng và thiếu định hướng về chiến lược.

Product Owner quá bận rộn.

Tôi thường thấy điều này xảy ra với các nhóm có PO phải làm nhiều vai trò cùng lúc, hoặc phải làm việc với nhiều sản phẩm cùng lúc. Dẫn đến việc những PO này thường không có đủ thời gian cho Scrum Team hoặc cho sản phẩm. Kết quả rõ ràng nhóm thường sẽ mất kết nối, và khó khăn trong việc xây dựng sản phẩm. Dĩ nhiên chất lượng công việc mà Product Owner mang lại cũng không thể tốt được.

Lý do của việc này thường đến từ rất nhiều nguyên nhân:

• Công ty chưa hiểu và thực sự coi trọng vai trò Product Owner, nên đã thiếu đầu tư cho một vai trò Product Owner riêng biệt, mà đã để một cá nhân kiêm nhiệm nhiều vai trò.
• Product Owner dành quá nhiều thời gian với khách hàng và các Stakeholders, những lại không dành thời gian cho Scrum Team.

Lẫn lộn vai trò Product Owner và Scrum Master:

Nghe có vẻ buồn cười vì bạn sẽ nghĩ làm sao mà có thể lẫn lộn. Nhưng tôi chia sẻ điều này vì nó là điều hay diễn ra nhất. Tôi đã từng thấy nhiều Product Owner đã dẫm chân lên vai trò của Scrum Master, trong tất cả event của Scrum team, người Product Owner này đóng cả vai trò điều phối cuộc họp, và cũng là người nói nên tiếng nói của sản phẩm. Bạn sẽ hiểu vì sao Product Owner không nên đóng vai của Scrum Master qua video này (video này được tạo trước khi bản Scrum guide 2020 phát hành, nên tôi vẫn nói Developer = Development team, các bạn khi xem hiểu rằng Development team = Developer, ngoài ta không có gì khác với bản Scrum Guide 2020 cả):

​Lý do:

• Cũng như lý do của vấn đề “PO quá bận”: thường thấy rằng tổ chức chưa xem trọng và hiểu rõ vai trò Product Owner và Scrum Master. Nên thường có xu hướng đem hai vai trò này nhập làm một.
• Bản thân của PO không nhận thức được rõ vai trò và trách nhiệm của mình, chưa hiểu được Scrum. Nên dẫn đến việc dẫm chân, và lẫn lộn.

Product Owner nghĩ Scrum Master là Project manager.

Vấn đề này có mối liên quan đến những sai lầm ở trên. Nhưng tôi thấy nó xảy ra quá thường xuyên và mang đến nhiều tai hại. Nên tôi muốn viết nó ra ở đây riêng. Thường bạn sẽ thấy PO sẽ thường đưa yêu cầu "xuống dưới" và mong muốn cho một vài Sprint sắp tới (PO này thường sẽ có cấp bậc và quyền hạn cao trong tổ chức), sau đó Scrum Master có trách nhiệm lên kế hoạch và giám sát Developer để hoàn thành công việc đúng thời gian, và yêu cầu?!

Vấn đề này thưởng xảy ra nếu Product Owner thiếu hiểu biết về Scrum, và Scrum Master cũng đã không đủ khả năng để chia sẻ và hướng dẫn Product Owner cũng như tổ chức hiểu đúng về Scrum và giá trị của nó. Dẫn đến, dù rằng áp dụng Scrum trên danh nghĩa, nhưng lại hiểu sai và mang tư duy kiểu cũ vào những vai trò trong Scrum?!

Bạn sẽ gặp nó trong những tổ chức cố gắng áp dụng Scrum, nhưng vẫn không thay đổi cách làm việc truyền thống của mình, khi mà PO nghĩ mình có cấp bậc cao trong công ty/ tổ chức (liên quan đến điều đầu tiên trong bài viết này).

Tôi nhấn mạnh, đây không phải là Scrum, và trong Scrum Team không có vai trò của Project Manager. Vai trò của Product Owner và Scrum Master đã được ghi và thể hiện rất rõ trong Scrum Guide. Việc cố gắng áp dụng Scrum nhưng lại hiểu sai, và giữ những cách vận hành cũ, không phù hợp, sẽ khiến nhóm của bạn không chỉ không nhận được giá trị nào từ Scrum mang lại mà còn khiến bạn gặp nhiều những vấn đề khó khăn hơn.

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
​

• Scrum Guide 2020

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
​
Scrum Guide 2020

--------

PS: Một Product Owner có thể đang có một hoặc nhiều sai lầm được liệt kê ở trên cùng lúc. Nhưng kết quả dẫn đến chỉ có một:

• Không có sự tin tưởng trong Scrum Team.
• Giá trị sản phẩm dành cho người dùng ngày càng thấp.
• Chất lượng sản phẩm đi xuống.
• Sự áp lực, và không hài lòng giữa các thành viên trong Scrum Team và các bên liên quan ngày càng gia tăng.

Chính vì vậy, việc hiểu rõ Scrum và các giá trị mà Scrum mang lại có phải là điều mà tổ chức bạn đang cần hay không là rất quan trọng. Bạn cần phải trả lời được điều này trước khi quyết định áp dụng Scrum vào nhóm hay tổ chức, qua đó có sự đầu tư đúng cho Scrum Team của mình (về kiến thức cũng như sự hỗ trợ cần thiết), để tránh những hiểu lầm như trên.

Scrum on!
​