Business Analyst (BA) là gì? Kinh nghiệm onsite tại Mỹ của 1 Business Analyst (updated 2018)

Business Analyst (BA) là người sẽ có rất nhiều giải pháp cho yêu cầu của khách hàng, không phải lúc nào vấn đề cũng được giải quyết bởi giải pháp phần mềm.

Công việc của Business Analyst IT bao gồm làm việc với khách hàng để lấy yêu cầu, sau đó chuyển thông tin và thảo luận về yêu cầu này với team nội bộ (Developer, QC), và quản lý document.

Đọc bài phỏng vấn của ITviec với anh Lê Hoàng Vũ – Business Analyst Manager của một Business Unit tại FPT Software – để nghe anh chia sẻ về:

• Công việc thường ngày của một BA là gì và những kỹ năng nào là quan trọng nhất đối với một BA
• Những con đường anh đã trải qua để trở thành một BA
• Lời khuyên anh dành cho các bạn muốn trở thành BA

Xem thêm việc làm Business Analyst trên ITviec

Tiểu sử: Khi vừa tốt nghiệp trường NIIT ngành CNTT vào năm 2006, anh Vũ được bạn giới thiệu vào công ty MMSOFT – Vietnam làm vị trí QA và chuyển sang BA trong hơn 2 năm, rồi anh chuyển qua HPT Vietnam Corporation làm Project Manager trong gần 1 năm.

Sau đó, anh đến làm việc tại Mirae Icon với vai trò BA trong gần 1 năm tiếp theo. Do môi trường không phù hợp, anh chuyển sang làm Senior BA cho công ty Pyramid Consulting Vietnam trong 9 tháng sau đó.

Từ cuối năm 2011, anh làm Senior BA cho Harvey Nash Vietnam. Đến cuối năm 2015, anh sang đầu quân cho FPT Software (FSoft) với vị trí Business Analyst Manager cho một Business Unit của công ty. Khoảng giữa năm 2016, anh được công ty cử sang Mỹ on-site dài hạn cho đến nay.

Anh có thể giải thích một chút Business Analyst là gì?

Business Analyst là người sẽ có rất nhiều giải pháp cho yêu cầu của khách hàng, không phải lúc nào vấn đề cũng được giải quyết bởi giải pháp phần mềm. Em có thể hiểu như vậy.

Riêng công việc Business Analyst của anh thì là Business Analyst IT. Tức là anh làm Business Analyst (BA) cho một công ty IT chuyên làm phần mềm cho những công ty khác. Tuy nhiên nghề BA nói chung khá là rộng, không phải chỉ có BA trong IT.

Những công việc chính hàng ngày của anh, một BA IT, bao gồm:

1. Làm việc với khách hàng để lấy yêu cầu, rồi chuyển cho team nội bộ. Điều thú vị ở đây là BA làm việc với khách hàng còn nhiều hơn cả PM. Và đôi khi, chính BA là người đủ thân thiết để có thể giúp công ty có thêm cơ hội hợp tác với khách hàng.

Như anh trong quá trình làm việc với nhiều khách hàng, anh từng phát hiện họ cần thêm những hệ thống khác. Anh giúp phân tích ưu nhược điểm của các hệ thống đó cho khách hàng, đưa ra nhiều giải pháp phần mềm cho họ. Tức là anh đã gián tiếp làm sales, đem lại project cho công ty.

2. Giao tiếp với team nội bộ, bao gồm chuyển thông tin và thảo luận về yêu cầu khách hàng, về dự án nói chung. Cụ thể hơn, BA phải làm việc với cả Developer, QC, PM.

Từng có một dự án, khi viết yêu cầu khách hàng xong, anh nhận ra rằng có một phần việc thuộc dự án khác của team khác, không phải team anh.

Lúc đó, anh trao đổi lại với bạn PM, rằng yêu cầu phát sinh này team anh có phải làm hay không, nếu làm thì tính tiền như thế nào, nếu làm thì nó có tác động gì đến những phần khác trong dự án của team không v.v…

3. Công việc về documentation, bao gồm việc viết và quản lý document. Quản lý document quan trọng vì document không phải viết một lần là xong, mà còn chỉnh sửa các kiểu.

Một dự án không chỉ có một document. Quản lý document nghĩa là phải làm sao để mọi người cùng biết đâu là bản cuối cùng, và khi có những thay đổi trong dự án thì nó ảnh hưởng đến document nào.

Anh Vũ (ngồi ngoài cùng bên trái) cùng đồng nghiệp ở Harvey Nash

Công việc mới của anh tại FSoft có thay đổi nhiều không?

Về cơ bản, công việc của anh vẫn là lấy yêu cầu từ khách hàng rồi chuyển cho team nội bộ.

Tuy nhiên, lúc trước thì khách hàng tìm đến công ty outsourcing nơi anh làm việc khi họ đã có ý tưởng về phần mềm rõ ràng. Business Analyst chỉ cần hiểu và đóng góp một vài thay đổi nhỏ để cụ thể hóa ý tưởng đó.

Còn bây giờ, anh tham gia vào dự án từ rất sớm. Lúc này, bản thân khách hàng cũng chưa mường tượng ra phải làm gì. Anh sẽ ngồi thảo luận chung với nhóm Product Owner của khách hàng trong giai đoạn product definition.

Sau đó, trong tuần anh sẽ có từ 1 đến 5 buổi tối (tùy thời điểm) họp với team ở Việt Nam (do Mỹ và Việt Nam trái múi giờ) để truyền đạt thông tin của khách hàng và thảo luận với team cách đáp ứng các yêu cầu của khách hàng.

Anh có gặp sự cố gì trong công việc Business Analyst Manager?

Có. Có lần sau khi khách hàng họp bàn và chia sẻ ý tưởng, anh chưa hỏi ý khách hàng mà chuyển ngay ý tưởng đó cho team Việt Nam. Sau đó, team Việt Nam đặt nhiều câu hỏi cho Product Owner của khách hàng.

Kết quả là các bạn Product Owner của khách hàng không vui. Họ nói với anh là những gì họ chia sẻ mới chỉ là ý tưởng rất sơ khai, sau khi bàn bạc thảo luận có thể sẽ chọn ý tưởng khác, nên việc anh chuyển thông tin ngay cho offshore team có thể làm mọi thứ rối lên.

Từ đó, anh rút ra bài học là phải thận trọng hơn, khi thảo luận ý tưởng đạt đến một mức độ nhất định thì mình cần hỏi khách hàng là có thể chuyển thông tin cho offshore team được chưa. Họ đồng ý thì mình mới trao đổi với offshore team.

Tuy nhiên, đến giai đoạn requirement đã rõ ràng, anh thường khuyến khích các team member làm việc trực tiếp với Product Owner của khách hàng.

Gần đây, mô hình Agile/Scrum được áp dụng, đòi hỏi mỗi team member phải làm rất nhiều việc và phải có các kỹ năng: giao tiếp, tiếng Anh, khái quát vấn đề, và trình bày.

Đây là một trong những thứ mà nhiều bạn Developer và Tester ở Việt Nam thiếu. Vì vậy, anh luôn khuyến khích và hỗ trợ các bạn bổ sung những kỹ năng này để đi theo mô hình Agile trên thế giới.

Có điều gì mà mọi người thường hiểu lầm về một BA?

Anh nghĩ cái mà nhiều người hiểu lầm là: khi nói đến BA, ai cũng nghĩ đến BA IT, nhưng đến khi anh làm BA rồi, và anh hiểu về công việc BA thì anh mới biết BA cần thiết cho mọi tổ chức chứ không chỉ riêng IT.

BA là Business Analyst. Thật sự trong cả chữ đó, không có chữ nào liên quan đến IT hết. (Cười)

Theo anh, định nghĩa của nghề BA là: “BA là người giúp định nghĩa ra những yêu cầu để có thể chuyển từ trạng thái này sang trạng thái khác.”

Ví dụ anh nói sales của tôi đang gặp vấn đề, và vấn đề đến từ việc đội ngũ sales chưa được chuyên nghiệp. Thì người BA chính là người giúp định nghĩa ra những yêu cầu để làm sao chuyển từ trạng thái ‘đội ngũ sales chưa chuyên nghiệp’ sang trạng thái ‘đội ngũ sales trở nên chuyên nghiệp’.

Có rất nhiều giải pháp cho yêu cầu này, không phải lúc nào vấn đề cũng được giải quyết bởi giải pháp phần mềm.

Giả sử bạn BA-1 sau khi phân tích thì thấy anh nên làm một phần mềm để training các bạn sales tốt hơn. Nhưng bạn BA-2 thấy rằng anh thuê toàn những bạn sales yếu kém nên đề nghị anh thay những bạn này bằng các bạn sales khác trưởng thành hơn.

Là người có nhiều kinh nghiệm trong nghề BA thì anh thấy điểm cộng và điểm trừ của nghề BA là gì ạ?

Về điểm cộng thì thứ nhất, với vị trí là một BA, em sẽ có cơ hội tiếp xúc với nhiều khách hàng, nhiều bạn developer, QC, QA. Vì vậy em sẽ phát triển được kỹ năng giao tiếp.

Điểm cộng thứ hai là em được biết rất nhiều domain knowledge. Bởi vì tính chất công việc khiến một BA biết rất nhiều domain, và mọi domain họ biết thì đều biết sâu.

Điểm cộng thứ ba thì giống như là một hiệu ứng phụ của điểm cộng thứ hai, đó là khả năng một bạn BA chuyển con đường sự nghiệp sang những công việc khác là khá rộng.

Vì khi em làm một dự án liên quan đến Digital Marketing, em hiểu về nó, thì có thể là có một cơ duyên nào đó (như là em thấy thích thú ngành Digital Marketing hơn) để em chuyển sang làm Digital Marketing mà không làm BA nữa.

Anh từng chứng kiến điều này ở vài người bạn của anh. Không chỉ Marketing mà còn có thể là Finance & Banking…

Về điểm trừ thì thứ nhất là thời gian làm việc của một bạn BA rất ngược với người thường.

Hầu hết thời gian, BA phải làm việc với khách hàng nước ngoài nên đôi khi thời gian biểu trái với giờ sinh hoạt và làm việc của gia đình. Ví dụ thỉnh thoảng buổi tối anh phải online để họp với khách hàng ở Mỹ, ở Anh vì tối của mình là sáng của họ.

Điểm trừ thứ hai là thỉnh thoảng phải đi onsite ở nước ngoài. Đối với một số người, thì đây là điểm tốt. Tuy nhiên với anh, về khía cạnh gia đình thì đi onsite nghĩa là anh phải xa gia đình, thì đây là điều trở ngại.

Điểm cuối cùng, cái này thì anh nghĩ nó là thử thách hơn là điểm trừ, chính là vì anh phải thay đổi dự án thường xuyên, nên trở ngại và thử thách là lúc nào cũng phải học những domain mới trong một thời gian ngắn.

Khi một khách hàng tìm đến mình thì mong đợi của họ là mình không chỉ có những kỹ năng về phân tích mà mình cần phải am hiểu về domain của họ.

Vì vậy, mình phải làm sao để khi mình gặp khách hàng, mặc dù chưa hiểu sâu về domain đó nhưng phải học đủ nhanh, nắm đủ thông tin để có thể nói chuyện với khách hàng, và thậm chí giống như là còn hiểu hơn cả khách hàng để có thể tư vấn ngược lại cho họ.

Anh có thể chia sẻ một câu chuyện về thử thách khi anh học một domain knowledge mới, và cách anh đã làm việc với khách hàng về domain knowledge đó không ạ?

Lúc trước anh có làm việc với một khách hàng Mỹ, làm về hàng không. Dự án anh làm là về “arrange accommodations,” tức là những bạn mà trễ chuyến bay có thể lên những ki-ốt ở trên sân bay, scan passport và vé của họ, rồi hệ thống sẽ biết bạn này bay chuyến nào, rồi hệ thống sẽ chạy phần mềm để đưa ra danh sách những chuyến bay thay thế cho bạn đó chọn.

Thật sự lúc anh qua làm việc với khách hàng, anh cũng chưa biết gì về lĩnh vực hàng không, nhưng được cái là anh hay quan sát và để ý, nên lúc qua gặp khách hàng, câu đầu tiên họ hỏi là anh có biết gì về lĩnh vực này không? Nếu là anh của vài năm nước, có thể anh đã trả lời: “Xin lỗi, tôi học IT tại trường, không biết gì về hàng không cả.” (Cười)

Nhưng lúc đó, anh đã chọn cách trả lời như sau: “Thực tế đúng là tôi chưa làm qua những dự án hàng không, tuy nhiên trong quá trình làm việc, tôi có từng sử dụng qua nhiều dịch vụ hàng không khác nhau và tôi để ý khá nhiều về nó và tôi biết cách nó vận hành như thế nào.”

Đó là một cách mà anh đã sử dụng. Lý thuyết của cách này là có thể là em chưa học qua domain đó nhưng trong quá trình sống, em để ý tới nó thì em vẫn có thể tạo được lòng tin ban đầu ở khách hàng. Anh khuyên các bạn muốn làm BA thì phải luôn để ý đến mọi thứ xung quanh.

Anh Vũ (đứng ngoài cùng bên trái) cùng đồng nghiệp trong Harvey Nash

Theo anh thì có những kỹ năng và yếu tố nào là quan trọng nhất đối với một người BA?

Kỹ năng giao tiếp là điều quan trọng đầu tiên. Nhưng quan điểm của anh là nghề BA và kỹ năng giao tiếp hỗ trợ qua lại cho nhau. Giao tiếp ở đây là em trao đổi và thương lượng với khách hàng về các yêu cầu dự án.

Thứ hai, em phải là người có đầu óc cởi mở, sẵn sàng đón nhận những cái mới. Vì nếu em không có suy nghĩ đó, cái gì thì em cũng chỉ đi theo lối mòn cũ.

Ngoài ra, theo anh thấy, một kỹ năng cần thiết cho mọi BA là suy nghĩ logic để giải quyết vấn đề và thương lượng.

Cuối cùng, em phải biết cách dùng những công cụ hỗ trợ cho BA như là Office, Visual để vẽ những hình như là wireframe mockup để trình bày cho khách hàng, hoặc là dùng những công cụ dùng để quản lý dự án Agile khá phổ biến như Jira, Confluence.

Anh có thể chia sẻ cách anh đã áp dụng để nâng cao kỹ năng giao tiếp cho bản thân không ạ?

Giao tiếp tốt giống như một vòng lặp khép kín (close loop), nghĩa là thông điệp của em được đối phương hiểu chính xác.

Anh ví dụ, khách hàng email hẹn gặp em tại công ty ở địa chỉ 466/4 Lê Quang Định, quận Bình Thạnh vào lúc 9AM, thứ sáu (13/03/2015).

Nếu em là người giao tiếp không tốt, email phản hồi của em là: “Em đã nhận được thông tin và sẽ có mặt đúng giờ.”

Nếu em giao tiếp tốt, em sẽ trả lời khách hàng là: “Em sẽ gặp anh/ chị tại công ty ở địa chỉ 466/4 Lê Quang Định, quận Bình Thạnh vào lúc 9AM, thứ sáu (13/03/2015).”

Lặp lại thông điệp giao tiếp sẽ 1) giúp em hiểu và nhớ chính xác thông điệp giao tiếp, 2) giúp đối tượng giao tiếp biết rằng em hiểu chính xác thông điệp của họ.

Khi em là người truyền đi thông điệp giao tiếp, đừng bao giờ cho rằng đối phương nhận được thông tin nghĩa là họ đã hiểu điều em muốn nói, cho đến khi họ lặp lại chính xác thông điệp của em.

Ngoài ra, mỗi khi giao tiếp với khách hàng, anh luôn áp dụng nguyên tắc SELF PR. SELF PR là từ viết tắt của:

[S]ympathy: đồng cảm, thấu hiểu đối tượng giao tiếp, lắng nghe và nhìn từ góc nhìn của người đối thoại.

[E]ngage: để tâm, chú ý vào câu chuyện đang giao tiếp, thỉnh thoảng lặp lại lời người đối thoại để chứng minh rằng mình đang lắng nghe.

[L]isten more: lắng nghe trước và lắng nghe nhiều hơn là nói. Không chỉ lắng nghe bằng tai, mà cả bằng mắt – nhìn thẳng vào người nói, và bằng toàn thân – vai thẳng, song song, đối diện với người nói.

[F]eedback: đưa ra phản hồi ngay lập tức khi đối tượng giao tiếp có câu hỏi.

[P]recise: phản hồi chính xác những điều mà đối tượng giao tiếp hỏi.

[R]esult oriented: tập trung vào kết quả cuộc đối thoại.

Làm sao để một bạn sinh viên mới ra trường hoặc là Developer, có thể xác định được rằng mình hợp với nghề BA hay không?

Nếu bạn nào thấy 1) mình là người thích giao tiếp và có nền tảng giao tiếp tương đối ổn, 2) mình thích tìm hiểu về nhiều ngành nghề và cũng có hiểu biết tương đối về 1-2 ngành nghề nào đó, 3) tiếng Anh của mình khá, thì 80% khả năng bạn đó có thể chọn con đường BA.

20% còn lại chính là bạn đó phải có nền tảng về IT. Vì nếu em như một tờ giấy trắng về CNTT, thì document cuối cùng em viết ra cũng giống document của khách hàng, đều là ngôn ngữ kinh doanh. Vậy câu hỏi là ý nghĩa của việc ‘nhờ em diễn dịch từ ngôn ngữ kinh doanh sang ngôn ngữ kỹ thuật nó nằm ở đâu?

Nếu một bạn muốn phát triển sự nghiệp theo định hướng BA thì anh khuyên bạn đó nên học cái gì ngay bây giờ?

Anh gợi ý cho các bạn hai nguồn.

Thứ nhất là nguồn quốc tế, thì hiện nay có một tổ chức là IIBA. Tổ chức IIBA này hiện nay là tổ chức nổi tiếng nhất trên thế giới về BA, và họ là về BA tổng quát, không chỉ riêng BA IT.

Họ phát hành một quyển sách là BABOK (Business Analysis Body Of Knowledge). Em có thể đăng ký thành viên, họ sẽ gửi cho em quyển ebook này để tự học. Học xong, em có thể ứng dụng việc học vào công việc hàng ngày hoặc là đăng ký thi online để lấy bằng (CCBA và CBAP).

Ở Việt Nam, anh biết một công ty cung cấp training về BA, là BAC. BAC có hai khóa học là BA căn bản và BA nâng cao. Hơn nữa họ có ưu điểm là một đối tác của IIBA.

Nếu có một tech guy muốn chuyển sang làm BA thì bạn ấy nên tiếp cận như thế nào ạ?

Thứ nhất, theo anh là mấy bạn QC có suy nghĩ gần với BA hơn. Nên nếu các bạn mới ra trường, có khả năng lập trình và các bạn cũng muốn chọn BA, thì bạn nên đi theo hướng QC, sau đó chuyển sang BA sẽ dễ dàng hơn.

Thứ hai là các bạn nên đi học và luyện tập nhiều về tiếng Anh.

Thứ ba là mặc dù chưa ai “phong” cho bạn chức danh BA, nhưng trong dự án, chắc chắn có nhiều lúc phát sinh những việc có tính chất giống với công việc của BA. Khi đó, các bạn cứ tự tin tình nguyện nhận công việc đó để mình tập làm quen.

Ví dụ thông thường trước dự án BA có một buổi trao đổi yêu cầu khách hàng cho cả team. Sau đó, BA chuyển qua viết yêu cầu khách hàng cho những dự án tiếp theo.

Thì nếu em là QC, em định hướng chuyển sang BA thì em hãy cố nghe kỹ mọi thông tin trong buổi họp đó hoặc em làm việc riêng với BA để hiểu thêm về yêu cầu khách hàng.

Tiếp theo, em nói với các bạn developer là: “bạn nào có gì không hiểu thì trước khi qua hỏi BA có thể hỏi tôi trước; nếu tôi không trả lời được, tôi sẽ qua hỏi BA để trả lời thêm cho các bạn.”

Tự nhận những trách nhiệm như vậy giúp em gần gũi và dễ dàng chuyển đổi công việc của mình hơn.

Career path của một BA thì sẽ đi theo những con đường nào anh nhỉ?

Lúc trước, anh định hướng con đường nghề nghiệp làm BA của mình theo như road map tại IIBA. Anh nghĩ các bạn cũng có thể tham khảo tại đó, vì nó là chuẩn quốc tế. Có hai con đường, 1) dành cho những bạn junior, 2) dành cho những bạn senior.

Sai lầm lớn nhất mà anh từng mắc phải và bài học anh rút ra từ sai lầm đó là gì?

Lúc trước có một dự án mà khi anh đọc sơ yêu cầu của nó rồi so với thời gian dự tính của team thì anh thấy là với nguồn lực hiện tại, team chắc chắn không thể hoàn thành dự án với yêu cầu nhiều như vậy.

Khi anh tham gia dự án thì nó đã chạy được một thời gian ngắn rồi. Sai lầm của anh là thay vì phải ngay lập tức feedback cho cả team với một thái độ cứng rắn thì anh lại nói thôi kệ, cứ cố gắng thôi. Nhưng càng làm thì thấy là càng đuối, không thể giải quyết được.

Chốt lại, anh học được bài học là phải nhìn nhận vấn đề đúng như những thật sự của nó, và đôi khi phải có thái độ cứng rắn đối với cả team cũng như cả bản thân mình trong việc thừa nhận vấn đề.

Bạn có đang định hướng trở thành một BA trong tương lai? Hoặc bạn đã là BA thì có kinh nghiệm gì về nghề BA mà bạn muốn chia sẻ cùng mọi người? Hãy cùng thảo luận tại phần comment ở cuối bài viết.

Và nếu bạn nào có hứng thú với nghề BA thì có thể tham khảo các việc làm Business Analyst tại ITviec.