Thống kê học trí tuệ nhân tạo dành cho người không chuyên ngành
arigaram
Thấu hiểu bản chất của thống kê cơ bản cần thiết cho việc phát triển và ứng dụng trí tuệ nhân tạo mà không cần đến một công thức hay một dòng mã nào.
Nhập môn
AI
Giúp rèn luyện 'tư duy cấu trúc' vấn đề.
36 học viên
Độ khó Nhập môn
Thời gian Không giới hạn
Cách tìm ra vấn đề thực sự ẩn sau các yêu cầu, đòi hỏi, phản hồi của người dùng và đánh giá mã nguồn (code review)
Cách diễn đạt vấn đề thực sự thành một vấn đề có cấu trúc bằng cách sử dụng các công thức phát biểu vấn đề.
Cách tìm ra nguyên nhân gốc rễ của vấn đề
Khái niệm triết học mang tên 'vấn đề hóa' (problematization), giúp thấu suốt bản chất từ hiện tượng.
Nhiều công cụ khác nhau để thực hiện việc 'vấn đề hóa'
Ngày 6 tháng 3 năm 2026
Nói chung, tôi đã cải thiện nội dung và tài liệu bài giảng. Tôi sẽ thay thế các bài giảng bằng cách đánh dấu chúng là [Phiên bản thứ 2].
Ngày 2 tháng 1 năm 2026
Chúng tôi đã bắt đầu công việc cải thiện chất lượng âm thanh của video và bổ sung nội dung bài giảng. Có thể sẽ mất một chút thời gian để cải thiện toàn bộ các bài học. Đối với những bài học đã hoàn tất việc cải thiện, chúng tôi sẽ đánh dấu '[Đã cải thiện âm thanh]' ở trước tên bài học.
Điểm khởi đầu của sự hợp tác, phân tích yêu cầu và review code dành cho các nhà phát triển mới và cấp junior!
Những năng lực cơ bản mà PM/PO nên khuyến khích tất cả các thành viên trong nhóm thực hiện để ngăn chặn 'lãng phí phát triển'!
Các năng lực cơ bản liên quan đến công cụ cộng tác, kỹ năng mềm, khả năng giải quyết vấn đề, v.v.!
"Bản kế hoạch quá mơ hồ nên tôi không biết mình phải tạo ra cái gì nữa."
"Tôi đã nhận được phản hồi từ buổi review, nhưng tôi không biết chính xác mình nên sửa ở đâu."
"Đến lúc định viết code thì… mình đang định giải quyết vấn đề gì ấy nhỉ?"
"Khi tôi đặt câu hỏi, họ lại hỏi ngược lại rằng 'Vậy vấn đề là gì?'."
Cốt lõi của tất cả sự nhầm lẫn này là do không thể định nghĩa chính xác vấn đề. Các nhà phát triển liên tục đối mặt với các vấn đề. Tuy nhiên, chỉ khi có thể nhìn nhận chính xác và định nghĩa được vấn đề đó thì việc giải quyết đúng đắn mới bắt đầu.
Yêu cầu mơ hồ: Các lập trình viên mới thường nhận được những yêu cầu không rõ ràng trong dự án. Ví dụ, khi nhận được chỉ thị mơ hồ như “hãy tạo một widget”, họ sẽ cảm thấy bối rối không biết cụ thể nên triển khai chức năng nào. Theo một blog dành cho lập trình viên, những nhân viên mới thường gặp khó khăn do “chỉ thị không rõ ràng” (vague instructions) và thiếu sự hướng dẫn đầy đủ (codeanywhere.com).
Thiếu kinh nghiệm: Do ít kinh nghiệm làm việc nên họ gặp khó khăn trong việc phân tích vấn đề một cách hệ thống hoặc tự mình tìm kiếm thông tin cần thiết. Như một ví dụ thực tế, một nhà phát triển mới vào nghề đã gặp khó khăn trong việc quyết định xem nên tự mình giải quyết đến mức nào và chỉ sau khi cố gắng tự giải quyết trong một thời gian quá dài, họ mới được dạy rằng nên đặt câu hỏi (rachsmith.com). Sự không chắc chắn này dẫn đến cảm giác lo lắng (hội chứng kẻ giả mạo), gây cản trở việc học hỏi và cộng tác.
Khoảng cách giao tiếp: Nếu thiếu kiến thức chuyên môn (domain) hoặc bối cảnh kinh doanh, bạn sẽ không thể nắm bắt chính xác vấn đề cốt lõi của các yêu cầu. Trong cộng đồng phát triển, cũng có những chỉ ra rằng việc thiếu kiến thức chuyên môn dẫn đến hiểu lầm yêu cầu (kedin.com), điều này sớm muộn cũng dẫn đến việc triển khai sai và phải làm lại.
Phương pháp tư duy thực tế để sắp xếp các yêu cầu mơ hồ một cách rõ ràng và thiết lập vấn đề cốt lõi
Phương pháp đặt câu hỏi để rút ra vấn đề từ các yêu cầu
5 tiêu chí để biến một ‘vấn đề’ trở thành vấn đề thực sự
Kỹ thuật tạo sự đồng cảm ngay cả với những đồng đội bất đồng quan điểm
Phương pháp sơ đồ hóa để ‘định nghĩa’ và ‘cấu trúc hóa’ vấn đề
Kỹ thuật hỏi lại chính xác khi review code, họp kế hoạch và bàn giao công việc
15 mẫu hình chính
Trường hợp lời nói của khách hàng hoặc người lập kế hoạch quá mơ hồ khiến bạn không biết phải tạo ra cái gì
Ví dụ: “UX hơi tệ”, “Chậm quá”, “Hãy làm cho nó trực quan hơn một chút”
→ Trạng thái thiếu khả năng chuyển đổi yêu cầu thành vấn đề cụ thể
Yêu cầu: "Hãy làm cho UX tốt hơn nữa đi"
Phản hồi: "Họ chỉ bảo là làm cho UX tốt hơn thôi..... nghĩa là sao nhỉ?"
“Bạn đã bao giờ khựng lại trước câu nói ‘Chỉ cần trực quan hơn một chút thôi’ chưa? Hãy bắt đầu học kỹ năng biến những yêu cầu mơ hồ thành vấn đề rõ ràng ngay từ bây giờ.”
Kỹ năng phân tích và cấu trúc hóa vấn đề vẫn chưa thành thạo
Trường hợp chỉ dừng lại ở mức độ ghi chép lại lời của người lập kế hoạch
→ Cần có kỹ năng để có thể tự mình định nghĩa vấn đề
Yêu cầu: Tính năng 'OO' - trạng thái chưa quyết định. Sẽ sớm được quyết định.
Phản hồi: "Liệu có ổn không khi cứ tiếp tục phát triển trong trạng thái hiện tại khi một vài tính năng vẫn chưa được quyết định?"
“Có phải bạn chỉ đang làm đúng theo những gì được giao? Hãy trưởng thành để trở thành một nhà phát triển biết cách diễn giải kế hoạch và tự mình định nghĩa vấn đề.”
Thực hiện tốt các tính năng nhưng không giải thích được tại sao tính năng đó lại cần thiết
Gặp khó khăn trong việc thiết kế mục đích phát triển và bối cảnh vấn đề
→ Từ nhà phát triển → Người giải quyết vấn đề → Người muốn phát triển thành người thiết lập vấn đề
Yêu cầu: Kích thước nút + 10 pixel
Phản hồi: "Cái đó ... chỉ là tôi nghĩ làm theo cách đó thì sẽ tốt hơn ..."
“Nếu bạn có thể hiện thực hóa tính năng nhưng không thể giải thích được lý do? Đây chính là lúc bạn cần một tư duy thấu suốt bản chất của vấn đề.”
Lời nói qua lại rất nhiều, nhưng sự đồng thuận về việc “vấn đề là gì” vẫn chưa được hình thành
Phản hồi bị lặp đi lặp lại hoặc xung đột giao tiếp xảy ra thường xuyên
→ Những người muốn cấu trúc hóa các ngôn ngữ khác nhau để tạo nên trọng tâm cho sự hợp tác
Yêu cầu: "Làm ơn hãy làm cho nó có cảm giác trực quan hơn"
Phản hồi: "Tại sao nhà thiết kế cứ liên tục nói về mấy cái 'cảm giác' như vậy nhỉ .... ?"
“Bạn có cảm thấy mình không cùng tiếng nói với người lập kế hoạch (Planner) không? Khi sắp xếp ngôn ngữ của nhau thành các ‘vấn đề’, sự hợp tác sẽ thay đổi.”
Nhà phát triển đang trên đà phát triển với vai trò cần định nghĩa vấn đề và đưa ra định hướng.
Cần có khả năng cấu trúc hóa những yêu cầu mơ hồ thành công việc cho nhóm
→ Xác định vấn đề chính là sự khởi đầu của năng lực lãnh đạo
Yêu cầu: Phù hợp với cấu trúc [Yêu cầu thông tin (Request) > Nguyên nhân (Cause) > Tình huống người dùng (User Situation)] ...
Phản hồi: "Để biến việc này thành nhiệm vụ của nhóm, mình nên định nghĩa nó như thế nào đây?"
“Khả năng cấu trúc hóa những yêu cầu mơ hồ thành công việc cụ thể chính là bước đi đầu tiên để bạn trở thành một nhà phát triển dẫn dắt đội ngũ.”
Khóa học này là một khóa học thực sự cần thiết cho tất cả các nhà phát triển, những người đang trăn trở rằng “Tôi có thể viết mã, nhưng tôi không biết mình nên viết cái gì”.
Đặc biệt, đây có thể coi là năng lực thiết yếu đối với các nhân viên mới ~ nhà phát triển cấp dưới có 3 năm kinh nghiệm.
Câu hỏi về thu thập yêu cầu: Trên các diễn đàn lập trình viên hoặc Reddit, thường xuyên xuất hiện các bài đăng của những người mới vào nghề hoặc đang chuẩn bị xin việc hỏi rằng "Làm thế nào để thu thập và phân tích yêu cầu?". Ví dụ, một sinh viên khoa khoa học máy tính đã tìm kiếm lời khuyên từ các lập trình viên tiền bối bằng câu hỏi "Trong thực tế, làm thế nào để thu thập yêu cầu từ các bên liên quan?" (reddit.com). Điều này cho thấy nhu cầu về việc học cách để có được những yêu cầu rõ ràng trong các dự án thực tế.
Nhấn mạnh vai trò: Theo lời khuyên từ các nhà phát triển dày dạn kinh nghiệm, cốt lõi của phát triển phần mềm là “định nghĩa vấn đề (Problem definition)” và một chuyên gia thực thụ cần có khả năng định nghĩa chính xác các yêu cầu (medium.com). Trong cộng đồng nhà phát triển, những ý kiến nhấn mạnh tầm quan trọng của việc định nghĩa vấn đề như thế này cũng thường xuyên được tìm thấy.
Nhu cầu đào tạo: Trên các blog dành cho nhà phát triển tại Hàn Quốc, khả năng định nghĩa vấn đề được coi là "kỹ năng cơ bản" (medium.com), đồng thời chỉ ra rằng khi phân tích dữ liệu hoặc thiết kế hệ thống, việc định nghĩa vấn đề cần giải quyết trước tiên là điều bắt buộc hơn cả các công cụ (inflearn.com, velog.io). Những bài viết này làm nổi bật sự cần thiết của kỹ năng định nghĩa vấn đề đối với người học.
Phương pháp tư duy dựa trên thực tế công việc:
Cấu trúc xoay quanh các ví dụ về vấn đề thực tế gặp phải trong quá trình hợp tác làm việc.
Bài giảng ngắn gọn và rõ ràng:
Mỗi bài học thường được thiết kế dưới 10 phút (có ngoại lệ), giúp người học có thể tập trung cao độ.
Huấn luyện cấu trúc tư duy:
Bài giảng tập trung vào các trang trình bày (slide) giúp hệ thống hóa một cách trực quan "luồng tư duy" định nghĩa vấn đề.
Ví dụ thực tế:
Bao gồm phương pháp đối thoại giúp chuyển đổi những phản hồi mơ hồ và kế hoạch trừu tượng thành các vấn đề rõ ràng.
Thiết lập vấn đề là gì – Điểm khởi đầu của việc giải quyết vấn đề
Yêu cầu mơ hồ, sai lầm bắt đầu từ đâu
5 tiêu chí để biến vấn đề thành một vấn đề thực thụ
Kỹ thuật hỏi câu "Vậy vấn đề là gì?" theo một cách khác
Review code, lập kế hoạch, điều phối lịch trình… mọi khoảnh khắc mà việc thiết lập vấn đề được áp dụng
Bạn có thể tự mình cấu trúc và sắp xếp ngay cả những yêu cầu gây nhầm lẫn.
Bạn có thể trở thành một lập trình viên nắm bắt trọng tâm chỉ với một câu hỏi.
Giảm thiểu những hiểu lầm không đáng có khi hợp tác trong công việc và có thể dẫn dắt cuộc đối thoại chính xác
Bạn cũng có thể chuyển đổi các phản hồi đánh giá từ những lời chỉ trích đơn thuần thành những vấn đề có thể giải quyết được.
Công việc của một nhà phát triển luôn bắt đầu từ việc nhận được 'yêu cầu'. Tuy nhiên, hầu hết các yêu cầu đều mơ hồ và không rõ ràng. Nếu không thể chuyển đổi chúng thành một vấn đề chính xác, kế hoạch sẽ bị sai lệch, việc phát triển sẽ trở nên vô ích và tiến độ sẽ bị trì hoãn.
Ví dụ: “Hãy làm nút to hơn một chút” →→ Tại sao? Cho ai? Vấn đề là gì?
Phần khó khăn nhất đối với các nhà phát triển mới vào nghề hoặc cấp độ junior không phải là việc triển khai đơn thuần, mà là năng lực phán đoán 'cần phải triển khai cái gì'. Khóa học này sẽ tập trung chính xác vào điểm đó.
Phân tích yêu cầu, review code, giao tiếp, thảo luận với PM… tất cả đều sẽ diễn ra trôi chảy nếu định nghĩa vấn đề tốt. Khóa học này sẽ huấn luyện cho bạn phương pháp tư duy để lắng nghe và rút ra bản chất.
Đây không phải là lý thuyết suông không có thực hành, mà cung cấp công thức phát biểu vấn đề, tiêu chuẩn phản hồi, kỹ thuật đặt câu hỏi, v.v. có thể áp dụng ngay vào công việc thực tế.
Tóm lại, khóa học này giúp bạn trở thành một lập trình viên có khả năng đưa ra những phán đoán và phát ngôn rõ ràng, không còn bị khựng lại trước những câu hỏi như “Tại sao chúng ta phải phát triển cái này?” hay “Đây có thực sự là vấn đề không?”
.
🎯 Trong thị trường lập trình viên hiện nay, những "lập trình viên biết tư duy" như thế này là những người phát triển nhanh nhất.
Giờ đây, hãy trở thành một nhà phát triển giỏi từ khâu thiết lập vấn đề thay vì chỉ giải quyết vấn đề.
Phải nhìn nhận vấn đề một cách chính xác thì việc giải quyết và trưởng thành mới có thể bắt đầu.
Khóa học này dành cho ai?
Một nhà phát triển muốn rèn luyện năng lực tự suy nghĩ và phán đoán vấn đề thực sự là gì, thay vì chỉ thực hiện nguyên văn các yêu cầu được đưa ra.
Các nhà hoạch định, nhà thiết kế, PM/PO muốn xác định hướng đi cho nhóm giữa những yêu cầu và ý kiến mơ hồ, đồng thời muốn giao tiếp mượt mà với các nhà phát triển.
696
Học viên
38
Đánh giá
2
Trả lời
4.6
Xếp hạng
18
Các khóa học
Tôi là một người coi IT vừa là sở thích vừa là nghề nghiệp.
Tôi có nhiều kinh nghiệm trong việc viết lách, dịch thuật, tư vấn, phát triển và giảng dạy.
Tất cả
73 bài giảng ∙ (17giờ 49phút)
Tài liệu khóa học:
Tất cả
3 đánh giá
5.0
3 đánh giá
Đánh giá 330
∙
Đánh giá trung bình 5.0
5
Chất lượng âm thanh không được tốt lắm nhưng không ảnh hưởng đến việc học và nội dung cũng hay
Cảm ơn bạn. Trong tương lai, tôi sẽ ghi âm lại các bài giảng hiện có để cải thiện chất lượng âm thanh.
Đánh giá 2
∙
Đánh giá trung bình 4.5
Đánh giá 111
∙
Đánh giá trung bình 4.9
Hãy khám phá các khóa học khác của giảng viên!
Khám phá các khóa học khác trong cùng lĩnh vực!