Yazılım

İş akışını koddan önce görünür hale getirmek

Üretim yapan bir tesiste aynı bilgi genelde birkaç yerde birden tutulur: bir hesap tablosunda, bir deftere yazılmış notta ve bir kişinin aklında. Yazma işine başlamadan önce bu akışın tamamını duvara çizmek gerekir. Özel yazılım kararlarının çoğu, ekranlar tasarlanmadan çok önce bu şemanın üzerinde alınır. Duvara çizilen bu şema, sonradan yapılacak tartışmaların çoğunu baştan bitiriyor.
Şemayı çıkarırken işi fiilen yapan kişiyle birlikte oturuyoruz. Bir talebin nereden girdiği, kimin onayından geçtiği, hangi noktada kâğıda döküldüğü ve hangi adımın neden atlandığı tek tek işaretleniyor. Atlanan adımlar çoğu zaman tembellikten değil, mevcut düzenin gerçek işe uymamasından kaynaklanıyor. Bu ayrımı görmeden yazılan her ekran aynı sorunu yeniden üretiyor. İşi yapan kişinin anlattığı akış ile yönetimin anlattığı akış çoğu zaman örtüşmüyor.
Şema onaylanmadan tek satır yazılmıyor. Akış kâğıt üzerinde baştan sona yürütülüyor, istisnai durumlar ayrıca not ediliyor ve hangi adımın ölçüleceği belirleniyor. Bu hazırlık, sonradan yapılacak büyük değişikliklerin maliyetini en çok düşüren aşama oluyor. Şemanın son hali de teslim dosyasında saklanıyor.

Kullanıcı rollerini ve yetki sınırlarını açıkça tanımlamak

Vardiyalı çalışan bir işletmede aynı ekranı gören üç kişi üç farklı sorumluluk taşır. Herkese her yetkiyi vermek kısa vadede kolaylık gibi görünse de yanlış kaydın kim tarafından girildiği sorulduğunda ortada cevap kalmaz. Rol tanımı bu yüzden bir güvenlik konusu olduğu kadar bir düzen konusudur. Kimin hangi kaydı değiştirebildiği, bir denetim istendiğinde ilk sorulan soru oluyor.
Rolleri unvanlara göre değil, yapılan işe göre kuruyoruz. Kim kaydı oluşturur, kim onaylar, kim yalnız görür ve kim geri alabilir soruları tek bir tabloda toplanıyor. Aynı kişi birden çok rolü taşıyabiliyor; önemli olan hangi işlemin hangi yetkiye bağlandığının yazılı olması. Yetki değişikliğini kimin yapacağı da aynı tabloda duruyor. Yeni bir rol gerektiğinde tabloya satır eklemek yeterli oluyor.
Tanımlar kurulduktan sonra her rol için ayrı bir hesap açılıp deneniyor. Görmemesi gereken ekrana ulaşan ya da onaylaması gereken adımı atlayabilen bir rol varsa düzeltme geliştirmeyle birlikte yapılıyor. Yetki denetimi teslimden önce bir kez daha tekrarlanıyor, çünkü araya giren her yeni ekran dengeyi değiştirebiliyor.

Veri kaynaklarını tek bir kurala bağlamak

Bir ürün kodunun üç ayrı yerde üç farklı biçimde yazılması, raporların birbirini tutmamasının en sık nedenidir. Tedarikçi listesi bir tarafta, sevkiyat kaydı başka tarafta tutulduğunda ay sonunda sayılar tartışma konusu olur. Çözüm genelde yeni bir ekran değil, hangi kaydın asıl sayılacağına dair net bir karardır. Bu karar alınmadan hazırlanan her rapor, bir sonraki ay yeniden tartışılıyor.
Kural belirlenirken her veri için tek bir sahip tanımlanıyor. Kodun nasıl yazılacağı, birimin ne olacağı, hangi alanların zorunlu olduğu ve boş bırakılan alanların nasıl işleneceği yazılı hale getiriliyor. Aktarım sırasında bu kurallara uymayan kayıtlar sessizce geçmiyor, ayrı bir listeye düşüyor ve sorumlusuna iletiliyor. Birimi belirsiz bırakılan bir sayı, raporda her okuyana başka bir şey anlatıyor.
Eski verinin taşınması ayrı bir iş olarak planlanıyor. Önce küçük bir örnek aktarılıyor, sonuç birlikte kontrol ediliyor ve ancak ondan sonra tamamına geçiliyor. Hatalı kayıtların düzeltilmesinin işletmede kimin sorumluluğunda olacağı da bu aşamada cevaplanıyor; aktarım sonrası temizlik çoğu projede hafife alınan bir yük oluyor.

Tekrarlanan işlemleri otomasyona taşımak

Her gün aynı saatte alınan bir çıktı, elle yazılan bir bildirim ya da her sevkiyatta tekrarlanan bir kopyalama işlemi zamanla görünmez bir maliyete dönüşür. Bu işler tek tek küçüktür; toplamı ise bir kişinin haftalık mesaisine yaklaşabilir. Özel yazılım tarafında otomasyon kararını çoğunlukla bu toplam belirliyor. Listeyi çıkarmak için bir hafta boyunca tutulan basit bir not defteri çoğu zaman yetiyor.
Neyin otomatikleştirileceğini seçerken sıklığı ve hata riskini birlikte tartıyoruz. Nadiren yapılan ama yanlış yapıldığında pahalıya mal olan işler de listeye giriyor. Her otomatik adımın ne zaman çalıştığı ve sonucunun nereye yazıldığı görünür kılınıyor; görünmeyen bir işlem güven vermiyor. Otomasyonun gerektiğinde kapatılmasını kimin yapabileceği de belirleniyor.
Otomatik çalışan işlemlere sessiz kalma hakkı tanınmıyor. İşlem tamamlandığında kayıt düşüyor, tamamlanamadığında sorumluya uyarı gidiyor. Arka planda sessizce çalışıp bir gün duran bir görev, en geç fark edilen arıza türü oluyor. Bu nedenle çalışma kayıtları ilk haftalarda düzenli olarak gözden geçiriliyor.

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

Denemelerin çoğu her şeyin yolunda gittiği senaryo üzerine kurulur. Oysa sahada bağlantı kopar, etiket okunmaz, kullanıcı yanlış tuşa basar ve iki kişi aynı kaydı aynı anda açar. Bu durumlarda ne olacağı önceden kararlaştırılmazsa cevabı kullanıcı kendi yöntemiyle üretir ve düzen ilk haftada bozulur. Kullanıcının kendi bulduğu çözüm, genelde kayıt dışı bir yöntem olarak yerleşiyor.
Her kritik adım için bir geri dönüş yolu tanımlıyoruz. Yarım kalan işlemin nereye kaydedileceği, yanlış girilen kaydın nasıl düzeltileceği ve düzeltmenin izinin nerede duracağı cevaplanıyor. Kaydı tamamen silmek yerine iptal durumuna almak, çoğu süreçte daha güvenli bir tercih oluyor. İptal edilen kayıtlar ayrı bir listede toplanıyor ve dönem sonunda gözden geçiriliyor.
Hata senaryoları da tıpkı normal akış gibi deneniyor. Bağlantı bilerek kesiliyor, eksik veri gönderiliyor ve eşzamanlı işlem yapılıyor. Sistemin bu koşullarda kullanıcıya ne söylediği ve verinin bozulup bozulmadığı teslimden önce görülüyor. Çıkan her aksaklık, düzeltildikten sonra aynı senaryoyla yeniden sınanıyor.

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

Mevcut bir muhasebe programı, tartım cihazı ya da sevkiyat sistemiyle konuşmak çoğu projenin en belirsiz kısmıdır. Belirsizlik teknik zorluktan değil, karşı tarafın neye izin verdiğinin bilinmemesinden doğar. Üretim tesislerinin yoğun olduğu Kocaeli çevresinde bu sistemlerin sayısı genellikle birden fazla olur; bu nedenle entegrasyon tahminle değil belgeyle konuşulur. Belgelenmemiş bir bağlantı, karşı taraftaki ilk güncellemede sessizce çalışmayı bırakabiliyor.
İlk adımda karşı sistemin teknik belgesi isteniyor; belge yoksa sağlayıcıyla doğrudan görüşülüyor. Hangi verinin okunabildiği, hangisinin yazılabildiği, günlük sınırların ne olduğu ve hata durumunda ne döndüğü yazıya geçiriliyor. Bu yazı aynı zamanda kapsamın da sınırını çiziyor ve teklifte karşılığını buluyor. Sağlayıcının ayrı bir ücretlendirme koşulu varsa bu da baştan hesaba katılıyor.
Bağlantı kurulduktan sonra veri iki tarafta karşılaştırılıyor. Aktarımın hangi sıklıkta çalışacağı, tekrar eden kayıtların nasıl ayıklanacağı ve bağlantı koptuğunda kuyruğun ne olacağı ayrıca deneniyor. Karşı sistem güncellendiğinde kimin haber vereceği de sözleşmede yer alıyor; bu madde sonradan yaşanan kesintileri önlüyor.

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

Depoda, sahada ya da araç içinde kullanılacak bir ekranın yalnız masa başında tasarlanması sık yapılan bir hatadır. Eldivenli parmak, güneş altında sönük görünen ekran ve tek elle kullanım masa başında hiç hissedilmez. Bu koşulların tasarımın erken aşamasında hesaba katılması gerekir. Ekran parlaklığı ve düğme boyutu bu koşullarda doğrudan zaman kaybına dönüşüyor.
Mobil tarafta ekranları göreve göre sadeleştiriyoruz. Sahadaki kişi genelde tek bir iş yapar: sayım girer, iş emrini kapatır ya da teslim onayı verir. O iş en fazla iki dokunuşa indiriliyor, geri kalan işlevler masaüstü görünümünde bırakılıyor. Böylece ekran kalabalıklaşmıyor ve yanlış tuşa basma ihtimali azalıyor. Ekran sayısı arttıkça sahadaki kullanım oranı düşüyor; sadelik burada tercih değil zorunluluk.
Denemeler gerçek ortamda yapılıyor. Bağlantının zayıfladığı bölgelerde verinin kaybolup kaybolmadığı, çevrimdışı girilen kaydın bağlantı gelince doğru biçimde işlenip işlenmediği izleniyor. Sahadan gelen ilk geri bildirimler yayın öncesinde uygulanıyor; sonraya bırakılan küçük rahatsızlıklar kullanım alışkanlığını baştan bozuyor.

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

Güvenlik, proje bittikten sonra eklenen bir katman olarak düşünüldüğünde genelde geç kalınır. Kimin hangi veriye ulaşabildiği, parolaların nasıl saklandığı ve kayıtların nerede tutulduğu ilk teknik kararlarla birlikte belirlenir. Sonradan yapılan düzeltmeler çoğu zaman yapının tamamını ilgilendirir ve zaman alır. Bu nedenle güvenlik başlığı, teklif aşamasında ayrı bir madde olarak konuşuluyor.
Kararlar alınırken verinin türü belirleyici oluyor. Müşteri bilgisi, fiyat verisi ve üretim kaydı aynı hassasiyette olmayabiliyor; koruma düzeyi buna göre ayarlanıyor. Kimin ne zaman hangi kaydı görüntülediği de gerektiğinde izlenebilir biçimde tutuluyor. Bu kayıtların ne kadar süre saklanacağı ayrıca kararlaştırılıyor. Saklama süresi dolan kayıtların nasıl temizleneceği de tanımlanıyor.
Yedekleme ile geri yükleme birlikte planlanıyor. Yedeğin hangi sıklıkla alındığı kadar gerçekten geri yüklenebildiği de deneniyor. Erişim iptali de aynı başlıkta konuşuluyor: ekipten ayrılan bir kullanıcının yetkisinin ne kadar sürede kapatılacağı yazılı hale getiriliyor ve sorumlusu belirleniyor.

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

Rapor ekranları çoğu projede en çok istenen, en az kullanılan bölümdür. Bunun nedeni genelde raporun soruyu değil yalnız veriyi göstermesidir. Yönetici bir tablo değil, karar için gereken cevabı arar: hangi hat yavaşladı, hangi müşteri gecikti, hangi kalem beklenenden pahalıya geldi. Özel yazılım kapsamında bu bölüm en sona bırakılmaz. Sorusu belli olmayan bir rapor, bir kez açılıp bir daha dönülmeyen bir ekran oluyor.
Hazırlığa, yönetimin ay içinde sorduğu soruları yazarak başlıyoruz. Her soru için hangi verinin gerektiği, nasıl hesaplanacağı ve hangi dönemle karşılaştırılacağı belirleniyor. Hesaplama kuralı yazılı olmadığında aynı rapor iki ay sonra başka bir sayı gösterebiliyor ve güven kayboluyor. Aynı sayının iki ekranda farklı çıkması, güveni en hızlı yıpratan durum oluyor.
Rapor ekranları küçük tutuluyor ve dışa aktarma imkânı bırakılıyor. Ekipteki herkes kendi görev alanına göre farklı bir görünüm alıyor. Kullanılmayan raporlar belirli aralıklarla kaldırılıyor; kalabalık bir rapor listesi kimsenin işine yaramıyor, üstelik hangi sayıya bakılacağı konusunda kafa karışıklığı yaratıyor.

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

Kullanıma alınan bir sistem sabit kalmaz; mevzuat değişir, yeni bir ürün grubu eklenir, ekip büyür. Bu değişikliklerin nasıl yürütüleceği baştan konuşulmazsa her talep acil işe dönüşür. Planlı bir sürüm düzeni, acil iş sayısını azaltan en pratik yöntemdir ve bütçeyi de öngörülebilir kılar. Öngörülebilir bir takvim, işletmenin kendi planlamasını da kolaylaştırıyor. İhracat yoğunluğu yüksek Kocaeli firmalarında mevzuat ve belge düzeni sık değiştiği için bu öngörü daha da değerli hale geliyor.
Değişiklikleri üç başlığa ayırıyoruz: hata giderme, bakım ve yeni geliştirme. Her biri ayrı kaydediliyor, ayrı önceliklendiriliyor ve ayrı fiyatlanıyor. Böylece hangi işin neden beklediği tartışma konusu olmaktan çıkıyor ve talep sahibi kendi işinin sırasını görebiliyor. Talepleri kaydeden ortak bir liste, sözlü isteklerin kaybolmasını önlüyor.
Yeni sürümler önce ayrı bir ortamda deneniyor. Gerçek veriye benzer bir kopyayla yapılan denemenin ardından yayına alma saati belirleniyor ve geri dönüş yolu hazır tutuluyor. Sürüm notu kısa tutuluyor; kullanıcının neyin değiştiğini tek bakışta görmesi yeterli oluyor.

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

Yalnız anlatılan bir sistem, kullanılmayan bir sistemdir. Toplantı odasında iki saat süren tanıtımın ardından ekip kendi bilgisayarına döndüğünde aynı soruları yeniden sorar. Bir özel yazılım ne kadar iyi kurgulanırsa kurgulansın, öğrenme dinleyerek değil gerçek bir kaydı baştan sona girerek gerçekleşir. Ekran başında geçirilen yarım saat, toplantı odasında geçen iki saatten daha kalıcı oluyor.
Eğitimi görev listesi üzerinden kuruyoruz. Her kullanıcı kendi rolünün günlük işlerini sırayla yapıyor; takıldığı yer not ediliyor ve gerekiyorsa ekran o gün sadeleştiriliyor. Eğitim sırasında çıkan sorular, kullanım notunun içeriğini de doğrudan belirliyor. Eğitim tek seferde bitmiyor; ilk ayın sonunda kısa bir tekrar yapılıyor.
Kısa ve aranabilir bir kullanım dosyası bırakılıyor. Uzun kılavuzlar yerine sık yapılan işlerin adım adım anlatıldığı bölümler tercih ediliyor. Ekipte görev değişikliği olduğunda aynı dosya yeni kişinin başlangıç noktası oluyor ve aynı eğitimi yeniden düzenlemek gerekmiyor.

Teslimden sonraki sorumlulukları yazılı hale getirmek

Devir aşamasında en çok karışan konu, hangi işin kimde olduğudur. Sunucu bakımı, alan adı yenilemesi, yedek kontrolü ve kullanıcı açma işlerinin sahibi yazılmadığında bunlar bir süre sonra kimsenin görevi olmaz. Sanayi işletmelerinde sık görülen ekip değişimi de bu boşluğu zamanla büyütür. Sorumlusu yazılmamış bir iş, ilk yoğun dönemde kendiliğinden askıya alınıyor.
Teslim belgesinde hesaplar, erişim bilgileri, kaynak dosyaların yeri ve üçüncü taraf abonelikleri tek tek listeleniyor. Her satırın karşısında sorumlu kişi ve yenileme tarihi duruyor. Belge tek dosyada tutuluyor ki aranacağı gün kaybolmuş olmasın; kopyası da işletmenin kendi arşivine bırakılıyor. Erişim bilgileri, ortak bir parola yöneticisi gibi güvenli bir yerde tutuluyor.
Destek kapsamı aynı belgede tanımlanıyor: hangi saatlerde ulaşılabileceği, ne kadar sürede dönüş yapılacağı ve hangi işlerin kapsam dışında olduğu yazılıyor. Sınır belli olduğunda ilişki beklenti üzerinden değil yazı üzerinden yürüyor ve iki taraf da aynı metne bakarak konuşuyor.

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 adedi ve test kapsamı belirlendikten sonra çıkarılır. Genelde aşamalı bir takvim kurulur ve ilk aşamada en çok kullanılan akış devreye alınır. Böylece ekip beklemeden çalışmaya başlar, kalan bölümler yayındaki geri bildirimle şekillenir. İlk aşamanın kapsamı dar tutulduğunda geri bildirim de daha erken alınır.
Hazır araçlar iş akışını güvenli ve verimli biçimde karşılıyorsa yeni bir geliştirmeye gerek kalmaz. Süreç hazır ürüne uydurulmak zorunda kalınıyorsa, veri birkaç sistem arasında elle taşınıyorsa ya da lisans yükü büyüyorsa özel yazılım seçeneği değerlendirilir. Karar, iki yolun toplam maliyeti karşılaştırılarak verilir. Karar verilirken mevcut verinin taşınma maliyeti de hesaba katılır.
Karşı sistemin teknik erişime izin vermesi ve veri kurallarının belgelenmiş olması gerekir. Bu koşullar sağlandığında hangi verinin ne sıklıkla aktarılacağı yazılı hale getirilir ve bağlantı ayrı ayrı denenir. Erişim kapalıysa dosya tabanlı aktarım gibi ara çözümler değerlendirilir. Bağlantının koptuğu durumlarda verinin nerede bekleyeceği önceden tanımlanır.
Hesaplar, erişim bilgileri, kaynak dosyalar ve kullanım dokümanı sözleşmedeki kapsam doğrultusunda işletmeye aktarılır. Devir sırasında hangi işin kimde kaldığı tek bir belgede listelenir. Böylece ileride farklı bir ekiple çalışılmak istendiğinde sürekliliği bozan bir bağımlılık oluşmaz. Kaynak dosyaların nerede tutulduğu da aynı belgede açıkça yazılır.
Hata giderme, bakım ve yeni geliştirme ayrı iş türleri olarak kaydedilir. Her talep sisteme girer, önceliklendirilir ve planlı sürümlerle yayına alınır. Acil olanlar ayrı bir akışta yürütülür; böylece planlı işler sürekli ertelenmek zorunda kalmaz. Her sürümün içinde hangi maddelerin yer aldığı kısa bir notla paylaşılır.
Yetkilendirme, kayıt tutma, yedekleme ve hata senaryoları ilk mimari kararlarla birlikte değerlendirilir. Verinin nerede saklandığı ve kimin erişebildiği yazılı hale getirilir. Ekipten ayrılan kullanıcıların erişiminin ne kadar sürede kapatılacağı da aynı belgede tanımlanır. Yedeklerin gerçekten geri yüklenebildiği belirli aralıklarla ayrıca denenir.