เมื่อก่อน Backlog ของคุณเป็นแค่ลิสต์ที่คุณกับเพื่อนร่วมทีมไม่กี่คนช่วยกันดึงงานออกมาทำ คุณอ่านรายการบนสุด เข้าใจมัน แล้วลงมือทำ การคัดกรองจึงเร็ว เพราะคำถามเดียวคือ "ใครมีเวลา?" ตอนนี้บางรายการในนั้นให้เอเจนต์เขียนโค้ดหยิบไปทำแทนคนได้แล้ว คิวที่เคยสงบเงียบก็กลายเป็นแหล่งรวมความผิดพลาดเล็ก ๆ ที่ราคาแพง เอเจนต์เริ่มทำงานที่ยังไม่มีใครเขียนให้จบ เอเจนต์สองตัวแย่งงานที่ทับซ้อนกัน และคอลัมน์ "เสร็จแล้ว" ก็เต็มไปด้วยผลลัพธ์ที่ไม่มีใครสั่ง
ปัญหาอยู่ที่เอเจนต์ไม่ใช่ แต่เป็นเพราะ Backlog ที่สร้างมาเพื่อมนุษย์นั้นเปลี่ยนบทบาทไปอย่างเงียบ ๆ มันเลิกเป็นลิสต์สิ่งที่ต้องทำ แล้วกลายเป็นคิวสำหรับสั่งงานที่เริ่มการทำงานได้จริง เมื่อรายการหนึ่งสามารถจุดชนวนให้เกิดงานจริงได้ โมเมนต์ที่คุณย้ายงานกับโมเมนต์ที่คุณตัดสินใจว่าใครเป็นเจ้าของงาน ก็มีผลตามมาที่ไม่เคยมีมาก่อน
นี่คือเลเยอร์ที่ Sharkly เข้ามาอยู่ คุณมีเอเจนต์เขียนโค้ดอยู่แล้ว Sharkly เปลี่ยนพวกมันให้เป็นทีม ด้วยการทำให้ Backlog มีความหมายร่วมกัน Task คือหน่วยหลักของงาน Backlog คือที่ที่งานที่ยังไม่ผูกมัดรออยู่ และ Triage คือคิวรับงานโดยเฉพาะที่รายการใหม่ ๆ เข้ามารอจนมีคนตัดสินใจ บทความนี้จะพาดูวิธีคัดกรอง Backlog ที่ปนกันระหว่างคนกับเอเจนต์โดยไม่ให้คิวเหล่านั้นกลายเป็นความวุ่นวาย และปิดท้ายด้วยเช็กลิสต์ที่คุณนำไปใช้ได้วันนี้
Backlog และ Triage หมายถึงอะไร เมื่อเอเจนต์ทำงานได้เอง
คำจำกัดความสองข้อนี้ทำงานหนักที่สุดในเรื่องนี้ เพราะฉะนั้นทำความเข้าใจให้แม่น
Backlog คือชุดของงานที่ยังไม่ผูกมัด นั่นคืองานที่มีอยู่แต่ยังไม่มีใครตัดสินใจเริ่มลงมือ Triage คือการตัดสินใจรับงานเข้าสำหรับรายการใหม่หรือรายการที่ยังคลุมเครือ จะรับ ปฏิเสธ ทำเครื่องหมายว่าซ้ำ หรือเลื่อนไปก่อน มนุษย์ทำทั้งสองอย่างแบบไม่เป็นทางการมาตลอด สิ่งที่เปลี่ยนไปคือ ในทีมที่ผสมคนกับเอเจนต์ ผลลัพธ์ของ Triage ตอนนี้รวมคำถาม "เอเจนต์ตัวไหนจะรันงานนี้" เข้าไปด้วย และการผูกมัดงานก็สามารถเริ่มการรันได้เลย
นี่คือเส้นแบ่งที่ทำให้คนสับสนเป็นข้อแรก: การมอบหมาย Agent ให้กับงานใน Backlog ไม่ได้เริ่มงานนั้น Backlog คือพื้นที่จอดรถที่งานถูกเตรียมให้พร้อมก่อนลงมือทำ การรันจะเริ่มก็ต่อเมื่องานออกจาก Backlog ไปสู่สถานะที่พร้อมทำงาน และมี Computer กับ Runtime ว่างอยู่ ดังนั้น "มอบหมายเอเจนต์" กับ "เริ่มเอเจนต์" จึงเป็นสองเหตุการณ์ที่แยกจากกัน โดยมีสถานะ Backlog คั่นอยู่ตรงกลางเป็นประตู
อีกเส้นแบ่งหนึ่งที่ควรพูดให้ชัด: เอเจนต์ไม่มี Backlog ส่วนตัว ไม่มีคิวลับที่ Agent ค่อย ๆ ตะลุยไปเอง ทุกรายการที่ Agent จะแตะอยู่ในบอร์ดร่วมทั้งนั้น ซึ่งเป็นสิ่งที่ทำให้การคัดกรองเป็นไปได้จริงแทนที่จะต้องเดา
จุดที่การตั้งค่าแบบ DIY ไปต่อไม่ได้
สเปรดชีตบวกบอร์ด Kanban บวกเทอร์มินัลไม่กี่หน้าต่าง ใช้ได้ดีสำหรับคนหนึ่งคนกับเอเจนต์สองตัว แต่มันไปต่อไม่ได้ที่จุดที่คาดเดาได้ และแต่ละจุดก็โผล่มาในรูปแบบความล้มเหลวที่เฉพาะเจาะจง
คอลัมน์สถานะไม่มีความหมายอะไรกับเอเจนต์ บนบอร์ดที่ทำมือ การย้ายการ์ดไปที่ "In Progress" เป็นแค่การบอกเพื่อนร่วมทีม ไม่มีอะไรถูกสั่งให้ทำงานจริง บอร์ดกับงานจริงจึงค่อย ๆ ห่างกัน การ์ดบอกว่า "In Progress" ทั้งที่เอเจนต์ทำเสร็จไปชั่วโมงแล้ว หรือบอกว่า "To Do" ทั้งที่เอเจนต์คอมมิตไปสามครั้งแล้ว เพราะมีคนไปสั่งรันในเทอร์มินัล ไม่มีใครเชื่อบอร์ด ก็เลยไม่มีใครใช้มัน
การตัดสินใจใน Triage อยู่ในหัวของคนคนเดียว ใครก็ตามที่รับเรื่องที่เข้ามาจะจำได้ว่าบั๊กนี้มีคนรายงานไปแล้ว ฟีเจอร์นี้ถูกปฏิเสธไปเมื่อไตรมาสที่แล้ว งานนี้ต้องรอ input จากฝ่ายดีไซน์ก่อน พอคนคนนั้นไม่อยู่ ก็มีรายการซ้ำถูกสร้างขึ้น และเอเจนต์ก็เริ่มทำงานที่ควรถูกปฏิเสธตั้งแต่ตอนรับเข้า คิวไม่มีความจำ
การมอบหมายกับขอบเขตงานถูกตัดสินในจังหวะเดียวกันที่รีบร้อน ขอบเขตงานที่คลุมเครือพออยู่ได้เมื่อคนเป็นคนหยิบงานขึ้นมาแล้วถามกลับ เอเจนต์ไม่หยุดถาม มันรันไปตามสิ่งที่คุณให้ แล้วส่งผลลัพธ์ที่มั่นใจแต่ผิดกลับมา ต้นทุนของ Triage แบบบาง ๆ จึงย้ายจาก "เพื่อนร่วมทีมงงไปแป๊บหนึ่ง" ไปเป็น "เอเจนต์เผาการรันหนึ่งรอบกับรอบรีวิวหนึ่งรอบไปกับเรื่องผิด ๆ"
คัดกรอง Backlog แบบผสม ทีละขั้นตอน
นี่คือลำดับที่ทำให้ Backlog ของคนกับเอเจนต์ยังซื่อสัตย์ แต่ละขั้นจะบอกว่ามันป้องกันความล้มเหลวอะไร
1. เคลียร์คิวรับงานก่อนแตะ Backlog คำขอใหม่จะเข้าที่ Triage ไม่ใช่เข้าตรงไปที่ Backlog จัดการแต่ละรายการด้วยหนึ่งในสี่การตัดสินใจ: รับ ปฏิเสธ ทำเครื่องหมายว่าซ้ำ หรือเลื่อนไปก่อน Triage คือคิวรับงาน ไม่ใช่ฟิลเตอร์ที่บันทึกไว้และไม่ใช่ตัวสร้างฟอร์ม การตัดสินใจจึงชัดเจนและถูกบันทึกไว้ ความล้มเหลวที่ป้องกันได้: งานที่ถูกปฏิเสธและงานซ้ำค่อย ๆ กลายเป็นงานจริงที่เอเจนต์ไปหยิบเข้าทีหลัง
2. ปั้นงานให้เป็นรูปเป็นร่างก่อนที่มันจะพร้อมให้เอเจนต์ทำ รายการที่รับเข้ามาจะกลายเป็น Task แต่ยังอยู่ใน Backlog ระหว่างที่คุณเขียนเกณฑ์การยอมรับ แนบ repository และระบุข้อจำกัด นี่คือขั้นที่คนมักข้ามตอนเวลาไล่หลัง ความล้มเหลวที่ป้องกันได้: เอเจนต์รันจากชื่อเรื่องบรรทัดเดียว แล้วส่งผลลัพธ์ที่ตรงตามตัวอักษรแต่พลาดเจตนาไปเลย
3. ตัดสินใจว่าใครรับงาน และมอง "เอเจนต์ตัวไหน" เป็นทางเลือกจริง ๆ บางงานต้องการคน บางงานต้องการเอเจนต์ และในบรรดาเอเจนต์ด้วยกัน ตัวที่เหมาะก็ขึ้นอยู่กับงาน ทั้งการรีแฟกเตอร์ การเขียนเทสต์ และการอัปเดตเอกสาร ล้วนไม่ใช่งานแบบเดียวกัน จงกำหนดเส้นทางอย่างตั้งใจ อย่าปล่อยให้เป็นเอเจนต์ที่ว่างอยู่เป็นค่าเริ่มต้น คู่มือการเลือกเส้นทางสำหรับเอเจนต์เขียนโค้ดของเราครอบคลุมวิธีตัดสินใจเรื่องนี้ ความล้มเหลวที่ป้องกันได้: รันไทม์ผิดตัวมาเคี้ยวงานที่มันไม่ถนัด
4. เก็บไว้ใน Backlog จนกว่าจะพร้อมจริง ๆ นี่คือประตู งานหนึ่งสามารถถูกมอบหมายครบถ้วนแล้วและยังนั่งอยู่ใน Backlog โดยไม่มีการรันใด ๆ เริ่มขึ้น ใช้ประโยชน์จากตรงนี้ อย่าเพิ่งย้ายมันออกจนกว่าขอบเขตจะชัดและคุณอยากให้งานเริ่มจริง ๆ ความล้มเหลวที่ป้องกันได้: งานที่เขียนค้างไว้ครึ่ง ๆ กลาง ๆ ปล่อยการรันออกมา เพราะมีคนลากมันไปผิดคอลัมน์
5. ผูกมัดงาน แล้วปล่อยให้การรันเริ่ม ย้ายงานไปยังสถานะที่พร้อม หรือดึงมันเข้า Sprint เมื่อ Task ที่มี Agent พร้อมอยู่ ออกจาก Backlog และมี Computer กับ Runtime ว่าง การทำงานก็เริ่มขึ้น ตอนนี้การเปลี่ยนสถานะกับตัวงานเป็นเหตุการณ์เดียวกัน ซึ่งนั่นคือประเด็นทั้งหมด
สำหรับทีมที่ทำงานเป็นรอบ การวางแผน Sprint สำหรับทีมที่ผสมคนกับเอเจนต์ แสดงให้เห็นว่าขั้นตอนการผูกมัดเดียวกันนี้กำหนดกรอบเวลาแทนที่จะเป็นงานเดี่ยวได้อย่างไร
สถานะ Backlog กลายเป็นประตูสู่การลงมือทำ
การปรับมุมมองคือแบบนี้ บนบอร์ดของคน สถานะเป็นป้ายที่อธิบายความจริง บนบอร์ดของคนกับเอเจนต์ สถานะเป็นคันโยกที่เปลี่ยนความจริง การย้ายงานออกจาก Backlog คือการกระทำที่เริ่มเอเจนต์ วินัยในการคัดกรองของคุณจึงกลายเป็นกลไกความปลอดภัยของคุณ
ประตูนี้ยังเป็นที่ที่สัญญาระหว่างคนกับเอเจนต์ควรอยู่ด้วย เอเจนต์ค้นคว้า ลงมือทำ ทดสอบ และรายงาน คนตัดสินใจว่าอะไรเข้าสู่ Backlog อะไรถูกผูกมัด และอะไรถูกปล่อยออกไป ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้ดุลยพินิจของทีม มุมมอง Plan เก็บ Backlog, Sprint และ Project ไว้ในที่เดียว เพื่อให้การตัดสินใจผูกมัดมองเห็นได้ แทนที่จะฝังอยู่ในเทอร์มินัล และการทำงาน อุปสรรค ผลลัพธ์ และการรีวิว ล้วนกลับมาที่ Task แทนที่จะกระจัดกระจายไปตามเซสชันส่วนตัว
นี่คือเหตุผลว่าทำไมสุขอนามัยของ Backlog จึงสำคัญขึ้นเมื่อมีเอเจนต์ ไม่ใช่ลดลง Backlog ของคนที่รกก็แค่ความยุ่งเหยิง แต่ Backlog ของเอเจนต์ที่รกคือความยุ่งเหยิงที่บางครั้งรันตัวเองได้ บอร์ดช่วยให้บริบท ความเป็นเจ้าของ ความคืบหน้า ผลลัพธ์ และการรีวิวโดยคน มองเห็นได้ตั้งแต่รับเข้าจนถึงปล่อยออก ซึ่งเป็นความต่างระหว่างคิวที่คุณจัดการ กับคิวที่จัดการคุณ เมื่องานรีวิว piled up แทนที่จะเป็นงานรับเข้า นั่นคือคอขวดอีกแบบหนึ่ง ซึ่งครอบคลุมไว้ใน ทำไมการรีวิวโดยคนถึงเป็นข้อจำกัดตัวจริง
คุณรันแบบนี้ด้วยสเปรดชีตกับวินัยแบบทำมือได้ ถ้าปริมาณงานของคุณต่ำ แต่ถ้าคุณรับเรื่องเข้ามาเรื่อย ๆ อยู่แล้วและรันเอเจนต์หลายตัว Sharkly ให้คิว Triage ประตู Backlog และบอร์ดร่วมหนึ่งเดียว เพื่อให้การตัดสินใจเหล่านั้นเลิกอยู่ในหัวคุณ สำหรับมุมมองที่กว้างขึ้นของเวิร์กโฟลว์เดียวกัน ดูคู่มือของเราเรื่อง การจัดการงานของเอเจนต์ AI และความต่างระหว่าง Triage กับ Inbox ส่วนตัวของคุณ
เช็กลิสต์การคัดกรองที่คุณใช้ได้วันนี้
ลองไล่เช็กลิสต์นี้กับบอร์ดปัจจุบันของคุณ ทุกคำว่า "ไม่" คือจุดที่เอเจนต์จะทำให้คุณประหลาดใจ
- คำขอใหม่เข้ามารอที่ไหนสักแห่งก่อนถึง Backlog หรือไม่? ถ้างานรับเข้าไปตรงที่ "To Do" เลย คุณไม่มีขั้นตอนรับ/ปฏิเสธ/ทำเครื่องหมายว่าซ้ำ และงานซ้ำก็เลี่ยงไม่ได้
- ขอบเขตของทุกงานใน Backlog ดีพอจะมอบให้คนแปลกหน้าได้ไหม? ถ้ามันไม่ดีพอสำหรับพนักงานใหม่ ก็ไม่ดีพอสำหรับเอเจนต์
- การย้ายงานเริ่มต้นอะไรจริง ๆ ไหม? ถ้าการเปลี่ยนสถานะของคุณเป็นแค่ป้าย บอร์ดกับงานจริงจะค่อย ๆ ห่างกัน
- การมอบหมายเป็นการตัดสินใจจริงหรือไม่ รวมถึงเลือกด้วยว่าเอเจนต์ตัวไหน? การปล่อยให้เป็นเอเจนต์ที่ว่างอยู่ไม่ใช่การกำหนดเส้นทาง
- ตอนนี้คุณบอกได้ไหมว่าเอเจนต์แต่ละตัวกำลังทำอะไร และมีอะไรกำลังรอรีวิว? ถ้าคำตอบอยู่ในความจำของใครสักคนหรือใน scrollback ของเทอร์มินัล Triage ก็ไม่มีแหล่งความจริงร่วมกัน
- งานที่เสร็จกลับมาที่ Task ไม่ใช่ไปที่เซสชันส่วนตัวหรือไม่? ผลลัพธ์ อุปสรรค และ diff ควรอยู่ในบันทึกร่วม เพื่อให้การรีวิวมีอะไรให้ลงมือทำ
แก้สองข้อแรกก่อนที่คุณจะขยายจำนวนเอเจนต์ ขั้นตอนรับเข้าที่สะอาดและขอบเขตงานที่ซื่อสัตย์ป้องกันความล้มเหลวราคาแพงส่วนใหญ่ไว้ได้ ที่เหลือเป็นเพียงการขัดเกลาบนพื้นฐานของ Backlog ที่มีความหมายอยู่แล้ว
