"On dört aydır inşa ediyoruz ve hâlâ bir müşteriye onu ne zaman alacağını söyleyemiyorum." İlk görüşmemizde erken aşamadaki bir ödeme şirketinin kurucusu — Series A, yaklaşık on sekiz mühendis — böyle demişti. Ekip güçlüydü ve pazar gerçekti. Eksik olan şey, bulundukları yerden bir müşterinin gerçekten elinde tutabileceği bir şeye giden inandırıcı bir çizgiydi.
Daha fazla mühendise ihtiyaçları yoktu ve bir yeniden yazıma da ihtiyaçları yoktu. Kalıcı bir lider işe alırlarken teknik stratejiyi sahiplenecek birine ihtiyaçları vardı. Fractional CTO olarak yaptığımız şey tam da budur: kıdemli sahiplenme, yarı zamanlı, tanımlı bir süre için — ve bunu geri devretmek için kasıtlı bir plan.
Durum neydi
Şirket, keskin bir demo ve gerçek bir kama üzerine yatırım almıştı: yerleşik oyuncuların yeterince hizmet vermediği küçük işletmeler için sınır ötesi ödemeler. Biz geldiğimizde, on sekiz mühendis dört ekibe (squad) bölünmüştü ve her biri kendi ritminde dağıtım yapıyordu. Bir mühendislik başkanı (head of engineering) yoktu. CEO, ayaküstü toplantılar (stand-up) arasında mimari tartışmalarını çözüyordu ve en kıdemli arka uç (backend) mühendisi, sessizce her sürümün geçmek zorunda olduğu kapı hâline gelmişti.
Yol haritası, dokuz ay boyunca üç lansman tarihi belirlemişti. Üçü de kaymıştı. Kimse tam olarak nedenini söyleyemiyordu, çünkü "bitti" her ekipte farklı bir anlama geliyordu ve dağıtılabilir ilk sürüm hiçbir zaman tek ve üzerinde anlaşılmış bir şey olarak yazıya dökülmemişti.
Aslında yanlış olan neydi
Üç sorun birbirini besliyordu. Kapsam kaymıştı: "MVP" artık çoklu para birimi cüzdanlarını, herkese açık bir iş ortağı API'sini ve bir satıcı panosunu bir araya getiriyordu — her biri kendi başına savunulabilir, hiçbiri ilk ödeme yapan müşteri için elzem değil. Mimari sürüklenmişti: erken bir "önce mikroservis" kararı, iki servisin yeteceği yerde yedi servis üretmişti; öyle ki her özellik bunlardan üçüne dokunuyordu ve entegrasyon her zaman geç ve sancılıydı. Ve ortak bir ritim yoktu — tek bir hazır ve bitti tanımı olmadan, ekipler yerel olarak optimize ediyor ve yalnızca en sonda bir araya geliyordu; ki bu tam da zor sorunların ortaya çıktığı andır.
Tüm bunların altında bir güven sorunu yatıyordu. Yönetim kurulu bir tarih istiyordu; kurucu, ekibin sunduğu hiçbir tarihe artık inanmıyordu; ekip ise başarısızlığa hazırlanmış hissediyordu. Bunu sık görürüz ve bu nadiren bir yetenek meselesidir. Neredeyse her zaman eksik bir karar alma yapısıdır.
Nasıl yaklaştık
Sisteme dokunmadan önce onu anlamak için kendimize iki hafta tanıdık.
Yeniden yapılandırmadan önce dinleyin
Her mühendisle bire bir konuştuk, her ekibin planlamasına katıldık ve son üç ayın pull request'lerini ve olaylarını okuduk. Biz gerçek bağımlılık haritasını istiyorduk, wiki'dekini değil.
Dürüst bir ilk sürüm için çizgiyi yeniden çizin
Gerçek bir müşterinin kullanabileceği tek bir sürümü tanımlamak için kurucuyla çalıştık ve buna hizmet etmeyen her şeyi kestik. Cüzdanlar ve iş ortağı API'si "sonra, bilinçli olarak" sütununa taşındı — görünür, silinmiş değil.
Mimariyi yerinde basitleştirin
Yeniden inşa etmek yerine, en çok haberleşen iki servisi tekrar bire katladık ve doğruluğun en çok önem taşıdığı ödeme defterinin (ledger) etrafına kalın bir sınır çizdik.
Ekibin sahiplendiği bir ritim kurun
Tek bir ortak hazır ve bitti tanımı, haftalık bir entegrasyon kontrol noktası ve tamamlanmamış işin kimseyi engellemeden birleştirilebilmesi için feature flag'ler.
Somut olarak ne yaptık
Sonraki iki ay boyunca sıkı, görünür bir program yürüttük. İçeriden iki ekip lideri (squad lead) atadık ve onlara gerçek karar yetkileri verdik; bu da kurucuyu günlük mimari görüşmelerinden çekip çıkardı. Yedi servisi, üç çekirdek artı iki destekleyici servisten oluşan bir yapıda birleştirdik ve defteri tek bir sahiplenen ekibin arkasına taşıdık. Düzgün bir hazırlık (staging) ortamı ve dürüst bir sinyal veren bir CI boru hattı kurduk; böylece "kod tamamlandı" ifadesi "şimdi acı başlıyor" anlamına gelmeyi bıraktı. Dağıtımı sürümden ayırmak için feature flag'ler devreye aldık. Ve yönetim kurulunun beş dakikada okuyabileceği tek sayfalık bir teknik strateji yazdık — kurucu dâhil herkesin gerçekten güvendiği ilk çıktı.
Nereye vardı
| Metrik | Öncesi | Sonrası |
|---|---|---|
| Kod tamamlanmasından üretime | Yaklaşık üç hafta | Bir haftadan kısa |
| Kritik yoldaki servisler | Yedi | Üç |
| Sprint taahhüdünü tutturan ekipler | Kabaca üçte bir | Yaklaşık dörtte üç |
| Müşterinin kullanabileceği ilk sürüm | Tarihsiz, kayma sayısı 3× | ~10 haftada dağıtıldı |
| Kurucuya iletilen (escalate) sürümler | Çoğu | Nadir |
Sayılar, temsil ettikleri şeyden daha az önemli: yeniden bir tarih vaat edip onu tutabilen bir ekip. Görev sonunda girişim, ilk müşterilerinin her gün kullandığı bir sürüm dağıtmıştı ve — aynı derecede önemlisi — bir kurtarma değil, çalışan bir sistem devralan kalıcı bir Mühendislik Başkan Yardımcısı (VP of Engineering) işe almıştı. Son ayımızı onların yanında geçirdik, sonra çekilip gittik.
Farkı yaratan neydi
Üç ders bu tek şirketin ötesine taşınır. Birincisi, kapsam bir liderlik eylemidir, bir backlog angaryası değil; neyi inşa etmeyeceğimize karar vermek, yaptığımız en yüksek kaldıraçlı tek hamleydi. İkincisi, ritim kahramanlığa üstün gelir — haftalık entegre olan bir ekip, en sonda entegre olan daha yetenekli bir ekipten daha fazla dağıtım yapar. Üçüncüsü, organizasyon şemasını ve mimariyi birlikte basitleştirin; yedi servis ve net sahiplerin olmaması, iki kostüm giymiş aynı sorundu.
Bir fractional CTO, kendini gereksiz kılarak hakkını verir. İşi doğru yaptığımızın en iyi işareti şu: bir yıl sonra oradaki hiç kimsenin, bir zamanlar işin içinde olduğumuzu hatırlamasına gerek yok.