Hazır Paket mi Özel Yazılım mı? Karar Çerçevesi
Ne zaman özel yazılım, ne zaman hazır paket?
Süreciniz sektördeki genel uygulamadan farklı değilse ve bu farklılık rekabet avantajı üretmiyorsa hazır paket doğru seçimdir. Özel yazılım; süreç gerçekten farklıysa, paket ürünün uyarlama sınırına dayanıyorsanız veya veriyi ve iş kurallarını kendi sisteminizde tutmanız gerekiyorsa anlamlıdır. Karar, özellik listesi karşılaştırması değil, dört ölçütün birlikte değerlendirilmesidir.
Dört karar ölçütü
- Süreç farkı: Bu iş akışı rakiplerinizle aynı mı? Aynıysa özel geliştirme, ortak bir çözümü yeniden üretmekten ibaret olur.
- Değişim hızı: Kural yılda bir mi değişiyor, ayda bir mi? Sık değişen kurallar paket üründe her seferinde uyarlama talebi ve bekleme süresi üretir.
- Veri sahipliği: Veri nerede tutulacak, dışa aktarım hangi formatta ve hangi sürede alınabilecek?
- Devralınabilirlik: Yazılımı geliştiren ekip değişirse başka bir ekip devralabilir mi?
Dört ölçütten en az ikisi özel yazılımı işaret etmiyorsa, pakete uyarlama yapmak genellikle daha düşük toplam maliyet üretir.
Karma model çoğu zaman doğru cevaptır
Uygulamada en sık işe yarayan yapı, muhasebe ve stok gibi standart alanlarda paket ürün kullanıp; farklılaşan alanı ([bayi portalı](/blog/bayi-portal-rehberi), [saha uygulaması](/blog/plasiyer-takip-rehberi), üretim izleme, müşteri portali) özel geliştirip aradaki veri akışını API ile kurmaktır. Bu modelde kritik nokta entegrasyon sözleşmesidir: hangi kayıt hangi sistemde doğrulanır, çakışma olduğunda hangisi kazanır, kayıt eşleşmesi hangi anahtarla yapılır.
Devralınabilirliği sözleşmeye yazın
Özel yazılımın en büyük riski teknoloji değil, bilgi tekelidir. Sözleşme aşamasında şunları isteyin:
- Kaynak kodun deposu ve erişim hakkı; proje bitmeden önce de erişilebilir olmalı
- Çalışır kurulum adımlarının yazılı olduğu bir kurulum dokümanı
- Veritabanı şeması ve alan sözlüğü
- Ortam değişkenleri, üçüncü parti servis listesi ve bağımlılık sürümleri
- Yeni bir geliştiricinin sıfırdan ortam kurup çalıştırabildiğinin bir kez fiilen denenmesi
Son madde en önemlisidir: dokümanın doğru olduğu ancak bir kez uygulanarak anlaşılır.
Teknik borcu görünür tutan üç ölçüm
- Ortam kurulum süresi: Yeni bir geliştirici projeyi ilk kez ne kadar sürede ayağa kaldırıyor?
- Değişiklik teslim süresi: Küçük bir iş kuralı değişikliği talepten canlıya kaç günde çıkıyor?
- Geri dönüş oranı: Canlıya çıkan değişikliklerin kaçı hata nedeniyle geri alınıyor?
Bu üç sayı yükseliyorsa sorun ekip hızında değil, mimaride ve test kapsamındadır.
Kapsamı küçük tutmanın pratik yolu
İlk sürümü tek bir uçtan uca iş akışıyla sınırlayın: bir kayıt, baştan sona, gerçek kullanıcıyla ve gerçek veriyle çalışsın. Yatayda modül eklemek yerine dikeyde tek akışı tamamlamak, hem erken geri bildirim verir hem de entegrasyon risklerini projenin başında ortaya çıkarır.
Sık sorulan sorular
Özel yazılımda kaynak kodu kime ait olmalıdır?
Bu bir sözleşme maddesidir, varsayılan değildir. Kodun mülkiyeti, kullanım hakkı ve üçüncü parti bileşenlerin lisansları ayrı ayrı yazılmalıdır. Açık kaynak bileşenlerin lisans türleri de listelenmelidir.
Özel yazılımda güvenlik nasıl doğrulanır?
Kabul aşamasına, kimlik doğrulama, yetkilendirme, oturum yönetimi, girdi doğrulama ve kayıt tutma başlıklarını içeren bir kontrol listesi ekleyin. OWASP ASVS bu listeyi hazır bir çerçeve olarak sunar ve seviye seçimiyle kapsamı ölçeklendirmenize izin verir.
Küçük bir ekip özel yazılımı sürdürebilir mi?
Sürdürülebilirlik ekip büyüklüğünden çok otomasyona bağlıdır. Otomatik test, tek komutla kurulum ve tekrarlanabilir dağıtım varsa küçük ekip yeterlidir; bunlar yoksa büyük ekip de yetmez.