สารบัญ
ตอนที่แล้ว สัญญาที่ต้องเขียน คำสัญญากับลูกค้าถูกเขียนไว้ และมีระบบที่ทำตามได้
ตอนนี้เราจะได้ 30 นาทีต่อสัปดาห์ที่ไล่ดูทุกตารางในภาคนี้ และบันทึกบทเรียนที่กลายเป็นกฎ
ตอนหน้าเมื่อต้นเปิดบริษัทที่สอง เขาจะรู้ว่าวันแรกต้องมีอะไร
ทุกบทความในซีรีส์นี้มาจากการที่ผมคุยกับ AI แล้วค้นข้อมูลเพิ่มเติม ผมเป็นคนกำหนดทิศทาง ให้ AI ช่วยสรุป วิเคราะห์ และเรียบเรียงออกมาเป็นบทความครับ
เราอยู่ตรงไหนของแผนที่
บนแถบ 5 ขั้น คราวนี้ไม่ได้อยู่ขั้นเดียว แต่เป็นลูกศรที่วนจาก Deploy/Run กลับไปที่ Requirements
ชิ้นจิ๊กซอว์ที่ 11 รอบทบทวน คือเรื่องที่ 27 วงเรียนรู้และตัวเลขที่ต้องดู กับเรื่องที่ 28 ตัวเจ้าของเอง
ตอนนี้ปิดช่วงที่ 3 เมื่อบริษัทโต
หัวใจของตอนนี้
ระบบที่ไม่มีใครกลับมาดู จะค่อยๆ เสื่อม และบทเรียนที่ไม่กลายเป็นกฎ จะเกิดซ้ำ
ทำไมเรื่องนี้สำคัญ?
ตอน 5 ถึง 11 สร้างตารางไว้ 7 ชุด
ทุกชุดทำงานได้ ก็ต่อเมื่อมีคนดูเป็นประจำ
ถ้าไม่มีรอบทบทวน เพดานจะเก่า การข้ามด่านจะกลายเป็นนิสัย และคำขอลูกค้าจะเลยกำหนด
ความผิดพลาดเดิมจะเกิดอีก เพราะไม่มีใครเขียนเป็นกฎ
หลัก 5 ข้อข้างล่างคือวิธีไปถึงประโยคในกล่องหัวใจ
ความผิดพลาดเดิม ครั้งที่สาม
สัปดาห์ที่ 30 นับจากเปิดบริษัท (ตัวอย่าง)
agent-build เขียน migration ที่ add แล้ว drop column ใน release เดียว
เป็นความผิดแบบเดียวกับตอน 7
ครั้งที่สองเกิดเมื่อเดือนก่อน แก้มือแล้วลืม (ตัวอย่าง)
ครั้งนี้ด่านใน staging จับได้ก่อนขึ้น production ข้อมูลจริงจึงไม่เสียหาย
แต่กฎ “ห้าม add กับ drop ใน release เดียว” ยังอยู่แค่ในหัวของต้น ไม่ได้อยู่ในที่ที่ agent อ่าน
เพดาน $150 ของ agent-build จากตอน 10 ก็ต่ำเกินงานจริงแล้ว เดือนนี้ชนเพดานสองครั้ง ต้นต้องเพิ่มเพดานชั่วคราว “แค่ครั้งนี้” (ตัวอย่าง)
คำขอลบข้อมูล #231 จากตอน 11 เหลืออีก 4 วันจะครบ 30 วันตามที่หน้า privacy สัญญาไว้ และไม่มีใครเห็น (ตัวอย่าง)
agent ไม่จำ ถ้าเราไม่เขียน
คนที่ทำงานแบบนี้จริง
Chris Sev หัวหน้าทีม DevRel ที่ Auth0 ตอบไว้ เรื่องความผิดพลาดที่หลุดไปว่า
“mistakes can get through but then you should always be creating new instructions using pstack’s /correct so it doesnt happen again”
lauren (@poteto) เขียนไว้ ว่าตอนที่โพสต์ เธอมี Cursor Projects ทำงานพร้อมกัน 16 ตัว และ prompt ที่เธอใช้บ่อยที่สุดคือ
“/bro catch me up on everything since my last message, and if there are any action items for me give me enough context (exec summary) to make a call”
ทั้งสองคนไม่ได้ไล่อ่านทุกอย่างเอง เขาให้ระบบสรุปมา แล้วตัดสินใจ และเขียนกฎใหม่ทันทีที่พลาด
ตารางครบแล้ว แต่ใครเปิดดู?
ทุกตารางมีรอบดูของตัวเองอยู่แล้ว
ค่าใช้จ่ายดูรายสัปดาห์ restore test ทำรายเดือน คำขอลูกค้าดูตามวันครบกำหนด
ปัญหาคือแต่ละรอบอยู่คนละที่ และไม่มีใครรวม
ตอนนี้รวมทุกรอบไว้ในช่องเวลาเดียว
หลัก 1: รอบสั้นที่แน่นอน
ระบบจะไม่เสื่อม ถ้ามีคนกลับมาดูเป็นรอบที่แน่นอน
หลักการข้อหนึ่งของ Agile Manifesto เขียนว่า “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Scrum Guide 2020 เขียนว่า “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”
ฉบับของต้น: วันศุกร์ 16:00 30 นาที ล็อกไว้ในปฏิทิน ทำคนเดียว (ตัวอย่าง)
หลัก 2: agent สรุปมาก่อน คนตัดสินใจ
ถ้าต้องไล่ดูทุกตารางเอง 30 นาทีไม่พอ
routine วันศุกร์ 15:00 (ตัวอย่าง) อ่านตาราง 7 ชุด ประวัติ PR และบิลของผู้ให้บริการ แล้วเติมส่วนที่ 1 ถึง 6 ของหน้าทบทวน
สรุปมีแต่ตัวเลขกับลิงก์ ไม่มีความเห็น ต้นอ่านจบในราว 10 นาที (ตัวอย่าง)
รอบนี้เป็นรายสัปดาห์ ไม่ใช่รายชั่วโมง lauren เขียนไว้ ว่า routine ที่ถี่เกินไปแพง และ “hourly is the most frequent interval i would recommend for scheduled ones”
หลัก 3: ดูตัวเลขที่ทำให้ตัดสินใจได้
การกลับมาดูมีประโยชน์ เมื่อสิ่งที่ดูบอกได้ว่าต้องทำอะไร
Google SRE book แนะนำ ให้ตั้ง error budget คือส่วนที่ยอมให้พลาดจาก SLO ได้ แล้ว “track that on a daily or weekly basis”
แต่ละส่วนของหน้าทบทวนจึงมีตัวเลขเดียว (ตัวอย่าง):
| ส่วน | ตัวเลข | มาจาก |
|---|---|---|
| 1 งาน | ค้างเกิน 7 วันกี่ใบ | ตอน 6 |
| 2 ด่าน | ข้ามด่านกี่ครั้ง | ตอน 7 |
| 3 drift | repo ไหน drift | ตอน 8 |
| 4 incident | ล่มกี่นาที และ restore test ผ่านไหม | ตอน 9 |
| 5 เงิน | ใช้ไปกี่ % ของเพดาน | ตอน 10 |
| 6 คำขอลูกค้า | กี่รายการใกล้ครบกำหนด | ตอน 11 |
งานมือที่เจอซ้ำทุกสัปดาห์ก็นับด้วย Google SRE แยกไว้ ว่า “Toil is not just “work I don’t like to do.”” toil คืองานมือที่ทำซ้ำและทำเป็นอัตโนมัติได้
เจอแล้วให้กลายเป็น script หรืองานของ agent
หลัก 4: ตัดสินใจไม่เกิน 3 เรื่อง
ถ้าตัดสินใจทุกเรื่องที่เห็น 30 นาทีจะยืดออกจนไม่มีใครอยากเปิด
ส่วนที่ 7 จึงมีที่ให้เขียนได้แค่ 3 เรื่อง
ทุกเรื่องกลายเป็น ticket ในช่องรับงานของตอน 6 พร้อมระดับความเสี่ยง
เรื่องที่เกินมารอสัปดาห์หน้า เหมือน WIP limit ของตอน 6
เรื่องที่เปลี่ยนเพดานหรือด่าน ต้นเป็นคนตัดสินใจเท่านั้น ตามชื่อคนรับผิดชอบในตอน 10
หลัก 5: บทเรียนต้องกลายเป็นกฎที่ agent อ่านได้
บทเรียนที่ไม่ถูกเขียนลงไป จะเกิดซ้ำ
ทุกความผิดพลาดกลายเป็นกฎหนึ่งบรรทัด แล้ววางไว้ในที่ที่บังคับได้แรงที่สุด
check หรือ lint (ตอน 4 และ 7) แรงกว่า gate (ตอน 7) แรงกว่า template (ตอน 8) และแรงกว่าประโยคใน AGENTS.md (ตอน 4)
check ที่รันได้ ดีกว่าประโยคที่ต้องหวังว่า agent จะอ่าน
DORA เขียนว่า “an organizational culture that values learning contributes to software delivery performance”
บทเรียนเขียนแบบไม่โทษใคร เหมือน postmortem ของตอน 9 เพราะเป้าหมายคือแก้ระบบ
หน้าทบทวนของต้น สัปดาห์ที่ 30 นับจากเปิดบริษัท หน้าตาเป็นยังไง?
หน้าทบทวนวันศุกร์ 2026-11-06 (ตัวอย่าง):
| ส่วน | สัปดาห์นี้ |
|---|---|
| 1 งาน | เข้า 14 เสร็จ 11 ค้างเกิน 7 วัน 2 |
| 2 ด่าน | ข้าม 1 ครั้ง (hotfix ทบทวนแล้ว) |
| 3 drift | app-booking ไม่มี dependabot.yml |
| 4 incident | 0 ครั้ง restore test 2026-11-01 ผ่าน ใช้ 7 นาที |
| 5 เงิน | agent-build ใช้ 150 agent-research ผิดปกติวันพุธ |
| 6 คำขอลูกค้า | คำขอลบ #231 ครบกำหนดอีก 4 วัน |
| 7 ตัดสินใจ | (a) เพิ่มเพดาน agent-build เป็น $200 alert ที่ 50% ticket #81 (b) lint rule ห้าม add กับ drop column ใน migration เดียว ticket #82 (c) gardener เติม dependabot.yml ticket #83 |
แถวหนึ่งในบันทึกบทเรียน (ตัวอย่าง):
| วันที่ | เกิดอะไร | กฎใหม่ | เขียนลงที่ไหน | ตรวจว่าได้ผลเมื่อไหร่ |
|---|---|---|---|---|
| 2026-11-06 | migration add กับ drop ซ้ำครั้งที่ 3 | ห้าม add กับ drop column ใน migration เดียว | lint check ใน template | 2026-11-20 |
มาตรฐานว่ายังไง
ISO/IEC 29110 ระดับ Basic มีกระบวนการ Project Management ที่ครอบคลุมการติดตามและปรับแก้ระหว่างทาง
ISO/IEC/IEEE 12207 มี Quality management และ Knowledge management อยู่ในกลุ่ม Organizational project-enabling processes
ผมเทียบเอง: บริษัทใหญ่มีประชุม ops รายเดือน retrospective และ QA audit ต้นมี 30 นาทีต่อสัปดาห์ ทำได้เพราะตารางมีอยู่แล้ว และ agent เติมให้
จิ๊กซอว์ชิ้นที่เติมแล้ว
ชิ้นที่ 11 เติมแล้ว ระบบกลับมาดูตัวเองทุกสัปดาห์ และเรียนรู้เป็นลายลักษณ์อักษร
ช่วงที่ 3 เมื่อบริษัทโต จบที่ตอนนี้
สิ่งที่ผมได้จากตอนนี้
ลองทำเอง
ใช้เวลาราว 30 นาที ไม่เสียเงิน (ตัวอย่าง)
- คัดลอกหน้าทบทวน 7 ส่วนจากตารางข้างบน
- ให้ agent เติมส่วนที่ 1 และ 2 จาก GitHub issues และ PR ของ 7 วันที่ผ่านมา
- เลือกเรื่องที่จะตัดสินใจไม่เกิน 3 เรื่อง เขียนแต่ละเรื่องเป็น issue
- เปลี่ยนความผิดพลาดเก่าหนึ่งเรื่องเป็นกฎหนึ่งบรรทัดใน AGENTS.md หรือเป็น check
ผมลองแล้ว: __ นาที ฿0 agent สรุปถูก / ส่วน ตัดสินใจ __ เรื่อง กฎใหม่: __ อยู่ที่ __
เก็บศัพท์
- weekly review: รอบทบทวนรายสัปดาห์
- retrospective: การมองย้อนว่าจะทำงานให้ดีขึ้นยังไง
- SLO: เป้าหมายระดับบริการที่ตั้งไว้
- error budget: ส่วนที่ยอมให้พลาดจาก SLO ได้
- toil: งานมือที่ทำซ้ำและทำเป็นอัตโนมัติได้
- lessons learned: บทเรียนที่ได้
- drift: ของที่ค่อยๆ ไม่ตรงกับแบบที่ตั้งไว้
- decision log: บันทึกว่าตัดสินใจอะไร เพราะอะไร
- routine: งานที่ agent ทำตามเวลาหรือเหตุการณ์
จดบันทึก
ทุกสัปดาห์ 30 นาที ตัดสินใจไม่เกิน 3 เรื่อง บทเรียนกลายเป็นกฎ
ถ้าต้นเริ่มใหม่
ถ้าต้นเริ่มใหม่ เขาจะทำเรื่องนี้ตั้งแต่วันแรกไหม?
ช่อง 30 นาที: ทำ ตั้งแต่สัปดาห์แรก แม้มีแค่สองตาราง
ให้ agent สรุปมาให้: เมื่อมีตารางตั้งแต่ 3 ชุดขึ้นไป
บันทึกบทเรียน: ตั้งแต่ความผิดพลาดครั้งแรก
ตอนต่อไป
ต้นตัดสินใจเปิดบริษัทที่สองของตัวเอง เป็นแอปรับสั่งอาหารจัดเลี้ยง (ตัวอย่าง)
เขาเปิดหน้าว่างหน้าหนึ่ง แล้วถามตัวเองว่าถ้าเริ่มใหม่ วันแรกต้องมีอะไร
ตอนหน้า เราจะใช้บันทึกบทเรียนของตอนนี้ เป็นจุดเริ่มของบริษัทที่สอง
คำถามที่พบบ่อย
30 นาทีพอจริงไหม?
พอ ถ้า agent เติมส่วนที่ 1 ถึง 6 มาให้ เรื่องที่เกินกลายเป็น ticket
ทำงานคนเดียว ต้องทำ retrospective ด้วยหรือ?
ต้อง เพราะเป้าหมายคือปรับระบบ ไม่ใช่ปรับทีม
ให้ agent ตัดสินใจเองได้ไหม?
agent เสนอได้ แต่เรื่องที่เปลี่ยนเพดานหรือด่าน คนรับผิดชอบเป็นคนตัดสินใจ
กฎเยอะจน agent อ่านไม่หมดทำยังไง?
เปลี่ยนประโยคเป็น check ให้มากที่สุด และตัดกฎที่ไม่ใช้แล้วออกในรอบทบทวน
