80/20

80% of The Effects Come From 20% of The Causes.

เมื่อปีค.ศ. 1906 นักเศรษฐศาสตร์ชาวอิตาเลียนชื่อ วิลเฟรโด พาเรตโต (Vilfredo Pareto) ได้ทำการสังเกตดูความเป็นไปทางเศรษฐศาสตร์ในประเทศบ้านเกิดตัวเองแล้วก็เห็นว่า “ที่ดิน 80 % ของประเทศถูกครอบครองโดยคน 20 % ของประชากร” เมื่อมีข้อสงสัย ข้อสมมุติฐานก็ตามมา แล้ววิลเฟรโดก็ได้เริ่มทำการทดลองโดยอาศัยฝักถั่วในไร่ของเค้าเอง!!! (โห คิดไปได้นะคนเรา) จนสุดท้ายก็ได้ข้อสรุปออกมาเป็นกฎ Pareto หรือกฎ 80–20 ว่า “ในหลายๆเหตุการณ์ โดยประมาณแล้ว 80% ของผลลัพท์เกิดจาก 20% ของสาเหตุ”

กฎข้อนี้เป็นที่แพร่หลายมากในวงการธุรกิจรวมถึงเรื่องที่เกี่ยวข้องกับ Product และ Project Management ด้วย (ต้องขอบคุณคุณวิลเฟรโด) รายงานทางสถิติจาก Standish Group เกี่ยวกับการใช้งานซอฟต์แวร์บอกว่าประมาณ 80% ของ ฟีเจอร์ต่างๆที่มีอยู่นั้นไม่เคยหรือแทบไม่เคยถูกใช้งานเลย ที่น่าสนใจไปกว่านั้นมีเพียง 20% ของฟีเจอร์เท่านั้นแหละครับที่ถูกใช้บ่อยๆ

หลักฐานชิ้นที่สองเกี่ยวข้องโดยตรงกับตัวผมเองครับ บทความนี้กำลังจะเป็นบทความที่ 246 ของผมที่เขียนใน Medium.com ผมพิมพ์ตัวอักษรไปหลายหมื่นตัวอักษรแล้ว (ไม่ต้องรวมตอนเรียนกับทำงานด้วย) แต่ผมมั่นใจเลยว่าผมใช้งานฟีเจอร์ของ Microsoft Word ไม่ถึง 20% ด้วยซ้ำ นี่ก็สอดคล้องกับผลการสำรวจโดย Microsoft เองว่ามีเพียง 8% ของฟีเจอร์ใน Microsoft Word ที่ถูกใช้บ่อยๆ หรือล่าสุดเลยคือ Microsoft ทำการสอบถามผู้ใช้ว่าอยากได้อะไรเพิ่มใน Microsoft Word เวอร์ชั่นใหม่ … มากกว่า 90% อยากได้สิ่งที่มีอยู่แล้วในเวอร์ชั่นปัจจุบัน (เหตุการณ์แบบนี้เรียกว่า Discoverability Problem — ปัญหาในการค้นหาและเข้าถึงฟีเจอร์ต่างๆในโปรดักส์) … หนักกว่าอีกนะเนี่ยะ

สองเหตุการณ์นี้มีนัยอะไรในมุมของ Product และ Project Management ครับ? สำหรับผมแล้วมันชี้ให้เห็นถึงความจำเป็นในการจัดลำดับความสำคัญของ Requirement ที่เราเรียกว่า Requirement Prioritization นั่นแหละ แบบนี้เราพูดได้แล้วมั้งว่า “80% ของผู้ใช้จะใช้งานแค่ 20% ของฟีเจอร์ทั้งหมด” หรืออีกความหมายนึงก็คือ ถ้าเราทำฟีเจอร์ที่สำคัญที่สุด 20% แรกได้ เราก็สามารถตอบสนองผู้ใช้ได้ตั้ง 80% แหนะ … ดูดีจริงๆ

มีอีก … IBM ก็ได้ประโยชน์จากการประยุกต์ใช้กฎนี้เหมือนกัน จากการศึกษาอย่างละเอียด IBM พบว่า 80% ของเวลาประมวลผล (Execution Time) ใน CPU ถูกใช้ไปกับชุดคำสั่ง (Instructions) เพียง 20% เท่านั้นเอง ดังนั้น IBM เลยทุ่มเทกำลังเพื่อปรับปรุงประสิทธิภาพการจัดการกับชุดคำสั่ง 20% นั้นจนประสบความสำเร็จ นี่เป็นการสร้างความได้เปรียบทางธุรกิจให้กับ IBM อย่างมหาศาลเลยทีเดียว เจ๋ง

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

• 80% ของ Requirement มีความสำคัญแค่ 20% ของโปรเจกต์
• 80% ของผู้ใช้จะใช้งานแค่ 20% ของซอฟต์แวร์
• 80% ของโค๊ดถูกเขียนโดยคนแค่ 20%
• 80% ของโค๊ดเป็น Exception Handling กับ Future Feature แค่ 20% ต่างหากที่เป็นงานจริงๆ
• 80% ของผลลัพธ์ที่ต้องการจากการ Test เกิดจากเวลา 20% ใน Test Phase
• 80% ของบั๊กที่เจอมาจาก 20% ของโค๊ดเรา
• 80% ของปัญหาและเสียงบ่นจากลูกค้าทั้งหมดที่เจอในซอฟต์แวร์เกิดจากแค่ 20% ของบั๊กที่มี
• 80% ของเอกสารถูกเขียนโดยคน 20%
• 80% ของเอกการถูกอ่านโดยคน 20%
• 80% ของประโยชน์ที่ได้เกิดจากเอกสาร 20% จากทั้งหมด
• 80% ของสิ่งสำคัญเกิดจากแค่ 20% ใน Product Backlog
• 80% ของยอดขายมาจากแค่กลุ่มลูกค้า 20%
• 80% ของยอดขายมาจากแค่ 20% ของโปรดักส์ที่เรามี
• 80% ของความคิดเห็นในห้องประชุมจะมาจากคนแค่ 20% ที่ร่วมประชุม
• 80% ของการตัดสินใจในห้องประชุมเกิดจากคนแค่ 20% ที่ร่วมประชุม
• 80% ของเรื่องการเมืองในโปรเจกต์เกิดจาก 20% ของ Stakeholder
• 80% … 20% …

เราคิดต่อยอดได้อีกเยอะ ประเด็นสำคัญอยู่ตรงนี้ครับ

“เราใช้เวลา 80% ไปเพื่อทำงานที่ได้ผลลัพท์แค่ 20% ในโปรเจกต์รึเปล่า?”

เมื่อพิจารณาดูแล้วก็มีส่วนจริงอยู่นะ ที่ปัญหาเวลาไม่พอมันเกิดก็เพราะสาเหตุนี้ด้วยจริงๆ

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

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ