I.

Nhóm kiến thức của Business Analyst

Hello anh em

Như mình có nói trong bài Business Analyst là gì và làm những gì?, một người BA sẽ phải gặp gỡ và kết
nối với rất nhiều người. Do đó BA luôn cần aware tới việc nâng cao kiến thức và kỹ năng của chính mình.

Bản thân mình tốt lên. Công việc được giải quyết nhanh gọn hơn. Anh em sẽ có nhiều thời gian hơn để
tiếp tục rèn luyện và nâng cao chất lượng công việc.

BABOK ver3 mô tả nhóm kiến thức (Knowledge Areas) của một người làm Business Analyst như sau.

Nguồn ảnh: BABOK (ver3)

Knowledge Areas và Underlying Competencies

Đọc trong BABOK, thường mình sẽ dễ bị lẫn lộn giữa Knowledge Areas và Underlying Competencies.

• Underlying Competencies nôm na là các kỹ năng cần của một người làm BA.

• Còn Knowledge Areas là các nhóm kiến thức mà một người làm công việc Business Analyst cần
phải có (nó là nhóm kiến thức đại diện cho các lĩnh vực chuyên môn của BA).

Underlying Competencies provides a description of the behaviors, characteristics, knowledge,

and personal qualities that support the practice of business analysis.
Knowledge Areas represent areas of specific business analysis expertise that encompass several tasks.

Nguồn: BABOK v3

Anh em nên hiểu tách biệt vậy cho rõ ràng. Kỹ năng là gồm cả cứng và mềm. Thời gian tu luyện sẽ cho
biết được kỹ năng của người này cao hơn, hay thấp hơn với người khác.

Còn kiến thức là thứ nền tảng, là kim chỉ nam cho toàn bộ hoạt động của BA. 100% các công việc thường
ngày của BA đều dựa trên nhóm kiến thức này.

Và cũng giống như kỹ năng, đây là những thứ mà mình tin rằng không chỉ đơn thuần rèn luyện, học hỏi
là có. Mà quan trọng là phải được tích lũy từ những kiến thức cơ bản, rồi áp dụng thực tế, chinh chiến
qua nhiều dự án thì mới rút kinh nghiệm và thẩm thấu được.

Ô kê hiểu sơ bộ vậy rồi, giờ thì cùng tìm hiểu về Knowledge Areas nhé anh em

Nội dung [Hide]

• 1. Lên kế hoạch và theo dõi tiến độ

• 2. Moi móc và cấu kết với anh em

o 2.1. Moi móc thông tin – Elicitation

o 2.2. Cấu kết với anh em – Collaboration

• 3. Quản lý requirements

• 4. Hiểu về chiến lược của khách hàng

• 5. Phân tích và thiết kế

• 6. Đánh giá giải pháp

1. Lên kế hoạch và theo dõi tiến độ

Planning và Monitoring, đây là 2 kỹ năng không thể thiếu của một người làm Business Analyst. Đây là
hai kỹ năng có ảnh hưởng trực tiếp đến các đầu mối công việc trong dự án.

Nhóm kiến thức về planning và monitoring được đưa lên đầu trong sơ đồ bởi vì tầm quan trọng và độ
bao quát của nó.

Anh em cũng biết là planning thì không có sai hoặc đúng, mà chỉ là phù hợp hay không mà thôi. Phù hợp
là đảm bảo được những resources hiện có và yêu cầu của dự án.

Resources là cả về nhân lực, vật lực và cả khả năng tiếp cận được công nghệ mới.

PM đưa ra plan cho dự án có sát với thực tế hay không, tùy thuộc rất nhiều vào kinh nghiệm của anh
này.
Một anh BA lên plan cho internal team cùng làm việc. Hay đơn thuần là những task công việc cho chính
bản thân, cũng đòi hỏi phải tích lũy nhiều góc nhìn và trải nghiệm thì mới sát thực tế được.

Plan anh em eiii…!!!

Thường thì mình sẽ thấy thoải mái và có động lực làm việc hơn khi có mục tiêu rõ ràng.

Từ những mục tiêu nhỏ, đạt được nó, rồi đi tiếp đến một mục tiêu khác. Tiếp tục đạt được nó, rồi lại đi
tiếp đến một mục tiêu khác. Đạt được nó, đạt được nó và mình sẽ đạt được mục đích đề ra ban đầu từ
việc đạt được những mục tiêu nhỏ này.

Như vậy, mình có thể keep track được tiến độ công việc. Điều này mang lại sự chủ động trong công
việc. Và dĩ nhiên, xuất phát điểm phải bắt đầu từ những việc nhỏ.

Điều này giúp mình bám sát kế hoạch và chủ động thay đổi nếu có phát sinh. Và đặc biệt là nó giúp mình

luôn ở thế chủ động, không bị task đè

Chỗ mình ngồi có 2 cái bảng nhỏ. Sáng lên công ty mình hay viết lên bảng 3-4 tasks mà mình muốn làm
trong ngày. Ngồi làm là luôn nhìn thấy nó. Đập thẳng vào mặt nên auto nhớ, muốn quên cũng không

được

2. Moi móc và cấu kết với anh em

2.1. Moi móc thông tin – Elicitation

Elicit là động từ, danh từ là Elicitation, nghĩa là moi móc, đào bới.

Trong bối cảnh Business Analyst, elicit nghĩa là moi móc thông tin nhằm lấy được requirement. Dùng
eilicit chính xác hơn so với get, hay gather.

Elicit là moi móc những thông tin từ khi nó còn “chưa tồn tại”, chưa được hình thành nữa. Thường là
thông tin chưa có sẵn, chưa được phát biểu ra (unstated). Mình phải moi móc, phải elicit cho ra được
thông tin, thành thông tin đã được phát biểu (stated).

Còn get hay gather thường chỉ dùng cho những thông tin đã có sẵn. Mình chỉ việc lấy về hoặc tập hợp lại
thôi. Giống như đi hái hoa bắt bướm thì hoa với bướm có sẵn rồi, chỉ đi bắt, đi lụm về thôi. Còn
requirement thì đâu dễ ăn như vậy.

Anh em xem thêm bài mình chém gió về Requirement và chuyện moi móc thông tin nhé.
2.2. Cấu kết với anh em – Collaboration

Collaboration, nghĩa là cộng tác, hợp tác, cấu kết với anh em cùng làm 1 cái gì đó, tốt cho dự án.

Không chỉ đơn thuần là teamwork, mà một người BA còn phải làm cho cả team cộng tác với
mình và cộng tác với nhau một cách hiệu quả nhất.

Làm việc tốt với mọi người vẫn là chưa đủ. BA cần phải đảm bảo các thành viên khác làm việc trơn tru và
hiểu ý nhau nữa.

Là một người nắm nhiều thông tin trong dự án, nên kết nối mọi người là “nghĩa vụ cao cả” của một
người làm BA.

Nghe có vẻ không liên quan, nhưng anh em hãy thử hình dung như thế này nhé.

Một anh tester và một anh dev xích mích với nhau về một tính năng. Ai cũng có lý của mình hết. Lúc
này người nắm nhiều thông tin nhất là BA, sẽ nhảy vào can thiệp để giải quyết vấn đề cho mọi người.

BA sẽ cố gắng giải thích theo góc độ lập trình và cả góc độ người dùng để hai bên thấy rõ được góc nhìn
của nhau.

Tuy đây không phải là một trong những yêu cầu công việc của BA, nhưng BA nên có nhận thức về điều
này. Nó như một underlying responsibility của BA.

Điều này sẽ giúp công việc của team trơn tru hơn.
Và dĩ nhiên, làm tốt thì sẽ rất là tốt, làm không khéo có thể gây ra những ảnh hưởng tiêu cực khác. Nên
chủ đề của bài này vẫn mong anh em luôn chú trọng nâng cao kỹ năng và kiến thức của mình. Từ đó giúp

giải quyết công việc một cách hiệu quả hơn

3. Quản lý requirements

Có bốn loại requirement trong một dự án:

• Business Objective Requirements

• Stakeholder Requirements

• Solution Requirements

• Transition Requirements

Việc quản lý dòng đời các requirements bắt đầu từ lúc khởi tạo cho đến khi các requirements được xử
lý.

Thực tế thì requirement rất hay thay đổi hoặc thêm mới. Thay đổi lớn có, nhỏ có. Tùm lum tùm la hết.
Và dĩ nhiên, nếu không kiểm soát tốt, nó sẽ là một mớ hỗn độn, phá nát dự án ở mọi khía cạnh (từ time,
budget, scope cho đến resources).

Không phải lúc nào cũng gật đầu “accept” một requirement mới. Và không phải lúc nào
cũng “reject” những requirement mới này.
Việc quản lý requirement như thế nào phụ thuộc rất nhiều vào việc dự án được triển khai theo phương
pháp nào: Waterfall, RUP hay Agile.

Mỗi phương pháp đều có những đặc điểm riêng. Và requirements trong các phương pháp này cũng
được quản lý rất khác biệt.

Thường thì trong dự án triển khai theo kiểu Waterfall hay RUP, requirements được chốt rất rõ ràng ngay
từ đầu. Trong quá trình triển khai, sự thay đổi là có nhưng không đáng kể.

Còn Agile thì lại welcome to change. Mật độ thay đổi requirement trong những dự án này khá thường
xuyên.

Nhưng quan trọng nhất, anh em BA cần phải học cách:

• Hiểu được sự xuất hiện của các requirement.

• Kiểm soát được các requirement từ lúc khởi tạo, có sự thay đổi cho tới khi được xử lý >> control
được sự kỳ vòng từ phía users.

Anh em đọc thêm bài note này để xem thử requirement nó chạy thế nào xuyên suốt dự án nhé anh
em: Quy trình dự án, BA làm gì ở trỏng? (P1)

4. Hiểu về chiến lược của khách hàng

BABOK nó dùng từ Strategy Analysis, dịch trắng ra là “phân tích chiến lược”. Mình thấy dùng từ này nó
đao to búa lớn quá, nên mình nghĩ một cách đơn giản: chỉ cần anh em hiểu về chiến lược của khách
hàng, là đã đủ để phục vụ công việc của một người làm BA.

Hiểu về chiến lược của khách hàng là sao?

Khi làm giải pháp, rõ ràng anh em phải nắm được giải pháp đó làm ra, để giải quyết vấn đề gì. Và rồi
mình mapping vấn đề đó với bối cảnh hiện tại của khách hàng, xem thử có suy ra được điều gì đáng chú
ý hay không.

Từ đó, anh em mới có góc nhìn rộng nhất về tổng quan bài toán mà khách hàng đang gặp.

Ví dụ mình đang làm giải pháp CRM cho một doanh nghiệp F&B. Cái sâu sa họ muốn là gì, có phải chỉ
đơn thuần là 1 giải pháp quản lý bán hàng? (trong khi thực tế là họ vẫn đang chạy một con local CRM rất
ngon).

Thu gom nhiều yếu tố, mình có thể suy ra được: họ đang muốn chuyển đổi toàn bộ giải pháp IT của
họ. Từ nhiều cục, họ muốn tất cả centralize lại thành một cục, một nền tảng, nhưng có nhiều giải pháp
trong đó.

Họ vừa chuyển đổi thành công ERP sang nền tảng Microsoft, giờ tiếp theo sẽ là CRM, sau đó là e-Office,
POS và kể cả toàn bộ cơ sở hạ tầng.
Đó chính là mong muốn sâu sa nhất của họ. Những giải pháp hiện tại chạy tốt, nhưng về cơ bản, nó đang
không tập trung, và data vẫn đang nằm rải rác rất nhiều nơi. Và điều này không đáp ứng được hướng đi
lâu dài của BOD.

Khi hiểu được điều này, anh em sẽ có hướng tiếp cận khách hàng phù hợp hơn. Cách đề xuất và đánh giá
giải pháp phù hợp hơn, so với việc, chỉ nghĩ một cách đơn giản cục bộ là họ chỉ đang cần một giải pháp
về CRM.

Và một lần nữa, giải pháp mình đề xuất đáp ứng được nhu cầu hiện tại của khách hàng. Nhưng nó cũng
phải map được với hướng đi lâu dài của họ trong tương lai.

5. Phân tích và thiết kế

Analysis and Design, chắc chắn ai làm Business Analyst cũng đều làm cái này.

Requirement Analysis and Design để đơn giản thì mình có thể hiểu là một loạt các việc bao gồm:

• Tổ chức và sắp xếp các requirement một cách có cấu trúc.

• Phân loại rõ các loại requirement.

• Verify requirement với internal team.

• Validate requirement với khách hàng.

• Làm tài liệu và mô hình hóa các requirement phù hợp với từng stakeholders cụ thể.

• Cùng với team đề xuất solutions phù hợp.

• Xác định những solution nào đáp ứng được business needs.

• Có thể là ước tính được những giá trị mà solution đó mang lại như thế nào so với các solution
khác. Hoặc có thể show cho khách hàng thấy Return On Investment là như thế nào.

6. Đánh giá giải pháp

Cái này thì rõ ràng quá rồi chứ hả anh em.

Không thể nào đi thuyết phục khách hàng ăn một món ăn dở, mà ngay cả mình cũng ghét

nữa Mình phải đánh giá một cách rất khách quan và tâm huyết với giải pháp mình đem lại thì mình
mới có thể deliver một cách hoàn chỉnh nhất có khách hàng được.

Như mình có nói ở trên, không chỉ hiệu quả trong thời điểm hiện tại mà còn phải phù hợp với hướng đi
lâu dài của khách hàng.

Ô kê mình sẽ tạm kết bài này ở đây. Hi vọng qua bài này, anh em hiểu được: 6 Knowledge Areas của một
người làm BA, tức nhóm kiến thức chuyên môn của một người làm BA. Nó bao gồm:
 • Business Analysis Planning and Monitoring – Lên kế hoạch và theo dõi tiến độ

• Elicitation and Collaboration – Moi móc và cấu kết

• Requirements Life Cycle Management – Quản lý requirements

• Strategy Analysis – Hiểu chiến lược của khách hàng

• Requirements Analysis and Design Definition – Phân tích và thiết kế

• Solution Evaluation – Đánh giá giải pháp

Mỗi ngành nghề có những kiến thức chuyên môn nhất định, và BA cũng có nhóm kiến thức chuyên môn
của riêng mình.

Hiểu và cố gắng áp dụng nó vào công việc và cuộc sống. Mình cũng đang cố gắng từng ngày, nhưng nhớ

áp dụng một cách linh hoạt và đừng rập khuôn nhé anh em

II. Business Analyst

Business Analyst là gì?

Mình thấy anh em vẫn hay nói Business Analyst là cầu nối, giúp kết nối và truyền đạt yêu cầu của khách
hàng với đội ngũ lập trình. Thực ra hiểu vậy cũng đúng, nhưng rất tối nghĩa và không thoát được hết ý
nghĩa của nghề BA.

Lúc trước mình cũng nghĩ như vậy. Mình còn nghĩ công việc Business Analyst chỉ tồn tại trong ngành IT
nữa. Nhưng thực chất thì BA không phải là một chức danh công việc. Và nó cũng không chỉ đơn thuần
như một chiếc cầu nối mà mọi người thường hay nói.

Business Analyst là gì và làm những gì? Bài này mình sẽ chia sẻ về những gì mình hiểu và áp dụng thực
tế cho anh em.

Nội dung

• 1. Business Analyst là gì

o 1.1. Business Analyst Concept

o 1.2. Một vài ví dụ

o 1.3. Business Analyst xuất hiện ở mọi ngóc ngách trong cuộc sống

o 1.4. Business Analyst không chỉ có riêng trong ngành IT

• 2. Business Analyst làm gì?

o 2.1. Business Requirement Analyst

 o 2.2. System Analyst

o 2.3. Business System Analyst

o 2.4. Functional Analyst

o 2.5. Agile Analyst

o 2.6. Service Request Analyst

• 3. Tạm kết

1. Business Analyst là gì

Business Analyst là đây!

Cụ thể thì Business Analyst sẽ là người thực hiện chính xác quy trình trên.

1.1. Business Analyst Concept

Cụ thể nhé. Từ các vấn đề mà doanh nghiệp đang gặp phải, doanh nghiệp có mục tiêu phải giải quyết
được các vấn đề này. Các mục tiêu đó gọi là Business Objectives.

Từ các Business Objective, BA sẽ làm việc với Stakeholders để đưa ra các Solution cụ thể. Các Solution
này phải đáp ứng được yêu cầu của các Stakeholder.

Sau đó, BA cùng đồng bọn sẽ xây dựng và triển khai Solutions đó cho doanh nghiệp. Giai đoạn triển khai
này gọi là Transition. Sẽ “biến” hiện trạng của doanh nghiệp ở thời điểm hiện tại thành trạng thái mong
muốn trong tương lai.

Và lúc này, các vấn đề mà doanh nghiệp gặp phải đã được giải quyết.

Do đó, Business Analyst là một loại công việc, người nào làm một loạt các việc trên sẽ được gọi là
Business Analyst.

Mình nghĩ có nhiều anh em vẫn nghĩ trong đầu là: BA phải nói được ngôn ngữ kinh doanh và ngôn ngữ
lập trình. Hiểu được cả các khái niệm kinh doanh, lẫn các khái niệm đặc thù trong ngành IT, như
database, web service, API, cloud, bla bla…
Nên mọi người vẫn cứ nghĩ: nhắc đến BA là nhắc đến “cầu nối” hay “người phiên dịch”. Nhưng như mình
nói thì đó chỉ là điều kiện cần của BA thôi chứ không nói lên được nghề này là gì và làm những gì.

Và solution không chỉ là một hệ thống, phần mềm hay một giải pháp công nghệ nào đó. Mà Solution có
thể là bất kỳ điều gì. Từ việc thay đổi chính sách, quy trình trong doanh nghiệp. Hay đơn thuần chỉ là
training lại cho doanh nghiệp mình.

Miễn giải quyết được Business Objectives thì đó đều là Solutions

1.2. Một vài ví dụ

Có một công ty muốn mở rộng thị trường.

Họ cần quản lý khách hàng và các cơ hội kinh doanh một cách tốt hơn. Thay vì thời điểm hiện tại, tất cả
đều được quản lý bằng excel. Thì đâu đó, một hệ thống CRM có thể giúp sẽ họ quản lý được tốt hơn
những thứ trên.

Business Objective ở đây là muốn quản lý tốt hơn khách hàng và các cơ hội kinh doanh. BA cần phải
nhìn ra điều này và cung cấp solution chính là việc áp dụng hệ thống CRM vào bộ máy hoạt động của
công ty đó.

Tuy nhiên đâu dễ ăn của ngoại :3

Không phải lúc nào Business Objectives cũng rõ ràng và đơn giản như vậy. Đa phần thì khách hàng họ
cũng không biết họ muốn gì, hoặc họ muốn quá nhiều. Khiến cho công việc Business Analyst cần phải
có nhiều đồ nghề hơn nữa, để nhìn ra được, đâu mới là Business Objectives thật sự của khách hàng.

Họ nói cần A không có nghĩa là họ đang thiếu A. Hoặc họ nói cần A nhưng thực chất lại là cần B.

Oái ăm là ở chỗ này.

Do đó để phát hiện chính xác vấn đề của họ đã khó, đề xuất solutions cho phù hợp lại càng khó hơn. Nên

“phiên dịch” không phải là từ phù hợp để mô tả một công việc BA thực thụ

Một điểm nữa là không phải lúc nào, việc áp dụng một hệ thống mới cũng là phương án hay. Và việc sử
dụng Excel cũng là cách hoạt động lỗi thời cả.

Có một số tổ chức vận hành bộ máy hoạt động của họ chỉ với những sheet Excel. Do họ “trưởng thành”,
và họ biết họ cần gì, và bao nhiêu là đủ với họ.

Excel là một công cụ tuyệt vời với khả năng vô tận của nó. Thậm chí Bill Gates còn chưa chắc biết hết

chức năng của Excel mà

Kể chuyện này anh em nghe mất hồn chơi.

Cũng bên Nhật Bản, có một ông tên Tatsuo Horiuchi. Ông này là họa sĩ nhưng không hiểu vì sao mà ổng
không vẽ trên giấy bút hay các phần mềm đồ họa khác như mọi người. Mà ổng vẽ bằng…..Excel.

Ổng chọn Excel như giải pháp để ổng thể hiện ý tưởng của mình. Một giải pháp mà không ai ngờ được.
Solution ở mọi nơi. The possibilities are endless

1.3. Business Analyst xuất hiện ở mọi ngóc ngách trong cuộc sống

Thiệt đúng là như zậy. Công việc BA tồn tại ở mọi ngóc ngách trong cuộc sống của mình.

Ví dụ bữa nọ đi làm về, xe hết xăng.

Rõ ràng là ngay lúc đó anh em muốn: tìm trạm xăng >> đổ xăng >> chạy tiếp về nhà.

Vậy thì Business Objectives lúc này của anh em sẽ là: “xe được đổ xăng để chạy tiếp về nhà” đúng
không nào.

Sẽ có rất nhiều Solutions anh em có thể nảy sinh ra ngay, như:

• Dắt bộ đến trạm xăng gần nhất.

• Gọi bạn bè ra cứu bồ.

• Nhờ bà con bên đường giúp đỡ.

• Tìm cây xăng lẻ.

• Hoặc thậm chí gửi xe đâu đó, bắt Grab đến cây xăng gần nhất rồi mua bịch xăng về đổ.

Anh em sẽ phải chọn, xem đâu là Solution phù hợp nhất ngay lúc này. Và Solution này có đáp ứng được
mức độ hài lòng của các Stakeholders hay không.

Stakeholders trong trường hợp này có thể là:

• Vợ con đang ở nhà chờ cơm.

• Đồng bọn đang chờ ở bàn nhậu.

• Một cuộc hẹn cà phê nào đó vào buổi tối.

• Hoặc có thể là mình chẳng phụ thuộc vào ai cả, tự mình chính là Stakeholder của chính mình.

Anh em cần phải tìm ra được solution đáp ứng tốt nhất nhu cầu của các stakeholders ngay lúc này.

Khi đã có solution, anh em phải thực hiện quá trình Transition một cách hiệu quả. Nếu không muốn tốn
quá nhiều thời gian vào chuyện này.

Anh em có thể khẩn trương dắt xe tới ngay một trạm xăng gần đó. Hoặc có thể thư thả gọi đồng bọn tới
cứu bồ. Tất cả những điều này đều tùy ở bản thân mình. Miễn đáp ứng được mục tiêu xe được đổ xăng
để chạy về nhà là thành công.

Nếu thực hiện các công việc trên, thì anh em đã làm công việc của một Business Analyst rồi. Chỉ khác ở

chỗ không phải là phiên bản công việc, mà là phiên bản cuộc sống thực tế thôi
1.4. Business Analyst không chỉ có riêng trong ngành IT

Thoát ra khỏi bối cảnh IT, công việc BA vẫn tồn tại ở những ngành nghề và lĩnh vực khác.

Từ “business” không chỉ có nghĩa là kinh doanh hay nghiệp vụ, mà còn là “vấn đề”. Anh em xem phim
Mỹ hay có câu: “This is not your business!”.

Business đồng nghĩa với matter.

Do đó, Business Analyst hiểu rộng ra hơn là người đi phân tích và giải quyết các vấn đề.

Ở Việt Nam mình thấy chia ra rõ ràng nhất là IT BA và BA. IT BA chiếm số đông hơn hẳn, họ làm Business
Analyst trong ngành IT.

Nhưng BA không phải là siêu nhân, BA sẽ không bao giờ tự chém gió ra các solutions mà không có đồng
bọn. Người làm Business Analyst sẽ phải kết nối với rất nhiều với stakeholders để đưa ra solution phù
hợp nhất.

Giá trị rõ nhất mà một BA có thể mang lại đó là họ nhìn nhận rõ được hiện trạng của tổ chức, và hệ
thống hóa được những gì cần làm để đạt được trạng thái “tốt hơn” của tổ chức đó.

Sau đó, nhiệm vụ thực thi là của cả team, cả tổ chức. Và khi mọi thứ đã rõ ràng, khả năng hiện thực hóa
sẽ cao hơn rất nhiều.

Tiện thể, Stakeholder dịch ra tiếng Việt là các bên liên quan. Nhưng dịch ra như vậy cũng chưa bám sát ý
nghĩa lắm. Cho đơn giản mà chính xác, anh em cứ hiểu: “stake” là cái cột, “holder” là người nắm giữ.
Ghép lại, Stakeholder là “Người nắm giữ những cái cột”.

Mà cái cột thì rất quan trọng trong bất kỳ ngôi nhà nào. Nó chống đỡ cho ngôi nhà. Trong dự án cũng
vậy, có những người sẽ giữ vai trò quyết định rất quan trọng. Những người này được gọi là
Stakeholders.

Hình minh quạ mấy ông stakeholder đang ngồi bàn bạc với nhau…

Stakeholders thường được chia thành các nhóm chính sau:

• Project team
 • Project sponsor

• Performing organization

• Partners

• Client

• Và một số “đối tượng” khác.

Làm việc với stakeholder là cả một chủ đề bao la, nên mình sẽ nói kỹ về stakeholder ở những bài sau nhé
anh em.

2. Business Analyst làm gì?

Công việc BA được thực hiện dưới rất nhiều vai trò khác nhau. Họ cũng làm y như sơ đồ đầu bài.

Từ Business Objectives >> làm việc với Stakeholders >> đề xuất Solutions >> làm Transition

Nhưng mỗi người sẽ thực hiện ở một mức độ khác nhau.

Theo BABOK ver3.0, công việc IT Business Analyst được thực hiện bởi 6 vai trò sau.

Nhìn cái hình, anh em sẽ hơi hoang mang hồ quỳnh hương chút xíu, nhưng yên tâm, dưới đây mình sẽ
giải thích kỹ hơn

2.1. Business Requirement Analyst

Đầu tiên là Business Requirement Analyst. Người đảm nhiệm vai trò này thường sẽ là người đưa ra các
giải pháp ngay thời điểm ban đầu làm việc với khách hàng.

Giải pháp ở đây rất đa dạng, có thể là: thay đổi chính sách công ty, điều chỉnh quy trình nghiệp vụ hoặc
training cho nhân viên. Sau đó mới là đề xuất áp dụng phần mềm, hệ thống hay một giải pháp công
nghệ. Hoặc áp dụng nhiều giải pháp với nhau để giải quyết bài toán mà doanh nghiệp gặp phải.

Người giữ vai trò này thường là Project Manager, Senior Business Analyst hoặc Principle Business

Analyst. Nói chung thường là trùm cuối thì mới giữ vai trò này
Vai trò này xuất hiện thường xuyên nhất trong giai đoạn Pre-Sales. Thường thì các PM hoặc những
người làm Business Analyst giàu kinh nghiệm sẽ tham gia vào quá trình này.

Họ sẽ tiếp nhận các vấn đề và yêu cầu ban đầu của doanh nghiệp. Phân tích một bức tranh toàn cảnh và
đưa ra 1 giải pháp tổng quan phù hợp nhất.

2.2. System Analyst

System Analyst thường là vai trò dành cho những người làm kỹ thuật. Họ có nhiều kinh nghiệm và rất
am hiểu về hệ thống.

System Analyst thường là chuyên gia về một khái niệm kỹ thuật hoặc một phương pháp kỹ thuật phức
tạp nào đó. Như blockchain chẳng hạn. Họ thường tham gia vào các dự án có độ phức tạp về kỹ thuật
cao.

Thường có một số dự án liên quan đến migrate data, đưa hệ thống lên mây hoặc tích hợp hệ thống sẽ
cần sự tham gia rất nhiều của System Analyst.

System Analyst sẽ phân tích hệ thống hiện tại, xem xét các yêu cầu và thiết kế một kiến trúc hệ thống
mới dựa trên những gì đã có.

2.3. Business System Analyst

Đây là vai trò chính yếu và nổi trội nhất của một người làm BA. Theo trình tự timeline của dự án, một
người có vai trò Business System Analyst sẽ có những nhiệm vụ chính sau:

Moi móc và khai thác thông tin từ các Stakeholders về chức năng và yêu cầu của dự án. Có thể thông
qua email, phỏng vấn trực tiếp hoặc demo hệ thống.

Làm tài liệu. Đây là một trong những công việc và kỹ năng rất quan trọng của BA. Document thì có rất
nhiều loại, mỗi loại dành riêng cho một Stakeholder. Vì không thể nào đưa bản thiết kế nhà cho thợ điện
lắp ráp điện được đúng không. Nói dễ, viết mới khó. Viết sao cho người khác dòm zô là hiểu cái một là

một kỹ năng đòi hỏi phải thực hành nhiều

Truyền đạt thông tin. BA phải đảm bảo được tất cả Stakeholders đã hiểu đúng các vấn đề. Mà một dự
án thì có rất nhiều vấn đề, và có rất nhiều thông tin cần truyền tải. BA có kỹ năng ăn nói tốt, giải quyết
mâu thuẫn và giải quyết vấn đề tốt thì thông tin trong dự án được truyền đi rất mượt và nhất quán.

Vắt não ra nghĩ solution. Mang tiếng là người đi giải quyết các vấn đề mà không làm công việc này thì
hơi kỳ đúng không anh em. Vấn đề có vấn đề lớn, vấn đề nhỏ. Từ khâu làm việc nội bộ với team cho đến
làm việc với khách hàng.

Sẽ có hàng trăm thứ xảy ra đòi hỏi mình phải xử lý rất nhiều. Việc đối mặt với vấn đề không phải lúc nào
cũng thuận tiện, nhưng somehow nó sẽ giúp anh em tư duy logic và cứng hơn rất nhiều.

Business System Analyst là vai trò thường gặp nhất đối với một người BA (hình chôm từ Modern
Analyst)

2.4. Functional Analyst

Vai trò này giống như Business System Analyst. Nhưng thay vì phát triển mới một sản phẩm giải pháp từ
hư vô (build from scratch), người làm Functional Analyst sẽ dựa trên một sản phẩm hay một platform
sẵn có. Từ đó configure hoặc customize sao cho sản phẩm đó mapping được với yêu cầu của khách
hàng. Giúp giải quyết bài toán mà doanh nghiệp gặp phải.

Trên thị trường có rất nhiều ông lớn cung cấp các sản phẩm hoặc nền tảng sẵn có như: Microsoft, SAP,
Oracle, Sharepoint, Salesforce, vâng vâng và mây mây.

2.5. Agile Analyst

Người giữ vai trò Agile Analyst sẽ có trách nhiệm đảm bảo deliver thông tin một cách chính xác, kịp thời
và phù hợp với các đối tượng Stakeholder.

Ensure the right info, with the right level & at the right time.

Ngoài ra, Agile Analyst là vai trò không thể thiếu trong các dự án triển khai theo phương pháp Agile như
Scrum chẳng hạn.

Deliver những gì đã cam kết với khách hàng là một trong những yếu tố cực kỳ quan trọng trong dự án
Agile. Do đó Agile Analyst đóng một vai trò rất quan trọng trong dự án kiểu như vậy.

2.6. Service Request Analyst

Thường thì BA sẽ giữ vai trò này trong giai đoạn triển khai giải pháp cho khách hàng (transition).

Người giữ vai trò Service Request Analyst sẽ có nhiệm vụ training cho end-users, thực hiện các buổi User
Acceptance Test (UAT), xử lý khi gặp lỗi nếu có và có thể là tiếp nhận thêm những yêu cầu tính năng
mới từ phía khách hàng.

Business Analyst có 6 vai trò khác nhau, nhưng không phải mỗi người chỉ được đảm nhận một vai trò.
Mà là một người làm Business Analyst phải đảm nhận nhiều vai trò cùng một lúc.

• Thường thì Business Requirement Analyst là vai trò dành cho PM hoặc BA nhiều năm kinh
nghiệm.
Còn hầu như một người làm BA bình thường đều đảm nhận các vai trò còn lại.

• Riêng anh em nào có vai trò Business System Analyst thì sẽ không có vai trò Functional Analyst.
Và ngược lại, người làm Functional Analyst sẽ không làm Business System Analyst. Nhưng các vai
trò khác vẫn được đảm bảo.

3. Tạm kết

Business Analyst là một nghề cũ trên thế giới, nhưng mới ở Việt Nam (khoảng hơn 15 năm).

Thực sự thì mình thấy đây là một nghề rất thú vị và có khá nhiều challenge. Điểm mạnh điểm yếu của
mình được cọ xát rất nhiều. Nhiều vấn đề thực sự rất chuối nhưng khi gỡ rồi thì đã lắm.

BA xuất hiện để giải quyết vấn đề. Vấn đề có thể là biến cái chưa tốt thành cái tốt. Hoặc biến cái đã tốt
rồi thành cái tốt hơn.
Thật sự cảm giác đem lại cái gì đó ý nghĩa cho người khác là một thứ khiến mình khó mà nản được.

III. Hiểu về Requirement như thế nào cho đúng?

Hế lô anh em! Ai cũng biết là requirement là 1 thứ rất quan trọng. Và hầu như được quan tâm nhiều
nhất trong các dự án.

Đối với BA thì requirement là một trong những yếu tố thể hiện được performance của mình.
Requirement có rõ ràng hay không, có sát thực tế hay không, có đảm bảo được đúng scope hay không,
bla bla…

Đối với requirement, đầu tiên thì chúng ta phải lấy nó về, hay nói thực tế là phải “moi móc, gợi mở” nó
về.

Requirement sau khi được lấy về, chúng ra sẽ phải xử lý nó. Lấy như thế nào và xử lý như thế nào? Bài
này mình sẽ chia sẻ về những gì mình hiểu và đã áp dụng thực tế.

Ngoài ra bài này mình cũng sẽ chém gió về cái gọi là Requirement thực sự của khách hàng. Nó tồn tại
như thế nào? Và làm thế nào để nhận biết được đó có phải thật sự là requirement của khách hàng
hay không?

Trạng thái và các bước xử lý requirement trong Business Analyst được thể hiện ở hình dưới đây. Toàn bộ
bài viết mình sẽ dựa vào hình này.

Nội dung [Hide]

• 1. Requirement trong Elicitation và Analysis

 o 1.1. Ở giai đoạn Elicitation

o 1.2. Ở giai đoạn Analysis

• 2. Ví dụ phát là hiểu ra liền

1. Requirement trong Elicitation và Analysis

Như hình trên, requirement trong Business Analyst tồn tại ở 2 giai đoạn: giai đoạn moi móc thông tin
(elicitation) và giai đoạn phân tích (analysis). Ở mỗi giai đoạn, requirement sẽ có những đặc tính riêng
và có cách xử lý riêng.

1.1. Ở giai đoạn Elicitation

Giả dụ có một công ty đang gặp vấn đề. Team triển khai sẽ xuất hiện để giải quyết vấn đề của họ. Khi đó
BA cần phải hiểu được họ đang gặp vấn đề gì để biết đường mà giải quyết đúng không nào.

Đương nhiên là công ty khách hàng sẽ không tuôn ra tất tần tật những vấn đề của họ. Không phải vì họ
không muốn, mà là vì họ không thể.

Cụ thể hơn là vì họ chưa hệ thống hóa được hiện trạng và vấn đề của họ. Do đó, BA cần phải elicit – tức
là moi móc thông tin để lấy được requirement từ họ.

Qua nhiều lần trao đổi, workshop hoặc làm việc với khách hàng, BA sẽ nắm được yêu cầu cụ thể từ phía
khách hàng (lẫn các stakeholders). Để rồi từ đó, chúng ta sẽ hệ thống hóa lại và cung cấp cho khách hàng
một góc nhìn tổng quan hơn về thông tin cũng như các requirements của họ.

Điều này có nghĩa là requirement ban đầu chưa được khách hàng nói ra, chưa được phát biểu ra
(unstated). Sau khi BA moi móc, requirement đó mới được nói ra và phát biểu ra bởi khách hàng
(stated).

Đó là mục đích của việc moi móc thông tin (elicitation). Và requirement sẽ từ trạng thái unstated chuyển

sang trạng thái stated

Mình nghĩ đây là một cách nghĩ rộng và tổng quan cho mọi vấn đề. Nó kích thích câu hỏi: “Tại sao khách
hàng lại muốn như vậy?”. Đây là một câu hỏi cực kỳ quan trọng. Không phải requirement nào cũng nên
ôm vào. Và không phải requirement nào cũng đáp ứng được mức độ hài lòng của khách hàng.

Khi tiếp nhận một requirement, cái đầu tiên mình nên nghĩ là khách hàng họ có thực sự họ cần cái này
hay không? Hay chỉ đơn thuần chỉ là… cơn mưa ngang qua thôi.

Câu chuyện requirement từ unstated sang stated là cả một quá trình. Sẽ có lý do để khách hàng nói ra
yêu cầu của họ cho mình nghe. Do đó, cần phải nhận diện đúng để biết đâu mới là requirement thật sự.
Và trong những requirement thực sự đó thì cái gì nên ưu tiên hàng đầu :3
1..2..3, requirement… hô biến :3

Nguồn: Modern Analyst

1.2. Ở giai đoạn Analysis

Requirement sau khi được anh em khai thác về sẽ được làm gì tiếp? Requirement sau khi thu thập về rất
lộn xộn và hỗn tạp nhiều loại.

Có thể là biên bản họp. Có thể là 1 tấm hình sketch lại quy trình kinh doanh. Có thể là một vài tấm hình
chụp những gì đã thống nhất trên bảng. Hoặc thậm chí có thể là file ghi âm quá trình moi móc thông tin
từ phía khách hàng. Nói chung là nhiều. Rất đa dạng và thường rất hỗn độn để anh em hệ thống lại.

Do đó, quá trình phân tích – Analysis sẽ giúp BA làm chuyện này. Nói nôm na Analysis không phải là phân
tích, suy luận gì ghê gớm hết. Mà đơn thuần, Analysis chỉ là đi hệ thống lại thông tin một cách phù hợp
mà thôi. Cụ thể nó là chuỗi các hoạt động như cái hình lúc nãy, mà là đoạn 3, 4, 5 và 6:
Các bước xử lý requirement trong Business Analyst

(3) Organized: Sắp xếp và tổ chức lại dữ liệu một cách có cấu trúc.

Hình ra hình, file word ra file word, excel ra excel. Đoạn ghi âm cũng cần phải tài liệu hóa lại. Những
phần nào là nháp thì note riêng ra. Những phần nào để chốt, quan trọng thì phải ghi nhận kỹ.

Thông tin sắp xếp theo chiều nào? Đi theo quy trình kinh doanh hay đi theo hành vi của người dùng?
Bước Organized cần phải xác định rõ những điều này.

(4) Specified: Trả lời câu hỏi các dữ liệu này được xác định và phân loại dùng để làm gì, dùng như thế
nào và dùng cho đối tượng nào?

Đối với end-user thì họ quan tâm cái gì? Họ liên quan đến thông tin nào, chức năng nào? Các
stakeholders còn lại thì sao? Khách hàng họ quan tâm gì, cần theo dõi thông tin gì? Trả lời càng rõ ràng
thì việc specify tài liệu sẽ dễ thở hơn. Sau này khi cần anh em cũng dễ lục lại.

(5) Verified: Bước này nhằm mục đích: đảm bảo các tài liệu mình hệ thống được đã ĐÚNG hay chưa.

Nhưng bước này là để verify với team nội bộ, chứ không phải khách hàng. Dữ liệu sẽ được internal team
kiểm tra xem thử đã chính xác và đảm bảo đúng logic hay chưa. Ví dụ các tài liệu đặc tả đã viết đúng
trình tự hay chưa? Đã thể hiện đầy đủ nội dung cần truyền tải hay chưa? Đảm bảo tất cả mọi thứ ok
trước khi deliver cho khách hàng.

(6) Validated: Bước này thì lại nhằm mục đích: confirm các thông tin trao đổi với khách hàng đã chính
xác, có sự ĐỒNG THUẬN giữa cả team phần mềm và phía khách hàng.

Dữ liệu sẽ được xác nhận với các stakeholder là đã đúng như yêu cầu của người ta hay chưa. Mỗi cái
meeting đều cần 1 người chốt lại biên bản họp. Thường thì vô họp chém ghê lắm, mà họp xong cũng
thường là quên hết bà.
Nói thêm về bước Specify, anh em BA cần phải làm tài liệu rất nhiều để gửi cho stakeholders. Mình note
lại mấy điều sau nên chú ý:

• Biết Stakeholder là ai để bàn giao tài liệu cho phù hợp. Mình chỉ nói cái người khác muốn nghe.
Không ai đi gửi tài liệu kỹ thuật cho end-users xem cả. Giống như không ai đưa bản vẽ thiết kế
đường ống nước cho thợ điện xem hết.

• Anh em nên nắm vững ngôn ngữ của mình, đó là Modelling. Modelling vẫn là một phương thức
truyền đạt thông tin vô cùng bá đạo. Nói bằng lời khó diễn tả quá thì mình vẽ ra, mô hình hóa nó
lại rồi lưu lại thành tài liệu. Mai mốt bà con có ai hỏi thì có hàng mà show liền. Đỡ mắc công giải
thích dài dòng, rườm rà.

2. Ví dụ phát là hiểu ra liền

Lý thuyết suông quá, ví dụ nhé anh em.

Có một cô gái mới ra trường cần mua một cái túi xách tay để đi làm.

Cô này có 300.000đ tiền để dành để mua một cái túi LV. Cô đến 1 cửa hàng chuyên bán túi thời trang nữ.

Người bán hàng hỏi cô gái: “Chị có cần em tư vấn gì không ạ?”

Cô gái trả lời: “Dạ em đang muốn mua 1 cái túi xách tay để đi làm, em có xem mấy mẫu LV trên website
của mình…”.

Giả sử cô gái là khách hàng còn người bán hàng là BA (vì người bán hàng đang đóng vai trò là người giải
quyết vấn đề cho cô gái).

Vậy thì vấn đề của cô gái là gì? Hay nói cách khác, requirement của cô gái là gì?

Đó là cần mua một túi xách tay đi làm đúng không nào. Ngay lúc đầu, requirement này của cô gái có
được nói ra, hay được phát biểu ra không?

Không, vì chỉ có mỗi cô gái mới hiểu được nhu cầu của cô mà thôi. Khi cô bước vào tiệm bán túi, người
bán hàng hỏi thì cô mới trả lời là tôi cần mua một cái túi LV. Đó là khi requirement được phát biểu ra.

Và người BA (ở đây là người bán hàng) đã hỏi cô gái để có được thông tin: à, cô này đang cần 1 cái túi đi
làm và cô muốn mua túi LV. Đây đúng là requirement của cô gái, do cô phát biểu ra. Nhưng thường thì
nó đâu có dễ ăn như vậy :)) Với trường hợp này thì mọi thứ không dừng lại ở đó.

Anh em nghĩ 300.000đ có thể mua được một cái túi LV không. Mình không rành túi nhưng cũng biết
chắc chắn là không rồi. Hàng đểu chắc cũng trên 300.

Với 300.000đ trong tay và đang cần 1 cái túi đi làm, nhu cầu thật sự của cô gái (requirement thật sự của
cô gái) là: mua một cái túi xách tay hàng Việt Nam, bền chắc và chất lượng, với mức giá tối đa là
300.000đ.

Đó mới thật sự là requirement phù hợp nhất với cô gái!

Và requirement này không chỉ đơn giản là từ unstated, hỏi một cái, chuyển thành stated là thôi. Mà
người BA (hay người bán hàng) cần phải tiếp tục elicit thêm thông tin. Như hỏi thêm: túi LV ở chỗ em có
3 mức giá, 850.000đ, trên 1.550.000đ và trên 4.200.000đ. Chị muốn xem mức giá nào. Lúc này, cô gái
cảm thấy không đủ ngân sách thì sẽ chuyển hướng sang một mẫu túi xách khác. Rẻ và phù hợp với mình
hơn.

Elicitation không chỉ đơn thuần là lấy thông tin từ khách hàng mà còn phải khơi gợi và hướng khách
hàng đi đúng hướng họ cần, gãi đúng chỗ họ ngứa. Và đó phải là hướng đi phù hợp với họ nhất trong
thời điểm hiện tại. Đâu đó sẽ có thêm hàm lượng business consultant vào quá trình này nữa.

Một cái túi ít tiền hơn chắc chắn sẽ là một giải pháp phù hợp hơn với cô gái lúc này

Thực tế là nhiều khách hàng cũng không biết mình đang muốn gì. Hay trớ trêu hơn, cái thực sự họ muốn
là quả táo, nhưng khi elicitation thì họ lại nói họ muốn quả chanh. Vì đơn giản, họ đang không thực sự
nhận thức được là họ đang cần quả táo chứ không phải quá chanh.

Họ chưa nhận thức ngay được điều đó và BA sẽ giúp họ hệ thống lại toàn bộ mọi thứ. Khi đó, chính
khách hàng sẽ tự trả lời được họ muốn gì một cách rõ ràng nhất.

Do đó, việc elicit thông tin để ra được requirement từ trạng thái unstated sang trạng thái stated là
không hề đơn giản chút nào. Đòi hỏi kinh nghiệm lão luyện mấy năm trời thì làm mới êm được.

Tóm gọn, requirement trong Business Analyst sẽ có 2 trạng thái: chưa được phát biểu và đã được phát
biểu.

Nhiệm vụ của người BA là phải thật cẩn thận trong việc MOI MÓC (ELICIT) thông tin. Để biến những
requirement từ trạng thái chưa đươc phát biểu thành trạng thái đã được phát biểu. Requirement chính
xác thì làm ra cái phần mềm mới chính xác, mới khớp với nhu cầu sử dụng của người ta. Không thì cũng
banh chành.

Tiếp đến, BA cần PHÂN TÍCH (ANALYSIS) những requirement này. Ý là hệ thống, sắp xếp lại thôi.
Quy trình analysis cứ lặp đi lặp lại cho đến khi nào đã đầy đủ các loại requirement cần có trong dự án thì
thôi. Bao gồm: Business Objective Requirement (cái này quan trọng), Stakeholder Requirement (cái này
cũng rất quan trọng), Solution Requirement (cái này thì lại càng quan trọng) và Transition
Requirement (cái này cũng quan trọng nốt).

Anh em tham khảo bài Business Analyst là gì mình có nói về 4 giai đoạn này.

IV. Quy trình dự án, BA làm gì ở trỏng? (P1)

Hế lôôôô anh em,

Từ lúc lập blog đến giờ mình có viết 2 bài về Business Analyst, đó là: concept tổng quan và những công
việc cụ thể hằng ngày. Đợt rồi mình có ngồi dòm lại những bài này thì hình như thấy nó thiếu thiếu gì đó.

Với những người mới, thì bài tổng quan có thể dễ hiểu, nhưng chưa cụ thể lắm. Còn bài công việc hằng
ngày thì lại… quá cụ thể, đến mức hơi lộn xộn, khó để anh em hình dung 1 cách tổng thể.

Do đó mình nghĩ phải có 1 bài ở giữa 2 bài này, để hệ thống lại rõ hơn công việc của BA theo trình tự
thời gian làm dự án. Từ đó anh em sẽ có cái nhìn rõ ràng hơn về công việc của BA.

Quy trình làm dự án

Đầu tiên sẽ là quy trình tổng quan như sau.

Quy trình dự án

Như anh em thấy quy trình làm phần mềm nó gồm 6 bước:

• Analysis: phân tích xem mình sẽ làm những gì

• Design: mình sẽ thiết kế phần mềm như thế nào

• Develop: mình sẽ code ra sao

• Test: phần mềm được đem đi test

• Deploy: phần mềm được đưa vào sử dụng

 • Maintain: giai đoạn bảo trì, hỗ trợ khách hàng sử dụng phần mềm.

Quy trình dự án về cơ bản gồm 6 bước trên, nhưng thực tế nó sẽ linh hoạt theo từng phương pháp
quản lý dự án (project management methodology).

Phương pháp quản lý dự án là những thứ như: Scrum/Agile, Waterfall, Kanban, Lean…

Ví dụ đối với Waterfall thì quy trình sẽ đi theo trình tự từ trái qua phải (không đi ngược lại), mỗi bước
chỉ đi qua 1 lần.

Cụ thể như analysis xong rồi, thì mới tới giai đoạn design, rồi xong design thì mới tới develop, tương tự
là test >> deploy >> maintain.

Tức mình phải đợi dự án chạy từ đầu tới cuối thì mới dòm được thành phẩm cuối cùng hình dạng nó
ra sao.

Còn đối với Scrum thì anh em sẽ chia nhỏ requirements ra thành các User Story, gom vào từng Sprint
Backlog để làm dần dần. Tức mình chia nhỏ ra thành từng cục để làm.

Vậy thì quy trình trên sẽ không đi từ đầu tới cuối 1 lần duy nhất, mà đi nhiều lần từ analysis -> deploy,
tạo thành nhiều sprint, nhiều vòng lặp. Mỗi vòng lặp sẽ làm một số tính năng nhất định, nên thời gian sẽ
được rút ngắn còn khoảng từ 2-4 tuần/ sprint.

Do đó, khách hàng sẽ thấy ngay được sản phẩm của mình thành hình dần dần, từ đó góp ý để cải thiện
sản phẩm ngày một phù hợp hơn với họ.

Mình nói đoạn này để anh em hiểu bản chất làm dự án phần mềm nó cũng chỉ gồm 6 bước thôi, dù cho
có làm Scrum hay Waterfall, hay bất cứ phương pháp nào.
(mặc dù ở mỗi phương pháp nó có 1 tí râu ria liên quan khác nhau, cái này mình sẽ nói sau nhé anh
em…)

Một điểm nữa là requirement sẽ đi xuyên suốt từ đầu đến cuối dự án thông qua 6 bước này. Là BA,
chúng ta cũng sẽ phải đi xuyên suốt từ đầu đến cuối dự án qua 6 bước này luôn.

Requirement xuyên suốt từ đầu đến cuối dự án

Giờ mình sẽ nói chi tiết về từng bước có trong dự án, và BA làm gì ở trỏng nhé anh em

Nội dung [Hide]

• 1. Analysis

o 1.1. Project Definition

o 1.2. Elicitation

o 1.3. Analysis

o 1.4. Documentation

o 1.5. Verification

o 1.6. Management

1. Analysis

Analysis là giai đoạn team dự án sẽ phân tích để hiểu được vấn đề của khách hàng và những gì mà họ
đang mong đợi.

Đối với BA, đây chính là giai đoạn lấy yêu cầu.

Anh em sẽ làm rất nhiều bước nhỏ trong bước Analysis này để lấy yêu cầu một cách bài bản nhất (chứ
không phải nói “lấy yêu cầu” là bay zô làm cái một, hỏi tùm lum tùm la là được)

Cụ thể Analysis gồm 6 bước nhỏ sau.

Thực chất mình chỉ cần focus vào 2 bước Elicitation và Analysis, vì các bước còn lại khá đơn giản, đều là
những bước hiển nhiên mình phải làm.

1.1. Project Definition

Mục đích của bước này là để anh em BA chúng ta hiểu được project. Hiểu được project này làm gì,
khách hàng là ai, lĩnh vực gì, vấn đề của họ ra sao, mục tiêu của họ là gì, scope dự án như thế nào…
Problem to be solved

Ví dụ như khách hàng đang dùng hệ thống SAP gặp lỗi nhiều quá, họ muốn build mới một hệ thống khác
chạy ngon hơn.

Hoặc họ đang không có hệ thống quản lý kho bãi, vẫn đang tốn tiền nhân công, hiệu suất thấp, và sai sót
vẫn còn xảy ra; thì đây chính là vấn đề họ cần giải quyết

Business Goal

Ví dụ họ muốn quản lý quan hệ khách hàng bằng một phần mềm nào đó. Hoặc triển khai thành công hạ
tầng IoT cho 5,000 hecta cà phê đang trồng chẳng hạn.

Business Case

Là những hiện trạng cụ thể của khách hàng. Ví dụ công ty con này mới thành lập được 5 năm, hoặc công
ty mới vừa bán hàng cho thị trường Châu Mỹ được gần 1 năm.

Project Scope

Phạm vi của dự án. Là BA, anh em cần phải hiểu rõ khoản này. Thường anh em sẽ chú ý tới:

• Organization Scope: ví dụ dự án được thực hiện tại Head Office ở Hồ Chí Minh, địa chỉ bao nhiêu
đó. Công ty con ở Đà Nẵng hay Hà Nội không được áp dụng.

• Users Scope: hệ thống có bao nhiêu người dùng, thuộc những bộ phận nào.

• Functional Scope: cái này quan trọng nhất – mô tả những chức năng của hệ thống mà khách
hàng mong muốn.

• Integration Scope: thực chất nó là 1 Non-Functional Requirement, nhưng được tách ra phần
riêng, mô tả phạm vi tích hợp: hiện tại khách hàng đang dùng những hệ thống gì, cần tích hợp
những components nào, tần suất ra sao, vâng vâng…

• Và cuối cùng là OUT OF SCOPE: anh em xác định trước những thứ sẽ nằm ngoài phạm vi dự án,
kiểu như rào trước vậy đó.

Project Plan

Anh em đã nắm được lịch dự án của PM hay chưa, có khó khăn về thời gian không, theo lịch thì có đoạn
nào cần gấp, dồn sức nhiều hay không… Và cuối cùng là.

Success Criteria

Cái này anh em có thể trao đổi với PM để hiểu hơn về dự án, về khách hàng: đâu là điểm họ kỳ vọng
nhất, làm họ happy nhất. Focus vào điểm đó, anh em sẽ dễ đóng dự án hơn rất nhiều!

Sau khi hiểu được tổng quan dự án, anh em sẽ bắt đầu vô bước MOI MÓC YÊU CẦU – Elicitation
1.2. Elicitation

Elicitation tức là moi móc thông tin, moi móc yêu cầu từ phía khách hàng. Moi móc nghĩa là nó không có
sẵn để anh em lấy, mà phải làm tùm lum tùm la mới ra được.

Sự khác biệt giữa Collect và Elicit.(Nguồn ảnh: ModernAnalyst.com)

Ở bước Elicitation, anh em cần nắm được các phương pháp moi móc thông tin. Phổ biến nhất có 11
phương pháp sau:

1. Meeting

2. Data Analysis

3. Interface Analysis

4. Prototyping

5. Business Rules Analysis

6. Observation

7. Bench Marking

8. Mind Mapping

9. Process Analysis and Modeling

10. Survey

11. Document Analysis

Sau khi nắm được 11 phương pháp, anh em sẽ đi vào quy trình Elicitation, gồm 4 bước nhỏ sau.
Mình có 2 bài note nói về nội dung này, anh em bấm vào link dưới tham khảo thêm nhé:

• 11 phương pháp moi móc yêu cầu

• 4 bước moi móc yêu cầu (như link trên)

• Những lưu ý khi lấy yêu cầu

Sau bước này anh em sẽ có output là thông tin, rất nhiều thông tin.

Trong mớ thông tin này, anh em có thể có luôn yêu cầu cụ thể, yêu cầu mơ hồ, câu trả lời từ phía khách
hàng; hoặc đơn giản chỉ là những thứ mà khách hàng nói với mình vì họ nghĩ những thông tin đó là cần
thiết.

1.3. Analysis

Sau khi anh em đã hiểu dự án (project definition) và moi móc được một mớ thông tin (elictation), giờ
anh em sẽ lấy mớ thông tin đó ra, và bắt đầu phân tích nó.

Thường thì mọi người không hiểu “phân tích” cụ thể sẽ làm những gì. Mình cũng vậy, cho đến khi mình
gặp 1 anh Manager đẹp chai mà mình rất hâm mộ. Ảnh nói rằng:

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

Hay Sandhya Jane (tác giả cuốn Business Analysis: The question and answer book) cũng có nói rằng:

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

Ngẫm đi ngẫm lại thì đúng là vậy anh em ạ.

Giám đốc ngân hàng yêu cầu phân tích xem: vì sao quý này nợ xấu lại tăng cao đến như vậy?

Lúc này bộ phận kinh doanh sẽ làm gì? Chẳng phải anh sếp kinh doanh ảnh sẽ yêu cầu đổ toàn bộ dữ liệu
các giao dịch cho vay trong khoảng thời gian phù hợp. Rồi phân loại rõ ràng theo các tham số: đối tượng
khách hàng, phân khúc sản phẩm, hạn mức, kỳ hạn trả, vâng vâng và vâng vâng…

Anh em có nhận ra anh sếp kinh doanh này đang làm gì không? Chính xác là ảnh đang sắp xếp & phân

loại mọi thứ cho ra ngô ra khoai

Để từ đó ảnh mới có thể làm tiếp công việc mà ảnh được trả hàng nghìn đô một tháng để làm, đó
là: nhìn số liệu >> tìm ra vấn đề >> và giải quyết.

Phân tích với BA cũng tương tự như vậy.

Khi khách hàng có vấn đề trong bộ máy hoạt động, họ sẽ tìm đến mình. Và sau một loạt các buổi elicit
requirement, chúng ta sẽ lấy được rất rất nhiều thông tin từ khách hàng (hoặc không).

Nhiệm vụ của anh em là phải xác định được: Đâu mới là vấn đề thực sự của khách hàng, và đâu mới là
cái họ cần nhất ngay lúc này.

Hãy tưởng tưởng từ một mớ hỗn độn thông tin lấy được, chúng ta sẽ rất khó để biết được:

• Đâu mới là vấn đề thực sự của họ

• Đâu là những yêu cầu thực tế

• Đâu là những yêu cầu tầm bậy tầm bạ

• Và đâu là những thứ khách hàng thực sự nên ưu tiên vào lúc này…

Bước Analysis sẽ giúp anh em làm rõ những điều trên. Cụ thể ở bước này anh em sẽ làm những thao tác
sau.
Theo trình tự, anh em sẽ:

(1) Organize

Tức là sắp xếp, tổ chức lại các requirement.

Ví dụ: tệp ảnh ra tệp ảnh, tệp ghi âm ra tệp ghi âm, thông tin về nhóm nghiệp vụ quản lý khách hàng
gom chung lại 1 chỗ, nghiệp vụ quản lý chất lượng gom chung lại 1 chỗ khác, ví dụ vậy. Để mình có cái
nhìn tổng quan nhất.

(2) Functional Decompose

Bước này anh em sẽ phân rã các yêu cầu thành các yêu cầu nhỏ hơn, cụ thể hơn. Mục đích là để có cái
nhìn thực tế nhất về tính khả thi của các yêu cầu này.

Ví dụ họ muốn hệ thống có khả năng nhắc nhở các buổi họp định kỳ với đối tác của khách hàng (*).

Vậy thì anh em sẽ phân rã ra, để làm được yêu cầu trên thì hệ thống phải có chỗ ghi nhận được các buổi
họp định kỳ đúng không anh em? Sau đó phải có một cái job nó chạy định kỳ, cứ trước 3 ngày diễn ra
cuộc họp là gửi email nhắc nhở.

Vậy thì sau khi phân rã (*), anh em sẽ có như sau:

• Tính năng lưu trữ thông tin cuộc họp

• Tính năng gửi email nhắc nhở dựa trên thời gian cuộc họp.

Để sau này khi ngồi lại với dev, anh em sẽ dễ dàng giải thích và cũng dễ để xác nhận với khách hàng hơn,
là: “à tụi em sẽ làm như vầy, như vầy nha chị…”. Kiểu vậy.

(3) Prioritize
Bước này là bước đánh số thứ tự ưu tiên cho từng yêu cầu cụ thể của khách hàng.

Ví dụ có 3 yêu cầu sau:

• Hệ thống phải lưu trữ được thông tin khách hàng (a)

• Hệ thống phải tự động thông báo những khách hàng đã mua hàng trên 5,000,000đ trong tháng
(b)

• Hệ thống phải tạo được đơn hàng với thông tin bảng giá lấy từ hệ thống quản lý bán lẻ A Á Ớ Bờ
Cờ (c)

Thì mình sẽ đánh giá mức độ ưu tiên của yêu cầu (b) thấp hơn yêu cầu (a) và (c). Vì phải có dữ liệu khách
hàng và đơn hàng thì mới có thể lọc được thông tin khách mua hàng trên 5 triệu trong tháng.

Anh em có thể tham khảo một vài tiêu chí phân loại Requirements dưới đây.

Tiếp theo là 2 bước Validate và Verify. 2 bước này đều là 2 bước xác nhận, nhưng nó khác nhau ở chỗ:

(4) Validate

Do the thing right

(5) Verify

Do the right thing

Nói về bước Analysis, anh em tham khảo thêm bài note này nhé, mình có nói chi tiết kèm ví dụ ở note
này: Hiểu về Requirement như thế lào cho đúng???
Sau 3 bước quan trọng đầu tiên: Project Definition >> Elicitation >> Analysis, anh em sẽ đi tiếp tới 3
bước cuối cùng.

Nãy giờ chúng ta đã đi được 3 bước này.

1.4. Documentation

Bước documentation nôm na nghĩa là anh em sẽ tài liệu hóa, tức là đem toàn bộ những thứ làm được
nãy giờ bỏ vô tài liệu.

Tài liệu đó chính là SRS, hoặc FRD, tùy loại dự án mà mình có những loại tài liệu khác nhau nhé anh em.
Nhưng mục đích chung thì vẫn là để mô tả chi tiết yêu cầu của khách hàng.

Để document thì anh em sẽ áp dụng 2 thứ sau:

1. Tận dụng các template có sẵn

2. Dùng ngôn ngữ mô hình hóa để document.

Ngôn ngữ mô hình hóa có khoảng 20 loại. Trong đó có 2 loại phổ biến nhất là BPMN và UML.

Template thì tùy công ty. Công ty của anh em dùng template gì thì anh em cứ dùng template đó thôi. Có
thời gian mình sẽ share về các template này sau nhé.

1.5. Verification
Sau khi document xong, anh em sẽ chuyển cho team verify lại một lần nữa. Cụ thể là QA hoặc PM.

Họ sẽ kiểm tra lại xem thử anh em đã document đúng chưa, đủ các phần yêu cầu chưa. Đặc biệt là PM
sẽ kiểm tra lại các yêu cầu của khách hàng đã được document chính xác và hợp lý hay chưa.

1.6. Management

Bước cuối cùng là management, tức là anh em sẽ quản lý các document sau khi đã xong xuôi. Quản lý ở
đây là quản lý gì?

Ví dụ nếu requirement thay đổi, tức nội dung của tài liệu SRS hoặc FRD thay đổi, thì anh em phải đánh
dấu version như thế nào, duyệt nội bộ rồi gửi cho khách hàng duyệt như thế nào.

Quản lý requirement sao cho dễ keep track cũng là một vấn đề khá nhức nhối :)) anh em nào có kinh
nghiệm share bên dưới cho mình nhé.

Stop station…

Dừng chân recall một chút về 6 bước nãy giờ nhé anh em. Mục đích mình làm bài bản 6 bước này là để
ra được 1 loại document mô tả chi tiết yêu cầu của khách hàng.

Như mình nói ở trên nó là SRS (Software Requirement Specification) hoặc FRD (Functional Requirement
Document). Và có thể là 1 số loại template khác nữa, tùy công ty.
Trong 6 bước này, anh em lấy bước Elicitation và Analysis làm trọng tâm. Vì hầu như các bộ kỹ năng
cứng của BA đều nằm ở đây hết.

Cái BA mình cần deliver được sau 2 bước này chính là REQUIREMENT. Nếu nhìn xuyên suốt qua cả 2
bước, anh em sẽ thấy requirement nó đi như sau:

Vậy là anh em đã đi xong giai đoạn Analysis trong quy trình làm dự án.

Quy trình dự án, BA làm gì ở trỏng? (P2)

Ở phần trước mình đã note lại giai đoạn đầu tiên là Analysis, gồm 6 bước nhỏ: Project Definition >>
Elicitation >> Analysis >> Documentation >> Verification >> Management.
Hi vọng anh em sẽ không cảm thấy khó hiểu khi đọc đến đây.

Sau bước Analysis này chúng ta đã có tài liệu mô tả yêu cầu, tức là đã biết được khách hàng cần gì. Giờ
BA và team dự án sẽ đi vào giai đoạn thiết kế hệ thống sao cho đáp ứng những yêu cầu này nhé anh

em

Nội dung [Hide]

• 2. Design

• 3. Develop

• 4. Test

o 4.1. Internal Testing

o 4.2. External Testing

• 5. Deploy

• 6. Maintain

2. Design

Ở bước này, tùy level, trách nhiệm, và loại dự án, mà BA sẽ tham gia vào ít hoặc nhiều.

Thực tế xảy ra là: hiếm khi BA ghi nhận các được yêu cầu một cách chi tiết ngay ở bước analysis. Nếu có
thì chỉ ở mức độ high level. Còn tiểu tiết như từng User Story thì rất khó.
Do đó thường thì ở giai đoạn này (và có thể là các giai đoạn sau), BA sẽ phải trao đổi thêm với khách
hàng để làm rõ các yêu cầu (những anh em nào đã kinh nghiệm, có khả năng clarify rõ ràng mọi thứ ngay
từ đầu thì những giai đoạn sau này sẽ đỡ hơn rất nhiều).

Chưa kể nếu dự án triển khai theo Agile thì yêu cầu thay đổi liên tục, đòi hỏi anh em phải quản lý các
requirement bài bản và làm việc với khách hàng nhiều về các yêu cầu thay đổi này.

Đó là phía mình, còn về phía khách hàng, nhiều khi họ còn chưa chắc về những yêu cầu họ đưa ra. Mà
business thay đổi thì là chuyện một sớm một chiều.

Nên đây là chuyện hết sức bình thường: Requirement sẽ luôn thay đổi không ít thì nhiều xuyên suốt
dự án. Đó là lý do vì sao mình vẽ đường //Requirement// màu xanh lá trên cùng chạy xuyên suốt dự án

đó anh em

Ở bước design, anh em sẽ can thiệp sâu một ít về kỹ thuật, bao gồm những thứ như:

• Thiết kế Database

• Vẽ Data Flow

• Vẽ Mockup

• Thiết kế UX/UI

• Thiết kế Business Process Flow

• Thiết kế bộ phân quyền hệ thống

• Vẽ Solution Architect
 • …

Nghe tùm lum tùm la nhưng những điểm trên không phải một mình BA thầu hết (may quá), mà phải có
sự can thiệp/ support của các anh em khác, có thể là Dev, Technical Architect, hoặc PM…

Và những thứ này sẽ linh động theo tùy loại dự án. Như những dự án triển khai thì sẽ không cần thiết kế
UX/UI hay vẽ mockup.

Tuy nhiên mình thấy trong các thứ trên, hầu như BA sẽ thầu hết 70%.

Solution Architect thì TA sẽ làm. Database thì BA làm cũng được, nhưng cần có sự review từ toàn team vì
nó sẽ ảnh hưởng đến những thứ trong tương lai. Còn về UX/UI thì có anh em designer làm chứ BA mình
không có chuyên môn để làm phần này (và thường thì cũng chẳng có BA nào đi design UX/UI cả – trừ khi
thiếu resources dữ lắm thôi).

Sau cùng cả team sẽ gom các kết quả lại để ra được thành phẩm cuối cùng là: Tài liệu thiết kế.

Để cho sang thì anh em hay gọi là SDD (Software Design Document) hoặc FDD (Functional Design
Document).

Ô kê, vậy là qua 2 giai đoạn (Analysis và Design), chúng ta đã có được 2 tài liệu quan trọng:

• Tài liệu mô tả yêu cầu (SRS/FRD)

• Tài liệu thiết kế (SDD/FDD)

Có hàng nóng trong tay, anh em developer sẽ bắt đầu HIỆN THỰC HÓA sản phẩm bằng cách viết những
dòng code đầu tiên.

3. Develop

Giai đoạn này anh em BA sẽ hỗ trợ Development Team trong quá trình build sản phẩm.

Ví dụ có Use Case nào chưa rõ, anh em sẽ giải thích để dev họ hiểu hơn về mục đích của Use Case. Hoặc
nếu anh em làm giai đoạn Analysis và Design không kỹ, thì giai đoạn Development sẽ lòi ra những lỗi
logic giữa các yêu cầu với nhau.

Ví dụ yêu cầu này conflict yêu cầu kia. Thì lúc này anh em BA phải làm việc lại với khách hàng để làm rõ
vấn đề, rồi update lại cho Development Team để anh em làm tiếp.
Sau khi Development Team build xong một hoặc nhiều tính năng nào đó, chúng ta sẽ phải test các tính
năng này.

4. Test

Giai đoạn test gồm 2 giai đoạn nhỏ: Internal Testing và External Testing.

4.1. Internal Testing

Internal Testing tức là nội bộ team dự án tự kiểm tra với nhau xem thử các tính năng đã được build
đúng chưa, trước khi release cho khách hàng.

Đây có thể là nhiệm vụ của BA, hoặc không.

Các Software Development Team luôn có vai trò QC. QC sẽ là người chịu trách nhiệm test các tính năng
vừa mới build này. Đảm bảo Dev làm đúng theo như tài liệu yêu cầu/ thiết kế, và đảm bảo team deliver
đúng như những gì đã cam kết với khách hàng.

QC sẽ viết các Test Case để kiểm tra từng tính năng một.

Còn đối với các dự án triển khai, Software Implementation Team thường sẽ không có QC. BA trong team
sẽ chịu trách nhiệm cho các phần test này luôn.

Vì so với những dự án build mới từ đầu, độ chính xác của các tính năng chuẩn trong các dự án triển
khai sẽ cao hơn rất nhiều.

Vì triển khai là triển khai những gì đã có sẵn. Những tính năng này đều do các hãng lớn build sẵn, nên
hầu như việc sai sót là không có.

BA trong các dự án triển khai chỉ cần test lại các tính năng “khác lạ so với chuẩn”. Tức là những tính năng
customized mà khách hàng yêu cầu. Chứ không cần test lại toàn bộ các tính năng từ nhỏ tới lớn mà dev
build như login, authorization, CRUD, import/export…
Ngoài Test Case ra, anh em BA cần phải chuẩn bị một thứ nguy hiểm hơn, đó là: Requirement
Traceability Matrix (RTM).

RTM cũng không có gì quá ghê gớm. Anh em chỉ cần lấy Test Cases map với Requirements là sẽ ra được
RTM.

Mục đích của Requirement Traceability Matrix là để anh em trace lại được là các Requirement đã được
test hay chưa, và test thành công hay thất bại. RTM sẽ giúp anh em control được “sức khỏe” của các
requirements xuyên suốt dự án.
4.2. External Testing

Sau khi team đã test nội bộ với nhau và chắc chắn rằng: “à những tính năng này đã được build đúng &
build đủ”. BA sẽ thực hiện các buổi User Acceptance Test (UAT) với khách hàng.

User Acceptance Test là buổi mà một vài key-users của khách hàng sẽ ngồi test lại hệ thống từ đầu đến
cuối, dựa trên Test Case mà khách hàng tự viết hoặc bên đối tác viết (cái lúc nãy).

Sau khi test xong, nếu có vấn đề gì thì anh em phải sửa lại và thực hiện UAT lại. Còn nếu mọi thứ ô tô kê

thì dự án sẽ qua bước tiếp theo: Deploy cho end-users sử dụng

5. Deploy

Đối với BA, anh em có thể hiểu Deploy nghĩa là mình sẽ làm tất cả những thứ để hệ thống sẵn sàng
được sử dụng. Những thứ đó có thể là:

• Build solution từ môi trường Dev lên môi trường Production.

• Migrate data: là chuyển toàn bộ data hiện tại của khách hàng từ hệ thống cũ sang hệ thống mới.

• Thiết lập người dùng như: phân quyền, cập nhật tài khoản, thông tin cá nhân…

• Hướng dẫn người dùng sử dụng hệ thống

• Và một số thứ râu ria khác tùy dự án, như: bật audit hệ thống, kích hoạt các batch job, hoặc
chuẩn bị Go-Live Checklist.
Ở bước này mình muốn highlight với anh em dòng “hướng dẫn người dùng sử dụng hệ thống” như
nhiệm vụ chính của BA trong giai đoạn này. Các phần còn lại, BA và anh em Developer sẽ cùng phối hợp
thực hiện.

Để training end-users, anh em sẽ cần có tài liệu hướng dẫn (User Manual). User Manual có thể có nhiều
dạng: tệp pdf, video, hoặc thậm chí là tài liệu prezi,… tùy nhu cầu và cách làm của mình.

Sau khi chuẩn bị xong User Manual, anh em sẽ tiến hành training cho end-users. Sau đó anh em sẽ làm
một danh sách các điểm cần chuẩn bị để tiến hành Go-live, gọi là Go-live Checklist.
Ví dụ về Go-live Checklist – những thứ anh em cần chuẩn bị trước khi Go-live

Xong, vậy là coi như anh em đã sẵn sàng để Go-Live, cột mốc quan trọng bậc nhất trong bất kỳ dự án

nào

Sau giai đoạn Deploy trước giai đoạn Maintain sẽ là cột mốc Go-live. Giả dụ anh em đã Go-live thành
công đi nhé, để mình qua giai đoạn tiếp theo :v

6. Maintain

Sau khi Go-live xong, tức là khách hàng đã thật sự sử dụng hệ thống, anh em sẽ vào giai đoạn cuối cùng
trong quy trình làm dự án phần mềm, đó là Maintenance – Bảo trì (hoặc cũng có thể là Warranty – Bảo
hành)

Thường thì các dự án mình làm sẽ bảo trì khoảng 1-3 tháng sau Go-live.

Bảo hành tức là mình sẽ hỗ trợ khách hàng, xem thử trong quá trình sử dụng họ có gặp vấn đề gì không,
bug chỗ nào để mình hỗ trợ giải quyết kịp thời.
Khi có lỗi phát sinh, khách hàng sẽ gửi lỗi này lên một trang portal để BA và anh em trong team biết mà
bay vô support. Hoặc đơn giản người Contact Point bên phía khách hàng sẽ tổng hợp các lỗi định kỳ
hàng tuần/ tháng và gửi email cho team dự án.

Trong giai đoạn này, các lỗi đều sẽ được log lại để theo dõi “vòng đời lỗi” (nghe hoành tráng quáaa). Tức
là lỗi từ lúc phát sinh đến lúc được giải quyết, ai là người phát hiện ra lỗi, thuộc phân hệ nào, nguyên
nhân ra sao, tình trạng thế nào, và thời gian ghi nhận.

Ngoài ra, nếu anh em có các hoạt động support khách hàng tại văn phòng của họ (onsite các kiểu) hoặc
online meeting, thì anh em sẽ phải làm những Activity Sheet, ghi nhận những hoạt động đó, để 2 bên có
thể dễ dàng quản lý, đặc biệt trong trường hợp có chi phí phát sinh.

Ô kêêê anh em đã thấy mệt chưa. Vậy là coi như chúng ta đã đi xong một quy trình làm dự án!

Cùng nhìn lại những thứ mà BA sẽ deliver xuyên suốt dự án nhé anh em.
Mình nhắc lại là tùy kiểu quản lý dự án (project management methodology) mà quy trình trên sẽ thay
đổi, nhưng về bản chất nó sẽ luôn bao gồm 6 giai đoạn trên, và công việc BA cũng sẽ không khác gì mấy
trong 6 giai đoạn này.

Kết bài

Hi vọng qua bài này anh em sẽ thật sự hiểu rõ về nghề BA, về Business Analyst.

Đây 100% là các công việc BA sẽ làm trong các công ty outsource hoặc service. Còn đối với các công ty
client, BA sẽ làm hơi khác một chút, nhưng cơ bản thì vai trò của BA trong công ty nào cũng giống nhau

hết

V. BA và lộ trình nghề nghiệp

Nguồn ảnh: Trak Search

Hế lô anh em,

Đã bao giờ anh em tự hỏi: “Mình sẽ làm BA đến bao giờ???”

Mình là Junior, làm 1-2 năm bỏ được chữ Junior, thành BA. Thêm 3-4 năm nữa mình sẽ lên Senior. Rồi
sao nữa???

PM là một sự lựa chọn phổ biến. Vậy thì ngoài PM ra, còn con đường nào khác cho BA hay không?

Câu trả lời là có. Nhưng sẽ có đôi chút hơi ngược với những gì anh em đã và đang nghĩ: “BA giỏi thì
không nên, không nên làm PM…”

Do đó bài viết hôm nay sẽ về một chủ đề mình nghĩ rất nhiều anh em quan tâm, đó là chuyện: lộ trình
nghề nghiệp cho BA. Hay nói cách khác: anh em BA mình có những nấc thang nào để leo trong suốt sự
nghiệp.
Và mình sẽ giải thích luôn chuyện: vì sao BA giỏi không nên làm PM

Nội dung [Hide]

• 1. Tổng quan

o 1.1. Junior BA và BA

▪ a) Fresher BA/Junior BA/ Associate BA

▪ b) Tháo mác Junior

o 1.2. Senior BA

▪ a) Hiểu chuyên sâu về một lĩnh vực

▪ b) Giải quyết nhiều bài toán chuối hơn

▪ c) Làm planning và scoping nhiều hơn

▪ d) Tập trung vào business, không phải software

▪ e) Business Domain mới cũng không thành vấn đề

▪ f) Leadership task

o 1.3. BA Leadership

o 1.4. Management Consultant

o 1.5. C-Level/ Entrepreneur

• 2. Vì sao BA giỏi không nên làm Project Manager?

• 3. Tạm kết

1. Tổng quan

Đầu tiên mình sẽ nói đôi chút về career path mà IIBA đưa ra.
Như anh em thấy, hình đầu tiên khá đơn giản. Rõ ràng là BA có thể đến từ nhiều đối tượng, nhiều yêu
cầu kinh nghiệm khác nhau. Nhưng chung quy lại, anh em sẽ có 6 role cơ bản khi làm BA.

Sau một thời gian làm các role trên, anh em sẽ bước sang trang mới: Senior BA.

Ở hình thứ 2, IIBA phân cấp độ BA 100% dựa vào bằng cấp do chính IIBA quy định. Chuyện bằng cấp cho
BA như mình có chia sẻ, thực sự cần hay không phụ thuộc nhiều vào thị trường mình đang làm.

Riêng chuyện bằng cấp này mà áp dụng ở Việt Nam thì mình thấy có vẻ CHƯA hợp lý lắm. Do đó theo
những gì mình biết và tham khảo, lộ trình nghề nghiệp của BA sẽ được chia lại thành những cánh cửa
sau.
1.1. Junior BA và BA

a) Fresher BA/Junior BA/ Associate BA

Đầu tiên sẽ là Junior BA và BA.

Ai cũng vậy, mới vào nghề chúng ta sẽ bắt đầu với title Junior. Một vài công ty họ sẽ gọi là Associate BA.

Ở vị trí này, anh em chủ yếu là hỗ trợ và theo học các anh chị đại là chủ yếu, bên cạnh một số task làm
document đơn giản. Anh em sẽ được tiếp cận cách làm dự án, cách làm document, được giới thiếu cái
này cái kia, hệ thống này hệ thống kia, tool này tool kia.

Nói chung ở giai đoạn này anh em sẽ được train ngập mặt.

Hãy tranh thủ học hỏi, ham muốn học hỏi và tận dụng cơ hội trải nghiệm thực tế nhiều nhất có thể nhé

anh em

Đối với Junior BA, công ty đa quốc gia với quy trình rõ ràng và benefit thuộc hàng khủng có thể là một sự
lựa chọn tốt khi mới bắt đầu.

Còn nếu làm start-up, anh em hãy luôn nhớ mình đang làm gì và muốn học gì, tránh lạc lối và tốn thời
gian vô ích, mặc dù anh em được làm rất nhiều.

Giai đoạn này quan trọng nhất là ở anh síp đẹp chai. Mindset mới vào nghề của mình sẽ bị ảnh hưởng
cực nhiều bởi người sếp đầu tiên này.

b) Tháo mác Junior

Một năm sau, hoặc cũng có thể nhiều hơn 1 năm, anh em sẽ được giao nhiều task khác, xịn sò hơn.
Những task đòi hỏi này anh em phải chiến độc lập, một mình một ngựa chứ không còn người theo kèm
như trước nữa.

Đó là khi anh em đã tháo được mác “Junior”. Trở thành một Business Analyst độc lập, tự tin, bản lĩnh và
có ích hơn cho công ty, gia đình và xã hội…

Ở vai trò này, anh em sẽ chủ động hơn trong những task được giao. Đảm bảo hoàn thành đúng deadline
và chất lượng, mà không cần ai nhắc nhở hay cầm tay chỉ việc.

BA có thể tham gia dự án cùng với 1-2 BA khác. Lúc này, anh em đã có thể tự elicit yêu cầu, phân tích nó
và document lại cho hợp lý.

Ở giai đoạn này, anh em cần phải nắm thật kỹ và vận dụng thật tốt các kiến thức
về elicitation, analysis và document. Vì đó chính là các đầu mục công việc mà BA làm nhiều nhất.

Nói về document, sẽ có các phương pháp modeling anh em phải nắm được, tiêu biểu là BPMN và UML.

Ngoài ra, các tài liệu cơ bản trong dự án gồm những gì, dự án triển khai như thế nào, các bước ra sao?
Anh em cũng phải hiểu được, để hỗ trợ PM kịp thời.

Một trong những điều vô cùng thực tế mà mình thấy là: một khi đã lên level BA, thì sự chủ
động và quản lý thời gian là cực kỳ quan trọng.

Đây là giai đoạn để anh em thể hiện, để show up bản thân và chứng minh năng lực. Sẽ có rất nhiều task
đổ về cho anh em.

Nguyên tắc 1: Cố gắng làm và làm hết sức, cơ hội là ở chỗ này.

Task chính có, task “xịn” có (làm task với những nhân vật khủng, mà ở đó mình học hỏi được nhiều). Và
đặc biệt, những “task support” cũng không phải ít.

Vấn đề phát sinh: task quá trời, làm sao cho hết?!?

Nguyên tắc 2: “Say no” đúng lúc.

Khi gặp nhiều task, anh em hãy cố gắng làm, tìm mọi cách để sắp xếp thời gian, và làm.

Tốn công sức không? Quá tốn. Nhưng học được gì không? Học rất nhiều.

Có những thứ lúc làm chỉ muốn chửi thề. Nhưng sau này đống công sức đó chuyển hóa thành kinh
nghiệm thì mới thấy quý giá.

Tuy nhiên khi gặp quá nhiều task support, anh em hãy say no đúng lúc. Work Hard chỉ là điều kiện cần,
Work Smart mới là điều kiện đủ. Điều này giúp anh em hạn chế được mấy đồng chí hay “nhờ vả trơ
trẽn”, và giúp mình focus vào chuyên môn tốt hơn.

Sau một thời gian cày bừa vất vả, tham gia 1-2 dự án êm xuôi trót lọt (nghe cứ như buôn lậu), anh em sẽ

chuyển sang nấc thang tiếp theo: SENIOR BUSINESS ANALYST

1.2. Senior BA

Khi đã lên tới nấc thang này, anh em sẽ ở một tư thế hoàn toàn khác. Mọi thứ sẽ dần trở nên khó hơn,
rát hơn và cần nhiều nỗ lực hơn từ chính bản thân mình.

Một khi đã vượt qua được vùng thoải mái, anh em sẽ nhận ra được: à, bản thân mình đã phát triển hơn
rất nhiều.

Trở thành Senior BA, anh em sẽ được hưởng một mức lương cao hơn. Và dĩ nhiên, phạm vi công việc
cũng sẽ được mở rộng hơn và chuyên sâu hơn rất nhiều so với thời làm BA.

a) Hiểu chuyên sâu về một lĩnh vực

Anh em sẽ được yêu cầu nắm thật kỹ một lĩnh vực hoặc kiến thức chuyên môn trong một ngành nghề
nào đó.

Ví dụ có người thì rành về CRM, có người thì rành về ERP. Có người thì chuyên về nghiệp vụ kế toán,
nghiệp vụ kho bãi, supply chain… Hoặc thậm chí có người chuyên về các dự án upgrade, migrate data
hoặc chuyên về lĩnh vực nhất định như Banking, Finance, Healthcare, Retail… vâng vâng và vâng vâng.

Khi khách hàng gõ cửa, anh em sẽ cùng Tech Lead là người đầu tiên đề xuất solution cho khách hàng. Vì
mình đã hiểu rõ bài toán của họ, đặc thù của họ có những gì, và quan trọng nhất là thấy được pain point
mà khách hàng đang gặp phải.

Đây là hướng đi theo chiều dọc, chuyên sâu vào một lĩnh vực nhất định. Chứ không phải đi theo chiều
ngang, vừa làm vừa xem xét có phù hợp với mình hay không nữa.

Đây là một điểm mình nghĩ cực kỳ quan trọng. Nó cũng sẽ quyết định anh em lên Senior nhanh hay
chậm. Và con đường tiếp theo sẽ như thế nào.

b) Giải quyết nhiều bài toán chuối hơn

Những bài toán đặc thù thì đã có anh em BA lo. Còn đối với Senior BA, chúng ta sẽ giải quyết những thứ
rắc rối hơn, phức tạp hơn và cần nhiều bên tham gia hơn rất nhiều.

Tuy nhiên theo mình thấy, độ rắc rối và phức tạp đa phần đến từ yếu tố… con người. Thậm chí, chính
yếu tố con người đến từ phía nội bộ mình, chứ không phải từ phía khách hàng.

Bài toán khách hàng đưa, dù có phức tạp đến đâu, cũng đều có cách giải quyết. Đó là điều chắc
chắn. Nothing is impossible!

Nhưng team nhà tự bóp nhau thì cái đó mới mệt Vì quá nhiều bên tham gia, nên không control
được mục đích thảo luận, bên nào cũng có cái lý của họ, và “n” vấn đề khác nữa.

Những điều phức tạp nhất đều do con người tự gây ra, và chính họ là người tự giải quyết với

nhau
Do đó ngay từ bây giờ, anh em hãy chăm thật kỹ people skills để sau này đỡ vất vả nhóe.

c) Làm planning và scoping nhiều hơn

Thường thì BA sẽ không làm những vấn đề này, mà làm những task liên quan chi tiết đến từng user
story, từng feature cụ thể.

Senior BA sẽ cùng PM chịu trách nhiệm cho việc planning và scoping cho dự án. Đó đa phần là những
công việc ngay từ đầu dự án, trong giai đoạn bidding hoặc sales.

Senior BA phải làm luôn câu chuyện pre-sales. Ở vai trò này, anh em sẽ được làm nhiều hơn về solution
ở mức độ high level.

Cụ thể, anh em sẽ cùng PM, Sales, và Tech Lead đề xuất solution. Trong quá trình pre-sales, anh em sẽ
làm như thứ như: POC (Proof Of Concept – chuẩn bị demo giải pháp), chuẩn bị proposal, và sẽ facing với
khách hàng ngay giai đoạn đầu để trình bày giải pháp.

d) Tập trung vào business, không phải software

Đây là yếu tố thứ 2 (bên cạnh việc hiểu sâu về 1 lĩnh vực) có thể giúp anh em leo lên vị trí Senior nhanh
hơn bất kể người nào khác.

Có một phần không nhỏ những anh em Developer chuyển sang làm BA. Do đó, mindset của mình ít
nhiều vẫn còn xoay quanh software, lấy software làm chủ đạo, để giải quyết vấn đề.

Từ đó, kéo theo hiện trạng BA tập trung nhiều vào chuyện “software change”, hơn là “business change”.
Cán cân bắt đầu hơi nghiêng về phía kỹ thuật.

Những người này thường có thiên hướng trả lời vanh vách những gì software có thể làm được, cũng
như những hạn chế của công nghệ. Nhưng dùng nó như thế nào cho khớp với business ở hiện tại và có
thể linh hoạt thay đổi trong tương lai thì không phải ai cũng có khả năng.

Ở vai trò Senior BA, anh em không thể để cán cân lệch về phía kỹ thuật từ đầu đến cuối dự án như vậy.

Vấn đề là chúng ta phải tập trung vào business. Vào những thay đổi của khách hàng. Chứ không phải cứ
khư khư vào requirement change, software change như thế nào.

Và quan trọng nhất là phải hiểu được insight của họ: tại sao họ thay đổi, tại sao họ làm thế này, thế
kia… Thì khi đó, chúng ta mới build được relationship với các stakeholder.

Từ đó hiểu họ, và hai bên mới thật sự, thật sự hỗ trợ nhau nhiều hơn, dự án đi đến đích nhanh hơn; chứ
đừng bao giờ làm ngược lại.
Nguồn ảnh: ModernAnalyst.com

e) Business Domain mới cũng không thành vấn đề

Khả năng học hỏi nhanh là một yếu tố không nhỏ ảnh hưởng đến yêu cầu này. Tuy nhiên còn một thứ
cũng quan trọng không kém mà mình học được từ anh sếp của mình, đó là các “pattern”.

Pattern tức là các khuôn mẫu. Pattern thuộc về bản chất của vấn đề.

Ví dụ…

Dù nhà cao cửa đẹp hay thiết kế có cầu kỳ đến mức nào đi chăng nữa, thì pattern xây nhà cũng chỉ gồm
4 mục chính: xây hầm, làm mống, dựng nhà và làm mái.

(Mình kể ví dụ thôi, lỡ chém có sai thì 500 anh em kiến trúc xây dựng bỏ qua cho, kaka)

BA CŨNG VẬY.

Dù business đó có làm dịch vụ, sản xuất, hay một model nào đó mới đi chăng nữa, thì nó cũng đều có
những pattern nhất định.
Vậy câu hỏi đặt ra: Pattern từ đâu mà có?

Câu trả lời: Pattern đến từ 2 thứ:

• Kinh nghiệm

• Kiến thức học được

Cả cuộc đời anh em xây 15 cái nhà, thì anh em sẽ đúc kết được pattern các bước xây nhà, mà nhà-nào-
cũng-phải-có.

Tương tự, anh em làm 50 cái dự án phần mềm cho mảng dịch vụ, thì anh em sẽ đúc kết được những thứ
không thể thiếu trong quản lý dịch vụ. Làm 30 cái dự án cho mảng Logistic, thì sẽ đúc kết được những
thứ không thể thiếu của mảng này.

Sau này, dù business có mới đến cỡ nào đi chăng nữa, thì chắc chắn một điều rằng: NÓ VẪN SẼ ĐI THEO
CÁC PATTERN MÀ THÔI.

Một điều hay ho nữa là: các pattern này có thể học được từ việc đọc sách. Do đó…

f) Leadership task

Cuối cùng là các task liên quan đến con người. Là một Senior BA, anh em sẽ chịu trách nhiệm mentor
cho 1-2 bạn Junior.

Quay lại thuở xa xưa, khi mình còn là Junior, còn cần các anh lớn cầm tay chỉ việc. Còn giờ thì mình đã là
các anh lớn, thì đương nhiên phải chỉ giáo lại cho lớp kế cận đàn em thân yêu. Để sau này còn có đứa nó

hầu hạ, à nhầm, còn có đứa nó hỗ trợ mình này nọ

Ngoài ra, nếu trong cùng một dự án có nhiều BA, anh em sẽ chịu trách nhiệm lead team BA này, dẫn dắn
anh em đi đến cuối con đường, nơi ánh sáng đang loe loét chợp tắt gần cuối đường hầm :))

1.3. BA Leadership

Sau một thời gian tác chiến ở vị trí Senior BA, anh em sẽ có cơ hội bước lên thêm 1 nấc thang mới.

Nếu anh em thích làm việc với con người, BA Leadership rõ ràng là một cánh cửa phù hợp BA
Leadership gồm 1 số vị trí như:

• BA Project Lead

• BA Program Lead

• BA Practice Lead

• BA Manager
Project hay Program gì thì tùy công ty, tùy mô hình hoặc thậm chí là tùy tên gọi ở mỗi chỗ mỗi khác
nhau. Anh em sẽ lead các anh em BA còn lại trong dự án.

Còn BA Practice Lead anh em có thể hiểu nôm na là người chịu trách nhiệm cho các hoạt động của BA
được trơn tru, hiệu quả. Từ các framework làm việc, processes, đến các tools; hoặc thậm chí là quản lý
luôn competency của các anh em BA trong team.

Còn BA Manager thì phạm vi rộng hơn rất nhiều.

Ngoài những việc trên, thì BA Manager phải kiêm luôn việc resrouces planning (tuyển người, dùng
người), training, cho tới quản lý ngân sách department hay co-working một cách hiệu quả với các bộ
phận khác trong công ty.

Nên nhớ, nhánh BA Leadership này hoàn toàn khác với Project Manager nhé anh em. Nhánh PM lát nữa
mình sẽ nói sau.

1.4. Management Consultant

Một nhánh khác sau level Senior mà anh em có thể cân nhắc là trở thành một Management
Consultant thực thụ.

Cái tên nói lên tất cả, ở level này, anh em chỉ làm TƯ VẤN là chủ yếu.

Sẽ có các công ty chuyên rộng cửa chào đón những Consultant chuyên nghiệp như: Big Four (Deloitte,
EY, KPMG, PwC), hoặc McKinsey, hoặc IBM, thậm chí là làm ở các hãng như Microsoft, SAP hay Oracle.

Ở vai trò này, anh em sẽ không phải làm tiểu tiết như thời Senior BA hay BA nữa. Công việc chính của
anh em là đi gặp khách hàng, mà khách hàng ở đây đa phần là các C-Level từ các công ty, tập đoàn lớn.
Và phạm vi khách hàng không chỉ trong nước, mà là cả khu vực, như Europe, Asia Pacific…

Một điều mà ai cũng có thể thấy là làm Management Consultant rất sướng: lương không dưới 5000$/
tháng (ở Việt Nam), công tác khắp các nước, được gặp gỡ những nhân vật khủng, abc, xyz…

Và dĩ nhiên đằng sau đó là những khó khăn và lớp “behind the scene” ít ai thấy để leo lên được vị trí này.

Khối kiến thức và kinh nghiệm được đòi hỏi ở đây phải nói là đồ sộ. Tích lũy 7-10 năm kinh nghiệm từ vị
trí Senior BA, anh em sẽ có đủ điều kiện cần để bước lên nấc thang Management Consultant này.

Nhưng chỉ mới là “điều kiện cần”. Điều kiện đủ là 1 vài yếu tố liên quan như: thị trường, may mắn, nỗ
lực của bản thân, vâng vâng…

Ngoài Management Consultant ra, cũng sẽ có 1 vài vị trí khác ở level tương đương như:

• Enterprise Architect

• Business Architect

• IT Business Parter
Những vị trí này mình sẽ nói chi tiết hơn ở bài sau nhé anh em.

1.5. C-Level/ Entrepreneur

Sau một thời gian dài trải nghiệm vị trí BA với nhiều level khác nhau, từ Junior, đến BA, đến Senior, lên
cả BA Leadership hay Management Consultant. Đã đến lúc anh em chạm tới nấc thang có thể nói là cao

nhất của một người làm công việc BA

Đó là C-Level hoặc Entrepreneur.

C-Level là gì?

Sẽ có nhiều “vị trí C” khác nhau yêu cầu mảng kỹ năng của BA, như:

• CIO – Chief Information Officer

• CTO – Chief Technology Officer.

• Hoặc COO – Chief Operating Officer

Rõ ràng những level này đòi hỏi anh em cần tích lũy nhiều “sẹo” hơn nữa, vì hầu như nó là một thế giới
mới, với phạm vi công việc rộng hơn rất nhiều.

Các vị trí này hầu như chỉ xuất hiện ở các công ty Client, tức trong môi trường end-user.

Còn Entrepreneur là gì?

Đơn giản, anh em có thể hiểu Entrepreneur là khi chúng ta ra làm riêng, bắt đầu một mô hình kinh
doanh của riêng mình. Mấu chốt ở đây là anh em phải có một cái gì đó đặc thù riêng của mình trên thị
trường. Đó là thế mạnh của mình.

Một trong những điểm quan trọng nhất của BA là hiểu rõ về một số domain knowledge nhất định và có
các solution đặc thù về nó.

Nếu ngay từ đầu anh em đi theo ngách, tập trung phát triển một mảng kiến thức – kỹ năng về một
domain knowledge nhất định, thì trong tương lai nó sẽ giúp ích cho anh em rất nhiều.

Cái này mình chỉ mới tham khảo và quan sát chứ chưa thực tế nên không dám nói nhiều nhé anh

em

2. Vì sao BA giỏi không nên làm Project Manager?

Ý này có thể làm anh em hơi ngạc nhiên, vì trước giờ ai cũng nghĩ: một khi đã làm BA, thì phải làm PM.
PM như một bước phát triển trong nghề BA.

Nhưng nếu chiêm nghiệm lại một cách thực tế thì rõ ràng anh em cũng thấy BA và PM nó không có ăn
nhậu với nhau gì nhiều hết.
Rõ ràng có một số thứ khác biệt lớn như sau:

• BA tập trung vào giá trị của giải pháp mang lại, tức tập trung vào Business.
Còn PM thì tập trung vào Project.

• BA tập trung vào giá trị mà project mang lại.

Còn PM thì tập trung vào việc thực thi project sao cho hiệu quả.

Ngoài ra, xét về kỹ năng yêu cầu thì bộ kỹ năng của BA cũng khác biệt so với PM.

• BA tập trung vào kỹ năng elicitation, analysis, requirement management, và sau cùng vẫn là xoay
quanh solution.

• Còn PM tập trung vào kỹ năng quản lý scope, time, budget của dự án, các hoạt động QA, cũng
như các thủ tục liên quan đến dự án.

Kỹ năng yêu cầu khác nhau, phạm vi công việc cũng khác nhau, dẫn đến mind-set cũng bị ảnh hưởng
theo.

Có một clip rất hay trên Youtube của Yasith Abeynayaka (CBAP) mà mình được truyền cảm hứng rất
nhiều. Clip nói về chủ đề tại sao một BA giỏi không nên làm PM.

https://youtu.be/6QgaXr_VHJo

Có một câu rất hay trong clip, đó là:

If you really, really good at something, why move sideways? Move forward!

Tuy lý thuyết là vậy nhưng ở Việt Nam việc BA chuyển sang làm PM diễn ra khá nhiều. Mà điều này cũng
chả có gì sai cả. Vấn đề vẫn nằm ở chính bản thân mình thôi.

Nếu anh em vẫn còn thích làm giải pháp thì phát triển tiếp con đường BA với nhánh BA Leadership hoặc
Management Consultant thì khá phù hợp. Và ngược lại, việc trở thành PM có thể mang lại một trải
nghiệm mới về các quản lý cũng như vận hành dự án sao cho hiệu quả.

3. Tạm kết

Trên là những tóm lược sơ bộ về lộ trình nghề nghiệp của BA mà anh em có thể tham khảo. Hi vọng note
này có ích với anh em.

À tuy nhiên còn một hướng đi (mà theo mình thấy cực kỳ, cực kỳ thú vị), đó là focus vào hẳn một “digital
product”, và trở thành một Product Manager.

Mình tin đây là một trong những hướng đi “sát sườn nhất” và thể hiện được giá trị nhất của người làm
công việc BA (bên cạnh những hướng đi bên trên). Đây là một chủ đề rất hay, mình sẽ đàm đạo với anh
em sau nhé!

VI. Sơ lược về requirement

Hello anh em. Lần này mình sẽ note về các loại requirement mà anh em sẽ gặp trong suốt chặng hành

trình của một BA chuyên nghiệp

Lét xờ gâu anh em eiii!

Nội dung [Hide]

• 1. Requirement là gì?

• 2. Loại 1: Business Requirement

• 3. Loại 2: Stakeholder Requirement

• 4. Loại 3: Solution Requirement

o 4.1. Functional Requirement

o 4.2. Non-Functional Requirement

• 5. Loại 4: Transition Requirement

• 6. Tạm kết

1. Requirement là gì?

Đầu tiên mình sẽ lật ngược lại BABOK để xem Requirement được định nghĩa như thế nào.

Requirement is a usable representation of a need

BABOK v3.0

Usable tức là khả năng dùng được cho một mục đích nào đó.
Representation nghĩa là sự mô tả, sự diễn đạt.
Còn Need đơn giản là nhu cầu.

Nôm na, Requirement là sự diễn đạt cho một nhu cầu nào đó, nhưng sự diễn đạt này phải rõ ràng nhé
anh em, để còn được sử dụng cho nhiều mục đích sau đó, như để làm document, cho các stakeholders
đọc hiểu chẳng hạn.

Thực tế là không phải anh em nào trong team nào cũng hiểu rõ bản chất của chữ “Requirement”. Nhiều
góc nhìn khác nhau là tốt, nhưng khi teamwork mà không cùng nhìn chung một hướng thì dễ tèo lắm.

Tuy nhiên, đó cũng chỉ là lý thuyết để anh em BA nắm một cách chính xác.

Thực tế thì hầu như 96,69% những gì mà khách hàng nói đều chính là Requirement. Và đều thể hiện
được một “usable representation of a need” như mình nói ở trên.

Ví dụ,
Ông CEO đi workshop bên châu Âu, thấy nhà máy người ta áp dụng IoT thứ dữ quá, ghê quá, hiệu quả
quá. Về mới họp ban điều hành lại và nói rằng:

“Ô kê, tui muốn triển khai IoT cho nhà máy chúng ta, nó sẽ cắt giảm 40% chi phí nhân công và tăng 25%
hiệu suất quản lý, anh em thấy thế nào”.

Một câu phát biểu rất đại khái, chung chung như vầy chính là requirement. Vì đơn giản nhu cầu của ổng
đã rõ ràng, là muốn cắt giảm phí nhân công, tăng hiệu suất, với sự diễn đạt là muốn áp dụng IoT vào
hoạt động của nhà máy.

Từ yêu cầu trên của CEO, ông Giám Đốc Mua Hàng mới bắt đầu liên hệ công ty Bosch để yêu cầu về giải
pháp IoT.

Khi gặp team Bosch, ông Giám Đốc Mua Hàng mới phát biểu:

“Nè nha, tụi tui muốn triển khai IoT, mà phải xong trong vòng 2 năm rưỡi, ưu tiên trước mắt là Smart
Metering và Asset Management, các module khác để sau cũng được…”

So với câu phát biểu của anh CEO thì câu này của anh Procurement Director có vẻ chi tiết hơn chút xíu.

Ảnh diễn đạt rõ ảnh cần gì trước, cần gì sau, cho một mục đích cụ thể nào đó (có thể là để đạt target của
công ty trong vòng 5 năm tới…).

Dựa vào đó, yêu cầu cứ được dưa dần xuống các bộ phận trực tiếp làm việc, a usable representation of
a need cứ thế sẽ được phát biểu rõ ràng và chi tiết hơn nữa.

Ví dụ các yêu cầu sẽ chi tiết đến mức như:

• Phần mềm quản lý phải được viết bằng .NET 4.5

• Toàn bộ Sensors và Actuators (cảm biến & thiết bị truyền động) phải do Bosch sản xuất và cung
cấp.

• Report được render không quá 3 giây.

• Phải có ít nhất 2 tuần đào tạo sử dụng cho người dùng là nhân công nhà máy.

• …

Anh em thấy những ví dụ trên đều là những requirement, nhưng với cấp độ chi tiết khác nhau.

Nếu cùng gom nó lại và để chung vô một document thì sẽ rất… rối vô đối. Vì những requirement này có
thể sẽ overlap lên nhau, khó theo dõi được cho cả BA lẫn khách hàng.

Do đó, IIBA mới chia nồi lẩu thập cẩm requirements ra thành 4 loại để anh em dễ quản lý. 4 loại đó được

chia theo vòng tròn công việc của BA như sau.

2. Loại 1: Business Requirement

Business Requirement là những yêu cầu rất high-level từ phía khách hàng.

High-level nghĩa là nó rất TỔNG QUÁT, và thể hiện được mục tiêu của tổ chức. Một số dấu hiệu nhận
biết đó là Business Requirement:

• Thường là các mục tiêu dài hạn của tổ chức

• Được áp dụng cho toàn tổ chức đó

• Và thường được các nhân vật chủ chốt phát biểu, như các nhân vật C-Level, hoặc các
Manager,…

Đó là nói theo kiểu bình dân – dễ hiểu. Còn nói theo kiểu pho mồ như BABOK thì Business Requirement
nghĩa là:

Business Requirement is statements of goals, objectives, and outcomes that describe why a change has
been initiated.

They can apply to the whole of an enterprise, a business area, or a specific initiative.

BABOK v3.0

Một số ví dụ về Business Requirement để anh em dễ hình dung:

• Áp dụng thành công hệ thống IoT cho nhà máy Hà Nam, Bình Dương và Bắc Ninh trước
Q3/2025.

• Giảm 50% tỉ lệ sai sót trong quá trình xử lý đơn hàng trước Q4/2019.
 • Tăng 10% tỉ lệ khách quay lại mua hàng trong vòng 6 tháng áp dụng giải pháp CRM.

3. Loại 2: Stakeholder Requirement

Cái tên cũng khá rõ ràng, Stakeholder Requirement là những yêu cầu cụ thể của từng đối tượng
Stakeholder. Những yêu cầu này phải thể hiện được cái need – nhu cầu cụ thể của các Stakeholder.

Anh em hãy chú ý đến các SME – Subject Matter Expert, đặc biệt là các Domain SME.

Vì các stakeholder này họ sẽ đưa ra requirement là những thứ, mà họ sẽ tương tác với hệ thống, dựa
trên vai trò cụ thể của họ trong tổ chức.

Ví dụ anh em làm hệ thống quản lý nội bộ cho một công ty du lịch cỡ bự như Expedia đi chẳng hạn.
Những Domain SME có thể anh em cần chú ý là Giám đốc chăm sóc khách hàng, Giám đốc nhân sự,
Trưởng bộ phận điều phối tour…

Từ đó, chúng ta có một số ví dụ cho Stakeholder Requirement:

• From HR Director: Hệ thống phải tuân thủ đúng bộ policy của Expedia, bao gồm quy trình tuyển
dụng phải qua 5 vòng, lương nhân viên phải được cập nhật 2 lần mỗi năm, hay hệ thống phải có
chế độ tự động gia hạn hợp đồng lao động dựa trên những tùy chỉnh trước đó.

• From Customer Service Director: Hệ thống phải theo dõi được mức độ tương tác của Expedia với
khách hàng, và cho ra số liệu cụ thể theo đúng form mẫu mà Expedia đang theo dõi hằng ngày
bằng Excel.

• From Tour Coordinator: Quy trình điều phối tour trên hệ thống sẽ không fix cố định, mà người
dùng có thể tùy chỉnh linh động vì nhu cầu thực tế thay đổi rất nhiều theo thời vụ.

• Hoặc đơn giản hơn, IT Manager nói rằng: Nhân viên kinh doanh phải quản lý và xem được lịch sử
Booking ngay trên hệ thống.

• Hoặc Sales Director nói rằng: Nhân viên kinh doanh phải dễ dàng kiểm tra được số tiền khách
hàng đã chi ra trong tháng/ quý/ hoặc trong khoảng thời gian nhất định.

BABOK định nghĩa Stakeholder Requirement như sau:

Stakeholder requirements describe the needs of stakeholders that must be met in order to achieve the
business requirements.

BABOK v3.0

Business Requirement và Stakeholder Requirement phải rất ăn rơ và bổ trợ cho nhau. Theo nguyên
tắc: Business Requirement chỉ đạt được khi Stakeholder Requirement đã đạt được.

Ví dụ Business Requirement là “tăng 10% tỉ lệ khách quay lại mua hàng”, thì Sales Team phải:

• Biết được thông tin khách hàng ==> Hệ thống phải quản lý được thông tin khách hàng

• Theo dõi được các hoạt động tương tác với khách hàng ==> Hệ thống phải lưu trữ được các hoạt
động tương tác
 • Hoặc Sales Team phải đo lường được giá trị mà từng khách hàng đóng góp cho công ty ==> Hệ
thống phải tính toán được chỉ số Customer Lifetime Value (CLV) cho từng khách hàng chẳng hạn.

Đó rõ ràng là các Stakeholder Requirements của Domain SME là Sales Team.

Nếu chúng ta không đạt được những yêu cầu này, thì rất khó, hoặc hầu như là không thể để đạt được
Business Requirement [tăng 10% tỉ lệ khách quay lại mua hàng]. Vì rõ ràng Sales Team chẳng có thông
tin gì bám víu vào để ra các quyết định giúp tăng 10% tỉ lệ khách quay lại mua hàng cả.

4. Loại 3: Solution Requirement

Sau khi nắm được Business Requirement và Stakeholder Requirement, anh em sẽ đi tới bước nắm chi
tiết được từng Solution Requirement.

Solution Requirement là những yêu cầu về khả năng và tiêu chuẩn mà giải pháp phải có để đạt được
Business Requirement và Stakholder Requirement ở trên.

Chính xác thì các requirement này nó dây mơ rễ má, ăn nhậu và bỗ trợ cho nhau rất nhiều.

BABOK định nghĩa Solution Requirement như sau:

Solution requirements describe the capabilities and qualities of a solution that meets the stakeholder
requirements

BABOK v3.0

Solution Requirement là thứ được mô tả chi tiết, kỹ càng hơn bất kỳ các loại requirement nào khác có
trong dự án. Và hơn hết, nó được chia làm 2 loại rõ rệt: một nói về capability và một nói về quality.

4.1. Functional Requirement

Functional Requirement là thứ nói về capability, tức là những thứ mà hệ thống làm được, nôm na là
như vậy.

BABOK v3.0 định nghĩa như sau: Functional Requirements describe the capabilities that a solution must
have in terms of the behavior and information that the solution will manage.

Mình có highlight 2 từ khóa quan trọng ở dòng trên là Behavior và Information.

Behavior tức là hành vi của hệ thống, những gì hệ thống có thể làm được.

Ví dụ:

• Hệ thống có thể xuất báo cáo ra dạng Excel lẫn PDF

• Hệ thống có thể hoạt động offline khi không có internet

• Hệ thống có thể tích hợp với Microsoft Project để thêm Gantt chart vào một record bất kỳ
 • Hoặc đơn gản là việc mô tả hệ thống có thể Cread/ Read/ Update/ Delete dữ liệu Đơn hàng.

Còn Information tức là dữ liệu của hệ thống, những gì hệ thống có thể lưu trữ được.

Ví dụ:

• Hệ thống quản lý được danh sách các món ăn trong menu theo thời vụ

• Hệ thống có thể lấy được dữ liệu chuyến bay từ Airlines GDS (Global Distribution System)

• Hoặc hệ thống có thể tự động ghi nhận các hoạt động tương tác với khách hàng dựa trên các
API có sẵn…

4.2. Non-Functional Requirement

Chúng ta đã biết được Functional Requirement, biết được hệ thống có thể làm gì, và biết được 50%
Solution Requirement.

50% còn lại chính là nằm ở Non-Functional Requirement (NFR)

Tin mình đi, sẽ có không ít những anh em BA dễ dàng bỏ qua các NFR – một thứ quan trọng không kém
Functional Requirement bên trên. Đặc biệt là đối với những anh em làm Outsource hay Service, như
mình hehe.

Anh em đọc thêm bài dưới đây mình có note về Non-Functional Requirements nhé.

• Non-Functional Requirements và chuyện về cái xô bể

• 23 loại Non-Functional Requirements trôi nổi ít ai để ý

Một ví dụ về NFR (Nguồn ảnh: CartoonStock.com)

5. Loại 4: Transition Requirement

Transition nghĩa là chuyển đổi, chuyển dịch từ một cái gì đó cũ sang một cái gì đó mới.

Transition Requirement là toàn bộ những yêu cầu của khách hàng liên quan tới việc áp dụng giải pháp
vào tổ chức như thế nào cho hiệu quả. Tức là những yêu cầu liên quan tới việc chuyển đổi tổ chức từ
trạng thái cũ, sang trạng thái mới.

Nguy hiểm hơn, anh em có thể nói là quá trình chuyển đổi từ As-is state thành To-be state, chuyển đổi
từ lúc tổ chức chưa áp dụng hệ thống sang áp dụng hệ thống, hoặc từ lúc áp dụng hệ thống cũ sang
lúc áp dụng hệ thống mới…

BABOK định nghĩa Transition Requirement như sau:

Transition requirements describe the capabilities that the solution must have and the conditions the
solution must meet to facilitate transition from the current state to the future state, but which are not
needed once the change is complete.
BABOK v3.0

Facilitate có nghĩa là làm cho đơn giản, làm cho dễ dàng.

Facilitate, một từ rất quan trọng với anh em BA (nguồn ảnh: Cambridge Dicitonary)

Đây là một từ khóa cực kỳ quan trọng với BA, với mình nó giống như một kim chỉ nam để làm việc vậy.
Càng làm thì mọi thứ phải càng đơn giản, chứ càng làm mà càng phức tạp hơn thì có vẻ công việc mình
làm không hiệu quả cho lắm.

Còn cụm “but which are not needed once the change is complete” nghĩa là BABOK muốn nhấn mạnh:
transition requirement chỉ quan trọng trong lúc triển khai, lúc đưa giải pháp vào sử dụng thực tế. Còn
khi áp dụng xong xuôi, mọi thứ chạy êm ru rồi thì mớ transition requirement này không còn quan trọng
nữa.

Một số ví dụ về Transition Requirement từ phía khách hàng cho anh em dễ hình dung:

• Ít nhất phải có 3 buổi đào tạo sử dụng hệ thống cho mỗi phòng ban

• Toàn bộ các Test Case phải được chạy test 2 lần bởi khách hàng trước khi Go-live

• Giải pháp phải được xây dựng trên nền Java 64-bit.

• Hoặc thậm chí có yêu cầu như: bộ phận ABC phải duy trì hoạt động trong suốt quá trình triển
khai dự án

• Hoặc đối với một số dự án ở Nhật: Nếu có thiên tai (động đất, sóng thần…) xảy ra, dự án sẽ tạm
hoãn cho đến khi tổ chức hoạt động trở lại và không phải chịu bất cứ chi phí nào cho việc hoãn
dự án.

6. Tạm kết

Hi vọng qua note này anh em sẽ hình dung rõ hơn về requirement, cũng như các loại của nó.
Đây là 4 loại requirement. Theo trình tự thì thường đầu dự án anh em sẽ nhận được các yêu cầu rất sơ
khởi như Business Requirement hoặc một vài Stakeholder Requirement.

Theo thời gian, anh em sẽ bắt đầu moi móc, cùng làm với team, với khách hàng để ra được những
Solution Requirement sát sườn nhất, phù hợp với cả 2 bên. Khi đó mình mới có cái nhìn rõ ràng nhất về
những thứ cần phải làm.

Còn Transition Requirement có thể có hoặc không. Vì thường nó sẽ được xem là “additional
requirement” trong dự án.

Để hiểu rõ hơn về requirement, anh em có thể đọc thêm các notes về:

• 11 cách moi móc requirement

• Các bước phân tích requirement

• Requirement tồn tại ra sao trong quy trình phát triển phần mềm?

VII. Non-Functional Requirements và chuyện về cái xô bể

Chuyện là nhà mình có cái xô bể, chắp vá cũng được 7-8 lớp. Về bản chất, nó vẫn đựng nước được.
Nhưng ngoài điểm đó ra, nó trông như đồ bỏ.

Mẹ mình thì vẫn khoái dùng cái xô này, và không nỡ vứt nó đi :3

Nhưng mỗi lần về quê mình lại chẳng muốn dùng nó tí nào? Kỳ cục zậy đó? Cùng là một cái xô bể,
nhưng có người muốn dùng, có người không.

Đó là vấn đề của Quality of Service. Ánh xạ qua thế giới phần mềm, nó chính là Non-Functional

Requirement

Nội dung [Hide]

1. Các loại requirement trong một dự án phần mềm

2. Functional Requirement là gì?

3. Non-Functional Requirement là gì?

3.1. Non-Functional Requirement quan trọng đến mức nào?

3.2. Non-Functional Requirement tạo ra GAP lớn giữa…

4. Các loại Non-Functional Requirement?

1. Các loại requirement trong một dự án phần mềm

Như anh em đã biết, hoặc chưa biết: một giải pháp, một sản phẩm, hay một phần mềm nào đó đều
có các yêu cầu cụ thể (requirement) cho các giải pháp, sản phẩm hay phần mềm đó.

Là một người làm Business Analyst, chúng ta sẽ làm rất nhiều thứ xoay quanh các requirement này.

Requirement thì có 4 loại:

Business Requirement

Stakeholder Requirement

Solution Requirement

Transition Requirement.

Bất kỳ phần mềm nào cũng vậy? Sinh ra đều phải có mục đích. Tức mỗi phần mềm đều có các yêu
cầu của riêng nó. Mà các yêu cầu này không phải là ít.

Một phần mềm có rất-rất-rất nhiều yêu cầu. Nào là phải làm được cái này, cái kia, nào là phải đẹp,
phải nhanh, phải abc, xyz…

Chính vì có quá nhiều requirement, xuất phát từ nhiều đối tượng khác nhau. Lộn xộn quá, nên người
ta mới gom nó lại, rồi chia thành 4 loại requirement như trên, để anh em BA chúng ta có thể dễ dàng
moi móc và quản lý được nó.

Cụ thể 4 loại nó như thế nào thì mình sẽ để dành nói ở bài sau. Bài này mình sẽ tập trung nói về
Solution Requirement.

Ô kê, Solution Requirement được chia nhỏ thành 2 loại sau:

Functional requirement

và Non-Functional requirement.

Có một số ví dụ cho anh em dễ hình dung hơn:

Ly nước:

Functional Req: ly đựng được nước

Non-Functional Req: ly rớt không bể.

Mũ bảo hiểm:

Functonal Req: có đèn chiếu sáng, nhấp nháy lòe loẹt trong đêm

Non-Functional Req: chịu được lực va đập lên tới 3000 Newton.

Ly chè đậu đen của bà Bảy đầu xóm:

Functional Req: chóng đói, bổ sung vitamin đậu đen.

Non-Functional Req: ăn xong có khăn giấy lau miệng, hoặc ăn xong không đau bụng.

Phần mềm ABCDXYZ:

Functional Req: quản lý thông tin khách hàng

Non-Functional Req: có nút Help – hướng dẫn người dùng online ngay trên hệ thống.

Đó là một vài ví dụ để anh em hình dung được thế nào là Functional Req và Non-Functional Req.

Vậy Functional Requirement là gì?

2. Functional Requirement là gì?

Functional Requirement là:

The capabilities that a solution must have in terms

of the behavior and information that the solution will manage

BABOK ver3.0

Trên là định nghĩa của BABOK, nhưng thôi, đọc nghe dài dòng tùm lum tùm la quá. Rút gọn lại anh
em có thể hiểu Functional Requirement là những thứ mà giải pháp có thể làm được.

Hay cụ thể hơn, Functional Requirement là nói về: Behaviors và Functions (Hành vi và Chức
năng) của giải pháp.

Ví dụ:

Ly thì phải đựng được nước

Mũ bảo hiểm phải có đèn phát sáng

Ly chè ăn zô là đỡ đói

Hệ thống ABCDXYZ quản lý được thông tin khách hàng.

Vậy còn lại.

3. Non-Functional Requirement là gì?

BABOK ver3.0 định nghĩa Non-Functional Requirement như sau:

Not relate directly to the behaviour of functionality of the solution, but rather describe conditions
under which a solution must remain effective or qualities that a solution must have.

BABOK ver3.0

Lại dài loằng ngoằng, nhưng không sao, đọc cũng dễ hiểu. Càng về sau BABOK định nghĩa càng dễ
hiểu mà, hehe.

Non-Functional Requirement là những thứ:

Không liên quan trực tiếp tới hành vi – chức năng của giải pháp

Nhưng lại là các điều kiện giúp hệ thống chạy tốt và đảm bảo được chất lượng như yêu cầu.
Rút gọn 2 dòng trên, mình có cách định nghĩa trực quan hơn như sau:

Non-Functional Requirement = Quality of Services

Tức Non-Functional Requirement là những thứ liên quan đến CHẤT LƯỢNG sản phẩm.

Sản phẩm đó đáp ứng được mục đích sử dụng là 1 chuyện, nhưng nó phải đảm bảo tốt về mặt trải

nghiệm người dùng thì mới thật sự đẳng cấp

3.1. Non-Functional Requirement quan trọng đến mức nào?

Quay lại cái xô ở đầu bài. Xô, là giải pháp để đựng nước và được dùng cho các mục đích khác nhau.

Functional Req của cái Xô là đựng được nước. Chỉ nhiêu đó thôi.

Còn Non-Functional Req của cái Xô là: xô làm bằng nhựa không giòn, phơi nắng không bể, không
mọc rêu, không trơn, kiểu dáng thon gọn, vừa tay cầm.

Rõ ràng, cái xô ở nhà mình chỉ đạt được mỗi Functional Requirement, còn Non-Functional
Requirement thì.. thấy gớm.

Mẹ mình thích dùng vì mẹ mình chỉ quan tâm đến Functional Requirement, tức là chức năng của
nó, chỉ cần đựng được nước là được.

Còn mình không thích dùng vì nó không đáp ứng được Non-Functional Requirement, những
requirement mà đáng lý ra một cái xô phải có. Đã zậy, còn lủng lỗ, chấp vá tùm lum tùm la, thấy ớn.

Điều này nói lên được vấn đề gì?

Nó nói lên được: User họ quan tâm điều gì?

À há…

Mấu chốt là ở chỗ này.

Nếu user giống mẹ mình, không care nhiều đến Non-Functional, ok anh em trong vùng an toàn.

Cứ thoải mái, chỉ cần cho hệ thống chạy được là được. Tức là hệ thống chỉ cần làm được những thứ
mà khách hàng yêu cầu là được.

Còn nếu user giống mình, rất rất quan tâm đến Non-Functional thì…, well, có vẻ hơi mệt với anh em.
Đối với họ, không những hệ thống phải chạy được, mà hệ thống còn phải chạy nhanh, gọn, và đẹp
nữa.

Và một khi mình nắm được mức độ kỳ vọng của users, mình sẽ biết cách làm họ hài lòng hơn.

Đã không ít lần mình và đồng bọn đang bon bon về đích, tưởng chừng sẽ Go-Live êm xuôi trót lọt.
Mà phải khựng lại cả thảy 4-5 lần cũng chỉ vì cái chữ Non-Functional Requirement này.

Khách hàng liên tục complain về nhóm users sử dụng iPad nhập liệu quá lâu, và touch quá nhiều trên
màn hình để có thể… hoàn thành được một giao dịch.
Hay việc tìm kiếm các keyword trên hệ thống cũng gặp trở ngại.

Ví dụ, có một dữ liệu mang tên: “Chú Bảy đẹp chai cute hột me tốt bụng”. Thì khi user nhập
keyword: “đẹp chai me” thì hệ thống không tìm ra kết quả.

Nhưng nếu user nhập keyword: “đẹp chai cute hột me” thì kết quả mới nhả ra. Tức hiện tại hệ thống
chỉ tìm được kết quả theo các keyword là một string theo đúng thứ tự từ trái sang phải.

Trong khi users họ lại muốn: chỉ cần nhập keyword “đẹp chai me”, thì hệ thống sẽ nhả ra tất cả các
kết quả chứa 3 từ khóa “đẹp”, “chai”, và “me” riêng biệt, không cần care đến thứ tự. Ví dụ:

Ông Sáu đẹp chai cute hột me khiêm tốn

ABC đẹp cute chai me hột khiêm tốn

XYZ đẹp me chai cute khiêm tốn hột…

Rõ ràng đó chính là các Non-Functional Requirement mà mình, một người BA không hề nắm được,
cũng như không làm rõ ngay từ đầu, khiến cho anh em tốn khá nhiều effort để setup lại mọi thứ cho
phù hợp với các “quality of services” này.

Đau thương, chỉ có thể chốt lại được bằng từ đau thương

….

Do đó nếu có ai hỏi mình: Non-Functional Req quan trọng đến mức nào? Thì mình tự tin trả lời
ngay: quan trọng như Functional Requirement vậy.
Nhiều lúc chưa cần quan tâm behind the scenes chạy như thế nào, lớp front end mà chuối là users

cũng bỏ chạy rồi (Nguồn ảnh: Browserling.com)

Mình tự tin đặt 2 thằng này ngang hàng nhau. Và đây thường là điểm GAP rất lớn giữa…

3.2. Non-Functional Requirement tạo ra GAP lớn giữa…

…anh em làm outsource và làm product.

Thường những người làm triển khai/ outsource – như mình không quan tâm nhiều đến các Non-
Functional Requirement. Vì end user của các giải pháp mình làm thường không phải là “end
consumer”.

Mà end user thì không phải trả tiền để sử dụng hệ thống, end consumer mới là người trả tiền để sử
dụng hệ thống.

Tức là end consumer mới là người sử dụng thông qua hệ thống.

Ví dụ anh em outsource làm hệ thống quản lý khách sạn Millennium, thì end user của hệ thống này
là các Quản trị viên của hệ thống, các nhân viên phòng ban. Tức họ là ai? Là người của khách sạn.
Không phải khách hàng.

Họ sẽ dụng hệ thống như một công-cụ-trung-gian giúp họ quản lý khách sạn tốt hơn mà thôi.

Còn đối với anh em làm product. Product ở đây có thể là ứng dụng đặt phòng trực tuyến của khách
sạn Millennium. End user chính là end consumer. Họ vừa là người dùng ứng dụng, vừa là người trả
tiền để sử dụng dịch vụ của Millennium.

Do đó, vấn đề “quality of service” của ứng dụng, hay các yếu tố non-functional của ứng dụng có làm
họ vui hay không? Có làm họ thấy thoải mái khi sử dụng hay không? Ứng dụng chạy mượt không?
vâng vâng… luôn được chú trọng hàng đầu.

Những yếu tố này góp phần KHÔNG-HỀ-NHỎ trong việc khách hàng ra quyết định: có tiếp tục sử
dụng dịch vụ nữa hay không.

Chưa kể, làm product phục vụ end consumer, anh em phải phục vụ tới hơn cả triệu người dùng.
Chứ không phải lẻ tẻ vài ba chục, hay chỉ vài trăm người dùng như những hệ thống quản lý back-
end.

Chắc hẳn anh em còn nhớ vụ Momo lắc lì xì.

Chỉ trong vòng một ngày 24/1, Momo phải chịu tải lên đến hơn 2 triệu lượt đăng nhập và lắc cùng
một lúc. Tức là hơn 2 triệu lượt CCU (concurrent users). Điều này có nghĩa đội ngũ anh em Momo
phải liên tục xử lý tình trạng tắt nghẽn server. Kinh khủng!

Hoặc lâu lâu app có vấn đề gì thì phải lo cắm đầu fix ngay, kể cả có holiday hay weekend.

Vì giả dụ anh em down cái app được quảng cáo thiệt ngon về xài, mà mới chạm có 3-4 cái thấy lag
banh chành, nút bấm gì mà tùm lum tùm la. Thì ngay lập tức: app bị delete cái một, và suốt đời nằm
gọn trong blacklist.

Do đó, đây là GAP không hề nhỏ, liên quan đến “tư duy hành nghề” của những anh em làm
outsource muốn chuyển qua làm product. Tuy nhiên, miễn là đừng ẩu và luôn chú ý cẩn thận thì

mình nghĩ GAP cũng không quá lớn

Ô kê, hi vọng mình đã chém đủ mạnh để anh em hiểu về tầm quan trọng của Non-Functional
Requirement (NFR). Biết nó quan trọng, chúng ta sẽ chú ý đến nó hơn.

Chú ý kể cả khi anh em đang làm triển khai những SaaS nhé. Những Software as a
Service như Dynamics 365 của Microsoft. Có những thứ NFR mà mình chẳng thể can thiệp được, ví
dụ như Security hay Accessibility của những SaaS này.
 Những yếu tố NFR này đều được các hãng build sẵn thành một gói để chúng ta tiện triển khai và sử
dụng.

Tuy nhiên, BA cũng cần nắm rõ những yếu tố NFR này ngay từ đầu dự án để tránh out of scope sau này,
cũng như giải thích trước cho khách hàng để họ hiểu những điểm mạnh và hạn chế của giải pháp (tránh
đòi thêm sau này).

Những NFR này thì các hãng đều có sẵn official document, anh em có thể dễ dàng tìm thấy bằng cụ

Gồ

Câu hỏi cuối cùng, Non-Functional Requirement (NFR) gồm những loại nào?

Phần dưới đây mình sẽ nói sơ lược về các loại NFR hay gặp nhất, từ những gì mình lượm lặt được

trong quá trình làm việc cũng như chia sẻ từ các bậc tiền bối

4. Các loại Non-Functional Requirement?

Sorry anh em, vì phần bốn này dài quá nên mình sẽ tách ra ở bài tiếp theo. Mình sẽ để link ở đây, vị
trí này, anh em đón đọc nhé.

Phần này sẽ nói về các loại NFR, kèm các ví dụ cụ thể luôn cho anh em dễ hình dung

Tóm tắt

Bài này mình sẽ đúc kết bằng những dòng sau cho anh em dễ nhớ:

Có 4 loại requirement: Business Req, Stakeholder Req, Solution Req và Transition Req (mình sẽ nói rõ
hơn ở bài sau)

Solution Requirement gồm: Functional và Non-Functional Req.

Functional Requirement nói lên behaviors và functions của giải pháp (what the system do?)

Non-Functional Requirement nói lên quality of services của giải pháp (how the system work?)
Phải luôn là Functional trước, rồi các yếu tố Non-Functional sẽ đi theo sau, đừng làm ngược lại
(Nguồn ảnh: akfpartners.com)

VIII. 23 loại Non-Functional Requirement trôi nổi ít ai để ý

Nguồn ảnh: GeriCoady/Hellogeri.com

Hế lô anh em, ở phần trước anh em đã hiểu thế nào là Functional Requirement và Non-Functional
Requirement (NFR).

Tiếp tục bài này mình sẽ điểm qua các loại Non-Functional Requirement mà anh em BA mình hay
gặp nhất. Cũng đơn giản, không có gì phức tạp lắm, tầm 23 loại thôi… anh… em…

“23 loại…”

23 loại nhưng ngắn gọn, dễ hiểu lắm :3

BABOK v3.0 thì chia NFR làm 15 loại. Tuy nhiên, mình thấy có vài cái hơi khó hiểu, và đâu đó vẫn
chưa cover được hết các trường hợp mình gặp, nên mình có làm lại danh sách dưới đây.

Danh sách 23 loại Non-Functional Requirement dưới đây là mình tổng hợp từ BABOK v3.0, từ
trang Requirement Quest, từ template của một số công ty và từ kinh nghiệm thực tế mà mình từng
trải.

Thứ tự quan trọng giảm dần nhé anh em.

Ô kê lét sờ gâuuuu

Nội dung [Hide]

• 1. Security

• 2. Performance

• 3. Usability
• 4. Integrity

• 5. Availability

• 6. Audit

• 7. External Interface

• 8. User Interface

• 9. Migration

• 10. Supportability

• 11. Compliance

• 12. Flexibility

• 13. Scalability

• 14. Extensibility

• 15. Localization

• 16. Purchased Component

• 17. Maintainability

• 18. Safety

• 19. Legal and Copyright

• 20. Installability

• 21. Accessibility

• 22. Reusability

• 23. Online Manual

• KẾT BÀI

1. Security
NFR 1: Security (Nguồn ảnh: SLANE Cartoons)

Security là các yêu cầu về bảo mật trong quá trình sử dụng hệ thống. Từ lúc truy cập, thực hiện thao
tác, in ấn chứng từ, đến lúc đăng xuất khỏi hệ thống.

Ví dụ về Security:

• Password của người dùng phải được hash bằng MD5.

• Hệ thống sẽ deactivate 30 phút nếu người dùng nhập password sai 5 lần liên tiếp.

• Tất cả những data “nhạy cảm” của người dùng như: password, SĐT, CMND, email phải được mã
hóa bằng 1024bit SSL.

• Khi user quên mật khẩu, link tạo mật khẩu mới phải được gửi về duy nhất địa chỉ email đăng ký
đầu tiên.

• Hoặc khi user thực hiện thanh toán online, hệ thống không được phép lưu trữ thông tin thẻ
credit/ debit của user.

2. Performance
Phần này có lẽ quá rõ ràng với anh em rồi chứ hả Performance tức là hiệu suất hoạt động của
hệ thống, và thường được đo lường bằng những tiêu chí sau:

• Thời gian phản hồi cho một transaction

• Số lượng transaction thực hiện được trong mỗi giây

• Công suất (capacity), ví dụ số lượng transaction mà hệ thống có thể lưu trữ/ thực hiện cho mỗi
đối tượng.

• Hoặc các yếu tố về tài nguyên sử dụng như: RAM, dung lượng DB…

Một số ví dụ để anh em hình dung rõ hơn về Performance khi lấy yêu cầu từ khách hàng:

Tất cả những màn hình input và output dữ liệu cần phải được sẵn sàng để hiển thị cho người
dùng trong vòng 3 giây, với điều kiện tải và connection giữa cilent/server là bình thường, cụ thể:

• Đối với màn hình input: tối đa 30 trường dữ liệu, không tính toán dữ liệu phức tạp, không tương
tác với hệ thống ngoài, có thể lưu trữ dữ liệu trực tiếp ngay xuống DB, và không lưu trữ các tệp
nội dung lớn như: hình ảnh, video, tệp tin quá 3MB.

• Đối với màn hình output: dữ liệu được query trực tiếp từ DB, hạn chế những query phức tạp,
những query từ hệ thống ngoài.
Hiển thị tối đa 50 dòng dữ liệu, mỗi dòng tối đa 10 cột, và mỗi dữ liệu có độ dài nhỏ hơn 100 ký
tự.

• *Điều kiện tải bình thường: 30 CCU (concurrent user – người dùng đồng thời) khi không dùng
cân bằng tải.

• *Điều kiện server tối thiểu: Intel Core i5, 4GB RAM, 500GB hard disk.

• *Client/ Server Connection: 500KB/s

Đối với những anh em làm software development, những điều trên là tối quan trọng. Nhưng đối với
anh em làm triển khai, thì những điều trên có vẻ hơi… thừa.

Vì hãng đã lo những thứ này cho mình hết, mình chỉ giải thích cho khách hàng hiểu để tránh yêu cầu
mở rộng sau này.

Tuy nhiên, cũng không nên lơ là mà bỏ nó ra khỏi document. Mình cũng đã từng như vậy. Hệ thống
khi đó phải query tới rất nhiều những component bên ngoài cho từng transaction một.

Và dĩ nhiên, performance bị kéo tụt hẳn xuống dưới đáy và mình bị complain rất nhiều về vấn đề
này. Lỗi do ai? Chính là do mình, do BA không làm rõ những vấn đề này ngay từ đầu. Don’t be like
me!

3. Usability
Làm rõ các yêu cầu về Usability là sẽ giúp user happy hơn rất nhiều

Là một trong những NFR quan trọng bậc nhất, Usability chính là khả năng “dễ sử dụng” của hệ
thống.

Nói về tính “dễ sử dụng” thì có 5 yếu tố sau, anh em có thể dựa vào đó để xác nhận yêu cầu với
khách hàng.

(Xác nhận chứ không phải lấy yêu cầu, vì thường khách hàng họ cũng chả mấy khi để ý đến vấn đề
này, trừ khi anh em đang làm product với end user cũng chính là end consumer).

a) Effectiveness

Là tính hiệu quả, làm được đúng những gì kỳ vọng.

Ví dụ user muốn xem hàng tồn kho thì thay vì user chọn menu On-hand >> rồi chọn kho để xem, thì
hãy hiển thị số lượng tồn kho ngay bên cạnh tên kho để user có thể xem được ngay, mà không cần
nhấp thêm phát nữa.

b) Efficiency

Cũng là tính hiệu quả, nhưng ngụ ý nhanh hơn, nguy hiểm hơn, thông minh hơn; nói chung là nhanh
và chính xác hơn.

Ví dụ BA chúng ta phải thiết kế làm sao để: giảm thiểu tối đa thao tác của users trên màn hình để họ
hoàn thành 1 task trên hệ thống nhanh nhất có thể.
Ví dụ từ 5 chạm, giảm xuống còn 3 chạm là có thể order xong ly trà sữa. Hoặc nút bấm có label rõ
ràng để user hiểu ngay được hành động sau khi bấm nút.

Nguồn ảnh: uxmovement.com

c) Engagement

Là mức độ: UI của hệ thống “tương tác” với khách hàng như thế nào. Không chỉ đẹp, mà còn phải
phù hợp với đối tượng end user và ngữ cảnh sử dụng.

Ví dụ hệ thống quản lý sản xuất thì không thể nào design trông như concưng.com được.

Nó tạo ra chút cảm xúc hơi hơi cu te chút xíu, mà những người làm planning trong sản xuất trên
dưới 30 tuổi không hề mong đợi một hệ thống như vậy.

d) Error Tolerance

Tolerance là mức độ “dễ tha thứ” của hệ thống. Nghe thấy hài quá, để ví dụ cho anh em dễ hình
dung.

Ví dụ khi tạo khách hàng, user nhập 20 trường thông tin, rồi nhấn nút Save. Khi đó, hệ thống tiến
hành kiểm tra và phát hiện có 3/20 trường dữ liệu bị nhập sai kiểu dữ liệu.

Lúc này hệ thống thấy ghét quá, chơi xóa hết cha nó 20 dữ liệu mà user đã nhập, yêu cầu user nhập
lại từ đầu, zậy mới ác chứ.

Đó là khi Error Toletance của hệ thống cực kỳ thấp.

Thay vào đó, hãy kiểm tra kiểu kiểu dữ liệu ngay trên từng field, và cảnh báo ngay nếu có lỗi, đừng
bắt user nhập đi nhập lại nhiều lần.

e) Easy to learn
Là tính “dễ học” của hệ thống. Thường người ta sẽ nhìn vào độ consistent (độ nhất quán) của các
form màn hình để đánh giá.

Ví dụ ở form màn hình Khách hàng, thanh Navigation ở vị trí A, thanh Command ở vị trí B, nút NEW
ở vị trí C. Mà qua form màn hình Đơn hàng, thanh Navigation thì ở vị trí C, thanh Command ở vị trí
A, nút New ở vị trí B, là coi như xong phim user luôn.

Họ không thể nhớ được, và cũng chả cần phải nhớ.

Phần nhiều các NFR thuộc nhóm Usability là mang kiến thức của UX, anh em có thể tham khảo thêm
về Usability tại đây nhé.

4. Integrity

Mục này là nói về “độ chính trực” của dữ liệu. Tức độ chính xác, xác thực của dữ liệu.

Ví dụ từ dữ liệu A được input vào hệ thống, nó xử lý hầm bà lằng ra kết quả A’, A”, rồi sang B, C, D,
D’, D” rồi ra E, cộng với F, chia cho G rồi tham chiếu với H để ra được một kết quả J cuối cùng.

Trong quá trình xử lý dữ liệu A để ra được dữ liệu “J” cuối cùng, hệ thống sẽ có các bộ batch jobs
chạy ngầm bên dưới, chạy đồng bộ và cả bất đồng bộ.

Nói về integrity, khách hàng sẽ yêu cầu dữ liệu phải được tính toán chính xác tại-tất-cả-các-thời-
điểm. Chứ không phải lúc này dữ liệu ra chính xác, lúc kia dữ liệu ra sai.

Nói thì nghe mắc cười quá, vì máy tính chứ có phải con người tính đâu mà lúc đúng lúc sai.

Nhưng thực tế đối vối những công thức phức tạp, đòi hỏi lấy dữ liệu từ nhiều nguồn thì chuyện này
là có xảy ra chứ không phải không.

Như cá nhân mình đã từng gặp một trường hợp: để ra được con số thành tiền cuối cùng, hệ thống
phải lấy toàn bộ thông tin đơn hàng, request đến dữ liệu khuyến mãi bên ngoài hệ thống để lấy giá,
discount, hàng tặng các kiểu, rồi tính toán thêm 4-5 parameters gì nữa để ra được giá cuối cùng.

Trong quá trình tính toán này có các batch job chạy bất đồng bộ, đòi hỏi 1 đoạn thời gian khoảng
30s đến 1 phút mới chạy xong hoặc người dùng phải chịu khó bấm nút force các job đó thì nó mới
chạy.

Khi những job này không chạy thì vô tình những batch job chạy đồng bộ khác nó overlap lên, thế là
kết quả bị thiếu đi 1-2 phép tính gì đó, nên kết quả lúc ra sai, lúc ra đúng.

Ra kết quả sai là khi user refresh màn hình ngay, ra kết quả đúng là khi user chờ khoảng 30s rồi mới
refresh màn hình hoặc chờ cho hệ thống tự refresh.

Lúc này thì thôi rồi, chỉ có đội quần chứ nói năng gì nữa. Hệ thống làm gì mà lúc ra sai, lúc ra đúng.
Từ đó nó tạo ra tâm lý ngờ vực rất lớn của khách hàng về giải pháp mình mang lại.
Do đó, anh em cần phải thống nhất rõ với khách hàng về độ “integrity” – độ “chính trực” của dữ liệu
trong những bối cảnh, những khoảng thời gian nhất định.

Nhớ integrity nhé anh em!

5. Availability

Availability là các yêu cầu về: mức độ hệ thống sẵn sàng để được sử dụng, gồm 2 yếu tố:

• Thời gian có thể sử dụng hệ thống

• Các yếu tố phụ thuộc để vận hành hệ thống.

Ví dụ về thời gian nhé: Hệ thống phải đảm bảo vận hành 24/7, nâng cấp tối đa 1 lần trong vòng 3
tháng, downtime mỗi năm không quá 1 giờ đồng hồ.

Còn về các yếu tố phụ thuộc thì mình cũng bị nhiều trường hợp.

Ví dụ hệ thống của mình đang cài thêm một “Add-on” hoặc một ứng dụng nào được built bởi bên
thứ ba, thì NFR ở đây có thể là: Hệ thống phải đảm bảo vận hành 24/7 và không phụ thuộc vào sự
ngưng hoạt động của bất kỳ sản phẩm đến từ bên thứ 3 nào.

6. Audit

Audit là các yêu cầu về khả năng ghi nhận lại các tác vụ đã thực hiện trên hệ thống, nhằm mục đích
kiểm tra. Nhớ nhé anh em, chỉ nhằm mục đích kiểm tra, không phải để thống kê hay báo cáo.

Ví dụ về Audit:

• Dữ liệu audit được sẽ lưu trữ tách biệt trong một database riêng, khác database chính của hệ
thống.

• Dữ liệu hệ thống phải được backup hằng ngày, và tồn tại trong vòng 30 ngày.

• Các dữ liệu audit được phải ở chế độ Read Only và không được sửa từ giao diện người dùng.
7. External Interface

Phần này nôm na nghĩa là tích hợp.

Anh em sẽ elicit các yêu cầu cụ thể của khách hàng về vấn đề: tích hợp các components ở hệ thống
đang build với các components ở các hệ thống khác như thế nào.

Vì chuyện tích hợp (integration) là cực kỳ quan trọng trong bất kỳ dự án nào, nên thường mình thấy
phần mô tả requirement về tích hợp sẽ được tách riêng ra một phần riêng biệt trong document.

Phần này anh em sẽ mô tả một bức tranh tổng quan cho việc trao đổi dữ liệu giữa các system, bao
gồm: những component nào được trao đổi, mục đích làm gì, tần suất thay đổi ra sao, số lượng
người dùng tác động…
Anh em sẽ phối hợp với Tech Lead/ PM để mô hình hóa lại bức tranh tích hợp dữ liệu của khách
hàng

Tuy nhiên ở phần External Interface, anh em cũng có thể thêm 1 vài yêu cầu chi tiết mà mình elicit
được từ phía khách hàng như:

• Toàn bộ dữ liệu phải được tích hợp qua API

• Và các API phải trả kết quả ra dạng JSON hoặc XML

• Hoặc toàn bộ quá trình nhận/ gửi dữ liệu giữa các hệ thống phải được mô tả chi tiết trong
document.

8. User Interface

Có thể anh em sẽ dễ nhầm lẫn giữa NFR Usability và User Interface. Nó đều đa phần thể hiện ở giao
diện người dùng. Nhưng:

• Usability mang nghĩa rộng hơn về tính “dễ sử dụng”, nó có thể là cải thiện UI, thay đổi cấu trúc
dữ liệu, hoặc thậm chí là thay đổi luồng data đi trong hệ thống.

• Còn User Interface chỉ đơn thuần là những yêu cầu về giao diện người dùng mà Khách hàng
mong muốn, bao gồm:

o Cấu trúc UI

o Cảnh báo và thông báo lỗi

o Một số yêu cầu khác.

Một số ví dụ về User Interface như sau:

• Các lưới dữ liệu xuất hiện trên hệ thống đều phải có chức năng filter và sort.

• Hệ thống đều phải hỏi xác nhận (Y/N) cho các thao tác xóa dữ liệu.

• Tất cả các thông báo lỗi đều phải đưa ra các hướng dẫn khắc phục cho người dùng.

• Khuyến khích vertical scrolling, hạn chế tối đa horizontal scrolling.

• Giao diện màn hình luôn có độ phân giải mặc định 1024×768 pixels.

• Đối với các quy trình tuần tự qua nhiều bước, phải có progess bar kèm thông tin chi tiết.

• Toàn bộ drop down list phải được sắp xếp theo thứ tự A to Z và số tăng dần.

Câu thần chú nổi tiếng khi làm bất kỳ UI mockup nào. (Nguồn từ: Hugh Macleod)

9. Migration

Migration là NFR quy định về việc migrate dữ liệu từ hệ thống cũ sang hệ thống mới.

Migrate dữ liệu tức là chuyển dữ liệu, đồng bộ dữ liệu từ hệ thống này, môi trường này, sang hệ
thống khác, môi trường khác.

Ví dụ: Chuyển toàn bộ 250,000 dữ liệu khách hàng; 12,500 dữ liệu sản phẩm và 500 dữ liệu bảng giá
từ hệ thống ABC cũ sang hệ thống ABC mới.
Cái này anh em phải, phải làm rõ ngay từ đầu. Vì chuyện migrate data không hề đơn giản tí nào.
Mình đã từng rất tơi tả vì ôm đồm tới hơn 180,000 dòng dữ liệu sản phẩm đưa qua hệ thống mới
bằng… excel.

10. Supportability

Supportability mô tả những yêu cầu về môi trường/ nền tảng mà hệ thống chạy tốt trên đó.

Ví dụ về supportability của sản phẩm Dynamics 365.

Các thiết bị, nền tảng mà giải pháp Dynamics 365 hỗ trợ (Nguồn ảnh: Microsoft).

11. Compliance

Compliance nghĩa là tuân thủ, làm đúng.

Tức compliance là các yêu cầu về việc hệ thống phải đảm bảo tuân thủ theo đúng những quy
định của pháp luật, quy định của nhà nước, luật công ty, luật tài chính, luật đất đai, luật môi trường,
luật bảo vệ trẻ em, động vật quý hiếm, abc, xyz…

Phần compliance này thường sẽ bao trùm luôn những quy định chung nhất, ví dụ quy định của các
tổ chức thanh toán quốc tế, quy định hàng hải, vận tải đường biển, vâng vâng…

12. Flexibility
Là yêu cầu về khả năng linh hoạt của hệ thống, có thể thích ứng với bất kỳ “môi trường” nào.

Từ môi trường ở đây có thể là: ở các tổ chức khác nhau, phạm vi địa lý khác nhau, hoặc là
những ngành nghề khác nhau.

Ví dụ sản phẩm Microsoft Dynamics 365 là giải pháp có thể đáp ứng flexibility requirement của bất
kỳ khách hàng khó tính nào.

Vì đây là gói giải pháp áp dụng được ở rất nhiều ngành nghề khác nhau: từ manufacture, đến media,
banking, hay kể cả healthcare. Chưa kể nó được áp dụng trên rất nhiều quốc gia, trải khắp thế giới.

Độ flexible của Dynamics 365, khi có tới hơn 120 quốc gia có thể áp dụng với mức độ hiệu quả
hoạt động ngang nhau, ở Việt Nam cũng như ở Mỹ, không thua kém gì nhau. (Nguồn ảnh:
Microsoft)

Ví dụ khách hàng có 5 location trên khắp thế giới: Việt Nam, Lào, Campuchia, Mông Cổ và Ả rập sau
đi. Lúc này giải pháp của anh em phải mang tính flexible. Tức là triển khai ở Việt Nam được, thì triển
khai ở Ả rập sau đi vẫn được.

Ví dụ giải pháp anh em build có hỗ trợ chữ Latin ==> Việt Nam, Mông Cổ ô kê.
Nhưng lại không hỗ trợ chữ tượng hình ==> Lào, Campuchia, Ả Rập tèo ngay. Ví dụ vậy.

Do đó, Dynamics 365 là một ví dụ điển hình cho việc đáp ứng flexibility requirement của khách hàng.

Ô kê, một vài phút quảng cáo trơ trẽn cho Dynamics 365 đã hết, chuyển qua phần tiếp theo nhé anh
em :3

13. Scalability
Scalability là khả năng mở rộng của system.

Ví dụ với một trang e-commerce hiện tại, hệ thống có thể proceed được 500 orders cùng một lúc, thì
anh em có thể có nhiều cách để thiết kế lớp back end phía sau.

Tuy nhiên, nếu khách hàng họ “tà loòng thêm” yêu cầu về khả năng: có thể scale up sau 2 năm hoạt
động, thì lúc này lớp back end phải được thiết kế khác.

Ở Non-Functional Requirement này, anh em sẽ ghi nhận những yêu cầu chi tiết về độ scale up mà họ
muốn trong tương lai (dĩ nhiên là nếu được :v).

Một số ví dụ cụ thể:

• Server có khả năng upgrade cấu hình.

• Có khả năng tách DB trên một server riêng và backend trên một server riêng.

• Có khả năng áp dụng load balancer chạy bằng HA Proxy.

• Có khả năng chia nhỏ DB master thành các DB con và đồng bộ ngược trở lại.

14. Extensibility

So với Scalability là mở rộng về tần suất hoạt động, thì Extensibility là mở rộng về phạm vi chức
năng của giải pháp.

Tức khả năng phát triển thêm những tính năng mới mà không làm ảnh hưởng tiêu cực đến các tính
năng cũ.

Ví dụ về Extensibility:

• Có khả năng phát triển thêm module quản lý chi phí Marketing cho kênh bán lẻ mà không thay
đổi cấu trúc dữ liệu cũ.

• Có khả năng phát triển tính năng kiểm hàng tồn kho mà không thay đổi cấu trúc dữ liệu cũ.

15. Localization

Trong danh mục các NFR, Localization là cái mình nghĩ sẽ ít được quan tâm nhất, nhưng lại đóng yếu
tố rất quan trọng. Nghe lạ lùng vậy đó.

Nó ít được quan tâm phần nào có lẽ vì nó đã khá… rõ ràng.

Localization nghĩa là các yêu cầu về “tính bản địa” của giải pháp mình đang làm. Cụ thể nó là các yếu
tố liên quan đến:

• Ngôn ngữ địa phương, phát âm

• Luật pháp bản địa

• Đơn vị tiền tệ bản địa

• Văn hóa

• Hoặc thậm chí là các đặc thù trong tính cách của end-users, người trực tiếp sử dụng hệ thống.

Ngôn ngữ địa phương thì có thể bỏ qua, vì thời buổi giờ thì hầu như system nào cũng hỗ trợ đa ngôn
ngữ. Tiếng Anh là ngôn ngữ chung của IT – là thứ chắc chắn phải có. Còn lại sẽ là ngôn ngữ địa
phương.

Nhưng cần chú ý là end-users là nhóm người sử dụng British English, hay American English. Cái này
cũng đem lại trải nghiệm người dùng rất khác biệt.

Phát âm cũng vậy. Behaviour hay behavior cũng là vấn đề à nha. Mấy điểm này phải moi móc thông
tin từ khách hàng hết, xem họ yêu cầu như thế nào.

Luật pháp là cái quan trọng nhất. Ví dụ anh em triển khai module kế toán cho 1 doanh nghiệp ở Việt
Nam khác hẳn hoàn toàn triển khai cho 1 doanh nghiệp ở Venezuela. Vì sổ sách kế toán, các bộ luật,
và chứng từ liên quan đến nghiệp vụ kế toán ở 2 location là hoàn toàn khác nhau.

Tương tự là văn hóa, hoặc tính cách của end-users. Cái này sẽ hơi thiên về UX, mình không rành lắm,
nên mình sẽ để một cái link ở đây, anh em tự tìm hiểu nhóe.

Tuy nhiên, giờ thế giới đa phần lên mây hết. Các SaaS được thiết kế thành các package rất flexible,
hỗ trợ yếu tố Localization rất nhiều. Nên hầu như NFR này không được quan tâm nhiều lắm ở thời
điểm bấy giờ.

16. Purchased Component

Tiếp theo, Purchased Component các NFR mô tả các component có trong hệ thống mà khách
hàng phải trả tiền để sử dụng, bao gồm việc mô tả tính năng và hạn chế của các components này.

Ví dụ: Mình triển khai hệ thống Dynamics 365 Customer Engagement (CRM) cho khách hàng, thay vì
việc khách hàng muốn mình build mới giải pháp Loyalty – Quản lý khách hàng thân thiết trên CRM,
thì họ mong muốn mình mua một giải pháp Loyalty có sẵn và trả tiền theo subscription hàng tháng,
để tiết kiệm thời gian triển khai và để họ đưa vào sử dụng càng nhanh càng tốt.

Khi đó, BA phải mô tả rất chi tiết về yêu cầu sử dụng giải pháp Loyalty có sẵn này như
một “Purchased Component”. Tính năng nó ra sao, hạn chế của nó như thế nào, khả năng thích ứng
của nó với các phiên bản Dynamics 365, rồi nâng cấp ra sao, vâng vâng và mây mây.

17. Maintainability

Maintainability là các yêu cầu về khả năng bảo trì hệ thống. Tức là hệ thống có: dễ dàng được phát
hiện ra lỗi và sửa lỗi hay không.

“Dễ dàng được phát hiện ra lỗi và sửa lỗi” nghĩa là khi gặp bug, Admin có thể dễ dàng biết được
nguyên nhân tại sao, và nắm được hướng khắc phục ngay.
Để làm được điều đó thì lớp behind the scenes bên dưới phải không được quá phức tạp, rối rắm.
Coding phải có convention rõ ràng, gọn, sạch, đẹp. Document phải rõ ràng từng module, từng
feature. Thì team maintain – support mới có thể làm tốt công việc sau này được.

Ví dụ một số yêu cầu về Maintainability:

• Với mỗi lần nâng cấp hệ thống định kỳ hàng quý sẽ không kéo dài quá 30 phút.

• Toàn bộ code Javascript và .NET phải được viết theo coding convention của ABC XYZ.

• Document và code phải được review nội bộ qua 2 cấp.

18. Safety

Đây đây đây…

Đây là cái mình nghĩ sẽ ít ai nghĩ tới, vì nó quá độc lạ và đặc biệt là ít dùng.

Safety là một NFR mô tả các yêu cầu về việc: hệ thống không được làm hại đến môi
trường hoặc sức khỏe của con người trong mục đích sử dụng.

Ví dụ: hệ thống quản lý khám chữa bệnh cho bênh viện ABC, các đơn thuốc trước khi được in ra và
gửi cho bệnh nhân phải được bác sỹ tự tay nhấn nút Approve trên hệ thống.

Vì nếu đơn thuốc được y tá hoặc hệ thống phát hành hàng loạt, mà không có sự kiểm duyệt của bác
sỹ thì rất nguy hại đến… bệnh nhân vì có thể sẽ có sai sót xảy ra (ảnh hưởng đến sức khỏe con
người).

Đó là nội dung chính của mục NFR Safety này.

19. Legal and Copyright

Phần này cũng lại quan trọng mà thường mình thấy mọi người ít khi để ý, đặc biệt là mình hê hê.

Đó là chuyện legal và các mẫu copyright liên quan.

Legal & Copyright là một NFR quy định các thủ tục pháp lý cần thiết, quy định sử dụng wordmark,
trademark hay quy định sử dụng logo của khách hàng như thế nào cho đúng.

Ví dụ về Legal & Copyright NFR:

Tất cả các quyền sở hữu trí tuệ (Intellectual Property Rights – IPR) liên quan đến sản phẩm hoặc tài
liệu đính kèm được tạo bởi ABC, thì đều là kết quả của gói dịch vụ và được sở hữu bởi khách hàng.

Hoặc nói về cách dùng logo, anh em phải đảm bảo logo của khách hàng phải được dùng đúng. Đúng
từ: khung hình, bảng màu, kích cỡ, màu nền, vâng vâng và vâng vâng.
Chứ có những chỗ trên hệ thống cần hiển thị logo khách hàng mà màu hiển thị không đúng, hoặc

logo của họ bị cắt xén để… vừa với khung hình, thì thật sự nó hơi thiếu chuyên nghiệp

20. Installability

Cái tên nói lên tất cả. Installability là các yêu cầu về cài đặt hệ thống. Cài đặt ở đây bao gồm: cài đặt
mới, cài đặt lại, nâng cấp, và xóa cài đặt.

Non-Functional Requirement về Installability nói đến các yêu cầu về quá trình cài đặt, ví dụ: quy
trình cài đặt không được quá mấy bước, ai là người cài đặt, họ cần có những kiến thức tối thiểu về
ngôn ngữ gì, platform, công cụ gì? PHP, C#, JS…

Ví dụ NFR về Installability:

• Việc cài đặt hệ thống cho người dùng phải được thực hiện bởi đối tác phát triển phần mềm hoặc
Quản trị viên hệ thống của khách hàng có ít nhất 3 năm kinh nghiệm làm C# và các thư viện liên
quan.

• Hoặc việc nâng cấp plugin sẽ không làm thay đổi dữ liệu và cấu trúc dữ liệu của hệ thống.

21. Accessibility

Accessibility là các yêu cầu về khả năng hỗ trợ người dùng sử dụng hệ thống, đặc biệt là dành cho
những người khiếm khuyết.

Ví dụ về Accessibility:

• Hệ thống e-Learning hỗ trợ các khóa học phiên bản TEXT cạnh bản AUDIO dành cho người khiếm
thính.

• Với những người khiếm thị, hệ thống hỗ trợ điều khiển qua giọng nói.
 Hệ thống có nhiều chức năng hỗ trợ người dùng (đặc biệt là người khiếm khuyết) sử dụng hệ
thống hay không? (Nguồn ảnh: Leewilson)

22. Reusability

Reusability là các yêu cầu về khả năng có thể tái sử dụng của một hoặc nhiều phần trong hệ thống.

Ví dụ: với các trang e-commerce thì mục Frequently Asked Questions lúc nào cũng có. Đây là thứ
khách hàng có thể yêu cầu để sau này họ có thể dùng source code đó để build các trang e-commerce
khác cho các công ty con chẳng hạn.

23. Online Manual

Online Manual là các NFR quy định về các chức năng hỗ trợ người dùng trực tuyến ngay trên hệ
thống.

Đa phần là các nút HELP ngay ở góc phải bên trên màn hình. Khi người dùng bấm vô thì mở ra một
trang online documentation, lưu trữ toàn bộ tài liệu hướng dẫn để người dùng tham khảo ngay tức
thì.

Hoặc khi người dùng thực hiện một thao tác lỗi, hệ thống hiển thị một popup message hướng dẫn
cách khắc phục ngay.

Ví dụ chức năng Online Manual của Dynamics 365

IX. Dân chơi lấy yêu cầu với 3 nguyên tắc sau

Hello anh em. Tiếp nối với bài viết lần trước – nói về những điều nên tránh khi làm BA. Ở bài này, mình
sẽ nói về điều ngược lại: những điều nên làm, rất nên làm, và thậm chí là không thể thiếu khi lấy yêu
cầu.

Nói cách khác nguy hiểm hơn, nội dung bài này sẽ là 3 nguyên tắc để lấy yêu cầu một cách hiệu

quả
“Dân chơi” ở đây là mình – từ số kinh nghiệm ít ỏi mình rút ra được, từ nhiều anh chị kỳ cựu xung quanh
mình chỉ dạy, và cũng như tham khảo từ các bậc tiền bối trên mạng.

Nhưng trước khi tham khảo 3 nguyên tắc chủ chốt này, mình sẽ nói qua về 2 khó khăn mà theo mình
là “oái ăm nhất” khi lấy yêu cầu nhé.

Ô kê lét gâuuuuu!!!

Nội dung [Hide]

• 1. Những khó khăn khi lấy yêu cầu

o 1.1. Kinh nghiệm

o 1.2. Khả năng diễn đạt

• 2. Ba nguyên tắc khi lấy yêu cầu

o 2.1. Luôn chuẩn bị

o 2.2. Trực quan khi cần

o 2.3. Tỉnh táo khi lắng nghe

• 3. Tự bốc phốt

1. Những khó khăn khi lấy yêu cầu

1.1. Kinh nghiệm

Bá tánh đồn rằng: Lấy yêu cầu là một “bộ môn nghệ thuật” đòi hỏi yếu tố kinh nghiệm cao và có thể xem

người lấy yêu cầu như một người nghệ sĩ

Nghe hơi chém gió một chút nhưng anh em cứ thử tưởng tượng thế này cho dễ hiểu.

Anh em được giao nhiệm vụ vận chuyển 5 tấn gỗ lậu từ Lào Cai đi Cam pu chia.

Ô kê, nhiệm vụ đã rõ ràng. Câu hỏi tiếp theo: những yếu tố nào có thể tác động, làm chuyến đi của mình
bị fail?

À, kinh nghiệm là ở chỗ này.

Với người đã có kinh nghiệm chạy tuyến đường này, họ biết rõ: chỗ nào có công an, chỗ nào đường xấu,
chỗ nào đường đẹp, chỗ nào có thể dừng xe nghỉ trưa, ăn tối. Và hàng tỉ thứ khác được xét vô diện “kinh

nghiệm”, mà chỉ những ai đã đi chuyến này rồi mới có được

Đây đều là những rủi ro tiềm tàng có trong chuyến đi.

Nếu không để ý, hoặc chưa từng biết, nó có thể làm chuyến hàng của mình bị delay, bị hư hỏng, bị cướp,
bị công an thổi, bị abc xyz, vâng vâng…

Lấy yêu cầu trong phần mềm cũng vậy!

Nếu anh em chưa từng làm 1 dự án nào, thì hầu như là rất khó để lấy yêu cầu 1-cách-ổn-nhất. “Ổn” ở
đây tức là đủ để team nhà hiểu được các vấn đề của khách hàng và thiết kế được giải pháp.

Nếu không có yếu tố kinh nghiệm, mà chỉ follow theo những questionnaire sẵn có, thì hầu như những gì
mình khai thác được từ khách hàng chỉ là 30% bề nổi của tảng băng.

Và dĩ nhiên, 30% là không đủ để ăn nhậu gì hết.

70% còn lại ở đâu?

70% còn lại đến từ những business case khác có thể xảy ra, mà mình chưa cover được hết.
70% đó cũng có thể đến từ những vấn đề kỹ thuật tiềm tàng như việc tích hợp, migrate data…

Hoặc phức tạp hơn, 70% đó đến từ yếu tố con người, cả từ phía khách hàng, lẫn team nhà. Mà chỉ
những ai, đã trải qua thực tế oái ăm như vậy, thì mới có thể nhìn nhận ra được các vấn đề tiềm tàng >>
để làm rõ ngay từ đầu, thì sau này dự án mới chạy trơn tru được.

Nói tóm lại, phải làm ít nhất một dự án từ đầu chí cuối rồi, thì mới mong lấy yêu cầu một cách ổn nhất
được…
Kinh nghiệm tuy là vấn đề không nhỏ, nhưng không phải không có cách giải quyết. Xem tiếp phần
dưới nhé anh em!

1.2. Khả năng diễn đạt

Vấn đề thứ hai đến từ khía cạnh giao tiếp.

Sẽ rất dễ để anh em rơi vào trường hợp: Mình muốn nói A, nhưng méo hiểu sao không diễn tả được.
Muốn nói A, nhưng người ta toàn hiểu A’, hoặc A+.

Điều này có ba lý do: một là do cách mình truyền đạt dở, hai là do cách mình truyền đạt dở, và ba cũng
là do cách truyền đạt của mình dở. Lạ lùng vậy đó :))

Cá nhân mình cũng gặp trường hợp này nhiều. Và trong các trường hợp, khi nói không được thì mình
phải… vẽ.

Thực hành vẽ mọi lúc mọi nơi nhé anh em

Vẽ là một trong 11 phương pháp moi móc thông tin được sử dụng phổ biến mà mình có đề cập. Và nó
cực kỳ lợi hại.

Anh sếp mình là chuyên gia vẽ hình.

Nói cái gì mà khó hiểu là ổng động thủ ngay. Nếu chỗ đó không có bảng, không có bút, thì ổng dùng

Power Point, Excel. Nói chung là đụng đâu vẽ nấy. Vậy mới đỉnh kout

(Phần này mình sẽ nói rõ hơn bên dưới).

Ô kê, chung quy lại thì đa phần chúng ta sẽ gặp phải 2 trở ngại “nổi cộm” trên khi lấy yêu cầu.

• Thiếu kinh nghiệm

• Và cách diễn đạt chưa hiệu quả

Để giải quyết được 2 vấn đề trên ==> lấy yêu cầu một cách hiệu quả hơn ==> anh em đọc ngay 3 nguyên
tắc dưới đây nhé.

2. Ba nguyên tắc khi lấy yêu cầu

2.1. Luôn chuẩn bị

Nguyên tắc đầu tiên: CHUẨN BỊ THẬT TỐT.

FAIL PREPARE = PREPARE FAIL.

Giờ, anh em hãy thử nhớ lại, có phải meeting mình toàn thò đâu vô cho có. Rồi khi vô meeting, mới bắt
đầu mở cái này, mở cái kia ra xem, rồi thảo luận. Chứ chả bao giờ chuẩn bị trước hết đúng không.

Cái này là bình thường khi họp nội bộ với nhau. Cao lắm sẽ gây tốn thời gian và họp không hiệu quả.

Nhưng hậu quả sẽ rất vô chừng nếu mình đi lấy yêu cầu mà vẫn giữ nguyên cách làm việc như này.

Vậy để chuẩn bị cho workshop lấy yêu cầu, anh em cần làm những gì?

Bảng questionnaire

Đầu tiên, anh em cần phải chuẩn bị được 1 cái bảng questionnaire.

Mỗi dự án, mỗi khách hàng khác nhau là một cái bảng questionnaire khác nhau. Không cái nào giống cái
nào.

Anh em phải chuẩn bị các câu hỏi dựa trên tài liệu RFP mà khách hàng gửi (Request For Proposal) hoặc
khi vô dự án rồi thì là UR (User Requirement). Thường khách hàng sẽ có RFP hoặc UR cho mình. Trong đó
nó sẽ liệt kê những vấn đề của khách hàng, cái họ cần và cái họ muốn.

Mình cần list down ra những câu hỏi cần làm rõ với khách hàng, dựa trên cái RFP vô cùng sơ khởi và
mông lung này.
Tuy nhiên nếu khách hàng không có RFP, hoặc anh em không join dự án ngay từ đầu giai đoạn sales, thì
bắt buộc anh em phải làm việc trước thật rõ ràng với Sales hoặc PM. Để hiểu rõ paint point của họ và
những thứ họ mong muốn, thì mới có thể xây bảng questionnaire các thứ cần hỏi được.

Ô kê, vậy thì chuẩn bị questionnaire như thế nào?

• Cột thứ 1 là số thứ tự

• Cột thứ 2 là câu hỏi

• Cột thứ 3 là câu trả lời (ghi nhận được)

• Cột cuối cùng là người/ team mà mình nghĩ là có câu trả lời chính xác nhất.

Nó sẽ kiểu kiểu như sau.

Sau đó, hãy đem bảng Questionnaire này đi nhờ những Senior trong team xem qua một lần.

Tận dụng kinh nghiệm của họ, để mang vào buổi workshop của mình.

Bài toán kinh nghiệm phần nào được giải quyết ở chỗ này.

Sàn lọc đối tượng tham dự

Workshop lấy yêu cầu thì nên tối giản người tham dự. Mục đích buổi đó liên quan đến module gì, chức
năng gì, thì cần người của bộ phận đó tham dự thôi.

Do đó, anh em cần chuẩn bị một cái lịch thật chi tiết để gửi cho khách hàng: À, ngày đó tui sẽ workshop
với chị này bộ phận A, anh kia bộ phận B.

Hoặc là workshop với bộ phận C cho chức năng C, thì tui muốn vừa có cả Manager, vừa có cả Admin,
vừa có cả nhân viên thị trường để kết quả thu được là đa chiều nhất.

Tránh làm tốn thời gian của khách hàng là điều mình rất rất rất cần chú ý.

Vì sao?

Vì khi khách hàng tốn thời gian >> họ uể oải >> chán nản >> ngáp ngắn ngáp dài >> BA khai thác kém
hiệu quả >> chất lượng output thấp >> BA nản >> requirement tệ >> dự án failed >> PM chửi >> Dev
chửi >> BA die!
Xác định mục tiêu rõ ràng

Anh em cần xác định được mục tiêu của các buổi workshop là gì. Càng cụ thể càng tốt. Ví dụ:

• Hiểu được cách đội Sales vận hành, theo các trường hợp thực tế có thể xảy ra.

• Hiểu được cách họ làm 1 cái contract cho khách hàng

• Hiểu được sếp của bộ phận sản xuất hằng ngày đang theo dõi chất lượng hoạt động như thế
nào.

• Xác định được cấu trúc, sơ đồ tổ chức, bộ máy hoạt động….

Khi đã có mục đích rõ ràng, anh em mới bắt tay vô chọn các phương pháp moi móc thông tin phù hợp
mà mình có nói ở trên.

Tiếp đến, mình sẽ “upgrade” bảng questionnaire như sau: phân loại bảng questionnaire này theo
những vấn-đề-quan-trọng-mà-mình-đang-mông-lung-cực-kỳ.

Mình từng làm project cho một công ty dịch vụ. Cái cốt lõi, chính yếu nhất của nó là cần theo dõi và
quản lý được quá trình thương thảo hợp đồng với khách hàng.

Mà phải nói là cái hợp đồng của nó kinh khủng, rồng rắn má ơi, đọc muốn lòiii con mắt @@ Thì đó chính
là điểm quan trọng nhất mình cần phải khai thác cho bằng được.

Và mình dành hẳn 2 trang A4 để note vào những câu hỏi, những giả định và các trường hợp có thể xảy
ra vào Questionnaire, để dành hỏi khách hàng, nhằm làm rõ vấn đề này.

(à, giả định trong trường hợp này rất nên xài nhé anh em, chứ không như trường hợp này)

Và nhớ bám sát mục tiêu

Đối với các buổi workshop kiểu này thì mục tiêu cao cả nhất vẫn là moi móc được những thứ mình cần.

Tức là từ thông tin có sẵn (chưa được phát biểu, hoặc đã được phát biểu ra), mình chỉ moi móc nó ra và
document lại.

Tránh trường hợp ngồi bàn với khách hàng về business của họ. Mình nói tránh thôi, chứ không phải
không được.

Bản chất của nghề BA là mang lại giải pháp cho khách hàng mà. Họ không biết thì mình tư vấn. Nhưng
mấu chốt là những buổi workshop lấy yêu cầu không phải là buổi để tư vấn. Anh em không nên tập
trung quá sâu vào chuyện tư vấn giải pháp cho họ.

Đáng lý ra, giải pháp tổng quan phải được xong ngay từ giai đoạn sales, khi team hoa tiêu đi câu dự án
về rồi.
Khi khách hàng chưa đủ sẵn sàng, hoặc thậm chí có phần hơi lúng túng khi anh em đặt câu hỏi, thì đó là
dấu hiệu cho thấy: chính họ cũng chưa hệ thống lại được bài toán của họ.

Khi đó anh em phải thật sự tỉnh táo, tránh sa lầy quá nhiều vào việc gỡ rối bài toán của họ. Mà trong khi
nhiệm vụ chính của mình tới buổi workshop này không phải zậy.

2.2. Trực quan khi cần

Nguyên tắc thứ hai khi lấy yêu cầu là anh em sẽ dùng tới những-thứ-rất-chi-là-trực-quan. Nó cũng là một
trong nhiều kỹ năng cần thiết của BA.

Trực quan là khi tui nói anh không hiểu thì tui sẽ show ra cho anh xem mất hồn chơiii.

Show thì có thể show màn hình phần mềm, show mockup hoặc show sơ đồ, diagram.

Theo đó, câu hỏi mình muốn làm rõ là: “Vì sao nó hiệu quả?”

Đầu tiên là các sơ đồ. Khi anh em show cho người ta 1 cái sơ đồ, nó sẽ mang lại những tác dụng sau:

• Làm cho pà con đỡ chán, vì mắt họ có cái để xem, đỡ buồn ngủ.

• Thu hút ánh nhìn, sự tập trung của họ lên màn hình >> chờ mình giải thích

• Mọi người được gom chung về 1 góc nhìn >> rất dễ để thống nhất 1 vấn đề khi các bên có cùng
góc nhìn.

• Thảo luận dễ hơn, vì trên diagram đã có ký hiệu (1 người nói là mọi người biết đang nói tới đâu,
cục số mấy, quy trình gì, ký hiệu ra sao…)

• Và sau cùng vẫn là quan trọng nhất, giúp mọi người hình dung vấn đề một cách rõ nét, không
còn mịt mờ như trước nữa.

Khi đã đạt được những điều trên, anh em sẽ lấy được sự confirm từ khách hàng một cách nhanh hơn,
hiệu quả hơn.

Chỗ nào cần làm rõ, anh em cứ trình bày bằng hình vẽ, highlight mạnh tay, rồi trình bày cách hiểu của
mình. Đúng hay sai, 5 giây sau là khách hàng confirm liền.

Hiệu quả vô cùng.

Anh em chỉ việc đứng dậy >> cầm bút lông >> phác thảo sơ quy trình trên bảng >> vẽ tới đâu, nói tới
đó >> nói để người ta hiểu-được-cách-hiểu-của-mình. Thì khi đó chốt vấn đề vô cùng nhanh chóng.

Chứ mà ngồi nói qua nói lại chắc tới sáng mai cũng chưa xong cái mở bài :))

Cách này có một điểm cực hay là nó là HÀNH ĐỘNG. Tức là nó sẽ thu hút mọi người hơn, tạo một chút
không khí khác biệt. Và hai bên có thể cùng tương tác, vẽ vời, thảo luận với nhau một cách dễ dàng.
2.3. Tỉnh táo khi lắng nghe

Nguyên tắc thứ ba đó là: phải luôn tỉnh táo khi lấy yêu cầu.

Dĩ nhiên BA không phải là một “thư ký” chỉ chuyên ghi ghi chép chép, deliver thông tin giữa các bên.

Ở trên mình đã chuẩn bị và có sự trực quan cần thiết khi trình bày. Vậy thì trong quá trình lấy yêu cầu,
mình phải lắng nghe thật sự kỹ càng câu trả lời của các Stakeholder.

Vì chắc chắn, sẽ không ít lần có sự bất hợp lý thông tin giữa các bên với nhau.

Anh em phải xem xét thử xem: một câu hỏi, được hỏi nhiều người, thì mình có nhận được cùng 1 câu trả
lời không? Hay nhận được nhiều câu trả lời hoàn toàn khác nhau…

Có thể mỗi người ở mỗi vị trí, bộ phận khác nhau, nên góc nhìn của mỗi người có thể khác nhau. Nhưng
về bản chất: chân lý là chân lý. Cái gì đúng, thì nó chỉ có 1 kết quả là đúng là thôi, còn cách giải thích thì
có thể có nhiều.

Ngoài ra, anh em phải chú ý xem thử câu trả lời của người đó, có dẫn mình tới một vấn đề nào
khác nữa hay không. Thường thực tế nó sẽ như thế này:

• Mình chưa hiểu vấn đề A, mình hỏi câu 1, 2, 3. Khách hàng trả lời x, y, z.

• Mình chưa hiểu vấn đề B, mình hỏi câu 3, 4, 5. Khách hàng trả lời g, h, o.

Nhưng vô hình dung, câu trả lời “h” lại làm mình thấy có 1 điều gì đó, hơi vô lý ở vấn đề A. Thế là mình
lại phải hỏi tiếp câu 6, 7, 8 cho vấn đề A’. Và nhận được câu trả lời q, w, e.

Cứ tiếp tục như thế, sau khi hỏi >> PHÂN TÍCH >> ghi nhận, mình tổng hợp lại các ý sẽ nhìn ra được bức
tranh tổng quan của khách hàng một cách chính xác nhất.

Ngoài ra, anh em cũng nên chú ý đến team nhà. Nhiều khi ở nhà nói 1 đằng, mà ra ngoài gặp khách hàng
nói 1 nẻo là hẻo lắm. Thông tin với BA là cực kỳ quan trọng, sơ suất vớ nhầm thông tin sai là tèo ngay.

Bonus anh em tấm hình xem chơi.

Nguồn ảnh từ modernanalyst.com, có bổ sung chữ tiếng Việt giữa hình.

3. Tự bốc phốt

Chém gió nãy giờ quá trời quá đất chứ thật ra mình cũng chả bao giờ chuẩn bị kỹ càng hết, chưa một lần
chuẩn bị các buổi meeting cho ra hồn. Đã vậy cũng ít khi giữ được sự tỉnh táo khi lắng nghe, vô nghe chữ
được chữ mất.

Mà nhờ có vậy mình mới lãnh đạn khá nhiều, chua có, chát có, nên giờ mình mới nhìn nhận và đút kết
được đôi điều, muốn chia sẻ với anh em.

Hi vọng anh em sẽ tìm thấy chút tia hi vong le lói gì đó sau bài viết này. Và đặc biệt là không quá bi quan,
hay nghĩ workshop lấy yêu cầu là một cái gì đó ghê gớm, dữ dội lắm. Dăm ba cái ruồi bu kiến đậu ấy mà,
muỗi hết :))

Chúc anh em gặp nhiều may mắn với 3 phương pháp trên
 X. Rốt cuộc, CRM là gì?

Credit: 123RF.com/AndrewGrossman

Hế lô a ji nô mô tô anh em. Mình đã trở lại với 1 bài viết khác, nguy hiểm và chém gió hơn xưa

Bài này mình sẽ viết về CRM, một thứ rất phổ biến trong tất cả các ngành nghề nói chung và ngành phần
mềm nói riêng.

Thật ra hồi xưa mình cũng chả hiểu CRM là gì hết. Mà hồi đó cũng chả có ai giải thích được cho mình
hiểu CRM nó là cái vẹo gì cả.

Đến khi đi làm có dịp tiếp xúc thực tế thì mới biết được bản chất nó là gì. Bài này mình sẽ share góc nhìn
cá nhân của mình về CRM, chủ yếu là cảm nhận của mình. Để qua đó anh em có thể hiểu hơn về nó, hiểu

CRM thật sự nó là cái gì

Okê, lét gô!!!

Nội dung [Hide]

• 1. CRM là Customer Relationship Management

• 2. Và ở đâu nó cũng… tồn tại

1. CRM là Customer Relationship Management

Giờ lên google search 1 phát là ra ngay: CRM tức là quản trị quan hệ khách hàng. Cái này thì ai cũng
search được, nên mình không nói lại nữa. Để bắt đầu thì anh em đọc một đống ví dụ ngay sau đây.

Một shop bán hàng online, mỗi tháng họ có khoảng 150 đơn hàng. Đâu đó trong 150 đơn hàng này là có
những khách hàng đã quay lại mua hàng của họ nhiều lần. Đó là dấu hiệu của CRM.

Cũng một shop bán giày đá banh khác. Khách đến mua cần được tư vấn về các loại giày đá banh.

Tư vấn xong, dù khách có mua hay không, shop này vẫn xin số điện thoại của khách ghé quán. Lần sau có
thông tin hàng mới về hay khuyến mãi gì thì shop sẽ nhắn tin báo. Đó là CRM.

Hoặc lâu lâu Viettel nhắn tin chúc mừng sinh nhật anh em. Đó cũng là CRM.

Shopee gửi mail báo sắp tới là sinh nhật Shopee, mời anh em ghé nhà Shopee để… mua đồ giảm giá. Đó
cũng là CRM.

Tự nhiên lâu lâu cái Mocha nó nhắn tin, kêu cài app Mocha dùng đi, tặng cho 50 phút nội mạng gọi miễn
phí. Đó là CRM.

Hay chả hiểu sao tự nhiên mấy trung tâm Wall Street, ILA nó cứ hay gọi mình lên test tiếng Anh, tiếng
Mã Lai gì đấy. Đó cũng là CRM.

Hoặc bữa mình có mua máy khoan trên Tiki, cái tợ nhiên lâu lâu lên lại Tiki thấy Tiki hỏi: “Bạn có hài lòng
với sản phẩm máy khoan ABCXYZ đã mua? Bạn có thể để lại cảm nhận của mình được hôn?”

Hoặc hôm bữa mình thấy có shop bán quà lưu niệm tổ chức minigame “xếp-hình” trên facebook. Ham
quá nhảy vào chơi, thế là được quà. Đó là CRM.

Mình có cài cái app MOMO vào điện thoại. Thấy suốt ngày MOMO thông báo hot deals, hết cái này
khuyến mãi rồi tới cái kia giảm giá. Ngày nào cũng nhận được tin. Một ngày mà MOMO không nhắn tin
cho mình thì chắc lạ lắm. Đó là CRM.

Hay đơn giản hơn. CRM là tất cả các hoạt động mình làm với khách hàng, để họ nhớ tới mình nhiều
hơn.

Giống như anh em đi cua gái vậy. Phải thể hiện tốt thì chị em mới nhớ tới mình. Bán hàng cũng vậy. Đôi
lúc bao nhiêu khách hàng mới không quan trọng bằng khách hàng cũ quay lại mua hàng bao nhiêu lần.

Một khi khách hàng đã nhận diện được mình, đã tin tưởng mình thì việc họ đến với mình để mua hàng
thì nằm trong bàn tay. CRM là một khái niệm về các chiêu thức để làm được điều này.

Tuy nhiên, các anh em hiểu tới đây thôi thì chưa đủ. CRM nó còn 1 nửa vòng tròn trước đó nữa!

Cũng là ví dụ từ một shop online khác.

Khi anh A ảnh mua sách từ FAHASA thì anh A trở thành khách hàng của FAHASA. Còn khi anh A chưa
mua sách của FAHASA thì anh A ảnh là người dưng của FAHASA.

Cái đoạn sau khi anh A ảnh mua sách và trở thành khách hàng rồi, thì chuyện chăm sóc ảnh là điều
đương nhiên.
NHƯNG,

Khi anh A ảnh đang là người dưng, không quen biết gì hết, mà đùng cái mình biến ảnh thành khách
hàng của mình thì việc này cũng được gọi là CRM.

Nó là nửa vòng tròn thường bị hiểu thiếu về CRM.

CRM không chỉ quản lý các hoạt động giữa người bán và người mua (sau khi người mua đã mua hàng).
Mà nó còn quản lý luôn các hoạt động giữa người bán và “người dưng”. Để sau một thời gian, “người
dưng” đó trở thành khách hàng của mình.

Vậy chốt lại CRM là tổng hợp các cách, các hình thức, các kỹ xảo, các tuyệt chiêu, các best practice
để: Biến một người dưng mua hàng của mình, trở thành khách hàng của mình, khiến họ nhớ tới mình
và quay lại, tiếp tục mua hàng của mình lần thứ 2, thứ 3 và lần thứ “n”.

Khái niệm nó là vậy, còn đưa vào áp dụng thì CRM nó tồn tại chủ yếu ở 3 hoạt động rõ rệt là: Marketing
– Sales – Customer Service.

Mình có một ví dụ cơ bản thường gặp nhất cho anh em. Ví dụ một shop bán hoa online.

Shop bán hoa này vừa rồi mới mua 1500 data khách hàng từ công ty bảo hiểm, từ Mobiphone, hoặc từ
một tổ chức, trường học nào đó.

Sắp tới mùa 8/3, họ sẽ chia nhau ra alo cho anh em, giới thiệu sản phẩm rồi tư vấn quà tặng vợ, tặng
mẹ, tặng bà ngoại. Hoa này thì ý nghĩa gì, hoa kia ý nghĩa gì, hoa này mua trước bao ngày, hoa kia thì
phải bỏ hộp giấy, vâng vâng và mây mây.

Từ 1500 người dưng, sau khi gọi xong họ xác định được có khoảng 850 người có vẻ hứng thú về việc
tặng hoa mùa 8/3 (có vẻ thôi nhé anh em). Đây là hoạt động Marketing.

Trong 850 người này, đội Sales của shop sẽ bắn 850 cái email về các câu chuyện ý nghĩa về việc tặng hoa
cho người phụ nữ. Rồi là đang có hot deal giảm giá, mua trước ngày 8/3 khoảng 365 ngày thì được giảm
giá 69%, ví dụ vậy. Rồi là chương trình đóng gói sẵn, tặng quà tận nơi cho đối tượng, rồi giúp khách hàng
viết những câu chúc hoành tráng nhất chẳng hạn. Đây là hoạt động Sales.

Các hoạt động này chứ dàn trải theo từng tuần, từng ngày. Trong 850 người có vẻ hứng thú, shop xác
định được có khoảng 600 người đăng ký nhận tư vấn từ shop.

Rồi từ 600 người, xuống còn 400 người đặt hàng online, 50 người yêu cầu gửi báo giá. Trước 8/3 khoảng
2 ngày, shop tổng kết họ nhận được 378 đơn hàng từ 1500 data ban đầu. Đem về doanh thu hơn 89 chai
bia sau hơn 1 tháng kick-off chiến dịch.

Sau khi thu về 89 triệu từ chiến dịch, shop bắt đầu tăng cường các hoạt động bên lề cho 378 người
khách đã mua hàng này.

Nào là gửi bản tin cách chăm sóc cây, hoa tại bàn làm việc, tại nhà. Rồi chọn hoa tặng người yêu sao cho
phù hợp. Rồi thì tặng hoa không nhất thiết chờ 8/3 hay valentine. Rồi ý nghĩa các loài hoa. Lâu lâu tổ
chức game tri ân khách hàng, tặng 10 tấm vé may mắn lên Đà Lạt nghỉ dưỡng tại Resort vườn hoa nhiệt
đới trong 3 ngày 2 đêm.
Đối với những khách đã mua hàng, hoa mua về có vấn đề gì thì shop hỗ trợ chăm sóc, giải đáp các thắc
mắc, khiếu nại nhiệt tình. Shop còn có chính sách đền bù nếu hoa bị dập trong quá trình vận chuyển
nữa.

Nhờ đó, cứ khách này giới thiệu khách khác. 378 người khách cũ đã giới thiệu được cho hơn 150 người
khác, mua hoa, và trở thành khách hàng thân thiết của cửa hàng. Đó là hoạt động Customer Service.

Tức là shop này đã dùng CRM, để biến 1500 người dưng thành 378 người khách hàng. Rồi từ 378 người
khách này, họ giới thiệu cho hơn 150 người khách khác. Đó là sức mạnh của CRM.

Rõ ràng là nếu áp dụng thành công, phù hợp với đối tượng khách hàng, phù hợp với sản phẩm và xu
hướng thị trường thì CRM là một thứ không thể thiếu đối với các doanh nghiệp.

Để hình dung rõ nhất về hoạt động CRM, anh em cứ tưởng tượng nó như 1 cái phễu (sales funnel) như
hình dưới đây.

Về cơ bản, Sales Funnel sẽ như thế này (Hình chôm từ pushalert.co)

Như hình trên, stage đầu tiên (discovery) sẽ lấy thông tin “người dưng” từ các Social Media, Website,…
Rồi tương tác với họ, rồi bán hàng, rồi theo dõi và chăm sóc khách hàng.

Các stage không nhất thiết phải như vậy.

Nó hoàn toàn có thể linh động thay đổi. Thay đổi tên cho tới cách thức vận hành, tùy vào mục đích sử

dụng của mình

2. Và ở đâu nó cũng… tồn tại

Bản chất của CRM nó tồn tại xung quanh chúng ta.
Trong cuộc sống thì ai chả cần duy trì mối quan hệ. Tạo dựng mối quan hệ đã khó, duy trì nó còn khó
hơn. Bạn bè thì nhiều mà bạn thân được tầm mấy đứa.

Nói về hệ thống CRM, thì… cũng không có nhiều cái để nói lắm :)) Nó cũng apply i chang concept như
mình chém gió bên trên. Tuy nhiên có một ý mình muốn chia sẻ thế này. Hệ thống CRM không phải là
một cái gì đó ghê gớm lắm.

Đơn giản hệ thống CRM nó chỉ là một cái tool.

Mà tool thì có nhiều loại, nhiều cấp độ, nhiều tính năng, tùy level sử dụng. Nhưng quan trọng nhất vẫn
là: sử dụng như thế nào mà thôi.

Tất cả các doanh nghiệp từ nhỏ tới lớn. Từ một cái shop online nhỏ xinh cho tới một công ty mấy nghìn
nhân viên bự chà bá lửa thì họ vẫn-đều-đang-áp-dụng hệ thống CRM đấy thôi. Đó chính là Excel!

Họ vẫn đang lưu thông tin khách hàng của họ vào Excel hết cả thôi. Làm việc và cập nhật ngay trên này.

Kể cả những form mẫu, biểu mẫu trong quá trình bán hàng cũng làm bằng Excel hết. Tức là cả thế giới
đều vẫn đang dùng hệ thống CRM, nhưng là mức sơ khởi, ở mức chỉ keep track được thông tin khách
hàng thôi. Đó là Excel.

Sau này khi lượng khách hàng đông, Excel không đáp ứng đủ khả năng. Thì họ mới tìm đến các công cụ
khác, xịn hơn, nguy hiểm hơn để dùng.

Những công cụ này không những giúp lưu trữ thông tin, mà còn tự động hóa được. Tự động gửi mail, tự
động nhận diện, phân loại khách hàng, tự động nhắc nhở Salesman.

Nói chung là tự động hết.

Các hệ thống tiên tiến ngày nay sẽ keep track hết toàn bộ các hoạt động của Salesman với khách hàng.
Từ email, phone call, fax, appointment, cho tới các buổi cà phê ngoài giờ, các hoạt động khác với khách
hàng như chạy bộ, cầu lông, tennis, đi hội thảo, abc, xyz.

Đều được các hệ thống CRM này lưu trữ lại hết, tự động hoặc thủ công, thì tùy vào tính năng của hệ
thống.
Đó là bối cảnh IT, và dưới góc nhìn của BA. Nhưng nếu nhìn qua lăng kính đời sống hằng ngày của anh
em mình thì sao?

CRM là Customer Relationship Management. Cái vế chính của khái niệm này là cụm: Relationship
Management.

Như mình nói ở trên thì mối quan hệ là một thứ rất quan trọng. Không chỉ có thời này mới quan trọng,
mà trước giờ nó cũng đã rất quan trọng rồi. Buôn có bạn, bán có phường mà.

Thiệt ra thì anh em mình vẫn luôn làm hoạt động CRM mỗi ngày đó thôi.

Lâu lâu lên facebook kiếm mấy đứa lâu ngày không nói chuyện, ping nó hỏi thăm vài câu. Hoặc lâu lâu
ngồi lọc lại danh sách friend trên facebook. Hoặc lâu lâu rủ mấy thằng bạn ra cà phê ngồi chém gió (cái

này chắc thường xuyên chứ không có lâu ). Mấy cái này chính xác là relationship management.

Mình thiết nghĩ, hiểu vầy cho gần gũi, cho đơn giản, nhưng nhận diện được cốt lõi vấn đề. Rồi áp nó vào
công việc, vào dự án sao cho hiệu quả.

Liên quan tới CRM, giờ có thể anh em sẽ bắt gặp một số khái niệm mới như CEM (Customer
Engagement Management) hoặc xRM (whatever Relationship Management).

Về bản chất thì cũng như nhau, nhưng mỗi khái niệm sẽ có một bối cảnh và mục đích sử dụng riêng.
Thường nói về CRM thì anh em sẽ hay nghe tới mấy ông lớn như Salesforce, Zoho, Dynamics 365 hay
Oracle CRM. Nhưng hệ thống thì cũng chỉ là hệ thống. Con người vận hành hiệu quả thì hệ thống phát

huy tác dụng. Và ngược lại

Bài này mình chia sẻ góc nhìn của mình về CRM, về khái niệm và các hoạt động CRM. Hi vọng anh em sẽ
thấy bài này dễ hiểu và thực tế. Có gì cần trao đổi thêm thì anh em cứ còm men phía dưới nhé.

a. CRM hoạt động như thế nào? (P1)

Credit: marketoonist.com

Hello anh em, như đã hứa thì mình đã quay trở lại một cách đầy nguy hiểm với bài detail về

CRM CRM gồm những gì, trong đó người ta làm gì, làm ra sao và làm với mục đích gì? Bài này hi
vọng sẽ giúp anh em hiểu rõ hơn về CRM.

Về bố cục thì bài này mình sẽ chia làm 2 mục lớn:

• Marketing làm gì?

• Sales làm gì?

Thật ra CRM gồm 3 modules cơ bản, là: Sales, Marketing và Customer Service. Nhưng ở chuỗi bài này
mình chỉ nói về Sales và Marketing thôi. Còn Customer Service thì anh em bấm vào link này để đọc tiếp ở
bài khác nhé.

Vì chuỗi bài nói về nghiệp vụ CRM này khá dài nên mình sẽ chia làm 3 bài nhỏ. Vì gom nhiều quá anh em
đọc nhiều sẽ ớn lắm, nên chia nhỏ ra đọc cho nhẹ nhàng.

Trong bài đầu tiên này mình sẽ chia sẻ tổng quan về CRM và module Marketing. Bài này “hơi bị dài” nên
có gì anh em bookmark lại, để dành đọc sau nếu đọc chưa xong nhé. Okay! Let’s go!!!

Nội dung [Hide]

• CRM nó có gì ở trỏng?

• 1. Marketing làm gì?

o 1.1 Quản lý các chiến dịch

o 1.2. Quản lý Marketing List

o 1.3. Quản lý phân khúc khách hàng

o 1.4. Quản lý khuyến mãi

o 1.5. Quản lý Lead

▪ a) Lead là gì?

• TÓM TẮT

CRM nó có gì ở trỏng?
Đầu tiên anh em tập trung ở cái hình trên, nó sẽ có 2 cục bự: cục Customer Relationship
Management và cục Enterprise Resource Planning. Tức là cục CRM và cục ERP. Cái này ai cũng biết. Và 4
cục xanh lè xanh léc phía trên cùng bên trái là: Social Network, Call Center, Email và Website. Bài này
viết về CRM, nhưng tại sao lại có cục ERP và 4 cục xanh lè kia?

Như mình đã nói thì không có hệ thống nào đứng 1 mình hết. Và CRM cũng vậy. Nó sẽ được tích hợp
với các hệ thống khác. Để quy trình được thực hiện chuyên sâu hơn ở từng hệ thống cụ thể. Và ERP là
cái sẽ được tích hợp nhiều nhất (nếu có). Đó là lý do anh ERP ảnh xuất hiện trong bài này. Cùng với đó là
Social Network, Call Center, Email và Website.

Quay lại với CRM, nó sẽ gồm 3 modules chính: Marketing (màu tím rịm), Sales (hường mộng mơ)
và Customer Service (xanh nhợt nhạt). Đây là 3 modules thường thấy nhất ở 1 hệ thống CRM. Ngoài ra
nó có thể bao gồm luôn cả Field Service.

Trong phạm vi bài này, mình chỉ nhấn mạnh tới Marketing và Sales thôi. Customer Service và Field
Service mình sẽ không đụng gì tới mấy ảnh hết. Mà sẽ để dành những bài viết sau, do Customer Service
cũng khá rộng, gom chung 1 đống vô đây luôn sẽ không đủ.

Ngoài ra, còn 1 điểm mà mình muốn lưu ý nữa là CRM thì có rất nhiều hãng lớn làm, như Salesforce,
Microsoft, SAP, Oracle hay Zoho. Ông nào cũng có bản cloud hết. Chưa kể mấy app CRM nhỏ nhỏ nữa.
Nhìn chung CRM thì nhiều. Nhưng bài viết này mình sẽ lấy hệ thống Dynamics 365 của Microsoft ra thị
phạm với anh em.

Anh em đừng lo là nó khác nhau. Hệ thống thì cũng chỉ là tool thôi. Mình làm cái gì và để đạt mục đích gì
trên hệ thống mới quan trọng. Nên mục đích bài này là: nghiệp vụ CRM có những gì, chứ hổng phải hệ
thống CRM làm được những gì. Hay nói cách khác là nghiệp vụ Marketing làm gì, nghiệp vụ Sales làm gì.
Nghiệp vụ Customer Service và Field Service thì để sau.

Trước khi bắt đầu, mình nghĩ anh em nên hiểu rộng ra về CRM. Toàn bộ những gì mà mình tương tác với
khách hàng (dù trực tiếp hay gián tiếp) thì đều cần phải ghi nhận lại hết, để phục vụ cho việc ra quyết
định của BOD. Hệ thống CRM sẽ giúp anh em ghi nhận những thứ này.

Bài này mình sẽ cố gắng chắt lọc những ví dụ thực tế nhất cho anh em đọc tham khảo chơi.

1. Marketing làm gì?

Bắt đầu từ một ví dụ đơn giản nhất. Bà Hai bán kem đầu ngõ, bả tự làm kem bả bán. Chi phí làm một cây
kem là 2 xèng, khách zô mua, bả bán 5 xèng, lời 3 xèng.

Càng nhiều người mua, bả càng lời. Vậy thì bả phải làm cho nhiều người biết là bả đang bán kem, kem
rất ngon. Thì bả mới nhanh giàu to được.

Bả dán quảng cáo lên cột điện. Bả nhờ thằng Tèo trong xóm vẽ dùm bả cái banner quảng cáo, bả đi treo
công viên. Rồi bả còn gọi điện cho bà con tới mua ủng hộ. Bả còn lên facebook, post bài chạy quảng cáo
liên tục. Rồi bả đi phát tờ rơi ở KTX sinh viên gần đó nữa. Nói chung là bả làm tùm lum hết.

Mà kẹt cái, những việc bả làm bả lại không follow được hết. Bả không biết là cái nào nên đẩy mạnh, cái
nào nên duy trì, cái nào nên bỏ, cái nào đang ngốn nhiều tiền của bả nhất.
Quảng cáo facebook tốn nhiều xèng quá, mà khách tới ít xịt. Chưa kể bả quảng cáo mệt thấy bà, khách
tới cũng có, mà toàn mấy đứa sinh viên. Tụi nó tới dòm quán thấy oải quá nên cũng bỏ đi. Đâm ra lại
không hiệu quả.

Đùng một cái, có 1 ông Mai Cồ xuất hiện (full name là Mai-cờ-rồ-sóp), quăng cho bả 1 cái CRM. Bả xài
thử. Ai dè sau 6 tháng, khách tới ăn đông quá trời. Sau 1 năm bả mua được chiếc Mercedez, đậu banh
chành trước nhà, để dành đi giao kem chơi.

Kết luận: Bà Hai bả vừa làm Marketing, nhưng nhờ sự hỗ trợ của hệ thống CRM, bả làm hiệu quả hơn
rất nhiều. Vậy CRM nó hỗ trợ là hỗ trợ chỗ nào?

1.1 Quản lý các chiến dịch

Lúc trước chưa có CRM, bả phải quản lý nhiều “chiến dịch marketing” cùng một lúc.

Nào là phải đi dán cột điện, ngày dán được mấy tờ cũng không biết. Rồi đi phát tờ rơi, phát ở đâu, phát
giờ nào thì hiệu quả cũng không biết. Rồi nhờ thằng Tèo vẽ banner. Trả nó bao nhiêu tiền thì hợp lý. Trả
nó 10 xèng, 8 xèng hay 5 xèng, cũng chả biết trả bao nhiêu là đủ. Rồi treo banner xong có khách hay
không thì chưa biết. Chưa đánh giá được.

Bà Hai đóng vai trò như một người Marketing Agent trong công ty client. Người này phải lên kế hoạch
các Campaign và thực thi nó sao cho hiệu quả.

CRM sẽ giúp Marketing Agent tạo chiến dịch, quản lý vòng đời chiến dịch qua các bước. Từ xây dựng kế
hoạch, phê duyệt các cấp, rồi thực thi và sau cùng quan trọng nhất là: đo lường hiệu quả. CRM sẽ giúp
bà Hai làm chuyện này.

Sau khi áp dụng CRM, bà Hai biết được: “ààààaa, thì ra là treo banner ở công viên có vẻ hiệu quả nhất”.
Vì khách của bả chủ yếu là con nít, tụi nó đến rất đông.

Bả biết được là: nếu bả đánh vô chiến dịch treo banner ở công viên, mà nơi này thì rất nhiều con nít. Mà
tụi con nít lại nằm trong phân khúc khách hàng của bả. Nên bả cứ mạnh dạn mà treo banner thêm thôi.

Quay lại với cái hình phía trên, quản lý Campaign bao gồm 5 cục chủ yếu.

Đầu tiên là làm Event. Quản lý event gì, tổ chức ở đâu, có những vendor nào, budget ra sao. Budget
phân bổ vào các hoạt động con như thế nào. Thuê bot, thuê PG, PB hết bao nhiêu xèng, abc, xyz.
Tiếp theo là Co-branding, kết hợp làm chiến dịch với nhãn hàng nào khác, nhắm đến sản phẩm nào cụ
thể. Rồi Direct Marketing hay Advertising cũng vòng vòng xoay quanh mấy mục như vầy.

Có những hoạt động nào cần chuẩn bị, ai làm, tiến độ tới đâu, plan chi tiết ra sao. Quản lý từ A tới Á
luôn. Như thằng Tèo vẽ banner khi nào xong, chi phí thuê nó vẽ là bao nhiêu tiền. Tất cả thông tin đều
được cập nhật và quản lý từ đầu tới cuối trên hệ thống.

Ngoài ra, còn một số hình về quản lý Campaign. Anh em xem chơi.
1.2. Quản lý Marketing List

Sau khi tạo ra các chiến dịch marketing rồi thì chúng ta phải… chạy nó.

Để chạy các chiến dịch này thì phải cần có đối tượng nhắm tới. Các đối tượng mà Campaign nhắm tới gọi
là Marketing List.

Marketing List có thể là một cái Lead bâng quơ nào đó (sẽ nói bên dưới), hoặc là khách hàng cũ đã mua
hàng. Khi mình chạy một chiến dịch, hệ thống CRM sẽ hỗ trợ anh em áp Campaign cho tất cả các đối
tượng trong danh sách Marketing này.

Ví dụ một email marketing quảng cáo bỉm chống ẩm baby girl thì nó sẽ tự động bắn email quảng cáo cho
hàng loạt các đối tượng là các user trên webtretho. Marketing list ở đây là danh sách các user trên
webtretho.

Một câu hỏi đặt ra để hiểu rõ Marketing List là: Các đối tượng trong list này sẽ thay đổi như thế nào
sau khi “được chạy chiến dịch”? Hay nói cách khác mục đích của việc chạy campaign là gì?

Sẽ có rất nhiều mục đích, từ giới thiệu sản phẩm mới đến giới thiệu khuyến mãi. Nhưng quy cho cùng
vẫn nhằm 2 mục đích:

• Khiến khách hàng cũ quay lại tiếp tục mua hàng

• Gia tăng lượng khách hàng mới.

Từ marketing list có hơn 500 đối tượng, sau khi chạy quảng cáo nhận được 200 lượt phản hồi. Từ 200
tiếp tục xuống còn 50. Từ 50 rút xuống được 15 đơn hàng. Bingooo! Anh em có thể xem thêm một đống
ví dụ ở đây!
Nghiệp vụ chỗ này là: anh em phải quản lý được danh sách Marketing của mình. Khi nào cần update, tự
động hay thủ công. List này dùng nhằm mục đích gì, hiệu quả ra sao, đo lường như thế nào. List kia dùng
khi nào, dùng cho loại đối tượng nào, vâng vâng và mây mây.

Các Marketing List sẽ được đính kèm với các Campaign. Hay nói cách khác là các Campaign sẽ nhắm đến
một hoặc nhiều đối tượng (marketing list) nào đó.

1.3. Quản lý phân khúc khách hàng

Ở trên mình có nhắc đến phân khúc khách hàng. Hệ thống CRM cũng sẽ quản lý cái này. Nó cho phép tạo
ra danh sách các phân khúc khách hàng. Định nghĩa ra sao. Khách hàng nào thuộc phân khúc nào. Hỗ trợ
được cả danh sách phân khúc theo kiểu static và dynamics.

Static tức là cố định, tạo ra phân khúc, nhập mô tả, điều kiện này nọ vào, rồi thêm khách hàng vào. Hoàn
toàn thủ công.

Còn Dynamics sẽ dựa vào những điều kiện cụ thể có trong segment, để tự động thêm khách hàng vào
đúng segment phù hợp. Khách hàng A thuộc phân khúc này, khách hàng B thuộc phân khúc khác.

Để tạo phân khúc khách hàng, hệ thống sẽ hỗ trợ anh em rất nhiều điều kiện lọc. Để từ đó hệ thống
chạy tự động và lọc ra những đối tượng là target audience chính xác nhất.

Ví dụ khách hàng là nam, nhà ở Sài Gòn, độc thân, tuổi từ 30 đến 40, nhân viên văn phòng,… Tất cả
những điều kiện này tạo thành một phân khúc cụ thể. Các Campaign chỉ việc nhắm tới phân khúc này để
cho ra những Lead chất lượng nhất.

Việc quản lý phân khúc khách hàng quan trọng ở chỗ: nó liên kết được với các chiến dịch và marketing
list, để tăng độ nhắm chính xác và mức độ hiệu quả của các chiến dịch. Biết người biết ra, trăm trận…
không thua mà. Chưa chắc có thắng không, nhưng không để lỗ cái đã. Ngoài ra, nó phục vụ các báo cáo
cũng rất powerful!

1.4. Quản lý khuyến mãi

Cái này nghiệp vụ thì không nhiều, nhưng làm rất mệt. Một chương trình khuyến mãi, có thể là tặng
hàng hoặc giảm giá là phổ biến.

Để ra được một mức chiết khấu ứng với một số lượng hay điều kiện đặc biệt gì đó, ví dụ mua 1,011,000
cái chén mới tặng 1 cái muỗng, thì rất công phu và phức tạp.

CRM làm được chuyện này, nhưng ở mức độ đơn giản. Chủ yếu là phần trăm khuyến mãi đi theo số
lượng sản phẩm. Ví dụ mua 500 cái ly được giảm 5%, mua 1500 cái được giảm 15%, trên 4000 cái được

giảm 30%. Hoặc tặng hàng, như mua bánh trung thu tặng bao cao su chẳng hạn

Còn lại mấu chốt ở cách tính giá, tính số lượng hàng tặng như thế nào đó sao cho có lời hoặc đảm bảo
không lỗ, phải được thực hiện bên hệ thống ERP và móc qua CRM. Chứ CRM không quản lý giá COGS
nên không thể tính toán mức giảm giá trên đây được. Và Marketing cũng không phải là bộ phận đảm
nhiệm việc tính giá Promotion.

Ngoài ra trên CRM, promotion từ master data phải được liên kết với Product và Customer. Giảm giá
theo số lượng sản phẩm, mua theo bộ sản phẩm hay theo từng khách hàng cụ thể, với từng tiêu chí cụ
thể. Phải thật sự rõ ràng.

1.5. Quản lý Lead

a) Lead là gì?

Tiếp theo sẽ là các Lead. Như mình nói ở trên thì chạy Campaign phải có mục đích. Mục đích của việc
chạy Campaign thì có nhiều, nhưng chung quy lại: nhằm tạo ra nhiều khách hàng tiềm năng nhất có
thể.

Và chất lượng của các chiến dịch chạy có tốt hay không, hiệu quả hay không, tiếp cận đúng đối tượng
hay không, phụ thuộc vào chất lượng các Lead. Hay còn gọi là khách hàng tiềm năng.
Nếu xem các chiến dịch Marketing như mồi câu, thì Lead chắc hẳn là mấy con cá rồi

Nói về Lead 1 xíu. Đây là 1 khái niệm quan trọng trong nghiệp vụ CRM. Nếu dịch Lead là khách hàng tiềm
năng thì cũng chưa chính xác lắm. Mình nên hiểu rộng ra hơn 1 xíu nữa.

Lead = specific expressions of interest

Theo Microsoft

Ví dụ tại triển lãm hàng Việt Nam chất lượng Lào, một ông khách tới gian hàng bán dao làm bếp ngó thử
xem có gì hay. Sau một loạt những đường múa dao, cắt dao sắt lẹm từ nhân viên bán hàng, ông khách
này mới trầm trồ: “Waooo, nhìn béng hết sẩy con bà bảy!!!”.

Nhân viên tiếp thị đứng đó thấy vậy, mới xin SĐT ông này về, để lần sau xin phép được tư vấn nếu có
khuyến mãi. Trong trường hợp này thì ông này có thể được xem là Lead luôn!

Thiệt ra là ông này đâu có ý định mua mua dao đâu. Ổng chỉ đi ngang gian hàng dao, thấy người ta múa
dao đẹp quá nên chui zô coi thôi.

Tuy nhiên, chỉ cần nhân viên tiếp thị thấy ổng có vẻ hứng thu với việc múa dao, chứ chưa cần hứng thú
với con dao, thì cũng được xem là một “specific expressions of interest” luôn. Chứ không nhất thiết,
Lead phải luôn là danh sách email đã subscribe, hay SĐT mua được từ Mobiphone hay một cái list cụ thể
gì đó.

Đây là khái niệm được đưa bởi Microsoft. Có câu hỏi đặt ra là: lỡ mai mốt mấy ông SAP, rồi Oracle đưa
ra khái niệm của riêng mấy ổng nữa thì sao, người nông dân biết phải nghe ai đây?
Thật ra mấy ông này định nghĩa Lead như thế nào không quan trọng. Quan trọng là khách hàng họ định
nghĩa Lead như thế nào. Họ nhiều tiền, muốn đánh bắt xa bờ thì khái niệm về Lead của họ có thể rộng
hơn so với khi có ít tiền.

Ví dụ như ông đứng xem múa dao ở trên là một Lead rất mơ hồ, rất rộng rồi. Khả năng ông này ổng mua
dao rất thấp, chưa nói được gì hết.

Còn so với một ông đã click vào đường link quảng cáo “dao giảm giá 15%” trên Google Ads, thì rõ ràng
cái ông click vô link quảng cáo ngon lành hơn rồi. Nhưng anh em cũng biết là càng detail thì càng gom
không nhiều, so với điều kiện được nới nới ra một chút.

Ví dụ một chút về dự án trước mình làm. Lead của họ rất cụ thể và rất specific. Lead của họ lấy từ nhiều
nguồn: Google Ads, Amazon, Alibaba, Email và Phone Call.

Ông nào gửi mail tới hỏi hàng hoặc phản hồi email marketing thì gom đầu vô Lead hết. Ông nào gọi tới
hỏi hàng cũng là Lead. Còn Amazon hay Alibaba, Marketing Agent sẽ lên 2 nền tảng này, scout những
cửa hàng thỏa tiêu chí, lấy yêu cầu nếu có và tạo Lead.

Trong ví dụ bà Hai bán cà rem ở trên thì Lead là mấy đứa con nít ở công viên.

Vì các Lead này được tạo ra bởi chiến dịch treo banner ở công viên của bà Hai. Tụi nó dòm banner thấy
đẹp quá, có thể có đứa tới ăn, có đứa không. Nhưng đó là những Lead rất chất lượng của bà Hai, vì bà
nhắm tới đúng phân khúc khách hàng của bà.

TÓM TẮT

• CRM bao gồm Sales, Marketing và Customer Service.

• CRM không đứng 1 mình và phải được tích hợp với ERP (nếu có).

• Marketing giúp tạo ra nhiều Lead >> nhiều Khách hàng >> nhiều tiền hơn.

• Quản lý Campaign: bây giờ người ta tự động hết rồi và các tool đều nằm trên cùng 1
platform cả.

• Quản lý Marketing List: chạy chiến dịch phải có đối tượng nhắm tới và Marketing List hoàn toàn
được tạo theo những điều kiện định sẵn.

• Quản lý Segment: giúp nhắm Target Audience chính xác và chạy Campaign hiệu quả hơn.

• Quản lý Promotion: hầu như móc từ ERP qua, CRM không phải là một bộ máy tính giá lời lãi chi
tiết.

• Quản lý Lead: tới phần này thì nhớ được Lead là gì.

b. CRM hoạt động như thế nào? (P2)

Nguồn hình: deafdelingcommercie.nl

Hello anh em. Welcome anh em trở lại với chuỗi bài về nghiệp vụ CRM. Đây là phần 2, và anh em đang

theo dõi blog Thinhnotes.com

Ở phần 1, mình đã nói tổng quan về CRM và module Marketing trong CRM nó làm những gì? Tuy nhiên
chỉ mới dừng ở Lead, mới nói Lead là gì thôi. Phần này mình sẽ tiếp tục với Lead và 4 mục tiếp theo của

module Sales

Điểm lại mục lục ở phần 1 xíu cho anh em đỡ hoang mang. Dưới đây là những gì mình đã nói.

1. Marketing làm gì?

1.1. Quản lý Campaign

1.2. Quản lý Marketing List

1.3. Quản lý Segment

1.4. Quản lý Promotion

1.5. Quản lý Lead

a) Lead là gì

Giờ anh em sẽ tiếp tục với phần 1.5, b.

Nội dung [Hide]

▪ b) Customer Journey đối với Marketing

▪ c) Lead Scoring Model

• 2. Sales làm gì?

o 2.1. Quản lý cơ hội kinh doanh (Opportunity)

o 2.2. Quản lý báo giá (Quote)

o 2.3. Quản lý đơn hàng (Sales Order)

o 2.4. Quản lý Invoice

• TÓM TẮT

b) Customer Journey đối với Marketing

Tiếp theo là 1 điểm cực kỳ quan trọng sẽ được nói rõ ở phần dưới, đó là Customer Journey.
Nôm na Customer Journey là bản tóm lược quá trình khách hàng mua hàng của mình. Chặng hành trình
từ một ông ngáo ngáo nào đó trở thành khách hàng giá trị của mình trải qua những điểm nào. Biết
được điểm này, BOD sẽ có thêm rất nhiều thông tin giá trị để ra quyết định phù hợp.

Ngày nay, người ta đang hướng tới việc auto các hoạt động Marketing và các hoạt động tương tác với
khách hàng. Là người BA, anh em nên biết được những giải pháp automation cho các hoạt động mà,
máy móc luôn làm việc hiệu quả hơn con người.

Ví dụ việc gửi email marketing, theo sát và phản hồi các chiến dịch email marketing đó như thế nào.

Ví dụ như đối với chiến dịch Email Marketing. Anh em sẽ thiết lập sẵn các “workflow” quy định các hành
động auto của hệ thống. 100% là kéo thả. Như khách hàng rep mail rồi tới bước gì nữa, họ rep mail mà
có keyword này thì sao, sau 5 ngày họ không rep mail thì sao…

Và đương nhiên, tất cả sẽ được tự động thông báo cho Marketing Agent khi có bất kỳ kết quả Lead nào
thu thập được. Không còn làm thủ công, hay phải dùng từng tool riêng lẻ trả phí hàng tháng để làm
chuyện này nữa.

c) Lead Scoring Model

Điểm cuối cùng trong phần Lead là về việc đánh giá Lead.

Hầu như đối với các hệ thống CRM hiện nay, Marketing Agent đều phải đánh giá và sàn lọc Lead một
cách… thủ công. Rõ ràng là có 2 vấn đề:

• Thứ nhất là mệt

• Thứ hai là rất mệt.

Vì nhiều quá ai làm cho nổi. Mà nhiều quá làm không nổi + mệt mỏi, sẽ dẫn tới Lead không chất lượng,
marketing không hiệu quả. Và hệ quả mà mọi người vẫn hay nói là Marketing ĐỐT TIỀN hay NÉM TIỀN
QUA CỬA SỔ.
Để giải quyết vấn đề đó, hệ thống CRM sẽ hỗ trợ anh em sàn lọc Lead một cách tự động. Toàn bộ công
việc anh em cần làm là:

• Bước 1: Define rõ ràng một cái Lead Scoring Model (tùy công ty, tùy khách hàng)

• Bước 2: Bưng nó để lên hệ thống thôi. Cũng tạo điều kiện If/ else vậy thôi. Nếu khách hàng làm
hành động A thì cho 5 điểm, làm tiếp hành động B thì cho 25 điểm, làm hành động C thì trừ đi
10 điểm. Ví dụ vậy.

Lead Scoring (nguồn ảnh: bostondigital.com)

OK, vậy là anh em đã hiểu được Lead là gì, tạo ra như thế nào. Lead có thể được xem là output của quá
trình Marketing, và là input của của quá trình Sales.
Lead – đầu nối đo lường mức độ hiệu quả giữa Marketing và Sales (nguồn ảnh: blog.insidesales.com).

Hiệu quả marketing rất khó để đo lường một cách chính xác. Một trong những best practices thường
được áp dụng là đo tỉ lệ conversion từ Lead thành Order.

CRM sẽ giúp theo dõi quá trình này chính xác và trực quan hơn rất nhiều. Lead nào đểu, Lead nào chuẩn,
sẽ lộ diện ngay!

Nói theo Phillip Kotler thì

Marketing là việc NHẬN DIỆN và ĐÁP ỨNG nhu cầu một cách SINH LỢI

Phillip Kotler

Vậy quay lại nghiệp vụ CRM nãy giờ, nhận diện là nhận diện chỗ nào, đáp ứng là đáp ứng chỗ nào?

Nhận diện nhu cầu của khách hàng, hành vi và thói quen của họ thông qua các chiến dịch như mình nói
ở trên. Họ phản ứng như thế nào với các chiến dịch, họ mong muốn điều gì qua kết quả thu thập được
từ các chiến dịch.

Đáp ứng nhu cầu của họ bằng những sản phẩm mình đang có, lại một lần nữa bằng các chiến dịch.

Chưa kể một khi hệ thống CRM được tích hợp với các Social Network, marketing có thể lắng nghe nhu
cầu của thị trường một cách tốt hơn, để từ đó nhận diện ra họ và đáp ứng được họ.

Hệ thống CRM sẽ giúp mình làm những việc này một cách khoa học và rất có tính toán. Một khi đã sinh
ra Lead, bộ phận Sales sẽ tiếp tục quy trình để “sinh lời” một cách rõ ràng nhất.

Okay, vậy là chúng ta đã đi được phần 1 (Marketing là gì?), giờ chuyển qua phần 2 nhé các anh em!
Okay, let’s gooo!!!

2. Sales làm gì?

Nhìn sơ thì anh em sẽ thấy Sales có những phần như: Customer, Product rồi Price List. Tuy nhiên mấy cái
này chỉ là phụ. Cái quan trọng mình muốn chia sẻ là những gì nằm trong phần nét đứt, từ Opportunity
đến Invoice.

2.1. Quản lý cơ hội kinh doanh (Opportunity)

Đầu tiên, Opportunity là gì? Khái niệm này ý chỉ một cơ hội kinh doanh, cơ hội bán hàng. Anh em còn
nhớ bên phần Marketing, Lead là đầu ra của quá trình Marketing, và là đầu vào của quá trình
Sales không? Khi vào quá trình Sales, Lead sẽ được dần dần chuyển hóa thành Opportunity.

Quay lại với ví dụ bà Hai bán kem.

Sau khi làm chiến dịch treo banner ở công viên khoảng 5 ngày, bả nhận được 6 cuộc điện thoại hỏi về
kem của bả. Người ta hỏi bả là kem bán sao, làm có chất lượng không, người ta muốn mua sỉ thì có giá
nào ok không? Đại loại vậy.

Thì ở đây, mình xem 6 cuộc điện thoại này là Lead của bà Hai, được tạo ra từ chiến dịch treo banner ở
công viên.

Sau khi gọi điện nói chuyện với 6 người này xong, bà Hai bả biết được rằng trong 6 người, chỉ đâu đó
tầm 4 người là hỏi để mua kem thiệt thôi. Còn 2 ông kia là hỏi tào lao.

Một ông ở nhà quỡn quá không có gì làm nên gọi điện hỏi chơi. Một ông khác thì đang tính mở tiệm kem
nên gọi điện hỏi dò la tin tức.

Đó là khi bà Hai bả nhận được 6 Lead, bả tiếp xúc với 6 Lead này (qua phone) và sàn lọc 6 Lead này
thành 4 Opportunity – cơ hội kinh doanh thực thụ của bả. Đó là Opportunity!
Bên cạnh vụ treo banner, bà Hai còn lên facebook chạy quảng cáo cho kem sỉ của bả nữa (có nói ở phần
1 đó anh em).

Sau 3 ngày chạy campaign, bả ngồi đếm bài post của bả được 69 likes, 6 comments. Tính tổng cộng sau
chiến dịch quảng cáo facebook, bà Hai thu hoạch được khoảng 81 người dùng, tương tác với bài post
của bả. 81 người này được xem là Lead của bà Hai.

Cũng giống ví dụ trên, bà Hai bả ngồi soi từng comment, soi profile từng đứa đã like bài post của bả. Đứa
nào mà bả thấy có vẻ tiềm năng, có vẻ thích ăn kem, facebook nó toàn hình ăn chơi đàn đúm với bạn thì
bả hốt cái rột, vô danh sách các Opportunity của bả luôn.

Vậy nên từ 81, sau 3 giờ “điều tra, đánh giá chất lượng”, bả lọc xuống còn 69 người hứng thú với kem
sỉ của bả. Tức là từ 81 Lead, xuống còn 69 Opportunities.

Cũng tiếp tục với bà Hai, hồi trước bả có đi phát tờ rơi ở KTX sinh viên. Tụi sinh viên thấy đang mùa hè
nóng nực, mà kem vừa gần, vừa rẻ nữa nên tụi nó gọi điện đặt hàng cho bà Hai khá nhiều.

À, trường hợp này thì tụi nó gọi điện đặt hàng luôn nhé anh em. Tức là mua kem của bả luôn.

Trong trường hợp này thì Campaign đi phát tờ rơi không tạo ra Lead nữa, mà tạo thẳng thành
Opportunity luôn, hoặc là tạo ra Order luôn. Do đó Campaign không nhất thiết tạo ra Lead, nó có thể đi
thẳng ra đơn hàng.

Nhưng trường hợp này thì hơi… hiếm.

Túm cái váy lại, Opportunity là cơ hội kinh doanh. So với Lead – khách hàng tiềm năng, thì
Opportunity đậm nét hơn rất nhiều. Một số ví dụ:

• Danh sách đăng ký email ở triển lãm là Lead. Khách hàng gọi tới mua hàng là Opportunity.

• Tài khoản Facebook đã comment là Lead. Tài khoản Facebook đã nhắn tin cho Fanpage là
Opportunity.

• Shop trên Shoppee là Lead. Shop trên Shoppee mà gửi yêu cầu báo giá là Opportuntiy.

• Khách hàng hỏi bâng quơ về 1 vấn đề mà mình có thể cung cấp giải pháp là Lead. Và nó cũng có

thể là Opportunity. Tùy mình xác định

Hiểu Opportunity là một chuyện, nhưng ứng dụng nó vào các doanh nghiệp là một chuyện rất khác.

Mỗi doanh nghiệp có những điều kiện xác định Opportunity khác nhau. Ví dụ vốn điều lệ trên 1 tỷ, văn
phòng ở miền Nam, là công ty tư nhân, hay có khả năng order trên 1000 sản phẩm, thì họ xem đó mới
thực sự là Opportunity, là cơ hội kinh doanh.

Còn có công ty khác thì đơn giản hơn. Nếu Lead mà Marketing gửi qua, Sales chỉ cần xác nhận lại đây
không phải công ty ma, thì đều được xem là Opp hết.
Khái niệm Opp rất linh hoạt. Do đó mình cần phải hiểu: Opportunity để làm gì?

Có Lead rồi có Opportunity nữa chi cho mắc công zậyyyyy? Câu trả lời là: nó đang tạo thành cái phễu
lọc rất hiệu quả!!!

Anh em muốn uống nước sạch thì phải qua cái bình lọc. Mà cái bình lọc thì nó có nhiều lớp lọc, nào là
than hoạt tính, bông, đá, vâng vâng. Lọc càng qua nhiều lớp thì nước uống càng ngon, càng sạch.

Cái phễu kinh doanh cũng vậy. Mục đích là để chắt lọc Lead thành những đơn hàng mang lại nguồn thu
thực thụ.

Như anh em thấy thông thường thì số lượng Lead bao giờ cũng nhiều hơn Opportunity hết. Tìm được
Lead rồi, nhưng để chắc chắn: HỌ ĐANG CÓ NHU CẦU MUA HÀNG CỦA MÌNH, thì anh em phải cho nó
qua một bước lọc thành Opportunity. Để rồi sao nữa? Để rồi qua lớp lọc tiếp theo, làm Quote – báo giá.

2.2. Quản lý báo giá (Quote)

Sau khi xác định Opportunity xong. Tức là xác định ông đó, bà đó có nhu cầu mua hàng của mình, chúng
ta sẽ phải chào giá cho họ, hay còn gọi là gửi báo giá. Mục đích là để họ biết giá chúng ta bán, với ngần
ấy số lượng, ngần ấy điều kiện, giá có mềm hơn được miếng nào không.

Hoạt động này sẽ nối liền ngay sau khi xác định được Opportunity. Việc quản lý các báo giá sẽ rất lộn
xộn, bừa bộn và kinh khủng nếu anh em không quản lý nó chặt chẽ.

Trước giờ các công ty không dùng CRM sẽ quản lý nó trên Excel, hoặc tệ hơn, chỉ cần keep track trên
email là đủ. Nhưng khi cần đến báo cáo thì chả biết mò thông tin đâu ra cho chính xác và đầy đủ nhất.

Việc quản lý báo giá sẽ giúp anh em trả lời được những câu hỏi “ngó bộ có vẻ hóc búa” sau:
 • Trong tuần này chào giá được mấy đơn vị rồi?

• Khách hàng họ phản hồi báo giá ra sao?

• Bao nhiêu phần trăm họ đồng ý ngay từ lần chào giá đầu tiên?

• Tương tự là số phần trăm đồng ý cho lần chào giá thứ hai, thứ ba, thứ tư?

• Nhóm sản phẩm nào bị “reject” nhiều nhất trong các lần chào giá?

• Ngược lại, nhóm sản phẩm nào có tỉ lệ “accept” cao nhất?

• Tỉ lệ win báo giá của nhân viên A trong tuần này như thế nào, khá hơn tuần trước bao nhiêu
phần trăm?

• Tỉ lệ Opportunity tạo ra một báo giá thành công là bao nhiêu phần trăm?

• Và hàng ngàn câu hỏi kiểu kiểu như vậy nữa?

Thật ra, quản lý báo giá đơn thuần chỉ là việc lưu trữ các báo giá mà mình đã gửi cho khách hàng, một
cách ngăn nắp và gọn gàng nhất có thể.

Dù cho báo giá gửi bằng email, fax, bưu điện, facebook messenger, zalo messenger hay bất cứ phương
tiện gì đó không quan trọng. Quan trọng là các báo giá này liên kết với nhau như thế nào, để từ đó, mới
có thể ra được các báo cáo trả lời được một mớ câu hỏi trên.

Tưởng tượng trong tuần gửi 45 cái báo giá qua email, 13 cái báo giá bản cứng qua đường bưu điện, 65
cái tin nhắn báo giá qua Facebook. Cái một ngày đẹp trời, sếp buồn buồn chụp đầu hỏi: “Tỉ lệ win báo
giá dạo này ổn không em?”

Câu này hơi cần tính toán chút, nhưng vẫn trả lời được.

Cái ổng hỏi tiếp: “Cái sản phẩm ‘thuốc xịt rụng lông nách’ mới ra dạo gần đây dễ bán không em? Giá cả
vậy có dễ chào giá hông em?”. Hỏi tới câu này là thấy hơi tái tái rồi.

Cái ông bơm cho câu nữa: “Gửi anh mấy cái báo giá ‘thuốc xịt rụng lông nách’ trong tháng để anh xem
nhen, để xem khách hàng họ phản hồi sao!!!”

Ái chà chà, hỏi tới câu này thì rõ ràng là xác định luôn.

Vì tháng rồi, gửi báo giá sản phẩm này cho 12 ông qua email, 40 ông qua tin nhắn Facebook, rồi 4 ông
gửi đường bưu điện lên tuốt Lào Cai. Giờ tổng hợp lại chẳng lẽ gửi nguyên đoạn chat chit với khách hàng
trên Facebook!?!?

Tới chỗ này thì CRM sẽ giải quyết 1 cái rẹt bằng cách các thông tin từ: khách hàng, sản phẩm, đơn giá
bán, giá chiết khấu, abc, xyz. Được móc ra từ master data nên tụi nó link với nhau rất rõ ràng.

Anh sếp muốn hỏi gì, là em có cái đó cho anh ngay. Mà cũng chả cần sếp phải hỏi. Sếp cứ việc âm thầm
chui vô hệ thống, xem tình hình anh em dạo này làm ăn sao, rồi chụp đầu từng thằng vô hỏi tội

thôi
Đó là ích lợi, mình sẽ nói ở 1 bài về Report sau. Quay trở lại với quy trình nhé anh em. Báo giá sẽ được
gửi qua gửi lại nhiều lần cho khách hàng. Gửi đến khi nào khách hàng và mình đồng ý thì thôi. CRM sẽ
lưu vết được báo giá này gửi lần 1, lần 2, lần 3, cho tới lần thứ “n”.

Quay lại với bà Hai một chút.

Từ 4 cái Opportunity bả có được qua điện thoại, bả chào giá hết thảy 80 lần thì được 2 người trong 4
người đó ok cái giá của bả. Còn 69 cái Opp trên facebook, bả nhắn tin báo giá cho tụi nó thì có 50 đứa
rep lại. Trong 50 đứa thì hết 30 đứa chê giá mắc quá. Còn 20 đứa chịu mua kem sỉ của bả.

Bước tiếp theo, bả sẽ làm kem và đi giao kem cho những người này. Phóng ra bối cảnh thực tế các
doanh nghiệp, họ sẽ tạo Sales Order để đánh dấu: họ đã win được Quote, và chuyển qua bước tiếp theo
– làm Sales Order.

2.3. Quản lý đơn hàng (Sales Order)

Ở bước này, bộ phận Sales sẽ tạo đơn hàng trên hệ thống CRM. Đơn hàng được quy định ở nhiều trạng
thái khác nhau.

Lúc mới tạo thì đang ở trạng thái draft. Sau khi đã sẵn sàng để giao hàng thì là Ready. Giao hàng xong
xuôi thì là Fulfilled hoặc Partial (nếu giao chưa đủ).

Nói chung trạng thái của đơn hàng có rất nhiều, và linh động theo nhu cầu của khách hàng. Linh động
theo từng giai đoạn họ muốn keep track đơn hàng của họ.

Phần này cũng không có gì nhiều để nói, nhưng mình có 2 ý muốn nhấn mạnh. Thông thường đối với 1
doanh nghiệp sản xuất B2B, sau khi chốt được đơn hàng với khách hàng, sẽ có 3 trường hợp cơ bản
nhất.

• Sản xuất rồi giao hàng cho khách.

• Lấy sẵn hàng trong kho ra giao khách.

• Vừa sản xuất, kết hợp lấy thêm hàng tồn trong kho ra giao khách.

Cũng giống như bà Hai bán kem. Khách order nhiều quá, trong tủ kem bả không có đủ thì bả phải sản
xuất thêm.

Do đó ở đây, chúng ta phải nói đến kế hoạch sản xuất và kế hoạch giao hàng.

Khi khách hàng mua hàng, một trong những dữ liệu quan trọng hàng đầu là: khi nào thì hàng được
giao? Hay còn gọi là Delivery Lead Time. Khách hàng họ quan tâm đến việc: lô hàng đó có được
giao đúng ngày như mình hứa với họ không. Chất lượng thì từ từ bàn sau.

Nếu lấy hàng sẵn trong kho ra giao thì nhanh. Nhưng nếu hàng không có sẵn trong kho thì chắc chắn
phải sản xuất mới rồi mới giao được.

Do đó hệ thống CRM làm gì làm, nhưng phải bắt được số lượng hàng tồn kho từ hệ thống ERP qua. Từ
tồn thực đến tồn ảo. Hoặc chí ít là tồn thực.
Tồn thực là số lượng hàng đó đã được book và đã ra khỏi kho hàng. Tồn ảo là số lượng hàng đó đã được
book, nhưng chưa rời khỏi kho.

Như hình trên ngay tại bước làm Sales Order, mình có vẽ 1 luồng dữ liệu tích hợp đến module Supply
Chain Management của hệ thống ERP. Tức là khi hệ thống CRM đã tạo Sales Order, và đã được confirm
tất cả mọi thứ, từ ngày giao hàng đến thông tin chi tiết trong đơn hàng.

Order sẽ được tích hợp qua hệ thống ERP.

Một nhân viên Sales sẽ nhận lệnh và tạo Delivery Plan và Production Request trên ERP.

Công việc tiếp theo về sản xuất sẽ được ERP quản lý và theo dõi. Ngay khi sản xuất xong hoặc giao hàng
xong, dữ liệu sẽ được update ngược lại CRM. Để nhân viên Sales có thể theo dõi được luồng đi của đơn
hàng. Sản xuất tới đâu rồi hoặc giao hàng tới đâu rồi.

Và anh em nhớ là tất cả các nghiệp vụ liên quan đến kho bãi và kiểm hàng tồn trong kho đều phải được
thực hiện bên ERP hết. CRM không làm chuyện này. CRM chỉ là nơi show up những thông tin đã được
kiểm tra mà thôi.

Sau khi Sales Order đã được tạo, dữ liệu từ ERP cũng được cập nhật trở lại CRM. Nhân viên bộ phận
Sales sẽ chuyển qua bước tiếp theo là làm Invoice.
Dữ liệu đổ qua đổ lại từ ERP và CRM luôn là thứ tốn nhiều thời gian và công sức của anh em!!! (Nguồn
ảnh: Brainsell.net)

2.4. Quản lý Invoice

Invoice chỉ xuất hiện khi khách hàng đã nhận được hàng, đã tiến hành làm QC lô hàng mình gửi và họ
đồng ý với chất lượng sản phẩm lô này.

Lúc này, CRM sẽ hỗ trợ làm phiếu Invoice để xác nhận rằng khách hàng đã nhận hàng theo đúng yêu
cầu và họ đồng ý thanh toán cho mình. Có thể Invoice sẽ được email cho khách hàng hoặc chuyển phát
bản cứng để họ ký.

Thực tế từ dự án mình thấy khá ít công ty làm Invoice ngay trên CRM. Đa phần họ đưa về ERP làm luôn
cho tiện quản lý.

Vòng đời mua hàng trên CRM chỉ dừng ở việc theo dõi Sales Order là đủ. Tuy nhiên, nếu làm Invoice trên
CRM, nó cũng sẽ được tích hợp qua ERP. Do đó ở hình trên, mình có vẽ mũi tên tích hợp qua module
Finance của ERP.
TÓM TẮT

• Quy trình bán hàng bắt đầu với Lead nhận được từ Marketing.

• Quy trình bán hàng cơ bản trên CRM trải qua 4 giai đoạn: Opportunity >> Quote >> Sales
Order >> Invoice

• Quy trình trên tạo thành 1 phễu lọc: Lead >> Money!!!

c. CRM hoạt động như thế nào? (P3)

Hello anh em. Chào mừng anh em quay trở lại với phần cuối của chuỗi bài viết về nghiệp vụ CRM. Vẫn
như thường lệ, mình là Thịnh và anh em đang đọc blog Thinhnotes.com.

Tiếp tục phần 1 và phần 2 bài viết về CRM, phần 3 này mình sẽ tiếp tục với 4 nội dung sau:

• Quản lý khách hàng

• Quản lý sản phẩm

• Quản lý giá bán

• Customer Journey đối với Sales

Cũng giống 2 phần trước thì mình chắc chắn phải điểm lại mục lục cho anh em đỡ hoang mang
1. Marketing làm gì?

1.1. Quản lý Campaign

1.2. Quản lý Marketing List

1.3. Quản lý Segment

1.4. Quản lý Promotion

1.5. Quản lý Lead

a) Lead là gì

b) Customer Journey đối với Marketing

c) Lead Scoring Model

2. Sales làm gì?

2.1. Quản lý Opportunity

2.2. Quản lý Quote

2.3. Quản lý Sales Order

2.4. Quản lý Invoice

Tiếp tục với phần 2.5, Quản lý khách hàng.

Nội dung [Hide]

• 2.5. Quản lý khách hàng

• 2.6. Quản lý sản phẩm

• 2.7. Quản lý giá bán (Price List)

• 2.8. Customer Journey đối với Sales

• TÓM TẮT

• KẾT BÀI

2.5. Quản lý khách hàng

Đầu tiên, bán hàng thì chắc chắn phải có khách hàng. Bán cho ông nào, bà nào đúng không?

Đối tượng khách hàng thường sẽ được chia làm 2 loại: Account và Contact. Hiểu nôm na thì Account
là khách hàng công ty, đại diện 1 tập thể. Còn Contact là khách hàng cá nhân, đại diện 1 người hoặc
là người liên hệ của một công ty nào đó.

Một Account có thể có nhiều Contact.

Một Contact chỉ thuộc 1 Account mà thôi. (Do 1 ông thì 1 lúc chỉ làm ở 1 công ty thôi. Nếu rõ ràng hơn,
thì 1 ông 1 lúc chỉ được đại diện mua hàng cho 1 công ty thôi).
Quay trở lại với ví dụ bà Hai bán kem. Một ngày đẹp trời, bà Hai bả nhận được 1 cuộc điện thoại từ ông
Sáu Quỡn hàng xóm, hỏi mua 2 hộp kem ký, mua về cho con ổng ăn. Thì lúc này bà Hai bả sẽ chui vô hệ
thống CRM, bả tạo 1 contact là Sáu Quỡn.

Sang ngày hôm sau, bả cũng nhận được 1 cuộc điện từ ông Sáu Quỡn. Có điều lần này ổng đặt tới 200
hộp kem ký luôn. Mà là ổng đặt cho công ty ổng, là công ty bán thuốc xịt rụng lông nách ở trên. Nếu anh
em là bà Hai, thì anh em sẽ dùng lại Contact Sáu Quỡn ở trên, hay tạo mới 1 Account?

CRM phân chia rất rõ ràng, khách doanh nghiệp là khách doanh nghiệp, khách lẻ là khách lẻ. Lúc này
best practice là bà Hai bả lên CRM, bả tạo 1 Account mang tên: “Công ty TNHH một thành viên Thuốc xịt
rụng lông nách”. Rồi chèn ông Sáu Quỡn vô danh sách Contact của Account này.

Ngoài chuyện phân biệt rõ Account và Contact, anh em cũng cần để ý đến chuyện Account Hierarchy
nữa. Tức là ông nào là con của ông nào, ông nào là cha của ông nào.

Các dự án mình làm thì chưa cần đến việc phân loại này, nhưng mình thấy các dự án khác anh em cũng
configure cái này nhiều. Cái này configure kỹ để sau này phục vụ báo cáo là chủ yếu và khi tích hợp qua
ERP để làm Invoice thì cũng để phân biệt rõ công ty nào mua hàng, công ty nào trả tiền.

2.6. Quản lý sản phẩm

Tiếp theo sẽ là mục quản lý các sản phẩm. Như mình nói ở mục Sales Order thì sản phẩm cần lấy thông
tin hàng tồn kho từ ERP.

Thông tin này có thể là được update ngay trên Master Data định kỳ theo một khoảng thời gian. Hoặc chỉ
cần chức năng check on-hand (kiểm tồn kho) ngay từ các transaction. Tức là lúc làm Opportunity, làm
Quote hay làm Order thì mới cần check để lấy dữ liệu từ ERP về.

Đó là chuyện tích hợp từ ERP qua. Còn về nội bộ CRM, anh em cần phải quản lý được các danh mục sản
phẩm của mình. Thế nào là Product Family, Product Hierarchy như thế nào, cấu trúc các danh mục sản
phẩm ra sao. Thông tin nào cần thiết phải được ghi nhận trên Master Data, thông tin nào chỉ cần ghi
nhận từ Transaction Data là đủ.

Ngoài ra các sản phẩm thường sẽ không đứng 1 mình, cô đơn lẻ loi lắm. Nó có thể được tạo thành
các Bundle – 1 nhóm gồm nhiều sản phẩm liên quan. Hoặc 1 bộ Kit – 1 nhóm gồm nhiều sản phẩm bổ trợ
cho nhau.

Ví dụ 1 sản phẩm anh em sẽ tạo là: “Tour du lịch Cambodia 4D3N”. Nó có thể được bỏ vô 1 cái Bundle
với tên gọi: “Cambodia Tour”, cùng với 2 sản phẩm liên quan là: “Tour ngắm plankton 30 phút” hoặc
“Tour thăm cao nguyên Bokor”.

Còn về Kit, 1 sản phẩm “Áo thi đấu Chelsea” sẽ đi kèm với bộ Kit “Chelsea 2018” cùng với 2 sản phẩm
“Quần thi đấu Chelsea” và “Vớ thi đấu Chelsea”.

Chưa dừng lại ở đó, CRM còn nguy hiểm hơn bằng việc hỗ trợ anh em Up Selling, Cross Selling,
Accessory và cả Substitute.
Sản phẩm nào là Up Selling của sản phẩm nào, sản phẩm nào là Cross Selling của sản phẩm nào. Tương
tự với Accessory, cái nào là phụ kiện của cái nào thường được bán kèm. Và cả sản phẩm thay thế
Substitute, nếu không thích kem socola của Wall’s thì còn có kem socola của Vinamilk.

Cross Selling và Up Selling (Nguồn: AgileCRM.com)

Khi anh em quy định những thứ này cho hệ thống hiểu, lần sau khi làm giao dịch trên CRM, hệ thống sẽ
tự động suggest cho anh em Sales. Để từ đó bộ phận Sales sẽ có nhiều phương án bán hàng hơn cho
khách hàng.

2.7. Quản lý giá bán (Price List)

Về quản lý giá bán, CRM sẽ hỗ trợ các bảng giá để quản lý giá sản phẩm, vào từng thời điểm và từng mục
đích khác nhau. Gọi là Price List.

Price List bao gồm những thông tin cơ bản sau:

• Thời hạn áp dụng: trong khoảng thời gian nào, bán xuyên suốt năm, hay chỉ áp dụng trong dịp lễ
Nô-en, hay chỉ để giám giá mùa Tết.

• Tiền tệ: 1 bảng giá chỉ áp dụng 1 loại tiền tệ duy nhất. Không thể nào bảng giá vừa bán Đô Mỹ
vừa bán Đô Sin được.

• Context: quy định bảng giá này phục vụ cho việc bán hàng, hay mua hàng từ Vendor hay chỉ là
bảng giá quản lý giá COGS.

• Sản phẩm: cái này quan trọng nhất, bảng giá này gồm những sản phẩm gì, giá cả ra sao.

Nói về quản lý giá cả thì cũng không gì nhiều, nhưng có 1 chỗ khá rắc rối anh em cần nắm và tìm hiểu
trước, đó là phần phương pháp tính giá. Các dự án mình làm thì cách tính giá của khách hàng cũng đơn
giản, bảng giá nói giá bao nhiêu thì bán bấy nhiêu thôi.
Tuy nhiên có 1 số khách hàng thì họ có phương pháp tính giá rất “thần thánh”. Nào là tính giá theo mức
phần trăm giảm giá, rồi giá tính luôn lời với vốn, giá chưa tính lời với vốn, nói chung CRM hỗ trợ rất
nhiều phương pháp. Anh em cứ tìm hiểu thêm nhé.

Bên cạnh đó là các chương trình khuyến mãi. Nếu sản phẩm đó, vào thời điểm đó được áp dụng khuyến
mãi, nó cũng sẽ được update từ ERP qua CRM luôn. Mà thường chức năng này được thực hiện trên từng
Transaction Data chứ không ai đưa nó vào Master Data cả.

Ví dụ khi làm báo giá, mình sẽ check xem thử: đối với khách hàng này, sản phẩm này và số lượng này có
được giảm giá không. Khi check, hệ thống ngay lúc đó mới chui vào ERP móc dữ liệu đã được tính toán,
cập nhật lên CRM cho mình.

Từ đó nhân viên Sales chỉ việc gửi báo giá cho khách hàng thôi, không cần phải mở danh sách các mặt

hàng khuyến mãi hay đi update thông tin từ đâu hết

2.8. Customer Journey đối với Sales

Ở phần cuối của module Sales, mình sẽ nói về 1 thứ, mà nó sẽ giúp anh em tóm lược lại từ đầu bài tới
giờ. Đó là Customer Journey – Hành trình từ một người dưng xa lạ trở thành một khách hàng của

mình

Toàn bộ những gì mình trình bày từ đầu bài tới giờ, đều là Customer Journey. Hay nói cách khác, CRM
giúp ghi nhận lại toàn bộ hành vi của khách hàng, từ lúc chưa mua hàng, đến khi họ đã mua hàng của
mình.

CRM giúp keep track được toàn bộ các hoạt động, từ việc gửi email, mở mail mấy lần, đăng ký form mấy
lần. Đến việc họ gọi cho mình bao nhiêu cuộc điện thoại, tham gia event được mấy lần. Hay họ từ chối
báo giá mấy lần, cụ thể các lần đó ra sao. Bên khách hàng thì ai là người contact làm việc với mình, họ có
thay đổi nhân sự không, hay xuyên suốt quá trình mua hàng vẫn là 1 người.

Những thông tin đó được CRM sắp xếp lại một cách khoa học, tạo thành 1 chặng hành trình của một đối
tượng khách hàng cụ thể.
CRM sẽ giúp anh em “theo dõi” khách hàng 1 cách đầy đủ và “auto” nhất có thể. Hoàn toàn không gây

ra bất kỳ bad experience nào cho khách hàng (nguồn ảnh: marketoonist.com)

Liên quan tới Customer Journey, một trong những thước đo được BOD quan tâm nhất khi làm CRM đó
là: tỉ lệ Lead tạo ra đơn hàng thực tế là bao nhiêu phần trăm?

Một khi câu hỏi này được trả lời một cách rõ ràng, hiệu quả công việc của Marketing và Sales sẽ được
sáng tỏ. CRM sẽ giúp chuyển hóa điều này bằng những con số thực tế!

TÓM TẮT

• Quản lý khách hàng: phân biệt rõ Account (khách doanh nghiệp) và Contact (khách lẻ hoặc
người liên hệ của doanh nghiệp).

• Quản lý sản phẩm: danh mục sản phẩm và phân loại sản phẩm là 2 thứ quan trọng nhất. Ngoài
ra cần phải tích hợp từ ERP để kiểm tồn kho (nếu có).

• Quản lý giá bán: anh em cần chú ý đến các phương pháp tính giá, ngoài ra còn phải tích hợp
được mức discount từ ERP (nếu có).
 • Customer Journey: CRM ghi nhận lại toàn bộ các hoạt động của khách hàng. Nhưng để các
data này thực sự có giá trị, BA cần phải chuyển hóa nó thành các report thật sự value với BOD.
Nội dung này mình sẽ nói ở 1 bài khác nhé.

KẾT BÀI

Những gì mình chia sẻ qua 3 bài về CRM này, phần nhiều anh em sẽ hình dung tới một doanh nghiệp sản
xuất B2B nhiều hơn. Mỗi loại doanh nghiệp sẽ có cách làm Marketing và cách làm Sales khác nhau.

Du lịch họ làm như thế nào, sản xuất nông sản làm như thế nào, tài chính, bảo hiểm, ngân hàng họ làm
ra sao, vâng vâng và mây mây. Cũng là CRM, nhưng cách áp dụng vô mỗi loại hình doanh nghiệp thì rất
nhiều.

Do đó những gì mình chia sẻ mang tính chất tham khảo cho một số mô hình doanh nghiệp nào đó,
không phải tuyệt đối toàn bộ.

Hi vọng anh em đọc bài này sẽ nắm được những gì cơ bản nhất của Marketing và Sales. Từ đó lấy
technology, lấy software (dù sẵn có hay tự build) hoặc thậm chí là lấy excel, áp một cách thật hiệu quả
vào những hoạt động Sales & Marketing. Để khách hàng có cái gì đó automation hơn, hiệu quả hơn và
tiết kiệm thời gian hơn!

Xem lại cái hình một lần nữa để tổng kết

XI. Tóm gọn các phần có trong FS?

Queo khom anh em tới với bài cuối cùng – trong chuỗi series bài viết về FS

Mình nghĩ sau khi đọc xong 3 bài trước, tâm lý anh em đang rất “bối rối” đúng hông. Vì FS có quá nhiều
phần, mà mình lại chưa hình dung rõ các phần đó xuất hiện như thế nào trong FS. Nên bài này mình sẽ
giúp anh em hệ thống lại toàn bộ nhé.

Thật ra có nhiều bạn xin mình template để viết FS. Nhưng thú thật là mình không thể share template
được.

Không phải vì mình ngại lộ thông tin dự án, mà đơn giản vì nếu làm vậy sẽ không tốt cho anh em. Thật
sự không có ích cho anh em chút nào hết.

Vì sao?

Vì nếu mình đưa cho anh em template, vô hình chung anh em sẽ rơi vào cái bẫy tâm lý “dọn sẵn”. Tức
có dự án là anh em sẽ lấy ngay template ra để fill thông tin vào. Template có gì là fill ngay vào, mà không
có chút mảy may suy nghĩ gì về nó.

Như mình đã nói thì dự án có trăm kiểu dự án, BA có trăm kiểu BA, thì FS cũng có cả trăm trăm kiểu FS.
Không dự án nào giống dự án nào. Nên anh em cần giữ được cái sense – cái nhạy bén của người làm
công việc Business Analyst khi tiếp cận dự án.

Lấy template ra xài là coi như lấy dao chém bặt cái “sense” đó của chính mình rồi.

Mình cần tiếp cận vấn đề theo hướng:

• Dự án này làm gì, có gì, và giờ cần gì?

• Stakeholder có những ai, vai trò họ là gì?

• Họ quan tâm những gì, thì chỉ cần focus vào những thứ đó thôi >> rồi cứ thế mà triển.

Mình không cần phải nhét cả đống thứ, mà ngay cả bản thân mình cũng không hiểu nó là gì vào FS. Mục
tiêu sau cùng vẫn là deliver được giải pháp phần mềm. Từ đó giúp business vận hành. Chứ mục tiêu của
BA không phải deliver 1 sấp A4 đủ các mục a bờ cờ như văn mẫu.

Nếu đã quen theo lối mòn dùng template, mà không tự tư duy sáng tạo khi viết FS. Thì càng về sau, anh
em sẽ trở thành “thợ viết” chứ không phải là “BA viết FS” nữa.

Dĩ nhiên dùng template cũng có cái lợi. Nhưng chỉ dùng khi anh em thật sự hiểu rõ tường tận các mục
trong template đó. Giống như thượng phương bảo kiếm chỉ lợi hại thật sự khi mình nắm vững công

năng của nó
Còn không nắm rõ bản chất và cách dùng, thì có cầm trong tay máy đào Bitcoin súp pơ xịn cỡ nào đi
nữa, thì cũng không được đồng nào.

“Vậy người mới nên bắt đầu từ đâu?”

Mình tin chuỗi bài notes về FS này ít nhiều sẽ giúp ích được anh em khi mới bắt đầu. Những thứ mình
viết ở đây, anh em đừng xem nó là template để copy exactly 100%. Hãy xem nó như từng món “vũ khí”
mình giới thiệu ra cho anh em.

Cứ xem chậm rãi (kiểu như đi shopping), xuy sét kỹ càng, và thử tư duy phản biện lại những cái mình
viết, xem nó có thật sự phù hợp với dự án mình đang làm hay không.

Rồi từ đó, cóp nhặt ra những món vũ khí phù hợp với mình nhất để đi chiến.

Ô kê chốt zậy nha anh em!

Mấy món này mình đã note ở 3 bài trước. Nằm trong cả 2 mục: FS kiểu truyền thống & FS kiểu Agile. Bài
này mình đóng gói lại toàn bộ cho anh em dễ hình dung nhé.

FS KIỂU TRUYỀN THỐNG

Khi gộp các phần lại, anh em sắp xếp nó như sau:

1. Overview

2. User Requirement

Kẻ bảng ghi từng UR cụ thể. Và đánh ID cho từng UR này.

3. Functional Requirement

3.1. BPMN

Anh em có thể để 1 sơ đồ BPMN high-level nhất cho toàn bộ quy trình nghiệp vụ ở đây. Rồi xuống từng
Use Case cụ thể sẽ có từng BPMN riêng nếu cần.

3.2. Use Case

Chủ yếu chỉ cần Use Case Specification. Nếu Use Case nào phức tạp thì vẽ thêm Use Case Diagram để dễ
hình dung nhé.

3.3. Business Rules

Vẽ 1 cái bảng, liệt kê toàn bộ Business Rules có trong Use Case. Nhớ đánh số ID cho từng Business Rule
nhé.

3.4. Wireframe
Anh em cũng vẽ 1 cái bảng. Rồi bỏ vào đây các màn hình wireframe (chỉ cần low-fidelity) kèm mô tả sơ
cho màn hình đó. Và nhớ có 1 cái bảng mô tả các component có trong wireframe này nhé anh em.

3.5. ERD

Phần này optional. Anh em có thể cân nhắc để nó trong Supporting Information nếu là ERD cho toàn bộ
hệ thống (thường là dự án mới). Hoặc nếu ERD theo từng phân hệ thì bỏ vào từng mục Use Case tương
ứng.

4. Non-Functional Requirement

Chia ra từng nhóm NFR. Trong mỗi nhóm NFR, anh em cũng vẽ 1 cái bảng, liệt kê toàn bộ các
requirement chi tiết thuộc nhóm NFR đó nhé.

5. Transition Requirement

Phần này nếu có thì anh em cứ mô tả y hệt như Functional Requirement là được. Tức cũng bao
gồm: BPMN, Use Case, Business Rule, & Wireframe.

Còn nếu dự án không có transition requirement gì đặc biệt thì anh em cứ mạnh dạn bỏ phần này ra khỏi
document nhé.

6. Supporting Information

Cuối cùng là tả bí lù các supporting document cần tham khảo. Lưu ý chỉ nên để cái gì thật sự hữu ích nhé
anh em. Nên cân nhắc kỹ.

Dưới đây là tổng quan các phần sẽ có trong FS kiểu truyền thống
FS KIỂU AGILE

1. User Story

User Story thì có format sẵn nên anh em cứ follow theo nhé. Cái nào không cần viết theo format thì cứ
viết theo ngôn ngữ tự nhiên như mình có note ở bài trước.

Nói về cách tổ chức thì ngay từ đầu anh em phải phân chia được hệ thống có những nhóm tính năng lớn
nào. Gom nó lại thành các EPICs. Dưới EPIC sẽ có các User Story. Từ User Story, mình sẽ break thành
các Task đủ nhỏ để “doable”.

Các Epic, User Story hay Task thì nó thuộc về phạm vi “project management”. Sẽ có các công cụ riêng để
handle việc này như Jira hay Trello.
Còn nói về tài liệu FS của BA thì có bao nhiêu User Story anh em cứ gom vào trong Backlog. Backlog có
thể là 1 trang “Backlog” trên tài liệu FS của mình. Hoặc là dùng Backlog của JIRA, Trello.

Nhưng chỉ khi chốt được các User Story cần làm trong Sprint đó, thì mình mới cần mô tả chi tiết cho
từng User Story nhé. Như: Acceptance Criteria, BPMN, hay Wireframe. Nôm na mình chỉ cần làm FS cho
từng User Story có trong Sprint Backlog thôi nhé anh em.

2. Acceptance Criteria

Với mỗi User Story thì anh em chỉ việc kẻ 1 cái bảng. Rồi list ra toàn bộ các item Acceptance Criteria và
nhớ đánh số ID cho nó nhé.

3. BPMN

Một vài User Story lớn hoặc phức tạp thì có thể anh em sẽ cần minh họa BPMN trong này. Nhưng đa
phần các User Story đều đã được break ra thành từng tính năng cụ thể. Nên thường anh em cũng không
cần mô BPMN cho từng US cụ thể đâu.

Nhưng nếu cần mô tả BPMN cho toàn bộ quy trình lớn thì mình vẫn khuyến khích anh em nên làm. Dù gì
có cái nhìn tổng quan từ đầu vẫn là tốt nhất.

4. Wireframe

Cũng như FS truyền thống thì anh em chỉ cần vẽ 1 cái bảng mô tả Wireframe, kèm mô tả các component
có trong đó nhé.

Dưới đây là tổng quan các phần sẽ có trong FS kiểu Agile

TẠM KẾT

Nhìn chung cách BA thể hiện trên tài liệu là rất rộng mở và linh hoạt. Nên đừng quá gò bó vào các
format hay template sẵn có anh em nhé.

Đều dựa trên quy chuẩn chung, nhưng tùy vào tính cách, năng lực & thái độ mà mỗi người làm BA sẽ có
một cách thể hiện FS khác nhau.

Nếu chuỗi bài về FS này quá nhiều thứ để nhớ, thì mình nghĩ anh em chỉ cần nhớ một thứ duy nhất. Đó
là mục đích sau cùng của FS. Làm sao làm, miễn FS phải: dễ đọc, dễ hiểu và team có thể thực thi được
dựa trên FS này
 XII. FS kiểu truyền thống

Hế lôôôô anh em!

Bài này mình sẽ note tiếp tập 2 của chuỗi series về viết FS nhé. Ở tập trước mình đã đi được các mục
sau:

VIẾT FS KIỂU TRUYỀN THỐNG

1. Overview
2. User Requirement
3. Functional Requirement
3.1. BPMN
3.2. Use Case
3.3. Business Rule

Tập này mình sẽ tiếp tục với anh em các phần dưới đây nhé.

Nội dung [Hide]

▪ 3.4. Wireframe

▪ 3.5. ERD

o 4. Non-Functional Requirement (NFR)

o 5. Transition Requirement

o 6. Supporting Information

• VIẾT FS KIỂU AGILE

3.4. Wireframe

Vì mình làm digital product, nên rõ ràng là không thể thiếu mô tả User Interface đúng không anh em.
Nhưng mình sẽ không vẽ UI ở đây, mà mình chỉ cần làm Wireframe thôi.

Ở các phần trước đó, mình đã cho người đọc:

• Nắm rõ tổng quan và tuyến đường dây của FS bằng BPMN.

• Cũng đã đi chi tiết vào từng tính năng bằng Use Case.

• Và cũng đã dùng Business Rules để làm sáng tỏ các tính năng đó.

Tổng quan đã có, chi tiết đã có. Giờ chúng ta cung cấp cho người đọc cái nhìn CỤ THỂ nhé anh em.

Nghĩa là mình đã có 1 nùi chi tiết bên trên rồi, người đọc cần hình dung rõ hơn: với những tính năng này,
thì user sẽ được-tương-tác-với-hệ thống như thế nào.
Wireframe sẽ giúp chúng ta thể hiện điều này. Wireframe thì anh em vẽ kiểu nào cũng được, nhưng phải
đảm bảo thể hiện được đầy đủ 2 mục sau:

• Luồng đi cơ bản của user (User Flows)

• Và cấu trúc nhóm các thông tin (Layout).

Lưu ý khi vẽ Wireframe thì anh em cũng phải MÔ TẢ nó nhé. Trên Wireframe, có bao nhiêu component
thì anh em đánh số thứ tự tương ứng vào. Rồi mình làm 1 cái bảng mô tả gồm các thông tin sau:

• ID: số thứ tự tương ứng trên wireframe

• Component: tên của component đó

• Type: là drop down list, hay là text, hay là label, button….

• Validation: mô tả các lớp validate trên front-end nếu có

• Editable: có chỉnh sửa được hay không

• Required: có required không

• Description: ghi chú các thứ khác, như diễn giải thêm ý nghĩa, default value là gì, hay tooltips
nếu có…

Làm xong phần này, anh em nên tự hỏi mình: “Vầy đã ổn chưa?”

Hãy làm bộ như mình là các thành viên khác của team, như: UI Designer, Dev Front-End, hay QC. Và
đang nhìn vào FS này, rồi tự vấn lại: để làm và test màn hình này, thì như vầy đã đủ thông tin để anh em
triển hay chưa?

Nếu còn gì lấn cấn thì rõ ràng là chưa được. Hãy tinh chỉnh lại đến khi nào anh em cảm thấy hợp lý và
đầy đủ thông tin nhất có thể nhé.

3.5. ERD

Nội dung cuối cùng anh em có thể đưa vào mục Functional Requirement đó là ERD. Phần là optional,
nên có cũng được mà không có cũng không sao nhé anh em.

Nếu có yêu cầu rõ ràng từ khách hàng về việc: Data Structure cần được thiết kế như thế nào thì việc
anh em vẽ ERD và đưa vào FS là vô cùng hợp lý. (Thường những dự án có cấu trúc DB phức tạp, thì mới
cần đưa hẳn ERD vào FS).

Nhưng nếu dự án không có yêu cầu gì đặc biệt về mặt Data Structure, thì mình khuyên anh em nên để
ERD ở riêng tài liệu Technical Specs. Vì: FS tốt nhất là hãy cứ đưa ra bài toán, còn cách làm cụ thể sẽ tùy
vào nhiều yếu tố mà quyết định.
Ví dụ cùng là 1 yêu cầu, nhưng có nhiều cách làm Data Structure khác nhau. Nếu dự án đang không
nhiều budget, hoặc team đang bị overload, hoặc timeline đang quá gấp – không thể sửa data cũ…, thì
mỗi tình huống lại có một cách tiếp cận và cách làm khác nhau.

Nên hãy để mở khoản này, để sau còn linh hoạt nhé anh em.

Ô kê vậy coi như mình đã đi qua phần 2 phần cốt lõi quan trọng nhất trong bất kỳ FS nào:

• User Requirement

• Functional Requirement

Xong 2 phần này, mình đã mô tả được đâu đó 80% những tính năng mà sản phẩm cần có rồi. Các phần
dưới đây sẽ chủ yếu tô điểm cho FS thêm rõ ràng và hoàn chỉnh nhé anh em.

4. Non-Functional Requirement (NFR)

Nói về NFR thì mình đã có 2 bài note về nó rồi. Anh em xem thêm ở đây nhé:

• Non-Functional và chuyện cái xô bể

• 23 loại Non-Functional Requirements

Với những kiến thức và trải nghiệm mình có được về NFR, hãy chỉ lượm lặt những thứ THẬT SỰ CẦN
THIẾT để đưa vào FS thôi nhé.
Tránh đưa hầm bà lằng các thứ không ăn nhậu gì với nhau vào. Hoặc nếu anh em nghĩ mình đã cover đủ
ở Business Rules rồi, thì NFR mục này không cần nữa. Nhớ nhé, FS phải rất súc tích & ngắn gọn. Cái gì

đưa vào thì phải đưa cho đáng đồng tiền bát gạo

Thường NFR sẽ dành cho:

• Những dự án có ràng buộc các tiêu chuẩn rõ ràng (như các dự án ERP, các dự án y tế, hoặc dự án
vận hành nhà máy…)

• Hoặc những dự án cần migrate toàn bộ system cũ lên system mới xịn hơn, ổn áp hơn

• Hoặc khi khách hàng có những yêu cầu rất cụ thể về các yếu tố Non-Functional này.

Phần NFR này anh em cũng làm từng mục riêng theo từng nhóm NFR nhé. Từng mục này thể hiện bảng
mô tả , bao gồm các cột: ID và mô tả NFR.

Ví dụ FS của mình có 2 NFRs rất cụ thể sau.

1. Performance Requirement

ID NFR

Đối với màn hình input: tối đa 30 trường dữ liệu, không tính toán dữ liệu phức tạp, không tương tá
NFR1-1
dung lớn như: hình ảnh, video, tệp tin quá 3MB.

Đối với màn hình output: dữ liệu được query trực tiếp từ DB, hạn chế những query phức tạp, những
NFR1-2
Hiển thị tối đa 50 dòng dữ liệu, mỗi dòng tối đa 10 cột, và mỗi dữ liệu có độ dài nhỏ hơn 100 ký tự.

NFR1-3 Điều kiện tải bình thường: 30 CCU khi không dùng cân bằng tải.

NFR1-4 Điều kiện server tối thiểu: Intel Core i5, 4GB RAM, 500GB hard disk.

2. Supportability Requirement
 ID NFR

NFR2-1 Có thể hoạt động trên platform: iOS và Android

Tương thích với hệ điều hành:

NFR2-2 • iOS: từ 8.1 trở lên

• Android: 4.4, 5.0, 6.0, 7.0**

NFR2-3 Có thể hoạt động trên thiết bị tối thiểu 1GB RAM (hệ điều hành iOS) và 1GB RAM (hệ điều hành And

5. Transition Requirement

Ô kê anh em, phần cuối cùng liên quan đến Requirement sẽ là: TRANSITION.

Ở bài 4 loại Requirement mình cũng đã note với anh em: Như thế nào là Transition Requirement? Phần
này mình sẽ tập trung nói đến: vai trò của Transition Requirement trong FS là như thế nào.

Anh em có thể hình dung: việc build phần mềm là 1 chuyện, việc đưa nó vào sử dụng thực tế lại là
chuyện hoàn toàn khác. Đây sẽ là chỗ để anh em tập hợp các yêu cầu để phục vụ cho việc chuyển giao
này.

Ví dụ có lần mình làm 1 dự án, mà trong đó có 1 tính năng chạy rất nhiều batch-job vào 2g00 sáng mỗi
ngày. Mục đích là để đổ data lên Cloud cho các hệ thống khác sử dụng.

Chỉ cần tạch 1 hôm, là ngày hôm sau các apps vệ tinh khác không get được data về là toang ngay.

Sau vài tháng sấp mặt thì cơ bản team cũng đã xong được 90% core features của hệ thống. Nhưng anh
em cũng biết là thực tế thường không êm xui trót lọt như mình tính. Thường thì sẽ có chuyện, không ít
thì nhiều. Vì rõ ràng môi trường production là thứ mà không ai lường trước được gì.

Nên team IT và team business mới thống nhất làm 1 function nhỏ cho anh Admin, để ảnh có thể can
thiệp: manually điều chỉnh hoặc refresh job transfer data vào 2g00 sáng mỗi ngày.

Nếu không thông luồng, mọi thứ sẽ bị tắt nghẽn cổ chai vào sáng hôm sau. Nên, nếu có sự can thiệp của
con người vào đoạn giữa này, mọi thứ sẽ được đảm bảo hơn.

Và tính năng này được thống nhất là chỉ kéo dài trong 5 ngày sau kể từ ngày release phiên bản đầu tiên.
Sau đó mọi thứ phải chạy tự động để tránh sai sót dữ liệu. (Và cũng không ai muốn tốn thêm 1
headcount chỉ để làm chuyện “automa-tay” này).
Do đó, Transition Requirement là chỗ để anh em mô tả những tính năng kiểu kiểu như vầy.

Sẽ có bạn dõng dạc hỏi: “Ụa anh eiii, sao mình không gom luôn zô phần Functional Requirement bên trên
zậy anh, đưa xuống đây chi cho nó dài quá xá?”

Câu trả lời là: Vì tính năng này không trực tiếp giải quyết cho bất kỳ Business Requirement nào. Nó chỉ
đơn thuần phục vụ cho việc: go-live, và chuyển giao hệ thống cũ sang hệ thống mới một cách trơn tru,
an toàn hơn mà thôi. Mục đích khác nhau, nên cần tách rời để dễ handle.

Về cách mô tả thì cũng làm tương tự như Functional Requirement nhé anh em. Cứ đi theo phương pháp
đó, cả phía Business cũng dễ hiểu, mà phía Tech cũng đủ hình dung để biến nó thành thực tế.

6. Supporting Information

Ô kê cuối cùng sẽ là phần lẩu thập cẩm. Anh em có thể gom tất cả những materials support cho các ý
bên trên vào đây. Đó có thể là:

• Bảng mô tả thuật ngữ.

• Bảng liệt kê Business Rules theo Use Cases.

• Các Meeting Minutes quan trọng (mục đích là để đảm bảo tính nguyên bản của original
problems, tránh bị tam sao thất bản qua mô tả của FS, hoặc để sau này cần thì refer lại).

• Các diagram mô tả thêm cho 1 vài đối tượng nào đó (như Sequence Diagram, Data Flow
Diagram,…).

• Hoặc anh em có thể để ERD vào đây.

Sau cùng thì các phần trong Supporting Information mục đích cũng chỉ để “easier for reader to
understand FS”.
(câu này nhấn mạnh bằng tiếng Anh nghe cho soang, nó sát nghĩa, với thêm phần nguy hiểm nha anh
em).

Ô keeeee vậy hườm hườm là mình đã hình dung được cách viết FS cơ bản nhất trong 1 dự án phần
mềm nhé anh em. Tiếp sau đây mình sẽ triển luôn cách viết FS trong các dự án Agile cho trọn bộ phun
HD nhé.

Lẹt sờ gâuuuuuuu!

VIẾT FS KIỂU AGILE

Về cơ bản thì FS kiểu Agile cũng phải show được các ý như khi anh em làm FS truyền thống. Nhưng
nó thể hiện theo một cách khác.
Vì tính chất của các dự án Agile là rất linh hoạt. Thường Requirement sẽ bị thay đổi hoặc làm mới rất
nhiều. Hoặc dự án cần phải roll-out rất nhanh để đáp ứng cho cả ti tỉ thứ: business changes, get user
feedback, đạt KPI khỉ khô nào đó, hoặc đơn thuần là đi theo một campaign đâu đó từ trên trển rơi
xuống…

Do đó, cách anh em BA mình làm FS trong các dự án mô hình kiểu này cần phải khác đi đôi chút. Nhưng
mục tiêu sau cùng là vẫn đảm bảo FS được súc tích & cô động. Nhưng có thể linh hoạt điều chỉnh bất cứ
khi nào.

Nếu FS truyền thống tiếp cận theo hướng Use Case, focus nhiều vào việc: tương tác của các Actor lên hệ
thống như thế nào. Thì FS kiểu agile tiếp cận theo góc nhìn User Story, tập trung hoàn toàn vào đối
tượng End-Users.

Gốc rễ của cách làm này đều bắt nguồn từ End-Users. Như nào? End-users sẽ kể ra nhu cầu mà họ cần
được giải quyết. Từ đó, anh em tập trung khai thác & phân tích vấn đề dựa trên đề bài này.

Mình sẽ đối chiếu cách viết FS kiểu Agile với kiểu truyền thống cho anh em dễ hình dung. Tạm gọi:

• T là FS kiểu Truyền thống

• A là FS kiểu Agile

Nếu Overview có trong T, thì thường phần Overview này sẽ không có trong A.
Nó sẽ được cover ở 1 loại document khác (có thể là Business Case, Proposal,…)

Nếu User Requirement có trong T, thì ở A nó lại tồn tại dưới dạng User Story.

Nếu Use Cases & Business Rules có trong T, thì ở A nó thể hiện dưới dạng Acceptance Criteria

Nếu BPMN & Wireframe có trong T, thì ở A vẫn là BPMN & Wireframe.

XIII. BA viết User Story?

Hế lô anh em!

Đây là bài thứ 3 trong chuỗi series bài notes về FS. Nếu anh em nào chưa đọc 2 notes trước thì hãy dừng

lại & đọc ngay để không bỏ lỡ bất kỳ thông tin nào nhóe

• BA viết FS như nào?

• FS kiểu truyền thống

Ở 2 phần này mình đã cùng nhau đi rất chi tiết về:

VIẾT FS KIỂU TRUYỀN THỐNG
1. Overview
2. User Requirement
3. Functional Requirement
3.1. BPMN
3.2. Use Case
3.3. Business Rule
3.4 Wireframe
3.5 ERD
4. Non-Functional Requirement
5. Transition Requirement
6. Supporting Document

VIẾT FS KIỂU AGILE

(Mới mở đầu về cách viết theo User Story…).

Nên tiếp theo đây mình sẽ đi chi tiết vào cách viết User Story & các phần liên quan nhé.

Nội dung [Hide]

• 1. User Story

o 1.1. <User> là người

o 1.2. Viết dạng chủ động & tránh mang hình ảnh “system” vào

o 1.3. Benefit không nhất thiết chỉ hướng tới User

o 1.4. Không phải lúc nào cũng áp dụng format

o 1.5. Ai viết User Story

• 2. Acceptance Criteria

o 2.1. Mỗi AC đều phải test được

o 2.2. Phải ghi RÕ RÀNG, chính xác, và dễ hình dung

o 2.3. Không mô tả chi tiết về technical

o 2.4. Ai là người viết Acceptance Criteria

• 3. BPMN & Wireframe

1. User Story

Cách viết User Story chắc cũng quá quen thuộc với anh em rồi, nên mình đi sơ qua thôi. Nôm na nó có
dạng:
Một vài ví dụ cho anh em dễ hình dung:

1. As a rider, I want to choose my favorite driver, so that I feel enjoyable and safe in my ride

2. As a system admin, I want to configure recruitment criteria, so that I can control recruitment
quality

3. As an engineer, I want to scan the Barcode of the laptop, so that I can enter data more
accurately and faster

4. As a reader, I want to cancel my subscription at any time, so that I do not lose money
unintentionally

Căn bản thì User Story không khác gì User Requirement. Nhưng so với User Requirement, thì User Story
được gói gọn trong một tính năng rõ ràng mà người dùng cần. Đâu đó nó mang lại cảm giác gọn
gàng, có tổ chức và dễ quản lý hơn rất nhiều. Đặc biệt trong những dự án có tính biến động cao.

Tuy nhiên mình cũng có vài lưu ý cho anh em khi viết User Story.

1.1. <User> là người

<User> ở đây nên là NGƯỜI thực tế. Khác với Use Case, Actor có thể là Human hoặc System. Nhưng
<user> trong User Story phải là người.

Vì sao?
Vì tiếp cận theo hướng User Story, là anh em đang setup mindset: lấy gốc ra làm người dùng, à
nhầm, lấy người dùng ra làm gốc. Các giải pháp đưa ra đều nhằm mục đích giải quyết vấn đề của người
dùng, chứ không chỉ đơn thuần là làm tính năng cho system.

Cụm từ “giải quyết gốc rễ vấn đề của user” nó khác hoàn toàn cụm “làm tính năng cho system” nhé anh
em.

Làm cho system có tính năng đó, không có nghĩa là đã giải quyết được triệt để vấn đề của user. Mà chỉ
khi mình suy nghĩ và phân tích tới tận cùng cái pain-point mà user đang gặp phải, thì khi đó mình mới đủ
mường tượng được tính năng này có giải quyết được pain-point đó hay không.

Nó là cách suy nghĩ “user-oriented”. Là cái mà anh em mình nên lưu tâm khi phân tích bất cứ tính năng
nào.

Có nhiều tính năng khi làm FS, anh em chỉ mới hình dung về nó thôi. Dù có phân tích kỹ đến cỡ nào,
nhưng nếu chưa có trải nghiệm thực tế & suy xét kỹ càng, thì tất cả cũng chỉ là mường tượng của mình
cho đến khi tính năng đó được thành hình thực tế.

Nhiều lúc cứ nghĩ: tính năng này đã ổn áp, đã giúp giải quyết vấn đề của user rồi. Nhưng khi deliver ra,
tận tay test, tận tay trải nghiệm thì mới thấy có gì đó lấn cấn, cợn cợn mà khó có thể giải thích được.

Nên nếu từ đầu không đặt mình vào tâm thế của User, thì rất khó để hiểu và giải quyết vấn đề một cách
hoàn chỉnh được. Nên ngay từ đề bài, User Story cần phải có “yếu tố con người” trong đó nhé anh em.

Ví dụ có lần mình làm tính năng “Global Search” trên trang chủ cho một website.

Search thì rõ ràng anh em phải mô tả cụ thể là search trên những object nào đúng không. Và khi search
ra kết quả thì team Development gặp 1 technical issue là: khi user bấm vào kết quả thì có 1 vài trang vì
build theo công nghệ cũ, nên không redirect đến trang chi tiết của kết quả tìm được. Mà chỉ đi được
đến trang danh sách các sản phẩm bên ngoài là hết xí quách.

Lúc này team mình đang focus nhiều vào cơ chế search để đảm bảo trải nghiệm người dùng sẽ được tốt
nhất. Nào là: search partial theo keyword như nào, hỗ trợ search có dấu/ không dấu như nào, rồi cách
kết quả được hiển thị có đủ thông tin cần thiết hay không….

Vì quá focus vào các cơ chế search này, nên khi technical issue bên trên được raise, mình nghĩ cũng chả
sao, và nghiễm nhiên ô kê với hạn chế này.

Đến hồi release ra để test, vô chính tay mình trải nghiệm thì mới thấy má ơi nó chuối. Mục đích user cần
search là: để họ đến được chính xác nơi họ cần đến. Và cái họ cần là đến trang chi tiết của sản phẩm.
Mà đằng này mới đưa người ta tới trang danh sách bên ngoài là đã đem con bỏ chợ rồi.

Đây chính xác chỉ là một trong những tính năng “trông có vẻ ổn”, nhưng sau cùng thì chỉ giải quyết được
NỬA VỜI vấn đề của người dùng.
Nên mới thấy, khi chạy dự án, biết bao nhiêu thứ cần phải suy xét. Nên nhiều khi, thứ cơ bản nhất mình
lại vô tình bỏ qua. Nếu không thường xuyên đặt mình vào tâm thế của End-User, thì chắc lỗi lầm bên
trên phải lặp lại cả sớ dài.

Do đó, mục đích của viết User Story là để anh em hình dung tường tận vấn đề. Và luôn nhắc nhở mình
phải “mang đôi giày” của chính end-user nhé anh em.

1.2. Viết dạng chủ động & tránh mang hình ảnh “system” vào

Này cũng là một mẹo mình muốn share với anh em.

Khi viết thì anh em phải viết theo hướng chủ động: là user chủ động, user cần cái này, cái kia, là một nhu
cầu có thật, khẩn thiết, và cần mình giúp họ giải quyết vấn đề này.

Nghe nó thôi thúc và tích cực hơn đúng không anh em.

Còn tránh mang hình ảnh “system” vào là sao? Là mình chỉ nói theo ngôn ngữ của user: User cần gì mà
thôi. Chứ không nói theo ngôn ngữ System có thể offer được gì cho user.

“System offer được gì cho user” là Solution Space.

Còn nói theo “User cần gì” là Problem Space.

Mình viết User Story thì chỉ nói trên Problem Space, đưa ra bài toán cần giải quyết rằng: tui đang bị zầy
nè & tui đang muốn cái này. Mình không cần, không cần & không cần đưa ra solution chi tiết ở đây nhé
anh em.

Hai lỗi này thường đi chung 1 cặp với nhau:

• US ổn áp: “Là nhà tuyển dụng, tôi muốn nhận thông báo về lịch hẹn phỏng vấn trước 2 ngày,
để tôi có thời gian chuẩn bị phỏng vấn”
(thông báo có thể qua email, SMS, zalo, in-app…, khi vào sâu phân tích sẽ biết thông báo qua
đâu là tối ưu)

• US cần tránh: “Là nhà tuyển dụng, tôi muốn hệ thống bắn noti trên app về lịch phỏng vấn
trước 2 ngày, để tôi có thời gian chuẩn bị phỏng vấn”
(Lỗi 1: Chưa gì đã muốn nhận thông báo trên app, trong khi chưa chắc đây đã là phương án tối
ưu khi chưa qua phân tích.
Lỗi 2: Nói theo góc nhìn “system offer được gì” – cái cụm “hệ thống thông báo trên app” vô hình
dung đã khóa cái đầu mình lại, không nghĩ thoáng ra được. Nếu lỡ system này củ chuối, không
thể gửi thông báo trên app thì sao?!?!
Nên mình chỉ cần tập trung vào Problem Space thôi nhé anh em).

1.3. Benefit không nhất thiết chỉ hướng tới User

“As a” <user> thì không nhất thiết “so that” phải là <benefit của user>
Nghĩ thoáng ra một chút thì benefit anh em có thể ghi bất cứ thứ gì, miễn:

• Nó là benefit thật sự (để cung cấp được chính xác context của requirement này)

• Và nó có thể là benefit của end-user hoặc là benefit của customer

Ví dụ: Mình đang làm 1 cái app giúp các kỹ sư tìm đường tới tận nhà của khách hàng để sửa & thay thế
linh kiện laptop theo các booking.

Sau khi hoàn tất công việc, anh kỹ sư có thể nhấn 1 nút để gửi thông tin thanh toán qua Momo cho
khách hàng. Để khách hàng tiện lợi thanh toán hơn. Tránh phải lui cui lấy đủ tiền mặt ra thanh toán ngay
lúc đó, rồi thối tiền tới lui mắc công.

Như vậy thì với Requirement mới này, mình sẽ viết dưới dạng User Story như sau: As an engineer, I
want to share payment information via Momo to customers, so that THEY can pay more conveniently.

Benefit ở đây là benefit của khách hàng, chứ không nhất thiết phải là benefit của anh engineer (là

user) nhé anh em

1.4. Không phải lúc nào cũng áp dụng format

Một ý nữa là không phải lúc nào mình cũng răm rắp làm theo: As ABC, I want XYZ, so that 123 blah
blah…. Với vài thứ đơn giản thì chỉ cần ghi huỵch toẹt nó ra là được.

Ví dụ Apple vừa ra mắt iOS 15, theo đó là app mình cũng cần phải check impact và nâng cấp để có thể
work tốt với iOS 15. Đây là một yêu cầu mới toanh. Nếu viết Requirement theo format User Story thì sẽ
như sau:

“As a user, I want my app work smoothly on iOS 15, so that I…..không bị bug khi sử dụng hả” (thiệt
mình cũng không biết ghi chỗ này sao…)

Gác format qua 1 bên. Câu trên được diễn giải gọn gàng – súc tích bằng đúng 1 dòng: “Check impact &
upgrade app to iOS 15”. Bùmmmmm, xong, ez game!!!

Vì sao?

• Vì ngữ cảnh này đơn giản, quá dễ hiểu đúng không anh em.

• Requirement này cũng rất hiển nhiên và chẳng có gì lạ lẫm (mình cũng làm i chang như khi
upgrade từ iOS 13 lên iOS 14 vậy)

Do đó, sẽ có những requirement tương tự – khá là rõ ràng & hiển nhiên. Thì khi đó anh em hãy cân nhắc
nên viết sao cho tối ưu nhé. Linh hoạt là chia khóa, đừng lúc nào cũng khư khư theo template, theo
format. Nếu không thì…

1.5. Ai viết User Story

Phần này cũng nhiều anh em hay hỏi mình. Như bên trên mình nói thì User Story nó như User
Requirement vậy. Nhưng được đóng gói ngăn nắp trong một format rõ ràng và dễ quản lý.

Nếu dự án chạy theo SCRUM hoặc các framework tương tự thì Product Owner sẽ là người viết. Product
Owner có thể đến từ các bộ phận Business hoặc IT.

Còn nếu không có Product Owner, thì BA sẽ là người viết User Story. Và cũng từ User Story đó, BA cùng
team sẽ phân tích & thiết kế giải pháp tương ứng về sau.

Ô kê anh em, vậy coi như mình đã đi qua về User Story.

Nếu phần này trả lời cho các câu hỏi Who, What, Why, thì phần dưới đây sẽ trả lời cho How. Đó
là Acceptance Criteria.

2. Acceptance Criteria

Phần Acceptance Criteria này tương đương với Use Case & Business Rules khi anh em viết FS kiểu
truyền thống. Nhưng cách thể hiện của nó thì đơn giản hơn.

Đơn thuần mình chỉ cần: 1 cái bảng & liệt kê toàn bộ các Acceptance Criteria thuộc User Story đó là

xong

Nói nghe easy game vậy chứ phần này làm khá tốn máu nhé anh em. Làm FS kiểu Agile ăn tiền là ở chỗ
này.

Chắc anh em sẽ có câu hỏi: Use Case thì có format, Business Rules cũng đơn thuần là note ra các rule của
tính năng đó. “Vậy giờ kêu ghi Acceptance Criteria tương đương Use Case với Business Rules là ghi sao
chaaaaa?”

Thì câu trả lời sẽ là: cứ liệt kê các Rules của User Story ra là được.

Cách tiếp cận này là mình đang làm theo hướng “rules-oriented”. Vì mình thấy đây là cách viết
Acceptance Criteria một cách tự nhiên và dễ kiểm soát nhất.

Rules như thế nào thì cũng tương tự Business Rules mình có note ở 2 bài trước. Nhưng nhìn chung,
Acceptance Criteria (AC) của anh em phải đảm bảo được 4 yếu tố sau đây.

2.1. Mỗi AC đều phải test được

Cái tên Acceptance Criteria đọc thôi là hiểu ngay ý nghĩa của nó đúng không anh em. Đây là những tiêu
chí cần có để User Story được “accept”.

Mà ai cần “accept” User Story? Như ban đầu mình có nói thì FS dành cho 2 đối tượng đọc: phía
Business & phía Tech. Vậy nên Acceptance Criteria mình cần ghi sao để cả 2 đối tượng này đều HIỂU và
TEST được.
Phía Business đơn cử là những key-users, hay project cordinator.

Khi sản phẩm được release, họ sẽ dựa trên những gì mình viết ở Acceptance Criteria, để test xem thử hệ
thống có chạy đúng như mô tả hông. Dĩ nhiên là trước đó họ cần agree với những gì mình viết. Để đảm
bảo AC đã mô tả đúng với kỳ vọng của họ.

Còn phía Tech là những anh em QC, Dev, hay Designer.

• Dev hay Designer cần đọc Acceptance Criteria để break task và dựa vào đó để làm.

• QC thì cần đọc Acceptance Criteria để biết đường viết và chạy Test Case.

Do đó mỗi thứ được ghi ở Acceptance Criteria đều phải được LƯỢNG HÓA rõ ràng. 5 ký tự thì ghi rõ 5
ký tự. Flow đi từ A đến B như nào thì phải mô tả rõ. Hoặc có rule hay công thức tính toán phải viết thật
cụ thể nhé anh em.

Tuyệt đối: không cảm thán, không định tính trong Acceptance Criteria. Như kiểu: “Màn hình claim điểm
phải được làm tuyệt đẹp và đầy đủ thông tin. User chỉ cần vài ba cú nhấp chuột là đã claim thành công”.

Ối zồồồi ôiiiiii

Tuyệt đẹp là tuyệt đẹp xaoooo? Đầy đủ thông tin là đầy đủ như nàoooo? Rồi “vài ba” cú nhấp là ba hay
bốn?

Viết như vậy không ai test được hết. Viết như vậy là tạch Acceptance Criteria, và tạch luôn cả User Story,
tạch luôn cả dự án. Viết vầy sớm muộn gì anh em cũng bị chém thôi nên…

2.2. Phải ghi RÕ RÀNG, chính xác, và dễ hình dung

Cái này thì quá hiển nhiên rồi. Xuyên suốt chuỗi bài về FS này mình luôn lặp đi lặp lại ý này. Cốt cũng chỉ
để anh em nhớ nằm lòng nguyên tắc vàng này thôi.

Viết FS kiểu Agile mà chỉ có cái User Story không thôi thì chưa bao giờ là đủ. Nó như cái mở bài vậy. Mở
bài anh em viết có khúc chiết đến cỡ nào. Mà thân bài nó dàiiiiiiii lêêêêê thêêêêê thì cũng không ổn.

Acceptance Criteria chính là thân bài. Nó nó cái ruột, là cái bo đỳ của cả FS. Nên bằng mọi cách, phải giữ
cho nó đơn giản và dễ hiểu nhất có thể. Để ai cũng có thể tiếp cận nhé anh em.

2.3. Không mô tả chi tiết về technical

Dĩ nhiên rồi, vì FS còn có cả business users đọc nữa, nên “keep it as simple as possible”. Thường mình
thấy điểm này hay gặp ở các anh em trước làm Dev xong chuyển qua BA. Nên đôi phần nhìn vấn đề sẽ
hơi thiên về lăng kính technical.

Điểm này mình nghĩ cũng không quá to tát. Chỉ cần khách hàng hay anh em góp ý, rồi thay đổi dần là
được.
2.4. Ai là người viết Acceptance Criteria

Câu trả lời là team dự án nhé anh em. Cụ thể hơn là BA, sau một loạt những nỗ lực lăn, lê, bò, trườn,
phân tích, thiết kế, đổ máu & nước mắt, BA sẽ là người “đứng mũi chịu sào” viết Acceptance Criteria.

Có vài anh em hay nhầm lẫn là Product Owner là người viết Acceptance Criteria. Ý này vừa đúng, vừa
không.

• Nếu project chạy theo SCRUM (hoặc các framework tương đương) định nghĩa được role Product
Owner rõ ràng. Và cái anh PO này work được với Development Team. Thì khi đó Product Owner
mới là người viết Acceptance Criteria và chịu trách nhiệm sau cùng.

• Các trường hợp còn lại (prj không hoàn toàn áp dụng SCRUM, hay Waterfall triệt để) mà có role
BA, thì anh BA này phải là người làm Acceptance Criteria.

Sau cùng, PO hay BA thì cũng chỉ là title. Câu chốt đơn để anh em hình dung rõ nhất là: Người làm-công-
việc-Business-Analyst sẽ là người chịu trách nhiệm cho Acceptance Criteria.

Nhưng rõ ràng BA không phải là người duy nhất được viết Acceptance Criteria. Mà là cả Development
Team phải cùng trao đổi và đưa ra ý kiến để input vào AC.

Bắt đầu 1 quan điểm, BA sẽ trình bày và khơi mào thảo luận cho anh em.

Dev có thể bàn về cách làm. Các technical spike có thể gặp phải. Nói về system performance, scalable,….
và hàng ti tỉ thứ khác có thể được đem ra mổ xẻ. Còn QC sẽ share góc nhìn về logic hay các góc khuất
nhìn từ khía cạnh testing.

Từ đó, gom góp lại toàn bộ, Business Analyst sẽ là người đóng gói cuối cùng và đưa lên FS dạng
Acceptance Criteria. Cứ vậy triển cho từng User Story một.

Như vậy anh em có thể thấy:

• Cả Development Team (bao gồm cả BA) là người RESPONSIBLE cho việt làm Acceptance Criteria

• Nhưng BA lại là người ACCOUNTABLE cho Acceptance Criteria.

Anh tham khảo thêm mô hình RACI nhé

Và ý cuối cùng là anh em nên chia Acceptance Criteria theo từng tính năng nhỏ có trong User Story. Rồi
viết theo từng mục như đã chia. Làm như vầy, mình sẽ dễ hình dung từng vấn đề một. Đảm bảo các khía
cạnh đều được cover, và tránh bị sót.

Ô kê lý thuyết nhiều quá, dưới đây mình sẽ show cho anh em vài ví dụ tham khảo cụ thể nhé.
Dự án này mình viết bằng Tiếng Việt nên phần nào cũng dễ viết, dễ đọc & dễ hiểu hơn so với Tiếng Anh
nên show cho anh em. Xem qua nếu có concern hay thắc mắc gì thì cứ comment bên dưới cho mình
nhé.

3. BPMN & Wireframe

Ô kê nội dung sau cùng của FS viết theo kiểu Agile này cũng chính là BPMN và Wireframe. Phần này thì
nội dung tương tự như FS kiểu truyền thống nên anh em xem tham khảo lại các bài trước đó nhé.
+ Ngoài lề:

I. Muôn nẻo đường BA (P1)

Hế lô ajinômôtô anh em. Bài này mình sẽ nói đến một vấn đề khá rộng, nhưng lại được rất nhiều anh em
quan tâm. Đó là các loại hình công ty mà BA có thể làm. Hay cụ thể hơn, công việc BA “tồn tại” ở
những vai trò nào.

Thời gian qua cũng có nhiều anh em gửi mail hỏi mình vấn đề này. Nhân dịp cuối tuần, mình sẽ overview
lại cho anh em có cái nhìn tổng quan luôn.

Ô kê. Lét gâuuuu!

Nội dung [Hide]

• 1. Một câu chuyện hư cấu có thật

• 2. Muôn nẻo đường BA

• 3. Công ty Product | Product Owner?

• 4. To be continued
1. Một câu chuyện hư cấu có thật

Gần nhà mình có ông Hải chuyên xe ôm.

Ông Hải này chạy xe ôm nổi tiếng vui tính, tốt bụng và có “quan hệ cực kỳ rộng”. Ổng có trong tay cả
trăm anh em xe ôm, phủ sóng khắp mọi ngóc ngách Sài Gòn.

Tuy nhiên, thời buổi Uber, Grab hoành hành loạn lạc, ổng cũng muốn có chút gì đó thay đổi. Một phần
để bắt kịp xu hướng thời hiện đại. Phần khác là để quản lý đội ngũ anh em xe ôm tốt hơn.

Ổng nghĩ ổng cần một cái gì đó, có thể giúp ổng quản lý tốt tuyến đường của các anh em, quản lý thông
tin cá nhân, cũng như lương lậu của các anh em tài xế.

Thế là ổng liên hệ ông Sáu Bảnh xóm trên, trước chuyên sửa win dạo, giờ chuyển sang làm giải pháp
phần mềm.

Ông là chủ tịch của tập đoàn Sáu Bảnh Gờ-Lâu-Bồ (Global), chuyên phát triển và triển khai các giải pháp
phần mềm, có trong tay hàng trăm kỹ sư khủng.

Ông Sáu Bảnh nói: cần phải có một hệ thống, áp dụng vô việc quản lý đội xe, có thể tạm gọi là hệ thống
“Self-Governing Motor Ôm”, nghĩa là Biệt đội xe thồ tự quản.

Vì để gọn nhẹ, và có thể nhanh chóng đưa vào áp dụng, ông Sáu Bảnh đề xuất sẽ triển khai hệ thống này
dựa trên một hệ thống sẵn có, mang tên Dynamics 365 for Ôm của Microsoft.

Trong team dự án của Sáu Bảnh Global có một anh BA tên Mai-cồ Tom.

Sau bốn tháng làm việc quần quật giữa anh Mai-cồ Tom và công ty Hải Motor Ôm, hệ thống cuối cùng
cũng go-live thành công. Ông Hải cùng đồng bọn chạy hệ thống vèo vèo, ngon lành cành đào.

Tuy nhiên khoảng 1 năm sau, nhiều thứ bắt đầu thay đổi.

Ông Hải thâu nạp thêm nhiều xe ôm mới, hệ thống bành trướng, và cũng cần bổ sung thêm một số chức
năng.

Các quy trình cũng trở nên phức tạp, và thay đổi liên tục. Không phải làm ngày một ngày hai là xong. Nên
Hải CEO mới quyết định thuê nguyên một đội IT vào để quản lý hệ thống Self-Governing Motor Ôm, sẵn
tiện phát triển thêm các tính năng mới.

Thành phần tuyển vào có 3 người: 2 anh Developer Full Stack và 1 chị BA, tên Tủn.

Chị Tủn hằng ngày có nhiệm vụ nhận các yêu cầu phản hồi của tài xế xe ôm, cũng như các bộ phận khác
về tính năng của hệ thống. Cái này cần cải thiện, cái nào cần phát triển thêm. Chị Tủn sẽ phân tích các
yêu cầu này, sau đó trình xếp Hải và estimate, rồi thực hiện.

Mọi thứ phát triển rất tốt, nhưng rồi…

Sau 4 năm phát triển như một tập đoàn xe ôm hùng mạnh nhất nhì Sài Gòn, ông Hải mới quyết định
thay đổi cách vận hành, tạo một cú sốc lớn trong làng xe ôm nước nhà.
Ổng quyết định sẽ tung ra app điện thoại, giúp kết nối hành khách đi xe ôm và tài xế xe ôm.

Thế là một lần nữa ông Hải phải liên hệ tập đoàn Sáu Bảnh Global để làm. Vì đội IT của ổng không đủ sức
để build một phần mềm chuyên dụng như vậy.

Nói về làm Mobile App thì Sáu Bảnh Global tự tin mình là số một. Lúc demo, Sáu Bảnh show hàng loạt
các tính năng khủng. Ông Hải thấy vậy khoái lắm, vỗ đùi phành phạch. Hỏi giá thì cha Sáu Bảnh hét lên
tới gần 1 tỉ. Mắc quá không có tiền làm, ông Hải phải nghĩ cách khác.

Nhờ bà con giới thiệu, ông Hải mới liên hệ qua bên Campuchia để làm cho rẻ. Mấy đồng chí bên
Campuchia thì lấy giá chỉ bằng phân nửa cha Sáu Bảnh, tròn 500 triệu, bao luôn bảo trì hai tháng.

Công ty này tên là Cambodian Technology, có một anh BA tên Tony Tèo. Anh Tèo vốn là du học sinh Lào
tại Việt Nam nên tinh thông khá nhiều thứ tiếng.

Cambodian Technology lập ra một project team cùng với team IT của ông Hải để làm dự án. Chi tiết một
chút về đội hình ra sân cho anh em dễ hình dung.

• Team Cambodian Technology (công ty phát triển Mobile App): gồm một anh BA tên Tony Tèo, 3
anh Dev và 1 anh UX/UI Designer.

• Team Hải Motor Ôm (khách hàng): có chị Tủn, đóng vai trò như một Product Owner, và một số
các stakeholders khác.

Dự án bắt đầu…

Tám chục năm sau, dự án kết thúc.

Cambodian Technology nhận tiền, Hải Motor Ôm có app phục vụ bà con.

Hải Motor Ôm áp dụng thành công ứng dụng điện thoại vào thị trường cho khách đặt xe (front-end).
Cùng với đó là áp dụng hệ thống Biệt đội xe thồ tự quản để quản lý nội bộ (back-end).

Cứ thế, Hải Motor Ôm ngày càng lớn mạnh, và phát triển cho đến tận ngày nay. Trở thành tập đoàn xe
ôm hàng đầu nước nhà, là niềm tự hào của cả dân tộc.

2. Muôn nẻo đường BA

Vậy từ câu chuyện trên anh em thấy được gì?

Trong bất kỳ các dự án phần mềm nào, BA cũng đều rất quan trọng. Nhưng không phải lúc nào, BA cũng
xuất hiện dưới cái tên BA. Công việc thì vẫn là công việc của BA, nhưng cái tên thì khác.

Cụ thể trong câu chuyện trên, anh em thấy xuất hiện 3 người làm công việc BA, nhưng với 3 vai trò khác
nhau:

• BA trong tập đoàn Sáu Bảnh Global: anh Mai-cồ Tom

• BA trong công ty Hải Motor Ôm: chị Tủn

• Và cuối cùng là BA trong công ty Cambodian Technology: anh Tony Tèo

Vậy công việc của 3 anh này khác nhau chỗ nào?

Nhưng khoan, trước khi phân biệt rõ vai trò của 3 anh này, mình sẽ làm anh em hoang mang hồ ngọc hà
hơn bằng hình dưới đây.

Ở bài này mình sẽ cố gắng giúp anh em phân biệt rõ 5 roles này cụ thể nó như thế nào, dựa trên case
study phía trên cũng như các ví dụ mà mình sưu tầm được.

Tuy nhiên, trước khi đọc tiếp anh em nên hiểu rõ như thế nào là công việc Business Analyst.

Dù cho chức vụ của người đó có là Bridge System Engineer, Functional Consultant hay Product Owner đi
chăng nữa, thì nhìn chung họ vẫn đang làm công việc Business Analyst, nhưng là với những mục đích
khác nhau.

Và chính vì mục đích khác nhau, nên các đầu mục công việc thường ngày sẽ có phần khác nhau đôi chút.

Cụ thể như thế nào?

3. Công ty Product | Product Owner?

Thứ nhất là Product Owner.

Ngắn gọn, Product là “sản phẩm”, Owner là “sở hữu”. Product Owner là Người sở hữu sản phẩm. Mà
khi một người sở hữu cái gì thì họ thường có trách nhiệm đảm bảo cho cái đó được hoàn thiện, được
phát triển và được mọi người đón nhận.
Khi anh em sở hữu một chiếc Mẹc-Xi-Đì, anh em sẽ chăm chút cho nó, nâng niu nó, không để nó trày,
không để nó xướt. Khi xe dơ thì mang xe đi rửa, xe bị hư thì mang xe đi sửa. Chưa kể khi chạy ngoài
đường, anh em thấy bà con góp ý nên tháo cái này, gắn cái kia, anh em cũng về độ theo cho hợp lý.

Hoặc, giống như chai Number One của Tân Hiệp Phát. THP tung sản phẩm ra, bà con uống thử. Khen chỗ
nào, chê chỗ nào, THP đều phải thu thập các ý kiến từ thị trường, nghiên cứu và liên tục cải tiến sản
phẩm Number One sao cho hợp khẩu vị với bà con nhất.

Khi chai Number One có vấn đề gì, như có bà ruồi bả chui vô chẳng hạn, thì THP phải có trách nhiệm
khắc phục vấn đề một cách nhanh nhất. Nhằm khôi phục những đánh giá của bà con về sản phẩm.

Product Owner cũng vậy!

Nhưng sản phẩm ở đây là một sản phẩm công nghệ. Ví dụ:

• Các website thương mại điện tử như: Tiki, Lazada, hay Giaohangnhanh.

• Các mobile app như: Grab, Zalo, Foody, Camera 360, hay Money Lover.

• Hoặc các nền tảng như: WordPress (content management system), Wix (tương tự + web
designer), hoặc nền tảng thiết kế trực tuyến Design Bold.

Thế nào là công ty Product?

Anh em có thể hiểu nôm na, công ty Product là công ty cung cấp các sản phẩm công nghệ trực tiếp cho
người dùng cuối, ví dụ: Tiki, Lazada, Money Lover, Momo, Zalo…

Người dùng cuối chính là khách hàng, và công ty product sẽ nhận được tiền khi người dùng mua hoặc
thuê sản phẩm công nghệ đó. Như việc đăng ký thuê bao 1 năm của ứng dụng quản lý tài chính Money
Lover chẳng hạn.

Có rất rất nhiều công ty làm Product trên thị trường hiện nay. Kéo theo đó là có rất nhiều sản phẩm
công nghệ mà anh em dùng hằng ngày.

Và đứng sau những sản phẩm này đều có bàn tay của BA nhúng vào, nhưng với cái tên khác: Product

Owner

Tại sao nói Product Owner vẫn đang làm công việc Business Analyst?

Mục đích lớn nhất của một người Product Owner là đảm bảo sản phẩm được mang đến người dùng
một cách nhanh chóng và hiệu quả nhất.

Rõ ràng là họ đang đem lại một giải pháp công nghệ, mà người dùng cuối lại chính là người sử dụng giải
pháp công nghệ đó.

• Tiki giúp anh em mua sắm trực tuyến, tiết kiệm thời gian, tiết kiệm tiền bạc.

• Money Lover giúp anh em quản lý chi tiêu một cách đơn giản, tiện lợi.

• WordPress giúp anh em lan tỏa ý tưởng trên Internet.

• Camera 360 giúp anh em đẹp chai cu te hột me hơn… và hàng loạt các ví dụ khác.
Đó là concept. Còn về công việc, anh em cứ quay lại bản chất của công việc Business Analyst cho dễ hình
dung.

Công việc Business Analyst.

Trước khi bước vào dự án, chị Tủn phải xác định rõ Business Objective của dự án là gì. Ở đây chính là
xây dựng một Mobile App giúp khách hàng đặt xe, gia tăng khả năng tiếp cận khách hàng, từ đó gia
tăng doanh số và giúp mở rộng business.

Sau đó, chị phải làm việc với các Stakeholder để đảm bảo Business Objective được thống
nhất. Stakeholder đầu tiên phải là síp Hải, tiếp đến là các đối tác tiềm năng có thể cung cấp giải pháp,
sau đó có thể là tài xế, để hiểu được mong muốn của họ đối với cái app này.

Sau khi đã xác định rõ mục tiêu Business Objective và Stakeholder, chị Tủn sẽ làm việc trực tiếp với
Development Team của công ty Cambodian Technology để xây dựng giải pháp Mobile App, tức là bắt tay
vào làm Solution.

Mặc dù không trực tiếp làm giải pháp, nhưng chị Tủn đóng vai trò cực kỳ quan trọng trong việc xây dựng
sản phẩm sao cho khớp với nhu cầu thị trường nhất.

Và sau cùng là đưa giải pháp đó vào thị trường (transition) sao cho hiệu quả và đạt được các Business
Objectives đề ra ban đầu.

Thực tế thì một người Product Owner sẽ có những trách nhiệm sau:

• Tìm hiểu, nghiên cứu, và nhận phản hồi từ thị trường xem họ nghĩ gì, cần gì từ sản phẩm của
mình.
 • Từ đó đảm bảo cải tiến, phát triển sản phẩm nhằm đạt được KPIs đề ra (traffic, CPI, CPC, tỉ lệ
hoàn thành đơn hàng…).

Anh em có thể tham khảo thêm: Bài viết về người thật việc thật từ ITVIEC.COM về Product Owner.

Công việc thực tế của chị Tủn – một Product Owner trong công ty ông Hải.

Thông qua chị Tủn, anh em sẽ hiểu được một số công việc cụ thể của một người làm Product Owner.

Chị Tủn tiết lộ về công việc hằng ngày của chỉ như sau:

“Chào các bạn, mình là Tủn, hiện tại mình đang làm PO trong dự án phát triển một sản phẩm Mobile
App, giúp khách hàng có thể đặt xe trực tuyến…

• Hằng ngày mình sẽ là người phân loại, đánh giá mức độ ưu tiên cho các chức năng. Xem thử
chức năng nào cần làm đầu tiên, tiếp theo sẽ là chức năng gì.
(Vì mình thuộc công ty Hải Motor Ôm mà, nên mình sẽ tiếp cận được khách hàng của công ty
mình muốn gì, cần gì. Khi đó, mình mới đánh giá được cái gì cần build trước).

• Từ đó, mình sẽ quản lý danh sách các item cần làm (các hạng mục công việc) trong một cái list,
gọi là Product Backlog.

• Ngoài ra, mình cũng phải viết document cho dự án nữa, từ User Stories, đến Acceptance Criteria
(và 1 số loại documents khác).

• Hằng ngày cũng phải họp hành các kiểu với các Stakeholder, Development Team.

• So với các anh em BA, thì công việc của mình chủ yếu focus vào khách hàng để hoàn thiện sản
phẩm, hơn là focus vào quy trình.

• Mình sẽ liên tục nhận feedback từ khách hàng, và ra quyết định về roadmap của sản phẩm
Mobile App khi hoàn thành (tất nhiên là có tham khảo ý kiến của síp Hải, hehe).”

Ô kê, cảm ơn chị Tủn!

Anh em thấy đó, về bản chất công việc của chị Tủn không khác anh em BA mình là mấy. Nhưng điểm
khác biệt rõ nhất, là chỉ sẽ focus vào khách hàng hơn là focus vào requirement như anh em BA mình.
Chị Tủn – Product Owner trong công ty Hải Motor Ôm

Ngoài ra còn một điểm khác biệt rất lớn giữa Product Owner và Business Analyst, đó là lượng user mà
họ phục vụ.

Output của PO sẽ chịu tải, phục vụ cho cả triệu người dùng, vì người dùng cuối chính là khách hàng của
họ. Như Tiki một ngày có cả triệu lượt truy cập, sử dụng hệ thống.

Còn output của BA trong các công ty làm giải pháp thì chỉ đến được một số lượng hữu hạn user nhất
định, khoảng vài chục người. Vì đa phần, sản phẩm của họ chỉ phục vụ cho các nhân viên của công ty
khách hàng.

Product Owner chỉ xuất hiện trong các công ty làm Product?

Đây là quan điểm hơi… sai lệch. Product Owner không chỉ xuất hiện trong các công ty làm Product,
mà có thể xuất hiện trong bất cứ các công ty nào.

Nói đúng hơn, Product Owner xuất hiện trong các dự án phần mềm làm theo mô hình Scrum.

Nói sơ bộ thì Scrum là phương pháp quản lý dự án theo nguyên lý Agile. Một dự án Scrum sẽ có 3 vai
trò:

• Scrum Master (1 người)

• Product Owner (1 người)

• Development Team (1 đống người).

Product Owner là một trong 3 vai trò này, với các đầu mục công việc như mình nói ở trên.

Ví dụ bên Home Credit, một công ty tài chính, chuyên cung cấp các sản phẩm tài chính, chả ăn nhậu gì
sản phẩm phần mềm trong đây cả. Nhưng vẫn có cả role Product Owner, lẫn Business Analyst.

Vậy tại sao 2 ông PO và BA lại xuất hiện trong công ty này?
Lý do rất đơn giản, khi công ty phát sinh nhu cầu cần một giải pháp phần mềm để giải quyết một số vấn
đề của họ.

Chẳng hạn như: cần quản lý document cho toàn công ty, cần một hệ thống có thể tính lương tự động,
hoặc thậm chí là cần một mobile app nhỏ để các sếp approve kế hoạch online, ngay trên điện thoại, mà
không cần mở máy tính.

Khi đó, Product Owner sẽ xuất hiện, làm việc với các phòng ban để hiểu được các Business Objectives.
Từ đó họ sẽ document thành các stories, deliver cho Business Analyst để làm việc với Development
Team, xây dựng sản phẩm.

Hoặc BA có thể nhận các tickets (yêu cầu hoặc góp ý) từ các bộ phận đang sử dụng hệ thống. BA sẽ phân
tích các yêu cầu, và đánh giá độ khả thi và estimate resources để làm.

Quay lại case study đầu bài, đây cũng là những công việc mà chị Tủn đã làm khi được ông Hải tuyển vào
công ty dưới chức danh BA.

Chỉ đến khi công ty bắt đầu dự án Xây dựng Mobile App đặt xe cho khách và dự án được quản lý theo
mô hình Scrum, thì chỉ mới đóng vai trò là Product Owner mà thôi.

Và, Product Owner không nhất thiết lúc nào cũng đến từ công ty khách hàng, mà có thể đến từ một bên
thứ ba.

Chẳng hạn bên Mỹ có công ty 123 muốn xây dựng hệ thống a-á-ớ-bờ-cờ.
Công ty 123 này liên hệ với công ty giải pháp 456 ở Mỹ để làm dự án.

Sau khi xác định được Solution Design các thứ, và thống nhất với khách hàng (là công ty 123).
Công ty 456 này mới liên hệ với công ty 789 ở Việt Nam để làm cho rẻ (vì giá nhân công ở Việt Nam rẻ
hơn mà).

Thì khi đó, Product Owner không đến từ công ty khách hàng 123, mà có thể đến từ công ty trung gian
456 bên Mỹ.

Ở phần 1, chúng ta đã đi được các phần sau.

1. Một câu chuyện hư cấu có thật

2. Muôn nẻo đường BA

3. Công ty Product | Product Owner?

Ở phần 2, mình sẽ tiếp tục đi các phần còn lại, bao gồm:

Nội dung [Hide]

• 4. Công ty Giải pháp

o 4.1. Business Analyst trong Công ty Outsourcing?

 o 4.2. Functional Consultant trong Công ty Services?

o 4.3. Bridge System Engineer trong công ty Outsourcing?

• 5. Công ty Tư Vấn | Business Consultant?

• 6. Tạm kết

4. Công ty Giải pháp

Đối với các công ty giải pháp, mình sẽ chia làm 2 loại công ty có công việc BA.

• Công ty Outsource (chủ yếu làm Software Development)

• Công ty Services (chủ yếu làm Software Implementation, Software Maintenance, và 1 nùi các
loại service khác).

Anh em xem lại cái hình overview ở phần 1 cho dễ hình dung nhé.

4.1. Business Analyst trong Công ty Outsourcing?

Công ty Outsourcing là gì?

Outsource nghĩa là gia công. Nghĩa là: thay vì mình làm, thì mình đi thuê thằng khác làm cho mình, chứ
mình hổng làm.
Vì thằng khác nó chuyên làm cái đó,
nó làm tốt hơn mình,
và giá nhân công nó rẻ hơn mình.

Quay lại case study phía trên. Công ty ông Hải cần phát triển một Mobile App, giúp khách hàng có thể
đặt xe trực tuyến.

Cái này đáng ra ổng phải làm, mà do đội IT của ổng cùi bắp quá, không đủ resources để làm. Nên ổng
phải tìm đến Sáu Bảnh Global để làm.

Tuy nhiên vì giá chát quá, nên ổng phải tìm qua một thị trường khác có giá nhân công rẻ hơn Việt Nam
để làm, là Campuchia.

Trong công ty Campuchia có một anh BA tên Tony Tèo. Và anh này chính là Business Analyst, trong công
ty Outsourcing, công ty Cambodian Technology.

Về công việc của ảnh thì chắc mình không cần giải thích thêm nhiều chứ hả anh em

Mình chỉ muốn nói rõ cho anh em đỡ lẫn lộn giữa 2 vai trò.

• Product Owner tập trung trả lời câu hỏi nghiêng về Product, là làm gì, tại sao phải làm và làm
khi nào?

• Còn Business Analyst tập trung trả lời câu hỏi nghiêng về Requirement, là làm như thế nào?

Cũng như chị Tủn (một Product Owner), công việc của anh Tony Tèo (một Business Analyst trong công ty
Outsource) cũng xoay quanh 4 vòng tròn sau.
Cũng như chị Tủn, công việc của anh Tèo cũng dựa trên 4 vòng tròn này.

Sơ bộ thì anh Tony Tèo sẽ làm việc trực tiếp với chị Tủn (Product Owner) để 2 bên cùng hiểu rõ Business
Objectives của dự án, cũng như các Stakeholder có trong dự án.

Giai đoạn xác định Business Objective và các Stakeholder anh Tèo không involve vào nhiều, vì đa phần
các nội dung này đã được chị Tủn Product Owner bên công ty khách hàng lo rồi.

Cái mà ảnh sẽ tập trung làm, đó chính là Solution. Ảnh phải thật sự nắm rõ về các requirement cần làm,
cũng như đưa ra giá trị tư vấn về Mobile App (tức là tư vấn về giải pháp), sao cho giải pháp này thật sự
đáp ứng được Business Objective và sự hài lòng của các Stakeholders.

Sau đó ảnh sẽ chuyển giao toàn bộ giải pháp cho chị Tủn, có thể hỗ trợ training sử dụng hệ thống,
hoặc hỗ trợ Go-Live, bảo trì khi kết thúc dự án, gọi là Transition.

Liệu Product Owner và Business Analyst có cùng tồn tại trong một dự án?

Như mình nói, Product Owner xuất hiện trong dự án làm theo mô hình Scrum. Mà 1 trong 3 vai trò của
mô hình Scrum là Development Team.

Vậy thì: người Business Analyst làm GIẢI PHÁP sẽ nằm ở đâu trong dự án Scrum?

Nằm trong Development Team, ngoài Development Team, hay Business Analyst chính là Product Owner?

Câu trả lời có hay không, tất cả đều phụ thuộc vào dự án. Hai vai trò cùng tồn tại cũng được, mà không
cũng được.

Như case study đầu bài của mình là có. Cả 2 role BA (anh Tony Tèo) và PO (chị Tủn) cùng tồn tại trong
dự án xây dựng Mobile App đặt xe cho công ty Hải Motor Ôm.
Mình có sưu tầm được 3 hình sau của Roman Pichler cũng có mention về vấn đề này.

Phương án 1, như case study của mình.

Phương án 2, Business Analyst đóng vai trò như một Product Owner.
Phương án 3, nên tránh, làm trung gian kiểu này sẽ làm mất đi tính chất “gọn nhẹ” của Agile, dẫn đến
trao đổi thông tin chậm và không hiệu quả.

Ô kê, vậy là nãy giờ anh em đã biết được role thực sự của chị Tủn và anh Tony Tèo.

Vậy thì còn lại, anh Mai-cồ Tom ở đầu bài, ảnh cũng làm công việc BA, nhưng thực sự ảnh đóng vai trò
nào?

4.2. Functional Consultant trong Công ty Services?

Thế nào là software implementation

Vâng, chính xác thì vai trò của anh Tom là Functional Consultant. Về cơ bản, công việc của anh Tony Tèo
chả khác gì anh Mai-cồ Tom là mấy.

Công việc của Business Analyst trong công ty Outsourcing hay công việc của Functional Consultant trong
công ty Services giống nhau đến 96,69%. Còn 69,96% khác biệt còn lại là đến từ GIẢI PHÁP.

Đơn giản vì, công ty Outsourcing thì làm giải pháp khi chưa có gì hết, phải build ngay từ đầu, start from
scratch. Bà con hay gọi là Software Development.

Còn công ty Services thì giải pháp họ cung cấp là một sản phẩm đã có sẵn. Nhiệm vụ của họ là triển khai
giải pháp đó một cách hiệu quả nhất. Bà con hay gọi là Software Implementation.

Công ty Service hay công ty Outsourcing là do mình tự đặt ra để phân biệt cho dễ giữa Software
Development và Software Implementation. Còn về bản chất, Outsourcing vẫn là một loại hình dịch vụ,
nên anh em đừng rối bời quá nhé.

Ba cái đồ triển khai cùi bắp, lêu lêu.

Nói về triển khai thì mình cũng đã từng nghe nhiều anh em “bĩu môi chê bai” rằng: “Triển khai thì có cái
gì đâu mà hay ho, toàn là có sẵn, giờ chỉ việc đem đi ‘ráp’ cho khách hàng xài thôi chớ có làm gì đâu, lêu
lêu…”

Mình xin khẳng định câu trên là hoàn toàn sai!

Comment này có thể đến từ những anh em chưa từng làm triển khai một lần nào trong đời, hoặc trong
đời chưa từng làm triển khai bao giờ. (Thực ra 2 ý này như nhau, nhưng blog của mình nên mình thích

nói vậy cho nó nguy hiểm )

Mọi thứ đâu dễ ăn của ngoại vậy được. Nói vậy chắc mấy công ty làm software implementation giàu bổ
xừ nó hết rồi.

Vậy thì thực sự như thế nào? Cùng quay lại vòng tròn BA huyền thoại để xem công việc của Functional
Consultant là gì nhé anh em.

Business Analyst hay Functional Consultant cũng giống y chang, cũng làm như này hết, cụ thể.

Anh Mai-cồ Tom có nhiệm vụ xác định rõ Business Objectives của ông Hải là gì. Rõ ràng là ổng muốn
quản lý đội xe của ổng tốt hơn, thông qua việc áp dụng hệ thống “Self-Governing Motor Ôm”.

Anh Mai-cồ này phải xác định rõ cụ thể: tốt hơn là như thế nào. Ảnh sẽ làm việc với các Stakeholder,
làm việc với ông Hải CEO, làm việc với bộ phận quản lý đội xe, tài xế, rồi nhân sự, kế toán… để xác định
các module/ functions cần có của hệ thống.
Sau đó, anh Mai-cồ mới bắt tay vào làm solution dựa trên hệ thống “Dynamics 365 for Ôm” của
Microsoft. Ảnh sẽ configure và customize lại hệ thống sẵn có sao cho phù hợp với những requirements cụ
thể từ khách hàng là công ty Hải Motor Ôm.

Và dĩ nhiên, không phải một mình ảnh làm solution, mà phải có cả team cùng làm, nồng cốt nhất vẫn là
PM và các anh em Developers.

Sau khi hoàn thiện xong Solution, ảnh sẽ mang đi triển khai bằng các hoạt động training key-user sử
dụng hệ thống, hoặc support go-live các kiểu. Đó là Transition.

Một số khác biệt giữa software developement và software implementation

Như anh em thấy, công việc của BA giữa 2 mảng này cũng không khác nhiều. Tuy nhiên, có một vài điểm
khác biệt mình nên nói rõ cho anh em như sau.

• BA trong software development thì tập trung sức lực vào build solution là nhiều.

• Còn BA trong software implementation thì tập trung vào khách hàng, vào người dùng nhiều
hơn.

Về khả năng tiếp cận người dùng để hiểu họ và đem lại giải pháp thật sự phù hợp, thì mình nghĩ đâu đó
BA trong software implementation vẫn nhiều cơ hội hơn, so với BA trong software development.

Nhưng bù lại, thì kiến thức IT của BA trong software development có thể được đòi hỏi cao hơn, so với
nhánh ngược lại.

Còn BA trong software implementation thì kỹ năng thuyết phục và thương thảo với khách hàng phải thật
sự tốt. Để có thể tư vấn, thuyết phục họ đi theo các best practices có sẵn, ngoài việc lái hệ thống đi theo
những quy trình đặc thù của khách hàng.

Ngoài những dự án triển khai mới ra, Functional Consultant còn có thể xuất hiện trong các dự án sau:
 • Software Maintenance – Các dự án bảo trì phần mềm

• Security – Các dự án bảo mật hệ thống

• Software Upgrade – Các dự án nâng cấp phần mềm

• Integration – Các dự án chuyên về tích hợp các sản phẩm phần mềm.

Chốt hạ

Business Analyst thì chỉ là cái TÊN CÔNG VIỆC. Còn chức danh là gì, thì anh em phải để ý thật sự kỹ. Có
một số công ty đặt chức danh theo đúng công việc họ làm, một số khác thì không.

Có một số công ty tuyển thì tuyển Business Analyst, nhưng vào thì chỉ cho làm các dự án support. Quanh
năm suốt tháng chỉ làm support. Chán như con gián.

Do đó anh em phải tìm hiểu thật kỹ. Chức danh có thể tạm gác qua 1 bên, nhưng Job Description thì
tuyệt đối phải đọc kỹ.

4.3. Bridge System Engineer trong công ty Outsourcing?

BrSE là kỹ sư cầu nối. Cái tên nói lên tất cả.

BrSE có nhiệm vụ trực tiếp kết nối team offshore (team làm ở nhà, không đi onsite) với khách hàng.

Vì rào cản lớn nhất ở đây là bất đồng ngôn ngữ, nên BrSE phải rất giỏi một ngoại ngữ nào đó. Nếu khách
hàng là Nhật thì phải biết tiếng Nhật, là Pháp thì phải biết tiếng Pháp…

Ngoài ra, một BrSE phải biết về kỹ thuật, có thể là rành một ngôn ngữ lập trình nào đó. Vì quá trình
“truyền tin” giữa khách hàng và team nhà có thể phát sinh nhiều vấn đề mới, hoặc các requirement cũ
phát sinh bug. BrSE cần hiểu rõ các vấn đề này để “dàn xếp” mọi thứ một cách ổn thỏa giữa 2 bên.

Về bản chất, vai trò BrSE cũng tương tự như vai trò Business Analyst. Họ sẽ làm việc với khách hàng,
nhận requirement từ họ, phân tích và tài liệu hóa các requirement, deliver cho team nhà, giải thích và
quản lý công việc các anh em team nhà. Nhằm đảm bảo mọi thứ được deliver một cách chính xác và
chất lượng.

That’s it, đó là những gì mình biết về BrSE Anh em có thể đọc thêm bài dưới đây để hiểu hơn về
công việc của BrSE nhé.

BrSE – Kỹ sư cầu nối, được gì và mất gì?

Hoặc BrSE là gì từ Hajimari.

5. Công ty Tư Vấn | Business Consultant?

Ô kê anh em, chúng ta đã đi được 4 vai trò:

 • Product Owner

• Business Analyst

• Functional Consultant

• Bridge System Engineer

Và vai trò cuối cùng là Business Consultant, và cũng là trùm cuối trong nghề BA. Hay nói đúng hơn, vai
trò này có thể là Technology Business Consultant hoặc Principle Business Analyst. Nói chung là chúa tể
của những BA.

Họ là ai?

Đây là những người rất khủng, họ đã có hàng chục năm kinh nghiệm chinh chiến, thương tích đầy mình.
Lăn lộn đủ lâu với ngành giải pháp phần mềm, đủ để tích lũy cho mình những góc nhìn đặc thù với
những vấn đề nan giải nhất, hay xảy ra trong tất cả các loại hình công ty.

Và kèm theo đó luôn là những best practices để xây dựng giải pháp phần mềm mang lại hiệu quả nhất
cho công ty khách hàng.

Vậy họ làm những việc gì? Đơn giản là họ làm tư vấn. Tư vấn thực thụ nhé anh em.

Anh em có thể thấy vai trò này i chang Technical Architect, nhưng không chuyên sâu kỹ thuật như TA.

Như mình nói, ý nghĩa của nghề BA là giải quyết vấn đề bằng giải pháp công nghệ thông tin. Giải pháp
này có thể là phần cứng, chứ không không nhất thiết chỉ là phần mềm. Và bằng bất kỳ các công nghệ,
từ AI, Cloud hay Blockchain, chứ không gói gọn trong bất kỳ phạm vi nào.

Thậm chí, họ còn có thể giải quyết vấn đề bằng cách tư vấn về quy trình, chiến lược phát triển nền tảng
CNTT cho khách hàng, chứ không chỉ gói gọn trong 1-2 hệ thống, sản phẩm phần mềm.

Và Technology Business Consultant là vai trò thể hiện giá trị tư vấn rõ nhất, và là đẳng cấp cao nhất của
một người làm BA.

Cũng như một BA thông thường, nhưng Technology Business Consultant không làm tiểu tiết đến từng
stories hay requirement như BA. Họ chỉ mang lại giải pháp ở tầng high level, vì với kinh nghiệm lâu năm,
họ biết đó là điều tốt nhất cho công ty khách hàng.

Vai trò này thường xuất hiện ở các bác principle, chuyên làm tư vấn chiến lược, hoặc thậm chí là làm
Pre-Sales. Anh em có thể bắt gặp vị trí này ở các công ty chuyên tư vấn giải pháp công nghệ thông tin.

Thường thì các công ty tư vấn chỉ làm tư vấn, và không được tham gia xây dựng hoặc triển khai giải
pháp. Việc “hiện thực hóa giải pháp” phải được một bên thứ ba làm thì mới minh bạch và hiệu quả.

Do đó, thứ mà Technology Business Consultant có thể deliver được cho khách hàng chính là tài liệu tư
vấn. Chính xác, chỉ đơn giản là các file pdf, nhưng đáng giá cả triệu đô.
Các công ty mà chuyên tư vấn giải pháp CNTT thì mình không biết nhiều, đếm trên đầu ngón tay thì
có: PAT Consultant, PwC, Deloitte, KPMG hay E&Y.

Nói vậy thôi nhưng ở Việt Nam thì các công ty như Deloitte hay KPMG vẫn tư vấn rồi triển khai cho
khách hàng luôn nhé anh em.

Best Practices

Nếu đúng bài bản như các công ty nước ngoài hay làm, thì khi có vấn đề/ nhu cầu về một giải pháp phần
mềm nào đó, khách hàng họ sẽ chủ động liên hệ với các công ty tư vấn CNTT trước. Sau đó mới đi tìm
các đối tác xây dựng hoặc triển khai phần mềm.

Khi đó, khách hàng họ đã biết được họ cần gì trước, cần gì sau, chức năng nào là phù hợp, nên ưu tiên
hàng đầu. Hoặc thậm chí là đối tác nào nên tiếp cận, đối tác nào nên né.

Chỉ như vậy, khách hàng mới có thể tự narrow down lại rủi ro có thể họ gặp phải, chi phí bỏ ra hiệu quả
hơn và tỉ lệ thành công của dự án cao hơn rất nhiều.

6. Tạm kết

Hi vọng qua bài này, anh em hiểu rõ được các vai trò của công việc BA.

Thực tế thì nó có thể như mình nói ở trên, hoặc không. Vì thực tế thì muôn hình vạn trạng, mình không
thể cover hết được. Anh em cứ xem đây là một note tóm gọn lại những vai trò dễ bắt gặp nhất đối với
một người làm công việc BA.
+ Thuật Ngữ BA:

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ờ

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.

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

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.

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.

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.

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.

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.

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.

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.

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ì?

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.

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 đó.

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.

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.

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.

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.

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 <<user name>>, I want to <<do something>>. So that, I can <<archieve … goal>>.

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….!