Kiến thức cần có của một BA (Business Analyst)

Business Analyst thường bị nhầm lẫn với vị trí marketing vì chức năng cũng gần như nhau (Tìm hiểu, thuyết phục khách hàng, bàn giao sản phẩm, …). Tuy nhiên, ở bài viết này mình sẽ nói về kĩ năng đặc thù của một người BA nhé …

Lên kế hoạch và theo dõi tiến độ

Planning và Monitoring, đây là 2 kỹ năng không thể thiếu của một người làm Business Analyst. Đây là hai kỹ năng có ảnh hưởng trực tiếp đến các đầu mối công việc trong dự án.

Anh em cũng biết là planning thì không có sai hoặc đúng, mà chỉ là phù hợp hay không mà thôi. Phù hợp là đảm bảo được những resources hiện có và yêu cầu của dự án.

Resources là cả về nhân lực, vật lực và cả khả năng tiếp cận được công nghệ mới.

PM đưa ra plan cho dự án có sát với thực tế hay không, tùy thuộc rất nhiều vào kinh nghiệm của anh này.

Một anh BA lên plan cho internal team cùng làm việc. Hay đơn thuần là những task công việc cho chính bản thân, cũng đòi hỏi phải tích lũy nhiều góc nhìn và trải nghiệm thì mới sát thực tế được.

Có kế hoạch, mục tiêu rõ ràng sẽ giúp công việc được trơn tru hơn.

Từ những mục tiêu nhỏ, đạt được nó, rồi đi tiếp đến một mục tiêu khác. Tiếp tục đạt được nó, rồi lại đi tiếp đến một mục tiêu khác. Đạt được nó, đạt được nó và mình sẽ đạt được mục đích đề ra ban đầu từ việc đạt được những mục tiêu nhỏ này.

Như vậy, mình có thể keep track được tiến độ công việc. Điều này mang lại sự chủ động trong công việc. Và dĩ nhiên, xuất phát điểm phải bắt đầu từ những việc nhỏ.

Điều này giúp mình bám sát kế hoạch và chủ động thay đổi nếu có phát sinh. Và đặc biệt là nó giúp mình luôn ở thế chủ động, không bị task đè.

Moi móc thông tin — Elicitation

Đây là khái niệm khiến bạn dễ dàng nhầm lẫn giữa Marketing và Business Analyst.

Trong bối cảnh Business Analyst, elicit nghĩa là moi móc thông tin nhằm lấy được requirement. Dùng eilicit chính xác hơn so với get, hay gather.

Elicit là moi móc những thông tin từ khi nó còn “chưa tồn tại", chưa được hình thành nữa. Thường là thông tin chưa có sẵn, chưa được phát biểu ra (unstated). Mình phải moi móc, phải elicit cho ra được thông tin, thành thông tin đã được phát biểu (stated).

Còn get hay gather thường chỉ dùng cho những thông tin đã có sẵn. Mình chỉ việc lấy về hoặc tập hợp lại thôi. Giống như đi hái hoa bắt bướm thì hoa với bướm có sẵn rồi, chỉ đi bắt, đi lụm về thôi. Còn requirement thì đâu dễ ăn như vậy.

Marketing thì nhẹ nhàng với KH còn BA cần tích cực bới móc, tra hỏi càng nhiều thông tin càng tốt.

Cấu kết với anh em — Collaboration

Collaboration, nghĩa là cộng tác, hợp tác, cấu kết với anh em cùng làm 1 cái gì đó, tốt cho dự án.

Không chỉ đơn thuần là teamwork, mà một người BA còn phải làm cho cả team cộng tác với mình và cộng tác với nhau một cách hiệu quả nhất.

Làm việc tốt với mọi người vẫn là chưa đủ. BA cần phải đảm bảo các thành viên khác làm việc trơn tru và hiểu ý nhau nữa.

Là một người nắm nhiều thông tin trong dự án, nên kết nối mọi người là “nghĩa vụ cao cả" của một người làm BA.

Lấy đủ yêu cầu nhưng không có anh em nào cùng làm thì cũng bằng 0

Nghe có vẻ không liên quan, nhưng anh em hãy thử hình dung như thế này nhé.

Một anh tester và một anh dev xích mích với nhau về một tính năng. Ai cũng có lý của mình hết. Lúc này người nắm nhiều thông tin nhất là BA, sẽ nhảy vào can thiệp để giải quyết vấn đề cho mọi người.

BA sẽ cố gắng giải thích theo góc độ lập trình và cả góc độ người dùng để hai bên thấy rõ được góc nhìn của nhau.

Quản lý requirements

Có bốn loại requirement trong một dự án:

• Business Objective Requirements

• Stakeholder Requirements

• Solution Requirements

• Transition Requirements

Việc quản lý dòng đời các requirements bắt đầu từ lúc khởi tạo cho đến khi các requirements được xử lý.

Thực tế thì requirement rất hay thay đổi hoặc thêm mới. Thay đổi lớn có, nhỏ có. Tùm lum tùm la hết. Và dĩ nhiên, nếu không kiểm soát tốt, nó sẽ là một mớ hỗn độn, phá nát dự án ở mọi khía cạnh (từ time, budget, scope cho đến resources).

Không phải lúc nào cũng gật đầu “accept" một requirement mới. Và không phải lúc nào cũng “reject" những requirement mới này.

Mọi yêu cầu thay đổi đều trả giá bằng thời gian, tiền bạc.

anh em BA cần phải học cách:

• Hiểu được sự xuất hiện của các requirement.

• Kiểm soát được các requirement từ lúc khởi tạo, có sự thay đổi cho tới khi được xử lý >> control được sự kỳ vọng từ phía users.

Hiểu về chiến lược của khách hàng

Hiểu về chiến lược của khách hàng là sao?

Khi làm giải pháp, rõ ràng anh em phải nắm được giải pháp đó làm ra, để giải quyết vấn đề gì. Và rồi mình mapping vấn đề đó với bối cảnh hiện tại của khách hàng, xem thử có suy ra được điều gì đáng chú ý hay không.

Từ đó, anh em mới có góc nhìn rộng nhất về tổng quan bài toán mà khách hàng đang gặp.

Ví dụ mình đang làm giải pháp CRM cho một doanh nghiệp F&B. Cái sâu sa họ muốn là gì, có phải chỉ đơn thuần là 1 giải pháp quản lý bán hàng? (trong khi thực tế là họ vẫn đang chạy một con local CRM rất ngon).

Thu gom nhiều yếu tố, mình có thể suy ra được: họ đang muốn chuyển đổi toàn bộ giải pháp IT của họ. Từ nhiều cục, họ muốn tất cả centralize lại thành một cục, một nền tảng, nhưng có nhiều giải pháp trong đó.

Họ vừa chuyển đổi thành công ERP sang nền tảng Microsoft, giờ tiếp theo sẽ là CRM, sau đó là e-Office, POS và kể cả toàn bộ cơ sở hạ tầng.

Đó chính là mong muốn sâu sa nhất của họ. Những giải pháp hiện tại chạy tốt, nhưng về cơ bản, nó đang không tập trung, và data vẫn đang nằm rải rác rất nhiều nơi. Và điều này không đáp ứng được hướng đi lâu dài của BOD.

Khi hiểu được điều này, anh em sẽ có hướng tiếp cận khách hàng phù hợp hơn. Cách đề xuất và đánh giá giải pháp phù hợp hơn, so với việc, chỉ nghĩ một cách đơn giản cục bộ là họ chỉ đang cần một giải pháp về CRM.

Yêu cầu “Đúng" không dễ dàng mà nghĩ ra được.

Giải pháp mình đề xuất đáp ứng được nhu cầu hiện tại của khách hàng. Nhưng nó cũng phải map được với hướng đi lâu dài của họ trong tương lai.

Phân tích và thiết kế

Analysis and Design, chắc chắn ai làm Business Analyst cũng đều làm cái này.

Requirement Analysis and Design để đơn giản thì mình có thể hiểu là một loạt các việc bao gồm:

• Tổ chức và sắp xếp các requirement một cách có cấu trúc.

• Phân loại rõ các loại requirement.

• Verify requirement với internal team.

• Validate requirement với khách hàng.

• Làm tài liệu và mô hình hóa các requirement phù hợp với từng stakeholders cụ thể.

• Cùng với team đề xuất solutions phù hợp.

• Xác định những solution nào đáp ứng được business needs.

• Có thể là ước tính được những giá trị mà solution đó mang lại như thế nào so với các solution khác. Hoặc có thể show cho khách hàng thấy Return On Investment là như thế nào.

Đánh giá giải pháp

Cái này thì rõ ràng quá rồi chứ hả anh em.

Không thể nào đi thuyết phục khách hàng ăn một món ăn dở, mà ngay cả mình cũng ghét nữa 🙂 Mình phải đánh giá một cách rất khách quan và tâm huyết với giải pháp mình đem lại thì mình mới có thể deliver một cách hoàn chỉnh nhất có khách hàng được.

Như mình có nói ở trên, không chỉ hiệu quả trong thời điểm hiện tại mà còn phải phù hợp với hướng đi lâu dài của khách hàng.

Làm hời hợt thì mất khách, mất dự án các bạn nhé.

Kết luận

Đây là bài viết mình trích ra từ bài viết gốc của anh Thịnh — Một BA lão làng của công ty Bosch. Xem full HD tại đây:

https://thinhnotes.com/chuyen-nghe-ba/nghe-cua-business-analyst/

Ai đã đọc tới đây thì đừng bảo BA cũng giống như làm Marketing nha tui khóc á.

Happy Coding!