thảo luận Sắp bỏ việc IT BA (Business Analyst), chia sẻ kinh nghiệm cho ae nào cần

JUchi đã nói:

Cả 2 đều là senior BA không kiêm nhiệm gì luôn. Mình và bạn mình đi theo hướng thông thạo kỹ năng của BA và nắm sâu về domain ngân hàng thôi.
Đi sâu vào mảng bank thực ra vẫn ít BA cứng lắm.

Nhấp để mở rộng...

JUchi đã nói:

4k là nhiều vl rồi thím muốn gì nữa... Lên cao rồi tăng được chút nào hay chút đó. Muốn cao vọt phải nhảy việc, mà nhảy việc thì rất rủi ro bị reset thời gian

Nhấp để mở rộng...

JUchi đã nói:

Thế thì thím luyện tiếng Anh mạnh vào rồi nhắm mấy cty ở top ấy.
Remote có CoverGo (3k5), KMS (3k), Fsoft (từ 2k5)

Nhấp để mở rộng...

JUchi đã nói:

Với mình là tìm được job remote, rồi mở rộng network để tìm các job freelance, sau đó pass cho junior (30%) hoặc middle (50%) là nhàn nhất. Mỗi ngày chỉ cần mất 1 tiếng review lại thôi.

Nhấp để mở rộng...

JUchi đã nói:

Học bất cứ ngành nào cũng làm BA được. Bác sĩ ra làm BA ầm ầm kìa

Nhấp để mở rộng...

JUchi đã nói:

Việc chắc chắn nhiều hơn do thị trường hồi phục, công việc nhiều hơn.
Nhưng cạnh tranh còn cao hơn vì việc tăng lên 2 thì số người nhảy vào tăng lên 10.
Khó hơn cũng là điều chắc chắn

Nhấp để mở rộng...

phammai16 đã nói:

Như title, mình làm IT BA đã x năm giờ chuẩn bị chuyển sang role khác. Kinh nghiệm BA vẫn còn kha khá nên muốn lên chia sẻ cho ae được tí nào hay tí đó trước khi kinh nghiệm out date Chủ yếu support ae mới vào nghề muốn hiểu rõ hơn các thứ, chứ ae làm lâu thì bỏ qua ha. Lưu ý trong bài m nói về IT BA thôi nhé

Phần 1. Sơ lược về mình

1. Background
Mình học ngành MIS của 1 trường kinh tế VN, ở trường học 1 nửa là kinh tế nửa còn lại là SQL, Code C, C++, Cấu trúc dữ liệu giải thuật, Toán rời rạc,.. nói chung là các môn cơ bản của ngành CS. Đồ án tốt nghiệp là build con web app --> Nhiều khi cũng k biết như này có gọi là có base IT ko nữa code thì ko rành như ae dev nhưng các thứ basic thì hiểu. English thì bình bình vì toàn làm cty VN cũng k cần dùng nhiều

2. Kinh nghiệm làm việc
Domain mình đã từng làm thì linh tinh mỗi thứ 1 ít: Kế toán, Kiểm toán, kho vận, chuyển phát, crm, sale, chứng khoán, khách sạn dịch vụ..
Các công ty đã trải nghiệm: Start up nhỏ mới mở, Công ty VN lâu đời (cty gia đình), Công ty nhà nước, Ngân hàng :> h đang yên vị ở cty nhà nước.
Môi trường: OS, product, triển khai

Phần 2. Các câu hỏi mà m hay gặp khi lượn qua các group BA:

1. BA là gì? BA làm gì hàng ngày?
Câu này thực ra không nhiều người hỏi lắm, nhưng mình thấy quan trọng nên đưa vào
Có thể nói cùng tittle BA nhưng job mỗi cty có đặc thù riêng, đòi hỏi bộ skill hơi hơi khác nhau. Bạn nên nắm được cơ bản trước khi jump vào các vị trí này kẻo lại vỡ mộng :>
Theo trải nghiệm của m thường có 3 loại BA chính theo loại cty:

- BA triển khai (nhân viên triển khai): thường làm trong các công ty triển khai ERP, triển khai giải pháp bán hàng cho khách,.. Đầu công việc của BA sẽ cực đa dạng, thường bắt đầu bằng việc support sale làm proposal cho khách để kéo hợp đồng về cty (có thể phải làm hoặc không, Sale k rõ detail thì BA và dev thường bị lôi vào cùng). Sau khi kí dc hợp đồng thì các bác sẽ chạy qua lấy đề bài chi tiết của KH --> map với giải pháp cty đang cung cấp xem thừa thiếu miếng nào, nói chung là tìm cách để tối đa được phần mềm theo yêu cầu của khách. Điều này đòi hỏi bạn phải cực vững về giải pháp bạn đang triển khai. Song song với đó là việc lấy dữ liệu cũ (nếu làm erp) , xử lý để import lên hệ thống sẽ chạy. Tưởng tưởng khách muốn có dữ liệu từ đầu 2022 trở đi trên hệ thống, mà tận t10/2022 mới ký hợp đồng triển khai thì các tháng thiếu cần xử lý thủ công ròi. Ngoài ra còn cần làm các bước cài cắm setup cho hệ thống chạy ổn định đúng với yêu cầu của khách (vd kế toán chạy thông tư 133 hay 200 thì cài đặt khác nhau). Xong xuôi ae sẽ qua training cho khách cách dùng hệ thống, có khi phải xuống tận nơi, đi công tác cả tuần --> điều mình ghét và bỏ nghề triển khai. Nói thiệt là job này nó cũng ko BA lắm, bù lại mới vào mà theo thì sẽ tiếp cận và hiểu nghiệp vụ rất nhanh và sâu sát. Career path có thể lên làm tư vấn chuyên nghiệp. Các bên kiểm toán cũng rất cần vị trí kiểu này. AE trái ngành kế kiểm qua job này cực phù hợp vì tận dụng được kiến thức nghiệp vụ :> Thường làm việc với các C level --> học hỏi dc nhiều tư duy các bác C.

- BA outsource: thường làm trong công ty OS. Nhiệm vụ là lấy đề bài từ phía khách hàng, confirm với khách, sau đó làm thành tài liệu rồi transfer cho ae dev --> Cần mạnh các skill về docs, mô hình hóa, giao tiếp,... ở đây cái dở là nhiều khi ae chỉ làm cầu nối thôi, bởi vậy nhiều bên cho test rồi dev trực tiếp connect với khách là vì vậy ko cần tới BA luôn. Làm bên này yêu cầu phải giỏi ngoại ngữ chút, làm lâu thì cũng nên góp gì đó thành tài sản cá nhân ví dụ như các kiến thức domain chẳng hạn. Được cái quy trình chuẩn chỉnh học hành bài bản, OS thì sẽ được tiếp cận đa dạng domain tha hồ trải nghiệm nhưng ko sâu như product được.

- BA product: như tên, các bác join vào làm BA cho 1 product nào đó. Mình thấy xu hướng hiện nay sẽ là PO kiêm BA có khi kiêm UX chỗ này luôn. Có 2 TH chính mình hay gặp. TH1 là các bạn chỉ nghe yêu cầu từ phía khách hàng (thường là sếp của các bạn) hoặc thậm chí k có tí yêu cầu nào cả, chỉ bâng quơ mấy câu kiểu "Anh cần thêm cái tính năng X trên con web nhà mình" ) Lúc này cần đi research, tìm hiểu xem tính năng X đó nên làm như nào, triển khai như nào cho hợp lý, demo sơ sơ mockup rồi đề xuất lại cho sếp --> Thiên về PO nhiều hơn. Cần nghĩ ra tính năng, hiểu về nghiệp vụ kĩ càng. TH2 là có khách hàng và đề bài tương đối clear, lúc đó thì khá giống BA OS rồi. Với BA product docs không phải là tất cả, nghiệp vụ đổi liên tục nên quá focus vào tài liệu sẽ mất thời gian. Để tiến xa khi làm product mình đánh giá cao các bạn hiểu nghiệp vụ và có tư duy của PO. Domain tốt có thể nhày việc theo ngành dọc, tức là nhảy cùng domain khác cty, ví dụ từ GHTK --> GHN --> VNPost, được trọng dụng hơn là nhảy linh tinh các domain

2. Có thể chuyển từ ngành XYZ qua IT BA không? Trái nghành có nên theo BA không?

==> Quan trọng nhất với BA là nắm nghiệp vụ vững, giải thích được gãy gọn cho dev cần làm gì, vì sao phải làm điều đó, đưua được lộ trình rõ ràng phase này làm A phase kia làm B để team follow theo (team có PO thì PO care chỗ này)
Quan trọng nữa là giao tiếp phải cực cực tốt với nhiều bên cả KH và team nội bộ, và hạn chế đổi requirement thôi, nhất là BA os. Đổi thì phải có lý do hợp lý. Chứ lấy đề bài về dev chán chê rồi lại thêm lại bớt, thì điều này thể hiện bạn là 1 BA còn non --> ae dev + test sẽ k tin bạn lắm, value của bạn trong team sẽ giảm nhiều :> Với khách bên ngoài thì m làm cho nhà nước mới thấy nhiều bên củ chuối, k chịu hợp tác. Luc này mà k cứng + bản lĩnh thì dự án k bao h trôi được. Cứng + bản lĩnh thì hoàn toàn là kĩ năng mềm rồi :>

• Nhiều case chuyển ngành BA thành công lương cao mình biết đều là do có domain trước đó rồi chuyển qua, có khi nhảy phát là 20- 30-40 cũng có. Hồi làm bank và chứng khoán, nhiều bạn ban đầu là dân chứng, đưa đề bài cho bọn mình làm product, sau đó tháy hợp nên move qua BA luôn, và làm rất tốt , làm BA đến tận giờ. BA lead chỗ mình hiện tại cũng k base IT gì cả nhưng tốt excel và nghiệp vụ cực đỉnh, vẫn lead ae như thường.
• Bởi vậy, nếu ae nhắm đáp ứng dc các cái đó thì BA thẳng tiến k cần lo gì đâu :> Kiến thức IT cho IT BA mỗi cty 1 khác. có cty m làm thì BA phải define được API structure, map được FE -API . Có công ty cần tốt excel, sql là được rồi. À basic về phần mềm thì vẫn nên có chứ mù tịt quá thì không được đâu

Dài quá, sơ sơ vậy. Ae hỏi gì thì post xem m có giúp được k nhé :>

Nhấp để mở rộng...

theasker01 đã nói:

Đi học đi bạn. Bạn có thể xem sách, tài liệu nhưng chỉ hiểu được mặt chữ. Học là học lấy tư duy làm sao phân tích và giải quyết vấn đề

Nhấp để mở rộng...

phammai16 đã nói:

Như title, mình làm IT BA đã x năm giờ chuẩn bị chuyển sang role khác. Kinh nghiệm BA vẫn còn kha khá nên muốn lên chia sẻ cho ae được tí nào hay tí đó trước khi kinh nghiệm out date Chủ yếu support ae mới vào nghề muốn hiểu rõ hơn các thứ, chứ ae làm lâu thì bỏ qua ha. Lưu ý trong bài m nói về IT BA thôi nhé

Phần 1. Sơ lược về mình

1. Background
Mình học ngành MIS của 1 trường kinh tế VN, ở trường học 1 nửa là kinh tế nửa còn lại là SQL, Code C, C++, Cấu trúc dữ liệu giải thuật, Toán rời rạc,.. nói chung là các môn cơ bản của ngành CS. Đồ án tốt nghiệp là build con web app --> Nhiều khi cũng k biết như này có gọi là có base IT ko nữa code thì ko rành như ae dev nhưng các thứ basic thì hiểu. English thì bình bình vì toàn làm cty VN cũng k cần dùng nhiều

2. Kinh nghiệm làm việc
Domain mình đã từng làm thì linh tinh mỗi thứ 1 ít: Kế toán, Kiểm toán, kho vận, chuyển phát, crm, sale, chứng khoán, khách sạn dịch vụ..
Các công ty đã trải nghiệm: Start up nhỏ mới mở, Công ty VN lâu đời (cty gia đình), Công ty nhà nước, Ngân hàng :> h đang yên vị ở cty nhà nước.
Môi trường: OS, product, triển khai

Phần 2. Các câu hỏi mà m hay gặp khi lượn qua các group BA:

1. BA là gì? BA làm gì hàng ngày?
Câu này thực ra không nhiều người hỏi lắm, nhưng mình thấy quan trọng nên đưa vào
Có thể nói cùng tittle BA nhưng job mỗi cty có đặc thù riêng, đòi hỏi bộ skill hơi hơi khác nhau. Bạn nên nắm được cơ bản trước khi jump vào các vị trí này kẻo lại vỡ mộng :>
Theo trải nghiệm của m thường có 3 loại BA chính theo loại cty:

- BA triển khai (nhân viên triển khai): thường làm trong các công ty triển khai ERP, triển khai giải pháp bán hàng cho khách,.. Đầu công việc của BA sẽ cực đa dạng, thường bắt đầu bằng việc support sale làm proposal cho khách để kéo hợp đồng về cty (có thể phải làm hoặc không, Sale k rõ detail thì BA và dev thường bị lôi vào cùng). Sau khi kí dc hợp đồng thì các bác sẽ chạy qua lấy đề bài chi tiết của KH --> map với giải pháp cty đang cung cấp xem thừa thiếu miếng nào, nói chung là tìm cách để tối đa được phần mềm theo yêu cầu của khách. Điều này đòi hỏi bạn phải cực vững về giải pháp bạn đang triển khai. Song song với đó là việc lấy dữ liệu cũ (nếu làm erp) , xử lý để import lên hệ thống sẽ chạy. Tưởng tưởng khách muốn có dữ liệu từ đầu 2022 trở đi trên hệ thống, mà tận t10/2022 mới ký hợp đồng triển khai thì các tháng thiếu cần xử lý thủ công ròi. Ngoài ra còn cần làm các bước cài cắm setup cho hệ thống chạy ổn định đúng với yêu cầu của khách (vd kế toán chạy thông tư 133 hay 200 thì cài đặt khác nhau). Xong xuôi ae sẽ qua training cho khách cách dùng hệ thống, có khi phải xuống tận nơi, đi công tác cả tuần --> điều mình ghét và bỏ nghề triển khai. Nói thiệt là job này nó cũng ko BA lắm, bù lại mới vào mà theo thì sẽ tiếp cận và hiểu nghiệp vụ rất nhanh và sâu sát. Career path có thể lên làm tư vấn chuyên nghiệp. Các bên kiểm toán cũng rất cần vị trí kiểu này. AE trái ngành kế kiểm qua job này cực phù hợp vì tận dụng được kiến thức nghiệp vụ :> Thường làm việc với các C level --> học hỏi dc nhiều tư duy các bác C.

- BA outsource: thường làm trong công ty OS. Nhiệm vụ là lấy đề bài từ phía khách hàng, confirm với khách, sau đó làm thành tài liệu rồi transfer cho ae dev --> Cần mạnh các skill về docs, mô hình hóa, giao tiếp,... ở đây cái dở là nhiều khi ae chỉ làm cầu nối thôi, bởi vậy nhiều bên cho test rồi dev trực tiếp connect với khách là vì vậy ko cần tới BA luôn. Làm bên này yêu cầu phải giỏi ngoại ngữ chút, làm lâu thì cũng nên góp gì đó thành tài sản cá nhân ví dụ như các kiến thức domain chẳng hạn. Được cái quy trình chuẩn chỉnh học hành bài bản, OS thì sẽ được tiếp cận đa dạng domain tha hồ trải nghiệm nhưng ko sâu như product được.

- BA product: như tên, các bác join vào làm BA cho 1 product nào đó. Mình thấy xu hướng hiện nay sẽ là PO kiêm BA có khi kiêm UX chỗ này luôn. Có 2 TH chính mình hay gặp. TH1 là các bạn chỉ nghe yêu cầu từ phía khách hàng (thường là sếp của các bạn) hoặc thậm chí k có tí yêu cầu nào cả, chỉ bâng quơ mấy câu kiểu "Anh cần thêm cái tính năng X trên con web nhà mình" ) Lúc này cần đi research, tìm hiểu xem tính năng X đó nên làm như nào, triển khai như nào cho hợp lý, demo sơ sơ mockup rồi đề xuất lại cho sếp --> Thiên về PO nhiều hơn. Cần nghĩ ra tính năng, hiểu về nghiệp vụ kĩ càng. TH2 là có khách hàng và đề bài tương đối clear, lúc đó thì khá giống BA OS rồi. Với BA product docs không phải là tất cả, nghiệp vụ đổi liên tục nên quá focus vào tài liệu sẽ mất thời gian. Để tiến xa khi làm product mình đánh giá cao các bạn hiểu nghiệp vụ và có tư duy của PO. Domain tốt có thể nhày việc theo ngành dọc, tức là nhảy cùng domain khác cty, ví dụ từ GHTK --> GHN --> VNPost, được trọng dụng hơn là nhảy linh tinh các domain

2. Có thể chuyển từ ngành XYZ qua IT BA không? Trái nghành có nên theo BA không?

==> Quan trọng nhất với BA là nắm nghiệp vụ vững, giải thích được gãy gọn cho dev cần làm gì, vì sao phải làm điều đó, đưua được lộ trình rõ ràng phase này làm A phase kia làm B để team follow theo (team có PO thì PO care chỗ này)
Quan trọng nữa là giao tiếp phải cực cực tốt với nhiều bên cả KH và team nội bộ, và hạn chế đổi requirement thôi, nhất là BA os. Đổi thì phải có lý do hợp lý. Chứ lấy đề bài về dev chán chê rồi lại thêm lại bớt, thì điều này thể hiện bạn là 1 BA còn non --> ae dev + test sẽ k tin bạn lắm, value của bạn trong team sẽ giảm nhiều :> Với khách bên ngoài thì m làm cho nhà nước mới thấy nhiều bên củ chuối, k chịu hợp tác. Luc này mà k cứng + bản lĩnh thì dự án k bao h trôi được. Cứng + bản lĩnh thì hoàn toàn là kĩ năng mềm rồi :>

• Nhiều case chuyển ngành BA thành công lương cao mình biết đều là do có domain trước đó rồi chuyển qua, có khi nhảy phát là 20- 30-40 cũng có. Hồi làm bank và chứng khoán, nhiều bạn ban đầu là dân chứng, đưa đề bài cho bọn mình làm product, sau đó tháy hợp nên move qua BA luôn, và làm rất tốt , làm BA đến tận giờ. BA lead chỗ mình hiện tại cũng k base IT gì cả nhưng tốt excel và nghiệp vụ cực đỉnh, vẫn lead ae như thường.
• Bởi vậy, nếu ae nhắm đáp ứng dc các cái đó thì BA thẳng tiến k cần lo gì đâu :> Kiến thức IT cho IT BA mỗi cty 1 khác. có cty m làm thì BA phải define được API structure, map được FE -API . Có công ty cần tốt excel, sql là được rồi. À basic về phần mềm thì vẫn nên có chứ mù tịt quá thì không được đâu

Dài quá, sơ sơ vậy. Ae hỏi gì thì post xem m có giúp được k nhé :>

Nhấp để mở rộng...

cuduke đã nói:

Hi bác. Nhờ bác tư vấn

Hiện tại ny em 25 tuổi tốt nghiệp ngành kế toán, đang làm giao dịch viên ngân hàng ( 2 năm kinh nghiệm) nma do không thích việc chạy số nên muốn đổi ngành. Em thì là dân dev nên có nói người yêu em thử học ITBA. Sau 1 tháng tự học thì em thấy ny cũng tiếp thu khá nhanh và sắp tới cũng đang dự định apply fresher BA.

Ở trên em có đọc thấy bác nói về BA về domain bank. Em đang thắc mắc với kn làm việc của ny em thì có được gọi là có lợi thế về domain bank hay không. Và bác có lời khuyên hay kinh nghiệm về việc nhảy việc từ giao dịch viên thành BA không ạ.

Nhấp để mở rộng...

Luc Lam đã nói:

Tôi gốc data, có cả exp DE lẫn DA nhưng còn thiếu nhiều về DS trong khi thực tế cũng đã có 1 vài cơ hội cho vị trí Head of Data (quản cả 3 team). Vì thế tôi có plan cho việc học cao học một ngành có liên quan đến DS và Finance, theo tham khảo từ những ace đi trước và cả tư vấn viên thì chương trình vốn dĩ rất nặng về toán đòi hỏi người học phải dành rất nhiều thời gian nghiên cứu và nó cũng không thiết kế cho người đi làm khi giờ học là giờ hành chính.

Vì vậy, tôi đã quyết định rời vị trí trước đó để chuẩn bị nhưng ngẫm cái cảnh đi làm lâu năm mà giờ về ôm cặp sách 2 năm thì cũng buồn. Thế mới hỏi mấy vị sếp cũ, anh có vị trí nào cho em làm từ xa được thì nhận được cái cơ hội bảo tao đang thiếu BA mày vào làm đi. Nghe cũng thú vị vì tôi chưa biết ngành này chính xác nó làm cái gì.

Thế là chiến thôi, tính đến giờ nom cũng được 06 tháng trải nghiệm. Tôi có 1 chút chia sẻ thực tế về vị trí này ở 1 công ty OS chuyên về lĩnh vực logistics cho các bạn nào mới và có ý định theo con đường này nhé: (phần nào nhiều người đề cập rồi thì tôi sẽ lướt qua nhé)

+ Ngành này tuyển nhiều nữ hơn nam? Ồ tôi không nghĩ thế, tỷ lệ dương thịnh âm suy ở công ty tôi chắc phải đến 80~90%, ngay cả dự án tôi vừa nhận thêm cũng có tới 3/3 BA là đực rựa.

+ Vì là OS nên projects rất nhiều, chỉ 6 tháng nhưng tôi được giao xử lý cùng lúc ít nhất 4 cái và có thể tăng thêm trong thời gian tới. Nên kỹ năng quản lý thời gian và biết ưu tiên cái nào trước sau sẽ rất quan trọng. Tính cách quyết đoán và dám chịu trách nhiệm là rất cần thiết, đặc biệt trong dự án mà khách hàng cũng chẳng biết chính xác nó cần cái gì, lúc này đợi chờ nhau thì dev đứng hết.

+ Domain ngành rất cần nhưng background IT cũng cần không kém, đặc biệt là có kinh nghiệm thực chiến chứ không phải là chỉ học ở trường là xong. Có dự án cần chuyển đổi nâng cấp hệ thống cũ được xây có khi từ thời ông bà hoặc đầu những năm 2000, tech lỗi thời - logic thì thôi loạn xạ dev comment đủ thứ trong đó với hàng tá trường hợp hardcode không document. Dự án đã to với hàng ngàn màn hình, table có khi còn chẳng set FK, partition gì toàn set trong code với chẳng procedure. Khách hàng thì feedback hệ thống chạy quá chậm chạp đòi hỏi hệ thống mới phải nhanh hơn v.v... Dù có Tech Lead đưa giải pháp nhưng hỏi thẳng Tech Lead cũng chưa chắc giải pháp đó là tốt nhất. Gặp dự án như này BA thuần business là phơi xác nhé.

+ Về designer thì figma cũng không quá khó, bạn nào hay vọc mấy trang như canvas thì làm quen nhanh thôi. Còn thực tế tôi cũng không dùng đến nó nhiều, nếu policy công ty cho phép thì kéo source của dev về không thì tạo môi trường tương tự nhét AI cho nó generate trực tiếp UI. Screen nào phức tạp thì tôi còn chuyển qua designer review UX còn simple thì tôi đẩy thẳng lên git cho dev pull về code cho nhanh.

+ Về user stories hay hàng tá document khác nó tùy dự án cần hay không, chủ yếu các bạn thu thập đủ ý xong đẩy thẳng vào AI, một ngày tôi ném 2~3 cái screen user stories là rất bình thường.

+ Về học thì cũng tốt đấy, nhưng tôi kém duyên. Do lần đó mới vào chân ướt chân ráo được 3 ngày thì sếp ném cho 1 cái project tự thân chèo với client bên USA, chẳng biết phải làm sao thì có thỉnh giáo 1 chị hơn 10 năm exp BA, cũng đứng lớp dạy ở 1 trung tâm đào tạo có tiếng ở HCM (tôi quên tên rồi), giờ làm PO cho một công ty khởi nghiệp của nước ngoài. Chị ấy phản hồi rằng giờ dạy gì cũng vô ích, mày vào trực tiếp làm luôn rồi thì tới đâu bí hỏi chị chỉ cho thôi. Tuy nhiên có 1 điểm chị ấy nói đúng, không phải dự án nào cũng sẽ cần bằng đó document như nhau nên đúng nghĩa học từ thực chiến rồi quay lại học trường lớp sẽ tốt hơn là ngược lại tránh học mà không ứng dụng thì cũng mau quên.

+ Về API rồi sâu vào Database v.v... thì tôi khuyên thật bạn hiểu đủ sâu thì hãy làm. Đừng vội nghĩ rằng mình có thể sử dụng query như SQL hay code 1 chút là mình đã có thể vẽ nó rồi, thực tế nó còn nhiều vấn đề rối rắm hơn đến từ trực tiếp engine của database được chọn như thế nào. Cách vận hành hệ thống khi truy vấn dữ liệu ra sao, phần này thì thường để Tech Lead / Architect nó chốt đi. Ngay cả dev thuần nhiều lúc còn chẳng nắm hết nói gì là BA không chuyên. Bạn viết mà Dev nó không dùng đến thì chỉ tổ mất thời gian, nó dùng đến rồi ngày sau impact đến performance hệ thống nó lại bảo do nó làm theo requirement của BA thì lại vỡ mồm.

+ Về lương lậu thì ngành nào cũng sẽ có cao thấp, mức lương tầm 5x 6x DE DA DS đầy. BA cũng thế, như công ty hiện tại senior BA cũng 5x. Nó còn cả level cao hơn là principal thì level đấy 7~8x hay cao hơn nữa cũng là chuyện bình thường.

+ Về thăng tiến thì tùy khả năng của mỗi bạn và độ open của doanh nghiệp. Như công ty hiện tại thì nó chia sẻ thẳng thắn sau BA có thể lên BC - Business Consultant, PM, PO v.v...

+ Về level entry fresher thì giờ nói thật bằng cấp cử nhân nó trở thành đại trà quá rồi, bác nào có ý theo ngành thì tôi khuyên thật nếu bằng không đến từ KHTN, Bách Khoa hoặc trường top thì nên học thêm cái vb 2 sẽ tăng khả năng cạnh tranh lên nhé. Như công ty bên này nó chỉ tuyển từ KHTN thôi, bằng tốt nghiệp loại giỏi có khi còn bị cho đợi.

Đôi lời chia sẻ thêm là thế, cũng khá dài nhưng thú thật chỉ mới là một số còn nhiều thứ nữa cũng khó nói hết 1 lần.

Nhấp để mở rộng...

Deptrai_ChuaYeuAi đã nói:

Cảm ơn bác, may sao vẫn tìm đc 1 bài viết ở post này thời điểm hiện tại, giờ có AI là dev IT mất hết việc rồi. Cho e hỏi BA hiện tại còn nhiều nhu cầu ko bác, e đang phân vân giữa BA với Data, e đang học MIS Hust

Nhấp để mở rộng...

phammai16 đã nói:

Như title, mình làm IT BA đã x năm giờ chuẩn bị chuyển sang role khác. Kinh nghiệm BA vẫn còn kha khá nên muốn lên chia sẻ cho ae được tí nào hay tí đó trước khi kinh nghiệm out date Chủ yếu support ae mới vào nghề muốn hiểu rõ hơn các thứ, chứ ae làm lâu thì bỏ qua ha. Lưu ý trong bài m nói về IT BA thôi nhé

Phần 1. Sơ lược về mình

1. Background
Mình học ngành MIS của 1 trường kinh tế VN, ở trường học 1 nửa là kinh tế nửa còn lại là SQL, Code C, C++, Cấu trúc dữ liệu giải thuật, Toán rời rạc,.. nói chung là các môn cơ bản của ngành CS. Đồ án tốt nghiệp là build con web app --> Nhiều khi cũng k biết như này có gọi là có base IT ko nữa code thì ko rành như ae dev nhưng các thứ basic thì hiểu. English thì bình bình vì toàn làm cty VN cũng k cần dùng nhiều

2. Kinh nghiệm làm việc
Domain mình đã từng làm thì linh tinh mỗi thứ 1 ít: Kế toán, Kiểm toán, kho vận, chuyển phát, crm, sale, chứng khoán, khách sạn dịch vụ..
Các công ty đã trải nghiệm: Start up nhỏ mới mở, Công ty VN lâu đời (cty gia đình), Công ty nhà nước, Ngân hàng :> h đang yên vị ở cty nhà nước.
Môi trường: OS, product, triển khai

Phần 2. Các câu hỏi mà m hay gặp khi lượn qua các group BA:

1. BA là gì? BA làm gì hàng ngày?
Câu này thực ra không nhiều người hỏi lắm, nhưng mình thấy quan trọng nên đưa vào
Có thể nói cùng tittle BA nhưng job mỗi cty có đặc thù riêng, đòi hỏi bộ skill hơi hơi khác nhau. Bạn nên nắm được cơ bản trước khi jump vào các vị trí này kẻo lại vỡ mộng :>
Theo trải nghiệm của m thường có 3 loại BA chính theo loại cty:

- BA triển khai (nhân viên triển khai): thường làm trong các công ty triển khai ERP, triển khai giải pháp bán hàng cho khách,.. Đầu công việc của BA sẽ cực đa dạng, thường bắt đầu bằng việc support sale làm proposal cho khách để kéo hợp đồng về cty (có thể phải làm hoặc không, Sale k rõ detail thì BA và dev thường bị lôi vào cùng). Sau khi kí dc hợp đồng thì các bác sẽ chạy qua lấy đề bài chi tiết của KH --> map với giải pháp cty đang cung cấp xem thừa thiếu miếng nào, nói chung là tìm cách để tối đa được phần mềm theo yêu cầu của khách. Điều này đòi hỏi bạn phải cực vững về giải pháp bạn đang triển khai. Song song với đó là việc lấy dữ liệu cũ (nếu làm erp) , xử lý để import lên hệ thống sẽ chạy. Tưởng tưởng khách muốn có dữ liệu từ đầu 2022 trở đi trên hệ thống, mà tận t10/2022 mới ký hợp đồng triển khai thì các tháng thiếu cần xử lý thủ công ròi. Ngoài ra còn cần làm các bước cài cắm setup cho hệ thống chạy ổn định đúng với yêu cầu của khách (vd kế toán chạy thông tư 133 hay 200 thì cài đặt khác nhau). Xong xuôi ae sẽ qua training cho khách cách dùng hệ thống, có khi phải xuống tận nơi, đi công tác cả tuần --> điều mình ghét và bỏ nghề triển khai. Nói thiệt là job này nó cũng ko BA lắm, bù lại mới vào mà theo thì sẽ tiếp cận và hiểu nghiệp vụ rất nhanh và sâu sát. Career path có thể lên làm tư vấn chuyên nghiệp. Các bên kiểm toán cũng rất cần vị trí kiểu này. AE trái ngành kế kiểm qua job này cực phù hợp vì tận dụng được kiến thức nghiệp vụ :> Thường làm việc với các C level --> học hỏi dc nhiều tư duy các bác C.

- BA outsource: thường làm trong công ty OS. Nhiệm vụ là lấy đề bài từ phía khách hàng, confirm với khách, sau đó làm thành tài liệu rồi transfer cho ae dev --> Cần mạnh các skill về docs, mô hình hóa, giao tiếp,... ở đây cái dở là nhiều khi ae chỉ làm cầu nối thôi, bởi vậy nhiều bên cho test rồi dev trực tiếp connect với khách là vì vậy ko cần tới BA luôn. Làm bên này yêu cầu phải giỏi ngoại ngữ chút, làm lâu thì cũng nên góp gì đó thành tài sản cá nhân ví dụ như các kiến thức domain chẳng hạn. Được cái quy trình chuẩn chỉnh học hành bài bản, OS thì sẽ được tiếp cận đa dạng domain tha hồ trải nghiệm nhưng ko sâu như product được.

- BA product: như tên, các bác join vào làm BA cho 1 product nào đó. Mình thấy xu hướng hiện nay sẽ là PO kiêm BA có khi kiêm UX chỗ này luôn. Có 2 TH chính mình hay gặp. TH1 là các bạn chỉ nghe yêu cầu từ phía khách hàng (thường là sếp của các bạn) hoặc thậm chí k có tí yêu cầu nào cả, chỉ bâng quơ mấy câu kiểu "Anh cần thêm cái tính năng X trên con web nhà mình" ) Lúc này cần đi research, tìm hiểu xem tính năng X đó nên làm như nào, triển khai như nào cho hợp lý, demo sơ sơ mockup rồi đề xuất lại cho sếp --> Thiên về PO nhiều hơn. Cần nghĩ ra tính năng, hiểu về nghiệp vụ kĩ càng. TH2 là có khách hàng và đề bài tương đối clear, lúc đó thì khá giống BA OS rồi. Với BA product docs không phải là tất cả, nghiệp vụ đổi liên tục nên quá focus vào tài liệu sẽ mất thời gian. Để tiến xa khi làm product mình đánh giá cao các bạn hiểu nghiệp vụ và có tư duy của PO. Domain tốt có thể nhày việc theo ngành dọc, tức là nhảy cùng domain khác cty, ví dụ từ GHTK --> GHN --> VNPost, được trọng dụng hơn là nhảy linh tinh các domain

2. Có thể chuyển từ ngành XYZ qua IT BA không? Trái nghành có nên theo BA không?

==> Quan trọng nhất với BA là nắm nghiệp vụ vững, giải thích được gãy gọn cho dev cần làm gì, vì sao phải làm điều đó, đưua được lộ trình rõ ràng phase này làm A phase kia làm B để team follow theo (team có PO thì PO care chỗ này)
Quan trọng nữa là giao tiếp phải cực cực tốt với nhiều bên cả KH và team nội bộ, và hạn chế đổi requirement thôi, nhất là BA os. Đổi thì phải có lý do hợp lý. Chứ lấy đề bài về dev chán chê rồi lại thêm lại bớt, thì điều này thể hiện bạn là 1 BA còn non --> ae dev + test sẽ k tin bạn lắm, value của bạn trong team sẽ giảm nhiều :> Với khách bên ngoài thì m làm cho nhà nước mới thấy nhiều bên củ chuối, k chịu hợp tác. Luc này mà k cứng + bản lĩnh thì dự án k bao h trôi được. Cứng + bản lĩnh thì hoàn toàn là kĩ năng mềm rồi :>

• Nhiều case chuyển ngành BA thành công lương cao mình biết đều là do có domain trước đó rồi chuyển qua, có khi nhảy phát là 20- 30-40 cũng có. Hồi làm bank và chứng khoán, nhiều bạn ban đầu là dân chứng, đưa đề bài cho bọn mình làm product, sau đó tháy hợp nên move qua BA luôn, và làm rất tốt , làm BA đến tận giờ. BA lead chỗ mình hiện tại cũng k base IT gì cả nhưng tốt excel và nghiệp vụ cực đỉnh, vẫn lead ae như thường.
• Bởi vậy, nếu ae nhắm đáp ứng dc các cái đó thì BA thẳng tiến k cần lo gì đâu :> Kiến thức IT cho IT BA mỗi cty 1 khác. có cty m làm thì BA phải define được API structure, map được FE -API . Có công ty cần tốt excel, sql là được rồi. À basic về phần mềm thì vẫn nên có chứ mù tịt quá thì không được đâu

Dài quá, sơ sơ vậy. Ae hỏi gì thì post xem m có giúp được k nhé :>

Nhấp để mở rộng...

• 2 yoe
• Các đầu việc vẫn giống như đầu việc của một BA thông thường: requirement gathering & analysis, documentation, UAT, stakeholder coordination, ...
• Em chỉ nêu một số thông tin như vậy thôi vì chắc hẳn các bác làm BA thì đã quá rõ với những đầu việc như thế này