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