10 dự án Data Analyst giúp xây Portfolio và chứng minh năng lực

Portfolio của một Data Analyst không nên chỉ là bộ sưu tập những ảnh dashboard đẹp. Một portfolio tốt phải cho thấy người học có thể bắt đầu từ một câu hỏi kinh doanh, hiểu dữ liệu, kiểm tra chất lượng, lựa chọn phương pháp phù hợp, phân tích kết quả và giải thích được ý nghĩa của những con số đó.

Đây là điểm khác biệt quan trọng giữa “biết dùng công cụ” và “có khả năng làm công việc phân tích dữ liệu”.

Một ứng viên có thể ghi SQL, Power BI, Python hay Excel trong CV. Nhưng nhà tuyển dụng vẫn cần bằng chứng cho thấy những công cụ đó đã được sử dụng để giải quyết một vấn đề cụ thể. Portfolio chính là nơi cung cấp bằng chứng này.

Người mới thường gặp hai thái cực.

Một nhóm tải một bộ dữ liệu phổ biến, tạo vài biểu đồ rồi gọi đó là dự án. Kết quả thường rất giống hàng nghìn portfolio khác trên Internet.

Nhóm còn lại cố gắng đưa quá nhiều công nghệ vào cùng một dự án: Cloud, Machine Learning, AI, Big Data, Data Engineering. Dự án nhìn phức tạp nhưng khi được hỏi một câu đơn giản như “Revenue này được tính như thế nào?”, người thực hiện lại không giải thích được rõ ràng.

Một portfolio tốt không cần phức tạp như một hệ thống doanh nghiệp thật. Nó cần đủ thực tế để chứng minh cách suy nghĩ và khả năng làm việc với dữ liệu.

Mười dự án dưới đây được thiết kế theo nhiều bối cảnh khác nhau như bán lẻ, Marketing, Finance, Sales, Logistics, HR và thương mại điện tử. Không cần thực hiện cả mười. Hai hoặc ba dự án được làm sâu, khác nhau về bối cảnh và do chính người học giải thích được thường có giá trị hơn nhiều dự án đơn giản.

Mục lục

Portfolio Data Analyst cần chứng minh điều gì?
Cấu trúc một dự án Data Analyst hoàn chỉnh
Mười dự án Data Analyst nên cân nhắc
Cách chọn dự án theo nền tảng và mục tiêu nghề nghiệp
Cách sử dụng Excel, SQL, Power BI, Python và Cloud
AI nên được sử dụng thế nào trong Portfolio?
Cách tự đánh giá chất lượng dự án
Checklist trước khi công khai Portfolio
Cách trình bày dự án trong phỏng vấn
Học qua dự án tại TechData.AI
Câu hỏi thường gặp

PHẦN I — PORTFOLIO DATA ANALYST CẦN CHỨNG MINH ĐIỀU GÌ?

1. Tư duy kinh doanh

Một dự án tốt phải bắt đầu bằng vấn đề, không phải bằng công cụ.

“Dashboard bán hàng bằng Power BI” chưa phải một bài toán phân tích. Nó chỉ mô tả sản phẩm cuối cùng.

Một cách đặt vấn đề tốt hơn là:

Doanh thu của chuỗi vẫn tăng nhưng lợi nhuận đang giảm. Ban điều hành muốn biết khu vực, sản phẩm và chương trình khuyến mại nào đang ảnh hưởng nhiều nhất.

Ngay lập tức, dự án có mục tiêu rõ hơn.

Người xem biết ai sẽ sử dụng kết quả, vấn đề cần giải quyết là gì và những quyết định nào có thể được hỗ trợ.

Đây cũng là cách công việc Data Analyst diễn ra trong doanh nghiệp. Hiếm khi quản lý nói:

“Hãy làm cho tôi một dashboard có tám biểu đồ.”

Họ thường hỏi:

“Tại sao doanh thu giảm?”

“Khách hàng nào đang rời bỏ?”

“Tại sao tồn kho cao nhưng vẫn hết hàng?”

“Marketing đang tiêu tiền vào đâu?”

Portfolio vì vậy nên chứng minh khả năng chuyển một câu hỏi kinh doanh thành câu hỏi dữ liệu.

2. Khả năng kiểm tra chất lượng dữ liệu

Trong thực tế, dữ liệu hiếm khi hoàn hảo.

Có thể có dòng trùng, giá trị thiếu, mã sản phẩm thay đổi, đơn hàng bị hủy, khách hàng xuất hiện nhiều lần hoặc hai hệ thống sử dụng cách định nghĩa khác nhau.

Một Data Analyst không chỉ nhận dữ liệu rồi lập tức tạo biểu đồ.

Trước hết phải hiểu dữ liệu đang đại diện cho điều gì.

Ví dụ, bảng Orders có thể có một dòng cho mỗi đơn hàng, trong khi Order Details có nhiều dòng cho mỗi đơn vì mỗi sản phẩm nằm ở một dòng riêng. Nếu JOIN không đúng rồi cộng Revenue từ bảng Orders, doanh thu có thể bị nhân nhiều lần.

Câu SQL vẫn chạy.

Dashboard vẫn hiển thị đẹp.

Nhưng số liệu sai.

Portfolio chuyên nghiệp nên thể hiện ít nhất một số bước kiểm tra như khóa có bị trùng hay không, dữ liệu thiếu ở đâu, thời gian bao phủ đến ngày nào và số liệu sau xử lý có còn khớp nguồn hay không.

3. Kỹ năng kỹ thuật

Portfolio cần chứng minh khả năng sử dụng công cụ, nhưng công cụ phải phục vụ bài toán.

SQL phù hợp khi dữ liệu có nhiều bảng và cần truy vấn, tổng hợp hoặc xử lý logic.

Excel phù hợp với kiểm tra nhanh, đối soát và những bộ dữ liệu nhỏ.

Power BI phù hợp để xây Data Model, KPI và dashboard.

Python hữu ích khi cần tự động hóa, xử lý dữ liệu linh hoạt hoặc thực hiện các phân tích khó bằng công cụ BI.

Không cần đưa tất cả vào một dự án.

Một dự án dùng SQL và Power BI thật tốt có thể thuyết phục hơn một dự án có SQL, Python, Cloud, Machine Learning và AI nhưng mỗi phần chỉ chạm qua.

Nhà tuyển dụng thường quan tâm tại sao lựa chọn công cụ đó và kết quả có đáng tin hay không hơn việc portfolio có bao nhiêu logo công nghệ.

4. Khả năng phân tích và giao tiếp

Một Data Analyst không chỉ tạo ra số liệu.

Người làm phân tích phải giúp người khác hiểu con số có ý nghĩa gì.

Ví dụ, câu:

“Doanh thu miền Nam giảm 12%.”

mới chỉ là mô tả.

Phân tích sâu hơn có thể là:

“Khoảng 65% mức giảm doanh thu miền Nam đến từ hai nhóm sản phẩm có tỷ lệ hết hàng tăng mạnh trong tháng. Cần kiểm tra thêm dữ liệu tồn kho và điều chuyển trước khi kết luận thiếu hàng là nguyên nhân trực tiếp.”

Cách viết thứ hai cho thấy ba năng lực cùng lúc: phát hiện, diễn giải và biết giới hạn của dữ liệu.

Portfolio tốt nên cho người không kỹ thuật hiểu được trong vài phút: vấn đề là gì, điều gì được phát hiện và bước tiếp theo nên là gì.

5. Khả năng chịu trách nhiệm với kết quả

Một dự án chỉ thật sự thuộc về ứng viên khi người đó có thể giải thích từng quyết định quan trọng.

Tại sao Revenue được tính như vậy?

Tại sao dùng Median thay vì Average?

Tại sao loại đơn hủy?

Tại sao biểu đồ này phù hợp?

Tại sao chọn nhóm khách hàng đó?

Nếu sử dụng AI hoặc template để hỗ trợ, điều đó không phải vấn đề. AI đang trở thành công cụ bình thường trong công việc Data.

Nhưng mã do AI tạo vẫn phải được hiểu và kiểm tra.

Một câu hỏi thay đổi nhỏ trong phỏng vấn thường đủ để cho thấy ứng viên thực sự hiểu dự án hay chỉ làm theo hướng dẫn.

PHẦN II — CẤU TRÚC MỘT DỰ ÁN DATA ANALYST HOÀN CHỈNH

6. Bắt đầu bằng bối cảnh và câu hỏi kinh doanh

Phần đầu dự án nên trả lời bốn câu hỏi: doanh nghiệp giả định là ai, vấn đề đang gặp là gì, ai sẽ sử dụng kết quả và phạm vi phân tích đến đâu.

Không cần viết dài.

Khoảng 150–250 từ thường đủ để tạo bối cảnh.

Ví dụ:

Một chuỗi bán lẻ có doanh thu tăng 8% trong sáu tháng gần nhất nhưng Gross Margin giảm. Ban điều hành muốn xác định khu vực, nhóm sản phẩm và chương trình khuyến mại nào đang ảnh hưởng tới lợi nhuận.

Chỉ vài câu như vậy đã giúp người đọc hiểu dự án đang cố giải quyết điều gì.

Phần giới thiệu không nên bắt đầu bằng:

“Dự án sử dụng SQL Server, Python, Power BI và Excel.”

Công cụ là phương tiện.

Vấn đề kinh doanh mới là điểm bắt đầu.

7. Mô tả dữ liệu và cách xử lý

Người xem cần biết dữ liệu đến từ đâu, gồm những bảng nào, một dòng đại diện cho điều gì và dữ liệu bao phủ khoảng thời gian nào.

Nếu có nhiều bảng, nên giải thích khóa dùng để liên kết.

Ví dụ:

Orders lưu thông tin đơn hàng.

Order Details lưu từng sản phẩm trong đơn.

Products chứa thông tin sản phẩm.

Customers chứa thông tin khách hàng.

Returns chứa dữ liệu hoàn trả.

Sau đó mô tả ngắn những vấn đề đã phát hiện và cách xử lý.

Ví dụ mã sản phẩm bị thay đổi, đơn hàng bị hủy, một số Customer ID bị trùng hoặc dữ liệu một ngày bị thiếu.

Không cần biến tài liệu thành nhật ký tất cả thao tác.

Chỉ cần những quyết định có thể ảnh hưởng đến kết quả.

8. Giải thích cách phân tích

Đây là phần chứng minh tư duy.

Nếu sử dụng SQL, nên chọn những truy vấn quan trọng thay vì đưa hàng trăm dòng code vào bài viết chính.

Nếu dùng Power BI, có thể trình bày Data Model và một số measure quan trọng.

Nếu sử dụng Python, notebook cần đủ rõ để người khác có thể chạy lại.

Điều quan trọng là giải thích logic.

Ví dụ:

Doanh thu thuần được tính từ doanh thu hoàn thành trừ giá trị hàng hoàn trả. Đơn bị hủy được loại vì chưa tạo giao dịch bán hàng thực tế.

Một câu giải thích như vậy thường có giá trị hơn việc chỉ đưa công thức DAX.

9. Kết quả và khuyến nghị

Một dự án không cần 20 insight.

Ba đến năm phát hiện quan trọng thường đủ.

Mỗi phát hiện nên trả lời ba câu hỏi:

Dữ liệu cho thấy điều gì?

Điều đó có ý nghĩa gì?

Doanh nghiệp nên kiểm tra hoặc làm gì tiếp theo?

Ví dụ:

Nhóm sản phẩm A chiếm 40% mức giảm Gross Margin dù doanh thu vẫn tăng. Nguyên nhân trực tiếp quan sát được là tỷ lệ Discount tăng đáng kể. Cần kiểm tra thêm chính sách khuyến mại trước khi kết luận chương trình giảm giá là nguyên nhân duy nhất.

Cách viết này vừa hữu ích vừa tránh việc biến tương quan thành nguyên nhân.

10. Kiểm thử và giới hạn

Một dự án chuyên nghiệp phải nói rõ dữ liệu đã được kiểm tra như thế nào.

Có thể đối soát tổng doanh thu với nguồn, kiểm tra số dòng trước và sau JOIN, kiểm tra khóa trùng và lấy một số đơn hàng mẫu để tính bằng tay.

Ngoài ra cần nêu giới hạn.

Ví dụ dữ liệu không có chi phí vận chuyển nên Gross Margin chưa phải lợi nhuận cuối cùng. Hoặc Marketing Data không nối đầy đủ với Customer ID nên chưa thể xác định chính xác toàn bộ hành trình khách hàng.

Nêu giới hạn không làm dự án yếu đi.

Ngược lại, nó cho thấy người phân tích hiểu ranh giới của dữ liệu.

PHẦN III — 10 DỰ ÁN DATA ANALYST GIÚP XÂY PORTFOLIO

11. Dự án 1: Phân tích doanh thu và lợi nhuận chuỗi bán lẻ

Đây là một trong những dự án phù hợp nhất cho người mới vì bài toán dễ hiểu nhưng đủ chiều sâu.

Giả sử chuỗi bán lẻ đang tăng doanh thu nhưng lợi nhuận lại giảm. Ban điều hành muốn biết vấn đề nằm ở khu vực, cửa hàng, sản phẩm hay chính sách khuyến mại.

Dữ liệu có thể gồm Orders, Order Details, Products, Stores, Returns và Sales Target.

SQL được sử dụng để JOIN dữ liệu, tính doanh thu thuần, giá vốn và Gross Profit. Power BI được dùng để xây Data Model và dashboard. Excel có thể đóng vai trò đối soát một số KPI quan trọng.

Điểm đáng chứng minh không phải chỉ là Top 10 Product.

Hãy phân tích sâu hơn xem thay đổi doanh thu đến từ giá bán, số lượng hay cơ cấu sản phẩm. Có thể so sánh Margin giữa sản phẩm giảm giá và không giảm giá hoặc xác định cửa hàng tăng doanh số nhưng giảm lợi nhuận.

Dự án cũng tạo ra nhiều câu hỏi phỏng vấn tốt: đơn hoàn trả được tính thế nào, Revenue khác Net Revenue ra sao và JOIN nhiều bảng có tạo duplicate hay không.

Nếu dữ liệu không có chi phí vận hành, cần ghi rõ rằng Gross Profit không đồng nghĩa lợi nhuận ròng.

12. Dự án 2: Phân tích tồn kho và nguy cơ hết hàng

Tồn kho là bài toán rất thực tế trong Retail và Supply Chain.

Doanh nghiệp có thể sở hữu lượng hàng tồn rất lớn nhưng vẫn xảy ra tình trạng một số cửa hàng hết sản phẩm bán chạy.

Dữ liệu nên gồm Inventory theo ngày, Sales, Purchase hoặc Inbound, Products và Stores.

Người học có thể tính tốc độ bán trung bình, số ngày tồn kho còn lại và xác định những SKU bán chậm hoặc có nguy cơ hết hàng.

Ví dụ một sản phẩm còn 100 units nghe có vẻ nhiều. Nhưng nếu mỗi ngày bán 30 units thì lượng hàng chỉ đủ hơn ba ngày.

Ngược lại, 100 units của sản phẩm chỉ bán hai chiếc mỗi tuần có thể là tồn kho cao.

Điểm khác biệt của dự án là không sử dụng một ngưỡng cho tất cả sản phẩm. Những nhóm hàng có vòng đời hoặc mùa vụ khác nhau cần được xem xét riêng.

Có thể mở rộng bằng kịch bản điều chuyển hàng giữa các cửa hàng. Nếu Store A có nguy cơ hết hàng trong ba ngày còn Store B đang có lượng hàng đủ 40 ngày, hệ thống có thể đề xuất kiểm tra khả năng điều chuyển.

Tuy nhiên, đây chỉ nên được trình bày như một recommendation. Quyết định điều chuyển thật còn phụ thuộc chi phí, nhu cầu tương lai và nhiều yếu tố khác.

13. Dự án 3: Phân tích hiệu quả chiến dịch Marketing

Đây là dự án phù hợp với người có nền tảng Marketing hoặc muốn trở thành Marketing Analyst.

Bài toán có thể bắt đầu từ tình huống rất phổ biến: Marketing Spend tăng nhưng số khách hàng mới không tăng tương ứng.

Dữ liệu có thể đến từ Google Ads, Meta Ads, website, CRM và đơn hàng.

Thách thức đầu tiên là những hệ thống này có mức chi tiết khác nhau. Một bảng lưu theo Campaign, bảng khác theo ngày, trong khi CRM lại theo Lead hoặc Customer.

Người học có thể chuẩn hóa Campaign ID rồi tính CPM, CPC, Conversion Rate, Cost per Lead, Customer Acquisition Cost và Revenue.

Điểm quan trọng là không dừng ở Click.

Một campaign có CPL thấp chưa chắc tốt nếu lead có tỷ lệ trở thành khách hàng rất thấp.

Portfolio sẽ mạnh hơn nếu tiếp tục nối dữ liệu Sales để xem lead từ từng campaign tạo ra bao nhiêu Revenue sau 30 hoặc 60 ngày.

Nếu dữ liệu Attribution chưa đầy đủ, cần nói rõ. Không nên tuyên bố ROAS tuyệt đối khi không thể theo dõi toàn bộ hành trình khách hàng.

14. Dự án 4: Phân tích khách hàng quay lại và nguy cơ rời bỏ

Dự án này giúp chứng minh khả năng làm Customer Analytics.

Bài toán là xác định khách hàng mới, khách quay lại, khách trung thành và nhóm có dấu hiệu không còn mua hàng.

Dữ liệu có thể gồm Customer, Transaction, Product và Channel.

SQL có thể được sử dụng để tìm lần mua đầu tiên, lần mua gần nhất và khoảng cách giữa các lần mua. Sau đó người học có thể xây cohort, tức nhóm khách bắt đầu mua cùng thời điểm, hoặc sử dụng RFM.

RFM gồm ba thành phần đơn giản: khách mua gần đây đến mức nào, mua thường xuyên ra sao và tổng giá trị mua bao nhiêu.

Một hướng phân tích tốt là so sánh retention giữa những khách đến từ các kênh khác nhau hoặc giữa những người mua sản phẩm đầu tiên khác nhau.

Ví dụ khách đến từ Campaign A có thể mua lần đầu nhiều nhưng tỷ lệ quay lại thấp hơn nhóm Organic Search.

Điểm cần cẩn thận là không sử dụng dữ liệu tương lai để xác định trạng thái khách hàng trong quá khứ.

Nếu đang đánh giá khách tại ngày 30/6 thì không được dùng hành vi tháng 7 để quyết định người đó có nguy cơ rời bỏ tại ngày 30/6 hay không.

15. Dự án 5: Phân tích công nợ phải thu

Đây là dự án rất phù hợp với người chuyển từ kế toán hoặc tài chính sang Data Analytics.

Bối cảnh có thể là doanh thu doanh nghiệp vẫn tốt nhưng dòng tiền bắt đầu căng vì khách hàng thanh toán chậm.

Dữ liệu gồm Invoice, Payment, Customer và Due Date.

Người học cần xác định số tiền còn nợ và số ngày quá hạn. Sau đó phân loại công nợ thành những nhóm như chưa quá hạn, 1–30 ngày, 31–60 ngày, 61–90 ngày và trên 90 ngày.

Dashboard không nên chỉ cho biết tổng công nợ.

Hãy chỉ ra khách hàng nào chiếm phần lớn số tiền quá hạn, nhóm Sales nào đang quản lý các account này hoặc công nợ quá hạn có đang tăng theo thời gian hay không.

Một điểm rất quan trọng là đối soát tổng Accounts Receivable với số liệu nguồn hoặc sổ cái nếu dataset có cung cấp.

Dữ liệu Finance thường nhạy cảm. Portfolio nên sử dụng dữ liệu giả lập, công khai hoặc đã được ẩn danh.

16. Dự án 6: Phân tích hiệu suất Sales Pipeline

Dự án này phù hợp với Sales Analyst, Business Analyst hoặc những người muốn chứng minh khả năng làm CRM Analytics.

Bối cảnh là doanh nghiệp có Pipeline lớn nhưng Win Rate thấp và quản lý không biết các cơ hội đang bị nghẽn ở giai đoạn nào.

Dữ liệu có thể gồm Opportunity, Stage History, Lead Source, Deal Value và Sales Representative.

Người học có thể tính Conversion Rate giữa các stage, Win Rate, Average Sales Cycle và thời gian trung bình một deal nằm ở mỗi giai đoạn.

Một điểm quan trọng là phải có lịch sử thay đổi Stage hoặc snapshot theo thời gian. Nếu chỉ sử dụng trạng thái hiện tại, rất khó phân tích chính xác cách Opportunity di chuyển trong Pipeline.

Dự án cũng nên phân biệt Pipeline Value và Forecast.

Một Pipeline trị giá 100 tỷ đồng không có nghĩa doanh nghiệp sẽ thu 100 tỷ.

Một phần có thể nằm ở các Deal đã không có activity nhiều tuần hoặc đang ở giai đoạn rất sớm.

Ngoài ra, không nên kết luận Salesperson A yếu hơn B chỉ vì Win Rate thấp nếu hai người được phân bổ những nhóm khách hàng hoàn toàn khác nhau.

17. Dự án 7: Phân tích giao hàng và SLA

Logistics là một bối cảnh rất tốt để xây dự án có chiều sâu.

Giả sử khách hàng phàn nàn giao hàng chậm nhưng báo cáo cho thấy thời gian giao trung bình vẫn tương đối ổn.

Đây chính là lúc Average có thể gây hiểu nhầm.

Dữ liệu nên có Order Time, Warehouse Processing, Handover, Shipping và Delivered Time.

Người học tính On-time Delivery Rate và thời gian tại từng chặng.

Ngoài Average, nên phân tích Percentile. Ví dụ 80% đơn được giao dưới hai ngày nhưng 10% đơn cuối cùng mất hơn năm ngày.

Đó có thể là nhóm tạo ra phần lớn khiếu nại.

Dashboard nên cho phép phân tích theo Carrier, Region, Warehouse và Order Type.

Điểm khác biệt là tìm nơi phát sinh độ trễ. Đơn chậm có thể do kho chuẩn bị lâu, bàn giao chậm hoặc đơn vị vận chuyển.

Nếu timestamp bị thiếu, cần nêu rõ ảnh hưởng đến kết quả.

18. Dự án 8: Phân tích nhân sự và nghỉ việc

HR Analytics là lựa chọn tốt cho người có nền tảng nhân sự.

Bài toán có thể là một số bộ phận đang có tỷ lệ nghỉ việc tăng nhưng HR chưa hiểu rõ xu hướng.

Dữ liệu nên được ẩn danh và có thể gồm Department, Position, Hire Date, Exit Date, Tenure và một số kết quả khảo sát.

Người học cần tính Headcount theo thời điểm, New Hire, Exit và Turnover Rate.

Một lỗi phổ biến là lấy số người nghỉ chia cho Headcount cuối kỳ. Tùy mục đích, có thể cần sử dụng Headcount bình quân trong giai đoạn.

Có thể phân tích turnover theo tenure để biết nhân viên thường rời đi trong sáu tháng đầu hay sau hai năm.

Tuy nhiên, đây là dữ liệu nhạy cảm.

Portfolio nên tập trung vào xu hướng ở cấp độ nhóm thay vì cố dự đoán một cá nhân cụ thể sẽ nghỉ việc.

Không nên dùng các thuộc tính nhạy cảm nếu chúng không cần thiết cho bài toán.

19. Dự án 9: Phân tích Funnel thương mại điện tử

Dự án này đặc biệt phù hợp với Product Analyst.

Bài toán là website có nhiều lượt truy cập nhưng tỷ lệ mua hàng thấp.

Dữ liệu có thể gồm các event như Product View, Add to Cart, Begin Checkout và Purchase.

Người học phải xử lý Session, User và Event Time. Sau đó tính Conversion Rate giữa từng bước và xác định nơi người dùng rời Funnel nhiều nhất.

Ví dụ:

100.000 người xem sản phẩm.

20.000 người thêm vào giỏ.

8.000 người bắt đầu checkout.

5.000 người mua.

Nhìn vào Funnel đã có thể xác định bước nào giảm nhiều nhất.

Sau đó phân tích theo Device, Traffic Source hoặc New/Returning Customer để tìm pattern.

Nếu mobile có tỷ lệ rời khỏi checkout cao hơn desktop đáng kể, đó là một tín hiệu cần Product Team kiểm tra.

Nhưng Portfolio không nên khẳng định “mobile checkout gây ra conversion thấp” nếu chưa có thêm kiểm chứng.

Khuyến nghị phù hợp hơn là đề xuất A/B Test hoặc kiểm tra trải nghiệm ở bước này.

20. Dự án 10: Dashboard điều hành cho doanh nghiệp nhỏ

Đây là dự án phù hợp để chứng minh khả năng kết nối nhiều phòng ban.

Bối cảnh là CEO đang nhận riêng báo cáo Sales, Marketing, Finance và Inventory nhưng thiếu một góc nhìn chung.

Mục tiêu là xây một Management Dashboard với khoảng 8–12 KPI quan trọng.

Ví dụ Revenue, Gross Margin, Cash, Accounts Receivable, Marketing Spend, Customer Acquisition Cost, Inventory và Sales Pipeline.

Thách thức lớn nhất không phải tạo biểu đồ.

Đó là thống nhất định nghĩa.

Sales có thể tính doanh thu dựa trên đơn hàng. Finance lại dùng doanh thu đã ghi nhận. Marketing có thể báo conversion theo nền tảng quảng cáo.

Một Data Analyst phải xác định từng KPI có nguồn nào và business owner nào chịu trách nhiệm.

Dashboard cũng nên tập trung vào ngoại lệ.

CEO không cần nhìn 100 KPI mỗi sáng. Người quản lý cần biết chỉ số nào đang lệch đáng kể và cần kiểm tra.

Có thể bổ sung một Decision Log đơn giản: khi KPI lệch, bộ phận nào cần kiểm tra và bước tiếp theo là gì.

Đây là dự án tốt để chứng minh tư duy từ Data đến Business Decision.

PHẦN IV — CÁCH CHỌN DỰ ÁN PHÙ HỢP

21. Tận dụng nền tảng công việc trước đây

Người chuyển ngành thường nghĩ kinh nghiệm cũ không còn giá trị.

Thực tế, kinh nghiệm ngành có thể là lợi thế rất lớn.

Người từ kế toán hiểu công nợ, sổ cái và dòng tiền nên có thể xây dự án Finance Analytics sâu hơn một người chỉ mới học thuật ngữ.

Người từng làm Marketing hiểu CPL, CAC và hành trình khách hàng.

Người làm Logistics hiểu giao hàng chậm không nhất thiết chỉ do Carrier.

Người làm Sales hiểu Pipeline có nhiều Deal nhưng không đồng nghĩa Revenue sắp tăng.

Vì vậy, nếu đã có nền tảng nghiệp vụ, nên tận dụng nó để tạo ra portfolio khác biệt.

Kỹ thuật có thể học.

Hiểu business context thường cần thời gian dài hơn.

22. Chọn dự án theo vị trí muốn ứng tuyển

Một cách thực tế là đọc khoảng 20 tin tuyển dụng cho vị trí mục tiêu.

Ghi lại những kỹ năng xuất hiện nhiều.

Nếu phần lớn vị trí BI Analyst yêu cầu SQL, Power BI, Data Modeling và khả năng làm việc với stakeholder, Portfolio nên chứng minh trực tiếp những năng lực đó.

Nếu mục tiêu Product Analyst, Funnel, event data, A/B Testing và phân tích hành vi người dùng sẽ quan trọng hơn.

Không cần chạy theo từng Job Description riêng lẻ.

Hãy tìm mẫu lặp lại.

Sau đó chọn dự án có thể chứng minh những kỹ năng phổ biến nhất.

23. Xây bộ ba dự án bổ sung cho nhau

Người mới thường chỉ cần hai hoặc ba dự án tốt để bắt đầu.

Một cấu trúc hợp lý có thể là:

Dự án đầu chứng minh SQL và xử lý dữ liệu nhiều bảng.

Dự án thứ hai chứng minh Power BI, Data Modeling và khả năng giao tiếp.

Dự án thứ ba tận dụng nền tảng ngành hoặc bổ sung Python.

Ví dụ một người muốn làm Data Analyst trong Retail có thể chọn Sales & Profitability, Inventory và Customer Retention.

Người từ Finance có thể chọn Accounts Receivable, Executive Dashboard và Sales Forecast.

Các dự án nên bổ sung cho nhau thay vì cùng chứng minh một kỹ năng.

24. Dùng dataset phổ biến nhưng phải thay đổi câu hỏi

Không có vấn đề gì khi sử dụng Kaggle hoặc dataset được nhiều người dùng.

Vấn đề xảy ra khi hàng nghìn portfolio đều sử dụng cùng dataset và cùng câu hỏi.

Có thể tạo sự khác biệt bằng cách thêm dữ liệu phụ.

Ví dụ thêm Sales Target, Returns hoặc Product Cost vào dataset bán hàng.

Sau đó đặt câu hỏi mới.

Không chỉ:

“Sản phẩm nào bán nhiều nhất?”

Mà:

“Tại sao doanh thu tăng nhưng Gross Margin giảm?”

Dữ liệu phổ biến vẫn có thể tạo ra dự án tốt nếu cách đặt vấn đề và kiểm tra đủ sâu.

PHẦN V — SỬ DỤNG CÔNG CỤ CÓ CHỦ ĐÍCH

25. Excel

Excel vẫn là một công cụ rất hữu ích cho Data Analyst.

Nó phù hợp để kiểm tra nhanh, đối soát số liệu, xử lý dữ liệu nhỏ hoặc xây các bảng kế hoạch.

Trong Portfolio, Excel không cần xuất hiện chỉ để chứng minh biết VLOOKUP.

Có thể dùng một sheet để đối soát tổng Revenue, số Orders, số Customers hoặc khoảng thời gian dữ liệu.

Đây là cách cho thấy Excel được sử dụng như công cụ kiểm soát.

Một nguyên tắc tốt là hạn chế những thao tác sửa tay không thể tái lập.

Nếu dữ liệu được xử lý bằng một chuỗi bước, nên ghi lại đủ để có thể thực hiện lại.

26. SQL

SQL gần như là kỹ năng cốt lõi đối với nhiều vị trí Data Analyst.

Portfolio nên cho thấy khả năng làm việc với dữ liệu nhiều bảng, JOIN, Aggregation, CTE hoặc Window Function khi cần.

Nhưng không cần đăng hàng trăm dòng SQL chỉ để chứng minh viết nhiều code.

Hãy chọn những truy vấn quan trọng.

Ví dụ truy vấn tính Net Revenue, xây Customer Cohort hoặc xác định Sales Funnel.

Mỗi truy vấn nên có mô tả ngắn về input, output và logic.

Điều quan trọng hơn cú pháp phức tạp là kết quả đúng.

JOIN sai vẫn là JOIN sai dù câu lệnh có rất nhiều CTE.

27. Power BI

Power BI Portfolio nên chứng minh nhiều hơn khả năng kéo thả biểu đồ.

Một dự án tốt có thể thể hiện Power Query, Data Model, DAX, KPI và cách thiết kế dashboard cho người sử dụng cụ thể.

Có thể đưa một ảnh Data Model, danh sách một số measure quan trọng và dashboard cuối cùng.

Nếu chia sẻ PBIX, cần loại bỏ thông tin kết nối hoặc dữ liệu không được phép.

Một video ngắn 60–90 giây giải thích dashboard cũng có thể rất hữu ích.

Người xem cần hiểu dashboard phục vụ ai và câu hỏi nào, không chỉ thấy nó đẹp.

28. Python

Không phải Data Analyst nào cũng cần Python ở mọi dự án.

Python nên được sử dụng khi thực sự có lợi.

Ví dụ xử lý nhiều file tự động, phân tích dữ liệu linh hoạt, làm thống kê hoặc thực hiện công việc khó bằng Power BI.

Notebook nên chạy được từ đầu đến cuối.

Cấu trúc đơn giản có thể gồm đọc dữ liệu, kiểm tra, xử lý, phân tích và kết luận.

Không nên đưa Machine Learning vào chỉ để dự án trông nâng cao hơn.

Nếu bài toán chỉ cần SQL và BI, đó có thể đã là lựa chọn tốt nhất.

29. Cloud

Cloud có thể là một điểm cộng nếu vị trí mục tiêu cần làm việc với BigQuery, Snowflake, Databricks hoặc các nền tảng dữ liệu tương tự.

Một dự án nhỏ có thể đưa dữ liệu lên BigQuery rồi truy vấn bằng SQL.

Không cần xây một hệ thống Cloud phức tạp.

Mục tiêu chỉ là chứng minh người học hiểu cách làm việc với Data Warehouse trên Cloud, dataset, quyền truy cập và chi phí cơ bản.

Tuyệt đối không đưa password, token, service account hoặc connection string vào GitHub.

PHẦN VI — AI TRONG DỰ ÁN PORTFOLIO

30. AI có thể hỗ trợ ý tưởng và code

AI hoàn toàn có thể được sử dụng trong Portfolio.

Nó có thể gợi ý câu hỏi phân tích, giải thích lỗi SQL, review code hoặc đề xuất cách kiểm tra dữ liệu.

Điều quan trọng là người học phải kiểm tra kết quả.

Ví dụ AI viết một câu SQL sử dụng LEFT JOIN. Người học phải hiểu tại sao dùng LEFT JOIN, kết quả có tạo duplicate không và nếu đổi thành INNER JOIN thì dữ liệu thay đổi thế nào.

Không nên đưa vào dự án một đoạn code mà bản thân không thể giải thích.

Trong phỏng vấn, điểm quan trọng không phải “có dùng AI hay không”.

Điểm quan trọng là có kiểm soát được AI hay không.

31. AI hỗ trợ tạo dữ liệu giả lập

Nếu không có dataset phù hợp, AI có thể giúp thiết kế cấu trúc hoặc tạo dữ liệu giả lập.

Tuy nhiên, dữ liệu phải được kiểm tra.

Ví dụ nếu tạo dữ liệu bán hàng, tổng giá trị Order Details phải hợp lý so với Order Total. Ngày giao hàng không thể xảy ra trước ngày đặt hàng. Giá trị hoàn trả không thể lớn hơn số hàng đã mua nếu logic không cho phép.

Dữ liệu giả lập cần được ghi rõ là Synthetic Data.

Không nên trình bày như dữ liệu thật của một doanh nghiệp.

32. AI Agent có thể là phần mở rộng

Với người muốn thể hiện thêm khả năng AI, có thể mở rộng một dự án Data Analyst thành workflow đơn giản có Agent.

Ví dụ hệ thống mỗi ngày kiểm tra Revenue theo cửa hàng.

Nếu doanh thu giảm hơn một ngưỡng, Agent tạo bản tóm tắt và gửi cho Analyst kiểm tra.

Điểm quan trọng là Agent chỉ nên được thêm sau khi nền dữ liệu, KPI và phân tích cốt lõi đã đúng.

Một Agent thông minh trên số liệu sai vẫn tạo ra kết quả sai nhanh hơn.

Nếu Agent có khả năng gửi thông tin hoặc thực hiện action, Portfolio nên nói rõ quyền của nó và bước nào cần con người phê duyệt.

PHẦN VII — TỰ CHẤM ĐIỂM DỰ ÁN TRƯỚC KHI ĐƯA VÀO PORTFOLIO

33. Một Rubric 100 điểm đơn giản

Có thể tự đánh giá dự án theo năm nhóm, mỗi nhóm 20 điểm.

Nhóm thứ nhất là bài toán kinh doanh: mục tiêu có rõ không, người sử dụng là ai và quyết định nào được hỗ trợ?

Nhóm thứ hai là dữ liệu: nguồn có rõ không, khóa có được kiểm tra và vấn đề Data Quality có được xử lý?

Nhóm thứ ba là kỹ thuật: SQL, Power BI hoặc Python có được sử dụng đúng và có thể chạy lại?

Nhóm thứ tư là phân tích: kết luận có bằng chứng, có nêu giới hạn và không suy diễn quá mức?

Nhóm cuối cùng là giao tiếp: người không kỹ thuật có hiểu được vấn đề, phát hiện và khuyến nghị hay không?

Điểm số không phải tiêu chuẩn tuyển dụng chính thức.

Nó chỉ giúp người học tự review có hệ thống.

Nếu một dự án chưa đạt khoảng 70/100 theo chính tiêu chí của mình, có thể nên sửa trước khi đưa vào CV.

34. Review ngược từ kết luận về dữ liệu

Một cách kiểm tra rất hữu ích là bắt đầu từ kết luận.

Ví dụ:

“Nhóm sản phẩm A là nguyên nhân chính làm Gross Margin giảm.”

Sau đó hỏi:

Biểu đồ nào chứng minh?

Measure nào tạo biểu đồ đó?

Measure lấy từ bảng nào?

JOIN có đúng không?

Nguồn dữ liệu có đủ không?

Nếu không lần ngược được từ kết luận về dữ liệu, dự án đang có một mắt xích yếu.

Cách review này cũng giúp loại bỏ biểu đồ thừa.

Một chart không hỗ trợ kết luận hoặc điều tra có thể không cần xuất hiện trong dashboard.

35. Nhờ nhiều góc nhìn review

Nếu có điều kiện, nên nhờ ít nhất ba kiểu người xem dự án.

Người hiểu nghiệp vụ kiểm tra câu hỏi có thực tế không.

Người kỹ thuật kiểm tra SQL, Data Model và Data Quality.

Người không chuyên kiểm tra phần trình bày có dễ hiểu hay không.

Không nhất thiết phải có ba người khác nhau nếu mentor đủ kinh nghiệm, nhưng ba góc nhìn này đều quan trọng.

Khi nhận feedback, ưu tiên sửa lỗi số liệu và logic trước.

Màu sắc dashboard nên được xử lý sau.

PHẦN VIII — CHECKLIST TRƯỚC KHI CÔNG KHAI PORTFOLIO

36. Kiểm tra nội dung

Dự án cần có bối cảnh, câu hỏi kinh doanh, dữ liệu, cách làm, kết quả và giới hạn.

Người đọc phải hiểu dự án đang giải quyết gì mà không cần mở toàn bộ code.

Tất cả dữ liệu nhạy cảm hoặc thông tin cá nhân phải được loại bỏ.

37. Kiểm tra kỹ thuật

SQL hoặc Python phải chạy lại được.

Các đường dẫn trong GitHub phải hoạt động.

Tên file nên rõ ràng.

README cần hướng dẫn người xem bắt đầu từ đâu.

Không được đưa password, token, API key hay connection string vào repository.

38. Kiểm tra số liệu

Các KPI quan trọng cần được đối soát.

Kiểm tra khóa, số dòng và các bộ lọc.

Các tỷ lệ phải có mẫu số rõ ràng.

Đơn vị tiền tệ và thời gian phải nhất quán.

Nếu Revenue được trình bày theo triệu đồng thì không nên có biểu đồ khác sử dụng đồng mà không giải thích.

39. Kiểm tra cách trình bày

Người xem nên hiểu giá trị của dự án trong khoảng hai phút đầu tiên.

README hoặc phần giới thiệu nên ngắn gọn.

Những chi tiết kỹ thuật sâu hơn có thể đặt ở phía dưới hoặc trong repository.

Đây cũng là cách báo cáo trong doanh nghiệp thường hoạt động: lãnh đạo cần phần chính trước, người muốn kiểm tra mới đi sâu vào chi tiết.

PHẦN IX — CÁCH TRÌNH BÀY DỰ ÁN TRONG PHỎNG VẤN

40. Cấu trúc trình bày khoảng 10–12 phút

Không cần demo toàn bộ dashboard.

Hai phút đầu có thể giới thiệu bối cảnh và câu hỏi.

Hai phút tiếp theo giải thích dữ liệu và những vấn đề chính.

Ba phút trình bày phương pháp.

Ba phút dành cho hai hoặc ba insight quan trọng nhất.

Phần cuối nói về giới hạn và bước tiếp theo.

Cách trình bày này giúp nhà tuyển dụng hiểu tư duy thay vì phải xem ứng viên click từng trang Power BI.

41. Những câu hỏi nên chuẩn bị

Nhà tuyển dụng có thể không hỏi đúng câu đã luyện.

Nhưng phần lớn câu hỏi sẽ xoay quanh logic của dự án.

Tại sao chọn KPI này?

Thiếu dữ liệu được xử lý thế nào?

JOIN có tạo duplicate không?

Điều gì chưa thể kết luận?

Nếu có thêm dữ liệu, bước tiếp theo sẽ là gì?

Nếu đổi định nghĩa Customer Active từ 90 ngày xuống 60 ngày thì kết quả thay đổi thế nào?

Một ứng viên hiểu dự án thường có thể xử lý các câu hỏi này dù chưa chuẩn bị chính xác câu trả lời trước.

42. Nếu phát hiện dự án có lỗi

Không cần cố bảo vệ một con số đã biết là sai.

Một cách phản hồi chuyên nghiệp hơn là:

“Đúng, điều kiện này có thể làm duplicate một số Order. Tôi sẽ kiểm tra lại Grain của hai bảng, đo số dòng trước và sau JOIN rồi tính lại KPI để xác định mức ảnh hưởng.”

Khả năng nhận ra lỗi và biết cách sửa thường đáng tin cậy hơn việc cố chứng minh mình luôn đúng.

Trong công việc thực tế, Data Analyst cũng phải sửa lỗi.

Điều quan trọng là quy trình xử lý lỗi.

PHẦN X — HỌC DATA ANALYST QUA DỰ ÁN TẠI TECHDATA.AI

43. Project-Based Learning cần kết nối kỹ năng thành một mạch

Một chương trình Data Analyst tốt không nên dạy SQL, Power BI, Python và Cloud như những môn độc lập không liên quan.

Trong công việc thực tế, những kỹ năng này thường nằm trong cùng một workflow.

Dữ liệu được lấy từ hệ thống.

SQL được sử dụng để truy vấn.

Data Model chuẩn hóa cách tính.

Power BI giúp trực quan hóa.

Analyst kiểm tra số liệu và giải thích cho người sử dụng.

AI ngày càng được sử dụng để hỗ trợ viết truy vấn, khám phá dữ liệu hoặc tự động hóa một số bước.

Chương trình Khóa học Data Analyst tại TechData.AI được xây theo hướng kết nối Business, Data và AI thông qua dự án, để người học không chỉ biết từng công cụ riêng lẻ mà hiểu cách chúng phối hợp trong một bài toán.

44. Dự án chỉ có giá trị khi được review và sửa

Làm dự án một lần chưa đủ.

Giá trị lớn đến từ quá trình làm, nhận phản hồi, sửa rồi kiểm tra lại.

Mentor có thể phát hiện những lỗi mà người mới rất khó nhìn thấy, như JOIN sai Grain, KPI chưa đúng nghiệp vụ hoặc dashboard chưa giúp người sử dụng đưa ra quyết định.

Tuy nhiên, dự án cuối cùng vẫn phải là sản phẩm mà học viên hiểu và chịu trách nhiệm.

Portfolio không nên là sản phẩm sao chép của lớp.

Nó phải trở thành bằng chứng năng lực của từng người.

CÂU HỎI THƯỜNG GẶP

45. Cần bao nhiêu dự án để bắt đầu ứng tuyển Data Analyst?

Không có một con số bắt buộc.

Với người mới, hai đến ba dự án được làm sâu thường đã đủ để bắt đầu xây Portfolio.

Quan trọng hơn số lượng là các dự án bổ sung cho nhau và phù hợp với công việc muốn ứng tuyển.

46. Có cần đưa dashboard lên Internet không?

Không bắt buộc.

Nếu có thể deploy an toàn, dashboard online giúp nhà tuyển dụng trải nghiệm tốt hơn.

Nếu không, có thể sử dụng screenshot, video ngắn và tài liệu giải thích.

Điều quan trọng là không công khai dữ liệu hoặc thông tin kết nối nhạy cảm.

47. Có nên dùng dataset từ Kaggle?

Có.

Kaggle là nguồn dữ liệu rất hữu ích cho người học.

Tuy nhiên, nên thay đổi câu hỏi, bổ sung kiểm tra và xây phân tích của riêng mình thay vì sao chép notebook có sẵn.

Nguồn dữ liệu cũng cần được ghi rõ.

48. Dự án nhóm có được đưa vào Portfolio không?

Có, nếu trình bày rõ phần mình thực hiện.

Ví dụ phụ trách Data Cleaning, SQL và Data Model trong khi một thành viên khác làm dashboard.

Tuy nhiên, người mới vẫn nên có ít nhất một dự án cá nhân để chứng minh khả năng làm việc độc lập.

49. Portfolio có thay thế kinh nghiệm thực tế không?

Không hoàn toàn.

Một dự án giả lập không thể tái tạo đầy đủ áp lực, dữ liệu và stakeholder của môi trường doanh nghiệp thật.

Nhưng với người chưa có kinh nghiệm, Portfolio là một trong những cách tốt nhất để chứng minh nền tảng và khả năng học nghề.

Dự án càng gần với bối cảnh của vị trí mục tiêu thì càng có giá trị.

KẾT LUẬN

Một Portfolio Data Analyst tốt không được đánh giá bằng số lượng dashboard hay số công nghệ được liệt kê.

Điều quan trọng hơn là toàn bộ quá trình từ câu hỏi kinh doanh đến dữ liệu, phân tích, kiểm thử, kết luận và giao tiếp.

Một dự án tốt phải giúp người xem trả lời được:

Ứng viên có hiểu vấn đề không?

Có biết kiểm tra dữ liệu không?

Có sử dụng công cụ đúng mục đích không?

Có phân tích được điều gì có ý nghĩa không?

Có biết giới hạn của kết luận không?

Và quan trọng nhất, có thể tự giải thích những gì mình đã làm hay không?

Không cần thực hiện đủ mười dự án trong bài.

Hãy chọn hai hoặc ba bài toán phù hợp với nền tảng và vị trí muốn theo đuổi. Làm đủ sâu, kiểm tra số liệu, nhận review và sửa nhiều vòng.

Một dự án bán lẻ được làm kỹ có thể chứng minh nhiều hơn năm dashboard mẫu.

Một dự án Finance dựa trên kinh nghiệm kế toán có thể giúp ứng viên nổi bật hơn việc cố làm giống mọi người.

Một Product Funnel được kiểm tra kỹ có thể giá trị hơn một dự án Machine Learning phức tạp nhưng không rõ mục tiêu.

AI cũng có thể được sử dụng trong Portfolio, nhưng nên được xem như một công cụ hỗ trợ. Người học vẫn phải kiểm tra code, hiểu logic và chịu trách nhiệm với kết quả.

Câu hỏi cuối cùng trước khi đưa một dự án vào CV nên rất đơn giản:

Nếu nhà tuyển dụng thay một điều kiện, hỏi ngược một KPI hoặc yêu cầu kiểm tra lại số liệu, người thực hiện có thể tự giải thích và xử lý hay không?

Nếu câu trả lời là có, dự án không còn chỉ là một bài tập.

Nó đã bắt đầu trở thành bằng chứng năng lực nghề nghiệp.

Tài liệu tham khảo

TechData.AI - Leading the Future.

Tham khảo khoá học theo link: https://techdata.ai/data-analyst/

Hoàng Minh.