Bu yazıda (8)
Bu projeler tek seferlik geçişte ölür
Plan slaytta gayet temiz görünür. Yeni sistemi bir yıl boyunca geliştir, bir hafta sonu seç, herkesi taşı, eskisini kapat. Gerçekte ise canlıya geçiş hafta sonu kimsenin belgelemediği bir düzine davranışı ortaya çıkarır, ekip bir haftalık iş kaybeder ve biri tek bir departman için eski sistemi geçici olarak yeniden açar. Eski bir sistemi işi durdurmadan değiştirmek, her şeyin yeni sistemin kusursuz çalışmasına bağlı olduğu bir anı hiç yaşamamak demektir. Bunu da her biri siparişleri, faturaları ya da müşterileri peşinden sürüklemeden başarısız olabilecek kadar küçük parçalarla ilerleyerek başarırsınız.
Önce eski sistemin gerçekte ne yaptığını öğrenin
Belgeler, varsa, sistemin on beş yıl önce ne yapmak için kurulduğunu anlatır. Değer ise bugün ne yaptığında. Onu her gün kullananların yanına oturun ve çalışmalarını izleyin. Hiçbir şartnamede yer almayan kurallar bulacaksınız: kod belirli bir harfle başlayınca devreye giren indirim, muhasebenin her salı aldığı rapor, birinin yıllar önce bambaşka bir şeyi takip etmek için kullanmaya başladığı alan. Bunları kaçırırsanız yeni sisteminiz teknik olarak doğru, operasyonel olarak işe yaramaz olur. Bu kısım yavaş ilerler ve projenin kaderini o belirler.
Sistemi dilim dilim değiştirin
Yeni sistemi eskisinin yanına kurun ve trafiğin dar bir kısmını ona yönlendirin. Tek bir rapor. Tek bir müşteri tipi. Tek bir departman. Geri kalan her şey eski sisteme eskisi gibi gitmeye devam eder. O dilim birkaç hafta sorunsuz çalışınca sıradakini alın. Eski sistem, geri kalanı törensiz kapatılabilecek kadar küçülene dek daralır. Bu yöntem kâğıt üzerinde tek seferlik geçişten uzun sürer, pratikte ise daha erken biter. Çünkü sürprizleri henüz ucuzken bulursunuz.
Asıl proje veri taşıma
Ekipler yeni özelliklere bütçe ayırır, veriyi de sona kalan bir iş gibi görür. Sonra aynı müşterinin üç farklı yazımla dört kez kaydedildiğini, tarihlerin iki ayrı formatta tutulduğunu, zorunlu alanların hiç doldurulmadığını ve on yıllık kayıtların kimsenin açıklayamadığı kodlara dayandığını keşfederler. Verinin bir kopyasını erkenden taşıyın, yeni sistemden geçirin ve neyin bozulduğuna bakın. Bunu birkaç haftada bir tekrarlayın. Canlıya geçişten önceki son taşıma, yaptığınız ilk değil yirminci taşıma olmalı.
Gücünüz yettiği sürece iki sistemi birlikte çalıştırın
Bir süre boyunca hem eski hem yeni sistem canlı veri tutar. Bu rahatsız edicidir ama alternatifinden daha güvenlidir. Her bilgi için hangi sistemin esas kaynak olduğunu net biçimde belirleyin ve iki sistemin aynı kayıtlara birlikte yazmasına izin vermek yerine tek yönlü bir senkronizasyon kurun. Eski sistemi kapatacağınız tarihi belirleyin ve ona sadık kalın. Bitiş tarihi olmayan paralel dönem kalıcı hale gelir. O noktada iki sistemin bakımına para öder, ikisini sonsuza dek elle eşleştirmeye çalışırsınız.
İnsanlar yazılımdan daha zor
Ekibiniz eski sistemi yıllar içinde öğrendi ve her köşesine kendi kısayollarını kurdu. Yeni bir sistem, daha iyisi bile olsa, birkaç hafta boyunca herkesi yavaşlatır ve direnç tam orada başlar. En yoğun kullanıcıları erkenden sürece katın, her gün dokundukları kısımları onlar şekillendirsin. Onlara yalnızca yönetimin istediğini değil, kendilerinin gerçekten istediği bir şeyi verin. Eğitimi demo verisiyle değil, kendi gerçek işleri üzerinden yapın. Kendi dilimini tasarlamaya katkı veren departman onu savunur. Dilim tepeden inen departman ise eski sistemi kullanmaya devam etmek için bahane bulur.
Neyi değiştirmediğinizi de netleştirin
Eski olan her şey yeniden yapılmaya değmez. Bazı eski sistemler tek bir işi güvenilir biçimde yapar ve ayakta tutması ucuzdur. Değiştirmenin gerekçesi şu durumlarda güçlüdür: sistem işin yapması gereken bir şeyi engelliyorsa, onu güvenle değiştirebilecek kimse kalmadıysa, başka hiçbir şeye bağlanamıyorsa ya da erişemediğiniz veriler tutuyorsa. Asıl şikâyet eski görünmesiyse gerekçe zayıftır. Başlamadan önce bunlardan hangisinin geçerli olduğunu yazın. Bu, yeni sistemin neyi kanıtlaması gerektiğini de size söyler.
Her şeye bağlanmadan nasıl başlanır
Gerçek değeri olan en küçük dilimi seçin ve canlıya alın. Şirket içinde tartışma konusu olan tek bir rapor, haftada saatlere mal olan tek bir iş akışı ya da şu an bir kişinin iki ekran arasında kopyala-yapıştırla yürüttüğü tek bir entegrasyon. Böylece yeni sistemin çalışan bir parçası canlıya çıkar, ekibiniz süreci bir kez yaşamış olur ve geri kalanının neler gerektireceğine dair kanıt elde edersiniz. Bu kanıt, tek satır kod yazılmadan önce yapılan her tahminden daha değerlidir.
Yazan
Idennex
Stratejiyle başlayan ajans, İstanbul