Mở đầu — vì sao bài này quan trọng
Trong hành trình ôn thi PSPO I, bạn sẽ gặp rất nhiều câu hỏi xoay quanh ranh giới quyền hạn giữa Product Owner (PO) và Developers. Đề thi của Scrum.org cực kỳ thích "gài bẫy" ở đúng điểm này: liệu PO có được quyền giao việc cụ thể cho từng lập trình viên không? PO có được quyết định bao nhiêu item sẽ đưa vào Sprint không? PO có được ép Developers cam kết một deadline cứng không? Nếu bạn trả lời theo bản năng quản lý kiểu truyền thống ("sếp giao việc, nhân viên làm"), bạn sẽ sai gần hết.
Lý do là Scrum xây dựng trên một nguyên tắc rất rõ ràng: PO làm rõ (clarify) CÁI GÌ và TẠI SAO, còn Developers quyết định LÀM NHƯ THẾ NÀO. Đây không chỉ là một mẹo thi. Đây là bản chất của một Scrum Team tự quản (self-managing). Khi một PO hiểu và sống đúng nguyên tắc này, mối quan hệ với Developers chuyển từ kiểu "sếp – lính" sang kiểu "đối tác cùng tạo giá trị". Năng suất tăng, chất lượng tăng, và quan trọng nhất với một sản phẩm: giá trị mang lại cho khách hàng tăng.
Bài này tập trung hoàn toàn vào một câu hỏi tưởng đơn giản nhưng vô cùng sâu: PO nên tương tác với Developers như thế nào trong và ngoài Sprint? Chúng ta sẽ phân định rạch ròi đâu là việc của PO, đâu là việc của Developers, và làm sao để bạn "có mặt khi cần" mà không "chỉ tay năm ngón". Đây cũng là chủ đề rất hay xuất hiện trong đề thi dưới dạng tình huống.
Khái niệm cốt lõi
Nguyên tắc nền tảng: Clarify, don't dictate
Hãy ghi nhớ một câu thần chú: "PO làm rõ, không ra lệnh." Trong tiếng Anh là clarify, don't dictate.
- Clarify (làm rõ): PO giải thích vấn đề khách hàng, ngữ cảnh kinh doanh, kết quả mong muốn (outcome), và các acceptance criteria. Khi Developers hỏi "tại sao tính năng này quan trọng?" hay "người dùng thực sự cần gì?", PO là người trả lời.
- Dictate (ra lệnh): PO áp đặt giải pháp kỹ thuật, ép buộc cách triển khai, chỉ định ai làm việc gì, hoặc ấn định khối lượng công việc trong Sprint. Đây là điều PO không được làm.
Phân chia trách nhiệm theo Scrum Guide 2020
Theo Scrum Guide 2020, Developers là những người cam kết tạo ra bất kỳ khía cạnh nào của một Increment có thể dùng được trong mỗi Sprint. Một trong những trách nhiệm cốt lõi của họ là "creating a plan for the Sprint, the Sprint Backlog" — tức là chính Developers tạo ra kế hoạch Sprint, không phải PO.
Điều này dẫn tới những hệ quả mà đề thi PSPO I rất hay kiểm tra:
| Quyết định | Ai có tiếng nói cuối cùng |
|---|---|
| Ưu tiên/thứ tự Product Backlog | Product Owner |
| Mục tiêu sản phẩm (Product Goal) | Product Owner |
| Item nào "cái gì" cần làm | Product Owner (qua ordering) |
| Bao nhiêu item lấy vào Sprint | Developers (PO không ép số lượng) |
| Cách thiết kế kỹ thuật, kiến trúc | Developers |
| Phân chia công việc nội bộ team | Developers (không ai gán việc) |
| Ước lượng (sizing) | Developers |
| Định nghĩa "đủ chất lượng" (DoD) | Cả team, không phải PO áp đặt một mình |
"Available, not absent" — PO phải sẵn sàng trong Sprint
Một hiểu lầm tai hại của nhiều PO mới: nghĩ rằng "đã giao backlog xong là việc của tôi hết, giờ để Developers tự làm". Sai. Trong suốt Sprint, PO phải sẵn sàng (available) để trả lời câu hỏi, làm rõ yêu cầu, ra quyết định nhanh về phạm vi khi tình huống thực tế phát sinh.
Developers thường xuyên gặp những câu hỏi như: "Khi người dùng nhập sai định dạng email thì hiển thị thông báo thế nào?", "Trường hợp khách hàng chưa thanh toán thì luồng này đi đâu?". Nếu PO "biến mất", Developers buộc phải tự đoán ý đồ — và đoán sai nghĩa là làm lại, lãng phí cả Sprint. Một PO tốt là người có thể tiếp cận được, phản hồi nhanh, và ra quyết định dứt khoát về WHAT/WHY khi được hỏi.
Nhưng "available" không có nghĩa là "ngồi cạnh chỉ đạo từng dòng code". Đây là điểm tinh tế: bạn có mặt để làm rõ, không phải để giám sát cách làm.
Quan hệ hai chiều: Developers cũng đóng góp vào WHAT
Một điểm nâng cao mà PO senior cần hiểu: ranh giới WHAT/HOW không phải bức tường bê tông. Developers — với hiểu biết kỹ thuật — thường phát hiện ra rằng một cách tiếp cận khác sẽ mang lại giá trị tương đương với chi phí thấp hơn nhiều. Ví dụ, Developers có thể nói: "Thay vì xây cả hệ thống gợi ý phức tạp như anh mô tả, ta dùng một bộ lọc đơn giản trước, ship trong 1 Sprint, đo phản hồi người dùng rồi mới đầu tư tiếp." Đây là Developers đóng góp ngược vào WHAT thông qua hiểu biết về HOW.
Một PO khôn ngoan lắng nghe những đề xuất này thay vì khăng khăng "tôi đã quyết rồi". Sự cộng tác (collaboration) hai chiều này chính là tinh thần của Scrum: cùng nhau tối đa hóa giá trị, chứ không phải PO "phát lệnh" còn Developers "thi hành".
Tình huống thực tế
Tình huống 1: PO ép giải pháp kỹ thuật tại Tiki
Tại một nhóm phát triển tính năng "giỏ hàng thông minh" ở một sàn thương mại điện tử lớn như Tiki, anh Minh — một PO mới chuyển từ vị trí Project Manager — quen kiểu giao việc cũ. Trong buổi Sprint Planning, anh không chỉ nói "chúng ta cần tính năng gợi ý sản phẩm mua kèm để tăng giá trị đơn hàng trung bình (AOV) thêm 8%", mà còn vẽ luôn sơ đồ database, chỉ định dùng Redis cache, và phân công: "Bạn Hùng làm backend, bạn Lan làm frontend, xong trong 6 ngày."
Hậu quả: Developers cảm thấy mình chỉ là "thợ code theo bản vẽ". Họ phát hiện thiết kế Redis của anh Minh không phù hợp với khối lượng dữ liệu thực tế nhưng ngại nói ra vì "sếp đã quyết". Cuối Sprint, tính năng chạy chậm, phải làm lại gần như từ đầu ở Sprint sau. AOV không nhúc nhích vì giải pháp ép buộc không tối ưu.
Diễn giải: Anh Minh đã dictate phần HOW (kiến trúc, công cụ, phân công) thay vì clarify phần WHAT/WHY (mục tiêu tăng AOV, hành vi người dùng). Anh cũng đã quyết "xong trong 6 ngày" — một dạng ép cam kết khối lượng thuộc thẩm quyền Developers.
Bài học: Nếu anh Minh chỉ làm rõ "chúng ta muốn người dùng thấy gợi ý mua kèm liên quan, để AOV tăng 8%; đây là dữ liệu hành vi người dùng" rồi để Developers tự thiết kế, họ sẽ chọn được giải pháp phù hợp với hệ thống thực tế và cảm thấy có trách nhiệm với kết quả.
Tình huống 2: PO "biến mất" tại một startup fintech ở TP.HCM
Chị Trang là PO của một startup ví điện tử với team 5 Developers. Sau Sprint Planning, chị giao backlog rồi tập trung toàn thời gian vào họp với nhà đầu tư và đối tác ngân hàng, gần như không trả lời tin nhắn của team trong 5 ngày.
Đến giữa Sprint, Developers gặp tình huống: với giao dịch hoàn tiền (refund), nếu người dùng đã rút tiền khỏi ví thì xử lý thế nào? Đây là quyết định về WHAT/WHY thuộc PO. Không liên lạc được chị Trang, Developers tự quyết định "khóa giao dịch và báo lỗi". Đến Sprint Review, chị Trang mới phát hiện logic này khiến trải nghiệm khách hàng tệ — đúng ra cần cho phép hoàn một phần. Cả luồng phải làm lại, trễ một phiên bản phát hành ra thị trường gần hai tuần.
Diễn giải: Chị Trang đã hiểu sai chữ "trao quyền". Trao quyền HOW cho Developers không có nghĩa là PO bỏ mặc các quyết định WHAT/WHY. Chị đã không available khi team cần làm rõ.
Bài học: PO phải duy trì kênh phản hồi nhanh trong Sprint — dù chỉ 15 phút mỗi ngày để giải đáp thắc mắc. Một quyết định làm rõ kịp thời trong 5 phút có thể tiết kiệm cả tuần làm lại. Nhiều team áp dụng nguyên tắc "PO phản hồi câu hỏi WHAT/WHY trong vòng nửa ngày làm việc".
Tình huống 3: Cộng tác đúng cách tại một team logistics ở Singapore
Tại một công ty công nghệ logistics ở Singapore, anh David là PO của team xây tính năng theo dõi đơn hàng thời gian thực. Trong Sprint Planning, anh chỉ trình bày: "Khách hàng doanh nghiệp phàn nàn họ không biết hàng đang ở đâu, dẫn tới 30% cuộc gọi chăm sóc khách hàng chỉ để hỏi vị trí đơn. Mục tiêu: cho khách tự xem vị trí, giảm 30% cuộc gọi đó."
Anh David không nói một chữ nào về công nghệ. Developers thảo luận và đề xuất: thay vì tích hợp GPS thời gian thực phức tạp (mất 3 Sprint), giai đoạn đầu chỉ hiển thị trạng thái theo các mốc (đã lấy hàng, đang vận chuyển, sắp giao) — đủ giải quyết 80% nhu cầu, ship trong 1 Sprint. Anh David lắng nghe, thấy hợp lý về mặt giá trị, và đồng ý. Khi Developers hỏi "trạng thái nào hiển thị cho khách doanh nghiệp, trạng thái nào ẩn?", anh trả lời ngay vì đó là WHAT.
Kết quả: tính năng ra mắt sau 1 Sprint, cuộc gọi hỏi vị trí giảm 26% ngay tháng đầu. Team đo phản hồi rồi mới đầu tư vào GPS thời gian thực ở giai đoạn sau.
Diễn giải: Anh David clarify WHAT/WHY xuất sắc, để Developers tự quyết HOW, và lắng nghe khi họ đóng góp ngược vào WHAT bằng hiểu biết kỹ thuật.
Bài học: Mối quan hệ PO–Developers lành mạnh là một cuộc đối thoại hai chiều, nơi PO giữ vững trách nhiệm về giá trị nhưng tôn trọng chuyên môn kỹ thuật của Developers.
Hướng dẫn từng bước
Dưới đây là cách xây dựng và duy trì mối quan hệ PO–Developers lành mạnh:
- Chuẩn bị WHAT và WHY thật rõ trước mỗi buổi làm việc. Trước Sprint Planning và refinement, đảm bảo mỗi item quan trọng đều có vấn đề khách hàng, kết quả mong muốn, và acceptance criteria rõ ràng. Đây là "nguyên liệu" để Developers tự quyết HOW.
- Trong Sprint Planning, trình bày giá trị — không trình bày giải pháp. Nói về vấn đề và outcome. Khi Developers hỏi về kỹ thuật, đừng vội đưa giải pháp; hãy hỏi lại "các bạn nghĩ cách nào tốt nhất?".
- Để Developers quyết định khối lượng Sprint. Bạn có thể nói "tôi mong muốn 3 item đầu được làm vì giá trị cao nhất", nhưng việc lấy bao nhiêu vào Sprint là quyết định của Developers dựa trên năng lực thực tế.
- Cam kết "available" trong suốt Sprint. Thông báo rõ kênh và thời gian phản hồi (ví dụ: "tôi luôn trả lời câu hỏi về yêu cầu trong nửa ngày làm việc"). Tham dự Sprint khi được mời để làm rõ, nhưng không can thiệp Daily Scrum như một buổi báo cáo.
- Tách bạch khi trả lời câu hỏi. Mỗi khi Developers hỏi, tự hỏi: "Đây là câu hỏi WHAT/WHY (tôi trả lời) hay HOW (họ tự quyết)?". Nếu là HOW, hãy trao lại cho team.
- Lắng nghe đề xuất kỹ thuật ảnh hưởng đến phạm vi. Khi Developers đề xuất một cách làm rẻ hơn/nhanh hơn đạt cùng giá trị, hãy đánh giá nghiêm túc và sẵn sàng điều chỉnh WHAT.
- Đưa phản hồi qua Increment, không qua chỉ đạo cách code. Khi xem Increment, nếu chưa đúng, hãy nói rõ kết quả nào chưa đạt (WHAT), để Developers tự điều chỉnh cách làm (HOW).
Lỗi thường gặp & mẹo
Lỗi 1 — PO gán việc cho từng cá nhân. "Bạn A làm phần này, bạn B làm phần kia." Sai. Developers tự tổ chức công việc nội bộ. Mẹo: Chỉ nói về cái gì cần đạt, để team tự chia.
Lỗi 2 — PO ép số lượng item hoặc deadline cứng vào Sprint. Đề thi PSPO I rất hay gài câu này. Mẹo: Nhớ rằng Developers quyết định bao nhiêu việc đưa vào Sprint; PO ảnh hưởng qua ordering và giải thích giá trị.
Lỗi 3 — PO áp đặt giải pháp kỹ thuật. Vẽ database, chọn framework, quyết kiến trúc. Mẹo: HOW thuộc Developers. Nếu bạn có ý tưởng kỹ thuật, hãy nêu như một gợi ý để thảo luận, không phải mệnh lệnh.
Lỗi 4 — PO biến mất trong Sprint. Giao backlog xong rồi mất hút. Mẹo: "Available, not absent." Cam kết một thời gian phản hồi rõ ràng.
Lỗi 5 — PO can thiệp Daily Scrum như sếp kiểm tra tiến độ. Daily Scrum là sự kiện của Developers (xem Bài 18). Mẹo: Nếu tham dự, bạn chỉ quan sát/làm rõ khi được hỏi, không biến nó thành buổi báo cáo cho PO.
Lỗi 6 — Hiểu "trao quyền HOW" thành "PO không cần quan tâm gì nữa". Mẹo: Trao quyền HOW nhưng giữ chặt trách nhiệm WHAT/WHY và luôn sẵn sàng làm rõ.
Mẹo thi cử: Khi gặp câu hỏi tình huống về quan hệ PO–Developers, hãy loại ngay các đáp án có động từ mang tính ra lệnh ("PO assigns", "PO decides how", "PO tells developers to..."). Đáp án đúng thường chứa các từ như clarify, collaborate, available, the Developers decide.
Bài tập thực hành
- Phân loại câu hỏi. Với mỗi tình huống sau, xác định đó là WHAT/WHY (PO trả lời) hay HOW (Developers quyết): (a) "Nên dùng PostgreSQL hay MongoDB cho tính năng này?"; (b) "Người dùng chưa đăng nhập thì có thấy giá khuyến mãi không?"; (c) "Chia tính năng này thành mấy task?"; (d) "Tại sao tính năng giỏ hàng lại ưu tiên cao hơn tính năng đánh giá sản phẩm?". (Gợi ý đáp án: a-HOW, b-WHAT, c-HOW, d-WHY)
- Viết lại câu chỉ đạo. Cho câu PO sai: "Bạn Hùng làm API thanh toán dùng Stripe, xong trước thứ Sáu." Hãy viết lại theo tinh thần clarify, don't dictate.
- Tự đánh giá tính sẵn sàng. Trong 1 Sprint gần nhất (hoặc dự án bạn đang làm), Developers mất trung bình bao lâu để nhận được câu trả lời từ PO khi có thắc mắc về yêu cầu? Đặt mục tiêu cải thiện và viết ra một cam kết phản hồi cụ thể.
- Đóng vai. Nhờ một đồng nghiệp đóng vai Developer đặt 5 câu hỏi trộn lẫn WHAT và HOW. Luyện phản xạ: trả lời WHAT/WHY và trao lại HOW cho người hỏi bằng câu "theo các bạn thì cách nào hợp lý nhất?".
Tóm tắt
- Nguyên tắc cốt lõi: PO clarify WHAT và WHY; Developers decide HOW. Hãy thuộc câu thần chú "clarify, don't dictate".
- Developers tự tạo Sprint Backlog, tự quyết bao nhiêu item vào Sprint, tự chia việc nội bộ, tự chọn giải pháp kỹ thuật và ước lượng. PO không gán việc, không ép số lượng, không áp đặt kiến trúc.
- PO phải available, not absent — luôn sẵn sàng làm rõ yêu cầu và ra quyết định về phạm vi trong suốt Sprint. Một câu trả lời kịp thời tiết kiệm cả tuần làm lại.
- Quan hệ là đối thoại hai chiều: PO lắng nghe khi Developers dùng hiểu biết kỹ thuật đề xuất cách đạt cùng giá trị với chi phí thấp hơn.
- Trong đề thi PSPO I, loại bỏ các đáp án mang tính ra lệnh; chọn đáp án thể hiện sự cộng tác, làm rõ và tôn trọng quyền tự quản của Developers.