Yazılım ekibi kiralama nedir? Dört model ve hangisinin size uyduğu

Yazılım ekibi kiralama, kendi kadronuza almadan bir ya da birkaç geliştiricinin belirli bir süre boyunca sizin projeniz üzerinde çalışmasıdır. Ama bu başlık altında birbirinden çok farklı dört model satılıyor: proje bazlı dış kaynak, freelancer, ekip takviyesi (staff augmentation) ve dedicated team. Hangisinin size uyduğu, ürünün sahibinin kim olduğuna ve içeride karar verecek biri olup olmadığına bağlı.

Dört model aynı şeyi satmıyor

Teklif toplarken en sık yapılan hata, bu dört modeli aynı rafta görüp günlük ya da aylık rakamları yan yana koymak. Oysa her biri farklı bir şey satıyor ve riski farklı bir tarafa yüklüyor.

Tablodaki en önemli sütun "yönü kim belirliyor". Diğer her şey ondan türüyor. Teslim riskinin kimde olduğu, fiyatın nasıl kurulduğu, sözleşmenin neyi güvenceye aldığı ve ilişki bittiğinde elinizde ne kaldığı bu sorunun cevabına bağlı. Aynı geliştirici, aynı günlük ücretle iki farklı modelde çalışabilir; ama birinde sonucu siz yönetirsiniz, ötekinde tedarikçi. Teklifleri karşılaştırmadan önce hangi modeli satın aldığınızı netleştirmek bu yüzden fiyat pazarlığından daha önemli.

Proje bazlı dış kaynak: sonucu satın almak

Burada bir yazılım şirketine "şunu kurun" diyorsunuz. Kapsam, kabul kriterleri ve fiyat başta yazılıyor; tedarikçi işi teslim ediyor, siz kabul ediyorsunuz. İçeride hiç geliştiriciniz olmasa bile çalışır, çünkü teknik kararların sahibi tedarikçidir.

İyi işlediği yer: sipariş takibi, saha formu, onay akışı gibi sınırları çizilebilen bir iş yazılımı. Kötü işlediği yer: öncelikleri her hafta değişen, sürekli hareket hâlindeki bir ürün. Orada her değişiklik yeni bir teklif turuna dönüşür ve iki taraf da yorulur.

Bu yolu düşünüyorsanız yazılım yaptırma rehberimiz süreci, süreyi ve maliyeti etkileyen kalemleri ayrıntılı anlatıyor.

Freelancer: hızlı başlangıç, tek kişilik risk

Freelancer'la anlaşmak genellikle en hızlı yol. İyi bir freelancer, küçük ve iyi tarif edilmiş bir işi — bir entegrasyon, bir rapor ekranı, bir performans sorunu — kısa sürede çözebilir.

Sorun modelin kendisinde değil, tek bir kişiye bağımlılıkta. Kişi başka bir projeye geçtiğinde, hastalandığında ya da ilgisini kaybettiğinde bilgi de onunla gider. Bu riski azaltmanın yolları basit ama sık atlanıyor:

• Kod baştan sizin hesabınızdaki repo'da dursun, onun kişisel hesabında değil.
• Sunucu, alan adı ve üçüncü taraf servis erişimleri sizin adınıza açılsın; ona ayrı ve sınırlı bir kullanıcı verilsin.
• Kararlar yazışmalarda değil, ekibin okuyabileceği bir yerde yazılı tutulsun.

Freelancer'la çalışırken kod incelemesini kimin yapacağını da baştan konuşun. İçeride kodu okuyabilecek kimse yoksa, teslim edilen işin kalitesini ancak bir şey bozulduğunda öğrenirsiniz.

Ekip takviyesi: eksik derinliği ekibinizin içine almak

Ekip takviyesinde (İngilizcesiyle staff augmentation) dışarıdan gelen geliştirici sizin ekibinizin bir parçası gibi çalışır. Sizin panonuzdan iş alır, sizin pull request kurallarınıza uyar, günlük toplantınıza katılır. Ürünün yönü sizde kalır; dışarıdan gelen kişi o yöne derinlik ekler.

Bu model en çok şu durumlarda anlam kazanıyor:

• Ekibinizde birkaç geliştirici var ama kıdemli bir Laravel'ci yok.
• Devraldığınız bir kod tabanına kimse dokunmak istemiyor.
• Kuyruklar, ödeme, yetkilendirme ya da kaynağını bulamadığınız bir performans sorunu gibi tek bir alan ekibe yabancı.
• İşe alım sürüyor ve kişi başlayana kadar bir köprü gerekiyor.

Takviyenin işlemediği durum da net: içeride ürün hakkında karar verebilecek kimse yoksa. O zaman dışarıdan gelen kişi ya ticket kuyruğunu eritip yönü kimsenin belirlemediği bir ürün üretir ya da fiilen yöneticiliğe zorlanır. İkisi de kimsenin satın almak istediği şey değil.

Takviyede en sık yapılan hata

Dışarıdan gelen kişiyi ekibin dışında tutmak. Ayrı bir kanal, ayrı bir iş listesi, haftada bir "durum toplantısı" — kulağa düzenli geliyor ama pratikte kişiyi bağlamdan koparıyor. Takviye edilen geliştirici ekibinizin kod incelemesine katılmıyorsa, planlamada söz almıyorsa ve ekibin neden o kararı verdiğini duymuyorsa, ondan beklediğiniz derinliği de alamazsınız. Tersi de geçerli: dışarıdan gelen kişinin kararları kimsenin görmediği bir yerde alınıyorsa, ayrıldığı gün o kararlar da kaybolur. İyi bir takviyenin ölçüsü, kişi bir ay izne çıktığında ekibin onun bıraktığı kodu okuyup devam edebilmesidir.

Dedicated team: size ayrılmış bütün bir ekip

Dedicated team modelinde tedarikçi size geliştiricilerden, çoğu zaman bir test uzmanı ve bir proje yöneticisinden oluşan bütün bir ekip ayırır. Büyük ve uzun soluklu bir ürün işi için mantıklı olabilir; özellikle aynı anda birden fazla alanda ilerlemeniz gerekiyorsa.

İki şeye dikkat edin. Birincisi, ekip büyüdükçe koordinasyon yükü de büyür ve bu yük er geç sizin tarafa taşar. İkincisi, "ekip" sözünün arkasında birbirinin yerine geçen koltuklardan oluşan bir havuz olup olmadığını sorun. Ay ortasında kişinin değişmesi, birikmiş bağlamın da sıfırlanması demek.

Aylık gün modeli pratikte nasıl işliyor

Ekip takviyesinin bizim uyguladığımız şekli aylık gün modeli. Saat değil gün üzerinden çalışıyor, çünkü saatlik faturalama zaman çizelgesini işin merkezine koyuyor ve yanlış şeyi ödüllendiriyor. Pratikte akış şöyle:

1. Problem ve sahiplik netleşir. İlk görüşmede neyin çözülmesi gerektiğini ve mimarinin sahibinin kim olduğunu konuşuruz. Dışarıdan gelen kişinin ticket mı alacağı yoksa bir alanın yönünü mü üstleneceği baştan, yüksek sesle kararlaştırılır.
2. Kişi ve gün sayısı belirlenir. Sözleşmeden önce adı belli tek bir geliştirici ve ayda kaç gün çalışılacağı yazılır. Günlük ücret ve aylık minimum gün sayısı yazılı teklifte yer alır.
3. Geliştirici ekibinize girer. Sizin repo'nuz, dal ve pull request kurallarınız, iş takip sisteminiz. Hangi toplantılara katılınacağı ve çalışma saatlerinin ne kadar örtüşeceği baştan bellidir.
4. Günler o ay içinde kullanılır. Günler aylık olarak önceden ayrılır; böylece kişi ara sıra uğrayan biri değil, gerçekten bağlamın içinde olan biri olur.
5. Kararlar yazılı kalır. Önemli teknik kararlar özel yazışmalarda değil, ekibinizin okuyabildiği yerde tutulur.
6. Ay sonunda özet gelir. Kullanılan günler ve o günlerden ne çıktığı kısa bir özetle paylaşılır.
7. Bırakmak sürpriz olmaz. İki taraflı bir bildirim süresi vardır; ayrılık bir karar olur, kesinti değil.

Çalışma modellerimizin genel şekli ve hangi işte hangisini önerdiğimiz fiyatlar ve çalışma modelleri sayfasında yazılı.

Hangi model size uyar: beş soru

Teklif istemeden önce şu soruları kendinize sorun. Yanıtlar çoğu zaman modeli kendiliğinden seçer.

• İçeride ürün hakkında karar veren biri var mı? Yoksa ekip takviyesi değil, sabit kapsamlı bir proje düşünün.
• Kapsamı bugün kâğıda dökebilir misiniz? Evetse proje bazlı dış kaynak ve sabit fiyat riski size değil tedarikçiye yükler.
• Eksik olan kapasite mi, derinlik mi? Aynı işi yapacak daha çok el gerekiyorsa başka bir model; ekibin bilmediği bir konuda kıdemli bir göz gerekiyorsa takviye.
• İhtiyaç ne kadar sürecek? Birkaç haftalık, sınırlı bir iş için freelancer yeterli olabilir; aylar sürecek bir işte süreklilik ve aynı kişiyle çalışmak öne çıkar.
• Kişi ayrıldığında ne olur? Erişimler, kod ve dokümantasyon sizde kalıyor mu? Hangi modeli seçerseniz seçin bu sorunun yanıtı "evet" olmalı.

Bir not: bu başlık altında gelen taleplerin önemli bir kısmı aslında ucuz kapasite talebi oluyor. Pazartesi başlayacak beş geliştirici arıyorsanız ihtiyacınız büyük bir dış kaynak firması; o başka bir hizmet ve onu iyi yapan şirketler var.

Nereden başlamalı?

Önce kendi durumunuzu tek cümleyle yazın: "Ekibimizde üç geliştirici var, kuyruk tarafında kimse kendine güvenmiyor ve bir sürüm yaklaşıyor" gibi. Bu cümle, hangi modelin uyduğunu büyük ölçüde söyler. Ardından seçtiğiniz tedarikçiye kimin geleceğini, kişinin değişip değişmeyeceğini ve ayrılık durumunda neyin sizde kalacağını sorun.

Ekibiniz varsa ve içinde kıdemli bir Laravel geliştiricisi eksikse, yazılım ekibi kiralama sayfamızda modelin nasıl işlediğini ve ne zaman işe yaramadığını açıkça yazdık. Durumunuzu otuz dakikalık bir görüşmede ya da iletişim sayfasından bize yazarak anlatın; takviyenin mi yoksa tamamen başka bir şeyin mi gerektiğini söyleriz.