Ürün ve teknik karar sahiplerini belirleyin
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.
Ürün kararı
Kapsam, öncelik ve kullanıcı görevinin kabul sahibini belirleyin.
Teknik onay
Kod incelemesi ve teknik risk kararının sorumlusu açık olsun.
Eskalasyon
Engel veya karar gecikmesi için gerçek alternatif iletişim yolu yazın.
Gerçek çalışma saatleri örtüşmesini kaydedin
Nearshore ekibin çalışma 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.
OKUMADAN SONRAKİ ADIMA
İlk teslimin çalışma anlaşmasını hazırlayın
Ürün hedefini, karar sahiplerini ve mevcut ortamları paylaşın. Türkiye ekibiyle başlangıcı küçük bir teslim ve açık sorumluluklar üzerinden planlayabiliriz.
Kod deposu ve ortam erişimlerini hazırlayın
Nearshore ekip erişimini hazırlarken 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.
İlk teslim diliminin kabul şartlarını yazın
Nearshore ekibin ilk iş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.
Görev
İlk dilim gerçek bir kullanıcı ihtiyacını sınırlı kapsamda karşılar.
İnceleme
Teknik gözden geçiren kişi değişikliği ve kanıtını değerlendirir.
Kabul
Ürün sahibi staging üzerinde yazılı şartları bağımsız olarak doğrular.
Karar, inceleme ve eskalasyon düzenini kurun
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.
Erişim devri ve ekip değişikliğini planlayın
Nearshore 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.
İlk teslimin çalışma anlaşmasını hazırlayın
E-posta ve telefon bu taleple ilgili iletişim içindir. Bülten aboneliği oluşturmaz.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Nearshore ekip için ülkede ofis gerekli mi?
Başlangıç kabulü karar sahipliği, erişim ve teslim düzeniyle değerlendirilir. Satın alma süreciniz belirli bir fiziksel varlık arıyorsa bunu ayrı doğrulayın. Kanıtlanmamış yerel ofis veya ekip varlığı varsayılmamalıdır.
Saat farkı yıl boyunca aynı kalır mı?
Böyle bir varsayım yapılmamalıdır. Müşterinin gerçek konumu, mevsimsel saat değişiklikleri ve tarafların mesai saatleri birlikte kontrol edilir. Takvimdeki yerel karşılıklar başlangıç anlaşmasına yazılır.
İlk iş olarak hangi teslim seçilmeli?
Gerçek bir kullanıcı görevini geliştirme, kod incelemesi ve staging kabulünden geçiren küçük bir dilim seçin. Bağımlılıkları açık olsun; ilk teslim tüm proje için garanti sayılmaz.
Kod deposunun sahibi kim olmalı?
İşletmenin sahipliği ve kalıcı yetkili erişimi doğrulanmalıdır. Ekip üyeleri görevlerine uygun izinle çalışır. Kişisel hesap veya dosya arşivi, açık devir düzeninin yerine geçmez.
Ekip üyesi ayrılırsa erişimler nasıl devredilir?
Açık işler ve kararlar yeni sorumluya aktarılır; eski erişimler envanter üzerinden kaldırılır. Yeni kişinin görevi yapabildiği ve ayrılan kişinin erişiminin kapandığı ayrıca doğrulanır.
KAPSAMI BİRLİKTE BELİRLEYELİM
İlk teslimin çalışma anlaşmasını hazırlayın
Ürün hedefini, karar sahiplerini ve mevcut ortamları paylaşın. Türkiye ekibiyle başlangıcı küçük bir teslim ve açık sorumluluklar üzerinden planlayabiliriz.
Nearshore ekip başlangıcını konuşun