Özel yazılımın maliyetini en çok belirleyen etkenler kapsamın ne kadar net tanımlandığı, kaç sisteme ve hangi kalitede arayüzlerle entegrasyon gerektiği, taşınacak verinin hacmi ve temizliği, güvenlik ve mevzuat gereksinimleri, performans ve süreklilik gibi fonksiyonel olmayan gereksinimler, ekip modeli ve canlıya çıktıktan sonraki bakım yüküdür. Saatlik ücret bu denklemin yalnızca bir parçasıdır; bütçeyi asıl oynatan, geç fark edilen belirsizliklerdir. Bu yazıda her etkeni ve riski azaltan uygulamaları anlatıyoruz. Rakam vermiyoruz, çünkü kapsamı tanımlanmamış bir iş için verilen rakam karar vermenize yardımcı olmaz.
Maliyet neden ekran sayısıyla ölçülmez
Alıcılar maliyeti çoğu zaman ekran veya özellik sayısı üzerinden tahmin etmeye çalışır. Oysa birbirine benzeyen iki ekranın arkasındaki iş çok farklı olabilir. Biri tek bir tabloyu listeler. Diğeri üç sistemden veri çeker, kullanıcının yetkisine göre bazı alanları gizler, her değişikliği denetim izine yazar ve onay akışını tetikler. Maliyeti anlamanın yolu, görünen arayüzün arkasındaki kuralları, verileri ve bağlantıları ortaya çıkarmaktır. Aşağıdaki yedi etken, bu görünmeyen işin nereden geldiğini gösterir.
1. Kapsam ve netliği
Kapsam yalnızca bir özellik listesi değildir. Kullanıcı rolleri, her rolün yetkileri, iş akışlarındaki istisnalar (iptal, iade, onay reddi, kısmi teslim), raporlar ve bildirimler kapsamın parçasıdır. Belirsiz kalan her istisna, geliştirme sırasında bir soruya, bazen de yeniden yapılan işe dönüşür. Kapsamı netleştirmek için şunları yapın:
- Her iş akışını adım adım ve istisnalarıyla birlikte yazın.
- Her özellik için bir kabul kriteri tanımlayın: “Bu tamamlandığında kullanıcı şunu yapabilir.”
- İlk sürüm için olmazsa olmazları, sonraya bırakılabileceklerden ayırın.
- Kimin hangi kararı verebileceğini, yani projenin karar yetkisini yazılı hale getirin.
2. Entegrasyonlar
Entegrasyon maliyeti, bağlanılacak sistem sayısından çok o sistemlerin durumuna bağlıdır. Belgelenmiş ve test ortamı olan bir API ile çalışmak; dokümantasyonu eksik, yalnızca canlı ortamda denenebilen veya her değişikliği tedarikçi onayına bağlı bir arayüzle çalışmaktan çok farklıdır. Aynı veri iki sistemde tutuluyorsa hangisinin doğru kabul edileceği de kararlaştırılmalıdır. ERP, CRM ve muhasebe sistemlerine bağlanan projelerde bu konuları ERP ve CRM entegrasyonu sayfamızda daha ayrıntılı ele alıyoruz.
3. Veri taşıma
Eski sistemden yeni sisteme veri taşımak çoğu zaman tahmin edilenden fazla iş çıkarır. Mükerrer kayıtlar, eksik zorunlu alanlar, kod yerine serbest metinle tutulmuş bilgiler ve farklı sistemlerde farklı tanımlayıcılar taşıma öncesinde temizlenmelidir. Bu temizlik teknik ekibin tek başına yapabileceği bir iş değildir; hangi kaydın doğru olduğuna veri sahipleri karar verir. Taşımanın deneme turları, mutabakat kontrolleri (kaynakta ve hedefte kayıt sayılarının ve toplamların eşleşmesi) ve geçiş günü planı da maliyetin parçasıdır.
4. Güvenlik ve mevzuat uyumu
Kişisel veri işleyen her sistem KVKK’ya, AB’deki kişilere hizmet veren sistemler ayrıca GDPR’a uygun tasarlanmalıdır. Rol bazlı yetkilendirme, denetim izi, şifreleme, saklama ve imha kuralları, sızma testleri ve sağlık ya da finans gibi sektörlerin kendi düzenlemeleri ayrı iş kalemleri olarak planlanmalıdır. Bu gereksinimleri proje başında tanımlamak, canlıya çıkışa yakın eklemekten genellikle çok daha az iş çıkarır. Kurumunuzun hazırlığını değerlendirmek için KVKK ve ISO 27001 uyum hizmetimize göz atabilirsiniz.
5. Fonksiyonel olmayan gereksinimler
Sistemin ne yaptığı kadar nasıl çalıştığı da maliyeti belirler. Aşağıdaki soruların her birinin cevabı mimariyi, test kapsamını ve altyapı maliyetini değiştirir.
- Performans: Aynı anda kaç kullanıcı, hangi yanıt süresiyle çalışacak?
- Süreklilik: Sistem kesintiye ne kadar tahammül edebilir, yedekten dönüş ne kadar sürede tamamlanmalı?
- Ölçeklenebilirlik: Veri hacmi ve kullanıcı sayısı önümüzdeki yıllarda nasıl büyüyecek?
- Dil ve bölge: Kaç dil, hangi para birimleri ve tarih biçimleri desteklenecek?
- Mobil: Çevrim dışı çalışma, eski cihaz desteği ve uygulama mağazası yayın süreçleri gerekecek mi?
- Erişilebilirlik ve tarayıcı desteği: Hangi standartlar ve hangi cihazlar hedefleniyor?
Bu beklentiler yazılı değilse ekip ya gereğinden basit ya da gereğinden karmaşık bir çözüm kurar. İki durum da ileride maliyet olarak geri döner.
6. Ekip modeli
Ekibin yapısı ve sizin ekibinizin projeye katılımı maliyeti doğrudan etkiler. Kıdemli bir ekip aynı işi daha az deneme yanılmayla yapabilir. Daha fazla kişi ise her zaman daha hızlı teslim anlamına gelmez, koordinasyon yükünü de artırır. Projenin süresi boyunca sabit bir ekip, işin ortasında değişen bir ekipten daha az bilgi kaybı yaşar. Sizin tarafınızda da kararları hızlı veren bir ürün sahibinin bulunmaması, beklemeye ve yeniden yapılan işe yol açar. Teklif değerlendirirken yalnızca ekibin büyüklüğüne değil, kimlerden oluştuğuna ve sizden ne kadar zaman beklediğine de bakın.
7. Bakım ve işletme
Yazılımın maliyeti canlıya çıkışla bitmez. Barındırma ve bulut kaynakları, izleme ve uyarı, güvenlik güncellemeleri, bağımlılıkların yenilenmesi, yedekleme, destek saatleri ve yeni gelen değişiklik talepleri sistemin ömrü boyunca sürer. Teklifleri karşılaştırırken ilk sürümün bedeli kadar ilk birkaç yılın işletme kalemlerini de sorun. Sistemin kimin tarafından ve hangi dokümanlarla işletileceği baştan belli değilse bu maliyet ileride beklenmedik bir kalem olarak ortaya çıkar.
Özet tablo
| Etken | Eforu artıran durum | Kontrol altında tutan uygulama |
|---|---|---|
| Kapsam | İstisnaları tanımlanmamış iş akışları | Yazılı akışlar ve kabul kriterleri |
| Entegrasyon | Belgesiz, test ortamı olmayan arayüzler | Erken arayüz testi, gerekirse PoC |
| Veri taşıma | Kirli ve mükerrer kaynak veri | Taşıma öncesi temizlik, deneme turları |
| Güvenlik ve uyum | Gereksinimlerin sona bırakılması | Tasarım aşamasında tanımlanan kontroller |
| Fonksiyonel olmayan gereksinimler | Yazılı olmayan performans ve süreklilik beklentileri | Ölçülebilir hedefler |
| Ekip modeli | Karar vericiye erişilememesi | Atanmış ürün sahibi, düzenli demolar |
| Bakım ve işletme | İşletme maliyetinin hesaba katılmaması | Teklifte yer alan destek ve işletme planı |
Riski nasıl azaltırsınız
Maliyeti kontrol etmenin en güvenilir yolu, belirsizliği büyük bütçe harcamadan önce azaltmaktır.
- Keşif ve iş analizi: İş akışları, entegrasyonlar ve veri yazılı hale gelir; tahminler bu belgeye dayanır.
- Kavram kanıtı (PoC): Riskli bir varsayım, örneğin bir API’nin davranışı, bir modelin doğruluğu veya bir veri kaynağının kalitesi, küçük ve sınırlı bir çalışmayla test edilir. Sonuç olumsuzsa büyük bir bütçe harcanmadan yön değiştirilir.
- Aşamalı teslim: İlk sürüm, iş değerini kanıtlayan en küçük kapsama indirilir; sonraki fazlar ilk sürümün kullanım verisiyle planlanır. Yeni bir ürün fikri için bu yaklaşımı MVP geliştirme sayfamızda anlatıyoruz.
- Hazır bileşenler: Kimlik doğrulama, ödeme ve bildirim gibi sizi farklılaştırmayan kısımlar için olgun hazır çözümler değerlendirilir; özel geliştirme, işinizi farklı kılan kısma ayrılır.
- Faz bazlı kabul: Bir sonraki faza geçiş kararı, ölçülebilir kabul kriterlerine bağlanır.
Teklifleri karşılaştırırken sorulacak sorular
- Tahmin hangi varsayımlara dayanıyor ve bu varsayımlar yazılı mı?
- Entegrasyonlar ve veri taşıma ayrı kalemler olarak görünüyor mu?
- Test, dokümantasyon ve devir teslim teklife dahil mi?
- Güvenlik ve KVKK gereksinimleri hangi iş kalemleriyle karşılanıyor?
- Canlıya çıktıktan sonraki destek ve bakım nasıl fiyatlanıyor?
- Kapsam değişiklikleri nasıl talep ediliyor, nasıl onaylanıyor?
İki teklif aynı rakamı gösterse bile bu soruların cevapları farklıysa aslında iki farklı iş fiyatlanmıştır.
Sonraki adım
ALGOFACT’te her proje 30 dakikalık bir keşif görüşmesiyle başlar; ardından kurucu ekip önerilen kapsamı sunar. Risk yüksekse önce bir PoC öneririz. Projenizin maliyetini belirleyen etkenleri birlikte netleştirmek için keşif görüşmesi planlayabilirsiniz.