Loading...
Tìm kiếm

Tag Archives: IT BA

Categories Business Analyst Chia sẻ

Khoá học sử dụng AI trong công việc cho IT Business Analyst (New)

by hoangphan Posted on
Khoá học sử dụng AI trong công việc IT Business Analyst

Khóa học sử dụng AI trong công việc cho IT Business Analyst (New)

Khoá này giúp gì cho bạn?

  • Kể từ khi ChatGPT 3.5 xuất hiện, nhiều người đã tận dụng AI để tối ưu hóa công việc của mình một cách hiệu quả.
  • Hoàng BA cũng nằm trong số đó, đã trải nghiệm và áp dụng AI vào công việc hàng ngày.
  • Với hơn 2 năm sử dụng AI liên tục, mình đã tích lũy được một số mẹo và kỹ năng hữu ích, đặc biệt trong các nhiệm vụ của BA/PM, giúp tiết kiệm thời gian và nâng cao hiệu suất làm việc.
  • Qua khóa học này, mình sẽ chia sẻ và hỗ trợ bạn biết cách sử dụng trong công việc BA / PM, để bạn cũng có thể làm việc thông minh và hiệu quả hơn!
Khoá học sử dụng AI trong công việc IT Business Analyst
Khoá học sử dụng AI trong công việc IT Business Analyst

Nội dung khóa học

BUỔI 1:

  • Hiểu cơ bản về AI
    • Giải thích cách AI hoạt động ở thời điểm hiện tại
    • Tìm hiểu AI models và AI Agent
  • Sử dụng AI:
    • Cách sử dụng AI cho đúng (hiệu quả hơn).
    • Đăng ký và tạo tài khoản, kiểm tra giá… để sử dụng một AI.
  • Một số AI mình hay sài: Giới thiệu về các AI mình hay dùng, cũng như chia sẻ kinh nghiệm, trải nghiệm cá nhân đến mọi người khi sử dụng AI.
  • Tạo Prototype với AI
    • Dùng v0.dev
    • Vibe coding (sharing ở buổi 2)

BUỔI 2:

  • Tạo UI/Wireframe với prototype vừa được tạo ra (mang lên Figma)
  • Viết Use cases
  • Vẽ diagram:
    • Flow chart
    • Activity Diagram
    • Sequence Diagram
    • Class Diagram
    • ERD

BUỔI 3:

  • Viết User story và AC
  • Tạo checklist và test cases với AI, đảm bảo độ coverage cao
  • Viết SRS
  • Viết User guide

BUỔI 4:

  • Hỏi đáp sau thực hành 2 tuần
  • Học và nghiên cứu tính năng mới
  • Một số tác vụ khác sử dụng AI
Timeline khoá học ITBA06
Timeline khoá học ITBA06 (này được tạo bởi AI)

Lợi ích của khóa học

  • Thực hành thực tế với các công cụ AI hiện đại.
  • Phát triển kỹ năng thiết kế, viết tài liệu và thử nghiệm bằng AI.
  • Cơ hội áp dụng kiến thức vào công việc thực tế, đặc biệt trong vai trò Business Analyst (BA), giúp bạn giảm rất rất nhiều thời gian khi làm công việc BA.
  • Tham gia group Telegram private được Hoàng hỗ trợ, cũng như được chia sẻ các kiến thức mới nhất về AI.
  • Một tháng sử dụng AI (mình sẽ mua 5 bạn/1 tài khoản) sài chung để thực hành, tài khoản này 1 tháng)
  • Các buổi học sẽ được record lại, mình sẽ gửi cho các bạn xem lại qua email.
  • Hỗ trợ trong vòng 3 tháng, giúp bạn thực hành và áp dụng trong công việc của bạn hiệu quả.

Thông tin đăng ký

Bạn sẵn sàng bắt đầu hành trình khám phá AI chưa? Hãy đăng ký ngay hôm nay để không bỏ lỡ cơ hội!

Hình thức đăng ký:

  • Vui lòng điền thông tin vào form: https://forms.gle/7ycSyGUyRcNpogMC6
  • Lớp 16 bạn, học 4 buổi
    • Buổi 1: Thứ 7 (05/04/2025), khung giờ 08:30 – 11:30 (Sáng 3h)
    • Buổi 2: Chủ nhật (06/04/2025), khung giờ 08:30 – 11:30 (Sáng 3h)
    • Buổi 3: Chủ nhật (06/04/2025), khung giờ 20:00 – 22:30 (Tối 2,5h)
    • Buổi 4: Chủ nhật (20/04/2025), khung giờ 19:30 – 22:30 (Tối 3h)
  • Địa điểm: Học trực tuyến qua Zoom, sẽ gửi cho bạn sau khi thanh toán và tham gia vào group Telegram Private.
  • Học phí: 2,400,000đ / bạn / 4 buổi.

Liên hệ:

Demo

Tạo prototype bằng AI, chỉ với 1 câu lệnh, mình chỉ mất 3 phút.

Chuyển prototype thành UI trên figma

Tạo testcase bằng AI, giảm thời gian build 100 testcases từ hơn 1 ngày còn 1 tiếng.

  • Từ yêu cầu cơ bản => ra được testcases với tỉ lệ coverage cao
  • Demo xem tại đây: https://cv.hoangphan.blog/token-info-testcase.html

FAQs:

Thời gian khoá học:

– 4 buổi, mỗi buổi 3 tiếng.

Có video record lại buổi học không?

– Sẽ có nha mọi người, các buổi học sẽ được record lại và gửi đến mọi người trong lớp học đó qua email.

Có được hỗ trợ sau các buổi học không?

– Sẽ có hỗ trợ các bạn trong vòng 3 tháng, để các bạn thực hành được, nên cứ mạnh dạn nhắn tin để mình hỗ trợ nhé. Miễn nội dung liên quan đến khoá học.

Sẽ học qua đâu?

– Dự kiến sẽ học qua Zoom nha mọi người. Mình sẽ gửi link zoom qua email trước cho bạn 1 ngày, cũng như nhắc nhở bạn trước giờ vào học để bạn tham gia

Dùng AI nào để thực hành vậy? có miễn phí không? Và có tool nào khác ngoài AI không?

– Khi học mình sẽ thực hành chính trên POE AI – Một bên thứ 3 xây dựng có kết nối với các models mới và nổi tiếng như: ChatGPT, Anthropic, Flux, DeepSeek, Gemini AI, Grok, Qwen, Nova, Llamma,…

– Do đó mà chỉ với 1 mình Poe bạn có thể sử dụng được nhiều tác vụ, từ chat hỏi đáp thông thường, dùng đa dạng models, có thể tạo ảnh minh hoạ, …

– Ngoài POE mình sẽ dùng một số AI khác.

– Ngoài các AI thì mình sẽ sài thêm 1 tool mini do Hoàng build, để mọi người view testcase lên dễ dàng và download về exel.

– Dùng chung 1 tài khoản POE premium trong 1 tháng (5-6 bạn 1 tài khoản), có 1 triệu Point, nhiêu point thì mọi người thong thả sài nha.

Sau này khi dùng, mình có cần trả tiền AI để dùng không?

– Sau này nếu bạn muốn dùng premium thì phải trả phí, 499K/1 triệu points/1 tháng, hoặc gói 128K/1 tháng cho 10,000 points/ngày hoặc có thể rủ người sài chung và chia tiền.

– Hoặc mình có gợi ý những AI mạnh mẽ đang có miễn phí để mọi người sài thay thế, dĩ nhiên là đôi lúc không bằng hàng Premium rồi, nhưng vẫn thực hiện được các tác vụ.

Mình chưa biết gì về AI thì có học được không?

– Học được nha, lớp này là lớp hướng dẫn sử dụng AI cho các tác vụ liên quan đến BA (không phải tất cả, nhưng là những phần mình có đưa ra khi giới thiệu khoá học)

– Vì đây là học sử dụng và các tip khi sử dụng AI, dùng AI nào cho phù hợp, chứ không phải học cách build AI hay AI-Agent.

Categories Business Analyst

Khoá học sử dụng AI trong công việc cho IT Business Analyst

by hoangphan Posted on
Khoá học sử dụng AI cho Business Analyst

Khóa học sử dụng AI trong công việc cho IT Business Analyst

Khoá này giúp gì cho bạn?

  • Kể từ khi ChatGPT 3.5 xuất hiện, nhiều người đã tận dụng AI để tối ưu hóa công việc của mình một cách hiệu quả.
  • Hoàng BA cũng nằm trong số đó, đã trải nghiệm và áp dụng AI vào công việc hàng ngày.
  • Với hơn 2 năm sử dụng AI liên tục, mình đã tích lũy được một số mẹo và kỹ năng hữu ích, đặc biệt trong các nhiệm vụ của BA/PM, giúp tiết kiệm thời gian và nâng cao hiệu suất làm việc.
  • Qua khóa học này, mình sẽ chia sẻ và hỗ trợ bạn biết cách sử dụng trong công việc BA / PM, để bạn cũng có thể làm việc thông minh và hiệu quả hơn!
Khoá học sử dụng AI cho Business Analyst
Hình này tạo bằng AI

Nội dung khóa học

  • Hiểu cơ bản về AI: Giải thích cách AI hoạt động ở thời điểm hiện tại, và cách sử dụng AI cho đúng.
  • Sử dụng AI: Đăng ký và tạo tài khoản, kiểm tra giá… để sử dụng một AI, 
  • Một số AI mình hay sài: giới thiệu về các AI mình hay dùng, cũng như chia sẻ kinh nghiệm, trải nghiệm cá nhân đến mọi người khi sử dụng AI
  • Tạo Prototype với AI
  • Tạo UI/Wireframe với prototype vừa được tạo ra
  • Tạo checklist và testcases với AI, đảm bảo độ coverage cao
  • Vẽ diagram: Flow chart, Sequence
  • Viết Usecase
  • Viết User story và AC
  • Viết SRS
  • Viết User guide
  • Học và nghiên cứu tính năng mới
  • Một số tác vụ khác sử dụng AI

Lợi ích của khóa học

  • Thực hành thực tế với các công cụ AI hiện đại.
  • Phát triển kỹ năng thiết kế, viết tài liệu và thử nghiệm bằng AI.
  • Cơ hội áp dụng kiến thức vào công việc thực tế, đặc biệt trong vai trò Business Analyst (BA), giúp bạn giảm rất rất nhiều thời gian khi làm công việc BA.
  • Tham gia group Telegram private được Hoàng hỗ trợ, cũng như được chia sẻ các kiến thức mới nhất về AI.
  • Một tháng sử dụng AI (mình sẽ mua 1 tài khoản cho 1 lớp (6 bạn) sài chung để thực hành, tài khoản này 1 tháng)
  • Được sử dụng AI Agent do Hoàng phát triển (thời gian sắp tới sẽ có vài công cụ Hoàng xây dựng)
  • Các buổi học sẽ được record lại, mình sẽ gửi cho các bạn xem lại qua email.

Thông tin đăng ký

Bạn sẵn sàng bắt đầu hành trình khám phá AI chưa? Hãy đăng ký ngay hôm nay để không bỏ lỡ cơ hội!

Hình thức đăng ký:

  • Vui lòng điền thông tin vào form dưới đây.
  • Mỗi lớp 6 bạn, học 2 buổi – 6 tiếng
  • Thời gian khai giảng: Xem kỹ trong từng form.
  • Địa điểm: Học trực tuyến qua google meet.
  • Học phí: 2,200,000đ / bạn / 2 buổi

Form đăng ký:

  • Lịch học Thứ 4 (19/03/2025) và Thứ 6 (21/03/2025), khung giờ 19:30 – 22:30 => Đã đủ học viên
  • Lịch học Thứ 7 (22/03/2025) và Chủ nhật (23/03/2025), khung giờ 9:00 – 12:00 => Đã đủ học viên
  • Lịch học Thứ 7 (22/03/2025) và Chủ nhật (23/03/2025), khung giờ 14:00 – 17:00 => Đã đủ học viên
  • Nếu nhu cầu nhiều hơn, mình sẽ mở nhiều lớp thêm, có gì cứ nhắn tin mình qua:

Demo

Tạo prototype bằng AI, chỉ với 1 câu lệnh, mình chỉ mất 3 phút.

Chuyển prototype thành UI trên figma

Tạo testcase bằng AI, giảm thời gian build 100 testcases từ hơn 1 ngày còn 1 tiếng.

  • Từ yêu cầu cơ bản => ra được testcases với tỉ lệ coverage cao
  • Demo xem tại đây: https://cv.hoangphan.blog/token-info-testcase.html

FAQs:

Thời gian khoá học:

– 2 buổi, mỗi buổi 3 tiếng hoặc có thể hơn nếu trao đổi trong buổi học nhiều.

Có video record lại buổi học không?

– Sẽ có nha mọi người, các buổi học sẽ được record lại và gửi đến mọi người trong lớp học đó qua email.

Có được hỗ trợ sau các buổi học không?

– Sẽ có hỗ trợ các bạn trong vòng 3 tháng, để các bạn thực hành được, nên cứ mạnh dạn nhắn tin để mình hỗ trợ nhé. Miễn nội dung liên quan đến khoá học.

Sẽ học qua đâu?

– Dự kiến sẽ học qua Zoom nha mọi người. Mình sẽ gửi link zoom qua email trước cho bạn 1 ngày, cũng như nhắc nhở bạn trước giờ vào học để bạn tham gia

Dùng AI nào để thực hành vậy? có miễn phí không? Và có tool nào khác ngoài AI không?

– Khi học mình sẽ thực hành chính trên POE AI – Một bên thứ 3 xây dựng có kết nối với các models mới và nổi tiếng như: ChatGPT, Anthropic, Flux, DeepSeek, Gemini AI, Grok, Qwen, Nova, Llamma,…

– Do đó mà chỉ với 1 mình Poe bạn có thể sử dụng được nhiều tác vụ, từ chat hỏi đáp thông thường, dùng đa dạng models, có thể tạo ảnh minh hoạ, …

– Ngoài POE mình sẽ dùng một số AI khác.

– Ngoài các AI thì mình sẽ sài thêm 1 tool mini do Hoàng build, để mọi người view testcase lên dễ dàng và download về exel.

– Một lớp 6-7 bạn sẽ dùng chung 1 tài khoản POE premium trong 1 tháng, có 1 triệu Point, nhiêu point thì mọi người thong thả sài nha. Hoàng ngày nào cũng sài, 1 triệu point tháng nào cũng dư.

Sau này khi dùng, mình có cần trả tiền AI để dùng không?

– Sau này nếu bạn muốn dùng premium thì phải trả phí, 499K/1 triệu points/1 tháng, có thể rủ người sài chung và chia tiền.

– Hoặc mình có gợi ý những AI mạnh mẽ đang có miễn phí để mọi người sài thay thế, dĩ nhiên là đôi lúc không bằng hàng Premium rồi, nhưng vẫn thực hiện được các tác vụ.

Mình chưa biết gì về AI thì có học được không?

– Học được nha, lớp này là lớp hướng dẫn sử dụng AI cho các tác vụ liên quan đến BA (không phải tất cả, nhưng là những phần mình có đưa ra khi giới thiệu khoá học)

– Vì đây là học sử dụng và các tip khi sử dụng AI, dùng AI nào cho phù hợp, chứ không phải học cách build AI hay AI-Agent.

Categories Business Analyst Tự học IT BA

Business Rule là gì? Tìm hiểu về Business Rule khi viết tài liệu

by hoangphan Posted on
Business Rule là gì? Tìm hiểu về Business Rule khi viết tài liệu

Chào anh em 😀

Lâu quá rồi không viết blog, nay nhân dịp đầu xuân nên mình sẽ chia sẻ về một khái niệm rất quan trọng mà BA nào cũng cần nắm vững – Business Rule (Quy tắc nghiệp vụ).

1. Giới thiệu

Làm BA, chúng ta thường xuyên phải đi phân tích nghiệp vụ và viết tài liệu. Và một trong những thứ quan trọng nhất mà BA cần xác định chính là Business Rule. Vậy:

  • Business Rule là gì?
  • Nó khác gì với Business requirement?
  • Làm sao để định nghĩa business rule hiệu quả?

Qua bài viết này, mình sẽ chia sẻ kinh nghiệm thực tế về business rule nhé.

2. Business Rule là gì?

Business Rule là các quy tắc, chính sách, ràng buộc mà một tổ chức/doanh nghiệp đặt ra để:

  • Kiểm soát hoạt động kinh doanh
  • Đảm bảo tính nhất quán của dữ liệu
  • Tuân thủ các quy định pháp lý
  • Thống nhất cách vận hành nghiệp vụ

Và đặt ra để khi build hệ thống (tại ta đang nói là IT BA mà) thì hệ thống sẽ phải tuân theo.

Nói cách khác

Business Rule là những gì định nghĩa hoặc ràng buộc một khía cạnh nào đó của nghiệp vụ. Nó giúp kiểm soát hoặc ảnh hưởng đến hành vi nghiệp vụ.

Ví dụ thực tế:

  • “Khách hàng phải trên 18 tuổi mới được mở thẻ tín dụng”
  • “Đơn hàng trên 500k được miễn phí ship”
  • “Mỗi user chỉ được tạo tối đa 3 tài khoản”

3. Business Rule vs Business Requirement

Đây là 2 khái niệm hoàn toàn khác nhau mà nhiều bạn hay nhầm lẫn.

Business Requirement là những mục tiêu, nhu cầu mà business muốn đạt được. Nó trả lời câu hỏi “CÁI GÌ” (WHAT).

  • “Hệ thống cần lưu được lịch sử giao dịch của khách hàng”
  • “Khách hàng có thể đặt lịch với bác sĩ yêu thích”

Business Rule là các quy định, ràng buộc để đạt được requirement. Nó trả lời câu hỏi “NHƯ THẾ NÀO” (HOW).

  • “Lịch sử giao dịch được lưu tối đa 5 năm”
  • “Chỉ khách hàng VIP mới được đặt lịch trước 30 ngày”
  • “Mỗi khách chỉ được đặt tối đa 3 lịch/tuần”

Những điểm khác biệt:

  Business Requirement Business Rule
Về tính chất Mang tính định hướng, mục tiêu

Thường chung chung, high-level

Focus vào outcome

 Mang tính ràng buộc, quy định

Phải cụ thể, chi tiết

Focus vào implementation
Về nguồn gốc Đến từ stakeholder/business user

Thường là pain point cần giải quyết

Xuất phát từ nhu cầu thực tế

 Có thể từ nhiều nguồn:

  • Legal/Compliance
  • Technical constraints
  • BA/Dev team suggest

Dựa trên phân tích nghiệp vụ
Về cách thể hiện Khách hàng có thể mở thẻ tín dụng online BR-001: Tuổi từ 18-65

BR-002: Thu nhập >= 10tr/tháng

BR-003: CMND còn hiệu lực

BR-004: Có tài khoản thanh toán
Về tính linh hoạt Ít khi thay đổi

Thay đổi impact lớn

Cần approval từ business

 Thường xuyên thay đổi

Thay đổi impact nhỏ hơn

BA có thể suggest thay đổi

 

4. Phân loại Business Rule

Theo kinh nghiệm làm việc của mình, business rule có thể chia thành các nhóm:

  1. Quy tắc ràng buộc (Constraint Rules): đây là những rule về giới hạn, điều kiện mà hệ thống phải tuân theo.
  • Giới hạn độ tuổi (Khách hàng phải từ 18-65 tuổi mới được mở thẻ tín dụng)
  • Hạn mức giao dịch (Rút tiền ATM tối đa 5tr/lần và 100tr/ngày)
  • Số lượng tối đa/tối thiểu (Mỗi user chỉ được tạo max 3 tài khoản)
  1. Quy tắc tính toán (Computation Rules): Những rule liên quan đến công thức tính toán, xử lý số liệu
  • Công thức tính điểm thưởng (Mỗi 100k chi tiêu = 1 điểm)
  • Cách tính lãi suất (Lãi suất = Số dư * 0.8%/tháng)
  • Logic tính phạt (Phí trả trễ = 3%/tháng trên số tiền chậm trả)
  1. Quy tắc quy trình (Process Rules): Rules về các bước xử lý, thứ tự thực hiện
  • Đơn hàng phải qua bước xác nhận OTP trước khi thanh toán
  • Khách hàng phải upload CMND trước khi tạo tài khoản
  • Hoàn tiền sau 24h kể từ khi huỷ đơn thành công
  1. Quy tắc dữ liệu (Data Rules): Rules về format, ràng buộc dữ liệu.
  • CMND phải là số và có 9 hoặc 12 ký tự
  • Email phải đúng định dạng [email protected]
  • Ngày sinh không được lớn hơn ngày hiện tại

5. Vai trò của Business Rule với BA

Business Rule cực kỳ quan trọng vì:

  1. Là nền tảng để xây dựng tính năng:
  • Thiếu rule => thiếu validation
  • Rule không rõ => code sai logic
  • Rule không đầy đủ => thiếu case xử lý

Ví dụ: làm feature đăng ký tài khoản mà không có rule về format mật khẩu => users tạo mật khẩu yếu => security risk

  1. Giúp quản lý thay đổi:
  • Dễ tracking khi có thay đổi
  • Đánh giá impact dễ hơn
  • Update requirement nhanh hơn

Ví dụ: khi legal yêu cầu thay đổi điều kiện mở thẻ, BA sẽ rà soát lại và chỉ cần update lại các rule liên quan, sau đó ghi rõ lại change để sau này dễ track.

  1. Trao đổi với team dễ hơn:
  • Dev hiểu rõ logic cần code
  • Tester biết case cần test
  • PO/PM nắm được ràng buộc

6. Tips định nghĩa Business Rule hiệu quả

Qua thực tế làm việc, mình rút ra một số tips:

  1. Viết ngắn gọn, rõ ràng:
  • Tránh câu dài, khó hiểu, một rule chỉ mô tả một ràng buộc
  • Dùng từ ngữ đơn giản
  • Format dễ đọc

Ví dụ:

  • BAD: Khách hàng đăng ký thẻ phải đủ 18 tuổi và có thu nhập ổn định từ 10 triệu trở lên mỗi tháng
  • GOOD:
    • BR1: Khách hàng phải từ 18 tuổi trở lên
    • BR2: Thu nhập tối thiểu 10tr/tháng
  1. Phân nhóm logic:
  • Group theo chức năng
  • Đánh ID dễ tracking
  • Sắp xếp độ ưu tiên

Ví dụ nhóm rule cho feature Mở thẻ:

  • Điều kiện cơ bản
    • BR-001: Tuổi >= 18
    • BR-002: Thu nhập >= 10tr/tháng
  • Xác thực thông tin
    • BR-003: CMND còn hiệu lực
    • BR-004: SĐT đã xác thực OTP
  • Tính hạn mức
    • BR-005: Hạn mức = 3x thu nhập
  1. Validate kỹ:
  • Review với SME (Subject Matter Expert)
  • Check conflict
  • Test các edge case

VD: Rule “Khách VIP được ưu tiên xử lý trong 2h” có conflict với rule “Đơn khiếu nại được xử lý theo thứ tự”.

  1. Cập nhật thường xuyên nếu có thay đổi:
  • Version control: Lưu lại các version để dễ tracking
  • Change log: Change log khi release sản phẩm
  • Notification khi update: Update gì thì thông báo các bên liên quan

7. Một ví dụ thực tế

Ví dụ một feature Đặt lịch khám

Business Requirement Business Rules
UC01: Khách hàng có thể đặt lịch khám với bác sĩ yêu thích Điều kiện đặt lịch
BR-UC01-001: Chỉ đặt được lịch trong 30 ngày tới
BR-UC01-002: Mỗi KH chỉ đặt max 3 lịch/tuần
BR-UC01-003: Phải đặt trước ít nhất 24hRàng buộc bác sĩ
BR-UC01-004: BS chỉ nhận tối đa 20 lịch/ngày
BR-UC01-005: Thời gian khám: 8h-17h các ngày 2-7
BR-UC01-006: Mỗi ca khám 30pThanh toán
BR-UC01-007: Phí đặt lịch: 50.000đ
BR-UC01-008: Hoàn 100% nếu huỷ trước 24h
BR-UC01-009: Hoàn 50% nếu huỷ trước 12h
BR-UC01-010: Không hoàn tiền nếu huỷ < 12h

8. Công cụ quản lý Business Rule

Mình hay dùng các tool sau:

  • Confluence/Notion/Docs/Word: Viết doc, xưa hay sài, giờ cũng ít sài
  • Excel: Track version, lúc 2019 sài cái này kha khá, viết dạng sheet nói chung đánh dấu ID các kiểu khá dễ quản lý
  • Draw.io: Vẽ flow
  • Dùng AI (ChatGPT/ClaudeAI): Phụ Generate ra thêm details, và nhờ vẽ các diagram logic
  • Jira: Link với requirement
  • Trello: Giờ hay sài Trello để add task, và trong task sẽ add luôn các Business Rule (dạng như add AC)

9. Kết bài

Hi vọng qua bài viết này anh em đã hiểu rõ hơn về Business Rule và cách quản lý nó hiệu quả. Nếu thấy hay thì anh em đừng quên chia sẻ và để lại comment góp ý nhé 😀

Categories Business Analyst Chia sẻ

Giao tiếp hiệu quả giữa Business Analyst và devs, testers, designers

by hoangphan Posted on
Business Analyst giao tiếp hiệu quả với Developers, Testers, Designers

Chào mọi người 😀

Giới thiệu

Vẫn là Hoàng đây, hôm rồi có bạn nhắn hỏi về “Vấn đề giao tiếp trong nhóm, kiểu làm sao để giao tiếp hiệu quả giữa dev, tester, design với BA”

Với kinh nghiệm làm việc và quản lý một vài đội nhóm, từ BA, PO, PM, QC tới UI Design, mình xin phép chia sẻ kinh nghiệm cá nhân đế các bạn đọc có cùng thắc mắc.

Trong bài này mình đổi cách xưng hô tí nhé, vì người đặt câu hỏi là 1 bạn nữ nhỏ hơn mình vài tuổi, nên mình xin phép xưng “Anh” “Em”

Ý chính từ ý kiến cá nhân

1. Hiểu những việc họ làm sẽ giúp em giao tiếp dễ với họ.

2. Nên chia sẻ nghiệp vụ với họ (họp nhóm/họp 1-1) để giới thiệu rõ nghiệp vụ, business rule, luồng, Đặc biệt là chia sẻ trên tinh thần mình hiểu, mình tự tin, và mục đích chia sẻ để họ hiểu thay vì qua loa cho xong việc.

3. Nói chuyện vui vẻ/ tâm sự chuyện thường ngày với họ.

1. Hiểu sâu về công việc của các bộ phận khác:

Ví dụ em thử học 1 khoá về dev sơ sơ, mò thử vài cái cơ bản về dev xem sao… or design thì thử học 1 khoá về design nhỏ trên youtube.

A Business Analyst is learning UI Design skills
A Business Analyst is learning UI Design skills

A thì nghĩ 1 số bạn nói là dư, nhưng với kinh nghiệm của anh, nhờ biết các kiến thức này mà từ lúc intern anh làm việc với mọi người rất suôn sẻ

Anh từng dev game, hiểu độ khó của việc dev ra sao, từng code web, từng code mobile app (Swift), code cả app trên win, đa phần là lúc còn sinh viên với những năm làm thêm freelancer, nên khi nói chuyện với dev, dù vấn đề khó anh vẫn nói chuyện với họ rất bình thường, thậm chí có thể trao đổi technical sâu với CTO trong công ty và CTO đối tác.

Từng làm QC Manual & Auto => a làm việc với QC cũng rất mượt =]], kiểu có thể nói chuyện về việc test như nào, đặt priority test ra sao, test plan kiểu gì, kiểm soát tiến độ, dùng phương pháp nào để test, dùng tool nào, Auto thì đang sài ngôn ngữ nào, Xpath hay code, sài thư viện nào, tool auto nào…

Design thì anh cũng tự vẽ & trao dồi thêm kinh nghiệm từ Design nữa. Nên bản thân cũng tự có thêm skill, nhiều lúc làm với Design thì biết cách diễn giải với ngôn ngữ của Design, dùng đúng các khái niệm như Auto-layout, Responsive, Hi-fi design, Prototype, Wireframe, Mockup, Component, Section, Animation,…

2. Chia sẻ kiến thức nghiệp vụ một cách toàn diện

Em hãy tổ chức các buổi họp nhóm hoặc 1-1 để giới thiệu chi tiết về nghiệp vụ, business rule và luồng công việc.

Chia sẻ với tinh thần tự tin, hiểu rõ và mong muốn truyền đạt kiến thức, không chỉ đơn thuần là hoàn thành nhiệm vụ.

Giải thích cả bức tranh tổng thể, từ bài toán kinh doanh đến cách hệ thống tạo ra giá trị cho người dùng.

Business Analyst trình bày trước Devs, Testers, Designers
Business Analyst trình bày trước Devs, Testers, Designers

Ví dụ thực tế: 

Anh sẽ không chỉ chia sẻ những phần của họ, mà anh chia sẻ từ bài toán business, làm sao kiếm ra tiền, cách nhìn nhận từ users, ví dụ như nay có mấy phần FE không cần hiểu là tính năng chạy như thế nào, chỉ cần share userflow & data đó từ BE trả ra là bạn tích hợp được rồi, nhưng anh lại chia sẻ thêm là vì sao nó phải chạy như vậy, phía BE phải dùng công thức như nào để bạn làm, biết đâu lúc code bạn cũng phát hiện ra bug từ Be trả kết quả sai thì sao 😀

Rồi hôm bữa ngồi chia sẻ về 1 dự án kiểu dạng nhận tiền users để mang đi đầu tự động thông qua Smart Contract, thì anh cũng chia sẻ luồng user bỏ tiền, rồi hệ thống làm gì, có công thức gì mà giúp tiền users đi đến những nơi khác và kiếm lợi nhuận, trường hợp nào sẽ lỗ, trường hợp nào sẽ lời, lỗ thì hệ thống phải làm sao, lời thì sao, … từ đó mà Design có thể bổ sung những trường hợp báo rủi ro lỗ, thêm các bước xác nhận risk trong đầu tư, … Mà vì được nghe rõ về Business => Designer họ cũng sẵn sàng chia sẻ kinh nghiệm design, chỉ tip design => Mình cũng được nâng cao kỹ năng desgin.

3. Nói chuyện vui vẻ như bạn bè.

Anh nghĩ công việc & chuyện đời thường mọi người cứ vui vẻ với nhau, làm việc khoẻ hơn rất nhiều, anh không chỉ áp dụng với trong team, mà còn áp dụng với đối tác đồ nữa.

Xưa làm mảng mobile banking, anh cũng hay đi ăn với bạn bên bank. Nên khi cần gì rắc rối nhờ họ là họ giúp mình ngay.

BA đi ăn cùng Devs, QCs, Designers
BA đi ăn cùng Devs, QCs, Designers

 

Các ý bổ sung, hơi thiên về kỹ năng

  • Anh em nên thống nhất 1 quy trình làm việc chung, ví dụ như stand-up meeting hằng ngày. Thẳng thắn chia sẻ/trao đổi/ chỉ ra lỗi sai của nhau trong khi làm việc
  • Làm gì cũng có plan, ví dụ sprint plan.
  • Làm rõ mục tiêu/kết quả của sprint/dự án/phase
  • Sử dụng công cụ tracking hiệu quả, như anh là sài Trello/Jira, kéo task liên tục, thường la mấy đứa để nó update task đúng.
  • Đánh version/commit code rõ ràng (này bạn Dev Lead hay nhắc nhở mấy đứa dev trong team =)) commit không rõ ràng là bị ăn chửi =)) )
  • Anh cũng hay hỏi mọi người ý kiến, chia sẻ idea để phát triển dự án, với 1 phần họ cảm thấy mình tôn trọng họ.
  • Nên dùng cách giao tiếp khác nhau với đối tượng khác nhau, ví dụ Designer => thì em không thể dùng các từ ngữ kỹ thuật bên Dev để nói chuyện.
  • Cập nhật tài liệu thường xuyên (wiki, SRS, URD, User Stories,…)
  • Tổ chức mấy buổi review UI cho các bên, Tester/BA/Dev cũng nên join. rồi nhờ mọi người cho ý kiến nữa.
  • Tăng cường chat, đặc biệt là chat nhóm, tránh chat riêng (Direct Message)
  • Nên tổ chức retrospective, anh lâu lâu thấy team không ổn, hoặc dự án nó đi sai với kế hoạch là anh làm ngay, anh không follow agile là hết sprint là làm, anh làm ít hơn, chỉ khi cần thiết thôi. => mọi người góp ý, nhìn nhận sai sót, đưa ra phản hồi để xây dựng.
  • Khi diễn giải nghiệp vụ => Nên sài biểu đồ nhiều vô, ít chữ thôi => Đi từ tổng quan đến chi tiết.

Kết bài

Hi vọng với những kinh nghiệm và ý kiến cá nhân sẽ giúp bạn đọc sẽ giao tiếp hiệu quả hơn nữa khi làm việc với QC, Dev, Designer.

Hãy để lại comment hoặc chia sẻ đến bạn bè nếu thấy hay nhé.

Categories Chia sẻ

Các vị trí công việc của BA?

by hoangphan Posted on
Vị trí công việc Business Analyst Hoang Phan blog

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

Hôm nay chúng ta sẽ tìm hiểu về các vị trí công việc của BA (Business Analyst) nhé.

Theo như cuốn BABOKv3 định nghĩa thì:

Vai trò BA

Vai trò của Business Analyst (BA) là căn chỉnh để các giải pháp được thiết kế và chuyên giao luôn phù hợp với nhu cầu của các bên liên quan. Và những công việc của BA bao gồm:

  • thấu hiểu các vấn đề và mục tiêu của doanh nghiệp,
  • phân tích các nhu cầu và giải pháp,
  • đề ra các chiến lược,
  • dẫn dắt sự thay đổi, và
  • tạo điều kiện thuận lợi cho sự hợp tác của các bên liên quan

Những Job Title trong sách nói

Và trong sách có ghi những common job titles như sau.

Công việc BA BABOKV3
Công việc BA – BABOKV3

Thì ta có:

  • Kiến trúc sư nghiệp vụ (Business Architect)
  • Chuyên viên phân tích hệ thống nghiệp vụ (Business System Analyst)
  • Chuyên viên phân tích dữ liệu (Data Analyst)
  • Chuyên viên phân tích doanh nghiệp (Enterprise Analyst)
  • Chuyên viên tư vấn quản lý (Management Consultant)
  • Chuyên viên phân tích quy trình nghiệp vụ (Process Analyst)
  • Quản lý sản phẩm (Product Manager)
  • Người lĩnh xướng và phát triển sản phẩm (Product Owner)
  • Kỹ sư thiết kế và quản lý yêu cầu (Requirement Engineer)
  • Chuyên viên phân tích hệ thống (Systems Analyst)

Ụa Ụa khoan, sao không thấy ông IT Business Analyst trong danh sách trên nhỉ???? :v 

Thì thật ra “IT Business Analyst” là một cái title hay được gọi ở Việt Nam, và tuỳ công ty sẽ những loại công việc khác nhau, nhưng nếu tính trên danh sách trên thì IT Business Analyst khá gần với tên Business System Analyst.

Nên khi tìm việc các bạn có thể nghiên cứu về Job Description của mỗi công ty tuyển dụng, họ sẽ yêu cầu công việc mà từ đó chuẩn bị cho phù hợp với yêu cầu tuyển dụng nhé.

Năm 2021 mình có làm cho công ty Blockchain, có CEO là người Mỹ, khi tuyển dụng có một bạn ở Shenzhen (Thâm Quyến, Trung Quốc), job title là Product Manager sinh năm 2K, nhưng task và công việc của bạn là một IT Business Analyst (junior), mà ông CEO ổng hỏi BA là gì, sao mày (ý nói là mình) không phải Title là PM mà là BA, Rồi nó kêu dựa theo kinh nghiệm của nó thì BA được xem như một Junior PM cũng được :v…

Hôm rồi mình có học 1 khoá trên Udemy thì trên đó họ cũng giải thích Business System Analyst

Business System Analyst Hoang Phan Blog
Business System Analyst Hoang Phan Blog

Những vị trí gần giống IT BA ở Việt Nam

Riêng với mình thì mình biết những title hay gặp ở Việt Nam mà hay có dính tới IT Business Analyst như sau:

  • BA Presale: Thường các bạn này hay kiểu đi cùng với Sale để pre-sale các sản phẩm của công ty (product)/hoặc sản phẩm build outsource, rồi tham gia vào trao đổi nghiệp vụ lúc deal, rồi sau đó viết docs các kiểu, trao đổi với Dev (và phần kỹ hơn thường giao cho IT BA để làm tiếp). Mình cũng từng làm qua vị trí này.
  • BA triển khai (ERP, …): Thường là cũng join vào Pre-sale, khai thác yêu cầu, tài liệu hoá các yêu cầu, xác nhận, và thường là dạng hiểu rõ về sản phẩm công ty => Sau đó tuỳ yêu cầu sẽ điều chỉnh, cài cắm cho phù hợp nhu cầu mỗi khách hàng.
  • IT BA: Đã chia sẻ ở bài trước
  • Consultant: … Mấy ông này là BA lâu năm, có kinh nghiệm và thường tư vấn, triển khai các phần mềm, process các kiểu cho các doanh nghiệp…. à ờ, này mình không chắc tại chỉ biết vậy thôi, k biết có level junior Consultant không nữa.
  • Product Owner: Ông này có vai trò vận hành, cải tiến sản phẩm và tối ưu hoá sản phẩm, tăng lợi nhuận hoặc 1 lợi ích gì cho sản phẩm/công ty, hay đi trong hệ Scrum/Agile. Nhưng cũng tuỳ công ty, đôi lúc không nhất thiết phải gắn vào Scrum/Agile… Thường product ông PO làm là những sản phẩm product của công ty, yêu cầu ông này phải tham các task vụ liên quan đến nghiên cứu thị trường, hiểu sản phẩm, và biết sắp xếp việc nào ưu tiên trước sau để đẩy ae đội ngũ team Dev chiến. (Mình cũng đang làm vị trí này) => Ở Việt Nam mấy product lớn hay có nhiều PO lắm, ví dụ Momo hay ZaloPay tuyển PO, mỗi PO nắm 1 nhóm sản phẩm/tính năng và tìm hiểu kỹ, tập trung phát triển về nhóm tính năng đó => mang lại hiệu quả cho sản phẩm/công ty.
  • Product Manager: Ông này thường làm ở mức high level hơn ông PO, về định hướng sản phẩm (thường là nguyên 1 sản phẩm, hoặc 1 nhóm nhánh tính năng trong sản phẩm), ưu tiên nhóm tasks lớn, quản lý về vòng đời, đôi lúc gồm các bước như phỏng vấn, làm việc với nhiều khách hàng khắp nơi. Mục tiêu của ông PM hay gắn với mục tiêu kinh doanh, còn so với ông PO thì mục tiêu thường là mục tiêu phát triển sản phẩm

Câu kết.

Thật ra thì những cái trên một phần cũng là title, và tuỳ mỗi công ty sẽ có những cái khác nhau, ví dụ PO ở công ty A, nhưng đôi lúc công việc lại như PM ở công ty B, hay làm IT BA công ty A thì lại giống ông BA triển khai của công ty B.

Nên khi tìm hiểu và tham gia tìm việc, làm việc, bạn nên đọc yêu cầu của mỗi công ty mà chiến nha.

Như mình làm chả biết title mình là gì luôn :)))) lúc thì BA, lúc thì PO, lúc thì Product Manager, lúc thì Project Manager, rồi tham gia mấy task vụ về UX research…

Nên cứ có kỹ năng nào phù hợp, bạn hỗ trợ dự án và giúp nó phát triển đi đúng định hướng là cứ quất nhé.

 

Đọc các bài khác trong chuỗi bài: Tự học IT Business Analyst

Categories Tự học IT BA

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

by hoangphan Posted on
Những kỹ năng của IT Business Analyst

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.
    • 5 mind map types popular with teams

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é. 

Categories Tự học IT BA

Tại sao bạn muốn làm IT Business Analyst?

by hoangphan Posted on
Tại sao bạn muốn làm IT Business Analyst

Qua 2 bài viết đầu và đã hiểu IT Business Analyst là gì?, Vai trò của IT Business Analyst thì bạn đã hiểu phần nào về những gì công việc BA sẽ làm. 

Cũng chính vì có rất nhiều bạn nhắn tin và hỏi mình dạy về IT BA, mình hỏi ngược lại “Tại sao muốn làm BA?” nhiều bạn trả lời rất ngập ngừng, mình cảm giác như các bạn biết tới vì nhiều bài trên mạng đăng giới thiệu về BA sơ qua, chưa hiểu rõ cốt lõi của công việc BA, hoặc nghe lương cao … nên chuyển qua làm.

Mình có search trên google về chủ đề này =)) mà thấy toàn quảng cáo cho IT BA, kiểu như “Tại sao bạn nên làm IT BA”, mình thì không thích làm vậy lắm, chủ yếu là muốn những bạn nghĩ tới việc làm IT BA thì nên tìm hiểu kỹ về nghề IT BA, tự thấu hiểu bản thân => Chọn hướng đi cho đúng.

Nên bài này chính là một bài mình viết ra những câu hỏi để các bạn tự hỏi lại bản thân xem thử là

Tại sao bạn muốn làm IT Business Analyst?

Các câu hỏi để bạn tự hỏi bản thân và từ đó tự trả lời cho câu hỏi “Tại sao bạn muốn làm IT Business Analyst?”

  • Bạn có thực sự hiểu về công việc của một IT BA hay chỉ bị thu hút bởi những lợi ích như lương cao hoặc cơ hội thăng tiến? => BA không phải dễ như bạn nghĩ
  • Bạn có nghĩ BA dễ làm hơn ngành khác không? Hoặc kiểu thấy nó dễ hơn vị trí khác trong ngành IT => muốn làm
  • Bạn có thấy làm IT BA ít áp lực và công việc nhẹ nhàng hơn so với các vị trí công việc khác đúng không? Như mình thì mình thấy đúng =)) Vì mình thích và cảm giác như mình đang đi đúng, nhưng mình nghĩ với những bạn khác thì không phải như vậy, mình từng đưa bài toán hơi khó 1 tíu thôi, thấy những bạn BA đó làm mà bảo muốn nản luôn…. Nên ở góc nhìn của bạn cũng chưa chắc là đúng => Tìm hiểu kỹ, nghe những người từng làm kể đã.
  • Bạn có thích làm về công nghệ không? => Làm IT BA buộc phải làm liên quan đến công nghệ.
  • Bạn thực sự đã hiểu về tất cả những công việc IT BA sẽ làm chưa? => Chưa hiểu thì phải tìm hiểu thật là kỹ để biết và làm
  • Bạn có thích giao tiếp và làm việc với nhiều người từ các bộ phận khác nhau không? => Phải thường xuyên trao đổi, họp hành, khi lên vị trí cao hơn, việc họp còn nhiều hơn thời gian ngồi phân tích và viết tài liệu nữa, chưa kể thường được/bị người này người kia hỏi nghiệp vụ
  • Bạn có khả năng tự tìm hiểu một thông tin mới không? => BA là người đi tìm hiểu, nghiên cứu, có kiến thức rộng để đưa ra những giải pháp phù hợp => Phải luôn trong tâm thế tìm hiểu và học hỏi, đặc biệt là tự tìm hiểu.
  • Bạn có khả năng tự học không? Tìm hiểu để học kỹ năng mới=> Có những dự án rất rất mới, không có ai chỉ cho bạn, mà bạn lại là người đi đầu trong dự án => bạn phải có khả năng tự học, tự tìm hiểu, tự suy luận để có những kiến thức mới phù hợp với dự án. Chưa kể công nghệ thay đổi liên tục, buộc người làm trong lĩnh vực IT phải luôn cập nhật cái mới để tìm ra cái phù hợp nhất trong từng giai đoạn.
  • Bạn có khả năng truyền đạt ý tưởng và thông tin phức tạp một cách rõ ràng, dễ hiểu không? => Thật ra câu hỏi này thì mang tính tương đôi, bạn có thể trao dồi thêm trong quá trình học và làm BA, nếu đã có rồi thì tốt, chưa có thì nên học, làm nghề, ngành nào cũng cần cái này.
  • Bạn đã có kiến thức nền tảng về IT chưa? => Nên trao dồi và nắm các kiến thức cơ bản trước khi vào làm, đừng mộng tưởng việc học xong 1 khoá học là có thể đi làm, cũng sẽ có công ty chấp nhận ấy, nhưng… làm việc thiếu kiến thức IT thì sờ chét lắm nhoa, và cũng khó lên ví trị cao được => Bạn đang làm/định hướng làm IT BA mà.
  • Bạn có sẵn sàng đối mặt với thách thức mới /dự án khó không? => Thường thì cũng có rất nhiều dự án dễ, nhưng cũng không thiếu những dự án trung bình và khó, như mình chỉ nghe 1 đề bài đơn giản là “Xây dựng hệ thống tối ưu lợi nhuận” và từ mỗi câu đó, và một số dự án tương tự => Mình phải tự xâu chuỗi, tự chiến, kiểu đôi lúc vô thế bí không biết làm gì tiếp, mà cũng không có ai để hỏi, sờ chét cực kì => Phải có những kỹ năng bóc tách, tìm ra vấn đề gốc rể và cách xử lý từng phần nhỏ, cũng như chịu được áp lực cao thì mới ra được một phân tích hệ thống đầy đủ và hợp lý với yêu cầu được.
  • Bạn kỳ vọng gì về sự nghiệp IT BA? (Thăng tiến, mức lương, sự ổn định, cơ hội học hỏi,…)
  • Bạn có sự kiên nhẫn không? => Đôi lúc đợi KH rep, hoặc kiểu yêu cầu 1 cái gì đó từ các bên mà không được hỗ trợ, hoặc bị gây khó dễ nữa => Bạn chịu được không?
  • Bạn có thích viết không? Thực tế thì việc viết docs cũng chiếm kha khá thời gian cho những bạn mới vào làm BA => nên cảm giác khúc đầu mới đi làm chả phân tích gì mấy, thời gian chính toàn viết docs
  • Bạn có linh hoạt, và chịu được sự môi trường thường xuyên thay đổi không? => Làm BA thì phải linh hoạt, đôi lúc đổi xoành xoạch ấy
  • Có vài câu chuyện liên quan đến BA bị Dev, QC, KH chèn ép, kiểu ở giữa bị mọi người gây sức ép ấy => Bạn chịu được không?
  • Bạn làm IT BA có phải là kế hoạch dài hạn không? Hay chỉ là 1 bước đệm để lên 1 vị trí khác?
  • Có kế hoạch phát triển sự nghiệp chưa?
  • Liệu do IT BA đang “hot” nên nhảy qua, hay thật sự thích làm IT BA?
  • Bạn chuyển việc => Vậy bạn có sẵn sàng bỏ kha khá kinh nghiệm cũ để qua làm IT BA để bắt đầu một sự nghiệp mới không?
  • Bạn có khả năng/thói quen tự hỏi bản thân không? => Kinh nghiệm của mình là thường khi phân tích, tự hỏi bản thân là 1 kỹ năng vô cùng quan trọng trong việc tìm ra được giải pháp đó….
  • Bạn có thích việc gì cũng tới tay mình không? => Tuỳ công ty, nhưng mình thấy kha khá bạn làm BA, trong đó có cả mình. Kiểu như việc gì cũng tới tay, bạn có khả năng chịu được áp lực, làm nhiều đầu việc cùng 1 lúc như vậy không? HOặc kiểu multitasking, bị nhiều người làm phiền ấy…. Như mình là vừa làm (công việc của) Project Manager, Product Manager, 50% việc của UI Design, UX design, BA, PO, QC Lead, hỗ trợ khách hàng (CS), thậm chí đôi lúc là Graphic design, … có khi sắp tới là code luôn =)).
  • Bạn có nói chuyện với mấy người làm IT BA chưa? Có hỏi họ về kinh nghiệm đi làm, nghe những câu chuyện trong ngành chưa? => Tham gia thử group trên tele của mình để đọc thử nhé: https://t.me/businessanalystvietnam
  • Xung đột giữa các bên (giữa các khách hàng, stakeholders với nhau, giữa dev, QC,…) liệu bạn có thích xen vào và xử lý không? => Thực tế không phải là thích hay không? Mà là tuỳ tình huống bạn nên tham gia vào để giải quyết, đôi lúc đó là 1 phần công việc của bạn
  • Bạn có nhút nhát khi đưa ra ý kiến cá nhân không? => Làm BA không phải là nghe răm rắp theo người khác, mà bạn phải tự nhận định đúng sai, đôi lúc bạn phải định hướng, bản thân đưa ra quyết định, solution và giải thích, thuyết phục người khác => Do đó nếu bạn thấy nhát khi phải đối chấp, thảo luận, tranh luận với người khác,… thì bạn nên học cách để có thể làm được nhé. Như hiện tại với mình, C-level của công ty mình hay của đối tác, việc mình thảo luận thẳng thắn, chỉ ra cái sai, đưa ra giải pháp là chuyện bình thường, mà mình cũng đã làm điều này từ những năm đầu tiên đi làm rồi, nhưng lúc đó chưa đủ trình để được nói chuyện trực tiếp với C-level thôi.
  • …

Cũng nhiều câu hỏi rồi đó, bạn hãy đọc và tự trả lời cho bản thân => từ đó rút ra được câu trả lời phù hợp, xem thử mình thực sự thích IT BA và muốn làm không nhé…

 

Bạn quay lại danh sách bài viết để xem bài tiếp theo nhé: https://hoangphan.blog/tu-hoc-business-analyst/

Categories Tự học IT BA

Vai trò của IT Business Analyst

by hoangphan Posted on
Vai trò IT Business Analyst

Bài thứ 2 trong chuỗi bài tự học IT Business Analyst của Hoàng Phan Blog

Vai trò của Business Analyst

Như cách bạn đọc hiểu về khái niệm BA và IT BA ở bài trước, ta có thể thấy vị trí IT Business Analyst đóng một vai trò quan trọng trong các dự án phát triển phần mềm, và cải tiến quy trình. Là một trong những cầu nối cực kì quan trọng giữa bộ phận kỹ thuật và kinh doanh, đảm bảo rằng các giải pháp được phát triển phù hợp với nhu cầu doanh nghiệp và các bên liên quan.

Vai trò của IT Business Analyst Hoàng Phan Blog
Vai trò của IT Business Analyst Hoàng Phan Blog

1. Thu thập và quản lý yêu cầu:

  • Thu thập yêu cầu: Làm việc với các stakeholders (bên liên quan) từ đó xác định được mục tiêu, yêu cầu từ họ thông qua các việc thực hiện như: phỏng vấn, khảo sát, hội thảo, đọc tài liệu hiện có, ….
  • Xác định và làm rõ yêu cầu: Phân tích và làm rõ yêu cầu, làm sao mà ta hiểu đúng và đầy đủ những yêu cầu đó. Từ đó dự vào kinh nghiệm và kiến thức cá nhân để chuyển đổi thành các yêu cầu về kỹ thuật, đảm bảo rằng đội ngũ dự án có thể thực hiện chúng một cách hiện quả ở bước transition.
  • Quản lý các yêu cầu: Thường có nhiều sự thay đổi, do đó cũng cần viết lại để quản lý, cũng như đưa ra sự ưu tiên cho từng yêu cầu, đảm bảo sao đó đáp ứng được trong sản phẩm release ra cuối cùng.

2. Phân tích quy trình

  • Hiểu về quy trình hiện tại: BA cần hiểu về quy trình, nghiệp vụ hiện tại của vấn đề/doanh nghiệp
  • Xác định và tìm phương án cải tiến: Xác định vấn đề và các cơ hội để cái tiến trong quy trình. Làm sao đó có thể giảm chi phí, tăng hiệu quả, mang lại giá trị cho doanh nghiệp.

3. Đề xuất giải pháp

  • Đề xuất giải pháp: Dựa trên yêu cầu đã thu thập được, khơi gợi, phân tích để đề xuất nhưng giải pháp phù hợp. Giải pháp có thể là phần mềm mới, cải tiến quy trình, thay đổi chiến lược, làm thêm tính năng, điều chỉnh tính năng,…
  • Đánh giá giải pháp: BA đánh giá các giải pháp dựa trên nhiều tiêu chí như: chi phí, lợi ích, rủi ro, tính khả thi => đưa ra giải pháp tốt và phù hợp nhất.

4. Xây dựng và trình bày tài liệu

  • Tạo tài liệu yêu cầu: BA chịu trách nhiệm tạo ra các tài liệu chi tiết như: Business Requirement Document (BRD) – Tài liệu yêu cầu kinh doanh, nghiệp vụ, User Requirement Document (URD) – Tài liệu yêu cầu người dùng, Software Requirements Specification (SRS) – Tài liệu yêu cầu phần mềm, Functional Requirement Specification / Functional Specification Document (FRS/FRD) Tài liệu yêu cầu chức năng, Các loại như Use Case, User Stories, Product Vision,…
  • Tài liệu hỗ trợ việc test: Checklist, Testcases, Testplan.
  • Trình bày giải pháp: BA trình bày các giải pháp đề xuất và các tài liệu yêu cầu cho các bên liên quan để đảm bảo rằng mọi người đều hiểu rõ và đồng ý với những gì sẽ được thực hiện. Việc này kiểu đi xuyên suốt quá trình phát triển, Dev hỏi, QC hỏi, Sếp hỏi, Khách hàng hỏi,… BA trả lời thông tin nghiệp vụ.

5. Hỗ trợ kiểm thử

  • Việc này BA cũng có phần đó nha =)), thường thì việc test sẽ nằm trong tay QC, nhưng BA cũng là người tham gia vào, đôi lúc sẽ xem thử khi lên thực tế sản phẩm thì có cần điều chỉnh gì không => từ đó điều chỉnh yêu cầu cho hợp lý
  • Test để xem thử giải pháp được phát triển có đúng yêu cầu đã đề ra hay không.
  • Tham gia viết Checklist, testcases, kiểm thử chấp nhận người dùng (User Acceptance Testing – UAT) => đi kèm với việc report bugs

6. Hỗ trợ thiết kế

  • BA cũng tham gia vào giai đoạn thiết kế (tuỳ công ty), thường BA là người tìm hiểu khá kỹ về nghiệp vụ, và luồng hệ thống chạy => có thể đề xuất các liên kết giữa các màn hình (User Flow)
  • Tham gia review & đánh giá thiết kế cùng với đội ngũ UI để xem đã meet requirements hay chưa.
  • Đề xuất giải pháp phù hợp để phụ trợ thêm cho đội ngũ UI/UX trong việc thiết kế giao diện và luồng người dùng.

7. Quản lý thay đổi

  • Dĩ nhiên quá trình phát triển phần mềm luôn có sự thay đổi ít nhiều, có thể xuất phát từ các stakeholders, hoặc từ chính BA thấy chưa hợp lý và đề xuất thay đổi => Cần quản lý thay đổi một cách hệ thống và không ảnh hưởng tiêu cực đến tiến độ, cũng như chất lượng dự án.
  • Đảm bảo sự đồng thuận: Thay đổi => Thì phải đề xuất => Rồi có sự đồng thuận từ nhiều bên => Áp dụng việc thay đổi, đôi lúc có những thay đổi tác động tới các bên khác và các dự án khác => cũng cần làm việc để việc thay đổi không ảnh hưởng quá nhiều hoặc có nhiều thì các bên đều xử lý tốt để mang tới 1 kết quả chung tốt nhất có thể.

8. Tạo cầu nối giữa các bên.

  • Truyền đạt thông tin: BA đóng vai trò là cầu nối giữa các bộ phận kinh doanh, các bên liên quan và kỹ thuật, đảm bảo rằng các yêu cầu và mục tiêu của doanh nghiệp được truyền đạt rõ ràng và chính xác đến nhóm phát triển.
  • Giải quyết xung đột: BA giúp giải quyết các xung đột giữa nhu cầu kinh doanh và khả năng kỹ thuật, đảm bảo rằng giải pháp cuối cùng phù hợp với cả hai bên.

9. Hỗ trợ triển khai

  • Thường giai đoạn triển khai, BA sẽ hỗ trợ trong việc đào tạo người dùng, viết tài liệu hướng dẫn, đôi lúc còn phải đi cài cắm nữa cơ 😀 

10. Đánh giá hiệu quả giải pháp

  • Đánh giá sau khi triển khai: Sau khi giải pháp được triển khai, BA đánh giá hiệu quả của nó so với các mục tiêu ban đầu. Họ thu thập phản hồi từ người dùng, phân tích dữ liệu hiệu suất, và xác định liệu giải pháp có đáp ứng được kỳ vọng hay không.
  • Đề xuất cải tiến: Nếu cần thiết, BA đề xuất các cải tiến hoặc điều chỉnh để tối ưu hóa giải pháp hoặc giải quyết các vấn đề phát sinh sau khi triển khai.

Kết luận

IT Business Analyst đóng một vai trò rất quan trọng trong quy trình phát triển phần mềm, giúp việc thực hiện phân tích, triển khai dự án trơn tru và đúng yêu cầu, nhưng có thể trong công ty bạn hoặc đội phát triển của bạn không có ai có title là “Business Analyst”, vậy thì hãy tìm hiểu thêm các bài phía sau để hiểu vì sao nhé.

 

Bạn quay lại danh sách bài viết để xem bài tiếp theo nhé: https://hoangphan.blog/tu-hoc-business-analyst/

Categories Tự học IT BA

Business Analyst là gì?

by hoangphan Posted on
IT Business Analyst là gì? Hoàng Phan Blog

Bài viết đầu tiên trong chuỗi tự học Business Analyst của Hoàng Phan. Blog.

Giới thiệu

Mấy năm gần đây ngành “IT Business Analyst” được tìm kiếm nhiều hơn, đi đâu cũng nghe bàn luận về việc tìm hiểu và làm BA. Bạn bè mình cũng hỏi thăm khi biết mình làm việc ở vị trí BA, cũng có bạn đã chuyển qua làm với mức lương khá ổn hơn nhiều so với công việc hiện tại của các bạn.

Nhớ năm 2017 mình mới đi làm và lúc đó ở công ty mình lúc đó vị trí BA chỉ dành cho mấy anh đã có rất rất nhiều năm kinh nghiệm, thế mà qua sau 1-2 năm sau, nhiều bạn dù chưa có kinh nghiệm vẫn làm được, và cũng như công việc BA được chia nhỏ tasks hơn, khó thì người có kinh nghiệm làm, các công việc còn đơn giản, dễ, thì giao cho các bạn mới tập tành vào nghề. Thế là nó trở nên phổ biến như bây giờ.

IT Business Analyst là gì? Hoàng Phan Blog
IT Business Analyst là gì? Hoàng Phan Blog

IT Business Analyst là gì?

IT Business Analyst (hay được gọi là Chuyên viên phân tích nghiệp vụ IT), là một trong những vai trò trong các dự án công nghệ thông tin và xây dựng phần mềm.

Nhiều bạn thì hay định nghĩa BA là:

  • Người phiên dịch
  • Là người làm Document cho dự án
  • Là cầu nối, giao tiếp giữa các bên (Dev team, Stakeholders, khách hàng,…)

Vậy giờ bóc tách từ cái tên IT Business Analyst ra để xem nhé.

  • IT: Information Technology (Công nghệ thông tin)
  • Business: thường được học là Kinh doanh, nhưng trong ngữ cảnh này còn có nghĩa là “Nghiệp vụ”
  • Analyst: là chỉ người làm những công việc liên quan đến nghiên cứu, tìm hiểu rõ hơn, đưa ra giải pháp, dự đoán,… Dịch tiếng Việt là “Người làm phân tích”

Do đó người làm IT Business Analyst là người làm công việc liên quan đến NGHIÊN CỨU, TÌM HIỂU, PHÂN TÍCH, LÀM RÕ, đưa ra GIẢI PHÁP, và những công việc đi theo như Họp hành, viết tài liệu (tài liệu hoá), truyền đạt thông tin, quản lý các yêu cầu, hỗ trợ triển khai, …

Những phần ở trên mình tập trung nói sâu về công việc IT BA, còn riêng Business Analyst (BA) thì nó hiện diện ở khắp mọi nơi.

Miễn sao người làm những công việc đó tìm ra được “Need” (nhu cầu, yêu cầu thực sự) để đưa ra được những Solution (giải pháp) và mang lại những giá trị cho doanh nghiệp, cá nhân, tổ chức, những bên liên quan (stakeholders). Bạn đọc khái niệm về Business Analysis (Việc/tasks mà Business Analyst sẽ làm) từ cuốn BABOK v3.

Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. (BABOK v3)

Thường thì cái “need” này cũng là một từ khoá, khi mà chính những người/doanh nghiệp đưa ra yêu cầu nhưng họ cũng không biết họ muốn thực sự là gì, thường yêu cầu khá chung chung => đó đó người làm việc này (BA) phải phân tích, sử dụng các kỹ thuật khác nhau để tìm ra Need và chỉ ra cho họ thấy.

Quy trình Business Analysis

Và thường thì BA sẽ làm theo quy trình sau, và IT BA cũng áp dụng quy trình này luôn

Quy trình Business Analyst - Hoàng Phan Blog
Quy trình Business Analyst => Tìm ra need
  • Thường thì bắt đầu từ Business Requirements (Yêu cầu về nghiệp vụ)
    • Cần trả lời được câu hỏi là “tại sao tôi muốn điều này?“
    • Điều này chính là các vấn đề mà doanh nghiệp đang gặp phải và có một mục tiêu cần giải quyết.
    • Cần xác định rõ là cần thay đổi hoặc thực hiện một giải pháp nào đó để mang lại giá trị cho doanh nghiệp ví dụ như tăng doanh thủ, giảm chi phí, cải thiện hiệu quả công việc,…
  • Stakeholder requirements
    • Cần trả lời câu hỏi là “Yêu cầu từ các bên liên quan là gì?“
    • Từ việc biết được mục tiêu cần giải quyết, BA sẽ làm việc với các bên liên quan để hiểu rõ nhu cầu và mong muốn của họ.
    • Stakeholder thì có thể là khách hàng, người dùng cuối (enduser), các nhà quản lý, các đội hỗ trợ, đội nghiệp vụ của công ty,…
  • Solution requirements
    • Cần trả lời câu hỏi “Tôi muốn gì?“
    • Từ yêu cầu và mong muốn của stakeholders, BA sẽ tìm ra các giải pháp cụ thể để đáp ứng những yêu cầu của họ, gồm những yêu cầu về chức năng, phi chắc năng.
    • Solutions có thể bao gồm: tính năng, hành vi/cách hoạt động/User flow của hệ thống, hiệu suất, tiêu chuẩn bảo mật, …
  • Transition requirements
    • Cần trả lời câu hỏi “Điều kiện là gì?“
    • Khi đã có giải pháp thì bắt đầu xây dựng và triển khai, cần xác định những điều kiện như đội ngũ phát triển, phát triển trong bao lâu, những ai tham gia vào, cần làm những gì?, kiểm thử, cơ sở hạ tầng,… để làm sao đó mà giải pháp được áp dụng tốt vào thực tiễn, giúp cho việc chuyển từ trạng thái hiện tại của doanh nghiệp sang trạng thái mới mong muốn trong tương lai (nhờ áp dụng giải pháp).
  • Và dĩ nhiên khi triển khai cũng cần phải đánh giá lại kết quả, chứ không phải làm 1 lần là xong, do đó mà có “Assess outcomes” ở trên mũi tên cuối.
    • Đánh giá để đảm bảo các yêu cầu ban đầu đã được đáp ứng Business Requirements chưa?
    • Và tiếp đó sẽ có những vấn đề, yêu cầu mới phát sinh ra => quay lại bước quy trình để điều chỉnh và cải thiện để đáp ứng tốt nhất yêu cầu từ doanh nghiệp.
    • Các dự án được làm ra luôn cần được điều chỉnh, thay đổi theo thời gian để phù hợp với những yêu cầu về nghiệp vụ/kinh doanh của doanh nghiệp theo từng giai đoạn.

Một ví dụ vui về giải pháp

Ví dụ vui về giải pháp Business Analyst
Ví dụ vui về giải pháp Business Analyst

Một ví dụ về việc làm BA trong cuộc sống hằng ngày:

Ngày mai anh em phải làm việc tại nhà, nhưng ở khu vực nhà bạn lại có lịch cúp điện, mà công việc cần xử lý ngay, vậy nếu theo như Quy trình Business Analysis chúng ta sẽ làm như sau:

  • Xác định Business Requirements (mục tiêu): Hoàn thành công việc một cách hiệu quả kể cả khi cúp điện.
  • Một số giải pháp (solutions) mà có thể có:
    • Tranh thủ tối nay làm việc trước hoàn thành sớm và báo công ty mình làm việc trước như vậy
    • Di chuyển ra quán cà phê nơi có điện để làm việc
    • Sử dụng pin laptop + phát 4G từ điện thoại và tranh thủ hoàn thành việc thời thời gian sử dụng PIN.
    • Sử dụng pin dự phòng
    • …
  • Các bên liên quan:
    • Công ty và Khách hàng: Chờ nhận kết quả công việc từ bạn, bạn phải chịu trách nhiệm khi không hoàn thành công việc đúng hẹn
    • Các thành viên trong đội ngũ làm việc cùng bạn, cần bạn làm việc cùng khung giờ để hỗ trợ nhau, cập nhật thông tin hoặc công việc có liên quan.
    • Bản thân bạn: xong công việc còn đi cà phê với bạn đúng 8g tối,… hoặc tránh mất uy tín vì trễ hẹn công việc,…
  • Chọn giải pháp phù hợp với các stakeholders và tuỳ trường hợp:
    • Thời gian cúp điện ngắn => Có thể dùng pin laptop để hoàn thành công việc
    • Cúp điện dài => Đi ra quán cf cho chắc, hoặc qua nhà bạn, qua co-working, hoặc lên công ty :v 
    • Nhà có sẵn máy phát điện, pin dự phòng => Sử dụng máy phát điện, pin dự phòng và làm tại nhà
    • Buộc phải ở nhà trông con => Thuê máy phát điện chẳng hạn để làm việc tại nhà và vừa có thể trông con, hoặc dẫn con tới co-working space/coffee để vừa trông con vừa làm.
    • Buộc phải làm cùng lúc với mọi người trong công ty để hỗ trợ qua lại => Không nên làm trước, hoặc làm trước 1 phần và cần đi ra nơi có điện để online và làm việc trong suốt thời gian mọi người khác trong công ty đang làm.
  • Transition:
    • Tuỳ theo giải pháp phù hợp nhất => Thực hiện cho phù hợp.
    • Ví dụ chọn làm việc trước: Chuẩn bị danh sách công việc, thời gian bao lâu để hoàn thành, sức khoẻ đảm bảo, báo trước cho công ty,…
    • Ví dụ chọn di chuyển đến nơi có điện: Thì cần chuẩn bị và mang theo thiết bị cần thiết, chuẩn bị hoặc tính phương án ăn uống cho phù hợp
    • Ví dụ chọn sử dụng pin điện thoại, laptop: Thì sạt đầy pin, tối ưu hoá việc sử dụng pin, giảm độ sáng màn hình
    • Ví dụ chọn sử dụng máy phát điện: Cho chạy máy trước và kiểm tra kết nối điện, mua xăng hay nhiên liệu để chạy được trong khung thời gian cần có điện,…

Một ví dụ về công việc IT BA trong làm phần mềm.

Mình đang có trung tâm tiếng Anh, hiện tại hệ thống quản lý khoá học, lớp học đã có học viên, giáo viên, khoá học nào, học bao nhiêu buổi.

Hiện tại khi mà có học viên đăng ký học, ví dụ 32 buổi học, thì người quản lý lớp học sẽ thêm vào trong hệ thống từng buổi học một, rất tốn thời gian dù đã biết trước lịch học vào những thứ mấy, khung giờ nào trong 1 tuần, có được lịch của giáo viên với học viên này rồi.

Do đó ta có thể phân tích và tìm ra giải pháp như sau:

  • Xác định Business Requirements (mục tiêu): Có thông tin về khoá học, người quản lý giảm thiểu thời gian thêm các buổi học vào hệ thống.
  • Các bên liên quan:
    • Người quản lý lớp học, có thông tin cơ bản về khoá học và muốn giảm thời gian thêm dữ liệu vào hệ thống
    • Giáo viên: Cung cấp danh sách các buổi trống có thể dạy học viên, xem được danh sách các buổi học có trước.
    • Học viên: Cung cấp lịch học, xem được buổi học tiếp theo.
  • Một số giải pháp (solutions) mà có thể có:
    • Viết công thức trên file excel, và tạo ra danh sách các buổi học, copy và bỏ vào trường nhập dữ liệu, hệ thống thêm các buổi đó vào db và hiển thị lên cho từng role sử dụng hệ thống
    • Có 3 trường dữ liệu gồm nhập giáo viên, nhập học viên, nhập lịch học theo tuần, số buổi học => nhấn nút và hệ thống tự chạy.
    • Thuê thêm người vào phụ.
  • Chọn giải pháp phù hợp với các stakeholders:
    • Thêm dữ liệu trên excel, thì việc cập nhật lịch của giáo viên phải bị x2 lần khi nhập cả ở excel và hệ thống, người quản lý cũng phải nhập thông tin và quản lý file excel, cũng như hệ thống bị tách rời, và cũng cần build logic cho việc thêm lớp
    • Thêm dữ liệu trên hệ thống thì giáo viên cập nhật dữ liệu 1 lần, người quản lý có thông tin toàn bộ trên hệ thống, điền vào và chạy, nhưng việc develop tính năng sẽ có chút phức tạp và tốn chi phí hơn, và chi phí này cần xem xét có phù hợp với chi phí trung tâm có thể cho phép làm không? => Có
    • Thuê thêm người phụ thì chi phí sẽ không chi nhiều ngay lúc đầu, nhưng về lâu về dài chi phí khá cao so với việc xây dựng hệ thống, cũng như phức tạp hơn trong việc quản lý nhân sự
    • => Chọn phương án số 2, dữ liệu trên 1 hệ thống quản lý duy nhất, tốn chi phí xây dựng ban đầu hơi cao tíu nhưng nằm trong phần chi phí chấp nhận.
  • Transition:
    • Dự trù kinh phí
    • Phân tích các tính năng, cách hoạt động, logic, làm file hướng dẫn cho giáo viên nhập thông tin lịch rãnh, cấu trúc lại hệ thống DB cho phù hợp
    • Testing và triển khai
  • Đánh giá hiệu suất, kết quả sau khi triển khai.

 

 

Bạn Quay lại danh sách bài viết để xem bài tiếp theo nhé: https://hoangphan.blog/tu-hoc-business-analyst/

Categories Blockchain Business Analyst Chia sẻ

Vẽ diagram sử dụng AI giúp Business Analyst tiết kiệm thời gian

by hoangphan Posted on
BA Sử dụng AI vẽ diagram

1. Giới thiệu

Hi mọi người, team mình vừa go live tính năng Seitrace Insights và với việc phân tích tính năng này, mình sử dụng AI rất nhiều để phục vụ việc phân tích, thiết kế và vẽ luồng nghiệp vụ.

Nhờ đó mà mình có kinh nghiệm để viết lại bài blog này để chia sẻ

cách mình đã dùng AI cho việc phân tích và vẽ sequence diagram một cách nhanh chóng

tiết kiệm khá nhiều thời gian, rút ngắn thời gian phân tích, và Dev cũng có thêm thời gian để develop tính năng khi mà yêu cầu về timeline khá gấp rút.

2. Công cụ AI sử dụng

Mình chỉ sử dụng 2 công cụ AI trong đợt này đó là ChatGPT4.0 và Mermaid

  • ChatGPT thì mình không biết phiên bản miễn phí 3.5 có hỗ trợ tốt được như bản mình đang sài không, mình sài Poe trả phí nên sài ChatGPT4 và các AI khác khá sướng 😀 Mà thiết nghĩ GPT3.5 cũng có support sẵn rồi.
  • Mermaid bạn có thể lựa chọn dùng phiên bản live tại: https://mermaid.live/ hoặc dùng Visual Studio Code và cài plugin Markdown Preview Mermaid Support
plugin mermaid hoangphan.blog
plugin mermaid hoangphan.blog

3. Bước phân tích cơ bản

Thật ra mỗi bạn BA, và tuỳ theo công ty sẽ có những cách phân tích khác nhau để đạt được mong muốn, mình với vai trò là một Product Manager, góc nhìn và cách phân tích của mình sẽ đi từ overview => đến chi tiết.

Mình chia làm các giai đoạn phân tích tính năng

Bước 1: Sử dụng thử các sản phẩm có sẵn trên thị trường mà có tính năng tương tự

Bước 2: Tập trung suy nghĩ và định hình những thành phần, Actors, tasks cần làm để xây dựng tính năng.

Bước 3: Dùng AI để research dựa theo keyword để tìm các kiến thức xung quanh tính năng/partner

Bước 4: Dùng AI để bắt đầu vẽ luồng…

Bạn có thể đọc bài “Phân tích tính năng subscription” của mình để biết được cách mình đã phân tích, ở bài này mình sẽ tập trung vào phần vẽ luồng

4. Sử dụng ChatGPT để vẽ ra luồng

Ở bước này mình cơ bản chỉ chat với ChatGPT và đưa ra yêu cầu cụ thể nhất có thể.

Thường thì các bạn có thể sử dụng để vẽ sequence diagram, flow chart hoặc activity diagram sẽ khá là ok nha.

Ví dụ:

Hi, Mình muốn xây dựng tính năng bán API của một Explorer blockchain SEI.
Hiện tôi đã có nguồn dữ liệu có sẵn.

Hãy giúp tôi vẽ luồng Sequence diagram, thanh toán sử dụng Coinbase, phần subscription (Subscription Management sẽ được đội ngũ tự phát triển)

Luồng người dùng sẽ chọn gói Advanced hoặc Professional, sau đó yêu cầu Sub Mgmt Server tính toán để cho User xác nhận, Khi xác nhận => xử lý để qua bên Coinbase tạo hoá đơn, Và khi có hoá đơn cần gửi cho user thông tin qua kênh Front end và Email.

User sẽ thanh toán

Sử dụng Mermaid

 

Thì mình sẽ nhận được một luồng bằng chữ như dưới => Copy bỏ vào trong công cụ Mermaid online, hoặc trên Visual Studio Code

mermaid-sequence text Hoang Phan blog
mermaid-sequence text Hoang Phan blog

Và sẽ nhận được luồng như sau.

mermaid-sequence-diagram Hoang Phan.blog
mermaid-sequence-diagram Hoang Phan.blog

Nhưng dĩ nhiên luồng sẽ chưa thể đúng 100%, do đó bạn cần chat và trao đổi, yêu cầu chỉnh sửa thêm với ChatGPT để cho luồng chính xác nhất.

Bạn có thể đọc đoạn demo của mình bên dưới để biết cách mình đã trao đổi với ChatGPT như thế nào để có luồng nhé.

…… đọc đoạn chat ở đây …

Sau khi đã có luồng hoàn chỉnh, mình sẽ lưu lại file Mermaid, và screenshot để bỏ vào tài liệu 😀

Final flow API Payment
Final flow API Payment

Đoạn luồng cuối cùng của Mermaid

Bạn có thể tải ở đây nha 

 

… Thế là có luồng rồi :v. Khá tiết kiệm thời gian, thậm chí đôi lúc AI hỗ trợ mình vẽ ra các luồng mà mình cũng không nghĩ tới luôn. Nhưng cần có những lưu ý sau khi sử dụng AI vẽ diagram.

5. Lưu ý khi sử dụng AI vẽ diagram

  • Cần phải phân tích cơ bản, high level trước, khi gặp vấn đề thì sẽ nhờ AI để ra thêm  ý tưởng, cũng như luồng còn thiếu, hoặc hỏi để tham khảo.
  • AI không thể thay thế được mình, bạn không thể đưa một bài toán chung chung mà nó giải và đưa ra luồng cho bạn
  • Phải chat và hỏi nhiều lần để AI làm gần sát với ý đồ của bạn nhất.
  • AI là trợ lý của bạn, giúp bạn có thêm ý tưởng, luồng chưa hiểu, nhưng việc rà soát lại luồng, đọc docs chính thống là rất quan trọng. Ví dụ như trong bài toán mình vừa giải, mình phải cần kiến thức về API để đọc rất nhiều docs API chính thống của 3rd để xác định xem luồng của AI vẽ đúng, và có thể sử dụng với bên thứ 3 không.
  • Bạn cũng cần có kinh nghiệm, quan điểm, ý kiến, tư duy riêng để check lại xem luồng, ý kiến của AI đưa ra đúng không.

6. Kết luận.

Mình gần đây nghiên cứu về các công cụ về AI, và sài khá nhiều loại khác nhau, thật sự thấy nó rất tiện ấy… Bạn thử sài đi nha 😀 Giờ mình xem AI như là 1 trợ lý, vừa rồi có ngồi cf với vài người bạn bàn luận về chủ đề, rất rất nhiều bạn đã áp dụng trong công việc và hiệu quả nhiều rồi. Bạn hãy thử sài đi nhé 😀

Và việc vẽ diagram này là một trong những ứng dụng mình thấy rất tiện, tiết kiệm thời gian, hi vọng sẽ giúp bạn làm việc nhanh và hiệu quả hơn với cách mình đã dùng.

1 2