Hộp công cụ của nhà phân tích nghiệp vụ đầy đủ các kỹ thuật phân tích nghiệp vụ. Dưới đây là một danh sách gồm 65 kỹ thuật phân tích nghiệp vụ mà việc biết về chúng rất hữu ích. Không nhất thiết bạn sẽ sử dụng mọi kỹ thuật trong mọi dự án (mặc dù một số trong số này chắc chắn là những kỹ thuật đã được thử và kiểm chứng, và thường được sử dụng), nhưng để bạn có một hộp công cụ ý tưởng để tham khảo khi quá trình phân tích nghiệp vụ của bạn không diễn ra suôn sẻ như mong đợi, để bạn có thể giải quyết vấn đề và tiếp tục dự án của mình.
Business Analyst có thể sửu dụng tích hợp nhiều công cụ
1. Active listening:
Một kỹ thuật giao tiếp mà liên quan đến việc diễn giải lại những gì bạn nghe trong một cuộc trò chuyện để xác nhận sự hiểu biết.
2. Agenda:
Một tài liệu chứa các chi tiết liên quan đến một cuộc họp, bao gồm mục tiêu và danh sách các chủ đề được thảo luận.
3. As is process analysis:
Xác định trạng thái hiện tại của một quy trình nghiệp vụ trong một tổ chức.
4. Brainstorming:
Một cuộc thảo luận nhóm tự phát được thiết kế để tạo ra các ý tưởng mà không có sự phê phán hoặc đánh giá ban đầu.
5. Business analysis plan:
Một tài liệu tóm tắt phương pháp phân tích nghiệp vụ, danh sách các sản phẩm cần hoàn thành, và lịch trình để hoàn thành các sản phẩm phân tích nghiệp vụ.
6. Business domain model:
Một mô hình hình ảnh mà biểu diễn một cách logic các khái niệm nghiệp vụ cần được thực hiện bởi hệ thống và cách chúng liên quan đến nhau. Đây không nên bị nhầm lẫn với sơ đồ dữ liệu, mà biểu diễn thiết kế hoặc kiến trúc cơ sở dữ liệu thực tế. Mặc dù chúng có thể trông giống nhau, một mô hình miền nghiệp vụ nên sử dụng các thuật ngữ trong lĩnh vực nghiệp vụ.
7. Business process model:
Một mô tả từng bước về việc một hoặc nhiều người dùng nghiệp vụ thực hiện để đạt được một mục tiêu cụ thể. Các bước này có thể làm thủ công, dựa trên giấy tờ hoặc dựa trên phần mềm.
8. Business process modeling notation (BPMN):
Một ký hiệu chuẩn để tạo ra các mô hình hình ảnh của quy trình nghiệp vụ hoặc tổ chức.
9. Business rules:
Một tuyên bố xác định hoặc hạn chế một khía cạnh của doanh nghiệp.
10. Change request:
Một tài liệu hoặc bộ thông tin tóm tắt một thay đổi cần được thực hiện. Thường liên quan đến một quy trình phê duyệt chính thức.
11. Competitive comparison:
Tài liệu hoặc ma trận so sánh trạng thái hiện tại hoặc tiềm năng của một sản phẩm hoặc hệ thống với các đối thủ của tổ chức.
12. Conference call:
Một cuộc họp được tiến hành qua một cầu nối hội nghị, với nhiều người tham gia từ các địa điểm vật lý khác nhau thông qua điện thoại.
13. Data dictionary:
Còn được gọi là Ma Trận Định Nghĩa Dữ Liệu, cung cấp thông tin chi tiết về dữ liệu nghiệp vụ, như định nghĩa tiêu chuẩn của các yếu tố dữ liệu, ý nghĩa của chúng và các giá trị cho phép.
14. Data feed specification:
Một tài liệu chứa các chi tiết nghiệp vụ và kỹ thuật liên quan đến việc trao đổi dữ liệu giữa các tổ chức. Có thể được sử dụng như một phần của quản lý tích hợp API hoặc các loại nguồn cung cấp dữ liệu đang diễn ra.
15. Data flow diagram:
Mô tả cách thông tin chảy qua, vào và ra khỏi một hệ thống. Chúng đặc biệt hữu ích khi đánh giá các quy trình tốn nhiều dữ liệu và xem xét cách dữ liệu được chia sẻ giữa các hệ thống hoặc tổ chức.
16. Data mapping:
Một loại cụ thể của từ điển dữ liệu mà cho thấy cách dữ liệu từ một hệ thống thông tin ánh xạ đến dữ liệu từ một hệ thống thông tin khác.
Data Mapping là một phần quan trọng của việc quản trị và tích hợp dữ liệu.
Việc tạo ra một bản đồ ánh xạ dữ liệu giúp bạn và nhóm dự án của bạn tránh nhiều vấn đề tiềm ẩn, loại vấn đề mà thường xuất hiện muộn trong quá trình phát triển hoặc trong quá trình kiểm thử chấp nhận người dùng và làm trật lịch trình dự án, đặc biệt là làm phiền các bên liên quan.
17. Deliverables list:
Một danh sách các mục giao hàng sẽ được tạo ra như một phần của nỗ lực phân tích nghiệp vụ cho một dự án hoặc sáng kiến.
18. Document analysis:
Quá trình phân tích tài liệu để khám phá thông tin liên quan đến yêu cầu.
19. Entity relationship diagram (ERD):
Một mô hình dữ liệu mô tả cách các thực thể (hoặc khái niệm hoặc đối tượng) liên quan đến nhau. Khi được tạo ra bởi các nhà phân tích nghiệp vụ, ERDs có thể được sử dụng để hiểu lĩnh vực nghiệp vụ, làm rõ thuật ngữ nghiệp vụ và kết nối các khái niệm nghiệp vụ với cấu trúc cơ sở dữ liệu (xem Mô hình Miền nghiệp vụ ở trên).
Mọi người sử dụng ERD để mô hình hóa và thiết kế cơ sở dữ liệu quan hệ.
20. Feature map:
Một biểu đồ hình ảnh của nhiều tính năng, thường là câu chuyện người dùng trên một danh sách chờ sản phẩm, mà cho thấy mối quan hệ giữa chúng.
21. Given When Then statements:
Một công thức để viết các bài kiểm tra chấp nhận cho một câu chuyện người dùng. Cho (một ngữ cảnh). Khi (một hành động được thực hiện). Sau đó (mô tả các hậu quả quan sát được, hoặc yêu cầu).
22. Glossary:
Một tài liệu cung cấp các thuật ngữ đặc biệt trong lĩnh vực nghiệp vụ hoặc kỹ thuật. Một từ điển được sử dụng để đảm bảo rằng tất cả các bên liên quan (nghiệp vụ và kỹ thuật) hiểu ý nghĩa của thuật ngữ, viết tắt và cụm từ được sử dụng trong tổ chức.
23. Grooming the product backlog:
Một quá trình để xem xét các mục mới trên danh sách chờ sản phẩm để làm rõ, ước lượng và ưu tiên, trước hoặc trong quá trình lập kế hoạch sprint.
24. Interface analysis:
Quá trình phân tích một giao diện, chẳng hạn như một giao diện người dùng để kết nối giữa hai hệ thống phần mềm, để khám phá thông tin liên quan đến yêu cầu.
25. Interview:
Một phiên hỏi đáp với một hoặc nhiều bên liên quan để hỏi và trả lời các câu hỏi liên quan đến bất kỳ khía cạnh nào của vấn đề, dự án hoặc yêu cầu.
Một buổi phỏng vấn hiệu quả sẽ cung cấp những thông tin hữu ích
26. Issues list:
Một tài liệu hoặc kho lưu trữ chứa một danh sách tất cả các vấn đề liên quan đến bất kỳ yêu cầu nào cho một dự án.
27. Meeting notes:
Một tài liệu ghi lại bản chất của các chủ đề được thảo luận trong một cuộc họp, cùng với bất kỳ quyết định và hạng mục hành động nào kết quả.
28. Mind map:
Được đề xuất bởi Bola Adesope, một mô hình hình ảnh với một chủ đề ở giữa mà hiển thị mối quan hệ phân cấp giữa các khái niệm và ý tưởng khác nhau. Đây là một công cụ tuyệt vời cho việc tạo ra ý tưởng.
29. Observation:
Quá trình quan sát người sử dụng hệ thống hoặc thực hiện một quy trình, thường là trong môi trường làm việc thực tế của họ, để khám phá thông tin liên quan đến các yêu cầu.
30. Organizational chart:
Một mô hình hình ảnh đại diện cho cấu trúc tổ chức đặt ra cho một tổ chức hoặc một phần của một tổ chức.
31. Performance measurement:
Quá trình thu thập, phân tích và/hoặc báo cáo thông tin về hiệu suất của một cá nhân, nhóm, tổ chức, hệ thống hoặc thành phần.
32. Performance report:
Tài liệu hoặc mô hình hiển thị kết quả từ một dự án, giai đoạn dự án, hoặc hoạt động kinh doanh.
Performance report giúp đánh giá hiệu quả dự án một cách trực quan
33. Portfolio management:
Quy trình để tổ chức, ưu tiên và hiển thị mối quan hệ giữa nhiều dự án đang hoạt động và được đề xuất cho một tổ chức.
34. Problem definition:
Quá trình phát hiện và xác định vấn đề thực sự cần được giải quyết bởi một dự án hoặc giải pháp.
35. Process improvement progress report:
Mô hình hình ảnh hiển thị những cải tiến được thực hiện đối với một quy trình nghiệp vụ hoặc kỹ thuật như kết quả của một dự án hoặc sáng kiến.
36. Process walk-through:
Một phiên làm việc trong đó các chuyên gia về vấn đề đi qua một quy trình tương lai để xác nhận nó.
37. Product backlog:
Danh sách tất cả các yêu cầu đang được xem xét (được viết bằng cú pháp câu chuyện người dùng), được sắp xếp theo thứ tự ưu tiên và được ma trận với các đặc điểm quan trọng khác để thuận tiện cho việc lập kế hoạch và ưu tiên cho một nhóm phát triển phần mềm linh hoạt.
38. Project list:
Một danh sách duy nhất các dự án được ưu tiên đang được xem xét bởi một nhóm hoặc tổ chức.
39. Prototype:
Một mô hình hình ảnh chức năng hiển thị giao diện người dùng của một hệ thống phần mềm chưa được xây dựng. Thường thì các mô hình nguyên mẫu cho phép một số tương tác hạn chế dựa trên dữ liệu mẫu.
40. Requirements questionnaire:
Một danh sách các câu hỏi về yêu cầu dự án. Thông thường các câu hỏi được tổ chức theo tính năng (hoặc yêu cầu nghiệp vụ hoặc mục tiêu dự án).
41. Requirements review:
Một cuộc họp tập trung các bên liên quan để đi qua tài liệu yêu cầu, trang qua trang, dòng qua dòng, để đảm bảo rằng tài liệu đại diện cho sự hiểu biết hoàn chỉnh của mọi người về những gì cần được thực hiện trong dự án cụ thể này.
42. Retrospective:
Quá trình xem lại công việc đã hoàn thành (thường là cho một dự án hoặc đoạn dự án) để khám phá và đưa ra các bài học rút ra.
43. Root cause analysis:
Quá trình phân tích một vấn đề để khám phá các nguyên nhân cơ bản hoặc vấn đề thực sự tạo ra vấn đề.
44. Scope model:
Một biểu đồ hình ảnh của các tính năng, quy trình hoặc chức năng trong phạm vi cho một dự án, giải pháp hoặc hệ thống cụ thể.
45. Stakeholder analysis:
Một tài liệu xác định ai là thành viên của nhóm dự án và họ chịu trách nhiệm về cái gì.
46. Stakeholder map:
Một biểu đồ hình ảnh mô tả mối quan hệ của các bên liên quan đến giải pháp và lẫn nhau.
47. Stakeholder request list:
Danh sách các yêu cầu liên quan đến một dự án hoặc giải pháp trước khi xác định phạm vi.
48. Survey:
Một loạt các câu hỏi được đặt ra cho nhiều bên liên quan trong một định dạng không đồng bộ, như một bảng câu hỏi trực tuyến. Hữu ích để thu thập nhiều thông tin từ nhiều người.
49. SWOT analysis:
Một mô hình hình ảnh hiển thị thông tin về Điểm mạnh, Điểm yếu, Cơ hội và Mối đe dọa mà một tổ chức đối diện.
SWOT là mô hình phổ biến để đánh giá các khía cạnh của một tổ chức/dự án
50. System architecture diagram:
Mô hình hình ảnh xác định các thành phần hệ thống và cách chúng tương tác như một phần của giải pháp và có thể giúp bạn tìm ra cách tốt nhất để tổ chức yêu cầu chi tiết.
51. System context diagram:
Một mô hình hình ảnh xác định hệ thống chính cần được xử lý trong một dự án hoặc sáng kiến và mối quan hệ giữa hệ thống chính và các hệ thống khác.
52. To Be process analysis:
Xác định trạng thái tương lai của một quy trình nghiệp vụ trong một tổ chức để làm rõ cách quy trình nghiệp vụ sẽ hoạt động, vào một thời điểm trong tương lai, sau khi có các thay đổi.
53. Traceability matrix:
Được đề xuất bởi Nikkita Nguyen, tài liệu này được sử dụng để ánh xạ yêu cầu nghiệp vụ với yêu cầu chức năng.
54. Triple constraint:
Một mô hình hiển thị sự cân bằng giữa ngân sách dự án, lịch trình, phạm vi và chất lượng.
55. Use case:
Các trường hợp sử dụng là một loại mô tả yêu cầu văn bản nắm bắt cách một người dùng sẽ tương tác với một giải pháp để đạt được một mục tiêu cụ thể. Chúng mô tả quá trình từng bước mà một người dùng trải qua để hoàn thành mục tiêu đó bằng cách sử dụng một hệ thống phần mềm.
56. Use case diagram:
Một biểu đồ UML (Ngôn ngữ mô hình hợp nhất) hiển thị các diễn viên, các trường hợp sử dụng và mối quan hệ giữa chúng.
57. User acceptance testing:
Một quá trình xác thực trong đó người dùng nghiệp vụ sử dụng một giải pháp mới, thường trước khi triển khai, để xác nhận rằng nó sẽ đáp ứng nhu cầu của họ.
58. User interface specification:
Một tài liệu xác định các quy tắc tương tác cho người dùng tương tác với một trang cụ thể trên một trang web hoặc màn hình trong một ứng dụng.
59. User story:
Một tài liệu ngắn ghi lại mô tả của một tính năng phần mềm từ quan điểm của người dùng cuối. Câu chuyện người dùng thường được viết theo cú pháp sau:
Như một ____ {người dùng}, tôi muốn ____ để _____.
60. Video conferencing:
Một mở rộng của cuộc họp web, nơi các bên tham gia cũng có thể chia sẻ video của họ.
61. Vision document:
Một tài liệu mô tả các mục tiêu kinh doanh và phạm vi của một dự án.
62. Web conference:
Một cuộc họp được tổ chức thông qua một webinar, cuộc họp trực tuyến, hoặc kết hợp của phần mềm chia sẻ màn hình và cầu cống hội nghị, với nhiều người tham gia từ các vị trí vật lý khác nhau thông qua một kết nối internet có thể tất cả xem một màn hình hình ảnh và nói chuyện với nhau.
Một cuộc họp trực tuyến giúp tiết kiệm thời gian, chi phí nhưng vẫn đem lại hiệu quả công việc cao
63. Wireframe (còn được gọi là Mock-Up, liên quan đến Prototype):
Một biểu đồ hình ảnh của màn hình giao diện người dùng, thường là một mô hình thấp.
Wireframe giúp thể hiện trực quan giao diện người dùng trong quá hình hoàn thiện sản phẩm
64. Workflow diagram (Còn gọi là Sơ đồ Hoạt động):
Một mô hình hình ảnh đơn giản nắm bắt các bước, quyết định, điểm bắt đầu và điểm kết thúc của một quy trình chức năng, kỹ thuật hoặc nghiệp vụ.
65. Workshop:
Một cuộc họp trong đó hợp tác theo thời gian thực về một hoặc nhiều sản phẩm làm việc, như các sản phẩm giao hàng yêu cầu, diễn ra trong phiên làm việc.
Một buổi workshop để thu thập thông tin và ý kiến của mọi người
Trên đây là những công cụ hiệu quả mà một người Business Analyst có thể sử dụng. Hy vọng những thông tin được BAC tổng hợp trên đây sẽ giúp các bạn có thêm kiến thức hữu ích. Đừng quên đón xem các bài viết mới nhất sẽ được cập nhật thường xuyên tại BAC's Blog.
Nguồn tham khảo:
https://www.bridging-the-gap.com/
Nhu cầu đào tạo doanh nghiệp
BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.
CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN
Khoá học Online:
Khoá học Offline:
Tại Tp.HCM:
Tại Hà Nội:
Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất
Ban biên tập nội dung - BAC