Yazılım projelerinin en yanıltıcı anı teslim günüdür. Ekranlar kabul edilir, son fatura kesilir, herkes birbirini tebrik eder; ertesi sabah ise gerçek personel gerçek verilerle sisteme girer ve yazılım tam o anda bir sunum olmaktan çıkıp işletmenin çalışan bir parçası hâline gelir. Sahadaki bütün sürprizler de o sabah başlar, çünkü bir sistemin nasıl davrandığını ancak yorgun bir muhasebeci, acelesi olan bir kasiyer ve elinde telefonla koşturan bir saha ekibi gösterebilir.
Teslim Edildi Demek Bitti Demek Değildir
Bu ilk dönemin sayıları aslında oldukça öngörülebilir. Yayına aldığımız sistemlerde ilk ay genellikle 25 ile 40 arasında destek mesajı gelir, ikinci ay bu sayı 16 civarına, üçüncü ay 9 civarına iner ve personel düzgün eğitildiyse dördüncü aydan itibaren ayda 4 ile 8 arasında bir yere oturur. Yani gürültülü bir ilk ay projenin başarısız olduğunun değil, sistemin yerine oturuyor olmasının işaretidir; asıl endişe edilmesi gereken şey, altıncı ayda hâlâ ayda otuz mesaj geliyor olmasıdır.
Sözleşmedeki garanti maddesini de en baştan net konuşalım. Yapım sözleşmelerinin çoğu 30 ile 90 gün arasında ücretsiz bir düzeltme dönemi içerir ve bu dönem yalnızca yanlış yapılmış işleri kapsar, yani teklifte söz verildiği gibi çalışması gerekirken çalışmayan şeyleri. Kapsamadığı üç şey vardır ve anlaşmazlıkların neredeyse tamamı buradan çıkar: yeni talepler, personelin veri girerken yaptığı hatalar ve dışarıdaki bir firmanın, mesela ödeme kuruluşunun, size dayattığı değişiklikler.
Geriye tek bir soru kalır ve bu yazının tamamı o soruya ayrılmıştır: garanti bittikten sonra bu sistemden her ay, yıllar boyunca kim sorumlu olacak ve bu sorumluluk ne kadar tutacak? Linkysoft olarak işimizin yalnızca teslim etmek değil, teslim ettiğimiz sistemi ayakta tutmak olduğunu düşündüğümüz için ilk on iki ayın gerçek işini burada saatiyle ve parasıyla yazdık.
Hiç Bitmeyen Dört Tür İş
Bakım denince akla tek bir şey gelir, oysa dört ayrı iş vardır ve dördü de birbirinden farklı bütçe ister. Teknik isimleri bir kenara bırakıp gündelik dille söyleyelim: bozulanı onarmak, dış dünyaya ayak uydurmak, insanların istediği şeyi iyileştirmek ve sorun gelmeden önlemek.
Her birinin tanıdık bir örneği var:
- Bozulanı onarmak: bir rapor toplamı yanlış yazdırır ve düzeltilir.
- Dış dünyaya ayak uydurmak: ödeme kuruluşu eski bağlantısını kapatır ve sizden yenisine geçmenizi ister.
- İyileştirmek: personel "müşteri kartına ikinci bir telefon alanı koyar mısınız" diye sorar.
- Önlemek: veritabanı sessizce büyüdüğü için aramalar yavaşlar, biri bunu fark eder ve henüz kimse şikâyet etmeden düzeltir.
Buradaki asıl sürpriz şudur: normal bir bakım ayının yalnızca üçte biri kadarı hata düzeltmeye gider, geri kalanın büyük kısmı ayak uydurma ve önleme işidir. Yani iyi yapıldığında kimsenin fark etmediği iş, faturanın en büyük kalemidir; kimse "bu ay sistem hiç çökmedi" diye bir teşekkür maili yazmaz.
Bunu bütçe konuşmasından önce anlatmamızın sebebi çok pratik. Bakımı sadece hata düzeltme sanan bir müşteri, iyi yazılmış bir sistemin neredeyse hiç bakım istemeyeceğine inanır ve ilk yılın sonunda gelen tabloya haklı olarak şaşırır; oysa tek bir hatası olmayan bir sistem bile her ay birilerinin ilgisini ister.
Siz Hiçbir Satıra Dokunmasanız Bile Dünya Değişiyor
Bu yazının ana fikri tek cümlede söylenebilir: yazılım, yerinde dururken bile eskir, çünkü etrafındaki her şey hareket eder. Tarayıcılar ortalama dört haftada bir güncellenir, telefon işletim sistemleri ise yılda bir büyük sürüm çıkarır ve bunların hiçbiri sizin sisteminizi kimseye sormadan olur.
Mobil tarafta müşterileri en çok şaşırtan kural mağazalardan gelir. Uygulama mağazaları asgari yapım gereksinimlerini yılda bir yükseltir, dolayısıyla 12 ile 18 ay boyunca hiç dokunulmamış bir uygulama, içinde tek bir şey değişmemiş olsa bile yeniden yayınlanabilmek için genellikle 20 ile 60 saat arası iş ister. Bu yüzden mobil uygulama geliştirme bütçesini yaparken yayın sonrasını da hesaba katmanızı, en azından yılda bir kez küçük bir uyum çalışması ayırmanızı öneriyoruz.
Sistemin üzerinde çalıştığı motorun da bir ömrü vardır. Motor derken sitenizin arkasında çalışan ve yazılan kodu işleten altyapıyı kastediyoruz; bu altyapıların desteklenme süresi kabaca iki ile üç yıldır. Yani iki üç yılda bir planlı bir motor yükseltmesi bekleyin, sistemin boyutuna göre 15 ile 60 saat arası. Bunu takvime bakarak yapmak, destek bittikten sonra panikle yapmaktan çok daha ucuzdur, çünkü planlı yükseltmede test edecek zamanınız olur.
Bir de dışarıdaki servisler var. Ödeme kuruluşları, kargo firmaları ve mesaj sağlayıcıları eski bağlantılarını zaman zaman kapatır ve bunu genellikle 6 ile 12 ay öncesinden e-posta ile haber verirler. İşte tam bu yüzden birinin o e-postaları okuyor olması gerekir; kimse okumadığı için kapanan bir entegrasyon, yani sizin sisteminizle o firmanın sistemi arasındaki bağlantı, haber verildiğinde iki saatlik iş olan şeyi bir sabah acil krizine dönüştürür.
Son olarak ucuz ama acımasız bir kalem: güvenlik sertifikası. Ücretsiz sertifikalar 90 gün geçerlidir ve kendi kendine yenilenir, ücretli olanlar genellikle bir yıl sürer. Yenilemenin kontrolü birkaç dakikalık iştir, ama süresi dolmuş tek bir sertifika bütün siteyi aynı anda ve her ziyaretçiye kapatır.
Bakım Gerçekte Ne Kadar Tutuyor, Hesabı Açık Yazalım
Pratikte kullanılan kural şudur: yıllık bakım, sistemin ilk yapım maliyetinin yüzde 15 ile 25'i kadar tutar. Hesabı hemen yapalım. 30.000 dolara yaptırdığınız bir sistem yılda 4.500 ile 7.500 dolar arası, yani ayda kabaca 375 ile 625 dolar arası bir bakım ister. Bu rakamı ilk duyduğunda çoğu işletme sahibi yüksek bulur, ama aynı işletme bir aracın yıllık bakımına ve sigortasına itiraz etmeden aynı oranı öder.
Bir projeyi bu aralığın üst ya da alt ucuna iten şeyler bellidir: kaç ayrı dış servisle konuştuğu, içinden para geçip geçmediği, mobil uygulaması olup olmadığı ve her gün kaç kişinin kullandığı. İçinden ödeme geçen ve mobil uygulaması olan bir sistem üst uca, yalnızca ofis içinde on kişinin kullandığı bir kayıt sistemi ise alt uca yakın durur.
Makine masraflarını da ayrı yazalım ki hiçbir kalem sonradan sürpriz olmasın:
- Küçük bir işletme sistemi için barındırma, ayda 40 ile 200 dolar arası.
- Alan adı, yılda 10 ile 40 dolar arası.
- Apple geliştirici hesabı, yılda 99 dolar.
- Google tarafında tek seferlik 25 dolar.
Yıllık kalemleri on iki aya böldüğünüzde, hiç insan emeği eklemeden sadece makinelerin maliyeti ayda kabaca 50 ile 215 dolar arasına oturur ve bu kalem bakım anlaşmanızdan bağımsız olarak her ay ödenir.
Son olarak yüzdeleri, tedarikçiden isteyebileceğiniz bir birime çevirelim. Pek çok pazarda ayda 500 dolarlık bir bakım anlaşması, nitelikli bir geliştiricinin 4 ile 10 saati arasında bir zamanını satın alır. Bu yüzden sorulacak doğru soru "aylık ücretiniz nedir" değil, "bu ücretin içinde kaç saat var ve kullanılmayan saatler bir sonraki aya devrediyor mu" sorusudur.
Sistemi Ayakta Kim Tutacak: Dört Dürüst Seçenek
Birinci seçenek, sistemi yapan ekiple aylık bir bakım anlaşması. En hızlısı budur, çünkü kodu zaten tanıyorlar ve bir sorunu anlamak için haftalarca okumaları gerekmez; standart bir anlaşma, değişiklik saatleri de dâhil, yılda 9.000 dolar civarına oturur. Dürüst zayıflığı ise bağımlılıktır, bu yüzden sözleşmenizde ayrılmak istediğinizde her şeyi yanınızda götürebileceğinizi yazılı olarak arayın.
İkinci seçenek, çağrı üzerine çalışan bir serbest geliştirici. Gerçekten ulaşılabilir bir serbest çalışan yılda 12.000 dolar civarına mal olur ve saat başına maliyeti bir ekibinkinden düşüktür. Riski ise tek cümlede söylenir: bir kişi hastalanır, tatile çıkar ya da başka bir işe geçer ve sistemin bütün bilgisi onunla birlikte gider.
Üçüncü seçenek, kadroya geliştirici almak. Pek çok pazarda orta seviye bir geliştiricinin gerçek yıllık maliyeti, maaş dışındaki her şey sayıldığında 35.000 ile 90.000 dolar arasına oturur. Bu ancak sistem her hafta değişiyorsa ve işletmenin para kazanma biçiminin tam merkezinde duruyorsa mantıklıdır; günde iki saat işi olan bir web uygulaması için tam zamanlı bir kişi tutmak, o kişinin de sıkılıp ayrılmasıyla biter.
Dördüncü seçenek, hiçbir şey yapmamak ve bozulunca birini aramak. Bunu küçümsemeyelim, beş kişinin kullandığı basit bir iç araç için gerçekten doğru tercih olabilir. Aynı açıklıkla şunu da söyleyelim: içinden ödeme geçen hiçbir sistem için doğru değildir, çünkü kurtarma işi neredeyse her zaman bir yıllık bakımdan pahalıya gelir.
Son Faturadan Önce Sahip Olmanız Gereken Devir Paketi
Şu listeyi çıktı alıp projenin sonunda tek tek işaretlemenizi öneriyoruz:
- Alan adı ve DNS kayıtları, yani sitenizin internette nerede durduğunu gösteren adres defteri, şirketinizin kendi hesabında.
- Barındırma ya da bulut hesabı, şirket adına açılmış olarak.
- Kaynak kodu, sizin kontrolünüzdeki bir depoda; depo dediğimiz şey, kodu ilk günden bu yana yapılmış her değişikliğin kaydıyla birlikte saklayan çevrimiçi ambardır.
- Veritabanı erişim bilgileri, bir parola yöneticisinde saklanmış olarak.
- Kullanılan her lisansın yazılı listesi.
Küçük işletmeleri en çok yakalayan madde ise şudur: ödeme, e-posta, SMS ve harita gibi bütün üçüncü taraf hesaplar şirketin e-posta adresine kayıtlı olmalı, asla bir geliştiricinin kişisel adresine değil. O hesaplarda sizin paranız ve müşterilerinizin verisi durur, dolayısıyla kimin adına açıldıkları teknik bir ayrıntı değil, doğrudan sahiplik meselesidir.
Bir de sade dille yazılmış iki belge isteyin: bir değişikliğin canlıya nasıl alındığı ve site akşam dokuzda çöktüğünde ne yapılacağı. İkisi de sizi hiç tanımayan yetkin bir yabancının takip edebileceği açıklıkta olmalı, çünkü bu belgelerin gerçekten okunacağı gün, onları yazan kişiye ulaşamadığınız gündür.
Bunun neden pazarlık konusu olmadığını aritmetik gösteriyor. Düzgün bir devir paketi hazırlamak proje sonunda 8 ile 16 saatlik bir iştir; oysa böyle bir paket olmadan devralan yeni bir ekip, tek bir satırı güvenle değiştirebilmek için sistemi okumaya 40 ile 120 saat harcar. Devir teslim üzerine yazdıklarımız bu listeyi sözleşmeye nasıl ekleyeceğinizi de anlatıyor.
Yedekleme ve Güvenlik Birer Abonelik, Tek Seferlik Alım Değil
Her yedekleme politikasının arkasında, kısaltmasız hâliyle, iki soru vardır: ne kadarlık işi kaybetmeyi göze alabilirsiniz ve ne kadar süre kapalı kalmayı göze alabilirsiniz. Çoğu işletme için cevaplar "bir günlükten fazlasını değil" ve "birkaç saatten fazlasını değil" olur, bu da pratikte günlük otomatik yedek artı ana sunucunun dışında tutulan bir kopya demektir.
En önemli kural ise şudur: bir yedek, biri onu geri yükleyene kadar yedek sayılmaz. Bu yüzden üç ayda bir gerçek bir geri yükleme denemesi yapın. 5 GB altındaki bir veritabanını geri yüklemek genellikle 10 ile 40 dakika sürer, ama başka ekiplerden devraldığımız sistemlerde her dört yedekleme işinden yaklaşık biri eksik ya da sessizce başarısız çıkıyor. Yani yedekleme takviminden çok, o takvimin çalıştığını kanıtlayan deneme önemlidir.
Dışarıdan gelen kod parçalarını da bakkal hesabıyla anlatalım. Normal bir web uygulaması, dolaylı olanlar da sayıldığında 300 ile 1.200 arası dış kod parçası taşır. Bir yıl içinde bunların 5 ile 20 tanesinin güvenlik güncellemesi isteyeceğini, 1 ile 3 tanesinin ise 24 ile 72 saat içinde yamanması gerektiğini bekleyin; geri kalanı planlı bakım gününe kalabilir.
Gerçek ihlallerin çoğu ise koddan değil insandan başlar, dolayısıyla üç basit alışkanlığı listenize alın: her yönetici hesabı için iki adımlı girişi açın, işten ayrılan personelin hesabını ayrıldığı gün kapatın ve kimde yönetici yetkisi olduğunu yılda iki kez gözden geçirin. Bu üçü için siber güvenlik tarafında bir uzman gerekmez, düzenli bir alışkanlık yeter; yedekleme denemeleriyle birlikte aynı çeyreklik takvime koyabilirsiniz.
Müdahale Süreleri: Ne İsteyin, Neye Para Vermeyin
Öncelik seviyelerini teknik dille değil kendi işinizin diliyle tanımlayın; yani kritik dediğinizde "ödeme sayfası çalışmıyor" gibi parayı durduran bir şeyi kastedin, önemli dediğinizde "günlük rapor yanlış sütunu gösteriyor" gibi işin yürüdüğü ama yanlış yürüdüğü bir durumu, düşük öncelikli dediğinizde de "bir düğme iki piksel kaymış" gibi haftaya rahatlıkla kalabilecek görsel bir ayrıntıyı.
Sözleşmeye yazılabilecek gerçekçi hedefler şunlardır: parayı durduran her şey için bir saat, önemli bir sorun için dört saat ya da aynı iş günü, görsel düzeltmeler için iki ile üç iş günü. Bu süreler sorunun çözülme süresi değil, birinin işe başlama sözüdür ve sözleşmede bu ayrımın açıkça yazılı olması ileride çok tartışma önler.
Çoğu okurun almaması gereken şeyi de açıkça söyleyelim. Yirmi dört saat kesintisiz kapsama, mesai saatleri kapsamasının genellikle 2,5 ile 3 katına mal olur, çünkü arkasında en az üç kişilik bir nöbet düzeni gerekir. Akşam altıda kapanan bir klinik için doğru alım, mesai saatleri kapsaması artı hafta sonu için bir acil telefon numarasıdır; gecenin üçünde birinin sizin için uyanık beklemesine para vermek o klinikte boşa gider.
Desteği gerçekten çalıştıran iki şey vardır ve ikisi de bedavadır: her iki tarafta birer isimli sorumlu ve tek bir anlaşılmış kanal. Destek kişisel sohbetlere ve üç ayrı telefon numarasına dağıldığı anda sonuç hep aynı olur, kimse sorumlu değildir.
Kullanımı Belirleyen Küçük Değişiklikler
Projenin geri dönüşünü belirleyen asıl mesele burasıdır. Personelin çalışma biçimine direnen bir yazılım sessizce terk edilir ve kimsenin kullanmadığı bir sistemin barındırma faturası, herkesin sevdiği bir sistemin faturasıyla aynıdır. Yani kullanılmayan sistem ucuz değildir, sadece karşılığını vermez.
İlk yılın tipik şekli şudur: 30 ile 60 arası değişiklik talebi gelir, ama bunların yalnızca 10 ile 15 tanesi sistemin ne kadar kullanıldığını gerçekten değiştirir. Bu yüzden üç ayda bir ayrılan 10 ile 20 saatlik bir değişiklik bütçesi, doğru taleplere harcandığı sürece gerçekten önemli olanların çoğunu karşılar.
Ölçmeniz gereken şeyler de zaten bildiğiniz sayılardır: her hafta kaç personelin giriş yaptığı, kaç kayıt oluşturulduğu ve sık yapılan bir işin eski yönteme göre şimdi kaç dakika sürdüğü. Bu üç sayı, hangi talebin gerçekten iyileştirme olduğunu, hangisinin sadece alışkanlık olduğunu size tedarikçinizden daha net söyler.
Bir de altıncı haftada kısa bir eğitim tekrarı ve yeni personel için iki sayfalık bir kılavuz isteyin, çünkü ikinci aydaki destek taleplerinin çoğu aslında hata değildir; bir kez gösterilmiş ve unutulmuş işlerdir. Yayına alındıktan sonra iyileştirilen sistemlerin nasıl göründüğünü merak ederseniz örnek çalışmalarımıza göz atabilirsiniz.
Ucuz Seçeneğin Doğru Olduğu Durumlar
Güveni asıl kazandıran bölüm burasıdır, o yüzden açık konuşalım. Beş kişinin kullandığı, oturmuş ve nadiren değişen bir iç araç için yılda 3.600 dolar civarında hafif bir idame planı doğru alımdır; bunun üstündeki her şey o iş için israftır ve size satmayız.
Özel sistemin bir parçasını hazır bir ürünle değiştirmek gerçekten daha iyi olduğunda bunu öneririz. Muhasebe ve e-posta pazarlaması bunun en yaygın iki örneğidir, çünkü o alanlarda hazır ürünler yıllardır olgunlaşmıştır. Böylece özel kalan kısım küçük kalır ve küçük kalan bir sistemin bakımı da doğal olarak ucuz olur.
Peki ne zaman daha az değil daha çok harcamak gerekir? İçinden gelir geçen, hasta kaydı veya ödeme bilgisi gibi düzenlemeye tabi veri tutan ya da doğrudan müşterinin karşısına çıkan her sistem düzgün bir kapsamayı hak eder, çünkü orada kötü geçen tek bir günün maliyeti bir yıllık bakımdan büyüktür.
Son olarak pahalı bir refleksten sakının. Bir sistem eskimiş hissettirdiğinde çoğu zaman 20 ile 40 saatlik bir iyileştirme, baştan yazmaktan daha iyi sonuç verir; baştan yazmak ancak eski sistemi ayakta tutmanın yıllık maliyeti yenisini yapmanın maliyetini aştığında masaya gelmelidir. Linkysoft'ta küçük seçeneğin doğru olduğu durumlarda bunu söylemeyi işimizin bir parçası sayıyoruz, çünkü bir müşterinin ikinci projesi ancak birincisi kazandırdığında olur.
İlk On İki Ayınız ve Sözleşmeye Yazılacak Beş Madde
Takip etmesi kolay bir ritim önerelim: ilk dört hafta yoğun kapsama, ikinci ayda eğitim tekrarı ve ilk toplu düzeltme paketi, üçüncü ayda ilk gerçek geri yükleme denemesi ve ilk küçük iyileştirmeler, altıncı ayda dış kod ve hız gözden geçirmesi, dokuzuncu ayda yol haritası konuşması, on ikinci ayda ise yenileme görüşmesiyle birlikte motor ve işletim sistemi sürümlerinin kontrolü.
Sözleşmede ısrar etmeye değer beş madde ise şunlardır:
- Her iki tarafta isimli birer sorumlu.
- Öncelik seviyesine göre yazılı müdahale süreleri.
- Ne yapıldığını gösteren kısa bir aylık rapor.
- Kullanılmayan saatlerin sonraki aya devredip devretmediği.
- Tam devir teslimi de içeren bir çıkış maddesi.
Kapanışı kendi cümlemizle yapalım: soru hiçbir zaman sistemin bakıma ihtiyacı olup olmadığı değildir, çünkü vardır. Soru, bu sorumluluğun kimde olduğu ve buna ne kadar ayırmaya karar verdiğinizdir.
Elinizdeki sistemi, kaç kişinin kullandığını ve şu anda kime baktığını kısaca anlatırsanız, Linkysoft ekibi olarak size gerçekçi bir yıllık rakam çıkarır ve dört seçenekten hangisinin sizin durumunuza uyduğunu birlikte konuşuruz; bunun için bize ulaşın. Karar vermeden önce biraz daha okumak isterseniz, yayın sonrası destek üzerine yazdıklarımızın tamamı blogda duruyor.
