สัปดาห์ที่ 01 · Foundation · Pre-code

หาปัญหาให้เจอ + เขียน Flowchart

ก่อน AI — นักศึกษาวิศวะเรียน "แก้โจทย์ที่อาจารย์ให้" · หลัง AI — นักศึกษาต้องเรียน "หาโจทย์เองให้เป็น" · สัปดาห์นี้ไม่มีการเขียนโค้ดเลย แต่เป็นทักษะที่ขาดไม่ได้สำหรับยุคที่ AI เขียนโค้ดให้

เป้าหมายสัปดาห์นี้

🔒 สัปดาห์นี้คือสิ่งที่ AI ทำให้คุณไม่ได้ AI ไม่ได้นั่งอยู่ในห้อง lab ของคุณ · ไม่รู้ว่าพี่ TA เครียดเรื่องอะไร · ไม่รู้ว่าอาจารย์เสียเวลากับงานไหน · ไม่เคยคุยกับเพื่อน 30 นาทีในโรงอาหาร · สิ่งที่ AI ไม่มีคือ "อยู่ตรงนั้น" ทักษะของสัปดาห์นี้ทำให้คุณ "มีค่ามากกว่า AI" เพราะคุณเอาข้อมูลที่ AI ไม่มี มาแปลงเป็นงานให้ AI ทำต่อ

ทำไมต้องเริ่มที่ "หาปัญหา"

AI ในปี 2026 เขียน Python ได้ดีกว่านักศึกษาปี 1 อยู่แล้ว · งานของคุณจึง ไม่ใช่ "เก่ง syntax" — แต่คือ "ตัดสินใจว่าจะให้ AI สร้างอะไร"

🎯 Running Case — พี่นัท TA วิชา Engineering Drawing

เราจะใช้ 1 case ตัวอย่าง ลากผ่านทั้งสัปดาห์ — เพื่อให้เห็นว่า observe → 5 Whys → interview → flowchart → Problem Statement เชื่อมกันยังไง

สถานการณ์ "พี่นัท" เป็น TA วิชา Engineering Drawing ของคณะวิศวกรรมศาสตร์ · ทุกศุกร์ ต้องตรวจ drawing assignment 50 ชิ้นจากนักศึกษาชั้นปี 1 · ใช้เวลา 8 ชั่วโมงต่อสัปดาห์ ส่ง feedback กลับช้าทุกครั้ง · ภาควิชาเริ่มได้รับ complaint จากนักศึกษา

เราจะตามพี่นัทไป — สังเกต, สัมภาษณ์, วาด flowchart, แล้วเขียน Problem Statement

Symptom vs Root Problem

นี่คือ skill แรกที่ต้องฝึก — ปัญหาที่เห็นบ่อยที่สุดมัก ไม่ใช่ ปัญหาจริง แต่เป็นแค่อาการ

Symptom (สิ่งที่เห็น)Root Problem (สิ่งที่จริง ๆ ผิด)
นักศึกษาส่ง lab ช้าใบงานเขียนไม่ชัด หรือไม่มีตัวอย่าง output
อาจารย์ตรวจงานนานนักศึกษาส่งหลายช่องทาง (LINE/email/print) ไม่รวมศูนย์
เครื่อง lab พังไม่มีระบบจองล่วงหน้า · ใช้ทับกัน · ไม่มี maintenance log
นักศึกษาสอบตกไม่รู้ว่าตัวเองเข้าใจอะไรไม่ครบ · ไม่มี feedback ระหว่างทาง
พี่นัทตรวจ drawing 8 ชม./ศุกร์ (เรายังไม่รู้ — ต้องทำ 5 Whys + interview)

🤔 5 Whys — กับ Case ของพี่นัท

เทคนิค 5 Whys ของ Toyota — ถาม "ทำไม" 5 ครั้งจนเจอ root ที่ เปลี่ยนได้

Symptom: พี่นัทตรวจ drawing 50 ชิ้นใช้เวลา 8 ชม. ทุกศุกร์ feedback ช้า

ทำไม 1? → เพราะต้องเปิดดูแต่ละ pdf ทีละไฟล์ แล้วเทียบ rubric ด้วยตา
ทำไม 2? → เพราะนักศึกษาส่งใน Classroom เป็น pdf รายคน · ไม่มี checklist ในตัว
ทำไม 3? → เพราะ rubric อยู่ใน Word แยก · พี่นัทต้องจำหรือเปิดดูทุกครั้ง
ทำไม 4? → เพราะไม่เคยมีเครื่องมือที่รวม rubric + checklist + feedback ในที่เดียว
ทำไม 5? → ✅ Root: ขาด tool ที่ tick checklist แล้วสร้าง feedback ลง Classroom comment อัตโนมัติ
เคล็ดลับ — Root ที่ "ใช่" Root ที่ดีจะรู้สึก "นี่แหละ ถ้าแก้ตรงนี้ symptom หายแน่นอน" · ถ้ายังคลุมเครือ หรือดูแก้ไม่ได้ — แสดงว่ายังไม่ลึกพอ หรือลึกเกินจนเปลี่ยนไม่ได้

✅ Rubric — ทำ 5 Whys ถูกต้องมั้ย?

ดู Root ของคุณ — ตอบ ✓ ทุกข้อมั้ย?

เกณฑ์ตัวอย่าง ✅ตัวอย่าง ❌
เปลี่ยนได้จริง (มีคนสร้าง/แก้ได้) "ขาด tool tick checklist" "มนุษย์ขี้เกียจโดยธรรมชาติ"
อยู่ระดับ process / system ไม่ใช่บุคคล "workflow ส่งกระจาย 3 ช่องทาง" "นักศึกษาคนนี้ไม่รับผิดชอบ"
ถ้าแก้ symptom หายแน่นอน มี checklist → ตรวจเร็วขึ้น → feedback ทัน "นักศึกษาไม่อ่าน announcement" (แก้แล้วยังตรวจช้าอยู่)
ไม่ตื้นเกิน (ไม่ใช่แค่ Why 1-2) ถาม "ทำไม" ลึก 4-5 ชั้น หยุดที่ "ไม่มีเวลา"
ไม่ลึกเกินจนเปลี่ยนไม่ได้ "ขาด tool รวม rubric+feedback" "ระบบการศึกษาไทยไม่ดี"
เป็น "สิ่งที่ขาด" ไม่ใช่ "คนที่ผิด" "ขาดระบบ X" "อาจารย์ Y ไม่ใส่ใจ"

🎤 คุยกับ user ของคุณยังไง

สมมติฐาน เรื่องพี่นัทอาจถูก ก็อาจผิด · วิธีเดียวที่จะรู้คือ "ไปคุยกับพี่นัทจริง" แต่ถ้าคุยไม่เป็น คำตอบที่ได้จะ "ตามใจที่ฉันอยากได้ยิน" — ไม่ใช่ความจริง

กฎ 8 ข้อสำหรับการสัมภาษณ์

กฎคำพูดที่ดี ✅คำพูดที่ไม่ดี ❌
1. ขอเวลาก่อน "พี่นัทมีเวลา 20 นาทีคุยกันได้มั้ย?" เดินเข้าไปถามทันที
2. เริ่มจากเล่า ไม่ใช่ถาม "เล่าวันศุกร์ทั่วไปของพี่ให้ฟังหน่อย" "พี่มีปัญหากับงานตรวจมั้ย?"
3. ถามเหตุการณ์ล่าสุด ไม่ใช่ค่าเฉลี่ย "ศุกร์ที่แล้วใช้เวลาเท่าไหร่?" "โดยปกติพี่ใช้เวลานานมั้ย?"
4. Show me, don't tell me "ขอดูตอนพี่ตรวจชิ้นนึงได้มั้ย?" "พี่ตรวจยังไง?"
5. ถามตัวเลข "ตรวจกี่ชิ้น? ใช้เวลาเท่าไหร่? ทำสัปดาห์ละกี่ครั้ง?" ปล่อยให้คำตอบกำกวม
6. ไม่ชี้นำ (no leading) "พี่รู้สึกยังไงกับงานนี้?" "คงเหนื่อยมากเลยใช่มั้ย?"
7. ขอ artifacts "ขอดู rubric ที่ใช้ได้มั้ย? ขอดูตัวอย่าง feedback ที่เคยส่ง?" เชื่อคำพูดอย่างเดียว
8. จดคำต่อคำ ไม่ตีความ "…แล้วพี่ก็เปิด Word ก็อปคำเดิม…" (จดตามที่พูด) "พี่ใช้ template ในการให้ feedback" (ตีความเอง)

คำถามมาตรฐาน 5 ข้อ ที่ใช้กับทุก user

  1. "เล่าวันทั่วไปให้ฟัง" — เปิดประตูแบบไม่กดดัน
  2. "ครั้งล่าสุดที่ทำงานนี้คือเมื่อไหร่? ใช้เวลาเท่าไหร่?" — ดึงตัวเลขจริง
  3. "ขั้นไหนที่รู้สึกเสียเวลาที่สุด?" — ระบุ pain point
  4. "ขอดูตอนทำจริงได้มั้ย?" — observe
  5. "ถ้ามีเครื่องช่วย — อยากให้มันทำอะไรให้?" — รับ wishlist (แต่อย่าเชื่อทันที — user มักไม่รู้ว่าตัวเองต้องการอะไร)
คำเตือน — user มักไม่รู้ว่าตัวเองต้องการอะไร ถ้าถามตรง ๆ "อยากได้อะไร?" — คำตอบมักจะเป็น "ม้าเร็วกว่าเดิม" (ไม่ใช่ "รถยนต์") · งานของคุณคือฟัง pain point จริง แล้วคิดทางแก้ที่เขาคิดไม่ถึง

Workshop 1 — สังเกตปัญหารอบตัว

เลือก 1 สถานที่ ที่คุณใช้เวลาเยอะที่สุด (ห้อง lab, ภาควิชา, หอพัก, ห้องเขียนแบบ) แล้ว:

  1. นั่งสังเกต 30 นาที ไปในเวลาที่มีคนใช้งาน · เงียบ ๆ ไม่คุย ดูว่ามีงานอะไรเกิดบ้าง — จดทุกอย่างที่เห็นในสมุด (ไม่เลือกก่อน)
  2. ระบุงานที่ทำซ้ำ งานไหน "ทำเหมือนเดิมทุกครั้ง"? — วงกลม (เซ็นชื่อเข้าห้อง · ตอบ LINE คำถามเดิม · เปิด-ปิดเครื่องตามลำดับเดิม · กรอก lab report header เดิม)
  3. ระบุข้อมูลที่หายไป งานไหนใช้ข้อมูลที่ "ไม่มีใครจดไว้"? (ใครยืมอุปกรณ์ · เครื่องไหนพังเมื่อไหร่ · นักศึกษาคนไหนติดขัดตรงไหน · ค่าวัดที่ลืมบันทึก)
  4. ระบุ "ใครเดือดร้อน" ในแต่ละปัญหา ใครคือคนที่ เสียเวลา / เครียด / ทำงานซ้ำ? — เขียนเป็น role (TA, อาจารย์, นักศึกษาปี 3, เจ้าหน้าที่ภาควิชา, แม่บ้าน)
  5. เลือก 3 ปัญหา ที่ "ถ้าแก้ได้ จะมีคน 5 คนขึ้นไปได้ประโยชน์" — เขียนเป็น Symptom สั้น
  6. ทำ 5 Whys + ตรวจ Rubric กับทั้ง 3 ปัญหา — เช็คทุกข้อใน rubric ด้านบน
  7. เลือก 1 ปัญหาไปต่อ — อันที่ user (1 คน) "ระบุได้" และคุณ "คุยได้"
  8. นัด user สัมภาษณ์ 20-30 นาที ใช้กฎ 8 ข้อ + คำถามมาตรฐาน 5 ข้อ · จดคำต่อคำ

Flowchart — สัญลักษณ์พื้นฐาน

Flowchart คือภาษากลางที่ทั้งมนุษย์ และ AI อ่านเข้าใจ — ก่อนสั่ง AI ให้สร้างอะไร ลองเขียน flowchart ของสิ่งที่อยากให้มันทำก่อน · AI จะเข้าใจคุณแม่นขึ้นมาก

⬭ Start / End

วงรี · จุดเริ่ม-จุดจบ

ทุก flowchart ต้องมี start และ end — ห้ามมี process ที่ลอย

▭ Process

สี่เหลี่ยม · การทำงาน 1 ขั้น

เช่น "คำนวณคะแนน", "บันทึกลงไฟล์" — เป็น verb + noun

◇ Decision

สี่เหลี่ยมข้าวหลามตัด · ตัดสินใจ

คำถาม yes/no เช่น "ผ่าน rubric?" — มีลูกศรออก 2 ทาง

▱ Input / Output

สี่เหลี่ยมขนาน · รับ-ส่งข้อมูล

เช่น "อ่านไฟล์", "พิมพ์ผล" — ทุก program ต้องมีอย่างน้อย I และ O

→ Arrow

ลูกศร · ทิศทางการไหล

เชื่อมระหว่างกล่อง — ห้ามมีลูกศรชนกันโดยไม่มี junction

○ Connector

วงกลม · จุดเชื่อม

ใช้เมื่อ flowchart ยาวจนต้องข้ามหน้า · ใส่ตัวอักษรเหมือนกัน

🎯 Flowchart "Current" — พี่นัทตรวจ drawing (ก่อนแก้)

เวลารวม ~8 ชั่วโมง · pain point อยู่ที่ "loop 50 ครั้ง" ที่ต้องสลับ Word + PDF + Classroom

flowchart TD A([ศุกร์ 9:00 น.]) --> B[/เปิด Classroom + ดาวน์โหลด 50 pdf/] B --> C[เปิด rubric ใน Word แยก tab] C --> D[เปิด pdf 1 ไฟล์ · zoom ดู drawing] D --> E{ผ่านแต่ละ criteria?} E -->|Yes| F[พิมพ์ feedback positive ใน Classroom] E -->|No| G[พิมพ์ feedback แก้ไข ใน Classroom] F --> H{ตรวจครบ 50 ชิ้น?} G --> H H -->|No · ~10 นาที/ชิ้น| D H -->|Yes| I([เที่ยงคืน · เสร็จ]) classDef pain fill:#7f1d1d,stroke:#ef4444,stroke-width:2px,color:#fff class D,E,F,G pain

⚠️ Pain: ขั้นในกรอบแดง ทำซ้ำ 50 ครั้ง · ~10 นาที/ชิ้น × 50 = 8 ชม.

🎯 Flowchart "Improved" — หลังมีระบบช่วย

เวลารวม ~3.5 ชั่วโมง · loop ยังอยู่ แต่ลดเหลือ ~4 นาที/ชิ้น เพราะ tools รวมในจอเดียว

flowchart TD A([ศุกร์ 9:00 น.]) --> B[/เปิด Grading App · ระบบโหลด pdf ให้/] B --> C[คลิก pdf รายคน · เห็น drawing + checklist พร้อมกัน] C --> D[tick checkbox criteria + พิมพ์ note สั้น] D --> E[ระบบสร้าง feedback text + คะแนน อัตโนมัติ] E --> F[/ส่งกลับ Classroom comment + gradebook/] F --> G{ตรวจครบ 50 ชิ้น?} G -->|No · ~4 นาที/ชิ้น| C G -->|Yes| H([บ่าย · เสร็จ]) classDef win fill:#064e3b,stroke:#34d399,stroke-width:2px,color:#fff class C,D,E,F win

✅ Win: ขั้นในกรอบเขียวเป็นกล่องเดียว · ประหยัด 4.5 ชม./สัปดาห์ × 16 สัปดาห์ = 72 ชม./เทอม

เทคนิคเขียน Flowchart เริ่มจากเขียนด้วย ปากกาบนกระดาษ ก่อนเสมอ · อย่ารีบเปิด draw.io/Mermaid เพราะจะติดอยู่กับการจัด layout · เขียนเสร็จและคุยจนแน่ใจกับเพื่อนก่อน ค่อยพิมพ์ลง diagram tool (W03 จะลงลึก)

🎨 ลองเขียน Mermaid Flowchart เลย

หลังวาดมือเสร็จ ลองพิมพ์ Mermaid syntax ของ flowchart พี่นัทดู — แก้ syntax ทางซ้าย จะเห็น diagram render ทางขวาทันที · เครื่องมือเต็ม + เทมเพลตอื่น ๆ ดูที่ 🎨 เครื่องมือสร้าง Diagram

flowchart TD A([ศุกร์ 9:00]) --> B[/เปิด Classroom + ดาวน์โหลด 50 pdf/] B --> C[เปิด rubric ใน Word] C --> D[เปิด pdf ทีละไฟล์] D --> E{ผ่านแต่ละ criteria?} E -->|Yes| F[พิมพ์ feedback positive] E -->|No| G[พิมพ์ feedback แก้ไข] F --> H[ส่ง comment ใน Classroom] G --> H H --> I{ตรวจครบ 50?} I -->|No| D I -->|Yes| J([เที่ยงคืน · เสร็จ])

Workshop 2 — เขียน Flowchart 2 แบบ ของ user คุณ

ใช้ปัญหา + interview note จาก Workshop 1 — ทำตามขั้นตอน:

  1. Flowchart "Current Workflow" — วาดสิ่งที่ user ทำ ตอนนี้ ทุกขั้น · ห้ามข้ามขั้น (ขั้นที่ดูไม่สำคัญ มักเป็นจุดที่ปัญหาเกิด)
  2. วงสี "Pain Point" — ขั้นไหนที่ "ช้า/ใช้เวลาเยอะ/ผิดบ่อย/ต้องทำซ้ำ" · วงด้วยปากกาแดง
  3. Flowchart "Improved Workflow" — ถ้าแก้ pain point จะหน้าตายังไง? · เปลี่ยน "ใช้เครื่องช่วย", "auto-fill", "ระบบกรอกครั้งเดียว"
  4. ระบุข้อมูลที่ระบบใหม่ต้องมี — Improved version ต้องการข้อมูลอะไร? เก็บที่ไหน? ใครเป็นคนกรอก?
  5. ส่ง flowchart ให้ user ดู — ขอ feedback — "พี่ดูถูกต้องตามที่ทำจริงมั้ย?" · ส่วนใหญ่จะมี 2-3 ขั้นที่คุณวาดผิด — แก้ตาม
  6. เขียน Problem Statement ใช้ template ด้านล่าง (มีตัวอย่างเต็มของพี่นัทให้ดู)

📝 Problem Statement — Template + ตัวอย่างเต็ม

Template

ปัญหา: [อะไรเกิดขึ้น]
ใครเดือดร้อน: [role + จำนวนคน]
ความถี่: [ทุกวัน / ทุกสัปดาห์ / ทุกเทอม]
ผลกระทบถ้าไม่แก้: [เสียเวลา / เสียงาน / เสียความน่าเชื่อถือ]
ทางออกที่อยากเห็น: [คนคนนั้นจะทำอะไรได้แทน]
สิ่งที่ ไม่ ทำ (Non-goals): [ตัดออกอะไรบ้าง]
จะรู้ว่าสำเร็จเมื่อ: [success metric เป็นตัวเลข]

📋 ตัวอย่างเต็ม — Problem Statement ของพี่นัท

**ปัญหา:**
TA ของวิชา Engineering Drawing ใช้เวลา 8 ชั่วโมงทุกวันศุกร์ในการตรวจ drawing
assignment 50 ชิ้น เนื่องจากต้องเปิด pdf ทีละไฟล์ เทียบ rubric ใน Word
แยกกัน แล้วพิมพ์ feedback ลง Classroom comment ทีละข้อ ทำให้ส่ง
feedback กลับล่าช้า 1 สัปดาห์เสมอ

**ใครเดือดร้อน:**
- TA (พี่นัท · 1 คน) — เสียคืนวันศุกร์ทุกสัปดาห์
- นักศึกษาปี 1 (50 คน) — ได้ feedback ช้า ทำผิดเดิมในงานถัดไป

**ความถี่:**
ทุกสัปดาห์ × 16 สัปดาห์ของเทอม = 128 ชม./เทอม

**ผลกระทบถ้าไม่แก้:**
- TA หมดไฟ · ภาควิชาหา TA ใหม่ทุกเทอม
- นักศึกษาไม่ปรับปรุงเพราะ feedback ไม่ทัน งานชิ้นต่อไป
- มี complaint จากผู้ปกครอง 2 ครั้งเทอมที่แล้ว

**ทางออกที่อยากเห็น:**
TA เปิด web app ขึ้นมา → เห็น drawing แต่ละชิ้นพร้อม rubric checklist
ในจอเดียว → tick checkbox + พิมพ์ note สั้น → ระบบสร้าง feedback
+ คะแนน → ส่งกลับ Classroom อัตโนมัติ

**สิ่งที่ไม่ทำ (Non-goals):**
- ไม่ตรวจคุณภาพ drawing อัตโนมัติด้วย AI
- ไม่แทน TA ในการตัดสินใจ
- ยังไม่รองรับ Auto-CAD/SolidWorks file (เฉพาะ pdf)
- ยังไม่ทำ mobile app

**จะรู้ว่าสำเร็จเมื่อ:**
- TA ตรวจ 50 ชิ้นได้ใน < 4 ชม. (จาก 8 ชม.)
- นักศึกษาได้ feedback ใน 24 ชม.หลังส่ง (จาก 1 สัปดาห์)
- TA บอกว่า "ใช้แล้วชีวิตดีขึ้น" หลังใช้ 3 สัปดาห์
สังเกต — Non-goals สำคัญพอ ๆ กับ Goals ตัวอย่างของพี่นัทตัด "AI grading" ออก · ไม่ใช่เพราะทำไม่ได้ — แต่เพราะ "ครั้งแรก ต้องเล็กพอที่ทำได้" · ใส่ Non-goals ทุกครั้ง · AI จะไม่ไปทำเกินขอบเขต

ข้อผิดที่พบบ่อย

เขียน flowchart จากสิ่งที่ "อยากให้เป็น" ทันที — ผิด! ต้องเขียน current workflow ก่อนเสมอ ถึงจะเห็น pain point จริง ถ้าข้ามขั้นนี้จะทำได้แค่ "วาดฝัน" ไม่ใช่ engineering
หลงทำ "App ของฉัน" แทน "ปัญหาของคนอื่น" — นักศึกษามักรีบเสนอ "อยากสร้างแอปสั่งอาหาร" · ลองถามตัวเองก่อน "ตอนนี้ใครสั่งอาหารแล้วเดือดร้อน?" — ถ้าตอบไม่ได้ แสดงว่ายังไม่มีปัญหาจริง
สัมภาษณ์โดยถามชี้นำ "พี่คงเหนื่อยกับการตรวจมากเลยใช่มั้ย?" — user จะตอบเออเอออย่างเดียวเพื่อจบบทสนทนา · ถาม open question เสมอ
ทำ flowchart ละเอียดเกินจนวาดไม่จบ — เริ่มที่ ระดับสูง 7-10 ขั้น ก่อน ห้ามเกิน 15 ถ้าจำเป็นต้องลึกค่อยแยกเป็น sub-flowchart

ส่งงานสัปดาห์นี้

Reference จาก slide เดิม

เนื้อหานี้เชื่อมโยงกับ Topic 1 — IntroFlowchart ของเอกสารประกอบการสอนเดิม + ขยายด้วย Mainidea Foundation 1 (Problem-finding) + 22 (Communication)

← กลับ
หน้าแรก