Enabling Teams (ทีมสนับสนุน)

เราเคยพูดถึง enabling team ครั้งล่าสุดใน "Sharing Specialists" ในบริบทของ user interface แต่จริงๆ แล้วมันมีการใช้งานที่กว้างกว่านั้นมาก ตามที่อธิบายไว้ใน Team Topologies นี่คือทีมที่ทำงานเพื่อสนับสนุน stream-aligned team ของเรา ไม่ว่าทีม stream-aligned ที่เป็นเจ้าของไมโครเซอร์วิสและโฟกัสแบบ end-to-end ของเราจะกำลังโฟกัสไปที่การส่งมอบฟังก์ชันที่ผู้ใช้เห็นตรงไหน พวกเขาก็ต้องการความช่วยเหลือจากคนอื่นเพื่อทำงานให้สำเร็จ เมื่อพูดถึง user interface เราพูดถึงแนวคิดของการมี enabling team ที่ช่วยสนับสนุนทีมอื่นในการสร้างประสบการณ์ผู้ใช้ที่มีประสิทธิภาพและสอดคล้องกัน ดังที่แสดงใน Figure 15-2 เราสามารถจินตนาการสิ่งนี้เป็น enabling team ที่ทำงานสนับสนุนหลายๆ stream-aligned team ในแง่มุมที่ตัดข้ามหลายทีม (cross-cutting)

Figure 15-2. Enabling team สนับสนุน stream-aligned team หลายทีม

แต่ enabling team มีได้หลากหลายรูปแบบและขนาด

ลองดู Figure 15-3 แต่ละทีมตัดสินใจเลือกภาษาโปรแกรมที่แตกต่างกัน เมื่อมองแยกทีละทีม การตัดสินใจแต่ละอย่างดูสมเหตุสมผล—แต่ละทีมเลือกภาษาโปรแกรมที่ตัวเองพอใจที่สุด แต่แล้วองค์กรโดยรวมล่ะ? คุณอยากต้องซัพพอร์ตภาษาโปรแกรมหลายภาษาภายในองค์กรของคุณจริงๆ หรือ? มันทำให้การหมุนเวียนคนระหว่างทีมซับซ้อนขึ้นแค่ไหน และมันส่งผลต่อการจ้างงานอย่างไร?

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

ในกลุ่มสนับสนุนแบบ cross-cutting เหล่านี้เองที่ผมเห็นว่าเป็นที่ที่เหมาะสมสำหรับสถาปนิก (architect) ที่จะประจำอยู่ อย่างน้อยก็บางส่วนของเวลาทำงาน สถาปนิกแบบเก่าจะบอกคนอื่นว่าต้องทำอะไร แต่ในองค์กรสมัยใหม่ที่กระจายอำนาจ สถาปนิกทำหน้าที่สำรวจภาพรวม จับตาแนวโน้ม ช่วยเชื่อมโยงผู้คน และเป็นที่ปรึกษาให้ทีมอื่นทำงานให้สำเร็จ พวกเขาไม่ใช่หน่วยควบคุมในโลกแบบนี้ พวกเขาเป็นอีกหนึ่งฟังก์ชันสนับสนุน (มักมีชื่อใหม่—ผมเคยเห็นคำอย่าง principal engineer ถูกใช้เรียกคนที่ทำหน้าที่แบบที่ผมมองว่าเป็นสถาปนิก) เราจะสำรวจบทบาทของสถาปนิกเพิ่มเติมใน Chapter 16 .

Figure 15-3. แต่ละทีมเลือกภาษาโปรแกรมที่แตกต่างกัน

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

Communities of Practice (ชุมชนแนวปฏิบัติ)

community of practice (CoP) เป็นกลุ่มแบบ cross-cutting ที่ส่งเสริมการแบ่งปันและการเรียนรู้ระหว่างเพื่อนร่วมงาน เมื่อทำได้ดี community of practice เป็นวิธีที่ยอดเยี่ยมในการสร้างองค์กรที่ผู้คนสามารถเรียนรู้และเติบโตอย่างต่อเนื่อง ในหนังสือที่ยอดเยี่ยมของเธอเกี่ยวกับหัวข้อนี้ Building Successful Communities of Practice , 11 Emily Webber เขียนว่า:

Community of practice สร้างสภาพแวดล้อมที่เหมาะสมสำหรับการเรียนรู้ทางสังคม การเรียนรู้จากประสบการณ์ และหลักสูตรที่ครบถ้วน นำไปสู่การเรียนรู้ที่เร่งขึ้นสำหรับสมาชิก...มันสามารถส่งเสริมวัฒนธรรมการเรียนรู้ที่ผู้คนแสวงหาวิธีที่ดีกว่าในการทำสิ่งต่างๆ แทนที่จะใช้แค่โมเดลที่มีอยู่แล้ว

ทีนี้ ผมเชื่อว่าในบางกรณี กลุ่มเดียวกันอาจเป็นทั้ง CoP และ enabling team ได้ แต่จากประสบการณ์ของผมเอง เรื่องนี้เกิดขึ้นได้ยาก แต่ก็มีความทับซ้อนกันอย่างแน่นอน ทั้ง enabling team และ community of practice ต่างก็ให้ข้อมูลเชิงลึกเกี่ยวกับสิ่งที่เกิดขึ้นในทีมต่างๆ ทั่วองค์กรของคุณ ข้อมูลเชิงลึกนี้ช่วยให้คุณเข้าใจว่าคุณจำเป็นต้องปรับสมดุลระหว่างการปรับให้เหมาะสมระดับส่วนกลางกับระดับท้องถิ่นหรือไม่ หรือช่วยให้คุณระบุความจำเป็นในการมีความช่วยเหลือจากส่วนกลางมากขึ้น แต่ความแตกต่างอยู่ที่ความรับผิดชอบและความสามารถของแต่ละกลุ่ม

สมาชิกของ enabling team มักทำงานเต็มเวลาในฐานะส่วนหนึ่งของทีม หรือไม่ก็มีเวลาส่วนใหญ่ที่ถูกจัดสรรไว้เฉพาะสำหรับจุดประสงค์นี้ ด้วยเหตุนี้ พวกเขาจึงมี bandwidth มากขึ้นที่จะนำการเปลี่ยนแปลงไปปฏิบัติจริง—ทำงานร่วมกับทีมอื่นๆ และช่วยเหลือพวกเขาจริงๆ Community of practice โฟกัสไปที่การส่งเสริมการเรียนรู้มากกว่า—บุคคลในกลุ่มมักเข้าร่วมฟอรัมแค่ไม่กี่ชั่วโมงต่อสัปดาห์เป็นอย่างมาก และสมาชิกของกลุ่มแบบนี้มักเปลี่ยนแปลงไปมาได้

CoP และ enabling team สามารถทำงานร่วมกันได้อย่างมีประสิทธิภาพมากเลยทีเดียว บ่อยครั้งที่ CoP สามารถให้ข้อมูลเชิงลึกที่มีค่าซึ่งช่วยให้ enabling team เข้าใจสิ่งที่จำเป็นได้ดีขึ้น ลองนึกภาพ Kubernetes CoP ที่แบ่งปันประสบการณ์ว่าการทำงานกับ development cluster ของบริษัทลำบากแค่ไหน กับทีม platform ที่ดูแล cluster นั้น พูดถึงเรื่อง platform team แล้ว นั่นเป็นหัวข้อที่ควรค่าแก่การเจาะลึกต่อไป

The Platform (แพลตฟอร์ม)

กลับมาที่ stream-aligned team ที่มีความผูกพันแบบหลวมๆ ของเรา เราคาดหวังให้พวกเขาทำการทดสอบของตัวเองใน environment ที่แยกออกมาต่างหาก จัดการ deployment ในแบบที่ทำได้ระหว่างวัน และเปลี่ยนแปลงสถาปัตยกรรมระบบของตัวเองเมื่อจำเป็น ทั้งหมดนี้ดูเหมือนจะผลักความรับผิดชอบ—และงาน—เข้าไปในทีมเหล่านี้มากขึ้นเรื่อยๆ แนวคิดของ enabling team โดยทั่วไปช่วยได้ตรงนี้ แต่ท้ายที่สุดแล้ว stream-aligned team ต้องการชุดเครื่องมือแบบ self-service ที่ทำให้พวกเขาทำ งานของตัวเองได้—นี่คือ แพลตฟอร์ม

อันที่จริง ถ้าไม่มีแพลตฟอร์ม คุณอาจพบว่าการเปลี่ยนแปลงองค์กรเป็นเรื่องยาก ในบทความ "Convergence to Kubernetes," 12 Paul Ingles ซีทีโอของ RVU แบ่งปันประสบการณ์ของเว็บไซต์เปรียบเทียบราคา Uswitch ที่ย้ายออกจากการใช้บริการ AWS ระดับ low-level โดยตรง ไปสู่แพลตฟอร์มที่เป็น abstraction ระดับสูงกว่าโดยใช้ Kubernetes แนวคิดคือแพลตฟอร์มนี้ช่วยให้ stream-aligned team ของ RVU โฟกัสไปที่การส่งมอบฟีเจอร์ใหม่ๆ ได้มากขึ้น และใช้เวลากับการจัดการ infrastructure น้อยลง ดังที่ Paul กล่าวไว้:

เราไม่ได้เปลี่ยนองค์กรของเราเพราะอยากใช้ Kubernetes เราใช้ Kubernetes เพราะเราอยากเปลี่ยนองค์กรของเรา

แพลตฟอร์มที่สามารถ implement ฟังก์ชันการทำงานร่วม เช่น ความสามารถในการจัดการ desired state ของไมโครเซอร์วิส การรวบรวม log และการยืนยันตัวตน/อนุญาตสิทธิ์ระหว่างไมโครเซอร์วิส สามารถสร้างการปรับปรุงผลิตภาพได้อย่างมหาศาล และทำให้ทีมรับผิดชอบมากขึ้นได้โดยไม่ต้องเพิ่มปริมาณงานอย่างรุนแรง อันที่จริง แพลตฟอร์มควรให้ bandwidth แก่ทีมมากขึ้นเพื่อโฟกัสไปที่การส่งมอบฟีเจอร์

The platform team (ทีมแพลตฟอร์ม)

แพลตฟอร์มต้องการคนมารันและจัดการมัน tech stack เหล่านี้อาจซับซ้อนพอที่จะต้องการความเชี่ยวชาญเฉพาะทาง แต่สิ่งที่ผมกังวลคือ บางครั้งมันง่ายเกินไปที่ platform team จะลืมไปว่าตัวเองมีอยู่เพื่ออะไร

Platform team มีผู้ใช้ เหมือนกับที่ทีมอื่นๆ ก็มีผู้ใช้ ผู้ใช้ของ platform team คือนักพัฒนาคนอื่นๆ—งานของคุณถ้าคุณอยู่ใน platform team คือทำให้ชีวิตของพวกเขาง่ายขึ้น (นี่คืองานของ enabling team ทุกทีมอยู่แล้ว) นั่นหมายความว่าแพลตฟอร์มที่คุณสร้างขึ้นต้องตอบโจทย์ความต้องการของทีมที่ใช้มัน และยังหมายความว่าคุณต้องทำงานร่วมกับทีมที่ใช้แพลตฟอร์มของคุณ ไม่ใช่แค่ช่วยให้พวกเขาใช้มันได้ดี แต่ยังต้องรับฟัง feedback และความต้องการของพวกเขาเพื่อปรับปรุงแพลตฟอร์มที่คุณส่งมอบด้วย

ในอดีต ผมชอบเรียกทีมแบบนี้ว่า "delivery services" หรือ "delivery support" เพื่อสื่อเป้าหมายของมันให้ชัดเจนขึ้น จริงๆ แล้วงานของ platform team ไม่ใช่ การสร้างแพลตฟอร์ม แต่คือการทำให้การพัฒนาและส่งมอบฟังก์ชันการทำงานเป็นเรื่องง่าย การสร้างแพลตฟอร์มเป็นแค่วิธีหนึ่งที่สมาชิกของ platform team ใช้เพื่อบรรลุเป้าหมายนี้ ผมเป็นห่วงว่าการเรียกตัวเองว่า platform team อาจทำให้พวกเขามองว่าทุกปัญหาเป็นสิ่งที่ควรและสามารถแก้ได้ด้วยแพลตฟอร์ม แทนที่จะคิดกว้างขึ้นถึงวิธีอื่นๆ ในการทำให้ชีวิตนักพัฒนาง่ายขึ้น

เช่นเดียวกับ enabling team ที่ดีทุกทีม platform team ต้องทำงานเกือบจะเหมือนที่ปรึกษาภายในองค์กรในระดับหนึ่ง ถ้าคุณอยู่ใน platform team คุณต้องออกไปหาว่าผู้คนกำลังเจอปัญหาอะไร และทำงานร่วมกับพวกเขาเพื่อช่วยแก้ปัญหาเหล่านั้น แต่เนื่องจากคุณก็ต้องสร้างแพลตฟอร์มด้วย คุณก็ต้องมีงานด้าน product development เข้มข้นด้วยเช่นกัน อันที่จริง การใช้แนวทางแบบ product development ในการสร้างแพลตฟอร์มของคุณเป็นความคิดที่ดีมาก และอาจเป็นที่ที่ดีเยี่ยมในการช่วยสร้าง product owner รุ่นใหม่ขึ้นมาด้วย

The paved road (ถนนลาดยาง)

แนวคิดที่ได้รับความนิยมในการพัฒนาซอฟต์แวร์คือแนวคิดของ "the paved road" (ถนนลาดยาง) แนวคิดคือคุณสื่อสารอย่างชัดเจนว่าคุณต้องการให้สิ่งต่างๆ ถูกทำอย่างไร แล้วจึงจัดหากลไกที่ทำให้สิ่งเหล่านั้นทำได้อย่างง่ายดาย ตัวอย่างเช่น คุณอาจต้องการให้แน่ใจว่าไมโครเซอร์วิสทั้งหมดสื่อสารกันผ่าน mutual TLS คุณก็สามารถสนับสนุนสิ่งนี้ได้โดยจัดหา framework หรือ deployment platform ทั่วไปที่จะส่งมอบ mutual TLS โดยอัตโนมัติสำหรับไมโครเซอร์วิสที่รันอยู่บนนั้น แพลตฟอร์มเป็นวิธีที่ยอดเยี่ยมในการส่งมอบถนนลาดยางนั้น

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

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

ถ้าเรามองแพลตฟอร์มเป็นถนนลาดยาง การทำให้มันเป็นทางเลือก (optional) จะสร้างแรงจูงใจให้ platform team ทำให้แพลตฟอร์มใช้งานง่าย นี่คือ Paul Ingles อีกครั้ง เกี่ยวกับการวัดประสิทธิภาพของ platform team: 13

เราตั้ง [objectives and key results (OKR)] เกี่ยวกับจำนวนทีมที่เราอยากให้ใช้แพลตฟอร์ม จำนวนแอปพลิเคชันที่ใช้บริการ autoscaling ของแพลตฟอร์ม สัดส่วนของแอปพลิเคชันที่เปลี่ยนมาใช้บริการ dynamic credentials ของแพลตฟอร์ม และอื่นๆ บาง OKR เราติดตามในระยะยาว บางอันก็ช่วยชี้แนวทางความคืบหน้าสำหรับหนึ่งไตรมาสแล้วเราก็เปลี่ยนไปใช้ตัวชี้วัดอื่นแทน

เราไม่เคยบังคับให้ใช้แพลตฟอร์ม ดังนั้นการตั้ง key result สำหรับจำนวนทีมที่ onboard เข้ามา บังคับให้เราต้องโฟกัสไปที่การแก้ปัญหาที่จะขับเคลื่อนการยอมรับใช้งาน เรายังมองหาตัวชี้วัดความคืบหน้าที่เป็นธรรมชาติด้วย เช่น สัดส่วนของ traffic ที่ให้บริการโดยแพลตฟอร์ม และสัดส่วนของรายได้ที่ให้บริการผ่านบริการของแพลตฟอร์ม ล้วนเป็นตัวอย่างที่ดีของสิ่งนั้น

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

การเปลี่ยนไปสู่ทีมที่เป็นอิสระและ stream-aligned มากขึ้นไม่ได้ขจัดความจำเป็นในการมีวิสัยทัศน์ทางเทคนิคที่ชัดเจน หรือความชัดเจนในบางสิ่งที่ทุกทีมต้องทำ ถ้ามีข้อจำกัดที่เป็นรูปธรรม (เช่น ความจำเป็นที่ต้องไม่ผูกติดกับ cloud vendor รายใดรายหนึ่ง) หรือข้อกำหนดเฉพาะที่ทุกทีมต้องปฏิบัติตาม (เช่น PII ทั้งหมดต้องถูกเข้ารหัสขณะจัดเก็บด้วยอัลกอริทึมที่กำหนด) สิ่งเหล่านั้นก็ยังต้องถูกสื่อสารอย่างชัดเจน และเหตุผลของมันก็ต้องชัดเจนด้วย จากนั้นแพลตฟอร์มก็สามารถมีบทบาทในการทำให้สิ่งเหล่านี้ทำได้ง่าย เมื่อใช้แพลตฟอร์ม คุณก็อยู่บนถนนลาดยาง—คุณจะทำสิ่งที่ถูกต้องหลายอย่างได้โดยไม่ต้องออกแรงมาก

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