การเปลี่ยนผ่านจาก Chat สู่ Backlog
เมื่อสามเดือนก่อน การจัดการงานของผมเป็นเพียงแค่หน้าต่างแชท ถ้าผมปิดแท็บไป แผนงานทั้งหมดก็หายไป
ทุกวันนี้ มันกลายเป็น Postgres backlog โดยมี AI agent สามตัวที่แตกต่างกัน ได้แก่ Claude Code, Codex และ Grok คอยดึงงานจากที่นั่น พวกมันจะระบุที่มา (attribution) และปิดงานโดยอ้างอิงจาก git history
ผมไม่ได้ตั้งใจจะสร้างระบบจัดการโปรเจกต์ขึ้นมาตั้งแต่แรก ผมแค่เจอกับอุปสรรคซ้ำแล้วซ้ำเล่า ทุกครั้งที่ผมแก้ปัญหาหนึ่งได้ ปัญหาใหม่ก็โผล่ขึ้นมาเสมอ
งานของผมหนักมาก ผมรันแพลตฟอร์มข้อมูลส่วนตัวที่ชื่อว่า Nexus ผมดูแล repository ประมาณ 100 แห่ง ในช่วงเวลาหนึ่ง ผมส่งมอบโค้ดถึง 557,000 บรรทัดภายใน 35 วัน ปริมาณงานขนาดนั้นทำให้วิธีการวางแผนทุกอย่างที่ผมเคยลองใช้พังไม่เป็นท่า
นี่คือวิวัฒนาการของระบบของผม:
Phase 1: Conversational Planning แผนงานอาศัยอยู่ในประวัติการแชท ผมจะคิดดังๆ เมื่อได้ไอเดียดีๆ ก็จะเริ่มลงมือสร้างทันที
- ปัญหา: แผนงานจะระเหยหายไปเมื่อการแชทสิ้นสุดลง คุณไม่สามารถจัดลำดับความสำคัญ หรือส่งต่องานให้คนอื่นได้
Phase 2: Per-Repo TODO Files ผมเริ่มใช้ไฟล์ TODO.md ในทุก repository ผมเลิกใช้รายการตรวจสอบ (checklist) แบบง่ายๆ แต่เปลี่ยนมาเขียนเป็นข้อกำหนด (specs) สั้นๆ แทน แต่ละรายการประกอบด้วย:
- สถานะและวันที่
- ตัวกระตุ้น (trigger) (ทำไมเรื่องนี้ถึงกลายเป็นเรื่องด่วน)
- ขั้นตอนที่ตัดสินใจไว้ล่วงหน้า (แผนงาน)
- ความเสี่ยงที่ทราบ
- ปัญหา: ด้วยจำนวน 100 repos ผมจึงไม่มีภาพรวม (global view) ผมไม่สามารถมองเห็นทุกสิ่งที่ต้องทำได้ในที่เดียว
Phase 3: The Operator Backlog (OB) ผมย้ายงานเข้าไปอยู่ในฐานข้อมูล Postgres ซึ่งทำให้เกิดคิวงานส่วนกลาง (global queue) ผมเพิ่มด่านการอนุมัติ (approval gate) งานจะกลายเป็นงานจริงก็ต่อเมื่อผมตรวจสอบแล้วเท่านั้น วิธีนี้ช่วยป้องกันไม่ให้ AI ส่งขยะเข้ามาใน backlog ผมใช้สถานะ (status lanes) ดังนี้:
- requires_triage
- requires_decision
- requires_investigation
- autonomous_safe
- ปัญหา: ผมกลายเป็นคอขวดเสียเอง ผมไม่สามารถเคลียร์งานในแต่ละสถานะได้เร็วพอ
Phase 4: Multi-Agent Execution ตอนนี้ backlog กลายเป็นคิวงานที่ใช้ร่วมกันสำหรับ AI agent หลายตัว
- พวกมันใช้ lease เพื่อไม่ให้ทำงานซ้ำซ้อนในงานเดียวกัน
- พวกมันใช้ attribution เพื่อให้ผมรู้ว่าใครทำอะไร
- พวกมันสามารถส่งต่องานกันได้ เช่น agent ตัวหนึ่งอาจพบว่างานนั้นเป็นไปไม่ได้และสร้างงานที่เป็นเงื่อนไขก่อนหน้า (prerequisite) ขึ้นมา จากนั้น agent ตัวที่สองก็สามารถมารับงานเงื่อนไขนั้นไปทำต่อจนเสร็จสิ้นงานเดิมได้
บทเรียนนี้เรียบง่ายมาก: คุณไม่จำเป็นต้องไปถึง Phase 4 ก็ประสบความสำเร็จได้
หากคุณจะหยิบยืมสิ่งหนึ่งไปใช้ ให้หยิบรูปแบบของ Phase 2 ไป จงเขียนงานของคุณโดยระบุสถานะ, ตัวกระตุ้น (trigger), ขั้นตอนที่ตัดสินใจไว้ล่วงหน้า และความเสี่ยง มันไม่มีต้นทุนอะไรเลย แต่จะเปลี่ยนทุกอย่าง
กฎที่สำคัญที่สุดคือสิ่งนี้: จงวางแผนบนพื้นฐานของความจริงเสมอ อย่าวางแผนโดยอิงจากการคาดเดาหรือการสรุปความเพียงอย่างเดียว แผนการที่สมบูรณ์แบบซึ่งสร้างขึ้นจากข้อมูลที่ล้าสมัย จะล้มเหลวรวดเร็วพอๆ กับการไม่มีแผนเลย
ชุมชนแห่งการเรียนรู้เพิ่มเติม: https://t.me/GyaanSetuAi