Hello anh em 🙂

Như mình có nói trong bài Business Analyst là gì và làm những gì?, một người BA sẽ phải gặp gỡ và kết nối với rất nhiều người. Do đó BA luôn cần aware tới việc nâng cao skill của chính mình.

Bản thân mình tốt lên. Công việc được giải quyết nhanh gọn hơn. Anh em sẽ có nhiều thời gian hơn để tiếp tục rèn luyện và nâng cao chất lượng công việc.

Vừa rồi mình có đọc trong cuốn BABOK ver3.0 có phần nói về các Knowledge Areas của 1 người làm BA. Cụ thể là các kỹ năng, các khía cạnh mà BA cần chú ý tới. Bài này mình share cho anh em những gì mình biết và đã tìm hiểu 🙂

BABOK ver3.0 đưa ra một bộ các kỹ năng và kiến thức cần có, gọi là Knowledge Areas. Knowledge Areas được thể hiện như hình dưới.

Kỹ năng của Business Analyst

Knowledge Areas đối với Business Analyst

1. Knowledge Areas

Thường thì anh em sẽ gọi cụm “Knowledge Areas” là nhóm những kỹ năng cần thiết của BA. Nhưng mình nghĩ thay vì gọi nhóm kỹ năng thì gọi là nhóm kiến thức có vẻ ổn hơn.

Vì những thứ dưới đây không chỉ đơn thuần là kỹ năng. Không chỉ đơn thuần thông qua rèn luyện mà có được. Mà còn phải có kiến thức cơ bản. Rồi từ đó mới áp dụng vào thực tế. Trải qua nhiều dự án rồi rút kinh nghiệm mới thẩm thấu được.

1.1. Biết tự lên kế hoạch và tự theo dõi được 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.

Nhóm kiến thức về planning và monitoring được đưa lên đầu trong sơ đồ bởi vì tầm quan trọng và độ bao quát của nó. Anh em cũng biết là planning thì không có sai hoặc đúng. Mà chỉ là planning có phù hợp hay không mà thôi. Phù hợp là đảm bảo được giữa resources hiện có và đáp ứng được 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 nữa. Và việc này đòi hỏi phải tích lũy nhiều kinh nghiệm.

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.

Lên kế hoạch làm việc

Plan anh em eiii…!!!

Thường thì mình sẽ thấy thoải mái và có động lực làm việc hơn khi có mục tiêu rõ ràng.

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

Đầu tiên thì phải lên kế hoạch, tuần này làm gì, ngày này làm gì. Bám sát kế hoạch và chủ động thay đổi nếu có phát sinh giúp mình làm chủ được công việc. Không cần chém gió đâu xa, đây chính là Planning and Monitoring trong công việc của chính mình (y)

Trên công ty chỗ mình ngồi có 2 cái bảng nhỏ. Sáng lên công ty mình hay viết lên cái bảng này những thứ mà mình muốn làm trong ngày. Thường là 3 hoặc 4 tasks. Ngồi làm là luôn nhìn thấy nó. Đập thẳng vào mặt mình luôn, nên luôn auto nhớ, muốn quên cũng không được :v

1.2. Biết “moi móc” và “cấu kết” với anh em (elicitation & collaboration)

a) Moi móc thông tin

Elicit là động từ, danh từ là Elicitation, nghĩa là moi móc, đào bới. 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.

Anh em xem thêm bài mình chém gió về Requirement và Moi móc thông tin nhé.

Fiction writing 🙂

(Nguồn: www.modernanalyst.com)

b) Collaboration – Cấu kết?

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 :3

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.

Tuy đây không phải là một trong những yêu cầu công việc của BA, nhưng BA nên có nhận thức về điều này. Nó như một underlying responsibility của BA. Điều này sẽ giúp công việc của team trơn tru hơn.

Và dĩ nhiên, làm tốt thì sẽ rất là tốt, làm không khéo có thể gây ra những ảnh hưởng tiêu cực khác. Nên chủ đề của bài này vẫn mong anh em luôn chú trọng nâng cao kỹ năng và kiến thức của mình. Từ đó giúp giải quyết công việc một cách hiệu quả hơn :3

Trong 4 Knowledge Areas còn lại, mình chưa nhiều kinh nghiệm nên góc nhìn có thể hơi hẹp. Do đó những chia sẻ mang tính cá nhân trong những phần này không nhiều lắm. Mình sẽ cố gắng giải thích theo BABOK ver3.0 để anh em có cái hiểu và góc nhìn cơ bản nhất nhé.

1.3. Quản lý tốt các 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ý. Yêu cầu của dự án thường rất hay thay đổi hoặc thêm mới. Có sự thay đổi lớn, có sự thay đổi nhỏ. Nhưng nhìn chung nếu không kiểm soát tốt, nó sẽ ảnh hưởng tiêu cực đến dự án ở rất nhiều 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.

Thường thì dự án sẽ được triển khai theo nhiều phương pháp, thường thì là: Waterfall, RUP hoặc Agile. Mỗi phương pháp đều có đặc điểm riêng. Và requirements trong các phương pháp này cũng rất khác biệt.

Thường thì trong dự án triển khai theo kiểu Waterfall hay RUP, requirements được chốt rất rõ ràng ngay từ đầu. Trong quá trình triển khai, sự thay đổi là có nhưng không đáng kể. Còn Agile thì lại welcome to change. Mật độ thay đổi requirement trong những dự án này khá thường xuyên. Do đó, trong mỗi dự án lại có cách quản lý requirement khác nhau.

Nhưng quan trọng nhất, 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ý.

1.4. Hiểu được hướng đi lâu dài của doanh nghiệp

Một người làm Business Analyst cần hiểu rõ và xác định được nhu cầu thật sự của doanh nghiệp. Đặc biệt rất cần thiết để hiểu về chiến lược và hướng đi lâu dài của doanh nghiệp đó trong tương lai.

Giải pháp mình đề xuất đáp ứng được nhu cầu hiện tại của doanh nghiệp. Nhưng liệu nó có mapping được với hướng đi lâu dài của doanh nghiệp trong tương lai hay không cũng là một vấn đề nên được chú ý ngay từ lúc tiếp cận dự án.

Mình nghĩ Knowledge Areas này thể hiện khá rõ nét ở vai trò Business Requirement Analyst được nhắc đến trong bài Business Analyst là gì và làm những gì? Anh em tham khảo thêm nhé.

1.5. Phân tích requirement và đưa ra solution

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
  • Specify rõ các loại requirement
  • Verify requirement với internal team
  • Validate các 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.
  • 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.

Knowledge Area này thể hiện một chuỗi các hoạt động lặp đi lặp lại. Và diễn ra vô cùng thường xuyên, gần như là cốt lõi công việc của một bạn BA trong dự án.

1.6. Tự đánh giá về solution của cả team

Một người làm Business Analyst cần phải deliver được cho khách hàng những giải pháp phù hợp và hiệu quả nhất. Như đã 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 doanh nghiệp.

2. Soft Skills

Ở phần này mình sẽ giới thiệu cho anh em một vài soft-skill của BA, nhưng mà với góc nhìn có thể hơi… khác chút xíu so với bình thường.

2.1. Analytical thinking

Trước giờ mình cứ nghĩ analytical thinking là cái gì ghê gớm lắm. Nào là phải tư duy có logic, có lý lẽ và có luận cứ mạch lạc với nhau. Đó có thể là một cách nghĩ đúng và phù hợp trong một vài khía cạnh hoặc góc nhìn nào đó.

Nhưng trong bối cảnh Business Analyst, mình muốn giới thiệu với anh em một góc nhìn mới.

Analytical thinking là Conceptual và Visual.

  • Conceptual là góc nhìn theo hơi hướng trừu tượng và khái quát về một vấn đề
  • Còn Visual là góc nhìn mang hơi hướng trực quan và cụ thể.

Khi làm việc với khách hàng, nói về concept chung của phần mềm có thể sẽ gây confuse cho khách hàng. Vì họ chưa hình dung được đó là gì hết, vẫn còn chung chung, trừu tượng quá (đó là Conceptual). Thay vào đó, việc demo ngay các chức năng trên phần mềm có lẽ sẽ khiến khách hàng dễ hình dung hơn (đó là Visual).

Visual thinking

Visual thinking cho phép khách hàng “nhìn được”, “tưởng tượng được” và “phản xạ” hình ảnh đó ngay trong đầu.

Nguồn: In-tờ-nét

2.2. Creative & Innovative

Creative là cần thiết đối với một người làm Business Analyst, nhưng đôi khi cũng cần phải innovative để nâng cao hiệu quả công việc. Vậy creative và innovative khác gì nhau?

Creative là biết làm, biết cách để làm, nói về cách làm, thường nghiêng về smart.

Còn Innovative mới thật sự là sáng tạo, nghĩ khác, tạo ra cái mới, cách làm mới.

2.3. Leadership

BA đóng vai trò như một người Leader vô hình trong team. Họ nắm rất nhiều thông tin và vô hình dung, điều này làm cho họ trở nên quan trọng.

Họ có thể giải đáp và tháo gỡ bất kỳ thắc mắc nào của các thành viên trong team. Do đó, tầm ảnh hưởng của họ trong team đến các thành viên khác là rất có trọng lượng.

Leadership luôn là kỹ năng cần thiết với bất kỳ ngành nghề nào, không chỉ riêng đối với một người làm Business Analyst

Qua bài này, mình hi vọng anh em hiểu được:

  • 6 Knowledge Areas cần có của BA
  • 3 Soft Skills cũng rất cần có của BA

Hiểu và cố gắng áp dụng nó vào công việc và cuộc sống. Mình cũng đang cố gắng từng ngày, nhưng nhớ áp dụng một cách linh hoạt và đừng rập khuôn 🙂

Cảm ơn anh em đã đọc đến dòng này. Hẹn gặp anh em ở bài sau. Bái baiii!

Nguyen Hoang Phu Thinh

Hello anh em! Mình là Thịnh, hiện tại mình đang làm Business Analyst tại RBVH. Mình đang tập viết, tập đọc sách và góp nhặt những trải nghiệm trong nghề BA trên blog này. Hi vọng những chia sẻ của mình sẽ giúp ích được anh em 🙂 Read more about me