Cynefin Nedir? Her Problem Aynı Türden Değildir

Bir problemi çözmeye çalışırken yaptığımız ilk hata bazen çözümün kendisinde değildir. Problemin nasıl bir yapıya sahip olduğunu yanlış anlamamızda olabilir.

Bildiğimiz bir problemi yeniden keşfetmeye çalışabiliriz. Uzmanlık gerektiren bir konuda rastgele deneyler yapabiliriz. Sonucu ancak deneyerek öğrenebileceğimiz bir durumda aylarca analiz yapabiliriz. Ya da kriz anında harekete geçmek yerine bütün cevapları bulmayı bekleyebiliriz.

Aynı karar verme biçimi her durumda işe yaramaz.

Cynefin tam olarak bu ayrımı düşünmemize yardımcı olan bir anlamlandırma çerçevesidir (sense-making framework). Bize doğrudan "şunu yap" demez. Önce daha temel bir soru sordurur:

Nasıl bir durumun içindeyiz ve bu durumda karar vermenin uygun yolu nedir?

Bu soru önemlidir. Çünkü her probleme aynı yönetim anlayışıyla yaklaşmak, iyi bildiğimiz bir yöntemi yanlış yerde kullanmamıza neden olabilir.

Cynefin nedir?

Cynefin, Dave Snowden'ın öncülüğünde geliştirilen bir anlamlandırma ve karar verme çerçevesidir. Adı Galce bir kelimeden gelir. Tek bir kelimeyle çevrilmesi zordur; kişinin içinde bulunduğu yer, geçmişi, ilişkileri, deneyimleri ve aitlik duygusuyla şekillenen bağlamı çağrıştırır.

Cynefin'in temel amacı, karşılaştığımız durumun doğasını anlamamıza ve karar verme biçimimizi buna göre değiştirmemize yardımcı olmaktır.

Model bazen bir "sistem sınıflandırması" olarak anlatılır. Bu ifade başlangıç için kullanışlı olsa da küçük bir düzeltme yapmak gerekir: Cynefin'in amacı sistemlere kalıcı etiketler yapıştırmak değildir.

Bir şirket bütünüyle "Karmaşık" değildir. Bir yazılım projesi tamamen "Uzmanlık Gerektiren" değildir. Bir ekip de sürekli "Açık" bir alanda çalışmaz.

Cynefin daha çok belirli bir anda karşı karşıya olduğumuz durumun doğasını anlamaya çalışır. Aynı ürünün, aynı projenin hatta aynı problemin farklı parçaları farklı alanlarda bulunabilir. Bu nedenle Cynefin'i katı bir sınıflandırma modelinden çok, bağlama göre düşünmemizi sağlayan bir karar verme çerçevesi olarak görmek daha yararlıdır.

Cynefin alanları nelerdir?

Cynefin, durumları anlamlandırmak için beş temel alan tanımlar:

Terminoloji notu: Cynefin yaşayan ve zaman içinde gelişen bir çerçevedir. Merkez alan tarihsel olarak Disorder olarak adlandırılmış, sonraki anlatımlarda Confused ve Aporetic kavramları kullanılmaya başlanmıştır. Bu kavramların kullanımı ve aralarındaki ayrım, çerçevenin farklı dönemlerindeki anlatımlarda değişiklik gösterebilir.

Buradaki tabloyu bir reçete gibi değil, bir düşünme biçimi olarak görmek gerekir. Çünkü Cynefin'in asıl değeri alanların isimlerini bilmekten değil, farklı durumların farklı karar verme biçimleri gerektirdiğini fark etmekten gelir.

Açık alan: Standartlaştırılabilen problemler

Açık alanda ne yapılacağı büyük ölçüde bellidir. Benzer durumlar daha önce yaşanmıştır, sonuçlar tahmin edilebilir ve standart bir uygulama tekrar tekrar kullanılabilir.

Buradaki karar döngüsü:

Algıla, sınıflandır, yanıtla (Sense, Categorise, Respond)

• Önce durumu algılarız.
• Daha önce bildiğimiz bir kategoriye yerleştiririz.
• Sonra o kategori için tanımlı cevabı uygularız.

Bu alanda en iyi uygulama (best practice) kavramı anlamlıdır. Çünkü bağlam yeterince kararlıdır ve iyi sonuç verdiği tekrar tekrar görülen bir yöntem standart hale getirilebilir.

Yazılımdan bir örnek

Bir geliştiricinin şirketin standart geliştirme ortamını kuracağını düşünelim.

Kurulum adımları dokümante edilmiştir:

1. Gerekli çalışma ortamı sürümünü kur.
2. Kod deposunu indir.
3. Ortam değişkenlerini tanımla.
4. Bağımlılıkları yükle.
5. Testleri çalıştır.

Bu süreç yüzlerce kez uygulanmış ve aynı sonucu üretiyorsa her yeni geliştirici için yeniden mimari tartışması yapmak gerekmez. Burada standartlaştırma değerlidir.

Başka örnekler de verilebilir:

• Kod biçimlendirme kuralları.
• Bilinen bir sertifika yenileme prosedürü.
• Standart kullanıcı yetkisi açma süreci.
• Tekrarlanan canlıya alma kontrolleri.
• Daha önce tanımlanmış ve kök nedeni bilinen operasyon hatalarının giderilmesi.

Bu tür işlerde amaç her seferinde yeni bir çözüm keşfetmek değildir. İyi çalışan yöntemi güvenilir biçimde tekrar etmektir.

Açık alanın tehlikesi

Bu alan kolay göründüğü için risksiz değildir. En büyük risklerden biri aşırı güven ve körleşmedir.

Bir uygulama uzun süredir çalışıyor diye sonsuza kadar doğru kalacağını varsayabiliriz. Kontrol listesi zamanla amaca hizmet etmek yerine mekanik bir ritüele dönüşebilir. İnsanlar neden yaptıklarını düşünmeden sadece prosedürü takip etmeye başlayabilir.

Örneğin yıllardır çalışan bir canlıya alma prosedürü, sistem mimarisi değiştiği halde güncellenmemiş olabilir. Ekip hâlâ eski kontrol listesini uygular ama sistem artık o listenin varsaydığı sistem değildir.

Cynefin'de Açık alan ile Kaotik alan arasındaki sınırın özellikle önemli olmasının nedenlerinden biri de budur. Uzun süre çalışan bir yönteme fazla güvenildiğinde çevredeki değişimler fark edilmeyebilir. Sistem bir noktaya kadar düzenli görünürken, biriken kırılganlıklar nedeniyle bir anda kontrolden çıkabilir.

Bu nedenle standart süreçlerin yalnızca uygulanması değil, dayandıkları varsayımların hâlâ geçerli olup olmadığının da zaman zaman sorgulanması gerekir.

Bir şeyin standartlaşmış olması, sonsuza kadar standart kalacağı anlamına gelmez.

Uzmanlık Gerektiren alan: Analiz edilebilen problemler

Uzmanlık Gerektiren alanda neden ve sonuç ilişkisi vardır. Ancak bu ilişki Açık alandaki gibi herkes tarafından kolayca görülemez. Yeterli veri, analiz ve uzmanlıkla ortaya çıkarılabilir.

Buradaki karar döngüsü:

Algıla, analiz et, yanıtla (Sense, Analyse, Respond)

• Önce bilgi toplarız.
• Sonra analiz ederiz.
• Elde ettiğimiz bilgiye göre hareket ederiz.

Burada tek bir doğru cevap olmak zorunda değildir. Birden fazla iyi çözüm bulunabilir. Bu nedenle bu alan iyi uygulama (good practice) ve uzmanlıkla ilişkilendirilir.

Uzmanlığın önemli olması, bu alanı tanımlayan tek özellik değildir. Karmaşık durumlarda da uzman bilgisi değerlidir. Asıl fark, Uzmanlık Gerektiren alanda neden-sonuç ilişkisinin yeterli analizle ortaya çıkarılabilmesidir.

Yazılımdan bir örnek: Veritabanı performansı

Bir uygulamadaki bazı sorguların yavaşladığını düşünelim. Sorunun kaynağı şu seçeneklerden biri veya birkaçı olabilir:

• Eksik indeks.
• Hatalı sorgu planı.
• Veri dağılımındaki değişim.
• Gereksiz tablo birleştirmeleri.
• Yanlış önbellek stratejisi.
• Disk veya ağ darboğazı.

Burada rastgele değişiklik yapmak yerine ölçüm ve analiz gerekir. Bir uzman sorgu yürütme planını inceler. Metrikleri karşılaştırır. İndeks kullanımına bakar. Alternatif çözümlerin maliyetlerini değerlendirir.

Sonuçta birden fazla geçerli çözüm olabilir. Daha fazla indeks eklemek sorguyu hızlandırabilir ama yazma maliyetini artırabilir. Önbellek kullanmak yükü azaltabilir ama veri tutarlılığı konusunda yeni kararlar gerektirebilir.

Yani cevap vardır. Ama cevap kendiliğinden görünmez.

Başka örnekler

• Büyük bir monolitin hangi modüllerinin ayrıştırılacağının teknik analizi.
• Bellek sızıntısının kaynağının bulunması.
• Yüksek trafikli bir sistem için kapasite planlaması.
• Bir veritabanı teknolojisinden diğerine geçiş tasarımı.
• Güvenlik açığının kök neden analizi.
• Belirli performans hedefleri için mimari alternatiflerin değerlendirilmesi.

Bu tür işlerde uzmanlık değerlidir. Fakat burada da bir risk vardır: Uzmanlığın mutlak doğru kabul edilmesi.

Uzman geçmiş deneyimlerinden yararlanır. Bu çok değerlidir. Ancak problem artık geçmişteki koşullarla aynı değilse uzmanlık yanlış bir kesinlik hissi de üretebilir.

Ben Cynefin'de en çok bu ayrımlardan birini önemsiyorum: Bazı problemlerde daha fazla analiz gerçekten daha iyi bir cevap üretir. Bazılarında ise analiz, sonucu önceden bilmemize yetmez. Uzmanlık Gerektiren alan ile Karmaşık alan arasındaki sınırı anlamak bu yüzden özellikle önemlidir.

Cynefin'de Complex ve Complicated farkı nedir?

Complicated bir problemde doğru veya iyi cevap, yeterli uzmanlık ve analizle bulunabilir. Complex bir problemde ise hangi yaklaşımın işe yarayacağı ancak sistemle etkileşime girdikten sonra öğrenilebilir. Bu nedenle complex problemler daha fazla analizle otomatik olarak complicated hale gelmez.

Karmaşık alan: Deneyerek öğrenilen problemler

Karmaşık alan Cynefin'in en önemli ayrımlarından birini gösterir.

Burada neden ve sonuç ilişkileri tamamen yok değildir. Fakat bu ilişkileri önceden güvenilir biçimde tahmin etmek zordur. Sonuç ortaya çıktıktan sonra geriye bakıp mantıklı bir açıklama yapabiliriz.

Olan şey sonradan anlamlı görünebilir. Ancak bu, onun önceden güvenilir biçimde tahmin edilebilir olduğu anlamına gelmez.

Buradaki karar döngüsü:

Dene, algıla, yanıtla (Probe, Sense, Respond)

• Önce küçük ve kontrollü denemeler yaparız.
• Sonra sistemin nasıl tepki verdiğini gözlemleriz.
• İşe yarayan örüntüleri güçlendiririz.
• Olumsuz sonuç verenleri sınırlarız veya durdururuz.

Buradaki temel fark şudur:

Karmaşık bir problemi sadece daha fazla analiz ederek Uzmanlık Gerektiren bir probleme dönüştüremezsiniz.

Çünkü sistem, siz onunla etkileşime girdikçe değişebilir.

Yazılımdan bir örnek: Yeni bir ürün özelliği

Bir ekibin kullanıcıların ekip içi bilgi paylaşımını artıracak yeni bir özellik geliştirdiğini düşünelim. Ekip şu soruya cevap arıyor:

Kullanıcılar bu özelliği nasıl kullanacak?

Bu sorunun cevabını toplantı odasında kesin olarak bulmak zordur.

• Kullanıcı araştırması yapılabilir.
• Uzman görüşü alınabilir.
• Benzer ürünler incelenebilir.

Bunların hepsi değerlidir. Ancak gerçek kullanıcı davranışı, kullanıcı ile ürün etkileşime girdikten sonra ortaya çıkar.

Bu nedenle ekip tek seferde altı aylık büyük bir çözüm geliştirmek yerine birkaç küçük deneme tasarlayabilir:

• Sınırlı bir kullanıcı grubuna basit bir prototip açmak.
• Farklı etkileşim modellerini denemek.
• Kullanım davranışlarını gözlemlemek.
• Beklenmedik kullanım biçimlerini incelemek.
• Küçük değişikliklerin etkisini ölçmek.

Buradaki amaç ilk denemede doğru cevabı bulmak değildir.

Amaç sistemden bilgi üretmektir.

Güvenli denemeler

Karmaşık alanda yapılan müdahalelerin küçük, sınırlı ve geri bildirim üretecek şekilde tasarlanması önemlidir. Bu yaklaşım güvenli biçimde başarısız olabilen denemeler (safe-to-fail experiments / probes) olarak ifade edilir.

Bir deneme başarısız olduğunda bütün sistemi tehlikeye atmamalıdır. Örneğin yeni bir kullanıcı karşılama akışını tüm kullanıcılara aynı anda zorunlu tutmak yerine küçük bir grupta denemek daha güvenlidir. Beklenmedik bir sorun çıktığında etki alanı sınırlı kalır. Ekip de öğrenmeye devam eder.

Mümkün olduğunda tek bir büyük deneme yerine farklı varsayımları sınayan birden fazla küçük ve paralel deneme yapmak daha değerlidir. Böylece tek bir fikre erken bağlanmak yerine sistemin farklı müdahalelere nasıl tepki verdiğini karşılaştırabiliriz.

Burada başarısızlık yalnızca kayıp değildir. Doğru sınırlar içinde gerçekleştiğinde bilgi üretir.

Karmaşık alana başka örnekler

• Yeni bir ürünün pazardaki davranışı.
• Kullanıcıların yeni bir özellik karşısındaki tepkisi.
• Bir organizasyonda ekip yapısının değiştirilmesi.
• Çok sayıda bağımsız ekibin birlikte çalışma biçiminin iyileştirilmesi.
• Şirket kültüründeki davranış değişiklikleri.
• Yeni bir teknolojinin organizasyon içinde nasıl benimseneceği.

Bu örneklerin ortak özelliği çok sayıda etkileşen unsur içermeleridir. İnsan davranışı, geri bildirim döngüleri ve değişen koşullar devreye girdikçe tahmin gücü azalır.

Bu alanda çözüm çoğu zaman baştan tam olarak tasarlanmaz. Sistemle etkileşim içinde ortaya çıkar ve şekillenir. Bu nedenle ortaya çıkan uygulama (emergent practice) kavramı burada daha anlamlıdır.

Kaotik alan: Önce sistemi dengelemek

Kaotik alanda analiz için beklemek tehlikeli olabilir. Sistem o kadar hızlı ve düzensiz değişmektedir ki kullanılabilir bir neden-sonuç ilişkisi kurmak mümkün değildir.

Öncelik doğru cevabı bulmak değil, daha fazla zararı önlemek ve yeniden hareket alanı oluşturmaktır.

Buradaki karar döngüsü:

Harekete geç, algıla, yanıtla (Act, Sense, Respond)

• Önce hareket edilir.
• Ardından oluşan durum gözlemlenir.
• Sonra daha bilinçli kararlar alınır.

Yazılımdan bir örnek: Büyük üretim kesintisi

Bir ödeme sisteminin aniden çöktüğünü düşünelim. Hata oranı hızla yükseliyor. Kuyruklar büyüyor. Bazı işlemler iki kez çalışıyor olabilir. Müşteri işlemleri etkileniyor.

Bu anda ilk yapılacak iş üç saatlik kök neden analizi toplantısı değildir.

Önce sistemi dengelemek gerekir. Örneğin:

• Hatalı görünen yeni sürümü geri almak.
• Trafiğin bir kısmını sınırlamak.
• Problemli entegrasyonu geçici olarak devre dışı bırakmak.
• Sistemi salt okunur moda almak.
• Veri kaybını önlemek için belirli işlemleri durdurmak.

Bu müdahaleler nihai çözüm olmayabilir. Amaç önce kaosu azaltmak ve sistemi tekrar gözlemlenebilir hale getirmektir.

Kontrol sağlandıktan sonra durum başka bir alana taşınabilir. Örneğin önce Kaotik olan bir üretim kesintisi, sistem dengelendikten sonra uzmanların kayıtları inceleyebileceği, kök nedeni araştırabileceği ve kalıcı çözüm tasarlayabileceği Uzmanlık Gerektiren bir probleme dönüşebilir.

Kaotik alanın önemli farkı

• Kaos bir çalışma yöntemi değildir.
• Sürekli yangın söndürmek çeviklik veya hız göstergesi değildir.
• Kaotik durum genellikle geçicidir.
• Amaç yeterli sınırları ve düzeni oluşturarak durumu tekrar anlamlandırılabilir hale getirmektir.

Cynefin'in merkez alanı: Confused ve Aporetic

Cynefin'in merkezindeki alanın terminolojisi çerçevenin gelişimi boyunca değişmiştir. Tarihsel olarak bu alan Disorder olarak adlandırılıyordu. Daha sonraki anlatımlarda Confused ve Aporetic kavramları öne çıkmaya başladı.

Bu kavramları birebir eş anlamlı görmek yerine aralarındaki nüansı anlamak daha yararlıdır.

Confused durumda hangi alanın karar mantığının uygun olduğunu henüz ayırt edemeyiz. Problem yeterince ayrıştırılmamış olabilir veya farklı nitelikteki sorunlar tek bir başlık altında toplanmış olabilir.

Aporetic durumda ise bilmemenin farkındayız. Mevcut kategorilerin veya varsayımların bizi erken bir cevaba sürüklemesine izin vermeden bir süre "bilmiyorum" diyebilmek, yeni olasılıkları görebilmek için bilinçli bir başlangıç noktası olabilir.

Bu ayrım ilk bakışta teorik görünebilir. Ancak pratikte oldukça değerlidir.

Yazılımdan bir örnek

Bir ekip şu ifadeyle karşılaşsın:

Sistem yavaş, performansı düzeltmemiz gerekiyor.

Bu tek cümle aslında farklı alanlara ait problemler içerebilir:

• Bilinen bir yanlış yapılandırma varsa Açık olabilir.
• Veritabanı sorgularının uzmanlar tarafından incelenmesi gerekiyorsa Uzmanlık Gerektiren olabilir.
• Kullanıcıların hangi gecikmeyi gerçekten sorun olarak gördüğü veya davranışlarının nasıl değişeceği bilinmiyorsa Karmaşık olabilir.
• Sistem şu anda tamamen erişilemez durumdaysa Kaotik olabilir.

Eğer ekip bu ayrımı yapmadan doğrudan çözüm üretmeye başlarsa herkes kendi alışık olduğu yöntemi kullanır.

• Bir geliştirici teknik optimizasyon arar.
• Ürün yöneticisi yeni bir önceliklendirme yapar.
• Operasyon ekibi kapasite artırır.
• Bir yönetici daha detaylı plan ister.

Fakat ortada henüz ortak bir problem tanımı yoktur.

Cynefin'in merkez alanı bize önemli bir şeyi hatırlatır:

Bazen ilk işimiz problemi çözmek değil, önce ne tür bir problemle karşı karşıya olduğumuzu anlamaktır.

Aynı yazılım projesi birden fazla alanda olabilir

Cynefin'i kullanırken yapılan yaygın hatalardan biri bütün projeye tek bir etiket vermektir.

Örneğin:

Bu proje Karmaşık.

Bu ifade çoğu zaman fazla geneldir.

Bir e-ticaret platformu geliştirdiğimizi düşünelim. Aynı proje içinde şunlar bulunabilir:

Bu bakış açısı önemli bir sonuç doğurur:

Projeyi değil, karar verdiğimiz durumu sınıflandırmak daha kullanışlıdır.

Böylece her işe aynı süreci zorla uygulamak yerine bağlama uygun yaklaşımı seçebiliriz.

Yanlış alanda karar verdiğimizde ne olur?

Cynefin'in değeri yalnızca alanları tanımlamakta değildir. Asıl değer, yanlış alanda yanlış karar verme biçimini kullandığımızda ortaya çıkan sorunları görmemizi sağlamasıdır.

Bağlam ile kullandığımız karar biçiminin uyuşmaması domain dissonance olarak ifade edilebilir.

Karmaşık problemi Uzmanlık Gerektiren sanmak

Bu, yazılım organizasyonlarında sık görülen bir durumdur.

Belirsiz bir ürün problemi vardır. Ekip daha fazla analiz yaparsa doğru cevabı bulacağını düşünür.

Daha fazla rapor hazırlanır. Daha detaylı plan yapılır. Daha fazla tahmin istenir.

Ancak problem analiz eksikliğinden değil, sonucu ancak etkileşim içinde öğrenebileceğimiz bir yapıya sahip olabilir.

Bu durumda daha fazla analiz kesinlik üretmez.

Sadece kesinlik hissi üretebilir.

Yazılım dünyasında bu ayrımın özellikle ürün problemlerinde sık karıştığını düşünüyorum. Teknik bir problemi çözmeye alışkın olduğumuz için, kullanıcı davranışı veya organizasyon dinamikleri gibi konularda da yeterince analiz yaparsak doğru cevabı önceden bulabileceğimizi varsayabiliyoruz.

Oysa bazen öğrenmenin yolu analiz etmekten değil, kontrollü biçimde etkileşime girmekten geçiyor.

Uzmanlık Gerektiren problemi Karmaşık sanmak

Tersi de mümkündür. Her şeyi deneysel hale getirmek iyi değildir.

Örneğin güvenilirliği kanıtlanmış bir şifreleme standardı varken her ekip kendi şifreleme yöntemini deneyerek yeni bir çözüm keşfetmeye çalışmamalıdır.

Uzmanlığın ve bilinen mühendislik bilgisinin olduğu yerde bunları kullanmak gerekir.

Karmaşıklık düşüncesi her şeyin belirsiz olduğunu söylemez. Bazı problemler gerçekten analiz edilebilir. Bazıları gerçekten standartlaştırılabilir.

Açık problemi gereğinden fazla büyütmek

Bazı ekipler basit bir işi çözmek için gereksiz toplantılar, analizler ve karar süreçleri oluşturabilir.

Bilinen ve tekrar eden bir iş için her seferinde yeniden karar vermek enerji kaybıdır. Standartlaştırılabilecek işi standartlaştırmak, zihinsel kapasitemizi gerçekten belirsiz problemlere ayırmamızı sağlar.

Kaotik problemi analiz etmeye çalışmak

Kriz anında en büyük hatalardan biri harekete geçmek için tam bilgi beklemektir.

Üretim sistemi çökmüşken önce bütün nedenleri anlamaya çalışmak zararın büyümesine yol açabilir.

Önce güvenli bir sınır oluşturmak gerekir. Analiz sonra gelir.

En iyi uygulama neden her yerde çalışmaz?

"En iyi uygulama" kavramı kulağa güven verici gelir. Birileri daha önce denemiştir, sonuç almıştır ve aynı yöntemi uygularsak benzer sonucu alacağımızı düşünürüz.

Bu yaklaşım Açık alanda oldukça değerlidir.

Ancak Karmaşık alanda başka bir organizasyonda işe yarayan yöntemi kopyaladığımızda yöntemi taşıyabiliriz; fakat onu başarılı yapan ilişkileri, geçmişi ve koşulları aynı şekilde taşıyamayız.

Bir uygulamanın başarısı yalnızca uygulamanın kendisinden kaynaklanmaz. İnsanlar, organizasyon yapısı, geçmiş kararlar, pazar koşulları ve geri bildirim döngüleri de sonucu şekillendirir.

Bu nedenle Cynefin açısından asıl soru:

Hangi uygulama en iyi?

sorusundan önce gelir:

Hangi bağlamdayız?

Açık alanda en iyi uygulamalar değerlidir. Uzmanlık Gerektiren alanda uzmanlar tarafından geliştirilmiş iyi uygulamalar öne çıkar. Karmaşık alanda ise çözüm çoğu zaman deneyler ve geri bildirimler sonucunda ortaya çıkar.

Mesele bir uygulamanın mutlak olarak iyi veya kötü olması değildir.

Mesele bulunduğumuz bağlam için uygun olup olmamasıdır.

Cynefin alanları arasında geçiş

Alanları sabit kutular olarak düşünmemek gerekir. Bir durum zaman içinde bir alandan diğerine geçebilir veya bazı yönleri farklı bir karar mantığına daha uygun hale gelebilir.

Örneğin yeni bir ürün özelliği ilk aşamada Karmaşık olabilir. Kullanıcı davranışı gözlemlenir, farklı denemeler yapılır ve bazı örüntüler ortaya çıkar.

Zamanla bu örüntülerin bir kısmı daha iyi anlaşılabilir. Belirli kararlar uzmanlık bilgisine dönüşebilir. Yeterince kararlı ve tekrar edilebilir hale gelen bazı uygulamalar ise standartlaştırılabilir.

Bu, her problemin zorunlu olarak:

Karmaşık -> Uzmanlık Gerektiren -> Açık

şeklinde doğrusal bir yol izleyeceği anlamına gelmez.

Daha çok, bugün belirsiz olan bazı ilişkilerin zamanla anlaşılabilir hale gelebileceğini gösterir.

Benzer şekilde büyük bir üretim kesintisi Kaotik başlayabilir. Sistem dengelenir. Problem sınırlandırılır. Ardından uzmanların analiz edebileceği bir duruma dönüşebilir.

Tersi de mümkündür. Uzun süredir Açık kabul edilen bir süreç, çevresindeki koşullar değiştiğinde artık aynı öngörülebilirliği göstermeyebilir.

Bu hareketlilik bize şunu hatırlatır:

Dün doğru olan karar verme biçimi bugün doğru olmayabilir.

Bağlam değiştiğinde yaklaşımın da değişmesi gerekir.

Yazılım ekipleri Cynefin'i nasıl kullanabilir?

Cynefin'i kullanmak için organizasyon çapında büyük bir dönüşüm programına ihtiyaç yoktur.

Bir planlama, problem çözme veya karar verme toplantısında bile kullanılabilir.

1. Önce problemi küçült

"Yeni platform projesi" gibi büyük bir başlığı tek bir alana yerleştirmeye çalışma.

Onun yerine somut kararları veya problemleri ayır:

• Kimlik doğrulama altyapısı nasıl kurulacak?
• Kullanıcılar yeni akışı benimseyecek mi?
• Veri taşıma stratejisi ne olacak?
• Şu anki üretim hatasını nasıl durduracağız?

Büyük problemler çoğu zaman farklı doğaya sahip daha küçük problemlerin birleşimidir.

2. Neden-sonuç ilişkisini sorgula

Şunu sor:

Bu problemi yeterince analiz edersek doğru cevabı önceden bulabilir miyiz?

Cevap açık biçimde evetse problem Açık veya Uzmanlık Gerektiren olabilir.

Cevap:

Ancak deneyip sistemin veya kullanıcıların tepkisini gördükten sonra anlayabiliriz.

ise Karmaşık olma ihtimali yüksektir.

Cevap:

Şu anda analiz edecek zaman yok, önce zararı durdurmalıyız.

ise Kaotik alanda olabiliriz.

Problemin ne olduğunu veya hangi karar mantığının uygun olduğunu bile net biçimde söyleyemiyorsak önce merkez alanda durup problemi ayrıştırmamız gerekebilir.

3. Karar yöntemini alana göre seç

• Açık ise standartlaştır.
• Uzmanlık Gerektiren ise analiz ve uzmanlık kullan.
• Karmaşık ise küçük, kontrollü ve mümkünse farklı varsayımları sınayan denemeler yap.
• Kaotik ise önce sistemi dengele ve hareket alanı oluştur.
• Hangi alanda olduğunu bilmiyorsan çözüm dayatmadan önce problemi ayrıştır ve varsayımlarını sorgula.

4. Alanın değişip değişmediğini tekrar kontrol et

Bir problemi bir kez sınıflandırıp unutma.

Yeni bilgi geldikçe durum değişebilir. Daha önce belirsiz olan bazı ilişkiler zamanla anlaşılabilir hale gelebilir. Standart olan bir süreç ise çevresindeki sistem değiştiği için yeniden belirsizleşebilir.

Cynefin bir defalık sınıflandırma aracı değil, tekrar tekrar kullanılabilecek bir düşünme biçimidir.

Sonuç: Doğru çözümden önce doğru bağlam

Mühendislikte iyi çözümler bulmayı severiz.

• Daha iyi mimari.
• Daha iyi süreç.
• Daha iyi araç.
• Daha iyi uygulama.

Fakat Cynefin daha temel bir şeyi hatırlatır:

Bir çözümün kalitesi yalnızca çözümün kendisine değil, uygulandığı bağlama da bağlıdır.

Standartlaştırılması gereken bir işi sürekli yeniden keşfetmek verimsizliktir.

Uzmanlık gerektiren bir problemi rastgele denemelerle çözmeye çalışmak risklidir.

Karmaşık bir sistemi detaylı planlarla tamamen kontrol etmeye çalışmak sahte bir kesinlik yaratabilir.

Kriz anında analiz için beklemek ise zararın büyümesine neden olabilir.

Bu nedenle bir probleme başlarken ilk sorumuz her zaman:

En iyi yöntem hangisi?

olmamalıdır.

Önce şunu sormak daha değerlidir:

Biz şu anda nasıl bir durumun içindeyiz?

Bu sorunun cevabı değiştikçe iyi kararın biçimi de değişir.

Cynefin'in verdiği en değerli derslerden biri budur:

Her problem aynı türden değildir.

O halde her probleme aynı şekilde yaklaşmak zorunda da değiliz.

Kaynaklar

• Cynthia F. Kurtz ve David J. Snowden, The New Dynamics of Strategy: Sense-making in a Complex and Complicated World, IBM Systems Journal, 42(3), 462-483, 2003.
• Dave Snowden ve Mary E. Boone, "A Leader's Framework for Decision Making", Harvard Business Review, 2007.
• The Cynefin Co, "The Cynefin Framework".
• The Cynefin Co, "Effective Decision Making Support Tool".