เพื่อนๆเคยได้ยินกฎ 80-20 มั้ยครับ? ผมรู้จักกับเจ้ากฎนี้ตอนที่เรียนปริญญาโทวิชา Business Process Management ซึ่งหลักใหญ่ใจความของมันก็คือ “ปัญหา 80% เกิดจากสาเหตุ 20%” หรือพูดอีกนัยหนึ่งก็คือถ้าเรากำจัดสาเหตุ 20% นั้นได้ก็เหมือนเราแก้ปัญหาไปได้แล้วตั้ง 80% ครับ

แล้วไงต่อ? เพื่อนๆอาจจะสงสัยว่าวันนี้ผมมาพูดถึงเรื่องนี้ทำไม แหะๆ ก็พอดีผมกำลังเจอปัญหาใน Project ที่ทำอยู่(ไม่)นิดหน่อย ปัญหาคลาสสิกครับ “เวลาไม่พอ” ตอนที่นั่งคิดหาทางแก้อยู่ดีๆก็มานึกถึงเจ้า 80-20 นี่เฉยเลยครับ พิจารณาต่ออีกหน่อย เออ เข้าท่าแหะ มันน่าจะช่วยเราได้จริงนะเนี่ยะ

ลองมาดูครับว่าผมประยุกต์ใช้กฎนี้เพื่อแก้ปัญหายังไง

กฎ 80-20 คืออะไร?

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

กฎ 80-20 กับ Software Development Project

อยากจะบอกว่าความเกี่ยวข้องของมันยิ่งใหญ่มากๆครับ เริ่มจากเรื่องที่เป็นทางการก่อนนะครับ รายงานทางสถิติจาก Standish Group เกี่ยวกับการใช้งานซอฟท์แวร์บอกว่าประมาณ 80% ของ Feature ต่างๆที่มีือยู่ในซอฟท์แวร์นั้นไม่เคยหรือแทบไม่เคยถูกใช้งานเลย ที่น่าสนใจไปกว่านั้นมีเพียง 20% ของ Feature เท่านั้นแหละครับที่ถูกใช้บ่อยๆ

หลักฐานชิ้นที่สองเกี่ยวข้องโดยตรงกับตัวผมเองครับ บทความนี้กำลังจะเป็นบทความที่ 65 ของผม ผมพิมพ์ตัวอักษรไปหลายหมื่นตัวอักษรแล้ว (ไม่ต้องรวมตอนเรียนกับทำงานด้วย) แต่ผมมั่นใจเลยว่าผมใช้งาน Feature ของ Microsoft Word ไม่ถึง 20% ด้วยซ้ำ นี่ก็สอดคล้องกับผลการสำรวจโดย Microsoft เองว่ามีเพียง 8% ของ Feature ใน Microsoft Word ที่ถูกใช้บ่อยๆ … หนักกว่าอีกนะเนี่ยะ

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

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

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

80% ของ Requirement มีความสำคัญแค่ 20% ของ Project

80% ของผู้ใช้จะใช้งานแค่ 20% ของซอฟท์แวร์

80% ของโค๊ดถูกเขียนโดยคนแค่ 20%

80% ของโค๊ดเป็น Exception Handling กับ Future Feature แค่ 20% ต่างหากที่เป็นงานจริงๆ

80% ของผลลัพธ์ที่ต้องการจากการ Test เกิดจากเวลา 20% ใน Test Phase

80% ของ Defect ที่เจอมาจาก 20% ของโค๊ดเรา

80% ของเอกสารถูกเขียนโดยคน 20%

80% ของเอกการถูกอ่านโดยคน 20%

80% ของประโยชน์ที่ได้เกิดจากเอกสาร 20% จากทั้งหมด

80% ของความคิดเห็นในห้องประชุมจะมาจากคนแค่ 20% ที่ร่วมประชุม

80% ของการตัดสินใจในห้องประชุมเกิดจากคนแค่ 20% ที่ร่วมประชุม

80% … 20% …

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

ทำงานอย่างฉลาดและคุ้มค่า

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

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

• ไม่สำคัญ – ไม่เร่งด่วน
• ไม่สำคัญ – เร่งด่วน
• สำคัญ – ไม่เร่งด่วน และ
• สำคัญ – เร่งด่วน
  

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

คำว่า “สำคัญ” กับ “เร่งด่วน” ของแต่ละคน แต่ละงานไม่เหมือนกันครับ คงไม่ง่ายนักที่ผมจะสรุปมาได้ว่าอะไรคืองานที่สำคัญและเร่งด่วนกว่ากัน แต่เพื่อให้เพื่อนๆได้ดูเป็นแนวทางผมขอเอาการจัดกลุ่มงานของผมเองมาให้ดูกันครับ การแบ่งงานออกเป็นกลุ่มๆของผมนั้นไม่ได้เฉพาะเจาะจงว่าต้องเป็นงานใน Phase ไหนหรือใครรับผิดชอบนะครับ แต่ผมมองโดยรวมของ Project เลย ไม่ว่าจะเป็นเรื่องการเลือก Requirement มาทำ การ Design การ Coding และ Testing แล้วก็รวมไปถึงเรื่องพวกการทำเอกสาร การประชุม ทั้งหมดเลยครับ

สรุป

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

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

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

Related posts:

1. ง่ายๆกับการเพิ่ม Project Task ให้ Outlook
2. Software Prototyping ภาค 1
3. Software Prototyping ภาค 2 — Throwaway Prototyping
4. Software Prototyping ภาค 3 — Evolutionary Prototyping
5. Historical Data กับ Software Estimation