Xử Lý Requirements “Mơ Hồ” – Kỹ Năng Sinh Tồn Của BA Trong Logistics

Bài viết được chia sẻ từ chuyên gia Business Analyst trong lĩnh vực Logistics

Trong thế giới Logistics vận hành với tốc độ cao, yêu cầu hệ thống thường bắt đầu bằng những câu nói cảm tính như: “Em làm sao cho nó thông minh hơn một chút”. Nhiệm vụ của IT BA không chỉ là lắng nghe, mà là “phiên dịch” những cảm nhận mơ hồ đó thành các đặc tả kỹ thuật chính xác, đảm bảo hệ thống thực sự giải quyết được các điểm nghẽn vận hành.

Từ “yêu cầu mơ hồ” đến “mò mẫm yêu cầu”

Nếu bạn là một Business Analyst đã từng làm trong ngành Logistics, chắc chắn ít nhất một lần bạn đã nghe các cụm từ dạng như:

• “Hệ thống nên thông minh hơn một chút”
• “Hiển thị rõ ràng để bên vận hành dễ theo dõi”
• “Nên cảnh báo khi có bất thường”
• “Chỗ này có vẻ chưa tiện, sửa lại cho hợp lý”

Đọc xong, bạn chỉ muốn thốt lên: “Chính xác là… muốn cái gì?”

Thực tế, các anh chị vận hành (warehouse ops, delivery manager, admin logistics) rất giỏi nghiệp vụ, nhưng thường không quen mô tả vấn đề bằng ngôn ngữ logic hay kỹ thuật. Với họ, “hiện trạng chưa ổn” là thứ cảm nhận được trong quá trình thao tác hàng ngày – nhưng mô tả để BA hiểu, thì… hơi khó.

“Mơ hồ” – vì sao lại mơ hồ?

Requirement mơ hồ xuất phát từ nhiều lý do:

• Không rõ vấn đề gốc rễ: Stakeholder thường nêu “triệu chứng” chứ không chỉ ra “căn bệnh”. Ví dụ: “Hệ thống hay lỗi” → do thao tác chồng đơn, không check được tồn kho.
• Không quen tư duy hệ thống: Nhiều người vận hành chỉ quen làm việc theo thao tác, chưa nhìn tổng thể quy trình – nên khi mô tả, dễ thiếu bước hoặc nhảy bước.
• Giao tiếp chưa khớp “ngôn ngữ”: BA nói “use case”, “flow”, “scenario”, còn stakeholder thì nói “hồi sáng có khách kêu”, “tài xế không tìm thấy điểm giao”,…

Làm thế nào để “gỡ rối” một yêu cầu hiển thị thông tin giao hàng?

Hãy cùng nhìn vào một Case Study thực tế: Một quản lý vận hành yêu cầu “thêm cái gì đó để kiểm soát đơn hàng dễ hơn khi khách gọi hỏi”. Phía sau câu nói đơn giản này là một mạng lưới phức tạp các câu hỏi về dữ liệu: Hiển thị ở đâu? Dữ liệu lấy từ Driver App hay hệ thống trung tâm? Như thế nào là “đủ” để kiểm soát?

Dưới đây là 5 bước đơn giản để gỡ rối yêu cầu mơ hồ:

Gợi mở bằng câu hỏi thực tế thay vì “kỹ thuật hóa”

Thay vì hỏi “Anh/chị muốn thêm trường gì trên hệ thống?”, hãy hỏi:

“Lúc có khách gọi hỏi, chị thường phải làm gì để tra đơn?”
“Có trường hợp nào làm chị thấy xử lý chậm không?”

Câu hỏi dạng hành vi/thói quen giúp họ nói thật – từ đó, mình mới có dữ liệu để gom thành yêu cầu, hay đó chính là khai thác pain-points (điểm thương đau :D) của khách hàng đó…

Yêu cầu đưa ra ví dụ cụ thể

Bạn có thể chủ động hỏi stakeholder những câu hỏi gợi mở như: “Chị có thể kể giúp 1–2 đơn gần đây mà gặp vấn đề chị nói không?”

Thông thường, Stakeholder sẽ nhớ những tình huống “căng thẳng” rất rõ. Khi họ mô tả lại, BA có thể dựng lại dòng sự kiện, từ đó suy ra logic nghiệp vụ và xác định đúng vấn đề cốt lõi.

Dựng sơ đồ quick-draft để xác nhận hiểu đúng

Hãy vẽ lại quick flow bằng tay (hoặc dùng Miro, draw.io), rồi hỏi người đã đưa ra yêu cầu để có thể xác nhận được mong muốn tức thì.

Bởi vì, khi stakeholder thấy hình ảnh cụ thể, họ sẽ dễ nhận ra được những điểm họ chưa nói rõ. Một bản vẽ có thể hiệu quả gấp 5 lần văn bản dài dòng. Đây chính là kỹ thuật “nháp wireframing”, giúp xác nhận nhanh yêu cầu và mong muốn của khách hàng, đồng thời hỗ trợ họ hình dung giải pháp một cách trực quan và dễ hiểu hơn rất nhiều.

Đề xuất các kịch bản thay vì hỏi “muốn gì”

Thay vì hỏi “muốn hệ thống làm gì”, bạn nên đề xuất 2–3 kịch bản, ví dụ như sau:

• Option A: Thêm cột “Tài xế đang giữ hàng” + số điện thoại.
• Option B: Thêm biểu tượng trạng thái + thời gian cập nhật cuối.
• Option C: Gửi email cảnh báo nếu đơn treo quá 2 tiếng.

Việc đưa ra lựa chọn giúp stakeholder dễ “gật đầu” hơn, thay vì suy nghĩ từ đầu.

Không ngại “quay lại hỏi tiếp”

Logistics là ngành có nhiều biến thể – 1 câu chuyện không bao giờ đủ. Hãy học cách chấp nhận việc phải hỏi lại, cập nhật lại bản yêu cầu, thậm chí demo thử bản mockup để stakeholder phản hồi cụ thể hơn.

Mặt trái: Khó nhưng vui

Làm BA trong logistics có nhiều tình huống “cười ra nước mắt”:

• Yêu cầu ban đầu là “thêm cột ETA” → Sau khi hỏi kỹ thì hóa ra cần tích hợp hệ thống bản đồ real-time + điều phối tuyến động.
• Có lần khách bảo “muốn tracking chính xác như Shopee”, nhưng thực tế doanh nghiệp đang nhập trạng thái bằng… Excel.

Thay vì thấy bực, những tình huống như vậy sẽ giúp mình hiểu khách hàng hơn, và cũng thấy rõ giá trị của nghề BA: biến ý tưởng mơ hồ thành thứ có thể làm được mà đáp ứng output nhanh, chính xác và đủ cho khách hàng

Kết bài – chốt nhé!!

Stakeholder không có nghĩa vụ phải nghĩ như BA – chính BA phải học cách hiểu họ.

Xử lý requirement mơ hồ là một nghệ thuật kết hợp giữa đồng cảm, logic và chủ động. Không chỉ là chuyện hỏi đúng câu, mà còn là khả năng nhìn thấy điều khách hàng chưa nói ra.

Và trong ngành logistics – nơi mọi thứ vận hành với tốc độ cao, quy trình phức tạp và dễ phát sinh lỗi – khả năng này còn quan trọng hơn bao giờ hết.