Web Sitesinde Ücretsiz Destek Nerede Biter, Yıllık Bakım Nerede Başlar?

Web sitesinde ücretsiz destek, teslim edilen ve onaylanan kapsamın planlandığı biçimde çalışmasını sağlamak için sunulan hata giderme dönemidir. Yıllık bakım ise site yayında kaldığı sürece güncelleme, güvenlik, yedekleme, performans ve işlev kontrolleri gibi tekrarlanan işlerin planlanmasıdır. Yeni bir sayfa, özellik, entegrasyon veya iş akışı talebi ise çoğunlukla yeni geliştirme kapsamına girer.

Bu üç alanı ayırmanın en sağlıklı yolu, talebin kaç dakika süreceğine bakmak değil; başlangıçta onaylanan kapsamın parçası olup olmadığını, sorunun kaynağını ve düzenli operasyon gerektirip gerektirmediğini incelemektir.

Kumsal Ajans projelerinde, aksi teklif veya sözleşmede belirtilmedikçe, canlıya geçiş veya nihai teslim tarihinden itibaren ilk altı ay teslim edilen kapsam içindeki yazılım hataları ve proje kaynaklı teknik sorunlar için ücretsiz destek uygulanır. Kurumsal web sitelerinde bu dönemin ardından yıllık bakım planlanabilir. Projeye özel web yazılımlarında ise bakım ihtiyaca göre aylık veya proje bazlı ele alınabilir.

Ücretsiz Destek, Bakım ve Yeni Geliştirme Arasındaki Fark Nedir?

Ücretsiz destek döneminin temel sorusu şudur:

Teslim sırasında onaylanan işlev, proje kaynaklı bir hata nedeniyle planlandığı biçimde çalışmıyor mu?

Yanıt evetse talep ücretsiz hata desteği kapsamında değerlendirilebilir. Örneğin teslim kapsamında bulunan bir iletişim formunun, projedeki bir yazılım hatası nedeniyle kayıt oluşturmaması bu sınıfa girebilir.

Bakımın temel sorusu farklıdır:

Siteyi yayın sonrasında güncel, izlenebilir ve yönetilebilir tutmak için tekrarlanan bir kontrol veya işlem gerekiyor mu?

Planlı yazılım güncellemeleri, güvenlik kontrolleri, yedeklerin izlenmesi, formların dönemsel denenmesi ve performansın takip edilmesi bakım planında yer alabilecek işlerdir. Bunların hangisinin hangi sıklıkta yapılacağı projenin altyapısına, veri yapısına ve risklerine göre yazılı biçimde belirlenmelidir.

Yeni geliştirmede ise soru şudur:

Talep, onaylanan kapsamı değiştiriyor veya genişletiyor mu?

Yeni bir başvuru formu, üyelik sistemi, farklı kullanıcı rolü, ödeme bağlantısı, rapor veya dış servis entegrasyonu mevcut siteye değer katabilir; fakat daha önce teslim edilen işlevin hatasını düzeltmek değildir. Bu nedenle ayrı kapsam, takvim ve bütçe gerektirebilir.

İlk Altı Aylık Ücretsiz Destek Ne Zaman Başlar?

Kumsal Ajans modelinde başlangıç noktası, aksi sözleşmede belirtilmedikçe, canlıya geçiş veya nihai teslim tarihidir. Dönemin başlangıcı ve bitişi teklif ya da teslim kaydında açıkça yazılmalıdır. Böylece “altı ay ne zaman başladı?” sorusu tarafların farklı yorumuna bırakılmaz.

Ücretsiz dönem şu işleri kapsar:

• Teslim edilen kapsam içindeki yazılım hatalarının giderilmesi
• Onaylanan işlevlerin planlandığı şekilde çalışmasının sağlanması
• Proje kaynaklı teknik sorunların incelenmesi

Bu kapsam, sitenin altı ay boyunca sınırsız biçimde değiştirilmesi anlamına gelmez. Başlangıç kapsamı, tasarım onayları, özellik listesi ve teslim kontrolü kayıtlı değilse sonradan gelen talebin hata mı yoksa değişiklik mi olduğunu ayırmak zorlaşır. Bu nedenle yayın öncesindeki kabul süreci, yayın sonrası desteğin de sınırını oluşturur. Erişim, işlev, mobil görünüm ve destek başlangıcı için kurumsal web sitesi teslim kontrol listesinden yararlanabilirsiniz.

Hangi Talepler Ücretsiz Desteğe Girmez?

Aşağıdaki çalışmalar, aksi açıkça teklif veya sözleşmede belirtilmedikçe, ücretsiz hata desteğinden ayrı değerlendirilir:

• Yeni özellik, modül veya entegrasyon geliştirilmesi
• Mevcut kapsamın değiştirilmesi veya genişletilmesi
• Tasarım ve kullanıcı deneyimi revizyonları
• Yeni sayfa şablonu veya farklı iş akışı
• Yoğun içerik ya da veri girişi
• Üçüncü taraf servisin yaptığı değişiklikten doğan uyarlamalar
• Müşteri veya başka bir hizmet sağlayıcının müdahalesinden doğan çalışmalar
• Alan adı, sunucu, lisans ve üçüncü taraf servis ücretleri
• Düzenli bakım, güvenlik güncellemesi, performans takibi ve operasyonel izleme

Burada “küçük talep” ifadesi tek başına karar ölçütü değildir. Ekranda yalnızca bir alan ekleniyor gibi görünen değişiklik; veri tabanını, kullanıcı yetkilerini, e-posta içeriğini ve raporları etkileyebilir. Talebin etkisi görülmeden hata veya ücretsiz iş olarak sınıflandırılması sağlıklı olmaz.

Yıllık Bakım Neden Ayrı Bir Hizmettir?

Web sitesi teslim edildiği gün sabit kalan bir dosya değildir. Sunucu ortamı, kullanılan yazılım bileşenleri, tarayıcılar, güvenlik açıkları ve üçüncü taraf servisler zaman içinde değişebilir.

NIST Secure Software Development Framework, yayımlanan yazılımdaki kalan güvenlik açıklarının belirlenmesini ve bunlara uygun yanıt verilmesini ayrı bir uygulama alanı olarak ele alır. Aynı çerçeve, ticari ve açık kaynak dâhil üçüncü taraf bileşenlerin bilinen açıklar ve bakım sonu durumu açısından yaşam döngüsü boyunca izlenmesini önerir. Bu yaklaşım her web sitesine aynı bakım paketini zorunlu kılmaz; yayın sonrasındaki değişikliklerin sorumlusu ve yöntemi belirlenmeden bırakılmaması gerektiğini gösterir.

Kurumsal web sitelerinde yıllık bakım, bu tekrarlanan işleri bir dönem içinde planlamak için kullanılabilir. Projeye özel web yazılımlarında kullanıcı sayısı, işlem yoğunluğu, entegrasyonlar ve operasyonel önem daha farklı olabileceği için aylık veya proje bazlı bakım daha uygun olabilir.

Bakım modelinin adı kadar kapsamı da önemlidir. “Yıllık bakım dahildir” cümlesi şu soruları yanıtlamıyorsa tek başına yeterli değildir:

• Hangi işler yapılacak?
• Hangi sıklıkta kontrol edilecek?
• Talebi kim açacak, kim değerlendirecek?
• Acil ve normal talepler nasıl ayrılacak?
• İlk yanıt veya çözüm için yazılı bir hedef var mı?
• Hangi durumlar ve dış servis maliyetleri kapsam dışında?
• Yapılan çalışma nasıl kayıt altına alınacak?

Bakım Planında Neler Açıkça Yazılmalıdır?

Aşağıdaki tablo, bakım teklifi veya hizmet ekini değerlendirirken kullanılabilir. Her satır bütün projeler için zorunlu değildir; uygulanmayan madde gerekçesiyle işaretlenebilir.

Yedekleme satırında yalnızca “yedek alınıyor” yazması yeterli bir operasyon tanımı değildir. CISA'nın fidye yazılımı rehberi, yedek prosedürlerinin düzenli test edilmesini ve yedeklerin kullanılabilirliği ile bütünlüğünün kurtarma senaryosunda kontrolünü önerir. Bu, her proje için aynı yedekleme sıklığı demek değildir; sıklığın, saklamanın ve geri dönüş yönteminin risklere göre tanımlanması gerektiğini gösterir.

Yayın Sonrası Talep Sınıflandırma Tablosu

Bir talep geldiğinde aşağıdaki alanları doldurun:

1. Talep veya sorun nedir?
2. Onaylanan teslim kapsamında karşılığı var mı?
3. Beklenen davranış neydi, gerçekleşen davranış ne?
4. Kaynak proje hatası mı, düzenli operasyon mu, müşteri değişikliği mi, üçüncü taraf mı?
5. Talep ücretsiz hata desteği, bakım, yeni geliştirme veya üçüncü taraf işi sınıflarından hangisine giriyor?
6. Sorumlu taraf kim?
7. Hangi erişim veya bilgi gerekiyor?
8. Varsa hedef süre ve istisna ne?
9. Ek maliyet veya dış bağımlılık bulunuyor mu?
10. Tamamlanma ve müşteri onayı nerede kaydedilecek?

Bu örnekler gerçek müşteri vakası değil, yöntemi açıklayan kurgusal karar senaryolarıdır. Kesin sınıf, projenin onaylanan kapsamı ve sözleşmesi incelendikten sonra belirlenir.

Beş Kısa Karar Senaryosu

1. Form hiç çalışmamışsa

Teslimde onaylanan bir form, proje içindeki hata nedeniyle kayıt oluşturmuyorsa ücretsiz hata desteği kapsamında incelenebilir. Ancak sorun müşterinin sonradan değiştirdiği e-posta hesabından veya harici gönderim servisinin yeni kuralından kaynaklanıyorsa sorumluluk ayrıca değerlendirilmelidir.

2. Yeni sayfa isteniyorsa

Mevcut metindeki bir yazım düzeltmesiyle yeni tasarım, yeni şablon ve yeni form içeren sayfa aynı iş değildir. Yıllık bakım paketinde küçük içerik güncellemeleri bulunabilir; yeni sayfa üretimi ise ayrı geliştirme olabilir.

3. Güvenlik güncellemesi gerekiyorsa

Güncellemenin uygulanması kadar mevcut işlevlerle uyumu, test yöntemi ve sorun hâlindeki geri dönüş planı da belirlenmelidir. Güncelleme tekrarlanan bir yaşam döngüsü işi olduğu için bakım kapsamında ele alınabilir.

4. Entegrasyon sağlayıcısı değişiklik yaptıysa

Harici ödeme, harita, e-posta, SMS veya başka API servisinin yaptığı değişiklik proje hatası değildir. Etkilenen işlev, yeni gereksinim, test ve üçüncü taraf maliyeti incelenerek ayrı kapsam oluşturulabilir.

5. Site zamanla yavaşladıysa

Önce sebep belirlenmelidir. Yeni yüklenen büyük görseller, artan veri, sunucu kaynağı, üçüncü taraf kodu veya yazılım değişikliği farklı sorumluluklar doğurur. “Site yavaş” ifadesi tek başına ücretsiz hata desteği kararı verdirmez.

Müşteri, Ajans ve Üçüncü Taraf Sorumlulukları Nasıl Ayrılır?

Bakım planı her işi ajansa bırakmak anlamına gelmez. Müşteri tarafında yetkili bir kişi, içerik doğruluğu, kullanıcı erişimleri ve talep onayından sorumlu olabilir. Ajans; üzerinde anlaşılan teknik kontrol, güncelleme ve geliştirme işlerini yürütür. Hosting, lisans, e-posta veya API sağlayıcısı ise kendi hizmetinin çalışma ve değişiklik koşullarından sorumludur.

Her satır için dört bilgi yazın:

• İşi yapan
• Gerekli bilgiyi veya erişimi sağlayan
• Sonucu onaylayan
• Üçüncü taraf bağımlılığı

Bu ayrım, kod ve hesap sahipliğiyle birlikte düşünülmelidir. Hazır ve özel sistemlerde sorumluluğun nasıl değişebileceğini hazır altyapı ile projeye özel web yazılım karşılaştırmasında inceleyebilirsiniz.

Altı Ay Dolmadan Bakım Planı Nasıl Hazırlanır?

Bakım görüşmesini ücretsiz destek bittikten sonra başlatmak yerine teslim döneminde temel sorumlulukları belirleyin. Altıncı aya yaklaşırken şu adımları uygulayın:

1. İlk dönemde açılan destek taleplerini konu ve kaynağına göre gruplayın.
2. Tekrarlanan form, içerik, entegrasyon veya performans ihtiyaçlarını belirleyin.
3. Kullanılan yazılım bileşenleri ve dış servislerin sorumlularını listeleyin.
4. Yedekleme, güncelleme, güvenlik ve işlev kontrollerinden hangilerinin gerekli olduğunu değerlendirin.
5. İş, sıklık, sorumlu, kanal, hedef ve istisna alanlarını yazın.
6. Yeni geliştirme ihtiyaçlarını bakım paketinden ayrı bir yol haritasına alın.
7. Alan adı, hosting, lisans ve dış servis yenilemelerini bütçeye ekleyin.

Kurulum, yenileme, bakım ve yeni geliştirme kalemlerini üç yıllık görünümde ayırmak için web sitesinin toplam maliyet tablosunu kullanabilirsiniz.

Bakım Teklifindeki Kırmızı Bayraklar

• “Sınırsız destek” deniyor fakat destek konusu ve kanalı yazılmıyor.
• “Düzenli yedek” deniyor fakat sıklık, saklama ve geri yükleme kontrolü açıklanmıyor.
• İlk yanıt ile çözüm süresi birbirine karıştırılıyor.
• Yeni geliştirme ile hata giderme aynı belirsiz hizmet içinde tutuluyor.
• Üçüncü taraf servis değişikliklerinin sorumluluğu yazılmıyor.
• Güncellemelerin test ve geri dönüş yaklaşımı belirtilmiyor.
• Hesaplar ve erişimler yalnızca hizmet sağlayıcının kontrolünde kalıyor.
• Yapılan bakım işlemleri için tarih ve sonuç kaydı oluşturulmuyor.
• Belirli güvenlik, hız veya kesintisiz çalışma sonucu kapsam ve koşul olmadan garanti ediliyor.

Bakım sağlayıcısının yalnızca hizmet listesini değil, teknik süreci ve teslim yaklaşımını da değerlendirmek için web yazılım firması teknik yeterlilik rehberinden yararlanabilirsiniz.

Sonuç: Desteğin Süresinden Önce Sınırını Yazın

Ücretsiz destek, teslim edilen kapsamın planlandığı biçimde çalışmasını sağlayan hata giderme dönemidir. Yıllık veya aylık bakım, siteyi yayın sonrasında güncel ve yönetilebilir tutmak için tekrarlanan işleri planlar. Yeni geliştirme ise onaylanan kapsamı değiştirir veya genişletir.

Bu üç alanı “küçük iş, büyük iş” yaklaşımıyla değil; onaylanan kapsam, sorunun kaynağı, operasyon sıklığı, üçüncü taraf bağımlılığı ve beklenen çıktı üzerinden ayırın. Bakım planına işin adını, sıklığını, sorumlusunu, bildirim kanalını, varsa hizmet hedefini, istisnaları ve tamamlanma kaydını ekleyin.

Kumsal Ajans kurumsal web sitelerinde ilk altı aylık ücretsiz hata desteğinin ardından yıllık bakım; projeye özel web yazılımlarında ise ihtiyaca göre aylık veya proje bazlı bakım planlayabilir. Projenizin yayın sonrası sorumluluklarını ve bakım kapsamını değerlendirmek için Kumsal Ajans web yazılım hizmetini inceleyebilirsiniz.

Sık Sorulan Sorular

İlk altı aylık ücretsiz destek hangi tarihte başlar?

Aksi teklif veya sözleşmede belirtilmedikçe canlıya geçiş veya nihai teslim tarihinde başlar. Başlangıç ve bitiş tarihlerinin teslim kaydında açıkça yazılması gerekir.

Ücretsiz destek yeni özellik geliştirmeyi kapsar mı?

Hayır. Yeni özellik, modül, entegrasyon, tasarım değişikliği veya kapsam genişletmesi ücretsiz hata desteğinden ayrı değerlendirilir.

Web sitesi bakımı ile teknik destek aynı şey midir?

Her zaman değildir. Teknik destek bir sorun veya kullanım talebine yanıt vermeyi; bakım ise güncelleme, güvenlik, yedekleme ve işlev kontrolü gibi tekrarlanan planlı işleri kapsayabilir. Kesin sınır teklif veya sözleşmede yazılmalıdır.

Yıllık bakım paketinde hangi işler bulunmalıdır?

Tek bir evrensel paket yoktur. Projenin ihtiyacına göre yazılım güncellemeleri, güvenlik kontrolleri, yedekleme, performans, formlar, entegrasyonlar, içerik desteği ve raporlama değerlendirilebilir. Her işin sıklığı ve sorumlusu ayrıca belirtilmelidir.

Üçüncü taraf servis değişikliklerinden doğan çalışma kimin sorumluluğundadır?

Harici servisin yaptığı değişiklik proje hatası sayılmaz. Ajansın etki incelemesi, uyarlama çalışması, testler ve dış servis ücretleri teklif veya sözleşmedeki sorumluluklara göre ayrıca değerlendirilir.

Altı ay dolmadan bakım planı hazırlanmalı mı?

Evet. İlk destek döneminde oluşan talepler, kullanılan bileşenler, dış servisler ve tekrarlanan operasyonlar incelenerek bakım kapsamı altı ay bitmeden planlanabilir. Böylece destek bittiğinde sorumluluk boşluğu oluşması önlenir.