Khám phá về nghệ thuật tiếp cận User Story dành cho BA

Trong vai trò của một Business Analyst (BA), việc hiểu đúng nhu cầu của người dùng cuối là điều vô cùng quan trọng để tạo nên những giải pháp đúng kỳ vọng và hiệu quả. Tuy nhiên, việc biết người dùng muốn gì là một chuyện, còn hiểu rõ tại sao họ cần điều đó và nó đóng góp như thế nào vào mục tiêu kinh doanh lại là một câu chuyện khác, đòi hỏi kỹ năng phân tích sâu hơn. Trong hành trình đó, User Story (câu chuyện người dùng) trở thành một công cụ vừa đơn giản, vừa hữu ích, giúp BA dễ dàng tiếp cận nhu cầu từ chính góc nhìn của người sử dụng.

Bài viết dưới đây sẽ cung cấp cái nhìn toàn diện, chi tiết và mang tính ứng dụng cao về User Story trong công việc thực tiễn. Chần chờ gì mà không cùng BAC khám phá về nghệ thuật tiếp cận User Story dành cho Business Analyst.

1. User Story là gì và vì sao lại quan trọng đến vậy?

User Story là một câu mô tả ngắn gọn về nhu cầu của người dùng, được thể hiện theo góc nhìn của chính người đó. Không giống như các tài liệu yêu cầu dài dòng và kỹ thuật, User Story tập trung vào yếu tố con người: ai cần gì và vì sao họ cần điều đó. Mẫu câu thường gặp của một User Story là:

"Là một [vai trò người dùng], tôi muốn [mục tiêu], để tôi có thể [lợi ích hoặc mục đích]."

Ví dụ: "Là một nhân viên kế toán, tôi muốn xem báo cáo dòng tiền theo thời gian thực, để tôi có thể kiểm soát chi phí tốt hơn."

Câu nói này chỉ dài một dòng, nhưng mang đầy đủ ba yếu tố thiết yếu: vai trò, mong muốn cụ thể và lý do. Nó không chỉ giúp BA hiểu nhanh nhu cầu mà còn tạo tiền đề cho các cuộc thảo luận sâu hơn, nơi những chi tiết kỹ thuật, ràng buộc và giải pháp bắt đầu được thảo luận rõ ràng hơn.

Trong thực tế, nhiều dự án thất bại không phải vì giải pháp kỹ thuật yếu kém, mà vì không ai hiểu rõ người dùng thực sự cần gì. User Story chính là công cụ khắc phục hạn chế đó.

2. Hành trình thu thập và viết User Story 

Học viên BA thường được giao bài tập viết User Story từ những mô tả có sẵn, nhưng trong môi trường làm việc thực tế, User Story phải được thu thập, sàng lọc và viết ra từ những thông tin rời rạc, đôi khi rất mơ hồ.

Quá trình này bắt đầu từ những cuộc phỏng vấn với người dùng. Không phải để hỏi "Anh/chị muốn gì?" mà để khám phá thói quen làm việc, các vướng mắc hiện tại và mục tiêu thực sự của họ. Câu chuyện của người dùng có thể bắt đầu bằng một than phiền như: "Tôi phải mất cả buổi sáng để tổng hợp báo cáo bằng tay". Và nhiệm vụ của BA là đào sâu xem nguyên nhân là gì, họ đang dùng công cụ nào, và họ sẽ ra sao nếu có giải pháp thay thế khác.

Quan sát trực tiếp cũng là một kỹ thuật quan trọng. Khi bạn nhìn người dùng thao tác với hệ thống, bạn sẽ nhận ra những điểm nghẽn mà bản thân họ đôi khi không nhận thức rõ. Kết hợp với các buổi brainstorming, workshop hoặc mapping về user journey (hành trình người dùng), bạn có thể phác thảo nên một loạt User Story thực tế, đại diện cho đa dạng vai trò trong tổ chức.

3. Đa dạng hóa User Story để phản ánh thực tế toàn diện

Một dự án thường có nhiều nhóm người dùng khác nhau. Nhân viên kế toán, trưởng nhóm vận hành, nhân sự hay khách hàng đầu cuối – tất cả đều có nhu cầu riêng biệt khi tương tác với hệ thống. Việc chỉ phỏng vấn một nhóm là chưa đủ.

Lấy ví dụ từ một hệ thống quản lý nhân sự. Nếu chỉ thu thập yêu cầu từ phòng nhân sự, bạn sẽ thiếu góc nhìn của nhân viên, người quản lý trực tiếp, và thậm chí là phòng tài chính. Mỗi vai trò sẽ đưa ra các User Story khác nhau, thể hiện kỳ vọng và khó khăn riêng.

Khi bạn tổng hợp được nhiều User Story đa dạng, bạn sẽ thấy bức tranh toàn cảnh dần rõ nét. Lúc này, BA không chỉ đóng vai người ghi chép mà còn là người kết nối các mong đợi rời rạc thành một giải pháp tổng thể.

4. Viết User Story thế nào để mang lại giá trị thực sự?

• Vai trò người dùng: Họ là ai? Làm gì trong tổ chức?
• Mục tiêu cụ thể: Họ đang cố đạt được điều gì?
• Lợi ích mong muốn: Vì sao điều đó lại quan trọng?

• Independent (Độc lập)
• Negotiable (Có thể thương lượng)
• Valuable (Mang lại giá trị rõ ràng)
• Estimable (Có thể ước lượng)
• Small (Đủ nhỏ để thực hiện nhanh)
• Testable (Có thể kiểm thử được)

Khi mỗi User Story đáp ứng các tiêu chí trên, việc phát triển, kiểm thử và xác nhận trở nên dễ dàng hơn rất nhiều.

5. Gợi ý thực hành user story dành cho các BA mới vào nghề

• Lựa chọn một tình huống giả lập, đóng vai nhân viên trong tổ chức và tự xây dựng các User Story từ góc nhìn của mình.
• Làm việc nhóm theo vai trò: một người đóng vai BA, một người là người dùng, người còn lại là developer. Thảo luận và viết User Story, sau đó phản biện.
• Sau khi viết xong, tự đánh giá lại các User Story dựa theo tiêu chí INVEST, xem có thể cải thiện ở đâu.
• Biến các User Story thành các câu hỏi phỏng vấn: nếu bạn chưa rõ "lợi ích" trong một User Story là gì, hãy thử nghĩ cách hỏi lại người dùng để tìm câu trả lời.

User Story không chỉ là công cụ kỹ thuật mà còn là cầu nối giữa nhu cầu người dùng và giải pháp kỹ thuật. Với các bạn theo đuổi nghề Business Analyst, việc thành thạo User Story sẽ giúp bạn không chỉ ghi nhận đúng yêu cầu, mà còn xây dựng được sự tin tưởng và phối hợp hiệu quả với toàn bộ các bên liên quan.