Nearshore Ekip Başlatma Kontrol Listesi

Türkiye’den nearshore yazılım geliştirme için başlangıçta ürün kararını veren kişiyle teknik onayı veren kişiyi adlandırın. Gereksinimi kim netleştirir, kapsam değişikliğini kim kabul eder, teslimi kim inceler? Bu roller aynı kişide bulunabilir; önemli olan bir talebin hangi karar yolu üzerinden ilerleyeceğinin ekip tarafından anlaşılmasıdır.

Öncelik veren kişi ile işi kabul eden kişi farklıysa aralarındaki bağlantıyı açıklayın. Geliştirici bir özelliği teknik olarak tamamlayabilir, fakat ürün sahibinin beklediği görev hâlâ çalışmıyor olabilir. Kabul şartlarının kimin tarafından hazırlanıp doğrulanacağını yazın. Belirsiz taleplerde soru sorulacak kişiyi belirlemek, ekipteki herkesin ayrı bir beklentiyle hareket etmesini önler.

Başlangıç anlaşmasına ürün sahibi, teknik gözden geçiren, ortam sorumlusu ve eskalasyon kişisi alanlarını koyun. Adların yanında her rolün verebileceği karar bulunsun. Bir kişinin bulunmadığı durumda işleyecek alternatif yolu belirleyin; bütün kararları tek kişiye bağlayan bir düzeni görünmez bırakmayın. Dosya, kadro sayısını göstermekten çok teslim sorumluluğunu açıklamalıdır.

Nearshore ekiple çalışma düzeninde mesai saatlerini müşterinin ve ekibin gerçek konumlarına göre karşılaştırın. Şehir veya ülke adı tek başına ortak mesaiyi belirlemez; tarafların işe başladığı ve bitirdiği saatler de gerekir. Saat dilimi kimliklerini ve toplantı için kullanılacak takvim yorumunu kaydedin. Planlanan örtüşme ile herkesin fiilen ulaşılabilir olduğu aralığı ayırın.

Müşterinin bulunduğu yerde mevsimsel saat değişikliği varsa sonraki değişim dönemindeki toplantıyı da takvimde kontrol edin. Yıl boyunca sabit evrensel saat farkı sözü vermeyin. Aynı toplantının iki tarafta hangi yerel saate denk geldiğini görün. Tatil, izin ve kurumun kapalı günleri için bildirim yöntemi belirleyin; bu koşullar günlük iletişim düzenini etkileyebilir.

Ortak saat aralığını hangi iş için kullanacağınızı açıklayın: kısa karar görüşmesi, tasarım sorusu veya teslim incelemesi gibi. Örtüşme dışındaki işlerde teslim dili, yazılı güncelleme yeri ve beklenen yanıt düzeni kararlaştırılsın. Destek saatlerini geliştirme mesaisinden ayrı yazın. Bir ekibin aynı saat diliminde bulunması, kendiliğinden sürekli destek ya da anında yanıt anlamına gelmez.

Erişim hazırlığını CTO teknik değerlendirme kontrol listesiyle düzenleyin. Kod deposu, iş takibi, tasarım kaynakları ve test ortamı için işletmeye ait hesapları belirleyin. Kişisel hesap üzerinden paylaşılmış bir arşiv, kalıcı erişim ve sahiplik düzeni sağlamayabilir. Ekip üyesine yapacağı görev için gereken erişimi verin. Ortam erişimi hazırlanmadan özellik teslimini beklemek, ilerlemeyen işi yanlış biçimde performans sorunu gibi gösterebilir.

Geliştirme, staging ve üretim ortamlarının izinlerini ayrı tutun. İlk teslim için hangi bağlantıların gerekli olduğunu yazın; çalışma dosyasına parola veya gizli anahtar koymayın. Testte kullanılan verinin paylaşım kapsamını belirleyin. Yeni üyenin projeyi açabildiği, gerekli bağımlılıklara ulaşabildiği ve kontrollü test çalıştırabildiği gözlensin; yalnızca davetin gönderilmesini hazırlık tamamlandı diye saymayın.

Mimari başlangıç notunda uygulamanın ana akışı, ilgili bileşenler, bilinen kısıtlar ve kararların tutulduğu yer olsun. Bütün şirket geçmişini aktarmak yerine ilk görevi anlamaya yetecek kaynakları seçin. Erişim eksikse engeli ve çözüm sahibini kaydedin. Teknik doküman bulunmaması gerektiğinde sorulacak kişiyi de görünür kılın; ekipten iş kuralını tahmin etmesini beklemeyin.

CI/CD ve DevOps sürecini doğrulayan ilk iş, kullanıcı açısından anlamı olan küçük bir teslim dilimi olsun. Yalnızca ortam kurmak teslim zincirinin tamamını göstermez; çok geniş bir özellik de başlangıçtaki engeli saklayabilir. Bir görevin geliştirilmesi, incelenmesi ve staging ortamında kabul edilmesi görülebilsin. Gerçek ihtiyaçla bağlantılı bir dilim seçin ve kapsam dışındaki işleri başlangıçta belirtin.

Kabul şartına kullanıcının görevi, örnek girdisi, beklenen sonuç, hata durumu ve inceleme sahibini ekleyin. “Çalışıyor” demek yeterli ayrıntı değildir. Tasarım veya içerik bekleyen kısım varsa bunu bağımlılık olarak yazın. Ekip teslim ederken ilgili test ve gözlem kanıtını sunsun; ürün sahibinin aynı görevi bağımsız olarak deneyebileceği bir staging yolu bulunmalıdır.

Kod incelemesi ve ürün kabulünü ayrı kararlar olarak takip edin. İnceleme bekleyen değişiklik kullanıcı görevini tamamlamış görünse de teslim sürecinde henüz açık olabilir. Sorun bulunursa düzeltmenin kimde olduğunu ve hangi kabul maddesinin yeniden denenmesi gerektiğini belirtin. İlk teslimdeki gözlem, sonraki işlerin başlangıç düzenini düzeltmek için kullanılsın; genel başarı garantisine çevrilmesin.

Nearshore ekip koordinasyonunda günlük iletişim için aynı bilgileri tekrar tekrar anlatmak yerine ortak bir ilerleme kaydı kullanın. Tamamlanan iş, sıradaki adım, engel ve gereken karar açık olsun. Toplantının amacı yazılı kayıtta çözülemeyen konuları ele almak olabilir. Teslim dili ile toplantı dilinin farklı olması halinde önemli kararın herkesçe anlaşılır kaydı ayrıca hazırlanmalıdır.

Karar günlüğünde konu, seçenek, gerekçe, karar sahibi ve etkilenen teslim bulunmalıdır. Mesajlaşmada verilen bir karar daha sonra bulunamıyorsa ekip eski varsayımla çalışabilir. Kapsam değişikliğini iş kaydına bağlayın. Yazılı kararın son sürümünü herkesin görebildiğini doğrulayın; teknik uygulamanın ürün kararına nasıl bağlandığı inceleme sırasında anlaşılabilmelidir.

Engel yükseltme düzenini kararın etkisine göre kurun. Erişim engeli, ürün sorusu ve canlı sistem olayı aynı kişiye ya da aynı kanala gitmeyebilir. Destek ve geliştirme sorumlularını, kabul edilmiş çalışma saatleriyle birlikte yazın. Beklenmeyen durumda yapılacak ilk temas belli olsun. Onaylanmamış çözüm süresi veya ülkeye özgü hizmet vaadi eklemeden operasyonu gerçek yetkilerle tanımlayın.

Dış kaynak CTO ile çalışan ekipte bir üye değiştiğinde devam eden görev, açık karar, ortam notu ve gerekli erişim yeni sorumluya devredilsin. Devir yalnızca dosya göndermek değildir; yeni kişi açık işi anlayıp test edebilmelidir. İşletme hesabında tutulan kaynaklar bu sürekliliği kolaylaştırır. Tek kişiye ait bilgi ve kişisel hesap bağımlılıklarını başlangıçta görünür yapın, ayrılış anına bırakmayın.

Ayrılan kişinin erişimlerini depo, ortam, iş takibi ve dış hizmet envanterinden takip ederek kaldırın. Paylaşılmış erişim bilgisi varsa işletmenin yetkili süreciyle ele alınmalıdır. Dosyaya gizli değerleri yazmadan hangi hesap veya yetkinin değişmesi gerektiğini kaydedin. Devir alan kişinin gerekli görevi tamamlayabildiği ve ayrılan kişinin artık erişemediği kontrollü gözlemle doğrulansın.

Başlangıç anlaşmasını sahipler, çalışma örtüşmesi, erişim envanteri, ilk dilim kabulü, karar günlüğü, destek düzeni ve devir koşullarıyla tamamlayın. Kanıtlanmış yerel ofis veya önceki ülke deneyimi yoksa varmış gibi açıklama eklemeyin. Satın alma için ek bir gereklilik varsa ayrıca doğrulatın. İlk teslimden öğrenilen koşulları anlaşmaya işleyin ve ekip düzeni değiştiğinde ilgili maddeleri yeniden inceleyin.

Çalışma belgesini isteyin

Bilgileriniz yalnızca bu belge talebini işlemek için kullanılır. Bülten aboneliği oluşturmaz.

Belgeyi istemek için daha sonra tekrar kontrol edin.