Bạn xử lý thế nào khi yêu cầu không rõ ràng?

Question

Accepted Answer

Sự mơ hồ là điều bình thường trong công việc thực tế. Họ muốn thấy bạn **chủ động giảm bớt sự không chắc chắn** thay vì đứng hình hoặc âm thầm phỏng đoán rồi xây sai thứ.

## Cách tiếp cận

```text
1. Đặt những câu hỏi làm thay đổi điều bạn sẽ xây
2. Tìm mục tiêu đằng sau yêu cầu (cái "why")
3. Nêu các giả định của bạn bằng văn bản và xác nhận chúng
4. Xây một lát mỏng, demo sớm, điều chỉnh nhanh
```

## Ví dụ minh họa

```text
S: Một ticket ghi "thêm một dashboard" mà không có chi tiết về các chỉ số hay
   người dùng.
T: Xây mù quáng có nguy cơ lãng phí hàng tuần công sức.
A: Tôi hỏi ai sẽ dùng nó và nó phục vụ cho quyết định nào, viết ra ba giả định,
   và xây trước một prototype bấm được của hai chỉ số quan trọng nhất.
R: Buổi demo làm lộ ra rằng họ thực sự cần tính năng export, không phải biểu đồ.
   Chúng tôi chuyển hướng sau hai ngày thay vì hai tuần.
```

## Tốt và yếu

```text
✓ Làm rõ cái "why", nêu các giả định, demo sớm
✗ Xây toàn bộ dựa trên một phỏng đoán
✗ Từ chối bắt đầu cho đến khi mọi thứ được đặc tả đầy đủ
```

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

Đặc tả rõ ràng là hiếm; những engineer phát triển mạnh là những người có thể di chuyển trong sương mù.

Tìm ra mục tiêu cốt lõi ngăn bạn xây đúng những gì được yêu cầu nhưng không phải thứ được cần đến.

Demo một lát mỏng từ sớm biến những phỏng đoán đắt đỏ thành những lần điều chỉnh rẻ và nhanh.