Uygulama Bakımı: Destek, İzleme ve Sürüm Yönetimi

Uygulama bakımı, her yıl özgün geliştirme bedelinin %15–25'i kadardır ve isteğe bağlı değildir. Bu rakam; güvenlik yamalarını, bağımlılık ve platform güncellemelerini, izlemeyi, olay müdahalesini ve küçük düzeltmeleri kapsar, tek bir yeni özellik eklenmeden önce. Bunu içermeyen bir bütçeyle çıkan ürün çalışır, sonra çürür; çünkü onu ayakta tutan işi finanse eden bir kalem yoktur.

Bu rehber bakımın gerçekte neleri kapsadığını, ne tuttuğunu, destek anlaşmasının nasıl kurulacağını ve düzenlemenin işe yarayıp yaramadığını hangi metriklerin söylediğini kapsar.

Önemli noktalar

• Yıllık olarak geliştirmenin %15–25'ini bütçeleyin: %10'un altında ürün çürür; %30'un üstünde yapısal bir sorun vardır.
• Bakım geliştirme değildir: Çalışır tutmak ile daha iyi hale getirmek ayrı bütçeler ve ayrı onaylardır.
• Önemli olan koşul yanıt süresidir: Kesinti gelir kaybettiriyorsa "elden geldiğince" bir destek modeli değildir.
• Platform tarihleri isteğe bağlı değildir: İşletim sistemi sürümleri ve mağaza gereksinimleri başkasının takvimiyle gelir.

Bakım gerçekte neleri kapsar

Uyarlayıcı iş, alıcıların beklemediği kategoridir. Mobil platformlar yılda bir sürüm çıkarır ve yeni gereksinimleri, hedef SDK sürümleri, gizlilik beyanları, hesap silme, sizin kontrol etmediğiniz tarihlerle zorunlu kılar. İki yıl dokunulmayan bir uygulama, kimse tek satır değiştirmemiş olsa bile dağıtılamaz hale gelir.

Maliyeti

Bu rakamlar barındırma ve üçüncü taraf servisleri içermez; onlar ayrıdır ve trafiğe göre yılda birkaç yüz dolardan birkaç bin dolara kadar değişir.

Yıllık olarak geliştirmenin %10'unun altında harcamak, "iki yıl gayet iyi çalıştı, şimdi hiçbir şey çalışmıyor" konuşmasını üreten örüntüdür. İş ortadan kalkmadı; birikti.

Anlaşmayı saat değil yanıt üzerine kurun

Yalnızca aylık saatle ölçülen bir anlaşma, saat tüketmeyi ödüllendirir. Yanıt ve çözüm taahhütleriyle ölçülen bir anlaşma, ürünü sağlıklı tutmayı ödüllendirir.

Önemi kimin sınıflandıracağını ve siz ile tedarikçi anlaşamadığınızda ne olacağını tanımlayın, o tartışma garantidir ve önceden çözmek kolaydır.

Kapsama saatlerini açıkça kararlaştırın. Ürününüz cumartesi işlem yapıyorsa mesai saatleri desteği sizi kapsamaz ve yoğun dönemler kendi maddesini hak eder.

Çalışır tutmayı iyileştirmekten ayırın

Bakım ile geliştirmeyi tek bir sözleşmede toplamak, birinin daima diğerini tüketmesi demektir ve bir şey bozulana kadar genellikle kazanan geliştirmedir.

Ayrı finanse edin: bakım sabit yıllık taahhüt olarak, geliştirme ise sürdürmeyi beklediğiniz bir ürün için yılda geliştirme bedelinin %10–20'si kadar değişiklik bütçesi olarak. Böylece güvenlik yaması bir özellik talebiyle yarışmaz ve gerçekten bir tercih gerektiğinde bu görünür olur.

Görebileceğiniz izleme isteyin

İzlemesiz bakım, kullanıcıların sorun bildirmesini beklemektir. En azından: çalışma süresi kontrolleri, hata oranı ve çökmesiz oturum oranı, önemli yolculuklarda performans ve harekete geçebilecek birine giden uyarılar.

Panolara erişiminiz olmalı. Yalnızca tedarikçinin ürünün sağlığını görebildiği bir destek düzeni, değer alıp almadığınızı değerlendirmeyi imkânsız kılar ve tedarikçi değiştirmeyi olması gerekenden zorlaştırır.

İş düzeyinde uyarılar da kurun: saatte sipariş, geçen ödeme, senkronlanan kayıt. Başarı yanıtı döndürürken hiçbir şey yazmayan bir sistem en çok zarar veren arızadır; çünkü her teknik pano sağlıklı olduğunu söyler.

Bağımlılıkları sürekli güncel tutun

Bağımlılıklar siz koda dokunmasanız da eskir. İki ana sürüm geride kalmış bir çatı, rutin bir güncellemeyi projeye çevirir ve yaygın bir kütüphanedeki bilinen bir açık, yayınlandığı gün sizin sorununuz olur.

Alarma tepki olarak değil takvimle güncelleyin. Küçük ve sık bağımlılık güncellemeleri olağan bakımdır; iki yıl ertelenmiş bir güncelleme bir göçtür ve öyle fiyatlanır.

Tedarikçi değiştirebilme yeteneğini koruyun

Bakım düzenlemeleri sessizce bağımlılık yaratır. Bunu bilinçli azaltın: sahibi olduğunuz bir depoda kod, adınıza açılmış hesaplarda altyapı, belgelenmiş dağıtım ve özgün geliştiriciyi gerektirmeyen bir çalıştırma kılavuzu.

İhtiyaç duymadan önce devrin neyi içereceğini sorun. Daha önce yapmış bir tedarikçi bir süreç anlatır; yapmamış olan soruyu güvensizlik sayar, ki bu da yanıtın kendisidir.

Yılda bir kanıta göre gözden geçirin

Yılda bir kez olay sayısına ve ciddiyetine, taahhütlere karşı yanıt sürelerine, sözleşmenin ne kadarının düzelticiye ne kadarının önleyiciye gittiğine ve küçük değişiklik teslim süresinin kararlı mı büyüyor mu olduğuna bakın.

Önleyici iş sabitken düzeltici işin artması, borcun biriktiğini ve düzenlemenin belirtileri tedavi ettiğini gösterir. Bu, sözleşmeyi olduğu gibi yenileme değil biçimini değiştirme anıdır.

İlgili rehberler

• Yap ya da satın al seçimini tartıyorsanız şunu okuyun: Özel Yazılım İçin İş Gerekçesi Nasıl Hazırlanır?.
• Bu, şu yazıdaki tartışmayla birlikte okunur: Dijital Dönüşüm İş Ortağı Nasıl Seçilir?.

Uygulama Bakımı: Destek, İzleme ve Sürüm Yönetimi bütçesi tanımlı, kapsamı belli bir projeye dönüştüğünde Yazılım Projenizi Konuşalım.