D-Bài 14 — Từ requirements engineering sang BA full-stack

Mở đầu — vì sao bài này quan trọng

Nếu bạn đến từ nền developer, có một sự thật ít người nói thẳng với bạn: bạn đã làm Requirements Engineering (RE) nhiều năm rồi mà không gọi nó bằng cái tên đó. Mỗi lần bạn đọc một cái ticket, hỏi lại PM "khi user chưa đăng nhập thì hiện gì?", viết acceptance criteria trong mô tả pull request, hay map một dòng yêu cầu sang đoạn code và unit test — đó chính là RE đang diễn ra trong đầu bạn. Vấn đề không phải là bạn thiếu kỹ năng, mà là bạn đang nhìn RE qua một lỗ kim: chỉ phần "biến yêu cầu đã rõ ràng thành phần mềm chạy được".

Bài này có một nhiệm vụ rất cụ thể và rất hẹp: giúp bạn nhìn thấy bức tranh đầy đủ của vai trò BA, lấy chính những mảnh RE bạn đã thành thạo làm điểm tựa, rồi chỉ ra những mảnh còn thiếu mà bạn cần lắp vào để trở thành một "BA full-stack" — nghĩa là một BA bao quát toàn bộ vòng đời yêu cầu, từ lúc nó còn là một câu nói mơ hồ của khách hàng cho tới lúc nó trở thành giá trị kinh doanh được đo lường.

Tôi gọi đây là khoảnh khắc "phóng to bản đồ". Trước đây bạn đứng ở một quận và nghĩ đó là cả thành phố. Giờ chúng ta zoom out để bạn thấy mình đang ở đâu, và những vùng đất nào bạn chưa từng đặt chân tới.

Khái niệm cốt lõi

Requirements Engineering — phần bạn đã biết

RE trong giáo trình kinh điển (Sommerville, IEEE 29148) gồm bốn hoạt động: elicitation (khai thác), analysis (phân tích), specification (đặc tả), và validation (kiểm chứng). Là developer, bạn đã chạm vào ba trong số đó một cách tự nhiên:

• Specification: Bạn viết user story, vẽ use case, liệt kê acceptance criteria (AC). Bạn biết một AC tốt phải kiểm chứng được — "hệ thống phản hồi dưới 2 giây" tốt hơn "hệ thống phải nhanh".
• Analysis (một phần): Bạn phát hiện mâu thuẫn trong yêu cầu vì bạn là người phải code nó. Khi spec nói "cho phép sửa đơn hàng" nhưng chỗ khác nói "đơn đã thanh toán thì khóa", chính bạn là người la lên.
• Traceability (truy vết): Đây là siêu năng lực ngầm của dev. Bạn quen với việc một requirement phải nối được tới một commit, một dòng code, một test case. Tư duy "requirement → code → test" này là vàng ròng, và phần lớn BA thuần nghiệp vụ lại rất yếu ở đây.

Bạn cũng quen công cụ: Jira để quản lý backlog, Confluence để viết tài liệu, Git để truy vết thay đổi. Đây là bộ công cụ mà nhiều BA mới phải học từ đầu, còn bạn đã dùng hàng ngày.

BA full-stack — bức tranh đầy đủ

Hãy hình dung vòng đời một yêu cầu như một dòng sông chảy qua sáu khúc. RE mà bạn biết chỉ là khúc giữa. BA full-stack đi cùng yêu cầu từ thượng nguồn tới hạ lưu:

• Business need (thượng nguồn) — Vì sao doanh nghiệp cần cái này? Mục tiêu kinh doanh, vấn đề thật sự đằng sau lời đề nghị. Đây là khúc dev hiếm khi được tham gia.
• Elicitation — Khai thác yêu cầu từ stakeholder bằng phỏng vấn, workshop, quan sát. Không phải nhận ticket, mà là chủ động đi đào.
• Analysis & modeling — Phân tích, mô hình hóa nghiệp vụ (process, data, rule), phát hiện gap, đề xuất giải pháp.
• Specification — Đặc tả yêu cầu (phần bạn mạnh).
• Validation & solution support — Cùng QA, dev, UAT để đảm bảo giải pháp đúng với yêu cầu.
• Value realization (hạ lưu) — Sau go-live, yêu cầu này có tạo ra giá trị như kỳ vọng không? Đo bằng số liệu kinh doanh.

Sự khác biệt cốt lõi: dev tối ưu cho "build the thing right" (xây đúng cách), BA full-stack chịu trách nhiệm cả "build the right thing" (xây đúng thứ). Bạn từng nhận một spec rồi build hoàn hảo, nhưng ba tháng sau tính năng đó không ai dùng. Đó là một thất bại RE ở khúc thượng nguồn — khúc mà từ giờ bạn phải làm chủ.

Khoảng cách bạn cần lấp

Đặt cạnh nhau, đây là ba khoảng trống lớn nhất khi dev chuyển sang BA full-stack:

Lưu ý: bài này chỉ vẽ bản đồ tổng thể và chỉ ra các khoảng trống. Từng kỹ thuật cụ thể (9 kỹ thuật elicitation, MoSCoW, BPMN, INVEST…) sẽ được mổ xẻ ở các bài sau. Việc của bạn lúc này là nhìn thấy toàn cảnh để biết mỗi bài sau đang lấp vào chỗ nào.

Tình huống thực tế

Ví dụ 1 — Anh Tuấn, backend dev tại một fintech ở TP.HCM

Tuấn có 5 năm code backend cho một ví điện tử (giả định, quy mô ~2 triệu user). Khi được đề bạt lên BA cho dự án "tính năng chia hóa đơn nhóm", phản xạ đầu tiên của Tuấn là mở Confluence viết ngay 14 user story và vẽ sequence diagram. Anh giao cho team, và sau 6 tuần sprint, tính năng ra mắt.

Kết quả: tỷ lệ sử dụng chỉ 0,8% sau một tháng. Khi đào lại, hóa ra business need thật sự không phải "chia hóa đơn" mà là "giữ chân nhóm bạn trẻ hay đi ăn chung khỏi chuyển sang ví đối thủ". Một giải pháp đúng với need đó có thể đơn giản chỉ là "nhắc nợ tự động qua thông báo" — rẻ hơn nhiều và đúng tâm lý hơn.

Bài học: Tuấn đã làm xuất sắc khúc specification nhưng bỏ trắng khúc thượng nguồn. Anh biến mình thành một "máy dịch ticket sang story" thay vì một BA. Một câu hỏi "vấn đề kinh doanh thật sự ở đây là gì?" hỏi đúng người trước khi viết story đầu tiên đã có thể tiết kiệm 6 tuần.

Ví dụ 2 — Chị Linh, full-stack dev chuyển BA tại một công ty logistics

Linh được giao viết yêu cầu cho module "tối ưu tuyến giao hàng". Lợi thế dev của chị phát huy ngay ở traceability: chị lập một bảng truy vết trong Jira nối mỗi business requirement (ví dụ "giảm 15% quãng đường rỗng") xuống các functional requirement, rồi xuống test case UAT, rồi xuống chỉ số đo sau go-live.

Khi sếp hỏi "tính năng này có đáng tiền không?", Linh không trả lời cảm tính. Chị chỉ vào dashboard: quãng đường rỗng giảm 11% sau 2 tháng, tiết kiệm khoảng 320 triệu/tháng tiền xăng, so với mục tiêu 15%. Vì có traceability từ đầu, chị biết chính xác requirement nào chưa đạt và đề xuất tinh chỉnh thuật toán gom đơn.

Bài học: Đây là minh họa hoàn hảo cho việc dùng kỹ năng dev (traceability) để bao trùm cả khúc hạ lưu (value realization) mà BA thuần thường bỏ. Linh đã là BA full-stack ở chỗ này.

Ví dụ 3 — Một team tại startup edtech (Đông Nam Á)

Một startup edtech ở Singapore tuyển 3 cựu dev làm BA. Cả ba đều giỏi specification nhưng đều rớt ở elicitation: khi vào workshop với phòng marketing và phòng vận hành đang cãi nhau về luồng đăng ký khóa học, cả ba đều im lặng chờ "ai đó chốt yêu cầu" rồi mới về viết spec — đúng thói quen nhận ticket.

Sau hai sprint trễ deadline, công ty thuê một BA senior về kèm. Người này không giỏi kỹ thuật bằng họ, nhưng biết facilitate: đặt câu hỏi mở, vẽ AS-IS process lên bảng cho hai phòng cùng nhìn, biến cuộc cãi nhau thành một bản yêu cầu thống nhất trong 90 phút.

Bài học: Specification giỏi không cứu được bạn nếu yêu cầu đầu vào còn mâu thuẫn và chưa được khai thác. Elicitation và facilitation là khúc sông dev hay đánh giá thấp nhất, và là chỗ bạn cần đầu tư học nhiều nhất.

Hướng dẫn từng bước

Đây là quy trình để bạn "nâng cấp" từ RE-specialist sang BA full-stack trên một yêu cầu thực tế:

• Vẽ bản đồ sáu khúc cho dự án hiện tại của bạn. Lấy một tính năng bạn đang làm, kẻ sáu cột (business need → elicitation → analysis → specification → validation → value). Đánh dấu cột nào bạn đang chủ động, cột nào bạn đang bị động hoặc bỏ trắng. Bạn sẽ thấy mình "đậm" ở giữa, "nhạt" ở hai đầu.

• Luôn truy ngược lên thượng nguồn trước khi viết story. Trước câu hỏi "viết gì", hỏi "vì sao". Với mỗi yêu cầu, viết một câu duy nhất: "Doanh nghiệp cần điều này để ___, và sẽ thành công nếu ___." Nếu không điền được vế sau, bạn chưa nên viết spec.

• Chủ động elicit, đừng chờ ticket. Đặt lịch 30 phút với người dùng cuối hoặc stakeholder. Chuẩn bị 5 câu hỏi mở ("Hôm nay anh/chị làm việc này thế nào?", "Chỗ nào khó chịu nhất?"). Mục tiêu là đào ra need ẩn, không phải xác nhận giải pháp có sẵn.

• Tận dụng tài sản dev của bạn ở khúc giữa. Khi specification, dùng đúng thế mạnh: viết AC kiểm chứng được, vẽ diagram khi luồng phức tạp, và đặc biệt — lập bảng traceability ngay từ đầu. Một cột "Requirement ID → FR → Test case → Metric" trong Jira/Confluence là thứ làm BA của bạn khác biệt.

• Đi tới hạ lưu: gắn metric vào yêu cầu. Với mỗi business requirement, định nghĩa trước một chỉ số đo giá trị (số người dùng, thời gian xử lý, doanh thu, chi phí tiết kiệm). Đây là cách bạn đóng vòng lặp và chứng minh giá trị công việc của mình.

• Lặp lại bản đồ sáu khúc sau mỗi dự án để thấy các cột "nhạt" của bạn đậm dần lên theo thời gian.

Lỗi thường gặp & mẹo

Lỗi 1 — Solution-jumping (nhảy thẳng vào giải pháp). Phản xạ dev là nghe vấn đề liền nghĩ ngay tới cách code. BA full-stack phải kìm lại ở khúc thượng nguồn. Mẹo: tự đặt luật "ba câu why" trước khi cho phép mình nghĩ tới bất kỳ giải pháp kỹ thuật nào. (Bài 32 sẽ đào sâu cái bẫy này.)

Lỗi 2 — Coi specification là toàn bộ công việc BA. Đây là lỗi của Tuấn ở ví dụ 1. Specification chỉ là 1/6 dòng sông. Mẹo: dán bản đồ sáu khúc lên cạnh màn hình, mỗi yêu cầu tự hỏi "mình đang ở khúc nào, đã bỏ khúc nào".

Lỗi 3 — Bỏ rơi yêu cầu sau khi deploy. Dev quen "merge xong là hết việc". BA thì việc mới bắt đầu ở go-live. Mẹo: đặt một lịch review giá trị sau 30 và 90 ngày cho mỗi tính năng lớn.

Lỗi 4 — Lạm dụng ngôn ngữ kỹ thuật khi elicit. Khi phỏng vấn người làm nghiệp vụ, đừng hỏi "API này trả về gì". Họ không hiểu, và bạn sẽ moi ra yêu cầu sai. Mẹo: dịch mọi câu hỏi sang ngôn ngữ công việc của họ.

Mẹo tận dụng lợi thế: Traceability là vũ khí mạnh nhất bạn mang từ thế giới dev sang. Rất ít BA thuần nghiệp vụ làm được việc nối liền business need xuống tận test case và metric. Hãy biến nó thành thương hiệu cá nhân của bạn.

Bài tập thực hành

• Bản đồ sáu khúc. Chọn một tính năng bạn từng tham gia (khi còn là dev hoặc hiện tại). Kẻ sáu cột business need → elicitation → analysis → specification → validation → value. Với mỗi cột, viết 2–3 dòng: ai đã làm khúc đó, làm tốt không, có khoảng trống gì. Tự chấm điểm bản thân ở từng khúc trên thang 1–5.

• Truy ngược thượng nguồn. Lấy một user story bất kỳ trong backlog hiện tại và viết câu hoàn chỉnh: "Doanh nghiệp cần điều này để ___, sẽ thành công nếu ___." Nếu không điền nổi vế sau, ghi lại bạn cần hỏi ai để điền được.

• Bảng traceability mini. Lấy một business requirement, lập bảng 4 cột: Business Requirement → Functional Requirement → Test/UAT case → Metric đo giá trị. Điền đầy đủ một dòng từ thượng nguồn xuống hạ lưu. Đây là bản nháp đầu tiên của siêu năng lực BA của bạn.

• Phác kịch bản elicitation. Chuẩn bị 5 câu hỏi mở để phỏng vấn một stakeholder về tính năng ở bài tập 2 — toàn bộ bằng ngôn ngữ nghiệp vụ, không một thuật ngữ kỹ thuật nào.

Tóm tắt

Là dev, bạn đã sở hữu khúc giữa của dòng sông Requirements Engineering: specification chắc tay, biết viết AC kiểm chứng được, và đặc biệt là tư duy traceability mà nhiều BA thuần phải ghen tị. Đó là điểm tựa, không phải đích đến.

BA full-stack là người đi cùng yêu cầu qua cả sáu khúc: từ business need ở thượng nguồn — nơi bạn học hỏi "why" trước "how"; qua elicitation và facilitation — khúc bạn cần đầu tư nhiều nhất; tới value realization ở hạ lưu — nơi bạn chứng minh công việc của mình tạo ra tiền và giá trị thật.

Hãy nhớ ba câu chuyện: Tuấn build hoàn hảo nhưng sai thứ vì bỏ thượng nguồn; Linh chứng minh được giá trị nhờ kéo traceability xuống tận hạ lưu; ba cựu dev ở startup edtech vấp ngã vì coi nhẹ elicitation. Bản đồ sáu khúc là la bàn của bạn từ giờ. Các bài tiếp theo sẽ trao cho bạn từng công cụ cụ thể để làm chủ mỗi khúc — còn ngay bây giờ, việc của bạn là không bao giờ nhầm một khúc với cả dòng sông nữa.