Yazılım teslim alırken elinizde tam olarak ne olmalı

Bir yazılım projesi bitti denildiğinde size teslim edilmesi gereken şey ekranda çalışan sistem değil, o sistemi bugünkü yazılımcı olmadan da yaşatabilecek malzemedir. Bu malzemenin çekirdeği sekiz kalemdir: kaynak kod ve nerede durduğu, sunucu ile alan adı erişimlerinin kimin adına kayıtlı olduğu, veritabanının alınabilir bir yedeği, kurulum ve ortam bilgisi, kullanıcı yetki listesi, üçüncü taraf servislerin hesapları, kısa bir kullanım dokümanı ve bilinen açık işler listesi. Bunlar teslim anında istenmezse sonradan istemek her zaman daha zor olur; çünkü teslim anında karşı tarafın da bir beklentisi vardır, sonrasında yalnızca sizin talebiniz kalır. Aşağıdaki liste teknik bir devir listesidir, sözleşme metni değildir; hukuki tarafı için kendi danışmanınızla çalışın.

Teslim edilen şey dosya değil, devam edebilme yeteneğidir

Teslim kelimesi çoğu işletmede yanlış anlaşılıyor. Sisteme giriş yapabiliyorsanız, kullanıcılar çalışıyorsa, raporlar geliyorsa teslim alınmış sayılıyor. Oysa asıl soru şudur: bugün bu projeyi yapan kişiyle yollarınız ayrılsa, yeni bir yazılımcı sıfırdan bakıp devam edebilir mi? Cevap hayırsa teslim tamamlanmamıştır, sadece kullanım başlamıştır.

Aradaki farkı görmenin pratik bir yolu var. Elinizdeki malzemeyle üç şeyi yapabiliyor musunuz diye sorun. Birincisi, sistemin bir kopyasını başka bir sunucuda ayağa kaldırabilir misiniz. İkincisi, veriyi dışarı alabilir misiniz. Üçüncüsü, tüm hesaplarda şifreyi siz değiştirebilir misiniz. Bu üçü sağlanıyorsa teslim gerçek anlamda olmuştur. Biri bile eksikse, sistem çalışıyor olsa da bağımlısınız demektir.

Bu bağımlılık genelde kötü niyetten doğmaz. Çoğu durumda kimse bir şey saklamıyordur; sadece hesaplar işin hızında kimin eli boşsa onun adına açılmıştır, kurulum bilgisi kimsenin aklına yazmak gelmediği için tek kişinin kafasındadır. Sorun, ilişki devam ederken hiç görünmez. Görünür hale geldiği an ise genellikle en kötü andır: yazılımcı ulaşılamaz olduğunda, ekip değiştiğinde ya da sistemde acil bir arıza çıktığında. Bu yüzden teslim listesi bir güven meselesi değil, bir süreklilik meselesidir.

Kaynak kod nerede duruyor ve hesap kimin adına açık

Kaynak kod, yazılımın metnidir. Çalışan sistem bu metinden üretilir. Elinizde çalışan sistem olup kaynak kod olmaması, bir binanın kendisine sahip olup projesine sahip olmamak gibidir; içeride bir şey değiştirmek isteyen herkes duvarı kırarak ilerlemek zorunda kalır.

Kod bugün genellikle bir kod deposunda tutulur; yaygın adlarıyla bir depo hizmetinde. Burada kritik olan kodun varlığı değil, deponun hangi hesabın altında olduğudur. Depo yazılımcının kişisel hesabında duruyorsa ve size sadece davetli olarak erişim verilmişse, o erişim tek tıkla kapatılabilir. Doğrusu, deponun şirketinizin adına açılmış bir kurum hesabında olması ve yazılımcının o hesaba davetli olmasıdır. İlişki bittiğinde davetli çıkar, depo kalır.

Kod teslim edilirken şunu da isteyin: son sürümün sisteme yüklenmiş haliyle aynı olduğunun beyanı. Deponun içindeki kodla sunucuda çalışan kodun farklı olduğu durumlar sık görülür ve bu fark ancak bir sorun çıktığında ortaya çıkar.

Sunucu, alan adı ve üçüncü taraf servis hesapları

Alan adı, yani sitenizin adresi, şirketiniz adına kayıtlı olmalıdır. Kayıt sahibi bilgisi yazılımcının ya da bir ajansın adına ise, adres teknik olarak sizin değildir. Aynı şey sunucu için de geçerlidir: barındırma hesabı sizin adınıza açılmış olmalı, faturası size gelmeli, kök erişim bilgisi sizde bulunmalıdır.

Yanına bir de dışarıdan alınan servisleri koyun. Tipik bir sistemde bunlardan birkaçı vardır: kısa mesaj gönderimi, e-posta gönderimi, ödeme altyapısı, harita servisi, e-fatura entegratörü, yedekleme alanı. Her biri ayrı bir hesap, ayrı bir anahtar, çoğu zaman ayrı bir fatura demektir. Bu hesapların hangi e-posta adresiyle açıldığını sorun. Yazılımcının kendi adresiyle açılmış bir mesaj gönderim hesabı, ilişki bittiğinde en sessiz kırılan yerdir; mesajlar bir gün durur ve nedenini kimse bilmez.

Kullanışlı bir alışkanlık: bu hesapların hepsini şirkete ait ortak bir kurumsal e-posta adresine bağlayın, kişisel adrese değil. Personel değişse de adres kalır.

Veritabanı yedeği ve geri dönüş denemesi

Veri, sistemin en değerli parçasıdır. Yazılım yeniden yazılabilir, veri yeniden yazılamaz. Teslim sırasında veritabanının tam bir yedeğini isteyin ve bu yedeği kendi kontrolünüzdeki bir yere kopyalayın.

Ama yedeği almak yetmez. Yedeğin geri yüklenebildiğini görmek gerekir. Bunu yapmadan alınan yedek, açılıp açılmadığı bilinmeyen bir kutudur. Yazılımcıdan yedeği alıp ayrı bir ortamda geri yüklemesini, sonra da içinden bir müşteri kaydı ve bir fatura kaydı göstermesini isteyin. Bu kısa gösterim, yedeğin gerçekten işe yaradığını kanıtlar.

Yedeğin nasıl alındığını da öğrenin: otomatik mi alınıyor, hangi sıklıkla, nerede duruyor, ne kadar süre saklanıyor. Yedekler sistemle aynı sunucuda duruyorsa, sunucu kaybında yedek de gider. Bunun ayrı bir yerde durması gerekir.

Kurulum ve ortam bilgisi: sistemi sıfırdan ayağa kaldırmak

Kod ve veri elinizde olsa bile, bunları birleştirip çalışır hale getirmek bilgi ister. Bu bilgiye ortam bilgisi denir ve genellikle hiç yazılmaz, çünkü onu yapan kişi zaten biliyordur.

İstemeniz gereken, kısa bir kurulum notudur. İçinde şunlar bulunmalı: sistemin hangi teknolojiyle ve hangi sürümüyle çalıştığı, veritabanının türü ve sürümü, çalışması için gereken ayar dosyaları ve içindeki ayarların ne işe yaradığı, arka planda düzenli çalışan görevler varsa hangileri olduğu, ve yeni bir sürüm yayına alınırken izlenen adımlar.

Ayar dosyalarında servis anahtarları da bulunur. Bunlar teslim edilirken açık metin olarak elden ele dolaşmasın; şifre yöneticisi gibi ortak bir kasada tutmak daha sağlıklıdır. Teslimden sonra bu anahtarların bir kısmını yenilemek de makul bir adımdır.

Kullanıcı yetkileri, kullanım dokümanı ve açık işler listesi

Sistemde kimin neyi görebildiği çoğu işletmede kimsenin elinde yazılı değildir. Teslimde bunu isteyin: rol listesi ve her rolün neye erişebildiği, bir de o an tanımlı kullanıcıların listesi. Bu liste hem güvenlik açısından hem de işten ayrılanların erişimlerini kapatmak açısından gereklidir.

Kullanım dokümanı uzun olmak zorunda değil. Sık yapılan işlerin adımlarını içeren birkaç sayfa, ekran görüntüleriyle, çoğu ihtiyacı karşılar. Amaç kitap yazmak değil, ekipten biri ayrıldığında bilginin de gitmemesidir.

Son olarak açık işler listesi. Hiçbir yazılım eksiksiz teslim edilmez; bilinen kusurlar, ertelenmiş istekler, sonraya bırakılmış kararlar vardır. Bunların yazılı olması kimseyi suçlamak için değil, sonraki kişinin aynı taşa takılmaması içindir. Bu liste teslim sırasında konuşulmazsa, birkaç ay sonra ortaya çıkan her sorun tartışmaya dönüşür.

Açık işler listesini isterken üç ayrı başlık altında toplanmasını isteyin: bilinen hatalar, yapılmasına karar verilip sonraya bırakılan işler, ve konuşulup vazgeçilen istekler. Üçüncüsü çoğu zaman atlanır ama en faydalısıdır; bir isteğin neden yapılmadığı yazılı değilse, aynı istek birkaç ay sonra yeniden gündeme gelir ve baştan tartışılır.

Teslim tutanağı mantığı

Bütün bunları toplayan pratik araç bir teslim tutanağıdır. Karmaşık bir belge değildir: yukarıdaki kalemlerin her biri için tek satır, karşısında teslim edildi ya da edilmedi bilgisi, teslim edilenin nerede durduğu, tarih ve iki tarafın imzası.

Tutanağın asıl faydası imzada değil, hazırlanma sürecindedir. Listeyi doldurmaya çalışırken eksikler kendiliğinden görünür hale gelir. Alan adının kimin adına olduğu, yedeğin gerçekten geri dönüp dönmediği, hangi servisin kimin hesabında açıldığı gibi sorular ancak tek tek yazıldığında sorulur.

Tutanağı proje sonunda değil, proje başında hazırlamak daha da iyidir. Teslimde nelerin isteneceği baştan konuşulmuşsa, hesaplar en baştan doğru adlara açılır ve teslim günü sürpriz olmaz. Sonradan toparlanan bir devir her zaman baştan planlanmış bir devirden daha eksik kalır.

Kısaca

• Teslimin ölçüsü şudur: yeni bir yazılımcı elinizdeki malzemeyle sistemi başka bir sunucuda ayağa kaldırabiliyor mu.
• Kaynak kod deposu, alan adı, sunucu ve tüm üçüncü taraf servis hesapları şirketinizin adına ve kurumsal bir e-posta adresine bağlı olmalı.
• Veritabanı yedeğini almak yetmez; geri yüklendiğinin gösterilmesini isteyin ve yedeğin sistemden ayrı bir yerde durduğundan emin olun.
• Kurulum notu, rol ve kullanıcı yetki listesi, kısa kullanım dokümanı ve bilinen açık işler listesi teslimin ayrılmaz parçasıdır.
• Teslim tutanağını proje sonunda değil başında hazırlayın; asıl faydası imzada değil, eksikleri görünür kılmasındadır.