เส้นทาง 01บทเรียน 5 / 6

วัดความก้าวหน้าที่มีประโยชน์

วัดงานที่เสร็จ แรงงานที่ใช้ตรวจทาน และงานที่ต้องทำใหม่ อย่าใช้ปริมาณโค้ดที่สร้างเป็นตัววัดคุณค่า

พื้นฐาน9 minตรวจทานแล้ว 5 ต.ค. 2569

เผยแพร่โดย Taigaวิธีเขียนเนื้อหาของเรา

ตรวจความเข้าใจAI ลดเวลาพัฒนาจาก 60 เป็น 30 นาที แต่เวลาตรวจทานเพิ่มจาก 10 เป็น 45 นาที สรุปอะไรได้ทำแบบฝึกหัด

แสดงคำตอบ

การคำนวณรวมทั้งสองช่วงแล้ว แต่การเปรียบเทียบที่ครบถ้วนยังต้องมีข้อมูลคุณภาพ การเตรียมงาน และการแก้ไข

สิ่งที่จะได้เรียนรู้

แยกกิจกรรมออกจากผลลัพธ์ที่มีประโยชน์
รวมการเตรียมงาน การตรวจทาน และการแก้ไขในการเปรียบเทียบเวลา
สังเกตข้อจำกัดของข้อกล่าวอ้างด้านผลิตภาพ

กำหนดผลลัพธ์ก่อนตัวชี้วัด

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

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

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

นับงานทั้งหมด

พิจารณาตัวอย่างสมมติของการเปลี่ยนตัวกรองรายงาน หากไม่ใช้ AI การพัฒนาใช้ 60 นาที และการตรวจทานใช้ 10 นาที หากใช้ AI การพัฒนาใช้ 30 นาที และการตรวจทานใช้ 45 นาที

การพัฒนาเร็วขึ้น แต่เวลาทำงานที่วัดได้สำหรับช่วงเหล่านี้เพิ่มจาก 70 เป็น 75 นาที ผลทั้งสองยังไม่รวมการเตรียมงาน การแก้ไขภายหลัง หรือข้อบกพร่องหลังออก release ระบุข้อจำกัดเหล่านี้ให้ชัดเจน

ช่วงงาน	ตัวอย่างที่ไม่ใช้ AI	ตัวอย่างที่ใช้ AI
การพัฒนา	60 นาที	30 นาที
การตรวจทาน	10 นาที	45 นาที
เวลารวมที่วัดได้	70 นาที	75 นาที

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

แยกเวลาทำงานออกจากเวลาที่ผ่านไป

เวลาทำงานวัดเวลาที่คนใช้ทำงาน ส่วนเวลาที่ผ่านไปทั้งหมดรวมเวลารอด้วย Agent รันการตรวจสอบได้ขณะที่ developer ทำงานอื่น อย่านับเวลาของคนช่วงเดียวกันซ้ำ บันทึกด้วยว่าการเปลี่ยนแปลงรอการตรวจทานหรือสภาพแวดล้อมนานเท่าใด

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

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

อ่านงานวิจัยโดยคำนึงถึงข้อจำกัด

METR รายงานว่าการทำงานช้าลงในการศึกษาเฉพาะกลุ่มช่วงต้นปี 2025 ซึ่งศึกษานักพัฒนา open source ที่มีประสบการณ์ การศึกษานี้ไม่ได้ยืนยันผลกับ developer หรืองานทุกประเภท ข้อมูลอัปเดตเดือนกุมภาพันธ์ 2026 อธิบายผลจากการคัดเลือกและปัญหาการวัดในการทดลองครั้งต่อมา

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

งานวิจัยปี 2025 ของ DORA ยังชี้ให้มององค์กรที่แวดล้อมเครื่องมือด้วย ทีมต้องมีแนวปฏิบัติการพัฒนาที่มีประสิทธิผลเพื่อเปลี่ยนความสามารถของเครื่องมือให้เป็นผลการส่งมอบที่มีประโยชน์

เปรียบเทียบในขอบเขตเล็กที่ทำซ้ำได้

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

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

การวัดที่ดีช่วยตัดสินใจขั้นถัดไปอย่างเจาะจง ไม่จำเป็นต้องพิสูจน์ว่า AI ดีหรือไม่ดีในทุกกรณี

ทำแบบฝึกหัด

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

ดาวน์โหลดใบงาน (Markdown)

ตรวจความเข้าใจ ↑