Trả lời ngắn: Dev muốn chuyển sang BA nên tận dụng lợi thế hiểu kỹ thuật, rồi tập thói quen hỏi để làm gì trước khi nghĩ cách làm. Không cần nghỉ việc, cứ rẽ dần bằng cách nhận phần làm rõ requirement, ngồi họp với user và viết tài liệu ngay trong dự án hiện tại.
Dev chán code có nên sang BA không, câu hỏi này sai ngay từ đầu, vì chán code là lý do để rời một việc chứ chưa phải lý do để chọn việc tiếp theo. Câu đáng hỏi hơn là bạn có thích cái phần trước khi dòng code đầu tiên được viết không, cái phần mà mọi người cãi nhau xem rốt cuộc cần làm gì.
Mình đi lên từ dev, nên bài này viết theo góc nhìn của người từng ngồi cả hai phía, không có công thức chung đâu, nhưng có vài thứ nên biết trước khi rẽ.
lợi thế là bạn nói được tiếng của dev#
Dev sang BA có một lợi thế rõ, nghe requirement là hình dung được technical constraint, user muốn một màn hình tự cập nhật liên tục thì bạn biết ngay câu tiếp theo là dữ liệu lấy từ đâu, bao lâu refresh một lần, nghẽn thì sao, còn dev bên kia bàn nói cái này phải chạy batch qua đêm thì bạn hiểu và dịch lại được cho user bằng lời thường.
Lợi thế thứ hai là bạn đọc được dữ liệu, biết bảng nào nối bảng nào, biết một field nullable nghĩa là gì, biết vì sao một yêu cầu “đơn giản” lại đụng tới ba hệ thống. Bài Làm BA có cần biết code không bàn kỹ hơn chuyện kiến thức kỹ thuật giúp BA tới đâu.
cái khó là bỏ phản xạ nhảy vào giải#
Dev giỏi là người nhìn vấn đề thấy ngay cách làm, mà với BA phản xạ đó lại hay hại. User nói thêm cho em một nút xuất Excel, con dev trong bạn đã chọn xong thư viện với format, còn BA thì phải hỏi ngược lại, xuất ra để làm gì, ai đọc, đọc xong quyết định gì. Nhiều khi hóa ra họ cần một báo cáo có sẵn, chẳng cần nút nào cả.
BABOK Guide v3 xếp việc này vào Elicitation and Collaboration, tức khai thác thông tin từ stakeholder rồi xác nhận lại hiểu biết chung, nghe thì đơn giản, nhưng với người quen giải bài thì ngồi yên hỏi thêm ba câu là cả một bài tập kiềm chế.
Một yêu cầu, hai cách nhìn
| Phản xạ dev | Phản xạ BA |
|---|---|
| Làm sao để chạy được | Chạy để giải quyết vấn đề gì |
| Bug là lỗi cần sửa | Bug có thể là dấu hiệu requirement chưa rõ |
| User nói gì làm nấy | User nói một chuyện, cần có thể là chuyện khác |
không phải dev nào cũng hợp làm BA#
Đừng nghĩ BA nhẹ hơn vì không phải code, nó mệt theo kiểu khác, dev mệt vì bug khó tìm, còn BA mệt vì stakeholder không nói hết, vì requirement đổi giữa sprint, vì đứng giữa user và dev mà bên nào cũng thấy mình chưa đủ.
Cái hay bị đánh giá thấp nhất là cảm giác xong việc. Code thì có lúc test pass, merge xong, nhẹ cả người, còn việc BA hiếm khi có điểm kết rõ như vậy, tài liệu duyệt rồi vẫn có thể phải sửa, họp xong rồi vẫn còn câu hỏi treo. Chuyện dev sang BA một thời gian rồi quay về code không có gì lạ, cũng chẳng có gì sai, biết sớm mình hợp phía nào vẫn hơn.
Thử tự hỏi xem một ngày tốt của bạn kết thúc bằng code chạy rồi, hay bằng mọi người cuối cùng cũng thống nhất cần làm gì. Nếu là vế sau thì đọc tiếp.
rẽ sang BA mà không phải nghỉ việc#
Cách ít rủi ro nhất là bắt đầu ngay trong vai dev hiện tại, trước mỗi task đọc kỹ requirement và hỏi người viết ít nhất một câu để làm gì, ghi lại những chỗ bạn phải tự đoán, vì đó chính là chỗ requirement còn hổng, và cũng là bằng chứng bạn biết nhìn ra lỗ hổng.
Tiếp theo là xin ngồi vào các buổi họp với user hoặc buổi grooming backlog, đừng chỉ ngồi nghe mà xung phong viết biên bản và tóm tắt requirement sau buổi họp, vài lần như vậy là bạn có sản phẩm thật để đưa vào hồ sơ, từ biên bản, user story tới sơ đồ quy trình tự vẽ.
Phần kỹ thuật thì giữ lại nhưng đổi cách dùng, SQL giờ là để trả lời câu hỏi nghiệp vụ chứ không phải để viết tính năng, bài SQL cho BA nói rõ mức nào là đủ. Cũng nên chuẩn bị tinh thần cho mấy cú sốc đầu tiên khi sang vai mới, từ chuyện bị hỏi mà không có đáp án đúng tới chuyện viết tài liệu xong không ai đọc, bài 5 cú sốc của BA mới vào nghề liệt kê khá đủ.
Chuyển từ dev sang BA rốt cuộc là đổi câu hỏi trong đầu, từ làm sao sang để làm gì, lợi thế kỹ thuật giúp bạn đi nhanh hơn người khác ở đoạn đầu, còn thói quen hỏi mới quyết định bạn đi được bao xa. Nếu bạn đang là dev, thứ làm bạn muốn đổi là bản thân việc code, hay là việc code những thứ chưa ai hỏi rõ để làm gì? Trả lời mình qua Facebook hoặc LinkedIn nhé.
