สองประตู หนึ่งด่าน: การกำกับดูแลที่เหนือกว่า EDD
กฎการ Onboarding และความติดขัดของนักพัฒนา (developer friction) มักจะดูเหมือนเป็นปัญหาเดียวกัน แต่จริงๆ แล้วไม่ใช่
เมื่อคุณขยายทีมจนมีนักพัฒนาถึง 40 คน คุณไม่สามารถใช้วิธีการฝึกอบรมแบบเดียวกันกับทุกคนได้ นักพัฒนาบางคนเป็นผู้เชี่ยวชาญด้าน AI agents ในขณะที่บางคนยังเป็นมือใหม่ หากคุณเขียนกฎชุดเดียวสำหรับทุกคน คุณจะล้มเหลว
นักพัฒนาที่มีประสบการณ์จะเพิกเฉยต่อกฎ ส่วนนักพัฒนาหน้าใหม่จะประสบปัญหาในการปฏิบัติตาม
คุณต้องแยกแนวทางของคุณออกเป็นสองเลเยอร์ที่ชัดเจน:
เครื่องมือสร้างความตระหนักรู้ (Awareness tools) เครื่องมือเหล่านี้เปลี่ยนสิ่งที่คนคนหนึ่งรู้ ตัวอย่างเช่น ความเห็นจากการรีวิวโดย AI หรือคำเตือนจาก linting เครื่องมือเหล่านี้ทำหน้าที่เหมือนพนักงานต้อนรับ พวกเขาจะสังเกตเห็นสิ่งต่างๆ และแนะนำการดำเนินการ แต่จะใช้ได้ผลก็ต่อเมื่อคนคนนั้นยอมรับฟังเท่านั้น
เครื่องมือการกำกับดูแล (Governance tools) เครื่องมือเหล่านี้เปลี่ยนสิ่งที่คนคนหนึ่งสามารถทำได้ ตัวอย่างเช่น การป้องกันสาขา (branch protection) และด่านการรวมโค้ด (merge gates) เครื่องมือเหล่านี้ทำหน้าที่เหมือนประตูหมุน (turnstile) พวกเขาไม่ต่อรอง และจะหยุดกระบวนการหากไม่เป็นไปตามข้อกำหนด
ความผิดพลาดคือการใช้พนักงานต้อนรับในขณะที่คุณต้องการประตูหมุน คำแนะนำจาก AI ที่นักพัฒนาเพิกเฉยไม่ใช่การกำกับดูแล แต่มันเป็นเพียงแค่เสียงรบกวน
เพื่อแก้ไขเรื่องนี้ ให้ใช้สองเลเยอร์ที่แยกจากกัน:
เลเยอร์การกำกับดูแล (The Governance Layer) เลเยอร์นี้มีขนาดเล็กและเป็นสากล ใช้กับทุกคนโดยไม่คำนึงถึงทักษะ ประกอบด้วยกฎต่างๆ เช่น ห้าม push โค้ดโดยตรงไปยัง protected branches และต้องมีการรีวิวเสมอ นี่ไม่ใช่เรื่องของความไว้วางใจ แต่เป็นเรื่องของการปกป้อง codebase จากความเสี่ยงสูงของการเปลี่ยนแปลงที่ขับเคลื่อนโดย agent
เลเยอร์โครงร่าง (The Scaffolding Layer) เลเยอร์นี้มีความเป็นส่วนตัวและยืดหยุ่น ประกอบด้วยขั้นตอนต่างๆ เช่น การวางแผนที่ชัดเจนและการให้เหตุผลอย่างละเอียด นักพัฒนาหน้าใหม่จะใช้เลเยอร์นี้อย่างหนักเพื่อสร้างวิจารณญาณ ส่วนนักพัฒนาที่มีประสบการณ์สามารถลดระดับการใช้งานลงได้เมื่อเก่งขึ้น นี่ไม่ใช่รางวัลสำหรับความอาวุโส แต่เป็นเครื่องมือที่จะกลายเป็นสิ่งที่ไม่จำเป็นเมื่อทักษะเพิ่มสูงขึ้น
คุณควรพิจารณาความเสี่ยงของการเปลี่ยนแปลงนั้นๆ ด้วย นักพัฒนาอาวุโสที่แตะต้องไฟล์ที่ซับซ้อนและมีความเชื่อมโยงกันสูง (highly coupled) จะสร้างความเสี่ยงมากกว่านักพัฒนารุ่นเยาว์ที่แตะต้องฟังก์ชันอรรถประโยชน์ (utility function) ง่ายๆ ระบบควรตอบสนองต่อตัวโค้ด ไม่ใช่แค่ตัวบุคคล
สุดท้าย ให้มุ่งเน้นไปที่ความเป็นเจ้าของ (ownership) AI agent อาจจะเป็นคนเขียนโค้ด แต่ตัวนักพัฒนาคือเจ้าของผลลัพธ์ หากนักพัฒนาไม่สามารถอธิบายได้ว่าทำไมถึงมีการเปลี่ยนแปลงเกิดขึ้นในระหว่างการรีวิว การเปลี่ยนแปลงนั้นก็ไม่ควรถูก merge
เลิกแบ่งระดับคนด้วยลำดับขั้น แต่จงจัดหาเครื่องมือที่ช่วยให้พวกเขาสามารถจัดการความเสี่ยงของตนเองได้
Source: https://dev.to/karlheinz_reichel_7ee08d/two-doors-one-gate-navigating-governance-beyond-edd-5clj
Optional learning community: https://t.me/GyaanSetuAi