แนวทางแรกของ DevOps และ Value Stream Mapping (VSM)

VSM

แนวทางแรกของ DevOps (The First Way of DevOps) มุ่งเน้นไปที่เรื่องโฟล์หรือการไหลอย่างต่อเนื่องของงานจากการพัฒนาไปสู่การปฏิบัติการและสุดท้ายถึงลูกค้า โดยมุ่งเน้นการปรับปรุงความเร็ว ประสิทธิภาพ และคุณภาพในการส่งมอบคุณค่า นั่นทำให้เราต้องเข้าใจเครื่องมือหนึ่งอย่างที่เอาไว้ใช้วัด Flow นั่นคือ Value Stream Mapping (VSM) เครื่องมือนี้มีความสามารถที่สอดคล้องกับหลักการนี้โดยตรง เนื่องจากช่วยให้มองเห็น วิเคราะห์ และปรับปรุงการไหลของงาน ทำให้ VSM เป็นเครื่องมือสำคัญในการสนับสนุนแนวทางแรก นี่คือวิธีที่ VSM และแนวทางแรกของ DevOps เชื่อมโยงกันเช่นเราสามารถใช้มันทำให้เรา การมองเห็นการไหลของงานทั้งหมด, การระบุคอขวดและข้อจำกัด หรือ การลดความสิ้นเปลืองและเพิ่มประสิทธิภาพการไหล

หลัการพื้นฐานของ VSM

ว่าแต่ว่าพอเราเข้าใจแล้วเราจะทำยังไงหล่ะเจ้า VSM เนี่ย กระบวนการ (stream) ควรแสดงให้เห็นถึงทุกสิ่งที่อยู่ระหว่างจุดเริ่มต้นและจุดสิ้นสุด ตั้งแต่การพัฒนาผลิตภัณฑ์ไปจนถึงการใช้งานจริง จากหลักการของ Lean และ Six Sigma แนะนำให้วัดสิ่งต่าง ๆ เช่น เวลาที่เพิ่มมูลค่า (value added time) และระยะเวลาที่ใช้ในการทำงาน (lead time)

• เพิ่มมูลค่า (Value Added — VA) เวลาที่เพิ่มมูลค่า คือระยะเวลาที่ทีมใช้ในการทำงานโครงการจริง ๆ (ตรงข้ามกับ ตัวอย่างเช่น เวลาที่โครงการหรือคำขออยู่ในคิว) เมื่อใดก็ตามที่ไม่มีการเปลี่ยนแปลงในผลิตภัณฑ์ ถือว่าเป็นเวลาที่ไม่เพิ่มมูลค่า
• ระยะเวลาที่ใช้ในการทำงาน (Lead Time — LT) ระยะเวลาที่ใช้ในการทำงาน หมายถึงเวลาทั้งหมดที่บุคคลหรือทีมใช้ในการทำงานให้เสร็จสมบูรณ์ ซึ่งเป็นการรวมกันของเวลาที่เพิ่มมูลค่าและเวลาที่ไม่เพิ่มมูลค่า
• % สมบูรณ์/ถูกต้อง (% Complete/Accurate — %C/A) นี่คือเปอร์เซ็นต์ของงานที่อิงตามข้อมูล ซึ่งเสร็จสมบูรณ์และถูกต้องในครั้งแรก และไม่จำเป็นต้องมีการแก้ไขโดยกระบวนการในภายหลัง

ขยายความเรื่อง Value Added — VA

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

• การเขียนโค้ดและการพัฒนา: การเขียนโค้ดใหม่ การนำฟีเจอร์ไปใช้ การแก้ไขข้อผิดพลาด
• การทดสอบ: การดำเนินการทดสอบหน่วย ทดสอบการรวมระบบ ทดสอบการยอมรับจากผู้ใช้ (UAT) เพื่อให้แน่ใจว่าซอฟต์แวร์ทำงานตามที่ต้องการ
• การตรวจสอบโค้ด(Coding Standard Check): การตรวจสอบโค้ดเพื่อคุณภาพ ความสามารถในการบำรุงรักษา และการปฏิบัติตามมาตรฐาน
• การปรับใช้ (Release and Deploy): การปรับใช้ซอฟต์แวร์ในสภาพแวดล้อมการผลิตหรือสภาพแวดล้อมสำหรับการทดสอบ
• การสนับสนุนลูกค้า(Support): การโต้ตอบโดยตรงกับผู้ใช้เพื่อแก้ไขปัญหา รวบรวมข้อเสนอแนะ และให้ความช่วยเหลือ

ตัวอย่างของกิจกรรมที่ไม่เพิ่มมูลค่าในการพัฒนาซอฟต์แวร์:

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

สร้างแผนภาพการทำงานที่เป็นแบบปัจจุบันก่อน (As — IS)

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

As Is

จากแผนภาพนี้เราเห็นได้ชัดเลยว่ามี waste หลายที่และเราทั้งทีมเข้าใจตรงกันว่านี่คือ คอขวด ที่ทำให้เราทำงานล่าช้า
การรอคอย (ความล่าช้า):
ความแตกต่างอย่างมีนัยสำคัญระหว่าง Lead Time (LT) และ Value-Added Time (VA) ในแต่ละขั้นตอนบ่งชี้ถึงเวลาในการรอคอยหรือความล่าช้าที่อาจเกิดขึ้น

การพัฒนา Development (LT: 144 ชั่วโมง, VA: 17 ชั่วโมง): นี่แสดงให้เห็นว่ามีช่วงเวลาจำนวนมากที่งานน่าจะอยู่ในคิวหรือรอการดำเนินการอื่นๆ ที่เกี่ยวข้อง

การ Deploy ไปที่ Pre-Production (LT: 31 ชั่วโมง, VA: 0.5 ชั่วโมง): นี่บ่งชี้ถึงปัญหาคอขวดที่อาจเกิดขึ้นในกระบวนการปรับใช้ ซึ่งทำให้เกิดความล่าช้า

ขั้นตอนอื่นๆ ก็แสดงให้เห็นถึงความแตกต่างนี้เช่นกัน แม้ว่าจะในระดับที่น้อยกว่า

ข้อบกพร่องและการแก้ไขงานซ้ำ:

“%C/A” โดยรวมที่ต่ำ (13%) แสดงให้เห็นว่ามีการแก้ไขงานซ้ำหรือการแก้ไขจำนวนมากที่เกิดขึ้นในภายหลัง

“%C/A” ที่ต่ำเป็นพิเศษ (44%) สำหรับ “Submit Request to Fix Bug” บ่งชี้ว่าการแก้ไขข้อผิดพลาดมักจะไม่สมบูรณ์หรือไม่ถูกต้อง จึงต้องใช้ความพยายามเพิ่มเติม

ออกแบบ VSM ที่องค์กรของเราอยากได้

To Be

เมื่อเราเห็นแล้วว่ากระบวนการทำงานแบบเดิมมีข้อจำกัดอะไรบ้าง สิ่งทีเราต้องทำคือออกแบบ VSM ใหม่ที่เราใช้ เครื่องมือหลายๆอย่างเข้ามาช่วย หรือ เปลี่ยนกระบวนการทำงาน หรือ การประสานงานระว่างทีมเพื่อให้เราทำงานได้ดีขึ้น ตัวอย่างนี้สิ่งที่เราพยายามลดคือ Non Value Added Time ที่เกิดระหว่างขั้นตอนการทำงานดังนั้่น เราจึงสามารถวัดผลได้ด้วยจากภาพเราจะเห็นว่าสิ่งที่เปลี่ยนไปคือ Total Lead Time ลดลงไป 7 ชั่วโมงในขณะที่ Total Value Added Time ไม่เปลี่ยนไปมาก ทำให้ Ratio %C/A เพิ่มขึ้นเป็น 24% และเมื่อเราได้มาซึ่ง VSM ใหม่แล้วสิ่งที่ควรทำต่อไปคือ การสื่อสารสิ่งนี้ออกไป

การสื่อสารการเปลี่ยนแปลงสู่หน่วยงานหลังจากได้ VSM ใหม่

เมื่อคุณมี Value Stream Map (VSM) ใหม่ที่ระบุถึงการปรับปรุงและการเปลี่ยนแปลงที่จำเป็น การสื่อสารที่มีประสิทธิภาพต่อองค์กรเป็นสิ่งสำคัญในการสร้างความเข้าใจร่วมกัน สร้างการยอมรับ และทำให้การเปลี่ยนแปลงราบรื่นและเราควรสื่อสารการเปลียนแปลงด้วยคำแนะนำเหล่านี้

1. เริ่มต้นด้วย “ทำไม”

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

2. แสดงภาพ VSM ปัจจุบันและอนาคต

• การนำเสนอด้วยภาพ: ใช้ VSM เพื่อแสดงให้เห็นถึงกระบวนการทำงานในปัจจุบันและกระบวนการที่ได้รับการปรับปรุงแล้ว เน้นถึงบริเวณที่มีของเสียและการปรับปรุงที่นำเสนอ
• ใช้ภาษาที่เข้าใจง่าย: หลีกเลี่ยงศัพท์เฉพาะทางและอธิบายแนวคิดในลักษณะที่ผู้ชมทุกคนสามารถเข้าใจได้
• เน้นผลประโยชน์: เน้นย้ำถึงผลประโยชน์ที่คาดว่าจะได้รับจากการเปลี่ยนแปลง (เช่น ระยะเวลาที่ใช้ในการทำงานที่สั้นลง คุณภาพที่ดีขึ้น ประสิทธิภาพที่เพิ่มขึ้น)

3. สร้างการมีส่วนร่วมและการเป็นเจ้าของ

• การประชุมแบบ Town Hall หรือ Workshop: จัดการประชุมเพื่อนำเสนอ VSM และเปิดโอกาสให้มีการอภิปราย ซักถาม และให้ข้อเสนอแนะ
• เชิญผู้มีส่วนได้ส่วนเสียที่สำคัญ: ตรวจสอบให้แน่ใจว่าผู้มีบทบาทสำคัญในกระบวนการทำงานมีส่วนร่วมในการอภิปรายและการตัดสินใจ
• มอบหมายความเป็นเจ้าของ: กำหนดให้บุคคลหรือทีมรับผิดชอบในการดำเนินการปรับปรุงแต่ละอย่าง

4. สื่อสารอย่างต่อเนื่องตลอดการเปลี่ยนแปลง

• อัปเดตความคืบหน้าเป็นประจำ: ให้ข้อมูลอัปเดตเกี่ยวกับความคืบหน้าของการดำเนินการตามแผนการปรับปรุง
• เฉลิมฉลองความสำเร็จ: ยอมรับและให้รางวัลแก่ทีมและบุคคลสำหรับความสำเร็จและความพยายามของพวกเขา
• จัดการกับข้อกังวล: จัดการกับข้อกังวลหรือข้อโต้แย้งใด ๆ อย่างเปิดเผยและโปร่งใส

5. ใช้ช่องทางการสื่อสารที่หลากหลาย

• การนำเสนอ: ใช้สไลด์หรือเอกสารประกอบการนำเสนอ VSM และแผนการปรับปรุง
• อีเมล: ส่งอีเมลสรุปพร้อมลิงก์ไปยัง VSM และข้อมูลที่เกี่ยวข้อง
• เครื่องมือการทำงานร่วมกัน: ใช้เครื่องมือ เช่น Slack หรือ Microsoft Teams เพื่อการสื่อสารและการทำงานร่วมกันแบบเรียลไทม์

ปรับปรุงอย่างต่อเนื่อง

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

• อย่างน้อยปีละครั้ง: แม้ในสภาพแวดล้อมที่มั่นคง ขอแนะนำให้ตรวจสอบ VSM ของคุณอย่างน้อยปีละครั้งเพื่อให้แน่ใจว่ายังคงถูกต้องและสะท้อนถึงสถานะปัจจุบันของกระบวนการของคุณ
• หลังจากการเปลี่ยนแปลงครั้งสำคัญ: เมื่อใดก็ตามที่คุณดำเนินการเปลี่ยนแปลงที่สำคัญในกระบวนการ เทคโนโลยี หรือเครื่องมือของคุณ ให้ทบทวน VSM ของคุณเพื่อประเมินผลกระทบและระบุโอกาสใหม่ ๆ ในการปรับปรุง
• เมื่อประสิทธิภาพลดลง: หากคุณสังเกตเห็นการลดลงของตัวชี้วัดสำคัญ (เช่น ระยะเวลาที่ใช้ในการทำงาน คุณภาพ ความพึงพอใจของลูกค้า) ให้ทบทวน VSM ของคุณเพื่อระบุปัญหาคอขวดหรือความไร้ประสิทธิภาพที่อาจส่งผลต่อการลดลง
• เป็นส่วนหนึ่งของการทบทวนเป็นประจำ: รวมการทบทวน VSM ไว้ในการทบทวนตามปกติของทีม เพื่อส่งเสริมวัฒนธรรมแห่งการปรับปรุงอย่างต่อเนื่องและกระตุ้นให้มีการไตร่ตรองอย่างต่อเนื่องเกี่ยวกับกระบวนการของคุณ