สร้างแอพมือถือสำหรับการสลับกะและการระบุความพร้อม

ระบุปัญหาและตัวชี้วัดความสำเร็จ

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

ใครได้ประโยชน์ (และพวกเขาต้องการอะไร)

พนักงานต้องการแอพความพร้อมพนักงานที่ทำให้ตั้งความพร้อม ขอวันหยุด และแลกกะได้ง่ายโดยไม่ต้องตามผู้จัดการ

หัวหน้าเวรต้องการความคุ้มครองรวดเร็ว โดยมีการติดต่อกลับน้อยลง

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

ฝ่าย HR/เงินเดือนต้องการบันทึกที่สะอาดและตรงกับการติดตามเวลาและการจ่ายเงิน

ถ้าคุณไม่จัดให้กลุ่มเหล่านี้สอดคล้องกันตั้งแต่ต้น คุณอาจสร้างแอพจัดตารางที่ “ง่าย” สำหรับบทบาทหนึ่งแต่เจ็บปวดสำหรับบทบาทอื่น

ผลลัพธ์ที่ควรตั้งเป้า

กำหนดผลลัพธ์ที่เชื่อมต่อกับต้นทุน เวลา และความเป็นธรรม:

• ลดข้อความ/สายที่ต้องใช้เพื่อเติมกะ (วัดเป็นรายสัปดาห์)
• เติมกะว่างได้ไวขึ้น (เวลาจากโพสต์ → ยอมรับ)
• อนุมัติเร็วขึ้น (เวลาจากคำขอ → อนุมัติ/ปฏิเสธ)
• ปฏิบัติตามปฏิทินและกฎความพร้อมชัดเจนขึ้น (เปอร์เซ็นต์ของการสลับที่ตรงกับกฎการลาและความพร้อม)

ตัดสินเกณฑ์ความสำเร็จก่อนสร้าง

เลือกชุดตัวชี้วัดเล็ก ๆ สำหรับ MVP การจัดตารางของคุณแล้ววัดค่าเริ่มต้นตอนนี้ ตัวอย่าง: ปรับปรุงอัตราการเติมกะว่างขึ้น 20%, ลดเวลาอนุมัติจาก 6 ชั่วโมงเป็น 1 ชั่วโมง, หรือลดเหตุการณ์ "กะไม่ถูกเติม" ลง 30%

เป้าหมายเหล่านี้จะชี้การตัดสินใจผลิตภัณฑ์ ช่วยจัดลำดับความสำคัญฟีเจอร์ เช่น การแจ้งเตือนกะ และทำให้ชัดเจนว่าการปรับใช้ได้ผลหรือไม่

เลือกกรณีใช้งานและกฎที่ต้องรองรับ

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

เลือกผู้ใช้หลัก (และอย่าเอามาผสมกันเร็วเกินไป)

เริ่มจากผู้ชมชัดเจนหนึ่งกลุ่ม:

• พนักงานรายชั่วโมงในค้าปลีก: พนักงานพาร์ทไทม์จำนวนมาก การเปลี่ยนแปลงนาทีสุดท้ายบ่อย ทักษะเรียบง่าย
• ร้านอาหาร: การจัดคนตามบทบาท (เซิร์ฟเวอร์/บาร์เทนเดอร์/เชฟหน้าเตา), ผลกระทบต่อทิป, การอนุมัติเร็ว
• การดูแลสุขภาพ: ใบรับรองเข้มงวด กฎอาวุโส ข้อจำกัดชั่วโมงล่วงเวลา
• โลจิสติกส์: ข้อกำหนดการครอบคลุม กฎความปลอดภัย และช่วงพักที่บังคับ

การตัดสินใจนี้มีผลต่อทุกสิ่งในแอพความพร้อมพนักงาน: ข้อมูลที่เก็บ การอนุมัติที่ต้องการ และความยืดหยุ่นของเวิร์กโฟลว์

กำหนดวิธีการสร้างกะ

โมเดลการจัดตารางของคุณมักเป็นหนึ่งในสองแบบ:

• เทมเพลตคงที่ (รูปแบบซ้ำ): ตรวจสอบการสลับได้ง่ายขึ้น คาดเดาได้มากขึ้น
• ตารางสัปดาห์/วัน (สร้างโดยผู้จัดการ): ตัวแปรมากกว่า เคสขอบมากกว่า

นอกจากนี้ให้กำหนดคุณสมบัติกะที่สำคัญสำหรับการแลก (สถานที่ บทบาท รหัสเงินเดือน เวลาเริ่ม/จบ)

ตัดสินสไตล์การอนุมัติการสลับ

ระบุอย่างชัดเจนว่าใครมีอำนาจสุดท้าย:

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

จดข้อจำกัดที่ต้องรองรับ

เขียนกฎเหล่านี้ตั้งแต่ตอนนี้ อย่าไปหลังเปิดใช้งาน:

• กฎสหภาพหรือตามสัญญา (อาวุโส ระบบประมูล ค่าตอบแทนพิเศษ)
• ใบรับรอง/ทักษะ (RN vs CNA, ใบขับรถยก)
• เวลาพักขั้นต่ำ ระหว่างกะ
• ชั่วโมงล่วงเวลาและชั่วโมงสูงสุด

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

บทบาทผู้ใช้และสิทธิ์

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

บทบาทหลักที่ควรรองรับ

พนักงาน

พนักงานต้องการเครื่องมือบริการตนเองพร้อมการป้องกัน: ตั้งความพร้อม (และการขอวันหยุด), ขอแลกกะ, รับ/ปฏิเสธข้อเสนอการสลับ, และดูตารางงานของตน ควรเห็นเฉพาะรายละเอียดที่เกี่ยวกับสถานที่/ทีมของตนและไม่สามารถแก้ไขกะที่เผยแพร่โดยตรง

ผู้จัดการ

ผู้จัดการอนุมัติหรือปฏิเสธการสลับ แก้ไขข้อขัดแย้ง (ล่วงเวลา ความต้องการทักษะ ภาวะขาดแคลน) สร้างและแก้ไขกะ และตรวจสอบความคุ้มครอง ในธุรกิจส่วนใหญ่ ผู้จัดการยังต้องเห็นคำเตือนกฎ (เช่น "จะเกินชั่วโมงต่อสัปดาห์") และประวัติชัดเจนว่าใครขอและอนุมัติการเปลี่ยนแปลง

แอดมิน

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

บทบาทเสริมที่ลด摩擦

หัวหน้าเวร อนุมัติการสลับในขอบเขตจำกัด (เช่น บทบาทเดียวกัน ภายในวันเดียว) โดยไม่ต้องสิทธิ์ผู้จัดการเต็มรูปแบบ

ผู้จัดตาราง สร้างตารางข้ามหลายทีม แต่ไม่สามารถเข้าถึงการตั้งค่าการจ่ายเงิน

ผู้ดู HR/เงินเดือน อ่านตารางและประวัติการเปลี่ยนแปลงได้โดยไม่สามารถแก้ไขกะ

เคล็ดลับการออกแบบสิทธิ์

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

ความพร้อม: ข้อมูลที่ต้องการและวิธีเก็บ

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

ประเภทความพร้อมที่ควรรองรับ

ทีมส่วนใหญ่ต้องการข้อมูลความพร้อมสามชั้น:

• ความพร้อมตามสัปดาห์ซ้ำ ๆ (เช่น "จันทร์–ศุกร์ 9:00–15:00")
• ข้อยกเว้นครั้งเดียว (เช่น "วันอังคารหน้าทำงานได้แค่ก่อนบ่าย 1")
• คำขอวันหยุด (เต็มวันหรือบางส่วน ควรมีสถานะการอนุมัติ)

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

ความชอบเทียบกับข้อจำกัดที่บังคับ

แยกให้ชัดทั้งใน UI และข้อมูล:

• ไม่พร้อม (ข้อจำกัดบังคับ): พนักงานไม่สามารถถูกกำหนดให้ทำงานในช่วงนี้
• พร้อม (กลาง ๆ): สามารถทำงานได้
• ต้องการ (ความชอบ): อยากทำช่วงนี้แต่ไม่บังคับ

สิ่งนี้สำคัญเมื่อระบบการจัดตารางหรือการตรวจสอบการอนุมัติการสลับตัดสินว่าการสลับ "อนุญาต" (กฎบังคับ) หรือแค่ "แนะนำ" (ความชอบ)

กฎการตรวจสอบที่ป้องกันการสลับแย่ ๆ

แม้ในขั้น MVP ให้เพิ่มเกราะป้องกันเพื่อไม่ให้ความพร้อมขัดกับนโยบาย:

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

ตรวจสอบทั้งตอนบันทึกความพร้อมและเมื่อใช้เพื่อสลับกะ

เคล็ดลับ UX: อัปเดตในไม่เกิน 30 วินาที

ใช้หน้าจอ "ความพร้อม" เดียวพร้อมกริดรายสัปดาห์และการกระทำด่วน:

• แตะวัน → เลือก ไม่พร้อม/พร้อม/ต้องการ
• สลับ "คัดลอกไปทุกวันทำงาน" และ "ทำซ้ำทุกสัปดาห์"
• เพิ่มข้อยกเว้นด้วยแตะเดียวจากปฏิทิน

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

เวิร์กโฟลว์การสลับกะ

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

โฟลว์สลับหลัก

ทีมส่วนใหญ่ต้องการเส้นทางที่คาดเดาได้:

1. ขอ: พนักงานเลือกกะแล้วแตะ "สลับ" (หรือ "ยกกะ")
2. เสนอ/ยอมรับ: การสลับถูกเสนอให้เพื่อนร่วมงานที่มีสิทธิ์ หรือเชิญเพื่อนร่วมงานเฉพาะคน เพื่อนร่วมงานสามารถยอมรับ (หรือเสนอทางเลือก)
3. อนุมัติ (เมื่อจำเป็น): ผู้จัดการหรือหัวหน้างานตรวจคำขอ
4. อัปเดตตาราง: เมืออนุมัติ การมอบหมายเปลี่ยนบนตารางและทุกคนเห็นการอัปเดตทันที

เพื่อลดการติดต่อกลับ แสดงให้ผู้ขอเห็นว่าจะเกิดอะไรต่อไป: "รอให้ Alex ตอบ" → "รอการอนุมัติจากผู้จัดการ" → "สลับเสร็จแล้ว"

สลับเต็ม สลับบางส่วน และการแบ่งกะ

ไม่ได้ทุกการเปลี่ยนเป็นการแลกแบบ 1 ต่อ 1:

• สลับเต็ม: A และ B แลกกะทั้งกะ
• ปล่อย + รับ: A ปล่อยกะ; B รับ (พบบ่อยในงานรายชั่วโมง)
• สลับบางส่วน/กะแบ่ง: A เก็บบางส่วนของกะและโอนส่วนที่เหลือ

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

การตรวจข้อขัดแย้ง (ก่อนอนุมัติใด ๆ)

รันการตรวจอัตโนมัติตั้งแต่ต้นเพื่อป้องกันการสลับที่ "อนุมัติแต่เป็นไปไม่ได้":

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

ถ้าล้มเหลว อธิบายเป็นภาษาง่าย ๆ และเสนอการแก้ไข (เช่น "เฉพาะพนักงานผ่านการฝึกบาร์เท่านั้นที่รับกะนี้ได้")

เส้นทางตรวจสอบและความรับผิดชอบ

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

UX บนมือถือ: หน้าจอและการไหลของผู้ใช้

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

มุมมองตารางที่ตอบคำถามต่าง ๆ

เสนอมุมมองตารางที่เน้นคำถามเฉพาะ มากกว่าปฏิทินเดียวที่อัดแน่น:

• กำหนดการส่วนบุคคล: รายการกะที่กำลังจะมาถึง (วันนี้ สัปดาห์นี้) พร้อมเวลา เริ่ม/จบ สถานที่ และบทบาท
• กริดทีม: ดูการครอบคลุมตามบทบาทหรือแผนก (มีประโยชน์สำหรับหัวหน้าและผู้จัดการ)
• ปฏิทินสถานที่: ปฏิทินกรองเฉพาะร้าน/ไซต์เดียวเพื่อตรวจช่องว่างและช่วงเวลายุ่ง

เก็บตัวกรองให้นิ่ง (สถานที่ บทบาท ช่วงวันที่) เพื่อผู้ใช้ไม่ต้องตั้งซ้ำทุกครั้ง

หน้าจอหลักเพื่อลด摩擦

ออกแบบรอบการกระทำหลัก พร้อมเส้นทางคงที่กลับไปยังตาราง:

• รายละเอียดกะ: แสดงว่าใคร ที่ไหน เมื่อไร บทบาท หมายเหตุ และคำเตือนนโยบาย (เช่น "การสลับต้องได้รับการอนุมัติจากผู้จัดการ")
• คำขอสลับ: เลือกกะเป้าหมายหรือเพื่อนร่วมงานที่มีสิทธิ์ ใส่ข้อความ และแสดงการตรวจกฎก่อนส่ง
• ตัวแก้ไขความพร้อม: สลับ "พร้อม/ไม่พร้อม" แบบเร็ว รูปแบบซ้ำ และข้อยกเว้นตามวันที่
• กล่องข้อความเข้า: ที่เดียวสำหรับการอนุมัติ คำถาม และอัปเดต—ผู้ใช้ไม่ควรต้องหาในแท็บอื่น

สถานะที่ป้องกันความเข้าใจผิด

ใช้ชุดสถานะเล็ก ๆ ที่สอดคล้องกันด้วยภาษาชัดเจนและตราประทับเวลา:

• Pending (รอดำเนินการ)
• Accepted (ยอมรับ)
• Approved (อนุมัติ)
• Denied (ปฏิเสธ)

แสดงสถานะปัจจุบันทุกที่ที่คำขอปรากฏ (การ์ดกะ รายละเอียด กล่องเข้า)

พื้นฐานการเข้าถึง

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

การแจ้งเตือนและการส่งข้อความ

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

ช่วงสำคัญที่ต้องแจ้งเตือน

เน้นเหตุการณ์ที่เปลี่ยนวันทำงานของใครบางคนโดยตรง:

• กะใหม่ถูกโพสต์หรือมอบหมาย (โดยเฉพาะการเติมกะนาทีสุดท้าย)
• ได้รับคำขอสลับ (สำหรับคนที่ถูกขอให้รับกะ)
• ผลการอนุมัติ (อนุมัติ/ปฏิเสธจากผู้จัดการหรือกฎอัตโนมัติ)
• การเตือน (คำขอกำลังจะหมดอายุ กะเริ่มใน X ชั่วโมง คุณยังไม่ได้ตอบ)

แต่ละการแจ้งควรตอบได้ว่า: เกิดอะไรขึ้น? ฉันต้องทำอะไร? ภายในเวลาเท่าไร? รวม deep link ไปยังหน้าจอที่เกี่ยวข้อง (เช่น "ทบทวนคำขอสลับ")

ให้ผู้ใช้เลือกช่องทาง—โดยไม่เสียการควบคุม

เสนอ push เป็นค่าเริ่มต้น แล้วอนุญาต email และตัวเลือก SMS (หากรองรับ) ผู้คนต่างกัน: พยาบาลในหน้างานอาจพึ่งพา push ขณะที่พนักงานพาร์ทไทม์อาจชอบอีเมล

เก็บการตั้งค่าง่าย ๆ:

• สวิตช์ต่อเหตุการณ์ (คำขอสลับ การอนุมัติ เตือน)
• ชั่วโมงเงียบ (เช่น ไม่มีการแจ้ง 22:00–07:00)
• ตัวเลือกการยกระดับ (เช่น "ถ้าไม่ตอบภายใน 30 นาที ให้ส่ง SMS ด้วย")

หลีกเลี่ยงสแปมและความเหนื่อยหน่ายจากการแจ้ง

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

แผนสำรองเมื่อผู้ใช้ออฟไลน์หรือปิด push

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

พื้นฐานแบ็กเอนด์และโมเดลข้อมูล

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

เอนทิตีหลักที่ต้องเก็บ

อย่างน้อยวางแผนสำหรับบล็อกเหล่านี้:

• Users: พนักงานและผู้จัดการ (โปรไฟล์ ข้อมูลติดต่อ สถานะ)
• Locations: สาขา คลินิก ไซต์ (เขตเวลาสำคัญ)
• Roles: แคชเชียร์ พยาบาล เชฟ (ทักษะ/ใบรับรอง)
• Shifts: วันที่/เวลา สถานที่ บทบาทที่ต้องการ ผู้รับผิดชอบ
• Availability: หน้าต่าง "สามารถทำงาน/ไม่สามารถทำงาน" และบล็อกการลา
• Swap requests: บันทึกการเสนอแลก รวมการตัดสินใจ

ความสัมพันธ์ (ชิ้นต่าง ๆ เชื่อมกันอย่างไร)

จุดเริ่มต้นที่นำไปใช้ได้:

• ผู้ใช้หนึ่งคนมีหลายกะ (กะที่มอบหมายตามเวลา)
• แต่ละกะเป็นของสถานที่หนึ่งและต้องการบทบาทหนึ่ง
• คำขอสลับเชื่อมสองผู้ใช้ (ผู้ขอ + เป้าหมาย) และหนึ่งหรือสองกะ ขึ้นกับประเภทการสลับ (ปล่อย vs แลก)

ตัวอย่าง (สรุป):

Shift(id, location_id, role_id, starts_at, ends_at, assigned_user_id)
SwapRequest(id, offered_shift_id, requested_shift_id?, from_user_id, to_user_id, status)

(หมายเหตุ: บล็อกโค้ดนี้ห้ามแปล)

สถานะคำขอสลับ ("ความจริง" ของแอพคุณ)

จัดการการสลับเหมือนเครื่องจักรสถานะเล็ก ๆ เพื่อให้ทุกคนเห็นความจริงเดียวกัน:

• pending → accepted หรือ declined
• accepted → approved (ถ้าต้องการการอนุมัติจากผู้จัดการ)
• ตลอดเวลา: canceled (โดยผู้ขอ), expired (ครบกำหนดเวลา)

ป้องกันการจองซ้ํา

การจองซ้ำเกิดเมื่oสองการกระทำมาถึงพร้อมกัน (สองการสลับ หรือการสลับ + แก้ไขโดยผู้จัดการ) แก้ด้วย การอัปเดตเชิงธุรกรรม: ตอนอนุมัติการสลับ ให้อัปเดตการมอบหมายกะทั้งสองในธุรกรรมเดียว และปฏิเสธถ้ากะใดเปลี่ยนไป

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

API, การซิงค์ และประสิทธิภาพ

แอพสลับกะขึ้นอยู่กับการที่ตารางดูเป็นปัจจุบัน นั่นหมายถึง API ชัดเจน พฤติกรรมการซิงค์ที่คาดเดาได้ และการป้องกันด้านประสิทธิภาพบางอย่าง—โดยไม่ต้องออกแบบเกินความจำเป็นสำหรับ MVP

จุดสิ้นสุด API หลักที่ควรวางแผน

เก็บเวอร์ชันแรกให้เล็กและมุ่งตามภารกิจ:

• Schedule: ดึงตารางทีม (ตามสถานที่/ทีม/ช่วงวันที่), ดึงรายละเอียดกะ
• Availability: ตั้ง/อัปเดตบล็อกความพร้อม, ดึงความพร้อมของผู้ใช้/ช่วงวันที่
• Swap actions: สร้างคำขอสลับ, ยอมรับ/ปฏิเสธ, ยกเลิก, ดูสถานะการสลับ
• Approvals: ดึงรายการการอนุมัติรอดำเนินการ (สำหรับผู้จัดการ), อนุมัติ/ปฏิเสธพร้อมเหตุผล

ออกแบบการตอบกลับเพื่อให้แอพมือถือเรนเดอร์เร็ว (เช่น ส่งกะพร้อมข้อมูลผู้ใช้ขั้นต่ำที่ต้องใช้แสดง)

อัปเดตแบบเรียลไทม์: การซิงค์ MVP แบบเรียบง่าย

สำหรับ MVP ให้ใช้ polling ด้วยช่วงเวลาอัจฉริยะ (เช่น รีเฟรชเมื่อเปิดแอพ ดึงลงเพื่อรีเฟรช และทุก ๆ ไม่กี่นาทีขณะดูหน้าตาราง) เพิ่ม timestamp updated_at ที่ฝั่งเซิร์ฟเวอร์เพื่อให้แอพทำการดึงข้อมูลเฉพาะส่วนที่เปลี่ยน

Webhooks และ sockets รอได้จนกว่าคุณจะต้องการอัปเดตแบบวินาทีต่อวินาที หากเพิ่ม sockets ให้เริ่มจากการเปลี่ยนสถานะการสลับเท่านั้น

เขตเวลาและการเปลี่ยนเวลาออมแสง

เก็บเวลาเริ่ม/จบกะในรูปแบบมาตรฐาน (UTC) พร้อมกับ เขตเวลาของสถานที่ทำงาน เสมอ คำนวณเวลาแสดงโดยใช้เขตเวลานั้น

ในช่วงเปลี่ยน DST ให้หลีกเลี่ยงเวลา "ลอย" เก็บจุดเวลาแน่นอนและตรวจสอบการทับซ้อนโดยใช้กฎเขตเวลาตัวเดียวกัน

ตัวเลือกการจัดเก็บ

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

ความปลอดภัย ความเป็นส่วนตัว และการปฏิบัติตามข้อกำหนด

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

การพิสูจน์ตัวตนและความปลอดภัยของเซสชัน

ตัดสินใจวิธีเซ็นอินตามความเป็นจริงของลูกค้า:

• อีเมล/รหัสผ่าน สำหรับการเปิดตัวง่าย ๆ
• SSO (Google/Microsoft/Okta) สำหรับองค์กรใหญ่
• รหัสเชิญ / ลิงก์เวทย์มนต์ เพื่อลดการจัดการรหัสผ่าน

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

การอนุญาตในทุกคำขอ

อย่าไว้วางใจ UI ในการ "ซ่อน" การกระทำ ให้บังคับสิทธิ์ใน ทุก API call กฎทั่วไปเช่น:

• พนักงานขอการสลับและแก้ไขความพร้อมของตนเองได้
• ผู้จัดการอนุมัติ/ปฏิเสธและดูความคุ้มครองทีมได้
• แอดมินจัดการสถานที่ นโยบาย และการส่งออกได้

นี่จะป้องกันไม่ให้ผู้ใช้เรียก endpoint การอนุมัติโดยตรง

ปกป้องข้อมูลส่วนบุคคลโดยออกแบบ

เก็บข้อมูลขั้นต่ำที่จำเป็นเพื่อจัดตารางงาน เข้ารหัสข้อมูล ขณะส่ง (TLS) และ ขณะพัก แยกฟิลด์ที่ละเอียดอ่อน (เช่น เบอร์โทร) และจำกัดผู้เข้าถึง

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

บันทึกตรวจสอบและควบคุมการส่งออก

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

เพิ่มการควบคุมการส่งออก: จำกัดผู้ที่ส่งออกได้ ใส่ลายน้ำใน CSV/PDF และบันทึกกิจกรรมการส่งออกในบันทึกตรวจสอบ ซึ่งมักจำเป็นสำหรับนโยบายภายในและการทบทวนการปฏิบัติตาม

การเชื่อมต่อ: เงินเดือน การติดตามเวลา และปฏิทิน

การเชื่อมต่อทำให้อัพสลับกะดู "สมจริง" สำหรับทีมปฏิบัติการ—เพราะการสลับไม่มีความหมายถ้าค่าจ้าง ชั่วโมง และการเข้าทำงานไม่ถูกต้อง กุญแจคือเชื่อมเฉพาะข้อมูลที่จำเป็นจริง ๆ และออกแบบชั้นการเชื่อมต่อให้สามารถเพิ่มระบบได้ทีหลัง

เงินเดือนและการติดตามเวลา: ควรซิงค์อะไร

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

วางแผนส่งหรือซิงค์ชุดขั้นต่ำ:

• รหัสพนักงาน (ID ภายใน + ID ภายนอกของระบบเงินเดือน/เวลา)
• สถานที่/แผนก/รหัสงาน (เพื่อให้กฎอัตราจ่ายถูกต้อง)
• เวลาเริ่ม/จบกะและกฎพัก
• ผู้รับผิดชอบสุดท้าย พร้อมการอ้างอิงบันทึกตรวจสอบ (ID ของสลับ ตราประทับเวลาอนุมัติ)

ถ้าแอพรองรับค่าพิเศษ (ทริกเกอร์ล่วงเวลา ค่าตอบแทนพิเศษ) ให้ตัดสินใจว่าส่วนไหนคำนวณโดย payroll (แนะนำ) หรือโดยแอพของคุณ เมื่อสงสัย ให้ส่งชั่วโมงที่สะอาดและให้ payroll คำนวณอัตราจ่าย

การซิงค์ปฏิทินส่วนตัว (ตัวเลือก) โดยไม่เปิดเผยมากเกินไป

ฟีเจอร์เสริมที่เป็นประโยชน์คือ การเข้าถึงปฏิทินส่วนตัวแบบอ่านอย่างเดียว เพื่อเตือนความขัดแย้งเมื่อเสนอหรือรับกะ

ทำให้เป็นมิตรกับความเป็นส่วนตัว: เก็บเฉพาะบล็อก "ไม่ว่าง/ว่าง" (ไม่เก็บหัวข้อ/ผู้เข้าร่วม), แสดงความขัดแย้งในเครื่องของผู้ใช้, และให้เป็นแบบเลือกเข้าร่วมต่อผู้ใช้

Webhooks การส่งออก และการออกแบบให้เพิ่มทีหลัง

ลูกค้าบางรายต้องการอัปเดตแบบเรียลไทม์ บางรายต้องการไฟล์รายวัน

สร้างเลเยอร์การเชื่อมต่อที่รองรับ:

• Webhooks (เช่น shift.updated, swap.approved) สำหรับระบบภายนอก
• การส่งออกตามตาราง (CSV/SFTP) สำหรับ payroll เก่า

เพื่อหลีกเลี่ยงการเขียนระบบใหม่ทีหลัง เก็บการเชื่อมต่อไว้หลังโมเดลเหตุการณ์ภายในที่มั่นคงและตารางแมป (ID ภายใน ↔ ID ภายนอก) เพื่อการเพิ่มผู้ให้บริการใหม่กลายเป็นการตั้งค่าและแปลข้อมูล ไม่ใช่งานแก้โครงสร้างหลัก

ขอบเขต MVP และโรดแมปผลิตภัณฑ์

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

MVP: ชุดเล็กที่สุดที่สร้างคุณค่าได้

เริ่มด้วยฟีเจอร์ที่รองรับวงจรประจำวัน:

• ดูตาราง (ตามสัปดาห์/วัน ตามบทบาทและสถานที่)
• ตั้งความพร้อม (เวลาที่ชอบ บล็อก "ไม่สามารถทำงาน")
• ขอสลับ (เลือกกะ เสนอเพื่อนร่วมงาน ใส่หมายเหตุ)
• การอนุมัติ/ปฏิเสธ (การอนุมัติผู้จัดการ และ/หรือ การยอมรับของเพื่อนร่วมงาน ตามกฎ)
• การแจ้งเตือน สำหรับคำขอใหม่ การอนุมัติ และการเปลี่ยนแปลงนาทีสุดท้าย

MVP ควรรวมเกราะป้องกันพื้นฐาน: ป้องกันการสลับที่ละเมิดข้อกำหนดบทบาท เวลาพักขั้นต่ำ หรือเกณฑ์ล่วงเวลา (แม้ว่ากฎจะเรียบง่ายในตอนแรก)

ถ้าต้องการไปเร็วโดยไม่ต้องสร้างสแตกใหม่ทีหลัง แพลตฟอร์มแบบ vibe-coding เช่น Koder.ai สามารถช่วยทำต้นแบบเวิร์กโฟลว์แบบ end-to-end (UI มือถือ + แบ็กเอนด์ + ฐานข้อมูล) จากสเปคแชทที่มีโครงสร้าง ทีมมักใช้เพื่อยืนยันเครื่องจักรสถานะการสลับ สิทธิ์ และทริกเกอร์การแจ้งเตือนตั้งแต่ต้น—แล้วส่งออกซอร์สโค้ดเมื่อต้องการปรับแต่งลึก

ฟีเจอร์ที่ดีควรมีในอนาคต (หลัง MVP เสถียร)

เมื่อผู้คนเชื่อมั่นในเวิร์กโฟลว์พื้นฐานแล้ว ให้เพิ่มฟีเจอร์ที่เพิ่มอัตราการเติมและลดงานผู้จัดการ:

• แนะนำผู้ทดแทนอัตโนมัติ ตามความพร้อมและคุณสมบัติ
• บอร์ดกะเปิด ที่พนักงานสามารถรับกะว่างได้
• การประมูลกะ (ใช้ได้กับกะที่ต้องการสูง แต่ต้องมีกฎที่ชัดเจน)

โรดแมปที่ลดความเสี่ยง

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

ติดตามตัวชี้วัดความสำเร็จเช่น เวลาในการเติมกะที่ลดลง กะที่พลาดน้อยลง และข้อความที่ลดลง

วางแผน milestone โดยมีเช็คลิสต์ว่า "พร้อม" หมายถึงอะไร (สิทธิ์ กฎ การแจ้งเตือน บันทึกตรวจสอบ) หากเป็นประโยชน์ ให้ดูตัวอย่างข้อความ: /blog/scheduling-mvp-checklist

การทดสอบ การพิลอต และการเปิดตัว

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

กรณีทดสอบที่มีผลสูง

รันการทดสอบแบบ end-to-end ด้วยข้อมูลสมจริง (หลายสถานที่ บทบาท และกฎ) และยืนยันตารางสุดท้ายทุกครั้ง:

• กะซ้อนกัน: ตรวจสอบว่าการสลับไม่สร้างการจองซ้ำสำหรับพนักงานเดิม แม้คำขอจะมาพร้อมกัน
• คำขอหมดอายุ: ยืนยันว่าคำขอสลับหมดอายุโดยอัตโนมัติตามเวลาที่กำหนด (เช่น 2 ชั่วโมงก่อนเริ่มกะ) และการแจ้งเตือนหยุด
• ผู้จัดการบังคับ: ตรวจสอบผลเมื่อผู้จัดการอนุมัติ/ปฏิเสธหลังช่วงตัดขาด หรือบังคับมอบหมาย—ประวัติการตรวจสอบควรยังแสดงว่าใครทำอะไร
• ขอบเขตเขตเวลา: ทดสอบการเปลี่ยน DST พนักงานเดินทาง และผู้จัดการอนุมัติจากเขตเวลาอื่น; กะควรแสดงอย่างสอดคล้องและบันทึกเวลาอย่างปลอดภัย

แผนพิลอตที่ได้ฟีดแบ็กจริงใจ

เริ่มกับกลุ่มเล็ก (ทีมเดียวหรือสถานที่เดียว) เป็นเวลา 1–2 สัปดาห์ เก็บวงป้อนกลับสั้น: เช็กอินรายวันและการทบทวนสั้น 15 นาทีรายสัปดาห์

เตรียมช่องทางซัพพอร์ตเดียว (เช่น อีเมลจัดไว้เฉพาะหรือหน้าสนับสนุน) และยืนยันเวลาในการตอบเพื่อให้ผู้ใช้ไม่กลับไปใช้ข้อความและการสนทนานอกระบบ

วัดการนำไปใช้และผลลัพธ์

ติดตามตัวชี้วัดไม่กี่ตัวที่สะท้อนคุณค่าจริง:

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

เช็คลิสต์ก่อนเปิดตัว

ก่อนเปิดให้ทุกคนใช้:

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