Ekibi Çekmeden Yeni Ürün Nasıl Kurulur?

Bu düzen tek bir kararda ayakta kalır ya da çöker: yeni ürün, mühendislerinizi kritik yola koyuyor mu? Koyuyorsa, ilkine başlayamamış bir ekibe ikinci bir proje eklemişsinizdir. Koymuyorsa gerçekten kapasite yaratmışsınızdır.

Aşağıdaki her şey bu tek meselenin hizmetindedir. Ayrı depo, ayrı dağıtım, yazıyla anlaşılmış bir arayüz ve haftalarla değil saatlerle ölçülen bir inceleme ritmi.

Önemli noktalar

• Tasarımın tamamı ayrıştırmadır: Yeni ürün için kendi deposu, kendi dağıtımı, kendi nöbeti.
• Arayüz sözleşmesi koddan önce gelir: Neyi okuyabilir, neyi yazabilir, iki taraftan biri değişince ne olur.
• Mühendislerinizden bir gün ayırın, haftada bir gün değil: Daha fazlası gerekiyorsa kapsam yanlış çıkarılmıştır.
• Devri baştan planlayın: Bu istisna değil, beklenen sondur.

Adım 1: Kapsamı ekibinizi meşgul etmeden çıkarın

Çoğu keşif aşaması kıdemli mühendislerinizin takvimiyle yürür ki bu tam olarak eksik olduğunuz kaynağı harcar. Alternatifi, dış ekibin sistemi kendisine anlattırmak yerine kendisinin okumasıdır: veri modeli, mevcut entegrasyonlar, API yüzeyi, dağıtım kurulumu, son yaşanan arızalar.

Bunun sizden istediği şey okuma erişimi ve tek günlük soru-cevaptır. Sabit haftalık toplantı değil, atölye serisi değil. Dış bir ekip kapsam önerebilmek için bundan fazlasına ihtiyaç duyuyorsa, kendi öğrenmesini sizin darboğazınızla finanse etmenizi istiyordur.

Bunu Ar-Ge projesinin kapsamı ekibi meşgul etmeden nasıl çıkarılır yazısında ayrıntılandırdık.

Adım 2: Yeni ürüne kendi yüzeyini verin

Kendi deposu, kendi dağıtım hattı, kendi ortamları, kendi nöbet sırası. Bu bir tercih değil, ekibinizi koruyan mekanizmadır.

Yeni ürün sizin hattınızdan dağıtılıyorsa sürümlerinin sahibi ekibinizdir. Sizin altyapınızda çalışıyorsa bozulduğunda ekibiniz aranır. Sizin deponuzda yaşıyorsa kodunu ekibiniz inceler. Bunların her biri küçük ve makul duran bir ödündür ve satın aldığınız kapasiteyi geri verir.

Yeni ürün mevcut sisteminize tanımlı tek bir yoldan ulaşır, başka hiçbir yoldan değil.

Adım 3: Kod yazılmadan arayüz sözleşmesini yazın

İki sistemin birbirinden bağımsız gelişip gelişemeyeceğine karar veren belge budur. Şunları söylemelidir:

• Yeni ürün neyi okuyabilir ve nereden. Üretim tablolarına doğrudan erişim değil, salt okunur bir kopya ya da belgelenmiş bir API.
• Neyi yazabilir, yazabiliyorsa, ve bu yazımları neyin doğruladığı.
• Yeni ürünün asla yapmaması gerekenler. Genelde: şema değişikliği yok, çekirdek tablolara yazım yok, üretime uzun süren sorgu yok.
• Sizin tarafınız değiştiğinde ne olur. Ne kadar önceden haber verilir ve kim kime söyler.
• Onların tarafı çöktüğünde ne olur. Sizin sisteminiz bunu fark eder mi ve etmeli mi?

Bunu yazıyla anlaşmak birkaç saat alır ve sonradan ters giden şeylerin çoğunu önler. Başarısız olan sürüm, sınırın anlaşıldığı ama hiç yazılmadığı ve iki ekibin de onu farklı anladığının ortaya çıktığı sürümdür.

Adım 4: Pull request değil çalışan yazılım inceleyin

İki haftada bir, açıp kullanabileceğiniz bir şey. Yüzde değil, renkli durum göstergesi değil, kod incelemesi değil.

Maliyeti düşük tutan takas budur. Ayrıntılı gözetimi düzenli kanıtla değiştiriyorsunuz ve bu yalnızca kanıt gerçekse işler: bir kurulum, bir bağlantı, bir test hesabı. İki hafta geçip kullanılabilir bir şey çıkmadıysa sebebini sorma sinyali budur ve herhangi bir rapordan çok daha iyi bir sinyaldir.

Mühendisleriniz bu incelemelere katılmaz. Mesele zaten katılmak zorunda olmamalarıdır.

Adım 5: Sonu baştan kararlaştırın

Devir, ümit edilen bir şey değil, tarihi olan planlı bir iştir. Üç sondan hangisini hedeflediğinizi başta belirleyin: ekibiniz devralır, dış ekip işletmeye devam eder ya da ürün ileride mevcut sisteme katılır.

Her biri yapım sırasında farklı tercihler gerektirir. Ekibinizin devralacağı bir ürün sizin teknoloji yığınınızda, sizin kurallarınızla ve onu devralacak mühendis için belgelenmiş olarak yazılmalıdır. Dışarıda kalacak olan farklı tercihler yapabilir. Bunu geç kararlaştırmak, ekiplerin sürdüremeyecekleri bir şeyi devralmasının yoludur. Ayrıntısını yeni ürünün sahibi kim olur yazısında ele aldık.

Ekibinize gerçekçi maliyeti

Başta bir günlük soru-cevap. Arayüz sorularına karar verebilecek, bir gün içinde ulaşılabilen bir muhatap; ayda birkaç saat. İki haftada bir, kurulanı görmek için yarım saat. İlgili sistemlere okuma erişimi.

Taahhüdün tamamı budur. İlk aydan sonra bundan yükseğe çıkıyorsa düzende bir şey ters gidiyordur ve bunu içine çekmek yerine erkenden adını koymak gerekir.