“Làm cái này chắc đơn giản thôi mà?” – Một câu nói quen thuộc từ Product Owner (PO), và sau đó là... một quả bom full-stack được quăng vào sprint.
1. “Quăng bom” nghĩa là gì?
Trong môi trường Agile, có một hiện tượng phổ biến mà dân dev hay gọi đùa nhau là “bị quăng bom” – tức là:
Nhận một yêu cầu tưởng chừng “nhẹ nhàng”, nhưng khi bắt tay vào làm thì vỡ ra đủ thứ: migrate DB, refactor code, ảnh hưởng tới flow cũ, thậm chí cả UI/UX.
PO mô tả không đầy đủ, thiếu case, thiếu context kỹ thuật → dev làm xong thì QA “nổ tung”, hoặc product không như kỳ vọng.
Những yêu cầu “ẩn” không xuất hiện ở backlog nhưng lại được nhồi vào trong quá trình dev → gây overload và trượt deadline.
Khi các bên hiểu khác nhau về cùng một yêu cầu: Tình trạng “quăng bom” thường xảy ra khi PO không nắm được toàn bộ ngữ cảnh kỹ thuật, dẫn đến dev thực hiện sai hoặc bị quá tải.
2. Vì sao PO không hiểu kỹ thuật lại nguy hiểm?
Không phải PO nào cũng cần biết code. Nhưng thiếu hiểu biết về kỹ thuật mà vẫn quản lý backlog và viết user story thì sẽ dẫn đến một số hệ quả tiêu cực:
- Underestimate effort: tưởng mọi thứ chỉ là “thêm một cái nút”, nhưng phía sau là thêm API, sửa schema, điều chỉnh logic.
- Bỏ sót ràng buộc kỹ thuật: như rate limit, latency, quy tắc bảo mật, hiệu năng...
- Mâu thuẫn dev–PO: khi team dev feedback “cái này phức tạp lắm” nhưng PO cho là “các bạn làm quá lên”.
- Tệ hơn, team dần mất niềm tin và ngừng chia sẻ thật, chỉ nhận task và “cố làm cho xong”, gây hậu quả lâu dài cho sản phẩm.
3. PO cần hiểu kỹ thuật đến đâu?
Không cần biết code, nhưng một PO tốt nên hiểu “just enough” kỹ thuật để:
- Biết điều gì là khó/dễ, có risk gì không
Vai trò của PO trong Scrum: PO không cần code, nhưng cần hiểu luồng làm việc để giao tiếp hiệu quả với dev.
- Ước lượng độ phức tạp sơ bộ để không ép team chạy nước rút vô lý
- Hiểu khi nào nên hỏi lại team dev thay vì tự đưa giải pháp
- Tôn trọng constraint kỹ thuật, không vẽ tính năng “bằng giấy”
Ví dụ:
Hiểu API có rate limit → không đưa ra yêu cầu “hiển thị realtime” 1000 items.
Biết dev cần test, staging, rollback → không yêu cầu “hôm nay làm, mai live”.
4. Cách để giảm “quăng bom” trong team Agile
✅ PO tham gia refinement cùng dev/QA
Đừng viết story một chiều rồi assign, hãy ngồi cùng dev để:
- Cùng phân tích logic
- Xác định constraint kỹ thuật
- Ước lượng effort sơ bộ
⟶ Giúp PO hiểu được những “chi phí ẩn” mà trước giờ mình không thấy.
✅ Dev chủ động “dịch kỹ thuật sang business”
Dev cũng cần học cách nói chuyện với PO một cách dễ hiểu:
Thay vì: “cái này phải re-index Elasticsearch”
Hãy nói: “để làm được vậy, dữ liệu phải được tìm lại toàn bộ, tốn 3–5 giờ chạy batch”
⟶ Giúp PO hiểu lý do tại sao việc tưởng đơn giản lại phức tạp.
Khi PO và Dev không “nói chung một ngôn ngữ”: Giao tiếp kỹ thuật mập mờ khiến PO hiểu sai, dev làm sai, và sản phẩm lệch hướng.
✅ Có “Definition of Ready” rõ ràng
Trước khi một ticket vào sprint, hãy đảm bảo:
- Có thiết kế logic (hoặc flow chart đơn giản)
- Có xác định case đặc biệt, edge case
- Có mô tả rõ ràng về input/output
⟶ Giảm rủi ro story bị thiếu hoặc mơ hồ.
5. Kết
Sự hiểu biết kỹ thuật không phải là nhiệm vụ riêng của dev, cũng không phải là gánh nặng của PO. Nó là cây cầu cần cả hai bên cùng xây dựng, để tránh những quả “bom” không ai mong muốn trong sprint.
“Agile không chỉ là chia task đều, mà là chia sẻ hiểu biết để cùng làm đúng.”