เราอยู่ตรงไหนของแผนที่#

บนแถบ 5 ขั้น Requirements สว่างอีกรอบ

รอบนี้ requirement มาจากลูกค้า ไม่ใช่จากหัวต้น แล้วไหลเข้า Build

ชิ้นจิ๊กซอว์ที่ 5 รับงานและอนุมัติ คือเรื่องที่ 11 ช่องรับงานและวางแผน เรื่องที่ 12 ทำงานร่วมกันและส่งต่องาน และเรื่องที่ 13 review และอนุมัติ

ตอนนี้เปิดช่วงที่ 2 ช่วงที่มีลูกค้าจริง

หัวใจของตอนนี้#

งานที่ไม่ได้เขียนลงที่เดียว สำหรับ agent คืองานที่ไม่มีอยู่จริง

ทำไมเรื่องนี้สำคัญ?#

ตอน 5 บอกแล้วว่าใครหรือ agent ตัวไหนทำอะไรได้

แต่ยังไม่มีอะไรบอกว่างานแต่ละชิ้นคืออะไร ใครขอ และเสี่ยงแค่ไหน

ถ้าไม่มีช่องเดียว งานหายในแชท ทำซ้ำสองรอบ ลูกค้าไม่รู้ว่าถึงไหน

และด่านในตอน 7 ก็ไม่รู้ว่าต้องเข้มแค่ไหน

ทางแก้คือทุกงานมีที่อยู่เดียวที่ agent อ่านได้

หลัก 5 ข้อข้างล่างคือวิธีไปถึงตรงนั้น

วันที่งานหายไปในแชท#

เพื่อนสามคนของต้นเริ่มจ่ายเงินแล้ว

วันจันทร์ 08:10 ฝนขอ export CSV ทาง LINE (ตัวอย่าง)

11:30 มิวส่ง email แจ้ง bug

บ่ายนั้นมีคนแปลกหน้าตอบใน X ว่า login บน Safari ไม่ได้

ถึงวันศุกร์มีคำขอ 23 เรื่อง 4 เรื่องไม่มีใครทำ 2 เรื่องถูกทำซ้ำโดย agent สองตัว (ตัวอย่าง)

ฝนถามว่า “ที่ขอไปเมื่อวันจันทร์ถึงไหนแล้ว”

ไม่มีใครตอบได้

agent ทำงานได้ 24 ชั่วโมง แต่ข้อความใน LINE ไม่มีอยู่จริงสำหรับมัน

ตารางสิทธิ์บอกว่าใครทำได้ แต่ใครทำอะไรอยู่?#

ตอน 5 ตั้งชื่อให้ agent ทุกตัวแล้ว

ตอนนี้งานทุกชิ้นต้องมีชื่อด้วย

log จะได้เขียนว่า “agent-build ทำ ticket #41 ที่ฝนขอ” (ตัวอย่าง)

ถ้าไม่มี ticket สามอย่างจากตอน 4 คือกฎ ระบบบังคับ และ log ก็ไม่มีอะไรให้ชี้ไปหา

หลัก 1: ช่องเดียว ทุกคำขอเป็น ticket#

ข้อนี้คือหัวใจตรงๆ งานต้องมีที่อยู่เดียว ไม่อย่างนั้น agent ไม่เห็น

ทุกช่องส่งต่อเข้าคิวเดียว เช่น GitHub Issues หรือ Linear

DORA อธิบาย visibility of work ว่า “represents the extent to which teams have a good understanding of the flow of work from the business all the way through to customers”

lauren (@poteto) เขียนไว้ ว่า “send feature requests to your issue tracker, bug reports to a cursor cloud agent or project to triage and fix”

อีก โพสต์ เธอเล่า loop ที่ใช้ทุกวัน ข้อ 1 “watch this slack channel for feedback about our app” ข้อ 2 “create a ticket for this in Linear”

เธอเรียกช่วงนี้ว่า “the first and the last mile of getting work done”

ส่งต่อจาก LINE ยังไงเป็นเรื่องเลือกเครื่องมือ จะใช้ bot ใช้ copy-paste หรือให้ agent ทำเป็น routine ก็ได้

กฎมีข้อเดียว ยังไม่เป็น ticket ยังไม่มีใครทำ

หลัก 2: ticket ที่ agent หยิบได้เอง#

มีที่อยู่แล้วยังไม่พอ agent ต้องอ่านแล้วรู้เลยว่าต้องทำอะไร

ticket ที่ดีมีปัญหา มีข้อเช็กว่าเสร็จเมื่อไหร่ และมีลิงก์กลับไปข้อความต้นทาง

GitHub issue forms เขียนว่า “You can define different input types, validations, default assignees, and default labels for your issue forms”

เลข ticket ใส่ในชื่อ PR ด้วย

บทความบน dev.to เตือนว่า “If your ticket IDs are not in your commit messages or PR titles, you are going to be reconstructing this by hand”

นี่คือข้อต่อแรกของสาย ticket → PR → review และ CI → deploy ที่ผู้ตรวจจะเดินตาม

หลัก 3: ระดับความเสี่ยงมาจากกฎ ไม่ใช่ความรู้สึก#

งานที่มีที่อยู่แล้ว ต้องบอกได้ด้วยว่าเสี่ยงแค่ไหน และระดับนั้นต้องเขียนลงที่เดียวกัน ไม่ใช่อยู่ในหัว agent

ต้นแบ่งสามระดับ

• low: ข้อความ, CSS, docs
• medium: logic ที่มี test
• high: auth, secret, การจ่ายเงิน, ลบข้อมูล, schema, infra

ระดับมาจากรายการ path และ label ที่แน่นอน

actions/labeler คือ “An action for automatically labelling pull requests”

CODEOWNERS ก็ทำให้ “Code owners are automatically requested for review when someone opens a pull request that modifies code that they own”

เรื่องจริงจาก Rewind

ทีม Rewind เขียนเล่า ระบบ AI reviewer ชื่อ Diff Vader ที่อนุมัติ PR เองได้เฉพาะ “a carefully bounded set of low-risk changes”

เขาบอกว่า “risk is not size” ยกตัวอย่าง “A twelve-line database migration that adds an index to a fifty-million-row table is one of the most dangerous things you can ship”

และเขียนกฎไว้ชัดว่า “Security-sensitive changes can never be auto-approved”

กับอีกข้อ “a PR authored by a non-human (an agent, a bot) can be reviewed by Diff Vader but can never be merged without a human clicking the button”

lauren ก็ เล่า ว่าที่ทีมเธอ “every PR gets assessed for risk. low-medium risk ones don’t require a review so you just merge it”

ของต้นเข้มกว่านั้น เพราะมีลูกค้าจ่ายเงินและไม่มีทีม

agent เสนอระดับได้ แต่กฎ path ทำได้แค่ดันระดับขึ้น ไม่ให้ลง

หลัก 4: งานในมือน้อยลง ส่งต่อชัดขึ้น#

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

agent 8 ตัวเริ่มงานได้ 8 อย่าง แต่ต้นมีตาคู่เดียว (ตัวอย่าง)

งานที่ค้างในคิวโดยไม่มีใครดู ก็ใกล้เคียงกับงานที่ไม่มีอยู่จริง

DORA เรื่อง WIP limits เขียนว่า “Only by imposing WIP limits and following this pull-based process do you actually create a Kanban board”

กฎของต้น agent ละไม่เกิน 3 ticket ที่ in progress และงาน high เปิดพร้อมกันไม่เกิน 2 (ตัวอย่าง)

ส่งต่องานใช้สถานะ ticket กับ comment หนึ่งข้อความ ไม่ใช่ “บอก agent ใน chat แล้ว”

ลูกค้าได้คำตอบทางเดียว คือลิงก์ ticket หรือข้อความสถานะที่สร้างจาก ticket

หลัก 5: ใครอนุมัติขึ้นกับระดับ#

งานที่มีที่อยู่และมีระดับแล้ว ช่องคนอนุมัติก็อยู่ใน ticket เดียวกัน

คอลัมน์ “ใครอนุมัติ” ใช้ต่อจากช่อง “ต้องอนุมัติ” ในตารางตอน 5

OWASP แนะนำให้ “require a human to approve high-impact actions before they are taken”

DORA บอกว่าการอนุมัติ change “best implemented through peer review during the development process, supplemented by automation”

ด่านบังคับยังไง เก็บไว้ตอนหน้า

ช่องรับงานและตารางระดับของต้นหน้าตาเป็นยังไง?#

ticket ตัวอย่างหนึ่งแถว (ตัวอย่าง)

#41 · ฝน (ลิงก์ LINE) · export CSV ของรายการเดือนนี้ · เสร็จเมื่อ: ไฟล์เปิดใน Excel ได้ ภาษาไทยไม่เพี้ยน · area: reports · ระดับ: low · agent-build · in progress

ตารางระดับ (ตัวอย่าง)

มาตรฐานว่ายังไง

ISO/IEC TR 29110-5-1-2 (ฉบับปี 2011) มีเป้าหมายข้อหนึ่งของ Project Management เขียนว่า “The Change Requests are addressed through their reception and analysis.” และมี Project Assessment and Control ที่ติดตามความคืบหน้าเทียบกับแผน

12207 มีกลุ่ม Agreement processes ระหว่างลูกค้ากับผู้ทำ และ Project assessment and control ในกลุ่ม Technical management

SOC 2 มีหมวด change management และ Rewind ก็ผูกกฎ “คนต้องกดเอง” ของเขาเข้ากับหมวดนี้

ข้อนี้ผมเทียบเอง คิวกับตารางระดับของต้น ก็คือบันทึก change request ที่บริษัทใหญ่เก็บใน Jira บวกกฎของ CAB แค่ไม่ต้องประชุมครับ

จิ๊กซอว์ชิ้นที่เติมแล้ว#

ชิ้นที่ 5 รับงานและอนุมัติ เติมแล้ว

ทุกคำขอมีเลข มีเจ้าของ และมีระดับ

ชิ้นถัดไปคือด่านที่ข้ามไม่ได้ กับทางถอยกลับ

สิ่งที่ผมได้จากตอนนี้#

ตอนต่อไป#

ศุกร์ 18:00 PR ของ ticket ระดับ high ที่มี migration ถูก merge ไป (ตัวอย่าง)

เหตุผลคือ “check ผ่านแล้ว” แต่ไม่มีใครดูว่า ticket นี้ระดับ high และยังไม่มีใครกดอนุมัติ

ตอนหน้า ระดับในตารางนี้จะกลายเป็นด่านที่ข้ามไม่ได้ พร้อมทางถอยกลับและทางฉุกเฉิน

คำถามที่พบบ่อย#

ลูกค้าต้องมาใช้ GitHub ไหม?

ไม่ต้อง ลูกค้าใช้ LINE หรือ email เหมือนเดิม เราส่งต่อเข้าคิวเอง

agent จัดระดับเองได้ไหม?

เสนอได้ แต่กฎ path ดันขึ้นได้อย่างเดียว

ทำคนเดียวต้องมี WIP limit ไหม?

ต้องมี เพดานคือเวลาของต้น ไม่ใช่จำนวน agent

ticket เล็กๆ ต้องเปิดไหม?

เปิด ticket บรรทัดเดียวใช้นาทีเดียว แลกกับหลักฐานย้อนหลังทั้งสาย

Next → ภาค 2 ตอนที่ 7: ผ่านด่านและถอยได้