Bilgiyi Geri Kazanma Playbook’u

İyi şeyler inandığında, daha iyi şeyler sabrettiğinde ve en iyi şeyler ise hiç vazgeçmediğinde gelir!

Knowledge Lock-in Serisi — 4

Şuana kadar yaptığımız yolculukta üç aşamadan geçtik. Önce sorunu tanımladık: Knowledge Lock-in.

Sonra bir harita çıkarttık ve adına KOM yani Knowledge Ownership Model dedik. Bu haritayı kullanarak ölçüm yapıp bir öz değerlendirme de bulunduk: Knowledge Lock-in Nasıl Ölçülür?

Peki ölçümü yaptıktan sonra sonucun pekte iç açıcı olmadığını fark ettiğimiz de ne yapacağız? Önce panik yapmayacaksınız :) Direk kötü haber ile başlayayım;

Kaybedilen bilgiyi geri satın alamazsınız. Bir bütçe kalemiyle, bir sözleşme maddesiyle ya da bir haftalık eğitimle geri gelmez!

Ama bir de iyi haber var. Yeniden üretebiliriz. Bunun içinde yeni bir proje beklemenize gerek yok. Mevcut çalıştığınız vendor aslında bilgiyi geri kazanmanızı sağlayacak en ideal çalışma ortamıdır.

Peki bu ideal çalışma ortamından nasıl faydalanmak gerekiyor. Tek bir yöntemi olmayan bu çözümü dört farklı katmanda ele aldım.

Sözleşme, Çalışma Biçimi, Kurumsal Hafıza ve tabi ki İnsan

Şunu da unutmamak gerekiyor. Bu bir sihirli değnek değil. Knowledge Lock-in yıllar içinde birikti ve geri gelmesi de zaman alacak. Ama yön belli olduğunda mesafe kısalır!

Şimdi bu katmanları teker teker detaylandıralım.

1. Katman: Sözleşme

Genelde üzerinde en çok durulduğu sanılan en az konuşulan fakat en etkili ve önemli olandır. Çoğu vendor sözleşmelerinde bilgi transferi bir cümledir. Genellikle yapılan toplantılarda “bilgi transferi/eğitim elbette yapılacaktır” denilir. Fakat bu kime, neyi, nasıl sorularına cevap vermeyen bir ifadedir. İyi niyetlidir fakat işe yaramaz. Çünkü ölçülebilir bir yükümlülük tanımlamaz. Bu katmanda yapılacak olan üç değişiklik büyük fark yaratır.

• Teslim edilebilir olarak “çalışan sistem” değil “çalışan sistem + onu sürdürebilen kurum ekibi”. Fark incedir fakat kritiktir. Çalışan sistem dendiğinde vendor sadece bir ürün teslim eder. Diğerinde ise yetkinlik almış olursunuz. Kabul kriteri de “sistem çalışıyor mu?” değil “kurum ekibi sistemi bağımsız devam ettirebiliyor mu?” olmalıdır.
• Dokümantasyon için gerçek bir kabul testi. Dokümantasyonun var olması yeterli olmaz. Asıl soru şudur; kurum ekibinden biri yalnızca bu dokümana bakarak süreçleri ilerletebiliyor mu? Dokümantasyonu vendor değil onu kullanacak olan ekip test etmelidir. Kullanılmayan doküman, olmayan dokümandır.
• Exit senaryosu maddesi. Sözleşmede “vendor yarın olmazsa ne olur?” sorusunun cevabı olmalıdır. Bu sadece bir madde değil düzenli bir tatbikattır. Kurum, ekibin vendor olmadan da sistemi belirli bir süre ayakta tutabildiğini düzenli olarak tatbik etmelidir. Yangın, deprem gibi doğal afetler nasıl gerçekmiş gibi tatbik edilmeye çalışılıyor ise buna da aynı önemin verilmesi gerekmektedir.

Önemli: Bu maddeler satın alma ve hukuk süreçlerini doğrudan etkiler. Bu yüzden bunları sözleşmelere eklerken kendi hukuk ve satın alma ekiplerinizle birlikte tasarlamanızı öneririm. Bu fikirler bir başlangıç noktasıdır hazır bir sözleşme metni değildir.

Almaca da çok güzel ve sevdiğim bir söz var;

Vertrauen ist gut kontrolle ist besser!

Yani güven önemlidir; ancak sadece söylenenlere veya başkalarının yaptıklarına dayanarak hareket etmemek gerekir. Gerektiğinde doğrulamak ve kontrol etmek her zaman sağlıklı bir yaklaşımdır.

2. Katman: Çalışma Biçimi

Peki bilgi nasıl elde edilir. Vendor çalışma yaparken izlemek bilginin geçmesine yeterli olur mu? Kısmen olabilir. Fakat asıl bilgi kazanımı uygulama ile olur. Vendor ilişkisini bu geçişi sağlayacak şekilde tasarlamak mümkündür.

Shadowing -> Pairing -> Reverse pairing evrimi. Çoğu kurum shadowing aşamasında takılır. Vendor yapar kurum izler. İzlemek bilgi transferi değildir. Gerçek transfer üç aşamadan oluşur. Önce vendor yapar kurum izler (shadowing) sonra birlikte yapılır (pairing) ve en sonunda kurum yapar vendor izler ve sadece gerektiğinde müdahale eder (reverse pairing) Asıl bilgi son aşamada olur. İlk ikisi bu aşamaya gelmek için bir hazırlıktır.

Sahdowing -> pairing -> reverse pairing

Incident’larda “yolcu” değil “sürücü” olmak. Çalıştığım bir çok kurumda tecrübesi az olan arkadaşlar dev, test ortamlarında bile hata yapmaktan çekiniyorlar. Halbuki en kalıcı bilgi uygulayarak öğrenilen bilgidir. Bu ortamlarda edinilen tecrübe ile zamanla kurum çalışanı vendor’ın yolcu olduğu kontrollü bir şekilde sürücü tarafına geçmesine hazırlamak demektir.

Her değişiklik için “neden” kaydı. Vendor bir değişiklik yaptığında kurum tarafında küçük bir kayıt tutulmalıdır. Ne, neden değişti? Bu ilerki bölümde değineceğim ADR pratiğinin günlük, düşük maliyetli halidir. Amaç mükemmel bir doküman elde etmekten ziyade karar gerekçelerinin kurumda kalmadır.

3. Katman: Kurumsal Hafıza

Alışkanlıklar ve disiplin yani çalışma biçimi bilgiyi kuruma taşır. Kurumsal hafıza ise onu kalıcı kılar.

ADR pratiğini minimum maliyetle başlatmak. ADR kulağa ağır bir süreç gibi geliyor ama olması gereken tam tersidir. Bir şablon ve kural yeterlidir. Her önemli mimari karar için o kararı verirken 15 dakika ayırıp neyin neden seçildiğini hangi alternatiflerin değerlendirildiğini ve elendiklerini yazmanız yeterli olacaktır. Mükemmel olmasına gerek yok var olması yeterlidir.

Runbookların incedent’lar sonrasında zorunlu güncellenmesi. Runbooklar yazıldıkları an eskimeye başlar. Onları canlı tutmanın tek yolu sürekli güncellemekten geçer. Incedent’ların kapanması yeterli olmaz. Runbookların güncellenmemiş olması gerekmektedir. Bunu disiplinli bir şekilde yapmak operasyonel bilginin zamanla kişilerden dokümanlara taşınmasını sağlar.

Bilgi borcu kavramı. Yazılımda technical debt kavramını zaten biliyoruz. Proje başladığında hızlı ilerlemek adına ertelenen ve sonra faiziyle ödenen borçtur. Dokümante edilmeyen her karar, yapılmayan her bilgi transferi bir borçtur ve zamanla faiziyle birikir. Önerim bu borcu görünür kılmaktır. Tıpkı teknik borç gibi her sprint veya her çeyrekte bilinçli olarak task listesine eklenerek eritilmelidir. Görünmeyen borç ödenmez!

Bilgi Borcu: Teknik borç gibidir. Bugün ertelenir yarın faiziyle ödenir!

4. Katman: İnsan

Belki de bu dört katman içerisinde ki en zorudur. Çünkü en az kontrol edilebilir olanıdır. Bilgi kişide kaldığı sürece kurumsallaşamaz. Bir sistemi yalnızca bir kişi biliyorsa o kişi ne kadar yetenekli olursa olsun bu bir güç değil risktir. KOM diliyle bu Seviye 1’dir.

Bilinçli rotasyon. Tek kişi bilir durumlarını kırmanın en etkili yolu bilgiyi taşıyan ikinci bir kişiyi bilinçli olarak yerleştirmektir. Bu ilk başlarda yavaşlık getirsede uzun vadede kurtarır. Tek uzmana sahip olmak konforlu gibi görünse de o konfor kırılgandır.

İç eğitim ve bilgi paylaşımı. Bilginin kişiler arasında transferi için aksiyonların olması gerekmektedir. Bunlar; iç teknik sunumlar, birlikte kod/mimari inceleme oturumları, kurum içi yazılı paylaşım. Bu gibi aksiyonlar zaman kaybı gibi görünür ama aslında bilgi borcunu ödeyen etkinliklerdir.

Bir gerçeği kabul etmek. İnsanlar farklıdır. En iyi mühendis bile bir gün başka bir yere gider. Bu bir ihtimal değil kesinliktir. Kurumsal hafıza tam da bu kesinliğe karşı bir sigortadır. Kişilere yatırım yapmak önemli ve gereklidir ama bilgiyi kişilere emanet etmek kurumsal hafıza açısından problemdir.

Bu katmanda vurgalamak istediğim bir konu daha var. Bilgi yönetimi literatüründe tacit knowledge (örtük bilgi) adında bir tanım vardır. Kişinin deneyiminde yaşayan tam ifade edilemeyen bilgi olarak geçer. Önemli bir gerçek şudur; tacit bilginin bir kısmı doğası gereği dokümante edilemez. İşte bu yüzden insan katmanı dokümantasyonun alternatifi değil ulaşamadığı yerin tamamlayıcısıdır.

Şimdiye kadar dört katmanı ve onlarca pratiği ele aldık. Ama unutmayalım ki hepsini aynı anda yapmaya çalışmak hiçbirini yapmamanın en kibar yoludur.

Peki Nereden Başlamalı?

Önceliklendirme için tavsiyem KOM matrisine geri dönün. Her sistemi iki eksende düşünün. Kritikliği yüksek ama sahiplik seviyesi düşük olan sistemler kırmızı bölgenizdir. İşte başlangıç yeri tamda burasıdır.

Nereden başlamalı

Bir ofis aracının bilgi Seviyesi 1 olabilir. Bu bir felaket değildir. Ancak gelir üreten, müşteriye dokunan veya regüle edilen bir sistemin operasyonel bilgi Seviyesi 1 ise tüm playbook’u önce oraya uygulayın. Bilgiyi geri kazanmak bir “bir bang” projesi değildir. Sabırlı olun ve en kritik sistemde en zayıf katmandan başlayın.

Kısacası;

• Knowledge Lock-in’den çıkış vendor’u koymakla olmaz aksine vendor’la çalışma biçimini değiştirmekle olur.
• Sözleşme içerisinde ki küçük değişiklikler bilgi transferini bir dilekten çıkarıp yükümlülük haline getirebilir.
• Çalışma biçiminde kurum içinde ki ekiplere sürücü olma fırsatını vermek izleyen bir ekipten uygulayan bir ekibe dönüşümün sağlayabilir.
• Kurumsal hafıza bilginin kişilerden dokümanlara taşınmasını sağlayabilir.
• Ve en önemlisi insan katmanı. Hiçbir sistemin tek bir kişiye bağlı kalmamasını sağlar.

Bu maddelerin hiçbiri tek başına yeterli değildir. Ama beraber bilgiyi yeniden kuruma kazandırmakta harika birer takım oyuncusu olurlar.

Peki tüm bu pratikleri kim kontrol edecek kim sürdürecek? Bir sonra ki projede unutulup göz ardı edilmeyeceğini kim garanti edecek? İşte burada devreye yönetişim girmektedir. Çünkü artık konu basit bir playbook değildir. İşte serinin son yazısında da bu konuyu ele alacağım. Bu pratiklerin kişilere ve projelere bırakıldığında neden eridiğini ve kalıcılığın neden kurumsal mimari yönetişimine gömülmekten geçtiğini ele alacağım.

Sabırla okuyup zaman ayırdığınız için teşekkür ederim. Geri dönüşlerinin benim için değerlidir.