โฟกัสแค่ปัญหา 20% แล้วอีก 80% มันจะหายไป

คำว่า “Pareto Principle” มันใช้งานได้จริงเหรอ?

ในโลกของการทำงาน โดยเฉพาะสาย Software Development (หรือ IT ของเรา) เราอาจรู้สึกว่าเวลาส่วนใหญ่หมดไปกับการจัดการกับปัญหาต่าง ๆ เต็มไปหมด ซึ่งพอมองดูดี ๆ ปัญหาที่ดูเล็กน้อยเหล่านั้น มันกลับทำให้เราวุ่นวายจนหมดวันไปโดยไม่รู้ตัว

และ ถ้าเราเจออะไรแบบนี้ หนึ่งสิ่งที่เราควรศึกษานั่นก็คือ Pareto Principle หรือที่รู้จักกันในนาม “กฎ 80/20” ที่เขาบอกไว้ว่า

“80% ของผลลัพธ์มักจะเกิดจาก 20% ของสาเหตุทั้งนั้น ซึ่งถ้าเราโฟกัสที่ปัญหาแค่ 20% ที่สำคัญจริง ๆ มันอาจช่วยแก้ปัญหาอื่น ๆ ที่เหลืออีก 80% ได้โดยอัตโนมัติ”

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

ตัวอย่างง่าย ๆ ของ Pareto Principle

เอาแบบที่เห็นได้ชัดเจนคือ “การจัดการบั๊ก” นั่นเอง ซึ่งในโปรเจกต์ซอฟต์แวร์ขนาดใหญ่ เรามักพบว่าบั๊กส่วนใหญ่นั้นถูกสร้างขึ้นมาจากโค้ดเพียง 20% เท่านั้น นั่นหมายความว่าถ้าเรารู้จักโฟกัสไปที่การปรับปรุงโค้ดส่วนนั้น เราก็อาจแก้ไขปัญหาได้อย่างมหาศาลแล้ว ไม่ต้องมานั่งล่าบั๊กทีละตัวให้เสียเวลา

อีกตัวอย่างหนึ่งคือการพัฒนาฟีเจอร์ใหม่ ๆ ทีมไอทีหรือ Dev Team ที่ดีมักจะรู้ว่า 20% ของฟีเจอร์สามารถทำให้ผู้ใช้งาน 80% พึงพอใจได้ ดังนั้นการเลือกโฟกัสที่ฟีเจอร์หลัก ๆ ที่จะสร้างผลลัพธ์ได้มากกว่า ก็ทำให้เราสามารถประหยัดทรัพยากร และทำให้ระบบออกสู่ตลาดได้เร็วขึ้น ซึ่งแนวคิดตรงนี้สามารถนำไปใช้พัฒนา MVP ของ Products / Services ของเราได้ด้วย

นำ Pareto Principle มาใช้ในงานจริงได้ยังไง ?

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

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

1. ใช้ Data เพื่อระบุปัญหาที่เกิดขึ้น

การเก็บและวิเคราะห์ข้อมูลเป็นขั้นตอนแรกที่สำคัญ เราสามารถใช้ Log Analysis หรือ Monitoring Tools ต่าง ๆ เช่นพวก New Relic, Datadog หรือ Grafana มาช่วยดูภาพรวมระบบได้ โดยให้เราลองสังเกต หรือ ลองมองหา

• ช่วงเวลาที่มีปัญหาเกิดขึ้นบ่อย ลองดูว่าเมื่อไหร่ที่ระบบทำงานช้าลงบ่อย ๆ หรือเกิด Downtime บ้าง
• เมตริกที่เกี่ยวกับ Latency หา request ที่ใช้เวลาประมวลผลนานที่สุด อาจจะเริ่มจาก endpoint ที่มีปริมาณการใช้งานสูงก่อน เพราะถ้าลด Latency ตรงนี้ได้จะมีผลมาก
• ข้อมูล Error Logs หากมีข้อผิดพลาดเกิดขึ้นบ่อย เราก็สามารถดูจุดที่มีการเกิด Error ซ้ำ ๆ ได้เช่นกัน ซึ่งช่วยระบุหาโค้ดส่วนที่ต้องปรับปรุงเป็นลำดับแรก ๆ
• หรือ ดูจาก Feedback / Inbox ทาง Social Media ก็ได้ ซึ่งตรงนี้ Dev / IT ส่วนใหญ่อาจไม่ได้ดูโดยตรง ซึ่งบอกเลยว่าการทำงานร่วมกันระหว่าง 2 แผนกขึ้นไปแบบนี้ก็ช่วยนำมาวิเคราะฆ์ได้เหมือนกัน

การวิเคราะห์ Log เหล่านี้จะช่วยให้เราเห็นชัดเจนว่าจุดไหนที่เป็น bottleneck และควรได้รับการแก้ไขก่อน ทำให้เราสามารถโฟกัสที่ปัญหา 20% นั้นเพื่อให้ได้ผลลัพธ์ที่ดีขึ้นทั้งระบบได้เลย

2. ลองทำ Root Cause Analysis (RCA)

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

• 5 Whys ลองถามคำถามว่า “ทำไม” 5 ครั้งกับปัญหาที่พบ จนกว่าจะได้สาเหตุจริง ๆ เช่น หากระบบมี Latency สูง ให้ถามว่า “ทำไมถึงมี Latency สูง” แล้วตอบให้ได้ว่าอะไรทำให้เกิดปัญหานั้น (เช่น อาจเกิดจาก Database Query ที่ทำงานช้าหรือการเรียกใช้ API ภายนอกที่มีการตอบสนองช้า)
• Fishbone Diagram เทคนิคนี้ช่วยให้เราเห็นสาเหตุของปัญหาจากหลายมุมมอง ไม่ว่าจะเป็นเรื่องของ Process, People, Technology หรือ Environment ซึ่งเราสามารถเห็นภาพรวมและหาได้ว่าปัญหาที่ใหญ่ที่สุดมาจากมุมไหน
• ถ้ามาในรูปแบบเชิงเทคนิค ก็จะแนะนำให้ใช้ Use Profiling Tools และ ใช้ Profilers อย่างเช่น Perf หรือ JProfiler (สำหรับ Java) หรือ Chrome DevTools สำหรับเว็บ เพื่อวิเคราะห์ว่าโค้ดส่วนไหนทำให้ประสิทธิภาพลดลงบ้าง

3. วิเคราะห์ Impact และจัดลำดับความสำคัญ

• ปัญหานี้กระทบผู้ใช้งานกี่คน ? ปัญหาที่กระทบผู้ใช้หลายคนมักจะมีความสำคัญสูงกว่าแน่ ๆ
• ปัญหานี้มันเกิดขึ้นบ่อยไหม ? ถ้าเดือนละ 1 – 2 ครั้ง ก็หมายความว่าไม่ต้องทำ ? ไม่ใช่ ! เราวัดหยาบ ๆ แบบนั้นไม่ได้ เราต้องเทียบต่อว่าเดือนละ 1 – 2 ครั้งนั้น ใช้คนเท่าไหร่ในการแก้ และ นับเป็นกี่ % ของงานทั้งหมด เช่น มีการใช้งานฟังก์ชันนี้ 10,000 ครั้ง จะเจอเคสแบบนี้สัก 1 เคส ซึ่งแต่ละเดือนเรามีการใช้ฟังก์ชันพวกนี้แค่ 5 – 6 พันครั้ง (โอกาสก็ลดลงไปอีก) และ หากการแก้นั้นเป็นงานที่ 1 – 2 นาทีก็เสร็จ และไม่ได้กระทบกับข้ออื่นมากก็ไม่เป็นไร
• ปัญหานี้ส่งผลกระทบกับ Core Functionality ไหม? หากปัญหาส่งผลต่อฟีเจอร์หลัก ๆ ของระบบ การแก้ไขปัญหานั้นจะมี Impact สูง และ ทำให้ผู้ใช้ได้รับประสบการณ์ที่ดีขึ้น
• การแก้ปัญหานี้ต้องใช้ทรัพยากรและเวลาเท่าไร ? ดูว่าปัญหานั้นใช้เวลาและทรัพยากรที่เหมาะสมหรือไม่ หากการแก้ไขใช้เวลามากเกินไป อาจจะเลื่อนปัญหานี้ไปจัดการในขั้นตอนถัดไปก็ได้ แล้วไปโฟกัสของที่ควรจะทำก่อน

การจัดลำดับนี้จะช่วยให้ทีมสามารถโฟกัสที่ปัญหา 20% ที่สำคัญที่สุด โดยที่สามารถใช้ทรัพยากรและเวลาของทีมให้เกิดประโยชน์สูงสุดได้นั่นเอง

4. ทำการแก้ไขและทดสอบผลลัพธ์

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

• การทำ A/B Testing หากเป็นการปรับปรุงที่มีผลต่อผู้ใช้โดยตรง ให้ทำ A/B Testing เพื่อดูว่าปัญหาที่แก้ไขมีผลเชิงบวก หรือ ฟีดแบ็คที่ดีกับประสบการณ์ของผู้ใช้ (UX) มากแค่ไหน
• ติดตาม Monitoring หลังการแก้ไข โดยแนะนำให้ลองหา หรือ ใช้พวก Monitoring Tools เพื่อติดตามระบบหลังจากแก้ไขปัญหาแล้วว่ามีการเปลี่ยนแปลงที่ดีขึ้นหรือไม่ ควรจะเห็นการลดลงของ Latency หรือ Error ตามเป้าหมายที่กำหนดด้วย
• และ สุดท้ายกับ Feedback Loop หากเป็นไปได้ ให้เก็บ Feedback จากผู้ใช้งานหรือทีมงานที่เกี่ยวข้องเพื่อนำมาพัฒนาปรับปรุงต่อไป

5. ปรับปรุงขั้นตอนให้เป็นระบบอัตโนมัติ (Automation)

เมื่อแก้ปัญหาและเห็นผลลัพธ์ที่ดีแล้ว ลองทำให้เป็นอัตโนมัติโดยใช้ CI/CD Pipelines หรือการตั้งค่าให้ระบบตรวจสอบ Latency อยู่เสมอ การทำงานให้เป็น Automation จะช่วยให้ทีมพัฒนามีเวลาทำงานกับปัญหาอื่น ๆ ที่สำคัญต่อไปได้นั่นเอง 📈

ส่วนฟีดแบ็ครูปแบบอื่น ๆ ก็ใช้รูปแบบ Design Thinking หรือ Framework อื่น ๆ มาจับเพื่อให้เกิด Feedback ในการพัฒนา ที่สำคัญเราควรใช้ทักษะสายไอทีของเราในการทำให้งานพวกนี้อัตโนมัติได้ด้วย ไม่ว่าจะเป็นการใช้ระบบ Ticket ในการ Tracking ปัญหาต่าง ๆ รวมถึงจบที่การวัดผลความพึงพอใจของผู้ใช้งานแบบอัตโนมัตินั่นเอง

ประโยชน์ที่ได้จากการใช้ Pareto Principle

การใช้ Pareto Principle ในงาน Software Development หรือ IT จะช่วยให้ทีมพัฒนาไม่ต้องเจอกับอาการ Burnout เพราะเราไม่ต้องพยายามทำทุกอย่างให้สมบูรณ์แบบไปซะทุกจุด

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

อย่าลืมลองนำ Pareto Principle ไปใช้กันนะครับ คิดแค่ 20% ที่สำคัญ แล้วอีก 80% จะตามมาเอง 👨‍💻👩‍💻