บทที่ 36: การตัดสินใจ ตารางเวลา และความต่อเนื่อง

ผลลัพธ์ของบทนี้

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

คุณจะรู้ขอบเขตของ Arra รุ่นที่ตรวจในหนังสือด้วยว่า แนวคิดการเก็บเหตุผลการตัดสินใจยังมีคุณค่า แต่เครื่องมือกลุ่มการตัดสินใจและการปรึกษาจากเอกสารรุ่นเก่าไม่ใช่พื้นผิวปัจจุบัน ส่วนตารางเวลาที่ตรวจยืนยันได้ในตอนนี้มีพื้นผิวอ่านผ่าน CLI/HTTP ไม่ใช่เครื่องมือ MCP สำหรับสอนในบทหลัก

สถานการณ์ใกล้ตัว

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

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

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

บันทึกที่ดีควรตอบได้ว่า

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

ตารางเวลาช่วยเตือน “เมื่อใด” แต่ไม่เก็บ “ทำไม” แทนบันทึกการตัดสินใจ

ต้นทุนของการเก็บเพียงผล ไม่เก็บเหตุผล

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

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

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

ภาพเปรียบเทียบ

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

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

ศัพท์ใหม่ในบทนี้

• บันทึกการตัดสินใจ (decision record): เอกสารที่เก็บโจทย์ ทางเลือก หลักฐาน เหตุผล และผู้อนุมัติ
• วันทบทวน (review date): วันที่กำหนดให้กลับมาดูว่าบริบทและหลักฐานยังเหมือนเดิมหรือไม่
• เงื่อนไขเปลี่ยนใจ (reversal trigger): เหตุการณ์หรือตัวเลขที่ทำให้ต้องหยุดหรือเลือกใหม่
• ตารางเวลา (schedule): รายการเหตุการณ์หรืองานตามวันและสถานะ
• พื้นผิวปัจจุบัน (current surface): คำสั่งหรือเครื่องมือที่ซอร์สโค้ดหรือหน้าช่วยเหลือของรุ่นที่ตรวจยืนยันว่ามีอยู่ตอนนี้

แก่นของเรื่อง

การตัดสินใจเป็นผลงาน ไม่ต้องรอเครื่องมือเฉพาะ

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

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

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

บันทึกเหตุผลให้แยกจากข้อเท็จจริง

ตัวอย่าง:

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

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

ผูกวันทบทวนกับเจ้าของ

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

ตารางเวลา (Schedule) ช่วยเรื่องเวลา ไม่ใช่การอนุมัติ (approval)

Arra รุ่นที่ตรวจในหนังสือมีการอ่านตารางเวลาผ่าน CLI schedule และ HTTP API ที่เกี่ยวข้อง การเพิ่มหรืออัปเดตกำหนดการเปลี่ยนข้อมูล จึงต้องมีขอบเขตและสิทธิ์

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

ความต่อเนื่องต้องกลับไปยังหลักฐาน

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

ผลงานประจำบท: บันทึกการตัดสินใจเก้าช่อง

เพิ่มสถานะว่า “draft”, “approved for experiment” หรือ “closed after review” ตามภาษาที่องค์กรกำหนด อย่านำสถานะ artifact completed/staged/supported/planned มาใช้แทนวงจรอนุมัติโดยไม่อธิบาย เพราะเป็นคนละมิติ

พื้นผิวปัจจุบัน: สิ่งที่ใช้ได้และสิ่งที่ไม่ควรเดา

ก่อนถ่ายคอร์สหรือใช้กับระบบจริง ให้ผู้ดูแลตรวจ arra-cli --help และหน้าช่วยเหลือของ schedule จากเวอร์ชันเป้าหมายอีกครั้ง เพราะแพ็กเกจ CLI, README และแพ็กเกจซอร์สในชุดที่ตรวจอาจรายงานเวอร์ชันต่างกัน

ตัวอย่างจำลองตามกระบวนการ Oracle V4

เส้นทางครบ: มนุษย์ส่งเรื่องให้ Earth AI แล้ว Earth AI ส่งต่อให้ Jan เลือก House เมื่อ House ทำงานเสร็จ รายงานจะกลับผ่าน Jan และ Earth AI จนถึงมนุษย์

มนุษย์ขอแฟ้มหลักฐานเรื่องรอบส่งวันเสาร์ผ่าน Earth AI ให้ Jan เลือก House House ทำแฟ้มและส่งรายงานเป็นไฟล์กลับ Jan จากนั้น Jan รวมรายงานและส่งผ่าน Earth AI กลับให้มนุษย์ตัดสิน เจ้าของธุรกิจเลือกทดลองสี่สัปดาห์ จึงสร้างบันทึกการตัดสินใจเป็นไฟล์พร้อมวันทบทวน

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

เมื่อถึงวันทบทวน รายงานผลใหม่จะกลับเข้าสู่เส้นทาง Jan-first และมนุษย์เป็นคนคง เปลี่ยน หรือยุติการทดลอง

หยุดแล้วมองอีกครั้ง

นึกถึงกฎหนึ่งข้อที่ทีมทำต่อเนื่องมานาน เช่น วันประชุม ส่วนลด หรือขั้นอนุมัติ คุณยังรู้หรือไม่ว่ากฎนั้นถูกเลือกเพื่อแก้ปัญหาอะไร

ถ้าเหตุผลเดิมหายไป เราอาจรักษากฎไว้เพราะความคุ้นเคย แม้กฎนั้นอาจหมดหน้าที่แล้ว บันทึกการตัดสินใจเปิดทางให้ทีมกลับมาถามอย่างมีหลักฐานโดยไม่บังคับให้เปลี่ยน

ลองทำอย่างปลอดภัย

ใช้กรณีสังเคราะห์:

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

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

ก่อนเริ่ม (preflight)

• ใช้วันที่ เขต ค่าใช้จ่าย และเกณฑ์ที่แต่งขึ้น
• ทำในเอกสารออฟไลน์
• ไม่เรียกตารางเวลาหรือพื้นผิวเขียนข้อมูลใด ๆ

ผลที่คาดหวัง (expected result)

• ได้บันทึกการตัดสินใจหนึ่งใบที่แยกข้อเท็จจริง สมมติฐาน และตัวเลือก
• มีผู้อนุมัติเป็นชื่อบทบาท
• มีวันทบทวนและเงื่อนไขหยุดอย่างน้อยหนึ่งข้อ
• ไม่มีชื่อคำสั่งกลุ่มการตัดสินใจ/การปรึกษารุ่นเก่าในขั้นปฏิบัติ

หยุดและถามคนเมื่อ… (stop condition)

• หยุดเมื่อจะสร้างหรือแก้ปฏิทินจริง
• หยุดเมื่อการตัดสินใจอาจกระทบลูกค้า พนักงาน งบประมาณ หรือสัญญาจริง
• หยุดหากกำลังเดา syntax จากคู่มือคนละเวอร์ชัน

วิธีกู้คืน (recovery)

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

ระวังความเข้าใจผิด

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

สามเรื่องที่ควรจำ

1. เก็บเหตุผล ทางเลือก ข้อจำกัด และเงื่อนไขเปลี่ยนใจ ไม่ใช่เก็บเพียงคำตอบ
2. ใช้ตารางเวลาเพื่อเตือนการทบทวน แต่ให้คนเป็นเจ้าของและอนุมัติ
3. ไม่สอนเครื่องมือการตัดสินใจ/การปรึกษา หรือตารางเวลาผ่าน MCP จากเอกสารเก่าเป็นพฤติกรรมปัจจุบัน

คำถามชวนคิด

การตัดสินใจใดในธุรกิจของคุณถูกทำให้ถาวร ทั้งที่ตอนแรกตั้งใจเพียง “ลองดูหนึ่งเดือน”

สะพานไปบทถัดไป

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