Vai trò của BA trong quy trình Waterfall

Bài này giả định bạn đã nắm cơ bản về Waterfall. Nếu chưa, đọc bài "Giới thiệu các mô hình phát triển phần mềm: Waterfall, Agile, Scrum" trước.

1. BA làm gì ở từng giai đoạn?

Nhìn bảng này sẽ thấy một hiểu lầm phổ biến cần gạt bỏ: BA trong Waterfall không phải "làm xong tài liệu rồi ngồi chơi". Khối lượng công việc dồn về đầu thật, nhưng BA vẫn theo dự án tới cuối. Chỉ là tính chất công việc đổi từ tạo ra yêu cầu sang bảo vệ và giải thích yêu cầu.

2. Tài liệu là sản phẩm chính

Ở Waterfall, tài liệu không phải thủ tục hành chính. Nó là thứ cả dự án dựa vào, và thường là một phần của hợp đồng.

Những tài liệu BA hay phải viết:

• BRD (Business Requirement Document) — mục tiêu kinh doanh, phạm vi, các bên liên quan. Trả lời câu hỏi vì sao làm.
• SRS (Software Requirements Specification) — đặc tả chi tiết cho đội kỹ thuật: yêu cầu chức năng, yêu cầu phi chức năng, quy tắc nghiệp vụ, luồng xử lý. Trả lời câu hỏi làm cái gì, đúng là thế nào.
• Use Case hoặc mô tả luồng nghiệp vụ — mô tả từng bước tương tác giữa người dùng và hệ thống, gồm cả luồng chính lẫn các trường hợp ngoại lệ.
• Wireframe hoặc mockup — hình dung màn hình để các bên liên quan duyệt trước khi code.

Điểm mấu chốt trong Waterfall: những tài liệu này được ký duyệt. Chữ ký đó biến chúng thành mốc tham chiếu. Sau này khi có tranh cãi "cái này đã thống nhất chưa", câu trả lời nằm trong tài liệu chứ không nằm ở trí nhớ của ai.

Vì vậy, ba tiêu chí của một tài liệu tốt trong Waterfall là: đầy đủ (không sót trường hợp), rõ ràng (mỗi câu chỉ hiểu được một cách), và không mâu thuẫn (mục 3.2 không nói ngược mục 5.7).

3. Truy vết yêu cầu

Khi dự án có hàng trăm yêu cầu và kéo dài nhiều tháng, câu hỏi "yêu cầu này đã được thiết kế chưa, đã code chưa, đã test chưa" trở nên rất khó trả lời bằng trí nhớ.

Công cụ cho việc này là ma trận truy vết yêu cầu (Requirements Traceability Matrix — RTM): một bảng nối từng yêu cầu với hạng mục thiết kế, đoạn code và test case tương ứng.

Nghe có vẻ nặng nề, nhưng nó giải quyết đúng nỗi đau của Waterfall: phát hiện sót ở giai đoạn cuối. Một yêu cầu không có test case tương ứng là một yêu cầu chưa ai kiểm tra.

4. Sống chung với quy trình quản lý thay đổi

Yêu cầu vẫn sẽ đổi, kể cả trong Waterfall. Khác biệt là ở chỗ đổi phải đi qua một cửa chính thức: Change Request (CR).

Một CR thường đi qua các bước:

1. Ghi nhận — ai đề xuất, đổi cái gì, vì sao.
2. Phân tích tác động — phần việc chính của BA. Thay đổi này ảnh hưởng tới những yêu cầu nào khác, những màn hình nào, dữ liệu đang có xử lý ra sao? Tốn thêm bao nhiêu công?
3. Ra quyết định — thường là một hội đồng hoặc cấp quản lý dự án duyệt hay từ chối, cân nhắc chi phí và tiến độ.
4. Cập nhật tài liệu — nếu duyệt, mọi tài liệu liên quan phải được sửa và ký lại. Nếu bỏ qua bước này, tài liệu và sản phẩm sẽ lệch nhau, và nửa năm sau không ai biết đâu là bản đúng.

Phần phân tích tác động là nơi một BA giỏi tạo ra khác biệt rõ nhất. Người mới thường chỉ nhìn thấy thay đổi trực tiếp; người có kinh nghiệm nhìn ra những chỗ bị kéo theo — báo cáo nào đang đếm theo trường dữ liệu sắp đổi, hệ thống nào đang nhận dữ liệu qua API, người dùng nào cần đào tạo lại.

5. Ví dụ

Công ty trúng thầu dự án Hệ thống Quản lý Hồ sơ Nhân viên cho một cơ quan nhà nước. Đặc tả nằm trong hồ sơ mời thầu, chi tiết và không được đổi trong quá trình thực hiện hợp đồng.

Giai đoạn đầu — phần lớn công sức phân tích dồn vào đây: BA đọc kỹ hồ sơ thầu, đối chiếu với quy định hiện hành về quản lý hồ sơ cán bộ, tổ chức các buổi làm việc với phòng tổ chức cán bộ để làm rõ những chỗ hồ sơ viết chung chung. Ví dụ hồ sơ ghi "quản lý quá trình công tác" — BA phải hỏi cho ra: gồm những trường thông tin nào, ai được sửa, có cần lưu lịch sử thay đổi không, xuất báo cáo theo mẫu nào.

Toàn bộ được tài liệu hoá vào SRS theo đúng quy chuẩn của bên A, rồi trình phê duyệt chính thức. Chỉ sau khi có chữ ký, thiết kế và lập trình mới bắt đầu.

Ba tháng sau — bên A muốn thêm chức năng ký số vào quyết định điều động. Yêu cầu này không có trong hồ sơ thầu. BA lập CR, phân tích tác động: cần tích hợp với hệ thống chữ ký số của đơn vị, ảnh hưởng tới luồng phê duyệt hiện tại, cần thêm khoảng sáu tuần và một hạng mục hợp đồng bổ sung.

Hội đồng dự án cân nhắc rồi quyết định tách thành giai đoạn 2. Đây là kết cục rất bình thường trong Waterfall — và cũng cho thấy vì sao việc làm rõ yêu cầu ở giai đoạn đầu lại quan trọng đến vậy.

6. Những cạm bẫy fresher BA hay mắc

• Chép lại lời khách hàng thay vì phân tích. Khách nói "cần báo cáo tổng hợp" mà bạn ghi đúng như vậy vào SRS thì đến lúc code, dev sẽ hỏi lại từ đầu — và lúc đó khách đã bận việc khác.
• Viết yêu cầu hiểu được nhiều cách. "Hệ thống phải phản hồi nhanh" là một câu vô nghĩa trong SRS. Bao nhiêu giây, với bao nhiêu người dùng đồng thời?
• Bỏ qua yêu cầu phi chức năng. Hiệu năng, bảo mật, phân quyền, sao lưu, khả năng chịu tải. Những thứ này ít khi được khách hàng nói ra, nhưng thiếu là nghiệm thu không qua.
• Không cập nhật tài liệu sau khi có CR. Tài liệu lệch sản phẩm là mầm mống của tranh cãi ở giai đoạn nghiệm thu.
• Ngại hỏi vì sợ lộ ra mình chưa hiểu. Trong Waterfall, một câu hỏi không dám hỏi ở tháng đầu có thể thành một CR tốn sáu tuần ở tháng thứ sáu.
• Nghĩ rằng hết giai đoạn phân tích là hết việc. Dev và tester sẽ tìm bạn suốt dự án.

7. Kỹ năng cần mạnh, khác với Agile

Cùng là BA, nhưng hai môi trường đòi hỏi trọng tâm khác nhau:

Không môi trường nào dễ hơn môi trường nào. Waterfall đòi hỏi bạn kỹ lưỡng và có kỷ luật với tài liệu. Agile đòi hỏi bạn chủ động và chịu được sự chưa chắc chắn.

Tóm lại

BA trong Waterfall là người đặt nền móng. Bạn dồn sức ở giai đoạn đầu để dựng một bản đặc tả đầy đủ, rõ ràng, không mâu thuẫn — rồi theo nó tới cuối dự án để bảo vệ, giải thích và cập nhật khi có thay đổi được duyệt.

Cái giá của Waterfall là phát hiện sai muộn. Cách phòng thủ tốt nhất của BA là hỏi cho hết ở giai đoạn đầu, và viết ra sao cho mỗi câu chỉ hiểu được một cách.