Oct 27, 2016

IT Business Analyst (IT BA) - Sự khác biệt giữa Senior và Junior?

Requirement Analysis

“Vậy thế nào là một BA chuyên nghiệp?”
“Giữa Junior BA (BA mới vào nghề) & Senior BA (BA đã có kinh nghiệm) sẽ khác nhau những gì?”

Đi từ cái ý nghĩa của nó cũng dễ khiến người nghe thấy ngay sự khác biệt. Thế thì có bao giờ bạn tự định nghĩa 2 từ “Junior” và “Senior”? Thông thường nếu bất ngờ được hỏi, người ta sẽ trả lời chung chung “Một người Senior dĩ nhiên là giỏi hơn rồi”. Nhưng giỏi hơn là như thế nào? Là kiến thức nhiều hơn, là làm được nhiều việc khó hơn?

Nói riêng trong lĩnh vực kỹ thuật thì chưa chắc gì một người mới ra trường sẽ thua kém một người làm việc lâu năm, vì công nghệ mới luôn được cập nhật liên tục. Với thời đại “internet làm phẳng thế giới” như hiện nay thì lượng thông tin truyền tải đến mỗi người là như nhau, nên thường người trẻ sẽ có xu hướng tiếp cận và nắm bắt thông tin, công nghệ kỹ thuật mới một cách linh hoạt, nhanh chóng hơn. Nên nếu nói rằng Senior “giỏi” hơn Junior cũng chưa hẳn là đúng.

Hôm trước, một anh bạn của tôi đã cho tôi câu trả lời mà tôi thấy hợp lý: “Ngoài chuyện làm được công việc mang tính phức tạp hơn, một người Senior còn làm việc ÍT LỖI hơn Junior”.

Thực tế, không ai làm việc mà không có lỗi, và việc đánh giá hiệu quả công việc có tốt hơn hay không thì chỉ có cách là xét về độ ổn định, ít lỗi. Một người chuyên nghiệp khi làm việc, họ luôn thấy được những rủi ro tiềm ẩn, có sự tính toán để phát triển hệ thống lâu dài, thái độ làm việc rõ ràng và khả năng hợp tác nhóm tốt .

Thông thường với một BA, thì những yếu tố nói trên là đặc tính mà mỗi BA cần có, và các nhà tuyển dụng cũng xem những tiêu chí này là một trong những tiêu chuẩn để họ chiêu mộ nhân tài. BA là “Connector” - người kết nối các thành viên trong nhóm, là người viết ra những tình huống nghiệp vụ (Business case) cho đội ngũ phát triển (Development team). Ở giai đoạn đầu, BA thường luôn phải làm việc nhiều hơn, vì vậy mà những tài liệu yêu cầu càng được định nghĩa rõ ràng và đồng bộ bao nhiêu, thì càng tiết kiệm được nhiều thời gian, chi phí cho việc phát triển sau này bấy nhiêu.

Tại Việt Nam, để cho định nghĩa bớt mập mờ, tôi tạm phân loại nghề IT BA thành 2 dạng (dựa theo tính chất của dự án/công ty phần mềm): Outsourcing BA (có thể gọi là BA cho các dự án thuê ngoài) và Inhouse BA (BA làm việc cho các dự án nghiệp vụ nội bộ). Điều này không phụ thuộc vào bản chất của công ty đó là Outsourcing hay Product, mà phụ thuộc vào tính chất dự án và phương thức làm việc được xác định từ ban đầu. Tạm thời tôi định nghĩa 2 khái niệm này như sau (đã là một BA thì trước khi đưa ra từ gì cũng phải cho định nghĩa của từ ấy):

Inhouse BA: Khách hàng chỉ đưa yêu cầu rất sơ sài (High-level requirement), và BA được thoả sức tìm kiếm và phân tích, chuyển đổi thành ngôn ngữ kỹ thuật, thiết kế các hoạt động hệ thống (System behavior),… miễn sao đáp ứng được đúng yêu cầu và nằm trong phạm vi (Scope) dự án. Ở vị trí này, BA được “hoành hành” nhiều hơn, có nhiều đất “dùng não” hơn, đúng nghĩa “Business/System analyzing” hơn. Làm việc với những dự án này đòi hỏi BA phải có nhiều kinh nghiệm về lĩnh vực liên quan đến dự án, nhanh nhạy, óc phân tích tốt, và đôi lúc có những ý tưởng táo bạo (Think-out-of-the-box).
Outsourcing BA: Khách hàng gần như đã có đầy đủ tài liệu (khoảng 99%) từ yêu cầu nghiệp vụ thô cho đến kỹ thuật (Technical và Business documents), BA chỉ có nhiệm vụ xem xét và phân rã chúng thành những nhóm công việc/công việc nhỏ hơn phù hợp với tiến độ thực hiện của nhóm và theo từng giai đoạn cụ thể (Phase/ Iteration trong tiến trình Scrum). Ở vị trí này, BA chỉ đơn giản là “biến tấu” các yêu cầu thành Use cases hay User stories và lặp lại những thứ có sẵn, sau đó thực hiện quản lý chúng sao cho mọi thứ diễn ra theo đúng yêu cầu. Có thể nói cho chính xác hơn thì Outsoucing BA chủ yếu đóng vai trò là một người quản lý yêu cầu (Requirement Manager – RM), vì ít khi họ phải ngồi lại phân tích những yêu cầu bởi chúng đã quá rõ ràng.s

Với vị trí là một RM, khi làm việc với dự án đã có 99% yêu cầu được nhận từ phía khách hàng (Product Owner - PO), thì nhất cử nhất động đều phải “đụng” tới PO. PO là những người luôn theo sát từng milimet trên các tài liệu yêu cầu vì họ trả tiền trên từng milimet ấy, dù chỉ là thay đổi một dấu chấm nhỏ, họ cũng xem xét kỹ rồi mới quyết định có cập nhật thông tin hay không.

Và một ngày đẹp trời nào đó, BA vô tình đưa ra một điều “bất thường” vào đấy mà không được PO xác nhận, nếu chỉ là những điều nhỏ nhặt không ảnh hưởng lớn thì không sao, nhưng lỡ có vấn đề phát sinh gây ra hậu quả lớn thì coi như “cả team lãnh đủ”, và BA tha hồ mà bị “thập diện mai phục”.

Trong thực tế, có 1001 các tình huống “dở khóc dở cười” liên quan đến vấn đề này. Một lần, tôi có dịp tham gia 1 ngày training khi làm việc tại một công ty outsourcing lớn. Trainer (giảng viên) là người nước ngoài và lúc nào cũng nhấn mạnh “Always asking”, “Always ask for confirmation”, “Evidences need to be collected/saved by official emails”, “Tracking requirement changes is important”, vì mỗi sự thay đổi đều liên quan đến “tiền” của công ty.

Tóm lại, BA luôn cần có nhưng câu hỏi/xác nhận yêu cầu với khách hàng, và mọi thứ phải được kiểm soát, để sau này có thể gọi vui là làm “bằng chứng trước toà” nếu xảy ra tranh cãi. Vì vậy, người BA ở đây đòi hỏi nhiều kỹ năng về quản lý tài liệu (Documents management), quản lý thay đổi yêu cầu (Tracking requirement change), đòi hỏi sự cẩn thận và kỹ lưỡng là điều cực kỳ quan trọng với một BA làm việc ở dự án outsourching.

Nghề Quản lý yêu cầu (Requirement Manager – RM)

Có lần tôi nói chuyện với một chị Quản lý dự án (Project Maneger – PM) đang làm việc cho công ty IT outsourcing lớn, chị bảo rằng một BA ở nhóm của chị không khác gì “Documenter” hoặc “Repeater” , tức là một người đơn giản chỉ nghe, đọc và lặp lại những thứ có sẵn, vì yêu cầu khách hàng đã quá rõ ràng, nên chị thấy rằng vị trí ấy không quan trọng trong nhóm nữa, bởi việc đọc và hiểu thì ai cũng làm được. Nên chị quyết định đào tạo thêm vài kiến thức cho các thành viên nhóm (Team member) về kỹ năng thu thập yêu cầu và xác nhận yêu cầu từ khách hàng mà không cần vai trò BA, vì vậy nhiều lúc cũng đỡ rủi ro hơn khi xảy ra trường hợp BA đọc-hiểu sai yêu cầu. Tôi thấy quyết định của chị hoàn toàn hợp lý, vì với một PM dày dặn kinh nghiệm, cùng một đội ngũ đủ mạnh cộng thêm việc giao tiếp tiếng Anh lưu loát khi gặp khách hàng, và lại áp dụng quy trình Scrum chặt chẽ thì vị trí BA ở đây nói thật là “không cần thiết”. Trong tình huống này, nghề BA dường như bị lỗi thời, thừa thải (nghe có vẻ hơi buồn ấy nhỉ!).

Tuy nhiên vẫn có nhiều đất “dụng võ” cho một BA trong những trường hợp “éo le” như vậy. Cụ thể, ở công ty lúc trước tôi làm, khi phải đối mặt với công việc RM, các bạn BA thường chia sẻ với nhau là “Hãy làm việc như một con người chứ đừng như cái máy”. Tức là đừng lặp lại một cách máy móc các yêu cầu của khách hàng, và cứ vịn vào cớ “Getting approval” (tài liệu đã được xác nhận rồi) thì cứ việc làm. Bởi có đôi lúc, bản thân PO cũng vẫn chưa thấy được rõ vấn đề của họ cùng nhiều khả năng tiềm ẩn phía sau.

Chính vì vậy, một BA chuyên nghiệp là phải biết cách tư vấn (Consult), thuyết phục khách hàng đi theo đúng hướng và hợp lý (Reasonable). Tốt hơn hết, BA nên dành nhiều thời gian để có được cái nhìn toàn cảnh (Whole picture) của dự án, kết hợp các công việc rà soát (Double-check), tái phân tích (Re-analyzing), tức là phân tích kỹ hơn những gì đã phân tích, để có thể phát hiện thêm những yếu tố tiềm ẩn phía sau. Như vậy thì yêu cầu sẽ chặt chẽ dẫn đến dự án cũng giảm thiểu được nhiều rủi ro.

Tôi nhớ có lần khách hàng đưa ra các yêu cầu phức tạp, chỉ cần nghĩ đến việc phân tích và tái cấu trúc lại một vài chức năng của hệ thống thôi là đã thấy cực kỳ phức tạp, mất nhiều thời gian, lại còn phải hoãn lại công việc khác. Vì vậy, tôi đã ngồi xuống cùng PO và phân tích kỹ chúng, cung cấp cho họ mọi thông tin liên quan, đồng thời đưa ra nhiều giải pháp chọn lựa (Solutions), ước lượng thời gian thực hiện mà nhóm phải bỏ ra (đồng nghĩa với “tiền” của PO) cộng với việc hiệu quả của chức năng mới đem lại, cuối cùng PO đã đồng ý với những lựa chọn thay đổi mang tính đơn giản nhưng hiệu quả, lại tiết kiệm được cả khối thời gian. Hơn nữa, cũng tạo được nhiều niềm tin cho khách hàng là mình đang đứng về phía họ và nghiêm túc nghĩ về chất lượng (Quality) của dự án.

Tóm lại, dù có “bị ném” vào bất cứ loại dự án nào, thì BA cũng phải luôn nhớ rằng: “ít lỗi hơn để chuyên nghiệp hơn”.

Nguồn: Hiệu chỉnh từ Blog - https://thaophuonghoang.wordpress.com

CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất.

Ban biên tập nội dung BAC.

Click để đọc tiếp

Roadmap Business Analyst

Business Analyst (BA) là cầu nối quan trọng giữa nhu cầu kinh doanh và giải pháp kỹ thuật, đảm bảo mọi khía cạnh vận hành hiệu quả. Trong bài viết này, hãy cùng BAC khám phá các công việc chính của một BA dựa theo nhiệm vụ cụ thể, con đường thăng tiến lên vị trí BA Manager.
Data analyst là gì? Mô tả công việc, kỹ năng và nhiều hơn thế nữa

Dữ liệu thô sẽ không có giá trị nếu thiếu đi việc trực quan hóa dữ liệu. Đây là lý do mà Data Analyst (các nhà phân tích dữ liệu) ra đời và chuyển thể hàng trăm nghìn dữ liệu thô thành những thông tin có giá trị, giúp cho các tổ chức ra quyết định một cách sáng suốt.
Từ phân tích đến hành động: Nhà phân tích kinh doanh và giải pháp bền vững

Khi người tiêu dùng ngày càng nhận thức rõ hơn về tác động môi trường mà các doanh nghiệp để lại, chúng ta cũng bắt đầu đòi hỏi sự minh bạch và hành động có trách nhiệm từ họ.
Bí quyết thúc đẩy đổi mới: Phân tích kinh doanh và vai trò phát triển sản phẩm mới

Để có một sản phẩm thành công trước khi ra mắt cần có kế hoạch tỉ mỉ, có sự thấu hiểu sâu sắc về thị trường và quy trình thực thi hiệu quả. Khi đó, phân tích nghiệp vụ chính là điểm giao thoa của tất cả những yếu tố này.

Bình luận

Nguyễn Thị Mai Bình

Business Analyst

Với một người ngoại đạo như mình thì những chuyên đề về "kỹ thuật" của BA hết sức quan trọng. Ví dụ như sử dụng các diagram để mô hình hóa requirement, viết User Story/Use case, v...v..

Đến với khóa học Fundamental Business Analysis, mình đã được gặp thầy Lộc, một người người rất nhiệt tình và có tâm. Ngoài việc chia sẻ các kinh nghiệm thực tế trên lớp thì thầy còn dành thời gian ra để tư vấn, hỗ trợ, góp ý CV cho mình. Bên cạnh đó trung tâm và anh Phụng cũng hỗ trợ gửi CV, kết nối học viên tới mạng lưới các công ty đối tác chất lượng, điều này giúp học viên như mình tìm được công việc phù hợp nhất. Cảm ơn BAC.
Xem chi tiết +
Phạm Quế

Business Analyst

Khoá học Product Design của BAC đã cung cấp cho tôi nhiều kiến thức và nền tảng vô cùng hữu ích. Giảng viên giảng dạy rất nhiệt tình, truyền cho chúng tôi ngọn lửa đam mê và nhiệt huyết trong ngành. Đồng thời chia sẻ các kiến thức và kỹ năng cần thiết trong bài giảng một cách dễ hiểu hơn. Số lượng học viên không quá nhiều nên chất lượng giảng giạy vô cùng tốt. Giảng viên sửa bài tập 1-1 nên bài giảng sẽ chuyên sâu hơn.
Xem chi tiết +
Nguyễn Văn Long

Chuyên viên về chế độ kế toán & Giải pháp nghiệp vụ Tài chính kế toán trong ứng dụng CNTT - Tập đoàn Điện lực Việt Nam (EVN)

Tôi đã tham gia khóa Phân tích nghiệp vụ phần mềm cơ bản 3.0 tại BAC. Ở đây, tài liệu đào tạo cung cấp nhiều nội dung bổ ích và trình bày dễ hiểu. Giảng viên rất nhiệt tình, ngoài nội dung giảng dạy theo giáo trình còn chia sẻ nhiều kinh nghiệm thực tiễn, các câu hỏi của học viên đều được giải đáp ngay trên lớp và có minh họa từ các dự án trong thực tế. Sau tất cả, tôi cảm ơn BAC và Thầy giáo Thái Sơn.
Xem chi tiết +