Yazılım

İş akışını koddan önce görünür kılmak

Bir işi yazılıma dökmeden önce o işin gerçekte nasıl yürüdüğünü adım adım görmek gerekir; aksi halde kod, var olan karışıklığı yalnızca hızlandırır. Ordu’da gelen talebi büyük ölçüde dijital kanallardan toplayan bir ekip için kurduğumuz özel yazılım çalışmasında, önce süreci birlikte çiziyor, ancak üzerinde anlaştıktan sonra geliştirmeye başlıyoruz.
Süreci çıkarırken kimin hangi adımda ne yaptığını, hangi bilginin nereden geldiğini ve nerede beklediğini tek tek not ediyoruz. Ekibin günlük diliyle konuşan bu haritayı, teknik bir belgeye çevirmeden önce sahadaki kişilere doğrulatıyoruz.
Akışı geliştirmeye almadan önce her adımı örnek verilerle kağıt üzerinde yürütüyoruz. Bir adım belirsiz kalıyor ya da iki yol birbirine giriyorsa bunu koda taşımadan çözüyor; böylece sonradan pahalıya mal olacak yanlış anlamaları baştan ayıklıyoruz.

Kullanıcı rollerini ve yetkileri açıkça tanımlamak

Bir sistemde herkesin her şeyi görebilmesi kolaylık gibi görünse de zamanla hem karışıklık hem risk üretir. Üretim ve bayilik kayıtlarını aynı anda tutan bir işletmede, kimin neyi görebileceği ve değiştirebileceği baştan belli olmalıdır. Rolleri, işin gerçek sorumluluk dağılımına göre tanımlıyoruz.
Yetki haritasını çıkarırken hangi ekranı kimin açması, hangi kaydı kimin düzeltebilmesi gerektiğini tek tek yanıtlıyoruz. İstisnaları da not ediyor; sonradan gelen tekil talepler sistemi bozmasın diye kuralları esnek ama izlenebilir kuruyoruz.
Devreye almadan önce her rolü ayrı ayrı deniyoruz: yetkisi olmayan biri kapalı bir alana ulaşabiliyor mu, yetkili biri işini engelsiz yapabiliyor mu. Açık kalan bir kapı ya da gereksiz bir kısıt bulduğumuzda, dengeyi kullanımı zorlaştırmadan düzeltiyoruz.

Veri kaynaklarını tek kurala bağlamak

Aynı bilginin birkaç yerde farklı biçimde tutulması, zamanla hangisinin doğru olduğunun bilinmediği bir kargaşaya dönüşür. Malını farklı illerdeki alıcılara ulaştıran bir ticaret ekibi için tek bir doğru kaynak şarttır. Ordu çevresinde fındık alımından sevkiyata uzanan kayıtların dağınık tutulduğu işlerde, bu kuralı en baştan koyuyoruz.
Hangi verinin nerede, hangi biçimde ve kimin sorumluluğunda tutulacağını önce belgeliyoruz. Aynı bilginin iki yerde birden girildiği noktaları bulup teke indiriyor; geri kalan ekranların bu tek kaynaktan beslenmesini sağlıyoruz.
Kuralın gerçekten tuttuğunu, veriyi bilerek çelişkili girmeye çalışarak sınıyoruz. Sistem aynı kaydın iki farklı hâlini sessizce kabul ediyorsa bunu engelliyor; doğru bilginin her ekranda aynı görünmesini devreye almadan önce güvenceye alıyoruz.

Tekrarlanan işlemleri otomasyona taşımak

Elle yapılan her tekrar hem zaman hem de hata payı taşır; aynı bilgiyi her gün yeniden girmek, kişinin asıl işine ayıracağı dikkati tüketir. Rezervasyon ve program bilgisini yöneten bir turizm işletmesinde bu yük özellikle görünürdür. İyi kurgulanmış bir sistem, tekrarlayan işi kişinin sırtından alıp arka planda düzenli biçimde yürütür.
Neyin otomatikleşeceğine, gerçekten her seferinde aynı biçimde yapılan işleri ayıklayarak karar veriyoruz. Kural netse ve istisnası azsa otomasyona uygun sayıyor; karar gerektiren, değişken işleri ise insanın elinde bırakıyoruz.
Bir işlemi otomatiğe bağlamadan önce yanlış çalıştığı durumları bilerek üretiyoruz: eksik bilgi, beklenmedik giriş, yarıda kesilme. Otomasyonun sessizce hatalı sonuç üretmesindense, fark edilir biçimde durup uyarması için bu senaryoları önceden kuruyoruz.

Hata durumları için geri dönüş planı kurmak

Hiçbir sistem her koşulda kusursuz çalışmaz; asıl fark, bir şey ters gittiğinde ne olacağının önceden düşünülüp düşünülmediğidir. Sevkiyat ile hizmet ayrıntısını tek yerden yürüten bir kuruluşta beklenmedik bir kesinti işi tümüyle durdurmamalıdır. Bu yüzden hata anını da tasarımın bir parçası sayıyoruz.
Nelerin ters gidebileceğini baştan listeliyoruz: bağlantı kopması, eksik veri, iki işlemin çakışması. Her biri için sistemin nasıl davranacağını, kullanıcının ne göreceğini ve verinin nasıl korunacağını önceden karara bağlıyoruz.
Geri dönüş planını, hataları bilerek tetikleyerek sınıyoruz. Yarıda kalan bir işlem geride bozuk bir kayıt bırakıyor mu, kullanıcı ne yapacağını anlıyor mu diye bakıyor; sistemin çökmek yerine güvenli bir noktaya dönmesini devreye almadan önce doğruluyoruz.

Entegrasyon sınırlarını belgelerle netleştirmek

Bir sistemin başka bir sistemle konuşması çoğu zaman en kırılgan noktadır; çünkü sınırlar belirsizse sorumluluk da belirsiz kalır. Yöredeki üretimi geniş bir alıcı kitlesine ulaştıran bir markada, dış bir hizmete bağlanan her nokta önceden tanımlanmalıdır. Nereye kadar bizim, nereden sonra karşı tarafın sorumlu olduğunu belgeyle netleştiriyoruz.
Entegrasyonu kurmadan önce hangi bilginin gidip hangisinin geleceğini, ne sıklıkla ve hangi biçimde aktarılacağını yazıya döküyoruz. Karşı tarafın erişim kurallarını ve sınırlarını da bu belgeye ekliyor; sözlü anlaşmalara güvenip belirsizlik bırakmıyoruz.
Bağlantıyı canlıya almadan önce, karşı taraf yanıt vermediğinde ya da beklenmedik bir veri döndürdüğünde ne olacağını deniyoruz. Bir aksaklık bütün işi kilitlemesin diye sınırı koruyor; entegrasyonun kendi sorunlarını sisteme bulaştırmadan yönetmesini sağlıyoruz.

Mobil kullanım senaryolarını erken sınamak

Bir aracın çoğunlukla masa başında mı yoksa sahada telefonla mı kullanılacağı, tasarımın en başında bilinmelidir. Siparişlerini uygulama üzerinden alan bir markada işin büyük kısmı hareket hâlinde, küçük ekranda yürür. Bu yüzden geliştirdiğimiz özel yazılım, mobil kullanımı sonradan eklenen bir uyarlama değil çıkış noktası olarak ele alır.
Mobil senaryoları gerçek kullanım koşullarını konuşarak çıkarıyoruz: tek elle giriş, zayıf bağlantı, güneş altında okunurluk, acele. Hangi işlemin sahada gerçekten gerektiğini ayırıyor; masabaşına ait olanları küçük ekrana zorla sığdırmıyoruz.
Ekranları erken aşamada gerçek telefonlarda deniyoruz; çünkü bilgisayarda düzgün görünen bir akış elde bambaşka davranabilir. Dokunma alanları, bekleme anları ve kesintiden sonra kaldığı yere dönme gibi ayrıntıları iş büyümeden önce yerine oturtuyoruz.

Güvenlik kararlarını mimariye yerleştirmek

Güvenlik, bitmiş bir sisteme sonradan eklenen bir kilit değil, temelden verilen bir dizi karardır. Hem imalat hem satış tarafını yöneten bir firmada kimin neye eriştiği ve verinin nasıl saklandığı baştan doğru kurulmalıdır. Sağlam bir özel yazılım, güvenliği en baştan mimarinin içine yerleştirir ve sonraki her adımı bu zemine göre atar.
Hangi verinin hassas olduğunu, kimin görmesi gerektiğini ve ne kadar süre tutulacağını önce konuşuyoruz. Erişimi en aza indiren, her önemli işlemi iz bırakacak biçimde kaydeden bir düzeni tasarımın ilk kararları arasına koyuyoruz.
Kararların gerçekten koruduğunu, sistemi kötüye kullanma denemeleriyle sınıyoruz: yetkisiz erişim, beklenmedik giriş, sınır aşımı. Bulunan her açığı devreye almadan önce kapatıyor; güvenliği tek seferlik bir kontrol değil, mimaride yaşayan bir ilke olarak tutuyoruz.

Raporlamayı gerçek yönetim sorularına bağlamak

Bir rapor ancak yöneticinin gerçekten sorduğu soruya yanıt veriyorsa işe yarar; aksi halde kimsenin bakmadığı bir sayı yığınına dönüşür. Ordu’da geniş bir müşteri ağına sevkiyat yapan bir ekip için önemli olan, ekranı sayılarla doldurmak değil bugün neye karar vermeli sorusuna açık bir cevap üretmektir. Raporları bu sorulardan geri doğru kuruyoruz.
Hangi bilginin raporlanacağına, yönetimin düzenli olarak verdiği kararlara bakarak karar veriyoruz. Karar değiştirmeyen süslü göstergeleri dışarıda bırakıyor; her sayının hangi eyleme yol açtığını baştan tanımlıyoruz.
Raporu yaymadan önce geçmiş gerçek verilerle çalıştırıp sonucun bilinen durumla örtüşüp örtüşmediğini kontrol ediyoruz. Bir gösterge yanıltıcı çıkıyorsa hesabı düzeltiyor; yöneticinin yanlış bir sayıya güvenerek karar vermesini baştan engelliyoruz.

Sürüm ve bakım planını teslimin parçası yapmak

Bir sistem teslim edildiği anda donup kalmaz; kullanıldıkça yeni ihtiyaçlar doğar, düzeltmeler gerekir. Konaklama ve tur kaydını takip eden bir girişimde her değişikliğin, çalışan düzeni bozmadan yapılabilmesi gerekir. Bu yüzden sürüm ve bakım yöntemini işin başında planın içine koyuyoruz.
Bakımı belirsizliğe bırakmamak için değişikliklerin nasıl yapılacağını, nasıl deneneceğini ve nasıl yayına alınacağını önceden yazıyoruz. Yeni bir sürüm çıkarken eski verinin ve alışkanlıkların korunması için de bir yol tanımlıyoruz.
Yeni bir sürümü doğrudan canlıya vermiyor; önce ayrı bir ortamda, gerçek işe benzer verilerle deniyoruz. Bir değişiklik başka bir yeri bozuyorsa bunu kullanıcıya ulaşmadan yakalıyor; güncellemenin günlük işi durdurmadan geçmesini sağlıyoruz.

Kullanıcı eğitimini gerçek görevlerle tamamlamak

Bir aracın ne kadar iyi tasarlandığı, onu kullanacak kişi kendini rahat hissetmiyorsa pek anlam taşımaz. Taşıma ve randevu bilgisini birlikte tutan bir kurumda eğitim, uzun bir kılavuzu okutmak değil günlük işleri sistemin üstünde birlikte yapmaktır. Bu yüzden eğitimi gerçek görevler üzerinden yürütüyoruz.
Eğitime hazırlanırken her rolün gün içinde en sık yaptığı işleri bir sıraya diziyoruz. Genel bir tanıtım yerine, kişinin kendi ekranında kendi işini baştan sona yapabildiği kısa ve somut adımlar hazırlıyoruz.
Eğitimi tamamlanmış saymadan önce, kullanıcının bir görevi desteksiz yürütebildiğini görüyoruz. Takıldığı nokta bir bilgi eksikliğinden değil de ekranın kendisinden kaynaklanıyorsa, kılavuzu değil sistemi sadeleştiriyoruz.

Teslim sonrasındaki sorumlulukları açıkça belgelemek

Bir işin nerede bittiği, nerede yeni bir sorumluluğun başladığı belirsizse, sorun çıktığında herkes bir diğerine bakar. Yerel üretimini kayıt altında büyüten bir işletme için teslim, kimin neyden sorumlu olduğunun yazılı hâle geldiği andır. Bir özel yazılım tesliminde hesapları, erişimleri ve belgeleri eksiksiz devrediyor; kalan sorumlulukları da açıkça yazıyoruz.
Devir öncesinde neyin teslim edileceğini bir liste hâlinde çıkarıyoruz: hesaplar, erişim bilgileri, kaynaklar ve kullanım belgeleri. Hangi işin bizde, hangisinin işletmede kalacağını da bu listeye bağlıyor; sözlü kalan hiçbir sorumluluk bırakmıyoruz.
Teslimi tamamlamadan önce devredilen erişimlerin gerçekten çalıştığını işletmeyle birlikte deniyoruz. Bir hesap açılmıyor ya da bir belge eksik kalıyorsa yayına almadan tamamlıyor; devrin kağıt üzerinde değil uygulamada bittiğinden emin oluyoruz.

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

Süre; kullanıcı rolleri, ekran sayısı, veri yapısı, entegrasyonlar ve test senaryoları netleştikten sonra çıkarılır. Bunlar belirlendiğinde iş, tek bir tahmin yerine aşamalı bir takvime bağlanır ve her aşamanın sonunda görülebilir bir çıktı hedeflenir.
İş akışı hazır araçlarla güvenli ve verimli biçimde karşılanabiliyorsa çoğu zaman en doğrusu odur. Ancak süreç bu araçlara sığmıyor, zorlama uyarlamalar risk ve fazladan emek üretiyorsa işe özel bir çözüm değerlendirilir.
Kullanılan sistemin teknik erişimi ve veri kuralları uygunsa entegrasyonun kapsamı belgelenerek planlanır. Erişim sınırlı ya da kapalıysa bu durum baştan konuşulur; belirsiz bir bağlantıya güvenip ilerlenmez.
Evet. Hesaplar, erişimler, kullanım dokümanı ve gerekli teknik teslimler sözleşmedeki kapsam doğrultusunda işletmeye aktarılır. Amaç, işletmenin kendi sistemini kendi denetiminde tutabilmesidir.
Hata giderimi, düzenli bakım ve yeni geliştirme birbirinden ayrı iş türleri olarak kayıt altına alınır. Her talep önceliğine göre sıralanır; böylece acil bir düzeltme ile uzun vadeli bir ekleme birbirine karışmaz.
Yetkilendirme, işlem kaydı tutma, yedekleme ve hata senaryoları ayrı bir aşama değil, mimari kararların bir parçası olarak değerlendirilir. Kimin neye eriştiği ve verinin nasıl korunduğu, sistemin en başından itibaren tanımlanır.