Những bước BA thường làm trong dự án

Bước 1: Đánh giá nhu cầu và hiện trạng

Tìm hiểu nhu cầu (Needs) và phân tích hiện trạng (AS-IS) là bước đầu tiên khởi nguồn cho mọi thứ trước khi bắt đầu việc khơi gợi và phân tích yêu cầu của khách hàng. Công việc này thường được thực hiện khi bắt đầu dự án, nó sẽ giúp chúng ta trả lời được câu hỏi “Tại sao cần phải thay đổi”, hiểu được mục đích của dự án, phạm vi áp dụng và các stakeholder chính liên quan đến dự án. Chúng ta không thể lao vào làm khi không biết dự án bắt đầu từ đâu và mục đích là gì, điều này sẽ dẫn đến nhiều hệ lụy sau này như:

• Tại sao hệ thống mới lại không có chức năng như hệ thống cũ?
• Sao hệ thống mới không có trường dữ liệu này?
• Sao hệ thống mới lại không tốt như hệ thống cũ?

Các kỹ thuật cần làm cho giai đoạn phân tích hiện trạng:

• Hiểu mục đích, phạm vi dự án (Objective, Scope)
• Đánh giá hệ thống hiện tại (Current Systems)
• Đánh giá quy trình hiện tại (Business Process)
• Đánh giá các quy định luật lệ trong doanh nghiệp (Business Rules)
• Đánh giá dữ liệu (Business Data)
• Hiểu thuật ngữ chuyên ngành (Glossary)

Bước 2: Lập kế hoạch công việc BA và cách tiếp cận

Ở bước này chúng ta sẽ lựa chọn quy trình cho bản thân công việc của BA cũng như cho cả dự án. Trước khi đi vào chi tiết thì BA phải lập kế hoạch để viết ra những đầu việc chính và thứ tự ưu tiên. 

BA Plan cần chú ý những điều sau:

• BA Resource Plan (Nguồn lực BA)
• BA Deliverables (Những tài liệu và thành phẩm mà BA phải làm trong dự án)
• Software Methodologies (Việc triển khai dự án theo mô hình Agile / Scrum hay Waterfall sẽ có những đầu việc và thứ tự khác nhau cho BA)
• Scope of Work (Phạm vi dự án, thường sẽ chia ra Modules)
• Estimation (Dự toán – sau khi đã có đầu việc chính của BA, thường là các đầu việc như: Run workshops, Wireframes, Documentation…)

Trong cuốn sách “A Guide to the Business Analysis Body of Knowledge” (BABOK) có đề cập tới 2 phương pháp tiếp cận là “Predictive” và “Adaptive”, thực tế chính là “Waterfall” và “Agile”. Mặc dù hiện nay hầu hết các công ty sử dụng phương thức “Agile” nhưng trước khi lựa chọn giữa 2 phương thức này nên cân nhắc một số điều như:

• Độ formal: là cấp độ chi tiết, quy chuẩn về tài liệu output mà BA phải đưa ra. Nếu khi dự án cầu tài liệu phải đầy đủ, ký duyệt cẩn thận trước khi thực hiện là đó là theo Waterfall.
• Hoạt động thu thập và phân tích nghiệp vụ: Nếu quá trình thu thập và phân tích nghiệp vụ được triển khai thành nhiều giai đoạn và mỗi giai đoạn chỉ cần cung cấp một lượng thông tin nhất định thì Agile sẽ tốt hơn. Nhưng các thông tin cần được khai thác toàn bộ, tổng hợp và tài liệu hóa rồi đem ký thì Waterfall sẽ phù hợp hơn.
• Độ phức tạp và rủi ro: Đối với những dự án có độ phức tạp và độ ảnh hưởng lớn, cũng như chứa nhiều rủi ro, thường những dự án có rủi ro lớn trong bước implement thì cần làm tài liệu thật kỹ từ trước, và lúc đó thì có lẽ nên dùng Waterfall.

Bước 3: Xác định và làm việc với các bên liên quan

Các stakeholder làm một trong những yếu tố tác động nhiều đến sự thành công của BA trong dự án. Vì vậy xác định và đánh giá kỹ lưỡng về các bên liên quan là rất cần thiết. Có những stakeholder chỉ gặp một vài lần, nhưng có stakeholder ngày nào cũng gặp. Ở bước này, BA nên chuẩn bị cách thức tiếp cận cũng như là giữ mối quan hệ với các stakeholder.

Khi lên kế hoạch làm việc với stakeholder, cần chú ý những thứ sau:

• Danh sách các stakeholder: liệt kê danh sách các stakeholder có liên quan đến dự án.
  • Sponsor (Chủ chi)
  • Implementation Subject Matter Experts (SME)
  • Tester (Kiểm thử)
  • Project Manager/ Scrum Master
  • Operational Support (Business As Usual)
  • Customers
  • End Users (Người dùng cuối)
  • Domain SME (Chuyên gia nghiệp cụ)
  • Vendors, Suppliers (Nhà cung cấp)
  • Regulator
• Cách tiếp cận và triển khai
  • Dự án thực hiện theo kiểu Waterfall hay Agile ảnh hưởng khá nhiều đến cách làm việc với stakeholder. Ví dụ theo kiểu Waterfall thì gần như ta chỉ đi gặp mỗi stakeholder 1 lần, khai thác toàn bộ các thông tin cần thiết và rất ít khi contact lại để khai thác thêm thông tin. Còn đối với kiểu Agile thì ta sẽ cân nhắc theo từng giai đoạn mình cần những thông tin gì, khai thác từ những stakeholder nào và triển khai theo từng giai đoạn đó.
  • Sau khi gặp và biết về các stakeholder, bước tiếp là gặp gỡ và nói chuyện để tìm ra những yêu cầu (business/ stakeholder requirements) có thể khơi gợi bằng nhiều cách như Meeting, Data Analysis, Prototyping, Observation Benchmarking, Mind Mapping, Survey, Document Analysis, nhưng thường sẽ tổ chức một buổi workshop để thuyết trình với sự tham gia của stakeholders để cùng nhau đưa ra ý tường, yêu cầu và cũng như chốt xem cần phải xây dựng cái gì cho phần mềm..

Bước 4: Viết Meeting of Minutes để chốt lại yêu cầu

Sau buổi workshop hoàn thành thì BA cần phải có Meeting of Minutes (MoM) để chốt lại những gì đã thảo luận và làm tiền đề tiếp tục các bước phân tích, thiết kế và viết tài liệu. Việc viết MoM sẽ giúp rất nhiều sau này như:

• Tránh hiểu sai và nhầm lẫn: Trong workshop mọi người sẽ bàn bạc và thảo luận rất nhiều nên rất dễ sẽ bị quên những gì đã nói. MoM như một bản chốt các ý kiến của stakeholder.
• Giúp stakeholder vắng mặt cũng có thể nắm bắt được thông tin.
• Dựa trên MoM để đưa ra những actions tiếp theo cần phải làm, giúp công việc được giải quyết, xử lý kịp thời và liên tục.

Bước 5: Phân tích và mô hình hóa yêu cầu

Sau khi BA lấy được thông tin từ các stakeholder, nhưng những thông tin là 1 mớ hỗn độn chưa được sắp xếp, phân loại gọn gàng. Ở giai đoạn phân tích này, BA sẽ sắp xếp và phân loại các yêu cầu, sau đó phân rã các yêu cầu và sắp độ ưu tiên cho yêu cầu. 

Lúc này các yêu cầu ở dạng note về các yêu cầu sẽ rất khó hình dung thì BA cần phải chuyển hóa những ghi chú đó bằng cách mô hình hóa như hình ảnh, biểu đồ (BPMN, UML,…) sẽ giúp:

• Thống kê lại dễ phát hiện những yêu cầu bị thiếu hoặc không đủ hoặc không logic trong câu từ).
• Dùng hình ảnh sẽ dễ hình dung và biểu đạt cho stakeholders hơn rất nhiều.

Những kỹ thuật thường dùng trong giai đoạn này:

• Scope Analysis & Modeling
• Process Analysis & Modeling
• Data Analysis & Modeling
• Rule Analysis & Modeling
• Interface Analysis & Modeling

Bước 6: Sử dụng SQL để truy vấn và phân tích dữ liệu

SQL (Structured Query Language) là ngôn ngữ để truy vấn dữ liệu từ Cơ Sở Dữ Liệu (CSDL – Database). Chi tiết hơn thì nó dùng để truy vấn data từ những Relational Database (Cơ sở dữ liệu quan hệ). BA nào cũng nên biết SQL để biết cách truy vấn để giúp cho việc phân tích dữ liệu.

Bước 7: Xây dựng mô hình dữ liệu và đặc tả dữ liệu

Sau khi đã hiểu được mối quan hệ dữ liệu và đặc tả dữ liệu của hệ thống cũ thì mình tiếp tục xây dựng lại Conceptual Data Model (Mô hình dữ liệu dạng khái niệm) và Data Dictionary cho hệ thống mới

Để làm tốt được bước này bạn phải biết cách phân biệt được giữa Business Data vs. Technical Data. Business Data xuất phát từ yêu cầu (requirements) còn Technical Data được sinh ra trong quá trình thiết kế về mặt hệ thống.

Bước này cực kỳ quan trong để chuẩn bị vẽ wireframes nhé. Vì bạn phải biết Customers phải có trường dữ liệu nào để thiết kế lên trên UI (User Interface – màn hình) cho phù hợp.

Bước 8: Vẽ wireframes và prototypes

Wireframe là bước quan trọng nhất, vì nó chính xác là bộ khung của UI. Không cần quan tâm đến màu sắc, font chữ, to nhỏ, hiệu ứng thế nào. Mặc dù không quá chi tiết nhưng nó thể hiện rõ được luồng thao tác của người dùng và cấu trúc các nhóm thông tin có trên UI đó. Một trong những công cụ tốt nhất để vẽ Wireframe là Balsamiq. Trực quan, dễ học, dễ xài, tính năng đơn giản, thao tác nhanh gọn.

Prototype là “mẫu thử đầu tiên” của phần mềm/ hoặc một chức năng của phần mềm, và người dùng có thể tương tác được ngay trên màn hình của chức năng/ phần mềm đó. Thường Prototype được làm trong giai đoạn pitching dự án. Hoặc cũng có thể làm để làm rõ requirement với khách hàng. Thường áp dụng cho những requirement phức tạp, cần thể hiện một cách trực quan.

Để vẽ được Wireframe và Prototype, BA cần có: Tư duy về UI, UX và kỹ năng sử dụng tool (Một số tool phổ biến: Balsamiq, Axure, FIGMA…)

Bước 9: Trình bày bản wireframe hoặc prototype để kiểm tra yêu cầu

Khi BA vẽ xong các wireframe hoặc prototype, sẽ cần trình bày demo với khách hàng để kiểm tra xem có đúng với yêu cầu (requirement) của khách hàng hay không. Sau đó điều chỉnh và tạm chốt bản wireframe hoặc prototype.

Bước 10: Viết tài liệu thông qua SRS, Use Case hoặc User Stories

Tiếp theo BA sẽ chuẩn bị viết tài liệu đặc tả yêu cầu. Có rất nhiều tài liệu mà BA có thể viết và tùy vào dự án và mô hình chạy dự án (Software Methodologies):

• Đối với Waterfall: Thường BA sẽ viết Use Case và SRS (Software Requirement Specification). UC như là một bản hướng dẫn cho team dev tập trung vào việc tạo ra các sản phẩm mang tính tập trung vào người dùng là chính và cũng giúp các bên liên quan không bị hiểu sai về thiết kế sản phẩm. SRS bao gồm các yêu cầu chức năng (The Functional Requirements, dùng để minh họa hành vi người dùng) và Phi chức năng (Non-Functional Requirements – miêu tả đặc điểm) cùng tất cả trường hợp khác mà phần mềm cần đáp ứng. Dựa vào các yêu cầu phần mềm được ghi nhận rõ ràng trong SRS cũng giúp ước tính chi phí và thời gian cần có để hoàn thiện hệ thống. Đây cũng là cơ sở để tạo lập hợp đồng giữa các bên.
• Đối với Agile Scrum: ngày nay hầu hết dự án theo mô hình Agile / Scrum và công việc viết tài liệu của BA không còn vất vả như Waterfall. Thường BA sẽ viết các User Story. User story thường được viết ngắn gọn trên Card, giấy note, tài liệu Words, Excels… tùy dự án. Ngoài ra, có thể quản lý chuyên nghiệp hơn thông qua phần mềm quản lý dự án như Jira, Trello,… 

Bước 11: Trình bày phần mềm đã xây dựng 1 phần

Ở bước này, BA sẽ demo với khách hàng trên hệ thống thật đã có một ít dữ liệu.

Đối với bước này thì cần luôn demo mỗi 2 – 4 tuần 1 lần hoặc khi xong 1 chức năng quan trọng nào đấy và luôn có MoM (Meeting of Minutes) để chốt lại sau buổi demo:

• Review lại với toàn team xem có nó hoạt động có đúng ý mình không? (Từ thiết kế đến triển khai có rất nhiều khoảng cách bạn nhé)
• Khách hàng có feedback gì để còn kịp thay đổi tránh về sau thay đổi thì sửa lại rất khó khăn và nhiều rủi ro

Bước 12: Hỗ trợ kiểm thử tích hợp phần mềm 

Kiểm thử tích hợp – Integration testing là bước rất quan trọng trong quá trình kiểm thử. Muốn phần mềm được đảm bảo chất lượng, hệ thống được vận hành theo đúng mong muốn người dùng thì kiểm thử tích hợp là không thể thiếu.

Khi đến giai đoạn System Integration Testing (SIT) thì công việc chính của BA là hỗ trợ đội ngũ Testing về việc tư vấn và trả lời các câu hỏi liên quan đến tích hợp xem dữ liệu và tính huống đã đúng theo yêu cầu hay chưa. Và trong lúc SIT sẽ có rất nhiều trường hợp hy hữu mà Tester họ nghĩ ra (Edge Cases) mà BA phải trả lời xem có cần test hay không?

Bước 13: Đào tạo người dùng

Bước tiếp theo sau khi hệ thống đã được tích hợp thành công là có thể chuẩn bị đưa vào sử dụng và cho phép người dùng trải nghiệm thực tế để kiểm tra, làm quen các tính năng. Lúc nào cần có những buổi để đào tạo cho Key/End Users, gồm 4 bước chính như UAT Briefing, UAT Training, UAT Testing, UAT Closure. Nên để người dùng test theo guồng từ đầu tới cuối (end-to-end flow) để dễ dàng nắm bắt sau đó chọn ra những trường hợp rẽ nhánh (alternative) hoăc trường hợp ngoại lệ (exceptions) để thêm vào.

Bước 14: Hỗ trợ UAT

Đây là bước thứ 3 trong UAT Testing, BA sẽ hỗ trợ người dùng hiểu và sử dụng hệ thống. Trong giai đoạn UAT này, end-users mới thật sự được sờ và trải nghiệm trực tiếp có thể khác với họ tưởng tượng nên có thể sẽ phát sinh ra rất nhiều bugs & requirement mới và BA lại có thể phải làm ra 1 danh sách chức năng mới cần làm trước khi Go-live.

Bước 15: Data Migration

Data Migration (Chuyển đổi dữ liệu) là quá trình di chuyển dữ liệu giữa các hệ thống lưu trữ dữ liệu, các định dạng dữ liệu hay giữa các hệ thống máy tính. Vậy nên, nếu khách hàng đã có hệ thống trước đó rồi và đã vận hành với dữ liệu có sẵn thì khi xây dựng hệ thống mới dữ liệu bắt buộc phải đưa sang hệ thống mới. Nếu không có bước này thì không thể nào Go-live được. 

Bước 16: Go-Live

Có thể nói khi làm phần mềm, Go-live là thời điểm mà quá trình triển khai phần mềm đã được hoàn tất và phần mềm được di chuyển từ thử sang ứng dụng được mong đợi nhất sau khoảng thời gian dài cả team họp hành làm việc cật lực. Sau khi hoàn thành UAT và Data Migration thành công thì chỉ cần thông báo Go-Live và bàn giao hệ thống cho đội BAU của khách hàng là xong. Và thường sau khi Go-Live sẽ có 1 giai đoạn gọi là Hypercare (tầm 2 tuần đến vài tháng) để tập trung sửa bug nếu có trong quá trình vận hành hệ thống trong vài tháng đầu đến khi nó thật sự đã vào guồng ổn định.

Sau cùng, để tổng kết và tóm tắt lại nội dung của bài viết, hãy cùng BAC điểm lại 16 bước BA thường làm trong dự án qua sơ đồ sau nhé:

Mong rằng bài viết này đã mang đến cho bạn đọc những thông tin hữu ích. Để không bỏ lỡ các kiến thức mới đừng quên đón xem các bài viết mới nhất tại BAC’s Blog.

Nhu cầu đào tạo doanh nghiệp