Laravel geliştirici: işe almak mı, ekip takviyesi mi?

Laravel geliştirici arayan bir şirketin önünde iki ana yol var: kadroya tam zamanlı birini almak ya da ekip takviyesiyle belirli bir süre için dışarıdan kıdemli birini ekibe katmak. Ürünün uzun vadeli sahibi olacak biri gerekiyorsa işe alım; bir derinlik eksiğini hızlıca kapatmak, bir dönemi köprülemek ya da tek bir zor alanı çözmek gerekiyorsa takviye daha doğru. Çoğu küçük ekip için en sağlıklı cevap ikisinin birlikte kullanıldığı hibrit yol.

Önce hangi problemi çözdüğünüzü yazın

"Laravel geliştirici lazım" cümlesi bir problem tanımı değil. Aynı cümlenin arkasında birbirinden çok farklı ihtiyaçlar olabilir:

• Ürün büyüyor ve sürekli iş var; uzun vadede bu kodun sahibi olacak biri gerekiyor.
• Ekipte geliştirici var ama kıdemli kimse yok; mimari kararlar ve kod incelemesi boşlukta.
• Bir kod tabanı devraldınız ve kimse dokunmak istemiyor.
• Belirli bir alan — kuyruklar, ödeme, yetkilendirme, performans — ekibe yabancı.
• Bir sürüm tarihi yaklaşıyor ve kapasite yetmiyor.

İlk madde işe alımı işaret ediyor. Diğerlerinin çoğu ya takviyeyle ya da ikisinin birleşimiyle daha hızlı çözülüyor. Modellerin genel farkını yazılım ekibi kiralama nedir yazımızda ayrıntılı anlattık; burada yalnızca işe alım ile takviye arasındaki seçime odaklanıyoruz.

İşe alım süresi: takvimde görünmeyen aylar

İşe alım kararı verildiği gün başlamaz, kişinin ilk commit'iyle biter. Arada şu adımlar var:

1. İlanın yazılması ve yayınlanması, ya da bir işe alım danışmanıyla çalışılması.
2. Başvuruların elenmesi; kıdemli roller için çoğu zaman aktif aday arama.
3. Bir ya da birkaç teknik görüşme, varsa deneme görevi.
4. Teklif, pazarlık ve adayın kararı.
5. Adayın mevcut işverenindeki ihbar süresi.
6. Oryantasyon: kişinin kod tabanını, iş kurallarını ve ekibi tanıması.

Bu adımların her biri haftalar sürebilir ve aralarından biri — örneğin adayın son anda başka bir teklifi kabul etmesi — süreci başa döndürebilir. Takviyede ise bu zincirin çoğu yoktur: kişi bellidir, başlangıç tarihi sözleşmede yazılıdır ve oryantasyon sizin kod tabanınızla sınırlıdır. Ama o kişinin şirkette kalıcı olmadığını da baştan bilirsiniz.

Kıdemi değerlendirmek neden zor

İçeride kıdemli bir geliştirici yoksa, kıdemli bir geliştiriciyi değerlendirmek de zordur. Yıl sayısı, özgeçmişteki şirket adları ve "Laravel biliyorum" cümlesi çok az şey söyler. Aynı yıl sayısıyla bir kişi her yıl yeni bir şey öğrenmiş olabilir, bir başkası aynı yılı beş kez yaşamış olabilir.

Bu yüzden teknik bilgisi olmayan bir kurucu ya da yönetici genellikle iki hatadan birine düşer: ya en iyi konuşanı seçer ya da güvende kalmak için en uzun özgeçmişi. İkisi de kodun kalitesini ölçmez.

Burada takviyenin dolaylı bir faydası var: dışarıdan gelen kıdemli bir geliştirici, işe alım sürecinde teknik değerlendirmeye de katılabilir. Adayın deneme görevini okuyabilir, görüşmede doğru soruları sorabilir ve "bu kişi bizim kod tabanımızda ne kadar sürede verimli olur" sorusuna somut bir yanıt verebilir.

Bilgi kimde kalıyor?

İşe alımın en güçlü argümanı bilgi birikimi. Tam zamanlı bir çalışan iş kurallarını, müşterilerin tuhaf taleplerini ve "bu alan neden böyle" sorusunun cevabını zamanla öğrenir ve şirkette tutar. Takviyede bu bilgi, özenle yazıya dökülmezse, kişiyle birlikte gider.

Ama bu, takviyenin doğası değil, uygulamanın kalitesi. Bilgi kaybını önlemenin yolları belli:

• Önemli teknik kararlar ekibin okuyabileceği bir yerde, kısa karar notları olarak yazılsın.
• Dışarıdan gelen kişinin her işi kod incelemesinden geçsin; en az bir iç ekip üyesi her değişikliği görmüş olsun.
• Kurulum, deploy ve sık yapılan operasyonlar README ya da wiki'de adım adım dursun.
• Erişimlerin hepsi şirketin hesaplarında açılsın, kişisel hesaplarda değil.

Aynı kurallar tam zamanlı çalışan için de geçerli. Tek kişinin kafasında yaşayan bir sistem, o kişi ister kadrolu ister dışarıdan olsun, aynı risktir.

Maliyet yapısı: rakamdan önce kalemler

İki yolun maliyetini yalnızca maaş ile günlük ücreti yan yana koyarak karşılaştırmak yanıltıcı. Kalemler farklı:

Kural basit: iş sürekli ve öngörülebilirse uzun vadede işe alım genellikle daha ekonomik. İhtiyaç dalgalıysa, belirli bir uzmanlık gerekiyorsa ya da bir dönemi köprülemek gerekiyorsa takviye daha esnek. Kendi rakamlarınızı bu tabloya göre doldurun; İK ve mali müşavirinizle işveren maliyetini hesaplamadan karar vermeyin.

Hibrit yol: köprü, değerlendirici ve mentor

Küçük ekiplerde en iyi işleyen düzen genellikle şu: işe alım süreci başlarken bir kıdemli geliştiriciyi takviye olarak almak. Bu kişi:

• İşe alım sürerken ürünü ilerletir; sürüm tarihi işe alımın takvimine bağlı kalmaz.
• Kod tabanında en riskli yerleri belirler ve belgelendirir.
• Aday değerlendirmesinde teknik göz olur.
• Yeni çalışan geldiğinde ilk haftalarında onunla birlikte çalışır, kod incelemesiyle bağlamı aktarır.
• Sonra gün sayısını azaltır ya da devri tamamlayıp ayrılır.

Bu yolun dürüst bir sınırı var: takviye edilen kişi bir yöneticinin yerini tutmaz. Ürünün yönünü kim belirleyecek, öncelikleri kim sıralayacak, bunun içeride bir sahibi olmalı.

Bir Laravel geliştiricisini nasıl değerlendirirsiniz

İster işe alın ister takviye alın, değerlendirmeyi gerçek iş üzerinden yapın. Şu kontrol listesi teknik olmayan bir yöneticiye bile yol gösterir; mümkünse kıdemli birinin yardımıyla uygulayın.

• Gerçek kod okuma. Mevcut kodunuzdan bir controller ya da bir pull request'i birlikte okuyun. "Burada neyi değiştirirdin, neden?" sorusuna verilen cevap çok şey söyler.
• Eloquent ve veritabanı. N+1 sorgu probleminin ne olduğunu ve nasıl fark edildiğini anlatabiliyor mu? Migration'ları geri alınabilir yazmanın neden önemli olduğunu biliyor mu?
• Kuyruklar ve zamanlanmış işler. Bir job başarısız olduğunda ne olur, tekrar denemeler nasıl ayarlanır, aynı işin iki kez çalışması nasıl önlenir?
• Yetkilendirme. Policy ve gate kullanımını, "bu kullanıcı bu kaydı görebilir mi" sorusunun nerede yanıtlanması gerektiğini açıklayabiliyor mu?
• Test. Feature ve unit test farkını biliyor mu, test yazılmamış eski bir koda nasıl test eklerdi?
• Sürüm yükseltme deneyimi. Bir Laravel uygulamasını bir ana sürümden diğerine taşıdı mı, neyle karşılaştı?
• Ücretli ve kısa bir deneme görevi. Birkaç saatlik, sizin alanınıza yakın bir görev. Ücretsiz uzun ödevler iyi adayları kaçırır.
• Belirsizliği nasıl yönetiyor? Eksik tarif edilmiş bir işte varsayım yapmak yerine soru soruyor mu?

Yanıtların "doğru" olmasından çok, gerekçelendirilmesine bakın. Kıdemli bir geliştirici çoğu soruya "duruma göre" der ve neye göre değiştiğini açıklar.

Dikkat edilmesi gereken işaretler

Bazı sinyaller, kim olursa olsun, ikinci bir değerlendirmeyi gerektirir:

• Mevcut kodun tamamının "baştan yazılması gerektiğini" ilk görüşmede, kodu görmeden söylemek.
• Test, kod incelemesi ya da dokümantasyonu "zaman kaybı" olarak görmek.
• Her soruya tek bir paket ya da araçla yanıt vermek; neyin neden seçildiğini açıklayamamak.
• Erişimlerin kendi kişisel hesaplarında açılmasında ısrar etmek.
• Daha önce çalıştığı bir kod tabanında yaptığı bir hatayı ya da öğrendiği bir dersi anlatamamak.

Bunların hiçbiri tek başına eleme sebebi değil, ama birkaçı bir aradaysa durup düşünmeye değer.

Nereden başlamalı?

Önce ihtiyacınızı yukarıdaki listedeki maddelerden hangisine denk geldiğine göre yazın ve ürünün uzun vadeli sahibinin kim olacağına karar verin. Uzun vadeli bir sahip gerekiyorsa işe alıma hemen başlayın; o sürecin aylar alacağını varsayarak arayı nasıl köprüleyeceğinizi planlayın.

Ekibinizde birkaç geliştirici var ama kıdemli bir Laravel geliştiricisi eksikse, ya da işe alım sürerken ürünün durmasını istemiyorsanız, yazılım ekibi kiralama hizmetimiz tam bu boşluk için var: ayda kararlaştırılmış gün sayısı kadar, adı belli bir kıdemli geliştirici, sizin repo'nuzda ve sizin sprint'inizde. Durumunuzu bize yazarak anlatın; takviyenin mi işe alımın mı daha doğru olduğunu açıkça söyleriz.