Özel Yazılım Geliştirme

Özel yazılıma ne zaman ihtiyaç duyulur?

Hazır paket programlar çoğu ihtiyacı karşılar ve genellikle daha ucuzdur. Bu yüzden ilk toplantıda sorduğumuz soru "ne yazalım" değil, "hazır bir çözüm bu işi görür mü" olur. Özel yazılımın gerçekten mantıklı olduğu durumlar şunlar:

• Süreciniz sektör standardından belirgin biçimde farklı ve bu fark rekabet avantajınız
• Kullandığınız paket programlar arasında veri elle taşınıyor, aynı bilgi birden fazla yere giriliyor
• Kullanıcı başına lisans maliyeti, ekip büyüdükçe geliştirme maliyetini geçiyor
• İhtiyacınız olan raporu hiçbir hazır sistem üretemiyor, herkes tabloya döküp elle hesaplıyor
• Verinin sizde kalması zorunlu ve bulut tabanlı paketler bu şartı karşılamıyor

Bu maddelerin hiçbiri geçerli değilse hazır bir çözüm önermekten çekinmiyoruz. Yanlış gerekçeyle başlayan özel yazılım projeleri hem pahalıya mal olur hem de kullanılmadan rafta kalır.

Analiz aşamasında tam olarak ne yapılıyor?

Projelerin başarısını en çok belirleyen aşama burasıdır ve atlanmaya en açık olan da budur. Analizi üç adımda yürütüyoruz.

Yerinde gözlem. Süreci anlatan kişiyle değil, süreci yürüten kişiyle konuşuyoruz. Çoğu işletmede yazılı prosedürle fiilî uygulama arasında fark vardır ve yazılım fiilî uygulamayı bilmeden yazılırsa kullanılmaz. Depoda çalışan kişinin klavyeye bakmadan barkod okuttuğunu görmek, ekran tasarımını doğrudan değiştirir.

Veri modeli. Hangi varlıklar var, aralarındaki ilişkiler ne, hangi alan zorunlu, hangi kayıt silinebilir, geçmiş nasıl saklanacak. Veri modeli yanlış kurulduğunda sonradan düzeltmenin maliyeti, ilk yazımın birkaç katı olur. Bu yüzden bu aşamada acele etmiyoruz.

Kabul kriterleri. Her işlev için "hangi durumda tamamlanmış sayılır" sorusunu yazılı olarak cevaplıyoruz. "Sipariş oluşturulabilmeli" yeterli değildir; stok yetersizse ne olacağı, aynı anda iki kullanıcı aynı ürünü alırsa ne olacağı, iptal edilen siparişin stoğa nasıl döneceği yazılır. Bu doküman hem geliştiricinin hem de sizin referansınız olur.

Geliştirme süreci nasıl yürüyor?

İki haftalık sprintlerle çalışıyoruz. Her sprintin başında o iki haftada nelerin biteceği belirleniyor, sonunda çalışan bir sürüm staging ortamında gösteriliyor. Bu ritmin iki faydası var: siz ilerlemeyi slaytla değil çalışan yazılımla görüyorsunuz, biz de yanlış anlaşılmayı aylar sonra değil iki hafta içinde fark ediyoruz.

Kod tarafındaki standartlarımız şunlar: PSR-12 kodlama standardı, her değişikliğin ayrı dalda geliştirilip birleştirme isteğiyle inceleme sürecinden geçmesi, kritik iş kuralları için birim testi, sipariş ve ödeme gibi akışlar için entegrasyon testi, otomatik statik analiz. Değişiklikler önce staging ortamına, testler geçtikten sonra canlıya gidiyor.

Demo toplantılarını kısa tutuyoruz ve gösterilen her işlev için tek bir soru soruyoruz: bu, sizin gerçek işinizi yapıyor mu. Toplantıya süreci fiilen yürüten kişinin katılması, yöneticinin katılmasından daha değerli sonuç veriyor. Toplantıda çıkan geri bildirimler aynı gün kayda geçiriliyor ve bir sonraki sprint planına giriyor.

Ortam ayrımı önemli: geliştirme, staging ve canlı olmak üzere üç ortam kuruyoruz. Canlı verinin kopyası staging ortamına aktarılırken kişisel veriler maskeleniyor; bu hem KVKK açısından gerekli hem de test verisinin gerçekçi olmasını sağlıyor.

Proje ne kadar sürer ve neden bu kadar sürer?

Orta ölçekli bir iş yazılımı için gerçekçi süre 4 ila 9 aydır. Sürenin dağılımı kabaca şöyle: analiz ve tasarım yüzde 20, geliştirme yüzde 50, test ve düzeltme yüzde 15, veri göçü ve devreye alma yüzde 15.

Süreyi uzatan en büyük etken beklenmedik iş kurallarıdır. "Basit bir izin talebi" diye başlayan bir modül, vardiyalı çalışanlar, yıllık devir hakları, avans izin ve farklı onay zincirleri eklenince üç katına çıkabiliyor. Bu yüzden analizde uç durumları özellikle kurcalıyoruz; "peki ya şu olursa" sorularını erken sormak, sonradan sormaktan çok daha ucuz.

Süreyi kısaltan etken ise sizin tarafınızda karar verecek tek bir sahibin olmasıdır. Kararların komiteye gitmesi, sprint ritmini bozan en yaygın nedendir.

Fiyat nasıl belirleniyor?

İki modelle çalışıyoruz. Sabit fiyat, kapsamın analizle net çıkarıldığı projelerde uygulanır; riski biz taşırız, karşılığında kapsam değişikliği ayrı fiyatlanır. Zaman ve malzeme modelinde ise aylık ekip kapasitesi satın alırsınız, öncelikleri sprint sprint siz belirlersiniz; kapsamın gelişerek netleştiği ürünlerde bu model daha verimli çalışıyor.

Fiyatı belirleyen teknik başlıklar: modül sayısı, kullanıcı rolü ve yetki karmaşıklığı, entegre olunacak dış sistem sayısı, raporlama derinliği, eş zamanlı kullanıcı hedefi ve veri göçünün hacmi. Eski sistemden veri aktarımı çoğu projede küçümsenen ama en çok zaman alan kalemdir; veri tutarsızsa temizleme işi de projeye eklenir.

Kaynak kod kimin olur, sonradan başka ekiple devam edebilir miyiz?

Kaynak kodun tamamı sizindir. Proje boyunca kod sizin adınıza açılan bir depoda tutulur, teslimatta depo yönetimi size devredilir. Kullanılan kütüphaneler açık kaynak lisanslıdır; kapalı bir bileşene bağımlılık oluşturmuyoruz. Gizli bir katman, şifrelenmiş dosya veya süre kilidi kullanmıyoruz.

Devri kolaylaştıran şey teslim dokümanıdır: mimari şema, veri modeli, ortam değişkenleri, kurulum adımları, dağıtım süreci ve bilinen teknik borç listesi. Bu dokümanla yeni bir ekip sistemi birkaç gün içinde çalışır hâle getirebilir.

Devreye aldıktan sonra ne oluyor?

Canlıya geçiş, projenin en riskli anıdır. Geçişi mümkünse paralel çalışma dönemiyle yapıyoruz: yeni sistem devredeyken eski sistem bir süre okuma amaçlı erişilebilir kalıyor. Geçiş öncesi geri dönüş planı yazılıyor ve süresi ölçülüyor.

Geçiş gününü de takvimde doğru seçmek gerekiyor. Ay sonu kapanışı, sezon yoğunluğu ve envanter sayımı gibi dönemlerin dışında kalan, ekibin göreli olarak rahat olduğu bir hafta seçiyoruz. Geçiş sabahı sahada destek veriyor, ilk günün sonunda kısa bir değerlendirme yapıyoruz.

Devreye almadan sonraki 30 gün stabilizasyon dönemidir; bu süreçte kapsam içindeki hatalar ücretsiz düzeltilir. Ardından bakım ve destek anlaşması devreye giriyor. Bu anlaşma güvenlik güncellemeleri, yedekleme kontrolü, izleme ve aylık belirli sayıda geliştirme talebini kapsıyor. Yazılımlar canlı sistemlerdir; kullanıldıkça yeni ihtiyaç doğurur ve bunu baştan bütçelemek en sağlıklı yaklaşımdır.

Kapsam değişikliği talepleri nasıl yönetiliyor?

Hiçbir yazılım projesi başladığı kapsamla bitmez ve bu kötü bir şey değildir. Sistemi kullanmaya başladıkça yeni ihtiyaçlar görünür hâle gelir. Sorun, değişikliklerin kayıt altına alınmadan ve etkisi ölçülmeden sürece sokulmasıdır; projelerin gecikmesinin en yaygın nedeni budur.

Kurduğumuz süreç şöyle işliyor:

• Talep yazılır: Sözlü konuşulan hiçbir değişiklik doğrudan geliştirmeye girmez. Talep, takip sisteminde neden ve beklenen sonuçla birlikte kaydedilir.
• Etki analizi yapılır: Bu değişiklik hangi ekranları, hangi veri yapılarını ve hangi mevcut işlevleri etkiliyor. Çoğu talep göründüğünden geniştir; bir alan eklemek rapora, dışa aktarıma ve yetki kurallarına da dokunur.
• Süre ve maliyet çıkarılır: Değişikliğin geliştirme ve test süresi tahmin edilir, hangi sprintten yer alacağı belirtilir.
• Karar verilir: Ya mevcut kapsamdan bir madde çıkarılır ya süre uzatılır ya da talep sonraki aşamaya bırakılır. Üçünden birini seçmeden kapsam büyütülmez.

Bu süreç bürokrasi yaratmak için değil, kararın bilinçli verilmesi için var. Deneyimimize göre taleplerin önemli bir bölümü, etki analizi görüldükten sonra sizin tarafınızdan geri çekiliyor; çünkü kazandıracağı fayda ile maliyeti karşılaştırılabilir hâle geliyor.

Zaman ve malzeme modelinde çalışan projelerde bu süreç daha da basit işliyor: her sprint başında öncelik listesini birlikte sıralıyoruz, yeni talep listeye giriyor ve altta kalan bir madde otomatik olarak sonraki sprinte kayıyor. Kapsam tartışması yerine öncelik tartışması yapılıyor, bu da çok daha verimli bir konuşma oluyor.