Mở đầu — vì sao bài này quan trọng
Nếu bạn đã làm Customer Service (CS) một thời gian, có một hệ thống mà bạn thuộc như lòng bàn tay: hệ thống ticket. Zendesk, Freshdesk, Jira Service Management, hay thậm chí là một sheet Google Sheets tự chế — mỗi ngày bạn mở nó ra, nhận ticket, phân loại, xử lý, đóng ticket. Bạn đã tạo ra hàng nghìn ticket trong sự nghiệp. Và đây là điều mà rất nhiều người từ CS chuyển sang BA không nhận ra: kỹ năng vận hành một ticket system chính là phiên bản sơ khai của Requirements Management — một trong những năng lực cốt lõi nhất của nghề Business Analyst.
Requirements Management (quản lý yêu cầu) là toàn bộ quá trình thu thập, ghi chép, phân loại, theo dõi, ưu tiên và kiểm soát thay đổi của các yêu cầu trong một dự án phần mềm. Nghe có vẻ xa lạ, nhưng nếu bạn bóc tách nó ra, bạn sẽ thấy bộ khung tư duy giống hệt cách bạn đã quản lý ticket suốt bao năm: mỗi ticket có ID, có trạng thái, có mức độ ưu tiên, có người phụ trách, có lịch sử thay đổi, và cần được truy vết từ lúc mở đến lúc đóng.
Bài học này sẽ giúp bạn nhìn thấy cây cầu nối giữa hai thế giới đó, và quan trọng hơn: biến kinh nghiệm ticket của bạn thành một lợi thế cạnh tranh khi phỏng vấn và làm việc như một BA. Chúng ta sẽ không nói về cách viết user story (đó là bài khác), cũng không đi sâu vào phân tích data ticket (bài khác nữa). Bài này tập trung đúng một việc: cách một hệ thống ticket vận hành, và cách chuyển hóa tư duy đó sang một hệ thống quản lý yêu cầu chuyên nghiệp.
Khái niệm cốt lõi
Ticket System và Requirements Management — hai anh em cùng gốc
Một ticket system, ở mức bản chất, là một hệ thống theo dõi vòng đời của "một đơn vị công việc". Đơn vị đó là ticket. Requirements Management cũng là hệ thống theo dõi vòng đời của "một đơn vị công việc" — nhưng đơn vị đó là requirement (yêu cầu).
Hãy nhìn vào bảng đối chiếu này, vì nó chính là nền tảng của cả bài:
| Trong Ticket System (CS) | Trong Requirements Management (BA) |
|---|---|
| Ticket ID (VD: #48210) | Requirement ID (VD: REQ-105, US-032) |
| Tiêu đề ticket | Requirement statement / User story title |
| Mô tả vấn đề khách hàng | Mô tả yêu cầu + acceptance criteria |
| Trạng thái (Open, Pending, Resolved, Closed) | Trạng thái (Proposed, Approved, In Dev, Verified, Deployed) |
| Mức ưu tiên (Low/Medium/High/Urgent) | Mức ưu tiên (MoSCoW: Must/Should/Could/Won't) |
| Người phụ trách (assignee) | Owner / Responsible stakeholder |
| Tag / Category | Category / Epic / Module |
| Lịch sử comment | Change log / Audit trail |
| SLA (thời gian phản hồi) | Delivery timeline / Sprint |
Traceability — trái tim của Requirements Management
Điểm khác biệt lớn nhất, và cũng là thứ mà một BA giỏi phải nắm chắc, là traceability (khả năng truy vết). Trong CS, khi bạn đóng một ticket, câu chuyện thường kết thúc ở đó. Nhưng trong BA, mỗi requirement phải được truy vết theo hai chiều:
- Truy vết ngược (backward): requirement này đến từ đâu? Từ nhu cầu kinh doanh nào? Ai đề xuất?
- Truy vết xuôi (forward): requirement này được hiện thực bằng design nào, code nào, test case nào? Nó đã được kiểm thử chưa?
Từ "phản ứng" sang "chủ động"
Có một chuyển dịch tư duy quan trọng ở đây. Ticket system về bản chất là reactive (phản ứng): khách hàng gặp vấn đề → tạo ticket → bạn xử lý. Requirements Management thiên về proactive (chủ động): bạn dự đoán, định nghĩa, và kiểm soát cái sẽ được xây dựng. BA không chỉ ghi lại "khách muốn gì", mà còn quản lý việc "yêu cầu đó thay đổi thế nào theo thời gian" — gọi là change control (kiểm soát thay đổi). Đây là năng lực mà bạn cần bồi đắp thêm.
Tình huống thực tế
Tình huống 1: Chị Lan tại Tiki — biến ticket trùng lặp thành backlog yêu cầu
Chị Lan là CS Team Lead tại một sàn thương mại điện tử lớn ở TP.HCM (bối cảnh tương tự Tiki). Mỗi tháng đội chị nhận khoảng 12.000 ticket. Khi được điều động hỗ trợ dự án nâng cấp tính năng "theo dõi đơn hàng", chị làm một việc rất BA mà không hề biết: chị export toàn bộ ticket 3 tháng gần nhất, lọc theo tag "tracking", và phát hiện 1.847 ticket đều xoay quanh cùng một nỗi đau — khách không biết đơn hàng đang ở khâu nào sau khi shipper nhận.
Thay vì coi đó là 1.847 vấn đề riêng lẻ (tư duy CS), chị gộp chúng thành một requirement duy nhất: "Là người mua, tôi muốn thấy trạng thái đơn hàng theo thời gian thực để không phải liên hệ CS." Chị đặt ID cho nó, gắn mức ưu tiên "Must have" (vì volume 1.847 ticket = chi phí vận hành rất lớn), và đính kèm 10 ticket tiêu biểu làm bằng chứng.
Bài học rút ra: Kỹ năng gom nhóm ticket trùng lặp của CS chính là kỹ năng requirement consolidation của BA. Volume ticket không chỉ là gánh nặng vận hành — nó là dữ liệu định lượng để bảo vệ mức ưu tiên của một yêu cầu trước ban lãnh đạo. Đây là lợi thế mà một BA thuần túy không có sẵn.
Tình huống 2: Anh Đức tại một fintech ở Singapore — khi thiếu traceability gây ra thảm họa
Anh Đức chuyển từ CS sang BA junior tại một công ty ví điện tử ở Đông Nam Á. Trong sprint đầu tiên, anh nhận yêu cầu "thêm giới hạn giao dịch 20 triệu/ngày cho tài khoản chưa xác thực". Theo thói quen CS cũ, anh ghi yêu cầu này vào một comment trong ticket Jira và coi như xong.
Ba tuần sau, khủng hoảng: bộ phận Compliance hỏi "ai duyệt con số 20 triệu, dựa trên quy định nào?" Không ai truy được. Yêu cầu bị thay đổi qua chat Slack thành 50 triệu mà không ai ghi lại lý do. Test team thì test theo con số 20 triệu cũ. Kết quả: một tuần làm lại, và một cuộc họp căng thẳng.
Sau sự cố, mentor của Đức bắt anh dựng một RTM đơn giản trên Confluence: mỗi requirement có nguồn gốc (link tới quy định của Ngân hàng Nhà nước), người duyệt, change log, và test case liên kết. Con số 50 triệu giờ có dấu vết rõ ràng: ai đổi, khi nào, vì sao.
Bài học rút ra: Trong CS, một ticket sai thì tối đa mất một khách. Trong BA, một requirement thiếu traceability có thể khiến cả team làm sai và gây rủi ro pháp lý. Đừng mang thói quen "ghi tạm vào comment" từ CS sang. Requirement phải có nguồn, có owner, có audit trail.
Tình huống 3: Chị Hương và việc dùng ngay Jira để làm cầu nối
Chị Hương làm CS tại một startup SaaS ở Hà Nội, đội dùng Jira Service Management cho ticket và Jira Software cho dev. Khi muốn thử sức BA, chị không chờ được cấp công cụ mới. Chị tận dụng chính Jira: tạo một project type "Requirements", dùng issue type "Story", tận dụng tính năng "link issues" để nối mỗi requirement với các service ticket gốc.
Chỉ sau 2 tháng, chị có một backlog 40 yêu cầu, mỗi cái đều truy được về ticket khách hàng thật. Khi phỏng vấn vị trí BA, chị cho nhà tuyển dụng xem đúng backlog này. Chị được nhận, và người phỏng vấn nói: "Em là ứng viên hiếm hoi cho tôi thấy requirement gắn với data khách hàng thật, chứ không phải requirement tưởng tượng."
Bài học rút ra: Bạn không cần công cụ đắt tiền hay chức danh mới để bắt đầu thực hành Requirements Management. Chính hệ thống ticket bạn đang dùng đã có đủ tính năng để tập. Và một portfolio requirement gắn với data thật là vũ khí phỏng vấn cực mạnh.
Hướng dẫn từng bước
Đây là quy trình 6 bước để bạn tự luyện tập chuyển từ tư duy ticket sang tư duy Requirements Management, ngay trên dữ liệu công việc hiện tại của bạn:
Bước 1 — Export và gom nhóm ticket. Lấy dữ liệu ticket 1–3 tháng gần nhất. Lọc theo tag/category. Với mỗi nhóm ticket lặp lại, hỏi: "Nỗi đau chung ở đây là gì?" Mỗi nỗi đau chung là một ứng viên requirement.
Bước 2 — Đặt định danh và viết requirement statement ngắn gọn. Cho mỗi requirement một ID (REQ-001, REQ-002...). Viết một câu mô tả nhu cầu ở góc độ giá trị kinh doanh, không phải góc độ giải pháp kỹ thuật.
Bước 3 — Gắn nguồn gốc (traceability ngược). Với mỗi requirement, đính kèm 3–10 ticket bằng chứng và ghi rõ: đến từ segment khách nào, volume bao nhiêu, ảnh hưởng doanh thu/chi phí ra sao.
Bước 4 — Ưu tiên hóa bằng MoSCoW. Phân loại Must / Should / Could / Won't. Dùng chính volume ticket và mức độ nghiêm trọng làm căn cứ — đây là thế mạnh dữ liệu của bạn.
Bước 5 — Định nghĩa vòng đời trạng thái. Thiết lập các trạng thái: Proposed → Approved → In Development → Testing → Done. Ánh xạ tư duy này từ vòng đời ticket (Open → Pending → Resolved → Closed) mà bạn đã quen.
Bước 6 — Thiết lập change log. Với mỗi requirement, tạo một khu vực ghi lại mọi thay đổi: ai đổi, ngày nào, lý do. Đây là bước mà CS thường bỏ qua nhưng BA bắt buộc phải có.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm requirement với giải pháp. Từ CS, bạn quen ghi "cần thêm nút X, popup Y". Nhưng đó là giải pháp, không phải requirement. Requirement là nhu cầu ("khách cần biết trạng thái đơn hàng"), giải pháp là cách đáp ứng ("hiển thị timeline"). Mẹo: luôn hỏi "tại sao khách cần cái này" thêm một lần nữa trước khi viết.
Lỗi 2 — Coi requirement là "đóng" như đóng ticket. Ticket đóng là xong. Requirement thì "sống" suốt dự án — nó thay đổi, bị gộp, bị tách. Mẹo: đừng bao giờ xóa, chỉ đổi trạng thái và ghi change log.
Lỗi 3 — Bỏ quên traceability. Ghi requirement vào chat, comment rồi quên nguồn. Mẹo: mỗi requirement phải trả lời được ba câu — đến từ đâu, ai chịu trách nhiệm, kiểm thử bằng gì.
Lỗi 4 — Ưu tiên hóa theo cảm tính. CS quen "khách nào la to thì ưu tiên". BA phải ưu tiên theo data + giá trị kinh doanh. Mẹo: dùng volume ticket + tác động chi phí làm bằng chứng khách quan.
Mẹo vàng: Hãy tận dụng chính công cụ ticket bạn đang có (Jira, Zendesk) để tập, đừng chờ công cụ chuyên dụng. Và luôn giữ lại các ticket gốc — chúng là "bằng chứng" biến requirement của bạn từ giả định thành sự thật có data.
Bài tập thực hành
Bài tập 1 — Xây RTM mini. Lấy 30 ticket thật (hoặc giả định) từ công việc của bạn. Gom thành tối đa 5 requirement. Với mỗi requirement, tạo một dòng RTM gồm: ID, requirement statement, nguồn (số ticket + volume), mức ưu tiên MoSCoW, trạng thái. Trình bày trên một bảng đơn giản (Google Sheets/Confluence).
Bài tập 2 — Vòng đời trạng thái. Vẽ sơ đồ trạng thái ticket của công ty bạn hiện tại, rồi vẽ song song sơ đồ trạng thái requirement tương ứng. Chỉ ra ba điểm giống và hai điểm khác biệt cốt lõi.
Bài tập 3 — Change control. Giả sử requirement "giới hạn giao dịch 20 triệu/ngày" bị đổi thành 50 triệu. Viết một change log entry đầy đủ: người đề xuất, người duyệt, lý do, ngày, và những test case nào cần cập nhật theo.
Tóm tắt
Bài học này cho bạn thấy một sự thật đầy khích lệ: bạn không bắt đầu từ con số 0. Kỹ năng vận hành ticket system — gom nhóm, phân loại, gán trạng thái, ưu tiên, theo dõi vòng đời — chính là nền móng của Requirements Management. Việc bạn cần làm là học một ngôn ngữ mới (requirement, RTM, MoSCoW, change control) và bồi đắp ba năng lực mà CS thường thiếu: traceability (truy vết hai chiều), change control (kiểm soát thay đổi), và tư duy proactive thay vì chỉ reactive.
Lợi thế độc nhất của bạn so với một BA thuần túy là: bạn có kho ticket thật làm bằng chứng. Mỗi requirement bạn đề xuất đều gắn với nỗi đau khách hàng có thật, có volume, có tác động đo lường được. Đó không phải requirement tưởng tượng — đó là requirement có dữ liệu. Hãy tận dụng ngay hôm nay: mở hệ thống ticket của bạn, gom nhóm, và viết requirement đầu tiên. Bạn đang bước những bước thật đầu tiên của một Business Analyst.