Career & Non-TechYêu cầu đổi là chuyện bình thường; điều được đánh giá là bạn có biến thay đổi thành quyết định có kiểm soát hay chỉ than phiền.
Bốn việc nên nêu:
1. Ghi lại thay đổi ở nơi chính thức — cập nhật ticket, comment vào ticket, hoặc email xác nhận. Yêu cầu nói miệng ở hành lang mà không ghi lại là nguồn tranh cãi về sau.
2. Định lượng tác động — "thêm phần này thì task tăng khoảng 2 ngày và phải sửa cả phần thanh toán". Đưa con số để người quyết cân nhắc, đừng chỉ nói "khó lắm".
3. Đánh đổi rõ ràng — nếu thêm A vào sprint này thì B lùi lại. Để PM chọn, đừng tự nhận hết rồi trễ cả hai.
4. Thiết kế để dễ đổi — với vùng nghiệp vụ hay biến động, tách cấu hình ra khỏi mã cứng, dựng giao diện phía sau một lớp trừu tượng mỏng, tránh tối ưu sớm phần chưa chốt.
Ví dụ mẫu: "Ở dự án tính phí vận chuyển, quy tắc giá đổi ba lần trong hai sprint. Sau lần thứ hai em đề xuất đưa bảng quy tắc ra cấu hình trong DB thay vì viết cứng trong code. Từ đó mỗi lần đổi giá chỉ mất một lần cập nhật dữ liệu thay vì một lần phát hành."
Lỗi hay mắc:
- Nhận hết mọi thay đổi và im lặng làm thêm giờ — dẫn tới trễ toàn bộ sprint mà không ai biết.
- Từ chối cứng "đã chốt rồi không đổi" — nghe thiếu hợp tác, nhất là ở công ty làm outsourcing.
- Không ghi lại, tới lúc nghiệm thu thì hai bên nhớ khác nhau.
Điểm cộng: nói được ranh giới giữa làm rõ yêu cầu (miễn phí, nên khuyến khích) và thay đổi phạm vi (cần đánh giá lại thời gian), và ai là người có thẩm quyền chấp thuận.