Những Kỹ Năng Cơ Bản Cho Business Analyst (Phần 1)
Xây nền móng vững chắc cho BA thông qua các kỹ năng thiết yếu.
Disclaimer: Bài viết dựa trên kinh nghiệm cá nhân của mình khi làm BA. Tùy từng công ty và từng vị trí BA mà yêu cầu công việc có thể khác nhau. Vì vậy, hãy xem đây là tài liệu tham khảo và chọn cho mình bộ kỹ năng phù hợp với con đường bạn muốn theo đuổi nhé!
Trong phần 1 này, mình sẽ giới thiệu 4 kỹ năng nền tảng nhất mà bất kỳ BA mới nào cũng cần. Nếu được quay trở lại những ngày đầu đi làm, dưới đây là những điều mình sẽ khuyến khích bản thân rèn luyện để có nền tảng vững chắc.
Kĩ năng thu thập yêu cầu và hợp tác (Elicitation and Collaboration Skills)
Kĩ năng mô hình hoá (Modelling Skills)
Kỹ năng Triển Khai Chi Tiết Nhu Cầu & Giải Pháp (Requirements & Solution Documentation)
Kĩ năng giải quyết vấn đề (Problem-Solving Skill)
1. Kĩ năng thu thập yêu cầu và hợp tác
Nếu như bạn còn nhớ ở bài viết trước khi đề cập đến những nhiệm vụ của BA mình có đề cập đến mô hình khái niệm cốt lõi trong phân tích nghiệp vụ (Business Analysis Core Concept Model™ – BACCM™) gồm 6 thành phần chính và một trong những bước đầu tiên của BA là hiểu nhu cầu (Need) thực sự của khách hàng. Để làm được điều đó BA phải trải qua quá trình thu thập yêu cầu (elicitation) thông qua trao đổi với khách hàng.
Theo BABOK, phần Elicitation & Collaboration được định nghĩa như sau:
The Elicitation and Collaboration describes the tasks that
business analysts perform to obtain information from stakeholders and confirm
the results. It also describes the communication with stakeholders once the
business analysis information is assembled.
Tạm dịch:
Hoạt động thu thập yêu cầu và trao đổi mô tả các nhiệm vụ mà BA thực hiện để thu thập thông tin từ các bên liên quan và xác nhận kết quả. Khu vực này cũng mô tả sau khi thông tin phân tích nghiệp vụ đã được tổng hợp đầy đủ.
Vì sao kĩ năng này quan trọng?
Việc thu thập thông tin của khách hàng chính là cách chính để có thể hiểu về yêu cầu và định hình cách bạn sẽ thiết kế hệ thống. Việc thu thập thông tin có thể bao gồm trao đổi với khách hàng trực tiếp hoặc BA nghiên cứu về chủ đề, tự thu thập thông tin hoặc có sẵn các thông tin từ khách hàng. Sau khi đã thu thập thông tin quá trình collaboration cũng bao gồm việc xác nhận thông tin với khách hàng và các bên liên quan về những thông tin đã thu thập được là đúng và đủ.
Việc thu thập thông tin và trao đổi với các bên sẽ luôn gắn liền với BA từ khi dự án bắt đầu và theo suốt dự án nếu nhiệm vụ của BA vẫn cần thực hiện. Việc trao đổi với các bên liên quan cũng đảm bảo những thông tin BA có được là đúng, chính xác và cập nhật mới nhất. Việc thu thập yêu cầu và trao đổi có thể được lên kế hoạch từ trước hoặc là phát sinh trong quá trình phân tích.
Việc thu thập thông tin không chỉ dừng lại ở ghi chép những gì khách hàng nói mà cần đào sâu hơn và tìm gốc rễ của những mong muốn đó. Thực tế là khách hàng hầu hết không biết họ muốn gì, việc của BA là cần tìm hiểu thật sâu để từ đó có thể cởi các nút thắt và đưa ra các giải pháp phù hợp nhất.
Quy trình cụ thể
Quy trình của thu thập yêu cầu thường có các bước sau:
Prepare for Elicitation: Chuẩn bị cho việc thu thập yêu cầu bao gồm agenda cho từng meeting, tài liệu, câu hỏi cho khách hàng.
Conduct Elicitation: Tiến hành thu thập yêu cầu thông qua workshop, phỏng vấn, quan sát, phân tích tài liệu.
Confirm Elicitation Results: Xác nhận thông tin bằng cách gửi tóm tắt những gì đã thu thập và xác nhận nhưng điểm chưa rõ.
Communicate BA information: Truyền đạt lại thông tin BA đã thu thập được sau khi đã xác nhận cho Developer, Tester…
Manage Stakeholder Collaboration: Quản lí sự trao đổi với các bên liên quan như chọn cách giao tiếp phù hợp, giải quyết xung đột hay follow-up với khách hàng.
Trên đây là những kiến thức cơ bản bạn cần biết về thu thập nhu cầu và trao đổi với các bên liên quan, mình sẽ viết một bài khác phân tích chi tiết hơn về từng bước trong quy trình phía trên đồng thời các skills cần có cho từng bước.
Thu thập yêu cầu không phải một giai đoạn cố định, mà diễn ra liên tục.
Bất cứ khi nào BA phát hiện thiếu thông tin cần quay lại bước Elicitation và collaboration này.
Note: Sau khi yêu cầu đã được xác nhận bởi khách hàng, BA sẽ ghi chép yêu cầu (Requirements) theo từng nhóm khác nhau. Phần này cũng cần đi vào chi tiết nên bạn chờ mình ở các bài viết chuyên về requirements nhé.
2. Kĩ năng mô hình hoá
Thông tin BA thu thập được thường rất nhiều và phức tạp. Để có thể tổng hợp và trình bày thông tin một cách dễ hiểu và đơn giản thì kĩ năng mô hình hoá là một bước vô cùng quan trọng.
Bạn tưởng tượng như thông tin bạn thu thập được giống như yêu cầu thiết kế để xây nhà vậy. Nếu chỉ dừng lại ở việc lắng nghe, tìm hiểu và ghi chép mong muốn của khách hàng thì rất khó để có thể xác nhận với khách rằng mình hiểu đúng. Việc suy nghĩ và vẽ một bản phác thảo nhà có thể giúp khách hàng hình dung ra ngôi nhà trông ra sao chính là bước mô hình hoá trong dự án IT.
Mô hình hoá giúp BA làm gì?
Dưới đây là một số lợi ích của việc mô hình hoá nhu cầu và giải pháp cho khách hàng:
Giúp minh hoạ yêu cầu và giải giáp dễ dàng.
Giảm hiểu lầm giữa các bên từ BA đến Dev, Tester và doanh nghiệp.
Tiết kiệm thời gian giải thích.
Dễ dàng tìm ra lỗ hổng và edge case (Những case mà hiếm gặp nhưng vẫn cần cân nhắc).
Một số mô hình phổ biến
Process flowcharts: (Sơ đồ quy trình): Sơ đồ thể hiện quy trình từ điểm bắt đầu đến kết thúc. Thường BA sẽ cần tìm hiểu về:
As Is Process: Mô phỏng quy trình hiện tại và nhấn mạnh những pain points mà doanh nghiệp gặp phải.
To Be Process: Mô phỏng quy trình tương lai. Với giải pháp hiện tại thì quy trình trong tương lai sẽ như thế nào.
Swimlane Flowchart (Sơ đồ theo làn): là sơ đồ BA muốn phân chia người thực hiện chức năng và bộ phận mà người đó thuộc về. Sơ đồ cũng thể hiện sự tương tác với nhau giữa các hệ thống. Sơ đồ này sẽ hữu ích nếu có nhiều bộ phận tham gia vào cùng một quy trình.
Dataflow Diagram (Sơ đồ luồng dữ liệu): Nếu như BA cần trình bày làm thế nào dữ liệu dược lưu trữ vào Database thì dataflow chính là một tool giúp thể hiện điều này. Sẽ có nhiều mức độ khác nhau từ tổng quan đến chi tiết mà tuỳ vào từng trường hợp và nhu cầu khác nhau.
Use Case (Sơ đồ chức năng của hệ thống): mô tả các chức năng mà một hệ thống cung cấp cho người dùng cuối, thể hiện sự tương tác giữa người dùng (tác nhân) và hệ thống (chức năng). Nó cho cái nhìn tổng quan về cách người dùng thực hiện hành động và mục tiêu của họ với hệ thống thông qua các chức năng được cung cấp.
Entity Relationship Diagram (ERD - Sơ đồ thực thể liên kết): Là sơ đồ thể hiện các thực thể có trong cơ sở dữ liệu và mối quan hệ giữa chúng. Việc thể hiện chức năng sẽ hoạt động như thế nào thể hiện thông qua các sơ đồ và quy trình chức năng, ERD tập trung sâu hơn vào những thông tin nào sẽ được lưu trữ và chúng tương tác với nhau như thế nào.
Mô hình hoá chính là cách biến từ phức tạp thành đơn giản từ rối rắm thành rõ ràng và logic.
Với BA, việc hiểu và biết cách sử dụng các mô hình khác nhau giúp không chỉ khách hàng mà cả lập trình viên, tester và UXUI designer có thể dễ dàng nắm được logic của chức năng hay thành phần nào của hệ thống. Từ đó cũng dễ dàng để đối chiếu và rà soát thông tin.
3. Kỹ năng Triển Khai Chi Tiết Nhu Cầu & Giải Pháp
Sau khi nhu cầu đã được ghi chép lại và BA đã xác nhận với các bên liên quan về giải pháp, các model đã được xây dựng. BA sẽ tiến hành chuyển giải pháp một cách tổng quan đó thành giải pháp chi tiết cụ thể để lập trình viên có thể dựa vào thông tin đó thiết kế chức năng theo đúng yêu cầu.
Trong quá trình triển khai chi tiết và ghi chép lại sẽ luôn có thêm câu hỏi cần khách hàng giải đáp vì vậy việc dừng ở bước Modelling với BA chưa bao giờ là đủ thông tin cả nên user story chính là bước giúp BA đi sâu vào các case và ví dụ cụ thể nhằm tìm ra các “lỗ hổng” trong việc phân tích.
Cấu trúc tiêu đề của user story
As a [type of user], I want [goal] so that [reason/benefit]
Là [vai trò người dùng], tôi muốn [mục tiêu] để [lợi ích].
Cụ thể, nó bao gồm ba phần: vai trò của người dùng, mục tiêu họ muốn đạt được và lợi ích đằng sau mục tiêu đó, được viết bằng ngôn ngữ tự nhiên để mô tả ngắn gọn yêu cầu về một tính năng của phần mềm từ góc nhìn của người dùng.
Là [vai trò người dùng] (As a [user role]): Phần này xác định người dùng đang nói chuyện là ai (ví dụ: một khách hàng, một quản trị viên, một nhân viên).
Tôi muốn [mục tiêu] (I want to [goal]): Mô tả hành động mà người dùng muốn thực hiện, tập trung vào nhu cầu và ý định của họ.
Để [lợi ích] (So that [benefit]): Giải thích lợi ích hoặc giá trị mà người dùng nhận được khi hoàn thành mục tiêu, giúp hiểu rõ tại sao tính năng này lại quan trọng.
Ví dụ: Là một khách hàng, tôi muốn xem lại đơn hàng đã đặt để có thể theo dõi tình trạng giao hàng.
Description (nội dung) của User story
Trong nội dung của user story sẽ có (không giới hạn) các phần dưới đây:
Function: Chức năng này hoạt động như thế nào có tương tác với các phần nào khác không, cách thiết kế của chức năng bao gồm những gì ( ví dụ: gồm các Fields nào, flow ra sao)
Business Rules: Các quy tắc nghiệp vụ cần tuân theo khi thiết kế yêu cầu.
Validation Rules: Yêu cầu kiểm tra về data, logic.
Acceptance Criteria: Tiêu chí chấp nhận để đảm bảo thiết kế của yêu cầu được chấp nhận.
Scenarios & Examples: Trường hợp cụ thể minh hoạ nếu có.
Formulas / Calculations: Công thức nếu liên quan đến tính toán giúp Dev tối ưu hoá giải pháp.
Note: Mình có dùng một số từ chuyên môn trong phần này khi viết user story. Sẽ có những bài viết chi tiết hơn về cách viết user story sắp tới nhé.
4. Kĩ năng giải quyết vấn đề
Mình để kĩ năng này vào mục cơ bản bởi vì với BA, mình nghĩ rằng đây không phải là kĩ năng mềm nữa mà đây là kĩ năng cốt lõi. BA chính là người mà khách hàng tìm đến khi gặp vấn đề, và việc BA có thể giúp đó là giải quyết và tìm ra phương án xử lí chúng. Mỗi ngày với BA đi làm là hành trình luôn luôn đặt câu hỏi và tìm câu trả lời cho chúng bằng trao đổi với khách hàng, tìm thông tin, đọc tài liệu hay trao đổi với trong nội bộ team.
Why - Tại sao?
Nguyên nhân sâu xa của vấn đề này là gì?
Tại sao khách hàng cần tính năng này?
Tại sao quy trình hiện tại không hiệu quả?
2. What - Cái gì?
Mình đã hiểu đúng vấn đề chưa?
Có thông tin nào còn thiếu?
Dữ liệu nào có sẵn và dữ liệu nào cần thu thập thêm?
How?
Có những giải pháp nào?
Giải pháp nào tối ưu nhất?
Làm thế nào để giảm rủi ro và hạn chế phát sinh?
Nếu không có giải pháp hoàn hảo, có phương án thay thế hay không?
Giải quyết vấn đề không phải chỉ là đích đến mà là cả một quá trình kết hợp với nhiều khâu khác nhau từ Elicitation (để hiểu đúng vấn đề) đến Modelling (để phân tích rõ ràng) từ đó mới có thể Documentation (mô tả giải pháp chi tiết) được.
Kết bài
Vậy là chúng mình đã đi qua 4 kĩ năng nền tảng nhất mà một BA mới cần biết, đây cũng chính là “khung xương” của nghề BA, bao gồm:
✔ Thu thập yêu cầu & hợp tác
✔ Mô hình hoá
✔ Viết tài liệu yêu cầu & giải pháp
✔ Giải quyết vấn đề
Nghề Business Analyst không yêu cầu bạn phải hoàn hảo ngay từ đầu, nhưng bắt buộc bạn phải liên tục học hỏi và cải thiện. Elicitation, Modelling, Documentation và Problem-Solving là những viên gạch đầu tiên để xây nền vững chắc.
Trong các phần tiếp theo, mình sẽ tiếp tục chia nhỏ từng kỹ năng, kèm ví dụ thực tế đi làm của mình để bạn dễ áp dụng vào công việc hoặc chuẩn bị cho con đường trở thành BA sắp tới. Hẹn gặp bạn ở bài tiếp theo của series nha.
Chúc bạn luôn chân cứng đá mềm trên hành trình mình đang đi. Và dù có khó khăn thế nào bạn cũng sẽ tin tưởng rằng mình chắc chắn sẽ làm tốt.
Mến thương,
Thơ Nguyễn