CTO’ya yalan söyleyip krizi atlatan olay

Bir geliştiricinin CTO’ya yalan söyleme hikâyesi

• Bu, birkaç yıl önce Fortune 500 şirketlerinden birinde çalıştığım dönemde yaşanan bir olay
• O sırada CTO, kişisel bağlantısı olan önemli bir müşteri için büyük bir proje almış ve kritik bölümü büyük bir teknoloji hizmeti sağlayıcısına outsource etmeye karar vermişti
• Ancak tedarikçinin "ürünü", gerçekte gereksinimlere uyması için kapsamlı özelleştirme gerektiriyordu ve bu yapılabilecek en kötü tercihti
• CTO ile yapılan durum kontrol toplantılarında kimse bunun iyi bir fikir olduğunu düşünmüyordu ama herkes sadece "Harika fikir patron" diyordu
• Sonunda tedarikçi "ürünü" teslim ettiğinde takvimler zaten eylülü gösteriyordu ve ekim lansmanı için ölüm yürüyüşü başlamıştı
• Testler sırasında performans sorunları ve MongoDB’nin 16MB belge sınırına takılma gibi ciddi hatalar bulundu
• Müşteriye lansmanın 1 ay gecikeceğini söylerken, aynı anda tedarikçi entegrasyonunun yerine geçecek gizli bir projeyi başlatmaya karar verdik
• Genç ve hevesli bir geliştirici olan ben, 3 ekip arkadaşını görevlendirip alternatif sistemi geliştirmeye başladım
• Aralık ortasında, son bir ayda alternatif yazılımı neredeyse tamamlamıştık ama herkes tükenmiş durumdaydı
• Tam o sırada CTO geldi ve tatilleri iptal ettiğini söyledi, ben de "Tamamdır" diye yanıt verdim
• Ama babamın öğüdünü hatırlayıp ekip arkadaşlarıma tatile çıkmalarını söyledikten sonra, tek başıma CTO ile yapılan ölüm yürüyüşü durum toplantısına katılıp yalan söyledim
  • "Ekip sıkı çalışıyor. Bugün 73. kilometre taşı entegrasyon noktasına ulaştık"
  • "Ekip dün iyi ilerleme kaydetti. Bir web servisini daha bitirdiler"
• Bir hafta sonra dinlenmiş ekip arkadaşları geri döndü ve ocakta son tarihe yetişip başarıyla yayına çıkabildik

GN⁺ görüşü

• Zorlu koşullar ve aşırı talepler altında bile projeyi başarıyla yöneten liderliğin öne çıktığı bir örnek. Özellikle ekip üyelerinin durumunu gözetmesi etkileyici
• Ancak CTO’ya yalan söylemek doğru değil. Uzun vadede bu, kurum içi güveni zedeleyip daha büyük sorunlara yol açabilir
• Tedarikçi seçimi ve outsource sürecinin yönetimindeki başarısızlıkta CTO’nun sorumluluğu büyük olsa da, bunu düzeltme sürecinde daha şeffaf ve daha proaktif iletişim gerekirdi
• Geliştiricilerin tükenmişliğini önlemek için en baştan daha gerçekçi bir takvim oluşturulmalı ve yeterli insan kaynağı sağlanmalıydı. Crunch mode kaçınılması gereken bir uygulama
• Benzer sorunlarla karşılaşıldığında başvurulabilecek alternatiflerden biri agile metodolojidir. Kısa döngülerle geliştirme yapıp geri bildirim alma sürecini yineleyerek hem risk azaltılabilir hem de ekibin iş yükü daha iyi dengelenebilir

[GN⁺]

Hacker News görüşleri

• Aşırı çalışma ve izin iptali:
  • Gerçekçi olmayan teslim tarihlerine yetişmek için aşırı çalışmak ve izni iptal etmek akıllıca değildir; sonradan pişmanlık yaratır
  • Çalışanların ürün teslim etmek için izinlerinden vazgeçmesine bel bağlayan şirketler, sorunlu bir iş yeri kültürüne katkıda bulunur
• Sağlıklı şirket vs sağlıksız şirket:
  • Sağlıklı bir şirkette, deneyimli kişiler outsourcing yaklaşımındaki sorunları öngörür ve endişelerini erkenden dile getirirdi
  • Açık iletişim, çözüm bulmak için birlikte çabalamak ve yöneticilerin ekibin refahını savunması sağlıklı bir ortamın işaretleridir
  • Hikâye, bir yöneticinin üstlerine tekrar tekrar yalan söylediği sağlıksız bir durumu tasvir ediyor
• Saçma vendor uygulamaları:
  • Tüm işlemleri devasa bir JSON belgesinde saklayıp her güncellemede tamamını okumayı gerektiren vendor yaklaşımı akıl almaz
  • Bir başka örnek de kullanıcı bilet verilerini kullanıcı tablosunda ek sütunlar olarak tutup yüzlerce sütun oluşturan bir startup
• İşlevsiz durumlar ve liderlik:
  • Takım liderinin izin konusunda yalan söyleyen yaklaşımı kabul edilemez ve işten çıkarılmaya kadar gidebilecek bir ihlaldir
  • Daha iyi yaklaşım, mantıksız fazla mesai taleplerine karşı çıkmak ve sağlıklı proje kapsamını serta vendor sorumluluğunu savunmaktır
  • Takım lideri, kendi işini riske atsa bile ekibi çılgın taleplerden korumakla yükümlüdür
• Kimse fayda görmüyor:
  • Vendor düşük kalite sundu, CTO olan bitenden habersizdi, geliştiriciler aşırı çalıştı ve hikâyenin kahramanı yalana başvurdu
  • Bu, kimsenin tolere etmemesi gereken çılgın bir durumdur. Daha iyi bir iş yerine gitmek tercih edilir
• Dürüstlük ve şeffaflık:
  • Teknik sorunlar, performans problemleri ve kapsam değişiklikleri gibi konularda yönetime dürüst davranmak bazı insanlar için iyi sonuç verdi
  • Gerçeklerden kopuk liderliğin koyduğu keyfi teslim tarihlerine uymak için yalan söylemek iyi bir yaklaşım değildir
• Geliştirici-yönetim arasındaki güven açığı:
  • Geliştiriciler ile teknik olmayan yöneticiler arasında çoğu zaman bilgi asimetrisi ve güven eksikliği vardır
  • Yöneticiler ilerlemeyi kolayca değerlendiremez ve projenin başarısı konusunda belirsizlik hisseder
  • Risk iş tarafında olduğu için geliştiricilerin bu güven açığını kapatmak adına yüklenip teslimat yapması gerekir
• Az söz verip fazlasını teslim etmek:
  • Hikâyenin kahramanının zaten bitmiş bir işi bitirdiğini söylemesi bir ölçüde "az söz verip fazlasını teslim etmek" olarak görülebilir
  • Tamamlanmamış iş hakkında yalan söylemek daha risklidir ve ekip arkadaşlarının geri dönme konusunda moralini bozabilir
• Güçsüz organizasyonlar ve low-code araçlar:
  • Vendorun berbat uygulamaları ve mütevazı proje kapsamı, bazı büyük şirketlerin yazılım projeleri karşısında ne kadar çaresiz hissettiğini gösteriyor
  • Bu durum, mühendisler için olmasa bile teknoloji liderliği nezdinde Retool gibi low-code araçların popülerliğini açıklayabilir
• Dürüstlük ve hayır diyebilmek:
  • Gerçek bir "rockstar", dürüstlüğe sahip olan ve aptallığa ya da mantıksız taleplere hayır deme cesareti gösteren kişidir
  • Olağanüstü beceriksizliği telafi etmek ya da tüm ekibin yükünü sırtlanmak bireyin sorumluluğu değildir