"BA level-up" - Số 02: Kỹ năng Technical cho BA - hiểu về hệ thống để cộng tác hiệu quả với Team Dev
- Tuan Anh
- 1 ngày trước
- 5 phút đọc
Tiếp tục hành trình nâng cấp bản thân, sau khi đã thông suốt về lộ trình sự nghiệp và những "điểm nghẽn" tư duy, hôm nay mình muốn cùng các bạn mổ xẻ một chủ đề mà rất nhiều BA (đặc biệt là các bạn trái ngành) thường cảm thấy "rén": Kỹ năng Technical cho BA.
Có bao giờ bạn rơi vào cảnh ngồi trong buổi họp với Team Dev mà cảm giác như họ đang nói tiếng... ngoài hành tinh? Họ thảo luận về API, Frontend, Backend, Database, Microservices... còn bạn thì chỉ biết gật đầu và ghi lại những từ khóa đó một cách vô hồn?
Sai lầm lớn nhất của BA là nghĩ rằng: "Mình làm nghiệp vụ, kỹ thuật là việc của Dev".
Đúng, bạn không cần phải tự tay viết code. Nhưng nếu không hiểu về hệ thống, bạn sẽ mãi chỉ là một "BA thư ký", người chuyển lời một cách máy móc. Một BA thực thụ (mình gọi là BA kiến trúc sư) cần có đủ nền tảng kỹ thuật để hiểu xem giải pháp mình đề xuất có khả thi không, nó ảnh hưởng đến các module khác như thế nào, và quan trọng nhất: để nhận được sự nể trọng từ Team Dev.
Dưới đây là bản đồ kỹ năng Technical có thể giúp các bạn "phá băng" và cộng tác hiệu quả với đội dev.
---------------
PHẦN 1: TƯ DUY HỆ THỐNG (SYSTEM THINKING) - GỐC RỄ CỦA MỌI VẤN ĐỀ
Trước khi học công cụ, các bạn cần học cách nhìn sản phẩm dưới góc độ một Hệ thống.
Kỹ năng này giúp bạn hiểu cách các thành phần công nghệ tương tác với nhau để tạo ra giá trị cho người dùng. Khi khách hàng yêu cầu một tính năng mới, phản xạ của bạn không phải là vẽ giao diện ngay, mà là phân tích:
Dữ liệu này lấy từ đâu? (Database)
Xử lý logic nằm ở đâu? (Backend)
Hiển thị cho người dùng như thế nào? (Frontend)
Nó có cần lấy thông tin từ bên thứ ba không? (API/Integration)
Chiến thuật: Hãy luôn đặt câu hỏi "Cái này chạy như thế nào?" thay vì chỉ quan tâm đến bề nổi.
---------------
PHẦN 2: BỘ KHUNG IT CƠ BẢN - NGÔN NGỮ CHUNG VỚI DEV
Để "nói chuyện" được với Dev, bạn cần nắm vững các khái niệm nền tảng sau:
Frontend & Backend: Sự tách biệt giữa hiển thị và xử lý
Frontend: Là tất cả những gì người dùng nhìn thấy và tương tác (HTML, CSS, Javascript, Mobile App). Bạn cần hiểu về UI/UX và các hạn chế của từng nền tảng (Web vs Mobile).
Backend: Là "bộ não" xử lý logic, tính toán và quản lý dữ liệu (Java, Python, .Net...). Khi viết User Story, hãy phân biệt rõ cái nào là thay đổi giao diện, cái nào là thay đổi logic xử lý.
Database (Cơ sở dữ liệu): Kho lưu trữ thông tin
Hệ thống không thể hoạt động nếu thiếu dữ liệu. BA cần hiểu về Relational Database (RDBMS) - nơi dữ liệu được tổ chức thành các bảng có mối liên hệ với nhau qua các khóa (Primary Key - PK và Foreign Key - FK).
Pro-tip: Đừng chỉ dừng lại ở việc biết dữ liệu có tồn tại. Hãy tìm hiểu về ERD (Entity Relationship Diagram) để biết thực thể A quan hệ với thực thể B như thế nào (1-1, 1-n, hay n-n).
API & Communication Protocols: Hệ thần kinh của hệ thống
Trong thời đại hiện nay, hiếm có hệ thống nào đứng độc lập. API (Application Programming Interface) chính là "hợp đồng" giúp các hệ thống nói chuyện với nhau.
Bạn cần hiểu API hoạt động theo cơ chế Request - Response.
Nắm được các phương thức cơ bản: GET (lấy dữ liệu), POST (tạo mới), PUT/PATCH (cập nhật), DELETE (xóa).
Học cách sử dụng các công cụ như Postman để "test thử" các API. Việc này giúp bạn xác thực yêu cầu nhanh hơn mà không cần đợi Dev xong giao diện.
---------------
PHẦN 3: SQL - "VŨ KHÍ" CỦA BA
Nếu phải chọn một kỹ năng kỹ thuật quan trọng nhất để BA đứng vững, đó chính là SQL (Structured Query Language).
Tại sao BA cần SQL?
Xác thực yêu cầu: Khi khách hàng nói "Hệ thống đang lỗi, dữ liệu sai", bạn có thể tự mình truy vấn để kiểm tra thay vì ngồi đợi Dev.
Phân tích tác động (Impact Analysis): Trước khi thay đổi một logic, bạn dùng SQL để xem có bao nhiêu dữ liệu cũ bị ảnh hưởng.
Data Storytelling: Dùng dữ liệu thực tế để thuyết phục Stakeholder thay vì nói bằng cảm tính.
Lộ trình học SQL cho các bạn:
Data Definition Language (DDL): Hiểu cách cấu trúc bảng được tạo ra (CREATE, ALTER, DROP).
Data Manipulation Language (DML): Đây là phần các bạn dùng nhiều nhất. Phải thành thạo SELECT, INSERT, UPDATE, DELETE.
Advanced SQL: Học cách nối các bảng (JOIN), nhóm dữ liệu (GROUP BY) và các hàm tính toán (SUM, AVG, COUNT).
Tip: Hãy bắt đầu với SQLite, nó đơn giản, không cần cấu hình phức tạp và cực kỳ phù hợp để học nền tảng.
---------------
PHẦN 4: HẠ TẦNG VÀ CÔNG NGHỆ MỚI (INFRASTRUCTURE & TRENDS)
Một Senior BA hoặc Technical BA cần nhìn rộng hơn về phía hạ tầng:
Server & Cloud (Azure, AWS): Hiểu cách các sản phẩm công nghệ vận hành trên đám mây giúp bạn tư vấn về tính ổn định và mở rộng của hệ thống.
Cấu trúc Microservices: Thay vì một khối khổng lồ (Monolithic), hệ thống giờ đây được chia thành các dịch vụ nhỏ. Kỹ năng mô hình hóa các tương tác giữa các dịch vụ (Sequence Interaction) là cực kỳ quý giá.
AI & Automation: Đừng coi AI là đối thủ. Hãy học cách sử dụng AI như một "đệ tử" để viết tài liệu nháp, tóm tắt cuộc họp hoặc thậm chí là hỗ trợ viết các câu lệnh SQL phức tạp.
---------------
PHẦN 5: CHIẾN THUẬT CỘNG TÁC "2 CHIỀU" ĐỂ DEV PHẢI NỂ
Kỹ năng kỹ thuật của bạn chỉ thực sự phát huy tác dụng khi nó được chuyển hóa thành hiệu quả giao tiếp.
Giao tiếp bằng ngôn ngữ Logic với Dev Team
Khi làm việc với Dev, hãy dẹp bỏ những câu nói mơ hồ kiểu "em muốn nó trông xịn xịn". Thay vào đó:
Sử dụng ngôn ngữ chính xác, chi tiết.
Cung cấp đầy đủ Acceptance Criteria (AC) theo định dạng Gherkin (Given/When/Then) để Dev biết chính xác điều kiện đầu vào và kết quả đầu ra, hoặc ít nhất hãy nêu rõ context, input và expected output.
Sử dụng sơ đồ trực quan như Activity Diagram hay Sequence Diagram thay vì viết văn bản dài dòng.
Trở thành "Quality Gate" cho kết quả từ kỹ thuật
Đừng tin tưởng 100% vào những gì Dev nói là "xong rồi". Hãy dùng kiến thức kỹ thuật của bạn để kiểm định (validate). Kiểm tra xem giải pháp có ảnh hưởng đến các module khác không (Impact Analysis), dữ liệu trong Database có khớp với hiển thị trên giao diện không.
---------------
KẾT LUẬN: KỸ NĂNG TECHNICAL CHO BA - MINDSET LÀ THEN CHỐT
Các bạn nhớ là, mục tiêu của BA học kỹ thuật không phải là để đi tranh cãi với Dev xem code nào tối ưu hơn. Mục tiêu là để:
Hiểu bản chất hệ thống để đưa ra giải pháp "đúng" và "trúng".
Thu hẹp khoảng cách giữa Nhu cầu kinh doanh và Khả năng thực thi công nghệ.
Xây dựng lòng tin và sự tin cậy - chất keo kết dính cả đội dự án.
Làm ra một hệ thống không khó. Làm ra đúng cái mà người ta chịu dùng và hệ thống vận hành trơn tru mới khó.
---------
Bài viết cùng Series:
Bình luận