Yönetim literatürünün büyük bölümü, ürün geliştiren ekipler için yazılmıştır. Hızlı yinele, ileriye doğru başarısız ol, suçlayıcı olmayan postmortem'ler, üretkenliği artıran bir kaldıraç olarak psikolojik güven. Hiçbiri, her ayın 15'inde emeklilik düzenleyicisini besleyen yasal bir boru hattıyla temas ettiğinde ayakta kalmıyor — yanlış bir rakam, bir sonraki sprint'te düzeltilecek bir bug değildir; resmi bir düzeltme yazısı, bir düzenleyici bulgu ve sizin retrospektifinizi umursamayan insanlarla yapılan bir toplantıdır.
Emeklilik ve hayat sigortasında paralel yasal raporlamadan sorumlu bir veri ekibini yönetmenin on beşinci ayında, açıkça söyleyebilirim: ürün ekipleri için yazılmış liderlik el kitapları burada yalnızca işe yaramaz değil; tehlikelidir. Size mühendislerinize güvenmenizi, süreç sürtünmesini kaldırmanızı, bireyleri güçlendirmenizi söylerler. Sıfır hata ortamında bu tavsiyeler sizi işten ettirir ve daha da önemlisi, şirkete yaptırım uygulanmasına yol açar.
Temel çerçeve değişikliği şudur: performansı yönetmiyorsunuz. Bireysel hatanın üretime ulaşamayacağı bir sistem tasarlıyorsunuz. Bu ayrımın aşağısındaki her şey — işe alım, kod incelemesi, nöbet, hatta 1:1 görüşmelerini nasıl yürüttüğünüz — değişir.
Yüksek Riskli ile Sıfır Hata Arasındaki Fark
İnsanlar bunları karıştırıyor. Bir işlem masası yüksek risklidir — bir hata para kaybettirir, bazen çok. Yasal bir emeklilik hesaplaması sıfır hatadır — bir hata, bir ihlaldir. Ekonomisi farklıdır. Yüksek risklide, sonuç dağılımı üzerinde beklenen değeri optimize edersiniz. Sıfır hatada, sol kuyruğun var olmasına izin verilmez.
Bu, "iyi"nin neye benzediğini değiştirir:
- Zamanın %98'inde temiz kod üreten hızlı bir mühendis varlık değil, yükümlülüktür.
- İkinci bir göz olmadan merge etmeyi reddeden yavaş bir mühendis işi doğru yapıyordur.
- %0,02'lik bir varyansı fark edip boru hattını durduran bir analist bilgiçlik yapmıyordur — para ödediğiniz davranış tam da budur.
Performans değerlendirmeleriniz hızı ödüllendiriyorsa, ekibi düzenleyicinin bulacağı tam o başarısızlık moduna eğitiyorsunuz demektir.
Onboarding, Güven İnşa Etmek Değil, Güveni Almakla İlgilidir
İçgüdü, yeni katılanları erkenden sorumluluk vererek işe almaktır. Yanlış içgüdü. Yasal bir boru hattında yeni katılan biri en az üç ay boyunca hiçbir şeye sahip olmamalıdır. Yetenekli olmadıkları için değil — çoğu kıdemli alımlardı — ama kod tabanındaki hangi varsayımların taşıyıcı, hangilerinin dekoratif olduğunu henüz bilmiyorlar.
Bunun yerine yaptığım şey:
- İlk iki döngü için gölge çalıştırmalar. Önceki ayın çıktısını kendi makinelerinde yeniden üretirler ve dosyalanan rakamla son kuruşa kadar mutabakat sağlarlar.
- İlk ay için yalnızca okuma erişimi. Dokunamadıkları şeyi kıramazlar.
- Artık dolaylı olarak sorumlu oldukları her düzenleyici son tarihin yanına finansal cezasıyla birlikte yazılı bir listesi. Korkutmak için değil — kalibre etmek için.
Amaç, kıdemli bir mühendisin güvenini, yanılmanın bedelinin bir Jira ticket'ı olmadığını yeni fark etmiş birinin tevazusuyla değiştirmektir.
Kod İncelemesi Bir Kontroldür, Bir Sohbet Değil
Ürün ekiplerinde kod incelemesi işbirlikçidir — "bu yaklaşım hakkında ne düşünüyorsun?". Düzenlemeye tabi finansta, kod incelemesi denetçilerin soracağı telafi edici bir kontroldür. Farklı bir biçime sahiptir:
- Yasal bir hesaplamadaki her değişiklik iki incelemeci gerektirir; bunlardan birinin son 90 gün içinde etkilenen modülün herhangi bir parçasını yazmamış olması gerekir.
- İncelemeciler yalnızca kodu değil, test kanıtlarını da onaylar. "İyi görünüyor" bir inceleme değildir. "Paralel çalıştırmaya karşı mutabakat sağlandı, varyans tolerans dahilinde, yıl ortası statü değişikliği olan poliçe sahipleri için sınır durumu doğrulandı" bir incelemedir.
- İncelemeci ile yazar arasındaki anlaşmazlıklar müzakere edilmez, eskalasyona alınır. Yazar incelemeciyi ikna etme hakkına sahip değildir. Şüphe varsa, bana ya da aktüeryal lidere gider.
Bu ağır geliyor. Öyle. Ayrıca yönettiğim dönemde tek bir düzeltme dosyalamamış olmamızın da sebebi bu.
Paralel Boru Hatları Yedeklilik Değildir — Mimarinin Kendisidir
Verdiğimiz tek en önemli karar, çekirdek yasal hesaplamanın iki bağımsız uygulamasını farklı dillerde, farklı kişiler tarafından çalıştırmak ve her dosyalamadan önce mutabakatlarını yapmaktı. Yedek olarak değil. Birincil kontrol olarak.
Bu pahalıdır. Herhangi bir değişikliğin maliyetini kabaca iki katına çıkarır. Aynı zamanda tek bir geliştiricinin yanlış bir rakam göndermesinin önüne geçer. Kendi tarafında yanlış bir rakam üretebilir, ancak mutabakat binadan çıkmadan önce bunu işaretler.
Yönetim zorluğu, çalışmaları tasarım gereği tekrarlı olduğunda her iki ekibi de motive tutmaktır. Öğrendiklerim:
- Aynı modülün iki uygulamasının sahibi asla aynı kişi olmasın. Tüm mesele bağımsızlık.
- Hangi uygulamanın belirli bir çeyrekte referans alındığını rotasyona alın. Aksi takdirde biri "gerçek" olur, diğeri lastik damga haline gelir.
- Bir mutabakat bozulduğunda, notları karşılaştırmadan önce iki taraf da bağımsız olarak araştırır. Çok erken işbirliği yaparlarsa, birlikte yanlış cevaba yakınsarlar.
Olay Müdahalesi Dosyalama Sonrası Değil, Dosyalama Öncesidir
Ürün dünyasında bir olay, üretimde meydana gelen ve sizin müdahale ettiğiniz bir şeydir. Yasal raporlamada, üretime girdiği anda — yani dosyalandığı anda — artık bir olay değildir. Bir düzenleyici meseledir.
Dolayısıyla tüm olay müdahale aygıtı sola kayar. "Olay", dosyalama öncesi penceredeki bir mutabakat varyansıdır. "Nöbetçi", dosyalama gününde boru hattının başında oturan ve gönderiyi durdurma yetkisine sahip kişidir. "Postmortem", düzenleyiciye herhangi bir şey ulaşmadan önce gerçekleşir, sonrasında değil.
Bu, görece kıdemsiz kişilere bir dosyalamayı durdurma yetkisi vermeyi gerektirir. Bu, onlar dahil herkes için rahatsız edicidir. Ekibime açıkça söylüyorum: bir dosyalamayı durdurursanız ve yanılırsanız, başınıza kötü bir şey gelmez. Bir dosyalamayı durdurmazsanız ve durdurmanız gerekiyorsa, sizi koruyamayacağım tek hata budur.
Yapmayı Bıraktığım Şeyler
Ana akım yönetim tavsiyesinin yapmamı söylediği ama artık yapmadığım şeylerin kısmi bir listesi:
- Düzenli bir uygulama olarak skip-level 1:1'ler. Hesap verebilirliği bulanıklaştırırlar. Bir kontrol ortamında, sorumluluk zinciri temiz olmalıdır.
- Ekibi "hızlı hareket et ve öğren" diye teşvik etmek. Yasal çıktıda öğrenmelerine izin verilmez. Sandbox'larda, geçmiş yeniden çalıştırmalarda, kukla portföylerde öğrenirler.
- Ham teknik yetenek için işe almak. Önce mizaca göre işe alıyorum. Sahip olduğum en iyi mühendis en zeki olan değil — emin olmadığında durup soran kişi. Bu içgüdü, herhangi bir framework uzmanlığından daha değerlidir.
- Dokümantasyona ek yük muamelesi yapmak. Boru hattındaki her varsayım belgelenir, çünkü onu yazan kişi sonunda ayrılacak ve düzenleyici sonunda soracaktır.
Kültürel Bedel
Bu yönetim tarzı moda değildir. Ürün geçmişinden gelen mühendisler ilk başta boğucu bulurlar. Bazıları ayrılır. Kalanlar genellikle ya daha önce düzenlemeye tabi ortamlarda çalışmış olanlar ya da bir düzenleyiciye yanlış bir şey göndermenin nasıl hissettirdiğini bizzat deneyimlemiş olanlardır. O ikinci kategorideki deneyimin yerini hiçbir şey tutamaz ve onu imal edemezsiniz.
Ayrıca size, bir yönetici olarak, kolay galibiyetlere de mal olur. Demo günü yoktur. Çeyreklik lansman yoktur. En iyi ay, hiçbir şeyin olmadığı, her şeyin mutabık kaldığı ve kimsenin fark etmediği şekilde dosyalamanın çıktığı aydır. Başka herhangi bir şirkette görünür bir şeyi kutlayacak olan bir ekibe, bunu bir başarı gibi hissettirmenin bir yolunu bulmanız gerekir.
Gerçek iş budur. Bir ekibi daha fazlasını yapmaya motive etmek değil. Ekibin en kötü gününde bile düzenleyiciye ulaşan yanlış bir rakam üretemeyeceği bir ortam tasarlamak. Geri kalan her şey süslemedir.