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.
入門
AI
Problematization (Vấn đề hóa) là một thuật ngữ cũng được dịch là đặt vấn đề, xây dựng vấn đề. Và nó cũng có thể được dịch là thiết lập vấn đề hoặc định nghĩa vấn đề. Đây là khái niệm bao gồm quá trình đặt câu hỏi từ góc độ mới về các sự kiện đã biết như yêu cầu hoặc tri thức thông thường, định nghĩa vấn đề và xây dựng cách thức giải quyết vấn đề đó. Vấn đề hóa phải là điểm xuất phát của mọi phát triển, nhưng đây vẫn là chủ đề chưa được thảo luận đầy đủ trong lĩnh vực phát triển. Việc thực hiện dự án hay phát triển chương trình thực chất cũng là việc lập kế hoạch giải quyết vấn đề. Nói cách khác, nó có liên quan đến vấn đề hóa. Để giải quyết vấn đề, trước tiên vấn đề phải được định nghĩa rõ ràng. Tuy nhiên, hầu hết các vấn đề được đưa ra dưới dạng yêu cầu mơ hồ. Do đó, cần có khả năng chuyển đổi yêu cầu mơ hồ thành vấn đề rõ ràng để giảm thiểu 'lãng phí phát triển' không cần thiết, làm cho cộng tác diễn ra suôn sẻ và nắm bắt đúng nhu cầu thực sự của người dùng. Khóa học này giúp rèn luyện 'tư duy cấu trúc' vấn đề thông qua các trường hợp thực tế và công cụ.
34 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 giấu trong yêu cầu, đòi hỏi, phản hồi của người dùng và code review
Phương pháp biểu diễn vấn đề thực tế thành vấn đề có cấu trúc bằng cách sử dụng công thức phát biểu vấn đề, v.v.
Phương pháp tìm nguyên nhân gốc rễ của vấn đề
Khái niệm triết học 'vấn đề hóa' - thấu hiểu bản chất từ hiện tượng
Nhiều công cụ khác nhau để thực hiện 'vấn đề hóa'
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. Việc cải thiện toàn bộ khóa học có thể mất một chút thời gian. Trước tên các bài học đã hoàn thành cải thiện, chúng tôi sẽ đánh dấu '[Đã hoàn thành cải thiện chất lượng âm thanh]'.
Điểm khởi đầu về hợp tác, phân tích yêu cầu và code review dành cho lập trình viên mới vào nghề và junior!
Năng lực cơ bản được khuyến nghị cho tất cả thành viên trong nhóm để ngăn chặn 'lãng phí phát triển' từ góc độ PM/PO!
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 đề!
"Bản kế hoạch quá mơ hồ nên tôi không biết phải làm cái gì."
"Tôi đã nhận được phản hồi trong buổi review, nhưng không nắm được chính xác phải sửa chỗ nào."
"Khi chuẩn bị viết code thì... mình định giải quyết vấn đề gì nhỉ?"
"Khi tôi hỏi thì họ lại hỏi ngược lại 'Vậy vấn đề là gì?'"
Cốt lõi của tất cả sự hỗn loạn này là do không định nghĩa chính xác vấn đề. Lập trình viên liên tục đối mặt với các vấn đề. Nhưng phải có khả năng nhìn nhận chính xác và định nghĩa được vấn đề đó thì giải pháp đú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 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ẽ bối rối không biết cụ thể cần triển khai chức năng nào. Theo một blog dành cho lập trình viên, người mới vào nghề gặp khó khăn do "hướng dẫn 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 khó có thể phân tách vấn đề một cách có hệ thống hoặc tự tìm ra thông tin cần thiết. Trong một trường hợp thực tế, một lập trình viên mới vào nghề đã gặp khó khăn trong việc đánh giá mức độ cần tự giải quyết và chỉ học được cách đặt câu hỏi sau khi đã cố gắng giải quyết trong thời gian quá lâu (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ẻ mạo danh), cản trở việc học tập và hợp tác.
Khoảng cách giao tiếp: Khi thiếu kiến thức về lĩnh vực hoặc bối cảnh kinh doanh, không thể nắm bắt chính xác vấn đề cốt lõi của yêu cầu. Trong cộng đồng phát triển cũng có chỉ적 rằng việc thiếu kiến thức về lĩnh vực dẫn đến hiểu sai yêu cầu (kedin.com), và điều này dẫn đến triển khai sai và phải làm lại.
Phương pháp tư duy thực tế để làm rõ các yêu cầu mơ hồ 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ừ yêu cầu
5 tiêu chí biến một 'vấn đề' thành vấn đề thực sự
Kỹ thuật hình thành sự đồng cảm với các thành viên trong nhóm có quan điểm khác nhau
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 code review, họp kế hoạch, và truyền đạt công việc
15 mẫu chính
Khi khách hàng hoặc người lập kế hoạch đưa ra yêu cầu quá mơ hồ khiến bạn không biết phải làm gì
Ví dụ: "UX hơi tệ", "Chậm quá", "Làm trực quan hơn đi"
→ Trạng thái thiếu khả năng chuyển yêu cầu thành vấn đề
Yêu cầu: "Làm UX tốt hơn đi"
Phản ứng: "Họ chỉ nói là làm UX tốt hơn thôi.....ý là gì nhỉ?"
"Bạn đã từng bối rối trước câu 'Làm trực quan hơn đi' chưa? Kỹ thuật biến yêu cầu mơ hồ thành vấn đề rõ ràng, hãy bắt đầu ngay từ bây giờ."
Khả 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 hoạch định
→ Cần có kỹ năng tự định nghĩa vấn đề
Yêu cầu: Chức năng 'OO' - Đang ở trạng thái chưa xác định. Sẽ sớm được quyết định.
Phản ứng: "Liệu có ổn không khi phát triển trong tình trạng hiện tại mà một số chức năng chưa được xác định?"
"Bạn có đang chỉ làm theo những gì được yêu cầu không? Hãy trở thành một lập trình viên biết cách diễn giải kế hoạch và tự định nghĩa vấn đề."
Triển khai tính năng tốt nhưng không giải thích được tại sao cần tính năng đó
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 đề
→ Người muốn phát triển từ lập trình viên → người giải quyết vấn đề → người thiết lập vấn đề
Yêu cầu: Tăng kích thước nút + 10 pixel
Phản ứng: "Ừm... tôi chỉ nghĩ là làm theo cách đó thì có vẻ hay..."
"Nếu bạn có thể triển khai tính năng nhưng không thể giải thích lý do? Đây là lúc bạn cần tư duy xuyên suốt bản chất vấn đề."
Có nhiều cuộc trao đổi nhưng không hình thành được sự đồng thuận về "vấn đề thực sự là gì"
Phản hồi lặp đi lặp lại hoặc xung đột giao tiếp thường xuyên xảy ra
→ Người muốn cấu trúc hóa những ngôn ngữ khác nhau để tạo trọng tâm cho sự cộng tác
Yêu cầu: "Làm ơn làm cho nó có cảm giác trực quan hơn"
Phản ứng: "Tại sao designer cứ toàn nói về những thứ kiểu 'cảm giác' thế nhỉ....?"
"Bạn cảm thấy không hiểu được người làm kế hoạch? Nếu chuyển ngôn ngữ của nhau thành 'vấn đề', sự hợp tác sẽ thay đổi."
Lập trình viên đang phát triển vai trò cần định nghĩa vấn đề và đưa ra phương hướng
Cần có khả năng cấu trúc hóa các yêu cầu mơ hồ thành công việc cụ thể của nhóm
→ Thiết lập vấn đề chính là khởi đầu của khả năng lãnh đạo
Yêu cầu: [Yêu cầu thông tin (Request) > Nguyên nhân (Cause) > Tình huống người dùng (User Situation)] theo cấu trúc ...
Phản ứng: "Để biến điều này thành nhiệm vụ của nhóm thì cần phải định nghĩa như thế nào?"
"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 đầu tiên để bạn trở thành một developer dẫn dắt team."
Khóa học này là khóa học cần thiết cho tất cả các lập trình viên đang băn khoăn "Tôi có thể viết code, nhưng không biết nên viết cái gì".
Đặc biệt, đây có thể được coi là năng lực cần thiết cho các lập trình viên junior từ mới vào nghề đến 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 viết của người mới vào nghề và sinh viên hỏi "Làm thế nào để thu thập và phân tích yêu cầu?". Ví dụ, một sinh viên ngành khoa học máy tính đã 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?" và tìm kiếm lời khuyên từ các lập trình viên đàn anh (reddit.com). Điều này cho thấy nhu cầu về cách thu thập 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 của các lập trình viên kỳ cựu, 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 sự cần có khả năng xác định chính xác các yêu cầu (medium.com). Trong cộng đồng lập trình viên, ý kiến nhấn mạnh tầm quan trọng của việc định nghĩa vấn đề như vậy cũng thường xuyên được tìm thấy.
Nhu cầu đào tạo: Trong các blog của lập trình viên Hàn Quốc, khả năng định nghĩa vấn đề được coi là "kỹ năng cơ bản"(medium.com), và 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 thiết yếu hơn cả công cụ(inflearn.com, velog.io). Những bài viết này làm nổi bật nhu cầu về 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 cấu trúc xoay quanh các tình huống vấn đề thực tế gặp phải trong quá trình cộng tác
Bài giảng ngắn gọn và rõ ràng:
Mỗi bài học thường được cấu trúc trong vòng 10 phút (có ngoại lệ), cho phép học tập với mức độ tập trung cao
Rèn luyện cấu trúc tư duy:
Bài giảng tập trung vào slide trực quan hóa 'dòng tư duy' để định nghĩa vấn đề
Ví dụ thực tế:
Bao gồm phương pháp đối thoại để chuyển đổi phản hồi mơ hồ, kế hoạch trừu tượng thành vấn đề rõ ràng
Thiết lập vấn đề là gì – Điểm khởi đầu của giải quyết vấn đề
Yêu cầu mơ hồ, sai từ đâu?
5 tiêu chí biến vấn đề thành vấn đề thực sự
"Vậy vấn đề là gì?" - Kỹ thuật đặt câu hỏi theo cách khác
Code review, lập kế hoạch, điều phối tiến độ… Tất cả những thời điểm cần thiết lập vấn đề
Có thể tự cấu trúc hóa và sắp xếp ngay cả những yêu cầu khó hiểu
Bạn có thể trở thành lập trình viên nắm bắt được cốt lõi chỉ với một câu hỏi
Khi làm việc nhóm, có thể giảm thiểu hiểu lầm không cần thiết và chủ động giao tiếp chính xác
Phản hồi đánh giá cũng có thể được chuyển đổi thành vấn đề có thể giải quyết chứ không chỉ là chỉ trích đơn thuần
Công việc của lập trình viên luôn bắt đầu từ việc nhận 'yêu cầu'. Nhưng hầu hết các yêu cầu đều mơ hồ và không rõ ràng. Nếu không chuyển đổi được chúng thành vấn đề cụ thể, kế hoạch sẽ sai lệch, phát triển sẽ đi chệch hướng và tiến độ sẽ bị trễ.
Ví dụ: "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 lập trình viên mới vào nghề hoặc junior không phải là việc triển khai đơn thuần mà là khả năng phán đoán 'cần phải triển khai cái gì'. Khóa học này chỉ ra chính xác điểm đó.
Phân tích yêu cầu, code review, giao tiếp, thảo luận với PM... tất cả đều cần định nghĩa vấn đề tốt thì mọi thứ mới diễn ra suôn sẻ. Khóa học này rèn luyện tư duy lắng nghe và rút ra bản chất.
Không chỉ là lý thuyết không có thực hành, mà còn cung cấp công thức phát biểu vấn đề, tiêu chí phản hồi, kỹ thuật đặt câu hỏi có thể áp dụng ngay trong công việc thực tế.
Tóm lại, khóa học này giúp bạn trở thành "Tại sao phải phát triển cái này?", "Đây có thực sự là vấn đề không?" - không dừng lại trước những câu hỏi như vậy mà
có thể đưa ra phán đoán rõ ràng và diễn đạt được như một lập trình viên.
🎯 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à người phát triển nhanh nhất.
Giờ đây, hãy trở thành lập trình viên giỏi thiết lập vấn đề chứ không chỉ giải quyết vấn đề.
Chỉ khi nhìn thấy vấn đề một cách chính xác, bạn mới có thể bắt đầu giải quyết và phát triển.
Khóa học này dành cho ai?
Một lập trình viên muốn phát triể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 yêu cầu được giao một cách máy móc
Người hoạch định, thiết kế, PM/PO muốn định hướng cho đội nhóm giữa những yêu cầu và ý kiến mơ hồ, đồng thời giao tiếp trôi chảy với các lập trình viên
613
Học viên
31
Đánh giá
2
Trả lời
4.5
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ả
72 bài giảng ∙ (17giờ 32phút)
Tài liệu khóa học:
Tất cả
3 đánh giá
5.0
3 đánh giá
Đánh giá 111
∙
Đánh giá trung bình 4.9
Đánh giá 327
∙
Đá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
1.146.211 ₫
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!