Yazılım

Süreci arayüz çizilmeden önce masaya yatırmak

Yoğun bir talep akışını yöneten işletmede asıl mesele ekranın görünümü değil, bir işin kimden çıkıp kime ulaştığının hiçbir yerde yazılı olmamasıdır. Bu yüzden geliştirmeye taslak ekranlarla değil, günlük işleyişin adım adım çıkarılmasıyla başlıyoruz. Hangi kararın hangi bilgiye dayandığı belirsizken çizilen her arayüz, sonradan bozulacak bir varsayımın üzerine kurulur.

Çözümleme sırasında mevcut kayıtları gerçek kullanım örnekleriyle karşılaştırıyor; eksik kalan bilgiyi, yalnızca alışkanlıktan sürdürülen adımları ve sorumlusu belirsiz kalan noktaları ayırıyoruz. Bir özel yazılım ancak bu ayıklama yapıldıktan sonra sağlam bir zemine oturuyor. Aksayan bir düzeni olduğu gibi aktarmak, aksaklığı daha hızlı tekrarlayan bir araç üretmekten öteye geçmiyor.

Ortaya çıkan akışı yalnızca her şeyin yolunda gittiği durumla değil; eksik veriyle, geç gelen onayla ve beklenmedik isteklerle de deniyoruz. Planda tutarlı görünen bir düzenin en yoğun günde de ayakta kalıp kalmadığı ancak böyle anlaşılıyor; teslimden sonra yapılacak geniş çaplı düzeltmelerin önü de burada kesiliyor. Böylece işleyiş, birkaç kişinin belleğine bağlı olmaktan çıkıyor.

Yetkiyi gerçek görev sınırına oturtmak

Rezervasyon ve konaklama işlerini tek bir uygulamada toplayan bir markada erişim sınırı, iş bölümünün kendisi kadar belirleyicidir. Erişimi kişilerin unvanına göre değil üstlendikleri işe göre tanımlıyor; okuma, veri girme, düzeltme ve onaylama haklarını birbirinden ayrı tutuyoruz. Herkesin her kayda ulaştığı bir düzen başta kolaylık gibi görünse de sorumluluğu zamanla belirsizleştirir.

Yetki haritasını çıkarırken istisnaları da hesaba katıyoruz; görevi geçici olarak devralan biri, izne ayrılan bir çalışan ya da ekibe yeni katılan bir kişi. Birlikte çalıştığımız Samsun merkezli ekiplerde en sık aksayan nokta da burasıdır. Fazla yetki sessiz hataların kaynağı olurken, eksik yetki çalışanı sistemi bırakıp kestirme yollara yöneltir.

Sınırların gerçekten tuttuğunu her rolün gözünden ayrı ayrı deniyor; bir kullanıcının kendi alanının dışındaki bir ekrana ulaşıp ulaşamadığını senaryolarla doğruluyoruz. Görev değişikliğinde erişimin tek yerden güncellenebilmesini baştan planlıyor, her değişikliği kim yaptıysa onun adıyla kayda geçiriyoruz. Böylece düzen, ekip büyüdüğünde baştan elden geçirilmeden genişleyebiliyor.

Veriyi tek bir ad ve biçim altında toplamak

Üretim tarafıyla satış tarafı aynı kaydı farklı adlarla tuttuğunda, raporların birbirini tutmaması kaçınılmaz olur. Aynı müşteri iki ayrı yerde iki farklı biçimde yazıldığında ortaya çıkan fark, sonradan elle düzeltilen ve her ay tekrarlanan bir işe dönüşür. Bu yüzden hangi alanın ne anlama geldiğini, hangi birimle ve hangi biçimde yazılacağını ortak bir tanım listesinde topluyoruz.

Tanımları belirlerken eski kayıtları da gözden geçiriyoruz; aynı ürünü ikiye bölen yazım farklarını, boş bırakılmış zorunlu alanları ve yıllar içinde kullanımdan düşmüş başlıkları ayıklıyoruz. Taşınacak veri taşınmadan önce sadeleşiyor, çünkü yeni bir düzenin ilk günden eski karışıklığı devralması hiçbir şeyi çözmüyor.

Ortak tanım yerleştikten sonra her ekran aynı dili konuşuyor; bir sayı iki ayrı raporda aynı anlama geliyor ve tartışma, verinin doğruluğundan çıkıp kararın kendisine kayıyor. Yeni bir alan gerektiğinde nereye ekleneceği belli olduğu için yapı zamanla dağılmıyor, sonradan gelen kişi de kayıtları tek başına okuyabiliyor.

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

Ürünlerini bölgesel alıcılara açan bir girişimde işler çoğu zaman onay bekleyen bir adımda takılır ve kimse bekleyenin kimde olduğunu bilmez. Süreç ilerlemez, ama nedeni de görünmez; bu belirsizlik kısa sürede telefon trafiğine ve karşılıklı beklemeye dönüşür. Onay sırasını ekranda görünür kılmak, sorunun daha büyümeden fark edilmesini sağlar.

Her adım için kimin karar vereceğini, kararın hangi bilgiye dayanacağını ve yanıt gelmediğinde ne olacağını önceden tanımlıyoruz. Bir özel yazılım içinde onay yalnızca bir düğme değil, kimin neye dayanarak karar verdiğinin kaydıdır. Reddedilen bir talebin gerekçesiyle birlikte geri dönmesi, aynı işin ikinci kez baştan kurulmasını önlüyor.

Akışın son hâlini gerçek taleplerle sınıyor, bekleyen işlerin toplu olarak izlenebildiği sade bir görünüm bırakıyoruz. Bir iş nerede duruyorsa orada görülüyor; gecikme, ay sonunda fark edilen bir sürpriz olmaktan çıkıyor. Yönetim tarafı da hangi aşamanın düzenli olarak tıkandığını kendi gözüyle görebiliyor.

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

Dönemsel yoğunlukla çalışan bir ekipte herkese giden uyarılar kısa sürede okunmaz hâle gelir; bir süre sonra önemli olanla sıradan olan aynı sessizliğe gömülür. Bildirimi kimin, neden ve ne zaman alacağını ayrıştırmak, dikkati gerçekten karar gerektiren olaylara yöneltmenin tek yoludur. Aksi hâlde uyarı sistemi kendi kendini işlevsiz bırakır.

Hangi olayın anında iletileceğini, hangisinin gün sonunda toplu bir özetle aktarılacağını birlikte belirliyoruz. Aynı durum için tekrarlayan mesajları tek bir bildirimde birleştiriyor, kişisel tercihe bırakılabilecek olanları kullanıcının kendi ayarına açıyoruz. Amaç ekranın sürekli dikkat istemesi değil, gerektiğinde güvenilir biçimde uyarmasıdır.

Kurulan düzeni farklı yoğunluk günleriyle deniyor, uyarının hiç ulaşmadığı ya da gecikmeli ulaştığı durumların da kayda düşmesini sağlıyoruz. Bir bildirim yalnızca gönderildiğinde değil, ulaştığı doğrulanabildiğinde güvenilir sayılır; bu ayrım, işin unutulduğu sanılan anlarda sorumluluğun nerede durduğunu açıkça gösterir.

Mobil kullanımı sahanın koşullarına göre biçimlendirmek

Farklı pazarlara çalışan bir üreticide kayıt çoğu zaman masa başında değil; depoda, yükleme alanında ya da yolda giriliyor. Bu koşullarda ekran boyutu kadar bağlantının kesildiği anda ne olacağı da tasarımın bir parçasıdır. Bunlar hesaba katılmadan kurulan bir özel yazılım, ofiste işe yarasa da sahada kısa sürede terk edilir.

Sahada kullanılacak ekranları az sayıda alanla, rahat dokunulabilen düğmelerle ve yazmayı azaltan hazır seçeneklerle kuruyoruz. Bağlantı koptuğunda girilen bilginin kaybolmaması, bağlantı geri geldiğinde ise kayıtların birbirini ezmeden tamamlanması için sıraya alma düzeni tanımlıyoruz. Eldiven takan ya da tek elini kullanan biri de aynı kolaylıkla ilerleyebiliyor.

Uygulamayı yavaş bağlantı, eski cihaz ve güneş altında okunan ekran gibi gerçek koşullarda deniyoruz. Sahadaki kişi kaydı zahmetsiz girebildiğinde veri gecikmiyor; ofis tarafı da gün sonunu beklemeden güncel bilgiyle çalışıyor. Kayıt anında düşülen bir not, sonradan hatırlanmaya çalışılan bilgiden her zaman daha doğru oluyor.

Dış bağlantıları sınırı belli biçimde kurmak

Yoğun talep yöneten bir hizmet işletmesinde özel yazılım tek başına çalışmaz; ödeme, kargo, muhasebe ya da mesaj sağlayıcılarıyla sürekli veri alışverişi yapar. Bu bağlantılarda asıl soru her şey yolundayken ne olduğu değil, karşı taraf yanıt vermediğinde ya da beklenmedik bir yanıt döndürdüğünde ne olacağıdır.

Bağlanılacak sistemleri seçerken belgelenmiş ve erişimi denetlenebilir olanları tercih ediyor, Samsun’daki işletmelerin halihazırda kullandığı araçları da hesaba katıyoruz. Verinin hangi yöne aktığını, hangi kaydın kaynak sayılacağını ve çakışma olduğunda hangisinin geçerli olacağını işe başlamadan yazıya döküyoruz.

Her bağlantı için bekleme süresi, yeniden deneme sayısı ve başarısızlık hâlinde kimin haberdar edileceği tanımlı oluyor. Karşı taraftaki bir duraklama sizin tarafınızdaki işlemleri kilitlemiyor; ilgili adım askıya alınıyor ve durum düzeldiğinde tamamlanıyor. Neyin ne zaman yürümediği kayıtta göründüğü için sorumluluk sonradan tartışma konusu olmuyor.

Hata kaydını okunabilir ve izlenebilir bırakmak

Bir aksaklık yaşandığında ilk sorulan soru genellikle olayın ne olduğu değil, ne zaman ve kimin işleminde ortaya çıktığıdır. Bu yüzden hata kayıtlarını teknik bir yığın olarak değil, sonradan okunup izlenebilecek bir iz olarak kuruyoruz. Kaydı tutulmayan bir sorun, her seferinde sıfırdan aranmak zorunda kalır.

Kayıtlarda hangi işlemin, hangi kullanıcı bağlamında ve hangi veriyle çalışırken durduğunu tutuyoruz. Kişisel bilgiyi gereksiz yere çoğaltmadan sorunu yeniden üretmeye yetecek kadar ayrıntı bırakmak arasındaki dengeyi baştan belirliyor; kayıtların ne kadar süre saklanacağını da aynı aşamada karara bağlıyoruz.

Kullanıcıya dönen mesajı ayrı ele alıyoruz; karşıdaki kişi ne yapması gerektiğini anlıyor, teknik ayrıntı ise kayda gidiyor. Destek talebi geldiğinde tahminle değil kayıtla ilerleniyor ve aynı sorunun tekrar edip etmediği ölçülebiliyor. Bu ölçüm, nelerin öncelikle düzeltileceğine karar vermeyi kolaylaştırıyor.

Oturum ve erişim güvenliğini senaryoyla denemek

Üretim ve satış verisini tek çatı altında toplayan bir kuruluşta güvenlik, tek bir ayarla değil birbirini tamamlayan küçük kararlarla kurulur. Oturumun ne kadar açık kalacağı, parolanın nasıl sıfırlanacağı ve şüpheli bir girişte ne olacağı bunların başında gelir. Bir özel yazılım geliştirirken bu kararları sonraya bırakmıyoruz.

Erişim denemelerini gerçek senaryolarla sınıyoruz; yetkisi olmayan bir hesapla doğrudan bir adrese gitmeyi, açık bırakılmış bir cihazdan devam etmeyi ve ayrılan bir çalışanın hesabının kapatılmadığı durumu tek tek deniyoruz. Her denemenin ne sonuç verdiğini yazıyor, düzeltmeden sonra aynı adımları yeniden çalıştırıyoruz.

Güvenlik böylece bir kerelik kontrol olmaktan çıkıp sürüm değiştikçe tekrarlanan bir alışkanlığa dönüşüyor. Kritik işlemlerin kim tarafından ne zaman yapıldığı kayıtta durduğu için, bir şüphe doğduğunda geriye dönüp bakılacak bir yer oluyor ve konu varsayımla kapatılmıyor.

Yedek ve geri dönüş planını önceden kurmak

Yedek almak ile geri dönebilmek aynı şey değildir; asıl ölçü, kaç saatlik kaybın göze alınabildiği ve dönüşün ne kadar sürdüğüdür. Bu iki ölçü konuşulmadan yedekleme sıklığına da saklama süresine de karar verilemez. Sorumlusu belirsiz bırakılan bir yedekleme düzeni, işe yaradığı sanılan ama hiç sınanmamış bir alışkanlığa dönüşür.

Veritabanının yanında dosyaları, ayarları ve erişim bilgilerini de kapsayan bir düzen kuruyoruz. Yedeğin uygulamadan ayrı bir yerde tutulması ve okunabilir olduğunun düzenli aralıklarla denenmesi, planın kâğıt üzerinde kalmamasını sağlıyor. Hiç açılmamış bir yedek, var sayılamayacak kadar belirsizdir.

Geri dönüşü gerçekten deneyerek gereken süreyi ölçüyor, adımları anlaşılır biçimde yazıya geçiriyoruz. Böyle bir gün geldiğinde kimin neyi hangi sırayla yapacağı belli oluyor ve karar, telaşın içinde doğaçlama verilmek zorunda kalmıyor. Ölçülen süre, hangi iyileştirmenin öncelikli olduğunu da gösteriyor.

Değişiklikleri aşamalı biçimde yayına almak

Dönemsel yoğunluğu planlayan bir ekipte yeni bir sürüm en kötü anda devreye girerse kazanç değil kayıp üretir. Bu nedenle değişiklikleri doğrudan canlıya taşımıyor; önce ayrı bir ortamda, gerçek kullanıma benzeyen örneklerle deniyoruz. Yayın zamanını da işin en sakin olduğu aralığa göre seçiyoruz.

Her yayında neyin değiştiğini, hangi işlemin bundan etkileneceğini ve sorun çıkarsa nasıl geri alınacağını yazılı hâle getiriyoruz. Küçük ve sık yayınlar, tek seferde yapılan geniş değişikliklere göre hem daha az risk taşıyor hem de bir aksaklık çıktığında kaynağı aramayı kolaylaştırıyor.

Yayından sonraki ilk saatleri izliyor, hata kayıtlarını ve olağandan yavaş çalışan işlemleri takip ediyoruz. Geri dönüş yolu açık tutulduğu için beklenmedik bir durumda sistem, baştan kurulmadan önceki hâline döndürülebiliyor. Kullanıcıya da neyin değiştiğini kısa ve anlaşılır biçimde aktarıyoruz.

Devir ve eğitim kayıtlarını eksiksiz bırakmak

Bir sistemin gerçekten teslim edilmiş sayılması dosyaların aktarılmasıyla değil, ekibin onu kendi başına yürütebilmesiyle olur. Teslimi kurumun kendi çalışanlarıyla birlikte yürütüyoruz; bu aşama, Samsun’da çalıştığımız işletmelerde çoğu zaman geliştirme kadar belirleyici oluyor. Ekranların yanında arkadaki kararların gerekçesini de aktarıyoruz.

Eğitimi kullanıcıların kendi görevleri üzerinden yürütüyor, sık karşılaşılan durumları uygulamalı biçimde geçiyoruz. Yanında kalıcı bir başvuru metni bırakıyoruz; işe yeni başlayan biri aynı anlatımı baştan dinlemek zorunda kalmıyor, aradığı adımı kendi başına bulabiliyor. Sorular biriktikçe bu metni de güncelliyoruz.

Teslimde hesapların, erişim bilgilerinin ve kaynakların kimde durduğunu yazılı olarak kayda geçiriyoruz. Kurumun kendi sistemine hâkim olması, ileride hangi yolla devam edeceğine bağımsız biçimde karar verebilmesi anlamına geliyor; bu netlik, uzun vadede çalışma ilişkisini de gereksiz pazarlıklardan uzak tutuyor.

Geliştirme Süreci Hakkında Sık Sorulan Sorular

Süreciniz hazır araçların kalıbına sığmıyorsa, yetki ayrımı ayrıntılıysa, farklı sistemler arasında düzenli veri aktarımı gerekiyorsa ya da rapor ihtiyacınız standart çıktılarla karşılanmıyorsa özel yazılım anlam kazanır. Ölçüt, aracın işinize uyması yerine işinizin araca uydurulmaya başlandığı noktadır. Böyle bir zorlama yoksa elinizdeki araçla devam etmek daha ölçülü bir tercihtir.

Süre baştan söylenen tek bir rakamla değil, kapsam netleştikçe belirginleşir. Kaç farklı kullanıcı tipi bulunduğu, kararların hangi kurallara bağlandığı, dışarıyla kurulacak bağlantılar ve denenecek durumlar ortaya konduktan sonra çalışma parçalara ayrılır; her parçanın kendi teslim zamanı olur. Böylece ilerleme yol boyunca izlenir, yalnızca sonda görülmez.

Bunun ön koşulu, karşı tarafın belgelenmiş ve denetlenebilir bir erişim noktası sunmasıdır. İki sistemden hangisinin bir kayıt için asıl kaynak sayılacağı, çakışma çıktığında hangisinin üstün geleceği ve aktarımın hangi sıklıkta yapılacağı işe başlamadan kararlaştırılır. Böyle bir erişim yoksa veriyi elle taşımadan yürüyen bir ara çözüm kurmak gerekir.

Devir kapsamı, işe başlamadan imzalanan metinde ayrıntılı biçimde belirtilir. Uygulamanın kodu, üzerinde çalıştığı ortam, alan adı kaydı ve kullanılan dış servis abonelikleri için kimin hesap sahibi olacağı tek tek karara bağlanır. Sahipliğin kurumda olması, ilerleyen dönemde yön değiştirmek istediğinizde elinizi bağlamaz.

Destek tek bir paket olarak değil, birbirinden bağımsız başlıklar hâlinde konuşulur. Ortaya çıkan bir aksaklığı düzeltmek, altyapıyı güncel tutmak, sistemi izlemek ve yeni bir yetenek eklemek aynı iş değildir; her birinin yanıt süresi ve bedeli ayrı belirlenir. Bu ayrım yazıya döküldüğünde iki taraf da neyin kapsamda olduğunu bilir.

Yapı kurulurken bugünkü kullanım kadar, önümüzdeki dönemde beklenen hacim de dikkate alınır. İşlem süreleri ve aynı anda çalışan kullanıcı sayısı gibi noktalara ölçüm bırakılır; hangi adımın yavaşladığı görülmeden kapasite kararı verilmez. Böylece genişleme ihtiyacı doğduğunda yapılacak iş, sistemi baştan kurmaktan çok daha sınırlı kalır.