21
RESERVE TIME TO CREATE ORGANIZATIONAL LEARNING AND IMPROVEMENT (จัดสรรเวลาเพื่อสร้างการเรียนรู้และปรับปรุงองค์กร)
O แนวปฏิบัติหนึ่งที่เป็นส่วนหนึ่งของ Toyota Production System เรียกว่า improvement blitz (หรือบางครั้งเรียกว่า kaizen blitz ) ซึ่งหมายถึงช่วงเวลาที่ทุ่มเทและโฟกัสอย่างเต็มที่เพื่อจัดการกับปัญหาเฉพาะ โดยมักใช้เวลาหลายวัน 1 ดร. Spear อธิบายว่า “blitz มักมีรูปแบบดังนี้: กลุ่มคนจะถูกรวมตัวกันเพื่อโฟกัสอย่างเข้มข้นกับกระบวนการที่มีปัญหา . . . blitz ใช้เวลาสองสามวัน เป้าหมายคือการปรับปรุงกระบวนการ และวิธีการคือการใช้คนจากภายนอกกระบวนการอย่างเข้มข้นเพื่อให้คำแนะนำแก่คนที่ทำงานอยู่ภายในกระบวนการนั้น” 2
Spear สังเกตว่าผลลัพธ์ของทีม improvement blitz มักจะเป็นแนวทางใหม่ในการแก้ปัญหา เช่น การจัดวางอุปกรณ์ใหม่ วิธีการใหม่ในการส่งต่อวัสดุและข้อมูล พื้นที่ทำงานที่เป็นระเบียบมากขึ้น หรือการทำงานที่เป็นมาตรฐาน พวกเขาอาจทิ้งรายการสิ่งที่ต้องทำ (to-do list) สำหรับการเปลี่ยนแปลงที่ต้องทำในภายหลัง 3
Thirty-Day Challenge ที่ Target (2015)
ตัวอย่างของ DevOps improvement blitz คือโปรแกรมความท้าทายรายเดือนที่ Target DevOps Dojo Ross Clanton อดีต Director of Operations ของ Target มีหน้าที่เร่งการนำ DevOps มาใช้ กลไกหลักอย่างหนึ่งของเขาคือ Technology Innovation Center หรือที่รู้จักกันในชื่อ DevOps Dojo
DevOps Dojo ของ Target ใช้พื้นที่สำนักงานแบบเปิดโล่งประมาณหนึ่งหมื่นแปดพันตารางฟุต ซึ่ง DevOps coaches ช่วยเหลือทีมต่างๆ จากทั่วทั้งองค์กรเทคโนโลยีของ Target ให้ยกระดับการปฏิบัติงานของตน รูปแบบที่เข้มข้นที่สุดคือสิ่งที่พวกเขาเรียกว่า “thirty-day challenges” โดยทีมพัฒนาภายในจะเข้ามาเป็นเวลาหนึ่งเดือนและทำงานร่วมกันกับ Dojo coaches และวิศวกรประจำ Dojo ทีมจะนำงานของพวกเขามาด้วย โดยมีเป้าหมายเพื่อแก้ปัญหาภายในที่พวกเขาประสบมาอย่างยากลำบาก และสร้างความก้าวหน้าภายในสามสิบวัน
ตลอดระยะเวลาสามสิบวัน พวกเขาทำงานอย่างเข้มข้นกับ Dojo coaches ในเรื่องปัญหา—วางแผน ทำงาน และทำเด모ในรอบสองวัน (two-day sprints) เมื่อความท้าทายสามสิบวันเสร็จสมบูรณ์ ทีมภายในจะกลับไปยังสายงานของตน ไม่เพียงแต่แก้ไขปัญหาสำคัญได้สำเร็จ แต่ยังนำความรู้ใหม่กลับไปให้ทีมของตน
Clanton กล่าวว่า “ปัจจุบันเรามีศักยภาพที่จะให้แปดทีมทำ 30-Day Challenges พร้อมกัน ดังนั้นเราจึงโฟกัสที่โปรเจกต์ที่สำคัญที่สุดขององค์กร เท่าที่ผ่านมา เราได้เห็นความสามารถที่สำคัญที่สุดบางอย่างของเราผ่าน Dojo รวมถึงทีมจาก Point Of Sale (POS), Inventory, Pricing และ Promotion” 4
การมีเจ้าหน้าที่ Dojo แบบเต็มเวลาและโฟกัสที่เป้าหมายเดียว ทำให้ทีมที่เข้าร่วม thirty-day challenge มีการปรับปรุงที่เหลือเชื่อ Ravi Pandey ผู้จัดการฝ่ายพัฒนาของ Target ที่ผ่านโปรแกรมนี้ อธิบายว่า “ในสมัยก่อน เราต้องรอหกสัปดาห์เพื่อได้ test environment ตอนนี้เราได้ภายในไม่กี่นาที และเราทำงานเคียงบ่าเคียงไหล่กับวิศวกร Ops ที่ช่วยเพิ่ม productivity และสร้าง tooling ให้เราเพื่อช่วยให้เราบรรลุเป้าหมาย” 5
Clanton ขยายความแนวคิดนี้: “ไม่ใช่เรื่องแปลกที่ทีมจะบรรลุในเวลาไม่กี่วันสิ่งที่ปกติต้องใช้เวลาสามถึงหกเดือน ปัจจุบันมีผู้เรียนสองร้อยคนผ่าน Dojo มาแล้ว โดยทำความท้าทายสำเร็จสิบสี่ครั้ง” 6
Dojo ยังสนับสนุนรูปแบบการมีส่วนร่วมที่เข้มข้นน้อยกว่า เช่น flash builds ที่ทีมมารวมตัวกันเป็นเวลาหนึ่งถึงสามวัน โดยมีเป้าหมายในการส่งมอบ minimal viable product (MVP) หรือความสามารถบางอย่างให้เสร็จภายในช่วงเวลานั้น นอกจากนี้ยังมี open labs ทุกสองสัปดาห์ ที่ใครก็ได้สามารถมาเยี่ยมชม Dojo เพื่อพูดคุยกับ Dojo coaches เข้าร่วมเด모 หรือรับการฝึกอบรม
ในบทนี้ เราจะอธิบายวิธีการนี้และวิธีการอื่นๆ ในการจัดสรรเวลาสำหรับการเรียนรู้และการปรับปรุงขององค์กร เพื่อทำให้การอุทิศเวลาเพื่อปรับปรุงงานประจำวันเป็นสถาบันที่ยั่งยืนยิ่งขึ้น
Institutionalize Rituals to Pay Down Technical Debt (สร้างพิธีกรรมขององค์กรเพื่อลด Technical Debt)
ในส่วนนี้ เราจะจัดตารางพิธีกรรมที่ช่วยเสริมสร้างการปฏิบัติในการจัดสรรเวลาของ Dev และ Ops สำหรับงานปรับปรุง เช่น non-functional requirements, ระบบอัตโนมัติ ฯลฯ หนึ่งในวิธีที่ง่ายที่สุดคือการจัด improvement blitzes แบบวันหรือสัปดาห์ โดยทุกคนในทีม (หรือทั้งองค์กร) จัดระเบียบตนเองเพื่อแก้ไขปัญหาที่พวกเขาใส่ใจ—ไม่อนุญาตให้ทำงานฟีเจอร์เด็ดขาด อาจเป็นพื้นที่ที่มีปัญหาของโค้ด สภาพแวดล้อม สถาปัตยกรรม tooling และอื่นๆ ทีมเหล่านี้ครอบคลุมทั้ง value stream มักจะรวมวิศวกรจาก Development, Operations และ Infosec ทีมที่ปกติไม่ทำงานร่วมกันจะรวมทักษะและความพยายามเพื่อปรับปรุงพื้นที่ที่เลือก แล้วสาธิตการปรับปรุงให้กับส่วนอื่นๆ ของบริษัท
นอกเหนือจากคำศัพท์แนว Lean อย่าง kaizen blitz และ improvement blitz แล้ว เทคนิคการจัดพิธีกรรมเฉพาะสำหรับงานปรับปรุงยังถูกเรียกว่า spring หรือ fall cleanings และ ticket queue inversion weeks 7 นอกจากนี้ยังมีคำอื่นๆ เช่น hack days , hackathons และ 20% innovation time แต่น่าเสียดายที่พิธีกรรมเหล่านี้อาจโฟกัสที่นวัตกรรมผลิตภัณฑ์และการสร้างต้นแบบไอเดียตลาดใหม่ มากกว่างานปรับปรุง และที่แย่กว่านั้นคือ มักจำกัดเฉพาะนักพัฒนา—ซึ่งแตกต่างอย่างมากจากเป้าหมายของ improvement blitz *
เป้าหมายของเราในช่วง blitz เหล่านี้ไม่ใช่เพียงแค่ทดลองและสร้างนวัตกรรมเพื่อทดสอบเทคโนโลยีใหม่ๆ แต่เพื่อปรับปรุงงานประจำวันของเรา เช่น การแก้ปัญหางานประจำวันที่เราต้องทำงานรอบๆ (workarounds) แม้ว่าการทดลองจะนำไปสู่การปรับปรุงได้เช่นกัน แต่ improvement blitzes นั้นโฟกัสอย่างมากที่การแก้ปัญหาเฉพาะที่เราเจอในงานประจำวัน
เราอาจจัด improvement blitzes แบบหนึ่งสัปดาห์ที่ให้ความสำคัญกับการที่ Dev และ Ops ทำงานร่วมกันเพื่อเป้าหมายการปรับปรุง การจัดการ improvement blitzes นั้นง่าย: เลือกหนึ่งสัปดาห์ที่ทุกคนในองค์กรเทคโนโลยีทำงานในกิจกรรมการปรับปรุงพร้อมกัน เมื่อสิ้นสุดช่วงเวลา แต่ละทีมจะนำเสนอให้เพื่อนร่วมทีมฟังถึงปัญหาที่พวกเขาจัดการและสิ่งที่พวกเขาสร้างขึ้น แนวปฏิบัตินี้ตอกย้ำวัฒนธรรมที่วิศวกรทำงานข้าม value stream ทั้งหมดเพื่อแก้ปัญหา นอกจากนี้ยังตอกย้ำการแก้ปัญหาในงานประจำวันของเรา และแสดงให้เห็นว่าเราให้ความสำคัญกับการลด technical debt
สิ่งที่ทำให้ improvement blitzes มีพลังมากคือเรากำลังเสริมพลังให้คนที่ใกล้ชิดกับงานมากที่สุดสามารถระบุและแก้ปัญหาของตนเองได้ ลองคิดดูว่าระบบที่ซับซ้อนของเราเปรียบเสมือนใยแมงมุม ที่มีเส้นใยพันกันซึ่งอ่อนแอและขาดอยู่ตลอดเวลา หากเส้นใยชุดที่เหมาะสมขาด ใยทั้งหมดจะพังทลาย
ไม่มีการจัดการแบบ command-and-control ใดที่จะสั่งให้คนทำงานซ่อมแต่ละเส้นใยทีละเส้นได้ แต่เราต้องสร้างวัฒนธรรมและบรรทัดฐานขององค์กรที่นำไปสู่การที่ทุกคนคอยค้นหาและซ่อมแซมเส้นใยที่ขาดอย่างต่อเนื่องเป็นส่วนหนึ่งของงานประจำวัน ดังที่ ดร. Spear กล่าวไว้ว่า “ไม่แปลกใจเลยที่แมงมุมซ่อมแซมรอยฉีกขาดของใยทันทีที่เกิดขึ้น โดยไม่รอให้ความเสียหายสะสม” 8
ตัวอย่างที่ยอดเยี่ยมของความสำเร็จของแนวคิด improvement blitz อธิบายโดย Mark Zuckerberg ซีอีโอของ Facebook ในการสัมภาษณ์กับ Jessica Stillman จาก Inc. เขากล่าวว่า
“ทุกๆ สองสามเดือนเราจะมี hackathon ที่ทุกคนสร้าง prototype สำหรับไอเดียใหม่ๆ ที่พวกเขามี ในตอนท้าย ทั้งทีมจะมารวมตัวกันและดูทุกสิ่งที่ถูกสร้างขึ้น ผลิตภัณฑ์ที่ประสบความสำเร็จที่สุดหลายอย่างของเรามาจาก hackathons รวมถึง Timeline, chat, video, mobile development framework และโครงสร้างพื้นฐานที่สำคัญที่สุดบางอย่างของเราเช่น HipHop compiler” 9
สิ่งที่น่าสนใจเป็นพิเศษคือ HipHop PHP compiler ในปี 2008 Facebook กำลังประสบปัญหาด้านความจุอย่างมาก โดยมีผู้ใช้ที่ใช้งานอยู่มากกว่าหนึ่งร้อยล้านคนและเติบโตอย่างรวดเร็ว สร้างปัญหามหาศาลให้กับทีมวิศวกรรมทั้งหมด 10 ในช่วง hack day Haiping Zhao วิศวกรอาวุโสด้าน Server ของ Facebook เริ่มทดลองแปลงโค้ด PHP เป็นโค้ด C++ ที่สามารถคอมไพล์ได้ โดยหวังว่าจะเพิ่มความจุของโครงสร้างพื้นฐานที่มีอยู่อย่างมีนัยสำคัญ ในช่วงสองปีถัดมา ทีมเล็กๆ ก็ถูกรวมตัวกันเพื่อสร้างสิ่งที่กลายมาเป็น HipHop compiler ซึ่งแปลงบริการ production ทั้งหมดของ Facebook จาก PHP ที่ถูกแปลความ (interpreted) ไปเป็น binaries C++ ที่ถูกคอมไพล์ HipHop ช่วยให้แพลตฟอร์มของ Facebook สามารถรองรับโหลดใน production ได้สูงถึงหกเท่าของ PHP ดั้งเดิม 11
ในการสัมภาษณ์กับ Cade Metz จาก Wired Drew Paroski หนึ่งในวิศวกรที่ทำงานในโปรเจกต์นี้กล่าวว่า “มีช่วงเวลาที่ถ้า HipHop ไม่มีอยู่ เราคงเดือดร้อนมาก เราอาจต้องใช้เครื่องจักรเพื่อให้บริการเว็บไซต์มากกว่าที่เราจะหาได้ทันเวลา มันเป็น Hail Mary pass ที่ได้ผล” 12
ต่อมา Paroski และวิศวกรร่วม Keith Adams และ Jason Evans ตัดสินใจว่าพวกเขาสามารถทำประสิทธิภาพให้ดีกว่า HipHop compiler และลดข้อจำกัดบางอย่างที่ลด productivity ของนักพัฒนาได้ โปรเจกต์ที่ได้คือ HipHop virtual machine project (“HHVM”) ซึ่งใช้วิธีการคอมไพล์แบบ just-in-time ภายในปี 2012 HHVM ได้แทนที่ HipHop compiler ใน production อย่างสมบูรณ์ โดยมีวิศวกรเกือบยี่สิบคนมีส่วนร่วมในโปรเจกต์นี้ 13
การจัด improvement blitzes และ hack weeks อย่างสม่ำเสมอ ทำให้ทุกคนใน value stream สามารถภาคภูมิใจและเป็นเจ้าของนวัตกรรมที่พวกเขาสร้างขึ้น และเรายังผสานการปรับปรุงเข้ากับระบบของเราอย่างต่อเนื่อง ซึ่งช่วยเสริมสร้างความปลอดภัย ความน่าเชื่อถือ และการเรียนรู้
Enable Everyone to Teach and Learn (ทำให้ทุกคนสามารถสอนและเรียนรู้ได้)
วัฒนธรรมการเรียนรู้ที่มีพลวัตสร้างเงื่อนไขให้ทุกคนไม่เพียงแต่เรียนรู้ แต่ยังสอนได้ ไม่ว่าจะผ่านวิธีการสอนแบบดั้งเดิม (เช่น การเรียนในชั้นเรียน การเข้ารับการฝึกอบรม) หรือวิธีการเชิงประสบการณ์หรือแบบเปิด (เช่น การเข้าร่วมสัมมนา เวิร์กช็อป การเป็นที่ปรึกษา) วิธีหนึ่งที่เราสามารถส่งเสริมการสอนและการเรียนรู้คือการอุทิศเวลาขององค์กรให้กับสิ่งนี้
Steve Farley รองประธานฝ่ายเทคโนโลยีสารสนเทศของ Nationwide Insurance กล่าวว่า
“เรามีผู้เชี่ยวชาญด้านเทคโนโลยีห้าพันคน ซึ่งเราเรียกว่า ‘associates’ ตั้งแต่ปี 2011 เรามุ่งมั่นที่จะสร้างวัฒนธรรมการเรียนรู้—ส่วนหนึ่งคือสิ่งที่เราเรียกว่า Teaching Thursday ที่แต่ละสัปดาห์เราสร้างเวลาให้ associates ของเราได้เรียนรู้ เป็นเวลาสองชั่วโมง แต่ละ associate ต้องสอนหรือเรียนรู้ หัวข้อเป็นสิ่งที่ associates ของเราต้องการเรียน—บางหัวข้อเป็นเทคโนโลยี การพัฒนา ซอฟต์แวร์ใหม่ หรือเทคนิคการปรับปรุงกระบวนการ หรือแม้แต่การบริหารจัดการอาชีพของตน สิ่งที่มีค่าที่สุดที่ associate สามารถทำได้คือการเป็น mentor หรือเรียนรู้จาก associates คนอื่น” 14
ดังที่ปรากฏชัดตลอดทั้งเล่มนี้ ทักษะบางอย่างมีความจำเป็นมากขึ้นสำหรับวิศวกรทุกคน ไม่ใช่แค่นักพัฒนาเท่านั้น ตัวอย่างเช่น การที่วิศวกร Operations และ Test ทุกคนคุ้นเคยกับเทคนิค พิธีกรรม และทักษะด้านการพัฒนา เช่น version control, automated testing, deployment pipelines, configuration management และการสร้างระบบอัตโนมัติ กำลังมีความสำคัญมากขึ้น ความคุ้นเคยกับเทคนิคการพัฒนาช่วยให้วิศวกร Operations ยังคงมีความเกี่ยวข้องเมื่อ value stream ด้านเทคโนโลยีจำนวนมากขึ้นนำหลักการและรูปแบบ DevOps มาใช้
แม้ว่าการเรียนรู้สิ่งใหม่อาจน่ากลัวหรือทำให้รู้สึกอึดอัดหรือละอายใจ แต่ก็ไม่ควรเป็นเช่นนั้น ท้ายที่สุดแล้ว เราทุกคนเป็นผู้เรียนรู้ตลอดชีวิต (lifelong learners) และหนึ่งในวิธีที่ดีที่สุดในการเรียนรู้คือจากเพื่อนร่วมงาน Karthik Gaekwad ซึ่งเป็นส่วนหนึ่งของการเปลี่ยนแปลง DevOps ของ National Instruments กล่าวว่า “สำหรับคนใน Operations ที่พยายามเรียนรู้ระบบอัตโนมัติ ไม่ควรน่ากลัว—เพียงแค่ถามนักพัฒนาที่เป็นมิตร เพราะพวกเขายินดีช่วยเหลือ” 15
เราสามารถช่วยสอนทักษะเพิ่มเติมผ่านงานประจำวันของเราได้ โดยการทำ code reviews ร่วมกันซึ่งรวมทั้งสองฝ่าย เพื่อให้เราเรียนรู้จากการลงมือทำ รวมถึงให้ Development และ Operations ทำงานร่วมกันเพื่อแก้ปัญหาเล็กๆ น้อยๆ ตัวอย่างเช่น เราอาจให้ Development แสดงให้ Operations เห็นวิธีการ authenticate แอปพลิเคชัน เข้าสู่ระบบ และรัน automated tests กับส่วนต่างๆ ของแอปพลิเคชันเพื่อให้แน่ใจว่าคอมโพเนนต์ที่สำคัญทำงานถูกต้อง (เช่น ฟังก์ชันหลักของแอปพลิเคชัน, database transactions, message queues) จากนั้นเราจะรวม automated test ใหม่นี้เข้าไปใน deployment pipeline ของเรา และรันเป็นระยะ ส่งผลลัพธ์ไปยังระบบ monitoring และ alerting ของเรา เพื่อให้เราตรวจพบปัญหาได้เร็วขึ้นเมื่อคอมโพเนนต์สำคัญล้มเหลว
ดังที่ Glenn O’Donnell จาก Forrester Research กล่าวติดตลกในการนำเสนอ DevOps Enterprise Summit 2014 ว่า “สำหรับผู้เชี่ยวชาญด้านเทคโนโลยีทุกคนที่รักนวัตกรรม รักการเปลี่ยนแปลง อนาคตที่ยอดเยี่ยมและสดใสรอเราอยู่ข้างหน้า” 16
Continuous Learning (การเรียนรู้อย่างต่อเนื่อง)
ASREDS Learning Loop (วงจรการเรียนรู้ ASREDS)
มนุษย์มีความต้องการโดยธรรมชาติที่จะเป็นส่วนหนึ่งของกลุ่ม แต่สัญชาตญาณนี้ก็อาจเป็นสัญชาตญาณในการกีดกันเช่นกัน เมื่อพูดถึงการเรียนรู้ร่วมกัน ความคิดแบบกลุ่มนี้อาจส่งผลให้เกิดฟองสบู่แห่งการเรียนรู้ (learning bubbles หรือ learning silos) หรือการสูญเสียความรู้ขององค์กรอย่างถาวรเมื่อคนออกจากกลุ่ม (บริษัท)
เมื่อการเรียนรู้ติดอยู่ในฟองสบู่ ความรู้จะถูกซ่อนไว้ และทีมต่างๆ จะต้องดิ้นรนกับปัญหาเดียวกันโดยไม่จำเป็น ทดลองแบบเดียวกัน พัฒนา antipatterns เดียวกัน และไม่สามารถใช้ประโยชน์จากเรียนรู้ของกันและกัน ใน Sooner Safer Happier ผู้เขียนใช้วงจรการเรียนรู้ ASREDS เพื่อทำลายฟองสบู่แห่งการเรียนรู้เหล่านี้ 17
วงจรนี้ขอให้ทีมเริ่มต้นด้วยการ Align (กำหนดเป้าหมายร่วมกัน) จากนั้น Sense (รับรู้บริบท) ตอบสนองโดย Respond (ออกแบบการทดลองหนึ่งรายการขึ้นไป) Distill (กลั่นกรองผลลัพธ์เป็นข้อมูลเชิงลึกและเมตริก) และ Share (แบ่งปันผลลัพธ์โดยเผยแพร่สิ่งที่เรียนรู้) เพื่อให้ผู้อื่นสามารถนำไปเริ่มต้นที่ขั้นตอน Sense ได้อีกครั้ง
แนวปฏิบัติอย่าง ASREDS ช่วยทำลายฟองสบู่แห่งการเรียนรู้ที่ disconnected และเมื่อรวมกับรางวัลและ Centers of Practice (ดูเพิ่มเติมใน Sooner Safer Happier ) รูปแบบเหล่านี้จะส่งเสริมการสร้างระบบนิเวศแห่งการเรียนรู้ในที่สุด
Figure 21.1: วงจรการเรียนรู้ ASREDS (The ASREDS Learning Loop)
ที่มา: Smart et al., Sooner Safer Happier: Antipatterns and Patterns for Business Agility (Portland, OR: IT Revolution, 2020).
Share your Experiences from DevOps Conferences (แบ่งปันประสบการณ์จาก DevOps Conferences)
ในหลายองค์กรที่เน้นการลดต้นทุน วิศวกรมักถูกกีดกันไม่ให้เข้าร่วมสัมมนาและเรียนรู้จากเพื่อนร่วมงาน เพื่อช่วยสร้างองค์กรแห่งการเรียนรู้ เราควรสนับสนุนให้วิศวกรของเรา (ทั้งจาก Development และ Operations) เข้าร่วมสัมมนา ไปพูดในงานสัมมนา และเมื่อจำเป็น ให้สร้างและจัดสัมมนาทั้งภายในและภายนอกด้วยตนเอง
DevOpsDays ยังคงเป็นหนึ่งในชุดสัมมนาที่จัดโดยชุมชนที่มีชีวิตชีวาที่สุดในปัจจุบัน แนวปฏิบัติ DevOps จำนวนมากถูกแบ่งปันและเผยแพร่ในงานเหล่านี้ งานนี้ยังคงฟรีหรือเกือบฟรี โดยได้รับการสนับสนุนจากชุมชนผู้ปฏิบัติงานและผู้ขายที่มีชีวิตชีวา
DevOps Enterprise Summit ถูกสร้างขึ้นในปี 2014 สำหรับผู้นำด้านเทคโนโลยีเพื่อแบ่งปันประสบการณ์ในการนำหลักการและแนวปฏิบัติ DevOps มาใช้ในองค์กรขนาดใหญ่และซับซ้อน โปรแกรมนี้จัดขึ้นโดยหลักจากรายงานประสบการณ์ (experience reports) จากผู้นำด้านเทคโนโลยีในเส้นทาง DevOps รวมถึงผู้เชี่ยวชาญเฉพาะด้านในหัวข้อที่ชุมชนเลือก ภายในปี 2021 DevOps Enterprise Summit ได้จัดสัมมนาไปแล้วสิบสี่ครั้ง โดยมีการบรรยายเกือบหนึ่งพันครั้งจากผู้เชี่ยวชาญด้านเทคโนโลยีจากแทบทุกอุตสาหกรรม
CASE STUDY (กรณีศึกษา)
Internal Technology Conferences ที่ Nationwide Insurance, Capital One และ Target (2014)
นอกเหนือจากการเข้าร่วมสัมมนาภายนอกแล้ว หลายบริษัทยังมีสัมมนาภายในสำหรับพนักงานด้านเทคโนโลยีของตน Nationwide Insurance เป็นผู้ให้บริการชั้นนำด้านประกันภัยและบริการทางการเงิน ดำเนินงานในอุตสาหกรรมที่มีการควบคุมอย่างเข้มงวด บริการต่างๆ ของพวกเขารวมถึงประกันรถยนต์และบ้าน และเป็นผู้ให้บริการอันดับต้นๆ ของแผน retirement ภาครัฐและประกันสัตว์เลี้ยง ในปี 2014 พวกเขามีสินทรัพย์ 195 พันล้านดอลลาร์ โดยมีรายได้ 24 พันล้านดอลลาร์ 18
ตั้งแต่ปี 2005 Nationwide ได้นำหลักการ Agile และ Lean มาใช้เพื่อยกระดับการปฏิบัติงานของผู้เชี่ยวชาญด้านเทคโนโลยีห้าพันคนของตน ทำให้เกิดนวัตกรรมจากระดับฐานราก (grassroots innovation)
Steve Farley รองประธานฝ่ายเทคโนโลยีสารสนเทศ เล่าว่า
“ในช่วงเวลานั้น สัมมนาด้านเทคโนโลยีที่น่าตื่นเต้นเริ่มเกิดขึ้น เช่น Agile national conference ในปี 2011 ผู้บริหารด้านเทคโนโลยีของ Nationwide เห็นตรงกันว่าเราควรสร้างสัมมนาด้านเทคโนโลยีของเราเอง เรียกว่า TechCon โดยการจัดงานนี้ เราต้องการสร้างวิธีที่ดีกว่าในการสอนตัวเอง รวมถึงทำให้ทุกอย่างมีบริบทของ Nationwide แทนที่จะส่งทุกคนไปสัมมนาภายนอก” 19
Capital One หนึ่งในธนาคารที่ใหญ่ที่สุดในสหรัฐอเมริกาด้วยสินทรัพย์กว่า 298 พันล้านดอลลาร์และรายได้ 24 พันล้านดอลลาร์ในปี 2015 จัดสัมมนาวิศวกรรมซอฟต์แวร์ภายในครั้งแรกในปี 2015 โดยเป็นส่วนหนึ่งของเป้าหมายในการสร้างองค์กรเทคโนโลยีระดับโลก 20 ภารกิจคือการส่งเสริมวัฒนธรรมการแบ่งปันและการทำงานร่วมกัน สร้างความสัมพันธ์ระหว่างผู้เชี่ยวชาญด้านเทคโนโลยี และทำให้เกิดการเรียนรู้ สัมมนามีสิบสามหัวข้อการเรียนรู้ (learning tracks) และห้าสิบสองเซสชัน โดยมีพนักงานภายในมากกว่า 1,200 คนเข้าร่วม 21
ดร. Tapabrata Pal นักเทคนิค Fellow ของ Capital One และหนึ่งในผู้จัดงาน อธิบายว่า “เรายังมี expo hall ที่มียี่สิบแปดบูธ ซึ่งทีมภายในของ Capital One แสดงความสามารถอันน่าทึ่งที่พวกเขากำลังทำงานอยู่ เราตัดสินใจอย่างจงใจว่าจะไม่มีผู้ขาย (vendors) อยู่ที่นั่น เพราะเราต้องการรักษาโฟกัสที่เป้าหมายของ Capital One” 22
Target เป็นผู้ค้าปลีกรายใหญ่เป็นอันดับหกในสหรัฐอเมริกา ด้วยรายได้ 72 พันล้านดอลลาร์ในปี 2014 และร้านค้าปลีก 1,799 แห่ง พนักงาน 347,000 คนทั่วโลก 23 Heather Mickman ผู้อำนวยการฝ่ายพัฒนา และ Ross Clanton ได้จัดงาน DevOpsDays ภายในหกครั้งตั้งแต่ปี 2014 และมีผู้ติดตามกว่า 975 คนในชุมชนเทคโนโลยีภายในของพวกเขา โดยจำลองมาจาก DevOpsDays ที่จัดขึ้นที่ ING ใน Amsterdam ปี 2013 24 †
หลังจาก Mickman และ Clanton เข้าร่วม DevOps Enterprise Summit ในปี 2014 พวกเขาก็จัดสัมมนาภายในของตนเอง โดยเชิญวิทยากรหลายคนจากบริษัทภายนอกเพื่อสร้างประสบการณ์เดียวกันให้กับผู้นำอาวุโส Clanton อธิบายว่า “ปี 2015 เป็นปีที่เราได้รับความสนใจจากผู้บริหารและเมื่อเราสร้างแรงผลักดัน หลังจากงานนั้น ผู้คนมากมายเข้ามาหาเราถามว่าพวกเขาจะมีส่วนร่วมและช่วยเหลือได้อย่างไร” 26
องค์กรสามารถเสริมพลังให้บุคลากรด้านเทคโนโลยีของตนได้โดยการจัดหาวัฒนธรรมการเรียนรู้และการสอนที่มีพลวัต ไม่เพียงผ่านการเข้าร่วมและนำเสนอในสัมมนาภายนอก แต่ยังรวมถึงการสร้างและจัดสัมมนาภายในด้วย ซึ่งสามารถส่งเสริมความไว้วางใจในทีมและองค์กร เพิ่มการสื่อสารและนวัตกรรม และปรับปรุงงานประจำวัน
Continuous Learning (การเรียนรู้อย่างต่อเนื่อง)
รายงาน State of DevOps Report ของ DORA ปี 2019 ได้ตรวจสอบว่าองค์กรเผยแพร่แนวปฏิบัติ DevOps และ Agile อย่างไร โดยให้พวกเขาเลือกจากวิธีต่างๆ ที่พบบ่อย เช่น training centers, centers of excellence, proof of concept ประเภทต่างๆ, big bang และ communities of practice
การวิเคราะห์แสดงให้เห็นว่า:
“องค์กรที่มีประสิทธิภาพสูงชอบกลยุทธ์ที่สร้างโครงสร้างชุมชนทั้งในระดับต่ำและสูงขององค์กร ซึ่งทำให้ยั่งยืนและทนทานต่อการปรับโครงสร้างและการเปลี่ยนแปลงผลิตภัณฑ์มากขึ้น สองกลยุทธ์อันดับต้นๆ ที่ใช้คือ communities of practice และ grassroots ตามด้วย proof of concept as a template (รูปแบบที่ proof of concept ถูกทำซ้ำในที่อื่นๆ ขององค์กร) และ proof of concept as a seed” 27
Create Community Structures to Spread Practices (สร้างโครงสร้างชุมชนเพื่อเผยแพร่แนวปฏิบัติ)
ก่อนหน้านี้ในหนังสือ เราเริ่มเล่าเรื่องราวของ Testing Grouplet ที่สร้างวัฒนธรรมการทดสอบอัตโนมัติระดับโลกที่ Google ตั้งแต่ปี 2005 เรื่องราวของพวกเขายังคงดำเนินต่อไปที่นี่ ขณะที่พวกเขาพยายามปรับปรุงสถานะของการทดสอบอัตโนมัติทั่วทั้ง Google โดยใช้ improvement blitzes เฉพาะกิจ โค้ชภายใน และแม้แต่โปรแกรมการรับรองภายใน
Mike Bland กล่าวว่า ในเวลานั้น มีนโยบายเวลา 20% สำหรับนวัตกรรมที่ Google ซึ่งช่วยให้นักพัฒนาใช้เวลาประมาณหนึ่งวันต่อสัปดาห์ในโปรเจกต์ที่เกี่ยวข้องกับ Google นอกเหนือจากพื้นที่รับผิดชอบหลักของตน วิศวกรบางคนเลือกที่จะสร้าง communities of practice ที่พวกเขาเรียกว่า grouplets ซึ่งเป็นทีมเฉพาะกิจของวิศวกรที่มีแนวคิดเดียวกันที่ต้องการรวมเวลา 20% ของพวกเขาเข้าด้วยกัน ทำให้พวกเขาสามารถทำ focused improvement blitzes 28
ชุมชนแห่งการปฏิบัติด้านการทดสอบ (testing community of practice) ก่อตั้งโดย Bharat Mediratta และ Nick Lesiecki โดยมีภารกิจในการขับเคลื่อนการนำการทดสอบอัตโนมัติไปใช้ทั่วทั้ง Google แม้ว่าพวกเขาจะไม่มีงบประมาณหรืออำนาจอย่างเป็นทางการ ดังที่ Mike Bland อธิบายว่า “ก็ไม่มีข้อจำกัดที่ชัดเจนวางไว้บนตัวเราเช่นกัน และเราใช้ประโยชน์จากสิ่งนั้น” 29
พวกเขาใช้กลไกหลายอย่างในการขับเคลื่อนการนำไปใช้ แต่หนึ่งในกลไกที่โด่งดังที่สุดคือ Testing on the Toilet (หรือ TotT) วารสารการทดสอบรายสัปดาห์ของพวกเขา แต่ละสัปดาห์ พวกเขาจะเผยแพร่จดหมายข่าวในห้องน้ำเกือบทุกแห่งในสำนักงาน Google เกือบทุกแห่งทั่วโลก Bland กล่าวว่า “เป้าหมายคือการยกระดับความรู้และความซับซ้อนด้านการทดสอบทั่วทั้งบริษัท เป็นที่น่าสงสัยว่าสิ่งพิมพ์ออนไลน์เท่านั้นจะเกี่ยวข้องกับผู้คนในระดับเดียวกันได้” 30
Bland กล่าวต่อว่า “หนึ่งในตอนที่สำคัญที่สุดของ TotT คือตอนที่ชื่อว่า ‘Test Certified: Lousy Name, Great Results’ เพราะมันสรุปสองโครงการที่ประสบความสำเร็จอย่างมากในการส่งเสริมการใช้การทดสอบอัตโนมัติ” 31
Test Certified (TC) จัดเตรียมแผนที่นำทาง (road map) เพื่อปรับปรุงสถานะของการทดสอบอัตโนมัติ ดังที่ Bland อธิบายว่า “มันมีเจตนาที่จะแฮ็กวัฒนธรรมที่เน้นการวัดผลของ Google . . . และเอาชนะอุปสรรคแรกที่น่ากลัวของการไม่รู้ว่าจะเริ่มต้นที่ไหนหรืออย่างไร Level 1 คือการสร้างเมตริกพื้นฐานอย่างรวดเร็ว Level 2 คือการกำหนดนโยบายและบรรลุเป้าหมายความครอบคลุมการทดสอบอัตโนมัติ และ Level 3 คือการมุ่งสู่เป้าหมายความครอบคลุมระยะยาว” 32
ความสามารถที่สองคือการจัดหา test certified mentors ให้กับทีมใดๆ ที่ต้องการคำแนะนำหรือความช่วยเหลือ และ test mercenaries (ทีมเต็มเวลาของโค้ชและที่ปรึกษาภายใน) เพื่อทำงานร่วมกับทีมต่างๆ ในการปรับปรุงแนวปฏิบัติการทดสอบและคุณภาพโค้ดของพวกเขา Mercenaries ดำเนินการดังกล่าวโดยการนำความรู้ เครื่องมือ และเทคนิคของ testing grouplet ไปใช้กับโค้ดของทีม โดยใช้ TC ทั้งเป็นแนวทางและเป้าหมาย
Bland เป็นผู้นำของ testing grouplet ตั้งแต่ปี 2006 ถึง 2007 และเป็นสมาชิกของ test mercenaries ตั้งแต่ปี 2007 ถึง 2009 33
Bland กล่าวต่อว่า
“เป้าหมายของเราคือการทำให้ทุกทีมไปถึง TC Level 3 ไม่ว่าพวกเขาจะลงทะเบียนในโปรแกรมของเราหรือไม่ก็ตาม นอกจากนี้เรายังทำงานร่วมกันอย่างใกล้ชิดกับทีมเครื่องมือทดสอบภายใน โดยให้ข้อเสนอแนะเมื่อเราจัดการกับความท้าทายด้านการทดสอบกับทีมผลิตภัณฑ์ เราเป็น boots on the ground นำเครื่องมือที่เราสร้างไปใช้ และในที่สุด เราก็สามารถลบ ‘ฉันไม่มีเวลาทดสอบ’ ออกจากข้อแก้ตัวที่ยอมรับได้ . . .” 34
ระดับของ TC ใช้ประโยชน์จากวัฒนธรรมที่ขับเคลื่อนด้วยเมตริกของ Google—การทดสอบสามระดับเป็นสิ่งที่ผู้คนสามารถพูดคุยและอวดอ้างได้ในช่วงเวลาการประเมินผลงาน (performance review) Testing Grouplet ในที่สุดก็ได้รับเงินทุนสำหรับ Test Mercenaries ซึ่งเป็นทีมที่ได้รับการจัดสรรบุคลากรของที่ปรึกษาภายในแบบเต็มเวลา นี่เป็นขั้นตอนสำคัญ เพราะตอนนี้ผู้บริหารอยู่บนเรืออย่างเต็มที่ ไม่ใช่ด้วยคำสั่ง แต่ด้วยเงินทุนจริง 35
โครงสร้างที่สำคัญอีกประการหนึ่งคือการใช้ประโยชน์จาก improvement blitzes “fixit” ทั่วทั้งบริษัท Bland อธิบายว่า fixit คือ “เวลาที่วิศวกรธรรมดาที่มีไอเดียและความรู้สึกถึงภารกิจ รับสมัครวิศวกร Google ทั้งหมดสำหรับการ sprint หนึ่งวันอย่างเข้มข้นเพื่อปฏิรูปโค้ดและการนำเครื่องมือมาใช้” 36
เขาจัด fixit ทั่วทั้งบริษัทสี่ครั้ง สองครั้งเป็น fixit ด้านการทดสอบล้วนๆ และอีกสองครั้งเกี่ยวข้องกับเครื่องมือมากขึ้น ครั้งสุดท้ายเกี่ยวข้องกับอาสาสมัครมากกว่า 100 คนในกว่า 20 สำนักงานใน 13 ประเทศ นอกจากนี้เขายังนำ Fixit Grouplet ตั้งแต่ปี 2007 ถึง 2008 37
fixit เหล่านี้ ดังที่ Bland อธิบาย หมายความว่าเราควรจัดหา missions ที่โฟกัส ณ จุดเวลาสำคัญเพื่อสร้างความตื่นเต้นและพลัง ซึ่งช่วยยกระดับสถานะของศิลปะ (state of the art) สิ่งนี้จะช่วยให้ภารกิจการเปลี่ยนแปลงวัฒนธรรมระยะยาวไปถึงที่ราบสูงใหม่ทุกครั้งที่มีความพยายามครั้งใหญ่ที่มองเห็นได้ 38
ผลลัพธ์ของวัฒนธรรมการทดสอบปรากฏชัดในผลลัพธ์ที่น่าทึ่งที่ Google ทำได้ ดังที่นำเสนอตลอดทั้งเล่ม
Conclusion (บทสรุป)
บทนี้ได้อธิบายว่าเราสามารถสร้างพิธีกรรมที่ช่วยเสริมสร้างวัฒนธรรมที่เราทุกคนเป็นผู้เรียนรู้ตลอดชีวิต และเราให้คุณค่ากับการปรับปรุงงานประจำวันมากกว่างานประจำวันเอง เราทำสิ่งนี้โดยการจัดสรรเวลาเพื่อลด technical debt และสร้างโครงสร้างชุมชนที่ช่วยให้ทุกคนได้เรียนรู้จากและสอนซึ่งกันและกัน ทั้งภายในและภายนอกองค์กรของเรา การที่ทุกคนช่วยกันเรียนรู้ในงานประจำวันของเรา ทำให้เราเรียนรู้ได้ดีกว่าคู่แข่ง ช่วยให้เราชนะในตลาด และนอกจากนั้น เรายังช่วยกันบรรลุศักยภาพสูงสุดของเราในฐานะมนุษย์