Yazılım

Ekran çizmeden önce işin akışını çözmek

Bir işletmenin günlük işleyişi çoğunlukla yazıya dökülmemiş alışkanlıklardan oluşur. Özel yazılım kararı verilmeden önce bu alışkanlıkların konuşulması ve kayda geçirilmesi gerekir; hangi belgenin nereden doğduğu, kimin elinden geçtiği ve hangi aşamada beklemeye girdiği görülmeden çizilen ekranlar kısa sürede kullanımdan düşer. Sorun genellikle arayüzde değil, işin kendi mantığının eksik anlaşılmasında başlar.

Çözümlemeyi Balıkesir merkezli işletmelerle yürütürken masabaşı varsayımlarla yetinmiyor, işin fiilen döndüğü noktayı dinliyoruz. Tek satır gibi görünen bir talebin arkasında kaç kişinin sırayla işlem yaptığı, hangi bilginin iki ayrı defterde ayrı ayrı tutulduğu ve hangi adımda geri dönüş yaşandığı ancak böyle ortaya çıkıyor. Eldeki kayıtlarla anlatılanlar arasındaki fark da bu aşamada görünür hale geliyor.

Akış netleştiğinde geliştirme sırası kendiliğinden belirginleşir. Hangi adımın otomatik yürüyeceği, hangisinin insan kararında kalacağı baştan ayrıldığı için sonradan gelen istekler kurulu düzeni bozmaz; kendilerine ayrılmış yere yerleşir. Uzun ömürlü bir uygulamanın temeli çoğu kez ilk satır yazılmadan önce, bu ayrımın yapıldığı görüşmelerde atılır.

Yetkileri kişinin gerçek sorumluluğuna bağlamak

Rol tanımı, ekranların kime açılacağından çok kimin neyi değiştirmeye yetkili olduğuyla ilgilidir. Bir kaydı görüntüleyebilmek ile onu geri dönüşü olmayacak biçimde değiştirebilmek arasındaki fark yazılı hale gelmediğinde yetkiler zamanla gevşer ve herkesin her şeye eriştiği bir yapı ortaya çıkar. Bu noktadan sonra geri dönmek, baştan kurmaktan daha zahmetli olur.

Bu nedenle rolleri unvanlara göre değil, kişinin fiilen üstlendiği sorumluluğa göre kuruyoruz. Vardiya değişiminde devreye giren kullanıcı, dışarıdan geçici erişim alan bir tedarikçi ve yalnızca rapor okuyan yönetici için ayrı sınırlar tanımlanıyor. Her sınırın hangi gerekçeyle konulduğu da kayıt altında tutuluyor; böylece ileride yapılacak değişiklikler tartışma yaratmıyor.

Sınırların dar tutulması ekibi yavaşlatmaz, tereddüdü azaltır. Kullanıcı karşısında yalnızca kendi işine ait seçenekleri gördüğünde yanlış ekrana girme ihtimali düşer, eğitim süresi kısalır. Bir aksaklık yaşandığında hangi işlemin kimin yetkisiyle yapıldığı kayıtlardan okunabildiği için sorumluluk da tartışmaya gerek kalmadan anlaşılır.

Veri alanları için ortak bir tanım kümesi

Aynı bilginin farklı birimlerde farklı adlarla tutulması, raporların birbirini tutmamasının en sık nedenidir. Müşteri numarası bir yerde metin, başka yerde rakam olarak saklandığında karşılaştırma yapmak güçleşir; tarih biçimleri ayrıştığında dönemsel toplamlar sapar. Sorun ekranlarda değil, alanların tanımsız bırakılmasında başlar ve zamanla her rapora yayılır.

Çalışmanın başında bütün alanları tek bir tanım kümesinde topluyoruz. Her alanın ne anlama geldiği, hangi biçimde girileceği, boş bırakılıp bırakılamayacağı ve hangi birimin sorumluluğunda olduğu yazıya geçiriliyor. Tartışmayı veri girişi başladıktan sonra değil önce yapmak, ileride binlerce kaydı elle düzeltme işinden kurtarıyor.

Ortak tanım oturduğunda yeni bir rapor istendiğinde veriyi yeniden derleme ihtiyacı büyük ölçüde ortadan kalkar. Farklı ekranlar aynı kaynağı okuduğu için sayılar birbirini doğrular. Sonraki geliştirmelerde de veri yapısını baştan kurma zorunluluğu doğmaz; eklenen alan, mevcut düzenin içine yerleşir.

Onay basamaklarını ekibe açık hale getirmek

Bekleyen bir işin kimde durduğu görünmüyorsa süreç telefonla takip edilmeye başlanır. Onay zincirinin adımları ekranda açıkça yer almadığında gecikmenin nedeni de kaynağı da tahmine kalır; bu tahminler çoğu zaman yanlış kişiyi işaret eder ve ekip içinde gereksiz gerilim yaratır.

Onay basamaklarını, talebin doğduğu andan kapandığı ana kadar tek bir görünümde topluyoruz. Her adımda kimin beklediği, ne kadar süredir beklediği ve hangi gerekçeyle geri gönderildiği kayda geçiyor. Geri gönderme de en az onay kadar açık bir adım olarak tanımlanıyor; gerekçesiz reddetme seçeneği bırakılmıyor.

Bu görünürlük süreci hızlandırmaktan çok tartışmayı bitirir. Ay sonunda hangi işin nerede takıldığı kayıtlardan okunabildiği için ekip, sorumlu aramak yerine tıkanan adımı düzeltmeye yönelir. İyileştirme kararları da varsayıma değil, aynı kayıttan çıkan somut sürelere dayanır. Zamanla hangi aşamanın gerçekten onaya ihtiyaç duyduğu da netleşir.

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

Fazla bildirim, hiç bildirim olmamasıyla benzer sonuç doğurur. Herkese giden uyarılar kısa sürede okunmadan kapatılır ve gerçekten önemli olan haber de bu yığının içinde kaybolur. Bu nedenle bildirimi bir özellik değil, dikkatle paylaştırılması gereken sınırlı bir kaynak olarak ele alıyoruz.

Hangi olayın kimi ilgilendirdiğini, hangi eşiği aştığında haber verilmesi gerektiğini ve hangi kanaldan ulaşacağını tek tek belirliyoruz. Kimi durumda anlık uyarı yerine gün sonunda toplu bir özet daha işlevsel oluyor. Karar, olayın aciliyetine ve alıcının o bilgiyle ne yapabileceğine göre veriliyor.

Doğru kurgulanmış bir bildirim düzeni, ekranı sürekli açık tutma zorunluluğunu ortadan kaldırır. Kullanıcı yalnızca kendisini ilgilendiren durumda haberdar olur, geri kalan zamanda kendi işine döner. Sistem de gereksiz trafik üretmediği için önemli uyarılar dikkat çekme gücünü korur.

Sahadaki kullanımı mobil koşullara göre kurmak

Depoda, araçta veya müşteri ziyaretinde kullanılan bir uygulamanın koşulları masa başındakinden farklıdır. Tek elle tutulan telefon, güneş altında okunmayan ekran ve zaman zaman kesilen bağlantı, arayüzün en baştan bu gerçeğe göre kurulmasını gerektirir. Masaüstü için düşünülmüş bir düzeni küçültmek çözüm olmaz.

Saha ekranlarını olabildiğince az alan içerecek biçimde sadeleştiriyoruz. Sık kullanılan işlem parmağın rahat ulaştığı yere alınıyor, uzun seçim adımları yerine arama tercih ediliyor. Bağlantı koptuğunda girilen verinin kaybolmaması için kayıt cihazda tutuluyor ve bağlantı döndüğünde sırasıyla gönderiliyor.

Bu düzeni Balıkesir’de saha ekibiyle çalışan işletmeler için kurarken önceliğimiz, kayıt tutmayı günün sonuna biriken bir yük olmaktan çıkarmak oluyor. İşlem yerinde ve o anda kaydedildiği için veri hem daha doğru hem daha güncel kalıyor; ofis tarafı bilgiyi beklemek yerine anında görebiliyor.

Dış sistemlerle bağlantıyı denetimli açmak

Muhasebe programı, kargo servisi veya ödeme altyapısıyla kurulan her bağlantı, sistemin dışarıya açılan bir kapısıdır. Özel yazılım çalışmasında bu kapıları tek tek ele alıyor; hangi verinin hangi yöne aktığını, hatanın nerede tutulacağını ve yetkinin nasıl doğrulanacağını baştan yazıyoruz. Açık bırakılan her ayrıntı sonradan maliyet olarak geri döner.

Bağlantıyı kurmadan önce karşı tarafın belgelerini ve sınırlarını inceliyoruz. Belirli sürede kaç isteğin kabul edildiği, yanıt gecikince ne yapılacağı ve aynı kaydın iki kez gönderilmesi durumunda ne olacağı önceden kararlaştırılıyor. Bu kararlar yazılmadığında sorun, ancak veri bozulduktan sonra fark ediliyor.

Dışarıdaki bir servis yanıt vermediğinde uygulamanın tamamen durmaması için bağlantılar birbirinden ayrı tutuluyor. Aktarılamayan kayıt sıraya alınıyor, ilgili kişi durumdan haberdar ediliyor ve bağlantı düzeldiğinde aktarım kaldığı yerden sürüyor. Böylece dışarıdaki bir aksaklık, kendi işleyişinizi durduran bir soruna dönüşmüyor.

Hata kayıtlarını okunur ve izlenebilir tutmak

Bir arıza bildirildiğinde ilk aranan şey, o anda ne olduğunu gösteren kayıttır. Kaydın hiç tutulmadığı ya da yalnızca teknik ekibin çözebileceği biçimde saklandığı durumlarda zaman, sorunun kendisinden çok arama işine harcanır. Kullanıcı da ne olduğunu anlamadığı için aynı adımı tekrar denemeye başlar.

Bu yüzden kayıtları iki katmanlı tutuyoruz. Kullanıcıya ne yapması gerektiğini söyleyen sade bir açıklama gösteriliyor; geliştiricinin ihtiyaç duyduğu ayrıntı ise arkada, hangi hesabın hangi işlemi hangi saatte denediğini gösterecek biçimde saklanıyor. İki katman birbirine bağlı olduğu için bildirim ile kayıt kolayca eşleştiriliyor.

Kayıtların düzenli tutulması aynı hatanın tekrar etmesini de önler. Sık karşılaşılan durumlar zamanla belirginleşir, kalıcı çözüm gerektiren nokta geçici müdahaleden ayrılır. Bakım planı böylece tahmine değil gözlenen duruma dayanır ve önceliklendirme yapmak kolaylaşır. Hangi bölümün elden geçirileceği de aynı kayıtlardan çıkar.

Oturum ve yetki güvenliğini senaryoyla denemek

Güvenlik, giriş ekranındaki parola alanından ibaret değildir. Asıl soru, oturumu açılmış bir kullanıcının kendi yetkisi dışındaki bir adrese doğrudan gitmeye çalıştığında ne olacağıdır. Bu tür denemeler yapılmadan verilen güvenlik kararları varsayıma dayanır ve varsayımın yanlış olduğu genellikle en geç anda anlaşılır.

Teslimden önce yetkileri senaryolarla sınıyoruz. İşten ayrılmış bir kullanıcının erişiminin gerçekten kapandığı, oturumun belirlenen süre sonunda sonlandığı ve düşük yetkili bir hesabın üst seviyedeki kaydı ne görüntüleyebildiği ne de değiştirebildiği tek tek deneniyor. Dosya yükleme ve dışa aktarma gibi adımlar da aynı gözle ele alınıyor.

Denemelerin sonuçları yazılı olarak kayda geçiyor; bulunan açıklar kapatıldıktan sonra aynı senaryolar yeniden çalıştırılıyor. Böylece güvenlik, teslim gününde bir kez bakılan bir konu olmaktan çıkıp her sürümde tekrarlanan bir denetime dönüşüyor. Sonradan eklenen bir ekran da aynı sınamadan geçmeden yayına alınmıyor.

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

Yedeklemenin değeri alınmasında değil, geri yüklenebilmesinde ortaya çıkar. Düzenli kopya alındığı halde bu kopyadan hiç dönülmemişse çalışıp çalışmadığı yalnızca varsayılır; bunun sınanacağı an da genellikle işlerin en yoğun olduğu zamana denk gelir. Hazırlığın sakin bir dönemde yapılmasının nedeni budur.

Bu nedenle yedek planını baştan yazıyoruz. Kopyanın hangi sıklıkta alınacağı, ne kadar süre saklanacağı, nerede tutulacağı ve geri dönüş gerektiğinde kimin hangi adımı uygulayacağı belirleniyor. Plan yalnızca kağıt üzerinde kalmıyor; deneme amaçlı bir geri yükleme ile gerçekten çalıştığı gösteriliyor.

Yanlışlıkla silinen tek bir kaydı geri getirmek ile sunucu düzeyindeki bir arızadan dönmek farklı hazırlıklar gerektirir. İkisini ayrı ayrı planladığımız için sorun çıktığında ne kadar veriyi ve ne kadar zamanı göze aldığınız önceden bilinir. Beklenti netse kriz anında verilen kararlar da sakin olur.

Sürüm geçişlerini denetimli biçimde yayımlamak

Çalışan bir uygulamaya yapılan her ekleme, yerinde duran işleyişi de etkileme ihtimali taşır. Bu nedenle değişiklikleri doğrudan canlıya almak yerine, gerçek verinin kopyasıyla çalışan ayrı bir ortamda deniyoruz. Sonuç ilgili kişiye gösterilip onayı alındıktan sonra yayına geçiliyor.

Yayın anı için de bir sıra belirleniyor. Hangi adımın önce uygulanacağı, geri dönüş gerekirse hangi noktaya dönüleceği ve işlem sırasında kullanıcıların ne göreceği önceden konuşuluyor. Yoğun saatlerin dışında yapılan geçişler, olası bir aksaklığın etkisini de sınırlı tutuyor.

Yayından sonraki ilk saatlerde uygulamayı yakından izliyoruz. Hata sayısındaki artış, yavaşlayan ekranlar ve kullanıcıdan gelen ilk geri bildirimler aynı gün değerlendiriliyor. Beklenmeyen bir durumda önceki sürüme dönmek hazır bir seçenek olarak duruyor; bu güvence, geliştirmeyi sürdürmeyi de kolaylaştırıyor.

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

Bir özel yazılım çalışması, onu kullanacak kişilere anlatılmadan teslim edilmiş sayılmaz. Ekranların nasıl işlediğini bilen tek kişi geliştirici olduğunda sistem ilk aksaklıkta bir kenara bırakılır ve ekip eski alışkanlığına geri döner. Yatırımın karşılıksız kalması çoğu zaman bu noktada başlar.

Eğitimi kullanıcı rollerine göre ayırıyoruz; herkese aynı anlatımı yapmak yerine kişinin kendi ekranlarını derinlemesine öğrenmesini sağlıyoruz. Anlatılanların kaydı, sık karşılaşılan durumların yazılı karşılığı ve yönetici tarafındaki ayarların açıklaması teslim paketinde yer alıyor. Böylece aynı soru her defasında yeniden sorulmuyor.

Hesapların, alan adının, sunucu erişimlerinin ve kaynak dosyaların kimde durduğu da aynı belgede net biçimde yazılıyor. Bu kayıtları, Balıkesir’de kurduğumuz her uygulamada projenin ayrılmaz parçası sayıyoruz; ekipte değişiklik olduğunda yeni gelen kişi sistemi sıfırdan çözmek zorunda kalmıyor.

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

Hazır araçlar yaygın ihtiyaçları ortak bir kalıpla karşılar; ayrım, işinizin o kalıba sığmayan adımlarında başlar. Kendine özgü bir onay zinciri, standart dışı yetki ihtiyacı, farklı sistemler arasında kurulacak veri bağlantısı ya da hazır raporlarla çıkarılamayan bir hesaplama varsa özel yazılım anlamlı hale gelir. İhtiyaç genel nitelikteyse mevcut bir çözümde kalmak çoğu zaman daha makuldür.

Süre, ekran sayısından çok iş kurallarının karmaşıklığına bağlıdır. Kullanıcı rolleri, karar noktaları, dış bağlantılar ve sınanacak durumlar çıkarıldıktan sonra çalışma aşamalara bölünür ve her aşama için ayrı bir takvim verilir. Kapsam sonradan genişlerse takvim yeniden hesaplanır; bu değişiklik iş başlamadan konuşulur.

Belgeleri yayımlanmış ve dışarıya denetimli bir erişim noktası açan sistemlerle bağlantı kurulabilir. Bunun için verinin hangi yöne akacağı, yanıt alınamadığında ne yapılacağı ve kimliğin nasıl doğrulanacağı önceden tanımlanır. Karşı tarafta böyle bir erişim yoksa aktarımın dosya üzerinden yürüdüğü ara bir yöntem değerlendirilir.

Teslim biçimi sözleşmede açıkça yazılır. Uygulamanın çalışacağı sunucunun, alan adının ve üçüncü taraf hesaplarının kimin adına açılacağı proje başlamadan netleştirilir. Bu konunun sonraya bırakılması, ilerleyen dönemde yaşanan erişim sorunlarının en sık nedenidir. Sahiplik baştan belirlendiğinde kimin neyi devredeceği de tartışma konusu olmaz.

Yayın sonrası iş, birbirinden ayrı sorumluluklar halinde planlanır. Arıza giderme, güvenlik yamalarının uygulanması, sistemin izlenmesi ve yeni işlev eklenmesi birbirinden farklı kalemlerdir; hepsini tek başlık altında toplamak beklentiyi bulanıklaştırır. Bir özel yazılım projesinde bu ayrımın yazılı olması, sonradan çıkabilecek tartışmaların büyük bölümünü baştan keser.

Mimari, beklenen kullanım yoğunluğu ve veri hacmi göz önünde tutularak kurulur. Sorgu süreleri, eş zamanlı kullanıcı sayısı ve depolama artışı düzenli olarak ölçülür; büyüme kararları tahminle değil bu ölçümlerle verilir. Gerektiğinde kaynak artırımı ya da yapısal iyileştirme ayrı bir çalışma olarak ele alınır.