บทสรุปสำหรับทีมเดโม
ระบบสำหรับโฟร์แมนไม่ควรถูกออกแบบเหมือน dashboard สำหรับออฟฟิศ แต่ควรเป็นเครื่องมือหน้างานที่ช่วยตอบคำถามเร็ว ๆ ว่า “วันนี้มีใครมา”, “ใครควรไปจุดไหน”, “คนนี้เข้าไซต์หรือออกไซต์แล้วหรือยัง” และ “งานสำคัญขาดคนไหม”
ความสำเร็จของเดโมจึงไม่ใช่จำนวนฟีเจอร์ แต่คือการพิสูจน์ว่าโฟร์แมนสามารถจบงานหลักได้ในไม่กี่จังหวะ แม้ถือโทรศัพท์กลางแดด ใส่ถุงมือ มีเสียงเครื่องจักร และไม่มีเวลานั่งอ่านหน้าจอยาว ๆ
ปุ่มใหญ่
ภาษาไทยหน้างาน
แก้พลาดง่าย
ทำงานได้เมื่อเน็ตไม่นิ่ง
เน้นรายชื่อวันนี้
1. Persona
Persona หลัก: “พี่สมชาย” โฟร์แมนไซต์
- อายุ: 48-58 ปี มีประสบการณ์หน้างานสูง แต่ไม่อยากเรียนระบบใหม่ยาว ๆ
- อุปกรณ์: โทรศัพท์ Android หน้าจอกลาง ๆ อาจมีรอย ฝุ่น แสงสะท้อน และแบตจำกัด
- สายตา: เริ่มอ่านตัวเล็กยาก ต้องยืดมือถือออกหรือถอดแว่นอ่านหนังสือ
- สภาพแวดล้อม: แดดแรง ฝุ่น เหงื่อ เสียงรถ เสียงเครื่องจักร ต้องคุยวิทยุหรือโทรศัพท์ตลอด
- ทัศนคติ: ยอมใช้ระบบถ้าช่วยลดงานจด ลดการโทรซ้ำ และไม่ทำให้เสียหน้าเวลาหน้าจอซับซ้อน
Persona รองที่เกี่ยวข้อง
- ผู้จัดการไซต์: ต้องการเห็นภาพรวมกำลังคน ความคืบหน้า และความเสี่ยงขาดคน
- ธุรการ/HR ไซต์: ต้องการข้อมูลเวลาเข้า-ออกที่เชื่อถือได้ ลดการรวม Excel ตอนเย็น
- หัวหน้าชุด/ช่างหลัก: ต้องรู้ว่าลูกทีมถูกส่งไปจุดไหนและใครยังไม่มาถึง
- รปภ. หรือจุดประตู: อาจช่วยบันทึกเข้า-ออก แต่ไม่ควรต้องเข้าใจแผนงานละเอียด
หลัก BA: โฟร์แมนคือผู้ตัดสินใจหน้างาน ไม่ใช่ data-entry clerk ระบบต้องช่วยเขาตัดสินใจและบันทึกผลในขั้นตอนเดียว
2. Jobs-to-be-Done
1รู้จำนวนคนที่มาจริงวันนี้
2จับคนให้ตรงงานและโซน
3แก้เมื่อคนขาดหรือย้ายงาน
4ยืนยันเข้า-ออกไซต์แบบเร็ว
5ส่งสรุปให้ผู้จัดการ/ธุรการ
JTBD เชิงหน้าที่
- เมื่อตอนเช้าเริ่มงาน ต้องเห็นทันทีว่าแรงงานครบหรือขาด เพื่อไม่ให้แผนงานช้า
- เมื่อมีงานหลายโซน ต้องจัดคนตามทักษะ เช่น ปูน ไฟฟ้า เหล็ก แบบ สี ทำความสะอาด หรือขับเครื่องจักร
- เมื่อมีคนไม่มา ต้องหาคนทดแทนโดยดูคนว่างและทักษะใกล้เคียง
- เมื่อคนเข้า/ออกไซต์ ต้องบันทึกเร็วเพื่อความปลอดภัย ค่าแรง และรายงานประจำวัน
JTBD เชิงอารมณ์และสังคม
- อยากมั่นใจว่าไม่ได้ลืมคนหรือส่งคนผิดจุด
- อยากอธิบายกับผู้จัดการได้ด้วยข้อมูล ไม่ใช่ความจำหรือกระดาษหลายแผ่น
- ไม่อยากถูกมองว่าใช้ระบบไม่เป็นเพราะปุ่มเล็กหรือขั้นตอนเยอะ
- ต้องการระบบที่ไม่ทำให้เสียจังหวะการสั่งงานลูกน้องหน้างาน
3. Pain Points
| ปัญหา | ผลกระทบทางธุรกิจ | ผลต่อการออกแบบเดโม |
|---|---|---|
| อ่านยากกลางแดด ตัวหนังสือเล็ก สีอ่อน และหน้าจอแน่น | กรอกผิด กดผิด ใช้เวลานาน หรือเลิกใช้ระบบ | ใช้ตัวอักษรใหญ่ คอนทราสต์สูง ปุ่มอย่างน้อย 56px และหน้าจอหนึ่งงานต่อหนึ่งเป้าหมาย |
| เสียงดัง ไม่เหมาะกับคำสั่งเสียงหรือแจ้งเตือนเสียงอย่างเดียว | พลาดแจ้งเตือนเรื่องคนขาดหรือออกไซต์ไม่ครบ | ใช้สี สถานะ ไอคอน และข้อความสั้น ๆ แทนการพึ่งเสียง |
| ระบบซับซ้อนเกิน เช่น ต้องเลือกโปรเจกต์ โซน วันที่ กะ ทีม หลายชั้น | โฟร์แมนกลับไปใช้ LINE โทรศัพท์ หรือกระดาษ | ตั้งค่า default เป็น “วันนี้ / ไซต์นี้ / ทีมของฉัน” และให้แก้เฉพาะเมื่อจำเป็น |
| แรงงานมีชื่อเล่น ชื่อซ้ำ แรงงานต่างด้าว หรือทักษะไม่เป็นทางการ | จัดคนผิดคน นับคนซ้ำ หรือประเมินกำลังผิด | แสดงชื่อเล่น รูป/สีทีม ทักษะหลัก และสถานะล่าสุดในบัตรเดียว |
| เน็ตไซต์ไม่เสถียรและงานเข้า-ออกเกิดเร็วช่วงต้น/ท้ายวัน | ข้อมูลหายหรือย้อนแก้ยากเมื่อจุดประตูคนแน่น | รองรับสถานะ pending/synced และมีปุ่มแก้ย้อนหลังพร้อมเหตุผล |
| การแก้พลาดมีความอ่อนไหวต่อค่าแรงและความปลอดภัย | เกิดข้อโต้แย้งค่าแรงหรือรายงานคนค้างไซต์ไม่ถูกต้อง | มี audit note สั้น ๆ เช่น “แก้โดยใคร เวลาใด เหตุผลอะไร” |
4. Business Goals
ลดเวลาประสานงาน
ลดการโทรถามซ้ำว่าใครมาแล้ว ใครอยู่โซนไหน และใครยังไม่ออกไซต์
เพิ่มความแม่นยำค่าแรง
ทำให้ข้อมูลเข้า-ออกและการมอบหมายงานตรงกับเหตุการณ์จริงมากขึ้น
ลดความเสี่ยงหน้างาน
เห็นคนค้างไซต์ คนอยู่ผิดโซน หรือโซนอันตรายที่มีคนไม่ครบได้เร็ว
รักษาความต่อเนื่องงาน
ช่วยโยกคนเมื่อมีการขาดงานหรือเปลี่ยนแผน เพื่อไม่ให้ critical path หยุด
สร้างข้อมูลสำหรับผู้บริหาร
มี daily manpower summary สำหรับดูต้นทุน กำลังคน และ productivity เบื้องต้น
เพิ่ม adoption
ทำให้โฟร์แมนรู้สึกว่าระบบช่วยงานจริง ไม่ใช่งานเอกสารเพิ่ม
5. Operational Constraints
ข้อจำกัดหน้างาน
- ช่วงเช้าและเย็นมี peak load สูง ต้องเช็กหลายคนในเวลาสั้น
- แสงแดด ฝุ่น ฝน เหงื่อ และถุงมือทำให้การกดละเอียดทำได้ยาก
- เสียงดังทำให้ voice-only หรือ alert เสียงอย่างเดียวไม่พอ
- สัญญาณอินเทอร์เน็ตบางไซต์ไม่เสถียร ต้องมีสถานะรอซิงก์
- ข้อมูลคนงานอาจไม่สมบูรณ์ เช่น ทักษะไม่ถูกบันทึกหรือเปลี่ยนทีมบ่อย
ข้อจำกัดธุรกิจและระบบ
- ต้องแยกข้อมูลสำหรับสาธิตออกจากข้อมูลจริง เพื่อไม่กระทบความเป็นส่วนตัว
- ต้องมีสิทธิ์การแก้ไข เพราะข้อมูลเวลาเข้า-ออกเกี่ยวข้องกับค่าแรง
- ระบบควรเปิดบนมือถือได้เร็ว ไม่บังคับติดตั้งแอปในช่วงเดโม
- คำศัพท์ต้องใกล้ภาษาหน้างาน เช่น “เข้าพื้นที่”, “เลิกงาน”, “ย้ายโซน” มากกว่า HR jargon
- ข้อมูล demo ต้องมีเคสผิดปกติให้เห็นคุณค่า เช่น คนขาด งานขาดคน และคนยังไม่ออก
6. Success Metrics
≤ 3 แตะเช็กคนเข้าไซต์จากหน้ารายชื่อวันนี้
≤ 30 วินาทีจัดคน 1 คนลงงานหรือย้ายโซน
≥ 90%รายการเข้า-ออกมีสถานะครบภายในวันเดียวกัน
≤ 5 นาทีโฟร์แมนใหม่เข้าใจ flow เดโมโดยไม่ต้องอบรมยาว
ลด 50%การโทรถามสถานะคนงานระหว่างโฟร์แมนกับธุรการใน scenario เดโม
0 blockerสำหรับการใช้งานบนมือถือจอเล็กกลางแจ้งใน flow หลัก
ตัวชี้วัดเดโมควรเน้น usability และ operational clarity มากกว่าการคำนวณ productivity ขั้นสูง เพราะเป้าหมายแรกคือพิสูจน์ว่าโฟร์แมนยอมใช้และใช้ได้จริง
7. MVP Scope
ต้องมีใน MVP
- หน้า “วันนี้” แสดงจำนวนคนเข้าไซต์แล้ว ขาดงาน อยู่ระหว่างงาน และยังไม่ออกไซต์
- รายชื่อคนงานแบบบัตรใหญ่ มีชื่อเล่น รูป/initial ทีม ทักษะหลัก สถานะ และปุ่ม action เด่น
- การกด Site-in และ Site-out ที่จบได้เร็ว พร้อมเวลาอัตโนมัติ
- การ assign คนลงโซน/งานจากรายการงานที่เตรียมไว้
- การย้ายคนระหว่างงานพร้อมเหตุผลสั้น เช่น “งานด่วน”, “คนขาด”, “เสร็จแล้ว”
- สถานะงานขาดคนและคนว่างที่เห็นได้ทันที
- สรุปรายวันสำหรับผู้จัดการหรือธุรการ export/แสดงเป็น demo summary
ขอบเขตข้อมูลเดโม
- ไซต์ตัวอย่าง 1-2 ไซต์ เช่น กรุงเทพฯ และปริมณฑล
- โซนงาน 4-6 โซน เช่น โครงสร้าง, ระบบไฟ, ปูน, เก็บงาน, ประตูไซต์, ความปลอดภัย
- คนงานตัวอย่าง 25-40 คน พร้อมทักษะ สถานะ และเคสผิดปกติ
- กะงานพื้นฐาน 1 กะต่อวัน ไม่ต้องรองรับ payroll เต็มรูปแบบ
- ข้อมูลจำลองที่สะท้อนบริบทไทย เช่น ชื่อเล่น ทักษะหน้างาน และตำแหน่งงานจริง
8. Out-of-Scope
ยังไม่ควรทำในเดโมแรก
- Payroll เต็มรูปแบบ ภาษี ประกันสังคม และการอนุมัติเงินเดือนหลายชั้น
- Biometric, face recognition หรือ hardware gate integration จริง
- ระบบวางแผนโครงการละเอียดระดับ Gantt chart หรือ BIM integration
- ระบบประเมินผลงานรายคนแบบละเอียด เพราะอาจทำให้ผู้ใช้กังวลเรื่องการถูกจับผิด
- AI optimization ซับซ้อนที่อธิบายไม่ได้ว่าแนะนำคนนี้เพราะอะไร
เหตุผลที่ตัดออก
- ลดความเสี่ยงด้านข้อมูลส่วนบุคคลและแรงงานสัมพันธ์
- รักษาเดโมให้เล่าได้ชัดใน 5-10 นาที
- โฟกัส pain point ที่โฟร์แมนเจอทุกวันก่อน
- หลีกเลี่ยง dependency กับอุปกรณ์หน้างานที่อาจไม่พร้อม
- เปิดทางให้ขยายเป็นระบบจริงหลังยืนยัน adoption
9. Risks
| Risk | ระดับ | Mitigation สำหรับเดโม |
|---|---|---|
| ผู้ใช้รู้สึกว่าระบบเป็นภาระเพิ่ม ไม่ใช่ตัวช่วย | สูง | เริ่มด้วย flow เช้า “เช็กคนครบไหม” ที่ให้ประโยชน์ทันที ไม่เริ่มจาก master data |
| UI ไม่เหมาะกับสายตายาวและกลางแจ้ง | สูง | กำหนด design rule: font ใหญ่, contrast สูง, ปุ่มใหญ่, ระยะห่างเยอะ, ไม่มีตารางแน่นบนมือถือ |
| ข้อมูลเข้า-ออกถูกใช้ตีความค่าแรงผิด | กลาง-สูง | แสดงว่าเป็น operational log และมี edit reason/audit trail ก่อนเชื่อม payroll |
| การ assign ตามทักษะไม่ตรงกับความจริง เพราะทักษะหน้างานยืดหยุ่น | กลาง | ให้ทักษะเป็นตัวช่วยกรอง ไม่ใช่กฎล็อก และให้โฟร์แมน override ได้ |
| ข้อมูลส่วนบุคคลแรงงานและแรงงานต่างด้าวอ่อนไหว | กลาง | ใช้ข้อมูลจำลอง ลดข้อมูลส่วนตัว และไม่แสดงเลขเอกสารในหน้าหลัก |
| ระบบสวยแต่ไม่สะท้อนความวุ่นวายจริงของไซต์ | กลาง | ใส่ scenario คนขาด, ย้ายโซน, คนยังไม่ออก, งานด่วน และสถานะรอซิงก์ |
10. Assumptions
Assumptions ด้านผู้ใช้
- โฟร์แมนคุ้นกับ LINE/โทรศัพท์ แต่ไม่ชอบระบบที่ต้องกรอกหลายช่อง
- ผู้ใช้หลายคนมีภาวะอ่านใกล้ยากตามวัย จึงต้องออกแบบเผื่อ presbyopia ตั้งแต่ต้น
- โฟร์แมนจำคนจากชื่อเล่น หน้า ทีม และทักษะมากกว่ารหัสพนักงาน
- การใช้งานส่วนใหญ่เกิดบนมือถือ ไม่ใช่ desktop
Assumptions ด้านธุรกิจ
- บริษัทต้องการลดความสูญเสียจากคนขาด งานรอคน และการสื่อสารซ้ำ
- ข้อมูลเดโมยังไม่ต้องเชื่อม payroll จริง แต่ต้องแสดงทิศทางการนำไปใช้ได้
- ไซต์ก่อสร้างไทยมีแรงงานหมุนเวียนและมีทั้งแรงงานไทย/ต่างชาติ จึงต้องทำ label ให้เข้าใจง่าย
- ผู้จัดการต้องการ summary มากกว่า real-time map ที่ซับซ้อนใน MVP
11. Prioritized Requirements
| Priority | Requirement | Acceptance Criteria สำหรับเดโม | Business Value |
|---|---|---|---|
| P0 | หน้ากระดาน “วันนี้” สำหรับโฟร์แมน | เห็นจำนวนคนมาแล้ว, ขาด, กำลังทำงาน, ว่าง, ยังไม่ออกไซต์ โดยไม่ต้องเลือก filter ก่อน | ให้ภาพรวมกำลังคนทันที ลดการโทรเช็กสถานะ |
| P0 | Site-in / Site-out แบบกดเร็ว | บัตรคนงานมีปุ่มเข้าไซต์/ออกไซต์ชัดเจน กดแล้วสถานะเปลี่ยนพร้อมเวลาและสามารถ undo ได้ช่วงสั้น | ลดความผิดพลาดเวลาเข้า-ออกและเพิ่มความปลอดภัย |
| P0 | Assign คนลงงาน/โซน | เลือกคน เลือกงานจากรายการสั้น กดยืนยัน แล้วเห็นจำนวนคนของโซนอัปเดตทันที | ช่วยจัดกำลังให้ตรงงานและเห็นงานที่ขาดคน |
| P0 | UI สำหรับสายตายาวและกลางแจ้ง | font หลักไม่เล็กกว่า 18px, action button สูงอย่างน้อย 56px, contrast สูง, ใช้ข้อความสั้นและสถานะสีชัด | เพิ่ม adoption และลดการกดผิด |
| P1 | ตัวช่วยหาคนว่างหรือคนทดแทน | เมื่อโซนขาดคน ระบบแสดงคนว่างที่มีทักษะใกล้เคียง 3-5 คน พร้อมเหตุผลสั้น | ลดเวลาตัดสินใจเมื่อเกิดเหตุขาดคน |
| P1 | แก้ไขย้อนหลังพร้อมเหตุผล | โฟร์แมนแก้เวลา/สถานะได้โดยเลือกเหตุผลสั้น และรายการแสดงว่าแก้ไขแล้ว | ลดข้อโต้แย้งและเพิ่มความน่าเชื่อถือของข้อมูล |
| P1 | สถานะรอซิงก์เมื่อเน็ตไม่เสถียร | รายการที่ทำแล้วแต่ยังไม่ซิงก์แสดงป้าย “รอส่งข้อมูล” และไม่หายจากหน้าจอ | สร้างความมั่นใจว่าใช้งานในไซต์จริงได้ |
| P1 | Daily summary สำหรับผู้จัดการ/ธุรการ | แสดง summary คนเข้าไซต์, ชั่วโมงโดยประมาณ, งานขาดคน, เหตุการณ์แก้ไข และคนยังไม่ออก | ทำให้ข้อมูลหน้างานส่งต่อได้โดยไม่ต้องรวมมือ |
| P2 | ค้นหาด้วยชื่อเล่น/ทีม/ทักษะ | ค้นหา “ช่างไฟ”, “ทีม A”, หรือชื่อเล่นแล้วเจอคนที่เกี่ยวข้อง | ช่วยไซต์ที่มีคนจำนวนมากและชื่อซ้ำ |
| P2 | Safety flag เบื้องต้น | งานเสี่ยงสูงแสดงป้ายเตือน และคนที่ไม่มี skill/permit ที่จำลองไว้ถูกเตือนก่อน assign | แสดงทิศทางต่อยอดด้านความปลอดภัยโดยไม่ทำให้ MVP หนักเกิน |
Demo Planning Notes
Scenario ที่ควรเล่า
- เช้าวันนี้มีคนเข้าไซต์ 31 จาก 36 คน และงานโครงสร้างขาด 2 คน
- โฟร์แมนกดดูคนว่าง ระบบแนะนำคนที่มีทักษะใกล้เคียง
- โฟร์แมนย้ายคนจากงานเก็บพื้นที่ไปช่วยงานโครงสร้าง พร้อมเหตุผล “งานด่วน”
- ตอนเย็นระบบเตือนว่ายังมี 3 คนไม่ออกไซต์ และสรุปส่งผู้จัดการได้
Design guardrails
- อย่าใช้ตารางแน่นเป็นหน้าหลักบนมือถือ ให้ใช้บัตรและแถบสถานะ
- อย่าซ่อน action หลักในเมนูจุดสามจุด
- อย่าใช้สีอย่างเดียว ต้องมีคำกำกับ เช่น “เข้าแล้ว”, “ยังไม่ออก”
- อย่าบังคับกรอกเหตุผลยาว ใช้ preset และเพิ่ม note ได้ถ้าจำเป็น
- อย่าให้ AI ตัดสินใจแทนโฟร์แมน ให้เป็นคำแนะนำที่ override ได้
ข้อมูลประกอบการวิเคราะห์
ใช้ข้อมูลเหล่านี้เป็นกรอบประกอบ ไม่ใช่ข้อสรุปแทน user research หน้างานจริง ทีมควร validate กับโฟร์แมนไทย 3-5 คนก่อนล็อก scope
- National Statistical Office Thailand: Statistical Yearbook Thailand 2024 สำหรับบริบทแรงงานและข้อมูลสถิติระดับประเทศ
- World Bank: Aging and the Labor Market in Thailand สำหรับบริบทแรงงานสูงวัยในไทย
- National Eye Institute: Presbyopia สำหรับผลกระทบการอ่านใกล้ในวัยกลางคนและผู้สูงอายุ
- W3C WCAG 2.2 สำหรับกรอบคิดเรื่อง contrast, target size และ accessibility ขั้นพื้นฐาน