Business Analyst (BA)Bắt đầu bằng giả định rằng phản đối có lý do, vì dev thường thấy trước ràng buộc mà tài liệu chưa nêu.
1. Nghe hết lý do và phân loại. Ba loại phản đối phổ biến:
- Kỹ thuật — làm được nhưng phá vỡ thiết kế hiện tại, gây rủi ro dữ liệu, hoặc chi phí bảo trì cao. Loại này thường đúng và cần điều chỉnh yêu cầu.
- Khối lượng — làm được nhưng không kịp trong sprint. Đây là vấn đề phạm vi và ưu tiên, không phải vấn đề đúng sai.
- Cách hiểu — dev đọc yêu cầu ra một nghĩa khác. Đây là lỗi ở khâu viết yêu cầu, cần sửa mô tả chứ không tranh luận.
2. Quay lại nhu cầu nghiệp vụ và lý do. Giải thích vì sao yêu cầu này tồn tại, ai bị ảnh hưởng nếu bỏ. Nhiều phản đối tan khi dev thấy được bối cảnh; và ngược lại, khi biết bối cảnh dev thường đề xuất được cách làm rẻ hơn đạt cùng mục tiêu.
3. Tách phần bắt buộc khỏi phần cách làm. Nếu điều bắt buộc là kết quả nghiệp vụ, còn cách triển khai thì linh hoạt, hãy nói rõ như vậy — nhiều xung đột đến từ chỗ yêu cầu vô tình mô tả sẵn giải pháp.
4. Đưa lên trên khi cần. Nếu vẫn không thống nhất và có ràng buộc nghiệp vụ hoặc pháp lý bắt buộc, đưa cùng lúc cho lead kỹ thuật và người có thẩm quyền nghiệp vụ, kèm đánh đổi của cả hai phương án.
Lưu ý: không dùng vị thế để ép ("khách hàng yêu cầu vậy"). Quan hệ làm việc với đội phát triển là tài sản dài hạn của một BA.