Queo com anh em đến với tập cuối của chuỗi bài note: Những kỹ năng cần có của người làm Business Analyst.

Trước khi đọc tập cuối này, nhớ hẳn đọc 4 tập trước đó nhé anh em.

Review nội dung trước đó:

TỔNG QUAN

1. ANALYTICAL THINKING
1.1. Conceptual & Visual Thinking
1.2. Creative & Innovative
1.3. Problem Solving
1.4. Decision Making
1.5. System Thinking

2. COMMUNICATION
2.1. Verbal
2.2. Listening
2.3. Body Language
2.4. Writing

3. BUSINESS KNOWLEDGE
3.1. Industry Knowledge
3.2. Learn something new
3.3. Solution Knowledge

4. BEHAVIORAL CHARACTERISTICS
4.1. Trustworthiness
4.2. Responsibility
4.3. Adaptability

…

5. Interaction Skills

Nhóm kỹ năng thứ 5 được yêu cầu ở một người làm Business Analys đó là nhóm kỹ năng về tương tác – Interaction Skills.

Nhóm này mô tả các kỹ năng cần có để có thể: nói chuyện, chém gió, làm việc, hỗ trợ, thương thảo giữa BA và các Stakeholders khác nhau. Từ team nội bộ như: PM, Dev, QA, QC…; đến các stakeholder bên ngoài như: End-Users, Key-Users, Sponsors, SMEs, 3rd Vendors…

Đừng nhầm với nhóm Communication phía trên nhé anh em. Tương tác ở đây mang nghĩa rộng hơn thế.

Nó có thể là cách chúng ta đặt vấn đề, giải quyết mâu thuẫn. Hoặc đơn thuần là kể một câu chuyện, hoặc hướng dẫn, chỉ cho người khác làm một cái gì đó.

Giao tếp tốt thì anh em sẽ dễ dàng tương tác một cách hiệu quả hơn.

Và nếu những kỹ năng sau được rèn luyện tốt, thì chắc chắn kỹ năng giao tiếp bên trên anh em sẽ khá hơn rất nhiều. Ô kê lặn vô nhóm kỹ năng tương tác nhé anh em 😎

5.1. Facilitation

Facilitation – như mình có nói thì đây là một từ khóa vô cùng quan trọng với BA. Nó có nghĩa là: làm cho mọi thứ đơn giản, dễ dàng hơn.

Nguồn ảnh: Cambridge Dictionary

Vì đơn thuần, người làm BA sẽ phải deal với rất nhiều thứ.

Team xịn, team đểu, vấn đề lớn, vấn đề nhỏ, khách hàng thế này, thế kia… và cả nghìn thứ hầm bà lằng, sẽ đổ dồn vào anh em, ngay cả những lúc mình uể oải, mệt mỏi nhất.

Anh em mình cần phải đủ tỉnh táo, để làm rõ hết mọi thứ còn mập mờ, rối rắm.

Một số dấu hiệu để anh em nhận biết mình có sương sương là một Facilitator hay không:

• Trong các buổi meetings, thường có mặt mình thì mọi thứ được trong sáng, rõ ràng, đâu vào đấy.
• Mọi người thường có khuynh hướng tìm tới mình khi họ cần catch up lại một vấn đề gì đó. Vì với những vấn đề phức tạp, Facilitator sẽ có góc nhìn rõ ràng và đơn giản nhất, để có thể truyền đạt lại hiệu quả cho người khác. Người ta khoái nên mới tìm tới mình hỏi là ở chỗ đó.
• Thường là người định hình rõ kết quả sau cùng cần đạt được (output là gì) và chúng ta hiện đang có những gì (input hiện tại).
• Có khuynh hướng tìm hiểu cặn kẽ bản chất vấn đề.
• Thường hay đặt câu hỏi tại sao với những thứ xung quanh.
• Thường có khuynh hướng mở đầu, nói cho người khác hiểu mục đích, cách mình sẽ làm, kèm giải thích tại sao nên như vậy.
• Hay thúc đẩy anh em trong team phát biểu. Và luôn muốn đảm bảo mọi người trong team đều cùng hiểu về một hướng >> nên người Facilitator thường hay tóm gọn nhanh về những vấn đề nhỏ vừa trao đổi.

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

✅ Tập viết Meeting Minutes (biên bản họp). Thử viết xong >> gửi người khác xem họ đọc có hiểu hay không >> hiểu đủ ý hay chưa >> và có hiểu nhầm ý nào không.
✅ Tập đặt câu hỏi Tại Sao trước những thứ mà mình không rõ bản chất vì sao nó lại như vậy.
✅ Luôn chuẩn bị nội dung họp RÕ RÀNG, trước khi zô meeting.
✅ Tận dụng kỹ năng vẽ, phác thảo bằng hình ảnh để làm rõ mọi thứ phức tạp (Visualize Thinking).

5.2. Leadership & Influencing

Nói không ngoa thì đôi khi…, à thực ra là nhiều khi, vai trò của người làm BA trong team không khác nào một người Leader.

Leader nghĩa là: người dẫn dắt anh em đi; giúp đỡ, giải quyết khó khăn của anh em. Xuống cùng xuống, lên cùng lên với anh em.

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.

Dựa vào một đống yêu cầu kỹ năng trên, nếu làm tốt, anh em sẽ là người xây dựng nên sự đồng thuận của cả team. Vậy thì còn gì quan trọng bằng cơ chứ.

Khi anh em hoang mang, BA phải là người mang thông tin cần thiết đến cho anh em. Là người làm rõ ràng – đơn giản hóa mọi vấn đề. Và khi cần sẽ phải thuyết phục cả team đi theo hướng mà mình nghĩ là tốt, cho cả khách hàng và team dự án.

Nếu không có kỹ năng gây ảnh hưởng đến người khác thì quả thật rất khó để làm những thứ này.

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

✅ Làm tốt những thứ trên, từ 1.1 đến 5.1 là ô kê xam bu chê 😎

5.3. Teamwork

Nói về teamwork thì khá là hiển nhiên. Không chỉ BA cần, mà là ai cũng cần. Tất cả mọi ngành nghề, từ freelancer đến nhân viên, kỹ sư, thiết kế, vâng vâng.

Tuy nhiên teamwork thường bị hiểu sót đi một nửa bức tranh.

Anh em sẽ thường nghĩ: teamwork tốt là khi ta làm việc nhóm hiệu quả, tức mình phối hợp với người khác tốt, deliver đúng hạn, người khác nói mình hiểu, mình diễn tả người khác hiểu…, đại loại như vậy.

Nhưng thực sự teamwork cần được hiểu toàn diện hơn thế nữa, đặc biệt là với BA.

Cá nhân người làm Business Analyst không chỉ cần hoạt động teamwork thật tốt, mà hơn thế, phải làm cho cả team, các thành viên còn lại CÙNG TEAMWORK tốt thì mới ngon lành được.

Vì chữ TEAM là viết tắt của: Together Everyone Achieve More mà 🙂

Một số dấu hiệu teamwork hiệu quả mà anh em có thể nhận diện như sau:

• Anh em cùng nhận diện được chung một mục đích.
  Hỏi ông A cuối tuần này deliver được gì, ổng trả lời 123.
  Hỏi ông B cuối tuần này deliver được gì, ổng trả lời 456.
  Tương tự ông C, cuối tuần này deliver được gì, ổng trả lời 789, là tèo rồi.
  Đó chỉ là những chặng nhỏ, gom lại sẽ đạt được mục đích lớn. Những cái nhỏ mọi người phải nắm được trong đầu, thì mới mong hoàn thành cái lớn được.
• Nếu có vấn đề xấu, mọi thành viên trong team đều biết, và đều tự giác nghĩ hướng giải quyết.
• Thường sẽ có lịch đi nhậu định kỳ hàng ngày, à nhầm hàng tháng cho team.
• Nếu có vấn đề, mọi người sẽ đều nói ra, và không một ai giữ trong lòng, bất kể nói cho cả team hay chỉ chia sẻ cho PM.
• Ai cũng xác định được rõ vai trò của mình trong dự án.
• Thường khi trao đổi, sẽ có nhiều ý kiến trái ngược nhau.
  Team tốt là cùng nhau brainstorm trên nhiều ý kiến và họ tôn trọng ý kiến của nhau.
  Team bèo nhèo cức mèo là khoanh chéo tay, không mở lòng để thảo luận, không góp ý để xây dựng, mà thậm chí còn ngụy biện, hoặc tấn công cá nhân.
• Nếu một thành viên nào trễ deadline, họ sẽ tự áy náy vô cùng và chủ động tìm cách khắc phục. Không để hệ lụy đến cả đám trong tương lai. Vì họ ý thức được vai trò của mình, và tự họ muốn cả team cùng đạt được mục đích đề ra (…để còn đi nhậu).

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

✅ Khi có vấn đề, dành phần năng lực có hạn của mình để tập trung tìm giải pháp. Đừng tốn thời gian truy lùng kẻ phạm tội làm gì.
✅ Tự đặt câu hỏi: “Mình đã thật sự hiểu ý nó nói chưa?!?”, trước khi phản biện, gào rú, đập bàn, đập ghế, hay bất cứ các thể loại nguy hiểm nào >> quay lại kỹ năng Listening ở những tập trước.
✅ Nhớ ghi nhận ý kiến của anh em, ghi lên bảng, hoặc lưu ý cho mọi người; đừng chỉ chăm chăm vào ý kiến của mình.
✅ Chú ý đến việc duy trì mối quan hệ ngoài công việc với các anh em trong team: cà phê chém gió, ăn trưa, ăn chiều, ăn tối, đi bơi, đá banh, đi team building, chơi bơi hút chích các kiểu tích cực vào, để hiểu nhau rõ hơn.
Bạn >> bàn >> bán mà 🙂 Cái gì thì cái, đầu tiên phải là bạn cái đã. Mà đã là bạn thì nên dành chút quan tâm cho nhau chứ :3
✅ Dám nhận trách nhiệm trước toàn thể anh em.
✅ Hạn chế complain (mặc dù rất rất khó, tu lắm may ra được)
✅ Thiết lập một vài rules để team đi đúng hướng ban đầu.
✅ Số lượng đẹp của một team dự án là đừng nên quá 8 người.
✅ Team nên dùng tools để quản lý các tasks. Đừng tin quá vào bộ nhớ của từng cá nhân, sau này sẽ dễ gây xung đột. Nên quẳng vô máy, để phần mềm làm việc ghi nhớ giúp anh em.
✅ Và quan trọng nhất là phải làm thực tế, và chịu khó thực hành. Từ teamwork trong nhóm nhỏ, bạn bè, gia đình, đến team dự án, vâng vâng…, có là quất.

5.4. Negotiation

Negotiation là đàm phán – thương lượng. Là các hoạt động mà trong đó, các bên tìm cách đáp ứng nhu cầu của nhau.

Vậy kỹ năng đàm phán là các best practice, các kỹ thuật để chúng ta tìm cách đáp ứng nhu cầu của nhau một cách hiệu quả nhất.

Mình tin với nhiều người, đây làm một kỹ năng khó. Khó để học, khó để rèn luyện, và càng khó hơn nữa để thành thạo, làm chủ được kỹ năng này.

Thương lượng thì có nhiều cấp độ, từ những thứ nhỏ nhất đến những thứ lớn lao.

“Sếp ơi, ngày 5 tới em xin nghỉ 4 tháng, à nhầm 4 ngày đi MỸ tho chơi, có gì sáng thứ Sáu vô. Có gì sáng đó em vô trễ xíu xiu nhé, tầm… 4 tiếng, do em sợ máy bay delay quớ, với lại giờ em cũng xong ABC, rồi bàn giao XYZ cho anh G rồi ạ…”

Đó là thương thảo, là deal với Mít tờ Síp sao cho mình có nhiều thời gian nghỉ ngơi nhất, nhưng vẫn đảm bảo được tiến độ công việc.

Hoặc khi vô dự án, thường nó sẽ có kịch bản như thế này.

BA xuất hiện để mang kiến thức của mình, phân tích bài toán của khách hàng, tư vấn giải pháp, và rồi hiện thực hóa giải pháp đó cho họ. Nhưng không phải lúc nào chúng ta nói A, khách hàng cũng sẽ hiểu và đồng ý ngay là A cả.

Giả sử chúng ta nói không sai và diễn đạt đúng ý đồ nhé anh em (communication skill).

Chúng ta biết cách làm đó sẽ lại nhiều value hơn cho họ, an toàn hơn cho họ, và tránh cả được rủi ro cho phía team mình. Mấu chốt chúng ta phải thuyết phục khách hàng tin vào điều đó.

Và anh em cũng đừng nghĩ neogtiation chỉ là skills dành cho PM. Cả BA, Dev, QA hay QC đều cần có kỹ năng này. Nội chyện phân chia công việc, họp team, tranh luận các kiểu cũng đã rất cần negotiation rồi.

Mình tin đó là hướng đi tốt cho cả team. Làm sao để thuyết phục cả team đi theo cách làm của mình? Làm sao để mọi người cùng đồng thuận mặc dù cách làm này vẫn còn nhiều rủi ro…?

Nguyên tắc của negotiation mà cũng biết đó là phải Win-Win. Nhưng thực tế như thế nào thì tùy mỗi người trải nghiệm. Với mình, win-win luôn là cách đi bền nhất cho đa bên.

Có hai ý mình thường hiểu sai về kỹ năng đàm phán như sau:

1. “Mày win thì tao lose, mà tao win thì mày lose”

Thật sự trong một số trường hợp thì là như vậy. Của cải tài sản trên thế giới đều là hằng số. Người kia được thì người này sẽ mất. Tiền không tự sinh ra, hay tự mất đi, mà chỉ chảy từ túi người này sang túi người khác mà thôi.

Tuy thực tế là như vậy, nhưng trong bối cảnh negotiation của việc triển khai các dự án phần mềm, không phải lúc nào, cái “needs” của hai bên cũng ở thế đối ngược nhau: anh được thì tui mất, mà tui được thì anh mất. Không phải lúc nào cũng vậy.

2. Mọi thứ đều có hai mặt của nó

Cái gì mà thấy ngon quá, lời quá, mà nhìn quài không thấy khuyết điểm chỗ nào, rủi ro ra sao là dễ đâm đầu vào sọt lắm. Bản chất cái gì cũng có hai mặt hết.

Khi chọn giải pháp phù hợp, anh em nên lôi đủ mặt ưu và khuyết của từng giải pháp ra. Rồi ngồi kỹ lưỡng cân đo đong đếm từng thứ một.

Cái nào mà không có khuyết điểm thì là do mình chưa tìm hiểu kỹ, chứ không phải nó không có khuyết điểm. Dẹp cái đó qua một bên đi, vì nó chưa đủ thông tin để ra quyết định. Đâm đầu vào là dễ dính chưởng lắm.

Ngoài ra, hai mặt của một vấn đề còn phụ thuộc vào từng bối cảnh, hoàn cảnh cụ thể.

Có hai đứa:

• Đứa thì nhà cách công ty 20 cây. Hằng ngày lặn lội bắt bus từ 6g00 sáng để đi làm, chiều 9g00 mới về tới nhà. Hẹn hò, bạn bè, chạy chỗ này chỗ kia các kiểu quá bất tiện, mà đùng cái được tặng con con AB, thì phải nói là khoái thôi rồi.
• Còn đứa thì nhà sát gần công ty. Hằng ngày đi bộ đi làm khỏe re, đỡ tốn xăng xe, mà đúng cái được tặng cho con AB, thì chưa chắc nó đã thích. Vì phải tốn thêm một mớ chi phí xe cộ, chạy xe ngoài đường rủi ro giao thông các thứ, abc, xyz…

Hai đứa, hai tình huống, hai bối cảnh khác nhau, với cùng một sự việc được tặng xe thì chưa chắc đã có ưu – khuyết điểm như nhau.

Do đó nghệ thuật nằm ở chỗ: anh em phải cân đo đong đếm từng ưu – khuyết điểm của giải pháp. Rồi sau đó mới mapping nó vào nhu cầu của các stakeholders sao cho phù hợp nhất có thể.

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

✅ Phải hiểu được needs của mình, và needs của các stakeholder ==> cần có kỹ năng Listening tốt, Business Knowledge tốt ==> thì mới hiểu chuyện và deal được với người khác.
✅ Chân thành. Nói rõ cái lợi, cái hại, cái nào tốt, cái nào không (dĩ nhiên là theo ý kiến chủ quan của mình).
✅ Chuẩn bị kỹ nội dung trước khi vô họp >> nắm nhiều thông tin trong tay thì mới tìm được nhiều cách đáp ứng needs của mình và mọi người được.
✅ Luôn xác định rõ trong đầu: họ muốn gì và mình muốn gì. Nếu không phát biểu ra (trong đầu), thì bản thân mình chưa chắc đã hiểu needs một các rõ ràng được.
✅ Tìm một mentor, theo đuôi học hỏi.

5.5. Teaching

Kỹ năng cuối cùng trong nhóm Interaction Skills đó là kỹ năng sư phạm 🙂

Có thể nghe khá lạ lẫm nhưng đúng thật là người làm BA rất rất cần kỹ năng sư phạm. Để làm gì?

Nếu có dự án mới, thuộc một Domain Knowledge mới, đẹp là đúng người – đúng việc. Ai chuyên môn lĩnh vực, ngành nghề gì sẽ join vào dự án thuộc lĩnh vực, ngành nghề ấy. Tuy nhiên chuyện đó khá hiếm.

Với những dự án có Domain Knowledge mới, mà team không một ai rành về lĩnh vực này, BA sẽ là người tiên phong đi nghiên cứu nghiệp vụ, và những khái niệm liên quan đến lĩnh vực, ngành nghề này.

Trong giai đoạn sales, chuẩn bị giải pháp, BA phải nghiên cứu rất kỹ cả về khách hàng, lẫn ngành nghề của khách hàng.

Và một khi đã win dự án, BA phải là người truyền thụ lại toàn bộ knowledge (có được, học được từ giai đoạn sales) cho team để anh em cùng làm.

BA có kỹ năng sư phạm, ăn nói thu hút, trình bày rõ ràng, mạch lạc; và quan trọng nhất là truyền được cảm hứng cho anh em trong dự án là một điều hết sức quan trọng.

Ngoài ra trong dự án, đôi lúc anh em phải giải thích cho khách hàng một vài khái niệm kỹ thuật phức tạp. Kỹ năng sư phạm tốt sẽ giúp anh em tiết kiệm rất nhiều thời gian những lúc thế này.

Chưa hết, khi dự án đến giai đoạn deliver cho khách hàng, anh em BA sẽ phải đứng ra làm các buổi workshop: training cho key-users cách sử dụng hệ thống.

Thử hỏi có ai muốn nghe một thằng gà mờ, nói chuyện thì nhàm chán, ngáp lên ngáp xuống, miệng cứ bô bô mấy cái thứ trên trời dưới đất, chả liên quan bà gì tới mình hết?!?!

Nếu vậy thì thật là thảm họa, users họ sẽ không get được gì từ những buổi training >> users không biết cách sử dụng hệ thống >> users không làm >> dự án pending >> khách hàng complain >> PM complain >> BA áp lực >> BA die, ặc.

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

✅ Copy cách làm của những người nói chuyện dễ hiểu, trình bày mạch lạc, rõ ràng.
✅ Nắm rõ hot keys và các chế độ present của Power Point hoặc Prezi.
✅ Hoặc tập cách thể hiện, trình bày vấn đề bằng hình ảnh (qua bảng vẽ, trên slide, hoặc excel…) >> Visualize Thinking
✅ Chú trọng âm vực và ánh mắt trong quá trình “giảng đạo” (tham khảo Communication Skills)
✅ Tích cực thu thập ý kiến phản hồi của bà con sau quá trình training >> đọc >> rút kinh nghiệm >> cứ lặp đi lặp lại đến khi thành thục thì thôi.
✅ Cân nhắc thời gian, và có break-time nếu lâu quá, đừng để bà con ngồi quá lâu, bà con mệt mỏi là dễ tèo lắm.
✅ Luôn-luôn-luôn nói về cái người khác cần, không-không-không bao giờ nói về cái mình có.
✅ Tập luyện, tập luyện và tập luyện.

6. Tools

Ô kê chúng ta đã đi tới nhóm kỹ năng cuối cùng của người làm Business Analyst. Đó là nhóm kỹ năng sử dụng các công cụ/ phần mềm phục vụ cho công việc BA.

BABOK v3 thì chia làm ba nhóm, anh em đọc thêm tham khảo nhé. Nhưng mình sẽ gom nhóm 1 và nhóm 3 của BABOK lại thành 1 nhóm cho dễ hình dung.

Cụ thể các công cụ/ phần mềm cần thiết cho người làm BA sẽ nằm gói gọn trong 2 nhóm sau:

• Office Productivity
• Business Analysis

Hiểu được những tools cần thiết cho công việc BA, chúng ta sẽ tìm cách sử dụng nó hiệu quả hơn, nhanh hơn, nguy hiểm hơn >> công việc sẽ trôi chảy hơn.

Và đúng nghĩa mình làm cho tools đi phục vụ mình, chứ mình không chạy theo nó.

Ô kê cùng tìm hiểu cụ thể 2 nhóm nhé anh em.

6.1. Office Productivity

Đây là nhóm các công cụ giúp anh em giải quyết tốt các việc hành chính và các việc cần phải làm chung với người khác.

Cụ thể bao gồm các loại sau:

• Soạn thảo văn bản, như: Microsoft Word, LibreOffice, Scribus, hay Google Docs…
• Trình chiếu, như: Microsoft PowerPoint, Prezi, Visme, Keynotes…
• Spreadsheets, tiêu biểu nhất là: Microsoft Excel, hoặc có thể là Google Sheets, LibreCalc…
• Communication, như: Outlook, Gmail, Microsoft Teams, GotoMeetings, Skype, Zoom…
• Collaboration & Knowledge Management, ví dụ: Sharepoint, OneNote, Slack, Flock…
• Hardware, là các thứ kiểu như: biết cách dùng máy in, máy chiếu, scanner…

Trên là 6 nhóm công cụ cơ bản trong nhóm lớn Office Productivity. Trong mỗi nhóm thì mình chỉ nên dùng duy nhất tool cho đơn giản.

Ở trên mình liệt kê ra nhiều là để anh em có cái nhìn tổng quan hơn về các tools có trên thị trường thôi.

Còn chuyện dùng tool nào thì tùy thuộc vào anh em, vào license mà công ty mua, và tùy vào dự án nữa.

Có những dự án khách hàng đòi hỏi rất khắt khe những tools phục vụ công việc như này. Đặc biệt là các tool dùng để collaboration và quản lý document vì những vấn đề bảo mật liên quan.

6.2. Business Analysis

Ở trên là nhóm tools dành cho mình và team cùng sử dụng, cộng tác và làm việc với nhau trên đó. Còn đây là nhóm tools thiên về việc giúp anh em tự làm việc độc lập, tự suy nghĩ, phân tích vấn đề và công cụ hỗ trợ đắc lực để làm document.

Đó là các tools liên quan đến:

• Modeling, như: Draw.IO, Microsoft Visio…
• Requirement tracking, bao gồm những tools như: Jira, Microsoft Teams/ VSTS, Trello, Slack…
• Designing, bao gồm những tools thuộc nhiều cấp độ khác nhau như: Balsamiq, AxureRP, Photoshop, hoặc thậm chí là PowerPoint.
• Data Query/ Reporting, như: SQL Server, Visual Studio, PowerBi, Crystal…
• Other, những tools bổ trợ khác như: Screenpresso (chụp màn hình, quay clip >> làm doc), bộ SDK phục vụ một số task nhất định…

Dưới đây là những tools mình hay dùng.

1. Word
2. Excel
3. PowerPoint
4. Microsoft Teams: để teamwork, communicate các kiểu.
5. Outlook
6. Sharepoint: lưu trữ doc.
7. Draw.IO: tool chính để mình vẽ diagram
8. Visio: có một số diagram có sẵn template như Sequence Diagram mình sẽ vẽ trên này. Mình cũng ít khi dùng Visio, thi thoảng mới dùng vì từ lâu mình đã chuyển sang Draw.IO
9. Screenpresso: tool để chụp màn hình, kéo thả ký hiệu các kiểu để làm User Manual. Ngoài ra nó còn quay phim HD cũng rất lợi hại (bản có phí hay không có phí cũng đều xài ngon, tùy vào nhu cầu anh em)
10. Jira/ Confluence
11. SQL
12. Balsamiq Mockup: để mockup sơ bộ các component có trong màn hình
13. AxureRP: làm chi tiết prototype; có hỗ trợ thao tác động, kèm lưu prototype dưới dạng html rất lợi hại.
14. PowerBI: report maker (“Đem tiếng nói và màu sắc cho những số liệu rối rắm và buồn tẻ” – datamaker.vn)
15. Adobe Photoshop: dùng làm mockup, hoặc để “bùa” một số màn hình cần thiết. Ngoài ra, mình còn dùng pts để design nhẹ một số slide giới thiệu giải pháp.
16. Visual Studio: làm SSRS (reporting service)

Nhìn chung, tool thì tool chứ bản chất vẫn là tư duy giải quyết vấn đề của mình. Cái mình cần là phải rõ ràng được “vấn đề gì cần được giải quyết” >> rồi sau đó mới tìm đến tool.

Nhiều khi dùng tool hầm bà lằng quá lại không hay, nhưng càng đơn giản lại càng hay. “Vô chiêu thắng hữu chiêu” mà 😎

Cá nhân mình thấy khó nhất, và hiệu quả nhất vẫn là bộ ba Word – Excel – và PowerPoint. 

Không cần múa may gì nhiều, mình tin rằng chỉ cần nắm thật kỹ 3 tool này, và sử dụng nó thành thạo như đúng nghĩa “công cụ” sẽ giúp tiết kiệm thời gian quý báu của anh em rất nhiều 🙂

Tạm kết

Chuỗi bài về nhóm các kỹ năng cần thiết của BA khá dài, nhưng tổng quan chỉ gồm 6 nhóm chính sau:

• Analytical Thinking: Tư duy phân tích
• Communication Skills: Kỹ năng giao tiếp
• Business Knowledge: Kiến thức nghiệp vụ
• Behavioral Characteristics: Các đặc điểm về hành vi
• Interaction Skills: Kỹ năng về tương tác
• Tools: Kỹ năng sử dụng các công cụ

Nguyên lý cái thùng gỗ (Nguồn ảnh: Giaoduc.net.vn)

Một đống các yêu cầu về kỹ năng trên, nếu hoang mang rối bời quá, không biết nên tập trung phát triển cái nào; thì anh em cứ áp dụng Nguyên lý cái thùng gỗ là được.

Tức anh em sẽ xem thanh nào ngắn nhất, thì lo kéo cho thanh đó nó dài ra, không để nước chảy ra ngoài. Từ đó nâng dần đều các thanh còn lại của cái thùng.

Hi vọng qua chuỗi 5 bài note này, anh em sẽ chịu khó tìm hiểu thêm, quan sát thêm và học hỏi thêm về các kỹ năng cụ thể mà mình đang yếu.

Chuỗi bài này chỉ như guideline để anh em không bị đi lệch mà thôi. Nó hoàn toàn dựa trên ý kiến chủ quan và kinh nghiệm ít ỏi mình có được.

Đào sâu học hỏi mới tạo ra sự khác biệt.

Nếu có gì cần trao đổi thì cứ còm men bên dưới để tăng tính tương tác nhé anh em.

Bái bai và hẹn gặp lại ở bài sau 😎