Yazılım

İşleyişi ekranlara dökmeden önce yazıya geçirmek

Bir talebin toplantıda anlatılan hâli ile masada fiilen yürüyen hâli çoğu kurumda birbirinden ayrılır. Özel yazılım kararı alınmadan önce bu ayrımın nerede başladığını görmek gerekir; hangi kaydın hangi soruyla açıldığı, kimin onayıyla ilerlediği ve hangi aşamada beklemeye geçtiği bilinmeden çizilen ekranlar kullanımda karşılık bulmaz. İlk konuşma bu nedenle araçlar üzerine değil, işin kendi mantığı üzerine kurulur.

Çalışmaya başlarken eldeki defterleri, tabloları ve yazışmaları gerçek bir iş gününün akışıyla yan yana koyuyoruz. Görüşmeleri Elazığ ve çevresindeki işletmelerle yürütürken, tek satırlık görünen bir işlemin arkasında kaç kişinin sırayla devreye girdiğini, hangi bilginin iki ayrı yerde ayrı ayrı tutulduğunu ve hangi adımın sürekli başa döndüğünü not ediyoruz. Anlatılan ile kayda geçen arasındaki fark da bu aşamada görünür oluyor.

Akış kâğıda döküldüğünde hangi bölümün önce geliştirileceği tartışma konusu olmaktan çıkar. Elle verilmesi gereken kararlar ile sistemin kendi başına tamamlayabileceği adımlar birbirinden ayrıldığı için, sonradan gelen istekler kurulu yapıyı zorlamaz. Bu ayrım yapılmadan başlanan işlerde ise her yeni talep, daha önce yazılmış bölümlerin sökülüp yeniden kurulmasını gerektirir ve takvim her defasında geriye kayar.

Yetkiyi kişinin üstlendiği işe göre tanımlamak

Yetki konusu çoğunlukla bir unvan listesiyle çözülmeye çalışılır; oysa belirleyici olan kişinin gün içinde fiilen hangi kararı verdiğidir. Aynı kaydı biri yalnızca okur, biri düzeltir, bir başkası kapatıp muhasebeye gönderir. Bu üç işlem tek bir yetki başlığında toplandığında, sonradan yaşanan yanlış girişlerin kaynağını bulmak ciddi biçimde güçleşir.

Bu yüzden erişim sınırlarını unvandan değil, üstlenilen sorumluluktan çıkarıyoruz. Vardiya devrinde devreye giren kullanıcı, kısa süreliğine dışarıdan bağlanan bir iş ortağı ve yalnızca dönem sonu özetini okuyan yönetici için birbirinden ayrı çerçeveler tanımlanıyor. Konulan her sınırın gerekçesi de aynı belgede duruyor; ileride biri değişiklik istediğinde tartışma sıfırdan başlamıyor.

Sınırın belirgin olması ekibin işini yavaşlatmaz, karar verirken duraksamayı ortadan kaldırır. Ekranında yalnızca kendi işine ait seçenekleri gören kullanıcı yanlış yere kayıt açmaz, yeni katılan personel de birkaç gün içinde düzene alışır. Bir aksaklık yaşandığında işlemi kimin hangi yetkiyle yaptığı kayıtlardan okunabildiği için konu kişisel bir tartışmaya dönüşmez.

Bilgi alanları için ortak bir tanım listesi kurmak

Raporların birbirini tutmaması çoğu zaman hesaplama hatasından değil, aynı bilginin her bölümde başka adla tutulmasından doğar. Stok kodunu bir ekip harflerle, diğeri yalnızca rakamla yazdığında iki liste eşleşmez; ölçü birimi kimi kayıtta adet, kimisinde kutu olarak girildiğinde toplamlar anlamını yitirir. Bu tür sapmalar ekranda değil, alanın karşılığı hiç tanımlanmadığı için ortaya çıkar.

Bu nedenle geliştirmeye geçmeden önce bütün alanları tek bir belgede topluyoruz; her birinin karşılığı, kabul edeceği biçim, zorunlu olup olmadığı ve hangi bölümün onu güncellemekle yükümlü olduğu tek tek yazılıyor. Tartışmanın veri girişi başlamadan bitmesi, sonradan binlerce kaydı elle düzeltme işini gündemden çıkarıyor ve raporlara duyulan güveni baştan sağlıyor.

Tanımlar yerine oturduğunda yeni bir döküm istendiğinde veriyi yeniden toplamak gerekmez; farklı ekranlar aynı kaynaktan okuduğu için sayılar kendiliğinden birbirini doğrular. İleride eklenecek bir alan da yapıyı baştan kurmayı zorunlu kılmaz, açılmış düzenin içine yerleşir. Böylece büyüme, her seferinde yeni bir düzeltme turu anlamına gelmez.

Onay basamaklarını ekibin gözü önünde tutmak

Bir talebin kimde beklediği bilinmiyorsa, gecikmenin nedeni de tartışmalı kalır. Özel yazılım kurgusunda onay basamakları ekranın görünür bir yerinde durur; hangi kaydın kimin masasında olduğu, ne zamandır orada beklediği ve sıradaki adımın kime düştüğü sorulmadan anlaşılır. Telefonla arayıp durumu öğrenme alışkanlığı da böylece kendiliğinden azalır.

Basamakları kurarken mevcut düzeni olduğu gibi aktarmıyor, önce gereksiz halkaları ayıklıyoruz. Yalnızca bilgi amacıyla eklenmiş bir onay adımı süreci uzatmaktan başka işe yaramaz; buna karşılık tutarı ya da teslim tarihini değiştiren bir işlem, kimin uygun gördüğü yazılmadan geçilmemelidir. Bu ayrımı birlikte yapıyor, çıkan sonucu yazılı bir kurala dönüştürüyoruz.

Görünür bir onay zinciri, iş hacmi arttığında en çok karşılığı olan bölümdür. Bekleyen kayıtların nerede biriktiği tabloya bakılarak anlaşıldığı için darboğaz ay sonunda değil oluştuğu gün fark edilir. Sorumluluğun kimde kaldığı da kayıttan okunduğundan, geçmişe dönük incelemeler uzun yazışmalara gerek kalmadan kısa sürede kapanır.

Bildirimi doğru kişiye ve doğru anda ulaştırmak

Sık gelen bildirim bir süre sonra okunmaz hâle gelir; geç gelen bildirim ise zaten işe yaramaz. Bu yüzden hangi olayın kime haber verileceğini tek tek kararlaştırıyoruz. Stok belli bir seviyenin altına indiğinde satın almadan sorumlu kişi, ödeme günü yaklaşan kayıtlarda muhasebe uyarılıyor; herkese aynı anda giden toplu uyarılardan kaçınılıyor.

Bildirimin hangi yoldan gideceği de içeriğine göre ayrılıyor. Günlük akışın içinde kalan hatırlatmalar uygulamada birikiyor, gecikmesi maliyet doğuracak durumlar ise doğrudan kullanıcının telefonuna düşüyor. Kurulan her uyarının bir karşılığı bulunuyor; okunduğunda ne yapılması gerektiği belli olmayan mesajlar en baştan kurguya alınmıyor.

Uyarıların dozu tutturulduğunda ekibin uygulamaya duyduğu güven artar. Bir bildirim geldiğinde gerçekten bakılması gereken bir durum olduğu bilindiği için tepki süresi kısalır. Zamanla hangi uyarının işe yaradığı da ölçülebilir hâle gelir ve karşılığı kalmayanlar, kimseyi rahatsız etmeden sessizce kapatılır.

Sahadaki kullanımı gerçek koşullara göre kurmak

Uygulamanın masa başında çalışması yetmez; kaydın açıldığı yer çoğu zaman depo koridoru, araç içi ya da müşteri masasıdır. Küçük ekranda tek elle doldurulamayan bir form, bağlantının zayıfladığı anda kaybolan bir giriş veya güneş altında okunamayan bir yazı, en doğru kurulmuş akışı bile kullanılmaz hâle getirir.

Bu nedenle saha ekranlarını ayrıca ele alıyoruz. Doldurulacak alan sayısı en aza indiriliyor, sık kullanılan seçenekler başa alınıyor ve bağlantı koptuğunda kayıt cihazda bekletilip şebeke döndüğünde gönderiliyor. Denemeleri benzetim ortamında değil, ekibin gün içinde gerçekten kullandığı cihazlarla, işin yapıldığı yerde yapıyoruz.

Saha tarafı oturduğunda bilgi ofise akşam değil, işin yapıldığı anda ulaşır. Kaydın sonradan deftere geçirilmesi beklenmediği için ikinci kez veri girişi ortadan kalkar; aradaki kopyalama hataları da kendiliğinden kapanır. Yöneticinin ekranında gördüğü tablo, geçmiş günün özeti değil o anki durumu gösterir.

Dış sistemlerle bağlantıyı denetimli biçimde kurmak

Bir uygulama nadiren tek başına çalışır; muhasebe programı, kargo firması, ödeme sağlayıcısı ya da resmî bir servis er geç devreye girer. Özel yazılım projelerinde bu bağlantıların her biri ayrı bir sorumluluk alanıdır, çünkü karşı taraftaki küçük bir değişiklik kendi tarafımızda hemen görünmeyen bir aksamaya yol açabilir.

Bağlantıyı kurmadan önce dört soruyu yanıtlıyoruz: veri hangi yöne akacak, ne sıklıkla taşınacak, karşı taraf yanıt vermezse ne yapılacak ve kimlik nasıl doğrulanacak. Yanıt alınamayan istekler kuyrukta bekletiliyor, yeniden deneme sayısı sınırlanıyor ve başarısız her deneme kaydediliyor. Böylece dışarıdaki bir arıza, içerideki işleyişi durdurmuyor.

Karşı tarafta belgelenmiş bir erişim noktası yoksa aktarımın dosya üzerinden yürüdüğü daha sade bir yol kuruluyor. Bu düzeni kurarken muhatabın Elazığ’da mı yoksa başka bir şehirde mi bulunduğu belirleyici olmuyor; önemli olan erişimin tanımlı ve denetlenebilir olması. Hangi çözüm seçilirse seçilsin, bağlantının ne zaman neyi taşıdığı kayıt altına alınıyor.

Hata kayıtlarını okunabilir ve izlenebilir tutmak

Hata kaydı, bir aksaklık yaşandığında başvurulacak tek güvenilir kaynaktır. Ancak yalnızca teknik satırlardan oluşan bir günlük dosyası kimseye yardımcı olmaz. Kaydın hangi kullanıcı tarafından, hangi ekranda ve hangi işlem denenirken oluştuğu yazılmıyorsa, sorunun kendiliğinden yeniden görülmesini beklemekten başka yol kalmaz.

Bu yüzden hata kayıtlarını iki katmanlı tutuyoruz. Kullanıcıya ne olduğunu ve ne yapması gerektiğini anlatan sade bir açıklama gösteriliyor; arka tarafta ise işlemin numarası, zamanı ve izlediği yol ayrıntısıyla saklanıyor. Destek tarafına bir çağrı ulaştığında tek bir numara üzerinden olayın tamamı geriye doğru izlenebiliyor.

Kayıtların düzenli okunması, henüz şikâyete dönüşmemiş sorunları da ortaya çıkarır. Aynı ekranda tekrarlayan bir uyarı çoğu kez kullanıcının anlamadığı bir alana işaret eder ve buradan çıkan küçük düzeltme ileride bir arızayı önler. İzleme bu nedenle yayından sonra kapatılan değil, sürekli açık kalan bir çalışma olarak planlanır.

Oturum ve erişim güvenliğini senaryoyla sınamak

Güvenlik, giriş ekranına parola koymakla bitmez. Oturumun ne kadar açık kalacağı, aynı hesabın iki cihazdan aynı anda kullanılıp kullanılamayacağı, paylaşılan bir bilgisayarda çıkış yapılmadığında ne olacağı ve görevinden ayrılan bir kullanıcının erişiminin hangi adımlarla kapatılacağı baştan karara bağlanır. Bunlar yazılmadığında sorumluluk kişilerin dikkatine bırakılmış olur.

Bu kararları yazmakla yetinmiyor, yayından önce senaryolarla deniyoruz. Yetkisi olmayan bir kullanıcının adres satırını değiştirerek başka bir kayda ulaşıp ulaşamadığı, süresi dolmuş bir oturumun işlem yapıp yapamadığı ve kapatılan bir hesabın açık kalmış bağlantılarının düşüp düşmediği tek tek sınanıyor. Çıkan sonuçlar yazılı bir rapora dönüştürülüyor.

Denemeler tamamlandığında ortaya bir kereye mahsus kontrol değil, sürdürülebilir bir alışkanlık çıkar. Yeni bir ekran eklendiğinde aynı sorular yeniden sorulur; böylece güvenlik, proje sonunda bir kez bakılan başlık olmaktan çıkıp her geliştirmenin doğal parçası hâline gelir ve maliyeti de küçük kalır.

Yedekleme ve geri dönüş planını önceden hazırlamak

Yedeğin varlığı tek başına bir güvence sayılmaz; asıl soru, gerektiğinde ne kadar sürede geri dönülebildiğidir. Özel yazılım teslimlerinde yedeğin hangi sıklıkla alındığı, nerede saklandığı, ne kadar süre tutulduğu ve geri yükleme işleminin kimin sorumluluğunda olduğu yazılı olarak belirlenir. Bu satırlar olmadan hazırlık yalnızca niyet düzeyinde kalır.

Planın işe yarayıp yaramadığı ancak denenerek anlaşılır. Bu nedenle yedekten dönüş provası ayrı bir ortamda yapılıyor, geçen süre ölçülüyor ve hangi verinin kurtarılamadığı açıkça not ediliyor. Prova yapılmadan verilen her süre tahmini, gerçek bir aksaklık anında karşılık bulmaz ve beklentiyi olduğundan iyimser gösterir.

Aynı çalışma içinde hangi kaybın kabul edilebilir olduğu da konuşulur. Birkaç saatlik bir boşluğu taşıyabilen bir iş ile tek bir işlemi bile kaybetmemesi gereken bir iş aynı çözümle korunmaz. Beklenti netleştiğinde yedekleme sıklığı, saklama yöntemi ve maliyeti buna göre kurulur; gereğinden ağır bir düzen kimseye yük olmaz.

Sürüm değişikliklerini denetimli biçimde yayımlamak

Çalışan bir uygulamaya yapılan her ekleme, halihazırda yürüyen işi etkileme ihtimali taşır. Bu yüzden değişiklikler doğrudan canlı ortama alınmaz; önce ayrı bir kopyada denenir, ilgili kullanıcıya gösterilir ve onayı alındıktan sonra yayımlanır. Yayın saati de yoğunluğun en düşük olduğu zaman aralığına bırakılır.

Her yayının neyi değiştirdiği kısa bir notla kayda geçiyor. Böylece bir aksaklık yaşandığında hangi değişiklikten sonra başladığı tahmin edilmiyor, doğrudan görülüyor. Geri alma yolu da aynı anda hazırlanıyor; sorun büyümeden önceki sürüme dönmek mümkün oluyor ve ekip gece yarısı çözüm aramak zorunda kalmıyor.

Değişikliklerin küçük parçalar hâlinde ilerlemesi hem denemeyi kolaylaştırır hem de ekibin alışmasını hızlandırır. Aylarca biriktirilip tek seferde açılan bir güncelleme, kullanıcı açısından tanımadığı bir uygulamaya geçmek anlamına gelir. Aralıklarla ilerleyen düzende ise her adım öncekinin üzerine oturur ve eğitim ihtiyacı kendiliğinden azalır.

Eğitim ve teslim kayıtlarını eksiksiz bırakmak

Bir uygulamanın gerçekten kullanılır hâle gelmesi teslim gününde değil, ekibin onu kendi işine yerleştirdiği haftalarda anlaşılır. Özel yazılım çalışmasının son aşaması bu nedenle yalnızca dosyaların ve şifrelerin devri değil, günlük işin yeni düzene taşınmasıdır. Bu geçiş planlanmadığında en iyi kurulmuş uygulama bile eski alışkanlıkların yanında kullanılmadan kalır.

Eğitimi tek bir toplantıya sığdırmıyoruz. Her bölümün kendi ekranları üzerinden ayrı oturum yapılıyor, sık karşılaşılacak durumlar canlı örnekle gösteriliyor ve sorular biriktikten sonra ikinci bir görüşme planlanıyor. Oturumlar Elazığ’daki ekiple yüz yüze yürütülebildiği gibi, farklı şehirlerde bulunan kullanıcılar için çevrim içi de yapılabiliyor.

Teslim dosyasında ise uygulamanın nerede çalıştığı, hangi hesaplarla bağlandığı, yetkilerin nasıl verildiği ve olağan bakım işlerinin hangi adımlarla yapılacağı yazılı olarak bulunur. Bu kayıt eksiksiz tutulduğunda ilerleyen yıllarda işi kimin sürdüreceği sorusu belirsizliğe dönüşmez; devralan kişi neyi nereden bulacağını ilk günden bilir.

Yazılım Çalışması Hakkında Sık Sorulan Sorular

Hazır programlar yaygın ihtiyaçları ortak bir kalıpla karşılar ve pek çok iş için yeterlidir. Ayrım, işin o kalıba sığmayan adımlarında başlar: kendine özgü bir onay sırası, standart dışı bir yetki ihtiyacı, farklı sistemler arasında kurulacak bir bağlantı ya da hazır dökümlerle çıkarılamayan bir hesaplama varsa özel yazılım anlamlı hâle gelir. Karar beğeniyle değil, bu farkın büyüklüğüyle verilir.

Takvimi belirleyen şey ekran sayısı değil, kararların iç içe geçme derecesidir. Roller, iş kuralları, bağlanılacak sistemler ve sınanması gereken durumlar çıkarıldıktan sonra iş parçalara ayrılır ve her parçaya ayrı bir süre verilir. Kapsam yolda genişlerse takvim yeniden kurulur; bu yeniden hesap sözlü olarak değil yazılı olarak paylaşılır.

Karşı taraf belgelenmiş ve denetimli bir erişim noktası sunuyorsa bağlantı kurulabilir. Çalışmaya başlamadan önce verinin hangi yöne akacağı, hangi sıklıkla taşınacağı, yanıt gelmediğinde nasıl davranılacağı ve kimliğin nasıl doğrulanacağı yazılır. Böyle bir erişim yoksa dosya aktarımına dayanan daha sade bir yöntem kurulur ve bu yöntemin sınırları baştan aktarılır.

Devir biçimi sözleşmede açıkça yazılır. Uygulamanın çalışacağı sunucunun, alan adının ve kullanılan üçüncü taraf hesaplarının kimin adına açılacağı işe başlamadan netleştirilir. Bu konunun sonraya bırakılması, ilerleyen dönemde yaşanan erişim sıkıntılarının en sık nedenidir. Sahiplik baştan belirlendiğinde ise devir gününde ayrıca bir pazarlık gerekmez.

Yayın sonrası iş tek bir başlık altında toplanmaz. Arıza giderme, güvenlik güncellemelerinin uygulanması, sistemin izlenmesi ve yeni işlev eklenmesi birbirinden ayrı kalemlerdir; hepsi aynı torbaya konduğunda beklenti bulanıklaşır. Hangi kalemin hangi sürede karşılanacağı baştan yazılırsa, sonradan yaşanan anlaşmazlıkların çoğu doğmadan kapanır.

Yapı, beklenen kullanım yoğunluğu ve veri birikimi hesaba katılarak kurulur. Sorgu süreleri, aynı anda bağlanan kullanıcı sayısı ve depolama artışı belirli aralıklarla ölçülür; büyüme kararları tahmine değil bu ölçümlere dayanır. Sınıra yaklaşıldığında kaynak artırımı veya yapısal iyileştirme ayrı bir çalışma olarak ele alınır.