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 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 note lại 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, đượ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à 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.

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

Đ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 đè 😀

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 bảng 3-4 tasks mà mình muốn làm trong ngày. Ngồi làm là luôn nhìn thấy nó. Đập thẳng vào mặt nên auto nhớ, muốn quên cũng không được 🙂

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

a) Moi móc thông tin – Elicitation

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à chuyện moi móc thông tin nhé.

Fiction writing 🙂

(Nguồn: www.modernanalyst.com)

b) 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 :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 🙂

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

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.

Việc quản lý requirement như thế nào phụ thuộc rất nhiều vào việc dự án được triển khai theo phương pháp nào: Waterfall, RUP hay Agile.

Mỗi phương pháp đều có những đặ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.

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ý >> control được sự kỳ vòng từ phía users.

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.

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

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

Cái này thì rõ ràng quá rồi 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 thật sự đánh giá khách quan và tâm huyết với nó thì 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.

 

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

Thường thì anh em sẽ nghĩ analytical thinking là cái gì ghê gớm, nguy hiể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 (hình chôm trên Google)

2.2. Creative & Innovative

Mình tin là sẽ có khá nhiều anh em không phân biệt rõ 2 khái niệm này. Đều là kiểu sáng tạo, nhưng nó khác nhau ở chỗ:

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

Rõ ràng, hai kỹ năng này là cực kỳ, cực kỳ quan trọng với BA.

2.3. Leadership

BA đóng vai trò như một người Leader vô hình trong team.

Chúng ta sẽ nắm rất nhiều thông tin và vô hình dung, điều này làm cho anh em mình trở nên quan trọng, và nguy hiểm không kém trong team 😎

BA 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 BA 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

 

Ô kê mình sẽ tạm kết bài này ở đây. Hi vọng qua bài này, 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 🙂

Hẹn gặp anh em ở những bài sau. Bái baiii!