Bạn thu thập và làm rõ requirement như thế nào?

Question

Accepted Answer

**Thu thập requirement (requirements gathering)** là quá trình tìm hiểu xem thực sự cần xây dựng cái gì — và *tại sao* — trước khi xây dựng nó. Sai lầm lớn nhất mà người mới mắc phải là hiểu một yêu cầu theo nghĩa đen mà không hiểu vấn đề cốt lõi bên dưới.

## Cách tiếp cận

```text
1. HỎI TẠI SAO → hiểu vấn đề đằng sau yêu cầu, không chỉ bản thân yêu cầu
2. TRÒ CHUYỆN với người dùng / stakeholder thực sự, không chỉ người yêu cầu
3. LÀM RÕ scope → cái gì trong, cái gì ngoài, "hoàn thành" trông như thế nào
4. ĐƯA RA những giả định và ràng buộc (deadline, ngân sách, giới hạn kỹ thuật)
5. VIẾT NÓ RA → xác nhận lại sự hiểu biết của bạn với họ
```

## Phân biệt yêu cầu với nhu cầu

Một stakeholder nói "thêm một nút export-to-PDF". Nhu cầu thực sự có thể là "tôi cần chia sẻ báo cáo với sếp của tôi". Email, một đường link chia sẻ, hoặc một dashboard có thể giải quyết tốt hơn. Hỏi *tại sao* mở ra những giải pháp tốt hơn.

## Những câu hỏi làm rõ tốt

```text
✓ "Cái này giải quyết vấn đề gì cho người dùng?"
✓ "Hôm nay khi không có nó thì chuyện gì xảy ra?"
✓ "Chúng ta sẽ biết nó hiệu quả bằng cách nào?"
✓ "Cái gì rõ ràng nằm ngoài scope?"
✓ "Các edge case là gì / điều gì có thể sai?"
```

## Một cạm bẫy phổ biến

Giả định rằng bạn đã hiểu rồi bắt tay vào xây dựng. Luôn phản chiếu lại requirement — "vậy điều anh cần là X, trước Y, và Z nằm ngoài scope?" — để bắt sớm các khoảng trống.

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

Một sai lầm về requirement được sửa ở giai đoạn ý tưởng tốn vài phút; cũng sai lầm đó được phát hiện sau khi phát hành tốn nhiều ngày hoặc nhiều tuần làm lại.

Requirement rõ ràng là bảo hiểm rẻ nhất chống lại việc xây dựng sai thứ.

Hỏi *tại sao* biến bạn từ một người nhận lệnh thành một người giải quyết vấn đề.