Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Bảy loại dự án IT mà BA hay gặp, mỗi loại BA làm gì khác nhau, và loại nào thường rơi vào tay người mới.
Hai người cùng chức danh Business Analyst, cùng một công ty.
Một người sáng nào cũng ngồi với giám đốc kinh doanh để vẽ ra một sản phẩm chưa tồn tại. Người kia mở Jira, đọc mô tả lỗi từ tổng đài, dựng lại tình huống rồi viết cho dev một mô tả đủ rõ để họ sửa.
Cả hai đều đang làm đúng việc của BA. Khác nhau ở loại dự án họ đang đứng.
Đây là chỗ người mới hay hụt. Đọc mô tả nghề BA thì thấy toàn "khơi gợi yêu cầu", "phân tích nghiệp vụ", "làm việc với stakeholder" — nghe như mọi BA đều làm một việc giống nhau.
Nhưng công việc thật của bạn từ 9 giờ sáng đến 6 giờ chiều phụ thuộc rất nhiều vào chuyện dự án bạn được xếp vào thuộc loại gì. Bài này điểm qua các loại dự án IT mà BA hay gặp: mỗi loại BA làm gì, và loại nào thường rơi vào tay người mới.
Trước khi vào danh sách, tách bạch nhanh ba thứ hay bị trộn:
Ba trục này độc lập. Một dự án chuyển dữ liệu có thể chạy Waterfall ở công ty outsourcing, cũng có thể chạy Scrum ở công ty product.
Nên đừng chọn nơi làm việc chỉ vì nghĩ ở đó sẽ được làm một loại dự án cụ thể.
Thêm một chú ý nữa: bảy loại dưới đây không phải bảng phân loại chuẩn quốc tế nào cả. Chúng chồng lên nhau, và một dự án thật có khi thuộc hai ba loại cùng lúc — lát nữa sẽ có ví dụ.
Để dễ theo dõi, cả bài dùng chung một ví dụ: một chuỗi cửa hàng đồ gia dụng có 9 chi nhánh, lâu nay chỉ bán tại quầy, giờ muốn bán online.
Chưa có gì cả. Có một ý tưởng, một mục tiêu kinh doanh, và một khoản ngân sách.
Đây là loại dự án mà BA được tham gia sớm nhất và cũng mông lung nhất. Chưa có hệ thống để mở ra xem, chưa có người dùng để hỏi "anh chị đang làm thế nào". Nguyên liệu duy nhất là các cuộc trò chuyện.
Bạn ngồi với ban giám đốc để hiểu họ muốn gì, ngồi với sales và marketing để biết khách hàng hiện tại là ai, rồi từ mớ mong muốn đó rút ra được phạm vi cho phiên bản đầu tiên.
Phần khó nhất không nằm ở chỗ thu thập yêu cầu. Nó nằm ở chỗ cắt.
Nói cho rõ, người cắt không phải bạn. Fresher không có cửa gạt tên tính năng của giám đốc kinh doanh, và cũng đừng bước vào phòng họp với tâm thế đó.
Ở dự án kiểu này bạn thường đi họp cùng PM hoặc một BA senior. Phần việc thật của bạn gọn hơn nhiều:
Các sếp nhìn con số rồi tự cãi nhau và tự cắt. Bạn chỉ cần lo sao cho con số đó không thiếu cái gì.
Chuỗi đồ gia dụng bắt đầu ở đây: dựng website bán hàng trên nền Magento, từ con số không. Những câu BA phải đi hỏi cho ra:
Hệ thống đã sống, đã có người dùng thật, đã có dữ liệu thật. Giờ thêm một mảnh vào.
Đây là nhóm việc bạn sẽ gặp nhiều nhất nếu làm BA cho một sản phẩm đang vận hành. Yêu cầu đến từ phản hồi người dùng, từ số liệu, hoặc từ một phòng ban nào đó phát hiện họ đang làm tay một việc lẽ ra máy làm được.
Khác biệt lớn nhất so với loại 1: bạn không được thiết kế trên giấy trắng. Mọi thứ bạn thêm phải sống chung với những gì đã có.
Nên bên cạnh việc làm rõ tính năng mới, BA còn một phần việc nữa là phân tích tác động — cái này đụng vào màn hình nào, báo cáo nào đang đếm theo trường dữ liệu sắp đổi, người dùng đang quen thao tác kiểu gì.
Việc được đặt lên bàn sau khi website chạy được vài tháng: thêm chức năng "Danh sách yêu thích" cho khách. Nghe đơn giản, cho tới lúc ngồi xuống hỏi kỹ:
Riêng câu cuối, nếu trả lời là có thì đây không còn là tính năng nhỏ nữa — nó kéo theo cả phần email marketing.
Không ai hỏi mấy câu đó ở đầu thì đến vòng test sẽ có người hỏi. Thường là bạn tester, và thường là vào chiều thứ sáu.
Trọng tâm ở đây là sửa lỗi, xử lý chỗ chậm, vá bảo mật, cập nhật cho tương thích — thay vì làm một tính năng kinh doanh mới. Vẫn có những cải tiến nhỏ lọt vào nhóm việc này, nhưng chúng không phải lý do dự án tồn tại.
Có một hiểu lầm cần gỡ trước. Bảo trì không phải việc nghe khách than rồi gõ lại nguyên văn cho dev.
"Không đặt hàng được" — dev đọc câu đó thì chẳng làm được gì.
Việc của bạn là lọc dữ liệu, đóng vai người dùng, thử tới thử lui cho ra quy luật: lỗi xảy ra với mọi đơn, hay chỉ những đơn giao tới một địa chỉ vừa đổi tên đơn vị hành chính?
Mức độ tham gia của BA thì co giãn mạnh theo môi trường.
Ở công ty product, có những tuần dev đọc log rồi tự sửa, BA gần như không đụng vào. Nhưng ở các hợp đồng bảo trì dài hạn bên outsourcing — thường gọi là AMS — thì đây là một vị trí BA toàn thời gian, có SLA, có phân loại mức độ nghiêm trọng, và BA là người chịu trách nhiệm truy nguyên nhân rồi viết yêu cầu cho từng ticket.
Cùng một loại dự án, hai mức độ hoàn toàn khác.
Việc nặng nhất trong nhóm này là nâng nền tảng. Website của chuỗi cửa hàng chạy trên Magento 1, mà Magento 1 đã kết thúc hỗ trợ, gồm cả bản vá bảo mật, từ 30/06/2020.
Chạy tiếp bản cũ không phải là không thể, chỉ là doanh nghiệp tự gánh rủi ro bảo mật và tự lo tiền vá.
Nói tiếp chuyện Magento một chút, vì nó là ví dụ đẹp cho cái ý "bảy loại chồng lên nhau" ở đầu bài.
Adobe không gọi việc đi từ Magento 1 sang Magento 2 là nâng cấp. Họ gọi là migration — phải dựng lại rồi chuyển dữ liệu sang, chứ không nâng phiên bản tại chỗ được. Cùng một việc, xếp vào mục 3 cũng đúng mà xếp vào mục 4 cũng đúng.
Còn định nghĩa của mục này thì gọn: dữ liệu đang nằm rải rác hoặc nằm ở hệ thống cũ, cần gom về một chỗ mới rồi tắt cái cũ đi.
Việc chính của BA ở đây là ánh xạ (mapping): trường nào ở nguồn tương ứng với trường nào ở đích, và những trường không tương ứng thì xử lý ra sao.
Cơ học là phần nhìn thấy được. Phần khó nuốt là ý nghĩa nghiệp vụ đằng sau mỗi trường, và nó gần như luôn lệch giữa hai hệ thống.
Bài toán này rơi xuống chuỗi cửa hàng khi họ gom dữ liệu khách hàng của 9 chi nhánh — mỗi nơi một phần mềm bán tại quầy, có nơi còn để trong Excel — về một cơ sở dữ liệu chung cho cả online lẫn offline.
Bảng mapping trên thực tế trông đại khái thế này:
Trường ở nguồn | Trường ở đích | Quy tắc chuyển đổi |
|---|---|---|
| Nhóm khách hàng | 1 → Khách lẻ, 2 → Khách sỉ, 3 → Nội bộ |
| Tỉnh/TP · Phường-Xã · Địa chỉ chi tiết | Tách bằng script, giữ lại chuỗi gốc để đối soát; ô nào tách không ra thì đội vận hành sửa tay |
Điểm tích luỹ | (không có) | Chưa quyết. Đang chờ marketing chốt |
Dòng địa chỉ là chuyện thời sự ở Việt Nam lúc này. Từ 01/07/2025 cả nước chuyển sang chính quyền địa phương hai cấp, cấp huyện kết thúc hoạt động, và phần lớn xã phường là đơn vị mới sau sắp xếp.
Dữ liệu khách hàng gom về đang lưu theo quận huyện cũ thì tách kiểu gì? Tách xong có khớp danh mục hành chính mới không? Có nên giữ lại trường quận/huyện để đối chiếu dữ liệu cũ không?
Đó là việc của BA, không phải của người viết script.
Dòng cuối bảng mới là thứ khiến loại dự án này khó. Hệ thống mới không có chỗ chứa điểm tích luỹ, mà khách thì đang có điểm thật.
Dev không trả lời hộ bạn được, và bạn cũng tuyệt đối không tự quyết. Việc của BA là gọi marketing với CSKH ngồi lại rồi bày vấn đề ra cho họ chốt: quy đổi điểm thành voucher trước khi chuyển, hay dừng hẳn chương trình tích điểm và thông báo cho khách trước bao nhiêu ngày?
Hai phần mềm đang chạy riêng, giờ cần trao đổi dữ liệu — thường qua API, đôi khi qua file đẩy theo giờ hoặc qua hàng đợi tin nhắn.
API, hàng đợi tin nhắn — nghe kỹ thuật, nhưng câu hỏi BA phải trả lời lại rất đời thường: thông tin gì cần qua lại, qua vào lúc nào, và khi đường truyền hỏng thì ai là người biết trước.
Ở chuỗi cửa hàng, việc cụ thể là nối website với một hãng vận chuyển để đơn tự đẩy sang, khỏi nhập tay.
Đẩy sang bên vận chuyển: tên người nhận, số điện thoại, địa chỉ, danh sách hàng, khối lượng, tiền thu hộ.
Nhận về: mã vận đơn, trạng thái giao hàng, lý do nếu thất bại.
Tên trường và danh sách trạng thái cụ thể thì phải theo tài liệu API của từng hãng, không có chuẩn chung.
Đó là phần dễ. Phần khó là những câu không hỏi thì đến lúc chạy thật mới lòi ra:
Câu thứ ba là cái bẫy quen thuộc của dự án tích hợp. Vẽ luồng chạy đúng thì ai cũng vẽ được, luồng chạy sai mới là chỗ hay bị bỏ quên trong buổi họp đầu tiên.
Bạn cũng không phải người tự nghĩ ra đáp án cho ba câu đó. Việc của BA là hỏi cho ra:
Rồi viết câu trả lời vào tài liệu để đội làm không phải đoán.
Loại này phục vụ chính nhân viên trong công ty. Một trang tra cứu, một script chạy đêm, một bảng tính được thay bằng phần mềm thật.
Điểm hay với người mới: người dùng ngồi ngay tầng dưới. Bạn hỏi được trực tiếp, quan sát được họ làm thật, và sửa sai nhanh.
Nhưng đừng mặc định là rủi ro thấp. Một công cụ nội bộ chạm vào giá, tồn kho hay dữ liệu khách hàng thì sai một cái là khách thấy ngay. Rủi ro nằm ở chỗ công cụ đó đụng vào cái gì, không nằm ở chỗ ai dùng nó.
Phần việc của BA bắt đầu từ quy trình hiện tại chứ không phải từ phần mềm. Ngồi cạnh xem người ta làm, ghi lại từng bước, rồi chỉ ra bước nào máy làm thay được, bước nào phải giữ cho người quyết định.
Bộ phận chăm sóc khách hàng của chuỗi cần một công cụ tra cứu đơn, để khỏi phải nhắn cho bạn kỹ thuật mỗi lần khách gọi lên hỏi.
Ngồi xem một bạn CSKH làm việc nửa buổi thì thấy ngay: họ tra theo số điện thoại chứ không phải mã đơn, vì khách gọi lên chẳng ai nhớ mã đơn cả.
Chi tiết đó không có trong bản mô tả yêu cầu mà trưởng bộ phận gửi sang.
Loại này ít được nhắc trong các bài giới thiệu nghề BA, nhưng ở Việt Nam thì rất nhiều việc: công ty không tự xây phần mềm mà mua một giải pháp đóng gói — ERP, CRM, phần mềm kho, phần mềm nhân sự — rồi cấu hình cho vừa với cách mình đang làm.
Việc của BA ở đây đảo ngược so với loại 1. Khách muốn gì thì mình làm nấy không còn đúng nữa.
Giờ là ngồi đối chiếu: phần mềm làm được những gì, doanh nghiệp cần những gì, chỗ nào khớp, chỗ nào lệch. Trong nghề thường gọi việc này là fit-gap analysis.
Chỗ lệch thì có mấy đường xử lý, thứ tự ưu tiên thông thường là:
Tuỳ chỉnh nhiều thì kiểm thử, bảo trì và nâng cấp đều đắt lên, và cái giá đó rơi vào công ty vài năm sau chứ không rơi vào dự án hiện tại.
BA không phải người quyết chọn đường nào. Chuyện đó thuộc về ban lãnh đạo và khách hàng, và thường dính cả yếu tố ngân sách lẫn ai có tiếng nói mạnh hơn trong công ty.
Phần của một người mới nhỏ hơn nhiều và cũng rõ hơn nhiều:
Đánh giá xem vài năm nữa nâng cấp có đau không thì để người đã đi qua vài lần nâng cấp làm.
Đến lượt chuỗi cửa hàng, đây là lúc họ mua một phần mềm quản lý kho dùng chung cho 9 chi nhánh thay vì tự viết.
Nhìn lại mục 1 thì thấy rõ hơn: cùng một chuỗi, cùng một nhu cầu, chọn tự dựng website thì thành loại 1, chọn một nền tảng bán hàng có sẵn như Shopify hay Haravan thì thành loại 7.
Không cần hỏi ai. Nhìn vào thứ người ta đưa cho bạn trong tuần đầu:
Còn một nhóm nữa không nằm gọn trong bảy loại trên: dự án sinh ra do quy định pháp luật, kiểu hoá đơn điện tử hay một thông tư mới bắt đổi cách báo cáo.
Nó có thể mang hình dạng của bất kỳ loại nào ở trên, nhưng có một đặc điểm riêng — hạn chót do luật định, không thương lượng, và không có chuyện cắt phạm vi cho kịp.
Bảng dưới đây là quan sát chung, không phải quy luật — mỗi công ty phân công một kiểu, tuỳ quy mô, tuỳ lĩnh vực, tuỳ đội bạn vào.
Loại dự án | Người mới hay được giao | Vì sao |
|---|---|---|
Xây mới từ đầu | Hiếm, mà nếu có thì làm cùng BA khác | Sai ở giai đoạn này thì cả dự án lệch theo |
Thêm tính năng | Thường xuyên | Phạm vi gọn, có hệ thống sẵn để đối chiếu |
Bảo trì, sửa lỗi | Thường xuyên | Vào việc được ngay, học hệ thống nhanh nhất |
Chuyển dữ liệu | Có, phần mapping | Việc chi li, đúng sai kiểm chứng được ngay |
Tích hợp | Ít khi làm chính | Cần hiểu cả hai hệ thống và các tình huống hỏng |
Công cụ nội bộ | Thường xuyên | Người dùng ngồi gần, vòng phản hồi ngắn |
Triển khai giải pháp có sẵn | Có, ở vai trò hỗ trợ | Học được nhiều nghiệp vụ chuẩn |
Nếu dự án đầu tiên của bạn là đi sửa bug và thêm mấy tính năng lặt vặt, đó không phải dấu hiệu bạn bị xếp ra rìa.
Đọc báo cáo lỗi vài tháng cho bạn hiểu một hệ thống hơn hẳn ngồi họp về một hệ thống còn chưa ra đời. Và người biết rõ hệ thống hiện tại thường là người được gọi khi có dự án lớn.
Bảy loại trên khác nhau ở nguyên liệu đầu vào và ở việc bạn dành thời gian cho ai. Bộ kỹ năng nền thì vẫn là một: hỏi cho ra vấn đề thật, phân tích, viết ra cho người khác hiểu đúng ý mình, và giữ được liên lạc tử tế với những người bạn cần thông tin từ họ.
Cái thay đổi là trọng số:
Bài tiếp theo nói về chuyện còn lại: bạn sẽ làm những dự án này ở đâu — công ty product hay công ty outsourcing, khác nhau thế nào, và hợp với kiểu người nào.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận