ผังต้นแบบล่าสุด · 15 ตุลาคม 2569

P0 ใช้ ESP32-S3, Mini Solar, แบต 18650 สองก้อน และ Dual-Rail UPS ส่วน P1 มีแบตเตอรี่กับ Single-Rail UPS ของตัวเอง ข้อมูลส่วน P1 ยังขาดหลัง EC จึงยังไม่ยืนยันการเดินสาย P1–P3

ผังนี้ใช้ร่วมกับ Pitch 10 หน้า ค่าบัส 12 V และความจุ 1.2 kWh บนเว็บเป็นสมมติฐานสาธิตเดิม ไม่ใช่สเปกฮาร์ดแวร์ตามผังล่าสุด

เปิดผังต้นแบบล่าสุด · อ่านรายละเอียดและสิ่งที่รอยืนยัน · ดาวน์โหลด Pitch 10 หน้า

TEAM PLAYBOOK · PRESENTATION FIRST

ทำสไลด์ให้เสร็จ แล้วค่อยเล่าเรื่องเป็นวิดีโอ

หน้านี้แปลงเอกสาร “สรุปงานรอบนี้” ให้เป็นแผนลงมือทำ: ใครรับผิดชอบอะไร ต้องส่งชิ้นงานแบบไหน และจุดไหนที่ทั้งทีมต้องช่วยกันยืนยัน ใช้ติดตามงานได้จากช่องทำเครื่องหมายด้านล่าง

เปิดพจนานุกรมศัพท์ทีม ดูที่ปักและสิ่งที่ต้องหา ดูงานรายคน เปิดแผนสไลด์วางงานวิดีโอ

อ่านขอบเขตเอกสารให้ตรงกัน: PDF ที่แนบเป็นสรุปงานและการแบ่งหน้าที่ภายในทีม ระบุร่างสไลด์ 12 หัวข้อ ส่วนเกณฑ์ Presentation 7–10 หน้า และ Video Walkthrough 1–3 นาที / ไม่เกิน 100 MB / ถ่ายทำจริง เป็นข้อกำหนดที่ผู้ใช้ให้ไว้ในข้อความนี้ ให้ยึดแบบฟอร์มรับสมัครฉบับล่าสุดก่อนส่งจริง แผนด้านล่างจึงรวม 12 หัวข้อให้เป็นตัวอย่าง 9 หน้าเพื่อช่วยเริ่มงาน ไม่ใช่การแทนกติกาจากฟอร์ม

TEAM GLOSSARY · BUSINESS × IT × ELECTRONICS

พจนานุกรมศัพท์กลางของทีม

ศัพท์เดียวกันบางครั้งแต่ละสายเข้าใจไม่เหมือนกัน ให้ใช้ความหมายในคอลัมน์ “พูดให้ตรงกัน” เวลาทำสไลด์ ประชุม ออกแบบวงจร หรือเขียนผลทดสอบ คำจำกัดความนี้เป็นคู่มือทำงานของทีม ไม่ใช่สเปกทางการของอุปกรณ์

Case เคส / กรอบปัญหาโครงการ

พูดให้ตรงกัน: เรื่องปัญหาหนึ่งเรื่องที่มีคนได้รับผล บริบท หลักฐาน วิธีเดิม จุดติดขัด ความต้องการ และแนวทางทดลองครบเป็นชุด ไม่ได้แปลว่าผ่านการพิสูจน์แล้ว

Challenge โจทย์หรือธีมของโครงการ

พูดให้ตรงกัน: ขอบเขตที่โครงการชวนให้ทีมสำรวจ เช่น ความมั่นคงพลังงาน โจทย์ Challenge เป็นจุดเริ่มค้นหา ไม่ใช่หลักฐานว่าปัญหาเกิดกับคนในพื้นที่ตามสมมติฐานแล้ว

Stakeholder ผู้เกี่ยวข้อง

พูดให้ตรงกัน: คนหรือหน่วยงานที่ได้รับผล ใช้ระบบ ตัดสินใจ จ่ายเงิน ติดตั้ง ดูแล หรืออาจได้รับผลเสีย ผู้ใช้เครื่องอาจไม่ใช่ผู้จ่ายหรือผู้มีอำนาจตัดสินใจ

Workflow ลำดับงานที่คนทำจริง

พูดให้ตรงกัน: ขั้นตอนก่อนเกิดเหตุ–ขณะเกิดเหตุ–หลังเกิดเหตุ ระบุว่าใครทำอะไร ใช้ข้อมูล/เครื่องมือไหน รอใคร และติดตรงไหน แยก workflow ปัจจุบันออกจาก workflow ที่เราออกแบบ

Unmet need ความต้องการที่วิธีปัจจุบันยังตอบไม่ได้

พูดให้ตรงกัน: ผลลัพธ์ที่คนต้องการแต่ยังทำได้ยาก เช่น (ตัวอย่างเพื่ออธิบาย ยังต้องยืนยันกับผู้ใช้) “รู้ให้เร็วว่าโหลดใดดับและใครควรเข้าไปดู” เขียนจากมุมคน ไม่ตั้งต้นด้วยชื่อเทคโนโลยี เช่น “ต้องมี AI”

Value proposition คุณค่าที่คำตอบมอบให้

พูดให้ตรงกัน: ใครได้ประโยชน์อะไร เมื่อเทียบกับวิธีที่ใช้อยู่ และมีหลักฐานอะไรสนับสนุน อย่าใช้เพียงคำขวัญอย่าง “ฉลาดขึ้น” หรือ “ยั่งยืนขึ้น” โดยไม่มีผลที่วัดได้

ESG สิ่งแวดล้อม · สังคม · ธรรมาภิบาล

พูดให้ตรงกัน: ตรวจทั้งผลดี ผลเสีย และคนที่รับผล เช่น พลังงาน/แบตเตอรี่, ความปลอดภัยและความเป็นธรรมในการเข้าถึง, ใครดูแลข้อมูลและรับเรื่องร้องเรียน ไม่จำเป็นต้องยัดทุกมิติถ้าไม่เกี่ยวข้อง

PoC Proof of Concept · ทดลองพิสูจน์แนวคิด

พูดให้ตรงกัน: การทดลองขนาดเล็กเพื่อตอบคำถามสำคัญหนึ่งข้อ เช่น “P0 ตรวจเห็นแรงดันตกและบันทึกเวลาได้ไหม” ผล PoC ไม่ได้แปลว่าเป็นผลิตภัณฑ์พร้อมใช้หรือพิสูจน์ผลกระทบระยะยาวแล้ว

Prototype / Pilot / Mockup สามสถานะคนละอย่าง

Prototype: สิ่งที่ประกอบหรือทำงานได้บางส่วน · Pilot: ทดลองใช้ในบริบทจริงแบบจำกัด มีผู้เข้าร่วม ขอบเขต ความปลอดภัย และวิธีวัด · Mockup: ภาพหรือจอจำลองเพื่อสื่อแนวคิด ไม่ได้ยืนยันว่าระบบทำงาน

Baseline / Metric / KPI ค่าตั้งต้นและตัวชี้วัด

พูดให้ตรงกัน: Baseline คือค่าก่อนเริ่ม; Metric คือสิ่งที่วัด; KPI คือตัวชี้วัดหลักพร้อมนิยาม เป้าหมาย และช่วงเวลา เช่น เวลาจากเหตุถึงการแจ้งเตือน ก่อน/หลังต้องวัดด้วยวิธีเดียวกัน

Measured vs Inferred วัดตรง เทียบกับอนุมาน/คำนวณ

พูดให้ตรงกัน: ค่าที่เซนเซอร์อ่านโดยตรงต่างจากสถานะที่ซอฟต์แวร์จัดประเภทหรือค่าที่คำนวณขึ้นมา เช่น วัด voltage ได้ แล้วใช้กติกาจัดสถานะ “ไฟตก”; ต้องเก็บค่าดิบ สูตร หน่วย และเกณฑ์ไว้ตรวจย้อนกลับ ห้ามเรียกค่าที่อนุมานว่าเซนเซอร์วัดได้

Node โหนด / จุดอุปกรณ์

พูดให้ตรงกัน: อุปกรณ์หนึ่งจุดที่อ่านค่า ประมวลผล หรือส่งสถานะ ในแบบทีม P0 เป็นศูนย์กลาง; P1 ตรวจน้ำและไฟ; P2 ดูโหลดจำเป็น; P3 ดูโหลดทั่วไป คำว่า “โหนด” ไม่ได้หมายถึงคนหรือพื้นที่ชุมชน

Telemetry ข้อมูลวัด/สถานะที่ส่งจากอุปกรณ์

พูดให้ตรงกัน: ค่าพร้อมเวลาและรหัสโหนด เช่น แรงดัน แบตเตอรี่ หรือสถานะไฟ ที่อุปกรณ์ส่งให้ P0/หน้าจอ การเห็นค่าบน dashboard หมายถึงมีข้อมูลเข้ามา ไม่ได้แปลว่าค่านั้นแม่นจนตัดสินใจได้แล้ว

Payload / Schema เนื้อหาและรูปแบบข้อความ

พูดให้ตรงกัน: Payload คือข้อมูลหนึ่งข้อความ; Schema คือกติกาว่าต้องมีฟิลด์อะไรและหน่วยอะไร เช่น node_id, timestamp, voltage, current, battery, power_state ต้องกำหนดชื่อ หน่วย และค่าที่หายไปให้ทุกฝ่ายตรงกัน

Timestamp / Sequence เวลาและลำดับข้อมูล

พูดให้ตรงกัน: Timestamp บอกว่าอ่านหรือบันทึกค่าเมื่อใด; Sequence/seq ช่วยเรียงข้อความและรู้ว่าขาด/ซ้ำ อย่าสับสน “เวลาที่วัด” กับ “เวลาที่ส่งถึง P0” เพราะสัญญาณอาจมาช้า

last_seen / Online / Offline ได้รับข้อมูลล่าสุดเมื่อไร

พูดให้ตรงกัน: last_seen คือเวลาที่ P0 รับข้อมูลจากโหนดนั้นครั้งล่าสุด; ถ้าเกินช่วงที่กำหนดให้ขึ้น “ไม่พบข้อมูล/โหนดออฟไลน์” ก่อน ห้ามสรุปว่าไฟดับจนกว่าจะมีค่าไฟหรือสัญญาณไฟยืนยันแยกต่างหาก

Threshold ค่า/เงื่อนไขที่ทำให้เปลี่ยนสถานะหรือแจ้งเตือน

พูดให้ตรงกัน: ต้องระบุแหล่งที่มาของค่า หน่วย ระยะเวลาที่ต้องผิดปกติ และวิธียกเลิกเตือน ไม่เลือกตัวเลขเพราะ “ดูสมเหตุผล”; threshold น้ำต้องอิงชนิดเซนเซอร์ ขอบเขตการวัด และผู้เชี่ยวชาญ

ACK / Retry / Store-and-forward ตอบรับ · ส่งซ้ำ · เก็บรอส่ง

พูดให้ตรงกัน: ACK คือข้อความรับทราบว่าได้รับแล้ว; Retry คือส่งซ้ำตามกติกา; Store-and-forward คือเก็บข้อมูลไว้เมื่อเน็ต/วิทยุขาดแล้วส่งภายหลัง เป็นคุณสมบัติที่ต้องทดลองยืนยัน ไม่ถือว่ามีเพราะใส่ไว้ในแบบออกแบบ

Voltage แรงดันไฟฟ้า · V

พูดให้ตรงกัน: แรงดันเป็นความต่างศักย์ไฟฟ้าที่วัด ณ จุดและเวลาใดเวลาหนึ่ง ค่าแรงดันตกอาจชี้ว่าจ่ายไฟผิดปกติ แต่ต้องรู้ตำแหน่งวัด ช่วงวัด การสุ่มตัวอย่าง และเกณฑ์ที่ใช้ก่อนเรียกว่าไฟดับ

Current กระแสไฟฟ้า · A

พูดให้ตรงกัน: ปริมาณกระแสที่ไหลในวงจร ณ จุดวัด ใช้ดูว่ามีกระแส/โหลดดึงไฟเท่าใด ต้องต่อเซนเซอร์ให้เหมาะกับช่วงและทิศทาง ไม่เท่ากับ “พลังงานที่ใช้ไป” โดยตรง

Power กำลังไฟฟ้า · W

พูดให้ตรงกัน: อัตราการใช้พลังงาน ณ ขณะหนึ่ง สำหรับไฟ DC แบบพื้นฐานคำนวณจากแรงดัน × กระแส; ไฟ AC ต้องพิจารณารูปคลื่นและ power factor ด้วย อย่าสรุปค่า W จากเซนเซอร์ตัวเดียวถ้าไม่ได้วัดครบ

Energy พลังงาน · Wh

พูดให้ตรงกัน: ปริมาณไฟที่ใช้สะสมตามเวลา (เช่น Wh) ใช้ประเมินว่าแบตเตอรี่เลี้ยงโหลดได้นานแค่ไหน ต้องคำนึงถึงความจุที่ใช้ได้ ประสิทธิภาพวงจร และโหลดจริง ค่า W อย่างเดียวบอกเวลาสำรองไม่ได้

Load โหลด / อุปกรณ์ที่กินกำลังไฟ

พูดให้ตรงกัน: อุปกรณ์หรือวงจรที่ใช้พลังงาน เช่น ระบบควบคุม ปั๊ม หรือเครื่องเติมอากาศ คำว่า “P2 โหลดจำเป็น” เป็นระดับจัดลำดับของโครงการ ไม่ใช่คุณสมบัติทางไฟฟ้าที่เซนเซอร์อ่านได้เอง ต้องตกลงกับผู้ใช้ว่าอะไรจำเป็น

Sensor vs Actuator ตัววัด เทียบกับตัวสั่งงาน

พูดให้ตรงกัน: Sensor อ่านค่าหรือสถานะ; Actuator เช่น relay ทำให้วงจร/อุปกรณ์เปลี่ยนสภาพ การตรวจพบเหตุไม่ได้แปลว่าระบบสั่งตัด/จ่ายไฟได้ และเอกสารทีมระบุว่าต้นแบบยังไม่ควบคุมไฟบ้านจริง

Calibration / Accuracy / Range สอบเทียบ · ความคลาดเคลื่อน · ช่วงวัด

พูดให้ตรงกัน: Calibration คือเทียบ/ปรับกับเครื่องมืออ้างอิง; Accuracy คือใกล้ค่าจริงแค่ไหน; Range คือช่วงที่เซนเซอร์อ่านได้ คำว่า “เซนเซอร์อ่านได้” ไม่ได้แปลว่าแม่นพอใช้ตั้งสัญญาณเตือน ต้องมีผลเทียบและเงื่อนไขวัด

Salinity vs DO ความเค็มไม่ใช่ออกซิเจนละลายน้ำ

พูดให้ตรงกัน: Salinity คือความเค็ม; DO (Dissolved Oxygen) คือออกซิเจนที่ละลายในน้ำ เป็นคนละตัวแปร ต้องใช้หัววัด DO แยกถ้าจะวัดออกซิเจน เอกสารทีมบอกว่าความเค็ม/อุณหภูมิช่วยเฝ้าระวัง แต่ไม่ได้วัด DO โดยตรง

Low voltage / Isolation / Fail-safe ขอบเขตแรงดันและการทำงานเมื่อขัดข้อง

พูดให้ตรงกัน: Low voltage ต้องบอกค่าแรงดันจริง ไม่ใช้เป็นคำรับรองความปลอดภัยทุกกรณี; Isolation คือการแยกส่วนวงจรตามการออกแบบ; Fail-safe คือเมื่อผิดปกติแล้วระบบไปสู่สภาพที่ลดอันตราย ต้องกำหนดและทดสอบ ไม่ใช่แค่ใส่ชื่อในสไลด์

ไฟดับ / ไฟตก / โหนด Offline สามเหตุการณ์คนละแบบ

พูดให้ตรงกัน: ไฟดับคือแหล่งจ่าย/แรงดันผิดปกติ; ไฟตกคือแรงดันต่ำกว่าช่วงที่กำหนด; Offline คือไม่ได้รับข้อมูลจากโหนดตามเวลา อาจเกิดจากไฟ วิทยุ ซอฟต์แวร์ หรือแบตเตอรี่ จึงต้องเก็บสัญญาณแยกและแจ้งต่างกัน

ไม่พบคำนี้ ลองค้นด้วยคำไทยหรือภาษาอังกฤษสั้นลง

ประโยคทีมที่ช่วยลดความเข้าใจผิด: “P0 ยังไม่ได้รับข้อมูลจาก P1 เกิน X นาที” คือสิ่งที่ telemetry ยืนยันได้; จะพูดว่า “ไฟดับ” ก็ต่อเมื่อมีการวัดแรงดัน/สถานะไฟรองรับ ส่วน X ต้องตกลงและทดสอบ ไม่ตั้งตัวเลขขึ้นเอง

คำอธิบาย P0–P3, ฟิลด์ข้อมูล, last_seen, แยกไฟดับกับสื่อสารหาย, เซนเซอร์น้ำ และขอบเขตวงจรอิง PDF สรุปงานหน้า 1–7 · เปิดเอกสารต้นทาง ↗. การเทียบความหมายกับเกณฑ์ส่งงานดูได้ใน เกณฑ์กลาง และ Decision Board.

WORK ORDER

ลำดับทำงานที่ลดการรอกัน

เริ่มจากเล่าให้ชัดว่าปัญหาคืออะไรและใครได้รับผล จากนั้นประกอบคำตอบของทีมจากชิ้นงานของแต่ละคน เมื่อเนื้อหาและหลักฐานในสไลด์พร้อมแล้ว จึงเลือกคนเล่าเรื่องและทำวิดีโอแยก

1 · สรุปปัญหา→2 · รวมคำตอบจากเจ้าของงาน→3 · ทำสไลด์และตรวจหลักฐาน→4 · เลือกผู้ Pitch→5 · ถ่าย Video Walkthrough

PART A · PROBLEM PITCH

ช่วงพรีเซนต์ปัญหา

อธิบายเหตุการณ์ไฟตก/ไฟดับและผลต่อโหลดสำคัญในบริบทชุมชนหรือพื้นที่เพาะเลี้ยงปลา
แสดงว่าใครได้รับผล กระบวนการเดิมเป็นอย่างไร และเมื่อเกิดเหตุคนทำอะไรอยู่
แยกสิ่งที่ทีมมีหลักฐานแล้ว ออกจากสิ่งที่ยังเป็นสมมติฐานหรือรอสัมภาษณ์/ทดลอง
นายวางเรื่องและโครงสไลด์; ข้าวฟ่างช่วยแปลงบริบทและตรวจภาษา; ทุกคนเติมข้อเท็จจริงจากงานตัวเอง

PART B · SOLUTION PITCH

ช่วงพรีเซนต์ตัวแก้ปัญหา

เล่าว่า Community Energy Resilience Platform ทำอะไร: ไฟฟ้าเป็นแกนหลัก ข้อมูลความเค็มและอุณหภูมิใช้เฝ้าระวังความเสี่ยงด้านน้ำ
ไล่โครงสร้าง P0–P3 ทางเดินพลังงาน ข้อมูล เซนเซอร์ หน้าจอ และการแจ้งเตือน
แสดง User Flow หรือภาพระบบอย่างน้อยหนึ่งภาพ และอธิบายมาตรการไม่ให้เข้าใจผิดระหว่างไฟดับกับโหนดสื่อสารหาย
พูดให้ตรงว่าทำจริง / จำลอง / ยังเป็นแผน รวมข้อจำกัดและผลเสียข้างเคียง

เลือกระดับความพร้อมตามหลักฐาน: สถานะบนสไลด์ต้องสะท้อนการทำงานจริง ไม่ใช่เป้าหมายที่อยากไปให้ถึง; ถ้ายังไม่มีหลักฐานรองรับ ให้ระบุว่ายังไม่ยืนยันหรืออยู่ระหว่างศึกษา

สถานะที่ทีมจะใช้ในร่างสไลด์

เลือกหลังทีมรวมหลักฐานแล้วเท่านั้น เครื่องมือนี้บันทึกไว้ในเบราว์เซอร์นี้เพื่อช่วยเตือนการทำงาน

กติกากลางจากเอกสารทีม: ต้นแบบปัจจุบันเป็นแรงดันต่ำ ยังไม่ควบคุมไฟบ้านจริง; P1 วัดความเค็มและอุณหภูมิ ไม่ได้วัดออกซิเจนในน้ำโดยตรง; โซลาร์ แบตเตอรี่ขนาดใหญ่ และวงจรสำรองอาคารเป็นแนวทางต่อยอด ไม่ใช่ความสามารถที่ยืนยันแล้ว

DECISION BOARD · EVIDENCE BEFORE CLAIMS

อะไรปักแล้ว อะไรต้องหาเพิ่ม และทำไปเพื่ออะไร

บอร์ดนี้แยกสถานะจากแหล่งที่มาออกจากสถานะตัดสินใจของทีม: “เอกสารทีมระบุแล้ว” ไม่ได้แปลว่าพิสูจน์ว่าใช้จริงได้; “ข้อเสนอของเว็บ” ยังรอทีมรับรอง; ส่วน “ต้องหา/ทดลอง” คือหลักฐานที่ขาดก่อนฟันธง

หลักอ่านสถานะ: คอลัมน์เกณฑ์บอกว่าส่วนใดเชื่อมกับสิ่งที่ต้องส่งตามข้อมูลแบบฟอร์มที่คุณให้มา ส่วน “ผลต่อการใช้จริง” บอกว่าข้อมูลนั้นช่วยตัดสินใจออกแบบ ทดลอง หรือดูแลระบบอย่างไร เรื่องบางอย่างจำเป็นต่อความปลอดภัยและความเป็นไปได้ แม้ไม่ได้เป็นหัวข้อบังคับเฉพาะในสไลด์

ระบุใน PDF / ขอบเขตตั้งต้นข้อเสนอ รอทีมปักหาหลักฐานเพิ่มต้องทดสอบก่อนกล่าวอ้าง

แสดง 12 หัวข้อบันทึกการตัดสินใจในเบราว์เซอร์นี้ · ถ้าจะย้ายเครื่องให้ใช้ export ของทีมแยกต่างหาก

1 · ปัญหาเกิดกับใครและเกิดเมื่อไร

ต้องหาเพิ่ม

ตอนนี้รู้อะไร: เอกสารวางบริบทไฟตก/ไฟดับและโหลดสำคัญในพื้นที่เพาะเลี้ยงปลา แต่หน้านี้ยังไม่มีบันทึกสัมภาษณ์หรือ log หน้างานยืนยันความถี่และผลกระทบเฉพาะราย
หาอะไร / จากใคร: เหตุการณ์วันเวลา ระยะดับ โหลดที่ได้รับผล ค่าเสียหาย/เวลาหยุด และวิธีสำรองปัจจุบัน จากผู้เลี้ยงปลา ผู้ดูแลระบบไฟ/อุปกรณ์ และผู้รู้พื้นที่; แยกสิ่งที่เห็นเองกับสิ่งเล่าต่อ
เกี่ยวเกณฑ์: ตรงกับ “ปัญหาและผู้ได้รับผลกระทบ” และ “บริบท/วิธีเดิม” ใน Presentation
ช่วยให้ใช้จริงอย่างไร: ยืนยันว่ากำลังแก้เหตุที่เกิดจริง เลือกจุดติดตั้งและโหลดเป้าหมายถูก และตั้งเส้นฐานวัดผลก่อน/หลังได้
เจ้าของ / หลักฐานส่ง: นาย + ข้าวฟ่าง; interview notes ที่ได้รับความยินยอม, event log หรือเอกสารท้องถิ่นพร้อมวันที่และขอบเขต
ต้นทาง: PDF หน้า 2 เป็นบริบท/ขอบเขตตั้งต้น ไม่ใช่หลักฐานภาคสนาม

2 · วิธีเดิมและ workflow หน้างาน

ต้องหาเพิ่ม

ตอนนี้รู้อะไร: PDF ระบุ workflow ของระบบที่ออกแบบ แต่ยังต้องรู้ขั้นตอนของคนใช้ก่อนมีระบบ เช่น ใครรู้เหตุ โทรหาใคร ปิด/เปิดโหลดอย่างไร และใช้เวลานานแค่ไหน
หาอะไร / จากใคร: เดินตามขั้นตอนจริงตั้งแต่เกิดเหตุจนฟื้นตัว; ถามสิ่งที่ทำแทนระบบอยู่แล้ว ปัญหาที่เกิดซ้ำ ค่าใช้จ่าย เวลา และข้อจำกัดในการเข้าถึง
เกี่ยวเกณฑ์: หัวข้อ “บริบท วิธีเดิม และ workflow” ระบุโดยตรงในรายการ Presentation
ช่วยให้ใช้จริงอย่างไร: ทำให้ระบบเข้ากับการทำงานเดิม ไม่เพิ่มภาระ ไม่ซ้ำเครื่องมือที่มี และออกแบบการแจ้งเตือนให้ไปถึงคนรับผิดชอบ
เจ้าของ / หลักฐานส่ง: ข้าวฟ่างนำเก็บ / นายช่วยสรุป; swimlane หรือ process map พร้อมแหล่งข้อมูลและขั้นที่ยังไม่ทราบ
ต้นทาง: PDF หน้า 2–3 เป็น workflow ของระบบที่ออกแบบ ต้องเก็บวิธีทำจริงจากผู้ใช้เพิ่ม

3 · สถาปัตยกรรม P0–P3

ระบุใน PDF

ปักไว้ในเอกสาร: P0 เป็นศูนย์กลางรับข้อมูล/ประเมินเหตุ/จัดลำดับโหลด; P1 น้ำและไฟ; P2 โหลดจำเป็น; P3 โหลดทั่วไป
ทำไปเพราะอะไร: เป็นโครงเรื่องกลางให้แผนภาพ หน้าจอ ข้อมูล และการสาธิตเรียกชื่อโหนดตรงกัน
เกี่ยวเกณฑ์: ช่วยอธิบาย Solution, User Flow/Diagram และความเป็นไปได้; PDF/รูปแบบ P0–P3 ไม่ใช่เงื่อนไขสมัครเฉพาะที่พิสูจน์คุณค่าได้เอง
ผลต่อใช้จริง: ต้องผูกแต่ละโหนดกับอุปกรณ์ จุดติดตั้ง ผู้ดูแล และพฤติกรรมเมื่อหลุดการสื่อสาร จึงจะเปลี่ยน block diagram เป็นระบบประกอบได้
ยืนยันเพิ่ม: นายเป็นเจ้าของผัง; ให้โฟล์ค/พี/บอสตรวจบทบาทกับของจริงที่ต่อและส่งข้อมูลได้ ปรับหากต้นแบบปัจจุบันต่างจากคำอธิบายใน PDF
ต้นทาง: PDF หน้า 1–2 · เปิดหน้าที่ 2 ↗

4 · ไฟฟ้าเป็นแกนหลัก; น้ำเป็นข้อมูลเฝ้าระวัง

ระบุใน PDF

ปักไว้ในเอกสาร: ระบบเน้นไฟฟ้า; ความเค็มและอุณหภูมิเป็นสัญญาณเฝ้าระวังความเสี่ยงด้านน้ำ ไม่ได้วัดออกซิเจนในน้ำโดยตรง
ทำไปเพราะอะไร: ป้องกันการอ้างความสามารถเกินเซนเซอร์ที่ติดตั้ง และแยก “ค่าที่อ่านได้” ออกจาก “ความหมายทางชีวภาพ”
เกี่ยวเกณฑ์: สอดคล้อง Solution, ข้อจำกัด PoC และป้องกันผลเสียข้างเคียงจากคำแนะนำผิด
ผลต่อใช้จริง: ถ้าจะเตือนหรือแนะนำการเลี้ยงปลา ต้องสอบเทียบกับเครื่องมืออ้างอิง/ผู้เชี่ยวชาญและดูชนิดปลา ฤดูกาล จุดวัด ก่อนตั้งเกณฑ์ใช้งาน
เจ้าของ / หลักฐานส่ง: โฟล์คยืนยันชนิดเซนเซอร์ ช่วง/ความคลาดเคลื่อน วิธีสอบเทียบ และบอกว่าต้องมี DO sensor แยกหรือไม่; รูปและผลเทียบค่าจริง
ต้นทาง: PDF หน้า 1–2 · เปิดหน้าที่ 2 ↗

5 · ขอบเขตแรงดันต่ำและไม่ควบคุมไฟบ้าน

ระบุใน PDF

ปักไว้ในเอกสาร: ต้นแบบใช้แรงดันต่ำ ยังไม่ควบคุมไฟบ้านจริง; แหล่งจ่าย/แบตเตอรี่ขนาดใหญ่และโหลดบางชนิดเป็นส่วนจำลอง
ทำไปเพราะอะไร: กำหนดขอบเขตสาธิตและสื่อสารความเสี่ยงอย่างตรงไปตรงมา ไม่ชวนให้ต่อวงจรจริงเกินความพร้อม
เกี่ยวเกณฑ์: ต้องรายงาน PoC/ผลทดลอง/ข้อจำกัด และป้องกันผลเสียข้างเคียง; ไม่พบว่าแรงดันต่ำเป็นรูปแบบบังคับของสไลด์จากข้อมูลที่ให้มา
ผลต่อใช้จริง: ใช้จริงต้องออกแบบ isolation, protection, fail-safe, การติดตั้งและผู้รับผิดชอบโดยผู้เชี่ยวชาญก่อน ไม่ควรทดสอบกับไฟบ้านจากต้นแบบนี้
เจ้าของ / หลักฐานส่ง: โฟล์คอัปเดตขอบเขตฮาร์ดแวร์ล่าสุด พร้อมภาพแยก “ต่อจริง” กับ “จำลอง”; ทีมตรวจถ้อยคำสไลด์ให้ตรงกัน
ต้นทาง: PDF หน้า 1–2 · เปิดหน้าที่ 2 ↗

6 · จัดลำดับโหลดและสำรองพลังงาน

ต้องทดสอบ

ข้อเสนอใน PDF: รักษา P0; ลด/ตัด P3 ก่อน และ P2 เมื่อจำเป็น; โหลด P1 สำคัญหลัง P0 ตามพลังงานที่มี แต่เอกสารระบุว่าอุปกรณ์/เหตุการณ์หลายส่วนเป็นการจำลอง
หา/ทดสอบอะไร: สมมติฐานเวลาใช้งานแบต ภาระโหลดจริง สถานะเมื่อพลังงานต่ำ การกู้คืน และผลหากรีเลย์/เซนเซอร์ล้มเหลว
เกี่ยวเกณฑ์: พิสูจน์ Solution และแผนทดลอง; ลำดับในภาพอย่างเดียวไม่ใช่ผลยืนยัน
ผลต่อใช้จริง: บอกได้ว่าโหลดใดอยู่ได้นานแค่ไหน และระบบตัดสินใจปลอดภัยหรือไม่ ต้องวัดกำลัง/พลังงานและทำ failure test ในวงจรแรงดันต่ำ
เจ้าของ / หลักฐานส่ง: นาย + โฟล์ค; ตารางโหลด/ระยะเวลา/เงื่อนไข/ผลจริง–จำลอง และสิ่งที่ไม่อนุญาตให้ระบบควบคุม
ต้นทาง: PDF หน้า 2–3 · เปิดหน้าที่ 3 ↗

7 · สถานะออนไลน์ การส่งซ้ำ และข้อมูลหาย

ต้องหาเพิ่ม

ตอนนี้รู้อะไร: PDF แนะนำแยกไฟดับออกจากการสื่อสารหาย โดยใช้สถานะไฟร่วมกับ last_seen; รอบส่ง ACK timeout retry และการเก็บข้อมูลออฟไลน์ยังเป็นแนวทางให้กำหนด
กำหนด/ทดสอบอะไร: รูปแบบ packet, interval, sequence, เวลา, retry limit, stale threshold, duplicate handling และ store-forward ที่ระบบปัจจุบันทำได้จริง
เกี่ยวเกณฑ์: เป็นหลักฐานความเป็นไปได้ของ Solution และ PoC; ไม่ใช่จำนวนฟิลด์ที่ฟอร์มระบุบังคับ
ผลต่อใช้จริง: ลดการแจ้ง “ไฟดับ” ผิดเมื่อ node offline และลดเหตุที่ผู้ดูแลพลาดเพราะข้อมูลค้าง; ต้องทดสอบกับสัญญาณ/ไฟดับที่จำลอง
เจ้าของ / หลักฐานส่ง: บอส + พี; ตัวอย่างข้อความและ log ส่งสำเร็จ/หาย/ส่งซ้ำ พร้อมค่าตั้งและเวลาที่วัดได้
ต้นทาง: PDF หน้า 5–6 · เปิดหน้าที่ 5 ↗

8 · Alarm threshold และคนรับแจ้ง

ต้องหาเพิ่ม

ยังไม่รู้: threshold ที่เหมาะกับแต่ละโหลด/สภาวะน้ำ ใครเป็นคนรับและตอบสนอง false alarm ที่ยอมรับได้ และถ้าไม่มีคนรับจะทำอย่างไร
หาอะไร / จากใคร: คุยผู้ใช้/ผู้ดูแล กำหนดเหตุการณ์กับการกระทำที่เหมาะสม; สร้าง threshold จากมาตรฐาน/ผู้เชี่ยวชาญและข้อมูลวัดจริง ห้ามคิดค่าขึ้นเอง
เกี่ยวเกณฑ์: ช่วยแสดง User Flow, หน้าจอ/แจ้งเตือน, user fit และแผนทดลอง; ข้อความแจ้งเตือนควรบอกอะไร-ที่ไหน-เมื่อไร-ควรทำอะไรต่อ
ผลต่อใช้จริง: แจ้งเตือนที่ไม่มีผู้รับผิดชอบ หรือดังบ่อยจนละเลย ทำให้ระบบไม่มีคุณค่าแม้เซนเซอร์อ่านได้
เจ้าของ / หลักฐานส่ง: พี + ข้าวฟ่าง; ตารางเหตุ→threshold ที่มีที่มา→ผู้รับ→action→ผลการซ้อมรับแจ้ง
ต้นทาง: PDF หน้า 5 มีแนวทางแจ้งเตือนและช่องให้ทีมกำหนดค่าจริง · เปิดหน้าที่ 5 ↗

9 · รูปแบบสไลด์ 9 หน้า

ข้อเสนอเว็บ · รอทีมปัก

ข้อเสนอปัจจุบัน: รวมรายการ 12 หัวข้อจาก PDF ให้เป็น 9 หน้า เพื่ออยู่ในช่วง Presentation 7–10 หน้า และเว้นที่ให้ปัญหา วิธีเดิม Solution, User Flow, PoC, ผลกระทบ
ทำไปเพราะอะไร: ลดงานซ้ำและทำให้นำเสนอเป็นเรื่องเดียว; จำนวน 9 เป็นทางเลือกของทีม ไม่ใช่ข้อกำหนดให้ต้องใช้ 9
เกี่ยวเกณฑ์: ช่วง 7–10 หน้าและเนื้อหาหลักมาจากเกณฑ์ที่ผู้ใช้ให้; ต้องตรวจภาษา/รูปแบบกับแบบฟอร์มล่าสุด
ผลต่อใช้จริง: ถ้าข้อมูลสำคัญเกินพื้นที่ 9 หน้า ให้ขยับเป็น 10 หรือลดเฉพาะข้อความซ้ำ ไม่ตัดหลักฐานและข้อจำกัด
ให้ทีมตัดสินใจ: นายเลือกจำนวนหน้าหลังดูข้อมูลจากเจ้าของงาน; เลือก “ยืนยัน / แก้ / ไม่ใช้” ด้านล่างหลังทีมเห็น outline
ต้นทาง: รายการ 12 หัวข้อใน PDF หน้า 2–3 ถูกยุบเป็นข้อเสนอ 9 หน้า + เกณฑ์ 7–10 หน้าจากข้อความที่คุณให้

สถานะทีม

10 · ทำวิดีโอหลังสไลด์และเลือก Pitcher

ปักลำดับงาน · คนยังไม่เลือก

ปักจากคำสั่งทีม: ทำ Presentation ก่อน แล้วค่อยหาคน Pitch; แยกงานวิดีโอ ใช้เรื่อง/สไลด์ที่ทำแล้วมาวาง storytelling
ทำไปเพราะอะไร: บทและเดโมจะอิงเฉพาะสิ่งที่ทีมมีหลักฐาน ลดการเขียนเรื่องใหม่ซ้ำและลดการกล่าวเกินจริง
เกี่ยวเกณฑ์: ความยาว 1–3 นาที ≤100 MB ถ่ายทำจริง ไม่ใช้ AI สร้างวิดีโอ และอธิบายประกอบสไลด์ เป็นเงื่อนไขจากข้อมูลที่ผู้ใช้ให้
ผลต่อใช้จริง: คนพูดต้องตอบคำถามและอธิบายข้อจำกัดได้; ถ่ายต้นแบบจริงเท่าที่ปลอดภัย พร้อมบอกชัดเมื่อเป็นภาพจำลอง
ยังต้องทำ: เลือกคนเล่า คนถือกล้อง/เสียง ทำ script, shot list และตรวจขนาดไฟล์จากฟอร์มล่าสุด
ต้นทาง: ลำดับหลังสไลด์และข้อกำหนดวิดีโออ้างอิงจากข้อความที่คุณให้ ไม่ใช่ข้อสรุปจาก PDF

สถานะทีม

11 · PoC และระดับความพร้อม

ต้องพิสูจน์

ยังต้องเติม: รายการที่ต่อได้จริง ผลผ่าน/ไม่ผ่าน สภาพแวดล้อม จำนวนรอบ เวลาแจ้งเตือน ความคลาดเคลื่อน และข้อจำกัด; หากยังไม่มีให้เขียนว่าไม่มีผล
เกณฑ์เกี่ยวข้อง: ระบุสถานะ PoC/ผลทดลอง/ข้อจำกัด และเลือก readiness ระดับ Idea → วิเคราะห์/ปรึกษา → prototype ทดลองกลุ่มตัวอย่าง → ใช้จริงในชุมชน → ธุรกิจที่มีรายได้ต่อเนื่อง
ผลต่อใช้จริง: ช่วยรู้ว่าก่อนติดตั้งต้องแก้เรื่องใด และไม่ทำให้ผู้ใช้/กรรมการเข้าใจว่าระบบใช้งานจริงแล้ว
เจ้าของ / หลักฐานส่ง: เจ้าของแต่ละชิ้นทดสอบส่ง raw log/photo/date/conditions; ข้าวฟ่างจัด proof matrix; ทุกคนตรวจ readiness ว่าไม่สูงกว่าผลจริง
ต้นทาง: PDF หน้า 3 และ 7 · เปิดหน้าที่ 7 ↗

12 · คนดูแล ต้นทุน ความยินยอม และทางซ่อม

ต้องหาเพิ่มก่อนใช้จริง

ตอนนี้ยังไม่ตอบ: ใครติดตั้ง/ดูแล/เปลี่ยนอุปกรณ์ จ่ายค่าไฟและ data ใครเห็นข้อมูล ชุมชนยินยอมหรือไม่ และจะซ่อมเมื่อระบบเสียได้ที่ไหน
เกี่ยวเกณฑ์: ผู้เกี่ยวข้อง แผนทดลอง ผลกระทบ ESG และแผนต่อยอดอยู่ใน Presentation; รายละเอียดต้นทุนอาจไม่ใช่ฟอร์มบังคับแต่เป็นข้อจำกัด feasibility
ผลต่อใช้จริง: ถ้าไม่มีเจ้าของ ไม่มีงบบำรุง หรือไม่มีคนตอบ alarm ระบบอาจหยุดหลังจบ hackathon; เรื่องข้อมูล/ไฟฟ้าต้องมีขอบเขตและผู้รับผิดชอบ
หาอะไร / จากใคร: คุยผู้ใช้ ผู้ดูแลอุปกรณ์ หน่วยงานพื้นที่; ประมาณ BOM/พลังงาน/เปลี่ยนอุปกรณ์/สื่อสาร และทำ data access + consent plan
เจ้าของ / หลักฐานส่ง: ข้าวฟ่างกับนายรวบรวม; ทุกฝ่ายยืนยันต้นทุน/ภาระดูแลในส่วนของตัวเอง พร้อมผู้ติดต่อและสมมติฐาน
ต้นทาง: PDF หน้า 3–7 มีแนวทางผลกระทบและแผนต่อยอด; เรื่องต้นทุน/การดูแลเป็นข้อมูลที่ต้องวิจัยเพิ่ม

ลำดับเก็บข้อมูลที่แนะนำ: (1) ยืนยันผู้ได้รับผลและ workflow ก่อนล็อกว่าปัญหาอยู่ตรงไหน → (2) เทียบวิธีเดิมและคนรับผิดชอบ → (3) ตรวจว่าต้นแบบวัด/ส่ง/แจ้งอะไรได้จริง → (4) ทดลอง failure mode และการใช้งานปลอดภัย → (5) ค่อยกำหนด readiness, ผลกระทบและแผนต่อยอด หัวข้อที่เป็นข้อกำหนดของสไลด์ให้ครบ ส่วนที่ไม่ใช่ข้อกำหนดแต่จำเป็นต่อการนำไปใช้ให้คงไว้ใน risk/แผนทดลอง

WHO DOES WHAT

แบ่งงานรายคน พร้อมของที่ต้องส่ง

ทุกคนเริ่มทำส่วนของตัวเองพร้อมกันได้ ไม่ต้องรอให้สไลด์หลักเสร็จ ส่งเป็นร่างอ่านรู้เรื่อง พร้อมหลักฐานและสถานะจริง แล้วทีมค่อยนำไปประกอบ

น

นาย · เจ้าของเรื่องและภาพรวมระบบ

รับผิดชอบหลัก: โครงสไลด์ ปัญหา ภาพรวมและขอบเขต P0–P3

ต้องส่ง

ร่างลำดับสไลด์ 7–10 หน้าและข้อความสั้นสำหรับแต่ละหน้า
คำอธิบายปัญหาและผลกระทบที่ตรวจที่มาได้ ร่วมกับข้าวฟ่าง
ภาพรวมระบบ บทบาท P0–P3 และทางเดินพลังงาน/เหตุฉุกเฉิน
ระบุให้ชัดว่าส่วนไหนทำจริง จำลอง หรือวางแผนต่อยอด

ฟ

โฟล์ค · เซนเซอร์และวงจร

รับผิดชอบหลัก: จุดวัด หลักการต่อวงจร ความปลอดภัย และขอบเขตการวัด

ต้องส่ง

แผนภาพเซนเซอร์/วงจรและคำอธิบายว่าแต่ละตัววัดอะไร
ตาราง “วัดโดยตรง / อนุมาน / ยังวัดไม่ได้” พร้อมเหตุผล
ข้อจำกัดการต่อใช้งานจริง การป้องกันสัญญาณรบกวน และภาพต้นแบบที่ทำจริง
สถานะผลทดสอบจริง หรือระบุว่ายังไม่มีผลทดสอบ

พ

พี · ข้อมูล หน้าจอ กราฟ และแจ้งเตือน

รับผิดชอบหลัก: สิ่งที่ผู้ใช้เห็นและวิธีอ่านสถานะ

ต้องส่ง

ตัวอย่างหน้าจออย่างน้อยสถานะปกติ เฝ้าระวัง วิกฤต ออฟไลน์ และเซนเซอร์ผิดปกติ (ทำเท่าที่ต้นแบบรองรับ)
ตัวอย่างกราฟไฟตก/ดับ ช่วงใช้ไฟสำรอง และแนวโน้มความเค็ม/อุณหภูมิ
กติกาและข้อความแจ้งเตือนที่บอกเหตุ โหนด เวลา และสิ่งที่ควรทำ
ระบุว่าหน้าจอหรือกราฟใดเชื่อมข้อมูลจริง และอันใดเป็น mockup

บ

บอส · การส่งข้อมูลและสถานะโหนด

รับผิดชอบหลัก: รูปแบบข้อความ P1–P3 ไป P0 และความทนทานของการส่ง

ต้องส่ง

ตัวอย่างข้อความที่มี node_id, seq, timestamp, ค่าเซนเซอร์/ไฟฟ้า และสถานะที่จำเป็น
แผนรอบส่ง การส่งทันทีเมื่อเกิดเหตุ การตอบรับและส่งซ้ำ
กติกาเก็บข้อมูลชั่วคราวและส่งย้อนหลังเมื่อสื่อสารกลับมา (ถ้ามีในขอบเขตต้นแบบ)
นิยามสถานะโหนด และตัวอย่างแยก “ไฟดับ” ออกจาก “P0 ไม่ได้รับข้อมูล”

ข

ข้าวฟ่าง · เรียบเรียงและตรวจหลักฐาน

รับผิดชอบหลัก: ทำเรื่องเทคนิคให้อ่านเข้าใจ ตรวจผลจริง ข้อจำกัดและผลกระทบ

ต้องส่ง

คำอธิบายระบบภาษาง่ายและตรวจความต่อเนื่องระหว่างหน้าสไลด์
ตารางเกณฑ์ยืนยันผล: พิสูจน์แล้ว / สาธิตด้วยการจำลอง / ยังทำไม่ได้
รายการหลักฐาน ภาพ/กราฟจากเจ้าของงาน ข้อจำกัด ผลต่อชุมชนและคำถามที่ยังต้องตอบ
ตรวจข้อความสไลด์ให้ไม่กล่าวอ้างเกินการทดลองที่มี

ทีม

งานที่ต้องช่วยกันทำ

ทำหลังแต่ละคนส่งร่าง หรือทำคู่ขนานในส่วนที่ไม่ต้องรอระบบรวม

ต้องช่วยกัน

ยืนยันว่าโจทย์ปัญหาและผู้ได้รับผลมาจากข้อมูล/การคุยกับผู้ใช้ ไม่ใช่คาดเดาแทนชุมชน
เตรียมสถานการณ์สาธิต: ปกติ → ไฟตก/ดับ → ไฟสำรอง/จัดลำดับโหลด → แจ้งเตือน → ฟื้นระบบ (แยกสิ่งจำลองออก)
เอาภาพต้นแบบ หน้าจอ บันทึกเหตุการณ์และผลผ่าน/ไม่ผ่านมารวมกัน
ตรวจชื่อ P0–P3 คำศัพท์ ตัวเลข หน่วย และขอบเขตให้ตรงกันทุกหน้า

ชุดส่งเข้ากลาง (ทุกคนใช้รูปแบบเดียวกัน)

ชื่อส่วนและเจ้าของงาน · ร่างข้อความ/ภาพ · แหล่งข้อมูลหรือรูปถ่ายต้นฉบับ
สถานะ: ทำจริง / จำลอง / mockup / แนวคิดต่อยอด · ผลทดสอบพร้อมวันและเงื่อนไขถ้ามี
ข้อจำกัดและคำถามที่ยังไม่มีคำตอบ — อย่าเติมค่าหรือผลทดลองที่ยังไม่ได้วัด

PRESENTATION PDF · SUGGESTED 9 PAGES

โครงสไลด์ที่รวมงาน 12 หัวข้อให้เล่าเป็นเรื่อง

เอกสารทีมแจกหัวข้อไว้ละเอียด 12 ข้อ แผนนี้รวมส่วนที่ต่อเนื่องกันเพื่อให้อยู่ในช่วง 7–10 หน้า โดยยังครอบคลุมปัญหา บริบท วิธีเดิม ตัวแก้ปัญหา User Flow หลักฐาน ข้อจำกัด ผู้เกี่ยวข้อง และแผนทดลอง

หน้า	จังหวะเรื่อง	สิ่งที่ใส่ให้คนดูเข้าใจ	คนทำหลัก / ช่วยกัน	ชิ้นงานก่อนรวม
1	Executive Summary	ชื่อ Community Energy Resilience Platform, ปัญหาที่เลือกตอบ, คำตอบหนึ่งประโยค, สมาชิกและสถานะต้นแบบจริง	นาย / ข้าวฟ่างตรวจข้อความ	ข้อความสรุปไม่เกิน 3 ประโยคและภาพระบบ
2	ปัญหาและผู้ได้รับผลกระทบ	เหตุไฟตก/ดับในบริบทที่ศึกษา, ใคร/โหลดใดได้รับผล, หลักฐานและปี, สิ่งที่ยังต้องยืนยันกับผู้ใช้	นาย + ข้าวฟ่าง / ทุกคนส่งหลักฐาน	แผนที่หลักฐานและผลกระทบโดยไม่อ้างความชุกเกินข้อมูล
3	บริบทและวิธีเดิม	ก่อนเกิดเหตุ–ระหว่างเหตุ–หลังเหตุ ผู้ใช้รับรู้และจัดการอย่างไร; ระบุ workflow ปัจจุบันตามข้อมูลจริง	ข้าวฟ่างเรียบเรียง + นายวางเรื่อง / ทีมช่วยยืนยัน	แผนภาพ workflow เดิม หรือบอกช่องว่างข้อมูลหากยังไม่ได้สัมภาษณ์
4	แนวทางแก้และโครงสร้าง	ไฟฟ้าเป็นแกนหลัก; P0 เป็นศูนย์กลาง, P1 น้ำและไฟ, P2 โหลดจำเป็น, P3 โหลดทั่วไป; ความเค็ม/อุณหภูมิใช้เฝ้าระวังความเสี่ยงน้ำ	นาย / โฟล์ค บอส พี ให้ข้อมูล	Block diagram P0–P3 พร้อมลูกศรไฟฟ้า/ข้อมูล
5	User Flow + Mockup/Diagram	ไฟตก/ดับ → ตรวจข้อมูล → ใช้ไฟสำรองตามขอบเขตที่ทำ → รักษาโหลดสำคัญ → แจ้งเตือน → ฟื้นระบบ; แยกกรณีสื่อสารหาย	นาย + พี + บอส / ทั้งทีมตรวจคำอธิบาย	อย่างน้อย 1 ภาพ user flow, หน้าจอ หรือ prototype ที่อ่านได้
6	เซนเซอร์และการทำงาน	จุดวัด หลักการวงจร สิ่งที่วัดได้ตรง ๆ สิ่งที่อนุมาน และสิ่งที่ต้นแบบยังวัดไม่ได้	โฟล์ค / ข้าวฟ่างจัดคำให้อ่านง่าย	ภาพวงจร/เซนเซอร์พร้อมป้ายชื่อและขอบเขต
7	ข้อมูล หน้าจอ และแจ้งเตือน	ตัวอย่างข้อมูล, การส่ง P1–P3 ถึง P0, กราฟ/หน้าจอ, ความหมายของ online/offline และเหตุการณ์	พี + บอส / นายเชื่อมกับระบบ	ตัวอย่าง payload + หน้าจอ/กราฟ และกติกาแจ้งเตือน
8	PoC / ผลทดลอง / ข้อจำกัด	ภาพต้นแบบและผลที่วัดได้, สิ่งที่จำลอง, ผ่าน/ไม่ผ่าน, ข้อจำกัดแรงดันต่ำ; ยังไม่ควบคุมไฟบ้านจริง	เจ้าของการทดลองทุกคน / ข้าวฟ่างรวมเกณฑ์	ตาราง “ทำจริง–จำลอง–ยังไม่ได้ทำ” พร้อมหลักฐานลงวันที่
9	ผู้เกี่ยวข้อง, ESG, ทดลองและต่อยอด	ใครต้องร่วมทดลอง, วิธีเก็บ feedback, ความปลอดภัยและผลข้างเคียง, ตัวชี้วัด, แผนถัดไป; ระบุโซลาร์/แบตจริงเป็นอนาคตถ้ายังไม่ได้ทำ	ข้าวฟ่าง + นาย / ทุกคนช่วยตรวจความเป็นไปได้	แผนทดลองสั้น ๆ ผู้รับผิดชอบ ความเสี่ยงและตัวชี้วัด

ภาพที่ห้ามลืม: สไลด์ 5 ต้องมีอย่างน้อยหนึ่งภาพที่ทีมทำเอง เช่น User Flow, block diagram, mockup หรือภาพต้นแบบ พร้อม label และคำอธิบาย ไม่ใช้ภาพตกแต่งแทนหลักฐานระบบ

VIDEO WALKTHROUGH · DO AFTER SLIDES

แยกทีมวิดีโอ หลังเรื่องและภาพในสไลด์ลงตัว

อย่าเริ่มอัดวิดีโอก่อนรู้ว่าทีมพิสูจน์อะไรได้แล้ว เมื่อสไลด์พร้อม ให้เลือกคน Pitch ที่เล่าเป็นธรรมชาติหนึ่งคน แล้วมีคนอีกคนคุมภาพ/เสียงและช่วยเช็กข้อเท็จจริง

คนทำวิดีโอต้องส่งอะไร

ไฟล์ Video Walkthrough ความยาว 1–3 นาที ขนาดไม่เกิน 100 MB — ตรวจซ้ำกับแบบฟอร์มล่าสุดก่อนส่ง
ถ่ายทำจริงและอธิบายประกอบสไลด์/ต้นแบบ ห้ามใช้ AI สร้างวิดีโอตามข้อกำหนดที่ผู้ใช้ให้มา
เล่าแบบ storytelling ไม่อ่านสไลด์ทีละบรรทัด: สถานการณ์ → ผลกระทบ → ทำไมวิธีเดิมยังมีช่องว่าง → ทีมสร้าง/ทดลองอะไร → หลักฐานและข้อจำกัด → ขั้นต่อไป
ถ้ามีภาพจำลองหรือ mockup ให้พูดกำกับตรง ๆ; อย่าตัดต่อจนคนดูเข้าใจว่าเป็นการใช้งานจริง

0:00–0:25 · เปิดเรื่องเหตุการณ์และผู้ได้รับผล

0:25–0:55 · ปัญหาวิธีเดิมและช่องว่าง

0:55–1:45 · วิธีแก้ภาพระบบ/เดโมจริง

1:45–2:30 · หลักฐานผลจริง ข้อจำกัด ขั้นถัดไป

เลือกคน Pitch เมื่อสไลด์เสร็จ: ให้คนที่อธิบายเข้าใจง่ายและตอบคำถามจากหลักฐานได้เป็นผู้เล่า ไม่จำเป็นต้องเป็นเจ้าของทุกชิ้นงาน; เจ้าของเทคนิคช่วยตรวจบทและร่วมถ่ายเดโมได้ คนถ่าย/ตัดต่อเป็นบทบาทแยกได้ แต่ทุกคำกล่าวต้องได้รับการยืนยันจากเจ้าของข้อมูล

0 / 10 ข้อ

SOURCE & NEXT STEP

ไฟล์ต้นทางและเครื่องมือที่เกี่ยวข้อง

รายละเอียดบทบาท P0–P3, ผู้รับผิดชอบทั้งห้าคน และรายการร่างสไลด์มาจากไฟล์สรุปงานที่ทีมแนบไว้ หน้านี้จัดรูปใหม่เป็นแผนปฏิบัติงานและตัวอย่างสไลด์ 9 หน้า โดยไม่เปลี่ยนสถานะความพร้อมของผลงาน ใช้แบบฟอร์มโครงการฉบับล่าสุดยืนยันข้อกำหนดก่อนส่งจริง

เปิดเครื่องมือทำ Case →เปิดเกณฑ์กลาง →อ่าน PDF สรุปงานฉบับเต็ม ↗ดาวน์โหลด PDF

ผังต้นแบบล่าสุด · 15 ตุลาคม 2569

ทำสไลด์ให้เสร็จ แล้วค่อยเล่าเรื่องเป็นวิดีโอ

พจนานุกรมศัพท์กลางของทีม

Case เคส / กรอบปัญหาโครงการ

Challenge โจทย์หรือธีมของโครงการ

Stakeholder ผู้เกี่ยวข้อง

Workflow ลำดับงานที่คนทำจริง

Unmet need ความต้องการที่วิธีปัจจุบันยังตอบไม่ได้

Value proposition คุณค่าที่คำตอบมอบให้

ESG สิ่งแวดล้อม · สังคม · ธรรมาภิบาล

PoC Proof of Concept · ทดลองพิสูจน์แนวคิด

Prototype / Pilot / Mockup สามสถานะคนละอย่าง

Baseline / Metric / KPI ค่าตั้งต้นและตัวชี้วัด

Measured vs Inferred วัดตรง เทียบกับอนุมาน/คำนวณ

Node โหนด / จุดอุปกรณ์

Telemetry ข้อมูลวัด/สถานะที่ส่งจากอุปกรณ์

Payload / Schema เนื้อหาและรูปแบบข้อความ

Timestamp / Sequence เวลาและลำดับข้อมูล

last_seen / Online / Offline ได้รับข้อมูลล่าสุดเมื่อไร

Threshold ค่า/เงื่อนไขที่ทำให้เปลี่ยนสถานะหรือแจ้งเตือน

ACK / Retry / Store-and-forward ตอบรับ · ส่งซ้ำ · เก็บรอส่ง

Voltage แรงดันไฟฟ้า · V

Current กระแสไฟฟ้า · A

Power กำลังไฟฟ้า · W

Energy พลังงาน · Wh

Load โหลด / อุปกรณ์ที่กินกำลังไฟ

Sensor vs Actuator ตัววัด เทียบกับตัวสั่งงาน

Calibration / Accuracy / Range สอบเทียบ · ความคลาดเคลื่อน · ช่วงวัด

Salinity vs DO ความเค็มไม่ใช่ออกซิเจนละลายน้ำ

Low voltage / Isolation / Fail-safe ขอบเขตแรงดันและการทำงานเมื่อขัดข้อง

ไฟดับ / ไฟตก / โหนด Offline สามเหตุการณ์คนละแบบ

ลำดับทำงานที่ลดการรอกัน

ช่วงพรีเซนต์ปัญหา

ช่วงพรีเซนต์ตัวแก้ปัญหา

อะไรปักแล้ว อะไรต้องหาเพิ่ม และทำไปเพื่ออะไร

1 · ปัญหาเกิดกับใครและเกิดเมื่อไร

2 · วิธีเดิมและ workflow หน้างาน

3 · สถาปัตยกรรม P0–P3

4 · ไฟฟ้าเป็นแกนหลัก; น้ำเป็นข้อมูลเฝ้าระวัง

5 · ขอบเขตแรงดันต่ำและไม่ควบคุมไฟบ้าน

6 · จัดลำดับโหลดและสำรองพลังงาน

7 · สถานะออนไลน์ การส่งซ้ำ และข้อมูลหาย

8 · Alarm threshold และคนรับแจ้ง

9 · รูปแบบสไลด์ 9 หน้า

10 · ทำวิดีโอหลังสไลด์และเลือก Pitcher

11 · PoC และระดับความพร้อม

12 · คนดูแล ต้นทุน ความยินยอม และทางซ่อม

แบ่งงานรายคน พร้อมของที่ต้องส่ง

นาย · เจ้าของเรื่องและภาพรวมระบบ

ต้องส่ง

โฟล์ค · เซนเซอร์และวงจร

ต้องส่ง

พี · ข้อมูล หน้าจอ กราฟ และแจ้งเตือน

ต้องส่ง

บอส · การส่งข้อมูลและสถานะโหนด

ต้องส่ง

ข้าวฟ่าง · เรียบเรียงและตรวจหลักฐาน

ต้องส่ง

งานที่ต้องช่วยกันทำ

ต้องช่วยกัน

ชุดส่งเข้ากลาง (ทุกคนใช้รูปแบบเดียวกัน)

โครงสไลด์ที่รวมงาน 12 หัวข้อให้เล่าเป็นเรื่อง

แยกทีมวิดีโอ หลังเรื่องและภาพในสไลด์ลงตัว

คนทำวิดีโอต้องส่งอะไร

เช็กความพร้อมก่อนซ้อม Pitch

ไฟล์ต้นทางและเครื่องมือที่เกี่ยวข้อง