Dashboard cho người điều hành: Looker Studio và Power BI
Nội dung khóa học (8 bài)
Bài 1/8 · Nền tảng: dashboard để quyết định, không để trưng bày
Bài học xem thử miễn phíĐang tải bài học
Đang tải bài học
Bài 1/8 · Nền tảng: dashboard để quyết định, không để trưng bày
Bài học xem thử miễn phíMột chuỗi bán lẻ mỹ phẩm 9 cửa hàng ở TP.HCM và 3 gian hàng sàn thương mại điện tử (ví dụ minh họa) chi 48 triệu thuê đơn vị bên ngoài dựng dashboard. Sáu tuần làm việc, bốn buổi lấy yêu cầu, kết quả là 5 trang với 42 biểu đồ: doanh thu theo ngày, theo cửa hàng, theo nhóm hàng, theo nhân viên, tồn kho theo kho, lượt truy cập, tỷ lệ chuyển đổi từng sàn. Buổi bàn giao ai cũng khen đẹp. Hai tháng sau, nhật ký truy cập ghi nhận 11 lượt mở, trong đó 9 lượt là của chính người dựng khi kiểm tra kết nối.
Cái giá không dừng ở 48 triệu. Cộng thêm khoảng 60 giờ của kế toán trưởng và trưởng phòng vận hành ngồi họp mô tả yêu cầu, rồi hằng tuần thêm chừng 3 giờ ngồi đối chiếu vì con số doanh thu trên dashboard lệch với báo cáo kế toán khoảng 4%. Không ai chứng minh được bên nào đúng, nên cả hai bên đều quay về file Excel cũ của mình. Từ lúc đó, dashboard chỉ còn là một đường link trong nhóm chat.
Phần đắt nhất nằm ở chỗ khó nhìn thấy. Trong hai tháng đó, nhóm hàng chăm sóc tóc tồn khoảng 1,2 tỷ tiền hàng chậm bán, tốc độ bán giảm dần từ tuần thứ ba. Dashboard có đủ dữ liệu để thấy điều này, thậm chí có hẳn một biểu đồ tồn kho. Nhưng biểu đồ đó nằm ở trang 4, không có ngưỡng, không có màu cảnh báo, và không ai được giao nhiệm vụ mở nó. Vấn đề được phát hiện trễ khoảng 7 tuần, khi hàng đã cận hạn và phải xả với mức giảm 35%.
Câu hỏi trung tâm của bài này, và cũng là của cả khóa: điều gì làm một dashboard được mở đều đặn mỗi sáng thứ Hai, trong khi một dashboard khác, nhiều số hơn và đẹp hơn, bị bỏ quên sau ba tuần?
Dashboard không tạo ra giá trị bằng việc hiển thị số. Nó tạo ra giá trị khi rút ngắn khoảng cách từ lúc một điều bất thường xảy ra đến lúc có người làm gì đó với điều bất thường ấy. Nếu khoảng cách này không đổi sau khi dashboard lên sóng, thì bạn vừa mua một bức tranh chứ không phải một công cụ điều hành.
Phần lớn dashboard chết vì một trong năm lý do lặp đi lặp lại: nhồi mọi chỉ số có thể lấy được, đẹp nhưng không trả lời câu hỏi nào, số lệch với báo cáo khác nên mất niềm tin, phải cập nhật thủ công nên luôn cũ, và không ai chịu trách nhiệm mở. Bốn lý do đầu là lỗi thiết kế, lý do thứ năm là lỗi tổ chức. Trong thực tế chúng hay đi cùng nhau, và lý do thứ ba thường là phát súng kết liễu vì niềm tin mất rồi rất khó lấy lại.
Cách chữa bắt đầu từ chỗ trước cả khi mở công cụ: viết ra ai mở, mở lúc nào, và quyết gì sau khi xem. Từ ba câu trả lời đó mới suy ngược ra cần bao nhiêu ô, mỗi ô là số gì, ngưỡng bao nhiêu, ai xử lý khi vượt ngưỡng. Thứ tự này quan trọng vì nó biến dashboard từ một sản phẩm hiển thị thành một phần của quy trình điều hành.
Một nguồn lãng phí âm thầm khác là nhầm tầng. Bảng điều hành cho chủ doanh nghiệp cần ít số và có ngưỡng rõ. Báo cáo vận hành cho trưởng bộ phận cần chi tiết hơn, chia theo cửa hàng, theo kênh, theo nhân viên. Báo cáo phân tích chỉ mở khi cần đào sâu một câu hỏi cụ thể và thường không cần đẹp. Trộn ba tầng vào một trang tạo ra thứ vừa thừa với người này vừa thiếu với người kia, và đó là hình dạng phổ biến nhất của dashboard 42 biểu đồ ở đầu bài.
Bài này đặt khung và ra yêu cầu, chưa động tới công cụ. Cách chuẩn bị dữ liệu nằm ở Bài 02, dựng trên Looker Studio ở Bài 03, Power BI ở Bài 04, chọn biểu đồ và bố cục ở Bài 05.
Thử một phép kiểm tra đơn giản với dashboard hiện có của bạn: che tên biểu đồ đi, hỏi người dùng "nếu con số này xấu đi, anh chị sẽ làm gì trong 48 giờ tới?". Nếu câu trả lời là "để tôi xem thêm", ô đó chưa phải công cụ quyết định. Nếu câu trả lời là "gọi cho nhà cung cấp X hỏi lịch giao", ô đó đã có chân đứng.
Kho lưu số cũng có ích, nhưng nó là vai trò của hệ thống nguồn và của file dữ liệu, không phải của trang đầu tiên mà giám đốc mở lúc 7 giờ sáng. Nhầm hai vai trò này là gốc rễ của thói quen "có dữ liệu gì thì đưa lên hết cho chắc". Đưa lên hết nghe có vẻ an toàn, nhưng nó chuyển toàn bộ công việc chọn lọc sang cho người xem, đúng vào lúc người xem có ít thời gian nhất.
Cách nói ngắn gọn để nhớ: mỗi ô trên trang là một lời hứa rằng có người sẽ hành động khi ô đó đổi màu. Không có lời hứa đó thì ô chỉ là trang trí.
| Kiểu | Dấu hiệu quan sát được | Gốc rễ |
|---|---|---|
| Nhồi mọi chỉ số | Trang cuộn dài, trên 20 biểu đồ, người xem phải tìm mới thấy số mình cần | Lấy yêu cầu bằng cách hỏi "anh chị muốn xem gì" rồi gom hết |
| Đẹp nhưng rỗng | Bố cục gọn, màu hài hòa, nhưng không ô nào dẫn tới việc phải làm | Bắt đầu từ mẫu có sẵn thay vì từ câu hỏi điều hành |
| Số mất niềm tin | Câu hỏi quen thuộc trong họp: "số này lấy ở đâu, sao khác báo cáo kế toán" | Không thống nhất định nghĩa và nguồn trước khi vẽ |
| Luôn cũ | Góc trang ghi ngày cập nhật cách đây 9 ngày, ai đó phải tải file và dán tay | Quy trình cập nhật phụ thuộc một người rảnh |
| Vô chủ | Không ai mở trong 14 ngày, cũng không ai thấy thiếu | Không gắn vào nhịp họp, không ai chịu trách nhiệm |
Kiểu thứ nhất và thứ hai sinh ra ở giai đoạn thiết kế, thường vì người dựng muốn chiều lòng tất cả các bên. Kiểu thứ ba nguy hiểm nhất: một lần lệch số không giải thích được là đủ để người xem quay lại file cũ và không quay ra nữa, dù sau đó bạn sửa đúng. Kiểu thứ tư giết dashboard chậm hơn, bằng cách dạy người xem rằng mở ra cũng chỉ thấy số của tuần trước. Kiểu thứ năm thì hiếm khi được thừa nhận, vì không ai muốn nhận mình là người bỏ quên.
| Tầng | Người đọc chính | Nhịp mở | Số lượng ô hợp lý | Câu hỏi tiêu biểu |
|---|---|---|---|---|
| Bảng điều hành | Chủ doanh nghiệp, ban giám đốc | Mỗi sáng hoặc đầu tuần, dưới 4 phút | Khoảng 5-8 ô, có ngưỡng | Tuần này có gì lệch kế hoạch tới mức tôi phải can thiệp |
| Báo cáo vận hành | Trưởng bộ phận, quản lý cửa hàng, phụ trách kênh | Hằng ngày tới hằng tuần | Khoảng 10-20 ô, chia nhỏ theo chiều | Cửa hàng nào, kênh nào, mã hàng nào đang kéo số xuống |
| Báo cáo phân tích | Người phụ trách phân tích, kế toán quản trị | Khi có câu hỏi cụ thể | Không giới hạn, thường là bảng và bộ lọc | Vì sao biên lợi nhuận nhóm hàng A giảm 3 điểm trong quý |
Nhầm tầng có hai hướng và cả hai đều tốn kém. Đưa chi tiết cấp vận hành lên bảng điều hành khiến chủ doanh nghiệp phải tự lọc nhiễu, và người bận thì sẽ ngừng mở. Ngược lại, đưa bảng điều hành cho trưởng bộ phận dùng thì họ thấy số tổng đang xấu nhưng không biết xấu ở đâu, nên vẫn phải quay về file chi tiết, và dashboard trở thành một bước thừa.
Một dashboard tốt hoàn toàn có thể phục vụ hai tầng, nhưng bằng cách xếp lớp chứ không trộn: trang đầu là tầng điều hành, các trang sau hoặc thao tác đào sâu dành cho tầng vận hành. Kỹ thuật xếp lớp bằng bộ lọc và drill-down nằm ở Bài 06.
Đây là đơn vị nhỏ nhất của một dashboard sống. Mỗi ô trên trang phải trả lời được ba dòng sau, viết bằng câu đầy đủ, trước khi ai đó chạm vào công cụ.
| Thành phần | Yêu cầu | Ví dụ cho một nhà phân phối |
|---|---|---|
| Câu hỏi điều hành | Một câu hỏi có người thật đang cần trả lời, đủ hẹp để một con số trả lời được | Tiền hàng đang bị khách nợ quá hạn có tăng so với tháng trước không |
| Chỉ số và ngưỡng | Số cụ thể, kèm mức bình thường và mức phải chú ý | Công nợ quá hạn trên 30 ngày, bình thường dưới 800 triệu, chú ý khi vượt 1 tỷ |
| Hành động khi vượt | Ai làm gì, trong bao lâu | Trưởng phòng kinh doanh rà 5 khách nợ lớn nhất và báo phương án thu trong 3 ngày làm việc |
Phần hay bị bỏ qua là ngưỡng. Không có ngưỡng, người xem phải tự nhớ mức nào là bình thường, mà trí nhớ về số của tuần trước thì rất kém. Có ngưỡng, mắt chỉ cần quét màu và dừng lại ở chỗ khác thường. Đây cũng là lý do một bảng điều hành 6 ô có ngưỡng thường hữu ích hơn một trang 30 biểu đồ không ngưỡng.
Lưu ý ranh giới: chọn chỉ số nào là đúng, định nghĩa nó ra sao, tính từ trường dữ liệu nào, đó là nội dung của khóa "Đo lường để quyết định" trong Học viện. Khóa này giả định bạn đã có danh sách chỉ số và tập trung vào việc đưa chúng lên một trang mà người ta thật sự dùng.
| Khoản chi phí | Cách ước tính | Ví dụ minh họa cho chuỗi 9 cửa hàng |
|---|---|---|
| Công dựng | Phí thuê ngoài hoặc số giờ nội bộ nhân chi phí giờ | 48 triệu thuê ngoài, cộng 60 giờ nội bộ |
| Giờ tranh luận số | Số buổi họp có tranh luận nguồn số nhân số người nhân thời lượng | Khoảng 3 giờ mỗi tuần cho 3 người, trong 8 tuần |
| Quyết định trễ | Giá trị bị ảnh hưởng nhân số tuần phát hiện trễ | Xả 1,2 tỷ hàng chậm bán với mức giảm 35% |
Hai khoản đầu dễ nhìn và thường bị đem ra tranh luận. Khoản thứ ba lớn hơn nhiều nhưng ít khi được ghi vào sổ, vì nó không có hóa đơn. Khi bạn cân nhắc có nên dựng lại dashboard hay không, hãy ước tính cả ba, và nhớ rằng phần lớn giá trị của việc dựng lại nằm ở khoản thứ ba chứ không phải ở việc tiết kiệm công dựng.
Trước khi mở Looker Studio hay Power BI, bạn viết một trang giấy. Trang này giữ vai trò hợp đồng giữa người dùng và người dựng, và nó là thứ giúp bạn từ chối yêu cầu thêm biểu đồ một cách có lý lẽ.
Khối 6 là cầu nối sang Bài 02, nơi bạn xử lý chuyện gộp nhiều nguồn lệch định dạng ngày và đơn vị.
Bước 5 có một quy tắc cứng đáng giữ: chốt số ô tối đa TRƯỚC khi vẽ. Với bảng điều hành, con số hợp lý cho SME Việt Nam thường là 6-8 ô trên một màn hình, không phải cuộn. Giới hạn này ép bạn xếp hạng, và việc xếp hạng chính là phần khó nhất của thiết kế dashboard.
Trước khi giữ một ô lại trên bản đặc tả, hỏi ba câu và yêu cầu câu trả lời cụ thể:
Một ô trượt câu 1 nghĩa là bạn đang vẽ cho một người dùng tưởng tượng. Trượt câu 2 thì ô sẽ chỉ được liếc qua chứ không được dùng. Trượt câu 3 là dấu hiệu ô đó thuộc tầng phân tích, nên chuyển xuống báo cáo chi tiết thay vì chiếm chỗ trên trang đầu.
Dùng cây này mỗi khi có người đề nghị thêm một biểu đồ vào trang chính. Phần lớn đề nghị sẽ rơi vào nhánh vận hành hoặc phân tích, và bạn có chỗ để đặt chúng thay vì phải nói không suông.
Doanh thu khoảng 180 tỷ mỗi năm, 220 khách hàng công nợ, 6 nhân viên kinh doanh. Trước đây họ có một báo cáo Power BI 3 trang do một bạn thực tập dựng, gồm 31 biểu đồ. Giám đốc mở lần cuối cách thời điểm rà soát 5 tuần.
Nhóm làm lại bắt đầu bằng phỏng vấn 25 phút với giám đốc, hỏi đúng một câu: tuần vừa rồi anh đã ra những quyết định nào cần số. Câu trả lời cho ra bốn quyết định lặp lại: duyệt hay không duyệt đơn hàng cho khách đang nợ, có đẩy hàng cận hạn xuống nhóm khách nào, có điều chỉnh chỉ tiêu cho nhân viên nào, và có nhập thêm nhóm hàng nào. Bốn quyết định này sinh ra sáu ô, trong đó ô quan trọng nhất là công nợ quá hạn trên 30 ngày kèm ngưỡng 1 tỷ và tên người xử lý.
Sau 10 tuần dùng nhịp đều, số ngày thu tiền bình quân giảm từ khoảng 58 ngày xuống khoảng 47 ngày. Điều đáng chú ý là dashboard mới có ít số hơn hẳn bản cũ, còn phần chi tiết theo từng khách được đẩy xuống một báo cáo vận hành riêng cho phòng kinh doanh. Bài học rút ra: giá trị đến từ việc gắn ngưỡng và người xử lý, không đến từ việc thêm biểu đồ.
Doanh thu khoảng 42 tỷ mỗi năm. Chủ chuỗi từng tự dựng một dashboard Looker Studio 28 biểu đồ, cập nhật bằng cách mỗi sáng tải file từ phần mềm bán hàng rồi dán vào Google Sheets. Được 3 tuần thì việc dán tay bị bỏ vào những ngày bận, và tới tuần thứ 6 thì dừng hẳn.
Khi làm lại, họ đổi thứ tự ưu tiên: trước khi bàn tới biểu đồ, họ chốt rằng chỉ giữ những số nào lấy được tự động, và chấp nhận bỏ hai chỉ số hay được nhắc tới nhưng phải nhập tay. Trang mới có 5 ô: doanh thu ngày so với cùng kỳ tuần trước, tỷ lệ chi phí nguyên vật liệu, số hóa đơn theo khung giờ, tồn nguyên liệu sắp hết, và chi nhánh thấp nhất tuần. Mỗi ô có ngưỡng, ô nào vượt ngưỡng thì đổi màu.
Ba tháng sau, chuỗi phát hiện một chi nhánh có tỷ lệ chi phí nguyên vật liệu cao hơn mặt bằng chung khoảng 4,5 điểm phần trăm, kéo dài đã lâu nhưng trước đây bị chìm trong bảng tổng. Xử lý xong định lượng và hao hụt, mức chênh còn khoảng 1,2 điểm. Bài học: một dashboard 5 ô chạy tự động có ích hơn một dashboard 28 biểu đồ phụ thuộc vào việc ai đó nhớ dán file. Cách dựng lịch cập nhật tự động nằm ở Bài 07.
Lấy yêu cầu bằng câu hỏi "anh chị muốn xem gì". Câu này mời mọi người liệt kê, và ai cũng sẽ liệt kê. Cách sửa: hỏi về quyết định gần nhất họ đã ra và số nào thiếu lúc đó, rồi suy ngược ra chỉ số. Hỏi về quá khứ cụ thể luôn cho câu trả lời chính xác hơn hỏi về mong muốn.
Vẽ trước, thống nhất định nghĩa sau. Khi doanh thu trên dashboard tính cả đơn hoàn còn kế toán trừ đơn hoàn, hai bên sẽ lệch và niềm tin mất trong một buổi họp. Cách sửa: chốt định nghĩa và nguồn cho từng ô ngay trong bản đặc tả, ghi rõ có trừ đơn hoàn hay không, có gồm thuế hay không.
Để trang đầu không có ngưỡng. Không ngưỡng thì người xem phải tự phán đoán, và mỗi người sẽ phán đoán khác nhau. Cách sửa: mỗi ô đều phải có mức bình thường và mức chú ý, lấy từ số thực tế 3-6 tháng gần nhất chứ không lấy từ cảm giác.
Giao dashboard cho người không có quyền hành động. Trưởng bộ phận nhìn thấy vấn đề nhưng phải xin ý kiến ba cấp thì tốc độ phản ứng vẫn chậm như cũ. Cách sửa: ghi tên người xử lý ngay cạnh ngưỡng, và xác nhận với người đó trước khi phát hành.
Chấp nhận cập nhật thủ công như một giải pháp tạm. Giải pháp tạm này thường sống được 4-6 tuần rồi tắt lặng. Cách sửa: nếu một số chưa lấy tự động được, hoặc bỏ số đó ở phiên bản đầu, hoặc ghi rõ tần suất nhập tay và người chịu trách nhiệm ngay trên trang.
Không gắn dashboard vào một cuộc họp cố định. Công cụ không tự tạo ra thói quen. Cách sửa: chọn một cuộc họp có sẵn, ví dụ họp đầu tuần, và quy định 4 phút đầu tiên nhìn vào trang này. Cách thiết kế nhịp họp và cách đi từ số tới quyết định được dạy kỹ trong khóa "Ra quyết định dữ liệu cho CEO"; ở khóa này bạn chỉ cần chốt thời điểm và người chủ trì.
Lấy dashboard hoặc file báo cáo đang dùng ở doanh nghiệp bạn. Với từng biểu đồ, điền vào bảng: tên ô, người xem, lần gần nhất nó làm ai đó đổi quyết định, ngưỡng hiện có hay không. Sau đó xếp mỗi ô vào một trong ba nhóm: giữ, chuyển xuống báo cáo vận hành, bỏ.
Rubric: đạt khi có ít nhất 10 ô được đánh giá, mỗi ô có kết luận rõ ràng, và tỷ lệ ô bị bỏ hoặc chuyển xuống ít nhất là 30%. Nếu bạn giữ lại gần như toàn bộ, khả năng cao là chưa dám xếp hạng.
Chọn hai người sẽ mở dashboard sắp dựng. Hỏi mỗi người ba câu trong 20 phút: tuần vừa rồi anh chị ra những quyết định nào cần số, lúc đó thiếu thông tin gì, và nếu có một con số duy nhất hiện lên mỗi sáng thì con số đó nên là gì. Ghi nguyên văn câu trả lời.
Rubric: đạt khi thu được ít nhất 5 quyết định lặp lại có thật, mỗi quyết định gắn với một tình huống cụ thể trong 30 ngày gần nhất. Câu trả lời chung chung kiểu "cần nhìn tổng quan tình hình" chưa tính là đạt, hãy hỏi tiếp cho tới khi ra được tình huống.
Dựa trên kết quả hai bài trên, viết bản đặc tả theo sáu khối ở mục 5. Giới hạn tối đa 8 ô cho tầng điều hành. Với mỗi ô ghi đủ: câu hỏi, chỉ số, mức bình thường, mức chú ý, người xử lý, nguồn dữ liệu, độ trễ chấp nhận được.
Rubric: đạt khi mọi ô đều qua bài kiểm tra ba câu ở mục 5.3, số ô không vượt 8, và ít nhất 6 ô có nguồn dữ liệu lấy được mà không cần nhập tay. Bản đặc tả này chính là phần nộp đầu tiên của Capstone, nên hãy lưu lại ở nơi bạn sẽ tìm thấy vào tuần 4.
1. Một trang có 30 biểu đồ, tất cả đều lấy dữ liệu tự động và số liệu đều chính xác. Nó có thể vẫn hỏng không, vì sao?
Có. Chính xác và tự động mới giải quyết được hai trong năm kiểu chết. Trang này vẫn có thể rơi vào kiểu nhồi mọi chỉ số và kiểu đẹp nhưng rỗng, vì người xem không biết nhìn vào đâu trước và không có ngưỡng nào chỉ ra điều gì đang bất thường.
2. Giám đốc yêu cầu thêm biểu đồ doanh thu theo từng nhân viên vào trang điều hành. Bạn xử lý thế nào?
Chạy cây quyết định ở mục 5.4. Câu hỏi này thường thuộc tầng vận hành vì cần chia nhỏ theo chiều và người xử lý là trưởng phòng kinh doanh. Đề xuất đặt nó ở báo cáo vận hành, còn trang điều hành chỉ giữ một ô tổng kèm ngưỡng, ví dụ số nhân viên không đạt 80% chỉ tiêu tuần.
3. Vì sao ngưỡng lại quan trọng hơn việc biểu đồ đẹp?
Vì ngưỡng chuyển việc phán đoán từ trí nhớ sang quy tắc. Người xem chỉ cần quét màu và dừng ở chỗ khác thường, thay vì phải nhớ mức bình thường của tuần trước. Không có ngưỡng, cùng một con số sẽ được ba người diễn giải theo ba hướng trong cùng một buổi họp.
4. Trong ba khoản chi phí của một dashboard hỏng, khoản nào thường bị bỏ sót và vì sao?
Khoản quyết định trễ. Nó không có hóa đơn nên không vào sổ, trong khi phí dựng và giờ họp thì thấy ngay. Đây cũng là khoản thường lớn nhất, ví dụ nhóm hàng chậm bán 1,2 tỷ phát hiện trễ 7 tuần rồi phải xả giảm 35%.
5. Bạn có một chỉ số rất hữu ích nhưng phải nhập tay mỗi tuần. Đưa lên trang điều hành hay không?
Cân nhắc theo tuổi thọ chứ không theo mức hữu ích. Nếu chưa có người chịu trách nhiệm nhập với cam kết rõ, khả năng cao nó dừng sau 4-6 tuần và kéo niềm tin của cả trang xuống. Lựa chọn an toàn là để chỉ số đó ở báo cáo riêng, hoặc ghi rõ trên trang tần suất cập nhật và tên người phụ trách.
6. Làm sao biết dashboard mới của bạn đang sống hay đang chết dần?
Nhìn ba dấu hiệu trong 30 ngày đầu: số lượt mở của đúng những người trong danh sách người dùng, số lần một ô vượt ngưỡng dẫn tới một việc được giao, và số lần trong họp có người hỏi lại nguồn số. Dấu hiệu thứ hai là quan trọng nhất, vì nó đo đúng thứ dashboard sinh ra để làm.
Capstone của khóa là một dashboard điều hành một trang chạy trên dữ liệu thật của bạn. Bài này đóng góp mảnh đầu tiên và cũng là mảnh quyết định chất lượng của mọi mảnh sau: bản đặc tả dashboard, gồm danh sách người dùng cụ thể kèm thời điểm mở, danh sách câu hỏi điều hành lấy từ các quyết định lặp lại hằng tuần, và với mỗi câu hỏi là một ngưỡng cùng một hành động có tên người xử lý. Hãy giữ bản đặc tả này ở dạng một trang, tối đa 8 ô, và mang theo suốt khóa. Bài 02 sẽ dùng cột nguồn dữ liệu trong bản đặc tả để quyết định phải chuẩn bị những bảng nào, và tới tuần 4 bạn sẽ chấm dashboard của mình bằng chính bản đặc tả đã viết hôm nay.
Khóa học còn 7 bài. Tạo tài khoản miễn phí để mở toàn bộ bài học, làm quiz và lưu tiến độ.