Birçok KOBİ sahibi, bir web projesinin teslimatından sonra bir bakım sözleşmesi imzalar. Fikir mantıklıdır: platformun çalışmaya devam etmesini, güvenli kalmasını ve karşılaşılan ilk tarayıcı güncellemesinde veya güvenlik açığında durmamasını istersiniz. Pratikte böyle bir sözleşme genellikle karşılığında şaşırtıcı derecede az şey sunan aylık bir fatura olur. Otomatik olarak bir güncelleme çalıştırılır ve bunun dışında hiçbir şey duymazsınız.

Bozuk bir iletişim formu veya aksayan bir ödeme süreci gibi gerçekten bir şeyler ters gittiğinde, sözleşmenin çok az garanti sunduğu ortaya çıkar. Geliştirici ancak iki gün sonra yanıt verir veya bir güncelleme nedeniyle oluşan bir hatayı düzeltmek için yüksek ücretler talep eder. Bu yalnızca zaman ve hayal kırıklığına değil, doğrudan ciroya da mal olur.

İyi bir bakım sözleşmesi idari bir zorunluluk değil, dijital platformunuzun sürekliliğine ve getirisine yönelik bir sigortadır. İster React ve Supabase'de özel bir platformla ister daha geleneksel bir sistemle çalışın, anlaşmaların net ve sonuç odaklı olması gerekir. Aşağıda, bakım sözleşmelerinde sıkça yapılan beş hatayı ve bunları somut olarak nasıl çözeceğinizi ele alıyoruz.

Hata 1: Kurtarma ve güvenlik kontrolü olmadan güncellemeler

Birçok sözleşme aylık bakım vaat eder, ancak pratikte bu, güncelleme düğmelerine amaçsızca tıklamaktan ibarettir. Koddaki bir çakışma nedeniyle bir şey bozulduğunda, bir müşteri şikâyet edene kadar kimse fark etmez. Üstelik yedeklemeler genellikle otomatik olarak alınır, ancak geri yükleme prosedürü hiçbir zaman test edilmez. Bir çökme anında geri yüklenemeyen bir yedek işe yaramaz.

Çözüm: Aktif izleme, test edilmiş yedekler ve staging ortamları talep edin

Profesyonel bir anlaşma yalnızca yedeklerin alındığını değil, aynı zamanda nerede saklandıklarını ve ne kadar hızlı geri yüklenebileceklerini de belirler. Yedekler, web sitenizle aynı sunucuda değil, harici ve korumalı bir sunucuda bulunmalıdır. Sözleşmede net bir kurtarma garantisi yer almalıdır: ciddi bir kesinti durumunda, çalışan bir sürüm kaç saat içinde tekrar yayında olacak?

Ayrıca güncellemeler, canlı ortama geçmeden önce her zaman önce korumalı bir test ortamında (staging) test edilmelidir. TypeScript, React ve Vite gibi modern araçlarla yapılan temiz kodlu özel çalışmalarda güncellemeler, eklentilerle dolu hazır CMS temalarına kıyasla genellikle çok daha az arızaya eğilimlidir. Yine de bağımlılıkların, API entegrasyonlarının ve güvenlik anahtarlarının periyodik olarak kontrol edilmesi gereklidir.

Hata 2: Olaylar için somut yanıt sürelerinin olmaması (SLA)

Platform pazartesi sabahı çöker veya ödeme ağ geçidi hizmet vermeyi reddeder. Geliştiricinize bir e-posta gönderirsiniz ve ancak çarşamba günü bir yanıt alırsınız. Sağlam bir Hizmet Seviyesi Sözleşmesi (SLA) olmadan, tedarikçinizin hızlı hareket etme konusunda hiçbir operasyonel yükümlülüğü yoktur.

Çözüm: Önceliğe göre yanıt sürelerini belirleyin

Bir bakım sözleşmesi, olay türleri ile bunlara karşılık gelen yanıt süreleri arasında net bir ayrım yapmalıdır. Erişilemeyen bir site veya bozuk bir ödeme sistemi gibi kritik bir olay, iş süreciniz için gerekliyse standart çalışma saatleri dışında bile hızlı bir yanıt gerektirir.

Dağılımı sözleşmede şu şekilde belirleyin:

  • Öncelik 1 (Kritik): Web sitesi çöktü veya ödemeler başarısız oluyor. Yanıt süresi: 2 ila 4 saat içinde.
  • Öncelik 2 (Yüksek): Önemli bir işlev çalışmıyor ancak geçici bir çözüm mümkün. Yanıt süresi: 1 iş günü içinde.
  • Öncelik 3 (Düşük): Küçük kozmetik hatalar veya metin düzenlemeleri. Yanıt süresi: 3 ila 5 iş günü içinde.

Ayrıca yanıt süresi tanımının, bir geliştiricinin gerçekten teşhise veya onarıma başlaması anlamına geldiğinden ve bir destek sisteminden gelen otomatik bir e-posta onayı olmadığından emin olun.

Hata 3: Dönüşüm kayıplarına ve işlevsel hatalara karşı kontrol eksikliği

Bakım çoğu zaman yalnızca teknik açıdan ele alınır: sunucu çalışıyor mu ve kod güncel mi? Bu sırada doğrudan ciroya mal olan işlevsel sorunlar ortaya çıkar. Harici sistemlerle entegrasyonlar sessizce değişir, formlar artık CRM'e ulaşmaz veya ödeme sürecinde aksayan adımlar oluşur.

Bunun somut bir örneği, ödeme sayfasındaki düşünülmemiş bir indirim kodu alanıdır. Aktif bir kampanyanız yokken orada göze çarpan bir giriş alanı gösterirseniz, satın almaya hazır ziyaretçiler bir kod aramak için arama motorlarına yönelerek ödeme sayfasını terk eder. Genellikle komisyon alan veya müşteriyi bir rakibe yönlendiren harici indirim sitelerinde son bulurlar. Bu, standart teknik bakımla asla fark edilmeyen ama doğrudan paraya mal olan işlevsel bir kayıptır.

Çözüm: Periyodik işlevsel denetimler ekleyin

İyi bir sözleşme, her çeyrek veya altı ayda bir sitenizdeki kritik yolların işlevsel bir incelemesini içerir. Tüm iletişim formları hâlâ çalışıyor mu ve veriler arka plandaki panoya veya veritabanına doğru şekilde ulaşıyor mu? Sipariş süreci mobil ekranlarda sorunsuz çalışıyor mu? Hata mesajları kullanıcıya net bir şekilde iletiliyor mu?

Bunu anlaşmaya yapısal olarak dahil ederek, bir platformun teknik açıdan kusursuz çalışırken ticari olarak ciro kaybetmesini önlersiniz.

Hata 4: Yükleme süresi ve performans garantilerinin eksikliği

Bir platform hafif kod, Tailwind CSS ve sıkı bir veritabanı yapısıyla yeni inşa edildiğinde, yükleme süresi idealdir. Zamanla ekip yeni harici script'ler ekler, büyük görseller düzensiz bir şekilde yüklenir veya harici yazılımlarla entegrasyonlar yavaşlar. Sürekli izleme olmadan, yavaşlık fark edilmeden sızar.

Yavaş bir site, daha yüksek bir hemen çıkma oranına ve daha düşük dönüşümlere yol açar. Bakım sözleşmesi performansla ilgili herhangi bir gereklilik belirlemiyorsa, geliştirici hızı izlemekten sorumlu hissetmez.

Çözüm: Bakımı somut hız standartlarına bağlayın

Web sitesinin performansının önceden tanımlanmış sınırlar içinde kalması gerektiğini kararlaştırın. Burada Google'ın yükleme süresi ve kararlılık için temel metriklerini düşünün.

Anlaşmaya şu noktaları ekleyin:

  • Ana sayfa, ürün sayfaları ve iletişim formu gibi kritik sayfalarda yükleme süresinin aylık veya sürekli ölçümü.
  • Yükleme süresi teknik birikim nedeniyle kararlaştırılan standardın altına düştüğünde ne olacağına dair sabit bir protokol.
  • Eski script'lerin, kullanılmayan kodun ve gereksiz bağımlılıkların periyodik olarak temizlenmesi.

Hata 5: Dahil edilen saatler ve devretme kuralları konusunda belirsizlik

Birçok KOBİ, örneğin iki saatlik küçük düzenlemeleri içeren sabit bir aylık ücret öder. Yıl sonunda bu saatlerin hiç kullanılmadığı ama tam olarak faturalandırıldığı ortaya çıkar. Tam tersi de olur: her ufak talep, her şeyin kapsam dışında kaldığı gerekçesiyle hemen ek bir teklife ve sonradan hesaplamaya yol açar.

Çözüm: Şeffaflık ve saat takibi konusunda net anlaşmalar yapın

Önleyici bakım kapsamına (güncellemeler, izleme, güvenlik) neyin girdiğini ve aktif geliştirme kapsamına (yeni işlevler, UX iyileştirmeleri, süreç optimizasyonu) neyin girdiğini tam olarak kararlaştırın.

Sözleşmede bir saat bakiyesi varsa, şunları belirleyin:

  • Bu saatlerin nasıl raporlanacağı, örneğin yapılan çalışmaların aylık bir özeti aracılığıyla.
  • Kullanılmayan saatlerin, örneğin iki ila üç ay gibi gerçekçi bir üst sınırla bir sonraki aya devredilip devredilmeyeceği.
  • Anlaşma dışındaki ek çalışmaların önceden nasıl onaylanacağı, böylece asla sonradan bir faturayla şaşırmazsınız.

Performans göstermeye devam eden bir temel üzerinde çalışın

Bir bakım sözleşmesi huzur, güvenlik ve süreklilik sağlamalıdır. Kurtarma süresi, yanıt hızı ve işlevsel kontrol konusunda net garantiler olmadan, bu sözleşme ağırlıklı olarak tekrarlayan bir maliyet kalemi olur. Sözleşme kapsamına neyin girdiğini önceden net bir şekilde belirleyerek dijital yatırımınızı korur ve kesintiyi önlersiniz.

Platformunuzun mevcut durumunu konuşmak veya yeni bir projeyi en baştan doğru şekilde kurmak ister misiniz? ferhat.io/contact üzerinden ücretsiz otuz dakikalık bir görüşme planlayın. Ardından durumunuz için en iyi yaklaşıma birlikte bakarız.