ก่อนเอา AI เข้าบริษัท จัดทีมใหม่ตามกระแสคุณค่าก่อน

ก่อนที่คุณจะนำ AI เข้ามา มีหนึ่งท่าที่คุ้มค่ากว่าการเลือกเครื่องมือ คุ้มกว่าการเลือกโมเดล: จัดทีมเทคโนโลยีใหม่ตามกระแสคุณค่า (value stream) ผมเห็นองค์กรมาเยอะ ซื้อเครื่องมือแล้ว ติดตั้งโมเดลแล้ว อบรมคนแล้ว ส่งงานก็ยังช้า คนยิ่งหมดแรง สาเหตุรากแทบไม่เคยอยู่ที่ AI ไม่แกร่ง แต่อยู่ที่ทีมถูกหั่นตามชั้นเทคโนโลยี — ฟรอนต์เอนด์ แบ็กเอนด์ อัลกอริทึม ดูแลระบบ ความปลอดภัย ฟีเจอร์หนึ่งที่ควรจบตลอดทั้งสายต้องข้ามทีมสี่ห้าทีม แล้วทุกครั้งที่ส่งต่อก็มีอะไรตกหล่น: โจทย์ตกนิดหน่อย บริบทตกนิดหน่อย ความรู้สึกเป็นเจ้าของตกนิดหน่อย ขอบเขตทีมถูกต้อง AI ถึงจะมีที่ยืนขยายผล ขอบเขตผิด AI ก็แค่เร่งสร้างหนี้ทางเทคนิคบนโครงสร้างที่พังอยู่แล้ว

บทความนี้วางวิธีออกแบบองค์กรที่ลงมือทำได้จริง — Team Topologies (Skelton & Pais, 2019) แกนสามข้อ: ตัดทีมตามกระแสคุณค่า ดู cognitive load ของทีม และถือแพลตฟอร์มภายในเป็นสินค้า เปิดเคสจริงจากโรงงานมาเล่าให้ฟัง

CIO ของบริษัทการผลิตแห่งหนึ่ง (เคสปกปิดชื่อจากโปรเจ็กต์จริง) เล่าให้ฟัง: ลองขึ้นฟีเจอร์ AI ตรวจสอบคุณภาพ ด้านเทคนิคไม่ยาก กล้องจับตำหนิ โมเดลมีสำเร็จให้ใช้ ที่ยากคือการส่งมอบ ทีมฟรอนต์เอนด์ทำ UI ทีม MES แก้งานใบผลิต ทีมอัลกอริทึมติดตั้งโมเดล ทีมดูแลระบบดูเซิร์ฟเวอร์ ทีมความปลอดภัยก็ต้องมาตรวจอีกรอบ ฟีเจอร์เดียว ข้าม 5 ทีม ส่งต่ออย่างเป็นทางการ 4 ครั้ง ดองยาว 3 เดือน ไม่มีทีมไหนขี้เกียจ แต่ทุกรอบส่งต่อมีอะไรตกหล่น

วิธีหั่นทีม ตัดสินความเร

หนึ่ง กฎของ Conway พูดแค่ครึ่งเดียว

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

แต่ Conway บอกแค่ว่า “มันเป็นแบบนี้” ไม่ได้บอกว่าจะออกแบบทีมยังไงให้สถาปัตยกรรมที่ดีงอกขึ้นมาเอง ช่องว่างนี้ Skelton กับ Pais มาเติมในปี 2019 ด้วยหนังสือ Team Topologies: ทีมมีสี่ประเภทพื้นฐาน สามรูปแบบการโต้ตอบ และหลักการหนึ่งที่แทรกอยู่ตลอด — ดู cognitive load

สอง สี่ประเภททีม: ใช้เป็นตัวเลือกตอนจัดใหม่ ไม่ใช่ให้ท่อจำ

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

stream-aligned team — กำลังหลักขององค์กร ควรเป็นส่วนใหญ่ (หนังสือใช้คำว่า most ไม่ได้ให้สัดส่วนตายตัว) “กระแส” คือกระแสคุณค่าที่ไหลต่อเนื่อง stream-aligned team รับผิดชอบช่วงหนึ่งของกระแสนี้จบตลอดสาย — ตั้งแต่เข้าใจโจทย์ พัฒนา ขึ้นโปรดักชัน ไปจนถึงดูแลระบบ ทดสอบว่าทีมไหนจัดอยู่ในประเภทนี้หรือเปล่า ดูข้อเดียวพอ: มันส่งคุณค่าไปถึงมือผู้ใช้ได้โดยไม่ต้องพึ่งทีมอื่นไหม กลับไปที่ CIO คนนั้น: ถ้าฟีเจอร์ตรวจสอบคุณภาพอัจฉริยะของเขาจัดเป็น “ทีมกระแสตรวจสอบคุณภาพ” ที่มีคนรู้ฟรอนต์ คนต่อ MES คนติดตั้งโมเดล คนดูแลระบบ อยู่ในทีมเดียว — ฟีเจอร์นี้จบที่ทีมเดียว ไม่มีการส่งต่อ นั่นแหละคือสภาพที่ควรจะเป็น

ปัญหาที่เจอบ่อยที่สุดในองค์กรใหญ่คือ ระบบวิ่งตลอดสาย แต่ทีมถูกหั่นเป็นชั้นเทคโนโลยีขวางกระแส ทุกครั้งที่ส่งมอบตลอดสาย ต้องทะลุขอบเขตการรายงานของหลายทีม เปลี่ยนอุตสาหกรรมก็เจอเหมือนกัน ของธนาคารยิ่งชัด: ฟีเจอร์ควบคุมความเสี่ยงเครดิตต้องข้ามสี่ทีม — ทีมแอป ทีมระบบหลัก ทีมโมเดลความเสี่ยง ทีมข้อมูล แต่ละทีมถือหน้าที่ของตัวเอง แต่ละรอบส่งต่อคือแต่ละรอบที่ทิ้งบริบทไปบ้าง ส่วนอีคอมเมิร์ซกับโทรคมนาคมเนื้อเรื่องเดียวกันแค่เปลี่ยนชื่อ — โปรโมชันข้ามสินค้า ธุรกรรม การตลาด คลัง; เปลี่ยนแพ็กเกจข้ามช่องทาง เรียกเก็บ CRM เครือข่าย พอทีมถูกหั่นขวางไปรับกระแสคุณค่าที่วิ่งตั้ง รอบส่งต่อก็ทยอยขึ้น นั่นคือตัวโรค

platform team — ปูทางให้ stream-aligned team ทีมนี้จัดหาโครงสร้างพื้นฐาน CI/CD และบริการใช้ร่วม ให้ stream-aligned team หยิบความสามารถไปใช้แบบ self-service ได้เลย ไม่ต้องเปิด ticket ขอคนอื่นทำให้ทุกครั้ง เกณฑ์ตัดสินมีข้อเดียว: แพลตฟอร์มภายในของคุณถูกบริหารเป็นสินค้า (มีผู้ใช้ มี roadmap มี SLA) หรือกลายเป็น “เอาท์ซอร์สในบ้าน” ที่รอตั๋วเข้ามา ฝ่าย IT ขององค์กรใหญ่ส่วนมากติดอยู่ในรูปแบบหลัง: สร้างแพลตฟอร์มไว้แต่ไม่มีใครใช้ ทีมธุรกิจหลีกไปทำของตัวเอง แล้ว platform team ก็เสื่อมกลายเป็นเอาท์ซอร์ส Spinnaker ของ Netflix (continuous delivery) กับ Backstage ของ Spotify (พอร์ทัลนักพัฒนา) คือตัวอย่างที่เป๊ะของการถือแพลตฟอร์มเป็นสินค้า สองอย่างนี้คนมักสลับกัน: Spinnaker ของ Netflix, Backstage ของ Spotify อย่าเขียนสลับในสไลด์รายงาน

enabling team — ช่วย stream-aligned team ยกระดับ เป้าหมายคือทำให้ตัวเองไม่มีงานทำ มันไม่ได้ส่งมอบธุรกิจโดยตรง หน้าที่คือยกความสามารถของ stream-aligned team ขึ้นมา: โค้ชเอาเทคโนโลยีใหม่เข้ามา คนนำการเปลี่ยนผ่าน DevOps ที่ปรึกษาด้านความปลอดภัยและ compliance ความสัมพันธ์กับ stream-aligned team เป็นพี่เลี้ยงกับศิษย์ ไม่ใช่ผู้ว่าจ้างกับผู้รับจ้าง สำหรับองค์กรใหญ่ ที่ปรึกษาภายนอกที่ดีที่สุดควรเล่นบทบาทนี้: ถ่ายทอดความสามารถ ไม่ใช่สร้างการพึ่งพาไปตลอด

complicated-subsystem team — สำหรับงานหนักที่ต้องการความเชี่ยวชาญลึก พอระบบย่อยไหนต้องการความลึกจริง ๆ — เอนจินความเสี่ยง อัลกอริทึมแนะนำ วิทยาการเข้ารหัส ตัวเข้ารหัสวิดีโอ — แยกออกเป็นทีมผู้เชี่ยวชาญเฉพาะ อย่าให้ cognitive load ของ stream-aligned team พัง ทีมประเภทนี้ควรมีน้อย องค์กรไหนมี complicated-subsystem team ผุดขึ้นมาเยอะ มักแปลว่าสิ่งที่ควรเป็นแพลตฟอร์มถูกหั่นเป็นปล่องแยกหลายจุด

แค่ตั้งชื่อประเภททีมไม่พอ ต้องนิยามว่าทีมโต้ตอบกันยังไงด้วย Team Topologies ให้มาสามแบบ แบบแรก collaboration — สองทีมลงลึกทำด้วยกัน เหมาะกับพื้นที่ใหม่ที่ยังไม่แน่นอน แต่กินพลังงานสูง ใช้ได้แค่ระยะสั้น แบบที่สอง X-as-a-Service — ทีมหนึ่งเสนอความสามารถเป็นสินค้าให้อีกทีมหยิบไปใช้เอง มีประสิทธิภาพสูงสุด ควรเป็นค่าเริ่มต้น แบบที่สาม facilitating — ใช้เฉพาะ enabling team คำถามหลักของการออกแบบองค์กรคือ จะดันให้การโต้ตอบมากที่สุดไปอยู่ในรูป X-as-a-Service ได้อย่างไร ถ้าทีมยังพึ่ง collaboration ระยะยาว แปลว่า platformization ยังไม่เกิด เอาเคส CIO มาดู: ทีมกระแสตรวจสอบคุณภาพกับ platform team ควรโต้ตอบกันแบบ X-as-a-Service แพลตฟอร์มเปิดทางเข้า CI/CD แบบ self-service ทีมตรวจสอบคุณภาพใช้เองไม่ต้องบอก ถ้าทุกครั้งต้องดึง platform team มาประชุม collaborate ก่อน deploy แปลว่า platformization ยังไม่ถึง — และปัญหาไม่ใช่ที่ท่าที แต่ที่แพลตฟอร์มไม่ได้ถูกถือเป็นสินค้าตั้งแต่แรก

องค์กรที่แข็งแรง: สี่ประ

สาม ทำไมทั้ง “เพิ่มคน” และ “เพิ่มกระบวนการ” ช่วยไม่ได้: cognitive load

นี่คือผลงานที่ถูกประเมินต่ำที่สุดของ Team Topologies: มันยก cognitive load ขึ้นมาเป็นศูนย์กลางของการออกแบบองค์กร

ทีม 5 ถึง 8 คน มี cognitive load จำกัด จะให้ทีมเดียวดูแลระบบไม่เกี่ยวข้องกันสิบกว่าระบบ ต่ออัปสตรีมหกเจ็ดสาย แถมต้องรับมือเฟรมเวิร์กใหม่สามชุดพร้อมกัน มันโอเวอร์โหลดแน่นอน ผลคือคุณภาพตก ส่งมอบช้าลง คนหมดไฟ

นี่อธิบายความงงอีกข้อของ CIO คนนั้น: “ผมเพิ่มให้สามคนแล้ว ทำไมยังช้า?” รากเหง้าอยู่ที่กลุ่มคนนี้แบกของไม่เกี่ยวข้องกันพร้อมกันอยู่แล้วเยอะเกินไป คนจริง ๆ พออยู่ การเพิ่มคนแค่เอาคนเพิ่มมาหมุนวนในความวุ่นวายเดิม การเพิ่มกระบวนการแย่กว่า: กระบวนการกิน cognitive load ไปอีกชั้น คนที่เดิมทำงานได้ต้องเสียเวลาไปกับฟอร์ม ประชุม และเดินขั้นตอนอนุมัติมากขึ้น

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

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

กฎ Two-Pizza Team ของ Amazon พูดถึงต้นทุนการสื่อสาร — พอคนเพิ่มขึ้น ช่องทางสื่อสารระหว่างสมาชิก (n(n-1)/2) พุ่งสูง การตัดสินใจก็ช้า Team Topologies ลงลึกไปอีกชั้น: เกิน 8 คนขึ้นไป cognitive load ก็คุมไม่อยู่เช่นกัน สิ่งที่การออกแบบองค์กรทำจริง ๆ คือแบ่งทีมตาม cognitive load ให้ภาระของทีมอยู่ในขอบเขตที่รับไหว ไม่ใช่วาดเส้นรายงานตามหน้าที่

บรรทัดตรวจสุขภาพสำหรับองค์กรใหญ่: “คนที่ยุ่งที่สุด” ของคุณ แบกของไม่เกี่ยวข้องกันมากกว่า 5 อย่างพร้อมกันไหม ถ้าใช่ เพิ่มคนเท่าไหร่ เพิ่มกระบวนการเท่าไหร่ ก็ช่วยไม่ได้ ต้องจัดใหม่

สี่ ลงมืออย่างไร: Inverse Conway Maneuver

ท่าที่ลงมือได้จริงที่สุด: อย่าวาดแผนผังสถาปัตยกรรมก่อนแล้วค่อยไปจัดทีม ให้จัดโครงสร้างทีมก่อน แล้วปล่อยให้สถาปัตยกรรมงอกเป็นรูปที่คุณต้องการเอง

วิธีเดิมคือสถาปนิกวาดภาพสถาปัตยกรรมเป้าหมาย (“เราจะไปไมโครเซอร์วิส!”) แล้วสั่งทีมให้จัดตาม วิธีนี้ล้มเกือบทุกครั้ง — โครงสร้างทีมที่มีอยู่จะดึงสถาปัตยกรรมกลับไปสู่รูปเดิมตลอดเวลา กฎของ Conway กำลังทำงาน

Inverse Conway Maneuver กลับลำดับ: จัดทีมใหม่ตามกระแสคุณค่าก่อน — ตั้ง stream-aligned team ขึ้นมา ตั้ง platform team ขึ้นมา — ให้ขอบเขตทีมกลายเป็นขอบเขตบริการในอนาคต แล้วสถาปัตยกรรมจะลู่เข้าสู่การแบ่งบริการที่สมเหตุสมผลเอง เพราะทีมจะคุยกันผ่าน API โดยธรรมชาติ ไม่ใช่ดึงมือเข้าไปแชร์ฐานข้อมูลเดียวกัน

กลับไปที่ CIO คนนั้น ผมไม่ได้ให้เขาเลือกเฟรมเวิร์กไมโครเซอร์วิส ผมให้เขาทำอะไรที่เรียบง่ายกว่า: ตั้ง “ตรวจสอบคุณภาพ” เป็นทีมกระแสของตัวเอง ดึงคนจากทีมฟรอนต์เอนด์ ทีม MES ทีมอัลกอริทึม ทีมดูแลระบบเดิม ทีมละคน รวมเป็นทีมกระแสตรวจสอบคุณภาพ 6 คน รับผิดชอบฟีเจอร์ตรวจสอบคุณภาพจบตลอดสาย สามสัปดาห์เกิดสามเรื่อง สัปดาห์แรก พวกเขาเจอว่าขั้นตอนหนึ่งที่ค้างอยู่ในงานใบผลิต MES จริง ๆ ไม่ต้องให้ทีมอัลกอริทึมมายุ่ง ทีมแก้เองได้ภายใน สัปดาห์ที่สอง พวกเขาตัดสินใจเองว่าจะเปลี่ยนการติดตั้งโมเดลจาก “ต่อแถวรอทีมดูแลระบบ” เป็น self-service ในทีม เพราะ platform team เปิดทางเข้า CI/CD แบบ self-service ให้ สัปดาห์ที่สาม พวกเขาขึ้นฟีเจอร์เล็ก ๆ ที่จบตลอดสาย ไม่ข้ามขอบเขตทีมไหนเลย คนไม่ได้เพิ่ม เครื่องมือไม่ได้เปลี่ยน แค่เอาชั้นที่หั่นขวางมาตั้งตรงเป็นกระแส รอบการส่งมอบจาก 3 เดือนกลับมาที่ 3 สัปดาห์ และมีผลพลอยได้ที่ไม่คาดคิด: ทีมนี้เริ่มเสนอการปรับปรุงเอง เพราะพวกเขาได้เห็นภาพรวมของกระแสตัวเองเป็นครั้งแรก และแบกความรู้สึกเป็นเจ้าของผลลัพธ์ทั้งหมด ตอนที่ข้าม 5 ทีม ไม่มีใครรู้สึกว่าตัวเองควรรับผิดชอบกระแสตรวจสอบคุณภาพทั้งสาย

เคสโรงงาน: ฟีเจอร์ตรวจสอ

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

ใครกำลังใช้

  • ธนาคาร (อุตสาหกรรมเชิงนโยบายของ TT + จุดอ้างอิงที่มีกฎเข้ม) teamtopologies.com มีคอลัมน์ผู้เชี่ยวชาญเรื่อง “When DORA metrics meet governance in banking” ข้อสรุปวิจัย DORA ที่ยกอ้างแน่นมาก: external approvals มีความสัมพันธ์เชิงลบกับ lead time, deployment frequency และ restore time — ยิ่งมีการอนุมัติข้ามทีมหลังเกิดเหตุมากเท่าไหร่ การส่งมอบและการกู้คืนจากขัดข้องยิ่งช้าลงเท่านั้น นี่ตรงกับเสียงของบทความนี้เป๊ะ: ฝังข้อกำหนด compliance เข้าไปใน stream team และเลื่อนการอนุมัติมาข้างหน้า แทนที่จะเซ็นรับข้ามทีมหลังเกิดเหตุ ClearBank และธนาคารดิจิทัลของอังกฤษอื่น ๆ ถูกกล่าวถึงซ้ำ ๆ ในระบบนิเวศทางการ ธนาคารคือสถานการณ์ที่มีค่าอ้างอิงมากที่สุดสำหรับ “การจัดกระแสคุณค่าใหม่ภายใต้กฎเข้ม”
  • Zalando (อีคอมเมิร์ซ ตัวอย่างแพลตฟอร์มเป็นสินค้า) แพลตฟอร์มนักพัฒนาภายในเป็นความสามารถแบบ self-service ของ stream-aligned team คือมาตรฐาน platformization ที่ชุมชน TT อ้างถึงบ่อย
  • AutoTrader UK (แพลตฟอร์มจัดประเภทรถ) เคสรับชมจริงที่ TT อ้างซ้ำ ๆ — จัดทีมใหม่ตามกระแสคุณค่า พลัสทำแพลตฟอร์มภายในเป็นสินค้า
  • KPMG UK (ปี 2024 กลายเป็นพันธมิตรโซลูชันทางการของ TT) เอา TT ไปส่งให้ลูกค้าองค์กรและการเงินขนาดใหญ่ — สัญญาณว่า TT เข้าสู่คำปรึกษาองค์กรกระแสหลักแล้ว
  • Netflix / Spotify (ตัวอย่างจิตวิญญาณ “แพลตฟอร์มเป็นสินค้า” ไม่ใช่เคสรับชม TT) ทั้งสองบริหารแพลตฟอร์มเป็นสินค้ามาตั้งแต่ก่อนหนังสือ TT ออกปี 2019 ยืนยันหลักการนี้ แต่ไม่นับเป็นการรับชมโมเดลสี่ทีมของ TT

อ้างอิง: teamtopologies.com/examples (คลังเคสทางการ) · teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking (คอลัมน์ผู้เชี่ยวชาญ DORA ในธนาคาร)

ห้า เมื่อไหร่ที่ใช้ไม่ได้ผล

Team Topologies ไม่ใช่กระสุนเงิน ความล้มเหลวสี่แบบที่เจอบ่อย แต่ละแบบตรงกับรอยโรคจริงขององค์กรใหญ่

เปลี่ยนชื่อแต่ไม่เปลี่ยนโครงสร้าง เปลี่ยนชื่อ “ทีมฟรอนต์เอนด์” เป็น “stream-aligned team” แต่เส้นรายงานเหมือนเดิม ยังเป็นชั้นเทคโนโลยีอยู่ — กฎของ Conway ไม่สนใจวิธีตั้งชื่อ นี่คือตอนจบที่เจอบ่อยที่สุดของการปฏิรูปแบบ “แก้แต่หน้า” ในองค์กรใหญ่

platform team ไม่ถูกถือเป็นสินค้า platform team ไม่มี roadmap ไม่มีประสบการณ์ผู้ใช้ stream-aligned team ยังหลีกไปทำเอง แพลตฟอร์มเสื่อมกลายเป็นเอาท์ซอร์สที่รอตั๋ว

ทุกทีมอยู่ในโหมด collaboration collaboration เป็นการโต้ตอบที่กินพลังงานสูง ใช้ได้แค่ระยะสั้นกับพื้นที่ใหม่ที่ยังไม่แน่นอน พึ่ง collaboration ระยะยาว แปลว่า platformization ยังไม่เกิด ภายนอกดูเหมือน “วัฒนธรรม collaboration ดี” แต่รากโรคคือ platformization หายไป

KPI ไม่เปลี่ยนตาม แผนผังองค์กรเปลี่ยนแล้ว แต่ยังประเมินผลตามหน้าที่ (บรรทัดโค้ดฟรอนต์เอนด์ จำนวน bug) พฤติกรรมทีมก็ถอยกลับเป็นเดิมอย่างรวดเร็ว

สี่ข้อนี้ชี้ไปที่คำตัดสินเดียว: โครงสร้างองค์กร โครงสร้างแรงจูงใจ สถาปัตยกรรมเทคโนโลยี — เปลี่ยนข้อใดข้อหนึ่ง อีกสองข้อไม่ตาม การเปลี่ยนแปลงย่อมล้มเหลว

รูปแบบย่อสำหรับอุตสาหกรรมที่มีกฎเข้ม ธนาคารและโทรคมนาคมจะถาม: หน้าที่ด้านความปลอดภัย compliance และความเสี่ยงเทคโนโลยี กฎหมายกำกับให้เป็นอิสระ (segregation of duties) ดึงเข้า stream team ไม่ได้ง่าย ๆ นี่เป็นข้อจำกัดทางกฎหมายที่แข็ง ไม่ใช่ความเฉื่อยขององค์กร — อย่าฝืนแยก แต่ก็ไม่จำเป็นต้องกลับไปสู่การอนุมัติข้ามทีมแบบเดิม ทางออกสองทาง ทางแรก ฝังตัวแทน compliance/ความปลอดภัยไว้ใน stream team: เขาอยู่ในทีม ขณะเดียวกันรายงานเส้นประไปยังสาย compliance ทั้งชิดกระแสคุณค่าและรักษาความเป็นอิสระ ทางที่สอง ทำ compliance ให้เป็น enabling team ช่วย stream team ฝังข้อกำหนดกำกับเข้าไปในกระบวนการ (เหมือนรัน compliance check ใน CI) เลื่อนการอนุมัติมาข้างหน้าภายในทีม แทนที่จะเซ็นรับข้ามทีมหลังเกิดเหตุ ข้อกำหนดกำกับกลายเป็นคุณภาพที่ฝังใน stream team ไม่ใช่ด่านตรวจจากภายนอก — นี่คือกุญแจที่ทำให้อุตสาหกรรมที่มีกฎเข้ม “ไหลได้”

หก คำถามที่คุณอาจอยากถาม

“เราตัดทีมตามชั้นเทคโนโลยีมาสิบปี การจัดใหม่จะกระทบกระเทือนมากไหม?” กระทบ แต่เบากว่าที่คิดมาก คุณไม่ต้องรื้อทั้งบริษัท เริ่มจากเลือกกระแสคุณค่าที่ติดขัดที่สุดสายหนึ่งก่อน (มักเป็นสายที่ถูกบ่นมากที่สุด) แล้วตั้งเป็น stream-aligned team ทดลอง แบบ CIO คนนั้น 4 ถึง 8 สัปดาห์ ทีมเล็ก ๆ หนึ่งทีม ก็เห็นความเปลี่ยนแปลงความเร็วการส่งมอบอย่างชัดเจน ใช้ผลลัพธ์โน้มน้าวรอบต่อไป ได้ผลกว่าใช้ PPT โน้มน้าว

“สิ่งนี้เกี่ยวกับการเปลี่ยนผ่าน AI ที่ผมกำลังทำอยู่ยังไง?” เกี่ยวโดยตรง AI ไม่ได้ซ่อมองค์กรที่จับคู่ผิด มันขยายสิ่งที่มีอยู่แล้ว: ทีมประสิทธิภาพสูงได้ AI มาจะเร็วขึ้น ทีมจับคู่ผิดได้ AI มาจะสร้างหนี้เร็วขึ้น การวินิจฉัยองค์กรต้องมาก่อนการจัดซื้อเครื่องมือ นี่คือเหตุผลที่ผมวาง “การประเมินความสามารถ” ไว้ข้างหน้าในระเบียบวิธีหลัก 7-Step AI Transformation Coaching Framework ของผม: ดูองค์กรและคนก่อน ค่อยพูดเรื่องเครื่องมือ

“เราจัดสี่ประเภททีมไม่ครบจะทำยังไง?” องค์กรส่วนใหญ่จัดไม่ครบ และไม่จำเป็นต้องครบ สองสิ่งที่ควรมีก่อนคือ stream-aligned team (เพื่อรับประกันการส่งมอบตลอดสาย) และ platform team (เพื่อไม่ต้องประดิษฐ์ล้อซ้ำ) enabling team และ complicated-subsystem team ตั้งขึ้นตามความจำเป็น หลายองค์กรยังไม่มีตั้งแต่แรกก็ปกติ อย่าสร้างทีมขึ้นมาเพียงเพื่อให้ครบสี่ประเภท นั่นคือเอาหางบังหัว

เจ็ด บทเรียนสำหรับผู้ตัดสินใจ

ข้อหนึ่ง: ก่อนเอา AI เข้ามา วาดแผนผัง team topology เสียก่อน ก่อนที่คุณจะเอาเครื่องมือ AI เข้ามาครั้งล่าสุด คุณเคยวาดแผนผัง topology ของทีมไหม ทีมที่หั่นตามชั้นเทคโนโลยีผิดที่ ต่อให้ AI แกร่งแค่ไหน ก็แค่เร่งสร้างหนี้บนโครงสร้างที่ผิด ข้อนี้ตัดการลงทุน IT ที่ไร้ผลขององค์กรใหญ่ออกไปได้อย่างน้อยครึ่งหนึ่ง การลงมือเป็นรูปธรรม: เอาทีมทั้งหมดมาลิสต์ ทำเครื่องหมายว่าทีมใดรับผิดชอบกระแสคุณค่าใดตลอดสาย — ทีมใดทำเครื่องหมายไม่ได้ คือทีมที่หั่นตามชั้นเทคโนโลยี ให้ระบุเป็นเป้าหมายจัดใหม่ก่อน

ข้อสอง: ตรวจสุขภาพ cognitive load ครั้งหนึ่ง อย่าถามแค่ “คนพอหรือไม่” ถามว่าทีมใดดูแลระบบที่ไม่เกี่ยวข้องกันมากกว่า 5 ระบบพร้อมกัน คนใดต่ออัปสตรีมมากกว่า 3 สายพร้อมกัน การเปิดเผยสิ่งเหล่านี้มีประโยชน์มากกว่าการเพิ่มคนหรือเพิ่มกระบวนการมาก AI ช่วยแบกภาระส่วนหนึ่งได้ (เขียนโค้ด ค้นหาข้อมูล คัดกรองเบื้องต้น) โดยมีเงื่อนไขว่าคุณกระจายภาระใหม่อย่างตั้งใจ ไม่ใช่ยัดให้ทีมที่โอเวอร์โหลดอยู่แล้วแบกภาระ “นำ AI ไปใช้” เพิ่มอีก

ข้อสาม: ถือแพลตฟอร์มภายในเป็นสินค้า ไม่งั้นย่อมกลายเป็นเอาท์ซอร์ส แพลตฟอร์มต้องมีผู้ใช้ มี roadmap มี SLA มีคนรับผิดชอบอัตราการนำไปใช้ ในยุค AI แพลตฟอร์มนี้ยังต้องรวม model gateway คลัง prompt และสภาพแวดล้อมรัน agent เข้ามาด้วย — นี่คือพื้นฐานที่บทความหลังเรื่อง “กรอบการนำไปใช้” จะเปิดต่อ

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

ตรวจสอบย้อนกลับ (ตอบอย่าปรุงแต่ง): ทีมของคุณถูกหั่นตามกระแสคุณค่า หรือหั่นตามฟรอนต์เอนด์/แบ็กเอนด์/ดูแลระบบ/ความปลอดภัย คนที่ยุ่งที่สุดของคุณ แบกของไม่เกี่ยวข้องกันมากกว่า 3 อย่างพร้อมกันไหม แพลตฟอร์มภายในไม่มีคนใช้ คือไฟแดงของความล้มเหลวของ platformization ถ้าข้อใดข้อหนึ่งตอบแล้วไม่มั่นใจ ก่อนเอา AI เข้ามา ให้จัดทีมใหม่เสียก่อน — นี่คือการลงมือทำล่วงหน้าที่ให้ผลตอบแทนสูงที่สุด

ก้าวต่อไป

นี่คือบทความที่ 2 ของซีรีส์ “เปลี่ยนแปลงวิศวกรรมซอฟต์แวร์ยุค AI” (ตอนที่ 172 ของคอลัมน์ “Learn AI Slowly”) เดินทางจาก Conway (องค์กรกำหนดสถาปัตยกรรม) ไปสู่ Team Topologies (จะออกแบบองค์กรอย่างไร) บทความต่อไป (ตอนที่ 3) จะดูคำถามที่พื้นฐานยิ่งกว่า: เมื่อ AI ทำให้การผลิตโค้ดแทบฟรี คอขวดของวิศวกรรมซอฟต์แวร์จะย้ายไปอยู่ที่ไหน?

หมายเหตุซีรีส์: ซีรีส์นี้ติดตามความก้าวหน้าล่าสุดของเครื่องมือเขียนโปรแกรม AI โครงสร้างองค์กร และกระบวนทัศน์วิศวกรรมซอฟต์แวร์อย่างต่อเนื่อง เช่น การเปลี่ยนแปลงใหม่ของกฎของ Conway ในยุค AI agent ปี 2026 ความเป็นผู้ใหญ่ของระบบนิเวศเครื่องมือล่าสุด ฯลฯ ติดตามซีรีส์นี้เพื่อรับข้อมูลเชิงลึกที่อัปเดตต่อเนื่อง

เกี่ยวกับซีรีส์นี้

“เปลี่ยนแปลงวิศวกรรมซอฟต์แวร์ยุค AI” คือซีรีส์วิจัยเชิงลึกสำหรับ CIO/CDO/CTO และผู้รับผิดชอบดิจิทัลในอุตสาหกรรมโทรคมนาคม การเงิน การผลิต และอีคอมเมิร์ซ รวม 15 ตอน อ้างอิงงานวิจัยและรายงานอุตสาหกรรมกว่า 200 ชิ้น มอบข้อมูลอ้างอิงเพื่อการตัดสินใจที่มีการระบุระดับหลักฐาน

ผมเป็นอดีตวิศวกร IBM และโค้ชที่ได้รับการรับรองจาก ICF เคยทำโปรเจ็กต์ลงมือ AI/ดิจิทัลของผู้ให้บริการโทรคมนาคมและองค์กรขนาดใหญ่ สิ่งที่เขียนที่นี่คือการตัดสินจากสนามจริงที่ผมร่วมเดินฝ่าฟันกับองค์กรต่าง ๆ

อ่านจบแล้วหากคุณกำลังคิดว่า “บริษัทเราเป็นแบบนี้ไหม” — ผมทำ “แบบประเมินตนเอง Team Topologies 20 ข้อ” ไว้ และยังเปิดให้ปรึกษา 1V1 แบบสนทนา 30 นาที เพื่อช่วยคุณระบุกระแสคุณค่าที่ควรจัดใหม่ก่อนเป็นอันดับแรก หากสนใจ: ทักทามที่บัญชีสาธารณะ “AI Decision Maker Insight” หรืออีเมล coach@iaiuse.com

แหล่งอ้างอิง

  • Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press. (แหล่งที่มาขั้นต้นของสี่ทีม / สามการโต้ตอบ / cognitive load — แหล่งระดับ 1)
  • Conway, M. (1968). How Do Committees Invent? Datamation.
  • Forsgren, Humble & Kim (2018). Accelerate. IT Revolution Press.
  • IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations. (บทสรุปการรับชมหลายองค์กร — ระดับ 2) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
  • Netflix Spinnaker / Spotify Backstage — ตัวอย่างการทำแพลตฟอร์มภายในเป็นสินค้า
  • AutoTrader UK — เคสรับชมที่ TT อ้างอิง (รายละเอียดรอเติมลิงก์ teamtopologies.com)
  • คลังเคสทางการ: https://teamtopologies.com/examples