Girişimler için Karar Günlüğü
Girişimler haftada yüzlerce karar alır. Çoğu Slack iş parçacıklarına ve unutulan toplantılara gömülür. İşe yarayan bir karar günlüğü nasıl oluşturulur.
By Ellis Keane · 2026-03-16
1986'da uzay mekiği Challenger, fırlatılmasından 73 saniye sonra parçalara ayrıldı. Sonraki soruşturma, Morton Thiokol'daki mühendislerin bir gece önce O-ring contalar hakkındaki endişelerini dile getirdiğini ortaya koydu; soğuk havanın fırlatmayı güvensiz kıldığını öne sürdüler. Yönetim onları reddetti. Karar bir telekonferansta alındı ve grafikler ile ifadeler mevcut olsa da geçersiz kılmanın arkasındaki kritik gerekçe katılımcılar arasında dağınık kaldı ve zincirin yukarısına hiçbir zaman güvenilir biçimde iletilmedi.
Girişiminizin ürün kararlarını bir mekik felaketine benzetmiyorum (çoğunu değil en azından). Ancak temel arıza modu, girişimlerde her hafta gördüğüm – yalnızca daha düşük risklerle – aynı şeydir: bir karar alınır, arkasındaki gerekçe birinin kafasında ya da yakında ekrandan kaybolacak bir Slack iş parçacığında yaşar; üç ay sonra neden A yaklaşımını B yerine seçtiğimizi kimse yeniden oluşturamaz. Karar yanlış olduğu için değil – bazen mükemmeldi – ama onu doğru kılan bağlam buharlaşıp gitmiştir.
"Bir karar alınır, arkasındaki gerekçe birinin kafasında ya da yakında ekrandan kaybolacak bir Slack iş parçacığında yaşar; üç ay sonra neden A yaklaşımını B yerine seçtiğimizi kimse yeniden oluşturamaz." – Ellis Keane
Girişimler için karar günlüğü bürokratik bir alıştırma değildir. "Bunu denedik ve işe yaramadı" (faydalı) ile "Sanırım bunu bir keresinde konuşmuştuk?" (faydasız) arasındaki farktır.
Kayıp Bir Kararın Anatomisi
Bu sorunun soyut versiyonu somut olanı kadar ikna edici olmadığından, belirli bir kararı yaşam döngüsü boyunca izleyelim.
Şubat ayında bir Salı günü. Mühendislik müdürünüz ve PM'iniz bir Slack iş parçacığında özel bir bildirim sistemi mi kuracaklarını yoksa üçüncü taraf bir hizmet mi kullanacaklarını tartışıyor. İş parçacığı 47 mesaj uzunluğunda (biliyorum, ama böyle gidiyor) ve 38. mesaja gelindiğinde üçüncü taraf seçeneğinde karar kılmışlar, çünkü özel geliştirme üç sprint alacak ve lansman son tarihi iki sprint sonra.
PM bir Linear sorunu oluşturuyor: "Bildirimler için [Service X]'i entegre et." Bir mühendis işi alıyor, inşa etmeye başlıyor. Slack iş parçacığı teknik olarak hâlâ orada, ama kimse onu yer imlerine eklemiyor ya da Linear sorunuyla ilişkilendirmiyor.
Mayıs'a hızlı ileri saralım. Üçüncü taraf hizmetinde güvenilirlik sorunu var. Biri soruyor: "Neden bunu kendimiz yapmadık?" PM konuşmayı hatırlıyor ama ayrıntıları hatırlamıyor. Mühendislik müdürü doğum izninde. Slack iş parçacığı Şubat ayından #engineering kanalında bir yerde, ama kimse tam tarihi hatırlamıyor ve Slack araması "notification" için 200 sonuç döndürüyor (çünkü tabii ki her ekip sürekli bildirimler hakkında konuşuyor).
Ekip, orijinal gerekçeyi yeniden oluşturmak için bir toplantıda 45 dakika harcıyor. Sonunda aynı sonuca varıyorlar – zaman çizelgesi kısıtlaması hâlâ geçerliydi – ama 45 dakika gitti ve şüphe sürüp gidiyor. Bunu bir girişimin her ay aldığı düzinelerce kararla çarpın ve zaten düşünceli bir şekilde verilmiş seçimleri yeniden tartışmak için harcanan anlamlı bir zaman dilimi elde edersiniz.
Girişimler Bu Konuda Neden Özellikle Kötü
Büyük şirketler (tüm kusurlarıyla birlikte, ve çok sayıda var) genellikle süreçte kodlanmış kurumsal belleğe sahiptir: mimari karar kayıtları, RFC'ler, resmi inceleme döngülerinden geçen tasarım belgeleri. Kararlar Confluence'a gömülmüş olabilir, ama en azından bir yerde bulunabilir şekilde yazılıdır.
Girişimlerin bu altyapısı yoktur ve onu oluşturmak, küçük ve hızlıyken kaçınmanız gereken yük türü gibi hissettiriyor. "Sadece hatırlayacağız" demenin 4 kişiyle işe yaradığına dair makul bir argüman var ve işe de yarıyor – ta ki 5. kişi katılana ve her şeyin neden böyle olduğuna dair hiçbir bağlamı olmadığı ana kadar.
Girişim karar takibini özellikle zorlaştıran bir diğer şey de araç dağılımıdır. Kararlar her yerde alınır: Slack iş parçacıkları, Zoom aramaları, Notion yorumları, Linear tartışmaları, GitHub PR incelemeleri ve (giderek artan şekilde) hiçbir zaman paylaşılan bir kanala ulaşmayan DM'lerde. Her araç kararın bir parçasını yakalar, ama hiçbiri bütünü yakalamaz ve aralarındaki bağlantılar insan belleği tarafından sürdürülür ki bu (sevgiyle söylüyorum) hepimizin erişebildiği en güvenilmez veritabanıdır.
Karar Günlüğünün Gerçekten Neye İhtiyacı Var
Bunu aşırı mühendisleştirme cazibesine kapılmak kolaydır. Ekiplerin giriş başına 15 özellik içeren ayrıntılı Notion veritabanları kurduklarını ve ardından her karar için tüm bu alanları doldurmak algılanan değerden daha ağır geldiğinden hiç kullanmadıklarını gördüm – karar türü, etki düzeyi, inceleme durumu, paydaşlar, ilgili OKR'lar.
Girişimler için karar günlüğünün insanların gerçekten kullanacağı kadar hafif olması gerekir. Önemli olan şeyler:
Kararın kendisi. Bir cümle. "Özel geliştirme yapmak yerine bildirimler için Service X'i kullanıyoruz." Bir paragraf değil – bir cümle.
Kimin aldığı ve ne zaman. İsim ve tarih. Bu açık görünüyor ama altı ay sonra biri kararı sorguladığında en çok önem taşıyan parçadır. Suçlamakla ilgili değil (çoğunlukla değil) – orijinal gerekçe için kime sorulacağını bilmekle ilgili.
Hangi alternatiflerin değerlendirildiği. İki veya üç madde. "Özel geliştirme değerlendirildi (3 sprint tahmini, son tarih çok sıkı)" ve "Service Y değerlendirildi (fiyatlandırma 10K kullanıcının ötesinde ölçeklenemedi)." Bu, yeniden tartışmayı önleyen kısımdır – alternatifler ve değiş tokuşları belgelenirse ekibin bunları yeniden keşfetmesi gerekmez.
Tartışmanın nerede gerçekleştiği. Slack iş parçacığına, Linear sorununa, Notion yorumuna bağlantı – gerçek tartışmanın nerede geçtiğine. Bu en az değer verilen alandır. Olmadan günlük girişi kanıtsız bir iddiadır. Onunla birlikte tam bağlamı isteyen herkes orijinal konuşmayı okuyabilir.
Kararı neyin değiştireceği. Bu isteğe bağlıdır ama bağlamın hızla değiştiği girişimler için inanılmaz derecede faydalıdır. "Lansman son tarihi 4 haftadan fazla ertelenirse bunu yeniden değerlendiririz" veya "Bu, aylık 10K bildirimin altında kaldığımızı varsayıyor." Statik bir kaydı canlı bir kayda dönüştürür.
Girişimler için en iyi karar günlüğü ekibinizin gerçekten doldurduğu günlüktür. Beş alan, her biri bir cümle. Bir kararı kaydetmek 90 saniyeden uzun sürüyorsa sistem bir ay içinde ölecektir.
Nereye Koyulacak
Ekiplerin üç yaklaşımı denediğini gördüm ve hepsinin ödünleşimleri var.
Bir Notion veritabanı. Bu en yaygın olandır ve oldukça iyi çalışır. Yukarıdaki beş alanla bir veritabanı oluşturun, doldurmayı hızlandırmak için bir şablon ekleyin ve her girişi ilgili proje sayfasıyla ilişkilendirin. Dezavantajı: Notion özelliklerin yaşadığı yerdir, kararların alındığı yer değil; bu nedenle karar başka bir yerde alındıktan sonra birisinin Notion'a gitmesine güveniyorsunuz. Bu "sonra" adımı, terk etmenin gerçekleştiği yerdir.
Doğrudan Slack'te. Bazı ekipler özel bir #decisions kanalı kullanır ve her karar için biçimlendirilmiş bir mesaj gönderir. Bu daha az sürtünmelidir (karar zaten muhtemelen Slack'te alındı), ancak Slack'in araması kararları proje veya tarih aralığına göre bulmayı zorlaştırır ve yapılandırılmış alanların olmaması tutarlılığın zaman içinde bozulduğu anlamına gelir.
Doğrudan Linear'da. Karar belirli bir iş akışıyla ilgiliyse ilgili Linear sorununa bir yorum olarak kaydetmek kararı etkilediği işin yakınında tutar. Dezavantajı, birden fazla sorunu veya projeyi kapsayan kararların doğal bir yeri olmamasıdır.
Dürüst olmak gerekirse bunların hiçbiri harika değil. Temel sorun, kararların araçlar genelinde alınmasına karşın günlüklerin tek bir araçta yaşamasıdır, bu nedenle boşluğu kapatmak için her zaman manuel bir adım vardır. Bu manuel adım, gördüğüm her karar günlüğünde tek başarısızlık noktasıdır.
Sugarbug'da Neler İnşa Ediyoruz
Sugarbug ile izlediğimiz yaklaşım, birinin bunları manuel olarak kaydetmesini gerektirmek yerine araçlar genelinde gerçekleştikleri anda kararları tespit etmektir.
Bir Slack iş parçacığı bir sonuca ulaştığında ("Tamam, Service X ile gidelim"), bir Linear sorun tartışması çözümlendiğinde, bir GitHub PR incelemesi bir onaylamayla bittiğinde – bunların hepsi bir kararın alındığına dair sinyallerdir. Sugarbug bu sinyalleri alır, sınıflandırır ve bilgi grafiğindeki ilgili görev ve kişilerle ilişkilendirir. "Karar günlüğü" birinin sürdürmesi gereken ayrı bir veritabanı değildir – mevcut araçlarınıza zaten yerleşik olan kararlar genelindeki bir görünümdür.
Sınıflandırma doğruluğunu hâlâ çalışıyoruz ("karar" ile "sadece konuşma" arasındaki farkı bulmak göründüğünden daha zordur), ancak yönlü bahis, kararları gerçekten oldukları kaynakta yakalamaktır; bu, insanlardan bunları ayrı bir sisteme kopyalamalarını istemekten daha güvenilirdir.
Bu sizi ilgilendiriyorsa sugarbug.ai daha fazla ayrıntı içeriyor. Ancak yukarıdaki manuel sistem, ekip manuel günlük tutmadaki araç yorgunluğu gerçek bir sorun haline gelene kadar – deneyimimize göre genellikle 8–12 kişi civarında – çoğu girişime iyi hizmet edecektir.
Kararları Slack kaydırmasına kaptırmayı bırakın. Sugarbug onları gerçekten gerçekleştikleri araçlardan otomatik olarak yakalar.
Q: Bir girişimin karar günlüğünde neler bulunmalıdır? A: En azından: kararın kendisi (bir cümle), kimin aldığı, ne zaman, hangi alternatiflerin değerlendirildiği ve tartışmanın nerede gerçekleştiği. Son alan en önemlisidir – orijinal konuşmaya bağlantı olmadan günlük kanıtsız bir iddiadır ve altı ay sonra biri onu sorguladığında hafızadan yeniden oluşturmaya geri dönersiniz.
Q: Sugarbug mevcut araçlardan otomatik olarak karar günlüğü oluşturur mu? A: Yöneldiğimiz yön bu. Sugarbug Slack, Linear, GitHub, Notion ve diğer araçlardan sinyaller alarak bunları bir bilgi grafiğinde sınıflandırır. Bir karar algıladığında – onaylanmış bir PR, çözümlenmiş bir Linear tartışması, net bir sonraki adımla biten bir Slack iş parçacığı – bu kararı ilgili görev ve kişilerle otomatik olarak ilişkilendirir. Sınıflandırmayı hâlâ iyileştiriyoruz ("karar"ı "konuşma"dan ayırt etmek gerçekten zor), ancak sinyal alımı ve ilişkilendirme çalışıyor.
Q: Bir girişim karar günlüğünü ne sıklıkla güncellemelidir? A: İdeal olarak kararlar alındıklarında kaydedilir, haftalık toplu değil. Cuma günü geldiğinde Salı günkü kararın arkasındaki gerekçe zaten belirsizleşmiştir ve "değerlendirilen alternatifler" alanını doğru doldurma şansı hızla düşer. Manuel kayıt tutuyorsanız karardan hemen sonra 90 saniyelik bir alışkanlık yapın. Sugarbug gibi bir araç kullanıyorsanız hedef kararların gerçekten alındığı araçlardan gerçek zamanlı yakalamadır.
Q: Sugarbug Slack, Linear ve GitHub'daki kararları takip edebilir mi? A: Sugarbug üçüne de (ve Notion ve Figma'ya) bağlanır ve konuşmalar, görevler ile kod değişiklikleri arasındaki ilişkilerin bilgi grafiğini korur. Bir Slack iş parçacığında bir karar ortaya çıktığında, bir Linear sorununa yol açtığında ve bir GitHub PR'ı doğurduğunda Sugarbug tüm zinciri bağlar; böylece kimsenin bu bağlantıları manuel olarak oluşturmasına gerek kalmadan kararı kaynaktan uygulamaya kadar takip edebilirsiniz.
Q: Karar günlüğü ile mimari karar kaydı (ADR) arasındaki fark nedir? A: ADR'ler genellikle önemli teknik seçimler için resmi belgelerdir – "MongoDB yerine PostgreSQL kullanıyoruz" – bağlam, karar ve sonuçlar için yapılandırılmış bölümlerle. Girişimler için karar günlüğü daha geniş kapsamlı ve daha hafiftir: ADR'lerin belgelemek için çok küçük sayacağı günlük operasyonel kararları (hangi satıcı, hangi son tarih, hangi özellik kesileceği) yakalar. İkisi de değerlidir; karar günlüğü resmi bir ADR gerektirmeyen ama yine de izlenebilir olması gereken kararların %95'ini kapsar.