Nghề BA & Nghệ Thuật “Giữ Hòa Bình” Giữa Business Và Dev

Bài viết được chia sẻ từ chuyên gia Business Analyst

Làm Business Analyst (BA) không đơn thuần là xử lý văn bản hay vẽ quy trình, mà thực chất là quản trị kỳ vọng và giải quyết xung đột lợi ích. Để dự án đi đến đích, BA phải đóng vai trò là “trạm trung chuyển” ngôn ngữ, chuyển hóa những mong muốn trừu tượng của Business thành những logic kỹ thuật chặt chẽ cho đội ngũ Development.

Nghề BA có thực sự chỉ là ngồi viết tài liệu?

Ngày đầu đi làm, mình (và chắc nhiều bạn cũng vậy) nghĩ nghề Business Analyst đơn giản là ngồi viết tài liệu thật đẹp: Use Case, SRS, BRD, Flow chart, vẽ thêm vài màn hình trong Figma là xong.

Rồi đời tát cho một phát thật đau:

Ngày thứ ba đi làm, team dev hỏi:

“Spec này ông ghi ‘auto-approve’ nghĩa là gì, approve theo logic nào?”

Mình ú ớ:

“Ờ… để em hỏi lại business đã…”

Vừa quay qua hỏi business, chị PM bảo:

“Ủa, cái đó anh dev phải tự xử chứ, mình cần nhanh lên để demo cho khách.”

Thế là mình chính thức hiểu:

Làm BA không chỉ viết tài liệu – mà là làm “phiên dịch viên kiêm nhà ngoại giao chuyên nghiệp” giữa Business và Dev.

Dev nói tiếng “logic”, Business nói tiếng “kỳ vọng”

Một ngày đẹp trời, Business bảo:

“Tôi muốn hệ thống tự động tính toán điểm thưởng cho khách hàng thân thiết.”

Nghe có vẻ dễ, nhưng sang dev, họ hỏi:

“Tự động là khi nào? Sau mỗi giao dịch hay cuối tháng? Tính theo rule nào? Có rounding không?”

Nếu bạn không chuẩn bị kỹ, thì BA chính là người bị “kẹt giữa hai làn đạn”:

• Business: “Sao dev làm không đúng ý tôi?”
• Dev: “Sao BA không nói rõ từ đầu?”

Đây là lúc bạn nhận ra:

Một BA giỏi không phải người viết tài liệu đẹp nhất, mà là người dịch được giữa hai ngôn ngữ: kỳ vọng của Business và logic của Dev.

Tại Sao BA Lại Trở Thành Người Giữ Hòa Bình Giữa Hai Phe?

Khi Business “nóng ruột”, còn Dev thì “nóng máy”

Trong dự án e-commerce mình từng tham gia, Business muốn thêm một tính năng nhỏ:

“Chỉ cần thêm một field ‘Promo Code’ thôi mà, 5 phút!”

Nhưng với Dev, “5 phút” đó là:

• Thêm field ở frontend
• Update API
• Validate input
• Test case
• Regression test
  

Khi hai bên bắt đầu “gầm gừ”, BA chính là người phải đứng ra dập lửa:

“Ok, để mình check lại impact. Nếu tách logic ra microservice hiện tại thì mất tầm 1.5 ngày. Nếu business cần gấp, mình có thể hardcode tạm trong batch, sau đó refactor sau sprint.”

Đôi khi chỉ cần nói cùng ngôn ngữ của họ, cả hai bên đều hạ nhiệt.

Nghệ Thuật Thương Lượng Để Bảo Vệ Tinh Thần Đội Ngũ

Trong giai đoạn Sprint, những thay đổi đột ngột (Change Request) thường là “ngòi nổ” cho các cuộc chiến tranh lạnh. Business muốn linh hoạt, nhưng Dev cần sự tập trung. Một BA bản lĩnh sẽ không “chuyển tiếp” nguyên văn yêu cầu của khách hàng xuống cho Dev, mà sẽ thực hiện bước đánh giá tác động.

Đừng chỉ nghe – Hãy “dịch”

Business nói: “Tôi muốn hệ thống dễ dùng.”
→ Dịch ra dev: “Cần giảm số bước thao tác trong UI, tối ưu flow.”

Dev nói: “Cái này architecture không support.”
→ Dịch ra business: “Tính năng này cần thêm effort để mở rộng cấu trúc hệ thống.”

BA giỏi là người nghe ra được thứ người ta không nói thẳng.

Đừng vội hứa

Business hay hỏi: “Khi nào có thể release?”
Dev thì bảo: “Còn cả đống bug chưa fix.”
Nếu bạn hứa bừa, dev ghét. Nếu bạn im lặng, business sốt ruột.
Cách hay nhất là dùng dữ liệu để nói chuyện:

Hiện tại backlog còn 12 tickets, velocity trung bình của team là 10 points/sprint → nếu không có issue phát sinh, mình có thể release trong tuần tới.

Dữ liệu là tấm khiên bảo vệ BA giữa hai phía.

Tình huống khi BA cứu team khỏi chiến tranh lạnh

Case 1: Dự án Healthcare – Cú hiểu nhầm “định mệnh”

– Business Hàn bảo: “Chúng tôi cần chức năng lọc bệnh nhân theo ‘case status’.”

Dev Việt Nam hiểu nhầm, tưởng là “filter theo bệnh viện”.

Demo lần đầu, business đứng hình.

Cả team im 10 giây. PM bắt đầu nhăn trán.

– Mình (BA) vội nói: “À, để mình clarify lại — business muốn lọc theo trạng thái hồ sơ bệnh án đúng không? Ví dụ: ‘Active’, ‘Closed’, ‘Pending Review’?”

– Chị khách gật đầu.

Mình quay qua dev, gửi ngay diagram flow + screenshot từ mockup cũ để minh họa. 30 phút sau, vấn đề xong.

Cả team thở phào.

– Từ đó, dev nói đùa:

“BA là người cứu thế giới – ít nhất là cứu sprint này.”

Case 2: Dự án Logistics – Cơn bão “change request”

– Khách Mỹ (rất khó tính) gửi mail 2 giờ sáng: “We need to recalculate shipment fee logic. The current one is not accurate.”

– Dev phản ứng: “Again? We changed it last sprint!”

Nếu không xử lý khéo, tinh thần team sụp liền.

– Mình reply lại khách bằng email ngắn, lịch sự:

“Thanks for your feedback. We’ll review the logic and propose 2 options tomorrow: one for quick fix and one for long-term refactor.”

Sáng hôm sau, mình họp với dev, lấy log + test data, vẽ flow “before – after”.

Business đồng ý chọn quick fix, dev nhẹ nhõm.

→  Đó là lúc mình nhận ra:

BA không chỉ viết requirement, mà còn là người thương lượng để giữ tinh thần team.

Những kỹ năng “mềm mà cứng” BA phải có

• Communication – nói để người khác hiểu

Càng làm lâu, mình càng tin rằng BA không được “nói thông minh”, mà phải “nói dễ hiểu.”
Một BA giỏi làm cho dev hiểu ý business trong 2 phút, và làm business hiểu constraint của dev trong 1 câu.

• Empathy – hiểu rằng ai cũng đang áp lực

Dev bị bug dí, Business bị deadline dí.
BA là người ở giữa – không phải để đổ lỗi, mà để kết nối sự thật với kỳ vọng.

• Clarity – rõ ràng là sức mạnh

Nếu có thể, hãy vẽ flow, mockup, hoặc sample data.

Một hình ảnh tốt còn hơn 10 đoạn text.

Dev nhìn thấy luồng, business nhìn thấy output, và bạn không phải ngồi explain lại 5 lần.

Công cụ “vàng” giúp BA giữ hòa bình

• Figma – vẽ prototype nhanh, show flow trực quan.
• Jira / Monday – quản lý ticket rõ ràng, trace thay đổi dễ.
• Confluence – nơi lưu lại “single source of truth”, tránh “ông nói gà bà nói vịt.”
• Draw.io / Lucidchart – vẽ system flow giúp dev khỏi hiểu nhầm.
• Slack / Teams  – nhớ pin message quan trọng, tránh trôi task.
  

Công cụ không làm bạn giỏi hơn, nhưng giúp bạn sống sót giữa hai “phe” lâu hơn.

Khi bạn làm BA đủ lâu, bạn sẽ nhận ra…

• Dev không ghét Business – họ chỉ ghét sự mơ hồ.
• Business không ghét Dev – họ chỉ ghét sự chậm trễ.
• Và cả hai đều cần một người “dịch” giữa họ – đó chính là BA.
  

Một ngày đẹp trời, khi bạn thấy dev chủ động ping hỏi: “Cái flow mới business approve chưa để mình code luôn?”
và business nhắn:
“BA ơi, gửi giúp mình update để mình báo lại team sale nhé.”

Thì xin chúc mừng – bạn đã thực sự giữ được hòa bình.

BA là “nhà ngoại giao” của thế giới công nghệ? Chuẩn ko?

Nhiều người bảo:

“BA không tạo ra sản phẩm, chỉ ghi chép lại thôi.”

Sai.

→ BA là người đảm bảo sản phẩm được hiểu đúng, làm đúng, và ra đúng. Là cầu nối giữa tầm nhìn và thực thi, giữa “tôi muốn” và “hệ thống có thể làm”.

Và nếu có lúc bạn cảm thấy mệt vì đứng giữa Business và Dev, hãy nhớ:

Không ai sinh ra để làm “người giữ hòa bình”, nhưng nếu bạn làm được – bạn đang tạo giá trị mà không tài liệu nào thể hiện hết được.

Tóm lại:
Làm BA không chỉ là nghề viết requirement – mà là nghề giúp mọi người hiểu nhau.
Càng làm lâu, bạn càng nhận ra “communication” là code mạnh nhất mà BA cần học.
Và đôi khi, chỉ một câu nói khéo của bạn có thể cứu cả sprint.

Nếu bạn đang là BA mới, lời khuyên của mình là:

• Đừng sợ “ở giữa hai lằn đạn.”
• Học cách nói chuyện bằng ngôn ngữ của cả hai bên.
• Và nhớ: BA không chỉ viết tài liệu – mà là người giúp dự án đi đến đích trong hòa bình.