Toward Stream-Aligned Teams (มุ่งสู่ Stream-Aligned Teams)

ผมคิดว่าการมีทีม frontend เฉพาะทางโดยทั่วไปแล้วเป็นความผิดพลาด หากคุณกำลังพยายาม optimize เพื่อ throughput ที่ดี เพราะมันสร้างจุด handoff ใหม่ๆ ในองค์กรของคุณ ทำให้ทุกอย่างช้าลง ทีมของเราควรจะจัดวางตามชิ้นส่วนของ functionality แบบ end-to-end เพื่อให้แต่ละทีมสามารถส่งมอบฟีเจอร์ใหม่ให้กับลูกค้าได้ พร้อมกับลดปริมาณการประสานงานที่จำเป็นลง รูปแบบที่ผมชอบคือให้ทีมหนึ่งเป็นเจ้าของการส่งมอบ functionality แบบ end-to-end ในส่วนหนึ่งของโดเมนนั้นๆ ซึ่งตรงกับสิ่งที่ Matthew Skelton และ Manuel Pais อธิบายไว้ว่าเป็น stream-aligned teams ในหนังสือของพวกเขาชื่อ Team Topologies . 1 พวกเขาอธิบายไว้ว่า

stream-aligned team คือทีมที่จัดวางให้สอดคล้องกับสายงานคุณค่า (stream of work) เดียวที่มีคุณค่า...[ทีม]ได้รับมอบอำนาจให้สร้างและส่งมอบคุณค่าให้กับลูกค้าหรือผู้ใช้ได้อย่างรวดเร็ว ปลอดภัย และเป็นอิสระที่สุดเท่าที่จะทำได้ โดยไม่ต้องส่งต่องานให้ทีมอื่นมาทำบางส่วนแทน

ในแง่หนึ่ง เรากำลังพูดถึง full stack teams (มากกว่าจะเป็น full stack developer) 2 ทีมที่มีความรับผิดชอบแบบ end-to-end ในการส่งมอบ functionality ที่ผู้ใช้เห็นโดยตรง ก็มีแนวโน้มที่จะมีความเชื่อมโยงกับผู้ใช้ปลายทางที่ชัดเจนกว่าเช่นกัน ผมเคยเห็นทีม "backend" ที่มีความเข้าใจเลือนรางว่าซอฟต์แวร์ทำอะไรหรือผู้ใช้ต้องการอะไรอยู่บ่อยครั้ง ซึ่งทำให้เกิดความเข้าใจผิดต่างๆ นานาเมื่อต้องสร้าง functionality ใหม่ ในทางกลับกัน ทีมแบบ end-to-end จะสร้างความเชื่อมโยงโดยตรงกับผู้ใช้ซอฟต์แวร์ที่พวกเขาสร้างได้ง่ายกว่ามาก พวกเขาสามารถโฟกัสกับการทำให้แน่ใจว่าคนที่พวกเขากำลังให้บริการได้รับสิ่งที่ต้องการจริงๆ

ยกตัวอย่างที่เป็นรูปธรรม ผมเคยใช้เวลาทำงานร่วมกับ FinanceCo บริษัท Fintech ที่ประสบความสำเร็จและกำลังเติบโตในยุโรป ที่ FinanceCo แทบทุกทีมทำงานกับซอฟต์แวร์ที่ส่งผลโดยตรงต่อประสบการณ์ของลูกค้า และมี key performance indicator (KPI) ที่เน้นลูกค้าเป็นศูนย์กลาง ความสำเร็จของแต่ละทีมไม่ได้วัดจากจำนวนฟีเจอร์ที่ส่งมอบมากเท่ากับการช่วยปรับปรุงประสบการณ์ของคนที่ใช้ซอฟต์แวร์ มันชัดเจนมากว่าการเปลี่ยนแปลงหนึ่งๆ ส่งผลต่อลูกค้าอย่างไร สิ่งนี้เป็นไปได้ก็เพราะทีมส่วนใหญ่มีความรับผิดชอบที่เชื่อมโยงกับลูกค้าโดยตรงในแง่ของซอฟต์แวร์ที่พวกเขาส่งมอบ เมื่อคุณอยู่ห่างจากผู้ใช้ปลายทางมากขึ้น มันก็ยากขึ้นที่จะเข้าใจว่าสิ่งที่คุณทำนั้นประสบความสำเร็จหรือไม่ และคุณอาจลงเอยด้วยการโฟกัสกับเป้าหมายที่ห่างไกลจากสิ่งที่คนใช้ซอฟต์แวร์ของคุณสนใจจริงๆ

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

Sharing Specialists (การแบ่งปันผู้เชี่ยวชาญ)

นักพัฒนาฝีมือดีหาได้ยากอยู่แล้ว และยิ่งยากขึ้นไปอีกเมื่อคุณต้องการนักพัฒนาที่มีความเชี่ยวชาญเฉพาะทาง ในด้านส่วนติดต่อผู้ใช้ เช่น ถ้าคุณมีทั้ง native mobile และ web interface คุณอาจต้องการคนที่มีประสบการณ์ทั้งด้าน iOS, Android และ web development สมัยใหม่ นี่ยังไม่นับว่าคุณอาจต้องการ interaction designer, graphic designer, ผู้เชี่ยวชาญด้าน accessibility โดยเฉพาะอีกด้วย คนที่มีทักษะเชิงลึกในสายงานที่ค่อนข้าง "แคบ" เหล่านี้อาจมีจำนวนน้อย และมักมีงานล้นมือตลอดเวลา

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

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

ผมยังจำได้ว่าสมัยก่อนการเปลี่ยนแปลงฐานข้อมูลทุกอย่างต้องผ่านทีมกลางของ database administrator (DBA) นักพัฒนาแทบไม่มีความรู้เรื่องการทำงานของฐานข้อมูลเลย จึงมักสร้างซอฟต์แวร์ที่ใช้ฐานข้อมูลได้ไม่ดีนัก ยิ่งไปกว่านั้น งานส่วนใหญ่ที่ DBA ผู้มากประสบการณ์ต้องทำก็เป็นการเปลี่ยนแปลงเล็กๆ น้อยๆ เมื่องานด้านฐานข้อมูลถูกดึงเข้ามาอยู่ในทีมส่งมอบมากขึ้น นักพัฒนาโดยรวมก็เข้าใจฐานข้อมูลดีขึ้น และสามารถทำงานง่ายๆ ได้เอง ทำให้ DBA ที่มีคุณค่ามีเวลาไปโฟกัสกับปัญหาฐานข้อมูลที่ซับซ้อนกว่า ซึ่งใช้ทักษะและประสบการณ์เชิงลึกของพวกเขาได้ดีกว่า การเปลี่ยนแปลงในลักษณะเดียวกันนี้ก็เกิดขึ้นในพื้นที่ของ operations และ tester เช่นกัน โดยงานเหล่านั้นถูกดึงเข้ามาอยู่ในทีมมากขึ้น

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

เคล็ดลับคือการหาวิธีที่มีประสิทธิภาพมากขึ้นในการใช้งานผู้เชี่ยวชาญของคุณ โดยหลักการแล้ว พวกเขาควรถูกฝังตัว (embed) อยู่ในทีมต่างๆ แต่บางครั้งอาจไม่มีงานมากพอที่จะรับประกันการอยู่ประจำเต็มเวลาในทีมใดทีมหนึ่ง ซึ่งในกรณีนั้นพวกเขาอาจแบ่งเวลาทำงานให้หลายทีม อีกรูปแบบหนึ่งคือการมีทีมเฉพาะทางที่มีหน้าที่ชัดเจนคือ enable ทีมอื่นๆ ใน Team Topologies Skelton และ Pais อธิบายทีมแบบนี้ว่าเป็น enabling team หน้าที่ของพวกเขาคือออกไปช่วยทีมอื่นๆ ที่โฟกัสกับการส่งมอบฟีเจอร์ใหม่ให้ทำงานได้ดีขึ้น คุณอาจมองทีมเหล่านี้เหมือนเป็นที่ปรึกษาภายในองค์กร พวกเขาสามารถเข้ามาและใช้เวลาที่มุ่งเป้ากับ stream-aligned team หนึ่งๆ ช่วยให้ทีมนั้นพึ่งพาตัวเองได้มากขึ้นในด้านใดด้านหนึ่ง หรือมอบเวลาช่วยเหลือเฉพาะกิจเพื่อ roll out งานที่ยากเป็นพิเศษ

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

Ensuring Consistency (การรักษาความสม่ำเสมอ)

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

อย่างไรก็ตาม ยังมีวิธีอื่นที่ช่วยรักษาความสม่ำเสมอในระดับหนึ่งข้ามทีมได้ ถ้าคุณใช้โมเดล enabling team ที่ผู้เชี่ยวชาญใช้เวลาไปกับหลายทีม พวกเขาสามารถช่วยให้แน่ใจว่างานที่แต่ละทีมทำนั้นสม่ำเสมอกัน การสร้างทรัพยากรที่ใช้ร่วมกัน เช่น living CSS style guide หรือ UI component ที่ใช้ร่วมกันก็ช่วยได้เช่นกัน

ตัวอย่างที่เป็นรูปธรรมของการใช้ enabling team เพื่อช่วยเรื่องความสม่ำเสมอคือทีม Origami ของ Financial Times ที่สร้าง web component ร่วมกับทีมออกแบบ ซึ่งบรรจุอัตลักษณ์ของแบรนด์เอาไว้ ทำให้มั่นใจได้ว่าหน้าตาและความรู้สึกจะสม่ำเสมอในทุก stream-aligned team enabling team แบบนี้ให้ความช่วยเหลือสองรูปแบบ อย่างแรกคือแบ่งปันความเชี่ยวชาญผ่าน component ที่สร้างไว้แล้ว และอย่างที่สองคือช่วยให้แน่ใจว่า UI มอบประสบการณ์ผู้ใช้ที่สม่ำเสมอ

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

เรื่องนี้ยิ่งเห็นได้ชัดขึ้นไปอีกเมื่อคุณดู web control panel ของ Amazon Web Services (AWS) ผลิตภัณฑ์ต่างๆ ใน AWS มี interaction model ที่แตกต่างกันอย่างมาก จน UI ดูสับสนวุ่นวาย อย่างไรก็ตาม นี่ดูเหมือนจะเป็นผลลัพธ์ทางตรรกะของแนวทางของ Amazon ที่ต้องการลดการประสานงานภายในระหว่างทีม

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

Working Through Technical Challenges (การรับมือกับความท้าทายด้านเทคนิค)

เราได้ผ่านวิวัฒนาการที่น่าสนใจมาหลายครั้งเมื่อพูดถึงการพัฒนาส่วนติดต่อผู้ใช้ ตั้งแต่ green-screen terminal ที่เป็น textual user interface ไปจนถึงแอปพลิเคชันเดสก์ท็อปที่ซับซ้อน เว็บ และตอนนี้คือประสบการณ์บนมือถือแบบ native ในหลายๆ แง่ เราวนกลับมาที่จุดเดิมและไปไกลกว่านั้นด้วยซ้ำ ไคลเอนต์แอปพลิเคชันของเราตอนนี้ถูกสร้างขึ้นด้วยความซับซ้อนและความล้ำสมัยจนเทียบเคียงได้กับความซับซ้อนของแอปพลิเคชันเดสก์ท็อปที่เคยเป็นกระแสหลักในการพัฒนา UI ช่วงทศวรรษแรกของศตวรรษที่ 21

ในแง่หนึ่ง ยิ่งสิ่งต่างๆ เปลี่ยนไปมากเท่าไร มันก็ยิ่งเหมือนเดิมมากขึ้นเท่านั้น เรามักยังคงทำงานกับ UI control แบบเดิมๆ เหมือนเมื่อ 20 ปีก่อน ไม่ว่าจะเป็นปุ่ม checkbox ฟอร์ม combo box และอื่นๆ เราเพิ่ม component ใหม่ๆ เข้ามาบ้าง แต่น้อยกว่าที่คุณอาจคิด สิ่งที่เปลี่ยนไปคือเทคโนโลยีที่เราใช้สร้างส่วนติดต่อผู้ใช้แบบกราฟิกเหล่านี้ตั้งแต่แรก

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

โดยพื้นฐานแล้ว ผู้ใช้ของเราต้องการโต้ตอบกับซอฟต์แวร์ของเราในแบบที่ราบรื่นที่สุดเท่าที่จะเป็นไปได้ ไม่ว่าจะผ่านเบราว์เซอร์บนเดสก์ท็อป หรือผ่านแอปมือถือแบบ native หรือ web ผลลัพธ์ก็เหมือนกันคือผู้ใช้โต้ตอบกับซอฟต์แวร์ของเราผ่านกระจกบานเดียว พวกเขาไม่ควรต้องสนใจว่า UI ถูกสร้างขึ้นแบบ modular หรือ monolithic ดังนั้นเราจึงต้องมองหาวิธีแยกส่วนติดต่อผู้ใช้ของเราออกจากกันแล้วนำกลับมารวมกันใหม่ ในขณะที่ยังต้องแก้ปัญหาที่เกิดจาก single-page application อุปกรณ์มือถือ และอื่นๆ อีกด้วย ประเด็นเหล่านี้จะเป็นเนื้อหาหลักของบทที่เหลือ