Yazılım

Yazılım projesini iş akışınızdan yola çıkarak planlıyoruz

İyi bir yazılım, işletmenizde zaten var olan düzeni hızlandırır; olmayan bir düzeni tek başına kuramaz. Bu yüzden ilk toplantıda kod konuşmuyoruz. Bir siparişin ya da talebin ilk telefondan faturaya kadar hangi ellerden geçtiğini kâğıt üzerinde birlikte çiziyoruz. Bu çizim, projenin sonraki bütün kararlarına zemin olur. Afyonkarahisar’da bayilere ürün gönderen bir gıda üreticisini düşünün. Siparişler telefonla gelir, bir deftere yazılır, sonra tabloya aktarılır ve sevkiyat listesi ayrıca hazırlanır. Aynı bilgi her yeniden yazıldığında yeni bir hata ihtimali doğar. Çizim, bu tekrarların nerede başladığını ve hangisinin ortadan kaldırılabileceğini açıkça gösterir. Akışı çizerken bekleme noktalarını da işaretliyoruz. Bir onayın yöneticiden dönmesini beklemek ya da stok bilgisini depodan telefonla sormak bu noktalara örnektir. Geliştirmenin önceliğini en çok zaman kaybettiren adım belirler. Başarının neye göre ölçüleceğini de bu aşamada birlikte yazıyoruz. Bu ölçüt, aynı kaydın yalnızca bir kez girilmesi ya da onayların kayıt altına alınması olabilir.

Akış netleştiğinde ilk soru, bu işin gerçekten yeni bir geliştirme isteyip istemediğidir. Muhasebe, ön muhasebe ya da basit stok takibi için piyasada olgun hazır programlar bulunur. Hazır bir aracın üzerine kurulacak küçük bir ek, çoğu zaman daha ekonomik bir çözüm olur. Böyle bir durumda bunu size açıkça söylüyoruz. Özel yazılım, işinizin kuralları hazır paketlerin kalıbına sığmadığında anlam kazanır. Mermer plakaların ölçü, kalınlık ve yüzey işlemine göre ayrı ayrı fiyatlandığı bir üretimi düşünün. Böyle bir hesap hazır programda çoğu zaman elle yapılan ek işlere dönüşür. Kurallara göre çalışan bir hesap ekranı ise bu yükü çalışanın omzundan alır. Karar vermeden önce iki yolu aynı tabloda karşılaştırıyoruz. Lisans ve kurulum giderleri, uyarlama sınırları, veri taşıma zorluğu ve gelecekteki bakım yükü bu tabloda yan yana durur. Çoğu durumda her şeyi değiştirmek de gerekmez; mevcut programınızı koruyup yalnızca eksik kalan parçayı geliştirmek mümkündür. Seçimi bu somut karşılaştırmaya bakarak siz yaparsınız.

Geliştirme kararı verildiğinde bütçeyi tek bir toplam olarak değil, iş kalemleri üzerinden konuşuyoruz. Bir yazılım teklifinde yalnızca geliştirme bedeline bakmak eksik bir hesap olur. Sunucu, alan adı, üçüncü taraf lisanslar ve yıllık bakım da sistemin ömrü boyunca sürecek giderlerdir. Teklifimizde bu kalemleri ayrı satırlarda gösteriyoruz. Değişiklik taleplerinin nasıl ele alınacağı da baştan yazılmalıdır. Proje sürerken ortaya çıkan her yeni istek kapsamı büyütür. Biz bu istekleri bir listede topluyor, etkisini gördükten sonra hangi aşamaya alınacağına sizinle karar veriyoruz. Böylece ne bütçe sessizce büyür ne de önemli bir istek unutulur. Karşılaştırma yaparken bugün elle yürütülen işin maliyetini de hesaba katın. Her gün aynı bilgiyi birkaç kez yazan çalışanların harcadığı zaman, görünmeyen bir giderdir. Sistemin getirisini bu zamanla birlikte düşünmek daha gerçekçi bir tablo sunar. Bu tablo, ilk sürüme hangi işlerin alınacağına karar verirken de yol gösterir.

İlk sürümü ekibinizin günlük işine göre kuruyoruz

Her isteği ilk sürüme sığdırmaya çalışmak yazılım projesini uzatır ve ekibin sabrını tüketir. Biz günlük işin en sık tekrar eden akışını seçip onu uçtan uca çalışır hâle getiriyoruz. Diğer istekler sıraya alınır ve kaybolmaz. Sıranın nasıl belirlendiğini de sizinle paylaşıyoruz; böylece hangi isteğin neden beklediği herkes için açık olur. Örneğin bir termal otel için ilk sürüm yalnızca kaplıca randevularını yönetebilir. Oda rezervasyonuyla bağlantı ve misafir bildirimleri sonraki aşamalara bırakılır. Önemli olan, ilk sürümün veri yapısının bu eklemeleri taşıyacak biçimde kurulmasıdır. Aksi hâlde her yeni aşama, öncekinin yeniden yazılmasını gerektirebilir. İlk sürümün sade olması ekibin yeni düzene alışmasını da kolaylaştırır. Alışkanlıklar bir anda değişmez; az sayıda ekranla başlamak direnci azaltır. Kâğıt defterle çalışmaya alışmış bir depo sorumlusu, önce yalnızca giriş ve çıkış ekranını kullanarak başlayabilir. Bu ekranların nasıl görüneceğine ise onları kullanacak kişilerle birlikte karar veriyoruz. Bir ekranın işe yarayıp yaramadığını, onu her gün kullanacak kişi söyleyebilir.

Bu yüzden taslakları yalnızca yöneticiyle değil, sahadaki kullanıcıyla da deniyoruz. Üretim hattında eldivenle tablet kullanan bir çalışan için büyük düğmeler ve az yazı gerekir. Muhasebe biriminde çalışan biri ise tek ekranda çok sayıda kaydı görmek ve klavyeden ayrılmadan ilerlemek ister. Tekrarlanan veri girişini azaltmak için barkod okuyucu, otomatik tamamlama ve varsayılan değerler kullanıyoruz. Depoya giren bir kolinin barkodu okutulduğunda ürün, parti ve tarih bilgisi kendiliğinden dolar. Hatalı bir girişte neyin yanlış olduğunu ve nasıl düzeltileceğini anlatan açık uyarılar gösteriyoruz. Sık yapılan bir işlemde azalan her tıklama önem taşır. Sahadaki ekip için de ayrı bir bakış gerekir. Satış temsilcileri, servis ekipleri ya da sevkiyat şoförleri gün boyu masa başında değildir. Onlar için sistemin telefondan kullanılabilen sade bir bölümü hazırlanabilir. Tarayıcıdan açılan bu arayüzde yalnızca stok sorgulama, sipariş girme ve teslimat onayı gibi sahada gereken işlemlere yer veriyoruz.

İlk sürümün bugün kullandığınız programlarla da konuşması gerekebilir. Muhasebe programınız, e-fatura sağlayıcınız ya da kargo firmanız bu bağlantıların tipik örnekleridir. Bağlantının nasıl kurulacağını karşı tarafın sunduğu arayüzler belirler. Bu yüzden entegrasyon olanaklarını teklif hazırlamadan önce inceliyor, sınırlı olan noktaları size baştan bildiriyoruz. Her veri için tek bir asıl kaynak belirliyoruz. Ürün fiyatı muhasebe programında tutuluyorsa yeni sistem onu oradan okur, kendi kopyasını ayrıca değiştirmez. Böylece iki ekranda iki farklı fiyat görme sorunu ortadan kalkar. Hangi bilginin hangi yöne aktarılacağını da yazılı bir tabloda gösteriyoruz. Bağlantı koptuğunda sistemin ne yapacağını da baştan tasarlıyoruz. Gönderilemeyen kayıtlar bir kuyrukta bekler ve bağlantı düzelince yeniden denenir. Sorun sürerse ilgili kişiye bildirim gider ve bekleyen kayıtlar listede görünür. Bu senaryoları, ilk sürüm devreye girmeden önce gerçek verilerle ayrıca sınıyoruz.

İlk sürümü gerçek verilerle sınayıp adım adım devreye alıyoruz

Bir yazılım sistemini yalnızca her alanı eksiksiz doldurulmuş örnek bir kayıtla denemek yanıltıcı olur. Asıl sınav, eksik bilgiyle açılan bir sipariş ya da yarıda iptal edilen bir işlemdir. Test senaryolarını bu yüzden ekibinizin gerçekten yaşadığı durumlardan derliyoruz. İade, kısmi sevkiyat ve sonradan değişen fiyat bu senaryoların başında gelir. Denemeleri, işletmenizin veri yapısını temsil eden örneklerle yapıyoruz. Bulunan hataları dağınık mesajlar yerine tek bir listede topluyor ve önemine göre sıralıyoruz. Her kaydın kim tarafından bildirildiği ve ne zaman düzeltildiği bu listede görünür. İşleyişi yakından bilen ekibinizin de bu denemelere katılmasını istiyoruz. Yeni sisteme geçiş için işinizin en sakin dönemini seçmenizi öneriyoruz. Bayram öncesi siparişlerin yoğunlaştığı bir üreticide geçişi o döneme denk getirmek gereksiz risk yaratır. Tarihi, takviminizi birlikte inceleyerek belirliyoruz. Geçiş gününde kimin hangi işten sorumlu olduğunu da önceden yazılı hâle getiriyoruz. Eski verilerin aktarımını önce küçük bir örnekle deniyoruz.

Müşteri kartları, açık siparişler ve stok bakiyeleri yeni sistemde kontrol edilir; tutmayan alanlar düzeltilir. Tam aktarım ancak bu provadan sonra yapılır. Aktarım sırasında bozuk ya da yinelenen kayıtlar çıkarsa, bunları silmek yerine size gösterip nasıl ele alınacağına birlikte karar veriyoruz. Geçişten sonraki ilk günlerde eski yöntemi bir anda bırakmamak güven verir. Kısa bir süre iki düzen yan yana yürür ve sonuçlar karşılaştırılır. Ekip yeni sisteme güvendiğinde eski tablolar arşive kaldırılır. Bu dönemde gelen sorular için ekibimizden birini doğrudan ulaşılabilir tutuyoruz. Canlı kullanıma geçmeden önce veri güvenliğini de son kez gözden geçiriyoruz. Müşteri bilgileri, fiyat listeleri ve üretim reçeteleri işletmenizin en değerli varlıkları arasındadır. Kişisel veri içeren alanları ilgili mevzuatı gözeterek saklıyor, gereksiz veri toplamıyoruz. Hangi bilginin neden tutulduğunu da yazılı olarak belgeliyoruz. Kimin neyi görebileceğini kişilerin unvanına göre değil, üstlendikleri işe göre belirliyoruz.

Sisteme girişte iki adımlı doğrulama ve güçlü parola kuralları kullanıyoruz. Sunucuyla kurulan bağlantılar şifrelenir. Mesai dışında yapılan toplu silme gibi olağan dışı hareketler için yöneticiye uyarı gönderilmesi de mümkündür. Yedekleme sıklığını, kaybetmeyi göze alabileceğiniz iş miktarına göre birlikte belirliyoruz. Gün boyu sipariş alan bir işletme için gece alınan tek bir yedek yetmeyebilir. Yedekler şifreli olarak ve sunucudan ayrı bir konumda tutulur. Geri yükleme adımını da yalnızca kâğıt üzerinde bırakmıyor, canlıya geçmeden önce deneyerek doğruluyoruz. Canlı kullanımın ilk döneminde gelen hata bildirimlerini de aynı düzenle ele alıyoruz. Her bildirim tek bir listede toplanır, önemine göre sıralanır ve çözüldüğünde bildiren kişiye haber verilir. İşi durduran bir sorun ile küçük bir görünüm hatası aynı sırada beklemez. Bu dönem tamamlandığında sistem, günlük kullanım için ekibinize devredilmeye hazırdır.

Canlıya geçişin son adımında sistemi ekibinize devrediyoruz

Teslim, bir dosyayı elden vermek değil işleyişi birlikte devretmektir. Ekibinizden bir kişiyi sistem sorumlusu olarak belirlemenizi öneriyoruz. Bu kişi eğitimlere daha ayrıntılı katılır ve iş arkadaşlarının günlük sorularını ilk elden yanıtlar. Bize ulaşan talepler de böylece daha net tarif edilmiş olur. Kullanım anlatımlarını uzun kılavuzlar yerine görev odaklı kısa notlar olarak hazırlıyoruz. “Yeni bayi nasıl eklenir” ya da “iade nasıl işlenir” gibi başlıklar, aranan bilgiyi kolayca buldurur. Sistemde bir ekran değiştiğinde ilgili not da güncellenir. Yeni işe başlayan bir çalışan da bu notlarla kimseyi beklemeden işe alışabilir. Projenin kod deposu baştan işletmeniz adına açılan bir hesapta tutulur. Veritabanı ve sunucu erişimleri de teslimle birlikte size geçer. Sistemin nasıl kurulduğunu anlatan teknik belgeler teslim paketinin parçasıdır. İleride başka bir geliştiriciyle çalışmak isterseniz yeni ekip işi sıfırdan çözmek zorunda kalmaz. Devrin önemli bir parçası da günlük ayarları sizin elinize bırakmaktır.

Fiyat listesi, ürün tanımları ya da vergi oranı gibi sık değişen bilgiler için yönetim ekranları hazırlıyoruz. Bu ayarlar için her seferinde geliştiriciye iş yazmanız gerekmez. Değişikliği yapan kişi ve tarih de kayda geçer. Yeni bir çalışan eklemek, rolünü belirlemek ya da ayrılan birinin erişimini kapatmak da yönetici ekranından yapılır. Hangi rolün hangi ekranı göreceğini bir tabloda işaretlemek yeterlidir. Böylece kadro değişiklikleri kimseyi beklemeden sisteme yansır. Yetkilerin belirli aralıklarla gözden geçirilmesi için basit bir kontrol listesi de bırakıyoruz. Raporlarda da benzer bir esneklik sağlıyoruz. Tarih aralığı, bayi ya da ürün grubuna göre süzülen listeler hesap tablosu dosyasına aktarılabilir. Yeni bir rapor ihtiyacı doğduğunda önce mevcut filtrelerle karşılanıp karşılanamayacağına bakıyoruz. Gerçekten yeni bir geliştirme gerekiyorsa bunu ayrı bir iş olarak planlıyoruz. Devrettiğimiz yapının işletmenizin büyümesine de hazır olması gerekir.

Yeni bir depo, şube ya da ürün grubu eklendiğinde sistem buna uyum sağlamalıdır. Veri yapısını baştan birden çok konumu taşıyacak biçimde kurmak bu büyümeyi kolaylaştırır. Hangi büyüme senaryolarını öngördüğünüzü ilk görüşmede sormamız bu yüzdendir. Teslimden sonra kullanım verilerine belirli aralıklarla birlikte bakıyoruz. Hiç açılmayan bir ekran gereksiz olabilir, sürekli dışarı aktarılan bir liste ise eksik bir raporun işaretidir. Kayıt sayısı arttıkça yavaşlayan listeler de bu incelemelerde fark edilir. Sayfalama ya da ağır raporların günlük işten ayrı çalıştırılması gibi önlemler sistemin hızını korur. Sonraki geliştirmeleri bu somut izlere göre sıralıyoruz. Kullanılan yazılım kütüphaneleri ve altyapı bileşenleri de zamanla eskir. Güvenlik yamalarını ve sürüm güncellemelerini planlı yapmak, birkaç yıl sonra toptan bir yenileme zorunluluğu doğması riskini azaltır. Afyonkarahisar’daki işletmelerle kurduğumuz bakım düzeninde bu güncellemeler takvime bağlanır. Sistem böylece ilk günkü hâlinde kalmaz, işletmenizle birlikte büyür.

Yazılım projeleri hakkında merak edilen sorular

Bugün kullandığınız tabloları, formları ve belgeleri örnek olarak getirmeniz çok işe yarar. Bir işlemi başından sonuna anlatabilecek bir çalışanınızın toplantıya katılması da önemlidir. Kesin bir özellik listesi hazırlamanıza gerek yok; ihtiyaçları birlikte yazıya dökeceğiz. Ardından kapsamı ve aşamaları gösteren yazılı bir teklif hazırlıyoruz.

Çalışmayı kısa aşamalara bölüyor ve her aşamanın sonunda çalışan bölümü size gösteriyoruz. Deneme ortamına erişiminiz olduğu için ekranları istediğiniz zaman kendiniz de inceleyebilirsiniz. Geri bildirimleriniz ortak bir listede toplanır ve hangisinin ne zaman ele alınacağı görünür. Toplantılarda alınan kararları yazılı bir özetle paylaşıyoruz.

İki seçenek de mümkündür. Bulut sunucuda çalışan bir sistem her yerden erişilebilir ve sizin için donanım bakımı gerektirmez. Kendi sunucunuza kurulum ise verinin binada kalmasını isteyen işletmeler için tercih edilir; ancak yedekleme ve güvenlik sorumluluğu da size geçer. Seçenekleri maliyet ve bakım yüküyle birlikte karşılaştırıyoruz.

Her zaman değil. Küçük bir işletmede sorun çoğu zaman tek bir süreçte düğümlenir; örneğin teklif hazırlamak ya da randevu takibi. Bu durumda yalnızca o süreci çözen küçük bir araç, büyük bir paketten daha ekonomik olabilir. Hazır bir çözüm yetiyorsa bunu açıkça söylüyor, gereksiz geliştirme önermiyoruz.

Zorunlu değildir; bakım isteğe bağlı bir hizmettir ve kapsamı ayrıca yazılır. Bakım almasanız da güncel tutulması gereken bileşenlerin listesini teslimde veriyoruz. Bakım anlaşmasında güvenlik güncellemeleri, yedek kontrolleri ve hata düzeltmeleri yer alır. Yeni özellik talepleri ise ayrı bir geliştirme olarak planlanır.

Eklenebilir; ancak bir özelliğin yapay zekâ içermesi tek başına bir değer taşımaz. Gelen e-postaları konusuna göre ayırmak, ürün açıklaması taslağı hazırlamak ya da geçmiş satışlardan talep eğilimi çıkarmak somut kullanım örnekleridir. Böyle bir özellik önce küçük bir denemeyle sınanır. Sonuçlarını kontrol edecek bir çalışanın sürece dahil olması gerekir.