Yazılım

İş akışını ekran tasarımından önce çözmek

Liman sahası, ocak vardiyası, üretim hattı ve nakliye planı arasında gün boyu bilgi taşıyan kuruluşlarda bir özel yazılım işi, kod yazmakla değil işin kendisini anlamakla başlar. Hangi kaydın kim tarafından açıldığı, hangi adımda beklemeye girdiği ve neden geri döndüğü bilinmeden ekran kararı verilemez. Bu nedenle ilk oturumları Zonguldak’taki işletmelerle tasarım masasında değil, işin fiilen yürüdüğü yerde kuruyoruz.

Başlangıçta güncel kayıtları, sahada yaşanan istisnaları ve çalışanların sık takıldığı belirsizlikleri topluyoruz. Bir işin kaç kez elden geçtiğini, hangi bilginin telefonla sorulduğunu ve hangi adımın hâlâ kâğıt üzerinde kaldığını not alıyoruz. Bu döküm, sonradan tartışmaya açılacak kapsamı baştan daraltır; geliştirme başladığında herkesin aynı akışı konuştuğundan emin oluruz.

Yayın öncesinde akışın tamamını gerçek kullanım örnekleriyle deniyoruz; bağlantıları, ekrandaki metinleri, telefonda ortaya çıkan davranışı ve yönetim tarafındaki görevleri tek tek yürütüyoruz. Böylece ortaya çıkan düzen, yeni bir ürün grubu eklendiğinde veya ekip büyüdüğünde baştan kurulmak zorunda kalmaz; üzerine eklenerek ilerler.

Rolleri gerçek sorumluluk sınırına oturtmak

Yetkilendirme çoğu projede sona bırakılır ve herkese geniş erişim vermek pratik bir çözüm gibi görünür. Oysa vardiya sorumlusunun gördüğü ekranla muhasebe biriminin gördüğü ekranın aynı olması, hem yanlış kayıt riskini hem de sorumluluğun kimde olduğu tartışmasını büyütür. Rol tanımını bu yüzden işin kendi sorumluluk sınırından çıkarıyoruz.

Önce kimin hangi kaydı açtığını, kimin değiştirdiğini ve kimin kapattığını yazıyoruz. İzin verilen kadar izin verilmeyen durumları da aynı ayrıntıyla tarif ediyoruz: bir kullanıcı kendi vardiyası dışındaki kaydı görebilir mi, gördüğü kaydı düzeltebilir mi, dışa aktarabilir mi. Bu sorulara baştan yanıt verilmediğinde yetki düzeni zamanla dağılır.

Yayına almadan önce her rolü ayrı hesapla deniyoruz; bir kullanıcının görmemesi gereken bir bağlantıya adres çubuğundan ulaşıp ulaşamadığını da sınıyoruz. Yapı böylece kâğıt üzerinde değil, çalışan sistemde doğrulanmış olur ve ekip büyüdüğünde yeni kişi tanımlamak dakikalık bir iş hâline gelir.

Veri alanlarını ortak bir sözlükte buluşturmak

Aynı bilgiyi farklı birimlerin farklı adla tutması, özel yazılım projelerinde çok zaman kaybettiren sorunlardan biridir. Sevkiyat tarafında “yükleme tarihi” denen alan, planlama tarafında “çıkış günü” olarak geçer; raporda iki sütun birden görünür ve hangisinin doğru olduğu tartışılır. Bu yüzden alan adlarını tek bir tanım üzerinde uzlaştırıyoruz.

Her alan için tipini, zorunlu olup olmadığını, hangi ekranda girildiğini ve hangi raporu beslediğini kayda alıyoruz. Ölçü birimi, tarih biçimi ve yaygın kısaltmalar da aynı kayda giriyor. Sözlük hazırlandığında veri girişi sadeleşir; sonradan istenen bir rapor için mevcut kayıtları toptan düzeltme ihtiyacı büyük ölçüde ortadan kalkar.

Tanımları gerçek kayıtlarla sınıyoruz: eksik doldurulmuş eski satırlar, beklenmedik karakterler ve iki ayrı biçimde girilmiş tarihler önce raporlanıyor. Düzeltme kuralı kararlaştırıldıktan sonra aktarım yapılıyor. Böylece yeni düzen, devralınan hatalı alışkanlıkları da beraberinde taşımıyor.

Onay basamaklarını ekibe görünür kılmak

Bir talebin nerede beklediğini kimse bilmiyorsa süreç hızlanmaz; yalnızca telefon trafiği artar. Onay zincirini ekrana taşımanın amacı bürokrasi kurmak değil, bekleyen işin sahibini görünür kılmaktır. Kaç basamak olacağı da işin riskine göre belirlenir; her kaydın üst yönetime kadar çıktığı bir düzen çoğu işletmede gereksiz yavaşlama üretir.

Hangi tutarın, hangi miktarın veya hangi istisnanın onay gerektirdiğini işletmeyle birlikte yazıyoruz. Onaycının izinli olduğu günlerde ne olacağı, vekâletin nasıl devredileceği ve reddedilen bir kaydın hangi aşamaya döneceği de baştan tanımlanıyor. Bu ayrıntılar atlandığında sistem, ilk yoğun haftada elle yürütülen eski düzene geri döner.

Kurgu tamamlandıktan sonra zinciri baştan sona örnek kayıtlarla yürütüyoruz; reddedilen, geri çekilen ve süresi geçen durumları ayrı ayrı deniyoruz. Onay geçmişi kayıtta kaldığı için sonradan gündeme gelen “bunu kim geçirdi” sorusu hafıza yerine belge üzerinden yanıtlanır.

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

Bildirim kurgusu genellikle iki uçta hata verir: ya kimse haberdar olmaz ya da herkese her şey gider. İkincisi daha sinsidir, çünkü bir süre sonra ekip bildirimleri okumadan kapatmaya başlar ve gerçekten önemli olan uyarı da aynı yığında kaybolur. Bu yüzden kimin neyi bilmesi gerektiğini tek tek çıkarıyoruz.

Her uyarı için tetikleyen olayı, alıcısını, kanalını ve tekrar sıklığını tanımlıyoruz. Gece vardiyasında düşen bir uyarının sabah da görülebilmesi, kapanmış bir işin uyarı üretmeyi bırakması ve aynı olayın art arda beş bildirim doğurmaması gibi durumlar ayrıca ele alınıyor.

Devreye almadan önce bildirimleri deneme ortamında çalıştırıyor, ulaşmayan ya da yanlış kişiye giden örnekleri düzeltiyoruz. Yayından sonra hangi uyarının gerçekten işe yaradığını ekibe soruyoruz; karşılık bulmayan bildirimler kapatılıyor, çünkü okunmayan bir uyarı sistemin güvenilirliğini zamanla aşındırır.

Saha koşullarını mobil kullanımda karşılamak

Sahada kullanılacak bir özel yazılım, masa başında denenen bir arayüzle aynı ölçütlerle değerlendirilemez. Eldivenli parmak, güneş altında sönük görünen ekran, dalgalanan bağlantı ve telefonu tek eliyle tutan bir kullanıcı; hepsi tasarım kararını doğrudan etkiler. Bu koşulları varsayım olarak değil, sınanacak birer durum olarak ele alıyoruz.

Dokunma alanlarını büyütüyor, sık kullanılan işlemi ilk ekrana alıyor ve giriş sayısını azaltıyoruz. Bağlantı kesildiğinde girilen verinin kaybolmaması için kaydın cihazda tutulup bağlantı döndüğünde gönderilmesi gibi davranışlar önceden kararlaştırılıyor. Hangi işlemin sahada, hangisinin ofis tarafında yapılacağı da ayrı ayrı belirleniyor.

Denemeyi gerçek cihazlarla yapıyoruz; küçük ekranlı eski bir telefon da sınama kapsamına giriyor. Yayın öncesinde bağlantıları, metinleri ve yönetim tarafındaki görevleri aynı cihazlar üzerinden yürütüyoruz. Sahada anlaşılmayan bir ifade varsa, kullanıcıların günlük konuşmasındaki karşılığıyla değiştiriyoruz.

Dış sistem bağlantılarını denetimli kurmak

Muhasebe programı, kantar, takip cihazı veya tedarikçi servisiyle kurulan her bağlantı, sisteme dışarıdan bir bağımlılık ekler. Bu bağımlılığın nasıl davrandığı iyi günde değil, karşı taraf yanıt vermediğinde belli olur. Bağlantıyı kurmadan önce hangi bilginin hangi yöne aktığını ve kesinti anında ne olacağını yazılı hâle getiriyoruz.

Kimlik doğrulama yöntemi, veri yönü, aktarım sıklığı, hata karşılığı ve yeniden deneme davranışı baştan belgeleniyor. Karşı sistem yavaşladığında isteğin kuyruğa alınması, aynı kaydın iki kez işlenmemesi ve tekrar denemenin sonsuz döngüye girmemesi gibi durumlar tek tek kararlaştırılıyor. Belgesiz bir arayüze bağlanmayı ise baştan riskli sayıyoruz.

Bağlantıyı önce deneme ortamında, ardından sınırlı veriyle canlı ortamda sınıyoruz. Aktarılan kayıtları karşı taraftaki karşılıklarıyla eşleştiriyor, tutmayan satırları raporluyoruz. Kesinti yaşandığında hangi kayıtların bekletildiği ve bağlantı döndüğünde bunların nasıl tamamlanacağı da bu denemede görülüyor.

Hata kayıtlarını okunur ve izlenebilir tutmak

Bir sorunu çözmek çoğu zaman onu yeniden üretebilmekle başlar. Kullanıcı “çalışmıyor” dediğinde hangi ekranda, hangi kayıtla ve hangi adımda çalışmadığı bilinmiyorsa geliştirme tarafı tahminle ilerler; harcanan süre de çözümden çok arama işine gider. Bu yüzden hata kaydını en baştan okunabilir biçimde kurguluyoruz.

Her kayıt; zamanı, kullanıcıyı, yapılan işlemi ve hatanın oluştuğu yeri içeriyor. Kullanıcıya gösterilen mesajla teknik ayrıntı birbirinden ayrılıyor: ekranda ne yapması gerektiğini anlatan sade bir açıklama kalırken, ayrıntı kendi kaydına yazılıyor. Kişisel veri içeren alanların bu kayda düşmemesi ayrıca kontrol ediliyor.

Yayın sonrasında bu kayıtları düzenli olarak gözden geçiriyoruz. Tekrarlayan bir uyarı çoğunlukla teknik bir arızadan değil, yanlış anlaşılan bir adımdan doğar; o durumda çözüm kodda değil, ekrandaki ifadede olur. Böylece aynı sorunun birkaç ay sonra yeniden açılmasının önüne geçilir.

Oturum ve yetki güvenliğini senaryoyla sınamak

Güvenlik, yayına alınmadan önce işaretlenip geçilen bir madde değil, belirli aralıklarla tekrarlanan bir sınama işidir. Parola kuralları kadar oturumun ne kadar açık kalacağı, ortak kullanılan bir cihazda çıkışın nasıl yapılacağı ve yetkisi geri alınan bir kullanıcının açık oturumuna ne olacağı da karara bağlanır.

Senaryoları gerçek kullanım üzerinden kuruyoruz: yetkisiz bir hesapla yönetim adresine doğrudan ulaşmayı, başkasının kaydını düzenlemeyi ve dışa aktarma sınırını aşmayı deniyoruz. Vardiya değişiminde aynı bilgisayarın el değiştirmesi gibi durumları da, Zonguldak’ta birlikte çalıştığımız kuruluşların günlük düzenini gözeterek sınama kapsamına alıyoruz.

Sonuçları yazılı hâle getiriyor, kapatılan açıkların hangi sürümle giderildiğini kayda alıyoruz. İşletme tarafında da yönetici hesabının günlük işler için paylaşılmaması ve ayrılan bir çalışanın erişiminin aynı gün kapatılması gibi sorumluluklar netleştiriliyor.

Yedekleme ile geri dönüş planını önceden kurmak

Yedek almak tek başına bir güvence sayılmaz; asıl soru, gerektiğinde o yedekten ne kadar sürede ve hangi kayıp payıyla dönüleceğidir. Denenmemiş bir yedek, olmayan bir yedek gibi davranır. Bu nedenle planı yalnızca kopyalama sıklığı üzerinden değil, geri dönüş süresi üzerinden kuruyoruz.

Hangi verinin ne sıklıkta yedekleneceği, kopyaların nerede tutulacağı, ne kadar süre saklanacağı ve geri yüklemeyi kimin yetkisiyle yapacağı yazılıyor. Yüklenen dosyalar, veri tabanı ve ayar dosyaları ayrı ayrı ele alınıyor; yalnızca birinin kopyalanması çoğu zaman eksik bir kurtarma anlamına gelir.

Geri dönüşü tatbikat olarak deniyoruz: yedek ayrı bir ortama yükleniyor, açılıyor ve kayıtlar karşılaştırılıyor. Deneme sırasında ortaya çıkan eksikler düzeltiliyor. Böylece gerçek bir sorun yaşandığında izlenecek adımlar ilk kez o gün öğrenilmiyor.

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

Çalışan bir sisteme yapılan her ekleme, yürümekte olan bir şeyi bozma ihtimali taşır. Bu ihtimali tamamen ortadan kaldırmak mümkün değildir; yönetilebilir hâle getirmek ise mümkündür. Değişiklikleri küçük parçalar hâlinde, yoğun saatlerin dışında ve geri alınabilir biçimde yayımlıyoruz.

Her sürüm için neyin değiştiği, hangi ekranı etkilediği ve hangi adımların sınanacağı önceden yazılıyor. Yayın öncesinde aynı değişiklik, deneme ortamında gerçek verinin kopyasıyla uygulanıyor. Sorun çıkarsa önceki sürüme nasıl dönüleceği de aynı belgede yer alıyor; bu adım atlandığında geri dönüş kararı baskı altında verilir.

Yayından sonraki ilk saatlerde hata kayıtlarını ve kullanıcı geri bildirimlerini yakından izliyoruz. Acil düzeltme ile planlı geliştirme ayrı kuyruklarda yürüyor; böylece bir hatayı düzeltirken yarım kalmış bir özellik istemeden canlı ortama taşınmıyor.

Eğitim ve teslim kaydını eksiksiz bırakmak

Bir özel yazılım ancak kullanan ekip onu benimsediğinde işe yarar. Devreye alma günü yapılan tek bir toplantı, üç ay sonra işe başlayan bir çalışan için hiçbir şey ifade etmez. Bu yüzden eğitimi tek seferlik bir sunum değil, geride iz bırakan bir aktarım olarak planlıyoruz.

Ekipler kendi rollerine göre ayrı ayrı çalışıyor; herkes günlük işini sistem üzerinde bizzat yapıyor. Sık karşılaşılan işlemler için kısa anlatımlar hazırlanıyor, yönetim tarafındaki görevler ayrı bir oturumda ele alınıyor. Oturumlarda sorulan sorular kayda alınıp anlatımlara ekleniyor.

Teslimde hesapların, erişimlerin, alan adı ve barındırma bilgilerinin kime ait olduğu yazılı olarak netleşiyor. Aynı belgede bakım kapsamının nerede başlayıp nerede bittiğini de aktarıyoruz; böylece Zonguldak’ta hizmet verdiğimiz kuruluşlarda ilerleyen dönemde kimin neyden sorumlu olduğu tartışma konusu olmuyor.

Yazılım Hakkında Sık Sorulan Sorular

Hazır araçlar yaygın ihtiyaçları karşılamak üzere kurgulanır; iş akışı o kalıbın dışına çıktığında zorlama çözümler birikmeye başlar. Kendine özgü onay basamakları, ayrıntılı yetki ayrımı, başka sistemlerle bağlantı veya standart raporlarla alınamayan çıktılar söz konusuysa özel yazılım anlamlı olur. Bu eşiğe karar vermeden önce mevcut araçla ne kadar yol alınabileceğini birlikte değerlendiriyoruz.

Süre, ekran sayısından çok iş kurallarının karmaşıklığına ve kurulacak bağlantı sayısına bağlıdır. Kullanıcı rolleri, ekranlar, kurallar, entegrasyonlar ve sınama senaryoları çıkarıldıktan sonra aşamalı bir takvim oluşturulur. Takvim tek bir teslim tarihi yerine ara teslimlerle ilerler; kapsam değişirse süre de yeniden değerlendirilir.

İlgili program belgelenmiş ve güvenli bir erişim sunuyorsa bağlantı kurulabilir. Verinin hangi yöne akacağı, hangi sıklıkta aktarılacağı, hata durumunda ne olacağı ve hangi yetkinin gerekeceği çalışma başlamadan tanımlanır. Erişim yöntemi belgesiz veya kapalıysa, elle aktarım gibi seçenekler birlikte değerlendirilir.

Teslim biçimi sözleşmede açıkça yazılır. İşletmenin kullanacağı hesaplar, sunucu erişimleri ve kaynakların sahipliği çalışma başlamadan netleştirilir. Bu konu sona bırakıldığında ileride yapılacak bir devir işlemi gereksiz yere karmaşıklaşır.

Hata giderimi, güvenlik güncellemeleri, izleme ve yeni özellik geliştirme ayrı sorumluluklar olarak kurgulanır. İlk üçü süreklilik gerektirir; yeni geliştirme ise kendi planıyla yürür. Kapsamın sınırı ve yanıt süresi baştan yazıldığında, bir sorun çıktığında kimin ne yapacağı tartışma konusu olmaz.

Mimari, beklenen kullanım yoğunluğuna ve veri hacmine göre kurulur. Yayından sonra yanıt süreleri ve kaynak tüketimi izlenir; büyüme kararları bu ölçümlere dayandırılır. Böylece kapasite artışı tahminle değil, görülen ihtiyaca göre planlanır.