Teknoloji
- Çekirdek sistemin 6-18 ay boyunca baştan yazılmasını talep edin. Önceki CTO'yu suçlayın.
- Herkesin farklı dil ve framework'ler kullanmasını teşvik edin.
- Sistemi keyfi sınırlardan bölün; böylece bir özelliğe birçok sistem dahil olsun.
- Karmaşık bir geliştirme ortamı oluşturun. En az 12 servis içeren bir service mesh çalıştırın.
- Prodüksiyon ortamı ile geliştirici ortamını mümkün olduğunca farklı hale getirin.
- Dağıtımı mümkün olduğunca seyrek yapın. Dağıtımlar konusunda aşırı temkinli olunmasını teşvik edin.
- Kod değişiklikleri ve genel iş akışına son derece karmaşık süreçler ekleyin. Buna mazeret olarak "güvenlik" veya "uyumluluk" deyin.
- Tüm işleri issue tracker'a kaydedin ve en az 5 kişilik bir grubun bunları gözden geçirip önceliklendirmesini ve onaylamasını sağlayın.
- İlk iş kapsamının dışındaki her şeyi yasaklayın. Örneğin kod temizliği veya diğer iyileştirme işlerini yasaklayın.
- Çekirdek yetkinlik olmayan neredeyse her şeyi kurum içinde geliştirin. Bunu "vendor lock-in'den kaçınmak" diye gerekçelendirin.
- Her şeye soyutlama katmanı eklenmesinde ısrar edin. Soyutlanmış vendor'lar kullanın ve üstüne ek soyutlama katmanları ekleyin.
- Ölçek konusunda gerçekçi olmayan derecede iyimser teknik kararları teşvik edin. Mevcut yükün en az 3 katına göre plan yapın.
- Sistemin ortak sahipliğini teşvik edin. Kimsenin bakım sorumluluğunu gerçekten hissetmemesini sağlayın.
- Neredeyse her şeyi merkezi bir "platform" altında toplamaya çalışın. Platform ekibini yetersiz kadroyla bırakın ve diğer ekiplerin platformun sahip olabileceği şeyleri geliştirmesini engelleyin.
- Platform ekibinin API'leri sık sık yinelemesini sağlayın ve diğer ekipleri en son sürüme göre kodlarını refactor etmeye zorlayın.
- "Mimarlar" işe alın ve küçük değişiklikler için bile "mimari inceleme" talep edin.
- Küçük değişiklikler için bile "güvenlik incelemesi" talep edin.
Ürün
- Faydalı metrikleri akademik gerekçelerle görmezden gelin. Örneğin bunlara "önyargılı" veya "gecikmeli gösterge" deyin.
- İş değeriyle ilgisi olmayan gösteriş metrikleri seçin. Gürültülü metrikler seçin.
- Her şeyi "büyük bahis" olarak görün ve her şey tamamen bitmeden yayımlamamakta ısrar edin.
- Her özelliği "olmazsa olmaz" ve "sıfırıncı sürüm"ün kritik bir parçası olarak görün. Asla taviz vermeyin.
- Son derece ayrıntılı "stratejik" planlar hazırlayın.
- Sık sık yön değiştirin.
- Bariz iyileştirmeleri "yerel optimizasyon" diyerek küçümseyin.
- En son trendleri kullanarak kaynakları kilitleyin. Yüzeyde makul görünen bir "AI stratejisi" başlatın. Bunun için vendor'lara ve danışmanlara bolca para harcayın.
- Ürün yöneticilerinin zamanlarının çoğunu "strateji" ve "planlama"ya harcamasını teşvik edin.
- Mühendislerin ve ürün yöneticilerinin ürünü şirket içinde kullanmasını zor veya imkansız hale getirin.
- İçeride kullanıcıları "aptal" diye küçümseyin.
Liderlik
- Ödülleri unvanlara ve ekip büyüklüğüne bağlayarak şişmeyi teşvik edin.
- Strateji, özellikler veya teknik karmaşıklık hakkında yüksek sesle konuşun.
- Yeni ürün alanlarına girmek için pahalı satın almalar yapın. "Sinerji"den bahsedin. Satın alınan ürünü rafa kaldırın.
- Raporlama yapısında bolca noktalı çizgili ilişki kullanın.
- Mümkün olduğunca çok kişinin başka ekiplerdeki, başka lokasyonlardaki veya başka fonksiyonlardaki yöneticilere raporlamasını sağlayın. Yöneticilerin doğrudan raporlarını denetleyememesini sağlayın.
- Düşük performans gösteren kişileri sık sık başka takımlara taşıyın.
- Yüksek performans gösteren kişileri sonucu belirsiz, aşırı spekülatif AR-GE projelerine atayın.
- Önemsiz kararlar için bile her zaman toplantı isteyin.
- Tüm "paydaşlar"ın toplantılara katılması gerektiğinde ısrar edin.
İşe alım
- Görünüşte objektif ama gerçekte öznel bir işe alım süreci oluşturun.
- En iyi yetenekleri "kültüre uyumsuzluk" veya başka muğlak gerekçelerle reddedin.
- En zayıf adayları "potansiyel", "tavır" veya başka muğlak gerekçelerle işe alın.
- Büyük kadro taahhütleriyle birlikte gelen, çok pahalı üst düzey yöneticiler işe alın.
- Fırsatçıları çekmek için şişirilmiş unvanlar ve uydurulmuş roller kullanın.
- Çok uzmanlaşmış "uzmanlar" işe alın, sonra ayrılmamaları için onlara yapay projeler yaratın.
- Uzmanlaşmayı, bunu tamamlayacak başka insanları işe almanın gerekçesi olarak kullanın.
Proje yönetimi
- Tüm projeler için aşırı ayrıntılı tahminler isteyin.
- Mümkün olduğunca çok ekibi, ideal olarak da farklı lokasyonlardaki ekipleri kapsayan projeleri teşvik edin.
- Başka ekiplerin yaptığı işlere bağımlı yeni gereksinimler ekleyin.
- Pahalı ajansları sık sık kullanın. Kapsamı belirsiz bırakın ve bitmemiş prototipleri iç ekiplere teslim edip tamamlamalarını isteyin.
- Diğer ekiplerdeki paydaşlar için karmaşık "self-service" sistemleri inşa edin.
Sonuç
- Üretkenliği düşürmek zor bir iştir. Ama düşman hattının gerisine paraşütle inip CTO olarak işe girerseniz bunu başarabilirsiniz.
- Yıkıcı olmayan insanlar için: Bu, aslında bir ekibin üretkenliğini nasıl en üst düzeye çıkaracağınıza dair bir yazı. Üretkenlik, küçük şeylerin birikimiyle oluşur.
- 100 küçük şeyin her biri %5'lik bir üretkenlik vergisi getirirse her şey 131 kat yavaşlar. Mühendisleri mutlu tutmak için kulağa makul gelen bu 100 küçük şeyi reddetmek gerekir.
GN⁺ görüşü
- Bu yazı, yazılım geliştirmede üretkenliği baltalamanın çeşitli yollarını mizahi bir dille anlatıyor. Böylece gerçekte kaçınılması gereken davranışlar net biçimde görülebiliyor.
- Teknik borcu azaltmak ve verimli bir geliştirme kültürünü korumak önemlidir. Gereksiz karmaşıklık ve bürokrasiden kaçınmak kilit noktadır.
- Ekip moralini yükselten ve iş birliğini teşvik eden bir ortam yaratmak önemlidir. Bunun üretkenlik artışı üzerinde doğrudan etkisi vardır.
- Bu yazı, yazılım mühendisliği ve yönetimin karmaşıklığını anlamaya yardımcı olur. Özellikle junior mühendisler için faydalı içgörüler sunar.
- Benzer temaya sahip diğer işler arasında "The Phoenix Project" gibi kitaplar da vardır. Bunlar IT ve DevOps verimliliğini artırmanın yollarını ele alır.
11 yorum
Böyle yapmayan şirket var mı ki? hüzün hüzün
Küçük ve başarılı bir şirket bile büyüyünce sanki sonunda hep böyle oluyor...
Önceki şirkette talimat olarak verilen işlerin çoğu burada varmış. Kullanamayacağın bir platformun zorla kullandırılması... standart performans göstergelerinin görmezden gelinmesi... daha önce yapılmış görevlerin tekrar yaptırılması falan filan
Şey..?
Bu tam olarak şu: 'Bakımı zor kod yazma sanatı: böylece sen de geliştirici olarak ömür boyu yan gelip yatabilirsin'...
Ölümüne seçeneğini tercih edeceğim.
Ah.. ah!.. aa!!.. Ah!... ah......
Bunlardan birkaçını bizim organizasyonumuzda da görmek üzücü. hıçkırık hıçkırık
Efsanevi "Bakımı Zor Olacak Şekilde Nasıl Kod Yazılır" kitabını hatırlatıyor.
Ben de bu kitabı!
"Bu kadar da mı?" diye düşünülebilir ama yukarıdaki şeyleri tek bir kişinin ya da tek bir organizasyonun başarabileceğini de düşündürüyor.^^
Hacker News görüşleri
CIA önerisinin gerçekten işe yarayıp yaramadığına dair güven eksikliği: CIA’nin asıl önerisinin gerçekten işe yaradığına dair ikna edici bir gerekçe gördüğümü hatırlamıyorum; ayrıca organizasyonlar doğal olarak böyle insanları görmezden gelme eğilimindedir.
Bir şirket nasıl batırılır: Kötü insanları yöneticiliğe terfi ettirmek ve kârlı olmayan şeyleri optimize etmelerini sağlamak, şirkete büyük zarar verebilir.
Yıkıcı bir CTO nasıl olunur: Neredeyse hiçbir şey yapmamak, yetkin insanları tasfiye etmek ve sorumluluğun aşağıya itildiği bir kültür oluşturmak kolaydır.
Resmî kanallar üzerinden çalışma ve yazılı emir talebi: Bazı insanlar için resmî kanallar üzerinden çalışmak ve yazılı emir istemek daha üretken olabilir.
OSS ile CIA arasındaki fark: OSS (Stratejik Hizmetler Ofisi) II. Dünya Savaşı sırasında harika bir kitap hazırladı; CIA ise 1947’de kuruldu.
Vizyonun önemi: Bir ürünün genel olarak nasıl çalıştığına ya da daha iyi bir geleceğe dair tutarlı bir vizyona sahip kişileri uzaklaştırmak en kritik adımdır.
İşe alım bölümünün güncellenmesi gerekiyor: Leetcode’daki zor soruları 30 dakika içinde çözmeyi şart koşmak ve belirsizlik ile şüpheye tahammül etmemek gerekiyor.
Prod ortamı ile geliştirici ortamı arasındaki fark: Modern mimarilerde çok sayıda dış servis bulunduğundan, prod ortamı ile geliştirici ortamının farklı olması kaçınılmazdır; bu da geliştiricilerin her zaman internete bağlı olması gerektiği anlamına gelir.
Kendini korumaya yönelik kararlar: “Sabotaj” için alınan birçok karar, insanlara kendi hatalarını örtbas etmeye çalıştıklarını kabul ettirmeye dayanır.
Şirketteki “best practice”ler: Yazının başında sunulan sekiz kural, şirkette “best practice” olarak katı biçimde uygulanıyor.
Danışmanların davranışları: Birçok danışman bu davranışların çoğunu, hatta tamamını sergiliyor.
Teknoloji sektöründeki sorun: Teknoloji sektöründe bu şekilde davranan çok sayıda insan var ve onlar gerçekten yardımcı olduklarına inanıyor.
Büyük şirket deneyimi: Büyük şirketlerdeki sınırlı deneyimim, bu yazıda anlatılanlarla büyük ölçüde örtüşüyor.