Làm thế nào bạn handle tradeoff giữa tốc độ ship nhanh và chất lượng sản phẩm?

Có một framework tôi hay dùng: 'two-door test' của Amazon. Nếu quyết định có thể reverse dễ dàng (two-way door), thì prioritize speed — ship nhanh và học. Nếu quyết định khó reverse (one-way door), thì ưu tiên quality và dành thêm thời gian để think. Architecture decisions, security model, data schema — những cái này cần chậm lại.

Tôi dùng 'definition of shippable' thay vì 'definition of done': một feature shippable khi nó đúng với core use case và không gây regressions. Nó không cần hoàn hảo. Tôi track technical debt được cố tình accumulate và plan trả nợ rõ ràng trong sprint tiếp theo. Điều này tránh debt tích lũy vô thời hạn.