เลิกใช้งานฟีเจอร์ด้วยกราฟความสัมพันธ์ ไม่ใช่แค่ดูยอด MAU

การถกเถียงกันในช่องทางสื่อสารช่วงดึกมักวนเวียนอยู่กับคำถามที่ว่า เราไม่สามารถตัดสินใจปิดฟีเจอร์ใดฟีเจอร์หนึ่งได้เพียงแค่มองดูสถิติการใช้งาน ตัวเลขการใช้งานบอกเพียงแค่ว่าใครเดินเข้ามาทางประตูหน้า แต่ไม่ได้บอกเลยว่าส่วนใดคือเสาหลักรับน้ำหนักในห้องใต้ดิน มีหลายทีมที่เคยสั่งปิดฟีเจอร์ที่มีผู้ใช้งานต่อเดือนเพียงร้อยละ 2 แต่กลับส่งผลกระทบทำลายเครื่องมือภายใน 3 ชนิด ระบบเชื่อมต่อของพาร์ทเนอร์ และรายงานการปฏิบัติตามกฎระเบียบที่ฝ่ายการเงินเรียกดูทุกไตรมาส ซึ่งไม่มีสิ่งเหล่านี้แสดงอยู่บนหน้าจอแดชบอร์ดเลย

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

ตัวอย่างจากบริษัท SaaS ระดับกลางรายหนึ่งที่มีฟีเจอร์ชื่อ Custom Export Templates ซึ่งถูกสร้างขึ้นเมื่อ 3 ปีที่แล้ว มีบัญชีใช้งานเพียงร้อยละ 1.4 ต่อเดือน และมีค่าใช้จ่ายในการบำรุงรักษาประมาณ 140 ชั่วโมงวิศวกรรมต่อไตรมาส หากวัดตามคะแนนการใช้งาน นี่คือผู้ป่วยซอมบี้ชั้นดีที่ควรถูกกำจัด ทีมผลิตภัณฑ์ถึงกับเตรียมสไลด์นำเสนอไว้รอแล้ว แต่โชคดีที่มีคนลองตรวจสอบความสัมพันธ์เชิงโครงสร้างก่อนที่จะลงมือตัดทอนมันจริงๆ

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

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