Mở đầu — vì sao bài này quan trọng
Nếu bạn đến từ nền tảng Sales/BD, có một nỗi sợ rất phổ biến mà tôi nghe đi nghe lại trong các buổi mentoring: "Em không học IT, em sợ vào BA là phải code, phải hiểu kỹ thuật, mà cái đó em mù tịt." Tôi muốn nói thẳng với bạn ngay từ đầu: BA không phải là một lập trình viên, và bạn không cần biết code để làm BA giỏi. Nhưng — và đây là chữ "nhưng" quan trọng — bạn cần đủ technical literacy (hiểu biết kỹ thuật nền tảng) để nói chuyện được với đội developer, hiểu được giới hạn của hệ thống, và làm việc trơn tru trong môi trường Agile mà gần như mọi công ty công nghệ ở Việt Nam đang áp dụng.
Hãy tưởng tượng như thế này: bạn không cần là đầu bếp để làm quản lý nhà hàng giỏi, nhưng bạn phải biết món nào nấu mất 5 phút, món nào mất 45 phút, bếp đang quá tải hay không, để hứa với khách một cách thực tế. Technical literacy của BA cũng vậy. Khi bạn còn làm Sales, bạn hứa với khách "tính năng này 2 tuần là có". Khi làm BA, nếu không hiểu kỹ thuật, bạn sẽ tiếp tục hứa kiểu đó — và đẩy đội dev vào tình huống cháy deadline triền miên.
Bài này tập trung duy nhất vào hai mảng: (1) technical literacy — bạn cần biết tech đến đâu là vừa đủ, và (2) Agile/Scrum — cách thức làm việc theo nhịp sprint mà bạn sẽ sống chung mỗi ngày. Tôi sẽ không dạy bạn viết user story hay BPMN ở đây (những bài sau sẽ làm điều đó); mục tiêu của bài này là gỡ bỏ nỗi sợ kỹ thuật và cho bạn một bản đồ tư duy về cách đội phát triển phần mềm vận hành.
Khái niệm cốt lõi
Technical literacy là gì và KHÔNG là gì
Technical literacy là khả năng hiểu và giao tiếp về công nghệ ở mức khái niệm, không phải khả năng tự xây dựng công nghệ đó. Một BA có technical literacy tốt sẽ biết:
- Hệ thống được chia thành frontend (phần người dùng nhìn thấy và tương tác — giao diện web, app) và backend (phần xử lý logic, lưu trữ phía sau).
- Dữ liệu được lưu trong database (cơ sở dữ liệu), và các hệ thống nói chuyện với nhau qua API (giao diện kết nối — hình dung như một người bồi bàn truyền yêu cầu giữa khách và bếp).
- Khi bạn muốn thêm một trường thông tin mới, nó có thể ảnh hưởng tới database, API, frontend cùng lúc — nên "thêm một ô nhập liệu nhỏ" đôi khi không hề nhỏ.
Vì sao ex-Sales lại có lợi thế "ngầm" về technical literacy
Nghe có vẻ nghịch lý, nhưng dân Sales/BD thường tiếp thu technical literacy nhanh hơn các bạn fresh graduate. Lý do: bạn đã quen với việc học vừa đủ để bán một sản phẩm phức tạp. Một Sales bán phần mềm ERP, bán giải pháp thanh toán, hay bán dịch vụ cloud đều đã phải nắm "sản phẩm này làm được gì, không làm được gì, tích hợp với hệ thống nào". Đó chính là technical literacy ở dạng thô. Việc của bạn bây giờ chỉ là chuyển nó từ "ngôn ngữ bán hàng" sang "ngôn ngữ xây dựng sản phẩm".
Agile và Scrum — nhịp đập của đội phát triển
Agile là một triết lý làm việc: thay vì xây toàn bộ sản phẩm trong 1 năm rồi mới giao (mô hình Waterfall cũ), Agile chia nhỏ thành các vòng lặp ngắn, làm ra phần dùng được, lấy phản hồi, rồi cải tiến. Scrum là cách triển khai Agile phổ biến nhất, vận hành theo sprint — chu kỳ thường kéo dài 2 tuần.
Trong Scrum có các vai trò và sự kiện chính bạn phải thuộc nằm lòng:
- Product Owner (PO): người quyết định làm gì trước, làm gì sau (ưu tiên backlog). Ở nhiều công ty VN, BA và PO gần như là một, hoặc BA là cánh tay phải của PO.
- Scrum Master: người gỡ vướng mắc, đảm bảo team chạy đúng quy trình.
- Development Team: các bạn dev, tester (QA).
- Backlog: danh sách tất cả việc cần làm, được xếp theo độ ưu tiên.
- Sprint Planning: họp đầu sprint để chốt sẽ làm gì trong 2 tuần tới.
- Daily Standup: họp nhanh 15 phút mỗi sáng — mỗi người nói "hôm qua làm gì, hôm nay làm gì, đang vướng gì".
- Sprint Review: cuối sprint, demo sản phẩm cho stakeholder.
- Retrospective: team nhìn lại để cải tiến cách làm việc.
Vai trò của BA trong vòng Scrum
BA không chỉ "viết tài liệu rồi biến mất". Trong Scrum, BA tham gia gần như mọi điểm chạm: chuẩn bị và làm rõ backlog trước Sprint Planning (gọi là backlog refinement), giải thích yêu cầu cho dev trong sprint, trả lời câu hỏi nghiệp vụ phát sinh, kiểm tra kết quả có đúng ý không, và hỗ trợ demo ở Sprint Review. Bạn là cầu nối giữa "khách hàng muốn gì" và "đội kỹ thuật xây gì".
Tình huống thực tế
Tình huống 1: Lời hứa "kiểu Sales" gặp tường kỹ thuật
Anh Minh, 31 tuổi, từng là BD Manager tại một công ty fintech ở TP.HCM, chuyển sang làm BA cho một ví điện tử (giả định gọi là PayGo). Trong tuần thứ hai, một đối tác lớn yêu cầu tính năng "cho phép khách hàng chia hóa đơn và thanh toán góp 3 kỳ không lãi suất". Theo phản xạ Sales cũ, anh Minh trả lời ngay với đối tác: "Tính năng này khoảng 1 sprint là xong, 2 tuần nha anh."
Khi đem vào Sprint Planning, tech lead lắc đầu: tính năng "trả góp" đụng tới hệ thống ghi nợ, đối soát với ngân hàng, xử lý hoàn tiền khi hủy, và tuân thủ quy định của Ngân hàng Nhà nước về tín dụng tiêu dùng. Ước tính thực tế là 3 tháng, chưa kể phần pháp lý.
Bài học: Trong Sales, bạn được thưởng vì sự tự tin và cam kết nhanh. Trong BA, technical literacy dạy bạn một thói quen mới: trước khi hứa, hỏi đội kỹ thuật. Anh Minh đáng lẽ nên nói với đối tác: "Đây là yêu cầu hay, để em làm rõ phạm vi và confirm timeline với team kỹ thuật trong 2 ngày." Câu này không làm bạn yếu thế — nó làm bạn đáng tin hơn, vì lời hứa của bạn sau đó luôn giữ được.
Tình huống 2: Hiểu API giúp BA "nói cùng ngôn ngữ" với dev
Chị Hương, ex-Sales tại một công ty SaaS quản lý bán hàng (giả định gọi là KiotViet-style), nhận yêu cầu tích hợp với một đơn vị vận chuyển (GHN). Ban đầu chị viết yêu cầu rất chung chung: "Hệ thống cần tự động tạo đơn giao hàng khi khách bấm xác nhận."
Sau khi học một buổi về API, chị hiểu rằng việc "tự động tạo đơn" thực chất là hệ thống của công ty gọi API của GHN, gửi đi các trường như địa chỉ người nhận, khối lượng, giá trị thu hộ (COD), rồi nhận lại mã vận đơn. Lần viết lại, chị hỏi đúng câu hỏi với dev: "API của GHN có hỗ trợ COD không? Nếu địa chỉ sai thì API trả lỗi gì, mình hiển thị cho user thế nào? Trường hợp GHN sập thì đơn hàng ở trạng thái nào?"
Bài học: Bạn không cần biết viết API. Nhưng khi hiểu API là "cuộc trao đổi gửi đi — nhận về giữa hai hệ thống", bạn lập tức nghĩ tới các tình huống lỗi, các trường dữ liệu cần thiết — những thứ mà nếu bỏ sót, dev sẽ phải quay lại hỏi bạn giữa sprint, làm chậm cả team. Technical literacy biến yêu cầu của bạn từ "mơ hồ" thành "đủ rõ để xây".
Tình huống 3: Sống cùng nhịp Sprint thay vì nhịp "deal"
Anh Tuấn quen với nhịp Sales: chốt deal là xong, chuyển sang deal mới, mọi thứ tính theo tháng và theo quý. Khi vào làm BA tại một startup logistics ở Hà Nội theo Scrum 2 tuần, anh bị "sốc nhịp". Anh hay mang vào giữa sprint những yêu cầu mới "khách vừa xin thêm cái này, làm luôn đi", khiến dev liên tục bị gián đoạn, sprint nào cũng vỡ kế hoạch.
Scrum Master phải ngồi lại giải thích nguyên tắc: trong sprint, phạm vi công việc được bảo vệ — yêu cầu mới sẽ được đưa vào backlog và cân nhắc cho sprint sau, trừ trường hợp khẩn cấp thật sự. Sau khi hiểu, anh Tuấn chuyển vai trò: thay vì "người mang việc đột xuất vào", anh thành "người gom yêu cầu mới, làm rõ, ưu tiên, và đưa vào Sprint Planning kế tiếp một cách có trật tự".
Bài học: Agile đòi hỏi bạn đổi từ tư duy "phản ứng tức thời" của Sales sang tư duy "nhịp điệu có kế hoạch". Đây không phải là làm chậm lại — mà là làm cho đội đi nhanh và bền hơn, vì không bị ngắt quãng liên tục.
Hướng dẫn từng bước
Đây là lộ trình thực tế để bạn xây technical literacy và làm chủ Agile trong khoảng 4–6 tuần, song song với công việc:
Bước 1 — Nắm bản đồ kiến trúc cơ bản (tuần 1). Học để hiểu, không phải để thi: frontend vs backend, database là gì, API là gì, "cloud" là gì. Một cách hay: chọn chính sản phẩm bạn từng bán, vẽ ra sơ đồ đơn giản "người dùng bấm nút → frontend gửi yêu cầu → backend xử lý → database lưu → trả kết quả". Vẽ tay cũng được.
Bước 2 — Học vốn từ kỹ thuật tối thiểu (tuần 1–2). Lập một bảng thuật ngữ riêng: API, endpoint, request/response, database, table, field/record, environment (dev/staging/production), bug, deploy, release. Mỗi từ ghi một câu giải thích bằng ngôn ngữ của bạn. Mục tiêu: ngồi họp với dev mà không bị "rớt nhịp" vì không hiểu họ nói gì.
Bước 3 — Đọc và hiểu một API doc đơn giản (tuần 2). Lên trang tài liệu API công khai của một dịch vụ Việt Nam (ví dụ tài liệu API của các cổng thanh toán như VNPay, MoMo, hoặc đơn vị vận chuyển GHN/GHTK). Bạn không cần gọi thử, chỉ cần đọc và trả lời: API này nhận vào những gì, trả ra những gì, có những trường hợp lỗi nào. Đây là kỹ năng vàng cho BA.
Bước 4 — Hiểu vòng đời Scrum bằng cách quan sát (tuần 3). Nếu đang đi làm, xin tham gia làm "người dự thính" trong một Daily Standup, một Sprint Planning, một Sprint Review. Quan sát: ai nói gì, quyết định gì được đưa ra, BA/PO đóng vai trò gì. Nếu chưa đi làm, xem các video mô phỏng sprint hoặc đọc Scrum Guide bản tiếng Việt (chỉ ~13 trang).
Bước 5 — Làm quen công cụ Agile (tuần 4). Tạo tài khoản Jira hoặc Trello miễn phí, tự lập một bảng backlog cho một dự án giả định (ví dụ "app đặt lịch cắt tóc"). Tạo vài task, kéo qua các cột To Do → In Progress → Done, gắn nhãn ưu tiên. Cảm giác "chạm tay" này giúp bạn tự tin hơn nhiều so với chỉ đọc lý thuyết. (Bài 26 sẽ đi sâu vào workflow Jira + Confluence.)
Bước 6 — Tập thói quen "hỏi trước khi hứa" (liên tục). Mỗi khi có yêu cầu mới, thay vì ước lượng theo cảm tính kiểu Sales, hãy chốt mẫu câu: "Để mình làm rõ phạm vi và confirm với team kỹ thuật rồi phản hồi anh/chị." Biến nó thành phản xạ.
Lỗi thường gặp & mẹo
Lỗi 1 — Lao vào học code để "chứng minh bản thân". Như đã nói, đây là cái bẫy tốn thời gian. Bạn cần đọc hiểu khái niệm kỹ thuật, không cần viết code. Mẹo: dành thời gian học SQL ở mức truy vấn cơ bản (bài 19 sẽ dạy) thì hữu ích hơn nhiều so với học một ngôn ngữ lập trình.
Lỗi 2 — Ước lượng timeline thay cho dev. BA không phải người ước tính khối lượng kỹ thuật. Việc của bạn là làm rõ cái gì cần làm, còn mất bao lâu là do dev ước lượng (story point — bài 45 sẽ bàn). Đừng vô tình "bán" deadline mà team không cam kết.
Lỗi 3 — Coi thường Daily Standup hoặc nói quá dài. Standup là 15 phút, không phải buổi báo cáo. Dân Sales hay có thói quen "trình bày", dễ biến standup thành độc thoại. Mẹo: chuẩn bị trước 3 ý ngắn gọn, đi thẳng vào vấn đề.
Lỗi 4 — Mang yêu cầu mới chen ngang giữa sprint. Tôn trọng phạm vi sprint. Mẹo: lập một "kênh chứa" — mọi yêu cầu phát sinh đều ghi vào backlog, và đem ra bàn ở buổi refinement hoặc planning kế tiếp.
Lỗi 5 — Dùng từ kỹ thuật sai để "ra vẻ". Dev nhận ra ngay khi bạn dùng sai thuật ngữ, và điều đó làm mất uy tín hơn là thẳng thắn nói "mình chưa rõ chỗ này, giải thích giúp mình". Mẹo: sự khiêm tốn ham học được dev quý hơn nhiều so với việc tỏ ra biết tuốt.
Mẹo vàng: Hãy biến mối quan hệ với dev thành "đối tác" chứ không phải "người giao việc". Kỹ năng xây dựng quan hệ vốn là sở trường của dân Sales — hãy dùng nó để thân thiết với team kỹ thuật. Một BA được dev yêu quý sẽ được giải thích cặn kẽ, được cảnh báo sớm về rủi ro, và làm việc nhẹ nhàng hơn rất nhiều.
Bài tập thực hành
- Vẽ bản đồ hệ thống: Chọn một sản phẩm bạn từng bán hoặc đang dùng (ví dụ app ngân hàng, app giao đồ ăn). Vẽ sơ đồ luồng đơn giản: người dùng thao tác → frontend → backend → database → trả kết quả. Chú thích mỗi phần bằng ngôn ngữ của bạn.
- Đọc một API doc thật: Truy cập tài liệu API công khai của một cổng thanh toán hoặc đơn vị vận chuyển VN. Viết ra: (a) API này dùng để làm gì, (b) cần gửi đi những trường thông tin nào, (c) ít nhất 2 trường hợp lỗi có thể xảy ra và cách bạn sẽ hiển thị cho người dùng.
- Mô phỏng một Sprint: Lập bảng Trello/Jira cho dự án giả định "app đặt lịch phòng gym". Tạo 8–10 task, gắn độ ưu tiên (Cao/Trung bình/Thấp), và sắp xếp xem 4 task nào nên đưa vào sprint đầu tiên. Viết 2–3 câu giải thích lý do bạn ưu tiên như vậy.
- Viết lại một lời hứa: Nhớ lại một lần bạn (hoặc đồng nghiệp) hứa với khách "tính năng này nhanh thôi". Viết lại câu đó theo phong cách BA có technical literacy: đặt 3 câu hỏi bạn cần hỏi đội kỹ thuật trước khi cam kết bất cứ điều gì.
Tóm tắt
Technical literacy của BA không phải là biết code — mà là hiểu đủ về cách hệ thống vận hành (frontend, backend, database, API) để giao tiếp trôi chảy với đội kỹ thuật và đưa ra yêu cầu đủ rõ ràng để xây dựng được. Là người đến từ Sales/BD, bạn đã có sẵn nền tảng "học vừa đủ để bán sản phẩm phức tạp"; việc của bạn là chuyển nó sang ngôn ngữ xây dựng sản phẩm.
Song song đó, Agile/Scrum là nhịp đập bạn sẽ sống chung mỗi ngày: sprint 2 tuần, các sự kiện Planning – Standup – Review – Retrospective, và vai trò BA như cầu nối xuyên suốt vòng lặp. Thử thách lớn nhất với ex-Sales là chuyển từ tư duy "phản ứng tức thời, hứa nhanh, chen việc" sang tư duy "nhịp điệu có kế hoạch, hỏi trước khi hứa, bảo vệ phạm vi sprint".
Ba điều cần nhớ nhất: (1) đừng lao vào học code — học hiểu khái niệm và SQL cơ bản là đủ; (2) đừng ước lượng timeline thay dev — hãy làm rõ "cái gì", để dev lo "bao lâu"; (3) hãy dùng sở trường xây dựng quan hệ của dân Sales để biến đội kỹ thuật thành đối tác thân thiết. Khi bạn làm được ba điều đó, nỗi sợ "không biết tech" sẽ tan biến, và bạn sẽ nhận ra mình không hề thua kém — thậm chí còn có lợi thế giao tiếp mà nhiều BA thuần kỹ thuật phải ao ước.