Yazılım 'Bitti' Dedikten Sonra Ne Oluyor? Aylık Bakım Anlaşmasının Gerçek Maliyeti

Proje teslim edildi, fatura kesildi, ekip elini eteğini çekti — sonra üç ay sonra normalde önemsiz sayılacak bir tarayıcı güncellemesi geldi ve müşteri kayıt formu sessizce bozuldu. Kimse koda dokunmamıştı; değişen kod değil, kodun etrafındaki dünyaydı. Yazılım 'bitti' dendiği andan sonra da hâlâ bir maliyeti var, ve bunu önceden konuşmayan kurucular bu maliyeti genellikle en kötü zamanda, bir arıza anında öğreniyor. Aylık bakım anlaşması tam olarak bu maliyeti önceden fiyatlandırmak için var — ama içeriği çoğu zaman muğlak kalıyor: gerçekte ne kapsıyor, ne kapsamıyor ve makul bir fiyat ne kadar?

##'Bitti' Aslında Ne Demek? Yazılımın Teslimattan Sonra Neden Hâlâ Maliyeti Var

Bir yazılım teslim edildiğinde kod donmuş gibi görünür ama çalıştığı ortam donmaz. Kullandığı kütüphanelerde her ay güvenlik açıkları bulunup yamalanıyor; tarayıcılar ve işletim sistemleri sessizce güncelleniyor ve bazı eski API'leri artık desteklemiyor; ödeme sağlayıcı, harita servisi veya SMS API'si gibi üçüncü taraf entegrasyonlar kendi sürümlerini değiştirip eskisini bir tarih vererek kapatıyor; sunucu çalışma zamanının (Node, PHP, Python) eski bir sürümü belli bir tarihte destekten çıkıyor; SSL sertifikası yenilenmezse site tarayıcıda 'güvensiz' uyarısı almaya başlıyor. Bunların hiçbiri 'bug' değil — kodun kendisi hâlâ doğru. Ama etrafındaki dünya değiştiği için, dokunulmayan bir yazılım zamanla sessizce kırılmaya başlıyor. Buna ek olarak gerçek kullanıcılar sisteme girdikçe geliştirme sırasında görülmeyen kenar durumlar (edge case) ortaya çıkıyor — belirli bir tarayıcıda bozulan bir form, belirli bir veri kombinasyonunda patlayan bir hesaplama.

##Bakım Anlaşması Aslında Neyi Kapsar?

• ▸Güvenlik yamaları ve bağımlılık/kütüphane güncellemeleri
• ▸Sunucu, hosting ve uptime izleme
• ▸Üretimde ortaya çıkan hataların (bug) düzeltilmesi
• ▸Üçüncü taraf API sürüm değişikliklerine uyum (ödeme, harita, SMS, e-posta servisleri)
• ▸Düzenli yedekleme ve felaket kurtarma testi
• ▸Küçük içerik/metin/ayar değişiklikleri
• ▸Belirlenmiş bir yanıt süresi (SLA) içinde destek

Buradaki kritik ayrım şu: bakım, var olan sistemi çalışır ve güvenli tutmakla ilgilidir — yeni özellik geliştirme değildir. İyi hazırlanmış bir bakım anlaşması bunu açıkça yazar: 'yeni bir sayfa, yeni bir entegrasyon veya büyük bir tasarım değişikliği kapsam dışıdır, ayrı teklif olarak fiyatlandırılır.' Bu ayrım net değilse, tartışma her zaman 'bu küçük değişiklik bakıma mı giriyor yoksa yeni özellik mi' sorusunda çıkıyor — bu yüzden anlaşmanın başında somut örneklerle sınırı çizmek, ilerideki her anlaşmazlığı baştan önlüyor.

##Gerçek Bir Senaryo: Küçük Bir Randevu Uygulaması

Bir güzellik salonu sahibi sekiz ay önce randevu ve ön ödeme alan küçük bir web uygulaması yaptırdı. Teslimattan sonra bakım anlaşması yapmadı — 'bir şey bozulursa ararım' dedi. Altıncı ayda ödeme sağlayıcı, kullandıkları eski API sürümünü kapatma tarihini geliştiricinin artık kullanılmayan proje e-postasına gönderdi; kimse okumadı. Kapanma tarihi geldiğinde randevu sayfası açılıyor ama ödeme adımında sessizce hata veriyor — müşteriler randevu alamadan sayfadan ayrılıyor, salon sahibi durumu ancak üç gün sonra düşen randevu sayısından fark ediyor.

Bakım anlaşması olsaydı senaryo şöyle işlerdi: ödeme sağlayıcının kapanma bildirimi geliştiricinin izlediği hesaba düşer, aylık rutin kontrolde 'bu değişiklik bizi etkiliyor mu' diye test edilir, kapanma tarihinden haftalar önce sessizce güncellenir ve salon sahibi olayın farkına bile varmaz. Acil durumda yapılan onarım — bağlamı unutulmuş bir kod tabanını yeniden çözmek, üç gün içinde bulup düzeltmek, o üç günde kaybedilen randevu gelirini saymadan — sekiz aylık bir bakım anlaşmasının toplam bedelinden daha pahalıya geldi. Bu, bakımın 'ekstra masraf' değil, öngörülebilir bir maliyeti öngörülemez bir krize çevirmemenin bedeli olduğunu gösteren tipik bir örnek.

##Bakım Anlaşması Ne Kadar Tutar?

Bu aralıklar geniş çünkü fiyatı belirleyen asıl şey uygulamanın büyüklüğü değil, taşıdığı risk ve beklenen yanıt hızı. Bir günlük yanıt süresiyle 'ayda birkaç saatlik paket' fiyatı ile 'dört saat içinde geri dönüş' garantisi veren bir SLA aynı fiyata gelmez. Hosting/sunucu maliyeti genelde bakım ücretine dahil değildir, ayrı faturalanır — bakım anlaşması geliştiricinin zamanını ve dikkatini kapsar, altyapı maliyetini değil. Bazı geliştiriciler sabit aylık ücret yerine 'paket saat' modeli sunar: ayda örneğin 4 saatlik bakım havuzu, kullanılmayan saatler bir sonraki aya kısmen devreder ya da yanar — bu, düzenli değişen bir sistem için sabit ücretten daha esnek olabilir.

##Bakım Anlaşması Olmadan Ne Kayar?

En görünür kayıp acil onarım maliyeti değil — asıl kayıp sessizce birikendir. Yamalanmayan güvenlik açıkları zamanla üst üste biner ve bir gün ciddi bir saldırı yüzeyine dönüşür. Küçük performans sorunları düzeltilmeden bırakıldıkça uygulama ay be ay biraz daha yavaşlar, kimse fark etmez ta ki kullanıcılar şikayet edene kadar. Ve bir şey bozulduğunda, 'bekleyen' bir geliştirici olmadığı için ya proje kuyruğunda bekliyorsunuz ya da acil/rush ücretiyle — planlı bakımın kat kat üzerinde bir saatlik ücretle — birini bulmaya çalışıyorsunuz; üstelik o kişi kod tabanına sıfırdan bakıp bağlamı yeniden çözmek zorunda kalıyor, bu da onarım süresini uzatıyor.

Bu birikim genelde doğrusal değil, katlanarak büyür. Güncellenmeyen bir kütüphane bir yıl sonra o kadar eski bir sürüme saplanır ki artık tek başına güncellenemez — önce onu kullanan başka üç bağımlılığın da güncellenmesi gerekir, bazen de o üç bağımlılık birbirleriyle uyumsuz hale gelmiştir. Böyle bir tıkanıklığı açmak, düzenli aralıklarla tek tek yapılan küçük güncellemelerin toplamından çok daha fazla saat alır — pratikte üç-dört katı bir mesai anlamına gelebilir. Bakımın değeri tam da burada ortaya çıkıyor: küçük şeyleri küçükken halletmek.

##Her Yazılımın Bakım Anlaşmasına İhtiyacı Var mı?

Hayır — ve bunu söylemek geliştiricinin çıkarına aykırı görünse de dürüst cevap bu. İki-üç kişinin kullandığı, gelirle doğrudan bağlantısı olmayan, bozulsa bir günlüğüne rahatsız edici ama kriz olmayan bir iç araç için düzenli bir bakım anlaşması genelde gereksiz — ihtiyaç oldukça saatlik destek almak yeterli. Ama müşteriyle doğrudan etkileşen, ödeme alan, gelire bağlı veya markanın yüzü olan bir üretim sistemi için bakım anlaşması bir lüks değil, işin sürekliliğinin bir parçası. Ayırt edici soru şu: 'bu sistem bir gün bozulsa, kaç saat içinde bunu fark eder ve düzeltirim, ve o sürede ne kaybederim?' Cevap 'saatler içinde ciddi kayıp' ise, bakım anlaşması kendini hızla amorti ediyor.

##Bakım Anlaşması Seçerken Nelere Dikkat Etmeli

• ▸Yanıt süresi (SLA) sözleşmede somut bir sayı olarak mı yazılı, yoksa 'mümkün olan en kısa sürede' gibi belirsiz bir ifade mi
• ▸Kapsam dışı sayılan işler — yeni özellik, büyük tasarım değişikliği — somut örneklerle tanımlanmış mı
• ▸Düzenli bir rapor var mı: hangi güncellemeler yapıldı, hangi saatler nerede harcandı
• ▸İptal koşulları ve bildirim süresi net mi, yoksa uzun vadeli kilitli bir sözleşme mi
• ▸Kod, sunucu erişimi ve dokümantasyon sizin adınıza mı kayıtlı, yoksa yalnızca geliştiriciye mi kilitli

Son madde küçümsenmemeli: domain, hosting hesabı ve kaynak kod deposu her zaman sizin adınıza kayıtlı olmalı, geliştiricinin kişisel hesabı altında değil. Aksi halde geliştiriciyle yollarınız ayrıldığında yazılımınız fiilen rehin kalır — yeni birine devretmek, erişimleri sıfırdan kurmakla uğraşmaktan çok daha pahalıya ve yavaşa gelir. İyi bir bakım anlaşması bu maddeyi baştan netleştirir; netleştirmiyorsa bunu sormak sizin sorumluluğunuzdadır. Aynı şekilde 'düzenli rapor' maddesi de önemlidir — hangi ay ne yapıldığını görmeden ödediğiniz ücretin karşılığını değerlendirmeniz zorlaşır.

##Sık Sorulan Sorular

>Bakım anlaşması olmadan yazılımımı kullanmaya devam edebilir miyim?

Evet, teknik olarak hiçbir şey sizi zorlamaz. Ama risk zamanla katlanarak birikir: her ay yamalanmayan bir güvenlik açığı, artık desteklenmeyen bir kütüphane, kapanma tarihi geçmiş bir üçüncü taraf entegrasyonu üst üste eklenir. Bir yıl sonra 'küçük bir güncelleme' yerine köklü, pahalı bir yeniden çalışmayla karşılaşma ihtimali önemli ölçüde artar.

>Bakım ücretine hosting/sunucu maliyeti dahil mi?

Genellikle hayır. Bakım anlaşması geliştiricinin izleme, güncelleme ve destek zamanını kapsar; sunucu, veritabanı, domain ve üçüncü taraf servis ücretleri (ödeme sağlayıcı komisyonu gibi) ayrı ve doğrudan sizin adınıza faturalanır. Bazı geliştiriciler ikisini tek bir paket fiyatında birleştirir ama bu istisnadır, kuraldan çok tercih meselesidir — anlaşmaya girmeden önce bunu netleştirmek gerekir.

>Bakım anlaşmasını istediğim zaman iptal edebilir miyim?

Çoğu bakım anlaşması ay bazlı çalışır ve bir sonraki ay için önceden haber vererek iptal edilebilir — uzun vadeli kilitli sözleşme genelde tercih edilmez, çünkü hem geliştirici hem müşteri için esneklik daha sağlıklı bir ilişki kurar. İptal ettiğinizde yazılım çalışmaya devam eder, sadece düzenli izleme ve öncelikli destek sona erer; gelecekte ihtiyaç olursa tek seferlik saatlik destek genelde hâlâ mümkündür.

>Orijinal geliştiricim yoksa başka biri bakımı üstlenebilir mi?

Evet ama bir devir (onboarding) süresi gerekir ve bu sürenin uzunluğu kod tabanının okunabilirliğine, dokümantasyon kalitesine ve kullanılan teknolojilerin ne kadar standart olduğuna bağlıdır. İyi belgelenmiş, yaygın bir teknoloji yığınıyla yazılmış bir sistem için bu birkaç saat sürebilir; özel, az belgelenmiş bir sistem için devir başlı başına ücretli bir keşif çalışmasına dönüşebilir. Bu yüzden ilk geliştiriciden temiz teslim (kod, erişimler, kısa bir mimari not) almak, ileride kimin bakımı üstleneceğinden bağımsız olarak değerlidir.

>Bakım anlaşmasını yıllık peşin mi, aylık mı ödemeliyim?

İkisi de yaygın. Yıllık peşin ödeme genelde bir miktar indirim getirir ve geliştirici için de öngörülebilirlik sağlar. Ama ilk kez birlikte çalıştığınız bir geliştiriciyle henüz ilişki test edilmemişken yıllık taahhüde girmek riskli olabilir; ilk birkaç ayı aylık ödemeyle geçirip iletişimin, raporlamanın ve yanıt hızının beklediğiniz gibi işleyip işlemediğini görmek, sonra isterseniz yıllığa geçmek daha güvenli bir yol.

Bakım anlaşması aslında bir sigorta gibi çalışır: her ay küçük, öngörülebilir bir bedel ödersiniz ki büyük, öngörülemeyen bir kriz anında kör yakalanmayasınız. Fiyatlandırma modelini netleştirmek istersen fiyatlandırma yaklaşımımı anlattığım yazıya göz atabilir ya da doğrudan projenle ilgili birkaç soruyla başlayabiliriz.