DevOps Handbook #3 : The three ways (Cont.)

Pasita T
2 min readApr 22, 2018

--

ตอนนี้ก้อต่อกันด้วย Way ที่สองและสาม

Way #2 The Principles of Feedback

ใน Way แรกจะพูดถึง left-to-right ส่วน Way นี้ย้อนศรกลับเป็น right-to-left คือ การทำให้ feedback กลับมาหาต้นทางได้ใน ทุกๆขั้น ของการทำงาน หลักการคือเพื่อสร้างระบบที่ปลอดภัยในการทำงานโดยพูดถึงหัวข้อ ตามนี้

  • See problems as they occur — คือ เราต้องเห็น feedback ต่างๆได้อย่างถูกต้องรวดเร็ว feedback ก็มีหลายอย่าง เช่น ผล test, error ที่เกิดขึ้นในระบบ หรือการตอบรับจาก user
  • Swarm and solve problems to build new knowledge — ทีนี้เมื่อเราเห็นปัญหาแล้วต้องทำยังไง เค้าพูดถึงแนวคิดแบบ “Andon cord” ของ Toyota คือในไลน์ผลิตจะมีเชือกอยู่อันนึง ใครก้อตามที่พบปัญหา ไม่ว่าจะเป็น defect หรือชิ้นส่วนไม่มา หรือมาช้า จะดึงเชือกนี้ หัวหน้าทีมก็จะมาดูแลแก้ไขปัญหาทันที ถ้าแก้ไม่ได้ในเวลาที่กำหนด ไลน์การผลิตต้องหยุดเพื่อแก้ปัญหา คือ แทนที่จะไม่เป็นไร อันอื่นพอทำได้ทำไปก่อนค่อยมาแก้ทีหลัง เค้าจะแก้ทันที เพื่อจะป้องกันไม่ให้ปัญหานี้ไปก่อปัญหาในขั้นตอนต่อไป(downstream) และป้องกันไม่ให้จุดนี้ทำงานชิ้นใหม่และมีปัญหาขึ้นซ้ำอีก นอกจากนี้การแก้ปัญหานี้จะเป็นการสร้างความรู้ให้กับคนที่สร้างปัญหานี้และคนอื่นไม่ให้เกิดซ้ำอีก
  • Keep push quality closer to the source —เวลาที่งานออกมาไม่มีคุณภาพแล้วต้องปรับปรุงกระบวนการ หลายๆครั้งคนก็มักจะแก้โดยเพิ่มคน approve เข้าไป แต่ในที่นี้เค้าบอกว่า “ประสิทธิภาพของ approval จะลดลง ถ้าคนตัดสินใจไม่ได้อยู่ใกล้งานที่ทำ การไปเพิ่มขั้นตอน approval โดยใช้คนที่อยู่ห่างจากงานไม่ใช่แค่ลดคุณภาพการตัดสินใจ แต่ยังเพิ่มเวลาในการทำงานเข้าไปอีก” แนวคิดนี้คือ เราต้องการให้ทุกๆคนใน value stream นี้มีการหาปัญหาและแก้ไขสิ่งที่เกิดขึ้นในงานตัวเองและมองสิ่งนี้เป็นส่วนหนึ่งของหน้าที่ประจำวัน วิธีที่ใช้ก้อเช่น peer review กันในกลุ่ม หรือ automate งานพวก quality check, security check คือแทนที่ dev ต้องไปรอทีม QA ทีม security ก็กด automate test เห็น feedback ตัวเองแล้วแก้ไขเองเลย ด้วยกระบวนการนี้เป็นการทำให้การดูแลคุณภาพงานนั้นเป็นหน้าที่รับผิดชอบของทุกคน ไม่ใช่หน้าที่ของ QA เพียงอย่างเดียว
  • Enable optimizing for downstream work centers — คำถามน่าคิดคือ ลูกค้าคนไหนสำคัญที่สุด คือในการทำงานเราจะมีลูกค้าภายในและภายนอก เรามักนึกถึงลูกค้าภายนอก แต่เราไม่สนคนภายในเท่าไหร่ ในแนวคิดนี้บอกว่าลูกค้าที่สำคัญที่สุดของคุณก้อคือ แต่นแต้น… “our next step downstream” คนที่รับงานชิ้นนี้ไปทำต่อจากคุณนั่นเองจ้า ในที่ที่คิดแบบนี้จะมีการคิดเช่นว่าเราจะออกแบบ part ที่เหมือนกันทั้งสองด้านนะ เผื่อคนประกอบได้ประกอบง่ายวางสลับข้างกันก็ยังใช้ได้ ไม่ใช่คิดว่า การใส่ part สลับข้างนี่เป็นปัญหาฝ่ายผลิต ไม่ใช่ฝ่ายออกแบบ เราอยู่ฝ่ายออกแบบ ออกแบบแล้วลูกค้าชอบจบ

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

Way #3 The Principles of Continual Learning and Experimentation

อันนี้ถึอเป็นขั้นสุดยอดของกระบวนการ คือ การสร้าง high-trust culture ที่ทำให้คนของเรามี disciplined, dynamic และมีแนวคิดแบบวิทยาศาสตร์ที่จะทำการทดลองใหม่ๆ และพร้อมที่จะเรียนรู้จากความสำเร็จและล้มเหลว

  • Enabling organizational learning and a safety culture — พื้นฐานคือ ไม่โทษกันนั่นแหละ เวลามีเรื่องแทนที่จะต้องไม่มุ่งถามว่าใครทำผิด แต่ต้องถามหาและช่วยกันคิด redesign ระบบให้ป้องกันปัญหานี้
  • Institutionalize the improvement of daily work — คือการที่ทีมคอยปรับปรุงวิธีทำงานอยู่เสมอ ซึ่งจะเกิดได้เมื่อเรากำหนดเวลาไว้ทำเรื่องพวกนี้ด้วย อาจจะมี kaizen blitzes คือช่วงที่จะ self-oraganize เพื่อจัดการปัญหาที่ตัวเองต้องการ
  • Transform local discoveries into global improvement — คือ ทำให้ความรู้ที่เกิดขึ้นระหว่างการทำงานของคนหนึ่งๆเป็นความรู้ของทั้งองค์กร โดยการจัดให้มีระบบที่จะแชร์ข้อมูล ค้นหาได้ง่าย
  • Inject resilience pattern into our daily work —สร้าง resilience ให้ระบบโดยการใส่ ‘tension to elevate performance’ ลงไป คือ คอยตั้งโจทย์ใหม่ขึ้นมา เช่นว่า ทำยังไง เราถึงจะลด deploy lead time ไปเป็น xx, หรือเพิ่ม test coverage เป็นอย่างนี้ๆได้มั้ย รวมถึงการทำการทดลองอยู่เรื่อยๆ ตัวอย่างของการทดสอบอย่างสม่ำเสมอคงไม่มีอะไรน่าสนใจไปกว่าเคส “Chaos Monkey” ของ Netflix อันนี้ลองอ่านเพิ่มเติมได้ (คหสต คือ ชอบความบ้าบิ่นนี้มาก)
  • Leaders reinforce a learning culture — คือผู้นำจะต้องให้คุณค่าของการเรียนรู้และแก้ปัญหาอย่างมีวินัย เค้าเรียกอันนี้ว่า “coaching kata” ซึ่งผู้นำจะมีบทบาทสำคัญในการตั้งคำถามในทีม เช่น เราทำอะไรไป เราเรียนรู้อะไรจากเรื่องนี้ สถานการณ์ปัจจุบันเป็นยังไง แล้วเป้าหมายต่อไปคืออะไร ผลที่เราอยากได้คืออะไร

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

Note: อันนี้เป็นสรุปจากการอ่านหนังสือ DevOps Handbook อาจมีผิดถูกบ้าง + มีคหสตบ้างเล็กน้อย ถ้าสนใจไปซื้อหาอ่านเล่มจริงกันต่อได้

ติดตามตอนอื่นๆ

--

--