Hế lôôô anh em, bài này mình sẽ đi tiếp quy trình làm dự án phần mềm và công việc của BA trong đó.

Ở phần trước mình đã note lại giai đoạn đầu tiên là Analysis, gồm 6 bước nhỏ: Project Definition >> Elicitation >> Analysis >> Documentation >> Verification >> Management.

Recall lại 6 bước nhỏ trong giai đoạn Analysis ở bài trước

Hi vọng anh em sẽ không cảm thấy khó hiểu khi đọc đến đây.

Sau bước Analysis này chúng ta đã có tài liệu mô tả yêu cầu, tức là đã biết được khách hàng cần gì. Giờ BA và team dự án sẽ đi vào giai đoạn thiết kế hệ thống sao cho đáp ứng những yêu cầu này nhé anh em 😎

2. Design

Ở bước này, tùy level, trách nhiệm, và loại dự án, mà BA sẽ tham gia vào ít hoặc nhiều.

Thực tế xảy ra là: hiếm khi BA ghi nhận các được yêu cầu một cách chi tiết ngay ở bước analysis. Nếu có thì chỉ ở mức độ high level. Còn tiểu tiết như từng User Story thì rất khó.

Do đó thường thì ở giai đoạn này (và có thể là các giai đoạn sau), BA sẽ phải trao đổi thêm với khách hàng để làm rõ các yêu cầu (những anh em nào đã kinh nghiệm, có khả năng clarify rõ ràng mọi thứ ngay từ đầu thì những giai đoạn sau này sẽ đỡ hơn rất nhiều).

Chưa kể nếu dự án triển khai theo Agile thì yêu cầu thay đổi liên tục, đòi hỏi anh em phải quản lý các requirement bài bản và làm việc với khách hàng nhiều về các yêu cầu thay đổi này.

Đó là phía mình, còn về phía khách hàng, nhiều khi họ còn chưa chắc về những yêu cầu họ đưa ra. Mà business thay đổi thì là chuyện một sớm một chiều.

Nên đây là chuyện hết sức bình thường: Requirement sẽ luôn thay đổi không ít thì nhiều xuyên suốt dự án. Đó là lý do vì sao mình vẽ đường //Requirement// màu xanh lá trên cùng chạy xuyên suốt dự án đó anh em 😎 

Output của bước Design đối với BA

Ở bước design, anh em sẽ can thiệp sâu một ít về kỹ thuật, bao gồm những thứ như:

• Thiết kế Database
• Vẽ Data Flow
• Vẽ Mockup
• Thiết kế UX/UI
• Thiết kế Business Process Flow
• Thiết kế bộ phân quyền hệ thống
• Vẽ Solution Architect
• …

Nghe tùm lum tùm la nhưng những điểm trên không phải một mình BA thầu hết (may quá), mà phải có sự can thiệp/ support của các anh em khác, có thể là Dev, Technical Architect, hoặc PM…

Và những thứ này sẽ linh động theo tùy loại dự án. Như những dự án triển khai thì sẽ không cần thiết kế UX/UI hay vẽ mockup.

Tuy nhiên mình thấy trong các thứ trên, hầu như BA sẽ thầu hết 70%.

Solution Architect thì TA sẽ làm. Database thì BA làm cũng được, nhưng cần có sự review từ toàn team vì nó sẽ ảnh hưởng đến những thứ trong tương lai. Còn về UX/UI thì có anh em designer làm chứ BA mình không có chuyên môn để làm phần này (và thường thì cũng chẳng có BA nào đi design UX/UI cả – trừ khi thiếu resources dữ lắm thôi).

Sau cùng cả team sẽ gom các kết quả lại để ra được thành phẩm cuối cùng là: Tài liệu thiết kế.

Để cho sang thì anh em hay gọi là SDD (Software Design Document) hoặc FDD (Functional Design Document).

…

Ô kê, vậy là qua 2 giai đoạn (Analysis và Design), chúng ta đã có được 2 tài liệu quan trọng:

• Tài liệu mô tả yêu cầu (SRS/FRD)
• Tài liệu thiết kế (SDD/FDD)

Có hàng nóng trong tay, anh em developer sẽ bắt đầu HIỆN THỰC HÓA sản phẩm bằng cách viết những dòng code đầu tiên.

3. Develop

Giai đoạn này anh em BA sẽ hỗ trợ Development Team trong quá trình build sản phẩm.

Ví dụ có Use Case nào chưa rõ, anh em sẽ giải thích để dev họ hiểu hơn về mục đích của Use Case. Hoặc nếu anh em làm giai đoạn Analysis và Design không kỹ, thì giai đoạn Development sẽ lòi ra những lỗi logic giữa các yêu cầu với nhau.

Ví dụ yêu cầu này conflict yêu cầu kia. Thì lúc này anh em BA phải làm việc lại với khách hàng để làm rõ vấn đề, rồi update lại cho Development Team để anh em làm tiếp.

BA làm gì trong bước Develop?

Sau khi Development Team build xong một hoặc nhiều tính năng nào đó, chúng ta sẽ phải test các tính năng này.

4. Test

Giai đoạn test gồm 2 giai đoạn nhỏ: Internal Testing và External Testing.

4.1. Internal Testing

Internal Testing tức là nội bộ team dự án tự kiểm tra với nhau xem thử các tính năng đã được build đúng chưa, trước khi release cho khách hàng.

Đây có thể là nhiệm vụ của BA, hoặc không.

Các Software Development Team luôn có vai trò QC. QC sẽ là người chịu trách nhiệm test các tính năng vừa mới build này. Đảm bảo Dev làm đúng theo như tài liệu yêu cầu/ thiết kế, và đảm bảo team deliver đúng như những gì đã cam kết với khách hàng.

QC sẽ viết các Test Case để kiểm tra từng tính năng một.

Còn đối với các dự án triển khai, Software Implementation Team thường sẽ không có QC. BA trong team sẽ chịu trách nhiệm cho các phần test này luôn.

Vì so với những dự án build mới từ đầu, độ chính xác của các tính năng chuẩn trong các dự án triển khai sẽ cao hơn rất nhiều.

Vì triển khai là triển khai những gì đã có sẵn. Những tính năng này đều do các hãng lớn build sẵn, nên hầu như việc sai sót là không có.

BA trong các dự án triển khai chỉ cần test lại các tính năng “khác lạ so với chuẩn”. Tức là những tính năng customized mà khách hàng yêu cầu. Chứ không cần test lại toàn bộ các tính năng từ nhỏ tới lớn mà dev build như login, authorization, CRUD, import/export…

Ngoài Test Case ra, anh em BA cần phải chuẩn bị một thứ nguy hiểm hơn, đó là: Requirement Traceability Matrix (RTM).

Output của bước Test đối với BA

RTM cũng không có gì quá ghê gớm. Anh em chỉ cần lấy Test Cases map với Requirements là sẽ ra được RTM.

Mục đích của Requirement Traceability Matrix là để anh em trace lại được là các Requirement đã được test hay chưa, và test thành công hay thất bại. RTM sẽ giúp anh em control được “sức khỏe” của các requirements xuyên suốt dự án.

Ví dụ về RTM. Lấy Test Case map với Requirement, anh em sẽ có Requirement Traceability Matrix.

Ví dụ về Test Case

4.2. External Testing

Sau khi team đã test nội bộ với nhau và chắc chắn rằng: “à những tính năng này đã được build đúng & build đủ”. BA sẽ thực hiện các buổi User Acceptance Test (UAT) với khách hàng.

User Acceptance Test là buổi mà một vài key-users của khách hàng sẽ ngồi test lại hệ thống từ đầu đến cuối, dựa trên Test Case mà khách hàng tự viết hoặc bên đối tác viết (cái lúc nãy).

Sau khi test xong, nếu có vấn đề gì thì anh em phải sửa lại và thực hiện UAT lại. Còn nếu mọi thứ ô tô kê thì dự án sẽ qua bước tiếp theo: Deploy cho end-users sử dụng 😎

5. Deploy

Đối với BA, anh em có thể hiểu Deploy nghĩa là mình sẽ làm tất cả những thứ để hệ thống sẵn sàng được sử dụng. Những thứ đó có thể là:

• Build solution từ môi trường Dev lên môi trường Production.
• Migrate data: là chuyển toàn bộ data hiện tại của khách hàng từ hệ thống cũ sang hệ thống mới.
• Thiết lập người dùng như: phân quyền, cập nhật tài khoản, thông tin cá nhân…
• Hướng dẫn người dùng sử dụng hệ thống
• Và một số thứ râu ria khác tùy dự án, như: bật audit hệ thống, kích hoạt các batch job, hoặc chuẩn bị

  Go-Live Checklist

  .

Output của bước Deploy đối với BA

Ở bước này mình muốn highlight với anh em dòng “hướng dẫn người dùng sử dụng hệ thống” như nhiệm vụ chính của BA trong giai đoạn này. Các phần còn lại, BA và anh em Developer sẽ cùng phối hợp thực hiện.

Để training end-users, anh em sẽ cần có tài liệu hướng dẫn (User Manual). User Manual có thể có nhiều dạng: tệp pdf, video, hoặc thậm chí là tài liệu prezi,… tùy nhu cầu và cách làm của mình.

Ví dụ về User Manual – phiên bản pdf: 1 bên là ảnh chụp màn hình, 1 bên là hướng dẫn chi tiết.

Sau khi chuẩn bị xong User Manual, anh em sẽ tiến hành training cho end-users. Sau đó anh em sẽ làm một danh sách các điểm cần chuẩn bị để tiến hành Go-live, gọi là Go-live Checklist.

Xong, vậy là coi như anh em đã sẵn sàng để Go-Live, cột mốc quan trọng bậc nhất trong bất kỳ dự án nào 😎

Sau giai đoạn Deploy trước giai đoạn Maintain sẽ là cột mốc Go-live. Giả dụ anh em đã Go-live thành công đi nhé, để mình qua giai đoạn tiếp theo :v

6. Maintain

Sau khi Go-live xong, tức là khách hàng đã thật sự sử dụng hệ thống, anh em sẽ vào giai đoạn cuối cùng trong quy trình làm dự án phần mềm, đó là Maintenance – Bảo trì (hoặc cũng có thể là Warranty – Bảo hành)

Thường thì các dự án mình làm sẽ bảo trì khoảng 1-3 tháng sau Go-live.

Bảo hành tức là mình sẽ hỗ trợ khách hàng, xem thử trong quá trình sử dụng họ có gặp vấn đề gì không, bug chỗ nào để mình hỗ trợ giải quyết kịp thời.

Khi có lỗi phát sinh, khách hàng sẽ gửi lỗi này lên một trang portal để BA và anh em trong team biết mà bay vô support. Hoặc đơn giản người Contact Point bên phía khách hàng sẽ tổng hợp các lỗi định kỳ hàng tuần/ tháng và gửi email cho team dự án.

Output của bước Maintenance đối với BA

Trong giai đoạn này, các lỗi đều sẽ được log lại để theo dõi “vòng đời lỗi” (nghe hoành tráng quáaa). Tức là lỗi từ lúc phát sinh đến lúc được giải quyết, ai là người phát hiện ra lỗi, thuộc phân hệ nào, nguyên nhân ra sao, tình trạng thế nào, và thời gian ghi nhận.

Ngoài ra, nếu anh em có các hoạt động support khách hàng tại văn phòng của họ (onsite các kiểu) hoặc online meeting, thì anh em sẽ phải làm những Activity Sheet, ghi nhận những hoạt động đó, để 2 bên có thể dễ dàng quản lý, đặc biệt trong trường hợp có chi phí phát sinh.

.

.

.

Ô kêêê anh em đã thấy mệt chưa. Vậy là coi như chúng ta đã đi xong một quy trình làm dự án!

Cùng nhìn lại những thứ mà BA sẽ deliver xuyên suốt dự án nhé anh em.

Những thứ mà BA sẽ deliver xuyên suốt dự án

Mình nhắc lại là tùy kiểu quản lý dự án (project management methodology) mà quy trình trên sẽ thay đổi, nhưng về bản chất nó sẽ luôn bao gồm 6 giai đoạn trên, và công việc BA cũng sẽ không khác gì mấy trong 6 giai đoạn này.

Kết bài

Hi vọng qua bài này anh em sẽ thật sự hiểu rõ về nghề BA, về Business Analyst.

Đây 100% là các công việc BA sẽ làm trong các công ty outsource hoặc service. Còn đối với các công ty client, BA sẽ làm hơi khác một chút, nhưng cơ bản thì vai trò của BA trong công ty nào cũng giống nhau hết 🙂

…

Sorry anh em dạo này nhịp độ ra bài hơi chậm, mong anh em thông cảm 😥 Mình sẽ luôn cố gắng duy trì mật độ 4 bài/ tháng, anh em cứ yên tâm nhé.

Nếu có gì cần hỏi hoặc trao đổi thêm, anh em cứ còm men bên dưới cho mình nhé. Bái bai và hẹn gặp lại!

Like this:

Like

Loading…

Related