Bạn nghĩ dự án nhỏ có thể chạy mượt mà mà không cần Business Analyst (BA)? 

Để xây dựng sản phẩm hoặc dịch vụ đáp ứng đúng nhu cầu, việc sở hữu một đội ngũ phù hợp là yếu tố then chốt. Tùy thuộc vào đặc thù của mỗi dự án, đội phát triển thường bao gồm các chuyên gia đến từ nhiều lĩnh vực khác nhau.

Dù khách hàng thường dễ dàng nhận thấy sự cần thiết của kỹ sư hoặc nhà thiết kế, vai trò của những thành viên khác đôi khi bị xem nhẹ hoặc không được đánh giá đúng mức. 

Vậy BA làm gì mà quan trọng đến thế? Điều gì xảy ra nếu thiếu họ? 

Trong bài viết này, mình sẽ chia sẻ vai trò của BA qua câu chuyện thực tế, dễ hiểu, đặc biệt dành cho các bạn non-IT muốn khám phá nghề. Hãy cùng tìm hiểu!

BA làm gì mà quan trọng đến vậy?

Không chỉ là người ghi yêu cầu

Khi mới làm BA, mình nghĩ công việc chỉ là nghe khách hàng và ghi lại. Nhưng nếu chỉ “ghi chép”, dự án dễ đi sai đường. 

BA phải đào sâu, phân tích để đảm bảo yêu cầu có ý nghĩa. 

Ví dụ, khách hàng nói “Muốn app như GrabFood”, nhưng nếu chỉ ghi lại, dev có thể làm ra những tính năng không đúng mong muốn.

Người dịch ngôn ngữ business sang tech

BA là cầu nối giữa business (khách hàng, marketing) và tech (developer). 

Khách hàng thường đưa ý tưởng mơ hồ, như “Muốn app như GrabFood”. 

BA sẽ hỏi: “Cụ thể là tính năng nào? Đặt hàng nhanh hay theo dõi đơn?” 

→ Từ đó, BA biến ý tưởng thành yêu cầu rõ ràng cho nhóm phát triển và các bên liên quan trong dự án. Thiếu BA, business và tech dễ trở thành “ông nói gà – bà nói vịt”.

Đặt câu hỏi để tìm giải pháp đúng

BA giỏi không cần biết tất cả, mà biết hỏi đúng. Trong dự án app đặt đồ ăn kể trên, khách hàng yêu cầu nút “Đặt ngay”. 

Thay vì ghi lại, BA hỏi: “Nút này giải quyết vấn đề gì? Người dùng có tìm dễ không?” 

→ Nhờ đó, mình phát hiện vấn đề nằm ở giao diện rối. Chỉ cần làm nút to hơn, rõ hơn, app đã thân thiện hơn nhiều.

Thiếu BA, dự án sẽ ra sao?

Yêu cầu sai, thời gian và tiền mất

Quay lại câu chuyện app đặt đồ ăn. Không có BA, team dev hiểu sai yêu cầu “giống app G”, tập trung vào giao diện đẹp nhưng quên tối ưu luồng đặt hàng. 

→ Kết quả: App ra mắt, khách hàng phàn nàn vì phải nhấn 5 lần mới đặt được món. Sửa lại mất 2 tháng và cả đống tiền. Nếu có BA, yêu cầu đã được làm rõ từ đầu.

Xung đột giữa các bên liên quan

Dự án thường có nhiều stakeholder: 

• Marketing muốn giao diện bắt mắt
• Dev muốn code nhanh
• Khách hàng muốn đủ tính năng. 

→ Không có BA, các bên dễ cãi nhau. 

Mình từng thấy một website thương mại điện tử trì hoãn vì marketing và nhóm phát triển không thống nhất về luồng đặt hàng. 

→ Nhưng nếu dự án có BA, họ sẽ giúp mọi người “nói cùng ngôn ngữ” và đi đúng hướng.

Sản phẩm không đáp ứng người dùng

Thiếu BA, sản phẩm có thể đẹp nhưng vô khó có thể sử dụng mượt mà. 

Vẫn là app đặt đồ ăn, nút đặt hàng nhỏ xíu, chữ mờ, người lớn tuổi không dùng được. 

→ Nếu có BA, họ sẽ hỏi: “Đối tượng người dùng là ai? Họ cần giao diện thế nào?” Sản phẩm không chỉ đẹp mà còn đúng nhu cầu thực tế.

Khi nào BA trở nên không thể thiếu?

Dự án phức tạp, nhiều stakeholder

Dự án càng lớn, càng nhiều bên liên quan → BA càng quan trọng. 

Một khách hàng từng yêu cầu “app như Netflix”. Nghe hoành tráng, nhưng không có BA, dev không biết bắt đầu từ đâu. 

Khi có BA, họ phân tích: “Bạn cần gợi ý phim hay chỉ phát video?” → Từ ý tưởng mơ hồ, BA tạo danh sách tính năng cụ thể.

Ngăn ngừa rủi ro từ sớm

BA không chỉ làm rõ yêu cầu, mà còn phát hiện vấn đề trước khi code. 

Mình từng làm dự án đăng ký người dùng. Nhờ phân tích, mình phát hiện luồng đăng ký vi phạm quy định bảo mật dữ liệu. 

→ Nếu không có BA, lỗi này chỉ lộ ra khi ra mắt, tốn kém để sửa, rủi ro lớn cho dự án và sản phẩm. Sản phẩm khi ra mắt thị trường sẽ dễ là chủ đề bàn tán trong cộng đồng chuyên môn do thiếu sót quá lớn. 

Tối ưu chi phí và thời gian

Thay vì làm tính năng phức tạp, BA có thể đề xuất giải pháp đơn giản. 

Ví dụ, một công ty muốn hệ thống đặt lịch spa online. Ban đầu, họ yêu cầu tính năng phức tạp, nhưng BA đề xuất chatbot trên Zalo, vừa nhanh vừa phù hợp khách trung niên. 

→ Kết quả: Tiết kiệm 50% chi phí và thời gian.

Có trường hợp nào không cần BA không?

Dự án siêu nhỏ, team tự quản lý

Thú thật, không phải dự án nào cũng cần BA riêng. 

Một landing page đơn giản, yêu cầu rõ ràng → Chỉ cần team có 3 người hiểu và từng có kinh nghiệp là có thể tự xử lý. Nhưng đây là ngoại lệ.

Rủi ro vẫn rình rập

Dù dự án nhỏ, thiếu BA vẫn có thể gây sai sót. 

Mình từng thấy team nhỏ làm website bán hàng, tưởng đơn giản, nhưng quên hỏi khách về phương thức thanh toán. 

→ Kết quả: Khách hàng bỏ đi vì website không hỗ trợ ví điện tử. Một câu hỏi từ BA có thể tránh vấn đề này.

BA là khoản đầu tư dài hạn

BA không chỉ giải quyết vấn đề hiện tại, mà còn giúp dự án tránh “bom nổ chậm”. Dù dự án nhỏ hay lớn, BA là khoản đầu tư để sản phẩm đúng hướng, tiết kiệm chi phí và giữ chân khách hàng.

Rèn luyện kỹ năng BA để đưa dự án đi đúng hướng

Phát triển tư duy phản biện

Muốn là BA giỏi, hãy rèn kỹ năng đặt câu hỏi. Trước mọi yêu cầu, hỏi “Tại sao?”. 

Ví dụ: “Tại sao khách cần tính năng này? Có giải pháp rẻ hơn không?” 

Mình từng tiết kiệm hàng giờ phân tích xoay vòng, lẩn quẩn chỉ bằng câu hỏi: “Tính năng này có thực sự cần với người dùng không, vì đối với người dùng, hành vi của họ có thể là A, B hay C. Vậy tính năng E của chúng ta có đang bao trùm được các hành vi của họ?” 

Quan sát và phân tích vấn đề đời thường

Nếu bạn non-IT, đừng lo! Quan sát các quy trình xung quanh mình hoặc mình thường xuyên sử dụng. 

Ví dụ rằng: nếu thấy quy trình đặt vé máy bay rối rắm? 

→ Hãy phân tích và đặt các câu hỏi rằng nếu bạn là người dùng, đang sử dụng ứng dụng để đặt vé nhưng các bước đang làm bạn cảm thấy hoang mang, không chắc chắn rằng đã nhập đầy đủ các thông tin hoặc không có section để xem lại thông tin của bước trước đó. Đặt ra các câu hỏi và làm rõ như sau: “Người dùng gặp khó ở đâu? Có thể cải thiện thế nào?” 

Xây portfolio để chứng minh năng lực

Không có kinh nghiệm? Không sau, hãy tự tạo portfolio bằng mock project!

Cách để xây dựng mock project đơn giản như: Chọn vấn đề mà bạn đang nhận thấy tại các tính năng trên các ứng dụng thường xuyên sử dụng, nếu là bạn – một người dùng đang bối rối và không cảm thấy quy trình hiện tại khả quan, có các ý tưởng cải tiến quy trình. 

→ Ngồi xuống, hãy viết user story, vẽ flowchart hiện tại và tương lai sau cải tiến từ ý tưởng của bạn, làm mockup giao diện. Từ đó đưa ý tưởng cải tiến thành một mock project có thể thể hiện kỹ năng, cá tính, tư duy cá nhân. 

Những sản phẩm này chứng minh bạn hiểu công việc BA, ngay cả khi chưa đi làm.

Kết luận: 

Business Analyst không chỉ ghi yêu cầu, mà là người đặt câu hỏi đúng, kết nối các bên, và đảm bảo dự án đi đúng hướng. Thiếu BA, dự án có thể chạy, nhưng rủi ro sai sót, tốn kém và thất bại luôn rình rập. Với BA, bạn tiết kiệm thời gian, chi phí, và tạo sản phẩm đúng nhu cầu.

Hãy tham gia group cộng đồng “Học BA từ số 0 – Road to your 1st BA job!” để kết nối với các đồng nghiệp, nhận thêm các chia sẻ về kiến thức và kỹ năng thực chiến nhé!