Final Project
ทำของจริงให้ user จริง

🎯 เป้าหมาย Final Project

สิ่งที่ทำให้ Final Project ของคู่มือนี้ ต่างจาก Final Project ทั่วไป — เกณฑ์ประเมินคือ:

• ✅ มี "real user" 1 คน ที่ "ขอใช้ด้วยตัวเอง"
• ✅ ของถูก ใช้จริงอย่างน้อย 3 ครั้ง ในชีวิตจริง
• ✅ User "พอใจ" และ "แนะนำให้คนอื่นใช้"
• ❌ ไม่นับ — "ทำสวย", "ใช้เทคโนโลยีใหม่", "code เยอะ"

📋 Spec — Final Project Requirements

🗺 Traceability — Final Project ใช้ทักษะจาก W01-W14

Final Project = บทรวม · ทุก week ที่เรียนมา ต้องเห็นใน project · นี่คือ checklist ที่ขาดอะไรไม่ได้

📝 Self-check: Project ของฉันใช้ทุก week มั้ย?

🚦 Day 0 — Pre-flight Checklist (ก่อนเริ่ม)

"ก่อนวันที่ 1" — ตอบ 8 ข้อนี้ก่อน · ถ้าตอบไม่ได้ → กลับไปคิด · เริ่มก่อนพร้อม = เสียเวลาทีหลัง

📜 Proposal Approval Gate

ส่ง proposal สั้น ๆ 1 หน้า ให้อาจารย์ "ก่อนเริ่ม" · ได้ approve ก่อน Day 1 · ป้องกัน scope ใหญ่เกิน

# Final Project Proposal — [ชื่อ project]

**User:** [ชื่อจริง · role · ทำไมเลือกคนนี้]
**Problem:** [1-2 ประโยค]
**Solution:** [1 ประโยค]
**Tech stack:** [Streamlit / Flask / LINE bot / ...]
**Deployment target:** [Cloud / Mobile / Desktop / IoT]
**Privacy:** [เก็บข้อมูลส่วนตัวมั้ย · จัดการยังไง]
**External services:** [API ที่ใช้ · cost estimate]
**Risk + Plan B:** [ความเสี่ยง 2 อย่าง + plan B แต่ละอัน]
**Why it's "right size":** [ทำไมไม่ใหญ่/เล็กเกิน]

🔐 Privacy + Ethics Review

ถ้า project เกี่ยวข้องกับ ข้อมูลของคนอื่น → ต้องผ่าน review นี้ก่อน deploy

✅ Privacy Checklist (จาก W10)

• ☐ User ยินยอม ให้ใช้ข้อมูล (consent ในรูปแบบที่บันทึกได้)
• ☐ ระบุชัด "ข้อมูลใช้ทำอะไร" ใน description
• ☐ ระบุชัด "ใครเห็น raw data ได้"
• ☐ ระบุชัด "ลบเมื่อไหร่" หลังคอร์สจบ
• ☐ Raw data ไม่ ใน public repo (gitignore private/)
• ☐ Anonymize ID/email ก่อน analyze · ก่อน publish dashboard
• ☐ ถ้าเก็บ password → hash ด้วย bcrypt · ไม่เก็บ plaintext
• ☐ ถ้าเก็บ API key → ใน .env · ไม่ใน code

⚖️ Ethics Checklist

• ☐ Project ไม่ harm ใคร (รวมทาง emotional / financial / reputational)
• ☐ AI ที่ใช้ ไม่ bias ในทาง gender/race/socioeconomic ที่ damage user
• ☐ Automation ไม่ replace human judgment ในเรื่องสำคัญ (ตัดสินใจทางการแพทย์/กฎหมาย)
• ☐ User เลือกออก ได้ตลอดเวลา
• ☐ ไม่ scrape ข้อมูลที่ไม่ได้รับอนุญาต (social media posts, web data)
• ☐ ไม่ใช้ copyrighted content เป็น training data
• ☐ ถ้า project เกี่ยวกับ hardware/IoT — มี fail-safe (W13: safety test)

🤖 AI Usage Disclosure — Academic Honesty

AI ช่วยเขียน code คือเรื่องปกติในยุคนี้ · แต่ "การไม่บอก" = academic dishonesty · ทุก Final Project ต้องมี AI_USAGE.md บอกตรง ๆ

📄 Template — AI_USAGE.md

# AI Usage Disclosure

## Tools ที่ใช้
- Cursor (Claude Sonnet 4.6) — main pair-programming
- ChatGPT (gpt-4o) — debug ครั้งคราว
- Claude API (Haiku) — ใน production สำหรับ summary feature

## AI ทำอะไรให้บ้าง
- [✅] เขียน boilerplate (`Flask app`, route definitions)
- [✅] สร้าง test cases หลังจากเขียน function เอง
- [✅] อธิบาย error message ที่ไม่เข้าใจ
- [✅] Generate Mermaid diagrams จาก spec
- [⚠️] เขียน function `calculate_grade()` ครั้งแรก · ผมแก้ logic เอง
- [❌] **ไม่ได้** ใช้ AI สำหรับ: spec writing · user interview · ตัดสินใจ scope

## สิ่งที่ผมเขียนเองล้วน ๆ
- spec.md
- user interview notes
- architecture decision records
- regression tests สำหรับ bug ที่เจอ
- README

## สิ่งที่ AI พลาด · ผมต้องแก้
1. AI ใช้ `df.dropna()` ทำลายข้อมูล 30% — แก้เป็น `dropna(subset=["x"])`
2. AI สร้าง class hierarchy 5 ชั้น สำหรับ "add 2 numbers" — refactor เป็น function
3. AI mock function ผิด level — แก้ patch ที่ถูกต้อง

🛡 Risk Register — รู้ว่าอะไรจะพัง ก่อนพัง

เขียน 3-5 ความเสี่ยง ที่ project อาจเจอ + plan B ของแต่ละอัน · ทำใน Day 0 · ทบทวนทุกวัน

📋 Risk Register Template

📝 ADR — Architecture Decision Records

ทุกครั้งที่ตัดสินใจใหญ่ (เลือก SQLite vs Postgres · เลือก Streamlit vs Flask · เลือก LLM ตัวไหน) → เขียน 1 ADR · ในงานจริง = standard practice

📄 Template — docs/adr/0001-choose-streamlit.md

# ADR-0001: เลือก Streamlit Cloud แทน Cloud Run

## Status
Accepted (2026-05-15)

## Context
- User เป็น TA ของอาจารย์ · เปิด URL บน laptop ในห้อง lab
- ต้องการ data dashboard ที่อัพเดตทุก 30 นาที
- มีเวลา 7 วัน · ทำคนเดียว

## Decision
ใช้ Streamlit Cloud (free tier) แทน Cloud Run

## Reasons
- ✅ Streamlit = Python ทั้งหมด · ไม่ต้องเขียน HTML/CSS
- ✅ Streamlit Cloud free · ไม่ต้องตั้ง Docker
- ✅ Deploy ใน 2 นาทีจาก git push
- ❌ Streamlit Cloud bandwidth limit · แต่ user 1 คน · พอ
- ❌ ไม่มี SLA — ถ้าพัง รอ 10 นาที · OK สำหรับ demo

## Consequences
- ถ้า user หลายคนใช้ → ย้ายเป็น Cloud Run
- ถ้าต้องการ custom domain → ต้อง upgrade ($20/เดือน) หรือใช้ Render

ทุก ADR 1 หน้า · 4-5 ADR ใน Final Project ก็พอ · ใส่ใน docs/adr/

♿ Accessibility — User บางคนต้องการความช่วยเหลือ

ถ้า user คือ พ่อ-แม่ (ตามตัวอย่างใน table) → accessibility สำคัญมาก · ถ้า user คือ เพื่อน Gen Z → ยังสำคัญ (50% ใช้บนมือถือ outdoor · จอเล็ก)

✅ Accessibility Checklist (เริ่มต้น)

• ☐ Font size ≥ 16px บน mobile · ≥ 14px บน desktop
• ☐ Color contrast ratio ≥ 4.5:1 (ใช้ WebAIM Contrast Checker)
• ☐ ไม่ใช้สีอย่างเดียว สื่อความหมาย (เพิ่ม emoji / text label) · เผื่อ colorblind
• ☐ Button area ≥ 44×44 px บนมือถือ (Apple guideline)
• ☐ Error message ภาษาไทย ที่อ่านเข้าใจ · ไม่ใช่ stack trace
• ☐ Loading indicator ทุกที่ที่ใช้เวลา > 1 วินาที
• ☐ ไม่ require account ถ้าไม่จำเป็น (พ่อแม่ลืม password)
• ☐ Test กับ user จริง ไม่ใช่แค่ตัวเอง — ทักษะ tech ของแต่ละคนต่างกัน

⏱ Estimation — ทำไม "7 วัน" จะกลายเป็น "14 วัน"

ความจริงของนักศึกษาทุกคน: ประเมินงานต่ำกว่าจริง 2-3 เท่า · "ผมว่าใช้ 2 ชั่วโมง" → 6 ชั่วโมง · "เสร็จคืนนี้" → 3 วัน · นี่ไม่ใช่ความขี้เกียจ — มัน "Planning Fallacy" ที่นักจิตวิทยายืนยันมา 30 ปี

📊 ทำไมประเมินผิด

📐 วิธีประเมินที่แม่นยำขึ้น — 3-Point Estimate

แทนที่จะให้ตัวเลขเดียว → ให้ 3 ตัว: best / likely / worst · เฉลี่ยน้ำหนัก

# Pessimistic-weighted average (PERT formula)
estimate = (best + 4 × likely + worst) / 6

ตัวอย่าง:
"Deploy ขึ้น Cloud Run"
- best:   30 นาที (ทำมาแล้ว · ทุกอย่างพร้อม)
- likely: 2 ชั่วโมง (ปกติ)
- worst:  6 ชั่วโมง (ติด billing · ติด IAM · ติด Docker)

→ (0.5 + 4×2 + 6) / 6 = 2.4 ชั่วโมง

🪜 Task Breakdown — เล็กไปเรื่อย ๆ จนเห็นชัด

ถ้าประเมินยาก = task ใหญ่เกิน · แตกเป็น sub-task < 2 ชั่วโมงต่ออัน

📈 กฎ "2x + 30% Buffer"

📋 Time-boxing — กฎเหล็กของ 7-day project

⚡ ถ้าใช้ AI — เพิ่มความเร็วไม่ใช่ครึ่ง

AI "ลดเวลาเขียน code" 50-80% · แต่ "เวลา debug + verify" เพิ่มขึ้น · เพราะต้อง review สิ่งที่ AI สร้าง · net = "ประหยัด ~30%" ถ้าใช้เป็น

📅 Timeline 7 วัน

🎨 ตัวอย่าง Project ที่ "ใช่"

🚫 ตัวอย่าง Project ที่ "ไม่ใช่"

• ❌ "Tetris" — ไม่มี user จริงเดือดร้อนกับเกม
• ❌ "Chatbot ตอบทุกคำถาม" — ไม่มี user เฉพาะ
• ❌ "AI Trading Bot" — เกินขอบเขต · เสี่ยง · ไม่มี user จริง
• ❌ "ระบบของมหา’ลัย" — ใหญ่เกิน · ไม่มี authority
• ❌ Copy tutorial มาเปลี่ยนชื่อ — ไม่มีคุณค่าใหม่

📋 Process — Spec ก่อน Code

วันที่ 1: หา User

1. คิดถึงคนรอบตัวที่ "บ่นเรื่องเดิม" บ่อย — เพื่อน, ครอบครัว, TA
2. นัดคุย 30 นาที — ฟังว่าเขาเสียเวลากับอะไร
3. ถาม: "ถ้ามีเครื่องช่วยทำ X ให้ คุณจะใช้บ่อยแค่ไหน?"
4. เลือก 1 ปัญหา → จด Problem Statement

วันที่ 2: Spec + Diagram

ใช้ template จาก W06:

## Spec: [ชื่อ project]

**User:** [ใคร · role · skill level]
**Problem:** [1 ย่อหน้า]
**Success criteria:** [user ทำอะไรได้ที่ทำไม่ได้ก่อน]

**Workflows:**
1. [Use case 1 · step-by-step]
2. ...

**Data:**
- [schema · primary keys]

**Constraints:**
- [tech limitation · time · cost]

**Non-goals:**
- [สิ่งที่ "ยังไม่ทำ"]

**Acceptance test:**
- [test scenario ที่ user ลงมือทำได้]

+ Diagrams (W03):

• C4 Container — ระบบมีอะไรบ้าง
• Sequence — flow หลัก
• ER — data schema

วันที่ 3-4: Build MVP

MVP = "ทำให้ user ทำสิ่งที่ตั้งใจให้ทำได้ ก่อน" · ไม่สวย ไม่ครบ · แต่ "ผ่านจุด pain" ของเขา

1. เริ่ม database schema (JSON/SQLite ก่อน)
2. เขียน function ที่ใช้บ่อยที่สุดก่อน — happy path
3. สร้าง UI (CLI / Streamlit / Flask) ที่ใช้ function นั้น
4. commit หลังทุก feature ที่ทำงานได้
5. หยุดเมื่อ "ครบ user story หลัก" · อย่าเพิ่ม feature ขณะ build

วันที่ 5: Test + Polish

1. เขียน pytest ≥ 10 cases
2. ลอง edge cases (W13)
3. เพิ่ม error message ที่ user อ่านเข้าใจ
4. ทำ UI ให้พอใช้ — ไม่ต้องสวย แต่อย่าทำ user สับสน
5. เซฟ regressions.md เผื่อ AI ทำพัง

วันที่ 6: Deploy + Docs

1. เลือก deploy method ตาม W14
2. ทดสอบ "fresh clone" — เพื่อนคนที่ไม่ใช่ user ลอง install
3. เขียน README ครบ — install + usage + screenshot
4. changelog.md + version 1.0.0

วันที่ 7: User Test + Demo

1. นัด user ใช้จริง 30 นาที
2. นั่งดูเขาใช้ "ไม่ช่วย" — สังเกตจุดที่งง
3. ถามคำถาม 3 ข้อ: "ใช้ง่ายมั้ย", "มีอะไรหายไป", "จะใช้อีกมั้ย"
4. แก้ของที่ user บ่นภายใน 2 ชั่วโมง
5. Demo 5 นาที — user ใช้จริงต่อหน้าคน

📊 Rubric (100 คะแนน)

🎤 Format ของ Demo

1. Hook (30 sec)
   "[User] เคยเสียเวลา X ทุกวัน · ผมสร้าง [Y] ให้เขา"

2. Problem (1 min)
   - แสดง workflow เดิม (flowchart)
   - บอกว่าเสียเวลา / ผิดบ่อยตรงไหน

3. Solution (1.5 min)
   - แสดง architecture (C4)
   - explain spec กับ non-goals

4. Live demo (1.5 min)
   - User ใช้จริงต่อหน้า
   - ใส่ข้อมูลจริง · เห็นผลลัพธ์จริง

5. Outcome (30 sec)
   - User ใช้ไปกี่ครั้งแล้ว
   - เปลี่ยน workflow เขายังไง

6. Reflection (30 sec)
   - "ถ้าได้ทำใหม่ จะเปลี่ยน X"

🧠 Reflection — สิ่งที่ต้องเขียน

# Reflection: [ชื่อ Project]

## ที่ทำสำเร็จ
- [3-5 ข้อ]

## ที่ไม่สำเร็จ / ยังขาด
- [3-5 ข้อ]

## AI ช่วยอะไรเป็นพิเศษ
- [อะไรที่ AI ทำได้ดีกว่าที่คาด]

## AI พลาดอะไรเป็นพิเศษ
- [อะไรที่ AI ทำผิด · ฉันต้องแก้]

## ที่เรียนรู้
- [3 ข้อหลัก]

## ถ้าทำใหม่ จะเปลี่ยน
- [3 ข้อ]

## Project นี้ใช้ทักษะอะไรจาก W01-W14 บ้าง
- [list]

🎓 Portfolio Path — Final Project → Resume / LinkedIn / สัมภาษณ์

Final Project ที่ดี ≠ คะแนน 100 · Final Project ที่ดี = "ของที่ใส่ resume ได้" · ผู้รับสมัครงานจะดูสิ่งที่คุณ "ทำได้" มากกว่าเกรด

📄 4 Assets ที่ต้องทำหลัง Final Project

📝 Resume Bullet Template — STAR Format

**Smart Lab Monitor** — Python · Flask · Streamlit · LINE bot
- (S) Situation: TA spent 8 hrs/week manually checking lab equipment
- (T) Task: Built automated PM2.5/temperature monitor with LINE alerts
- (A) Action: Designed REST API, integrated 3 external services (IQAir, LINE, Claude),
       deployed to Cloud Run with monitoring + budget alerts
- (R) Result: Reduced manual check time to < 1 hr/week · used daily by 5 TAs

[GitHub link] · [Live demo URL] · [Architecture diagram link]

🎤 สัมภาษณ์ — เล่ายังไง

เมื่อ interviewer ถาม "เล่า project ที่ภาคภูมิใจ" — ใช้ STAR:

1. Situation (15 sec) — user/problem · ไม่เริ่มที่ tech
2. Task (15 sec) — สิ่งที่คุณรับมาทำ
3. Action (60 sec) — สิ่งที่คุณ ตัดสินใจ · 2-3 key decisions
4. Result (30 sec) — metric ที่วัดได้ · feedback ของ user

🎁 Bonus Path — สำหรับคนที่อยากไปต่อ

• Maintain mode — ใช้ project นี้ต่อ 1 เทอม · เพิ่ม feature ตาม user request · เขียน CHANGELOG จริง
• Open source — public repo + MIT license · รับ PR จากเพื่อน
• ขยาย user base — จาก 1 คน → 5 คน · ดูว่า scale แบบไหนจะแตก
• Add 2nd deployment target — ถ้าทำ Cloud แล้ว · เพิ่ม PWA หรือ desktop .exe
• Compete — ส่งเข้า hackathon (Microsoft Imagine Cup · NSC Thailand · Showcase Day ของคณะ)
• Internship pitch — บริษัทเทคโนโลยีรับ portfolio · ใช้ Final Project เป็นข้อพิสูจน์

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

ส่งงาน Final Project

📦 Repository ครบ checklist

• 📁 GitHub repo public · live URL · "fresh clone" test ผ่าน
• 📄 spec.md + Spec Scorecard score ≥ 75%
• 📄 diagrams.md — C4 + sequence + ER (Mermaid)
• 📄 docs/adr/*.md — ≥ 3 Architecture Decision Records
• 📄 AI_USAGE.md — disclosure ตาม template
• 📄 CHANGELOG.md — v1.0.0 + ทุกการแก้
• 📄 reflection.md — สิ่งที่เรียนรู้
• 📄 RISKS.md — risk register + plan B
• 📄 PRIVACY.md — ถ้ามีข้อมูล user

📊 Evidence ครบ checklist

• 📷 Screenshot user ใช้ "จริง" 3 ครั้ง (ไม่ใช่ตัวเอง)
• 📷 Screenshot Sentry dashboard + UptimeRobot uptime
• 📷 Screenshot budget alert ของทุก service
• 📷 Screenshot mobile view (test บนมือถือจริง)
• 📷 Screenshot CI/CD passing (GitHub Actions green badge)
• 🎤 5-min demo video หรือ live · user ใช้สำเร็จต่อหน้า
• 📊 User feedback log — 3 คนทดสอบ + comments

🎓 Portfolio (Bonus +5 pts)

• 📝 LinkedIn post · blog post · resume bullet
• 🌟 GitHub repo มี ≥ 5 stars (ขอเพื่อนช่วย)
• 📺 Demo video บน YouTube · เปิด public

🌟 หลังจาก W15

จบคู่มือนี้ — คุณ ไม่ใช่ programmer มืออาชีพ · แต่คุณมี "workflow" ที่ programmer มืออาชีพใช้: เห็นปัญหา → spec → AI build → test → deploy → maintain

ปีต่อไปเรียนวิชาอื่น — เอา workflow นี้ไปใช้ · ค่าของคุณ ไม่ใช่ "เขียน Python ได้" · ค่าของคุณคือ "นำ AI ไปทำของจริงที่ใช้ได้"