Ngày đầu đi làm BA, mình từng nghĩ “cần gì mấy thứ này, cứ lao xuống xưởng hỏi khách hàng cần gì rồi về bảo IT code là xong”, rồi đời dạy cho một bài rằng không như là mơ. Bài này là sáu vùng kiến thức (Knowledge Areas) của BABOK mà mình thấy giúp BA trong nhà máy trụ được, viết lại bằng ngôn ngữ bình dân cho dễ nhớ.
Với mình, kiến thức trong sách, tức BABOK, là cái móng nhà, còn kinh nghiệm thực chiến là những viên gạch, thiếu cái nào thì nhà cũng đổ. BA trong nhà máy lại là nghề làm dâu trăm họ, vừa phải hiểu chuyện sản xuất vừa phải nói chuyện được với đội Dev, nên cứ lao vào làm mà thiếu phương pháp thì dự án gãy lúc nào không hay.
planning & monitoring: đừng để nước đến chân mới nhảy#
BA không ỷ lại vào Project Manager được, vì lịch của nhà máy lủng cà lủng củng lắm, hôm nay bận kiểm kê, mai lại quyết toán thuế bất ngờ, mình không chuẩn bị trước thì đến lúc cần gặp người là không gặp được ai. Cho nên cần một BA Approach rõ ràng: gặp ai, lúc nào, chuẩn bị gì trước khi gặp. Có cái đó thì mình chủ động được, chứ không thì task cứ dồn dập đè lên đầu. Mệt lắm.
elicitation & collaboration: nghệ thuật moi tin#
Thông tin không bao giờ nằm sẵn trên mặt bàn, nó nằm trong đầu người dùng, nên việc của BA không chỉ là “lấy yêu cầu” (gather) mà là khơi gợi (elicitation). Công nhân hay quản đốc sẽ không nói bằng ngôn ngữ phần mềm, họ chỉ than “máy hay hỏng lắm”, “viết giấy mỏi tay lắm”, và BA phải ngồi trà đá, hút thuốc cùng họ mới moi ra được pain point thật nằm sau lời than đó.
requirements life cycle management: trị bệnh sáng nắng chiều mưa#
Hôm nay sếp chốt “làm nút màu xanh”, tuần sau sếp đổi ý “thôi màu đỏ cho hợp phong thủy”, đây là ác mộng của mọi dự án, và nếu BA gật đầu vô tội vạ thì scope nát bét. Kỹ năng ở đây là biết lúc nào nói có, lúc nào nói không, và đánh giá được thay đổi đó ảnh hưởng đến tiến độ với tiền bạc ra sao, tất cả phải đi qua quy trình, giấy trắng mực đen, chứ không dựa vào lời nói. Chuyện yêu cầu phình dần mình có viết riêng ở bài scope creep.
strategy analysis: nhìn rừng chứ đừng chỉ nhìn cây#
Khách bảo “anh muốn mua phần mềm CRM”, BA non tay sẽ đi tìm CRM ngay, còn BA có tầm sẽ hỏi ngược lại: tại sao anh cần CRM, chiến lược ba năm tới là bán lẻ hay bán buôn, anh muốn tăng doanh số hay giữ chân khách cũ? Hiểu đúng chiến lược thì mới tư vấn đúng giải pháp, mà đôi khi thứ họ cần chẳng phải CRM, chỉ là chấn chỉnh lại quy trình Sales đang lộn xộn thôi.
requirements analysis & design definition: làm người phiên dịch#
Dịch sai một chữ là ông Dev code sai một dặm. Khi ôm về một đống thông tin hổ lốn từ xưởng, BA phải xào nấu lại thành sơ đồ (flowchart), thành mô hình dữ liệu, thành bản mô tả (SRS) để IT đọc là hiểu ngay, và khâu này đòi tư duy logic rất chắc tay.
solution evaluation: dùng được hay đắp chiếu?#
Làm ra một hệ thống xịn sò mà không ai dùng thì giá trị của BA bằng 0. Đánh giá giải pháp không dừng ở chuyện hết bug, mà phải quay lại hỏi nó có giải quyết được vấn đề ban đầu không: công nhân có chịu dùng không hay vẫn lén ghi giấy, doanh nghiệp có tiết kiệm được chi phí không, và rốt cuộc giá trị thật nó mang lại là gì.
móng và gạch#
BABOK là nền móng, thực chiến là gạch xây, chỉ có một thứ thì nhà vẫn đổ. Trong môi trường sản xuất rối rắm, sáu món võ trên gói lại thành mấy việc rất đời: chủ động lên kế hoạch, moi đúng nỗi đau, giữ chặt thay đổi, nhìn chiến lược trước khi nhìn tính năng, phiên dịch nghiệp vụ sang công nghệ cho chuẩn, và sau go-live thì quay lại xem cái mình làm có ai dùng thật không. Nghe thì dễ, làm mới thấm.
Nếu bạn muốn xem chuyện dự án gãy thì trông như thế nào, đọc thêm bài tại sao dự án ERP thất bại.
Bài đăng lần đầu trên quanlamba.wordpress.com.
