ช่วงนี้ผมให้ความสนใจเกี่ยวกับการนำ “DevOps” มาใช้ในการจัดการองค์กรให้มีประสิทธิภาพ ซึ่งเป็นแนวคิดที่ผสมผสานกันระหว่าง Development และ IT Operations โดยอาศัยกระบวนการพัฒนา (Development) การทดสอบ (Testing) และโครงสร้างพื้นฐานทาง IT (IT Infrastructure) เพื่อสร้างห่วงโซ่คุณค่า (Value Stream Chain) ในการตอบสนองโจทย์ทางธุรกิจขององค์กร
นอกจากนี้ยังนำหลักการที่ใช้ในการบริหารจัดการโรงงานมาใช้ร่วมกันด้วย เช่น Toyota มีการใช้ Lean Management, Kanban, และการจัดการ WIP (Work In Progress) ซึ่งเป็นหลักการที่ดีที่เราสามารถนำมาปรับใช้กับสายงานด้านข้อมูล (data) และสายงาน ML โดยเรียกใหม่ว่า DataOps และ MLOps โดยทำให้โครงสร้างพื้นฐานมีความยืดหยุ่นและปรับเปลี่ยนได้ (อ่านบทความเพิ่มเติมเรื่อง องค์กรที่ใช้ความยืดหยุ่นเป็นแนวทางปฏิบัติ: )
มีคนแนะนำให้ผมอ่านหนังสือ The Phoenix Project เป็นเรื่องราวเกี่ยวกับบริษัท Part Unlimited ผู้ผลิตอุปกรณ์อะไหล่รถที่มีปัญหาด้านโครงสร้างพื้นฐานด้าน IT จึงได้มีการใช้หลักการ DevOps เข้ามาช่วยจัดการระบบให้มีความเสถียรขึ้น ซึ่ง Bill ตัวละครหลักของเรื่องได้เข้ามาดูแล Phoenix Project ที่ช่วยทำให้สาขาต่าง ๆ สามารถเชื่อมโยงกับ e-commerce ของบริษัทซึ่งช่วยสร้างรายได้และประสบการณ์ที่ดีกับลูกค้า ซึ่งผมขอสรุปเป็นแนวทางที่เรียกว่า “หลักการ 345” ดังรายละเอียดต่อไปนี้
3 Ways — DevOps Patterns
1. The First Way — Maximize the Flow of Work
การพัฒนาซอฟท์แวร์หรือข้อมูล ไปสู่การใช้งานของลูกค้า (Production Deployment) มีสิ่งที่สำคัญในการเพิ่มประสิทธิภาพการทำงาน คือ
- การจัดการขนาดของงานและระยะเวลางานที่เหมาะสม
- การไม่มีข้อบกพร่อง ความเสียหาย (defect) ของซอฟท์แวร์หรือข้อมูล ที่จะถูกส่งต่อไปยังขั้นตอนถัดไป ซึ่งในทาง DevOps สามารถทำได้ด้วยการใช้ Automated Testing มาเป็นส่วนหนึ่งของการตรวจสอบงานก่อนส่งต่อไปยังขั้นตอนถัดไปได้
- การจัดการทรัพยากรที่เป็นข้อจำกัดหรือคอขวด (Bottleneck) ของระบบ (Manage Constraints) ซึ่งแนวคิดนี้ได้รับอิทธิพลมาจากหนังสือ The Goal: A Process of Ongoing Improvement ของ Dr. Eliyahu Goldratt เล่าถึงตัวละครที่ชื่อ Brent ที่มีความสามารถทำได้ทุกอย่าง ทำให้มีคนวิ่งเข้าไปขอความช่วยเหลืออยู่ตลอด จนเขากลายเป็นคอขวดของโครงการ หัวหน้างานจึงแก้ไขโดยการยกเลิกงานที่ไม่จำเป็นออกจากเขา และสอนงานคนอื่นในทีม เพื่อให้เขาไม่ต้องลงมือทำเองทุกอย่าง ซึ่งเป็นหนึ่งในทฤษฎี Constraints (Theory of Constraints or TOC) ที่ให้ความสำคัญกับการจัดการข้อจำกัดต่าง ๆ ที่จะทำให้งานบรรลุเป้าหมายอย่างไม่ติดขัด รวมทั้งการจัดการงานที่ไม่ได้อยู่ในแผนงาน (Unplanned work) ที่มาสร้างภาระให้กับคนทำงานสำคัญของโครงการ และการลดงานที่ค้างคาในระบบ (Work In Progress or WIP)
2. The Second Way — Fast Feedback
การได้รับรู้ผลตอบสนองอย่างรวดเร็ว เช่น กรณีที่โรงงานจะมีการหยุดการผลิตเพื่อตรวจสอบข้อผิดพลาดและแก้ปัญหานั้นไม่ให้สะสมเรื้อรัง เราเรียกว่า Technical Debt ซึ่งสิ่งที่กระบวนการนี้เน้นคือการใช้ Automated Test อย่างรวดเร็วเพื่อให้สามารถนำโมเดลไปใช้งานต่อได้
3. The Third Way — Continual Experiment and Mastery
แนวทางที่ 3 นี้จะเน้นเรื่องการสร้างวัฒนธรรมที่จะทดลองปรับปรุงงานให้ดีขึ้นอย่างต่อเนื่อง (Continual Experiment) และฝึกปรือให้มีความชำนาญ (Mastery) เพื่อให้มีการปรับปรุงกระบวนการให้มีประสิทธิภาพสูงสุด
4. Types of Works
เราควรทำความเข้าใจลักษณะหรือประเภทของงานที่แตกต่างกัน เพราะการเลือกวิธีในการบริหารจัดการงานให้มีประสิทธิภาพก็ย่อมแตกต่างกันไปเช่นกัน งานจากลักษณะของงานพื้นฐานที่พบในทุกองค์กร เราสามารถแบ่งประเภทของงานได้เป็น 4 รูปแบบ ได้แก่
- Business Projects งานที่เกี่ยวข้องกับธุรกิจของบริษัทโดยตรง เช่น ผลิตภัณฑ์หรือบริการ
- Internal IT Projects งานที่เกี่ยวข้องกับโครงสร้างพื้นฐาน IT ที่จะไปรองรับงานในบริษัทหรือโครงการอื่น ๆ
- Changes เป็นงานที่ทำขึ้นเพื่อขอเปลี่ยนแปลงความต้องการบางอย่างของ 2 รูปแบบแรก
- Unplanned Works งานที่ไม่ได้อยู่ในแผนงาน ส่วนใหญ่เป็นปัญหาที่ไม่คาดคิดจาก 3 งานแรก ในการจัดการโครงการ ถ้าสามารถลดงานแบบนี้ได้ด้วยการใช้ Automation ก็จะช่วยลดความผิดพลาดที่เกิดจากมนุษย์ (Human Error) รวมทั้งช่วยให้ขั้นตอนต่าง ๆ ในการทำงานราบรื่นขึ้นด้วย
5. Dysfunctions of a Team
การที่โครงการจะสามารถทำงานได้ดีนั้น ต้องมีทีมงานที่ทำงานร่วมกันได้อย่างดีด้วย ในหนังสือ The Five Dysfunctions of a Team ของ Patrick Lencioni ได้พูดถึง 5 สิ่งที่ต้องระวังในการสร้างทีม ได้แก่
- Absence of Trust ทีมงานที่ไม่มีความเชื่อใจกัน กลัวที่จะยอมรับความผิดหรือเปิดเผยจุดอ่อนของตัวเองให้คนในทีมรู้ เพื่อขอความช่วยเหลือ วิธีแก้ไข คือ แสดงความเป็นผู้นำโดยยอมรับจุดอ่อนของตัวเองและนำจุดแข็งของคนในทีมมาช่วยเสริ
- Fear of Conflict ทีมงานที่กลัวความขัดแย้ง จริง ๆ แล้วเราสามารถหาจุดร่วมของความเห็นต่างได้ ซึ่งอาจนำมาซึ่งไอเดียใหม่ ๆ เราอาจจะแสดงให้เห็นว่าความเห็นต่างมีประโยชน์อย่างไร โดยการสร้างเป็นตารางแสดงให้เห็นข้อดี ข้อเสียของหัวข้อที่กำลังถกเถียงกัน หรืออาจจะกำหนดให้คนใดคนหนึ่งในทีมเป็นคนที่มองต่างจากเพื่อน (Devils’ advocate)
- Lack of commitment ทีมที่ขาดบทสรุปหรือข้อตกลงร่วมกัน วิธีแก้ไข คือ มีการกำหนดเวลาในการตัดสินใจ พิจารณาข้อดี ข้อเสียเพื่อหาบทสรุปร่วมกัน
- Avoidance of Accountability ทีมที่หลีกเลี่ยงความรับผิดชอบ วิธีแก้ไขคือ กำหนดกฎเกณฑ์ ตรวจสอบความคืบหน้าของงานอย่างต่อเนื่อง และให้รางวัลหรือกำลังใจกับความสำเร็จของทีม
- Inattention to Results ทีมที่สนใจงานของตัวเองมากกว่างานของทีม วิธีแก้ไขคือ เน้นการวัด KPI และให้รางวัลที่ระดับทีมแทนระดับบุคคล
หลักการ 345 ที่ผมสรุปมานี้ ผู้อ่านสามารถนำไปประยุกต์ใช้กับการบริหารโครงการต่าง ๆ ที่มีเทคโนโลยีเป็นส่วนสำคัญของธุรกิจ โดยพิจารณาการบริหารจัดการให้ขั้นตอนการทำงานต่าง ๆ มีประสิทธิภาพ การใช้ทรัพยาการให้คุ้มค่า รวมทั้งสร้างความยืดหยุ่นและการตรวจสอบกระบวนการทำงานต่าง ๆ เพื่อลดข้อผิดพลาดที่เกิดจากคนให้ได้มากที่สุด ขอให้ทุกท่านสนุกกับแนวคิดใหม่นี้ครับ
แหล่งอ้างอิง:
- The Phoenix Project by Gene Kim, George Spafford, and Kevin Behr
- High 5 Test
บทความโดย: คุณจรัล งามวิโรจน์เจริญ Chief Data Scientist & VP of Data Innovation Labบริษัท เซอร์ทิส จำกัด
Originally published at https://www.sertiscorp.com/
