ให้เอเจนต์ AI ลงมือพัฒนา: ขั้นตอนการพัฒนาลดลง 95.5% ส่วนทั้งโครงการคาดว่าอยู่ที่ 60–70%

บทนำ

ระหว่างที่พัฒนาระบบธนาคารที่สร้างเอง ฉันเพิ่มคอลัมน์อีกหนึ่งคอลัมน์ลงในตารางประมาณการของ WBS (Work Breakdown Structure — ตารางบริหารงานที่แตกโครงการออกเป็นงานย่อยแต่ละชิ้น) ชื่อของมันคือ “เวลาจริงของ AI” เป็นคอลัมน์ที่สงวนไว้สำหรับบันทึกว่า หลังจากเอเจนต์ AI ลงมือทำงานนั้นจริงแล้ว ใช้เวลาไปเท่าไร

ตารางที่เคยมีแต่ประมาณการ กลายเป็นตารางที่นำไปเทียบกับค่าที่วัดได้ บทความนี้เขียนถึงตัวเลขที่ออกมาจากตารางนั้น ว่าตัวเลขเหล่านั้นหมายถึงอะไรและไม่ได้หมายถึงอะไร และระหว่างทางที่ผลิตตัวเลขออกมา ฉันทำอะไรผิดไปบ้าง

เพิ่มคอลัมน์สำหรับค่าที่วัดได้หนึ่งคอลัมน์ลงในตารางประมาณการ

เดิม WBS นี้มีคอลัมน์ประมาณการอยู่สองคอลัมน์ คือ “ประมาณการของมนุษย์” (ค่าประมาณแบบคน-วันตามธรรมเนียม สำหรับกรณีที่ SE มนุษย์ทำงานนี้เต็มเวลา) และ “ประมาณการของ AI” ฉันเพิ่มคอลัมน์ที่สามคือ “เวลาจริงของ AI” กฎการบันทึกที่เขียนไว้ใน WBS มีดังนี้

เวลาจริงของ AI: คอลัมน์ที่สงวนไว้สำหรับเติมหลังจากลงมือทำงานนั้นจริงแล้ว ห้ามเติมล่วงหน้า ห้ามเขียนทับค่าประมาณการก่อนลงมือ (เป็นกฎเพื่อไม่ให้ประมาณการกับค่าจริงปะปนกัน) WBS ฉบับนี้ทำหน้าที่เป็นบันทึกแบบเติมต่อท้ายเท่านั้นของ “ประมาณการ → ลงมือ → บันทึกค่าจริง”

คอลัมน์ผู้รับผิดชอบก็ไม่ได้ใส่ชื่อคน แต่ใส่ชื่อเอเจนต์ย่อยที่กำหนดเอง ได้แก่ rag-coder สำหรับการอิมพลีเมนต์ rag-reviewer / test-reviewer สำหรับการตรวจสอบ และ test-coder สำหรับเขียนโค้ดทดสอบ การแบ่งบทบาทว่าใครทำอะไรไม่ได้อธิบายซ้ำในบทความนี้ แต่ยกให้บทความต่อไปนี้

สร้างแพลตฟอร์มสตรีมมิงและธนาคารไปพร้อมกัน — จัดวางกองเอเจนต์ AI ให้ลงมือพัฒนาฟีเจอร์จริง แล้วปรับจูนการแบ่งงานด้วยการวัดผล

WBS ยังระบุด้วยว่า “มนุษย์ (ตัวฉันเอง) ทำเพียงการอนุมัติขั้นสุดท้าย การตั้งค่าสภาพแวดล้อม และการตรวจสอบการทำงานจริง” ดังนั้นเวลาที่ลงในคอลัมน์เวลาจริงของ AI คือเวลาที่เอเจนต์กำลังลงมือทำงานนั้นเอง ไม่รวมเวลาที่ฉันดูผลลัพธ์แล้วตัดสินใจ (เรื่องนี้จะกลับมาพูดอีกครั้งในส่วนหลังในฐานะวิธีอ่านตัวเลข)

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

bed0c8b docs: WBSに口座詳細画面向けBFF API+取引履歴フィルタのAI実績を追記
f3ac5d3 docs: WBSにBFF-4(accounts-service部分)のAI実績を記録
2f4f5d6 docs: WBSにBFF-1のAI実績を記録
0206dda docs: WBSにAUTH-4のAI実績を記録
4cc2182 docs: WBSにNOTIF-4のAI実績を記録
04da765 docs: WBSにACC-8/PAY-7/AUTH-7/NOTIF-6のAI実績を記録
a738c4b docs: WBSにACC-7のAI実績を記録
3c8dcce docs: WBSにACC-6のAI実績を記録
3434ddc docs: WBSにACC-5のAI実績を記録
b0d82f9 docs: WBSにPAY-5のAI実績を記録
df89606 docs: WBSにPAY-4のAI実績を記録
3ef1172 docs: WBSにPAY-3のAI実績を記録
2b88b45 docs: WBSにPAY-6のAI実績を記録
3290475 docs: WBSにACC-4のAI実績を記録
cc289cb docs: WBSに人間実施予想/AI実施予想/AI実績の3軸を追加
27399ea docs: 全体WBS・マスタスケジュールを新規作成

ตัวอักษรผสมตัวเลขอย่าง BFF-4 และ AUTH-4 ในข้อความคอมมิตคือหมายเลขส่งมอบใน WBS คำนำหน้าบอกว่าเป็นเซอร์วิสใด (AUTH = เซอร์วิสยืนยันตัวตน, ACC = เซอร์วิสบัญชี, PAY = เซอร์วิสชำระเงิน, NOTIF = เซอร์วิสแจ้งเตือน, BFF = ชั้นรวม API สำหรับหน้าจอ, WEB = เว็บฟรอนต์เอนด์, INF = โครงสร้างพื้นฐาน) และตัวเลขคือหมายเลขงานภายในเซอร์วิสนั้น หมายเลขที่ปรากฏในคอมมิตข้างต้น เมื่อเขียนเป็นคำพูดคือดังนี้

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

ถ้าวาดกระบวนการที่หนึ่งงานปิดจบเป็นหนึ่งแถว จะได้ภาพแบบนี้ มันไม่ได้จบที่ อิมพลีเมนต์ → ตรวจสอบ แต่มีเส้นย้อนกลับสำหรับการแก้ไข และเส้นย้อนกลับเส้นที่สองที่ป้อนค่าจริงกลับเข้าสู่ประมาณการครั้งถัดไป

flowchart TD
    subgraph WBS["WBS (กลุ่มซ้อนกัน: auth / accounts / payments / notifications / bff / web)"]
        T["1 งาน<br/>เช่น PAY-3 = ตัว Saga เอง"]
    end
    T --> IMPL["อิมพลีเมนต์<br/>rag-coder"]
    T --> TC["ตารางมุมมองทดสอบ → โค้ดทดสอบ<br/>test-coder"]
    IMPL --> REV{"รีวิว<br/>rag-reviewer / test-reviewer"}
    TC --> REV
    REV -->|"must-fix 0 รายการ"| REC
    REV -->|"must-fix N รายการ<br/>เช่น ขาดการตรวจสิทธิ์ความเป็นเจ้าของ"| FIX["แก้ไข"]
    FIX -->|"ตีกลับ"| REV
    REC["บันทึกเวลาเป็น m ลงคอลัมน์เวลาจริงของ AI<br/>เช่น 75m = รอบแรก 50m + แก้ไข 25m"] --> CM["1 งาน = 1 คอมมิต"]
    CM -->|"ค่าจริงสะสมขึ้นเรื่อยๆ"| EST["คอลัมน์ประมาณการของ AI แม่นยำขึ้น"]
    EST -->|"สะท้อนไปยังประมาณการงานถัดไป"| T

    style REC fill:#e8f4ea,stroke:#4a7c59
    style FIX fill:#fbeee6,stroke:#c17f4a

งานที่ฉันประเมินไว้ 490.8 ชั่วโมงของ SE มนุษย์ เขียนเสร็จด้วยเวลาที่วัดได้ 21.9 ชั่วโมง — ลดลง 95.5%

จาก 189 แถวที่ AI รับผิดชอบใน WBS มี 49 แถวที่มีตัวเลขทั้งในช่องประมาณการของมนุษย์และช่องเวลาจริงของ AI จึงนำมาเทียบกันได้ (ส่วนที่เหลือคืออะไร เขียนไว้ตรงๆ ในส่วนถัดไป)

490.8 ชั่วโมงเท่ากับ 61.4 คน-วันในการประมาณการแบบธรรมเนียม ใกล้เคียงกับสามเดือนของ SE เต็มเวลาที่ไม่ทำอย่างอื่นเลย งานเท่านั้นถูกเขียนเสร็จด้วยเวลาที่วัดได้ 21.90 ชั่วโมง เมื่อวางบนแกนเดียวกัน จะได้ภาพนี้

xychart-beta
    title "เวลาที่ใช้กับ 49 งานเดียวกัน (หน่วย: ชั่วโมง)"
    x-axis ["ประมาณการ SE มนุษย์ 490.8h", "เอเจนต์ AI วัดได้ 21.9h"]
    y-axis "ชั่วโมง" 0 --> 500
    bar [490.8, 21.9]

ลำพังหน่วยชั่วโมงทำให้นึกภาพปริมาณงานได้ยาก จึงเขียนตัวเลขชุดเดิมใหม่ด้วยหน่วยอื่น (คิด 1 คน-วัน = 8 ชั่วโมง, 1 เดือน = 20 วันทำการ)

• 490.8 ชั่วโมง ⇒ 21.90 ชั่วโมง ลดลง 95.5%
• 61.4 คน-วัน (ราวสามเดือนของคนหนึ่งคนแบบเต็มเวลา) ⇒ 2.7 คน-วัน (ราวสามวัน)
• งานเท่ากับหนึ่งเดือนคือ 20 วันทำการ ⇒ ราว 7 ชั่วโมง คือหนึ่งวันทำการ

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

เมื่อแยกตามบทบาท จะเห็นว่าไม่ได้มีแต่การอิมพลีเมนต์เท่านั้นที่เร็ว

ตรงนี้คือแกนกลางของบทความ จำนวนแถวรีวิว (23) มีพอๆ กับจำนวนแถวอิมพลีเมนต์ (22) เมื่อแยกย่อย 21.90 ชั่วโมงถูกใช้ไปแบบนี้

pie showData
    title สัดส่วนของเวลาจริง 21.90 ชั่วโมง แยกตามบทบาท
    "อิมพลีเมนต์ rag-coder" : 13.64
    "รีวิว rag-reviewer / test-reviewer" : 6.11
    "โค้ดทดสอบ test-coder" : 2.15

28% ของทั้งหมดถูกใช้ไปกับการตรวจสอบ ต้นตอของความเร็วไม่ใช่ “ให้เอเจนต์ตัวเดียวทำทุกอย่างให้จบๆ ไป” แต่คือ แยกการสร้างกับการตรวจสอบออกเป็นคนละเอเจนต์แล้ว ยังลงเอยที่ 21.90 ชั่วโมง นี่ไม่ใช่ตัวเลขที่ได้มาจากการข้ามขั้นรีวิว

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

xychart-beta
    title "อัตราส่วนแยกตามเอเจนต์ (ประมาณการ SE มนุษย์ ÷ เวลาจริงของ AI)"
    x-axis ["rag-coder อิมพลีเมนต์", "rag-reviewer ตรวจสอบ", "test-coder ทดสอบ", "test-reviewer ตรวจสอบ"]
    y-axis "เท่า" 0 --> 30
    bar [26.4, 17.7, 14.9, 13.3]

การอิมพลีเมนต์ลดลง 96.2% (26.4 เท่า) ขณะที่ฝั่งตรวจสอบหยุดอยู่ที่ 92.5–94.4% (13–18 เท่า) การตรวจสอบไม่ได้ถูกบีบอัดมากเท่ากับการอิมพลีเมนต์ เนื้อของการรีวิวคือการอ่านส่วนต่าง เทียบกับเอกสารออกแบบ แล้วตัดสินว่าต้องแก้หรือไม่ ซึ่งเป็นงานที่ไม่ได้เร็วขึ้นเชิงกลไกเหมือนการเขียน นี่คือรูปร่างที่ 49 แถวสะท้อนออกมา

ตรงนี้ควรพูดถึงเรื่องหน่วยที่ใช้เขียนสักหน่อย บทความนี้เขียนด้วยอัตราการลดลงเป็นหลัก แต่ ตัวเลขอัตราการลดลงมีบางอย่างที่มันบังไว้ 96.2% ของการอิมพลีเมนต์ กับ 92.5% ของการรีวิว อ่านแล้ว แทบจะเท่ากัน ทั้งที่อัตราส่วนต่างกันถึงสองเท่า คือ 26.4 เท่า กับ 13.3 เท่า เมื่อเลย 90% ไปแล้ว ตัวเลขอัตราการลดลงจะกลบความต่างทิ้ง แผนภูมิจึงยังคงเป็นอัตราส่วน และเนื้อความก็เขียนอัตราส่วนกำกับไว้ด้วย เพราะการแสดงแต่เปอร์เซ็นต์เท่ากับส่งภาพที่ผิดให้ผู้อ่านว่าทุกขั้นตอนเร็วขึ้นพอๆ กัน

เมื่อตัดตามเซอร์วิส อัตราการลดลงก็ไม่ได้สม่ำเสมอเช่นกัน

xychart-beta
    title "อัตราส่วนแยกตามเซอร์วิส (ประมาณการ SE มนุษย์ ÷ เวลาจริงของ AI)"
    x-axis ["web", "payments", "bff", "auth", "accounts", "notifications", "infra"]
    y-axis "เท่า" 0 --> 40
    bar [34.8, 23.7, 23.6, 22.0, 20.2, 17.8, 15.0]

ฝั่งหน้าจอ (web, 2 งาน) สูงสุดที่ 97.1% (34.8 เท่า) และการแจ้งเตือน (notifications, 2 งาน) ต่ำสุดที่ 94.4% (17.8 เท่า) แต่ทั้งสองมีงานรองรับเพียง 2 งาน ซึ่งไม่พอจะอ่านเป็นแนวโน้ม กลุ่มที่มีจำนวนงานรองรับมากกว่าคือ accounts (7 งาน, 95.0%) และ payments / auth (อย่างละ 5 งาน, 95.8% / 95.5%) และทั้งสามกลุ่มนี้เกาะกลุ่มกันอยู่ราว 95%

อัตราการลดลงกระจายตั้งแต่ 90.4% ถึง 97.8% — การแสดงแต่ค่าเฉลี่ยชวนให้อ่านผิด

การเขียนแต่ค่าเฉลี่ยทำให้เข้าใจสภาพจริงคลาดเคลื่อน เมื่อดูเป็นรายงาน (26 งาน โดยรวบงานที่พาดหลายแถวให้เป็นหนึ่งงาน) อัตราการลดลงมีช่วงกว้างมาก

นับจากนี้ไป หมายเลขส่งมอบจะมีชื่องานเป็นคำพูดกำกับไว้ด้วย

เมื่อนับ 26 งานตามช่วง จะเห็นความกว้างของช่วงได้โดยตรง การนับนี้ใช้อัตราส่วน ถ้าแบ่งช่วงด้วยอัตราการลดลง แท่งทั้งแปดจะอัดกันอยู่ในช่วง 90.4%–97.8% ซึ่งทุกแท่งดูเหมือน “เกือบ 100%” ไปหมด และการกระจายก็จะอ่านไม่ออก

xychart-beta
    title "การกระจายอัตราส่วนของ 26 งาน (มัธยฐาน 21.8 เท่า = ลดลง 95.4%)"
    x-axis ["10-15 เท่า", "15-20 เท่า", "20-25 เท่า", "25-30 เท่า", "30-35 เท่า", "35-40 เท่า", "40-45 เท่า", "45-50 เท่า"]
    y-axis "จำนวนงาน" 0 --> 9
    bar [4, 6, 8, 4, 1, 1, 1, 1]

18 งาน (69%) ตกอยู่ในช่วง 93.3–96.7% (15–30 เท่า) ขณะที่มีหนึ่งงานถึง 97.8% (เกิน 45 เท่า)

ถ้าเขียนเป็นอัตราการลดลง ค่าต่ำสุด 90.4% กับสูงสุด 97.8% ดูเหมือน ต่างกันเพียง 7.4 จุด แต่ถ้าวัดด้วยเวลาที่เหลืออยู่ ทั้งสองต่างกัน 4.4 เท่า ค่าเฉลี่ยรวม 95.5% (22.4 เท่า) เป็นเพียงเส้นที่ลากผ่านกลางช่วงนั้น ไม่ได้แปลว่างานแต่ละชิ้นจะจบลงที่ค่านั้น หากนำตัวเลขนี้ไปแสดงในที่ประชุมกับลูกค้า แล้วค่าเฉลี่ยเพียงอย่างเดียวทำให้ใครอ่านว่า “ทุกงานจบที่ลดลง 95%” การอ่านแบบนั้นผิด

งานฝั่งที่อัตราการลดลงต่ำ (ช่องว่างกับประมาณการของมนุษย์แคบที่สุด):

งานฝั่งที่อัตราการลดลงสูง:

“เทสต์ตรวจทิศทางการพึ่งพา” หมายถึงการวางกลไกที่ตรวจเชิงกลไกในรูปของโค้ดทดสอบว่า การพึ่งพากันระหว่างเลเยอร์ไหลไปในทิศทางที่การออกแบบกำหนดไว้หรือไม่ (ทิศทางเดียวคือ api → application → domain → infrastructure)

มี 6 งานที่ถูกตีกลับระหว่างรีวิว และอัตราการลดลงของงานเหล่านั้นคือ 90.4%, 93.4%, 95.0%, 95.8%, 95.9% และ 96.6% ซึ่งกระจายอยู่ทั้งสองฝั่งของมัธยฐาน 95.4% ตัวเลขไม่ได้แสดงความสัมพันธ์ในรูปที่ว่า “ถูกตีกลับจึงช้า” ในฐานะตัวอย่างรูปธรรมว่าการตรวจสอบและการแก้ไขถูกนับรวมอยู่ในความเร็วนั้นด้วย นี่คือข้อความจากคอลัมน์เวลาจริงใน WBS

PAY-3 (อิมพลีเมนต์ตัว Saga เอง — Saga คือแพตเทิร์นการออกแบบมาตรฐานที่ลำดับงานพาดหลายเซอร์วิสจะไม่ถูกยืนยันรวดเดียว แต่ยืนยันทีละขั้น และถ้าล้มเหลวกลางคันก็ย้อนกลับด้วยการดำเนินการผกผันคือการชดเชย) มีเวลาจริงของ AI ว่า “75m (รอบแรก 50m + แก้ must-fix 25m)” และรีวิว “25m (ตรวจพบครั้งแรก 15m + ยืนยันซ้ำหลังแก้ 10m)” ข้อความในช่องรีวิวอ่านได้ดังนี้

ตรวจพบ must-fix 2 รายการ (1: ขาดการตรวจสิทธิ์ความเป็นเจ้าของบน fromAccountId = IDOR, 2: ความเสี่ยงเงินเพิ่มซ้ำซ้อนจากการชดเชยทันทีเมื่อ transfer-in หมดเวลา) แก้แล้วรีวิวซ้ำและยืนยันว่าหมดปัญหา ผลพลอยได้คือพบช่องว่างเดิมที่ jwt.secret ไม่ตรงกันใน 3 เซอร์วิส และแก้ไปด้วย

IDOR (Insecure Direct Object Reference — ช่องโหว่มาตรฐานที่เพียงระบุ ID ก็เข้าถึงบัญชีหรือข้อมูลของคนอื่นได้) เป็นข้อบกพร่องที่จะหลุดขึ้นโปรดักชันถ้าไม่มีการรีวิว PAY-6 (ไคลเอนต์เชื่อมระหว่างเซอร์วิส) ก็เป็นรูปแบบเดียวกัน เทียบกับเวลาจริงของ AI “50m (อิมพลีเมนต์รอบแรก 35m + แก้ไข 15m)” ข้อความรีวิวอ่านได้ดังนี้

ตรวจพบ must-fix 1 รายการ (ขัดกับกฎ NEVER ใน 0402 §1.6 มีการอิมพลีเมนต์การออก JWT ด้วยตัวเองลงในโค้ดโปรดักชัน) rag-coder แก้ไปทางฝั่งปลอดภัย (กลับไปใช้เฮลเปอร์เฉพาะการทดสอบ) และตรวจสอบซ้ำแล้ว

AUTH-4 (อิมพลีเมนต์การยืนยันตัวตนด้วยชีวมิติ 66m + แก้ไข 16m), ACC-7 (แบตช์ตรวจหาบัญชีไม่เคลื่อนไหว 19m + แก้ไข 10m), NOTIF-6 (เทสต์ตรวจทิศทางการพึ่งพาของเซอร์วิสแจ้งเตือน 36m + แก้ไข 10m) และ BFF-1 (โครงร่างของชั้นรวม API 11m + แก้ไข 16m) ก็มีการตีกลับแบบเดียวกันบันทึกไว้ must-fix เป็นคำที่ใช้ภายใน WBS หมายถึง “ข้อบกพร่องที่พบในรีวิวและต้องแก้ก่อนปล่อยของ” และ 21.90 ชั่วโมงโดยรวมคือส่วนผสมของงานที่ผ่านโดยไม่มีรายการเหล่านี้เลย กับงานที่ผ่านการตีกลับ

49 แถวที่ใช้เทียบ และแถวที่ไม่ได้ใช้

“ได้ลงมือทำหรือไม่” กับ “ได้วัดเวลาหรือไม่” เป็นคนละแกน เมื่อแยก 189 แถวที่ AI รับผิดชอบใน WBS ตามสองแกนนี้ จะได้แบบนี้

flowchart LR
    A["แถวที่ AI รับผิดชอบใน WBS<br/>189 แถว"] --> B["ไม่เกิดขึ้นเลย เพราะการตัดสินใจ<br/>ด้านออกแบบหรือการเปลี่ยนกระบวนการ<br/>47 แถว"]
    A --> C["งานที่เกิดขึ้นจริง<br/>142 แถว"]
    C --> D["ลงมือทำแล้ว<br/>124 แถว = 87.3%"]
    C --> E["ยังไม่เริ่ม 18 แถว<br/>ขอบเขตของ Phase 3 เป็นต้นไป"]
    D --> F["วัดเวลาเป็นหน่วยนาที<br/>49 แถว<br/>ตัวเลขในบทความนี้มาจากตรงนี้"]
    D --> G["ไม่ได้วัดเวลา<br/>75 แถว"]

    style D fill:#e8f4ea,stroke:#4a7c59
    style F fill:#e8f4ea,stroke:#4a7c59
    style G fill:#fbeee6,stroke:#c17f4a

จาก 142 งานที่เกิดขึ้นจริง มี 124 งาน (87.3%) ที่ลงมือทำไปแล้ว ในจำนวนนั้น มีเพียง 49 แถวที่บันทึกเวลาเป็นหน่วยนาที ฉันเริ่มวัดกลางเดือนกรกฎาคม 2026 และมีช่วงหนึ่งที่หยุดวัดเพื่อให้ความสำคัญกับการอิมพลีเมนต์ ตัวเลข 490.8 ชั่วโมง → 21.90 ชั่วโมง มาจาก 49 แถวที่วัดไว้เท่านั้น

ฉันไม่ย้อนกลับไปเขียนค่าประมาณลงใน 75 แถวที่ไม่ได้วัด เรื่องนี้ระบุไว้ในกฎการเขียนของ WBS เอง (ในข้อความที่ยกมา “หมายเหตุ 2” หมายถึงแถวที่ลงมือแล้วแต่ไม่ได้วัด และ “หมายเหตุ 1” หมายถึงแถวที่มีค่าที่วัดได้)

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

“47 แถวที่ไม่เกิดขึ้นเลย” ก็ควรแจกแจงเช่นกัน 45 แถวในนั้นตั้งอยู่บนสมมติฐานว่าจะมีสามขั้นตอน คือ test-writer สร้างตารางมุมมองทดสอบ test-coder อิมพลีเมนต์เทสต์ตามตารางนั้น และ test-reviewer รีวิวเทสต์ พอใช้งานจริงกลับลู่เข้าสู่รูปแบบที่ rag-coder เขียนเทสต์ไปพร้อมกับการอิมพลีเมนต์ และ rag-reviewer รีวิวทั้งการอิมพลีเมนต์และเทสต์รวมกัน การไม่แทรกผลงานตัวกลางอย่างตารางมุมมองทดสอบ ทำให้การไป-กลับระหว่างการอิมพลีเมนต์กับเทสต์เร็วกว่า ส่วนอีก 2 แถวที่เหลือ (AUTH-6 / BFF-3) หลุดออกนอกขอบเขตด้วย ADR 0016 (เลิกใช้รูปแบบที่ Keycloak ทำหน้าที่เป็น IdP แล้วให้ auth-service ออก JWT ด้วยตัวเองแทน)

ทั้งสองกลุ่มไม่ใช่ “ยังทำไม่เสร็จ” แต่ เลิกจำเป็นไปแล้ว จึงถูกกันออกจากตัวหารของการลดเวลาทำงาน

18 แถวที่ยังไม่เริ่มคือหน้าจองานฝั่งโมบายล์ โครงร่างของระบบภายใน (operator / backoffice / admin) และรายการที่เป็นตัวเลือกอย่างการวางระบบสังเกตการณ์และไฟล์ k8s manifest ซึ่งทั้งหมดอยู่ในขอบเขตของ Phase 3 เป็นต้นไป

ฉันจะลบแถวที่วัดไม่ได้ทิ้งเพื่อดันความครอบคลุมที่มองเห็นให้สูงขึ้นก็ได้ แต่ทำแบบนั้นแล้วบัญชีจะกลายเป็นแผ่นโฆษณา แถวที่เขียนว่า “ไม่มีข้อมูลการวัด (กู้จำนวนนาทีที่แน่นอนไม่ได้เพราะช่วงเวลานั้นอยู่ก่อนการบีบอัดสรุป อ้างอิง: คอมมิต 467f594/a6e6057)” จึงคงไว้อย่างนั้น

ประมาณการอยู่ที่ลดลง 94.7% แต่ค่าที่วัดได้อยู่ที่ 95.5%

WBS ยังมีตัวเลขอีกตัวหนึ่ง ส่วนสรุปของมันระบุว่า “ประมาณ 18.7 เท่า” คือลดลง 94.7% (210.35 คน-วันที่ AI รับผิดชอบ = 1,682.8 ชั่วโมง หารด้วยผลรวมประมาณการของ AI ราว 90.2 ชั่วโมง) และนั่นคือ ประมาณการหารด้วยประมาณการ ไม่ใช่ค่าที่วัดได้ WBS เองก็หมายเหตุไว้ว่าเป็น “ค่าชั่วคราว ซึ่งมาจากข้อเท็จจริงที่ว่าประมาณการของ AI ส่วนใหญ่เป็นค่าคาดเดา”

อัตราการลดลงที่วัดได้จริงจาก 49 แถวคือ 95.5% (490.8 ชั่วโมง → 21.90 ชั่วโมง) ตัวเลขสองตัวนี้มีตัวหารคนละแบบ จึงเทียบกันตรงๆ ไม่ได้ แต่วางเรียงกันได้ ค่า 95.5% ที่วัดได้ในช่วงนั้นออกมาสูงกว่า 94.7% ที่เห็นตอนยังเป็นประมาณการ พูดอีกอย่างคือ ประมาณการเป็นฝั่งที่อนุรักษ์นิยมกว่า

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

ตัวเลขสองตัวมาจากไหน วางเรียงไว้ตรงนี้ ฝั่งซ้ายทั้งตัวตั้งและตัวหารเป็นประมาณการ ฝั่งขวามีเพียงตัวหารที่เป็นค่าวัดได้ แผนภาพวาดด้วยอัตราส่วน (การวาง 94.7% กับ 95.5% ไว้ข้างกันทำให้มองไม่เห็นว่าที่มาของทั้งสองต่างกัน)

flowchart LR
    subgraph A["ประมาณ 18.7 เท่าในส่วนสรุปของ WBS = ลดลง 94.7% = ประมาณการ ÷ ประมาณการ"]
        A1["AI รับผิดชอบ 210.35 คน-วัน<br/>= 1,682.8 ชั่วโมง<br/>ประมาณการของมนุษย์"] --> A3["18.7 เท่า"]
        A2["ผลรวมประมาณการของ AI<br/>ราว 90.2 ชั่วโมง<br/>ส่วนใหญ่เป็นค่าคาดเดา"] --> A3
    end
    subgraph B["22.4 เท่าในบทความนี้ = ลดลง 95.5% = ประมาณการ ÷ ค่าที่วัดได้"]
        B1["490.8 ชั่วโมงจาก 49 แถว<br/>ประมาณการของมนุษย์"] --> B3["22.4 เท่า"]
        B2["21.90 ชั่วโมงจาก 49 แถว<br/>เวลาจริงของ AI = วัดได้"] --> B3
    end
    A3 -.->|"ประชากรต่างกัน<br/>เทียบกันตรงๆ ไม่ได้"| B3

    style A2 fill:#fbeee6,stroke:#c17f4a
    style B2 fill:#e8f4ea,stroke:#4a7c59

อย่างไรก็ตาม ค่า 95.5% นี้ต้องมีข้อสงวนของตัวเองด้วย ไม่มีบันทึกว่า SE มนุษย์ลงมือทำ 49 งานเดียวกันนี้ด้วยมือจริงๆ ฝั่งมนุษย์ยังเป็นประมาณการ มีเพียงฝั่ง AI เท่านั้นที่วัดได้ ฉันจึงเขียนว่า “ลดเวลาทำงานลง 95.5%” ไม่ได้ ถ้าจะพูดให้ตรง มันคือการวัดทางเดียว: งานที่ประเมินไว้ 490.8 ชั่วโมงของ SE มนุษย์ ถูกเขียนเสร็จด้วยเวลาที่วัดได้ 21.90 ชั่วโมง

ขอบเขตของคอลัมน์เวลาจริงของ AI เองก็จำกัดเช่นกัน มันไม่รวมการอนุมัติขั้นสุดท้าย การตั้งค่าสภาพแวดล้อม การตรวจสอบการทำงานจริง และเวลาที่ใช้ตัดสินว่าจะตีกลับหรือไม่พร้อมเขียนคำสั่ง ตามที่ WBS ระบุว่า “มนุษย์ (ตัวฉันเอง) ทำเพียงการอนุมัติขั้นสุดท้าย การตั้งค่าสภาพแวดล้อม และการตรวจสอบการทำงานจริง” สิ่งเหล่านั้นอยู่นอกคอลัมน์เวลาจริง คืออยู่ฝั่งมนุษย์ ตัวเลขในบทความนี้จึงไม่ได้แสดง “จำนวนชั่วโมงที่วิศวกรกลายเป็นไม่จำเป็น” แต่แสดงเพียงจำนวนชั่วโมงที่เอเจนต์กำลังประมวลผลอะไรบางอย่างอยู่จริง

สุดท้าย อัตราการลดลงรายงานเองก็มีความคลาดเคลื่อน เพราะบางแถวในคอลัมน์เวลาจริงถูกทำเครื่องหมายว่ารวมยอด

BFF-2  48m（BFF-7と合算）
WEB-1  29m（WEB-2/WEB-4一部と合算）
AUTH-7 46m（auth-service/bff/web一体実装）
BFF-4  27m（accounts-service部分のみ、AUTH-6未着手のためpayments/notifications/auth向けは別途）
INF-1  11m12s（docker-compose.yml実装作業と合算、内訳分離不可）

หมายเลขใน 5 แถวนั้นชี้ไปยังงานต่อไปนี้

(ข้อความ “AUTH-6 ยังไม่เริ่ม” ในช่องของ BFF-4 คือถ้อยคำ ณ ตอนที่เขียน ภายหลัง AUTH-6 ซึ่งคือการเชื่อมต่อกับผู้ให้บริการยืนยันตัวตนภายนอก ถูกยืนยันว่าอยู่นอกขอบเขตด้วย ADR 0016 และเป็นหนึ่งใน “47 แถวที่ไม่เกิดขึ้นเลย” ข้างต้น)

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

ตัวเลข 24.40 ชั่วโมงนั้นไม่ถูกต้อง

ตัวเลขข้างต้นทั้งหมดเขียนไว้ที่ 21.90 ชั่วโมง แต่ผลรวมแรกที่สคริปต์รวมยอดให้มาคือ 24.40 ชั่วโมง

ต้นเหตุอยู่ที่นิพจน์ปกติ กับการเขียนแบบ 75m（初回50m+must-fix是正25m） มันเก็บทั้ง 75, 50 และ 25 มานับรวมเป็น 150m สิ่งที่อยู่ในวงเล็บคือรายละเอียดแยกย่อย ไม่ควรบวกทับค่าหลัก การเขียนแบบเดียวกันนี้ปรากฏใน 50m（初回実装35m＋是正15m） ด้วย

ขณะเดียวกันก็มีรูปแบบที่ไม่มีวงเล็บ เช่น 66m+16m是正 ตรงนั้นทั้งรอบแรกและการแก้ไขต่างเป็นค่าหลัก จึงต้องนับเป็น 82m ความผิดพลาดของฉันคืออ่านทุกอย่างด้วยกฎเพียงข้อเดียวจากสองแบบ โดยไม่ทันสังเกตว่ามีการเขียนสองรูปแบบปะปนกันอยู่

flowchart TD
    S["คอลัมน์เวลาจริงใน WBS<br/>มีการเขียนสองรูปแบบปะปนกัน"] --> P1["75m (รอบแรก 50m + แก้ไข 25m)<br/>ในวงเล็บคือรายละเอียดแยกย่อย"]
    S --> P2["66m+16m แก้ไข<br/>ไม่มีวงเล็บ = ทั้งคู่เป็นค่าหลัก"]
    P1 --> BUG["นิพจน์ปกติตัวแรก<br/>เก็บทุกตัวเลขในบรรทัด"]
    P2 --> BUG
    BUG --> W["นับ 75+50+25 = 150m"]
    BUG --> OK["นับ 66+16 = 82m"]
    W --> WT["รวม 24.40 ชั่วโมง / ลดลง 95.0%"]
    OK --> WT
    WT --> D{"ยังเหลือแถวที่อธิบายไม่ได้<br/>ด้วยการมีหรือไม่มีวงเล็บ"}
    D -->|"สังเกตเห็นความต่างของรูปแบบ"| FIX["ตัดวงเล็บออกก่อนแล้วค่อยแยกวิเคราะห์"]
    FIX --> R["นับ 75m"]
    R --> RT["รวม 21.90 ชั่วโมง / ลดลง 95.5%"]

    style WT fill:#fbeee6,stroke:#c17f4a
    style RT fill:#e8f4ea,stroke:#4a7c59

ตัวเลขที่เป็นฐานของบทความว่าด้วยการวัดประสิทธิภาพของ AI คลาดเคลื่อนไป 11.4% เพราะวิธีวัดของฉันเอง ทิศทางของความคลาดเคลื่อนก็ควรเขียนไว้ด้วย เมื่อแก้แล้ว ผลรวมฝั่ง AI ลดจาก 24.40 ชั่วโมงเหลือ 21.90 ชั่วโมง และอัตราการลดลงขยับขึ้นจาก 95.0% เป็น 95.5% พูดอีกอย่างคือ บั๊กเดิมทำให้ฝั่ง AI ดูช้ากว่าความจริง เป็นบั๊กที่เข้าทางฝั่งตรงข้ามกับผลประโยชน์ของฉันเอง และตรงนี้ก็เห็นคุณสมบัติของตัวเลขเปอร์เซ็นต์อีกครั้ง 95.0% กับ 95.5% ดูเหมือนต่างกันแค่ครึ่งจุด แต่เวลาที่เหลืออยู่คือ 24.40 ชั่วโมง กับ 21.90 ชั่วโมง ต่างกันถึง 2.5 ชั่วโมง

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

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

เงื่อนไขที่ทำให้การลดลง 95.5% นี้เป็นจริง

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

• ประมาณการของมนุษย์ไม่ใช่บันทึกของมนุษย์ที่ลงมือทำจริง แต่เป็นค่าประมาณแบบคน-วันตามธรรมเนียมที่วางไว้ตอนสร้าง WBS
• เวลาจริงของ AI ไม่รวมเวลาฝั่งมนุษย์สำหรับการอนุมัติขั้นสุดท้าย การตั้งค่าสภาพแวดล้อม การตรวจสอบการทำงานจริง การตัดสินใจ และการเขียนคำสั่ง
• ตัวเลข 95.5% เป็นการเทียบฝั่ง AI ที่วัดได้ กับฝั่งมนุษย์ที่ยังเป็นประมาณการ คือวัดเพียงฝั่งเดียว
• อัตราการลดลงรายงานมีความคลาดเคลื่อนจากแถวที่รวมหลายงานไว้เป็นแถวเดียว
• ตัวหารคือ 49 แถวที่วัดเวลาเป็นหน่วยนาที ส่วน 75 แถวที่ลงมือทำแล้วแต่ไม่ได้วัด ไม่มีการใส่ค่าประมาณ และไม่ได้อยู่ในตัวหารด้วย
• หนึ่งใน 49 แถวมีผู้รับผิดชอบเป็น “rag-coder / ฉันทำแทน” เป็นงานที่ประเมินไว้ 4.0 ชั่วโมงของมนุษย์ และ 0.33h ในคอลัมน์เวลาจริงคือเวลาที่ฉันลงมือทำเอง ดังนั้นคอลัมน์เวลาจริงจึงไม่ใช่เวลาของเอเจนต์ล้วนๆ (0.33h เทียบกับ 21.90 ชั่วโมงโดยรวม คือ 1.5%)

พูดกลับกัน ถ้าตัดหกข้อนี้ทิ้ง อัตราการลดลงจะทำให้ใหญ่กว่านี้ก็ได้ เอาแถวรีวิวออกจากตัวหาร ก็จะเหลือ 96.2% เฉพาะการอิมพลีเมนต์ ตัดเวลาแก้ไขและการตีกลับออกไปอีก ก็จะสูงขึ้นไปอีก 95.5% คือตัวเลขที่ไม่ได้ทำสิ่งเหล่านั้นเลย

ทั้งโครงการอยู่ที่ 60–70% — 95.5% ไม่ได้ยกไปใช้ทั้งดุ้น

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

เมื่อรวมทั้งหมดนั้นเข้าไปด้วย สิ่งที่ลดลงได้ทั้งโครงการคือ 60–70% ของเวลาทำงาน

flowchart LR
    A["เวลาทำงานทั้งหมดของโครงการ"] --> B["งานพัฒนาที่อยู่ใน WBS<br/>อิมพลีเมนต์ รีวิว เทสต์"]
    A --> C["เอกสารส่งมอบ ปรับความต้องการ<br/>ประชุม สร้างข้อตกลง<br/>ส่วนที่บีบอัดได้ยาก"]
    B -->|"วัดได้ ลดลง 95.5%"| D["ทั้งโครงการ<br/>ลดลง 60-70%"]
    C -->|"แทบไม่ถูกบีบอัดเลย"| D

    style B fill:#e8f4ea,stroke:#4a7c59
    style C fill:#fbeee6,stroke:#c17f4a

ตัวเลข 60–70% นี้สอดคล้องกันในเชิงเลขคณิตด้วย ถ้าให้งานพัฒนาคิดเป็น 6–7 ส่วนสิบของเวลาทำงานในโครงการ แล้วลดเฉพาะส่วนนั้นลง 95.5% โดยส่วนที่เหลือไม่ลดเลย อัตราการลดลงโดยรวมจะมาอยู่ที่ 60–70% พูดกลับกันคือ ตัวเลขนี้มาเป็นชุดเดียวกับข้อสมมติที่ว่า ส่วนที่ไม่ใช่การพัฒนาคิดเป็น 3–4 ส่วนสิบ และมันจะขยับ ถ้าโครงการนั้นมีสัดส่วนต่างออกไป

ตัวเลขสองตัวนี้มาจากคนละที่กัน 95.5% คือค่าที่วัดถึงระดับนาทีจาก 49 แถวของ WBS ชุดนี้ โดยมีทั้งวิธีวัดและจุดที่ฉันทำผิดเขียนอยู่ในบทความนี้แล้ว ส่วน 60–70% คือ คำตอบที่ฉันหามาได้ด้วยตัวเอง จากการเฝ้าดูว่าเวลาในโครงการหนึ่งไหลไปอยู่ตรงไหนบ้างจริงๆ ตัวที่ควรนำไปใช้กับทั้งโครงการคือตัวหลัง

ถ้าจะแสดงตัวเลขเหล่านี้ในที่ประชุมกับลูกค้า ฉันจะแสดงตามลำดับนี้ มองเฉพาะงานพัฒนาลดลงได้ 95.5% ส่วนทั้งโครงการอยู่ที่ 60–70%

คอลัมน์เดียวกันนี้ใส่ลงใน WBS ไหนก็ได้

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

สิ่งที่ออกมาคือ งานที่ประเมินไว้ 490.8 ชั่วโมงของ SE มนุษย์ ถูกเขียนเสร็จด้วยเวลาที่วัดได้ 21.90 ชั่วโมง คือ ลดลง 95.5% พร้อมกับการแจกแจงของมัน การอิมพลีเมนต์ลดลง 96.2% ส่วนการตรวจสอบหยุดอยู่ที่ 92.5–94.4% ต้นตอของความเร็วไม่ใช่ “ให้เอเจนต์ตัวเดียวทำทุกอย่างให้จบๆ ไป” แต่มีรูปร่างเป็น การแยกการสร้างกับการตรวจสอบออกเป็นคนละเอเจนต์ แล้วนี่คือเวลาที่ใช้ไป

95.5% นั้นเป็นตัวเลขของขั้นตอนการพัฒนา ไม่ใช่ตัวเลขของทั้งโครงการ ถ้ารวมเอกสารส่งมอบและการประชุมเข้าไปด้วย ทั้งโครงการจะอยู่ที่ลดลง 60–70% เพื่อไม่ให้ตัวเลขสองตัวที่มาจากคนละที่ถูกเอามาปนกัน บทความนี้จึงแยกหัวข้อของทั้งสองออกจากกัน

วิธีที่ฉันวัด และจุดที่ฉันทำผิดไประหว่างทาง เขียนไว้ทั้งหมดแล้ว คอลัมน์เดียวกันนี้ใส่ลงใน WBS ไหนก็ได้