สมมติว่า AI ตัวหนึ่งแก้หน้าจออนุมัติใบสั่งซื้อ อีกตัวแก้บริการตรวจสิทธิ์ แต่ละตัวส่งงานพร้อมผลทดสอบผ่านทั้งหมด พอรวมกัน ผู้จัดการกลับกดอนุมัติไม่ได้ เพราะหน้าจอยังส่งรหัสบริษัทในช่องข้อมูลชื่อเดิม ขณะที่บริการเปลี่ยนชื่อช่องที่รับแล้ว
ทีมอาจแก้ให้ปุ่มกลับมาใช้ได้ด้วยการข้ามการตรวจบริษัทเมื่อไม่พบช่องข้อมูลใหม่ การแก้เร่งด่วนเช่นนี้ก็อาจเปิดให้คนอนุมัติรายการของบริษัทที่ตนไม่มีสิทธิ์ได้ ตัวอย่างนี้เป็นสถานการณ์สมมติ ไม่ใช่เหตุการณ์ของลูกค้าหรือระบบที่ผมเปิดใช้แล้ว
ความเร็วของแต่ละงานจึงยังไม่ตอบว่า งานทั้งหมดจะอยู่ร่วมกันได้หรือไม่ ผมคิดว่ายิ่ง AI ช่วยลงมือได้เร็ว ทีมยิ่งต้องออกแบบจังหวะที่คนกลับมารวมงาน ตรวจข้อสมมติ และตัดสินใจร่วมกันให้ชัด
บทความก่อนหน้า ถามว่าเดโมพร้อมให้คนอื่นใช้หรือยัง บทความนี้ขยับมาถามเรื่องทีม เมื่อหลายคนมอบหมายงานให้ AI พร้อมกัน เราจะทำให้ความเร็วเหล่านั้นกลายเป็นระบบเดียวที่ดูแลต่อได้อย่างไร
ผ่านแยกกัน ยังต้องตรวจตอนรวมงาน
ส่งรหัสบริษัทในช่องข้อมูลชื่อเดิม
รับรหัสบริษัทในช่องข้อมูลชื่อใหม่
ในเรื่องสมมติ ผลทดสอบแต่ละส่วนผ่าน
คำขอจากหน้าจอไม่ตรงสัญญาที่บริการรอรับ ผู้จัดการจึงอนุมัติไม่ได้
อย่าข้ามการตรวจบริษัทเพื่อให้ปุ่มกลับมาใช้ได้
ตรวจจากผู้ใช้ที่ยืนยันตัวตนแล้ว ว่ามีสิทธิ์ต่อรายการและบริษัทนั้นจริง
ตกลงรอยต่อก่อนแยกกันทำ
จุดที่นำงานมาตรวจและตัดสินใจร่วมกัน คือจังหวะที่ทีมตรวจว่างานจากหลายส่วนยังตรงกับข้อตกลงเดียวกัน พร้อมหลักฐานและคนที่ตัดสินใจเรื่องถัดไปได้ บางจุดเป็นการคุยสั้น ๆ บางจุดเป็นการทดสอบอัตโนมัติ และบางจุดต้องให้คนผู้มีอำนาจตรวจความเสี่ยงก่อนเดินต่อ
ในตัวอย่างใบสั่งซื้อ ทีมควรตกลงก่อนว่าใครอนุมัติได้ ใช้ยอดใดตัดสินสิทธิ์ และเมื่อยอดหรือบริษัทเปลี่ยนต้องตรวจใหม่อย่างไร จากนั้นจึงกำหนดสัญญาการเชื่อมต่อ หรือ API contract ว่าหน้าจอส่งข้อมูลอะไร บริการตอบอะไร และกรณีไม่มีสิทธิ์จะแสดงผลอย่างไร
สัญญานี้ต้องรวมความหมายด้วย ชื่อช่องข้อมูลตรงกันแต่ตีความต่างกันก็ยังพังได้ เช่น ฝั่งหนึ่งคิดว่า "ผู้จัดการ" อนุมัติได้ทุกบริษัท อีกฝั่งหมายถึงผู้จัดการของบริษัทในรายการนั้นเท่านั้น การปิดปุ่มบนหน้าจอเป็นเพียงการช่วยผู้ใช้ ส่วนบริการที่รับคำขอต้องหาสิทธิ์จากผู้ใช้ที่ยืนยันตัวตนแล้วและตรวจสิทธิ์ต่อรายการนั้น ไม่เชื่อบทบาทที่หน้าจอส่งมา
ข้อตกลงควรอยู่ในที่ที่ทีมและ AI อ้างอิงได้ และมีวิธีเปลี่ยนร่วมกัน หากคนหนึ่งแก้สัญญาระหว่างทาง ต้องรู้ว่างานใดได้รับผลกระทบ ใครต้องตรวจ และต้องรองรับของเดิมชั่วคราวหรือไม่ การประชุมทุกวันไม่ได้ทดแทนข้อตกลงที่ค้นเจอและทดสอบได้
- ตกลงงานกติกาและสัญญา API
- รวมงานPR เล็กและผลทดสอบรอยต่อ
- ตรวจร่วมกันบริบท สิทธิ์ และผู้ตัดสินใจ
- เตรียมปล่อยstaging และผู้รับผิดชอบ
- ฟังผลจริงผู้ใช้ เหตุขัดข้อง และการแก้ไข
สิ่งที่พบหลังใช้จริงกลับมาแก้กติกาและชุดทดสอบ
งานเล็กช่วยให้ตรวจความคิดทัน
เมื่อ AI ส่งโค้ดได้มาก การรับงานเป็นก้อนใหญ่ทำให้คนตรวจต้องไล่หาว่ากติกาธุรกิจเปลี่ยนตรงไหน ควรแบ่งเป็นคำขอรวมโค้ด หรือ pull request (PR) ที่มีเหตุผลเดียวพอให้เข้าใจได้ เช่น เปลี่ยนการตรวจสิทธิ์หนึ่งกรณี พร้อมระบุผลต่อผู้เรียกใช้ ไม่ใช่รวมการเปลี่ยนหน้าจอ สิทธิ์ และโครงสร้างข้อมูลโดยไม่มีขอบเขตให้ตรวจ
DORA อธิบายการทำงานเป็นชุดเล็ก ว่าช่วยให้ได้ข้อมูลกลับเร็วและปรับข้อสมมติได้เร็ว สำหรับผม ขนาดที่เหมาะสมจึงต้องดูว่าคนตรวจเข้าใจผลกระทบได้หรือไม่ ไม่ใช่นับจำนวนบรรทัดอย่างเดียว แยก PR จนแต่ละชิ้นดูเล็ก แต่ทดสอบหรือใช้งานแยกไม่ได้ ก็ยังต้องจัดลำดับการรวมงานให้ชัด
ผลทดสอบแต่ละส่วนต้องตามด้วยการทดสอบรอยต่อ ในตัวอย่างนี้ควรเรียกบริการจริงในสภาพแวดล้อมทดสอบด้วยรูปแบบข้อมูลที่หน้าจอจะส่ง ตรวจผู้ใช้ที่มีสิทธิ์และไม่มีสิทธิ์ รวมถึงกรณีบริษัทไม่ตรงกัน การทดสอบที่แทนบริการด้วยคำตอบจำลองชุดเดิมทั้งหมดอาจไม่พบความขัดแย้งของสัญญา
ผมอยากให้ PR บอกกติกาที่ใช้ สิ่งที่เปลี่ยน ผลตรวจที่รันจริง และเรื่องที่ยังไม่ทราบ ผู้ตรวจไม่ควรต้องย้อนอ่านบทสนทนากับ AI ทั้งหมดเพื่อเดาว่า "เสร็จ" หมายถึงอะไร
คนตรวจต้องมีบริบทและอำนาจหยุด
การตรวจของคนมีค่าตรงการถามเรื่องที่ข้อทดสอบอาจยังไม่ครอบคลุม เช่น เราควรให้สิทธิ์แบบนี้หรือไม่ ข้อมูลนี้ควรปรากฏกับผู้ใช้กลุ่มนี้หรือไม่ และมีขั้นตอนเดิมใดได้รับผลกระทบ การกด Approve โดยไม่เข้าใจขอบเขตไม่ได้เพิ่มหลักฐานให้ระบบ
GitHub รองรับการกำหนดให้ต้องมีผู้ตรวจและผลตรวจผ่านก่อนรวมโค้ด แต่ทีมต้องตั้งกติกาให้ตรงงาน รวมถึงดูว่าใครข้ามกติกาได้ และเมื่อโค้ดเปลี่ยนหลังตรวจต้องตรวจซ้ำอย่างไร ความสามารถของเครื่องมือไม่ได้แปลว่าคลังโค้ดทุกแห่งเปิดใช้การป้องกันเหล่านี้แล้ว
AI เองก็ควรได้สิทธิ์เท่าที่งานต้องใช้ แยกสิทธิ์อ่าน เสนอแก้ รวมโค้ด และปล่อยระบบตามความเสี่ยง งานที่ควรหยุดรอคนไม่ควรอาศัยเพียงข้อความในคำสั่งว่า "อย่าทำ" หากสามารถจำกัดสิทธิ์ของบัญชีและสภาพแวดล้อมได้
ผู้รับผิดชอบงาน ผู้ตรวจ และผู้รับผิดชอบการปล่อยระบบอาจเป็นคนเดียวกันในทีมเล็ก แต่ควรบอกได้ว่ากำลังตัดสินใจในหน้าที่ใด การอนุมัติจากอีกคนไม่ได้ย้ายความรับผิดชอบทั้งหมดออกจากคนทำงาน และคำว่า "AI เขียนให้" ก็ไม่ได้ทำให้ความรับผิดชอบหายไป
กติกาเดิมมีค่าเมื่อทำให้คนกล้าพูด
ข้อตกลงก่อนเริ่มงาน การตรวจงานร่วมกัน และการส่งมอบให้คนดูแลต่อ เป็นพื้นฐานของการทำงานเป็นทีมอยู่แล้ว AI ทำให้เรามีเหตุผลต้องดูแลพื้นฐานเหล่านี้จริงจังขึ้น เพราะงานใหม่อาจเข้ามาเร็วกว่าที่คนจะทำความเข้าใจทัน
ทีมควรมีความหมายร่วมกันของคำว่าเสร็จ หรือ definition of done สำหรับงานแต่ละระดับ งานแก้ข้อความอาจต้องเพียงตรวจความหมายและการแสดงผล ส่วนงานอนุมัติใบสั่งซื้อควรมีหลักฐานเรื่องสิทธิ์ รอยต่อ และผลต่อข้อมูล พร้อมคนดูแลหลังปล่อย เกณฑ์นี้ช่วยให้ผู้รับงานทราบว่าต้องส่งอะไร และช่วยให้ผู้ตรวจไม่เปลี่ยนกติกาทีหลังโดยไม่อธิบาย
วัฒนธรรมการตรวจมีผลด้วย ถ้าคนถูกมองว่าถ่วงงานเมื่อพูดว่า "ผมยังไม่เข้าใจผลกระทบนี้" ข้อสงสัยจะถูกเก็บไว้จนสายเกินไป ผมอยากเห็นการตรวจที่ถามถึงข้อสมมติและหลักฐาน เปิดให้ผู้ตรวจผิดได้ และให้เครดิตคนที่พบปัญหาก่อนผู้ใช้เจอ
DORA เชื่อมโยงวัฒนธรรมที่มีความไว้วางใจและข้อมูลไหลถึงกันกับผลการส่งมอบซอฟต์แวร์ ข้อนี้สนับสนุนให้ทีมดูว่าข่าวร้ายเดินทางถึงผู้ตัดสินใจได้เร็วแค่ไหน ไม่ใช่ใช้ผลวิจัยรับประกันว่าทีมที่ประชุมบ่อยจะทำงานดีขึ้น ความปลอดภัยทางใจควรทำให้คนรายงานความผิดพลาดได้ ขณะเดียวกันก็ต้องมีเจ้าของเรื่องที่ติดตามแก้ไข
หน้าจอเขียวตอบได้เพียงบางคำถาม
หน้าจอ Argo CD ที่แสดง Healthy และ Synced ช่วยเล่าเรื่องสถานะการติดตั้ง แต่ต้องอ่านตามขอบเขตของมัน Synced หมายถึงสถานะที่ใช้งานอยู่ตรงกับสถานะเป้าหมายตามที่ Argo CD เปรียบเทียบ ส่วน Healthy มาจากเกณฑ์ตรวจสุขภาพของทรัพยากรที่เกี่ยวข้อง เกณฑ์เหล่านั้นขึ้นกับชนิดทรัพยากรและการตั้งค่า
ระบบอาจอยู่ในสถานะดังกล่าว แต่ยังคำนวณวงเงินผิดหรืออนุญาตผู้ใช้ผิดคนได้ ต้องมีหลักฐานด้านธุรกิจและความปลอดภัยของงานนั้นเพิ่ม การเห็นปุ่ม Sync แบบสั่งเอง หรือเห็นว่า PR รวมแล้ว ก็ยังไม่บอกว่ามีการอนุมัติครบทุกขั้นหรือทดสอบการกู้คืนแล้ว ภาพหน้าจอเพียงภาพเดียวไม่พิสูจน์ความพร้อมของระบบจริง
ก่อนปล่อย ควรนำรุ่นที่จะปล่อยไปทดสอบในพื้นที่เตรียมใช้งาน หรือ staging ด้วยเงื่อนไขที่ใกล้กับส่วนเสี่ยงของงาน ระบุข้อแตกต่างจากระบบจริง และให้ผู้รับผิดชอบการปล่อยระบบตัดสินใจจากหลักฐาน ไม่ใช่จากสีของสถานะอย่างเดียว
| จังหวะ | หลักฐานที่นำมาดูร่วมกัน | ผู้รับผิดชอบตัดสินใจ |
|---|---|---|
| ก่อนแยกงาน | กติกาอนุมัติและสัญญา API ที่ตรงกัน | เจ้าของกติกาธุรกิจกับผู้ดูแลรอยต่อ |
| ก่อนรวมโค้ด | ผลตรวจของรุ่นที่จะรวม รวมกรณีผิดสิทธิ์ | เจ้าของการเปลี่ยนแปลงกับผู้ตรวจ |
| ก่อนปล่อย | ผลทดสอบ staging ข้อแตกต่าง และวิธีหยุด | ผู้รับผิดชอบการปล่อยระบบ |
| หลังเปิดใช้ | ผลต่อผู้ใช้ รายการที่ผิดกติกา และเหตุขัดข้อง | ผู้ดูแลระบบร่วมกับเจ้าของงานธุรกิจ |
ต้องรู้ว่าจะหยุดอะไร และกลับได้ถึงไหน
แผนรับเหตุหรือ runbook ควรบอกว่าเมื่อพบการอนุมัติผิดสิทธิ์จะหยุดการกระทำใหม่ตรงไหน ใครรับเรื่อง ดูรายการที่อาจกระทบจากหลักฐานใด และใครตัดสินใจว่าจะกลับรุ่นหรือแก้เดินหน้า คนเข้าเวรควรใช้แผนนี้ได้โดยไม่ต้องตามหาคนเขียน AI prompt คนแรก
การย้อนรุ่นแอปพลิเคชันไม่เท่ากับย้อนข้อมูล ถ้ารุ่นใหม่เปลี่ยนโครงสร้างฐานข้อมูล ลบช่องข้อมูล หรือส่งใบสั่งซื้อออกไปแล้ว การกลับไปใช้โค้ดเก่าอาจใช้ไม่ได้ หรือยังเหลือผลกระทบที่ต้องแก้ต่างหาก ทีมจึงควรทดสอบความเข้ากันได้ของการเปลี่ยนฐานข้อมูล วางลำดับเปลี่ยนอย่างระมัดระวัง และมีหลักฐานว่ากู้คืนข้อมูลได้ในขอบเขตที่ต้องการ การมีไฟล์สำรองอย่างเดียวไม่พิสูจน์ว่ากู้คืนได้ทันเวลาที่ธุรกิจรับได้
เอกสาร Argo CD ระบุว่าไม่สามารถใช้คำสั่ง rollback กับแอปพลิเคชันที่เปิด automated sync อยู่ วิธีรับเหตุจึงต้องเข้ากับนโยบาย sync และแหล่งกำหนดสถานะเป้าหมายของทีม การเลือก revision เก่าไม่ได้ย้อนฐานข้อมูลหรือธุรกรรมภายนอกโดยอัตโนมัติ ข้อจำกัดส่วนหลังนี้เป็นเหตุผลทางวิศวกรรมที่ต้องออกแบบแผนกู้คืนแยก ไม่ใช่คำรับรองความสามารถจากหน้าจอ
หลังเปิดใช้ ต้องกลับมาดูผลของงานจริงด้วย นอกจากข้อผิดพลาดทางเทคนิค ทีมควรดูเหตุการณ์ที่มีความหมายกับงาน เช่น คำขออนุมัติถูกปฏิเสธผิดปกติ ผู้ใช้ทำขั้นตอนต่อไม่ได้ หรือมีรายการเปลี่ยนสถานะไม่ตรงกติกา เก็บข้อมูลเท่าที่จำเป็น จำกัดผู้เข้าถึง และส่งสิ่งที่พบกลับไปแก้ข้อตกลงกับชุดทดสอบ
เลือกจุดที่ต้องตัดสินใจตามความเสี่ยง
จุดที่นำงานมาตรวจและตัดสินใจร่วมกันไม่จำเป็นต้องเป็นการรอคนกดอนุมัติทุกครั้ง งานที่ผลกระทบต่ำ มีหลักฐานอัตโนมัติที่เชื่อถือได้ และกลับได้ตามแผน อาจเดินต่อภายใต้กติกาที่ตกลงไว้ ส่วนงานที่เปลี่ยนสิทธิ์ แตะข้อมูลสำคัญ หรือมีผลที่ย้อนกลับยาก ควรมีการตรวจจากคนที่เข้าใจผลกระทบและมีอำนาจตัดสินใจ
ถ้าทุกเรื่องไปรอคนเดียว ทีมจะสะสมคิว และคนคนนั้นจะมีเวลาตรวจแต่ละเรื่องน้อยลง ควรทบทวนว่าจุดไหนช่วยค้นความผิดพลาดจริง จุดไหนซ้ำกับหลักฐานที่มีอยู่ และจุดไหนยังไม่มีเจ้าของ อย่าลดขั้นตอนเพียงเพื่อให้ส่งเร็วขึ้น แต่ก็ไม่ควรเพิ่มขั้นตอนโดยไม่รู้ว่าต้องการคำตอบเรื่องใด
สำหรับงานถัดไป ลองเลือกหนึ่งรอยต่อที่สองคนหรือสอง AI ทำงานมาบรรจบกัน แล้วเขียนให้ได้ว่าเราตกลงอะไร ใช้หลักฐานใดพิสูจน์ว่าเข้ากัน ใครตัดสินใจเมื่อไม่ตรงกัน และหลังเปิดใช้ใครจะฟังเสียงจากผู้ใช้ คำตอบเหล่านี้ช่วยให้ทีมใช้ความเร็วของ AI ได้โดยยังทำงานร่วมกันรู้เรื่อง
ที่มาและขอบเขต
บทความนี้เป็นข้อเสนอเรื่องวิธีทำงานของทีม เชื่อมต่อจากบทความเดโมสู่การทดลองใช้บนเว็บไซต์นี้ โดยใช้เอกสารทางการของ Argo CD และ GitHub อธิบายขอบเขตเครื่องมือ และใช้ DORA ประกอบเรื่องงานชุดเล็กกับวัฒนธรรมทีม ตัวอย่างใบสั่งซื้อ แผนภาพ และตารางเป็นสิ่งที่จัดทำเพื่ออธิบาย ไม่ใช่รายงานระบบที่เปิดใช้ ผลทดสอบ หรือการรับรองความปลอดภัยของระบบใด