Queo khom anh em tới với bài cuối cùng – trong chuỗi series bài viết về FS 😎

Mình nghĩ sau khi đọc xong 3 bài trước, tâm lý anh em đang rất “bối rối” đúng hông. Vì FS có quá nhiều phần, mà mình lại chưa hình dung rõ các phần đó xuất hiện như thế nào trong FS. Nên bài này mình sẽ giúp anh em hệ thống lại toàn bộ nhé.

Thật ra có nhiều bạn xin mình template để viết FS. Nhưng thú thật là mình không thể share template được.

Không phải vì mình ngại lộ thông tin dự án, mà đơn giản vì nếu làm vậy sẽ không tốt cho anh em. Thật sự không có ích cho anh em chút nào hết.

ba-viet-fs-thinhnotes

Vì sao?

Vì nếu mình đưa cho anh em template, vô hình chung anh em sẽ rơi vào cái bẫy tâm lý “dọn sẵn”. Tức có dự án là anh em sẽ lấy ngay template ra để fill thông tin vào. Template có gì là fill ngay vào, mà không có chút mảy may suy nghĩ gì về nó.

Như mình đã nói thì dự án có trăm kiểu dự án, BA có trăm kiểu BA, thì FS cũng có cả trăm trăm kiểu FS. Không dự án nào giống dự án nào. Nên anh em cần giữ được cái sense – cái nhạy bén của người làm công việc Business Analyst khi tiếp cận dự án.

Lấy template ra xài là coi như lấy dao chém bặt cái “sense” đó của chính mình rồi.

Mình cần tiếp cận vấn đề theo hướng:

  • Dự án này làm gì, có gì, và giờ cần gì?
  • Stakeholder có những ai, vai trò họ là gì?
  • Họ quan tâm những gì, thì chỉ cần focus vào những thứ đó thôi >> rồi cứ thế mà triển.

Mình không cần phải nhét cả đống thứ, mà ngay cả bản thân mình cũng không hiểu nó là gì vào FS. Mục tiêu sau cùng vẫn là deliver được giải pháp phần mềm. Từ đó giúp business vận hành. Chứ mục tiêu của BA không phải deliver 1 sấp A4 đủ các mục a bờ cờ như văn mẫu.

Nếu đã quen theo lối mòn dùng template, mà không tự tư duy sáng tạo khi viết FS. Thì càng về sau, anh em sẽ trở thành “thợ viết” chứ không phải là “BA viết FS” nữa.

Dĩ nhiên dùng template cũng có cái lợi. Nhưng chỉ dùng khi anh em thật sự hiểu rõ tường tận các mục trong template đó. Giống như thượng phương bảo kiếm chỉ lợi hại thật sự khi mình nắm vững công năng của nó 😎

viet_fs_thinhnotes

Còn không nắm rõ bản chất và cách dùng, thì có cầm trong tay máy đào Bitcoin súp pơ xịn cỡ nào đi nữa, thì cũng không được đồng nào.

“Vậy người mới nên bắt đầu từ đâu?”

Mình tin chuỗi bài notes về FS này ít nhiều sẽ giúp ích được anh em khi mới bắt đầu. Những thứ mình viết ở đây, anh em đừng xem nó là template để copy exactly 100%. Hãy xem nó như từng món “vũ khí” mình giới thiệu ra cho anh em.

Cứ xem chậm rãi (kiểu như đi shopping), xuy sét kỹ càng, và thử tư duy phản biện lại những cái mình viết, xem nó có thật sự phù hợp với dự án mình đang làm hay không.

Rồi từ đó, cóp nhặt ra những món vũ khí phù hợp với mình nhất để đi chiến.

Ô kê chốt zậy nha anh em!

Mấy món này mình đã note ở 3 bài trước. Nằm trong cả 2 mục: FS kiểu truyền thống & FS kiểu Agile. Bài này mình đóng gói lại toàn bộ cho anh em dễ hình dung nhé.

ba-viet-fs-thinhnotes

FS KIỂU TRUYỀN THỐNG

Khi gộp các phần lại, anh em sắp xếp nó như sau:

1. Overview

2. User Requirement

Kẻ bảng ghi từng UR cụ thể. Và đánh ID cho từng UR này.

3. Functional Requirement

3.1. BPMN

Anh em có thể để 1 sơ đồ BPMN high-level nhất cho toàn bộ quy trình nghiệp vụ ở đây. Rồi xuống từng Use Case cụ thể sẽ có từng BPMN riêng nếu cần.

3.2. Use Case

Chủ yếu chỉ cần Use Case Specification. Nếu Use Case nào phức tạp thì vẽ thêm Use Case Diagram để dễ hình dung nhé.

3.3. Business Rules

Vẽ 1 cái bảng, liệt kê toàn bộ Business Rules có trong Use Case. Nhớ đánh số ID cho từng Business Rule nhé.

3.4. Wireframe

Anh em cũng vẽ 1 cái bảng. Rồi bỏ vào đây các màn hình wireframe (chỉ cần low-fidelity) kèm mô tả sơ cho màn hình đó. Và nhớ có 1 cái bảng mô tả các component có trong wireframe này nhé anh em.

3.5. ERD

Phần này optional. Anh em có thể cân nhắc để nó trong Supporting Information nếu là ERD cho toàn bộ hệ thống (thường là dự án mới). Hoặc nếu ERD theo từng phân hệ thì bỏ vào từng mục Use Case tương ứng.

4. Non-Functional Requirement

Chia ra từng nhóm NFR. Trong mỗi nhóm NFR, anh em cũng vẽ 1 cái bảng, liệt kê toàn bộ các requirement chi tiết thuộc nhóm NFR đó nhé.

5. Transition Requirement

Phần này nếu có thì anh em cứ mô tả y hệt như Functional Requirement là được. Tức cũng bao gồm: BPMN, Use Case, Business Rule, & Wireframe.

Còn nếu dự án không có transition requirement gì đặc biệt thì anh em cứ mạnh dạn bỏ phần này ra khỏi document nhé.

6. Supporting Information

Cuối cùng là tả bí lù các supporting document cần tham khảo. Lưu ý chỉ nên để cái gì thật sự hữu ích nhé anh em. Nên cân nhắc kỹ.

Dưới đây là tổng quan các phần sẽ có trong FS kiểu truyền thống

FS KIỂU AGILE

1. User Story

User Story thì có format sẵn nên anh em cứ follow theo nhé. Cái nào không cần viết theo format thì cứ viết theo ngôn ngữ tự nhiên như mình có note ở bài trước.

Nói về cách tổ chức thì ngay từ đầu anh em phải phân chia được hệ thống có những nhóm tính năng lớn nào. Gom nó lại thành các EPICs. Dưới EPIC sẽ có các User Story. Từ User Story, mình sẽ break thành các Task đủ nhỏ để “doable”.

Các Epic, User Story hay Task thì nó thuộc về phạm vi “project management”. Sẽ có các công cụ riêng để handle việc này như Jira hay Trello.

Còn nói về tài liệu FS của BA thì có bao nhiêu User Story anh em cứ gom vào trong Backlog. Backlog có thể là 1 trang “Backlog” trên tài liệu FS của mình. Hoặc là dùng Backlog của JIRA, Trello.

Nhưng chỉ khi chốt được các User Story cần làm trong Sprint đó, thì mình mới cần mô tả chi tiết cho từng User Story nhé. Như: Acceptance Criteria, BPMN, hay Wireframe. Nôm na mình chỉ cần làm FS cho từng User Story có trong Sprint Backlog thôi nhé anh em.

2. Acceptance Criteria

Với mỗi User Story thì anh em chỉ việc kẻ 1 cái bảng. Rồi list ra toàn bộ các item Acceptance Criteria và nhớ đánh số ID cho nó nhé.

3. BPMN

Một vài User Story lớn hoặc phức tạp thì có thể anh em sẽ cần minh họa BPMN trong này. Nhưng đa phần các User Story đều đã được break ra thành từng tính năng cụ thể. Nên thường anh em cũng không cần mô BPMN cho từng US cụ thể đâu.

Nhưng nếu cần mô tả BPMN cho toàn bộ quy trình lớn thì mình vẫn khuyến khích anh em nên làm. Dù gì có cái nhìn tổng quan từ đầu vẫn là tốt nhất.

4. Wireframe

Cũng như FS truyền thống thì anh em chỉ cần vẽ 1 cái bảng mô tả Wireframe, kèm mô tả các component có trong đó nhé.

Dưới đây là tổng quan các phần sẽ có trong FS kiểu Agile

TẠM KẾT

Nhìn chung cách BA thể hiện trên tài liệu là rất rộng mở và linh hoạt. Nên đừng quá gò bó vào các format hay template sẵn có anh em nhé.

Đều dựa trên quy chuẩn chung, nhưng tùy vào tính cách, năng lực & thái độ mà mỗi người làm BA sẽ có một cách thể hiện FS khác nhau.

Nếu chuỗi bài về FS này quá nhiều thứ để nhớ, thì mình nghĩ anh em chỉ cần nhớ một thứ duy nhất. Đó là mục đích sau cùng của FS. Làm sao làm, miễn FS phải: dễ đọc, dễ hiểu và team có thể thực thi được dựa trên FS này.

Vì sau cùng, cái mình deliver không phải là tài liệu, mà là deliver được tính năng cần thiết và giúp business vận hành.

Hi vọng những gì mình tóm lược ở bài này đủ cô đọng cho anh em về FS. Hẹn gặp anh em ở các bài sau nhé 🙂