- vừa được xem lúc

Khi PO không hiểu kỹ thuật, dev hay bị “quăng bom”

0 0 5

Người đăng: Nguyen Hoang Linh B

Theo Viblo Asia

“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.”

Bình luận

Bài viết tương tự

- vừa được xem lúc

Các mô hình phát triển phần mềm

1. Định nghĩa. Mô hình phát triển phần mềm hay quy trình phát triển phần mềm xác định các pha/ giai đoạn trong xây dựng phần mềm. Có nhiều loại mô hình phát triển phần mềm khác nhau ví dụ như:.

0 0 115

- vừa được xem lúc

Scrum Vs. Kanban

Scrum Vs. Kanban. Scrum là gì. Kanban là gì.

0 0 31

- vừa được xem lúc

Tạo Kanban board và Burndown chart để quản lý công việc

1. Tìm hiểu Kanban board. 1.1.

0 0 122

- vừa được xem lúc

9 ý tưởng cho buổi Retrospective hiệu quả!

Với những bạn đang vận hành dự án theo Scrum hoặc ít nhất đang cố gắng thử vận hành, ắt hẳn biết đến một scrum event quan trọng - Retrospective. Một event để scrum team cùng nhìn nhận lại lại cách thức làm việc, hợp tác với nhau hay nói chung là các vấn đề về quy trình, con người trong dự án.

0 0 72

- vừa được xem lúc

Scrum là gì?

Làm trong ngành phát triển phần mềm, nói đến Scrum chắc hẳn phần lớn ai cũng một hình dung nhất định về Scrum. Tuy nhiên, mỗi người có thể có một góc nhìn, một cách hiểu khác nhau.

0 0 50

- vừa được xem lúc

Tổng quan về Agile - Scrum

Agile là gì? Scrum là gì? Agile và Scrum có liên quan gì đến nhau mà tại sao ai cũng nhắc hai cái tên này với nhau? Tất cả mọi thắc mắc về Agile và Scrum mọi người sẽ được giải đáp trong bài viết này.

0 0 77