Learn DevOps ตอนที่ 5: หลักการของการทดลองและเรียนรู้อย่างต่อเนื่อง
Learn DevOps ตอนที่ 1 : จุดเริ่มต้นของการเปลี่ยนแปลง
Learn DevOps ตอนที่ 2 : DevOps คืออะไร ?
Learn DevOps ตอนที่ 3: หลักการของ Flow
Learn DevOps ตอนที่ 4: หลักการของ Feedback
→ Learn DevOps ตอนที่ 5: หลักการของการทดลองและเรียนรู้อย่างต่อเนื่อง
หลังจากที่เรากล่าวถึงหลักการของ flow และหลักการของ feedback ไปแล้ว บทความตอนนี้จะกล่าวถึงหลักการสำคัญของ DevOps ข้อสุดท้ายซึ่งมุ่งเน้นในเรื่องของการสร้างวัฒนธรรมของการทดลองและเรียนรู้อย่างต่อเนื่อง เราต้องเปลี่ยนแปลงวัฒนธรรมที่หวาดกลัวบทลงโทษจากการทำผิด และมองว่าคนที่ให้คำแนะนำหรือบ่งชี้ให้เห็นถึงปัญหา เป็นตัวสร้างปัญหาเสียเอง ให้กลายเป็นวัฒนธรรมที่เข้าใจว่าการเรียนรู้ทำได้ตลอดชีวิต และสนับสนุนให้คนกล้าลองผิดลองถูกเพื่อทดลองสิ่งใหม่ๆ โดยประยุกต์หลักการทดลองทางวิทยาศาสตร์มาใช้ เรียนรู้จากทั้งความสำเร็จและล้มเหลว เพื่อปรับปรุงกระบวนการทำงานและพัฒนาผลิตภัณฑ์ที่มีอยู่ให้ดีขึ้นอย่างต่อเนื่อง ด้วยการสร้างวัฒนธรรมแบบนี้จะทำให้องค์กรสามารถปรับตัวเข้ากับโลกปัจจุบันซึ่งเปลี่ยนแปลงไปอย่างรวดเร็ว และช่วยให้องค์กรสามารถเอาชนะคู่แข่งในตลาดได้
การสร้างพื้นที่ปลอดภัยเพื่อการเรียนรู้ในองค์กร
เมื่อเราทำอะไรบางอย่างกับระบบที่ซับซ้อนอย่างระบบ IT เป็นไปไม่ได้เลยที่จะคาดการณ์ผลลัพธ์ที่เกิดขึ้นได้อย่างแม่นยำ ซึ่งหนึ่งในสาเหตุหลักของข้อผิดพลาดที่ส่งผลกระทบต่อลูกค้า ก็คือเกิดจาก human error นั่นเอง
โดยวิธีการรับมือกับข้อผิดพลาดที่เกิดจาก human error ขององค์กร เป็นตัวบ่งชี้สำคัญว่าองค์กรมีประสิทธิภาพในการเรียนรู้มากแค่ไหน ถ้าองค์รับมือโดยการหาผู้รับผิดชอบมาต่อว่าหรือลงโทษ จะทำให้เกิดวัฒนธรรมแห่งความกลัว ซึ่งคนจะปกป้องตนเองโดยการปกปิดหรือบิดเบือนความจริง และไม่กล้าที่จะแลกเปลี่ยนเรียนรู้ข้อผิดพลาดที่เกิดขึ้นกับบุคคลที่เกี่ยวข้อง ผลลัพธ์ก็คือปัญหาที่แท้จริงไม่ถูกค้นพบหรือถูกค้นพบตอนที่กลายเป็นปัญหาใหญ่แล้ว อีกทั้งยังไม่เกิดกระบวนการเรียนรู้จากข้อผิดพลาดอีกด้วย
องค์กรควรจะสร้างพื้นที่ปลอดภัยให้กับพนักงานโดยการไม่มองว่าข้อผิดพลาดเกิดจากตัวคน แต่ให้มองไปที่ระบบว่าเราจะ redesign ระบบของเราอย่างไรให้ไม่เกิดข้อผิดพลาดแบบนี้ซ้ำขึ้นอีก เราอาจจะตั้งการประชุมทุกๆครั้ง หลังจากที่มีข้อผิดพลาดเกิดขึ้นโดยตั้งกฎไว้ว่าห้ามมีการตำหนิหรือกล่าวโทษกัน เพื่อให้ทุกคนเข้าใจถึงปัญหาที่เกิดขึ้น และร่วมมือกันแก้ปัญหาเพื่อไม่ให้ข้อผิดพลาดเกิดขึ้นอีก หรือทำให้สามารถพบเจอข้อผิดพลาดและแก้ไขได้อย่างรวดเร็วที่สุดเมื่อเกิดปัญหาในครั้งถัดไป การทำแบบนี้จะทำให้พนักงานได้เรียนรู้จากข้อผิดพลาด และกล้าที่จะแลกเปลี่ยนเรียนรู้กับคนอื่นอีกด้วย
การจัดสรรเวลาให้มีการปรับปรุงงานที่ทำอย่างต่อเนื่อง
เรามักจะพบเห็นว่าทีมไม่เต็มใจหรือไม่สามารถที่จะปรับปรุงงานประจำวันของตนเองให้ดีขึ้นได้ ผลลัพธ์ไม่เพียงแต่ทำให้ทีมประสบความยากลำบากกับปัญหาที่ยังคงมีอยู่ต่อไป แต่ยังทำให้ปัญหาแย่ลงอีกด้วย ยกตัวอย่างในหน่วยงาน IT ถ้าเราแก้ปัญหาที่เกิดขึ้นแบบเฉพาะหน้าไปก่อน แต่ไม่ไปแก้ที่ technical debt ของระบบ วันหนึ่งเราจะไปถึงจุดที่ว่าวันๆแก้แต่ปัญหาและไม่เหลือเวลาไปทำงานอย่างอื่นอีกเลย
เพราะฉะนั้นเราควรจัดสรรเวลาให้โปรแกรมเมอร์เลือกที่จะแก้ไข technical debt, defect ต่างๆ หรือการ refactor code ได้ด้วยตนเอง เช่นอาจจะแบ่งเวลางานสัก 20% มาทำ หรืออาจจะกำหนดให้งานนี้เป็นส่วนหนึ่งของงานประจำวันไปเลย เป็นต้น ผลลัพธ์ของการทำแบบนี้อย่างต่อเนื่อง นอกจากจะทำให้แก้ปัญหาที่เคยเกิดขึ้นในอดีตอย่างถาวรแล้ว ยังทำให้พบปัญหาที่จะเกิดขึ้นในอนาคตได้รวดเร็วขึ้น ส่งผลให้สามารถแก้ปัญหาได้อย่างทันท่วงทีในขณะที่ปัญหายังมีขนาดเล็กซึ่งยังแก้ไขได้ง่ายอยู่อีกด้วย
การเปลี่ยนความรู้ระดับบุคคลสู่ความรู้ทั่วทั้งองค์กร
เมื่อมีความรู้ใหม่ถูกค้นพบจากความเชี่ยวชาญและประสบการณ์การทำงานของคนใดคนหนึ่ง เราต้องมีกลไกในการส่งต่อความรู้นี้ไปให้คนทั้งองค์กรได้ใช้ประโยชน์ และสามารถนำความรู้นี้ไปฝึกฝนให้เชี่ยวชาญได้
สำหรับหน่วยงาน IT เราอาจจะทำได้โดยนำ report ที่บันทึกเกี่ยวกับวิธีการแก้ปัญหาในครั้งก่อนๆ มาเผยแพร่และจัดทำในรูปแบบที่ให้คนอื่นสามารถค้นหาได้ง่ายๆ เพื่อให้เป็นแนวทางในการแก้ไขปัญหาที่คล้ายๆกัน และสร้าง source code repository ส่วนกลางที่ให้ทุกคนมาแชร์ code, library และ configuration file ต่างๆ เผื่อว่าถ้ามี code ที่เคยเขียนมาก่อนใน repository แล้ว จะได้นำไปใช้ประโยชน์ต่อได้ทันทีไม่ต้องเขียน code ซ้ำอีก นอกจากนี้ยังเป็นการแลกเปลี่ยนวิธีการเขียน code ระหว่างคนในองค์กรซึ่งสามารถนำไปสร้างเป็น best practice สำหรับองค์กรนั้นๆต่อไปได้ รวมถึงเป็นแหล่งเรียนรู้ชั้นดีให้กับโปรแกรมเมอร์ที่ยังมีประสบการณ์น้อยอีกด้วย
การเพิ่มประสิทธิภาพด้วยการทดลองที่ท้าทาย
ในบางครั้ง องค์กรก็มีวิธีการลดความเสี่ยงหรือเพิ่มประสิทธิภาพการทำงานด้วยการเพิ่ม resource ขึ้นไปเรื่อยๆ จนเป็นการเพิ่ม cost มากเกินกว่าความจำเป็น และสร้างความยุ่งยากให้มากขึ้น อย่างเช่น สมมติว่าหน่วยงาน IT ได้รับโปรเจคพัฒนา software และเริ่มพัฒนาไปแล้วระยะหนึ่ง แต่มีแนวโน้มว่าโปรเจคจะไม่เสร็จตามกำหนดเวลา ผู้บริหารอาจจะแก้ปัญหาโดยไปจ้างโปรแกรมเมอร์คนใหม่มาเพิ่มขึ้นอีกเยอะๆ เพื่อให้งานเสร็จ ซึ่งในบางบริบทอาจจะเป็นการเพิ่ม cost โดยไม่จำเป็นและเพิ่มความยุ่งยากในการทำงานร่วมกัน
ในขณะเดียวกัน เราสามารถลดความเสี่ยงหรือเพิ่มประสิทธิภาพการทำงาน ให้ได้ผลลัพธ์เท่ากับหรือมากกว่าตัวอย่างด้านบน โดยไม่ต้องเพิ่ม cost ใดๆด้วยการทดลองปรับปรุงกระบวนการทำงานประจำวันอย่างต่อเนื่อง และทดลองเพิ่มความท้าทายให้กับงาน ประจำวัน ยกตัวอย่างเช่น ทดลองหาวิธีการที่จะสามารถลดระยะเวลาการพัฒนา software ได้, ทดลองหาวิธีลดระยะเวลาการประมวลผลของระบบ หรือแม้แต่ทดลอง re-architect ระบบใหม่เพื่อเพิ่ม performance ให้ระบบหรือเพิ่ม productivity ของโปรแกรมเมอร์ เป็นต้น
ในองค์กร IT ชื่อดังอย่าง netflix ก็มีการทดลองซึ่งท้าทายในระดับที่ว่าใช้โปรแกรมที่เขียนขึ้นมาเองอย่าง chaos monkey random ให้ server ที่ production ล่มเลยทีเดียว ซึ่งผลลัพธ์ของการทำแบบนี้ก็คือ netflix มีภูมิคุ้มกันกับเรื่อง server ล่มและสามารถรับมือได้เป็นอย่างดีเมื่อมีเหตุการณ์ server ล่มเกิดขึ้นจริงๆ
ผู้นำต้องสนับสนุนวัฒนธรรมแห่งการเรียนรู้
โดยปกติแล้ว ผู้นำขององค์กรจะมีหน้าที่ตั้งเป้าหมายแล้วมอบหมายหน้าที่งานให้คนที่เหมาะสม เพื่อให้บรรลุเป้าหมายที่ตั้งไว้ รวมถึงมีหน้าที่สร้างบรรยากาศในการทำงาน เพื่อให้ทุกคนทำงานร่วมกันได้อย่างที่ตั้งใจไว้ ทักษะที่ผู้นำขาดไม่ได้เลยคือทักษะการตัดสินใจที่ถูกต้อง
แต่อย่างไรก็ตามหลายๆองค์กรพิสูจน์ให้เห็นแล้วว่า ความสำเร็จไม่ได้มาจากการที่ผู้นำสามารถตัดสินใจได้ถูกต้องคนเดียวทั้งหมด แต่ความสำเร็จมาจากการที่ผู้นำและผู้ปฏิบัติงานร่วมมือกันแก้ไขปัญหาและปรับปรุงงานประจำวันที่ทำอยู่ให้ดีขึ้นเรื่อยๆ ผู้นำและผู้ปฏิบัติงานต้องพึ่งพาอาศัยซึ่งกันและกันเพราะไม่มีใครแก้ปัญหาเดี่ยวๆได้ เนื่องจากผู้นำก็ไม่รู้รายละเอียดงานในเชิงลึกที่ต้องใช้ในการแก้ปัญหา และผู้ปฏิบัติงานก็ไม่รู้รายละเอียดงานในเชิงกว้างรวมถึงไม่มีอำนาจในการเปลี่ยนแปลงส่วนงานอื่นที่ตนเองไม่ได้รับผิดชอบอีกด้วย
โดยลักษณะการร่วมมือนั้น ผู้นำต้องทำหน้าที่เป็นคนให้โจทย์และเป็น coach คอยตั้งคำถามให้ผู้ปฏิบัติงานสามารถมองเห็นและแก้ปัญหาได้ด้วยตนเอง ซึ่งเป็นการสนับสนุนให้ผู้ปฏิบัติงานเรียนรู้ผ่านการแก้ปัญหา หรือที่เรียกว่าการเรียนรู้แบบ Problem-based learning
ยกตัวอย่างเช่นผู้นำอาจจะตั้งโจทย์ที่เป็นเป้าหมายระยะยาวไว้ว่า ภายในหนึ่งปีจะต้องส่งมอบ software ให้เร็วกว่าเดิมอย่างน้อย 2 เท่า และตั้งเป้าหมายระยะสั้นไว้ว่าในแต่ละเดือนต้องส่งมอบ software ให้เร็วกว่าเดิม 10% ผู้ปฏิบัติงานก็จะต้องใช้วิธีการคล้ายๆกับการทดลองทางวิทยาศาสตร์มาช่วยคือ ตั้งสมมติฐานเกี่ยวกับวิธีที่จะบรรลุเป้าหมาย ทดสอบสมมติฐานที่ตั้งขึ้นมา และนำความรู้ที่ได้จากผลทดสอบเดือนนี้ ไปใช้กับเดือนถัดๆไป เพื่อให้เป้าหมายสำเร็จ ทำอย่างนี้วนไปเรื่อยๆจนครบหนึ่งปี โดยระหว่างการทำงานผู้นำจะมีหน้าที่ในการ coach โดยการถามคำถามให้ผู้ปฏิบัติงานฉุกคิด เช่น คุณได้เรียนรู้อะไรบ้าง, อุปสรรคของคุณในตอนนี้คืออะไร, คุณจะทำอะไรต่อเป็นลำดับถัดไป, ผลลัพธ์ที่คุณคาดหวังคืออะไร, เราสามารถตรวจสอบผลได้เมื่อไหร่ เป็นต้น
สรุปว่าหลักการข้อนี้ต้องการที่จะสร้างองค์กรแห่งการเรียนรู้ให้เกิดขึ้น โดยการสร้างพื้นที่ปลอดภัยเพื่อการเรียนรู้ในองค์กร, จัดสรรเวลาให้มีการปรับปรุงงานที่ทำอย่างต่อเนื่อง, เปลี่ยนความรู้ระดับบุคคลสู่ความรู้ทั่วทั้งองค์กร, เพิ่มประสิทธิภาพด้วยการทดลองที่ท้าทายและผู้นำต้องสนับสนุนวัฒนธรรมแห่งการเรียนรู้ ผลลัพธ์ที่เกิดขึ้นไม่ใช่แค่มีประสิทธิภาพการทำงานที่ดีขึ้น แต่ยังเพิ่มความพึงพอใจในงาน และเพิ่มความสามารถในการปรับตัวขององค์กรอีกด้วย
เอกสารอ้างอิง
หนังสือ DevOps Handbook : How to Create World-Class Agility, Reliability, and Security in Technology Organizations (2016). โดย Gene Kim, Jez Humble, Patrick Debois, John Willis.