Nguồn: https://ivolunteer.vn/fpt-digital-tuyen-dung-thuc-tap-sinh-business-analyst-s26352.html
Nguồn: https://ivolunteer.vn/fpt-digital-tuyen-dung-thuc-tap-sinh-business-analyst-s26352.html
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.
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.
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.
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 riêng biệt dành cho những bạn junior và dành cho những bạn senior.
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ó. 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.