Check list các kỹ năng cần phải có của người làm BA (Phần 1)

Bài viết được sự cho phép của tác giả Nguyễn Hoàng Phú Thịnh

Thời gian qua có nhiều anh em hỏi mình về ngành MIS. Và đặc biệt là câu hỏi: sau này ra trường, làm BA thì cần có những kỹ năng – kiến thức chuyên ngành như thế nào???

Do đó, như lời giới thiệu ở trên, chuỗi bài này mình sẽ note về chủ đề: những kỹ năng cần có của một người làm công việc Business Analyst. 

Là một bài khá fundamental, nhưng cũng là dịp để bản thân mình dòm lại: thật sự BA cần có những kỹ năng nào, và liệu mình đã có đủ hết những kỹ năng đó hay chưa.

Bắt đầu thôi nào!

Tổng quan một chút

Trong bất kỳ ngành nghề nào, chúng ta đều cần tới: Kiến thức và kỹ năng cần có của ngành nghề, công việc đó.

Business Analyst cũng vậy, sẽ có:

  • Nhóm các Kiến thức chuyên môn – Knowledge Areas (có thể hiểu là kỹ năng cứng).
  • Và nhóm các Kỹ năng cần thiết – Underlying Competencies (có thể hiểu là kỹ năng mềm).

List dài những kỹ năng dưới đây là mình tham khảo từ BABOK v3.0. Nhìn khá dài và chuối, nhưng anh em khoan hẳn hoang mang, vì mình sẽ cố gắng đưa nó về sát thực tế nhất cho anh em dễ hình dung.

Nếu đọc có gì không ổn, chưa rõ, hoặc cần thảo luận thêm thì cứ quăng mình cái boong, à nhầm, quăng mình cái còm men để tăng tính tương tác nhé anh em.

Ô keiii, lét sờ gâu anh em eiiii 😎

1. Analytical Thinking

Đầu tiên là nhóm kỹ năng về Tư duy phân tích.

“Tư duy phân tích” nghe thì có vẻ hơi đao to búa lớn, nhưng thực tế anh em cứ hình dung vầy cho đơn giản. Mấu chốt nằm ở từ phân tích, nên hiểu “phân tích” như thế nào cho thực tế nhất.

Như trong bài note Quy trình làm dự án của BA, mình có diễn giải từ “phân tích” mang nghĩa như sau:

“Phân tích đơn giản là sắp xếp & phân loại mọi thứ lại cho đẹp đẽ, sạch sẽ mà thôi 🙂 “

Từ một BA Manager nọ

…hoặc

“Analysis means simply breaking down the information of an object, entity, process, or anything else to understand its functioning“

Sandhya Jane – Author of Business Analysis: The Question and Answer book

Mục đích sau cùng của việc phân tích là để mình hiểu được cái mình phân tích, hiểu được bản chất vấn đề.

Còn “tư duy” là hoạt động của hệ thần kinh, giúp chúng ta nhìn nhận những thứ xung quanh mình. Từ đó định hướng cho các hành động phù hợp hơn, hiệu quả hơn với tình huống mà mình đang gặp.

Vậy nên, người có tư duy phân tích là người có thiên hướng sắp xếp và phân loại các tiểu tiết của vấn đề, để qua đó: hiểu được bản chất của vấn đề. 

Và 5 thứ sau đây sẽ giúp hình thành nên tư duy phân tích của anh em.

1.1. Conceptual & Visual Thinking

Trong bối cảnh Business Analyst, tư duy phân tích thể hiện rõ ở hai mặt: Conceptual và Visual.

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

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 bối rối cho khách hàng. Vì họ chưa hình dung được nó là cái gì. Mọi thứ vẫn còn chung chung và trừu tượng quá.

Thay vào đó, việc demo ngay các chức năng có trên phần mềm sẽ khiến khách hàng dễ hình dung hơn (đó là Visual)

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

Visual Thinking

Nói về Visual Thinking thì đây là thứ anh em sẽ rất-rất-rất cần khi làm BA.

Vì có nhiều thứ mình sẽ rất khó để hình dung rõ vấn đề. Đặc biệt là các vấn đề quá sâu về chuyên môn, như chuyện coding chẳng hạn.

Chưa kể anh em còn phải giải thích, document lại cho các bên hiểu rõ vấn đề đang gặp phải.

Khi trao đổi với anh em đì ve lốp pơ, sẽ có những thuật ngữ, mà nếu mình chưa từng tận tay làm thực tế, thì thề luôn, là hầu như rất khó để mường tượng, và hiểu nó một cách “bản chất nhất”.

Nó nằm ở cả quá trình lấy yêu cầu với khách hàng. Ví dụ những thứ như API, Web Service… Hai thứ này thật sự rất khó gặm với những ai chưa làm thực tế bao giờ.

Những thứ thư: nhận và gửi data như thế nào, hay những hạn chế của những “available API” ảnh hưởng đến solution requirement ra sao???

Tất cả những thứ này sẽ gây rất nhiều khó khăn cho anh em nếu không hiểu rõ nó.

Đối với những trường hợp khá là trừu tượng như vầy thì hãy nhờ đến Visual Thinking.

Hãy nhờ một chuyên gia về khái niệm, lĩnh vực đó, diễn tả lại cho anh em hiểu thông qua… hình vẽ.

Vẽ là thứ rất quan trọng với anh em BA mình. Khi mọi thứ đã được phác thảo rõ ràng ra về hình ảnh, thì bản chất vấn đề sẽ dần lộ diện.

Mấu chốt là vẽ như thế nào cho hiệu quả. Cái này thì rõ ràng cần phải học và tích lũy rất nhiều.

Visual Thinking

  Mới ra trường không kinh nghiệm, sao làm BA?

  Dân BA có cần phải rành về kỹ thuật???

Conceptual Thinking

Conceptual Thinking nghĩa là tư duy theo hơi hướng trừu tượng, bao quát vấn đề.

Trừu tượng nghĩa là tổng quát hóa một cái gì đó, không cần care chi tiết bên trong nó có gì. Và thường thì bà con vẫn hiểu khái niệm trừu tượng đó khi chúng ta nói ra. Vì trừu tượng là thứ dựa trên một hình tượng nào đó, và được hình dung trong đầu.

Cái này có vẻ lạ. Thường thì khi trừu tượng quá, khó hiểu quá thì mình mới cần áp dụng Visual Thinking để mọi thứ được phác thảo ra rõ ràng, để dễ mường tượng hơn.

Vậy thì ngược lại, Conceptual Thinking – tư duy theo hướng trừu tượng thì được dùng khi nào?

Đó là khi anh em cần nhìn vấn đề dưới bức tranh tổng quan. Để xác định được các component chung nhất trong bức tranh tổng quan đó. Và relationship giữa chúng với nhau.

Ví dụ trong giai đoạn pre-sales, anh em thường phải gặp những người là C-Level bên phía khách hàng. Mà đã là C-Level rồi thì góc nhìn của họ thường rất bao quát và trừu tường.

Họ luôn nhìn bài toán từ trên cao, và đó phải là cách tiếp cận của BA khi làm việc với những người này.

Mình từng bị dập tơi bời không biết bao nhiêu lần khi cứ nói detail thế này thế kia với “nhầm đối tượng”.

Cách tiếp cận chỉ là một chuyện. Nếu anh em không suy nghĩ bao quát, tổng quát hóa, sẽ rất khó để hiểu được ý đồ thật sự mà khách hàng mong muốn.

Cuối cùng, Conceptual Thinking và Visual Thinking thường phải đi chung, và bổ trợ cho nhau. Không phải cứ tổng quát hóa là không cần visualize, mà hễ visualize thì không được visualize một bức tranh tổng quát.

Vậy chốt lại, để rèn luyện được Tư duy phân tích, anh em cần có Tư duy tổng quát hóa và Tư duy bằng hình ảnh 🙂

Nên làm để rèn luyện

✅ Đọc thêm về Design Thinking.
✅ Tập vẽ bằng bút, tập thể hiện ý đồ bằng nét vẽ của mình.
✅ Tập vẽ mind map.
✅ Đọc bộ Hình vẽ thông minh của Dan Roam (hiểu cách ổng dùng hình ảnh để giải quyết vấn đề như thế nào)
✅ Chịu khó quan sát (cả top-down và bottom-up)
✅ Tập làm Power Point, thể hiện ý tưởng bằng hình vẽ trên Power Point.
✅ Tập present trước đồng bọn.
✅ Thử nghe một câu chuyện phức tạp nào đó, rồi thể hiện lại bằng hình ảnh cho người khác hiểu.

1.2. Creative & Innovative

Tiếp theo là Creative và Innovative. Cả 2 đều kiểu 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, tiếng Việt dịch là SÁNG TẠO.
  • Còn Innovative nghĩa là nghĩ khác, tạo ra cái mới, cách làm mới, là sáng tạo của sáng tạo, tiếng Việt dịch là ĐỘT PHÁ.

Và dĩ nhiên, dù có sáng tạo hay đột phá thứ dữ cỡ nào thì cũng phải mang lại kết quả tích cực; chứ hổng có sáng tạo tầm bậy tầm bạ.

Mình cũng không ít lần phát sinh “ý tưởng vĩ đại” để update dữ liệu của khách hàng, theo kiểu bulk update. Nghĩa là update nguyên cục. Và cũng không ít lần ôm mỏ máo khi làm tầm bậy tầm bạ.

Cứ tưởng sáng tạo để tiết kiệm thời gian, mà ai dè còn tốn thời gian hơn cả chục lần để đi đổ đống vỏ mình gây ra, đắng lòng…

Nhiều lúc overload với đống công việc theo kiểu hành chính, hoặc update dữ liệu khá thủ công. Chúng ta cần tìm ra cách làm cho nhanh, cho hiệu quả. Dù có hỏi người này, người kia, tự mình google, hay tự mình nghĩ ra thì cũng đều rất cần thiết cho công việc BA hằng ngày.

Nó giúp chúng ta tiết kiệm được thời gian, để tập trung vào cái cần thiết hơn, và tạo ra được nhiều kết quả hơn.

Nên làm để rèn luyện

✅ Chịu khó đọc chuyên mục các mẹo (tips) của các tools hay dùng như Office365, Draw.IO, Jira…
✅ Chú ý quan sát, copy cách người khác làm.
✅ Bản thân mình tự thử nhiều cách khác nhau để làm một cái gì đó (mặc dù có thể fail, tốn thời gian hơn, nhưng ít nhất cũng biết được vài cách không thành công. Và đặc biệt là bản thân mình dạn hơn, dám thử nhiều cái mới hơn)
✅ Nên tracking những task mình làm trong ngày (để đo lường được hiệu quả >> cuối ngày xem lại >> tìm cách nâng cao hiệu suất).
✅ Có một chỗ ghi note thật nhanh trên điện thoại. Có ý tưởng một phát là rút điện thoại ra, rẹt rẹt, ghi âm lại liền. Hoặc chỉ cần 2-3 chạm là đã nhập ý tưởng được rồi.
✅ Lâu lâu đi lòng vòng nói chuyện với đồng bọn để refresh. Sẵn xem thử đồng bọn có gì hay không để về bắt chước.
✅ Đặt deadline cho các task mình làm >> càng gấp >> càng dễ nghĩ cách khác làm nhanh hơn.

Creative & Innovative

1.3. Problem Solving

Chắc chắn không chỉ BA, mà ai cũng cần kỹ năng này hết, kỹ năng giải quyết vấn đề.

Kỹ năng này cần xuyên suốt mọi lúc mọi nơi. Từ lúc chưa có dự án, tới lúc làm dự án. Thậm chí đóng dự án rồi mà vẫn còn một đống vấn đề phát sinh cần giải quyết.

Người có kỹ năng giải quyết vấn đề tốt là người nhạy với các thông tin nhận được.

Giả dụ khi mình nhận được thông tin, về một vấn đề cần phải giải quyết đi chẳng hạn. Là ngay lập tức trong đầu mình xác định được ngay vấn đề đang gặp là vấn đề gì. Hoặc chí ít nhìn nhận được nó thuộc khía cạnh, lĩnh vực nào, liên quan tới mình không, liên quan nhiều hay ít, abc, xyz...

Vì thực sự trong quá trình làm dự án sẽ có rất nhiều “problem” xảy ra. Nhỏ có, to có, bự chà bá cũng có.

Là người “đầu mối thông tin”, hầu như anh em BA sẽ phải can thiệp đến 96,69% các vấn đề xảy ra.

Từ những thứ nho nhỏ như sắp tới hạn deliver rồi mà anh em đì ve lốp pơ cứ nghỉ liên tục, cả team bị pending không ăn nhậu được gì. Hoặc tới deadline rồi mà khách hàng vẫn chưa chịu gửi master data, vâng vâng…

Cho đến những thứ mệt não hơn như: đang lúc demo cho khách hàng mà server ở nhà bị… tụt bà nó, không connect zô được.

Đây là trường hợp mình gặp rất nhiều, nội kể lại không cũng thấy ớn ớn.

Lần đó đi khách hàng cũng toàn nhân vật thứ dữ. Mặc dù đã nhắn nhủ anh em ở nhà là ráng support tốt, để anh em ra chiến trường demo cho suôn sẻ. Thì y như rằng, lần nào cũng có chuyện.

Lần đó có một ông Marketing Director. Khi đi tới phần nói về Social Listening, tích hợp với Facebook thì ổng có vẻ khoái. Vì trước giờ chưa có partner nào show cho ổng xem được cái này. Và thực sự business của họ đang rất có nhu cầu về khoản này.

Một phần cũng tự tin vì giải pháp mà team đã chuẩn bị. Phần khác vì thấy ổng khoái nên mình chém khá cao hứng.

Đến hồi quan trọng nhất: “bây giờ em sẽ demo cho anh xem ví dụ cụ thể mà bên em đã chuẩn bị cho bên mình”.

Nghe vậy ổng khoái lắm, gật đầu lia lịa.

Cái ai dè, login vô hệ thống bị failed, báo lỗi thiếu quyền các kiểu. Lúc này mình cũng hơi tái táiii. Nhờ anh PM chém gió câu giờ, mình ping về nhà nhờ anh em Dev support.

Mà hình như anh em đang vi vu đâu đó, gọi cháy máy không được. Thấy sốt ruột quá, nghĩ bụng: “chết mẹ rồi, lỡ chém mạnh quá mà không show được gì thì hố chết...”

Hồi sau anh em gọi lại, đưa cho cái account khác, thử login nhưng vẫn failed. Thử vào trình duyệt ẩn, vẫn failed.

Thôi thì cũng đã hơn 20 phút trôi qua, bèn dùng phương án B. Show hình, thay cho live demo. May hôm trước có nghe lời anh PM, chịu khó screenshot trước vài tấm sơ cua, hú vía.

Với những trường hợp gặp sự cố với khách hàng như vậy, mình nghĩ sẽ thiên nhiều về kinh nghiệm chinh chiến của anh em.

Còn những thứ trao đổi nội bộ với nhau, để cùng giải quyết 1 vấn đề nào đó thì có phần thiên nhiều về soft skills của mình hơn (dĩ nhiên là kinh nghiệm dự án cũng rất quan trọng).

Có những người khi gặp vấn đề, họ sẽ cứ phang phang vào mình, nói đủ thứ trên trời dưới đất, búa lua xua hết.

Nhiệm vụ của mình là cần phải bình tĩnh lại >> từ từ nhìn nhận đâu là vấn đề cốt yếu mà người đó đang gặp.

Cái này rất khó, vì khi gặp những thứ mà anh em không phải chuyên môn, như những term về kỹ thuật đi chẳng hạn. Hoặc có quá nhiều thông tin chồng chéo nhau, mother of phức tạp của phức tạp. Thì cái cần ở đây là mình phải đủ bình tĩnh và tỉnh táo dể nhận diện vấn đề.

Khi đã hiểu vấn đề, anh em mới nghĩ tới phương án giải quyết.

Có thể có nhiều phương án, nhưng việc chọn phương án nào là tốt nhất ở thời điểm hiện tại mới là quan trọng. Mỗi phương án nó đều mở ra 1 cánh cửa mới.

Và không bao giờ có công thức chung cho từng hoàn cảnh cụ thể.

Cùng tình huống đó, nhưng ở bối cảnh A, con người A’ thì giải quyết khác. Nhưng với bối cảnh B, và con người B’, thì lại phải giải quyết khác.

Nên khoản này đòi hỏi anh em phải chú ý quan sát nhiều. Học hỏi và gặp nhiều sự cố thì sẽ rèn luyện được kỹ năng này.

Ngoài ra, kỹ năng Giải quyết vấn đề sẽ luôn đi kèm với một thứ quan trọng không kém, đó là…

.

Xem tiếp tập 2 nhé anh em: Kỹ năng cần có của người làm BA (Tập 2) ?

Bài viết gốc được đăng tải tại thinhnotes.com

Xem thêm:

Xem thêm công việc CNTT hấp dẫn trên TopDev