--- title: "Yeni Geliştiricinin İlk 30 Günü: İşe Alıştırma Planı" url: "https://cilginyazilim.com/blog/yeni-gelistiricinin-ilk-30-gunu-ise-alistirma-plani" description: "Yeni geliştiriciyi verimli hâle getiren onboarding planı: ilk gün, ilk hafta ve ilk ay hedefleri, mentor ataması ve ölçülebilir başarı kriterleri." published: "2026-09-05T10:00:00+03:00" modified: "2026-09-05T10:00:03+03:00" author: "superadmin" category: "Kariyer ve Öğrenme" tags: ["verimlilik", "eğitim", "süreç", "ekip çalışması", "yazılım kültürü", "dokümantasyon", "geliştirici deneyimi", "onboarding", "işe alıştırma", "ekip yönetimi", "mentorluk", "ilk katkı", "kurum içi eğitim"] site: "CılgınYazılım" language: "tr" --- # Yeni Geliştiricinin İlk 30 Günü: İşe Alıştırma Planı İlk gün laptop ve 40 sayfalık doküman vermek işe alıştırma değildir. Ölçülebilir bir 30 günlük plan. **İşe alıştırma** (onboarding), çoğu şirkette bir dizi belge ve birkaç tanışma toplantısından ibarettir. Yeni geliştiriciye bir bilgisayar, birkaç hesap ve "şu dokümanları okuyabilirsin" cümlesi verilir. Sonuç genellikle aynıdır: ilk iki hafta belirsizlik içinde geçer, kişi soru sormaya çekinir ve gerçek verimlilik aylar sonra gelir. Oysa bu süre, planlı bir yaklaşımla belirgin şekilde kısaltılabilir. ![Onboarding kilometre taşları](https://cilginyazilim.com/uploads/blog/2026/07/yeni-gelistiricinin-ilk-30-gunu-ise-alistirma-plani-ozet.png) *İlk katkının erken olması, öğrenme hızını belirleyen tek en güçlü etkendir.* ## Birinci gün: tek hedef, çalışan bir ortam İlk günün başarı ölçütü nettir: yeni geliştirici, günün sonunda uygulamayı kendi makinesinde çalıştırabilmelidir. Bu basit görünen hedef, birçok ekipte günler alır — çünkü kurulum adımları eksiktir, dokümantasyon eskimiştir veya yalnızca bir kişinin bildiği ayarlar vardır. Bunun çözümü, kurulumu ilk günün konusu olmaktan çıkarmaktır: tek komutla çalışan bir kurulum betiği veya hazır bir konteyner yapılandırması. Bu yatırım, her yeni katılımda geri döner ve mevcut ekip için de faydalıdır. Otomasyon kararının hesabı için [otomasyon yazımıza](https://cilginyazilim.com/blog/tekrarlayan-isleri-otomatiklestirmek-ne-zaman-script-yazmali) bakabilirsiniz. Pratik bir ipucu: kurulum dokümanını, o gün işe başlayan kişinin kendisine güncelletin. Takıldığı her adımı not alması, dokümanın gerçekten güncel kalmasının en sürdürülebilir yoludur. ## İlk üç gün: yayına çıkan ilk değişiklik İşe alıştırmanın en güçlü aracı, erken bir başarıdır. Yeni geliştiricinin ilk üç gün içinde küçük ama gerçek bir değişikliği yayına çıkarması hedeflenmelidir — bir metin düzeltmesi, bir hata mesajının iyileştirilmesi, küçük bir arayüz düzenlemesi. Bunun amacı üretkenlik değil, *süreci öğrenmektir*: dal açmak, değişiklik yapmak, testleri çalıştırmak, kod incelemesine göndermek, geri bildirim almak ve dağıtımı görmek. Bu zinciri bir kez baştan sona yaşamak, aynı bilgiyi anlatan on sayfalık dokümandan çok daha etkilidir. Bu yüzden her ekibin elinde hazır bekleyen birkaç "ilk katkı" işi bulunmalıdır. Bunlar zor olmamalı ama gerçek olmalıdır — yapay bir alıştırma değil, gerçekten yayına çıkacak bir değişiklik. ## İlk hafta: bir hata kaydını baştan sona çözmek İkinci kilometre taşı, küçük bir hata kaydının tamamen yeni kişiye verilmesidir. Hata ayıklama süreci, bir sistemi öğrenmenin en hızlı yoludur çünkü kişiyi kod tabanında gezinmeye, log okumaya ve katmanlar arasındaki ilişkiyi anlamaya zorlar. Dokümantasyon okumak pasif, hata aramak aktiftir. Burada mentorun rolü kritiktir: cevabı vermek değil, nereye bakılacağını göstermek. Hata ayıklama alışkanlıkları için [hata ayıklama yazımız](https://cilginyazilim.com/blog/hata-ayiklamada-zaman-kurtaran-aliskanlik) ve araç kurulumu için [hata ayıklayıcı rehberimiz](https://cilginyazilim.com/blog/hata-ayiklayiciyi-gercekten-kullanmak-debugger) bu aşamada paylaşılabilecek kaynaklardır. ## İkinci hafta: kod incelemesine katılmak Yeni geliştiricinin kod incelemesi yapmaya başlaması genellikle çok geciktirilir; oysa inceleme yapmak, kod tabanını öğrenmenin en verimli yollarından biridir. Başkasının değişikliğini okumak, hem kod standartlarını hem de ekibin karar alma biçimini gösterir. Bu aşamada beklenti açıkça belirtilmelidir: yeni kişiden onay vermesi değil, soru sorması beklenir. "Bunu neden böyle yaptık?" sorusu, çoğu zaman ekibe de fayda sağlar — çünkü alışkanlık hâline gelmiş kararları görünür kılar. İnceleme kültürü için [kod incelemesi yazımıza](https://cilginyazilim.com/blog/kod-incelemesinde-neyi-nasil-elestirmeli) bakabilirsiniz. ## Otuzuncu gün: tek başına teslim edilen bir özellik Ayın sonundaki hedef, küçük ama uçtan uca bir özelliğin yeni kişi tarafından tasarlanıp teslim edilmesidir. Bu, öğrenilenlerin gerçekten yerleşip yerleşmediğinin en dürüst sınavıdır ve aynı zamanda kişiye ekibin bir üyesi olduğu duygusunu verir. ## Planın işlemesi için gerekenler - **Atanmış bir mentor.** "Herkese sorabilirsin" pratikte "kimseye soramazsın" demektir. Tek bir isim, soru sormanın eşiğini düşürür. - **Sorulara açık bir alan.** Yeni kişinin en büyük korkusu aptalca soru sormaktır. Mentorun ilk gün "ilk iki hafta her soru meşrudur" demesi, bu eşiği belirgin düşürür. - **Yazılı ama kısa dokümantasyon.** 40 sayfalık bir doküman okunmaz. Gerekli olan; mimari için bir sayfalık genel bakış, kurulum adımları ve "kim ne biliyor" listesidir. - **Düzenli geri bildirim.** Birinci hafta ve birinci ay sonunda kısa birer değerlendirme, sorunları erken yakalar. Kurum içi eğitim programlarında en sık yapılan hatalar için [eğitim programı yazımıza](https://cilginyazilim.com/blog/kurum-ici-egitim-programinda-en-buyuk-hata) bakmanızı öneririz. Ekip kültürünün yazılı iletişim tarafı için ise [yazılı iletişim yazımız](https://cilginyazilim.com/blog/uzaktan-calisan-ekipte-yazili-iletisim) tamamlayıcıdır. Genel yol haritaları için [roadmap.sh](https://roadmap.sh/) paylaşılabilir bir kaynaktır. ## Ölçmek: plan işliyor mu? İşe alıştırmanın kalitesi ölçülebilir. İzlenebilecek birkaç basit gösterge: ilk katkının yayına çıkma süresi, ilk bağımsız özelliğin teslim süresi ve otuzuncu günde yapılan kısa bir görüşmede alınan geri bildirim. Bu sayılar ekipler arasında karşılaştırıldığında, sürecin nerede tıkandığı genellikle hemen görünür hâle gelir. ## Sonuç İyi bir işe alıştırma süreci, daha çok doküman yazmakla değil, yeni kişiyi mümkün olduğunca erken gerçek işin içine sokmakla kurulur. Birinci gün çalışan bir ortam, üçüncü gün yayına çıkan ilk değişiklik, birinci hafta çözülen bir hata ve otuzuncu gün teslim edilen bir özellik — bu dört kilometre taşı, aylar sürebilecek bir uyum sürecini haftalara indirir. Ekibinize son katılan kişiye tek bir soru sorun: "İlk değişikliğin kaçıncı gün yayına çıktı?" Cevap iki haftadan uzunsa, iyileştirilecek yer sürecin kendisidir. ## Sıkça Sorulan Sorular ### Uzaktan çalışan ekiplerde bu plan işler mi? Evet, ancak mentorluk ve soru sorma kanalları daha bilinçli kurulmalıdır. Uzaktan çalışmada yeni kişi "acaba rahatsız eder miyim" çekincesini daha yoğun yaşar; düzenli kısa görüşmeler bu etkiyi azaltır. ### Deneyimli bir geliştirici için de aynı plan geçerli mi? Kilometre taşları aynı kalır, süreler kısalır. Deneyim, kod tabanını ve ekibin kararlarını öğrenme ihtiyacını ortadan kaldırmaz. ### Mentor olmak deneyimli geliştiricinin verimini düşürmez mi? Kısa vadede bir miktar düşürür, orta vadede artırır: iyi alıştırılmış bir geliştirici çok daha erken bağımsızlaşır ve mentorun yükünü kalıcı olarak azaltır. ### İlk katkı için uygun iş bulamıyorsak ne yapmalı? Genellikle sorun iş bulunamaması değil, listelenmemiş olmasıdır. Küçük iyileştirmeleri fark ettikçe "ilk katkı" etiketiyle biriktirmek, bu havuzu doğal olarak oluşturur. --- Kaynak: [Yeni Geliştiricinin İlk 30 Günü: İşe Alıştırma Planı](https://cilginyazilim.com/blog/yeni-gelistiricinin-ilk-30-gunu-ise-alistirma-plani)