Email sign-off đến lúc 5:42 chiều. Nó có cảm giác nhẹ nhõm của một việc đã xong: requirements approved, next phase ready, mọi người đều được cc. Hai tuần sau, team phát hiện "export customer data" nghĩa là CSV với một stakeholder, Excel với stakeholder khác, API feed với engineering, và dữ liệu đã redact theo luật với compliance.
Đây là phần Business Analysis hay bị xem nhẹ. Công việc không kết thúc khi requirement được viết xong. Nó đi tiếp qua quality check, prioritization, traceability, change, testing, rollout và evaluation.
Ghi chú nguồn: Series này được viết từ file Markdown nội bộ về Lean Business Analysis, tổng hợp ý từ Emrah Yayici, PMI và Business Analysis For Dummies. Em xem đây là tư liệu làm việc, không thay thế cho việc đọc các sách gốc.
Requirement không tốt chỉ vì nghe có vẻ đầy đủ
Tư liệu tách các level requirement khá hữu ích: business requirements mô tả goal và outcome, stakeholder requirements mô tả nhu cầu của từng nhóm, solution requirements mô tả solution phải làm gì hoặc behave thế nào, transition requirements mô tả thứ cần để chuyển từ cũ sang mới, còn technical requirements mô tả constraint hoặc implementation need.
Trộn các level này làm mọi thứ mơ hồ. "Improve renewal retention" không cùng loại requirement với "send an email reminder seven days before contract expiry." Cả hai có thể đúng, nhưng chúng phục vụ hai quyết định khác nhau.
Quality criteria giúp requirement review bớt thành chuyện cảm tính. Requirement nên clear, precise, consistent, correct, complete đủ cho mục đích, measurable, feasible, testable và necessary. Điều đó không có nghĩa mọi câu đều phải như văn bản pháp lý. Nó có nghĩa team có thể build, test và accept mà không phải đoán.
| Requirement yếu | Vấn đề | Phiên bản mạnh hơn |
|---|---|---|
| The system shall be fast. | Không đo được | Search results page shall return the first 50 matching records within two seconds for 95 percent of requests under normal load. |
| Users can export data. | Mơ hồ | Account managers can export filtered customer renewal records to CSV with the columns currently visible in the table. |
| High-risk customers need approval. | Rule chưa định nghĩa | Customers with overdue invoices above 10,000 dollars or an active legal hold require finance approval before renewal discount is applied. |
Prioritization bảo vệ focus
Prioritization không phải nghi thức chính trị nơi stakeholder nói to nhất thắng. Nó là cơ chế bảo vệ value, risk và delivery focus. MoSCoW có thể giúp: must, should, could, will not for now. Multivoting giúp khi một nhóm cần thu hẹp options. Weighted scoring giúp khi criteria được nói rõ.
Nguy hiểm nằm ở việc dùng label mà không có hậu quả. Nếu tất cả đều Must, thật ra không có gì Must. Một Must hữu ích nên qua được câu hỏi khó: nếu không có nó, release có sai luật, vô nghĩa về thương mại, không dùng được về operation, hoặc không an toàn về kỹ thuật không? Nếu không, nó vẫn có thể quan trọng, nhưng có thể chưa phải Must.
Ví dụ trong first release của internal procurement tool, "create purchase request", "approve request" và "audit approval history" có thể là Must. "Dashboard by department", "bulk vendor import" và "custom email templates" có thể là Should hoặc Could tùy rollout need. Một first release rõ thường tử tế hơn một release anh hùng.
Traceability giữ lời hứa được nối liền
Traceability là sợi chỉ nối business need tới requirement, design, build item, test case, release và outcome. Nó có thể nặng nếu làm máy móc, nhưng rất có giá trị khi change xuất hiện.
Requirements traceability matrix có thể gồm requirement ID, source, business objective, priority, owner, status, related design, related test, release và change history. Với product team nhỏ, nó có thể nằm trong Jira links và một table nhẹ. Trong môi trường regulated, nó có thể cần baseline và approval chặt hơn.
Giá trị thực tế xuất hiện trong các câu hỏi như:
- Nếu bỏ requirement này, business objective nào bị ảnh hưởng?
- Nếu regulation đổi, screen, rule, data field và test nào phải đổi?
- Nếu test fail, lời hứa với stakeholder nào đang có risk?
- Nếu stakeholder yêu cầu feature mới, đó là scope mới hay correction của need đã approve?
Traceability cũng giúp kiểm soát scope creep. Không phải bằng cách nói không với mọi thứ, mà bằng cách làm impact visible. Change request nên được assess theo value, effort, risk, timeline, downstream dependencies, test coverage, training và operational readiness.
Change control không chống lại change
Lean BA có tính adaptive, nhưng adaptive không có nghĩa là casual. Khi requirement đã baseline, change cần một đường đi. Đôi khi đường đó là Change Control Board formal. Đôi khi là product trio hoặc delivery lead group. Điều quan trọng là decision có chủ ý và visible.
Một impact analysis đơn giản có thể hỏi:
- Chính xác là điều gì thay đổi?
- Requirement, rule, process, data, interface hoặc stakeholder nào bị ảnh hưởng?
- Nếu accept ngay, defer hoặc reject thì chuyện gì xảy ra?
- Test, training, report, integration hoặc operation procedure nào phải đổi?
- Ai có quyền quyết định?
Đây không phải bảo vệ document cũ. Đây là bảo vệ team khỏi những lời hứa âm thầm.
Solution Evaluation bắt đầu trước go-live
Solution Evaluation hỏi solution được giao có thật sự đáp ứng need không. Nó không nên đợi tới sau launch. Acceptance criteria, test scenario, prototype, walkthrough, exploratory testing, UAT và Day-in-the-Life Testing đều cho tín hiệu sớm hơn.
UAT thường bị hiểu nhầm là chữ ký ban phước cuối cùng từ users. Cách nhìn tốt hơn: UAT validate xem solution có hỗ trợ business use thật không. Day-in-the-Life Testing đi xa hơn bằng cách mô phỏng một ngày làm việc bình thường: edge case, interruption, handoff, correction, report và recovery path.
Sau release, evaluation tiếp tục bằng expected versus actual. Cycle time có giảm không? Error rate có xuống không? Users có bypass system không? Support tickets chỉ chuyển từ queue này sang queue khác không? Process mới có tạo limitation ở chỗ khác không?
Transition là một phần của solution
Solution không thể adopt thì chưa xong. Transition requirements gồm data migration, training, support, communication, cutover, rollback, operational handover và retirement process hoặc system cũ.
Rollout strategy rất quan trọng. Parallel processing an toàn hơn nhưng tốn hơn vì old và new chạy cùng lúc một thời gian. Piloting giảm blast radius và lấy feedback từ nhóm nhỏ. Single cutover nhanh hơn nhưng risk cao hơn. Hypercare cho team một khoảng hỗ trợ tập trung sau go-live, khi usage thật làm lộ những điều planning chưa thấy.
Bài học bình tĩnh là: sign-off là một checkpoint, không phải điểm kết thúc của BA. Requirement chỉ giữ được ý nghĩa nếu team trace được nó, test được nó, change nó có trách nhiệm, và evaluate xem business outcome có thật sự tới hay không.