Ana sayfa → Ekip Yönetimi
Yeni Mühendisin İlk 30 Günü: Oryantasyon Değil, İlk Canlı Değişiklik
Onuncu gün sordum: “Okuduklarından aklında ne kaldı?” Bir süre düşündü. “Açıkçası hiçbiri. Hiçbirini kullanmadım.” Laptopu üçüncü gün gelmişti, test ortamı erişimi sekizinci gün açılmıştı. İlk değişikliği canlıya 23. iş gününde çıktı.
- Tek sayı yeter: ilk canlı değişikliğe kadar geçen iş günü. Laptoptan deploy hattına kadar yolun tamamını ölçüyor.
- Gecikmenin çoğu bekleme. Bizde 23 günün 14’ü laptop, erişim ve onay beklemekle geçti. Bunlar ilk günden önce çözülür.
- İlk iş gelenden önce yazılır. Küçük, gerçek, canlıya çıkan, geri alınabilir. Alıştırma değil, kritik yol da değil.
- Buddy bir rol, iyi niyet değil. Günde iki kısa görüşme ve sprint kapasitesinden düşülen %20.
- Doküman iş yaparken okunur. Okuma listesi unutuluyor; kullanılan doküman hem kalıyor hem düzeltiliyor.
Sahadan: 23 iş günü
Geçen Eylül ekibe bir backend mühendisi katıldı. Pazartesi 09:30’da geldi. Masada bir sandalye, bir hoş geldin kupası ve 140 sayfalık bir okuma listesi vardı. Laptop yoktu; BT’ye talebi Cuma günü açmıştık.
Plan kafamda netti: “İlk iki hafta sistemi tanısın, doküman okusun, sonra işe başlar.” Bir aracı kurumda sistemi anlamadan koda dokunmak riskli, diye düşünüyordum. Kulağa sorumlu bir karar gibi geliyordu.
Olan şuydu. Laptop üçüncü gün geldi. VPN beşinci gün çalıştı. Test ortamı erişimi güvenlik onayından geçip sekizinci gün açıldı. Lokal ortamı kurmak dört gün sürdü, çünkü README iki yıl önce yazılmıştı: veritabanı sürümü eskiydi ve piyasa verisi için gereken sahte servisin adı değişmişti. Bunu kimse bilmiyordu, çünkü ekipteki herkes ortamını yıllar önce kurmuştu.
İlk commit on birinci gün geldi. İlk canlı değişiklik 23. iş gününde çıktı. Sonradan günleri tek tek saydım: 14 gün bir şey beklemekle geçmişti. Laptop, erişim, onay, bana sorulacak bir sorunun cevabı. Geri kalan dokuz günün büyük kısmı da okuduğu ve kullanmadığı şeylerle geçmişti.
O hafta sorunun oryantasyonda olmadığını anladım. Ben bir bilgi aktarım programı kurmuştum. Oysa yeni gelenin ihtiyacı yolu bir kez baştan sona yürümekti.
Neden ilk canlı değişiklik?
Canlıya çıkan tek satırlık bir değişiklik bile uzun bir yoldan geçiyor: laptop, repo erişimi, lokal ortam, testler, kod incelemesi, pipeline, test ortamı, onay, deploy. Yolun herhangi bir yerinde bir engel varsa, ilk değişiklik orada takılıyor. Takıldığı yeri de sen görüyorsun.
Bu yüzden ölçtüğüm tek sayı bu: ilk canlı değişikliğe kadar geçen iş günü. “Oryantasyon tamamlandı mı” sorusunun cevabı hep evet. “Kaçıncı gün canlıya çıktı” sorusunun cevabı ise bir sayı ve o sayı yalan söylemiyor.
Sayının asıl değeri şu: kişiyi değil hazırlığı ölçüyor. 23 gün, yeni gelenin yavaş olduğunu söylemiyordu. Laptop talebinin Cuma açıldığını, erişim onayının tek sıraya dizildiğini ve README’nin iki yıldır kimse tarafından denenmediğini söylüyordu. Hepsi benim alanımdaydı. Hiçbiri yeni gelenin elinde değildi.
Bir yan etkisi daha var: ilk değişikliğini canlıda gören kişi, ekibe katıldığını hissediyor. Onuncu gününde hâlâ doküman okuyan kişi ise hâlâ misafir. Mühendislik metrikleri yazısında anlattığım gibi, sayı burada da karne değil; nereye bakacağını söylüyor.
Birinci günden önce
14 günlük beklemenin neredeyse tamamı, kişi gelmeden önce çözülebilecek şeylerdi. Şimdi teklif kabul edildiği gün bir liste açılıyor:
GUN -10 : Erisim talepleri acilir (11 kalem).
Ilk hafta icin SART olan 4 kalem isaretlenir:
repo, VPN, test ortami, pipeline.
Canli veritabani okuma erisimi bu listede YOK.
GUN -5 : Laptop hazir, standart imaj kurulu.
Lokal ortam scripti bu laptopta bir kez calistirilir.
GUN -3 : Ilk is ticket olarak yazilir, ekipte kimse dokunmaz.
GUN -1 : Buddy belirlenir, sprint kapasitesinden %20 dusulur.
GUN 0 : Laptop masada. Ogleden sonra lokal ortam ayakta.
GUN 1-3 : Ilk is -> inceleme -> test ortami -> canli.
KURAL : Listede bir kalem gecikirse ilk gun ertelenmez,
gecikme ilk degisiklik sayisina yazilir.Listenin en önemli satırı, lokal ortam scriptinin yeni laptopta bir kez çalıştırılması. İlk seferde bu adımı atladık. Script, ekipteki herkesin makinesinde zaten kurulu olan bir aracı varsayıyordu. Temiz bir makinede ilk satırda patladı. Bunu kişi gelmeden önce görmek, ilk günün yarısını kurtarıyor.
Erişim tarafında da bir ayrım yaptık. Bir aracı kurumda erişim onayı haklı olarak yavaş. Ama ilk değişiklik için gereken erişimle ilk ay içinde gerekecek erişim aynı şey değil. Canlı veritabanına okuma yetkisi ilk hafta gerekmiyor. Onu beklerken diğer dördünü de bekletmek, en yavaş onayı herkesin hızı yapıyor.
İlk iş nasıl seçilir
İlk iş yanlış seçilirse hazırlık listesinin kazandırdığı her şey ilk incelemede kayboluyor. Bunu da yaşadım; aşağıda anlatacağım.
- Bir günde biter
- Gerçek bir kullanıcıya dokunur, canlıya çıkar
- Yolun tamamından geçer: test, inceleme, pipeline, deploy
- Tek adımda geri alınabilir
- Gelenden önce yazılmış ve bekletilmiştir
Örnek: portföy ekranında yanlış yuvarlanan bir komisyon etiketi.
- “Kodu kurcala, kendine bir şey bul”
- Canlıya hiç çıkmayacak bir alıştırma projesi
- Emir iletimi gibi kritik bir yol
- Kimsenin sahiplenmediği eski bir hata
- “Yeni gelen bakar” diye biriktirilmiş sıkıcı işler
Hepsi ya yolu yürütmüyor ya da ilk adımda yoruyor.
Bir günde bitme kuralı keyfi değil. İşi sekiz saatlik parçalara bölmenin mantığını epic, story, task yazısında anlatmıştım. Yeni gelen için bu kural daha da önemli, çünkü ilk hafta her şey iki kat uzun sürüyor. Bir günlük iş üç günde bitiyor. Üç günlük iş iki hafta sürüyor ve kimse neden diye sormuyor.
Buddy: iyi niyet değil, rol
İlk denemede ekibin en kıdemli mühendisini buddy yaptım. Mantıklı görünüyordu: en çok bilen o. Ama en meşgul olan da oydu. Yeni gelen iki gün boyunca bir soruyu sormadı, “çok yoğun, rahatsız etmeyeyim” dedi. Soru basitti: test ortamında hangi kullanıcıyla giriş yapılır?
Şimdi buddy için üç kural var:
- Takvimde görünür. İlk iki hafta günde iki kez 15 dakika: sabah ve öğleden sonra. Soru biriktirmek yerine bu saatlere getiriliyor.
- Kapasiteden düşülür. Buddy’nin sprint kapasitesinden %20 çıkıyor. Düşmezsen buddy iki işi birden yapmaya çalışıyor ve yeni gelen fark ediyor.
- En kıdemli kişi değil, yolu en yakın zamanda yürüyen kişi. Bir yıl önce gelmiş biri, hangi adımın takıldığını hâlâ hatırlıyor.
İlk inceleme, ekibin ilk cevabı
Yeni gelenin ilk PR’ı, ekip hakkında öğrendiği ilk gerçek bilgi. Oryantasyon sunumunda “birbirimize yardım ederiz” yazıyor olabilir. Ama PR iki gün cevapsız kalırsa ya da ilk yorum bir değişken adı üzerine üç paragraflık bir ders olursa, kişi sunumu değil o yorumu hatırlıyor.
Bu yüzden ilk PR için ayrı bir kural koyduk: aynı gün, dört saat içinde incelenir. İncelemeyi buddy yapmaz; ekipten başka biri yapar. Böylece yeni gelen ilk haftada en az iki kişiyle gerçek bir iş üzerinden konuşmuş oluyor. Yorumlar da ikiye ayrılıyor: canlıya çıkmayı engelleyenler ve “bir dahaki sefere” notları. İkinci türü ilk PR’da bir mesajda toplayıp geçiyoruz.
Bu, kalitenin gevşetilmesi değil. İlk iş zaten küçük ve geri alınabilir seçildiği için riski düşük. Riski düşük bir işte standart yorum yığını, sadece yeni gelene “burada her şey zor” mesajı veriyor. Aynı kişi iki ay sonra kritik bir servise dokunduğunda inceleme sıkı olacak. O gün neden sıkı olduğunu da bilecek.
Doküman ne zaman okunur
140 sayfalık listeyi çöpe atmadım. Sadece sırasını değiştirdim. Artık doküman bir işin içinden açılıyor: komisyon etiketini düzeltirken komisyon hesaplama sayfası, pipeline’a takılınca deploy sayfası. Okunan şey hemen kullanılınca kalıyor.
Bir de yeni gelenin ilk hafta yazdığı bir şey var: kurulum dokümanının düzeltmesi. Ekipte herkes ortamını yıllar önce kurduğu için README’nin nerede yanlış olduğunu kimse göremiyor. Göremeyen kişi yeni gelen değil; bilen herkes. Kurulum dokümanını en son kuran kişi günceller; bu kural koyduğumuzdan beri README her işe alımda bir kez düzeliyor.
İlk 30 gün: haftalık hedefler
| Dönem | Hedef | Kanıt |
|---|---|---|
| 1. gün | Lokal ortam ayakta, testler geçiyor | Lokalde çalışan bir test |
| 1. hafta | İlk değişiklik canlıda | Deploy kaydında adı |
| 2. hafta | İkinci ve üçüncü küçük iş; ilk kod inceleme yorumu | Başkasının PR’ına yazdığı yorum |
| 3–4. hafta | Bir özelliğin tamamında payı; ilk gölge nöbet günü | Sprint review’da kendi anlattığı iş |
Tablodaki dördüncü satır, ilk 30 günün asıl hedefi. Kişi otuzuncu günde artık “yeni gelen” değil, ekibin sıradan bir üyesi olarak iş alıyor. İlk hafta bunun ön şartı; tek başına hedef değil.
Ne izlemeli?
| Ne | Neden |
|---|---|
| İlk canlı değişikliğe kadar iş günü | Yolun tamamının tek sayısı; bizde 23 → 9 → 3 |
| Bu sürenin kaç günü bekleme | Beklemeyi kişi değil, hazırlık üretiyor |
| Lokal ortamın ayağa kalkma süresi | Bir günü geçiyorsa script ya da README bozuk |
| İlk PR’ın incelemede beklediği süre | İlk iş yanlış seçildiyse burada görünür |
| Yeni gelenin README’ye yaptığı düzeltme sayısı | Sıfırsa ya doküman kusursuz ya da kimse okumadı |
Bende işe yaramayanlar
- İki haftalık okuma listesi. 140 sayfa. Onuncu gün aklında kalan neredeyse hiçbir şey yoktu. Bu kişinin değil, benim hatamdı: bağlamı olmayan bilgiyi ezberletmeye çalışmıştım.
- Üç saatlik hoş geldin sunumu. Şirket tarihi, organizasyon şeması, ürün haritası. Ertesi gün kimsenin adını hatırlamadı. Şimdi 30 dakika ve tek slayt: ekip, sahip olduğumuz servisler, kime ne sorulur.
- İlk işi kritik yoldan seçmek. İkinci işe alımda “gerçek iş olsun” diye emir iletimi servisinde küçük bir değişiklik verdim. Değişiklik küçüktü ama servis kritikti; inceleme altı gün sürdü, dört kişi yorum yazdı. İlk canlı değişiklik 9. gündü ve bunun altı günü incelemeydi. Hazırlık listesi bekleme süresini düşürmüştü; yanlış seçilen iş, kazanılan süreyi incelemede harcattı.
- “Soru sormaktan çekinme” demek. Söylemek yetmiyor. Buddy’nin takvimde görünen bir saati olmadıkça herkes çekiniyor.
Üçüncü işe alımda dört şeyi birlikte yaptık: hazırlık listesi, gelenden önce yazılmış bir günlük iş, kapasitesi düşülmüş buddy ve iş yaparken açılan doküman. İlk canlı değişiklik üçüncü iş gününde çıktı. Lokal ortam ilk gün öğleden sonra ayaktaydı. İlk hafta README’de iki düzeltme yaptı. Bu sayıları tek bir işe alım üzerinden gördüğümü de not ediyorum; üç kişi bir istatistik değil. Ama 23 günün 14’ünün bekleme olduğunu görmek için istatistiğe gerek yoktu.
Kontrol listesi
- Erişim talepleri en az on gün önce açıldı mı, ilk hafta için şart olanlar ayrıldı mı?
- Laptop hazır mı ve lokal ortam scripti o laptopta bir kez çalıştırıldı mı?
- İlk iş ticket olarak yazıldı mı, bir günde bitiyor mu, canlıya çıkıyor mu?
- İlk iş kritik bir yola dokunuyor mu? (Dokunuyorsa değiştir.)
- Buddy belli mi, takvimde saati var mı, kapasitesinden düşüldü mü?
- İlk PR’ı aynı gün kim inceleyecek?
- İlk haftanın planında “doküman oku” dışında somut bir iş var mı?
- Son işe alımda ilk canlı değişiklik kaçıncı gündeydi ve bunun kaç günü beklemeydi?
- README’yi en son kim, ne zaman düzeltti?
Sonuç
O onuncu gün sorusunu hâlâ hatırlıyorum. “Aklında ne kaldı?” diye sorarken kişiyi ölçtüğümü sanıyordum. Aslında kurduğum süreci ölçüyordum ve süreç sınıfta kalmıştı.
Değişen şey bir program değil, bir sıralama oldu. Önce yol hazırlanıyor, sonra kişi yolu bir kez yürüyor, sonra doküman o yolun üstünde okunuyor. 23 gün 3 güne indi. Bu farkın hiçbiri yeni gelenin yeteneğinden gelmedi; hepsi o gelmeden önce ne hazırladığımdan geldi.
Test şu: bir sonraki işe alımda, kişi daha gelmeden ilk değişikliğinin ne olacağını söyleyebiliyor musun? Söyleyemiyorsan, onu karşılamaya hazır değilsin.