Bạn cân bằng giữa tốc độ và chất lượng dưới deadline như thế nào?

Question

Accepted Answer

Người phỏng vấn muốn một **sự đánh đổi có chủ đích, nhận biết được bối cảnh** — không phải kiểu giáo điều "luôn ship nhanh" hay "không bao giờ thỏa hiệp." Điểm mấu chốt là thực hiện sự đánh đổi đó *một cách có ý thức và công khai*.

## Cách tiếp cận

```text
1. Xác định phần chất lượng không thể thương lượng (tính đúng đắn, bảo mật, an toàn dữ liệu)
2. Tìm phần có thể hoãn lại (đánh bóng, các edge case, refactor)
3. Cắt phạm vi, không cắt chất lượng cốt lõi — ship ít hơn, không tệ hơn
4. Nói rõ ra mọi khoản nợ kỹ thuật và lên lịch trả nó
```

## Ví dụ minh họa

```text
S: Chúng tôi có ba ngày để launch một MVP cho một bản pilot với khách hàng.
T: Không thể có đủ bộ tính năng đầy đủ mà không gây rủi ro cho độ ổn định.
A: Tôi ship luồng chính (happy path) một cách chắc chắn, hoãn hai edge case sau
   một flag, và viết một ticket cho khoản nợ kèm ngày hẹn. Tôi báo cho khách
   hàng phần nào chỉ là bản xem trước.
R: Bản pilot launch đúng hạn và ổn định. Chúng tôi đóng các ticket đã hoãn vào
   sprint kế tiếp.
```

## Tốt và yếu

```text
✓ Đánh đổi có ý thức, nợ được theo dõi, cắt phạm vi
✗ Âm thầm ship code lỗi để kịp một ngày hẹn
✗ Từ chối nhân nhượng và bỏ lỡ deadline
```

## Tại sao điều này quan trọng

Tốc độ và chất lượng thường là một vấn đề về phạm vi đội lốt — cắt phạm vi bảo vệ cả hai.

Nói rõ ra khoản nợ kỹ thuật giữ cho các đường tắt trung thực, để chúng được trả lại thay vì bị lãng quên.

Biết phần *chất lượng nào* không thể thương lượng là một sự phán đoán đến cùng với kinh nghiệm — đó là thứ người phỏng vấn đang thăm dò.