Chapter 05 03 The Second Way The Principles Of Feedback

3

THE SECOND WAY: THE PRINCIPLES OF FEEDBACK (หลักการของ Feedback)

ในขณะที่ First Way อธิบายหลักการที่ทําให้งานไหลจากซ้ายไปขวาอย่างรวดเร็ว Second Way อธิบายหลักการที่ทําให้เกิด Feedback ที่รวดเร็วและต่อเนื่องจากขวากลับไปซ้ายในทุกขั้นตอนของ Value Stream เป้าหมายของเราคือการสร้างระบบการทํางานที่ปลอดภัยและยืดหยุ่นมากยิ่งขึ้น

สิ่งนี้สําคัญเป็นพิเศษเมื่อทํางานในระบบที่ซับซ้อน (Complex Systems) ซึ่งผลลัพธ์ที่ร้ายแรง เช่น พนักงานในโรงงานได้รับบาดเจ็บจากการทํางาน หรือเครื่องปฏิกรณ์นิวเคลียร์กําลังจะหลอมละลาย อาจเกิดขึ้นจากข้อผิดพลาดได้

ในสายงานเทคโนโลยี งานของเราเกิดขึ้นแทบจะทั้งหมดภายในระบบที่ซับซ้อน (Complex Systems) ซึ่งมีความเสี่ยงสูงต่อผลกระทบที่ร้ายแรง เช่นเดียวกับในอุตสาหกรรมการผลิต เรามักจะค้นพบปัญหาก็ต่อเมื่อความล้มเหลวครั้งใหญ่กําลังเกิดขึ้นแล้ว เช่น การหยุดทํางานของระบบ Production ครั้งใหญ่ หรือการละเมิดความปลอดภัยที่ส่งผลให้ข้อมูลลูกค้าถูกขโมย

เราทําให้ระบบการทํางานของเราปลอดภัยยิ่งขึ้นโดยการสร้างการไหลของข้อมูลที่รวดเร็ว บ่อยครั้ง และมีคุณภาพสูงทั่วทั้ง Value Stream และองค์กรของเรา ซึ่งรวมถึง feed back และ feed forward loops สิ่งนี้ช่วยให้เราตรวจพบและแก้ไขปัญหาในขณะที่ยังเล็ก ต้นทุนต่ํา และแก้ไขได้ง่ายกว่า สามารถหลีกเลี่ยงปัญหาก่อนที่จะเกิดหายนะ และสร้างการเรียนรู้ขององค์กรที่เรานําไปผสานกับงานในอนาคต เมื่อเกิดความล้มเหลวและอุบัติเหตุ เรามองว่าเป็นโอกาสในการเรียนรู้ ไม่ใช่เหตุผลในการลงโทษและกล่าวโทษ เพื่อให้บรรลุทั้งหมดนี้ เรามาสํารวจธรรมชาติของระบบที่ซับซ้อนและวิธีทําให้ปลอดภัยยิ่งขึ้นก่อน

Working Safely within Complex Systems (การทํางานอย่างปลอดภัยในระบบที่ซับซ้อน)

ลักษณะเด่นอย่างหนึ่งของระบบที่ซับซ้อน (Complex System) คือการที่ไม่มีบุคคลใดสามารถมองเห็นระบบทั้งหมดและเข้าใจว่าทุกส่วนประกอบกันอย่างไร ระบบที่ซับซ้อนมักมี Degree ของการเชื่อมต่อระหว่าง Component ต่างๆ ที่ Tightly Coupled ในระดับสูง และมีพฤติกรรมในระดับระบบที่ไม่สามารถอธิบายได้จากพฤติกรรมของ Component ย่อยๆ เพียงอย่างเดียว

Dr. Charles Perrow ศึกษาเหตุการณ์เครื่องปฏิกรณ์นิวเคลียร์หลอมละลายบางส่วนที่ Three Mile Island และพบว่ามันเป็นไปไม่ได้ที่ใครจะเข้าใจว่าปฏิกรณ์จะมีพฤติกรรมอย่างไรในทุกสถานการณ์ หรือจะล้มเหลวในรูปแบบใด 1 เมื่อเกิดปัญหาใน Component หนึ่ง การแยกมันออกจาก Component อื่นๆ เป็นเรื่องยาก ความล้มเหลวจะกระจายตัวอย่างรวดเร็วผ่าน Path ที่มีความต้านทานน้อยที่สุดในแบบที่คาดเดาไม่ได้

Dr. Sidney Dekker ผู้ซึ่งกำหนดองค์ประกอบสำคัญของ Safety Culture ไว้ด้วย สังเกตเห็นลักษณะอีกอย่างของระบบที่ซับซ้อน นั่นคือการทำสิ่งเดียวกันสองครั้งไม่ได้ให้ผลลัพธ์เดียวกันเสมอไป 2 ลักษณะนี้เองที่ทำให้ Static Checklists และ Best Practices แม้จะมีประโยชน์ แต่ก็ไม่เพียงพอที่จะป้องกันหรือจัดการกับหายนะได้อย่างมีประสิทธิภาพ (ดูเพิ่มเติมที่ ภาคผนวก 5 .)

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

หลังจาก Dr. Steven Spear ถอดรหัสกลไกของ Toyota Production System ซึ่งเป็นส่วนหนึ่งของวิทยานิพนธ์ระดับปริญญาเอกที่ Harvard Business School เขากล่าวว่าการออกแบบระบบที่ปลอดภัยอย่างสมบูรณ์แบบอาจเกินความสามารถของเรา แต่เราสามารถทำให้การทำงานในระบบที่ซับซ้อนปลอดภัยยิ่งขึ้นได้เมื่อตรงตามเงื่อนไขสี่ประการต่อไปนี้: 3 *

• งานที่ซับซ้อนได้รับการจัดการเพื่อให้ปัญหาในการออกแบบและการดำเนินงานถูกเปิดเผย

• ปัญหาถูก Swarm และแก้ไข ส่งผลให้เกิดการสร้างความรู้ใหม่อย่างรวดเร็ว

• ความรู้เฉพาะจุด (Local Knowledge) ใหม่ถูกนำไปใช้ประโยชน์ทั่วทั้งองค์กรในระดับ Global

• ผู้นำสร้างผู้นำคนอื่นๆ ที่จะพัฒนา Capabilities เหล่านี้อย่างต่อเนื่อง

ความสามารถ (Capabilities) แต่ละข้อเหล่านี้จำเป็นต่อการทำงานอย่างปลอดภัยในระบบที่ซับซ้อน ในหัวข้อถัดไป จะอธิบายสอง Capabilities แรกและความสำคัญ รวมถึงวิธีที่ Capabilities เหล่านี้ถูกสร้างขึ้นใน Domain อื่นๆ และแนวปฏิบัติที่ทำให้เกิด Capabilities เหล่านี้ใน Technology Value Stream (Capabilities ที่สามและสี่จะอธิบายใน บทที่ 4 .)

See Problems as They Occur (มองเห็นปัญหาเมื่อมันเกิดขึ้น)

ในระบบการทำงานที่ปลอดภัย เราต้องทดสอบสมมติฐานเกี่ยวกับการออกแบบและการดำเนินงานของเราอย่างสม่ำเสมอ เป้าหมายของเราคือการเพิ่มการไหลของข้อมูลในระบบของเราจากหลายๆ ด้านให้มากที่สุด โดยเร็วที่สุด ถูกที่สุด และมีความชัดเจนระหว่าง Cause และ Effect มากที่สุดเท่าที่จะทำได้ ยิ่งเราสามารถลบล้างสมมติฐานได้มากเท่าไหร่ เราก็จะยิ่งค้นหาและแก้ไขปัญหาได้เร็วขึ้น เพิ่มความยืดหยุ่น (Resilience) ความคล่องตัว (Agility) และความสามารถในการเรียนรู้และสร้างนวัตกรรมของเรา

เราทำสิ่งนี้โดยการสร้าง Feedback และ Feedforward Loops เข้าไปในระบบการทำงานของเรา Dr. Peter Senge ในหนังสือของเขา The Fifth Discipline: The Art & Practice of the Learning Organization (วินัยที่ห้า: ศิลปะและแนวปฏิบัติขององค์กรแห่งการเรียนรู้) อธิบายว่า Feedback Loops เป็นส่วนสำคัญขององค์กรแห่งการเรียนรู้ (Learning Organization) และการคิดเชิงระบบ (Systems Thinking) 5 Feedback และ Feedforward Loops ทําให้ Effects ภายในระบบเสริมกำลังหรือหักล้างซึ่งกันและกัน

ในอุตสาหกรรมการผลิต การขาด Feedback ที่มีประสิทธิภาพมักนําไปสู่ปัญหาด้านคุณภาพและความปลอดภัยที่ร้ายแรง ในกรณีที่มีการบันทึกไว้อย่างดีที่โรงงานผลิตของ General Motors ใน Fremont ไม่มีขั้นตอนการทํางานที่มีประสิทธิภาพในการตรวจจับปัญหาระหว่างกระบวนการประกอบ และไม่มีขั้นตอนที่ชัดเจนว่าจะทําอย่างไรเมื่อพบปัญหา ผลที่ได้คือมีกรณีที่เครื่องยนต์ถูกใส่กลับด้าน รถที่ไม่มีพวงมาลัยหรือยาง และแม้กระทั่งรถที่ต้องถูกลากออกจากสายการประกอบเพราะสตาร์ทไม่ติด 6

ในทางตรงกันข้าม ในโรงงานผลิตที่มีประสิทธิภาพสูง จะมีการไหลของข้อมูลที่รวดเร็ว บ่อยครั้ง และมีคุณภาพสูงทั่วทั้ง Value Stream — ทุกขั้นตอนการทํางานถูกวัดและตรวจสอบ และข้อบกพร่องหรือการเบี่ยงเบนที่มีนัยสําคัญจะถูกค้นพบและดําเนินการแก้ไขอย่างรวดเร็วโดยผู้ที่ทํางานนั้น นี่คือรากฐานที่ทําให้เกิดคุณภาพ ความปลอดภัย และการเรียนรู้และการปรับปรุงอย่างต่อเนื่อง

ใน Technology Value Stream เรามักจะได้ผลลัพธ์ที่แย่เพราะการขาด Feedback ที่รวดเร็ว ตัวอย่างเช่น ในโครงการซอฟต์แวร์แบบ Waterfall เราอาจพัฒนาโค้ดทั้งปีและไม่ได้รับ Feedback เกี่ยวกับคุณภาพจนกว่าเราจะเริ่ม Phase การทดสอบ หรือแย่กว่านั้น คือเมื่อเราปล่อยซอฟต์แวร์ให้ลูกค้า เมื่อ Feedback ล่าช้าและไม่บ่อยขนาดนี้ มันช้าเกินไปที่จะช่วยให้เราป้องกันผลลัพธ์ที่ไม่พึงประสงค์ได้

ในทางตรงกันข้าม เป้าหมายของเราคือการสร้าง Fast Feedback และ Feedforward Loops ในทุกจุดที่มีการทํางาน ทุกขั้นตอนของ Technology Value Stream ครอบคลุมทั้ง Product Management, Development, QA, Infosec และ Operations ซึ่งรวมถึงการสร้างกระบวนการ Build, Integration และ Test แบบอัตโนมัติ เพื่อให้เราสามารถตรวจพบได้ทันทีเมื่อมีการเปลี่ยนแปลงที่ทําให้ระบบออกจากสถานะที่ทํางานได้อย่างถูกต้องและสามารถ Deploy ได้

เรายังสร้าง Telemetry ที่ครอบคลุมทั่วถึง เพื่อให้เรามองเห็นว่า Component ต่างๆ ของระบบทํางานอย่างไรในสภาพแวดล้อม Testing และ Production และสามารถตรวจพบได้อย่างรวดเร็วเมื่อมันทํางานไม่เป็นไปตามที่คาดหวัง Telemetry ยังช่วยให้เราวัดได้ว่าเรากําลังบรรลุเป้าหมายที่ตั้งไว้หรือไม่ และตามอุดมคติแล้ว ข้อมูลนี้ควรถูกกระจาย (Radiated) ไปทั่วทั้ง Value Stream เพื่อให้เราเห็นว่าการกระทําของเราส่งผลต่อส่วนอื่นๆ ของระบบโดยรวมอย่างไร

Feedback Loops ไม่เพียงแต่ทําให้สามารถตรวจจับและกู้คืนปัญหาได้อย่างรวดเร็ว แต่ยังช่วยบอกเราถึงวิธีป้องกันปัญหาเหล่านี้ไม่ให้เกิดขึ้นอีกในอนาคต การทําเช่นนี้ช่วยเพิ่มคุณภาพและความปลอดภัยของระบบการทํางานของเรา และสร้างการเรียนรู้ขององค์กร (Organizational Learning)

Elisabeth Hendrickson รองประธานฝ่ายวิศวกรรมของ Pivotal Software, Inc. และผู้แต่งหนังสือ Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing กล่าวว่า "เมื่อฉันนําทีม Quality Engineering ฉันบรรยายงานของฉันว่า 'การสร้าง Feedback Cycles' Feedback มีความสําคัญเพราะมันคือสิ่งที่ทําให้เราสามารถนําทาง (Steer) ได้ เราต้องตรวจสอบความสอดคล้อง (Validate) ระหว่างความต้องการของลูกค้า ความตั้งใจของเรา และการ Implement ของเราอย่างสม่ําเสมอ Testing เป็นเพียง Feedback รูปแบบหนึ่งเท่านั้น" 7

Continuous Learning (การเรียนรูอย่างต่อเนื่อง)

Feedback Types and Cycle Times (ประเภทของ Feedback และ Cycle Times)

ตามที่ Elisabeth Hendrickson กล่าวในการนําเสนอ DevOps Enterprise Summit ปี 2015 มี Feedback อยู่หกประเภทในการพัฒนาซอฟต์แวร์: 8

• Dev Tests: ในฐานะ Programmer ฉันเขียนโค้ดที่ตั้งใจจะเขียนหรือไม่?

• Continuous Integration (CI) and Testing : ในฐานะ Programmer ฉันเขียนโค้ดที่ตั้งใจจะเขียนโดยไม่ละเมิด Expectations ที่มีอยู่ในโค้ดเดิมหรือไม่?

• Exploratory Testing: เราสร้างผลกระทบที่ไม่ตั้งใจ (Unintended Consequences) หรือไม่?

• Acceptance Testing: ฉันได้รับ Feature ที่ขอไว้หรือไม่?

• Stakeholder Feedback: ในฐานะทีม เรากําลังไปในทิศทางที่ถูกต้องหรือไม่?

• User Feedback: เรากําลังผลิตสิ่งที่ลูกค้าหรือผู้ใช้ของเราชอบหรือไม่?

และ Feedback แต่ละประเภทใช้เวลาแตกต่างกัน ลองนึกภาพเป็นวงกลมซ้อนกันหลายชั้น วงที่เร็วที่สุดอยู่ที่สถานีทํางานของ Developer (Local Tests, Test-Driven Development ฯลฯ) และวงที่ยาวที่สุดคือ Customer หรือ User Feedback ที่ปลายสุดของ Cycle (ดังที่เห็นใน รูปที่ 3.1 )

Figure 3.1: Feedback Cycle Times (Cycle Times ของ Feedback)

ที่มา: Hendrickson, Elisabeth. "DOES15—Elisabeth Hendrickson—Its All About Feedback." Posted by DevOps Enterprise Summit, November 5, 2015. YouTube video, 34:47. https://www.youtube.com/watch?v=r2BFTXBundQ .

Swarm and Solve Problems to Build New Knowledge (Swarm และแก้ปัญหาเพื่อสร้างความรู้ใหม่)

แน่นอนว่าแค่ตรวจจับเมื่อมีสิ่งไม่คาดคิดเกิดขึ้นนั้นไม่เพียงพอ เมื่อปัญหาเกิดขึ้น เราต้อง Swarm ปัญหาเหล่านั้น โดยรวบรวมทุกคนที่จําเป็นเพื่อแก้ไขปัญหา

ตามที่ Dr. Spear กล่าว เป้าหมายของ Swarming คือการควบคุมปัญหา (Contain) ก่อนที่มันจะแพร่กระจาย และวินิจฉัยและรักษาปัญหาเพื่อไม่ให้เกิดขึ้นซ้ำ "ในการทําเช่นนี้" เขากล่าว "พวกเขาสร้างความรู้ที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับวิธีการจัดการระบบสําหรับการทํางานของเรา เปลี่ยนความไม่รู้ (Ignorance) ที่หลีกเลี่ยงไม่ได้ในช่วงแรกให้กลายเป็นความรู้" 9

ตัวอย่างที่ดีที่สุดของหลักการนี้คือ Toyota Andon cord ในโรงงานผลิตของ Toyota เหนือทุกสถานีงานจะมีเชือก (Cord) ที่พนักงานและผู้จัดการทุกคนได้รับการฝึกให้ดึงเมื่อมีสิ่งผิดปกติเกิดขึ้น เช่น ชิ้นส่วนมีตําหนิ ชิ้นส่วนที่ต้องการไม่มี หรือแม้กระทั่งเมื่องานใช้เวลานานกว่าที่บันทึกไว้ †

เมื่อ Andon cord ถูกดึง หัวหน้าทีมจะได้รับแจ้งและทํางานเพื่อแก้ไขปัญหาทันที หากปัญหาไม่สามารถแก้ไขได้ภายในเวลาที่กําหนด (เช่น ห้าสิบห้าวินาที) สายการผลิตจะหยุดลง เพื่อให้ทั้งองค์กรสามารถระดมกําลังช่วยกันแก้ไขปัญหาจนกว่าจะมีการพัฒนา Countermeasure ที่สําเร็จ

แทนที่จะทํางานรอบปัญหา (Work Around) หรือนัดหมายแก้ไข "เมื่อเรามีเวลามากขึ้น" เราจะ Swarm เพื่อแก้ไขทันที ซึ่งเกือบจะตรงกันข้ามกับพฤติกรรมที่โรงงาน GM Fremont ที่อธิบายไว้ก่อนหน้านี้

Swarming จําเป็นด้วยเหตุผลดังต่อไปนี้:

• ป้องกันไม่ให้ปัญหาเคลื่อนไปยังขั้นตอนถัดไป (Downstream) ซึ่งต้นทุนและความพยายามในการซ่อมแซมจะเพิ่มขึ้นแบบ Exponential และ Technical Debt จะสะสมเพิ่มขึ้น

• ป้องกันไม่ให้สถานีงานเริ่มงานใหม่ ซึ่งมีแนวโน้มที่จะนําข้อผิดพลาดใหม่เข้าสู่ระบบ

• หากปัญหาไม่ได้รับการแก้ไข สถานีงานอาจเจอปัญหาเดิมซ้ำในการดําเนินงานครั้งถัดไป (เช่น ห้าสิบห้าวินาทีต่อมา) ซึ่งต้องใช้การแก้ไขและงานเพิ่มเติม (ดูเพิ่มเติมที่ ภาคผนวก 6 .)

การปฏิบัติแบบ Swarming นี้ดูเหมือนจะขัดกับแนวทางการจัดการทั่วไป เพราะเราจงใจปล่อยให้ปัญหาเฉพาะจุด (Local Problem) รบกวนการดําเนินงานในระดับ Global อย่างไรก็ตาม Swarming ช่วยให้เกิดการเรียนรู้ มันป้องกันการสูญเสียข้อมูลสําคัญเนื่องจากความทรงจําที่เลือนหายหรือสถานการณ์ที่เปลี่ยนแปลงไป ซึ่งสําคัญอย่างยิ่งในระบบที่ซับซ้อน ที่ปัญหาหลายอย่างเกิดขึ้นจากปฏิสัมพันธ์ที่ไม่คาดคิดและเฉพาะตัว (Idiosyncratic) ระหว่างคน กระบวนการ ผลิตภัณฑ์ สถานที่ และสถานการณ์ต่างๆ — เมื่อเวลาผ่านไป มันเป็นไปไม่ได้ที่จะสร้างสถานการณ์ตอนที่เกิดปัญหาขึ้นมาใหม่ได้อย่างถูกต้อง

ตามที่ Dr. Spear กล่าว Swarming เป็นส่วนหนึ่งของ "วงจรที่มีวินัยของการรับรู้ปัญหา การวินิจฉัย . . . และการรักษา (Countermeasures หรือ Corrective Measures ในภาษาของการผลิต) ซึ่งคือวินัยของ Shewhart Cycle—Plan, Do, Check, Act—ที่ถูกทําให้เป็นที่นิยมโดย Dr. W. Edwards Deming แต่เร่งความเร็วจนถึงระดับ Warp Speed" 10

มีเพียงการ Swarm ปัญหาที่เล็กลงเรื่อยๆ ซึ่งถูกค้นพบเร็วขึ้นเรื่อยๆ ใน Life Cycle เท่านั้น ที่เราจะสามารถเบี่ยงเบนปัญหาก่อนที่หายนะจะเกิดขึ้น กล่าวอีกนัยหนึ่ง เมื่อเครื่องปฏิกรณ์นิวเคลียร์หลอมละลาย มันสายเกินไปที่จะหลีกเลี่ยงผลลัพธ์ที่เลวร้ายที่สุด

เพื่อให้เกิด Fast Feedback ใน Technology Value Stream เราต้องสร้างสิ่งที่เทียบเท่ากับ Andon cord และการตอบสนองแบบ Swarming ที่เกี่ยวข้อง ซึ่งต้องสร้างวัฒนธรรมที่ทําให้การดึง Andon cord เป็นเรื่องปลอดภัย และแม้กระทั่งได้รับการสนับสนุน เมื่อมีสิ่งผิดปกติเกิดขึ้น ไม่ว่าจะเป็นเมื่อเกิด Incident ใน Production หรือเมื่อเกิดข้อผิดพลาดก่อนหน้านั้นใน Value Stream เช่น เมื่อมีใครสักคนนําการเปลี่ยนแปลงที่ทําให้ Continuous Build หรือ Test Process ของเราเสีย

เมื่อเงื่อนไขกระตุ้นให้เกิดการดึง Andon cord เราจะ Swarm เพื่อแก้ไขปัญหาและป้องกันไม่ให้มีการเริ่มงานใหม่จนกว่าปัญหาจะได้รับการแก้ไข ‡ สิ่งนี้ช่วยให้ Feedback ที่รวดเร็วแก่ทุกคนใน Value Stream (โดยเฉพาะบุคคลที่ทําให้ระบบล้มเหลว) ทําให้เราสามารถแยกและวินิจฉัยปัญหาได้อย่างรวดเร็ว และป้องกันปัจจัยที่ซับซ้อนเพิ่มเติมที่อาจบดบัง Cause และ Effect

การป้องกันการเริ่มงานใหม่ช่วยให้เกิด Continuous Integration และ Deployment ซึ่งก็คือ "Single-Piece Flow" ใน Technology Value Stream การเปลี่ยนแปลงทั้งหมดที่ผ่าน Continuous Build และ Integration Tests ของเราจะถูก Deploy ไปยัง Production และการเปลี่ยนแปลงใดๆ ที่ทําให้ Test ใดๆ ล้มเหลวจะเป็นการดึง Andon Cord ของเราและถูก Swarm จนกว่าจะแก้ไขเสร็จ

CASE STUDY: NEW TO SECOND EDITION (กรณีศึกษา: ใหม่ในฉบับพิมพ์ครั้งที่สอง)

Pulling the Andon Cord at Excella (2018) (การดึง Andon Cord ที่ Excella)

Excella เป็นบริษัทที่ปรึกษาด้าน IT ในงาน DevOps Enterprise Summit ปี 2019 Zack Ayers, Scrum Master และ Joshua Cohen, Sr. Developer ได้พูดถึงการทดลองใช้ Andon cord เพื่อลด Cycle Time, ปรับปรุงการทํางานร่วมกัน และสร้างวัฒนธรรมที่มี Psychological Safety สูงขึ้น 11

Excella สังเกตเห็นในช่วง Team Retrospective ว่า Cycle Times ของพวกเขาเริ่มสูงขึ้น พวกเขามีสิ่งที่ Joshua Cohen อธิบายว่าเป็นกรณีของ "Almost Dones" เขากล่าวว่า "ระหว่าง Standup Developers ของเราจะอัปเดตเกี่ยวกับ Feature ที่พวกเขากําลังทําเมื่อวันก่อน พวกเขาจะพูดว่า 'เฮ้ ฉันไปได้ไกลมาก ฉันเกือบเสร็จแล้ว' และเช้าวันรุ่งขึ้นพวกเขาจะพูดว่า 'เฮ้ ฉันเจอปัญหาบ้างแต่ก็ผ่านมาได้ มีแค่ Tests สองสามอันที่ต้องรัน ฉันเกือบเสร็จแล้ว'" 12

กรณีของ "Almost Dones" นี้เกิดขึ้นบ่อยเกินไป ทีมตัดสินใจว่านี่คือจุดที่พวกเขาต้องการปรับปรุง พวกเขาสังเกตว่าสมาชิกในทีมจะนําปัญหาขึ้นมาพูดก็ต่อเมื่อถึงเวลาที่กําหนดเท่านั้น เช่น ระหว่าง Standup พวกเขาต้องการให้ทีมเปลี่ยนวิธีปฏิบัติเพื่อร่วมมือกันทันทีที่ระบุปัญหาได้ แทนที่จะรอจนถึง Standup หรือ Meeting ในวันถัดไป

ทีมตัดสินใจทดลองใช้แนวคิดของ Andon cord พวกเขามีพารามิเตอร์สําคัญสองข้อ: (1) เมื่อ Cord ถูก "ดึง" ทุกคนจะหยุดงานเพื่อหาแนวทางในการแก้ไขปัญหา (2) Cord จะถูกดึงเมื่อใดก็ตามที่มีคนในทีมรู้สึกติดขัดหรือต้องการความช่วยเหลือจากทีม

แทนที่จะใช้เชือกหรือ Cord จริงๆ ทีมสร้าง Bot ใน Slack เพื่อใช้เป็น Andon cord เชิงอุปมา เมื่อมีคนพิมพ์ andon ใน Slack Bot จะ @here ทีมเพื่อแจ้งทุกคนใน Slack แต่พวกเขาไม่ได้หยุดแค่นั้น พวกเขายังสร้าง "if/this/then/that" Integration ใน Slack ที่จะเปิดไฟสีแดงหมุน ไฟประดับ และแม้กระทั่งหุ่น "tube" เต้นรําในออฟฟิศ

เพื่อวัดผลการทดลอง Andon cord ทีมตัดสินใจมุ่งเน้นที่การลด Cycle Time เป็น Metric หลักของความสําเร็จ รวมถึงการเพิ่ม Collaboration ของทีม ' และกําจัด "Almost Dones" โดยการพูดถึงปัญหาเมื่อมันเกิดขึ้น

ในช่วงเริ่มต้นของการทดลองในปี 2018 Cycle Time ของพวกเขาอยู่ที่ประมาณสามวัน In Progress ตลอดหลายสัปดาห์ต่อมา เมื่อ Andon cord เริ่มถูกดึง พวกเขาเห็น Cycle Time ลดลงเล็กน้อย สองสามสัปดาห์ต่อมา พวกเขาหยุดดึง Andon cord และเห็น Cycle Time พุ่งสูงขึ้นเกือบสิบเอ็ดวัน ซึ่งเป็นสถิติสูงสุดตลอดกาล 13

พวกเขาประเมินสิ่งที่เกิดขึ้นกับการทดลอง พบว่าแม้การดึง Cord จะสนุก แต่พวกเขาก็ดึงมันไม่บ่อยพอเพราะคนกลัวที่จะขอความช่วยเหลือและไม่ต้องการรบกวนเพื่อนร่วมทีม

เพื่อแก้ปัญหานี้ พวกเขาเปลี่ยนนิยามว่าควรดึง Andon cord เมื่อใด จากเดิมที่ดึงเมื่อสมาชิกติดขัด พวกเขาจะดึง Cord เมื่อต้องการ ความคิดเห็นของทีม (Opinion of the Team)

ด้วยการเปลี่ยนแปลงนี้ พวกเขาเห็นจํานวนการดึง Andon cord เพิ่มขึ้นอย่างมาก และ Cycle Time ลดลงตามลําดับ

ทุกครั้งที่ทีมเห็นว่าการ Andon cord pulls ลดลง พวกเขาหาวิธีใหม่ๆ เพื่อกระตุ้นให้เกิดการดึง และทุกครั้งที่พวกเขาเห็น Cycle Time ลดลงเมื่อมีการดึงเพิ่มขึ้น ทีมยังคง Iterate อย่างต่อเนื่อง และในที่สุดก็ย้าย Andon cord experiment ไปเป็นแนวปฏิบัติ (Practice) และขยายไปทั่ว Product โดยใช้ "Andon: Code Red" เพื่อรายงานปัญหาสําคัญ

Figure 3.2: Cycle Time vs. Andon Pulls at Excella (Cycle Time เทียบกับ Andon Pulls ที่ Excella)

ที่มา: Zach Ayers and Joshua Cohen. "Andon Cords in Development Teams—Driving Continuous Learning," presentation at the DevOps Enterprise Summit Las Vegas, 2019. https://videolibrary.doesvirtual.com/?video=504281981 .

นอกจาก Cycle Time แล้ว พวกเขายังพบว่า Andon cord ส่งเสริม Psychological Safety สมาชิกในทีมกล้าพูดมากขึ้นและเสนอแนวทางแก้ไขที่สร้างสรรค์มากขึ้น

Jeff Gallimore, Chief Technology and Innovation Officer และ Cofounder ของ Excella อธิบายว่า:

หนึ่งในบทเรียนที่ขัดกับสามัญสํานึก (Counterintuitive) จากการทดลองนี้คือ มันท้าทายความเชื่อทั่วไปที่ว่า โดยเฉพาะสําหรับ Developers และ Engineers คุณไม่ควร ' ขัดจังหวะ Flow เพราะมันทําลาย Productiviy ของแต่ละบุคคล แต่นั่น ' คือสิ่งที่ Andon cord ทํา เพื่อประโยชน์ของ Team Flow และ Productivity 14

กรณีศึกษานี้แสดงให้เห็นถึงประสิทธิภาพที่น่าทึ่งของการ Swarming เพื่อแก้ไขปัญหาก่อนที่ปัญหาเฉพาะจุดจะกลายเป็นปัญหาระดับ Global และการบูรณาการระบบ Andon cord อย่างสร้างสรรค์ช่วยลด Cycle Time และปรับปรุง Collaboration ได้อย่างไร

Keep Pushing Quality Closer to the Source (ผลักดันคุณภาพให้ใกล้กับแหล่งกําเนิดมากขึ้น)

เราอาจทําให้ระบบการทํางานที่ไม่ปลอดภัยคงอยู่ต่อไปโดยไม่ตั้งใจ เนื่องจากการตอบสนองต่ออุบัติเหตุและเหตุการณ์ต่างๆ ของเรา ในระบบที่ซับซ้อน การเพิ่มขั้นตอน Inspection และ Approval Processes เข้าไปอีก จริงๆ แล้วเพิ่มโอกาสของความล้มเหลวในอนาคต ประสิทธิภาพของ Approval Processes ลดลงเมื่อเราโยกย้ายการตัดสินใจออกไปไกลจากจุดที่ทํางาน การทําเช่นนี้ไม่เพียงลดคุณภาพของการตัดสินใจ แต่ยังเพิ่ม Cycle Time ของเรา ทําให้ความแข็งแกร่งของ Feedback ระหว่าง Cause และ Effect ลดลง และลดความสามารถของเราในการเรียนรู้จากความสําเร็จและความล้มเหลว §

สิ่งนี้สามารถเห็นได้แม้ในระบบที่เล็กกว่าและซับซ้อนน้อยกว่า เมื่อระบบแบบ Top-Down, Bureaucratic, Command-and-Control ไร้ประสิทธิภาพ มักเป็นเพราะความแตกต่าง (Variance) ระหว่าง "ใครควรทําอะไร" กับ "ใครกําลังทําอะไรจริงๆ" นั้นมากเกินไป เนื่องจากขาดความชัดเจนและความทันท่วงที

ตัวอย่างของ Quality Controls ที่ไม่มีประสิทธิภาพ ตาม Lean Enterprise ได้แก่: 16

• การให้ทีมอื่นมาทํางานที่ Tedious, Error-Prone และ Manual ซึ่งสามารถทํา Automation ได้ง่ายและให้ทีมที่ต้องการทํางานนั้นรันได้ตามต้องการ

• การขออนุมัติจากคนที่ยุ่งและอยู่ห่างไกลจากงาน ทําให้พวกเขาต้องตัดสินใจโดยไม่มีความรู้ที่เพียงพอเกี่ยวกับงานหรือผลกระทบที่อาจเกิดขึ้น หรือเพียงแค่ประทับตราอนุมัติ (Rubber Stamp)

• การสร้างเอกสารปริมาณมากที่มีรายละเอียดน่าสงสัย ซึ่งล้าสมัยไม่นานหลังจากเขียนเสร็จ

• การส่งงานเป็น Batch ขนาดใหญ่ให้ทีมและคณะกรรมการพิเศษเพื่ออนุมัติและดําเนินการ แล้วรอการตอบกลับ

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

เราใช้ Peer Reviews สําหรับการเปลี่ยนแปลงที่เสนอ เพื่อให้ได้รับความมั่นใจว่าการเปลี่ยนแปลงของเราจะทํางานตามที่ออกแบบไว้ เราทํา Automation การตรวจสอบคุณภาพเท่าที่ทําได้ ซึ่งโดยทั่วไปแล้วแผนก QA หรือ Information Security เป็นผู้ดําเนินการ แทนที่ Developers จะต้องขอหรือนัดหมายให้ทําการทดสอบ การทดสอบเหล่านี้สามารถทําได้ On Demand ทําให้ Developers สามารถทดสอบโค้ดของตัวเองได้อย่างรวดเร็ว และแม้กระทั่ง Deploy การเปลี่ยนแปลงเหล่านั้นไปยัง Production ด้วยตนเอง

การทําเช่นนี้ทําให้คุณภาพเป็นความรับผิดชอบของทุกคนอย่างแท้จริง แทนที่จะเป็นความรับผิดชอบแต่เพียงผู้เดียวของแผนกใดแผนกหนึ่ง ความปลอดภัยของข้อมูล (Information Security) ไม่ใช่แค่งานของแผนก Information Security เช่นเดียวกับ Availability ที่ไม่ใช่แค่งานของ Operations เท่านั้น

การให้ Developers แบ่งปันความรับผิดชอบต่อคุณภาพของระบบที่พวกเขาสร้าง ไม่เพียงปรับปรุงผลลัพธ์ แต่ยังเร่งการเรียนรู้ด้วย ซึ่งสําคัญอย่างยิ่งสําหรับ Developers เพราะพวกเขามักจะเป็นทีมที่อยู่ห่างไกลจากลูกค้ามากที่สุด ดังที่ Gary Gruver กล่าว "มันเป็นไปไม่ได้ที่ Developer จะเรียนรู้อะไรได้เมื่อมีคนตะคอกใส่พวกเขาเรื่องสิ่งที่พวกเขาทําพังเมื่อหกเดือนก่อน — นั่นคือเหตุผลที่เราต้องให้ Feedback แก่ทุกคนให้เร็วที่สุดเท่าที่จะทําได้ เป็นนาที ไม่ใช่เป็นเดือน" 17

Enable Optimizing for Downstream Work Centers (เปิดใช้งานการปรับให้เหมาะสมสําหรับ Work Centers ปลายทาง)

ในทศวรรษ 1980 หลักการ Designing for Manufacturability พยายามออกแบบชิ้นส่วนและกระบวนการเพื่อให้สินค้าสําเร็จรูปสามารถผลิตได้ด้วยต้นทุนต่ําที่สุด คุณภาพสูงที่สุด และ Flow เร็วที่สุด ตัวอย่างเช่น การออกแบบชิ้นส่วนที่ไม่สมมาตรอย่างชัดเจนเพื่อป้องกันการประกอบกลับด้าน และการออกแบบสกรูยึดที่ไม่สามารถขันแน่นเกินไปได้

นี่เป็นการเปลี่ยนแปลงจากวิธีออกแบบทั่วไปที่มุ่งเน้นไปที่ลูกค้าภายนอก (External Customers) แต่มองข้ามผู้มีส่วนได้ส่วนเสียภายใน (Internal Stakeholders) เช่น ผู้ที่ทํางานในการผลิต

Lean กําหนดลูกค้าสองประเภทที่เราต้องออกแบบให้ ได้แก่ ลูกค้าภายนอก (External Customer) ซึ่งมีแนวโน้มว่าจะเป็นผู้จ่ายค่าบริการที่เราส่งมอบ และลูกค้าภายใน (Internal Customer) ซึ่งรับและประมวลผลงานต่อจากเราทันที ตามหลัก Lean ลูกค้าที่สําคัญที่สุดของเราคือขั้นตอนถัดไปในสายงาน (Downstream) การปรับงานของเราให้เหมาะสมสําหรับพวกเขาต้องการให้เราเห็นอกเห็นใจ (Empathy) ต่อปัญหาของพวกเขา เพื่อที่จะระบุปัญหาในการออกแบบที่ขัดขวาง Flow ที่รวดเร็วและราบรื่น

ใน Technology Value Stream เราปรับให้เหมาะสมสําหรับ Downstream Work Centers โดยการออกแบบเพื่อการดําเนินงาน (Designing for Operations) ซึ่ง Non-Functional Requirements ด้านการดําเนินงาน (เช่น สถาปัตยกรรม, Performance, Stability, Testability, Configurability และ Security) จะได้รับลําดับความสําคัญสูงเทียบเท่ากับ User Features

การทําเช่นนี้ทําให้เราสร้างคุณภาพตั้งแต่ต้นทาง (Quality at the Source) ส่งผลให้เกิดชุดของ Non-Functional Requirements ที่เป็นลายลักษณ์อักษร ซึ่งเราสามารถบูรณาการในเชิงรุกเข้ากับทุก Service ที่เราสร้างขึ้น

Conclusion (บทสรุป)

การสร้าง Fast Feedback เป็นสิ่งสําคัญต่อการบรรลุคุณภาพ ความน่าเชื่อถือ และความปลอดภัยใน Technology Value Stream เราทําสิ่งนี้โดยการมองเห็นปัญหาเมื่อมันเกิดขึ้น การ Swarm และแก้ปัญหาเพื่อสร้างความรู้ใหม่ การผลักดันคุณภาพให้ใกล้กับแหล่งกําเนิดมากขึ้น และการปรับให้เหมาะสมสําหรับ Downstream Work Centers อย่างต่อเนื่อง

แนวปฏิบัติเฉพาะที่ทําให้เกิด Fast Flow ใน DevOps Value Stream มีอยู่ใน ส่วนที่ IV ของหนังสือเล่มนี้ ในบทถัดไป เราจะนําเสนอ Third Way ซึ่งเป็นหลักการของการเรียนรู้อย่างต่อเนื่องและการทดลอง (The Principles of Continual Learning and Experimentation)