Yazılım

İşin sırası ilk ekrandan önce netleşiyor

Bir geliştirme talebi çoğu zaman ekran diliyle geliyor: şu liste şurada görünsün, şu düğme sayfanın üstünde dursun. Oysa ekran, işin yalnızca en son görünen yüzü. Özel yazılım kararı da ancak işin kendisi konuşulduktan sonra olgunlaşıyor; bir talebin nereden doğduğunu, hangi ellerden geçtiğini ve nerede karara bağlandığını adım adım yazıya geçiriyoruz.

Bu çözümlemeyi toplantı odasında değil, işin yapıldığı masada yürütüyoruz. Aynı bilginin kaç ayrı yerde tutulduğu, hangi adımın düzenli olarak başa sarıldığı ve kimin kimden bilgi beklediği ancak orada görünür oluyor. Anlatılan düzenle kayıtlara yansıyan düzen arasındaki fark, geliştirmenin gerçek kapsamını belirliyor.

Ortaya çıkan akışı işi yapan kişilerle birlikte okuyoruz; itiraz gelen her nokta kodlanmadan önce düzeltiliyor. Bu okuma, Sakarya’da görüştüğümüz işletmelerde çoğu zaman kimsenin ayrıca dile getirmediği bir adımı da gün yüzüne çıkarıyor. Böylece geliştirme, varsayımların değil üzerinde uzlaşılmış bir düzenin üstüne kuruluyor.

Yetki, kişinin taşıdığı sorumlulukla eşleşiyor

Yetkilendirme çoğunlukla unvan listesinden yola çıkılarak kuruluyor; oysa aynı unvanı taşıyan iki kişinin gün içinde dokunduğu işler birbirinden ayrılabiliyor. Rolleri tanımlarken sorduğumuz soru basit kalıyor: bu kişi hangi kaydı açıyor, hangisini değiştiriyor, hangisini yalnızca görüyor ve hangisine hiç erişmiyor.

Yanıtları tek tek çıkardıktan sonra rolleri gerçek sorumluluk sınırlarına oturtuyoruz. Geniş tutulan bir yetki ilk bakışta işi hızlandırıyor gibi görünse de yanlış düzeltmelerin ve sonradan kaynağı bulunamayan değişikliklerin önünü açıyor. Fazla dar tutulan yetki ise çalışanları sürekli birbirinden erişim istemeye itiyor.

Dengeyi kurarken yetkinin sonradan değiştirilebilmesine de dikkat ediyoruz. İşe yeni katılan birine erişim açmak ya da ayrılan birinin erişimini kapatmak, geliştiriciye haber verilmeden yönetim ekranından yapılabiliyor. Kimin neyi ne zaman değiştirdiği arka planda kayda geçtiği için sonradan geriye dönüp bakmak da mümkün oluyor.

Alan adları tek bir tanım listesinde buluşuyor

Aynı işletmenin iki biriminde aynı kayda farklı adlar verilmesi sık karşılaşılan bir durum. Biri müşteri numarası diyor, diğeri cari kod; biri teslim tarihini malın çıktığı gün, diğeri faturanın kesildiği gün olarak anlıyor. Tablolar tek tek bakıldığında doğru duruyor, yan yana getirildiğinde tutmuyor.

Bu nedenle geliştirmeye geçmeden önce alanların ortak bir tanım listesini çıkarıyoruz. Her alanın adı, neyi ifade ettiği, hangi biçimde girileceği ve boş bırakılıp bırakılamayacağı tek bir belgede toplanıyor. Bir özel yazılım çalışmasında bu belge, sonradan çıkacak pek çok tartışmayı daha başlamadan kapatıyor.

Liste yalnızca geliştirme sırasında işe yaramıyor. Sonradan rapor isteyen, yeni bir alan ekletmek isteyen ya da veriyi başka bir ortama taşıyan herkes aynı belgeye bakıyor. Ekrandaki başlıkla veritabanındaki alanın aynı şeyi anlatmaya devam etmesi de bu sayede sağlanıyor.

Onay sırası ekibin ortak görüş alanına giriyor

Onay bekleyen işlerin nerede durduğu bilinmediğinde takip, telefonla yapılan bir hatırlatma işine dönüşüyor. Kimin sırada olduğunu sormak zorunda kalan bir ekip, asıl işten çok durum sorgulamaya vakit ayırıyor. İşin hangi aşamada beklediği ekranda görünmedikçe bu döngü kapanmıyor.

Akışı kurarken her aşamanın sahibini, beklenen yanıt süresini ve gecikme hâlinde ne olacağını tanımlıyoruz. Onaylayan kişi neye onay verdiğini tek ekranda görüyor, reddederken gerekçe yazması isteniyor. Kayıt geri döndüğünde hangi adıma döneceği baştan belli olduğu için iş sıfırdan başlamıyor.

Geçmişe dönük izleme de aynı ekrandan yürüyor. Bir işlemin hangi gün kime geldiği ve ne kadar beklediği sonradan sorulabiliyor. Bu kayıt kimseyi denetlemek için değil, tıkanmanın hangi adımda tekrarlandığını görüp o adımı yeniden kurmak için tutuluyor.

Bildirim, işi olmayanın ekranına düşmüyor

Uyarı düzenleri çoğu zaman iyi niyetle geniş kuruluyor, kısa sürede de kimsenin okumadığı bir yığına dönüşüyor. Herkese giden bir bildirim aslında kimseye gitmemiş sayılıyor; sorumluluk dağıldıkça kimse o satırı kendi işi olarak görmüyor.

Kurgulamaya başlarken üç soruyu ayrı ayrı yanıtlıyoruz: bu olay kimi ilgilendiriyor, ne kadar sürede görülmesi gerekiyor ve hangi kanaldan ulaşması doğru oluyor. Beklemeye tahammülü olan hatırlatmalar günlük bir özete toplanıyor, gecikmesi maliyet yaratanlar ise anında iletiliyor.

Kullanıcıya kendi bildirim tercihini kısma imkânı da veriyoruz; kapatılamayan uyarılar zamanla göz ardı edilmeye başlıyor. Hangi bildirimin gönderildiği ve açılıp açılmadığı ayrıca tutuluyor, böylece karşılığı olmayan uyarılar yayından sonra sadeleştirilebiliyor.

Arayüz, sahadaki koşullar hesaba katılarak kuruluyor

Masa başında sorunsuz görünen bir ekran sahada bambaşka koşullarla karşılaşıyor: tek elle tutulan bir telefon, güneş altında okunmayan bir yazı, bağlantının zayıfladığı bir depo köşesi. Kullanım yeri hesaba katılmadan kurulan uygulamalar, en çok ihtiyaç duyulduğu anda kenara bırakılıyor.

Bu yüzden sahada kullanılacak ekranları ayrı düşünüyoruz. Zorunlu alan sayısını azaltıyor, seçim listelerini kısaltıyor, en sık yapılan işlemi ilk dokunuşa yaklaştırıyoruz. Bağlantı koptuğunda kayıt cihazda bekliyor, hat geri geldiğinde ise çakışma yaratmadan gönderiliyor.

Denemeleri ofis ağında değil, işin gerçekten yapıldığı yerde yürütüyoruz. Eldiven takan bir kullanıcının dokunamadığı bir düğme ya da tek elle uzanılamayan bir alan, ancak yerinde yapılan denemede ortaya çıkıyor. Çıkan notlar yayına geçilmeden önce düzeltiliyor.

Dış bağlantılar sınırı çizilmiş biçimde açılıyor

Bir uygulamanın tek başına çalıştığı durum artık seyrek görülüyor. Muhasebe tarafı, kargo tarafı, ödeme sağlayıcısı derken bağlantı sayısı hızla artıyor. Her yeni bağlantı bir kolaylık getiriyor, aynı zamanda dışarıda yaşanan bir aksaklığın içeriye taşınma ihtimalini de beraberinde getiriyor.

Bu nedenle bağlantıların sınırını önceden çiziyoruz. Hangi bilginin hangi yöne aktığı, karşı taraf yanıt vermediğinde ne yapılacağı ve aynı kaydın iki kez gitmesinin nasıl engelleneceği baştan tanımlanıyor. Erişim bilgileri kodun içine gömülmüyor, ayrı ve değiştirilebilir bir yerde tutuluyor; hazır paketlerle özel yazılım arasındaki fark da en çok burada görünür oluyor.

Karşı sistemin yavaşladığı ya da tamamen durduğu anlarda uygulamanın kendi işini sürdürebilmesi önem taşıyor. Aktarımı bekleyen kayıtlar sıraya alınıyor, yeniden denenmesi gereken adım işaretleniyor ve durum, konuyla ilgili kişiye teknik olmayan bir dille aktarılıyor.

Kayıtlar, sorunun kaynağını gösterecek ayrıntıda tutuluyor

Bir aksaklık bildirildiğinde ilk kaybedilen şey genellikle zaman oluyor. Kullanıcı ne yaptığını tam hatırlamıyor, ekran görüntüsü tek başına yetmiyor, aynı adım tekrar denendiğinde sorun ortaya çıkmıyor. Arkada düzgün bir kayıt tutulmuyorsa geriye tahminle ilerlemek kalıyor.

Kayıtları okunabilir tutmayı bu yüzden geliştirmenin ayrılmaz bir parçası sayıyoruz. Hangi kullanıcının hangi işlemi denediği, isteğin hangi adımda takıldığı ve o sırada sistemin hangi yanıtı verdiği anlaşılır biçimde yazılıyor. Kişisel bilgiler ise kayda düşerken gizleniyor.

Toplanan kayıt yalnızca sorun çıktığında açılan bir dosya olarak durmuyor. Tekrar eden uyarılar belirli aralıklarla gözden geçiriliyor; aynı adımda biriken hatalar, o adımın kurgusunda bir aksaklık olduğunu gösteriyor. Düzeltme de çoğu zaman koddan önce akışın kendisinde yapılıyor.

Güvenlik, gerçek denemelerle sınanıyor

Yetki tablosunun kâğıt üstünde doğru görünmesi, uygulamanın o tabloya uyduğu anlamına gelmiyor. Ekranda görünmeyen bir sayfanın adresine doğrudan gidilebiliyor, başkasına ait bir kaydın numarası elle değiştirilebiliyor. Bu tür açıklar ancak deneyerek ortaya çıkıyor.

Sınamayı senaryolar üzerinden yürütüyoruz. Sınırlı yetkili bir hesapla yönetim ekranlarına ulaşmayı, oturumu açık bırakıp uzun süre sonra geri dönmeyi ve şifre değiştirildikten sonra eski oturumun geçerliliğini korumasını tek tek deniyoruz. Çıkan her bulgu düzeltildikten sonra aynı adımla yeniden kontrol ediliyor.

Oturum süresini işin ritmine göre belirliyoruz. Ortak kullanılan bir cihazda süre kısalıyor, gün boyu tek kişinin oturduğu bir ekranda gereksiz kesintiden kaçınılıyor. Yönetim yetkisi taşıyan hesaplarda ek bir doğrulama adımı öneriyor, bunun gerekçesini de işletmeye açıkça anlatıyoruz.

Geri dönüş, yedek alındığı gün deneniyor

Yedekleme pek çok işletmede kurulduğu gün bir kez konuşuluyor, sonra unutuluyor. Oysa asıl soru yedeğin alınıp alınmadığı değil, gerektiğinde geri yüklenip yüklenemediği. Hiç denenmemiş bir yedek, işe yaramadığı ancak en kötü anda fark edilen bir dosya olarak kalıyor.

Planı kurarken yedeğin hangi sıklıkta alınacağını, nerede saklanacağını ve ne kadar süre tutulacağını yazıyoruz. En fazla ne kadarlık bir kaybın kabul edilebileceği ve işin en çok ne kadar durabileceği ise işletmeyle birlikte kararlaştırılıyor; teknik seçimler bu iki yanıta göre şekilleniyor. Kopyalardan birinin Sakarya dışındaki bir konumda tutulması da aynı başlık altında konuşuluyor.

Teslimden önce geri dönüş provası yapıyoruz. Yedek ayrı bir ortamda açılıyor, veriler kontrol ediliyor ve adımların ne kadar sürdüğü not ediliyor. Gerçek bir kayıp yaşandığında kimin ne yapacağı böylece tartışma konusu olmuyor, hazır bir yol izleniyor.

Yeni sürüm, çalışan düzeni bozmadan devreye giriyor

Çalışan bir uygulamaya dokunmak, sıfırdan geliştirme yapmaktan daha fazla dikkat istiyor. Kullanıcılar alıştıkları düzende ilerliyor, veriler birikmiş durumda ve işin durması doğrudan maliyet anlamına geliyor. Yayına alınmış bir özel yazılım üzerinde bu nedenle değişiklikleri doğrudan canlı ortama bırakmıyoruz.

Her değişiklik önce ayrı bir ortamda toplanıyor, gerçek verinin bir kopyası üzerinde deneniyor ve işin sahibi tarafından görülüyor. Yayın için günün yoğun olmayan bir saati seçiliyor; geri alma adımı ise yayına çıkılmadan önce hazırlanıyor.

Yayından sonraki ilk saatlerde hata kayıtlarını ve işlem hacmini izliyoruz. Beklenmedik bir durum görülürse önceki sürüme dönmek tartışma konusu olmaktan çıkıyor, tanımlı bir adım olarak uygulanıyor. Yapılan değişiklikler tarihiyle birlikte ayrıca kayda geçiyor.

Teslim, eğitim ve yazılı kayıtla kapanıyor

Bir uygulamanın yayına alınması işin bittiği an değil. Teslim aşamasında Sakarya’daki ekiplerle yürüttüğümüz oturumlar bunu tekrar tekrar gösteriyor: ekranları günlük olarak kullanacak kişiler yeni düzeni öğrenmedikçe eski yöntem sessizce yanında yaşamaya devam ediyor.

Eğitimi rollere göre ayırıyoruz; herkesin her ekranı öğrenmesi gerekmiyor. Anlatımı işletmenin kendi verileri üzerinden yürütüyor, sık yapılan işlemleri katılımcılara bizzat yaptırıyoruz. Sorular not alınıyor, tekrar edenler kısa bir kullanım notuna dönüştürülüyor.

Teslim dosyasında hesapların nerede tutulduğu, hangi erişimin kimde olduğu, kurulumun hangi adımlarla tekrarlanabileceği ve bakımın neleri kapsadığı yazıyor. Bu kayıt, çalışmayı ileride başka birinin sürdürmesi gerektiğinde işletmenin elini güçlü tutuyor.

Yazılım Geliştirme Üzerine Sık Sorulan Sorular

Ayrım genellikle işin ne kadarının paketin dışında kaldığıyla ortaya çıkıyor. Ayda birkaç kez elle düzeltilen bir tablo, paketin tanımadığı bir onay sırası ya da iki program arasında insan eliyle taşınan bir veri varsa, o bölüm zaten yazılmayı bekliyor demektir. Böyle durumlarda özel yazılım, işi ayakta tutan el emeğini azaltan bir yöntem hâline geliyor.

Tek bir süre vermek yerine işi parçalara ayırıyoruz. Roller, ekranlar, iş kuralları, dış bağlantılar ve sınama senaryoları çıkarıldıktan sonra her parçanın süresi ayrı ayrı konuşuluyor. Takvim aşamalı ilerliyor; ilk bölüm kullanılabilir hâle geldiğinde kalan bölümlerin süresi gerçek kullanımdan gelen bilgiyle güncelleniyor.

Bağlantı, karşı sistemin dışarıya açtığı arayüze ve o arayüzün belgelenmiş olmasına göre kuruluyor. Çalışmaya başlamadan önce hangi bilginin hangi yöne akacağını, karşı taraf yanıt vermediğinde ne yapılacağını ve erişim yetkisinin kim tarafından verileceğini yazıya döküyoruz. Belgesi bulunmayan sistemlerde ise önce küçük bir deneme yapıp sonucu birlikte değerlendirmeyi öneriyoruz.

Sahiplik, çalışma başlamadan sözleşmede yazılı hâle getiriliyor. Alan adı, barındırma ve üçüncü taraf servislerin hesaplarının doğrudan işletme adına açılmasını öneriyoruz; erişim böylece baştan sizde kalıyor. Kaynak kodun hangi biçimde ve hangi ortam üzerinden devredileceği de aynı belgede yer alıyor.

Desteği birbirine karıştırılmaması gereken başlıklara ayırıyoruz: hata giderme, güvenlik güncellemeleri, izleme ve yeni özellik geliştirme. İlk üçü uygulamanın çalışır kalmasıyla ilgili olduğu için düzenli bir çerçevede yürüyor, yeni özellik ise ayrıca değerlendirilip planlanıyor. Hangi işin hangi başlığa girdiği baştan tanımlandığında sonradan yaşanan kapsam tartışmaları da ortadan kalkıyor.

Mimariyi kurarken bugünkü kullanımı değil, birkaç kat artmış hâlini düşünüyoruz; veri modeli ve bağlantı yapısı buna göre seçiliyor. Yayından sonra yanıt süreleri ve kayıt hacmi izlendiği için hangi bölümün ne zaman güçlendirileceği tahminle değil ölçümle belirleniyor. Büyüme anında gereken çoğu zaman sınırlı bir müdahale oluyor; özel yazılım baştan yazılmak zorunda kalmıyor.