Product Owner là người chịu trách nhiệm tối đa hoá giá trị của sản phẩm do đội Scrum tạo ra, chủ yếu bằng cách quản lý Product Backlog: quyết định làm gì, theo thứ tự nào, và vì sao. Khi doanh nghiệp thuê một công ty phần mềm làm theo Scrum, vai trò này gần như luôn phải nằm ở phía doanh nghiệp, vì chỉ bên đặt hàng mới biết giá trị kinh doanh nằm ở đâu.
Đây là điểm nhiều doanh nghiệp chưa lường trước khi ký hợp đồng "làm agile". Họ nghĩ agile nghĩa là linh hoạt, có thể thay đổi yêu cầu bất cứ lúc nào, mà không nhận ra cái giá là phải cử một người có thẩm quyền làm việc cùng đội hằng tuần. Bài này giải thích vai trò Product Owner theo Scrum Guide, những gì người giữ vai trò làm trong mỗi chu kỳ, các mô hình chia vai trò với nhà cung cấp, và những sai lầm khiến dự án agile thuê ngoài trôi dạt.
Scrum trong một trang, từ góc bên đặt hàng
Scrum là một khung làm việc do Ken Schwaber và Jeff Sutherland phát triển từ đầu thập niên 1990, trình bày chính thức tại hội nghị OOPSLA năm 1995. Tài liệu chuẩn là Scrum Guide, bản đầu năm 2010 và bản cập nhật gần nhất tháng 11 năm 2020. Scrum chia công việc thành các sprint ngắn, thường hai đến bốn tuần, mỗi sprint tạo ra một phần sản phẩm có thể dùng được, gọi là Increment.
Đội Scrum có ba trách nhiệm: Product Owner quyết định làm gì; Developers quyết định làm thế nào và làm ra sản phẩm; Scrum Master giúp đội áp dụng Scrum hiệu quả và gỡ trở ngại. Bản 2020 cũng nhấn mạnh Product Goal, mục tiêu dài hạn của sản phẩm mà backlog hướng tới.
Với bên đặt hàng, điều quan trọng nhất cần hiểu là cơ chế phản hồi. Cuối mỗi sprint, bạn thấy phần mềm chạy thật, không phải báo cáo tiến độ phần trăm. Bạn có thể đổi ưu tiên cho sprint sau dựa trên những gì vừa thấy. Đây là lợi thế lớn so với mô hình thác nước, nơi bạn có thể chờ sáu tháng mới phát hiện hiểu lầm. Nhưng lợi thế đó chỉ thành hiện thực nếu phía bạn có người xem, đánh giá và quyết định đều đặn.
Hai khái niệm nữa nên biết trước khi ký hợp đồng. Định nghĩa hoàn thành (Definition of Done) là cam kết chất lượng áp cho mọi hạng mục: đã kiểm thử, đã rà soát mã, đã có tài liệu, triển khai được. Bên đặt hàng nên tham gia thống nhất định nghĩa này, vì nó quyết định "xong" nghĩa là gì khi trả tiền. Increment phải dùng được, không phải bản trình diễn dựng tạm; nếu cuối sprint đội chỉ cho xem màn hình tĩnh hoặc chạy trên máy lập trình viên, đó là tín hiệu cần hỏi lại.
Product Owner làm gì trong mỗi sprint
Theo Scrum Guide, Product Owner có thể giao bớt việc cho người khác nhưng vẫn chịu trách nhiệm. Công việc cụ thể trong một chu kỳ gồm:
- Lập kế hoạch sprint: trình bày mục tiêu và các mục ưu tiên cao nhất, trả lời câu hỏi để Developers chọn khối lượng phù hợp; cùng đội thống nhất mục tiêu sprint.
- Trong sprint: có mặt để trả lời câu hỏi nghiệp vụ trong ngày, không để đội chờ một tuần. Câu trả lời chậm là nguyên nhân hàng đầu khiến đội đoán, rồi làm lại.
- Làm mịn backlog: viết và làm rõ story cho các sprint tới, bổ sung tiêu chí chấp nhận, chia story lớn, cùng đội ước lượng sơ bộ.
- Sprint review: xem sản phẩm chạy thật, mời người dùng và bên liên quan, thu phản hồi, quyết định điều chỉnh backlog.
- Chấp nhận công việc: kiểm tra story đã xong theo tiêu chí chấp nhận và định nghĩa hoàn thành, từ chối nếu chưa đạt.
- Quản lý bên liên quan: gom yêu cầu từ các phòng ban, nói không với yêu cầu không phục vụ mục tiêu, giải thích lý do ưu tiên.
- Theo dõi giá trị và ngân sách: đo xem tính năng đã phát hành có được dùng không, chi phí đã tiêu so với giá trị nhận được.
Khối lượng việc này thường chiếm từ một nửa đến toàn bộ thời gian làm việc của một người với một đội phát triển cỡ năm đến chín người. Giao vai trò Product Owner cho một trưởng phòng vốn đã kín lịch là kịch bản thất bại thường gặp nhất.
Ba mô hình chia vai trò với nhà cung cấp
Khi thuê ngoài, câu hỏi thực tế là chia vai trò Product Owner thế nào giữa hai bên. Mỗi mô hình có đánh đổi:
| Mô hình | Mô tả | Ưu điểm | Rủi ro |
|---|---|---|---|
| Product Owner phía khách | Người của bạn giữ vai trò đầy đủ, nhà cung cấp cung cấp Developers và Scrum Master | Quyết định gần giá trị kinh doanh nhất | Đòi người có năng lực và thời gian, nhiều doanh nghiệp không có |
| Product Owner phía khách cộng chuyên viên phân tích phía nhà cung cấp | Bạn quyết định ưu tiên và chấp nhận; nhà cung cấp hỗ trợ viết story, tiêu chí | Giảm tải cho bạn, giữ quyền quyết định | Ranh giới trách nhiệm mờ nếu không thống nhất rõ |
| Product Owner đại diện phía nhà cung cấp | Người của nhà cung cấp quản lý backlog, bạn duyệt định kỳ | Ít tốn công của bạn | Xung đột lợi ích: người quyết định phạm vi cũng là bên được trả tiền theo công sức |
Mô hình thứ hai thường thực tế nhất với doanh nghiệp Việt Nam lần đầu làm agile thuê ngoài. Mô hình thứ ba chỉ nên dùng khi có cơ chế kiểm soát mạnh như trần ngân sách và rà soát giá trị hằng tháng, và khi quan hệ hai bên đã có độ tin cậy. Dù mô hình nào, quyền quyết định cuối cùng về ưu tiên và chấp nhận sản phẩm nên thuộc bên trả tiền.
Phẩm chất cần có ở người giữ vai trò
Thẩm quyền quyết định thật. Scrum Guide nhấn mạnh tổ chức phải tôn trọng quyết định của Product Owner. Nếu mỗi quyết định ưu tiên phải trình ba cấp duyệt, đội sẽ chờ, và vai trò chỉ còn là người chuyển lời.
Hiểu nghiệp vụ sâu. Biết quy trình, các ngoại lệ, nỗi đau của người dùng, và giá trị kinh doanh của từng thay đổi. Người từ phòng nghiệp vụ chuyển sang thường làm tốt hơn người CNTT thuần.
Biết nói không. Backlog luôn dài hơn ngân sách. Giá trị của Product Owner nằm ở những gì họ quyết định không làm, hoặc chưa làm, nhiều hơn những gì họ thêm vào.
Hiểu kỹ thuật vừa đủ. Không cần biết lập trình, nhưng cần hiểu khái niệm như nợ kỹ thuật, tích hợp, hiệu năng để cân nhắc khi đội đề xuất dành thời gian cho phần không nhìn thấy.
Có thời gian. Phẩm chất ít được nhắc nhất nhưng quyết định nhất. Một Product Owner giỏi mà chỉ có hai giờ mỗi tuần thì kém hơn một người trung bình dành trọn thời gian.
Những sai lầm thường gặp khi thuê ngoài theo Scrum
Các sai lầm dưới đây khiến dự án mang danh agile nhưng mất cả ưu điểm của agile lẫn sự chắc chắn của mô hình truyền thống:
- Không có Product Owner thật, chỉ có người nhận báo cáo; đội phát triển tự quyết ưu tiên.
- Product Owner là một uỷ ban: ba trưởng phòng cùng quyết, mỗi người kéo ưu tiên về phía mình.
- Bỏ sprint review hoặc chỉ xem slide; không ai bấm thử phần mềm thật.
- Đổi yêu cầu giữa sprint liên tục, coi linh hoạt là được thay đổi bất cứ lúc nào.
- Không có định nghĩa hoàn thành, nên story "xong" nhưng chưa kiểm thử, chưa tài liệu, chưa triển khai được.
- Đo tiến độ bằng số story hoặc điểm ước lượng thay vì giá trị kinh doanh và phần mềm dùng được.
- Ký hợp đồng trọn gói với phạm vi cố định rồi yêu cầu làm theo Scrum, khiến hai bên tranh cãi về mỗi thay đổi.
- Không phát hành cho người dùng thật trong nhiều tháng, tích luỹ phần mềm chưa ai kiểm chứng.
Sai lầm áp chót gắn với bài toán hợp đồng: Scrum hợp với mô hình theo thời gian và vật tư, đội chuyên trách hoặc ngân sách cố định với phạm vi linh hoạt. Ép Scrum vào hợp đồng phạm vi cố định thì một trong hai phải nhường.
Đo xem vai trò có hiệu quả không
Vài chỉ báo đơn giản giúp ban lãnh đạo biết Product Owner phía mình có đang làm tốt, mà không cần hiểu sâu Scrum. Thứ nhất, thời gian trả lời câu hỏi của đội: tính bằng giờ là tốt, tính bằng ngày là có vấn đề. Thứ hai, tỷ lệ story bị làm lại sau sprint review vì hiểu sai yêu cầu: cao và kéo dài nghĩa là khâu làm rõ yêu cầu đang yếu.
Thứ ba, tỷ lệ tính năng đã phát hành được người dùng thật sử dụng sau vài tuần. Nhiều tính năng được yêu cầu kịch liệt rồi không ai dùng; Product Owner giỏi đo điều này và dùng nó để từ chối yêu cầu tương tự sau này. Thứ tư, backlog có trật tự rõ không: mười mục đầu được mô tả kỹ, có tiêu chí chấp nhận, còn phần đuôi thô là bình thường; mọi thứ đều thô hoặc mọi thứ đều chi tiết đều là dấu hiệu lệch.
Cuối cùng, hỏi đội phát triển. Trong buổi rà soát cuối sprint, nhóm nên được hỏi điều gì cản trở họ. Nếu câu trả lời thường xuyên là chờ quyết định hoặc yêu cầu không rõ, vấn đề nằm ở phía bên đặt hàng chứ không phải ở nhà cung cấp, và sửa ở đó sẽ hiệu quả hơn mọi điều khoản phạt.
Câu hỏi thường gặp
Product Owner có phải là quản lý dự án không?
Không hoàn toàn. Quản lý dự án truyền thống điều phối phạm vi, tiến độ, chi phí, nguồn lực. Product Owner tập trung vào giá trị và thứ tự ưu tiên của sản phẩm, còn việc tổ chức công việc thuộc Developers và Scrum Master. Trong thực tế thuê ngoài, phía bên đặt hàng thường vẫn cần người theo dõi hợp đồng và ngân sách, có thể là cùng một người hoặc khác.
Có cần chứng chỉ Product Owner không?
Không bắt buộc. Các chứng chỉ phổ biến giúp người mới nắm khung Scrum và thuật ngữ, có ích khi làm việc với đội nhà cung cấp. Nhưng năng lực quyết định của vai trò này đến từ hiểu nghiệp vụ, thẩm quyền và kỹ năng ưu tiên, những thứ không đo được bằng bài thi. Một khoá học ngắn kèm người hướng dẫn có kinh nghiệm thường đủ.
Một Product Owner quản lý được mấy đội?
Scrum Guide quy định một sản phẩm có một Product Owner và một Product Backlog, dù nhiều đội cùng làm. Với một đội, vai trò đã chiếm phần lớn thời gian. Với hai ba đội, Product Owner thường cần người hỗ trợ viết và làm rõ story, nhưng vẫn giữ quyền quyết định ưu tiên chung.
Scrum Master nên ở phía nhà cung cấp hay phía khách hàng?
Thường ở phía nhà cung cấp, vì Scrum Master làm việc hằng ngày với Developers. Tuy nhiên Scrum Master cũng có trách nhiệm hỗ trợ Product Owner và tổ chức hiểu Scrum. Nếu doanh nghiệp lần đầu làm Scrum, thuê thêm một huấn luyện viên agile độc lập trong vài tháng đầu có thể giúp phía bạn học nhanh hơn.
Có nên dùng Scrum cho mọi dự án phần mềm thuê ngoài?
Không. Scrum hợp với sản phẩm có nhiều điều chưa biết và cần phản hồi sớm. Với dự án triển khai gói phần mềm có sẵn, chuyển đổi dữ liệu, hay nâng cấp hạ tầng có phạm vi rõ, cách làm theo kế hoạch tuần tự nhiều khi đơn giản và hiệu quả hơn. Chọn phương pháp theo mức bất định của bài toán, không theo trào lưu.
Khi Product Owner nghỉ việc giữa dự án thì làm sao giảm rủi ro?
Duy trì backlog và quyết định trong công cụ chung thay vì trong đầu một người; ghi lại lý do của các quyết định ưu tiên lớn; có một người dự phòng tham gia sprint review đều đặn. Khi cần thay, cho người mới làm cùng người cũ ít nhất một vài sprint nếu được. Thiếu những điều này, dự án thường chững lại nhiều tuần.