Slack'te Eski Kararlar Nasıl Bulunur (Arama Yetmediğinde)
Slack araması yetmediğinde eski kararları nasıl bulunur. Kararlar neden kaybolur, karar günlükleri neden işe yaramaz ve iş akışı zekası nasıl fark yaratır.
By Ellis Keane · 2026-03-14
Hızlı bir soru: Ekibiniz polling yerine webhook kullanmaya nerede karar verdi? Ne kararlaştırdığınızı değil – o karar şu anda nerede yazılı, önümüzdeki ay katılacak birinin bulabileceği bir yerde?
Bizim gibi bir ekipseniz, dürüst yanıt "muhtemelen bir Slack thread'i" ile "sanırım #eng-backend'deydi, belki üç hafta önce, iki ya da üç kişinin dahil olduğunu düşünüyorum ama hangilerinin olduğunu gerçekten hatırlamıyorum" arasında bir yerlerdedir. Bunu düşününce ilginç bir durum ortaya çıkıyor: Söz konusu karar tüm sistemin nasıl çalıştığını değiştirecek kadar önemliydi, ancak görünüşe göre zaman damgasına göre sıralanmış bir bilinç akışının dışında bir yere not alınacak kadar önemli değildi. Slack'te eski kararları bulmaya çalışmanın özündeki sorun da bu – tüm bilgi orada, sadece onu bir karar olarak almanıza izin verecek şekilde düzenlenmiş değil.
Bir süredir Slack'te eski kararları nasıl bulacağımı araştırıyorum ve ne kadar derine inersem, temel sorunun disiplin ya da alışkanlık ya da insanların suçladığı diğer şeyler olmadığına o kadar inanıyorum. Sorun mimari. Slack'in araması mesajları bulmak için oluşturulmuş, kararlar ise mesaj değil – mesajlar aracılığıyla ifade edilen anlamlardır; bu ayrım, "webhook"un 17 kez geçtiği arama sonuçlarını ekibinizin gerçekten kullanmaya karar verdiği yeri bulmak için yirmi dakika kaydırarak geçirene kadar gereksiz bir ayrıntı gibi görünür.
Slack araması nasıl çalışır (ve nerede bozulur)
Bunu açıkça ortaya koymak gerekiyor çünkü "Slack araması kötü" doğru bir teşhis değil – Slack araması yaptığı şeyi oldukça iyi yapıyor. Sorun, yaptığı şey ile bir karar ararken ondan yapmasını istediğiniz şeyin temelden farklı iki şey olması.
Slack, mesajları meta verilerle birlikte metin olarak dizinler: zaman damgası, gönderen, kanal ve (ücretli bir planda iseniz) tam thread bağlamı. "Webhook" için arama yaptığınızda Slack, o kelimeyi içeren her mesajı güncellik ve alaka düzeyi kombinasyonuna göre sıralı olarak döndürür. Arama operatörleri ile kapsamı daraltabilirsiniz – in:#eng-backend from:@sarah before:2026-02-15 – ancak tek yaptığınız şey meta verilere göre aynı düz mesaj listesini filtrelemektir. Bu anahtar kelime erişimidir ve yarım hatırladığınız belirli bir mesajı bulmak için gayet iyi çalışır.
Ama karar bir anahtar kelime değildir. Bir karar, bir soru, bir dizi seçenek, bir grup insan ve grubun bir seçenekte uzlaştığı bir an arasındaki ilişkidir. Kararın gerçek metni "tamam, webhook yapalım, polling yöntemi rate limit'imizi mahvediyor" şeklinde olabilir – konuşma diliyle, bağlamsal ve ancak göründüğü thread'i zaten biliyorsanız anlamlı. Ya da "olur, prototype yapayım" şeklinde olabilir; bu ifade temsil ettiği teknik kararla ilgili sıfır anahtar kelime içerir.
İşte mimari uyumsuzluk bu: Slack mesajları kronolojik olarak depolar ve anahtar kelimeyle erişir. Kararlar semantiktir (anlam içerir) ve ilişkiseldir (görevler, kişiler ve sonuçlarla bağlantılıdır). Kronolojik bir depolama sisteminden semantik erişim yapmasını istiyorsunuz; bu mümkün değil çünkü sistem bunun için tasarlanmadı. "Aranabilir" ile "bulunabilir" arasındaki uçurum çok büyük – Slack geçmişinizdeki her mesaj teknik olarak aranabilir, ancak bu, ihtiyacınız olan kararın pratikte bulunabilir olduğu anlamına gelmiyor.
"Slack, tarihin en büyük kurumsal karar deposunu oluşturdu ve bunların neredeyse hiçbiri karar olarak erişilemiyor – her kelime mükemmel korunuyor ve neredeyse tamamen bulunamıyor." – Ellis Keane
Slack'te eski kararları bulmaya çalıştığınızda ne olur
Uyumsuzluk pratikte şu şekilde görünür. Diyelim ki ekibiniz üç hafta önce bir GitHub entegrasyonu için polling yerine webhook kullanmaya geçmeye karar verdi. Tartışmanın #eng-backend'de gerçekleştiğini ve birkaç mühendisi kapsadığını hatırlıyorsunuz. O kanalda "webhook" arıyorsunuz.
Geri gelenler: #eng-backend'de webhook'tan bahseden her mesaj. Altı ay önceki hata raporları. Tamamen farklı bir bağlamda webhook yeniden deneme mantığı soran biri. Birisinin webhook en iyi uygulamaları hakkında bir blog yazısına paylaştığı bağlantı (güzel bir ironi olarak, bu büyük olasılıkla arama sonuçlarında yanında oturduğu gerçek karardan daha yüksekte yer alıyor). Kararın kendisi – polling yaklaşımının rate limit'e çarptığını söyleyen birinin thread yanıtı – üçüncü sayfada bir yerde, etrafındaki her mesaja tıpatıp benzeyerek gömülü duruyor.
Bu da kullanılan kelimeleri kabaca hatırladığınız senaryo. Çoğu zaman kararlar o kadar bağlamsal bir dil kullanır ki neredeyse şifreli gibidir. "Seçenek B'ye gidelim" ifadesi "webhook" kelimesini hiç içermez, oysa seçenek B webhook'tu. "Olur, prototype yapayım" ifadesi "seçenek" kelimesini bile içermez. Kararın gerçek anı genellikle tüm thread'deki en kısa ve anahtar kelime açısından en fakir mesajdır çünkü o noktada konuşmadaki herkes zaten bağlamı anlıyor ve sadece uzlaşmayı onaylıyor.
Bunu bir bilgi mimarisi sorunu olarak gerçekten ilginç buluyorum (ilginç ve aynı zamanda aramayı yapan kişi sizseniz hafifçe sinir bozucu). Slack, tarihin en büyük kurumsal karar deposunu oluşturdu ve bunların neredeyse hiçbiri karar olarak erişilemiyor – her kelime mükemmel korunuyor, neredeyse tamamen bulunamıyor.
Karar günlükleri neden daha iyi tabelalarla bir mezarlıktır
Çözüm ararken karşılaşacağınız standart tavsiye karar günlüğü tutmaktır. Bir Notion veritabanı, özel bir Slack kanalı (bunu öneren kişilerin ironiyi fark etmediği görünüyor), bir wiki sayfası – kararların alındıkça kaydedildiği tek bir yer.
Bunu denedik. Yaklaşık altı hafta sürdü. İlk iki hafta harikaydı – herkes kararlıydı, girdiler ayrıntılıydı, günlük gerçekten işe yarıyordu. Üçüncü haftaya gelindiğinde girdiler seyrelmaya başladı. Beşinci haftada sadece bir kişi güncelliyordu; bağlantı, bağlam ve kimlerin dahil olduğuna ya da alternatiflerin ne olduğuna dair herhangi bir işaret olmaksızın "auth hakkında bir şeye karar verildi" gibi şeyler yazıyordu. Altıncı hafta sessizce vazgeçtik.
Sorun ekibimizin disiplinsiz olması değil (belki öyledir, ama bu asıl mesele değil). Sorun, karar günlüğünün tam yanlış anda bir "vergi" koyması. Üretken bir tartışma yaptınız, uzlaşmaya vardınız, biri inşa etmeye hazır – ve şimdi durmanız, başka bir araç açmanız, özet yazmanız, ilgili kişileri etiketlemeniz ve orijinal konuşmaya geri bağlantı vermeniz gerekiyor. Bu karar başına üç ila beş dakika ve kanallar ve thread'ler genelinde günde beş ila on anlamlı karar alan bir ekip için yük, kimsenin sahiplenmek istemeyeceği bir şeye dönüşüyor.
Ve sistem yalnızca %100 uyumda çalışır. Kararların %70'ini içeren bir karar günlüğü, bazı açılardan hiç günlük olmamasından daha kötüdür; çünkü artık iki yere bakıyor ve hiçbirine güvenmiyorsunuz. Günlüğe bakıyorsunuz, karar orada değil, yine de Slack'i arıyorsunuz – ve başladığınız yere döndünüz, üstelik önce günlüğü kontrol etmek için iki dakika harcadınız.
Kararlar olay değildir – gradyandır
Manuel günlük tutmanın başarısız olmasının nedenlerinden biri, kararların ayrı ve belirlenebilir anlar olduğunu varsaymasıdır. Gerçekte çoğu karar konuşmalar yoluyla kademeli olarak ortaya çıkar ve "karar anı" çoğunlukla gerçekten belirsizdir.
Tipik bir mühendislik kararının nasıl şekillendiğini düşünün. Biri Figma yorumunda bir endişeyi dile getirir: "bu etkileşim deseni mobilde çalışmayabilir." Bir mühendis orijinal yorumu etiketleyerek Slack thread'inde yanıt verir: "evet, baktım – bileşen kütüphanesi bunu desteklemiyor." Bir tasarımcı aynı thread'de alternatif bir yaklaşım önerir. Mühendis "olur, prototype yapayım" der. İki gün sonra alternatifi uygulayan bir PR açılır ve Linear issue güncellenir.
Karar nerede verildi? Sorunu ortaya koyan Figma yorumunda mıydı? Alternatifin önerildiği Slack thread'inde mi? Mühendis "olur" dediği anda mı? Onu uygulayan PR'da mı? Pratikte karar, iki araç ve üç gün boyunca bu dört anın hepsine dağılmıştı. Günlüğe alabileceğiniz bir olay değildi – bir sonuca dönüşen bir gradyandı ve bir karar alındığını bilmemizin tek nedeni kodun değişmesiydi.
Bu, "karar takibi" tavsiyelerinin çoğunun yanlış anladığı kısım bence. Kararları bir telefon numarasını not almak gibi yakalayabileceğiniz şeyler olarak ele alıyor. Ama çoğu gerçek karar sonradan yeniden inşa ettiğiniz şeylerdir – neyin değiştiğine bakarsınız, oraya giden konuşmaları geriye doğru izlersiniz ve gerekçeyi sonradan bir araya getirirsiniz. Bu da ihtiyacınız olan sistemin bir günlük değil, bir grafik olduğu anlamına gelir.
Grafiğin size günlüğün veremeyeceği şeyleri vermesi
Grafik, araçlar ve zaman boyunca sinyalleri birbirine bağlar. Birinin elle "rate limit nedeniyle webhook kullanmaya karar verdik" yazması yerine, grafik rate limit'lerin tartışıldığı Slack thread'ini, entegrasyon çalışmasını takip eden Linear issue'yu, webhook'ları uygulayan PR'ı ve konuşmaya dahil olan kişileri birbirine bağlar. Karar kaydedilmez – zaten gerçekleşmekte olan şeyler arasındaki bağlantılardan yeniden inşa edilebilir.
Pratik fark belirli bir senaryoda ortaya çıkar. Webhook kararından üç hafta sonra yeni bir mühendis katılır ve sorar: "GitHub için neden polling yerine webhook kullanıyoruz? Polling daha basit görünüyor." Bağlı bir sistem olmadan, biri "bunu bir süre önce kararlaştırdık" der, kimse hangi kanal olduğunu hatırlamaz, biri on beş dakika Slack'i arar ve ya bulur ya da (daha olası olarak) hafızadan gerekçeyi yeniden inşa eder; bu risklidir çünkü hafıza güvenilmezdir ve orijinal gerekçe üç hafta sonra herkesin hatırladığından neredeyse kesinlikle daha nüanslıydı.
Grafik sayesinde mühendis GitHub entegrasyon görevine bakar. O göreve dokunan her sinyal bağlantılıdır: rate limit'ler hakkındaki orijinal tartışma, polling ile webhook'ların değerlendirildiği thread, değişikliği uygulayan PR. Tam karar izi, baştan sona, kimse hiçbir şey aramadan ve kimse hiçbir şey kaydetmeden.
Uçurum "iyi arama" ile "kötü arama" arasında değil – anahtar kelimeyle erişim ile ilişkiyle erişim arasındadır. Kararlar görevler, kişiler ve sonuçlarla bağlantılarıyla tanımlanır, onları ifade etmek için kullanılan kelimelerle değil.
Hiçbir panoda görünmeyen maliyetler
Bu tür yumuşak maliyetler için kesin rakamlar iddia eden herkese dürüstçe şüpheyle bakıyorum ("ekipler haftada X saat harcıyor" türündeki istatistikler her zaman istenen sonuçtan tersine mühendislikle elde edilmiş gibi hissettiriyor), ancak kendi ekibimizde gözlemlediklerimiz şunlar.
En belirgin maliyet yeniden müzakeredir – orijinal kararı kimse bulamadığında ekipler onu yeniden açar; bazen insanlar gerçekten hatırlamadığı için, bazen de yeni bir ekip üyesinin kimsenin ayrıntılı yanıt veremediği meşru soruları olduğu için. Kararları kaynağına kadar izleme yolumuz olmadan önce çözülmüş soruları düzenli olarak yeniden müzakere ediyorduk ve her yeniden müzakerenin kendi maliyeti var: toplantı süresi, zaten çözüldüğünden oldukça emin olduğunuz bir şeyi tartışmanın duygusal yorgunluğu, orijinal gerekçenin herkesin hatırladığından daha nüanslı olduğuna dair rahatsız edici şüphe.
Daha ince maliyet ise işe alım sürecinde yaşananlar. Yeni bir ekip üyesinin "bu neden böyle yapıldı?" sorusu, orijinal kararda bulunan birini her seferinde aksatır ve cevap her sorulduğunda hafızadan yeniden inşa edilir; her anlatımda orijinal gerekçeden biraz daha uzaklaşır – kurumsal yazılımın telefon olduğu ve mesajın "mimari neden böyle çalışıyor" olduğu bir kulaktan kulağa oyunu gibi. Ve zamanla birikim gösteren bir güvenilirlik açığı var: "webhook'ları tercih ettik" ifadesi, "polling GitHub API rate limit'imizin %40'ını tükettiği ve yoğun saatlerde throttling ile karşılaştığımız için webhook'ları tercih ettik" ifadesinden daha az ağırlık taşır. Gerekçe, gelecekteki mühendislerin değişen koşullar altında bir kararın hâlâ geçerli olup olmadığını değerlendirmesini sağlayan şeydir ve bu gerekçe mükemmel korunmuş, pratikte görünmez halde bir Slack thread'inde bir yerlerde duruyor.
Kararlarınızın Slack kaydırmasında kaybolmasını durdurun. Sugarbug, Slack thread'inden Linear issue'ya, PR'a kadar tam karar izini otomatik olarak takip eder.
Q: Slack'te eski kararları bulmak neden bu kadar zor? A: Slack mesajları kronolojik olarak depolar, anlam bazında değil. Bir thread'e gömülü karar, diğer tüm yanıtlarla birebir aynı görünür – Slack araması anahtar kelimeleri eşleştirebilir, ancak tam konuşma bağlamını okumadan "Redis kullanmaya karar verdik" ile "Redis kullansak mı?" arasındaki farkı ayırt edemez. Ne kadar zaman geçerse bulmak o kadar zorlaşır çünkü aramayı ilk etapta uygulanabilir kılan bağlamsal ipuçlarını (kimlerin dahil olduğu, hangi kanal, hangi hafta) kaybedersiniz.
Q: Sugarbug, Slack'te alınan kararları otomatik olarak takip ediyor mu? A: Evet. Sugarbug, Slack'ten ve bağlı diğer araçlardan gelen sinyalleri sınıflandırır; görevlere atıfta bulunan, atanan kişileri kapsayan ve durum değişikliklerine ya da PR'lara yol açan thread'ler gibi karar benzeri desenleri belirler. Bunlar bilgi grafiğindeki ilgili görevle ilişkilendirilir, böylece Slack geçmişini aramak yerine görevden karar izini takip edebilirsiniz.
Q: Karar günlüğü ile kararlar için bilgi grafiği arasındaki fark nedir? A: Karar günlüğü, her kararın gerçekleşirken birisi tarafından elle kaydedilmesini gerektirir – fark edilmesi, duraklanması, özetlenmesi, etiketlenmesi, bağlantı verilmesi. Bilgi grafiği, araçlarınızdan akan sinyallerden kararları çıkarır ve bunları görevler, kişiler ve konuşmalarla otomatik olarak ilişkilendirir. Biri her ekip üyesinden tutarlı disiplin gerektirir; diğeri zaten gerçekleşen faaliyetten arka planda çalışır.
Q: Sugarbug, Slack dışındaki araçlardan gelen kararları da ortaya çıkarabilir mi? A: Sugarbug; Slack, GitHub, Figma, Linear, Notion, e-posta ve takvimlerle bağlantı kurar. Kararlar genellikle birden fazla aracı kapsar (Figma yorumu bir Slack thread'ine, o da bir PR'a yol açar) ve bilgi grafiği sinyalleri tüm bağlı yüzeylerde birbirine bağlar. Konuşmanın hangi araçta başladığından bağımsız olarak tam izi görürsünüz.
Q: Bu, Slack'in yerleşik aramasını kullanmaktan nasıl farklı? A: Slack araması belirli anahtar kelimeleri içeren mesajları bulur. Bilgi grafiği mesajlar, görevler ve kişiler arasındaki ilişkileri bulur. Bir karar ararken nadiren bir kelime ararsınız – bir ekibin bir yaklaşımı diğerine tercih ettiği anı ararsınız ve bu an, onu ifade etmek için kullanılan kelimelerle değil, diğer sinyallerle olan bağlantılarıyla tanımlanır.
---
Kararlar Slack geçmişinizde kaybolmaya devam ediyorsa sorun Slack değil – önemli anları izleyen ve onları şekillendirdikleri çalışmayla ilişkilendiren hiçbir sistemin olmamasıdır. Sugarbug'u inşa ederken doldurmaya çalıştığımız boşluk tam da bu.