Học Business Analyst Tại Fpt Tuyển Dụng Tại Mỹ Không Cần Bằng Cấp

Nguồn: https://ivolunteer.vn/fpt-digital-tuyen-dung-thuc-tap-sinh-business-analyst-s26352.html

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 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.

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/2019).

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/2019).”

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.

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, bạn có thể học tại các công ty training về BA.

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.

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.