[16 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 khaiDự á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.

-------

Nguồn: BAC Blog