Product Owner(PO)
Người chịu trách nhiệm tối đa hoá giá trị sản phẩm bằng cách quyết định thứ tự Product Backlog. Một người cụ thể, có quyền nói không, chứ không phải một hội đồng ký duyệt.
Định nghĩa
Trong Scrum Guide 2020, Product Owner là một trong ba accountability của Scrum Team, cùng với Scrum Master và Developers. Việc của PO gói trong một câu: làm sao để thứ team tạo ra có giá trị cao nhất với nguồn lực đang có. Cách PO làm việc đó là quyết định thứ tự Product Backlog, và giải thích cho cả team hiểu vì sao lại là thứ tự đó.
PO là người duy nhất được quyền đổi thứ tự Product Backlog. Ai muốn chen item lên đầu thì thuyết phục PO, đừng nhắn thẳng cho dev.
Quyền và trách nhiệm thật sự
Scrum Guide liệt kê bốn việc cho PO: xây dựng và diễn giải Product Goal, tạo và làm rõ các Product Backlog Item, sắp thứ tự backlog, và giữ cho backlog minh bạch với mọi người. PO có thể nhờ người khác làm hộ — BA viết user story chẳng hạn — nhưng người chịu trách nhiệm cuối vẫn là PO.
Hai chi tiết hay bị bỏ qua:
- PO phải là một người cụ thể, không phải một hội đồng. Ba trưởng phòng cùng ký duyệt backlog thì đó là ban dự án đội lốt Scrum.
- Quyết định của PO phải được tổ chức tôn trọng. Nếu giám đốc khối cứ nhảy vào ép chèn tính năng giữa sprint, chức PO chỉ còn là danh nghĩa trên slide.
So sánh PO, BA và Product Manager
Đây là chỗ gây tranh cãi nhiều nhất trên thị trường Việt Nam. Rất nhiều công ty ở đây gộp BA và PO làm một, tuyển "BA/PO" trong cùng một JD, và người ngồi ghế đó vừa viết spec, vừa ưu tiên backlog, vừa demo cho khách.
| Tiêu chí | Product Owner | Business Analyst | Product Manager |
|---|---|---|---|
| Câu hỏi chính | Làm gì trước, gì sau | Làm cụ thể ra sao | Làm sản phẩm gì, cho ai |
| Xuất xứ | Scrum Guide | BABOK, IIBA | Nghề product, không có chuẩn cứng |
| Đầu ra chính | Product Backlog có thứ tự, Product Goal | User story, acceptance criteria, sơ đồ quy trình | Chiến lược, định vị, giá, roadmap dài hạn |
| Phạm vi | Một Scrum Team, một sản phẩm | Có thể trải nhiều dự án, cả phần phi phần mềm | Cả vòng đời sản phẩm và thị trường |
| Quyết định cuối về scope | Có | Không, BA đề xuất | Có, ở tổ chức có PM |
Ở công ty outsourcing, PO thật thường nằm bên phía khách hàng, còn BA phía nhà thầu gánh gần hết phần phân tích. Vấn đề kinh điển: khách bận, một tuần trả lời một lần, backlog kẹt. Cách chữa quen thuộc là dựng một proxy PO bên nhà thầu. Chấp nhận được, miễn ai cũng biết proxy không có quyền quyết định cuối và phải chốt với PO thật trước Sprint Planning.
Ví dụ thực tế
Ba yêu cầu rơi vào backlog của một app đặt lịch khám trong cùng một tuần. Marketing muốn mã giảm giá cho chiến dịch tháng 9. Vận hành muốn màn hình xếp lịch bác sĩ. Còn tổng đài thì gửi kèm một con số: 31 cuộc gọi khiếu nại mỗi ngày, tất cả chỉ vì nút Hủy lịch nằm sâu ba lớp menu.
PO chọn sửa luồng hủy lịch trước. Lý do nêu ngay tại Sprint Planning: 31 cuộc gọi mỗi ngày gần bằng một nhân sự tổng đài toàn thời gian, trong khi sửa mất khoảng 3 ngày công. Mã giảm giá lùi sang sprint sau vì chiến dịch còn 6 tuần nữa. Quyết định đó đúng hay sai còn phải chờ số liệu sau khi release. Nhưng PO nói ra được lý do ngay tại chỗ, và cả phòng biết mình đang đứng ở đâu trong hàng đợi.
Lỗi hay gặp
- Xuất hiện ở Sprint Planning rồi biến mất. Dev hỏi acceptance criteria, nhắn Zalo ba ngày không ai trả lời.
- Nhận hết mọi yêu cầu, không từ chối cái nào. Backlog phình lên 400 item và chẳng item nào bị đóng — bãi rác có thứ tự.
- Viết luôn giải pháp kỹ thuật vào story: "tạo bảng tạm rồi chạy job đêm". Đó là phần việc của Developers.
- Và kiểu kinh điển nhất: nhầm "ưu tiên" với "cái nào sếp nhắc gần đây nhất".
Câu hay bị hỏi phỏng vấn
"Stakeholder ép thêm việc vào giữa sprint thì bạn xử lý sao?" Câu trả lời vừa an toàn vừa đúng chuẩn: Sprint Goal giữ nguyên, phạm vi bên trong có thể thương lượng lại giữa PO và Developers khi phát sinh hiểu biết mới; nếu việc mới thật sự làm Sprint Goal mất ý nghĩa thì PO có quyền hủy sprint. Nhưng đó là nút bấm khẩn cấp, một năm dùng một lần đã là nhiều.
