Blame (การตำหนิ)

เมื่อสิ่งต่างๆ ผิดพลาด เรามีวิธีจัดการมันได้หลายแบบ แน่นอนว่าในทันทีที่เกิดเหตุ จุดโฟกัสของเราคือการทำให้ทุกอย่างกลับมาใช้งานได้อีกครั้ง ซึ่งก็สมเหตุสมผล หลังจากนั้น บ่อยครั้งเกินไปที่จะตามมาด้วยการตำหนิ มีจุดยืนเริ่มต้นที่จะมองหาบางสิ่งหรือใครสักคนมาโทษ แนวคิดเรื่อง "root cause analysis" สื่อว่ามี root cause จริงๆ อยู่ มันน่าประหลาดใจที่บ่อยครั้งเราต้องการให้ root cause นั้นเป็นมนุษย์

หลายปีก่อน ตอนที่ผมทำงานอยู่ที่ออสเตรเลีย Telstra ผู้ให้บริการโทรคมนาคมรายใหญ่ (และเคยเป็นผู้ผูกขาด) เกิด outage ครั้งใหญ่ที่ส่งผลกระทบต่อทั้งบริการเสียงและโทรศัพท์ เหตุการณ์นี้เป็นปัญหามากเป็นพิเศษเพราะขอบเขตและระยะเวลาของ outage ออสเตรเลียมีชุมชนชนบทที่ห่างไกลจำนวนมาก และ outage แบบนี้มักจะร้ายแรงเป็นพิเศษ แทบจะทันทีหลังจาก outage COO ของ Telstra ได้ออกแถลงการณ์ที่ชี้ชัดว่าพวกเขารู้แน่ชัดว่าอะไรเป็นสาเหตุของปัญหา: 8

"We took that node down, unfortunately the individual that was managing that issue did not follow the correct procedure, and he reconnected the customers to the malfunctioning node, rather than transferring them to the nine other redundant nodes that he should have transferred people to," Ms. McKenzie told reporters on Tuesday afternoon.

"We apologise right across our customer base. This is an embarrassing human error."

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

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

กลับมาที่ Telstra ด้วยสาเหตุของการตำหนิที่ถูกกำหนดไว้ชัดเจนในการสอบสวนเชิงลึกที่ทำเพียงไม่กี่ชั่วโมงหลัง outage ทั่วประเทศ เราคงคาดหวังได้ว่าจะไม่มี outage ตามมาอีก ใช่ไหม? แต่น่าเสียดายที่ Telstra ประสบกับ outage ต่อเนื่องอีกหลายครั้ง ความผิดพลาดของมนุษย์อีกครั้งหรือ? บางที Telstra อาจคิดแบบนั้น—หลังจากเหตุการณ์ต่อเนื่องหลายครั้ง COO ก็ลาออก

สำหรับมุมมองที่มีข้อมูลมากกว่าเกี่ยวกับวิธีสร้างองค์กรที่คุณสามารถได้สิ่งที่ดีที่สุดจากความผิดพลาด และสร้างสภาพแวดล้อมที่ดีกว่าสำหรับพนักงานของคุณด้วย บทความ "Blameless Post-Mortems and a Just Culture" ของ John Allspaw เป็นจุดเริ่มต้นที่ดีมาก 10

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