ความท้าทายเก่าแก่เรื่องซอฟต์แวร์ที่พองตัวได้จุดประกายการถกเถียงใหม่ในหมู่นักพัฒนาและผู้จัดการผลิตภัณฑ์ การอภิปรายล่าสุดเผยให้เห็นความจริงพื้นฐานเกี่ยวกับการออกแบบแอปพลิเคชัน: แม้ว่าผู้ใช้โดยทั่วไปจะใช้งานเพียง 20% ของฟีเจอร์ในแอปพลิเคชัน แต่ผู้ใช้แต่ละคนกลับพึ่งพา 20% ที่แตกต่างกันโดยสิ้นเชิง
การตรวจสอบความเป็นจริงในองค์กร
การสนทนาเปลี่ยนไปในทิศทางที่น่าสนใจเมื่อตรวจสอบการขายซอฟต์แวร์องค์กร นักพัฒนาหลายคนแบ่งปันประสบการณ์ที่ฟีเจอร์ที่ดูเหมือนไม่มีใครใช้กลับกลายเป็นตัวทำลายข้อตกลงสำหรับลูกค้าองค์กรขนาดใหญ่ ฟีเจอร์สุขอนามัยเหล่านี้ - เช่น single sign-on การบันทึกการตรวจสอบ หรือข้อกำหนดการปฏิบัติตามกฎระเบียบเฉพาะ - อาจถูกใช้น้อย แต่จำเป็นอย่างยิ่งสำหรับการปิดสัญญาใหญ่
เพราะ 'ฟีเจอร์สุขอนามัย' ที่หายไปเพียงอันเดียวสามารถทำลายข้อตกลงทั้งหมดได้ และองค์กรแต่ละแห่งก็มีฟีเจอร์ที่แตกต่างกัน
สิ่งนี้สร้างพลวัตที่ท้าทายสำหรับทีมพัฒนา ทีมขายมักจะสัญญาฟีเจอร์ที่กำหนดเองเพื่อให้ได้ลูกค้าใหญ่ ทำให้วิศวกรต้องสร้างและดูแลฟังก์ชันการทำงานที่ให้บริการความต้องการเฉพาะเจาะจง บางครั้งเป็นความต้องการของลูกค้าเพียงรายเดียว หนี้ทางเทคนิคจากฟีเจอร์ที่จำเป็นเหล่านี้สามารถสะสมได้อย่างรวดเร็ว โดยเฉพาะเมื่อลูกค้าที่ขอฟีเจอร์เดิมในที่สุดก็หยุดใช้บริการ
รายการตรวจสอบ "คุณสมบัติด้านสุขอนามัย" สำหรับองค์กร:
- Single Sign-On (SSO) / การรวมระบบ SAML
- การรับรอง ISO และการปฏิบัติตามข้อกำหนด
- การทดสอบการเจาะระบบอย่างสม่ำเสมอ
- การสนับสนุนการปรับแต่งตามท้องถิ่น
- การเข้าถึง API (มักไม่ได้ใช้แต่จำเป็นต้องมี)
- ความสามารถในการดำเนินการจำนวนมาก
- ตัวเลือกการติดตั้งเซิร์ฟเวอร์เอง
- ทีมงาน & สิทธิ์การเข้าถึงแบบละเอียด
- การบันทึกการตรวจสอบ
- การปฏิบัติตามข้อกำหนด SOC 2/3
- นโยบายการเก็บรักษาข้อมูล
- เครื่องมือปฏิบัติตามข้อกำหนด GDPR & CCPA
ปรากฏการณ์ Microsoft Office
การอภิปรายมักกลับมาที่ Microsoft Office เป็นตัวอย่างหลักของหลักการนี้ นักพัฒนาคนหนึ่งพยายามวิเคราะห์แอปพลิเคชัน SaaS ของตนโดยจัดกลุ่มผู้ใช้ตามการใช้ฟีเจอร์ หวังว่าจะระบุต้นแบบผู้ใช้หลัก ผลลัพธ์ที่ได้บอกเล่าได้ชัดเจน - นอกเหนือจากฟังก์ชันการเข้าสู่ระบบพื้นฐานแล้ว ผู้ใช้แทบทุกคนมีฟีเจอร์ที่พึ่งพาซึ่งแตกต่างกันโดยสิ้นเชิง
สิ่งนี้สะท้อนการสังเกตที่มีมานานหลายทศวรรษเกี่ยวกับการใช้งาน Office Suite ที่มีเรื่องตลกว่าไม่มีใครใช้ความสามารถของ Microsoft Word มากกว่า 5% แต่ไม่มีผู้ใช้สองคนที่ใช้ 5% เดียวกัน รูปแบบเดียวกันนี้เกิดขึ้นในแอปพลิเคชันที่ซับซ้อน: ผู้ใช้แต่ละคนสร้างชุดเครื่องมือที่จำเป็นของตนเองจากชุดฟีเจอร์ที่กว้างขึ้น
 |
|---|
| การมีส่วนร่วมของผู้ใช้ที่หลากหลายกับฟีเจอร์เฉพาะในแอปพลิเคชันซอฟต์แวร์สะท้อนให้เห็นการผสมผสานที่เป็นเอกลักษณ์ที่ผู้ใช้แต่ละคนพบว่าจำเป็น ดังที่เห็นในแดชบอร์ดทางการเงินที่แสดงอยู่ที่นี่ |
การค้นหาความสำเร็จในช่องว่าง
บางบริษัทพบโอกาสในการแยกส่วนนี้ เสิร์ชเอนจิน Kagi ระบุว่า 1% ที่ไม่พอใจของ Google - ผู้ใช้ขั้นสูงที่หงุดหงิดกับสแปม SEO และข้อกังวลเรื่องความเป็นส่วนตัว - จริงๆ แล้วแทนลูกค้าที่มีศักยภาพหลายล้านคน แทนที่จะแข่งขันกับ Google ในทุกกรณีการใช้งาน Kagi มุ่งเน้นไปที่การให้บริการส่วนเฉพาะนี้อย่างสมบูรณ์แบบ
กลยุทธ์นี้ปรากฏในผลิตภัณฑ์ที่ประสบความสำเร็จอื่นๆ ด้วย Figma ไม่จำเป็นต้องแทนที่เครื่องมือสร้างสรรค์ทั้งหมดของ Adobe - พวกเขาแค่ต้องเป็นเลิศในการออกแบบแบบร่วมมือ ข้อมูลเชิงลึกสำคัญคือการตระหนักว่าส่วนไหนของผู้ใช้ที่ได้รับการบริการไม่เพียงพอจากโซลูชันที่มีอยู่และสร้างขึ้นเฉพาะสำหรับความต้องการของพวกเขา
ตัวอย่างกลยุทธ์ "20% ที่แตกต่าง" ที่ประสบความสำเร็จ:
- Kagi: มุ่งเน้นผู้ใช้ขั้นสูงของ Google ที่ไม่พอใจและต้องการการค้นหาที่ปราศจากโฆษณาและเน้นความเป็นส่วนตัว
- Figma: เชี่ยวชาญด้านการออกแบบแบบร่วมมือ เทียบกับชุดเครื่องมือสร้างสรรค์ที่กว้างขวางของ Adobe
- Notion: เครื่องมือแบบผสมผสานสำหรับทีมที่ต้องการทั้งฟังก์ชันการประมวลผลคำและฐานข้อมูล
- VS Code: ตัวแก้ไขแบบโมดูลาร์ที่ให้ปรับแต่ง 20% ได้ผ่านส่วนขยาย
- Trello: การจัดการโครงการแบบง่ายที่พัฒนามาจากฟังก์ชันการสร้างตารางของ Excel
ภาวะที่กลืนไม่เข้าคายไม่ออกของการพัฒนา
สำหรับนักพัฒนาแต่ละคนและทีมเล็ก ความเป็นจริงนี้สร้างความขัดแย้งที่น่าหงุดหงิด นักพัฒนาที่ทำเป็นงานอดิเรกหลายคนสร้างแอปพลิเคชันที่แก้ปัญหาเฉพาะของตนเองได้อย่างสมบูรณ์แบบ แต่ลังเลที่จะเผยแพร่ต่อสาธารณะเพราะไม่ต้องการใช้งาน 80% ที่เหลือที่ผู้ใช้ต่างๆ อาจต้องการ
โซลูชันมุ่งไปที่การสร้างแพลตฟอร์มแบบโมดูลาร์และขยายได้มากกว่าแอปพลิเคชันแบบ monolithic VS Code ประสบความสำเร็จโดยเริ่มต้นด้วยแกนกลางของโปรแกรมแก้ไขข้อความที่เบาและอนุญาตให้ผู้ใช้ปรับแต่งสภาพแวดล้อมของตนผ่านส่วนขยาย วิธีการนี้ให้ผู้ใช้แต่ละคนสร้าง 20% ที่สมบูรณ์แบบของตนในขณะที่รักษาแอปพลิเคชันฐานให้จัดการได้
บทสรุป
กฎ 80/20 ในซอฟต์แวร์ไม่ได้เป็นเพียงการระบุฟีเจอร์ที่ไม่ได้ใช้ - แต่เป็นการเข้าใจว่าผู้ใช้ต่างๆ มีความต้องการที่แตกต่างกันโดยพื้นฐานจากแอปพลิเคชันเดียวกัน แทนที่จะต่อสู้กับความเป็นจริงนี้ ผลิตภัณฑ์ที่ประสบความสำเร็จยอมรับมันโดยการสร้างรากฐานที่ยืดหยุ่นที่ผู้ใช้สามารถปรับให้เข้ากับความต้องการเฉพาะของตนได้ ความท้าทายสำหรับนักพัฒนาคือการสร้างระบบที่รองรับความหลากหลายนี้โดยไม่กลายเป็นสิ่งที่ดูแลไม่ได้หรือสูญเสียโฟกัสในฟังก์ชันการทำงานหลัก