Uyarı En İyi Uygulamaları

İyi tasarlanmış bir bildirim stratejisi, takımınızı bunaltmadan bilgilendirir. Çok az uyarı ve kritik güncellemeler kaçırılır. Çok fazla uyarı ve insanlar bildirimleri tamamen görmezden gelmeye başlar. Bu rehber, takımınızın güveneceği ve dayanacağı bir bildirim sistemi oluşturmak için pratik önerileri kapsar.

Tetikleyici stratejinizi tasarlama

Olayları aciliyetlerine göre sınıflandırın

Her olay aynı bildirim işlemini hak etmez. Kullanılabilir 16 olay türünü üç katmana ayırarak başlayın:

Katman	Aciliyet	Önerilen kanallar	Örnek olaylar
Kritik	Anında eylem gerektirir	Uygulama içi + E-posta + SMS	due_date_passed, priority_changed (Acil'e)
Önemli	Saatler içinde görülmeli	Uygulama içi + E-posta	state_changed, assignee_changed, mentioned, comment_added
Bilgilendirici	Bilmesi iyi, aciliyeti yok	Yalnızca uygulama içi	label_changed, property_changed, link_changed, archive_changed

Bu katmanlı yaklaşım, en acil olayların en fazla dikkat çekmesini sağlarken daha düşük öncelikteki güncellemeler gürültü oluşturmadan erişilebilir kalır.

Daha az tetikleyiciyle başlayın

Uyarıları ilk kez kurarken, her olay türü için tetikleyici oluşturma cazibesine karşı koyun. Küçük bir yüksek değerli tetikleyici setiyle başlayın ve takım geri bildirimlerine göre genişletin.

Önerilen başlangıç tetikleyicileri:

1. due_date_passed --- Atanan kişileri geciken iş öğeleri hakkında bilgilendir.
2. state_changed koşul "Durum İncelemede" --- İş hazır olduğunda incelemecileri bilgilendir.
3. mentioned --- Yorumlarda bahsedilen kullanıcıları bilgilendir.
4. assignee_changed --- Yeni atanan kişiyi ataması hakkında bilgilendir.

Bu dört tetikleyici en yaygın sorunlu noktaları kapsar: kaçırılan son tarihler, inceleme darboğazları, görmezden gelinen bahsetmeler ve onaylanmamış atamalar. Takım belirli eksiklikleri tanımladığında daha fazla tetikleyici ekleyin.

Kapsamı daraltmak için koşulları kullanın

Koşulsuz bir tetikleyici, çalışma alanındaki eşleşen her olayda tetiklenir. Neredeyse hiç istenen durum bu değildir. Önemli olan bildirimleri hedeflemek için koşulları kullanın:

Bunun yerine...	Bunu kullanın...
Koşulsuz state_changed (her durum değişikliğinde tetiklenir)	Koşullu state_changed "Durum İncelemede" (yalnızca incelemeye girdiğinde tetiklenir)
Koşulsuz priority_changed (her öncelik değişikliğinde tetiklenir)	Koşullu priority_changed "Öncelik Acil" (yalnızca kritik eskalasyonlarda tetiklenir)
Koşulsuz issue_created (her yeni iş öğesinde tetiklenir)	Koşullu issue_created "Etiket Hata içeriyor" (yalnızca yeni hatalar için tetiklenir)

Genel olaylar yerine spesifik olayları tercih edin

property_changed olayı, bir iş öğesindeki neredeyse her değişiklikte tetiklenir. Genel yakalayıcı olarak yararlıdır ancak hedefli olaylardan önemli ölçüde daha fazla bildirim üretir. İlgilendiğiniz özellik için belirli bir olay türü varsa, onu kullanın:

Genel yaklaşım	Daha iyi yaklaşım
Koşullu property_changed "Öncelik değişti"	priority_changed
Koşullu property_changed "Atanan değişti"	assignee_changed
Koşullu property_changed "Durum değişti"	state_changed

property_changed'ı, 15 spesifik olay türü tarafından karşılanmayan uç durumlar için saklayın.

Bildirim yorgunluğunu önleme

Bildirim yorgunluğu, herhangi bir uyarı sisteminin birincil riskidir. Kullanıcılar çok fazla bildirim aldığında, "bildirim körlüğü" geliştirir ve kritik olanlar dahil uyarılara dikkat etmeyi bırakırlar.

Bildirim yorgunluğu belirtileri

• Takım üyeleri çoğu olay için e-posta veya SMS'i devre dışı bırakır.
• Bildirim paneli (zil simgesi) sürekli yüksek okunmamış sayıları gösterir.
• Kullanıcılar "çok fazla" olduğu için bildirimleri görmezden geldiklerini bildirir.
• Önemli uyarılar doğru teslim edilmesine rağmen kaçırılır.

Önleme stratejileri

1. Daha az tetikleyici, daha fazla tetikleyiciden iyidir. Her ek tetikleyici, çalışma alanı genelindeki bildirim hacmini artırır. Her tetikleyicinin net bir gerekçesi olmalıdır.

2. Yayın değil, alıcı hedefleme kullanın. Tüm çalışma alanı üyelerini bilgilendiren tetikleyicilerden kaçının. Bildirimleri harekete geçmesi gereken kişilere hedefleyin: atananlar, oluşturucular veya belirli rol sahipleri.

Yaklaşım	Hacim etkisi
Alıcılar: Tüm çalışma alanı üyeleri	Yüksek (olay başına N bildirim, N = üye sayısı)
Alıcılar: Atananlar + Oluşturucu	Düşük (olay başına 1-3 bildirim)
Alıcılar: Belirli kullanıcılar (rol tabanlı)	Düşük (olay başına 1-5 bildirim)

3. Kullanıcıların tercihlerini kontrol etmesine izin verin. Takım üyelerine, yararlı bulmadıkları olaylar için kanalları devre dışı bırakabileceklerini hatırlatın. Tercihler sayfası her kullanıcıya bildirim deneyimleri üzerinde tam kontrol sağlar.

4. Tetikleyici hacmini periyodik olarak denetleyin.Geçmiş sayfasını aylık olarak inceleyin. Tek bir tetikleyici orantısız bir bildirim payından sorumluysa, kapsamını daraltmak için koşullar eklemeyi veya devre dışı bırakmayı düşünün.

5. Silmek yerine devre dışı bırakın. Bir tetikleyici çok fazla gürültü üretiyorsa, geçici olarak devre dışı bırakın ve takımın bildirimleri kaçırıp kaçırmadığını gözlemleyin. Kimse farketmezse, tetikleyici değer sağlamıyordu demektir.

SMS kullanım önerileri

SMS, en kesintiye uğratıcı bildirim kanalıdır. Kısa mesajla titreşen bir telefon, e-posta ve uygulama içi bildirimlerin yapamadığı bir şekilde anında dikkat talep eder. Dikkatli kullanın.

SMS ne zaman kullanılır

Senaryo	SMS için uygun mu
İş öğesi gecikti ve size atanmış	Evet
İş öğenizde engelleyici oluşturuldu	Evet
Kritik yoldaki bir öğede öncelik Acil'e yükseldi	Evet
Takip ettiğiniz bir iş öğesine yorum eklendi	Hayır
Bir iş öğesinde etiket değiştirildi	Hayır
Projenizde yeni bir iş öğesi oluşturuldu	Hayır

SMS yönergeleri

• Kullanıcı başına 1-3 olay türüyle sınırlı tutun. Bir kullanıcının üçten fazla olay türü için SMS'i etkinleştirmiş olması, muhtemelen aşırı bildirim aldığını gösterir.
• SMS'i koşullarla birleştirin. Her priority_changed olayında SMS göndermeyin --- yalnızca yeni öncelik Acil olduğunda.
• Kişisel zamana saygı gösterin. SMS bildirimleri her saatte gelir. Takımınız birden fazla saat dilimini kapsıyorsa, hangi olayların SMS tetikleyeceğine dikkat edin.
• SMS maliyetlerini izleyin. Her SMS mesajının bir maliyeti vardır (Twilio veya webhook sağlayıcınız). Yüksek hacimli SMS pahalıya gelebilir. SMS hacmini Geçmiş sayfasında düzenli olarak inceleyin.

Önerilen SMS yapılandırması

Olay türü	SMS önerisi	Koşul
due_date_passed	Evet	Yalnızca atanan
priority_changed	Evet	Yalnızca öncelik Acil olduğunda
state_changed	Duruma bağlı	Yalnızca engelleyici durumları için
Diğer tüm olaylar	Hayır	---

Durum eşleme kalıpları

Durum eşlemeleri, iyi tanımlanmış aşamalara sahip iş akışları için güçlüdür. Pratikte iyi çalışan kalıpları aşağıda bulabilirsiniz.

Doğrusal inceleme hattı

Doğrusal iş akışına sahip takımlar için (Geliştirme - İnceleme - KG - Tamamlandı):

Kaynak durum	Hedef durum	Alıcılar	Amaç
Devam Ediyor	İncelemede	Kod incelemecileri	İncelemeci devralma
İncelemede	KG Testi	KG takımı	KG devralma
KG Testi	Dağıtıma Hazır	DevOps lideri	Dağıtım kuyruğu farkındalığı
Herhangi	Tamamlandı	Oluşturucu, Aboneler	Tamamlanma bildirimi

Eskalasyon kalıbı

Öğeler engellendiğinde eskalasyona ihtiyaç duyan takımlar için:

Kaynak durum	Hedef durum	Alıcılar	Amaç
Herhangi	Engellendi	Atanan, Proje yöneticisi	Anında eskalasyon
Engellendi	Devam Ediyor	Atanan	Engelleyici çözümü onayı

Sürüm yönetimi

Sürüm döngülerini yöneten takımlar için:

Kaynak durum	Hedef durum	Alıcılar	Amaç
Herhangi	Sürüm İçin Hazır	Sürüm yöneticisi	Sürüm aday kuyruğu
Sürüm İçin Hazır	Sürüldü	Oluşturucu, Aboneler	Sürüm onayı

Eşlemeleri odaklı tutun

• Eşlemeleri yalnızca insan eylemi veya farkındalığı gerektiren geçişler için oluşturun.
• Her durum geçişinin eşlemeye ihtiyacı yoktur. Rutin geçişler (örneğin "Bekleme Listesi" iken "Yapılacak") nadiren bildirim gerektirir.
• Mümkün olan her geçiş için eşleme oluşturduğunuzu farkediyorsanız, muhtemelen aşırı yapılandırıyorsunuz. Bildirimin değer kattığı geçişlere odaklanın.

Şablon kullanım ipuçları

SetGet 21 sistem şablonu sunar. Bunları etkili kullanma ipuçları:

Şablonları bağlamla eşleştirin

Her tetikleyici için her zaman en spesifik şablonu kullanın. Durum Değişikliği şablonu, genel Özellik Değişikliği şablonunun sahip olmadığı önceki ve yeni durum bağlamını içerir. Benzer şekilde, Öncelik Uyarısı şablonu öncelik düzeyi değişikliğini belirgin şekilde vurgular.

Etkinleştirmeden önce önizleyin

Bir tetikleyiciyi etkinleştirmeden önce her zaman şablonları önizleyin. Konu satırı, gövde ve değişken değiştirmenin açık ve eyleme dönüştürülebilir bir bildirim oluşturduğunu doğrulayın.

Gerçek alıcılarla test edin

Canlı olmadan önce kendinize test bildirimi gönderin. Bu, yalnızca önizlemenin ortaya çıkaramayacağı biçimlendirme sorunlarını, bozuk bağlantıları ve teslimat problemlerini yakalar.

Eylemi net tutun

En iyi bildirimler tek bir açık eyleme sahiptir: "Bu iş öğesini inceleyin," "Bu engelleyiciyi çözün," "Bu sürümü dağıtın." Bir bildirim açık bir eylem önermiyorsa, muhtemelen bilgilendiricidir ve yalnızca uygulama içi kullanılmalıdır.

Teslimat sağlığını izleme

Bildirim sistemi yalnızca bildirimler gerçekten teslim edilirse yararlıdır. Teslimat sağlığını proaktif olarak izleyin.

İzlenecek temel metrikler

Metrik	Sağlıklı aralık	Uyarı işareti
Başarı oranı (panodan)	%95+	%90'ın altında sistemik teslimat sorununu gösterir
Günlük başarısız gönderim	0-5	10'dan fazla yapılandırma sorununu gösterir
5 dakikadan eski bekleyen gönderimler	0	5 dakikadan eski herhangi bir bekleyen gönderim kuyruk sorununu gösterir
SMS başarısızlık oranı	%5'in altında	Daha yüksek oranlar telefon numarası veya sağlayıcı sorunlarını gösterir

Haftalık gözden geçirme kontrol listesi

Uyarı sistemi sağlığınızın kısa bir haftalık gözden geçirmesini yapın:

• [ ] Başarı oranı eğilimleri için istatistik panosunu kontrol edin.
• [ ] Geçen hafta için Geçmiş'i Durum: Başarısız ile filtreleyin.
• [ ] Tekrarlayan başarısızlık kalıplarını araştırın (aynı alıcı, aynı kanal, aynı hata).
• [ ] SMS bakiyesinin (Twilio) gelecek hafta için yeterli olduğunu doğrulayın.
• [ ] Takım üyelerine bildirimleri bekledikleri gibi alıp almadıklarını sorun.

Teslimat sorunlarına yanıt verme

Teslimat sorunları tespit ettiğinizde:

1. Kanalı izole edin. Başarısızlıklar e-postada mı, SMS'te mi yoksa her ikisinde mi?
2. Kimlik bilgilerini kontrol edin. SMTP ve SMS sağlayıcı kimlik bilgileri süresi dolmuş veya değiştirilmiş olabilir.
3. Test gönderin. Kanalın çalıştığını doğrulamak için şablon test özelliğini kullanın.
4. Sağlayıcıyı kontrol edin. E-posta için SMTP sunucu durumunu kontrol edin. SMS için Twilio panosunu veya webhook uç noktası sağlığını kontrol edin.
5. Son değişiklikleri inceleyin. Birisi SMTP ayarlarını, SMS sağlayıcısını veya ağ yapılandırmasını değiştirdi mi?

Ölçekleme değerlendirmeleri

Çalışma alanınız üye ve iş öğesi sayısında büyüdükçe, bildirim hacmi orantılı olarak ölçeklenir. Bu büyümeyi planlayın.

Hacim tahmini

Çalışma alanı boyutu	Tahmini günlük olay	Tahmini bildirimler (hedefleme ile)
5-10 üye	50-200 olay	100-500 bildirim
10-50 üye	200-1.000 olay	500-3.000 bildirim
50-200 üye	1.000-5.000 olay	3.000-15.000 bildirim
200+ üye	5.000+ olay	15.000+ bildirim

Ölçekleme ipuçları

• Takım büyüdükçe koşulları sıkılaştırın. 10 kişilik takım için çalışan geniş tetikleyiciler, 50 kişi için dayanılmaz hacim üretebilir.
• Rol tabanlı alıcılar kullanın. Çok sayıda belirli kullanıcı eklemek yerine, doğru kişileri otomatik olarak hedefleyen alıcı türlerini (Atananlar, Oluşturucu, Aboneler) kullanın.
• Tetikleyici sayısını inceleyin. Bir çalışma alanı nadiren 20-30'dan fazla aktif tetikleyiciye ihtiyaç duyar. Daha fazlanız varsa, konsolidasyon fırsatları arayın.
• Kuyruk işlem süresini izleyin. Geçmiş'teki "Beklemede" ve "Gönderildi" zaman damgaları arasındaki fark büyürse, bildirim kuyruğu dikkat gerektirebilir.

Kaçınılması gereken yaygın hatalar

Hata	Neden sorun	Bunun yerine ne yapmalı
Her olay türü için tetikleyici oluşturmak	Bildirim seli, kullanıcılar her şeyi görmezden gelir	4-5 yüksek değerli tetikleyiciyle başlayın ve ihtiyaca göre genişletin
Alıcı olarak "Tüm çalışma alanı üyeleri" kullanmak	Herkes her şey için bilgilendirilir	Atananlar, Oluşturucu veya belirli rol sahiplerini hedefleyin
Bilgilendirici olaylar için SMS etkinleştirmek	Kullanıcıları gereksiz yere rahatsız eder, maliyet oluşturur	SMS'i yalnızca kritik ve acil olaylar için saklayın
Şablonları etkinleştirmeden önce test etmemek	Bozuk biçimlendirme veya teslimat üretimde keşfedilir	Her zaman canlı olmadan önce önizleyin ve test gönderin
Geçmiş sayfasını görmezden gelmek	Teslimat başarısızlıkları farkedilmez	Başarısız gönderimler için Geçmiş'i haftalık inceleyin
Aynı olay için yinelenen tetikleyiciler oluşturmak	Kullanıcılar tek olay için birden fazla bildirim alır	Birleştirilmiş alıcılarla tek bir tetikleyiciye konsolide edin
Tetikleyici etkinliğini hiç gözden geçirmemek	Eskimiş tetikleyiciler değer olmadan gürültü üretir	Tetikleyicileri üçaylık denetleyin ve kullanılmayanları devre dışı bırakın

İlgili sayfalar

• Uyarılara genel bakış --- Uyarı sistemine giriş
• Tetikleyiciler --- Olay tabanlı bildirim tetikleyicilerini yapılandırın
• Şablonlar --- E-posta şablon kataloğu ve değişken referansı
• Durum eşlemeleri --- Durumdan duruma geçiş uyarıları
• SMS yapılandırması --- SMS teslimat sağlayıcıları yapılandırın
• Bildirim tercihleri --- Kullanıcı başına kanal yapılandırması
• Uyarı geçmişi --- Gönderim günlüklerini ve teslimat durumunu görüntüleyin
• Otomasyonlar --- Otomatik iş akışları için tetikleyici-eylem kuralları