การวิเคราะห์สาเหตุของปัญหา: 4 เคล็ดลับในการแก้ไขปัญหาข้อบกพร่องได้เร็วขึ้น

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

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

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

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

แล้วเราจะหาปัญหาให้เร็วแล้วแก้ปัญหาให้ฉับไวได้อย่างไรกันล่ะ

การวิเคราะห์สาเหตุของปัญหา: คืออะไรและทำไมคุณต้องให้ความสนใจ

การวิเคราะห์สาเหตุของปัญหา (RCA) คือเทคนิคพิเศษที่คุณนำไปใช้เพื่อแก้ไขปัญหาโดยเฉพาะ เทคนิคนี้ช่วยให้คุณสามารถวิเคราะห์ปัญหาที่พบเจอได้โดยใช้ขั้นตอนที่กำหนดมาโดยเฉพาะต่างๆ เพื่อค้นหาสาเหตุหลักของปัญหา RCA ยึดหลักการว่า การสนใจแต่ปลายเหตุโดยเพิกเฉยต่อสาเหตุของปัญหานั้นไม่มีประโยชน์

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

เมื่อรู้ "ปัญหา" และ "สาเหตุ" แล้ว ก็ควรรู้ 4 เคล็ดลับที่จะช่วยให้การใช้ RCA มีปัญหาน้อยลง

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

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

แนวทางเป็ดยางเพียงพอต่อการแก้ไขปัญหาหรือไม่ ไม่ใช่อยู่แล้ว ก็อาจจะเพียงพอ แต่แนวทางนี้มักเป็นแค่ขั้นแรกในบันไดที่มีอีกหลายขั้นนัก

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

คุณสามารถใช้แนวทางต่อไปนี้ได้
1. เขียนคำถามใน Stack Overflow หรือแกล้งทำเป็นว่าคุณกำลังเขียนคำถามใน Stack Overflow แต่จริงๆ แล้วเขียนใน Notepad ก็ได้
2. บันทึกรายงานข้อบกพร่องโดยละเอียดเอาไว้ ยังไงก็ต้องมีใครสักคนทำอยู่ดี ยิงปืนนัดเดียวได้นกสองตัวก็ย่อมดีกว่าใช่ไหมล่ะ
3. ไปที่ห้องของเพื่อนร่วมงาน แล้วพูดคุยกันสักครู่หนึ่ง ง่ายๆ แค่นั้นเลย แต่เพื่อนร่วมงานต้องโอเคด้วยนะ อย่ารบกวนเพื่อนร่วมงานโดยไม่จำเป็นล่ะ


รวบรวมข้อมูลบันทึกจำนวนมาก (และค้นหาข้อมูลอย่างมีประสิทธิภาพ)

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

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

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

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


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

โดยถามว่า "เพราะเหตุใด" ซ้ำๆ จนคุณพบเจอสาเหตุของปัญหา ลองดูตัวอย่างคร่าวๆ กัน

ปัญหา: เว็บไซต์แสดงรหัสข้อผิดพลาด 500
1. เพราะเหตุใด เพราะองค์ประกอบการกำหนดเส้นทางของเฟรมเวิร์กเว็บไซต์ทำงานผิดพลาด
2. เพราะเหตุใด เพราะองค์ประกอบดังกล่าวต้องใช้อีกองค์ประกอบร่วมด้วย ซึ่งก็ทำงานผิดพลาดเช่นกัน
3. เพราะเหตุใด เพราะองค์ประกอบของเฟรมเวิร์กเว็บไซต์นี้ต้องใช้ส่วนขยาย intl ซึ่งไม่ทำงาน
4 เพราะเหตุใด เพราะส่วนขยายนี้ถูกปิดโดยไม่ได้ตั้งใจหลังจากอัปเดตซอฟต์แวร์เซิร์ฟเวอร์

อย่างที่คุณเห็น ข้อ 5 เป็นเพียงภาพประกอบ เพราะเราอาจจะเจอสาเหตุของปัญหาได้เร็วกว่านั้น หรือบางทีคุณก็อาจต้องถามเพิ่ม

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


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

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

ศาสตร์หรือศิลป์

การแก้ไขข้อบกพร่องคือกระบวนการที่ค่อนข้างไปทางศิลป์มากกว่าศาสตร์ แต่นั่นก็ไม่ใช่เหตุผลที่คุณไม่ควรใช้เทคนิคต่างและเครื่องมือต่างๆ เพื่อให้มีประสิทธิภาพมากขึ้น

ดังนั้นให้ใช้เทคนิคเหล่านั้นในการทำ RCA
1. ใช้แนวทางเป็ดยาง
2. รวบรวมข้อมูลจำนวนมาก และใช้เครื่องมือที่เหมาะสมในการค้นหาและวิเคราะห์ข้อมูล
3. ใช้เทคนิค 5 Why
4 ให้ผู้อื่นช่วย

ถึงเวลาหาเป็ดยาง และเริ่มวิเคราะห์สาเหตุของปัญหาแล้ว

เรียนรู้เพิ่มเติมเกี่ยวกับราคา Amazon OpenSearch Service

ไปที่หน้าราคา
พร้อมสร้างหรือยัง
เริ่มต้นใช้งาน Amazon OpenSearch Service
มีคำถามเพิ่มเติมหรือไม่
ติดต่อเรา