--- title: "Kỹ năng BA cho người mới bắt đầu: Hành trang thiết yếu để thành công" url: "https://bahub.vn/khoa-hoc/ba-foundation/ky-nang-ba-cho-nguoi-moi-bat-dau" author: "Hải Đăng, Phan Minh Hoàng" published: "2026-08-14" updated: "2026-08-16" source: "bahub.vn" license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc." --- # Kỹ năng BA cho người mới bắt đầu: Hành trang thiết yếu để thành công > 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. - Nguồn: https://bahub.vn/khoa-hoc/ba-foundation/ky-nang-ba-cho-nguoi-moi-bat-dau - Tác giả: Hải Đăng, Phan Minh Hoàng - Khoá học: BA Foundation (mục lục: https://bahub.vn/khoa-hoc/ba-foundation.md) - Chương: Nhập môn và định hướng nghề nghiệp 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é! ## Phần 1: Kỹ năng chuyên môn — nền tảng cốt lõi của một BA ### [Kỹ năng khơi gợi yêu cầu](https://bahub.vn/khoa-hoc/ba-foundation/ky-thuat-khoi-goi-yeu-cau-elicitation-phong-van-workshop-quan-sat) (Requirements Gathering and Elicitation) 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: * Phân tích các tài liệu hiện có (Document Analysis) * Phỏng vấn trực tiếp (Interviews) * Thực hiện khảo sát (Surveys) * Tổ chức các buổi Workshop ![Phỏng vấn và khảo sát các bên liên quan để khơi gợi yêu cầu](https://bahub.vn/uploads/2026/08/1786809086931-fvp91r-can-ky-nang-gi-de-lam-business-analyst-cho-nguoi-m.webp "Phỏng vấn và khảo sát các bên liên quan để khơi gợi yêu cầu") **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: * **Chuẩn bị:** Xác định mục tiêu (hiểu khó khăn, mong muốn về đặt lịch), chuẩn bị câu hỏi mở như "Anh/chị đang gặp vấn đề gì khi đặt lịch khám/chữa bệnh?" * **Thực hiện:** Tạo không khí thoải mái, lắng nghe chủ động, ghi chú chi tiết. * **Kết quả:** * Yêu cầu chức năng: Chọn bác sĩ, xem lịch trống, nhận xác nhận lịch hẹn. * Yêu cầu phi chức năng: Trang xem lịch trống tải xong dưới 3 giây; người dùng lần đầu đặt được lịch trong vòng 2 phút; thông tin cá nhân và hồ sơ khám được mã hoá khi lưu trữ và khi truyền. Để ý 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](https://bahub.vn/khoa-hoc/ba-foundation/phan-biet-yeu-cau-chuc-nang-va-phi-chuc-nang). 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. ### Kỹ năng phân tích yêu cầu (Requirements Analysis) 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ư: * [BACCM](https://bahub.vn/khoa-hoc/ba-foundation/cac-nhom-kien-thuc-danh-cho-ba-tu-babok) (Business Analysis Core Concept Model) * SWOT Analysis (phân tích điểm mạnh, điểm yếu, cơ hội, thách thức) * Business Process Modeling (mô hình hoá quy trình nghiệp vụ) để hiểu sâu hơn về bối cảnh và nhu cầu. **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: * **Nhu cầu (Need):** Bệnh nhân muốn đặt lịch khám nhanh chóng mà không cần gọi điện hay xếp hàng. * **Giải pháp (Solution):** Cung cấp giao diện trực quan để chọn bác sĩ, xem lịch trống và xác nhận hẹn. * **Bên liên quan (Stakeholder):** Bao gồm bệnh nhân (người dùng), bác sĩ, nhân viên phòng khám, và đội phát triển ứng dụng. * **Giá trị (Value):** Tiết kiệm thời gian cho bệnh nhân, tăng hiệu quả quản lý lịch cho phòng khám. * **Bối cảnh (Context):** Nhu cầu sử dụng ứng dụng y tế tăng cao do người dùng ưu tiên dịch vụ trực tuyến. * **Thay đổi (Change):** Cập nhật hệ thống để tích hợp tính năng đặt lịch và gửi thông báo xác nhận tự động. ![BACCM — sáu khái niệm cốt lõi và quan hệ giữa chúng](https://bahub.vn/uploads/2026/08/1786810143147-h184vt-ky-nang-ba-baccm.webp "BACCM — sáu khái niệm cốt lõi và quan hệ giữa chúng") 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. ### Kỹ năng tài liệu hoá yêu cầu (Requirements Documentation) 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](https://bahub.vn/khoa-hoc/ba-foundation/cac-loai-tai-lieu-ba-thuong-tao-brd-srs-user-stories-meeting-minutes) 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](https://bahub.vn/khoa-hoc/ba-foundation/gioi-thieu-ve-user-story-va-cach-viet-hieu-qua) | 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](https://bahub.vn/khoa-hoc/ba-foundation/usecase-la-gi-khi-nao-nen-su-dung-usecase) | 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. ### Kỹ năng quản lý yêu cầu (Requirements Management) 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: * **Quản lý phiên bản (version):** Mỗi tài liệu cần có lịch sử thay đổi rõ ràng — ai sửa, sửa gì, ngày nào. Khi có tranh luận "sao lúc trước không phải vậy", đây là chỗ bạn tra lại. * **Cập nhật tài liệu:** Sau khi một thay đổi được duyệt, tài liệu phải được sửa lại ngay để luôn phản ánh đúng yêu cầu tại thời điểm hiện tại. Tài liệu lệch với thực tế còn nguy hiểm hơn không có tài liệu. * **Truyền đạt thay đổi:** Chủ động thông báo cho đội phát triển, QC và các bên liên quan biết cái gì vừa đổi và đổi ở đâu. Đừng mặc định mọi người sẽ tự đọc lại tài liệu. * **Đánh giá tác động:** Trước khi chấp nhận một thay đổi, xem nó ảnh hưởng tới những tính năng nào, tốn thêm bao nhiêu công sức và có làm chậm tiến độ hay không. * **Sắp xếp độ ưu tiên:** Không phải yêu cầu nào cũng phải làm ngay. Phân loại để đội ngũ tập trung vào phần cốt lõi trước. ### Kỹ năng mô hình hoá (Modeling) Đôi khi, việc diễn đạt bằng lời nói hoặc chữ viết không đủ. Bạn có thể sử dụng các sơ đồ (như Use Case, Activity Diagram, Data Flow\...) và các mô hình trực quan (như [UML](https://bahub.vn/khoa-hoc/ba-foundation/gioi-thieu-ve-uml-va-cac-diagram-ba-hay-dung-use-case-activity-sequence), [BPMN](https://bahub.vn/khoa-hoc/ba-foundation/gioi-thieu-ve-bpmn-va-loi-ich-trong-mo-hinh-hoa-quy-trinh-nghiep-vu)) để biểu diễn và truyền đạt các yêu cầu và quy trình một cách dễ hiểu và nhanh chóng hơn. ![Dùng sơ đồ để truyền đạt yêu cầu và quy trình](https://bahub.vn/uploads/2026/08/1786809130552-vevbyv-can-ky-nang-gi-de-lam-business-analyst-cho-nguoi-m.webp "Dùng sơ đồ để truyền đạt yêu cầu và quy trình") Bạn sẽ làm quen với [các công cụ như Draw.io, Visio, Lucidchart](https://bahub.vn/khoa-hoc/ba-foundation/gioi-thieu-cac-cong-cu-ba-pho-bien-phan-2-cong-cu-ve-diagram-draw-io-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ụ:** * **BPMN:** Quy trình "Đặt lịch hẹn bác sĩ" với các bước: Chọn chuyên khoa → Xem lịch bác sĩ → Đặt lịch → Nhận xác nhận. * **Use Case:** Tương tác giữa "Bệnh nhân" và hệ thống với các Use Case như "Chọn bác sĩ", "Xác nhận lịch hẹn". ![Sơ đồ quy trình đặt lịch hẹn bác sĩ theo hai làn Bệnh nhân và Hệ thống](https://bahub.vn/uploads/2026/08/1786810143882-f8yksk-ky-nang-ba-bpmn.webp "Sơ đồ quy trình đặt lịch hẹn bác sĩ theo hai làn Bệnh nhân và Hệ thống") ### [Kiến thức về lĩnh vực kinh doanh](https://bahub.vn/khoa-hoc/ba-foundation/tam-quan-trong-cua-domain-knowledge-va-cach-hoc) (Domain Knowledge) 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... ### Hiểu biết về các phương pháp phát triển phần mềm (Software Development Methodologies) 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: * **Agile** không phải một phương pháp cụ thể, mà là một tập giá trị và nguyên tắc (theo Agile Manifesto) — ưu tiên phản hồi sớm, làm việc theo từng phần nhỏ và chấp nhận thay đổi. * **Scrum** là một _framework_ triển khai tinh thần Agile, với sprint, backlog và các vai trò được định nghĩa rõ. * **Kanban** là một _phương pháp quản lý luồng công việc_ — trực quan hoá công việc trên bảng và giới hạn số việc đang làm cùng lúc (WIP). Kanban không phải framework như Scrum, và có thể áp lên quy trình đang có mà không cần đổi vai trò. * **Waterfall** là cách tiếp cận vòng đời tuần tự: làm xong giai đoạn này mới sang giai đoạn kế, yêu cầu được chốt sớm. Đ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](https://bahub.vn/khoa-hoc/ba-foundation/gioi-thieu-cac-mo-hinh-phat-trien-phan-mem-waterfall-agile-scrum). ![So sánh cách BA làm việc trong Waterfall và trong Scrum](https://bahub.vn/uploads/2026/08/1786810144472-5y33s9-ky-nang-ba-scrum-waterfall.webp "So sánh cách BA làm việc trong Waterfall và trong Scrum") ### [Kỹ năng quản lý các bên liên quan](https://bahub.vn/khoa-hoc/ba-foundation/stakeholder-la-ai-cach-xac-dinh-va-lam-viec-voi-stakeholder) (Stakeholder Management) 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. ## Phần 2: Kỹ năng kỹ thuật — tăng tốc và tối ưu hoá hiệu quả công việc ![Bộ công cụ kỹ thuật hằng ngày của BA](https://bahub.vn/uploads/2026/08/1786809187568-zjdxs4-can-ky-nang-gi-de-lam-business-analyst-cho-nguoi-m.webp "Bộ công cụ kỹ thuật hằng ngày của BA") **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](https://bahub.vn/khoa-hoc/ba-foundation/mo-hinh-3-lop), cách các hệ thống trao đổi dữ liệu qua [API](https://bahub.vn/khoa-hoc/ba-foundation/api), và [cơ sở dữ liệu](https://bahub.vn/khoa-hoc/ba-foundation/sql)) 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](https://bahub.vn/khoa-hoc/ba-foundation/gioi-thieu-cac-cong-cu-ba-pho-bien-phan-1-jira-confluence), 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](https://bahub.vn/khoa-hoc/ba-foundation/gioi-thieu-cac-cong-cu-ai). **Công cụ thiết kế và tạo** [**wireframe**](https://bahub.vn/khoa-hoc/ba-foundation/wireframe-mockup-la-gi-tai-sao-ba-can-biet) **(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ử**](https://bahub.vn/khoa-hoc/ba-foundation/ky-nang-ve-testing-uat) **(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). ## Phần 3: Kỹ năng mềm — yếu tố then chốt cho sự hợp tác và thành công 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. ![Kỹ năng mềm giúp BA gắn kết các bên](https://bahub.vn/uploads/2026/08/1786809230197-vv7p2d-can-ky-nang-gi-de-lam-business-analyst-cho-nguoi-m.webp "Kỹ năng mềm giúp BA gắn kết các bên") 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. * **Kỹ năng giao tiếp (Communication):** Lắng nghe chủ động để hiểu nhu cầu bệnh nhân về "Đặt lịch hẹn bác sĩ", trình bày yêu cầu rõ ràng cho đội phát triển. * **Kỹ năng làm việc nhóm:** Phối hợp với đội kỹ thuật và bác sĩ để đảm bảo tính năng đặt lịch hoạt động mượt mà. * **Kỹ năng giải quyết vấn đề:** Đề xuất cách xử lý khi lịch hẹn bị trùng, như thêm kiểm tra tự động trong hệ thống. * **Tư duy phản biện:** Đánh giá xem yêu cầu tích hợp lịch cá nhân có thực sự cần thiết cho bệnh nhân hay không. * **Kỹ năng trình bày:** Thuyết phục stakeholder về lợi ích của giao diện đặt lịch đơn giản qua một bản demo trực quan. * **Kỹ năng quản lý thời gian:** Ưu tiên hoàn thiện tài liệu yêu cầu đúng hạn để không làm chậm tiến độ dự án. * **Kỹ năng đàm phán:** Thương lượng với đội phát triển để cân bằng giữa bảo mật dữ liệu và tốc độ đặt lịch. * **Khả năng thích ứng:** Nhanh chóng tìm hiểu và nghiên cứu về một lĩnh vực khi tham gia vào một dự án mới. 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ể. ## Lời kết 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. --- Nguồn: https://bahub.vn/khoa-hoc/ba-foundation/ky-nang-ba-cho-nguoi-moi-bat-dau — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.