Bạn sequence và sắp xếp thứ tự dependencies trong một epic lớn như thế nào?

Khi một dependency bị delay, tôi ngay lập tức evaluate hai options: unblock bằng cách borrow resource từ team kia, hoặc resequence những work không phụ thuộc vào dependency đó để team không bị idle. Tôi thông báo ngay cho stakeholder về impact và revised timeline thay vì chờ đến review meeting.

Tôi dùng 'dependency inversion' khi có thể: thay vì team A phải chờ team B, tôi hỏi 'làm thế nào team A có thể proceed với mock/stub trong khi team B build real thing?' Kỹ thuật này phổ biến trong engineering nhưng ít được áp dụng ở product planning. Nó giúp unblock work sớm hơn rất nhiều.

Dependencies thường có hai loại: technical (cần API X trước khi build UI Y) và knowledge (cần research A trước khi design B). Technical dependencies rõ ràng và dễ spot. Knowledge dependencies ẩn và nguy hiểm hơn. Tôi hỏi team 'có quyết định nào chúng ta chưa có đủ thông tin để đưa ra không?' để surface những cái ẩn đó.

Tôi bắt đầu bằng cách vẽ dependency graph cho toàn epic: mỗi story là một node, mỗi dependency là một edge có hướng. Từ đó tôi xác định critical path — chuỗi stories dài nhất cần xong trước khi epic có thể release. Bất kỳ delay nào trên critical path đều delay entire epic, nên tôi focus risk management vào đây.