↓ Chuyển đến nội dung chính

Kỹ Năng BA

bàn làm việc với tập tài liệu dự án

Documentation BA: nói miệng thì nhanh, bắt bug thì mất dấu

·
Dev báo bug, hỏi chỗ này hồi đó chốt thế nào anh, và bạn mở máy ra tìm mà không thấy gì, không phải vì tài liệu bị xóa, mà vì nó chưa bao giờ được viết, lúc triển khai mọi thứ toàn nói miệng trong họp hoặc gõ vội qua tin nhắn. Bài này mình viết từ chính mấy lỗi documentation mình đã mắc, chứ không phải từ sách.
Bản wireframe đen trắng trên bàn cạnh mockup màu

Wireframe, mockup, prototype: BA cần làm tới đâu là đủ

·
Giả sử bạn gửi khách một wireframe xám để chốt luồng màn hình đề nghị mua hàng, và phản hồi đầu tiên là giao diện thế này người dùng không chịu đâu, đổi sang màu logo công ty nhé, thế là cả buổi họp sau đó bàn màu, còn câu bạn cần chốt là duyệt xong thì đề nghị đi đâu thì chẳng ai trả lời. Chuyện này dễ xảy ra khi hai bên chưa thống nhất đang xem loại bản vẽ nào, vì wireframe, mockup và prototype trả lời ba câu hỏi khác nhau, mà BA thường chỉ cần sở hữu một.
Bảng kịch bản UAT với các cột test trên màn hình

UAT cho dự án ERP: BA chuẩn bị kịch bản thế nào để không vỡ

·
Nhiều đợt UAT trong dự án ERP hỏng từ trước khi ai bấm nút đầu tiên, kịch bản viết theo màn hình, dữ liệu test toàn abc, chẳng ai thống nhất thế nào là đạt, tới tuần test thì key user bận, lỗi nào cũng bị ném vào một sheet chung, và buổi sign-off thành buổi cãi nhau. Nếu bạn là BA được giao chuẩn bị UAT, phần lớn việc của bạn nằm ở trước tuần test.
Danh sách kiểm NFR trên bàn làm việc của BA

Non-functional requirement: những yêu cầu BA hay quên

·
Giả sử bạn viết xong mọi yêu cầu chức năng cho màn hình báo cáo tồn kho, chạy test ngon lành, ai cũng khen, rồi tới ngày go-live dữ liệu thật đổ vào mấy chục nghìn dòng, báo cáo mất hơn một phút mới load xong, khách đứng bên cạnh nhìn bạn. Đó là lúc bạn nhận ra mình đã quên một thứ tên là non-functional requirement, yêu cầu phi chức năng.
Bảng fit-gap analysis với các cột phân loại trên màn hình

Fit-gap analysis ERP: làm thế nào để mỗi gap ra quyết định

·
Có lần mình làm một hệ thống chia lệnh sản xuất tự động, hệ thống đã tự tính hết rồi, vậy mà khách vẫn muốn giữ file Excel cũ, tự nhập tự điền như trước, vì quen và vì tiện lưu trữ. Nói thẳng thì việc đó không còn cần nữa, nhưng gốc của nó không phải lười đổi thói quen, họ sợ hệ thống tính nhầm, một nỗi lo rất tự nhiên.
Sơ đồ ERD với các bảng và quan hệ trên màn hình

ERD cho BA: đọc được sơ đồ dữ liệu mà không cần là dev

·
Lỗi hay gặp của BA mới với ERD là lướt qua luôn, coi đó là việc của dev, mà hậu quả thì tới muộn, viết yêu cầu xem lịch sử mua hàng của khách mà không biết dữ liệu nằm ở bảng nào, nên chẳng hỏi được mấy câu quan trọng kiểu một khách có thể có mấy địa chỉ giao hàng. Đọc ERD ở mức BA không cần biết code, chỉ cần bốn bước và một ví dụ.
Ba chồng tài liệu BRD SRS FS trên bàn làm việc của BA

BRD, SRS, FS khác nhau thế nào? Dự án thật dùng cái nào

·
Lỗi hay gặp của fresher với BRD, SRS, FS là thuộc lòng ba định nghĩa mà vẫn viết sai tài liệu. Giả sử ngày đầu đi làm bạn được giao viết SRS cho module này, trong khi tuần trước có người vừa gửi BRD, cả team thì cứ nói FS, ba cái tên mà câu hỏi thật chỉ có một, tài liệu này ai đọc và để quyết định việc gì.
Sơ đồ BPMN với các lane và task trên bàn làm việc

BPMN cho người mới: vẽ as-is/to-be từ ghi chú workshop

·
Giả sử bạn vừa bước ra khỏi buổi workshop hai tiếng với phòng mua hàng, cầm về tờ giấy chi chít chữ, ai gửi yêu cầu, ai duyệt, mức nào phải lên giám đốc, lúc nào thì chạy Excel ngoài, giờ phải vẽ lại thành một sơ đồ cho cả team nhìn chung một bức tranh, mở công cụ lên rồi đứng hình. Bài này đi từ đúng tờ giấy đó ra một sơ đồ BPMN dùng được, kèm mấy lỗi hay biến sơ đồ thành tranh treo tường.
BA dùng SQL truy vấn dữ liệu trên màn hình

BA có cần biết SQL không? SELECT, JOIN, GROUP BY là đủ sống

·
Trả lời ngắn: BA không bắt buộc phải biết SQL, nhưng nên biết ở mức SELECT, JOIN, GROUP BY, mức đó đủ để tự trả lời phần lớn câu hỏi dạng bao nhiêu, mấy cái, theo từng tháng, và đủ để kiểm tra requirement với dữ liệu thật, không cần học tới mức developer. Thử hình dung cuộc họp với phòng kinh doanh, trưởng phòng hỏi tháng trước có bao nhiêu đơn bị khách trả lại, chủ yếu là sản phẩm nào, bạn hứa sẽ gửi số, về chỗ nhắn dev nhờ lấy, dev đang chạy deadline nên ba ngày sau mới có file, mà tới lúc đó câu hỏi đã đổi, cuộc họp tiếp theo cũng đã diễn ra rồi. Tình huống kiểu này là lý do nhiều BA bắt đầu học SQL, và câu hỏi là học tới đâu thì vừa, để khỏi mất cả năm cày khóa database.
Business Analyst làm việc với code — bàn phím, màn hình hiển thị SQL và API

làm BA có cần biết code không? Cần đọc được, chưa cần viết

·
Trả lời ngắn: làm BA không cần viết code sản phẩm, nhưng nên đọc được SQL, tài liệu API và luồng dữ liệu, mức đó đủ để bạn tự kiểm tra requirement với dữ liệu thật và nói chuyện thẳng với dev, thay vì chuyển lời qua lại. Hỏi ba nhà tuyển dụng câu “BA có cần biết code không” thì bạn có thể nhận về ba câu trả lời khác nhau, chỗ này bảo chỉ cần hiểu nghiệp vụ, chỗ kia hỏi SQL, chỗ khác lại đưa một đoạn JSON rồi hỏi thiếu trường gì. Người mới nghe xong rất dễ hoang mang, nhưng thật ra ba câu đó không mâu thuẫn nhau, chúng chỉ phản ánh ba kiểu dự án khác nhau. Câu trả lời của mình là BA cần biết đọc, chưa cần biết viết, còn đọc cái gì và đến mức nào thì ở phần dưới.