Business Analyst: Người làm thông dịch viên

Business Analyst: Người làm thông dịch viên

Bài viết trên PC World Việt Nam, ấn phẩm B, chuyên đề giải pháp và ứng dụng công nghệ thông tin, số tháng 4/2011, trang 60.

Chuyên viên phân tích nghiệp vụ (chuyên viên phân tích thiết kế hệ thống, Business Analyst, BA) là cầu nối giữa bộ phận CNTT và hoạt động kinh doanh của doanh nghiệp. Họ phân tích và thiết kế mô hình kinh doanh, quản lý của các tổ chức doanh nghiệp. Do đó, họ có vai trò quan trọng trong mối quan hệ giữa doanh nghiệp với khách hàng và đối tác.


Xuất phát từ developer

Anh Nguyễn Hoàng Minh, Chuyên viên BA Công ty DICentral chuyên về mảng phát triển tính năng của Microsoft SharePoint 2010 cho thị trường Mỹ cho biết, với chuyên ngành CNTT, trong thời gian sinh viên, Minh đã thực hiện khá nhiều dự án làm thêm từ trang web RentACoder.com. Nhờ vậy, đã có kinh nghiệm làm việc với các dự án cho khách hàng nước ngoài. Khách hàng nước ngoài thì ngoài việc viết mã chương trình, họ còn yêu cầu về việc thực hiện tài liệu thiết kế rõ ràng. Trong khoảng thời gian này, Minh cũng đã bắt đầu làm quen lấy yêu cầu và phân tích yêu cầu từ những dự án nhỏ và chi phí không cao.

Sau đó, Minh được nhận vào một công ty phần mềm của Đức chuyên gia công cho thị trường châu Âu. Tại đây, Minh được công ty cho cơ hội thử thách ở vị trí trưởng nhóm (Team Leader) nhờ vào khả năng nắm bắt, khả năng giao tiếp, tiếp cận vấn đề tổng thể và làm việc trực tiếp với bên đối tác ở Đức. Kinh nghiệm qua 3 dự án khá lớn nên Minh có cơ hội trau dồi khả năng lấy yêu cầu, tiếp xúc khách hàng và khả năng phân tích yêu cầu. Tuy nhiên, ở thời điểm đó, công việc vẫn chưa phải hoàn toàn là một BA thật sự.

“Tôi thật sự thích cái nghề này và đã định hướng đi theo nghề này, học thêm kỹ năng cũng như kiến thức chuyên môn. Khoảng 2 năm sau đó, tôi chính thức bước hẳn vào làm ở vị trí BA và tư vấn giải pháp phần mềm trên công nghệ .NET của Microsoft cho đến bây giờ”, anh Minh chia sẻ.

Chị Tô Việt Anh, Chuyên viên phân tích hệ thống Công ty phần mềm FPT cho biết, sau nhiều năm học hỏi, tích lũy kinh nghiệm từ lập trình viên (Developer), tôi chuyển dần sang mảng cơ sở dữ liệu (CSDL, Database), chịu trách nhiệm phân tích nhu cầu của hệ thống và thiết kế database cho phù hợp. BA phải tìm hiểu hệ thống thật kỹ lưỡng các quy trình trong doanh nghiệp hoạt động như thế nào, hệ thống phục vụ nhu cầu gì của người dùng, xác định thật rõ các yêu cầu người dùng. Từ đó, họ phân tích để thiết kế được CSDL cho hệ thống đó hợp lý hoặc đề xuất cải tiến quy trình. Sản phẩm sau khi thiết kế hệ thống sẽ được chuyển cho bộ phận thiết kế giao diện và lập trình cho hệ thống này.

Business Analyst: Người làm thông dịch viên
Business Analyst: Người làm thông dịch viên

Trưởng thành từ dự án

Đa số sinh viên thường tập trung vào các môn có thể ứng dụng được ngay như lập trình hay cơ sở dữ liệu. Có thể nói, nhiều môn học ngành CNTT như công nghệ phần mềm, quản lý công nghiệp… tưởng chừng như khô khan, quá lý thuyết nhưng BA rất cần có những kiến thức ở những môn này.

Theo anh Minh, BA được ví như những người làm “thông dịch viên” giữa người làm nghiệp vụ và người lập trình thông qua một trong các  ngôn ngữ thể hiện là UML (Unified Modeling Language). Đây là các tài liệu theo chuẩn trong công nghệ phần mềm mà ở đó cả người làm nghiệp vụ và người lập trình đều đọc hiểu.

Nguyễn Hoàng Minh, Chuyên viên BA Công ty DICentral
Nguyễn Hoàng Minh, Chuyên viên BA Công ty DICentral

Nghề BA là một nghề đặc trưng cần rất nhiều kỹ năng mềm như kỹ năng tổ chức, kỹ năng viết tài liệu, ngoại ngữ, kỹ năng giao tiếp, kỹ năng lấy yêu cầu, kỹ năng phân tích, tầm nhìn xa và kỹ năng giải quyết vấn đề bên cạnh kiến thức chuyên môn cần thiết. Ngoài ra, BA cũng là một nghề chịu áp lực cao và đôi khi làm việc đêm rất nhiều khi làm việc với khách hàng trái múi giờ, vì vậy, Minh nghĩ nghề này phù hợp với các bạn nam năng động, có duyên ăn nói và linh động thời gian, có thể đi công tác mà không phải gặp nhiều vấn đề. Tuy nhiên, nếu các bạn nữ có tính cách và muốn thử thách thì cũng đáng để thử một nghề đầy thử thách và cơ hội.
Anh Nguyễn Hoàng Minh, Chuyên viên BA Công ty DICentral

Ngoài những kiến thức nền tảng về CNTT, để trở thành một BA, họ phải có thời gian trải qua nhiều dự án với các công việc như lập trình, giải quyết các vấn đề khó khăn của hệ thống và tiếp cận cũng như thiết kế các giải pháp phần mềm phù hợp. Theo anh Minh, nếu không hiểu, không biết những vấn đề khó khăn hoặc không có kinh nghiệm trong thiết kế kiến trúc phần mềm thì khi gặp khách hàng  rất dễ bị “hố” (khó thuyết phục và không làm khách hàng tin tưởng) khi đưa quy trình hay giải pháp mà bên kỹ thuật không thể làm được.

“Bản thân tôi đã trải nghiệm qua nhiều dự án lớn nhỏ khác nhau, nhiều lĩnh vực khác nhau (dự án bất động sản, dự án phần mềm, dự án về CRM hay CMS…). Càng nhiều càng tốt vì khi đó BA càng có nhiều kinh nghiệm, kiến thức về nghiệp vụ và khả năng “nhìn thấy” được những vấn đề “tiềm ẩn”. Nếu không phân tích kỹ thì dự án có khả năng phải bỏ (failed) hoặc làm lại dự án vào phút chót (tốn nhiều thời gian, công sức và cũng có thể dự án đi đến thất bại). Đặc biệt, những dự án đặc thù như dự án về tài chính, kinh doanh, thuế… thì người BA cần phải tìm hiểu rất kỹ các vấn đề liên quan”, anh Minh nói.

Vì những yêu cầu khắt khe trên, người BA muốn làm tốt công việc của mình thì nhất thiết phải có kiến thức nền tốt về CNTT, kiến thức nghiệp vụ và khả năng nhìn xa về mặt kỹ thuật. Thực tế, họ có thể học thêm chuyên đề, bổ sung kiến thức liên quan khác trong ngành kinh tế, chính, kế toán… Điều này thường có trong các dự án triển khai sản phẩm ERP. Tuy nhiên, hiện vẫn chưa có một điều kiện bắt buộc, tiêu chuẩn nào cho một BA. Đôi khi, người làm BA cũng xuất thân từ ngành kinh tế nhưng có kiến thức về mảng công nghệ phần mềm vẫn có thể làm việc tốt.

Khách hàng và nhà thiết kế

Công việc đặc trưng của một người làm BA thường sẽ tập trung vào khởi đầu và kết thúc dự án (giao sản phẩm cho khách hàng). Khi bắt đầu 1 dự án, người làm BA cần phải tiếp xúc khách hàng, lấy và nắm yêu cầu khách hàng, làm rõ yêu cầu của khách hàng sau đó phân tích yêu cầu của khách hàng. Xem thử những yêu cầu đó có thể “tin học hóa” được hay không. Vì rất nhiều khách hàng không có nhiều kiến thức chuyên môn về CNTT hoặc đôi khi yêu cầu hoặc mong muốn của khách hàng thâm chí chưa rõ rang. Lúc này, vai trò của người BA lại trở thành người tư vấn viên để tư vấn quy trình cho họ.

Chị Anh cho biết, khi có dự án mới, chị thường đọc hiểu tài liệu khách hàng cung cấp, tìm hiểu nhu cầu của khách hàng. Đối với những vấn đề chưa hiểu, chưa rõ, chị liên hệ với khách hàng để làm rõ thêm. Theo chị, có thể dùng nhiều cách như tổ chức hội thảo – workshop để thảo luận, nhờ BA hay trưởng dự án (PM) đến tận nơi tìm hiểu, làm rõ thêm yêu cầu, gửi bảng câu hỏi (Q&A) để khách hàng trả lời… Sau đó, BA viết lại yêu cầu khách hàng dưới dạng tài liệu đặc tả yêu cầu hệ thống (System Requirement Specification, SRS), dưới dạng sơ đồ người dùng (Use Case), yêu cầu nghiệp vụ (Business requirements), yêu cầu chức năng (Functional Requirements)  và các yêu cầu khác. Trong đó, đa phần là sử dụng ngôn ngữ UML. Đây cũng chính là công việc quan trọng nhất vì nó ảnh hưởng tới toàn bộ phần sau của dự án như thời gian hiện thực, khả năng hiện thực dự án, độ khó và tính chi phí cho khách hàng.

Sau khi có SRS, BA sẽ gửi cho khách hàng xác nhận độ chính xác của tài liệu; Trình bày về hệ thống cũng như các tài liệu liên quan cho Developer và kiểm thử viên phần mềm (Tester) thực hiện công việc. Hỗ trợ đội dự án khi lập trình và kiểm thử phần mềm. Sau khi sản phẩm hoàn chỉnh và được tester thông qua, BA phải duyệt lại sản phẩm dưới dạng kịch bản (scenarios) ban đầu theo yêu cầu người dùng cuối. Khi sản phẩm được BA thông qua, thì sẽ được giao cho khách hàng. Trong tất cả những công đoạn trên, bước nào cũng quan trọng và cần sự cẩn thận tuyệt đối vì nếu có bất kỳ sai sót nào của BA cũng có thể dẫn đến việc hiểu sai yêu cầu của khách hàng. Và nghiêm trọng nhất, dẫn đến việc khách hàng không chấp nhận sản phẩm do đội dự án tạo ra.

Anh Minh chia sẻ, một công việc khác nữa của một người làm BA là theo dõi trong quá trình thực hiện dự án để đảm bảo các bước thực hiện dự án đi theo đúng hướng và phù hợp với các yêu cầu thông qua các công cụ đặc trưng. Người làm BA đa phần cũng sẽ là người quản lý những yêu cầu thay đổi trong quá trình thực hiện dự án, đánh giá sự ảnh hưởng của yêu cầu thay đổi lên dự án và có dự đoán chính xác về sự điều chỉnh thời gian cũng như sự điều chỉnh nghiệp vụ liên quan. Vào cuối dự án, BA đôi khi lại là người chịu trách nhiệm như một người làm QC hay QA, kiểm tra sản phẩm thỏa mãn các yêu cầu ban đầu trước khi giao cho khách hàng.

Trong quá trình thực hiện dự án, người làm BA ở phía nội bộ dự án thì BA như là khách hàng, nắm vững các yêu cầu. Vì vậy, họ có thể trả lời các câu hỏi liên quan tới yêu cầu trong quá trình phân tích. Ngược lại, khi gặp khách hàng, BA lại ở vai trò người thiết kế/lập trình cho dự án và phải trả lời được đa số các vấn đề kỹ thuật của dự án, hoặc giải thích những thay đổi trong cấu trúc kỹ thuật của dự án.

Những khó khăn

Theo anh Minh, làm nghề BA có 2 vị trí/vai trò, và mỗi vai trò có cái khó riêng của nó. Khi ở gặp khách hàng, thì nhiều khách hàng sẽ không hiểu vấn đề kỹ thuật. Làm sao để truyền tải được những vấn đề kỹ thuật cho khách hàng hiểu theo suy nghĩ người làm kinh doanh là cả một vấn đề.

Hơn nữa, cái khó lớn nhất khi làm BA đó là khả năng lấy thiếu yêu cầu. Đôi khi chính khách hàng cũng không nghĩ là người ta đã đưa đủ yêu cầu, vì có 1 số trường hợp đặc biệt hoặc lâu lâu mới xuất hiện thì người ta không thể nhớ mà báo cho mình. Điều này rất nguy hiểm và là lý do thất bại của nhiều dự án. Một cái nữa khi làm BA là ở phía nội bộ, có những vấn đề nghiệp vụ ví dụ như kế toán hoặc thuế chẳng hạn, truyền đạt kiến thức quy trình cho những người lập trình vốn không chuyên cũng là cả một vấn đề.

Anh Minh chia sẻ, cách đây vài năm, khi lấy yêu cầu của một công ty làm chuyên về nghiệp vụ cung cấp địa chỉ nhà và dịch vụ bất động sản ở Đức, trong đó có một phần cho phép người ta tính toán giá trị nhà, giá trị vay vốn. Khó khăn là văn phòng này chỉ làm môi giới, chưa bao giờ làm việc này trước đây (công ty bất động sản cung cấp thêm cho khách hàng như một dịch vụ tiện ích) nên đã đưa một công thức tính toán sai. Cũng may, lúc đó tôi đã tìm cách kiểm tra lại công thức và cảm thấy không hợp lý. Ngay sau đó, tôi phải liên hệ với rất nhiều chuyên gia trong lĩnh vực ngân hàng để tìm hiểu và cuối cùng mới có công thức chính xác.

Cũng trong dự án bất động sản này, khách hàng chỉ yêu cầu có 10 trường (field) dữ liệu được chuyển đổi và tính toán. Nhưng sau đó, khi yêu cầu chuyển dữ liệu mẫu qua để phân tích thì mới phát hiện số lượng field cần xử lý nó không cố định và có thể nhiều hơn 10. Vì vậy, tôi và đội dự án phải điều chỉnh kiến trúc sản phẩm, để có thể nhận dữ liệu với số lượng fields từ hệ thống khách hàng là động. Về sau, khách hàng yêu cầu nhận thêm dữ liệu từ một hệ thống khác của một chi nhánh khác. Lúc đó, công ty của tôi đã tiết kiệm rất nhiều thời gian mà không phải phân tích và kiến trúc lại phần mềm do lúc phân tích yêu cầu đã tính toán trước những vấn đề này dù khách hàng không yêu cầu từ đầu, anh Minh chia sẻ.

Có 2 khái niệm không được rõ ràng lắm. Đó là BA (Business Analyst) va SA (System Analyst). Theo lý thuyết, BA là người làm việc trực tiếp với khách hàng, lấy cụ thể của khách hàng và tạo ra những tài liệu yêu cầu người dùng (User Requirement Document). Trong tài liệu này, mọi yêu cầu được mô tả chung chung và bằng ngôn từ của người sử dụng. SA là người phân tích tài liệu do BA tạo ra (nghĩa là phân tích User Requirement) và viết lại thành một tài liệu chi tiết hơn, phân tích sâu hơn những yêu cầu đó và được gọi là tài liệu hệ thống thông tin (System Requirement Document). Khi đó, Developer và Tester có thể dựa trên tài liệu này mà hiện thức hoà lại chương trình. Công việc hiện tại của tôi có khi là BA, có khi là SA và cũng có khi làm đảm nhận cả 2 công việc của BA và SA. Điều này tuỳ thuộc cụ thể từng dự án.
Chị Tô Việt Anh, Chuyên viên phân tích hệ thống Công ty phần mềm FPT.

Điều làm chị Anh nhớ nhất và là một kinh nghiệm không bao giờ quên cho bản thân chị là “sự khác biệt khi làm việc với khách hàng am hiểu về CNTT và người dùng cuối thực thụ”. Với khách hàng am hiểu về CNTT (làm việc với bộ phận CNTT của một công ty nào đó), khách hàng sẽ rất dễ dàng duyệt hay đưa ra một quyết định nào đó về những ràng buộc trong chương trình. Hai bên có thể trao đổi và chọn cách phù hợp nhất. Nhưng khi làm việc với người dùng cuối, BA phải là người tư vấn và đôi khi đóng vai trò quyết định giúp khách hàng. Điều quan trọng nhất là phải bám sát nhu cầu thực sự của khách hàng để đưa ra những tư vấn hợp lý cho cả hai bên. Điều này hầu như dựa vào kinh nghiệm làm việc do bản thân đúc kết được.

Vì quyền lợi khách hàng

Anh Minh chia sẻ, nghề BA hiện vẫn chưa được coi trọng, một phần là đa số các dự án ở Việt Nam đều là dự án không phức tạp. Vì vậy, để tiết kiệm đa số các công ty đều cử các lập trình viên đi để lấy yêu cầu và viết tài liệu khá đơn giản. Phía khách hàng, họ cũng không yêu cầu vì tiết kiệm thêm chi phí. Trong khi ở nước ngoài, các dự án từ 10.000 USD trở lên đều phải có BA. Các dự án lớn ở trong nước thì công ty mới có những người làm BA nhưng đa số là kiêm nhiệm từ lập trình viên.

“Trong khi ở nước ngoài, BA là một người lương khá cao cũng như được đánh giá khá quan trọng trong các dự án. Làm BA có những niềm vui riêng như cơ hội giao tiếp với nhiều khách hàng khác nhau, tìm hiểu nghiệp vụ khác nhau. Chính vì vậy, cũng tôi luyện cho cá nhân tôi thêm nhiều kinh nghiệm và vốn sống hơn. Tuy vậy, thử thách trong nghề BA là không ít. Riêng việc gặp khách hàng và lấy yêu cầu, nếu như phía khách hàng hợp tác thì tốt. Một số trường hợp hay gặp phải là nhân viên nghiệp vụ ở khách hàng không hợp tác hoặc hợp tác nhưng không hợp tác hết mình vì một số lý do gì đó (có thể như ngại tin học hóa vì sợ mất việc hoặc sợ lộ các thông tin tài chính không rõ ràng…). Điều đó làm việc lấy yêu cầu dễ dàng bị lệch hướng”, anh Minh nói.

Trong nghề BA cũng hay gặp phải chuyện “dở khóc dở cười” khi làm việc với các lập trình viên. Đôi khi, tôi phải rất defensive (hình thức bảo vệ ý kiến, chống đối với đội dự án) vì lập trình viên luôn đẩy những vấn đề khó, lỗi hoặc trách nhiệm về 1 người khác. Trong khi đó, khách hàng bỏ tiền ra không thể chấp nhận được những lập luận như vậy. Và BA phải là “khách hàng” của lập trình viên và phải đấu tranh rất nhiều trong chính nội bộ nhóm.

Triển vọng nghề BA

Thực tế, khó khăn hiện nay là sinh viên muốn theo nghề nhưng chưa có trường, lớp nào đào tạo BA. Vì thế, mọi thứ đều phải tự rèn luyện và học hỏi kinh nghiệm từ những thế hệ đi trước, những dự án vừa làm vừa học. Ngoài ra, công việc BA thì hầu như ít được tuyển dụng. Đa phần chỉ những công ty lớn, có quy trình rõ ràng chuyên về phần mềm thì mới tuyển BA.

Theo chị Anh, nói đến tố chất để theo đuổi nghề này, thì điều đầu tiên phải có sự yêu thích, đam mê, nhưng chưa đủ, cần phải có tư duy logic và khả năng nhìn nhận, suy luận vấn đề, khả năng giao tiếp (không những với khách hàng bên ngoài mà còn trong nội bộ nhóm làm việc của bạn). Đó là điều kiện tối thiểu mà BA cần có. Hơn nữa, bạn nhất định phải có kiến thức cơ bản về máy tính (hay nói cách khác, bạn nên học ngành CNTT) và ít nhất 2 năm lập trình.

Theo anh Minh, trong vài năm tới nhu cầu BA sẽ tăng trưởng nhanh chóng. Các doanh nghiệp ngày càng nhận ra tầm quan trọng của CNTT trong kinh doanh, trong quản lý. Vì vậy, doanh nghiệp sẽ có nhu cầu nhiều hơn trong lĩnh vực tin học hóa các hoạt động của mình. Lúc đó, những người làm BA sẽ thực sự được trọng dụng. Riêng hiện nay, nhu cầu BA chỉ có ở các công ty lớn hoặc các công ty có nhu cầu làm dự án lớn với khách hàng nước ngoài như châu Âu, châu Mỹ, Nhật bản. 

PC World Việt Nam, ấn phẩm B, số tháng 4/2011

./.

2 thoughts on “Business Analyst: Người làm thông dịch viên

  • Hah, thanks for posting this! I couldn’t find anywhere the PC world this month to read the article. Just now I know more clearly about how you do what you do, which was pretty vague to me before. I had to ask Mr.Google for some jargon used in the post :)).

Để lại phản hồi