30 Günde Özel Bir Geliştirme Ekibini İşe Almak

Giriş

Çoğu dış kaynak kullanımı sözleşmesi ilk yıl değil, ilk ay içinde başarısız olur. Mühendisler niteliklidir ve ücretler makuldür, ancak ekip haftalarca erişim, bağlam veya net öncelikler olmadan çalışır. İşe başlandığında, müşteri bu modele olan güvenini çoktan yitirmiştir.

Müşteri hazırlıklarını yaptığında, özel bir geliştirme ekibi 30 gün içinde tam verimliliğe ulaşabilir. İşe alım ve istihdam süreçlerini tedarikçi yürütür, ancak ürünü, kod tabanını ve iş hedeflerini sadece müşteri açıklayabilir. İşe alım süreci ortak bir projedir ve bilgi aktarımının büyük kısmı müşteri tarafında gerçekleşir.

İlk Günden Önce: Neler Hazırlanmalı

Başlangıç tarihinden önceki hafta, ekibin ne kadar hızlı ilerleyeceğini belirler. Depoya erişim için üç gün bekleyen mühendisler ivmelerini kaybeder ve bu gecikme, tüm projenin gidişatını belirler.

Hazırlık, müşteri tarafında birkaç saatlik bir çalışma gerektirir. Bunun çoğu idari işlerden oluşur ve tek bir kişi tüm listeyi üstlenebilir.

• Erişim ve hesaplar. Kod deposu, görev takipçisi, bulut konsolu ve iletişim kanalları için hesaplar oluşturun. Başlangıç tarihinden önce her bir oturum açma işlemini test edin.
• Teknik belgeler. Mimari şemalarını, API açıklamalarını ve kurulum kılavuzlarını tek bir yerde toplayın. Değişiklikler belirtilmişse, güncel olmayan belgeler de kabul edilebilir.
• İrtibat kişisi. Müşteri tarafında, bir iş günü içinde soruları yanıtlayacak bir kişi atayın. Bu kişi genellikle teknik lider veya ürün sahibi olur.
• İlk iş yığını. Düşük ve orta karmaşıklıkta 10 ila 15 görev hazırlayın. Ekibin, üretim sürecini riske atmadan kod tabanını öğrenmesini sağlayacak işlere ihtiyacı vardır.

1. Hafta: Erişim, Bağlam ve İlk Görevler

İlk hafta oryantasyona ayrılır. Ekip, ürünün ne işe yaradığını, kimler tarafından kullanıldığını ve kodun nasıl organize edildiğini öğrenir.

Bu haftadaki çıktı, tasarım gereği azdır. Amaç, bir özellik sürümü değil, çalışır bir ortam ve ilk birleştirilmiş değişikliktir.

1–2. Günler: Ortam Kurulumu

İlk gün, müşteri bir başlangıç toplantısı düzenler. Ürün sahibi, iş modelini, ana kullanıcı gruplarını ve mevcut öncelikleri açıklar. Teknik lider, mimariyi ve dağıtım sürecini adım adım anlatır.

Görüşmenin ardından mühendisler yerel ortamları kurar ve uygulamayı çalıştırır. Kurulum sorunlarının çoğu bu aşamada ortaya çıkar; bu nedenle müşteri temsilcisi, hızlı yanıt verebilmek için hazır bulunmalıdır.

3–5. Günler: İlk Küçük Görevler

Her mühendis, ilk iş yığınından bir veya iki görev alır. Hata düzeltmeleri, küçük kullanıcı arayüzü değişiklikleri ve test kapsamı bu aşamada iyi sonuç verir. Gerçek kodla çalışırlar ancak risk düzeyi düşüktür.

Her görev, kod incelemesi, test ve dağıtımdan oluşan tam döngüden geçer. Bu, ekibe müşterinin nasıl çalıştığını gösterir ve süreçteki eksiklikleri erken aşamada ortaya çıkarır.

2. Hafta: Süreçler ve İletişim Ritimleri

İkinci haftada ekip, bireysel görevlerden ekip rutinlerine geçer. Müşteri ve tedarikçi, işin nasıl planlanacağı, tartışılacağı ve raporlanacağı konusunda anlaşır.

Dağınık ekipler, aynı yerde çalışan ekiplere göre daha fazla yapıya ihtiyaç duyar. Zaman dilimleri ve kültürel farklılıklar, gayri resmi iletişimi zorlaştırır; bu nedenle iletişim ritmi açıkça belirlenmelidir.

• Günlük standup toplantıları. Her iki zaman dilimini de kapsayan bir saatte kısa bir görüşme yapın. Durum ve engelleri görüşmek için on beş dakika yeterlidir.
• Sprint planlaması. Çalışmaları bir veya iki haftalık sprintler halinde planlayın. Öncelikleri müşteri ürün sahibi belirler, ekip ise iş yükünü tahmin eder.
• Kod inceleme kuralları. Kimin neyi ne kadar hızlı inceleyeceği konusunda anlaşın. Bir günden fazla süren inceleme gecikmesi tüm ekibi yavaşlatır.
• Yazılı güncellemeler. Paylaşılan kanalda haftalık kısa bir özet isteyin. Bu, paydaşlara ekstra toplantılar yapmadan durum hakkında bilgi sağlar.
• Eskalasyon yolu. Her iki tarafta engelleri kimin çözeceğini belirleyin. Satıcı hesap yöneticisi ekip sorunlarını, müşteri irtibat kişisi ise ürünle ilgili soruları ele alır.

3. ve 4. Haftalar: Sorumluluk ve Ölçüm

Son iki hafta, oryantasyon sürecinin işe yarayıp yaramadığını test eder. Ekip gerçek sorumluluk alır ve her iki taraf da sonuçları net kriterlere göre değerlendirir.

Bu aşama, sürecin hangi kısımlarında hala ayarlamaya ihtiyaç olduğunu da gösterir. Küçük sorunları 25. günde düzeltmek, 90. günde düzeltmekten daha kolaydır.

Gerçek Bir Özelliğin Devri

Üçüncü haftada, ekibe ürün yol haritasından eksiksiz bir özellik atayın. Bu özellik, tasarım kararları gerektirmeli, kod tabanının çeşitli kısımlarında çalışma gerektirmeli ve üretim sürümüne dahil edilmelidir.

Geliştirme başlamadan önce, müşterinin teknik lideri teknik yaklaşımı gözden geçirir. Bundan sonra, ekip, tahmin aşamasından dağıtım aşamasına kadar tüm süreci üstlenir. Bu aşamada sıkı denetim yapmak, sürecin amacına aykırıdır.

30. Günde İzlenecek Metrikler

Ayın sonunda, tedarikçi ile bir değerlendirme görüşmesi yapın. Sonuçları birinci haftada belirlenen beklentilerle karşılaştırın ve mümkün olduğunca sayısal veriler kullanın.

• Teslimat hızı. Son iki sprintte planlanan ve tamamlanan hikaye puanlarını karşılaştırın. Yüksek bir hızdan çok istikrarlı bir hız daha önemlidir.
• Kod kalitesi. İlk veya ikinci turda incelemeyi geçen çekme isteklerinin oranını kontrol edin. Sık sık yeniden çalışma yapılması, bağlamdaki eksikliklere işaret eder.
• Soru hacmi. Mühendislerin müşteriden ne sıklıkla yardım istediğini takip edin. Bu sayı her hafta azalmalıdır.
• Paydaş geri bildirimi. Ürün sahibinden ve teknik liderden kısa bir değerlendirme isteyin. Onların görüşleri genellikle metriklerin gözden kaçırdığı sorunları ortaya çıkarır.

Yaygın Onboarding Hataları

Onboarding gecikmelerinin çoğu, birkaç ortak nedene dayanır. Şirketler, her birinin başlangıçta önemsiz göründüğü için bu hataları tekrarlar.

• Geç erişim. Üçüncü günde gelen hesaplar, ekibe üç günlük bir kayba mal olur. Güvenlik onayları genellikle beklenenden daha uzun sürer, bu nedenle bu süreçleri erken başlatın.
• Ürün bağlamının olmaması. Kullanıcıları anlamayan mühendisler, teknik olarak doğru ancak yararsız kararlar alırlar. Bir saatlik ürün açıklaması, haftalarca sürecek yeniden çalışmayı önler.
• Çok fazla irtibat kişisi. Beş kişi talimat verdiğinde öncelikler çakışır. Tek bir karar verici, yönün net kalmasını sağlar.
• Ekibi dış bir unsur olarak görmek. Ayrı iletişim kanalları ve kısıtlı toplantılar, iki kademeli bir yapı oluşturur. Müşterinin rutinlerine katılan ekipler daha hızlı entegre olur.

Son Düşünceler

Özel bir ekibin tam verimliliğe ulaşması için 30 gün yeterlidir. Sonuç, tedarikçiden çok, müşterinin erişim, bağlam ve net öncelikleri ne kadar iyi hazırladığına bağlıdır.

Onboarding sürecini, sahipleri, son teslim tarihleri ve nihai bir değerlendirme aşaması olan bir proje olarak ele alın. Yapılandırılmış bir ilk ay, uzun soluklu bir işbirliği için gerekli olan güveni oluşturur.