Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Các kỹ năng cần thiết cho người bắt đầu làm IT BA: khơi gợi và phân tích yêu cầu, tài liệu hoá, mô hình hoá, cùng bộ công cụ kỹ thuật và kỹ năng mềm đi kèm.
Chào mừng bạn đến với thế giới của IT Business Analyst (IT BA)! Nếu bạn đang đọc bài viết này, có lẽ bạn đang tò mò về vai trò thú vị này hoặc đang chuẩn bị bước chân vào lĩnh vực phân tích nghiệp vụ đầy tiềm năng. BA được ví như cầu nối giữa kinh doanh và công nghệ, giúp các tổ chức hiểu rõ nhu cầu, tối ưu hoá quy trình và phát triển các giải pháp hiệu quả.
Nhưng một Fresher BA cần trang bị những gì để có thể tự tin và thành công trên con đường này? Đừng lo lắng! Bài viết này sẽ là bản đồ kỹ năng BA cho người mới bắt đầu, chỉ ra những "hành trang" thiết yếu mà bạn cần chuẩn bị. Chúng ta sẽ cùng nhau khám phá các kỹ năng BA cho người mới bắt đầu, từ những kiến thức chuyên môn nền tảng đến các công cụ kỹ thuật và những kỹ năng mềm quan trọng. Hãy cùng bắt đầu hành trình khám phá nhé!
Là một BA, bước đầu tiên của bạn là thu thập thông tin, yêu cầu từ các bên liên quan (stakeholder) như khách hàng, người dùng, hay các bộ phận trong công ty để hiểu rõ nhu cầu, mong muốn và những khó khăn thực tế của họ.
Các phương pháp thường được sử dụng:
Ví dụ: Khi phát triển tính năng "Đặt lịch hẹn bác sĩ" cho một ứng dụng y tế, bạn phỏng vấn hoặc làm khảo sát với bệnh nhân, nhân viên và bác sĩ phòng khám:
Để ý sự khác nhau giữa hai nhóm: yêu cầu chức năng trả lời "hệ thống làm được gì", còn yêu cầu phi chức năng trả lời "làm tốt tới mức nào". Điểm quan trọng là yêu cầu phi chức năng phải đo được — viết "giao diện đơn giản, phản hồi nhanh" thì không ai kiểm chứng được, còn "tải xong dưới 3 giây" thì tester đo được và dev biết đích cần đạt. Chi tiết hơn, bạn xem bài Phân biệt yêu cầu chức năng và phi chức năng.
Sau khi đã thu thập được các "nguyên liệu thô" quý giá này, bạn sẽ cần đến kỹ năng phân tích yêu cầu để "xử lý" và "chế biến" chúng.
Bằng cách chia nhỏ, phân loại, đánh giá và liên kết các yêu cầu với nhau, bạn sẽ đảm bảo được tính nhất quán của các yêu cầu, cũng như dễ dàng quản lý chúng.
Bạn sẽ làm quen với các kỹ thuật phổ biến như:
Ví dụ: Vẫn với tính năng "Đặt lịch hẹn bác sĩ", bạn áp dụng BACCM như sau:
Tuy nhiên, phân tích thôi vẫn chưa đủ. Để đảm bảo có một sự hiểu chung giữa các bên liên quan, bạn cần trình bày những phân tích này một cách có hệ thống — đó là lý do kỹ năng tài liệu hoá yêu cầu trở nên thiết yếu.
Có khá nhiều loại tài liệu, mỗi loại được sử dụng với mục đích khác nhau, phụ thuộc vào người đọc, bối cảnh, công ty, hoặc phương pháp phát triển (như Agile hay Waterfall). Tuy nhiên tất cả đều cần được trình bày một cách rõ ràng, chi tiết và dễ hiểu. Chọn đúng tài liệu giúp bạn truyền đạt yêu cầu hiệu quả đến các bên liên quan, từ khách hàng đến đội ngũ phát triển.
Các loại tài liệu phổ biến và thường được sử dụng:
Tên tài liệu | Mục đích | Đối tượng sử dụng | Đặc điểm nổi bật |
|---|---|---|---|
SRS | Mô tả toàn diện yêu cầu hệ thống | Đội phát triển, QC, BA; khách hàng tham gia khi nghiệm thu | Chi tiết; ở các dự án hợp đồng, SRS đã duyệt thường được dùng làm căn cứ nghiệm thu |
BRD | Tập trung vào nhu cầu kinh doanh | Business Owner, quản lý cấp cao, khách hàng, PM | Ngắn gọn, định hướng mục tiêu kinh doanh |
URD | Mô tả nhu cầu và những việc người dùng cần làm được | Đại diện người dùng và khách hàng (để xác nhận); BA, thiết kế, dev, QC (để triển khai) | Viết theo góc nhìn người dùng: họ cần đạt điều gì, trong hoàn cảnh nào |
PRD | Mô tả tính năng và hành vi sản phẩm | Đội phát triển, thiết kế, QC (thường do PO hoặc Product Manager soạn) | Linh hoạt, dùng trong phát triển sản phẩm |
| User Story | Mô tả ngắn gọn tính năng từ góc nhìn người dùng | PO, đội phát triển, QC | Ngắn gọn, dễ hiểu, đi kèm Acceptance Criteria |
| Use Case | Mô tả chi tiết tương tác giữa người dùng và hệ thống | Đội phát triển, QC | Cụ thể, bao gồm các bước và kịch bản |
Khi đã hoàn thiện các tài liệu, bạn cần quản lý, cập nhật chúng theo những thay đổi không thể tránh khỏi trong dự án — đó là lúc kỹ năng quản lý yêu cầu phát huy tác dụng.
Dự án thường có nhiều thay đổi (change request) có thể xuất phát từ các yếu tố kinh doanh, tính khả thi về mặt công nghệ, pháp lý... Việc quản lý yêu cầu tốt giúp bạn dễ dàng theo dõi và cập nhật các thay đổi này, đảm bảo tính nhất quán của các yêu cầu trong suốt dự án.
Cụ thể, những việc bạn sẽ làm gồm:
Bạn sẽ làm quen với các công cụ như Draw.io, Visio, Lucidchart... để vẽ và quản lý các sơ đồ này, giúp các bên liên quan hình dung rõ ràng về hệ thống hoặc quy trình cần xây dựng.
Ví dụ:
Các kỹ năng được đề cập bên trên là những nền tảng quan trọng giúp bạn tổ chức và truyền đạt thông tin hiệu quả. Tuy nhiên, để thực sự làm tốt những kỹ năng này, bạn cần hiểu sâu về lĩnh vực kinh doanh của khách hàng và công ty. BA không chỉ là "người viết tài liệu" mà còn có vai trò đưa ra giải pháp phù hợp, đáp ứng đúng nhu cầu và mục tiêu của dự án.
BA mới vào nghề có thể thử sức ở nhiều lĩnh vực khác nhau. Tuy nhiên, khi đã có 1–2 năm kinh nghiệm, việc tập trung vào 1 hoặc 2 lĩnh vực (domain) cụ thể sẽ giúp bạn trở thành chuyên gia, có kiến thức sâu rộng và mang lại giá trị cao hơn cho các dự án.
Hiện nay, các domain đang "hot" với mức lương hấp dẫn là Banking, Fintech, Blockchain, AI, ERP, Cloud, E-commerce...
Kiến thức lĩnh vực giúp bạn đề xuất giải pháp phù hợp, nhưng để triển khai chúng hiệu quả, bạn cần hiểu cách các đội ngũ công nghệ vận hành. Đây là chìa khoá để bạn phối hợp nhịp nhàng với đội phát triển và đảm bảo yêu cầu được hiện thực hoá đúng hướng.
Trước hết, cần phân biệt mấy khái niệm hay bị gộp làm một:
Điều bạn thực sự cần nắm là cách làm việc của BA thay đổi thế nào giữa chúng:
Waterfall | Scrum | |
|---|---|---|
Thời điểm làm rõ yêu cầu | Tập trung ở giai đoạn đầu, chốt trước khi code | Rải đều theo từng sprint, làm rõ dần |
Hình thức tài liệu | Tài liệu lớn, đầy đủ (BRD, SRS) và được duyệt | User story kèm acceptance criteria, bổ sung dần |
Xử lý thay đổi | Đi qua quy trình change request, đánh giá tác động | Đưa vào backlog và sắp lại thứ tự ưu tiên |
Nhịp làm việc của BA | Theo mốc bàn giao của dự án | Theo nhịp sprint, luôn chuẩn bị trước cho sprint sau |
Nói cách khác, cùng một kỹ năng phân tích nhưng ở Waterfall bạn viết tài liệu dày và chốt sớm, còn ở Scrum bạn chia nhỏ và làm rõ liên tục. Chi tiết hơn, bạn xem bài Giới thiệu các mô hình phát triển phần mềm: Waterfall, Agile, Scrum.
Xuyên suốt dự án, BA làm việc với rất nhiều bên liên quan, từ khách hàng, người dùng, chuyên gia... cho đến đội ngũ phát triển. Kỹ năng quản lý các bên liên quan giúp bạn xác định ai là người ảnh hưởng đến dự án, hiểu mong đợi của họ, và xây dựng mối quan hệ tốt để đạt mục tiêu chung.
Hiểu biết về kiến trúc hệ thống và công nghệ cơ bản: Mặc dù không cần phải là một lập trình viên, việc có hiểu biết cơ bản về kiến trúc hệ thống và công nghệ (ví dụ như mô hình 3 lớp, cách các hệ thống trao đổi dữ liệu qua API, và cơ sở dữ liệu) sẽ giúp bạn giao tiếp hiệu quả hơn với đội ngũ kỹ thuật và hiểu rõ hơn về những giới hạn và khả năng của hệ thống.
Công cụ quản lý công việc (Task Management): Trong quá trình làm việc, bạn sẽ cần sử dụng các công cụ quản lý công việc như Jira, Trello, Asana, Microsoft Project... để theo dõi tiến độ công việc, quản lý các đầu việc và phối hợp với các thành viên trong nhóm.
Sử dụng AI trong công việc: Đây là kỹ năng mới nhưng đang nhanh chóng trở thành mặc định của nghề. Điều quan trọng bạn cần hiểu ngay từ đầu: AI không lấy mất việc của BA, nhưng nó lấy đi phần lớn thời gian làm tay — và đẩy giá trị của bạn về phía phân tích, quyết định và review.
Gần như mọi tác vụ trong Phần 1 của bài này đều đã có AI hỗ trợ:
Tác vụ | AI làm được gì | Bạn vẫn phải làm gì |
|---|---|---|
Khơi gợi yêu cầu | Tóm tắt bản ghi buổi phỏng vấn, soạn mail xác nhận lại nội dung đã trao đổi, gợi ý những điểm còn mơ hồ nên hỏi thêm | Đặt câu hỏi đúng, đọc được ẩn ý và cảm xúc của người trả lời |
Đọc hiểu tài liệu cũ | Đọc cả kho tài liệu dự án rồi trả lời câu hỏi của bạn, thay vì bạn lật 500 trang | Biết câu nào đáng hỏi, và nghi ngờ khi câu trả lời nghe quá gọn |
Viết URD/SRS | Từ ghi chép elicitation, sinh ra bản nháp đúng format bạn đưa | Kiểm chứng từng dòng và chịu trách nhiệm nội dung |
User story | Sinh hàng loạt story từ một nhóm yêu cầu, giữ giọng văn nhất quán | Cắt phạm vi, quyết định story nào làm trước |
Acceptance criteria | Gợi ý các case dễ sót, soi lại AC bạn viết và chỉ chỗ mâu thuẫn | Chốt tiêu chí nào là bắt buộc, tiêu chí nào bỏ được |
Diagram và ERD | Sinh sơ đồ Mermaid/PlantUML từ mô tả bằng lời, cập nhật lại khi yêu cầu đổi | Kiểm tra sơ đồ có đúng nghiệp vụ thật không |
Prototype / wireframe | Dựng bản demo bấm được từ một đoạn mô tả (Reqwise Figma MCP, Claude Code, Antigravity, Codex, OpenCode...) | Đánh giá luồng có hợp lý với người dùng thật không |
Test case và checklist | Sinh test case từ AC, map lại đúng story | Bổ sung case đến từ hiểu biết nghiệp vụ |
Change request và cập nhật tài liệu | Khi có CR, tự dò xem những tài liệu nào bị ảnh hưởng, đề xuất chỗ cần sửa và viết luôn changelog | Duyệt thay đổi, quyết định có nhận CR hay không |
Gap analysis | Đọc chéo nhiều tài liệu, chỉ ra chỗ mâu thuẫn hoặc thiếu | Phán đoán mâu thuẫn nào nghiêm trọng |
Báo cáo tiến độ | Tổng hợp từ Jira, biên bản họp và tài liệu thành bản nháp báo cáo | Biết stakeholder cần nghe gì |
Đây cũng là lý do cập nhật tài liệu — việc từng khiến BA đau đầu nhất, sửa một chỗ quên ba chỗ — giờ là chỗ AI đỡ được nhiều nhất: change request vào, AI dò ra các tài liệu liên quan và ghi changelog thay bạn.
Ngược lại, có những phần AI không làm thay được, và đó chính là chỗ bạn nên đầu tư: hiểu nhu cầu thật đằng sau lời khách hàng nói, sắp xếp ưu tiên theo giá trị kinh doanh, quyết định cắt gì trong ràng buộc scope – time – budget, và điều phối những bên liên quan có quyền lợi mâu thuẫn nhau.
Hai điều cần nhớ khi dùng: luôn tự kiểm chứng lại — AI viết rất trôi chảy nhưng có thể bịa ra business rule không tồn tại, và bản nháp sai mà nghe hợp lý thì nguy hiểm hơn bản nháp trống; và cẩn thận với dữ liệu khách hàng — đừng dán tài liệu nội bộ hay dữ liệu thật vào công cụ công cộng khi chưa được phép. Chi tiết hơn, bạn xem bài Giới thiệu các công cụ AI.
Công cụ thiết kế và tạo wireframe (Wireframing): Để hình dung giao diện người dùng và luồng tương tác, BA thường sử dụng các công cụ thiết kế và tạo wireframe như Figma, Balsamiq, Axure... Wireframe giúp xác định phạm vi (scope) của dự án hoặc sản phẩm một cách trực quan cho các bên liên quan như khách hàng, designer và đội ngũ phát triển, đảm bảo mọi người có chung một hiểu biết về sản phẩm sẽ được xây dựng.
Kỹ thuật kiểm thử (Testing Techniques): BA cần có kiến thức cơ bản về các kỹ thuật kiểm thử phần mềm để có thể tham gia vào quá trình đảm bảo chất lượng sản phẩm, chẳng hạn như kiểm thử chức năng (Functional Testing), kiểm thử chấp nhận của người dùng (User Acceptance Testing - UAT).
Các công cụ kỹ thuật kể trên có thể giúp bạn tối ưu hoá hiệu suất công việc, nhưng để gắn kết mọi người và thúc đẩy dự án, bạn sẽ cần đến các kỹ năng mềm như giao tiếp, làm việc nhóm... — những kỹ năng quen thuộc được sử dụng nhiều trong cuộc sống hàng ngày. Việc áp dụng linh hoạt các kỹ năng mềm giúp bạn làm việc tốt với các bên liên quan, xử lý xung đột, và đảm bảo yêu cầu được hiểu đúng.
Dưới đây là những kỹ năng mềm quan trọng và minh hoạ cách chúng tạo giá trị trong công việc của BA.
Ngoài những kỹ năng đã được liệt kê ở trên, có rất nhiều kỹ năng khác mà một Business Analyst có thể cần đến trong quá trình làm việc, tuỳ thuộc vào từng dự án và lĩnh vực cụ thể.
Dựa trên kinh nghiệm nhiều năm làm Business Analyst của bản thân và tham khảo ý kiến từ các BA kỳ cựu trong ngành, bài viết này đã tổng hợp những kỹ năng thiết yếu mà một newbie BA cần trang bị để có thể tự tin và vững bước trên con đường sự nghiệp.
Chúc bạn thành công trên hành trình trở thành một Business Analyst chuyên nghiệp! Hãy nhớ rằng, sự kiên trì, đam mê và tinh thần học hỏi sẽ là những người bạn đồng hành tốt nhất của bạn.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận