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.
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ó 😎
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é.
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é 🙂
02/10/2021 at 4:09 chiều
Anh ơi anh có thể làm 1 series hướng dẫn cách viết Test case và User manual ko ạ 😁
02/10/2021 at 10:01 chiều
OK em anh sẽ note lại, nhiều bạn hỏi về 2 cái này anh sẽ viết nhé 🙂
31/10/2021 at 3:50 chiều
dạ em cũng hóng nhen anh Thịnh ơi. Mong anh Thịnh ra bài <3
07/10/2021 at 3:25 chiều
Lâu lắm mới thấy anh quay trở lại với series FS. Những chia sẽ của anh giúp người đọc có cách tiếp cận thực tế hơn khi làm tài liệu FS. Cảm ơn anh.
Mong anh ra thêm series về Business Requirement Document nhé.
17/10/2021 at 11:54 sáng
Thanks em nhé, a sẽ note ý BRD lại, nhiều bạn hỏi thì anh sẽ viết bài về BRD em nhé 😀
07/10/2021 at 4:13 chiều
Hóng anh quay lại. Chờ a từ bài học năm ngoái ạ <3. A có thể làm thêm series về cách vẽ các Diagram hay dùng như Activity diagram, Sequence diagram, Ussecase diagram, State diagram,.. không ạ. Em cảm ơn a ạ
17/10/2021 at 11:57 sáng
Thanks em, a cũng chờ được publish bài mới từ năm ngoái tới giờ :)))
Về Use Case thì anh có viết 2 bài: UC Diagram & UC Specs năm ngoái đó. Còn Activity Diagram thì anh cũng có series bài về diagram tương tự là BPMN.
Em xem lại ở đây nhé:
Use Case: https://thinhnotes.com/chuyen-nghe-ba/use-case-diagram-va-5-sai-lam-thuong-gap/
BPMN: https://thinhnotes.com/chuyen-nghe-ba/bpmn-va-su-loi-hai-cua-no/
Còn các diagram kia nếu nhiều bạn hỏi a sẽ viết về nó nhé. Thanks em 🙂
11/10/2021 at 1:57 chiều
Cám mơn anh rất nhiều nhiều nhiều ạ
17/10/2021 at 11:53 sáng
Thanks em 🙂
18/10/2021 at 12:56 sáng
Cám ơn Thịnh, bạn hệ thống rất rõ ràng về những gì bạn muốn nói.
Mình đã theo dõi và thán phục. Mình rất thích sự tìm tòi, tư duy phản biện, phong cách chuyên nghiệp và cái quan trọng nhất là tinh thần chia sẻ
Nếu được nhờ Thịnh chia sẻ kinh nghiệm cách ghi nhận Change Requirement nha, mình chưa tìm được cách ghi hiệu quả để thể hiện hợp lý các thay đổi được bổ sung sau 😀
19/10/2021 at 2:38 chiều
Thanks Phong nhé. Về CR mình cũng đang draft mấy ý, có thời gian mình lên bài nhé 😀
07/11/2021 at 9:15 chiều
Anh Thịnh ơi, ngày trước anh học MIS ở ĐH ngân hàng anh có được dạy các phần mềm như là Jira, SQL, Python, BPMN, URM ko ạ. Anh có thể liệt kê các phần mềm anh được học ở BUH ko ạ. e cảm ơn anh ạ !!!!!!
05/12/2021 at 10:44 chiều
Hồi anh học ĐH ngta không dạy phần mềm gì đâu em ơi. Phần mềm cũng chỉ là tool thôi. Quan trọng là em nắm được bản chất vấn đề, khi đó em mới xài tool được. Nên trước mắt cứ tìm hiểu gốc rễ vấn đề, rồi khi đó mới đi mò các tools support nha em. Good luck em!
07/12/2021 at 11:47 sáng
Em cảm ơn anh ạ !!!!!
08/12/2021 at 4:11 chiều
Cảm ơn anh Thịnh, em mới chỉ là một sinh viên năm nhất đi tìm hiểu về nghành BA( còn không đúng chuyên nghành học xD) nhưng lối văn của anh thực sự làm em thấy rất cuốn hút và cũng là động lực để em tiếp tục học hỏi về
16/01/2022 at 5:09 chiều
Thanks em, hi vọng blog làm e đủ hứng thú để tự đào sâu nghiên cứu thêm 😃 good luck em nhé
03/01/2022 at 1:09 chiều
Thank you anh về những bài học bổ ích trên trang, mong anh ra nhiều bài hơn về các diagram trong UML và cách quản lý us backlog
16/01/2022 at 5:06 chiều
Thanks em, topic về quản lý US trong backlog cũng hay đấy, a note lại nhé Trường 🙂
07/01/2022 at 3:48 chiều
Bạn ơi làm seri này luôn đi bạn, kiến thức chia sẻ khá rõ ràng dễ hiểu
16/01/2022 at 5:04 chiều
Nguyên serie 4 bài luôn gòi đó bạn ơi 😏
03/03/2022 at 9:59 sáng
Xin anh đọc mail hoặc rep Mess của em ạ! Em có một chút vấn đề về việc viết Use Case Diagram cần anh giúp. https://www.facebook.com/profile.php?id=100010931016018
13/03/2022 at 12:14 sáng
Anh ơi e học htttql của đh ngân hàng thì gồm 3 chuyên ngành: httt kinh doanh và chuyển đổi số, quản trị tmđt, khdl trong kinh doanh. E chưa biết phải chọn như nào, a có thể cho e lời khuyên đc hk ạ. Và nếu muốn làm BA thì chọn chuyên ngành nào vậy a
19/03/2022 at 11:44 sáng
E cứ đọc kỹ khung chương trình học của từng ngành rồi xem BẢN THÂN MÌNH hứng thú với cái nào nhé. Vì 1 là chỉ có e hiểu e thôi, nên a nghĩ sẽ ko ai đưa ra lời khuyên phù hợp hơn chính em đâu. 2 là học trong trường ĐH ở VN thì phần nhiều cũng sẽ lý thuyết, ra thực tế sẽ khác rất nhiều. Nên quan trọng mình cứ học & chuẩn bị thêm nữa các kiến thức bên ngoài & thực hành càng sớm càng tốt nhé 🙂
18/05/2022 at 3:59 chiều
dạ e cảm ơn anh
18/04/2022 at 3:59 chiều
Anh Thịnh không ra note mới đi, hóng đọc thêm các bài viết của anh !!!
19/04/2022 at 8:05 chiều
Âu keyyy em ơi, anh cũng đang draft mấy bài, chờ anh lên bài mới nhé
18/05/2022 at 7:59 sáng
Một trong những blog mà e đọc đi đọc lại vì dễ hiểu và thực tế quá anh Thịnh ơi. Mong anh lại ra bài đều.
28/05/2022 at 2:30 chiều
Thanks em nhé
26/05/2022 at 8:53 sáng
Anh ơi, cái slide ví dụ về viết fs trong agile bị lỗi, anh sửa lại đi anh. Em xem được 1 slide đầu, mấy slide sau không click được ạ.
26/05/2022 at 8:56 sáng
À oke cái slide Fs của agile chỉ có 1 trang ạ
07/06/2022 at 11:58 chiều
Em có một chút thắc mắc muốn hỏi:
Trong phần 3.1. BPMN – Thì mình vẽ BPMN các Công việc của dự án (VD: Thu thập yêu cầu, phân tích, thiết kế,…) hay Quy trình nghiệp vụ của sản phẩm (VD: Đăng nhập, Chọn hàng, Vào giỏ hàng, Thanh toán…) nhỉ?
Nếu là của Quy trình nghiệp vụ thì ở bảng mô tả, mỗi step có Người chịu trách nhiệm mình viết thế nào? Ví dụ như step Đăng nhập thì mình viết PIC có phải là:
– Cung cấp yêu cầu các loại TK: Ông A
– Mô tả yêu cầu: Ông B
– Vẽ giao diện: Ông C
– Dev: Ông D
Phần này em hơi confused vì nếu viết PIC như vậy thì đa số mọi step đều giống nhau rồi?
Ở phần Use Case thì Use Case Specification có chứa Business Rules của từng Use Case rồi. Vậy mình có cần tách ra thành một phần riêng như 3.3. không anh nhỉ?
Rất cảm ơn những thông tin hữu ích mà anh chia sẻ ạ!
30/08/2022 at 4:00 chiều
Anh có dạy BA không anh em muốn đăng ký học từ anh
Mong anh rep ạ
23/10/2022 at 4:29 chiều
Hiện tại thì chưa Kiên nhé, có gì không rõ em có thể ping facebook hoặc email anh để hỏi nhé
20/10/2022 at 12:58 sáng
Em chào anh!
Em thấy cách anh mô tả user story và usecase khá giống nhau. Vậy thì liệu trong cách viết FS kiểu Agile này thì User story có tương tự như Use case không ạ? Nhưng anh cũng có nói Acceptance Criteria nó tương tự Use case vs Business rule thì em đang hơi bị rối đoạn này ạ. Mong được anh giải đáp.
Em cám ơn anh nhiều.
23/10/2022 at 4:34 chiều
Hi Kiều, cả 2 cách (User Story hay Use Case) em đều có thể có được nhanh những gạch đầu dòng về “những thứ bắt buộc phải có” đối với mỗi phương pháp.
Thì khi đó em sẽ nhìn nhận rõ 2 cái khác nhau chỗ nào chứ cũng không hẳn tương tự đâu.
Tổng quan thì User Story nó tiếp cận vấn đề nhanh, trực quan hơn dựa theo góc nhìn của user. Còn Use Case thì nó đi sâu vào từng ngõ ngách các trường hợp sử dụng (các steps) mà user có thể làm, có thể tương tác với hệ thống.
Mỗi cách đều có đặc điểm & mục đích sử dụng tùy vào từng tình huống project khác nhau. Nhưng đã mô tả hệ thống thì những thứ như “Acceptance Criteria” hay “Business Rule” đều là như nhau, đều cần phải rõ ràng, minh bạch, testable, và được đo lường cụ thể. Nên maybe em thấy confuse đoạn này ở cả 2 phương pháp.
Nhưng sau cùng vẫn là mục đích mình muốn mô tả như thế nào, với mục đích gì, thì sẽ chọn được phương pháp phù hợp nhé em.
09/11/2022 at 12:45 sáng
Blog hay và hữu ích lắm ạ, anh viết thêm đi vì cách hành văn của anh cũng vui nữa =))) e chưa bao giờ thấy code thú vị đến vầy
18/02/2023 at 10:50 sáng
Anh đâu viết về code đâu em :))
04/12/2022 at 9:58 chiều
Anh ơi, e thấy có rất nhiều khái niệm được đưa ra như: use case, user story, BPMN,… nhưng vẫn mông lung chưa hình dung tổng thể được là n được nhét vào trong phần nào, nằm ở đâu trong FS. A có thể chia sẻ thêm giúp e phần này được k ạ :((
18/02/2023 at 10:50 sáng
Anh có cái hình demo ở trên đó, em kéo lên xem lại nhé
03/07/2023 at 11:37 sáng
Bên em đang viết tài liệu qua từng version của dự án, mỗi ver sẽ phát triển tính năng mới hoặc làm lại luồng nếu như có yêu cầu của KH. Hiện nay tài liệu mỗi ver em chỉ viết thể hiện: Activity -> UI Design -> UI Description -> User Story -> AC. Theo anh thì có cần bổ sung BPMN không hoặc cần thêm nội dung gì nữa không ạ? Em cảm ơn ạ
02/01/2024 at 8:45 sáng
Mong anh sẽ ra thêm blog nói về nhiều model khác như DFD, Sequence,…
25/02/2024 at 11:26 sáng
Anh Thịnh ơi, em có được học về Function list/ Screen list, site map. Anh có bài viết nói chi tiết về phần này không ạ, em có search trên gg trước đó nhưng thông tin cũng khá mông lung ạ.
17/04/2024 at 11:17 sáng
Tool anh dùng để vẽ ảnh là gì vậy ạ
21/04/2024 at 11:34 sáng
do máy a có sẵn photoshop nên a dùng nó để vẽ luôn
19/06/2024 at 9:57 sáng
Hay quá anh!