Yazılım

Ekranlara geçmeden önce işin kendisini çözmek

İşletmeler çoğu zaman ihtiyaçlarını ekran diliyle anlatır: şu liste görünsün, şu düğme burada dursun. Oysa bir uygulamanın değerini belirleyen şey, arkasındaki işin hangi sırayla yürüdüğü ve hangi noktada kimin karar verdiğidir. Özel yazılım kararı da bu sıra yazıya geçirilmeden olgunlaşmaz; eldeki yöntemin tam olarak nerede tıkandığı bilinmeden başlanan çalışmalar, ilerledikçe hem takvimi hem bütçeyi zorlar. İlk görüşmelerde bu nedenle araç değil, işin kendisi konuşulur.

Elde ne varsa onunla başlıyoruz: defterler, tablolar, yazışmalar ve kimsenin açmadığı hâlde herkesin adını bildiği dosyalar. İncelemeyi kullanıcının kendi masasında yürütüyoruz; böylece bir işlemin kaç elden geçtiği, hangi bilginin birden çok yerde ayrı ayrı tutulduğu ve hangi aşamanın düzenli olarak başa sarıldığı ortaya çıkıyor. Anlatılan düzen ile kayıtlara yansıyan düzen arasındaki mesafe, geliştirmenin hangi bölümden başlayacağını kendiliğinden gösteriyor. Bu adımı, ölçeği ne olursa olsun Kütahya’da görüştüğümüz her işletmede aynı biçimde uyguluyoruz.

Bu çözümleme tamamlandığında geliştirme sırası belirginleşir ve tartışma konusu olmaktan çıkar. İnsan yargısı gerektiren adımlar ile sistemin tek başına tamamlayabileceği adımlar ayrıştığı için, ilerleyen haftalarda gelen istekler kurulu yapıyı sökmeyi gerektirmez. Çözümleme atlandığında ise her yeni talep önceki bölümlerin yeniden yazılmasına yol açar; süre uzar, maliyet baştan öngörülemez hâle gelir.

Yetkiyi unvana göre değil yapılan işe göre vermek

Aksaklıkların çoğu kötü niyetten değil, kimin neye dokunabileceğinin belirsiz kalmasından doğar. Herkese her kapının açık olduğu bir düzende bir kaydı kimin değiştirdiği sonradan anlaşılamaz; fazla dar kurulan bir düzende ise işler tek kişinin masasında birikir ve o kişi izne ayrıldığında akış durur. Doğru ölçü, kâğıt üzerindeki unvanlarda değil gün içinde fiilen yapılan işte bulunur.

Rolleri belirlerken ekipteki herkesin bir hafta boyunca hangi kayıtları açtığını, hangilerini yalnızca okuduğunu ve hangilerinde son sözü söylediğini çıkarıyoruz. İzin verilen işlemlerin yanına izin verilmeyenleri de yazıyoruz; bir rolü asıl tanımlayan şey, yapabildikleri kadar yapamadıklarıdır. Vekâlet bırakma, izin dönemleri ve görev değişikliği gibi durumlar da aynı aşamada karşılığını buluyor.

Sınırlar netleştiğinde ekranlar da sadeleşir; kişi yalnızca kendisini ilgilendiren alanı görür, geri kalanı onu oyalamaz. Bir kaydın kim tarafından ve hangi yetkiyle değiştirildiği sorusu tartışmaya açık kalmaz. İşe yeni katılan biri geldiğinde ise tanımlı bir rol devredilir, kurulum baştan düşünülmez.

Aynı bilgiye herkesin aynı adı vermesi

Bir kurumda müşteri, cari, kayıt ve hesap sözcükleri sıklıkla aynı şeyi işaret eder; ama bunu yalnızca o bölümde çalışanlar bilir. Raporların birbirini tutmaması genellikle hesaplama hatasından değil, aynı alanın iki yerde farklı biçimde doldurulmasından kaynaklanır. Bu yüzden ilk satır yazılmadan önce alanların adı, biçimi ve zorunlulukları üzerinde anlaşmak gerekir.

Mevcut tablolardaki sütunları sırayla geçiyor, hangi alanın gerçekten kullanıldığını ve hangisinin yıllar önce açılıp boş kaldığını ayırıyoruz. Serbest metin olarak tutulan bilgilerden hangilerinin seçimli bir alana, hangilerinin tarih ya da sayı biçimine geçmesi gerektiğine birlikte karar veriyoruz. Ortaya çıkan ortak sözlük, sonraki tüm ekranların ve dökümlerin zeminini oluşturuyor.

Alan adları sabitlendiğinde iki bölümün aynı soruya farklı cevap verme ihtimali ortadan kalkar. Veri sonradan taşınacağı, dışarı aktarılacağı ya da başka bir sisteme bağlanacağı zaman da elde tarif edilmiş bir yapı bulunur. Böylece büyüme, her seferinde temizlik gerektiren bir yük olmaktan çıkar.

Bir işin hangi masada beklediğinin bilinmesi

Onay bekleyen bir talebin nerede durduğu bilinmiyorsa, ekip zamanının önemli bir bölümü iş yapmaya değil işin nerede olduğunu sormaya gider. Sözlü hatırlatmayla yürüyen onaylar, yoğun günlerde ilk aksayan halka olur. Özel yazılım çalışmasında onay sırası da tıpkı bir kayıt gibi tanımlanır; kimin neyi hangi koşulda onayladığı baştan yazılır.

Her onay adımı için üç soruyu ayrı ayrı yanıtlıyoruz: bu adım hangi durumda devreye girer, atlanabilir mi, atlanırsa yerine ne geçer. Tutar, süre ya da nitelik eşiğine bağlı onayları da aynı aşamada tanımlıyoruz; böylece küçük işler büyük işlerle aynı yolu izlemek zorunda kalmıyor. Reddedilen bir talebin gerekçesiyle birlikte geri dönmesi de bu kurgunun parçası oluyor.

Süreç tanımlandığında bir talebin geçmişi tek ekrandan okunur; ne zaman açıldığı, kimde beklediği ve hangi gerekçeyle sonuçlandığı görülür. Yoğun dönemlerde hangi adımın tıkandığı da tahmine değil kayda dayanarak anlaşılır. Bu bilgi, ekip düzenini değiştirmek gerektiğinde elde tutulabilir bir dayanak sağlar.

Uyarıların doğru kişiye doğru anda ulaşması

Fazla bildirim, bildirim yokluğuyla aynı sonucu doğurur; bir süre sonra hepsi okunmadan kapatılır. Önemli olan her hareketi duyurmak değil, yalnızca birinin harekete geçmesi gereken durumları iletmektir. Bu ayrım yapılmadığında sistem sürekli konuşur, kimse dinlemez.

Hangi olayın kime ulaşacağını, hangi kanaldan gideceğini ve ne kadar beklendikten sonra tekrarlanacağını tanımlıyoruz. Aynı konudaki uyarıların birikip tek bir özet hâlinde iletilmesi gereken durumları da ayırıyoruz. Mesai dışındaki saatlerde nelerin bekleyebileceği, nelerin bekleyemeyeceği ise ekiple birlikte kararlaştırılıyor.

Ölçü tutturulduğunda gelen her uyarı bir karşılık bekler ve gerçekten okunur. Gecikmiş bir iş fark edilmeden birikmez, kimsenin haberi olmayan bir talep gün sonunda ortaya çıkmaz. Ekip de bildirimleri kapatmak için değil, bir şey yapmak için açar.

Masa başında değil sahada kullanılacak ekranlar

Depoda, araçta ya da müşteri ziyaretinde kullanılan bir uygulama ile masa başındaki bir ekranın koşulları aynı değildir. Tek elle tutulan bir telefonda, güneş altında ve zayıf bağlantıyla doldurulan bir form, geniş ekranda rahat görünen düzenin küçültülmüş hâli olamaz. Bu fark hesaba katılmazsa saha kaydı ertesi güne, çoğu zaman da hafızaya kalır.

Sahada hangi bilginin fiilen girildiğini gözlemleyerek başlıyoruz; çoğu durumda üç dört alan işin tamamını karşılıyor, gerisi ofiste tamamlanabiliyor. Dokunma alanlarını büyütüyor, yazmayı azaltacak seçimler sunuyor ve bağlantı koptuğunda girilen verinin kaybolmamasını sağlıyoruz. Fotoğraf, imza veya konum gibi eklerin boyutunu da alandaki koşullara göre ayarlıyoruz.

Kayıt işin yapıldığı anda tutulduğunda ofisteki ikinci giriş ortadan kalkar ve bilgi aynı gün içinde ilgili kişiye ulaşır. Sahadaki kişi form doldurmak için işini bölmez, ofistekiler de akşamı beklemek zorunda kalmaz. Aradaki bu kısa mesafe, gün içinde alınan kararların isabetini doğrudan etkiler.

Dış sistemlerle bağlantıyı ölçülü kurmak

Bir uygulama nadiren tek başına çalışır; muhasebe tarafı, kargo tarafı, ödeme altyapısı ya da bir tedarikçinin kendi sistemi er geç devreye girer. Her bağlantı yeni bir bağımlılık demektir ve karşı taraf bir gün yavaşladığında veya yanıt vermediğinde ne olacağı baştan düşünülmelidir. Bu yüzden özel yazılım kurgusunda bağlantılar, işin tümden durmasına yol açmayacak biçimde ele alınır.

Her bağlantı için verinin hangi yöne aktığını, hangi kaydın hangi tarafta doğru kabul edileceğini ve çakışma olduğunda hangisinin üstün geleceğini yazıya döküyoruz. Karşı sistemin belgelenmiş bir arayüzü varsa onun üzerinden ilerliyor, yoksa aktarımın el yordamıyla değil tanımlı bir dosya düzeniyle yapılmasını sağlıyoruz. Deneme ortamında sınanmadan hiçbir bağlantı yayına alınmıyor.

Bağlantı kurallı yürüdüğünde aynı bilginin iki yere elle girilmesi gereği ortadan kalkar. Karşı taraftan gelen bir aksama ise tüm işleyişi kilitlemek yerine tek bir başlıkta birikir ve düzeldiğinde tamamlanır. Böylece dışarıdaki bir arıza içerideki işin ölçüsünü bozmaz.

Bir aksaklığın izini kayıttan sürebilmek

Yazılımda hata olmaması değil, olduğunda ne yapıldığı belirleyicidir. Kullanıcıya anlamsız bir uyarı gösterip arkada hiçbir iz bırakmayan bir sistemde aynı sorun aylarca tekrar eder; çünkü kimse nereye bakacağını bilmez. Kayıt tutmanın amacı sorumlu aramak değil, aksaklığın hangi koşulda ortaya çıktığını tarif edebilmektir.

Hata anında kullanıcının ne yapmaya çalıştığını, hangi kaydı işlediğini ve sistemin hangi adımda durduğunu birlikte kaydediyoruz. Kişisel bilgilerin bu kayıtlara düşmemesine dikkat ediyor, yinelenen sorunların dağınık satırlar hâlinde değil tek başlık altında toplanmasını sağlıyoruz. Kullanıcıya gösterilen mesajı ise teknik ayrıntı yerine ne yapması gerektiğini söyleyecek biçimde yazıyoruz.

İz düzgün tutulduğunda bir şikâyet, uzun yazışmalar yerine kısa bir incelemeyle karşılık bulur. Hangi sorunun kaç kez yaşandığı görüldüğü için öncelik sırası da tahminle değil sıklıkla belirlenir. Bakım böylece her seferinde baştan başlayan bir arayış olmaktan çıkar.

Oturum ve erişimi denemelerle sınamak

Güvenlik, bir kez kurulup kenara bırakılan bir ayar değil sürekli sınanması gereken bir düzendir. Yetkisiz bir adresin doğrudan çağrılması, süresi dolmuş bir oturumun kullanılmaya devam etmesi ya da bir kullanıcının kendi kaydı dışındaki bir kayda ulaşabilmesi ancak denenerek görülür. Bu denemeler yapılmadığında eksik, çoğu zaman en kötü anda kendini gösterir.

Her rol için yalnızca yapabildiklerini değil, yapamaması gerekenleri de ayrı ayrı deniyoruz. Oturum süresinin dolması, şifre değişiminden sonra açık kalan girişlerin kapanması ve arka arkaya başarısız denemelerin sınırlanması gibi durumları ayrı senaryolar hâlinde sınıyoruz. Dosya yüklenebilen alanlarda tür ve boyut denetimi de aynı titizlikle ele alınıyor.

Denemeler tamamlandığında hangi kontrolün hangi senaryoyla sınandığı yazılı olarak elde kalır. Sonradan bir değişiklik yapıldığında aynı senaryolar yeniden çalıştırılır; böylece kapatılmış bir açık, yeni bir eklemeyle sessizce geri gelmez. Denetim ya da müşteri sorusu geldiğinde de anlatılacak bir kayıt bulunur.

Yedeğin değil geri dönüşün denenmiş olması

Yedek almak pek çok kurumda yapılır; asıl soru o yedekten dönülüp dönülemediğinin hiç denenip denenmediğidir. Dosya duruyor diye güvenilen bir kopya, ihtiyaç anında eksik ya da okunamaz çıkabilir. Özel yazılım teslim edilirken bu nedenle yalnızca kopyalama değil, geri dönüş adımları da yazılı hâle getirilir.

Hangi verinin ne sıklıkla kopyalanacağını, kopyaların nerede ve ne kadar süre tutulacağını işin niteliğine göre belirliyoruz. Geri dönüşü deneme ortamında bir kez fiilen uyguluyor, ne kadar sürdüğünü ve hangi adımda kimin devreye girmesi gerektiğini kaydediyoruz. Yüklenmiş dosyaların ve ayarların da veriyle birlikte kopyalanmasını gözden kaçırmıyoruz.

Bu hazırlık yapıldığında olağandışı bir durum telaşla değil, önceden yazılmış bir sırayla karşılanır. Ne kadar veri kaybının göze alınabileceği baştan konuşulduğu için beklenti de gerçekçi olur. Karar anında kimsenin hafızasına ihtiyaç duyulmaz.

Değişiklikleri işi durdurmadan yayına almak

Yayındaki bir uygulamada yapılan en küçük düzeltme bile o gün çalışan bir ekibin işine dokunur. Doğrudan canlı ortamda yapılan müdahaleler kısa vadede hızlı görünse de geri alınamayan bir hata için hiçbir pay bırakmaz. Bu yüzden değişikliğin nasıl yayımlandığı, ne yayımlandığı kadar belirleyicidir.

Her değişikliği önce ayrı bir ortamda çalıştırıyor, gerçek veriye benzeyen örneklerle sınıyor ve ancak ondan sonra yayına alıyoruz. Yayın öncesinde neyin değiştiğini sade bir dille yazıyor, geri alma adımını da aynı anda hazırlıyoruz. Yoğun saatlerde yayın yapmamayı ise ayrı bir kural olarak koruyoruz.

Bu düzen kurulduğunda yeni bir özellik eklemek, mevcut işleyişi riske atan bir karar olmaktan çıkar. Bir aksama görüldüğünde hangi değişiklikten sonra başladığı bilindiği için arayış kısalır. Ekip de güncelleme gününü tedirginlikle değil sıradan bir iş olarak karşılar.

Teslimi eğitimle ve belgeyle tamamlamak

Bir çalışmanın bittiği an, dosyaların yüklendiği an değil ekibin işini o uygulamayla yürütmeye başladığı andır. Kullanımı anlatılmadan bırakılan bir sistem, en iyi kurulmuş hâliyle bile eski alışkanlıkların yanında ikinci sırada kalır. Teslim bu nedenle tek bir oturum değil, karşılığı görülebilen bir aşamadır.

Eğitimi her rol için ayrı yapıyor, kişiye günlük işinde karşılaşacağı ekranları kendi verisiyle gösteriyoruz. Oturumları Kütahya içindeki ekiplerle yerinde, uzaktaki kullanıcılarla aynı içerik üzerinden çevrim içi yürütüyoruz. Sık sorulan noktaları kısa notlar hâlinde yazıya döküyor, yönetici tarafındaki ayarları ayrı bir oturumda ele alıyoruz. Hesapların, alan adının ve barındırma erişimlerinin kimde olduğu da teslim sırasında teyit ediliyor.

Kayıtlar eksiksiz devredildiğinde işletme kendi sistemine kendi başına hâkim olur; küçük bir değişiklik için her seferinde dışarıya bağlı kalmaz. Ekibe yeni katılan biri de anlatılanlara değil, yazılı olana bakarak başlar. Sonraki geliştirmeler ise sıfırdan tanışmayla değil, elde duran bir zeminle konuşulur.

Yazılım Geliştirme Sürecine Dair Sık Sorulan Sorular

Hazır paketler yaygın ihtiyaçlar için hazırlanır ve pek çok işletmenin işini fazlasıyla görür. Tercih, ancak işin bir bölümü pakete hiç sığmadığında ya da her ay elle yapılan bir düzeltmeyle ayakta tutulduğunda değişir; kendine özgü bir hesaplama, paketin tanımadığı bir yetki ayrımı veya başka bir sistemle kurulması gereken bir aktarım bunun tipik göstergesidir. Böyle durumlarda özel yazılım ek bir masraf değil, tekrar eden el emeğinin yerine geçen bir çözüm olarak değerlendirilir.

Süre, ekran sayısına değil işin içerdiği karar noktalarına bağlıdır. Roller, iş kuralları, dış bağlantılar ve sınanacak durumlar çıkarıldıktan sonra çalışma aşamalara bölünür ve her aşamanın kendi takvimi olur. İlk aşama yayına alınıp fiilen kullanılmaya başlandığında geri kalanın süresi de daha gerçekçi hesaplanır.

Karşı sistemin dışarıya açık ve belgelenmiş bir arayüzü varsa bağlantı kurulabilir. Bu durumda verinin hangi yöne akacağı, çakışma hâlinde hangi kaydın esas alınacağı ve hata durumunda ne yapılacağı baştan tanımlanır. Böyle bir arayüz yoksa dosya üzerinden düzenli aktarım da değerlendirilebilir; hangisinin uygun olduğu incelemeden sonra netleşir.

Bu konunun çalışma başlamadan sözleşmede yazılı hâle getirilmesi gerekir. Alan adı, barındırma ve üçüncü taraf servislerdeki hesapların işletme adına açılması, sonradan yaşanabilecek erişim sorunlarını baştan önler. Kaynakların teslim biçimi ve kapsamı da aynı belgede açıkça belirtilir.

Bakım tek bir başlık değildir; hata giderme, güvenlik güncellemeleri, izleme ve yeni özellik geliştirme ayrı ayrı ele alınır. Hangisinin ne kapsamda ve hangi süre içinde karşılanacağı baştan yazılırsa sonradan beklenti farkı oluşmaz. Acil sayılacak durumların tanımı da aynı aşamada yapılır.

Yapı, bugünkü kullanımın yanı sıra öngörülen büyümeye göre kurulur; veri hacmi ve eşzamanlı kullanıcı sayısı bu kararın temelidir. Özel yazılım tarafında bu, en baştan en geniş kurulumu yapmak anlamına gelmez; yavaşlamanın hangi noktada başlayacağının bilinmesi ve ölçümle izlenmesi anlamına gelir. Kapasite kararları böylece tahminle değil, elde duran ölçümlerle alınır.