Home | Blog | Rehber

Takımınız 5 Araç Kullanırken Kararlar Nasıl Takip Edilir

Araçlar arasında dağılan kararları nasıl takip edersiniz – Slack, Notion, Linear ve PR'larda – ve neden karar günlükleri sizi kurtarmaz.

By Chris Calo · 2026-03-13

"Bunu zaten karara bağlamıştık değil mi?"

Aramada beş kişi. Kimse cevap vermiyor. Biri mikrofon açıyor ve bunun birkaç hafta önce bir Slack thread'inde gündeme geldiğini düşündüğünü söylüyor, belki #engineering'de, belki de #backend'de. Tasarımcımız bir Notion yorumunu bulanık hatırlıyor. Mühendislerimizden biri – kapalı ya da arşivlenmiş ya da başka bir projeye taşınmış olabilecek bir issue'daki yorumu aramak için – zaten Linear'a bakıyor.

Söz konusu karar: ilerleyen dönemde hangi API sürümleme şemasını kullanacağımız. Şirketi ayakta tutacak ya da batıracak bir karar değil. Mimari bir uçurum da değil. Araçlar arasında kararları nasıl takip edeceğimize dair sade bir karar – daha doğrusu, kesinlikle ve kanıtlanabilir biçimde alınmış olan, şimdi ise birbirleriyle konuşmayan beş araç arasındaki boşlukta buharlaşıp giden tek bir kararı nasıl bulacağımıza dair.

Suç mahallini yeniden oluşturayım.

Kayıp bir kararın adli zaman çizelgesi

İşte gerçekte neler olduğu, sonradan bir araya getirilmiş haliyle (çünkü elbette sonunda hepsini buldum – yaklaşık bir saat sürdü, bu da bir Çarşamba öğleden sonrasının verimli kullanımı gibi hissettirdi).

1. Gün, 10:14 – Mühendislerimizden biri #engineering'de "API Versioning Options" başlıklı bir Notion dokümanı paylaşıyor. Üç seçenek, her biri için artılar ve eksiler. Temiz biçimlendirme. İyi düşünülmüş. Takımın işini bilen biri olduğunu hissettiren türden bir belge.

1. Gün, 10:22 – Paylaşılan link altındaki Slack thread'inde tartışma başlıyor. İlk yirmi dakikada altı yanıt. Geriye dönük uyumluluk, istemci SDK'sı etkileri ve başlık tabanlı sürümlemenin hata ayıklama zahmetine değip değmeyeceği hakkında gerçek ve yararlı bir konuşma. Ayrıca dördüncü yanıt civarında öğle yemeğinin nerede yeneceğine dair kısa bir sapma (bu, sürümleme tartışmasından daha hızlı fikir birliğine ulaştı).

1. Gün, 11:47 – Sessizce izleyen tasarımcımız tek satırlık bir mesaj atıyor: "path versioning, API explorer'ı okunabilir tutar, sadece /v2/ yapalım." İki beğeni. İtiraz yok. Karar verildi.

1. Gün, 14:30 – Bir takım arkadaşı sonucu API refactor issue'sunun Linear yorumuna özetliyor. İyi bir içgüdü. Ama pratikte, bir issue kapatıldığında Linear yorumları işlevsel olarak görünmez hale geliyor.

8. Gün – /v2/ uygulayan PR merge ediliyor. PR açıklaması Linear issue'ya numarasıyla atıfta bulunuyor ama sürümleme kararından ya da bunun gerçekleştiği Slack thread'inden hiç bahsetmiyor. Son derece normal. Kimse bir PR açıklamasına "bu arada, işte bu kararın tam soy ağacı" yazmıyor; çünkü kimse böyle bir zorunluluk duymaz.

43. Gün – Yeni biri ilgili bir ticket alıyor ve soruyor: "Path versioning mi yapıyoruz, başlık versioning mi?" Notion dokümanı? Sonuçla hiç güncellenmedi. Slack thread'i? Altı haftalık mesajların altında gömülü. Linear yorumu? Kimsenin aramayı düşünmediği kapalı bir issue üzerinde. PR? Var olduğunu bilmeden bulamazsınız.

Ve böylece beş kişi bir aramada oturuyor, birbirlerine bakıyor, altı hafta önce zaten çözüme kavuşturulmuş bir kararı yeniden türetmeye çalışıyor. İlerleme.

title: "Bir Karar, Altı Hafta, Beş Araç"

Gün, 10:14|ok|"API Versioning Options" Notion doc'u #engineering'de paylaşıldı; üç seçenek
Gün, 10:22|ok|Slack tartışması başladı; geriye dönük uyumluluk ve SDK hakkında verimli tartışma
Gün, 11:47|ok|Karar alındı: path versioning, /v2/
Gün, 14:30|amber|Sonuç Linear yorumunda özetlendi; kapalı issue = zayıf keşfedilebilirlik
Gün|amber|/v2/ PR'ı merge edildi; açıklama issue'yu referans alıyor ama kararı değil
Gün|missed|Yeni geliştirici soruyor: "path mı header mı?" – cevap mevcut; kimse bulamıyor

Kararların gittiği yer

Şu var ki, hiçbir araç başarısız olmadı. Slack tam olarak Slack'in yaptığını yaptı. Notion dokümanı güzelce tuttu. Linear issue'yu takip etti. GitHub kodu merge etti. Her araç kendi başına kusursuz çalıştı – bu, iltifat gibi görünen ama aslında teşhis olan türden bir gözlem.

| Nerede gerçekleşti | Neden sonradan bulunamıyor | |---|---| | Slack thread | Altı hafta önce birinin kullandığı tam kelimeleri hatırlamanız gerekiyor. Bol şans. | | Linear yorumu | Kapalı issue'lardaki yorumlar okyanus tabanına kazınmış gibi | | Notion dokümanı | Doküman var, ama kimse sonuçla güncellemedi, çünkü insanlar böyle | | GitHub PR | Konuşmalar merge sonrası çöküyor – hangi PR'ı kazmak gerektiğini bilmeniz lazım | | Toplantı (sözlü) | Biri not almadığı ve bir yere koymadığı sürece tamamen yok | | E-posta zinciri | Makul arama, ama sadece doğru zincirdeyseniz |

Altı araç. Altı arama motoru. Sıfır paylaşılan bellek.

Her araç kendi başına kusursuz çalıştı – bu, iltifat gibi görünen ama aslında teşhis olan türden bir gözlem. attribution: Chris Calo

Karar günlüğü: güzel bir ceset

Eğer başınızı sallayarak okuyorsanız, muhtemelen Sezgiyi yaşadınız. "Bir Karar Günlüğü oluşturayım" diye düşündüğünüz şu. Tarih, Karar, Bağlam, Paydaşlar ve Durum sütunlarıyla mükemmel bir Notion veritabanı. Takım kanalında duyuruyorsunuz. İlk üç kaydı özenli ayrıntılarla kendiniz ekliyorsunuz ve gerçekten harika hissettiriyor.

Şimdiye kadar tam olarak bu eseri üç şirkette oluşturdum (ve evet, aynı başarısız deneyi tekrar tekrar yapıp farklı sonuç beklemesinin klinik bir adı olduğunun farkındayım). Her seferinde kesinlikle işe yarayacağına emindim. "Bu sefer disiplinli olacağız!" Olmadık. Siz de olmayacaksınız. Bunu zalimce söylemiyorum – bunu söylüyorum çünkü başarısızlık biçimi tasarıma gömülü.

İşte olan bu. Birinci hafta: mükemmel. İkinci hafta: büyük ölçüde dolu. Üçüncü hafta: biri Slack DM'inde hızlı bir karar veriyor ve günlük hiçbir şey duymuyor. Dördüncü hafta: bir review yorumuna gömülü örtük mimari kararla bir PR merge ediliyor ve kimse onu aktarmayı düşünmüyor. Beşinci hafta: biri tatilde, kalan takım öğle yemeğinde bir şeye karar veriyor (öğle yemeği sapması yeniden vurdu) ve günlük sessizliğe gömülüyor.

Altıncı haftaya gelindiğinde Karar Günlüğünüz bir anıt oluyor. İyi niyetlere adanmış zarif bir anıt, Notion kenar çubuğunuzda oturuyor, dokunulmamış, dijital toz biriktiriyor. Üç tanesim var. Muhteşemler. Aynı zamanda tamamen işe yaramıyorlar.

Karar günlükleri takımlar disiplinsiz olduğu için değil, insanlardan bir anın önemli olduğunu o an yaşanırken fark etmelerini, duraklamalarını, bir belgeleme aracına bağlam değiştirme yapmalarını ve altı hafta sonra işe yarayacak kadar ayrıntılı biçimde yazmalarını istediği için başarısız olur. Bu, gerçek işlerle meşgul insanlardan istemek için saçmalık derecesinde zor bir şeydir.

Araçlar arasında kararları gerçekten nasıl takip edersiniz

Manuel günlükler insan doğası yüzünden başarısız oluyor. Araç başına arama, parçalanma yüzünden başarısız oluyor. Gerçekten işe yarayan şey, araçlarınızın tam yüzey alanını izleyen ve kimsenin yaptığı şeyi durdurmak zorunda kalmadan noktaları birleştiren bir şey.

Pratikte bu dört şey anlamına geliyor:

Otomatik veri toplama. Araçlarınızdan gelen her sinyal – Slack mesajları, Linear yorumları, PR incelemeleri, Notion güncellemeleri, toplantı transkriptleri – kimse parmağını kaldırmadan yakalanıyor. Çalışmaya devam ediyorsunuz. Sistem izlemeye devam ediyor. Kimsenin düşüncesinin ortasında durup bir elektronik tablo açıp az önce olanı kaydetmesi gerekmiyor (ki oluşturduğumuz üzere zaten kimse yapmıyor).

Sınıflandırma. Her mesaj bir karar değil. Çoğu durum güncellemesi, soru veya gürültü. Sistemin "path mı header versioning mi kullanalım?" (bir soru), "sadece /v2/ yapalım" (bir karar) ve "/v2/ endpoint'i devreye alındı" (bir durum güncellemesi) arasındaki farkı söylemesi gerekiyor. Burada bir LLM sınıflandırıcısı değerini kanıtlıyor – yanlışsız olmasa da. "Evet o olsun" ifadesinin gerçekte biri kahve içmeyi kabul ettiğinde büyük bir karar olarak işaretlendiği unutulmaz bir dönem yaşadık. Güven puanını doğru ayarlamak için zamansal bağlam ve gönderen rolü ağırlığına ihtiyaç duyulduğu ortaya çıktı.

Bağlama. Bu, "daha iyi arama"yı gerçek karar takibinden ayıran kısım. Bir Slack thread'indeki karar, bir GitHub PR'ı üretmiş bir Linear issue'suyla ilgili olduğunda – bu bağlantıların var olması gerekiyor çünkü sistem referansları izledi (issue ID'leri, PR numaraları, thread URL'leri, zamansal yakınlık), kimse bunları el ile özenle çizmediği için değil. Notion dokümanı, Slack thread'i, Linear yorumu ve PR'ın hepsinin otomatik olarak birbirine işaret etmesi gerekiyor, çünkü olan bu.

Erişim. "API versioning kararı" diye aradığınızda, tam izi geri alıyorsunuz – ilk aradığınız araç değil. Seçeneklerin yer aldığı Notion dokümanı, kararın verildiği Slack thread'i, onu özetleyen Linear yorumu ve onu uygulayan PR. Hepsi bağlantılı. Hepsi kimse tek bir günlüğe tek bir kayıt girmeden.

Şu anda deneyebileceğiniz iki şey (gerçekten, hiçbir koşul yok):

#decisions kanalı. Slack'te bir tane oluşturun ve takımınızdan başka bir yerde bir şey kararlaştırıldığında oraya kısa bir mesaj atmalarını isteyin. Manuel ve bir ay içinde çürüyecek (bu konudaki güvenilirliğimi kanıtladım), ancak kısmi ve çürüyen bir günlük bile parçalı iletişim örüntüsünü acı verici biçimde görünür kılıyor.

PR açıklaması alışkanlığı. Bir kararı uygulayan PR açtığınızda, açıklamaya şunu ekleyin: "Karar: [ne karar verildi] – bkz. [thread/doküman bağlantısı]." Bu on saniye sürer, kod incelemesinden sağ çıkar ve gelecekteki size aranacak bir şey verir. Slack DM'lerinde ya da öğle yemeğinde alınan kararları yakalamayacak, ama yakaladıkları en önemli olanlar – codebase'i değiştirenler.

Bağlantılı karar takibinin gerçekte neyi değiştirdiği

Arkeoloji bir sorguya dönüşüyor. Girişten o sürümleme araştırması? Çapraz araç indekslemeyle beş saniyelik bir aramaya dönüşüyor ve zincirdeki her eseri bağlantılı biçimde döndürüyor. Bu utanç verici bir Çarşamba öğleden sonrasından beni kurtarırdı. This is what visibility across your engineering tools actually means in practice. It’s closely related to a semantic approach to finding past Slack decisions and a connected view of tasks that span three or more tools – all three problems stem from the same fragmented-tools root cause.

Çürümeyen işe alım bağlamı. Yeni takım üyeleri, üç ay önce güncellenen ve herkesin bulanık biçimde yanlış olduğunu ama kimsenin düzeltmeye zahmet etmediği bir wiki sayfası yerine, neden şeylerin böyle olduğunun bağlantılı izini alıyor. (Bunun bir tane var. Herkesin bir tane var.)

Aynı tartışmanın daha az tekrarı. Bu beni şaşırttı. Kararlar bulunabilir olduğunda, "bunu zaten karara bağlamıştık değil mi?" sorusu saniyeler içinde yanıtlanabilir hale geliyor; herkesin bunu tartıştığını hatırladığı ama kimsenin gerçekte ne sonuca varıldığını doğrulayamadığı on dakikalık grup halüsinasyonuna dönüşmek yerine.

Önceden göremediğiniz örüntüler. Kararlar topluca görünür olduğunda, hangi konuların en uzun tartışmaları ürettiğini ve kararların nerede takıldığını fark etmeye başlıyorsunuz. Hiçbir tek aracın veremeyeceği operasyonel içgörü, çünkü hiçbir tek araç tam resme sahip değil.

Sugarbug buna nasıl yaklaşıyor

Sürümleme araştırması, Sugarbug'ı oluşturmaya başlamama yol açan son kırdı (ayrıca vicdanıma ağırlık yapan üç ölü Karar Günlüğü). Yukarıda tanımladığım sistem – API aracılığıyla mevcut araçlarınıza bağlanıyor, her sinyali bir bilgi grafiğine besliyor, otomatik olarak sınıflandırıp bağlıyor. Takımınız çalışırken grafik kendini inşa ediyor. Kimse hiçbir şeyi belgelemiyor, çünkü veri yakalama işin kendisinin bir yan ürünü.

Hâlâ erken aşamadayız (üretimde, henüz lansmanı yapılmadı) ve henüz çözmediğimiz zor sorunlar var – kimsenin not almadığı toplantılarda sözlü olarak alınan kararlar veya "evet, onu yapalım"ı gerçek bir taahhütten ayırt etmek (kahve olayı bize güven eşikleri hakkında çok şey öğretti). Ama geçmiş kararları aramak için harcadığım süre "düzenli olarak sinir bozucu"dan "ara sıra hafifçe sinir bozucu"ya düştü, bu da makul bir yörünge gibi hissettiriyor.

Sinyal zekasını gelen kutunuza alın.

Sık Sorulan Sorular

Haftalarca önce bir Slack thread'inde alınan bir kararı nasıl bulurum?

Çapraz araç indeksi olmadan, benim yaptığımı yapıyorsunuz – kaydırıyorsunuz, farklı anahtar kelimeler deniyorsunuz, konuşmanın yaklaşık ne zaman gerçekleştiğini hatırlamayı umuyorsunuz. Sugarbug, Slack mesajlarını diğer kaynaklarınızla birlikte bir bilgi grafiğine aktarıyor, böylece tam anahtar kelime yerine kavrama göre arayabiliyorsunuz. Sihir değil – konuşmanın yine de metin olarak gerçekleşmiş olması gerekiyor – ama arkeolojik kazıdan daha iyi.

Sugarbug araçlar arasında kararları otomatik olarak takip ediyor mu?

Evet. Bağlı araçlarınızdan gelen her sinyal sınıflandırılıyor – kararlar, durum güncellemeleri, sorular, engelleyiciler – ve ilgili kişiler ile görevlerle ilişkilendiriliyor. Bir Linear issue'suyla ilgili bir Slack thread'inde bir karar ortaya çıktığında, grafik kimsenin bağlantı kopyalayıp yapıştırması veya günlük güncellemesi gerekmeden onları bağlıyor.

Karar günlüğü ile bilgi grafiği arasındaki fark nedir?

Karar günlüğü, neyin, ne zaman ve kimin tarafından kararlaştırıldığını yazan birisini gerektiriyor. Bilgi grafiği, bu bağlantıları araçlarınızın zaten ürettiği sinyallerden otomatik olarak oluşturuyor – Slack thread'i, Linear issue'su, onu uygulayan PR. Biri disiplin gerektiriyor (ki iyice kanıtladığım üzere bunda berbatız); diğeri bir sistem gerektiriyor.

Karar günlükleri neden her zaman başarısız oluyor?

Çünkü yük tam yanlış anda düşüyor. Bir kararın önemli olduğunu onu yaşarken fark etmeniz, duraksayanız, başka bir araca geçmeniz, haftalar sonra işe yarayacak kadar bağlamla yazmanız ve ardından ipliğinizi kaybetmeden işe dönmeniz gerekiyor. Bu şekilde denediğini gördüğüm her takım altı hafta içinde bırakıyor – tembellikten değil, süreç insanların gerçekte nasıl çalıştığına karşı savaştığı için.

Küçük takımlar faydalanabilir mi, yoksa bu sadece büyük kuruluşlar için mi?

Küçük takımlar deneyimime göre daha ağır darbe alıyor. Belgeleri koruyan özel bir PM yok ve "kurumsal bellek" iyi hatırlamaya sahip olan bir veya iki kişi. Slack, GitHub ve Notion'da haftada düzinelerce mikro karar alan beş kişilik bir girişim, elli kişilik bir organizasyonla aynı parçalanma sorununa sahip – sadece bir şey kaybolduğunda maliyeti özümseyen daha az insanla.

---

Beş kişinin, haftalar önce zaten çözüme kavuşturulmuş bir kararı yeniden oluşturmaya çalıştığı bir aramada otururken kendinizi bulduysanız, bu tam olarak Sugarbug'ı ortadan kaldırmak için oluşturduğumuz sorun. Bekleme listesine katılın.