Mình nhớ tháng đầu tiên làm BA. Ngồi phòng họp với 8 người, ai cũng nói, ai cũng có ý kiến. Mình ghi chép hết — xong về bàn không biết cái nào mới là requirement thật.
Kinh khủng hơn: mình ngồi đó, gật đầu lia lịa, tỏ vẻ “OK em hiểu” — mà thực ra chẳng hiểu gì. Cảm giác như đi thi mà đề toàn tiếng Tây Ban Nha.
Không trường lớp nào dạy mình mấy cái dưới đây. Toàn tự ngã, tự vỡ đầu ra mới thấm.
1. Stakeholder không biết mình muốn gì#
Hồi mới ra trường, mình tưởng BA là nghề đẹp nhất thế gian: stakeholder nói requirement, mình ghi vào, đem về cho dev làm. Như đi chợ: người ta kêu gà, mình mua gà.
Sai be.
Phần lớn stakeholder không biết họ muốn gì. Họ chỉ biết họ đau, không biết thuốc nào trị. Họ nói “em làm cái màn hình giống Excel cũ nhé” — nhưng Excel cũ họ cũng ghét, (Mình đã viết kỹ hơn về chuyện này trong bài 3 nguyên tắc sống còn để lấy yêu cầu hiệu quả.)
Rồi mình mất 3 tuần làm đúng như họ nói. Xong họ bảo: “không phải ý anh.”
Cú sốc thứ nhất: requirement không nằm sẵn trong đầu ai cả. Nó là thứ mình phải moi ra, phải đặt câu hỏi ngu, phải propose phương án, phải cho họ thấy prototype mới biết họ gật hay lắc.
2. Requirement thay đổi mỗi ngày#
Tuần 1: “Làm cái này trước, gấp lắm.” Tuần 2: “Thôi bỏ, cái kia quan trọng hơn.” Tuần 3: “Hai cái đều làm, thêm cái này nữa.” Tuần 4: “Sao chậm thế?”
Mình từng thấy BA khóc vì cái vòng luẩn quẩn này. Mình cũng từng muốn khóc.
Hóa ra scope creep không phải exception — nó là default. Quan trọng không phải ngăn nó (không ngăn được), mà là có trace được mỗi thay đổi, có chữ ký cho mỗi lần “thêm cái này nữa.”
3. Dev không tin BA#
Có lần mình ngồi nghe một dev nói thẳng: “Em viết spec xong rồi, anh dev tự hiểu mà làm, khỏi giải thích.”
Cảm giác lúc đó như mình là cái bánh kẹp. Stakeholder đổ requirement lên đầu. Dev đổ code lên đầu. BA ở giữa hứng hết.
Dev muốn spec chi tiết từng dấu phẩy. Stakeholder muốn “tự động xử lý hết đi, đừng hỏi tôi.”
Cú sốc thứ ba: giao tiếp với dev là một kỹ năng riêng, không phải cứ viết dài là xong. Phải nói chuyện bằng ngôn ngữ của họ — data model, logic flow, edge case. Và quan trọng nhất: phải chứng minh được mình hiểu business để họ tôn trọng.
4. “Mình làm gì thế nhỉ?” — cảm giác vô dụng 3 tháng đầu#
Tháng một: mình quan sát. Tháng hai: mình viết meeting minutes. Tháng ba: mình hỏi “bao giờ em được làm việc thật?”.
Nhìn xung quanh: stakeholder vẫn nói chuyện với nhau, dev vẫn code, dự án vẫn chạy. Mình như cái bóng. Có mình cũng được, không mình cũng chẳng sao.
Phải đến một lần mình phát hiện requirement conflict giữa phòng sale và phòng kho — cùng một quy trình, hai đầu óc khác nhau — mình mới hiểu: cái giá trị nhất của BA không phải viết spec. Mà là nối những mảnh ghép mà mỗi phòng ban không thấy, vì họ chỉ nhìn từ góc của họ.
Cú sốc thứ tư: cảm giác vô dụng là bình thường. Kéo dài 3-6 tháng. Sau đó, nếu bạn chịu khó đi xuống xưởng, hỏi mấy câu “ngu”, bạn sẽ là người hiểu quy trình nhất — hơn cả stakeholder, hơn cả dev.
5. Không có template nào áp dụng được nguyên xi#
Học BA ở trường: có khung, có mẫu, có đáp án. Làm BA thực tế: mỗi dự án mỗi khác, mỗi stakeholder mỗi tính, template chép mạng về không dùng được.
Mình từng mất 2 tuần làm một cái BRD 30 trang. Stakeholder lật 2 trang đầu: “Dài quá, tôi không hiểu.”
Lần sau mình chỉ làm 2 trang A4, vẽ 4 cái hộp với mũi tên. Stakeholder gật: “Thế mới dễ hiểu.”
Cú sốc thứ năm: không có công thức chung. Cái hiệu quả ở dự án này có thể fail thảm ở dự án khác. BA giỏi không phải người thuộc nhiều template — mà là người đọc được tình huống và biết nên xài template nào, hay nên vứt template đi.
Năm cái trên không phải để bạn sợ. Ai mới vào cũng va phải. Mình cũng từng muốn bỏ nghề vì mấy thứ này.
Giờ nghĩ lại, chính mấy cú sốc đó mới dạy mình làm nghề.
Hỏi thật: bạn đang gặp cú sốc nào nhất? Hay có cú nào mình chưa liệt kê? Comment hoặc DM mình nhé.
#DehaDigitalSolutions #BusinessAnalyst #BAMoiVaoNghe
📖 Xem thêm:
- Xem thêm: Business Analyst là gì?