Sáng thứ Hai, calendar của BA nhìn từ xa có vẻ bình thường: ba buổi interview, một workshop, một backlog refinement, và một buổi review với operations. Nhìn gần hơn, nó kể câu chuyện khác. Cùng một vấn đề nhưng có năm phiên bản, mỗi phiên bản được nắn bởi áp lực hằng ngày của một stakeholder khác nhau.
Vì vậy BA Planning không phải việc hành chính. Nó là cách team quyết định sẽ dùng attention ở đâu, cần hiểu thực tế của ai, và cần evidence nào trước khi requirement trở nên đắt đỏ.
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.
BA Planning là lập kế hoạch cho sự hiểu biết
Project plan nói delivery work có thể diễn ra thế nào. BA plan nói việc hiểu vấn đề sẽ diễn ra thế nào. Hai thứ liên quan nhau, nhưng không giống nhau. Delivery plan có thể ghi "build onboarding flow trong Sprint 3." BA plan hỏi ai hiểu onboarding hiện tại, assumption nào còn yếu, quyết định nào phụ thuộc vào assumption đó, và khi nào team phải biết đủ để đi tiếp.
Tư liệu đặt BA Planning quanh những câu hỏi rất thực dụng: requirement sẽ được elicited, analyzed, documented, prioritized, verified, validated, traced và changed như thế nào. Với team nhỏ, câu trả lời có thể nằm trong một trang. Với môi trường regulated hoặc nhiều vendor, ceremony có thể nhiều hơn. Điểm chính là vừa đủ với risk.
Một BA working plan đơn giản có thể như sau:
| Câu hỏi | Câu trả lời planning |
|---|---|
| Mình cần học gì? | Current process, pain points, decision rules, data ownership, nonfunctional constraints |
| Ai có thể dạy mình? | Users, managers, operations, support, compliance, engineering, downstream teams |
| Mình học bằng cách nào? | Observation, interviews, workshops, document analysis, prototype review |
| Khi nào là đủ? | Khi risk chính đã được gọi tên, options so được với nhau, và delivery slice tiếp theo đã rõ |
Stakeholder không chỉ là một cái tên trong list
Stakeholder register chỉ hữu ích nếu nó ghi nhiều hơn contact detail. Một BA cần hiểu attitude, influence, expertise, availability, location, complexity, decision rights và loại evidence mà mỗi stakeholder tin.
Ví dụ trong một project claims processing, head of operations quan tâm throughput, frontline agents quan tâm ít screen và ít rework hơn, compliance quan tâm auditability, finance quan tâm leakage, còn engineering quan tâm integration limit. Nếu BA gom tất cả thành một nhóm "business users", requirement sẽ gọn trên giấy và fail rất lặng.
RACI matrix có thể giúp, nhưng không nên biến thành decoration. Dùng nó để rõ ai responsible cho input, ai approve business rules, ai cần được consulted khi trade-off, và ai chỉ cần update. Giá trị ẩn không nằm ở cái bảng. Nó nằm ở cuộc nói chuyện hơi khó nhưng cần làm trước khi project bị áp lực.
Predictive và adaptive cần nhịp BA khác nhau
Lean BA không bắt mọi project phải Agile. Có việc cần upfront analysis nhiều hơn vì cost of change cao, process regulated, hoặc nhiều bên ngoài phải coordinate. Có việc lại cần learning cycle ngắn vì solution chưa chắc và user feedback quan trọng hơn completeness ban đầu.
| Context | Nhịp BA | Artifact thường gặp |
|---|---|---|
| Predictive project | Elicitation và baseline approval nhiều hơn từ đầu | BRD, requirements package, traceability matrix |
| Adaptive product work | Progressive elaboration trước từng slice | User stories, examples, prototypes, acceptance criteria |
| Hybrid program | Business outcome ổn định, solution detail tiến hóa | Roadmap, capability map, evolving backlog |
Sai lầm là giả vờ một nhịp phù hợp với mọi nơi. Team làm banking regulatory report có thể cần traceability và approval rõ hơn team đang test một onboarding experiment. Nhưng cả hai vẫn cần cùng một discipline: hiểu đủ, quyết định trung thực, và giữ learning visible.
Elicitation không phải ghi order
File tư liệu phân biệt khá hay giữa gathering và eliciting. Gathering nghe như requirement đã nằm đâu đó, BA chỉ cần đi nhặt về. Elicitation nhìn thực tế hơn: sự thật phân tán, chưa đầy đủ, đôi khi mâu thuẫn, và nhiều thứ nằm trong thói quen chứ không nằm trong lời nói.
Vì vậy elicitation tốt bắt đầu trước buổi interview. BA xác định objective, stakeholders, sequencing, questions, artifact cần đọc và output format. Workshop không có decision rõ sẽ sinh noise. Interview không có context có thể thành buổi than phiền. Survey gửi quá sớm có thể đóng băng assumption nông thành con số.
Cách đặt câu hỏi quan trọng. Open question mở context: "Lần gần nhất việc này fail, anh/chị đi qua những bước nào?" Closed question xác nhận fact: "Refund trên 500 dollars có luôn cần manager approval không?" Context-free question giảm solution bias: "Điều gì làm process này không thể chấp nhận, kể cả khi screen chạy nhanh hơn?" Why question giúp tìm cause, nhưng hỏi why vụng có thể làm người nghe phải phòng thủ.
Chọn technique theo điều cần học
Không có elicitation technique nào tự động trưởng thành. Technique phải khớp với uncertainty.
- Dùng document analysis khi policy, contract, report hoặc procedure hiện có đang định hình công việc.
- Dùng observation khi người làm không dễ giải thích vì công việc đã thành thói quen.
- Dùng interview khi cần chiều sâu, nuance hoặc context nhạy cảm.
- Dùng workshop khi decision đi qua nhiều role và disagreement cần được nhìn thấy cùng lúc.
- Dùng survey khi cần breadth sau khi topic đã đủ rõ.
- Dùng prototype khi người dùng cần thấy thứ gì đó trước khi nói được còn thiếu gì.
- Dùng interface analysis khi data đi qua system boundary và assumption ẩn trong handoff.
Ví dụ: warehouse team nói muốn "ít click hơn". Observation có thể cho thấy vấn đề lớn hơn không phải số click mà là quãng đường đi bộ, scanner latency và exception handling. Prototype một mình sẽ bỏ lỡ chuyện đó. Ngược lại, nếu compliance yêu cầu "full audit trail", document analysis và rule workshop có thể quan trọng hơn user interview.
Một operating rhythm nhỏ
Với nhiều team, một cadence BA nhẹ là đủ:
- Map stakeholders và gọi tên decision họ own.
- Chạy elicitation nhỏ nhất có thể giảm risk kế tiếp.
- Biến findings thành model, example hoặc story thật nhanh.
- Review với người dùng, người approve, người build, người test và người vận hành change.
- Giữ assumptions visible cho tới khi chúng được chứng minh hoặc được chấp nhận có chủ ý.
Planning không xóa uncertainty. Nó giúp team gặp uncertainty theo một thứ tự tốt hơn.