Bài viết thứ 4 trong chuỗi bài “Tự học IT Business Analyst”

IT Business Analyst (ITBA) là một vị trí yêu cầu kết hợp của rất nhiều kỹ năng mềm và kỹ năng chuyên môn nghiệp vụ. Để làm tốt vị trí BA, thì cần khá nhiều thời gian để rèn luyện – nắm vững các kỹ năng và công cụ để phân tích, giao tiếp và làm việc hiệu quả với các bên liên quan.

Trong bài viết này mình sẽ chia sẻ những kỹ năng cần thiết và khá phổ biến khi làm IT Business Analyst nhé.

Bài viết cũ

Cách đây một thời gian mình cũng viết một bài liên quan đến các kỹ năng cần cho một internship khi làm BA theo cách nhìn và cách tuyển dụng của mình.

Bạn có thể đọc ở bài đây nhé

Thực tập IT Business Analyst cần những kỹ năng gì?

Tiếp theo đây mình vẫn chia sẻ những kỹ năng khác đầy đủ hơn.

IT Business Analyst cần những kỹ năng gì?

1. Kỹ năng về giao tiếp

Từ giao tiếp ở đây trong tiếng Anh mình đang muốn nói tới từ “Interpersonal skills“, 

Nó bao gồm:

• Kỹ năng làm việc với những người khác (dev team, stakeholders, c-level,…)
• Kỹ năng giao tiếp (communicate): gồm biết cách
  • Truyền đạt thông tin hiệu quả, rõ ràng, chính xác => này cả việc viết tài liệu & thuyết trình.
  • Lắng nghe và hiểu nhu cầu từ các bên liên quan
  • Đàm phán, thương lượng, thường là giải thích solutions, thuyết phục stakeholders theo một hướng nào đó tốt cho dự án, đôi lúc có xung đột giữa các bên cũng biết cách xử lý.
• Kỹ năng về ngoại ngữ: Giờ tiếng Anh là một cái buộc phải có của BA, dù bạn BA cho công ty Nhật thì cũng cần phải biết tiếng Anh, đa số các kiến thức về BA, nghiệp vụ, công nghệ được viết trong tiếng Anh => Có tiếng Anh hỗ trợ việc đó, Ngoài ra nếu là công ty sử dụng tiếng Anh trong giao tiếp thì càng tốt, có tiếng Anh => Tăng lương, tăng cơ hội việc làm,… Nếu không là công ty sử dụng tiếng Anh => Thì biết thêm tiếng Nhật, Hàn, Thái … tuỳ mỗi công ty 😀

2. Kỹ năng đặt câu hỏi

Hình như không mấy bài viết về kỹ năng này, nhưng mình nghĩ kỹ năng này rất rất quan trọng cho người làm Business Analyst luôn.

• Luôn luôn hỏi “Tại sao?”, “Tại sao?”, và “Tại sao?”.
• Câu hỏi này dành cho Stakeholders, các thành viên khác và hỏi cả chính mình, từ đó mà có thể tìm ra được vấn đề gốc rễ, những điều bạn chưa biết, chưa rõ để làm rõ nó, từ đó phân tích ra được giải pháp phù hợp.
• Dĩ nhiên là khi hỏi “Tại sao” cũng cần có một sự tinh tế nhất định để phù hợp với từng bối cảnh cụ thể.
• Và “tự thì thầm nói chuyện” với bản thân, tự đặt câu hỏi với chính bản thân bạn, đây là một trong những kỹ thuật mình sài để tự khơi gợi (elicitation) và tìm ra đáp án cho các câu hỏi khó.

Bạn hãy nghiên cứu những loại câu hỏi sau, mình nghĩ sẽ có lợi cho bạn đoá:

• Câu hỏi làm rõ: Kiểu hỏi để làm rõ vấn đề, những thứ bạn chưa hiểu
  • Ví dụ 1: “Bạn có thể giải thích ý số 2 là như thế nào được không?”
  • Ví dụ 2: “Đăng nhập với email, ý bạn là cần mật khẩu hay với OTP?”
• Câu hỏi đóng: thường là để xác thực thông tin
  • Ví dụ: “Vậy đăng nhập với email sẽ gửi một link vào email và người dùng nhấn vào để xác thực đúng không?”
• Câu hỏi mở: khuyến khích người khác bày tỏ ý kiến
  • Ví dụ: “Bạn nghĩ gì về giải pháp này?”
• Câu hỏi giả định: đưa vào một tính huống giả định và hỏi xem có những khả năng nào xảy ra hoặc kiểu xem thử người được hỏi phản ứng như thế nào
  • Ví dụ 1: “Giả sử user đăng ký, và luồng là tự động đăng nhập sau khi đăng ký, vậy email nằm trong blacklist có tự động đăng nhập được hay không?”
  • Ví dụ 2: “Giả sử như giải pháp không được lãnh đạo duyệt thì sẽ làm gì?”
• Câu hỏi thăm dò: nhằm kháp phá sâu hơn về một vấn đề cụ thể, khuyến khích người được hỏi cung cấp thêm thông tin hoặc suy nghĩ kỹ hơn về câu trả lời của họ.
  • Ví dụ 1: “Bạn có thể cung cấp thêm chi tiết về những phần của hệ thống đang hoạt động chậm?”
  • Ví dụ 2: “Bạn có thể mô tả cụ thể hơn về ý nghĩa của ‘dễ sử dụng’ trong bối cảnh này không? Ví dụ, bạn đang nghĩ đến giao diện người dùng, tốc độ phản hồi của hệ thống, hay mức độ đào tạo cần thiết cho người dùng mới?”
  • Ví dụ 3: “Có ví dụ nào từ hệ thống hiện tại hoặc từ các ứng dụng khác mà bạn cho là dễ sử dụng không? Điều gì trong đó mà bạn nghĩ sẽ hữu ích cho hệ thống mới?”
• Câu hỏi dẫn dắt: Dẫn mọi người đi theo 1 hướng cụ thể hoặc đồng ý với 1 quan điểm nhấn định => nhưng nên cẩn thận vì tránh ảnh hưởng đến tính khách quan.
  • Ví dụ 1: “User chắn chắn sẽ thích giao diện mới này hơn, vì nó trực quan hơn nhiều, các bạn thấy vậy đúng không?”
  • Ví dụ 2: “Bạn cũng đồng ý rằng việc thêm tính năng báo cáo tự động sẽ giúp tiết kiệm rất nhiều thời gian cho team, đúng không?”
• Câu hỏi đối chiếu: Kiểu dẫn dắt việc trả lời so sánh 2 hoặc nhiều lựa chọn => giúp đánh giá ưu và nhược điểm của từng phương án
  • Ví dụ 1: “Giải pháp A và B, cái nào tốt hơn nhỉ?”
  • Ví dụ 2: “Dự án này nên theo WaterFall hay Agile sẽ phù hợp hơn?”

3. Khả năng “Take notes”

😀 BA thường tham gia nhiều cuộc họp thảo luận, rồi trao đổi với nhiều bên, gathering requirements, tránh bỏ sót những chi tiết quan trọng => Cần take notes lại để sau còn phân tích, đưa ra solutions, viết docs, cập nhật docs các kiểu. Do đó kỹ năng này rất quan trọng với người làm IT Business Analyst.

Nguyên tắc cơ bản

Để tốt khả năng take notes thì có 1 số nguyên tắc cơ bản mình gợi ý như sau, bạn có thể nghiên cứu và học thêm nhé.

• Xác định mục tiêu ghi chép: Trả lời những câu hỏi “bạn cần ghi lại những thông tin gì?” “những điểm nào là quan trọng nhất?”
• Sử dụng từ khoá/cụm ngắn gọn: Viết ngắn gọn, dùng từ khoá, hoặc dùng các ký hiệu để tiết kiệm thời gian, không gian, vì đâu ai đang nói cái đợi bạn ghi notes lại đâu phải không? =)) => Nhưng không có nghĩa bạn được hỏi lại nhé… do đó tận dụng việc hỏi lại để xác thực thông tin.
• Sử dụng ứng dụng, hoặc giấy bút hợp lý, tuỳ thuộc vào cái nào tiện: tuỳ theo mỗi bạn, có thể viết note vào bút nếu bạn ghi chép nhanh và quản lý tốt, còn không thì có thể sài những phần mềm take notes như: Onenote, Evernote, Notion, Sticky Notes, Google Docs, Ms Word. => Như mình thì chỉ sài phần mềm thôi, gõ nhanh hơn nhiều :3
• Tổ chức thông tin hợp lý: Nên học vài phương pháp ghi chép phổ biến => từ đó luyện và ghi thành cấu trúc hợp lý kiểu như có tiêu đề, đánh số, gạch đầu dòng,… Sau đọc lại còn biết ý nào ý chính, ý nào ý phụ, tìm kiếm thông tin cũng dễ dàng hơn.
• Highlight những điểm quan trọng: Kiểu như sài dấu sao, tô đỏ, tô đậm, gạch chân, để sau này đọc lại còn chú ý những điểm đó
• Được thì tổng hợp lại mấy cái bạn notes, xong gửi lại cho team/người tham gia cuộc họp để họ đọc & xác nhận lại. Hoặc đơn giản chỉ gửi thôi.
• Bạn cần lắng nghe 1 cách chủ động, đừng ngại hỏi, khi viết xong thì dành thời gian đọc lại, đôi lúc cần điều chỉnh cho hợp lý, lưu trữ nơi dễ truy cập, ngăn nắp.

Phương pháp

• Phương pháp outline, cách này mình hay sài: sắp xếp thông tin theo dạng thứ tự từ trên xuống, kiểu như viết sách ấy, đánh 1, 2, 3 hoặc I, II, III,.. cho tiêu đề, dưới thì a, b, c, … gạch đầu dòng (-)
  • Ví dụ:
    1. Yêu cầu dự án
    – Hệ thống cần hỗ trợ đa ngôn ngữ
    – Phải tích hợp với hệ thống CRM hiện tại
    2. Thời hạn và ngân sách
    – Thời hạn hoàn thành: 3 tháng
    – Ngân sách dự kiến: $50,000
• Phương pháp Cornell: Chia làm 3 phần (dạng kẻ bảng),này mình cũng có sài, hay viết trên excel, nhưng cũng ít chứ không nhiều.
  • Phần 1: Bên trái: Kiểu như ghi từ khoá/ý chính
  • Phần 2: Bên phải: Ghi chi tiết nội dung (dạng tóm tắt)
  • Phần 3: Ghi tóm tắt toàn bộ nội dung (mình ít khi viết phần này lắm :v)

  • Từ khoá/Ý chính	Ghi chép chi tiết
    Yêu cầu hệ thống	Hỗ trợ đa ngôn ngữ Tích hợp với CRM hiện tại Người dùng cần quyền truy cập hạn chế
    Thời hạn & Ngân sách	Thời hạn 3 tháng Ngân sách $50,000Ví dụ:

    Tóm tắt: Dự án yêu cầu hệ thống đa ngôn ngữ, tích hợp với CRM, và phải hoàn thành trong 3 tháng với ngân sách $50,000.

• Phương pháp sài mindmap: Mình cũng ít sài mấy này lắm 😀 Nhưng share cho bạn biết, có thể phù hợp với bạn.
  • 

4. Kỹ năng gathering requirements

Kiểu các kỹ năng, techniques, hiểu các bước cần thực hiện để làm sao đó Gathering requirements một cách hiệu quả.

Gathering ở đây không phải là “Lấy”, mình cũng không biết dịch sao cho hợp lý, kiểu như bạn phải đi thu thập nhưng không phải nó có sẵn mà bạn phải nỗ lực để khơi gợi, làm việc, trao đổi, phân tích thì mới có được.

Sẽ có 1 bài viết về phần này kỹ hơn ở sau, bạn tìm đọc trong chuỗi bài viết của mình nhé.

5. Kỹ năng Thinking & Visualize

• Tư duy phân tích: Phân tích từ vấn đề phức tạp thành những vấn đề nhỏ hơn, để tìm ra được giải pháp.
• Tư duy phản biện: Kiểu hỏi, tự phản biện, đánh giá và phân tích thông tin một cách khách quan để đưa ra quyết định sáng suốt.
• Tư duy hệ thống: Khả năng hiểu và phân tích một ván đề một cách hệ thống, hơi thiên kiểu như A thì dẫn đến B, Rồi B lại ra 2-3 trường hợp C1, C2, C3, …
• Creative thinking: Kiểu tư duy sáng tạo, bạn nghĩ ra cái mới, hoặc tìm ra cách tiếp cận mới mẻ (innovation) để giúp cho dự án đi tới được mục đích một cách hay hơn, không đi theo khuôn khổ.
• Tư duy hình dung/mô hình hoá dữ liệu (Visualize): Kiểu như từ một bài toán, mọi người nói và chia sẻ, nhưng những thông tin đó khó hình dung => Ta đưa nó về 1 dạng visualize. Như mình thì mình hay vẽ wireframe, takenote trên đó, vẽ userflow, hoặc modal overview, hoặc là diagram để cấu trúc lại nội dung sau đó dùng nó để phân tích, điều chỉnh thêm.
• Tư duy vẽ bức tranh toàn cảnh: Mình hay phân tích vẽ đi từ bức tranh toàn cảnh vào, lúc nào cũng vẽ các thành phần của hệ thống, cách chúng kết nối, sau đó mới đi vào chi tiết hơn.

6. Kỹ năng viết docs/tài liệu

Bao gồm việc vẽ sequence, activity diagram, Usecases, User story, UML, BRD, URD, SRS, …

Kể cả việc vẽ wireframe, mockup, đôi lúc là UI design

Bạn đọc bài: https://hoangphan.blog/thuc-tap-it-business-analyst-can-nhung-ky-nang-gi/ để kỹ hơn phần này nhé.

7. Hiểu biết về Công nghệ và hệ thống

Như số 5, bạn đọc thêm trong bài viết mình đã viết trước đó nhé.

Không phải là kiểu bạn cái gì cũng biết, như code bạn không cần biết code giỏi, nhưng ít nhất biết cách hệ thống/code nó hoạt động, ví dụ đang phân tích tính năng “Calendar” cho chọn range ngày A=>B, mà nó yêu cầu animation các kiểu, thì bạn cũng cần biết ít nhiều để mà biết chắc là cái này Dev làm được chứ không đưa ra 1 tính năng mà Dev chả làm được, hoặc tốn rất rất nhiều thời gian, kinh phí.

Như mình thì từ dân Dev ra, trước cũng code được sơ sơ nên giờ phần đó khá lợi thế với mình, kiểu mình có thể ước chừng tính năng mất khoảng bao lâu thì xong nếu Dev đang ở level nào, làm được tính năng đó hay không? Hay thậm chí đi tìm code mẫu gửi cho dev luôn.

Hoặc kiểu như giờ các dự án dính tới vụ API khá nhiều => cần có kiến thức để mà đi đọc docs của đối tác, xem bên mình tích hợp được không? nếu tích hợp được thì luồng như thế nào.

8. Kỹ năng tư duy, chiến lược

• Tư duy chiến lược: Khả năng nhìn nhận các vấn đề kinh doanh từ góc nhìn chiến lược, đảm bảo rằng các giải pháp được đề xuất không chỉ giải quyết các vấn đề trước mắt mà còn hỗ trợ mục tiêu dài hạn của doanh nghiệp.
• Tư duy hệ thống: Hiểu biết về cách các yếu tố trong hệ thống công nghệ và kinh doanh tương tác với nhau, và cách các thay đổi trong một phần của hệ thống có thể ảnh hưởng đến toàn bộ hệ thống, hoặc ảnh hưởng 1 phần => từ đó nhắc Dev, QC chú ý tới để tránh xảy ra lỗi.

9. Hiểu biết chút về UI/UX

• Biết cách vẽ wireframe, biết cách cấu trúc (layers), dùng các phần mềm vẽ như Figma, Axure, Balsamiq đồ.
• Biết chút về WCAG để khi mà UI vẽ ra, mình test được, tránh phạm quá lỗi này.
• Khi vẽ wireframe, thì không phải vẽ riêng biệt các screens, mà kiểu vẽ rồi link chúng nó lại với nhau, nhấn nút nào thì điều hướng tới đâu, đó là 1 phần của User Flow, UX, nên bạn có hiểu biết về UX để khi vẽ tối ưu được luồng, biết cách đặt button đâu cho hợp lý… Đôi lúc còn biết kiến thức mà cãi lại UI/UX team nữa :v mình hay vậy lắm, kkk. Đùa thôi!!! Tuỳ trường hợp.

10. Hiểu biết về Business/Domain

😀 Ví dụ làm BA Banking, thì bạn phải hiểu nghiệp vụ về Bank, làm bảo hiểm thì phải biết bảo hiểm là gì, nó thường có những tính năng gì, hoạt động ra sao,…

Này chắc không cần giải thích gì nhiều. … 😀

Ngoài ra bạn cũng hiểu thêm chút về tài chính, kiểu như khi build hệ thống nên biết về cách hệ thống làm ra tiền, hệ thống nào build chả support cho việc làm ra tiền đúng không? Hoặc kiểu giống như ảnh hưởng tới tài chính/business á => hiểu biết thì sẽ giúp bạn hiểu cái gốc rễ của việc làm ra hệ thống hơn => đưa những solutions hợp lý, chứ k thể nghe sao là làm vậy, BA phải tư duy lên.

11. Các kỹ năng khác

Mình nghĩ IT BA không chỉ dừng lại là cần những kỹ năng mình kể trên đâu, mà nó cần phối hợp nhiều kỹ năng khác nữa…

Mình chỉ kể 1 phần, trong quá trình làm việc các bạn có thể nhận ra thêm nha.

 

Bạn tìm và đọc tiếp những bài tiếp theo của mình nhé.