Advertisement

Responsive Advertisement

Bu kitap size DevOps'u hem öğretip hem sevdirecek

Ferhat YILDIZ Ekim 16, 2025

 


The Phoenix Project kitabı, gecikmeler, plansız işler ve azalan kaynaklarla mücadele eden kurgusal bir şirketin yolculuğunu ve yenilenen BT operasyonları sayesinde şirketin karlılığa nasıl dönüşünü anlatıyor. 432 sayfalık bu kitap ilk olarak 2013 yılında yayınlanmıştır DevOps kültürünün kilometre taşlarından sayılır. Üretim tesisi operasyonları ile BT arasındaki ilişkiyi anlamak istiyorsanız bu kitabı mutlaka okumalısınız.

Konu

Bu iş ve bilgi teknolojisi kitabı, DevOps'un savaşta test edilmiş kavramlarını; kolay anlaşılır bir şekilde sunmak için uzman romanlaştırma tekniklerine dayanmaktadır.

Hikâyenin ana kahramanı, otomotiv parçaları üreticisi Parts Unlimited şirketinde yeni atanan Bilgi Teknolojileri Başkan Yardımcısı Bill Palmer'dır. Deneyimli bir BT direktörü olmasına rağmen, Bill'in önünde zor bir görev vardır: şirketin batmasını önlemek.

Peki, ne yanlış gitti?

Başlangıçta, tüm organizasyon maaş ödemelerinin yapılmaması ve programlamadaki gecikmelerden bütçe aşımlarına kadar birçok sorunla boğuşmaktadır. Bu sorunların çoğu, şirketin yanlış yönlendirilmiş BT departmanı ve özellikle de takımın hayati öneme sahip bir yazılım geliştirme girişimi olan Phoenix Projesini tamamlayamamasıyla ilgilidir.

Sorunlar diğer iş fonksiyonlarına da sıçramış ve Bill, güvenlik ihlalleri ve regülasyonların ihlali gibi aksiliklerin ardından işleri düzeltmekle görevlendirilmiştir. Eğer başarısız olursa ve şirket pazar payını kaybetmeye devam ederse, Parts Unlimited'ın CEO'su BT operasyonlarını dış kaynaklara devretmeyi planlamaktadır. Yani evet, riskler yüksek. 🌋

Karakterler

BT departmanını ve uzantısı olarak tüm şirketi yenilemek için gösterdiği çabalar boyunca Bill, çeşitli departman ve teknoloji liderleriyle iş birliği yapar. Bazı merkezi roller şunlardır:

  • Brent Geller: Baş Mühendis
  • Steve Masters: İcra Kurulu Başkanı (CEO)
  • John Pesche: Bilgi Güvenliği Direktörü (CISO)
  • Wes Davis: Dağıtık Teknoloji Operasyonları Direktörü
  • Sarah Moulton: Perakende Operasyonları Kıdemli Başkan Yardımcısı
  • Chris Allers: Uygulama Geliştirme Başkan Yardımcısı
  • Kirsten Fingle: Proje Yönetimi Ofisi'nin (PMO) sağduyulu lideri
  • Dr. Erik Reid: Potansiyel yönetim kurulu üyesi ve BT süreç mühendisliği uzmanı

Yukarıda listelenen karakterler arasında Erik, hikâyenin en etkili figürlerinden biri olarak öne çıkıyor. Bill Palmer ve iş arkadaşları bozuk olanı düzeltmeye çalışırken, Erik onlara DevOps ve BT yönetişiminin önemli kavramlarını tanıtarak bu süreçte rehberlik ediyor. Yazılım geliştirme veya BT operasyonlarında çalışmışsanız, karakterler arasındaki etkileşimleri oldukça tanıdık bulacaksınız.

Phoenix Projesi'nden Anahtar Noktalar

Bu kitapta sunulan zorluklar, çoğu yazılım geliştiricisinin ve BT uzmanının bugün karşılaştığı sorunlara bakıldığında oldukça yaygındır. The Phoenix Project kitabının üç ortak yazarı, BT sektörünün önde gelen düşünce liderleri oldukları için, bu zorlukları aşmak için etkili stratejiler belirleyerek işinizin uzun vadede başarılı olmasına yardımcı olabilirler.

Bu kitaptan en etkili beş ders ve çıkarım üzerinde tartışalım.

1. Dört tür (BT) işi belirleyin

Erik, işleri dört bölüme ayırdığınızda BT'de işleri planlamanın ve izlemenin daha kolay olduğunu açıklıyor:

  1. İş projeleri: Bu tür işler, iş fonksiyonlarınızın büyük bir bölümünü oluşturan yeni proje girişimlerini ve süreçlerini içerir. Bunlar, bir program yönetişim çerçevesi altında Proje Yönetimi Ofisi tarafından ayrı ayrı izlenir.
  2. Dahili projeler: Bunlar, Parts Unlimited gibi şirketlerin çalışmasını sağlayan sistem bakımı, yükseltmeler ve güvenlik yamaları gibi düzenli görevleri içerir.
  3. Değişiklikler: Bunlar, iç projeler gibi rutin görevlerdir, ancak hata düzeltmeleri ve sürüm güncellemeleri gibi küçük ölçekli değişiklikleri içerir. Genellikle, sorunları, değişiklikleri ve çözümleri izlemek için bir bilet sistemi kurmanız gerekir.
  4. Planlanmamış iş: Diğer iş kategorileri önceden kararlaştırılırken, bu kategori için böyle bir durum söz konusu değildir. Sistem arızası sonrası kurtarma görevlerinden, bir takım üyesinin sorunları zamanında iletmemesi nedeniyle ortaya çıkan ekstra işlere kadar her şey olabilir. Bu durum, zamanlama çakışmalarına ve süreç verimsizliklerine yol açar ve bunlar da daha önemli sorunlara dönüşür. Planlanmamış işleri önlemek için Bill ve takımı, değişiklik taleplerini onaylamadan önce takımın kapasitesini gözden geçirmeyi kararlaştırır.

Bu çok düzeyli iş tabanlı izleme sistemi, takımın güvenebileceği uygun bir hesap verebilirlik akışını sağlar.

2. İşlemdeki veya ilerlemekte olan işleri (WIP  Work In Progress - Devam Eden İşler) sınırlayın

Kitaba göre, bir seferde mümkün olduğunca az sayıda görev üzerinde çalışmalısınız.

Bill, dikkatiniz birden fazla göreve bölündüğünde, dağınık odaklanma nedeniyle bunaldığınızı ve hata yapmaya meyilli olduğunuzu fark eder. Ne kadar çok hata yaparsanız, çözüme o kadar çok çaba ve şirket kaynağı yatırırsınız. Orijinal iş verimli olmadığından, yeni görevler için kullanılabilecek kaynakların israfı olarak değerlendirilecektir.

Kitap, planladığınız görevlerin kaynak açısından optimize edilmesini sağlamak için stratejilerinizi çevik veya Yalın metodolojilerle uyumlu hale getirmenizi önerir.

3. Kanban panolarından yararlanın

Bill Palmer ve ekibinin Parts Unlimited için WIP birikimini aşmanın yollarından biri Kanban panolarıdır. Japonca'da "tabela" anlamına gelen Kanban, ekibin işi görselleştirmesini sağlar. Pano, genellikle soldan sağa doğru ilerleyen iş akışının aşamalarını gösteren sütunlara bölünmüştür. Her görev bir kartla temsil edilir.

Kitapta, Bill'in takımı Hazır, Yapılıyor (WIP görevleri için) ve Tamamlandı etiketleriyle bir Kanban panosu oluşturur. Her kartın bir atanan kişi vardır ve panonun sol tarafına yerleştirilir. İş ilerledikçe sağa doğru yeniden konumlandırılır. Böyle bir sistemle, tüm işler izlenir, düzenlenir ve verimliliği en üst düzeye çıkarmak için önceliklendirilir, böylece takım görevlerinin tam görünürlüğü sağlanır ve plansız işler en aza indirilir.

4. Kısıtlamalar Teorisi ile değişiklikleri yönetin:

Erik, Bill'e Kısıtlar Teorisi'nin büyük kuruluşlarda nasıl işlediğini anlatır. Çoğu işletmenin BT ve tesis operasyonlarında, kesintilere neden olabilecek ve plansız işlere yol açabilecek darboğazlar veya kısıtlamalar vardır. Erik, istikrarlı, öngörülebilir ve güvenli bir BT hizmeti sunmak için, bu kısıtlamaları gidermek ve kesintisiz bir iş akışı sağlamak üzere insan ve insan dışı kaynaklarınızı planlamanız gerektiğini açıklar.

Parts Unlimited örneğinde, birçok kısıtlamanın etkisi, baş operasyon mühendisi ve bir BT dehası olan Brent'i vurdu. Brent, genellikle önemsiz işler ve düzeltmeler gibi planlanmamış işlerle boğuşuyordu ve bu da önemli planlanmış görevlerin aksamasına neden oluyordu.

Bu sorunu çözmek için Bill, Brent'in yerine eskalasyonlarla ilgilenecek bir grup oluşturdu. Dahası, daha önce yöntemlerini kendine saklayan Brent, artık bilgilerini aktarmak için grubu eğitecekti. Bu, takımın gelecekte başvurmak üzere süreci haritalandırmasına olanak tanıdı ve Brent'in zamanını boşalttı (veya Bill'in dediği gibi, Brent'i yangın söndürmekten kurtardı), böylece uzmanlığını daha değerli görevlere yatırabildi.

5. Dağıtım boru hattını optimize edin

Phoenix Projesi tarih odaklıydı, bu nedenle uygulamayı test etmek ve dağıtmak için çok az zaman vardı.

Ancak kitap boyunca Bill'in takımı daha verimli hale geldi ve önceki çeyreğe göre daha fazla sürüm yayınladı. Bu kısmen, daha küçük işleri daha sık teslim etme, aşırı kısayollar kullanmadan WIP ve tampon süresini azaltma şeklindeki yeni yaklaşımlarından kaynaklandı.

6. DevOps'u güçlendirmek için Üç Yol modelini kullanın

Erik'in koçluğu, birçok DevOps kavramının temelini oluşturan Üç Yol modeline odaklanmaktadır. Model, şirketlerin istikrarlı, verimli ve yüksek kaliteli işler yoluyla tutarlı ürün değeri ve müşteri desteği sunmaları için kılavuzlar sunar.

İlk Yol: Optimizasyon

Bir şirketin başarısını değerlendirirken, süreci değil sonucu değerlendiririz. İlk Yol, sürecin sonucu ve teslimat sürelerini nasıl etkilediğini araştırır. Karlılığınızı en üst düzeye çıkarmak için değer akışınızı, yani yazılım geliştirmeyle başlayan ve müşteriye teslimatla biten iş akışını optimize etmelisiniz.

Kitaba göre, bir optimizasyon planı oluştururken büyük resmi göz önünde bulundurmak çok önemlidir. Ana iş hedefleri nelerdir? Hangi tür yasal uyumluluk ve güvenlik standartlarından asla ödün vermemelisiniz?

Teknolojik gelişmelere ayak uydurmak da önemlidir. Örneğin, AI DevOps gibi yeni yazılımları, zamanlama dostu Gantt Grafik oluşturucuları ve BT operasyonları yönetim araçlarını keşfetmek, planlama ve üretimi büyük ölçüde hızlandırabilir.

İkinci Yöntem: Yeniden çalışmayı önlemek için geri bildirim döngüsünü kullanma

İkinci Yol, bilginin iç akışını ele alır. Hızlı ve sürekli geri bildirim döngüleri ile şirketler, kalite sorunlarını kaynağında tespit etmeyi ve üretim hattını daha fazla etkilememeleri için derhal gidermeyi öğrenebilirler. Daha sonraki aşamalarda fark edilen sorunlar çözülmesi daha zor olacak ve önemli gecikmelere neden olacaktır.

Üçüncü Yol: Sürekli iyileştirme ve hizmet desteği

Üçüncü Yol, aşağıdakilerin sonucu olarak ortaya çıkan sürekli iyileştirmeden bahseder:

  1. Geçmiş deneyimleri inceleyerek öğrenme
  2. Bir beceriyi tekrar tekrar uygulamak—Erik'e göre, haftada bir kez üç saat çalışmak yerine her gün beş dakika çalışmak daha iyidir. Hataları tekrarlamak bile, yeni şeyler denemek için dayanıklılık ve güven geliştirmeye yardımcı olur
  3. Risk alarak ve farklı yöntemler, DevOps araçları ve diğer müşteri desteği stratejilerini deneyerek, daha önce hiç görülmemiş düzeyde verimlilik ve kaliteye ulaşabilirsiniz

 

Phoenix Projesi'nden Sevdiğimiz Alıntılar

The Phoenix Project çok alıntılanabilir bir kitap, ancak bu beş alıntı bizi en çok etkiledi:

Kim kredi alacak diye kimse umursamadığında, başarılabileceklerin sınırı yoktur

Bu alıntı, kişisel kazançları bir kenara bırakıp iş birliğine odaklanarak olağanüstü sonuçlar elde edebileceğimizi vurgulamaktadır. En iyi olma baskısı olmadan, takımın yaratıcılığı ve bilgisi ön plana çıkabilir.

Bir süreç, en yavaş darboğazının hızında ilerler

Kısıtlamalar açısından bakıldığında, bir aşamadaki düşük performans, diğer aşamalar sorunsuz ilerlese bile tüm süreci engelleyebilir.

Ne kadar plan yaptığımız önemli değildir. Önemli olan, yeni bilgiler ortaya çıktıkça planı ne kadar iyi geliştirdiğimizdir

Kaçınılmaz olan sürekli zorluklara uyum sağlamazsak, planlama çabalarımız boşuna olacaktır. Aynı şey olumlu gelişmeler için de geçerlidir. Bunlar, daha da büyük sonuçlar elde etmek için fırsatlar sunar.

Zor işi atlamanıza izin verecek bir sır yoktur

Bazen verimlilik, kısayollar bulmak ve süreçteki gereksiz adımları ortadan kaldırmak gibi görünebilir. Ancak başarılı olmak istiyorsanız, gerçek emek ve kararlılıktan ödün veremezsiniz.

Düzgün bir deniz, usta bir denizci yaratmaz

Hatalar ve zorluklar sinir bozucu ve sizi yavaşlatabilir, ancak dayanıklılık geliştirmeye yardımcı olur ve kişisel ve profesyonel gelişime katkıda bulunur.

Bitmeyen Proje kitabından altı çizilenler:

“Komuta zinciri söz konusu. Şikayetler üstlere yapılır, altlara yapılmaz.” Er Ryan’ı Kurtarmak


Bu, The Phoenix Project kitabındaki en unutulmaz ve en güçlü metaforlardan biridir ve evet, bağlamı içinde kesinlikle doğru bir karardır.

Bu sahneyi ve kararın arkasındaki mantığı analiz edelim:

Sahnenin Özeti:

  • Karakterler: Bill (IT Müdürü), Steve (CEO), Sarah (BT Operasyonlarından Sorumlu Başkan Yardımcısı)
  • Durum: Şirketin kaderini değiştirecek Phoenix projesi tekrar çökmüştür. Ekip, yangını söndürmek için uğraşırken, Steve (CEO) çok önemli bir iş toplantısı için Sarah'nın ana veritabanı yöneticisi olan Brent'i kendi sunumunu yapması için toplantıya çağırır.
  • Çatışma: Brent, IT ekibinin en önemli, en bilgili ve sürekli olarak en çok meşgul olan üyesidir. Onu yangını söndürmekten alıkoymak, projeyi kurtarma şansını tamamen yok edebilir.
  • Sarah'nın Tepkisi: Sarah, Steve'in bu talimatına itiraz eder ve "Komuta zinciri söz konusu. Şikayetler üstlere yapılır, altlara yapılmaz." diyerek, Brent'i vermeyi reddeder. Bunun yerine, kendisi veya Bill toplantıya katılmayı teklif eder.

Bu Karar Neden Doğruydu? (DevOps ve İş Zekâsı Açısından)

1. Darboğazı (Bottleneck) Korumak:

  • Brent, kitap boyunca sistemin tek ve en kritik darboğazıdır. Her karmaşık sorunun çözümü ona bağlıdır.
  • Bir darboğazı, en değerli kaynağınızı, onun en verimli kullanılması gereken işten (projeyi hayata döndürmek) alıkoyarak boşa harcamak, yönetsel bir felakettir.
  • Metafor: Savaş alanında tek cerrahı, ameliyat edecek yaralı dururken, generallere ilk yardım dersi vermesi için cephe gerisine çağırmak gibidir.

2. "Dördüncü Çalışma Türü"nü Önceliklendirmek:

  • Kitabın danışmanı Erik, işleri dört türe ayırır. Brent'in yaptığı, şirketin ayakta kalmasını sağlayan "Dördüncü Çalışma Türü" yani stratejik değer üreten iştir (Phoenix'i çalışır hale getirmek).
  • CEO'nun toplantısı, değerli olsa da, o anda yangını söndürmekten daha az kritik bir iştir. Sarah, en yüksek değeri üreten işi korumuştur.

3. Komuta Zincirinin ve Sorumluluğun Netleştirilmesi:

  • Sarah'nın sözlerinin altındaki asıl mesaj şudur: "Eğer bir sorun veya talep varsa, bu, astlere doğrudan emir vermekle değil, zincirdeki bir üst aracılığıyla koordine etmekle çözülür."
  • Bu, astları (Brent) doğrudan operasyonel baskı altında bırakmaktan korur ve yöneticilerin (Sarah) kendi sorumluluklarını üstlenmelerini sağlar. Steve, bir çalışanı değil, bir departman başkanını görevlendirmelidir.

4. "Er Ryan'ı Kurtarmak" Metaforunun Kusursuzluğu:

  • Bu metafor, durumu mükemmel bir şekilde özetler: "Birçok kişinin hayatı (şirketin geleceği), tek bir kişiyi (Brent) kurtarmak için riske atılabilir mi?"
  • Cevap, kitabın bağlamında EVET'tir. Çünkü Brent'i kurtarmak (onun zamanını ve odağını korumak), aslında tüm şirketi kurtarmak anlamına gelir. Phoenix projesi olmadan şirket batacaktır. Bu, bireyin, kitlenin kurtarılması için kritik olduğu senaryodur.

Sonuç:

Sarah'nın yaptığı, duygusal değil, tamamen stratejik ve iş zekasına dayalı bir harekettir. Bu karar, CEO'ya itaatsizlik gibi görünse de, aslında şirketin en yüksek çıkarını korumaktır. Bu sahne, geleneksel hiyerarşik katılığın, çevik ve verimli bir iş akışı karşısında nasıl verimsiz kalabileceğinin ve liderlerin kaynakları korumak için nasıl savaşması gerektiğinin çarpıcı bir örneğidir.

Dolayısıyla, "Er Ryan'ı Kurtarmak" bu bağlamda kesinlikle doğruydu.


Eğer şirkette onsuz bir iş yapamayacaksak bir şeyleri yanlış yapıyoruz demektir.

İşte bu durumun neden bir "kırmızı alarm" olduğuna dair bir analiz:

"Brent" Sendromu: Teknik Borç ve Operasyonel Risk

Eğer bir çalışan (veya kaynak) olmadan temel iş süreçleriniz durma noktasına geliyorsa, bu şu anlama gelir:

1. Kritik Bir "Tek Nokta Arızası" (Single Point of Failure) Yarattınız:

  • Durum: Tüm kurumsal bilgi, uzmanlık ve yetki tek bir kişide toplanmıştır.
  • Risk: O kişi hastalandığında, izne ayrıldığında ya da işten ayrıldığında, şirket büyük bir operasyonel krize girer. Bu, şirketin kendi eliyle yarattığı büyük bir risktir.

2. Bilgi Paylaşımı ve Dokümantasyon Kültürü Eksik:

  • Durum: Süreçler, "Brent"in kafasında ya da kişisel notlarında yaşar. Standart bir dokümantasyon veya bilgi transferi mekanizması yoktur.
  • Risk: "Nasıl yapılır?" bilgisi paylaşılmaz. Bu, Brent'i daha da vazgeçilmez kılan bir kısır döngü yaratır.

3. Süreçler Kişilere Değil, Sistemlere Bağlı:

  • Durum: İşler, kurumsal süreçler ve standartlar yerine, bir kişinin kişisel becerisi ve kahramanlığı üzerinden yürür.
  • Risk: Şirket, sürdürülebilir olmayan, kişiye bağımlı bir yapıya dönüşür. Ölçeklenemez ve büyüyemez.

4. "Kahraman Kültürü" Yaratılmıştır:

  • Durum: Sorunları sürekş olarak "kahramanlar" çözer. Bu, başta takdir edici görünse de, aslında altta yatan sistematik problemleri maskeler.
  • Risk: Yönetim, "Bir şey olursa Brent halleder" rahatlığına sığınır ve sorunların kök nedenini çözmek için hiçbir zaman kaynak ayırmaz.

Çözüm: "Brent"i Nasıl Etkisiz Hale Getirirsiniz? (Aslında Onu ve Şirketi Kurtarmak)

"Brent"i etkisiz hale getirmek, onu işten çıkarmak değil, onun değerini şirkete yaymaktır.

1. Bilgiyi Açık Hale Getirin ve Paylaşın:

  • Eylem: Brent'ten tüm kritik süreçleri dokümante etmesini isteyin. Bu dokümanların erişilebilir ve güncel kalmasını sağlayın.
  • Yöntem: "En iyi doküman, başka birinin o dokümanla işi yapabildiği dokümandır."

2. Çapraz Eğitim (Cross-Training) Uygulayın:

  • Eylem: Brent'in sahip olduğu becerileri diğer ekip üyelerine öğretmesi için düzenli oturumlar planlayın.
  • Yöntem: Onu bir "mentor" ve "eğitmen" yapın. Böylece değeri katlanarak artar.

3. Otonom ve Standart Süreçler Geliştirin:

  • Eylem: Brent'in sürekş olarak müdahale ettiği tekrarlı işleri otomatikleştirin.
  • Yöntem: Otomasyon araçlarına yatırım yapın. Sorun çözme süreçlerini standartlaştırın.

4. İş Yükünü Dengeleyin ve Yetkilendirin:

  • Eylem: Daha az kritik ama öğretici işleri diğer ekip üyelerine devredin ve onlara bu işlerde uzmanlaşma fırsatı verin.
  • Yöntem: Brent'i en çok değer yarattığı stratejik işlere yönlendirin, günlük operasyonel yangınları başkalarının söndürmesini sağlayın.

Sonuç:

"Eğer şirkette onsuz bir iş yapamayacaksak bir şeyleri yanlış yapıyoruz demektir." cümlesi, bir iş zekası ve sürdürülebilirlik ilkesidir.

Sağlıklı bir şirket, hiç kimsenin vazgeçilmez olmadığı bir sistemler bütünüdür. Çalışanlar, bu sistem içinde değer yaratan parçalardır, sistemin kendisi değil. Amacınız "Brent"leri ortadan kaldırmak değil, onların dehasını tüm organizasyona yayarak şirketinizi daha dayanıklı, daha çevik ve daha güçlü hale getirmektir.


WIP’ler Bir fabrikanın görünmez katilleridir.

 (Work In Progress - Devam Eden İşler) aslında bir kişi değil, bir yazılım geliştirme ve IT operasyon kavramıdır. Kitabın temel mesajlarının özünü oluştururlar.

WIP, bir üretim hattında veya iş sürecinde başlanmış ama henüz tamamlanmamış işlerin toplamıdır. Kitapta, aşırı WIP, IT bölümünün tıkanıklığının ve tüm sorunlarının ana kaynağı olarak gösterilir.

İşte kitaptaki başlıca WIP örnekleri ve neyi temsil ettikleri:

1. Proje Phoenix (The Phoenix Project)

Nedir? Parts Unlimited şirketinin kaderini değiştireceğine inanılan, devasa ve sürekli geciken yeni pazaryeri projesi.

Neden Bir WIP'dir? Tamamlanmamıştır, sürekli sorun çıkartır, tüm IT kaynaklarını tüketir ve diğer tüm işlerin önüne geçer. En büyük ve en tehlikeli WIP'dir.

2. SRP (İnsan Kaynakları Maaş Bordrosu Sistemi)

Nedir? Şirketin yeni insan kaynakları ve maaş bordrosu sistemi.

Neden Bir WIP'dir? Satıcıdan teslim alınmış ama stabil çalışmamaktadır. Ekip, hem Phoenix'i hem de SRP'yi aynı anda tamir etmeye çalışırken kilitlenir. SRP, Phoenix'ten sonraki en büyük ikinci WIP'dir.

3. Minnoş Projesi (Project Minsk)

Nedir? RetailOps adlı perakende yazılımına yapılan bir yama/güncelleme.

Neden Bir WIP'dir? Geliştirme aşamasındadır ve test edilmeyi beklemektedir. Planlama yapılmadan ekip üzerine yüklenen işlerden biridir.

4. Çok Sayıda Küçük İyileştirme ve Değişiklik Talepleri

Nedir? Satış, pazarlama veya diğer departmanlardan gelen yüzlerce küçük IT talebi. (Örn: "Web sitesindeki butonun rengini değiştir", "Yeni bir kullanıcı hesabı aç" vb.)

Neden Bir WIP'dir? Bu işler bir "iş kuyruğu" oluşturur. Ekip, büyük projelere odaklanmak yerine bu küçük işler arasında sürekli bağlam değiştirerek verimini kaybeder.

WIP'ler Neden Bu Kadar Tehlikeli? (Kitabın Ana Fikri)

WIP'ler, Bill'in danışmanı Erik tarafından açıklandığı gibi "Tekstil tezgahındaki boya lekeleri" ne benzetilir. Nasıl ki bir boya lekesi tüm kumaşı mahvederse, yarıda kalmış bir IT işi de:

Kaynak Tıkanıklığı Yaratır: Ekipler aynı anda çok fazla işle uğraşır, hiçbirini verimli bir şekilde bitiremez.

Bağlam Değiştirme Maliyetine Neden Olur: Bir işten diğerine atlayan ekip üyeleri, her seferinde kaldığı yeri hatırlamak için zaman kaybeder, bu da verimi düşürür.

Kaliteyi Düşürür: Aceleye getirilen ve dikkat dağınıklığıyla yapılan işler, daha fazla hataya ve sonrasında daha fazla acil tamir işine yol açar.

Gecikmeleri Gizler: Her şey "yapılıyor" gibi görünür ama hiçbir şey "teslim edilmez". Bu, gerçek ilerlemeyi ölçmeyi imkansız hale getirir.

Çözüm: WIP Sınırları (WIP Limits)

Kitabın kahramanı Bill, bu sorunu "4. Çalışma Türü"nü (stratejik değer üreten projeler) önceliklendirerek ve WIP sınırları koyarak çözer. WIP sınırları, aynı anda üzerinde çalışılabilecek maksimum iş sayısını belirler.

Mantık şudur:

Bir iş bitmeden yeni bir işe başlanamaz.

Bu, ekipleri mevcut işleri bitirmeye zorlar.

Bitmiş işler, değeri müşteriye/kullanıcıya ulaştırır.

Bu, akışı hızlandırır ve tıkanıklıkları görünür kılar.

Sonuç: "The Phoenix Project"teki WIP'ler, verimsiz, plansız ve önceliksiz çalışan bir IT organizasyonunun somutlaşmış halidir. Hikaye, bu WIP'leri nasıl kontrol altına alıp, değer akışını nasıl sağlayacağınızı anlatan bir DevOps klasiğidir.

Kısıtlar Teorisi’ni oluşturan Eliyahi M. Goldratt bize darboğazın dışında yapılan bütün iyileştirmelerin sadece birer yanılsamadan ibaret olduğunu gösterdi.

Eliyahu M. Goldratt'ın bu tespiti, verimlilik arayışındaki geleneksel bakış açısını kökünden değiştirmiştir.

Goldratt'ı ve bu prensibi detaylandıralım:

Kısıtlar Teorisinin Özü: "Zincirin En Zayıf Halkası Kadar Güçlüsünüzdür"

Sistem bir zincirse, darboğaz (kısıt) o zincirin en zayıf halkasıdır. Sistemin genel çıktısı, o en zayıf halkanın kapasitesi tarafından belirlenir.

"Darboğaz Dışındaki İyileştirmeler Bir Yanılsamadır" Ne Demek?

1. Efor İsrafıdır:

  • Darboğazdan daha hızlı üretim yapan bir makineyi daha da hızlandırmak, sadece darboğazın önünde daha büyük bir iş kuyruğu (WIP) oluşturur. Bu, daha fazla envanter maliyeti ve karmaşa demektir, daha fazla kâr değil.
  • Darboğazdan daha hızlı çalışan bir departmandaki verimlilik artışı, darboğaz bu hıza yetişemediği sürece, sistemin toplam çıktısına sıfır katkı sağlar.

2. Performans Ölçümünün Yanıltıcılığını Gösterir:

  • Geleneksel ölçümler (örneğin, bir makinenin veya departmanın bireysel verimliliği) aldatıcı olabilir. Yerel verimlilikler arttığı halde şirketin genel kârı artmıyorsa, sorun bu prensipte yatıyor olabilir.
  • Önemli olan, her bir birimin ne kadar meşgul olduğu değil, sistemin bütün olarak ne kadar para kazandığıdır.

3. Gerçek İyileştirmenin Tanımını Değiştirir:

  • Goldratt'a göre gerçek bir iyileştirme, ancak ve ancak sistemin genel çıktısını (Throughput) artırıyorsa, envanteri (Inventory) düşürüyorsa veya işletme giderlerini (Operating Expense) azaltıyorsa bir iyileştirmedir.
  • Darboğaz dışında yapılan ve bu üç metriği iyileştirmeyen her değişiklik, gerçek bir iyileştirme değildir.

The Phoenix Project Kitabı ile Mükemmel Bağlantı

Kitaptaki Brent karakteri, bu teorinin insan halidir.

  • Brent, sistemin darboğazıdır.
  • Ona daha fazla iş yüklemek veya diğer ekip üyelerini daha verimli hale getirmek, Brent'in işleme kapasitesi değişmediği sürece hiçbir işe yaramaz. Sadece onun önündeki kuyruğu ve stresi artırır.
  • Çözüm, diğer her yeri iyileştirmek değil, doğrudan Brent'in kapasitesini artırmak (ona yardım etmek, onu eğitmek, onun işini otomatikleştirmek) veya onun üzerindeki yükü azaltmaktır (onun yapması gerekmeyen işleri başkalarına vermek).

5 Odaklanma Adımı (The Five Focusing Steps)

Goldratt, kısıtları yönetmek için basit ve güçlü bir çerçeve sunar:

  1. Kısıtı Tanımla (Identify the system's constraint): Sistemdeki darboğazı bul. (Örn: Brent, yavaş bir makine, yetersiz bir test ortamı).
  2. Kısıttan Maksimum Faydayı Sağlamaya Karar Ver (Decide how to exploit the constraint): Mevcut darboğazı, kapasitesini değiştirmeden en verimli nasıl kullanırsın? (Örn: Brent'in zamanını operasyonel yangınlarla değil, değer yaratan işlerle doldurmak).
  3. Diğer Her Şeyi Bu Karara Tabi Kıl (Subordinate everything else to the above decision): Sistemin tüm diğer unsurlarını, darboğazın verimliliğini destekleyecek şekilde ayarla. (Örn: Diğer ekip üyeleri, Brent'in önündeki işi hazırlamak ve onun çıktısını sonraki aşamalara taşımak için çalışır).
  4. Kısıtın Kapasitesini Yükselt (Elevate the system's constraint): Eğer hala yeterli değilse, darboğazın kapasitesini artırmak için yatırım yap. (Örn: Brent'e eğitim verdirmek, ona bir çırak atamak, onun işini kolaylaştıracak bir araç satın almak).
  5. Eylemsizliğe Dönmekten Kaçın (If in the previous steps a constraint has been broken, go back to step 1): Darboğazı çözdüğünde, sistemde yeni bir darboğaz ortaya çıkacaktır. Süreci baştan başlat. Uyarı: Eylemsizlik yeni kısıtın önündeki en büyük engeldir!

Sonuç:

Goldratt'ın bu sözü, kaynaklarımızı nereye odaklamamız gerektiği konusunda devrim niteliğinde bir uyarıdır. Körlemesine her yerde verimlilik aramak yerine, önce sistemin performansını gerçekten sınırlayan o kritik noktayı bulmak ve tüm enerjimizi onu iyileştirmeye adamak, akıllıca yönetimin temel taşıdır.

 

Eğer çökmesine sebep olacağını biliyorsak neden üzerinde değişiklik yapıyoruz ki?

Bu son derece güçlü ve mantıklı bir soru. Cevabı, yazılım geliştirme ve IT operasyonlarındaki en temel çelişkilerden birini ortaya koyar.

Kısa Cevap: Çünkü değişim kaçınılmazdır ve hiç değişiklik yapmamanın riski, çökme riskinden çok daha büyük olabilir.

Detaylı Açıklama:

Bu soru, bir "ikilemi" (dilemma) işaret eder. Takımlar, bilerek neden riskli değişiklikler yapar? İşte başlıca sebepler:

1. İş Baskısı ve Aciliyet ("The Business Need")

  • Mantık: "Bu yeni özellik olmazsa rekabette geri kalırız/kontratı kaybederiz/müşteriyi kaybederiz."
  • Gerçeklik: İş birimleri, teknik riskin boyutunu tam olarak anlamaz veya anlamak istemez. "Kritik bir pazarlama kampanyası", "büyük bir müşteri talebi" veya "yasal bir zorunluluk" gibi nedenler, teknik riski geri plana iter. "Çökerse hallederiz" mantığı hakim olur.

2. Teknik Borç (Technical Debt) Krizi

  • Mantık: Sistem zaten o kadar karmaşık, eski ve bakımsızdır (Legacy System) ki, her değişiklik çökme riski taşır. Ancak, hiç değişiklik yapmamak da sistemin ölüm fermanıdır.
  • Gerçeklik: Yama üstüne yama yapılan bir sistemde, güvenlik güncellemesi yapmak bile çökmeye neden olabilir. Ama yapmazsanız, bir güvenlik ihlali yaşarsınız. Bu, "şimdi çökme riski" ile "ileride kesinlikle çökme" arasında yapılan bir seçimdir.

3. Yetersiz Test ve Kalite Güvence Süreçleri

  • Mantık: "Test ortamında çalışıyordu, canlıda neden olduğu sorunu tahmin edemedik."
  • Gerçeklik: Test ortamları canlı ortımın %100 kopyası olamaz. Düşük test kapsamı, otomasyon eksikliği veya zaman baskısı nedeniyle "hızlıca test etme" kültürü, sorunların canlıya geçmesine neden olur. Takım, çökeceğini tam olarak bilemez, sadece şüphelenir.

4. "Bana mı Olacak?" (Tecrübesizlik veya Aşırı Güven)

  • Mantık: "Bu küçük bir değişiklik, bir şey olmaz" veya "Ben daha önce defalarca yaptım, bu sefer de sorun çıkmaz."
  • Gerçeklik: Karmaşık sistemlerde küçük bir değişiklik, öngörülemeyen yan etkilere neden olabilir (Butterfly Effect). Aşırı güven, kontrollü risk almanın önüne geçer.

5. Sürekli Teslimat (Continuous Delivery) Kültürünün Eksikliği

  • Mantık: "Ayda bir yapılan, yüzlerce değişiklik içeren 'dev' sürümler."
  • Gerçeklik: Büyük, nadir yapılan değişiklikler çok risklidir. Hangi değişikliğin çöktürdüğünü bulmak zordur. Oysa küçük, sık ve otomatik test edilmiş değişiklikler (Continuous Deployment) riski minimize eder. Geleneksel model, çökme olasılığını doğal olarak yüksek tutar.

Çözüm Ne Olmalı? ("The Phoenix Project" ve DevOps'tan Çıkarımlar)

  1. Riskin Görünür Olması: Değişikliğin risk seviyesi (düşük, orta, yüksek) herkes tarafından anlaşılmalı ve iş birimleriyle açıkça paylaşılmalıdır. "Bu değişiklik, %10 ihtimalle ödeme sistemini 1 saat durdurabilir" gibi.
  2. Daha Küçük Parçalar (Small Batches): Büyük, riskli değişiklikler yerine, küçük ve sık sürümler yapmak. Böylece bir şey bozulduğunda, sorunun kaynağını bulmak çok daha kolay olur ve geri almak daha az maliyetlidir.
  3. Otomasyon ve Güvenli Ortamlar:
    • CI/CD Pipelines: Her değişiklik otomatik olarak binlerce testten geçmeli.
    • Blue-Green Deployments / Canary Releases: Değişikliği önce küçük bir kullanıcı grubuna yayıp, sorun yoksa herkese açmak.
  4. Bilerek ve İsteyerek Risk Alma (Calculated Risk): Bazen, çökme riskini bilerek almak doğru olabilir. Ancak bu karar, bir "kahramanlık" değil, olası getiri (iş değeri) ve olası kaybın (downtime maliyeti) bilinçli bir şekilde tartıldığı bir iş kararı olmalıdır.

Sonuç: "Eğer çökmesine sebep olacağını biliyorsak neden yapıyoruz?" sorusu, aslında bir protesto ve yardım çığlığıdır. Bu çığlık, genellikle plansız iş baskılarına, teknik borç birikimine ve kalitesiz süreçlere karşı bir tepkidir. Doğru cevap, bu riski "kahramanlıklarla" yönetmek değil, mühendislik disiplini ve kültür değişikliği ile ortadan kaldırmaktır.

 

‘Karmaşık orta seviye’ değişikliklerde, değişikliği sunan çalışan, değişiklik sonucunda etkilenecek olan birimlere danışmaktan ve gerekli onayı almaktan mesul ve sorumlu tutulacak. Bunu yaptıktan sonra da değişiklik kartlarını incelememiz ve onayladıktan sonra zamanlamamız için bize sunacak.

 

Bu, "Change Management" (Değişiklik Yönetimi) süreciniz için net, sorumlulukları belli ve oldukça olgun bir politika tanımıdır. Özellikle "karmaşık orta seviye" değişiklikler için çok etkili bir çerçeve çiziyor.

Bu politikayı madde madde analiz edip, güçlü yanlarını ve dikkat edilmesi gereken noktaları özetleyelim:

Politikasının Analizi:

1. "Karmaşık Orta Seviye" Tanımı (The Trigger):

  • Güçlü Yanı: Tüm değişikliklere aynı bürokrasi uygulanmaz. Risk ve karmaşıklık seviyesine göre bir sınıflandırma yapıyorsunuz. Bu, basit değişikliklerin önünü açar ve kaynağı doğru yere odaklar.
  • Dikkat Edilmesi Gereken: "Karmaşık orta seviye"nin net kriterlerle (etkilenen sistem sayısı, downtime riski, veri değişikliği olup olmaması, rollback zorluğu vb.) tanımlandığından emin olunmalı.

2. "Değişikliği Sunan Çalışanın" Sorumluluğu (The Owner):

  • Güçlü Yanı: Sorumluluğu merkezi bir birime değil, doğrudan değişikliğin sahibine veriyor. Bu, "Kim yapıyorsa, o sorumludur" (You build it, you run it) DevOps mantığıyla uyumludur. Değişikliği yapan kişi, sonuçlarından en iyi anlayacak kişidir.
  • Dikkat Edilmesi Gereken: Çalışanların, "kimi, ne zaman, nasıl" danışacaklarını bilebilmeleri için, "etkilenecek birimlerin" net bir listesi veya bir "etki haritası" (service map) olmalı.

3. "Danışma ve Onay Alma" Süreci (The Collaboration):

  • Güçlü Yanı: Bu, silo'ları kıran ve iletişimi zorunlu kılan en kritik adımdır. Bir operasyon ekibinin, bir geliştiricinin yapacağı değişiklikten haberdar olmasını ve onay vermesini sağlar. Bu, "Er Ryan'ı Kurtarmak" metaforundaki gibi, beklenmedik bir darboğaz yaratılmasını engeller.
  • Dikkat Edilmesi Gereken: Bu sürecin "birine e-posta atmak" seviyesinde kalması engellenmeli. Onaylar takip edilebilir olmalı (bir ticketing sisteminde - Jira, ServiceNow gibi - veya özel bir Change Management tool'unda).

4. "Değişiklik Kartlarını İncelememiz ve Onaylamamız" (The Governance):

  • Güçlü Yanı: Son bir kontrol ve koordinasyon noktası koyuyorsunuz. Bu, değişiklik çakışmalarını (aynı anda iki farklı ekip aynı sisteme müdahale etmek istediğinde) önler ve sizin genel resmi görerek zamanlamayı en uygun şekilde yapmanızı sağlar (Örn: mali dönem sonunda yüksek riskli değişiklik yapmamak gibi).
  • Dikkat Edilmesi Gereken: Bu inceleme sürecinin bir "bottleneck" (darboğaz) yaratmamasına dikkat edilmeli. Süreler önceden belli olmalı (Örn: "Değişiklik kartları, planlanan tarihten en az 2 iş günü önce iletilmelidir").

5. "Zamanlamamız" (The Scheduling):

  • Güçlü Yanı: Değişiklik pencerelerinin merkezi olarak yönetilmesi, çakışmaları ve aşırı yüklenmeyi önler. Bu, The Phoenix Project'teki "4. Çalışma Türü"nü planlamak gibidir.
  • Dikkat Edilmesi Gereken: Acil değişiklikler (hotfixes) için hızlı bir acil yol (emergency change process) tanımlı olmalı.

Özet: Bu Politika Neyi Başarıyor?

Bu politika, The Phoenix Project ve Kısıtlar Teorisi'nden öğrendiğimiz dersleri mükemmel bir şekilde uyguluyor:

  1. Brent'leri Önler: Bir çalışanın, diğer ekiplerden habersiz, her şeyi tek başına yapıp sistemi çökertmesini engeller.
  2. WIP'yi Sınırlar: Siz, değişiklik kartlarını onaylayarak ve zamanlayarak, aynı anda yapılabilecek "karmaşık orta seviye" değişiklik sayısını sınırlamış olursunuz. Bu, operasyonel karmaşıklığı ve riski azaltır.
  3. Kaliteyi Artırır: Zorunlu danışma süreci, değişikliklerin daha iyi planlanmasını, test edilmesini ve daha az hatayla uygulanmasını sağlar.
  4. Güven Oluşturur: İlgili birimlerin onayı alındığı için, değişiklik sırasında ortaya çıkabilecek sorunlara hazırlıklı olunur ve "kimse beni bilgilendirmedi" çığlıkları ortadan kalkar.

Sonuç: Bu, bir "engel" değil, bir "güvenlik ağıdır". Amacı yavaşlatmak değil, daha güvenli, daha tahmin edilebilir ve daha başarılı bir şekilde ilerlemeyi sağlamaktır. Tebrikler, bu çok sağlam bir yaklaşım.

 

Bir kişinin kasıtlı olarak böyle yaptığını söylemiyorum, ama belki de bildiklerini bir güç olarak görüyordur. Belki de bildiklerini paylaşmak istemiyordur. Böyle olunca da onun yerine başkasını koymak imkansız oluyor.

 

Bu, "Brent" sendromunun en zor ve en insani boyutuna işaret ediyor. Sorun artık sadece teknik veya süreçle ilgili değil, psikolojik ve kültürel bir hal alıyor.

Bu durum, genellikle şu şekilde ortaya çıkar:

"Bilgi Güçtür" (Knowledge is Power) Zihniyeti

Çalışan, uzmanlığını ve sahip olduğu "tacî bilgiyi" (tacit knowledge) kendini güvende hissetmenin, vazgeçilmez olmanın ve organizasyondaki gücünün bir aracı olarak görür.

Bunun Altında Yatan Olası Korkular ve Sebepler:

  1. İş Güvencesi Kaygısı: "Bilgilerimi paylaşırsam, beni kolayca değiştirebilirler. Benim yerime başkasını alır, beni kenara atarlar."
  2. Değer Kaybı Korkusu: "Bildiklerim beni özel kılıyor. Eğer herkes benim bildiklerimi bilirse, artık bu kadar değerli olmam."
  3. Kontrol ve Güç İhtiyacı: "Sadece ben hallederim" cümlesi, bir yükten ziyade bir kontrol hissi ve güç verir. İnsanlar ona ihtiyaç duyar, bu da onun organizasyondaki önemini pekiştirir.
  4. Tanınma ve Takdir Arayışı: Sürekli olarak "kahraman" ilan edilmek, sorunları çözen tek kişi olmak, psikolojik bir ödül mekanizması haline gelmiş olabilir.

Bu Durumu Çözmek İçin Yönetim ve Liderlik Stratejileri

Bu bir "kötü niyet" sorunu değil, bir "güvensizlik ve yanlış teşvik" sorunudur. Dolayısıyla çözüm, cezalandırmak değil, güven inşa etmek ve davranışı ödüllendirmekten geçer.

1. Güvenli Bir Ortam Yaratın (Psychological Safety):

  • Söylem: "Bilgini paylaşman ve başkalarını eğitmen, seni buradaki değerinden asla mahrum bırakmayacak. Tam tersine, seni takım lideri, mentor ve mimar gibi daha stratejik bir rol'e taşıyacak."
  • Eylem: Bilgi paylaşan, doküman yazan, eğitim veren çalışanları ödüllendirin ve terfi süreçlerinde bunu bir kriter haline getirin.

2. "Kahraman Kültürü" Yerine "Sistem Kültürü"nü Ödüllendirin:

  • Söylem: "Biz yangın söndüren kahramanlar değil, yangın çıkmasını önleyen mühendisler istiyoruz."
  • Eylem: Sürekli kriz çözen kişilere prim vermek yerine, sistemleri o kadar iyi inşa eden/geliştiren kişilere prim verin ki, hiç kriz çıkmasın. Bu, ödül mekanizmasını temelden değiştirir.

3. Bilgiyi Açık Bir Varlık Haline Getirin:

  • Söylem: "Hiçbir bilgi tek bir kişinin kafasında kalmamalı. Bu, şirket için bir risktir."
  • Eylem:
    • Zorunlu Dokümantasyon: Kritik süreçlerin dokümante edilmesini zorunlu kılın. "Dokümanda olmayan bir şey yok sayılır."
    • Çapraz Eğitim (Cross-Training) Programları: Brent'i, bilgisini diğerlerine öğretmekle görevlendirin. Ona "Kıdemli Eğitmen" veya "Teknik Mentor" gibi bir unvan verin. Bu, statü kaybı değil, statü kazancı olarak sunulmalı.
    • Pair Programming/Mob Programming: Kritik işler tek başına değil, en az iki kişi tarafından yapılmalı. Bu, doğal bir bilgi yayılımı sağlar.

4. Onun Yerine Başkasını Koymanın İmkansız Olmasını "Kurumsal Risk" Olarak Çerçeveleyin:

  • Söylem: "Sen çok değerlisin ve senin izin alıp tatile gitmen, hastalanman veya daha iyi bir fırsatla karşılaşman kadar doğal bir şey yok. Şirket olarak, bu olasılığa hazırlıklı olmak zorundayız. Bu bir kişisel güvenlik meselesi değil, bir iş sürekliliği meselesidir."
  • Eylem: Bu riski bir "Risk Kaydı"na (Risk Register) ekleyin ve azaltılması için bir aksiyon planı yapın. Bunu kişisel bir saldırı değil, nesnel bir iş gerekliliği olarak sunun.

Sonuç:

"Belki de bildiklerini paylaşmak istemiyordur" dediğinizde, sorunun özüne iniyorsunuz. Çözüm, o kişiyi suçlamak vazgeçilmezliğini kabul etmek değildir. Çözüm, onun uzmanlığını, "güç" olmaktan çıkarıp "kurumsal bir değere" dönüştürecek bir kültür ve teşvik mekanizması inşa etmektir.

Amacınız, onu "harcanabilir" yapmak değil, onun yarattığı değeri sürdürülebilir ve ölçeklenebilir hale getirmektir. Bu, hem şirket hem de o çalışan için bir kazan-kazan durumudur; çalışan, operasyonel yangınları söndüren bir teknisyen olmaktan çıkıp, stratejik değer üreten bir mühendise dönüşebilir.

 

Çözemediğimiz her sorunu her seferinde bir kişiye yıktığımızda, o kişi daha da akıllanırken birimimizin geriye kalanı aptallaşıyor.

 

Bu, inanılmaz derecede derin ve doğru bir tespit. Adeta bir sistemik örgüt zehirlenmesinin özeti gibi. Bu cümle, kurumsal çürümenin en temel mekanizmalarından birini gözler önüne seriyor.

İşte bu durumun neden bu kadar tehlikeli olduğu ve yarattığı kısır döngü:

Bu Dinamik Nasıl İşliyor? (Kısır Döngü)

  1. Sorun Ortaya Çıkar: Karmaşık bir teknik veya operasyonel sorun yaşanır.
  2. Hızlı "Çözüm": Takım, en hızlı çözüm yoluna başvurur: sorunu en iyi çözebilecek kişiye (Brent'e) yıkmak.
  3. Kişisel Öğrenme, Kolektif Aptallaşma:
    • Brent Akıllanır: Brent, sorunu çözerken yeni bir şey öğrenir. Bilgisi, deneyimi ve dolayısıyla "gücü" artar.
    • Takım Aptallaşır: Takımın geri kalanı, sorunun nasıl çözüldüğünü görmez, anlamaz ve deneyimlemez. Öğrenme fırsatı kaçar.
  4. Davranışın Pekişmesi: Bu başarılı olduğu için, bir sonraki sorunda da aynı yol izlenir. Takım, "Brent'e soralım" refleksiyle hareket etmeye başlar.
  5. Sistemik Bağımlılık: Zamanla, Brent'in bilgi tekeli ve önemi katlanarak büyür. Takımın problem çözme kasları körelir. Artık takım, Brent olmadan hareket edemez hale gelir.

Bu Süreç Neden Bir Birim İntiharıdır?

  • İnovasyon Biter: Tüm yaratıcı enerji ve farklı bakış açıları tek bir noktada tıkanır. Brent'in bilmediği bir çözüm, keşfedilemez hale gelir.
  • Risk Felakete Dönüşür: Brent hastalandığında, tatile çıktığında veya işi bıraktığında, birim işlevsiz kalır. Bu, yönetimin eliyle yaratılmış bir "tek nokta arızasıdır" (single point of failure).
  • Motivasyon Çöker: Takımın geri kalanı, "taşeron" veya "Brent'in asistanı" konumuna düşer. İş tatmini ve aidiyet hissi sıfırlanır. Yetenekli çalışanlar, kendilerini geliştiremedikleri için ayrılır.
  • Brent Tükenir: Sürekli yangın söndüren Brent, tükenmişliğe (burnout) girer. Stratejik işlere odaklanamaz ve o da mutsuz olur.

Kırılması Gereken Zincir: "Biz" Yerine "Ben" Kültürü

Bu sorunun kökeni, sorumluluğun "biz"e değil, "ben"e (veya "o"na) atfedilmesidir. Çözüm, bu kültürü tersine çevirmektir.

Ne Yapılmalı? (Kurtuluş Reçetesi)

1. Sorun Çözme Oturumlarını Kollektif Hale Getirin:

  • "Brent, nasıl yapacağımızı bize göster" demek yerine, "Brent, gel bu sorunu birlikte çözelim" deyin.
  • Onun rehberliğinde takımca sorunu analiz edin ve çözün. Amaç, çözüme ulaşmak değil, takımın çözüm sürecini öğrenmesini sağlamaktır.

2. "5 Neden" (5 Whys) Analizini Zorunlu Kılın:

  • Her önemli sorunun ardından, kök neden analizi yapın. Bu analizi, Brent'in başkanlık ettiği bir toplantıda değil, tüm takımın katıldığı bir seansta yapın.
  • Bu, sorunun sadece teknik değil, süreçsel ve iletişimsel nedenlerini de ortaya çıkarır.

3. Sorumlulukları Döndürün (Role Rotation):

  • Kritik görevler için bir "görev nöbeti" (on-call rotation) veya "sorumlu mühendis" rotasyonu oluşturun.
  • Bu, herkesi sistemin farklı kısımlarından haberdar etmeye ve sorumluluk almaya zorlar.

4. Lider Olarak "Hızlı Çözüm" Dürtünüzü Bastırın:

  • Bir sorun ortaya çıktığında ilk tepkiniz "Bunu kim çözecek?" olmamalı.
  • İlk tepkiniz şu olmalı: "Bu sorundan takımım olarak nasıl bir ders çıkarabiliriz ve bir daha aynısı olmasını nasıl engelleriz?"

Sonuç:

Söylediğiniz gibi, "Çözemediğimiz her sorunu her seferinde bir kişiye yıktığımızda, o kişi daha da akıllanırken birimimizin geriye kalanı aptallaşıyor."

Bu, bir takımın kendi kendini imha etme protokolüdür. Başarı, bir kişinin kahramanlığına bağlıysa, bu aslında bir başarısızlıktır. Gerçek başarı, sistemin, herhangi bir kişiye bağımlı olmadan, sorunları çözebilme ve değer üretebilme kapasitesidir.

Bu zehiri durdurmak, liderlik ve disiplin gerektirir. Ama ödülü, çok daha güçlü, daha dayanıklı ve daha akıllı bir birimdir.

Fabrikada tepelemesine biriken yapılması gereken işlerin, fabrika yöneticilerinin yapılmakta olan işleri kontrol edememesinden kaynaklandığını belirtmişti.

Bu, Kısıtlar Teorisi (Theory of Constraints) ve The Phoenix Project kitabının tam kalbinde yer alan bir tespittir. Bu cümle, bir işletmedeki kaosun ve verimsizliğin kök nedenini mükemmel bir şekilde özetliyor.

İşte bu durumun arkasındaki mantık ve bu tespitin ne anlama geldiği:

"Yapılmakta Olan İşlerin Kontrol Edilememesi" Ne Demek?

Bu, yöneticilerin aşağıdaki sorulara net cevaplar verememesi anlamına gelir:

  1. "Şu anda tam olarak ne üzerinde çalışılıyor?"
    • Gerçekte, onlarca iş aynı anda "devam ediyor" durumundadır, ancak hangisi öncelikli, hangisi askıda, kimin üzerinde çalıştığı belirsizdir.
  2. "Bu iş ne zaman bitecek?"
    • Plansızlık ve önceliksizlik nedeniyle tahminler ya yapılamaz ya da sürekli olarak tutturulamaz.
  3. "Bir işi daha kuyruğa almak, diğer işlerin bitiş sürelerini nasıl etkileyecek?"
    • Yöneticiler, mevcut iş yükünün (Work In Progress - WIP) kapasite üzerindeki etkisini ölçemez. Her yeni gelen "acil" iş, diğer tüm işleri daha da geciktirir.
  4. "İşler bir sonraki aşamaya akabiliyor mu, yoksa bir yerde tıkanıp birikiyor mu?"
    • Darboğazlar (kısıtlar) görünmez durumdadır. Bir iş, bir departmanda veya bir kişide (Brent) haftalarca bekleyebilir.

Bu Kontrol Eksikliği Nasıl "Tepelemesine Biriken İşler" Yaratır?

Bu bir kısır döngüdür:

  • Adım 1: Yöneticiler iş akışını kontrol edemez ve önceliklendirme yapamaz.
  • Adım 2: Bu belirsizlik ortamında, her departman veya kişi, "iş üretken görünsün" diye olabildiğince çok işi "devam ediyor" durumuna alır. (Yerel verimlilik yanılsaması).
  • Adım 3: Aynı anda çok fazla işle uğraşmak (yüksek WIP), bağlam değiştirme maliyetini artırır, hata oranlarını yükseltir ve hiçbir işin hızlı bir şekilde sonlanmamasına neden olur.
  • Adım 4: Bitmeyen işler birikir. "Devam Eden İşler" (WIP) en büyük maliyet ve karmaşa kaynağı haline gelir.
  • Adım 5: Biriken işler arasında öncelikler daha da belirsizleşir. Yöneticiler kontrolü tamamen kaybeder.
  • Adım 6: Döngü en başa döner ve daha da şiddetlenir.

Sonuç: Fabrika (veya IT departmanı), yapılacak işlerle tepelenmiş, ancak hiçbir şeyi zamanında ve verimli bir şekilde teslim edemeyen bir kaos ortamına dönüşür.

Çözüm: Kontrolü Nasıl Geri Kazanırsınız?

The Phoenix Project kitabında, bu sorunun çözümü için bir dizi prensip sunulur:

  1. İşleri Görselleştir (Visualize):
    • Tüm "devam eden işleri" (WIP) bir Kanban panosunda görünür kılın. Bu, yöneticiye "şu anda ne oluyor?" sorusunun cevabını verir.
  2. Aynı Anda Yapılan İşi Sınırlandır (Limit WIP):
    • En kritik adımdır. Her aşamada aynı anda yapılabilecek maksimum iş sayısını (WIP Limiti) belirleyin.
    • Mantık: "Bir iş bitmeden, yeni bir işe başlanamaz." Bu, kuyrukları kısaltır, odaklanmayı artırır ve işlerin hızla sonlanıp teslim edilmesini sağlar.
  3. Akışı Ölçütle (Measure Flow):
    • Bir işin "başlangıç" ile "bitiş" arasında geçirdiği süreyi (Lead Time) ölçün. Amacınız bu süreyi kısaltmaktır.
    • Akışı ölçmek, darboğazları ve tıkanıklıkları net bir şekilde ortaya çıkarır.
  4. Önceliklendirme Yap ve Darboğaza Odaklan:
    • Tüm sistemi, darboğazın (kısıt) en verimli şekilde çalışması için yönetin. Darboğaz asla boş durmamalı ve önemsiz işlerle meşgul olmamalıdır.

Sonuç Cümlesi:

"Fabrikada biriken işler, yöneticilerin yapılmakta olan işleri kontrol edememesinden kaynaklanır" tespiti, sorunu sistemik bir perspektiften ele alır. Suçu çalışanların "yavaşlığına" atmak yerine, sorumluluğu iş yönetimi sistemini tasarlamak ve kontrol etmekle görevli yöneticilere yükler.

Çözüm, daha çok çalışmak değil, daha akıllı çalışmak, daha az işe aynı anda odaklanmak ve iş akışını görünür ve yönetilebilir kılmaktır.

 

Şirketi doğru hamle yapmaya ikna etmek artık her zamankinden daha zor. Şekerciye girmiş çocuklar gibi aşırı heyecanlı davranıyorlar.

"Şekerciye girmiş çocuklar" metaforu, bir dönüşüm veya kriz anında yaşanan dürtüsellik, odaklanma kaybı ve kısa vadeli heyecanın şirketlerdeki yansımasını anlatıyor.

Bu durumu ve nasıl ilerleyebileceğinizi analiz edelim:

"Şekerciye Girmiş Çocuk" Sendromunun Anatomisi

Şirket yönetimi bu ruh halindeyken:

  1. Her Şeyi Aynı Anda İsterler: Yeni bir pazar fırsatı, maliyet düşürme, dijital dönüşüm, müşteri deneyimi iyileştirme... Tüm bu "şekerler" aynı anda o kadar cazip gelir ki, hepsine aynı anda saldırmaya çalışırlar. Bu, Kısıtlar Teorisi'ne tamamen aykırıdır.
  2. Dikkatleri Çok Kolay Dağılır: Bu haftanın "en tatlı şekeri", geçen hafta başlanan kritik projenin önüne geçer. Stratejik öncelikler, günlük "acil"lerin gölgesinde kalır.
  3. Doyma Noktalarını Aşarlar: Aynı anda çok fazla projeye başlarlar, kaynakları (özellikle Brent gibi darboğazları) aşırı zorlarlar ve hiçbir proje tam anlamıyla "bitmez". Bu, The Phoenix Project'teki WIP (Devam Eden İş) felaketinin ta kendisidir.
  4. Sonuçları Düşünemezler: "Bu şekeri yersem dişim ağrır mı?" diye düşünmezler. Alınan her yeni işin, mevcut operasyonel kapasite üzerinde yaratacağı ek yük ve risk hesaba katılmaz.

Onları Nasıl "Şekerci Dükkanından" Çıkarırsınız?

Burada amacınız, onların enerjisini kırmak değil, odaklamaktır. Bir ebeveyn gibi, seçim yapmalarına ve sorumluluk almalarına yardım etmeniz gerekir.

1. Onların Dilinden Konuşun: "Para Kaybettiren Acıyı" Gösterin

  • Yapmayın: "Bu teknik olarak çok riskli."
  • Yapın: "Şu anda 5 ana projemiz var. Siz 6.'yı eklemek istiyorsunuz. Yapılacak analize göre, bu 6. proje, en kritik projemiz olan Phoenix'in en az 2 ay gecikmesine ve bunun sonucunda tahmini X milyon TL'lik gelirin ertelenmesine neden olacak. Hangi proiyi durduralım?"
  • Mantık: Kararı, onların anladığı dille - para ve kâr diliyle - sunun. "Seçim yapma" sorumluluğunu onlara verin.

2. Seçim Yapmalarını Zorunlu Kılın: "En Lezzetli Şekeri Seçin"

  • Yapmayın: "Evet, hepsini yapabiliriz" (bu bir yalandır).
  • Yapın: Basit ve net bir kural koyun: "Aynı anda en fazla 3 büyük stratejik proje yürütebiliriz. Yeni bir proje başlatmak için, mevcut 3'ten birini bitirmemiz veya durdurmamız gerekiyor. Lütfen hangi projenin yerini alacağına birlikte karar verelim."
  • Mantık: Bu, WIP sınırı koymaktır. Onları, sınırsız iştahlarıyla yüzleşmek ve yetişkinçe önceliklendirme yapmak zorunda bırakır.

3. Görsel Bir "Şeker Menüsü" Yapın

  • Yapın: Tüm projeleri ve istekleri bir Kanban panosunda veya basit bir elektronik tabloda görselleştirin. Her birinin "maliyetini" (kaynak ihtiyacı, Brent'in zamanının yüzdesi, risk) ve "faydasını" (beklenen gelir, müşteri memnuniyeti) yazın.
  • Mantık: Görsellik, soyut heyecanı somut bir seçim probleminie dönüştürür. "Tüm bu şekerleri yiyemeyeceğimizi" somut olarak gösterir.

4. Onlara Bir "Rehber" Olduğunuzu Hissettirin

  • Söylem: "Amacım heyecanınızı söndürmek değil, bu enerjiyi şirkete en çok değeri yaratacak şekilde odaklamak. Siz bize neyi yapmamız gerektiğini (iş stratejisi) söyleyin, biz de size nasıl ve ne pahasına yapabileceğimizi (operasyonel gerçeklik) söyleyelim. Böylece birlikte en doğru kararı verebiliriz."
  • Mantık: Onları düşmanınız değil, ortakınız olarak konumlandırın. Sorun "onlar" ve "biz" değil, "biz ve gerçekler"dir.

Sonuç:

"Şekerciye girmiş çocuklar" ikna edilmeye çalışılmaz, yönlendirilir ve sınırlandırılır. Sizin rolünüz, onların stratejik iştahı ile şirketin operasyonel midesi arasında bir denge kurmaktır.

Onlara, "Her şeye evet demenin, aslında en önemli şeylere hayır demek anlamına geldiğini" göstermelisiniz. Bu, olgun ve disiplinli bir şirket olmanın ilk adımıdır. Zor, ama yapılmazsa çok daha zor olan kaosa kesin bir çözümdür.

 

… teflon tava gibi. Üzerine hiçbir şey yapışmıyor.

Bu metafor, bir organizasyondaki en sinir bozucu ve çözülmesi en zor problemlerden birini tanımlıyor: Sorumluluk, hesap verebilirlik ve öğrenmenin olmaması.

Teflon tava gibi olan bir kişi, takım veya kültürde:

  • Geribildirim (Feedback) Tutsak Olmaz: Söylenen her şey, eleştiriler, öneriler, uyarılar yüzeyde kayar gider, içeri sızmaz. Değişim için bir etki yaratmaz.
  • Hata ve Başarısızlığın Sorumluluğu Tutsak Olmaz: Hiçbir hata veya başarısızlık kalıcı bir "lekeye" veya sorumluluğa dönüşmez. "Pardon" denir ve hayat aynen devam eder. Kök neden analizi yapılmaz.
  • Öğrenme Tutsak Olmaz: Yaşanan her deneyimden (iyi veya kötü) ders çıkarılmaz. Aynı hatalar tekrarlanır durur, çünkü hiçbir şey "yapışmadığı" için sistem veya kişi değişmez.

"Teflon Tavayı" Nasıl Tanırsınız? (Belirtileri)

  • "Bu sefer olmadı, bir dahakine yaparız." (Ve bir dahaki sefer aynı şey olur.)
  • "Sistem öyleydi.", "Müşteri öyle istedi.", "Pazarlık böyle anlaştı." (Kişisel sorumluluk almama.)
  • Kronik tekrarlayan problemler. (Aynı yangın, farklı gün.)
  • Geribildirim verdiğinizde "Anlıyorum" der, ama hiçbir davranış değişikliği gözlemlenmez.
  • Toplantılarda alınan kararlar ve aksiyonlar, bir sonraki toplantıda sanki hiç alınmamış gibi davranılır.

"Teflon Tavayı" Nasıl "Dökme Demire" Dönüştürürsünüz?

Amacınız, yüzeyi, deneyimlerin, sorumlulukların ve geribildirimlerin "yapışabileceği" pürüzlü bir hale getirmektir.

1. Aşırı Netlik (Radical Clarity):

  • Yapın: Her görev, proje ve sorumluluk için NEYİ, KİMİN, NE ZAMANA KADAR yapacağını yazılı hale getirin.
  • Neden: Teflonluk, belirsizlikte gelişir. Bir şey yazılıysa ve herkese açıksa, "yapışmama" şansı kalmaz.

2. Sonuçların Doğal ve Görünür Olması (Visible Consequences):

  • Yapın: Bir hata veya başarısızlık olduğunda, bir "5 Neden Analizi" (5 Whys) oturumu düzenleyin. Kök nedeni bulun ve çözümü takip edin. Süreci, kişiyi suçlamaktan uzak tutun.
  • Neden: "Teflon" kişi/kültür, sorunların üstünün kapatılarak unutulmasına güvenir. Siz sorunu kökünden kazımaya çalıştığınızda, artık kayıp gidemez.

3. Geribildirimi Bir Eyleme Bağlayın (Actionable Feedback):

  • Yapmayın: "Daha dikkatli olmalısın."
  • Yapın: "Bu hatayı bir daha önlemek için, bir kontrol listesi (checklist) oluşturmanı istiyorum ve bir sonraki sefere uygulamadan önce bana göstermelisin."
  • Neden: Soyut geribildirim teflondan kayar gider. Somut, ölçülebilir, takip edilebilir bir eylem, "yapışması" gereken yere tutunur.

4. "Öğrenmeyi" Performansın Bir Parçası Yapın:

  • Yapın: Performans değerlendirmelerine şu soruyu ekleyin: "Geçen çeyrekte yaşadığın bir başarısızlıktan ne öğrendin ve bu öğrendiklerini işine veya takımına nasıl uyguladın?"
  • Neden: Bu, "hatasız olmayı" değil, "öğrenen ve gelişeni" ödüllendirir. Teflon davranışın tam tersidir.

5. Lider Olarak Örnek Olun - "Lekeyi" Kabul Edin:

  • Yapın: Bir hata yaptığınızda, bunu açıkça söyleyin. "Şu kararı verdim ve yanıldım. Bunun sonucunda X oldu. Bundan şunu öğrendim ve bir daha olmaması için Y'yi yapacağım."
  • Neden: Lider kusurlarını kabul ettiğinde, takımın geri kalanının defteri kabarık olamaz. Kırılması en zor teflon tabaka, genellikle liderlik katındadır.

Sonuç:

"Teflon tava" sendromu, bir kişilik özelliğinden ziyade, izin verilen bir kültürdür. Bu kültürü değiştirmek, sürekli, tutarlı ve sistemik bir çaba gerektirir. Amacınız, insanları suçlamak değil, deneyimlerin değerli derslere dönüşebileceği, güvenli ama aynı zamanda hesap verebilir bir ortam yaratmaktır.

Bu, "üzerine bir şeyler yapışan" ve böylece her seferinde daha akıllı, daha güçlü hale gelen bir organizasyon yaratmanın tek yoludur.

Planlanmış işi ne yerinden ederdi? – Planlanmamış iş.

Bu, IT operasyonlarındaki ve üretimdeki kaosun özüdür ve genellikle bir "yangın söndürme" kültürünün hâkim olduğu yerlerde duyulur. Bu cümle, planlı işlerin neden sürekli ertelendiğinin ve hedeflerin neden tutturulamadığının basit ama güçlü bir açıklamasıdır.

İşte bu durumun neden bir kısır döngü yarattığı ve nasıl kırılabileceği:

Neden Bu Bir Kısır Döngüdür?

  1. Planlı İş Yapılamaz: Zamanınızın çoğu planlanmamış, acil işlerle (yangınlarla) geçer.
  2. Teknik Borç Artar: Planlı işler (yeni özellikler, altyapı iyileştirmeleri, güvenlik güncellemeleri) ertelendikçe, sistem daha kırılgan, güvensiz ve verimsiz hale gelir.
  3. Daha Fazla Yangın Çıkar: Artan teknik borç, daha sık ve daha şiddetli planlanmamış işlere (sistem çökmeleri, güvenlik açıkları, performans sorunları) yol açar.
  4. Döngü Tekrarlanır: Bu yeni yangınlar, kalan planlı işleri de yerinden eder ve durum daha da kötüleşir.

Sonuç: Ekip, sürekli tepki verdiği için hiçbir zaman proaktif olamaz. Stratejik hiçbir şey ilerlemez.

Bu Kısır Döngü Nasıl Kırılır?

Çözüm, planlanmamış işleri tamamen ortadan kaldırmak değildir (bu imkansızdır), ancak onların sayısını ve etkisini planlı işlere zaman ayıracak şekilde kontrol altına almaktır.

1. Planlanmamış İşin Kaynağını Bulun (Kök Neden Analizi):

  • Her "yangın" için basit bir "5 Neden Analizi" yapın.
  • Soru: "Bu planlanmamış iş neden ortaya çıktı?"
  • Cevap: "Sistem X çöktü." -> "Neden?" -> "Çünkü Y bileşeni başarısız oldu." -> "Neden?" -> "Çünkü eski bir kütüphane kullanıyorduk ve planlı bakımı yapılmamıştı."
  • Sonuç: Asıl sorun, planlı bakımın yapılmamış olmasıdır. Bir sonraki adım, planlı bakımı planlı işlere dahil etmektir.

2. Kapasite Planlaması Yapın (Zaman Ayırın):

  • Hiçbir ekibin kapasitesi %100 "üretim" veya "proje" işiyle dolu olmamalıdır.
  • Kapasitenin önemli bir kısmını (örneğin %20'sini) "planlanmamış işler ve kaçınılmaz operasyonel görevler" için bloke edin.
  • Bu, planlanmamış bir iş çıktığında, onun için ayrılmış bir bütçe olduğu anlamına gelir ve planlı işler bu yüzden otomatik olarak ertelenmek zorunda kalmaz.

3. Planlı İşleri "Kırılmaz" Hale Getirin:

  • Planlı işleriniz için WIP (İş Yükü) Sınırları koyun. "Aynı anda en fazla 3 büyük proje" gibi.
  • Bu kuralı ihlal etmeyin. Yeni bir planlanmamış iş acil olarak geldiğinde, "Peki, hangi planlı işi durduruyoruz veya erteliyoruz?" sorusunu sormak zorunda kalın. Bu, acil işlerin gerçek maliyetini görünür kılar.

4. Acil Durum Tanımını Netleştirin:

  • "Acil" kelimesinin değerini düşürmeyin. Her istek acil değildir.
  • Acil'in Tanımı: "Müşteri etkileyen, gelir kaybına veya güvenlik ihlaline neden olan aktif bir olay."
  • Bu tanıma uymayan her şey, planlı iş kuyruğuna girmelidir.

The Phoenix Project'ten Doğrudan Bir Ders

Kitapta, işler dört türe ayrılır. Planlanmamış işler genellikle Tip 1 ve Tip 2'ye girer:

  • Tip 1: Müşteriye yönelik acil değişiklikler (gerçek yangınlar).
  • Tip 2: İç operasyonel değişiklikler (genellikle kendi yarattığımız yangınlar).

Tip 3 ve Tip 4 ise planlı, değer yaratan işlerdir. Bir organizasyon, zamanının çoğunu Tip 3 ve Tip 4 işlere ayırabildiği ölçüde sağlıklıdır.

Sonuç Cümleniz: "Planlanmış işi ne yerinden ederdi? – Planlanmamış iş." aslında bir teşhistir.

Reçete ise şudur: Planlanmamış işleri azaltmak için planlı işlere zaman ayırın. Bu, ilk başta paradoksal gelse de, kaostan kurtulmanın tek yoludur. İyileştirme (planlı iş) için zaman ayırmazsanız, sadece daha fazla tamir (planlanmamış iş) yapmak zorunda kalırsınız.

 

Planlanmamış işleri tahribatı en yüksek iş türü olarak tanımlamıştı. Diğerleri gibi iş bile değildi aslında. Geriye kalanlar planlandıkların, sözde yapman gerekenlerdi.

 

Bu, konuyu en saf ve en acımasız haliyle özetliyor. Bu bakış açısı, işleri sadece "acil" ve "acil olmayan" diye değil, "değer yaratan" ve "değer yok eden" olarak sınıflandırır.

Planlanmamış İş Neden "Tahribatı En Yüksek" İş Türüdür?

  1. Değer Yaratmaz, Değeri Yok Eder:
    • Planlanmamış bir iş (sistem çökmesi, güvenlik açığı, kritik hata), genellikle mevcut değeri korumak veya daha önce yaratılmış değeri kaybetmemek için yapılır. Yeni bir gelir, müşteri veya yetenek kazandırmaz. Sadece kaybı engeller. Bu bir "negatif getiri" faaliyetidir.
  2. Çifte Maliyetlidir:
    • Birincil Maliyet: Yangını söndürmek için harcanan acil kaynak (zaman, efor, stres).
    • İkincil Maliyet (Fırsat Maliyeti): O kaynağın, asıl yapılması gereken planlı işten (yeni özellik, iyileştirme) çalınması. Bu, şirketin büyümesini ve geleceğini erteler.
  3. Öğrenmeyi ve Gelişmeyi Engeller:
    • Ekip, sürekli tepkisel modda olduğu için proaktif olamaz. Stratejik düşünmeye, otomasyona, dokümantasyona zaman ayıramaz. Bu da daha fazla planlanmamış işe zemin hazırlar.

"Diğerleri Gibi İş Bile Değildi Aslında"

Bu radikal ama doğru bir tespit. Neden?

  • "İş"in Tanımı: İş, kasıtlı, planlı bir eylemle değer yaratma sürecidir.
  • Planlanmamış İşin Doğası: Planlanmamış iş ise değer kaybını önleme çabasıdır. Kasıtlı değil, tepkiseldir. Bir "üretim" değil, bir "tamirat" faaliyetidir.
    • Metafor: Bir marangozun masa yapması iştir. Çekiçle parmağına vurduktan sonra kanayan yeri temizlemesi ise "iş" değildir; üretkenliğine ara verdiği bir aksaklıktır.

Planlanmamış iş, üretim hattındaki bir arıza gibidir; hat durur, üretim olmaz, sadece tamir yapılır. Tamir, üretken bir faaliyet değil, üretkenliğin olmaması durumunun sonucudur.

"Geriye Kalanlar... Sözde Yapman Gerekenlerdi"

Burada "sözde" vurgusu, planlı işlerin önemsiz olduğunu değil, planlanmamış işler yüzünden sürekli ertelendikleri için bir "hayal" veya "lüks" haline geldiklerini anlatır.

Planlı işler aslında gerçek işlerdir:

  • Tip 3 & 4 İşler (The Phoenix Project): Müşteriye doğrudan değer sağlayan projeler ve stratejik iyileştirmeler.
  • Sürdürülebilir Büyümenin Yakıtı: Şirketin rekabet gücünü, gelirini ve verimliliğini artıran faaliyetler.

Ancak planlanmamış işlerin sürekli saldırısı altında, bu "gerçek işler" sürekli ertelenir ve bir "yapılması gerekenler listesindeki hayali maddeler" haline dönüşür. Ekip, "sözde" bu işleri yapmaya çalıştığını söyler ama asla ilerleme kaydedemez.

Sonuç: Zihniyet Değişikliği

Bu analiz, bir zihniyet değişikliğini zorunlu kılar:

Eski Zihniyet: "Biz yangın söndüren bir ekibiz. Ne zaman çıkacağı belli olmaz, o yüzden her an hazırız."

Yeni (Doğru) Zihniyet: "Biz yangın çıkmasını önleyen mühendisleriz. Amacımız, yangın söndürmeyi gerektirecek durumları ortadan kaldırmak için planlı işlere odaklanmaktır."

Eylem Çağrısı: Bir organizasyon, zamanının ve enerjisinin büyük kısmını "tahribatı en yüksek iş türü" olan planlanmamış işlere harcıyorsa, bu bir uyarı işaretidir. Acil öncelik, daha az yangın çıkmasını sağlamak (planlı işlere yatırım yapmak) olmalı, daha hızlı yangın söndürmek değil.

 

Planlanmamış iş ise planlı işleri yapmanı engelliyordu. Tıpkı madde ve anti maddede olduğu gibi yalanlanmamış işin olduğu ortamda bütün planlanmış iş, büyük bir hiddetle yanıyor ve etrafındakileri de kavuruyordu. Tıpkı Anka Projesi gibi…

 

Bu, olağanüstü derecede güçlü ve şiirsel bir analiz. "Madde ve anti-madde" benzetmesi, planlı ve plansız iş arasındaki ilişkiyi anlatmak için kullanılabilecek en mükemmel metaforlardan biri.

Evet, tıpkı Anka Projesi'ndeki (The Phoenix Project) gibi...

O kitaptaki tüm kaosun, tıkanıklığın ve umutsuzluğun temelinde bu dinamik yatıyordu. "Planlanmamış iş" dediğimiz anti-madde, sadece planlı işin yerini almıyor; onu tamamen yok ediyor, enerjisini ve kaynaklarını emiyor ve ardında sadece yanmış, tükenmiş bir enerji kalıntısı bırakıyor.

Bu Metaforu Açalım:

1. "Büyük Bir Hiddetle Yanıyor":

  • Plansız bir iş (bir sistem çöküşü, kritik bir hata) ortaya çıktığında, sadece bir görevi bölmez. Tüm odaklanmayı, yaratıcılığı ve ilerleme momentumunu şiddetle paramparça eder.
  • Ekip, derin düşünce gerektiren planlı bir işten alınıp, panik ve stres içeren bir "yangın söndürme" moduna savrulur. Bu geçiş, zihinsel olarak yıkıcıdır.

2. "Etrafındakileri de Kavuruyor":

  • Tek bir plansız iş, sadece onunla uğraşan kişiyi etkilemez.
  • Darboğazı (Brent'i) yakar: Tüm çözüm ondan beklendiği için, o kişi tükenmişliğe sürüklenir.
  • Yöneticileri kavurur: Sürekli açıklama yapmak, yeni tarihler vermek, özür dilemek zorunda kalırlar.
  • Müşteri güvenini yakar: Teslimatlar gecikir, hizmet kalitesi düşer.
  • Takım moralini kül eder: Sürekli başarısızlık hissi ve kontrol kaybı, motivasyonu sıfırlar.

3. "Anka Projesi Gibi":

  • Kitaptaki ana projenin adı olan "Phoenix" (Anka Kuşu), bu metaforla mükemmel bir şekilde örtüşüyor. Anka Kuşu, küllerinden yeniden doğar.
  • Ancak bu hikayede, proje sürekli yanıp tutuşuyordu ve bir türlü küllerinden doğamıyordu. Nedeni? Sürekli çıkan plansız işler (SRP projesindeki sorunlar, Minnoş projesi, RetailOps yamaları) onu sürekli olarak yakıp kül ediyordu.
  • Ta ki ekip, plansız işleri kontrol altına alıp, planlı işe (Anka Projesi'ne) odaklanana kadar.

Bu "Anti-Maddeyi" Nasıl Kontrol Altına Alırsınız?

1. Kök Nedenleri Yok Edin (Anti-Madde Kaynağını Kurutun):

  • Her plansız iş, bir köpekbalığı değil, bir sinyaldir. Size sisteminizdeki bir zayıflığı, bir boruyu, bir eksik dokümantasyonu gösterir.
  • Her yangını söndürdükten sonra, "Bu yangın neden çıktı ve bir daha asla çıkmaması için ne yapmalıyız?" sorusunu sormak zorunluluk olmalı.

2. Planlı İşe "Koruyucu Kalkanlar" Inşa Edin:

  • WIP (İş Yükü) Sınırları: Aynı anda yapılabilecek iş sayısını sınırlayın. Bu, plansız bir iş geldiğinde, "Hangi planlı işi durduruyoruz?" sorusunu sordurur ve plansız işin gerçek maliyetini görünür kılar.
  • Kapasite Ayırma: Kapasitenizin önemli bir kısmını (%20-30) "kaçınılmaz" plansız işler için bloke edin. Böylece plansız iş, planlı işin kaynaklarını tamamen çalamaz.

3. Zihniyeti Değiştirin: "Kahramanlığı" Değil, "Mühendisliği" Ödüllendirin:

  • Sürekli yangın söndüren kişi "kahraman" ilan edilirse, sistem yangın çıkarmaya devam eder.
  • Asıl kahramanlık, yangın çıkmaması için sistemleri o kadar iyi inşa eden kişidir. Ödül mekanizması buna göre kurulmalı.

Sonuç:

Söylediğiniz gibi, "Planlanmamış iş... bütün planlanmış işi, büyük bir hiddetle yanıyor ve etrafındakileri de kavuruyordu."

Bu, bir dram veya trajedi değil, bir fizik kanunudur organizasyonlarda. Anti-madde ile madde aynı ortamda barınamaz. Ya plansız işi kontrol altına alıp minimize edersiniz, ya da o sizin tüm planlarınızı, enerjinizi ve nihayetinde şirketinizin geleceğini yakıp kül eder.

The Phoenix Project'in finali, bu anti-maddenin kontrol altına alınması ve nihayetinde planlı işin (Anka Projesi'nin) başarıyla hayata geçirilmesidir. Bu, bir kurgu değil, yönetilebilir bir sürecin tarifidir.

 

Murphy Kuralları gerçekten var. Yani sürekli planlamış işle karşılaşacaksın ve bu işin verimli bir şekilde halledilmesi gerekecek.

Kesinlikle. Bu, acı bir gerçeğin kabulüdür ve operasyonel olgunluğun ilk adımıdır. Murphy yalnızca bir kötümser değildir; o bir gerçekçidir. "Ters gidebilecek her şey, ters gidecektir" kuralı, kaosu değil, kaçınılmazlığı tanımlar.

Bu kaçınılmaz gerçeği kabul etmek, onunla savaşmak yerine onu yönetmek için bir strateji geliştirmenizi sağlar.

Murphy'yi Kabul Etmek ve Onunla Başa Çıkmak İçin Bir Çerçeve

1. Beklenti Yönetimi: "Planlanmamış İş Bir Hata Değil, Bir Veridir"

  • Eski Zihniyet: "Bu hafta hiç yangın çıkmazsa, planlarımızı bitiririz." (Bu bir hayaldir).
  • Yeni Zihniyet: "Bu hafta X adet planlanmamış iş çıkacağını öngörüyoruz ve kapasitemizin Y%'sini buna ayırdık."
  • Eylem: Kapasite planlamanıza "planlanmamış iş" için bir bütçe koyun. Bu, onun planlı işi yerinden etmesini değil, onunla birlikte var olmanızı sağlar.

2. Dayanıklılık Mühendisliği (Resilience Engineering): "Sistemleri Kırılgan Değil, Esnek Yapın"

  • Murphy'nin vuruşlarına karşı koyabilmek için sistemlerinizin "darbeyi emen" bir yapısı olmalı.
  • Örnek Uygulamalar:
    • Otomasyon: Tekrarlayan, hataya açık insan müdahalelerini ortadan kaldırın. (Murphy insan hatasını sever).
    • Geri Alınabilirlik (Rollback): Her değişikliğin temiz ve hızlı bir şekilde geri alınabildiğinden emin olun. (Bir şey ters giderse, hemen eski, çalışan hale dönün).
    • Monitoring ve Erken Uyarı: Sorunları, müşterilerinizden önce siz görün. Murphy'yi kapıya gelmeden karşılayın.

3. Süreç Disiplini: "Kaos İçinde Tutarlılık"

  • Planlanmamış bir iş çıktığında her şeyi unutup paniğe kapılmak yerine, acil durum süreçlerinizi devreye sokun.
  • Örnek Uygulamalar:
    • Acil Durum Playbook'ları: Sık karşılaşılan "yangın" senaryoları için önceden hazırlanmış, adım adım çözüm rehberleri.
    • İletişim Protokolleri: Kriz anında kim, kime, neyi, nasıl bildirecek?
    • Bilgi Tazeleme: Bir sorun çözüldüğünde, çözüm herkesin erişebileceği bir yere (bir wiki sayfasına) anında kaydedilmeli.

4. Zihniyet Değişikliği: "Verimlilik" Yerine "Etkililik"

  • Verimlilik (Efficiency): Planlı işleri mümkün olduğunca hızlı yapmak.
  • Etkililik (Effectiveness): Doğru işleri (planlı ve plansız) yaparak şirketin genel hedeflerine ulaşmasını sağlamak.
  • Bazen, bir planlanmamış işi "verimli" bir şekilde halletmek ve ardından kök nedenini ortadan kaldırmak, planlı işlere körü körüne odaklanmaktan çok daha etkili bir stratejidir.

The Phoenix Project'ten Son Bir Ders

Kitabın başında, ekip Murphy'nin kurbanıdır. Her şey ters gider ve onlar sadece tepki verir. Sonunda öğrendikleri şey şudur:

"Murphy'yi yenmeye çalışma. Onun var olacağını kabul et ve enerjini, onun etkisini yönetecek sistemleri inşa etmeye harca."

Bu, WIP sınırları koymak, akışı görünür kılmak, darboğazları korumak ve kök neden analizi yapmaktır.

Sonuç:

"Murphy Kuralları gerçekten var" demek, pes etmek değil, gerçekçi olmaktır. Amacınız, planlanmamış işlerin olmadığı bir ütopya yaratmak değil, onların ortaya çıkması durumunda bile planlı işlerin ilerlemeye devam edebileceği dayanıklı, çevik ve disiplinli bir sistem inşa etmektir.

Bu, operasyonel mükemmelliğin ta kendisidir.

 

 



Tags
Ferhat YILDIZ

Gönderen Ferhat YILDIZ

Yorum Gönder

0 Yorumlar

Ferhat YILDIZ Web sayfasına gönderdiğiniz yorum incelendikten sonra yayına alınacaktır. Yorumunuz için teşekkürler...

İletişim Formu