Bạn xử lý requirement thay đổi như thế nào?

Question

Accepted Answer

Requirement thay đổi — thị trường dịch chuyển, bạn học hỏi từ người dùng, ưu tiên thay đổi. Mục tiêu không phải là *ngăn chặn* thay đổi (điều đó vừa bất khả thi vừa không mong muốn) mà là xử lý nó một cách **có chủ đích** để nó cải thiện sản phẩm thay vì làm chệch hướng dự án.

## Đón nhận thay đổi, nhưng kiểm soát nó

```text
✓ MONG ĐỢI thay đổi → xây sự linh hoạt vào kế hoạch (đừng cam kết quá xa)
✓ ĐÁNH GIÁ từng thay đổi → tác động lên scope, timeline, chi phí, công việc khác
✓ Làm cho ĐÁNH ĐỔI rõ ràng → "được, nhưng nó tốn X hoặc đẩy Y"
✓ Để stakeholder QUYẾT ĐỊNH với đầy đủ thông tin
✓ TRUYỀN ĐẠT kế hoạch mới đến mọi người bị ảnh hưởng
```

Kỷ luật then chốt giống như quản lý scope: không bao giờ âm thầm hấp thụ một thay đổi. Mỗi thay đổi là một đánh đổi có ý thức mà ai đó sở hữu.

## Vì sao agile giúp ích

Agile được xây dựng cho requirement thay đổi: các vòng lặp ngắn nghĩa là bạn sắp xếp lại ưu tiên thường xuyên, nên một thay đổi chờ tối đa một sprint thay vì làm gián đoạn một kế hoạch dài cả năm. Làm việc theo các bước tăng nhỏ giới hạn lượng làm lại mà bất kỳ thay đổi đơn lẻ nào có thể gây ra.

## Phân biệt khám phá (discovery) với xáo trộn (churn)

```text
Thay đổi LÀNH MẠNH → học hỏi mới, hiểu vấn đề tốt hơn
Xáo trộn KHÔNG LÀNH MẠNH → do dự, mục tiêu không rõ, không ai sở hữu ưu tiên
```

Nếu requirement giằng co liên tục, vấn đề thực sự nằm ở thượng nguồn — mục tiêu mơ hồ hoặc ưu tiên yếu — và đó là cái cần sửa.

## Một ví dụ cụ thể

Giữa sprint, nghiên cứu người dùng tiết lộ rằng flow đã lên kế hoạch khiến người ta bối rối. Thay vì lao tới, bạn đánh giá: làm lại nó tốn ba ngày và đẩy một mục ưu tiên thấp hơn. Bạn trình bày sự đánh đổi đó, PM đồng ý, và bạn điều chỉnh — một thay đổi làm sản phẩm *tốt hơn*, được xử lý mà không có hỗn loạn.

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

Hoặc cứng nhắc từ chối mọi thay đổi (tung ra thứ bạn *biết* là sai) hoặc chấp nhận mọi thay đổi mà không đánh giá tác động (trượt tiến độ kinh niên và kiệt sức).

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

Khả năng thích nghi là một thế mạnh — phần mềm không thể thay đổi là phần mềm đang dần lỗi thời.

Xử lý thay đổi tốt (đánh giá, làm rõ đánh đổi, truyền đạt, làm theo bước tăng nhỏ) cho phép bạn luôn đáp ứng được thực tế mà không mất kiểm soát việc chuyển giao.