Hoàng xuất phát là dân kỹ thuật phần mềm, tham gia mảng phát triển phần mềm từ 2017 đến nay. Mình muốn mang những trải nghiệm cá nhân chia sẻ đến anh em, từ đó anh em thấy gì hay thì có thể tham khảo sử dụng, mà dỡ thì anh em góp ý giúp nhé.
View all posts by hoangphan
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
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 (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!
– 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.
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!
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:
– 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.
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:
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)
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ả)
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
Quy tắc dữ liệu (Data Rules): Rules về format, ràng buộc dữ liệu.
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
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.
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:
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
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
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ự”.
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é 😀
Một bài trong chuỗi tự học IT Business Analyst cho người mới bắt đầu
Giới thiệu
Làm Business Analyst (BA), một trong những công cụ mạnh mẽ nhất mà chúng ta sử dụng để truyền đạt các yêu cầu và mô hình hóa các luồng, các hệ thống phức tạp là dùng UML.
Với bài viết này, Hoàng sẽ trình bày chi tiết hơn về UML, vai trò của nó trong công việc của một IT Business Analyst, và cách thức nó giúp chúng ta tối ưu hóa quá trình phát triển phần mềm.
UML là gì?
UML (Unified Modeling Language) là ngôn ngữ mô hình hóa tiêu chuẩn được sử dụng để biểu diễn và trực quan hóa thiết kế của hệ thống phần mềm. UML không phải là một ngôn ngữ lập trình, mà là một ngôn ngữ trực quan giúp chúng ta truyền đạt các yêu cầu, thiết kế, và cấu trúc hệ thống một cách hiệu quả giữa các bên liên quan.
Mình thì thấy UML nó giống như 1 bộ quy tắc/syntax để đưa ra 1 chuẩn thống nhất để mô hình và trực quan hoá phần mềm khác nhau, nó có nhiều loại mô hình/diagram, và cũng kiểu triển khai sao cho đơn giản, dễ tiếp cận và phổ biến đến mọi người.
Tại sao UML quan trọng đối với IT Business Analyst?
Là Business Analyst, một trong những tác vụ chúng ta cần phải làm đó là cầu nối giữa doanh nghiệp và nhóm phát triển (Dev team). Do đó mà chúng ta sẽ làm việc với các khách hàng/stakeholders để thu thập yêu cầu, làm rõ và xác nhận, sau đó chúng ta sẽ truyền đạt yêu cầu đó đến cho đội ngũ Dev. Vậy truyền đạt không phải chỉ nói là xong mà chúng ta cần phải viết tài liệu, mô tả, để làm sao dễ hiểu, chính xác và hiệu quả nhất. Mà thường để dễ hiểu cần hình minh hoạ, lưu đồ (diagram), thì UML chính là công cụ quan trọng trong việc đó => Giúp các bên dễ dàng hình dung và thảo luận về hệ thống.
Một số lợi ích mà IT Business Analyst có thể dễ thấy khi dùng UML:
Mô hình hoá yêu cầu: Dĩ nhiên UML là dùng để mô hình hoá 😀 nên nó sẽ giúp ta mô hình hoá yêu cầu, mà khi mô hình hoá lên mọi người đọc sẽ dễ hiểu hơn là đọc chữ không.
Truyền đạt yêu cầu hiệu quả: UML giúp chúng ta trình bày các yêu cầu và thiết kế hệ thống một cách rõ ràng và dễ hiểu, ngay cả với các bên không phải là Dev team. Các diagram UML giúp thu hẹp khoảng cách giữa doanh nghiệp và nhóm phát triển phần mềm (Dev).
Giảm thiểu hiểu lầm: Sử dụng UML giúp giảm thiểu sự hiểu lầm giữa các bên liên quan vì sơ đồ trực quan có thể truyền đạt nhiều thông tin hơn so với mô tả bằng ngôn ngữ tự nhiên.
Quản lý yêu cầu hiệu quả: Không chỉ về phần truyền đạt, mà UML còn giúp cho các yêu cầu được quản lý một cách hiệu quả, có hệ thống. Rồi phần dễ dàng theo dõi tiến độ nữa, mình cũng hay dùng các UML rồi đổi màu để đánh trạng thái phần nào đã xong.
Linh hoạt với nhiều mô hình phát triển phần mềm khác nhau: Ví dụ như Scrum/Agile, WaterFall, V-model, …
Tái sử dụng tốt: Thường nếu chung 1 luồng gần giống nhau, BA cũng hay dùng lại các diagram cho các dự án, tài liệu khác nhau.
Quản lý rủi ro và đánh giá tác động: Nhờ các diagram mà chúng ta có thể nhìn dự án một cách tổng quản, xem xét khi làm tính năng A thì ảnh hưởng tới những tính năng nào, rủi ro ra sao, đôi lúc cũng liên quan đến các chi phí phát sinh như cần phải có server A, server B,… Từ đó mà tránh đi được những vấn đề trước khi chúng trở nên nghiêm trọng.
Danh sách các loại UML Diagram
Mình để 1 hình các bạn xem là sẽ hiểu có những loại nào ha, hiện theo Wiki thì có 14 loại.
14 loại UML Diagrams
Sơ đồ lớp (Class Diagram)
Sơ đồ đối tượng (Object Diagram)
Sơ đồ tình huống sử dụng (Use Cases Diagram)
Sơ đồ trình tự (Sequence Diagram)
Sơ đồ cộng tác (Collaboration Diagram hay là Composite Structure Diagram)
Sơ đồ trạng thái (State Machine Diagram)
Sơ đồ thành phần (Component Diagram)
Sơ đồ hoạt động (Activity Diagram)
Sơ đồ triển khai (Deployment Diagram)
Sơ đồ gói (Package Diagram)
Sơ đồ liên lạc (Communication Diagram)
Sơ đồ tương tác (Interaction Overview Diagram – UML 2.0)
Sơ đồ phối hợp thời gian (Timing Diagram – UML 2.0)
Sơ đồ hồ sơ (Profile Diagram)
Về phần details giải thích từng cái bạn có thể xem video ngay ở dưới, hoặc các bạn đọc bài này nè, khá là hay luôn đó, có sẵn hình minh hoạ.
Thiệt mà để chỉ các bạn vẽ khá là tốn nhiều thời gian, nhiều khi cần phải làm video cơ. Mình xưa tự học được => mình nghĩ các bạn cũng sẽ tự học được.
Trên youtube giờ search có rất nhiều video hướng dẫn vẽ, dưới đây là 1 video, các bạn có thể xem và học nha 😀 mình đỡ làm lại
Các loại UML diagram hay được dùng
Đây là 1 khảo sát về việc sử dụng UML
Mức độ sử dụng các loại UML Diagrams
Trên là mức độ sử dụng của các loại UML diagrams, nhưng không phải chỉ áp dụng cho BA mà là cho tổng quan chung.
Qua thực tế sử dụng, với kinh nghiệm sử dụng của mình thì có những loại sau BA hay sử dụng:
Activity diagram (Nhiều chúa)
Sequence diagram (Nhiều chúa)
Class diagram (nhiều)
Usecase (Tuỳ công ty =)) có cty dùng User Stories (một phương pháp khác) nên ít sài Use case hơn)
State machine (hay gọi là State diagram) (nhiều)
Mình thấy cũng khá đúng so với cái survey trên.
Khi làm với Dev, nói sâu về tổng quan hệ thống, kiến trúc hệ thống, deployment các kiểu thì mình cũng có sài, nhưng không nhiều bằng ở trên
Component diagram
Deployment diagram
Package diagram
Object diagram
Các diagram khác hay được sử dụng.
Sơ đồ khối (Flowchart), khá tương đồng với cái Activity diagram, có vài chỗ khác, nhưng mình hay dùng để thay cho nhau (Flowchart <> Activity diagram)
Mô hình ERD (The Entity-Relationship Model)
Sơ đồ luồng dữ liệu (Data Flow Diagram – DFD)
BPMN (dùng không nhiều lắm, mình có cho survey, bạn có thể xem ở hình dưới)
Khảo sát về việc sử dụng BPMN khi là Business Analyst
Thì có (42+7+3)% = 52% số người đã votes không sử dụng BPMN trong công việc
51% số người đã votes có sử dụng, nhưng có thể thấy là tận 26% hiếm khi sử dụng.
Tổng 52+51 >100% vì được làm tròn 😀 á.
Cả 4 cái mình vừa liệt kê trên không phải là UML, nhưng thuộc loại hay được dùng, mình sẽ viết thêm bài viết về 4 loại trên cho các bạn tìm hiểu nhé, chờ đấy…
Microsoft Visio (cài ở máy Window – chưa biết hỗ trợ Mac chưa nữa, dùng trên cloud)
Draw.io (cài ở máy hoặc dùng trên cloud, gắn được trên Jira, notion đồ nữa) => Mình sài thèn này nhiều nhất, tên mới của nó là https://app.diagrams.net/, mình hay sài nó trên cloud và Jira (cũng cloud)
Figma (cài ở máy, cloud, mình toàn sài trên cloud)
Miro (mình hay sài cloud, mà giờ ít sài lại rồi) -> https://miro.com/
Cảm ơn các bạn đã đọc đến đây,.. vẫn là như cũ – hi vọng qua bài viết các bạn lại có thêm kiến thức về BA, biết thêm về UML, các loại UML, những loại nào hay sài và những loại nào cũng hay sài nhưng không phải là UML.
Và các công cụ mình hay sài để vẽ các diagram là gì => từ đó bạn có thể thử sài, học cách sài cho công việc của bạn.
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 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
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
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é.
Dưới đây là các task vụ trong BA/PO/PM mình đã áp dụng AI để thực hiện. Nhưng trước khi đọc phần này, bạn nhớ đọc phần 1 nhé, phần 1 là những nhận định cá nhân chung về các công cụ AI.
Viết user story và Acceptance Criteria
Role của mình cũng hay viết User Story, và việc xử dụng AI để viết và để viết hiệu quả mình thường sử dụng ChatGPT để thực hiện task vụ này.
Bạn có thể xem video dưới đây để hiểu cách viết nhé.
Dĩ nhiên là với AC, bạn có thể viết theo syntax “GWT” Given When Then
Scenario 1: Successful Admin Login
Given an administrator is on the Shared Login Page for Teachers and Admins, And the administrator has a valid Email and Password, When the administrator enters the correct Email and Password, And clicks the “Login” button, Then the system should authenticate the administrator, And redirect the administrator to the Admin Dashboard, And display the Admin Dashboard interface.
Và từ đó suy ra Decision Table
Tip từ bản thân mình cho phần viết này là bạn hãy input thật rõ chi tiết về User story bạn muốn, hoặc add những idea bạn đã nghĩ ra cho phần User story và bảo AI bổ sung hoặc viết chỉnh chu hơn cho User Story.
Thường thì mình có idea về tasks, và cũng hơi hơi làm biết để làm chi tiết, hoặc cụ thể hoá theo 1 cách đầy đủ => Đây là cơ hội để nhờ AI hỗ trợ =))
Mình đưa ví dụ, bạn có thể tự áp dụng thêm nha.
Như ví dụ dưới đây mình có idea về làm tròn số và có nhiều trường hợp khác nhau, mình cứ mô tả theo cách mình hiểu.
Cuối cùng với những dòng mình viết kiểu khá dài dòng, AI có thể đọc hiểu và viết gọn lại cho mình => Thậm chí mình biết ae Dev đang dùng ngôn ngữ lập trình nào, mình copy mẫu luôn cho họ.
AI hỗ trợ viết lại yêu cầu rõ ràng và gọn hơn
Hay ví dụ như viết checklist, testcase mình cũng mô tả rồi nhờ AI hỗ trợ làm rõ và viết ra các cases
AI hỗ trợ viết testcase/checklist
Với trường hợp viết testcase như này, bạn cần input thật rõ business rule cho AI để nó viết cho đầy đủ, thậm chí bạn cũng phải suy luận, đọc và kiểm tra lại xem AI đã viết đủ và đúng chưa nữa.
Vẽ Diagram
Mình sử dụng kết hợp ChatGPT + Mermaid hoặc ChatGPT + Draw.io
Các loại biểu đồ mà ChatGPT có thể hỗ trợ gồm:
Flowchart => Tận dụng làm Activity Diagram luôn cũng được
State diagram
Grantt chart
Sequence Diagram (Mình hay sài nhất)
Class diagram
ERD
User Journey
Object Diagram
Mình thì hay sài Flow chart và sequence nhất, mấy loại khác thì mình hay sài kiểu khác hơn. Các bạn cứ thử mò và tìm cách sử dụng nhé, nhớ là tự mày mò => tìm được “AI Prompting” và sử dụng nó nhiều lần để thuần thục nhé.
Bước 1: Cứ nói chuyện với AI (Prompting), sau đó khi AI đã hiểu được bài toán => Bảo tạo ra diagram (với loại Mermaid), ví dụ: “Tạo sequence diagram cho tính năng đăng nhập của giáo viên, các actor trong hệ thống gồm: Teacher, UI, BE, AuthService, sử dụng syntax Mermaid”
Bước 2: Copy đoạn code được tạo ra từ AI, bỏ vào một trong những công cụ hỗ trợ view từ Code sang Diagram.
Sử dụng ChatGPT vẽ sequence diagram – Hoàng Phan Blog
Mermaid Live Editor: https://mermaid.live/ => Cứ copy code và bỏ vào bình thường theo loại bạn muốn
Sử dụng Mermaid tạo diagram – Hoàng Phan Blog
Dùng Markdown, có thể sài trên github, visual studio code, thì trước đoạn code bạn bổ sung “`mermaid
Hiển thị trên draw.io thì bạn làm theo như hình dưới đây, sau đó paste code vào và nhấn lưu để hiển thị.
Sử dụng Draw.io và ChatGPT tạo diagram – Hoàng Phan Blog
Mình hay sài Mermaid/Draw.io nên dùng cách này, các bạn cũng có thể sài những format khác như PlanUML, StartUML nhé.
Vẽ wireframe/mockup
Nói thật với các bạn là có nhiều người nhắn tin hỏi mình về AI để vẽ mấy wireframe/mockup, mà thực sự mình rất ít khi sài :D. Kiểu giống như là cả team mình sài Figma, xong rồi mình đi sài những công cụ khác để vẽ rồi copy qua, khi cần edit nó cũng bất tiện ấy.
Một phần là khi vẽ wireframe, rõ là bước này chính là bước Elicitation của mình luôn, hay đặt câu hỏi, phân tích tới đâu vẽ tới đó, vừa visualize ý tưởng lên cho dễ hình dùng khi phân tích
Chưa kể là mình vẽ wireframe khá là nhanh :v không tốn mấy thời gian, tốn là tốn thời gian ngồi suy nghĩ luồng nghiệp vụ sao cho hợp lý ấy.
Điểm mình quan tâm ở công cụ này đó là làm sao để mình sài, và khi có kết quả được tạo ra => Khi mình bàn giao dự án cho người khác, họ vẫn tiếp tục sử dụng được resource mình đã tạo ra trước đó và họ điều chỉnh, chỉnh sửa. => Các bạn nhớ chọn công cụ phù hợp nhé. Mình thì mình vẫn trung thành với Figma 😀
Ngoài việc sử dụng AI để vẽ, mình còn dùng Pinterest, Behance để tham khảo các ideas để vẽ Wireframe sao cho hợp lí.
Viết lệnh SQL
Mình cũng hay sài để kiểu query, hoặc thậm chí các vấn đề hơi thiên về code tíu là mình sài AI để hỗ trợ.
Dĩ nhiên là yêu cầu người viết cũng cần có kiến thức sẵn về SQL để thực hiện đọc hiểu và xác thực tính chính xác của câu lệnh cho AI tạo ra.
Phần này khá phổ biến nên có rất nhiều AI hỗ trợ, mình thì sài Poe có sẵn ChatGPT, Claude, thì mình sẵn sài những con này luôn.
Bạn có thể xem video dưới đây biết biết cách sài nha.
Mình làm ở mảng blockchain, và dự án đi khá nhanh. Như một bài mình từng đề cập trước đây là khi làm các dự án Blockchain, tỉ lệ cao là hay đi copy lẫn nhau rất nhiều, ví dụ ứng dụng A có trên blockchain Ethereum, nhưng loại ứng dụng A lại chưa có trên một mạng mới, ví dụ Sei blockchain, thì mình sẽ tham khảo các dự án đã build sẵn đó (dự án A), đọc code, đọc tài liệu, cách nó hoạt động.
Các bạn có thể tham khảo các tip sau để nghiên cứu các Domain Knowledge mà các bạn chưa hiểu, hoặc chưa làm qua để học thêm cái mới, hoặc là dự án bắt buộc làm nhưng mình có kiến thức chưa đủ nhiều.
Mình sài Poe, và sài lõi Claude.AI (Claude-3.5-Sonnet) để thực hiện
Mình có những tips sau cho bạn để thực hiện.
Tip 1: Yêu cầu tóm tắt.
Thường thì các dự án blockchain hay có whitepaper, hoặc docs cho Developer, Users.
Thì mình sẽ tải file về, hoặc gửi link docs cho AI, bảo nó tóm tắt nhanh để mình hiểu.
Bước này chính là bước để mình hiểu tổng quan về cách dự án nó hoạt động.
Thậm chí có thể kêu AI vẽ lưu đồ để hiểu cách mà hệ thống đang chạy.
Tóm tắt docs với Claude – Hoàng Phan Blog
Trong quá trình tóm tắt, có thể bạn chưa hiểu hết thì có thể hỏi lại kỹ hơn để nó giải thích
Tip 2: Hỏi lại những gì AI trả lời/giải thích, để nó trả lời rõ hơn.
Ở bước này bạn có thể đặt lại câu hỏi với ý rõ hơn cho từng phần nhỏ, vì AI cũng không phải thần thánh do đó đôi lúc trả lời thiếu ý, hoặc chưa hiểu rõ kiến thức đó => Hỏi lại
Khi chưa hiểu bạn có thể hỏi lại AI để giải thích rõ hơn
Tip 3: Giải thích như một trẻ em
Thật ra nhiều lúc AI trả lời cũng hơi hơi khó hiểu, do đó bạn hãy bảo nó giải thích như một đứa trẻ em (độ tuổi cỡ 10 hoặc nhỏ hơn), thì nó sẽ giải thích và ví dụ đơn giản để bạn dễ hiểu.
AI giải thích như trẻ em sẽ giúp bạn dễ hiểu hơn
Tip 4: Đặt Q/A, hoặc kiểu câu hỏi giả định
Thường thì trong quá trình giải thích, bạn cần hỏi ngược lại AI khá là nhiều, một trong những câu hỏi mình hay đặt ra là câu hỏi “Giả định”
Ví dụ ở bài toán này mình sẽ hỏi lại là “Có khi nào tiền người dùng bỏ vào Vault thì sẽ bị giảm lợi nhuận (tiền bị âm) không?”
Câu hỏi giả định sử dụng AI
Tip 5: Bảo AI cung cấp thêm keyword để nghiên cứu
Khi bạn nghiên cứu, thường có nhiều từ khoá để bạn học thêm kiến thức liên quan đến dự án, do đó việc hỏi thêm keyword để tự nghiên cứu đi details hơn sẽ giúp bạn hiểu dự án hơn.
Hỏi AI thêm về Keyword
Sau khi có danh sách => Bạn bảo nó tiếp tục giải thích các keyword đó.
Tip 6: Sử dụng thêm nhiều nguồn tài liệu khác nhau
Ngoài ra bạn nên cung cấp nhiều nguồn tài liệu khác nhau để AI học và cùng trao đổi => Từ đó nắm rõ kiến thức hơn.
Đọc code và giải thích cách code hoạt động
Như bài toán ở trên, lúc mình tìm hiểu thì cần đụng tới code, hoặc như bài toán subscription mình từng viết trước đây thì cần đọc hiểu API.
Do đó mình luôn nhờ ChatGPT/Claude hỗ trợ trong việc giải thích code, mình thì hay tải code về + attach code vào trong AI để nó đọc và giải thích cách hoạt động.
Nhờ AI giải thích code – Hoàng Phan Blog
Và từ đó sẽ hiểu nghiệp vụ của dự án chi tiết hơn => Mà hiểu rồi thì lúc thực hiện checklist, viết các case test cụ thể hơn
Hỗ trợ phần UX Writing
AI có 1 lợi thế rất tốt về ngôn ngữ, do đó mình luôn tận dụng để AI hỗ trợ mình trong việc viết các UX writing khi làm UI cho các dự án.
Ví dụ như 1 tooltip mình không biết phải nên hiển thị gì cho gọn mà đọc dễ hiểu, mình viết những ý của mình ra, rồi bảo AI nó viết lại một số câu phù hợp, và mình đọc cũng như chọn lựa cái nào phù hợp nhất.
UX Writing – Hoàng Phan Blog
Viết docs cho user (User Guide)
Mình hay sài AI để viết docs, đặc biệt là docs viết tiếng Anh.
Input đầu vào là mình hay bảo nó re-write lại nhưng viết hay hơn, dùng từ vựng của level B1 trở xuống (thường mình bảo nó viết theo trình độ A2-B1)
Ở phần này bạn chat và cung cấp ngữ cảnh đầy đủ, ideas từ bạn nó sẽ viết lại khá hay.
Bạn có thể đọc docs này của seitrace.com, mình dùng AI hỗ trợ rất nhiều.
Này chắc các bạn cứ search google là ra nhiều video hướng dẫn lắm. Mình thường nghĩ ra 1 ideas, và trong đầu mình đã phân tích sẵn những cái mình muốn, nhưng nằm ở mức chưa quá rõ ràng details, nhưng về mặt tổng quan đã có.
Lúc này mình sẽ xem AI là một người bạn chuyên gia trong mảng đó, và mình sẽ hỏi đáp, rồi chia sẻ + hỏi cảm nghĩ của con AI về cái ý tưởng đó, rồi bảo nó cho những ý tưởng tương tự 😀
Cái này hơi mơ hồ, với lại mình không thể chia sẻ mấy cái đoạn chat mình đã nói chuyện với AI, các bạn tự nghiên cứu thêm nhé, mình chỉ share ideas thôi.
Tóm tắt nội dung cuộc họp
Otter.ai => Công cụ này các bạn search và sài đi 😀 hịn đó.
Kiểu như vào google meet hoặc một công cụ họp khác như Team, Zoom => sẽ bật con AI lên để sử dụng, nó sẽ hỗ trợ việc ghi lại nội dung cuộc họp, rồi tóm tắt.
Với việc sử dụng cả tháng nay mình thấy nó ghi nhận và tóm tắt khá chính xác nha.
Nó còn tạo sẵn luôn các action cần phải thực hiện luôn (kiểu như tasks – đầu việc)
Theo công cụ này bảo thì nó hiện tại đang hỗ trợ English (US, UK), Spanish, French.
“We currently only support transcribing in English, Spanish, and French; however, we hope to support more languages in the future. Stay tuned!”
Thiệt là mình sài AI hỗ trợ phần viết khá nhiều, đặc biệt là viết tiếng Anh, xưa môn ngữ văn, viết văn có 5/10 điểm à => Tiếng Anh viết cũng dỡ.
Mình cứ viết ý, bảo AI nó re-write lại, hoặc thậm chí là copy từ nguồn khác :v chả lẽ viết lại y chang => Bỏ qua AI nó đổi lại cho :)))
Mà nó viết format khá ok á nha, ae cứ thử nhé.
Mình đã áp dụng cho:
Viết email
Viết nội dung tuyển dụng
Viết Report
Chỉnh sửa proposal
…
Học tiếng Anh
Đối với mình, để làm BA mà sử dụng tiếng Anh giao tiếp được thì trình độ khoảng rơi vào C1 (theo chuẩn IELTs, một số chuẩn khác C1 đôi lúc cũng hơi ảo, kiểu dễ)…
Thì việc mình nâng cao trình độ tiếng Anh lên việc dùng AI cũng là một lựa chọn tốt.
Hoặc sài con ChatGPT 4o á, cũng đang hỗ trợ khá tốt, mình đã test rồi, nhưng bạn nào đã có kỹ năng nói rồi thì luyện với nó sẽ tốt hơn với việc các bạn mới. => Này các bạn cứ search youtube là có mấy video test á.
Viết code/build app
Mình thì lai lai giữa BA, PM, QC, UI Design, rồi cả Dev nữa… không quá giỏi dev nhưng hiểu logic và có thể tự build 1 sản phẩm từ A->Z dạng như CRM, mini app, các app không quá nặng về hạ tầng.
Do đó việc dùng AI hỗ trợ việc code là 1 lợi thế rất lớn với mình 😀
Mình có dùng con Claude Sonnet và Cursor AI. Ae có thể search hoặc nt hỏi mình để sharing thêm nha.
Kết bài
Ở trên là những công cụ AI mình đã sử dụng để phục vụ cho việc làm IT Business Analyst, hi vọng các bạn có nguồn tham khảo cũng như trải nghiệm và có thể áp dụng vào công việc thực tế.
Trong thời gian vừa qua, với việc AI được biết đến rộng rãi, đặc biệt là khi OpenAI đã cho ra mắt ChatGPT vào cuối năm 2022 (30/11/2022). Làm cho nhiều người quan tâm cũng như trải nghiệm sử dụng AI, nhưng mình cũng không chắc là nhiều bạn đã thực sử hiểu nhiều về AI và đã áp dụng nó vào công việc được chưa.
Với bài viết này, hôm nay mình xin phép chia sẻ những suy nghĩ và trải nghiệm cá nhân, cũng như qua việc sử dụng AI vào thực tế công việc.
Cần hiểu về AI
Hiện tại, đối với mình thì AI là một công cụ hỗ trợ đắc lực cho mình, với việc sử dụng qua những công cụ như ChatGPT, Claude, Midjourney,… những công cụ hay được nhắc tới. Mình chưa nhắc tới một số công cụ AI trong robot, hay AI trong tự động lái nha, chuỗi tự động hoá, …
Thì những công cụ này sẽ nhận vào 1 input đầu vào (AI Prompting) và gửi cho AI, AI sẽ sử dụng các mô hình học máy để phân tích và hiểu dữ liệu, từ đó đưa ra và tạo những câu trả lời hoặc hành động dựa trên dữ liệu đã xử lý để trả ra cho User. Trong quá trình trao đổi trong một cuộc trò chuyện (1 đoạn chat) thì AI cũng sẻ học tập, cải thiện để phân tích ra những dữ liệu và điều chỉnh cho đáp án phù hợp.
Cách AI hoạt động cơ bản
Vậy cần hiểu “AI Prompting” là gì?
AI Prompting mô tả hình thức mà con người có thể giao tiếp với AI bằng ngôn ngữ tự nhiên, để cho AI có thể hiểu và trả kết quả đúng như ta mong muốn.
Và khi ta biết cách tạo AI Prompting để AI hiểu ý muốn của chúng ta và thực hiện theo ý của ta => Ta có thể gọi nó là “Làm chủ và sử dụng AI”
Do đó khi các bạn tìm hiểu và sử dụng 1 công cụ AI nào đó, thì hãy bỏ chút thời gian nghiên cứu về cú pháp trao đổi với AI, mỗi AI lại có một cái prompting cho hiệu quả khác nhau. Việc sử dụng AI có hiệu quả hay không là nhờ cách bạn nghĩ ra Prompting phù hợp nhất.
Hiện nay trên youtube/google chia sẻ rất rất nhiều tips để làm được những điều này. Và các bạn có thể học hỏi, sử dụng AI nhiều từ đó có những kinh nghiệm riêng, viết Prompt A mà chưa đúng thì điều chỉnh, thêm bớt để cho phù hợp hơn, nếu chưa được thì lại tiếp tục gửi Prompting mới => dần dần sẽ tạo thành kinh nghiệm.
Prompting AI – Hoàng Phan Blog
AI có thể thay thế hoàn toàn một BA không?
Theo mình là không?
Bản chất thì BA là làm những công việc như Gathering requirement, elicitation, … thì giờ khi làm việc BA vẫn sẽ làm những bước đó, AI không thể thay thế, nó chỉ là góp sức thêm, vẫn cần người suy nghĩ và viết Prompting
Nhận định sai về AI
AI không thể giải quyết ngay 1 bài toán lớn, mà ta phải mơn mớn cung cấp dữ liệu, phân rã từng task nhỏ và giao cho AI ⇒ Do đó cũng cần người phân tích/ bóc tách cho dữ liệu đầu vào cung cấp cho AI những dữ liệu phù hợp và đầy đủ. Sau đó là tổng hợp/ đánh giá dữ liệu đầu ra từ AI, vì AI cho rất nhiều insight, và không phải cái nào cũng đúng ⇒ Người sử dụng AI cũng cần có kinh nghiệm về Tech, về BA trước đó để nhận định đúng sai.
Cho ví dụ ở đây về bài toán phân tích luồng subscription trong thanh toán dự án Seitrace của mình:
Mình đã hiểu subscription nó hoạt động ra sao
Nhờ AI tư vấn những bên cung cấp dịch vụ
Mình phải vào đọc tài liệu/ đọc code/API của những dự án đó + nhờ AI support giải thích nhanh
Sau khi hiểu ⇒ Nhờ AI đánh giá các bên phù hợp nhất với nhu cầu ⇒ mình check và kiểm chứng lại
Tổng hợp luồng tổng quan để đi qua 1 bên cung cấp thứ 3 phù hợp với bên mình nhất ⇒ Và mô tả cách hoạt động cho AI ⇒ AI vẽ luồng Sequence phù hợp.
Tức là AI ở đây được sài kiểu như giúp mình làm chi tiết hơn cho một số công việc. Từ một tasks lớn cần 3 ngày giải quyết xong, thì có thể nhờ AI mà ta giảm bớt 1 số công việc chi tiết nhưng lại tốn nhiều thời gian => Từ đó giảm còn 1 ngày để hoàn thành xong task.
Nhưng sẽ làm giảm lượng nhân sự trong một đội ngũ (Tức là dùng AI giúp doanh nghiệp giảm chi phí thuê nhân công)
Ví dụ thực tế là ở công ty mình, lượng việc khá nhiều và nếu trước kia chưa sử dụng AI mình nghĩ phải cần tuyển thêm 1-2 bạn BA để phụ tasks (Bản thân mình là 1 manager nên khá hiểu câu chuyện estimate task). Nhưng với việc mình biết sử dụng AI, làm cho hiệu quả công việc mình tăng lên rất nhiều => từ đó với ngày xưa 3 ngày xong 1 tasks lớn, thì giờ mình vẫn với 3 ngày đó có thể làm thêm 1-2 tasks với độ khó tương tự => Không cần tuyển thêm vẫn cover được.
Giả dụ một công ty với đội ngũ 20 nhân sự BA, và giờ Công ty biết cách đưa AI vào sử dụng, mình chỉ ví dụ là các bạn biết sử dụng ở mức tương đối (trung bình), và giúp các bạn giảm được 20% thời gian thực hiện task => Thì từ 20 nhân sự công ty có thể chỉ tuyển 16 nhân sự… (này là mình ví dụ =)) vì không chắc các công ty có đưa AI vào làm việc hoặc có vi phạm privacy gì không nữa)
Thách thức và lợi thế của người sử dụng AI
=)) Đôi lúc mình cũng cảm giác não mình bớt suy nghĩ logic đi 1 tí, cứ đụng là AI =)) cũng sợ lâu quá bị lụt nghề, hoặc thậm chí giảm đi tính tư duy… giống như xưa sài máy tính cầm tay á => làm giảm khả năng tính nhẩm 😐 đôi lúc kiểu 35 + 18 = XX thì lôi máy tính ra bấm :3 hoặc kiểu gõ lên google để tìm ra đáp án thay vì tính nhẩm (có kết quả nhanh hơn).
Thách thức:
Như ở trên có nói, dễ bị phụ thuộc quá nhiều vào nó
AI đôi lúc đưa ra insight ẩn => làm ta bị đánh lạc hướng/ đi sai hướng
Bảo mật dữ liệu, đôi lúc dùng => dữ liệu bị chia sẻ ra ngoài
Chi phí… nếu công ty tự build thì chi phí khá cao, còn đối với User sài bình thường thì như sài ChatGPT mỗi tháng 20$ cũng khá cao nếu bạn không biết tận dụng AI vào việc giúp bạn giảm hiệu suất, cũng như đôi lúc ngại việc trả tiền cho AI
Tốn công training, AI mà… cần 1 lượng dữ liệu khá lớn, với các công ty lớn thì dĩ nhiên cần training khá nhiều, còn sài cá nhân cũng phải biết cách nạp dữ liệu cho nó để nó có 1 context, dữ liệu từ đó phân tích và đưa ra đáp án đúng cho bạn.
Độ chính xác,… thiệt lòng mà nói thì AI… hiện tại độ chính xác cũng kiểu 80-20 (cảm nhận cá nhân),… mình qua thời gian thấy AI cung cấp dữ liệu khá ổn, đúng được cỡ 80%, còn 20%… hay sai lắm. Vậy lỡ bạn sài và không nhận ra 20% cái sai kia thì … toang. 😐
AI trả lời sai – Hoang Phan blog
Lợi thế:
Tăng hiệu quả công việc: như chia sẻ ở trên rồi
Tạo tài liệu, … đây là 1 phần của tăng hiệu quả công việc, giúp ta có thể tạo tài liệu nhanh hoặc với một idea với một số ý nội dung => AI có thể giúp để Gen ra chi tiết hơn
Hỗ trợ tăng insight, đôi lúc bị bí ý tưởng, hoặc nghĩ không ra, cho AI 1 input và cố gắng trò chuyện với AI kiểu như AI là một chuyên gia từ đó có thêm nhiều insight + keyword để tìm hiểu thêm
Giúp dịch thuật: Giúp tóm tắt thông tin, Q/A, đôi lúc là dịch từ ngôn ngữ khác sang ngôn ngữ “tiếng Việt” cho bạn đọc hiểu.
Tìm thông tin/câu trả lời nhanh hơn… với cách trước đây ta sử dụng google để tìm đáp án, như hôm rồi mình tìm số liệu về doanh thu của 1 số competitors, search google tốn rất nhiều thời gian, nhưng sài AI => Nó cho mình kết quả có vẻ nhanh hơn,.. với này cũng tuỳ topic, thông tin mình đang tìm nhé.
Hỗ trợ ra quyết định =)) Cung cấp thêm thông tin và gợi ý để hỗ trợ ra quyết định lẹ hơn.
=> Bạn biết sài => là đã có thêm ít nhất 1 lợi thế rồi đó.
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
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
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é.
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.
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
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é.
