Karar Günlüğü: Kararların Nedenlerini Korumak İçin Kararlar Nasıl Kaydedilir?

Kurumlar neye karar verdiklerini hatırlar ama nedenini unuturlar. Karar kayıtlarının nasıl çalıştığı, nelerin kaydedilmesi gerektiği, hafif bir şablon ve bunların sonuçlarla nasıl ilişkilendirileceği üzerine.

Ibrahim Elkobeissi · 2 Kasım 2026 · 6 dakikalık okuma ·

LinkedIn X WhatsApp

Büyük modernist bir kurum binasının cephesi

Bir ekibe bir politikanın neden var olduğunu sorun, genellikle bir sessizlik duyarsınız. Birisi bir toplantıyı hatırlar. Bir başkası bunun bir tedarikçi sorunu olduğunu düşünür. Bilgisi olan kişi geçen yıl işten ayrılmıştır. Karar yaşamıştır, ancak nedenleri değil.

Bu durum olağandır ancak maliyetlidir. Nedenleri olmadan bir ekibin iki kötü seçeneği vardır: Artık anlamadığı bir kararı sürdürmek veya kararı geri alıp çözdüğü sorunu tekrar getirme riskini almak. Karar günlüğü üçüncü bir seçenek sunar. Kaydı okuyun, koşulların hala geçerli olup olmadığını kontrol edin ve bilinçli bir şekilde yeniden karar verin.

Kurumlar neden karar verdiklerini unutur

Bir kurumun kendi kararlarını hatırlamasına karşı üç güç çalışır.

Nedenler konuşmalarda yaşar. Kararlar toplantılarda, görüşmelerde ve mesajlaşma dizilerinde alınır. Sonuç bir politikaya veya plana dönüşür; ancak bağlam nadiren oraya ulaşır.
İnsanlar yer değiştirir. Seçenekleri değerlendiren kişiler rollerini değiştirir veya ayrılırlar. Onların anlayışı da onlarla birlikte gider.
Hafıza kendini yeniden yazar. 1975 tarihli bir çalışmada psikolog Baruch Fischhoff, insanların bir sonucu öğrendikten sonra onu olduğundan daha öngörülebilir olarak değerlendirdiğini bulmuştur. Buna "sinsi determinizm" adını vermiştir. Olay gerçekleştikten sonra, kötü sonuçlanan sağlam bir karar dikkatsizce, şanslı bir karar ise bilgece görünür.

Son nokta en önemlisidir. Aynı kişiler kalsa bile, neden karar verdiklerine dair hafızaları, sonrasında olanlarla şekillenir. Yalnızca karar anında yazılan bir kayıt; neyin bilindiğini, neyin beklendiğini ve neyin belirsiz olduğunu korur.

Microsoft'un mimari kılavuzu maliyeti açıkça belirtir: Hiç kaydedilmeyen bir karar "muhtemelen unutulacak ve tekrarlanan tartışmalara yol açacaktır."

Yazılım ekiplerinin öğrendiği: mimari karar kaydı

Yazılım mühendisliğinin test edilmiş bir cevabı vardır. Kasım 2011'de Michael Nygard, mimari karar kaydını (ADR) önerdi: Her önemli karar için sıralı numaralandırılmış ve projeyle birlikte tutulan kısa bir belge. Formatı beş bölümden oluşur.

Başlık. "ADR 9: Çoklu Kiracılı Entegrasyon için LDAP" gibi numaralı, kısa bir isim tamlaması.
Bağlam. Devrede olan güçler: teknik, politik, sosyal ve yerel. Nygard, bu bölümün değer yargısından uzak, sadece gerçeklerin bir açıklaması olmasını istemiştir.
Karar. Bu güçlere verilen yanıt; etken çatılı, tam cümlelerle: "Şunu yapacağız..."
Durum. Önerilen, kabul edilen, kullanımdan kaldırılan veya geçersiz kılınan; varsa yerine gelen karara atıfta bulunarak.
Sonuçlar. Ortaya çıkan durum. Nygard'ın ifadesiyle, "Sadece 'pozitif' olanlar değil, tüm sonuçlar burada listelenmelidir."

Bu uygulama yayıldı. Thoughtworks, hafif ADR'leri Teknoloji Radarı'nın en güçlü öneri seviyesi olan Adopt halkasına yerleştirdi ve bunları ayrı bir wiki yerine kaynak kontrolünde tutmayı tavsiye etti. Microsoft'un Azure Well-Architected Framework'ü, karar kaydını bir çözüm mimarının en önemli çıktılarından biri olarak tanımlar. Kılavuzu, ödünç alınmaya değer iki kural daha ekler: günlüğü sadece ekleme yapılabilir (append-only) olarak değerlendirin ve her kararla birlikte bir güven seviyesi kaydedin.

Bunların hiçbiri sadece yazılıma özgü değildir. Hastaneler kabul prosedürlerini değiştirir. Okullar değerlendirme politikalarını değiştirir. Kurumlar tedarikçileri değiştirir. Bu kararların her birinin bağlamı, seçenekleri ve sonuçları vardır ve her biri daha sonra odada bulunmayan biri tarafından sorgulanacaktır.

Bir karar kaydı neleri kapsamalıdır

Karar günlüğü, her birini özetleyen bir dizine sahip olan bu kayıtların koleksiyonudur. Microsoft'un mühendislik kılavuzu, günlüğü; tam kayıtlarda tutulan kararlar için meta verileri içeren bir yönetici özetleri tablosu olarak tanımlar. Aşağıdaki karar günlüğü şablonu mühendisliğin çok ötesinde işe yarar. Her alan yerini hak eder.

ID ve başlık. Bir numara ve neye karar verildiğini belirten bir ifade.
Tarih. Kararın yazıldığı tarih değil, alındığı tarih.
Sorumlu. Karardan sorumlu olan kişi ve danışılan kişiler.
Bağlam. Sorun, kısıtlamalar ve çatışan güçler.
Değerlendirilen seçenekler. Reddedilenler ve nedenleri dahil. Bu, en sık eksik olan ve en çok ihtiyaç duyulan alandır.
Karar. "Şunu yapacağız..." ile başlayan net bir cümle.
Kanıt. Kararın dayandığı verilere, raporlara, denetimlere veya geri bildirimlere bağlantılar.
Beklenen sonuç. Karar işe yararsa neyin doğru olacağı ve ne zamana kadar olacağı.
Güven. Yüksek, orta veya düşük; belirsiz kalan kısımlar için bir açıklama ile birlikte.
İnceleme tarihi. Kararın, beklenen sonuçla ne zaman karşılaştırılacağı.
Durum. Önerilen, kabul edilen, geçersiz kılınan veya emekli edilen; varsa yerine geçen yeni kayda bir bağlantı ile birlikte.

Beklenen sonuç ve güven alanları, bir karar Journal işlevi görür. Sonucu bilmeden önce neye inandığınızı kaydederler; bu da tam olarak geriye dönük bakışın (hindsight) sildiği şeydir.

Kendi ürün kararlarımızda da aynı alışkanlığı sürdürüyoruz. Gözlemlenenler, çıkarımlardan ayrı bir şekilde kaydedilir ve çelişen görüşler yumuşatılmak yerine olduğu gibi korunur. Bir karar, en az bu kadar özen gerektirir.

Her kararı kendi kanıtına ve sonucuna bağlayın.

Tek başına duran bir kayıt, hiç yoktan iyidir. Bağlantılı bir kayıt ise çok daha kullanışlıdır.

Kanıta geri bağlantı kurun. Bir karar bir hasta anketine, maliyet analizine veya bir olay raporuna atıfta bulunuyorsa, doğrudan kaynağa bağlantı verin. Böylece sonraki okuyucular kanıtın hala geçerli olup olmadığını değerlendirebilir. Microsoft'un kılavuzu da aynı noktaya değiniyor: Gerekçelendirilmemiş bir kayıt "zamanla değerini kaybeder."

Sonuca ileri bağlantı kurun. İnceleme tarihinde, beklenen şeyin yanına gerçekte ne olduğunu yazın. Eğer aradaki fark büyükse, nedenini sorun. Kanıtlar zayıf mıydı? Koşullar mı değişti? Karar doğruydu ama sonuç sadece talihsiz miydi? Cevap bir derstir ve aynı zincirin bir parçası olmalıdır. Gelecek projeleri değiştiren çıkarılan dersler hakkındaki makalemiz, bu tür derslerin nasıl kalıcı hale getirileceğini açıklamaktadır.

Ardıllara çapraz bağlantı kurun. Bir karar geri alındığında eski kaydı düzenlemeyin. Onu geçersiz kılınmış olarak işaretleyin ve yenisine yönlendirin. Bir yön değişikliğinin geçmişi, genellikle günlükteki en değerli şeydir.

Varsayımsal bir örnek zinciri gösteriyor: Bir klinik, takip aramalarını hemşirelerden özel bir koordinatöre devretmeye karar verir. Kayıt, arama tamamlama verilerine atıfta bulunur, operasyon müdürünü sorumlu olarak belirler, tamamlanma oranının üç ay içinde artmasını bekler ve bir inceleme tarihi belirler. İnceleme yapıldığında, tamamlanma oranı artmıştır ancak hemşire iş yükü beklendiği gibi düşmemiştir. Yeni bir kayıt ilkinin yerine geçer, rolü ayarlar ve ona geri bağlantı kurar. İki yıl sonra, yeni bir yönetici tüm hikayeyi beş dakikada okuyabilir.

Sürdürülebilir olması için hafif tutun.

Karar günlükleri, çoğu dokümantasyonun başarısız olduğu şekilde başarısız olur. Bir angaryaya dönüşürler ve sonra dururlar. Beş kural onları canlı tutar.

Yalnızca önemli kararları kaydedin. Microsoft'un testi kullanışlıdır: Yapıyı şekillendiren, temel nitelikleri etkileyen veya geri alınması zor olan kararlar.
Her kaydı kısa tutun. Bir sayfa veya daha az. Kopyalamak yerine destekleyici materyallere bağlantı verin.
Karar verdiğinizde yazın. Aynı hafta yazılan bir kayıt doğrudur. Aylar sonra yazılan ise bir yeniden kurgudur.
İşin yapıldığı yerde tutun. Etkilediği plan ve prosedürlerin yanında tutulan bir günlük okunur. Ayrı bir klasördeki günlük ise okunmaz.
Şimdi başlayın, sonra birkaçını geriye dönük doldurun. Yeni kararlarla başlayın. Ardından insanların en çok sorduğu birkaç geçmiş kararı yeniden kurgulayın ve bunları 'yeniden kurgulanmış' olarak işaretleyin.

Nedenleri olmayan bir karar, bir talimattır. Nedenleri olan bir karar ise dikkatle test edilebilir, saklanabilir veya değiştirilebilir.

Prism karar kayıtlarını nasıl tutar

Prism, bir kurumun kararlarını ve bilgisini; onaylanmış, kanıtlanmış, gözlemlenmiş veya çıkarılmış gibi belirtilmiş bir Trust seviyesine sahip öğeler olarak tutar. Her karar kendi kanıtına, onu gerçekleştiren adımlara ve ardından gelen sonuçlara ve Duraklat ve Öğren derslerine bağlanır. Bir karar geçersiz kılındığında, önceki karar görünür kalmaya devam eder. Ekibinizin halihazırda kullandığı asistanlar da kaydı okuyabilir, böylece birisi sorduğunda nedenler orada hazır bulunur. Kararları insanlar verir. Prism ise nedenlerini saklar.