VIẾT FS KIỂU TRUYỀN THỐNG

1. Overview

Overview là mô tả súc tích & ngắn gọn về: Purpose, Business Objectives, và Scope. Cụ thể:

• Purpose: nôm na FS này mô tả cái gì, dành cho ai đọc?
• Business Objectives: mô tả background & context mà dự án này ra đời nhé
• Scope thì thường sẽ đi theo:
  • Organization Scope: giải pháp này áp dụng ở Business Unit nào, hay áp dụng cho toàn tổ chức?
  • User Scope: giải pháp này dành cho toàn bộ đối tượng nhân viên, hay chỉ áp dụng cho một vài bộ phận nào đó?
  • Functional Scope: giải pháp này bao gồm những Use Case nào (chỉ việc gom nhóm lại , chứ không cần detail ở đây)
  • Integration Scope: list ra những integration point với các system khác.
  • Out of scope: note rõ những thứ mà giải pháp này không làm và không cover trong tài liệu FS này.

Ngoài ra, phần này có thể đặt các Assumption (các giả định) & Dependencies (các yếu tố phụ thuộc) vào để làm rõ các khía cạnh của giải pháp.

2. User Requirement

Cụ thể nó sẽ là Business Requirement & Stakeholder Requirement. Chỉ việc kẻ 1 cái bảng, list những item UR và mô tả chi tiết của từng item đó.

Đây là điểm nên làm kỹ. Vì việc mình có gãi có đúng chỗ ngứa của business hay không, là nằm ở đây.

Nên phần này (một lần nữa) phải cực kỳ súc tích và cô đọng nhé . Không ghi thì thôi, nhưng đã ghi thì phải đúng, và vừa đủ từng chữ một. Không thừa, mà cũng không thiếu.

Để có nội dung viết vào đây thì rõ ràng phải thật sự hiểu pain-points của khách hàng.

Và để hiểu được các pain-points này, thì cần phải có trải nghiệm. Và đã phải làm đủ các nghiệp vụ khảo sát & phân tích trước đó thì mới có thể ghi được đúng và đủ vào trong này được.

3. Functional Requirement

Đây sẽ là nội dung chính cho cả FS. Nên cần đầu tư nhiều vào phần này khi viết.

Mỗi công ty, mỗi dự án sẽ có một kiểu mô tả khác nhau. Nhưng nhìn chung mình thấy kiểu phổ biến, hiệu quả và khoa học nhất thường sẽ bao gồm các items sau:

1. BPMN
2. Use Case
3. Business Rules
4. Wireframe

Tuy nhiên để cho dễ hình dung thì mình sẽ tiếp cận theo hướng: 1. ĐỂ LÀM GÌ? và 2. RÁP CÁI “ĐỂ LÀM GÌ” ĐÓ LẠI. Mục đích là để hiểu được bản chất vấn đề. Và từ đó lần lên được hình ảnh tổng thể của một bức tranh FS.

3.1. BPMN

Đầu tiên là BPMN: cho người đọc 1 cái nhìn tổng quát từ trên xuống.

Một yếu tố tâm lý rất quan trọng mà cần khai thác, đó là: chúng ta rất sợ bị lạc.

“Lạc” nghĩa là không định vị được mình đang ở đâu. Trước mình là gì, sau mình là gì. Mình nhích tiếp 1 bước nữa sẽ gặp gì, lùi lại 1 bước nữa sẽ gặp gì? Và khi đó, quan trọng hơn hết là mình không-thấy-đường đi đến điểm cần đến.

Việc thể hiện ý tưởng cũng vậy. VIẾT tài liệu là 1 cách thể hiện ý tưởng dễ khiến người đọc bị rối nhất.

Trong 1 mớ tài liệu cả trăm trang, nếu không có chỉ dẫn rõ ràng cho người đọc: cần đọc từ đâu, chỗ này nói gì, chỗ kia nói gì, sau đó là gì, trước đó là gì, hay đọc hết cái này để làm gì? Thì vô hình dung anh em đã làm cho người đọc LẠC trong mớ tài liệu của mình rồi.

CÁCH KHẮC PHỤC? => chính là BPMN.

Vẽ tổng quát quy trình của hệ thống/ sản phẩm đang làm. Có thể là end-to-end process. Hoặc tách nhỏ ra thành vài process theo các phân hệ chính yếu.

“Tuyến đường dây” của FS có rõ hay không, phụ thuộc nhiều vào cách nhìn của người làm tài liệu, và phân tách quy trình ra sao cho hợp lý.

Lưu ý là CÓ VẼ, thì nhớ PHẢI MÔ TẢ cái mình vẽ. Mô tả như thế nào?

Anh em cứ việc làm 1 cái bảng gồm các cột: ID, Steps, PIC, Description. Và nhớ các task trên BPMN PHẢI ĐÁNH SỐ ID nhé anh em.

Mỗi task này làm gì, làm bởi ai, mô tả chi tiết hay có note gì lưu ý không, anh em cứ gom hết vô cái bảng đặc tả BPMN này. Nhớ, ngắn gọn và súc tích nhé .

3.2. Use Case

Nếu BPMN là khung xương nối các phần của FS, thì Use Case chính là mô tả chi tiết các phần đó.

Bây giờ để hình dung rõ mục đích chính của Use Case, mn thử giúp mình mô tả cách nấu 1 tô canh gà lá giang thử xem 

Với Use Case, sẽ thể hiện rõ được:

• Các công đoạn nấu canh gà lá giang: làm gà, làm lá giang, nấu canh gà (break ra thành 3 use cases nhỏ)
• Với mỗi công đoạn này, cần làm các bước gì, theo thứ tự gì (Main Flows)
• Với mỗi công đoạn này, có cách nào khác để làm không, nếu mình không có đủ dụng cụ để làm theo cách chính (Alternative Flows)
• Hay nên lưu ý điều gì để bước này không bị fail (Exceptional Flows)
• Gà để nấu món này thì yêu cầu như thế nào, hay lá giang trước khi nấu có cần vo nhẹ, hoặc làm gì không (pre-conditions)
• Nồi canh gà lá giang nấu ra màu sắc, mùi vị như thế nào là chuẩn (post-conditions)
• Và còn nhiều thông tin quan trọng khác mà anh em có thể khai thác được dựa trên Use Case.

Quay lại với FS của mình, sẽ rất rối và đặc biệt là rất dễ để viết thừa thứ không cần và viết thiếu thứ phải có, nếu anh em mô tả một tính năng nào đó theo bản năng mà không có phương pháp.

Do đó, nên dùng Use Case triệt để để tối ưu FS.

3.3. Business Rule

Nếu Use Case giúp mô tả chi tiết từng phần trong FS, thì Business Rules góp phần làm sáng tỏ nội dung được mô tả trong Use Case.

• Business là nghiệp vụ
• Rules là những quy định được đưa ra

Business Rules nôm na là những quy định liên quan tới mặt nghiệp vụ mà hệ thống phải-tuân-theo.

Business Rules có thể là những quy định được đưa ra bởi các stakeholder. Như yêu cầu về mặt Legal/ Compliance, về Marketing, hay về định hướng phát triển sản phẩm…, mà hệ thống phải đảm bảo.

Rộng ra hơn một chút. Business Rules còn có thể là những thứ được đưa ra bởi team dự án, mà PIC chính là BA. Vì sao? Vì không ai hiểu rõ hệ thống hơn BA, hay rộng hơn là team dự án.

Nắm được Requirement từ phía Business, kết hợp với những gì mình biết ở hệ thống hiện tại, hoàn toàn có thể đề xuất ra những rules giúp “hiện thực hóa” requirement từ phía Business một cách: phù hợp và hiệu quả.

Đây mới là điểm ăn tiền của người làm công việc Business Analysis.

Đặc biệt nếu anh em làm FS cho một tính năng nào đó, mà đòi hỏi phải connect với rất nhiều hệ thống khác. Thì việc hiểu rõ cách vận hành và rules của các hệ thống khác là một điểm tối quan trọng.

Chỉ khi đó, anh em mới có thể đưa ra được business rules cho tính năng mới này, một cách: hợp lý, hợp logic với hệ sinh thái hiện tại. Mà vẫn đảm bảo giải quyết được Business Requirement một cách hiệu quả nhất.

Nhưng anh em lưu ý là: mình không để Business Requirement vào thẳng mục Business Rules trong FS này nhé. Từ Business Requirement và những gì phân tích được, anh em sẽ suggest ra Business Rules. Chứ Business Requirement và Business Rules là 2 khái niệm hoàn toàn khác nhau.

• Business Requirement có thể là 1 statement rất CHUNG CHUNG.
• Còn Business Rules thì rất RÕ RÀNG và TƯỜNG MINH.

Còn về mặt tương quan thì Business Rules là những thứ chi tiết xung quanh, giúp làm sáng tỏ Use Cases. Và đảm bảo Business Requirement có thể trở thành hiện thực.

Ví dụ cho dễ hiểu:

3.4. Wireframe

Vì mình làm digital product, nên rõ ràng là không thể thiếu mô tả User Interface . Nhưng mình sẽ không vẽ UI ở đây, mà mình chỉ cần làm Wireframe thôi.

Wireframe sẽ giúp chúng ta thể hiện điều này. Wireframe thì anh em vẽ kiểu nào cũng được, nhưng phải đảm bảo thể hiện được đầy đủ 2 mục sau:

• Luồng đi cơ bản của user (User Flows)
• Và cấu trúc nhóm các thông tin (Layout).

Lưu ý khi vẽ Wireframe thì cũng nên MÔ TẢ nó nhé. Trên Wireframe, có bao nhiêu component thì anh em đánh số thứ tự tương ứng vào. Rồi mình làm 1 cái bảng mô tả gồm các thông tin sau:

• ID: số thứ tự tương ứng trên wireframe
• Component: tên của component đó
• Type: là drop down list, hay là text, hay là label, button….
• Validation: mô tả các lớp validate trên front-end nếu có
• Editable: có chỉnh sửa được hay không
• Required: có required không
• Description: ghi chú các thứ khác, như diễn giải thêm ý nghĩa, default value là gì, hay tooltips nếu có…

Oops, bài này tới đây cũng dài rồi nên mình sẽ dừng để mn đọc cho liền mạch nhé. Nếu mn có thắc mắc hay cần trao đổi gì thì cứ để lại comment bên dưới cho mình nhé.