Thuật ngữ cho Business Analyst
Thuật ngữ cho Business Analyst
Hello anh em. Như tiêu đề, bài này mình sẽ nói về các thuật ngữ thông dụng đối với một Business Analyst. Và đặc biệt, các thuật ngữ cho Business Analyst này đều được nhắc đến trong quyển BABOK v3.0.
BABOK v3.0 nhắc đến rất nhiều các thuật ngữ cho Business Analyst. Và trong đó có cả những khái niệm riêng biệt được sử dụng trong sách nữa. Do đó, bài này mình sẽ không đề cập hết mà chỉ nhắc đến những thuật ngữ thật sự cần và quan trọng thôi nhé.
BABOK v3.0 builds hẳn một chương để nói về các glossary (thuật ngữ) để người đọc dễ dàng hiểu chính xác được nội dung, tránh hiểu sai. Do đó, anh em nên tham khảo các thuật ngữ trước khi đọc để tránh rối khi nuốt 514 trang BABOK này nhé.
Let’s start! Mình đi theo thứ tự a bờ cờ 
A
Acceptance Criteria: là những điều kiện hoặc tiêu chuẩn liên quan đến các requirement, các user story hay thậm chí là các function. Và các điều kiện hoặc tiêu chuẩn này phải đáp ứng được yêu cầu của stakeholder về requirement, user story hay function đó. Nói cách khác ngắn gọn hơn, Acceptance Criteria là những điều kiện hoặc tiêu chuẩn để xác nhận yêu cầu của stakeholder đã được hoàn thành.
Actor: là một người, một thiết bị hoặc một hệ thống mà thể hiện được một vai trò cụ thể và có tương tác trong hệ thống. Nhớ nhé, actor không chỉ là người, mà còn có thể là một hệ thống. Ví dụ: Payment Gateway hoặc GDS (Global Distribution System, được dùng trong các hệ thống đặt phòng khách sạn, máy bay).
Allocation: sự phân bổ, bố trí resources, tasks hoặc cost.
Alternative: thay thế, mang tính thay thế. Từ này thường gặp trong Alternative Flow lúc mô tả Use Case.
Authentication: là quá trình mà hệ thống sẽ xác nhận anh em là ai và anh em có được phép truy cập vào hệ thống hay không. Hay nói cách khác, Authentication trả lời câu hỏi anh em có vào được hay không?
Authorization: là quá trình mà hệ thống sẽ xác nhận anh em truy cập được gì trong hệ thống. Khác với Authentication, Authorization sẽ trả lời câu hỏi anh em xem được gì và làm được gì trong hệ thống. Chứ không còn đơn thuần là có vào được hay không.
B
Baseline: dịch ra tiếng Việt thì mình sợ không đúng lắm. Có thể hiểu baseline là một hành động để final một document. Ví dụ document đang ở draft, lúc mới soạn đang là version 0.1. Qua nhiều lần chỉnh sửa, update, revise thì sẽ lên 0.2, 0.3 hoặc 0.4. Sau khi được Line Manager trong team hoặc khách hàng baseline thì document đó sẽ lên version 1.0. Cứ tiếp tục như vậy theo chu trình của dự án.
Body of Knowledge: là những kiến thức được tổng hợp lại và những hành động mà được đa số mọi người đồng ý áp dụng để giải quyết những topic phổ biến và thường gặp nhất.
BPMN: Business Process Model and Notation là một phương pháp chuyên biệt để mô hình hóa các quy trình đặc thù có trong doanh nghiệp. Anh em có thể tìm hiểu thêm về BPMN tại http://www.bpmn.org.
Mình cũng có viết chuỗi 3 bài về BPMN, anh em xem tham khảo thêm nhé
Bench Marking: như đã nói trong bài Các phương pháp moi móc thông tin của BA, bench là một cái bảng mẫu, marking là đánh dấu, là cho điểm. Bench Marking cốt là phương pháp so sánh theo một điểm chuẩn nào đó.
Black Belt: là Leader của nhóm, thường có vai trò là PM trong dự án. Chịu trách nhiệm chính trong việc deliver “right things on time”cho khách hàng và đảm bảo được sự hài lòng của các stakeholder.
Business Drivers: các yếu tố then chốt tác động đến sự thành công của dự án (con người, thông tin, quy trình…).
Burndown Chart: là biểu đồ thể hiện khối lượng công việc ước tính và thực tế (trục thẳng) so với khoảng thời gian cần để thực hiện công việc đó (trục ngang). Biểu đồ này mang đến một cái nhìn tổng quan về khối lượng công việc được hoàn thành trong thời gian bao lâu.
Burndown Chart
C
CRUD: Là viết tắt chữ cái đầu của Create, Read, Update and Delete. Đây là bốn chức năng cơ bản để xử lý dữ liệu.
Contact Point: là đầu mối liên hệ chính cho bất cứ thông tin nào của dự án. Thường thì trong team triển khai dự án sẽ có từ 1-2 contact points. Mỗi người sẽ đảm nhận một phạm vi thông tin khác nhau. Thường thì là PM và BA.
PM chịu trách nhiệm liên hệ cho các thông tin liên quan đến hợp đồng, resource, scope, budget, time hay thậm chí là các integration cho tương lai. Còn BA chịu trách nhiệm liên hệ cho các thông tin phục vụ cho việc xây dựng giải pháp.
Phía team dự án của khách hàng cũng sẽ có 1-2 contact points. Thường thì các contact point của các bên sẽ liên lạc với nhau theo cấp độ và theo các phạm vi thông tin cần trao đổi.
Ví dụ PM thường sẽ liên lạc với contact point của khách hàng là các sếp để trao đổi về resource, scope, budget và time cho dự án. Còn BA sẽ liên lạc với contact point là đại diện các end-user đến từ các phòng ban hoặc các sếp nếu cần để lấy requirement cho dự án.
Cost of Goods Sold (COGS): cái tên đã nói lên tất cả, giá thành sản phẩm được bán ra.
Commercial off-the-shelf (COTS): là một gói giải pháp chuyên biệt được bán cho các doanh nghiệp. Và nó đáp ứng được hầu hết các nhu cầu thường gặp của các doanh nghiệp đó. Có thể hiểu COTS như một solution, nhưng ở một phạm vi nhỏ hơn.
COTS rất chuyên biệt và nó giúp giải quyết được các vấn đề rất thường gặp của doanh nghiệp. Thường là về một module cụ thể nào đó, như: HR, Finance hay Document Management. Các gói COTS có thể được configure lại một số function để đáp ứng được sâu hơn nhu cầu của doanh nghiệp.
Component: là thành phần trong trong hệ thống. Các component rất khác nhau, được xác định rõ ràng với nhau và nó là duy nhất trong hệ thống.
D
Domain: domain là lĩnh vực kiến thức mà ở đó chúng ta có thể hiểu rõ và xác định được các yêu cầu, vấn đề thường gặp và các thuật ngữ trong ngành.
E
Elicitation: anh em tham khảo bài Elicitation là gì? nhé.
Evolutionary Prototype: là những mẫu prototype liên tục được tùy chỉnh và cập nhật theo phản hồi của khách hàng. Evolutionary Prototype là một điều không thể thiếu trong các dự án Agile.
F
Facilitate: theo mình hiểu nôm na là “làm cho đơn giản”.
Còn theo cách định nghĩa của BABOK v3.0 thì facilitation là: “nghệ thuật lãnh đạo và khuyến khích người khác thông qua nỗ lực của tất cả mọi người để đạt được những mục tiêu đã được thỏa thuận từ trước“ @@ Nghe má ơi luôn :)))
Thiệt ra hai cách hiểu này nghe có vẻ khác nhau, nhưng ngẫm lại thì nó rất hợp lý và ăn rơ với nhau. Việc dựa trên những nỗ lực của cả team để hướng mọi người tới mục tiêu giải quyết được các requirement, là cách làm đơn giản và hiệu quả nhất để close dự án và đảm bảo deliver được những giá trị cần thiết cho khách hàng.
Lý thuyết là vậy, nhưng thực tế thì quá khác. Mình rất nên suy nghĩ đơn giản và bám sát đề bài, đừng đi lan man mà chệch hướng. Bỏ ra nhiều effort mà chả deliver được cái gì có giá trị với khách hàng thì cũng xem như hỏng.
Feature: là thứ mà hệ thống làm được. Giúp giải quyết các requirement cũng như đáp ứng được sự hài lòng của các stakeholder. Tùy nhiều trường hợp, nhưng theo mình thì feature phải giúp thỏa mãn nhu cầu của các stakeholeder thì mới đáng làm. Còn không thì cứ cho vào backlog hết, cân nhắc resource rồi mới làm.
Thường thì users họ… hơi tham lam. Được 1 sẽ đòi 10. Xu hướng của con người mình là vậy mà. Cái gì có thể làm cho họ đỡ cực hơn thì họ đều yêu cầu hết. Do đó không phải tính năng nào mình cũng “accept”.
Functional Requirement: là khả năng mà hệ thống có thể giải quyết được các requirement liên quan đến hành vi người dùng. Như các quy trình nghiệp vụ hay các solution tính toán có trong hệ thống.
Cụ thể hơn, Functional Requirement liên quan đến behavior/ interaction của người dùng và những data nào sẽ có trong hệ thống.
Ví dụ, khách hàng mong muốn Salesperson nhập các đặc tính sản phẩm vào bảng báo giá, sau đó gửi bảng báo giá cho Sales Admin kiểm tra. Và tiếp tục gửi bảng báo giá cho bộ phận kế toán nhập giá thành sản phẩm. Cuối cùng bảng báo giá sẽ quay lại Salesperson để nhập giá bán. Thì đây chính là functional requirement.
Requirement của khách hàng hoàn toàn liên quan đến việc hệ thống có hỗ trợ được hành vi của người dùng trên hệ thống hay không. Hay nói đơn giản hơn là các quy trình và dữ liệu có trong hệ thống.
G
Gap Analysis: là quá trình so sánh giữa hai thứ gì đó để xác định sự khác biệt và độ chênh lệch giữa chúng. Thường thì người ta phân tích GAP ở hai trạng thái khác nhau của hệ thống. Ví dụ trạng thái ở tương lai sẽ có gì khác so với trạng thái ở hiện tại.
Go-Live: là thời điểm chuyển giao hệ thống cho khách hàng sử dụng thật. Đội ngũ triển khai dự án sẽ hỗ trợ giải quyết các thắc mắc và các vấn đề gặp phải của khách hàng trong giai đoạn Go-live này (đọc là /ɡəʊ-lʌɪv/ nhé). Go-live là một cột mốc thời gian (milestone) do team triển khai dự án và khách hàng cùng thống nhất.
H
Happy Case: là trường hợp thuận tiện nhất mà user gặp trong quá trình thực hiện nghiệp vụ trên hệ thống.
I
Initiative /ɪˈnɪʃətɪv/: nghĩa thông thường của initiative là sáng kiến. Còn trong bối cảnh IT đối với BA, thì initiative có thể hiểu là một dự án hoặc một giải pháp cụ thể giúp giải quyết được các vấn đề mà doanh nghiệp đang gặp phải.
Iteration: là một chu trình liên tiếp của các quá trình phân tích, phát triển, kiểm thử và thực thi. Iteration là khái niệm thường dùng để quản lý dự án. Hiểu đơn giản hơn là các giai đoạn của dự án, giống như sprint trong agile.
K
Knowledge Area: là lĩnh vực chuyên môn, BABOK v3.0 xác định có 6 lĩnh vực chuyên môn cụ thể của một BA. Anh em tham khảo thêm ở bài Kỹ năng của Business Analyst – cần gì và nên tập trung những gì?
L
Life Cycle: là chu trình thể hiện được một loạt các sự thay đổi của đối tượng mình đang theo dõi từ lúc bắt đầu cho đến khi kết thúc.
Lessons Learned Process: là quy trình được thực hiện nhằm nâng cao chất lượng dự án thông qua các kinh nghiệm rút được. Quy trình này thường bao gồm các cuộc họp rút kinh nghiệm trong team dự án với nhau. Những gì đã làm tốt, những gì chưa làm được và best practice về sau. Output của quy trình sẽ ra được một framework làm việc tiêu chuẩn cho cả team.
M
Metadata: metadata là bản mô tả dữ liệu để giúp người dùng hiểu được cách sử dụng các dữ liệu này. Cả về cấu trúc lẫn đặc điểm kỹ thuật của dữ liệu. Người ta thường nói: metadata là data của data.
Ví dụ một cuốn sách thì có: thông tin tên sách, chủ đề, tác giả, kiểu chữ, lần xuất bản và kích thước của tệp dữ liệu của một tài liệu tạo thành siêu dữ liệu (metadata) về cuốn sách đó.
Methodology: hiểu nôm na là phương pháp luận. Còn hiểu cụ thể hơn thì methodology là một phương pháp, kỹ thuật, quy trình, concept làm việc và các quy định, yêu cầu để giải quyết một vấn đề nào đó.
N
Non-Functional Requirement: chính là Quality of Service. Cụ thể hơn nó mô tả hiệu suất và chất lượng của giải pháp mà mình cung cấp.
Ví dụ đối với một giải pháp phần mềm thì Non-Functional là những thứ như:
- UI/UX thân thiện với người dùng, dễ học (learnability)
- Dễ nhớ (memorality)
- Hệ thống mang tính consistent
- Hay phải đảm bảo được tính an toàn bảo mật.
Do đó, Non-Functional Requirement có vai trò quan trọng không hề kém cạnh Functional Requirement. Nó sẽ là yếu tố làm cho system này better hơn system kia. Nếu không chú trọng Non-Functional Requirement, BA sẽ không deliver được hết những giá trị gia tăng cho khách hàng. Và chính những yếu tố được xem là “nhỏ” như vầy sẽ kéo khách hàng lại với mình trong những dự án lần sau.
Non-Functional và Functional Requirement phải hợp lý và bổ trợ được với nhau. Nếu không kết quả solution sẽ không có giá trị cho lắm.
P
Pilot: là chạy thử, thử nghiệm solution trên một quy mô giới hạn nhằm đảm bảo tính hiệu quả và tránh gây ra lãng phí không đáng có.
Prototype: nói đơn giản là bản demo cho khách hàng. Còn để hiểu chính xác thì prototype là một nguyên mẫu mô phỏng giải pháp mà mình dự định sẽ deliver cho khách hàng.
Product Backlog: là một danh sách tập hợp các User Story, các yêu cầu của khách hàng hoặc các tính năng sẽ có trong tương lai mà team dự án dự định sẽ triển khai.
S
System Rule: là những giới hạn và quyền hạn của end-user trên hệ thống. System Rule sẽ giúp thực thi được các Business Rule thực tế của doanh nghiệp trên hệ thống.
Scope: phạm vi dự án là giới hạn về sự kiểm soát dự án, về các sự thay đổi và các solution có trong dự án và về cả nhu cầu của khách hàng.
Swimlane: là một thuật ngữ trong các sơ đồ thể hiện quy trình hoạt động. Cụ thể, swimlane là một khu vực có thể theo chiều dọc hoặc ngang, mà ở đó thể hiện được vai trò và công việc của một đối tượng cụ thể. Swimlane là một thứ không thể thiếu trong BPMN diagram.
T
Traceability: là tính năng có thể lần lại được các sự thay đổi đã diễn ra một đối tượng hoặc giữa các đối tượng với nhau.
U
User Story: có thể hiểu là một yêu cầu cấp cao ở dạng tổng quát. User Story bao gồm các thông tin cần thiết để team triển khai break ra được các requirement cụ thể trong User Story đó. User Story thường được viết ở dạng: As a <>, I want to <>. So that, I can <>.
Cấu trúc viết User Story phổ biến
User Acceptance Test (UAT): là những session mà khách hàng sẽ test xem thử những giải pháp mà team triển khai đã deliver có meet được với yêu cầu của khách hàng hay không.
Unified Modelling Language (UML): ngôn ngữ mô hình hóa thống nhất là một phương pháp luận để thể hiện (để mô hình hóa) các loại quy trình của doanh nghiệp theo một tiêu chuẩn đã được thống nhất. Mình nhớ là UML có tới hơn 14 loại mô hình. Anh em có thể tìm hiểu thêm về UML tại www.uml.org.
Still loading….!
Nguồn: thinhnotes.com
