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ế.
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é.
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
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é.
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
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
Và sẽ nhận được luồng như sau.
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é.
… 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.
Nhân dịp đầu năm 2024, BA Zone (Hoàng làm Admin tại cộng đồng này) ra mắt trang tin BA School. Với mục tiêu kết nối và mang lại giá trị cho cộng đồng. Đội ngũ BA Zone tổ chức một sự kiện miễn phí dành cho cộng đồng Business Analyst Việt Nam.
Sau một thời gian dài lắng nghe tâm sự về những khó khăn khi làm Business Analyst nhưng chưa biết bắt đầu từ đâu. Nhất là trong bối cảnh thị trường tuyển dụng BA ngày càng khó hơn như hiện tại. Ngoài kiến thức nền tảng, các doanh nghiệp lớn giờ đây đã đưa những yêu cầu về ứng viên cần có chứng chỉ BA quốc tế như CCBA, CBAP như một điều kiện bắt buộc cần có.
IIBA cũng đưa ra thống kê những ứng viên có chứng chỉ quốc tế có nhiều cơ hội việc làm tốt hơn và có mức lương cao hơn 12%.
Vậy nên đội ngũ Admin BA Zone đã quyết định tổ chức một buổi Workshop online để giúp các bạn tìm hiểu về nghề BA dễ dàng hơn. Đặc biệt là giúp các bạn đang làm Business Analyst có kế hoạch thi chứng chỉ quốc tế như CCBA, CBAP được thuận lợi hơn.
Trong buổi workshop này, chúng ta sẽ cùng nhau chia sẻ những nội dung:
Phần 1: Giới thiệu cộng đồng BA Zone
Phần 2: Lộ trình phát triển nghề Business Analyst
Phần 3: Giới thiệu tổ chức IIBA và các chứng chỉ BA Quốc Tế
Phần 4: Kinh nghiệm thi chứng chỉ CCBA và CBAP
Cách ôn thi chứng chỉ BA hiệu quả, tiết kiệm chi phí
Cách đọc sách Babok v3 hiệu quả
Hướng dẫn làm đề thi thử
Những kinh nghiệm khi làm bài thi
Những vùng kiến thức trọng tâm cần biết khi thi CCBA/CBAP
Những mẹo làm bài giúp bạn tăng tỷ lệ đỗ chứng chỉ
Phần 5: Giao lưu, trao đổi cùng khán giả.
Buổi Workshop có sự góp mặt của các khách mời là đội ngũ Admin BA Zone:
Host chương trình:
Phúc Nguyễn – Founder BA Zone | Business Analyst Lead VNPAY
Hoàng Phan – Admin BA Zone | Co-Founder Cavies Labs
Ms.Hồng có hơn 5 năm là Kỹ sư Giải pháp nghiệp vụ tại Viettel AI.
Tham gia phát triển nhiều sản phẩm lớn trong lĩnh vực Phân tích dữ liệu và Trí tuệ nhân tạo…Đặc biệt với vai trò Admin, Mentor BA Zone Ms. Hồng sẽ chia sẻ những kinh nghiệm rất hữu ích về kì thi CCBA và CBAP.
Hà Mạnh Trí Toàn | Senior Business Analyst
Bachelor of Business in Information Systems, Minor in Logistics and Supply Chain -RMIT
Trong quá trình làm Business Analyst, Mr.Toàn cũng đã thi 2 chứng chỉ BA chuyên nghiệp dành cho BA đó là chứng chỉ CCBA năm 2020 và chứng chỉ CBAP năm 2023. Đây là chứng chỉ cao nhất do IIBA quốc tế cấp. Đặc biệt Mr. Toàn còn chia sẻ kinh nghiệm thực tế khi du học Master BA dành cho các bạn quan tâm.
Với Workshop lần này, đội ngũ Admin mang đến những kiến thức, kinh nghiệm, trải nghiệm về nghề BA. Những kỹ năng nền tảng cần có để giúp BA phát triển hơn trong sự nghiệp.
Đặc biệt sự kiện online miễn phí vì cộng đồng – Bên cạnh đó các bạn sinh viên năm 4 tham gia sự kiện còn có cơ hội được tham gia chương trình “BA Zone Mentorship Program” miễn phí dành cho các bạn sinh viên muốn làm BA.
Với phương châm “Learning and Sharing Knowledge for BA”, mục tiêu của BA Zone là nơi học hỏi, chia sẻ và giúp cộng đồng BA phát triển.
Mình bắt đầu sử dụng công cụ Figma đã được gần 2 năm, trước đây rất lâu được nhiều bạn giới thiệu nhưng vì những công ty mình làm việc qua đều không sử dụng công cụ này.
Nhưng khi có cơ hội được vào một môi trường startup, nơi mà tất cả mọi thứ chưa được định hình, tự công cụ quản lý, process – quy trình, vận hành, đội ngũ, và cả những công cụ sử dụng để vẽ wireframe/mockup/design/prototype.
Do đó mà tại thời điểm đó mình mạnh dạng đề xuất quy trình vận hành, và tất cả công cụ cho đội ngũ công ty sử dụng (và đặc biệt là team Tech), những công cụ mình đề xuất gồm có:
Công cụ quản lý task/process: Sử dụng Jira hoặc Larksuite hoặc Notion
Công cụ viết tài liệu: Notion hoặc Confluence
Công cụ vẽ thiên về wireframe/mockup/prototype: Figma
Công cụ brainstorming: Figma & Miro
Công cụ vẽ diagram: Figma Jam và Draw.io
Kênh chat trao đổi: Sài mặc định công ty đang sài Telegram
Meeting: Google Meet/GG Calendar
Một số công cụ riêng cho team Dev như Github/Gitlab, CI/CD, DB: MongoDB, Postgre,… thì do ae chuyên về Dev tự đề xuất cho phù hợp mình follow theo.
Công cụ Figma
Giới thiệu xong rồi thì vào phần nói về Figma thôi.
Thực ra công cụ này được giới làm UX/UI biết tới nhiều hơn dùng để vẽ UI (User Interface) và làm về UX (User Experience), nhưng dĩ nhiên khi làm những công việc BA vẫn có thể sử dụng nó, vì dùng Figma ta có thể vẽ Wireframe, Sketch, Mockup,… rồi dùng để brainstorming, và vẽ cả diagram (thường mình vẽ activity diagram ở đây)
Vì sao mà mình lại đề xuất sử dụng Figma như vậy?
Thực tế là mình đã sử dụng qua rất nhiều công cụ dùng để vẽ wireframe/sketch/mockup, làm prototype và trao đổi với đồng nghiệp như là: Axure RP, Balsamiq Mockup, Adobe XD, Sketch, thậm chí từng làm việc với Photoshop để view wireframe/mockup khi đi làm cho các dự án/công ty. Và dùng thử qua các công cụ kiểu như FluidUI, Mockflow,… nhưng chưa áp dụng vào công việc thực tế.
Nhưng vì có những ưu điểm mà mình thấy nó đã hội tụ đủ mọi yêu cầu về công việc của mình:
Miễn phí/paid: nếu mình áp dụng cho công ty thì sẽ dùng bản trả phí, còn nếu mình làm freelancer mình sài phiên bản miễn phí, tối đa là 3 figma files và 3 figjams. Nếu bạn dùng phiên bản Education (free 2 năm) thì sẽ không giới hạn số file, số pages và có thể cùng với những người khác edit chung 1 files, cuối bài viết mình sẽ hướng dẫn đăng ký.
Vẽ wireframe và mockup: Dĩ nhiên công cụ này để vẽ UI/UX nên việc dùng để vẽ được wireframe và mockup là điều hiển nhiên được 😀
Thiết kế prototype: Mình thường hay present design cho đối tác và anh em trong team, hoặc present trực tiếp với ae đội ngũ C-level, nên việc có tính năng prototype sẽ rất tiện để trực quan hoá một design/wireframe/idea hay luồng trong khi build một ứng dụng.
Vẽ diagram, brainstorming: ở Figma có tính năng Figjam giúp vẽ diagram rất tiện, còn có hỗ trợ các widget như đếm giờ hay note trực tiếp trên canvas => dùng thảo luận brainstorming rất đã.
Nhưng thực tế là mình sài draw.io cho việc vẽ diagram nhiều hơn :D, draw.io nó được tích hợp trong confluence nữa.
Comment xuyên lục địa, cộng tác đa người dùng: yeah, tính năng này mình cực kì thích khi mà phải làm việc với nhiều stakeholders khác nhau, nên việc có thể cho nhiều người vào xem, phân quyền view only hoặc cho edit, và có thể comment góp ý trực tiếp trên chính xác vị trí đề xuất, tính năng này tuyệt vời hơn trên XD Cloud và Axure, Balsamiq cloud khi mà comment nó đôi lúc bị trật chỗ, chưa kể trên XD nó cho webview tách từng frame nằm trên 1 page rất khó để review, chưa biết nay đã update lại chưa :D. Yeah, cái này mình thích nhất á =)). Đã đã.
Chia sẻ dễ dàng, nhiều người cùng vào xem mà không cần gì cả: Như mục 5 có nhắc, thì chỉ cần chuyển qua view with the link by anyone, thì ai có link đều có thể xem design mà không cần tài khoản, nên khi đó ai hỏi mà họ được quyền xem design => Đưa họ cái link là họ xem được rồi. Xưa mình sài Balsamiq desktop, nên việc share này cực kì mệt, chưa kể phần góp ý cứ screenshot rồi edit trên screenshot rất là mệt.
Các thiết kế cùng nằm trên 1 canvas/project, zoom nhỏ ra để xem tổng quan và zoom to vào để xem chi tiết: Này thì mình nghĩ giờ nhiều công cụ đã hỗ trợ, nhưng bên figma có hỗ trợ mấy tính năng ở mục 5, 6 thành ra thấy tính năng này khá tiện.
Tài nguyên phong phú (free & trả phí), mình có thể lên Figma Community và tải về các thiết kế có sẵn hoặc mẫu wireframe, nên khi mà thiết kế wireframe, mình hay dùng các component mình clone sẵn và gọi ra để sử dụng, nên vẽ rất tiện luôn. Ví dụ mình thường có các component sẵn như Popup thông báo (với nhiều style như 1 button, có nút close, hoặc popup có 2 button, …), Buttons, Tables, …
Ngoài ra có các widget và plugin nơi mà mình dùng icon miễn phí (đôi lúc là trả phí), và nhiều thứ hay ho khác, bạn nên sài và thử nghiệm 😀
Sử dụng component: Như mình chia sẻ ở trên, thì có component nên khi mình vẽ wireframe rất tiện luôn, đầu tiên là clone component qua 1 project mới, rồi sau đó khi vẽ sẽ gọi ra sử dụng và sửa content, thay vì phải vẽ từ đầu từng elements rất chi là cực. Nên rất là speed up thời gian mình hoàn thành tasks.
Dễ dàng học và sử dụng: Theo mình thì nếu bạn đã quen sử dụng 1 công cụ design thì việc sử dụng Figma rất chi là dễ, thậm chí là có thể bạn chưa sài nhiều thì tiếp cận nó rất dễ, trong cty mình nhiều bạn chưa sài bao giờ, mình chỉ làm 1 buổi seminar chia sẻ thôi thì về các bạn sài được hết mà gần như không có Q/A gì thêm, vì các bạn đó chỉ sài tính năng basic nên sẽ ít hỏi lắm 😀 còn ông nào làm chuyên design thì không kể tới nhá, mấy cái như variants, effects, auto layout, different states,…
Kết hợp với team design, review design/luồng: Này thì như mục 5, 6 khi mà mình vẽ wireframe xong, cùng trên 1 project đó design sẽ mở page riêng và vẽ design trên đó, dữ liệu thiết kế được tổng hợp tại một nơi, rồi từ đó mình cũng review design trực tiếp bằng comment luôn, nghĩa là team BA/PO và UX/UI Design sài chung 1 project trên figma.
Dùng như một công cụ để mình thiết kế banner/standee/…: Mình hay sài như này để thiết kế banner/standee/ rồi mấy hình cần thiết, mình xem nó như 1 công cụ giống Adobe Illustration (AI), bao gồm cả việc thiết kế logo luôn nha khi mà mình có thể export file vector hay export png, pdf,…
Đôi lúc export ra được html để xem trước trên webview như một website thực sự: Này thì sau khi thiết kế ra xong, mình hay export ra html rồi mớ view trên các screen khác nhau, lý do là khi view trên canvas đôi lúc nó bị sai size và mình không nhận ra được sự khác thường, mình từng bị trường hợp này rồi khi thiết kế nhìn trên canvas nhìn rất ok, nhưng khi dev ra sản phẩm, layout nhìn rất là chán vì các element bị bự ra so với cách mình nhìn trên canvas,… màn hình bự cỡ 27, 32 inch thì không sao, chứ khi trên màn hình cỡ 14 inch là nhìn nó chán lắm. Nên tính năng này cũng là thứ cần thiết (dĩ nhiên là có thể làm kiểu prototype để view cũng đc, nhưng html giúp mình xem nó real hơn 1 tíu).
Còn mấy lý do khác thì giờ mình chưa nghĩ ra,… khi nào thấy có thêm thì mình bổ sung vào bài.
So sánh Figma với các công cụ khác
Thực ra tính không viết phần này, vì đa số các công cụ mình sài chưa hết tính năng đâu, chỉ sài 1 phần các tính năng, nên khi so sánh sẽ bị thiếu sót gì đó,.. nhưng mình cứ chia sẻ theo quan điểm và cách mình sử dụng để mọi người có thể thấy 1 cách nhìn nhận nào đó hé.
Chắc nói mấy cái hơn của Figma đi ha, tại giờ mình mê Figma quá nên …. à…
So với Adobe XD:
Dễ comment, review hơn, trên XD lúc comment nó hay bị sai vị trí sao đó
Dễ sharing hơn, trên XD nó bị 1 lỗi là nó tự động zoom hơi bị to so với size mình thiết kế, chưa kể zoom in, zoom out không được mượt lắm
Mình thấy XD hỗ trợ phần component không được xịn như trên Figma lắm, sài Figma sướng hơn nhiều, chưa kể trên Figma có nhiều thư viện bao đã.
Thật ra mình thích cách dùng XD để thiết kế banner/standee, logo nha, xưa là sài XD làm việc đó không á
Trước khi sài Figma, thì công cụ chính mình sài là XD, nhưng khi sài Figma nhiều rồi thì lại sài Figma nhiều hơn.
XD giờ không có bản free nữa, xưa có giờ thì không còn.
XD thì mình chưa thử nghiệm làm việc với member khác kiểu nhiều người edit 1 file, nên k review chỗ này.
So với Axure:
Axure xưa mình phải sài crack rất cực luôn, phải trả phí để sài (không biết giờ có bản free chưa), nhưng có bản cho students/teachers dùng free 1 năm.
Khúc làm prototype bên Axure hơi bị cực
Lúc vẽ wireframe mình cũng thấy cực nốt, cực hơn khi vẽ bên Figma rất nhiều, kiểu vẽ từng elements, rồi đổ dữ liệu vào, với lúc ra element nhìn như thời window hay kiểu UI của element nó cũ cũ sao đó.
Được cái nó hỗ trợ kiểu như Git để mà làm việc với team, nhưng mình lại thấy hơi phức tạp để sài.
Mình thấy công cụ này mà kiểu công ty bự bự sài sướng, crack để sài nên cũng giảm bớt chi phí sử dụng cũng ok.
Axure cũng có các thư viện khá là okela như Figma.
Sài ver desktop nên khi làm việc với members khác sẽ khó, phải export rồi gửi file xong import, quản lý version rất cực
Bản cloud thì buộc phải trả phí => cũng phần làm việc với team khá ok chỗ này, cũng ok chỗ quản lý version luôn.
Được cái Balsamiq mình thấy còn dễ sài hơn cả Figma, nhưng mà cũng bị giới hạn phần components và elements có sẵn, muốn sài xịn phải tự define ra khá là cực.
Balsamiq vẽ wireframe cũng nhanh, nhất là mấy cái liên quan đến table thì balsamiq là nhanh lắm (so với các công cụ khác)
Bước 5: Điền thông tin Get free Figma for Education
Nhớ là bạn đang đăng ký với Figma bạn là 1 sinh viên => bạn cần phải xác nhận bạn là sinh viên
Bằng cách điền các thông tin như sau:
Are you a student or an educator? chọn Student
What type of institution do you attend or work for? => Chọn K12 => Rồi 2 câu dưới chọn Agree, Agree
Why are applying for a free Figma Education plan: Bạn nên gõ tiếng Việt, ghi gì cũng được, đại loại là tui cần acc figma để làm bài tập, mình thì hay ghi bằng tiếng Anh “For doing assignment from teachers where I can design User Interface and Wireframe for application”
School name: School not listed
Full school name: nhập tên tiếng Anh của 1 trường đại học bất kỳ => Như mình học UIT thì mình điền đúng University of Information Technology – VNU HCM.
Nhâp địa chỉ Website của trường bạn đã khai báo ở trên: nhập đúng website chính của trường
Why is your primary field of study: Chọn bất kỳ theo ngành trường đó dạy, ví dụ mình chọn Information Technology hay kiểu kiểu vậy.
Expected graduation date: chọn tháng nào cũng được, năm 2024 trở đi, nên chọn từ năm hiện tại + 2 năm nữa là ok nhất.
Có 1 bước là upload lịch học, thì bạn cứ lên web chọn đại 1 lịch học nào đó điền, mình thì vào trực tiếp lịch kế hoạch năm file png của trường mình upload lên.Mình thấy là khi đăng ký tuỳ lúc nó ra form thông tin khác nhau, bạn điền sao cho hợp lý nhất là được nhé, lúc thì chỉ show có vài trường, lúc thì show 1 mớ thông tin. => Tuỳ cơ ứng biến thêm nhé.
Bước 6: Tạo team
Bạn chỉ cần điền tên Team rồi tạo thôi.
Sẽ có bước mời thành viên team => bạn có thể mời hoặc skip nhé, tuỳ mục đích.
Bước 7: Chọn gói dịch vụ và thanh toán (Free)
Lúc này bạn nhấn vào team => Sẽ có popup show ra và chọn Next cho team đó.
Sau đó chọn thanh toán (upgrade)
Vậy là giờ bạn đã có tài khoản Figma Edu được dùng như bản Professional trong 2 năm.
Kết bài
Như vậy là mình đã chia sẻ công cụ Figma, một công cụ tuyệt vời cho anh em Business Analyst, không chỉ là một công cụ để thiết kế mà còn có một công cụ để tư duy, trình bày và thực hiện ý tưởng của mình một cách chuyên nghiệp và hiệu quả, dù bạn làm trong team nhỏ hay lớn.
Và cũng đã chia sẻ luôn cách đăng ký tài khoản Figma Edu (free 2 năm).
Hi vọng giúp cho anh em nào chưa từng sử dụng tìm được công cụ mới hữu ích khi làm công việc Business Analyst nhé.
Mấy bữa trước ngồi chia sẻ cho một bạn BA mới vào làm mảng blockchain nắm thêm các môi trường phát triển phần mềm, nên sẵn có dịp viết lại để chia sẻ đến mọi người, có vẻ nó sẽ là kiến thức khá cũ với mọi người, nhưng đôi lúc bạn phân vân không biết được testing environment và staging environment khác nhau như thế nào, hay thỉnh thoảng lại bảo dev là “Deploy lên cho mình test với” thì dev hỏi lại “Deploy lên môi trường nào?”, hoặc thậm chí là bạn không biết khi nào gọi tên môi trường cho đúng và phù hợp, hi vọng dưới góc nhìn của một BA sẽ giúp bạn hiểu các môi trường này và áp dụng, triển khai nó một cách an toàn, hiệu quả.
Các môi trường trong phát triển phần mềm
Những môi trường mà mình nhắc đến trong bài viết hôm nay sẽ gồm có: Localhost (Development), Testing, Staging, Production, Sandbox, và một môi trường có thể hơi hơi lạ với một số người là Pilot, Devnet, Testnet.
Trước hết cho cái hình để bạn dễ hình dung hơn
Phân biệt các môi trường phát triển phần mềm
Môi trường Development/Localhost:
Môi trường này là môi trường người Dev dựa theo tài liệu của BA và xây dựng tính năng trên máy của tính (local) của họ, người khác không thể truy cập server ngoài họ.
Database kết nối: Là database test, hoặc sandbox (tẹo mình sẽ giải thích sandbox là gì)
Người thực hiện test:
Người thực hiện test trên môi trường này chính là người Dev luôn, hoặc là một người Dev khác họ pull code về và chạy thử, test lại tính năng.
Đôi lúc team test nội bộ sẽ pull code của Dev xây dựng xong về test trên máy local của team test nội bộ luôn, nhưng mình nghĩ này có nhưng ít.
Vai trò của BA: Thường là hỗ trợ giải thích tính năng, nghiệp vụ, kiểm thử tính năng mới/hoặc bug fixed.
NOTE: BA cũng được xem như một phần của team test nội bộ
Môi trường Testing:
Môi trường này thường là môi trường được đội ngũ team test nội bộ chạy kịch bản kiểm thử đã được thiết kế trước, giúp tìm lỗi và sự cố trong phần mềm, đảm bảo chất lượng phần mềm trước khi lên những môi trường tiệm cận production, hoặc production.
Còn về phần dev thì xem thử mấy tính năng họ code có tích hợp được với code có sẵn hay code của người khác chạy được trơn tru hay không?
Database kết nối: Là database test hoặc sandbox
Người thực hiện test:
Người thực hiện chính là nhóm kiểm thử nội bộ
Dev đôi lúc sẽ vào test để kiểm tra lỗi có bị như nhóm kiểm thử nội bộ đã report hay không.
Vai trò của BA: Thường là hỗ trợ kiểm thử, review bugs, đứng ra làm việc giữ tester và dev để xác nhận bug là bug thật hay có thể bỏ qua, giải quyết tranh cãi giữa họ, có thể dùng môi trường này để UAT (một số trường hợp).
Môi trường Staging:
Cũng là môi trường test nhưng tập trung vào phần tương thích và ổn định của phần mềm trước khi triển khai, môi trường này gần như sát với môi trường production.
Database kết nối: Là database test hoặc sandbox, đôi lúc có thể cắm trên database production hoặc là lấy database production clone ra và đổi hay dấu đi những thông tin nhạy cảm như email, số điện thoại, id nhận notification,…
Tại vì khúc này môi trường cần gần giống với production để khi go live tránh xảy ra lỗi hoặc sự cố không đáng xảy ra nên cần phải có configuration/phần cứng, service tương tự với production.
Có những cái khi mà dev chạy trên local/testing env thì thấy ngon nghẻ, nhưng đẩy lên production cái sinh ra lỗi => Cũng là một lý do để có môi trường staging để tạo cơ hội cho dev tìm lỗi liên quan đến configuration, tính tương thích với phần cứng.
Người thực hiện test:
Người thực hiện chính là khách hàng hoặc nhóm kiểm thử nội bộ
Dev kiểm tra lỗi do KH hoặc tester report.
Đôi lúc vẫn có thể cho một số nhóm user đặc biệt test cùng (kiểu như sài thử và đưa ra feedback)
Vai trò của BA: UAT, follow nắm thông tin từ khách hàng khi họ test, trao đổi nghiệp vụ nếu cần, review lại bugs, confirm một số bugs có tranh cãi.
Môi trường Production:
Là môi trường chạy thật với người dùng và dữ liệu thật
Database kết nối: Là database thật.
Người thực hiện test:
Tester thực hiện test khi release sản phẩm
Dev kiểm tra lỗi do người dùng cuối report
BA follow hoặc kiểm tra lỗi do người khác report.
Người dùng cuối sử dụng
Vai trò của BA: Tương tác với người dùng cuối hoặc nhận thông tin từ bên khác liên quan đến lỗi, giải quyết vấn đề phát sinh, hỗ trợ người dùng, hoặc phân tích dữ liệu/ux để tìm ra những giải pháp tốt hơn cho phần mềm.
Môi trường Pilot:
Môi trường này mình mới biết từ năm 2019 khi làm các dự án liên quan đến banking.
Là môi trường chạy thật với một nhóm người dùng đặc biệt và dữ liệu thật, nhóm này sẽ đưa ra các nhận xét góp ý cho ứng dụng.
Thường thì Pilot sẽ nằm sau giai đoạn UAT và trước khi lên production
Test trên thời gian thực để tìm ra lỗi.
Không phải dự án nào cũng có môi trường này
Database kết nối: Là database thật.
Người thực hiện test:
Nhóm người dùng cuối đặc biệt được lựa chọn sẵn để sử dụng trước sản phẩm.
Nhóm kiểm thử team nội bộ và khách hàng.
Vai trò của BA: Tương tác với nhóm người dùng đặc biệt để thu thập phản hồi, ý kiến góp ý, từ đó giải quyết các vấn đề phát sinh.
Đây cũng là một môi trường xác minh tính sẵn sàng của dự án, nên mọi thứ giống y chang production, chỉ khác là cho một nhóm người sài, những người dùng cuối khác chưa được sài.
Môi trường Sandbox:
Sau khi xem xét thì thấy Sandbox không nên xếp vào nhóm của Localhost, testing, staging, pilot, production, mà nó là 1 kiểu thể loại khác.
Có thể hiểu nó là môi trường thật dùng thử, thường được sài cho những hệ thống liên quan đến tiền bạc, tài chính, payment
Vì là dùng thử nên nó là database thử (test) chứ không phải database thật, hoặc là clone từ thật ra, chỉ cần thay đổi endpoint (api) thì sẽ có thể giúp phần mềm hoạt động trên môi trường real.
Nếu không có sandbox thì khi test có thể khó cover nỗi những tính năng liên quan đến tiền thật.
Mình thấy nó khi làm blockchain, hoặc banking, billing, AAS, payment gateway.
Một số tên khác
Testnet/Devnet: Môi trường test/sandbox của một blockchain
Goerli, Sepolia: Môi trường testnet/sandbox của Ethereum.
Lưu ý khi làm việc trên các môi trường khác nhau.
Không nên để khách hàng vào môi trường testing, sau khi mình làm với rất nhiều khách hàng cho thấy để KH vào môi trường test họ sẽ thấy những cái không hay, hoặc có khi họ không hiểu mình đang làm gì và tưởng là mình đang làm sai yêu cầu, hoặc gây ảnh hưởng đến quá trình test của team nội bộ khi KH vào và thay đổi một số cấu hình.
Ở môi trường local host -> Có những trường hợp cần chạy cronjob liên tục hay sửa database sướng hơn trên môi trường testing (dù trên testing env vẫn thực hiện được nhưng đôi lúc gặp khó khăn)
Chia thành nhiều môi trường testing hoặc kế hoạch release trên testing env theo từng giai đoạn để tránh bug nó bị lộn xộn, ví dụ như báo bug xong dev fix và đẩy ngay lên testing mà không báo, hoặc 2-3 testers nhảy vào test chung 1 môi trường nhưng lại thay đổi DB có ảnh hưởng lẫn nhau, làm cho kết quả test bị rối hoặc bị sai.
Điều quan trọng là phải có môi trường Testing độc lập để không ảnh hưởng đến các môi trường khác và giúp dev tập trung vào việc tìm lỗi và sửa chúng, chứ đụng lỗi cái báo và fix liền, xong deploy lên test liền thì không hay.
Môi trường Staging, Pilot đôi lúc không cần thiết phải có mà có thể gộp lại thành môi trường testing thôi, lý do chính là khá tốn chi phí, tài nguyên khi phải cần gần giống với môi trường production.
Khi test ở Pilot hoặc Staging, BA cần kiểm tra lại với các thành viên khác vì có dính tới database thật, có thể sẽ gửi những kết quả test đến cho người dùng thật, do đó nên phân nhóm người dùng được nhận hoặc thay đổi email/phone thật thành những dữ liệu test.
Đối với môi trường Pilot, luôn phải có một kế hoạch liên quan đến việc Rollback release để khi có trường hợp xấu sẽ xử lý được.
Kết bài.
Với những chia sẻ của mình hi vọng các bạn hiểu được từng môi trường phát triển phần mềm, cũng như nhiệm vụ và trách nhiệm một BA làm việc trong từng môi trường, sẽ có những thay đổi trong tên gọi của môi trường, hay trách nhiệm của người làm BA trong từng dự án, công ty khác nhau.
