แจ้งเตือน Linear, GitHub, Slack ท่วม – ลดเหลือแค่ 5
การแจ้งเตือนจาก Linear, GitHub และ Slack ท่วมทีมวิศวกรของคุณ? วิเคราะห์ว่าทำไมสถาปัตยกรรมนี้ถึงพัง – และ 5 สัญญาณที่ควรเก็บไว้
By Ellis Keane · 2026-03-13
ปัญหาไม่ใช่ว่าคุณได้รับการแจ้งเตือนมากเกินไป ปัญหาคือคุณได้รับจำนวนที่ถูกต้องพอดี – จากสามเครื่องมือที่แตกต่างกัน เกี่ยวกับเหตุการณ์เดียวกัน ในเวลาเดียวกัน
ทุก webhook ทำงานถูกต้อง ทุกการเชื่อมต่อส่งมอบสิ่งที่สัญญาไว้อย่างแม่นยำ GitHub แจ้งเตือนคุณเกี่ยวกับ PR Linear แจ้งเตือนคุณเกี่ยวกับ issue ที่ PR นั้นปิด Slack แจ้งเตือนคุณเพราะมีคน ณ จุดใดจุดหนึ่ง (น่าจะเป็นคุณ เมื่อสามเดือนก่อน ในช่วงที่มองโลกในแง่ดีเรื่อง "การมองเห็น") เชื่อมต่อบอตเข้ากับช่องโปรเจกต์ สามเครื่องมือ สามการแจ้งเตือน หนึ่งเหตุการณ์ และทั้งหมดทำงานตามที่ออกแบบมา วิศวกรรมสมบูรณ์แบบ ประสบการณ์แย่มาก
การแจ้งเตือนจาก Linear, GitHub และ Slack ของคุณไม่ได้ท่วมหัวเพราะมีบางอย่างพัง แต่ท่วมหัวเพราะไม่มีอะไรพัง เครื่องมือแต่ละชิ้นกำลังดำเนินการตามสัญญาการแจ้งเตือนของตัวเองอย่างซื่อสัตย์ โดยไม่รับรู้ถึงการมีอยู่ของเครื่องมืออื่น ไม่มี shared event bus ไม่มี deduplication layer ไม่มีแนวคิดใดๆ ในสแต็กนี้ที่ว่า "มนุษย์คนนี้รู้เรื่องนี้แล้ว" คุณไม่ได้ทุกข์ทรมานจากการตั้งค่าผิดพลาด คุณทุกข์ทรมานจากผลลัพธ์สุดท้ายของการเสียบเครื่องมือหกชิ้นเข้ากับเวิร์กโฟลว์เดียวกันและปล่อยให้แต่ละชิ้นตะโกนออกไปสู่ความว่างเปล่าอย่างอิสระ
"ระบบการแจ้งเตือนไม่ได้ล้มเหลว มันประสบความสำเร็จจนกำลังฝังคุณ" – Chris Calo
ความก้าวหน้า
กายวิภาคของการรวมโค้ดครั้งเดียว – การชันสูตรการซ้ำซ้อน
ขอเดินทางผ่านหนึ่งเหตุการณ์ – การรวม PR ครั้งเดียว – และติดตามสิ่งที่เกิดขึ้นในชั้นการแจ้งเตือน ไม่ใช่เพราะมันผิดปกติ แต่เพราะมันธรรมดาอย่างน่าหดหู่
เพื่อนร่วมทีมรวม PR บน GitHub นี่คือปฏิกิริยาลูกโซ่:
- GitHub ส่ง webhook ไปยังกล่องการแจ้งเตือนของคุณ คุณเขียนรีวิวบน PR นี้ ดังนั้นคุณจึงติดตามอยู่ นั่นคือการแจ้งเตือนที่หนึ่ง
- การเชื่อมต่อ GitHub ของ Linear ตรวจจับ issue ที่เชื่อมโยงและเปลี่ยนสถานะอัตโนมัติจาก "กำลังดำเนินการ" เป็น "เสร็จแล้ว" Linear สร้างการแจ้งเตือนสำหรับทุกคนที่กำลังดู issue นั้น – รวมถึงคุณด้วย เพราะคุณอยู่ในทีมเดียวกัน นั่นคือการแจ้งเตือนที่สอง
- บอท Slack (ที่คุณเชื่อมต่อด้วยความสุขใจที่ฉันกล่าวถึง) โพสต์สรุปการรวมโค้ดไปยัง #frontend ถ้ามีคนตอบสนองต่อข้อความนั้นด้วย emoji หรือความคิดเห็น Slack จะสร้างการแจ้งเตือนเธรด นั่นคือการแจ้งเตือนที่สาม อาจถึงที่สี่
- CI รันบน merge commit GitHub ส่ง webhook อีกครั้ง ถ้า CI ผ่าน คุณอาจไม่สนใจ แต่คุณก็ได้รับการแจ้งเตือนอยู่ดี เพราะโมเดลการติดตามของ GitHub เป็นแบบไบนารี – คุณกำลังดูอยู่หรือไม่ก็ไม่ดู นั่นคือการแจ้งเตือนที่ห้า
ห้าการแจ้งเตือน หนึ่งเหตุการณ์ และคุณอยู่ในการโทรที่มีการพูดคุยเรื่องการรวมโค้ด ดังนั้นคุณรู้เรื่องนี้แล้วก่อนที่จะมีการแจ้งเตือนใดๆ มาถึง
คูณสิ่งนี้กับทุก PR ทุกการเปลี่ยนสถานะ issue และทุก CI run สำหรับทีมหกคน และคุณกำลังมองดูเหตุการณ์ซ้ำ 30 ถึง 40 รายการต่อคนต่อวัน ก่อนที่จะนับสัญญาณใหม่จริงๆ ด้วยซ้ำ ระบบการแจ้งเตือนไม่ได้ล้มเหลว มันประสบความสำเร็จจนกำลังฝังคุณ
ทำไมการปิดเสียงถึงเป็นแค่การปะผุปัญหาใหญ่
คำแนะนำมาตรฐานคือการปิดเสียงอย่างรุนแรง ปิดการแจ้งเตือนอีเมลของ GitHub ตั้ง Slack ให้แจ้งเตือนเฉพาะเมื่อมีการกล่าวถึงโดยตรง ยกเลิกการติดตาม issue ทั้งหมดใน Linear ยกเว้นที่มอบหมายให้คุณ นี่คือเทียบเท่าการแจ้งเตือนของการรักษาข้อมือหักโดยถอดนาฬิกาออก – ในทางเทคนิคคุณลดความซับซ้อนเกี่ยวกับข้อมือ แต่คุณก็สูญเสียความสามารถในการบอกเวลาด้วย
ฉันลองวิธีการปิดเสียง (แน่นอนว่าลอง – เราทุกคนทำ มันเป็นสิ่งแรกที่ทุกคนลอง ก่อนสิ่งที่สอง ซึ่งคือ Zapier chain ที่ทำให้มันแย่ลงไปอีก) ฉันทำอย่างจริงจัง: ปิดอีเมล GitHub ทั้งหมด ปิดเสียงทุกช่องใน Slack ยกเว้นช่องทำงานของทีม ยกเลิกการติดตามทุกอย่างใน Linear ยกเว้น issue ของตัวเอง ความสุขประมาณสามวัน
แล้วฉันก็พลาดการรีวิว PR ที่บล็อกงานสองรายการ เพราะการสนทนาเกิดขึ้นในช่องที่ฉันปิดเสียงไว้ วิศวกรที่ต้องการการรีวิวของฉันในที่สุดก็ DM ฉัน – ซึ่งก็แค่การแจ้งเตือนที่มีขั้นตอนเพิ่มเติมพร้อมกับพลังงาน "เฮ้ คุณเห็นข้อความของฉันไหม?" แบบ passive-aggressive หนึ่งสัปดาห์ต่อมา การตัดสินใจด้านดีไซน์ถูกโพสต์ใน Figma comment thread ที่เปลี่ยนคอมโพเนนต์ที่ฉันกำลังสร้างอยู่ครึ่งหนึ่งโดยสิ้นเชิง และฉันไม่รู้จนกว่า PR ของฉันจะถูกปฏิเสธ ซึ่งมันสนุกมาก
ปัญหาพื้นฐานของการปิดเสียงคือการใช้กฎแบบคงที่กับบริบทแบบไดนามิก การตั้งค่าการแจ้งเตือนของคุณจากวันอังคารที่แล้วไม่รู้เกี่ยวกับบักเร่งด่วนที่เกิดขึ้นเช้านี้ และยิ่งคุณปิดเสียงอย่างรุนแรงมากขึ้น ช่องว่างในการรับรู้ของคุณก็ยิ่งกว้างขึ้น – ช่องว่างที่เพื่อนร่วมทีมเติมด้วย DM "แค่เช็คว่าเห็น..." ซึ่งถ้าคุณนับคะแนน หมายความว่าการปิดเสียงอย่างรุนแรงไม่ได้ลดการแจ้งเตือนของคุณ มันแค่เปลี่ยนจากบอต (ที่ไม่ตัดสินคุณ) ไปเป็นมนุษย์ (ที่ตัดสินแน่นอน)
ห้าสัญญาณที่จำเป็นต้องขัดจังหวะจริงๆ
หลังจากบันทึกการแจ้งเตือนสองสามสัปดาห์ (ในไฟล์ข้อความธรรมดา เพราะฉันเป็นแบบที่คุณคาดหวังจะเห็นเขียนบทความเกี่ยวกับสถาปัตยกรรมการแจ้งเตือน) รูปแบบก็ปรากฏขึ้น จากประมาณ 200 การแจ้งเตือนต่อวัน รายการที่ต้องดำเนินการจริงๆ ภายในชั่วโมงนั้นอยู่ในห้าหมวดหมู่:
- มีคนถูกบล็อกโดยคุณ คำขอรีวิว PR บนโค้ดที่คุณเป็นเจ้าของ คำถามที่มีแต่คุณเท่านั้นที่ตอบได้ การตัดสินใจที่รอ input ของคุณ นี่เป็นหมวดเดียวที่การล่าช้ามีต้นทุนแบบทบต้น – ทุกชั่วโมงที่คุณไม่ตอบสนองคือชั่วโมงที่คนอื่นทำงานไม่ได้
- มีบางอย่างที่คุณ deploy แล้วพัง CI ล้มเหลวบน branch ของคุณ error spike หลังการรวมโค้ดของคุณ คำขอ revert หมวด "โค้ดของคุณกำลังติดไฟ"
- มีการตัดสินใจที่กระทบงานปัจจุบันของคุณ การเปลี่ยนแปลงดีไซน์ การอัปเดต API contract การเปลี่ยนลำดับความสำคัญจากฝั่งผลิตภัณฑ์ สิ่งเหล่านี้หายากแต่ราคาแพงถ้าพลาด (ดู: PR ที่ถูกปฏิเสธของฉัน ข้างต้น)
- กำหนดเวลาเปลี่ยน ขอบเขต Sprint เปลี่ยน การ demo ถูกเลื่อนขึ้น dependency ล่าช้า เหตุการณ์ที่เปลี่ยนปฏิทิน
- มีคนต้องการความช่วยเหลือและคุณเป็นคนที่เหมาะสม ไม่ใช่ทุก @channel ไม่ใช่ทุก @here รายการที่เฉพาะเจาะจงที่ความเชี่ยวชาญของคุณมีความเกี่ยวข้องจริงๆ – และแม้กระนั้น ต่อเมื่อไม่มีคนอื่นตอบได้เท่านั้น
ทุกอย่างอื่น – การเปลี่ยนสถานะ ข้อความบอตอัตโนมัติ การตอบสนองด้วย emoji "เยี่ยม" CI ผ่านบน branch ที่คุณไม่ได้ดูอยู่ – คือข้อมูลที่อาจมีประโยชน์ในที่สุด แต่ไม่จำเป็นต้องขัดจังหวะฟังก์ชันที่คุณกำลังเขียน อุตสาหกรรมการแจ้งเตือนทำให้เราเชื่อว่าทั้งหมดนี้สมควรได้รับความเร่งด่วนเท่ากัน แต่มันไม่ใช่
จากการแจ้งเตือน 200 รายการต่อวัน มีประมาณห้าหมวดหมู่ที่จำเป็นต้องขัดจังหวะงานของคุณจริงๆ ส่วนที่เหลือคือข้อมูลที่อาจมีประโยชน์ในที่สุด – แต่เครื่องมือต่างๆ ปฏิบัติต่อทุกอย่างด้วยความเร่งด่วนเท่ากัน ซึ่งหมายความว่าไม่มีอะไรเร่งด่วนจริงๆ
กรอบการคัดแยกสำหรับผู้ที่ถูกสถาปัตยกรรมทรยศ
นี่คือกรอบที่คุณสามารถเริ่มใช้วันนี้ได้เลย – ไม่ต้องการเครื่องมือใดๆ แค่ต้องมีวินัยและตั้งค่าประมาณ 20 นาที มันจะไม่แก้ปัญหาสถาปัตยกรรม (ไม่มีอะไรนอกจาก deduplication layer ที่ทำได้) แต่จะหยุดเลือดไหลในขณะที่คุณประเมินทางแก้ไขระยะยาว
การกวาดสองครั้งต่อวัน: แทนที่จะตรวจสอบการแจ้งเตือนอย่างต่อเนื่อง รวมเป็นสองช่วง – ช่วงสายๆ ในตอนเช้าครั้งหนึ่ง และบ่ายๆ ครั้งหนึ่ง ในแต่ละช่วง สแกนการแจ้งเตือน GitHub กล่องข้อความ Linear และข้อความที่ยังไม่อ่านใน Slack แล้วจัดแต่ละรายการเป็นหนึ่งในสามกลุ่ม:
| กลุ่ม | กฎ | การดำเนินการ | |--------|------|--------| | ดำเนินการทันที | มีคนถูกบล็อก มีบางอย่างพัง หรือการตัดสินใจต้องการคุณ | จัดการทันที | | รวมกลุ่ม | สำคัญแต่ไม่ต้องรีบ | เพิ่มใน "ตอบทีหลัง" จัดการตอนสิ้นวัน | | เก็บถาวร | การสนทนาของบอต การอัปเดตสถานะ เธรดที่แก้ไขแล้ว รายการซ้ำ | อ่านแล้วทำเครื่องหมาย ดำเนินชีวิตต่อ |
ตั้งค่าเริ่มต้นระดับช่องใน Slack: สำหรับแต่ละช่อง ตัดสินใจ: นี่คือช่อง "ดำเนินการทันที" (ช่องทำงานของทีม ช่อง incident) หรือช่อง "รวมกลุ่ม" (ประกาศทั่วไป การอัปเดตข้ามทีม)? ปิดเสียงช่องรวมกลุ่มและตรวจสอบเฉพาะในช่วงการกวาด ใช่ นี่คือการปิดเสียงทางเทคนิค ซึ่งฉันเพิ่งใช้เวลาสองย่อหน้าวิจารณ์ – ความแตกต่างคือคุณยังตรวจสอบตามตารางเวลาแทนที่จะแกล้งทำเป็นว่าไม่มีอยู่
ใช้ตัวกรองการแจ้งเตือนของ GitHub: บุ๊คมาร์ค github.com/notifications?query=reason:review-requested – URL นั้นแสดงเฉพาะการรีวิว PR ที่มอบหมายให้คุณโดยตรง ตัดเสียงรบกวนจากการติดตาม/CI ออกทั้งหมด สำหรับอีเมล GitHub มี reason header (review_requested, mention, subscribed, ci_activity) ที่คุณกรองได้: เก็บถาวรอัตโนมัติ "subscribed" และ "ci_activity" แล้วคุณจะไม่พลาดสิ่งที่คุณต้องการจริงๆ ข้อเท็จจริงที่ว่า GitHub ฝัง metadata ที่มีประโยชน์นี้ไว้ใน email headers แทนที่จะแสดงใน notification UI บอกทุกอย่างเกี่ยวกับความคิดที่ลงทุนในฝั่งการบริโภคของระบบเหล่านี้
วิธีนี้จะไม่ดักจับสัญญาณเชิงบริบท (จำ Figma comment ที่ทำให้ PR ของฉันล่มไหม? การกวาดสองครั้งต่อวันก็ไม่ได้จับมันเช่นกัน) แต่จะลดเสียงรบกวนลง 60 ถึง 70 เปอร์เซ็นต์ ซึ่งเพียงพอที่จะหยุดการ alt-tab แบบบีบบังคับในขณะที่คุณคิดว่าปัญหาต้องการทางแก้ไขจริงๆ หรือไม่
สิ่งที่ deduplication layer จำเป็นต้องทำจริงๆ
นี่คือจุดที่น่าสนใจในเชิงสถาปัตยกรรม – และจุดที่ฉันหยุดคิดว่านี่เป็นปัญหาการตั้งค่าการแจ้งเตือนและเริ่มคิดว่าเป็นปัญหาการจำแนกประเภท
วิธีการแบบไร้เดียงสาคือการจับคู่คำสำคัญและการตรวจจับการกล่าวถึง ถ้าชื่อของคุณปรากฏ ให้แสดงขึ้น ถ้าเป็นคำขอรีวิวที่มอบหมายให้คุณ ให้แสดงขึ้น สิ่งนี้ดักจับกรณีที่ชัดเจนแต่พลาดกรณีเชิงบริบทโดยสิ้นเชิง – การตัดสินใจด้านดีไซน์ในเธรดที่ไม่มีใคร @-mentioned คุณเพราะพวกเขาไม่รู้ว่าคุณกำลังสร้างคอมโพเนนต์ที่มันกระทบ (อันนั้นจะหลอกหลอนฉันอีกสักพัก)
สิ่งที่คุณต้องการจริงๆ คือกราฟความสัมพันธ์: งานใดของคุณ PR ใดเกี่ยวข้องกับ issue ใด เธรด Slack ใดเกี่ยวกับฟีเจอร์ใด คนใดมักต้องการ input ของคุณในหัวข้อใด เมื่อสัญญาณใหม่มาถึง – ข้อความ Slack เหตุการณ์ GitHub การเปลี่ยนสถานะ Linear – คุณจำแนกมันตามกราฟนั้น ไม่ใช่ "นี่กล่าวถึง Chris ไหม?" แต่ "สิ่งนี้กระทบบางอย่างที่ Chris กำลังทำงานอยู่ รอคอย หรือรับผิดชอบอยู่ไหม?"
การจำแนกประเภทจำเป็นต้องแบ่งออกเป็นบางอย่างเช่น:
| การจำแนกประเภท | ความหมาย | การดำเนินการ | |---------------|---------------|--------| | เร่งด่วน | คุณกำลังบล็อกคนอื่น หรือมีบางอย่างพัง | แสดงทันที | | สำคัญ | กระทบงานปัจจุบันของคุณ แต่ไม่สำคัญด้านเวลา | รวมเป็น daily digest | | เพื่อข้อมูล | ดีที่รู้ ไม่ต้องดำเนินการ | พร้อมใช้ถ้าคุณไปค้นหา | | เสียงรบกวน | รายการซ้ำ บอตพูดคุย เธรดที่แก้ไขแล้ว | กรองออกทั้งหมด |
ส่วนที่ยากคือความมั่นใจในการจำแนกประเภทไม่ใช่แบบไบนารี ข้อความ Slack ในช่องที่คุณไม่เคยเข้าชมอาจยังเร่งด่วนถ้ามันอ้างถึง issue ที่มอบหมายให้คุณ การแจ้งเตือน GitHub เกี่ยวกับ repo ที่คุณไม่ได้แตะมาหลายเดือนอาจสำคัญถ้ามีคนเพิ่งเปิดบักที่คุณคิดว่าแก้แล้วขึ้นมาใหม่ คุณต้องการสองชั้นที่ทำงานร่วมกัน: ชั้นปรับมาตรฐาน event ที่ hash webhook ขาเข้าแต่ละตัวตาม composite key – repo, issue ID, actor, event type – และตรวจสอบกับ TTL'd dedup window (โดยพื้นฐานคือ sliding window ของ event fingerprint ล่าสุด) และอยู่เบื้องหลังนั้น live relationship graph ที่แมป task ownership, PR linkage, thread participant และรูปแบบกิจกรรมล่าสุด คุณกำลังสร้าง read model ของสถานะการทำงานของทีมทั้งหมด อัปเดตแบบ near-real-time และ query ทุกสัญญาณขาเข้า ชั้น dedup ดักจับรายการซ้ำที่ชัดเจน กราฟตอบคำถามที่ยากกว่า: "สิ่งนี้เกี่ยวข้องกับคุณโดยเฉพาะ ตอนนี้ไหม?"
ลูปการจำแนกประเภทหลักจัดการกรณีที่ชัดเจนได้ดี และนั่นเพียงอย่างเดียวก็ลดเสียงรบกวนได้อย่างมาก – แต่สัญญาณที่คลุมเครือจริงๆ (ที่คุณไม่มั่นใจพอที่จะระงับแต่ก็ไม่มั่นใจพอที่จะแสดง) ยังคงเป็นปัญหาที่ยังเปิดอยู่ เรากำลังทดลองรวมสิ่งเหล่านี้เป็น "maybe" digest แต่ฉันจะไม่แกล้งทำเป็นว่าเราแก้ได้แล้ว
สิ่งที่เปลี่ยนไปเมื่อสายน้ำดับดิ้นหยุดไหล
สิ่งที่ฉันไม่คาดหวัง – ฉันคิดจริงๆ ว่าประโยชน์จะเป็นแค่ "การแจ้งเตือนน้อยลง" – คือความสัมพันธ์ของคุณกับเครื่องมือของคุณเปลี่ยนแปลงไปอย่างลึกซึ้งแค่ไหนเมื่อมันหยุดกรีดร้องใส่คุณ
เมื่อการแจ้งเตือนทุกรายการอาจสำคัญ คุณพัฒนาความวิตกกังวลระดับต่ำเกี่ยวกับจำนวนที่ยังไม่อ่าน แถบด้านข้างของ Slack ที่มีชื่อช่องตัวหนา กระดิ่ง GitHub กล่องข้อความ Linear คุณตรวจสอบแบบบีบบังคับ ไม่ใช่เพราะคุณคาดหวังอะไรเร่งด่วน แต่เพราะต้นทุนของการพลาดอะไรบางอย่างรู้สึกสูงกว่าต้นทุนของการตรวจสอบ 50 อย่างที่กลายเป็นเสียงรบกวน ฉันเคย alt-tab ไปที่ Slack ระหว่างการเขียน function signature กับ body ของมัน ไม่ใช่การตัดสินใจโดยตั้งใจ – แค่สัญชาตญาณ เหมือนที่คุณส่องกระจกที่ไฟแดง
การขัดจังหวะตัวเองล่วงหน้าอาจแย่กว่าการแจ้งเตือนเอง เพราะคุณกำลังทำลายสมาธิของตัวเองก่อนที่การแจ้งเตือนใดๆ จะมาถึง คุณอาศัยอยู่ในสถานะของความสนใจบางส่วนถาวร และคุณรู้สึกได้ในโค้ดที่คุณเขียน – รีวิวที่ตื้นกว่า ตัวเลือกสถาปัตยกรรมที่ปลอดภัยกว่า เส้นทางที่ต้านทานน้อยที่สุดแทนวิธีที่ถูกต้องจริงๆ เพราะคุณไม่เชื่อว่าคุณจะได้เวลา 45 นาทีที่ไม่ถูกขัดจังหวะเพื่อคิดมัน
เมื่อสายน้ำดับดิ้นหยุดไหล – เมื่อคุณเชื่อว่าสัญญาณสำคัญจะหาคุณเจอและเสียงรบกวนจะไม่ – สัญชาตญาณนั้นก็จางหาย ไม่ใช่ทันที เพราะนิสัยเก่าหัวแข็ง แต่ภายในสองสัปดาห์คุณสังเกตว่าคุณใช้เวลาในโปรแกรมแก้ไขโค้ดนานขึ้นโดยไม่ต้อง alt-tab แบบบีบบังคับ คุณเริ่มคิดจบ คุณเขียนโค้ดดีขึ้น ไม่ใช่เพราะคุณฉลาดขึ้นอย่างกะทันหัน แต่เพราะคุณหยุดอาสาทำการสลับบริบท 30 ครั้งต่อชั่วโมงในนามของระบบการแจ้งเตือนที่ไม่เคยขอให้คุณทำ
หยุดจมน้ำกับการแจ้งเตือน Sugarbug จำแนกทุกสัญญาณจาก Linear, GitHub และ Slack ตามความเกี่ยวข้อง – และแสดงเฉพาะสิ่งที่ต้องการคุณจริงๆ
Q: Sugarbug ช่วยลดการแจ้งเตือนที่ท่วมหัวจาก Linear, GitHub และ Slack ได้ไหม? A: ได้ Sugarbug เชื่อมต่อกับ Linear, GitHub และ Slack ผ่าน API และจำแนกทุกสัญญาณตามความเร่งด่วนและความเกี่ยวข้อง แทนที่จะส่งต่อการแจ้งเตือนทุกรายการ ระบบจะแสดงเฉพาะรายการที่ต้องการความสนใจจากคุณ – โดยทั่วไปลดการแจ้งเตือนหลายร้อยรายการต่อวันให้เหลือเพียงกำมือที่ต้องการคุณจริงๆ
Q: Sugarbug จัดลำดับความสำคัญการแจ้งเตือน GitHub PR ตามงานที่กำลังทำอยู่ได้ไหม? A: Sugarbug สร้างกราฟความรู้ของงาน PR และการสนทนาของคุณ ระบบรู้ว่า PR ใดเกี่ยวข้องกับงานปัจจุบันของคุณ และแสดงคำขอรีวิว ความขัดแย้งเมื่อรวมโค้ด และ CI ที่ล้มเหลวสำหรับ PR เหล่านั้นก่อน – ขณะที่จัดเก็บส่วนที่เหลือไว้อย่างเงียบๆ
Q: Sugarbug ต่างจากการตั้งค่าการแจ้งเตือนในตัวของ Slack อย่างไร? A: การตั้งค่าของ Slack ให้คุณปิดเสียงช่องทางหรือตั้งคำสำคัญได้ แต่ไม่สามารถเข้าใจบริบทข้ามเครื่องมือได้ Sugarbug อ่านข้อมูลจาก Linear, GitHub และ Slack พร้อมกัน จึงรู้ว่าเธรดใน Slack เกี่ยวกับ PR ที่คุณเขียนนั้นเร่งด่วน แม้จะอยู่ในช่องทางที่คุณปิดเสียงไว้
Q: ต้นทุนที่แท้จริงของการแจ้งเตือนล้นเกินสำหรับทีมวิศวกรคืออะไร? A: งานวิจัยของ Gloria Mark ที่ UC Irvine ชี้ว่าต้องใช้เวลาประมาณ 23 นาทีในการโฟกัสลึกอีกครั้งหลังจากถูกขัดจังหวะ นอกเหนือจากการแจ้งเตือนเอง พฤติกรรมการตรวจสอบแบบบีบบังคับที่เกิดขึ้นจะทำให้สมาธิที่ต่อเนื่องซึ่งงานวิศวกรรมที่ซับซ้อนต้องการนั้นแตกกระจาย
ถ้าการแจ้งเตือนของทีมวิศวกรของคุณข้ามเส้นจาก "รับรู้ข้อมูล" เป็น "รับรู้ความวิตกกังวล" นั่นอาจเป็นสัญญาณว่าสถาปัตยกรรมต้องการการแก้ไข ไม่ใช่การตั้งค่าการแจ้งเตือนของคุณ