STAKEHOLDER KHÓ TÍNH KHÔNG PHẢI LÀ VẤN ĐỀ CỦA HỌ.
Tôi nhận ra dó là vấn đề của tôi.
Tôi đã từng:
- Ra khỏi buổi họp với cảm giác bị tấn công cá nhân.
- Viết BRD xong rồi bị bác toàn bộ ở vòng review.
- Trở thành "người đưa tin xấu" giữa dev và business - và bị cả hai bên trách.
-
Tự hỏi: "Có phải mình không hợp làm nghề này?"
Vấn đề không phải stakeholder. Vấn đề là tôi đang xử lý conflict bằng phản xạ - không phải bằng kỹ thuật.
Đây là 3 kỹ thuật tôi ước có ai dạy mình từ năm đầu.
KỸ THUẬT 1: "5 WHYS" NGƯỢC - Khi requirement bị bác
Tình huống: Bạn trình BRD, stakeholder nói: "Không, tôi không muốn vậy." Bạn hỏi: "Vậy anh/chị muốn thế nào?" Họ trả lời mơ hồ, hoặc đưa ra một solution khác cũng có vấn đề.
Cách xử lý: Đừng hỏi "Anh muốn gì?" hỏi "Anh đang cố giải quyết điều gì?"
Sau đó dùng 5 Whys ngược: mỗi câu trả lời, hỏi tiếp "Tại sao điều đó quan trọng?" 3-5 lần.
Ví dụ thực tế:
BA: "Vì sao anh muốn thêm tính năng export Excel?"
Stakeholder: "Để team kế toán đối soát."
BA: "Tại sao việc đối soát quan trọng?"
Stakeholder: "Vì cuối tháng họ phát hiện sai sót thì mất 2 tuần để fix."
BA: "Tại sao mất 2 tuần?"
Stakeholder: "Vì không có log thay đổi."
→ Vấn đề thật không phải "thiếu nút export" - mà là thiếu audit trail. Giải pháp đúng hoàn toàn khác.
KỸ THUẬT 2: "PARKING LOT" - Khi conflict giữa hai stakeholder trong họp
Tình huống: Trong buổi họp 3 bên, sales nói requirement A, kỹ thuật nói A không khả thi, không khí căng thẳng, BA bị kẹp giữa. Tiếp tục họp thì mất thời gian, dừng họp thì mất momentum.
Cách xử lý: Đừng cố giải quyết tại chỗ. Áp dụng kỹ thuật "Parking Lot":
Viết conflict đó lên bảng/file chia sẻ với cấu trúc: "Vấn đề cần giải quyết riêng: [A vs B]. Người chịu trách nhiệm: [tên]. Deadline: [ngày]."
Nói rõ: "Chúng ta sẽ giải quyết item này trong một buổi 1-1, không phải bây giờ. Bây giờ tiếp tục với những item team đồng thuận."
Sau họp, gửi calendar invite cho 2 bên với agenda đã có sẵn.
Hiệu quả: Vừa giữ momentum buổi họp, vừa cho 2 bên thời gian "nguội" trước khi đối thoại lại. Đa số conflict tự giảm 50% sau 24h.
KỸ THUẬT 3: "DOCUMENT LOOP" - Khi stakeholder hay đổi ý
Tình huống: Tuần này họ chốt A, tuần sau đổi sang B, hôm họp dev kick-off thì lại bảo "à hôm trước tôi nói nhầm." Dev nổi giận, BA mất uy tín, dự án trễ.
Cách xử lý: Sau MỌI cuộc trao đổi liên quan đến requirement (kể cả chat 5 phút), gửi tóm tắt theo template:
Theo cuộc trao đổi hôm nay [ngày/giờ], tôi hiểu:
1. [Decision A] - confirmed by [tên]
2. [Decision B] - confirmed by [tên]
3. [Item pending] - sẽ confirm trước [ngày]
Nếu tôi hiểu sai chỗ nào, anh/chị reply trước [ngày] giúp em nhé.
Không có phản hồi, em sẽ tiến hành theo nội dung trên.
Tại sao hiệu quả:
Không phải truy cứu trách nhiệm - mà là xây ký ức chung.
Stakeholder buộc phải đọc kỹ trước khi đổi ý, vì biết có "evidence" được ghi lại.
Khi conflict phát sinh sau này, bạn không cần cãi - chỉ cần forward email.
Sau khi áp dụng 3 kỹ thuật này, tôi nhận ra một điều:
Stakeholder không khó tính. Họ chỉ đang giao tiếp bằng ngôn ngữ mà BA chưa biết dịch.
Conflict requirement không phải dấu hiệu bạn dở. Nó là dấu hiệu bạn đang chạm vào vùng quan trọng của business - và chính ở đó, BA giỏi được sinh ra.
