Yazılım

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

Bir işletmenin gerçek ihtiyacı çoğu zaman ilk anlatıldığı gibi değildir; kod yazmadan önce işin nasıl aktığını görünür kılmak gerekir. Yoğun bir operasyonu İstanbul’da yöneten bir işletmede özel yazılım, hangi adımın kimden gelip kime gittiğini netleştirmeden yazılmaya başlanmamalıdır. Önce akışı çizer, sonra çözümü kurarız.

Tahmin yürütmek yerine eldeki belgeleri, ekibin günlük alışkanlıklarını ve gerçek örnek durumları birlikte inceleriz. Hangi ekranın kime gerektiğini, hangi kararın nerede verildiğini ve hangi bilginin nereye yazıldığını tek bir akış üzerinde toplarız. Bu ortak resim, sonraki her kararı kolaylaştırır.

Bu akışı yalın bir şema ve birkaç örnek senaryo üzerinden ekiple birlikte gözden geçiririz. Yanlış anlaşılan bir adımı kâğıt üzerinde düzeltmek, aynı hatayı çalışan bir sistemde bulup onarmaktan çok daha kolaydır. Herkes aynı resmi onayladığında geliştirme başlar.

Kullanıcı rollerini görev ve yetkiye göre ayırmak

Bir sistemi herkesin aynı yetkiyle kullanması, hem güvenlik hem düzen açısından sorun yaratır. Kimin neyi görebileceğini, neyi değiştirebileceğini ve neyi onaylayabileceğini rollere göre ayırırız. Rol ayrımı, yalnızca kısıtlama değil; herkesin kendi işine odaklanmasını sağlayan bir sadeleştirmedir.

Rolleri tanımlarken gerçek görev dağılımını esas alırız; kâğıt üzerindeki unvan yerine, kişinin günlük olarak ne yaptığına bakarız. Fazla yetki kadar eksik yetki de iş akışını tıkar. Bu yüzden her rolün sınırını, o rolün gerçek ihtiyacına göre çizeriz.

Yayından önce her rolü ayrı ayrı deneriz: yetkisiz bir kullanıcının göremeyeceği alan gerçekten kapalı mı, yetkili biri işini tamamlayabiliyor mu. Yetki hatalarının çoğu en kötü zamanda fark edilir; bu yüzden onları baştan sınamayı önemseriz.

Farklı kanallardan gelen veriyi ortak kurala bağlamak

Veri farklı kanallardan geldiğinde, aynı bilgi her yerde farklı biçimde yazılmış olur; bir yerde kısaltma, başka yerde tam ad. Bu dağınıklığı ortak bir kurala bağlar, hangi biçimin esas alınacağını baştan tanımlarız. Böylece aynı müşteri iki farklı kayda bölünmez.

Gelen her veriyi olduğu gibi kabul etmek yerine, önce belirlediğimiz kurala uyup uymadığını denetleriz. Eksik ya da tutarsız kayıtları erken yakalamak, sonradan yapılacak temizlik işini büyük ölçüde azaltır. Kuralın kendisi de zamanla ihtiyaca göre güncellenir.

Farklı kaynakları birleştirmeden önce küçük örneklerle deneriz; büyük veri yığınını körlemesine aktarmak, hataları görünmez kılar. Verinin nereden geldiğini ve ne zaman değiştiğini kayıt altına almak, ileride bir sorun çıktığında izini sürmeyi kolaylaştırır.

Tekrar eden işleri güvenli biçimde otomatikleştirmek

Elle yapılan tekrarlı işler zamanla hem yorucu hem hataya açık hâle gelir. Bu işleri otomatikleştirmek zaman kazandırır; ancak her otomasyon, yanlış çalıştığında sessizce zarar verebileceği için dikkatle kurulmalıdır. İşte özel yazılım tam da bu noktada, tekrarı güvenli sınırlar içinde üstlenir.

Bir işi otomatiğe bağlamadan önce, hangi durumda durması ve kime haber vermesi gerektiğini tanımlarız. Kontrolsüz bir otomasyon, hatalı bir kaydı da hızla çoğaltır. Bu yüzden her otomatik adımın yanına, gerektiğinde insana devreden bir denetim noktası koyarız.

Otomasyonu yayına almadan önce, beklenen ve beklenmeyen durumları örnek verilerle deneriz. Doğru çalıştığında kimse fark etmez; asıl önemli olan, bir şey ters gittiğinde nasıl davrandığıdır. Geri alınabilir adımlar, güveni artırır.

Yoğun kullanım ve hata anları için geri dönüş kurmak

Bir sistem, en çok ihtiyaç duyulduğu anda çökerse, o ana kadar sağladığı fayda gölgede kalır. Yoğun kullanımı ve olası hataları baştan hesaba katar, bir şey aksadığında sistemin tümüyle durmak yerine güvenli bir yedek davranışa geçmesini sağlarız. Kesinti, planlı biçimde yönetilir.

Hangi işlemin kritik, hangisinin ertelenebilir olduğunu ayırırız; böylece bir bölüm yavaşlasa bile temel işleyiş sürer. Hataların sessizce yutulması yerine kaydedilmesi, sorunun tekrar etmeden çözülmesini sağlar. Kullanıcıya da anlaşılır bir bilgi verilir.

Yayından önce sistemi bilinçli olarak zorlar, yoğun anı ve hatalı girişleri taklit ederiz. Bir servisin yanıt vermediği durumda ne olacağını görmeden yayına almak, riski geleceğe ertelemek olur. Geri dönüş yollarını önceden denemek, sürprizleri azaltır.

Dış servis bağlantılarını açık sınırlarla tanımlamak

Çoğu sistem, ödeme, mesaj ya da kargo gibi dış servislere bağlanır; bu bağlar kolaylık sağlar ama aynı zamanda bağımlılık yaratır. Her dış bağlantıyı açık sınırlarla tanımlar, o servis yanıt vermediğinde sistemin ne yapacağını baştan belirleriz. Sınırı belirsiz bir bağ, sorunu da belirsiz kılar.

Dış bir servisle konuşurken hangi bilginin gidip hangisinin geleceğini, hata durumunda nasıl davranılacağını yazılı hâle getiririz. Servisin kuralları zamanla değişebileceği için, bağlantıyı bu değişime dayanacak biçimde esnek kurarız. Tek bir dış aksaklık, tüm sistemi durdurmamalıdır.

Bağlantıları yayına almadan önce, servisin yavaş yanıt verdiği ya da hiç yanıt vermediği durumları deneriz. Gerçek ortamda ancak kötü günde ortaya çıkan sorunları, sakin bir zamanda görmek çok daha ucuzdur. Sınırlar netse, sorun da sınırlı kalır.

Masaüstü ve saha kullanımını prototiple sınamak

Aynı sistem, masabaşında ve sahada çok farklı koşullarda kullanılır; biri geniş ekranda rahatça, diğeri küçük ekranda ve aceleyle çalışır. Bu farkı tahmin etmek yerine, erken bir prototiple gerçek kullanıcıya deneterek görürüz. Sahada bir adım fazlası, gün içinde yüzlerce kez tekrar eder.

Prototip, henüz ucuzken yanlış varsayımları ortaya çıkarır; kâğıt üzerinde doğru görünen bir akış, gerçek elde beklenenden farklı işleyebilir. Kullanıcının nerede duraksadığını izler, çözümü ona göre sadeleştiririz. Erken görülen bir hata, en ucuz hatadır.

Farklı kullanım ortamlarını ayrı ayrı sınar, saha koşullarındaki bağlantı kesintisi gibi durumları da hesaba katarız. Masabaşında sorunsuz çalışan bir ekranın, sahada işe yaramaması sık görülür. Bu yüzden denemeyi gerçek koşullara olabildiğince yaklaştırırız.

Güvenlik ve kayıt izlerini mimariye baştan katmak

Güvenlik, tamamlandıktan sonra üzerine eklenen bir kabuk değildir; mimarinin en baştaki kararlarına işlenmelidir. Kimin neye eriştiğini, hangi kaydın ne zaman değiştiğini izleyen kayıt izlerini de tasarımın parçası olarak kurarız. Bu yüzden özel yazılım, güvenliği sonradan yamanacak bir eksik olarak bırakmaz.

Yetkilendirme, verinin korunması ve işlemlerin kaydı; birbirinden ayrı düşünülemez. Bir sorun yaşandığında ne olduğunu geriye dönük anlayabilmek, kayıt izleri olmadan neredeyse imkânsızdır. Bu izleri baştan kurmak, sonradan eklemekten hem kolay hem güvenilirdir.

Yayından önce yetki sınırlarını zorlar, izinsiz bir erişimin gerçekten engellendiğini deneriz. Hassas bilgilerin nasıl saklandığını ve yedeklendiğini gözden geçiririz. Güvenlik, tek seferlik bir kontrol değil; sürekli gözden geçirilen bir sorumluluktur.

Raporları yöneticinin gerçek sorularına göre kurmak

Bir yönetici rapora, veriyi merak ettiği için değil, bir karar vermek zorunda olduğu için bakar. Birden çok birimi İstanbul’da yöneten bir işletmede raporu, yöneticinin gerçekten sorduğu sorular üzerine kurarız: ne gidiyor, nerede tıkanıyor, neye öncelik vermeli. Süsleyen değil, yön gösteren bir rapor hedefleriz.

Her sayıyı göstermek yerine, kararı etkileyen birkaç ölçütü öne çıkarırız; kalabalık bir tablo çoğu zaman asıl bilgiyi gizler. Rapor, aynı soruyu her ay elle hesaplama yükünden de kurtarır. Doğru kurgulanmış bir özet, toplantıyı kısaltır.

Raporun kime hitap ettiğini baştan tanımlarız; sahadaki bir sorumluyla üst yönetimin ihtiyacı aynı değildir. Aynı veriyi farklı düzeylerde, gereksiz ayrıntıya boğmadan sunarız. Anlaşılmayan bir rapor, üretilmemiş bir rapordan farksızdır.

Sürüm ve bakım takvimini teslimle birlikte planlamak

Bir sistem teslim edildiğinde donup kalmaz; kullanıldıkça yeni ihtiyaçlar doğar. Sürüm ve bakım takvimini daha teslim anında planlar, hangi işin düzeltme, hangisinin yeni geliştirme sayılacağını baştan ayırırız. Belirsiz bırakılan bakım, en yoğun günde acil bir soruna dönüşür.

Küçük düzeltmeleri, planlı iyileştirmeleri ve acil müdahaleleri ayrı iş türleri olarak ele alırız; hepsini aynı torbaya koymak önceliklendirmeyi imkânsız kılar. Her sürümün geri alınabilir olması, bir güncellemenin yeni bir sorun getirme riskini azaltır.

Değişiklikleri doğrudan canlı sisteme değil, önce bir deneme ortamına uygularız. Bir güncellemenin mevcut işleyişi bozmadığını görmeden yaymak, kazanılmış istikrarı riske atar. Sürüm geçişini sakin bir zamanda planlar, sonrasını da izleriz.

Ekip eğitimini günlük görevler üzerinden yürütmek

En iyi kurulmuş sistem bile, ekip onu güvenle kullanamıyorsa beklenen faydayı vermez. Eğitimi soyut anlatımlarla değil, ekibin gerçekten her gün yapacağı görevler üzerinden yürütürüz. Kişi kendi işini sistemde bir kez tamamladığında, öğrenme kalıcı olur.

Sık karşılaşılan durumları birlikte adım adım deneriz; takıldıkları noktaları not eder, arayüzü ya da anlatımı buna göre sadeleştiririz. Bazen eğitimin gösterdiği zorluk, aslında sistemde giderilmesi gereken bir pürüzü işaret eder. Bu geri bildirimi ciddiye alırız.

Teslimde kısa ve anlaşılır bir kullanım kaynağı bırakır, ekip değiştiğinde yeni gelenin de hızlı uyum sağlamasını gözetiriz. Bilgi tek bir kişide sıkışıp kalırsa, o kişi ayrıldığında sistem sahipsiz kalır. Bu yüzden bilgiyi paylaşılır tutarız.

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

Bir sistemin teslimi, ilişkinin sonu değil, yeni bir aşamanın başlangıcıdır. Hesapların, erişimlerin ve kaynak dosyaların kime ait olduğunu; bakımın, güvenlik güncellemelerinin ve olası arızaların nasıl yürütüleceğini açıkça yazarız. Bu çerçevede özel yazılım, teslimden sonra havada kalan bir sorumluluk bırakmaz.

Kimin neyden sorumlu olduğu belirsiz kaldığında, en basit sorun bile uzun bir tartışmaya dönüşür. Bu yüzden sorumluluk sınırlarını, iyi gittiği zamanı değil, bir şeyin ters gittiği anı düşünerek tanımlarız. Yazılı bir çerçeve, güveni korur.

Devir sırasında işletmenin kendi sistemine tam olarak sahip olduğundan emin oluruz; erişimler, belgeler ve teknik teslimler eksiksiz aktarılır. İleride başka bir ekiple çalışmak gerekse bile, bağımlılık değil, sağlam bir zemin bırakmayı hedefleriz.

Yazılım hakkında sık sorulan sorular

Kullanıcı rolleri, ekranlar, veri yapısı, dış bağlantılar ve deneme senaryoları belirlendikten sonra aşamalı bir takvim çıkarılır. Süre tek bir tahmine sıkıştırılmaz; her aşama tamamlandıkça plan gerçeğe göre güncellenir. Kapsam netleştikçe zamanlama da netleşir.

İş akışı hazır araçlarla güvenli ve verimli biçimde karşılanabiliyorsa, yeni bir şey geliştirmek gereksizdir ve bunu açıkça söyleriz. Ancak süreç hazır kalıplara sığmıyor, her zorlama yeni bir aksaklık üretiyorsa, özel yazılım değerlendirmeye değer. Karar, hevesle değil ihtiyaçla verilir.

Kullanılan sistemin teknik erişimi ve veri kuralları uygunsa, bütünleşme kapsamı belgelenerek planlanabilir. Erişimin sınırlı olduğu durumlarda neyin mümkün, neyin mümkün olmadığını baştan paylaşırız. Belirsiz bir söz yerine, denenmiş ve doğrulanmış bir yol öneririz.

Hesaplar, erişimler, kullanım belgesi ve gerekli teknik teslimler; sözleşmedeki kapsam doğrultusunda işletmeye aktarılır. Amacımız, sizi bize bağımlı kılmak değil, kendi sisteminizi güvenle yönetebilir hâle getirmektir. Devir, baştan planlanan bir aşamadır.

Hata giderme, düzenli bakım ve yeni geliştirme; ayrı iş türleri olarak kaydedilir ve önceliklendirilir. Böylece acil bir düzeltme, planlı bir iyileştirmeyle karışıp gecikmez. Her talep, etkisi ve aciliyeti birlikte değerlendirilerek sıraya alınır.

Yetkilendirme, kayıt tutma, yedekleme ve hata senaryoları; sonradan eklenen önlemler değil, mimari kararların bir parçası olarak değerlendirilir. Hangi verinin ne kadar hassas olduğunu ayırır, korumayı buna göre ölçeklendiririz. Güvenlik, bir kez kurulup unutulan değil, sürekli gözetilen bir alandır.