Problem Solver 1 và Problem Solver 2 là hai khoá học dành cho trẻ 7–9 tuổi tại IQode Lab — giai đoạn não bộ đã đủ sẵn sàng để học cách tiếp cận vấn đề có cấu trúc, tự tìm lỗi, và bắt đầu tư duy như một kỹ sư.

Có một khoảnh khắc mà nhiều phụ huynh kể lại sau khi con học Problem Solver: lần đầu tiên, khi máy tính ở nhà bị lỗi, con không gọi ba mẹ ngay. Con ngồi nhìn màn hình một lúc, rồi nói: "Để con thử xem lỗi ở chỗ nào trước."
Đó không phải là kỹ năng kỹ thuật. Đó là tư duy.
Problem Solver là hai khoá học dành cho trẻ 7–9 tuổi tại IQode Lab — giai đoạn não bộ đã đủ sẵn sàng để học cách tiếp cận vấn đề có cấu trúc, tự tìm lỗi, và bắt đầu tư duy như một kỹ sư.
Jean Piaget mô tả trẻ 7–11 tuổi đang trong giai đoạn "thao tác cụ thể" — một trong những bước nhảy quan trọng nhất trong phát triển nhận thức. Ở giai đoạn này, não bộ bắt đầu có khả năng:
Tư duy logic có hệ thống: Trẻ có thể theo dõi một chuỗi bước suy luận và nhìn thấy hệ quả ở cuối chuỗi đó.
Tư duy đảo ngược: Trẻ hiểu rằng một vấn đề có thể được tiếp cận từ nhiều hướng, và có thể "tháo gỡ" một giải pháp để hiểu tại sao nó hoạt động hoặc không hoạt động.
Tư duy điều kiện: Trẻ bắt đầu xử lý được cấu trúc "nếu điều này xảy ra thì làm thế này, ngược lại thì làm thế kia" — nền tảng của mọi quyết định có logic.
Metacognition sơ khai: Trẻ bắt đầu có thể tự nhìn lại quá trình suy nghĩ của mình, không chỉ nhìn vào kết quả.
Nghiên cứu với 72 học sinh tiểu học 6–9 tuổi chơi một trò chơi lập trình khối lệnh trong 6 tuần cho thấy hoạt động lập trình có thể đo lường được cả tư duy máy tính lẫn kỹ năng giải quyết vấn đề một cách đáng tin cậy. Đây không phải kỹ năng trừu tượng — đây là năng lực có thể quan sát và đo được.
Nói cách khác: trẻ 7–9 tuổi không chỉ có thể học các khái niệm này — não bộ của các em đang chờ được thách thức ở đúng mức độ này.
7–8 tuổi · 20 buổi · 10 tuần · 60 phút/buổi
Problem Solver 1 là khoá học đưa vào ba khái niệm tư duy lập trình cốt lõi nhất — không phải để trẻ trở thành lập trình viên, mà vì ba khái niệm này chính xác là cách não bộ cần học để giải quyết vấn đề có cấu trúc.
Đây là khái niệm trọng tâm nhất của khoá học. Trẻ học cách chương trình đưa ra quyết định: "Nếu nhân vật chạm tường thì quay lại, ngược lại tiếp tục đi thẳng."
Tại sao điều này quan trọng vượt ra ngoài lập trình? Vì tư duy điều kiện là nền tảng của mọi quyết định logic trong cuộc sống — từ việc lên kế hoạch, giải quyết xung đột, đến đánh giá thông tin. Trẻ học không phải bằng cách được giải thích lý thuyết, mà bằng cách tự xây dựng chương trình có những điều kiện đó và thấy chúng hoạt động — hoặc không hoạt động — trong thực tế.
Trẻ đã gặp vòng lặp ở Mindbuilder Kids 1–2. Ở Problem Solver 1, vòng lặp được đưa vào ngữ cảnh phức tạp hơn: kết hợp với điều kiện — "Lặp lại cho đến khi điều này xảy ra." Đây là bước chuyển từ "lặp đơn giản" sang "lặp có điều kiện" — nền tảng của tư duy thuật toán thực sự.
Đây là phần quan trọng nhất và cũng là phần khác biệt nhất so với lớp coding thông thường.
Ở Problem Solver 1, debugging không phải là chuyện xảy ra ngẫu nhiên khi code sai — đây là một kỹ năng được dạy có hệ thống. Trẻ học quy trình: khi chương trình không chạy đúng, không đoán mò và sửa lung tung — mà phân tích có trình tự: "Bước nào đầu tiên có thể gây ra vấn đề này? Nếu sửa bước đó, kết quả thay đổi như thế nào?"
Nghiên cứu về tư duy thuật toán và debugging ở học sinh tiểu học (Springer Nature, 2024) xác nhận rằng debugging là một trong những kỹ năng con người cần thiết nhất cho sự phát triển nhận thức — cùng với abstraction, phân tích vấn đề và generalization. Đây là các kỹ năng cốt lõi của tư duy tính toán, không phải chỉ của lập trình.
Cuối khoá, trẻ tạo ra mini game đơn giản hoạt động được — với nhân vật di chuyển, điều kiện thắng/thua, và vòng lặp xử lý các tình huống khác nhau. Đây không phải mục tiêu của khoá học — đây là bằng chứng rằng trẻ đã hiểu đủ để tạo ra thứ gì đó có logic thật sự.
8–9 tuổi · 24 buổi · 12 tuần · 60 phút/buổi
Nếu Problem Solver 1 xây dựng nền tảng — thì Problem Solver 2 là khoá học đưa trẻ vào tư duy kỹ sư thực sự: không chỉ làm cho chương trình chạy được, mà làm cho nó chạy tốt.
Đây là khái niệm trừu tượng nhất trong cả lộ trình Scratch — và cũng là một trong những khái niệm tư duy quan trọng nhất.
Biến số là thứ có thể thay đổi giá trị trong quá trình chương trình chạy: điểm số tăng lên khi nhân vật bắt được item, thanh máu giảm khi bị tấn công, bộ đếm thời gian đếm ngược theo giây. Trẻ không chỉ học "biến số là gì" — trẻ học cách nghĩ về dữ liệu thay đổi, và đây là nền tảng của tư duy toán học, tư duy khoa học và tư duy phân tích trong mọi lĩnh vực.
Đây là kỹ năng mà ngay cả nhiều người lớn không có: khi gặp một vấn đề lớn và phức tạp, không cố giải quyết toàn bộ cùng một lúc — mà chia thành các phần nhỏ hơn, giải từng phần, rồi ghép lại.
Tại Problem Solver 2, trẻ học cách thiết kế chương trình theo từng module — mỗi module xử lý một chức năng cụ thể. Khi một phần bị lỗi, chỉ cần debug phần đó mà không ảnh hưởng đến phần còn lại. Đây là cách tư duy mà kỹ sư phần mềm, bác sĩ, luật sư — bất kỳ người giải quyết vấn đề phức tạp nào — đều sử dụng mỗi ngày.
Problem Solver 2 đưa debugging lên một cấp độ mới: không chỉ tìm lỗi trong một đoạn code ngắn, mà debug trong một chương trình phức tạp có nhiều module. Trẻ học cách cô lập vấn đề — xác định lỗi nằm trong module nào trước khi xem xét từng dòng lệnh.
Đây là câu hỏi cuối cùng và quan trọng nhất của mỗi buổi Reflect ở Problem Solver 2. Chương trình chạy được rồi — nhưng có cách nào viết ít lệnh hơn mà vẫn ra kết quả tương tự không? Có cách nào làm chương trình chạy mượt hơn không?
Tư duy tối ưu hoá không phải là cầu toàn — đây là thói quen luôn hỏi "còn cách nào tốt hơn không?" sau khi đã có một giải pháp hoạt động. Đây là thứ phân biệt người giải quyết vấn đề bình thường với người giải quyết vấn đề xuất sắc.
Ở cả Problem Solver 1 và 2, có một quy tắc bất biến mà phụ huynh nào cũng ngạc nhiên khi nghe lần đầu:
Máy tính chỉ được mở sau khi học viên đã vẽ sơ đồ trên giấy.
Mỗi buổi học, sau khi phân tích bài toán, học viên lấy ra tờ giấy trắng và vẽ sơ đồ luồng (flowchart) của giải pháp mình dự định thực hiện — mũi tên, hình chữ nhật, hình thoi cho các điều kiện. Giáo viên không vẽ mẫu. Giáo viên chỉ hỏi từng câu nhỏ để giúp học viên tự tìm ra.
Tại sao?
Bởi vì khi học viên mở máy tính trước khi hiểu rõ bài toán, thói quen tự nhiên là thử từng cách cho đến khi một cách tình cờ hoạt động — học mà không hiểu. Khi học viên vẽ sơ đồ trước, não buộc phải xử lý logic của bài toán hoàn toàn bằng tư duy, không dựa vào phản hồi tức thì của máy tính như nạng chống.
Đây là điểm khác biệt lớn nhất giữa Problem Solver và hầu hết các lớp coding — không phải ở công cụ hay nội dung, mà ở thứ tự: tư duy trước, máy tính sau.
Một câu hỏi phụ huynh thường đặt ra: "Học Scratch thì học được gì ngoài việc biết Scratch?"
Câu trả lời từ nghiên cứu khá rõ ràng.
Học sinh học cách sử dụng sequences, events, operators, conditionals và loops thông qua debug'ems — các chương trình Scratch có lỗi cố tình — kết nối giải quyết vấn đề với kiến thức vượt ra ngoài chương trình công nghệ.
Meta-analysis 2021 về coding xác nhận transfer effect — kỹ năng tư duy học qua coding có thể áp dụng sang toán học và giải quyết vấn đề trong các lĩnh vực khác. Đây không phải giả thuyết — đây là kết quả đo được từ dữ liệu nghiên cứu.
Frontiers in Psychology (2019) xác nhận coding cải thiện planning và inhibitory control (khả năng dừng lại và suy nghĩ thay vì phản ứng bốc đồng) nhanh hơn phát triển tự nhiên — hai Executive Functions quan trọng nhất cho học tập ở trường và trong cuộc sống.
Học sinh lớn hơn ít mắc lỗi hơn và giỏi mô hình hoá vấn đề theo cách trực quan và trừu tượng hơn so với học sinh nhỏ tuổi hơn — điều này cho thấy nhóm 7–9 tuổi đang ở giai đoạn phát triển phù hợp nhất để tiếp thu các khái niệm này.
Khởi động (5 phút): Giáo viên đặt tình huống: "Mình đang làm game mà nhân vật cứ đi xuyên qua tường. Điều gì đang xảy ra? Con nghĩ nguyên nhân là gì?" — học viên tự phán đoán trước khi nhìn vào code.
Phân tích (8 phút): Học viên tự viết ra: đầu vào là gì, đầu ra mong muốn là gì, điều kiện nào cần được kiểm tra. Máy tính vẫn đóng.
Vẽ sơ đồ (10 phút): Học viên vẽ flowchart trên giấy — hộp quyết định hình thoi cho điều kiện, mũi tên cho luồng chương trình. Giáo viên không vẽ mẫu, chỉ hỏi: "Nếu điều này xảy ra thì con muốn chương trình làm gì? Còn nếu không xảy ra thì sao?"
Lập trình (25 phút): Học viên mở Scratch và code theo sơ đồ của mình. Khi chương trình không chạy như dự kiến, giáo viên hỏi: "Sơ đồ của con nói bước này làm gì? Code con đang viết có đúng với sơ đồ không?" — không sửa hộ.
Tự nhìn lại (7 phút): "Con đã giải quyết vấn đề bằng cách nào? Điều kiện nào con đã kiểm tra? Có cách nào viết ít lệnh hơn mà vẫn ra kết quả đúng không?"
Chú ý: Phần quan trọng nhất không phải là 25 phút lập trình. Phần quan trọng nhất là 10 phút vẽ sơ đồ — khi học viên buộc phải tư duy hoàn toàn bằng não bộ, không có sự hỗ trợ của máy tính.
Sau Problem Solver 1: Con bắt đầu tiếp cận vấn đề theo kiểu "Điều kiện nào đang xảy ra? Bước nào có thể gây ra điều này?" thay vì thử đại các cách cho đến khi một cách tình cờ hoạt động. Khi gặp bài toán khó ở trường, con ngồi phân tích thay vì bỏ cuộc ngay hoặc chép đáp án.
Sau Problem Solver 2: Con bắt đầu tự chia bài toán lớn thành từng phần nhỏ — "Bài này có mấy phần? Phần nào mình giải được ngay? Phần nào cần nghĩ thêm?" Và quan trọng hơn: con không bằng lòng với "làm xong rồi" — con hỏi "có cách nào tốt hơn không?"
"Con 8 tuổi chưa học Scratch — có vào Problem Solver 1 được không?" Được. Problem Solver 1 bắt đầu từ nền tảng Scratch cơ bản trong những buổi đầu. Tuy nhiên nếu con đã qua Mindbuilder Kids 2, quá trình học sẽ mượt hơn vì con đã có thói quen tư duy trước khi làm.
"Giấy trắng trước máy tính — con có thấy khó chịu không?" Ban đầu nhiều trẻ sẽ thấy bất tiện — quen rồi thì muốn mở máy ngay. Nhưng sau 3–4 buổi, hầu hết trẻ tự nhận ra rằng khi có sơ đồ trước, code ít bị lỗi hơn nhiều. Việc tự phát hiện ra điều này — thay vì được nói — làm cho thói quen trở nên bền vững hơn.
"Problem Solver 2 có quá khó với trẻ 8–9 tuổi không?" Các khái niệm như biến số và modular design được giới thiệu qua bài toán cụ thể và quen thuộc — không phải lý thuyết trừu tượng. Trẻ không học "biến số là gì" mà học "tại sao điểm số của nhân vật cần phải thay đổi được, và làm thế nào để máy tính biết điểm hiện tại là bao nhiêu". Khi bài toán gần gũi, khái niệm trở nên tự nhiên hơn nhiều.
"Sau Problem Solver 2, con học gì tiếp?" Hai hướng: Robotics 1 (8–10 tuổi) nếu con muốn áp dụng tư duy này vào môi trường vật lý với robot mBot2 — hoặc tiếp tục Thinking Lab để hiểu sâu hơn về AI và công nghệ trong thế giới thực. Nhiều gia đình chọn học song song cả hai.
"Con học Problem Solver có bị 'nghiện' lập trình không?" Thực ra điều ngược lại thường xảy ra hơn: trẻ sau khoá này thường ít bị cuốn vào tiêu thụ nội dung thụ động (xem YouTube, chơi game) hơn — vì giờ chúng biết cách tạo ra thứ gì đó, và niềm vui từ sáng tạo chủ động lớn hơn nhiều so với tiêu thụ thụ động.
Problem Solver không phải lớp học lập trình. Đây là chương trình dạy trẻ 7–9 tuổi cách tiếp cận vấn đề có cấu trúc — phân tích trước khi làm, lập kế hoạch trước khi code, tìm lỗi có hệ thống thay vì đoán mò, và luôn hỏi "có cách nào tốt hơn không?" sau khi đã có giải pháp.
Những kỹ năng này — dù được học qua Scratch — sẽ theo trẻ vào toán học, khoa học, viết luận, và mọi tình huống đòi hỏi tư duy có hệ thống trong cuộc sống. Đó là lý do tại sao nhiều nghiên cứu ghi nhận transfer effect: kỹ năng tư duy học qua lập trình không ở lại trong lập trình — chúng di chuyển sang mọi nơi.
Và đó là điều IQode Lab thực sự muốn xây dựng.
Tìm hiểu thêm về chương trình Problem Solver hoặc đặt lịch tư vấn: iqode.vn
"Máy tính vẫn đóng. Scratch chưa được mở. Con phải giải thích lại bài toán bằng lời của chính mình trước. Nếu con giải thích được — con hiểu. Nếu con không giải thích được — con chưa sẵn sàng để giải." — IQode Method