Yazılım

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

Bir işletmenin günlük akışı çoğu zaman kimsenin tam olarak yazıya dökmediği alışkanlıklardan oluşur. Şube ve kampanya bilgisini yöneten bir kurumda bu akış görünür kılınmadan koda geçilirse, ortaya çıkan sistem gerçek işi değil, varsayılan işi destekler. Bu yüzden başkentte, Ankara’da çalıştığımız kurumlarda da özel yazılım sürecini yazmaktan değil, akışı birlikte çizmekten başlatırız.
İlk adımda varsayım üretmek yerine mevcut işleyişi izleriz. Hangi belgenin nereden geldiğini, hangi kararın kimin elinde şekillendiğini ve işin nerede beklemeye takıldığını, işi fiilen yapan kişilerle birlikte kâğıda döker; sonra bunu herkesin okuyabileceği ortak bir şemaya çeviririz.
Çizdiğimiz akışı geliştirmeye geçmeden önce ekibe geri okuruz. Eksik kalan adımları, atlanan istisnaları ve gerçekte farklı yürüyen kısımları düzeltir; tek bir satır kod yazılmadan önce herkesin aynı işleyişi onayladığından emin oluruz.

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

Kurumsal müşterilerle çalışan bir danışmanlık ekibinde herkesin her şeyi görebildiği bir sistem, zamanla hem karışıklık hem de risk üretir. Kimin neyi görebileceği ve değiştirebileceği baştan ayrılmadığında sorumluluk da bulanıklaşır; bir hata olduğunda kaynağını bulmak güçleşir.
Bu yüzden rolleri, kişilerin unvanına göre değil, gerçekte yaptıkları işe göre tanımlarız. Her rolün hangi ekranı görmesi, hangi kaydı açması ya da yalnızca okuması gerektiğini; ekibin günlük görev dağılımını dinleyerek belirleriz.
Kurduğumuz yetki düzenini farklı roller adına deneyerek sınarız. Bir rolün görmemesi gereken bir yere ulaşıp ulaşamadığını, bir yetkinin gereğinden geniş kalıp kalmadığını kontrol eder; her kullanıcının yalnızca işine yetecek kadar erişimle çalışmasını sağlarız. Dar tutulmuş bir yetki, kullanıcıyı kısıtlamak için değil, onu gereksiz bir sorumluluğun yükünden korumak içindir.

Farklı kaynaklardaki veriyi ortak bir kurala bağlamak

Teknik ürünlerini farklı pazarlara sunan bir üreticide veri, çoğu zaman birbirinden habersiz tablolarda ayrı biçimlerde tutulur. Aynı ürün bir yerde başka, başka bir yerde daha başka yazıldığında, sayılar birbirini tutmaz ve zamanla verilere duyulan güven sarsılır.
Bu dağınıklığı gidermek için önce her kaynağın kendi mantığını anlarız. Aynı bilginin farklı yerlerde nasıl adlandırıldığını eşler, ortak bir kural tanımlar; hangi kaydın hangi durumda esas alınacağını belirsizliğe yer bırakmadan kararlaştırırız.
Kuralı uygulamaya almadan önce gerçek veriyle deneriz. Çelişen kayıtları, boş kalan alanları ve eşleşmeyen satırları önceden yakalar; verinin tek ve tutarlı bir doğruya oturduğundan emin olduktan sonra sistemi bu temele bağlarız.

Tekrarlanan işleri güvenli biçimde otomatikleştirmek

Karar vericilere ulaşan bir hizmet markasında ekibin zamanının önemli bölümü, her gün aynı biçimde yinelenen elle işlere gider. Bu işler yalnızca yavaş değildir; her tekrar, insan kaynaklı küçük bir hata olasılığını da sessizce beraberinde taşır.
Otomatikleştirmeden önce hangi işin gerçekten kurala bağlanabildiğini ayırt ederiz. Her seferinde aynı adımlarla yürüyen görevleri belirler, insan kararı gerektiren yerleri bunun dışında tutar; otomasyonu yalnızca öngörülebilir kısma uygularız.
Kurduğumuz otomasyonu, geri alınabilir biçimde ve gözlem altında devreye alırız. Beklenmedik bir durumda sürecin nerede durup kime haber vereceğini önceden tanımlar; hız uğruna denetimi kaybetmeden, tekrarlı işi güvenle sisteme bırakırız.

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

Büyümekte olan bir teknoloji girişiminde sistem, sakin bir günde sorunsuz görünse de asıl sınavını yoğun anlarda verir. Bir özel yazılım çözümünün olgunluğu, her şey yolundayken değil, bir şeyler ters gittiğinde nasıl davrandığıyla ortaya çıkar.
Bu yüzden tasarımın başından itibaren hata durumlarını hesaba katarız. Yükün arttığı anları, yarıda kalan işlemleri ve dışarıdan gelen bir aksaklığı öngörür; sistemin bu koşullarda ne yapacağını rastlantıya bırakmadan önceden kurgularız.
Kurduğumuz geri dönüş yollarını, sorunları bilerek yaratarak deneriz. Bir işlem yarıda kesildiğinde verinin bozulup bozulmadığını, sistemin kendini toparlayıp toparlayamadığını sınar; olağan dışı anlarda bile işin güvenli bir noktada durmasını sağlarız.

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

Kayıtlarını tek merkezde toplayan bir kuruluşta sistem, çoğu zaman kendi dışındaki servislerle konuşmak zorundadır. Bu bağlantılar belirsiz sınırlarla kurulduğunda, dışarıdaki küçük bir değişiklik içeride beklenmedik bir aksaklığa yol açabilir.
Bu yüzden her dış bağlantıyı, ne alıp ne verdiği açıkça yazılı bir anlaşmaya bağlarız. Hangi bilginin hangi biçimde geçtiğini tanımlar, bağlantının yanıt vermediği durumda sistemin nasıl davranacağını baştan belirleriz.
Bağlantıları, gerçek koşulları taklit eden denemelerle sınarız. Dış servisin yavaşladığı, hata döndürdüğü ya da hiç yanıt vermediği durumları kurgular; bu anlarda bile sistemin kendi işini kararlılıkla sürdürmesini güvence altına alırız.

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

Şube ve kampanya bilgisini yöneten bir işletmede aynı sistemi hem masa başındaki bir çalışan hem de sahada, ayaküstü çalışan biri kullanır. Bir özel yazılım çözümünü tek bir kullanım biçimine göre tasarlamak, bu iki gerçeği birden ıskalamak anlamına gelir.
Bu yüzden ekranları, tam olarak yazmadan önce basit bir prototiple ortaya koyarız. Masadaki ayrıntılı girişle sahadaki hızlı dokunuşu ayrı ayrı canlandırır; her iki kullanımı da gerçek kişilere elleriyle denetiriz.
Denemede ortaya çıkan takılmaları, yanlış anlaşılan düğmeleri ve fazladan adımları not ederiz. Tasarımı bu geri bildirimle sadeleştirir; kod yazımına, iki kullanım biçiminin de gerçekten işlediğinden emin olduktan sonra geçeriz.

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

Kurumsal müşterilerle çalışan bir danışmanlık ekibinde güvenlik, iş bittikten sonra eklenen bir katman olarak düşünüldüğünde çoğu zaman geç kalınmış olur. Kimin ne zaman neye eriştiği kayıt altına alınmıyorsa, bir sorun çıktığında geriye dönüp bakılacak bir iz de kalmaz.
Bu yüzden yetkilendirmeyi ve kayıt tutmayı, sonradan değil tasarımın ilk kararlarıyla birlikte ele alırız. Hangi işlemin iz bırakması gerektiğini, bu kayıtların nasıl saklanacağını ve kimin inceleyebileceğini baştan tanımlarız.
Kurduğumuz düzeni, olası bir denetimi canlandırarak sınarız. Bir işlemin kim tarafından ve ne zaman yapıldığını kayıtlardan izleyebiliyor muyuz diye kontrol eder; güvenliği sonradan yamanmış değil, yapının içine örülmüş bir nitelik olarak bırakırız. Sonradan eklenen bir önlem çoğu zaman gecikirken, baştan kurulan bir iz sessizce her gün çalışır.

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

Teknik ürünlerini farklı pazarlara sunan bir üreticide yönetici, sistemden çoğu zaman uzun bir tablo değil, birkaç sorunun net yanıtını bekler. Veriyi olduğu gibi önüne yığan bir rapor, karar vermeyi kolaylaştırmak yerine daha da zorlaştırır.
Bu yüzden raporlamayı, önce yöneticinin gerçekte hangi soruları sorduğunu anlayarak kurarız. Hangi bilginin karar anında işe yaradığını belirler; ekranı bu soruların yanıtını en sade biçimde verecek şekilde düzenleriz.
Hazırladığımız raporları, kararı verecek kişiyle birlikte deneriz. Yanlış okunan bir grafiği, eksik kalan bir kırılımı ya da gereksiz bir ayrıntıyı onun geri bildirimiyle düzeltir; raporu bir veri dökümü değil, gerçek bir karar aracı hâline getiririz.

Bakım ve sürüm takvimini teslimle birlikte planlamak

Karar vericilere ulaşan bir hizmet markasında sistem, teslimle birlikte donup kalmaz; kullanıldıkça yeni ihtiyaçlar doğar ve zamanla küçük onarımlar gerekir. Bu süreklilik planlanmadığında, her küçük değişiklik ayrı bir telaşa dönüşür.
Bu yüzden bakımı ve yeni sürümleri, teslim anından itibaren bir takvime bağlarız. Düzenli kontrollerin ne zaman yapılacağını, güncellemelerin nasıl sıraya gireceğini ve acil bir durumun normal işten nasıl ayrılacağını baştan tanımlarız.
Planı işletmeyle birlikte gözden geçirir, hangi işin hangi başlık altında yürüyeceğini netleştiririz. Böylece sistem, teslimden sonra kendi hâline bırakılmak yerine, öngörülebilir bir ritimle bakımı yapılan canlı bir araç olarak kalır.

Ekip eğitimini günlük görevler üzerinden tamamlamak

Büyümekte olan bir teknoloji girişiminde en iyi kurulmuş sistem bile, ekip onu günlük işine yediremezse beklenen faydayı vermez. Bir özel yazılım çözümü ancak kullananların elinde gerçek karşılığını bulur; bu yüzden eğitimi teslimin küçük bir eki saymayız.
Eğitimi soyut bir tanıtım yerine, ekibin her gün yapacağı gerçek görevler üzerinden kurarız. Sık yapılan işleri birlikte adım adım yürütür; herkesin kendi rolündeki akışı, yalnızca izleyerek değil deneyerek öğrenmesini sağlarız.
Eğitim sırasında en çok takılınan noktaları not eder, bunları hem anlatımla hem de gerektiğinde sistemi sadeleştirerek gideririz. Ekibin başvurabileceği sade bir kullanım kılavuzu bırakır; öğrenmenin teslimle bitmeyip günlük kullanımda sürmesini gözetiriz.

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

Kayıtlarını tek merkezde toplayan bir kuruluşta iş, sistem teslim edildiğinde değil, sorumlulukların netleştiği anda güvenceye alınır. Kimin neyi üstlendiği yazılı değilse, bir aksaklık çıktığında zaman, çözümü aramak yerine sorumluyu aramakla geçer.
Bu yüzden teslimden önce kimin neyden sorumlu olduğunu tek tek yazıya dökeriz. Hangi işin işletmede, hangisinin bizde kalacağını; erişimlerin, hesapların ve teknik belgelerin nasıl devredileceğini açık bir dille tanımlarız.
Bu belgeyi teslim sırasında birlikte gözden geçirir, belirsiz kalan hiçbir başlık bırakmayız. Böylece sistem devredildikten sonra da herkes kendi sorumluluğunu bilir; olası bir sorun, tartışmaya değil doğrudan çözüme yönlendirilir. Böylece devir teslim, ilişkinin bittiği değil, güvene dayalı biçimde sürdüğü bir aşama olur.

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

Süre; kullanıcı rollerinin, ekranların, veri yapısının, dış bağlantıların ve test senaryolarının netleşmesiyle şekillenir. Bunlar belirlendikten sonra tek bir tarih değil, aşamalara bölünmüş bir takvim çıkarır; her aşamayı ayrı ayrı planlar ve birlikte izleriz.
İş akışı, hazır araçlarla güvenli ve verimli biçimde karşılanabiliyorsa ayrıca geliştirmeye gerek yoktur. Ancak süreç bu araçların sınırlarına takılıyor ve zorlama çözümlerle yürüyorsa, bu noktada özel yazılım uzun vadede daha sade ve güvenli bir yol sunar.
Kullandığınız sistemin teknik erişimi ve veri kuralları uygun olduğunda entegrasyon yapılabilir. Öncelikle ne alınıp ne verileceğini ve sınırların nerede olduğunu belgeler; bağlantıyı, iki taraf da beklenen biçimde çalıştığından emin olduktan sonra devreye alırız.
Evet. Hesaplar, erişim bilgileri, kullanım belgeleri ve gerekli teknik teslimler, sözleşmede tanımlanan kapsam doğrultusunda işletmeye aktarılır. Amacımız Ankara’da da başka her yerde de aynıdır: sistemin denetimini zamanla dışarıya bağımlı kılmak değil, işletmenin kendi elinde tutmasını sağlamak.
Hata giderimi, düzenli bakım ve yeni geliştirme ayrı iş türleri olarak kaydedilir. Her istek, aciliyetine ve etkisine göre sıraya alınır; böylece küçük bir düzeltme ile kapsamlı bir yeni özellik birbirine karışmaz ve her biri hak ettiği özenle ele alınır.
Yetkilendirme, kayıt tutma, yedekleme ve hata senaryoları; sonradan eklenen önlemler olarak değil, mimari kararların bir parçası olarak değerlendirilir. Verinin kimin elinde ve nasıl korunduğu baştan tanımlanır; bu tercihler yazılı olarak işletmeyle paylaşılır.