Staff augmentation, ekibinize dışarıdan uzman kişileri ekleyerek kapasite ya da yetkinlik açığını kapatma modelidir: kişiler sizin önceliklerinizle ve sizin yönetiminizde çalışır. Dedicated team’de size özel, kendi içinde organize bir ekip kurulur; proje bazlı modelde ise tedarikçi tanımlı kapsamı teslim etmekten sorumludur. Üç model de “dışarıdan yazılım gücü almak” gibi görünse de yönetim sorumluluğu, risk paylaşımı ve fiyatlama mantığı birbirinden çok farklıdır. Yanlış model seçimi; ya ekibinizin yönetim kapasitesini aşan bir koordinasyon yüküne ya da kontrol edemediğiniz bir kara kutuya dönüşür. Bu rehber, farkları somut tablolarla açıklar ve hangi durumda hangisinin seçilmesi gerektiğini gösterir. Hizmet detayları için staff augmentation hizmet sayfamıza da bakabilirsiniz.
Staff augmentation nedir, nasıl işler?
Staff augmentation’da tedarikçi, ihtiyaç duyduğunuz rol için uygun kişiyi bulur, sözleşmesel ve idari süreçlerini yürütür ve süreklilikten sorumlu olur. Kişi ise sizin ekibinizin bir parçası gibi çalışır: sizin sprint planlamanıza katılır, sizin araçlarınızı kullanır, teknik liderinizin önceliklerine göre iş yapar. Kısacası “ne yapılacağına” siz, “kimin, hangi yetkinlikle ve kesintisiz biçimde yapacağına” tedarikçi bakar.
Bu model, teknik liderliği olan ve süreçleri oturmuş ekipler için en verimli sonucu verir. Teknik liderliğin olmadığı bir yapıda staff augmentation, yönetilmeyen kaynak anlamına gelir ve beklenen faydayı sağlamaz.
Staff augmentation’da kim neyden sorumlu?
| Sorumluluk | Müşteri (siz) | Tedarikçi |
|---|---|---|
| Önceliklendirme ve iş dağıtımı | Evet | Hayır |
| Teknik mimari kararlar | Evet | Kişi katkı sağlar, karar sizde |
| Adayın yetkinliği ve seçimi | Son onay | Tarama, ön mülakat, aday sunumu |
| İdari işler, bordro, yan haklar | Hayır | Evet |
| Kişi ayrılırsa yerine kişi sağlama | Hayır | Evet, sözleşmedeki sürede |
| Kod kalitesi standartları | Standardı siz belirlersiniz | Kişinin uymasını sağlar, performansı izler |
| Ekipman ve erişim | Erişimler sizde | Ekipman genellikle tedarikçide |
Dedicated team nedir?
Dedicated team, sadece sizin projeniz için çalışan, uzun süreli ve kendi içinde organize bir ekiptir. Genellikle geliştiriciler, test uzmanı, gerekiyorsa tasarımcı ve DevOps uzmanından oluşur; çoğunlukla bir takım lideri veya proje yöneticisi ekibin günlük işleyişini yönetir. Ürünün yönü ve önceliklendirme sizde (genellikle bir ürün sahibi aracılığıyla) kalırken, ekibin nasıl çalıştığı, kapasitesi ve sürekliliği tedarikçinin sorumluluğundadır.
Dedicated team, kendi iç ekibini kurmak için zamanı veya kaynağı olmayan ama uzun soluklu bir ürün geliştiren şirketler için uygundur. Ekip zamanla ürün bilgisi biriktirir; süreklilik, staff augmentation’a göre daha da önemli hale gelir. Ölçek büyüdüğünde birden çok ekibin koordinasyonu için büyük ölçekli yazılım ekibi yapıları devreye girer.
Proje bazlı (anahtar teslim) model nedir?
Proje bazlı modelde tedarikçi, yazılı bir kapsamı belirli bir süre ve bedelle teslim etmeyi taahhüt eder. Ekibin kim olduğu, nasıl organize olduğu ve işin nasıl yürütüldüğü tedarikçinin sorumluluğundadır; siz teslimatları kabul kriterlerine göre değerlendirirsiniz. Bu model, kapsamı net bir web sitesi, bir entegrasyon veya bir mobil uygulamanın ilk sürümü gibi işler için uygundur.
Proje bazlı modelin zayıf noktası değişime direncidir: kapsam değiştikçe değişiklik talepleri, ek bedeller ve süre uzamaları gündeme gelir. Kapsamı henüz netleşmemiş, keşif gerektiren ürünlerde bu model sıklıkla sürtünme yaratır.
Staff augmentation, dedicated team ve proje bazlı model: karşılaştırma
Aşağıdaki tablo üç modeli aynı kriterlerle yan yana koyar. Hiçbiri diğerinden “daha iyi” değildir; her biri farklı bir ihtiyaca cevap verir.
| Kriter | Staff augmentation | Dedicated team | Proje bazlı |
|---|---|---|---|
| Günlük yönetim | Sizde | Çoğunlukla tedarikçide (takım lideri) | Tedarikçide |
| Ürün yönü ve öncelikler | Sizde | Sizde (ürün sahibi) | Sözleşmedeki kapsamla sabit |
| Teslim sorumluluğu | Sizde | Paylaşımlı | Tedarikçide |
| Kapsam esnekliği | Çok yüksek | Yüksek | Düşük; değişiklik talebiyle |
| Başlama hızı | Hızlı (rol bazlı) | Orta (ekip kurulumu) | Orta (analiz ve teklif) |
| Sizden beklenen yönetim kapasitesi | Yüksek | Orta | Düşük–orta |
| Tipik süre | Birkaç ay ile yıllar arası, esnek | Genellikle uzun soluklu | Projenin süresi kadar |
| Tipik fiyatlama | Adam/ay veya saatlik | Ekip bazlı aylık bedel | Sabit fiyat veya kilometre taşı ödemeleri |
| Ürün bilgisinin birikimi | Ekibinizde ve kişide | Dedicated ekipte | Tedarikçide; devirle size geçer |
| En büyük risk | Yönetilmeyen kaynak | Ekipten kopuk ürün kararları | Kapsam belirsizliği |
Hangi durumda hangi model?
| Durum | Önerilen model | Gerekçe |
|---|---|---|
| İç ekibiniz var, belirli bir rolde (ör. iOS, DevOps) açık var | Staff augmentation | Yönetim zaten sizde, eksik olan sadece yetkinlik veya kapasite |
| Teknik lideriniz var ama yeni bir ürün hattı için ayrı ekip gerekiyor | Dedicated team | Ana ekibi bölmeden paralel ilerleme |
| Teknik ekibiniz yok, kapsamı net bir ilk sürüm yapılacak | Proje bazlı | Yönetim yükünü tedarikçi taşır, bütçe öngörülebilir |
| Kapsam belirsiz, ürün keşif aşamasında | Kısa keşif + dedicated team | Önce kapsam netleşir, sonra kalıcı ekip kurulur |
| Ani yoğunluk (kampanya, regülasyon tarihi) | Staff augmentation | Sınırlı süreli kapasite artışı |
| Uzun vadede ekibi içeri almak istiyorsunuz | Dedicated team, devralma seçeneğiyle | Ekip ve bilgi birikimi kademeli olarak içeri alınabilir |
Rol bazlı ihtiyaçlarınızı netleştirmek için geliştirici kiralama sayfamızdaki rol ve teknoloji listelerini, ekip kompozisyonunu denemek için ise ekip oluşturucu aracını kullanabilirsiniz.
Staff augmentation süreci: adım adım
Aşağıdaki süreler tipiktir; rolün nadirliği, kıdem seviyesi, dil gereksinimi ve şirketinizin karar hızına göre değişir.
| Adım | İçerik | Tipik süre |
|---|---|---|
| 1. İhtiyaç tanımı | Rol, kıdem, teknoloji, çalışma şekli, başlangıç tarihi, süre | 1–3 gün |
| 2. Aday taraması | Tedarikçinin havuzunda ve ağında teknik ön eleme | 3–10 iş günü |
| 3. Aday sunumu ve mülakat | Sizin teknik mülakatınız, gerekirse vaka çalışması | 1–2 hafta |
| 4. Sözleşme ve hazırlık | Hizmet sözleşmesi, NDA, erişim talepleri, ekipman | 2–7 iş günü |
| 5. Oryantasyon | Kod tabanı, araçlar, süreçler, ilk küçük görevler | 1–2 hafta |
| 6. Düzenli değerlendirme | Aylık geri bildirim, çeyreklik performans görüşmesi | Sürekli |
İlk iki hafta için oryantasyon kontrol listesi
- ☐ Kişisel hesaplar açıldı, çok faktörlü kimlik doğrulama aktif
- ☐ Depo, ticket sistemi, iletişim kanalları ve dokümantasyon erişimi verildi
- ☐ Bir “buddy” (eşleştirilmiş ekip üyesi) atandı
- ☐ Mimari genel bakış ve kodlama standartları paylaşıldı
- ☐ İlk hafta için küçük, tamamlanabilir görevler tanımlandı
- ☐ Definition of Done ve kod inceleme kuralları anlatıldı
- ☐ İkinci haftanın sonunda karşılıklı geri bildirim toplantısı planlandı
Fiyatlama: modele göre maliyet mantığı
Üç modelin fiyatlama mantığı, risk paylaşımını yansıtır. Staff augmentation’da kişi başına zaman satın alırsınız; verimlilik riski sizdedir. Proje bazlı modelde bir sonuç satın alırsınız; tahmin hatası riski tedarikçidedir ve bu risk fiyata yansır. Dedicated team ikisinin arasında yer alır.
| Fiyatı etkileyen faktör | Etkisi |
|---|---|
| Rol ve teknoloji | Nadir uzmanlıklar (ör. bazı bulut ve güvenlik rolleri) daha yüksek fiyatlanır |
| Kıdem | Junior, mid, senior ve lead seviyeleri arasında belirgin fark vardır |
| Çalışma şekli | Yerinde çalışma; seyahat, ulaşım ve ofis düzeni nedeniyle maliyeti artırabilir |
| Süre ve taahhüt | Uzun süreli taahhütler genellikle birim fiyatı olumlu etkiler |
| Dil ve saat dilimi | Yabancı dilde çalışma veya farklı saat diliminde mesai ek maliyet yaratabilir |
| SLA ve yedekleme | Kesintisizlik garantisi ve yedek kişi taahhüdü fiyata yansır |
| Ekip yönetimi | Dedicated team’de takım lideri veya proje yöneticisi ayrı bir kalem olabilir |
Rol ve kıdem bazlı bir bütçe nasıl kurulur, toplam maliyet nasıl karşılaştırılır gibi soruların ayrıntılı cevabı yazılım ekibi maliyeti hesaplama rehberimizde yer alıyor.
Riskler ve önlemler
| Model | Tipik risk | Önlem |
|---|---|---|
| Staff augmentation | Kişinin ekibe entegre olamaması | Yapılandırılmış oryantasyon, buddy, ilk ay sonunda karşılıklı değerlendirme |
| Staff augmentation | Yönetim yükünün iç ekibi yorması | Augmente edilen kişi sayısını teknik liderin kapasitesiyle sınırlamak |
| Dedicated team | Ekibin ürün vizyonundan kopması | Düzenli ürün demoları, ürün sahibinin aktif katılımı |
| Dedicated team | Bilginin tedarikçide kalması | Dokümantasyon, kodun sizin depolarınızda olması, devir planı |
| Proje bazlı | Kapsam belirsizliği ve değişiklik talepleri | Detaylı analiz, kabul kriterleri, değişiklik yönetim süreci |
| Proje bazlı | Teslim sonrası bakımın belirsiz kalması | Garanti süresi ve bakım sözleşmesinin baştan tanımlanması |
Hukuki çerçeve: hizmet alımı ve personel sağlama
Üç model de Türkiye’de genellikle hizmet alımı sözleşmesiyle yürütülür: çalışanlar tedarikçinin bordrosundadır ve tedarikçi işi kendi organizasyonuyla sağlar. Hizmetin müşteri işyerinde yürütüldüğü durumlarda 4857 sayılı İş Kanunu md. 2 kapsamındaki alt işverenlik hükümleri değerlendirilmelidir. Geçici iş ilişkisi (md. 7) ise İŞKUR izinli özel istihdam büroları üzerinden kurulabilir; 360 Soft bu statüde değildir ve hizmetlerini hizmet alımı modeliyle sunar. Uygulamadaki ayrıntılar için IT personel kiralama nasıl çalışır rehberimize bakabilir, somut durumunuz için hukuk danışmanınızın görüşünü alabilirsiniz.
Model seçimi için kontrol listesi
- ☐ İşin günlük yönetimini kim yapacak? Bu kişinin zamanı var mı?
- ☐ Kapsam net mi, yoksa ürün hâlâ keşif aşamasında mı?
- ☐ İhtiyaç kaç ay sürecek? Kalıcı mı, geçici mi?
- ☐ Ürün bilgisinin uzun vadede kimde kalması gerekiyor?
- ☐ Bütçe öngörülebilirliği mi, kapsam esnekliği mi daha önemli?
- ☐ ekibin araçları ve süreçleri yeni kişileri karşılamaya hazır mı?
- ☐ Sözleşmede kişi değişikliği, bildirim süresi ve devir planı tanımlı mı?
- ☐ Fikri mülkiyet, NDA ve KVKK maddeleri yazılı mı?
Örnek senaryo: staff augmentation’dan dedicated team’e
Temsili senaryodur. Bir e-ticaret şirketi, kampanya döneminden önce ekibine iki backend geliştiriciyi staff augmentation ile ekliyor. Kampanya sonrası şirket, yeni bir pazar yeri entegrasyonu ürün hattı açmaya karar veriyor. Ana ekibi bölmemek için bir takım lideri, üç geliştirici ve bir test uzmanından oluşan dedicated team kuruluyor; daha önce augmente edilen iki geliştiriciden biri, ürün bilgisini taşıması için bu ekibe aktarılıyor. Ürün sahibi şirket tarafında kalıyor, iki haftada bir demo yapılıyor.
Çalışma şekli: uzaktan, yerinde, hibrit
Model seçiminden bağımsız olarak, ekibin nerede çalışacağı da karar verilmesi gereken ayrı bir başlıktır. Yazılım ekiplerinde uzaktan çalışma yaygınlaşmış olsa da donanım, saha veya yüksek güvenlik gerektiren işlerde yerinde ya da hibrit düzen tercih edilir.
| Çalışma şekli | Avantaj | Dikkat edilecek nokta | Uygun olduğu durumlar |
|---|---|---|---|
| Uzaktan | Geniş aday havuzu, hızlı başlangıç, düşük lojistik maliyet | İletişim disiplini, güvenli erişim (VPN, cihaz yönetimi) | Yazılım geliştirme, test, DevOps |
| Yerinde | Yüz yüze iletişim, fiziksel sistemlere erişim | Ulaşım, ofis kapasitesi, alt işverenlik değerlendirmesi | Donanım entegrasyonu, saha destek, kapalı ağlar |
| Hibrit | Kritik toplantılar yüz yüze, üretim uzaktan | Takvim ve kuralların net olması | Oryantasyon dönemi, atölye ve planlama günleri |
Yönetişim ve performans takibi
Hangi model seçilirse seçilsin, sağlıklı bir ilişki için düzenli bir yönetişim ritmi gerekir. Önerilen yapı; günlük kısa senkronizasyon, iki haftalık sprint planlama ve demo, aylık hizmet değerlendirmesi ve çeyreklik stratejik gözden geçirmedir. Staff augmentation’da bu ritim sizin ritminizdir; dedicated team ve proje bazlı modelde ise tedarikçinin raporlarıyla desteklenir.
| KPI | Staff augmentation | Dedicated team | Proje bazlı |
|---|---|---|---|
| Sprint hedefi tutarlılığı | İzlenir | Ana gösterge | Kilometre taşı bazında |
| Hata oranı / tekrar açılan kayıtlar | İzlenir | İzlenir | Kabul testinde |
| Lead time (talepten canlıya) | İzlenir | Ana gösterge | Genellikle izlenmez |
| Yerine kişi sağlama süresi | Ana gösterge | Ana gösterge | Geçerli değil |
| Bütçe sapması | Düşük önemde | İzlenir | Ana gösterge |
Sık yapılan yanlış anlamalar
- “Staff augmentation, işi tedarikçiye devretmektir.” Değildir. İş ve öncelikler sizde kalır; tedarikçi doğru kişiyi ve sürekliliği sağlar. Teknik liderliğiniz yoksa bu model tek başına sonuç üretmez.
- “Dedicated team daha pahalıdır, o yüzden kaçınılmalıdır.” Ekip bazlı bedel ilk bakışta yüksek görünebilir; ancak takım liderliği, test ve süreklilik dahil olduğunda karşılaştırma kişi başı ücret üzerinden değil, teslim edilen değer üzerinden yapılmalıdır.
- “Sabit fiyat her zaman daha güvenlidir.” Kapsam netse evet; kapsam belirsizse tahmin riski fiyata eklenir ve her değişiklik ayrı bir pazarlığa dönüşür.
- “Uzaktan çalışan ekip daha az güvenlidir.” Güvenlik, çalışma yerinden çok erişim yönetimine, cihaz politikalarına ve kayıt tutmaya bağlıdır. Yerinde çalışan ama ortak hesap kullanan bir ekip, iyi yönetilen uzak bir ekipten daha risklidir.
Sık sorulan sorular
Staff augmentation nedir?
Staff augmentation, ekibinize dışarıdan uzman kişiler ekleyerek kapasite veya yetkinlik açığını kapatma modelidir. Kişiler sizin yönetiminizde ve önceliklerinize göre çalışır; tedarikçi doğru kişiyi bulmaktan, idari süreçlerden ve süreklilikten sorumludur.
Staff augmentation ile dedicated team arasındaki fark nedir?
Staff augmentation’da kişiler sizin ekibinize katılır ve günlük yönetim sizdedir. Dedicated team’de size özel, kendi içinde organize bir ekip kurulur; günlük yönetim çoğunlukla tedarikçi tarafındaki takım lideri tarafından yapılır, ürün önceliklerini siz belirlersiniz.
Proje bazlı model ne zaman daha doğru seçimdir?
Kapsamı ve kabul kriterleri net, süresi belli bir işiniz varsa ve projeyi yönetecek iç teknik ekibiniz yoksa proje bazlı model uygundur. Kapsam belirsizse sabit fiyatlı proje sürtünme yaratabilir.
Staff augmentation ile ne kadar sürede başlayabilirim?
Rol tanımı net olduğunda aday taraması birkaç gün ile iki hafta arasında sürer; mülakat, sözleşme ve erişim hazırlıklarıyla birlikte tipik başlangıç birkaç hafta içinde gerçekleşir. Nadir uzmanlıklarda süre uzayabilir.
Dışarıdan gelen geliştiricinin performansı yetersizse ne olur?
Sözleşmede tanımlı değerlendirme ve değişim süreci işletilir. İyi kurgulanmış bir sözleşmede tedarikçi, belirlenen süre içinde yerine uygun bir aday sunmakla yükümlüdür.
Staff augmentation’da kod ve fikri mülkiyet kime aittir?
Sözleşmede aksi kararlaştırılmadıkça, hizmet kapsamında üretilen kodun ve dokümanların fikri mülkiyetinin müşteriye geçtiği açıkça yazılmalıdır. Kodun müşteriye ait depolarda tutulması da bu hakkı pratikte güvenceye alır.
Dedicated team’i ileride kendi bünyeme alabilir miyim?
Bu, sözleşmede baştan konuşulması gereken bir konudur. Bazı sözleşmelerde belirli bir süre sonra ekibin veya bilginin kademeli devri için koşullar tanımlanır. Hukuki ve ticari koşullar taraflar arasında açıkça düzenlenmelidir.
Staff augmentation geçici iş ilişkisi midir?
Hayır. Staff augmentation genellikle hizmet alımı sözleşmesiyle yürütülür ve çalışanlar tedarikçinin bordrosundadır. Geçici iş ilişkisi ayrı bir hukuki yapıdır ve İŞKUR izinli özel istihdam büroları aracılığıyla kurulabilir.
Üç modeli birlikte kullanmak mümkün mü?
Evet. Pek çok şirket çekirdek ekibini içeride tutar, belirli rolleri staff augmentation ile tamamlar, yeni bir ürün hattı için dedicated team kurar ve kapsamı net yan projeleri proje bazlı yaptırır. Önemli olan her işin doğru modele oturtulmasıdır.
Doğru modeli birlikte seçelim
İhtiyacınızı dinleyip staff augmentation, dedicated team veya proje bazlı modelden hangisinin size uygun olduğunu birlikte değerlendirebiliriz. Genel çerçeve için outsourcing nedir rehberimize göz atabilir; 360 Soft ekibine +90 850 335 10 87 numarasından, info@360-soft.com adresinden ya da iletişim sayfamızdan ulaşabilirsiniz.
