10. นโยบายและข้อกำหนด#
10.1 การเข้าถึงระบบ#
| เรื่อง | ข้อกำหนด |
|---|---|
| การยืนยันตัวตน | Google Workspace เท่านั้น จำกัดโดเมน @buildupclick.com — ไม่มีรหัสผ่านของระบบเอง |
| พนักงานลาออก | ปิดบัญชี Google → เข้าระบบไม่ได้ทันที · ตั้ง is_active = false ห้ามลบข้อมูล |
| Token สำหรับ Claude | ผูกรายบุคคล · หมดอายุ 180 วัน · เพิกถอนได้ทันทีจากหน้าเว็บ · เก็บแบบ hash |
| การเข้าถึงฐานข้อมูลโดยตรง | เฉพาะผู้ดูแลระบบ ผ่าน SSH เท่านั้น ไม่เปิดพอร์ตออกอินเทอร์เน็ต |
10.2 ข้อมูลพนักงานและความไว้ใจ#
กติกาที่สำคัญที่สุดของทั้งโครงการ
ชั่วโมงทำงานที่บันทึกในระบบ จะไม่ถูกใช้เป็นตัวชี้วัดประเมินผลรายบุคคล
เหตุผล: วินาทีที่ทีมรู้ว่าชั่วโมงมีผลต่อการขึ้นเงินเดือนหรือโบนัส ตัวเลขจะถูกปั้นทันที แล้วข้อมูลต้นทุนที่เป็นเป้าหมายหลักของทั้งระบบจะพังทั้งหมด — ได้อย่างเสียอย่าง บริษัทเลือก ข้อมูลต้นทุนที่จริง มากกว่าเครื่องมือจับผิดรายคน
แยกให้ชัดสองเรื่อง#
| ใช้ทำอะไร | ใช้ข้อมูลอะไร | |
|---|---|---|
| ข้อมูลต้นทุน | คิดต้นทุนโครงการ · ตัดสินใจเรื่องราคาและขอบเขต · วางแผนกำลังคน | ชั่วโมงที่ลง — ต้องจริงที่สุด |
| การประเมินผลงาน | ขึ้นเงินเดือน · โบนัส · เลื่อนตำแหน่ง | คุณภาพงาน · การส่งมอบตรงเวลา · การช่วยทีม — ไม่ใช่จำนวนชั่วโมง |
สิ่งที่ระบบจะไม่ทำ#
- ❌ ไม่มีตารางจัดอันดับชั่วโมงทำงานรายบุคคล
- ❌ ไม่แสดง timesheet ของคนหนึ่งให้เพื่อนร่วมงานระดับเดียวกันดู
- ❌ ไม่จับเวลาอัตโนมัติ ไม่จับภาพหน้าจอ ไม่ติดตามการเคลื่อนไหวของเมาส์
- ❌ ไม่ใช้ข้อมูลเวลาเป็นหลักฐานลงโทษทางวินัย
สิ่งที่ต้องประกาศให้ทีมทราบก่อนเริ่มใช้#
- เก็บข้อมูลอะไรบ้าง
- ใครเห็นข้อมูลอะไรได้บ้าง (ตารางสิทธิ์ใน หน้า 2)
- ข้อมูลถูกใช้ทำอะไร และ ไม่ถูกใช้ทำอะไร
- พนักงานขอดูข้อมูลของตัวเองทั้งหมดได้เมื่อไหร่ก็ได้
10.3 ความเป็นส่วนตัวและ PDPA#
| หลักการ | การปฏิบัติ |
|---|---|
| เก็บเท่าที่จำเป็น | เก็บเฉพาะข้อมูลที่ใช้คิดต้นทุนและบริหารงาน ไม่เก็บข้อมูลส่วนตัวที่ไม่เกี่ยวข้อง |
| แจ้งวัตถุประสงค์ | ประกาศเป็นลายลักษณ์อักษรก่อนเริ่มใช้ระบบ ให้พนักงานรับทราบ |
| สิทธิ์เข้าถึงข้อมูลตนเอง | พนักงานดูและ export ข้อมูลของตัวเองได้ตลอดเวลา |
| จำกัดผู้เข้าถึง | เงินเดือนและ cost_rate เห็นได้เฉพาะ executive และ admin |
| ระยะเวลาเก็บ | ข้อมูลเวลาเก็บ 5 ปี (สอดคล้องกับระยะเวลาเก็บเอกสารทางบัญชี) แล้วทำให้ไม่ระบุตัวตน |
| ข้อมูลลูกค้า | ห้ามนำข้อมูลของ LSM99 หรือคุณตั้มออกนอกระบบ · KB ต้องไม่มีข้อมูลลับของลูกค้า |
10.4 การตรวจสอบย้อนหลัง (Audit)#
ทุกการกระทำต่อไปนี้ต้องบันทึกใน audit_log — ใคร เมื่อไหร่ ค่าเดิม ค่าใหม่ เหตุผล
- แก้ไขหรือลบ
time_entry - สร้างหรือแก้
cost_rate - อนุมัติ / ไม่อนุมัติ OT และการลา
- ปิดงวด และการแก้ไขข้อมูลหลังปิดงวด (บังคับกรอกเหตุผล)
- สร้าง / เพิกถอน token สำหรับ Claude
- เปลี่ยนบทบาทของพนักงาน
audit_log เป็นแบบ เพิ่มได้อย่างเดียว ไม่มีใครลบหรือแก้ได้ รวมถึง admin
10.5 ข้อกำหนดที่ไม่ใช่ฟังก์ชัน#
| ด้าน | เป้าหมาย |
|---|---|
| ความพร้อมใช้งาน | 99% ในเวลาทำงาน — ระบบล่มไม่กระทบงานลูกค้าโดยตรง แต่ต้องกู้ได้ใน 4 ชม. |
| ความเร็ว | ทุกหน้าโหลดใน 2 วินาที · การลงเวลาบันทึกเสร็จใน 1 วินาที |
| รองรับผู้ใช้ | ออกแบบสำหรับ 50 คน (ปัจจุบันน้อยกว่านี้มาก) — ไม่ต้องออกแบบเผื่อระดับพันคน |
| ภาษา | ภาษาไทยเป็นหลักทั้งระบบ |
| อุปกรณ์ | ใช้งานได้เต็มรูปแบบบนมือถือ |
| การกู้คืน | RPO 24 ชม. (เสียข้อมูลได้ไม่เกิน 1 วัน) · RTO 4 ชม. |
10.6 การดูแลระบบหลังส่งมอบ#
| งาน | ความถี่ | ใคร |
|---|---|---|
| ตรวจว่า backup ทำงานปกติ | ทุกสัปดาห์ | ผู้ดูแลระบบ |
| ทดสอบกู้คืนข้อมูลจริง | ทุกไตรมาส | ผู้ดูแลระบบ |
ทบทวน overhead_rate |
ทุกไตรมาส | ผู้บริหาร + บัญชี |
| ทบทวนสิทธิ์การเข้าถึง | ทุกไตรมาส | ผู้บริหาร |
| อัปเดตความปลอดภัยของระบบ | ทุกเดือน | ผู้ดูแลระบบ |
| ทบทวนเอกสารฉบับนี้ | เมื่อมีการเปลี่ยนแปลงสำคัญ | ผู้รับผิดชอบโครงการ |
10.7 การเปลี่ยนแปลงเอกสารนี้#
เอกสารนี้เก็บเป็นไฟล์ Markdown ใน Git ที่ apps/spec/docs/
การแก้ไขทำผ่าน commit แล้ว deploy ใหม่ด้วย deploy wai-work spec
ประวัติการเปลี่ยนแปลงทั้งหมดดูย้อนหลังได้จาก Git
| เวอร์ชัน | วันที่ | การเปลี่ยนแปลง |
|---|---|---|
| v0.1 | 12 ส.ค. 2569 | ฉบับร่างแรก — ครอบคลุมภาพการทำงานร่วมกัน โมเดลต้นทุน โครงสร้างข้อมูล และแผนงาน |