Yazılım teslim edildi, bakımını kim yapacak? Destek sözleşmesinde olması gereken maddeler

Bir bakım ve destek sözleşmesinin işe yarayıp yaramadığı ilk ciddi arızada belli olur. O gün dört sorunun yazılı cevabı varsa sözleşme çalışıyordur: neyin hata, neyin değişiklik talebi sayıldığı; hangi saatlerde kaç dakika içinde yanıt geleceği ve neyin çözülmesinin taahhüt edildiği; çalışan sistemin yamalarını ve bağımlılık güncellemelerini kimin geçtiği; sözleşme bittiğinde nelerin hangi biçimde devredileceği. Bu dördü yazılı değilse her arıza küçük bir pazarlığa dönüşür. Pazarlık için en kötü zaman da sistemin çalışmadığı zamandır.

Bakım dört ayrı iştir, sözleşmeler genelde birini kapsar

ISO/IEC/IEEE 14764'ün 2022 sürümü yazılım bakımını dört başlıkta ele alır. Düzeltici bakım, teslimden sonra ortaya çıkan hataların giderilmesidir. Uyarlayıcı bakım, yazılımın kendisi değişmese de çevresi değiştiği için yapılan iştir: bulut sağlayıcı bir API'yi emekliye ayırır, ödeme kuruluşu SDK sürümünü yükseltir, tarayıcı yeni bir kural getirir. Mükemmelleştirici bakım çalışan bir şeyi iyileştirmektir; performans ayarı, ekran düzeni, küçük eklemeler. Önleyici bakım ise henüz arızaya dönüşmemiş sorunu kapatmaktır: destek takvimi dolmak üzere olan kütüphaneyi değiştirmek, sürekli hata çıkaran modülü yeniden yazmak gibi.

Aynı standart bakım sürecinin içine göçü ve yazılımın emekliye ayrılmasını da koyar. Sözleşmelerde bu iki başlığı neredeyse hiç görmüyoruz.

Sorun şu ki "bakım" kelimesi tek başına durduğunda taraflar farklı şey anlıyor. Müşteri dördünü birden anlıyor, tedarikçi çoğunlukla yalnızca birincisini.

Bütçenin büyük kısmı hata düzeltmeye gitmez

Lientz, Swanson ve Tompkins'in 1978'de yayımladığı ve hâlâ atıf alan anket çalışmasında bakım eforunun dağılımı şöyleydi: düzeltici yüzde 17,4; uyarlayıcı yüzde 18,2; mükemmelleştirici yüzde 60,3; kalan yüzde 4,1 diğer. Sonraki yıllarda anket yerine gerçek kayıtları ölçen çalışmalar düzeltici bakımın payını bu rakamın iki katından fazla buldu, ama tablonun ana hattı değişmedi. Bakıma harcanan emeğin çoğu hata düzeltmeye değil, yazılımı değişen çevresine ve değişen işe uydurmaya gidiyor.

Pratik sonucu şu: kapsamı yalnızca "hata düzeltme" diye yazılmış bir destek sözleşmesi, ilk yılın sonunda teklif trafiğine dönüşür. Her uyarlama işi ayrı bir ek sözleşme olur, her ek sözleşme iki hafta bekler.

"Bu hata değil, değişiklik talebi"

Bu cümleyi bir kez duyacaksanız, tanımı sözleşmede yapmış olun. İşleyen kural sade: yazılı gereksinime veya kabul ölçütüne aykırı davranış hatadır ve tedarikçinin hesabına yazılır, gereksinimi genişleten her şey değişiklik talebidir. Kuralın çalışması için gereksinimlerin ölçülebilir yazılmış olması gerekir; bunun nasıl yapıldığını yazılım şartnamesi ve kabul testi yazılarında ele almıştık.

Gri alanları baştan paylaştırın. Veri büyüdükçe yavaşlayan ekran, kabul ölçütünde bir sayı varsa hatadır, yoksa tartışma konusudur. İşletim sistemi güncellemesinden sonra bozulan mobil ekran uyarlayıcı bakımdır ve faturası genelde müşteriye çıkar. Üçüncü taraf bir servisin sürüm emekliliği de aynı yere düşer. Bu üç örneği sözleşmeye yazmak, bir yıl sonra yaşanacak üç tartışmayı bugünden bitirir.

Garanti süresi ile bakım sözleşmesi aynı şey değil

Garanti, teslim anında var olan ayıpları kapsar ve süresi sözleşmede yazar; 3 ila 12 ay aralığı yaygın. Bakım sözleşmesi ise teslimden sonra başlayan sürekli iştir ve ücretlidir. İkisini karıştıran müşteri garanti süresi boyunca izleme, yama ve sürüm yükseltmesi bekler; tedarikçi ise yalnızca hata düzeltmeyi taahhüt ettiğini düşünür. Aynı masada iki farklı beklenti oturur.

Hukuki taraf sözleşme maddesinden bağımsız işler. Türk Borçlar Kanunu'nun 478. maddesi ayıplı eser nedeniyle açılacak davalar için teslimden itibaren iki yıllık zamanaşımı öngörür, yüklenicinin ağır kusuru varsa süre yirmi yıla çıkar. Garanti maddesinin bitmesi sorumluluğun bittiği anlamına gelmiyor.

SLA'da iki ayrı saat vardır: yanıt ve çözüm

Yanıt süresi bir bildirim taahhüdüdür, çözüm süresi bir tamamlama taahhüdü. Sözleşme uyuşmazlıklarının en sık kaynağı ikisini aynı satıra yazmaktır. Önceliği de duyguya bırakmayın: ITIL'in yaygın kullanılan yaklaşımı önceliği etki ve aciliyetin kesişiminden üretir, üçer seviyeli bir matris P1'den P4'e doğru sıralanır. Piyasada sık görülen hedefler P1 için 15 ila 30 dakika içinde yanıt ve 7/24 kapsam, P3 için mesai saatleri içinde birkaç saattir.

Sözleşmeye şunları da yazın: kayıt hangi kanaldan açılır (geliştiricinin WhatsApp'ı bir kanal değildir), saat hangi anda başlar ve hangi durumda durur, kapsam saatleri hangi zaman diliminde tanımlıdır, nöbet var mı. Çözüm taahhüdünü kontrolünüzde olmayan şeylere vermeyin. Kesinti kaynağı üçüncü taraf bir servis olduğunda taahhüt, sorunu çözmek değil geçici çözüm üretmek ve belirli aralıklarla bilgilendirmek olmalı.

Bir de şu var: SLA saati kayıt açıldığında başlıyorsa ve sistemi izleyen kimse yoksa, arızayı fark eden ilk kişi müşteri olur. Bu durumda sözleşmedeki dakikalar gerçek kesinti süresini ölçmez. İzlemenin kapsamda olup olmadığını netleştirin, izlenebilirlik ve SLO tarafındaki eşikleri bakım sözleşmesindeki hedeflerle aynı sayfaya koyun.

Saat havuzu mu, sabit bedel mi

Üç model dolaşımda: aylık sabit bedel karşılığı tanımlı kapsam, saat havuzu, iş başına faturalama. Kurumsal yazılım tarafında fiyat bandı oturmuş durumda; Oracle teknoloji ürünlerinde yıllık destek bedelini net lisans bedelinin yüzde 22'si olarak uygular, SAP'de sözleşme tipine göre yüzde 19 ya da yüzde 22 karşımıza çıkar. Özel yazılımda dayanak lisans olmadığı için bu oranlar doğrudan uygulanmaz, ama yıllık bakım bütçesini yapım maliyetinin bir yüzdesi olarak planlamak için makul bir başlangıç noktası verir.

Çıplak saat havuzu almayın. Havuzun yanında kapsam listesi olsun: izleme, yama, yedek doğrulama, sürüm yükseltme, küçük geliştirme. Devreden saatlerin ne olacağını, acil müdahale ücretini ve havuz bittiğinde ne yapılacağını yazın. Bakımın yazılımın toplam yaşam döngüsü maliyetindeki payı için literatürde yüzde 60 ile 80 arasında rakamlar verilir. Tek bir doğru sayı yok, ama hepsi aynı yöne bakıyor: asıl para teslimden sonra harcanıyor.

Güvenlik yaması ayrı bir madde olmalı

Yalnızca sizin açtığınız kaydı işleyen bir destek sözleşmesinde, CVE akışını izleyen kimse yoktur. Bağımlılıklarda çıkan bir açık kimsenin bildirim açmasını beklemez. Sözleşmeye yazılması gerekenler net: bağımlılık ve işletim sistemi güncellemelerini kim geçiyor, hangi ciddiyet seviyesi kaç gün içinde kapatılıyor, konteyner temel imajı ve çalışma zamanı kimin sorumluluğunda, yıllık güncelleme penceresi ne zaman. Yama ve zafiyet yönetimi yazısındaki sıralamayı sözleşme ekine koymak iyi işliyor.

Destek takvimlerini de takvime bağlayın. Kullandığınız dil sürümünün, veritabanının ve çerçevenin destek bitiş tarihleri bellidir; bakım sözleşmesi bu tarihleri en az altı ay önceden gündeme getirmeyi taahhüt etmeli. Aksi halde desteği biten yazılımla bir gün aniden tanışırsınız.

Hesaplar kimin adına açıldı

Bakım ilişkisi ne kadar iyi işlerse işlesin, erişimin tedarikçide toplanması sizi sıkıştırır. Bulut hesabı, alan adı ve DNS, uygulama mağazası geliştirici hesapları, kod deposu, sır yönetimi ve izleme araçları sizin adınıza açılmış olmalı; tedarikçi bunlara yetkilendirilmiş kullanıcı olarak girsin. Bu ayrımın ayrıntısını kaynak kod mülkiyeti ve emanet yazısında anlatmıştık.

Yanına bir de devredilebilirlik şartı ekleyin: dağıtım adımları depodaki belgeden tekrar edilebilir olsun, ortam değişkenleri listelensin, yedekten dönüş prosedürü yazılı olsun. Ölçüt basit. Tedarikçinin en deneyimli geliştiricisi bir ay izne çıkarsa sistem kimin elinde ayakta kalıyor?

Sözleşme bittiğinde ne olacak

Çıkış maddesi, imza gününde en kolay, ayrılık gününde en zor yazılan maddedir. İçinde şunlar bulunmalı: fesih bildirim süresi, devir paketinin içeriği, verinin hangi biçimde ve ne kadar sürede teslim edileceği, bilgi aktarımı için kaç saat ayrılacağı, hesap ve erişim devrinin takvimi, tedarikçinin elindeki kopyaların ne zaman silineceği. ISO/IEC/IEEE 14764'ün göç ve emekliye ayırma başlıklarını açması boşuna değil; yazılımın son günü de bir süreçtir.

Ölçülmeyen bakım, pahalı bakımdır

Aylık rapor istemeyen müşteri, bir yıl sonra parasının nereye gittiğini bilmez. Rapor ağır olmasın: kayıt sayısı ve dört bakım kategorisine dağılımı, SLA uyumu, harcanan saat, yama ve bağımlılık durumu, tekrar eden ilk beş sorun. Üç ayda bir de gözden geçirme toplantısı yapın.

Bu rapor bir şeyi görünür kılar. Kayıtların çoğu aynı üç modülden geliyorsa yaptığınız iş bakım değil, teknik borcun faizini ödemektir. O noktada doğru hamle daha çok destek saati satın almak değil, o modülü düzeltmektir.

Bu hafta atabileceğiniz adım

Mevcut sözleşmenizi açın ve beş soruya cevap arayın: hata ile değişiklik talebi nasıl ayrılıyor, yanıt ve çözüm taahhütleri ayrı ayrı yazılı mı, güvenlik yamasını kim geçiyor, hesaplar kimin adına, fesih halinde devir paketi tanımlı mı. İkisinden fazlasına cevap bulamıyorsanız, bir sonraki arızayı beklemeden ek protokol hazırlayın. Yazması bir gün sürer, yazmamanın faturası genelde bir kesinti gecesinde ödenir.