- Şirketler Toyota tarzı üretim yetkinliği, six-sigma kalitesi, Dell tarzı tedarik zinciri gibi operasyonel yetkinlikleri yakalamak için büyük harcamalar yapar; ancak iyileştirme programlarının sürdürülebilir performansa dönüşmesi nadirdir
- TQM, bir dönem yaygın kullanıldıktan sonra hızla geri plana itilen bir örnek; Fortune 1000 içinde iyi gelişmiş bir TQM programına sahip şirketlerin oranı %10’un altındaydı
- Başarısızlığın nedeni belirli bir aracın seçiminden çok, yeni programın fiziksel, ekonomik, sosyal ve psikolojik yapılarla nasıl iç içe geçtiğinde yatar; iyileştirme nihayetinde bir sistem sorunu haline gelir
- Performans açığı büyüdüğünde kuruluşlar daha uzun çalışmayı ifade eden Work Harder ile yetkinlikleri geliştirmeyi ifade eden Work Smarter arasında seçim yapar; ancak ikincisi gecikme ve başarısızlık riski nedeniyle kolayca geri plana düşer
- İyileştirmeye ayrılan zamanı azaltan Shortcuts kısa vadeli çıktıyı artırdığı için caziptir; fakat geç ortaya çıkan yetkinlik kaybı birikirse kuruluşu bir Capability Trap içine hapsedebilir
İyileştirme programlarının başarısızlık paradoksu
- Şirketler üretim, kalite, müşteriyi anlama, tedarik zinciri yönetimi gibi operasyonel yetkinlikleri geliştirmek için süreç iyileştirmeye aktif biçimde yatırım yapar
- 1997’de ABD şirketlerinin yönetim danışmanları ve eğitim harcamalarının toplamı 100 milyar doların üzerindeydi ve bunun önemli bir bölümü üstün şirketlerin operasyonel yetkinliklerini yakalamaya harcandı
- Bazı dramatik başarılara rağmen birçok iyileştirme programı anlamlı sonuçlar üretemez
- TQM bu paradoksu iyi gösterir
- 1980’lerde Japon şirketlerinin başarısından etkilenerek ABD şirketleri arasında büyük bir moda haline geldi
- 1990’ların ortalarında akademinin ve iş dünyası medyasının ilgisi azaldı; re-engineering gibi yeni yeniliklerin gölgesinde kaldı
- TQM’in disiplin ve yöntemlerine ciddi biçimde bağlı kalan şirketler rakiplerinden daha yüksek performans gösterdi
- Bir araştırmada Fortune 1000 içinde iyi gelişmiş TQM programına sahip şirketlerin oranı %10’un altındaydı
- Başka bir araştırmada TQM 1993’te en çok kullanılan üçüncü iş aracıydı; ancak 1999’da 14. sıraya geriledi
- Geçmişteki iyileştirme teknikleri bazen isim değiştirerek yeniden ortaya çıkar
- İstatistiksel süreç kontrolü ve değişkenliği azaltmanın temel disiplini six-sigma olarak devam etti
- quality circle yeniden high-performance work team olarak adlandırıldı
Araçlardan daha zor olan şey uygulama yapısıdır
- Performans iyileştirme araçları ve teknikleri hızla çoğaldı; bilgi teknolojisi ve danışman sayısındaki artış sayesinde hangi tekniği kimin kullandığını öğrenmek de kolaylaştı
- Çoğu yönetici için daha büyük engel yeni yöntemi bilmek değil, onu günlük işlere başarıyla uygulamaktır
- six-sigma kalite programı gibi yetkinlikler anahtar teslim ürün gibi satın alınamaz; kuruluşun içinde geliştirilmelidir
- Yaklaşık 10 yıl boyunca telekomünikasyon, yarı iletken, kimya, petrol, otomotiv ve eğlence ürünleri sektörlerinde 12’den fazla derinlemesine vaka çalışması yürütüldü
- Gözlem, katılımcı görüşmeleri, kayıt materyalleri ve nicel göstergeler kullanıldı
- Uygulama ve iyileştirme dinamiklerini yakalamak için modeller de geliştirildi
- Çoğu kuruluşun iyileştirme yeniliklerinin faydasını tam olarak elde edememesinin, belirli iyileştirme aracının seçimiyle pek ilgisi yoktur
- Yeni iyileştirme programı; araçların, ekipmanların, çalışanların, yöneticilerin ve fiziksel, ekonomik, sosyal, psikolojik yapıların iç içe geçtiği yerde işlediği için sistemsel bir sorun haline gelir
İyileştirmenin temel fiziği: zaman ve yetkinlik
- Bir sürecin gerçek performansı, çalışmaya harcanan zaman (Time Spent Working) ve o işi yürütmeye yönelik süreç yetkinliği (Capability) tarafından belirlenir
- Üretimde net kullanılabilir çıktı, günlük çalışma saatleri ile üretkenliğin, yani çalışma saati başına kullanılabilir çıktının çarpımıyla belirlenir
- Performans daha fazla çalışarak veya iyileştirmeye daha fazla yatırım yaparak artırılabilir; ancak iki yöntemin sonuçları farklıdır
- Haftalık çalışma saatini %20 artırmak, fazla mesai sürdüğü sürece çıktıyı %20 artırabilir
- Süreç yetkinliğini iyileştirmek, bundan sonra harcanan tüm çalışma saatlerinin çıktısını artırır
- Kusurlu ürünleri yeniden işlemek için yapılan fazla mesai, yalnızca fazla mesai sürdüğü sürece çıktıyı artırır; kusurun kök nedenini ortadan kaldırmak ise yeniden işleme ihtiyacını kalıcı biçimde azaltır
- Yetkinlik, zaman içinde biriken bir varlık (stock) olarak ele alınır
- İyileştirmeye harcanan zaman, yetkinlik yatırımını artırır
- Kök nedeni bulmak ve çözümü keşfetmek, test etmek ve uygulamak zaman aldığından iyileştirme faaliyetleri ile yetkinlik değişimi arasında gecikme vardır
- Makine aşınması, süreçten sapma, tasarımın eskimesi ve prosedürlerin güncelliğini yitirmesi nedeniyle düzenli olarak bakımı yapılmayan yetkinlik geriler
- İyileştirme gecikmesi, sürecin teknik ve örgütsel karmaşıklığına bağlıdır
- job shop’taki makine verimi gibi görece basit süreç iyileştirmelerinde gecikme aylar mertebesindedir
- Ürün geliştirme gibi karmaşık süreç iyileştirmelerinde gecikme birkaç yıl veya daha uzun olabilir
- Ürün ve personel değişim oranı yüksek kuruluşlarda iyileştirilmiş yetkinliğin ömrü de kısalır
Work Harder ile Work Smarter arasındaki gerilim
- Yönetim, müşteri talebi, sigorta talebi işleme hacmi, çeyrek başına yeni ürün lansmanı sayısı gibi hedefleri Desired Performance olarak belirler
- Gerçek performans ile hedef arasındaki fark Performance Gap haline gelir; incelenen kuruluşlarda beklentileri aşan süreçlere nadiren rastlandı
- Kaynak artırmaya veya ek işe alıma isteksiz kuruluşlarda performans açığını kapatmanın iki temel seçeneği vardır
-
Work Harder döngüsü
- Yöneticiler performans açığı olduğunda çalışma hızını artırma, fazla mesai, daha agresif hedefler, hedefi tutturamama cezaları gibi yollarla iş baskısını artırır
- Performans değerlendirmelerinin sıklığı, inceleme ayrıntı düzeyi ve değerlendiren kişinin kıdemi gibi daha incelikli yollar da iş baskısına dahildir
- Bir şirkette kıdemli başkan yardımcısı fabrika sahasındaki tek tek makinelerin performansını inceliyordu; bu da makineleri bedeli ne olursa olsun çalışır tutma mesajı haline geldi
- Bir proje yöneticisinin sorumlu olduğu alt sistemin takvimi gecikince, prototip şartnameyi karşılayana kadar her saat başı durum raporu telefonu yapması istendi
-
Work Smarter döngüsü
- Yöneticiler iyileştirme programı başlatma, yeni fikirlerin denenmesini teşvik etme, eğitime yatırım yapma gibi yollarla süreç yetkinliğini artırmaya çalışabilir
- Başarılı olursa zaman içinde yetkinlik iyileşir, işleme hacmi artar ve performans açığı azalır
- İyileştirme yatırımı uzun vadede daha büyük etki yaratabilir; ancak etkinin ortaya çıkmasına kadar önemli bir gecikme vardır ve kök nedeni bulmanın ya da yeni araçları uygulamanın başarısız olma riski de bulunur
- Acil sorunlarda Work Harder sıkça seçilir
- Önemli bir müşteriye hizmet veren bir üretim hattı durursa, yönetici güvenilirlik iyileştirme eğitimi yerine hattı yeniden çalıştırmaya ve sevkiyat bitene kadar fazla mesaiyi zorlamaya daha yatkındır
- Geçici müdahale sona erdikten sonra bile iyileştirme faaliyetlerine dönülemezse, daha çok çalışma biçimi standart işletim yöntemi haline gelir
Yeniden yatırım döngüsü ve yetkinlik tuzağı
- Kuruluşlarda çok az yedek kaynak bulunduğu için iş baskısı arttığında insanlar dinlenme gibi iş dışı faaliyetleri azaltır ve fazla mesaiyi artırır
- Bilgi çalışanlarının fazla mesaisi çoğu zaman ücretsiz biçimde gecelere ve hafta sonlarına uzanır; aile ve topluluk faaliyetlerine ayrılan zamanı elinden alır
- Zaman daha fazla artırılamadığında, büyümeye devam eden performans açığını karşılamak için iyileştirme zamanını azaltmaktan başka yol kalmaz
-
Reinvestment döngüsü
- İyileştirme yatırımı başarılı olursa performans yükselir, performans açığı azalır ve iyileştirmeye daha fazla zaman ayrılabilir; böylece erdemli döngü oluşur
- Buna karşılık işleme hacmi açığına iş baskısıyla yanıt verilirse iyileştirme zamanı azalır, yetkinlik geriler ve performans açığı daha da büyür; bu da daha güçlü iş baskısına ve daha az iyileştirmeye yol açan kısır döngü yaratır
- Başarılı iyileştirme örneklerinde üretkenlik artışıyla elde edilen kaynaklar, yeniden yatırım sürecini güçlendirmek için açıkça yeniden iyileştirme faaliyetlerine tahsis edilir
- Birçok kuruluşta maliyet ve takvim baskısı küçülmeye veya daha yüksek performans hedeflerine yol açarak iyileştirme kaynaklarını alıp götürür; yetkinlik durur ya da düşer
-
Shortcuts döngüsü
- İyileştirme toplantılarını atlamak, planlı önleyici bakımı ertelemek, dokümantasyon gerekliliklerini yok saymak gibi kestirme yollar hemen çalışma zamanını artırır
- Yetkinlik kaybı hemen ortaya çıkmadığı için kestirme yollar kısa vadede etkili ve cazip görünür
- Önleyici bakımı erteleyen yönetici planlı duruş süresinden kaçındığı ve bakım maliyetinden tasarruf ettiği bir erteleme dönemi kazanır; ancak daha sonra ekipmanın yaşlanması ve aşınması nedeniyle verim ve çalışma süresi düşer
- Dokümantasyonu atlayan yazılım mühendisi projeyi zamanında bitirebilir; ancak haftalar ya da aylar sonra testte bulunan hataları düzeltirken bunun bedelini öder
-
Capability Trap
- Work Harder başlangıçta toplam işleme hacmini hemen artırır ve iyileştirme zamanındaki azalmanın maliyeti geç ortaya çıkar; bu nedenle önce iyi, sonra kötü bir durum yaratır
- Work Smarter kısa vadeli çıktıyı azaltır; ancak zamanla yetkinlik artışı çalışma çabasındaki azalmayı telafi ederek performansı yükselten önce kötü, sonra iyi dinamiklerine sahiptir
- Shortcuts ve Reinvestment etkileşimi, kuruluşu yetkinlik düşüşünün kısır döngüsüne hapseden bir Capability Trap yaratabilir
2 yorum
Hacker News yorumları
Hafızam biraz bulanık ama iyi bir örnek var.
Bir organizasyonda kritik bir sipariş işleme süreci vardı; gereken bilgilerin tamamının geleceğine ya da doğru geleceğine güvenilemeyen bir durumdu. Bu yüzden girdileri temizleyen ve işleme biçimini değiştiren doğrulama mantığı oluşturuldu; her siparişte hangi doğrulamanın tetiklendiği de metrik olarak tutuldu. Yeni bir doğrulama eklendiğinde tarih de iliştirildi.
Bu metrikler açık hale getirilip ara sıra paylaşıldığında, biri “XYZ olursa ne olur?” diye sorduğunda “zaten ele aldık ve XYZ yüzünden #### siparişin engellenmesini önledik” diye cevap verilebiliyordu.
Ekibin dikkatli çalıştığı, sistemin iyi işlemeye devam etmesi için bu tür işlerin gerekli olduğu ve bunun verilerle desteklenebildiği ortaya çıktı. Bu sayede kurum içindeki konuşma “bunu neden düşünmediniz?”den “şimdi ne yapmalıyız?”a dönüştü; önleyici kaliteye verilen takdir de üst kademelere taşındı.
Çoğu ekip muhtemelen sadece sipariş başarı oranı gibi metriklere bakıp bırakırdı; kötü veriyi işleme sayısını metrik yapmak, iyi işlerin görünmez kalması tuzağından çıkmayı sağlıyor.
Yakın zamanda iş yerimde tam olarak aynı şeyi yaşadım.
Kurumun teknik lideri/mimarı olarak yakın zamanda yayınlanan projeleri inceledim ve ciddi güvenilirlik/performans sorunları nedeniyle mutlaka iyileştirilmesi gereken yerler buldum. Bir ekibin birkaç sürümü listenin en üstündeydi, ancak o ekibin PM’i ve mühendislik yöneticisi, ayrıca üst yönetimdekiler, özellik güncellemelerinin öncelikli olması gerektiğini söyleyerek tüm endişeleri görmezden geldi.
Birkaç ay sonra ben tatildeyken olay patladı; sev 1 escalation yaşandı, birçok müşteri öfkelendi ve CEO/CTO bile devreye girdi. Sorunlu, özensiz kodu yazan ve uyarıları görmezden gelen tam da o ekip, hizmeti geri getirmek için gece gündüz çalıştı ve artık kahraman oldular. Özellikle o yönetici, kesinti sırasında aktif iletişim kurduğu ve liderlik gösterdiği gerekçesiyle şirkette iyi bir itibar kazandı.
Başkasının yarattığı sorunları düzeltmek daha etkileyici. Kendi hatasını düzelten birine övgü yağdırmak istemem; ben de kendi hatamı düzelttiğim için övgü beklemem. En başta berbat ettiğim şey için herkesten özür dilerdim.
Başlıktaki sorunu kendi değerimle bağlantılı olarak sürekli düşünüyorum.
Birine 3 aydır takıldığı bir işi 40 dakikada çözerek yardım edersem değerim herkes için açıktır. Ama en başından beri birlikte çalışıp kimsenin 3 ay boyunca takılı kalmamasını sağlarsam değerim belirsizleşir. Bu paradoksla nasıl başa çıkacağımı bilmiyorum.
Daha fazla emek ve zaman harcadığında, çoğu zaman ödül geride kalırken senden daha fazla emek ve zaman beklenir. Değer ve fırsat, emek ve zamana göre daha çok kaotik bir sürece benzer.
Sonuçta bir fırsat belirdiğinde onu yakalayabilecek kadar zihnin açık kalsın diye iş yükünü dengede tutmaya çalışmak gerekir. Dürüst ve dengeli iş arkadaşları yardımcı olur ama nihayetinde bunu insanın kendisi yapmalıdır.
Yöneticim açıklamaya çalışsa bile, bir sonraki işten çıkarmada kesilecek baş benimki olabilir.
Başka şirketlere bu tür işleri iyi yaptığımı söylediler ama hiçbir şeyin devamı gelmedi. Küçük şirketlere yönelik sözleşmeli işte o gün benim için ilk ve sondu.
Bu yüzden ekip üyelerinin morali kırılmaz. Ekip üyeleri psikolojik olarak bireysel katkılarının tanınmasına ihtiyaç duyar.
Bu tür yöneticiler çoğu zaman yetkin bireysel katkı sağlayıcılarken ekip lideri olmuş kişilerdir; kendileri o tekniğin ustası oldukları için yönettikleri bireysel katkı sağlayıcıları değerlendirmek açısından en iyi konumdadırlar.
Kaçınılan felaketleri canlı biçimde tasvir edip insanların zihninde net bir resim oluşmasını sağlamalısın.
Bir başka varyasyon da, gerçekten bir kez yaşanmış bir sorunu önlemek için kaynakları aşırı tahsis edip, daha ciddi ama henüz yaşanmamış sorunlara daha az ilgi göstermek
Bu bir yönetim sorunu. Çünkü başka, daha önemli işleri yapmak rasyonel olsa bile, aynı kaza tekrarlandığında kimse sorumluluğu üstlenmek istemez
Küçük bir yaranın yerini sert ve esnek olmayan bir organizasyonun alması gibi. Bir şeyin bir kez yaşanmış olması, bir daha asla yaşanmaması için mutlaka değişiklik yapılması gerektiği anlamına gelmez; bu tür aşırı tepkiler gelecekte büyük bir yüke dönüşebilir
Kaybı kabullenip tekrar yaşanabileceğini kabul etmek, kesin biçimde engelleyeceğiz diye aşırı önlem almaktan daha iyi olabilir
Bir şey gerçekten yaşanana kadar önleme kaynakları ayırmama politikası bir ölçüde rasyoneldir
Bir yıl boyunca, arızaya aşırı tepki verildiğini ve gerçekten yaşanan sorunun çok basit bir çözümü olduğunu anlatmaya çalışarak sefil oldum. Ama üst düzey bir yönetici, tekrar yaşanması kendi koltuğunu tehlikede gösterecekse, tüm departmana benzer sorunlu kodları inceleyip düzeltme talimatı verir. Ve tuhaf biçimde, inanılmaz derecede aşırı tasarlanmış çözümü öneren en yüksek sese kulak verir
Bir başka sefer de parola süresinin dolması yüzünden işlem stack'inde kesinti yaşandı. Bunu “bir daha asla yaşanmayacak” hale getirmek için gülünç derecede karmaşık, el yapımı bir çözüme harcanan çaba akıl almazdı. Sonunda bir yıldan fazla çalışıldıktan sonra hepsi çöpe atıldı ve en baştan yapılması gereken çok daha basit, merkezi çözüme geçildi
Eskiden çalıştığım yeri hatırlattı. Ne zaman geri bildirim istesem, “burada PIR(post-incident response) olmadan hiçbir şey öncelik haline gelmez” diye tekrarlardı
Sonlara doğru PIR ile ilgili bir ticket açıldığında, o kazayı önleyebilecek ama backlog'da can çekişen gerçek ticket'ın duplikasyonu olarak işaretliyordum. Sorumluluk alanımızdaki öngörülebilir sorunları önleme konusunda hiçbir etkimizin olmaması ekip moralini ciddi biçimde zedeledi
Ekip üyelerinin çoğu iyileştirme önerileri sunmayı tamamen bıraktı. Çünkü yönetim, ticket'ları kendimizin öne çekmesine izin vermiyordu
Kurumsal Scrum'ın nasıl bir cehenneme dönüştüğünü çok iyi anlatıyor
Agile kelimenin tam anlamıyla hızlı çalışmak ve yetkinliği hızlı döngülerle geliştirmek demekti. Ama Scrum, yerini almayı amaçladığı planlama sürecinin daha kötü bir versiyonuna dönüştü
Scrum'ın işi anlık sorunlara bölme biçimi bu döngüyü daha da kötüleştiriyor. Uzun vadede yangınların yukarı itildiği, teknik borcun aşağı itildiği bir ticket sistemine dönüşüyor
Üstelik danışmanların ve yöneticilerin optimizasyon oyunu oynamasını kolaylaştıran, takip etmesi kolay ama anlamsız verimlilik sayıları da üretiyor
Bunu söyleyebilirim. Yakın arkadaşlarım arasında scrum master olanlar da var
Nedenini anlıyorum. Yapılabilecek onca iş arasından hangisinin yapılacağına birinin karar vermesi gerekiyor. Bu özellik para kazandıracak mı? Özellik değil ama kaynak maliyetini azaltan işler ne olacak? Özellik teslim hızını yavaşlattığı söylenen teknik borç ne olacak?
Ben üst düzey yönetici değilim ama sonuçta yukarıda birileri şirketin hayatta kalıp para kazanmasından ve bize maaşlarımızı ödemesinden sorumlu. Onlar da bizim gibi, elde edebildikleri az bilgiyle karar vermek zorunda. Bu yüzden “bunun maliyeti ne, değeri ne” ile “şunun maliyeti ne, değeri ne”yi karşılaştırabilecek bir yönteme ihtiyaçları var
Bunu tahmin etmenin bir yolu gerekiyordu ve teknoloji sektörü Agile'ı bu araç olarak pazarlayınca ona tutundular. Kimin suçu?
Böylece sık tahminler, takvim takibi ve ritüeller geldi. Bunun doğal olarak gelmesi gerektiğine inanmayanlar var, ben de katılıyorum. Ama her hâlükârda o ritüeller kültün parçası haline geldi
Biz Scrum'ı bıraktık; refinement toplantılarını, story tahminlerini ve story point'leri de bıraktık. Artık ayda bir kez PM ile resmî olarak buluşup ekip düzeyinde mevcut duruma sadece tişört bedeni tahmini ile bakıyoruz. Bunun dışında PM istediğinde ya da biz gerekli gördüğümüzde güncelleme yapıyoruz. Bu sayede yetki bizde, ama bunun karşılığında sorumluluk alıp durum riskli görünüyorsa zamanında haber veriyoruz. Hâlâ “tahmin” yapmak zorundayız. Sonuçta üst düzey yöneticilerin karar vermesi gerekiyor. Ama genel olarak oldukça hafif ve gerçekten özgürleştirici
Herkes sürece bağlıydı ve Scrum ekibi çabasının %20'sini borçları ele alma önceliğine ayırıyordu. Herkesin hızı da oldukça isabetliydi; bu sayede kişisel ilgi alanı işleri için ek %20 de hesaba katılabiliyordu ve paydaş öncelikleri kalan %60'ı dolduruyordu
Bazı sprint'lerde bir epic'i ya da ekip hedefini bitirmek için yüklenmek gerektiğinde veya acil durum/bug yüzünden öncelikleri değiştirmek gerektiğinde yön değiştiriyorduk
Sırf süreç eklemek istediğin için bir sürü süreç eklemek değer yaratmıyor
Ofiste astığım şu çizgi romanı hatırlattı: https://naksecurity.medium.com/the-detriments-of-hero-cultur...
Bu yüzden birçok şirket kültüründe, bir sorun senin doğrudan sorumluluk alanın değilse, nasıl düzelteceğini bilsen bile proaktif olarak önlememek ödül açısından daha avantajlıdır. Sorunun görünür olmasına izin ver, birinin acil durumuna dönüşsün, sonra düzelt
Elbette uzun vadede böyle bir organizasyonun iyi gitmesi mümkün değildir; bu yüzden ayrılma planı da yapmak gerekir
“Kimse hiç yaşanmamış bir sorunu düzelttiği için takdir edilmez” (2001) [pdf] aklıma geliyor
YouTuber’lar ya da sosyal medya clickbait’leri Y2K hatasının aslında önemli bir şey olmadığını her iddia ettiğinde bu düşünce aklımda kalıyor
Önemli bir şey olmamasının nedeni, benim gibi sayısız deneyimli kişinin aylar öncesinden geceleri uykusuz kalıp sistemleri çalışır hâle getirmesiydi
UTC gece yarısı geri sayımındaki gerilimi hâlâ hatırlıyorum. Sonra Doğu saati geri sayımında yeniden gerildik, yerel saat gelince bir kez daha. Pasifik saatiyle yıl 2000 olana kadar ancak gevşeyebilmiştik
2038’de öğreniriz
Aynı dönemden bakarsak Y2K de çok iyi bir örnek. Göze çarpan pek bir şey olmadı ama insanlar onu öylece görmezden gelseydi çok şey yaşanmış olması muhtemeldi
Bunu maaşım buna bağlı olduğu için söylemiyorum. Elbette başka iş fırsatları boldu. Gerçekten enerji sektörünü felç edebilecek bir sorundu ve büyük şirketleri, ayrıca onlara bağımlı sayısız kuruluşu etkilerdi. Bu deneyime bakınca finans ya da kaynak geliştirme gibi birçok sektörde de doğrudan ya da dolaylı aynı etkinin görüleceğini düşünüyorum
Bu yüzden iyi bir örnek. Hâlâ Y2K’yi önemsiz bir yaygara olarak hatırlayan insanlarla karşılaşıyorum. Değildi. Sizin için sorun olmamasının nedeni, çok sayıda insanın onu engellemek için çok çalışmasıydı
Sorunlar aşırı karmaşık değildi ama yaygındı, önemliydi ve büyük iş yükü gerektiriyordu. İnsanlığın başarısı diye sunulacak Ay’a iniş düzeyinde bir mühendislik probleminden çok, patlamadan önce bir sürü aptalca Challenger O-ring sorununu düzeltmeye benziyordu
Bu yüzden o gün geldiğinde geriye yalnızca az sayıda küçük kalıntı hata kalmıştı. Gazetelerde birkaç şaka vardı ama kamuoyu genel olarak olayı es geçti
Ben iklim alanında çalışıyorum ve aynı şeyin olmasını ummuştum ya da hâlâ umuyorum. Ama yakında herkesin dikkatini çekmek zorunda kalacak gibi görünüyor
Hazırlıklıysanız ilginç hiçbir şey olmaz, hayat devam eder ve insanlar bunu birilerinin laptop açıp birkaç düğmeye basması olarak hatırlar
Hazırlıklı değilseniz Teksas elektrik şebekesi donar, insanlar ölür, birikimlerini kaybeder ve “kimse bu kadar kötü olacağını hayal edemezdi” denir
İtiraf edeyim, ben de o çalışmada yer aldım. Komik olan, eski bir müşteriye geri çağrılıp geçmişteki çalışmamın kelimenin tam anlamıyla yarattığı sorunu düzeltmemdi. Sorunu görür görmez 20 dakikada düzelttim. Ardından “madem gelmişken şuna da bir bakar mısın…” süreci başladı ve o departman kapatılıp New York’a taşınana kadar yaklaşık 2 yıl sürdü
En azından faturalanabilir saatler olarak takdir gördüm
Bu yazı hemen sonrasında yazılmış olduğu için Y2K hakkında olacağını sanmıştım
90’ların sonlarında birkaç yıl Y2K projelerinde çalışarak Birleşik Krallık’ın kritik altyapısının gece yarısı durmamasına yardımcı oldum. Örneğin bizim çabamız olmasaydı Galler’de su ya da gaz olmayacaktı
Ama sonrasında “hiçbir şey olmadı, demek ki açıkça sorun değilmiş; Y2K’ye neden o kadar para harcandı?” ya da “Y2K, BT sektörünün uydurduğu bir dolandırıcılıktı” sözlerini duydum
Biz kazandık. Y2K hatasını başarıyla engelledik; zor bir işti ve gece yarısına kadar hepsini yakalayıp yakalamadığımızdan da emin değildik. Ama kutlanmak yerine, bazıları bunu bizim kazık attığımızın kanıtı olarak gördü. İnsanlar tuhaf
Sinir bozucu olan şu ki iklim değişikliğinde de en iyi senaryo bununla aynı. Gerçekten kıyameti önlemeyi başarırsak bütün “iklim inkârcıları” kendilerinin haklı olduğunu düşünecek
Hacker News yorumları
Başlığı görünce aklıma ilginç bir antik Çin hikâyesi geldi. Toyota'nın yakın zamanda bir skandala karışmış olması da biraz ironik: https://www.bbc.com/news/articles/c1wwj1p2wdyo
Wei Kralı Wen, Bian Que'ye “Üç kardeşin de hekimse, en iyisi hangisi?” diye sorunca, Bian Que “En iyisi ağabeyim, ondan sonra ortanca kardeşim gelir, en kötüsü de benim” diye cevap verir
Ağabeyi hastalığı daha şekil kazanmadan fark edip kimse fark etmeden ortadan kaldırdığı için adı sadece aile içinde bilinir; ortanca kardeşi hastalık daha yeni ortaya çıkarken tedavi ettiği için adı köyün sokağının dışına çıkmaz; Bian Que ise damarları deler, güçlü ilaçlar kullanır ve eti keser, bu yüzden gözle görülür eylemleri sayesinde şöhreti derebeyleri arasında yayılır
“Çok çalışan departman”ın kendi yarattığı sorunları kahramanca toparladığı için bir sonraki çeyrekte övgü ve bütçe artışı aldığı şirketler gördüm
Buna karşılık sessizce iyi işleyen benim departmanım, ışıkları açık tutmakta bile zorlanıyordu
Sadece çift tıklama seviyesinde anlayışı olan teknik olmayan yöneticiler ile şirketi gerçekten ayakta tutan mühendislik arasındaki kopukluk yüzünden bu sektörde ciddi bir sorun bu. Çözüm olarak yöneticilerin mühendislik kökenli olması dışında pek bir şey gelmiyor aklıma
Bazı sorunlarda, liderliğin ders çıkarabilmesi için tamir etmeden önce acı sinyalini yukarı göndermek gerekir
Yine de teşvik tasarımı zordur ve en üst düzey yöneticilerin, astlarının ve departmanlarının acıyı ve sorunları görünür kılamadığı bir yapı oluşturmamak gerekir. İyi niyetle sinyali perdeleyen insanlar da yaygındır; bu yüzden büyük organizasyonlarda bazı sorunların gelişmesine izin vermenin ve fazla tepkisel davranmamanın daha verimli olabileceği konusunda koçluk yapmak gerekir
Herkes normal koşulları ve kusursuz operasyonu varsayarak tasarım yaparken, tasarımı, servisi, altyapıyı ve uygulamayı nasıl bozabileceğini arayan biri çok önemlidir
IT departmanından bir arkadaşım ticari sertifikaları Let’s Encrypt ile değiştirip EV gereksinimlerini kaldırarak 2.000 avronun biraz üzerinde alabilirdi, ama sonunda alamadı. Gerekçe bunun “zaten işinin parçası” olmasıydı
Gerçekte çalışan servisleri yapan ekiplerin ise bütçeleri donduruldu, hatta personelleri azaltıldı
Başka bir ekipte sorun çıktığında, bizim ekipte neden aynı sorunun yaşanmadığını tamamlanmış işler listesiyle gösterebiliriz. İş zaten yapılmıştır; sadece kesintiyi önleyebilecek daha iyi bir zamanda yapılmıştır
Bu çok sık yaşanıyor. Özellikle hoşuma giden şey, zarif çözümlerin sonradan bakınca çoğu zaman basit görünmesi
Uzun süre düşünüp akıllıca bir çözüm bulduktan sonra açıkladığınızda karşı tarafın “Evet, tabii” diye tepki vermesi gibi
Yan masadaki kişi problemi gereksiz yere karmaşıklaştırdığında ise, ne kadar zor bir şey yaptığı için övgü alıyor
Büyük şirketler hâlâ karmaşıklığa hayran kalma konusunda geride olabilir, ama doğrudan ya da dolaylı olarak AI çıktısı almak zorunda olan tarafta karmaşıklık artık eskisi kadar etkileyici görünmüyor
Ne kadar mucizevi bir kurtarma olursa olsun, size “Yeğenim küçük bir sorunu anında çözdü” hikâyesi anlatılıyor; sanki benim bunu yapamamış olmamı vurguluyorlarmış gibi geliyor
Sorumlu kişi ise karmaşık yolu seçmesini tavsiye etmiş, çünkü ancak öyle yayımlanırmış. Yani akıllı olduğunuz için değil, çözüm karmaşık duyulduğu için kabul görüyorsunuz
Bu, güzel çözümler yerine karmaşık süreçleri öven gerçeklikle tam örtüşüyor; bürokrasinin de muhtemelen böyle doğduğunu düşündürüyor
O kod, yayına çıktıktan 15 dakika sonra unutuldu ve kimse bir daha okumadı, ama yıllarca kullanıldı. Bu yüzden AI'nın pek çok kişinin düşündüğünden çok daha hızlı biçimde işleri elinden alabileceğini düşünüyorum
Temiz kod, sorumlulukların ayrılması, bakım kolaylığı gibi en çok zaman harcadığımız şeyler gerçekte ödüllendirilmedi. “Yeterince iyi” olduğu sürece yönetici memnun oluyor; sorun çıkarsa AI, isterse spagetti gibi bir yamayla onu düzeltebilir
Önceki iş yerimde benzer bir sorun vardı. Neredeyse tüm zamanımı toplantı planlamak, insanların toplantıdan önce gerekli bilgilere sahip olmasını sağlamak gibi arka planda yürüyen idari işlere harcıyordum
Ama performans değerlendirmesinde bana söylenen tek önemli şey, işlerin dağılmasını engellemekle meşgul olduğum için çok fazla story point bitirememiş olmamdı
Ben de tüm idari işleri bırakıip sadece story point tamamlamaya odaklandım; 1-2 hafta sonra yönetici takıma, “Neden tüm toplantılar raydan çıktı? Toplantıya giriyoruz ve kimse neler olduğunu bilmiyor” diye sordu
Y2K hazırlığı için yaklaşık 2 yıl boyunca ağ, donanım ve IT işleriyle inanılmaz yoğun çalıştıktan sonra pazarlamaya geçmeye başladım. Sonunda, “nasıl olsa hiçbir şey olmadı” diye neredeyse tüm şirketler bu zamanın ve paranın boşa gittiğini düşündü
Hatta bir şirket ücretin tamamını geri istedi; ben de yaptığım işleri geri alabilseydim iade yapabileceğimi söyledim, onlar da kabul etti. Ertesi gün şirketin tüm sistemleri çöktü
Babamın şirketinin ağ desteğini de, ücretimi asla ödemek istemedikleri için üstlenmek zordu. İki başka kişi sorunu çözemeyip ben 15 dakikada düzelttikten sonra bu kez de sadece 15 dakika sürdüğü için para ödemek daha da zorlarına gitti
Bir şeyi bozulmadan ayakta tutma becerisi takdir görmüyordu; takdir gören tek şey, bozulduktan sonra gidip düzeltmekti. Pazarlama daha iyi ücret veriyordu ve her gün maaşımı somut rakamlarla gerekçelendirebiliyordum. Çok daha az sevsem de, yaptığım herhangi bir IT işinden daha fazla saygı görüyor
Takdir gören şeyler yazıcı tamir etmek, bilgisayar sorunu A/B/C’yi çözmek, arkadaşlar için yaptığım reklamsız Android Sudoku gibi basit şeyler
Para karşılığı yaptığım asıl iş takdir görmüyor. Sanırım birçok sektörde para devreye girince sözleşmedeki rolü yerine getirmek zaten beklendiği için minnettarlık azalıyor
Teknolojiden anlamayan insanlar, geliştiricilerin evden çalışıp günde sadece 30 dakika çalıştığını sanıyor; AI da bu imajı daha kötü hale getirdi
Ian Rush bunu çok iyi söylemişti: “En iyisi forvet olmaktır. Beş kez kaçırırsın ama galibiyet golünü atarsan kahraman olursun. Kaleci ise muhteşem kurtarışlar yapar ama tek gol yerse kötü adam olur”
Çalıştığım her yerde, yangın çıkmasını engelleyenlerden çok itfaiyeciler ödüllendirildi. Daha da kötüsü, teşvikleri belirleyenler dışında herkes bunun hesabını apaçık biliyordu
Bir de işin karşı tarafı var. Hiç olmayacak şeyler için tüm zamanını kaygıyla geçiren insanlar da bulunduğundan, mesele sadece savunmacı tutumu ödüllendirmek değil
İş yerinde terfiler de böyle oluyor. Bir şeyi bozarsın, konu escalation ile görünür hale gelir, bir yöneticiye e-posta gider. Sonra sen gidip onu “düzeltince” herkes teşekkür eder, aferin der
Bir başka versiyonu da zaten yapılması gereken işi uzun süre geciktirip görünürlüğünü artırmaktır. Yöneticiler, sorun büyümeden sorumluluk alıp işi bitiren insanların emeğini görmez
Ama bir şeyi bozup günü “kurtaran” kişinin adını hatırlarlar
Bu arada yöneticiye yağ çeker, “doublerabbit’e bırakmamak daha iyi”, “takım oyuncusu gibi görünmüyor” der. Üstelik bunların hepsi benim altyapımdı
İnsanların bana neden insanlardan nefret ettiğimi sorduğunun sebebi bu
Bunu ilkokul birinci sınıfta öğrenmiştik aslında. Derste uslu duran ve ödevini yapan çocuklar öğretmenin zamanını ve emeğini fazla almaz
Kurallara uymayan ve ders için en ufak çabasında bile sürekli övgü gerektiren sorunlu çocuklar öğretmenin ilgisini çeker
IT’de geçirdiğim zaman iki uç arasında gidip geldi
“Etraftaki her şey gayet iyi çalışıyor. IT’ye niye para ödüyoruz?”
“Her şey mahvolmuş. IT’ye niye para ödüyoruz?”
Ben şahsen ikincisinden ziyade birincisini hedefliyordum. “İşimi doğru yaparsam burada olduğumu bile fark etmezsiniz” derdim. Ama tam da bu yüzden işten çıkarıldım
Karmik bir tatmin gibi, eski şirketimdeki insanlarla hâlâ iletişimdeyim ve orası şimdi tam bir keşmekeş. Bu da az da olsa teselli veriyor
Yetkinlik tuzağını bir kez fark edince her yerde görüyorsunuz
Sterman, Repenning ve diğer ortak yazarlar bu makaleden sonra birkaç tane daha yazdı; hepsi ilginç ama neredeyse hepsi moral bozucu
Özellikle sistem dinamiğinin ilk kez akademik bir alan olarak yerleştiği MIT Sloan’ın, sistem dinamiğinin ilk kez görmezden gelindiği Harvard Business School’un hemen yakınında olması daha da ironik