Hế lô anh em, đợt rồi có nhiều anh em nhắn tin hỏi mình về cách BA viết tài liệu FS.

Như tuần trước có bạn nhắn mình: “anh ơi BA mình viết FS như nào anh”. Hoặc có bạn nhắn “anh có sẵn template FS hông anh”. Hoặc có bạn vào thẳng luôn vấn đề: “hỏng ấy, anh viết dùm em cái FS này luôn được hông….

Nói chung có rất nhiều câu hỏi liên quan đến FS. Nên nay tranh thủ vừa đóng xong dự án, mình xin note lại vài ý về chủ đề “BA viết FS như thế nào” nhé anh em.

1. Bản chất của FS

Ô kê trước khi bắt tay vào làm FS, thì mình cần nắm rõ nó là gìmục đích tồn tại của nó nhé anh em.

FS trong Software Development là viết tắt của Functional Specification. Nghĩa là Đặc tả chức năng (của phần mềm). Nôm na thì đây là tài liệu mô tả phần mềm làm được những gì.

Như anh em biết thì BA có nhiều kiểu BA, mỗi công ty lại định nghĩa scope của BA là rất khác nhau. Chưa kể trong cùng 1 công ty, nhưng BA của dự án này lại perform một scope khác hoàn toàn với BA của 1 dự án khác.

Nói vậy để anh em hình dung là phạm vi công việc của BA trong từng dự án, từng công ty là rất linh hoạt. Và hoàn toàn không có đúng hay sai. Mà là có phù hợp với nhu cầu hiện tại của dự án đó hay không mà thôi.

Kéo theo đó là “việc làm FS của BA” nó cũng sẽ khác nhau theo từng dự án và từng công ty nhé anh em.

Ngoài FS ra, thì tài liệu này còn có nhiều tên gọi khác nhau, như: SRS – Software Requirement Specification, FRD – Functional Requirement Document, hoặc là viết dưới dạng User Story.

Nhưng dù có tên gì thì mục đích duy nhất của nó cũng là mô tả: Phần mềm này làm được những gì.

Ba-viet-tai-lieu-nhu-nao

 

2. FS viết cho ai đọc

Để dễ hình dung thì anh em cứ xem nội dung trong FS chính là “điểm giao thoa giữa Business và Tech”. Theo đó, mục đích sau cùng của FS là dành cho 2 đối tượng này đọc.

ba-viet-tai-lieu-nhu-nao

Vậy phía Businessphía Tech cần đọc những gì từ FS này?

Business

Như anh em đã biết (hoặc biết mà làm bộ chưa biết) thì thường có 4 loại requirements: Business Requirement >> Stakeholder Requirement >> Solution Requirement >> và cuối cùng là Transition Requirement.

Phía Business User chủ yếu quan tâm đến cái Biz Requirement và Stakeholder Requirement được phát biểu trong FS là gì? Nó có đáp ứng đúng nhu cầu hiện tại của họ hay không?

Và thường thì đây là phần “văn mẫu” mà anh em BA hay chém bừa nhất ?

Mặc dù phần này không nhất thiết cần phải trình bày rõ ràng, mang tính logic, hay thuyết phục hùng hồn về giải pháp có chắc là giải quyết được các requirement hay không. Vì phần này đã-phải-được-làm trước đó trong các câu chuyện “thấm đẫm tiền bạc” như: bidding, làm POC, Business Case… rồi.

Nhưng việc BA trình bày một cách gọn gàng và logic về đề bài mà Biz Requirement & Stakeholder Requirement đặt ra là rất quan trọng. Cụ thể:

  • Nó có ăn nhậu gì với phần giải pháp bên dưới không?
  • Khi review milestone nào đó, có dễ dàng đánh giá được KPI nào đạt, KPI nào không hay không?

Và quan trọng nhất, khi nói rõ và gãi được đúng chỗ ngứa của khách hàng (sponsor, system owner…) thì rất dễ để họ thật sự quan tâm đến docs mình viết. Theo đó là rất dễ để kéo họ tiếp tục với các phần phía sau (rất khô khan) của FS.

ba-viet-tai-lieu-nhu-nao

Tech

Còn về phía Tech, anh em trong team sẽ quan tâm nhiều đến Solution Requirement được mô tả trong này như thế nào.

Đó là những Use Case, Business Process Flow, Business Rules, Wireframe hay các Diagram thể hiện theo từng nội dung cụ thể. Phần Solution Requirement này giúp team hiểu được chi tiết từng module. Hiểu được độ lớn, và độ phức tạp của nó.

Từ đó có cái nhìn tổng quan. Và có thể phân rã thành từng task nhỏ phù hợp.

Cụ thể hơn một chút thì phía Business có thể là các anh em đến từ: Sales, Marketing, Operation, CS…
Phía Tech thì chắc chắn sẽ là: Dev, QC, PM, Designer, Infra, Security…

Ô kêêêêê, đến đây phần nào anh em đã nắm được mục đích và đối tượng của FS. Tiếp theo sẽ là?

 

3. FS thường viết ở đâu?

Đâu cũng được. Đây là câu trả lời mình nghĩ thực tế nhất. Anh em nên cởi chuồng à nhầm cởi mở như vậy.

Anh em có thể viết FS trên:

  • Word (dĩ nhiên rồi)
  • Hoặc trên excel (như mình cũng đã từng, và hiệu quả vô cùng)
  • Hoặc trên power point (mình cũng đã từng, vì tính chất dự án nên chủ yếu mô tả BPMN là đủ)
  • Hoặc trên Confluence, Google Docs hoặc bất kỳ platform nào có hỗ trợ viết docs.

Nói như vậy để một lần nữa khẳng định: FS là một thứ rất linh hoạt, có thể viết trên bất kỳ đâu.

Nhưng, câu hỏi: Nên viết ở đâu?” thì lại cần cân đo đong đếm giữa nhiều yếu tố.

Nếu team có nhiều người, và anh em cần một chỗ share chung để viết thì Confluence là quá hợp lý. Có tracking history, có version baseline, có sharing theo permission, formatting thoải mái,…. nói chung là SƯỚNG. Dự án có điều kiện thì đầu tư quả Confluence viết là chuẩn bài nhất.

Nhưng nếu dự án chỉ có 1-2 BA, hoặc chỉ mình anh em làm. Và nhu cầu transfer FS cho team cũng không quá thường xuyên thì mình nghĩ word hay excel là đủ!!!

  • Nó là file trên local, phần nào sẽ bảo mật hơn khi nằm duy nhất trên máy của anh em.
  • Tự mình edit, tự mình control, tránh nhầm nhọt khi cả lũ cùng edit.
  • Miễn phí, nhanh gọn, không cần cài đặt. Ai cũng xem được mà không cần đăng ký bất kỳ tài khoản gì.
  • Thậm chí nếu dùng Excel, anh em có thể nhanh chóng nhảy qua nhảy lại giữa các sheet. Giúp trải nghiệm đọc “ngay trong tầm mắt” và dễ dàng đối chiếu được các phần với nhau.

Có những dự án consulting cả tỷ bạc mà người ta vẫn dùng file word để deliver tài liệu như thường mà anh em. Nên anh em cứ tùy tình hình dự án mà liệu cơm gắp mắm nhé.

Chủ trương vẫn là tinh thần: nhanh, gọn, lẹ và đặc biệt là hiệu quả ?

 

4. Những quan điểm lệch lạc về FS

ba-viet-tai-lieu-nhu-nao

Mình thấy anh em thường lậm vào 2 quan điểm sau, mà theo mình 10 phần thì sai hết 11 phần.

1. Ông nào viết FS, ông đó là BA ?

Câu trên thoạt nhìn cứ nghĩ là đúng, nhưng theo mình nó chỉ đúng được 1 nửa.

Anh em phải hình dung là: ĐỂ-CÓ-CÁI-VIẾT trên FS, thì chúng ta phải làm hầm bà lằng rất nhiều thứ trước đó, thì mới ra được cái, để mà viết vào FS.

Nào là phải hiểu về business, rồi hiểu về vấn đề đang gặp là gì. Nội sương sương hai này thôi cũng đã rất trày trật rồi. Hiểu cái hiện tại rồi, anh em phải đề xuất được vài ba cái solution nào đó, để giải quyết vấn đề sao cho phù hợp và tối ưu nhất.

Rồi solution này được phân tích trên các khía cạnh nào, impact của nó ra sao. Chưa kể còn phải cân đo đong đếm tính hiệu quả, rồi khả năng thực thi (technical feasibility). Và phải map nó vô cái roadmap như thế nào cho hợp lý…

…Những thứ này ít nhiều mình cũng có note ở đây, anh em xem thêm nhé 😀

Nhìn chung, anh em mình phải làm rất nhiều thứ – với nhiều người, thì mới có cái để viết được trong FS. Khoan nói đến chuyện viết chuẩn. Nếu ngay từ đầu, việc định hình bài toán trật, thì giải pháp dù ngon nghẻ cỡ nào cũng không gãi trúng được chỗ ngứa. Kéo theo đó là viết có xịn đến cỡ nào thì cũng toang.

Do đó, để hiểu đúng bản chất vấn đề thì: Người làm công việc phân tích & thiết kế để rồi mô tả nó lại trong FS mới là BA (là người làm công việc Business Analysis)

Giá trị của BA không nằm ở chuyện viết docs. Giá trị của BA nằm ở khâu phân tích & thiết kế để ra-được-thứ viết vào docs.

ba-viet-tai-lieu-nhu-nao

Và trong câu chuyện phân tích – thiết kế, cá nhân mình thường dành ra khoảng:

  • 60% thời gian để tìm hiểu về problem gặp phải
  • 40% thời gian còn lại mới đi vào solution (chứ đừng ngược lại nhé anh em).

Nên suy nghĩ “Ông nào viết FS thì ông đó là BA” chỉ đúng được 1 nửa, và không đi sâu vào gốc rễ vấn đề.

Mình biết ở một vài công ty, 1 dự án nhỏ thôi cũng có tới 2-3 ông làm BA. Nhưng lại chia theo kiểu:

  • 1 ông chủ yếu trao đổi với khách hàng để elicit requirement
  • Rồi 2 ông kia dựa vào đó, viết lại vào FS, theo sự hướng dẫn của ông ở trên.

Nếu nói 2 ông kia làm BA luôn vì 2 ổng là người viết FS thì chả đúng tí nào. Nó mất đi cái tính chất của công việc BA.

Mô hình này mình thường thấy ở các công ty oursource. 2 Junior sẽ theo chân 1 Senior. Senior chuyên facing với khách hàng để tìm hiểu & phân tích business. Junior ghi meeting minutes rồi viết lại vào FS theo hướng dẫn của Senior.

Cách làm này không hẳn là xấu, nhưng nó không giúp cho bạn Junior hiểu được tường tận vòng đời từ lúc: nhận yêu cầu đến khi ra được giải pháp và viết nó vào FS là như nào.

Sẽ tốt hơn nếu cả Senior & Junior cùng side-by-side với nhau xuyên suốt dự án. Kể cả lúc tìm hiểu về business, thảo luận với khách hàng, hay brainstorm tìm giải pháp với team. Rồi sau đó là cùng chia ra các phần trong FS để viết với nhau.

Thì chỉ khi đó, cái anh Senior này mới rút chích ra được những điểm tốt và chưa tốt của bạn kia trong xuyên suốt cả quá trình từ UR -> FS. Từ đó mới giúp cải thiện lên dần được.

Hiệu quả và đi thẳng vào vấn đề là ưu điểm mà cách làm này mang lại.

Và cũng một quan điểm khác, liên quan đến vụ này…

2. Viết FS dễ mà, cứ đưa cho Junior viết!!!

Câu này có 2 ý:

  • Viết FS dễ mà
  • FS thì cứ đưa cho Junior viết

Ý 1, “Viết FS dễ” thật ra không đúng, cũng không sai. Nó tùy vào công đoạn trước đó anh em làm có hiệu quả hay không.

Nếu từ một mớ rối rắm, anh em định hình được bài toán, đưa giải pháp phù hợp, và thật sự đã phân tích kỹ giải pháp này. Thì chuyện đưa nó vào trong FS là chuyện… làm cái một.

(…dĩ nhiên khi viết FS nó sẽ có vài lưu ý để viết sao cho ổn, mình sẽ nói ở chuỗi bài sau nhé anh em.
Nhưng sau tất cả thì đây không phải vấn đề lớn nhất).

Hoặc cũng từ một mớ rối rắm, anh em có thể vào & càng làm phức tạp hóa vấn đề. Định nghĩa sai đề bài, giải pháp trớt quớt, không ăn nhậu với cái gì. Và ngay cả bản thân anh em cũng không hiểu rõ solution đó là như thế nào. Thì việc đưa nó vào FS đúng thật là một cực hình.

Tin mình anh em, cá nhân mình đã trải qua “n mũ hai” lần rồi nên mình hiểu rõ lắm. Chưa kể áp lực về thời gian, chưa có kinh nghiệm không biết làm sao. Hay thậm chí áp lực từ chính team nhà mình, từ Dev, QC, Designer…. đổ lên đầu cùng lúc.

Sẽ thật sự là chuaaaa nếu anh em rơi vào cảnh nào. Nhưng, no pain no gain!

Do đó, chuyện viết FS dễ hay khó hoàn toàn phụ thuộc vào công đoạn phân tích & thiết kế trước đó nhé anh em. Phụ thuộc vào cái gọi là “bản chất của công việc BA” mà bên trên mình có nói đó 🙂

ba-viet-tai-lieu-nhu-nao

Ý thứ 2, “viết FS thì cứ để cho Junior viết”.

Nhiều công ty có role “Technical Writer”. Bạn này thường được yêu cầu không quá cao. Theo chân BA để viết FS, và được định hướng để sau này làm BA.

Nếu project mình làm thì rất ít khi mình để chuyện này xảy ra. Hoặc cùng lắm, bạn Junior này chỉ viết trong từng phạm vi nhỏ, được giao rất rõ ràng. Vì 2 lý do:

1/ Người kể chuyện nên là người từng trải.

Người trực tiếp tìm hiểu vấn đề và trao đổi từng khía cạnh (dù là nhỏ nhất) của giải pháp, thì nên là người trực tiếp thể hiện nội dung đó vào trong FS. Mục tiêu quan trọng nhất là tránh tam sao thất bản khi cascade cho nhiều anh em khác để viết.

Người ta thích nghe kể chuyện từ một người đã trực tiếp trải qua chuyện đó, hơn là nghe kể lại đúng không anh em. Stakeholder của mình cũng vậy.

2/ Viết FS cũng rất quan trọng.

Mình ghi chữ viết zậy thôi, chứ thật ra anh em phải tận dụng toàn bộ technique mà mình biết để THỂ HIỆN ý đồ một cách rõ nét nhất. Cần cho người đọc hiểu: thật sự đây là cái tui cần thể hiện.

  • Sẽ không ai thèm đọc 1 sớ văn xuôi từ trên xuống toàn chữ là chữ
  • Và cũng không ai thèm đọc 1 mớ boòng boong sơ đồ chi chít khắp tài liệu, mà không có lấy một dòng mô tả.

Do đó việc kết hợp nhuần nhuyễn giữa: chữ viết, quy trình, diagram, hình ảnh thiết kế,… như thế nào cho hiệu quả là cả 1 quá trình. Dù anh em phân tích có tốt, có ổn, có đúng i sì “sách giao khoa” đi chăng nữa, mà lại không thể hiện nó ra được thì coi như công sức trước đó cũng đổ sông đổ bể.

Viết FS không khó cũng không dễ, nhưng cũng đừng quá xem nhẹ chuyện viết FS nhé anh em. Nếu team có nhiều anh em BA hoặc các bạn Junior cùng viết, thì phải hỗ trợ nhau review thật kỹ trước khi “on air” nhé.

 

5. Tạm kết

Ô kêêêê anh em, trên là 7749 điều về FS, theo những gì mình biết và từng trải qua. Hi vọng nó hữu ích với anh em 🙂

HIỂU đúng về nó, khả năng cao mình sẽ LÀM tốt nó. Hiểu không tới nơi, thì phần nhiều mình đã toang ngay từ đầu. Hẹn gặp anh em ở bài sau nhé. Mình sẽ note chi tiết cách mình làm FS để anh em tham khảo.

See yahhh!!!