Yazılım

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

Bir işletmenin gerçek iş akışı çoğu zaman hiçbir yerde yazılı değildir. Kimin neyi onayladığı, hangi bilginin hangi aşamada eklendiği ve istisnaların nasıl yönetildiği genellikle deneyimli birkaç kişinin hafızasında durur. Özel yazılım çalışması, bu bilgiyi önce görünür kılmakla başlar.
Akışı çıkarırken toplantı odasındaki tarifle yetinmiyoruz. İşin yapıldığı yerde bir siparişin, bir sevkiyatın ya da bir talebin baştan sona nasıl ilerlediğini izlemek, anlatılan sürecin yanında gerçekten uygulanan süreci de ortaya çıkarır. Aradaki fark genellikle projenin en riskli bölgesidir.
Çizilen akış, geliştirme başlamadan önce işi yapan kişilere okutulur. Kendi günlük işini o şemada tanıyamayan biri varsa eksik olan şema değil bizim anlayışımızdır. Bu doğrulama birkaç gün sürer ama yanlış kurgulanmış bir modülün maliyetinin yanında küçük kalır.

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

Yetki tanımı geciktirildiğinde sistem herkese her şeyi açan bir yapıya kayar. Başlangıçta pratik görünen bu kolaylık, ekip büyüdükçe hem hata hem de sorumluluk belirsizliği üretir. Kimin neyi değiştirebildiği sonradan sınırlandırılmaya çalışıldığında alışkanlıklar direnç gösterir.
Rolleri unvanlara göre değil yapılan işe göre kuruyoruz. Aynı unvandaki iki kişi farklı işler yapabilir, farklı unvandaki iki kişi aynı ekranı kullanabilir. Yetkiyi kişiye değil göreve bağlamak, kadro değişikliklerinde sistemi baştan kurmak zorunda kalmaktan kurtarır.
Tanımlar yazıldıktan sonra sınır durumları denenir. Bir kullanıcının yetkisi dışındaki kaydı adres satırından açmaya çalıştığında ne olduğu, izin verilmeyen işlemin nasıl bildirildiği ve devredilen yetkinin nasıl geri alındığı tek tek sınanır. Bu denemeler kısa tutulmaz.

Veri kaynaklarını tek kurala bağlamak

Aynı bilginin farklı yerlerde farklı biçimde tutulması, geliştirme projelerinin en yaygın açığıdır. Müşteri adı bir yerde kısaltmayla, başka yerde tam yazımla durur; ikisi eşleşmeyince rapor da eşleşmez. Sorun genellikle rapor aşamasında fark edilir ama kaynağı çok daha eskidir.
Bu yüzden her veri parçası için tek bir sahip belirliyoruz. Hangi sistemin o bilginin doğrusunu tuttuğu, diğerlerinin oradan mı beslendiği ve çakışma olduğunda hangisinin geçerli sayılacağı yazılı kurala bağlanır. Kural yoksa her yeni bağlantı bir kopya daha üretir.
Kural konduktan sonra mevcut veri temizlenmeden taşınmaz. Yinelenen kayıtlar, boş bırakılmış zorunlu alanlar ve biçimsiz tarihler yeni sisteme olduğu gibi aktarıldığında sorun büyüyerek devam eder. Taşıma öncesindeki temizlik, sonraki aylarda gelecek destek taleplerini doğrudan azaltır. Hangi kaydın neden birleştirildiği de ayrıca not edilir.

Tekrarlanan işlemleri otomasyona taşımak

Otomasyona taşınacak işi seçerken sıklık ile riski birlikte değerlendiriyoruz. Gün içinde defalarca yapılan basit bir kopyalama, ayda bir yapılan karmaşık bir hesaptan daha fazla zaman kazandırabilir. Buna karşılık hata yapıldığında geri alınması zor olan iş her zaman önce ele alınır.
Her tekrar eden iş otomasyona uygun değildir. İnsan kararı gerektiren, istisnası bol olan ve girdisi düzensiz gelen adımlar otomatikleştirildiğinde kazanç yerine sürekli düzeltme doğurur. Bu adımları olduğu gibi bırakıp çevresini kolaylaştırmak daha iyi sonuç verir. Karar veren kişiye doğru bilgiyi zamanında ulaştırmak da başlı başına bir kazançtır.
Devreye alırken eski yöntemi bir süre açık tutuyoruz. İki yöntemin çıktısı karşılaştırılmadan eskisi kapatılmaz. Geçiş dönemi kısa olabilir; ama güveni kuran şey, yeni düzenin aynı sonucu ürettiğinin gözle görülmesidir.

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

Her sistemde bir gün beklenmeyen bir şey olur. Asıl soru bunun olup olmayacağı değil, olduğunda ne kadar sürede ve ne kaybederek geri dönüleceğidir. Bu soru geliştirme sırasında sorulmazsa cevabı kriz anında aranmak zorunda kalır.
Geri dönüş planı yalnızca yedek almak demek değildir. Yedeğin gerçekten geri yüklenebildiği denenmemişse elde yedek yok sayılır. Bu yüzden yükleme denemesini bakım takvimine yazıyor, geçen süreyi ölçüyor ve sonucu kayda geçiriyoruz.
Kullanıcıya gösterilen hata mesajları da planın parçasıdır. Ne olduğunu söylemeyen genel bir uyarı, kullanıcıyı aynı işlemi tekrar tekrar denemeye iter ve durumu ağırlaştırır. Mesajın ne yapılması gerektiğini söylemesi, destek yükünü belirgin biçimde azaltır. İyi yazılmış bir uyarı metni, özel yazılım projelerinde çoğu zaman fazladan bir ekrandan daha çok işe yarar.

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

Entegrasyon konuşmaları çoğu zaman iyimser başlar. Karşı sistemin ne verdiği, hangi sıklıkla güncellendiği ve hata durumunda nasıl davrandığı netleşmeden verilen süre tahminleri neredeyse her zaman aşılır. Dış ticaret bağlantısı yoğun olan İzmir’de karşı tarafın sistemi çoğu kez başka bir ülkede yönetilir ve iletişim tempoyu belirler. Özel yazılım kapsamında en çok sürprizin çıktığı yer burasıdır.
Bu yüzden entegrasyonu koda dökmeden önce belgeye döküyoruz. Hangi alanın hangi alana karşılık geldiği, eksik gelen verinin nasıl işleneceği ve karşı taraf yanıt vermediğinde ne olacağı yazılır. Yazılamayan bir kural, geliştirme sırasında tahmine dönüşür.
Sınırları belirlemek sorumluluğu da belirler. Karşı sistemin kendi hatasından doğan bir aksaklıkla bizim tarafımızdaki bir eksiklik aynı şey değildir. Bu ayrım baştan yazıldığında, sorun çıktığında zaman tartışmaya değil çözüme gider.

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

Sahada kullanılacak bir ekranı masa başında kurgulamak yanıltıcıdır. Depoda eldivenle, açık havada güneş altında ya da araç içinde tek elle kullanılan bir arayüzün gereksinimleri, ofis bilgisayarındakinden bütünüyle farklıdır.
Bu nedenle mobil senaryoları geliştirmenin sonuna bırakmıyoruz. Veri girişinin hangi sırayla yapılacağı, bağlantı koptuğunda kaydın ne olacağı ve barkod ya da fotoğraf gibi girdilerin nasıl alınacağı erken kararlaştırılır. Sonradan eklenen mobil katman genellikle yamalı kalır.
Sınama da gerçek koşullarda yapılır. İşi yapan kişinin kendi cihazıyla, kendi ortamında ve kendi hızında denemesi, laboratuvar koşulunda hiç görülmeyecek aksaklıkları ilk günde ortaya çıkarır. Bu denemelerin notları doğrudan geliştirme sırasına girer.

Güvenlik kararlarını mimarinin içine yerleştirmek

Güvenlik, teslimden hemen önce eklenen bir kontrol adımı olarak ele alındığında geç kalınmış olur. Kimin hangi veriyi görebildiği, kayıtların nasıl tutulduğu ve dışarıya açılan her noktanın nasıl korunduğu mimari kararların içinde yer alır.
Kayıt tutma bu kararların en sessiz ama en işe yarar olanıdır. Bir kaydın kim tarafından, ne zaman ve hangi değerle değiştirildiği görülebiliyorsa anlaşmazlık tartışmayla değil kayda bakılarak çözülür. Bu iz, sonradan eklenmesi en zor özelliklerden biridir. Geçmişe dönük kayıt üretmek mümkün olmadığı için karar baştan verilmelidir.
Kişisel veri söz konusu olduğunda kapsamı daraltmayı tercih ediyoruz. Toplanmayan veri korunmak zorunda değildir. Gerçekten gerekmeyen alanları baştan çıkarmak hem yasal yükü hem de olası bir sorunun etkisini azaltır.

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

Yönetim raporu, veritabanındaki her alanın ekrana taşınmasıyla oluşmaz. Önce hangi sorulara cevap arandığını konuşuyoruz. Hangi işin geciktiği, hangi müşterinin kârlı olduğu ve hangi aşamanın darboğaz yarattığı belirlenmeden ekran kurgulanmaz.
Sorular netleştiğinde her göstergenin nasıl hesaplandığı yazılır. Aynı adı taşıyan iki rakamın farklı formüllerle üretilmesi, raporu güvenilmez kılan en yaygın sebeptir. Tanım metni raporun yanında durur ve hesap değiştiğinde birlikte güncellenir.
Raporun ne zaman açıldığı da kurgusunu etkiler. Her sabah bakılan bir özet ile ay sonunda incelenen bir döküm aynı biçimde hazırlanmaz. Özel yazılım tarafında bu ayrım yapıldığında ekran sayısı azalır, kullanım artar.

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

Teslim edilen bir sistem sabit kalmaz. Mevzuat değişir, ekip büyür, yeni bir satış kanalı eklenir. Üretim ve ihracat tarafında çalışan İzmir merkezli işletmelerde bu değişim hızı daha da belirgindir. Bunların nasıl karşılanacağı teslim anında belirlenmemişse her küçük talep ayrı bir pazarlık konusuna dönüşür.
Sürüm düzenini baştan kuruyoruz. Hangi değişikliğin hangi sıklıkta yayımlanacağı, denemenin nerede yapılacağı ve geri alma kararını kimin vereceği yazılı olur. Bu düzen olmadan yapılan her güncelleme, çalışan sisteme doğrudan dokunmak anlamına gelir.
Bakım ile yeni geliştirmeyi ayrı tutmak iki tarafın da işine yarar. Hata giderimi öngörülebilir bir hizmettir, yeni özellik ise ayrıca planlanan bir iştir. Bu ayrım yapılmadığında bakım bütçesi yeni taleplerle erir ve asıl bakım hiç yapılmaz.

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

Eğitim, ekran ekran gezdirilerek yapıldığında akılda kalmaz. Kullanıcı kendi işini o sistemde bir kez baştan sona yaptığında öğrenir. Bu yüzden eğitimi gerçek görevler üzerinden kuruyoruz ve katılımcı kendi verisiyle çalışıyor.
Farklı rollerin eğitimi de farklı olmalıdır. Günlük veri girişi yapan biriyle yalnızca onay veren biri aynı anlatımdan aynı şeyi çıkarmaz. Herkese tek bir sunum yapmak, katılımcıların çoğu için gereksiz, bir kısmı için yetersiz kalır.
Eğitimden sonraki ilk haftalarda gelen sorular kayda alınır. Aynı sorunun tekrarlanması genellikle kullanıcının değil arayüzün eksikliğine işaret eder. Bu geri bildirim, ilk bakım turunun gündemini oluşturur. Küçük bir etiket değişikliği bile tekrarlanan sorulardan birkaçını tümüyle ortadan kaldırabilir.

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

Teslim, dosyaların devredilmesiyle bitmez. Hangi hesapların kimin adına açıldığı, sunucu ve alan adı erişimlerinin nerede durduğu, kaynak kodun nerede tutulduğu ve hangi üçüncü taraf hizmetlerin abonelik gerektirdiği tek tek yazılır.
Sorumluluk sınırının yazılması iki tarafı da rahatlatır. Hangi durumun destek kapsamında olduğu, hangisinin ayrı bir iş olarak tanımlandığı ve müdahale için beklenen sürenin ne olduğu önceden bilinir. Bu netlik, sorun anındaki gerginliğin büyük bölümünü ortadan kaldırır.
Devir belgesiyle birlikte sistemin nasıl yeniden ayağa kaldırılacağı da aktarılır. Kurulum adımları, bağımlılıklar ve yapılandırma bilgileri yazılı olduğunda işletme tek bir kişiye ya da tek bir tedarikçiye bağımlı kalmaz. Özel yazılım yatırımını kalıcı kılan şey büyük ölçüde budur.

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

Süre; kullanıcı rolleri, ekran sayısı, veri yapısının karmaşıklığı, entegrasyon ihtiyacı ve test senaryoları belirlendikten sonra çıkarılır. Çalışma tek bir blok hâlinde değil aşamalara bölünerek planlanır. Her aşamanın sonunda çalışan bir parça teslim edildiği için takvim ilerledikçe daha da netleşir.
Hazır araçlar işin büyük bölümünü karşılıyorsa geliştirme önermiyoruz. Karar, iş akışının hazır çözümlere ne kadar uydurulabileceğine bakılarak verilir. Uyum için fazla taviz gerekiyorsa ya da veri güvenliği tarafında kısıt varsa geliştirme seçeneği değerlendirilir. Bu kararı, İzmir’de görüştüğümüz işletmelerin çoğunda tek bir değerlendirme toplantısı netleştiriyor.
Kullanılan sistemin teknik erişim sağlaması ve veri kurallarının belgelenebilmesi gerekir. Bu iki koşul sağlandığında kapsam yazılı olarak planlanır. Erişimin kapalı olduğu durumlarda ara çözümler konuşulur ve sınırları baştan paylaşılır.
Hesaplar, erişim bilgileri, kaynak kod, kullanım dokümanı ve kurulum adımları sözleşmedeki kapsam doğrultusunda işletmeye aktarılır. Devir tek bir dosya gönderimi değil, birlikte yürütülen bir kontrol oturumudur.
Hata giderimi, düzenli bakım ve yeni geliştirme ayrı iş türleri olarak kaydedilir. Böylece bakım bütçesi yeni taleplerle tükenmez. Öncelik sırası dönemsel olarak birlikte gözden geçirilir ve kararlar yazılı tutulur.
Yetkilendirme, işlem kaydı, yedekleme ve hata senaryoları mimari kararların içinde değerlendirilir. Toplanan veri gerçekten gereken alanlarla sınırlandırılır. Yedeklerin geri yüklenebilirliği düzenli aralıklarla denenir ve sonucu kayda geçirilir.