#productmanagement

Developer ngày nay – đặc biệt trong kỷ nguyên vibe coding – phải kiêm BA. Không phải vì được thăng chức. Mà vì nếu không biết phân tích yêu cầu, viết user story, xác định acceptance criteria, bạn sẽ build nhanh nhưng build sai. Kỹ năng BA không phải của BA nữa – nó là kỹ năng sống còn của developer hiện đại. Hãy để tôi kể bạn nghe sprint đó. Ông dev của tôi – một anh senior rất giỏi, code sạch, tốc độ nhanh – sprint 3 tuần làm xong cái feature mà anh ấy gọi là "hoàn hảo". Đúng spec. Đúng deadline. Test pass 100%. Anh ấy demo với vẻ mặt rất tự hào. Khách hàng ngồi im lặng một lúc. Rồi nói: "Cảm ơn anh, nhưng... đây không phải thứ chúng tôi cần." Không phải lỗi của anh. Không phải khách hàng thay đổi ý kiến giữa chừng. Mà ngay từ đầu, cái yêu cầu ban đầu – "tôi muốn xem báo cáo doanh thu theo ngày" – đã bị hiểu sai hoàn toàn. Khách hàng muốn xem doanh thu thực thu, sau khi đã trừ refund và discount. Dev của tôi build báo cáo doanh thu gộp. Ba tuần. Sai ngay từ từ đầu. Tôi ngồi trong buổi retrospective hôm đó và tự hỏi: lỗi này từ đâu ra? Ticket viết "báo cáo doanh thu theo ngày". Anh dev đọc ticket, code đúng theo ticket. Ticket sai thì sao anh biết được? Đúng. Ticket sai. Nhưng ai viết ticket? Cậu BA của team – người lúc đó đang bận sprint review của team khác và "copy spec từ email khách hàng vào Jira cho nhanh". Email của khách hàng cũng mơ hồ. Không ai hỏi thêm. Không ai clarify. Tất cả cứ chạy về phía trước và nghĩ người kia đã hiểu. Tôi đã thấy kiểu tình huống này lặp lại trong 20 năm làm PM/BA. Tên gọi khác nhau. Ngôn ngữ lập trình khác nhau. Nhưng root cause giống nhau hoàn toàn: vấn đề không bao giờ là code – mà là khoảng trống trong giao tiếp yêu cầu.