IT BA Fresher Trong E-Commerce: 3 Bài Toán Thực Chiến

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

Khi mới vào nghề BA, tôi nghĩ E-commerce chắc “dễ thở”: có sản phẩm → cho vào giỏ → thanh toán → xong.
Nhưng chỉ đến ngày đầu vào dự án tôi mới hiểu… “dễ” chỉ đúng với người mua hàng, còn đội làm hệ thống thì rối như dây sạc dưới đáy balo.

Trong bài này, tôi kể lại 3 bài toán thực tế tôi đã gặp khi làm Fresher BA trong team E-commerce – không quá phức tạp, nhưng đủ giúp tôi học rất nhiều về cách phân tích yêu cầu và làm việc với Dev/QA/Business.

Bài toán 1: “Sao khách thêm mã giảm giá mà hệ thống báo không hợp lệ?”

Tình huống thực tế

Ngày thứ 5 đi làm, chị CSKH gửi ticket:

“Khách nhập mã SALE20 nhưng hệ thống báo: Mã không tồn tại.
Trong khi mã này đang chạy ở banner trang chủ.”

Tôi mở Admin kiểm tra thì rõ ràng mã SALE20 vẫn đang active và còn 2 ngày nữa mới hết hạn.

Thế là business, dev và QA… nhìn nhau.

Cách tôi – một Fresher BA – xử lý

Tách logic của mã giảm giá

Tôi hỏi anh QA:

“Mã giảm giá dựa trên những rule nào vậy?”

Anh ấy liệt kê:

• Loại mã: phần trăm / số tiền 
• Ngày hiệu lực 
• Giới hạn số lần dùng 
• Áp dụng cho toàn shop hay chỉ 1 danh mục 
• Điều kiện giá trị đơn hàng tối thiểu 
• Mã dành cho user mới hay mọi user 

Tôi nhận ra SALE20 là mã dành cho đơn hàng tối thiểu 300k, mà khách chỉ mua 250k.

Thiết kế lại thông báo lỗi

Câu chuyện ở đây không phải hệ thống lỗi, mà thông báo lỗi quá chung chung, khiến user nghĩ mã không tồn tại.

Tôi viết yêu cầu cải tiến:

IF order_value < min_required

THEN show: "Đơn hàng cần tối thiểu 300.000đ để áp dụng mã SALE20."

ELSE IF code_not_found

THEN show: "Mã không tồn tại hoặc đã hết hạn."

Test lại với QA và demo cho business

Sau khi dev sửa, tôi test các case:

• Giá trị đơn hàng < min → báo đúng 
• Đủ điều kiện → áp dụng 20% 
• Mã sai → báo đúng 

Business xem demo xong gật đầu ngay.

Bài học rút ra

Đôi khi vấn đề không phải hệ thống hỏng, mà người dùng không hiểu hệ thống đang nói gì.
Một BA fresher chỉ cần hỏi đúng câu hỏi, tách đúng logic, là tìm ra gốc vấn đề.

Bài toán 2: “Khách thêm sản phẩm vào giỏ, nhưng ra trang thanh toán thì… biến mất”

Tình huống thực tế

Một khách phản ánh:

“Tôi thêm 2 áo thun vào giỏ, nhưng đến bước Checkout thì chỉ còn 1 cái?”

Nghe thì đơn giản, nhưng lúc đó team nghĩ đủ thứ:

• Bug session? 
• API giỏ hàng lỗi? 
• Sản phẩm sold-out?
  

Tôi – với tâm thế Fresher – hơi hoang mang.

Tôi giải quyết như nào?

So lại thiết kế ban đầu của giỏ hàng

Tôi xem lại user flow do BA chính làm:

• Giỏ hàng local (trên browser) 
• Giỏ hàng server (khi user đăng nhập)
  

Tôi nghi ngờ đồng bộ giữa client và server.

 Lấy log từ QA

QA nói:

• Lúc khách thêm sản phẩm → lưu localStorage 
• Khi đến trang Checkout → hệ thống merge giỏ local + giỏ server 
• Nếu trùng sản phẩm → lấy số lượng trên server
  

Thì ra:
Khách có giỏ hàng cũ từ 2 tuần trước → lúc đó còn 1 cái áo thun.
Khi merge → hệ thống ghi đè số lượng từ server.

Viết rule đồng bộ mới

Tôi đề xuất:

IF product_id trùng

THEN quantity = local_quantity + server_quantity

Dev đồng ý vì không ảnh hưởng logic chính.

Tạo test case rõ ràng cho QA

Tôi viết 8 case cho giỏ hàng:

• Local 1 – Server 0 
• Local 0 – Server 1 
• Local 1 – Server 1 
• Local 2 – Server 3 
• Local khác thuộc tính (size M) – Server (size L) 
• Sản phẩm hết hàng 
• Sản phẩm không còn bán 
• User chưa đăng nhập vs đã đăng nhập
  

Kết quả

Bug biến mất.
→ Conversion tăng nhẹ vì người dùng đỡ bực mình.

Bài học rút ra

Giỏ hàng là tính năng “nhỏ nhưng cực trọng yếu”.
Là BA, kể cả Fresher, phải hiểu source-of-truth dữ liệu nằm ở đâu.

Bài toán 3: “Khách chọn COD nhưng checkout xong thì hệ thống lại mặc định thành Thanh toán qua ví?”

Tình huống

Một ngày business gọi tôi:

“Khách chọn COD nhưng hệ thống lại hiện thành thanh toán bằng e-wallet. Tụi em check giúp anh xem lỗi gì nhé.”

Khá nghiêm trọng vì liên quan đến tỉ lệ hoàn đơn.

Tôi xử lý như sau

Vẽ lại Payment Flow

Tôi mở Figma của app ra xem:

Product → Cart → Payment Method → Confirmation → Order Created

Nhưng đó chỉ là UI.
Tôi hỏi dev về flow thật:

• UI ghi nhận lựa chọn Payment Method 
• Gửi API order/create 
• Backend validate lại phương thức thanh toán 
• Nếu không hợp lệ → fallback về default: e-wallet
  

Aha!
Vấn đề nằm ở Backend fallback.

Tìm nguyên nhân

Backend chỉ chấp nhận COD khi:

• Đơn hàng < 3 triệu 
• Địa chỉ nằm trong khu vực hỗ trợ giao COD 
• Sản phẩm không thuộc loại “dễ vỡ”
  

Trong case khách hàng kia:

• Order 5 triệu
  → backend chuyển sang “ví” vì đơn vượt hạn mức COD.
  

UI thì lại không thông báo gì → dẫn đến hiểu nhầm.

Viết yêu cầu cải tiến

Tôi đề xuất:

• UI phải validate trước giống backend 
• Nếu đơn không đủ điều kiện COD → disable tùy chọn COD 
• Khi khách bấm vào COD nhưng không đủ điều kiện → hiện popup giải thích 

Viết acceptance criteria theo kiểu dễ hiểu

GIVEN khách ở khu vực có hỗ trợ COD

AND giá trị đơn hàng < 3.000.000

WHEN họ chọn COD

THEN hệ thống tạo đơn thành công với phương thức COD

GIVEN giá trị đơn hàng > 3.000.000

WHEN khách chọn COD

THEN disable COD và hiển thị lý do

Kết quả

Sau khi fix:

• Giảm 70% lỗi “checkout sai phương thức thanh toán” 
• CSKH bớt nhận khiếu nại 
• Người dùng bớt hiểu lầm vì UI minh bạch hơn 

Bài học

Luôn nhớ:
UI hiển thị cái gì → backend phải hiểu cái đó.
Backend thay đổi cái gì → UI phải thể hiện cái đó.

Là Fresher BA trong E-commerce không đáng sợ như bạn nghĩ?

Tôi rút ra vài điều quan trọng:

1. Hỏi đúng người: không biết thì hỏi QA, dev, CS, Marketing. 
2. Luôn vẽ lại flow: nhìn tổng thể mới hiểu gốc vấn đề. 
3. Đừng phức tạp hóa vấn đề: nhiều bug chỉ là case nhỏ chưa được tính. 
4. Đọc log và test case: BA fresher mà đọc log được thì cực “đắt giá”. 
5. Luôn đứng về phía người dùng: họ không sai—UI/logic có thể đang làm họ hiểu lầm. 

BA trong E-commerce rất vui, vì mỗi bug giải quyết xong là thấy rõ kết quả: giảm hủy đơn, tăng conversion, ít khiếu nại.
Và quan trọng nhất: được hiểu cách một sàn thương mại điện tử thật sự vận hành bên trong.